Rx timeout Issue in RxDutyCycle

[piyushy6]

Hi, I am using WL55JC1 board with STM32CubeIDE. (SF=7 and BW=125)

I have modified the code from Applications/SubGHz_Phy/SubGHz_Phy_PingPong for LoRa-to-LoRa transmission. On the receiver end, I am using duty cycle - Radio.SetRxDutyCycle(((uint32_t)(2048000/ 15.625f)), ((uint32_t)(10240000/ 15.625f)));

I am using a long preamble (12 seconds) for the 1st packet sent by the transmitter. And short preamble for the rest of the packets. The Semtech manual says that in duty cycle, when a "preamble is detected, the Receiver timeout is stopped and restarted with the value (2 rxPeriod + sleepPeriod)." But in my case, somehow the timeout is restarted with a value = sleepPeriod (10.24 seconds) only. Due to this, before the complete preamble (12 seconds) is received, the board goes to sleep mode, and the packet is not received. And few subsequent packets are also dropped. I am not sure why the Rx timeout is restarted with sleepPeriod, instead of (2 rxPeriod + sleepPeriod). Also, when I use Preamble time (= 9 seconds) < Sleep Period (10.24 seconds), I am able to receive the 1st packet. I have also tried StopTimerOnPreamble command, with this also I am able to receive the 1st packet.

So, not sure why after preamble detection, timeout is restarted with a value = sleepPeriod (10.24 seconds) instead of (2 * rxPeriod + sleepPeriod).

[ASELSTM]

Hi @piyushy6,

Thank you for your contribution. Please allow me to introduce @YoannBo who will look deeper into your report.

Thank you for your patience and again thank you for your contribution.

With regards,

[piyushy6]

Hi @piyushy6,

Thank you for your contribution. Please allow me to introduce @YoannBo who will look deeper into your report.

Thank you for your patience and again thank you for your contribution.

With regards,

Hi, Any update?

[YoannBo]

Hello @piyushy6 ,

I think what you descibe is exactely whay is written in the datasheet

(1) The radio will enter Receive mode and listen for a preamble for the specified RxPeriod period. -> The RxPeriod must be greater or equal than the length of the preamble. It means the Rx Period should be greater than 12 seconds in your case. (2) Only Upon the detection of a preamble, the RxPeriod timeout is stopped and restarted with the value 2 x RxPeriod +SleepPeriod. -> since in your case, the 12 second preamble is never detected (due to (1) ), the timeout is not restarted with 2 x RxPeriod +SleepPeriod.

let me know,

Yoann

[ASELSTM]

Hi @piyushy6,

Any new comments to move this discussion forward?

With regards,

[ASELSTM]

Hi @piyushy6,

Please allow me to close this thread as no updates since a couple of months. You can reopen the issue at any time if you have any updates so that we can help you. Thank you for your comprehension.

With regards,

[piyushy6]

Hi @ASELSTM @YoannBo Sorry for the late reply, I missed your response. I have few updates to share.

I am using Lora point to point communication with STM32WL chip. I am using SF7 with Duty Cycling on Rx end. Radio.SetRxDutyCycle(((uint32_t)(2048000/ 15.625f)), ((uint32_t)(10240000/ 15.625f)));

The Rx time is 2.048 second and the sleep time is 10.24 second.

I am using preamble symbol as 11000 , which is equivalent to 11.264 second.

1.) If you look in manual AN1200.36 (Application Note: RxDutyCycle), you can clearly see that -

Preamble time > Sleep time
(preamble should have a minimum value consisting of

• sleepPeriod + 8 symbols in LoRa)

2.) If you look in manual SX1261/2 Data Sheet, you can clearly see that - Tpreamble + Theader ≤ 2 * rxPeriod + sleepPeriod

Both of my conditions are True, so not sure why do I still miss initial packet sometimes? It does not happen consistently, but still happens.

@YoannBo , you earlier mentioned that "The radio will enter Receive mode and listen for a preamble for the specified RxPeriod period. -> The RxPeriod must be greater or equal than the length of the preamble. It means the Rx Period should be greater than 12 seconds in your case.",

I think what this point means is that the Receiver looks for a preamble in RxPeriod, it does not mean that it needs to wait for the entire preamble. As you look at the below point in manual, it says - "Upon preamble detection, the timeout is stopped and restarted with the value 2 rxPeriod + sleepPeriod", so if the Preamble is detected in RxPeriod, the timeout will stop and will be restarted with the value 2 rxPeriod + sleepPeriod ?

Also, if look at AN1200.36 , it never mentions that Rx Period should be > Preamble period. It only mentions that Preamble time > Sleep Time , so we don't miss these initial packets.

Looking to hear back soon.

Piyush

[YoannBo]

Hi @piyushy6,

can you share the sample code you are using so that i can have a deeper look?

thank you

[YoannBo]

HI @piyushy6 meanwhile, I tried reproduce your bench, probably not the same as yours, but before I receive your code, it is the best i could do.

in Radio.Random, all Radio IRQ are disabled and not restored after (probably something) to be corrected.

Either: 1/ remove Radio.Random from you modified code

or

2/

add SUBGRF_SetDioIrqParamsin RadioSetRxDutyCyclein file radio.c as below, and it is showing Rx done interrupts. It seems to be better

static void RadioSetRxDutyCycle( uint32_t rxTime, uint32_t sleepTime )
{
   SUBGRF_SetDioIrqParams( IRQ_RADIO_ALL, IRQ_RADIO_ALL, IRQ_RADIO_NONE, IRQ_RADIO_NONE );
    /* RF switch configuration */
    SUBGRF_SetSwitch(SubgRf.AntSwitchPaSelect, RFSWITCH_RX);

    SUBGRF_SetRxDutyCycle( rxTime, sleepTime );
}

let me know

[YoannBo]

HI @piyushy6 ,

I have reproduced your test bench, and i can reproduce the issue you are facing. The issue is an hardware bug. We are looking at a SW workaround and let you know as soon as we have any update,

Sorry for the inconvenience

best regards

[piyushy6]

Thanks @YoannBo Hope to get the SW workaround soon!

Any idea what might be the issue on the hardware side?

Regards

[YoannBo]

Hello @piyushy6 ,

please try the following patch using git apply patch.patch.txt onto stm32cubeWLv1.1.0

patch.patch.txt This should workaround the hardware bug in the Radio IP.

Let me know,