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.

IWR1642BOOST: Profile Configuration for long range detection (CFAR and DOA)

Part Number: IWR1642BOOST
Other Parts Discussed in Thread: IWR1642

Hello again,

From previous answers I have a better understanding of many of the configuration parameters now, however there are 2 sections that don't have enough detail:

1) cfarCfg:

Sample from long range cfg:

cfarCfg 4 60 18 16 8 4 0 63 63 0 1

In the MMWAVE SDK user guide for the first parameter it states in the case of the IWR1642 chip: "For legacy mode, that field should be set to -1 whereas for advanced frame mode, it should be set to either the intended subframe number or -1 to apply same config to all subframes." and in a number of labs it is indeed set to -1, however in the traffic monitoring it is set to 4.  Delving into the cli.c source code I see the following section:

/* Populate configuration: */
cfarCfg.cfarMethod = (uint16_t) atoi (argv[1]);
cfarCfg.cfarDiscardLeft = (uint16_t) atoi (argv[2]);
cfarCfg.cfarDiscardRight = (uint16_t) atoi (argv[3]);
cfarCfg.refWinSize[0] = (uint16_t) atoi (argv[4]);
cfarCfg.refWinSize[1] = (uint16_t) atoi (argv[5]);
cfarCfg.guardWinSize[0] = (uint16_t) atoi (argv[6]);
cfarCfg.guardWinSize[1] = (uint16_t) atoi (argv[7]);
cfarCfg.thre = (float) atoi (argv[8]) * 0.1f;
cfarCfg.dopplerSearchRelThr = (float) atoi (argv[9]) * 0.1f;
cfarCfg.log2MagFlag = (uint16_t) atoi (argv[10]);
cfarCfg.clRemoval = (uint16_t) atoi (argv[11]);

Which matches up with the config file section. Could somebody elaborate on:

a) What the various "cFarMethods" are and how they differ?

b) What the cFarDiscardLeft and cFarDiscardRight refer to and why would the DiscardLeft by set to a higher value?

c) What the refWin and GuardWin sizes do?

d) What the threshold (which looks like a range threshold in the code) and doppler threshold will effect?

e) What effect the remaining parameters have?

2) doaCfg:

Could these parameters also be explained in more detail:

Sample from cfg file:

doaCfg 1 0 1047 3 600 10 100
From the cli.c code:

doaCfg.doaMethod = (uint16_t) atoi (argv[1]);
doaCfg.vmaxUnrollFlag = (uint8_t) atoi (argv[2]);
doaCfg.doaGamma = (float) atoi (argv[3]) * 0.001f;
doaCfg.doaSideLobeLevel_dB = (uint16_t) atoi (argv[4]);
doaCfg.doaSearchRange = (float) atoi (argv[5]) * 0.1f;
doaCfg.doaSearchRes = (float) atoi (argv[6]) * 0.1f;
doaCfg.doaVarThr = (float) atoi (argv[7]) * 0.1f;

a) What are the various doaMethods and how do they differ?

b) What do the other parameters effect, in particular the search parameters as they effect range?

3) Also, I note from the SDK doc that bmpCfg might improve SNR - can this be used as part of the traffic monitoring lab? Would it be recommended as it relates to longer range detection?

Finally, in using the chirp estimator tool it suggest for longer range detection to use 1 tx antenna, but when I try this by changing the last parameter of chirpCfg to 3 I get no data back at all - is there a second section of the cfg file I need to change in conjunction to do this?

