• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 35 subscribers
  • Views 465 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.

AWRL6432: DPIF_DetMatrix data format

Daniel Cheng1
Mastermind 8275 points

Part Number: AWRL6432

Hi Expert,

SDK:MMWAVE_L_SDK_05_05_02_0

Example:radar_toolbox_3_20_00_04 / Automotive_InCabin_Security_and_Safety / AWRL6432_Life_Presence_Detection_Demo_Capon2D.

I am currently trying to retrieve the data after running Capon2D. Based on the example, the data is stored in detMatrix->data. According to the DPIF_DetMatrix Struct Reference, it only defines one format and arrangement. However, in the example, a custom format (format 2) is used without specifying the arrangement.

Is there any way to know the exact data layout? For instance, something like: uint16_t x[azimuthFftSize][elevationFftSize][numRangeBins].
Additionally, for Capon1D, is the data also stored in detMatrix? If so, what are the differences in the arrangement compared to Capon2D?

Any clarification or documentation on this would be greatly appreciated.

 

 

Daniel

  • 0
    TI__Expert 4520 points

    Hi Daniel,

    Thank you for reaching out. I have looped in an expert in this topic, please allow them a few days to look into this and get back to you with some answers.

    Best,
    Vignesh K.

  • 0
    TI__Mastermind 45615 points

    Hi, there:

    For capon1D, the detMatrix is two dimensional, like uint32_t x[numRangeBins][azimuthFftSize]

    For capon2D, the detMatrix is three dimentional, like uint32_t x[elevationFftSize][numRangeBins][azimuthFftSize]

    The first dimension is azimuth index

    The second dimension is range Index

    the third dimension is elevation index. 

    Let me know if it makes sense.

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Prodigy 50 points

    Hi Zigang,

    Thank you for your previous guidance.

    I’ve conducted additional tests on the Capon2D demo and would like to share detailed observations regarding the Range–Angle Map (RAM) behavior under different configurations, especially when increasing the azimuth FFT size to 64.

    For clarity, all RAM images referenced below are generated by slicing the detMatrix at the mid-point of the elevation dimension: (obj->cfg.staticCfg.elevationFftSize >> 1)

    Test Results Summary

    Case NumOfAdcSamples Azimuth FFT Elevation FFT Observation
    Default 128 32 16 Expected behavior (Fig. 1)
    Case A 64 32 16 Expected behavior (Fig. 2)
    Case B 64 64 8 No output observed
    Case C 64 64 16 Output present but RAM pattern appears abnormal (Fig. 3)
    Note:
    Due to UART bandwidth limitations, only a subset of range bins is transmitted for visualization.
    The full detMatrix is still generated internally based on the configured parameters.
    Questions for Clarification

    1. Support for azimuthFftSize = 64
      Is azimuthFftSize = 64 officially supported in the current
      radar_toolbox_3_20_00_04 / AWRL6432_Life_Presence_Detection_Demo_Capon2D implementation?
      If so, could you please share a known working configuration, recommended parameter set, or any required patch / constraint?

    2. Minimum elevation FFT size constraint
      In Case B, no output is produced when elevationFftSize = 8.
      I suspect there may be a constraint or assumption in caponbeamforminghwa.c (e.g., HWA memory layout or param-set configuration).

      • Is there a minimum requirement that elevationFftSize >= 16 for Capon2D?

      • If yes, is there any recommended modification or workaround to support smaller elevation FFT sizes?

    Your clarification on these points would help us better understand the supported parameter space and any underlying HWA or memory limitations.

    Thank you very much for your support.

    Best regards,
    Maureen

  • 0 in reply to Maureen Mao
    TI__Mastermind 45615 points

    Hi, there:

    I have tried the demo with different azimuth and elevation FFT size on my side.  I agree with your observations.

    We have never tried other FFT size.  And I will need some time to look deeper into this problem.

    Best,

    Zigang

  • 0 in reply to zigang Yang
    TI__Mastermind 45615 points

    Hi, there:

    I have confirmed with our designer, we have a hard memory limited. The following condition must be satisfied: NumberOfAntennas x elevationFftSize x AzimuthFfftSize * sizeof(uint32) < 16KB. With default parameters, 6 antennas, elevationFft = 16, azimuthFft =32, the size in M0 is 12288Bytes, that fits in M0.

    So, we can not do 64 azimuth FFT and 16 elevation FFT. 

    But elevationFft = 8, azimuthFft =32, should work. It could be a bug on our size.  Will need some time to debug it.  Will get back to you as soon as we have a clue.

    Best,

    Zigang

  • 0 in reply to zigang Yang
    Prodigy 50 points

    Hi Zigang,

    Thank you for the detailed update and for checking the memory constraints with the designer — much appreciated.

    Once you have finished debugging the elevationFft = 8 and azimuthFft = 32 case, could you please also help confirm whether the combination of elevationFft = 8 and azimuthFft = 64 is supported as well?

    Based on the same formula and assuming 6 antennas, this configuration would also result in 12,288 bytes, which is still below the 16 KB limit.

    Thanks again for your support.

    Best,
    Maureen

  • 0 in reply to Maureen Mao
    TI__Mastermind 45615 points

    Hi, Maureen:

    I was able to figure out why elevation FFT size = 8 does not work.  

    Inside function caponBeamformingHWA_ConfigHWA in caponbeamforminghwa.c, you can find the following code lines

    if(cfg->staticCfg.numAnglesToSampleElevation == 16) hwaParamCfg.accelModeArgs.fftMode.fftSize = 4;
    else if(cfg->staticCfg.numAnglesToSampleElevation == 32) hwaParamCfg.accelModeArgs.fftMode.fftSize = 5;
    else if(cfg->staticCfg.numAnglesToSampleElevation == 64) hwaParamCfg.accelModeArgs.fftMode.fftSize = 6;

    Basically, the elevation FFT size = 8 is not supported.   After I add the option for 8 as below, the code runs. 

    if(cfg->staticCfg.numAnglesToSampleElevation == 8) hwaParamCfg.accelModeArgs.fftMode.fftSize = 3;
    else if(cfg->staticCfg.numAnglesToSampleElevation == 16) hwaParamCfg.accelModeArgs.fftMode.fftSize = 4;
    else if(cfg->staticCfg.numAnglesToSampleElevation == 32) hwaParamCfg.accelModeArgs.fftMode.fftSize = 5;
    else if(cfg->staticCfg.numAnglesToSampleElevation == 64) hwaParamCfg.accelModeArgs.fftMode.fftSize = 6;

    However, the performance with Elevation FFT size = 8 is not good.  I am still working on debug this issue.

    Best,

    Zigang 

  • 0 in reply to zigang Yang
    Prodigy 50 points

    Hi Zigang,

    Thanks a lot for finding the root cause and for adding the elevation FFT size = 8 support.
    Good performance with the combination of elevation FFT size = 8 and azimuthFft = 64 is exactly what I’m looking for, so I really appreciate you continuing to debug this.

    Thanks again for the help.

    Best,
    Maureen

  • 0 in reply to Maureen Mao
    TI__Mastermind 45615 points

    Hi, Maureen:

    I will keep you updated. 

    Best,

    Zigang

  • 0 in reply to zigang Yang
    TI__Mastermind 38575 points

    Hi Bibben,

    I do not think the 2D capon demo is designed to support the smaller elevation FFT size that you are looking for here based off Zigang’s responses. This demo is designed to show balanced performance in both azimuth and elevation domains.

    Why are you trying to reduce elevation FFT size here? Is the real goal here to support a 64-point azimuth FFT, and you think you need an 8-pt elevation FFT to allow this? Have you explored reducing the number of doppler bins?

    Best,

    Nate