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.

IWR1642: Frame processing time in Traffic Monitoring object detectiong

Part Number: IWR1642
Other Parts Discussed in Thread: AWR1642

Hi 

I have questions about the frame processing time at table 3 MIPS usage Summary of TIDUD31 document.

this table show frame used time is 22.73mS, my questions below:

(1) frame used time means frame processing time? if not , how much time the frame peocessing time use?

(2) 22.73 use C674 DSP or ARM R4F? is there any method to improve so than we can increase data rate?

(3) how much time the Clustering and Tracking used? I test the AWR1642 boost board with 1.0005 SDK  , the GUIMonitor statics show about 4.9 mS  when use 256 ADC sample with 64 chirp loops with 2TX and 4RX. so if TIDUD31 table show 22.73mS for frame processing time, seems the time used for clustering and tracking is large than 15ms?

  • In the configuration contained in the demo, the chirp time is 53us, and there is a chirp loop of 46 times the 2 defined chirps (92 chirps per frame).  53us * 92 equals 4.876ms - the chirping period per frame.  The frame rate is 40ms (25fps), so that gives 35.124ms available for frame processing.  Table 3 indicates that 22.73ms of this consumed by frame processing, which according to my math is 22.73 / 35.124 = 64.7% loading.  I assume the table is rounding.

    To your questions:

    1) Yes, it refers to the time that frame processing is taking.

    2) This runs on the C674 DSP. It is not clear what you mean by increasing the data rate.  More chirps/frame, higher sampling rate per chirp, larger number of objects tracked, etc?  You need to define your requirements, then determine if the additional load will fit within the frame time without further optimizations, and if not, look into ways to make it fit.  There usually are several ways to do this, but you need to know what your design constraints are first.

    3) To my knowledge, these algorithms have not been profiled individually, per tracked object. This is not hard to do, simply search for Cycleprofiler in the demo and insert some of your own calls to capture the time.

  • Thanks for your answer. I will follow your suggestion to insert code in Cycleprofile to capture the time.