Hi,
I am trying to interface Stonex S900A GPS with nVidia TX2 which has ROS melodic installed. The GPS data cable is a DB9 type (RS232). I connected a DB9 to USB converter with the cable and connected it to the USB port of TX2. I intend to use nmea_driver_navsat ros package to read the GPS data. However, when trying to monitor the GPS data on a serial monitor (such as puTTY or CuteCom), I am getting messages in the following format:\
\
Could it be an issue with the serial driver? When I connect the same GPS with the same cable to another system (for example my Linux PC), I get valid information on the serial monitor. What could be the issue here?
Hi @a.imrantw ,
The converter’s driver might be an issue in your scenario. Another thing that I just thought, the serial port might need an access permission for connection. You can give the access permission like,
sudo chmod <mode_detail> <serialport_path>
For example,
sudo chmod 777 /dev/ttyTHS0
Hi @ozguryildiz ,
Thank you for your response.
I have already given access permission to the USB port. In my case I did:
sudo chmod 777 /dev/ttyUSB0
So the converter is just a cable extension, which has a DB9 male connector on one end and a USB connector on the other. How can I update the driver of this converter?
Hi @a.imrantw,
You should find out that which chip inside your converter? We have worked MOXA Uport 1130 RS232-USB converter before. We just download and install its driver and it worked. In your case, you should get kernel build with your converter chip for kernel or you should get kernel module build for converter chip.
Hi @ozguryildiz ,
I just checked. I cant find the name of the chip, neither physically or through the source from where it was bought but this cable is very low cost. However, I found out that it is a HL-340 USB serial converter.
Is this compatible with TX2?
I read somewhere that CH341 is the right type to be used with TX2. Is that right?
I am just a beginner and i apologize if any question seems basic.
Thanks for the help!
Can you try the following command? It might solve the problem.
sudo modprobe ch341
Just tried the modprobe command. Getting the same output unfortunately.
Do make sure you have set the correct stop bits and parity. If those are wrong, then some bytes will be interpreted the wrong way (data versus control). Also, since that output is from a small subset of control characters (mainly whitespace associated with end of line or delimiting in some way), and because control characters may just happen to be set to show as hex, double check if those characters are perhaps not so much an error as they are an interpretation.
Here’s a nice ASCII table if interested in seeing the “published” (but not enforced) typical meaning of those characters:
https://simple.wikipedia.org/wiki/ASCII#/media/File:ASCII-Table-wide.svg
Hi @linuxdev ,
Thank you for your message. I went through a few webpages and the suggested stop bits and parity were 1 and none respectively and number of data bits set to 8. Do you suggest that I change these parameters and see if I get any results?
Secondly, I have tried matching these characters with ASCII table. They dont seem to make sense. Ideally, I should be getting some data of this type:
The values are zero because the GPS is currently indoor.
There are no configurable settings for the GPS which could allow me change the format of the transmitted data.
What could be wrong here?
So far as default settings go on the integrated UARTs of a TX2, this is always speed 115200, 8 bits, no parity, and one stop bit. I don’t know with your particular (CH341) UART, but consider that there are always two UARTs involved even if each end only sees one UART. If a UART at either end has the wrong parity or stop bits, then the data won’t be interpreted correctly. The other half of the UART connection is the one in the actual GPS. It does not hurt to try, and there wouldn’t be any damage if settings differ, so it is ok to experiment (two UART connections have to be matching voltage levels, but software settings cause no harm when wrong…they just won’t work as expected).
What you’d want to do is see if you can find the documentation for the GPS itself, and see if serial UART settings can be changed or not. I recall seeing some GPS units in the past that have a fixed UART setting and the other UART is forced to match the GPS’s UART. If that is the case, you’d be able to find documentation on either how to change the GPS’s UART settings, or else the setting for your (CH341) UART which would match the GPS. Should your terminal and the GPS be confirmed to have matching settings, then probably the data you see is correct and it is only how the characters are being displayed which is unusual. On the other hand, if for example stop bits are wrong, then the data is shifting by a byte and showing some control characters as data instead of using it as a control sequence.
FYI, much of what is showing up could be shown as white space or be used as a delimiter between packets. Take something like the 0x13 character…this is a carriage return. Depending on what operating system you are on, this would be interpreted as hitting the “enter” key during typing. Seeing the cursor go to a new line, and seeing hex 0x13, are just two valid different ways of seeing that character. Your serial terminal itself might be doing that. A terminal application on a Mac might view such characters differently than a Windows application, and this would also differ from a Linux application on how it displays. Should all your settings match between GPS and your USB UART, then I’d think it is really not an error to see this, but is instead a choice of the application choosing to show hex instead of interpreting this as white space.
