Home › Forums › Conduit: AEP Model › Issue with AU915 ADR
Tagged: AU915 Datarate ADR Dwell
Andrew Larkin.
Andrew LarkinI have been tracking down an issue with nodes rejecting a channel mask sent from the gateway as a part of ADR.
The issue is that the channel mask from the gateway specifies a minimum datarate DR_0 while the node wants a minimum DR_2.
While I believe that the cause is an error in the reference RegionAU915 that is setting uplink dwell time to 1 (which triggers the DR_2 minimum), I was hoping that it might be possible to specify/override the minimum datarate being sent from the Conduit.
What does the “Min Datarate” setting in the LoRaWAN Network Settings page do if not this?
Jason ReissWhat version of firmware is installed on the gateway?
The Min/Max datarate settings on the Conduit control the datarate to be sent to an end-device in a LinkADRReq MAC command. Setting the Min Datarate to 2 should restrict the network server from sending commands to use DR0 or DR1.
ADR does not control the minimum datarate a device will reach when ACK or ADRACKReq are note received. Although this does sound like an interesting addition to the protocol that may warrant a request to the LoRa-Alliance.
The end-device is responsible for lowering the datarate when connectivity to the network is lost, i.e. when it moves out of range of the current datarate.
I am surprised to see TxParamSetupReq implemented in the reference code as it is specifically called to not be implemented in the specification.
LoRaWAN 1.0.2 and 1.1rA Regional Parameters Page 29
2.5.3 AU915-928 Data Rate and End-point Output Power encoding
The TxParamSetupReq MAC command is not implemented by AU915-928 devices.
Andrew LarkinFirmware is 1.4.17
What LoRaWAN version is it implementing in the inbuilt Network Server (2.0.19)?
Looks like it has all changed for 1.1rB and 1.03rA of the regional parameters.
The 1.1rB and 1.03rA for AU915 both specify that the node device should be operating with UplinkDwellTime = 1 until reception of TxParamSetupReq.
I note that there seems to be a major new version due out in a couple of days (20th August 2018): http://www.multitech.net/developer/downloads/#lorawan-downloads
Jason ReissLoRaWAN 1.0.2rB
Jason ReissAn application can send the txparamsetupreq command using port 0.
Andrew LarkinSo, what I have worked out is this.
The node is running LoRaWAN 1.0.3 code base (latest STM32Cube extension download). This implements the 1.0.3rA regional params for AU915 that specifies UplinkDwellTime = 1 and DR2.
When ADR is enabled, the Conduit sends a LinkADRReq with the correct channel mask for the gateway but specifies DR0 for the 125kHz channels.
The Node is rejecting this because it wants minimum DR2 when UplinkDwellTime=1. This leaves the channel mask unchanged with subsequent transmissions hopping all over the band.
It seems to me that the Node should be using the higher data rate. I did a quick hack test to this effect and it seems to work.
Very much still stumbling around in ignorance on this…
Jason ReissEdit: The current 2.0.19 network server implements LoRaWAN spec 1.0.2 with DR0-DR6.
If ADR is disabled the stack will accept the channel mask regardless of datarate.
The upcoming release will use 1.0.2rB.
Jason Reiss.
Jason ReissAt what datarate is the first uplink following the Join Request/Accept message being sent?
The ADR commands to set the Channel Mask, sent in the first downlink, should be instructing the device to keep the current datarate, it should only send a command to set to DR0 if the uplink used DR0.
Andrew LarkinThe join request is sent with DR2
As the LinkADRReq is coming back with DR0, it is being ignored. Subsequent transmissions are DR2 and spread across the entire 72 channels as the channel mask was rejected.
Andrew LarkinI don’t see this as a gateway/network server issue. I have raised an issue in the LoRaMAC reference stack as there is a straight forward solution in the node code that I believe correctly solves the matter.