1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by pozz, Mar 24, 2013.

  1. pozz

    pozz Guest

    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, Mar 24, 2013
    #1
    1. Advertisements

  2. 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, Mar 24, 2013
    #2
    1. Advertisements

  3. pozz

    pozzugno Guest

    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, Mar 25, 2013
    #3
  4. 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, Mar 25, 2013
    #4
  5. 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
     
    Vladimir Vassilevsky, Mar 25, 2013
    #5
  6. pozz

    upsidedown Guest

    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.
     
    upsidedown, Mar 26, 2013
    #6
  7. 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.
    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, Mar 26, 2013
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.