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.
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 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…
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
