ADR always DR_0 on LoraMac AU915 based Nodes

Hi!

I have an issue that’s not related to Loraserver per se but maybe someone can give me a hand to spot the issue on my node code.

I have an AcSiP device (a integrated STM32L073 + SX1276 + GPS) where I have a basic LoraMac implementation (a bit tweaked). The thing is that it always sends messages on DR0, no matter what RSSI and SNR values I get. (it’s in the same room as the gateway).
I have multiple devices running with ADR working (mostly on RN2903).

Here’s the log for this device:

time="2019-08-08T12:00:01Z" level=info msg="packet(s) collected" dev_eui=9c65f9fffeac5500 gw_count=1 gw_ids=b827ebfffe01adba mtype=JoinRequest
time="2019-08-08T12:00:01Z" level=info msg="device-queue flushed" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:01Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:01Z" level=info msg="device-activation created" dev_eui=9c65f9fffeac5500 id=2883
time="2019-08-08T12:00:01Z" level=info msg="device updated" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:01Z" level=info msg="downlink-frames saved" dev_eui=9c65f9fffeac5500 token=23148
time="2019-08-08T12:00:24Z" level=info msg="rx info sent to network-controller" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:24Z" level=info msg="device gateway rx-info meta-data saved" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:24Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:24Z" level=info msg="requesting device-status" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:24Z" level=info msg="pending mac-command block set" cid=LinkADRReq commands=2 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:24Z" level=info msg="pending mac-command block set" cid=DevStatusReq commands=1 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:24Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:00:24Z" level=info msg="downlink-frames saved" dev_eui=9c65f9fffeac5500 token=63109
time="2019-08-08T12:01:22Z" level=info msg="rx info sent to network-controller" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:01:22Z" level=info msg="device gateway rx-info meta-data saved" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:01:22Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:01:22Z" level=info msg="pending mac-command block set" cid=LinkADRReq commands=2 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:01:22Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:01:22Z" level=info msg="downlink-frames saved" dev_eui=9c65f9fffeac5500 token=26418
time="2019-08-08T12:02:18Z" level=info msg="rx info sent to network-controller" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:02:18Z" level=info msg="device gateway rx-info meta-data saved" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:02:18Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:02:18Z" level=info msg="pending mac-command block set" cid=LinkADRReq commands=2 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:02:18Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:02:18Z" level=info msg="downlink-frames saved" dev_eui=9c65f9fffeac5500 token=21091
time="2019-08-08T12:03:04Z" level=info msg="rx info sent to network-controller" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:04Z" level=info msg="device gateway rx-info meta-data saved" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:04Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:04Z" level=info msg="adr request added to mac-command queue" dev_eui=9c65f9fffeac5500 dr=0 nb_trans=1 req_dr=0 req_nb_trans=1 req_tx_power_idx=6 tx_power=0
time="2019-08-08T12:03:04Z" level=info msg="pending mac-command block set" cid=LinkADRReq commands=2 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:04Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:04Z" level=info msg="downlink-frames saved" dev_eui=9c65f9fffeac5500 token=38401
time="2019-08-08T12:03:10Z" level=info msg="rx info sent to network-controller" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:10Z" level=info msg="pending mac-command deleted" cid=LinkADRReq dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:10Z" level=info msg="link_adr request acknowledged" dev_eui=9c65f9fffeac5500 dr=0 enabled_channels="[0 1 2 3 4 5 6 7]" nb_trans=1 tx_power_idx=6
time="2019-08-08T12:03:10Z" level=info msg="device gateway rx-info meta-data saved" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:10Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:10Z" level=info msg="adr request added to mac-command queue" dev_eui=9c65f9fffeac5500 dr=0 nb_trans=1 req_dr=0 req_nb_trans=1 req_tx_power_idx=10 tx_power=6
time="2019-08-08T12:03:10Z" level=info msg="pending mac-command block set" cid=LinkADRReq commands=1 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:10Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:10Z" level=info msg="downlink-frames saved" dev_eui=9c65f9fffeac5500 token=28876
time="2019-08-08T12:03:40Z" level=info msg="rx info sent to network-controller" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:40Z" level=info msg="pending mac-command deleted" cid=LinkADRReq dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:40Z" level=info msg="link_adr request acknowledged" dev_eui=9c65f9fffeac5500 dr=0 enabled_channels="[0 1 2 3 4 5 6 7]" nb_trans=1 tx_power_idx=10
time="2019-08-08T12:03:40Z" level=info msg="device gateway rx-info meta-data saved" dev_eui=9c65f9fffeac5500
time="2019-08-08T12:03:40Z" level=info msg="device-session saved" dev_addr=01b96734 dev_eui=9c65f9fffeac5500
time="2019-08-08T12:04:10Z" level=info msg="rx info sent to network-controller" dev_eui=9c65f9fffeac5500

Is there something I’m missing?
You can see the NS actually sending the node the ADRreq with dr_0.

Thanks in advance!

What sort of SNR and RSSI are you actually getting?

