[ICOM] Splitting the remote stream

Sun Apr 18 15:04:18 EDT 2010

Very Well Stated .... I guess I got kinda harsh on my first reply to these
questions ... Please Forgive ....

On Sun, Apr 18, 2010 at 12:50 PM, Dave AA6YQ <aa6yq at ambersoft.com> wrote:

> 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
>

-- 
de KA5CDJ,  T. Brad Smith,  ka5cdj.com
M.A.R.I.E. El Paso w5dpd.org
Life Member ARRL arrl.org
Life Member Texas VHF/FM Society txvhffm.org
Member Armadillo Intertie armadillo.org
Member Jacks Peak ARA jpara.net
Member of the Board, Sun City Amateur Radio Club k5wph.org
Trustee & Web Master of West Texas Repeater Association k5elp.com
Past Member JSCARC w5rrr.org