IWR6843AOP: LAMBDAOVER2D value in Capon Beamformer steering vector definitions

Hello Riccardo,

Please give us 24 hours to respond with additional information.

Best Regards,

Pedrhom

Hi,

I've these additional questions:

1. The spacing between TX antennas in the xWR6843 AoP is equivalent to 1 lambda (half lambda for the RX antennas), which corresponds to 5 mm.  With a speed of light of 3e8 m/s,this is equivalent to a central frequency of 60GHz. Is the value  0.9813 of LAMBDAOVER2D  based on a central frequency different from 60GHz?
   In fact, lambda = 0.9813*2d = 0.9813*5mm = 4.9065mm , resulting in a central frequency of 3e8m/s / 4.9065mm = 61.143GHZ
   
2. From a formal point of view,  the steering vector formulation provided in Section 6.1.1.1 of the 3D People Tracking Demo Software Implementation Guide – Rev 2.2 suggests that  the correct name should be 2DOVERLAMBDA instead of LAMBDAOVER2D. Is there a typo in the name (but in this case how this number is calculated?) or does it depend on the specific steering vector formulation used in RADARDEMO_aoaEst2DCaponBF_create()?
3. In the same function, LAMBDAOVER2D is present at lines 162-163 for the azimuth steering vector but it is missing at lines 175-176 for the elevation one. Is there a typo or a mathematical reason for this discrepancy?

Thanks,

Riccardo

Hi,

Regarding the answers:

1. Do you know to which central frequency the value 0.9813 for LAMBDAOVER2D, which is defined at compile time, correspond? Moreover I suspect that using the code with a chirp configuration not aligned with the expected central frequency will produce some degree of error in the resulting heatmap.
2. The document is 3D_people_tracking_demo_implementation_guide.pdf from radar_toolbox_1_20_00_11, in particular in the section 6.1.1.1 pag 29 we readin which a factor 2DOVERLAMBDA is defined instead of LAMBDAOVER2D
3. We expected the elevation and azimuth steering vectors to be indipendent, so LAMBDAOVER2D is needed in the elevation one:

 for (i = 0; i < (int32_t)handle->raHeatMap_handle->azimSearchLen; i++ )
 {
 for (j = 0; j < (int32_t)handle->nRxAnt; j++)
 {
 tempfRe = (float)cossp_i(-RADARDEMO_AOAESTBF_PI * LAMBDAOVER2D * moduleConfig->m_ind[j] * currentAngle) * (float) moduleConfig->phaseRot[j];
 tempfIm = (float)sinsp_i(-RADARDEMO_AOAESTBF_PI * LAMBDAOVER2D * moduleConfig->m_ind[j] * currentAngle) * (float) moduleConfig->phaseRot[j];
 _amem8_f2(steerVecPtr++) = _complex_mpysp(_ftof2(tempfRe, tempfIm), _amem8_f2(&moduleConfig->phaseCompVect[j]));
 }
 currentAngle += handle->raHeatMap_handle->nuStep;
 }

currentAngle = handle->raHeatMap_handle->muInit;
 steerVecPtr = (__float2_t *)handle->raHeatMap_handle->steeringVecElev;
 for (i = 0; i < (int32_t)handle->raHeatMap_handle->elevSearchLen; i++ )
 {
 for (j = 0; j < (int32_t)handle->nRxAnt; j++)
 {
 tempfRe = (float)cossp_i(-RADARDEMO_AOAESTBF_PI * moduleConfig->n_ind[j] * currentAngle);
 tempfIm = (float)sinsp_i(-RADARDEMO_AOAESTBF_PI * moduleConfig->n_ind[j] * currentAngle);
 _amem8_f2(steerVecPtr++) = _ftof2(tempfRe, tempfIm);
 }
 currentAngle += handle->raHeatMap_handle->muStep;
 }

Thanks,

Riccardo

Riccardo Repetto said:

• Do you know to which central frequency the value 0.9813 for LAMBDAOVER2D, which is defined at compile time, correspond? Moreover I suspect that using the code with a chirp configuration not aligned with the expected central frequency will produce some degree of error in the resulting heatmap.

Yes that appears correct. I would modify this to work with your center frequency.

For items 2/3, I am investigating now. Please give me a day to come up with a complete answer.

Best,

Nate

Hi,

any news?

Best Regards,

Riccardo

Hi Nathan,

Thanks for the explanation.

Riccardo