Summary
TI’s millimeter wave radar sensors include an internal processor and hardware architecture that enables self-calibration and monitoring. Calibration ensures that radar front-end performance is maintained over temperature and process variations. Monitoring can periodically measure RF/analog performance parameters and detect potential failures.
This application note provides a brief introduction to the calibration and monitoring mechanisms, focusing primarily on the software configurability of the calibration routines run by the internal processor.
Abbreviation
APLL Analog Phase Locked Loop
BIST Built-in Self-Test
CLPC Closed Loop Power Control IFA intermediate frequency amplifier IF intermediate frequency HPF high-pass filter
DFE digital front end LO Local Oscillator LPF Low Pass Filter LUT Lookup Table a> VCO voltage controlled oscillator PA power amplifier OLPC open loop power control
1 Introduction
TI’s millimeter wave radar sensors include an internal processor that runs calibration routines to stabilize radar front-end performance across temperature ranges and processes. The processor also enables functional safety of the sensor by periodically determining RF/analog performance parameters and detecting functional failures (by running monitoring routines). The processor is programmed by TI specifically for RF calibration and functional safety monitoring.
This document describes the various calibration mechanisms available in TI millimeter wave radar sensors and their configurability.
1.1 Calibration purpose
Figure 1-1 shows the radar front-end architecture in a TI millimeter wave radar device. Performance parameters of the RX LNA, IF amplifier, TX PA, X4 (multiplier), LO distribution buffer, and clock sources shown vary with process and temperature.
Figure 1-1. Radar front-end architecture in TI mmWave devices
Figure 1-2 illustrates the calibration purpose using RX gain and TX power as examples. The gain of the RX LNA and TX PA varies from device to device due to manufacturing process and temperature variations. The purpose of calibration is to ensure that RX gain and output power are maintained according to user configuration, despite process and temperature variations. To achieve this, an internal processor adjusts the mmWave circuit configuration both upon initialization (to mitigate the effects of process variations) and periodically during runtime (to mitigate the effects of temperature drift). Figure 1-2 shows how calibration can be used to maintain RX gain and TX power close to configured settings over temperature drift. These graphs are for illustrative purposes and may not reflect actual device performance. Even when these calibrations are completed over temperature, there will be some gain differences between devices, which must be accounted for in the user application.
Figure 1-2. Calibrated and Uncalibrated RX Gain and TX Power
These are representative images of TI’s first generation radar devices. Adjust the circuit configuration to achieve some calibration (e.g., gain and power calibration) based on RF/analog parameter measurements. Adjustments are made based on process/temperature lookup tables for additional calibrations.
1.2 Purpose of monitoring mechanism
To achieve functional safety, such as in automotive applications, monitoring mechanisms in the device can be configured to periodically provide RF/analog health and diagnostic information to the host processor. These mechanisms are able to determine RF/analog performance parameters and detect faults caused by in-field transistor and interconnect failures. The diagnostic information they provide is also useful during the development and optimization of designs integrating TI millimeter wave radar devices.
2 Hardware infrastructure to support calibration and monitoring
The calibration and monitoring mechanisms in TI mmWave devices are implemented using a combination of hardware and firmware. Some of the hardware infrastructure blocks that implement these mechanisms are shown here.
Multiple TX, RX RF and IFA parameter measurements are provided by mmWave power detectors coupled to the TX PA output and RX LNA input, as well as the TX-RX RF and RX IF loopback structures in the device Supported, as shown in Figure 2-1.
Figure 2-1. On-chip TX-RX test signal loopback architecture: TX monitoring, RX monitoring, RX baseband monitoring
For example, enable Tx output power calibration by measuring the internal Tx power using a power detector located at the Tx power amplifier output port. Use the internal general-purpose ADC to read the voltage level of the power detector. These ADCs are also used to measure other internal voltage levels, such as the PLL control voltage, during VCO and APLL calibration.
Some calibrations (such as RX IF filter calibration) use an internal IF loopback structure. Feed the loopback signal at different IF frequencies, analyze the IF frequency response, and make appropriate resistor and capacitor bank adjustments to achieve the desired cutoff frequency. Other calibrations, such as Rx gain calibration, use an internal RF loop structure to feed a signal level of known amplitude from the TX chain to the Rx chain. Analyze the Rx gain by processing the ADC data amplitude and set the Rx chain bias accordingly to calibrate the gain.
In some other calibrations, a fixed look-up table (LUT, derived from nominal design simulation) is evaluated in firmware based on measured temperature and adjusted analog bias settings.
3 Calibration Checklist
TI’s millimeter wave radar devices support calibration as described in the following sections. All calibrations can be performed during the RF initialization phase (when the RfInit() API is called during power-up), and some can also be performed at runtime. The user can select the calibration to be performed at RfInit and runtime using the AWR_RF_INIT_CALIBRATION_CONF_SB API (called before the RfInit API) and the AWR_RUN_TIME_CALIBRATION_CONF_AND_TRIGGER_SB API. Two of the calibrations (APLL and synthesizer VCO calibration) are always enabled at boot time and runtime and cannot be disabled. The time required for these two calibrations, as well as any periodic runtime calibrations enabled, must be budgeted for when defining the frame configuration. More details can be found in the interface control documentation provided as part of the mmWave DFP package. If calibration is disabled during RF initialization, it cannot be enabled at runtime. In this case, the corresponding block always uses fixed settings and does not compensate for device process variations and temperature changes.
Note: The term "boot time" in this document refers to the radio frequency initialization phase.
3.1 APLL calibration
The APLL (or Cleanup PLL) is a closed-loop PLL that takes a 40Mhz reference clock as input and generates the clocks required by the processor, digital logic, and ADC, DAC, and FMCW synthesizers. APLL calibration is performed to keep the system clock locked at a constant frequency regardless of process and temperature. It is done during the RF initialization phase by measuring the control voltage of the VCO and adjusting the VCO tuning.
This is incrementally repeated periodically at runtime to account for temperature drift. Runtime APLL calibration is triggered when the last calibration result is more than 1 second old. Due to the importance of the system clock, APLL calibration cannot be disabled by the user and the calibration period is not user controllable. Users should consider this calibration time when programming frame timing.
3.2 Synthesizer VCO Calibration
The synthesizer VCO generates RF frequencies, calibration is done at boot, and is also triggered when the last calibration result is more than 1 second old. The calibration algorithm measures the synthesizer control voltages VCO and always maintains these voltages within a fixed range.
Again, due to the importance of the synthesizer VCO frequency, the user cannot disable this calibration, nor is the calibration period user controllable. Users should consider this calibration time when programming frame timing.
3.3 LO distribution calibration
A set of buffers are used to distribute the high frequency RF clock to the Rx and Tx sections. In TI's first generation MMICs (xWR1243, xWR1642, xWR1443, xWR6843, xWR6443, and xWR1843), there is a fixed temperature-based lookup table (LUT) that controls the buffer's bias setting. In the second generation MMIC (xWR2243), the buffer output signal swing is maintained and optimized through closed-loop calibration using a combination of a millimeter-wave power detector (used to reduce process variation) and a temperature-based lookup table.
3.4 ADC DC offset calibration
The ADC DC offset is only calibrated once at boot time. Perform this calibration without any signal at the RF LNA input. During calibration, the LNA input is terminated to prevent reception of any RF signals, and DC power is measured using DFE statistics collection. The measured DC offset is programmed into the digital DC correction block for cancellation.
3.5 HPF cutoff frequency calibration
The HPF1 and HPF2 high-pass filters are only calibrated once at boot time. The RX IFA square wave loopback is used to feed a known signal tone at the IFA input and measure the FFT component of the ADC output at the same frequency. Tune the filter to achieve the desired attenuation at the desired cutoff frequency.
3.6 LPF cutoff frequency calibration
The LPF1 and LPF2 low-pass filters are only calibrated once at startup. In TI's 1st generation MMICs (xWR1243/1443/1642/1843/6843/6443), the IFA square wave loop is used to feed a known tone at the IFA input and tune the filter to operate at the desired cutoff frequency achieve the desired attenuation. In 2nd generation MMIC (xWR2243), a fixed lookup table is used depending on the sample rate DFE operating mode (complex 1x/2x/, real-time).
3.7 Peak detector calibration
The peak detector is designed to provide an absolute voltage and power reference for the entire radar chip. They monitor voltage stress on the RF node and quantify the output power at the TX output and RF input. This enables accurate RF BIST and impedance detector measurements. For these measurements to be accurate, the peak detector must be calibrated for temperature changes. Perform this calibration for all critical peak detectors, especially those used for TX power calibration.
The peak detector is calibrated at boot time and can be recalibrated at runtime. TI recommends enabling peak detector runtime calibration with the monitor enabled. Monitoring circuits also use these peak detectors.
3.8 TX power calibration
Perform a TX power calibration to ensure that the device transmits exactly at the specified transmit power for the given profile.
TX power calibration can be done in open loop power control (OLPC) or closed loop power control (CLPC) mode. In OLPC mode, the TX-level code is based on coarse measurement settings and generates a LUT for each temperature range. The final stage code is picked from the LUT and applied to the device based on the temperature at the time of calibration.
In CLPC mode, TX-level codes are picked from the coarse LUT, just like in the OLPC step. The actual TX power is then measured using a peak detector and the TX stage code is improved to achieve the desired TX power accuracy. In many cases, CLPC mode provides better control of the TX output power because the gain is updated based on performing loop measurements again. This also resulted in intentional transmission and extended calibration times on the PA. See the interface control documentation for calibration times.
The LUT used for TX power calibration can be read back from the device using the API. It is also possible to replace the LUT with a user-programmed LUT (for example, using an LUT previously read back from the device). Section 7.8 contains the API for reading and writing the TX power calibration LUT.
Note: In CLPC mode, the LUT used for TX power calibration can be updated by the device after a run-time calibration event. If desired, the updated LUT can be read back from the device.
Performs TX power calibration for all enabled TXs on startup and can be performed again at runtime. During runtime recalibration, TX power calibration is done per profile, per TX.
3.9 RX gain calibration
Calibrate the RX RF gain to ensure overall RX gain is maintained over temperature changes. Before configuring any profiles, measure the RF gain once at boot time. The boot-time temperature when the gain is measured is also stored for use during run-time recalibration.
Calculate the current RF gain of the profile using the device temperature at calibration, the temperature at boot, and the RX RF gain measured at boot. Changes in RX gain are compensated in the RX IFA and DFE to achieve the overall gain required by the profile.
The LUT used for RX gain calibration can be read back from the device using the API. It is also possible to replace the LUT with a user-programmed LUT (for example, using an LUT previously read back from the device). The API for reading and writing the RX gain calibration LUT is described in Section 7.9.
3.10 IQ mismatch calibration
TI’s MMIC has a complex chain of receivers, each with available I and Q channels. The RF loopback structure is used to measure and correct for any inter-IQ gain and phase mismatch. This calibration is only done at RfInit (boot time).
3.11 TX phase shifter calibration
The AWR1843 and AWR2243 devices can configure the transmit phase in steps of 5.625 degrees, and 64 code settings are available to cover phase shifts from 0 to 360 degrees. To provide an accurate phase shift corresponding to each code (5.625 degrees * code), the phase shifter can be calibrated using the RF loopback structure at RF INIT. This is done at boot time.
To include correction over temperature and additional external calibration by the user for greater accuracy, see the Cascade Consistency and Phase Shifter Calibration Application Manual.
4 Effect of calibration on gain and phase
As the device temperature changes, the gain of the RX and TX modules will also change. If the gain settings are not corrected over temperature, the Rx and Tx gains will continue to decrease as temperature increases. For example, on the AWR2243 device, the Rx gain change for a fixed gain setting is approximately 0.4dB per 10 degrees Celsius temperature change. The Tx gain change for a fixed bias setting and 0dB backoff scenario is 0.2dB per 10 degrees Celsius temperature change. To reduce the effect of this gain variation with temperature, run-time calibration can be used in periodic mode or in a single-shot mode emitted by the user application based on temperature changes.
After completing calibration adjustments, there may be step changes in Rx or Tx gain or phase. Step changes in gain depend on calibration-induced changes in the gain code. A gain code change in the RX gain results in a 2dB gain change. Because the same calibration code is applied to all receivers or transmit chains within a single MMIC, there is minimal variation in gain/phase mismatch between channels. However, the absolute gain/phase may be different before and after calibration.
Some processing algorithms that rely on inter-frame coherence or amplitude/phase consistency (such as historical static clutter estimation) may be sensitive to sudden changes in absolute gain/phase caused by calibration. This is addressed by resetting its estimate after calibration. In a single-chip configuration, periodic run-time calibration can be avoided if gain/phase coherence is required between frames. Applications can use run-time calibration in one-time calibration mode, as described in Section 6.3. The app monitors the internal temperature and can issue a calibration if the temperature changes significantly (e.g. 30°C change). At this point, gain and phase change with subsequent frames, so the algorithm must be reset if the application uses any phase estimates from previous frames.
In cascaded use cases, gain/phase mismatch between multiple MMICs becomes critical, and absolute gain/phase changes in one MMIC can cause mismatches between multiple MMICs. To account for this variation, see the Cascaded Coherence and Phase Shifter Calibration application note (https://www.ti.com/lit/pdf/spracv2).
5 Effect of interference on calibration and radiation caused by calibration
When performing internal measurements for calibration, strong interference from outside the device can affect the measurement and degrade the quality of the calibration. Most calibrations are robust to such interference: Tx power calibration, DC offset calibration, APLL calibration, VCO calibration, LO distribution calibration, HPF/LPF calibration and power detector calibration are not affected by high power levels (< - 10dBm) in-band interference. All runtime calibrations are also robust to withstanding such large disturbances.
Some calibrations, including Rx gain attack time calibration, Rx IQ mismatch attack time calibration, and phase shifter calibration, may be affected if in-band interference is present during the measurement. These calibrations are only performed during Rfinit (startup time). Only perform these operations in a interference-free environment at the customer's factory to avoid any interference-induced damage, and use the device calibration data save and restore API to inject this information into interference-prone field-operated devices. The following steps demonstrate this approach:
1. Perform all Rfinit calibrations on sensors in a clean factory environment where interference is not expected.
2. Use the "AWR_CAL_DATA_SAVE_SB" and "AWR_PHASE_SHIFTER_CAL_DATA_SAVE_SB" APIs to save the Rfinit calibration results on the sensor's non-volatile memory.
3. After the sensor is installed, Rx IQ mismatch, Rx gain calibration, and phase shifter calibration are disabled in Rfinit using the "AWR_RF_INIT_CALIBRATION_CONF_SB" API during sensor operation. This is called before issuing the Rfinit API.
4. Call the "AWR_CAL_DATA_RESTORE_SB" and "AWR_PHASE_SHIFTER_CAL_DATA_RESTORE_SB" APIs linked to the previously stored calibration file.
5. After the recovery is complete, the Rfinit API can be called to perform other enabled calibrations.
Enables the TX power amplifier for certain startup calibrations (Tx power startup calibration, Tx phase shifter startup calibration, and Rx IQMM startup calibration). This results in some signals being emitted in the air during the process. If this raises any regulatory standards issues for the sensor, the above save-restore scheme can be extended to avoid these emissions during startup. To do this, the Tx power start calibration should also be disabled as part of step 3 in the above sequence.
TX output power runtime calibration in CLPC mode also enables the TX power amplifier. The TX power fallback settings used for this chirp calibration are the same as those in the profile configuration, so the total power emitted during this runtime calibration is the same as a regular chirp for the same profile. However, the calibration chirp scan bandwidth is between 75 - 100Mhz, so the spectral density may not be the same as the functional chirp. If this is a radiation issue, the TX power runtime calibration can be set to OLPC mode, where transmission is not involved.
6 Schedule runtime calibration and monitoring
The device receives the required chirp and frame configuration from the corresponding API message and schedules the transmission of the chirp accordingly. Chirps are transmitted in bursts or frames depending on the programmed configuration.
All regular calibration and monitoring are arranged within the free time period between the devices between the large frames (or the emergencies, the high -end frame) of each frame. Runtime calibration in primary mode must be manually scheduled and triggered by the application based on internal temperature sensor readings. Calibration must be triggered before changes are intended to be made to the frame. Single monitoring and calibration can be enabled or disabled depending on the needs of the application. The period of calibration and monitoring is configurable through two programmable parameters: CALIB_MON_TIME_UNIT and CALIBRATION_PERIODICITY.
Each CALIB_MON_TIME_UNIT frame (programmed by the user) executes a monitoring cycle covering all enabled monitors. therefore:
MonitoringPeriod (in μs) = FramePeriod (in μs) × CALIB_MON_TIME_UNIT (1)
Periodic calibrations (except APLL and synthesizer VCO calibrations) are performed in configurable multiples of CALIB_MON_TIME_UNIT. This multiplier is configured using the CALIBRATION_PERIODICITY parameter.
CalibrationPeriodicity (in μs) = MonitoringPeriod (in μs) × CALIBRATION_PERIODICITY (2)
NOTE: APLL and synthesizer VCO calibration always occurs during the next available idle period after every 1 second; this is beyond the control of the host. APLL and synthesizer VCO calibration are always enabled.
The value of CALIB_MON_TIME_UNIT must be large enough to accommodate all enabled monitors, all enabled periodic runtime calibrations, and some software overhead. Even though calibration does not necessarily occur every monitoring period, it must still be budgeted for when selecting CALIB_MON_TIME_UNIT.
At each CALIBRATION_PERIODICITY, the processor reads the temperature and performs calibration updates if needed. This update will only occur if the temperature is within ±10 degrees Celsius of the last calibration. LO distribution calibration updates are only made when the temperature is within ±20 degrees Celsius from the last update.
This temperature measurement and calibration occurs during the idle time between frames (or bursts). If any calibration results in a device register update, the host is notified of the calibration update via an asynchronous event message.
The device determines the available idle time before the start of each frame (or burst) to ensure that there is enough idle time to complete each calibration.
Figure 6-1 shows an example where CALIB_MON_TIME_UNIT is 2 and CALIBRATION_PERIODICITY is 3. Note that monitoring activity can occur during multiple inter-frame idle times. For detailed examples of programming CALIB_MON_TIME_UNIT and CALIBRATION_PERIODCITY, see the Interface Control documentation in mmWave DFP.
Figure 6-1. Calibration and monitoring activities during interframe idle time
6.1 Select CALIB_MON_TIME_UNIT
The first step is to calculate the total idle time available for each frame. For advanced frames, this includes all inter-burst idle time, inter-subframe idle time, and inter-frame idle time. From this number, 100μs should be left to allow preparation time for the next frame.
The next step is to calculate how long all periodic calibrations have been enabled, all monitors and software overhead have been enabled. The duration of each monitoring and calibration is listed in Appendix A.
The minimum allowed value for CALIB_MON_TIME_UNIT is then the number of frames required to accommodate the above duration in the available idle time per frame. The software overhead of the window watchdog depends on CALIB_MON_TIME_UNIT, so the calculation must be iterative.
Depending on the requirements of your application, CALIB_MON_TIME_UNIT can be chosen to be any number higher than this value. See the interface control documentation for some example calculations of calibration times and how to configure CALIB_MON_TIME_UNIT.
6.2 Select CALIBRATION_PERIODICITY
The calibration period must be at least 1 second or longer. The minimum allowed value for CALIBRATION_PERIODICITY is:
CALIBRATION_PERIODICITY > = CEIL(1/(FramePeriod (in s) × CALIB_MON_TIME_UNIT)) (3)
For some example calculations of calibration times and how to configure CALIBRATION_PERIOCITY, see the interface control documentation.
6.3 Application-controlled one-time calibration
In scenarios where the user does not want the device firmware to automatically trigger periodic calibration, the application can use the one-time calibration feature, which controls the instances at which calibration must be performed and the change in gain value. The application can trigger the calibration once using the internal temperature sensor reading, or always before starting the radar measurement if the measurement period is expected to be short and the temperature is not expected to change significantly during the measurement. When the primary calibration mode is triggered, various RF/analog calibrations are triggered based on the bits configured in the "ONE_TIME_CALIB_ENABLE_MASK" field. The response takes the form of an asynchronous event. If enabled, calibration is performed after the completion of any ongoing FTTI cycle, and the calibration results are valid starting with the next FTTI.
There are two ways to use one-time calibration:
1. One-time calibration without temperature index coverage; in this mode, when the application triggers one-time calibration, The firmware measures the internal temperature and sets the gain index based on the measured temperature. The app can control the timing of the calibration, but not the exact gain setting selected by the firmware.
2. One-time calibration with temperature index coverage: This mode is available in the xWR2243 device. In this mode, in addition to controlling the calibration time, the application selects the gain index to be selected by firmware regardless of the internal temperature reading. This gives the application complete control over gain changes. This mode is typically only needed in a cascaded environment to ensure that gain and phase mismatch between channels of multiple devices varies in a predictable manner.
7 Software calibration controllability
This section lists the calibration-related software APIs available in mmWaveLink. The latest information on these APIs is provided in the AWR1xx Radar Interface Control documentation
7.1 Calibration and monitoring frequency limits
The rlRfSetCalMonFreqLimitConfig function can be used to program the lower and upper RF frequency limits for calibration and monitoring. These limits apply to all TXs. TI recommends using the rlRfTxFreqPwrLimitConfig function instead because it allows greater flexibility.
Note: If the rlRfSetCalMonFreqLimitConfig and rlRfTxFreqPwrLimitConfig functions are called at the same time, the function called later will determine the limits used during calibration and monitoring.
7.2 Calibrate and monitor TX frequency and power limits
The user can select the frequency band and Tx power level to be used during calibration and monitoring. This is done using the rlRfTxFreqPwrLimitConfig API. The Tx power level and chirp frequency range for active chirps are selected by Profile Config. The two are not automatically related to each other in firmware, so the user can choose to use the same or different settings for calibration and active chirps.
For best calibration accuracy, TI recommends always using a Tx power setting with 0-dB backoff for calibration/monitoring, even if the active chirp uses a higher backoff setting. The calibration frequency range can be aligned with the effective chirp frequency range.
TI recommends performing Tx output power calibration using 0-dB backoff in a factory environment and for use in field operations if the use of the 0-dB backoff setting during calibration affects transmit requirements. Calibration save/restore function. See Section 5 for details on the save/restore process steps. During factory calibration, a 0db fallback can be used and the calibration saved. During operation RfInit calibration is disabled and the saved calibration results can be restored. Even if calibration is done with 0dB backoff, functional chirps can still use more than 0dB backoff.
7.3 Calibration status report
7.3.1 RF initialization calibration completed
When rlRfInit is called, boot-time calibration will be run and the application should wait for the RF initialization/calibration complete asynchronous event
AWR_AE_RF_INITCALIB_STATUS_SB.
This report indicates the pass/fail status of all enabled boot-time calibrations and whether any calibration data was updated in the hardware as a result of the calibration. This report also contains the timestamp when the calibration was performed, and the temperature measured at the time of calibration (this is the average of the readings from the temperature sensors located near the TX and RX channels).
7.3.2 Runtime calibration status reporting
If calibration reporting is enabled using the rlRfRunTimeCalibConfig API, the mmWave device sends the AWR_RUN_TIME_CALIB_SUMMARY_REPORT_AE_SB asynchronous event message after completing any runtime calibration (one-time and periodic).
This report indicates the status of each enabled runtime calibration and whether any calibration data was updated in the hardware as a result of the calibration. This report also contains the timestamp when the calibration was performed, and the temperature measured at the time of calibration (this is the average of the readings from the temperature sensors located near the TX and RX channels).
7.3.3 Calibration/Monitoring Timing Fault Status Report
If the total monitoring and calibration time does not fit into one CALIB_MON_TIME_UNIT, the mmWave device sends
the AWR_CAL_MON_TIMING_FAIL_REPORT_AE_SB asynchronous event message.
This report is also sent when there is a runtime violation (i.e. monitoring and calibration cannot be performed in a CAL_MON_TIME_UNIT).
7.4 Programming CAL_MON_TIME_UNIT
Use the rlRfSetCalMonTimeUnitConfig function to set CALIB_MON_TIME_UNIT. CALIB_MON_TIME_UNIT is the basic calibration and monitoring time unit, which determines the period of periodic execution of each monitor.
7.5 Calibration periodicity
The CALIBRATION PERIODICITY parameter is set by the rlRunTimeCalibConf API. This parameter controls the total time between runtime calibrations.
7.6 RF initialization calibration
The rlRfInitCalibConfig function can be used to control the calibration set performed when rlRfInit is called. By default, all calibrations are performed on RF initialization. This function must be called before calling rlRfInit.
7.7 Runtime calibration
rlRfRunTimeCalibConfig function can be used to:
• Trigger a calibration instantaneously
• Schedule periodic run-time calibration
Configure calibration period
use using use using with use use using using being being being taking into being through out through out off through out off through down through ’’'‐ ‐‐ ‐ ‐ • The runtime calibration API can be issued during the framing process; the firmware performs calibration internally at the end of the current FTTI period and applies the changes to frames in the next FTTI.
7.8 Override TX Power Calibration LUT
You can use the rlTxGainTempLutGet function to read back the LUT used for TX power calibration. This returns a lookup table of TX power calibrations applied to the given profile. This function can only be called after the configuration file has been configured in the device.
The LUT structure is described in the AWR1xx Radar Interface Control Document. The LUT for a given profile consists of a set (19) of TX gain codes for each TX, each code corresponding to a specific 10-degree temperature interval. Each TX gain code is a 6-bit number, with higher values corresponding to higher gains.
If CLPC mode is enabled, the device may automatically update entries in the LUT due to runtime calibration.
The rlTxGainTempLutSet function can be used to replace the device's LUT used for TX power calibration with a different set of gain codes. This function should be called once for each profile for which the LUT needs to be replaced. This function can only be called after the configuration file has been configured in the device.
7.9 Override RX Gain Calibration LUT
You can use the rlRxGainTempLutGet function to read back the LUT used for RX gain calibration. This returns a lookup table of RX gain calibrations applied to the given profile. This function can only be called after the configuration file has been configured in the device.
The LUT structure is described in the AWR1xx Radar Interface Control Document. The LUT for a given profile consists of a set (19) of RX gain codes, each code corresponding to a specific 10-degree temperature interval. Each RX gain code is divided into an IF gain code and an RF gain code.
The rlRxGainTempLutSet function can be used to replace the device's LUT used for Rx gain calibration with a different set of gain codes. This function should be called once for each profile whose LUT needs to be replaced. This function can only be called after the configuration file has been configured in the device.
7.10 Retrieve and restore calibration data
The rlRfCalibDataStore and rlRfCalibDataRestore functions retrieve and reprogram all calibration data from the device. These APIs can be used to store all calibration data into non-volatile memory at the factory and restore them on every power-up.
The calibration data consists of 3 blocks of 228 bytes each. The rlRfCalibDataStore function reads calibration data from the device one block at a time, and the rlRfCalibDataRestore function restores calibration data to the device one block at a time.
The rlRfCalibDataRestore API must be called before calling rlRfInit.
After the calibration data has been correctly restored and verified, the device will issue an AWR_AE_RF_INITCALIB_STATUS_SB report indicating the calibration results based on the restored calibration data.
A Calibration and Monitoring Duration
For the length of time required to complete each boot-time calibration, run-time calibration, and monitoring, see the Calibration and Monitoring Duration section of the interface control document. In addition to the time spent per calibration and monitoring, the firmware has some fixed overhead that must be taken into account when calculating the total interframe time requirements in FTTI. This can be found in the interface control documentation, chapter Calibration and monitoring duration.