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.

AWR1243: Boot and Run Time Calibrations

Part Number: AWR1243


Hello, 

In the recently release document, SPRACF4 titled 'Self-Calibration in TI's mmWave Radar Devices', table A.1 on page 14 does not show IQ Mismatch and Tx phase calibrations. Have these calibrations been left out intentionally ? 

Regards,

RJ

  • Radar Junkie,

    The TX gain phase mismatch monitor is listed on page 15 and has a duration of 400 us.

    Regards,
    Kyle
  • Hi Kyle, 

    Thanks for the reply. My question was related to calibration not monitoring. In the ICD, there are enable/disable option for Tx Phase Calibration and RX IQMM Calibration. In the SPRACF4 document, 
    these two calibration dont exist at boot time or run time. 

    RJ

  • Hi RJ,

    TX Phase calibration is applicable only to AWR1243P - the corresponding firmware for AWR1243P ES3 is not yet publicly available.
    RX IQMM Calibration is currently disabled in the firmware and may be enabled in an upcoming firmware release.

    These have been left out intentionally in the SPRACF4 document for these reasons.

    Best Regards,
    Anand
  • Hi Anand, 

    Thank you for the reply. I appreciate your help. 

    The IQMM calibration is disabled in ES 3.0 I assume from your reply, but it is enabled in ES 2.0 based on our observations. Some chips on our board show IQ MM calibration passed and the other show failed. Is it better that we just disable the IQMM calibration then ?

    Regards,

    RJ

  • Hi RJ,

    For now, we recommend IQMM be disabled in both ES2 and ES3 chips. The release notes for the new firmware will mention when it is okay to enable IQMM calibration later.

    Best Regards,
    Anand
  • Hi all,

    I have two related questions

    1. With RX IQMM calibration (bit 12) disable as part of the calibEnMask for rlRfInitCalibConfig(), the async event message of RL_RF_AE_INITCALIBSTATUS_SB, still have RX IQMM calibration (bit 12) of calibStatus turned on. Does this mean the RX IQMM calibration is still running? Or does it mean the respond is incorrect?

    2. Bit 11 for the calibEnMask variable inside the rlRfInitCalConf structure inside rl_sensor.h is defined as reserved (see below). However in the AWR1xxx Radar Interface Control Document Revision 0.95 – Dec 27, 2017. bit 11 is defined for Enable TX Phase calibration. Should it be set to 0 or do I have control over it?

    typedef struct rlRfInitCalConf
    {
    /**
    * @brief Allowed values = 0x000 or 0xFFF Normally, upon receiving RF INIT message, the \n
    * radarSS performs all relevant initial calibrations. This step can be disabled \n
    * by the host by setting this field to 0x00. If disabled, the host needs to send \n
    * the INJECT CALIB DATA message so that the radarSS can operate using the \n
    * calibration data thus injected. Each of these calibrations can be selectively \n
    * disabled by issuing this message before RF INIT message. \n
    *
    * Bit Calibration \n
    * 0 [Reserved] \n
    * 1 [Reserved] \n
    * 2 [Reserved] \n
    * 3 [Reserved] \n
    * 4 Enable LODIST calibration \n
    * 5 Enable RX ADC DC offset calibration \n
    * 6 Enable HPF cutoff calibration \n
    * 7 Enable LPF cutoff calibration \n
    * 8 Enable Peak detector calibration \n
    * 9 Enable TX Power calibration \n
    * 10 Enable RX gain calibration \n
    * 11 [Reserved] \n
    * 12 Enable RX IQMM calibration \n
    * 31:13 [Reserved] \n
    */
    rlUInt32_t calibEnMask;

    Thanks,

    Dom
  • Hi Dominic,

    The status bits in the AE message are only valid for calibrations that are enabled. Please ignore the values for those bits where the calibrations are disabled.

    Bit 11 is reserved in the firmware for both versions. It has been reserved for phase shifter calibration which will be implemented in a future version of the firmware. Please set it to 0 in all current versions of the firmware. Setting it to 1 in the current versions may change the behavior, as the implementation may take this bit into account - however our recommendation is to set it to 0 for now.

    Best Regards,
    Anand