Re: [Hamlib-stationserver] Philosophy: Abstraction vs Rig Interface Artifacts

[Tony L. <vk...@gm...>]

On 5/03/2014 8:35 AM, 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.)
I agree.  The capabilities need to be discovered.  The driver (with 
maybe some manual configuration in some places) needs to be able to tell 
the server what the radio can do.  A "radio" could be modelled as an 
entity with a transmitter (might need to allow for more, though I am not 
aware of a currently available radios with more than one transmitter) 
and one or more receivers (most will have one, HPSDR being one of the 
few exceptions).
>
> 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. *
Those features are peripheral.  Issues such as memories for instance are 
more a "convenience" thing.  Here you run into some proprietary 
oddities.  For example, the IC-7000 has 5 banks of 99 memories, though 
this could be mapped into a "flat" space (1-499), with 4 unprogrammable 
gaps (virtual memories 100, 200, 300 and 400), by the abstraction.

So what is a "radio"?  It's an entity that contains:

0 or more transmitters (some receivers are controllable). Currently, 
only the cases of 0 or 1 transmitters exist in the wild.

0 or more receivers (I am not aware of any transmit only controllable 
radios, but 1-7 receivers are availavle today).

The case of 0/0 might seem useless, but could be a "dummy" driver to 
allow testing.

Radios will have a number of properties:

1 or more "modes" - AM, FM, USB, LSB, CW, etc...

One or more receive frequency ranges.  Can be a single frequency (e.g. a 
repeater receiver).

One or more transmit frequency ranges.  Again, can be a single frequency 
(e.g. for a beacon or repeater transmitter).

A feature list - Here we specify what inbuilt features the radio has, 
and how these features are mapped to the virtual radio model in the 
server.  Examples of features include VFOs, filters, RIT/XIT, repeater 
offsets, noise reduction, noise blanker, RF gain, audio gain, ATU, 
memories, etc.  Also in here I would put a full duplex flag.  The radio 
server should be inherently full duplex, but know whether it's connected 
to a full duplex capable radio.  Duplex may be conditional (e.g. some 
radios are only duplex when in satellite mode, others can go duplex 
whenever configured to transmit and receive on different bands, some are 
inherently full duplex - e.g. a repeater).  The feature list in this 
context is basically what the radio can be made to do by commands, and 
may or may not be how the functionality is implemented by the radio 
server/driver combination.

A resource list - This is the list of resources (COM ports, soundcards, 
etc) used to communicate with the radio and the settings of those 
resources (baud rate, data format - data bits, stop bits, parity, audio 
gain settings).

A protocol - this is the definition of the command set used by the radio 
to access its features.  This can be as simple as toggling RTS or DTR 
for PTT in the case of a fixed frequency transceiver, or it can (usually 
will be) a full blown command set.  This would have to be some sort of 
capabilities table and would be linked to the feature set.

The combination of feature list and protocol would have an impact on how 
the virtual radio in the server and the real radio interact. For 
example, with my 2 main radios, the FT-736R has a very limited CAT 
capability (e.g. you can't read the VFO frequency), so the virtual radio 
needs to maintain the radio state and send it to the real radio as 
necessary.  My IC-7000, OTOH, is capable of sending its state back to 
the PC, so the virtual radio has to be able to read that state 
information and update its own state if the radio changes (e.g. I turn 
the VFO, change bands, mode, filter settings, etc manually from the 
front panel).

I'm sure you programmer types can tidy this up a bit. :)
>
> 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.
Spectrographs are also going to be something that need to be handled 
when considering encoding data modes as data rather than audio (waaaay 
off in the future). :)
>
> - Art
>
> * (I'm neglecting spread-spectrum and other broadband modes for the moment, but it might be more precise to say "one channel at a time.")
Yep.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com