xWRL6432 MMWAVE-L-SDK  05.04.00.01
Motion and Presence Detection OOB Demo

Purpose and Scope

The Motion and Presence Detection OOB demo shows some of the capabilities of the xWRL6432 SOC using the drivers in the MMWAVE-L-SDK (Software Development Kit). The chapter provides description of system execution flow, memory usage, task organization and benchmark results. The chapter focuses on the implementation details of the low-level signal processing chain. It allows user to specify the chirping profile and displays the detected objects and other information in real-time. The demo comes with some default configurations (PresenceDetect.cfg, MotionDetect.cfg etc...). The configuration in PresenceDetect.cfg leverages the Minor Motion mode of the Signal processing chain to demonstrate the sensors ability to detect presence through fine motion. The MotionDetect.cfg configures the device to detect moving objects. It outputs a point cloud that can be fed to a tracker.

Supported Combinations

Parameter Value
CPU + OS m4fss0-0 freertos
Toolchain ti-arm-clang
Board xWRL6432-evm
Example folder examples/mmw_demo/motion_detection

Supported Features

Feature Description
Quick Evaluation Preflashed default application toggles the user LED based on presence detected within 1x1 sq mtr box infront of the radar. This feature is disabled by default.
Feature Lite Build This feature generates an optimized application with reduced RAM and inturn reduced power. It is important to note that CLI is removed, if this feature is enabled, in addition to other features such as ADC logging, Monitors etc. This is disabled by default.
Dynamic Reconfig This feature enables seamless transitions between high-performance tracker processing and low-power presence detection, for intelligent power saving. This feature is disabled by default.
Raw ADC streaming Streaming of adc data over RDIF+DCA1000 or SPI. This feature is disabled by default.
Monitors FECSS analog monitors. This feature is disabled by default. This feature is disabled by default.

Using SysConfig

A GUI tool SysConfig is used to configure different modules and peripherals of the example. Using this tool, users can select and customize different modules and peripherals. The SysConfig tool will generate the code for initializing and configuring these modules. This configuration is saved to a file called example.syscfg for every example. To know more about how to use SDK with SysConfig, Visit this page

Using SDK with SysConfig

Custom Demo Code Options

Additionally, the GUI also allows enabling of supported combinations of the features listed above.

Steps to enable/disable the supported features

  • Open the demo example.syscfg and navigate to the TI DEMO menu
  • This provides the flexibility to Enable/Disable the features as shown in the figure below. Choose the required features and save the example.syscfg file

  • Compile the application and run the demo with the updated binaries
Note
  • For Feature Lite Build, there is an additional option to upload CLI json file to update the predefined configurations. However, this is an optional step, only if the default configuration needs to be updated
  • When Feature Lite Build is enabled, the following features are not supported:
    • Monitors
    • Raw ADC data streaming
    • Phase Compensation
    • Dynamic Reconfig
    • MPD DPU

Motion Detection Demo Setup

The OOB motion/presence detection demo setup is shown in Figure below. The demo configuration is provided by the command line interface (CLI) configuration file. The PC visualizer is connected to the xWRL6432 EVM board via single UART port. The motion/presence detection algorithm runs on the xWRL6432 radar sensor. Initially, to start a demo, a set of CLI configuration commands is sent to the EVM. Based on the configuration the EVM sends through the same port various detection information to the visualizer, such as point cloud, range profile, detection heatmap, presence detection information, and stats data.

OOB Motion detection demo setup

The updated release of the SDK incorporates new functionalities including target tracking and target classification. With these added functionalities, the OOB demo can perform different use cases that can be controlled through the CLI configuration file.

Below is the processing layers of the demo for the motion/presence detection use case.

The signal processing layers of the motion/presence detection demo

Below is the processing layers of the demo including target tracking and classification.

The signal processing layers including target tracking and classification

Below is the top-level radar signal processing timing diagram per frame including presence detection, and target tracking and classification.

Signal processing high level timing diagram

MIMO Modulation Schemes

Motion Detection OOB Demo supports two MIMO modulation schemes TDM-MIMO and BPM-MIMO scheme. Typical timing diagram is illustrated in Figure below.

Chirp timing diagram TDM-MIMO and BPM-MIMO

Chirp Configuration Modes

The motion detection demo currently supports two chirp configuration modes “Normal mode” and “Burst mode”. The following configuration conditions are defined for the two modes. In the normal mode, one burst per frame is configured, and the number of chirps is even number, while in the burst mode 2 chirps per burst are configured, and the number of bursts per frame is even number. Both modes support either TDM or BPM MIMO modulation scheme. The Tx antenna pattern for these two modes is illustrated below.

2Tx MIMO pattern in Normal Mode

2Tx MIMO pattern in Burst Mode

Antenna Geometry

The demo supports different antenna configurations. This is achieved through the CLI configuration. The antenna pattern is specified by the CLI command antGeometryCfg. The command specifies the row and column position for each virtual antenna in the 2D virtual antenna array grid, as illustrated in Figure below. The syntax of the command is

antGeometryCfg ant1Row ant1Col ant2Row ant2Col …ant6Row ant6Col distX distZ

The last two parameters of the command specify antenna spacing (in millimeters) in X and Z dimensions.

Virtual antenna arrangement based on the Tx/Rx antenna pattern and the corresponding CLI configuration command for xWRL6432 EVM board

Below figure shows the antenna configuration on the IWRL6432 EVM board.

IWRL6432 EVM board, FR4 based, 2-patch antennas.

The antenna spacing and the virtual antenna array are shown below. The right-most figure shows the virtual antenna with the red and blue antennas corresponding to TX1 and TX2 respectively.

Antenna spacing and virtual antenna array representation

Signal Processing Chain

The top-level signal processing chain implemented on xWRL6432 for the presence/motion detection use case is shown below. For more information on the signal processing chain please refer ${SDK_INSTALL_PATH}/docs/MotionPresenceDetectionDemo_TuningGuide.pdf.

High level view of radar processing chain with presence detection option

Below is the top-level signal processing chain including the tracker and micro-Doppler based classification and discrimination between human and non-human targets.

Top-level view of radar signal processing chain tracker and tracker and classification

The basic signal processing is split among the following data processing functional block units (DPUs)

  • Range DPU: Performs:
    • BPM decoding applied on the ADC samples,
    • Range FFT for each antenna and chirp.
    • The only radar data cube format supported in this demo is DPIF_RADARCUBE_FORMAT_6
  • DOA DPU: Creates the range azimuth detection matrix (heatmap). Per range bin it performs:
    • Doppler FFT per each antenna,
    • Static clutter removal by dropping zero Doppler bin,
    • Antenna mapping into (azimuth-elevation) 2D array, and 2D angle FFT per Doppler bin,
    • Summation and peak selection across Doppler dimension,
    • Peak selection across elevation dimension. (NOTE: The angle-FFT processing of the SDK only supports the antenna configuration shown in Figure above. Below chapters describes how this may be modified for other antenna configurations. The summation/peak selection across Doppler and elevation dimensions are used to collapse the Doppler and elevation dimensions to create a range-azimuth detection matrix)
  • CFAR DPU: Performs CFAR detection algorithm on the range-azimuth detection matrix:
    • CFAR detection algorithm (CFAR-CASO) applied along range dimension,
    • Detected points confirmed by being local peak in azimuth domain,
    • Range and azimuth interpolation,
    • Elevation estimation as maximum peak selection in elevation domain,
    • Radial Velocity estimation as maximum peak selection in Doppler domain,
    • Calculates cartesian coordinates of detected point, places detected point to point cloud list.
  • Presence Detection DPU: Performs:
    • Zone association,
    • Search for clusters in Cartesian space,
    • State machine per zone,
    • Outputs presence information per zone
  • Tracker processing DPU: Performs target tracking based on the point cloud data and reports a list of tracking targets.
  • Micro-Doppler DPU: Performs the classification of detected and tracked targets. The classification is based on the features extracted from the detected µ-Doppler spectrum reflected from the target. It includes the following functionalities per detected target:
    • µ-Doppler spectrum computation,
    • Feature extraction from the µ-Doppler spectrum,
    • Classification of detected targets as human or non-human.

Motion Detection Modes

Motion detection algorithm supports following motion detection modes.

  • Major motion detection mode: In this mode, the detection layer chain runs one time using the radar cube from the current frame. The Doppler FFT processing is done across chirps in a single frame.
  • Minor motion detection mode: In this mode, the detection layer chain runs one time using the radar cube created across the current and previous frames. The Doppler FFT processing is done across chirps that span multiple frames.
  • Auto mode: In this mode, the detection layer chain runs two times using both the radar cube from the current frame and the radar cube created across the current and previous frames.

