As I’m typing this it has not been implemented yet (feature implemented on 2016-03-20), but the idea is to hide all “old” measurements for a gateway if it has moved more than 100m. Therefore, if you mapped the coverage of a gateway, the measurements showed up on the map, but the gateway was then placed at a new location more than 100m from the original location, the old measurements will be hidden.
Thanks. I also realise the gateway will be shown back as online once you start mapping it again. In other words, if a gateway is offline, it won’t be shown online again on ttnmapper.org unless it’s ‘triggered’ by some mapped data.
I add my question here, as it is reasonably close to this thread.
the problem i have is:
i have moved a gateway and changed the location info in console, local_conf.json and remote_config .jsn file.
So, neither console nor gateway has any reference to the old location anymore.
yet, when i m trying to map new connections (via android app), the connections are shown to go to the gateway in its old location, > 48 hours after the changes.
so, i guess my question is: where does ttnmapper look up gateway positions, and is there a delay in changes coming into effect?
am i overlooking something?
thanks in advance!
i was too impatient.
documenting it here in case it s useful for others.
the issue was not ttnmapper or app, but the gateway still sending old coords despite all the conf files and console settings changed. old settings survived in binaries on the gateway.
so, when moving a gateway, update all conf files, local and remote, but also re-build the ic880A. that solved it for me, in any way.
The code does not contain coordinates. However the software only reads the configuration on startup. So any changes to the configuration files are only activated on start of the software.
And if you pushed the configuration to github (for the ttn-zh installation) you will need to pull the update on the gateway.
thanks for your comment -
i expected it to work the way you describe, with new configs being read on startup.
i found, however, that restarting the software (and the whole Pi) with the new configuration files, thoroughly checked to not contain any old coordinates, was not enough - the gateway still sent the old coords. i didnt quite understand that.
running .install.sh fixed that though, so it s solved.