• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 53 subscribers
  • Views 3052 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1200: CRC Errors in Received data packets.

Christopher Ingraham
Intellectual 1000 points
Other Parts Discussed in Thread: CC1200

Hello,

I have an application where I'm trying to maximize data throughput.  One radio sends a packet, the other radio, upon reception will send a small "ack" packet back to the first radio which will then send the next data packet.  Both radios are configured to return to RX mode after either receiving a packet or sending one (RXOFF and TXOFF modes are configured to go to RX).  I tend to see CRC errors in about 1 to 2% of my packets.  Typical large data packets are 126 bytes long including the 2 appended status bytes (RSSI and CRC_OK/LQI bytes).  The system has builtin buffering and can tolerate some number of back packets.  However, periodically, I am seeing prolongs sequences of CRC errors, i.e. 30 to 40 packets in a row.  My system cannot tolerate this many bad packets.  So, I have a couple of questions:

1. Is it normal to expect to see 1 to 2% CRC errors in packet transmissions.

2. What could be causing the prolonged periods of sequential CRC Errors in packets.  Normally I'll see one or two, but every now and then, I see 30 to 40.  Is there some specific recovery mechanism that should be used to "reset" or recover from a CRC Error?

Best Regards,

Chris.

  • 0
    TI__Guru* 86071 points

    Hi Chris

    If you periodically see long sequences of CRC errors, this could be caused by an interferer operating at the same or a nearby frequency. For debugging you can try another frequency and see if this helps. You can also investigate the packets with CRC errors to find out if it is single bit errors in the packet or if the complete packet is corrupted. If it is single bit errors, it might be worth trying to enable FEC.

    BR

    Siri

  • 0 in reply to Siri
    Intellectual 1000 points
    Hello Siri,

    Thank you for the quick reply! It is difficult to know if it is a single bit error since the data being transmitted is a compressed data signal that is highly variable. I guess for debugging I could try sending a fixed pattern to see if the CRC errors persist. Eariler in my development of this application, I found it necessary to turn on data whitening in order to pass the packets as reliably as the are now. In my initial development I found very large numbers of CRCs even with fixed packets when data whitening was off. I duplicated this problem using RF Studio and the TI Eval boards. The the particular data packet I was using, I would get large numbers of CRC errors without data whitening. With whitening, the CRC errors dropped to almost zero. Would you expect the data packet contents to make CRC errors more or less likely, even when data whitening is on?

    I can try running my system on a different frequency or in a different band altogether to see if it affects the behavior. Thanks for the suggestion.

    Best Regards,
    Chris.
  • 0 in reply to Christopher Ingraham
    TI__Guru**** 317180 points
    What is your FREQOFF_CFG setting and what was your packet content before whitening?

    From my experience whitening or not should have limited impact on packet errors on CC1200.
  • 0 in reply to Christopher Ingraham
    Intellectual 1000 points
    Hello Siri,
    I changed my system to use a different base band configuration. I had been in the 920mhz base band and move to the 868mhz. I am seeing the same bursts of CRC errors every now and then. So changing the frequency had no effect. I will investigate the crc errors to see if I can determine if there are only single bit errors or more extensive damage next.
    Thanks again for your help so far...

    Best Regards,
    Chris.
  • 0 in reply to TER
    Intellectual 1000 points
    Hello,

    The tests that I am conducting are based on two configurations from RF Studio. The "Symbol rate: 500ksps, 4-GFSK, max throughput, ETSI Standard (868MHz)" and "Symbol rate: 500ksps, 4-GFSK, max throughput, ARIB Standard (920MHz)". In both of these configurations, the FREQOFF_CFG setting is 0x23. So, that is what my FREQOFF_CFG register setting is.

    As far as the packet content before whitening, during my testing I believe I was using the following test packet:

    4f 00 01 02 f8 00 34 02 11 11 22 22 33 33 44 44 55 55 66 66 77 77 88 88 69 69 69 69 69 69 69 69 69 69 69 69 69 69 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 a5 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 96 96 96 96 96 96 96 96 96 96 96 96 96 96

    In my test it was like night and day. With whitening on, no CRC errors. With Whitening off, all kinds of CRC errors. The whole reason I even looked into the whitening setting was that I couldn't get the RF Studio comms through the TI Eval boards to generate CRC errors when I let RF Studio pick the "random" data to send. It wasn't until I started sending the exact same data packet that I was sending in my application that the CRC errors were registered in RF Studio. Then, I decided to try data whitening and that cleared the errors.

    Best Regards,
    Chris.
  • 0 in reply to Christopher Ingraham
    TI__Guru**** 317180 points
    The reason I asked about the FREQOFF_CFG setting is that I have seen before that FREQOFF_CFG=0x23 solves some CRC problems for a lot of different packets. I replaced the content of your packet from the first 0x69 with only 0x00 repeated 36 times and I get no CRC errors. In your case it looks like a repeated 0x69 pattern causes the CRC errors. It looks like an alternating 0101 pattern using only the inner symbols cause a problem. Since whitening removes repeated patterns I suggest you use this. That said it's not often a real packet will have more than 0x69 reppeated in a row.
  • 0 in reply to TER
    Intellectual 1000 points
    Hello,
    I really appreciate you taking the time to duplicate this error. When I did the test, I found that it wasn't necessarily the 69's that were causing the problem as much as the "depth" into the packet, but I could be remembering it wrong. The reason I picked the 69, A5, 5A, and 96 patterns were because of the alternating 1's and 0's. It seems to me that "in the air", the sequence of 69s and a 96s would look identical after a 4 bit shift. This experiment confirms my suspicion that the CRC errors can be cause by data dependencies. In my application, I try to send a packet and if I get a CRC error, I try to resend the same packet. If the data in that packet somehow make it more susceptible to a CRC error, then re-transmitting the same data will a higher likelihood of causing the same CRC error. I have no control of the signal that is being passed through my system at any given time, so I cannot say with certainty that I wouldn't get repeated bytes.
    Since you have the test setup handy, it would be interesting to see if it is actually the 69s or the location of the 69s in the packet. Perhaps switch the order of some of the bytes in the sequence to see if the CRC errors persist. (i.e. change the 69s and the A5s.)

    Thanks again for looking into this. It really is a problem for me at the moment and I'm not entirely sure how I can get past it.
    Best Regards,
    Chris.
  • 0 in reply to Christopher Ingraham
    Intellectual 1000 points

    Hello TER and Siri,

    Well I think I've moved past this issue of CRC problems that appear to be data dependent.  From what I can tell, the data whitening algorithm always "resets" as the start of every packet.  So, if I send the exact same packet data (even with whitening turned on), the "over the air" data will also be the same.  Albeit, whitened, but the same each time.  So, I decided to add my own "XOR" to my data packet that would ordinarily be zero.  (i.e. a no-op).  In the event that my receiver detects a CRC error, it will reply to the transmitter with a NAK packet.  This will cause the transmitter to resend the troublesome packet, but this time apply a different XOR value for the data payload.  Therefore, if there was something in the first version of the packet's data bit sequence that made it more susceptible to CRC errors, the next packet will contain a completely different bit sequence which in theory won't have the same bit sequence.  With this minor tweak to my data packet processing algorithm, I totally eliminated sequential CRC errors in my testing.  I still get the occasional CRC error (51 out of 20590 packets) but I never get two CRC errors in a row.

    Thanks for your help on this.  I am surprised that I could actually hit upon data payload sequences that would repeated generate CRC errors, but it is what it is.  This minor change seems to have cleared the problem for now.  I'll let you know if the CRC errors resurface, but for now, I guess I'm going to close this thread.

    Best Regards,

    Chris.

  • 0 in reply to Christopher Ingraham
    TI__Guru**** 317180 points
    Thanks for sharing. This is the first time I have experienced that CC1200 has issues with receiving a given packet. It is also probably tied to the datarate/ modulation since a high datarate 4-FSK demodulation is less robust than a low datarate 2-FSK.

    It sounds like your system should be robust now. Please let us know if you get some other issues.