Re: [Hamlib-developer] Icom CI-V Trancieve issue...
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Stephane F. <f4...@fr...> - 2001-02-05 07:48:07
|
David HM Spector wrote: > > Here's an interesting issue (and potential problem): > very interesting indeed. and a limitation of the CI-V protocol on Icoms :( > The CI-V trancieve mode setting is defined in the manuals for my > 756PRO and R-8500 to be a mode that will change the operating > frequency of all Icom radios connected to the CI-V bus if one of them > is changed; however the trancieve function is mentioned in rig.h as: > > "tranceive mode, ie. the rig notify the host of any event,like freq > changed, mode changed, etc." > well, the rig.h comment is referring to event notification (ie. not only Icom mode) > Having had trancieve mode turned on on both these rigs connected to > the same bus, I can vouche for the fact that it will indeed cause > freq/modes to change in all rigs connected if you change the freq/mode > on one of them. > There must be a solution using a couple of components on a PCB. I'm thinking of diodes isolating rigs when they are transmitting (ie. the Host is not Transmitting). Could it be feasible with async comm ? (I'm not an expert in electronics) > Perhaps there needs to be a polling API defined (I don't know if this > is an Icom specific "feature") that will allow things like GUIs get > the state of a rig rather than depend upon the tranceive mode which > clearly doesn't do what one needs here... > Funny enough, there's a RIG_TRN_POLL constant defined recently in rig.h. Actualy, I was thinking of implementing this feature at the frontend level, since some rigs are not able to do this (Yaesu, Kenwood, ..). Please note that some Icoms do not support notification for all possible events. Thus emulation would be interesting. One last thought on the subject. This feature is a must for GUIs. Hamlib developers COULD decide to not implement it in their library and let the GUI's developer struggle with it. IMO, this is not a good approach. Since Hamlib aims to standardize radio control, event notification MUST be done in Hamlib, hiding communication details (originating from rig, or by polling). Right now, Hamlib has only proof of concept code for event notification. It works (at least with my IC706). However, it's only a hack, so let's rework(ie. rewrite) it. We have to design a nice interface for this purpose. Ideas anyone?! Cheers, -- Stephane / F4CFE |