RTOS/CC1310: Frequency shift self compensation

For the center frequency:
If you open SmartRF Studio and go to the Tools menu in the upper right corner, click on the "SmartRF Test Environment". In the RTlib it should be an example on how to measure frequency offset.

The question is how to use this information. For an application using prop commands the offset could calculated in to the frequency given to the CMD_FS. In the BLE stack the parameters to this command is more hidden. You can as an a different option modify the load cap array. If you have a table given for the xtal/ board you are using that setting the array one value up or down equals x Hz you can look up in this table and see what you have to set the array to in the CCFG area.

How exactly can i find this example?

And any information about Amplitude compensation control?

From 4.2 in www.ti.com/.../swra495f.pdf : "TI intends the amplitude control loop to regulate the amplitude of the oscillations of the crystal for optimal performance".

Do you actually have a need to try to regulate the amplitude?

For the example, see the doc folder in the test library after you download it for usage.

As i mentioned in first post, when we measured 24MHz in custom crystal oscilator it has different amplitude which depended on marking. Is it possible measure and regulate amplitude instead of dynamic tunning of caparray?

Thank you i found it.

Does the different amplitude have a practical impact?

Based on this measurement it has direct connection between amplitude and frequency shift in transmitted spectrum.

A shift in amplitude will not shift the frequency. But the frequency will change from xtal to xtal and from batch to batch. I get the impression that you measure a frequency shift that is within the spec of the xtal. Do you actually need to do an initial calibration of the xtal?

Ok i'll try to describe it again. We constructed crystal oscilator with two different markings of this crystal. Measured frequency which was pretty precise (less than 10ppm), then we measured amplitude of these two markings and there was difference almost 40%. It leads to different internal capacitance of these two markings and it leads into problem in our device because of different load capacitance is needed. We measured more than 15kHz frequency shift in final 2FSK spectrum on CC1310 radio with these crystals and cap array needed to be adjusted.
Summary:
Amplitude difference in 2 crystal markings (same PN) leads to internal capacitance difference leads to frequency shift in final spectrum.
Because of that i think we need amplitude compensation.

"We constructed crystal oscilator with two different markings of this crystal. Measured frequency which was pretty precise (less than 10ppm"

Does that mean you designed a test setup that does not involve CC1310 to measure the xtals?

yes

Not sure how relevant the results from your test setup are. The test setup will have give a different Cload compared to when placed on a PCB with CC1310 and the amplitude control will be different since the CC1310 monitors and control the amplitude of the xtal.

Do I understand you correctly that you see 15 kHz delta if you place xtals from the two different batches on a CC1310 based board? But you see a smaller delta if you use you test setup and measure the same two xtals?

What does your test setup consist of?

1) Our board with CC1310 with different batches different frequency shift (we tried more then 2 batches of the same xtal). This shift was measured on 868MHz spectrum.
2) Xtal from different batches needed to be tested so we did. We created crystal oscillator and measured two different marking on the same board with same setup, frequence was precise, amplitude was not. Amplitude was only difference between these two crystals. It leads to some difference between markings on CC1310 pcb and on custom pcb for measuring xtals, its hardly coincidence.
3) so you think that it is not possible to contol amplitude and compensate this problem?

As according to 4.2 in www.ti.com/.../swra495f.pdf states the xtal module on CC13xx does amplitude control.

Have you measured the amplitude for the two batches with the functions described in the start of chapter 8 of www.ti.com/.../swra495f.pdf

Have you tried to compensate for the frequency shift using the cap array based on the frequency offset you read out?

And my i ask you, where can i set this amplitude control manually? (if it is possible)

We did and it returns different numbers for xtals from different batches.
Results:
1. batch:
420 - uint32_t OSCHF_DebugGetCrystalAmplitude( void );
465 - uint32_t OSCHF_DebugGetExpectedAvarageCrystalAmplitude( void );
2. batch:
480 - uint32_t OSCHF_DebugGetCrystalAmplitude( void );
465 - uint32_t OSCHF_DebugGetExpectedAvarageCrystalAmplitude( void );

We tried to tune cap array based on offset which we measured on spectrum analyzer and it works properly, we need to find the way to tune it automaticly based on assembled xtal, do you think that is possible?

Could you post a link to the xtal you are using?

I checked some with the xosc module designer yesterdayThe amplitude control loop will try to keep the amplitude between 450 mV and 480 mV hence your first measured value is too low and the other value is on the upper limit. For the low value it could be that you have a very slow xtal and that the control loop turns off before the swing is fully settled. I will check if it's possible to have the loop regulating longer.

A couple of theories on why you are seeing what you see:

If the 2 batches of crystals have different C0, the loading seen by the XOSCHF in CC1310 will be different. Higher C0 will give lower amplitude. Based on some quick math, the difference in amplitude he sees would be explained by C0 varying by 0.7pF from one batch to the other.

Another theory is that the Rm between the different batches could be different. Higher Rm will give lower amplitude. This is harder to estimate without know exactly what crystal is used, but with some assumptions about typical values, this would match up to about 10-15 ohm change in Rm between the different crystal batches.

One other thought is that if you have a correlation between frequency offset and amplitude offset that persists even after a longer settling time is used (this is only going to be the case if the root cause is a C0 that varies between lots), the capacitor array can be adjusted based on the amplitude in software.

We are using Q22FA12800249, Crystal SMD 24MHZ 2x1,6 (FA-128 7PF, 10 ppm). 

Is it possible use longer regulation loop?

It leads to capacitance difference rather then Rm difference between badges. We are communicating with epson and they claim, that we have to have different crystals sold under same PN.

The regulation loop is set in an internal register and is therefore not easily accessible for customers. Have you tried to adjust the cap array based on frequency offset only?

Yes we did, but this is not a solution when the manufacturer buys new batch of xtals. We cant release new FW with different cap array settings after each batch of xtals bought. Because of that we are trying to solve it in some different way. It happened lately to us, manufacturer bought xtals from different batch a and we didnt noticed and now we have 1000pcs of devices with sfited center frequency.

Since you have two different sets of xtals you would only need two different firmwares and based on the frequency offset you can select which of them you want to use?

The cap array setting is on a given address (part of the CCFG) so it should be possible to use a master hex file and then based on the measured frequency offset you can run the hex file through a script that changes the cap array setting based on a table . If you get a xtal with a different Cload spec than you have designed for it should be possible to set the cap array to a value giving the wanted Cload (as long as the xtal is within the spec given in the datasheet). If the cap array is modified you should probably retest.

It is not acceptable for us, we cant recompile FW for each xtal type. We do not know how will be next batch shifted. I would like to ask you: Is it possible to change caparray while running?