Thanks again,
Scott
  • Hi Scott,

    1) For a decent explanation of CFAR, see the Wikipedia article.  The goal is too estimate the noise floor, then look for areas of high signal strength relative to the noise floor. This happens in 2 steps:

    1. Estimate the noise floor:  For a bin under test, certain reference bins are sampled.  The values in the reference bins are averaged.
    2. Find High signal strength: The bin under test is compared to the reference cells (noise floor) - if it is larger than that value plus the CFAR threshold, it becomes a detected point

    a)  There are various cfar methods - 3 commonly seen are CFAR cell averaging (CACFAR), CFAR cell averaging smallest of (CASOCFAR), and CFAR cell averaging greatest of (CAGOCFAR).  CACFAR is the process outlined above. CASOCFAR calculates 2 noise floors - one with reference bins of smaller index than the bin under test, and one with reference bins of larger index than the bin under test. The smallest of the two noise floors in used for step 2 above. CAGOCFAR follows the same process as CASOCFAR, but uses the greatest noise floor (instead of the smallest).

    In the Traffic Monitoring demo, CACFAR = 1, CASOCFAR = 2, CAGOCFAR = 4.

    b)  These arguments discard some of the samples. Left samples start at index 0 and get greater, Right samples start at index Max and get smaller. We discard more samples on the left because these close range measurements usually have strong near field signal.

    c) refWin size is the number of cells that will be used to calculate the noise floor. Guardwin is the number of bins that will be skipped between the bin under test and the reference bins.

    d) A bin must have a value greater than (reference bin average + threshold) to be considered a detected point. CFAR is done in two passes - one along range bins, and one along doppler bins. Range threshold is used for the range pass, doppler threshold is used for the doppler pass.

    e) Log2mag flag determines if values are logarithmic or not. I recommend leaving this 0, which means log values. clRemoval is the clutter removal flag.  Leave this as 1 to remove static objects.

    2) I will ask another TIer to comment on this configuration.

    3) BPM config allows you to chirp with phase 0 degrees or phase 180 degrees. Generally, this is used an as interference mitigation tool.  However, the recommendation in the SDK user's guide to enable both TX for a chirp will increase detection range, but lower angular resolution.

    4) The demo is not returning data because there is a bug in the software. The value numAntenna is used in the direction of arrival calculation.  This value is the number of virtual antennas, which is Tx*Rx. However, when using both Tx at the same time, the 2 Tx are effectively 1 Tx for the virtual array.  The software does not account for this, leading to a crash.  The numAntenna value is set at line 1171 in dss_data_path.c. This value is used erroneously at line 350 in radarProcess.c.

    Regards,

    Justin

  • Hi Scott,

    Answer to your question 2:

    doaCfg.doaMethod = (uint16_t) atoi (argv[1]); /* 1: beamforming: single peak search in angle spectrum. 3: beamforming: multipeak search in angle spectrum. */
    doaCfg.vmaxUnrollFlag = (uint8_t) atoi (argv[2]); /* 1: enable angle correction when over Vmax, if 1 only single peak search is used. 0: no angle correction when over Vmax */
    doaCfg.doaGamma = (float) atoi (argv[3]) * 0.001f; /*Multipeak search parameters for keeping local maximum as a peak, best empirical value is 1.047*/
    doaCfg.doaSideLobeLevel_dB = (uint16_t) atoi (argv[4]); /*Multipeak search parameters for sidelobe threshold, best empirical value is 3*/
    doaCfg.doaSearchRange = (float) atoi (argv[5]) * 0.1f; /*Boundary of the angle search, only angle between range of [(-doaSearchRange- doaVarThr) (doaSearchRange+doaVarThr)] will be reported */
    doaCfg.doaSearchRes = (float) atoi (argv[6]) * 0.1f; /*Angle search resolution, in unit of degree.*/
    doaCfg.doaVarThr = (float) atoi (argv[7]) * 0.1f; /*Angle search variance, in unit of degree, calculated as the Cramer-Rao Bound of the angle estimation.*/

    A couple of notes to clarify the answer above:
    Multipeak search means more than one point could be detected at a single range and doppler (e.g.: two different angles.

    The third argument, doaGamma, is divided by 1000. To get to the value suggested above, enter 1047.

    Arg 5, angle bound search, can be used to narrow the FOV - this is only in software, will not change the physical characteristics of the chirp.

    Regards,
    Justin
  • Hi Justin,

    Sorry for the delayed response - thanks for answering all of this, it has helped my understanding of the CFAR significantly.

    Just on the last 2 points:

    Will the bug mentioned in point (4) mean that the suggestion in the SDK for BPM won't work (it requires that "the chirpCfg command for this chirp index must have both TX antennas enabled")?

    Thanks,

    Scott

  • Hi Scott,

    Please see the attached example config for use of BPM with the Out of Box demo.  For People Counting, you will need to fix the bug listed to enable bpm to work.

    Regards,

    Justin2055.profile_2d_bpm.cfg

  • Hi Justin, thanks these answers have helped explain a lot. I have now downloaded and compiled the dss and mss and am ready to fix the bug you mentioned. Would the correct fix be to modify the numAntenna value as it is set in dss_data_path to account for tx antenna count > 1 or to instead modify the radarProcess to use numPhyRxAntenna instead of numAntenna?
    Thanks,
    Scott
  • Hi Scott,

    I think you would be better off modifying the numAntenna value.  You would be able to check the profile config to see if both tx are on for the same chirp.  If so, you could configure chirps with 2 Tx on and chirps with 1 Tx on without recompiling.

    Regards,

    Justin

  • Hi Justin,

    I'm not sure what you mean by "without recompiling" as I believe any bug fix here will require this?

    But on the numAntenna change, the current code at time of setting is this:

    radarProcConfig->numTxAntenna = (uint16_t)_bitc4(demoCfg->openCfg.chCfg.txChannelEn);
    if (radarProcConfig->numTxAntenna > 1)
    	radarProcConfig->mimoModeFlag = 1;
    radarProcConfig->numPhyRxAntenna = (uint16_t)_bitc4(demoCfg->openCfg.chCfg.rxChannelEn);
    radarProcConfig->numAntenna = radarProcConfig->numPhyRxAntenna * radarProcConfig->numTxAntenna;

    What should numAntenna be changed to in order to address this bug without interfering with configurations without 2 tx antennas?

    Thanks,

    Scott

  • Hi Scott,

    Sorry for the confusion my earlier comment caused. You will have to recompile the software. numAntenna should be 4, and mimoModeFlag should be 0. Essentially, we are telling the datapath that it is receiving data from 1 chirp, which will appear across 4 virtual antenna.

    Regards,
    Justin
  • Hi Justin,

    I made the changes you suggested and recompiled the traffic monitoring lab and uploaded it to the board but now when I have the same cfg as before except with the following chirpCfg the board does not respond:

    chirpCfg 0 0 0 0 0 0 0 3

    chirpCfg 1 1 0 0 0 0 0 3

    And in fact the ppl counting GUI crashes out with an error message on data timeout.  Is there something else I need to change in the code? Or in the Config?  Really at this stage it might be more efficient if someone from TI were to fix this bug and produce a new lab?

    Scott

  • Hi Scott,

    We can work internally to try to resolve this issue. Expect a 1 to 2 week turnaround.

    Regards,

    Jusitn

  • Hi Justin,

    Any update on this issue and internal fix?

    Thanks,

    Scott