I've been seeing a problem with the listen/wake code where the burst message received by the listener is totally bogus. The format of the burst message is:
0: Size
1: target node address
2: sender node address
3: low byte of burst time remaining
4: high byte of burst time remaining
5+: payload (in my case, 8 bytes)
What sometimes (about 1 out of 50) arrives is something like this:
0: Size
1: target node address
2: also target node address
3: appears to be sender node address
4: unknown, but maybe part of the time remaining -- the value varies
5+: zeroes
I would guess the zeroes were not received, but just what happened to be in the FIFO since it gets cleared when transitioning from standby to rx. How could this happen? Wouldn't the CRC prevent a corrupted message?
One possibility I thought about is that when sending the burst, we put the radio into TX and then write our stuff into the FIFO. We wait for the FIFO to clear (indicating it was sent), then write the next message, never leaving TX mode. The default TX condition from RFM69 is RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY, which should mean that the radio can begin processing the FIFO as soon as it is not empty. This is probably wrong for our burst case, since we could still be filling it. I changed it to use RF_FIFOTHRESH_TXSTART_FIFOTHRESH during the burst, with a value set appropriately for the message size, but that didn't seem to help my issue here.
I also thought maybe we're reading the FIFO when it is in the process of being cleared. The listen mode code uses RF_LISTEN1_END_10 currently, which means listen mode stays enabled when a packet is received, and we have the duration of the idle period (about 1s for me) to retrieve the message before it gets cleared during the next RX period. It looks like RF_LISTEN1_END_01 (which disables listen mode after PacketReady or timeout) is actually more appropriate for us, since we normally abort listen mode immediately upon waking up anyway. Changing to that mode seemed to somehow break listen mode, though -- I could only receive two or so packets before it stopped working. It looks like we exit the irq handler and then nothing happens (CPU goes back to sleep?).
Anyone have other ideas?