Re: [Hamlib-stationserver] [with attachment] A very preliminary requirements draft for discussion

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

On 4/03/2014 8:42 AM, Art Botterell wrote:
> Thanks.  We should probably pause briefly to see who accretes to the list... but in the meantime, I'd very much appreciate some help in the Background section.
>
> Without being hypercritical I'm thinking it might be useful to highlight some of the things we'd like to improve over the status quo, and that's really not my area of expertise.
Just took a quick look at the draft.  I think we're better off kicking 
it around in here before creating a document, but thanks for the stab at it.

For me, the status quo has a number of limitations:

1.  Most solutions are single platform and proprietary (Hamlib is an 
exception).

2.  There are no solutions that allow for the sharing of a radio between 
multiple applications.

3.  Because of #2, there is no API for requesting exclusive control of 
the radio and releasing it.

4.  No integration between remote base software radio control, meaning 
you can't share a remote base with local control - see #2 and #3 above 
(as well as making it easier to use your own radio, could also be a 
useful training and PR tool).

What I would like to see:

Having a networking background, I tend to think in layers, and this 
model is relevant here.

Layer 1 - Physical.  This is where the actual radio control takes 
place.  Here we define the ports and soundcard resources used, as well 
as the control protocol between the radio and server.  The physical 
layer should be defined by a "driver", which requires no code (should be 
a list of definitions that a relative non programmer can change or 
write) in a standardised format.  A tool could be written to help users 
and radio tinkerers to create their own driver files.  I'm thinking 
something like RigCAT XML files in concept (but use what is best).  The 
ability to use Hamlib drivers would also be useful to help facilitate 
rapid adoption, since many Hamlib drivers are fully functional.  Similar 
can be done for rotator control.

Layer 2 - server/abstraction.  Here the specific commands sets of the 
radios and rotators are abstracted into a generalised API.  The server 
knows (from the drivers) the capabilities of each device and is 
configured with the resources (serial/audio/network/etc) that each one 
uses.  The API is the means by which client software communicated to the 
radio(s) and rotator(s).  Space should be made in the API for other 
devices (amplifiers, remotely controlled switches, etc).  The API is 
also network aware, has minimal latency and only needs moderate 
security.  This API should NOT be used outside of a controlled 
environment such as a single machine or a LAN.  Given that it is now 
2014, the radio control API should work over both IPv4 and IPv6.  Also 
at this level comes the ability to request exclusive use of one or more 
resources, so other software accessing that resource can't inadvertently 
change settings such as VFO or mode, or rotate the antenna at an 
inappropriate time.

Layer 3 - Additional functionality.  Here we "bolt on" additional 
functionality that is not part of the core control system.  This 
additional functionality would be implemented in additional (possibly 
and most likely third party) modules which communicate with the server 
via the API.  Examples of add-on modules would include:

- Remote base.  This provides the functionality we are now familiar with 
to share your radios over the Internet.  The remote base module would 
incorporate the functions specifically needed for remote base operation, 
such as enhanced security, user authentication and validation, audio 
compression, etc.  Astute readers will notice that the remote base can 
be overridden by local access controls at the server level, in case you 
want to use your radio for something which keeping the remote base 
active (e.g. for remote listeners), but prevent it from changing any 
settings.

- Data transmission.  Modules for popular data modes could be linked to 
the server to perform the modularion and demodulation, and exchange 
baseband data and optional diagnostic information (S/N, summarised 
waterfall, etc) with a compatible data client.  Want to run PSK-31 
without a soundcard (on the client)? :)  This would potentially reduce 
the bandwidth used by data modes, especially for remote bases.

- Digital voice, D-STAR and other modes.  Modes such as D-STAR, FreeDV 
and others could be implemented as modules and effectively add to the 
command set of radios which have the appropriate capabilities (e.g. 9600 
bps capability for D-STAR).  Of course, a D-STAR module would need a 
DV-RPTR AMBE board or a DV Dongle.  The DV Dongle could be positioned at 
the server end (for sharing among multiple clients) or at the client end 
(for saving network bandwidth).  This type of add-on would effectively 
add extra mode buttons to your radios, with the magic happening behind 
the scenes. DV modules also may need to set certain radio parameters 
such as mode and 9600 bps.

- Legacy radio emulation.  It's going to take a while for developers of 
radio control software to adopt the server API.  Radio emulation 
presents a traditional (virtual) serial and soundcard interface, using a 
well known radio command set (e.g. late model Kenwood).  It may be 
possible to use existing virtual device emulators (e.g. VSPE and Virtual 
Audio Cable in the case of Windows, etc) for the sound and serial 
support, which would save development of these parts. The radio emulator 
would ideally be network aware (since it uses a network aware API), so 
it wouldn't need to reside on the same box as the server, which would 
make old client software instantly network capable.  A Hamlib module 
could also be developed to enable Hamlib capable applications to 
directly access the server API without having to go through serial port 
emulation.

- Infrastructure linking - This sort of module is related to the remote 
base module, and would allow the server to be linked to and controlled 
by other radio networks - e.g. IRLP, Echolink, D-STAR, etc.  For 
example, creating an IRLP remote base, which would require the module to 
interface with an IRLP node for audio and accept commands generated by 
scripts for the control side.  An Echolink remote base could accept 
commands via a text window.  The infrastructure linking could be 
delevoped in conjunction with other open source projects such as 
thelinkbox (but not share code, otherwise you'll end up being GPL, which 
we don't want at this stage).

Anyway, that's a few of my thoughts.  Ad this stage a wish list, but 
hopefully to give some idea.  For priorities, I'd say that layers 1 and 
2 are the priorities, as well as the radio emulator, as these are the 
things needed to make the system work, as well as encourage users of 
existing software to adopt the system.

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