[Hamlib-developer] Icom transceive feature and poll

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

When working on my software, I wanted to use the "transceive function" (have 
radio send a ci-v frame when the dial is changed) so I could tell if someone
was turning the dial on the radio.  

(One of the modes I wanted to support was the ability to have the user tune
the radio with the dial, stop when the user hears something interesting, and
then do doppler updates after that point (sort of like InstantTune))

I also was writing this as a network daemon using a poll loop and I didn't want
to use signals.  I couldn't find any documentation for doing this.  So after
looking through testtrn.c, and some of the other routines I came up with 
something like this:

When opening the rig, set up callback for freq event:

 rig->callbacks.freq_event = process_freq_event;

Add rig rig->state.rigport.fd to my list of fd's to poll.

And when I see input on that fd, I call:

 void check_rig_for_input(int xkey,RIG *rig)
 {
   if(!rig)
     return;
   /*
    * Do not disturb, the backend is currently receiving data
    */
   if (rig->state.hold_decode)
     return;
  
   if (rig->caps->decode_event)
     rig->caps->decode_event(rig);
 }

 int process_freq_event(RIG *xrig, vfo_t xvfo, freq_t xfreq)
 {
   int slot;
   char message_buf[1024];

   printf("Rig %p changed freq to %l Hz\n",xrig,xfreq);

   ...

   return(0);
 }

This seemed to work reasonably well, but it seemed to have a few problems:
a. It seems to me to be not as clean as it could be.
b. I'm not sure how I would handle multiple radios on the same serial/ci-v bus.
c. I'm not sure if I'm using routines that I'm not supposed be using.
d. I'm not sure if there is anywhere I can store any user data so I don't have
   to do a search to find which rig this came from. 
   Either the ability to set something that comes back as an additional
   argument to the callback routine, or a user_data pointer in RIG.
e. I'm not a big fan of callbacks (they tend to cause large numbers of global
   variables) but I'll live with them if need be.
e. There doesn't seem to be any docs for it.

Since in both network (poll) based programming and gtk (callback if input
available on fd) could use an api to be able to poll the radio I was wondering
if there was a plan?

Also was wondering if someone had played with multiple radios on a CI-V bus.
Just looking at the design of the transceive feature, it looks like if you
turn it on on a radio, it wants to both send and receive the frames and
because of this if you have two radios that can tune the same frequency, then
it automatically sets the second radio to the same frequency as the first.  It
looks like an interesting misfeature that you can't separately turn on and off
the send and receive parts.

Also just wondering what I want to do with radios that don't support this
feature.  It looks like you would have to poll the radio every so often to
see if the frequency has changed.  I was just wondering if hamlib should worry
about that, or leave that up to the calling software.

BTW When doing this, it seems that occasionally it seems that hamlib gets
confused and doesn't send out all the updates.  (it seems to keep calling
the icom_decode routine but doesn't always call the callback routine.  I haven't
had a chance to track this down further.  I don't know if this is caused by a
collision, something getting in the wrong state, or something else.