Hi folks - I haven’t had a chance to play with it yet, this is hot off the presses. RTKHOLD is an interesting new feature where they boast 10 minute RTK fix once corrections have ceased. Might be helpful in areas with dense foliage with open patches.
I wanted to follow up regarding the new RTKHOLD feature included in the latest LG290P firmware (LG290P03AANR01A06S, linked below). This feature uses advanced prediction models to maintain centimeter-level accuracy for up to 10 minutes after RTK correction data is lost/paused/stopped.
Flash the R01A06 FW which supports this feature
Set the RTK timeout to 600 seconds by sending the command:
$PQTMCFGRTK,W,1,1,600*76
Then save the parameter using:
$PQTMSAVEPAR*5A
Reset the receiver, provide correction data, and wait for it to reach RTK fix. Once it is in RTK fix, stop providing the correction data for up to 600 seconds. During this period, check the RTK fix status and observe the accuracy to evaluate the hold performance.
If you give it a try, please report back about what you experienced. Note - this firmware is best for the LG290P breakout. For now, our RTK Everywhere firmware is not aware of this version so it may work, it may not on RTK Everywhere devices (ie, Postcard).
I understand it mostly for a use in areas with poor cellular coverage to overcome white areas.
For comparison, ublox F9P is maintaining fix for 60 s after correction stream loose. If PointPerfect corrections are also provided, RTK is maintained for 4 minutes after RTK corrections are lost. So, 10 minutes for LG290P is a significant step forward. Do they use additional data? (like Galileo HAS?)
Hi @sparky
I think this firmware doesn’t support Galileo HAS.
It was sent to me by Quectel a few weeks ago ( 20/10/25), and they had removed the Galileo HAS fixes that were included in the beta versions. Aside from the RTKHOLD function, I don’t know what other significant improvements it has. Since it didn’t have the Galileo HAS fixes, I didn’t test it further.
Thanks for sharing.
Regards
The very interesting feature is the cryptographic autentication of signals against spoofing…
…added support for Galileo OSNMA ?!
for the LC29HAA there is related documentation; but for our module I do not know.
As Angel said few months ago here for Galileo Open Service Navigation Message Authentication (OSNMA) .
Anyway thanks @sparky, if there is a newer gnss_protocol for v6, please share it into the repository.