-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No accuracy information available with SW Maps or GNSS Master (no NMEA GST) #513
Comments
Indeed, I've confirmed the GST message is not supported on the LG290P and requested it in a future firmware release. Quectel says maybe in a future firmware update but I haven't seen any firmware updates yet so who knows.
Anything is possible but there's not so many hours available. We can generate NMEA easily enough but we don't yet have a scheduler to add messages to the outbound circular buffer (what you see in your GIS app). This feature would be related to the unique ID messages request. Same plumbing, different message to report. |
The timing couldn't be better. I was just notified by Quectel that they released new firmware that supports GST. Quectel_LG290P_Firmware_Release_V0104S.zip We'll get started implementing this. |
GST is working on the Postcard in the release candidate. We have a bunch of docs to update but you should be able to update your LG290P firmware on Postcard with this: Start the update procedure from QGNSS: Within 20 seconds, you have to reset the LG290P. Do this from system->hardware->13) LG290P reset for firmware update: Firmware updates took me about 75 seconds. Release candidate is scanning for old (< v4) and new (>=v4) firmware types and settings things up accordingly. Note: GST is currently reporting single decimals so the accuracy during normal 3D Fix will look fine, but in RTK Fix mode, some GIS softwares (ie, SW Maps) will report an unknown lat/lon positional error because of this:
Error in GST is reported as '0.0' when really it's 0.013 (13mm). Their binary protocol confirms this but the GST message is cutting off those all important decimals. I've pinged Quectel to see if there's a remedy. |
Thanks for the hard work on this! I need to find an Windows PC first to try that firmware upgrade, I'll report my progress in about 20 hours... |
Np! Glad it's coming together. Also, our RTK loader is available on Win/iOS/*inux. |
Hi! Sorry for the long delay. I was able to flash the firmware (both ESP32 and LG290P) and see the results. Let's hope Quectel can fix that data problem soon. |
I flashed the release candidate from Jan 20th, v4 firmware from above, and enabled the gst message in the serial menu. I still get blanks and even though my PDOP is good surpad can't take a point. |
As mentioned, Note: GST is currently reporting single decimals so the accuracy during normal 3D Fix will look fine, but in RTK Fix mode, some GIS softwares (ie, SW Maps) will report an unknown lat/lon positional error because of this: $GNGST,190701.500,0.7,0.0,0.0,85.7,0.0,0.0,0.0*4F Error in GST is reported as '0.0' when really it's 0.013 (13mm). Their binary protocol confirms this but the GST message is cutting off those all important decimals. I've pinged Quectel to see if there's a remedy. |
Yes I was able to get 0.000 on surpad so that's solved. If quectel can fix it this chip is phenomenal for surveying. I mean it still is by RMS would be nice to see. |
Anyway to force minimum to equal 0.01 instead of rounding to 0.00? Field genius refuses to store points with no gst value |
We could disable the GST sentence the module produces and produce our own GST sentence. Not something I really want to do since this is Quectel's fault. But if it's breaking compatibility with GIS software, I'll consider it. |
Yeah basically on most apps it prevents you from storing a position I've told quectel we really need more decimals but who knows how long it will take. The postcard would be a beautiful device if you could possibly fix this one little issue :D |
Oh, I've heard that one before! We'll do our best :) |
Should we just bombard Quectel forums? Nothing else we can do I guess? |
I've been doing that and I think sparkfun has too. |
Quectel told me end of Q2 for the next firmware update that fixes the malformed GST sentence so I'm not willing to wait. I've got a work around in place. It's not completely accurate, but we've extended the GST sentence to include 3 decimals. Above, GST with a RTK Fix that is waning. Note that the vertical error (that's the 0.066m that follows the two 0.033m fields) is basically made up. 0.033 is the LG290P's reported horizontal error for both the lat and lon error, and the 0.066 is double the horizontal error for the height error. This is just a rough hack until Quectel properly outputs the GST sentence. Above, SW Maps with a good RTK Fix. While I haven't tested this on anything but SW Maps so please test today's (Feb 10) RC and let me know. This work around will only operate on LG290P v4 firmware. So if you've got v3 (no support for GST) or v5 (the upcoming hopefully fixed GST firmware) this code won't run. |
Nathan you are my hero! Thank you for throwing this together that solution is perfect for the meantime. Sparkfun rocks! |
Tested out new RC it works for now :D |
Glad to hear it's working! I pushed another small change to prevent this GST patch from being applied unless RTK Fix/Float is happening. I'd rather trust the original GST if the HPA is >0.1m. It's only when we're in the mm range that we need the extra decimals. |
When connecting to RTK Postcard via Bluetooth with SW Maps or GNSS Master, there isn't accuracy information displayed, and GNSS Master even says "No NMEA GST". This does not change if I enable NTRIP client in the app (NTRIP client in the RTK Postcard does not work, I'll create a separate issue if I remember).
However, if I open the serial terminal, you can see status strings that specify the accuracy, so the data is there somewhere.
Weirdly, Quectel also confirm that they do not output that data currently (https://forums.quectel.com/t/the-lg290p-doesnt-seem-to-support-nmea-gst-message/39242), but is it possible that you could inject that data to the output?
The text was updated successfully, but these errors were encountered: