# Sniffing an RS-485 communication

I am trying to sniff a serial communication between two devices. One of them sends a command (6 bytes + 2 bytes CRC), the other one responds (4 bytes + 2 bytes CRC). My computer monitors the exchange with an USB-serial converter and PuTTY. I have access to the source code of both devices, and the baud rate seems to be set to 57600.

However two things are quite astonishing :

1. In PuTTY, I must set the baud rate to 57100 to "get the bytes right". At 57600, I see gibberish.
2. There seems to be "junk" in the response once in a while (see picture below).

I don't know what could be causing this, anyone has an idea ?

• perhaps the communication protocol is more complex than you think – jsotola May 9 at 18:40
• For the baud difference that's only 0.86% difference. Most UART receivers should handle that. For the noise, maybe the USB dongle doesn't handle the hi-z state well? – Aaron May 9 at 18:50
• +1 on Aaron. Is there any external hardware PHY or hardware block inside the CPU/FPGA which does something extra you can’t see in the code? – winny May 9 at 19:20
• What devices they are, and what clocks do they use, and how they set their baud rate? Does the USB sniffer have RS-485 data inputs with ground connected between all three devices? Does the terminal show any communication errors, such as overrun errors? What about other terminals? – Justme May 9 at 19:37

Something like this seems to be happening.

x        - stop  bit   (1)
S        - start bit   (0)

01234567 - bit numbers (correspond to bits in first row)

Bits are sent LSB first.

x S   0123 4567    x S    0123 4567    x S    0123 4567
06 49 05       1 0   0110 0000    1 0    1001 0010    1 0    1010 0000

06 92 2a fc    1 0   0110 0000    1 0    0100 1001    1 0    0101 0100    1 0    0011 1111
x S   0123 4567    x S    S012 3456    6 7    7xS0 1234    ? 5    67xx xxxx
|    |
start bit is read twice and becomes an extra bit
then following bits get messed up because of
waiting for stop and start bits