Problems driving a RS-485 bus

[ARQuattr]

I have a board with a PIC18F46K22 on it, and one of its UART ports is fed to a MAX13430 RS-485 half-duplex transceiver to communicate with other identical boards on a multi-drop network. There are bias resistors on the lines, and the bus is running at 5V, 9600 baud.

For the most part the communications work well. All nodes keep the receiver on always, and the 'sending' node enables the transmitter just before sending a message. The protocol is set up to avoid collisions. Messages sent from the sending node appear properly on the bus and are received OK by the other nodes, except for at the very end of the packet. Just before disabling the transmitter driver (or perhaps it's happening as the driver is being disabled), there is a brief pulse which is seen as a start bit for a new character. The receivers see this as 0xFF. I have adjusted the protocol to filter out this last character, but I would like to know if this is normal or if I should be trying to figure out the reason and fix it.

I have attached a couple of logic probe captures I took at the end of the packet showing what I mean. The last byte was 0x20, and you can see the transmitter driver is then disabled. But then after the expected stop bit (differential A high, B low = high level at the receiving node's single-ended UART RX pin), the signals both invert (A low, B high = UART RX low), and then return to the normal idle state (A high, B low = UART RX high) after the transmitter is fully disabled. The second capture is just a close-up of the same pulse.

What could be causing that short pulse?

Thanks,
Angelo

 

[D.A.(Tony)Stewart]

It would be better to scope the analog signals.

Although the Tx is differential, each is unipolar. Thus enabling/ disabling the Tx injects a differential noise equal to the common mode voltage.

Without seeing everything, my guess is an offset bias to the idle state , more hysteresis a small cap, and a large ferrite CM choke around the cable may be considered.

 

[ftsolutions]

Yes - use a scope, not a logic analyzer and configure the probes for differential operation.
Also, what are the pullups and termination resistor values you are using on the RS485 bus (and we are assuming that the bus +5V is isolated). There is almost always some small bias offset, though this varies by the chips used and the resistor scheme on the bus.

Also, if you haven't seen them already, Texas Instruments offers some good application notes on RS485 bus systems in general:
https://www.ti.com/lit/an/snla049b/snla049b.pdf
**broken link removed**
https://www.ti.com/lit/an/snla042a/snla042a.pdf
... and they have more..


It is not uncommon for there to be some noise on long RS485 lines when one or more devices disable their transmitters (Hi Z). It is very common for devices on such distributed RS485 busses to also implement/enforce a minimum "dead time" in between messages as part of the protocol-> any message to be sent must not try to start to be sent until xxx microseconds or milliseconds have elapsed from the end of the previous message.. so all receivers can ignore anything that arrives before that inter-message time transpires. This allows driver software on all devices to filter out transients like this and largely avoid having the start of a bonafide message be mangled by switching transients along longer cables (accounting for propagation delays, etc). This makes the system more robust.

 

[ARQuattr]

Thanks for your suggestions.

I checked with the scope and it looked good, but after some more troubleshooting I realized that I was actually turning off the driver prematurely. I was monitoring the TX1IF flag after sending the last byte to know when to disable the driver, but it's set after loading the byte, not after it's all transmitted. I added a check of the TRMT1 flag (which is set only after all bits are transmitted), and this fixed that bad byte. (I had forgotten that I previously padded the end of the string with an extra character to compensate for this issue, and that was the character it was actually trying to send at the end.)

 

[D.A.(Tony)Stewart]

good test to always verify output is completed. or wait required time.