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.

IWR6843AOP: Replicating AOP demo results with DSP processing from ISK demo, AOA vs AOA2D DPU

Part Number: IWR6843AOP

Tool/software:

In answer to a previous question, I was told the best performance for point cloud calculation was not DSP+HWA, but pure DSP as found in the ISK demo. Per the answer to the previous question, I have started converting the ISK software for the AOP.

I see that the AOP software uses a 2D AOA calculation, while the ISK software does not.

Should I expect to see identical results with the two different AOA calculations?

Again, to be clear, I just want the logical operation of the AOP demo, calculated at the fastest rate possible for the largest point clouds.

  • Hello,

    We will get back to you within 24 hours

    Best Regards,

    Pedrhom

  • Hello.

    I'm still a bit confused as to why you are trying to port the ISK project to AOP.  You can simply use the same ISK project but swap out the antenna_geometry file to match that of the AOP demo.  That way you are fully utilizing the DSP as in the ISK demo but able to run it on the AOP device.  Is there a reason you want to port it over as opposed to just changing the antenna_geometry.c file?

    Sincerely,

    Santosh

  • The main issue is just that I am ignorant, I think, and I'm trying to piece things together by reading documentation and this forum.

    I can easily change the ISK definition to AOP definition (the antenna_geometry files are actually the same, and this definition change is required). The software builds fine.

    However, now the options in the mmWave Demo Visualizer do not match.

    If I only change the define for the antenna_geometry.c, then only the "Platform: xWR68xx" option works (setting platform to "xWR68xx_AOP" fails with a mismatch error). However, the values for parameters do not match up between the AOP and non-AOP platforms, so that seems wrong. For instance, angular resolution is listed with different values for AOP vs non-AOP with the same number of TX/RX antennas.

    So I go and check for where the AOP software defines its platform string, and I find this:

    // mmwave_cli.c : Line 1335
        cliCfg.overridePlatform             = true;
    #if defined(USE_2D_AOA_DPU)
        cliCfg.overridePlatformString       = "xWR68xx_AOP";
    #else
        cliCfg.overridePlatformString       = "xWR64xx";
    #endif

    Okay, so now I'm really curious, because it seems that the 2D AOA DPU is a defining difference between the AOP and non-AOP chips. So important that the demo visualizer doesn't consider them compatible and the platform needs be special-cased.

    If I ignore the USE_2D_AOA_DPU define, and just force the override to "xWR68xx_AOP", and attempt to use the radar with the same CLI settings as my functional AOP demo example, it does not return any contact points at all (0 detected objects always, which implies an error to me). So it's clear that making the ISK demo fully work on the AOP is more than just changing the antenna geometry file.

    I'm just really confused. And reading the documentation confuses me more I guess, because every time I read it, it seems like I can make the DSP and HWA work in parallel and improve performance. It says things like "the EDMA transfers and the local core processing is done in parallel" (mmwave_sdk_03_06_02_00-LTS/packages/ti/datapath/dpc/dpu/aoa2dproc/docs/doxygen/html/index.html#aoa2d_dpu_intro_section).

  • Hello Aubrey.

    So the reason that the AOP project uses the AoA2D is because in the AOP project originally, it is only using the HWA, and the AoA2DProc is done on the HWA only as opposed to the AoAProc, which can be run on the HWA or the DSP.  I would keep the platform string the same to make sure that the appropriate DPUs are being used for the appropriate core, and modify the parameters that differ between the projects to set them correctly for the AOP project.  I assume by parameters you mean the configuration differences?

    Sincerely,

    Santosh

  • Ah, I see. Okay.

    Your assumption is correct. Configuration, yes.

    Thank you for the information.

  • I wish there were an answer to this question: https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1295468/awr6843-question-about-aoa-and-aoa2d-dpu

    I also wish that I'd found this thread earlier: https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1198162/iwr6843aop-importing-ccs-out-box-demo-project-spec-of-iwr6843isk-and-recompiling-it-for-aop-antenna-pattern

    I also wish TI would please just release a 6843AOP MSS+DSS version. There are obviously numerous people who literally just want to start from the fastest-possible, densest-possible point cloud and develop from there. Because we keep asking these questions about DSS, HWA, demo performance, and porting the apparently more-performant ISK demo.

  • Hello Aubrey.

    Thank you for your feedback.  SDK 3.6 is long term support, so the SDK will only get updated for critical issues/bugs.  However, if you have any other questions regarding the demo please feel free to post more questions on our E2E support forum!

    Sincerely,

    Santosh