Error in the accuracy display on the portability shield screen.
In rover mode, the accuracy displayed on the screen is roughly the same as that reported by the control program, such as SWmaps or GNSS Master.
However, if ntrip corrections are provided, the accuracy reported on the display is several meters. I obtained up to 14 meters, and the accuracy in the app was within a few decimeters, for example, 0.45 m or 0.35 m.
When the position fix is obtained, the accuracy is corrected on the display and equals that shown in the app.
Something is wrong.
Regards
I’m uploading a video where the accuracy increases to 7 m upon receiving ntrip corrections, and when the solution is fixed, it plummets to 2.6 cm, as expected.
Meanwhile, the accuracy in the control app continues to decrease, as expected.
The video has a .txt extension so I can upload it.
I do not know if I can fully explain this. But I can explain what the code is doing:
On Postcard (LG290P), the “horizontal accuracy” on the OLED display is actually the “EPE_2D” “Estimated 2D positioning error” from the $PQTMEPE NMEA message.
My guess is that that value is different to the value in the NMEA data used by SW Maps.
Which version of the LG290P firmware are you using?
Hi Paul.
The LG290P firmware is the latest, the beta version.
The strange thing is that the reported accuracy worsens with corrections, sometimes reaching tens of meters. As seen in the video.
It’s counterintuitive to expect an improvement in accuracy, as seen in all data collection apps.
Best regards.
Angel
I understand what you’re saying.
But the idea is that I don’t have to send commands directly to the LG290p, but rather that the ESP32 firmware does it.
The idea is to display the same thing on the screen as in the control app.
I’m waiting for a new version of SparkFun_RTK_Everywhere_Firmware that fixes this and a few other things.
I tend to see accurate hmrs and vrms from gst in Carlson survpc, fieldgenius, and surpad on my phone. I don’t really pay attention to what’s on the portability shield. I have set quite a few baselines with Carlson survpc set up with my total station and checked 0.02 or better horizontally. I tend to just hold a point for position and a second point purely for geodetic azimuth to get me onto a coordinate system. Since the last beta fw and current rc RTK firmware I havent had many problems lately. I do admit I don’t use swmaps because it seems more like a GIS app over an actual surveying app.
@amlago . Seems like it’s best to ignore the Proprietary $PQTMEPE Message on the Shield.
There “may” be a snag in Quectel Firmware generating the $PQTMEPE message as the RTK engine/calculations takes over, for a short amount of time?
Or this flow might make perfect sense to the Quectel FW Engineers…who knows.
The GST Message is how the device will communicate this metadata to the rest of the world anyway
Of course, I’m ignoring the on-screen message with absurd precisions of many meters before obtaining the fixed solution.
It would be ideal if this were corrected so that the displayed values were similar to those reported in the control app.
Regards
Angel
I hope your comments are like a boulder that crushes the obstinacy to perpetuate on a dead end by Quectel…
I appreciate the decisive outcome of this forum regarding the improvement of the GST at the expense of proprietary parameters such as PQTMEPE.
Now I beg you not to give up on the development of Galileo HAS; if the developers had completed an external processing with the raw data capable of obtaining solutions, they would have been able to implement an internal algorithm already ready for a long time…
They easily abandon what is not easy to do, not caring about the expectations of a few… only the strong commercial and media power induces them to conclude a promised project.
Here my two cents. Spero che la sintesi tradotta abbia reso bene il significato…
Saluti a tutti e un ringraziamento a questo valido forum.
Marco
