• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 199 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.

AWRL1432: 1432BSD v4.1RangeResolution

chunxiang yu
Prodigy 10 points
Part Number: AWRL1432

Tool/software:

In the version AWRL1432_ADAS_BSD_DEMO v4.1 code, I noticed that the calculation of gMmwMssMCB.numRangeBins as the following line:

gMmwMssMCB.numRangeBins = (int32_t) ceilf(((float)numRangeBinsTmp/4.0f)*0.90f)*4; // Process only 90% of the rangeBins.

This multiplication by 0.90f was not present in version 3.2. It seems to be an intentional change by TI, but it results in a 1.1 times increase in the subsequent calculation of rangeStep, which in turn causes the reported target distance to be 1.1x larger. Could you please explain the purpose of this 0.90f? Is it for the purpose of decreasing memory usage? BTW, the tlv type = 302 for rangeProfile output data also has a mismatch like length = 116 (128 points * 0.90 = 116 points) and still output data value = 128*4bytes. 

 

(2) During practical testing with version 4.1, I observed that at very close range, one or two persistent target points consistently appear. These seem to originate from DC leakage in the rangeProfile. When configuring rangeSelCfg via CLI, setting argument 1 (minMeters) too large causes the CFAR DPU to fail, while setting it too small does not remove the persistent close-range points. Could you clarify if there are any limitations or recommended guidelines for tackling these persistent targets?

  • 0
    TI__Guru*** 148334 points

    Hi,

    (1) The reason for multiplication by 0.9f are as follows:

    Reason1: Save Memory for future usage. Notice that BSD demo does not use this additional memory. This is available for customers to use.

    Reason2: Reduce Processing time

    chunxiang yu said:
    it results in a 1.1 times increase in the subsequent calculation of rangeStep, which in turn causes the reported target distance to be 1.1x larger.

    This is a bug that needs to be fixed. RangeStep should not be affected by the 0.9f

    chunxiang yu said:

    the tlv type = 302 for rangeProfile output data also has a mismatch like length = 116 (128 points * 0.90 = 116 points) and still output data value = 128*4bytes. 

     

    Yes, this is a bug that needs to be fixed

    We will fix the bugs in the next release

    thank you
    Cesar

  • 0 in reply to Cesar
    TI__Guru*** 148334 points

    For (2)

    Please let us know what is the "very close range"? What is too large in  "argument 1 (minMeters) too large "?

    If the persistent target points are always present, they could be removed after the detected points are computed by removing all points at very close range.

    thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 10 points

    Hello,Cesar:

    Thank you for your response. I think the first question has been resolved. For the second question, I need to wait for my colleague to finish the test before providing feedback to you.