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.
