ZED-F9P to ZED-F9P RTK correction questions

I have been trying to get a rover-basestation setup for a couple days now. My rover does not seem to be respecting the RTCM corrections it gets from the base station.

I have followed this tutorial to the best of my ability:

https://learn.sparkfun.com/tutorials/se … orary-base

however, the ZED module on the rover never gets that RTK blink, or turn of that I am expecting, and the rover never gets above a standard 3-d fix.

I’ve been using u-center to view and configure the devices to some success

I do not believe I have any issues with the QUIIC connectors because I have a sparkfun monitor displaying information that is being received by a Arduino Uno on the base station

In the base station I can see that the scan passed, and that the fix type is set to TIME on the UBX-NAV-PVT monitor.

In the rover, when I view the RTCM input status monitor (UBX-RXM-RTCM) I can see the RTCM messages come through properly, pass the CRC checks, and claim to be used. I can also see the UART2 messages go up on the communication ports monitor (UBX-MON-COMMS).

I have tried taking a common ground and connecting the TX2 on the base station directly to the RX2 on the rover, with no apparent improvement.

Do I need to enable RTCM correction on the rover somehow?

Can the base station help a rover with no-fix get a better reading?

Can RTCM corrections improve a 2d-fix to a 3d-fix?

Does the rover need to have its own 3D-fix to begin RTK mode?

What exactly causes the RTK light to blink/turn off when the rover enters RTK mode?

The above tutorial suggests that only the baud rate for the rover’s UART2 needs to be set to get the RTK mode working, is that really the case?

Help is appreciated

  • SA

Hi @stevena,

RTCM3 input (Protocol In) is enabled by default on the ZED-F9P’s UART2. You do not need to do anything ‘extra’ to enable it. The default baud rate for UART2 is 38400 baud.

The Rover should get a Floating Carrier Solution (Flashing RTK LED) and then a Fixed Carrier Solution (RTK LED off) very quickly with good RTCM3 data.

But the Rover’s antenna still needs to have a good view of the sky and the Rover still needs its own 3D fix. Good RTCM data cannot help a Rover which has a poor GNSS signal.

This sounds like an antenna / signal / sky view problem. Please tell us which antennas you are using. Are both antennas outside, with a clear view of the sky?

Best wishes,

Paul

Thanks for getting back to me, this is info has already been helpful

The rover uses a QGP magnetic antenna very similar to the one suggested in the tutorial

The base station is using a more powerful Tallyman antenna

The GPS signal in my office is super poor, but I can get a signal outside. I’ve stood outside and had a 3d fix with the rover before.

Ill add some checks to make sure the groundstation gets a 3D fix too, and I’ll see if that helps

I also want to make sure I’m understanding you here, if the rover doesn’t have its own 3D fix then the RTCM corrections wont be used?

along the same lines, do the two stations need to be some distance apart to get the RTK mode to work? As part of my debugging network I have been tying the Rx2 line directly to the Tx2 lines so I dont have to work about some potential radio problem, will the rover still get the Floating Carrier Solution this way?

I’ll reply with more updates

  • SA

I stood outside with the two parts to see what type of fix I’ll get

I use an Arduino to manage the monitor for my rover, and the SFE_UBLOX_GPS getFixType() function from the Sparkfun-Arduino library to see my fix. Today I added the same function to the base station to display fix type.

The base station stops its search at 5m accuracy, as per the tutorial

I can verify that the yellow PPS light blinks on both GPS modules

I can see that the rover gets to fix 3, 3D fix, what I was expecting.

The base station is displaying a fix type 5, labeled in my examples as “Time fix only”

Could this be why my RTK isn’t working, or is this what is expected?

Is there something I should to get the base station to get a standard fix, like lowering the accuracy threshold?

-SA

~edited for spelling and grammar

Hello SA,

The QGP antenna looks like it is single band (L1) - but it should still work OK for your rover.

Both base and rover need a clear view of the sky, and both need a 3D fix. RTCM is not a ‘magic wand’ :smiley: . RTCM allows the rover to correct the signals it receives from the satellites to produce a more accurate fix. Without its own 3D fix, the rover cannot use the RTCM.

The base and rover can be very close together. You do not need to separate them. But both antennas need a clear view of the sky. You will need to separate them a little, to make sure one is not creating a shadow for the other. It is OK to link UART2 TX on the base directly to UART2 RX on the rover. Connect GND to GND too. That is the best way to test an RTCM system.

When the base has completed its “survey-in”, it goes into “Time” mode. It is then only calculating time from the satellite signals. It stops calculating position. It uses the location it calculated during the survey-in to calculate the error in the satellite signals. It generates RTCM corrections for each satellite it can ‘see’. The corrections allow the rover to remove the error from its signals and calculate a more accurate position. This only works if the location of the base is fixed. If you move the base antenna during the survey-in, or afterwards, the RTCM messages will be wrong and the rover will not be able to use them.

Check that your base is producing RTCM3 messages 1005, 1074, 1084, 1094, 1124 and 1230. 1005 is the most important one. Check that the rover is receiving all those messages and is “using” them. UBX-RXM-RTCM will show if this is happening. With a clear signal and good RTCM data, the rover fix should go from standard 3D, to a Floating carrier solution, then to a Fixed carrier solution. With an ‘OK’ signal and data, the fix will stay Floating. With poor signal or poor data, the fix will stay 3D.

I hope this helps!

Best wishes,

Paul