• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 402 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

IWR6843ISK-ODS: Automotive toolbox / Overhead mount occupancy lab: peak search algorithm

Nikolay Olyunin1
Prodigy 60 points
Part Number: IWR6843ISK-ODS

Hi.

I am customizing Overhead mount occupancy lab from Automotive toolbox.

Perhaps, there is a small bug in Capon3d module.

The CFAR function in RADARDEMO_detectionCFAR_priv.c includes "neighbour check" logic for local maxima. A local peak is detected if it is higher than sidelobeThr * azMaxPerRangeBin[localRangeInd]. See lines 1374, 1415, 1454 in RADARDEMO_detectionCFAR_priv.c file .

However, the array azMaxPerRangeBin is not filled out, because every time when the heatmap calculating function RADARDEMO_aoaEst2DCaponBF_raHeatmap is called, it writes the max. value into the first element of azMaxPerRangeBin array.

Therefore, random values are used as thresholds in the detection logic in CFAR function.

Can I reach the developers of the lab through this forum, to confirm whether it is a bug indeed or my misunderstanding?

Thank you!

  • 0
    TI__Genius 17265 points

    Hi,

    Please allow me some time to take a look into this and get back to you. Thanks for calling this out!

    Best Regards,
    Alec

  • 0
    TI__Genius 17265 points

    Hi,

    I followed your logic and I believe you are correct, but I am checking with the team who originally created this module to ensure that there is nothing that we have both missed, and will keep you updated. If you believe you can resolve it in your environment, I would encourage you to try it out and see if it gets you the expected results and keep me updated.

    Best Regards,
    Alec

  • 0
    TI__Genius 17265 points

    Hi,

    They got back to me already, and have cleared things up. If you refer to radarProcess.c, you'll see that before we call RADARDEMO_aoaEst2DCaponBF_run, we update the rangeIndx, and then inside of RADARDEMO_aoaEst2DCaponBF_run when we call RADARDEMO_aoaEst2DCaponBF_raHeatmap, we pass in the address of the specific range bin using the rangeIndx. Let me know if this makes sense or if you have any further questions.

    Best Regards,
    Alec

  • 0 in reply to Alec May
    Prodigy 60 points

    Hi Alec,

    I think the answer of the developers may be applicable to some other lab, but not to the lab which I mentioned (\mmwave_automotive_toolbox_3_3_0\labs\incabinsensing\overhead_mount_occupancy).

    I checked once again the execution of Capon3d module in that lab using debugger. I used the original code with following changes:

    - turned off optimization in DSS;

    - commented out the assertion in DPC which checks if previous frame processing was completed.

    Here is what I found.

    1) In the call of RADARDEMO_aoaEst2DCaponBF_raHeatmap we pass the the first range bin address of max. value array (see yellow highlight on the screenshot below):

    2) Further, after calling RADARDEMO_aoaEst2DCaponBF_raHeatmap two times (for two antenna rows), we square and sum up the calculation results for two antenna rows. Therefore, the max. value has to be re-calculated anyway (even if we pass the correct range bin address). However, the re-calculation is not done.

    I believe, following change in RADARDEMO_aoaEst2DCaponBF.c file would fix the issue (provided that the first range bin is ignored).

    I have confirmed that in the original code the array azMaxPerRangeBin used for thresholding in RADARDEMO_detectionCFAR_raCAAll function contains random float values. Whereas after the change which I suggested above, the non-ignored range bin elements of azMaxPerRangeBin contain the expected data: maximum values of range bins in the calculated heatmap.

    I would appreciate if you confirm whether the above is correct or not.

    Thank you,

    Nikolay

  • 0 in reply to Nikolay Olyunin1
    TI__Genius 17265 points

    Nikolay,

    Ah I see, my apologies, I think when my colleague and I discussed we looked at the version from Industrial Toolbox. Your logic looks pretty straightforward here, so I don't see much risk, but I will try to discuss this with the owners and make sure we can validate it.

    Best Regards,
    Alec