The radar cube generation in Major and Minor mode is illustrated in Figures below.

Radar cubes for Major and Minor motion detection

Radar processing chain in auto mode (major and minor motion detection mode)

Dynamic Reconfig

This feature enables seamless transitions between high-performance tracker processing and low-power presence detection through the designed state machine. It additionally achieves power saving by intelligent configuration switching, based on the detected scene.

The flow diagram is shown below.

This feature can be added to the demo code by using syscfg, as it is disabled by default. And, the configuration parameters can be populated via CLI command - "profileSwitchCfg" which has the following parameters:

  • switchCfgEnable: 0: Disable, 1: Enable.
  • frmPretoTrack: Threshold on number of frames for switching from presence to tracker state.
  • frmTracktoPre: Threshold on number of frames for switching from tracker to presence state.

Users can initiate the demo with either the presence/tracker configuration. Once the set threshold is hit, the sensor smoothly switches to the alternate configuration (tracker/presence) predefined in the demo application. When the sensor returns to the initial config state based on the state machine, it takes the saved user configured parameters.

For example, if a user starts the demo with the presence configuration with profileSwitchCfg enabled, the sensor automatically transitions to the tracker configuration when continuous presence is detected for frmPretoTrack frames. If no tracker objects are detected for frmTracktoPre frames, the demo reverts to the user-provided presence configuration. This cycle repeats based on the sensing scene. In turn, power saving is also achieved by staying in the low power presence configuration, unless a constant movement is detected for the configured number of frames.

Note: This feature can be enabled only when lowPowerCfg CLI command is enabled. This is to ensure maximum power saving possible and optimal demo experience overall.

Rx Channel Gain/Offset Measurement and Compensation

Because of imperfections in antenna layouts on the board there is a need to calibrate the sensor to compensate for bias in the range estimation and the receive channel gain and phase imperfections. The motion detection demo provides the ability to do the measurement and compensation.

Measurement Procedure Implementation

The measurement procedure is configured using a CLI command measureRangeBiasAndRxChanPhase. The following is the command syntax:

measureRangeBiasAndRxChanPhase enabled targetDistance searchWindow

  • where enabled - is the flag to enable the procedure, targetDistance - is the distance of the strong target in front of the sensor at the bore site (in meters), searchWindow - is the search window (in meters).

The procedure is implemented by the function mmwDemo_rangeBiasRxChPhaseMeasure(). It is called in the processing chain after the range processing DPU. The input to the procedure is a radar cube. The measurement procedure first calculates the range profile as the sum of the magnitude squares across all antennas on the range FFTs. Then it searches for the peak in the zone 𝑋−𝐷/2 ≤ 𝑟𝑎𝑛𝑔𝑒 ≤ 𝑋+𝐷/2 where 𝐷 = searchWindow and 𝑋 = targetDistance.

The procedure then estimates the peak position using the three point parabolic interpolation and the range bias as the difference between the peak position and the configured target distance X.

The Rx channel compensation coefficients are calculated according to following equations.

From the radar cube stored as a complex16 3D array 𝑋[𝑐ℎ𝑖𝑟𝑝][𝑎𝑛𝑡𝑒𝑛𝑛𝑎][𝑟𝑎𝑛𝑔𝑒], the received symbols are extracted at the range index 𝑖𝑝𝑒𝑎𝑘 of the peak position corresponding to the target as

The coefficients are calculated as

where

The coefficients are sent per frame to the host within the TLV packet.

Measurement Procedure Steps:

  • Set a strong target like corner reflector at boresight at desired distance and measure precisely the distance from the sensor.
  • Create the CLI configuration file for the measurement procedure with
    • the enabled flag to 1 in CLI command measureRangeBiasAndRxChanPhase,
    • all antennas enabled,
    • TDM MIMO mode selected,
    • major mode detection enabled.
  • Run the target demo. The target sends TLV with the calculated coefficients.
  • Copy one snapshot of the coefficients to clipboard.
  • Paste the copied line into the final CLI configuration file.

System execution flow

This section explains the execution flow of the demo during both the initialization and configuration stages, as well as during each frame in the steady state.

Initialization and Configuration

The system execution flow at the initialization and configuration time is shown in Figure below. At the startup the system initialization is performed, the CLI task is created, waiting for the input CLI commands. After receiving the CLI sensorStart command, the last command in the configuration sequence, it configures the RF and then creates the demo DPC task, mmwDemo_dpcTask. As the DPC task has higher priority than the CLI task, it preempts the CLI task, and performs the configuration of the signal processing chain components, and calls the range processing API as a first processing DPU in the chain. The range processing function starts pending on the semaphore waiting for the first frame chirping and the chirp processing time to complete. The task control is then switched back to CLI task that creates the UART transmit task, mmwDemo_TransmitProcessedOutputTask, and issues the sensor start command to the RF. The CLI task then enters the pending state and remains in it from that moment on. The power management task, that is also created at the start time is engaged only in the power saving mode.

Initialization and configuration

Steady state – low power mode disabled

The steady state system execution flow is periodic, executed per frame. Figure below shows the system execution flow over one frame period. The frame ISR function is triggered upon the frame start event, and currently it is only used for diagnostic purpose. During the chirping time, the HWA is performing the chirp processing, while the range DPU process function is waiting for the HWA processing to complete. After the range processing, the DOA DPU followed by CFAR DPU are executed creating the point cloud list. The point cloud list is compressed to fix format ready to be sent out to the Host. The HWA is then configured for the next frame, semaphore post to the UART task indicating that the frame data are ready, and the range processing API is called for the next frame. The DPC task goes to pending state giving control to the UART task to send data to the HOST.

System execution per frame when low power mode is disabled

Steady state – low power mode enabled

The steady state system flow in low power mode is shown in Figure below. In the low power mode the powerManagementTask() controls the power savings. When the UART task completes the data transfer to the Host of the frame n, it calculates the available time for the low power deep sleep phase as 𝑇𝑠𝑙𝑒𝑒𝑝(𝑛) = 𝑇𝐹𝑟𝑎𝑚𝑒 − 𝑇𝐷𝑒𝑚𝑜(𝑛) − 𝑇𝑙𝑝𝑑𝑠𝐿𝑎𝑡𝑒𝑛𝑐𝑦

System execution per frame when low power mode is enabled

Task Model

Motion detection demo is implemented on xWRL6432 using multiple tasks running in the system. Table below list all tasks used in the system.

Motion detection demo tasks

Main Task

This is free RTOS main task initially called by the main function. It is active only during the start time, and after the creation of the CLI task it rests in pending state.

CLI Task

The CLI task provides the execution context for the command line interface. It includes simple command parser.

DPC Task

The DPC task provides the execution context for the detection processing chain.

UART Task

This task controls the transfer of radar detection data to the host. The task transmits one packet of data per radar frame using a TLV format structure. Depending on the CLI configuration command guiMonitor the task sends point cloud, range profile, detection matrix, presence detection information, etc.

ADC read data Task

This task is used for running the unit tests for motion detection demo. The task reads reference ADC data samples from the file and feeds the signal processing chain instead of real ADC data coming from the RF.

Power Management Task

This task is engaged when the motion detection demo is running in the power saving deep sleep mode.

Timing Diagram

The timing diagram during the startup and the first two frames is illustrated below

Timing diagram – low power mode disabled.

The timing diagram in the low power mode is shown below.

Timing diagram – low power mode enabled.

Memory Usage

The OOB motion detection demo memory usage can always be found in the MAP file. The current usage is shown in Table below.

Motion detection OOB demo memory usage

Some of the data arrays are dynamically handled using a set of simple memory allocation utility functions, provided below.

Memory allocation functions

Two memory heaps are created, one in the local core memory, gMmwCoreLocMem[28*1024], and the other, gMmwL3[416K], occupying 256KB shared memory of APPSS and 160KB shared memory of HWASS. Currently less than one 1kB of memory is allocated in the local core RAM.

In addition to the above local core memory heap, two more memory heaps objects are created in gMmwCoreLocMem2[25*1024] and gMmwCoreLocMem3[2*1024] using the free RTOS memory heap management scheme. The former is used for the tracker and the latter is used for the feature extraction and for the classifier.

The usage of the shared memory depends on the configuration. At the start time, after the CLI commands has been received and configuration completed, memory usage of these two heaps is printed out on the console.

