Serial protocol with physical decoding

Don Y wrote:
> On 5/4/2017 4:47 PM, Les Cargill wrote:
>> Don Y wrote:
>>> I want to push a bit stream through a series of *identical* devices
>>> and have (identical) software running on each determine if that
>>> particular device is being addressed, or not.
>>>
>>> It seems like the simplest way to do so is to require each device
>>> to examine an address field in the packet and, if '0', assume the
>>> data that follows is intended for its consumption.  If not,
>>> decrement the address and pass the packet along.
>>>
>>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
>>> signals)
>>>
>>> Of course, this means a failure of any device renders those that
>>> follow it inaccessible.  That's acceptable.
>>
>> <snip>
>>
>> It's way simpler to just have a 422/485 bus.
>
> Then you have to have a way of making each device "unique".
> This typically means a configuration activity that is probably
> non-trivial.  And/or stocking different "part numbers" for
> what are essentially the same component but with different
> addresses, etc.
>

You have to have some way of managing this anyway.

in your example - do you somehow know that the third device in the
chain is always the "bluralizer"? I suppose that makes sense.

But these things are a truck roll anyhow, and 2.5 minutes sending a node 
address isn't that much more work.

I wrote a proposal once for a MODBUS system to automate addressing, but
it required a priori knowlege of order of devices on the bus, powering
them up in order  and nobody could guarantee that. Stuff was wound
every which way, so it was decided that explicit addressing was
preferred.

> And, protocols to handle the case where two devices are
> NOT unique (i.e., duplicate address).
>

In reality, that cannot be done for ostensibly "serial"
stuff. CAN is different[1]; but it's still a CM fail.

[1] I don't really recall what happens there.

> Plus all the bus contention/arbitration possibilities, etc.
> (if you want to get data *back* from the devices)
>
> For example, with the cascaded scheme, you can wire all
> of the lamps on the playfield of a pinball machine to power
> and ground; then daisy chain a data line through a "smart
> lamp driver" located adjacent to each individual lamp.
>
> That *one* "lamp bus" signal would allow the processor to
> turn any lamp on or off (dim, flash, whatever) regardless
> of the number of lamps on the playfield.  The system
> software would only need to know the lamp "order" of the
> prototype as all future playfields (for that model) would
> be wired in the same daisy-chain order.
>
> When a lamp driver fails, it could be replaced with a
> new component without any need for reconfiguration,
> testing for duplicate bus addresses, etc.
>

That's true. That's a sort of "degenerate" case where your
proposal makes sense.

It still smacks of "look! If we're real clever, we can
eliminate a whole wire!" which makes me eye-roll :)

> The same power/ground could be distributed to all of the
> "smart hammer drivers" sited adjacent to each of the
> solenoids/actuators on the playfield.  That *one*
> "hammer bus" signal would allow the processor to turn
> any solenoid on or off (including supporting a pull-in
> coil, maximum duration timer, shorted/open coil detector,
> etc.) regardless of the number of drivers on the playfield.
>
> [The lamp driver and hammer driver could be similar save for
> current handling capacities and other "use related" issues
> in their software; you probably don't care if a lamp
> stays lit indefinitely -- but, a coil often has a duty cycle
> limit!]
>
> Likewise, you could have a "switch driver" that is distributed
> around the playfield to sense contact closures arising from
> the ball's motions.
>
> You could do this with *other* busses -- including those that
> require explicit addressing -- but with considerably more pain.

Right.

-- 
Les Cargill

