For SF10 TTN will not force a LinkADRReq as soon as it can (it will for SF12). So, TTN will await a downlink, or for the device to set its ADRACKReq bit. The latter will take at least 64 uplinks in LoRaWAN 1.0.x.
1 Like
Thanks for the reply Arjan.
TTN will await a downlink from whom? My device sends yours uplinks packet in ABP mode. Their need a reply (ACK) of TTN, this is a downlink?
Do you know how to set the ADRACKReq bit in the LMIC library?
We are working on a university project and we are new to this.
Thanks for the help and for your time.
From the link you posted:
…
A regular ADR request is scheduled when we have enough measurements and the current data rate is not optimal. The request is only scheduled, and will be attached to an existing application downlink (such as an ACK or downlink payload).
…
An ADR request is sent when the device sets the ADRAckReq bit. By default this happens after sending 64 uplinks without receiving a downlink, but as that depends on the device implementation we can’t give you an exact number here.
An ACK for a confirmed uplink would indeed be a downlink that TTN could use to piggyback the ADR on. But that would really be a waste of limited resources, when used just for ADR. (Also, LoRaWAN confirmed uplinks have a flaw.)
LMIC takes care of that for you. (But when powering down, you’ll need to save its state.)
Or maybe that would be a nice tradeoff between starting at SF10 and then allowing TTN to send an early LinkADRReq by only using a confirmed uplink soon after the 20th message.
On the other hand: after your first tests with ABP you’ll probably want to switch to OTAA. For OTAA, you could start at SF7, after which LMIC will try a worse SF if SF7 fails. More on that in ADR and gateway distance that I linked to above too.
Well thank you, so how should I proceed? Since even waiting for more than 64 uplinks the adr does not turn on and continues to send with SF10 / BW125.
Even with the ADR bit on:
Should I make any particular configuration on my end device to be up ADR with TTN?
Should I turn on the ACK bit in the transmission?
LMIC_setTxData2(1, lpp.getBuffer(), lpp.getSize(), 0)
I’m tempted to say you should know if you understand ADR by now. So maybe the best suggestion is: make sure to follow the links above and ensure you understand how it’s supposed to work.
What gateway are you using? Is that confirmed downlink that is shown in the screenshot received by the device?
And which LMIC are you using? You’ll want one that is actively maintained, such as GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment (and not GitHub - matthijskooijman/arduino-lmic: ⚠ This library is deprecated, see the README for alternatives., which was mostly tested for EU868, I think).
If you’re already using MCCI, then I’m afraid you’ll need to capture a lot of full LoRaWAN packets from the gateway’s traffic, and decode those to see if after 64 packets without receiving a downlink they indeed have their ADRAckReq bit set until TTN responds with a LinkADRReq MAC command in FOpts. I don’t think that the online decoder shows FCtrl.ADRACKReq, but maybe it does when it’s set. If not: it’s the 6th bit in FCtrl:
To force a downlink for debugging (not as a final solution, even if it works) you could indeed set the ACK bit for a few uplinks (but certainly not for all) when TTN should have enough details to piggyback a LinkADRReq on the confirmation downlink.
But to force a downlink for debugging it may be easier to just schedule one in the device’s Overview page in TTN Console (just a random value) when you think that it’s time TTN could be waiting for an opportunity to send the LinkADRReq. (So, you can already do that long before the device should set its ADRACKReq bit after 64 uplinks without a downlink.) Even more: your screenshot shows you’re already sending some downlinks, so it seems there’s no need for neither a confirmed uplink nor some dummy downlink.
Next, you can decode the full LoRaWAN packets of the downlinks too, to see if FOpts contains some MAC command. (See an example for AU915.) Maybe TTN simply has determined that SF10 is the best you can do…
Just in case the state that TTN knows is very much out of sync with the ABP device’s state, you may want to delete the device and register it again. Or better yet: if the downlinks are working for you, just switch to OTAA first, before trying to fix ADR. And remember, no matter what: use MCCI LMIC.
1 Like
My gateway is Dragino LPS8 my library is MCCI_LoRaWAN_LMIC_library.
Its a confirmed downlink without fields.
I have the FCtrl.ADRACKReq bit set as the online deco shows
Because 0xC0 is 1100 0000 binary, the 6th bit in FCtrl its in 1.
Even so, being the device close to the gateway it continues sending SF10 / BW125 when it should without problems use SF7 since the SNR is around 11dB.
The decode of the dowlink show this:
Both starting with 0x03, both denoting a LinkADRReq
Simulate downlinks works, but my SF its always in 10.
1 Like
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.
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?)
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.
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
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.
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
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]
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
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.
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.
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.
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
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.
Keep in mind you are allowed only 10 acks of other downlinks a day.