HDOP or Accuracy

[jpmeijers]

https://github.com/packetbroker/api/blob/b5a778640285001e3cc091bcefd6a0e0907e1768/mapping/v2/openapi.tmpl.json#L367

HDOP doesn't feel like the correct parameter to include here. Shouldn't we rather use the location accuracy in metres?

I've looked at the Basic Station protocol docs, but I do not see any reference to the location of the gateway in the protocol.

The UDP protocol did not include an accuracy or HDOP field.

If the location is set by hand, the accuracy should be infinitely good, ie. 0 metres, or an HDOP of 0. Or if the accuracy is estimated, the estimate should be in metres. HDOP refers to how optimal the GNSS satellite constellation was when the location was obtained, and is therefore only useful along with a location obtained with a GNSS (GPS) receiver.

• Where do we expect this HDOP to come from?
• Shouldn't we rather use accuracy?

[johanstokking]

This comes from gateways that have GPS and report their location to the Gateway Server.

[jpmeijers]

Do you maybe have a link to any reference?

Looking at the current data on the mapping API, I see this example with HDOP = 0, which is not a realistic value.

  {
    "netID": "000013",
    "tenantID": "ttn",
    "id": "jruys-indoor",
    "eui": "58A0CBFFFE80207F",
    "clusterID": "ttn-eu1",
    "location": {
      "latitude": 52.343611637284845,
      "longitude": 4.907219409942628,
      "altitude": 5,
      "hdop": 0
    },
    "antennaCount": 1,
    "online": true
  },

[johanstokking]

If the location is set on the map, the hdop will be 0. This is also what you suggested:

If the location is set by hand, the accuracy should be infinitely good, ie. 0 metres, or an HDOP of 0

The Mapper API doesn't provide information whether the location comes from the gateway's GPS or from the registry.

[jpmeijers]

Yes, but you are now only partially quoting me. If you read on you see:

HDOP refers to how optimal the GNSS satellite constellation was when the location was obtained, and is therefore only useful along with a location obtained with a GNSS (GPS) receiver.

So I still believe HDOP is not the right thing to use here.

Please point me to where gateways are sending hdop to the network server.

[johanstokking]

HDOP refers to how optimal the GNSS satellite constellation was when the location was obtained, and is therefore only useful along with a location obtained with a GNSS (GPS) receiver.

So I still believe HDOP is not the right thing to use here.

I don't understand the logic here. Or what your question really is.

You agree that hdop provides a qualitative indication of latitude, longitude and altitude, right?

I said that the coordinates in this API may come from a registry or from the gateway itself, using GPS. If the former, you agree that hdop should be 0. If the latter, it should be hdop, right?

What the contents of status messages is that gateways send to network servers is far beyond the scope of this API here.

[jpmeijers]

Ok, let me try and be more clear:

• HDOP does not make sense in the context of this API.
• Accuracy in meters will make sense in the context of this API.

Exception:

• I can only think that HDOP is valuable if this API is consumed by LoRaCloud or similar mathematical models that can make sense of HDOP - but likely these models would want accuracy in metres.

Question:

• Does Basic Station forward the location of a gateway along with the HDOP? => Is the intention to provide this HDOP value for LoRaCloud? => Does LoRaCloud consume this API? => If NO to any of these, why have HDOP in this API?

---

PS: Maybe have a quick read up on what HDOP is. I've seen you mix accuracy and hdop elsewhere too, while these parameters are totally different things: https://github.com/TheThingsNetwork/lorawan-application-payload/pull/2

HDOP is a unitless indicator of the accuracy. An accuracy of 3 metres is good, while an HDOP of 3 is quite bad.

[johanstokking]

The thing is that HDOP can be determined by the gateway, and accuracy in meters cannot be determined by the gateway. The field is either 0 when the gateway is "put on the map" by the user, or it comes from status messages from the gateway. Those status messages will contain HDOP, not accuracy in meters.

I don't know what LoRa Cloud has to do with this.

Anyway, https://github.com/TheThingsNetwork/lorawan-application-payload/pull/2 is good, I'll merge that.

I will also go ahead and remove hdop here and add accuracy. Indeed, assigning accuracy to HDOP and vice-versa is not correct.

[jpmeijers]

Happy with your last comment, so the rest is just further thinking abut this, and off-topic for this issue.

---

HDOP can be determined by the gateway, and accuracy in meters cannot be determined by the gateway

Yes and no. All GPSs provide the HDOP values in their NMEA strings. But most of the newer ones also provide accuracy in meters in their vendor specific strings. So it depends on which GPS is used on the gateway, and how the GPS data is read out. On linux systems one should use gpsd, and not read out the data directly over serial like the Semtech UDP forwarder does. Gpsd will detect the vendor of the gps chipset and configure it to output the vendor-specific strings, and therefore give us access to accuracy.

Also following this same line of thought, the best place to estimate an accuracy from an HDOP value is the gateway itself, as it has all the info needed. Any other location will not have this same context.

Leaving me with the conclusion that a gateway should rather report an accuracy in meters if it is available. If it is not available the accuracy should be estimated by the gateway using the HDOP, satellite count, almanac age, etc.

(Please let me know where I can file a feature request for this. Basic Station repo?)

[johanstokking]

Thanks! This is closed by https://github.com/packetbroker/api/commit/9e605bfaeff6593a149436f962f61dc7dadfe2bf

For Basic Station, it seems like there's already an issue (https://github.com/lorabasics/basicstation/issues/105) but you might want to upvote or add some additional information there.