Sparse#

The sparse service is ideal for motion-sensing applications requiring high robustness and low power consumption.

examples/a111/services/sparse.py contains example code on how the Sparse service can be used.

How it works#

The other services, Envelope, IQ, and Power Bins, are all based on sampling the incoming waves several times per wavelength (effectively ~2.5 mm). In sparse, the incoming waves are instead sampled every ~6 cm. Therefore, sparse is fundamentally different from the other services. It does not simply produce a downsampled version of the Envelope or IQ service.

Due to the highly undersampled signal from the sparse service, it should not be used to measure the reflections of static objects. Instead, the sparse service should be used for situations where detecting moving objects is desired. Sparse is optimal for this, as it produces sequences of very robust measurements at the sparsely located sampling points.

../../../_images/over_time.png — Figure 26 An illustration of how the sparse service samples reflected waves from a moving object.#

The above image illustrates how a single sparse point samples incoming wavelets from a moving target. The three different blue colored waves are from different points in time, where the darkest one is the most recent (present), and the faded ones are from the past. For every point in time, a sample is taken at the sampling point(s). In this example, there is only one single sample point, but in reality, most often several points are used.

The bottom plot lays out the sampled points over a time scale. In this simple example, the object moves with a steady velocity. As such, over time, the samples will reconstruct the incoming wavelet, which the orange line illustrates.

Note

If the target object is static, the signal too will be static, but not necessarily zero. It can take any value within the peak values of the reflected wave, depending on where on the wave it is sampled.

../../../_images/sweeps_and_frames.png — Figure 27 An illustration of the sparse data frames consisting of a number of sweeps.#

From sparse, every received data frame consists of a number of sweeps \(N_s\) which are sampled after each other. Every sweep consists of one or several (sparse) sampling points in distance as configured. Depending on the configuration, the time between sweeps \(T_s\) may vary. It can also, within certain limits, be set to a fixed value. Often, we refer to this as the sweep rate \(f_s=1/T_s\) instead of referring to the time between sweeps \(T_s\).

Typical sweep rates range between 1 and 50 kHz. On the other hand, typical frame (update) rates \(f_f\) range between 1 and 200 Hz. Therefore, there often is a large gap between the end of a frame to the beginning of the next one. From a power consumption perspective, this is desirable since it allows the sensor to have a smaller duty cycle. However, if needed, the sparse service can be configured for a near 100% duty cycle.

For many applications, sweeps are sampled closely enough in time that they can be regarded as being sampled simultaneously. In such applications, for example presence detection, the sweeps in each frame can be averaged for optimal SNR.

Tip

Unlike the other services, there is no processing applied to the radar data. Also, it typically produces less data. This makes the sparse service relatively computationally inexpensive and suitable for use with smaller MCU:s.

The sparse service utilizes longer wavelets than the other services, meaning that there will be more energy and therefore better SNR in the received signal. For example, this results in an increased distance coverage for presence detection applications. This also means that a wavelet often spans several sparse points.

How to use#

Tip

If this is your first time working with the sparse service, we recommend first getting a feel for how it can be used by running and looking at the presence detector.

While the sparse service has a lot of configuration options, they all have sensible defaults for most applications. The only parameters that you really need to set up to get started is the range and frame (update) rate. Other parameters can be tuned as you go.

If you’re doing things like gesture recognition or any velocity measurements, we recommend using sampling mode A and explicitly setting the sweep rate. Also, raising the number of sweeps per frame might be beneficial for such measurements. From there it is also often a good idea to set the frame (update) rate as high as possible. Lowering the number of HWAAS might be necessary to obtain the desired sweep and/or frame rate.

Configuration parameters#

class acconeer.exptool.a111.SparseServiceConfig

sweeps_per_frame

The number of sweeps per frame \(N_s\).

Must be at least 1, and not greater than 64 when using sampling mode B.

Type: int

Default value: 16

sweep_rate

In Sparse, each frame is a collection of several sweeps over the selected distance range (sweeps per frame). The sweep rate \(f_s\) is the rate at which sweeps are performed, i.e. the rate at which each distance point is scanned. If you set the sweep rate to 4000 Hz and the sweeps per frame to 32, each Sparse data frame will contain 32 sweeps over the selected distance range, where the sweeps are measured at a rate of 4000 Hz.

The maximum possible sweep rate…

Is roughly inversely proportional to the number of depth points measured (affected by the range interval and downsampling factor).
Is roughly inversely proportional to HW accelerated average samples.
Depends on the sampling mode. Mode A is roughly \(4/3 \approx 130\%\) slower than mode B with the same configuration.

