While looking through our gateway data to find out some distance records we found interesting gps-tracking results from one of our nodes. During a business trip (on 24th of January 2020) to Vienna (Austria) by car i took one of my TTGO-Beam board with me - its TTN Device-ID is named „jn-ttntracker_1-2“. It is running with standard software from Cyberman54 (github) – without any special modifications (oky we soldered an BME280 sensor to the device). I used a magnetic outdoor antenna on the cars roof-top. While travelling down the A3 highway i watched from time to time the node status – and lots of nearby gateways transfered the location information into the cloud. As we have the ttnmapper integration from JP Meijers running in this application i can follow up now this special travel-data.
First one is pm 3:08:22 our community gateway named „ttn-hennef-gateway04“ listening to all pakets in the air and recieved ID 126298582 from the distance 573,4 km (356,3miles). I am just passing city Wels on the A25 in Austria ….
Next one is pm 3:15:32 – seven minutes later also one of our community gateways named „ttn-siegburg-gateway01“ sent one paket of my tracker to the cloud. Now the distance is 648,5km (403miles). Still driving down the A25 – nearby city is Pöchlarn.
Some more points were tracked in the next minutes until the last one of this series at pm 03:33:33 with a total distance of 649,6 km (404 miles) – some kilometers of city Melk.
This mentioned gateways are Raspberry Pi 3 based with the IMST880a Concetrator board. Running outside with an OMB Taoglas antenna and booth are mounted on roof-tops. We are very proud of this values – thinking about this standard setup without any high-altitude balloon or any special technical laboratory settings. If you are interested in this measurements – just see my device and check the values in TTN. Let me know your opinion about this - is this real ? Or is this something strange in the database ?!
Have you verified the frame counter for each point in combination with the time of reception? Could it be that some packets have suffered from some unclarified delay?
Very long distance LoRa reception normally relies on line of sight communications.
The difference between the distance you can get between two LoRa devices at ground level in an urban area and line of sight, ground to high altitude balloon for instance, is in the region of 1000:1. At a height of 30km a high altitude balloon has line of sight over a very large area, at 30km height the radio horizon is 714km.
Ocaisionally there can be atmospheric conditions that break the normal rules, so whilst you may normally only get 10km or so in these rare conditions reception could stretch to hundreads of kilometres.
We recommend using SF7. This provides us with a map of “worst case” coverage. Due to the 1% duty cycle limit on transmissions, using the fastest spreading factor will maximize the number of measurements taken.
From experimentation it has been seen that slower spreading factors (like SF12) does not perform well when the device is mobile. This is likely due to path fading from obstacles in the radio path, causing bursts of interference (erasures) which the forward error correction can not deal with. When you are doing measurements while standing still higher spreading factors (SF9-SF12) will work, but when mobile it’s better to use SF7.
So, the SF9 you used at the point below is not strictly forbidden, but not using SF7 might be confusing when others are using the map to evaluate gateway coverage? And I even see SF11 and SF12 for other points on your map?
Yes, @arjanvanb makes a good point above that SF7 normally works better for mapping coverage. But it’s not a problem using slower SFs.
I don’t see anything obviously wrong with the data. A good next step would be to draw an elevation profile for those long links and see if it is possible taking line-of-sight and knife-edging into account. The other option is that you were lucky and experienced tropospheric ducting. Or maybe reflection off of aeroplanes, but that is highly unlikely with the time-on-air of SF9 and up.
My feeling is that there might be some reflections that helps this radio path to work. Any chance you can try this experiment again?
Looking at the timestamps of the measurements around the city of Melk it seems like you were driving very slowly. That definitely helped the slower SFs to work.
My point was merely that not using SF7 is confusing for others, who might not expect people to use worse data rates for mapping. But I guess I’m the only one worried about that.
thanks to all of you – very interesting discussion and good recommendations – i agree with the elevation profile that it cant be possible in straigth line on sight — but — maybe reflections ? … i am not sure about the traffic arround Melk - maybe there was a traffic-jam but its 5 month ago …
The most important one is that the free space loss should be compared with MAPL (Maximum Allowed Path Loss) as a result of the linkbudget. For example: If the antenna gain is having a higher gain than you account for, you have a discrepancy.
Sporadic-E has never been accomplished higher than 250MHz. Over meteor scatter even on 432MHz it is almost impossbile to work anything without having a few hundred watts and a >20dBi antenna setup on both sides. The same for Airplane scatter. I do work with this mode as a HAM on 70cm and 23cm but with huge Yagis (>19Ele). I cannot imagine how this little LoRa Power should reach anything with this little undirected power.
But I guess something: Tropo. Why? There was a quite rare january report of a duct around that date:
My point was merely that not using SF7 is confusing for others, who might not expect people to use worse data rates for mapping. But I guess I’m the only one worried about that.