LoRa RX timeout triggers immediately in non-continuous receive mode

[Erlkoenig]

On the STM32WL55, when using LoRa and non-continuous receive mode, the RX timeout triggers immediately, i.e. the value passed to Radio.Rx is ignored. This can be demonstrated using the SubGHz_Phy example on the NUCLEO-WL55JC and setting

#define USE_MODEM_LORA  1
#define USE_MODEM_FSK   0

and also

#define TEST_MODE                     RADIO_RX

 and modifying the call to Radio.SetRxConfig:

  Radio.SetRxConfig(MODEM_LORA, LORA_BANDWIDTH, LORA_SPREADING_FACTOR,
                    LORA_CODINGRATE, 0, LORA_PREAMBLE_LENGTH,
                    LORA_SYMBOL_TIMEOUT, LORA_FIX_LENGTH_PAYLOAD_ON,
                    0, true, 0, 0, LORA_IQ_INVERSION_ON, false);

i.e. setting the last parameter to false such that continuous mode is disabled. The OnRxTimeout function will be called very quickly, even though the timeout is set to 2s. The red LED will flash very quickly. (No transmitter is present, just listening to "silence").

Timeouts work fine on FSK RX in non-continuous mode (red LED flashes slowly).

Strangely, when first setting the modem to LoRa TX and transmitting >= 1 packets and then immediately re-configuring for LoRa RX, the timeout works fine! This does however not work when transmitting an FSK packet before. Going to standby inbetween transmitting a packet and configuring for RX also does not make it work.

Is this a hardware bug?

[Tesla DeLorean]

>>Is this a hardware bug?

More probably software, I had to fix several issues in continuous mode on earlier versions.

All the source is provided, track/trace why

[Erlkoenig]

But I'm using non-continuous mode, not continuous.

Tracing the framework source shows me that the RX timeout interrupt was indeed triggered by the SubGHz hardware, and also that the timeout is configured correctly.

[Erlkoenig]

When setting symbTimeout=0, it works. In continuous mode, the middleware does this automatically:

static int32_t RadioSetRxGenericConfig( GenericModems_t modem, RxConfigGeneric_t *config, uint32_t rxContinuous,
                                        uint32_t symbTimeout )
{
...
    if( rxContinuous != 0 )
    {
        symbTimeout = 0;
    }

What is the exact purpose of disabling the symbTimeout only in continuous mode? 

[STTwo-32]

The Firmware disable automatically symbTimeout on the continuous mode but on the Discontinuous mode, you have to do this manually if you want (Just a programming choice).

Best Regards.

STTwo-32

[Erlkoenig]

---

@STTwo-32 wrote:

you have to do this manually if you want (Just a programming choice).

---

So this means I can choose between:

• Use continuous mode, where symbTimeout is forced to 0
• Use non-continuous mode with symbTimeout != 0 which does not work as timeout is triggered immediately by the SubGHz peripheral (not the software timer)
• Use non-continuous mode with symbTimeout = 0

So effectively, the symbol timeout can't be used at all? Then why do the peripheral and the SubGHz middleware appear to support it? The manual even recommends using it:

In LoRa packet type, when entering the Receive mode and SymbNum[7:0] = 0x0, the
modem locks as soon as a single LoRa symbol is detected. This may lead to a false
detection. To avoid false detections, the number of LoRa symbols to be detected can be
increased.

---

But why does it work when I send a LoRa packet directly before?

[Zeepunt]

Hi, I have same problem too.

Have you slove the problem? Or can you share the solution? Thanks.

[Erlkoenig]

Hi Zeepunt, unfortunately I don't know of a "real" solution (except using TX mode right before entering RX mode). The workaround is to use continuous mode, or set symbTimeout = 0.