2 wire rs485

ok, i'll try to be as precise as possible, but bear in mind i am a sw engineer, i don't have much of an electronics knowledge.

when i use the converter (which by the way is a JaRa 2102E(chinese)) i do this:

- plug the converter to the serial port RS232

- screw one end of each of two wires into, respectively, a hole marked d+/A and a hole d-/B on the converter side

- screw the other end of the wires to the holes of the meter i mentioned before.(A and B)

the total length of the cable is approx 60cm.

the software i wrote does this:

- set the port parameters as needed to communicate with the meter(1200 baud, even parity, 8 data bits, 1 stop bit)

- send 16 bytes(a packet of the meter communication protocol with a request enclosed)

- receive 20 bytes (the response packet)

no rts cts lowering or raising. no ground wire, even though there is a hole on the converter end marked as GND.(as i mentioned before, the meter doesn't have one)

i googled for the converter model but i found no electrical scheme, just a few pages in chinese.

also, about waiting for the clear to send signal, well, it is never sent by the meter.

I was talking about "shift-register empty" bits that went true before the stop bit had been sent.

Sorry, Grant ;).

Even so - I've occasionally come across UART architectures which seem to use two shift registers in series. (Or perhaps I dreamed that?) Or, possibly, the shift register is indeed empty and the stop bit is added automagically? It's been a while, and perhaps my leedle grey cells are, comment dire en anglais, scrambled?

Steve

--

Yes, but you need to connect the interface to the line to send. rts does this. cts announces that the connection has been made. You can get away with less, but the net signal is less positive (it depends on default biases) or eats extra power.

Normally all devices connected to the RS485 line are disconnected. This says nothing about the number of systems connected, or the number of drivers. RS485 is a hardware standard, not a communication standard. It is often used to transmit/receive 8-bit bytes, which includes the complete ASCII symbols.

So don't use a 14550 UART. If you are bit-banging the UART you have no problem, you can build the appropriate timing into the software. Otherwise look for a UART with a 'transmit shift register not empty' signal.

Please don't strip attributions for quoted material. I hope I have restored them accurately.

If you're shopping for a UART, pick one that does half-dupex RTS control in HW. :)

That CTS connection is only required for the RS-232 port and SW driver. In practice, the CTS is simply connected to the RTS line at the converter or the CTS could also be connected to the RTS line (which going to the transceiver) at the RS-232 D9 connector at the PC etc.

While the fail-safe termination will consume some power, it is usually a small price to pay to have a stable bus between bus transactions.

The only protocol in which the separate RTS/CTS handshake might be usable is Modbus, in which the protocol specifies that the bus should be driven into idle ("1") state for at least 1.5 character times, before sending the actual frame. This is intended to let any transmitter turn on transient reflections to die out and also let any spurious noise generated by an unterminated floating bus being purged (a pause longer than 1.5 character times are considered spurious in Modbus).

The transceiver in a Modbus could be turned on into the idle ("1") state, start a HW timer, which expires after 1.5 character times, then activates the CTS and SW driver then sends the actual message. However, I have never seen such circuits, one serious problem is that you would have to reprogram the timer (DIP switches etc.) each time the bit rate is changed.

With the "fail-safe" termination, the bus is constantly terminated by a low impedance, thus reducing the risk for any interference that might otherwise be connected to a high impedance floating bus. Any transmitter turn on should produce only a minor voltage step (or any) when going from the fail-safe idle to the active driven idle state, before the first start bit is actually transmitted. If such step even exists, it is dissipated at the end of the line at the terminating resistor and not bouncing forth and back along as in the unterminated bus case.

All the transmitters are normally in the high impedance tri-state state, while all receivers are continuously connected to the bus, drawing some input transistor bias current, represented as the "unit load" in the RS-485 standard.

Paul

I'm lost. What generates CTS? RTS controls the enable on the RS-485 driver. When that is asserted, why do you need something to tell you that it has been asserted??? What generates the CTS signal? RTS and CTS are both signals in the RS-232 standard. They don't exist in the RS-485 environment other than unused pins on the UART. So they use the RTS to control the enable on the RS-485 driver because it is convenient. If that signal was not there, they would just use some other I/O signal.

Yeah, what's your point?

Rick

use

