using radio address event to detect packet in progress

[butch]

I am duty-cycling the radio, so I listen with a timeout and then power off the radio (or transmit) if no packets were received. Currently I am ignoring the address event from the radio. Is it worthwhile to enable an interrupt on the address event and set a flag in the IRQ so that if there is a timeout, I can know when a receive is in progress, and spin until the packet is done (disabled event)?

A related question is: if the address event is triggered, will the radio always go to the disabled state in a finite time? The state diagram seems to indicate that the address event implies an address match and that the radio will proceed to the disabled state, even if length or CRC is bad.

To check for receive in progress seems like a form of carrier sense. You don't want to abort a receive in progress, and you don't want to start a transmission when another radio is transmitting.

By my rough calculations, even a short message of 10 bytes payload at 1Mbit would take about 0.1mSec, say 10,000 instructions, so there is plenty of leeway to set and check the flag.

Not using SoftDevice, a proprietary, raw protocol.

[butch]

To answer my own question, from experiments, it does NOT seem to be true that an END event will follow soon after an ADDRESS event. Looking again at the state diagram (which could be a simplification) it doesn't say an ADDRESS event takes the radio to a new state. That is, the diagram implies that many addresses could be matched consecutively (in noise), each setting the ADDRESS event. Thats what my experiments suggest. I suppose the radio could lose the carrier and start again looking for another preamble and address? In my experiments with no senders if the radio advances to the RXIDLE state after a (spurious) ADDRESS event, it usually is much later and is a CRC error. I could be wrong, try it for yourself. So the ADDRESS event can't be used in the manner I envisioned (or at least requires a more sophisticated implementation, say using another timeout after any ADDRESS event.)