IWR1642BOOST: Profile Configuration for long range detection

Hi Scott,

For a 50m chirp with Traffic Monitoring Demo, use this configuration:

dfeDataOutputMode 1
channelCfg 15 3 0
adcCfg 2 1
adcbufCfg 0 1 1 1
profileCfg 0 76 15 6.5 48.3 0 0 7.481 1 125 3117 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
frameCfg 0 1 125 0 33.3 1 0
lowPower 0 1
guiMonitor 1 0 0 0
cfarCfg 4 4 15 16 8 6 0 63 63 0 1
doaCfg 1 0 1047 3 600 10 100
sceneryParam 1 -50 50 0.0 75.0 0 0 0 0 1 1.25 11.0 20.0 50.0 0 0 0 0
gatingParam 12 8 4 0
stateParam 3 10 20 2000 10
allocationParam 30 60 1.0 3 2.8 2.0
variationParam 1.15 0.433 1.0
trackingCfg 1 1 250 20 78 110 33 90
compRangeBiasAndRxChanPhase 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
sensorStart

You can see the results of our tests here.  In short, at bore-sight you should expect detection between 40 and 50 meters. If this config is rejected, change allocationParam to 30 1.0 3 2.8 2.0.

There are some commands in the configuration file that are defined by the SDK and shared across all demos.  There are also demo specific commands.

dfeDataOutputMode 1
channelCfg 15 3 0
adcCfg 2 1
adcbufCfg 0 1 1 1
profileCfg 0 76 15 6.5 48.3 0 0 7.481 1 125 3117 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
frameCfg 0 1 125 0 33.3 1 0
lowPower 0 1

compRangeBiasAndRxChanPhase 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

sensorStart

sensorStop

The above are defined by the SDK and will work with any demo that uses the TI SDK.  All other commands in the configuration file are demo specific.  As a result, most configuration files are not compatible across demos.  If you are curious to see new commands that have been added in each demo, see the cli.c file in the MSS project.

Finally, there are some constraints in the Out of Box (OOB) demo that limit which chirps can be used.  OOB requires that the chirp have an even number of samples, and that the frame have an even number of chirp loops.  This is not required in TM or PC.

Regards,

Justin

Hi Justin,
I will try this configuration and see what results it produces, thanks.

Your the reference to the cli.c was very useful. The differences between your suggested configuration and the base working one that I'm using prompts some follow up questions:

1) The allocationParam config will fail as it has 1 too many params, I assume the 30 is to be removed?

2) Profile cfg: when I use the mmwave chirp estimator tool (dev.ti.com/.../) and select "long range default", "adult target", I get the following suggested profileCfg (unless I've misinterpreted the results):

profileCfg 0 76 2 5.3 52.68 12 0 7.19 1 173 3730 0 0 48

What differences are there in your profile cfg that would increase the reliablity / range of detection?

3) I assume for the sceneryParam I can zero out the last 9 values if I don't want target boxes without affecting the tracking?

4) Gating param & Variation param - I had used the values from the people counting lab as I thought they would more accurate represent the size and cross sectional area of the target I'm trying to see rather than traffic monitoring defaults, should this be the case or should I leave these per the traffic monitoring?

5) TrackingCFG: the 110 parameter (timestep between each frame) - how does this related to the frameCfg parameter frame periodicity? Or does it relate at all to other parameters in the cfg?

6) frameCfg - I don't see this mentioned in the cli.c at all, is it being used in this lab?

Thanks,
Scott

Hi Justin,

That's great info, thanks - I'm already getting better results.  Not quite 50m yet, more 30-40m, but I'll keep tweaking the configuration and see where I get to. One last question: how much of a difference does the calibration under the "Range Bias and Rx Channel Gain/Offset Measurement and Compensation" section of the docs matter to the range/accuracy of the tracked objects? Is this calibration scene specific or hardware specific?

Thanks,

Scott

Hi Scott,

The calibration is hardware specific. We recommend using the OOB demo once to get the calibration values, then use those calibration values anytime you use that board. I do not expect that you will see major differences with a people detection application, but for high speed objects like vehicles or very accurate measurements, calibration is helpful.

Regards,
Justin

Hi Justin,

That's good to know.  Thanks for all your help with this, I'll get back in touch if I have any other questions.

Cheers,

Scott

Hi Justin,
I'm getting better results with these parameters, and it does seem to track reasonably reliably for people walking away from the radar (to about 40m) but with people walking toward the radar they need to be around 15m away before it will start tracking. Is there anything in the configuration that would explain this anomaly that I can try changing?
Thanks,
Scott

Hi Scott,

Do you have any recordings when a person is approaching the radar device? Usually there are two issues that need to be solved to enable reliable detection.

1. The radar is not detecting points from the approaching target; there is no point cloud
2. The tracking algo is not tracking the returned points in the point cloud.

When you are testing, which issue do you think you are seeing?

Thanks,

Justin

Hi Justin,
I will play closer attention to that data on my next field test, but from memory it was the first issue (i.e. there were only a very small number of points detected and ergo not enough to constitute a trackable target).

Scott

Hi Scott,

Which chirp did you use for most of your testing?

For issue 1, there are generally 2 ways to approach the problem.

1. If you have any detected points at all, you can try adapting the tracker to pick up the track with just 1 point.  This will make the tracker very sensitive, and you may have issues when targets are close.
2. Further tune CFAR parameters to increase detection points.  If you have the ability to collect raw data, this would be useful as you could do one capture for a given chirp and try multiple configurations.

What kind of area are you testing in? Our test was done in a parking lot.

Regards,
Justin