The memory usage for the CLI configurations files provided in this SDK release is shown in Tables below. (The configuration files are located in examples/mmw_demo/motion_and_presence_detection/profiles.)

Memory usage – dynamic allocation in major motion mode, (configuration file: MotionDetect.cfg).

Memory usage - dynamic allocation in minor motion detection mode, (configuration file: PresenceDetect.cfg).

Memory usage - dynamic allocation in auto motion detection mode, with tracker and classifier, (configuration file: TrackingClassification_MidBw.cfg).

Memory usage - dynamic allocation in auto motion detection mode, with tracker and classifier, (configuration file: TrackingClassification_HighBw_4Ant.cfg).

Benchmarks

Currently the CPU time and the UART transmit time is reported to Host within the stats TLV. The explanation of these time intervals is shown in the timing diagram above.

Configuration (.cfg) File Format (CLI INTERFACE)

Attention
Converting configuration from older SDK release to current SDK release:
As new versions of SDK releases are available, there are usually changes to the configuration commands that are supported in the new release. Now, users may have some hand crafted config file which worked perfectly well on older SDK release version but will not work as is with the new SDK release. Check users guide for details.
Note
Example configuration files are available at '${SDK_INSTALL_PATH}/examples/mmw_demo/motion_detection/profiles/xWRL6432-evm'. All the CLI commands should be between 'sensorStop' and 'sensorStart'

Each line in the .cfg file describes a command with parameters. The various commands and their arguments are described in the table below (arguments are in sequence)

Sensor front-end parameters

Commands Parameters Notes
sensorStop FrameStopMode Indicates the frame stop mode. This command stops the sensor from transmitting further frames.
Important Note: This command is not supported when lowPowerCfg is 1
channelCfg RxChCtrlBitMask RX antennas 1 and 2, mask = 0x011b = 3
RX antennas 1 and 3, mask = 0x101b = 5
RX antennas 2 and 3, mask = 0x110b = 6
RX antennas 1, 2 & 3, mask = 0x111b = 7
TxChCtrlBitMask TX antennas 1 and 2, mask = 0x011b = 3
TX antenna 1, mask = 0x001b = 1
TX antenna 2, mask = 0x010b = 2
MiscCtrl Not supported on the current version of the SDK.
chirpComnCfg DigOutputSampRate Digital output Sampling rate for chirp ADC samples. Digital sampling rate is given by 100MHz/ DigOutputSampRate. The valid sampling rate can be configured as per below.
8 - 12.5 MHz
9 - 11.11 MHz
10 - 10 MHz
12 - 8.333 MHz
16 - 6.25 MHz
20 - 5 MHz
25 - 4 MHz
32 - 3.125 MHz
40 - 2.5 MHz
50 - 2 MHz
64 - 1.5625 MHz
80 - 1.25 MHz
100 - 1 MHz
DigOutputBitsSel Digital output sample bits select, this field governs which bits of the FECSS DFE's internal 16 bit signed data path are sent as output.
0 - Digital sample output is 12 MSB bits of DFE after rounding 4 LSBs
1 - Digital sample output is 12 bits after rounding 3 LSBs & clipping 1 MSB
2 - Digital sample output is 12 bits after rounding 2 LSBs & clipping 2 MSB
3 - Digital sample output is 12 bits after rounding 1 LSBs & clipping 3 MSB
4 - Digital sample output is 12 LSB bits after clipping 4 MSB
5 - Digital sample output is 16 bits
DfeFirSel The final stage FIR filter's characteristics can be selected as below.
0 - Long Filter (90% visibility): This provides visibility to a larger range of IF frequencies: 0 to 0.45 x Sampling Rate. Beyond that, the filter response starts drooping & enters filter transition band.
1 - Short Filter (80% visibility): This provides faster settled outputs but the IF frequency range visible is 0 to 0.40 x Sampling Rate. Beyond that, the filter response starts drooping & enters filter transition band.
NumOfAdcSamples No. of ADC samples. Current SDK work for values with powers of 2
Valid Range: 2 to 2048
ChirpTxMimoPatSel Only option 0 is not supported in current OOB Demo.
0 - TX BPM MIMO pattern disabled
1 - TDMA_2TX pattern
4 - BPM_2TX pattern
ChirpRampEndTime Chirp Profile Ramp end Time. This is a common ramp end time value for all chirps in a frame.
ChirpRxHpfSel Chirp Profile HPF corner frequency. This is a common HPF corner frequency value for all chirps in a frame.
0 - 175kHz HPF corner frequency
1 - 350kHz HPF corner frequency
2 - 700kHz HPF corner frequency
3 - 1400kHz HPF corner frequency
chirpTimingCfg ChirpIdleTime Chirp Profile Idle Time. This is a common idle time value for all chirps in a frame.
Unit: 1us.
ChirpAdcSkipSamples Chirp Profile ADC start skip samples. This is a common adc start time value for all chirps in a frame
Valid range: 0 to 63
ChirpTxStartTime Chirp Profile TX start Time. This is a common TX start time value for all chirps in a frame.This field indicates the TX start time in the chirp cycle with respect to the knee of the ramp.
Unit: In usec
ChirpRfFreqSlope Chirp Profile RF Frequency Slope. This is a common RF frequency slope value for all chirps in a frame.This field indicates the required FMCW slope of the chirp.
Unit: MHz/us
Valid range:- 399MHz/us to +399MHz/us.
ChirpRfFreqStart Chirp Profile RF start Frequency. This is a common RF start frequency value for all chirps in a frame. This field indicates the required start frequency of the chirp.
Unit: GHz
Valid range:58GHz to 62.5GHz for ES1.0 devices
frameCfg NumOfChirpsInBurst Number of Chirps in a Burst. This field indicates the number of chirps to be generated per burst.
Valid range: 1 to 65535 chirps .
(Limited support in current OOB)
NumOfChirpsAccum Number of accumulation per chirp. This field indicates the Number of chirps to be accumulated before sending the ADC data out in DFE, this can be used to increase the SNR without increasing the number of chirps to process in the DSP/HW accelerator.
Valid range: : 0 to 64 chirps.
(Limited support in current OOB)
BurstPeriodicity Burst periodicity in μs. This field indicates the period of the burst.
(Limited support in current OOB)
NumOfBurstsInFrame Number of bursts per frame.
Valid range:1 to 4096
(Limited support in current OOB)
FramePeriodicity Frame Periodicity. This field indicates the period of the frame, 32bit counter.This field indicates the frame periodicity, the time gap between successive frame starts.
Unit: ms
Valid range:100 to 4294967295 (Limited support in current OOB)
NumOfFrames Number of frames.
Valid range: 0 to 65535, 0 means infinite
adcLogging enable ADC data logging enable:
0 - Disable.
1: Enable via DCA.
2: Enable via SPI.
NOTE: When ADC logging via DCA is enabled number of adc samples must be a multiple of 4. And the configs listed below are not applicable when SPI logging is used.
sideBandEnable Sideband data logging:(optional argument)
0: Disable.
1: Enable.
NOTE: FrameLivMonEn in sensorstart must be set to a value 2(RX_SATURATION_LIVE_MON must be enabled) for sideband data logging. And by default sideband data is disabled.
(Refer to the ICD for more details about this feature)
swizzlingMode RDIF Data Swizzling Mode enable control:(optional argument)
0: Pin0-bit0-Cycle1 Mode.
1: Pin3-bit0-Cycle1 Mode.
2: Pin0-bit0-Cycle3 Mode.
3: Pin3-bit0-Cycle3 Mode.
(Refer to the ICD for more details about this feature)
scramblerMode RDIF Scrambler Mode enable control:(optional argument)
0: Disable.
1: Enable.
(Refer to the ICD for more details about this feature)
laneRate Enable RDIF lane rate update:(optional argument)
0: Combined Lane Rate of 400Mbps.
1: Combined Lane Rate of 320Mbps.
2: Combined Lane Rate of 200Mbps.
3: Combined Lane Rate of 160Mbps.
4: Combined Lane Rate of 100Mbps.
(Refer to the ICD for more details about this feature)
lowPowerCfg Enable/Diable Configuration to enable/disable the power management framework.
0 - Disabled
1 - Enabled
factoryCalibcfg Save enable When this option is enabled application will boot-up normally and configure the FECSS to perform all applicable factory calibrations during FECSS initialization. Once the calibrations are performed, application will retrieve the calibration data from FECSS and save it to FLASH. User need to specify valid <flash offset> value. <restore enable> option should be set to 0.
Note The factory calibration should be done at room temp (25 °C +/- 15 °C)
0 - Save Disabled
1 - Save Enabled
restore enable When Restore enabled option is set, application will check the FLASH for a valid calibration data section. If present, it will restore the data from FLASH and provide it to FECSS while configuring it to skip any real-time factory calibrations and use provided calibration data. User need to specify valid <flash offset> value which was used during saving of calibration data. <save enable> option should be set to 0. <rxGain> and <backoff0> arguments will be ignored when restore option is enabled.
0 - Restored Disabled
1 - Restore Enabled
rxGain Recommended value is 30db to 40db.
Units: db.
backoff0 TX channel power calibration. Valid Range: 0db to 26db.
Units: db.
flash offset Address offset in the flash to be used while saving or restoring calibration data. Make sure the address doesn't overlap the location in FLASH where application images are stored and has enough space for saving factory Calibration data. This field is don't care if both save and restore are disabled.Flash address range is 0x0 to 0x1FFFFF (16Mb) Actual Factory calibration data is of size 128 bytes. It is recommended to use last sector of flash memory starting with address 0x1FF000.
Note Note The flash offset should be greater than 1MB (0x100000h) for EVM. This check is only to make sure Appimage and ATE calibration data is not corrupted.
baudRate baudRateVal The sensor starts with 115200 baud rate by default. When this command is sent to the device, the baud rate for the UART communication is updated according to the given value. Currently only baudRateVal=1250000 is supported
sensorStart 'FrameTrigMode' Frame Trigger Mode.
0 - Frame SW immediate trigger Mode (SW_TRIG).
1 - Frame SW timer based trigger Mode (SW_TIMER_TRIG).
2 - Frame HW trigger low power Mode (HW_LOW_PWR_TRIG).
3 - Frame HW trigger low jitter Mode (HW_LOW_JIT_TRIG).
4 - CW CZ Trigger Mode (CW_CZ_TRIG).
5 - Chirp Timer Override Trigger Mode (CT_OVRD_TRIG).
(Currently SDK supports only SW_TRIG mode(0))
'ChirpStartSigLbE' Chirp Timer (CT) start signal loopback enable control.
0 - CHIRP_START_SIGNAL to DIG_SYNC_OUT Loopback Disable
1 - CHIRP_START_SIGNAL to DIG_SYNC_OUT Loopback Enable.
(Currently SDK supports only Loopback Disable mode(0))
'FrameLivMonEn' Frame Live monitors enable control.
0 - Live monitor Disabled
1 - Synth Frequency Monitor Enabled
2 - Rx Saturation Live Monitor Enabled
3 - Both Synth Frequency Monitor and Rx Saturation Live Monitor Enabled
'FrameTrigTimerVal' Frame Trigger Timer Value. 32bit counter value.
(Currently SDK demo is tested only with value 0)
sensorWarmRst Reserved for future This command initiates a warm reset of sensor with application getting reloaded from flash after reset.
Important Note: This command is not supported when lowPowerCfg is 1