y?

Actually, I expect that is how most UARTs are made. The shift register holds the start bit and the various other bits *other* than the last stop bit (some UARTs let you program 2 or even 1.5 stop bits). The last stop bit is just a constant 1 that is shifted into the input end of the shift register. So the counter has reached zero when the shift register is full of 1 data and the stop bit is being sent. This is when the tx reg empty flag can go high and is 1 bit too early for the RS-485 transmitter to be disabled.

Rick

/A

Just one comment on this. Unless I have missed something major all these years, the A signal is D- and the B signal is D+. I think they do it this way to be compatible with single ended operation where the data is inverted between the UART and the cable. Sometimes individual companies buck this convention. That can make it very difficult to know how to connect the wires.

Rick

Turning the transmitter off at the _start_ of the (first) stop bit is usually not an issue on a fail-safe terminated bus, since the fail-safe termination will pull the line to the ("1") state after the last actual data bit has been sent, which is first interpreted by the receiver as the stop bit state ("1") and after one character time it is interpreted as the idle state ("1") :-).

Paul

Which shouldn't be a problem since the idle state of the RS-485 lines should be '1' anyway. So disabling the driver before the stopbit is sent should result in the same line state.

Meindert

IMHO, this is a very desirable situation, since it immediately obvious that something is wrong and problems can be easily fixed during the commissioning phase. It is much worse to have intermittent problems when the system is actually in use.

With fail-safe termination it is easy to set up correctly the RS-232/485 converters and the cabling between the converters, just by observing the status LEDs, before even having the actual control systems installed.

Especially with the 4 wire RS-422 there is one combination which works and quite a lot of ways connecting the 4 (or even 5) wires incorrectly:-).

Paul

if i got this right, i have to send the same electrical signals that the converter sends? how can i find out wich signals to send without an oscilloscope?....

what do you mean by going tristate?

thanks again,

vasilis.

Yes, that's generally true for RS-485 with pull-up/down resistors when running at low baud rates. At high baud rates, the pull-up/down resistors might not be low-enough impedance to get the line charged to the "1" state before the point in the stop bit where the receiver starts to sample it. That's partiucularly true if it's a long bus, and the pull-up/down resistors are at one one, and the sender and receiver are at the other end.

However, the systems where the start-bit truncation was most problematic were using half-duplex FSK modems rather than RS-485, and turning off carrier at the beginning of the stop bit definitely caused problems. Adding a 1-bit-time delay loop in the code that was polling the shift-register empty status fixed the problem, but it's ugly.

Paul, I've never seen an RS-485 system with LEDs (and I have dealt with more than a few). Luxury ;).

Also, I've rarely (until fairly recently) seen fail-safe termination *as standard*. (I include it in my designs, but hey... in my industry there seems to be an awful lot of broken RS-485 implementations out there...)

And from other posts re power consumption when both termination and biasing are involved: there's a trick. AC-couple the termination resistor/s with e.g. 0.1uF. Works a treat ;).

Steve

--

... snip ...

You are making unnecessary assumptions. For example, when you assert rts the line is busy. The interface cannot connect. When it can, it does so, and returns cts. Now you can send

The LED is usually on the TTL side of an external RS-232/485 converter or PLC, but it is sufficient to tell the difference between the idle and the break condition.

While putting a red/green low current LED and a series resistor directly across the A and B lines would technically violate the standard, this works quite well in practice, if this is used only on one or two stations at a time during the setup phase (i.e. using it as a break-out-box). Just use a DIP switch to activate the LED or use a separate screw terminal that can be jumpered to the B-line to complete the test circuit. While the standard only requires a +/-200 mV swing at the receiver, in practice the swing is much larger in any sensible system, thus, there are sufficient voltage swing to activate the LED.

I only use masters in which the fail-safe termination can be activated. With the fail-safe termination at the master, just remember to add a 100-120 ohm termination at the opposite end of the bus. The intermediate stations along the bus should not have the fail-safe termination activated.

Which breaks the DC path and you have to use a separate signal ground. There are several tricks to reduce the bias current, but they all seem to have various drawbacks, but may be justified in a battery operated environment, but if the power levels controlled by the serial message is thousand or million times the bias current, why bother to optimize the bias current :-).

Paul