I’m trying to connect a Jetson Nano Orin (developer kit) with a Pixhawk Cube Orange running Ardupilot through UART port. I’m using the ports for Tx (pin8) and Rx (pin10) that correspond to the UART “/dev/ttyTHS0”. Then I use mavproxy to establish the communication with “sudo mavproxy.py --master=/dev/ttyTHS0 --baudrate=115200”. And it is able to receive data, but the transmission seems to be unstable and some trash is received (also the link goes downs continuously).
I was able to establish connection between my Pixhawk and a Jetson Nano (not Orin) using the same procedure (but on “/dev/ttyTHS1”) successfully. So what can I do to solve this issue in the Orin version? I’ve read a lot of forums regarding the wrong UART functionalities on the Orin version. Some solutions are workarounds using a UART-USB adapter (but I don’t want that, I need to use the pins directly).
Based on your description, here are some steps and considerations to help stabilize the connection using the GPIO pins (Tx on pin 8, Rx on pin 10) directly, avoiding a UART-USB adapter:
Verify UART Mapping and Pinout
On the Jetson Orin Nano Developer Kit, /dev/ttyTHS0 typically corresponds to UART1, which uses pins 8 (UART1_TXD) and 10 (UART1_RXD) on the 40-pin GPIO header. This matches your setup, but recent reports (e.g., from NVIDIA Developer Forums and ArduPilot Discourse) suggest that UART mappings can vary or behave differently on the Orin Nano compared to older Jetson models like the Nano.
Double-check the pinout in the Jetson Orin Nano Developer Kit User Guide (available on the NVIDIA Jetson Linux R36.4.3 page or Jetson Download Center). Ensure you’re correctly wiring pin 8 to Pixhawk’s RX and pin 10 to Pixhawk’s TX (e.g., TELEM2 port), with a shared ground (pin 6 on the Jetson to GND on Pixhawk).
Check Device Recognition and Logs
Run dmesg | grep tty to confirm /dev/ttyTHS0 is recognized and active. Look for any error messages related to UART or DMA that might indicate driver or hardware issues. For example, some users have reported DMA-related complications affecting UART stability on Orin Nano (as noted in recent Jetson troubleshooting docs).
If /dev/ttyTHS0 isn’t listed or shows errors, it could indicate a misconfiguration or driver issue. Ensure JetPack 6.0 (R36.4.3) is properly installed and up-to-date, as UART behavior can change after upgrades (a common issue mentioned in forums).
Configure UART Settings
You’re using mavproxy.py --master=/dev/ttyTHS0 --baudrate=115200, which is a standard baud rate for Pixhawk-Ardupilot communication. However, some forums (e.g., ArduPilot Discourse) report that the Cube Orange’s H7 processor may have different serial handling compared to older Cube models, sometimes requiring lower baud rates or specific Ardupilot serial parameters.
In Ardupilot, check the SERIAL1_BAUD (or relevant SERIALx_BAUD for TELEM2) parameter in Mission Planner or QGroundControl. Ensure it matches 115200. You might also try lowering the baud rate (e.g., 57600 or 38400) to test if stability improves, as higher rates can cause issues with Cube Orange (as seen in web:5).
Disable DMA for /dev/ttyTHS0 if possible. Some users have reported better stability by toggling DMA settings in the device tree or kernel parameters, though this requires advanced configuration (check the Jetson Linux Developer Guide for R36.4.3 or NVIDIA forums for details).
Test Ground Connections and Hardware
Ensure a solid ground connection between the Jetson Orin Nano (pin 6) and the Pixhawk Cube Orange (GND on TELEM2). Poor or missing grounds are a frequent cause of unstable UART communication, even with correct TX/RX wiring (as noted in web:10).
Verify the wiring for continuity and check for loose connections or interference. Use a multimeter to confirm signals on pins 8 and 10 are clean and match the expected voltage levels (typically 3.3V for Jetson Orin Nano UART).
Troubleshoot Link Dropouts and Garbage Data
The garbage data and continuous link dropouts suggest potential baud rate mismatches, noise, or driver issues. Run mavproxy.py with verbose logging (e.g., sudo mavproxy.py --master=/dev/ttyTHS0 --baudrate=115200 --verbose) to capture more details about the link failures.
Check dmesg and journalctl for UART-related errors during mavproxy.py execution. If you see input/output errors or DMA issues, it could indicate a driver mismatch or hardware limitation on the Orin Nano’s UART1.
Test with a different Pixhawk port (e.g., TELEM1) or a different cable to rule out hardware-specific issues with the Cube Orange or wiring.
Compare with Jetson Nano (Non-Orin) Behavior
Since /dev/ttyTHS1 worked on the Jetson Nano, note that UART mappings differ between models. On the Orin Nano, /dev/ttyTHS0 is UART1 (pins 8, 10), while /dev/ttyTHS1 might map to a different UART (e.g., UART2 on pins 22, 32, as seen in web:10). Ensure you’re not mistakenly expecting /dev/ttyTHS1 behavior on the Orin Nano.
The Orin Nano’s UART implementation (e.g., DMA-enabled interfaces) may introduce new challenges not present in the older Jetson Nano, as reported in recent forums (web:3, web:10, web:15).
Advanced Debugging
If the issue persists, consider modifying the device tree or kernel configuration to disable DMA for /dev/ttyTHS0 or adjust UART settings. This requires editing the tegra234-p3767-0000+p3768-0000.dts file (for Orin Nano Dev Kit) in ~/kernel_build/Linux_for_Tegra/source/kernel/kernel-jammy-src/arch/arm64/boot/dts/, then recompiling and flashing the kernel (see the Jetson Linux Developer Guide for R36.4.3).
Use minicom or screen to manually test /dev/ttyTHS0 (e.g., sudo minicom -D /dev/ttyTHS0 -b 115200) and verify data transmission without MAVProxy to isolate the issue.
8. Forum Insights and Workarounds
Recent forum posts (e.g., ArduPilot Discourse, CubePilot, NVIDIA Developer Forums) indicate that UART issues on Jetson Orin Nano, especially with Cube Orange, can stem from hardware differences (e.g., H7 processor, DMA settings) or software misconfigurations post-JetPack upgrades. Some users suggest using USB adapters as a workaround, but since you prefer GPIO pins, focus on the above steps.
Check the NVIDIA Developer Forums (forums.developer.nvidia.com) or ArduPilot Discourse (discuss.ardupilot.org) for recent threads on Jetson Orin Nano UART stability, as newer posts (e.g., from 2024–2025) might offer updated solutions.
Ensure JetPack 6.0 (R36.4.3) is fully updated, as UART driver changes between JetPack versions can affect functionality (web:15).
If the Pixhawk Cube Orange uses Ardupilot firmware, verify its version and serial settings match the Jetson’s configuration. Older firmware or mismatched settings can cause instability (web:2, web:5).
Test in a stable environment (consistent power supply, minimal interference) to rule out external factors.
If you’ve tried any specific configurations or logs (e.g., dmesg, MAVProxy output), sharing those could help narrow down the issue further. I hope these steps resolve the instability!
Best regards,