RS485 signalling characteristics - collisions - Page 1
Forum section: electronics / projects

author: Simon
author_rank: Unknown
timestamp: May 08, 2020, 09:37:27 pm
content: I see that some micro controllers have an automatic bus collision detection which usually fires an interrupt for RS485 modes. So it has me wondering how the actual driving of an RS485 output works as two devices trying to put opposite states on the bus seem to be OK. CAN bus works in such a way, is RS485 the same? Is it a pull up/down resistor with opposing transistors so that the "dominant" state will prevail?I cannot actually find any information on the bus driving itself unlike with CAN. All the specs say is that you have +/- 0.2-1.5V output and that's that.

author: ogden
author_rank: Super Contributor
timestamp: May 08, 2020, 10:00:21 pm
content: Modern rs485 drivers have push-pull mosfet output. One datasheet that I know is SN65HVD76, look for "9.4.1 Equivalent Circuits". For MCU that does not have rs485 line driver built-in only way to detect bus contention - compare transmitted bits with received. Hope this helps.

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 07:49:19 am
content: 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.

author: Alti
author_rank: Frequent Contributor
timestamp: May 09, 2020, 08:24:31 am
content: Proper transceivers are short-circuit protected and as long as power dissipation is not exceeded and you won't start violating maximal ratings(-7V/+12V), she'll be fine.Quote from: SN65176B

author: ogden
author_rank: Super Contributor
timestamp: May 09, 2020, 08:26:17 am
content: Yes, contention is effectively "bus shorted" state. Most drivers have bus short-circuit protection, including one I mention. Usually it is implemented as thermal shutdown. In short: avoid rs485 collisions by design, pay close attention to device ID assignments so they do not match - using warnings and doublechecks for users. Further reading: TI have good rs485 driver datasheets and good appnote as well: "AN-1057 Ten Ways to Bulletproof RS-485 Interfaces". Good idea to test supply voltage ripple during bus-short early in the prototyping. Most likely you don't want whole device/circuit to brownout during rs485 short/contention.

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 09:09:41 am
content: OK so bus collisions are serious errors to be avoided not just part of an arbitration process like CAN bus.

author: ogden
author_rank: Super Contributor
timestamp: May 09, 2020, 09:23:38 am
content: Quote from: Simon on May 09, 2020, 09:09:41 amRight. Rs485 is not designated for multi-master/peer-peer communications with all the consequences.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 09, 2020, 12:19:57 pm
content: To be perfectly clear, RS-485 is the electrical signal only. What's transmitted, can be anything. Ethernet, asynchronous serial, synchronous serial, various "self clocking" codes, parallel (e.g. SCSI), etc. OSI layer 1, physical only.(Funny, I never thought about Ethernet and RS-485 together before, but the signal levels and bitrates are comparable -- 10BASE-T that is. Ethernet is of course an AC-coupled medium, but there's nothing stopping you from using a 422/485 transmitter to drive it, the coding is what controls DC balance.)Note that RS-422 is the always-on fixed direction (half duplex) version; RS-485 is identical but with transmit enable added, that's all. And RS-232 is a high voltage, low current, unbalanced mode, lower bitrate interface, etc.So as soon as you're talking about data, codes, arbitration -- you're onto OSI layer 2 at least (link layer). You can do whatever you want with that: you have the RS-485 transceiver's RX, TX and EN pins available for arbitrary use.Integrated RS-485 peripherals may integrate some of these features as well, which does lock them into particular kinds of links, but automating it as well so you don't need to think about frames, bytes or bits (as the case may be) in software. YMMV.If collision is detected as RX != TX, note that this depends on line length, because two PHYs right beside each other will tend to drive towards 0V differential, and yield bit errors, but with 10s of ohms of line between them, they'll dominate themselves and not detect bit errors. A more sophisticated PHY with current sensing could still detect this over reasonable distances (indeed, it could perform full duplex service, on a point-to-point link; but multi-drop may not be possible in such a mode), and maybe that's offered by some integrated PHYs, but I haven't seen any standalone chips that offer it.So it's much better, in general, to have a higher level communication protocol that controls who's talking and listening, to avoid collisions. Handle that however you like: token passing, addressing, etc.CANbus, solves this in basically the same way I2C does: using a one-way transmitter. Indeed, CAN was invented using a RS-485 transmitter plus diodes. Bus contention is much more detectable when the physical layer has features like this to support it, which in turn simplifies the link layer.Tim

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 12:33:17 pm
content: Yes the problem here is that I could not find information about how RS485 operates electrically and if it's designed to work with bus contention or if this is a serious error. CAN yes was designed to work that way. My understanding of CAN is that the lines float to 2.5V and that is "1" when a "0" is sent the lines are pulled apart buy open collectors. So if one node is transmitting a "1" it does not actually do anything so another node putting a "0" on the buss will not electrically be in contention only the software protocol will see this and deal with it.RS485 Is not very clear about idle states and how the lines are driven so I was wondering if they passively "float" to a "1" and then get hard pulled to "0" but apparently not and the only salvation is short circuit protection so yes you're right that this condition has to be programmed out in whatever higher level protocol.I expect the collision detection in the SAMC in only for serious errors or could be used if the "RS485" mode was being used with a different type oy line driver. I am finding that the various protocol support in the UART of the SAMC is rather flimsy. For example it will work as a LIN master but really that functionality amounts to automatically sending the break and sync field when an identifier is loaded into the data register which is really trivial functionality to go trumpeting when on the other hand i see no indication of functions for the required by the standard LIN slave like address recognition that would be more useful saving overheads.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 09, 2020, 12:38:40 pm
content: 485 is terminated, so the lines float to zero. Receiver threshold is usually slightly positive so this is received as zero, however there is little noise margin in this condition.Bias is often added (with resistor dividers) to improve this noise margin, keeping the line close to a logic-low condition at idle.Common mode, the lines also float towards zero, or something mid-supply, I forget exactly. The receivers sense line voltage with resistor dividers, which is how they achieve a wide (-7 to 12) input voltage range from a 3.3 or 5V supply, and why there is a limit to the number of receivers on a bus.Tim

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 12:45:08 pm
content: Yes but if the output drivers are H bridges as shown on some data sheets then clearly even an outputted "1" is being hard driven even if as idle the bus may sort of float there.

