EmbeddedRelated.com
Forums
Memfault Beyond the Launch

RS485 bus with "non-true" fail-safe transceivers

Started by pozz March 24, 2013
I have manu SN75176 (www.ti.com/lit/ds/symlink/sn75176a.pdf) that I'd 
like to use to create a 2-wires RS485 bus with 10 nodes.

However this transceiver isn't true fail-safe, so the receiver, if 
enabled, has an undefined output (with wrong data received from the 
UART) if the inputs are open or shorted.

This is a 2-wires bus, so only one node transmits at one time.  After 
transmitting it disables the transmitter.  In the period from the 
disabling of the transmitter of one node and the enabling of the 
transmitter of another node, the bus is in high-impedance (idle) state.

Of course, I use resistors between the two wires of the bus (as 
illustrated in Figure 15 of the datasheet), but in idle state the 
receivers reads 0V so the output is undefined!

How this bus could work with transceiver like the SN75176?
pozz <pozzugno@gmail.com> writes:

> I have manu SN75176 (www.ti.com/lit/ds/symlink/sn75176a.pdf) that I'd > like to use to create a 2-wires RS485 bus with 10 nodes. > > However this transceiver isn't true fail-safe, so the receiver, if > enabled, has an undefined output (with wrong data received from the > UART) if the inputs are open or shorted. > > This is a 2-wires bus, so only one node transmits at one time. After > transmitting it disables the transmitter. In the period from the > disabling of the transmitter of one node and the enabling of the > transmitter of another node, the bus is in high-impedance (idle) > state. > > Of course, I use resistors between the two wires of the bus (as > illustrated in Figure 15 of the datasheet), but in idle state the > receivers reads 0V so the output is undefined! > > How this bus could work with transceiver like the SN75176?
You can bias the bus wires high and low (so it generates an idle state when not actively driven). <www.ti.com/lit/an/slyt324/slyt324.pdf> -- John Devereux
On Sunday, March 24, 2013 9:29:31 AM UTC+1, John Devereux wrote:
> pozz writes: > > > I have manu SN75176 (www.ti.com/lit/ds/symlink/sn75176a.pdf) that I'd > > like to use to create a 2-wires RS485 bus with 10 nodes. > > > > However this transceiver isn't true fail-safe, so the receiver, if > > enabled, has an undefined output (with wrong data received from the > > UART) if the inputs are open or shorted. > > > > This is a 2-wires bus, so only one node transmits at one time. After > > transmitting it disables the transmitter. In the period from the > > disabling of the transmitter of one node and the enabling of the > > transmitter of another node, the bus is in high-impedance (idle) > > state. > > > > Of course, I use resistors between the two wires of the bus (as > > illustrated in Figure 15 of the datasheet), but in idle state the > > receivers reads 0V so the output is undefined! > > > > How this bus could work with transceiver like the SN75176? > > You can bias the bus wires high and low (so it generates an idle state > when not actively driven). > > <www.ti.com/lit/an/slyt324/slyt324.pdf>
Thank you for the document. It is interesting. Anyway I'm asking why this kind of info doesn't appear in the datasheet of the transceiver.
pozzugno@gmail.com writes:

> On Sunday, March 24, 2013 9:29:31 AM UTC+1, John Devereux wrote: >> pozz writes: >> >> > I have manu SN75176 (www.ti.com/lit/ds/symlink/sn75176a.pdf) that I'd >> > like to use to create a 2-wires RS485 bus with 10 nodes. >> > >> > However this transceiver isn't true fail-safe, so the receiver, if >> > enabled, has an undefined output (with wrong data received from the >> > UART) if the inputs are open or shorted. >> > >> > This is a 2-wires bus, so only one node transmits at one time. After >> > transmitting it disables the transmitter. In the period from the >> > disabling of the transmitter of one node and the enabling of the >> > transmitter of another node, the bus is in high-impedance (idle) >> > state. >> > >> > Of course, I use resistors between the two wires of the bus (as >> > illustrated in Figure 15 of the datasheet), but in idle state the >> > receivers reads 0V so the output is undefined! >> > >> > How this bus could work with transceiver like the SN75176? >> >> You can bias the bus wires high and low (so it generates an idle state >> when not actively driven). >> >> <www.ti.com/lit/an/slyt324/slyt324.pdf> > > Thank you for the document. It is interesting. > > Anyway I'm asking why this kind of info doesn't appear in the datasheet of the transceiver.
That is "background" information that you are supposed to know about. Just like there is no amplifier design tutorial in the datasheet of a transistor. It would lead to massive duplication of material. Having said that I got bit by this the first time I implemented RS485. But that was a long time ago, before everything was a google search away. (Kids of today...) -- John Devereux
On 2013-03-25, pozzugno@gmail.com <pozzugno@gmail.com> wrote:

>>> Of course, I use resistors between the two wires of the bus (as >>> illustrated in Figure 15 of the datasheet), but in idle state the >>> receivers reads 0V so the output is undefined! >>> >>> How this bus could work with transceiver like the SN75176? >> >> You can bias the bus wires high and low (so it generates an idle >> state when not actively driven). >> >> <www.ti.com/lit/an/slyt324/slyt324.pdf> > > Thank you for the document. It is interesting. > > Anyway I'm asking why this kind of info doesn't appear in the > datasheet of the transceiver.
It's a surprise to you that if you want to make sure an undriven line floats to a certain state you should bias it with a pull-up or pull-down resistor? What are they teaching in universities these days? -- Grant Edwards grant.b.edwards Yow! I'm wearing PAMPERS!! at gmail.com
On 3/25/2013 9:15 AM, Grant Edwards wrote:
> On 2013-03-25, pozzugno@gmail.com <pozzugno@gmail.com> wrote: > >>>> Of course, I use resistors between the two wires of the bus (as >>>> illustrated in Figure 15 of the datasheet), but in idle state the >>>> receivers reads 0V so the output is undefined! >>>> >>>> How this bus could work with transceiver like the SN75176? >>> >>> You can bias the bus wires high and low (so it generates an idle >>> state when not actively driven). >>> >>> <www.ti.com/lit/an/slyt324/slyt324.pdf> >> >> Thank you for the document. It is interesting. >> >> Anyway I'm asking why this kind of info doesn't appear in the >> datasheet of the transceiver. > > It's a surprise to you that if you want to make sure an undriven line > floats to a certain state you should bias it with a pull-up or > pull-down resistor?
With or without pullups, a networked device should handle random garbage at the input at the protocol level. As well as check integrity of the packets. Vladimir Vassilevsky DSP and Mixed Signal Designs www.abvolt.com
On Mon, 25 Mar 2013 14:54:28 -0500, Vladimir Vassilevsky
<nospam@nowhere.com> wrote:

>On 3/25/2013 9:15 AM, Grant Edwards wrote: >> On 2013-03-25, pozzugno@gmail.com <pozzugno@gmail.com> wrote: >> >>>>> Of course, I use resistors between the two wires of the bus (as >>>>> illustrated in Figure 15 of the datasheet), but in idle state the >>>>> receivers reads 0V so the output is undefined! >>>>> >>>>> How this bus could work with transceiver like the SN75176? >>>> >>>> You can bias the bus wires high and low (so it generates an idle >>>> state when not actively driven). >>>> >>>> <www.ti.com/lit/an/slyt324/slyt324.pdf> >>> >>> Thank you for the document. It is interesting. >>> >>> Anyway I'm asking why this kind of info doesn't appear in the >>> datasheet of the transceiver. >> >> It's a surprise to you that if you want to make sure an undriven line >> floats to a certain state you should bias it with a pull-up or >> pull-down resistor? > >With or without pullups, a networked device should handle random garbage >at the input at the protocol level. As well as check integrity of the >packets.
Since we are talking about RS-485 and hence half duplex, any retransmission will degrade the troughput significantly, especially at high line speeds (due to various turn around delays), every means should be used to keep the bus in good condition. Even if a frame always starts with a known character and hence noise characters can be ignored, the problem is false start bits less than a character time before the frame, such as reflections from a previous frame, will completely garble the frame. One problem that really addresses these issues is Modbus RTU *IF* implemented according to the book. To send a frame, the first thing is to turn on the transmitter and actively drive it to the Idle/Mark ("1") state. Then you wait at least 3.5 character times, during which any reflections should die out and all receivers should see a healthy Idle/Mark. Only after this, there is the start bit Space ("0") of the first character in the frame. After the actual message has been transmitted and the stop bit Mark ("1") of the last character has been sent, the line remains actively driven in the Mark/Idle ("1") state for an additional 3.5 character times, effectively killing any reflections and also ensuring a reliable end of frame detection. Only after this, is the transmitter put into tri-state and let the line float. Thus, _if_ Modbus RTU is properly implemented, it should also work on networks that do not use fail-safe termination and even if the termination is done badly or the network topology is bad. Other protocols on the same network would most likely suffer more retransmissions.
On 2013-03-26, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> On Mon, 25 Mar 2013 14:54:28 -0500, Vladimir Vassilevsky > > One problem that really addresses these issues is Modbus RTU *IF* > implemented according to the book.
Unfortunately, it often is not. Many slave implementations seem to ignore the 3.5 byte-time requimrent and will answer immediately following a command. Even worse, I've run into masters that will send a command immediately after receiving the last byte of a slave response -- which, on a 2-wire system makes it hard for other slaves to determine where the command actually began.
> To send a frame, the first thing is to turn on the transmitter and > actively drive it to the Idle/Mark ("1") state. Then you wait at > least 3.5 character times, during which any reflections should die > out and all receivers should see a healthy Idle/Mark. Only after > this, there is the start bit Space ("0") of the first character in > the frame.
Of the implementations that do provide a 3.5 byte time gap, many of then don't drive the line to the Mark state during that gap -- they just don't transmit. It's a shame, because the gap requirement was actually a very clever idea. -- Grant Edwards grant.b.edwards Yow! Hey, waiter! I want at a NEW SHIRT and a PONY TAIL gmail.com with lemon sauce!

Memfault Beyond the Launch