Yesterday I finally got a node with GPS working for ttn mapper. Cycled from work and got the expected result:
However one of the packets apperantly found it’s way all the way from west coast of Norway to Lithuania!
Surely this is not real. What can be the reason? The only thing that I can think of is that I’ve poorly named the node, and I’m thinking that others have nodes with the same device-id.
Mmm… if the gateway is really in Vilnius, then coordinates are correct, this is something to investigate.
Since the collected packet is on your path, in principle your device id should not matter much (maybe except when you are looking at special maps - there you have to put a device id), but the TTN Mapper developer should better know…
I found data using my device-id today in Italy under “advanced map option” So perhaps it is source of error. I will change it to something random to avoid future duplicate’s.
I think this should be the only case, but if by chance @jpmeijers used the device-id as unique in the world also in the overall mapping yes, it could be (and by the way, since my tracker too has a very basic id, I checked whether I have points in Norway but no, it’s not mine ).
Duplicate device ID’s should not be a problem. Internally the app-id and dev-id are used to uniquely identify devices. The special maps dev-id input is just a simple filter to show data.
The lines you see on the map is directly from the metadata obtained from TTN. So if you see a line between Norway and Lithuania, the metadata in the packet said that your specific device, at its reported location, was received by that gateway. And according to the metadata that gateway is in Lithuania.
Most likely the issue here is either an incorrectly configured gateway, or two gateways both using the same EUI.
… and the same owner has also a gateway set to Bergen coordinates:
“SmartCity Vilnius HQ2”,“owner”:“gobas”,“owners”:[“gobas”],“location”:{“latitude”:60.38515853881836,“longitude”:5.333629131317139,“altitude”:26},“country_code”:“no”,“attributes”:{“frequency_plan”:“EU_863_870”,“placement”:“outdoor”},“last_seen”:“2019-04-26T06:56:32Z”}
Sounds like that must be the reason indeed.
below is data from ttnmapper the SNR &RSSI is quite low, perhaps the signal bounced off an A380 passing over Sweden;)
On TTN Mapper looking at all the points that have every been mapped for 0000024B08030A15, the map looks like this:
Judging from this the gateway surely must be located in Bergen. We would need some more LoRdriving to determine where exactly.
A lot of mapping has been done in Vilnius for the other gateway of the same user, so if 0000024B08030A15 was located there we surely should have seen points for it in Vilnius on TTN Mapper. This gateway (0000024B08030A15) also has its location set on the console and not via the GPS in the gateway, so maybe just a misconfiguration.
Hi @kjetilsn, if all the gateways are configured correctly then you may have encountered transient tropospheric ducting.
I have encountered this many times in my past work as an engineer on 3G and 4G mobile networks. Distant (hundreds of km away) UHF terrestrial TV broadcast transmissions appear temporarily and disrupt the 700MHz band. This happens much more than we realise, it’s just not recorded very often.
There are even tropospheric ducting forecasts, such as…
Thank you all for your feedback on this!
I think it is pretty clear that the gateway is in Bergen as suspected. Would have been awesome if it weren’t;)