2 wire rs485

Ok, now I understand. You are thinking of something other than RS-485. I don't what protocol you are thinking of, but RS-485 does not provide any mechanism for knowing when someone else is driving the bus. That has to be done in a higher level protocol. Typically it is handled at the message level using a single master and multiple slaves. So there is no CTS provided by the interface when using a standard RS-485 chip.

Rick

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.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

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?

Rick

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

Thanks.

Peter

... 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.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

I am trying to understand where you got the idea that this is supported in either the hardware or the standard. Have you seen an implementation of RS-485 that provides a CTS that tells the sender that they are on the bus without contention? I have never seen this either in any RS-485 interface chips or in any design using RS-485.

Thinking about how this might would seems like it would be a messy addition to any of the currently available RS-485 interface devices. It would require at a minimum two opamps or threshold comparators to detect the small difference in voltage when the bus is in idle state vs. when it is being driven. Even then I don't see a way to tell if your driver is the only driver on the bus. What if another driver is enabled onto the bus at the same time your driver is enabled. The bus voltage would go from idle state to driven state and neither of you would know the difference.

The only way of detecting a bus collision is to detect the abnormal voltage from drivers driving to opposite states. I can do that much more easily by just monitoring the data at the receiver to see if what I am sending is what the bus is showing. No need at all for a CTS signal and no practical way that I can see to invent one.

Rick

... snip ...

Once more, this has nothing to do with the RS-485 standard, which deals only with hardware. This is about communication between your system and the i/o module that puts the signal on the RS-485 lines. You need this to use the system intelligently.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

So does that mean that you don't have any examples of hardware that implement this protocol? But the real point is that, as you say, there is nothing in RS-485 that indicates a function that you describe. That is likely why it has not been seen in the wild.

Rick

While I have never seen such circuit, the other way to implement such "bus available" signal would be with a retriggable monostable, which is restarted each time a "0" bit is detected (either start bit or a genuine 0 data bit) and when the monostable expires after one character time, the RTS signal could be gated back to CTS and the actual message could be sent.

However, this does not detect the situation, in which two stations start to transmit simultaneously (or within the propagation delay of the cable). Also the monostable delay would have to be configured for the line speed used.

Paul

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

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]: 
            Try the download section.

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

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

[...]

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

..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...

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

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

_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:

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

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

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.

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

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).

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.

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

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

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.

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

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

not only resistance, also delay.

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: