¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Commander - Disable interrogation doesnt ¡°stick¡±


 

Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because of documented/captured CIV bus collisions that the flex amp/tuner cannot handle, thats another story). ? If i dont, the flex (not so genius) amp and tuner randomly change frequencies if slaving to the civ when collisions occur (long story, for another tread).

But when i goto commander¡¯s config, and uncheck the interrogation box, it doesnt seem to save that configuration artifact when i close the appl and i have to again disable it every time.

anyone else notice this? ? I¡¯d like to have it save it and restore that setting like all (or most) the other settings.


 

Do you have more than one radio defined or a radio
defined on the MultiRadio tab? If so, uncheck interrogation
there.

Do you have a workspace defined and loaded on start-up? If
so, uncheck interrogation on both the General and MultiRadio
tabs, close all applications except Launcher and update your
workspace.

73,

... Joe, W4TV

On 6/16/2024 11:41 AM, bob-w9zv wrote:
Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because of documented/captured CIV bus collisions that the flex amp/tuner cannot handle, thats another story). ? If i dont, the flex (not so genius) amp and tuner randomly change frequencies if slaving to the civ when collisions occur (long story, for another tread).
But when i goto commander¡¯s config, and uncheck the interrogation box, it doesnt seem to save that configuration artifact when i close the appl and i have to again disable it every time.
anyone else notice this? ? I¡¯d like to have it save it and restore that setting like all (or most) the other settings.


 

+ AA6YQ comments below
Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because of documented/captured CIV bus collisions that the flex amp/tuner cannot handle, thats another story). ? If i dont, the flex (not so genius) amp and tuner randomly change frequencies if slaving to the civ when collisions occur (long story, for another tread).

But when i goto commander¡¯s config, and uncheck the interrogation box, it doesnt seem to save that configuration artifact when i close the appl and i have to again disable it every time.

anyone else notice this? ? I¡¯d like to have it save it and restore that setting like all (or most) the other settings.

+ Commander's Interrogation option is intentionally enabled at startup because control of most radios requires it. For example, Commander can't track the state of your IC-7610's receive filtering with Interrogation disabled; it also can't track S-meter and transmit meter readings. The ability to temporarily disable Interrogation is provided for diagnostic purposes.

+ Any device that connects to an Icom CI-V bus must be able to properly handle collisions, as specified in the CI-V bus specification. The CI-V bus uses the same technique as does the Ethernet physical layer protocol; collisions should not cause errors!

+ The designers of Icom's PW-1 amplifier assumed that the amplifier would be directly connected to the transceiver's CI-V port with no other CI-V devices present to cause collisions, and so omitted the (trivial) collision detection logic. When ops began using connecting their PCs to the CI-V bus to enable the use of transceiver control applications (like Commander), the resulting collisions let the smoke out of many a PW-1. Larry K8UT carefully studied this phenomenon, and documented his findings in a paper entitled? "Riding the CI-V Bus", which is available here:

+ Commander's Secondary CAT port can be configure to provide a collision free CI-V bus for the PW-1 amplifier. I don't know that this will satisfy your Flex amplifier and tuner, but you might give it a try. See

+ From a source code review (but not a hand-on test), the technique that Joe W4TV suggested -- configure Commander to use MultiRadio support and disable Interrogation on the Configuration window's MultiRadio tab -- should work. However, running with Interrogation disabled will result in a loss of functionality, as noted above. Using Commander's Secondary CAT port would be the best solution, if it keeps your amplifier and tuner happy.

? ? ? ?73,

? ? ? ? ? ? ?Dave, AA6YQ

?

?


 

Hi Dave/Joe,
apologies for the delayed response, fathers day/holiday got in the way.

My comments #### below


On Sun, Jun 16, 2024 at 01:25 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because of documented/captured CIV bus collisions that the flex amp/tuner cannot handle, thats another story). ? If i dont, the flex (not so genius) amp and tuner randomly change frequencies if slaving to the civ when collisions occur (long story, for another thread).

But when i goto commander¡¯s config, and uncheck the interrogation box, it doesnt seem to save that configuration artifact when i close the appl and i have to again disable it every time.

anyone else notice this? ? I¡¯d like to have it save it and restore that setting like all (or most) the other settings.

