Hi, I am trying to use ADR, but seems that it is not working.
I wait 20 uplink and printout the selected SF and BW in the firmware. They are always the same.
This is my configuration:
So:
Is my hardware ok to implement ADR?
Is ADR enabled by default in TTN server?
Can I visualize ADR downlink message in the device console?
Try sending a downlink after the 20 uplink messages, this worked for me with a Tuino1 board.
As ADR needs downlinks, and downlinks are very expensive, it’s highly optimized:
ADRACKReq bit set, which the node should request when it has sent 64 messages without getting any response from the server.So, when no changes are needed, one might not get any ADR soon.
No, the node decides: https://www.thethingsnetwork.org/wiki/LoRaWAN/ADR
To see if your node’s packets even request ADR, paste a full packet into an online LoRaWAN packet decoder, and see if FCtrl.ADR is set. (Of course, that needs a full LoRaWAN packet, not just the application payload.)
And yes, ADR downlinks are shown in, at least, the gateway traffic page as empty downlinks (which can be expanded to show their trace details), below showing a size of 17 and 22 bytes:
Above, the node was erroneously not expecting the downlink in RX2 to occur at SF9 (11:55:38, 17 bytes) and apparently ignored it, and kept using SF12 (11:57:42). So, in the next try, TTN repeated the ADR in RX2 at SF12, and also told the node to use SF9 for RX2 in the future (11:57:43, 22 bytes). After that, the node changed from SF12 to using SF8 (12:04:01) and from then on would be using SF9 for RX2.
If your node’s traffic is received by multiple gateways, TTN will select the gateway for the downlink, so you might not see it in the Traffic of your own gateway.
Hi,
@arjanvanb, i’ve just read your explaination (and check into the server code you mention) about how ADR is managed.
I’m testing a STM Nucleo node, and I’m not seeing what I’ve expected.
I’m using the semtech demo program which is nice to test different lorawan parameter. So, here is what I can notice :
Default rate is set to DR0/SF12
Any ideas ?
Thanks for help
Anthony.
It seems ADR is only implemented for EU868. https://github.com/TheThingsNetwork/ttn/issues/619
ADR has been implemented for EU, US and AU. But then, as you’re seeing ADR in the first experiment, I guess you’re using that?
Yes, I’m using the EU 868 Band, but it seems ADR command are only pushed with ACK frame, not into other downlinks. I did another test, this is to send downlink to the node from a red-node network (in my previous test it was sent from the ttn console) … but no changes … the downlink is perfectly routed to the device, but ADR are never packed into thoses downlinks.
Anthony.
@arjanvanb
I’ve just found this issue : https://github.com/TheThingsNetwork/ttn/issues/655
It explains exactly what Im’ seeing (except for the downlink not sending LinkADRReq in my case).
Anthony.
So first off just to say I understand ADR basics, and have read and read forum posts on the subject.
We have a few badger boards working fine on OTAA and with ADR - they start at default SF7 and ADR works as expected (say if gateway is turned off for a few hours, the node will end up on SF12 say, and then ADR will then bring it back to SF7 once the gateway is working again) and we also see downlinks at set intervals too - have confirmed payload as having ADR flag set too. All good.
Now looking at some new RAK boards and I just can seem to work out what the issue is, they connect fine via OTAA and then jump to SF12, ok I can live with that because ADR should then bring them also down to SF7 in time but I am just not seeing any attempt by the gateway to send any downlinks to these node - I have ran the decoder on the uplinks and the ADR flag is set true.
So on the one hand one node is getting downlinks from its gateway (and adr fine), and yet another node the backend is simply not sending downlnks at all? why would this be
(posted this on this thread as it seems related)
Hi @jezd, in order to trigger an ADR downlink from the TTN core, the device needs to set the FCtrl.ADRACKReq bit = 1. The device should set this bit once every 64 uplink frames.
If you are looking at the TTN console gateway traffic and taking the physical payload and using lora-packet-decode then you can see the FCtrl field. The lora-packet-decode software only displays 2 of the bits; FCtrl.ACK and FCtrl.ADR.
You need to hand-decode the rest of FCtrl per the LoRaWAN specification. Examples are:
FCtrl, hex 80 = binary 0100 0000, FCtrl.ADRACKReq = 0 and FCtrl.ADR = 1
FCtrl, hex C0 = binary 1100 0000, FCtrl.ADRACKReq = 1 and FCtrl.ADR = 1
I suggest that you watch your - working correctly - badger boards as they go through the process. Leave the gateway off, let the badger board go to SF12. Then power up the gateway and use the TTN console to start collecting physical payloads and watch for the FCtrl.ADRACKReq bit to be set to 1 and an ADR downlink from the core. Then do the same with the RAK boards.
This behaviour was changed from LoRaWAN specification 1.0 to 1.0.1 as there was an error in 1.0.
Same problem here, Adr works only with confirmed messages
After the first message with sf12, the server response with a change configuration message.
In a previous test, my node sent 64 uplink messages unconfirmed and ttn never schedule a message for adr.
Adr was enabled with both test, I can post a decoded message for both.
After more investigation, here is what comes up. The problem for unconfirmed uplink it seems to be FCtrl.ADRACKReq.
From RegionEU868AdrNext
if( adrNext->AdrEnabled == true )
{
if( datarate == EU868_TX_MIN_DATARATE )
{
*adrAckCounter = 0;
adrAckReq = false;
}
else
{
if( adrNext->AdrAckCounter >= EU868_ADR_ACK_LIMIT )
{
adrAckReq = true;
txPower = EU868_MAX_TX_POWER;
}
else
{
adrAckReq = false;
}
if( adrNext->AdrAckCounter >= ( EU868_ADR_ACK_LIMIT + EU868_ADR_ACK_DELAY ) )
{
if( ( adrNext->AdrAckCounter % EU868_ADR_ACK_DELAY ) == 1 )
{
// Decrease the datarate
getPhy.Attribute = PHY_NEXT_LOWER_TX_DR;
getPhy.Datarate = datarate;
getPhy.UplinkDwellTime = adrNext->UplinkDwellTime;
phyParam = RegionEU868GetPhyParam( &getPhy );
datarate = phyParam.Value;
if( datarate == EU868_TX_MIN_DATARATE )
{
// We must set adrAckReq to false as soon as we reach the lowest datarate
adrAckReq = false;
if( adrNext->UpdateChanMask == true )
{
// Re-enable default channels
ChannelsMask[0] |= LC( 1 ) + LC( 2 ) + LC( 3 );
}
}
}
}
}
}
This is code it seems to work only in one direction, decrease data rate and make an adr ack request every EU868_ADR_ACK_LIMIT as lorawan specification says. But because my default data rate at start up is already the min data rate possible for eu868, this mean that the end node will never get a chance to obtain a better datarate.
What I miss?
Thanks
After reading lorawan specification about ADRACKReq, the above device code seems to be correct. The only thing that the end node can do is to switch to a lower datarate after EU868_ADR_ACK_DELAY if previous request fails and stop when reach the lowest datarate.
It’s up on the server make an adr mac request based on its historical date. This mean that 64 unconfirmed messages are not enough for ttn to schedule a new downlink.
I’m gonna to check with 100.
Hi @gzazo, I think that the polite term here is that this is an “inter-operability issue”.
TTN has chosen to implement ADR in a way that I think is strange; the TTN core appears to only send an ADR command to a device in a downlink in response to the ADRACKReq bit being set in an uplink.
I can find nothing in the LoRaWAN specification version1.0.2 that says when the core should send ADR commands to devices.
I think that the TTN core should be continually monitoring device uplink SFs and RSSIs and whenever a device has its FCtrl.ADR bit set and the SF/RSSI combination looks wrong then it should send an ADR command in a downlink.
I think that the current TTN ADR setup is probably wasting a lot of battery power and airtime.
I default all my devices to SF11 and ADR works. There are some devices that, if defaulted to SF12, will just sit there forever when connected to TTN.
Yes, interestingly last night my gateway dropped out for 6 hours, my working badger node was on SF7 and gradually moved to SF12 as it looked for any gateway, once my gateway was rebooted the node uplinked followed by immediate downlink switching it back to SF7 - all works perfectly.
Re your idea, I’ve not tested the idea that devices that default to SF12 never drop down because I need to look at RAK811 tracker code and what they have done re defaulting to SF12, these boards connect (otaa) at SF7 then switch to SF12 for all downlinks and never get any uplinks even though FCtrl.ADR is set on.
I think you exactly understand what I mean. I understood that a good workaround was to set sf11 as default to force ADRACKReq bit and “order” a new mac adr command from ttn, but for some reasons my devices should they start with SF12.
What you think about to send sometimes a confirmed message? The result seems to be the same.
Thanks
Hi @jezd
The main problem it seems to be, from lorawan specification
The ADRACKReq shall not be set if the device uses its default data rate because in that case no action can be taken to improve the link range
The system fails if your default datarate is SF12, due this piece of code
if( datarate == EU868_TX_MIN_DATARATE )
{
*adrAckCounter = 0;
adrAckReq = false;
}
In this case the ADRACKReq bit will be never set, and because ttn never schedule a new downlink, your devices sit there forever.
Hi @gzazo, I think the quote from the LoRaWAN specification is from version 1.0 and was an error and was corrected in version 1.0.1 and remains corrected in version 1.0.2. Please check version 1.0.2.
I’m waiting for the last specifications.
However I don’t think it’s an error or at least it was an error. It’s on the end node shift back the datarate if the gateways are unreachable and it’s on the server send a mac adr request to set a better datarate based on receive data (rssi and snr).
No?
The ADRACKReq shall not be set if the device uses its lowest available data rate because in that case no action can be taken to improve the link range.
(Same for version 1.1.)
Hello,
I’m facing the same issue.
For unkown reason, my TTN gateway dropped out for 2 hours yesterday.
My nodes jumped from SF7 to SF12 and never go back ti SF7 although ADR is ON.
I’m using a LSN50 from Dragino. Firmware V1.1.
I’m not able to physically access to these nodes.
May I send a downlink message through the TTN console to make my nodes go back to a lower SF ?
Thank you