I’ve ported the Semtech LoRa Basic Modem library to Zephyr for my project. It works fine until I enable CONFIG_PM. Does anyone have any insight into what might be causing this issue? I understand that the LoRa Basic Modem library isn’t officially part of Zephyr yet, but perhaps someone has encountered a similar problem and has a solution or idea.
I can see that the join request from the chip successfully reaches the gateway, and the gateway accepts it, but the LoRa device immediately generates a fail event due to modem returns RX Timeout flags. There is no problem with dev eui and app_key. if I disable the configuration. a join request will will be ok.
Here are the gateway LoRaWAN frames:
zephyr version: v3.6-branch
sdk version: zephyr-sdk-0.16.6
MCU: STM32U575ZIQ
SHIELD: semtech_lr1121mb1xxs
Any workaround ideas? Can anyone shed some light on how to debug at least?
@descartes acutally, i dont think its a kernel issue., The modem generates correct interrupts, for tx and rx for the app without pm, but for the fail app rx, it generates rx timeout within the same time window
Please look at the logs
One fail join attempt log:
INFO: Use soft secure element for cryptographic functionalities
stack_id 0
DevNonce = 24
JoinNonce = 0xff ff ff, NetID = 0xff ff ff
Region = CN470_RP_1_0
255 smtc_modem.c
Modem event callback
Event received: RESET
2
INFO: smtc_modem_join_network
Start a new join sequence now on stack 0
262 smtc_modem.c
313 main_periodical_uplink.c
318 main_periodical_uplink.c
Join is starting
DevEUI - (8 bytes):
66 30 31 34 63 36 39 65
JoinEUI - (8 bytes):
00 00 00 00 00 00 00 00
DevNonce 0x19, stack_id 0
Send Payload for stack_id = 0
1381 lr11_apps_common.c
ralstatus1:0 4194308 2
793 radio_planner.c update: 2
1381 lr11_apps_common.c
662 lr1_stack_mac_layer.c update: 3
749 lr1_stack_mac_layer.c update: 2
TX DONE
radio_timestamp: 47934 time_off_ms: 0 jn stat:1
296 lr1mac_core.c wnds: 0 1
delay_ms 5000
rx_offset_ms:-2, rx_timeout_symb_in_ms:16, rx_window_symb: 8, board_delay_ms:2
freq rx1: 507500000
timeout prm: 3000
RX1 LoRa at 52932 ms: freq:507500000, SF8, BW125, sync word = 0x34
Timer will expire in 4975 ms
300 lr1mac_core.c past: 0
1381 lr11_apps_common.c
ralstatus1:0 4195328 8
793 radio_planner.c update: 8
822 radio_planner.c update:
1381 lr11_apps_common.c
662 lr1_stack_mac_layer.c update: 5
749 lr1_stack_mac_layer.c update: 4
1RX1 Timeout for stack_id = 0
delay_ms 6000
rx_offset_ms:-2, rx_timeout_symb_in_ms:16, rx_window_symb: 8, board_delay_ms:2
freq rx2: 505300000
timeout prm: 3000
RX2 LoRa at 53932 ms: freq:505300000, SF8, BW125, sync word = 0x34
Timer will expire in 764 ms
1381 lr11_apps_common.c
ralstatus1:0 4195328 8
793 radio_planner.c update: 8
822 radio_planner.c update:
1381 lr11_apps_common.c
662 lr1_stack_mac_layer.c update: 5
749 lr1_stack_mac_layer.c update: 4
RX2 Timeout for stack_id = 0 Start a new join sequence in 14 seconds on stack 0
Modem event callback
Event received: JOINFAIL
one successful join request
INFO: Use soft secure element for cryptographic functionalities
stack_id 0
DevNonce = 46
JoinNonce = 0x21 00 00, NetID = 0x00 00 00
Region = CN470_RP_1_0
Modem event callback
Event received: RESET
2
INFO: smtc_modem_join_network
Start a new join sequence now on stack 0
Join is starting
DevEUI - (8 bytes):
66 30 31 34 63 36 39 65
JoinEUI - (8 bytes):
00 00 00 00 00 00 00 00
DevNonce 0x2f, stack_id 0
Send Payload for stack_id = 0
1446 lr11_apps_common.c
1446 lr11_apps_common.c
662 lr1_stack_mac_layer.c update: 3
749 lr1_stack_mac_layer.c update: 2
TX DONE
radio_timestamp: 13408 time_off_ms: 0 jn stat:1
297 lr1mac_core.c wnds: 0 1
delay_ms 5000
rx_offset_ms:-2, rx_timeout_symb_in_ms:16, rx_window_symb: 8, board_delay_ms:2
freq rx1: 506700000
timeout prm: 3000
RX1 LoRa at 18406 ms: freq:506700000, SF8, BW125, sync word = 0x34
Timer will expire in 4980 ms
301 lr1mac_core.c past: 0
1446 lr11_apps_common.c
1446 lr11_apps_common.c
662 lr1_stack_mac_layer.c update: 4
749 lr1_stack_mac_layer.c update: 4
1Receive a Valid downlink RX1 for stack_id = 0 update join procedure
DevAddr= ba9a01
MacRx1DataRateOffset= 0
MacRx2DataRate= 0
MacRx1Delay= 1
Modem event callback
Event received: JOINED
Modem is now joined
Joined
How am I supposed to see this in the logs? I don’t see any timestamps, I have no clue what you are referring to. Can you turn on timestamps in your terminal/device console?
What frequency band are you using? CN470? How is your device configured regarding LW version and RP version? May sound useless to you, but details like these make us get a tiny bit of feeling for what is going on - besides Zephyr being completely outside expertise of almost everyone here including me.
Without timestamps we can’t really move forward. Some debug messages on the interrupts would help. You could also put in a breakpoint just before the sleep to check the pin configuration is setup OK.
As you are geolocated in Ireland, why the CN470 channel plan?
You could also put in a breakpoint just before the sleep to check the pin configuration is setup OK.
There is no sleep during the boot-up and join request, and the device is fully functional/operational. The configurations is the same for both w/o pm. I am putting the device in sleep mode after sending all data.
The main thing that I observe is this: note the time difference between the Rx1 window opening and the IRQ received.
Successful join:
Failed join:
In case of the failed join, there is only a 20ms Rx1 window apparently! That is quite a stretch… I’m not completely up to date on the conditions to stay in Rx mode for the LR11xx series, but 20ms is really optimistic as far as I’m concerned.
Apparently they are optimistic and apparently it is possible to catch a downlink with that, but if the timing is only very slightly off, that’s game over. So my guess is the PM thingamajig is throwing that off.
@stevencellist@descartes Ive just come across another issue that lr1121 modem does not have any more successful join requests, even though I am using the test software I always have successful join request.; it always returns rx_timeout for some reason. Is it possible that the device get corrupted?
Have you checked for errors in the TTN application console? Does TTN show success for the join request or does it drop it because of something it considers an invalid condition?
If I tell you that the PM = Power Manager and that that flags tells Zephyr to go in to the lowest sleep state it can if there is nothing doing - particularly including a busy-wait - does that help?
I’d surmise that the IRQ fires and by the time everything is put back in place to continue running, particularly as Zephyr is a pre-emptive OS with all that is involved with context switching, the moment appears to have passed according to LBM.
The Semtech implementations and indeed almost every other stack don’t sleep in the Rx1 wait and the forum is littered with attempts by people to optimise that, only a handful successful.
I’d suggest turning off sleep whilst doing a send-receive. Not sure how as usually I’m trying to get things to go low power but there is the rather brutal CONFIG_SYS_POWER_DEEP_SLEEP_STATES=n which will stop k_sleep() from doing anything other than a delay with yield. There may be some hints on how this is handled in the Zephyr LoRaMac-node implementation.
