Re: [Hamlib-developer] Kenwood AI command?

[Chuck H. <n2...@am...>]

On Thu, 19 Feb 2009 18:59:21 +0100
Stephane Fillod <f8...@fr...> wrote:

> Hi Rob,
> 
> Rob Frohne skribis:
> > In instances where the computer needs to know when things have changed  
> > in the rig, it would be nice to have the rig just tell the computer when  
> > that has happened.  Kenwood has a method of doing that with the AI  
> > command.  I don't see any implementation of this feature in hamlib, but  
> > it would eliminate some of the kludgy polling that is going on  
> > presently.  Is there a nice way to include this kind of feature in 
> > hamlib?
> 
> There's already such a feature in Hamlib. It is called "transceive mode",
> or "trn" for short. It comes after the Icom so-called mode, where the rig
> sends change notifications to the host. You can play with it in rigctl
> using the command 'A: set_trn'. Any change should be reported to
> the terminal, provided your rig/backend has appropriate support.
> Basically, the application should register callbacks through
> rig_set_{vfo,freq,mode,ptt,dcd}_callback() beforehand. Then, rig_set_trn
> will enable SIGIO processing upon serial tty activity, and make the
> backend send the enable command (AI for Kenwood). Upon activity,
> the sighandler of SIGIO will call the backend's caps->decode_event
> for appropriate processing, and callback calling. See src/event.c
> and tests/rigctl_parse.c for more info.
> 
> This looks nice on the paper, but when implemented, you run into plenty
> of troubles. Some events may be missed because the rig does not send
> the notification. Sometimes the notification happens just in the middle
> of a query. The protocol parsing gets tricky. The SIGIO is not very
> portable platform-wise. An emulation of notification was also made through
> RIG_TRN_POLL and timers, but in the end, it is just simpler and more robust
> for the application to handle the polling in an explicit manner. On top
> of that, the I/O latency bothers most of GUI framework, hence the
> need of explicit handling.
> The trn code used to work couple of years ago (at least on Icom's),
> I don't know whether some people are still using it now, and whether
> it still works. You will probably tell us.

I worked on implementing it a while ago for a Kenwood TS-790 but
haven't had a chance to submit my changes back to the cvs.  I also
haven't used it since because I ran into a few problems with way it was
implemented in the firmware in the rig:

1. The radio would only check for changes every so often (~5-10 secs???)
2. It wouldn't send out any changes while you were spinning the knob.
3. It would many times totally miss things like:
     hit main/sub to switch vfo
     spin the knob
     hit main/sub to switch back

It seemed to me that it was implemented in the firmware by a low
priority polling process and I could get better results doing my own
polling. Since I was doing satellite doppler corrections every few
seconds, it wasn't going to work for me.

Contrasting that with the Icom R7000 (the old receiver, not the new
transceiver), that would spew updates out the serial port as you were
spinning the wheel.

If your still interested, let me know and I'll dig up my code.