After several tests with Galileo HAS corrections using the Postcard RTK (LG290P), I still have the same question when trying to perform field work.
How can I know if the solutions’ convergence is correct without precision information?
At a test point, I can compare data, but when I take the equipment to the field in a real-world work situation, I still can’t determine the quality of each point surveyed.
Does anyone currently have a method?
Or should we wait for another firmware update?
Thanks and best regards
Angel
Ciao Angel, ecco le mie considerazioni a riguardo:
I took your advice to keep only
$PQTMCFGCNST,W,1,0,1,0,0,0*2B active
and I’m operating with the utmost restriction
$PQTMCFGPPP,W,2,1,90,0.01,0.01*57 or
$PQTMCFGPPP,W,2,2,90,0.01,0.01*54
given the immediacy of HAS convergence
like a charm, I must say that since there is no immediate comparison
between RTK and PPP results, superimposing them, they have a difference of up to 60cm, both with ntrip WGS84 or with ITRF differentials, assuming that “ORIGINAL” are those referring to the GTRF reference system however aligned with ITRF2020.To be fair I used one private station in wgs84 and the other from the euref-asi system referring to IGS20.
Last night I recorded about 7 continuous hours in GPS+Galileo in original and I noticed that the position stabilizes only after 20 minutes and that at a certain point it stops in dgps as for the first evening for about 2 minutes and resumes the estimated position only after 35 minutes, however moving away by about 8cm from the initial cloud of dots.
The fact is that one point calculated in PPP cannot be superimposed to one resulting from an RTK correction, we will see only (after 16gg) what the post processing calculation and the famous Canadian_ppp says.
So only by using a “relative system” we can rely on taking the points obtained as in a static mode at face value with at least 25 minutes of observation for each point!
To force the software I tried to spit out other types of sentences including pqtmsvinstatus all unnecessarily; instead the module swallowed the ntrip_corrections while resolving the PPP and the nmea GGA ruling passed fearlessly into RTK fix (4)! Although the disclaimer says: “If you want to output RTK results in this version, you need to turn off the PPP function.”
Pictures will follow…
Hi Marco.
My country’s network is on a very old ITRF, so using ntrip with that network isn’t useful for comparisons.
What I’m going to do is generate another station with coordinates from sirgas2022, quite similar to ITRF20. The differences are small.
I’ll continue making comparisons there.
I’ve also observed the 20 minutes you mention, and in any case, we need instant information on the estimated precision to make a decision in the field whether to accept the surveyed point or not.
I still doubt that imposing horizontal and vertical restrictions would actually have any effect.
I haven’t been able to test it.
My experience is completely experimental, jajaja
We continue investigating.
Regards
Angel
How do you guys feel about a slightly different methodology ?
In real-world use, we allow 15-20 minutes for PPP Convergence, then take quick shots as a Rover like we do with RTK/RTN.
So Testing would be to move the Rover to multiple marks/points after HAS/PPP convergence and compare solutions to known coordinates. That’s how we intend to use HAS in the field, as a Rover (or am I missing an important use-case) ?
The snag in the field is when PPP Fixed status is lost (bad reception area, multipath, etc), which requires a new convergence. I’ve found that this Re-Acquisition time is generally the limiting factor for practical use in the real world, IMHO.
We assume that future Quectel Firmware will correctly report the PPP Residuals in the NMEA stream, but residuals are not an indication of actual accuracy. A “check-point” produced under different conditions is still required to have any confidence in a position (when you need assurance). Again, the current Re-Acquisition time for PPP makes that hard.
IE: When I’m using a fully trusted and qualified RTCM Source, I still perform a check-shot (later in time, or dump the antenna) if I need to trust/use the position (especially Elevation), even when the RTK residual claims 1-2cm.
I just wanted to share the concepts I’ve been using for testing HAS (in general) to get your comments and opinions. Having hours of occupation time on a Point using HAS isn’t something anyone will use (we might as well Post-Process). The goal is a Real-Time solution after convergence, so we should be testing in that context ?
Hi @rftop y @bamarcant
What you’re saying is what we’re trying to get at.
The static tests we’re conducting are to test the power of the method and how the firmware works.
I need to move on to real field tasks in rover mode, and I need to have an idea of the reported accuracy to accept or reject a point.
Having a known control point (DECI) is important.
And in real work, right now, the loss of convergence isn’t reported; the controller keeps reporting floating, and it’s impossible to know if the data is valid or not.
We’re waiting for firmware improvements regarding this necessary and urgent information so we can move on to testing in real field tasks.
I’m still converting the Excel spreadsheet (XLSM) to TXT format so I can upload it. From today to tomorrow.
Regards
Angel
The description of your methodology,Ryan, is definitely what we all mean even if the language barrier doesn’t spell it out…
I focused on the behavior of the ppp engine rather than comparing the known points which are also from various epochs even if from the same wgs84.
In a static situation, I’m pointing out that ppp has fluctuating behaviors if it loses and (it) resumes the point only after 20, even 35 minutes, compared to the initial solution itself, however (even itself) after a convergence of 20min from the beginning of the observation.
The goal of the real-time solution after convergence seems like a utopia to me so that I don’t trust the receiver yet.
