UWB radar on Qorvo QM35: taking presence detection from SDK demo to a validated product feature

Facts checked on 16 October 2026

Short answer

The QM35825 works as a radar: it transmits and listens simultaneously and reports a channel impulse response (CIR) per sweep. Qorvo’s QM35 SDK 3.0 (July 2025) supports radar sessions alongside FiRa ranging and ships “a sample presence detection algorithm”, positioned for “initial trials, proof-of-concept implementations, and internal evaluations”.

A product needs its own host algorithm, a configuration sized for the host link and power budget, and validation on recorded datasets. In cars, that means Euro NCAP’s child presence detection (CPD) protocol, which has rewarded only direct sensing since 2025.

What the QM35825 and SDK 3.0 give you

Qorvo’s product brief lists radar for “Motion Detection, vital sign monitoring, people counting, gesture detection” on the QM35825, a system-on-chip with four RF ports on channels 5 and 9. The SDK documentation describes the principle: “While the QM35 is transmitting a frame, its RX path is activated and listens to the echoes from the environment.” The chip produces one CIR, an array of complex samples (taps), per sweep; sweeps are grouped into bursts, and the direct path from transmit to receive antenna appears in every CIR.

Four constraints shape every design:

• Your algorithm runs on the host. Customers cannot build their own QM35825 firmware: “you must use the pre-compiled software from Qorvo on the device”. The radar session delivers CIR data, and “the algorithm then processes this data”.
• Low power mode pauses during radar. The release notes state that “Low Power Mode is automatically disabled when Sensing/Radar is active, as enabling it would degrade CIR (Channel Impulse Response) quality”, with a fix expected in a later release.
• Older Qorvo parts are not radars. Qorvo staff wrote in June 2026 that “the DWM3001C was not meant for radar and it cannot simultaneously transmit and receive at the same time. Our QM35 series has this ability.”
• Each sensor keeps its own clock. Qorvo staff wrote in January 2026 that synchronising two boards using different preamble codes is not supported, so fuse decisions from several sensors, not raw CIRs.

For vehicles, Qorvo’s automotive QPF5100Q (AEC-Q100 Grade 2, up to 2 MB of flash) also lists radar for presence detection. Its product page lists an application note titled “In Car Cabin Child Presence Detection (CPD)”, dated September 2026.

Inside a radar data message

In the SDK’s Python tools, a radar session is a UCI session of type 0xA1, configured through vendor tags 0xB0 to 0xB7 and started with the ordinary ranging start command. CIRs arrive as UCI data packets with data packet format 15, which the Python decoder and Cherry’s C client parse the same way (all fields little-endian):

A 64-tap sweep with 48-bit samples makes a 406-byte message: about 8.1 kB/s at a 50 ms burst period and 58 kB/s at Qorvo’s measured 7 ms minimum, before UCI and transport framing. The 32-bit timestamp wraps every 4,294,967,296 RSTU, about 60 minutes; log host time too. The documents allow up to 255 samples per sweep, but a comment in Qorvo’s Cherry sample says “the QM firmware returns 157 sample at most”, and its C dump utility decodes only 48-bit samples.

The configuration that matters

The C sample defaults to a 100 ms burst period.

Timing must be consistent: Qorvo’s Cherry guide requires burst_period_ms >= sweep_period_rstu/1200 * sweeps_per_burst, and a session that breaks the rule reports an error at start. Qorvo also warns that “setting burst_period_ms too low could overflow the transport medium and cause Radar measurments drop”, so size the host interface early. It traced the 7 ms limit to the Python script and FT4222 adapter; because all sweeps of a burst travel in one message, one sweep per burst gives the best rate. The UART “is much slower than the SPI one”.

Set every radar parameter explicitly

In SDK 3.0.0, cherry_radar_session_create() sets only timing, samples per sweep and antenna set, with no setter for frame configuration or preamble. One developer removed null taps from the Cherry sample by adding one that forces SP0.

A Cherry session for a 4.8 m window sampled at 20 Hz (illustrative):

