ADR doesn't work (915 MHz Band - ABP)

End Devices (Nodes) LMIC
9

Good, so LMIC is setting the ADRACKReq bit and TTN is including the LinkADRReq MAC commands in FOpts of the downlink. All fine so far!

Next: LMIC should change its settings and include a LinkADRAns in its next uplink, if all was well.

I guess “simulate” should read “scheduling”. In the gateway’s Traffic page you’ll probably also see that TTN has forwarded/delegated the downlink to the gateway? (If not, then TTN Console may just not be working fine, or it may have selected another gateway if the uplink was received by multiple gateways. But given the distance to your gateway I’d say TTN would choose yours for that downlink.)

So, does the device receive the downlink? As yours is even a confirmed downlink, LMIC should set the ACK bit in its next uplink. (And otherwise you’d see TTN repeating the downlink after the next uplink.) You should also be able to print the downlink’s payload in the device’s log.

If it’s not receiving the downlink, then you may need to validate the frequency plan settings, and look at timing issues. Or you may even need to peek into the gateway’s log to ensure it’s sending it.

If the device is receiving the downlink: is LMIC including the LinkADRAns MAC command in FOpts of its next uplink?

And to be very sure, you could try to decipher the LinkADRReq to see what TTN is requesting.

Finally, always make sure to keep at least a few meters between gateway and device.

10

Ah! That’s an EU868 setting, which I think does not apply to any frequency plan that uses 915 MHz? So, if the downlink is sent in RX2 then the device is not likely to receive it.

The gateway’s Traffic page should show the frequency that is used, from which you can decipher if it’s RX1 or RX2.

(Aside: which frequency plan are you using?)

11

Thanks for the help!
Now looking more deeply inside the arduino LMIC.dataLen = 0 and LMIC.dataBeg = 0, does this mean that my device is not receiving the downlinks?
For this reason it may not print in serial monitor.
imagen
And also for this same reason ADR doesnt work.
My frequency plan is US902-928, #define CFG_us915 1 in lmic_proyect_config.h
About timing issues I set LMIC_setClockError((MAX_CLOCK_ERROR * 5) / 100) in void setup, and doesn’t work. I have only one gateway, the downlink reaches the gateway I see this in logs.
I remove the line with LMIC.dn2Dr ​​= DR_SF9 in the sketch.
The traffic gateways shows the downlinks in RX1 because the SF10 in this band RX2 sending at SF12: https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html
imagen

12

From your log, it looks like you are getting ADR responses (you can click into one of the those downlinks to be sure…)

So most likely the problem is that your node is not correctly receiving - typically the error is a timing one, but it could also be a frequency or settings problem.

13

Yes its ADR responses but i Think this responses dont reach the device and also for this reason ADR doesnt work.
If LMIC.dataLen = 0 and LMIC.dataBeg = 0, does this mean that my device is not receiving the downlinks?
Thanks

14

Only if the downlink had some application payload, like you showed earlier.

The downlinks shown in your screenshot of TTN Console’s gateway Traffic have a total length for the full LoRaWAN packet of 22 bytes. If that would have the MAC commands in FOpts, then I’d expect 12 bytes for the LoRaWAN overhead (FPort is not needed when there’s no FRMPayload) and 2 × 5 bytes for the 0340020071 033500FF01 LinkADRReq MAC commands that you saw earlier. So, a total packet size of 22 bytes for the downlink indeed seems to indicate two LinkADRReq’s like you saw earlier, without any application payload. Those 22 bytes could also be an application payload of 9 bytes, without any LinkADRReq. But in that case, LMIC.dataLen should be 9.

So, it seems TTN has created its own downlink, just for ADR. Normally, it would only do that if the device has set its ADRACKReq bit (after 64 uplinks without receiving a downlink), in which case TTN must send a LinkADRReq within the next 32 uplinks. In this case, with the low uplink counter, apparently TTN is repeating the ADR downlink as it knows it’s still awaiting the LinkADRAns from the device.

Without any application payload LMIC.dataLen will be zero indeed. To possibly see that log, just schedule a new downlink with some (dummy) payload (using “replace” to be sure), allowing TTN to piggyback on that. Also, please check if there is any LinkADRAns in the uplinks. I guess you won’t see that log, and won’t see that LinkADRAns as the device has not received the downlink.

Aside: just for the sake of completeness: LMIC may also reject downlinks, if the downlink counter is not higher than the last value it knows. But seeing that your uplink counters started at zero again, I assume you restarted the device (and have the frame counter security disabled?), so LMIC will have its last known downlink counter reset to zero too. As a result it would accept the high downlink counter of 344 just fine. At some point using ABP is going to bite you, for all these details that can be out of sync. However, OTAA needs downlinks too, so I’d focus on the downlinks now.

Did you also set LMIC_ENABLE_arbitrary_clock_error to allow for values larger than 0.4 / 100? And did you try with, say, 20% or even 100%, just to go wild?

Just to be sure: that’s the logs on the gateway, right? The screenshot of TTN Console only tells you if TTN has delegated it to the gateway. A gateway may reject it if it arrives at the gateway too late to be transmitted.

Aside: please don’t post text (like text from the online packet decoder results, and code) as images. See also How do I format my forum post? [HowTo]

15