To get the maximum possible rate, leave this value unset and look at the sweep rate in the session info (metadata).

Tip

If you do not need a specific sweep rate, we recommend leaving it unset.

Type: float
Unit: Hz
Default value: None

sampling_mode

The sampling mode changes how the hardware accelerated averaging is done. This may either increase SNR or reduce correlation.

Mode A is:

optimized for maximal independence of the depth points, giving a higher depth resolution than mode B.
more suitable for applications like gesture recognition, measuring the distance to a movement, and speed measurements.

Mode B is:

optimized for maximal SNR per unit time spent on measuring. This makes it more energy efficient and suitable for cases where small movements are to be detected over long ranges.
resulting in roughly 3 dB better SNR per unit time than mode A.

Default value: SamplingMode.B

class MUR(value, names=None, *, module=None, qualname=None, type=None, start=1, boundary=None)

class PowerSaveMode(value, names=None, *, module=None, qualname=None, type=None, start=1, boundary=None)

asynchronous_measurement: Enabling asynchronous measurements will result in a faster update rate but introduces a risk of interference between sensors.

Type: bool

Default value: True

downsampling_factor

The range downsampling by an integer factor. A factor of 1 means no downsampling, thus sampling with the smallest possible depth interval. A factor 2 samples every other point, and so on. In Envelope and IQ, the finest interval is ~0.5 mm. In Power Bins, it is the same but then further downsampled in post-processing. In sparse, it is ~6 cm.

The downsampling is performed by skipping measurements in the sensor, and therefore gives lower memory usage, lower power consumption, and lower duty cycle.

In sparse, setting a too large factor might result in gaps in the data where moving objects “disappear” between sampling points.

In Envelope, IQ, and Power Bins, the factor must be 1, 2, or 4. In sparse, it must be at least 1. Setting a factor greater than 1 might affect the range end point and for IQ and Envelope, also the first point.

Type: int

Default value: 1

gain

The receiver gain used in the sensor. If the gain is too low, objects may not be visible, or it may result in poor signal quality due to quantization errors. If the gain is too high, strong reflections may result in saturated data. We recommend not setting the gain higher than necessary due to signal quality reasons.

Must be between 0 and 1 inclusive, where 1 is the highest possible gain.

Note

When Sensor normalization is active, the change in the data due to changing gain is removed after normalization. Therefore, the data might seen unaffected by changes in the gain, except very high (receiver saturation) or very low (quantization error) gain.

Sensor normalization is not available for the Sparse service, but is enabled by default for the other services - Envelope, IQ, and Power Bins.

Type: float

Default value: 0.5

hw_accelerated_average_samples

Number of samples taken to obtain a single point in the data. These are averaged directly in the sensor hardware - no extra computations are done in the MCU.

The time needed to measure a sweep is roughly proportional to the HWAAS. Hence, if there’s a need to obtain a higher sweep rate, HWAAS could be decreased. Note that HWAAS does not affect the amount of data transmitted from the sensor over SPI.

Must be at least 1 and not greater than 63.

Type: int

Default value: 10

maximize_signal_attenuation: When measuring in the direct leakage (around 0m), this setting can be enabled to minimize saturation in the receiver. We do not recommend using this setting under normal operation.

Type: bool

Default value: False

mur

Sets the maximum unambiguous range (MUR), which in turn sets the maximum measurable distance (MMD).

The MMD is the maximum value for the range end, i.e., the range start + length. The MMD is smaller than the MUR due to hardware limitations.

The MUR is the maximum distance at which an object can be located to guarantee that its reflection corresponds to the most recent transmitted pulse. Objects farther away than the MUR may fold into the measured range. For example, with a MUR of 10 m, an object at 12 m could become visible at 2 m.

A higher setting gives a larger MUR/MMD, but comes at a cost of increasing the measurement time for a sweep. The measurement time is approximately proportional to the MUR.

This setting changes the pulse repetition frequency (PRF) of the radar system. The relation between PRF and MUR is

\[\text{MUR} = c / (2 * \text{PRF})\]

where c is the speed of light.

Setting	MUR	MMD	PRF
6	11.5 m	7.0 m	13.0 MHz
9	17.3 m	12.7 m	8.7 MHz

This is an experimental feature.

Default value: MUR.MUR_6

power_save_mode

The power save mode configuration sets what state the sensor waits in between measurements in an active service. There are five power save modes. The modes differentiate in current dissipation and response latency, where the most current consuming mode Active gives fastest response and the least current consuming mode Off gives the slowest response. The absolute response time and also maximum update rate is determined by several factors besides the power save mode configuration.

