Adr can only increase your sf, it’s on node shift back sf if it does’t receive an adr in 128 uplink messages, if it happens it could means the node is not reachable by any gateway, decrease sf help the node to reach more far gateaway . Sometimes ttn forgot to send the adr, make the messages with ack help a lot, don’t abuse of ack system it waste the gateway channels.
Edit: i am a bit confused by the anser with the icrease and decrease of SF… should not ADR decrease the SF (from SF9 to SF8 for example - and increase DR) and the node increase the SF (from SF8 to SF9 - and decrease DR)?
Thanks for your feedback anyway.
one more question: Is it defined by LoraWAN Specifications, that a LoRa-Server (the things network or others) can’t decrease DR? And is the 128 Uplinks also a LoRaWAN Specification or can nodes handle it the way they want/configured?
Last: Do you know where the “shift back” algorithem is documented in LoRaWAN specifications?
If no reply is received within the next ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the end-device MUST try to regain connectivity by first stepping up the transmit power to default power if possible then switching to the next lower data rate that provides a longer radio range. The end-device MUST further lower its data rate step by step every time ADR_ACK_DELAY is reached. Once the device has reached the lowest data rate, it MUST re-enable all default uplink frequency channels.
If your nodes are stationary enable adr, beware if you use the semtech lorawan stack there are some minor bugs that blocks the node to move from sf12.
hi
Today I tried using sf12 for uplink and based on the log on my gateway side after an uplink there was a downlink on sf9 and the reason was optimizing
means nodes should switch to higher data rate but this did not happen and regarding all downlinks my node did not change the sf from 12 to lower sf
what would be the problem?
I have enabaled adr
thank you for the reply,
I am using v2 and I have tried for 12 uplinks which I did not see any changes in sf from 12 to lower ones,
after how many uplinks i can see the adr effect?
I have another problem when I use sf7 after 12 uplinks i got adr ack downlink for every uplink And as I have read from this forum this shows the problem but I could not find any answer regarding sovling this problem for the old lmic library by matt
Can you show the log info that shows these downlinks - preferably from the device, the gateway log and the gateway console - assuming you mean ADR Req (the downlink) and the devices lack of ADR Ack in its next uplink?
Then brighter minds than mine can look at the details for you.
about the adr effect , I have just tried for less than 1 packets and as you said I must try for more uplinks to see the result
here is my gateway log when I tried SF12:
LoRa Alliance requires network providers to restrict SF11 & 12 so you are likely to get an immediate response if your link margin is ridiculously hight.
At some point you will be told that your uplinks are far far to frequent - put a push button on your device so you can send an uplink on demand rather than have it hammering out one every minute.
We can guess at some of the detail but if you want to debug this, you’ll need to capture the actual payloads / headers etc
thank you I will put a push button,
here is downlink payload from gateway side when i use SF7 and after 12 packets I receive this downlink after every uplink :
Look at the same sort of data on the application console for the uplink - it will show a list of all the gateways.
But now we see the rssi & snr, we can see that they are most likely in the same room, which isn’t good for the gateway BECAUSE IT IS EXACTLY LIKE SHOUTING IN THE EAR OF SOMEONE WITH VERY SENSITIVE HEARING.
And because the device may not be reducing power, you may have found a way to break the ADR algorithm.
Try something more akin to real life - like about 200m separation.
Or if you aren’t actually investigating ADR, just put 10m & a wall between the device & gateway.