Ti Design Reference

TI Designs: TIDEP-01001
Vehicle Occupant Detection Reference Design
Description Features
This reference design demonstrates the use of the • Demonstration of mmWave sensor technology for
AWR1642, single-chip mmWave sensor with robust detection of life forms (adults, children, pets)
integrated DSP, as a Vehicle Occupant Detection in a vehicle.
Sensor enabling the detection of life forms in a vehicle. • Generate presence heat map with an FOV of ±60
This design provides a reference processing chain degrees.
which runs on the C674x DSP, enabling the • Source code for processing and detection based
generation of a heat map to detect life forms in a Field on the mmWave software development kit (SDK)
of View (FOV) of ±60 degrees.
• Based on proven EVM hardware designs, enabling
Resources quick time to market and out-of-the-box
demonstration.
TIDEP-01001 Design Folder • Radar front-end and detection configuration fully
AWR1642 Product Folder explained
AWR1642BOOST Tool Folder
mmWaveSDK Software Development Kit Applications
• Child left behind in car detection
• Vehicle occupant detection
ASK Our E2E™ Experts • Intruder detection
An IMPORTANT NOTICE at the end of this TI reference design addresses authorized use, intellectual property matters and other
important disclaimers and information.
TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 1

Submit Documentation Feedback
Copyright © 2018, Texas Instruments Incorporated
System Description www.ti.com
1 System Description
Today’s vehicles require robust and reliable information about the in-cabin occupancy. Smart airbag
deployment systems, air condition controls, detecting children and disabled people left behind in vehicles
relies upon this information.
The TIDEP-01001 provides a reference for creating a vehicle occupant detection application, using TI’s
AWR1642 based on 77-GHz mmWave radio-frequency complementary metal-oxide semiconductor (RF-
CMOS) technology.
TI’s mmWave sensing devices integrate a 76-GHz to 81-GHz mmWave radar front end with ARM®
microcontroller (MCU) and TI DSP cores for single-chip systems.
This reference design demonstrates the suitability of the AWR1642 for vehicle occupant detection
applications. This design targets the implementation of a wide, azimuth field of view (±60°), close range (3
m) sensor configuration, which can detect life forms across two regions of interest. This can be extended
to multiple regions detection.
This TI Design implements algorithms for generating an azimuth-range heat map, detection, and decision
for an AWR1642 device on a TI EVM module.
The design provides a list of required hardware, schematics, and foundational software to quickly begin
traffic monitoring product development. It describes the example usage case as well as the design
principle, implementation details, and engineering tradeoffs made in the development of this application.
High-level instructions for replicating the design are provided.
2 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

www.ti.com System Overview
2 System Overview
The VOD TI design is built around the AWR1642EVM evaluation board and the millimeter wave
(mmWave) SDK demo application. The system is optimized and built for VOD applications to detect
objects within a 3-m range
2.1 Block Diagram

The mmWave software development kit (SDK) enables the development of mmWave sensor applications
using the AWR1642 SOC and EVM. The SDK provides foundational components that let end users focus
on their applications. In addition, the SDK provides several demonstration applications, which serve as a
guide for integrating the SDK into end-user mmWave applications. This TI Design is a separate package
installed on top of the SDK package.
Figure 1. Software Block Diagram
2.2 Vehicle Occupancy Detection Software Block Diagram

As described in Figure 2, the implementation of the vehicle occupancy detection example in the signal-
processing chain consists of the following blocks, implemented as DSP code executing on the C674x core
in the AWR1642:
• Range processing
– For each antenna, 1D windowing, and 1D fast Fourier transform (FFT).
– Range processing is interleaved with the active chirp time of the frame.
• Clutter removal
– Estimate the DC component for each range bin, across chirps in a frame.
– Subtract the estimated DC component for each range bin.
• Range-Azimuth heatmap generation
– Perform Direction-of-Arrival (DOA) Spectral Estimation to calculate a 2D heatmap for the frame,
indexed by range (Nr, rows) and azimuth (Naz, columns).
• Feature Extraction
– Each frame, scan the heatmap within each defined zone of interest and compute a feature vector:
System Overview www.ti.com
• Average zone power