struct cherry_radar_session *rs = cherry_radar_session_create(
    ctx, on_radar_event, &app,
    1,     /* session_id: any non-zero value */
    50,    /* burst_period_ms: slow-time sampling period */
    1200,  /* sweep_period_rstu: 1 ms */
    1,     /* sweeps_per_burst: one CIR per message */
    32,    /* samples_per_sweep: about 15 cm per tap */
    3);    /* antenna_set: defined by runtime calibration */
/* rule: 50 >= 1200 / 1200 * 1, otherwise an error event at start */
cherry_radar_session_set_sweep_offset(rs, -10);
cherry_radar_session_set_tx_profile_idx(rs, 1);    /* 0x01 = TX_PROFILE_LOW */
cherry_radar_session_set_number_of_bursts(rs, 0);  /* run until stopped */
cherry_radar_session_start(rs);

A tuning procedure

Run the steps in order; any hardware, firmware or parameter change restarts at step 2.

1. Calibrate after every boot. Load the radar antenna-set definitions and read them back. Pass: keys present after every power cycle.
2. Fix the frame configuration. Set SP0 and record an empty scene. Pass: no single taps near zero between strong neighbours.
3. Choose the burst period. Start at 50 ms and log for ten minutes. Pass: no gaps in sequence numbers.
4. Place the range window. Cover the zone from the direct path to the farthest reflector of interest, plus a few taps. Pass: an adult at the far edge appears; one outside does not.
5. Choose the Tx profile. Use the lowest profile that keeps the far-edge target clearly above the empty-scene score.
6. Set thresholds from recorded distributions. Qorvo warns that the demo thresholds “have to be adjusted for a given combination of hardware and parameters”. Pass: no crossings on a held-out recording.

On the DK-05:

# PC interface board, Python tools over the FT4222 SPI bridge
cd Samples/Python/UWB-Qorvo-Tools/scripts/device/load_cal
load_cal -p ftdi://FT4222 -f calib_files/QM35825DK/jolie_quad_radar_TWR_180AoA.json
radar_simple_demo -p ftdi://FT4222 -o Output/ --plot static
radar_presence_detection_demo_cli -th 3000 5000 -sample 0 64 -sweep 0 50

# Raspberry Pi host, Cherry samples
cherry-get-calib-app -a                       # dump all calibration keys
cherry-radar-app -n 0 -b 50 -f radar.data     # run until a key press, I/Q to file

From CIR to a decision

A presence feature is a processing chain, and most of the product value sits in it:

1. Remove the static scene. Subtract a slowly updated background from each CIR to suppress walls, furniture and the direct antenna path.
2. Find motion per range bin. Large changes indicate walking or limb movement.
3. Find micro-motion. Breathing appears as small periodic changes; Euro NCAP’s test bulletin specifies breathing rates from 30 breaths per minute for a newborn to 18 for a six-year-old.
4. Track and decide. Combine evidence over time with hysteresis, so one noisy frame neither triggers nor clears a detection.
5. Report with confidence and diagnostics. The rest of the product needs a state, a confidence and health information, such as lost sweeps.

Qorvo describes UWB radar as using about 500 MHz of bandwidth, “approximately 30 cm of spatial resolution”, and enough sensitivity to detect “subtle movements associated with breathing and heart rate”. Those are capabilities of the signal; reliability comes from the algorithm and its validation.

What Qorvo’s sample algorithm does

The demo’s presence_detection.py keeps 50 sweeps, subtracts each tap’s mean, takes magnitudes and scores the largest per-tap standard deviation over time. Presence is declared above a high threshold and cleared below a low one: 500 and 200 in the class, 5,000 and 3,000 in the command-line demo, which refreshes every 0.1 s.

Two limits matter for CPD. At the demo’s 50 ms burst period, 50 sweeps span 2.5 s, shorter than one breath at 18 per minute (3.3 s); the code’s own comment recommends keeping 5 to 10 seconds. And one maximum over all taps reacts to movement anywhere in the window.

Static clutter removal

The SDK’s sweep_utils.py offers several background estimators:

Subtracting the background is a high-pass filter. At a 50 ms burst period, an EMA with alpha 0.9 puts the −3 dB point near 0.38 Hz and attenuates a six-year-old’s 0.3 Hz test rate by about 4 dB; alpha 0.99 moves it to about 0.03 Hz.

