How to mesure baudrate of RS485 and "jitter" in signal

[Sorama]

Hello,

First time message here...goodmorning from Belgium to everyone !

I'm trying to understand my RS 485 domotic system (master/slave) with 8 RS485 buses and 1 UART.

First question:
I have an Siglent 2104X Plus scope with all the decode options but do not succeed in getting a stable signal: the A and B outputs of the RS 485 driver are shifting horizontally when trigger is set to Normal.
That makes it difficult to decode.
However, when triggering is set to Pulse than of course there is no jitter, but I feel I have to know what makes this signal dancing.

Second question:
although I know that the UART (RS232) has 8 bits, 1 stop bit and that communication with RS232 and Hyperterminal software works perfectly, I don't succeed in knowing the baudrate of the RS485 buses.
When I mesure the smallest bit (according to me) , the baudrate is something around 344k (see screenshot).

I do happen to know that the slave device (a control panel; just one is connected), when communicating, has 3 bytes for RX (7f 3f 00) and 1 byte for TX: 04.

I haven't been able to get those bytes properly decoded, as you can see in the attachments.

Anyone out there that can help me?
any help would be very much appreciated as the manufacturer is no longer....

tnx.

[Siwastaja]

Usual RS485 gotchas:

1) RS485 is a three-wire bus. Ground (or return) wire is absolutely mandatory. Some devices use mains protective earth as RS485 ground, which is confusing and usually causes EMC/EMI failure, but communication still often works even with such designs; but if you don't have even that, but have completely floating grounds, it's likely not going to work at all.

2) Additionally to termination (the need of which is probably well known even to young players), you also need biasing. Termination resistors are used twice (once at each end of the bus); biasing resistors are used once at the bus (where exactly does not matter, but often at master). Google for "RS485 fail-safe biasing" for application notes how to calculate them, but do note the name is absurd, fail-safe biasing has absolutely nothing to do with fail-safe, it's a normal operational requirement.

3) Note how there are two differing ways to label A and B; basically Wikipedia + a few others, versus most of the manufacturers. There is still enough disagreement about what the standard originally meant and who is right and who is wrong, so that only practical way is to always test swapping these two signals until the communications work. If you need to try out other parameters, too, this doubles the number of permutations; for each experiment you make, you need to test it with A&B swapped and non-swapped.

Your way of finding the shortest bit and measure it's period seems correct to me. Expect to see any weird baud rates in RS485 systems. And also any stop bit and parity settings. And remember that even if a standard such as the modbus standard says something about the required parity setting, that does not mean anyone follows these requirements.

[Sorama]

Tnx.
I’m aware of the gotchas, but these devices are working perfectly.

As the bus speed is rather low and cabling is short, (50cm), termination nor grounding is an issue nor will it influence the decoding.

As said, at the Uart side I have no issues in decoding correctly.
It is before the uart, the RS485 buses who seem to work at a higher baudrate than the uart (uart =19200 baud) that I need to decode the communication (on RS485 level).

Because of the horizontal shifting of the signal (A line), I am not sure in what way this influences the decoding.

[PGPG]

As said, at the Uart side I have no issues in decoding correctly.
It is before the uart, the RS485 buses who seem to work at a higher baudrate than the uart (uart =19200 baud) that I need to decode the communication (on RS485 level).

I probably differently understand UART term as for me speed at UART have to be the same as at RS485.
For me UART is typically integrated in microcontroller section controlling serial communication. So microcontroller has TXD and RXD pins connected then to RS485 transceiver. And at UART level (TXD and RXD pins) speed is the same as at RS485 level as RS485 transceiver only changes unbalanced signal TXD into balanced at A and B wires and than back balanced into unbalanced at RXD.

do not succeed in getting a stable signal:

Serial communication is not periodic signal so you can't get stable view if you trigger several times. You should set Trigger to Single.
If you have terminal resistors at both bus ends and you insert a serial resistors in both lines then using oscilloscope you can distinguish frames sent in one direction and the other.

[tooki]

It is before the uart, the RS485 buses who seem to work at a higher baudrate than the uart (uart =19200 baud) that I need to decode the communication (on RS485 level).

This cannot be.
RS-485 describes ONLY the physical interface — that is, the voltage levels and electrical requirements. It says absolutely nothing about the protocol, speed, etc.

An RS-485 transceiver does NOTHING except convert signal levels and drive the bus. You can think of it as some slightly specialized comparators (which is why the schematic symbol is in fact an amplifier). So whatever baud rate goes in is what comes out.


Or are the RS-485 buses completely separate from the UART, in which case there’s a microcontroller or something in between?

Are you sure the RS-485 buses are even asynchronous serial at all? They could be some completely unrelated protocol, like DMX.

[Sorama]

