If your GIS app is having issues displaying the proper accuracy when using the RTK Postcard it may be because the LG290P did not support the GNGST sentence until v04 of the Quectel firmware. But then in v04 they didn’t print enough decimals so in RTK Fix mode, the precision was ‘0.0’ when it should have been ‘0.008’ for 8mm. Please see this issue for more information.
There is new beta firmware for the LG290P that fixes the decimals correctly. Please get the firmware v04 beta for the LG290P here. Please see these docs for updating your Postcard. Note: You may need to update the firmware on the ESP32 as well so that the “LG290P reset for firmware update” option is made available.
I got it all flashed. Bonus my lora serial cables came and that is working. Now to just send back my 2nd faulty postcard and I can finally get a base rover setup testing
Ellipsoid heights remained the same, but the LG290P appears to have a new(wrong) geoid at my location after the Beta Update.
I’m scratching my head here. I would assume a corrupted embedded geoid would cause an error or a Zero, not produce a real value.
um should you not be using the app to calculate the orthometric height? I did not even know there was an onboard option. do you know what geoid model it’s even using?
For real surveying = yes.
But I have a lot of RTK devices in the field for GIS.
The GGA sentence tells the data collector both the ellipsoid height and geoid separation.
If you apply a geoid in Surpad, then you won’t notice at all.
Up until now, orthometric heights were fairly consistent in my area for F9P, UM980, and LG290P…….Plenty good for GIS work across those 3 platforms.
It’s Beta FW on the LG290P that caused the change for me; so no reason for me to freak out. It’s just confusing if the geiod changed.
I cant find the info on the Geoid
I believe this is unintentional behavior in the Beta.
The LG290P03AANR01A04S_BETA0212 Release Notes only mention:
Change Point:
(1) Changed <RMS_D>, <MajorD>, <MinorD>, <Orient>, <LatD>, <LonD> and <AltD>
field values in the GST message from 1 decimal place to 3 decimal places.
Below is an example slice that shows the results of the change in the Geoid Separation. The UTM coordinates for X and Y are all reduced by the “lowest” value in the entire set, for an easy comparison. I’m testing the SFE helical antenna in this dataset over several weeks, so that’s why the numbers aren’t too tight. I downgraded the LG290P and the Orthometric results returned to normal.
Note: I think the Helical antenna is doing a great job for what it is. My test stand is in a multi-path environment on purpose… to mimic real-world results as much as possible. The σ’s for the entire dataset look good (excluding the Ortho Height during Beta0212, of course).
Is it possible by increasing decimals and isn’t it ECEF that causes a shift on Ortho height?
Have you computed a orthometric height with vertcon previously to confirm what you get for Ortho?
Sorry, I’m not following the question.
[ I know that you know all this, I’m just going to step through it and see if you spot something that I’m missing]
GNSS operates in the ECEF reference frame natively and the final output positions are transformed using the WGS 84 ellipsoid model. The satellites are orbiting the Earth’s Center of Mass, so ECEF makes perfect sense when you need to predict the position of a satellite that’s flying 7,000 mph around the Earth’s center of mass. A randomly defined ellipsoid would be chaos.
But the resulting WGS “best fit” ellipsoid doesn’t mean anything to humans as a reference, so the receivers use their decimated geoid (decimated to save space and speed up the computation) to also output the Orthometric height.
The GGA sentence tells the data collector both the height above this “best fit” ellipsoid and geoid separation used, so we can apply our own Geoid Model for “Real” Surveys when needed to calculate the most accurate Ortho Height.
Quectel didn’t change the Geoid, so I’m thinking the “AltD” value is getting botched somehow in the Beta ?
I’m wondering if the additional decimals are refining the equation but that doesn’t make much sense with order of magnitude. If I had a better guess as I’m sure you’d agree thinking back to engineering classes it’s more likely that the equation calculating height are missing a decimal or something causing a magnitude error.
