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.

IWR1843BOOST: Chirp timing tuning

Part Number: IWR1843BOOST


I'm interested in getting as high a frame rate as possible with a large number of chirps, and I'm capturing the raw ADC data, and I'm not interested in any onboard processing.

In the mmWave SDK user guide, it is stated that the active chirp duty cycle should be less than 50% (in frameCfg). Is the entire chip considered "active chirp" or it the part where the transmitter is on?

It is also mentioned in the documentation that if raw capture is used, there should be enough idle time for all data to be sent over LVDS. How can the idle time be computed or tuned such that it is reduced to the minimal?

  • Hello Teck Yian Lim,

    For capturing raw ADC data mmWave studio with DCA1000 is used. In this framework there is no on board processing done, all the processing are done on the mmWave studio, You want to do custom processing you could do with matlab or similar tools based on the raw adc data available. 

         You could refer to mmWave studio chirp configuration section for configuring chirp parameters including idle time, TX start time and frame rate configurations.

    In the chirp configuration below shows the idle time, this idle time could be configured through the chirp configuration section in the mmWave studio. By increasing the idle time it would reduce the number of data, hence over all data rate going through the gigabit Ethernet. 

    mmWave studio also provides the duty-cycled used based on the configured chirp paramters.

    Thanks and regards,

    CHETHAN KUMAR Y.B.

  • Hi,

    Thanks for the reply, however it does not answer my question. I'm aware of the tools mentioned above and I have my data processing chain implemented.

    To clarify, I'll like to know of any hardware limitations that will prevent me from lowering idle times. In the documentation, with a bandwidth of >3GHz, the settling time after the ramp is stated as 7us. However,

    1) there isn't any reference on how long the ADC valid start time should be to avoid the knee at the start of a ramp.

    2) there isn't any guideline on the timing required based on the number of ADC samples, but it is stated the idle time + ADC start time needs to be long enough for raw data transfer.

    3) both in mmwave studio and the sdk documentation, there's a mention of 50% duty cycle. Does this duty cycle refer to the "Ramp end time" or the entire chirp cycle time (i.e idle time + ramp end time)

    Ideally, I'll like to set my idle time to 7us, ADC valid start time to 0us and frame time to be exactly the number of times I repeat each chirp. (i.e. chirp cycle time * N)

  • Hello,

       At high level to understand the implications of idle_time, ADC_start time, Tx start time and ramp end time you could refer to below application note. 

    http://www.ti.com/lit/an/swra553a/swra553a.pdf

    For the below two questions you could refer to the Chirp timing calculator in the mmWave studio. 

    1) there isn't any reference on how long the ADC valid start time should be to avoid the knee at the start of a ramp.

    2) there isn't any guideline on the timing required based on the number of ADC samples, but it is stated the idle time + ADC start time needs to be long enough for raw data transfer.

    Ramp settling time has the implication on the ADC valid start time, smaller the ADC valid start time lesser would be time available for the synthesizer to be in linear region of the ramp. You could use the Ramp timing calculator to analyze the ADC_start time and Ramp end time to analyze the affect on the chirp timing parameters and settling time behaviors.

    3) both in mmwave studio and the sdk documentation, there's a mention of 50% duty cycle. Does this duty cycle refer to the "Ramp end time" or the entire chirp cycle time (i.e idle time + ramp end time)

    If the idle time + Tx start time is less than < 10usec then entrie chip cycle time including idle time is included in the duty-cycle calculation, if the idle time + Tx start time is less than > 10usec then idle time + Tx start time is excluded in the active period of Duty-cycle calculations. This is mainly due to dynamic power saving options gets enabled f the idle time + Tx start time is less than > 10usec, which disables the Tx and Rx blocks during the inter-chirp period, Hence this duration need to be excluded for the on time-calculation of duty cycle. In the profile configuration duty-cycle calculation account for this behavior. 

    For the below question:

    "Ideally, I'll like to set my idle time to 7us, ADC valid start time to 0us and frame time to be exactly the number of times I repeat each chirp. (i.e. chirp cycle time * N)"

    You should be able to set the idle time to 7us then this idle time would be part of RF on time for the duty-cycle calculation.And choosing ADC valid start time to 0us  you may be introducing settling time artifact of Synthesizer depending upon the slope/BW used, based on the chirp timing calculator explained above. As long as you are aware of this trade-off you should be able to configure the above chirp configuration. 

    Thanks and regards,

    CHETHAN KUMAR Y.B. 

  • Hello Teck Yian Lim,

      In the above post Ramp-gen timing calculator did not show up correctly, not sure why, hence re-attaching the image for the reference.

    Thanks and regards,

    CHETHAN KUMAR Y.B.

  • Hi Chethan, 

    Thanks for the reply, there's just a small question remaining. From the documentation, I gather that the chirp's ADC data is sent out at the end of the chirp after Tx is turned off. Thus, idle time + ADC valid start time needs to be long enough for all the samples to be sent. Does mmWave studio's timing include this? Or can I safely assume that the transfer time is negligible and I don't have to worry about it?

  • Hello Teck Yian Lim,

    If you use faster LVDS data rates for example 600Mbps then it's time is negligible. We need to consider that effect for lower LVDS data rate and for very small idle time values. For your application it should not be a problem. 

    Thanks and regards,

    CHETHAN KUMAR Y.B.