• Moving-average zone power (for L (window length), frames)
• Moving-average power ratio (for L frames)
• Correlation coefficient of zone power
• Zone Detection
– For Nz zones, there are 2Nz possible occupancy states. Offline, define a matrix of decision
parameters (coefficients) to represent targets of interest (adults, children, pets, etc).
– Perform matrix multiplication with the decision parameters and feature vector. This yields an array
of flags, one flag per zone, a 1 indicating ‘zone occupied’, and 0 indicating ‘empty’.
Figure 2. Application Software Block Diagram
After the DSP finishes frame processing, the results are formatted and written in shared memory
(HSRAM) for the R4F MCU to send to the host through a UART for visualization.
2.3 Highlighted Products
2.3.1 AWR1642 Single-Chip Radar Solution

The AWR1642 is an integrated single-chip FMCW sensor capable of operation in the 76-GHz to 81-GHz
band. It is built with TI’s low power 45-nm RFCMOS process, and enables unprecedented levels of
integration in an extremely small form factor. The AWR1642 is an ideal solution for low power, self-
monitored, ultra-accurate radar systems in the automotive and industrial space.
Figure 3. AWR1642BOOST EVM Block Diagram
The AWR1642 EVM has the following features:

• AWR1642 radar device
• Power management circuit to provide all the required supply rails from a single 5-V input.
• Two onboard TX antennas and four RX antennas
• Onboard XDS110, which provides JTAG interface, UART1 for loading the radar configuration on the

AWR1642 device, and UART2 to send the object data back to the PC.
For more details on the hardware, see the AWR1642 Evaluation Module (AWR1642EVM) Single-Chip
mmWave Sensing Solution. The schematics and design database can be found in the following
documents: the AWR1642 Evaluation Board Design Database and the AWR1642EVM Schematic,
Assembly, and BOM .
2.3.2 mmWaveSDK
The mmWave SDK is split in two broad components: the mmWave Suite and mmWave demos. The
mmWave Suite is the foundational software part of the mmWave SDK and includes smaller components:
• Drivers
• OSAL
• mmWaveLink (BSS interface API)
• mmWaveLib (C674 optimized library)
• mmWave API (High level control API)
• BSS firmware
• Board setup and flash utilities
The mmWave SDK demos provide a suite of demonstrations that depict the various control and data
processing aspects of an mmWave application. Data visualization of the demonstration's output on a PC is
provided as part of these demonstrations:
• mmWave processing demonstration
• ADC data streaming demonstration
2.4 System Design Theory
2.4.1 Use Case Geometry and Sensor Considerations

The AWR1642 is a radar-based sensor that integrates a fast FMCW radar front end with both an
integrated ARM R4F MCU and the TI C674x DSP for advanced signal processing.
The configuration of the AWR1642 radar front end depends on the configuration of the transmit signal and
the configuration and performance of the RF transceiver, the design of the antenna array, and the
available memory and processing power. This configuration influences key performance parameters of the
system.
When designing the frame and chirp configuration for a vehicle occupancy detection use case, start by
considering increasing range resolution and velocity resolution over maximum range and velocity; because
objects are within short range, defined zones will be relatively stationary

Figure 4. Example Zone Geometry
Figure 4 shows the zone geometry for the example configurations. In these examples, the primary field of
zone coverage begins at about 61 mm and continues to 136 mm. The zone widths are roughly 38 degrees
each. Tuning of the zones is completely configurable, as described in the user guide. There is a small
amount of spectral leakage from cell to cell, so an object entering a heatmap cell adjacent to a defined
zone cell could cause enough averaged energy in the zone to cause a transient positive detection.
2.4.2 Chirp Configuration used and System Performance

An example configuration for the VOD application is given in Table 1.
Table 1. Example Configuration

PARAMETER SPECIFICATION
Idle time (µs) 250
ADC start time (µs) 10
Ramp end time (µs) 40
Num ADC samples per chirp 64
Freq slope (MHz/µs) 98
Starting frequency (GHz) 77
ADC sampling freq (ksps) 2200
Num chirps per frame 512 (128 × 4)
MIMO (1 => Yes) 1
Chirp cycle time (µs) 340
Bandwidth (MHz) 3920
Frame periodicity (ms) 160
Memory requirements (KB) 512