Detection layer parameters

Commands Parameters Notes
sigProcChainCfg azimuthFftSize Azimuth FFT size. Suggested to set as power of 2
elevationFftSize Elevation FFT size. Suggested to set as power of 2
motDetMode Major / Minor / AUTO mode selection
1 - Major motion detection only
2 - Minor motion detection only
3 - Auto detection mode.
coherentDoppler Coherent/Non-coherent Doppler selection
0 - Non-coherent integration along Doppler dimension.
1 - Select maximum (coherent) peak in Doppler dimension.
2 - Non-coherent integration along Doppler used to create detection matrix, and find maximum position to add to detected point.
numFrmPerMinorMotProc Number of frames included for minor motion detection.
numMinorMotionChirpsPerFrame Number of chirps (bursts) per frame used for minor motion detection.
forceMinorMotionVelocityToZero Force Doppler value of detected points tp zero in minor motion detection
0 - Disabled
1 - Enabled
minorMotionVelocityInclusionThr Minor motion detected points with absolute velocity greater than this threshold are not included in the point cloud list. Threshold is specified in m/sec
cfarCfg averageMode CFAR Averaging mode selection Recommened to set 2
0 - CFAR-CA
1 - CFAR-CAGO
2 - CFAR-CASO
winLen One-sided noise averaging window length (in samples) of range-CFAR Recommened to set as power of 2
guardLen One-sided guard length (in samples) of range-CFAR.
noiseDiv Cumulative noise sum divisor expressed as a shift. Sum of noise samples is divided by 2^noiseDiv. Suggested to set as log2(winLen).
cyclicMode Cyclic mode or wrapped around mode.
0 - Disabled
1 - Enabled
thresholdScale Threshold factor of range-CFAR in dB scale (20log10).
peakGroupingEn Enable or disable Peakgrouping
0 - Disabled
1 - Enabled
sideLobeThreshold Sidelobe threshold (in linear scale) in azimuth domain to declare a local peak as a valid detection.
localMaxRangeDomain Enable/disable selection of the local maximum in the range domain
0 - Disabled
1 - Enabled
localMaxAzimuthDomain Enable/disable selection of the local maximum in the Angle domain
0 - Disabled
1 - Enabled
interpolateRange Enable /disable the interpolation of the range
0 - Disabled
1 - Enabled
interpolateAzimuthDomain Enable /disable the interpolation of the Azimuth
0 - Disabled
1 - Enabled
aoaFovCfg minAzimuthDeg Minimum azimuth angle (in degrees) that specifies the start of field of view
maxAzimuthDeg Maximum azimuth angle (in degrees) that specifies the end of field of view
minElevationDeg Minimum elevation angle (in degrees) that specifies the start of field of view
maxElevationDeg Maximum elevation angle (in degrees) that specifies the end of field of view
rangeSelCfg minMeters Minimum range of exported detected points
maxMeters Maximum range of exported detected points
clutterRemoval enabled Configure the static clutter removal
0 - Disabled
1 - Enabled
compRangeBiasAndRxChanPhase rangeBias Value of the Range Bias (m).
virtAntIdx 1 Phase compensation factor (real, imaginary) of virtual antenna 1.
virtAntIdx 2 Phase compensation factor (real, imaginary) of virtual antenna 2.
virtAntIdx 3 Phase compensation factor (real, imaginary) of virtual antenna 3.
virtAntIdx 4 Phase compensation factor (real, imaginary) of virtual antenna 4.
virtAntIdx 5 Phase compensation factor (real, imaginary) of virtual antenna 5.
virtAntIdx 6 Phase compensation factor (real, imaginary) of virtual antenna 6.
measureRangeBiasAndRxChanPhase enabled Enable measurement of the range bias and rx channel gain and phase imperfections
0 - Disabled
1 - Enabled
targetDistance Distance in meters where strong reflector is located to be used as test object for measurement. This field is only used when measurement mode is enabled.
searchWin Distance in meters of the search window around targetDistance where the peak will be searched
guiMonitor pointCloud Enable/Disable the transmission of the point cloud data
0 - Disable
1 - Enable, point cloud in floating point format, plus side information,
2 - Enable, point cloud in compressed format (fixed point)
rangeProfile Enable/Disable the transmission of the Range Profile data
0 - Disable
1 - Enable, range profile from Major mode detection
2 - Enable, range profile from Minor mode detection
3 - Enable, both range profiles
NoiseProfile Not used in the current SDK
rangeAzimuthHeatMap Enable/Disable transmission of the Range Azimuth heatmap
0 - Disable
1 - Enable, heatmap from Major mode detection
2 - Enable, heatmap from Minor mode detection
3 - Enable, both heatmaps
rangeDopplerHeatMap Not used in the current SDK
statsInfo Enable/Disable the transmission of the Statistics info that include processing time, temperature, power. (Partially supported in the current SDK)
0 - Disabled
1 - Enabled
presenceInfo Enable/Disable the transmission of the presence detection information
0 - Disabled
1 - Enabled
adcSamples Enable/Disable the transmission of the raw ADC samples of the last two chirps of the frame
0 - Disabled
1 - Enabled
trackerInfo Enable/Disable the transmission of the group tracker information
0 - Disabled
1 - Enabled
microDopplerInfo Enable/Disable the transmission of the micro-Doppler information
0 - Disabled
1 - Enabled
classifierInfo Enable/Disable the transmission of the classifier information
0 - Disabled
1 - Enabled
quickEvalInfo Enable/Disable the quick eval plots. The quick eval plots the presence info and is not useful without it being enabled
0 - Disabled
1 - Enabled
antGeometryCfg vAnt1_row row index of virtual antenna 1. (TxAnt1->RxAnt1)
vAnt1_col column index of virtual antenna 1. (TxAnt1->RxAnt1)
vAnt2_row row index of virtual antenna 2. (TxAnt1->RxAnt2)
vAnt2_col column index of virtual antenna 2. (TxAnt1->RxAnt2)
vAnt3_row row index of virtual antenna 3. (TxAnt1->RxAnt3)
vAnt3_col column index of virtual antenna 3. (TxAnt1->RxAnt3)
vAnt4_row row index of virtual antenna 4. (TxAnt2->RxAnt1)
vAnt4_col column index of virtual antenna 4. (TxAnt2->RxAnt1)
vAnt5_row row index of virtual antenna 5. (TxAnt2->RxAnt2)
vAnt5_col column index of virtual antenna 5. (TxAnt2->RxAnt2)
vAnt6_row row index of virtual antenna 6. (TxAnt2->RxAnt3)
vAnt6_col column index of virtual antenna 6. (TxAnt2->RxAnt3)
antDistX Antenna spacing in X dimension in mm. This is optional argument. If omitted, it is assumed that λ/dx=2
antDistZ Antenna spacing in Z dimension in mm. This is optional argument. If omitted, it is assumed that λ/dz=2