On 5/7/2017 7:21 AM, Les Cargill wrote:
> Don Y wrote:
>> On 5/4/2017 4:47 PM, Les Cargill wrote:
>>> Don Y wrote:
>>>> I want to push a bit stream through a series of *identical* devices
>>>> and have (identical) software running on each determine if that
>>>> particular device is being addressed, or not.
>>>>
>>>> It seems like the simplest way to do so is to require each device
>>>> to examine an address field in the packet and, if '0', assume the
>>>> data that follows is intended for its consumption.  If not,
>>>> decrement the address and pass the packet along.
>>>>
>>>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
>>>> signals)
>>>>
>>>> Of course, this means a failure of any device renders those that
>>>> follow it inaccessible.  That's acceptable.
>>>
>>> <snip>
>>>
>>> It's way simpler to just have a 422/485 bus.
>>
>> Then you have to have a way of making each device "unique".
>> This typically means a configuration activity that is probably
>> non-trivial.  And/or stocking different "part numbers" for
>> what are essentially the same component but with different
>> addresses, etc.
>
> You have to have some way of managing this anyway.
>
> in your example - do you somehow know that the third device in the
> chain is always the "bluralizer"? I suppose that makes sense.

In the pinball example, the guy who designed the wiring harness
knows what order the "nodes" are visited by the wire -- and, this
order doesn't change from machine to machine.

The order is unlikely to change -- after manufacture or deployment.
This is not true of "computers" and devices with assigned addresses.

Also, as there will be an inherently LIKELY order, it will be trivial
to deduce the order and adjust a table (that would almost surely
exist) in the software.  E.g., it would be unusual for the light
adjacent to the left flipper to be followed by the light in the top
RIGHT pop bumper and then the right flipper, then the top left pop
bumper then the light adjacent to the very first light... etc.

> But these things are a truck roll anyhow, and 2.5 minutes sending a node
> address isn't that much more work.

"Minutes"?

> I wrote a proposal once for a MODBUS system to automate addressing, but
> it required a priori knowlege of order of devices on the bus, powering
> them up in order  and nobody could guarantee that. Stuff was wound
> every which way, so it was decided that explicit addressing was
> preferred.

Assigning addresses in this scheme would be trivial:
      3 ADDRESS 14
would cause the first 3 devices to propagate the command
thereby informing the fourth device (in the chain) that
its address is "14".  But, what does that buy you?  Unless
you can then reconfigure the network to a bus topology
(to eliminate the processing delay through each device)

>> And, protocols to handle the case where two devices are
>> NOT unique (i.e., duplicate address).
>
> In reality, that cannot be done for ostensibly "serial"
> stuff. CAN is different[1]; but it's still a CM fail.
>
> [1] I don't really recall what happens there.

In the daisy-chain case, its not possible for more than
one device to process a message intended for *one* device.
(You could implement a message that is designed to be
processed by some subset of devices -- even things like
"every other", "every third", etc.)

>> Plus all the bus contention/arbitration possibilities, etc.
>> (if you want to get data *back* from the devices)
>>
>> For example, with the cascaded scheme, you can wire all
>> of the lamps on the playfield of a pinball machine to power
>> and ground; then daisy chain a data line through a "smart
>> lamp driver" located adjacent to each individual lamp.
>>
>> That *one* "lamp bus" signal would allow the processor to
>> turn any lamp on or off (dim, flash, whatever) regardless
>> of the number of lamps on the playfield.  The system
>> software would only need to know the lamp "order" of the
>> prototype as all future playfields (for that model) would
>> be wired in the same daisy-chain order.
>>
>> When a lamp driver fails, it could be replaced with a
>> new component without any need for reconfiguration,
>> testing for duplicate bus addresses, etc.
>
> That's true. That's a sort of "degenerate" case where your
> proposal makes sense.
>
> It still smacks of "look! If we're real clever, we can
> eliminate a whole wire!" which makes me eye-roll :)

OK, I'll ADD the wire back into the bundle -- and just
mark it "spare".  Does that feel better?  Maybe add two or
three, just in case?

Why doesn't RG6 have a spare conductor?  Seems silly to only
use 2; then have to deal with power injectors when you want
to power an in-line amplifier up on the mast...

Why not run 4-pair (or 2-pair) around the interior of an
automobile so the various modules can implement ethernet to
talk to each other?

Or, put a NIC at each of those lamps on the pinball playfield?