The above configurations are just illustrative, and can be tailored according to user requirements
2.4.3 Configuration Profile

The demo applications in the mmWave SDK distribution let the user push the radar configuration using a
“Profile Configuration” file over UART to the AWR1642 EVM. The mmWave SDK user guide (included in
the mmWave SDK distribution) describes the semantics of the following commands in detail. In the
configuration files for the vehicle occupancy demo, additional commands are created that allow
configurability of the specialized algorithms. These commands are described in the demo’s user guide.
Figure 5. VOD Profile Configuration File
The profile configuration (profileCfg), defines the profile of a single chirp (as seen in Figure 5).
Subsequently, four chirp configurations are defined; each one inheriting the same profile but associated
with TX1 and TX2 alternately. Finally, a frame config message constructs a frame with transmissions
alternating between TX1 and TX2.
2.4.4 Processing Chain

An example processing chain for vehicle occupancy detection using a short range chirp and frame design
is implemented on the AWR1642 EVM.
The main processing elements involved in the processing chain consist of the following:
• Front end – Represents the antennas and the analog RF transceiver implementing the FMCW
transmitter and receiver and various hardware-based signal conditioning operations. This must be
properly configured for the chirp and frame settings of the usage case.
• ADC – The ADC is the main element that interfaces to the DSP chain. The ADC output samples are
buffered in ADC output buffers for access by the digital part of the processing chain.
• EDMA controller – This is a user-programmed DMA engine employed to move data from one memory
location to another without using another processor. The EDMA can be programed to trigger
automatically, and can also be configured to reorder some of the data during the movement

operations.
• C674 DSP – This is the digital signal processing core that implements the configuration of the front end
and executes the main signal processing operations on the data. This core has access to several
memory resources, as noted further in the design description.
• ARM R4F – This ARM MCU can execute application code, including further signal processing
operations and other higher level functions. In this application, the ARM R4F primarily relays
visualization data to the UART interface. There is a shared memory visible to both the DSP and the
R4F.
The processing chain is implemented on the DSP. There are several physical memory resources used in
the processing chain, which are described in Table 2.
Table 2. Memory Resources

Section Name Size (KB) as Memory Used Description
Configured (KB)
L1D SRAM 16 16 Layer one data static RAM is the fastest data access for
DSP and is used for most time-critical DSP processing
data that can fit in this section.
L1D cache 16 Used as cache Layer one data cache caches data accesses to any other
section configured as cacheable. The LL2, L3, and
HSRAM are configured as cacheable.
L1P SRAM 16 4 Layer one program static RAM is the fastest program
access RAM for DSP and is used for most time-critical
DSP program that can fit in this section.
L1P cache 16 Used as cache Layer one cache caches program accesses to any other
section configured as cacheable. The LL2, L3, and
HSRAM are configured as cacheable.
LL2 256 240 Local layer two memory is lower latency than layer three
for accessing and is visible only from the DSP. This
memory is used for most of the program and data for the
signal processing chain.
L3 640 595 Higher latency memory for DSP accesses primarily stores
the radar cube and the range-Doppler power map. It is a
less time sensitive program. Data can also be stored here.
HSRAM 32 32 Shared memory buffer between the DSP and theR4F
relays visualization data to the R4F for output over the
UART in this design.
Figure 6. Processing Chain Flow
As shown in Figure 6, the implementation of the vehicle occupancy detection example in the signal-
processing chain consists of the following blocks, implemented as DSP code executing on the C674x core
in the AWR1642:
• Range processing — For each antenna, EDMA is used to move samples from the ADC output buffer to