+ Commander's Interrogation option is intentionally enabled at startup because control of most radios requires it. For example, Commander can't track the state of your IC-7610's receive filtering with Interrogation disabled; it also can't track S-meter and transmit meter readings. The ability to temporarily disable Interrogation is provided for diagnostic purposes.

#### yes i am very aware of this, i also have transcieve disabled for another reason, which can make the radio data stale as well (for speeds above 19.2, unlinking them) .? ?this is the reason i was posting the specific query if this is supposed to "stick" or not.? i didnt want this to turn into a general discussion of CI-V/collisions etc.? ?that is why i said "thats another story" and "long story for another thread".? ?

+ Any device that connects to an Icom CI-V bus must be able to properly handle collisions, as specified in the CI-V bus specification. The CI-V bus uses the same technique as does the Ethernet physical layer protocol; collisions should not cause errors!

#### this is the problem,? and like the PW-1, the not so genious tuner/amp simply doesnt handle collisions (or the collision JAM 0xFC 0xFC FCFCFCFC signaling) well at all.? ?both constantly poll the CI-V interface for freq info asynchronously causing collisions and the parser on the PG/TG isnt savvy enough to toss them out, and they BOTH erronously decode a momentary random freq change until the the next reply from the radio.? since they are constantly polling, if the only thing the parser did was vote for agreement on two successive frequency queries i bet it would eliminate the problem.?
?
to some extent i have relieved the CI-V bus from TGXL polling via slaving it off the PGXL (a recent software update) LAN.? However, that still doesnt totally eliminate the issue, as if the PGXL gets a bogus momentary freq decode,? the TG follows it from the LAN.? ?But i reduces collisions by a lot.?
?

+ The designers of Icom's PW-1 amplifier assumed that the amplifier would be directly connected to the transceiver's CI-V port with no other CI-V devices present to cause collisions, and so omitted the (trivial) collision detection logic. When ops began using connecting their PCs to the CI-V bus to enable the use of transceiver control applications (like Commander), the resulting collisions let the smoke out of many a PW-1. Larry K8UT carefully studied this phenomenon, and documented his findings in a paper entitled? "Riding the CI-V Bus", which is available here:

#### have read this long ago, and should be considered a "must read" by anyone using the CI-V bus.?
Like you said, the old ethernet vampire tap coax bus handled collisions -? this should be able to as well.? ? Seems other stuff i have had on the CI-V bus has handled collisions and the JAM code fine by not momentarily "jumping" to bogus frequencies.? But not so on the "not so genius" tuner/amp.? ? again, if it wants to constantly poll, possibly just a vote to have multiple successive replies from the radio agree on the same frequency (knowing the polling interval) before accepting it would work well (along with other hardening).? ?i see only that it would delay a valid frequency update on the PG/TG by the additional time it would take to vote on multiple replies, which shouldnt be an issue in most cases since its done so frequently.?
?

+ Commander's Secondary CAT port can be configure to provide a collision free CI-V bus for the PW-1 amplifier. I don't know that this will satisfy your Flex amplifier and tuner, but you might give it a try. See

#### i will have to take a look at this... but the only thing i have on the ICOM's CI-V now is the PGXL and Commander.
I use N1MM as general logging, pitching to DXLab via DXKeeper Gateway as my "log of record" and to monitor DXCC etc.? ?ICOM radio is connected to the USB com ports to N1MM, while the TG/PG is connected via ICOM CI-V jack.? ?But to have DXC push the radio to a DX spot, i have it connected to the CI-V.?

I also have MicroKeyerII in the mix, which is currently disconnected from the CI-V because it pummels the bus with similar interrogations generating collisions and making the PG/TG useless because nearly constant bogus frequency changes occurring many times/minute.? ?

Further, i dont want to alway have to have DXLabs/computer up to use radio/amp/tuner.?

If the PG/TG CI-V interface/parser was hardened, i could use other configurations as this is not my preferred one.

I have craploads of capture files showing all the interactions/collisions etc.? now i now more about the ICOM command set than i ever wanted to !? ?I do that via a VE2DX CI-V bus CT-17B-6USB, which i connect to a term-emulator to monitor on the USB serial port presented (which is quite nice to have).?