Motion/presence detection layer

Commands Parameters Notes
mpdBoundaryBox Zone Zone: This command is used to describe the boundary of each zone. (Upto twelve zones are permitted in current SDK)
x-min x-min
x-max x-max
y-min y-min
y-max y-max
z-min z-min
z-max z-max
sensorPosition xOffset Offset of the radar sensor position in x-axis referenced to the boundary box origin. (m)
yOffset Offset of the radar sensor position in y-axis referenced to the boundary box origin. (m)
zOffset Height of the radar sensor above the ground plane. (m)
azimTilt The azimuth tilt (in degrees)of the sensor about the axis Zw. A positive value indicates clockwise rotation when viewing towards the ground.
elevTilt The elevation tilt (in degrees)of the sensor about the axis Xw. A positive value indicates tilt towards the ground.
majorStateCfg pointThre1 Number of detected points (in a single frame) needed in a zone to enter the motion/presence state. If the number of points exceed this threshold, no need to check the SNR.
pointThre2 Number of detected points (in a single frame) needed in a zone to enter the motion/presence state. If the number of points exceeds this threshold, the snrThre2 criteria is checked.
snrThre2 Minimum total SNR (linear) of detected points (in a single frame) in a zone to enter the motion/presence state if the pointThre2 criteria is also satisfied.
pointHistThre1 Number of detected points (in a frame history buffer) needed in a zone to enter the motion/presence state. If the number of points exceed this threshold, no need to check the SNR.
pointHistThre2 Number of detected points (in a frame history buffer) needed in a zone to enter the motion/presence state. If the number of points exceeds this threshold, the snrHistThre2 criteria is checked.
snrHistThre2 Minimum total SNR (linear) of detected points (in a frame history buffer) in a zone to enter the motion/presence state if the pointHistThre2 criteria is also satisfied.
histBufferSize Size of the frame history buffer size (in frames) used in pointHistThre1, pointHistThre2, and snrHistThre2 parameters.
major2minorThre A motion status is preserved if it recorded at least one motion detection in the last major2minorThre frames.
minorStateCfg pointThre1 Number of detected points (in a single frame) needed in a zone to enter the motion/presence state. If the number of points exceed this threshold, no need to check the SNR.
pointThre2 Number of detected points (in a single frame) needed in a zone to enter the motion/presence state. If the number of points exceeds this threshold, the snrThre2 criteria is checked.
snrThre2 Minimum total SNR (linear) of detected points (in a single frame) in a zone to enter the motion/presence state if the pointThre2 criteria is also satisfied.
pointHistThre1 Number of detected points (in a frame history buffer) needed in a zone to enter the motion/presence state. If the number of points exceed this threshold, no need to check the SNR.
pointHistThre2 Number of detected points (in a frame history buffer) needed in a zone to enter the motion/presence state. If the number of points exceeds this threshold, the snrHistThre2 criteria is checked.
snrHistThre2 Minimum total SNR (linear) of detected points (in a frame history buffer) in a zone to enter the motion/presence state if the pointHistThre2 criteria is also satisfied.
histBufferSize Size of the frame history buffer size (in frames) used in pointHistThre1, pointHistThre2, and snrHistThre2 parameters.
minor2emptyThre A motion status is preserved if it recorded at least one motion detection in the last minor2emptyThre frames.
clusterCfg enabled Configure clustering logic.
0: Disable.
1: Enable.
maxDistance The radius (in meters) of the neighborhood around a point (i.e., epsilon in DBSCAN algorithm). Note that the distance measure only takes the geometric difference between the point and centroid into account.
x-max Minimum number of neighbor points required within the epsilon radius around point.

Tracking layer parameters

Commands Parameters Notes
boundaryBox x-min Minimum distance in x-dimension with respect to the origin in the World co-ordinates
x-max Maximum distance in x-dimension with respect to the origin in the World co-ordinates
y-min Minimum distance in y-dimension with respect to the origin in the World co-ordinates
y-max Maximum distance in y-dimension with respect to the origin in the World co-ordinates
z-min Minimum distance in z-dimension with respect to the origin in the World co-ordinates
z-max Maximum distance in z-dimension with respect to the origin in the World co-ordinates
Note that Z = 0 corresponds to the ground plane.
staticBoundaryBox x-min Minimum distance in x-dimension with respect to the origin in the World co-ordinates
x-max Maximum distance in x-dimension with respect to the origin in the World co-ordinates
y-min Minimum distance in y-dimension with respect to the origin in the World co-ordinates
y-max Maximum distance in y-dimension with respect to the origin in the World co-ordinates
z-min Minimum distance in z-dimension with respect to the origin in the World co-ordinates
z-max Maximum distance in z-dimension with respect to the origin in the World co-ordinates
Note that Z = 0 corresponds to the ground plane.
sensorPosition xOffset Offset of the radar sensor position in x-axis referenced to the boundary box origin. (m)
yOffset Offset of the radar sensor position in y-axis referenced to the boundary box origin. (m)
zOffset Height of the radar sensor above the ground plane. (m)
azimTilt The azimuth tilt (in degrees)of the sensor about the axis Zw. A positive value indicates clockwise rotation when viewing towards the ground.
elevTilt The elevation tilt (in degrees)of the sensor about the axis Xw. A positive value indicates tilt towards the ground.
presenceBoundaryBox x-min Minimum distance in x-dimension with respect to the origin in the World co-ordinates
x-max Maximum distance in x-dimension with respect to the origin in the World co-ordinates
y-min Minimum distance in y-dimension with respect to the origin in the World co-ordinates
y-max Maximum distance in y-dimension with respect to the origin in the World co-ordinates
z-min Minimum distance in z-dimension with respect to the origin in the World co-ordinates
z-max Maximum distance in z-dimension with respect to the origin in the World co-ordinates
Note that Z = 0 corresponds to the ground plane.
gatingParam Gain Gain of the gating function. It is set based on expected tracking errors and uncertainties of detection layer
Limit-Width Gating Limit in Width (m). It is set based on the physical dimensions and agility of the targets
Limit-Depth Gating Limit in Depth (m). It is set based on the physical dimensions and agility of the targets
Limit-Height Gating Limit in Height (m). It is set based on the physical dimensions and agility of the targets
Limit-Velocity Gating Limit in (radial) Velocity (m/s). It is set based on the motion of the targets
allocationParam snrThre Minimum total SNR for the allocation set
snrThreObscured Minimum total SNR for the allocation set when obscured by another target
velocityThre Minimum radial velocity of the allocation set centroid (m/s)
pointsThre Minimum number of points in the allocation set
maxDistanceThre Maximum squared distance between candidate centroid and centroid to be part of the allocation set (m^2)
maxVelThre Maximum velocity difference between candidate and centroid to be part of the allocation set (m/s)
stateParam det2actThre In DETECT state; threshold for the number of continuous HIT events to transition from DETECT to ACTIVE state (number of frames)
det2freeThre In DETECT state; threshold for the number of continuous MISS events to transition from DETECT to FREE state (number of frames)
active2freeThre In ACTIVE state and NORMAL condition; threshold for the number of consecutive MISS events needed to transition from ACTIVE to FREE state (number of frames)
static2freeThre In ACTIVE state and STATIC condition; threshold for the number of continuous MISS events for a STATIC target in a static zone to transition from ACTIVE to FREE state (number of frames)
exit2freeThre In ACTIVE state and EXIT condition; threshold for the number of continuous MISS events for a target outside the static zone to transition from ACTIVE to FREE state. Determines the Maximum lifespan for the target outside the static box (number of frames)
sleep2freeThre Determines the Maximum lifespan for the target inside the static box (number of frames)
maxAcceleration MaxAccel-X-direction Maximum amount that the target acceleration is expected to change in the X-direction between time-periods (m/s^2)
MaxAccel-Y-direction Maximum amount that the target acceleration is expected to change in the Y-direction between time-periods (m/s^2)
MaxAccel-Z-direction Maximum amount that the target acceleration is expected to change in the Z-direction in between time-periods (m/s^2)
trackingCfg enable Group tracker processing enable/disable flag:
0 - Disabled
1 - Enabled
IntialConfigParams An index to the default internal tracker parameter structure array that initializes the tracker configurations for different use-cases. These internal tracker parameters will be used by default if the user does not set these through the corresponding CLI command
maxNumPoints Maximum number of Detection points per frame
maxNumTracks Maximum number of Targets to track at any given time
maxRadialVelocity Maximum Radial velocity. If the maximum radial velocity reported from the sensor is 5 m/s then maxRadialVelocity needs to be set to 50 (10 x velocity in m/s)
radialVelocityResolution Radial velocity resolution in millimeter/sec that the configured chirp profile can provide (mm/sec)
deltaT Frame periodicity. This should match the sensor chirp configuration (msec)
boresightFilteringEnable Boresight filtering enable/disable flag:
0 - Disabled
1 - Enabled

