2 wire rs485

"CBFalconer" <cbfalconer@yahoo.com> wrote in message 
news:4997712E.334F1406@yahoo.com...
> rickman wrote:
>> CBFalconer <cbfalco...@yahoo.com> wrote:
>>
> ... snip ...
>>
>>> Yes, it has a mechanism.  Is there an active signal on the bus.
>>> If so, set a protective delay (1 bit time for ASCII) before
>>> seizing the buss.
>>>
>>> RS-485 IS NOT a protocol.  It is a hardware spec.
>>
>> Exactly!  There is nothing in RS-485 to provide for this CTS
>> function.  There is no CTS function in any RS-485 chip I have
>> ever seen.  What hardware have you seen that generates a CTS
>> signal from the RS-485 bus?
>
> That's what you build, or select a chip (or chips) to do.  RTS/CTS
> is a provision for communicating with that hardware, not the other
> end of the hardware connection.

As I understand it CBF is talking about communicating using RS-485 
signalling controlled via RS-232 type signalling.
RS-485 is a multidrop shared serial bus with at most one node transmitting 
at any particular time. This means the protocol or hardware must provide for 
collision detection or collision avoidance. The RS-485 specification 
provides no help for collision detection not do I see a sane way to add it. 
In any case the RTS/CTS mechanism has to know whether it is safe to transmit 
before it started, so detection would be too late. Collision avoidance 
requires a mechanism for all nodes to agree on who can transmit next. This 
might be token passing, (addressed) half-duplex, central arbitration or the 
like. The RTS/CTS scheme could be implemented though a central arbitor over 
separate RS-485 lines but I think breaks the point of a shared bus. 
Alternative there needs to be a lower level protocol in which the RS-232 
data and signaling is embedded. Either way, the receiving end has to 
understand the added behaviour too.

Peter 

Peter Dickerson wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>
... snip ...
>
>> That's what you build, or select a chip (or chips) to do.  RTS/CTS
>> is a provision for communicating with that hardware, not the other
>> end of the hardware connection.
> 
> As I understand it CBF is talking about communicating using RS-485
> signalling controlled via RS-232 type signalling.
>
> RS-485 is a multidrop shared serial bus with at most one node
> transmitting at any particular time. This means the protocol or
> hardware must provide for collision detection or collision avoidance.
>
> The RS-485 specification provides no help for collision detection not
> do I see a sane way to add it. In any case the RTS/CTS mechanism has
> to know whether it is safe to transmit before it started, so
> detection would be too late. Collision avoidance requires a mechanism
> for all nodes to agree on who can transmit next. This might be token
> passing, (addressed) half-duplex, central arbitration or the like.
> The RTS/CTS scheme could be implemented though a central arbitor over
> separate RS-485 lines but I think breaks the point of a shared bus.
> Alternative there needs to be a lower level protocol in which the
> RS-232 data and signaling is embedded. Either way, the receiving end
> has to understand the added behaviour too.

Precisely.  That's why people have been talking about UART chips
having a serial shift register empty signal, which extends over the
stop bit, to settle when the line can be released.  

One technique that has been used is a central poller, who signals
each peripheral 'you can transmit now'.  If they do, they grab the
line.  If not, after a short delay the poller advances to the next.

If we bias the line correctly we can detect three states - zero
xmit, one xmit, no xmit (free) - by simply watching the line.  If
we are using an ASCII like code and are willing to give up a little
time, we can avoid the need for this.

Using the line cleanly requires thinking about the demands and
their timing.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Sat, 14 Feb 2009 10:13:39 -0000, "Peter Dickerson"
<first.last@REMOVEtiscali.co.uk> wrote:

>Could you share how you do failsafe biasing, R values etc. I'm designing 
>something with RS485 now...

The twisted pair line has a characteristic impedance between 100 and
120 ohms. The line should be terminated at both ends with the
characteristic impedance. Assuming that 100 ohm termination resistors
are used and since from DC point of view, the terminating resistors
are in parallel, the combined resistance is 50 ohms. 

The standard requires that the B input is 200 mV more positive than
the A input a 200 mV voltage difference is required in the terminating
resistors. Thus, a current 200 mV/50 ohm=4 mA totally must flow
through the two terminating resistors. 

Assuming Vcc=5 V, the voltage divider resistor total resistance must
be less than 5 V/4 mA=1250 ohm, of which 50 ohms are in the two
terminating resistors in parallel, thus the sum of the two bias
resistors is 1200 ohms. When biasing at Vcc/2 each bias resistor would
be less than 600 ohms.  Select one from the standard value series and
connect 560 ohms from Vcc to B input, the two 100 ohm terminating
resistors in parallel between B and A and a 560 ohm resistor from A to
Gnd.

