Multi-master RS485

[pozz]

Are there any *real* implementation of multi-master half-duplex RS485 bus?

I often use half-duplex RS485 and I always use a master-slave polling
protocol. This choice dramatically reduce the complexity of the system
and it works well with a limited number of nodes.

When the nodes are 10 or 20 and they usually send only a few bytes in a
minuted, the polling scheme is inefficient. The bus is alway busy for
polling, but the real data are very small.

I'm thinking to "improve" this bus with a multi-master approach, but it
doesn't appear simple. Do you know of real and working implementation of
this type on half-duplex RS485 bus?

[Don Y]

Sure! An easy way is to time-division-multiplex the bus and assign
specific slots to specific nodes.

You can also use a token-passing protocol to select the next master.

You have to address start-up issues to initialize the first
set of accesses. And, you have to include provisions to handle
the case where things go wonky and resynchronization becomes
necessary.

But, you *can* handle things like a device failing to pass the token
or skipping its timeslot in the "normal" protocol.

Note that any approach requires pre-configuration; you can't just
arbitrarily add nodes to the bus and expect them to arbitrate
access (like CD/MA).

[This is a minor lie -- but, autoconfiguration is not trivial]

[Grant Edwards]

On 2021-03-25, Don Y <blocked...@foo.invalid> wrote:
> On 3/25/2021 9:27 AM, pozz wrote:

>> Are there any *real* implementation of multi-master half-duplex RS485 bus?

> Sure! An easy way is to time-division-multiplex the bus and assign
> specific slots to specific nodes.
>
> You can also use a token-passing protocol to select the next master.
>
> You have to address start-up issues to initialize the first
> set of accesses. And, you have to include provisions to handle
> the case where things go wonky and resynchronization becomes
> necessary.
>
> But, you *can* handle things like a device failing to pass the token
> or skipping its timeslot in the "normal" protocol.
>
> Note that any approach requires pre-configuration; you can't just
> arbitrarily add nodes to the bus and expect them to arbitrate
> access (like CD/MA).
>
> [This is a minor lie -- but, autoconfiguration is not trivial]

Since the OP didn't specify async UARTs, I might mention that you can
CAN controllers with a half-duplex RS485 physical layer but it's a bit
of hack and easier to just use real CAN transceivers.

--
Grant

[pozz]

Il 25/03/2021 17:33, Don Y ha scritto:
> On 3/25/2021 9:27 AM, pozz wrote:
>> Are there any *real* implementation of multi-master half-duplex RS485
>> bus?
>>
>> I often use half-duplex RS485 and I always use a master-slave polling
>> protocol. This choice dramatically reduce the complexity of the system
>> and it works well with a limited number of nodes.
>>
>> When the nodes are 10 or 20 and they usually send only a few bytes in
>> a minuted, the polling scheme is inefficient. The bus is alway busy
>> for polling, but the real data are very small.
>>
>> I'm thinking to "improve" this bus with a multi-master approach, but
>> it doesn't appear simple. Do you know of real and working
>> implementation of this type on half-duplex RS485 bus?
>
> Sure!  An easy way is to time-division-multiplex the bus and assign
> specific slots to specific nodes.

This means assigning a predefined slot duration for each node. What
happens if a node wants to transmit a big packet? It should split packet
in multiple consecutive slots.

Moreover, is time-division-multiplex efficient? Now with master-slave
polling mechanism I already have a time-division-multiplex: for each
slave there's a time window in which master sends the token and slave
reply with token (and probably data).
With a pure time-division-multiplex I will save only the time of the
master request.

>
> You can also use a token-passing protocol to select the next master.

Same, each node is an "active" node in every loop. I imagine a bus that
is idle for most of the time and busy only when a node wants to transmit
something.
In my case real data are very low. Anyway I have to face the event of a
conflict.

> You have to address start-up issues to initialize the first
> set of accesses.  And, you have to include provisions to handle
> the case where things go wonky and resynchronization becomes
> necessary.
>
> But, you *can* handle things like a device failing to pass the token
> or skipping its timeslot in the "normal" protocol.

This is why I'm searching a "ready-to-use" protocol, if any.

[Don Y]

CAN is considerably more flexible, in that regard.

The OP can (if the application lends itself) just create one
big "frame" initiated by the master and let all of the slaves
slip their contributions in at the appropriate places
(without having to formally take ownership of the bus) as
well as peeling-off any data intended for their consumption.

But this seems like a design decision that should have been
made early on; not shoehorned in after the design has begun!

[upsid...@downunder.com]

On Thu, 25 Mar 2021 17:27:34 +0100, pozz <pozz...@gmail.com> wrote:

>Are there any *real* implementation of multi-master half-duplex RS485 bus?

