Hello,
I’m trying to connect my Jetson Orin nano to a flight controller (Cube Orange +) with a serial connection with the command : “mavproxy.py --master=/dev/ttyTHS0” and i have this result:
So what i understood is i can receive a heartbeat from the flight controller (flight controller’s TX is sending a signal to Orin’s RX!), but I can’t send anything from the Orin to the FC (i think this means there is a problem in the connection between the Orin’s TX and the flight controller’s RX!).
If you have already a similar problem or have more questions about the problem don’t hesitate to contact me for more informations.
I’m using the devkit Orin Nano with a 5.3 Jetpack version.
For the UART loopback test, it seems like it’s working (when i type a caracter on the keyboard, the same caracter is typed in gtkterm!).
Honestly, i didn’t check if there is any signal from TX, because i don’t have an oscilloscope nor a voltmeter. But it has already worked in the loopback test, so I don’t think it’s the problem.
I have tested the same command with a USB-UART adapter (/dev/ttyUSB0) and i have this in Terminal:
One thing to consider: You know it is sending because of loopback. What you don’t know is if the other side is listening, or if the logic levels are correct. Normally a UART will agree with itself on settings during loopback. Levels are guaranteed to be the same. The UARTs you are looking at by default will be at a 3.3V logic level. Can you check if the UART at the other end is 3.3V? This is likely correct, but it might not be. If voltages are wrong it is unknown if there will be errors, but usually too much send strength might result in send (or hardware failure), and too low of a send strength would almost always fail.
Second, there are different forms of flow control. You might see the normal situation without flow control, but there is a possibility that the side sending is indeed sending, but not using flow control, and thus if the receiving side demands flow control, will ignore what is sent. Can you check your other end to see if it expects flow control?
Basically, if flow control is enabled, then the the RTS (request to send) must be asserted before the sender can send; the sender then asserts CTS (clear to send) if it is ok to send. When both assert data is sent and received. If the buffer at receive fills up, then CTS de-asserts. RTS will remain asserted if there is more to send. When CTS re-asserts (assuming processing buffer data finished), then both CTS and RTS agree and the sender continues sending. If sender runs out of data, then it de-asserts RTS and stops sending.
Many many UART designs ignore and do not use the CTS and RTS wires. It is software though which sets or removes the CTS/RTS flow control requirements. Knowing what the other end expects is critical. Jetsons default to not using CTS/RTS flow control
