Connection to the Copenhagen. This was today from my paraglider.
1 Like
are you sure its not simply a GPS module location fail?! this happens to me sometimes. just ignore this one glitch.
This is not how TTN Mapper works. The device transmits the GPS co-ordinates. All the plots show some consistency for his location and if it was a glitch, it would show his position being somewhere else entirely and the other gateways would report the same.
What we have here is a gateway that appears to have heard it, at the same time as other far more local gateways, over 1000km away.
The most likely explanation is that the gateway has moved from its previous location in Denmark to a new location in the vicinity of the other gateways but it hasn’t had its location updated on the console.
what is more likely:
*a person from denmark that moves (or sells) its gateway (and credentials) to (a person) in slovenia…as you say correctly …over 1000km away.
or
- its a software glitch in the giant pile of code all the way from the source to the destination produced by the failing mankind
?
sorry, but in the game of probailities i bet on the 2nd possibility. its very unlikly thats someone moves from denmark to slovenia. but bad code is very likely.
Gateways have a unique identifier, its EUI, just like devices. Almost all of them check in with the gateway server every 30 seconds. So a gateway submitting an uplink will have matching network info the same as the heartbeat.
The glitch you describe has to be to provide an outlier gateway, something somewhere would have to submit the identical uplink - let’s assume in the area the others are - and the glitch would have to transform the gateway id/EUI inside the LNS in to the one for Denmark - which is a pretty amazing co-incidence that it hit lucky and produced a valid gateway.
Alternative glitches would be a corruption in the id/EUI in the Protocol Buffers structure as it passed through the Network & App Server or a corruption when the HTTPS was decrypted at TTN Mapper or a corruption during processing of the JSON.
Whereas we see gateways being moved regularly enough, internally or just bought/sold on the open market. In this case, most likely an internal move as a new registration would presumably set a more appropriate location. Or even that the owner of the gateway wants to pretend to be somewhere they aren’t. As we don’t get an IP address in the meta data there is no way to geolocate it.
Checking the gateway status, the Id is still reporting the same location, so it wasn’t a glitch that messed up the gateway lat & long.
Sure, at the end of the day this sort of anomaly can just be ignored, which is why I didn’t comment previously. But, given the design of TTN Mapper, it can’t have been a GPS glitch as all the other gateways heard the same location for the device, your original thesis, and I’d be surprised if the enterprise hardware that TTI uses at Amazon is prone to in-memory corruption, particularly as it is likely to have ECC modules.
We often see such anomolous readings/data captures for various reasons, some as described. I spend a lot of time mapping and it can be an irritiation working out what may have happened/eliminating obvious errors. In this case if you look at the GW colour you will note that it isn’t atually a TTN deployment GW, rather there are a bunch of private network GW’s in/around Copenhagen that are peered with TTN. This allows for mutual data sharing - hence you see a value catured by their network. Many private networks do this and are mutually beneficial to TTN users (e.g. SmartBerks/Reading Council here in UK), sadly many take from TTN only and dont share back (looking at you Connexin! 
). In this case it is entirely possible that the private network originally provisioned a unit in Copenhagen - hence location identification - but subsequently deployed it much closer to your GPS source, placing it in range. Private networks often redeploy in such a way for their own priority coverage needs, spares, etc. and we have no control or influence on this. More irritating and typical of what happens is one example here in the UK where I often do Tracker/Mapping/Range tests on devices from the Cliveden escarpment over looking the River Thames. All well and good and a reasonably well know/predicatable environment from coverage POV, but then I will get a spurious hit to a GW close to Durham in the N.East of England…WTF! Investigation of that GW shows it is likely being used to monitor a mobile home/caravan - (T&H, Gas bottle or Water tank levels, intrusion or whatever). Every so often the owner must drive it down to somewhere in range of the Thames Valley and the Cliveden estate. I then see a hit(s). Must be visiting friends or relatives, or simply in passing along one of the local motorways transiting through. One of the problems of having mobile vs fixed GW’s. When I see I now ignore…