ok, let me clear the elephant in the room, no I ain't sniffing anything...  other then in my coding...

The goal of this email is to open a discussion about how to reach CI-V information on a CI-V bus like the CT17Bs to use this information within your projects...

there are basically two ways of getting information from your radios for your applications or your hardware projects...

PULL: 

Pulling information from a CI-V based radio is done for most applications like HRD, Logger32, etc... but also by OEM hardware and many of our Hardware projects.

When you use a PULL method you are basically sending commands to the radio via your CI-V bus or USB port to get specific information like frequency, band, volume settings, voltage, etc...  the more advanced the application the more PULLing it will do.

PROs;
- Accurate
- Low latency
- Great in a 1 to 1 environment.

CONs;
- High usage of the CI-V Bus
- Pron to collision in multiple device environment

you see...  The reason why it is so low latency, is because most hardware or Application that use this will be polling, and the better ones with very latency like HRD use a LOT of polling...  and I mean a LOT!

that is why this is highly pron to collisions if in a multiple device environment... Works great in a 1 to 1 environment.

SNIFF:

Sniffing is simple, if you have a multiple devices/Application environment on your CI-V bus, like Radio, HRD, Steppir, etc...  for example then if both HRD and the Steppir SDA100 are PULLING data from the radio there WILL be collisions and thus problems...

And if you don't have any application and are in a 1 to 1 environment then you MUST turn one CI-V transceive, CI-V transceive will make the radio send CI-V data on whatever is changed on the radio so that the SNIFFing device can get the info.

Mind you a lot of applications like to have CI-V transceive ON so that they can drop their latency even lower...  and this even if they are running PULL.

PROs; 
- Low collision (None!)
- Accurate as long as CI-V Tranceive is ON.

CONs;
- Latency issues can be a problem.
- Must have Transceive ON, well in a single CI-V bus with multiple radios, this will cause ALLL radios to change info at the same time and you may not want that!

Hey, I probably forgot something important! would be interested to hear from you and your experience with this...  Join in!

--

Collisions are a normal part of the CI-V bus protocol, just as they are a normal part of the Ethernet protocol. All Icom transceivers with CI-V bus support include the logic require to detect and reject collision-damaged messages. Only the Icom PW-1 amplifier lacks this capability, and thus requires a "private" CI-V bus on which collisions cannot occur; this is a blatant defect in the PW-1 design.

An application that interacts with a CI-V bus must include collision detection or collision prevention even when the only nodes on the bus are the application a single transceiver: if the application sends CI-V commands too quickly, the transceiver's response to command N can collide with the application's command N+1.

One can attempt to prevent this from happening by never sending command N+1 until the response to command N has been received. But what happens if the response to command N is never received, perhaps because command N was damaged by RFI and thus ignored by the transceiver? How long should the application wait for a response before giving up and retransmitting the outgoing command? And if the transceiver finally sends its response just when the application has given up and is re-sending the command, there will be a collision.

Enabling a transceiver's "CI-V transceive" option to increase responsiveness to transceiver state changes will greatly increase the likelihood of collisions.

I've been developing transceiver control software since getting my novice ticket in 1990; it's successfully employed by tens of thousands of users around the world. In my experience, the best way to handle the CI-V bus is to always implement collision detection and damaged-message rejection as described in Icom's CI-V bus specification - no matter how simple the CI-V bus topology. Polling provides the ability to pace outgoing commands at a rate that the transceiver's microprocessor can reliably handle; my IC-7800 can reliably accept a new command every 25 ms, but my IC-7300 can do so every 10 ms.

73,

Dave, AA6YQ

great Input Dave,

can you expand on collision detection...  and N+1 approach...

also what apps did you develop anything we know well...

+ AA6YQ comments below

can you expand on collision detection

+ Collision detection is described in the CI-V Manual you posted in this group's Files area:

https://groups.io/g/CIV/files/CI-V%20Reference%20Manual%20Third%20Edition.pdf

+ in two sections:

- 1-6 CSMA/CD System

- 5-4 Jammer code

also what apps did you develop anything we know well...

+ I am the developer of the freeware DXLab Suite, which is comprised of 8 applications that run independently, but can detect each other's presence and interoperate automatically. Commander is the application that performs transceiver control:

https://www.dxlabsuite.com/commander/

73,

Dave, AA6YQ

I would have to lie to say I never heard of DXLab almost every hams on HF have ! ;P I am very happy to have you in our group... You are a reference for us...

I hope my dumb post don’t make you laugh to much! ;P trying to start exchanges... Glad you jumped in a couple of times...

please feel free to start or as you did here expand on our exchanges, as you know what we are trying to do here is to have share and answer questions on CI-V.

thanks for the references, yes I was aware of the fact that Ethernet is another protocol dealing with collision.

(Note to self... Stop using HRD in your examples and use DXLab instead... you dumbass! ;P )

Hi, I most frequently use polling ( “pull” ) as it is easier to process the reply data because the expected reply message ( arriving about 20ms later ) is known.   I have included qite a bit of TX and RX message checking in my code, including collision and corruption checking, but could do more, especially when considering scenarios where multiple devices are on the One Wire Bus.  I have tried “Sniffing” too, but that was in a prototype CI-V / ethernet Bridge which attempted to “catch all” and pass them via ethernet to a reciprocal device .  demo of latter :   https://youtu.be/N0np3d6_tgw

Very nice
--