DSP’s local memory. A 16-bit, fixed-point 1D windowing and 16-bit, fixed-point 1D FFT are performed.
EDMA is used to move output from DSP local memory to radar cube storage in layer three (L3)
memory. Range processing is interleaved with active chirp time of the frame. All other processing
happens each frame, except where noted, during the idle time between the active chirp time and the
end of the frame.
• Clutter removal — In clutter-rich environments, especially indoor, detecting objects with small RCS
(radar cross section), such as pedestrian and life-form objects, is a challenge. Some clutters with large
RCS, such as building structure and furniture, can dominate the received signal. As a result, objects
with small RCS can be buried under the strong interference from the clutters and become difficult to
detect. When the radar sensor is stationary, clutters and all stationary objects have zero Doppler,
which is exploited to improve the signal condition for the remaining radar signal processing chain.
• Range-Azimuth heatmap generation — The Range-Azimuth heatmap is generated using high
resolution direction of arrival (DoA) spectral estimation, based on spatial covariance. This is done each
frame using the clutter removed, 1D FFT outputs. To avoid numeric instability issues, a small value is
added along the diagonal of the covariance estimate matrix.
• Feature extraction — Using the frame’s Range-Azimuth heatmap (and several previous frame’s
heatmaps), several features are calculated using zone definitions pre-computed and loaded during
configuration. The features are computed using only the heatmap cells within the defined zones. These
features are average power, average power for the past N frames, power ratios, and the correlation
coefficient.
• Zone detection — For Nz zones, there 2Nz are possible occupancy states for the area of interest. Matrix
multiplications are performed with the feature vectors and offline-generated training coefficients. The
result of these multiplications is an array of decisions, 1 (occupied) or 0 (empty) for each zone,
representing the possible occupancy states.
After DSP finishes frame processing, the results are formatted and written in shared memory for the
MSS R4F to send to host using UART for visualization. The PC GUI executable then decodes each
frame’s data and updates the heatmap and zone detections accordingly.
2.4.5 Heatmap Generation Algorithms

This section explains a functional block for high-resolution DoA spectral estimation based on spatial
covariance. The spatial covariance is estimated within a radar frame. Although an MVDR (minimum
variance distortion less response) based DoA estimation approach is presented, other covariance-based
high-resolution DoA methods can be used as well using the same radar processing signal chain.
Notation:
X n,k,p : the output of range processing and clutter removal.
n,k, and p are the range bin index, the chirp index, and the virtual receive antenna index, respectively.
The following describes a DoA spectral estimation:
For the n-th range bin:
1. Spatial covariance is estimated as follows:
where
• xn,k is called a dimensional spatial vector for n-th range bin and the k-th chirp, which is formed from the data
cube by stacking samples across the virtual antennas (1)
For example:
(2)
To reduce the amount of computation, a smaller number of chirps less than Nc may be used in estimating
the spatial covariance.
DoA spectral estimation is performed as follows: An MVDR (also known as Capons’ beamforming) based
approach is shown here. First, denote α(θ) a steering vector for an azimuth angle θ as follows: for a linear
one-dimensional virtual receiver antenna array,

where
• d is the inter-antenna spacing normalized by the wavelength. (3)
The steering vector represents phase difference on each of virtual receive antennas when the incident
radar radio-frequency (RF) signal comes from azimuth angle θ. The angular spectrum for the n-th range
bin is given by:
(4)
And the corresponding beamforming vector is given as:
(5)
The DoA spectrum for each range bin is stacked into a matrix form, where the n-th row is populated with
the DoA spectrum of the n-th range bin. This matrix is called range-azimuth spectrum matrix S (see
Figure 1), whose (n, m) element is given by:
where
• the azimuth angle θ m for an azimuth angle index m (6)
2.4.6 Diagonally-Loading Method

In some situations, the covariance estimate is singular or near-singular, which may cause numeric stability
issues in doing the matrix inversion as a part of the DoA spectral estimation. One way to avoid the
numeric stability issues is to add a small value along the diagonal of the covariance estimate matrix:
(7)
The diagonally loading factor α n may be determined using the noise variance estimate as follows:
(8)
for a constant β , where P n = 1/Nα trace{Rn}) is the average of the diagonal terms of the covariance
estimate matrix.
2.4.7 Feature Extraction Algorithms