+ From a source code review (but not a hand-on test), the technique that Joe W4TV suggested -- configure Commander to use MultiRadio support and disable Interrogation on the Configuration window's MultiRadio tab -- should work. However, running with Interrogation disabled will result in a loss of functionality, as noted above. Using Commander's Secondary CAT port would be the best solution, if it keeps your amplifier and tuner happy.

? ? ? ?73,

? ? ? ? Dave, AA6YQ


#### tnx dave/Joe... I may play with this next week.? ?Any other thoughts welcome.?
?i really think i need to work with Flex to find some way of getting them to harden their CI-V interface as this is really the solution ultimately.? not eveyone wants or will buy a PG/TG for use only on a flex.? Flex recognizes that by providing the interface to capture that market buckage opportunity.? ?But at this caliber of equipment in 2024, it needs hardening in the real-world and better is expected.? As it is, it seems totally intolerant of any of this, again, randomly changing frequencies (and all the relay chugging that goes along with it) far too frequently if absolutely anything is on the CI-V bus or if a CAT change (on the USB) is echoed out to the CI-V from another appl.? ?

apologies for the tome.? ?thanks to a once thought of as "useless" typing class in high-school, i can easily pound it out !


 

+ AA6YQ comments below
?i really think i need to work with Flex to find some way of getting them to harden their CI-V interface as this is really the solution ultimately.

+ It's not a question of "hardening", it's a question of correcting an egregious defect caused by failing to fully implement the CI-V specification.

? ? 73,

? ? ? ? ? Dave, AA6YQ


 

I also have MicroKeyerII in the mix, which is currently disconnected from the CI-V because it pummels the bus with similar interrogations generating collisions and making the PG/TG useless because nearly constant bogus frequency changes occurring many times/minute.
If that's the case, why don't you connect PG/TG to the MK II Aux CI-V
output? The Aux CIV is isolated and emulates the Icom "Transceive"
data with no collisions.

Use MK II to the transceiver's CI-V output and allow Commander to
access the transceiver via Router's CAT port. N1MM can use the
Icom USB port, you can enable/disable Commander as needed and the
MK II will automatically provide the transceiver TX Frequency,
RX Frequency, Operating Frequency, VFO A Freq or VFO B Freq depending
on which you select in Router's "System Settings" CI-V port settings.

As long as you set the 7610 as documented in microHAM's Support
recommendations, each of the three (USB, CI-V and Aux CI-V) should
be fully decoupled.

73,

... Joe, W4TV


On 6/23/2024 4:29 PM, bob-w9zv wrote:
Hi Dave/Joe,
apologies for the delayed response, fathers day/holiday got in the way.
My comments #### below
On Sun, Jun 16, 2024 at 01:25 PM, Dave AA6YQ wrote:


+ AA6YQ comments below

Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because
of documented/captured CIV bus collisions that the flex amp/tuner cannot
handle, thats another story). ? If i dont, the flex (not so genius) amp
and tuner randomly change frequencies if slaving to the civ when
collisions occur (long story, for another thread).

But when i goto commander¡¯s config, and uncheck the interrogation box, it
doesnt seem to save that configuration artifact when i close the appl and
i have to again disable it every time.

anyone else notice this? ? I¡¯d like to have it save it and restore that
setting like all (or most) the other settings.


+ Commander's Interrogation option is intentionally enabled at startup
because control of most radios requires it. For example, Commander can't
track the state of your IC-7610's receive filtering with Interrogation
disabled; it also can't track S-meter and transmit meter readings. The
ability to temporarily disable Interrogation is provided for diagnostic
purposes.

#### yes i am very aware of this, i also have transcieve disabled for another reason, which can make the radio data stale as well (for speeds above 19.2, unlinking them) .? ?this is the reason i was posting the specific query if this is supposed to "stick" or not.? i didnt want this to turn into a general discussion of CI-V/collisions etc.? ?that is why i said "thats another story" and "long story for another thread".




+ Any device that connects to an Icom CI-V bus must be able to properly
handle collisions, as specified in the CI-V bus specification. The CI-V
bus uses the same technique as does the Ethernet physical layer protocol;
collisions should not cause errors!

