[ICOM] Splitting the remote stream

Sun Apr 18 17:24:13 EDT 2010

Ahhh - thanks for the education (I'd never delved quite that deep into
CI-V).

So then it IS using what I alluded to - in fact the same protocol I was
referring to ala networking.  It's just that the PW-1 doesn't have a correct
implementation in that it isn't detecting and discarding the corrupted
packets.

Seems to me if it's just the PW-1 that isn't playing nice, that Icom should
provide an update to fix it.  Especially since having it switch to the wrong
band (and then transmitting) could cause damage. 

73,
Jay

-----Original Message-----
From: icom-bounces at mailman.qth.net [mailto:icom-bounces at mailman.qth.net] On
Behalf Of Dave AA6YQ
Sent: Sunday, April 18, 2010 13:50
To: ICOM Reflector
Subject: Re: [ICOM] Splitting the remote stream

Jay, your explanation below is incorrect. The Icom CI-V bus uses a protocol
known as Carrier Sense Multiple Access with Collision Detection (CSMA/CD).
The idea is that a node wishing to transmit on a shared bus waits until the
bus is free, and then transmits. From the CI-V Reference Manual, 3rd
Edition, section 1.6 "During data transmission, the radio which is
transmitting a message monitors the CI-V bus line simultaneously. If message
collisions are detected, the radio halts the message transmission. After
waiting for a programmed period of time, the radio sends the previous
message again". For this scheme to work, all receiving nodes must detect and
discard commands corrupted by collision, and a transmitting node must
retransmit after seeing its outgoing command be corrupted or after failing
to receive a positive acknowledgement (FE FE E0 <addr> FB FD).

CSMA/CD is a well-known protocol; Ethernet employs CSMA/CD, for example. See
<http://en.wikipedia.org/wiki/Carrier_sense_multiple_access>

The problem with the PW-1 is that its designers did not include the required
collision detection and corrupted command rejection logic. Thus it cannot be
placed on a CI-V bus with another master, e.g. a PC running transceiver
control software.

   73,

      Dave, AA6YQ

-----Original Message-----
From: icom-bounces at mailman.qth.net
[mailto:icom-bounces at mailman.qth.net]On Behalf Of AD5PE
Sent: Sunday, April 18, 2010 12:26 PM
To: 'ICOM Reflector'
Subject: Re: [ICOM] Splitting the remote stream

The problem isn't really the "split", it stems from both devices doing
two-way comms.

If CI-V was the radio "broadcasting" its settings (band, freq, mode, etc.)
to various devices, then those that needed that info could monitor the
stream and "follow along" with no problem.

This doesn't work with computer remote control, though.  Now you have a
second device (the computer, microkeyer or whatever) that wants to send
(unsolicited) commands to the RADIO, telling it to do something.  (IE,
computer through HRD commands a freq change, radio changes freq, then sends
new freq to amp).

This scenario also works fine, provided there is only ONE device (besides
the radio) on the buss that is sending commands.

This issue is that in some cases you have two devices sending commands, and
neither is checking for a "busy" line.  For example, the computer sends a
command to the radio to do something, and at the same time the radio is
sending its band data (operating freq) out as a broadcast.  The computer's
message gets "lost" as far as the radio is concerned (and likely the
computer sends it again when it doesn't get an acknowledgement) - a no harm
situation (other than the frustrated op that didn't have his "command"
obeyed).  On the other devices, though, they received two messages
overlapped time-wise.  There's a command to the radio embedded in the middle
of the band data message, so what the amp "sees" is a string of bits that
doesn't make sense (or maybe it does, but it doesn't mean what either the
radio or the computer "meant" - hence the "random" band switching).

In computer programming, this is a fairly common problem with a number of
possible solutions.  One common fix is for all devices to monitor the buss
and wait for a "ready to send" (and assert "not ready to send" when they
grab the buss) but this requires ALL devices to abide by this protocol.  It
only takes one device sending without an "ok" to mess up the buss.  The
basics of the CI-V logic is that they did not do this.  The command set
allows any device capable of sending to do so without any form of checking
for the buss being in use by another device.  Normally this wouldn't be a
problem, since any two-way device would be listening as well (and therefore
could "see" the busy buss) but it is now THEIR responsibility, not the buss
or the radio to do so.  It only takes one programmer for one interfacable
device to forget one line of code in one spot and now you have the potential
for that device to "send" on a busy line, and now you get a collision.

Without fixing the CI-V command set to force some sort of semaphore by all
buss users (a major undertaking as it would invalidate every remote control
program out there today) the other options are to set all but one device to
"read-only" or to get individual devices manufacturer's to fix their code to
use "listen first" logic so as to not step on a message originating from
some other device on the buss.

The other (not so easy) solution would be to insert memory buffer devices
between the offending buss users.  Basically a mini memory that detects the
busy buss, "eats" the potentially colliding command, and either disposes of
it, or holds it until the buss is free, then forwards it on.  This kind of
logic is fairly common in computer OS (I/O buffering disk writes) and
networking (IP does this at the switch level) but the hardware and software
required is significant.  Not huge (they build it into $30 consumer home
routers!) but usually very application specific and not easily adapted.  It
would take some R&D to make a similar device using OTS components.

Jay

-----Original Message-----
From: icom-bounces at mailman.qth.net [mailto:icom-bounces at mailman.qth.net] On
Behalf Of Paul Beringer
Sent: Saturday, April 17, 2010 22:03
To: icom at mailman.qth.net
Subject: [ICOM] Splitting the remote stream

Here's the deal. Awhile back on the PW-1 reflector, someone posted a note
saying that they had multiple devices using the CI-V output of the radio and
were experiencing some problems with the amp making band jumps
intermittently. The problem seemed to be associated with remote jack being
split. One person suggested that due to bit collisions, some data gets
corrupted while being sent after a request from the outboard devices. I use
a splitter so the CI-V signal can be sent to the Microkeyer and the amp and
am experiencing the same thing. So I thought it would be interesting to see
if someone had invented a device to prevent data corruption. I didn't think
it was a dumb thing to ask but perhaps I was wrong. Maybe this reflector was
designed for those who are more intelligent than I am, if so my apologies.
73 Paul NG7Z

----
Your Moderator: Dick Flanagan K7VC: icom-owner at mailman.qth.net Icom Users
Net: Sundays, 1700Z, 14.316 MHz Icom FAQ: http://www.qsl.net/icom/ To
support QSL/QTH.net: http://www.qsl.net/donate.html

----
Your Moderator: Dick Flanagan K7VC: icom-owner at mailman.qth.net Icom Users
Net: Sundays, 1700Z, 14.316 MHz Icom FAQ: http://www.qsl.net/icom/ To
support QSL/QTH.net: http://www.qsl.net/donate.html No virus found in this
incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 271.1.1/2812 - Release Date: 04/18/10
02:31:00

----
Your Moderator: Dick Flanagan K7VC: icom-owner at mailman.qth.net Icom Users
Net: Sundays, 1700Z, 14.316 MHz Icom FAQ: http://www.qsl.net/icom/ To
support QSL/QTH.net: http://www.qsl.net/donate.html