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 seems to get a large number of CRC errors.

Other Parts Discussed in Thread: CC1200

I have an application where I'm trying to send large packets of data (124 bytes including the packet length and device address byte).  I have written my application to be tolerant of crc or dropped packet errors.  However, from time to time, I get a long sequence of CRC errors from which my application cannot recover.  I've looked at the RSSI and LQI bytes that are appended to the data in the fifo both when the packets arrive error free and when the CRC failures occur.  I can see no significant difference in the RSSI and LQI values being reported.  Is there some other reason that the CRC errors would occur.  I looking for ideas for how to debug this a little more.  The application is simply written where one board will transmit the large data packet, the receiver looks at the packet and will then send and ACK or NACK back to the original board based on whether the received packet had a good or bad CRC indication.

Any clues where I should look to get to the bottom of this?  Even when my application is successfully able to transmit all the data it needs to, there are still about 1% CRC errors detected in the data stream.  That seems high to me.

Thanks in advance for your help!

Chris

  • The number of CRC errors in a real world setting is dependent on how much noise/ other traffic it's on the air. You can try a different frequency to see if this help.

    With a signal some dB above the sensitivity limit you should get 0 % PER. You are not saying anything about bitrate/ RF settings and which RSSI you see so it's not possible for me to know what you should expect.
  • Hello,

    Thanks for getting back to me so quickly.  The RSSI values I'm seeing appended to the data in the fifo are in the range 0x20 to 0x27.  The LQI values range from 0x00 through 0x06 although most of the time the values are either 0x00 or 0x01.

    As far as the Bit rate goes, I'm effectively using the "Max Throughput Symbol rate:  500ksps, 4-GFSK, ETSI Standard (868Mhz)" config from RF Studio.

    I can provide you with the complete register configuration setting list if that would help.  If you would like to know specific register settings that would affect the ability to get to a 0% PER, I could supply you with those values as well.  Please let me know what you would prefer to see.

    Chris.

  • The 500 ksps/ 4-GFSK setting is a bit more sensitive to noise etc than the other settings since it's using the maximum datarate the chip is capable of. Is 500 ksps your target rate or is it just for testing?
  • Hello,

    The 500ksps/4-GFSK setting is a requirement of our application.  In fact, I wish I had double that throughput, but I have to live with the current max.  I've seen other posts that indicate it is possible to get error free transmissions at that data rate (PER = 0%).  Just as more information, as I said, I'm using virtually all the register settings that are output from RF Studio for the configuration I indicated.  The only changes I've made are to the following:

    CC120X_WOR_CFG0 = 0x20

    CC120X_WOR_EVENT0_MSB = 0x03

    CC120X_WOR_EVENT0_LSB = 0xA5

    CC120X_FS_CFG = 0x02

    CC120X_RFEND_CFG1 = 0x3F

    CC120X_RFEND_CFG0 = 0x30

    CC120X_IOCFG0 = 0x06

    Then on the board transmitting the large packets I set

    CC120X_IOCFG2 = 0x02

    That's really it.

    What I find odd is that about half the time I get around 1% or 2% failures due to CRC errors.  The rest of the time, i get almost 100% CRC failures.  It's almost as though the radio gets itself into a latched condition where all packets are CRC errors.  Interestingly, whenever I've looked at the received data that I read from the FIF0, the beginning of the packet looks valid.  The data starts falling apart the further I look in the data buffer.

    Thanks again for helping with this.

    Chris

  • I've been trying to debug this. I couldn't remember why I had turned off the FS PLL Lock Detection (FS_CFG = 0x02) so I decided to re-enable it and assign the LOCK status to GPIO3. I noticed that when I serviced my Packet Receive interrupt the status was 0, or "Out of Lock", 167 times out of 20143 packets received. Of all those packets received, 701 had CRC errors. Is the PLL Lock/Unlock status something that should concern me?
  • Hi

    Since you are changing the settings shown above I assume you use RX Sniff mode and you also have a two-way protocol since you are using TXOFF_MODE = RX.

    The first thing I would suggest that you start by testing the RF performance. You should then use ordinary RX and have both off modes set to IDLE. The link should be one-way only.

    If this works as expected, you know that your HW is good and that the RF is good. You can then start to do changes to your protocol. Start by implementing Sniff mode. If the timing is set up correctly, the performance will be just as good as it is with ordinary RX, but the current consumption will be lower. When this is also OK, you can implement your two-way protocol.

    I’ll leave it to someone else to comment on the lock issue.

    Siri

  • You should not get out of lock in normal operation. Do you change frequency or start Rx/ Tx without doing a SCAL/ auto calibration at some point ?
  • No, I should be executing the SCAL anytime the radio is reconfigured and before I attempt RX or TX mode.  A little background:  My application actually transitions through 3 distinct radio configurations.  I start using the setup that was presented in the smartpreamble example to wake up my "sensor" unit. Once this is successful, I transition to a "Symbol Rate 200ksps, 2-FSK, ETSI Standard (868Mhz)" configuration to exchange some configuration and status information between my two boards.  Once this is complete and the system is ready to start streaming information, I transition to the high data rate setup I've previously described.  Each reconfiguration begins with a reset of the radio, followed by a configuration and verification of all registers, a command to idle (which is probably redundant), the SCAL command, a wait for MARCState to be 0x41.  Once all that has completed, I command the system to enter RX mode.

    The SCAL was the first thing I suspected so I ran through and double checked that and have verified that it does occur in all cases.

    What would be the main causes for the PLL to fall out of lock? 

    Thanks,

    Chris.

  • Sorry for the delay. Have you managed to get any closer to why you have some problems?

    For the VCO to be out of lock:
    - Hardware: wrong component values, typically the external cap in the loopfilter
    - Settings: The recommended settings for the FS_x registers are not set correctly.
    - Calibration

    From your description it sounds like thing are correct. If you run the code found here: processors.wiki.ti.com/.../Category:Sub-1GHz with the 500 kbps settings exported from Studio, do you see the same issue then?

    Do you have access to a spectrum analyzer you can use to look at the spectrum?
  • Hello,

    I made a mistake.  It turns out the PLL is NOT falling out of lock.  I was mistakenly trying to use GPIO3 to indicate the PLL Lock state and it turns out that is not a valid configuration option of the IOCFG3 register.  Once I "fixed" this to use a valid configuration for a GPIO pin, I saw that the lock was in fact stable.  So unfortunately, that is not the clue I thought it would be.

    So, I took Siri's advice and tried more simple tests to verify the hardware.  What I did was to configure my board as a packet transmitter to send a simple packet of known contents that happened to be 80 bytes or so in length.  I then used the TI TrxEB with a CC120xEM 868/930 module installed and connected it to RF Studio 7.  I used RF Studio to configure the TrxEB to use the "Symbol Rate 500ksps, 2-FSK, ETSI Standard (868MHz)" configuration.  I installed the same configuration on my hardware.  When I run my hardware and set the RF Studio into Packet RX mode, I can see packets arriving that look good.  The reported average RSSI value is -6.9dBm and there are no Packet errors.  All packets are received OK.

    I then tried the "Symbol Rate 500ksps, 4-GFSK, max throughput, ETSI Standard (868MHz)" configuration and ran the same test.  Now, all packets fail with CRC errors.  Interestingly, the packets all look good for the first 30 to 34 bytes.  Then there are random bit errors.  It seems like the further into the packet, the more errors are observed.  This configuration yields 100% packet failure.

    Does this testing give any additional clues as to what may be wrong in the hardware and/or what register manipulations I might be able to try to work around or fix the issue?

  • Hello,

    I've been doing a lot of analysis and testing here trying to determine what's going wrong.  I decided to reduce the unknowns in the system by totally removing my firmware from the equation.  I was able to build a wiring harness that enabled me to connect my CC1200 RF section to the TrxEB P7 Header.  Once I did this, I was able to use RF Studio, connected via the USB to control my CC1200 radio module.  I noticed that when I ran the normal Packet TX or RX on my board to the corresponding Packet RX or TX running on the stock TrxEB with the TI CC120xEM 868/930 module that I was able send and receive packet error free at the desired configuration of "Symbol rate: 500ksps, 4-GFSK, max throughput, ARIB Standard (920)".  This was very good news as I had not yet seen error free transmissions or receptions at this speed from my radio module.

    So, I decided to change the configuration from the normal "Random" setting to "Hex" and specify the exact packet data that I've been trying to transmit without success.  Once I tried this, I got continuous CRC errors!  I went back to "Random" and everything worked again.  I copied the "Random" data to the "Hex" data window and still everything worked.  I then put my packet back into the "Hex" window and sure enough I got continuous CRC errors!  I decided to try turning on the "Whitening" to see if that would help.  Once Whitening was enabled, the packets with my data were now error free.  That's pretty amazing to me that the data Whitening would make that much of a difference, but it appear to.

    Given this information, I decided to try my code again.  I exported the register settings from RF Studio for the config I mentioned above, but with Whitening enabled as well.  When I ran my code, which simply transmits my data packet once ever 200ms, I was now getting 75% success and 25% packet errors with CRC errors.  This was much better than before, but something was still wrong since under RF Studio control, my radio was able to send 100% error free data to the TI Radio.  I decided to look deeper at what RF Studio was doing to the CC1200 radio configuration when it actually sent a packet.  So I switch back to RF Studio Control of my radio, chose the "Symbol rate: 500kbps, 4-GFSK, mas throughput, ARIB Standard (920Mhz)", enabled whitening, and then sent one packet of my data.  I then did a "Refresh" of the registers and then exported the result.  I found that the following registers were modified from the base config:

      {CC1200_FS_CHP,            0x2A},
      {CC1200_FS_VCO4,           0x13},
      {CC1200_FS_VCO2,           0x64},
      {CC1200_FS_VCO1,           0x9C},
      {CC1200_LQI_VAL,           0x80},

    So, I took these register settings, added them to my code, and fired up my application.  I now had 100% error free transmissions to the TI Radio Module.

    So, my question is why?  What is RF Studio doing after the initial register configuration is sent down that causes those 5 registers to be changed.  I've run my test several times, and those 5 registers are always changed the same way after one packet has been sent from my radio board.  How is RF Studio coming up with these values?  Is this the result of an SCAL operation?  Or is it something else.

    Any insight you can offer into this would be greatly appreciated!

    Thanks in advance,

    Chris Ingraham

  • FS_CHP, FS_VCO4, FS_VCO2, FS_VCO1 contain the results of the VCO calibration. I assume you either issue a SCAL strobe or use auto calibration in your code?
  • Yes, I use the SCAL command. My procedure is to reset the cc1200, write all registers as provided by rf studio, verify all register values, command to idle, issue SCAL, Wait for return to idle.  Then proceed with my application code.  What is missing?