Notations:
• Nz is the number of zones.
• rn (for n = 1,2, ... , Nr ) is the range value for the range bin index n, and θ m (for m = 1, 2, ... , Naz ) is the
azimuth angle for the azimuth angle index m, where Nr is the number of range bins and Naz is the
number of azimuth angle bins.
• S[t] is the Nr x Naz range-azimuth spectrum matrix at radar frame t, whose (n,m)-th element is denoted
as Sn,m [t].
2.4.8 Definition of Zones

Zones may be defined in range and azimuth-angle domain, and depend on the mounting location and
attitude of the radar sensor. For example, in-cabin applications for automotive vehicles, each
driver/passenger seats can be defines as zones. A zone can be defined as follows with four parameters.
(9)

Z i is the set of all the range-azimuth angle grids within the i-th zone (a rectangular-shaped boundary in
range-azimuth domain) which is defined by four parameters, ri L, ri U, θi L, and θi U.
2.4.9 Features
For each zone, several features used in determining the occupancy state are extracted. The features may
be derived from the average power for each zone (referred to as ‘zone power’). For zone i at a radar
frame index t, the average zone-power is defined as follows:
(10)
Features are defined as follows:
Moving-averaged zone power: for zone i at frame t,
where
• L is the window length for the moving-average. (11)
•
• Moving-averaged power ratio: for zone i at frame t,
(12)
• Correlation coefficient of zone power: between zone i and zone j,
where
• σi[t] is the standard deviation of Qi[t]for zone i, which is defined as follows:
(14) (14)
The feature set for a radar frame is formed by stacking all the features. For example, when N Z = 3, the
feature set vector is 9-dimensional vector x[t] as follows:
(15)
In the following sections, the element of the feature vector is sometimes also denoted as x[t] = [x1[t],
x2[t], ... , xN[t]]T , where is the number of features.
2.4.10 Zone Detection Algorithms

For NZ zones, there are 2 Nz possible occupancy states for the area of interest. The binary occupancy
state for zone i is denoted by Oi[t] E {0,1}. Oi[t] = 0andOi[t] = 1 represents that the zone i at radar frame t
is ‘empty’ and ‘occupied’, respectively. For example, when NZ the occupancy status for the all the zones
are:
(16)
For each of possible occupancy decision states, we define (N+1) dimensional decision weight vector (also
called decision parameters):

where
• N is the number of element in feature vector x[t], w 0is for bias term. (17)
The probability (or likelihood) of having a particular occupancy state is defined as follows:
where
• x~[t] = [1; x[t]] = [x0[t], x1[t], ... , xN[t]]T (obtained by pre-appending ‘1’ to the feature vector x[t]. Note that x0[t] =
1 always), and g(.) is a non-linear function, e.g., logistic function,
(19) (19)
Zone occupancy state is estimated as follows:
(20)
Because g(.) is an increasing function, the occupancy decision making is equivalent to:
(21)
Furthermore, the zone detection can be implemented with a matrix-vector multiplication as shown in
Figure 3, by stacking w(o1, o2, ... , oNz) into a 2Nz x (1 + N)matrix W as follows:
(22)
Then the zone-based decision may be made as follows:
where
• the non-linear function g(.) is element-wise, and arg max(.) gives the index of element that gives the
maximum in a vector, and de2bi[.] is a converter from a decimal value to a binary vector. (23)
For example, when Nz = 3, de2bi[.] functions as shown in the following table:
index (O~ 1[t],O~ 2[t], O~ 3[t]) = de2bi[index]

0 (0, 0, 0)
1 (1, 0, 0)
2 (0, 1, 0)
3 (1, 1, 0)
4 (0, 0, 1)
5 (1, 0, 1)
6 (0, 1, 1)
7 (1, 1, 1)

2.4.11 Output through UART
Figure 7. AWR1642BOOST UART Communication
As illustrated in Figure 7, the example processing chain uses one UART port to receive input configuration
to the front end and signal processing chain, and uses the second UART port to send out processing
results for display. See the information included in the user guide for detailed information on the format of
the input configuration and output results.

Hardware, Software, Testing Requirements, and Test Results www.ti.com
3 Hardware, Software, Testing Requirements, and Test Results
3.1 Required Hardware and Software

