AS923 Region Incorrect Downlink Implementation

[BenAtPip]

Hi All,

I'm currently working on an application using LRWAN from the ST-Cube package which I understand uses this project for the Radio stack. I understand that this project deviates from the releases ST makes, but the activity on these posts and some of fixes I have seen have been applicable to the version we are implementing (a version of 1.2.0 which is being patched)

My current issue is that while I can successfully send uplinks with the device I only sporadically receive downlinks from the backend. This is observed in Class A device type, with both ABP and OTAA, and with either ADR set to 0 or 1.

The device typically receives it's first downlink from the LoRaWAN network, and responds to the MAC commands from the downlink. Following the first downlink however the device services downlinks without an apparent pattern. My observation is that either there is a receive window issue which prevents the device from receiving subsequent frames. My question is if anyone else has been experiencing these issues with either the ST code releases or this project, in either AS923 or other regions.

I can provide further details on the device configuration and fixes implemented based on issues raised on this project as necessary.

[jamesl-dm]

There does seem to be a bug in the window timing code - but 9 times out of 10 the problem is that the gateway just isn't sending the downlinks due to network latency. For instance, if you're using TTN, the TTN console will show the downlink as sent, but the gateway debug log will show it as discarded due to lag.

[BenAtPip]

Hi James,

Thanks for quickly getting on this discussion. Truth be told this isn't an option I had considered. For context I am directly under a gateway and observe RSSI values of around -80 typically. The network provider I am using (ThingPark/Actility) doesn't discard downlinks, but does raise alarms in the backend when device do not correctly service MAC commands or acknowledge downlink frames

[tibortiz]

Hi BenAtPip,

May I ask you the gateway model you are using ? -80 dB is the default value for the LBT in AS923 (Japan only). Did you see any error on the Wlogger console ?

To help you to understand this issue maybe we can start discussing this issue in private.

Best Regards,
Thibault

[BenAtPip]

Hi Thibault,

Unsure of the Gateway. I'm working towards the NZ standard for AS923. When checking the wireless logger I am able to see uplink payloads coming from my end devices, the main issue which is persistent is end devices not receiving, or at the very least processing, downlinks from the gateway. I'm observing this as resulting in the end devices having associated alarms in regards to unprocessed MAC commands.

[jamesl-dm]

I remember having to disable some payload size policing when getting ready for AS923 support on Actility. Offending code was:

             // Check if the received payload size is valid
             getPhy.UplinkDwellTime = LoRaMacParams.DownlinkDwellTime;
             getPhy.Datarate = McpsIndication.RxDatarate;
             getPhy.Attribute = PHY_MAX_PAYLOAD;

             // Get the maximum payload length
             if( RepeaterSupport == true )
             {
                 getPhy.Attribute = PHY_MAX_PAYLOAD_REPEATER;
             }
             phyParam = RegionGetPhyParam( LoRaMacRegion, &getPhy );
             if( MAX( 0, ( int16_t )( ( int16_t )size - ( int16_t )LORA_MAC_FRMPAYLOAD_OVERHEAD ) ) > phyParam.Value )
             {
                 McpsIndication.Status = LORAMAC_EVENT_INFO_STATUS_ERROR;
                 PrepareRxDoneAbort( );
                 return;
             }

But presumably you'd have noticed this one already if it was that easy.

[BenAtPip]

Hi James,

Looking at my current builds version of the LoRaMac.c file this code is essentially matched. My PHY_MAX_PAYLOAD is defined as the values stored in the MaxPayloadOfDatarateRepeaterDwell0AS923 & MaxPayloadOfDatarateDwell1UpAS923 arrays in the Region header file. Are these value incompatible with Actility's implementation of AS923? Note: edited

[jamesl-dm]

I don't actually remember the details now... Just that for the particular test profile they had us set up with (we were also targeting NZ) we got some larger than expected packets. I think it has to do with the dwell time being enabled on the client by default, but not required in NZ. The standard doesn't require us to police the packet sizes, so I don't see any reason not to remove that check.

[BenAtPip]

Awesome. Thank you for your insight!

[mluis1]

As there is no activity for quite long time we close the issue.