GPS report accuracy in meters

[jpmeijers]

Looking at the code in gps.c I see three GNSS location quality parameters being sent to the LNS:

• dilution
• satellites
• quality

https://github.com/lorabasics/basicstation/blob/bd17e53ab1137de6abb5ae48d6f3d52f6c268299/src-linux/gps.c#L240-L242

From a long discussion at https://github.com/packetbroker/api/issues/32 and a comment at https://github.com/lorabasics/basicstation/issues/105#issuecomment-878362476 my recommendation is that these quality parameters should be used to calculate an accuracy in metres, which are then sent to the LNS. Dilution and satellite count are both very useful metrics, but for end users these have no meaning. Only in the right context these parameters carry a useful meaning. In this case only the gateway has this context. In any other context down the line, dilution and satellite count has no meaning.

Because the UBX strings are already parsed by gps.c, maybe it is possible to parse the string that contains the accuracy in metres. If this string is not available, the accuracy can be estimated based on the dilution.

See $PUBX's Hacc field, or pAcc in NAV-POSECEF (0x01 0x01). One could parse this latter message around https://github.com/lorabasics/basicstation/blob/bd17e53ab1137de6abb5ae48d6f3d52f6c268299/src-linux/gps.c#L447.

https://www.sparkfun.com/datasheets/GPS/Modules/u-blox5_Protocol_Specifications%28GPS.G5-X-07036%29.pdf

[beitler]

Thanks for submitting this issue, which, I think, proves the point that basic station should not be in the business of parsing NMEA/UBX sentences except for testing purposes.

If this string is not available, the accuracy can be estimated based on the dilution

I understand that for end users an accuracy metric in meters is most desirable. However, deriving this metric from GNSS observables is one of the secretest of sauces of GNSS solution providers and is by no means trivial. I am sure after Basic Station implements an accuracy metric from GDOP/residuals/etc, there will be a number of tickets popping up detailing alternative/superior approaches.

Hence, I suggest to implement a simple script which consumes the GNSS receiver data and reports whatever metrics are important to the user. If you are looking for something more generic, you will have to converge to something like GDOP/HDOP for all practical purposes because that's the lowest common denominator you get via NMEA.

[jpmeijers]

I agree with you, but I still hope there is some kind of middle ground here. I'll think a bit about the problem and try a few experiments on my side.

[jpmeijers]

Just coming back to this, as I'm running into HDOP vs. accuracy in meters again while looking at LoRaWAN gps trackers.

On GIS Stackoverflow someone summarised the problem nicely in a comment:

But because HDOP is used to multiply the other errors you should also know the technical accuracy of your receiver.

In other words, HDOP on its own is useless. One needs to know the GPS receivers specs to convert it to an accuracy. Only the GPS device, or device it's connected to has this knowledge. The LoRaWAN network does not have this knowledge.

Therefore:

• Report accuracy in meters, as that is useful.
• Do not report HDOP as it's meaningless.

[smtc-bot]

Thank you for your inquiry.

Customers are encouraged to submit technical questions via our dedicated support portal at https://semtech.force.com/ldp/ldp_support.

We invite all users to visit the LoRa Developer Portal Forum at https://forum.lora-developers.semtech.com and to join the thriving LoRa development community!