The idle power consumption is just above 20 mW, which should not be an
issue in mains powered systems. The worst power consumption on a long
break signal situation in which A is ideally driven to Vcc and B to
Gnd would be 0,5 W in the termination resistor and 2x45 mW in the bias
resistors or totally 0,59 W, however, the output swing is smaller and
thus the currents in the resistors are smaller and also the total
power dissipation in the driver and resistors are less.

Paul

"Paul Keinanen" <keinanen@sci.fi> wrote in message 
news:k9dip4l48sbhq13ngueb032a6f99fqa94m@4ax.com...
> On Sat, 14 Feb 2009 10:13:39 -0000, "Peter Dickerson"
> <first.last@REMOVEtiscali.co.uk> wrote:
>
>>Could you share how you do failsafe biasing, R values etc. I'm designing
>>something with RS485 now...
>
> The twisted pair line has a characteristic impedance between 100 and
> 120 ohms. The line should be terminated at both ends with the
> characteristic impedance. Assuming that 100 ohm termination resistors
> are used and since from DC point of view, the terminating resistors
> are in parallel, the combined resistance is 50 ohms.
>
> The standard requires that the B input is 200 mV more positive than
> the A input a 200 mV voltage difference is required in the terminating
> resistors. Thus, a current 200 mV/50 ohm=4 mA totally must flow
> through the two terminating resistors.
>
> Assuming Vcc=5 V, the voltage divider resistor total resistance must
> be less than 5 V/4 mA=1250 ohm, of which 50 ohms are in the two
> terminating resistors in parallel, thus the sum of the two bias
> resistors is 1200 ohms. When biasing at Vcc/2 each bias resistor would
> be less than 600 ohms.  Select one from the standard value series and
> connect 560 ohms from Vcc to B input, the two 100 ohm terminating
> resistors in parallel between B and A and a 560 ohm resistor from A to
> Gnd.
>
> The idle power consumption is just above 20 mW, which should not be an
> issue in mains powered systems. The worst power consumption on a long
> break signal situation in which A is ideally driven to Vcc and B to
> Gnd would be 0,5 W in the termination resistor and 2x45 mW in the bias
> resistors or totally 0,59 W, however, the output swing is smaller and
> thus the currents in the resistors are smaller and also the total
> power dissipation in the driver and resistors are less.

Thanks for the info.

Peter 

It seems like everyone has their own way of making an RS-485
connection work in the real world.  This thread made me do a little
research on my own and I found that there is more than one way to skin
a cat (my apologies to any cat lovers out there).

The biasing technique that many recommend to provide "fail-safe"
operation should work in most circumstances.  But it does corrupt the
receiver threshold so that it is not within the spec any longer.  Of
course with the wide margins between driver and receiver voltages, it
is unlikely that this bias will affect most operations.

However, there are RS-485 chips available that will provide this fail-
safe function without external biasing.  The standard requires that
the thresholds for the receiver be within the range of -200 mV to 200
mV.  If the receiver threshold is actually within the range of -200 mV
to something less than 0 volts, then it will handle a shorted bus, a
terminated, but undriven bus or an open bus.  All of these conditions
will result in a high on the output of the receiver.  I found
National, TI and LTC all provide chips with this capability.

I also found the LTC1482 from LTC that will not only give a high
output on these conditions, but does have a detection for an undriven
bus.  If the voltage on the bus is in the range of the carrier detect
(-0.2 V min and 0.2 V max) the CD signal is removed and the receiver
output is held high.  When the receiver input is outside this range,
the CD signal is low and the receiver reflects the state of the bus.
So you can implement a CTS protocol (but not an RTS-CTS handshake) to
check for the bus being driven before you transmit.  This will also
detect a short on the bus when the driver is enabled.  Not only is
external biasing not needed with this device, it will mess up the
carrier detect function.

Rick

rickman wrote:

[...]

>The biasing technique that many recommend to provide "fail-safe"
>operation should work in most circumstances.  But it does corrupt the

BTW: I consider this a kludge to get a broken design running.

>receiver threshold so that it is not within the spec any longer.  Of
>course with the wide margins between driver and receiver voltages, it
>is unlikely that this bias will affect most operations.
>
>However, there are RS-485 chips available that will provide this fail-
>safe function without external biasing.  The standard requires that
>the thresholds for the receiver be within the range of -200 mV to 200
>mV.  If the receiver threshold is actually within the range of -200 mV
>to something less than 0 volts, then it will handle a shorted bus, a
>terminated, but undriven bus or an open bus.  All of these conditions

