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.

IWR6843AOP: Finding the best trade-off for idleTime

Part Number: IWR6843AOP

Tool/software:

Hello,

I’m working on a modified version of the Area Scanner demo, and I'm trying to tune my chirp profile for my application's requirements.
There's one parameter that I don't quite fully understand its implications, which is the idleTime.
Right now, I have an idleTime of 100us:

profileCfg 0 60 100 10 79 0 0 24 1 256 4000 0 0 30


But I can set this much smaller, like 10us, or much larger and the profile will still be valid.
I know that there's a minimum of a couple of micro seconds, based on the bandwidth used, in my case is 3.5us.
And it should also be a bit higher if I use a low sampling rate, which I do (4 Msps).

I also know that as I lower the idleTime, it increases max velocity and velocity resolution, while it lowers
compliance chirp time and RF duty cycle.

My questions are:

  1. Are there other implications of lowering the idleTime apart from those described above?
  2. Does it impact motion sensitivity? A higher velocity resolution would mean a loss in motion sensitivity, right?
  3. What is the compliance chirp time?
  4. Is it essentially just a tradeoff between a higher velocity resolution and power consumption (RF duty cycle)?

Please tell me if there are other considerations and how should I approach the tuning of this parameter.
Thank you for your support!

Best regards,
Ed

  • Hello Ed,

    Have you been using our mmWaveSensingEstimator at all? If not I heavily using the "Advanced Chirp Design and Tuning" tab on it, copy and paste your .cfg parameters to the "Configuration I/O" text window and then hit the "AUTO-POPULATE" button. Ensuring the device selection is correct, all the configuration inputs should be set and the resulting outputs will be displayed below it. Try changing the idle time and see what resulting outputs change.

    https://dev.ti.com/gallery/view/mmwave/mmWaveSensingEstimator/ver/2.4.0/

    Best Regards,

    Pedrhom

  • Hello Pedrhom,

    Thank you for your response!

    Yes, I have been using the mmWaveSensingEstimator extensively, and it has been a valuable tool in understanding the implications of different chirp parameters. As you mentioned, I’ve observed that lowering the idleTime increases the maximum velocity and velocity resolution while reducing compliance chirp time and RF duty cycle.

    However, I still have some specific doubts that I would appreciate clarification on:

    1. Are there other implications of lowering the idleTime apart from those described above?
      I am curious if there are any subtle effects, such as changes in system performance or accuracy, that may not be immediately apparent in the Estimator.
    2. Does it impact motion sensitivity?
      My understanding is that increasing velocity resolution (via lower idleTime) could reduce motion sensitivity, since coarser resolution might make it harder to detect slower-moving objects. Is that interpretation correct?
    3. Is it essentially just a tradeoff between a higher velocity resolution and power consumption (RF duty cycle)?
      Or are there additional considerations (e.g., hardware constraints, temperature effects, or signal quality) that I should keep in mind when tuning this parameter?

    Thanks again for your support. I look forward to your insights!

    Best regards,
    Ed

  • Hello Ed,

    You have the main effects of idleTime correct, but anything more is a bit of an open discussion because saying "system performance" is a bit vague. You could say something along the lines of a larger idle time increases performance because it allows additional buffer time needed to run more complex processing algorithms.

    The larger the velocity resolution value, the more variance you will see in velocity measurements, thus it being less accurate.

    Best Regards,

    Pedrhom

  • Thank you Pedrhom, I think a have a decent understanding now.

    Best regards,
    Ed