RFM95/SX1276 FSK Rx hardware timeout not always occuring?

[gitdode]

This question is just to help my understanding on the topic.

I've implemented very basic support for RFM95/SX1276 and an AVR MCU (just for fun & to learn); it works fine but when receiving a packet with timeout on DIO4 in FSK mode, when the signal is "on the edge", the timeout interrupt sometimes does not occur.

I have the impression that RSSI, PreambleDetect and SyncAddress timeouts occur, but if all events occur and no payload "becomes ready", there will be no timeout interrupt.
The RFM69 has a "PayloadReady" timeout and it works just fine. Is the RFM95/SX1276 missing such a "PayloadReady" timeout? In LoRa mode, timeout via DIO0 works perfectly fine.

Looking at SX127x::receive, the hardware timeout is only used in LoRa mode while in FSK/OOK only a software timeout is used.
Is my observation correct and is this behaviour the reason for not using the hardware timeout in FSK/OOK mode?

[StevenCellist]

The coincidence.. #1496 ;)

[gitdode]

Do I understand correctly, that the solution for #1496 won't use the interrupt on DIO2/4 but a software timeout?

We can use the SX127x timeout mechanism even without having access to the physical DIO pin.

I'd be really happy if someone could confirm my observation (or tell me what I am missing). I asked the question at SO but no luck. I just can't believe they "forgot" a PayloadReady timeout like the RFM69 has.

[jgromes]

In that specific issue, I was mainly trying to get SX127x working in FSK LoRaWAN channel. For that, we needed to distinguish between reception timing out, and packet being received. The problem there was that this timeout interrupt is only signalled on DIO2 or DIO4, which are typically left unconnected.

Once fixes from #1496 are in upstream (pending tests), the SX127x Rx timeout interrupt will be activated and signalled on DIO2.

In general to answer your original question, you need to (assuming you are not using RadioLib):

1. Set the timeout duration by writing into the appropriate REG_RX_TIMEOUT register (depending on whether you want the timeout to occur on RSSI, preamble or sync word)
2. Activate the timeout trigger in REG_RX_CONFIG
3. Set the appropriate DIO configuration to route the interrupt signal to either DIO2 or DIO4

I just can't believe they "forgot" a PayloadReady timeout like the RFM69 has.

They didn't, it's just not available on the commonly used DIO0/DIO1 pins, and it is not explicitely called out in the interface, as is the case with LoRa RxSingle and RxContiuous modes.

[gitdode]

Thank you so much for your detailed answer.

I am already doing what you suggest, and in general the timeout interrupt occurs on DIO4 as expected, but when the signal strength is really on the limit, there is sometimes no timeout and no PayloadReady interrupt either.
I tried many combinations, for example setting all of RegRxTimeout1..3 and RxTrigger to 111 so all 3 timeouts are active, but still, pretty well reproducible, no timeout and no PayloadReady is issued when the signal is very weak.

This works perfectly well with the RFM69, which has a "Timeout duration between RSSI detection and PayloadReady" which the RFM95 does not seem to have:

• Rx to RSSI
• Rx to Preamble
• Rx to SyncWord

I suppose it is not guaranteed that if the SyncWord flag was raised, a payload with the expected length is received and the PayloadReady interrupt is issued?

[jgromes]

I think the core issue is that neither of these interrupts are actually tied to PayloadReady. For example, let's say only the RSSI timeout is active. If there just so happens to be a signal powerful enough that is not the packet you are expecting, then the RSSI timeout will not trigger (since the radio detected that signal). However, there will also be no packet interrupt, since the radio will most likely fail to demodualte this spurious signal.

So in fact you were right before, there is no direct equivalent of the Rx timeout within the LoRa modem of SX127x or RF69 (aka SX1231).