For instance Profibus-DP. Usually one master is used for real-time
data, while the other is mainly used for configuration. A token is
passed between masters, so each master knows when it is allowed to
access the slaves.

[Don Y]

On 3/25/2021 9:57 AM, pozz wrote:
> Il 25/03/2021 17:33, Don Y ha scritto:
>> On 3/25/2021 9:27 AM, pozz wrote:
>>> Are there any *real* implementation of multi-master half-duplex RS485 bus?
>>>
>>> I often use half-duplex RS485 and I always use a master-slave polling
>>> protocol. This choice dramatically reduce the complexity of the system and
>>> it works well with a limited number of nodes.
>>>
>>> When the nodes are 10 or 20 and they usually send only a few bytes in a
>>> minuted, the polling scheme is inefficient. The bus is alway busy for
>>> polling, but the real data are very small.
>>>
>>> I'm thinking to "improve" this bus with a multi-master approach, but it
>>> doesn't appear simple. Do you know of real and working implementation of
>>> this type on half-duplex RS485 bus?
>>
>> Sure! An easy way is to time-division-multiplex the bus and assign
>> specific slots to specific nodes.
>
> This means assigning a predefined slot duration for each node. What happens if
> a node wants to transmit a big packet? It should split packet in multiple
> consecutive slots.

Or, the next node defers claiming it's timeslot until it senses the bus has
gone idle.

You have to decide how much you want to put in the lower level protocol
and how much you're willing to put *above* it (e.g., packet reassembly)

> Moreover, is time-division-multiplex efficient? Now with master-slave polling
> mechanism I already have a time-division-multiplex: for each slave there's a
> time window in which master sends the token and slave reply with token (and
> probably data).
> With a pure time-division-multiplex I will save only the time of the master
> request.

It depends on how big your packets are, how high the bus utilization, etc.
Only *you* can make that determination, from *your* application.

>> You can also use a token-passing protocol to select the next master.
>
> Same, each node is an "active" node in every loop. I imagine a bus that is idle
> for most of the time and busy only when a node wants to transmit something.
> In my case real data are very low. Anyway I have to face the event of a conflict.

If there is nothing to transmit, a node just sends a "keep alive" packet.
This also lets other nodes know that the network (and other devices on it)
are intact.

