• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 949 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.

IWR1642: constant 48279762268.06641 in range resolution formula

Gennadii Lichkov
Intellectual 930 points
Part Number: IWR1642
Other Parts Discussed in Thread: IWR1443

Hi,

There is range resolution formula
rangeResolutionsInMeters = VelosityOfLight * ADCsamplingRate / (2 * freqSlope * NumberOfADCSamples)
e2e.ti.com/.../666937

You divided it by constant ((3.6*1e3*900) /(1U << 26)) * 1e12 = 48279762268.06641

dss_main.c IWR1662 mmw demo
C:\ti\mmwave_sdk_01_01_00_02\packages\ti\demo\xwr16xx\mmw\dss\dss_main.c
1795: 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);

Same in main.c  IWR1443 mmw demo
C:\ti\mmwave_sdk_01_01_00_02\packages\ti\demo\xwr14xx\mmw\main.c
1089

Why you use the constant?

Gennadii Lichkov

  • 0
    TI__Guru 50240 points
    Hello Gennadii,

    This is a good observation and I am not so sure why we are using such an arbitrarily large number here. I will have to look into this and get back to you.


    Cheers,
    Akash
  • 0
    TI__Expert 5235 points
    The calculation is implementing the formula you quoted from the other thread. But in order to understand the calculation, you need to understand the units and formats of the different variables used in the equation, namely the profileCfg variable which if you read the code, is of the type rlProfileCfg_t, so you need to look-up the documentation of this structure. You can do this by searching this structure in the mmwavelink code or just opening its doxygen documentation, which is also referred in the SDK UG ("Most of the parameters described below are the same as the mmwavelink API specifications (see doxygen mmwave_sdk_<ver>\packages\ti\
    control\mmwavelink\docs\doxygen\html\index.html."). Reading this documentation you will be able to understand why the constants are used.
  • 0 in reply to Piyush_
    Intellectual 930 points
    Hello Akash,

    VelosityOfLight in meters per second, no converting is needed
    #define MMWDEMO_SPEED_OF_LIGHT_IN_METERS_PER_SEC (3.0e8)

    ADCsamplingRate in KHz, 1e3 factor is needed

    freqSlope in MHz/us, 1e12 factor is needed

    Thereby converting constant is 1e3 / 1e12 = 1e-9

    not 1.0 / 48279762268.06641 = 2.071261234567901e-11
    Why your converting constant is 48.3 times smaller than should be?

    Gennadii
  • 0 in reply to Gennadii Lichkov
    TI__Expert 5235 points
    I am not sure why you are ignoring the variables profileCfg.digOutSampleRate and profileCfg.freqSlopeConst in the formula, the purpose of the previous post was for you to look-up the units and formats of these variables and then see if the constants make sense. If it does not, please report back the error.
  • 0 in reply to Piyush_
    TI__Expert 5235 points
    Hi Gennadii,

    The reason for your confusion is because you are assuming the format of slope to be MHz/us but that is not correct (your assumption of the sampling rate format happens to be correct). If you read the documentation or code I pointed out earlier, the unit of slope in the structure is not MHz/us but 1 LSB is 48.279 KHz/uS as seen in the documentation below. My purpose of that post was to let you do this homework yourself so you are better prepared to navigate and understand the code for future situations.

    /**
    * @brief Ramp slope frequency, \n
    1 LSB = (3.6e9 * 900) / 2^26 = 48.279 kHz/uS \n
    Valid range: -2072 to 2072 \n
    */
    rlInt16_t freqSlopeConst;

    Note that the CLI command formats may not always match the rl formats, sometimes the rl formats are not user friendly (e.g the case of freqSlopeConst above) so we give more user friendly CLI formats and translate to the rl formats inside the CLI processing, in this case, you can see the following line in the ti\utils\cli\src\cli_mmwave.c file that does this translation from MHz/us to the format needed by rl:

    profileCfg.freqSlopeConst = (int16_t)(atof (argv[8]) * (1U << 26) / (3.6*1e3*900)); //2^26 * 1e6/((3.6*1e9)*900)

    The code you are reading is using the rl formats. The CLI once converted to rl is no longer used and the profileCfg storage is the rl format, hence in order to calculate the resolution we have to translate back.

    That said, I also noticed that while in earlier release (SDK 1.0) we had documented the CLI slope to be in MHz/us, newer releases we did not mention this unit and for valid values asked to look up the mmwavelink. The CLI still is in MHz/us. Although this documentation error is not the cause of your question (because you still correctly assumed CLI format in MHz/us, just that you did not realize this is no the rl format), we will correct the UG documentation in upcoming release.

    thanks.