• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 692 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/IWR1443BOOST: Frame Timing on People Counting Lab

Thomas McCotter
Prodigy 110 points
Part Number: IWR1443BOOST
Other Parts Discussed in Thread: IWR1642

Tool/software: Code Composer Studio

Hello!

I'm hoping somebody can provide some clarity with respect to frame timing in the People Counting Lab.  There seems to be a couple of conflicts between the documentation, code and device performance:

  • The User's Guide states that the timestamp data on the frame is from a free running 600MHz clock; however, the system clock speed constant in the code says it is 200MHz.  
  • The vales returned from the device for uartSent, TrackProcessing and ChirpMargin plus the difference in timestamp between the prior and current frame correctly add up to the FrameMargin if the timestamp is converted to micro-seconds using the 200MHz value for the clock.  The documentation states that those times are given in milliseconds (ms) but they seem to be in microseconds (μs).  
  • The documentation states that the sample rate is 50 frames per second, which would be consistent with timestamp (based on 200MHz clock speed); however, frames seemed to be sent through the UART approximately once each 50-60ms; no frames are missing in the sequence of FrameNumbers so, how is this possible?  I could be explained if the system were actually running at 80MHz but I don't think that is the case.

Is there a detailed explanation of what each part of the frame timing represents?  Could somebody verify that actual clock speed?  I have used the lab from the 2.1.2, 2.2.0 and 2.3.0 versions of the Industrial Toolbox and I see the issue in all three.

This code is lines 290-292 of :sys_common_xwr16xx_dss.h.  Could this be the source of the confusion?

/* Sys_vclk : 200MHz */
#define DSS_SYS_VCLK                                    (200000000U)
#define DSP_CLOCK_MHZ                                   (600U)

 

Thanks

Tom McCotter

  • 0
    TI__Mastermind 23725 points
    Hello Thomas ,


    We should be able to help you with detailed response on Monday Usa time.
    Regarding the frame rate question in the last bullet you can refer to the explanation of frame config parameter sent to the device via cli command/cfg. The frame periodicity parameter in frame config decides the rate at which Rf chirp frames are generated and data from these frames is post processed and sent out on user port. This parameter decides your update rate.
    Please check the Sdk’s User guide where this chirp parameter is explained.



    Thank you
    Vaibhav
  • 0
    TI__Mastermind 28055 points

    Hi Tom,

    1. On the IWR1642 device, there is a 600MHz DSP and a 200 MHz ARM Cortex.  The Cortex R4F supplies the timestamp, so the timestamp is based on the 200 MHz clock.
    2. The documentation is incorrect, these times are in micro-seconds.
    3. I am not sure where you read that the sample rate was 50 Hz.  Can you point me to this?  For the default configuration, sample rate is 20 Hz.
    4. The different time metrics in the Frame Header are used for debug. There are 4 values:
      1. chirpMargin - time to process a chirp 
      2. frameMargin - time to process the frame
      3. uartSentTime - time to send the data
      4. trackProcessTime - time to run the tracker

    We will try to quickly fix these documentation errors.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Prodigy 110 points

    Hi Justin,

    Thanks so much for your response, a few more points of clarification:

    Regarding your item 3 above, the issue is that if the timestamps for each frame are 20ms apart on the free-running clock how is it that a frame get delivered to the UART every 50ms and there are no missing frames?  Each timestamp's value less the prior timestamp's value divided by the 200MHz is 20ms, am I interpreting this correctly?  How is this possible?

    As to item 4, what exactly is the Chirp Margin?  Is this the time taken to process the received data?  It seems that that ChirpMargin, uartSentTime and trackProcess times are all happening outside of the timestamp from the R4F.  I assume the R4F is handling the transmit and receive side of things and the additional items (chirp processing, uartSentTime and trackProcessTime) are happening on the DSP in parallel with the subsequent frame, is that right?

    Thanks

    Tom

  • 0 in reply to Thomas McCotter
    TI__Mastermind 28055 points
    Hi Tom,

    The device is only capturing data at a rate of 20 Hz. How are you calculating the time step between frames?

    The chirp margin is the time available to the device to process the chirp data. This is measured as the time between the end of chirp N and the beginning of chirp N+1. This is determined in the DSS.

    The tracker and the UART are both controlled by the MSS in this lab, so these timestamps will be based on the MSS clock.

    Regards,
    Justin
  • 0 in reply to Justin Curewitz
    Prodigy 110 points
    Hi Justin,

    To get the time step I'm simply subtracting the last "timestamp" value in the prior frames header from the current frame's value and then dividing by 200MHz. The result (in micro-seconds) plus the chirpMargin, trackProcessing and uartSendTime correctly add up to the FrameMargin so I'm assuming this is the correct calculation. The confusion for me is that the frame timestamp implies that frames are being created at 50Hz but the UART is delivering frames at only 20Hz.

    I would suspect that either:

    1) Frames are being dropped; however this is not appear to be the case because the frame numbers are consecutive, or
    2) There is a delay between each frame; however, this does not appear to be the case because the timestamp value in the frame header is from a free-running clock and there is almost exactly 20ms between frames (50Hz).

    I'm trying to tie empirical data to the data reported to the device and this discrepancy is leading me to doubt my methods. I'm relatively new to all this so I may be missing something simple.

    Thanks

    Tom
  • 0 in reply to Thomas McCotter
    TI__Mastermind 28055 points
    Hi Tom,

    There is an oversight on my side. The fHist(x).timestamp field is set by matlab. To see the timestamp from the device, fHist(x).header.timestamp. Using your method, I get about 50 ms between frames.

    What are you hoping to use this data for?

    Regards,
    Justin
  • 0 in reply to Justin Curewitz
    Prodigy 110 points

    Hi Justin,

    I'm not using the MATLAB UI so I was only seeing the timestamp from the device.  I did my math on more recent data and I too am seeing 50ms between timestamps.  I could swear on prior versions I was getting values that where timestamp difference plus chirp, track and uart were exactly adding up to FrameMargin; however, I'm not seeing that now.  I'm satisfied with your explanation and I should be good now.

    In general, I'm just trying to get the closest association I can get between the timestamp from the device and video (ground truth) data.  I was frustrated earlier when I thought I was seeing frames being created every 20ms and only being reported every 50ms, that made me doubt my synchronization methods.  All good now.

    I really appreciate your attention and prompt replies to my messages, you guys do a great job!

    Tom