ZED-F9P RTK with PointPerfect - Correction Data Not Always Applied?

GPS/GNSS
1

Hi all,
I’ve been testing my ZED-F9P module with RTK corrections from PointPerfect, but I’ve encountered an issue where it seems like the u-blox module doesn’t always apply the correction data. During these times, the horizontal and vertical precision values increase significantly, and the “last correction age” is shown as 0.

I’m using the SPARTN 2.0 data format via the MQTT protocol. The data is sent from a computer through the USB interface to the ZED-F9P. To handle the data transfer, I’m using the Python script provided by PointPerfect.

Here’s an example of the feedback I get when the system works correctly:

$GNGGA,150930.00,****.22402,N,*****.49550,E,4,12,0.56,207.0,M,36.8,M,8.0,0000*6A

And when it doesn’t work:

$GNGGA,001207.00,****.18941,N,*****.52992,E,2,12,0.55,207.0,M,36.8,M,,0123*48

**** - used to hide location

Has anyone else experienced a similar problem or found a solution? I’d appreciate any advice or insight into what might be going wrong.

Thanks in advance!

2

I’ve primarily worked with the L-Band data source. There I and others in the USA Midwest have observed periodic outage of service, where the L-Band basically transmits dead-air for hours, ie all data frames 0x13 bytes.

It’s going to be hard to say without actual salient data what specifically is going on. Most likely would be a mismatch on the dynamic keys and a failure to decrypt the stream. I’d perhaps look to UBX-RXM-SPARTN,COR to understand what packets it is and is not taking, and UBX-NAV-SIG,SAT to see satellite level application.

I’m not sure if the IP stream is selective, there’s 30+ zones in the USA GAD, if there’s a mismatch in your location vs the zone furnished, that’d be a problem.

If you use the uCenter Classic MQTT Client do you see similar issues?

3

I’d guess you’re in Europe, this is illustative of the coverage areas when I originally sampled them.

4

As someone who’s built a stand-alone L-Band decoder/decrypter it shouldn’t be unduly hard to determine if the decryption keys, and decryption is in fact viable. There’s no secondary authentication however of the plain-text, only the cipher-text is checksummed via a CRC24Q, but there are enough tells as to whether you’re grinding metal, or have viable data.

5

If you use the uCenter Classic MQTT Client to you see similar issues?
I have to try with uCenter or pygpsclinet.

Thank you for sharing your experience. I’ll investigate the issue further. Your detailed feedback is very helpful, and I’ll provide updates once I have a solution. :grin:

6

Yes, thats seems to be a symptom of the problem described in your dec 5th post.

7

I found out recently that there is a configuration option “DGNSS timeout” in the firmware that is by default set to 60 (seconds). Seems like after that time of no correction being received it switches to normal GNSS, and information about last correction is removed. I was able to extend that time to maximum value of 255.

8

Or understand why you aren’t getting viable data in over 4 minutes…

0x201100C4 CFG-NAVSPG-CONSTR_DGNSSTO 8-bit U1 setting