In addition, the host capabilities in terms of SPI communication speed and processing speed also impact on the absolute response time. The power consumption of the system depends on the actual configuration of the application and it is recommended to test both maximum update rate and power consumption when the configuration is decided.

Power save mode	Current consumption	Response time
Off	Lowest	Longest
Hibernate	…	…
Sleep	…	…
Ready	…	…
Active	Highest	Shortest

Note

Hibernation has limited hardware support. It is not supported by the Raspberry Pi EVK:s and XM112.

Default value: PowerSaveMode.ACTIVE

profile

The main configuration of all the services are the profiles, numbered 1 to 5. The difference between the profiles is the length of the radar pulse and the way the incoming pulse is sampled. Profiles with low numbers use short pulses while the higher profiles use longer pulses.

Profile 1 is recommended for:

measuring strong reflectors, to avoid saturation of the received signal
close range operation (<20 cm), due to the reduced direct leakage

Profile 2 and 3 are recommended for:

operation at intermediate distances, (20 cm to 1 m)
where a balance between SNR and depth resolution is acceptable

Profile 4 and 5 are recommended for:

for Sparse service only
operation at large distances (>1 m)
motion or presence detection, where an optimal SNR ratio is preferred over a high resolution distance measurement

The previous profile Maximize Depth Resolution and Maximize SNR are now profile 1 and 2. The previous Direct Leakage Profile is obtained by the use of the Maximize Signal Attenuation parameter.

Default value: Profile.PROFILE_2

range_interval

The measured depth range. The start and end values will be rounded to the closest measurement point available.

The the sweep range is limited to 7.0 m for the default “maximum unambiguous range” setting. To change this limitation, increase “maximum unambiguous range”.

Type: float
Unit: m
Default value: [0.18, 0.78]

repetition_mode

The RSS supports two different repetition modes. They determine how and when data acquisition occurs. They are:

On demand / host driven: The sensor produces data when requested by the application. Hence, the application is responsible for timing the data acquisition. This is the default mode, and may be used with all power save modes.
Streaming / sensor driven: The sensor produces data at a fixed rate, given by a configurable accurate hardware timer. This mode is recommended if exact timing between updates is required.

The Exploration Tool is capable of setting the update rate also in on demand (host driven) mode. Thus, the difference between the modes becomes subtle. This is why on demand and streaming are called host driven and sensor driven respectively in Exploration Tool.

Default value: RepetitionMode.HOST_DRIVEN

sensor: The sensor(s) to be configured.

Default value: [1]

tx_disable: Disable the radio transmitter. If used to measure noise, we recommended also switching off noise level normalization (if applicable).

Type: bool

Default value: False

update_rate

The rate \(f_f\) at which the sensor sends frames to the host MCU.

Attention

Setting the update rate too high might result in missed data frames.

In sparse, the maximum possible update rate depends on the sweeps per frame \(N_s\) and sweep rate \(f_s\):

\[\frac{1}{f_f} > N_s \cdot \frac{1}{f_s} + \text{overhead*}\]

* The overhead largely depends on data frame size and data transfer speeds.

Type: float
Unit: Hz
Default value: None

Session info (metadata)#

The following information is returned when creating a session.

Data length: Python: data_length

C SDK: data_length

Type: int

The size of the data frames. For sparse, this is the number of depths times the number of sweeps.
Range start: Python: range_start_m

C SDK: start_m

Type: float

Unit: m

The depth of range start - after rounding the configured range to the closest available sparse sampling points.
Range length: Python: range_length_m

C SDK: length_m

Type: float

Unit: m

The length of the range - after rounding the configured range to the closest available sparse sampling points.
Step length: Python: step_length_m

C SDK: step_length_m

Type: float

Unit: m

The distance in meters between points in the range.

Sweep rate: Python: sweep_rate

C SDK: sweep_rate

Type: float

Unit: Hz

The sweep rate. If a sweep rate is explicitly set, this value will be very close to the configured value. If not (the default), this will be the maximum sweep rate.

Data info (result info)#

The following information is returned with each data frame.

Missed data: Python and C SDK: missed_data

Type: int

Indicates if a data frame was missed, for example due to a too high update_rate.
Data saturated: Python and C SDK: data_saturated

Type: bool

Indication that the sensor has hit its full dynamic range. If this indication is given, the result might be unstable. Most often, the problem is that the gain is set too high.

Disclaimer#

The sparse service will have optimal performance using any one of the XM112, XM122 or XM132 Modules. A111 with batch number 10467, 10457 or 10178 (also when mounted on XR111 and XR112) should be avoided when using the sparse service.