Breathing: band, window and phase

Breathing is read in slow time, one tap’s values across sweeps. A 50 ms burst period samples at 20 Hz; a window of length T resolves 1/T, so 15 s resolves 4 breaths per minute, as in one IR-UWB study that used 15 s windows with 2 s steps. The SDK’s 32-point short-time FFT spans only 1.6 s at 20 Hz (0.625 Hz resolution): fine for motion, too coarse for breathing rate.

Size the band for children. That study used 0.15 to 0.4 Hz and another searched 10 to 30 cycles per minute, which miss or graze Euro NCAP’s 0.5 Hz newborn rate; a Lancet review gives a median of 44 breaths per minute at birth (about 0.73 Hz).

Pick the tap with the highest slow-time variance and use complex samples, not magnitude alone. A chest displacement z shifts the echo phase by 4πz/λ; on channel 9 (7,987.2 MHz, λ ≈ 37.5 mm), 1 mm rotates it by about 0.33 rad (19°). Keep heart rate out of presence decisions: one study shows a fourth breathing harmonic at 71 per minute beside a true heart rate of 70.

Decision logic and timing

Combine a motion score for awake occupants with a breathing score for sleeping ones, give each transition its own threshold and a minimum run of consecutive windows, and publish the state with health counters. Euro NCAP allows 15 seconds after locking to assess occupancy, so start filling the window earlier, for example when the engine stops.

The sketch below is illustrative; the 0.15 to 1.0 Hz band, thresholds and counts are example placeholders.

import numpy as np

FS = 1000 / 50             # slow-time rate for a 50 ms burst period, Hz
N, STEP = int(15 * FS), int(2 * FS)   # 15 s window, a decision every 2 s
BAND = (0.15, 1.0)         # Hz, example breathing band

def main_axis(z):          # complex slow-time signal of one tap
    z = z - z.mean()
    w = np.linalg.eigh(np.cov(np.vstack([z.real, z.imag])))[1][:, -1]
    return w[0] * z.real + w[1] * z.imag   # roughly proportional to displacement

def scores(win, bg):       # win, bg: complex arrays [N, taps]
    x = win - bg                           # static clutter removed
    motion = np.std(np.abs(x), axis=0).max()
    tap = np.argmax(np.var(x, axis=0))
    spec = np.abs(np.fft.rfft(main_axis(x[:, tap]) * np.hanning(N)))
    f = np.fft.rfftfreq(N, d=1 / FS)
    inb = (f >= BAND[0]) & (f <= BAND[1])
    breath = spec[inb].max() / (np.median(spec[f > 0]) + 1e-9)
    return motion, breath, 60 * f[inb][spec[inb].argmax()]

state, count = "EMPTY", 0
for win, bg, health in windows(stream, N, STEP):   # bg: EMA with alpha 0.99
    motion, breath, rate = scores(win, bg)
    if state == "EMPTY":
        hit = motion > MOTION_HI or breath > BREATH_HI
        count = count + 1 if hit else 0
        if count >= N_ENTER:
            state, count = "OCCUPIED", 0
    else:
        quiet = motion < MOTION_LO and breath < BREATH_LO
        count = count + 1 if quiet else 0
        if count >= N_EXIT:
            state, count = "EMPTY", 0
    publish(state, motion, breath, rate, health)   # rate in breaths per minute

Cherry’s header says the callback “should return immediately and should not be blocking”, and each event “has to be freed” with cherry_radar_event_free() (illustrative):

static int32_t s24(const uint8_t *p)    /* 24-bit little-endian, signed */
{
    int32_t v = p[0] | (p[1] << 8) | (p[2] << 16);
    return (v & 0x800000) ? v - 0x1000000 : v;
}   /* 48-bit sample k: I = s24(d + 6 * k), Q = s24(d + 6 * k + 3) */