The AWR1642EVM from Texas Instruments is an easy-to-use evaluation board for mmWave sensing
devices. The VOD radar application runs on the AWR1642 EVM and connects to a visualization tool
running on a PC connected to the EVM over USB.
For details regarding usage of this board, see the AWR1642 Evaluation Module (AWR1642EVM) Single-
Chip mmWave Sensing Solution.
For details regarding the VOD GUI visualization tool, see the user guide for this demo.
3.1.1 Hardware
The AWR1642 core design includes:
• AWR1642 device: A single-chip, 77-GHz radar device with an integrated DSP
• Power management network using a low-dropout linear regulator (LDO) and power management
integrated circuit (PMIC) DC/DC supply (TPS7A88, TPS7A8101-Q1, and LP87524B-Q1)
The EVM also hosts a device to assist with onboard emulation and UART emulation over a USB link with
the PC.

www.ti.com Hardware, Software, Testing Requirements, and Test Results
Figure 8. AWR1642BOOST EVM
3.1.2 Software and GUI

• The mmWave SDK can be downloaded from here. The installation program will also install all required
tool components.
• To download the vehicle occupant detection application software, use the following TI Resource
Explorer (TI Rex) here.
• Details on how to run the pre-built binaries and how to rebuild the demonstration application are
provided in the VOD user guide in TI-Rex.

3.2 Testing and Results
3.2.1 Test Setup

Two test scenarios were used to test the VOD application software: a lab setup and a vehicle setup. The
lab setup attempted to replicate the seating area of a vehicle, but without the confinement of door and roof
panels. The vehicle setup created a zone in each of the back seats of a common vehicle. When the test
setup is replicated, the demo application can be run as described in the user guide, using the appropriate
configuration file.

3.2.2 Test Results

To create a testing criteria, the VOD demo GUI was instrumented with a counting widget that when
started, counts frames received from the AWR1642, and counts positive (occupied) detections in each
zone per frame. No averaging or smoothing is performed; it is a simple frame count. For each scenario, all
possible occupied and empty zone combinations were tested. Each test was allowed to run for at least
1000 frames (approximately 2.75 minutes at 6 frames/second), and the resulting counts are recorded in
the following tables. These tests require that the test subjects are in place when the frame counting
begins, and nothing enters an “empty” zone during the testing period.
Table 3. Scenario Config file: od_demo_carseats_0302_3p0.cfg

Test Total Frames Zone1 Count Zone1Error (%) Zone2 Count Zone2 Error (%)
Zone1: 1004 0 0 0 0
emptyZone2: empty
Zone1: 1018 1018 0 0 0
occupiedZone2:
empty
Zone1: 1034 2 0.19 1034 0
emptyZone2:
occupied
Zone1: 1025 1025 0 1011 1.3
occupiedZone2:
occupied
Table 4. Scenario Config file: od_demo_ car_0318_1p0.cfg

Zone1: 1011 0 0 0 0
emptyZone2: empty

Table 4. Scenario Config file: od_demo_ car_0318_1p0.cfg (continued)

Zone1: 1008 1008 0 0 0
occupiedZone2:
empty
Zone1: 1007 0 0 1007 0
emptyZone2:
occupied
Zone1: 1012 1012 0 1012 0
occupiedZone2:
occupied
Table 5. Scenario Config file: od_demo_ car_0318_3p0.cfg

Zone1: 1004 0 0 0 0
emptyZone2: empty
Zone1: 1012 1012 0 0 0
occupiedZone2:
empty
Zone1: 1006 0 0 1006 0
emptyZone2:
occupied
Zone1: 1008 1008 0 1002 0.6
occupiedZone2:
occupied
Other tests were also performed with the AWR1642 sensor mounted in the vehicle. The first test was a
child seated in a carseat in one of the zones. Figure 13 shows the child in the carseat, and a capture from
the VOD demo GUI during testing.
Figure 13. Child in a Car Seat

Another test illustrates an intruder approaching the vehicle. Figure 14 shows the intruder and the
corresponding heatmap image. A positive (occupied) detection was not gathered, because the intruder
was still outside the defined zones.
Figure 14. Intruder Approaching Vehicle

