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.

AWR2944EVM: AWR2944 DDMA maximum velocity issue

Part Number: AWR2944EVM
Other Parts Discussed in Thread: AWR2944

Hi

 

We are trying to verify the maximum velocity of DDMA method of AWR2944 device which maximum velocity can reach 140kph.

In our experiment result, we find that the velocity can reach -140kph in negative region while in positive region, it only reach 50kph.

When the velocity exceeds 50kph, the velocity value will be wrong.

 

From the document ti/mmwave_mcuplus_sdk_04_02_00_02/mmwave_mcuplus_sdk_04_02_00_02/ti/datapath/dpc/dpu/dopplerprocDDMA/docs/doxygen/html/index.html.

We find that the doppler is selected from Z-value. If the velocity is negative, the maximum Z-value will be Z1, Z2 or Z3.

However, if the velocity is positive, the maximum Z-value will be Z4, Z5 or Z6 which will wrap the S1 to S3 value back from the spectrum.

 

But the c code in C:\ti\mmwave_automotive_toolbox_3_6_0\labs\lab0015_high_end_corner_radar\src\datapath\dpc\dpu\dopplerprocDDMA\src\dopplerprochwaDDMA.c (line 1052-1151),

when calculate Z4, Z5, Z6, the value S1, S2, S3 are from the next chirp rather than wrapping back the same chirp S1,S2, S3 values. (Flow chart in red line block, DDMA Matric step)

 

I think without the wrapping back, it may cause the wrong positive velocity.

How to modify the c code to solve this problem?

Thank you.

Best Regards, 

Wei Sung

  • Hi Wei,

    I am going to have a discussion with the developer of the SDK datapath, which is in most part borrowed by the high end corner radar as well. It is my understanding that the shuffleMode being configured to HWA_SRC_SHUFFLE_AB_MODE_ADIM in the source configuration of the DDMA metric paramset should provide the wraparound needed to compute Z4, Z5, Z6. I will nonetheless confirm this.

    Can I ask for more details about the test setup used to determine that velocities above 50kpmh are not detected properly?

    Thanks & Regards,

    Aayush

  • Hi Aayush,

    We use the radar simulator to setup the object's velocity. When we set the velocity equal to 50kph, the real velocity we observed is about 0kph rather than turn back to negative maximum velocity.

    The wraparound in the shuffleMode is done after all chirps but the Z4, Z5, Z6 we need to compute are wraparound every 6 chirps (6 sub band for AWR2944). So i guess the mistake is caused by this wrong wraparound mechanism.

    Thanks & Regards,

    WeiSung Jen

  • Hi Aayush,

    Below are the experiment result.

    In Fig. 1 the tested velocity are in negative region, and the results are pretty close to expected. however, at -150kph, there is an error detected velocity occurred.

    Moreover, in Fig. 2, the velocity are still correct with different value  in negative region.

    On the contrary, as the velocity goes positive near 50kph, the detected values  became  completely wrong. However, as velocity is near 150kph, the detected value goes wrong again.

    This is what I mention before, if the velocity is negative, the maximum Z-value will be Z1, Z2 or Z3 which doesn't need wraparound and make results corrected.

    However, if the velocity is positive, the maximum Z-value will be Z4, Z5 or Z6 which need wraparound to get S1 to S3 value.

    And the wraparound in the shuffleMode is done after all chirps but the Z4, Z5, Z6 we need to compute are wraparound every 6 chirps. So I guess the mistake is due to  this wrong wraparound mechanism.

    The red blocks represent the wrong velocity

    (figure 1)

    (figure 2)

    (figure 3)

    (figure 4)

  • Hi WeiSung Jen,

    Thank you for sharing the results. I have looped in the relevant people for this, and I will let you know as soon as we root cause the issue on our side and have a fix.

     

    Thanks & Regards,

    Aayush

  • Hi Aayush,

    Thank you. 

    Best Regards,

    WeiSung Jen

  • Hi,

    Apologies for the delay. We were able to replicate, root cause and fix the issue. It will be fixed in the next release. The bug was in DPC_ObjDet_estimateXYZ function in ti\datapath\dpc\objectdetection\objdethwaDDMA\src\objectdetection.c. The HWA paramsets programmed did not have an issue with the wraparound.

    I am attaching the fixed file that can be dropped into SDK 4.2.0.2 as a patch.

    0336.objectdetection.c

    Regards,

    Aayush

  • Hi Aayush,

    Thank you for fixing this problem, we will try whether it work later.

    Regards,

    WeiSung Jen