SimpleAsync Example does not receive packets from the Helium Network

[rickhewes]

Describe the bug
When running a Lora-e5 module (STM32WL55) with Arduino example SimpleAsync.ino packets are not received from the Helium network. However if a packet is queued before a join, when the device joins the packet is received, but only once.

To Reproduce

Compile, flash SimpleAsync.ino to e5-mini, setup config variables.

Queue packet to be sent on LNS
Reset device.
Device joins.
Packet received

Queue packet to be sent on LNS
Device transmits data to LNS
No packet received

Expected behavior
Queue packet to be sent on LNS
Reset device.
Device joins.
Packet received

Queue packet to be sent on LNS
Device transmits data to LNS
Packet received

Screenshots

Desktop (please complete the following information):

• OS: Linux
• Arduino IDE version: 2.3.2
• Library version: 0.2.0
• Upload method: SWD

Hardware (please complete the following information):

• Board Name: Lora-E5 Dev board
• Extra hardware used if any: ST Link

Additional context

I have tried setting

modem.setRX2DR(DR_0);
modem.setRX2Freq(869525000);

Also setting in the queued message

FPort

But still not working.

[fpistm]

Hi @rickhewes
I've tested with the LoRa E5 mini which is supported by the STM32duino core.
https://wiki.seeedstudio.com/LoRa_E5_mini/
And it works as expected.
But it seems you used a other board:
https://wiki.seeedstudio.com/LoRa_E5_Dev_Board/

So how do you test it ?
Using the LoRa E5 mini ? or using generic variant?

Edit:
Got my answer:

Compile, flash SimpleAsync.ino to e5-mini, setup config variables.

Anyway even if they seems similar, don't know if it should work or of a new variant should be added.
As stated with my LoRa-E5 mini the SimpleAsync.ino works as expected on Orange Live Object network as you can see
herafter. I've also sent

11:18:38.081 -> Start
11:18:46.326 -> Joined
11:18:46.358 -> Queued packet
11:18:51.963 -> Sent packet
11:19:51.644 -> Queued packet
11:19:57.282 -> Sent packet
11:20:56.975 -> Queued packet
11:21:03.314 -> Sent packet
11:22:03.019 -> Queued packet
11:22:08.454 -> Sent packet
11:22:08.454 -> Received packet on port 1: DE AD BE EF
11:23:08.167 -> Queued packet
11:23:13.322 -> Sent packet
11:24:13.038 -> Queued packet
11:24:18.165 -> Sent packet
11:25:17.899 -> Queued packet
11:25:23.053 -> Sent packet
11:26:22.750 -> Queued packet
11:26:27.909 -> Sent packet
11:27:27.588 -> Queued packet
11:27:32.742 -> Sent packet
11:28:32.441 -> Queued packet
11:28:37.599 -> Sent packet
11:29:37.303 -> Queued packet
11:29:42.750 -> Sent packet
11:30:42.476 -> Queued packet
11:30:52.787 -> Sent packet
11:31:52.512 -> Queued packet
11:32:02.790 -> Sent packet
11:33:02.518 -> Queued packet
11:33:12.803 -> Sent packet
11:34:12.521 -> Queued packet
11:34:22.833 -> Sent packet
11:35:22.560 -> Queued packet
11:35:32.875 -> Sent packet
11:36:32.592 -> Queued packet
11:36:42.911 -> Sent packet
11:37:42.636 -> Queued packet
11:37:52.915 -> Sent packet
11:38:52.645 -> Queued packet
11:39:02.966 -> Sent packet
11:40:02.687 -> Queued packet
11:40:12.997 -> Sent packet
11:41:12.731 -> Queued packet
11:41:23.304 -> Sent packet
11:42:23.040 -> Queued packet
11:42:28.199 -> Sent packet
11:43:27.916 -> Queued packet
11:43:33.073 -> Sent packet
11:44:32.824 -> Queued packet
11:44:37.980 -> Sent packet
11:45:37.707 -> Queued packet
11:45:42.863 -> Sent packet
11:46:42.614 -> Queued packet

[rickhewes]

That is great to know. I don't think there is much difference between the mini and dev board.

Could I ask what versions of Lorawan protocols you have setup?

Region : EU868
MAC version : LoraWan 1.0.4
Regional Parameter : B

Can you think of any other configuration that might be different?

Thanks,

Rick.

[fpistm]

I used default one.
EU868 Class A. LoRaWan 1.04
https://stm32duino.github.io/STM32LoRaWAN/index.html

[rickhewes]

