# ZED-F9P RTK with PointPerfect - Correction Data Not Always Applied? **URL:** \ **Category:** GPS/GNSS\ **Created:** [December 5, 2024, 3:35pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157 "2024-12-05T15:35:53Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Bitnut011](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/bitnut011/32/7507_2.png) [@Bitnut011](https://community.sparkfun.com/u/Bitnut011)\ **Post date:** [December 5, 2024, 3:35pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/1 "2024-12-05T15:35:53Z")
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: ```bash $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: ```bash $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! ---
**Author:** ![clive1](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/clive1/32/6396_2.png) [@clive1](https://community.sparkfun.com/u/clive1)\ **Post date:** [December 5, 2024, 4:17pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/2 "2024-12-05T16:17:19Z")
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? ---
**Author:** ![clive1](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/clive1/32/6396_2.png) [@clive1](https://community.sparkfun.com/u/clive1)\ **Post date:** [December 5, 2024, 4:21pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/3 "2024-12-05T16:21:15Z")
I’d guess you’re in Europe, this is illustative of the coverage areas when I originally sampled them. > **[RandomNinjaChef/uBloxSPARTN at main · cturvey/RandomNinjaChef](https://github.com/cturvey/RandomNinjaChef/tree/main/uBloxSPARTN#gad-maps)** > > This is a general parking space for forum related code posts which is safer from forum transitions, damage, and loss - cturvey/RandomNinjaChef ---
**Author:** ![clive1](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/clive1/32/6396_2.png) [@clive1](https://community.sparkfun.com/u/clive1)\ **Post date:** [December 5, 2024, 4:23pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/4 "2024-12-05T16:23:12Z")
> **[Not able to achieve RTK Float or Fix, UBX-RXM-COR shows messages are being...](https://support.thingstream.io/hc/en-gb/articles/10688387744924-Not-able-to-achieve-RTK-Float-or-Fix-UBX-RXM-COR-shows-messages-are-being-decrypted-but-not-used)** > > It can be confusing to see UBX-RXM-COR correction messages being "decrypted" but "not used". There could be two scenarios for this, which are further explained below. Scenario 1 is the usual scenar... 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. ---
**Author:** ![Bitnut011](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/bitnut011/32/7507_2.png) [@Bitnut011](https://community.sparkfun.com/u/Bitnut011)\ **Post date:** [December 7, 2024, 4:54pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/5 "2024-12-07T16:54:03Z")
_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. 😁 ---
**Author:** ![btreichel](https://avatars.discourse-cdn.com/v4/letter/b/eb8c5e/32.png) [@btreichel](https://community.sparkfun.com/u/btreichel)\ **Post date:** [December 9, 2024, 4:59pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/6 "2024-12-09T16:59:39Z")
Yes, thats seems to be a symptom of the problem described in your dec 5th post. ---
**Author:** ![QuickBit](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/quickbit/32/7846_2.png) [@QuickBit](https://community.sparkfun.com/u/QuickBit)\ **Post date:** [December 14, 2024, 11:01pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/7 "2024-12-14T23:01:17Z")
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. ---
**Author:** ![clive1](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/clive1/32/6396_2.png) [@clive1](https://community.sparkfun.com/u/clive1)\ **Post date:** [December 15, 2024, 2:51pm UTC](https://community.sparkfun.com/t/zed-f9p-rtk-with-pointperfect-correction-data-not-always-applied/62157/8 "2024-12-15T14:51:05Z")
Or understand why you aren’t getting viable data in over 4 minutes… 0x201100C4 CFG-NAVSPG-CONSTR\_DGNSSTO 8-bit U1 setting