I have a large group (hundreds) of switches and displays.Their state needs to be determined/updated rather slowly(a few hertz). Each has local smarts so it can retainsome state information and processing capability.Their physical arrangement variesfrom one installation tothe next. So, there is no economy of scale available by"settling" on a specific configuration or physical arrangement.I would like to be able to address them (the entire *set*) -- andpass data to/fro -- with a small, fixed number
CAN network?
On 6/24/2025 9:18 AM, Martin Rid wrote:
CAN network?
Each CAN node either needs a unique address to which messages can be directed; *or*, to KNOW to listen for particular BROADCAST messages.
So, you either send a message to node 5 to do something
OR, you send a message about that something and expect
that node to know that *it* should process that message.
If all of the nodes are *identical* (hardware and software),
there is nothing to distinguish one device from any other.
On 6/24/2025 9:49 AM, Don Y wrote:
On 6/24/2025 9:18 AM, Martin Rid wrote:
CAN network?
Each CAN node either needs a unique address to which messages can be
directed; *or*, to KNOW to listen for particular BROADCAST messages.
So, you either send a message to node 5 to do something
OR, you send a message about that something and expect
that node to know that *it* should process that message.
If all of the nodes are *identical* (hardware and software),
there is nothing to distinguish one device from any other.
By way of example, in the 70's, we would do "poor man's networking"
by daisy-chaining IDENTICAL devices with serial ports:
HOST---->[]----->[]---->[]----->[]
(each set of brackets represents a device with its serial input
on the left side and output on the right)
If I pass a message (from the host) of the form "1xxxxxx", the
first device receives the message, notices that it begins with
a '1' and assumes it is meant for it; the message is absorbed
by that device.
On 6/24/2025 9:49 AM, Don Y wrote:
On 6/24/2025 9:18 AM, Martin Rid wrote:
CAN network?
Each CAN node either needs a unique address to which messages can be
directed; *or*, to KNOW to listen for particular BROADCAST messages.
So, you either send a message to node 5 to do something
OR, you send a message about that something and expect
that node to know that *it* should process that message.
If all of the nodes are *identical* (hardware and software),
there is nothing to distinguish one device from any other.
By way of example, in the 70's, we would do "poor man's networking"
by daisy-chaining IDENTICAL devices with serial ports:
HOST---->[]----->[]---->[]----->[]
(each set of brackets represents a device with its serial input
on the left side and output on the right)
The point is, ALL of the devices are identical, run identical
software, etc. Their physical position in the chain determines
their "address".
Don Y <blockedofcourse@foo.invalid> wrote:
I have a large group (hundreds) of switches and displays.
Their state needs to be determined/updated rather slowly
(a few hertz). Each has local smarts so it can retain
some state information and processing capability.
Their physical arrangement varies from one installation to
the next. So, there is no economy of scale available by
"settling" on a specific configuration or physical arrangement.
I would like to be able to address them (the entire *set*) -- and
pass data to/fro -- with a small, fixed number of conductors /having
built them all identically/. The amount of data exchanged being
traded off vs. update rate for a given interface bandwidth.
The obvious "one wire" scheme would have a gazinta and cumzouta
for each device so the device could modify a serial bit stream
to account for its "position" in that stream.
I can pipeline processing between devices so the overall access
rate remains high (though latency obviously suffers).
But, a single device failure renders all downwind devices
inaccessible (or, possibly ALL devices, depending on implementation)
I'm looking at a two wire solution that piggybacks the data
stream on power and ground (those "two wires"). But, it
adds complexity to the devices (I want to keep them REALLY
small and dirt cheap)
Any existing schemes that allow this without the failure mode cited?
Philips I2c ?
I have a large group (hundreds) of switches and displays.
Their state needs to be determined/updated rather slowly
(a few hertz). Each has local smarts so it can retain
some state information and processing capability.
Their physical arrangement varies from one installation to
the next. So, there is no economy of scale available by
"settling" on a specific configuration or physical arrangement.
I would like to be able to address them (the entire *set*) -- and
pass data to/fro -- with a small, fixed number of conductors /having
built them all identically/. The amount of data exchanged being
traded off vs. update rate for a given interface bandwidth.
The obvious "one wire" scheme would have a gazinta and cumzouta
for each device so the device could modify a serial bit stream
to account for its "position" in that stream.
I can pipeline processing between devices so the overall access
rate remains high (though latency obviously suffers).
But, a single device failure renders all downwind devices
inaccessible (or, possibly ALL devices, depending on implementation)
I'm looking at a two wire solution that piggybacks the data
stream on power and ground (those "two wires"). But, it
adds complexity to the devices (I want to keep them REALLY
small and dirt cheap)
Any existing schemes that allow this without the failure mode cited?
My goal
is just to "run wires" between devices and let the devices sort
it all out.
Don Y <blockedofcourse@foo.invalid> wrote:
[...]
My goal
is just to "run wires" between devices and let the devices sort
it all out.
I must admit this problem is a long way outside my comfort zone, but if
we postulate that all the devices are truly identical then the contoller
has no way of initially setting up the system. If it sends out a
request for a response, all the devices will respond virtually simultaneously and there will be no way of sorting out the resulting 'pile-up'
Even if the controller is clever enough to detect the nearest device on
the line, because its response arrives first, it has no way of telling
that device to assume a particular identity because the same identity
command will be picked up by all the other devices too. The problem
isn't one of which system to use, but whether an overall strategy can be developed to solve a problem that appears to be logically insoluble.
Having said that, there is one feature that could be used to distinguish between the devices before any address allocation has taken place, they
are all different distances from the controller.
If the controller sends out a pulse and every device responds instantaneously, the first response received back can trigger a second
pulse from the controller. The first device on the line will receive
the second pulse after a time which corresponds to twice its distance
from the controller and this can generate a number which the device
stores. The controller polls through the numbers sequentially from zero until the first device responds, the controller now tells the first
device to shut up and repeats the entire sequence so that the second
device is now the first one to respond.
This is repeated until each device along the line has a unique number
and has been muted.. The controller sends out a command to re-activate
all the devices and polls through the numbers again, listening for each device to respond individually. When a device responds it is allocated
a proper address and the network is gradually set up in this manner.
WS2812 LED chips do something like that. The first chip in the chain
absorbs the first three bytes and passes on all that come after, and
so on down the chain. Wait 50 us and the first chip in the chain is
ready again to intercept its three bytes.
On 2025-06-24, Jeroen Belleman <jeroen@nospam.please> wrote:
WS2812 LED chips do something like that. The first chip in the chain
absorbs the first three bytes and passes on all that come after, and
so on down the chain. Wait 50 us and the first chip in the chain is
ready again to intercept its three bytes.
That's not quite how they work. The whole chain is one big shift register, (24 bits per device), with 1's and zero's being shifted along as broad
or narrow pulses. When the pulses stop for a while*, the 24 bits sitting
in the "shift register" are latched into the "DAC register" and the
colour changes.
I think I saw that there was some variant of the WS2812 that went into
a bypass mode on failure, to avoid breaking all that follow. Exactly what counted as failure wasn't clear.
* An intersting / irritating bug had the firmware not waiting long enough
(= at all) between sending updates, so although the string was buisily clocking data through it, nothing was happening on the lights. Getting the bit count wrong can produce some pretty patterns, if you like migraines.
I have a large group (hundreds) of switches and displays.
Their state needs to be determined/updated rather slowly
(a few hertz). Each has local smarts so it can retain
some state information and processing capability.
Their physical arrangement varies from one installation to
the next. So, there is no economy of scale available by
"settling" on a specific configuration or physical arrangement.
I would like to be able to address them (the entire *set*) -- and
pass data to/fro -- with a small, fixed number of conductors /having
built them all identically/. The amount of data exchanged being
traded off vs. update rate for a given interface bandwidth.
The obvious "one wire" scheme would have a gazinta and cumzouta
for each device so the device could modify a serial bit stream
to account for its "position" in that stream.
I can pipeline processing between devices so the overall access
rate remains high (though latency obviously suffers).
But, a single device failure renders all downwind devices
inaccessible (or, possibly ALL devices, depending on implementation)
I'm looking at a two wire solution that piggybacks the data
stream on power and ground (those "two wires"). But, it
adds complexity to the devices (I want to keep them REALLY
small and dirt cheap)
Any existing schemes that allow this without the failure mode cited?
I have a large group (hundreds) of switches and displays.
Their state needs to be determined/updated rather slowly
(a few hertz). Each has local smarts so it can retain
some state information and processing capability.
Their physical arrangement varies from one installation to
the next. So, there is no economy of scale available by
"settling" on a specific configuration or physical arrangement.
I would like to be able to address them (the entire *set*) -- and
pass data to/fro -- with a small, fixed number of conductors /having
built them all identically/. The amount of data exchanged being
traded off vs. update rate for a given interface bandwidth.
The obvious "one wire" scheme would have a gazinta and cumzouta
for each device so the device could modify a serial bit stream
to account for its "position" in that stream.
I can pipeline processing between devices so the overall access
rate remains high (though latency obviously suffers).
But, a single device failure renders all downwind devices
inaccessible (or, possibly ALL devices, depending on implementation)
I'm looking at a two wire solution that piggybacks the data
stream on power and ground (those "two wires"). But, it
adds complexity to the devices (I want to keep them REALLY
small and dirt cheap)
Any existing schemes that allow this without the failure mode cited?
On 2025-06-23, Don Y <blockedofcourse@foo.invalid> wrote:
A thought...
If you have a chain, you get the "downstream failure" issue.
If you have a bus, each device nees an address.
How about having both. Use the chain to assign addresses at power-up
or whenever, then use the bus for real communication. If the devices
have some NV storage, the address assignment can be a 1-off, so the
whole chain only needs to work "once" (assuming a dead device
just keeps quiet and doesn't kill the bus).
------ ----- ----- ----- -----
| | | | | | | | |
ctrlr |--------->| Dev |-->| Dev |-->| Dev |-->| Dev |-----> Chain
| | | | | | | | |
| ----- ----- ----- -----
| ^ ^ ^ ^
| | | | |
| v v v v
|<---------------------------------------------------> Bus
|
------
I am increasingly convinced that I need to just see if I can
find a (dirt cheap) MCU with built in (factory) serial number
and incrementally poll for S/Ns during network discovery.
Having the *factory* (manufacturer) guarantee the uniqueness
of these identifiers means I'd never have to worry about
duplicates or assigning identifiers, etc.
On 2025-06-24, Jeroen Belleman <jeroen@nospam.please> wrote:
WS2812 LED chips do something like that. The first chip in the chain
absorbs the first three bytes and passes on all that come after, and
so on down the chain. Wait 50 us and the first chip in the chain is
ready again to intercept its three bytes.
That's not quite how they work. The whole chain is one big shift register, (24 bits per device), with 1's and zero's being shifted along as broad
or narrow pulses. When the pulses stop for a while*, the 24 bits sitting
in the "shift register" are latched into the "DAC register" and the
colour changes.
On 6/25/25 14:41, Don Y wrote:
I am increasingly convinced that I need to just see if I can
find a (dirt cheap) MCU with built in (factory) serial number
and incrementally poll for S/Ns during network discovery.
Having the *factory* (manufacturer) guarantee the uniqueness
of these identifiers means I'd never have to worry about
duplicates or assigning identifiers, etc.
Like the one wire DS2401 digital serial number?
If the controller sends out a pulse and every device responds instantaneously, the first response received back can trigger a second pulse from the controller. The first device on the line will receive
the second pulse after a time which corresponds to twice its distance
from the controller and this can generate a number which the device
stores. The controller polls through the numbers sequentially from zero until the first device responds, the controller now tells the first
device to shut up and repeats the entire sequence so that the second
device is now the first one to respond.
This is too "high tech". You're effectively trying to build a TDR into
each device. Recall, I want these to be dirt cheap because I use so many of them in a system.
This is too "high tech". You're effectively trying to build a TDR into
each device. Recall, I want these to be dirt cheap because I use so many of >> them in a system.
Actually the individual devices just need to store the time between two
clear digital pulses as a number. If the devices are never closer than
one yard apart, a 300 Mc/s clock speed will be sufficient to distinguish between them. (The twin identification pulses will be spaced by double
the path length.)
That programs each device with an unique address and the rest can be
done with normal digital handshaking and read/write. It is a way of overcoming the 'identicality' of the devices so you don't have to
allocate individual serial numbers to them during manufacture, which
could reduce the cost if a lot have to be made.
Then they can all be strung out along a two-wire bus (send and return)
to allow individual devices to be removed or changed without a lot of re-wiring or bridging connectors, so installation and maintenance costs
are reduced too..
On 6/26/2025 1:59 AM, Liz Tuddenham wrote:
This is too "high tech". You're effectively trying to build a TDR into
each device. Recall, I want these to be dirt cheap because I use so
many of them in a system.
Actually the individual devices just need to store the time between two clear digital pulses as a number. If the devices are never closer than
one yard apart, a 300 Mc/s clock speed will be sufficient to distinguish between them. (The twin identification pulses will be spaced by double
the path length.)
Sorry, this is a *display*. Even as oversized as it is (a few
square feet), it is quite possible that devices will be immediately
adjacent -- a fraction of an inch apart.
This is too "high tech". You're effectively trying to build a TDR into
each device. Recall, I want these to be dirt cheap because I use so
many of
them in a system.
On 6/25/2025 1:04 PM, Don Y wrote:
This is too "high tech". You're effectively trying to build a TDR into
each device. Recall, I want these to be dirt cheap because I use so many of
them in a system.
You could tile 'em. A local bus north west south and east with the main IO bus
on the perimeter.
Send outputs towards the edge using a greedy algorithm that only needs local state and if a tile has failed then route around it.
Don Y <blockedofcourse@foo.invalid> wrote:
On 6/26/2025 1:59 AM, Liz Tuddenham wrote:
This is too "high tech". You're effectively trying to build a TDR into >>>> each device. Recall, I want these to be dirt cheap because I use so
many of them in a system.
Actually the individual devices just need to store the time between two
clear digital pulses as a number. If the devices are never closer than
one yard apart, a 300 Mc/s clock speed will be sufficient to distinguish >>> between them. (The twin identification pulses will be spaced by double
the path length.)
Sorry, this is a *display*. Even as oversized as it is (a few
square feet), it is quite possible that devices will be immediately
adjacent -- a fraction of an inch apart.
I hadn't realised they were that close together. Obviously my
suggestion fir timing is a non-starter.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:11:55 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,058 |
| Messages: | 6,416,655 |