AWRL6432: Detection Matrix Deviation.

Hello Bodhit,

Could you please describe the steps that you took to perform this test? Where you set breakpoints, the data that you load into the radar cube, your configuration (is it the SDK's parking_5m.cfg?), etc.

Best regards,
François.

Hello Francois, 

Please find stepwise description of the test below.

1. Config used : I am using the BYPASS_CLI to start the sensor automatically without giving any Config through Visualizer. The configuration values for this have been taken as it is from "parking_5m.cfg", Except "lowPowerCfg" made to 0 and "baudRate 1250000" command removed.

 Please find a screenshot  of the same here. 

2. BreakPoint  for 1D FFT input and Reference Detection Matrix : I put  Breakpoint1 just before the call to function "DPU_DopplerProcHWA_process". At this Point I save the existing Radar Cube (96Kb Size).

To collect Reference Detection matrix of the Corresponding Radar cube, I resume the pipeline for next frame. The execution hits Breakpoint1 again where i save the Reference Detection Matrix (16KB) memory corresponding to Input Radar Cube.

3. Collecting Multiple Detection Matrices for same RadarCube : I inject the saved RadarCube(in step 2) at Breakpoint1, hit resume in CCS and save the Detection Matrices in the same fashion as step 2 and performed a comparison.

These are the steps that i followed in the same order.

Please let me know if you have any questions.

Warm Regards

Bodhit Gupta

Hi Bodhit,

Thank you for the additional details. I'm looking into this and will follow up within a day or so.

Thanks again,

Clinton

Hi Bodhit,

I wanted to let you know I'm trying to reproducing this issue on my end. I'll follow up tomorrow.

Thanks,

Clinton

Hi Bodhit,

After looking into this further, the difference you are seeing in the detection matrices is most likely related to the dither added to FFT twiddle coefficients. Is this an issue for you?

Thanks,

Clinton

Hello Francois and Clinton,

Thanks for the response.

We are currently testing the changes suggested at our end.

However i had a question, How does the change in Range DPU(rangeprochwa.c), affect the Detection Matrix, which is a product of Doppler DPU ?

I would really appreciate if you can help me understand it.

Best Regards

Bodhit Gupta

Hello Bodhit,

You are correct, the detection matrix is at the Doppler DPU level, when the dithering happens at the range DPU level. However this dithering would affect the range DPU and propagate into the Doppler DPU, thus the detection matrix.

Looking forward to hearing the outcome of your test.

Best regards,
François.

Hello Francois,

Thankyou for the clarity. I understand that the changes in range DPU level get propagated to Doppler DPU and hence Detection Matrix.

But when I inject a Reference Radar Cube(collected previously with dithering Enabled) and discard the Real time dithering disabled RadarCube, just before the Doppler_process(), we still get matching Detection matrices which i am still not able to understand. 

Please allow us some more time so that we test this thoroughly at our end and get back to you with an update on the test.

Best Regards,

Bodhit Gupta

Hi Bodhit,

Could you provide an update on your testing?

Thanks,

Clinton

Hello Clinton,

We are able to get Matching Detection Matrices for same Radar cube injected every time by disabling the dithering in RangeDPU.

Can you please provide an explanation for this for my understanding :

"When I inject a Reference Radar Cube(collected previously with dithering Enabled) and discard the Real time dithering disabled RadarCube, just before the Doppler_process(), we still get matching Detection matrices which i am still not able to understand."

Thanks and Regards,

Bodhit

Hello Francois, 

Thankyou for the response.

However it still remains unclear to me how the effect of Disabling dithering be embedded in the Radar Cube, when I am injecting another Radar Cube(Dithering Enabled) and discarding the existing one whole together.

Since the injection of Dithering Enabled Radar Cube will be just before Doppler_process, I expect that the Detection Matrices should not match here. But somehow they match. I fail to understand so.

Please help me understand the same.

Thanks and Regards

Bodhit

Hello Bodhit,

Could you please describe exactly your datapath? What I am saying is that the dithering only affects the range processing, from the ADC data to the radar cube. What follows (Doppler, CFAR, AoA) only depends on the radar cube.

So I expect the Doppler processing output will be the same irrespective of the dithering setting if its input is the same radar cube.

The Doppler processing output will change with the dithering setting if its input is the same ADC data, because the ADC data goes first through the range processing which output depends on the dithering setting.

Best regards,
François.

Hi Francios,

Thank you for the fix, we are getting consistent det-matrix without any deviation/mis-match.

But we need some clarification here: Here we mentioned our debugging procedure that we followed:

1. Started working on base SDK and built the respective binaries.

2. In CCS, after loading the program, we kept a breakpoint at start of DPU_DopplerProcHWA_process function and ran the code.

3. After hitting the break point, we captured radar-cube, Since base SDK contains dither enabled Rangeproc DPU, the output is also dither enabled radar-cube

4. Did step over and collected the det-matrix also. 

5. Collected multiple det-matrix data with same dither enabled radar-cube and compared with each other. Observed that there is det-matrix mismatch.

At this point we raised this question in e2e.

6. After implementing the suggested fix (i.e., disabling dither in Rangeproc DPU), we again collected multiple det-matrix data using the same dither enabled radar cube captured in Step 3 and observed that there is no mismatch.

We can understand that  dither disabled radar-cube should give same det-matrix, but why the dither enabled radar-cube is giving consistent det-matrix output after implementing fix in range proc DPU.
By seeing this, We have a question: Is there any configuration dependency/leakage happening from range proc DPU to doppler proc DPU. If not, why the dither enabled radar-cube is giving consistent det-matrix output after implementing the fix in range proc DPU but not having any configurational change in Doppler DPU?

I hope our question is more clear now. Please let me know if you have any questions in our debugging procedure.

Regards
M Girish Veerendra

I wanted to note here that this information is being evaluated.

Thanks,

Clinton

Hi Clinton, please let us know if there are any updates.

Hi Girish,

I'm trying to recreate your issue on my end. I plan to follow up later today.

Thanks,

Clinton