Re: [Xlog-discussion] Re: [Hamlib-developer] Hamlib, Xlog and IC725

[Stephane Fillod]

On Fri, May 02, 2003, Chuck Hemker wrote:
> I see several ways to solve this problem 
> (and they should work for most/all radios)
> 
> 1. You should be able to shut off the CI-V tranceive function in the radio by
> either a config menu item on the newer rigs or a jumper or dip switch on the
> older rigs.  I know in the IC-R7000 it's a jumper on the CPU board which to 
> get
> to you have to open the rig up and remove the top board to get to the CPU 
> board.
> I wouldn't recommend this option because on some radios it's difficult and 
> some
> people may want to run several difference software packages and some prefer 
> it.

On some rigs, it is possible to disable the transceive mode with rig_set_trn().
Unfortunately, the ICOM's are not able to switch it on/off using
protocol commands. Kenwood has a better protocol.

> 2. Support CI-V tranceive in the software.
> This will give a quicker indication of tuning knob changes to the software.
> If this is useful depends on the software
> You might also be able to either not poll or only poll if you haven't seen
> anything for a while with if you do this.

There's plan in Hamlib to "emulate" polling on rigs which don't have the
transceive ability. There's already a RIG_TRN_POLL for that purpose.
This would be implemented at the frontend level.

My idea is to implement this feature using setitimer(2). The downside is
the potential conflict with the  application about SIGALRM.
The polling frequency would be configurable. The notification would 
be the same as the transceive mode, ie. through rig_set_freq_callback et al.
Instead of setitimer, one might implement it using a dedicated thread.

> 3. Check for errors on commands and retry a few times if you get an error
> 
This is the purpose of the caps->retry field. So far, no backend has
implemented it. Maybe the icom backend has good reason to be the first
one to receive support for it.

> 4. Poll the radio often enough and ignore responses with errors
> 
> 5. Confirm sets with a read afterwords to make sure the set worked
> 
This could be implemented in Hamlib at the frontend level, with an
configuration parameter making this feature optional.
What do you all think about it?

> 6. Some combination of the above
> 
> With my software I'm working on (for doing satellite doppler correction) uses 
> a
> combination of options 2, 4, and 5.

Any chance we get a pointer one day, and maybe add a link in the
screenshot section of the Hamlib web site?

> 
> If your confused by this or need anything else feel free to ask.  I'd write
> something better but I have to leave for a hamfest in an hour or so.

Have fun!

73's
Stephane