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.

IWR6843ISK-ODS: range values are smaller than expected

Part Number: IWR6843ISK-ODS

Hi,

I have evaluated range value of point cloud data using following package.

ti\mmwave_industrial_toolbox_3_3_1\labs\lab0020_pplcount_Overhead\GUI_A_base_no_logic

As a result, range values were smaller than expected.

My understanding is that range accuracy is depends on chirp bandwidth, independent of distance from a radar. Moreover, most of values are smaller, not larger.

Do you have any idea for the reason why my results ?


Example of the data:

1. Set the radar board at the ceiling height 2.7 meter.

2. Stand a person whom height is 1.7 meter at the 1 meter horizontal distance from the radar board.

3. The range value is expected at least 1.4 meter calculated as following,

SQRT(1^2 + (2.7-1.7)^2) = 1.4

Obtained data in the test are following

frame ID   Range       Elevation(degree)   Azimuth [degree]

57173       1.02279     -7.18076                39.04575

57177        1.07962    -7.18076                39.04575 ...

Range value averaged 30 seconds is 1.27 meter < 1.4 meter

Same as above, other results are

horizontal distance           expected range          obtained range

2 meter                             2.24 meter                 1.90 meter

3 meter                             3.16 meter                 2.49 meter

Best regards,

Fountain

  • Hi Fountain,

    How did you determine that the points whose distance you are checking are detection points from the person under the sensor? Did you use the index list from the tracker output?

    Regards,

    Justin

  • Hi Justin,

    I have used serial output. I have referred following document.

    ti\mmwave_industrial_toolbox_3_3_1\labs\lab0020_pplcount_Overhead\docs\Overhead_People_Tracking_and_Stance_Detection_users_guide.pdf

    I have parsed TLVs, and associated point clouds with targets using "Target Index TLV".
    Because the test was done with only one person, it was easy and clear to associate person and the target.

  • Hi Fountain,

    Two things to check:

    1. Are you using the default chirp? If not, what is the range resolution of the chirp you are using?
    2. In a situation with the device pointed directly at the person, do you notice range inaccuracy? 
      1. Have you done other range tests before?

    Regards,

    Justin

  • Hi, Justin,

    Thank you for your confirmation.

    1. Yes, I used the default chirp following. The range resolution is 7.57 cm with my calculation.

    \ti\mmwave_industrial_toolbox_3_3_1\labs\lab0020_pplcount_Overhead\GUI_A_base_no_logic\mmw_pplcount_demo_default.cfg

    2. It seems same phenomenon to see the provided visualization application (main_pplcount_viz.exe).

    2-a Not yet. This is the first evaluation for IWR6843ISK-ODS.

    Best regards,

    Fountain

  • Hi Fountain,

    I want to try to isolate the issue:

    1. If you have an ISK, there is a version of this demo available for ISK. The difference is the Angle of Arrival function - can you confirm that you experience this issue with that firmware? Does not need to be ceiling mount, just interested in range.
    2. Can you try using lab0025 - ODS Point Cloud? Signal chain software is almost identical, I want to see if the issue persists on this software.
    3. Can you try a chirp with different range resolution? I want to see if the error changes with different range resolution.

    Regards,

    Justin

  • Hi Justin,

    I am Big Fields, and now investigating this issue with Fountain. I ask you some questions on behalf of Fountain.

    Questions to your questions...

    1. Yes, we do have ISK. Looking inside of the folder "mmwave_industrial_toolbox_3_4_0__win\mmwave_industrial_toolbox_3_4_0\labs\lab0020_pplcount_Overhead\Pre-compiled Binary", there are AoP, ISK and ODS folders. Do you mean that I should flash "ISK\isk_pplcount_lab_68xx.bin" to ISK module and do the same experiment?

    2. lab0025 is for ODS, so I will flash "ods_point_cloud_68xx.bin" to ODS module and do the same experiment. Is the procedure correct?

    I will share the results later. 

    Best regards,

    Fields

  • Hi Fields,

    I would like you to complete the tests as you outlined them above. It will allow us to determine what is causing the issue.

    Regards,

    Justin

  • Hi Justin,

    By the way, could you please tell me the data format of serial output of lab0025?

    We managed to receive serial data from radar with lab0025 firmware flashed, but we can't parse it based on the data format of lab0020(TLV, point cloud, target list, index). As a result, we can't get range, azimuth, elevation and velocity values.

    It seems that the lab0025 data has different data format from lab0020.

    Best regards,

    Fields

  • Hi Fields,

    The output format of lab0025 is described in the SDK1.1.x user's guide.  This is because this demo was built on an older SDK out of box demo.

    Regards,

    Justin

  • Hi Justin,

    I completed the test you required.

    Please check the file below.

    Experiment 1 and 2 tell the problem we are facing.

    Experiment 3 tells the result when using ISK.

    Experiment 4 tells the result when using lab0025.

    Experiment 5 tells the result when setting different range resolution.

    Best regards,

    Fields

    range_resolution.ppt

  • Hi Big Fields,

    Please make the following change to the software:

    Line 1870 in src/dss/dss_main.c - 

    dataPathObj->rangeResolution = MMWDEMO_SPEED_OF_LIGHT_IN_METERS_PER_SEC *
    profileCfg.digOutSampleRate * 1e3 /
    (2 * (profileCfg.freqSlopeConst) * ((3.6*1e3*900) /
    (1U << 26)) * 1e12 * dataPathObj->numRangeBins);

    Change to:

    dataPathObj->rangeResolution = MMWDEMO_SPEED_OF_LIGHT_IN_METERS_PER_SEC *
    profileCfg.digOutSampleRate * 1e3 /
    (2 * (profileCfg.freqSlopeConst) * ((2.7*1e3*900) /
    (1U << 26)) * 1e12 * dataPathObj->numRangeBins);

    The range resolution is being calculated improperly, which is leading to the range to be calculated as 3/4 the true value.

    Thank you for finding this bug.

    Regards,

    Justin