Processing RTCM bytes in Rover

Hello all,

I am using two Arduino boards connected to two Sparkfun ZED F49P. The two Arduino boards are connected to each other via UART. One of them acts as a base station while the other acts as the Rover. From this repo (https://github.com/sparkfun/SparkFun_Ub … es/ZED-F9P), I am using Example 3 and Example 5 as the base codes for the base station and rover, respectively. I have done some slight modifications in both of the codes like adding some header to identify the start of the RTCM-packets and so on.

I can successfully transmit the RTCM bytes from the base station. On the rover side, I look for the headers to identify the start and end of the packets. I store all the bytes on the packets and push the bytes using “myGPS.pushRawData(((uint8_t *)&store), numBytes)”. The push is successful, or at least it says the push is successful. But I am not getting the relative position. It is printing out zeros with “None” as carrier Solution Type. Can anyone please explain the correct way to push the data or store the data before pushing?

Yunish

capture.PNG

Hi Yunish,

Have you removed the header before pushing the data to the ZED?

Can you try a test where the base does not add a header, and the rover pushes all bytes to the ZED. Do you get a differential solution then?

You need to make sure you are not dropping any bytes, or adding any. The “Serial1” example code shows what you need to do.

Then please check both ZEDs have a good GNSS signal. You will need to be outdoors. Dual-band (L1+L2) antennas will help too.

Best wishes,

Paul

Thank you Paul for your reply. Yes, I have removed the header before pushing the data into the ZED. I tried without using the header initially. With that, it would push the bytes before collecting all the bytes in one packet, like only 4 bytes at a time. Should all the bytes be collected before pushing into the ZED? Also, the number of bytes fluctuates in each packet. I think that is because I have enabled different message types (1005, 1074, 1084, 1094, 1124 and 1230). Should I enable only one RTCM message?

Both ZEDs have an accuracy of around 5 meters.

Hi Yunish,

Pushing the bytes as you receive them should be OK. So long as you don’t drop any…

u-blox recommend: 4072.0, 1074, 1084, 1094, 1124, 1230

See section 2.2 in:

https://www.u-blox.com/sites/default/fi … 093%29.pdf

Best wishes,

Paul

Thank you Paul for the documentation. I was implementing the UART communications using Arduinos rather than the UART provided by ZED-F9P’s UART 2 pins. Is “Serial1” defined for the UART2 connection in examples 3 and 5 in the GitHub repo?

Hi Yunish,

It depends on which board you are using. Most use “Serial” for the console (Serial Monitor) and then provide an extra hardware serial port on Serial1. Others use SerialUSB + Serial. Please change Serial1 to whatever hardware serial port your board supports.

Best wishes,

Paul

Hi Paul,

Thank you for the response. I am aware of the Serial1 and Serial commands for the Arduino. But, if I connect directly using UART2 in ZED F9P (as shown in Figure 16 of “https://www.u-blox.com/sites/default/fi … 093%29.pdf”), what command should I use to push the bytes into ZED F9P?

Yunish

Ah, OK.

You can use a simple Serial.write. I recommend write, not print, as write handles the binary format better.

Best wishes,

Paul

Hmm. If I am utilizing the UART 2 connection to push RTCM bytes (connecting TXD2 of the base to RXD2 of the rover), without using Arduino’s UARTs to establish the communication between base and rover, are the bytes received by RXD2 automatically used to compute the relative position?

Yunish

Yes. Please re-read the u-blox application note. You may need to use u-center to make sure that the UART2 on the rover is configured to accept RTCM data.

Paul

Thanks. I got it to work. However, I was not able to use the Example3_StartRTCMBase from the new reop with the Arduino Micro I have due to the larger size of the sketch file. What is the difference between the latest one and the one from the archived repo? I see the use of “packetUBXNAVSVIN” in the newer version. Will this affect my survey-in process?

Hi Yunish,

Yes, the code size is a lot larger with the new v2 u-blox library. But you can still continue to use v1 if you want to.

Please see:

https://github.com/sparkfun/SparkFun_u- … ibrary#v20

The old library is here:

https://github.com/sparkfun/SparkFun_Ub … no_Library

The old examples are here and will still work OK for you:

https://github.com/sparkfun/SparkFun_Ub … rtRTCMBase

https://github.com/sparkfun/SparkFun_Ub … nformation

Best wishes,

Paul

Great. Thanks, Paul.