You're also ignoring the fact that the devices then become
identical.  You (user) can replace ANY failed/suspect device
with a generic device of the same type -- without having
to do any followup configuration of the device or the
system.

I've been surprised at how many (sub-)applications I have that
can benefit from NOT needing to configure specific devices
to have specific addresses; cases where it would be great if
a user could simply replace a defective unit with a factory
fresh one without also having to "configure" it.

But, that's largely possible because I can control the cabling
technology and topology.

E.g., whenever I add another node to the network in the office,
I have to run a hole new wire from the switch, FOLLOWING the
existing wire bundle as it makes its way around the room to
the location of the new node.  20 years ago, I'd just unplug
the coax feeding the device "downstream", insert the new node
with an appropriate length of coax to that downstream node
and be done with it.

[Of course, the network is disturbed *while* this is happening
(as the downstream PORTION would be in my daisy-chain scheme)
but that's an infrequent event and one in which I participate]

Nowadays, I have to track the lengths of all of the cables
leaving the switch(es) -- so I have an idea how long of a cable
I will need to service a new addition:
    "I'm going to be locating this new node between the color printer
     and the VM server.  The cable to the printer is 13 ft long
     and the VM server is 18 ft.  So, aim for about 15 ft and hope
     for the best (cuz there's no place to "store" any service loops
     and coming up short will mean removing the cable from the bundle
     and starting over)"

OTOH, I can move the color printer to another *room* and not have
to change any configuration tables!  (wouldn't have had to with
10Base2, either, but WOULD have with this daisy-chain scheme)

>> The same power/ground could be distributed to all of the
>> "smart hammer drivers" sited adjacent to each of the
>> solenoids/actuators on the playfield.  That *one*
>> "hammer bus" signal would allow the processor to turn
>> any solenoid on or off (including supporting a pull-in
>> coil, maximum duration timer, shorted/open coil detector,
>> etc.) regardless of the number of drivers on the playfield.
>>
>> [The lamp driver and hammer driver could be similar save for
>> current handling capacities and other "use related" issues
>> in their software; you probably don't care if a lamp
>> stays lit indefinitely -- but, a coil often has a duty cycle
>> limit!]
>>
>> Likewise, you could have a "switch driver" that is distributed
>> around the playfield to sense contact closures arising from
>> the ball's motions.
>>
>> You could do this with *other* busses -- including those that
>> require explicit addressing -- but with considerably more pain.
>
> Right.

Il giorno domenica 7 maggio 2017 16:16:24 UTC+2, Les Cargill ha scritto:
 
> I wrote a proposal once for a MODBUS system to automate addressing, but
> it required a priori knowlege of order of devices on the bus, powering
> them up in order  and nobody could guarantee that. Stuff was wound
> every which way, so it was decided that explicit addressing was
> preferred.

If you know the position of the devices, you can use something simila to LIN Bus Shunt Method to autumatically address the devices.
But you need some additionaly circuitry.

Bye Jack

On Sat, 6 May 2017 12:29:11 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 5/6/2017 9:14 AM, Martin Riddle wrote:
>> On Wed, 3 May 2017 23:14:09 -0700, Don Y <blockedofcourse@foo.invalid>
>> wrote:
>>
>>> I want to push a bit stream through a series of *identical* devices
>>> and have (identical) software running on each determine if that
>>> particular device is being addressed, or not.
>>>
>>> It seems like the simplest way to do so is to require each device
>>> to examine an address field in the packet and, if '0', assume the
>>> data that follows is intended for its consumption.  If not,
>>> decrement the address and pass the packet along.
>>>
>>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT
>>> signals)
>>>
>>> Of course, this means a failure of any device renders those that
>>> follow it inaccessible.  That's acceptable.
>>>
>>> It also means there is a latency proportional to the device address
>>> inherent in the protocol.  Also acceptable (the data source can
>>> take that into consideration when creating the message stream).
>>> And, the incremental latency can be made pretty small.
>>>
>>> Another downside is the cost of updating data on *all* (multiple)
>>> devices as this requires N messages.
>>>
>>> An alternate message format (or, a cleverer encoding of the above)
>>> could be used to allow a single COMPOSITE message to be propagated
>>> in which a node encountering a '0' address field strips the data
>>> that is intended for its use and then reconstructs a message
>>> bearing a '0' address field with the BALANCE of the data that it
>>> then passes to the next device, in series.  In effect, letting
>>> each subsequent device strip off "its" data before passing the
>>> remainder along.
>>>
>>> [When no data remains, the message dissipates]
>>>
>>> As such, you could "address" any set of contiguous addresses
>>> by creating an initial message of the form:
>>>     <first_target_ID> <first_datum> ... <last_datum>
>>> where the number of data present in the message implicitly defines
>>> the *last_target_id* relative to the first_target_id.
>>>
>>> Any problems with this sort of kludged encapsulation?
>>
>> You would need two fields, one the 'Target Address' and a 'Address
>> Counter'
>
>No.  The "address counter" serves dual purpose:  when the count
>attains '0', the message is intended for the current device.
>I.e., it indicates the number of devices *upstream* from the
>targeted device that should be skipped.
>
>[Of course, you can define other semantics]
>
>> The Target Address is the device to  be controlled.
>> The Counter address is the Address that each device increments and
>> passes to the next device.
>
>The only advantage, there, is that it then *tells* the device what it's
>position (address) happens to be.  If such a capability was needed,
>you could kludge that capability into this structure -- incurring that
>overhead only when needed.
>
>> But I don't see why a 8 pin address header is a bad idea. You can
>> still do a pass thru serial chain. plus the devices dont need to
>> enumerate.
>
>Depends on the number of devices, the distance between them, the
>nominal data rates, etc.  E.g., if you have to handle a network
>spanning hundreds of feet, you'd want to minimize the number of
>conductors (and associated line drivers/receivers).  If you wanted
>to handle a network with hundreds of "devices" (note that a device
>is an arbitrary construct -- a physical device could, potentially,
>consist of 30 devices, if you opted to treat them as such!), then
>the width of the address field could exceed a fixed size.
>
>The logical idea of increasing the width of the address field then
>penalizes smaller networks as well as impacting maximum data rate
>(more symbols to xmit with "no" information content!).  So, you could
>encode the "address"/ID in a manner that allows for it to expand to suit
>the needs of the particular network/message -- without unduly burdening
>short messages/nearby targets or long messages/distant ones.
>
>> I've done a 2 device serial pass thru chain, but they were hard coded
>> addresses.
>
>So far, the problems that I've identified are related to error analysis
>(and recovery) along with distributed clock synchronization.  Hard failures
>are (relatively) easy to address:  fix the damn thing!  :>

