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.

AWR6843: Calibration methods and parameter questions

Part Number: AWR6843

Hi Ti Temas

I am ED Wu.

Our teams using 3D_Occupancy_Detection demo with  AWR6843AOP and sample PCB designed based on AWR6843.

The SDK version link to mmwave_sdk_03_05_00_04


We have the following questions to ask:
1. We found that both one-time calibration and periodic calibration are turned off. Is there any reason?

2. The CASE RL_RF_AE_INITCALIBSTATUS_SB in the function OccupancyDetection3D_eventCallbackFxn can display the initialization calibration status, but no matter how it is set, the result will be the same (0xffe).

Is the calibStatus data structure updated correctly?

3. In the document Self-Calibration in TI’s mmWave Radar Devices, 6.3 Application-Controlled One Time Calibration,  When the one-time calibration is triggered, the internal temperature is measured to set the gain index. In this case, can one-time calibration be used instead of periodic calibration? And avoid the influence of temperature on the antenna?

Regards, ED

  • Hi,

    Please allow us a day or so to provide a response.

    Regards,

    Tim

  • OK, we'll wait for your reply, but please do it as soon as possible. We still have many questions to clarify.
     

    Regards, ED

  • Hi,

    1,2) Is there any specific reason not to use the latest SDK Version mmwave_sdk_03_06_00_00? We would recommend you to use the latest SDK version which is available.

    3) Yes, one-time calibration can be used if you don't intend to trigger calibrations automatically by the firmware. But can you please elaborate "And avoid the influence of temperature on the antenna" part.

    Thanks,
    Kundan

  • HI, ED:

    The actual RF boot-time calibration configuration is done with rlRfInitCalibConfig.   If you search in the SDK folder, you can find it in the mmwave_link.c.  And you can see that the RF init calibration is always enabled.  

    /* Are we supporting custom calibration or not? */
    if (ptrMMWaveMCB->openCfg.useCustomCalibration == true)
    {
    /*********************************************************************
    * Custom Calibration: Use the application provided calibration mask
    *********************************************************************/
    rfInitCalib.calibEnMask = ptrMMWaveMCB->openCfg.customCalibrationEnableMask;
    }
    else
    {
    /*********************************************************************
    * Default: Enable all calibrations
    *********************************************************************/
    rfInitCalib.calibEnMask = CSL_FMKR (4U, 4U, 1U) | /* LODIST calibration */
    CSL_FMKR (5U, 5U, 1U) | /* RX ADC DC offset calibration */
    CSL_FMKR (6U, 6U, 1U) | /* HPF cutoff calibration */
    CSL_FMKR (7U, 7U, 1U) | /* LPF cutoff calibration */
    CSL_FMKR (8U, 8U, 1U) | /* Peak detector calibration */
    CSL_FMKR (9U, 9U, 1U) | /* TX Power calibration */
    CSL_FMKR (10U, 10U, 1U) | /* RX gain calibration */
    CSL_FMKR (11U, 11U, 1U) | /* TX phase calibration */
    CSL_FMKR (12U, 12U, 1U); /* RX IQMM calibration */
    }
    retVal = rlRfInitCalibConfig(RL_DEVICE_MAP_INTERNAL_BSS, &rfInitCalib);

    And the following two lines are all related to the runtime calibration.  You can find it how it is used also in mmwave_link.c

    calibrationCfg.u.chirpCalibrationCfg.enableCalibration = true;
    calibrationCfg.u.chirpCalibrationCfg.enablePeriodicity = true;

    Sorry for the confusion. 

    Best,

    Zigang

  • Hi Kundan,

    When loading the project, it has been automatically defaulted to SDK 3.5, as shown in the figure.

    When we used a baby simulation doll for actual measurement, we found that the SNR and point cloud were unstable, and we speculated that the periodic calibration parameters affected the one-time calibration.
    But after seeing the relevant setting switches for calibration, I am not sure what the cause of the impact is.


    After we read the documents "Self-Calibration" and "Cascade Coherency and Phase Shifter Calibration", we did not clearly understand the method and process of periodic calibration. However, in Self-Calibration 6.3, it was mentioned that one-time calibration may replace periodicity calibration.

    Until now, we are still investigating the cause of instability and trying to capture and record the unstable situation.

    Regards, ED

  • Hi Zigang,

    Thanks for your answer.
    I looked at the link below and thought that to disable all calibrations I just need to set these two lines of code to false.

    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1051278/iwr6843aop-how-we-verify-the-calibration-result-or-compare-the-performance-with-or-without-calibration

    In addition, we have changed the SDK to 3.6, and plan to add CLI to capture temperature information, TX Power and RX Gain to try to find the cause of instability.

    Also, we asked the local FAE, and his answer was that SNR would be quite sensitive to temperature, which is basically the same as the description in the document.

    There are also the following correction method issues that need to be clarified:
    1. "The LUT structure is described in the AWR1xx Radar Interface Control document." is described in 7.8 of the document. I would like to ask if this description also applies to AWR6843AOP?

    2. Similar question, document "Cascade Coherency and Phase Shifter Calibration
    "Application Note" also applies to AWR6843AOP?

    3. Based on my understanding after reading, do I need to create some CLI to connect to the periodic calibration API? For example: rlTxGainTempLutGet, rlTxGainTempLutSet...

    4. Continuing from question 3, when performing periodic calibration, is a calibration box that can control the temperature required? This box also needs a retroreflector and high-frequency absorbing material?

    Best Regards,

    ED

  • HI, ED:

    The baby doll (at least the one we have), has a breathing pattern, so the SNR and number of detected points are not constant over time.  But it should have a rough pattern over 7-20 seconds. 

    Let me know whether it explains the SNR variation you observed. 

    Best,

    Zigang

  • HI, ED:

    I think that e2e is misleading.  If you still have doubt on the boot-time calibration control, you can change the following lines to enable partial calibrations and see whether it shows a change in the init calibration status

    Let us focus to solve this question on this e2e thread and please start a new e2e thread regarding your other questions. 

    /*********************************************************************
    * Default: Enable all calibrations
    *********************************************************************/
    rfInitCalib.calibEnMask = CSL_FMKR (4U, 4U, 1U) | /* LODIST calibration */
    CSL_FMKR (5U, 5U, 1U) | /* RX ADC DC offset calibration */
    CSL_FMKR (6U, 6U, 1U) | /* HPF cutoff calibration */
    CSL_FMKR (7U, 7U, 1U) | /* LPF cutoff calibration */
    CSL_FMKR (8U, 8U, 1U) | /* Peak detector calibration */
    CSL_FMKR (9U, 9U, 1U) | /* TX Power calibration */
    CSL_FMKR (10U, 10U, 1U) | /* RX gain calibration */
    CSL_FMKR (11U, 11U, 1U) | /* TX phase calibration */
    CSL_FMKR (12U, 12U, 1U); /* RX IQMM calibration */
    }
    retVal = rlRfInitCalibConfig(RL_DEVICE_MAP_INTERNAL_BSS, &rfInitCalib);

    Best,

    Zigang

  • OK, thank you for your answer, I will open another thread to discuss the calibration method.

  • I am in the process of setting up CLI and GUI to capture data. When I capture the data where the problem occurs, I will ask you again. Thank you.

  • Hi, ED:

    Take your time.  I will leave this thread open. 

    Best,

    Zigang

  • Hi Zigang,

    Based on the question at the beginning of this discussion, there is no answer yet,

    why is the run-time calibration of this demo turned off?

    Best Regards,

    ED

  • Hi, ED:

    In this demo, we are processing the neighboring 4 frames together to improve the sensitivity.  If we enable run-time calibration, and the gain setting changes between the frames, we will have a lot of false detection when mixed the frames right before and after the gain change.

    Best,

    Zigang 

  • Hi Zigang,

    Sorry it took me some time to retrieve the information.
    The same SDK and Demo.
    We use a fixed corner reflector to record the average changes in temperature and SNR every second.
    To observe the results, the SNR was averaged and multiplied by a factor of 6.
    The changes in temperature and SNR are shown in the figure below:

    In this case, when should one-time calibration be triggered?

    For one-time calibration settings, refer to the following link settings
    https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1062129/iwr6843-iwr6843-runtimecalibconfig

    Best Regards,

    ED

  • Hi,

    Zigang is out today, and will send a reply here next week.

    Regards,

    Tim

  • HI, ED:

    Usually RX gain change does not affect the SNR.  So, your SNR change is due to the TX gain change.  1dB gain change is not a lot.  You can enable the run-time calibration and see which way works better.  It is really up to the user to decide when to enable run-time calibration.  Usually we suggest 30 degree of temperature change. 

    Best,

    Zigang