Serial Communication issue on j21 header: TX2 slows down to a crawl when connected to a ublox_gps module

Background:
My company has had a TX2 for about 4 months and have had no problems using it for machine-learning applications. I was handed the machine today for configuration with certain sensors. The TX2 has Ubuntu 16.04 LTS installed on it. It also has ROS Kinetic installed.

Problem:
When I connected a ublox Neo 6m GPS module to the TX2, it took extraordinarily long to boot up. Attempting to access the GPS via ROS on ttyS1 resulted in predictable output (with an error thrown for baud rate configuration issues), but the CPU0 graph on the System Monitor shot up to 100% and there was system lag on everything including mouse movement.
The GPS module was connected to the J21 header on pins 4, 6, 8 and 10. I attempted to use pins 1 and 2 for power instead, with the same result. I also tried using pin 9 for ground, with the same result. I used a volt-meter to check the voltage readings on the pins with pin 6 on the negative terminal; touching pin 4 to the positive terminal of the volt-meter for a couple of seconds led to the machine powering down (hard shut-off). The other power pins are giving expected readings.

Is this problem being reproduced on other TX2s, or do I have a faulty device? I am not even sure what the problem is, though I suspect it is a short on the J21 header. Does anyone have any recommendations on what I should do?

I would suggest forgetting about ROS for the moment and get your UBlox module working with GPSD http://catb.org/gpsd/gpsd.html

I’ve never had issues with UBlox Neo GPS modules, though mine are USB based and not pins directly connected to the J21 headers.

Update:
I have temporarily got the GPS module working with ROS by connecting it to the TX2 via USB through an FTDI, but that is not a permanent solution as there is a device conflict with the other sensors I have attached via USB (due to the async attribute of the data, according to the error thrown). In the past on another device I have resolved the conflict by associating the asynchronous processes with specific device names (eg /dev/ttyUSB1) and cycling the connection of USB devices manually until the devices had the desired names, but this will be a major hassle with 3+ USB devices.

I really need to know if there is a fault in the J21 header of specifically this TX2 that prevents serial communication with the GPS module, or if this is a flaw in all TX2s. If the latter is true, then buying a new TX2 will not solve the problem.

My guess is that you’re using the console UART. The console and the external GPS will go into a feedback loop that is quite bad if you do this. It may think the GPS is trying to log in on the console, for example.

There is no flaw in the TX2. There is a flaw in your configuration.

The easiest thing to do is to connect the GPS to J17 instead. The default camera module that comes with the TX2 does not use the J17 serial port, and thus you don’t need to do anything else than wire up the right cable.

The harder thing to do is to disable serial console and disable init/getty login on the J21 console serial port. There are some tutorials google-able for how to do this, but I recommend against it, as the serial console is quite useful at times, and I’m not sure whether it’s possible to disable ALL console serial output, even from early-boot tools like uboot.

What @snarky said. J21 is the serial console…any character going over that wire to the Jetson during U-Boot would drop into U-Boot command line.

FYI, ports of the naming convention “/dev/ttyS#” (including S0 and S1) are standard drivers. The ones with names of format “/dev/ttyTHS#” (including “/dev/ttyTHS2” on J17) use DMA. You cannot use both simultaneously. The J17 recommendation is by far the best way to go…and just point at “/dev/ttyTHS2”. Your CPU use will probably also go down.

I looked up a few J17 pinout configuration tables online but got conflicting configurations, and using trial and error on the basis of Vcc pins did not help. Could you point me to the specific J17 pin configuration for the TX2?

Also, I have been informed that there is a CAN port on the TX2 that allows a user to bypass a USB connection with a car’s OBD and directly interface with the OBD through the CAN port. This would be useful since the Jetson having only one USB port (without a USB hub attached) has led to some problems with OBD interfacing (for some reason even though the OBD is recognized on the USB hub, the data is inaccessible). Is there a resource available that explains how to interface the TX2’s CAN port with a car’s OBD?

“Also, I have been informed that there is a CAN port on the TX2 that allows a user to bypass a USB connection with a car’s OBD and directly interface with the OBD through the CAN port.”

There is no USB connection to OBD. There are USB tools which are essentially CAN transceiver(s) (and other serial communication transceivers), with a microprocessor which supports the OBD2 protocols e.g. https://www.amazon.co.uk/ELM327-USB-Interface-Diagnostic-Scanner/dp/B00IWLLX1Y

“This would be useful since the Jetson having only one USB port (without a USB hub attached) has led to some problems with OBD interfacing (for some reason even though the OBD is recognized on the USB hub, the data is inaccessible). Is there a resource available that explains how to interface the TX2’s CAN port with a car’s OBD?”

There are 2 CAN interfaces available on the TX2, both of which will require a CAN transceiver each and the use of SocketCAN https://en.wikipedia.org/wiki/SocketCAN.

This should allow you to get started with OBD2 and SocketCAN https://github.com/linklayer/pyvit/blob/master/docs/getting-started.rst, this is a common enough question on the forums, I’m sure you will find several threads related to the TX2 and CAN using the search function.

Thanks, and sorry for the misunderstanding, I meant to say MY usb connection to the OBD, not the TX2’s.