TDA2EXEVM: Switching AWR Profile Config in Cascade MIMO Usecase

Please use the below function under ~/vision_sdk/apps/src/rtos/radar/src/common/chains_common_ar12xx.c. You can refer to the use case, radar_objectdetect_display, to see how it is used.

/**
*******************************************************************************
*
* \brief Function to change the profile parameters at run time
*
* \param algId Algorithm Link ID for the FFT Heat Map
* \param pAr12xxCfg Pointer to the configuration structure.
*
* \return retval SYSTEM_LINK_STATUS_SOK if the parameter change has happened.
*
*******************************************************************************
*/
Int32 ChainsCommon_ar12xxChangeParameters(UInt32 algId, ChainsCommon_Ar12xxConfigOut *pCfgOut)

Hi Stanley,

Using your suggestion with some code mods allows me to switch from one chirp profile to another. However, the new profile radar cube didn't seem to automatically recognize in the processing data flow (ie: FFT Alg didn't get a new profileID). Debugging into the FFT code that sets the ProfileID in this code block below get skipped over the logic. pObj->inBufAddrOffset[chId] is never > 0. So, currProfile is always 0 due to initialization. My new chirp profile change also has numADCSamples and numLoops that are different than the the first profile.

if (pObj->inBufAddrOffset[chId] > 0U)
{
currProfile = ((*(UInt32*)inBufAddr) >> 2U) & 0xFU;
}

Any thought?

Can I get a zoom session with you to debug this?

Thanks,

--Khai

Hi Stanley,

If currProfile = ((*(UInt32*)inBufAddr) >> 2U) & 0xFU; is not changing upon ProfileCfg_t change, how do I know if the AWR radar cube size actually did change?

Thanks,

--Khai

Did you use the data out format 6 in dataPathCfgArgs? You need that so chirp profile will be added to the beginning of input data..

    .dataPathCfgArgs   = {
        .intfSel         = (rlUInt8_t) 0,
        .transferFmtPkt0 = (rlUInt8_t) 6, /**< Data out Format, \n
                                      b5:0 Packet 0 content selection\n
                                      000001 - ADC_DATA_ONLY \n
                                      000110 - CP_ADC_DATA \n
                                      001001 - ADC_CP_DATA \n
                                      110110 - CP_ADC_CQ_DATA
                                      b7:6 Packet 0 virtual channel number (valid only for CSI2)\n
                                      00 Virtual channel number 0 (Default)\n
                                      01 Virtual channel number 1\n
                                      02 Virtual channel number 2\n
                                      03 Virtual channel number 3 \n*/

Yes, when i set .transferFmtPkt0 = (rlUInt8_t) 6, profileId varies from 0 -> 15 from frame to frame. Not reliable. I would expect it to remain 0 until a new profile is changed.

Thanks,

--Khai

Is there another way to know when profile changes (which in turns radar cube size changes), the correct radar cube size is coming into the TDA2 processing chain? In the past, reply on setting this flag to 6 so when profile changes, a new profileId is updated in FFT Alg and thus pull the right parameters to process the incoming ADC data. Now that that is not reliable, how do I know the profile has actually been changed on the AWR? Where can i print the actual ADC radar cube size and not from the pre-populated profile info in the pRadarParam object?

Thanks,

--Khai

This would be a question for our radar team.

Maybe you can test this with mmWave Studio first to see if it is even possible to do what you want to achieve with the radar configurations.