SF7 for short range drives, yes.
Higher SF is unnecessarily long and might give probs.
SF 10 and keeping the content of your packets to just a few bytes is probably a good compromise
or, to base advice on data,
of about 190,000 successful mapping points in my city,
SF7 87530
SF8 13446
SF9 6049
SF10 6281
SF11 2727
SF12 72524
so that suggests what setting you wanna use.
Thanks for your help,
from the top floor I have the best success with SF10,
unfortunately only there and only at the window.
Other floors do not want:-(
What is the 0xFF supposed to do?
No local community on https://www.thethingsnetwork.org/community?
Did you see ttnmapper.org? (That only shows results of people who go out mapping explicitly, but may give you some idea.)
Aside: note that thermally insulating glass will affect reception too, so go outside when testing the range.
Such list shows what others are using, but unless the majority is using ADR it doesn’t necessarily indicate which settings are needed for proper reception? Other factors, most importantly battery life and the TTN Fair Access Policy will affect a proper choice too?
No, it does not, at all. It’s actually utterly without any meaning at all.
What spreading factor is actually appropriate depends on the path from a node to the best reachable gateway with good uptime.
the comment about window glass is correct - coated glass has significant attenuation.
also yes, of course you want to keep an eye on battery use (the higher the SF, the more battery use) and follow the fair use policy.
the data i showed are for gateways whose behaviour i have no knowledge of, and for a wide variety of mapping devices - it just shows what statistically goes through and what doesn’t, no more, no less.
when you are mapping, riding/driving the city, you typically don’t know where to expect gateways and what kind - so you can’t optimize for a specific link.
I even find “goes through” difficult in this context. I understand that’s not what you’re implying, but one cannot interpret the numbers for SF12 to indicate that SF11 and better would not have “gone through” for those. (Unless you know ADR was used, or at least know that the number of ADR-enabled devices is evenly distributed over the SFs in that list.)
It may be interesting to see how many of those did use ADR, and on how many of that city’s gateways a packet for each SF was received on average, regardless ADR. (And even then there’s more to know, like how many of the SF12 devices are ABP or pre-October 2019 OTAA devices that do not get ADR MAC commands due to TTN erroneously using SF12 for RX2 when one confirmation of a MAC command failed.)
Agreed. 
No, there’s no blocking in place. But after your testing you’re not allowed to fix your device to use SF11 or SF12. And see also Is there a correlation between payload length and potential packet loss?
as you say, i m not implying any of this. you might change “what goes through” to “what actually came through”. it s just statistics of the distribution i get in an
- urban environment
- with mapping nodes doing ADR (to answer you question)
- and no knowledge of gateways involved
it s what works (or rather, results) for a random “mapping cruise” through a city (“i drove through town with a node”, Alexander said), not meant for optimizing specific links.
Well, that’s makes for an invalid experiment.
The timescales of ADR are orders of magnitude too long for anything that moves
If you want to do mapping, use a fixed reasonable SF like SF10 with a short packet; slower spreading factors pretty quickly hit usability limits, but where you have spotty coverage at SF10 you might perhaps do better with a slower one. And based on the signal quality of the SF10 you can estimate if something actually deployed in that location could run faster.
perfectly valid data, not sure what experiment you are referring to.
i understand you favor SF10 for mapping, while i suggest SF7, which i observe to be working fine for dense urban environments. i guess it is fine to have diverging opinions here.
not sure the remainder of the arguments contributes much to the original question.
Hallo Alex,
visit the TTN-Slack Channel of Cologne. There are many people that will help you.
1 Like
You stated that you did mapping with ADR.
I explained that mapping with ADR is not workable, as ADR takes orders of magnitude too long to adjust to a change in connectivity. In effect, your results would say more about your path of travel, and rate of travel, than they would about the actual locations where you did (or especially didn’t) have success in getting a packet through.
In a situation where SF7 gets through, it is of course the ideal choice. But there are plenty of situations which would work with SF10, that do not work with SF7. Unlike at SF11 and SF12, at SF10 it’s possible to pack a few application bytes and the LoRaWAN headers into a packet that is still a short enough on-air period to be used for something like mapping.
If you prefer SF9, or 8, or even 7, realize that while you save airtime, you’re starting to map “no coverage” in places where SF10 actually could get a signal out.
That’s exactly the point - none of your data really means anything for the asker’s problem, because at best it’s appropriate for your situation (not theirs!) and at worst it’s not even what would be appropriate for your situation, but merely whatever you happened to try.
I said my data was taken with ADR. Where did i say they were from fast moving measurements?
Note that most field mappers of course offer ADR, as it makes good sense.
For mobile/fast-moving mapping, i suggested fixed SF7 - that, not ADR, was what the whole thread was about. If we suggested ADR, we wouldn’t have to discuss SF.
I offered my data as they are mostly from dense urban environments, so it s fair to assume some similarity to the asker’s situation.
The asker’s situation was that high SF wasn’t giving any results, in a “driving round” scenario. So going shorter makes a lot of sense, not least cos you are allowed to send more than just 3 or 4 points an hour.
https://avbentem.github.io/airtime-calculator/ttn/eu868.
But maybe the best advice comes from @wolfp - work with the local community.
You obviously did not collect 190,000 distinct points with fixed nodes.
But then when asked if you had used ADR, you confirmed that you had.
Therefore it seems you were making the invalid experiment of moving an ADR node around fairly quickly compared to the timescale at which ADR operates.
No, it is not fair to assume that AT ALL.
Where gateways are compared to where you are trying to get signal from, has absolutely nothing to do with where gateways are compared to where the asker is trying to get signal from.
If we suggested ADR, we wouldn’t have to discuss SF.
ADR still results in an SF. If one left a node in place long enough for ADR to stabilize, then absent gateway changes or construction blocking the line of site, the long-term stable ADR result would be a good choice for a static SF, too.
But the result of moving an ADR node around on a timeframe of less than days isn’t meaningful.
The asker’s situation was that high SF wasn’t giving any results, in a “driving round” scenario. So going shorter makes a lot of sense, not least cos you are allowed to send more than just 3 or 4 points an hour.
That may be true.
But your offered data is useless for determining so.
The comparative lack of mid-range SF’s in your data calls its validity for even your situation into serious question.
That EUI looks a bit dodgy, like someone just made it up.
Still weird that you can are received by that one, and not others.
EDIT: I can find the following information for this EUI on https://www.thethingsnetwork.org/gateway-data/ :
“eui-0908070605040302”:{“id”:“eui-0908070605040302”,“description”:“Boltenburg Unternehmensgruppe, Standort Remscheid, Service-Line: 0700 - 80 80 80 08”,“owner”:“hartmut-boltenburg”,“owners”:[“hartmut-boltenburg”],“location”:{“latitude”:51.18321709,“longitude”:7.22158692,“altitude”:398},“country_code”:“de”,“attributes”:{“antenna_model”:“Procom CXL 900-3LW-NB / 868 MHz mit 32m Koaxkabel LCF 78/50”,“brand”:“Four-Faith”,“frequency_plan”:“EU_863_870”,“model”:“F8L10GW EU 868”,“placement”:“outdoor”},“last_seen”:“2020-09-29T11:19:55Z”}
This information gives a different location: https://goo.gl/maps/noAmJVGjooH8jNoZ9
1 Like
Nice find, but not that much different? https://maps.google.com/?q=51.18321,7.22183 vs https://maps.google.com/?q=51.18321709,7.22158692
Uplinks include the current GPS coordinates, if any, that the gateway may include (which may be fake; TTN cannot tell). And it seems https://www.thethingsnetwork.org/gateway-data/gateway/eui-0908070605040302 returns some older cached value, or more likely whatever has been entered in TTN Console.
The gateway of the Boltenburg Group near Remscheid is abt 300m MSL high. It looks from above down to the river Rhein. It should be no problem to “see” this gateway from the west of Cologne. This gateway has a huge coverage.
yes, that gateway is in a really nice place indeed, topology-wise - link to the location (west of cologne) given above is entirely possible.
2 Likes
Sorry, I must have made some typing mistake when looking them up. The locations are indeed nearly identical, so no cause for concern.
1 Like