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: clutter removal when only one chirp/frame is used

Part Number: IWR1443
Other Parts Discussed in Thread: MMWAVE-SDK

Hi,

The clutter removal feature does a nice job in the oob demo.  However this feature requires that a series of doppler chirps are available in a frame to obtain the average of each range bin. It appears that if one is only interested in range and not velocity or aoa, one can not remove clutter in the current version when only one transmit antenna, one receive antenna and one chirp per frame is required.  Is this correct?

For the case of one transmit antenna, one receive antenna and one chirp per frame, I assume the oob demo mss binary would be almost as fast as the high accuracy range mss binary.  Is this correct?

What advice can you offer to have clutter removal when doppler chirping is not performed in the case of range determination only?

Thanks.

Al

  • Hi Allen,

    The Static Clutter Removal Algorithm uses information obtained from the second dimension FFT which procures velocity so velocity information would be needed here.

    The speed of the OoB demo is reasonably faster than high accuracy (for range only) since the high accuracy demo performs additional processing (zoom fft algorithm) to obtain a high accuracy measurement.

    I would not recommend Clutter removal if second dimension fft is being ignored.


    Cheers,
    Akash
  • Hi Akash,

    Thank you for the information. I reviewed the user guide for the high accuracy app. Yes, maybe I got off on the wrong track. Perhaps you can re-direct me. I had thought that is was the way to go since I was only interested in range and being able to provide rapid range data (frame rate > 100 Hz). I thought that no velocity and aoa calculations would be advantageous for a faster rep rate. I then realized that I should have clutter removal and realized that the high accuracy approach did not support it since the oob demo used the chirp train which provides the velocity information.

    I will re-examine using only one transmit and one receive antenna to improve the frame rate but I think the frame rate is heavily dependent upon the number of chirp loops (the number of chirps in a frame). The frame rate to my understanding is (not considering the gui's uart time which will not be in the final application, I will have a gpio as an event notifier)

    chirp_cycle_time=idle_time+rampEndTime
    numChirpsPerFrame=numTxAnt*num_chirp_loops
    chirping_time=numChirpsPerFrame*chirp_cycle_time
    fps=1/chirping_time

    This does not reflect any processing time and no consideration for duty cycle to let the transmitter cool off. Also I have not accounted for the number of receive antennas. I suppose I would replace numTxAnt with numTxAnt*numRcAnt=numVirtualAnt. Any guidance on these topics is appreciated.

    You made a comment that the clutter removal is dependent upon the second fft. The following code segment indicates that this is not the case (main.c):

    Load_update();
    dataPathObj->timingInfo.interFrameCPULoad=Load_getCPULoad();

    MmwDemo_dataPathWait1D(dataPathObj);
    /* 1st Dimension FFT done! */

    Load_update();
    dataPathObj->timingInfo.activeFrameCPULoad=Load_getCPULoad();

    /* Clutter removal */
    if (dataPathObj->cliCfg->clutterRemovalCfg.enabled)
    {
    int32_t rngIdx, antIdx, dopIdx;
    cmplx16ImRe_t *fftOut1D = (cmplx16ImRe_t *) dataPathObj->radarCube;
    cmplx32ImRe_t meanVal;

    for (rngIdx = 0; rngIdx < dataPathObj->numRangeBins; rngIdx++)
    {
    for (antIdx = 0; antIdx < dataPathObj->numVirtualAntennas; antIdx++)
    {
    meanVal.real = 0;
    meanVal.imag = 0;
    for (dopIdx = 0; dopIdx < dataPathObj->numDopplerBins; dopIdx++)
    {
    meanVal.real += fftOut1D[rngIdx*(dataPathObj->numDopplerBins*dataPathObj->numVirtualAntennas) +
    antIdx + dopIdx*(dataPathObj->numVirtualAntennas)].real;
    meanVal.imag += fftOut1D[rngIdx*(dataPathObj->numDopplerBins*dataPathObj->numVirtualAntennas) +
    antIdx + dopIdx*(dataPathObj->numVirtualAntennas)].imag;
    }
    meanVal.real = meanVal.real/dataPathObj->numDopplerBins;
    meanVal.imag = meanVal.imag/dataPathObj->numDopplerBins;
    for (dopIdx = 0; dopIdx < dataPathObj->numDopplerBins; dopIdx++)
    {
    fftOut1D[rngIdx*(dataPathObj->numDopplerBins*dataPathObj->numVirtualAntennas) +
    antIdx + dopIdx*(dataPathObj->numVirtualAntennas)].real -= meanVal.real;
    fftOut1D[rngIdx*(dataPathObj->numDopplerBins*dataPathObj->numVirtualAntennas) +
    antIdx + dopIdx*(dataPathObj->numVirtualAntennas)].imag -= meanVal.imag;
    }
    }
    }
    }

    MmwDemo_process2D(dataPathObj);
    /* 2nd Dimension FFT done! */

    To improve my frame rate, I would reduce the numVirturalAntennas to 1 and do not perform MmwDemo_process2D since I am not interested in velocity or aoa data. Again, your thouhts.

    Thanks.

    Al
  • Hi Akash,

    I have sent you post regarding your reply. Do you have anything to add?

    Thanks.

    Al
  • Hi Allen,

    Static Clutter Removal requires velocity information since it filters out non-moving (static) objects from the scene. It is discussed in the mmWave-SDK user guide on page 22.


    Cheers,
    Akash
  • Akash,

    Unfortunately, for the way the code is written, it does require the samples used for velocity information to obtain this static value. If the background is truly static, then one could collect one chirp outside the main loop when the scene is stationary and subtract the values from this chirp from each future chirp. Currently the coded approach is a little inefficient, however, there is some benefit if the scene does have some minor change over time since this approach continually updates the static reference.

    Al