A few notes on Icom's CI-V interface

[N8YX]

Almost every Icom rig made since the mid 80s incorporates their CI-V computer interface. It allows multiple radios to be connected together and computer controlled via a CT-17, or two to be directly connected for purposes of synchronized operation.

I recently dragged one each IC-751A and R-71A out of storage to place in my main floor shack/home office. The aim was to use the -751A as my FT8 rig and the -71A as a second receiver, for monitoring other parts of the shortwave spectrum. In a future implementation, multiple receivers (a mix of R-71As and R-7000s) may see duty with each transceiver - all capable of being controlled via one CT-17.

Icom offered a CI-V accessory for the R-71, IC-751 and other rigs...the UX-14. It supports communication baud rates of 300, 1200 and 9600. We're going to take advantage of this.

The interface (in face, most CI-V hardware) also supports something called "transceive mode". That is if it's configured to use this mode, a change in operating parameters will result in a data stream being transmitted out the port so that other devices configured with "transceive" will automatically sync to the "master" (whichever radio initiated the change). Handy in true diversity-reception scenarios, or if your secondary receiver is a better performer than the one in your transceiver. A special bus address (corresponding to "all") makes this possible and is automatically set if "Transceive" is enabled on a given interface.

Conversely, if this isn't set nothing happens. A change to the radio's operating parameters won't be broadcast, and the radio won't act upon any received updates. Changing the interface mode requires removing the radios from the lineup and pulling the covers off. Not an ideal way of doing things.

While I had the -751A apart to install its interface, I decided to do a little playing around. Both receiver and transceiver had their UX-14s set to "transceive" and 9600 baud speed. Any changes made on the -751A immediately propagated to the -71A, and vice versa.

Except for changes made by WSJTX. I could change bands on either transceiver or receiver via the program and the other device stayed put. Until the VFO, Memory or Mode switches were touched, that is. I also experimented with baud rates of the UX-14s and found that if they're different, no synchronization occurs.

Some contemplation led me to the following:

• In a multi-rig Icom station with one station controller PC available, leverage a CT-17 for connection of up to four different radios.
• All radios connected to one of these can "see" each other if "transceive" is set and the baud rates are the same
• Several communications control programs (e.g., ScanCAT Gold, Spectrum Commander) offer the ability to control the R-71 and R-7000 receivers (and others) in either independent mode or as a "range pair". That is, the R-71 handles frequencies below 30MHz and the R-7000, those above. Handoff is done automatically as the programs scan or search.
• A fully equipped station with radios of this era could include the -751A, a pair of R-71As and an R-7000.
  
  • The IC-751A and one R-71A have their UX-14s set to 1200 baud
  • The other R-71A and the R-7000 are configured for 9600 baud
  • Each radio is configured for a different CI-V address
  • All radios have the "transceive" option set
  • The IC-751A feeds signals to its companion R-71A via a Mini Circuits 50-ohm power divider, connected to the Rec Ant Out/In ports on the transceiver's rear panel
  • The second R-71A is either fed from the "active" station antenna (use a 4-port divider) or via a separate receive antenna (use a receiver protector at the antenna input).
  • The R-7000 is fed from a wideband scanner antenna. Use a high-pass filter if 10M operation of the transceiver is contemplated.
  • An IC-EX1 handles muting of all the receivers and acts as an I/O interface to things like a SignaLink or KAM.
    
    • Note: An R-7000 "Ext Mute" scheme is being devised. Why didn't Icom think to include this...
    
    
  
  
• To use the station, one does the following:
  
  • Dial up a favorite frequency to monitor with the first R-71A. Set mode, memory, what have you - then hit the Tuning Lock button.
  • Use WSJTX, HRD, etc. to control the transceiver. Its Tuning Lock button should also be pressed.
  • Use Spectrum Commander, ScanCAT, etc. to control the R-71A/R-7000 pair. Ditto the Tuning Locks.
    
    • Note that only one program at a time can access the serial port used to connect the CT-17. Simultaneous operation requires two of these adapters, one per "pair". You can control up to four rigs through each and I've tested this with Spectrum Commander.
    • R-71 and R-7000 require a special "Squelch Detect" cable to stop on a busy signal. In the Groups.io "R7000RX" group I detailed how to build a multi-radio cable. This has been tested with three concurrently operating R-7000s.
    
    
  • When you wish to sync two radios, stop the controller program which is interacting with the desired "pair" then make a parameter change to one or the other. Its companion will track.
  
  

It's important to relinquish PC control of the transceiver before changing parameters if you have accessories connected which automatically track band changes. I have an AT-150 at my FT8 position. IC-2KL/AT-500 pairs can also be pressed into service and you don't want them jumping between bands in response to a receiver-commanded change if you're actively using the transceiver.

Granted, this was a rather long post - but may spur a few ideas. Later CI-V implementations may support more choices of baud rate, and I'll look into this as yet another possibility for multi-rig operation.

[KG4CGC]

Thank you.

[N8YX]

A few more notes (I'll add as I find this stuff out):

• The IC-703 has a baud rate option of 19200, and I presume 2400/4800 is supported too. This would give more options for "sync pairs" on one CT-17.
• fldigi supports the IC-751 via RigCAT. Hamlib supports it in "Beta" mode but I find their implementation to be very problematic (i.e., frequent lockups of the transceiver and program).
• Running wsjt-x and fldigi concurrently is a no-go, even though the radios (IC-751 and R-71) are at different addresses and the interfaces configured to use the same baud rate. This SHOULD work in theory...
• Concurrent operation of both programs and two radios on the same host PC is possible if one uses two USB-to-CI-V dongles...but it defeats the purpose of CI-V and I'm out of I/O ports on this system regardless.

I've a thread going on linuxham as to the possibilities of concurrent control - will post any results gleaned from further experiments here.

[N8YX]

Became somewhat frustrated with the beta IC-751 CAT driver in fldigi and the nonexistent support for the radio in flrig so I took off my fog hat, put on my Nerd Hat then proceeded to code up a driver (borrowing from existing flrig Icom drivers wherever possible).

The R-71 is almost identical in terms of command set to the IC-751 so I created a unique driver for it as well. If you have a Piexx UX-14Px CI-V/serial interface installed in the transceiver, S/Po functions are supported. As is PTT via an flrig button. The receiver only supports S meter monitoring and I'm working with the program maintainer(s) to get an RX-only S meter graphic into the library files.

Next will be a deep dive into hamlib. I can't believe someone dropped the ball on multi-rig CI-V support, as the whole premise of that bus is to facilitate it.

[N1LAF]

In single wire communications, collision control becomes important, more devices you communicate with, more collision potential exists, especially with babbling devices that broadcast its new frequency when you turn the frequency dial. Additional conversion devices, such as USB/RS232 becomes problematic with multiple devices and the time delay with USB conversion. The talking device should also monitor/read its own transmission - if what was sent doesn't equal to what it read, a collision may have occurred, and may need a resend process.

[N1LAF]

I saw this link that addresses and 'solves' collision problems. http://k9jm.com/CIV_Router/CI-V%20Router.htm
I think you can have multiple devices per port, minimizing collisions based on port sharing selection.

I also read this: http://k9jm.com/CIV_Router/CIV_Electrical_Interface.pdf , but I think the author misunderstood the MAX232 interface spec sheets. The author states: "Here they do what appears to be the insanity of shorting pin 11 to pin 12 to the CI-V bus, which are in input and the output of the level translator. Looking at the datasheet for the MAX232, this part has Vih=2 and Vil = .8 volts. Combining this with that of the radio, Vil = .8 volts and Vih = 3.6v The Max232 also has an output source current of 1ma, and an output sink current of 3.5 ma. Because the input is connected to the output, the CT17 can only sink a maximum of 2.5ma, which is far less than the current sinking capabilities of the radio."

I looked at the spec sheet, and from what I see, the Rout has a diode on the output, with a pull up resistance of 1.3K, and an output resistance of 300 ohms. This is consistent with the parameters on the spec sheet. This is what I see - the diode with the pull-up resistor which essentially gives it open collector/drain characteristics. This will allow shorting of pins 11 and 12 on the CV-17 interface. If you put a dead short on Rout of the device, the source 5 VDC divided by the 1.3K pull-up plus the load resistance of 300 ohms, becomes 5/1600 = 3.125 mA, rounded up to 3.2mA, as specified in the spec sheet. Any number of CV-17 drivers is not going to beat a dead short, its not going to change anything.

What is important is the issue of collisions between two (or more) talkers.

[N8YX]

Not quite CI-V but still Icom:

I'm about 90% done with the update of the PCR-1000 'black box" driver for flrig. Dave (W1HKJ) started writing the driver but his radio has no DSP module installed. The one connected to the PC I'm using to reply does. The only thing not working at this point is the routine to get the noise reduction level value (slider control), include it in a formatted string then send the string to the radio via the serial port. I -think- I reverse-engineered what Dave is up to with the Send routine but it's still not functioning properly. DSP activation, auto-notch, noise reduction on/off and AGC are all working properly now.

As far as CI-V: Paul, I understand that Icom built anti-collision and bus negotiation routines into the firmware/hardware of compatible transceivers, so a controller program doesn't have to perform traffic control.

[N1LAF]

As far as CI-V: Paul, I understand that Icom built anti-collision and bus negotiation routines into the firmware/hardware of compatible transceivers, so a controller program doesn't have to perform traffic control.

I would expect anti-collision on the firmware side, but you still need anti-collision on the application side. Usually this would not be a problem with master-slave communications, but for example - do a periodic S-Meter update, and turn the tuning dial on the radio, the radio is going to spit out its frequency, and this is where a collision could occur.

Keep in mind that the TX and RX is tied together, so you will get an echo of the master command back to the master serial receive. By reading back the serial receive, you will clear the serial buffer of the original command, and verify that the command sent was valid.

[John M0NRZ]

Hi … I’ve been tinkering with CI-V for a few years using an Arduino to build an external controller. Re the One wire Bus ( i.e. common to TX and RX ) : I send commands to request data e.g. Frequency, Mode, S-meter…. the control software waits about 40ms … by then a copy of my TX message AND the radio’s reply is in the Receive buffer. I compare the TX message with what was sent ( if ok no data collision occurred ) … then process and use the reply data …. demo. https://youtube.com/shorts/tNivADqig...fGs4_TJ_kY6ota

[NQ6U]

Welcome to the Island, John!


I read your profile on QRZ and I’d be interested to hear more about the interface you’re working on since I also have an IC-7300. In the mean time, speaking as the Island Pope, have Charles pour you a drink and put it on ny tab. And make it the good stuff — the Vatican can afford it.