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.

IWR1443: Generic development flow to define/implement the RF and DFE configuration for the specific application

Part Number: IWR1443
Other Parts Discussed in Thread: MMWAVE-STUDIO,

Hi,

My customer would like to know the generic development flow of IWR devices especially RF and DFE configurations.

For example, one of my customer is seeing the following whitepapar 

And found the Table 2. Chirp configuration and radar performance for fluidlevel sensing. It seems this describe the target performance for this specific application. 

My customer`s questions is --- How to define the spec for the specific application and how to implement the configurations into the target device ? 

As for former question, should we use mmWave Sensing Estimator ? If so, how to import the configurations into mmWaveStudio or target device ?

And as for latter question ... it is difficult for me to explain, but I`ll try:

I know the environment of IWR devices + DCA1000 with mmWaveStudio can be used to evaluate RF/DFE performance with various configurations (Too many configurations ! -- and many parameters are unclear to use...). I think this environment would be useful to evaluate RF/DFE performance in early development phase, but once the configurations are validated, how can user implement these configurations into their own IWR firmware ? In case of IWRxxxBOOST + DCA1000 environment, we use binary image for IWR firmware and unfortunately, there is no source code for that. In other words, the communications (control and commands between mmWaveStudio GUI and the target IWR device) to configure RF/DFE are still unclear. So even if the configurations are validated on IWRxxxBOOST + DCA1000 environment. I`m wondering if users couldn`t understand how to program the IWR device to have the same RF/DFE performance with IWRxxxBOOST+DCA1000 environment.
I know some source code are available for demos (for example, ppcount, level sense, etc...). All of them are using UART for command I/F to configure IWR device including RF/DFE. Each demo has their own command handler implementation to parse the incoming commands and execute rader APIs. So if we should use the demo sample code as a template for customer`s application, I think it might be useful if we have mapping information from the above black-boxed communication to rader APIs to be executed in the target device.

Could you please kindly suggest ? Please note I`m new in mmWave devices.