#### this is the problem,? and like the PW-1, the not so genious tuner/amp simply doesnt handle collisions (or the collision JAM 0xFC 0xFC FCFCFCFC signaling) well at all.? ?both constantly poll the CI-V interface for freq info asynchronously causing collisions and the parser on the PG/TG isnt savvy enough to toss them out, and they BOTH erronously decode a momentary random freq change until the the next reply from the radio.? since they are constantly polling, if the only thing the parser did was vote for agreement on two successive frequency queries i bet it would eliminate the problem.
to some extent i have relieved the CI-V bus from TGXL polling via slaving it off the PGXL (a recent software update) LAN.? However, that still doesnt totally eliminate the issue, as if the PGXL gets a bogus momentary freq decode,? the TG follows it from the LAN.? ?But i reduces collisions by a lot.




+ The designers of Icom's PW-1 amplifier assumed that the amplifier would
be directly connected to the transceiver's CI-V port with no other CI-V
devices present to cause collisions, and so omitted the (trivial)
collision detection logic. When ops began using connecting their PCs to
the CI-V bus to enable the use of transceiver control applications (like
Commander), the resulting collisions let the smoke out of many a PW-1.
Larry K8UT carefully studied this phenomenon, and documented his findings
in a paper entitled? "Riding the CI-V Bus", which is available here:






#### have read this long ago, and should be considered a "must read" by anyone using the CI-V bus.
Like you said, the old ethernet vampire tap coax bus handled collisions -? this should be able to as well.? ? Seems other stuff i have had on the CI-V bus has handled collisions and the JAM code fine by not momentarily "jumping" to bogus frequencies.? But not so on the "not so genius" tuner/amp.? ? again, if it wants to constantly poll, possibly just a vote to have multiple successive replies from the radio agree on the same frequency (knowing the polling interval) before accepting it would work well (along with other hardening).? ?i see only that it would delay a valid frequency update on the PG/TG by the additional time it would take to vote on multiple replies, which shouldnt be an issue in most cases since its done so frequently.




+ Commander's Secondary CAT port can be configure to provide a collision
free CI-V bus for the PW-1 amplifier. I don't know that this will satisfy
your Flex amplifier and tuner, but you might give it a try. See





#### i will have to take a look at this... but the only thing i have on the ICOM's CI-V now is the PGXL and Commander.
I use N1MM as general logging, pitching to DXLab via DXKeeper Gateway as my "log of record" and to monitor DXCC etc.? ?ICOM radio is connected to the USB com ports to N1MM, while the TG/PG is connected via ICOM CI-V jack.? ?But to have DXC push the radio to a DX spot, i have it connected to the CI-V.
I also have MicroKeyerII in the mix, which is currently disconnected from the CI-V because it pummels the bus with similar interrogations generating collisions and making the PG/TG useless because nearly constant bogus frequency changes occurring many times/minute.
Further, i dont want to alway have to have DXLabs/computer up to use radio/amp/tuner.
If the PG/TG CI-V interface/parser was hardened, i could use other configurations as this is not my preferred one.
I have craploads of capture files showing all the interactions/collisions etc.? now i now more about the ICOM command set than i ever wanted to !? ?I do that via a VE2DX CI-V bus CT-17B-6USB, which i connect to a term-emulator to monitor on the USB serial port presented (which is quite nice to have).




+ From a source code review (but not a hand-on test), the technique that
Joe W4TV suggested -- configure Commander to use MultiRadio support and
disable Interrogation on the Configuration window's MultiRadio tab --
should work. However, running with Interrogation disabled will result in a
loss of functionality, as noted above. Using Commander's Secondary CAT
port would be the best solution, if it keeps your amplifier and tuner
happy.



73,




Dave, AA6YQ

#### tnx dave/Joe... I may play with this next week.? ?Any other thoughts welcome.
i really think i need to work with Flex to find some way of getting them to harden their CI-V interface as this is really the solution ultimately.? not eveyone wants or will buy a PG/TG for use only on a flex.? Flex recognizes that by providing the interface to capture that market buckage opportunity.? ?But at this caliber of equipment in 2024, it needs hardening in the real-world and better is expected.? As it is, it seems totally intolerant of any of this, again, randomly changing frequencies (and all the relay chugging that goes along with it) far too frequently if absolutely anything is on the CI-V bus or if a CAT change (on the USB) is echoed out to the CI-V from another appl.
apologies for the tome.? ?thanks to a once thought of as "useless" typing class in high-school, i can easily pound it out !