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.

LAUNCHXL-CC1310: External calibration of the RF Crystal Frequency

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1101, CC1070, CC1310, CC1021

On earlier generations of the CC1xxx radio transceiver parts (i.e. CC1070, CC1101, etc.) we have made use of the ability to output the RF crystal signal (divided down by a pre-scaler) on one of the GPIO pins.

During our manufacturing process we measure this frequency to determine the "zero point" frequency error of the crystal, which we use together with an estimate of the temperature error to calculate the frequency value to program into the part that will produce the desired RF output for a multi-channel FHSS system.

How should I replicate this operation on the CC1310 part? The RF crystal output is not one of the values available (as far as I can tell) for the RFC_GPOx signals.

Since the radio crystal is also shared with the main CPU, I could use the 24 MHz crystal as the system clock and then use a timer module to generate a PWM output on one of the GPIO pins. Is this a reasonable approach?

My goal is to measure the frequency error with a resolution of 0.1 ppm and an accuracy of better than 0.5 ppm. I want to be sure that the PWM output of the timer module does not add any distortion of the crystal timing that would take me past these limits.

  • Edward,

    Yes, I would recommend just using a timer. The only catch is that you have to make sure that you force the RF to remain on during this test. I think the simplest way to do this is go configure the radio for RX mode and then for a frequency that you will not get a packet. Now that the RF is on the MCU should switch to the 24MHz (but if does not, you might need to force that also)

    Regards,
    /TA
  • Edward,

    But an other simple way to do this is to just look at the frequency error on the RF output, because you know what you programmed the PLL to do and therefore a simple frequency counter can look for the TX tone and you can easily count it...

    Regards,
    /TA
  • I use this method (measuring the RF output frequency) for "informal" prototype testing, but for production testing we prefer a method that does not does not involve direct RF frequencies due to the testing being both susceptible to and a source of RF noise. Another advantage is we can perform the test on stuffed PCBs without having to attach an antenna, saving labor costs.

    We do perform end to end functional testing, including AFC and RSSI verification, before we box our products, but more as a qualitative "does it work" test, not as a calibration test.

    As long as the internal gating of the timer modules don't add too much distortion, I am sure I can figure out how to make sure we are measuring the correct clock source.

    Thank you.

    Ed

  • Which datarate/ RX BW are you using in your system? The reason I ask is that I wonder how much you gain by testing the frequency offset in production.
  • Data rate is 19.2 kBaud.

    GFSK Deviation is 9.9 kHz

    RX Bandwidth is 51.2 kHz

    These are figures from our product that uses the CC1021/1070 radio transceivers. Our new products must be able to receive the same radio modulation format from existing devices in the field.  

    We have traded off a narrow receive BW for noise rejection against tolerance of frequency error between the transmitter and receiver. This requires us to take steps to remove the easily testable and correctable sources of frequency error.

    We have successfully done the port to the CC1101/1150 chips, so I have every reason to expect to be able to also support the CC1310.