pls send me email ve2dx at hotmail
--

7610, 9700

Hello Richard

great list, please send me an email ve2dx at hotmail
--

Hello guys needs a couple more beta testers for my new projects, am looking for guys with 7000,  705, 905,  756ProIII, 746Pro, 7400, 7410, 7100, 7200, 7300, 7600, 7610, 7700, 7850, 7851, 9100, 9700, R8600 and R9500

Please contact me direct via email at ve2dx at hotmail dot com

Follow my projects on www.facebook.com/VE2DX/

Hello guys, Here is the demo of our 100% VE2DX ICOM Needle Meter. Hardware and code are 100% VE2DX Electronic.
https://youtu.be/FjT3O2ku120
and
https://youtu.be/Er17RMD_18Y
Let me be clear, this unit supports Bluetooth radios and 19 CI-V ICOM Radios using a simple 1/8 mono audio cable. Among other things, It supports ; - 19 ICOM Radios, - 3 cabled CI-V Speeds, - Bluetooth CI-V for radios like the 705/905, - it has CI-V data indicators in the upper corners for Bluetooth (Left) and Cabled radios (Right), - By default, it always shows S-Meter data - and then the user can select ALC, Power or SWR while in Transmit mode, - it shows the data using the needle and also numerically, - it shows the operating frequency and a Transverter offset can be added if need be, - finally, it also shows Mode (Including Data modes) and Filter settings... There is a lot of flexibility available to the user via the menu system changing; - Radio Model, - CI-V Speed, - Turning on/off DataLeds, - Selecting Transverter modes, - Changing Background color (White or Black), - Adjusting Brightness, - Beep Volume, - ScreenSaver timer, - Power off - and exiting the menu. Please drop by WWW.VE2DX.COM for more info --

Arduino nano EVERY.  Can do Yaesu too.  This video is more focused on the configuration than the operation. ahttps://youtu.be/u8pPKy762sg

Hello guys, as some of you are aware I have a small lab where I work on Ham Radio devices and have been doing a lot of work around CI-V devices and hubs.

Well after many months of work, I am introducing this week my ICOM Meter this meter was originally based on the work done and published in QST that I modified as shown in Dayton to adapt my new VE2DX CT17B-Micro Internal RF Filtered 3 Ports CI-V Ports.  My new meter supports 15 icom radios via CI-V and 1 via BT (705), and will link Bluetooth and Cabled devices like radios or OEM CI-V devices.

Also, the Bluetooth link can be used to connect your computer or cellphone to your CI-V devices and radio for use with software like HRD.

Please drop in to take a look WWW.VE2DX.COM
--

I use either a mega 2560 ( with Ethernet shield ) or a nano EVERY on a custom PCB

Very nice
--

Very nice is it Arduino or ESP32 based?
--

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

Hi, I’ve been experimenting with CI-V for a few years, originally driven by my desire to add a few external buttons to IC 7300 ( and later my 8600 ), the project evolved to more than that.  Here is a brief demo. https://youtu.be/-kn3Pd1ENI8

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 )

+ 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

great Input Dave,

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

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

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