I’m testing the ADR sequences. On EU868 it works: now and then the device gets LinkAdrReq mac commands, which is good. However for AU915 and US915 gateways and devices, I never see any ADR coming by. According to TTN Adaptive Data Rate, I would expect after about 20 uplinks to get a LinkAdrReq, which never happens (I tested up to 72 uplink packets). Can it be that ADR is only supported by TTN for EU868? The gateway & device under test are on my desk:
Furthermore I think the network server should send LinkAdrReq’s until acknowledged immediately after a successful join on US915 and AU915 channel plans. Often gateways only support 8 of the 64 frequencies, and the device should know the channel masks it should use as soon as possible. Otherwise a device may use frequencies the gateway doesn’t listen too.
You are correct. ADR is not supported in the US and the current implementation makes no attempt to inform devices about active channels. I have a pull request that I am working on to enable it (with.a proper channel mask), but I don’t currently have a gateway and it’s going to be my first contribution.
Thanks for verifying. Could you then please explain why the default SF10BW125 data rate and radio power setting 18 never changes on the device which has ADR turned ON. I am using a Microchip RN2903 module v 0.9.8.
Here is a snapshot of the traffic view on the Gateway. There are 2 devices reporting with ADR turned ON, one with an uplink count of 5675 and the other with uplink count of 85 (both beyond 20 TX counts), and they’re both placed a couple of feet away from the gateway.
But NO ADR so far. Diagnostics on the radio board confirm that the ADR bit is set in the data packet, but LinkADRReq command never happens.
Does ADR only happen if I schedule a downlink packet and setup the device to RX downlink packets ? Does it not occur with the empty payload downlink on port 0 that happens following a TX ?
Here is a snapshot of one of the decoded packets proving that ADR is ON on the uplink:
@BoRRoZ. The node is succeeding to join every time and is hence able to succesfully TX its Data packet following a join. Its the nature of the radio to be powered down completely by a host processor between every TX interval and be powered up and transmit one packet. In my travails POWER OFF -> POWER ON -> DATA TX has been problematic unless it’s modified to do POWER OFF -> POWER ON -> OTAA JOIN -> DATA TX. It’s done to perform intense battery power saving on a product that requires 10 years of battery life. Would this approach impede ADR from working correctly on the TTN ?
@BoRRoZ Wow thanks for your suggestion. An OTAA rejoin definitely seems to interrupt/suspend ADR on TTN. I skipped powering ON/OFF the radio and I see the SF throttled down to 8 in about 15 transmissions. The LoraWAN 1.1 spec does not seem to specify that ADR should be suspended/resumed/restarted if a device tries to rejoin the network. So is this behaviour TTN specific ? In my case, I’m trying to help out the Network Server maintain ADR by keeping my Uplink counter increment even if a OTAA rejoin happened. Is there anything else I can do on the application side to keep completely powering down my radio between transmissions and still make use of the TTN ADR ?
You are aware this will not work in the long term? OTAA join requires a unique identifier which is random in LoRaWAN 1.02 and these random values can not be reused (back-end stores them). So you will be running out of possible values at a certain time and you will have collisions far sooner. (Collision means join will fail)
For OTAA you should join and keep the keys etc alive. Not join every time you want to send data.
If you are able to ‘store’ the keys and keep track of the up and down counters you could use OTAA join the first time and after the radio has been reset restore the keys and counters and perform an ABP join to resume the session. Or use ABP from the start and store just the counters to make sure no duplicate packets are sent.
BTW, OTAA joining everytime is a waste of energy, for a 10 year battery node really bad…
An OTAA join creates a new session and the MAC state from the previous session is discarded (as per specification). This means frame counters reset to 0 and all state related to MAC (including ADR) is reset to the defaults.
Changing the frame counter after a join is not compliant with the specification.
Sessions are meant to be used for way longer times (thousands of messages instead of 1, months instead of seconds), so I recommend you to change a few things in your device.
@htdvisser@kersing. Thank you for directing me on the correct path. In page 52 of the the Lora Spec 1.1, line 1477, it states that “It is RECOMMENDED that session state be maintained across power cycling of an end-devicxe. Failure to do so for OTAA devices means the activation procedure will need to be executed on each power cycling of a device”. Seems to describe my predicament verbatim. I don’t see any way in Microchip RN2903 to save session context comprehensively. “mac save” command in microchip does save some subset of the network and applicaiton session states, but not all. I have verified this by joining OTAA, followed by a successful TX, followed by a mac save and then power cycling the device, and performing a mac status check, the status comes back as not joined. Is this an overlook on the microchip implementation of the stack. If so, this seems like a major one. If not, how am I supposed to make the radio remember session states ?
After power cycle you need to perform an ABP join. Keys etc are set so just issuing the join command is sufficient. Keep in mind the counters change whenever you send data so you need to keep them safe. Saving in the device might wear out the eeprom used, so you might want to look for another way to store (just) the counters.
@kersing Thank you for that suggestion. That is indeed correct, that after power cycle, an ABP join should be performed to resume operation. But that’s just half the story. In case of the RN2903 (Not sure if this applies to the RN2483), a mac save after an OTAA join DOES NOT seem to save the appskey, nwkskey or the devaddr, for future use by the ABP rejoin UNLESS, you perform the following on the first initiation of the radio :
mac set appskey 00000000000000000000000000000000
mac set nwkskey 00000000000000000000000000000000
mac set devaddr 00000000
mac save
If these commands are not given atleast once in the lifetime of the radio, the following sequence:
OTAA join => Mac Save => Power Cycle => ABP Join will always fail with the condition keys_not_init.
It seems like the eeprom register spaces for appskey/nwkskey/devaddr needs to cleared/changed atleast once for the mac save command to write to them and save the values following the otaa join.
I can verify this behaviour with brad new RN2903 modules where NOT writing to the devaddr/nwkskey/appskey does not allow for ABP joins. Microchip did not make this clear in their RN2903 documentation at all. The documentation leads us to believe that “mac save” ALWAYS saves these 3 values.
Oh well, I hope this post is worthwhile to others trying to turn OFF their radios in between transmissions.
Is there a way to verify that the channel mask is being sent down properly?
In the MQTT Data API I am able to see downlinks on this topic: {application_id}/devices/{dev_eui}/events/down/sent
The “payload” attribute appears to be the full LoRaWAN frame, but I do not see any channel masks. My assumption here is that the /down/sent topic is only giving me events that include an application downlink payload, not downlinks that are just ACKs and/or MAC commands
.