static void on_radar_event(struct cherry_radar_event *ev, void *user)
{
    struct app *app = user;

    if (ev->type == CHERRY_RADAR_EVENT_TYPE_SESSION_REPORT &&
        ev->data.report->status == CHERRY_RADAR_REPORT_STATUS_SUCCESS) {
        struct cherry_radar_session_report *r = ev->data.report;

        for (int i = 0; i < r->n_sweeps; i++) {
            struct cherry_radar_sweep *s = &r->sweeps[i];

            if (app->have_seq && s->sequence_number != app->next_seq)
                app->lost += s->sequence_number - app->next_seq;
            app->next_seq = s->sequence_number + 1;
            app->have_seq = true;
            for (int f = 0; f < s->n_data_fragments; f++)
                queue_push(app->q, s->timestamp, s->data_fragments[f].data,
                           s->data_fragments[f].size);
        }
    } else if (ev->type == CHERRY_RADAR_EVENT_TYPE_SESSION_ERROR) {
        app->session_errors++;
    }
    cherry_radar_event_free(ev);
}

Radar and ranging on one chip

The SDK states that “the Radar and FiRa TWR can be run concurrently” and includes an interleaving sample. That enables combined products: a lock that detects a person approaching and ranges with their phone, or a car-access system that also checks the cabin. Plan three things before you combine them:

• Airtime and priority. Each session has a priority from 1 to 100. As embedUR put it in June 2026, interleaving ranging and radar “is a scheduling problem that ranging-only firmware never had to solve”.
• Power. With low power mode off during radar, run radar in bursts triggered by events, such as a door closing or a ranging result, rather than continuously.
• Host load. CIR streams and ranging results share the same host link and processor.

The interleaving sample pairs a radar session (priority 70, 200 ms burst period, 1,024-symbol preamble) with a FiRa session (200 ms ranging duration) and prints frames per second and frames lost, useful pass criteria when you change either session:

# Shell 1: controller runs FiRa TWR and radar.  Shell 2: the ranging peer.
radar_fira_interleaving -p /dev/ttyUSB0 -t -1 --radar-burst-period-ms 200
run_fira_twr -p /dev/ttyUSB1 --controlee -t -1

Power budget

Qorvo states that “UWB radar sensing consumes less than 10mW while detecting objects across several meters”. Treat it as a vendor figure and measure your own configuration. The SDK’s limitation on low power mode means the duty cycle decides battery life. Measure on representative hardware: Qorvo’s release notes advise against using its PC interface board for “meaningful low power measurement”.

Budget energy per event. Taking Qorvo’s figure as a ceiling, the 15-second check at locking costs under 0.15 J and a ten-minute watch after a door closes on an unlocked car under 6 J; continuous radar costs up to 240 mWh a day. Add the host, which stays awake to receive every burst.

On the DK-05 radio board, measure each QM35825 rail by replacing its jumper with a current probe: VDD1 (1.8 V, J8), VDD2 (2.5 V, J7), VDD3 (1.6 V, J9), VDD4 (1.8 V, J6) or VDD1.2V (1.2 V, J5). With 1.8 V GPIOs, optimal low-power current needs RRVDD moved to VDDIO (remove R33, fit R36).

Typical failures and how to fix them

Validation: where demos and products part ways

A demo shows that detection is possible. Validation shows how often it fails. Build the plan around four metrics: detection rate per position and posture, false alarms per day, time to detect, and time to clear.

Collect real-world data from the first prototype onwards. Euro NCAP’s own warning applies beyond cars: “test tools must not be the only source of data used during system development”.

How many trials are enough

With no failures in N independent trials, the upper 95% confidence limit for the failure rate is approximately 3/N. A 99% detection claim for one scenario needs about 300 trials without a miss; fewer than one false alarm per 100 empty days needs about 300 empty device-days without one. Count independent sessions, not overlapping windows.

ETSI EN 302 065-3-3 asks micro-motion equipment for a Probability of Detection above 90% from 20 decisions and a False Detection Ratio below 1% from 400: a radio-conformance floor, far too few decisions to characterise a safety feature.

Bench tests before cabin tests

ETSI’s micro-motion set-up moves a corner reflector sinusoidally at 0.5 Hz with 3 mm peak-to-peak at 3 m, or rotates a sphere at 0.5 cycles per second on a 3 mm radius at 1 m. Its 3 mm swing is about 1 rad of phase on channel 9. Use it for unit-to-unit spread and regression before human tests.

