0
\$\begingroup\$

Part 1

What is the standard timing method for bits acquisition for a receiver using Modbus RTU?

For example, for UART: "Communicating UARTs have no shared timing system apart from the communication signal. Typically, UARTs resynchronize their internal clocks on each change of the data line that is not considered a spurious pulse. [...] they resynchronize on the falling edge of the start bit only, and then read the center of each expected data bit, and this system works if the broadcast data rate is accurate enough to allow the stop bits to be sampled reliably." (source wikipeda)

I didn't see that kind of information onto the modbus organization.org website.

Part 2

To go further, here is the issue: I use a FTDI F232R TTL USB cable (from RS-component) to make a custom sensor (server with a STM32 uC) communicate (using modbus protocole) with a computer (client), using a terminal (realterm) or a software (ModbusReader or custom) on it. I know I shouldn't do this because I have read that modbus protocole should be used with RS232 or RS485 physical layers, not TTL levels.. (I didn't find yet any explanation about that (?)) Everything works fine at several baud rate speeds (i.e 115200, 19200, 1200) but at 57600 baud rate, it raises error (frame error on Modbus Reader). So, to know if there is any transmission issue (such as timing ones) on the line, I want to decode my self (using Scilab) the data recorded by an oscilloscope.

Note: strange thing: with an FTDI F232R TTL USB cable from an other (mysterious) source, which I opened to see that it uses same IC, but only 2 capacitors versus 4 capacitors on the RS-component source, I works pretty fine for all baud rate speed.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Can you ask your question in a very short form? \$\endgroup\$ Mar 9, 2021 at 11:05
  • \$\begingroup\$ Part 1. Modbus RTU uses standard async uart. The receive retiming is not its concern as this is a physical layer requirement. Get the baud rate, bits and parity correct and let the hardware do its thing. Stm32 uarts, ftdi232 uarts are all compatible. As for rs485, rs232 or ttl levels - that isnot a concern of the modbus protocol - that is hardware layer. \$\endgroup\$
    – Kartman
    Mar 9, 2021 at 12:31
  • \$\begingroup\$ so timings for acquisition follow standard async uart, which is independant from RS485, RS282 or TTL levels. Is that correct? \$\endgroup\$
    – NinjaGreg
    Mar 9, 2021 at 13:45
  • \$\begingroup\$ "resynchronize on the falling edge of the start bit only" Leading edge (i.e. beginning) would be less ambiguous here given that the leading edge of a RS-232 start bit is actually a rising edge (negative to positive transition). \$\endgroup\$
    – Graham Nye
    Mar 10, 2021 at 0:12
  • \$\begingroup\$ So, do you have a link giving the timings for my application case ? Thank you =) \$\endgroup\$
    – NinjaGreg
    Mar 10, 2021 at 8:51

1 Answer 1

1
\$\begingroup\$

It is not very frequent but it happens.

Sometimes a pair of serial devices won't talk to each other at certain baud rates.

To understand why you need to realize that baud rates are derived from a clock by dividing by an integer value. Since each device might have a very different clock rate it might happen that the real baud rates are quite different. In general they should not vary more than 3-5% if they are to communicate with no errors.

An example: your FTD chip uses a 3 MHz clock. To derive 57600 baud it needs to divide by 3000000/57600 = 52.0833. Since that's no integer the closest it can go is 52. Reverting the calculation 3000000/52 = 57692.3

You will have to do the same calculation for the Modbus device on the other side to see if they are within 3-5% of each other. Most microcontroller and transceiver datasheets include a table with the percentage error on baud rates for you to check and choose. This is also a good reason to stick to standard values but as you probably know by now that is no silver bullet. Sooner or later you will pair devices that won't be able to sync.

Be aware that these are only theoretical values, that's probably why you have no problem with your second FTD transceiver. If you want to be sure you need to hook up a scope and measure those baud rates carefully.

The solution is quite obvious: change baud rates or use a different transceiver (or change its clock rate if you can).

You can read more details here.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.