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.
Yea,the solution is to have a dedicated port for corrections, you could use a module on the third port…
As for the dynamics, I also confirm that the fix is lost during even slight changes of direction…
(IMHO) Quectel did not implement a motion variile because the kisilicon chip (LG290P) was not designed to process hight motion dynamics;(perhaps deliberately by the creator so as not to allow for military purposes).
Regards
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.
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.
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.
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
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.
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!
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.)
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
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…
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.
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
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?
Which PQTMCFGNAVMODE value is recommended for a human-carried antenna with rapid vertical motion? Is mode 0 or 5 expected to behave differently?
Is there any parameter (PQTMCFGRTKRL or other) that relaxes the reset criteria or shortens re-fix time?
Has dynamic RTK hold changed between firmware versions? SparkFun issue #1031 reports earlier firmware held fix better while moving.
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.
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
