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

[DBhut.1]

I used timestamp  edges and calculate debounce it works, now Device miss 8 out of 50, success ratio of downlink increases, but still missing downlinks, any idea what I can do to make sure 100% downlink success.

[Tesla DeLorean]

Anything remarkable about the ones you missed vs what the system was doing?

Perhaps you could have a second unit that listens for diagnostic/logging purposes to confirm reception/availability of the transmission. On your primary system reflect current radio state to a GPIO, so you can view real-time on a scope or analyzer why you might be missing specific transmissions.​

[DBhut.1]

Hello,

I have observed that RX1 Window sometimes open late by 100-150ms and so downlink missed by node. This happens due to other task is performing and time comes to open Rx1 Window. So, node is not opening Rx1 window on time needed.

So, if a task is responsible for opening RX1/RX2 window, then it is obvious, that sometime downlink will missed by node, as it also have other task to perform.

So, Is there any way to open RX1/RX2 window on time without task(inside timer interrupt)?

can I call LoRaMacHandleIrqEvents( ) inside OnMacProcessNotify(), as we also have high frequency pulse on External GPIO?

I tried calling LoRaMacHandleIrqEvents( ) inside OnMacProcessNotify(), and get 50 downliks out of 50 if no external interrupt rise, and if fast pulse arise then We get 49 out of 50, which is nearby to 100%, So Result is positive, but I am not sure this is a good way to solve this issue.

So, please guide me regarding this.

Thank You

[Tesla DeLorean]

Rather than use the approach of trying to call these other function, you should resolve the underlying issue of why you're soaking up so much time in tasks, that the critical task(s) miss their window so widely.

Move long running functions into lower priority tasks, and use more stateful approaches that don't require blocking or waiting, but rather yield and resume when data is available.

Keep the external pin monitoring out of the radio's tasks/business, any interrupts/callbacks need to be very fast.

I thought you were "functional safety", so hacky work-arounds don't seem to be the wise path.

[DBhut.1]

I agree that this is not wise path to call LoRaMacHandleIrqEvents( ) inside OnMacProcessNotify(),

I am not using FREERTOS for task, I am using STM32_seq.h library for task management. So, function is called in sequence, not by interrupt nd priorities, I have display and other tasks which could take about 30-40ms max to execute.

I will try to optimize delays in functions, but it seems to be difficult as already they are optimized. and no delays in any GPIO or Timer Interrupt is there.

but delay in functions (task callbacks) should not affect Lorawan functionality. Could you please elaborate downlink missing issue, when there is 50ms delay in task.

I have 6 tasks performing different task, let each takes 50ms, will this affects Lorawan Downlink?

Is there anyway to solve downlink issue without modifying tasks code (50ms time)?

Thank You

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