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.