I originally posted this in January of 2020. In the intervening time, between COVID and other matters, I have not been working on this project. I am now back on it.
We are looking to use the IWR1443 to just measure a linear distance. The high-accuracy lab gives us most of what we need, but it only choses the largest peak. In some cases, we need the closest peak above a certain amplitude to be chosen. Using the CFAR feature appears to be a way to choose a peak from a list of peaks. However, at this point, I have not been able to find documentation or guidance as to how to configure the CFAR to work in this mode. I am hoping that by now there may be some new documentation or someone who can help guide me.
I am trying to add the CFAR option to the high accuracy lab. The intent is to place it after the first FFT to choose a particular peak, which may be different than the highest peak as found when using the MmwDemo_peakSearch() function. Once a particular peak is chosen, that index would be copied to the maxIndex element of the rangeProcStats structure, and then the MmwDemo_processInterpolation() function would be called to perform the zoom FFT. Essentially, a version of the MmwDemo_processCfar() function from the lab0003-4k-fft project would be substituted for the MmwDemo_peakSearch() function in the high accuracy lab firmware.
To start, I added just the MmwDemo_CLICfarCfg() and MmwDemo_CLIPeakGroupingCfg() functions from the lab0003-4k-fft project. I hard-coded values for the various parameters based on values that I found in various labs. I find that if I set the peakGroupingCfg.inDopplerDirectionEn variable to either 0 or 1, the firmware runs but no chirps are performed. Performing a search for inDopplerDirectionEn in both the SDK and the toolkit files does not result in finding a location where that variable is used that should affect the functioning of the firmware. But obviously, there is some effect.
How can I find out why setting that enable variable to a valid value causes the firmware to not run correctly?
In the HWAutil_configCFAR() function of the 4k_fft lab, there is
hwaParamCfg.source.srcRealComplex = HWA_SAMPLES_FORMAT_REAL;
The source appears to come from the M0 buffer. However, in the HWAutil_configRangeFFT() function used to configure the 1st FFT of that lab, there is
hwaParamCfg[paramsetIdx].source.srcRealComplex = HWA_SAMPLES_FORMAT_COMPLEX; //complex data
That source also appears to be the M0 buffer. It does not seem that there is anything that changes the M0 buffer between the call to the 1st FFT and the CFAR, so how is it that one function says M0 contains REAL data and the other says that is has COMPLEX data?
Matters are not helped that the high accuracy lab and the 4k_fft have different styles of coding. That complicates trying to ensure that all of the necessary functions and statements needed for the CFAR have been copied from one lab to the other.
I have asked in another post about documentation for the firmware. I have the same question for this instance. The Radar Hardware Accelerator User's Guide indicates details about the CFAR, but it does not give a clear description of how to link various paths through the HWA. The 4k-fft lab uses a different set of settings for the first FFT than the high accuracy lab. Therefore, the settings for the CFAR in the MmwDemo_configCFAR_HWA() function would need to be different than what is in the 4k-fft lab. How to determine what those settings need to be? What documentation describes that?