Classification layer parameters

Commands Parameters Notes
microDopplerCfg enabled Micro-Doppler (µ-Doppler) and feature extraction processing enable/disable flag:
0 - Disabled
1 - Enabled
(For detailed information refer to Parameter Tuning and Customization Guide)
genApproach The angle spectrum generation approach (in the azimuth domain) when creating the µ-Doppler spectrum per track:
0 - FFT
1 - Beamforming
targetSize The target size (in xy-domain) to be used to when extracting the µ-Doppler around the corresponding centroid.
magnitudeSquared If this flag is enabled, the generated µ-Doppler spectrum will be magnitude squared:
0: Keep the magnitude spectrum as is.
1: Take the magnitude square (i.e., power spectrum).
circShiftCentroid If this flag is enabled, the generated µ-Doppler spectrum will be circularly shifted around the estimated target velocity provided by the tracker:
0: Keep the µ-Doppler spectrum as is.<br> 1: Circularly shift the µ-Doppler spectrum around the estimated target velocity from the tracker.
normalizedSpectrum If this flag is enabled, the generated µ-Doppler spectrum will be normalized between [0 1]:
0: Keep the µ-Doppler spectrum as is.
1: Normalize the µ-Doppler spectrum between [0 1].
interceptThrLowFreq The power ratio (%) used to compute the lower envelope (Dlow) feature from the µ-Doppler spectrum. This parameter is common for all the tracked objects.
interceptThrUpFreq The power ratio (%) used to compute the upper envelope (Dup) feature from the µ-Doppler spectrum. This parameter is common for all the tracked objects.
specShiftMode If this flag is enabled, the generated µ-Doppler spectrum will be circularly shifted around the mean Doppler:
0: Keep the µ-Doppler spectrum as is.
1: Circularly shift the µ-Doppler spectrum around the mean Doppler.
classifierCfg enabled Classifier processing enable/disable flag:
0: Disable.
1: Enable.
minNumPntsPerTrack Minimum number of points required for a track to run the classifier for it.
missTotFrmThre The maximum number of frames allowed which do not have enough number of points for a specific track.

Profile switching parameters

This configuration enables dynamic switching between high performance tracker configuration, processing and low power presence detection based on a state machine.

Commands Parameters Notes
profileSwitchCfg switchCfgEnable Profile switch enable:
0: Disable.
1: Enable.
Enabling low power mode in lowPowerCfg CLI is a prerequisite to enable this feature.
frmPretoTrack Threshold on number of frames for switching from presence to tracker state.
frmTracktoPre Threshold on number of frames for switching from tracker to presence state.

Refer ${SDK_INSTALL_PATH}/docs/MotionPresenceDetectionDemo_TuningGuide.pdf and ${SDK_INSTALL_PATH}/docs/MotionPresenceDetectionDemo_GroupTracker_TuningGuide.pdf document for Parameter tuning and customization of Demo application.

UART and Output to the Host

Output TLV Description

The packet structure consists of fixed sized frame header, followed by variable number of TLVs (see Figure below). Each TLV has fixed header followed by variable size payload. The Byte order is Little Endian.

Data packet structure sent to Host.

Frame Header Structure

The frame header is of fixed size (52bytes). It is defined by the structure as

typedef struct MmwDemo_output_message_header_t
{
uint16_t magicWord[4]; /* Sync word: {0x0102,0x0304,0x0506,0x0708} */
uint32_t version; /* MajorNum*2^24+MinorNum*2^16+BugfixNum*2^8+BuildNum */
uint32_t totalPacketLen; /* Total packet length including header in Bytes */
uint32_t platform; /* platform type */
uint32_t frameNumber; /* Frame number */
uint32_t timeCpuCycles; /* Time in CPU cycles when the message was created */
uint32_t numDetectedObj; /* Number of detected objects */
uint32_t numTLVs; /* Number of TLVs */
uint32_t subFrameNumber; /* Subframe number */
} MmwDemo_output_message_header;

TLV Structure

The TLV structure consists of a fixed header, TL (8bytes) followed by TLV specific payload. The TLV header structure is shown below.

typedef struct MmwDemo_output_message_tl_t
{
uint32_t type; /* TLV type */
uint32_t length; /* Length in bytes */
} MmwDemo_output_message_tl;

Point Cloud TLV

Motion detection demo outputs point cloud data in one of the two formats, floating point format and more compressed fixed point format. The format option is selected from the CLI configuration.

Floating point format

The point cloud data are sent using two TLV elements, first one with the detected point cartesian coordinates and the radial velocity, and the second one, this side information, the detected point snr and noise.

Point Cloud – Coordinates TLV
  • Type = MMWDEMO_OUTPUT_MSG_DETECTED_POINTS
  • Length = sizeof(DPIF_PointCloudCartesian) * numberOfPoints

The single point is defined as:

typedef struct DPIF_PointCloudCartesian_t
{
float x; /* x - coordinate in meters. */
float y; /* y - coordinate in meters. */
float z; /* z - coordinate in meters. */
float velocity; /* radial velocity away from sensor in m/s */
} DPIF_PointCloudCartesian;

Point Cloud - Side information TLV
  • Type = MMWDEMO_OUTPUT_MSG_DETECTED_POINTS_SIDE_INFO
  • Length = sizeof(DPIF_PointCloudSideInfo) * numberOfPoints

The single point side info is defined as:

typedef struct DPIF_PointCloudSideInfo_t
{
int16_t snr; /* snr - CFAR cell to side noise ratio in dB, 1LSB = 0.1dB */
int16_t noise; /* noise level of side of detected cell in dB, 1LSB = 0.1dB */
} DPIF_PointCloudSideInfo;

Fix-point format

  • Type = MMWDEMO_OUTPUT_EXT_MSG_DETECTED_POINTS
  • Length = sizeof (MmwDemo_output_message_point_uint) + sizeof (MmwDemo_output_message_UARTpoint) * numberOfPoints

The unit structure is defined as:

typedef struct MmwDemo_output_message_point_uint_t
{
float xyzUnit; /* x/y/z coordinates reporting unit, in m */
float dopplerUnit; /* radial velocity reporting unit, in m/s */
float snrUint; /* SNR reporting unit, in dB */
float noiseUint; /* Noise reporting unit, in dB */
uint16_t numDetectedPoints[2]; /* number of detected points in [0]-major and [1]-minor motion mode */
} MmwDemo_output_message_point_uint;

The single point is defined as:

typedef struct MmwDemo_output_message_UARTpoint_t
{
int16_t x; /* Detected point x, 1LSB = xyzUnit */
int16_t y; /* Detected point y, 1LSB = xyzUnit */
int16_t z; /* Detected point z, 1LSB = xyzUnit */
int16_t doppler; /* Detected point radial velocity, 1LSB = dopplerUnit */
uint8_t snr; /* Range detection SNR, 1LSB = snrUnit */
uint8_t noise; /* Detected point noise value 1LSB = noiseUnit */
} MmwDemo_output_message_UARTpoint;

Range Profile TLV

