Reflections on HamLib

There is no doubt in my mind that HamLib is a brilliant implementation of rig control software. As an API, it's contribution to the Ham Community is invaluable.

However, HamLib's strength is it's weakness: HamLib must exist to unify the interface to computer-controllable radios because the manufacturers have neglected to revolutionize how we interface with the rigs, on their own. With the notable exception of Kenwood Inc., instead of being a symbiotic relationship, Rig Manufacturers see computerized control as an afterthought... an 'added feature.'

'...Allow just enough of the radio to be controlled by computer, so that contesters can take advantage of our rig,' in the case of main-line HF Radios. Of course, those Contesters are usually the ones who spend oodles of money for the newest features, either simply to posses them, or in order to try and increase their scores.

Perhaps 'Regular Hams,' are not seen as being lucrative enough to justify innovations that could change the Radio Art.

Moreover, each manufacturer's implementation of computer control strategies is so radically different from the next, that the only common denominators in a unified control protocol -- especially when it comes to 'conventional,' 'narrow-bandwidth' rigs -- is the ability to change frequencies, bands, and modes.

Even these features have their own discrepancies: There are differing implementations (if any implementation exists) of feedback, or 'alerts,' so that the controlling software will knows that an operator changed something on the face of Radio (something very important to successful software control paradigms).

So, what can be gleaned from HamLib, and applied to OpenTRx?

1) The groundwork has already been laid: HamLib already defines the minimum operating features a unified protocol must have in order to flexibly interface with a CLASS 1a OpenTRx (OpenTRx 1a) module. 

2) An OpenTRx 1a adapter should, effectively, be a host of the HamLib libraries and rig interface, be it single-purpose, or multi-rig capable.

3) The OpenTRx Protocols should be offered as rig type in HamLib, ensuring backwards compatibility with existing software implementations, meaning that CLASS 2 interface modules must be backwards-compatible with the CLASS 1a control librar[ies].

4) There is no need to implement OpenTRx as a serial- or parallel-port-based protocol, as most all newer computer configurations will not easily or reliably host these technologies, and any that still do will most easily implement the established HamLib libraries natively.