Hello my friends.
I’m doing an experiment with the postcard.
I left only GPS and Galileo on and turned off GLONASS and Beidou.
It’s 7:00 PM in my country, and I’ve been collecting data for 40 minutes.
A quick visual analysis of the coordinate values leads me to believe the results are better than with all four constellations on.
I’ve been doing this for 40 minutes, and it seems to me that the differences are around 10 cm.
When I analyze it on the PC, I’ll upload the data so we can continue sharing.
I’d like you to do the same; leave only GPS and Galileo on and try it out.
I look forward to your comments.
Best regards,
Angel
1 Like
I don’t want to get my hopes up with the configuration changes.
I’m sending you data from an hour and a half with only GPS and Galileo enabled.
The results are too good to be true.
100% of cases are below the promised 20 cm.
A huge percentage are below 10 cm, and several are close to 2 cm.
I’m sending you the Excel spreadsheet (xlsm) in txt format so you can upload it. Change the format to xlsm to open it.
These are local coordinates, as I mentioned before, of a known point processed by ppp-Canada.
For those who don’t know, I take the data with the Landstar 8 program, running on a CHCNAV model HC320 collector.
Regards
Angel
base casa ppp 02-09-2025.txt (192.0 KB)
Not to sidetrack things too much, but are you sure the bias is removed for you? A HAS position could sit a decimeter or two from the real position for multiple hours so a short test might seem OK, but at 24+ hours it isn’t.
I spent a lot of time trying different settings with the UM980 and never got the NMEA data to align with a ITRF2020 position. I did get the PPPNAVA message to match the (east biased) NMEA data once though, but it wasn’t repeatable.
The data I posted above had the datum set to PPPORIGINAL. I know that’s not a fix so if you are sure you have no bias there is something else going on.
Hi @jpb
I wanted to make it clear that the results seemed too good to me.
The only configuration difference is that I’m working only with Galileo and GPS.
I just woke up after a rainy night and put the postcard back to work.
After 15 minutes, it was below 20 cm, and I’m collecting data.
We’ll see what happens later.
If it stays below the promised 20 cm, that would be fantastic.
I ask again that you turn off GLONASS and BEIDOU and run your tests, so we can compare.
With that configuration, I’ve gotten the best results so far.
We still need the postcard to report correct precision (GST).
As I write, it started raining again, and that may affect the results. I’ll analyze it later.
Regards
1 Like
Hi @Sparky.
What data can you provide from Sparkfun?
Have you tested the new firmware?
Looking forward to hearing your feedback.
My measurements using only GPS and Galileo seem promising.
I don’t want to get my hopes up too much.
Regards
Angel
1 Like
I’ll transfer the data I measured today to tomorrow (7:30 AM). txt format, change to xlsm.
They’re still very good, not as good as yesterday’s, but still very good.
Under 20 cm, 72%
Under 10 cm, 46%
Around 30 cm, 1%
It still seems very good to me.
I only remember Galileo and GPS.
Regards
Angel
base casa ppp 03-09-2025 - copia.txt (428.3 KB)
1 Like
Above, ~20 minutes of location reports.
Nothing too new to report. The LG290P with LG290P03AANR01A03S_PPP_TEMP0812 firmware shown above. Green dot is PPP’d known location of antenna. HAS is bouncing around a bit, but overall, ~0.5m accuracy from the ‘known’ location is very reasonable.
Setup:
- Postcard with v2.2 ESP32 firmware
- LG290P with PPP_TEMP firmware
- Stock settings otherwise (all constellations enabled)
- Manually enabled HAS:
$PQTMCFGPPP,W,2,1,120,0.10,0.15*68 - I did not change the fix rate. My unit adjusted this to 1Hz by itself.
Notes:
- This test firmware is frustratingly v03, therefore as @bamarcant points out, GST is not supported. Let’s hope they bring the branches and new features together into v06.
- Because this is marked as a v03 firmware, it’s a bit annoying for us to parse and handle this ‘PPP_TEMP’ version for RTK Everywhere Firmware. Whatever; we can do it if Quectel doesn’t release a production firmware version soon.
- HPA is, as @amlago points out, confusingly reported as no-better-than 1.30m when it appears to be much better than that.
- Additionally, we have only the ‘5’ indicator, as @bamarcant said earlier, in GGA indicating PPP but no indication if we have PPP convergence or not. So currently there is no way to tell if we’ve achieved a ‘good’ HAS based location, other than waiting ‘awhile’.
Quectel is good to release this, but this is not yet a magic bullet. And I agree with @rftop, real testing begins once we can test locate over known monuments with movement of the antenna when potential HAS convergence loss is real.
2 Likes
@sparky - Ah, but a scientist would tell you that the +/- of 0.5m of that test means 1m of confidence in any particular solution (~0.8m to be fair). The +N and -E was random in this scope, but obviously driven by the entire System during the test.
I haven’t been able to use HAS this year for reproducible real-world results that I would trust independently…..with any hardware. I’ve tried many times but I can’t produce defendable data.
I’m very hopeful that someone can make it work 
2 Likes
Doh! You’re correct. Science… I’m just the hardware guy!
@amlago and other Postcard users, we’ve added a menu setting to enable/disable this PPP feature. Please see this issue. An RC is available here.
2 Likes
Hi everyone.
Thanks @Sparky for the changes to firmware v2.3.
I’d like your confirmation if you get different results when leaving only GPS and Galileo on.
The results still seem better to me than with all four constellations on.
In static mode, you’ve seen that my results were significantly better at 50 cm. See the Excel spreadsheets in previous posts.
More similar to the theoretical 20 cm at 95% than at 50 cm.
So I look forward to your comments.
Regards
Angel
Here’s a 23 hour static plot after convergence of the LG290P in HAS mode and a Septentrio Mosaic receiver in WAAS mode. The same antenna fed both receivers.
A horizontal 95% accuracy figure of 65 cm is typical for WAAS. While 29 cm for HAS is certainly better it’s on the high side compared to what I’ve seen in more than 50 days of Unicore UM980 HAS data.
Of course this is a beta version so I’m going to wait before doing any serious testing.
Hi @jpb
Good data series.
Is the center of your diagram the average of the data, or are the coordinates obtained by another method?
Have you analyzed the deviations from the point’s true position?
I can’t leave the postcard on the roof of my house for as many hours as you can, but when I can, I’ll leave it for up to 6 hours. I’ll continue to report the data.
Regards
@jpb shared some good data…..so we can get a little deeper in the analysis.
For that data set, I would start to have some confidence in a single real-time position being within 40cm, if we are assuming the center of the plot is the truth. This is very promising 
A trap that we fall into when considering real-time positions is inferring too much with many positions produced over long occupation times. The math is basically the same but how you apply it is different that how we evaluate a static session. Averaging all these points does produce a higher accuracy….but that’s not a true evaluation and doesn’t match the application of a real-time procedure. Averaging a days worth of epochs doesn’t increase the precision for a real-time application, only the accuracy when all points are combined.
Another way to say the same thing: With HAS, we aren’t getting atmospheric corrections. So for now we are stuck with those random errors. Averaging many points is how we cancel random errors, but that’s not a possibility for real-time work.
In the end We need to be able to say with confidence: “Anytime I have PPP Convergence with HAS (or any correction source), the real-time position is within XX cm for This Device.” That’s any single epoch…..and that’s the hard part. Plus, the device must be able to reproduce that accuracy after dumping the antenna, and tomorrow, and the next day.
This is one reason why I love this tech. You can dive as deep as you want to and learn more every day.
I think @jpb‘s latest data is defendable to 40cm for that day. I like it and I can’t wait for that to tighten up. I haven’t been able to get repeatable real-time HAS accuracy over the long term…..yet 
My opinion
Even though the antenna makes a big difference, prolonged exposure doesn’t improve the situation at all. In fact, this is an unadulterated graph and represents about 11 hours of observations. Note that I’ve only superimposed Q=1 and Q=2, but there are many positions even with Q=4 that aren’t exposed. I note that receiver get HAS after just a few seconds (could it be the antenna’s superfault?) and that stability (convergence) only occurs after about twenty minutes, barring any unexpected DGPS issues. I’ll leave the comments…
1 Like
@sparky , I wanted to give the RC-Sep_04 a spin but it can’t successfully configure the LG290P because of v3 Quectel :
GNSS LG290P online
Current LG290P firmware: v3 (full form: LG290P03AANR01A03S_PPP_TEMP0812). GST and DATA port configuration require v4 or newer. Please update the firmware on your LG290P to allow for these features. Please see https://bit.ly/sfe-rtk-lg290p-update
PPP trial firmware detected. HAS settings will now be available.
Current LG290P firmware: v3 (full form: LG290P03AANR01A03S_PPP_TEMP0812). Elevation and CNR mask configuration require v5 or newer. Please update the firmware on your LG290P to allow for these features. Please see https://bit.ly/sfe-rtk-lg290p-update
LG290P version: v03 - LG290P03AANR01A03S_PPP_TEMP0812 2025/08/12 16:19:24 - v-1357648824
[ 5020][E][Wire.cpp:515] requestFrom(): i2cWriteReadNonStop returned Error -1
[ 5077][E][Wire.cpp:515] requestFrom(): i2cWriteReadNonStop returned Error -1
[ 5134][E][Wire.cpp:515] requestFrom(): i2cWriteReadNonStop returned Error -1
Resetting LG290P to complete configuration
configureOnce: Enter config mode failed. 3 retries remaining
Resetting LG290P to complete configuration
configureOnce: Enter config mode failed. 3 retries remaining
Resetting LG290P to complete configuration
LG290P failed to configure
I can turn off the GST message for the 1’st warning – But Items #5 & 6 are missing from the Receiver menu now (to turn off Elevation and CNR Masks). Any Hints for the RC?
Menu: GNSS Receiver
1) Set measurement rate in Hz: 1.00000
2) Set measurement rate in seconds between measurements: 1.00000
Note: The measurement rate is overridden to 1Hz when in Base mode.
4) Set Constellations
7) Toggle NTRIP Client: Disabled
x) Exit
Hi, the same thing happened to me, and I remembered I had the same problem a while back, and Nathan discovered that in my case it was the radio speed. Not all speeds were accepted.
It seemed to me that only 9600 and higher were accepted. I went back to v2.2 and set the highest speed. I don’t remember the exact number: 460 and something else.
Then I went back to the latest v2.3 and everything was fine for me.
Coincidence? You analyze it.
In case it’s helpful, I’ll let you know.
Regards
Angel