Re: [Hamlib-stationserver] Terminology

[Nate B. <n0...@n0...>]

* On 2014 23 Mar 13:54 -0500, Art Botterell wrote:
> Greg / All -
> 
> This is where I've gotten a bit stalled... I don't think we've reached
> critical mass on this list for collecting user inputs.

No problem, I have been moving and will now start the process of getting
settled into the "new" digs, which the house I grew up in.  Mailing
lists have been a bit off of my radar lately and I have some catching up
to do.

> One way to look at this project, I suppose, would be as a matter of
> putting a network front-end on existing hamlib modules.  Not sure what
> are the status and/or shortcomings of rigctld... and I think I've seen
> reference to an XMLRPC mechanism as well.  Maybe Nate or someone else
> could help bring us up to speed on the prior art?

XMLRPC is a feature of W1HKJ's Fldigi/Flrig.  This is an RPC deamon in
Hamlib 1.2.15.3 and earlier but has been removed in the forthcoming
Hamlib 3.0.

> Meanwhile... in a scratching-my-own-itch sort of way... I've been
> noodling on the question of the most useful level(s) of abstraction.
> The existing hamlib appears to approach this at two levels... one at
> the individual "rig" level... and another at what I take it is a
> generic "virtual rig" level.  But considering the enormous variety of
> existing rig configurations... and what I assume will be a sustained
> commercial incentive toward product differentiation by adding new and
> unique features (or at least controls)...  I'm thinking this might not
> be the most sustainable model.

No argument from me!

> There does seem to be a natural demark at the level of different CAT
> interface protocols 'twixt computer and radio.  That appear to be
> structured largely by different vendors' implementations with perhaps
> some "dialects" within vendors' lines.  This again, is somewhere I
> could use some help; maybe someone with more experience in CAT
> implementations could brief us on the current landscape of CAT
> protocols?

Right now it appears that the Kenwood style command set is gaining
ground although I doubt Icom will abandon CI-V anytime soon.  The
Kenwood command strings are human readable so that is an aid in
development/troubleshooting.

While some commands are rather universal, FA; to read the frequency of
VFO A, in my experience the variance will be in the range of parameters
each model supports.  As you've noted, newer models often have
additional commands.  Other manufacturers will use Kenwood compatible
commands and add additional ones (Elecraft, for example).

Yaesu's binary CAT command set is dead for new models (hooray!).

> Above that level, though, the practical definition of "rig" seems to
> be "a collection of features flying in loose formation."

Nice DC3 reference.  ;-)

> The
> functionality of a "rig" may be defined not just by a particular box,
> but also by its interconnections with other devices.  Thus, if the
> functionality of a control interface isn't to be restricted to
> predictable "generic" functions, we need a way to discover which
> functions are on offer from a particular server instance.

This is a bit of a duplication of the usual Hamlib backend.  Much useful
information is stored there and a good part of it is reasonably
debugged.

The tricky part is dealing with differences in a radio's firmware.
Where this cannot be determined reliably, we have resorted to separate
backend models.  I think the IC-756 series is broken out in a manner
such as this.  At least that would be my advice to a Hamlib contributor
looking at different firmware revisions that would force backend
functions to be supported in a different manner.

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