Skip to main content
NMeno
NMeno
Associate II
Jul 26, 2023 4:03 PM UTC
Question

Receiving unexpected LoRaWAN MAC commands on OnRxData (Application layer)

Hi everyone!
 
I'm working with STM32WLE5CC chips and developing the firmware using STM32Cube FW_WL V1.2.0.
In general the motes are working fine in Lorawan Class C mode.
 
The issue I'm observing is that in a random way (once or twice in a day) the motes receive a downlink frame which is not sent by the high level application behind NS (ChirpStack).
As you can see in the mote's logs the mote detects it with a FCnt=0 (it should be much higher) and FPort=0. Based on the FPort=0 it should be a MAC command so it shouldn't be passed to the mote application layer handled by the OnRxData callback in the firmware. 

 

 

2023-07-26 00:32:17,236 - usb1 - INFO - 136193s478:MAC rxDone
2023-07-26 00:32:17,244 - usb1 - INFO - ###### D/L FRAME:0000 | PORT:0 | DR:8 | SLOT:C | RSSI:-105 | SNR:-24
2023-07-26 00:32:17,248 - usb1 - INFO - 136193s484:RX_C on freq 923300000 Hz at DR 8
2023-07-26 00:32:17,255 - usb1 - INFO - 136193s485: >>>>>> DOWNLINK received: 518350011080de2f8eac55d055acae1f9388273b. << this log is generated in the OnRxData function by my code
2023-07-26 00:32:17,260 - usb1 - INFO - 136193s485: >>>>>> Unknown command received. << this log is generated in the OnRxData function by my code
2023-07-26 00:32:49,739 - usb1 - INFO - 136225s984:MAC rxTimeOut
2023-07-26 00:32:49,742 - usb1 - INFO - 136225s984:HDR KO

 

 

After receiving this frame sometimes the motes get stuck and hung, and stop responding to downlink commands and stop sending uplink frames as well.
At first I thought it could be an interference causing the mote to interpret it as a DL, but after reviewing the Lorawan modules and specifications I think that is almost impossible.
The other thing that made me think about an interference is that the RSSI for these frames (-105) is much lower than an expected frame (-40, I'm very close to my GW).
 
Have you experimented with something similar?
Could be it a multicast frame coming from another GW?
 
The other thing I'll try is the v1.3.0 of the ST library, maybe I'm hitting a bug?
 
Thanks!
This topic has been closed for replies.

2 replies

IIRHO.1
IIRHO.1
ST Employee
Jul 27, 2023 7:34 AM UTC

Hello @NMeno and welcome to ST Community.

the issue can be a  multicast frame coming from another GW.

I suggest you to:

  • upgrade to the STM32CubeWL v1.3.0 to see if that resolves the issue.

  • Check the ChirpStack logs to see if there are any indications of unexpected downlink frames or multicast frames being sent.

  • Verify that the network configuration is correct and that all gateways are properly configured.

  • Consider using a packet sniffer to capture the downlink frames and analyze their contents.

When your question is answered, please close this topic by choosing "Accept as Solution". This will help other users find that answer faster.

Issam

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
NMeno
NMenoAuthor
Associate II
Aug 1, 2023 11:42 AM UTC

Hi Issam, thanks for your reply and suggestions.

Here are my tests:

  1. Updating to the STM32CubeWL v1.3.0 didn't change anything.
  2. No downlink frame were sent my Chirpstack.
  3. I changed the AppKey and then it stopped receiving those frames.

To be honest I'm not sure about the root cause of the issue, I had not enough time to get a clear conclusion but I'm still doing some test so I'll came back if something new appears.

Thank you for the support.

Nicolas.

    Terms & ConditionsAccessibility statement