Gateway GPS configuration in local_conf.json

1

Tags: location, gps, coordinates, local_conf

To be consistent with the GPS coordinates for a gateway, we need to standardise the flow and origin of manually set coordinates. The flowchart above basically says that coordinates should always be set on the TTN console, unless the gateway has a GPS. In all other cases you should configure the gateway in such a way that either it does not send coordinates to the backend, in which case the coordinates from the console will be used, or fetch the coordinates from the console.

Single channel gateways
For gateways that does not have a local_conf.json, or does not have the ability to disable sending coordinates in status update packets, set:
latitude=0, longitude=0, altitude=0.
When these values are 0, they will be replaced by the values defined on the console.

Location privacy
If you want your gateway’s location to appear on https://www.thethingsnetwork.org/map or on https://ttnmapper.org/ you need to make your gateway location public by changing the setting on the console.

Please feel free to comment on this and I will update the flowchart if necessary.

6 Likes
3

I would suggest a different system. Being able to set everything about a gateway without opening the console is a big plus, and we could keep that if only we agree that there’s a hierarchy: values set in the console take precedence over local configuration. I assume this flowchart was designed to support real GPS, but I would suggest that still works: one must simply not set location on the console if the local GPS is preferred.

4

Copy of my comment on Github:

Here are the rules for gateway location:

For the gateway:

  • If the gateway has a GPS and has a GPS fix:
    • The gateway must add the location calculated from GPS to status messages as status.gps
    • The gateway must add the time field to uplink messages as message.gateway_metadata.gps.time
    • The gateway may add the gps field to uplink messages as message.gateway_metadata.gps
  • In all other cases:
    • The gateway must not add a location to the status messages.
    • The gateway must not add a time field to uplink messages.

For the backend:

  • Each time the gateway sends a status message, a location is cached as “latest”
    • If the status message contains a location, the location from the status message must be cached.
    • If the status message does not contain a location, but the gateway location is set in its registration, the registered location must be cached.
    • In all other cases, the location must be stored as “empty”.
  • Each time the gateway sends an uplink message:
    • If the metadata of the uplink message contains a gps field, this field must not be changed
    • If the metadata of the uplink message does not contain a gps field and the “latest” status message from the gateway contains a location, the “latest” location must be inserted.
    • In all other cases, the location must remain “empty”

Note: The fake_gps option must only be used if the gateway has some other means to determine an accurate location

2 Likes