Best Regards,
NK 

  • TI’s mmWave sensors are based on Frequency Modulated Continuous Wave (FMCW) radar technology. The design process for an FMCW radar system starts with determining the sensing requirements for the application such as the type of target(s) to be detected, Field of view (azimuth and elevation), maximum range, maximum velocity, range resolution, velocity resolution and angular resolution. The type of target(s) to be detected is quantified as the RCS (Radar Cross Section) value which is a measure of the target’s ability to reflect Radar Signals in the direction of the radar receiver and field of view is dependent on the Antenna design, but the other requirements such as max range, max velocity etc are achieved by designing appropriate chirp and frame design.

    The mmWave Sensing Estimator helps users calculate the chirp parameters for TI’s mmWave Radar devices based on high level inputs such as maximum range, range resolution, maximum unambiguous velocity etc. (If you need to understand the theoretical aspects behind the various chirp parameters and their relation to the scene requirements, please look at the app note Programming Chirp Parameters in TI Radar Devices)

    Next, you can enter the various parameters calculated by the Sensing estimator into MMWAVE-STUDIO to evaluate the detection performance of the chirp configurations using MMWAVE-STUDIO. Please refer to the MMWAVE-STUDIO users guide for more details. You can also evaluate the sensor using pre-defined configurations with the mmWave SDK OUt of box demo and mmWaveDemoVisualizer.

    The computed chirp parameters are programmed into the mmWave device using the mmWave Link API which is provided in TI's mmWave SDK. The mmWave Link API allows the application to configure, control, and monitor the Radar subsystem using high level function calls. Hence, the next step is to map the chirp parameters to a set of mmWave Link API calls which are called from the application. To understand this process, please refer to the mmWave SDK users guide, especially the section "Configuration File format". Most of the lines in the Configuration file map to an equivalent API that configures the corresponding parameters in the Sensor. The CLI in the demo parses the Cfg file and maps the parameters to the API calls (for e.g. profileCfg., chirpCfg, frameCfg, etc).

    With the sensor configured according to the scene requirements, the next step is to design the digital processing chain to process the ADC data coming from the front-end to extract the range, velocity and angle information and optionally perform other high level operations. The typical FMCW processing flow on the received data consists of a series of FFT operations for Range and Doppler processing, followed by detection algorithms (such as CFAR) and Angle of Arrival estimation. TI’s IWR1443 device includes a Hardware Accelerator for FFT (Range, Doppler and Angle estimation) and CFAR detection processing. The IWR1643 replaces the Hardware Accelerator with a C674x DSP which is used for the FFT (Range, Doppler and Angle estimation) and CFAR detection and also to run advanced algorithms such as clustering and tracking. The mmWave SDK provides the hardware accelerator drivers for the 1443 as well as software FFT and CFAR libraries for the DSP on 1642 along-with other drivers such as ADC buffer, SPI, HWA, and EDMA etc. to help implement the radar processing chain on either device. Please refer to the SDK OOB demos and the various other examples provided under mmWave Industrial Toolbox to understand the software processing.

    Please also refer to mmWave Training Series for many helpful training resources.

    Regards

    -Nitin

  • Hello Nitin,

    Thank you so much for you kind answers. That make sense. It seems I need to have more good understandings for the following.

    Nitin Sakhuja said:
    The computed chirp parameters are programmed into the mmWave device using the mmWave Link API which is provided in TI's mmWave SDK. The mmWave Link API allows the application to configure, control, and monitor the Radar subsystem using high level function calls. Hence, the next step is to map the chirp parameters to a set of mmWave Link API calls which are called from the application. To understand this process, please refer to the mmWave SDK users guide, especially the section "Configuration File format". Most of the lines in the Configuration file map to an equivalent API that configures the corresponding parameters in the Sensor. The CLI in the demo parses the Cfg file and maps the parameters to the API calls (for e.g. profileCfg., chirpCfg, frameCfg, etc).

    I`ll dig into this part. For now, I close the thread. 

    Best Regards,
    NK 

     

  • Hi,

    As for mapping information of radar API, it looked like the following log is useful.

    Here is a snippet from C:\ti\mmwave_studio_01_00_00_00\mmWaveStudio\PostProc\adc_data_LogFile.txt:

    20-Sep-2018 10:42:27: IsFPGA:,0,0,
    20-Sep-2018 10:42:27: C:\ti\mmwave_studio_01_00_00_00\mmWaveStudio\RunTime,0,
    20-Sep-2018 10:43:33: API:select_chip_version,AR1642,0,
    20-Sep-2018 10:43:34: API:select_chip_version,AR1642,0,
    20-Sep-2018 10:44:45: API:ChannelConfig,3,15,0,
    20-Sep-2018 10:44:45: API:AdcOutConfig,2,2,0,
    20-Sep-2018 10:44:45: API:DataFmtConfig,15,2,1,0,1,0,
    20-Sep-2018 10:44:46: API:LowPowerConfig,0,0,0,
    20-Sep-2018 10:44:57: API:DataPathConfig,1,1,0,2,0,
    20-Sep-2018 10:45:19: API:LvdsClkConfig,1,1,0,
    20-Sep-2018 10:45:19: TSW1400 Sampling rate : 600000000 7500000,0,
    20-Sep-2018 10:45:19: API:SetHsiClock,9,0,
    20-Sep-2018 10:45:20: API:LaneConfig,3,0,
    20-Sep-2018 10:45:20: API:LvdsLaneConfig,0,1,0,
    20-Sep-2018 10:45:25: API:ProfileConfig,0,1435384036,10000,600,6000,0,0,621,0,256,10000,0,0,30,0,
    20-Sep-2018 10:45:26: API:ChirpConfig,0,0,0,0,0,0,0,1,0,
    20-Sep-2018 10:45:28: API:EnableTestSource,0,1,0,
    20-Sep-2018 10:45:28: API:FrameConfig,0,0,8,128,8000000,0,512,0,
    20-Sep-2018 10:45:28: API:AdvancedFrameConfig,1,0,0,0,1,128,8000000,0,1,1,8000000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
    20-Sep-2018 10:45:29: API:select_capture_device,DCA1000,0,
    20-Sep-2018 10:48:54: API:SensorStart,0,
    2

    For example, can i understand API:ChirpConfig and following arguments means chirpCfg with the same arguments (it has been defined in 3. 4. Configuration (.cfg) File Format in mmwave sdk user guide). Correct ?
    (If yes, i`m not sure why the arguments of API:xxxxxx command has been always terminated with 0)

    Best Regards,
    NK
  • Any comments?

    BR
    Nk
  • Hi Nk,

    The 0 termination of the argument string is specific to MMWAVE-STUDIO and should not be used with the mmWaveLink API. Moreover, MMWAVE-STUDIO does not use the .cfg file defined in the SDK documentation. Please follow the SDK documentation, mmwavelink API documentation and the SDK mmw demo code to understand the chirp parameter mapping to the mmwavelink API.

    Regards
    -Nitin