Class C downlinks failing from changing rx2 data rate

TTN Network and Services The Things Stack v3
1

Hi all,

Setup:

  • TTS Cloud Standard
  • RAK Gateway
  • RAK End Node

Situation:
Im running into a recurring sporadic problem where Class C devices stop receiving downlinks. I believe I’ve narrowed the issue to the Network Server scheduling the downlink using a different data rate than what’s set. Currently, I have the desired rx2 data rate set to 12, and ADR is turned off on both the Network Server and the end device.

image

When I first start the device, it is able to receive downlinks, but after a certain amount of time (say 24-48 hours) the Network Server changes the data rate. I am able to verify that the data rate changes by looking at the debugging logs of my gateway. See an example below where dr=13 instead of 12

Fri May  9 19:46:13 2025 user.debug basicstation[3968]: [LOG:DEBU] rrd_statistic_down-421 downlinkTqByAirtime: dr=13, timeonair=13, tm=1746819973
Fri May  9 19:46:13 2025 user.debug basicstation[3968]: [LOG:DEBU] rrd_statistic_down-423 downlinkTqByPkt: dr=13, tm=1746819973
Fri May  9 19:46:13 2025 user.debug basicstation[3968]: [AIO:DEBU] [5|WS] > {"msgtype":"dntxed","seqno":70,"diid":70,"DR":13,"Freq":926900000,"DevEui":"00-00-00-00-00-00-00-01","rctx":0,"xtime":41658301258945080,"txtime":5521759.889923,"gpstime":0}
Fri May  9 19:46:13 2025 user.info basicstation[3968]: [S2E:INFO] TX ::1 diid=70 [ant#0] - dntxed: 926.9MHz 26.0dBm ant#0(0) DR13 SF7/BW500 frame=A0CED4FE2726C5030D121E49..6093AB7F (20 bytes)
Fri May  9 19:46:13 2025 user.debug basicstation[3968]: [S2E:DEBU] Tx done diid=70

Another issue is that this is sporadic, so somewhere from 25% - 50% of devices that I deploy run into this issue.

Any insight to this issue?

EDIT: to clarify, I am referring to downlinks I am initiating, not as a result of a confirmed uplink.

2

Not only the datarate is different, also the frequency is. The default Rx2 frequency for US915 (which I assume you’re using, you haven’t mentioned that) is 923.3MHz. However, your log shows 926.9MHz, which is a normal downlink channel.

When using Class C, the usual Rx1 and Rx2 window are still valid. Rx2 admittedly is equal to the RxC (class C) window, but to me, it appears very likely that these downlinks are simply scheduled as normal downlinks.

Is there a problem with those downlinks being sent in the Rx1 window instead of the Rx2/RxC window? Did you specifically set these to Class C downlinks, or did you simply schedule “a downlink”?

(Note that I don’t know if they are actually sent in Rx1, it’s my best guess. It could very well be something else at play here.)

3

Correct this is US915. I realised in my excitement to send the logging data I had attached a log for a confirmed uplink reply, so I assume thats why the frequency is different.

Now murphys law is at play and I cannot even get the NS to schedule a confirmed downlink for the effected end device, though unconfirmed downlinks are being scheduled.

I’ll update the logs when I figure out how to get the downlinks working correctly, though my original issue still stands…stay tuned

4

Both are pushing the boundaries of mainstream usage and may be contributing to the problem. Confirmed uplinks could push the downlink to Rx2 or even just the gateway not having the air time. SF12 needs a smallish packet to stay under dwell time limits - and the LA requests network providers to limit the use of SF11 & 12.

Do you devices really need SF12 or is this just “to be sure”?

5

@descartes for US915, DR12 is SF8BW500 and DR13 is SF7BW500.

6

If I am manually initiating a downlink I don’t really need a high DR. For me my main concern with downlinks is reliability.

To clarify, I am not talking about downlinks being sent as a result of a confirmed uplink. I am referring to downlinks I am sending to update device states for my application. I can try lowering the RX2 DR to see if that resolves the problem.