• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 850 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: AoAProcDSP Question -- Why is max_index the same for both elevation and azimuth ffts?

Alex Byrley
Intellectual 465 points
Part Number: IWR6843

So in aoaprocdsp.c, specifically AoAProcDSP_XYZEstimation() we have the following:


peakAzimIm = (float) azimuthFftOut[maxIdx].imag;
peakAzimRe = (float) azimuthFftOut[maxIdx].real;
peakElevIm = (float) res->elevationFftOut[maxIdx].imag;
peakElevRe = (float) res->elevationFftOut[maxIdx].real;

where max_index gets passed in as a parameter

/**
 *  @b Description
 *  @n
 *      This function is called per object and it calculates its x/y/z coordinates
 *      based on Azimuth/elevation FFT outputs. It stores the coordinates
 *      to the output list of type @ref DPIF_PointCloudCartesian_t and it also
 *      calculates object's SNR and the noise level and writes into the side
 *      information list of type @ref DPIF_PointCloudSideInfo_t
 *
 *  @param[in] aoaDspObj Pointer to AoA DPU internal object
 *
 *  @param[in] objOutIdx Index of the current object in the output lists @ref DPIF_PointCloudCartesian_t and @ref DPIF_PointCloudSideInfo_t
 *
 *  @param[in] objInCfarIdx Index of the current object in CFAR output list @ref DPIF_CFARDetList_t
 *
 *  @param[in] maxIdx Peak position in the FFT output of azimuth antennas
 *
 *  @param[in] dopplerSignIdx The signed Doppler index
 *
 *  @retval objOutIdx Index for the next object in the output list
 *
 *
 *  \ingroup    DPU_AOAPROC_INTERNAL_FUNCTION
 *
 */
static uint32_t AoAProcDSP_XYZestimation
(
    AOADspObj   *aoaDspObj,
    uint32_t    objOutIdx,
    uint32_t    objInCfarIdx,
    uint32_t    maxIdx,
    int32_t     dopplerSignIdx
)
The code seems to be saying that the peak index in azimuth is the same as the peak index in elevation. Is this what is going on here? 

If so, it doesn't seem quite right. You can imagine a scenario where the target moves directly towards the radar, thereby changing the elevation angle while the azimuth stays constant. 

We see this separation in the function AoAProcHWA_XYZestimationAoA2D() that is part of the AoAHWA2D DPU. This function seems to have different indices for elevation and azimuth peaks, as would make sense. 