I have had some success with the FreeRTOS_LoraWAN_AT application.
I can successfully send and receive.

So there is some discrepancy between the Arduino library and the FreeRTOS_LoraWAN_AT application.

Not sure where to go from here. Are you able to try your device on Helium?

[fpistm]

Not sure where to go from here. Are you able to try your device on Helium?

Unfortunately not.

[rickhewes]

So where do we go from here?

Ta,

Rick

[fpistm]

So where do we go from here?

Ta,

Rick

Don't know.

[rickhewes]

Further investigation:

FreeRTOS_LoraWAN_AT successfully receive downlink:

16:19:25.181 -> OK
16:19:26.500 -> 244s540:MAC txDone
16:19:27.528 -> 245s580:RX_1 on freq 868300000 Hz at DR 0
16:19:27.722 -> 245s778:IRQ_RX_TX_TIMEOUT
16:19:27.722 -> 245s778:MAC rxTimeOut
16:19:28.526 -> 246s580:RX_2 on freq 869525000 Hz at DR 0
16:19:29.941 -> 248s000:MAC rxDone
16:19:29.973 -> +EVT:1:03:0f340a
16:19:29.973 -> +EVT:RX_2, DR 0, RSSI -34, SNR 6

SimpleAsync.ino successfully receive downlink after OTAA:

15:37:26.183 -> TX on freq 868100000 Hz at DR 4
15:37:26.183 -> TX: 40 4a 09 00 48 80 01 00 0a f7 ef 66 b2 15 f6 df ff
15:37:26.183 -> Queued packet
15:37:26.280 -> MAC txDone
15:37:27.281 -> RX_1 on freq 868100000 Hz at DR 4
15:37:27.314 -> IRQ_RX_TX_TIMEOUT
15:37:27.314 -> MAC rxTimeOut
15:37:28.316 -> RX_2 on freq 869525000 Hz at DR 0
15:37:29.576 -> MAC rxDone
15:37:29.576 -> RX: 604a0900488600000352ff000106c374017d
15:37:29.576 -> McpsConfirm: req=MCPS_UNCONFIRMED, status=LORAMAC_EVENT_INFO_STATUS_OK, datarate=4, power=0, ack=0, retries=0, airtime=93, upcnt=1, channel=0
15:37:29.608 -> McpsIndication: ind=MCPS_UNCONFIRMED, status=LORAMAC_EVENT_INFO_STATUS_OK, multicast=0, port=0, datarate=0, pending=0, size=0, rxdata=0, ack=0, dncnt=0, devaddr=4800094a, rssi=-33, snr=5, slot=1
15:37:29.608 -> Sent packet

SimpleAsync.ino failed downlink:

15:42:39.300 -> Setting TX Config: modem=MODEM_LORA, power=9, fdev=0, bandwidth=0, datarate=7, coderate=1 preambleLen=8, fixLen=0, crcOn=1, freqHopOn=0, hopPeriod=0, iqInverted=0, timeout=4000
15:42:39.368 -> TX on freq 868300000 Hz at DR 5
15:42:39.368 -> TX: 40 4a 09 00 48 80 06 00 0a 90 16 1e 36 f0 61 ef 7c
15:42:39.368 -> Queued packet
15:42:39.395 -> MAC txDone
15:42:40.393 -> RX_1 on freq 868300000 Hz at DR 5
15:42:40.393 -> IRQ_RX_TX_TIMEOUT
15:42:40.393 -> MAC rxTimeOut
15:42:40.425 -> McpsConfirm: req=MCPS_UNCONFIRMED, status=LORAMAC_EVENT_INFO_STATUS_OK, datarate=5, power=2, ack=0, retries=0, airtime=52, upcnt=6, channel=1
15:42:40.425 -> Sent packet

So from this you can see data is received in the second receive window. However after the initial join the RX2 window is never tried again.

Any ideas why that might be?

[rickhewes]

I have it working, something to do with this code LoraMac.c:

Does this check need a grace period or something?

[fpistm]

Honestly, I don't know, we simply use the LoRaWan implementation provided by the STM32CubeWL:
https://github.com/STMicroelectronics/STM32CubeWL/blob/788f569cd50ff1431c9361baece7e0d869089835/Middlewares/Third_Party/LoRaWAN/Mac/LoRaMac.c#L1835

I will check if an update is needed.
Or it is linked to #38 issue. We provide a fix and wait a confirmation from the OP.

[mrschuster]

The LoraMac.c is skipping the RX2 every now and then, since it thinks it has missed the rx2 window. Cause is a flawed conversion from ticks to ms.