Hello everybody
I have the following problem:
I get a connection to the remote gateways about 36km
In my city there are 43 of them. And I can’t get in touch with theirs.
I use FRM95W, lmic library, CFG_eu868
is sent with “LMIC_setDrTxpow (DR_SF11,0xFF);”
Can someone tell me what the problem is?
I would be very grateful for the help.
That does seem rather strange. Can you tell us your exact location and the location of the gateway that is 36km away so we can look at the line of sight.
Please consider that the location is entered by the user so any number of gateways may have their location misreported - but I’d expect you to reach of the more local gateways.
In that respect, just in case the long duration of the SF11 transmission is causing issues, try SF7 or 8 as well.
Hello,
Thank you for your answer.
That’s the data:
“time”: “2020-09-27T12:56:16.589742888Z”,
“frequency”: 867.1,
“modulation”: “LORA”,
“data_rate”: “SF11BW125”,
“coding_rate”: “4/5”,
“gateways”: [
{
“gtw_id”: “eui-0908070605040302”,
“timestamp”: 1791440876,
“time”: “2020-09-27T12:56:26.164683Z”,
“channel”: 0,
“rssi”: -118,
“snr”: -8,
“latitude”: 51.18321,
“longitude”: 7.22183,
“altitude”: 390
}
],
“latitude”: 50.963551,
“longitude”: 6.837021,
“location_source”: “registry”
}
I also tried SF7, SF8 without any result
Well, it s legit that you would see that gateway 36 km away, as that seems to be a rather strong one, judging from ttnmapper.
so the question really is, why not any of the gateways closer to you?
SF11 might be part of the explanation, but you d probably have to look at
a. your precise location (it s urban, right? - are you very “hidden”?)
b. antenna?
I drove through town with the node - it was nothing
Antenna is a piece of wire 8.6 cm
hhmm, that sounds about right. you should see something at least.
i d suggest testing it with some known gateway,
somebody to test it together with, if you know someone?
it doesn’t look good, I don’t know anyone.
Will the SF11 possibly be blocked?
Do I have a better chance of driving around town with SF8?
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
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.
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.