Serial Communication update problems and RTCM3 msg format

I have two Reach RTK GNSS modules that I am planning on using for robotic autonomous waypoint navigation. One robot will act as a base station while the other is a rover. I have been able to connect the sensors using the micro USB and setting a serial communication with a ROS package to convert the NMEA format to standard ROS sensor topics. However, the most recent update v2.18.0 caused the lsusb and ls /dev port name to vanish. The module showed up as a ttyACM port now no new port appears. Does anyone know of a fix to this problem?

My second question is how to get corrected values if the sensors are connected over serial. The input corrected values is in a different format RTCM3, and I would like to use the robots own network. I am unfamiliar with the RTCM3 format. Can I send that message format over serial to the network of the second robot back to serial again? How do the modules actually communicate for the corrected GPS values?

Hi @twpietrzyk,

We’re working on the fix for this issue now. I’ll inform you once it’ll be available.

The scheme you’ve described sounds feasible. You can also transfer corrections via TCP, for example.

Could you please clarify your question?
Usually, base unit output RTCM messages, while the rover unit inputs them. It’s one-way communication.

The base station will output an RTCM3 message format, and the rover will have to receive that same message format from the base station as an input. Can I send both RTCM3 and NMEA message formats through serial?

Can I have two serial connections for the rover module. One connection to be the input RTCM3 correction, and the second to provide the NMEA message output? I was considering using the micro USB for and input with one of the other two connection ports using a USB to UART interface.

Hi @twpietrzyk,

Sure, Reach can input RTCM3 and output NMEA over Serial simultaneously. You can use one UART port for this.

1 Like

Hi @twpietrzyk,

We pushed the v2.18.1 stable update with the fix for your issue.
Please let me know how it works.

Thank you it worked.

On a side note do you know what the message format is for the RTCM3 message. I know that only 1002 and 1006 is needed. My current setup is one Reach module is connected to my computer sending RTCM3 messages to the USB, while the rover module will have the correction input over USB and provide the output location through UART. I have a TTL chip connected to the UART port with only TX, RX, and ground populated. I have a cpp driver written for the /dev ports to read or write to the sensor. I am unfamiliar with the RTCM3 message format, and I would like more information. I am using the serial ports from the sensors due to the simplicity of having only one network.

Hi @twpietrzyk,

Great to hear it helped. :slightly_smiling_face:

1002 and 1006 is a minimum required set. The 1002 message provides ARP station coordinate. The 1006 message contains GPS L1 observations.

Depending on which satellite systems you use, you may also enable optional messages for other GNSS.

You can read more about supported RTCM3 messages in our docs.

Can I setup a UDP server client for the RTCM3 communication between the two sensors? I would like to use the robots network. Currently I have cpp serial drivers written for the base and rover sensors. I don’t know the byte format for the RTCM3 message. So can I send the whole message straight from serial to UDP, or would I need to configure a specified number of bytes to be read for the 1002 and 1006 message formats?

Hi @twpietrzyk,

UDP communication isn’t supported in the ReachView. However, you can use the TCP option instead.

Do you want to create your own script that provides UDP communication?

I’m afraid I hardly can help you a lot with this question. Still, if you need to calculate the size of transmitted data, you can find an estimation of bytes/sec for 1 satellite when messages are configured at 1 Hz in our docs.

1 Like

I did get the modules to work with the TCP settings in the reach view application. Thank you for all your help.


When I was testing the Reach Modules the status always displayed Float. How do I get the status to be Fixed for higher accuracy?

Also when in base mode for the “Average Fix” data, what is the sensor looking for? I know it is a fix value, but from another sensor? Is there an advantage to “Average Fix” over “Average single”?

Do you do your testing inside? It will need a good unobstructed skyview to get a fix-solution.

It is simply a an average of the fixed solution coordinates over a given time. RMSE for this will like be below 0.005 meters.
If you did this with Single solution coordinates, your RMSE would likely be 1.5-2 meters.

Yes I tested the sensors outside in a open field. I have the base station currently configured to “Average single” would changing the setting to “Average Fix” result in a Fix status?

Hi @twpietrzyk,

You can use the Average Fix option if your base unit is getting corrections from another reference station (NTRIP, for example).