• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 224 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.

IWR6843: CFARProcDSP Test -- Does one exist?

Alex Byrley
Intellectual 465 points
Part Number: IWR6843


I noticed under cfarcaproc/test in the 3.06 MMWAVE SDK there is only cfarprochwa_test_main.c -- there doesn't appear to be a similar unit test that uses the DSP despite the option of using it for CFAR on the IWR6843 in the OOB. Does one exist in another SDK that I can repurpose for the IWR6843 or does one exist somewhere on TI's developer's site?

Thanks! 

Alex

  • 0
    TI__Mastermind 37805 points

    Hi Alex,

    Asking about this internally. Ping this again tomorrow if you don't get an answer by EOD.

    Best,

    Nate

  • 0 in reply to Nathan Block
    TI__Mastermind 37805 points

    Hi Alex,

    The 6843 CFAR DSP pipeline relies on mmWavelib APIs for almost all the CFAR computes. These APIs/units are already covered therough the mmWavelib's unit testing (refer to lib.unittest.c). In addition, the objectdetdsp DPC chain' tests also cover this pipeline, which is why it's not a part of the DPU's test folder.

    Additionally, why use the DSP for CFAR in your application? The software team informs me that HWA will be significantly faster/more efficient.

    Best,

    Nate

  • 0 in reply to Nathan Block
    Intellectual 465 points

    Nathan -- thank you. I have been looking into the object detection DPC unit test and indeed I can modify it to fit my needs. I was just hoping for something more out of the box. 

    Interesting. I did not know that about the HWA. We are encountering a scenario of dense point clouds causing the 3.05 HWA-based firmware to crash. Our preliminary testing has shown that using the DSP allows the device to handle these point clouds much better than when the HWA is employed. So I am a bit confused as to why the HWA is considered faster/more efficient. 

    Well -- it is my understanding that the CFAR algorithms that are available when the HWA is employed are limited in number. So perhaps this "hard-coding" is why they are said to be faster/more efficient? In contrast, using the DSP instead of the HWA allows us to implement a wider variety of CFAR algorithms, which is probably why it is considered less efficient.  But this denser point cloud scenario we are encountering demands such a customized solution, which we have developed, tested on historical and simulated data, and are beginning to implement and deploy. Am I correct about this point or am I missing something about the HWA?


  • +1 in reply to Alex Byrley
    TI__Mastermind 37805 points

    Hi Alex,

    Alex Byrley said:
    So I am a bit confused as to why the HWA is considered faster/more efficient. 

    I think if you use the typical CFAR algorithms that do not require advanced statistics (CFAR-CA, CFAR-CAGO/CASO...) then the HWA is more efficient. But, if you're planning to do different statistics to estimate the noise power then I understand why you'd prefer the DSP. So I think you're correct :).

    Best,

    Nate