• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 1410 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.

AWR1642BOOST: ADCBUFCFG : Chirp threshold

Santhana Raj
Expert 1765 points
Part Number: AWR1642BOOST

Hi,

In the mmWave SDK 1.1.User guide, the profile configuration that has to be done over UART for mmWdemo and/or Capture Demo,I for some confusion regarding the ADCBUGCFG parameter.

The last value in the parameter is termed as "Chirp Threshold". And the explanation goes like this:

0: Determine chirp threshold automatically. to maximize 32 KB usage of ADCBUF memory while meeting requirements of divisibility (multiplicity of 2 and divisibility by number of chirps in a frame).
n: Set to n unless....
    1. n exceeds what is determined to be possible maximum based on 0 interpretation above.In such case, the demo app will cap the value to the max with a diagnostic warning message that threshold has been capped to max.
    2. n does not meet divisibility requirements and in this case, demo app will throw an assert.

The User Guide also says that only value of 1 is supported  in mmW demo and Capture demo.

My question is: I am not able to understand or visualize the use case or situation where chirp threshold will be other than 0.

I think My doubt is basically what this parameter does and the requirement of such parameter.

  • 0
    TI__Expert 5235 points
    "The User Guide also says that only value of 1 is supported in mmW demo and Capture demo"
    I am not sure how you reached this conclusion from reading the UG, can you explain? The conclusion that can be reached from reading the UG is that the feature of threshold programmability (setting numbers other than the trivial case of 1) is only supported on 16xx in the mmw demo.

    The purpose of this is configuration is to allow multiple chirps to be accumulated in the ADC buffer (within the limits of the physical ADC buffer size in the SoC) before being processed i.e the chirp interrupt comes every n chirps instead of the usual case of every (1) chirp, so 1 D processing happens n chirps at a time. It improves processing efficiency which as mentioned in section "Multichirp use case" of www.ti.com/.../swra552.pdf can allow for lowering power consumption (due to more idle time) or more processing time for background processing during 1D. It comes at the cost of processing latency (net increase of (n-1) chirps of processing time), so user is given control of what they want to set. The feature is also more suitable for small chirps where overhead of interrupt puts less pressure on the chirp processing deadline because you can process multiple smaller chirps per interrupt.

    In the mmw demo doxygen, the section "Data Path - 1st Dimension FFT Processing" illustrates the case where the chirp threshold is 2 [contrast the diagrams with what was in SDK 1.0 where the feature was not supported i.e the diagrams where with chirp threshold of 1].
  • 0 in reply to Piyush_
    Expert 1765 points

    Hi Piyush,

    Thank you for the explanation.

    "The conclusion that can be reached from reading the UG is that the feature of threshold programmability (setting numbers other than the trivial case of 1) is only supported on 16xx in the mmw demo."

    You are correct. My statement was wrong. Sorry for the confusion.

    And about the explanation, it is helpful Now I understand the reasoning of chirp event coming late that I expected. The document you referred is also helpful

  • 0 in reply to Santhana Raj
    TI__Expert 5235 points

    Just to be clear, 1 is allowed so if you do not want chirp to be late, you can set the threshold to 1. It seems the documentation when it says multiplicity of 2 as a requirement, users may rule out 1 even though it is allowed, we will clean up the documentation in a future release to make it unambiguous. Thanks.