• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 361 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.

IWR6843: Total frame time length

Pavel Bartoš
Prodigy 70 points
Part Number: IWR6843

Tool/software:

Hello,

we are running into issues when trying to have as big total frame time as possible (chirp cycle time * nr of chirp loops) - which I assume you call Active frame time. Is there any HW boundary, which limits us considering the time length of the measurement?

We are trying to get the lowest velocity resolution possible. This leads to having to set the Idle time high because of ADC sampling time having to be >2Msps.

Boundary of framePeriodicity using the demo SW is 1330ms. Is there a way to further increase this value?

Thank you,

Pavel B.

  • 0
    TI__Mastermind 22577 points

    Hello Pavel,

    No as this is a hard limitation on a firmware level, beyond the demo. You could potentially edit the firmware but we do not provide support on that.

    Best Regards,

    Pedrhom

  • 0 in reply to Pedrhom Nafisi
    Prodigy 70 points

    Hello,

    thank you for your answer.

    Is it a HW or SW limitation?
    What is the reasoning behind setting the upper threshold of it to 1330ms?
    Where can we please find the means to change the parameter (files/code line)?



    Thank you,

    Pavel Bartoš

  • 0 in reply to Pavel Bartoš
    TI__Mastermind 22577 points

    Hello Pavel,

    I want to add that velocity resolution is dependent on number of chirp loops, not frame periodicity, so if your goal is best velocity resolution aka lowest velocity resolution, you will need to focus on this. The two key factors that will affect the maximum number of chirp loops will be the amount of time it takes and the size of the radar cube. You have to ensure that you process and get the 2D FFT fully before the next frame gets in. Second, the more chirp loops you have, the more data that needs to be saved and eventually you will run into a memory issue. In a theoretical sense, the limitation of velocity resolution is the amount of memory space on the chip and speed in which you want to get a view of the environment. You can have a very low velocity resolution, but if you are only taking a snapshot of the environment every 2-3 seconds, depending on the application things can be missed.

    For more information between range resolution, velocity resolution, max velocity, and more, you can use the mmWaveSensingEstimator. On the "Advanced Chirp Design and Tuning" tab you can import a cfg file's parameters to get the chirp design's output statistics. Hover over the outputs to get a tooltip on how that output is calculated.

    https://www.ti.com/mmWaveSensingEstimator

    Hope that helps!

    Best Regards,

    Pedrhom

  • 0 in reply to Pedrhom Nafisi
    Prodigy 70 points

    We understand that, however the FFT limit of 512 samples is the hard limit for the IWR6843.
    The hard time limit of 1330ms - 

    Is it a HW or SW limitation?
    What is the reasoning behind setting the upper threshold of it to 1330ms?
    Where can we please find the means to change the parameter (files/code line)?

    We need to know whether it is in our means to change it and if it is, where to look to do that.

    Thanks,

    Pavel B.

  • +1 in reply to Pavel Bartoš
    TI__Mastermind 22577 points

    Hello Pavel,

    It is a hard limit and very likely due to a counter in the chip's front end. The firmware is fixed and cannot be changed.

    What can be done is having an external MCU to act as a trigger. You'd configure the radar to do one frame, and have the sync pins connected to drive it. When doing it like this you could have whatever frame periodicity you want.

    Best Regards,

    Pedrhom