This TLV contains the range profile, specified as an array of 32-bit unsigned linear values of range bins. The length is equal to number of range bin elements, (half of the range FFT size, since the ADC samples are real).

  • Type = MMWDEMO_OUTPUT_EXT_MSG_RANGE_PROFILE_MAJOR, or MMWDEMO_OUTPUT_EXT_MSG_RANGE_PROFILE_MINOR
  • Length = sizeof(uint32_t) * numberOfRangeBins

Detection heatmap TLV

This TLV contains the range-azimuth detection matrix (heatmap) which consists of two dimensional array of 32-bit unsigned magnitude values. The matrix is arranged as X[rangeInd*azimuthFftSize + azimuthInd], rangeInd = 0, numRangeBins - 1, azimuthInd = 0, azimuthFftSize – 1

  • Type = MMWDEMO_OUTPUT_EXT_MSG_RANGE_AZIMUT_HEAT_MAP_MAJOR, or MMWDEMO_OUTPUT_EXT_MSG_RANGE_AZIMUT_HEAT_MAP_MINOR
  • Length = sizeof(uint32_t) * numberOfRangeBins * numAzimuthBins

Presence Detection TLV

This TLV contains the presence information for number of zones defined in the radar scene. The information for each zone is represented with 2 bits, packed in bytes starting from LSB position towards MSB.

  • 0 – no detection
  • 1 – minor motion detected
  • 2 – major motion detected
  • 3 – major and minor motion detected
  • Type = MMWDEMO_OUTPUT_EXT_MSG_ENHANCED_PRESENCE_INDICATION
  • Length = sizeof(uint8_t) * (1 + celing(NumberOfZones/4))

Stats TLV

This TLV contains statistics described in the structure below.

  • Type = MMWDEMO_OUTPUT_EXT_MSG_STATS
  • Length = sizeof(MmwDemo_output_message_stats)
typedef struct MmwDemo_output_message_stats_t
{
uint32_t interFrameProcessingTime; /* Interframe processing time in usec */
uint32_t transmitOutputTime; /* Transmission data transmit time in usec */
uint16_t powerMeasured[4]; /* Power at 1.8V, 3.3V, 1.2V and 1.2V RF rails(1LSB = 100 uW) */
int16_t tempReading[4]; /* Temperature: Rx, Tx, PM, DIG. (oC), 1LSB = 1oC */
} MmwDemo_output_message_stats;

Group tracker data TLVs

There are two TLV types associated with the tracking data:

  • TLV with the list of tracking objects of the current frame, and
  • TLV with the target index array, the array indicating which tracking ID is assigned to the point-cloud point of the current frame.

These two TLVs are sent together to the host when all of the following conditions are satisfied:

  • the group tracker is enabled in the CLI command trackingCfg,
  • the tracking data enable bit is enabled in the CLI command guiMonitor,
  • the number of tracking objects in the current frame is greater than zero.

List of tracking objects TLV

  • Type = MMWDEMO_OUTPUT_EXT_MSG_TARGET_LIST
  • Length = numTrackedObjects * sizeof(trackerProc_Target)