Go over to Hack-a-day, theres someone that daisy chained some audrinos
and just let each audrino grab the last 5 bytes of the control packet
and send the remaing bytes to the next device. Addressing is by the
position of the data in the packet.
He has no error control, but the idea of all the devices running the
same code is what your looking for.


Cheers

On 5/8/2017 3:53 PM, Martin Riddle wrote:
>> So far, the problems that I've identified are related to error analysis
>> (and recovery) along with distributed clock synchronization.  Hard failures
>> are (relatively) easy to address:  fix the damn thing!  :>
>
> Go over to Hack-a-day, theres someone that daisy chained some audrinos
> and just let each audrino grab the last 5 bytes of the control packet
> and send the remaing bytes to the next device. Addressing is by the
> position of the data in the packet.
> He has no error control, but the idea of all the devices running the
> same code is what your looking for.

The code is trivial.  The question concerns identifying "issues"
to which this approach might be more vulnerable (see above).

For example, if messages "dissipate" when they reach their intended
node, then nodes at the far end see much less traffic than near-end
nodes.  They spend less resources processing (propagating) messages
than their upstream peers.  And, they also are slower to notice when
the network has *crashed*.

Etc.

On 5/4/2017 7:54 AM, Tim Wescott wrote:
> On Wed, 03 May 2017 23:14:09 -0700, Don Y wrote:
>
>> I want to push a bit stream through a series of *identical* devices and
>> have (identical) software running on each determine if that particular
>> device is being addressed, or not.
>>
>> It seems like the simplest way to do so is to require each device to
>> examine an address field in the packet and, if '0', assume the data that
>> follows is intended for its consumption.  If not, decrement the address
>> and pass the packet along.
>>
>> (I.e., the protocol would require a SERIAL_IN and SERIAL_OUT signals)
>>
>> Of course, this means a failure of any device renders those that follow
>> it inaccessible.  That's acceptable.
>>
>> It also means there is a latency proportional to the device address
>> inherent in the protocol.  Also acceptable (the data source can take
>> that into consideration when creating the message stream). And, the
>> incremental latency can be made pretty small.
>>
>> Another downside is the cost of updating data on *all* (multiple)
>> devices as this requires N messages.
>>
>> An alternate message format (or, a cleverer encoding of the above) could
>> be used to allow a single COMPOSITE message to be propagated in which a
>> node encountering a '0' address field strips the data that is intended
>> for its use and then reconstructs a message bearing a '0' address field
>> with the BALANCE of the data that it then passes to the next device, in
>> series.  In effect, letting each subsequent device strip off "its" data
>> before passing the remainder along.
>>
>> [When no data remains, the message dissipates]
>>
>> As such, you could "address" any set of contiguous addresses by creating
>> an initial message of the form:
>>      <first_target_ID> <first_datum> ... <last_datum>
>> where the number of data present in the message implicitly defines the
>> *last_target_id* relative to the first_target_id.
>>
>> Any problems with this sort of kludged encapsulation?
>
> I've done this, it worked -- the customer went through some personnel
> changes and the project died before it could get shipped, but cest la vie.
>
> I wouldn't overthink things vis-a-vis the composite message -- just send
> lots of little messages and be happy.  Complexity leads to bugs.