Design Files www.ti.com
4 Design Files
To download the software files, see the design files at TIDEP-1001.
4.1 Schematics
To download the schematics, see the design files at TIDEP-01001 .
4.2 Bill of Materials

To download the bill of materials (BOM), see the design files at TIDEP-01001 .
4.3 PCB Layout Recommendations
4.3.1 Layout Prints

To download the layer plots, see the design files at TIDEP-01001 .
4.4 Altium Project

To download the Altium Designer® project files, see the design files at TIDEP-01001 .
4.5 Gerber Files

To download the Gerber files, see the design files at TIDEP-01001 .
4.6 Assembly Drawings

To download the assembly drawings, see the design files at TIDEP-01001
5 Software Files
To download the software files, see the design files at TIDEP-01001 .
6 Related Documentation
• Texas Instruments, AWR1642 Evaluation Module (AWR1642EVM) Single-Chip mmWave Sensing
Solution
• Texas Instruments, Programming Chirp Parameters in TI Radar Devices
• Texas Instruments, AWR1642 Single-Chip 77- and 79-GHz FMCW Radar Sensor
• Texas Instruments, AWR14xx/16xx Technical Reference Manual
• Texas Instruments, AWR1642 Evaluation Board Design Database
• Texas Instruments, AWR1642BOOST Schematic, Assembly, and BOM
• Texas Instruments, mmWave SDK User's Guide
• Texas Instruments, AWR1642 mmWave sensor: 76–81-GHz radar-on-chip for short-range radar
applications
6.1 Trademarks
E2E is a trademark of Texas Instruments.
ARM is a registered trademark of ARM Ltd..
Altium Designer is a registered trademark of Altium LLC or its affiliated companies.
All other trademarks are the property of their respective owners.

