CC1120 - RX transparent mode problem

There will always be some 'jitter' on the output datastream in transparent mode because the input is not in sync with the internal clock and hence it will be a finite resolution on the output given by the internal clock rate.

This could be seen if one GPIO is set to 0x09 (data) and one GPIO is set to 0x08 (serial clk). The serial clock is equal to the internal clock and the data changes on falling flank of the clock signalas shown in the attachement. 3348.transparent_intfact=10.TIF The resolution could be increased (jitter lowered) by setting MDMCFG0.transparent_intfact higher than default. 

Is it possible for you to oversample the datastream to sync it to your system/ why does the jitter cause problems?

Thanks for the reply,

The issue I experienced was actually solved (and not related to the jitter) once I got my hands on the updated user guide (until now I've been working with a early NDA version). The application (frequency hopping) requires rather fast frequency change and switching between RX/TX. Is there any specific register and or procedure that can improve this performance?

Currently I'm doing the following to change frequency (auto calibration is turned off):

commandStrobe(0x36); // SIDLE

/*writing new values to CC112X_FREQ0-2 registers here*/

commandStrobe(0x33); // SCAL

while( (commandStrobe(0x3D) 0xF0) != 0x00);

/*enter RX or RX with commandStrobe(0x34) or commandStrobe(0x35) */

For this application it's not possible to pre calibrate the frequencies.

As long as you can't pre-calibrate it is not that much you can do to decrease the time. Please also read the errata note for CC1120 because this contains information on how you should do calibration for this version of the chip.

Thanks for the reply,

with regards to the errata calibration procedure, in my application there is really no time to perform the number of operations listed in the errata. Will the calibration always fail for future calibration attempts if it fails once? It would be acceptable to every once in a while fail to calibrate as long as it is recovered on the next calibration attempt.

Does the calibration issue also occure when performing the SFSTXON strobe (with AUTOCAL = 1)?

Is there any ETA on when the calibration issue will be fixed?

The calibration could fail n times in row. Without following the errata procedure you will not know if the calibration succeeded or not. The bug is independent of AUTOCAL. The bug is straight forward to fix in hardware but no official timeline is available.

Why is it not possible to do some pre calibration to get around the problem?

The CC1120 is in this application used to replace an exsisting descrete radio solution where backward compability must be ensured, it is not possible to change application software or logical hardware. To solve this we use a stand alone radio PCB with an MSP430 acting as a translator, translating control information sent to the PLL of the exsisting descrete radio and translating this to the CC1120.

As the radio frequencies used vary from product to product it is not known in advance which frequencies will be used. The start up time is also rather critical as well as the RX/TX/frequency change time as a delay is already introduced due to the translator, and the exsisting PLL has locking times comparable to the CC1120. The product is naturally not restarted and as temperature will vary it is really optimally to perform calibration on each frequency change.

The errata states there is a "finite possibility" of calibration failure, do you have any statistics regarding the term "finite". Our application is not really affected if this happens in the range of 1 out of every 100 calibration attempts, as long as not too many (5-10 would start to cause issues) consecetive calibration attempts fail.

The probability for calibration failure is dependent on various factors and we don't have the statistics for all cases. Please keep in mind that if the calibration fails the chip will try to transmit on ~700MHz when in TX which could cause problems with regulations. Also you can risk that the calibration fails several times in a row.