I've run some simulations with different protocol proposals.
The "cascaded messages" scheme is a win when number of nodes is high,
individual messages short (e.g., "ON", "OFF", "LEFT", "RIGHT", etc.)
and update rate high (or, time between updates short -- e.g., to support
a short keep alive interval).

So far, I've only looked at bit-oriented protocols, not "character-oriented".
But, I think character oriented would probably make things worse for the
individual-message-per-node case.

E.g., in one case, I have ~190 nodes and ~5 different message types.
The most common messages are coded in two bits (00, 01) while the less
common messages are in three (100, 101, 110, 111/unused).  So, in the
"common case", I can refresh the entire set of nodes with a single
7[addr]+(190*2)[data]+9[CRC] bit packet ... 396b total.

If, instead, I deliver individual messages to each of the 190 nodes,
I spend 190[nodes]*(7[addr]+2[data]+4[CRC]) = 2470b -- a bit more than
6 times the bandwidth (assuming a "free" means of detecting individual
message extents in each case).

I.e., a 2400 "baud" (but bit-oriented) link would allow for one update
per second instead of 6.

> Use all ones in the address field as a 'broadcast' address.
>
> Or do the address decrementing by shifting down one bit, and consider the
> message "yours" if the least significant bit is zero.  That only allows
> eight devices, but if you foresee a lot of traffic with identical
> messages for selected sets of devices, this would move you on down the
> road.

It doesn't scale well to larger "networks".  I'm presently looking at alternate 
ways of encoding the "destination/skip-over" address as well
as the potential for using a tagged message format -- so the protocol
layer wouldn't need to know anything about the "content" of the message
set.  This would allow me to use exactly the same code in different
applications and just have an up-call from the protocol handler to the
message decoder -- letting the protocol handler know how/when/what to
propagate without having to consult with the decoder in making that
decision.  Otherwise, the protocol layer code would have to understand
the content of the message(s) to determine what portion to forward along.