Electronics > Projects, Designs, and Technical Stuff
RS485 signalling characteristics - collisions
nctnico:
--- Quote from: Simon on May 09, 2020, 07:49:19 am ---Yes the micro controllers just read back in what is transmitted on the bus and if it does not match throws and error and interrupt. But this means that it is deemed acceptable to put both a 0 and a 1 on the same bus, how is that possible if each node is a push pull driver? that would result in a direct short circuit.
--- End quote ---
Current limiting in the driver will do the trick. HOWEVER RS485 busses may have a long cable in between. Say you have 4 devices A,B,C and D on a segment. A and B are 2 meters apart, B and C are 40 meters apart and C and D are 5 meters apart. If A and D are going to transmit at the same time chances are A and D read their own message back without error, B is receiving A just fine and C is receiving D just fine but C is not getting the message from A and B is not getting the message from D.
There are 2 ways around this: 1) expect an acknowledge from each node for each message (this can work for point-to-point messaging only) OR 2) have an arbiter in place which queries the devices and sends commands to them.
@MosherIV: RS485 is definitely to be used as a bus. The standard says there is a limit of 15 or 16 nodes but there are chips which support up to 128 nodes on a single RS485 bus (this has to do with bus loading). Another thing to keep in mind is that RS485 is just a differential, common ground electrical interface. You can use it for whatever signalling you want. When using the OSI layer model then layer2/layer3 has to deal with collissions / arbitration. I have used RS485 for a wide variety of signalling systems over the years.
Simon:
Yes I would work on the basis of a master slave network like lin. Master transmits instruction, slave replies. The SAMC UART with the bus collision is interesting though as coupled with a CAN transceiver instead of a RS485 one multi-master systems work fine.
ogden:
--- Quote from: Simon on May 09, 2020, 08:25:48 pm ---RS422 just splits transmission and reception to the master, it is still master slave.
--- End quote ---
I would avoid saying so. Your statement is corret in case of bus topology when there is more than two devices. Often rs422 is used as UART extender to connect two nodes over longer distances. In such case there is no need for master nor arbitration, it can be just plain bidirectional UART.
Simon:
Yes OK, I am looking at this from a multidrop point of view.
Doctorandus_P:
With RS485 both the "A" and the "B" wire are push pull outputs.
If multiple RS485 drivers are sending on the same bus at the same time you have a collision, and this can not be detected reliably by reading back the data at the transmitting point.
RS485 can still detect valid logic levels at 50mv to 100mV or so, and usually the wiring resistance is high enough that each RS485 transceiver reads it's own data back even during a collision.
CAN has an "active" and a "passsive" state. In the passive state the 2 lines have a very low differential voltage, because the bus is not driven, and the bus resistors pull the lines together. In the active state, one line is pulled high, and the other low. In can signalling, when one or more transceivers are sending an "active" state, the whole bus is in the "active" state. Because of this, collisions can be detected reliably on a CAN bus, and if a node backs of fast enough, the "highest priority" message can pass undamaged even during a bus collision. To be "fast enough" the collsion detection is often done in hardware. There are limits to the effectiveness of this depending on bitrate and wirelength (Time for the signal to travel the wire, compared to bit time).
So you need to avoid this situation.
I use RS485 with uC's (and their uart as data provider), and I do it on a "multi-master" bus.
I use collision avoidance and it works very good. I once did a test with sending over a million packets over RS485 in less than half an hour, and I had less than a handfull of damaged packages.
My collision avoidance works as follows:
Every time a node wants to send a message, it listens for 9 bit times (&115k2) for silence on the bus. If the bus is active, it backs off to try later. If the bus is Idle for 9 bit times, then it assumes it is safe to send, and it sends the start bit of the first byte as quick as possible. There is <500ns between the last idle check and sending the start bit, so there is a very small chance 2 transmitters start sending in that same time window.
For real high baud rates you also have to correct for signal speed in long cables.
As a second measure I have 16 bit CRC's on each packet, which is also standard good practice. For simple nodes I just spit out messages when they need to. For other nodes with more important data, there is an automatic re-transmit if no answer is received in a certain time frame.
A very common mistake with RS485 (and CAN) is to just use 2 wires. A proper GND level is required to keep the common mode of the signal wires within -7 to 12V.
There are some very good application notes "out there" for RS485. One of the best is the "10 ways to bullet proof RS485". It's old, but still very good. It was either from National Semiconductor or from Ti.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version