[Hamlib-developer] Re: Kenwood backend, etc

[Francois R. <fgr...@su...>]

Hello Stephane

Stephane Fillod wrote:
> 
> Great! We'll have to add the new callbacks to the frontend.
> However, if I remember well, the "AI" command does not send what has changed
> but the complete status of the rig right after the event happened.
> Is it what you noticed on the THD7?
> So the backend would have to remember the previous state, and from the delta,
> find and call only the appropriate callbacks. Is it worth the trouble?

The AI command is only used the switch transceive mode on or off.  
The actual async events is exactly the same as normal commands, 
ie. When the band A/B button is pressed, an 'BC 0' or 'BC 1' is sent,
or when a signal measurement is given, 'SM 0,03', etc.

But when a frequency changed, the complete vfo status is sent, ie
'BUF 0,00145830000,0,0,0,0,,05,,03,00060000,0' which include among
others include the Frequency, VFO, Mode, Split, Tone, CTCSS and 
a few more.  At the moment I only generate an callback event for 
the VFO, Frequency and Mode. The other data is currently ignored.

Do we include an callback for all possible async events? I counted 
almost 30 events that can be send async.  I was thinking of adding
callbacks for the most popular/useful/frequently used events,
ie. Frequency, signal strength, VFO, etc.  and a general purpose
callback that handle all the rest/unhandled events.

Thus a GUI app can hook into the frequency callback for fast 
display updates and hook into a general-purpose callback that signal
stuff like keyboard-lock, lamp on/off, etc.  I think Hamlib should 
not store the state of the radio. It should serve as a control
instrument and an event notifier.

> > I created an account today. login name: fgretief
> > Once created I'll commit my latest changes.
> 
> okay, you're in. happy hacking!
> There's no written down rules, just common sense. Adding stuff is no problem.
> Just ask for discussion on the list if you plan to do major or heavy
> changes on the API/frontend.

Thanks.

> > I have been playing with a Hamlib binding for Borland's Kylix.
> > Should I contribute it to Hamlib?
> 
> Oh yes, sure! please! We have already c++, tcl, and I can see perl
> and python bindings which stand out in the horizon.
> You can create a separate directory, much like c++ and tcl, coming along
> with a simple sample program illustrating the new binding. This will give
> others (starting from me :) envy and a quick start in Borland's Kylix.

Will do.

 
Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za