STM32WLE5CC miss Lorawan Downlinks

[DBhut.1]

Hello,

We are facing issue of missing downlinks, say missing 5 out of 30 downlinks, there is only 1 device and 1 gateway on TTN, gateway shows data that it sends downlink, but device unable to get it.

If there is fast External Interrupts (use to count external reed switch pulse), this ratio increases, and we miss 16 out of 30.

Please help us to solve this issue.

Thank You

[Louis AUDOLY]

Hello,

I have some question to understand better your issue.

What is the RSSI value when you receive downlinks ?

Do you have an error when you don't receive the downlink or just a timeout ?

Regards

[DBhut.1]

RSSI is about -64 and SNR is nearby to 8.

I doesn't see any error on server Side(I used Chirpstack as Server), and I got Timeout in device.

[Louis AUDOLY]

Hello,

Ok so I will need more information on your system.

Which application are you using ? Are you in class A or class C ?

Do you use a local network or distant one ? If you are connected to internet via a mobile phone, sometimes, the delay is to important and it can cause missed downlinks.

Concerning the interrupts, what is their period and which interrupts do you raise ?

Have you well define the priority of the interrupts you use to avoid any conflict ?

For the fast mode interrupts, they are used when the GPIO is an output, is it your case ?

Thank for your replies

Regards

[DBhut.1]

I am using Class A, and Network is 4G GSM(USB QMI) based Lorawan Gateway (on Raspberry Pi), I am using Chripstack Network Server installed on our own Server(AWS).

External GPIO Interrupt priority is 0(Highest) as we can't afford to miss pulse interrupt, and Timer is on priority and RTC Alarm interrupt is on priority 1 and SUBGHZ Radio interrupt on priority 1, as shown in below image.

 

Our Device reads pulses of a reed switch which is connected to meter. This Interrupt can be as fast as of 100ms for one pulse.

We detect this pulse in HAL_GPIO_EXTI_Callback() with 50s debounce check inside interrupt.

[Tesla DeLorean]

Doing a blocking delay in the interrupt will be a problem, you need to leave immediately and check the pin state again later.​

[DBhut.1]

Sorry delay is 50 millisecond debounce, But check in interrupt is only solution that we didn't miss pulse, as after that pin state may change, but As SX1262 Subghz is independent receive data and send Interrupt of complete, So I think it shouldn't be a problem of missing data.

[Louis AUDOLY]

Hello @DBhut.1​ ,

I think you may have several possibilities :

First to avoid to been stuck and wait 50ms because of the debounce, you could add a well designed low pass filter to your reed switch to have the interrupt when you can really measure it.

Or you could, as when the TxDone interrupt is raise (without a low pass), launch a timer of 50ms that can call a function to handle your measure.

Or as @Community member​ said, you can lower the priority of this interrupt, because I think that RTC Alarm and SUBGHZ interrupt have to stay to the lower priority because even a little delay of a Rx can make you miss your downlink.

Anyway I think the RTC and the SUBGHZ should be at least at the same priority of your EXTI.

Please try the option you prefer and let me know if you have better results

Regards

[Tesla DeLorean]

The SX12xx devices will only capture signals if they are listening for them when they occur. If the chip is in an idle or transmit mode it's going to miss what's happening. Getting the chip in to an RX mode at the right frequency and channel parameters as quickly as possible increases the chance of you getting data off the air. Clearly there's still the possibility of missing data, or mid-air collisions, but if you're ready and listening at the right time, with sufficient margin, you're going to be successful more often than you will be randomly disappearing for large fractions of a second.

Interrupts and callbacks can be a big trap for sequential/linear programmers, you need to be mindful, and defer things you can't do immediately, so other things can occur concurrently.

[DBhut.1]

I got another issue by calling LoRaMacHandleIrqEvents( ) inside OnMacProcessNotify(),

Device sleep current consumption increases to 600uA.

Could you please explain reason behind this?

[DBhut.1]

Hello @Tesla DeLorean (Community Member) and @Louis AUDOLY (ST Employee), please help me to solve this issue, we are just near to solve the problem. Your earlier responses helps us lots, So its my kind request you to please response.

Thank You

[DBhut.1]

Hello @Tesla DeLorean (Community Member) and @Louis AUDOLY (ST Employee), please help me to solve this issue, we are just near to solve the problem. Your earlier responses helps us lots, So its my kind request you to please response.

Thank You

[Louis AUDOLY]

Hello @DBhut.1​ ,

If you enter these functions, you are not anymore in sleep mode so it's normal if you notice an increase of your consumption.

Moreover 600uA is not so much in run mode.

Regards

[DBhut.1]

OnMacProcessNotify() function is calls when any interrupt occurs, and this triggers the lmhandler task, in this task LoRaMacHandleIrqEvents() is called. So whenever any Loramac interrupt occurs OnMacProcessNotify() will be called, as so LoRaMacHandleIrqEvents() be called.

So what I have done is called LoRaMacHandleIrqEvents() in OnMacProcessNotify() instead of task. So, I think this should not be an issue for current consumption.

current consumption is measured when device doesn't have any event sleep for 4 hours.