Hi,
I’m currently facing problem to get emlid reach rover and base to talk via serial uart for my project.
setup: Rover module talks to onboard computer via usb-uart cp2102 : 38400, 8,N,1 (OFF,OFF) : position output in NMEA and base corrections in RTCM3
Base Module connected to wifi sends RTCM3 base corrections over tcpsvr localhost:9000 and posiiton output over localhost:3000
onboard computer : Listens to base corrections over same wifi and has RTKLIB str2str receiving base corrections and sending them over serial://ttyUSB0 over cp2102 usb to uart connected to rover emlid reach module.
command used
os used: UBUNTU 16.04 X64
./str2str -in tcpcli://192.168.1.10:9000#rtcm3 -out serial://ttyUSB0:38400:8:n:1:0ff -msg 1002,1006,1010
or
./str2str -in tcpcli://192.168.1.10:9000#rtcm3 -out serial://ttyUSB0:38400:8:n:1:0ff#rtcm3 #verified base corrections output using st2svr gui on windows system.(output to serial doesn’t work here too) #verified output from str2str using -out in a file and even -out to another uart device
Problem:
I’m able to receive data from emlid reach via serial like NMEA position output., but not able to send data to reach module. #tried ssh into reach >> installed pynicom >> no data observed #reach app logging doesn’t record any data sent by str2str #reach app input corrections tab says connected to ttyMFD2 but doesn’t show received data while at the same time if I configure additional corrections to tcpcli://(base-rover):9000 it receives data.
Tried on both reach app 2.9.x and 2.10 - no luck
Tried loop back test on usb uart cp2102 #test positive - receiving data
Tried str2str from original RTKLIB and emlid fork version of RTKLIB
Tried with different Emlid reach devices - no luck
Tried str2str from a local rtcm3 file to reach device over serial no luck.
Tried with usb to rs232 (hawking H-UC232S ) (logic level 7v ) - receiving position output, but not able to send base corrections.
Tested with usb-uart cp2102 logic level 3V and 5v modes - no luck.
#most of the content pn forums were focused on connecting uart to RF link, but not directly.
Here I’m using trying to use it on uav (NOT BASED ON PIXHAWK, so I cannot use gps injection as mentioned) and don’t want to have additional rf links due to other aspects of the project.
Could you help me to send and receive base corrections and postion output via uart.
what is the best way to send rover NMEA to base.
Is it maybe because you can’t have two programs use the same serial port?
Well, maybe you can, but there are always problems when you try.
You need one program to access the serial port. Then that does the separation by taking input from one program and sending output to a different program.
I haven’t messed around with str2str, so I don’t know if it is capable of that. I think you can do it on the command line with netcat and separate file descriptors for the input and output streams. Let the search engines guide you! (because I can’t remember right now )
The same port if locked by one program cannot be used by another as you said.
But emlid in the backend used forked version of RTKLIB which has rtkrecv and str2str which takes care of all protocols available in front end version of reach app.
Uart is bidirectional and a single program can send and receive data. If used in flow control or interrupt based multiple programs can access serial port for bidirectional data. And str2str foesnt lock the port, as I have tried minicom and str2str simulateously. Im hoping someone at emlid or in the forum who used this before could help.
OK, disable rover position output temporarily. Also disable the listening for position output on your onboard computer. Then just concentrate on sending your RTCM3 corrections through from the onboard computer over the serial port to the rover.
If that works, as seen by grey bars on status page of ReachView, then try adding the position output to the serial port and see if that breaks it again.
Also don’t forget you can use the screen program for many things, including interacting with the serial ports: screen /dev/ttyMFD2 38400
(launches a full screen window connected to the serial port - but make sure when you logged in, you were a member of the dialout group or use sudo or root) CTRL-a k y <-- kills the screen window
before you monitor a serial port, check to make sure it is not being used already: fuser /dev/ttyMFD2
I checked that too, no luck.
For some reason emlid is not receiving the data sent.
Verified the same without any programs listening to tyymfd2 and with pynicom on reach to listen on ttymfd2. Checked sent data on reach app logging and input corrections tab.
I remember spending a whole day on serial port problems, and I was my own worst enemy
Go to absolute basics then. Run that screen program on each side and type into the serial port and see if you get characters on the other screen.
use the program stty on each computer and look for problem setiings like software flow control. stty -F /dev/ttyMFD2 stty -F /dev/ttyUSB0
change any suspect settings to match the other end. confirm the baud rates are equal. once you can make characters pass both ways on the screen, then it should all be downhill from there!
don’t forget to be sure that no other program is using the port. Use fuser command above and kill any other process using your serial port.
sometimes this problem can drive you nuts. If you have a logic analyzer probe or oscilloscope, you can probe the TX and RX lines to see if data is being transmitted. When I was tearing my hair out, I even went as far as making up an LED circuit to show the logic levels of all the serial port pins. I have one old serial connection that is used heavily all day, every day, and every time the computer is rebooted I have to issue a serial port reset command to get it going (different operating system though). All I mean by this is that I understand your frustration, and I hope to find out that you made some progress when I check in tomorrow. Good luck!
Thanks Bide,
I completely understand what you mean.
I remember when I used just pynicom on both sides and when I sent data from my laptop over serial first two bits were received and then my system started receiving position output and then it couldn’t transmit anything to reach. But anything I type on reach pynicom was getting transmitted to my laptop different byte at different times along with nmea strings.
I try in the morning without position output.
#tested logic levels too😜 #tested with software flow control too #next thing I didn’t want to do is implement serial uart using interrupts between two programs trying to share same serial port.
#I didn’t try oscilloscope but tried to transmit data from one laptop to another laptop over serial uart converters. Data is getting transmitted.
If I got it all correctly, you are trying to connect to the base’s serial port and forward this information into a cp2101 converter. I assume you have a Reach module connected to it.
Please, post a simple system report. Let’s check the settings first.
Second, check the wiring. Try sending NMEA from the rover’s side and opening ttyUSB0 with screen from the PC side.
If all this works, I suggest running str2str without protocol conversion(the #rtcm3 part).
Thanks for replying and yeah right images are better than words any day.
USB to pc option works beautifully, after testing uart for many hours and I finally tested usb option (usb driver handles bidirectional flow efficiently and it worked with netcat.
USB also connects as Ethernet so it’s good way to connect even via tcp directly.
Catch here is usb option keeps on disconnecting and reconnecting automatically, due to nature of usb driver I suppose on computers(it usually doesn’t occur with usb option with power banks)
So once it disconnects it has to average again to get fix Incase if base rover and this disconnecting Behaviour can also be aggregated due to drones movement or if any other device like camera draws more current from usb the kernel powers off usb for cycle and it’s bad for robot to loose gps in flight and due to some reason if serial port is locked by a process before it got powered off. It’s a kind of less robust.
So that’s the main reason, I wanted to resort to good old serial uart
I’ll upload system report today
Heads up: I checked stty on both rover and my laptop
Set all settings using stty
Still it doesn’t accept incoming data for some weird reason.
If you are running Linux on your PC, it should be because you lose your IP address on the usb interface. The simplest solution for it work stable is constantly reconfigure the interface using watch. Something like watch sudo ifconfig enpxxxxx 192.168.2.2
If this works for you, I’ll think of a better way to achieve stable connection.
)
= 1000 words