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.

AWR1642: heat map data overflow with vehicle occupation detection demo

Part Number: AWR1642

Hi,

My customer has tried vehicle occupation detection demo (lab0003_occupancy_detection) on their AWR1642 board. And they found in some special case some of the heat map datas overflowed. In CCS, we can see some of the value of heat map data is negative.

Any comment to solve the overflow issue?

  • Hi Chris,

    We need to check this case in detail, please provide some time to check this and get back to you.

    Regards,

    Jitendra

  • Hi Chris,

    In our testing, the only way to produce an overflow is to place an object with a very large RCS (such as a large corner reflector) close to the sensor.  Normal objects will not do this.  If the Rx Gain is set too high you could see this.  The most susceptible point in the algorithms to experience overflow is the chirp processing where the 16 bit signed samples are FFT'd and stored as 16-bit I/Q in the radar cube.  The rest of the algorithms are in floating point.

    So, if the issue is with an object that would normally be found inside a vehicle, I would recommend checking the Rx Gain.  Beyond this, we would need a more exact description of the scenario causing the overflow.

     -dave

  • Dave,

    Thanks for your reply!

    The overflow only happens in some special case inside a vehicle, such a person stands up and his head is closer to the sensor.

    Would you pls kindly advise how to check/comfirm if the FFT result overflows or not? Customer found some FFT data is bigger than 30000 or less than -30000 when heatmap is overflowed. So they think the FFT data should also overflow.

    Any comment is appreciated!

  • Hi Chris,

    I ran an experiment for this:  I placed a large corner reflector ~23cm from a 1642 EVM:

    This is a very large RCS and produces a single bright spot in the heatmap:

    Looking through the heatmap data, the bright spot is in range row 7, azimuth col 27.  The value of this cell is 512215.1.  This isn't an overflow, as the cells moving away from this cell decrease continually in value.  I then looked through the radar cube data for range bin 7, and saw very large values, but I couldn't tell if anything was an overflow.  All values had a few sign bits at the top.  I also looked through the current ADC data and also saw large values, but nothing that jumped signs quickly indicating an overflow.

    I have two suggestions if this is an issue that needs checking in the device or host:

    1) Check the heatmap values.  They should never be negative. The customer can test for what the expected positive maxcan be, then either discard larger values or saturate them.  Remember that this only needs to be done in the defined zone regions.

    2) Enable the Rx Saturation Monitor in the RF front end. See AWR_MONITOR_RX_SATURATION_DETECTOR_CONF_SB in the Radar Interface Control Document. Rx Monitor support was added to the Out Of Box demo after we implemented VOD, so it is not supported in this demo, but could be added by the customer by porting those sections of OOB to VOD.  Even with this enabled, there is no guarantee that something won't overflow downstream.  So #1 may be the best and easiest option.

      -dave