• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 29 subscribers
  • Views 137 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.

AWRL1432BOOST-BSD: Questions Regarding Non-Coherent Summation and SNR Calculation in AWRL1432 BSD v4.1

Hsu Yuri
Prodigy 60 points
Part Number: AWRL1432BOOST-BSD

Tool/software:

Dear TI Team,

I would like to inquire about the implementation of Non-Coherent Summation and the detection matrix for SNR value in the TI 1432BSD Demo v4.1, particularly focusing on the Doppler DPU.

As I understand, there are two non-coherent summation stages involved in the Doppler processing:

  1. Sum of Doppler FFT output absolute values across Rx antennas

  2. Sum (or Max) of Doppler FFT output absolute values across DDMA bands
    (From the demo, it uses SUM)

While examining the dopplerProcHWA_ConfigHWA function, I have a couple of questions:

1. Regarding averaging in non-coherent summation across Rx channels

In this stage, HWA_FFT_MODE_OUTPUT_SUM_STATS is used, which performs accumulation only. However, I am wondering why this summation is not followed by an averaging step (i.e., division by the number of Rx channels).

Is this because the averaging is deferred until the final SNR computation, where the detection matrix is used to extract the SNR, and then divided by the number of non-coherent summed elements?

However, from the code, I did not find such a division mechanism:

noisedB = DPU_CFAR_CONV_LOG2Q11_TO_20LOG10((float)cfarCellNoise);
snrdB = DPU_CFAR_CONV_LOG2Q11_TO_20LOG10((float) detMatLog2[rangeIdx * numDopplerBinsPerBand + dopplerIdx]) - noisedB;

Wouldn’t this result in an SNR value that does not properly account for the non-coherent summation?
For example, in mmwave_automotive_toolbox_3_2_0, specifically in lab0007 medium_range_radar, the non-coherently summed values are explicitly divided by the number of summations:

/* 4. Note that the peakVal is taken from the sumAbsRange. */
detObj2DRaw[numDetObj2D].peakVal = sumAbsRange[rangeIdx] >> obj->log2numVirtAnt;
/* 5. Note that the SNR is taken from the CFAR output. */
detObj2DRaw[numDetObj2D].rangeSNRdB = cfarDetObjSNR[detIdx2] >> obj->log2numVirtAnt;

Could you clarify why this averaging is not applied in the 1432BSD demo? Or is it perhaps handled implicitly at a later stage in the processing chain?

2. Regarding summation across DDMA bands and averaging

This step sums the Doppler FFT output absolute values across DDMA bands, and from the configuration:

cfg->staticCfg.detectionMode == DPU_DOPPLERPROCHWA_DDM_SUM_ACROSS_BANDS

Additionally, I noticed in the code that the following line is used:

hwaParamCfg.accelModeArgs.fftMode.butterflyScaling = (cfg->staticCfg.numDDMABands-1); //ToDo: tweak scaling, now we average

I would like to ask:

  • Why is the scaling value set to numDDMABands - 1?

  • Is this step intended to perform an average across the 4 DDMA bands after non-coherent summation across DDMA bands?

  • Why is averaging applied across DDMA bands, but not across Rx channels in previous question?

I would appreciate any clarification regarding the rationale behind these design choices.

Thank you for your support.

Best regards,

Yuri