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.
Hi, TI team,
It seems to be different heatmap data arrangement between function codes and the description in document while computing the static scene Azimuth-Elevation Bartlett beamforming.
(The source codes are imported from project: "C:\ti\mmwave_industrial_toolbox_4_11_0\labs\People_Counting\3D_People_Counting\src\68xx\68xx_3D_people_count_dss.projectspec".)
(The source codes are in lines 119~177 in RADARDEMO_aoaEstimationBFSinglePeak_static() function in RADARDEMO_aoaEstimationBFSinglePeak_staticHeatMapEst.c file. And "RADARDEMO_aoaEstimationBFSinglePeak_static()" is called by RADARDEMO_aoaEst2DCaponBF_static_run() while "processingStepSelector == 0". )
。In codes: Using 2 for loops which process all elevation index (in inner loop) according to each azimuth index (outer loop), then change to next azimuth index to keep processing:
=> The arrangement become: [azimIdx_0; elevIdx_0 ~ elevIdx_End], [azimIdx_1; elevIdx_0 ~ elevIdx_End], ... [azimIdx_End, elevIdx_0 ~ elevIdx_End]
。In "3D_people_counting_demo_implementation_guide" document description(figure 34 in p.51), the data should be arranged in all azimuth indexes then all elevation indexes for following Azimuth-Elevation CFAR detection process:
I think both arrangement are quite different, which leads to different CFAR detection results!
Shihyu.
Shihyu,
Are you finding that the format is not what you expect? In the function description, it states:
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 Shihyu,
Figure 34 shows [elev][azim] format. If you move down from top to bottom, the azimuth varies first, then the elevation. An array organized in [elev][azim] format would also vary first in azimuth, then in elevation. Your picture shows [azim][elev] format because moving downward (or upward in your case), you vary in elevation first, then in azimuth.
Best,
Nate
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:
2. For static scene 2D angle Bartlett beamforming process: (lines 119~177 in RADARDEMO_aoaEstimationBFSinglePeak_static() function in RADARDEMO_aoaEstimationBFSinglePeak_staticHeatMapEst.c)
(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 Shihyu,
What you're saying here aligns with my understanding. I cannot really confirm your understanding, but I can't see anything written that is noticeably incorrect. If there is a specific question to answer here I'd be happy to help, but otherwise I will close this thread.
Best,
Nate