author: ogden
author_rank: Super Contributor
timestamp: May 09, 2020, 12:55:25 pm
content: Quote from: Simon on May 09, 2020, 12:45:08 pmEvery node including master have option to go into RX mode with TX driver in high impedance mode. So in theory bus can "float" indeed. Thou usually master is always in TX mode and goes RX only when slave is expected to TX. Could you give some hint - what rs485 will be used for?

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 01:04:02 pm
content: Oh I have no use for it here and now. I am just working my way through the UART capabilities on the SAMC. RS485 will be used on devices I work with at work so understanding it is good. I am also looking at Lin to better understand how to use the SAMC UART in lin mode as I will be working on that in the future.

author: MosherIV
author_rank: Super Contributor
timestamp: May 09, 2020, 08:11:40 pm
content: Hi Simon.I think RS485 is meant to be point to point not a bus, so it is not possible to have bus collision.If the system has multiple nodes, then each node must have an input and an output RS485.Each node must know if it is the node being communicated to or it must forward the data stream.RS422 is the bus version of RS485, no idea how it deals with bus collision, when I used it, we just used it as a RS485 protocol analyser, so the analyser did not cause bus collisions.

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 08:25:48 pm
content: RS422 just splits transmission and reception to the master, it is still master slave. It just means that as the master sends data the slave can send data back. Given that RS485 should not be expected to operate in collision mode it should also be a master slave system like lin.

author: nctnico
author_rank: Super Contributor
timestamp: May 09, 2020, 08:30:40 pm
content: Quote from: Simon on May 09, 2020, 07:49:19 amCurrent 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.

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 08:34:53 pm
content: 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.

author: ogden
author_rank: Super Contributor
timestamp: May 09, 2020, 08:35:53 pm
content: Quote from: Simon on May 09, 2020, 08:25:48 pmI 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.

author: Simon
author_rank: Unknown
timestamp: May 09, 2020, 08:37:36 pm
content: Yes OK, I am looking at this from a multidrop point of view.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: May 10, 2020, 12:22:00 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: May 10, 2020, 12:31:04 pm
content: If I was operating a multi master system I would probably time slot it which will be my suggestion on the upcoming system at work should we have the need. As I have seen suggested elsewhere giving each node an Id that is also a time point for each device to spontaneously transmit. A regular transmission from the master can reset the clock so that drifting clocks are not a problem.I am slightly peeved that on SAMC the UART mode does not support activation by address recognition like the SPI mode of the same serial hardware does (SERCOM).Although the SERCOM in UART mode supports lin master it was not even thought of for a slave device as again address recognition would have been very useful.