The following KBA was written using an EFR32MG14 radio board (BRD4169A) under Flex SDK 2.5.1 (RAIL 2.6), but the process should be the same on all EFRs and all Flex SDKs since version 2.0.
The main goal to share information about what CTune means, and how can it be configured to reach optimal radio link quality. In most cases, this is done through the RAIL APIs. A good starting point is the RAILTEST Application which implements CLI commands to do the calibration. This KBA focuses only to HFXO calibration but the LFXO has its own capacitor bank.
EFR32 devices are equipped with a configurable internal capacitor bank to load external crystals for proper operation and frequency calibration. We usually call the configuration value of this capacitor bank CTune.
This CTUNE value is applied during the startup phase of the HFXO. The following equation gives the relation between the programmed and the real value of the capacitance:
Ctune = Cpar + CTUNE<8:0> * 40fF,
as the reference manual states (EFR32MG14 reference manual), where Cpar means parasitic capacitance, which depends on the board type, the layout, the temperature and the type of the crystal. The internal capacitor size inversely proportional to the frequency, therefore the higher capacitor value lead to lower HFXO frequency.
The CTune is responsible for the quality of the radio link, because it sets up HFXO clock properly which is used for the radio clock as well. This radio clock is used by the synthesizer. Thus incorrect setting may lead to broke a radio link between two devices.
The CTune calibration value can be stored in non-volatile memory of the device. All Silicon Labs modules and radio boards are factory calibrated, and the CTune value is stored on the device information page, while other Silicon Labs radio boards equipped with an external EEPROM which holds the CTune value. For further information, see this KBA for Bluetooth or this KBA for RAIL and Connect.
However, on custom boards, the calibration should be always performed. It is a preferable way to measure 10-20 board's HFXO frequency per design, and get the average CTune value which can be used for all devices. In this way a good enough calibration value can be taken. Obviously the optimal calibration can be done for each board, but it takes more longer.
This KBA focuses on this calibration process. Once an optimal CTune value has been found for a given circumstance (given board, layout, temperature etc.), the above KBAs can be used to store it on the device.
The easiest way to set CTune value is to call the
RAIL_SetTune() API. The first argument is the RAIL handle (similarly to most RAIL APIs) and the second is the CTune calibration value to use. Though the latter is a
uint_32 type variable, the API is only using the lower 9 bits (masking with 0x1FF), therefore the valid range for that argument is between 0 and 511. RAIL API does not reject higher values, it's the application's responsibility to prevent misconfiguration.
Issue the following commands on a device programmed with RAILTEST in order after reset for the initialization of the calibration:
> rx 0 > setPower 1 > getCTune > setCTune <0x[hex-value] or [decimal value]> > setTxTone 1
RAILTEST starts the device in rx mode, therefore first the device should switch to IDLE mode, because the PA Power can be changed in
RAIL_RF_STATE_IDLE state only. The purpose of this step will be explained in the next section. The actual CTunevariable can be read with
getCTune command. Then write over this value, which can be done with the
setCTune command. After the configuration the
setTxTone 1 command sets the radio to transmit mode with CW signal.
For changing CTune value issue these commands:
> setTxTone 0 > rx 0 > setCTune <0x[hex-value] or [decimal value]> > setTxTone 1
This procedure is very similar to the initialization process. After disabling the transmit mode and calling
rx 0 the radio is able to get a new CTune value.
CMU_HFXOAutostartEnable() as its name states enables auto starting after a Wake-up from EM2/3. If this API is called with either of the last two argument as
true, it prevents the restart of the HFXO and therefore the change of the CTune value. Note that this feature is enabled by default in the Bluetooth stack.
The measurements had been done with a spectrum analyzer, and with an EFR32MG14 Radio Board (BRD4169A) at 868 MHz. It's recommended to do these calibrations with conducted RF connection. It is also recommended to use the low power output during the measurements (configured by
RAIL_SetTxPower() API) to avoid calibration drift which is caused by the increased temperature, caused by the current consumption of the PA.
The optimal test signal is the CW signal which can be transmitted by calling
RAIL_SetTxStream() API. For better resolution smaller Video Bandwidth was selected.
The first capture shows the achievable resolution with low capacitance: The frequency is measured with CTune values 0 to 9.
The average frequency step is 1540 Hz in this frequency region.
The resolution is not linear on the full frequency range. That has been showed with the following picture:
Each spike is measured with CTune increased by 50 from 0 to 250.
After learning the general configuration possibilities it's possible to find the optimal CTune value with an iterative approach. Set the marker to the desired frequency (in this case it is 868 MHz) and change the CTune value until the radio transmits at this frequency. In our case the optimal value was
317 (The factory calibration was
322). The third picture shows the the optimal calibration with the neighbor values.
With a higher transmission power the optimal value is harder to find, due to chip is warming up affecting the crystal's resonance frequency. The above picture captured with "max hold" mode during 2 minutes when higher transmission power was applied. It is shown that the frequency drift was 0.5 KHz, which could result inaccurate calibration.