IMPORTANT NOTICE FOR TI DESIGN INFORMATION AND RESOURCES
Texas Instruments Incorporated (‘TI”) technical, application or other design advice, services or information, including, but not limited to,
reference designs and materials relating to evaluation modules, (collectively, “TI Resources”) are intended to assist designers who are
developing applications that incorporate TI products; by downloading, accessing or using any particular TI Resource in any way, you
(individually or, if you are acting on behalf of a company, your company) agree to use it solely for this purpose and subject to the terms of
this Notice.
TI’s provision of TI Resources does not expand or otherwise alter TI’s applicable published warranties or warranty disclaimers for TI
products, and no additional obligations or liabilities arise from TI providing such TI Resources. TI reserves the right to make corrections,
enhancements, improvements and other changes to its TI Resources.
You understand and agree that you remain responsible for using your independent analysis, evaluation and judgment in designing your
applications and that you have full and exclusive responsibility to assure the safety of your applications and compliance of your applications
(and of all TI products used in or for your applications) with all applicable regulations, laws and other applicable requirements. You
represent that, with respect to your applications, you have all the necessary expertise to create and implement safeguards that (1)
anticipate dangerous consequences of failures, (2) monitor failures and their consequences, and (3) lessen the likelihood of failures that
might cause harm and take appropriate actions. You agree that prior to using or distributing any applications that include TI products, you
will thoroughly test such applications and the functionality of such TI products as used in such applications. TI has not conducted any
testing other than that specifically described in the published documentation for a particular TI Resource.
You are authorized to use, copy and modify any individual TI Resource only in connection with the development of applications that include
the TI product(s) identified in such TI Resource. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE TO
ANY OTHER TI INTELLECTUAL PROPERTY RIGHT, AND NO LICENSE TO ANY TECHNOLOGY OR INTELLECTUAL PROPERTY
RIGHT OF TI OR ANY THIRD PARTY IS GRANTED HEREIN, including but not limited to any patent right, copyright, mask work right, or
other intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information
regarding or referencing third-party products or services does not constitute a license to use such products or services, or a warranty or
endorsement thereof. Use of TI Resources may require a license from a third party under the patents or other intellectual property of the
third party, or a license from TI under the patents or other intellectual property of TI.
TI RESOURCES ARE PROVIDED “AS IS” AND WITH ALL FAULTS. TI DISCLAIMS ALL OTHER WARRANTIES OR
REPRESENTATIONS, EXPRESS OR IMPLIED, REGARDING TI RESOURCES OR USE THEREOF, INCLUDING BUT NOT LIMITED TO
ACCURACY OR COMPLETENESS, TITLE, ANY EPIDEMIC FAILURE WARRANTY AND ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL
PROPERTY RIGHTS.
TI SHALL NOT BE LIABLE FOR AND SHALL NOT DEFEND OR INDEMNIFY YOU AGAINST ANY CLAIM, INCLUDING BUT NOT
LIMITED TO ANY INFRINGEMENT CLAIM THAT RELATES TO OR IS BASED ON ANY COMBINATION OF PRODUCTS EVEN IF
DESCRIBED IN TI RESOURCES OR OTHERWISE. IN NO EVENT SHALL TI BE LIABLE FOR ANY ACTUAL, DIRECT, SPECIAL,
COLLATERAL, INDIRECT, PUNITIVE, INCIDENTAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES IN CONNECTION WITH OR
ARISING OUT OF TI RESOURCES OR USE THEREOF, AND REGARDLESS OF WHETHER TI HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
You agree to fully indemnify TI and its representatives against any damages, costs, losses, and/or liabilities arising out of your non-
compliance with the terms and provisions of this Notice.
This Notice applies to TI Resources. Additional terms apply to the use and purchase of certain types of materials, TI products and services.
These include; without limitation, TI’s standard terms for semiconductor products http://www.ti.com/sc/docs/stdterms.htm), evaluation
modules, and samples (http://www.ti.com/sc/docs/sampterms.htm).
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265

Ti Design Reference

Uploaded by

Copyright:

Available Formats

Ti Design Reference

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ti Design Reference

Uploaded by

Copyright:

Available Formats

TI Designs: TIDEP-01001

Vehicle Occupant Detection Reference Design

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 1

2 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

2.1 Block Diagram

Figure 1. Software Block Diagram

2.2 Vehicle Occupancy Detection Software Block Diagram

• Average zone power

Figure 2. Application Software Block Diagram

2.3 Highlighted Products

2.3.1 AWR1642 Single-Chip Radar Solution

Figure 3. AWR1642BOOST EVM Block Diagram

The AWR1642 EVM has the following features:

4 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

2.4 System Design Theory

2.4.1 Use Case Geometry and Sensor Considerations

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 5

Figure 4. Example Zone Geometry

2.4.2 Chirp Configuration used and System Performance

Table 1. Example Configuration

6 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

2.4.3 Configuration Profile

Figure 5. VOD Profile Configuration File

2.4.4 Processing Chain

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 7

Table 2. Memory Resources

Figure 6. Processing Chain Flow

8 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

2.4.5 Heatmap Generation Algorithms

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 9

2.4.6 Diagonally-Loading Method

2.4.7 Feature Extraction Algorithms

2.4.8 Definition of Zones

10 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

2.4.10 Zone Detection Algorithms

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 11

index (O~ 1[t],O~ 2[t], O~ 3[t]) = de2bi[index]

12 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

2.4.11 Output through UART

Figure 7. AWR1642BOOST UART Communication

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 13

3 Hardware, Software, Testing Requirements, and Test Results

3.1 Required Hardware and Software

14 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

Figure 8. AWR1642BOOST EVM

3.1.2 Software and GUI

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 15

3.2 Testing and Results

3.2.1 Test Setup

16 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

3.2.2 Test Results

Table 3. Scenario Config file: od_demo_carseats_0302_3p0.cfg

Table 4. Scenario Config file: od_demo_ car_0318_1p0.cfg

TIDUE95 – April 2018 Vehicle Occupant Detection Reference Design 17

Table 4. Scenario Config file: od_demo_ car_0318_1p0.cfg (continued)

Table 5. Scenario Config file: od_demo_ car_0318_3p0.cfg

Figure 13. Child in a Car Seat

18 Vehicle Occupant Detection Reference Design TIDUE95 – April 2018

Figure 14. Intruder Approaching Vehicle