using radio address event to detect packet in progress

RE: using radio address event to detect packet in progress

butch — Fri, 04 Nov 2016 21:49:45 GMT

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.)

RE: using radio address event to detect packet in progress

butch — Fri, 04 Nov 2016 15:32:02 GMT

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.)

RE: using radio address event to detect packet in progress

FormerMember — Fri, 04 Nov 2016 15:00:27 GMT

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.