tnx.
the microcontroller is a (Dallas) DS87C530 (ain't that a 8051 ?), good old stuff with 2 full duplex serial controllers built in.
The RS 485 drivers are (behind a mux/demux) going to 1 serial input in the controller, the RS232 (UART) is going to the other.

So That explains why 2 different speeds can be maintained, right?

As the RS485 is in fact a serial communication, I set the scope to decode UART and the measurement (look at the attachment) of a single bit clearly tells the baudrate is somewhere near 342kbaud.

I hope this can help in further analysis?

[pcprogrammer]

the microcontroller is a (Dallas) DS87C530 (ain't that a 8051 ?), good old stuff with 2 full duplex serial controllers built in.

This microcontroller is indeed 8051 instruction set compatible.

The RS 485 drivers are (behind a mux/demux) going to 1 serial input in the controller, the RS232 (UART) is going to the other.

So That explains why 2 different speeds can be maintained, right?

Correct, using two separate UART's for both type of serial communication interfaces means there can be two different speeds.

As the RS485 is in fact a serial communication, I set the scope to decode UART and the measurement (look at the attachment) of a single bit clearly tells the baudrate is somewhere near 342kbaud.

I would not use the term "fact" when stating that RS485 is "a" serial communication. RS485 is a specification for a hardware interface to support serial data transfer.

You should connect your scope to the TXD line before the RS485 transceiver to get a better signal to trigger UART (universal asynchronous receiver-transmitter) decoding on. This way you can be sure it is the actual transmission you are looking at and not the balanced copy of it where possible collision can take place.

[PGPG]

clearly tells the baudrate is somewhere near 342kbaud.

One of the (less common) used baudrate speeds is 3 x 115200 = 345600.

https://vesc-project.com/node/391

[Sorama]

clearly tells the baudrate is somewhere near 342kbaud.

One of the (less common) used baudrate speeds is 3 x 115200 = 345600.

https://vesc-project.com/node/391

Hi

I have indeed for the moment set the baudrate at 345600, but that still doesn't give me an good decoding (scope says: over length )

[Sorama]

the microcontroller is a (Dallas) DS87C530 (ain't that a 8051 ?), good old stuff with 2 full duplex serial controllers built in.

I would not use the term "fact" when stating that RS485 is "a" serial communication. RS485 is a specification for a hardware interface to support serial data transfer.

You should connect your scope to the TXD line before the RS485 transceiver to get a better signal to trigger UART (universal asynchronous receiver-transmitter) decoding on. This way you can be sure it is the actual transmission you are looking at and not the balanced copy of it where possible collision can take place.

I tried input as well output on the RS485 drivers (output is A, idle high, no need to map both channels and do the math).
No difference in behavior of decoding.

Shouldn't it be possible to count all the bits to know the content of that diagram?
But I find it difficult to do that, given there is also a start and a stop bit somewhere.
(And of course a lack of experience :-)

[tooki]

As the RS485 is in fact a serial communication, I set the scope to decode UART and the measurement (look at the attachment) of a single bit clearly tells the baudrate is somewhere near 342kbaud.

I would not use the term "fact" when stating that RS485 is "a" serial communication. RS485 is a specification for a hardware interface to support serial data transfer.

While this is 100% true today from any practical standpoint, I will point out for completeness’ sake that in the past, we also had parallel buses using the RS-485 physical layer, namely Ultra SCSI. The SN75971B SCSI transceiver chip is essentially just a 9-channel RS-485 transceiver!

[tooki]

clearly tells the baudrate is somewhere near 342kbaud.

One of the (less common) used baudrate speeds is 3 x 115200 = 345600.

https://vesc-project.com/node/391

Hi

I have indeed for the moment set the baudrate at 345600, but that still doesn't give me an good decoding (scope says: over length )

Have you made sure the serial decode settings are actually correct? Not just baud rate, but the polarity, parity, word length, bit order, and stop bits? It may be necessary to play around with these.

[pcprogrammer]

Very good point from tooki.

Read the manual of your scope before trying to use this kind of features. I don't own a Siglent but can imagine that it needs other settings then just selecting UART decoding as a trigger option.

[tooki]

I don’t know if it has UART triggering. I don’t think most scopes do. So you’d want to trigger on a pulse or edge or whatever, ideally using triggering settings like pulse width and holdoff to get a stable trigger before even bothering to try decoding.

[pcprogrammer]

I would have to look in the manual of the Rigol MS5070 I own to be sure, but if I remember correctly from some experiments you can set a data value to trigger on. If you are expecting a sequence of data that always starts with, for instance, 0xAA you can setup your scope to start recording when it encounters that value.

This is what I think of when "using UART triggering" is stated.

But as I wrote, read the manual to find out the capabilities of the scope in question.

[tooki]

Sure, but for trigger-on-data to work, decoding has to work first. Until decoding is set up properly, OP needs to set up a stable edge or pulse trigger.

[Sorama]

clearly tells the baudrate is somewhere near 342kbaud.

One of the (less common) used baudrate speeds is 3 x 115200 = 345600.

https://vesc-project.com/node/391

Hi

I have indeed for the moment set the baudrate at 345600, but that still doesn't give me an good decoding (scope says: over length )

Have you made sure the serial decode settings are actually correct? Not just baud rate, but the polarity, parity, word length, bit order, and stop bits? It may be necessary to play around with these.

That’s the actual problem: I don’t know these settings but I have tried all combinations, but to no avail.

[Sorama]

I don’t know if it has UART triggering. I don’t think most scopes do. So you’d want to trigger on a pulse or edge or whatever, ideally using triggering settings like pulse width and holdoff to get a stable trigger before even bothering to try decoding.

I have this scope for some years now and indeed, it has uart triggering.
But technically this is not a prerequisite, as one can simply trigger on edge on the A of B output of the rs485 driver.

Single triggering works perfectly, standard works but with some horizontal shift.
I use Single trigger and then tried all combinations of uart decoding settings.

[rteodor]

In my experience MSO decoding on I2C fails badly where a cheap LA works well with 5x sampling.

I would go medieval on this signal: use vertical cursors to find the bit duration then slide it until you find the correct character size and parity.
It could be hard if there is lots of well timed data but otherwise it should be quite easy after a bit of practice.

Later clarification: I did not tried UART decoding but I expect it to perform as worse. I got a sense that decoding is done on the "display signal" and not on the actual samples: zoom out too much and it gets confused, slide horizontally and it looses track of the start condition.

[tooki]

In my experience MSO decoding on I2C fails badly where a cheap LA works well with 5x sampling.

I would go medieval on this signal: use vertical cursors to find the bit duration then slide it until you find the correct character size and parity.
It could be hard if there is lots of well timed data but otherwise it should be quite easy after a bit of practice.

Later clarification: I did not tried UART decoding but I expect it to perform as worse. I got a sense that decoding is done on the "display signal" and not on the actual samples: zoom out too much and it gets confused, slide horizontally and it looses track of the start condition.

That depends entirely on the design of the oscilloscope. The Rigol DS1054Z, for example, decodes from the display data. But most models from the “big” manufacturers (Keysight, LeCroy, Tek, Rhode & Schwarz) decode directly from acquisition memory and thus decode regardless of the zoom level.

[tooki]

I don’t know if it has UART triggering. I don’t think most scopes do. So you’d want to trigger on a pulse or edge or whatever, ideally using triggering settings like pulse width and holdoff to get a stable trigger before even bothering to try decoding.

I have this scope for some years now and indeed, it has uart triggering.
But technically this is not a prerequisite, as one can simply trigger on edge on the A of B output of the rs485 driver.

Single triggering works perfectly, standard works but with some horizontal shift.
I use Single trigger and then tried all combinations of uart decoding settings.

I assume by “some horizontal shift” you just mean that it’s not necessarily triggering on the same edge in each character. I already said how to fix this: learn to use trigger holdoff (and possibly pulse width trigger) to get a stable trigger on the first edge.

Without trigger holdoff you’re just triggering at some random edge or pulse within the character. Holdoff lets you delay rearming the trigger so that it skips the subsequent edges or pulses within the same character.

All combinations? You sure about that? That’s a lot of permutations!

[tooki]

Here’s a lousy sketch of what holdoff does. You figure out how long one character is, here apparently around 550 microseconds. You want it to trigger on the first falling edge, but ignore all the others in the character, so you set the holdoff to a bit more, like 700 microseconds. This means that after the first falling edge (where it triggers), the trigger is “paused” until 700 microseconds later, when we are in the pause between characters. Then the trigger rearms and triggers on the first falling edge of the next character. This gives you a nice stable trigger that’s always triggering on the same place.

[JustMeHere]

Try sending the bit pattern 10101010

This can make it easier to figure out what you're doing wrong.

[Shay]

Recently I had to "decode" unknown differential protocol. I tried using my rigol scope but I faced the same issue as you, which is a lot of timing jitter. I am not certain what is causing this, might be just bad  triggering, but I am certain the device it is connected to samples it at the correct baud rate at the middle of each bit, with or without timing jitter. So, using logic analyzer really helps here as it basically emulates the slave, and it allows you to find patterns and perform quick testing of the protocol, much more comvinent. Next, figure out what is the start byte, as it will always repeat itself, and try to find if there is a CRC - this will help decoding the frame.

[Sorama]

Here’s a lousy sketch of what holdoff does. You figure out how long one character is, here apparently around 550 microseconds. You want it to trigger on the first falling edge, but ignore all the others in the character, so you set the holdoff to a bit more, like 700 microseconds. This means that after the first falling edge (where it triggers), the trigger is “paused” until 700 microseconds later, when we are in the pause between characters. Then the trigger rearms and triggers on the first falling edge of the next character. This gives you a nice stable trigger that’s always triggering on the same place.

Tnx very much.
I tried it, but didn’t change the outcome.
I tried different delta’s, but triggering never got better.