RX FIFO Overflow

Just to add more information:

1. The CC1101 is configured to return to RX mode after TX or RX.

2. After I get the overflow, I read the data and it seems very random. Not something which I might have sent from other transmitter.

3. After getting the overflow, I clear the buffer and it returns to 0.

See bewow example for printout.

• First parameter is mode (dec)
• Sewcond parameter number of bytes in fifo
• Number of packets received.

d[ 56352]: RX 13 0 0
d[ 57459]: RX 13 0 0
d[ 58566]: RX 13 0 0
d[ 59672]: RX 13 0 0
d[ 60779]: RX 17 65 0
d[ 60780]: 175 255 204 219 242 73 253 173 118 173 202 183 90 93 234 171 57 208 169 222 239 202 229 108 103 136 215 38 213 166 119 69 252 245 42 255 56 231 171 95 39 119 183 109 101 15 88 138 19 175 213 208 223 223 232 189 120 101 162 81 39 6 172 23
d[ 60800]: RX After Flush 0
e: 11 to RX
d[ 61885]: RX 13 0 0

It sounds like you are receiving a lot of false sync words that eventually fills up your FIFO with noise causing the RXFIFO to overflow. You can verify this by monitoring signal 0x06 on one of the GDO's.

Please read section 17 of the userguide on how to reduce the likelihood of false syncword detections

Hi Martin,

Thx for your reply.

I will try to change the sync word settings and see if it helps.

My current settings are SYNC WORD 0xB527 and MDMCFG2 0x12.

Lets assume that this is the issue. I want to stay with 16 bit SYNC WORD. How can I redunce to minimum the false detections? Should I change the SYNC WORD itself?  Use other sync word quilifier settings? 

Thx

Martin,

Also, assuming that I will stay in 16 bit SYNC WORD, what is the best way to identify sync detection and discrad the false received data?

Thx

Hi

Try to change the PQT. This adds the requirement that a syncword has to be preceded with a good preamble to be valid. You can also gate the syncword with Carrier Sense which is also described in chapter 17 of the user guide.

To discard any unwanted packets in the RXFIFO you can enable the CRC_AUTOFLUSH feature which will flush any packet with a bad CRC check from the RXFIFO. 

Can you please help to explain what is the meaning of 4PQT?

" ... A threshold of 4∙PQT for this counter is used to gate sync word detection. When PQT=0 a sync word is always accepted"

Which threshold I should use? Does it mean I need to put 4 in those bits?

Also, just to be sure,

If I already have a packet in the FIFO and packet with CRC error received, the FIFO will not be flush. Am I right? Is it the same for CC1200? Will I be able just to flush the bad packet?

Thx for your help

Hi

ECH12 said:

Which threshold I should use? Does it mean I need to put 4 in those bits?

The preamble quality estimator increases an internal counter by one each time a bit is received that is different from the previous bit. If you have 2 byte of clean preamble you will have at least a score of 15 on the internal counter. The threshold is set by the PQT register field value times 4, so if PQT is set to 3 the threshold will be 12. With a good two byte preamble the counter will be above 12 and a following sync word will be accepted. However if you have a bit error in the preamble the score will be reduced by 8 so then a following sync word will not be accepted if the PQT is set to in this case 3.

The threshold you should use is dependent on the environment you are working in. This is a matter of finding the optimum PQT value which will eliminate false syncwords, but not rejecting actual packets by having a to strict PQT.

ECH12 said:

If I already have a packet in the FIFO and packet with CRC error received, the FIFO will not be flush. Am I right? Is it the same for CC1200? Will I be able just to flush the bad packet?

The CC1200 and CC1101 are different in the way the autoflush works. You are right that the CC1200 will only flush the packet with the bad CRC, however the CC1101 will flush the entire RXFIFO so it assumes that the bad packet is the only data in the FIFO.

Hi Martin,

Thx for your help!!! After setting the PQT I don't get the overflow issue anymore. 

One thing I don't understand is why I got it from start. If the issue is with the preamble, receiver still need to match the SYNC WORD before adding data to the FIFO. Am I right? If so, how is it possible that the SYNC WORD match passed? (Note that I also have address check).

Also, 

I want to use 16 bit SYNC WORD, are there any guidelines for selecting the value for the SYNC WORD?

Thx

Eyal

Just a comment to your first post. This looks like the RXXFIFO OVERFLOW issue described in the errata note.

BR

Siri

Hi Siri,

I've read the errata but I am not sure that my case is the same. Maybe I am reading the wrong one. I will appriciate if you can point me to the section which describes the issue.

Thx

Eyal

I was referring to the RXFIFO_OVERFLOW issue described here: http://www.ti.com/lit/swrz020

But I just realized that this is not relevant. I was thinking that you were stuck in RX state, but as long as the chip reports FXFIFO_OVERFLOW, it is not this bug you encounter.

It is not possible for the radio to enter this state unless a sync word has been received, so there must have been packets that has not been handled or.

Make sure your FIFO is empty before strobing SRX (the FIFO must only be flushed from IDLE state or OVERFLOW/UNDERFLOW state).

If you use append status remember to read these bytes after the payload. If not, 2 bytes will be left in the FIFO for every packet received, and after a while the FIFO will be full.

Siri

Hi Siri,

You can see from my printouts that the FIFO  is empty and suddenly it filled up with data although nothing was sent. I am using the payload and it is being read so this is not the issue.

Is it possible that somehow the sync word was matched?

Eyal

Hi

You can check if the radio detects sync word by monitoring signal 0x06 on one of the GDO's. Then you can verify if you receive sync words despite you are not transmitting.