# Repeating downlink messages with RxParamSetupReq that never stop

**URL:** <https://www.thethingsnetwork.org/forum/t/repeating-downlink-messages-with-rxparamsetupreq-that-never-stop/23916>\
**Category:** Gateways\
**Created:** [March 14, 2019, 2:13pm UTC](https://www.thethingsnetwork.org/forum/t/repeating-downlink-messages-with-rxparamsetupreq-that-never-stop/23916 "2019-03-14T14:13:59Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**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:** [March 14, 2019, 6:12pm UTC](https://www.thethingsnetwork.org/forum/t/repeating-downlink-messages-with-rxparamsetupreq-that-never-stop/23916/7 "2019-03-14T18:12:18Z")

</div>

Does expanding the uplink in the gateway’s Traffic page of TTN Console give you any details in the Trace part?

Given your:

> [@xeranos](#):
>
> In the uplink from the end node, there is a RXParamSetupAns

…your node must receive the downlink, so it’s probably _not_ sent in SF12. Just to be sure:

Is the downlink transmitted in RX2, **using SF12**? Then I guess the endless repetition is a bug:

> [@ADR problems - node of the same type have different ADR behaviour](https://www.thethingsnetwork.org/forum/t/adr-problems-node-of-the-same-type-have-different-adr-behaviour/22825/11):
>
> Now, [an example](https://www.thethingsnetwork.org/forum/t/adr-is-not-working-nucleo-raspberry-italy/10078/3) has proved that, when using RX2, TTN surely is smart enough to repeat ADR on SF12 if nothing changed when the node ignored the ADR downlink in the documented SF9. The same can been seen [in the code](https://github.com/TheThingsNetwork/ttn/blob/v2.10.0/core/networkserver/uplink_mac.go#L98-L119). But I feel TTN should not keep using SF12 for ADR in RX2 then; assuming your node _is_ using the TTN specific settings that it got in the EU868 OTAA Join Accept, it will never receive the RX2 downlinks when TTN uses SF12…

If true, then the above would be triggered by the node not acknowledging the settings after the very first ADR, which presumably was sent in RX2/SF9. (Like maybe it simply did not receive that downlink.)

That does not explain why TTN was even trying to send such first ADR, if your node does not set the ADR bit in its uplinks. It also does not explain the remaining 22 07 D4 A4 that you saw in FOpts…

If all above is true, then making the device join again, if possible, might solve it?

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/repeating-downlink-messages-with-rxparamsetupreq-that-never-stop/23916)._
