TTN Mapper found gateway 3000KM from Amsterdam?

Gateways
25

Wait… Isn’t fake_gps needed if the coordinates are hard-coded, i.e. not coming from a real GPS? If that is the case, considering the large majority of gateways do not have GPS modules, I don’t get the reason to disable it by default.

Yes, it’s quite unfortunate that the default ones are 10,20 instead of 0,0.

26

It should not be required, if a gateway does not have gps it should not send coordinates but the owner should set them in the TTN console. The only reason to set the coordinates in the gateway configuration is if you use another backend as well.

27

But then is not a good idea to change the defaults so lightly on the installers. It will mean we will have more and more gateways without location set because many will not register it in the console.

Currently the installation is pretty self-contained in the sense that it works and is “done” after it finishes it. Additional steps must be integrated properly. I suggest we include the gateway registering step right into the installer: using ttnctl is already possible to register a gateway, so we’d need to put that into the installers.

Does that sound like a good option?

28

I think that the most coordinates are not accurate. E.g – It is hard to find gateway with correct Altitude nearby my area. North Brabant- the Netherlands. Either the altitude is missing or is not correct.

29

Non-accurate coordinates may be caused by:

  • Users not wanting to be located via coordinates (think home locations) and therefore specifying (slightly) aberrant coordinates (still wanting to see their gateway on the map) or even complete bogus coordinates.
    (While the location can be marked as private in the TTN Console, the user has no further control over what happens with that information).
  • Users not knowing their exact location, e.g. thinking “I will add the proper coordinates later” (but don’t and forget).
  • Unawareness of why the backend should know the gateway location is of importance for LoRaWAN.

Similarly for specifying the correct height. Most reported heights will be approximations anyway.
It is also not clear which height to specify, height from ground-level or from sea-level, as that information is not clearly specified where the height has to be filled in.
That information should be added as remarks to the TTN Console and gateway configuration files.

And it is not simple to verify the correctness of a gateway’s reported coordinates. The gateway’s IP address could be used for determining a rough indication of the location.
(Several GPS modules that I have played with were very bad at reporting the proper height - at least indoors).

I do remember that months ago I had specified a height of 3m for gateways (indoor, on first floor). That this height was first shown on the map but not anymore at a later moment. When I moved a gateway to the second floor and adjusted height to 6m it was shown again on the TTN Map. I assume that this was a temporary quirk (because I cannot think of a reason why lower heights should be filtered out).

There was an issue with the TTN Map lately where it did not show the height for (all) gateways. This issue was fixed last week.

1 Like
30

Yes, this is always a problem. Fortunately we are not involved in AirTraffic control :wink:
I think there should be two values to omit errors:

Antenna height above sea level (mandatory)
Antenna height above ground (optional)

Not to forget that automated gps position could be slightly off the antenna position

31

IMHO, I think that even with GPS module linked to gateway, coordinates should be handled with precaution, as both gateway antennas are not necessarily at the exact same place, and even then, as we don’t have the GPS HDOP or sat number, its accuracy may vary a lot

32

what is the difference between your resin build and that from @jpmeijers ?

33

[off topic] Mine was used a few weeks ago for workshops. The changes have been integrated into his repo. I’ll remove mine shortly.

1 Like