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.

[Tesla DeLorean]

Says guy who is missing data...

I​f you're blocking in the highest priority interrupt what else is going to happen?

Defer that stuff into the 1ms tick interrupt​. Or timestamp signal edges and filter those.

[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.