typedef struct trackerProc_Target_t
{
uint32_t tid;
float posX;
float posY;
float posZ;
float velX;
float velY;
float velZ;
float accX;
float accY;
float accZ;
float ec[16];
float g;
float confidenceLevel;

The target coordinates are “sensor” coordinates that could be converted to “world” coordinates on the Host side.

Group Tracker indices array TLV

  • Type = MMWDEMO_OUTPUT_EXT_MSG_TARGET_INDEX
  • Length = numberOfPoints * sizeof(uint8_t)

Micro-Doppler TLV

This TLV contains µ-Doppler spectra of the tracked objects. Note that this TLV is sent to host when all of the following conditions are satisfied:

  • the group tracker is enabled in the CLI command trackingCfg,
  • the µ-Doppler DPU is enabled in the CLI command microDopplerCfg,
  • the tracking data enable bit is enabled in the CLI command guiMonitor,
  • the µ-Doppler data enable bit is enabled in the CLI command guiMonitor,
  • the number of tracking objects in the current frame is greater than zero.
  • Type = MMWDEMO_OUTPUT_EXT_MSG_MICRO_DOPPLER_RAW_DATA
  • Length = numTrackedObjects * numDopplerBins * sizeof(float)

Value = Array of µ-Doppler spectra of the tracked targets, corresponding to target IDs sent in the tracker data TLV. The samples are stored in float format as dopplerData[targetIndex][DopplerIndex].

Features TLV

This TLV contains features extracted from the µ-Doppler FFT. It is sent out along with the µ-Doppler TLV.

  • Type = MMWDEMO_OUTPUT_EXT_MSG_MICRO_DOPPLER_FEATURES
  • Length = numTrackedObjects * numberOfFeatures * sizeof(float)

Value = array of features sets, corresponding to target IDs sent in the tracker data TLV. The features are stored in a floating point format as features[targetIndex][featureIndex]

Classifier Output TLV

This TLV is sent out when all of the following conditions are satisfied:

  • the group tracker is enabled in the CLI command trackingCfg,
  • the µ-Doppler DPU is enabled in the CLI command microDopplerCfg,
  • the classifier is enabled in the CLI command classifierCfg,
  • the classifier data enable bit is enabled in the CLI command guiMonitor,
  • the number of tracking objects in the current frame is greater than zero.
  • Type = MMWDEMO_OUTPUT_EXT_MSG_CLASSIFIER_INFO
  • Length = numTrackedObjects * CLASSIFIER_NUM_CLASSES * sizeof(uint8_t)

Value = array of classifier outcome in Q7 format, packed as classOutcome[targetIndex][classIndex]

Quick-Eval TLV

This TLV contains the presence info and is not useful without it being enabled.

  • Type = MMWDEMO_OUTPUT_EXT_MSG_QUICK_EVAL_INFO
  • Length = sizeof(uint8_t) + sizeof(sceneryParams)

Rx channel compensation measurement output TLV

This TLV contains the output of Rx channel compensation measurement procedure.

  • Type = MMWDEMO_OUTPUT_EXT_MSG_RX_CHAN_COMPENSATION_INFO
  • Length = sizeof(DPU_DoaProc_compRxChannelBiasFloatCfg)
typedef struct DPU_DoaProc_compRxChannelBiasFloatCfg_t
{
float rangeBias;
float rxChPhaseComp[2 * SYS_COMMON_NUM_TX_ANTENNAS * SYS_COMMON_NUM_RX_CHANNEL];

Low Power Configuration (lowPowerCfg = 1)

Flow Diagram

Below is the high level flow diagram of Motion and Presence detection OOB demo in Low Power Mode:

Flow in Low Power Mode

Threshold and Latency time duration for Power module

Syscfg of Power driver provides some options to be configured by user as per their demo implementations:

Threshold Value The idle time available only after which entry to various power modes is considered. This is upto the user to configure based on their system requirements.
Latency Value: There is a latency for the device to transition into the different low power modes, and to wake up from that specific low power mode to resume activity. The actual transition latency will depend upon overall device state, as well as execution of notification functions that are registered with the Power driver. User is expected to measure this in their implementations and configure this value. If there is Xms idle time, device will get into low power state for (X - Latency value) time duration.

Threshold and latency values can be changed (tuned) to meet specific application requirements. Threshold and Latency values for different power modes can be configured in Power Syscfg:

THRESHOLD AND LATENCY VALUES OF DIFFERENT POWER MODES



Enabling wake-up sources from LPDS state: Wake-up from Deep sleep exit is provisioned in the device through a number of external wakeup sources like UART/SPI/GPIO/SYNC_IN/Sleep counter, etc. By Default, wake-up using Sleep Counter is enabled in Demo.

LPDS WAKEUP SOURCES



Raw ADC data streaming

Steps for DCA based streaming

MMWAVE-L-SDK OOB (out-of-box) demo supports raw ADC data streaming through the RDIF interface. When the radar EVM board connected with the DCA1000EVM board, users can use the DCA1000EVM CLI application to capture the raw data without starting the mmWaveStudio GUI interface. The DCA1000EVM CLI application is primarily a command line tool for configuration of FPGA and recording based on the user inputs. The DCA1000EVM CLI application connects to DCA1000EVM system through 1GB Ethernet for configuration and recording of data. RADAR EVM is connected to DCA1000EVM for data capture and connected to PC for configuration of data generation. However, there are some important limitations associated with this feature:

  • Do not use this feature when Low power mode is enabled (lowPowerCfg 1).

The DCA1000EVM CLI application is provided for Windows and can be recompiled for other platforms. Users can find the source code and user guide in MMWAVE-STUDIO release package.

The DCA1000EVM CLI application has the following functionalities.

  • CLI application parses the parameters in JSON formatted config file for the corresponding CLI Control commands.
  • CLI application supports both Windows and Linux.
  • Acknowledgement of commands and error codes are handled and returned by the CLI application.
  • The response status of each of the command is captured in a log file by the CLI application.
  • CLI application supports running as a foreground as well as a background process.

DCA1000EVM Setup

  • DCA1000EVM should be connected to Host PC via Ethernet cable to access the CLI and Data Transfer process.
  • DCA1000EVM should be connected to TI Radar EVM via 60 pin HD Connector by using 60 pin Samtec ribbon cable.
  • DCA1000EVM power input should be connected either from DC Jack or TI Radar EVM power output (from 60 pin HD connector) by selecting the switch SW3.
  • Follow the mmWave Studio for additional RADAR EVM connectivity to PC and other pre-requisites.
  • Refer TI_DCA1000EVM_quickStartGuide.pdf document for more details.

Power on/off sequence

Initiate the power on sequence by turning on the radar EVM first, followed by the DCA1000EVM board. For shutdown, power off the DCA1000EVM board first, and then the radar EVM board.

Steps to Perform Raw ADC Data Streaming

For successful recording of data from RADAR EVM sequence is given as follows

  • Configure FPGA
    • Ensure JSON config file (CLI) and Script config file (RADAR EVM) data format mode are in sync
    • Run the command - DCA1000EVM_CLI_Control.exe fpga configFile.json (located in mmWaveStudio/PostProc)
    • The acknowledgement for the above command is shown below
  • Start the record
    • Ensure JSON config file (CLI) and Script config file (RADAR EVM) data logging mode are in sync
    • Run the command - DCA1000EVM_CLI_Control.exe start_record configFile.json (located in mmWaveStudio/PostProc)
    • The acknowledgement for the above command is shown below
  • Run the demo immediately after the above command by using the configuration with "adcLoggging 1" to enable this feature.
  • When data transfer starts DATA_TRANS_PRG LED (LD1) on DCA1000EVM will start toggling.
  • After the Raw ADC Data capture it will get stored in a adc_data_Raw_0.bin file in PostProc folder. And CLI_LogFile.txt contains all the commands execution information along with the timestamp. It can be viewed manually whenever required. The file will be appended for new sessions and new command execution information.
  • FPGA should be reconfigured in the following scenarios
    • When the system is booted or rebooted
    • When the FPGA or DCA1000EVM is reset

Refer TI_DCA1000EVM_CLI_Software_UserGuide.pdf document for more details.

Validation of the ADC data

The path ${SDK_INSTALL_PATH}/tools/ADC_parser includes parsing and post processing scripts for interpreting Raw ADC data acquired from the DCA1000EVM board.

  • The ar_convertAdcData_xWRLx432.m takes the Raw adc dump as input and converts it into adc matrix.
  • In addition, a post processing script Test_read_adc_data_xWRLx432.m, has been included to invoke the above parsing script, compute 1D and 2D FFTs.
  • The inputs to this script are adc_data_Raw_0.bin and cli_configuration.cfg. Update the paths accordingly in the above post processing script.
  • The FFT peaks are a means of validating the captured raw adc data. For example, a corner reflector is placed at 1m along the boresight of the radar. Assuming an FFT bin resolution of 0.1m/bin (derived based on chirping params), the 1D FFT peak falls at 10th bin.

Steps for SPI based streaming

The Motion and Presence Detect Demo supports streaming of raw ADC data over SPI interface every frame during the frame idle time. To enable this feature in demo, user has to ensure that demo is built with "SPI_ADC_DATA_STREAMING" compile time macro defined. To use this feature in demo have "adcLogging 2" in the configuration file. However, there are some important limitations associated with this feature:

  • User has to ensure that sufficient memory is available to store Raw ADC Data required per frame.
  • ADC data of every frame is transmitted during frame idle time. User has to ensure that sufficient frame idle time is available to transmit all the data.
  • Do not use this feature when Low power mode is enabled (lowPowerCfg 1).

This feature uses FTDI USB to SPI converter chips like FT232H, FT4232H etc. to transfer data from SPI interface of xWRL6432 to Host. If EVMs have these FTDI chips on them, user can use those, if not external converters have to be connected. Here the FTDI chip acts as SPI master and xWRL6432 acts as Slave device. SPI_busy signal is used as means of synchronization between FTDI chip and xWRL6432 device.

Steps to Perform Raw ADC Data Streaming on xWRL6432 FCCSP device:

C232HM-DDHSL-0 Cable SPI Wire Description
  • Connection Table of SPI Interface of xWRL6432 with C232HM-DDHSL-0 Cable
XWRLx4XX FCCSP Device C232HM-DDHSL-0 Cable
MOSI YELLOW WIRE
MISO GREEN WIRE
CHIP SELECT BROWN WIRE
SPI CLOCK ORANGE WIRE
SPI BUSY GREY WIRE
GROUND BLACK WIRE


  • Ensure that switch S1.6 is ON.
  • Run the demo and use configuration with "adcLoggging 2" to enable this feature.
  • Run the adcDataSPIFTDI.exe application located in tools/spi_adc_streaming folder after issuing the configuration (via Visualizer or serial term etc.) and before the sensor start command is sent to device.
  • Give all the inputs to adcDataSPIFTDI application like Device Type, Number of ADC samples, Number of chiprs in burst, Number of burst in frame, Number of Frames, Number of Rx Antennas as given in configuration file. Ensure that this is done before "sensorStart" comamnd is sent.
  • After the demo starts, Raw ADC Data for given number of frames will get stored in a adcData.txt file in spi_adc_streaming folder.

Steps to Perform Raw ADC Data Streaming on xWRL6432 AOP device:

  • There are two USB interfaces on xWRL6432 AOP device, one is XDS110 and other is for FTDI transmission. Connect both interfaces of xWRL6432 with Host.
  • Ensure that switch S1.6 is ON and S4.3 is OFF.
  • Run the demo and use configuration with "adcLoggging 2" to enable this feature.
  • Run the adcDataSPIFTDI.exe application located in tools/spi_adc_streaming folder after issuing the configuration (via Visualizer or serial term etc.) and before the sensor start command is sent to device.
  • Give all the inputs to adcDataSPIFTDI application like Device Type, Number of ADC samples, Number of chiprs in burst, Number of burst in frame, Number of Frames, Number of Rx Antennas as given in configuration file. Ensure that this is done before "sensorStart" comamnd is sent.
  • After the demo starts, Raw ADC Data for given number of frames will get stored in a adcData.txt file in spi_adc_streaming folder.

Validation of the ADC data

The path ${SDK_INSTALL_PATH}/tools/ADC_parser includes parsing and post processing scripts for interpreting Raw ADC data acquired through SPI.

  • The SPI based adc data is input as a .txt file along with the corresponding cli.cfg file.
  • The above file paths can be updated in the post processing script Test_read_adc_data_xWRLx432.m, to compute 1D and 2D FFTs.
  • The FFT peaks are a means of validating the captured raw adc data. For example, a corner reflector is placed at 1m along the boresight of the radar. Assuming an FFT bin resolution of 0.1m/bin (derived based on chirping params), the 1D FFT peak falls at 10th bin.

Running in test mode

For testing the signal processing chain, the source for the ADC samples can be configured to be the input file, instead of RF input stream, as shown in Figure below. This mode is enabled using a CLI command adcDataSource which specifies the input binary ADC data file. Note that this mode can run when the code is loaded through CCS. In this mode the RF part of the SOC is not configured.

Reading ADC data from file

In this mode demo is controlled form the ADC read data task mmwDemo_adcFileReadTask(), that reads data from the file, and triggers the input EDMA of the range DPU. This task also saves the point cloud and the range azimuth heat map to files.

The timing diagram is illustrated below.

Timing diagram in demo test mode - ADC samples read from file.

Steps to Run Monitors

Please refer to Monitors for steps to run monitors

Steps to Run the Example

Power Measurements with INA228

Following are power numbers with SDK default configurations measured using INA228 sensor.

Configuration Average Power (mW)
High Performance Motion Detection 32.2
Low Power Presence Detection 9.7
Object Tracking 81.6
DPU_DoaProc_compRxChannelBiasFloatCfg
Range Bias and rx channel gain/phase compensation configuration.
Definition: doaproc.h:474
trackerProc_Target
Structure holds the target features.
Definition: trackerproc.h:234