Hi @bamarcant
I’ve found the program you use.
Thanks
1 Like
Thanks! 0.34m at 95% is pretty good. Not RTK level by any means, but also far better than 1.0m that a regular L1/L2 receiver would achieve (on a good day).
1 Like
Hola Angel,Are two points, one at near and at sea level other at roof top of the Hotel.
The fix is not like rtk float but a single PPP provided by HAS correction service.
but now with cloudy skies and still at home (at a bad time):
You can also use Rtklib_rtknavi having activated all useful rtcm’s for a static rover solution log.
$PQTMCFGRTCM,W,7,0,-90,07,06,3,0*24 #MSM7 instead of default 4’s
$PQTMCFGMSGRATE,W,RTCM3-1005,058 #disable default one
$PQTMCFGMSGRATE,W,RTCM3-1006,15A
*errata corrige
$PQTMCFGMSGRATE,W,RTCM3-1019,154
$PQTMCFGMSGRATE,W,RTCM3-1020,15E
$PQTMCFGMSGRATE,W,RTCM3-1041,159
$PQTMCFGMSGRATE,W,RTCM3-1042,15A
$PQTMCFGMSGRATE,W,RTCM3-1044,1*5C
$PQTMCFGMSGRATE,W,RTCM3-1046,1*5E
@sparky let me know if fix_rate & gnss_stop works, because default is at 100ms in rover_mode…
@sparky: “Muchas gracias por instar al equipo de Quectel a escupir el fw!”
Thanks a lot
Marco
Thanks, Marcos.
We’re at the beginning of the journey.
Sparkfun as a company and @Sparky are invaluable support.
We’ll continue testing and sharing results.
Best regards
Angel
Question:
At some point in the future, after convergence, will the system display a fixed solution?
When I connect the Postcard RTK to my controller with Landstar 8, it quickly displays a floating solution, but the accuracy indicated by the program is never less than 70 cm, and on the Portability Protector screen, it is never less than 1.30 m.
These are very different values.
With very clear skies,
The accuracy results, compared after taking multiple data sets, are in the range of 15 cm to 40 cm.
I’ll share them when I can.
If anyone can explain, I’d appreciate it.
Thanks.
No porque en la cadena Nmea GGA el 5 indica incorrectamente un valor que no es atribuible al float, sino que se atribuye deliberadamente solo al PPP por convención.
Es posible activar todas las cadenas Nmea, pero hay que entender cómo y qué valores asume el programa; mientras se utilicen protocolos universales, serán interpretados correctamente (con suerte) pero puede suceder como en el caso del GST discutido al principio de los posts sobre LG290P.
Exacto comparar diferentes períodos de observación y compararlos con valores atribuidos a puntos conocidos ayuda a comprender la exactitud de los datos…
For now, I’ll make a series of recordings near the hotel, having the entire area available (at break time) and throughout the night, weather permitting…
I’ll later analyze the values, using a nearby but very ancient tower as a reference point with monography in various topographical systems.
Saluti
BTW, recently, I was driving far, far away (no SBAS coverage), with the RTK Express (F9P), the u-blox antenna sticked on the engine hood and no RTK correction.
Indeed, the F9P was indicating uncertainties between 25 and 35 cm. I will try to check latter on static stays what was reel dispersion.
Anyhow, to asses HAS performances, we have to compare single positioning to the one with HAS supposedly activated.
Imho, @clive1 correct me if I’m wrong, the F9P is capable but it (have) not an PPP resolution engine yet…
That’s also my understanding.
U-Blox published some material on their HAS testing with the X20, but the new marketing strategy will likely squash that considering HAS PPP-RTK is direct competition to the various “paid” ThingStream services (just a personal guess).
However, @Eric_S appears to have something working….?
1 Like
They had PPP back in the NEO-6P / 7P days.
HAS is scheduled for support in the ZED-X20P in 26Q1, whether that will be worked back into the ZED-F9 firmware is hard to know,
One of the hang-ups for uBlox is the lack of Phase Biases
1 Like
Hi everyone.
I have a fixed point with good sky visibility, attached to a wall where I do my tests. Point number 501.
To be able to compare data with Galileo HAS corrections, I sent my Rinex to PPP-Canada to obtain data in ITRF20.
The local coordinates of my test base are (10485.582, 11842.985, 59.44), based on the PPP-Canada results.
I’m sending you a screenshot of my controller with Landstar 8 showing the differences between three points taken from a series of more than 80 points surveyed every 15 seconds.
The differences are very good. Better than I expected, given the accuracy reported by the Landstar 8 of around 70 cm and the 1.30 m portability shield display.
I never expected such excellent results.
The question is, how can I trust future measurements if the devices show accuracy around 1 meter?
I look forward to your comments.
And I’m waiting for firmware v5 or v6 with Galileo HAS.
1 Like
Hola Ángel aquí hay otros resultados…
The fixed station is on the terrace and lasts 2h:40m during the night.(00.43.27 GPST)
note that there was a disturbing event, certainly the passing of Elon’s toys or the propeller jet of some late VIP…
the re-recovery for convergence has distorted the average but it remains somewhat stunning!
And notice the comparison with the rtcm_raw without correction data plot!
P.s.
Module was prepared as above with GGA only and all available rtcm msm7 & ephemeris data output.
the second one is a 35min near the swimming pool beside the building and and under the trees…And notice that after 30min it stabilizes the pos.
same raw rtcm only and without correction rtkplotted.
terrace.txt : 60.97 MB file on MEGA
Saluti
1 Like
Hi Marco.
Great, we’re continuing to make progress. Your data is very valuable, as you’re in Europe, where convergence is supposed to be faster.
Actually, the float appears very quickly, but I see from the tests that the best results are from 20 minutes onward.
I’m doing some long-duration tests and waiting for results from the Canadian PPP from my fixed point for comparison.
Generally, after 30 minutes or more, I get dispersion values less than 20 cm, as indicated by Galileo, in clear-sky situations.
With more obstructed skies, the dispersions are more significant.
My concern is how to have confidence in the data if my equipment tells me, as I’ve already reported, that the accuracy is 70 cm and up to 1.30 m.
I still need to study the topic, but I’ve seen several videos from South and another company I don’t remember, with controller accuracies reported as less than 10 cm, and they indicate ppp-fix.
So, my question again: are we measuring with floating situations, and will we ever have our ppp-fix from Quectel in the future?
Is it just a matter of new firmware?
We continue studying.
Regards
Angel
Hi everyone.
I’m sending you nearly three hours of measurement data with the Postcard in a clear sky area.
These are local coordinates taken with Landstar 8 software on the HC320 controller. 2010 epochs were recorded, with 63% having horizontal deviations of less than 0.25 m from the correct point, sent by ppp-Canada.
In the middle of data collection, strange things happened, such as poor corrections and inaccuracies that occurred by several meters. Then the corrections returned and things improved somewhat.
Here’s the Excel spreadsheet in case anyone is curious (I changed the extension .xlsm to .txt so I can upload it ).
Landstar 8 reported accuracies below 1 meter, even though the deviations were several meters, at the time when convergence failed.
I don’t know what happened at that time.
We’ll continue investigating. I think this beta version still needs some improvement.
Regards
Angel
I’ve done a few static tests with the LG290 in HAS mode and a Unicore UM980 attached to the same antenna. The LG290 HAS positions seem reasonable. Here’s a 27 hour plot (RTKPLOT) showing the light colored LG290 data and the darker UM980 HAS positions after twenty minutes of convergence. The graph is centered on a ITRF2020 OPUS position (27 hours).
This is a NMEA GGA sentence plot. Note that the Unicore data is biased about a third of a meter to the east. It’s a bug in their firmware where the NMEA data is not in the ITRF2020/WGS84/Galileo Reference Frame it should be. Their PPPNAVA message will (usually) be in the correct datum so just think of the plot being shifted about a third of a meter west with that message.
It’s just a one day static test, but the LG290 has a little more noise in the data. Not surprising given the heavy filtering. Even so the horizontal error never exceeds a half meter.
Location is the center of North America, a good though not perfect GNSS site, essentially default receiver settings, and a Harxon GPS1000 antenna was used.
1 Like
@amlago , Which Datum did you select when you collected the PPP from the PostCard ?
From the Beta FW Readme.txt :
<Datum>: Reference coordinate system.
1 = WGS84
2 = PPP original
As we all know, HAS works on GPS and Galileo Constellations, which are different reference frames, but we get “1” position per solution. Google claims alignment typically within a few cm, but I haven’t checked any particular point to confirm that.
What epoch is the CSRS-PPP position that you’re using for the truth ?
I’m likely getting too deep for a ~20cm correction source, but it’s always helpful to sort-out the System(s) before comparison.
Thanks to everyone for sharing their work !
Hi @rftop
To configure the postcard, use option 1, which corresponds to wgs84.
My base point for comparisons has its coordinates according to this week’s ppp-canada (epoch 2025.7 according to the report).
wgs84 and itrf20 are practically identical today, to the nearest cm, and the Galileo reference frame can also be considered almost equivalent.
The small differences between reference frames are far from the 20 cm of these HAS corrections.
I agree with you that you have to be very careful with reference frames to make reliable comparisons.
For now, I’m half satisfied. I expected results below 20 cm most of the time, given what Galileo claims of <20 cm at 95%.
And while I’ve gotten some significantly better results than that, I’ve also gotten significantly worse.
And to top it all off, we can’t know the estimated accuracy for each era, because the firmware is old. If I could know the estimated accuracy for each era, I’d be more confident in what we’re doing. For now, this firmware is only useful for testing. It’s not yet useful for real-world work.
We’ll continue to wait for improvements.
Regards
Angel
2 Likes
@jpb, that’s very valuable “real-world” data for the LG290P, and outside the “claim” of ~20cm for HAS. I have no opinions as to where the snag might be (HAS service, the chip’s implementation of it, a bad day for space weather, etc).
RE: UM980 - I had to make a change in the Torch FW to remove the East Bias, back in January when I was tinkering with HAS on the Torch:
CONFIG PPP DATUM WGS84 [ From SFE ]
changed to
CONFIG PPP DATUM PPPORIGINAL
Thanks for sharing !
2 Likes
Hi everyone.
I’m not sure what the original PPP datum is.
Is it a Chinese datum?
I don’t know what it corresponds to. If you know, let me know.
Regards
I’m not sure either.
I think of HAS as almost 2 seperate services (I could easily be mistaken), one for GPS, and one for Galileo. Since Galileo is GTRF, I’m fuzzy on what our combined HAS PPP solution is when we are using both GPS and Galileo Constellations with HAS PPP [for Datum = 2 “PPP Original”]
It’s not going to matter as much as with RTK simply because of the decreased precision and accuracy of HAS, but we know it “does” matter a little 
Even when using Datum = 1 “WGS84” , we need to know which WGS84 realization the LG290P is using.
I’m reminded of the time I mentioned to @sparky that everyone should just use ECEF and we all transform at the end. This was his response, ROFL :
4 Likes