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.

RTOS/AWR1642BOOST: Double check bandwidth of .cfg file

Part Number: AWR1642BOOST
Other Parts Discussed in Thread: AWR1642

Tool/software: TI-RTOS

Given the following profileCfg what is the bandwidth of the chirp?

profileCfg 0 77 7 7 58 0 0  68 1 256 5500 0 0 30

I thought that B=rampEndTime*freqSlope

where rampEndTime = 58 and freqSlope = 68

according to the rlProfileCfg_t structure from the mmWave Link doxygen: file:///C:/ti/mmwave_sdk_01_01_00_02/packages/ti/control/mmwavelink/docs/doxygen/html/structrl_profile_cfg__t.html

1LSB for rampEndTime = 10ns, therefore 58*10e-9 = 580e-9 [s]

1LSB for freqSlope = 48.279 kHz/uS, therefore 68*48.279e9= 3.283e12 [hz/s]

B=(580e-9)*(3.283e12) = 1.9e6 [hz] = 1.9MHz.

This grossly underutilizes the available bandwidth of the sensor. Am I doing something wrong with my math? 

  • So I believe I found an explanation. There is conflicting information between the mmWave Link doxygen and the most recent SDK User Guide (SDK 2.0). In the mmWave Link doxygen, it says that 1LSB for freqSlope = 48.279 kHz/us. On p.16 of the mmWave SDK 2.0 User Guide, it specifies that for the xwr16xx version of the AWR1642, the freqSlopeConst parameter within the profileCfg command requires "any value greater than 0 as per mmwavelink doxygen/device datasheet BUT REPRESENTED in MHz/usec"

    Therefore, there is a factor of 1000 difference for the frequency slope. The bandwidth of the signal is thus 1000 times greater (1.9Gz). I hope this helps anyone who has a similar question.
  • The mmwavelink doxygen I am referring to is SDK 1.1. It may be different in other versions, but my hardware is not ES2.0 which is why I'm not using SDK 2.0.
  • Glad you got the answer and helped others' future similar query.