Deep sleep is never achieved with SUBGRF_SetRxDutyCycle

[vrAntoine]

I was trying to use SUBGRF_SetRxDutyCycle, and I noticed that my current consumption in the radio sleep phase is higher than when I call the sleep through SUBGRF_SetSleep.
I measure 77.55uA in the sleep phase of the Rx duty cycle, and 2.10uA if I call SUBGRF_SetSleep.

After some investigation, I have found that the difference is the Radio RF switch set to RBI_SWITCH_RX in SUBGRF_SetRxDutyCycle, while it is set to RBI_SWITCH_OFF in SUBGRF_SetSleep.
In the paper, everything seems all right because in the RX duty cycle process, we want the RF switch set to RBI_SWITCH_RX during the awaken phase. However, by doing a workaround, I was able to set the sleep phase consumption to 2.82uA and still have my listen window working fine.

My workaround:

In HAL_SUBGHZ_ExecSetCmd I force back the switch to RADIO_SWITCH_OFF if a sleep status is set.
https://github.com/STMicroelectronics/stm32wlxx-hal-driver/blob/a496d1eebd7394fb880ebfdd56fdcb5f2cce687b/Src/stm32wlxx_hal_subghz.c#L978

if ((Command == RADIO_SET_SLEEP) || (Command == RADIO_SET_RXDUTYCYCLE))
    {
      HAL_RADIO_SetSwitchConfig (RADIO_SWITCH_OFF);
      hsubghz->DeepSleep = SUBGHZ_DEEP_SLEEP_ENABLE;
    }

This seems to continue to work fine because, from the SX1261/2 datasheet p77 (datasheet link):

When this command [SetRxDutyCycle] is sent in STDBY_RC mode, the context (device configuration) is saved and the chip enters in a loop ...

At the end of the SLEEP window, the chip automatically restarts the process of restoring context en enters the RX mode, and so on.

I guess the initial RF switch status is saved when the Rx duty cycle is set and restored every time the Rx window is entered again.

Can somebody try to reproduce this workaround and validate that the listening window continues to work as expected ?
If everything is working without issue, is it possible to add the workaround in the next version ?

[vrAntoine]

I have conducted some testing with the proposed workaround, and there is one major issue: a significant amount of reception sensitivity is lost.

In fact, the communication is working on the working desk, but it's not the same case outside. The communication range is reduced by 4 in my use case.

I attempted to enhance the workaround by utilizing the busy signal from the SX126x as an interrupt to change the RF switch, but I was still consuming too much current in the process.

To summarize:

The proposed workaround should not be implemented, but the consumption issue still exists. Is it possible to change the RF switch without waking up the STM32? Or if a solution with a quick wake-up is proposed, the global current consumption shall be below the current driver version without changes in the RF switch.

[vrAntoine]

Last update on this issue for me.
I have implemented a change on the RF switch through the BUSY signal from the SX126x. The BUSY signal is high when the RF module is in sleep and low when it is ready to receive RF data (chapter 8.3.1 from SX126x datasheet). It seems that the BUSY signal is well commanded during the Rx duty cycle phase. I had to use the busy IRQ on the falling edge, because the rising one was making consume my board 1mA passively.

While the switch command seems coherent with what was expected, my radio range tests in the field were not convincing. Indeed, I had similar results after this workaround as with the previous one, where the RF switch was kept at OFF status.

Here is a consumption graph of the STM32WL5 I used

To estimate the RF switch status, I mimicked its command to another GPIO and sampled it with a power profiler kit. I commanded the reception to be 1.2ms long, and the GPIO switch came after 420µs.

I have no other solution to propose, so I will wait for an update on the bug.

[MKISTM]

Hello @vrAntoine,

Thank you for your contribution. I have tried to reproduce the issue but was unable to do so.
Could you please provide more details about the problem? Specifically, could you share your code modifications and clarify the description of the issue?

BR,
Mohamed Chaker.