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.

IWR1443: chirp parameters

Part Number: IWR1443

Hi,

I used the mmWave Sensing Estimator to acquire a set of chirp parameters. The parameters from the estimator are shown in estimator.gif.  These values have been inserted in a configuration file which is partially shown below.

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 1 1 0
adcCfg 2 1
adcbufCfg 0 1 0 1
profileCfg 0 77 7 4.6 125.19 0 0 25.11 1 556 4649 0 0 30
chirpCfg 0 0 0 0 0 0 0 1
frameCfg 0 0 4 0 50 1 0
lowPower 0 0
guiMonitor 0 0 0 0 0 0
cfarCfg 0 2 8 4 3 0 1280
peakGrouping 1 1 0 1 1020
multiObjBeamForming 1 0.5
clutterRemoval 1

As is indicated, the application is for a frame with only 4 chirps and each chirp has a repetition period of 132 us.  My intent was to obtain distance information at a rate of 100 Hz (frameperiodicity of 10 ms).  I thought this could be supported since the duration for four chirps would be ~.5 ms plus time for the associated processing.  The processing is minimal.  I am using a modified demo visualizer code where my only ouput is via a gpio.  I was collecting undesirable data so I printed to the console some range data after a desired event so the io would not interfere with the processing I am doing which is very simple ( a few lines).  I examined the 1d fft data available in the fftOut1D array after the MmwDemo_dataPathWait1D(dataPathObj) call and the log data in the rangeDopplerLogMagMatrix array after the MmwDemo_process2D(dataPathObj).  I observed that the quality of the range data degraded as I decreased the framperiodicity from 100 ms to 10 ms.  I collected the peak value for each frame for a particular event and plotted them. Attached are plots for when the frameperiodicity was at 100, 50 and 25 ms (I see that I labeled the plot for 100 as 50 but it is the smoothest).  10 ms is very poor (I unfortunately did not save it).  I would expect all the plots should be smooth and continuous as is the 100 ms case.  These plots are from the rangeDopplerLogMagMatrix array which it smoother than the data in the fftOut1D array.

Do you have any thoughts on why the degradation when the frameperiodicity was decreased?

Thanks.

Al

Note wrong label for first graph.  It should read 4_100 and not 4_50.

  • Hi Allen,

    Are you using the Out of Box Demo application for your measurements or do you have modifications on it? Can you repeat this experiment with the OOB demo and Visualizer and check the Range profile plot?

    Regards
    -Nitin
  • Hi Nitin,

    When I have used the oob demo and the visualizer to originally observer the range profile characteristics, I obtained a fairly consistent/smooth magnitude variation.  My configuration is a moving corner reflector at 2 m/s.  I makes two passes in front of the sensor.  Since the corner reflector has only one dominant scattering center, one would expect the maximum, received signal for each frame to have a smooth variation as function of position.  This does occur when the frame periodicity is 100 ms (sample rate of 10 Hz).  With the dynamic clutter reduction, instead of a single "hump" as the reflector goes by, the received signal actually generates a null when the corner reflector is right in front of the sensor since the returned signal is slowly varying.  This is why the plots have four humps, each time through the sensor's field of view, the received signal gets nulled out (from the clutter reduction algorithm) when  the corner reflector is directly in front of it.

    I have attached some plot  for two frame periodicity values, 10 ms (100 Hz sampling) and 100 ms (10 Hz sampling).  Each value has magnitude plots from data in the rangedopplerlogmag and fft1d arrays.  For periodicities of 100 ms, both arrays have data as I would expect.  When the periodicity value is decreased to 10 ms, the data becomes very disjointed.  I only collected 120 samples for each run so the time history is shorter for the 10 ms cases.  I have also attached the code fragment that was inserted in MmwDemo_dataPathTask function to collect this data.  The insertion point is essentially after to MmwDemo_process2D call.  The plot title of rdlmm corresponds to rangedopplerlogmag arrary data and the fft2d title corresponds to fft2d array data.  The number 4 means that 4 chirps per frame was used and the 10 or 100 is the frame perioidicity.

    Al

            cmplx16ImRe_t *fftOut1D = (cmplx16ImRe_t *) dataPathObj->radarCube;
        MmwDemo_process2D(dataPathObj);
            /* 2nd Dimension FFT done! */
        if(flg==0)
          {
            max_mag_rd=0;
            for (rngIdx = 0; rngIdx < dataPathObj->numRangeBins; rngIdx++)
                  {
                    mag_rd=dataPathObj->rangeDopplerLogMagMatrix[rngIdx*dataPathObj->numDopplerBins];
            /* mag_rd=fftOut1D[rngIdx*(dataPathObj->numDopplerBins)].real*fftOut1D[rngIdx*(dataPathObj->numDopplerBins)].real+fftOut1D[rngIdx*(dataPathObj->numDopplerBins)].imag*fftOut1D[rngIdx*(dataPathObj->numDopplerBins)].imag */;
                    if (mag_rd > max_mag_rd) max_mag_rd=mag_rd;
                  }
            if(max_mag_rd>3000) /*for rangeDopplerLogMagMatrix*/
              /* if(max_mag_rd>5000) */ /*for fftOut1D*/
              {
            MagMax[idx]=max_mag_rd;
            idx++;
              }
            if(idx==120)
              {
            System_printf("range %d\n",dataPathObj->numRangeBins);
            System_printf("doppler %d\n",dataPathObj->numDopplerBins);
            System_printf("antennas %d\n",dataPathObj->numVirtualAntennas);
            for(idx1=0; idx1 < 120; idx1++)
              {
                System_printf("%d %d\n",idx1,MagMax[idx1]); /*for rangeDopplerLogMagMatrix*/
                /* System_printf("%d %d\n",idx1,(int)(sqrtf((float) MagMax[idx1]))); */ /*for fftOut1D*/
              }
            flg=1;
              }
          }

  • It seems your prints (System_printf) are coming out once per frame. Note system_printf when you see them print out on the CCS console is not real-time i.e CCS halts the code, gets the data to print and then prints before resume the code run. It is best if you store the max-es in some globals or stream it out on the UART every frame (as part of the point cloud data for example). It may be that at 100 ms the system (PC) is able to keep up but at 10 ms it is not. Although unless you modified the original oob code to bypass the real-time frame deadline check, you should see the demo report an exception (assert for frame token) when it is not able to keep up the real-time. Otherwise I cannot think of any good explanation for what you are observing.

  • One clarification regarding my previous post: On 1443 (or on 1642 when printing out on R4F, not DSP), the real-time deadline exception will not happen because halting the MSS (R4F) [whether using break-points/single-stepping or CCS halting for prints] automatically halts the BSS/chirping. So even with system_printfs you will not see the deadline exception. However, your real-time will still be screwed up, and this matters for your experiment because you are moving the object at a constant speed, the PC when it is not able to keep up with the frame rate, will introduce variability in the frame time which will reflect in your readings. So as I mentioned, it is best if you store the data in say a global circular buffer or stream out the data on the UART in real-time instead of using system_printfs.
  • Hi Piyush,

    Yes I am collecting one data point per frame but I am storing it in an array until I am done collecting data since I am very sensitive not to mess up the real time flow.  My logic to collect the one data point per frame is very simple as not to disturb the real time flow as well.

    I believe I will try another sensor to confirm it is not a hardware problem.

    Al

  • Hi Piyush,

    All though my issue is not resolved, I am walking away from this approach. Thank you for your time and you can close this topic.

    Al