IWR6843AOP: How to Proceed in Designing/Testing Chirps

Hello

Can you please help us understand:

1. What setup - HW, SW  are you trying to carry out these changes

2.  How are you designing or coming up chirp variations to try with device

3. What is the objective of these  tests :    Testing HW  for RF performance, Testing  SW performance for  different chirps?

Thank you,

Vaibhav

1. It's a custom board using an IWR6843AOP with a somewhat modified version of the automated doors and gates lab. But I'm asking what HW/SW is going to be the easiest to try and design a chirp with.

2. I'm not. I just tried changing some of the parameters and it was causing the device to crash, so I figured it was more complicated than that. In essence, this is the question I'm asking TI.

3. The primary objective is to optimize the chirp to capture as much data from the environment as possible that is relevant to our application.

Hi, Abram:

Here is the resource to understand chirp parameter and chirp design. 

1) App notes to understand the parameters in chirp, and how the chirp parameter affects the system performance in terms of max range, range resolution, max Velocity, Velocity resolution.  (for the rest, we refer system performance as max range, range resolution, max velocity and velocity resolution)

https://www.ti.com/lit/an/swra553a/swra553a.pdf

Based on those theoretical equations, you can create an excel sheet, play with the chirp parameter, such as number ADC sample, sampling frequency, chirp slope, and total ramp time and etc, to see how it affects the system performance.  Here, we attached an example of such excel sheet to get the customer started, but it is far from golden.  chirp_params_withCheck.xlsx

Note that there is a minimum setting on idle time, ADC start time, excess ramp time based on other system parameters, users will need to use "rampTimingCalculator" tab inside mmWave studio as a golden reference (mentioned in section 5.4 in the above app note). 

For each chirp parameter setting, there will be some limitation for each device, users can find these information  through SDK Dogygen documentation in mmwaveLink API.  file:///C:/ti/mmwave_sdk_03_05_00_04/packages/ti/control/mmwavelink/docs/doxygen/html/group___sensor.html 

2) Training video on FMCW fundamental:

https://training.ti.com/intro-mmwave-sensing-fmcw-radars-module-1-range-estimation?context=1128486-1139153-1128542

3) Sensor estimator tool and basic training:  users define the max range, range resolution, max velocity and velocity resolution, and the tool will provide the chirp parameter.   Users can choose from short range or long range application to start with.  

https://www.ti.com/mmWaveSensingEstimator 

https://training.ti.com/mmwave-sensing-estimator-overview 

Best,

Zigang

The customer mentioned that change of chirp parameter can cause the demo to crash, below are some of the common errors:

1) The ramp ending frequency is beyond VCO range.  For example, for xwr6843, RF frequency of 60G-64G is supported.  The ending frequency can not exceed 64GHz. 

2) RF ramp end time is less than the sum of ADC start time and ADC sampling time. 

3) Idle time is too short. 

4) The radarCube size is too big to fit into the L3 memory.  The radarCube contains the range FFT output for all the chirps and all antennas in one frame. 

5) An individual parameter is beyond the range for that device, for example, the maximum ADC sampling rate, the maximum frequency slope, the RX gain and etc.  

There are some case, the chirp is not failing the check, but you see abnormal ADC samples when there is not enough excess ramp time, ADC start time or idle time.