Hi @Rftop
I’ve been posting my problems on the Quectel forum.
This support guy, @yonghuang, took an interest in the issue. He asked me a few days ago for a log with the NMEA file showing the problematic times.
Today he emailed me version 2.01 with the debug add-on. It seems larger, and I thought about installing it for a while.
But before installing it, I decided to try the latest beta, which I thought would give me better results.
And it did.
I’ve been getting good results all day, even with high TECU values.
The solution converges in about 15 or 20 minutes and remains quite stable. And what worried me a lot, which was the loss of HAS corrections with version 2.01, hasn’t happened with the beta version.
@amlago - Can you email me a copy of the beta firmware you received? I’ll get it posted and give it a try as well. I too am frustrated with the v2.1 (LG290P03AANR02A01S) performance today.
Hi @sparky
I’m not sure if that was clear. Remember my translator.
They sent me the same 2.01 with debug options, which I didn’t install.
The one working much better for me is the previous beta we already had: .LG290P03AANR01A06S_PPP_TEMP1107.pkg
It really works much better, giving me good results most of the day, and when the results are off, it’s only for a short time and no more than 50 or 60 cm.
With version 2.01, I was losing corrections and getting differences of several meters.
But I’m sending you the firmware they sent me, and you can try it.
From the experience I had and I talk since the version
06S_PPP_TEMP0829 , I remember the algorithm hold the position even suddenly switching from rtk to ppp and vice versa (in the presence of rtcm corrections), with the latest version (really since NR01A06S) this is no longer possible, in fact if convergence is lost even for a moment it requires another twenty minutes for the full re-acquisition.
Seem the _beta’s have a sort of ppp_hold algorithm that the final do not have.
Regards
I’m about to be travelling with no way to test, but can someone try :
$PQTMCFGPPP,W,1,1,120,1.0,1.0*5D
We were previously initializing the PPP engine with 120s holdover (which should have worked), but V2.01 drops the fix after missing 1-2 seconds of E6 data. The culprit might have been the previous 0.10m H & V thresholds we were using. It may be worth changing the thresholds to 1m and fine tune if that helps.
This is a long-shot, as the PPP engine shouldn’t drop the entire convergence when the uncertainty drifts above the threshold.
OR, the V2 FW doesn’t obey the Holdover parameter. Either would be an easy fix for Quectel.
$PQTMCFGRTK,W,1,1,15*44 for send noise in rtcm to divert PPP convergence
First I used an helical antenna like 6E
result, the convergence occurred fast but differential age goes to 180 and loose ppp
so changed with “default” helical antenna the one like Q50
and voilà, the differential age goes lower
then reverted to my defaults $PQTMCFGPPP,W,2,2,90,0.01,0.01*54
and now, not quickly, but after 15min ppp converged in a stable situation and the differential age is 2.1 to 12
so leaved rtcm inj. and rtk hold respect the 15 age imposed
re-converge after 15 min
now the matter is when I change to $PQTMCFGRTK,W,1,1,1*71 the module do not hold
ppp neither rtk and seat in a unstable situation
not an issue, but the older firmware revert istantanely to a ppp or rtk solution. so after leave noise (i.e. close rtcm inj.), the module takes other 15min to ppp.
P.s I’m trying out some radios Cdebyte sent me “E62-433T30D” …
Hi everyone. The LG290P03AANR01A06S_PPP_TEMP1107 firmware definitely works much better in my area (Uruguay) than the latest v2.01.
This afternoon, with a heavy drizzle, convergence occurred between 15 and 20 minutes, and I obtained many values below 20 cm and several between 20 and 30 cm, which at this stage of the investigation seem quite acceptable to me.
Something was different in v2.01.
Regards
Has anyone been able to verify that the beta version LG290P03AANR01A06S_PPP_TEMP1107 works better than the latest version 2.01?
I’m very interested in your conclusions.
Regards, Angel
I think didn’t quite understand what you were trying to explain. I’m currently working with a Mozihao board and a JDY 23 module for Bluetooth. Therefore, I’m not able to physically disconnect the COM port.
Unless you meant via the application. I’ll go into detail about my procedure. I connected to my GNSS receiver via Bluetooth, configured it using Serial Bluetooth Terminal, and then restarted it. I established the GNSS to smartphone connection via GNSS Master because SWMAP seemed to have difficulties with my BLE Bluetooth module (JDY-23). Using SWMAP, I was taking a continuous reading with one point every 5 seconds.
If I understand your advice correctly, I should re-establish communication with the LG290P after convergence to obtain only the corrected data. I’d have to retest, but if I remember correctly, I’ve left my LG290P alone several times, disconnected from my smartphone, then reconnected it after 30 minutes, and found that swmpas and gnss master always showed 80cm and DGNSS.
I’ve put everything on hold now. I’m going to review my setup because I have several issues. There’s oxidation on my antenna cable. For the sake of compactness, I removed my SMA connector and connected a direct cable (my chipsets are in the antenna housing). I’m thinking of using iPEX instead, but I’m not very optimistic because even with the SMA connector and the old firmware (version 06), my results were also disappointing. I’m also going to replace my Bluetooth module. The choice of the BLE protocol is causing me problems with swmap, and my JDY 23 doesn’t accept baud rates higher than 38400 (which isn’t listed as supported in the Quectel documentation, but my module did accept it). I’m currently waiting for the parts. I might get a license for Landstar 8, which seems to offer more possibilities than swmaps.
Furthermore, I’m abandoning my idea of using the LG290P as a temporary base station using Galileo HAS to provide decimeter corrections to my LC29H rover. Given the good ntrip coverage in France, the RTKHOLD and long baseline functions should cover 90% of the needs. I’ll continue testing out of curiosity once I’ve reviewed my equipment, as HAS could meet the remaining 10% of requirements, and it remains an interesting technology, still under development, and one that’s worth mastering… especially with low-cost equipment.
I’ve seen this article circulating in the last few days, and it looks like some pretty wild things are going to develop around GNSS technology, and things are likely to move very quickly.
@2M2C , I appoligize… I assumed you were using QGNSS and the Deviation Map. Yes, I was referring to disconnecting the App after convergence - then reconnect to only show the converged positions.
That makes me think that you might not be getting the HAS/PPP engine started on the LG290P.
The module should be reporting a RTK Float solution in the GGA sentence once PPP has converged.
I performed a systematic “Antenna Dump” stress test on the LG290P (Firmware NR02A01S) to verify the Galileo HAS holdover capability is broken. I used a breakout LG290P (not the PostCard) for these tests to be in complete control of the module.
To ensure a clean test, I configured the holdover timer and accuracy thresholds using: $PQTMCFGPPP,W,2,1,110,0.0,0.0* (110s Timer / 0.0m “Infinite” Thresholds).
Why 0 meter thresholds?
The 0m (Infinite) thresholds were used to “blind” the receiver’s safety manager. By removing any accuracy limit, after convergence the module should (in theory) stay in a Float Fix (GGA 5) for the full 110 seconds, regardless of how much the position drifts. This was intended to isolate the Holdover Timer as the sole remaining constraint.
The $PQTMCFGNAVMODE Test Results:
I tested various $PQTMCFGNAVMODE bitmasks (values 0, 5, 11, 12, 13, and 14) to see if any specific engine priority would prevent a PPP reset. The results were consistent across all values:
Universal Filter Reset: Regardless of the bitmask or the “infinite” accuracy threshold, the Navigation Filter performs a Hard Reset the instant the E6 signal is lost. In every test, the module dropped to Fix 1 (SPS) or Fix 0 (No Fix) before attempting to recover.
Ghost Timer (Field 13): During the 1-2 second outage, the Age of Corrections correctly continues to count up (e.g., 10, 15, 20) as expected. This proves the background data task is active and “remembers” the timer, but the Positioning Engine ignores it and flushes the PPP convergence.
Discontinuous Recovery: The module will quickly “re-converge” to a GGA Fix 5 with these extreme settings, but it results in a discontinuous coordinate jump…(an artifact of the 0m thresholds) instead of using the previous PPP convergence that’s only a few seconds old.
Conclusion:
The V2.01 PPP/HAS engine is fundamentally broken for seamless PPP/HAS holdover. It provides a “Data Holdover Timer” (only counts up, no actual impact) but fails to provide any stability. I’m guessing the firmware contains a hard-coded “Loss of Signal” flag that overrides the user-defined timer. I also found several issues with the Quectel FW compared to the official documentation.
BTW: The good news is a LG290P can correctly handle the automatic transition from RTK to HAS when RTCM(NTRIP) is lost, without user intervention. HAS/E6 does function as an emergency/backup correction source, but the Holdover Timer needs to be fixed.
After sleeping on it, this morning I realized my post above has a major problem. Removing the antenna (or “Dumping” it) for 1-second will always be catastrophic to a PPP engine. HAS relies on counting the individual wave cycles of the E6 satellite signal (Carrier Phase Tracking). Even a quick disruption of that E6 signal = cycle slip, and will require a new convergence.
So my test in the above post was “mostly” pointless
I will leave the post instead of deleting it, but please disregard the Conclusion. The good news is I learned a few things about the LG290P during the process.
Hi everyone.
It’s great to share the data like this.
Now, I’d like to ask for your conclusions after using the latest firmware, version 2.01, and the latest beta version.
I remain convinced that the latest beta version works better than version 2.01.
I tested a professional instrument like the CHC i85, and the results are frankly better when using Galileo HAS compared to the LG290P.
While the reported accuracy is absurdly optimistic in some cases, it’s much closer to the true difference relative to the fixed point with PPP Canada coordinates.
Quectel needs to continue refining its firmware if it wants to compete in this area of Galileo HAS corrections.
@amlago , I compared NR01A03S_PPP_TEMP0812 and NR02A01S yesterday and didn’t notice any significant difference in “real-time” results. Both versions seem to fit my previous statement (for my location):
Please note: I haven’t tested any long occupation times, and that might be why I haven’t noticed any significant difference between the 2 FW versions (as you and others have) ?
When I have some time, I’m going to setup the LG290P with an aggressive configuration (High Elevation Mask & C/No, great antenna, etc) to eliminate as much multi-path as possible.
That makes perfect sense, since the CHC i85 is a wideband receiver. The LG290P processes Galileo E5a and E5b as separate narrowband sidebands. Wideband Receivers (CHC i85, Mosaic X5, etc) will outperform Sideband Receivers in this context.
I asked Google AI to explain the major error sources for HAS on a LG290P in the USA (basically anywhere outside the EU). I think it did a great job :
1. Ionospheric Delay
Impact on Convergence Time: Critical. Because HAS Service Level 1 in the USA does not provide ionospheric grid corrections, the LG290P must calculate an Ionospheric-Free combination using the E1 and E5a signals. This mathematical process significantly increases measurement noise. The Kalman filter requires about 10 to 20 minutes just to smooth out this noise before it can reliably declare a high-precision fix.
Impact on Overall Accuracy: Low. Once the ~10-minute smoothing period is complete, the dual-frequency math successfully cancels out the majority of ionospheric errors. It is a major bottleneck for your startup time, but it typically doesn’t degrade your final accuracy goal.
2. Multipath (Local Reflections)
Impact on Convergence Time: High. Multipath acts as false data. If a signal reflects off a nearby surface during your initial 10-minute window, it can trick the filter into an incorrect solution. This often leads to a divergence where the convergence clock essentially has to restart from zero.
Impact on Overall Accuracy: Extreme. This is the primary cause of position drift and jitter. Because the LG290P is a sideband receiver, it cannot sharpen the signal pulse as effectively as a wideband receiver to ignore these reflections. Even after you achieve convergence, local multipath can pull your coordinates 15 to 30cm away from the true center.
3. Tropospheric Delay
Impact on Convergence Time: Low. The troposphere affects all frequencies equally, so the LG290P does not have to perform noisy dual-frequency math to mitigate it. Instead, it applies a standard mathematical model immediately upon startup, which does not add significantly to your 10-minute wait.
Impact on Overall Accuracy: Medium. The troposphere is the main contributor to vertical or altitude errors. Since the HAS message does not account for local pressure or humidity in the USA, your altitude will often have a persistent 10 to 15cm bias. It remains relatively stable but prevents you from reaching a true geodetic zero.
