# LoRaWAN duty cycle abuse **URL:** \ **Category:** LoRaWAN Discussions\ **Created:** [March 9, 2017, 9:47am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945 "2017-03-09T09:47:28Z")\ **Posts on this page:** 1\ **Showing post:** 25
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [September 29, 2017, 10:49am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/25 "2017-09-29T10:49:20Z")
> [@htdvisser](#): > > This indeed seems to be the backend desperately trying to get that device off SF12 using ADR. Like you wrote elsewhere: TTN deployed a fix to send commands on SF12 if a node is erroneously expecting RX2 to use the LoRaWAN default SF12 rather than [the TTN EU868 SF9](https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/Frequency-Plans#lorawan-frequencies_eu863-870), and is not responding to the SF9 ADR command. This specific node is now at SF8, since it received the new 22 bytes network settings on SF12 at 11:57 below, after the earlier 17 bytes message on SF9 did not make the node change its settings: ![image](https://www.thethingsnetwork.org/forum/uploads/default/original/2X/8/86e6125e2c5299f4422a7cfea6ce0c343fb9ef91.jpg) Still then, new abuse or bug: the node is not doing any channel hopping anymore ☹ --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945)._