I set LMIC_setClockError((MAX_CLOCK_ERROR * 5) / 100) in void setup, and try with 20% or even 100%, may doesnt works ( i set LMIC_ENABLE_arbitrary_clock_error in lmic_proyect_config.h)
I schedule a downlink in TTN with a payload (220022 for example), the packet reach de gateway (i see this in the logs of the gateway with this payload) but i think the gateway it is not sending it to the node because in logs of the gateway the line in strong.
https://wiki.dragino.com/index.php?title=Communication_with_ABP_End_Node

"When there is an upstream from end node, this downstream will be sent and shows:
lora_pkt_fwd[4286]: INFO: tx_start_delay=1497 (1497.000000) - (1497, bw_delay=0.000000, notch_delay=0.000000)
lora_pkt_fwd[4286]: [LGWSEND]lgw_send done: count_us=3537314420, freq=923300000, size=17"
This is the log
imagen
With a downlink payload 220022 LMIC.dataLen and (LMIC.dataBeg still in zero. LMIC.txrxFlags is 32. In the gateway parameters of channels set for uplink matches with US902-928, the uplink works. According to LoRaWAN spec, the downlink radio parameters frequency is defined by network server (TTN). LPS8 will adjust downlink parameters according to info from TTN, this doesnt works, but i see the downlink radio parameters sends with TTN they’re right according the bandplan.
http://wiki.dragino.com/index.php?title=LoRaWAN_Communication_Debu
Thank you very much for the help Arjan.

16

I see many log examples on this forum with “tx_start_delay” but without that “lgw_send done” part, and the REPORT lines show no errors. So I wonder if that documentation is accurate. But indeed, one may expect some confirmation that a downlink was sent, so you may be on the right track…

I’d create a new topic, e.g., “How to tell if Dragino LPS8 has transmitted downlink” along with the non-LMIC parts of the details that you posted above. Please, post the log as text, not as an image. Also please prefix quotes from the documentation with a > to make things a bit easier to read.

17

Thanks a lot for the help Arjan, I was able to fix the problem in the reception of the downlinks adding the lines in the sketch inside void loop:

Here is may code:

unsigned long now;
now = millis();
if ((now & 512) != 0) {
  digitalWrite(13, HIGH);
}
else {
  digitalWrite(13, LOW);
} 

os_runloop_once();

From here the downlinks began to arrive and ADR worked correctly. I leave my solution in case someone does the same.
Thank you very much again for the help.
Regards.

18

Nice, but what’s connected to pin 13?

(Aside, please see How do I format my forum post? [HowTo])

19

It seems I asked the same question for the very same code in another topic last year:

Great that this seems to fix ADR (or, downlinks in general) for you, but do you (or anyone) have any idea why? Are you using any sensors in your code?

1 Like
20

From what I have been able to find out, this code slows down the void loop since the pro mini would hang after a while and it would have to be reset. After adding this code, not only the downlinks are received but it also no longer hangs.

You who have experience, for what reason if I don’t turn on adr setting the SF to a fixed one, the SF even so changes for example SF7 to SF8 or SF9 or SF10.

Here is my code.
// Disable link check validation
LMIC_setLinkCheckMode(0);
// Set data rate and transmit power for uplink
LMIC_setDrTxpow(DR_SF7,14);
//Enable or disable data rate adaptation. Should be turned off if the device is mobile.
LMIC_setAdrMode(0);

My packets in the uplink dont carry enabled any bit of ADR, in downlink neither.
Uplink:

FCtrl = 00
FCnt = 0000 (Big Endian)
FOpts =

Message Type = Confirmed Data Up
Direction = up
FCnt = 0
FCtrl.ACK = false
FCtrl.ADR = false

Downlink:

FCtrl = 20
FCnt = 0000 (Big Endian)
FOpts =

Message Type = Unconfirmed Data Down
Direction = down
FCnt = 0
FCtrl.ACK = true
FCtrl.ADR = false

I have enabled ACKs for the uplinks without acks SF not change.
When I did the tests without ADR and the SF was modified, it was when there were not good channel conditions and some packets were lost.
Maybe this is the cause because the SF change?
Thanks for the help.

21

Keep in mind you are allowed only 10 acks of other downlinks a day.

22

Yes, I have it clear, it is only to see the operation without ADR. Still this doesn’t answer my question.

23

Realistically:

  1. Use an up-to-date LMiC especially if you want ADR without OTAA; there were bugs that made that combination not work

  2. DO NOT USE AN ATMEGA328 - you don’t have the resources in that chip to do things properly

  3. Do not use confirmed uplink, the design of that in LoRaWAN is basically broken

24

Ok, my library is update such as https://github.com/mcci-catena/arduino-lmic.
I dont use ATMEGA, I use Arduino Pro Mini.
It is NOT possible to use ACKS?
Likewise, the reason why the SF changes when no MAC command comes inside FOpts in dowlink is not understood.

25

Arduino Pro Mino does use ATmega328P

1 Like
26

Indeed, that is pretty much the case, practically speaking

For uplink you need to just accept that packets will be lost, and use the data from the next that gets through instead.

For downlink, what you should probably do is have the receipt of a downlink make a small modification to the uplink packet, and if you get uplinks that lack that, eventually re-try the downlink. But be patient… this is not a system designed to promptly downlink things.

27

Ok I understand this point about ACks, but I dont understand why downlinks (or ACk) modify SF without MAC commands in FOpts. Is this a bug of my end node? In which fields of the frame do the SF adjustment commands come? Does the node by itself make the determination to vary its SF? or its the algorithm?
Thanks!!!

28

Yes. No. Whatever.

Read the spec. Read the code.

Add debug output.

1 Like