AWR6843AOPEVM: 3D People Counting: The heatmap data arrangement of static scene beamforming

Hi Nate,

The heatmap data was indeed arranged in [elev][azim] format, and it conform to the behavior of the codes.

=> For my understanding, and to embody the [elev][azim] format is:

(The 0 indexes of azimuth and elevation are at the bottom since it follows the "heatMapPtr" which starts from end of the buffer, and step-by-step count down; see codes above, in line 151.)

But my confusion was this did not conform to the figure 34, it was arranged in [azim][elev]. The data might be re-arranged to fit the figure.

Did I miss any information in codes or my understanding was incorrect?

Thanks

Shihyu.

Hi Nate,

After reading the content of implementation guide literature and reviewing the codes again, There is a misunderstanding.

Thus, following 2 lists are my current comprehension about the heatmap data arrangement, and corresponding process meaning of CFAR in both dynamic and static-scene detection parts.

Please correct me if anything goes wrong and give me the guidance.

1. In ceil-mount case of Capon beamforming process:

• The 2D angle steering vectors(raHeatMap_handle->steeringVec) were initialized in [elev][azim] order: (see line 221~238 in RADARDEMO_aoaEst2DCaponBF_create() function in RADARDEMO_aoaEst2DCaponBF.c)

• The heatmap(rangeAzimuthHeatMap) will then be computed in same [elev][azim] order using steering vectors: See line 1162 in RADARDEMO_aoaEst2DCaponBF_raHeatmap() function in RADARDEMO_aoaEst2DCaponBF_heatmapEst.c. Which use the outer-most for loop to compute each AngleBins.

• Thus, after these 2D angle Capon beamforming computation of ceil-mount case, the heatmap and corresponding data arrangement fit the [elev][azim] format just like figure 34.
• Finally, CFAR detects peaks using this heatmap for detection in range-domain then in azimuth-domain (ignore several Angle Index cross different elevation-domain.)

2. For static scene 2D angle Bartlett beamforming process: (lines 119~177 in RADARDEMO_aoaEstimationBFSinglePeak_static() function in RADARDEMO_aoaEstimationBFSinglePeak_staticHeatMapEst.c)

• Which use 2 for loops process all elevation index (in inner loop; line 138) according to each azimuth index (outer loop; in line 121). That is to say, in [azim][elev] order. (Thus the data were arranged in [azim][elev] format just like the figure draw by myself.)

• Finally, the CFAR detects peaks using this heatmap for detection in range-domain then in elevation-domain!

(Another clue is that in line 1402 of RADARDEMO_detectionCFAR_raCAAll() function in RADARDEMO_detectionCFAR_priv.c, the annotate denotes "with elevation domain local max confirmation" if the enableSecondPassSearch == 0, which is the static scene setting.)

So, I can say that each case listed above detect peaks through CFAR in its major angle domain (focus on the second-pass in CFAR); first one, ceil-mount case, major in azimuth-domain; while second one, static scene, major in elevation-domain.

(Since Figure 34 is the description for ceil-mount dynamic scene detection, and also is the only visualization for CFAR, I was misled that all data in heatmap should be arranged in same format.)

Do all these algorithms behavior and my understanding correct? Need your guidance.

Thanks a lot.

Shihyu.

Hi Shihyu,

Give me a day or two to investigate this. I'll get back to you as soon as I can.

Best,

Nate

Hi,

I think it's clear enough for me!

Thanks a lot of the effort.

Shihyu.