Do you know if the device is actually receiving the downlink’d MAC commands? One idea that comes to mind is that it might be so close it is actually being weakly received on the wrong channel via bleedover, the wrong frequency packets are being put into the queue a hair before the right frequency ones and capturing the fcount so the right ones get discarded. That would both cause low ADR settings, and cause the node to never hear anything as it would be receiving on the wrong channel.

The other thought is you could have something wrong with the node, for example an antenna not actually connected. Or an 868 vs 915 board being used on the wrong frequency band: it will “work” as the silicon is the same and uses the high band RF pins in either case, but with the RF networks badly mistuned it would be weak.

Are you able to get RSSI of the gateway downlinks as heard by the node and output that to a serial debug log? It is a capability of the radio chip, but reading it may not be implemented in your firmware.

From the node-side (downlink frames avg):
RSSI: -87 SNR: 25

From the NS side (uplink frames):
RSSI: -60 SNR: 10
Freq: 915.6, 915.4 (I’m using subband 1 so those freq are ok imo)

The node is sending both CNF and UNCNF uplinks and they all arrive to the NS. The LinkADR downlinks are also being received well.

Any ideas? The signal is not the best… but the RF traces are as vendor requested. I’m using a small antenna with a UFL to SMA cable

PD: Thanks for your response!

Which region’s parameters are you configured for? And are both ends set for the same region?

If you have a mixup between US915 (which is really 902) implementation on one end an something like AU915 on the other that might explain oddities - things like definitions of data rate are different between those.

Also your server is commanding the node to use channels 0-7 which would be a mismatch for an intention to use any subband but the first, it is unclear if you were counting from 0 or 1 when you said subband 1.

I’m using AU915 on both sides. The gateways are listening on channels 0-7 and frequencies on those channles are (according to Regional Parameters 1.0.2 which I checked in gateway’s config) from 915.2 (chan0) to 916.6 (chan7). The Gateway Profile has those same channels enabled and the LinkADRReq shows those channels in the log.

We have several RN2903 nodes with AU firmware working with ADR. The issue comes from this node as the other ones have closed stack implementation.

Here’s a fragment of the init code:

DeviceState = DEVICE_STATE_INIT;
	LoRaMacPrimitives.MacMcpsConfirm = McpsConfirm;
	LoRaMacPrimitives.MacMcpsIndication = McpsIndication;
	LoRaMacPrimitives.MacMlmeConfirm = MlmeConfirm;
	LoRaMacCallbacks.GetBatteryLevel = BoardGetBatteryLevel;
	LoRaMacStatus_t status = LoRaMacInitialization(&LoRaMacPrimitives, &LoRaMacCallbacks, LORAMAC_REGION_AU915);
	if (status == LORAMAC_STATUS_OK)
	{
		printf( "LORA - Iniciada la capa LoRa\r\n" );
		mibReq.Type = MIB_PUBLIC_NETWORK;
		mibReq.Param.EnablePublicNetwork = LORAWAN_PUBLIC_NETWORK;
		LoRaMacMibSetRequestConfirm( &mibReq );
		mibReq.Type = MIB_ADR;
		mibReq.Param.AdrEnable = LORAWAN_ADR_ON;
		LoRaMacMibSetRequestConfirm( &mibReq );
		DeviceState = DEVICE_STATE_JOIN;
		return 0;
	}

I’m actually lacking the compliance test stuff, I didn’t add that code. Maybe that has something to do with ADR?
Everything else is working (cnf and uncnf uplinks, downlins)

Could you maybe do a side by side comparison of the “conversation” each has with the server? ADR stuff tends to be outside the encryption, so you could just look at the appropriate bits of the raw uplink and downlink packets in both cases and see if you can figure out the difference in behavior.

I’ve made some tests with a colleague that has a Kerlink gateway with OrbiWise NS service.
ADR works flawlessly and the device reaches DR_4.

Maybe our RAK gateway has some missconfiguration in channel settings… I’m gonna keep testing.

Ok, I was missing the LoRa_STD channel settings, so I added an extra channel to te Gateway profile like this:

I’m confused… because as soon as I changed this setting all my nodes started to work better (donwlink frames where often not heard by the nodes)

Is this channel configuration good for subbad 1 in AU frequencies?

Frequencies according to auto-generated local-config.json are these:

Channel Freq Cfg IF
FSK disabled
STD 915900000 r0 300000 SF8 BW500
Radio 0 915600000
TX min 915000000
TX max 928000000
Radio 1 916600000
Chan 0 915200000 r0 -400000
Chan 1 915400000 r0 -200000
Chan 2 915600000 r0 0
Chan 3 915800000 r0 200000
Chan 4 916000000 r0 400000
Chan 5 916200000 r1 -400000
Chan 6 916400000 r1 -200000
Chan 7 916600000 r1 0

@ezequielfalcon what are your min / max DR settings in your service-profile?

2 Likes

I’m so sorry… It was in 0

Thanks @brocaar and @cstratton