WLR089U0 Unable to receive downlinks in AU915

End Devices (Nodes) SAMR34
1

Need your collective help and advice.

Despite repeated attempts, our SAMR34 based end-node does not seem to be receiving downlinks at all when configured in AU915 over TTN. Join and uplinks seem to work pretty well.

The same node, however when configured in IN865 (and a corresponding antenna) works perfectly fine for both uplinks and downlinks.

I can also see on the console, a continuous attempt to downlink ‘schedule data downlink’ event after every uplink. I am assuming this is some mac command being attempted since
ttn-lw-cli end-devices downlink list
returns empty [ ]

Checking the RX configuration in the MLS (1.0.5) regional parameters configuration for AU915 on the app shows:

	RegParams.DefRx1DataRate = MAC_RX1_WINDOW_DATARATE_AU; //DR8
	RegParams.DefRx2DataRate = MAC_RX2_WINDOW_DATARATE_AU; //DR8
	RegParams.DefRx2Freq = MAC_RX2_WINDOW_FREQ_AU; //FREQ_923300KHZ
...
	RegParams.cmnParams.paramsType1.minRxDR = DR8;
	RegParams.cmnParams.paramsType1.maxRxDR = DR13;
	RegParams.cmnParams.paramsType1.RxParamWindowOffset1 = 8;
	RegParams.cmnParams.paramsType1.UpStreamCh0Freq = UPSTREAM_CH0_AU;//FREQ_915200KHZ
	RegParams.cmnParams.paramsType1.UpStreamCh64Freq = UPSTREAM_CH64_AU;//FREQ_915900KHZ
	RegParams.cmnParams.paramsType1.DownStreamCh0Freq = DOWNSTREAM_CH0_AU;//FREQ_923300KHZ
   ...
    RegParams.Rx1DrOffset = 5;

On the TTN console creating a new device under
AU915, FSB 2 (TTN)
Lorawan 1.0.4,
RP 1.0.2 Rev.B,

results in the following Advanced MAC setting values:

Desired Rx1 delay: 5 sec
Desired Rx1 data rate offset: 0
Desired Rx2 data rate index: 8
Desired Rx2 frequency: 923.3 MHz
Duty cycle: 100%

To match the regional settings on-device, I also tried changing

Desired Rx1 data rate offset: 5
Then I also tried
Desired Rx1 delay: 8 sec

These did not help either!

Has anyone else faced an issue with downlinks on AU915 with TTN and SAMR34/ WLR089U ?
Is there something obvious that I am missing here?

EDIT:

Updated the following in lorawan_mband_au.c on the end-device:

RegParams.cmnParams.paramsType1.RxParamWindowOffset1 = 5;
RegParams.Rx1DrOffset = 0;

Did a mac reset from the web console for TTN for the device after restoring defaults in advanced mac section.

Still no luck in receiving downlinks :frowning:

Plus now there seems to be a constantly repeating ‘Schedule data downlink…’ after each uplink. This seems to be some MAC command from TTN? since nothing shows up in CLI console.

image

Thanks.

2

The DevAddr is inconsequential, the id is shared with any gateway log that hears the device, so please don’t redact stuff - the only thing you should share on a device is the AppKey.

Can you tell us what the RSSI & SNR of the uplink is please. Preferably as text, not a screen shot.

3 
      "channel_rssi": -99,
      "snr": 11.5,
4

The DevAddr is inconsequential, the id is shared with any gateway log that hears the device, so please don’t redact stuff - the only thing you should share on a device is the AppKey.

Sorry about that. Noted.

5

Opps, sorry, major typo there, the only thing you should NOT share is the AppKey - the DevEUI & App/JoinEUI are sent plain text at join and the DevAddr is shared between a number of devices - it’s used to speed up figuring out who the uplink is for so is internal use only.

OK, so device reasonably separated from the gateway and they are not shouting in each others ears.

I know what a PitA it is to downgrade MLS but can you try 1.0.4?

If you can bear with me for a day or so, I can try my AU TTIG config with a WLR089 here (in the UK, so shhhh, don’t tell the authorities)

6

the only thing you should NOT share is the AppKey
:slight_smile:

I know what a PitA it is to downgrade MLS but can you try 1.0.4?
Will try that.

If you can bear with me for a day or so, I can try my AU TTIG config with a WLR089 here (in the UK, so shhhh, don’t tell the authorities)
That would be awesome! :smiley: :zipper_mouth_face:

Thanks!

7

Tried MLS1_0_4, used the provided example LoraWAN Mote Application

On TTN set AU915 FSB 2 (TTN)
LoraWAN version 1.0.2
Regional Parameters: RP001 1.0.2 version B

Same story, downlinks not getting processed:

image

Also tried changing RX1 data rate offset to 5 on TTN web console. Still no downlinks on AU915!

image

:frowning:

The same codebase on a clone device on IN865 works perfectly fine

image

image

There are other sensors (eg: from Dragino and Milesight) that seem to be working perfectly fine on TTN AU915 which indicates there’s something wrong with the MLS regional param/ config for downlinks. Trying to figure out what exactly. My suspicion is rx1 delay or offset settings.

8

MLS 1.0.4 is LoRaWAN version 1.0.3 which does have differences that matter from 2.

Did you mean Rx1 delay - as changing the DR offset won’t be going in the right direction.

This is the most likely cause - I had to fix it for Arduino & ST, no reason not to think that Microchip will have got it right if others haven’t.

9

Ok. Will change on TTN to LoRaWAN version 1.0.3

MLS 1.0.4 has these interesting settings in regional parameters for AU915:

RegParams.cmnParams.paramsType1.RxParamWindowOffset1 = 8;
RegParams.Rx1DrOffset = 5;

I was assuming window offset was the max time window between end of Tx and opening of Rx1 window (= Rx1 delay) and Rx1DrOffset was some kind of an offset applied to the Tx data rate?

image

What changes would you suggest based on your earlier experience?

10

Downlinks are working now with LoRaWAN version 1.0.3 :slight_smile:

Settings changed in Advanced MAC Settings on TTN console:

Desired Rx Delay: 5s
Desired Rx1 data rate offset: 5

But it looks like there is still some mac downlink in a perpetual scheduling queue? (underlined in red, application message underlined in green)

image

11

Yeah, that’s a thing that I haven’t been able to isolate yet and I hate filing GitHub issues without any evidence.

Last week when that happened to me I deleted the device and put it back in again. I think some of the settings aren’t coping well with console edits but I haven’t tried the CLI tool to see if I can right size them. The next device I create I’ll allocate time to investigate further.

12

Thanks for all your help @descartes
Please do update if you get a solution to the repeating schedule issue.