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.

AWR1243: Buffering in the AWR1243 Before Sending to TDA3

Part Number: AWR1243

Hi,

I am trying to find out if there is some kind of FIFO Buffers inside the AWR1243 FW to store the ADC chirp frame. My understanding is that the IssCaptureLink gets notification of the ADC raw data at framePeriodicity interval. If there is a FIFO say 2 buffer deep, the ADC frame wouldn't be clocked out (or make available to the IssCapture) on the first interval but until the second interval. Is this really the case?

Thanks,

--Khai

  • Hello Khai,

    You are right, there is an internal ADC buffer to store the data from a single chirp before its sent out over CSI interface. For example if you have programmed 512 samples per chirp , we wait for 512 samples of data to be filled in the ADC buffer and then initial a transfer of this data out on the CSI interface. In parallel the second chirp sampling can continue while the previous chirp data is being transferred out. This is achieved by having two buffers which ae switched in ping-pong fashion.

    Regards,

    Vivek

  • Hi Vivek,

    What if I have 128 chirp in the frame instead of 1 chirp of 512 samples? My understanding is that IssCapture won't be notified until a whole radar cube size is available.Does that mean all 128 chirp (512 samples ADC data) are buffered before it initiates a transfer? What is the ADC time required to sample the analog chirp data + Chirp transmit/receive time (which we know was 4ms).

    The reason I am asking this question is that the returned chirp frame (128x512) seems to be 1 periodic interval (framePeriodicity set in the chirp profile config) behind? Can you confirm this is the case?

    Thanks,

    --Khai

  • Hello Khai,

    Are you referring to the data being sent our from the AWR1243 device out to the TDA or out from the TDA? From AWr1243 device the ADC data is sent out on  a per chirp basis. So independent of how many chirps you have in a frame the DAC data is sent out at the end of every chirp.

    regards,
    Vivek

  • HI Vivek,

    I am referring to ADC data coming out of the AWR1243 to the TDA3. That's is NOT what I experience when running the VisionSDK code on the TDA3. TDA3 IssCapture Link gets a single notification per frame interval (defined in framePeriodicity in the Chirp Profile Config) and this is the entire radar cube size (nRx * nChirps * nRangeBins). If it's sent on a per chirp basis, then the notification would have been in usec while framePeriodicity defined in the Chirp Profile is in msec.

    Thanks,

    --Khai

  • Hello Khai,

    The data from 1243 is sent out every chirp. But on the CSI driver on the TDA the data is handled at frame level. So it would keep collecting that data from the 1243 once frame start is got and it would wait till the frame end packet is received. After that it would transfer the whole frame data.

    regards,

    Vivek

  • HI Vivek,

    Can you point me to the CSI driver code on the TDA3? I would like to know if it also buffers the ADC data. As I mentioned again, what we see is that the ADC data arrives to the IssCapture 1 frame behind.

    Thanks,

    --Khai

  • Khai

    This is expected. The Driver holds on to the last buffer. 

    ti_components\pdk_\packages\ti\drv\vps\src\vpslib\isscore\src\vpscore_captureapi.c

    Thanks and Regards

    Piyali

  • Hi Piyali,

    Thanks for the response and Happy New Year.

    Can you give me a bit of top level description of how the driver interacts with the RFIC thru CSI interface? I would like to know:

    1. How and when it gets interrupted for data availability

    2. How does it hand over the ADC data to IssCapture

    3. What's the FIFO depth it holds in the driver of ADC data cube

    4. What happens if framePeriodicity is set too fast

    Thanks,

    --Khai

  • Hi Piyali,

    I looked into the code comment a little bit and bumped into this flag VCORE_ISS_CAPT_CAL_SET_SUB_FRM_PRMS where it said:

    In cases where applications requires to be notified as soon a frame
    is captured, the end-of-frame notification can be enabled with
    VCORE_ISS_CAPT_CAL_SET_SUB_FRM_PRMS

    Does this mean issCapture will be notified immediately upon current frame capture completion instead of waiting until the start-of-frame interrupt for the next frame which is set by default? Is the default behavior of the capture driver described exactly what we experience?

    If this is indeed the case, can you suggest how this flag can be set in the IssCapture Link or else where to make it effective? Is there side effect to using this flag? 

    Thanks,

    --Khai

  • Khai

    This flag VCORE_ISS_CAPT_CAL_SET_SUB_FRM_PRMS would only give you an indication if a sub frame has been captured. The Buffer is still not released but the ISS CAL driver till a new buffer is provided to it. The concept of holding on to the last frame buffer comes from the fact that the ISS CAL should always have a buffer with itself for writing the data which is captured by the CAL interface.

    Thanks and Regards

    Piyali

  • Got it. Thanks.

    --Khai