RS485 signal error

Hi all,
I have two PCB’s that will talk over RS485. One board can send data to the other without any problems. The other board only sends gibberish in return. One board has a MAX3468. The other board has a MAX14948 (to be optically isolated from the other board). Both ends have a 120 ohm resistor for termination.

The serial signal going into the MAX3468 looks good, but when I look at the signal being output using a logic analyzer, I can see that the start bit is too long/short for the logic analyzer so the decoding fails.

The Red signal is the Serial input, the Yellow signal is the A output and the Blue is the B signal to the MAX3468 chip. Here they share a common GND wire (per RS485 spec). If I disconnect the GND wire to the other board, the A signal will look correct, but the B signal will be the same, so sync between the channels are lost.

Looking at the signals with an Oscilloscope reveals that the start bit isn’t at the correct voltage level. It’s quite a bit higher/lower. Here the Yellow signal is the Serial input to the MAX3468 and the purple is the A-signal output.

If I set the scope to display only the A/B signal, one can clearly see why this isn’t interpreted correctly:

There is no load on the RS485 cables other than the termination resistors, but I tried removing them and it is the same with them removed.

Is there anyone with RS485 experience that have seen this problem before? Or have pointers as to where I should start digging? Any help would be much appreciated!

It’s been 10 years since I did RS485 last. Don’t you need pull-up resistors as per default?

People think of RS485 as a two wire system, but you really need three (common ground) for reliable comms. Without one it’s possible to have an offset that exceed the common mode voltage range of the receiver.

As I wrote, I do indeed have a common ground.

Pullup/pulldown should not be required since the IC’s will provide the voltage levels. It’s normally only used “when the bus is not actively driven or is in a fail state”. I’ve never had to use it before for communicating between just two devices.

That intermediate-level start bit looks like a bus conflict. Check the receiver’s TX Enable?


First of all, thank you for your excellent question/analysis and capture of the logic and oscilloscope traces.

It looks to me that the 2 transmitters are driving the same signal line at the same time – as such, there is a collision where a logic-high contends with a logic-low and the voltage meets about halfway between them – thus showing a runt start bit in your oscilloscope trace. It may happen only to the start bit because the collision may somehow de-assert the driver enable DE line and thus tristate the remaining bits. Electrically, the signals look as expected during a collision. The transmitters should be able to withstand collisions okay occasionally - but, collisions will cause dropped bits. Yes, you always include a ground line between the two systems and no pullups/pulldowns – just the termination resistors (as you’ve done). Yes, it may happen one-sided where circuitry on one device always wins and the other is always slower and always likely to lose in contention.


It’s interesting that the onset of activity on the A signal output precedes the start bit serial input. What’s happening at that time? It sounds like this is a bidirectional application over 2 wires. How are you controlling which side drives the outputs? Is it possible there’s an overlap and contention?

I’ll second this opinion. That was my immediate opinion when looking at the 'scope trace.

Can you look at both bus drivers on a scope disconnected from one another?


1 Like

One thing I find helpful in these situations is to connect my Saleae logic analyser to all the tx/rx, A/B, DE/RE lines at once, and check the timing. All my problems have been errors in my program driving the transceivers.
FYI Pull up/downs are only to ensure the bus returns to a known “neutral” state, and are generally not needed. See
Terminating resistors are only to stop signal reflections at high data rates, and must be matched to the cable you are using. (ie the same as a high speed bus on a pcb). There is no sign of reflections on your scope trace.


Thanks all! Much appreciated as it was indeed an incorrect response at the the other end that caused this behavior.