On some highways in the Netherlands in ttnmapper I see some implausible red dots where no gateway is available.
It seems to me someone is polluting the database and map with his specific experiment.
Look for example at A28, A7 and other roads with red dots. Can these points be removed?
Which ones do you have in mind - how might they be differentiated? So probably not!
Please define ‘no gateway available’ - LoRa is a Long Range technology and many areas are quite flat with some GW’s at relative height, which helps achieve significant distances, especially when assisted by good SNR’s.
Quite possible but again we would need to discriminate which tracks.
Many of the roads you call out are well trafficked and datapoints can accumulate over time. I know I have travelled up and down both of these roads several times myself over the last few years and slowly contributed many datapoints 
(I often travel with 6-10 active trackers to avoid individual device issues with duty cycle and FUP, whilst still attempting to get some granularity into the journey mapping and to assist in generating TTN coverage data!)
Not all trackers will be in cars or on bikes but may be in higher cabs of lorries/freight traffic even mounted on containers or embedded within freight vehicle loads and pallets etc…
From experience I know even SF7 can reach many 10’skm so more GW’s may be in range that you might expect. Note the Few km diameter perfect circles shown on TTN Community maps are idealised and in no way represent realworld GW coverage 
That said if you have specific instances you have concerns about then I’m sure @jpmeijers would be interested to hear.
Thanks for your reaction!
I did some research, and discovered more unlogical heatmap patterns:
TTN Coverage (ttnmapper.org)
TTN Coverage (ttnmapper.org)
TTN Coverage (ttnmapper.org)
TTN Coverage (ttnmapper.org)
TTN Coverage (ttnmapper.org)
I think there are more, but it takes time to detect and find the related gateway or device…
Indeed, trackers can be placed on high vehicles, so it’s hard to differentiate between those track points and others. In the examples above it is possible to detect wrong data visibly, but I can imagine it’s hard to detect suspicious data automatically.
Perhaps an algoritm that combines SF, RSSI and SNR in combination with distance that detects outliers? Easy question, difficult to build
FYI: I am building a gateway network in the middle of the Netherlands. I work for a Water Management Authority (Vallei en Veluwe), and we work on this with municipalities, Provinces and others.
2 Likes
Then also perhaps talk with @rish1 about working with TTI on commercial instance - if not already doing so. if you do please peer with TTN TTS instance so wider community benefits and so you also leverage community coverage to fill in your netwok blackspots as you build out! (Good for Corporate ESG goals also )
Will take a look at what you call out later…
Ok 1st rule in many situations is dont speculate…but I think I will break that.!
Looking e.g. at eui-58a0cbfffe8054e2 (WoMo112 GW) near Bocholt/Rhede as you say the tracks seem entirely implausable. If I look at last ~12months constrained data set I see this:
Which is entirely normal and nothing like the tracks you call out so strange data injected or it predates end July last year.
Now a quick look on satellite view shows no building near that location on Barge/Jahnstrasse, so I suspect something (currently) parked up there or something now placed long term around there.
Looking at the traces you highlight one starts to suspect perhaps a logistics company and the fact that (most likely) tracks go to an end point then essentialy retrace their steps (e.g. the Kastel run) makes me wonder…and speculate on another possibility. Might the GW name be an abreviation of german “Mobile Home”? As its a TTIG I wonder if its a campervan or similiar equiped with the TTIG that is then used to monitor e.g. gas bottle level (use weight!), water tank levels, general environment, perhaps motion sensing/tracking in the event of theft?!, intrusion detection or what ever. That would then explain. On TTNMapper if a GW moves (as in relocates formally) more than a certain distance from its original point to a new registered location old data gets wiped (is that right @jpmeijers ?) What we may be seeing is tracks of someones holiday trips! or again could be a freight vehicle using TTN/LoRaWAN for monitoring as above? The GW effectively travelling with the sensors but location never updated in TTN or TTNMapper… (one reason why we discourage ‘mobile’ GW’s in the community deployments (note that’s ‘mobile’ whilst active vs ‘re-deployable’, which is a must for tests and trials and coverage optimisation, etc.)
Have a similar situation here in UK where someone I suspect based near Durham (N.East UK) area goes to somewhere near me in Thames Valley (perhaps other way around) and visits folk a few times a year in a campervan (GW ID “mymotorhome”!) and I suddenly find my test mapping gets hits from high on Cliveden escarpment all the way to Cassop - County Durham! 
Sadly as TTN V2 suffered bit rot and in the transition to V3 (now TTN TTS) TTI core turned off various useful console info on main, or community maps that would previously have allowed us to reach out to users, owners and ‘usernames’ to message and say WTF is going on here but that is now a challenge! Perhaps @jpmeijers can see more from his data feeds…
Looking at another you highlight - Zupten:
That is less of a concern and just looks like normal tracks (Wonder, given GW name, if connected to Laurens Slats formerly of TTI?)
Note these tracks I collected (not on TTNMapper but much of the same/similar data would have been fed onto there - IIRC these are original Semtech/iMST LoRaMOTEs that I cant get to decode in TTN hence nor feed to TTNMapper!), that shows similar shapes and levels of general coverage (across many GW’s in the region) over several days last year:
Specifically for Zupten area - which includes the same GW for data capture:
No time to look at rest for now - will look again tonight…
Looks like some of the data are not correct or corrupt.
A very quick glance at one point
RSSI of -78dBm
Distance of 112Km
I don’t believe this is achievable, free space loss is 132dB (ether very high TX power, or very high gain antennas) for that RSSI
Actually if you look at a few of these nodes they set some new records
Actually for that one if you look and ignore the odd genuine GW’s hit en route I suspect that the majority of those points (and fact they are high RSSI/Red) are tied to some guy or gal with a TTIG and a RPi customer build that likely is/are also mobile per my potential explaination above. Pity is we dont yet know who Berny is! (GW ID’s BernyTTIG & BernyDragino !!!), unless of course its @berny who is a bit of an old timer wrt TTN and as been around for fair time now…?
At least we know where they like to go for holidays or to see family!
As for
That one seems to hit GW’s with names like “skyhigh-leeuwarden” and “skyhigh-haarlem” which might give us a clue as to how/why they get such great range! (Some of the others in the Amsterdam area also mounted very high with great coverage I believe) Especially over the A7 route and particularly on the viaduct section (had great hits along here myself way back after visits with Jac @kersing and Leonel @bluejedi ) in Noord-Holland and Frysian and across Ijsselmeer/Markermeer
Exceptionally well tuned node.
Here’s a hit I got two days ago (note a slightly different website, same TTN datafeed) on a hike:
Completely standard SX1262 with 2dBi ~8cm omni-directional antenna.
So yes, this is ‘easily’ possible, just need some good LoS without interference.
Show off.
No Nick, he’s just a proud developer!..and fundamentally he is right, good height and good LOS are key to these long range hits. Back in Summer 2021 (grabbed 3 years ago yesterday!) I posted some of these hits captured with a (now ancient!) original RAK811 Tracker (SX127x) using stock (2.1db? IIRC) ant.
This is ~70-74km from area around the Levant Mine (National Trust) and Pandeem lighthouse up the North Cornish coast to Rob’s GW at Wadebridge. And to show not a fluke:-
This was grabbed at same time using a stock Dragino LGT-92T tracker using its internal (-3dbi?/0dbi?) small form factor antenna! Again we are looking ~70-75km range.
Then almost exactly a year later high up from around St.Catherine’s Castle near Fowey on the Cornish South Coast using the same Dragino LGT-92 (albeit then reprogrammed SF11 or 12 IIRC) I got this 186km+ hit to a GW on the North Brittany, France Coast around Ploumanac’h/Perros-Guirec
@stevencellist did Nick @descartes let you wimp out with just a Rivington Pike hike vs the full slog up to the tops around Winter Hill?! IIRC there were posts on the Forum years back from top of Snowdon all the way across to around that area (I must search when I have a few moments)
1 Like
Sort of, they did Rivington Gardens & Pike but they chose not to make the left turn up to to the masts. To be fair they did walk all the way home.
I was monitoring the hastily erected 20m mast + Dragino LPS8 on power bank lash up.
I did a little more digging on the (Red- high RSSI) tracks down the A7 and over the viaduct and checked location of GW. Won’t post detailed location due to privacy reasons but what I found wasnt a highrise building enabling great coverage but rather a corner of a housing estate and suprise suprise at immediate GPS location was this! -
The case for the prosecution rests M’Lud! (Dragino GW mounted inside?)
1 Like
Checking the (Blue - low level RSSI) tracks back up to “skyhigh-leeuwarden” GW this is more credible (Delottes/AppMachine high rise building)
Great research Jeff 
I exported points with the ‘advanced maps’ option on ttnmapper.org (great feature!)
I calculated the distance of every point to the gateway, and plotted RSSI against distance in the graph.
The gateway is 85 meter above ground level.
Most of measurements are in the city around it.
The dots with black circle around it are also marked in the map. That are points where the gateway is visible or almost visible.
So even with the gateway in sight, the RSSI decreases strongly with increasing distance. (in this specific circumstances of course, but representative for this type of landscape: low hills and many trees)
Below a printscreen of ttnmapper.org. I marked locations where the signal strength seems not to decrease with changing loation / distance from a gateway. If you pan around on ttnmapper you’ll find more locations. Because this seem to be ‘unnatural’ measurement results, this was the reason to start this topic.
Thanks to all repliers for comments, additions and expertise. I hope I didn’t bother you with my observations and analyses…
1 Like
Yep classic ISL (inverse square law) behaviour… the other factor you wont necessarily pick up on is whilst much of the mapping is done using SF7 the fact is that wrt connectivity/mapping and coverage possibilities users may also be interested in how other SF’s perform and from a coverage perspective if paying the silicon overhead for a LoRa implementation c/w what I call a ‘legacy’ modulation then, unless battery life (derived from/heavily influenced by on air time) is paramount - perhaps in some gas/water metering applications where networks constrain to just the lower SF’s in order to maximise field life - other SF’s will puturb your analysis and may explain such ‘peaks’ or clusters of results. With each SF allowing a roughly ~2.5db coding gain you can quickly see 5, 8, 10 or 12+ extra db of RSSI on your plots, so someone doing a run using say SF10 (picked that as nominal limit for e.g. US915 due to dwell time restrictions) will show a nice long series of data points and reasonably higher RSSI values and will demonstrate TTN coverage in that area.
Ultiately though, I suspect many of these long runs with no/few missing data points are actually people using travelling GW’s! Gaps might appear where the (usually cellular) GW backhaul drops out in a mobile black spot…
“Attack of the camper vans” - sounds like a doctor who episode!
Thanks for these IDs. They have been blacklisted and are currently reprocessing, so should disappear from the global heatmap and beams in the next week:
raglan-rpi-ic880a-upgrade
smart-united-04
eui-58a0cbfffe802ef0
eui-a84041ffff22d5f0
eui-58a0cbfffe8054e2
laurenshps-rak04
Lists like these are really helpful. I do not get time finding rogue devices, gateways, or mapping sessions, so if you stumble upon any, please let me know and I’ll clean up!
eui-2cf7f1c05460065c and eui-2cf7f1c054100594 also cleaned up for the periods @Johan_Scheepers linked.
| Type | Name | ID | EUI |
|---|---|---|---|
| Gateway | BernyDragino | eui-b827eb4e61d5ffff | B827EB4E61D5FFFF |
| Tracker | eui-2cf7f1c05460065c | ||
| Gateway | smart-united-02-MatchX-1701 | eui-40d63cfffe1f8525 | 40D63CFFFE1F8525 |
| Tracker | eui-2cf7f1c054100340 | ||
| Gateway | LoRaBorg | eui-a84041ffff24a524 | A84041FFFF24A524 |
| Tracker | eui-2cf7f1c05380089b |
In addition to previous conversation I found some more gateways/trackers with strange data.
The combination of device eui-2cf7f1c05460065c and gateway eui-b827eb4e61d5ffff was cleaned before, but I think it needs cleaning months or years before.