[When should a node "get nervous" that it hasn't been polled, "recently"?]

>> You have to address start-up issues to initialize the first
>> set of accesses. And, you have to include provisions to handle
>> the case where things go wonky and resynchronization becomes
>> necessary.
>>
>> But, you *can* handle things like a device failing to pass the token
>> or skipping its timeslot in the "normal" protocol.
>
> This is why I'm searching a "ready-to-use" protocol, if any.

Dunno. I always roll a protocol that is appropriate for the
application. That lets me tailor it to get the best performance
for the cost invested. (my designs are closed so I don't have
to worry about something being *added*, arbitrarily, at a later
date)

The exercise of thinking about the protocol often reveals
vulnerabilities in the design; "what if node X doesn't
take its time slot? what does that mean for the system,
as a whole? should the other nodes be able to independantly
detect this and bring the system to a safe/secure state
WITHOUT waiting for the master to command them to do so?"

(what does it *mean* when X is misbehaving?)

[David Brown]

The first CAN transceivers were basically RS-485 transceivers with the
CAN TX line connected to the driver's transmit enable input, the
driver's receive enable always on, and the driver's data in line
connected to 0.

You can also use UARTs along with CAN transceivers. (I worked with a
propriety protocol like that a good while ago - it was a slightly odd
bus that evolved gradually from a Dallas one-wire bus.)

[anti...@math.uni.wroc.pl]

pozz <pozz...@gmail.com> wrote:
> Are there any *real* implementation of multi-master half-duplex RS485 bus?
>
> I often use half-duplex RS485 and I always use a master-slave polling
> protocol. This choice dramatically reduce the complexity of the system
> and it works well with a limited number of nodes.
>
> When the nodes are 10 or 20 and they usually send only a few bytes in a
> minuted, the polling scheme is inefficient. The bus is alway busy for
> polling, but the real data are very small.

What do you really want? That is what is your "efficiency"
criterion. For embedded system a lot of folks consider
worst case delay. For normal design worst case is when
all nodes have data to transmit. Clearly, "last node"
have to wait on all previous nodes. So, best "efficiency"
would be sum of transmit times for data. On top ot that
you have various overhead: bus turnaround times, time
for polling or token passing, possible timeout in case
of fixed time slots. AFAICS polling messages from master
to slave may be very small, so they should at most
double time: you have twice as many messages compared
to case when each node "magically" knows when to
transmit. You can play some tricks, like group poll,
when nodes are ordered (numbered) and each node in
the group is supposed to send its data, starting from
first. Of course, it means that each node must be
capable of detecting end of transmission from
lower numbered node. Token passing may be slightly
more efficient, as data messages may serve double
duty of passing token to next node: so you save
cost of polling messages.

But you basically fight with constant factor of 2.
If you need more improvement, then you need bigger
change. Say faster links or star topology. In
star topology intermediate nodes may aggregate
messages, so you can significantly decrease number
of messages going to maser node. And it is easier
to provide fast links to limited number of "hub"
nodes, than to have fast links everywhere. But
as downside, there is more complexity and potentially
lower reliability...

--
Waldek Hebisch

[pozz]

Suppose you have a bus with 20-30 nodes: one master is the central unit,
the other are slaves that get a code from a keypad. When a code is typed
on the keypad, it is transmitted to the master. If it is ok, master
sends an ack to the slave that get the code so it enabled an electric
lock and the door is unlocked.

With a polling scheme, master must sends a poll request continuously and
the the slaves answer, most of the time, with no data. It appears to me
a very inefficient approach.

What's the worst case, i.e. the delay between pressing OK button on the
keypad and the door opening? It is the sum of 30 (number of slaves)
polling requests and replies. If a single request takes 100ms, the worst
case should be around 3 seconds.
I'd like to reduce this time to 100ms.

It is impossible with polling approach. However the bus is idle (without
real data) most of the time. I could avoid polling at all and instruct
the slave to transmit when it wants. I think the probability of a
conflict with another slave is very low and I could reach the
requirement of 100ms above. However I sholud design the behaviour with a
conflict, even rare, happens.

[Richard Damon]

The Problem is that RS485 is not designed with this sort of architecture
in mind. Yes,you could build a protocol which the slave listens first
and makes sure no one else is talking, Then send the message (with good
error detection built in) and see if it gets a response (maybe first an
ACK and then later an order to go ahead). If you don't get the ack, you
presume that your message got garbled so you send again after some
random wait designed that you and whoever you conflicted with won't send
again at the same time. MAybe even the master sends a NAK that it got
garbage.

Much better would be use a driver that can reliably detect a conflict
with known results. You send your message and listen for conflicts. If
you get a conflict you stop sending immediately.

If the system uses a driver where say 0 always wins over a 1, and the
bit time is longer than the network transmission time, then if two
drivers start at the same time, whoever send the first 0 when the other
wants to send a 1 will win and get their message through. The other
backs off, waits for the message and ack to clear, then does their message.

[anti...@math.uni.wroc.pl]

100ms for round trip looks very long. You should be able to
do with very short (3-4 bytes, maybe 8 if you add strong
cryptography) messages, so at 9600 even with delays for
turnaround you should be closer to 20-30 ms.

And I do not understand why you wait for OK? Typing on
keypad takes some time and it is likely that node will be
polled before number is finished. Then node can ask for
polling with shorter delay. If only small number of nodes
asks for more frequent polling, then master can respect
this giving you shorter effective response time. If
several (most of) keypads are busy, then clearly master
can not quickly serve all of them, but that is exactly
situation where nodes talking without polling would lead
to trouble.

> It is impossible with polling approach. However the bus is idle (without
> real data) most of the time. I could avoid polling at all and instruct
> the slave to transmit when it wants. I think the probability of a
> conflict with another slave is very low and I could reach the
> requirement of 100ms above. However I sholud design the behaviour with a
> conflict, even rare, happens.

You can bring down average, but worst case will be bad: in case
of conflict you need enough delay to significanlty reduce risk
of repeated conflict. And detection of conflicts may be
problematic. You may sell more, as during demo salesman
can arrange for no conflicts and clients will see best
case. But you may get bad publicity, as ocasional, much
longer than usual delay will look like malfunction.

--
Waldek Hebisch

[Don Y]

On 3/27/2021 4:37 PM, pozz wrote:

> Suppose you have a bus with 20-30 nodes: one master is the central unit, the
> other are slaves that get a code from a keypad. When a code is typed on the
> keypad, it is transmitted to the master. If it is ok, master sends an ack to
> the slave that get the code so it enabled an electric lock and the door is
> unlocked.
>
> With a polling scheme, master must sends a poll request continuously and the
> the slaves answer, most of the time, with no data. It appears to me a very
> inefficient approach.

That's because you are envisioning a request/ack per slave. So, the maximum
latency is O(Kn) and increases with increasing 'n'.

You can reduce K. Or, you could design the system so that the master
is not involved in that decision making process. E.g., the master can
*tell* each node whether it can respond to a local keypress by unlocking the
door -- and reporting that after-the-fact if the master needs to track that
info.

To reduce K, you can initiate a polling frame at t=0. Each node watches the
bus for I*L time (L being the time in which any lower numbered node can
reply; I being the ID of the current node).

Any node wanting the master's attention (or, wanting to tell the master
"yes, *my* keypad was activated!") seizes the bus at its timeslot and
generates an appropriate response. All nodes with "higher* IDs
add the time required for this response (which could be known /a priori/
if you can ensure replies to THAT type of polling request are always
a fixed duration) to the delay that they wait before taking *their*
turn.

