Author Topic: Burst message weirdness with listen mode [solved: bad radio]  (Read 3104 times)

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
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?
« Last Edit: May 26, 2016, 06:34:12 PM by Felix »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Burst message weirdness with listen mode
« Reply #1 on: May 25, 2016, 09:48:45 AM »
Quote
Anyone have other ideas?

The only times when I've seen wrong data arrive at a listen mode client is when I forgot to switch encryption off at the sender.

Quote
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 don't think this is an issue: as long as we fill the fifo faster than the radio sends, it will just push out byte by byte and in the end the calculated CRC. And we have quite a bit of time buffer since the radio first sends preamble etc.

So sorry, I don't have a solution. But maybe knowing that this doesn't happen everywhere helps a bit.

Joe

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Burst message weirdness with listen mode
« Reply #2 on: May 25, 2016, 02:11:04 PM »
Except the way I read it, if encryption is on, then the "fifo" isn't really acting like a pipe.  Instead, it seems as though everything inside the FIFO is either encrypted or decrypted as a unit (albeit in 16 byte blocks):

Quote
5.5.5.1. Tx Processing
1. User enters the data to be transmitted in FIFO in Stdby/Sleep mode and gives the transmit command.
2. On Tx command the Packet handler state machine takes over the control and If encryption is enabled then the
message inside the FIFO is read in blocks of 16 bytes (padded with 0s if needed), encrypted and stored back to FIFO.
All this processing is done in Tx mode before enabling the packet handling state machine. Only the Message part of the
packet is encrypted and preamble, sync word, length byte, address byte and CRC are not encrypted.
3. Once the encryption is done the Packet handling state machine is enabled to transmit the data.

5.5.5.2. Rx Processing
1. The data received is stored in the FIFO, The address, CRC interrupts are generated as usual because these
parameters were not encrypted.
2. Once the complete packet has been received. The data is read from the FIFO, decrypted and written back to FIFO.
The PayloadReady interrupt is issued once the decrypted data is ready in the FIFO for reading via the SPI interface.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Burst message weirdness with listen mode
« Reply #3 on: May 25, 2016, 02:23:22 PM »
Yeah that's the point. If you fill the Fifo while in tx data will get corrupted if encryption is on. You have to fill the complete packet while in sleep and afterwards switch to rx.

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Burst message weirdness with listen mode
« Reply #4 on: May 25, 2016, 02:34:44 PM »
Yeah that's the point. If you fill the Fifo while in tx data will get corrupted if encryption is on. You have to fill the complete packet while in sleep and afterwards switch to rx.

Ah, so that's why we can't use encryption. Hmm. I'm turning off encryption just by setting RF_PACKET2_AES_OFF, but maybe you really do need to clear the key too? That would be stupid.

If we set the FIFO threshold like I described above, we could probably use AES right? I might try that even though it's unrelated to my issue.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Burst message weirdness with listen mode
« Reply #5 on: May 25, 2016, 02:43:37 PM »
You don't need to reset the key. Just switching off the flag is enough. The data sheet explicitly says you need to fill the buffer in standby of sleep with encryption. Although I guess it's worth a try.

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Burst message weirdness with listen mode
« Reply #6 on: May 26, 2016, 12:39:59 PM »
Well the good news is that encryption does seem to work with burst if I set the FIFO threshold appropriately. To make sure, I changed the encryption key on the receiving side and it did not receive any messages. It did generate an interrupt, though, which seems wrong if that is supposed to correspond to PayloadReady. The FIFO was empty in that case.

Unfortunately, my corrupted message issue persists. Ugh.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6522
  • Country: us
    • LowPowerLab
Re: Burst message weirdness with listen mode
« Reply #7 on: May 26, 2016, 01:20:07 PM »
@snorp,
Did you try another radio to see if it's consistent?

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Burst message weirdness with listen mode
« Reply #8 on: May 26, 2016, 03:53:47 PM »
@snorp,
Did you try another radio to see if it's consistent?

I have not, but that's a good idea, thanks.

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Burst message weirdness with listen mode
« Reply #9 on: May 26, 2016, 06:01:33 PM »
@snorp,
Did you try another radio to see if it's consistent?

I have not, but that's a good idea, thanks.

I've received over 1000 messages using another Moteino and no problem so far. Looks like the board is the culprit. Felix, I'm going to update RFM69_WL with the fixes to enable encryption in the burst, and then try to merge those over into your branch of RFM69.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6522
  • Country: us
    • LowPowerLab
Re: Burst message weirdness with listen mode
« Reply #10 on: May 26, 2016, 06:33:54 PM »
Great, so it was a suspected bad radio. Interesting. At least its solved for now.
I can merge whenever I can have time to review/test etc. Thanks for your contributions.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Burst message weirdness with listen mode [solved: bad radio]
« Reply #11 on: May 27, 2016, 02:00:19 AM »
Quote
Well the good news is that encryption does seem to work with burst if I set the FIFO threshold appropriately.

Excellent! That solves the encryption issue not only for listen mode but also for my bootloader. Good work!