Store raw captures (radar_simple_demo JSON or cherry-radar-app -f files) and replay the archive after each algorithm change. Split data by vehicle or room and by unit: TU Graz researchers report an infant-detection F1 score of 97.0% in a car similar in size to the training data and 93.2% in a substantially larger one.

Child presence detection: what Euro NCAP asks for

In the 2026 rating scheme, CPD belongs to the Occupant Monitoring protocol (version 1.2, July 2026, implementation January 2026) in the Safe Driving stage, and is worth up to 5 points.

Regulation is moving in parallel. In the EU, Implementing Decision (EU) 2024/1467 allows UWB equipment in vehicles under conditions, and ETSI EN 302 065-3-3 (January 2026) covers monostatic in-vehicle UWB radar, including detection of “respiration or heartbeat”. In the US, the FCC sought comment in July 2026 on a waiver for in-car UWB motion sensors that detect infants left in parked cars, and in September 2026 proposed modernising its UWB rules.

SD-102 test cases in radar terms

Technical Bulletin SD-102 v2.0 defines the left-behind cases:

The blanket is at least 70 × 90 cm and 300 GSM, covering a sleeping child from shoulders to feet, and sleeping means “only respiratory movement”. Gained-access cases use no child seat: a three-year-old asleep on the rear seat or awake in a footwell, and a six-year-old asleep on the rear seat, in an unlocked car out of keyless-entry range.

The dossier asks for “triggering thresholds and any grey zone information”, worst cases “from newborn (4kg/46cm) up to 6YO”, unoccupied seats moved through their adjustments, machine-learning training-sample details and “a direct comparison between the output recorded with humans and the test tool(s)”. After locking, detection must continue, because escalation depends on the child’s continued presence.

Beyond cars: smart home and vital signs

Presence detection in buildings uses the same chain with different targets: rooms instead of seats, comfort and energy instead of safety alarms. Qorvo and its partners also promote vital-sign sensing without cameras. If a product reports breathing or heart rate, decide early whether it is a wellness feature or a medical device, because the second brings a separate regulatory programme.

From our engineering work

Inside Qorvo’s UWB programme, needCode led end-to-end UWB radar development and bring-up, a capability beyond ranging, and built hardware-in-the-loop stands with custom robotics for verification. Our architects co-designed emerging UWB radar standards and APIs with leading technology companies. Radar and presence detection, including child presence detection, are among the use cases we deliver on Qorvo silicon.

How needCode helps

We take UWB radar on the QM35825 and QPF5100Q from the SDK demo to a validated feature: radar configuration and host integration, the CIR processing chain and detection logic, concurrency with ranging, power design, and a validation programme with recorded datasets, test rigs and long-run false-alarm measurements. For automotive programmes we prepare the CPD evidence that the Euro NCAP dossier requires.

Frequently asked questions

How do I implement UWB radar presence detection on the QM35825?

Start a radar session through the Cherry C API or UCI, receive CIR reports on the host and run your own detection algorithm there. The SDK’s demos and sample algorithm show the data flow. Product reliability depends on the processing chain and its validation, not on the demo.

Can one UWB chip do ranging and radar at the same time?

Yes, on the QM35825. Qorvo’s SDK 3.0 release notes state that radar and FiRa TWR “can be run concurrently”, and the SDK includes an interleaving sample. Plan airtime, session priorities and power, because low power mode is disabled while radar runs.

Can the DWM3001C or DW3000 work as a radar?

No. Qorvo staff wrote in June 2026 that the DWM3001C “cannot simultaneously transmit and receive at the same time”, while the QM35 series can.

What does Euro NCAP require for child presence detection?

Direct sensing that is on by default, coverage of children up to six years old in all likely positions, a first warning at locking or within 10 minutes for children who got into an unlocked car, and escalation within 90 seconds. Since 2025 indirect systems score no points, and in 2026 CPD is worth up to 5 points.

How much power does UWB radar presence detection use?

Qorvo states under 10 mW for sensing across several metres. In SDK 3.0 low power mode is disabled while radar is active, so the duty cycle decides battery life. Measure your configuration on representative hardware.

