Allowable fluctuation range of Nano UART

Hi all,

The Jetson Nano communicates with an MCU using UART, the percentage of abnormal data is 5%. After analysis, we believe it is caused by MCU frequency offset.

What I want to know is that if I set the uart baud rate to 57600 or 9600, and the peer end has a frequency offset, what range will the frequency offset reach, and Nano will not receive the data sent by the peer end?

Thank you to everyone who is willing to help me.


In other words, how much baud rate difference is allowed between the Jetson Nano and external devices using UART communication?

hello Zz.W,

the default baud-rate configuration is 115200/8n1,
had you also update device tree to change the settings?
for example,

        uartc: serial@70006200 {
                compatible = "nvidia,tegra114-hsuart";
                reset-names = "serial";
                nvidia,adjust-baud-rates = <115200 115200 100>;

you may also use below commands to review the settings on the TTY.
for example, $ sudo stty -F /dev/ttyTHS1

There is some error in the frequency of the clock which matters above a speed of around 115200. Are you asking how clock multipliers at different rates change that offset relative to standards? I can’t answer if that is the question, but a typical method to counter this is to use two stop bits.

Sorry for the late reply.
We can check the correct Settings through stty to verify that the modification is effective. So we’re still working on the issue.
I will update if there is any progress, thank you!


Hi linuxdev,

Sorry for the late reply.

After your reminding, I also checked some similar topics on the forum. Meanwhile, we tried to use two stop bits.

The results have not improved much. I noticed that the way you mentioned is more necessary in higher baud rate, but in fact, we tested at 115K and below.

We’re still trying to solve the issue.

Thank you for your help.


At or below 115200 I’ve not seen any issue with the tolerance of the clock relative to a given baud rate. One thing I’ll suggest, which you might have already done, is to use a logic analyzer. UART/serial logic analyzers are a lot cheaper than man of the other analyzers, so it is worth looking at (on the other hand, since you know of a clock issue, perhaps this is how you are already aware of the issue).

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.