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.

Compiler/AWR1642: Difference of acquisition of raw data between using mmWave Studio and SDK code

Part Number: AWR1642
Other Parts Discussed in Thread: DCA1000EVM, ,

Tool/software: TI C/C++ Compiler

I acquired the raw date using mmWave Studio and SDK code for LVDS control.

I set the sensor configuration with 4byte for Rx, 256byte for adc samples, 128bytes for chirps, 2bytes for real+image (expect total 262,144bytes)

For setting in API code,


 

For setting in mmWave Studio,

※ Packet 0/1 Select

Packet 0 : ADC_ONLY (mmWave Studio) >>>  pCliCfg[index].lvdsStreamCfg.dataFmt = 1; (API code)

Packet 1 : Suppress Packet (mmWave Studio)   >>>   ??? ( I couldn’t find in API code)

※ Clock Setting

Lane Clock : DDR Clock  /   Data Rate : 600 Mbps (mmWave Studio)   >>>  hsiClkgs.hsiClk = 0x9;  initCfg.u.lvdsCfg.ddrClockMode    = 1U;  initCfg.u.lvdsCfg.ddrClockModeMux = 1U; (API code)

※ LVDS Lane Setting

Lane Format : Format 0 (mmWave Studio)  >>>   initCfg.u.lvdsCfg.laneFormat = 0U; (API code)

Lane Config : Lane1, Lane2 (mmWave Studio)  >>>  initCfg.u.lvdsCfg.lvdsLaneEnable  = 0x3U; (API code)

MSB Fist Check (mmWave Studio) >>>  initCfg.u.lvdsCfg.msbFirst        = 1U; (API code)

 

I want to confirm if the setting is correct in API code compared with mmWave Studio to acquire the raw data.

I expect the size of adc data for 1 frame is 262,144 bytes but only I got about 30,000 adc data (between header to header)

I got different size and format of header and adc data as mentioned in the SDK document (03.03.00.03)

And, when we use the ‘PostProc’ button in mmWave Studio, the header in raw date is removed.

If we want to acquire the raw data correctly, how can I change the setting in API code?

  • Seokhyun,

    Let's first clarify something. Are you modifying the Out-of-Box Demo from SDK version 3.3, flashing it to your AWR1642BOOST device, and then using the DCA1000EVM to capture the output data.

    If this is the case, please refer to section 3.3.2 "mmfWave demo with LVDS-based instrumentation" for more detailed instructions.

    In this scenario, you would not use mmWave Studio to capture the data. You use a .json file to control the DCA1000EVM.

    Otherwise, you would use mmWave Studio to configure your AWR1642BOOST EVM and capture just the raw ADC data.

    In this scenario, you are using the basic device firmware for both the BSS and MSS that is included in the mmWave Studio installation folder.

    You would not be running the Out-of-Box Demo and the output data would be different than the Out-of-Box Demo.

    Regards,

    Kyle

  • Kyle,

    Thank you for your response.

    I do not know  what "Out-of -Box" means.

    I used the code "mmw_lvds_stream.c" in mss for control the lvds. (referred in my first question above)

    In the user guide document of SDK, there is no direction for lvds control in SDK code.

    I want to control the lvds by mmw_lvds_stream.c in sdk code to acquire the raw data.

    And, I am using 2.1.0.4 version of sdk with flashing it to the AWR1642.

    In the document for 2.1.0.4 sdk, section 3.3.2 "mmfWave demo with LVDS-based instrumentation" does not exist.

    Also, I planned to make own capture board instead of DCA1000EVM to mount the radar and capture board on vehicle.

    BR

    Seokhyun Kang

  • Seokhyun,

    I would recommend that you download the latest mmWave SDK, version 3.3. You can download it here: http://software-dl.ti.com/ra-processors/esd/MMWAVE-SDK/latest/index_FDS.html

    This SDK includes documentation on how to implement LVDS streaming with the Out-of-Box Demo. By the Out-of-Box Demo, I mean the demo project that is included in the SDK. For SDK version 3.3, this demo project is found in this folder location:

    C:\ti\mmwave_sdk_03_03_00_03\packages\ti\demo

    SDK version 3.3 will contain the section I mentioned in the User's Guide.

    For some additional context, mmWave SDK version 2.1 was not designed to complete data capture with the DCA1000EVM. This functionality became available beginning with mmWave SDK version 3.2.

    Regards,

    Kyle

  • Seokhyun,

    Assuming that you have all 4 RX channels enabled on your device, your expected file size per frame is 524,288 bytes.

    I arrive at this number from the following calculation:

    ADC_Data_Size_per_Frame = sizeof(real_part) * sizeof(imaginary_part) * num_adc_samples * num_chirps * num_TX * num_RX

    Based on your screen shots above, I evaluate the equation as follows:

    ADC_Data_Size_per_Frame = (2 bytes) * (2 bytes) * (256 samples) * (128 chirps) * (1 TX) * (4 RX)

    ADC_Data_Size_per_Frame = 524,288 bytes

    Additionally, I would suggest removing the following line of code from "dss_lvds_stream.c"

    initCfg.u.lvdsCfg.laneFormat = 0U; //Add lane format lane-0

    You may be potentially overwriting a configuration that is already being handled by the CBUFF driver.

    Regards,

    Kyle

  • Kyle,

    We expected similar size of data what you mentioned. ( I calculated with 2bytes for complex number real(1)/ imag(1) )

    However, I got adc data about 32,000 bytes. (between header to header)

    And, do you mean that lane format is default setting for lvds control?

    Best regards,

    Seokhyun Kang

  • Seokhyun,

    What I am trying to say is that the CBUFF driver handles the lane settings for LVDS control, based on the platform (i.e. AWR1642) as well as the number of TX and RX lanes that are enabled in your configuration.

    So the init.Cfg.u.lvdsCfg.laneFormat = 0 line could be overwriting the configuration that the driver is already handling.

    The recommendation would be to remove this line, rebuild the code, and see if this changes the result.

    Regards,

    Kyle