At the Port of Antwerp in Belgium we are currently conducting tests witch some ‘of-the-shelf’ LoRa sensors from Adeunis, Atim and Nemeus. All of them have the same issue: ADR bit is on but the devices keep sending data at SF12/125. The manufacturers all tell me that the TTN ADR implementation is not correct and are very reluctant to modify the sensor firmware to implement workarounds. Has anyone an idea when this issue will be fixed?
(So getting an LinkADRReq downlink command without requiring an ADRACKReq and not only piggybacking on acks or application downlinks)
Hi Gzazo, hi @all
I am new to thethings network - and i try to understand ADR.
is it not the default behavior of lorawan that ADR only increases the datarate?
how does this work in the things network. Can ADR increase and decrease the datarate of a node or only increase?
regards, sil
Hi,
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.
Regards
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?
many thanks and regards, Sil
from LraWan v 1.1
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
SF9 is the standard downlink for TTN for the Rx2 slot.
It will take a few more uplinks for ADR to cut in, depending on which stack you are on.
Please note that you replied to a 2 year old post!
1 Like
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
thank you so much
what about my second question, is it normal to receive adr ack after every uplink?
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.
these are the logs from gateway and application part:
Doesn’t show any of the payload details to determine what’s being sent & why
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:
payload from application part in downlink is empty and it is in port 0
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 :
and from application side:
Can you click on some of the SF 7 uplinks and let us know what the rssi/snr values are.
Also check how many GW’s are seeing your uplink messages
sorry for the late answer
these are uplink datas ,
honestly I do not know where i have to check the number of gateways which are seeing uplink messages
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.
1 Like