Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts
Library to control radio transceivers and receivers
Brought to you by:
n0nb
From: Nate B. <n0...@n0...> - 2014-03-05 02:26:57
|
* On 2014 04 Mar 15:36 -0600, Art Botterell wrote: > On Mar 4, 2014, at 1:00 PM, Tony Langdon <vk...@gm...> wrote: > > How will we handle radios that are capable of having multiple > > simultaneous receivers, for instance? (e.g. the TAPR HPSDR software > > defined radios can have up to 7 receivers independently running at > > the same time). > > A great question. My current thinking is to define a "device" (aka a > "rig") as a black box that has a single connection to a server. > Within the device there may be multiple receivers, possibly even > multiple transmitters, and various other components... amplifiers of > various types, filters of various types, meters and controls of > various types, etc. (This is why we need the capacity to "discover" > from the device its particular composition.) The manufacturers are throwing new wrinkles at us all the time. I learned earlier this year that the FT-950 has a command to control at least one of the Yaesu rotor models. Hamlib has entirely separate code paths for radios and rotors and not easily resolved. On a related note, Elecraft has the K-line which consists of the K3 transceiver, P3 panadapter, KAT500 auto tuner, and KPA500 amplifier all of which can be daisy-chained to a single RS-232 port and they handle receiving commands between the devices. At the rate things are going, the server will need to expect any sort of device on a physical port and multiple devices of differing sorts as the K-line above. > Again, we get into questions of what's essential and what's just an > artifact of individual product design. E.g., many rigs have memories, > multiple VFOs, RIT, XIT and so on, even though in actuality each > transmitter and each receiver can only be set to one operating > frequency at a time. * Case in point, up through version 1.2.15.3 Hamlib assumes that when the RIT or XIT is set to 0 Hz that the intention is to disable the RIT/XIT function. Sounds good in theory, but one developer of a downstream contest logger wants to have his program clear the RIT on his K3 while leaving the RIT activated so he can manually adjust it when needed on some future QSO. I was able to give him a specific work-around for the K3 and then implemented a more general solution for the dummy and k3 banckends in anticipation of Hamlib 3.0, but haven't gotten motivated to tackle the other backends. Sigh. At the time it was probably a reasonable assumption to do it that way. I guess I shouldn't be bogging this discussion down with war stories... > Thus those features strike me as expedients ("facades" in the > programming sense) added to make the rig's front panel interface more > convenient for the user, but don't reflect essential reality. They > can reproduced on a client as desired without reproducing all the > vendor-specific details end-to-end. > > The essential, for each transmitter for example, is to set-and-get a > frequency, a modulation mode/modem, a power level and... well, those > are the ones that spring immediately to mind. Receivers are more > complicated (as usual) but again, the essentials for each receiver are > relatively limited in number. Given those essential parameters in the > protocol and a computer at the other end we could construct as > sophisticated or as simple a UI as any particular user needs. Thus > the same rig might look very different to a contester than to a MARS > op. > > At the other extreme... many higher-end rigs and SDRs can display a > spectrograph, which visualizes energy levels in intervals across a > segment of the spectrum. Do any of the existing CAT interfaces make > that vector of values available outside the rig? This may be an area > where we'll need to innovate, not to say lead. Not that I have seen, but I have not done an exhaustive review of all of the commands available. The few that I am aware of treat the control channel as separate from the information channel but this too is bound to change at some point. 73, de Nate >> -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |