Well, the answer is; yes and no! It depends...

One a unique hub like CT-17 or the VE2DX CT17B series, you CAN run more than one radio linked to the same computer...

But...

Yes, there is a BUT... :P

Your CI-V is an addressable protocol where each radio has a unique address AND (this is a BG ONE!!!) each computer output or application MUST also have a UNIQUE address...

And this is where we run into a problem, since on an ICOM CT17, VE2DX CT-17B-5, CT17B-6, or CT17B-6BT all the devices are on the same hub bus then if you start two sessions of HRD for example talking to two radios even via separate ports (USB and Bluetooth for example) then HRD is always using E0 as the computer.

Thus... when the 7300 responds to the HRD source1 with 28.074.00 for example, it is possible (likely!) that you will see that same freq pop up in HRD Source2 (the 9700) and then flip back and vice versa...

To fix this the source program would have to use a unique Address like E0, E1, E2, etc... and this would solve the problem since E0 would be use by the 7300 to respond and E1 would be used by the 9700.

this is RAREly available in most applications.

Solution;

Simple either install two separate hubs.

or use a VE2DX CT17B-10, this is a 10 port hub where by removing a simple jumper you can split the hub into two 5 port hubs...

And yes the CT-17B-11USB, CT17B-11BT, CT17-12USB and CT17B-12BT and coming back... I am working on new versions of these babies that will blow your pants off...

A lot more new stuff coming out soon, We finalized our IMK2-JR 7610, 7850, 7851 and 705 8 memory keyers with external M1 and M8 footswitch connectors, working on releasing next month the IMK3J3, Larger and added features IMK3 and dual radio IMK3uP, all 4 memory keyers with TONES of features...

follow us here and at WWW.VE2DX.COM


--

The CI-V protocol is defined to support interactions among multiple nodes. With more than two nodes communicating, there will likely be collisions. The protocol defines how collisions should be detected and resolved, but not all hardware devices conform to the protocol; the PW-1 amplifier, for example, is notoriously non-compliant. Furthermore, not all computer-hosted transceiver control applications conform to the protocol's collision-handling requirements.

73,

Dave, AA6YQ

I fully agree, Dave!

Could be debated that even Icom does not always follow properly there own standards...

And it is very difficult to know if all application and hardware design (firmware) apply or not the ICOM standards properly...

The issue of the Applications ALWAYS using E0... This is wrong, if multiple radios are being accessed by an application on a single CI-V bus a different controller address should be assigned.

And I agree also that putting multiple radios (that do not need to be on the bus) on the same bus bring multiple issues of collision.

And you have to be careful about OEM devices... devices like Band decoders are not always passive, some like the Band Decoder II actually can be active polling the radio, this can definitively cause a collision with other radio, devices or applications.  A device like a band decoder SHOULD be passive sniffing the data on the bus if another device or application is already using the CI-V bus that needs priority...

I have been working on a very flexible routing approach for many months, debugging at this time latency issues...but this approach does help some of these issues.

Depending on your needs you should ALWAYS keep in mind the possibilities of collisions on your CI-V bus, and look at the need to split your station into multiple CI-V Bus set up to prevent this.



--

Could be debated that even Icom does not always follow properly there own standards...

+ the PW-1 is the only example I know of where Icom violates the CI-V bus specification. It has no collision detection capability whatsoever. See Larry K8UT's analysis here:

http://www.k8ut.com/wpfb-file/riding-the-ci-v-bus-by-k8ut-pdf/


And you have to be careful about OEM devices... devices like Band decoders are not always passive, some like the Band Decoder II actually can be active polling the radio, this can definitively cause a collision with other radio, devices or applications. A device like a band decoder SHOULD be passive sniffing the data on the bus if another device or application is already using the CI-V bus that needs priority...

+ I can understand why the ability to poll the radio is provided, as it may be needed in some topologies; but there must be a way to disable the polling when the only thing it's doing is creating collisions.

I have been working on a very flexible routing approach for many months, debugging at this time latency issues...but this approach does help some of these issues.

+ I've found it sufficient to provide a private CI-V bus for the PW-1, thereby eliminating any possibility of collisions. All other valid topologies are handled by collision detection and retransmission as described in the CI-V bus spec.

73,

Dave, AA6YQ