So, to put it bluntly, is there something wrong with the AoAProcDSP XYZ estimation or is this intended functionality? 
  • 0
    TI__Genius 13276 points

    Hey Alex,

    Thanks for reaching out regarding your question. One of our experts on DSP will get back to you either today or Monday.

    Regards,

    Kristien

  • 0
    TI__Mastermind 40495 points

    Hi, there:

    Can you let me know which demo you are using and which antenna pattern you are using?  It is hard to get into the lower level DPU code without understanding which application it is for.  The code may not be even used by any demo. 

    Best,

    Zigang 

  • 0 in reply to zigang Yang
    Intellectual 465 points

    Sure -- I am using the IWR6843-ODS and am using the OOB demo. My version uses the RangeProcHWA DPU, and the DopplerProcDSP DPU, the CFARProcDSP DPU and the AoAProcDSP DPU. 

  • 0 in reply to Alex Byrley
    TI__Mastermind 40495 points

    HI, Alex:

    It seems that you are developing your own demo.  Is it correct?   Which TI demo you are based on to start your development?  Can you explain where you get the idea that AoAProcDSP DPU should be used?

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Intellectual 465 points

    I suppose I am -- I am just trying to use the other DPUs. I got the idea because the AoAProcDSP DPU is included in the SDK, so my assumption is that it can be used for AoA processing. Is this not correct? Should the AoAProcDSP DPU not be used? If so, does this imply that the DPU is not functioning as intended -- ie to form pointclouds? 

  • 0 in reply to Alex Byrley
    TI__Mastermind 40495 points

    HI, Alex:

    If you download the latest radar mmwave Toolbox at: https://dev.ti.com/tirex/explore/node?node=A__AGvTEJkh-csqqwXnVhDbTQ__radar_toolbox__1AslXXD__LATEST

    And go to the out-of-box demo directory

    C:\ti\radar_toolbox_1_xx_xx_xx\source\ti\examples\Out_Of_Box_Demo\src\xwr6843ODS

    You can find the ccs project spec as out_of_box_6843_ods.projectspec

    You can find the information on line 67, it means that a0a2dproc is used instead of aoaproc module. 

            -I${COM_TI_MMWAVE_SDK_INSTALL_DIR}/packages/ti/datapath/dpc/dpu/aoa2dproc/lib

    You can find the information for other EVM board.  LIke AOP is using the same aoa2dproc DPU.  Only ISK board is using aoaproc DPU.   

    If you want to understand the difference between these two angle estimation DPU, you can find the Doxygen documentation (after you download SDK)

    file:///C:/ti/mmwave_sdk_03_05_00_04/packages/ti/datapath/dpc/dpu/aoaproc/docs/doxygen/html/index.html

    file:///C:/ti/mmwave_sdk_03_05_00_04/packages/ti/datapath/dpc/dpu/aoa2dproc/docs/doxygen/html/index.html

    Please replace the highlighted sdk version name to match your download SDK version. 

    Let me know if it is helpful.

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Intellectual 465 points

    I have seen all of that documentation and I think I understand the idea behind the algorithms as a result.

    Is there a reason why the only the ISK board is using the aoaproc DPU while the AOP/ODS come standard with the aoa2dproc DPU? Should I not be using the aoaproc DPU with the ODS board?

    I want to move everything over to use the DSP DPUs because they offer a lot of flexibility to (eventually) change the algorithms while we cannot see the HWA internals or change how those algorithms work (beyond a few config changes). 

    But is this not going to work because the aoaproc DSP DPU not meant for the ODS board? 

  • 0 in reply to Alex Byrley
    Intellectual 465 points

    I have seen all of that documentation and I think I understand the idea behind the algorithms as a result. I have also seen this article -- https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9658500 -- which is great in explaining the basic ideas behind each step.

    Is there a reason why the only the ISK board is using the aoaproc DPU while the AOP/ODS come standard with the aoa2dproc DPU? Should I not be using the aoaproc DPU with the ODS board?

    I want to move everything over to use the DSP DPUs because they offer a lot of flexibility to (eventually) change the algorithms while we cannot see the HWA internals or change how those algorithms work (beyond a few config changes). 

    But is this not going to work because the aoaproc DSP DPU not meant for the ODS board? 

  • 0 in reply to Alex Byrley
    TI__Mastermind 40495 points

    Hi, Alex:

    aoaProc just apply 1D FFT on the one angle dimension (azimuth), and the algorithm will find the peak on azimuth dimension, and then calculated the elevation angle based on the peak of azimuth angle.   For ISK board, there are 8 visual antenna in azimuth dimension (same elevation), so the first step uses 8 visual antenna.   However, if you apply the same algorithm to ODS board, then we only have 4 visual antenna in azimuth dimension (same elevation), we are not fully using all the visual antenna.   

    On the other hand, aoa2DProc uses all the visual antenna to apply 2D FFT on both angle dimensions and all the 12 visual antennas are used in this process.  However, due to memory limitation, the angle FFT size is usually smaller compared to the azimuth FFT size used in aoaProc DPU.  

    Hope you have this information helpful.

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Intellectual 465 points

    Ah I got it -- so a 1D FFT is expected to be less accurate using the ODS board, (if we used one azimuth row that is), but the code as is isn't setup for the ODS antenna arrangement anyway. If we do use the existing 1D aoaproc code anyway, we are putting antennas that are not at the same elevation in the same FFT, and thus the result should be nonsensical as the delays from the differing elevation will cause errors in the azimuth measurement.

    In order to use the DSP then, we will need to perform a true 2D FFT, but that is not implemented anywhere except in the HWA, whose code we don't have access to. Is that correct? 

  • +1 in reply to Alex Byrley
    TI__Mastermind 40495 points

    Hi, Alex:

    See my answers below:

    so a 1D FFT is expected to be less accurate using the ODS board, (if we used one azimuth row that is), but the code as is isn't setup for the ODS antenna arrangement anyway. If we do use the existing 1D aoaproc code anyway, we are putting antennas that are not at the same elevation in the same FFT, and thus the result should be nonsensical as the delays from the differing elevation will cause errors in the azimuth measurement?  

    [ZY] You are right.  The aoaProc assumes the ISK type of antenna and does not support any other antenna like AOP or ODS. 

    In order to use the DSP then, we will need to perform a true 2D FFT, but that is not implemented anywhere except in the HWA, whose code we don't have access to. Is that correct? 

    [ZY] You can find a DSP-based a0a2dProc at radar toolbox C:\ti\radar_toolbox_1_xx_xx_xx\source\ti\dpu\aoaproc\src\aoa2dprocdsp.c.  You will need to install the radar toolbox (if you have not do that before) (https://dev.ti.com/tirex/explore/node?node=A__AGvTEJkh-csqqwXnVhDbTQ__radar_toolbox__1AslXXD__LATEST) and replace the toolbox version at the directory above.

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Intellectual 465 points



    I have a follow up question:

    We see in the DSP AoA processing diagram -- C:\ti\mmwave_sdk_03_06_00_00-LTS\packages\ti\datapath\dpc\dpu\aoaproc\docs\dsp_aoa.png -- that the symbols from Tx0 and Tx1 are considered for the azimuth FFT and those from Tx2 are considered for the elevation FFT.

    But according to the geometry -- C:\ti\mmwave_sdk_03_06_00_00-LTS\packages\ti\datapath\dpc\dpu\aoa2dproc\docs\antenna_geometries.png -- should it not be that Tx0 and Tx2 should be considered for the azimuth FFT? Or does this diagram mislabel Tx0, Tx1 and Tx2? Or does the code order them differently? Or does the ISK use a different ordering in practice?

  • 0 in reply to Alex Byrley
    TI__Mastermind 40495 points

    HI, Alex:

    If you check the chirp definition, you will find the chirp order is TX0, TX2 and Tx1.  So the first 8 visual antenna represent the signal from TX0 and Tx2 and are good for azimuth estimation.

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Intellectual 465 points

    Got it -- thanks :-)