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.

[FormerMember]

1) Whether or not it can be useful to check the address to avoid timeout when a receive is in progress depends on how you want the protocol to work. To me, it sound like a good idea to avoid a timeout when there is a receive in progress.

2) The radio will not go to "disabled" state unless TASKS_DISABLE is triggered by the firmware. In which state diagram does the radio automatically go to "disabled"? The below state diagram shows that the radio will only be disabled when "TASKS_DISABLE" is triggered. If you want the radio to spend as little time in RXIDLE as possible, you can use a shortcut between EVENTS_END and TASKS_START.

[butch]

Re 2) I should have said the RXIDLE state. But my code shortcuts past RXIDLE and RXDISABLED all the way to DISABLED, and I think that is a common thing to do. It doesn't matter whether you start from the RXIDLE state or the DISABLED state, to subsequently transmit requires another ramp up delay of 40uSec.

To be clear, I am not "avoiding a timeout." There is a race between the receive done and the timeout. The timeout might just barely beat the receive done, and that is what I want to detect. But then I want to busy wait (or spin) on the END event (or if shortcuts are used on the DISABLED event.)