You can also change the polling order (for individual polls *or* for
this sort of group poll) to reflect where you are most likely to
encounter slave requests. E.g., if node X has seen keypad activity,
recently, it may inherently be less/more inclined to see activity in
the near future.

For example, requests to access the janitorial supply closet may be
infrequent during *normal* occupancy. Requests to access the CEOs
office may be infrequent "afterhours" -- when the janitor's
activities are more commonplace.

You seem to be wanting a generic solution -- and then complaining that
it isn't very efficient for YOUR application!

> What's the worst case, i.e. the delay between pressing OK button on the keypad
> and the door opening? It is the sum of 30 (number of slaves) polling requests
> and replies. If a single request takes 100ms, the worst case should be around 3
> seconds.
> I'd like to reduce this time to 100ms.
>
> It is impossible with polling approach. However the bus is idle (without real
> data) most of the time. I could avoid polling at all and instruct the slave to
> transmit when it wants. I think the probability of a conflict with another
> slave is very low and I could reach the requirement of 100ms above. However I
> sholud design the behaviour with a conflict, even rare, happens.

Then you need to be able to detect collisions on the bus (e.g., CD/MA).
With EIA485, that's not always possible as the signal your node
"sees" isn't exactly the signal that every OTHER node is seeing.

At the very least, the master would have to be able to ensure the
bus returns to an idle condition that the protocol *enforces*...
so that it can then verify what it thinks just transpired.

And, other nodes (who may have competed for the wire -- and *apparently*
lost) can note that their messages were NOT heard (as evidenced by the
fact that the master replied to someone OTHER than them!)

[upsid...@downunder.com]

On Sat, 27 Mar 2021 20:14:54 -0400, Richard Damon
<Ric...@Damon-Family.org> wrote:

>On 3/27/21 7:37 PM, pozz wrote:

>> Suppose you have a bus with 20-30 nodes: one master is the central unit,
>> the other are slaves that get a code from a keypad. When a code is typed
>> on the keypad, it is transmitted to the master. If it is ok, master
>> sends an ack to the slave that get the code so it enabled an electric
>> lock and the door is unlocked.

Does the user have to press a single key or enter a multidigit access
code ?

In the latter case, do the access code processing locally including
feedback beeps and only send a complete sequence to the master. When
the user enters the first digit, answer to the master poll "data will
soon be arriving" i.e. there is a user at the slave. The master can
then poll those slaves more frequently which have users at the slave
and hence read the full access code with the frequent polls.

>> With a polling scheme, master must sends a poll request continuously and
>> the the slaves answer, most of the time, with no data. It appears to me
>> a very inefficient approach.
>>
>> What's the worst case, i.e. the delay between pressing OK button on the
>> keypad and the door opening? It is the sum of 30 (number of slaves)
>> polling requests and replies. If a single request takes 100ms, the worst
>> case should be around 3 seconds.
>> I'd like to reduce this time to 100ms.

The wire network must be huge, if you are forced to use 300 bits/s:-)

If you can use 9600 bits/s i.e. 1 ms character time and a 2 byte poll
and 1 byte Ack/Nak that takes 3 ms plus some additional time for Rx/Tx
and Tx/Rx delays. I would expect a 5 ms transaction time and 150 ms
poll cycle,

>> It is impossible with polling approach. However the bus is idle (without
>> real data) most of the time. I could avoid polling at all and instruct
>> the slave to transmit when it wants. I think the probability of a
>> conflict with another slave is very low and I could reach the
>> requirement of 100ms above. However I sholud design the behaviour with a
>> conflict, even rare, happens.
>
>The Problem is that RS485 is not designed with this sort of architecture
>in mind. Yes,you could build a protocol which the slave listens first
>and makes sure no one else is talking, Then send the message (with good
>error detection built in) and see if it gets a response (maybe first an
>ACK and then later an order to go ahead). If you don't get the ack, you
>presume that your message got garbled so you send again after some
>random wait designed that you and whoever you conflicted with won't send
>again at the same time. MAybe even the master sends a NAK that it got
>garbage.
>
>Much better would be use a driver that can reliably detect a conflict
>with known results. You send your message and listen for conflicts. If
>you get a conflict you stop sending immediately.
>
>If the system uses a driver where say 0 always wins over a 1, and the
>bit time is longer than the network transmission time, then if two
>drivers start at the same time, whoever send the first 0 when the other
>wants to send a 1 will win and get their message through. The other
>backs off, waits for the message and ack to clear, then does their message.

It sounds that you are trying to reinvent the CAN bus protocol ?

You can even use RS-485 transceivers chips (Data out to Transmit
enable, Tx input to fixed "0"). You need a CAN control chip, e.g.
SJA1000 for the master and some simpler for slaves. There are several
uCs with built in CAN controllers usable as slaves.

With CAN, there are some snags. The maximum net payload is 64 _bits_
(8 bytes) so if more data needs to be transmitted, you may have to use
some higher level protocols above CAN. The other snag is that all
stations must hear each other well within a single _bit_ time to
handle conflicts. This limits the length of the bus and/or maximum bit
rate that can be used e.g. 250 kbit/s with 250 m bus cable. At lower
speeds the range can be extended.

[Richard Damon]

On 3/28/21 12:32 AM, upsid...@downunder.com wrote:
> On Sat, 27 Mar 2021 20:14:54 -0400, Richard Damon
>

That methodology is used in CAN, it is also used in I2C, and I suspect
other systems. It is close to the method used for ethernet on coax (but
that uses a slightly different method because the line might be longer
than allowing collision detection in a single bit.

[upsid...@downunder.com]

The difference is that in coaxial Ethernet CSMA/CD collisions _both_
messages are lost and _both_ needs to be retransmitted at a later
time. In CAN bus, the higher priority message gets through despite a
collision, only the lower priority message needs to be retransmitted.
For this reason a much higher bus loading are possible in CAN, while
in Ethernet high collision rates will kill the traffic completely much
earlier.

The dominant/recessivebit protocol used in CAN may also be used with
other transports than RS-485 or dedicated CANbus transceivers. One
could even use with 20 mA current loop by putting all stations into
the sane current loop, but the optoisolator photo transistor Vce(max)
may limit the number of stations in the same loop to about a dozen.

[Richard Damon]

Yes, the Ethernet protocal loses the whole message because the bit time
isn't large comparared to the propagation delay across the system, so
you might not know of the collision until it is too late to get off.

CAN/I2C require a bit time longer than network propagation, so the
transmitter knows after the first collision that it has lost, and the
master that was sending the dominant bit gets control.

As you say, you can use dominant/recessive bit physical layer with many
protocals, even pure asynchronous serial (though that may need a bit of
external logic to get you off the bus before you corrupt the message,
like the 485 with data on the enable.

[Hans-Bernhard Bröker]

Am 28.03.2021 um 00:37 schrieb pozz:

> What's the worst case, i.e. the delay between pressing OK button on the
> keypad and the door opening? It is the sum of 30 (number of slaves)
> polling requests and replies. If a single request takes 100ms, the worst
> case should be around 3 seconds.
> I'd like to reduce this time to 100ms.

That will never be possible. If 30 those slaves simultaneously trigger
a request, then at least one of them will have to wait for the
communication to all the others to be done before it can get its reply.

The worst case for a bus of 30 slaves cannot possibly be exactly as
quick as the optimum case for a single slave.

The only way that could work is if there is no bus at all, but rather a
star topology: each slave has its own, dedicated connection to the
master. I'll assume that this untenable because of the cabling costs.

> It is impossible with polling approach. However the bus is idle (without
> real data) most of the time.

That makes no sense at all. If the bus is so idle, why are you polling
so slowly? Why would you poll at any less than the maximum possible
communication rate, while at the same being concerned about too long a
response time?

But I'll second upsidedown's hint: you appear to be trying rather
unnecessarily hard to reinvent CAN.

[Richard Damon]

On thing to note, if you are worried about WORSE case performance even
under full load, the synchronous polling is probably the best option. If
every keypad got the last key press at exactly the same time, the
shortest maximum delay would have the master go at full speed and
interrogate each slave and process it. This eliminates all the loses due
to conflicts and re-transmitting.

If you do use a CAN bus style arbitration, and can make the protocol not
lose frames in the case of a conflict, and the 'high priority' slaves
will wait long enough between mesages to give everyone a chance to send
their message, then that might get a bit faster as the amount thqt needs
to be sent is less, but the protocol overheads to wait to see the bus is
idle might eat that up.

The asyncronous messaging with arbitration is probably faster at
'average' delay under lighter loads. This is just the way these things
tend to work.

Another option is to use a dominate/recessive bus drive and the master
sense out a query request, and with a fixed timing any slave that has a
request replies with its address, and sees if someone else answer too,
and drops out on conflict. (This method is used on the SMB Bus). The
master can then poll at a base rate, and then if it gets a reply,
immediate ask for more requests until it gets a no request pending answer.

[pozz]

Many thanks to all of you that spent some time to answer my question.

Some additional details. The example I wrote is... just an example and
not exactly the real application. The system has a central unit and many
slaves installed in different places of a building (imagine a keypad, a
sensor and so on). This is a home/building automation application.

After first connection the master sends many configuration data to
slaves (around 2-4kB), so CAN bus is not ideal because of its small
packets (however I can split data on different packets).
Then the bus stays idle for most of the time. The user could interact
with a slave and only in that case the slave has something to tell to
the master.

Yes, you are right when you say that putting a known limit on the worst
case can be done with a polling approach. However my goal is not limit
the worst case, but minimizing the "normal"/mean delay in the
slave->master->slave transaction.
I know this mean of delays can be reduced a lot, because the bus is idle
most of the time, so the probability of a conflict is very very low.

Even number of slaves was just an example. I can think of systems with
50 or 100 slaves and in those cases the polling approach performance
would be very bad.

Do you know of real wired cable used in home/building automation? I
heard about KNX on twisted pair, but I think the complexity and cost of
the system would increase very fast.

[Don Y]

On 3/30/2021 3:34 PM, pozz wrote:
> Do you know of real wired cable used in home/building automation? I heard about
> KNX on twisted pair, but I think the complexity and cost of the system would
> increase very fast.

Ethernet and industrial variants. The cost of running the cable typically
far exceeds the cost of the device(s) placed along the cable!

And, bandwidth is sort of like disk space -- there's always SOMETHING
you can use it for!

[upsid...@downunder.com]

In CanOpen (a protocol built on CAN) has one option of transferring
127 x 7 bytes or up to 889 bytes before being acknowledged. These big
transfers run with low priority identifiers, so it does not delay high
priority messages during the big and slow transfer.

>
>Yes, you are right when you say that putting a known limit on the worst
>case can be done with a polling approach. However my goal is not limit
>the worst case, but minimizing the "normal"/mean delay in the
>slave->master->slave transaction.
>I know this mean of delays can be reduced a lot, because the bus is idle
>most of the time, so the probability of a conflict is very very low.
>
>Even number of slaves was just an example. I can think of systems with
>50 or 100 slaves and in those cases the polling approach performance
>would be very bad.

With standard 1 Unit Load (UL) RS-485 transceivers, you can only have
31 slaves on the bus. You would need 1/2 UL or 1/4 UL transceivers to
run such networks. It would be better to have multiple serial ports on
the master and split the network between them.

[Stef]

On 2021-03-31 upsid...@downunder.com wrote in comp.arch.embedded:
> On Wed, 31 Mar 2021 00:34:45 +0200, pozz <pozz...@gmail.com> wrote:

[RS485 home/building automation system]

>>
>>Even number of slaves was just an example. I can think of systems with
>>50 or 100 slaves and in those cases the polling approach performance
>>would be very bad.
>
> With standard 1 Unit Load (UL) RS-485 transceivers, you can only have
> 31 slaves on the bus. You would need 1/2 UL or 1/4 UL transceivers to
> run such networks. It would be better to have multiple serial ports on
> the master and split the network between them.

Splitting up the network may also make your cabling easier. If you use
a single 485 bus for the entire building, your single cable has to pass
every node and has to go in and out every room. And when installing
additional nodes, they have to be placed in te same loop. Cable length
will also be an issue with such a setup. A single break in the cable
disables the entire network and you have no easy way to determine where
to start looking for the fault.

With a single controller with multiple ports, you can poll all ports
simultaneously.

You can also create a tree network, but that requires additional branch
controllers. Have for example a central controller connected to the
trunk and then a branch controller on each floor/room. With 10 branch
controllers, the master only has to poll 10 nodes. And if you have 10
nodes on each branch, the branch controllers also have to poll only 10
nodes. So you still poll 100 end nodes, but in 1/10th of the time. And
because you require shorter bus cables, the baudrate can be increased
as well, further reducing required poll time.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Do you guys know we just passed thru a BLACK HOLE in space?

[David Brown]

CAN is a short-range protocol. If your bus is over about 20-30 m,
forget CAN. (People do use it for longer distances, at low speeds, but
it's horrible for the task. And CANOpen and other "standards" look like
they were designed specifically to be as complex and inefficient as
possible.) For a short range, small message bus on a closed network
entirely under your control, CAN is great.

>
> Yes, you are right when you say that putting a known limit on the worst
> case can be done with a polling approach. However my goal is not limit
> the worst case, but minimizing the "normal"/mean delay in the
> slave->master->slave transaction.
> I know this mean of delays can be reduced a lot, because the bus is idle
> most of the time, so the probability of a conflict is very very low.
>
> Even number of slaves was just an example. I can think of systems with
> 50 or 100 slaves and in those cases the polling approach performance
> would be very bad.
>

You should try to think about having multiple bus segments with fewer
nodes per segment, and some sort of aggregator or gateway that combines
them.

> Do you know of real wired cable used in home/building automation? I
> heard about KNX on twisted pair, but I think the complexity and cost of
> the system would increase very fast.
>

I think KNX is mainly used in lifts, but I'm not sure. There are a
large number of "standards" used for building automation, with a variety
of pros and cons, standardisation processes, membership fees,
complexities, etc.

As Don said, often the cost of the wiring is the real price. But that
can depend on where you are (the ratio of electrician hourly rate to
cable price per meter varies hugely around the world) and the stage the
building is at. Pulling one more cable while the building is being
constructed, is practically free. Installing hidden wiring in a
building in heavy use is massively expensive.

So sometimes using existing Ethernet networks, wireless networks (either
Wifi or a dedicated wireless network), or even power-line communication
can be cheaper than wiring.

If you want the newest and coolest solution, try two-wire Ethernet.
Long-range does 2 km point to point, while short range is (IIRC) 40 m on
a multi-drop bus - though I haven't seen any PHYs for short range
two-wire Ethernet as yet.

[pozz]

Do you mean 10BASE-T1L and 10BASE-T1S?

Actually my RS485 bus is wired without great care in normal condition:
star, bus, tree or mixed topology.

Does T1L support only point-to-point, i.e. star topology? Is the center
of the star a switch/hub with N ports?

T1S could be great because of multi-drop, but 40m can be limiting.

[pozz]

Il 31/03/2021 10:23, David Brown ha scritto:

Another question on 10BASE-T1L. What is the complexity of a single node?

Actually RS485 can be managed by a very cheap MCU with a simple embedded
UART and a very cheap external half-duplex transceiver.

What will I need to have 10BASE-T1L in a node? I think at the minimum an
Ethernet MAC and an external T1L transceiver.

[upsid...@downunder.com]

On Wed, 31 Mar 2021 10:23:43 +0200, David Brown
<david...@hesbynett.no> wrote:

>On 31/03/2021 00:34, pozz wrote:


>> After first connection the master sends many configuration data to
>> slaves (around 2-4kB), so CAN bus is not ideal because of its small
>> packets (however I can split data on different packets).
>> Then the bus stays idle for most of the time. The user could interact
>> with a slave and only in that case the slave has something to tell to
>> the master.
>
>CAN is a short-range protocol. If your bus is over about 20-30 m,
>forget CAN. (People do use it for longer distances, at low speeds, but
>it's horrible for the task.

If you try to run CAN at 1 Mbit/s it is quite critical with limited
distance and strict rules how long branches you can connect from the
main bus. Ideally the main bus should be routed through all nodes
without branch cables.

At 250 kbits/s you can still run about 250 m and the branch lengths
are not that critical. Should be sufficient for home automation,

>And CANOpen and other "standards" look like
>they were designed specifically to be as complex and inefficient as
>possible.)

CanOpen is great for setting up the system with EDS (Electronic Data
Sheet) or inquiring the node capabilities with SDOs request messages.

For real-time communication the PDOs are mapped directly to real-time
CAN-frames, so no performance issues.

>For a short range, small message bus on a closed network
>entirely under your control, CAN is great.

I assumed that the OP is designing both the master and slaves.

>> Yes, you are right when you say that putting a known limit on the worst
>> case can be done with a polling approach. However my goal is not limit
>> the worst case, but minimizing the "normal"/mean delay in the
>> slave->master->slave transaction.
>> I know this mean of delays can be reduced a lot, because the bus is idle
>> most of the time, so the probability of a conflict is very very low.
>>
>> Even number of slaves was just an example. I can think of systems with
>> 50 or 100 slaves and in those cases the polling approach performance
>> would be very bad.
>>
>
>You should try to think about having multiple bus segments with fewer
>nodes per segment, and some sort of aggregator or gateway that combines
>them.

I have designed both CAN as well as RS-485 networks with 60 - 100
nodes and in practice, most problems were related to the electro-
mechanical reliability of the cabling harnesses.

For this reason, it is a good idea to split the network into multiple
segments, each with own independent master.

If the master doesn't have sufficient number of serial ports one
solution is to connecting multiple Ethenet/RS-485 or Ethernel/CANbus
converters with ordinary Ethernet cabling and Ethernet switches. This
may also simplify RS-485 or CAN cable length issues by inserting the
converters closer to the nodes,

[David Brown]

Yes, that's it.

> Actually my RS485 bus is wired without great care in normal condition:
> star, bus, tree or mixed topology.

That can be fine, if the bus is short enough with a small enough loading
in comparison to the speed. (Another thing I have done long in the past
to make wiring easier is support auto-swapping of D+ and D-, correcting
some wiring errors automatically.)

>
> Does T1L support only point-to-point, i.e. star topology? Is the center
> of the star a switch/hub with N ports?
>

Yes, AFAIK. I haven't used it yet, however.

Of course you could have switches anywhere, giving you a tree just like
normal Ethernet.

You can drive power over the two lines as well.

> T1S could be great because of multi-drop, but 40m can be limiting.

It's hard to get /everything/ you want from a bus!

[David Brown]

On 31/03/2021 13:39, pozz wrote:
> Il 31/03/2021 10:23, David Brown ha scritto:

(Appropriate snipping makes Usenet much nicer!)

>> If you want the newest and coolest solution, try two-wire Ethernet.
>> Long-range does 2 km point to point, while short range is (IIRC) 40 m on
>> a multi-drop bus - though I haven't seen any PHYs for short range
>> two-wire Ethernet as yet.
>>
>
> Another question on 10BASE-T1L. What is the complexity of a single node?
>

It's 10 Mbps Ethernet. You need something that has an Ethernet MAC.

> Actually RS485 can be managed by a very cheap MCU with a simple embedded
> UART and a very cheap external half-duplex transceiver.

You'll need a few dollars for the MCU, and I think the PHY's are about
three dollars last I looked. Expect prices to come down as popularity
and competition increases. Ethernet on an MCU is not expensive these
days, but it's still a good deal more than RS-485.

>
> What will I need to have 10BASE-T1L in a node? I think at the minimum an
> Ethernet MAC and an external T1L transceiver.
>

Yes.

[David Brown]

On 31/03/2021 14:29, upsid...@downunder.com wrote:
> On Wed, 31 Mar 2021 10:23:43 +0200, David Brown
> <david...@hesbynett.no> wrote:
>
>> On 31/03/2021 00:34, pozz wrote:
>
>
>>> After first connection the master sends many configuration data to
>>> slaves (around 2-4kB), so CAN bus is not ideal because of its small
>>> packets (however I can split data on different packets).
>>> Then the bus stays idle for most of the time. The user could interact
>>> with a slave and only in that case the slave has something to tell to
>>> the master.
>>
>> CAN is a short-range protocol. If your bus is over about 20-30 m,
>> forget CAN. (People do use it for longer distances, at low speeds, but
>> it's horrible for the task.
>
> If you try to run CAN at 1 Mbit/s it is quite critical with limited
> distance and strict rules how long branches you can connect from the
> main bus. Ideally the main bus should be routed through all nodes
> without branch cables.

Yes.

You can be a little loser if you can impose some rules on the messages
you send (like avoiding collisions).

>
> At 250 kbits/s you can still run about 250 m and the branch lengths
> are not that critical. Should be sufficient for home automation,

I wouldn't want to rely on CAN for anything like that distance/speed
combination - my experience is not as good. However, there are all
kinds of details involved such as the type of cable, grounding, driver
power, EMC protection, etc.

Agreed.

[Don Y]

On 3/31/2021 4:39 AM, pozz wrote:
> Another question on 10BASE-T1L. What is the complexity of a single node?

There are lots of ways to evaluate complexity.

Your hardware costs (for the "slaves") will likely increase. You will
also likely incur the cost of a switch -- which may also impact deployment
logistics and costs (e.g., if you were hoping to daisy chain from one
node to the next NEARBY node, a switch forces duplication of cable).

You'll need an MCU with a MAC and, hopefully, external PHY interface.
Then, the actual PHY, itself.

Your software complexity will likely increase at the driver level.
Instead of a Linux "master" and /ad hoc/ slaves, you will likely run
something *like* Linux on the slaves, as well (to benefit from the
network stack).

OTOH, the whole polling issue becomes moot. It's just as easy
(and reliable/scalable) to have each "slave" act as initiator
when *it* wants to talk to the "master" (let's call it a "controller"
and them, "motes")

Depending on the power requirements of your motes, you may be able
to source power centrally (from the switch) and thus eliminate the
need for locally sourced power at each mote.

[It is incredibly liberating to be able to place a mote anywhere
that is convenient -- instead of having to make considerations
for how you'll access power. E.g., I have devices up at ceiling level,
inside walls, *above* the ceiling, etc. I have neither the
unsightliness of "power supplies" scattered all around -- nor the
regulatory issues (e.g., hidden boxes). Likewise, one less
aspect of an attack surface]

You may end up rethinking the application's feature set. E.g.,
perhaps you incorporate provisions for two-way audio (intercom)
between each mote and ????. Or, a fingerprint sensor -- with
the authentication performed by transferring the image to the
controller at the enhanced throughput available.

With (likely) more smarts at a mote, there are other options
available to enhance reliability. I.e., what happens when your
controller is not accessible (perhaps the network has been subverted
or the controller has crashed or the system is in overload)?

> Actually RS485 can be managed by a very cheap MCU with a simple embedded UART
> and a very cheap external half-duplex transceiver.

If your focus is exclusively on the (recurring) cost of comms, you
will end up chasing an /ad hoc/ bastardization of *some* protocol
to "make it work". You should, instead (IMO) think about what you can
do with a different capability suite.