Autodetect slave devices on a bus network (RS485)

I have a bus network (RS485 based) with one master and N slaves. Each slav e has a different unique 32-bits serial number.

I was thinking on a method for the master to autodetect the serial numbers of the connected slaves. Of course, the brute force method isn't acceptable for the time to test ALL the serial numbers.

A more intelligent approach could be to discover the serial numbers on a bi t basis (similar to 1-wire discovery algorithm).

Starting from bit 0, the master could send a broadcast request: are there s laves with bit 0 set to 1? If the serial number matches the request, the sl ave answers with its complete serial number. If no answer is detected, the result is simple: all the serial numbers have the bit 0 set to 0. If N corrected answers are received (so they don't overlap), the master has detected N slaves. If some bytes are received, but the message isn't correct, most probably mo re than one slave has a serial number with the same characteristic (bit 0 t o 1) and the answers are overlapped. The master should move to bit 1 to sol ve the collision, sending a request similar to the following: are there ser ial numbers with bits 1-0 set to 1-1? And so on...

Do you think this could work in a real situation? Are there implementations similar to this?

Are there other better methods to implement an auto-discovery feature?

Reply to
Loading thread data ...

I think you have to consider the situation where several slaves reply together, but one "wins" (because it has stronger drivers or is closer). So that replies get lost without any error detected.

You could build in a random reply time delay element (seeded with the serial number perhaps).

Or consider switching to CAN if that is still possible, which has arbitration built-in.


John Devereux
Reply to
John Devereux

If you get a clean response, this slave should be locked out (not respond) to any further searches.

You may have to run this bit search a few times, each time locking out any successful matches, until there are no conflicts.

Regarding collisions, with some CANbus style dominat/recessive style RS-485 like communication, it should be possible to detect one station correctly and lock it out from the search and try again.

Reply to

Yes, if two slaves answer at exactly the same time, this could be a problem . One answer could hide the other.

As you suggest later, I can add a delay (calculated from the serial number) to the answer, but there's a not-null probability the delay time for two s laves on the bus are the same. So those slaves will answer always at the sa me time and the problem remains.

I have to use a RS485.

Reply to

Not really. If you make the backoff unit time greater than the reply message length / time, then you guarantee that reply frames never overlap, assuming that all serial numbers are unique...


Reply to

A much better way is to stick closer to the 1-wire discovery algorithm.

First, ask on the bus if there are any slaves with 0 in bit 0. All slaves that want to answer, should check the bus for communication (i.e., check that they are not currently reading a byte, and check that the UART start bit is not on the line already). If the bus is free, they start sending with a fixed "Yes" reply. If the slaves are fast enough (in comparison to the baud rate), then there should be no problems with overlap - any slaves that are a bit late compared to other repliers will keep quiet, and if there are several "winners" in the reaction time race, then each sends an identical message and there is no corruption.

If the master sees any "Yes" replies, then it knows there is at least one node on the bus with 0 in bit 0. It then asks if there are any slaves with 00 on the first two bits. Suppose there are no replies within the timeout - then it knows 00 is a dead-end. It can ask for 01 and search down that tree branch. You continue in this way, doing a depth-first search until you have identified all nodes (each at a depth of 32 down the tree). Whenever a node has been fully identified, the master sends a "shut up for now" message specifically to that node, so that it does not reply to the rest of the search.

The slaves never send their serial numbers - they only send a "Yes" message - this keeps the replies corruption-free. The serial numbers are found by the search mechanism.

Alternatively, you might consider allowing corruption - slaves should send "Yes", immediately followed by their serial number and a CRC check. If only one (still unidentified) node exists in the current branch, then the CRC should pass - you can confirm it when you send a "shut up for now" message (if this fails, you've hit an unlucky corruption). If two or more nodes are on the branch, the CRC will most likely be corrupted and you continue with your bit-search.

Reply to
David Brown





Are you sure?

A message of 8 bytes on a 9600bps bus takes 80 / 9600 = 8.33ms. If I use

10ms as the delay step (as you suggested, a little bigger than the message length) and the delay must be different for each serial number, I will have a maximum delay of 2^32 * 10ms = 42 million of seconds!!!

If the delay is only derived/calculated from the serial number, the probabi lity to have two slaves with the same delay on the bus is not null.

Reply to

Do you think this approach works well? I never tried to check the bus statu s before sending a message. Can a long cable (100meter) cause some problem with this method? Consider the bus is running at 9600bps.

Good suggestion. I'll try to think to the best solution.

It's strange this kind of descovery mechanism isn't already implemented.

Reply to

Depends on how many nodes you have on the network. Is it really necessary to have the address defined as 2^32, or would fewer bits returned get the job done ?. It's a bit of an extreme example.

You have to design the address protocol to suit the expected number of nodes + a margin and the latency of the network. Design is about optimising this juggling act :-)...


Reply to

try a "binary search" on address space:

the master must be able to send request of this kind:

"Is there ANY slave with address between Value1 and Value2 ?"

the slaves reply with a break on serial port ( long low signal ) if the address match the range

start with request with Value1=0 and Value2=0xffffffff

next step is ( low half ) Value1=0 and Value2=0x7fffffff and ( upper half ) Value1=0x80000000 and Value2=0xffffffff

and so on

if no slave reply for a request the block is empty if ( at least ) a slave reply for a request the block is not empty and the interval must be halved and visited

Reply to

If you are allowed to set the TX/DE on the slaves in I/O mode, you could just send an acknowledge level. Or use the UART break function to send an ACK instead. The fixed level prevents colision problems when your slaves are not fast enough in comparison with the bitrate.

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

Charm is a way of getting the answer "Yes" -- without having asked any 
 Click to see the full signature
Reply to

100 m is not long, and 9600 is not fast.

With 100m, the propagation delay will be a few microseconds (depends on the capacitance and inductance of the line, of course), while a bit time is 100 us at 9600 baud. So you should have no problem with the this bus.

As a rule of thumb, if CAN can work on the bus, then this sort of bus status checking should work (again, assuming the slave microcontrollers are fast enough that there is no significant delay between checking the state of the line as a GPIO input, and starting the UART transmission). At 100 m, CAN runs fine at 500 kBaud.

It /is/ already implemented - I have used it in an application. (For weird "historical" reasons, the bus had CAN drivers rather than RS-485 drivers, but used UARTs rather than CAN controllers. That bus ran with several hundred meters at 38400 baud.)

Reply to
David Brown

BTW: Please limit your line length to 70 characters.

It would be also a problem, if two slaves answer at different time, because they will try to drive the bus to opposite levels causing high currents, reflections, corrupted UART frames.

...unless the delay step is larger than the bus delay. But you can't wait so long.

that's the problem. As I wrote already in "RS485 bus and auto-addressing" 2013-04-29, EIA485 likely is not a good choice for your application.


Oliver Betz, Munich is broken, use Reply-To:
Reply to
Oliver Betz

If you can reliably detect that overlapping responses have occurred (either by detecting gibberish - bad CRC, formatting, etc. - or line noise - framing errors, etc.), this isn't too hard.

Broadcast an "identify" a query, with a range of addresses, initially the whole address space. Any device with an address in the specified range should respond. If you get one good response (or several, if you're timing constraints allow that), life is good, record those and move on. If, OTOH, you get an error, divide the range in half, and resend the query for the half range. Continue the binary-like search until each range returns either nothing, or good responses. Of course you have to probe both sides of the division.

You need to allow enough time between queries to allow the line to settle (IOW, the slowest possible response plus a bit).

At worst that will run in O(m*n), where m is the number of devices to be found, and n is the number of bits in the address space. Actually I think for cases where both n and m are not close to unity, the runtime has to be considerably smaller than that.

For robustness, you need to have a little chat with each device to verify it's existence after you've found it, and then you should tell each found device to stop responding to ident queries. And then repeat the whole process a few times (starting with the "whole address space" query).

If you can't detect collision reliably, but with some probability, an appropriate number of repetitions would allow you to reduce the probability of missing a device to an arbitrarily low value. This assumes that there are no systemic problems that would prevent you from ever detecting a collision between two specific devices (explicitly adding some random timing jitter to the responses may help with that).

Reply to
Robert Wessel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.