# Postcard RTK: Fix instability at speed **URL:** \ **Category:** GPS/GNSS\ **Created:** [May 25, 2026, 6:34pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838 "2026-05-25T18:34:56Z")\ **Posts on this page:** 20\ **Page:** 2
**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:** [July 8, 2026, 3:37pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/21 "2026-07-08T15:37:04Z")
In other Quectel parts the equivalent to the dynamics of the u-Blox is navigation mode $PAIR080: PAIR\_COMMON\_SET\_NAVIGATION\_MODE $PAIR081: PAIR\_COMMON\_GET\_NAVIGATION\_MODE In terms of latency, best way to reduce that is keep the number of hops (MCU/UART in/out) to an absolute minimum, and to use the highest baud rates on wired connections, to fill/empty buffers so the air rate is the only real bottle-neck. The least number of interfaces and buffers the data needs to transition the better. This is kind of why the uBlox ZED’s wanted the radio connected directly to UART2 and avoiding as much intermediary MCU interaction as possible. A Radio that integrates MCU and Baseband is best. Throw away stale data, don’t buffer/retry, UDP with loss is better than TCP with lag. ---
**Author:** ![bamarcant](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/bamarcant/32/9152_2.png) [@bamarcant](https://community.sparkfun.com/u/bamarcant)\ **Post date:** [July 8, 2026, 5:37pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/22 "2026-07-08T17:37:24Z")
Yea,the solution is to have a dedicated port for corrections, you could use a[module](https://www.sparkfun.com/sparkfun-bluesmirf-v2-jst.html) on the third port… As for the dynamics, I also confirm that the fix is lost during even slight changes of direction… > [@PaulZC](#): > > …it does not have a dynamic model setting… (IMHO) Quectel did not implement a motion variile because the [kisilicon](https://community.sparkfun.com/t/sparkfun-gnss-flex-phat-lg290p-some-of-the-ppp-features-not-supported/66349/7) chip ([LG290P](https://kisilicon.com/productinfo/111312.html)) was not designed to process hight motion dynamics;(_perhaps deliberately by the creator so as not to allow for military purposes_). Regards ---
**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:** [July 8, 2026, 7:26pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/23 "2026-07-08T19:26:10Z")
More likely they just didn’t bother to code the tables for the tracking and navigation engines. Would make the coding and testing tasks significantly more manageable. People were doing university level projects capable of 4G, two decades ago, and only needs a 50-60 Hz tracking loop. For 20G you’d likely only need 200 Hz, but you’d lose sensitivity as the integration time drops. The old SiRF silicon was rated for 4G acceleration, 2G/s jerk (20m/s^3), and the 500 m/s and 60,000 feet (18km) limits, the latter being more software level limits, as the satellites are moving at orbital speeds and we’re tracking those. Hopefully with some prodding Quectel should be able to address walking thru UAV speeds without loss-of-lock in the tracking engine. ---
**Author:** ![Jeff\_G](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@Jeff\_G](https://community.sparkfun.com/u/Jeff_G)\ **Post date:** [July 10, 2026, 11:57am UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/24 "2026-07-10T11:57:47Z")
Recommendations for commercially available hardware capable of tracking during dynamic events? ---
**Author:** ![rftop](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/rftop/32/6121_2.png) [@rftop](https://community.sparkfun.com/u/rftop)\ **Post date:** [July 10, 2026, 12:30pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/25 "2026-07-10T12:30:43Z")
@Jeff_G, it might be worth trying older FW on the LG290P. It’s possible there is a snag in the current release. The same goes for RTK Everywhere. LG290P Specs say: ![image](https://canada1.discourse-cdn.com/sparkfun/original/2X/1/1cf8edefa3cac39aa8c7bf574dc9c79f27d3b277.png) Also, it’s not impossible that ThingStream has changed something with their NTRIP delivery of their RTCM stream. My guess is some latency has creeped in somewhere, because the PostCard has been successful in highly dynamic testing in the past. HAS/E6 has been a major focus for the last few FW cycles. Even when priority is given to RTK RTCM, the concurrent PPP-HAS engine might be causing processor conflicts and increased load (enough to create latency) ? So a few things you can try: - Turn off HAS/E6 PPP in RTK Everywhere FW - Test with local BASE/Rover, even as simple as a 2’nd PostCard using ESP-Now. - Downgrade the LG290P’s FW, and maybe even RTK Everywhere (but not likely) I’ve used the same setup (SW Maps, PP RTCM NTRIP over Bluetooth, PostCard) in highly dynamic situations in the past without issue. But I agree with you, it’s not working the same currently. ---
**Author:** ![amlago](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/amlago/32/6128_2.png) [@amlago](https://community.sparkfun.com/u/amlago)\ **Post date:** [July 10, 2026, 1:55pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/26 "2026-07-10T13:55:38Z")
Hi everyone. With my helical antenna, I’ve always had those float changes with abrupt movements, ever since the early firmware versions of the LG290p. I actually got used to it and always tried to make the position changes slow. But it always caught my attention given the published acceleration specifications. And now, since the release of version 2.01, Quectel hasn’t mentioned any updates. There has even been no talk of improvements to the LG290p firmware; for example, there is no more talk of improvements to Galileo HAS. ---
**Author:** ![bamarcant](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/bamarcant/32/9152_2.png) [@bamarcant](https://community.sparkfun.com/u/bamarcant)\ **Post date:** [July 10, 2026, 3:36pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/27 "2026-07-10T15:36:40Z")
_Forse dirò sciocchezze…_ but considering that at 144 km/h you travel for 40m in a second (similar to 1G stopped at 1s), if rtk tracks at 10 Hz (10 readings per second) 40m/10 do 4meters at each reading, here if even you go to 40Hz you have 0.4 per reading which is too much for a solution… Rtk alone is not the way, need others,e.g. imu at **1 kHz** and a dedicated mcu & software. _Regards_ ---
**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:** [July 10, 2026, 4:27pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/28 "2026-07-10T16:27:54Z")
The ~500m/s and 4G are mostly artifacts of ITAR/COCOM, and aren’t things you’re going to be able to avoid without an export license. The acceleration and jerk are more tracking loop limitations and how many orders of motion are modelled in the local code/carrier signal copies fed into the correlators, and how frequently the loop adjusts them to account for local motion. I’m not sure how the ThingStream/Latency issue plays, the base station reporting it’s observations is static, so extrapolating the code/carrier forward to a common observation time for the base/rover shouldn’t be a big issue. It could be the rover is eliminating prior measurements and can’t back-fit the model as the window has moved on. In terms of latency, one could make a local reference station using the ThingStream RTCM3 to anchor it, and then broadcast local RTCM3 over a higher bandwidth link. Or use a much higher bandwidth hard-wired internet connection to ThingStream, and manage the last mile with your own radio distribution. ---
**Author:** ![bamarcant](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/bamarcant/32/9152_2.png) [@bamarcant](https://community.sparkfun.com/u/bamarcant)\ **Post date:** [July 16, 2026, 1:04pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/29 "2026-07-16T13:04:56Z")
Hi Jeff @Jeff_G try a shot… ![immagine](https://canada1.discourse-cdn.com/sparkfun/original/2X/2/27e473e2dca5e8c9570fd911918bd9bf3c367138.png) ---
**Author:** ![rftop](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/rftop/32/6121_2.png) [@rftop](https://community.sparkfun.com/u/rftop)\ **Post date:** [July 16, 2026, 1:37pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/30 "2026-07-16T13:37:46Z")
Marco _( @bamarcant )_, Thanks for telling us about that [Update](https://community.sparkfun.com/t/has-e6-results-on-postcard-fw-v3-1-with-lg290p-fw-v2-01-feb-2026/67988/106) ! Those look like a lot of the improvements we’ve all discussed on this forum. +1 to _Angel (@amlago )_ for sharing it too 😉 ---
**Author:** ![amlago](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/amlago/32/6128_2.png) [@amlago](https://community.sparkfun.com/u/amlago)\ **Post date:** [July 16, 2026, 2:51pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/31 "2026-07-16T14:51:01Z")
Hey everyone, if you try it, let me know if it performs better under high acceleration. Cheers, Angel ---
**Author:** ![Jeff\_G](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@Jeff\_G](https://community.sparkfun.com/u/Jeff_G)\ **Post date:** [July 17, 2026, 12:04am UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/32 "2026-07-17T00:04:22Z")
I updated the firmware and while I can still get it to lose fix and enter float (shaking by hand), it seems to recapture faster and with more precision. It will be a few weeks before I’m back in the field and can repeat my original testing. Much appreciated! ---
**Author:** ![bamarcant](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/bamarcant/32/9152_2.png) [@bamarcant](https://community.sparkfun.com/u/bamarcant)\ **Post date:** [July 17, 2026, 3:37am UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/33 "2026-07-17T03:37:50Z")
> [@PaulZC](#): > > The Postcard uses LG290P. As far as I am aware, it does not have a dynamic model setting… Now there is 2.3.64. PQTMCFGNAVMODE and **the module is capable of rtk even at 20Hz** > **[Quectel\_LG29xPLGx80P\_Series\_GNSS\_Protocol\_Specification\_V1.3.pdf](https://www.quectel.com/content/uploads/2024/09/Quectel_LG29xPLGx80P_Series_GNSS_Protocol_Specification_V1.3.pdf)** > > 1273.29 KB move the default 11 (lawn mower) to 0 or 5 and try both at 20Hz. ---
**Author:** ![PaulZC](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/paulzc/32/67_2.png) [@PaulZC](https://community.sparkfun.com/u/PaulZC)\ **Post date:** [July 17, 2026, 7:58am UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/34 "2026-07-17T07:58:40Z")
Thank you Marco - and Angel I have opened issues for this: > > > Thanks to Angel and Marco, we have LG290P v2.02 \[firmware\](https://community.spa…rkfun.com/t/has-e6-results-on-postcard-fw-v3-1-with-lg290p-fw-v2-01-feb-2026/67988/106) and \[protocol specification\](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/33). > > "Changed the RTCM-1230 message format to the standard protocol." - mentioned by Angel in \[this post\](https://github.com/sparkfun/SparkFun\_RTK\_Everywhere\_Firmware/pull/1048#issuecomment-4998066880) > > PQTMCFGNAVMODE: > \* 0 = Normal mode. (Basic mode applied to most scenarios, for example, driving scenario) > \* 5 = Dynamic flight mode (applied to Dynamic flight mode with equivalent dynamics range and vertical acceleration on different flight phase) > \* 11 = Mower mode (applied to mower application) > \* 14 = Agriculture mode (applied to agriculture application) > \* Default value: > \* LG290P series, LG293P (03) and LG680P (03): 11 (Mower mode) > \* LG580P series: 5 (Dynamic flight mode) > > > Thanks to Angel and Marco, we have LG290P v2.02 \[firmware\](https://community.spa…rkfun.com/t/has-e6-results-on-postcard-fw-v3-1-with-lg290p-fw-v2-01-feb-2026/67988/106) and \[protocol specification\](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/33). > > Significant changes: > > "Changed the RTCM-1230 message format to the standard protocol." - mentioned by Angel in \[this post\](https://github.com/sparkfun/SparkFun\_RTK\_Everywhere\_Firmware/pull/1048#issuecomment-4998066880) > > PQTMCFGNAVMODE: > \* 0 = Normal mode. (Basic mode applied to most scenarios, for example, driving scenario) > \* 5 = Dynamic flight mode (applied to Dynamic flight mode with equivalent dynamics range and vertical acceleration on different flight phase) > \* 11 = Mower mode (applied to mower application) > \* 14 = Agriculture mode (applied to agriculture application) > \* Default value: > \* LG290P series, LG293P (03) and LG680P (03): 11 (Mower mode) > \* LG580P series: 5 (Dynamic flight mode) ---
**Author:** ![PaulZC](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/paulzc/32/67_2.png) [@PaulZC](https://community.sparkfun.com/u/PaulZC)\ **Post date:** [July 17, 2026, 12:14pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/35 "2026-07-17T12:14:51Z")
PQTMCFGNAVMODE was added with firmware v2.01. We missed this… It does indeed default to MOWER mode! Thank you Marco (@bamarcant ). Jeff (@Jeff_G ) : this probably explains your instability at speed…?! I should be able to release the updated LG290P Library today, but getting these changes into RTK Everywhere will take longer. (We are working on some big firmware-update improvements.) Best wishes, Paul ---
**Author:** ![rftop](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/rftop/32/6121_2.png) [@rftop](https://community.sparkfun.com/u/rftop)\ **Post date:** [July 17, 2026, 1:47pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/36 "2026-07-17T13:47:25Z")
Quectel fixing the bitmasks for various birds and bands is a big step too. We no longer have to use the script manually. ---
**Author:** ![amlago](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/amlago/32/6128_2.png) [@amlago](https://community.sparkfun.com/u/amlago)\ **Post date:** [July 17, 2026, 9:38pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/37 "2026-07-17T21:38:26Z")
Hey everyone. I couldn’t resist the urge to experiment with the Postcard. Firmware version 2.02. PQTMCFGNAVMODE value = 5. Frequency of 10Hz. The preliminary results are interesting. Moderate manual movement of the Postcard didn’t produce the classic float; instead, it remained in Fix mode. This didn’t happen before, when any moderate manual movement would cause a float. I didn’t actually test it with high-acceleration movements. But it looks promising. Let’s keep in touch; I look forward to your results. Angel ---
**Author:** ![Ozzieian](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/ozzieian/32/12384_2.png) [@Ozzieian](https://community.sparkfun.com/u/Ozzieian)\ **Post date:** [October 13, 2026, 10:17pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/38 "2026-10-13T22:17:31Z")
**LG290P (v2.02) drops RTK fixed to float under brief high-acceleration motion, no C/N0 or satellite loss: controlled test data** Hi all, I have read your issues and responses. I am developing a wearable sports product using the postcard and it is so, so good until it isn’t. It seems like there is an undocumented jerk limit. To confirm i am on the latest firmware and in mode 5, 10hz. corrections from Auscorrs via ntrip and 4g modem and wifi (not badly aged). Diagrams are from claude analysis of the log file on SD card. I am sending summary data to an android watch over BLE so there is a lot going on here. I understand the workload on the ESP 32 but i see no change based on the complexity and number of NMEA sentences logged. Could there be an antenna tilt issue? I am not a GNSS specialist but i try… Setup - LG290P firmware LG290P03AANR02A02S (v2.02), via SparkFun RTK Postcard (RTK Everywhere v3.3) - Rover mode, 10 Hz fix rate, NAVMODE [5], PPP disabled - NTRIP corrections (RTCM MSM), baseline approx. 12 km, correction age normally 0.6-1.6 s - SparkFun SPK-6E helical GNSS antenna screwed to board. open sky 80 percent, 20 percent occluded at 500m to 20 degrees, GPS+GLO+GAL+BDS, ~40 satellites used - Logged GGA, VTG, GSA, GSV, PQTMNAV Test Antenna in a pouch at the tip of a ~5 m rod (see diagrams). The rod tip was moved up and down in short strokes (peak vertical speed 1-7 m/s). 18 minutes, 68 distinct movements. Repeated at a second site with similar results. ![pole_test_overview_261013](https://canada1.discourse-cdn.com/sparkfun/original/2X/1/1d4ba82e4b7451d060476ab4ee0ca76a3275a929.png) ![pole_test_events_261013](https://canada1.discourse-cdn.com/sparkfun/original/2X/8/8707b53652bbf6d368305810658e0114864ac6a4.png) ![rig_diagram](https://canada1.discourse-cdn.com/sparkfun/original/2X/c/ca55b8695bcafe88ec9c0f3a6c0029fe004068e7.png) ![rig_diagram_2_top](https://canada1.discourse-cdn.com/sparkfun/original/2X/3/310c689f68bec2b5f77adff70c0a700100a276a1.png) with the same result. Results - 42 fixed-to-float transitions, all during movement, none during static periods. - Probability of losing fix rises with peak acceleration of the movement (from PQTMNAV velocity): \<0.5 g: 0 of 27 | 0.5-0.75 g: 1 of 3 | 0.75-1.0 g: 5 of 10 | 1.0-1.25 g: 9 of 13 | \>1.25 g: 13 of 15 - Satellites used unchanged at every transition (34 of 34 checked: identical count 0.5 s before and at onset). - C/N0 unchanged during movements that lost fix vs those that held (~41.5 dB-Hz mean), in all elevation bands, no signals lost (GSV at 1 Hz). - Correction age normal at onset in most cases. - Onset coincides with peak acceleration of the stroke (median within 0.1 s). AltStd starts rising ~0.2-0.3 s before GGA changes to 5. - Float height error vs integrated vertical velocity: median 2.4 m, max 7.4 m. - Recovery: half of events last \>4 s; a cluster at 5.4-6.3 s. Questions 1. What triggers the ambiguity reset here, given tracking and C/N0 appear unaffected? Is there an acceleration/jerk or innovation threshold in the RTK engine? 2. Which PQTMCFGNAVMODE value is recommended for a human-carried antenna with rapid vertical motion? Is mode 0 or 5 expected to behave differently? 3. Is there any parameter (PQTMCFGRTKRL or other) that relaxes the reset criteria or shortens re-fix time? 4. Has dynamic RTK hold changed between firmware versions? SparkFun issue #1031 reports earlier firmware held fix better while moving. I can share the full 10 Hz log. ---
**Author:** ![sparky](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/sparky/32/6021_2.png) [@sparky](https://community.sparkfun.com/u/sparky)\ **Post date:** [October 14, 2026, 3:44pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/39 "2026-10-14T15:44:03Z")
In short, as of a few weeks ago with LG290P firmware v2.1, I have similar results: RTK Fix is lost with kinetic movement of a few 0.1 m/s. My solution was to switch to the ZED-X20P. The results were stark - the X20P was able to maintain RTK Fix under much more extreme conditions. Your good questions about acceleration/jerk and thresholds are sound, but those really can only be answered by Quectel. > Has dynamic RTK hold changed between firmware versions? SparkFun issue #1031 reports earlier firmware held fix better while moving. In our testing, all previous version of the LG290P firmware have this issue - the RTK engine within the LG290P seems to not handle movement as well as other engines. Perhaps they can fix it in a future firmware release, but as of 2.1, it’s pretty rough. ---
**Author:** ![rftop](https://yyz1.discourse-cdn.com/sparkfun/user_avatar/community.sparkfun.com/rftop/32/6121_2.png) [@rftop](https://community.sparkfun.com/u/rftop)\ **Post date:** [October 14, 2026, 5:24pm UTC](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838/40 "2026-10-14T17:24:10Z")
Yesterday I took a few minutes and reverted the LG290P on a PostCard back to `LG290P03AANR01A04S.pkg`. It still lost RTK Fixed with fast human movement. I have driven hundreds of miles at 85 mph with a LG290P remaining in Fixed mode previously. I don’t know what has changed. I had assumed a snag was created during the Quectel FW progression for HAS/PPP, but A04 should still work if that was the case (IMHO). My next “theory” is the correction source. My previous successful testing was using PointPerfect RTCM, which has subsequently been re-branded as PP Flex. It’s my understanding that nothing was changed however. I cant remember if I tested any of the Statewide CORS services at highway speeds or not (around the same time), unfortunately. This previous testing might have aligned with some of the LG290P configuration changes we were testing for HAS/E6. I have some notes, but **nowhere** near all of the configuration changes documented. It’s frustrating because I know the RTK engine in the LG290P is capable and able to provide RTK Fixed solutions at speed and through “normal” acceleration…but I cant reproduce that ability now ☹ [Previous page](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838.md?page=1) [Next page](https://community.sparkfun.com/t/postcard-rtk-fix-instability-at-speed/68838.md?page=3)