..with a miserable noise margin. That's IMO the worst problem of
RS485. I can't believe that the inventors of RS485 didn't consider the
idle bus.

CAN has much more noise margin. But many people don't understand that
the line doesn't need to be driven actively in both directions to get
decent speed.

And...

>will result in a high on the output of the receiver.  I found
>National, TI and LTC all provide chips with this capability.
>
>I also found the LTC1482 from LTC that will not only give a high
>output on these conditions, but does have a detection for an undriven

...you don't get three state transmission with CAN transceivers. But
I'm sure that very few people use this possibility really.

>bus.  If the voltage on the bus is in the range of the carrier detect
>(-0.2 V min and 0.2 V max) the CD signal is removed and the receiver
>output is held high.  When the receiver input is outside this range,
>the CD signal is low and the receiver reflects the state of the bus.
>So you can implement a CTS protocol (but not an RTS-CTS handshake) to
>check for the bus being driven before you transmit.  This will also

since there is no collsion detection, it won't work reliably. You need
some arbitration method in a higher layer.

>detect a short on the bus when the driver is enabled.  Not only is

_When_ do you detect the short if the short is 100m apart?

Disclaimer: I didn't read this thread completely, so please excuse if
I repeated something already said.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

On Feb 17, 3:22=A0am, Oliver Betz <ob...@despammed.com> wrote:
> rickman wrote:
>
> [...]
>
> >The biasing technique that many recommend to provide "fail-safe"
> >operation should work in most circumstances. =A0But it does corrupt the
>
> BTW: I consider this a kludge to get a broken design running.
>
> >receiver threshold so that it is not within the spec any longer. =A0Of
> >course with the wide margins between driver and receiver voltages, it
> >is unlikely that this bias will affect most operations.
>
> >However, there are RS-485 chips available that will provide this fail-
> >safe function without external biasing. =A0The standard requires that
> >the thresholds for the receiver be within the range of -200 mV to 200
> >mV. =A0If the receiver threshold is actually within the range of -200 mV
> >to something less than 0 volts, then it will handle a shorted bus, a
> >terminated, but undriven bus or an open bus. =A0All of these conditions
>
> ..with a miserable noise margin. That's IMO the worst problem of
> RS485. I can't believe that the inventors of RS485 didn't consider the
> idle bus.

There are other ways of mitigating noise.  RS-485 uses differential
signaling which helps a lot.  Twisted pair further reduces pickup of
noise.

> CAN has much more noise margin. But many people don't understand that
> the line doesn't need to be driven actively in both directions to get
> decent speed.

Can you explain that?  If both ends don't drive actively, what do they
do?


> >will result in a high on the output of the receiver. =A0I found
> >National, TI and LTC all provide chips with this capability.
>
> >I also found the LTC1482 from LTC that will not only give a high
> >output on these conditions, but does have a detection for an undriven
>
> ...you don't get three state transmission with CAN transceivers. But
> I'm sure that very few people use this possibility really.
>
> >bus. =A0If the voltage on the bus is in the range of the carrier detect
> >(-0.2 V min and 0.2 V max) the CD signal is removed and the receiver
> >output is held high. =A0When the receiver input is outside this range,
> >the CD signal is low and the receiver reflects the state of the bus.
> >So you can implement a CTS protocol (but not an RTS-CTS handshake) to
> >check for the bus being driven before you transmit. =A0This will also
>
> since there is no collsion detection, it won't work reliably. You need
> some arbitration method in a higher layer.

I'm not sure why you say that.  If each sender also receives his
signal, a collision will result in a received message that does not
match what was sent.

Besides, using collision detection is a poor use of bandwidth on a
shared bus.  Every RS-485 implementation I have seen used a master-
slave setup where the slaves only responded to a query from the
master.  That prevents collisions as long as each one waited a bit
after receiving a message before sending.

> >detect a short on the bus when the driver is enabled. =A0Not only is
>
> _When_ do you detect the short if the short is 100m apart?

What does that mean?  I don't get it?


> Disclaimer: I didn't read this thread completely, so please excuse if
> I repeated something already said.
>
> Oliver
> --
> Oliver Betz, Munich
> despammed.com might be broken, use Reply-To:

"rickman" <gnuarm@gmail.com> wrote in message
news:ae2b40f8-afb4-4c9b-acee-4b39977bf091@a12g2000yqm.googlegroups.com...
On Feb 17, 3:22 am, Oliver Betz <ob...@despammed.com> wrote:
>> CAN has much more noise margin. But many people don't understand that
>> the line doesn't need to be driven actively in both directions to get
>> decent speed.

>Can you explain that?  If both ends don't drive actively, what do they
>do?

