Re: [Hamlib-stationserver] Terminology

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

On 24/03/2014 1:42 PM, Nate Bargmann wrote:
> 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.
Arrrgh house moving - fun...  NOT! :)

> 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!).
So, we're basically down to two main command sets (with dialects) - Icom 
and Kenwood, at least for current models?
> 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.
There is a good argument to support the use of Hamlib backends. This 
would be useful for 2 reasons:

1.  Allows development to focus on areas other than specifics of rig 
support - the end result would be useable, while the native backend 
definitions are still being written.

2.  Allows support of older models for which a new style backend may 
never be written (but have Hamlib support today).  I'm thinking of 
radios like my FT-736R.
>
> 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 >>
>


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