Is the SDK’s presence-detection algorithm ready for production?

Qorvo calls it a sample, and positions SDK 3.0 for trials, proofs of concept and evaluation. Use it to understand the data, then develop and validate your own algorithm for your housing, mounting and use case.

Why do some CIR taps drop to near zero?

Qorvo staff reproduced the “Null taps” with the SP3 frame configuration and confirmed that the documented SP3 default is an error; the SDK default is SP0. Set SP0 explicitly; Cherry’s radar API in SDK 3.0.0 has no setter for it, so add one.

How many test runs support a detection-rate claim?

With no failures in N independent trials, the 95% upper confidence limit on the failure rate is about 3/N, so about 300 clean trials per scenario support a 99% claim.

Sources

1. Qorvo QM35825 product page and QM35 SDK repository with documentation
2. Qorvo Tech Forum: “QM35 SDK 3.0 is now available” (July 2025)
3. Qorvo Tech Forum: radar frame configuration default (staff, January 2026), DWM3001C and radar (June 2026) and QM35825 application development (2025–2026)
4. Qorvo blog: “Ultra-Wideband (UWB) Radar: Beyond Ranging to Advanced Sensing” (March 2025) and white paper “Sensing Beyond Limits” (July 2025)
5. Qorvo QPF5100Q product page and QPF5100Q announcement (January 2025)
6. Euro NCAP: Safe Driving – Occupant Monitoring Protocol v1.2 (July 2026)
7. Euro NCAP: SD-102 Child Presence Detection Evaluation v2.0 (July 2025) and CPD Test and Assessment Protocol v1.3 (2024)
8. Commission Implementing Decision (EU) 2024/1467 and ETSI EN 302 065-3-3 V3.1.1 (January 2026)
9. FCC Public Notice DA 26-743 on in-car UWB motion sensors (July 2026) and Benton: FCC proposes modernisation of UWB rules (September 2026)
10. embedUR: “UWB Beyond Ranging: What IEEE 802.15.4ab Means for Your Firmware” (June 2026)
11. Qorvo QM35 SDK 3.0.0 documents (July 2025): UWB Radar Protocol, Release Notes and UWB Qorvo Tools Guide
12. Qorvo QM35 SDK 3.0.0 guides (July 2025): QM35 DK-05 User Manual, QM35825DK-05 HW User Guide Rev B and Cherry API and Integration Guide
13. Qorvo QM35 SDK 3.0.0 Python radar code: radar scripts with presence detection, sweep utilities and parameters, radar data decoder, UCI radar extension and UCI core definitions
14. Qorvo QM35 SDK 3.0.0 Cherry radar code: cherry_radar.h, cherry-radar-app sample, radar UCI client and dump utility
15. Qorvo Tech Forum: synchronising two QM358 boards (staff, January and July 2026)
16. Khan and Cho: “A Detailed Algorithm for Vital Sign Monitoring of a Stationary/Non-Stationary Human through IR-UWB Radar”, Sensors 17(2), 2017
17. Zhang et al.: “Contactless Simultaneous Breathing and Heart Rate Detections in Physical Activity Using IR-UWB Radars”, Sensors 21(16), 2021
18. Zheng et al.: “MoRe-Fi: Motion-robust and Fine-grained Respiration Monitoring via Deep-Learning UWB Radar”, ACM SenSys 2021
19. Fleming et al.: “Normal ranges of heart rate and respiratory rate in children from birth to 18 years”, The Lancet, 2011
20. Newman: “If Almost Nothing Goes Wrong, Is Almost Everything All Right? Interpreting Small Numerators”, JAMA, 1995
21. TU Graz Signal Processing and Speech Communication Laboratory: “Infant Detection using UWB Radar” (April 2026)

About needCode

needCode is an independent embedded engineering company from Kraków, Poland, and an official UWB business partner of Qorvo. Its engineers have worked inside Qorvo’s wireless programmes for more than eight years, including on the public QM35 SDK. needCode is certified to ISO 9001:2015 and ISO/IEC 27001:2022 and is a member of the UWB Alliance. This article does not represent Qorvo. All trademarks belong to their respective owners.