He doesn't say "both ends", but "both directions", meaning that you drive a
1 and 0 both actively with a transistor/fet. With CAN, you only drive the
line with a transistor to 0. The 1 state is made with pull-ups (resistor or
current source).

>> since there is no collsion detection, it won't work reliably. You need
>> some arbitration method in a higher layer.

>I'm not sure why you say that.  If each sender also receives his
>signal, a collision will result in a received message that does not
>match what was sent.

Depends on the line length. A sender could drive a 1 and see a 1 while 2km
down the line another sender drives a 0, due to line resistance.

> Besides, using collision detection is a poor use of bandwidth on a
> shared bus.  Every RS-485 implementation I have seen used a master-
> slave setup where the slaves only responded to a query from the
> master.  That prevents collisions as long as each one waited a bit
> after receiving a message before sending.

Is it? Waiting for a non-responsive slave is also a waste...

>> _When_ do you detect the short if the short is 100m apart?

> What does that mean?  I don't get it?

A short 100m away doesn't look like a short at the tranceiver, there is line
resistance. I have seen RS-485 perform well even when a trunk line was
shorted at the end.

Meindert

On Tue, 17 Feb 2009 11:03:46 +0100, "Meindert Sprang"
<ms@NOJUNKcustomORSPAMware.nl> wrote:

>"rickman" <gnuarm@gmail.com> wrote in message
>news:ae2b40f8-afb4-4c9b-acee-4b39977bf091@a12g2000yqm.googlegroups.com...
>On Feb 17, 3:22 am, Oliver Betz <ob...@despammed.com> wrote:

>> Besides, using collision detection is a poor use of bandwidth on a
>> shared bus.  Every RS-485 implementation I have seen used a master-
>> slave setup where the slaves only responded to a query from the
>> master.  That prevents collisions as long as each one waited a bit
>> after receiving a message before sending.
>
>Is it? Waiting for a non-responsive slave is also a waste...

This is only an issue, if the normal slave response time is not well
defined, in order to have short timeout times. If a slave does not
respond within 2-3 attempts, it can be considered dead and not polled
regularly anymore. It is however a good idea to perform infrequent
single polls in case the slave device is up and running after a power
failure or watchdog reboot.

>>> _When_ do you detect the short if the short is 100m apart?
>
>> What does that mean?  I don't get it?
>
>A short 100m away doesn't look like a short at the tranceiver, there is line
>resistance. I have seen RS-485 perform well even when a trunk line was
>shorted at the end.

This is really an issue only when the master sends broadcast messages,
which will not reach the slaves on the other side of the short. For
normal request/response traffic, the master will quickly realize, that
some slaves are permanently non-reachable and perform required
actions, e.g. inform the service staff. When request/respons sequences
fail, the master should also assume that broadcasts fail.

Paul

"Meindert Sprang" wrote:

>>> CAN has much more noise margin. But many people don't understand that
>>> the line doesn't need to be driven actively in both directions to get
>>> decent speed.
>
>>Can you explain that?  If both ends don't drive actively, what do they
>>do?
>
>He doesn't say "both ends", but "both directions", meaning that you drive a
>1 and 0 both actively with a transistor/fet. With CAN, you only drive the
>line with a transistor to 0. The 1 state is made with pull-ups (resistor or
>current source).

no pullup - just the terminating resistor, completely passive. The
undriven CAN has 0V differential voltage.

>>> since there is no collsion detection, it won't work reliably. You need
>>> some arbitration method in a higher layer.
>
>>I'm not sure why you say that.  If each sender also receives his
>>signal, a collision will result in a received message that does not
>>match what was sent.
>
>Depends on the line length. A sender could drive a 1 and see a 1 while 2km
>down the line another sender drives a 0, due to line resistance.

not only resistance, also delay.

>> Besides, using collision detection is a poor use of bandwidth on a
>> shared bus.  Every RS-485 implementation I have seen used a master-
>> slave setup where the slaves only responded to a query from the
>> master.  That prevents collisions as long as each one waited a bit
>> after receiving a message before sending.
>
>Is it? Waiting for a non-responsive slave is also a waste...
>
>>> _When_ do you detect the short if the short is 100m apart?
>
>> What does that mean?  I don't get it?
>
>A short 100m away doesn't look like a short at the tranceiver, there is line
>resistance. I have seen RS-485 perform well even when a trunk line was
>shorted at the end.

again not only resistance but delay. Until the reflected signal
travelled back, the sender sees only the line impedance. 100m forth
and back with 0,5c results in more than one microsecond delay.

But resistance is also an issue with long lines.

Oliver
-- 
Oliver Betz, Munich
despammed.com might be broken, use Reply-To: