RX2 Window Downlink Sent at SF12BW125 869.525

Gateways
1

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 downlinks they change to SF12BW125.

What I’m doing is a bit strange and probably not a valid use-case but it would be good to understand.

I’m forcing the end-device to use a specific DR and not disabling ADR. Nothing interesting happens if the end-device transmits at DRs above and including SF11BW125.

If the end-device transmits 20 messages at SF7BW125, with the ADR bit set, and then changes to SF12BW125 TTN starts sending ADR requests, as expected, using SF9BW125 869.525.

If the end-device ignores the ADR requests and continues transmitting at SF12BW125 the downlink messages change to SF12BW125 869.525.

Is this expected TTN behaviour?

Thanks,
Matt

2

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

1 Like
3

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:

4

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

5

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 think it is too late to change any of this. TTN have made their decision and they know more about it than me.

Regards,
Matt

6

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 components. I don’t know the details, and don’t know if that might affect this.