Using the ttnmapper.org app and a TTUno to check the coverage of some gateways installed at Hogeschool van Amsterdam near the Wibautstraat I found a gateway eui-84eb18fffee55226 with RSSI -109dB located in AFRICA!
Is there a ttn-robocop that checks weird gateway locations and (re)moves these from the map or [edit]notify the owner? I guess these that kind of gateways can also mess up triangulation-based position calculations.
I did have a laugh looking at the mapper radio distance: 4889KM!
Of course you never make mistakes? Can we keep this civil?
@jand Hey Jan, saw your post and wanted to say hi 
nice to see the HVA has got a gateway now On ttnmapper there is only a mechanism that automatically removes gateways that have not been seen for an extended period of time. Jpmijers is the maintainer, maybe you could DM him?
@kersing, i guess people have different kinds of humour, personally I had a laugh reading it. I am sure the post was not meant to be interpreted/taken literal in the way you did.
(Mass) shootings come in the news quite often âlatelyâ, so the word âshootâ has quite some negative associations so therefore better not use it in a âfunnyâ way.
I fully understood it was meant to be a joke, but difference in humor is exactly the reason why one should not post a remark like this. Thirty years of forum usage have thought me there will always be someone interpreting it the wrong way. (Thinking about this makes me feel old, next subject 
)
For that one we can make an exception. 
Ok, have removed my remark/joke, instead on a more serious note:
Do we have somewhere that @jand could look and find the owner, so he is able to send him/here a polite mail/message about the location?
I guess, the weather conditions must have been truly exceptional!
I donât think so, however if you want to help the gateway owners correct the mistake you can (as long as they registered their gateway). Go to the main TTN page, scroll down to the map and zoom the map to the location where the wrong gateway is listed, now click on the antenna symbol and it will list the known information on the gateway (or list multiple gateways which you can check one by one). If the gateway is registered you should see a link you can click to go to the owner page which has a button to contact the owner.
There are currently 5 gateways in the center of Africa so have fun helping at least 4 of those owners to correct the gateway information.
84:eb:18:e5:52:26 is a MAC address that lists Texas Instruments as vendor.
And this map image may give some hints:
19 gateways at the exact same location, only 5 of which active. The 5 gateways are owned by different TTN users.
These users have used bogus coordinates, these coordinates: 10.0, 20.0
Thanks for the edit.
Iâm afraid that takes 30 years of gaining your own experience and most definitely is not free. You need a computer, Internet access (in the old days a modem and telephone connection charges which were expensive compared to the flat fee we pay these days), money to buy some people a beer after stepping on their toes or grovel and apologize (which some people find more expensive).
Ha die Sven, long time no see!
Yes, finally students can play with theTTN-UNOâs you designed and have their packets actually delivered to the internet The gateways are also to be used by Surfnet. I think the idea is to have a âoff-bandâ way to monitor the network.
I have justed started reviving your old TTUnoâs by updating the RN2483âs to 1.03 and checking the coverage. The OTAA process seems to suffer most from a bad connection.
The backend part of LORA is still new to me and I want to try out our royal commercial partner also - do you know if it is easy to connect the TTNUNO to KPN LORA? Free access is given at
https://loradeveloper.mendixcloud.com/login.html
As far as I understand the TTN mapper is not responsible for wrong gateway config, although it could detect strange values like 5000KM ranges. Just like agentschap telecom should detect âillegalâ use of the radio frequencies and jammers I think the gateway data should be checked too. I wonder how KPN does that.
They own the gateway so are able to fix the data themselves.
I think @jpmeijers will gladly update his data validation mechanism. However, that will not update the gateway information to the correct coordinates not signal the issue to the owner. @jpmeijers does the data you use include contact details we (==the community) could use to notify gateway owners?
Those are the defaults in the stock global_conf.json as provided with some packet forwarders like poly_pkt_fwd and mp_pkt_fwd. Iâll update the mp_pkt_fwd repo example config to remove the coordinates. @devlaam could you do the same for your repo?
@gonzalo Could you update the default global_conf.json for the ttn-zh packet forwarder fork not to set fake_gps to true? And remove the âdefaultâ coordinates from it as well? It probably will require updates to all configs in gateway-remote-config repo but will prevent inaccurately placed gateways on the map and while mapping.
[edit]I pushed the update for mp_pkt_fwd.
Keep in mind people should not be using those config files as theyâre not tuned for TTN anyway. When installing the software you need to get the TTN specific version for your region from TTN github repo.
The MultiTech Conduit build of MP forwarder does this on (re)start of the sofware, the resin.io build for the RPi as provided by @jpmeijers does this as well.
Exactly, therefore âdefaultâ configurations (when unaltered) should fail.
Maybe to clarify a bit here:
The iOS and Android app uses the coordinates for the gateways as they are obtained in the metadata of the packet when it is received from TTN. This is blindly used to draw where a gateway says it is on the map in the app.
On the TTN Mapper website the gateway locations are obtained directly from TTN and common incorrect locations are filtered out. The map on the website will therefore most likely not show this 3000km link.
So the ttn site DOES have some filtering on gateway locations but the filtering is not done on the metadata in the packages ttn forwards and the app doesnât have filtering by itself.
And anyone can install gateways with default (bogus) gps locations.
Thanks for the clarification.
TTN mapper does some data validation. TTN mapper is not run by The Things Network but by @jpmeijers. The data your mobile receives is obtained directly from The Things Network.
Gateway locations are set by the owner (and for UDP connected gateway they can be set by anyone caring to delve a bit into the protocol, that is partly why TTN created a protocol with authentication) There is no validation on data the owner provides, would be hard to do anyway without auditors visiting the gateway and validating the position data.