Hi, I’m sorry the RX2 window parameters appear to be a common topic but I just noticed something that I don’t understand and I couldn’t find it mentioned anywhere else. I can see RX2 window downlink messages being sent at SF9BW125, as I would expect, but if the end device ignores about 5 or so dow…

[image] mattbrown015: if the end device ignores about 5 or so downlinks they change to SF12BW125 I think that only applies to ADR? Then, yes, courtesy of TTN: [image] LoRaWAN duty cycle abuse TTN deployed a fix to send commands on SF12 if a node is erroneously expecting RX2 to use the LoR…

Oh, I see, that’s it! I don’t think it’s a problem, I just wanted to understand in case it was important. In normal operation we will ensure we don’t set the ADR bit if we’ve selected a specific DR. Thanks! :slight_smile:

Hello, I have the same behaviour in OTAA, where ttn changes from SF9 to SF12 after a lost downlnk frame of the remote device… it is very dangereous because we lost for ever the remote device… TTN should test on RX1 instead of change RX2… what do you think? best regards, Mathieu

Hi Mathieu, It’s been 6 months since you replied to my post. I feel bad because it is not very helpful to ignore posts on a community forum. But, I didn’t receive a notification and have only just noticed your reply. :frowning: TTN should test on RX1 instead of change RX2… what do you think? I…

An erroneous fallback mechanism has been fixed for OTAA Joins that happened after October 2019. Not for OTAA devices that joined before that (and did not re-join after October 2019), and not for ABP. Also, early 2020 some things changed in the routing, making V2 gateways go through some V3 component…

RX2 Window Downlink Sent at SF12BW125 869.525

Gateways

arjanvanb (Arjan) November 5, 2018, 4:28pm 2

I think that only applies to ADR? Then, yes, courtesy of TTN: