DEV Community: fuxinsuo

The Sleep Monitoring Radar: What It Measures, How to Install It, and How to Read the Data

fuxinsuo — Sat, 17 Oct 2026 09:14:24 +0000

The sleep monitoring radar measures presence in bed, breathing rate, heart rate, body movement, sleep stages, and a sleep score, all without contact and without a camera. It is mounted once above or beside the bed, and it reports data continuously through the night.

This article covers everything about this radar: what each data point means, how a night is processed, where to install it, and how to read the output over MQTT or UART. It is written for the radar sold in this store, so all ranges, frequencies, and values are the ones this specific model uses.

This is a consumer wellness device. It is not a medical device and does not diagnose, treat, or prevent any condition.

Two Variants, Two Protocols

This radar is available in two forms, and they use completely different protocols. Check which one you have before reading further.

Variant	Interface	Protocol	Configuration
Sleep radar module	UART only	Frame protocol at 115200 bps	Wired, no network setup
Sleep radar	2.4 GHz Wi-Fi + MQTT	JSON property protocol over MQTT topics	Web page for MQTT, Android app for Wi-Fi

Both variants share the same sensing core, so the measured values mean the same thing. The ranges, the commands, and the reporting details differ, and every value in this article is marked with the variant it belongs to.

The sleep radar module is the bare sensing core for integrators who embed it in their own product; its output is described under Over UART. The sleep radar is the finished unit that joins your network; its output is described under Over Wi-Fi and MQTT.

What This Radar Is

The sleep radar is a 60 GHz millimeter wave sensor in a housing of approximately 80 × 80 × 51.8 mm. It is designed for fixed installation at a bed: either side-wall mounted or mounted above the bed head and tilted downward.

The sleep radar module is the same sensing core without the housing and without the Wi-Fi section. It exposes a UART interface and is intended to be built into another product.

Both measure, through a blanket and in complete darkness:

Whether a person is in bed or out of bed
Breathing rate and breathing state
Heart rate
Body movement level
Sleep stage: awake, light sleep, or deep sleep
Time spent in each stage, and a sleep score at the end of the night

Neither measures who the person is, and neither records images, video, or audio. The sleep radar publishes numbers over Wi-Fi; the sleep radar module publishes them over a serial line.

How It Sees You Through a Blanket

The radar transmits a 60 GHz FMCW signal and analyses the echo. Breathing moves the chest wall by less than one millimeter, and the 60 GHz band resolves displacements of that scale. A blanket is a non-metallic material, so the signal passes through it and reflects off the chest underneath.

The beam covers a horizontal angle of 40° and a vertical angle of 40°, so the radar must be aimed at the chest area rather than at the whole room. A full explanation of the FMCW principle is in the companion article How mmWave Radar Works.

What It Measures

Every value below is reported either when the state changes or at a fixed interval. The exact property names for Wi-Fi and UART are given in the section Getting the Data Out.

Presence in Bed

State	Meaning
0	Out of bed
1	In bed

The radar reports a person within 0.5 s of detection. It takes about 40 s of confirmed absence before it reports unoccupied, because the radar checks for micro-movement and breathing before declaring the area empty.

The in-bed state is entered as soon as the energy condition is met. The out-of-bed state is output about 30 s after the person leaves.

Motion Status

Value	Meaning
0	No movement
1	Still (static)
2	Active

State changes are reported within 0.5 s.

Body Movement Level

A single value from 0 to 100, reported every 1 s. The ranges have fixed meanings:

Value	Meaning
0 %	No person in range
1 %	Still: breathing only, no limb movement
2 %–30 %	Micro movement: small head or limb motion
31 %–60 %	Walking or fast limb movement
61 %–100 %	Running or large close-range movement

This is the most useful value for tuning an installation. A correctly aimed radar reports values around 1 % while a person lies still.

Breathing Rate

Reported every 3 s. The range is 0–45 breaths per minute on the sleep radar module and 0–30 on the sleep radar.

The breathing state is reported separately when it changes:

State	Meaning
Normal	10 to 25 breaths per minute
High	Above 25 breaths per minute
Low	Below 10 breaths per minute
None	No person detected (default state)

The breathing waveform is available but switched off by default. When enabled, it reports 5 values every second, each in the range 0–255. Each value is the real measurement plus 128, which keeps the curve centred on the display axis.

Heart Rate

Reported every 3 s. The range is 50–120 bpm on the sleep radar module and 60–120 bpm on the sleep radar, which is the corrected range.

The heart rate state is reported separately: normal, high, low, or detecting. The heart rate waveform follows the same rule as the breathing waveform: 5 values per second, 0–255, real value plus 128, off by default.

Human Distance and Position

Both are reported every 2 s. Distance is in centimetres, 0–65535. Position is given as x, y, and z coordinates.

Both are marked as non-critical functions with limited accuracy in the sleep radar module documentation. They are useful for debugging an installation, but they should not be used as the basis of a product feature.

Sleep Stage

Reported every 10 minutes while the person is in bed.

Value	Meaning
0	Deep sleep
1	Light sleep
2	Awake
3	None (out of bed)

The stage is evaluated once per 10-minute window, so the value changes in steps rather than continuously. Note that some older versions of the documentation list these values in a different order; the order above is the one used by the sleep radar module protocol.

Stage Durations

Three separate values, in minutes: awake duration, light sleep duration, and deep sleep duration. Each ranges from 0 to 65535 and is updated together with the 10-minute sleep stage report.

Sleep Score and Sleep Rating

The sleep score is reported when the sleep session ends, as a value from 0 to 100.

A valid score is only produced when the sleep duration is between 4 and 12 hours. Outside that range the session is treated as an anomaly and no meaningful score is output.

The radar also reports a rating derived from the score:

Score	Rating
1–60	Poor
61–75	Fair
76–100	Good

The Sleep Report

At the end of a sleep session the radar publishes a report of 11 fields. This is the main output most integrations use.

Field	Range
Sleep score	0–100
Total sleep duration	0–65535 minutes
Awake percentage	0–100
Light sleep percentage	0–100
Deep sleep percentage	0–100
Time out of bed	0–255
Number of times out of bed	0–255
Turn count	0–255
Average breathing rate	0–25
Average heart rate	0–100
Breathing pauses	0–10

Breathing pauses are counted as a raw sensor output. The radar counts pauses in the breathing waveform; it does not interpret them, and no medical meaning should be attached to the number.

Sleep Comprehensive Status

A second, shorter report published every 10 minutes while the person is in bed, with 8 fields:

Field	Range
Presence	1 = present, 0 = absent
Sleep stage	3 = out of bed, 2 = awake, 1 = light, 0 = deep
Average breathing rate	10-minute average
Average heart rate	10-minute average
Turn count	Turns during light or deep sleep
Large movement proportion	0–100
Small movement proportion	0–100
Breathing pauses	Count within 10 minutes

This report is the practical choice for a live dashboard, because it arrives every 10 minutes whether or not the stage changes.

Sleep Anomalies

Reported when the state changes:

Value	Meaning
0	Sleep duration shorter than 4 hours
1	Sleep duration longer than 12 hours
2	No presence detected for 30 minutes while in a sleep state
3	None

The 30-minute rule is the one most useful in care settings: if the radar is in a sleep state and detects nobody for half an hour, it raises the anomaly.

Struggle and No-Person Timing

Two further functions are available on the sleep radar module protocol. Both are switches that must be enabled before they report anything.

Abnormal struggle: reports none, normal, or abnormal struggle. The sensitivity of the judgement can be set to low, medium (default), or high.
No-person timing: reports none, normal, or abnormal. The threshold is configurable; note that the documented range differs between the setting command and the query command, so treat the setting range as the reliable one.

Reporting Rhythm

A single table of every value and when it arrives:

Data Point	Range	Reported
Presence in bed	0 / 1	On change
Motion status	0 / 1 / 2	On change
Body movement	0–100	Every 1 s
Human distance	0–65535 cm	Every 2 s
Human position	x, y, z	Every 2 s
Breathing rate	0–45	Every 3 s
Breathing state	Normal / high / low / none	On change
Heart rate	50–120 bpm	Every 3 s
Heart rate state	Normal / high / low / detecting	On change
Breathing waveform	5 values, 0–255	Every 1 s, off by default
Heart rate waveform	5 values, 0–255	Every 1 s, off by default
Sleep stage	0–3	Every 10 min while in bed
Stage durations	0–65535 min	With the 10-minute report
Sleep score	0–100	On sleep end
Sleep rating	Poor / fair / good	On change
Sleep report	11 fields	On sleep end
Sleep comprehensive status	8 fields	Every 10 min
Sleep anomaly	0–3	On change

Installation

Two Mounting Methods

Side-wall mounting (sleep radar). Mount the radar on the wall at the side of the bed, at a height of 1.8–2.2 m, pointing at the bed. This is the standard method for the finished sleep radar and needs no tilt adjustment.

Tilted mounting above the bed head (sleep radar module). Mount the radar above the bed head, tilted downward at 30°–45°, with 45° recommended, and 0.8–1 m above the bed surface. This is the method described in the sleep radar module documentation and gives the strongest breathing signal, because the beam hits the chest directly instead of at an angle.

Use the tilted method whenever the physical layout allows it.

Detection Range

Signal	Maximum Distance
Breathing rate	~1.5 m
Sleep detection	~2.5 m
Human presence	~2.5 m

If the bed is large, or the radar ends up further away than these distances, the breathing signal degrades first and disappears before the presence detection does.

What Interferes

Avoid installing the radar where the beam reaches:

Electric fans (moving blades cause false readings)
Air conditioners (the internal motor causes false detection)
Curtains that move with air flow
Metal objects
Water pipes or flowing water
Pets that move around the bed

Do not aim the radar directly at an air conditioner, and do not install it facing the same direction as the air flow.

What the Signal Passes Through

The signal is not blocked by:

Clothing and blankets
Curtains
Thin wooden boards
Glass

Installation Steps

Identify the bed head and the position where the sleeper's chest rests.
For side-wall mounting, mark a point 1.8–2.2 m high on the wall at the side of the bed. For tilted mounting, mark a point 0.8–1 m above the bed surface, above the bed head.
Aim the radar so the main beam covers the chest area of a person lying on the bed.
Check the whole detection area for the interference sources listed above and remove or avoid them.
Fix the radar in place and power it.
Wait for the initialization to complete, then verify the data.

Verifying the Installation

Four tests, taken from the sleep radar module documentation:

Sleep stage. Lie still on the bed for 10 minutes. The reported stage should change from awake to light sleep.
In-bed detection. Approach the bed at a speed of at least 0.7 m/s and stop the moment the state changes. The radar should report in-bed.
Out-of-bed detection. Leave the area, at least 3 m away with no interference. The radar should report out-of-bed within 5 minutes.
Breathing. Sit still within 1.5 m in front of the radar, breathe calmly for 3 minutes, then hold your breath for 30–40 seconds. The breathing value should drop to 0 and the radar should report a breathing-hold event.

If the breathing waveform is flat or missing during test 4, the radar is not aimed at the chest. Adjust the angle or the height before looking at anything else.

How a Night Is Processed

Understanding this sequence explains most of the odd-looking data.

Power on. The radar initializes and reports that initialization is complete.
Mode selection. The radar runs in one of two modes. Sleep detection mode is the default and the mode to use. Real-time detection mode exists for quick testing only and does not produce a sleep report.
In-bed. When the energy condition is met, the radar reports in-bed and starts evaluating.
Stage evaluation. Every 10 minutes, the radar judges the stage and reports it, together with the updated stage durations and the comprehensive status.
Out of bed. About 30 seconds after the person leaves, the radar reports out-of-bed.
Session end. If the person does not return, the radar treats the session as finished and computes the statistics.
Report. The sleep score and the full sleep report are published. The report is generated once the area has been unoccupied for about 5 minutes.

Two consequences worth knowing:

Switching modes clears the data. If you switch between real-time and sleep detection mode, the accumulated data is discarded and detection restarts from zero.
A short night produces no score. Sessions shorter than 4 hours or longer than 12 hours are reported as anomalies instead.

Getting the Data Out

Over Wi-Fi and MQTT (sleep radar)

Two topics are used, with the model prefix for the sleep radar being Radar60SP:

Report topic: /Radar60SP/{DeviceID}/sys/property/post
Set topic: /Radar60SP/{DeviceID}/sys/property/set

Data is JSON. A typical report looks like:

{"version": "1.0", "method": "post", "params": {"sleepStatus": "0"}}

The properties you will use most:

Property	Meaning	Access
`sleepSwitch`	Sleep function on / off	get, set
`sleepStatus`	Sleep stage	post, get
`getIntoBed`	In bed / out of bed	post, get
`awakeDuration`	Awake minutes	post, get
`lightSleepDuration`	Light sleep minutes	post, get
`deepSleepDuration`	Deep sleep minutes	post, get
`sleepScore`	Sleep score	post, get
`sleepComprehensiveStatus`	8-field status report	post, get
`sleepQualityAnalysis`	11-field sleep report	post, get
`abnormalSleep`	Sleep anomaly	post, get
`breathSwitch`	Breathing function on / off	get, set
`breathValue`	Breathing rate	post
`breathInform`	Breathing state	post, get
`heartRateSwitch`	Heart rate function on / off	get, set
`heartRateValue`	Heart rate	post
`heartRateInform`	Heart rate state	post, get
`someoneExists`	Presence	post, get
`motionStatus`	Motion status	post, get
`movementSigns`	Body movement level	post, get
`reportMode`	1 = sleep mode, 0 = real-time mode	get, set

Values are reported as strings. Most properties support a query with "method": "get" and a setting with "method": "set"; the device answers on the report topic.

Over UART (sleep radar module)

The sleep radar module exposes a UART interface at 115200 bps, 8 data bits, 1 stop bit, no parity, 3.3 V TTL level.

The frame structure is:

Header   Control  Command  Length   Data     Checksum  Tail
0x53 0x59  1 Byte   1 Byte   2 Bytes  n Bytes  1 Byte    0x54 0x43

The checksum is the sum of the header, control byte, command byte, length bytes, and data, taking the low 8 bits.

Control byte 0x84 covers sleep monitoring. Within it, command 0x0C returns the comprehensive status, 0x0D returns the sleep report, 0x0E returns the sleep anomaly, and 0x10 returns the rating. Query commands are the same values with the high bit set, for example 0x8D to query the comprehensive status.

With Home Assistant

Because the radar publishes standard MQTT, it can be added to Home Assistant as an MQTT sensor. The practical approach is to subscribe to the report topic and map the fields you need. The comprehensive status report, arriving every 10 minutes, is usually enough for a dashboard; the full sleep report is best stored for history.

Where It Is Used

Home sleep tracking. One radar above the bed gives a nightly record of stages, durations, and score with nothing to wear and nothing to charge. This is the most common individual use.

Care facilities and nursing homes. A room without a camera still needs to know whether the occupant is in bed, how long they were out of bed, and whether the night was unusually short or long. The anomaly report covers the last case directly.

Hotels and long-stay apartments. Presence-based control of lighting and climate, with the sleep report available as an optional guest feature.

Solution integrators. The radar plus a broker plus a dashboard is a complete bed-side monitoring unit. The UART interface allows the same sensor to be embedded in a product without Wi-Fi.

What It Cannot Do

This section matters as much as the features.

It is not a medical device. It does not diagnose, treat, or prevent any condition, and its output must not be presented as a medical measurement.
It does not identify people. With two people in one bed the signals combine, and the stage judgement reflects the combined movement. Use one radar per bed, not per room.
It cannot see through metal. A metal bed frame, a metal headboard, or a metal lamp between the radar and the chest will degrade the signal.
It is sensitive to movement in the beam. A fan, a curtain, or a pet produces readings that look like a person. Installation is not optional.
A wrong angle produces unusable data. If the beam misses the chest, the breathing value will be absent or unstable long before the presence detection fails.
The score is a device index. It is computed from duration, stage proportions, movement, and breathing. It is not a health assessment and should not be compared with any clinical scale.
Breathing pauses are a raw count. The radar counts pauses in the waveform. It does not classify them, and no medical conclusion follows from the number.

Troubleshooting

Symptom	Possible Cause	Solution
No breathing value	Beam missing the chest	Adjust the angle or height; run the breathing test
	Metal object in the beam path	Remove or relocate the radar
	Person too far away	Move within 1.5 m for breathing detection
Breathing value unstable	Interference source in the beam	Remove fans, curtains, or pets from the area
Always reports out of bed	Radar too high or too far	Lower to 0.8–1 m above the bed, or use side-wall mounting at 1.8–2.2 m
Sleep stage never changes	Person not still for 10 minutes	Wait a full 10-minute window
	Radar in real-time mode	Set `reportMode` to 1 (sleep mode)
No sleep score	Session shorter than 4 h or longer than 12 h	Check the anomaly report instead
Waveform empty	Waveform reporting is off by default	Enable the waveform switch
Data cleared unexpectedly	Mode was switched	Do not switch modes during a session
False presence at night	Moving object in the beam	Remove the interference source

Specifications

Parameter	Value
Radar frequency	60 GHz
Beam angle	40° horizontal, 40° vertical
Housing size	80 × 80 × 51.8 mm
Supply voltage	4.5–5.5 V
Operating current	200 mA minimum
Power consumption	0.8 W minimum
Wireless	2.4 GHz Wi-Fi
Data output	MQTT over Wi-Fi (JSON), UART
UART	115200 bps, 8N1, 3.3 V TTL
Side-wall mounting height	1.8–2.2 m
Tilted mounting	30°–45° downward, 0.8–1 m above the bed
Breathing detection range	~1.5 m
Sleep and presence range	~2.5 m
Sleep stage interval	10 minutes
Sleep score range	0–100

Summary

The sleep monitoring radar reports presence in bed, breathing rate and state, heart rate, body movement, sleep stage, stage durations, and a sleep score, at fixed intervals from every second to every 10 minutes, with the full report published when the session ends.

Mount it above the bed head tilted 30°–45° at 0.8–1 m above the bed surface, or side-wall mounted at 1.8–2.2 m. Keep it within 1.5 m for breathing and 2.5 m for sleep and presence. Keep fans, air conditioners, moving curtains, metal, and pets out of the beam.

It is a consumer wellness device that records what happens at the bed side. It does not diagnose anything, and the quality of its data depends almost entirely on where and how it is installed.

Three mmWave Radar Specs That Are Almost Always Exaggerated

fuxinsuo — Sat, 17 Oct 2026 09:09:07 +0000

Anyone who has compared millimeter wave radar quotations has seen the same thing. A spreadsheet arrives with columns for detection angle, detection distance, and speed, and some rows look far better than the rest. Angles of 130° and 140°. Distances of 8 m and 10 m. Speed described only as "fast".

Most of those numbers are not achievable, and the reason is not commercial. They are blocked by antenna physics, transmit power, and processing capacity. This article sets out the practical limits for home and building millimeter wave radar, explains why each one cannot be moved by better algorithms, and gives a short checklist for reading a spec sheet.

Why Inflated Specs Hurt Everyone

An exaggerated specification is usually not written to mislead the buyer. It is written to exclude competitors. If the tender requires 140° of coverage, every honest supplier is disqualified before the comparison even starts.

The consequences land on all three parties:

The buyer receives hardware that does not meet the number it was purchased against, and has no recourse at acceptance because the specification was never achievable in the first place.
The honest supplier is filtered out by a threshold it could not meet without lying.
The vendor who signed the inflated specification ships a product that underperforms on site, and carries the warranty and reputation cost.

A spec sheet is a contract. Numbers that no hardware can reach do not protect the buyer; they only move the failure to a later date.

Limit 1: Detection Angle

A horizontal detection angle of 130° or 140° is common in tender documents. For a home or building mmWave radar it is not achievable.

A mmWave radar antenna — whether etched on a PCB or built as an AiP module — transmits into a bounded spatial region and listens for the return. Outside that region the signal is too weak to be useful. The geometry is set by the antenna, not by software.

The practical figures:

Measure	Value
Maximum angle per side	~60°
Absolute maximum total angle	~120°
Usable total angle	~100°

At 120° the mmWave radar is already working at the edge of the antenna pattern, where the signal is weak and the detection becomes unreliable. In practice, the usable angle is closer to 100°. Anything beyond that is either a specially designed antenna for a specific application, or a number that was written down rather than measured.

This applies to general chip-based solutions and PCB-based products, which is what nearly all home mmWave radars are. A finished home product does not exceed these figures.

This is an antenna limit, not an algorithm limit. No amount of signal processing creates energy that the antenna never radiated in that direction. A specification of 130° or 140° cannot be met by any supplier using standard hardware, which is precisely why writing it is an effective way to remove the competition — and precisely why it should not be written.

Limit 2: Detection Distance

A detection distance of 8 m or 10 m appears regularly in comparison tables. For a home mmWave radar, the reliable figure is around 6 to 7 m.

The reason is transmit power. Home mmWave radar antennas transmit at low power — a few dBm — because the product is meant to radiate as little as possible into a living space. That power sets the range at which a human target still returns a usable signal.

Increasing the range means increasing the power, and that creates a second problem. More power brings in more of everything else in the room: noise, clutter, and weak returns from distant objects. The mmWave radar then has to filter the clutter out while keeping the person, and those two requirements pull against each other. Push the range far enough and the mmWave radar either loses the person or keeps the clutter.

This has been measured repeatedly across many rooms. The consistent result is that 6 to 7 m is where a home mmWave radar reliably detects a person, and beyond that the margin disappears.

A distance of 8 m or 10 m is a theoretical figure. It may describe what the radio can do in an empty anechoic chamber. It does not describe what the product does in a room with furniture, a fan, and a curtain. If a product genuinely detected a person reliably at 10 m in a real room, its anti-interference performance would have to be extremely poor, because it would be reporting everything it received.

Limit 3: Speed

Speed is often listed as "fast" or omitted entirely. For a home mmWave radar detecting a person, the honest figure is that it handles movement up to roughly 3 m/s.

A home mmWave radar does far more than measure speed. It has to run the detection chain, extract targets, and perform point cloud and posture analysis on every frame. All of that computation takes time, and it limits how fast a moving target can be tracked reliably.

A speed-measuring radar has a simpler job: it measures speed and nothing else, so it can be very fast. A presence or fall radar also has to decide what the target is doing — standing, sitting, lying, falling — and that judgement is what caps the usable speed.

So a home mmWave radar is not the right instrument for tracking a fast-moving object, and any specification implying otherwise is describing a different product.

Why These Are Hardware Limits

The three limits share a structure. Each is fixed before any algorithm runs.

Parameter	Fixed by	Can an algorithm improve it?
Detection angle	Antenna size and array geometry	No — the energy was never radiated in that direction
Detection distance	Transmit power and signal-to-noise ratio	Partly, but only by trading away anti-interference
Speed	Frame rate and processing load	No — the computation has to happen before the result exists

The angle is set when the antenna is laid out. The distance is set when the transmit power is chosen. The speed is set when the processing budget per frame is allocated. By the time the detection chain receives a frame, all three are already decided.

This is why a supplier cannot sign a specification of 140°, 10 m, and high speed and then engineer around it later. The hardware does not support it, and no firmware release changes an antenna.

How to Evaluate a Spec Sheet

Six checks, in order of how quickly they eliminate a misleading claim.

Check the angle against 120°. Anything above 120° total is beyond standard antenna geometry. Anything above 130° is not achievable with a general-purpose mmWave radar.
Check the distance against 7 m. Ask what the test environment was. A distance quoted without a room description, an installation height, and a target description is a theoretical number.
Check the speed unit. If the specification says "fast" instead of a figure in m/s, ask for the figure. For home posture detection, expect something in the region of 3 m/s.
Ask for the test conditions, not just the number. Installation height, room size, target posture, and interference sources present. Two mmWave radars with the same quoted range can behave completely differently once these are stated.
Ask for a recorded test in the target scene. A short video of the mmWave radar running in a room of the size and shape you intend to deploy is worth more than any table.
Write the acceptance criteria as scenarios, not numbers. "Detects a lying person within 3 s in a 2 m × 3 m bathroom with the door closed" is verifiable. "10 m detection range" is not.

The last point matters most. A scenario-based acceptance criterion can be tested on delivery. A headline number usually cannot.

What We Publish Instead

The specifications we publish are the values we have measured, stated with the conditions they were measured under.

Detection angles are given as usable figures, not antenna-pattern extremes.
Distances are given for the scene the product is specified for, with the installation height that produces them.
Speeds are given as figures in m/s, with the posture analysis they assume.
Where a value depends on the scene — and most of them do — the article that covers it says so.

This costs us some rows in a comparison table. It also means that a mmWave radar bought against our specification behaves the way the specification said it would, which is the only outcome a procurement process is supposed to produce.

Summary

Three numbers in a millimeter wave radar specification are almost always inflated, and all three are fixed by hardware rather than by software.

The usable detection angle is around 100°, with 120° as the absolute maximum of a standard antenna. The reliable detection distance for a home mmWave radar is 6 to 7 m, because the transmit power is deliberately low and raising it destroys anti-interference. The usable speed for posture detection is around 3 m/s, because the processing budget per frame is spent on deciding what the target is doing.

None of these can be improved by a better algorithm, because the antenna, the power, and the frame budget are all decided before the algorithm receives a frame. A specification that asks for 140°, 10 m, and high speed is not asking for a better product. It is asking every honest supplier to disqualify itself.

Read a spec sheet for the test conditions behind each number. If the conditions are missing, the number is decoration.

How to Set Up Your mmWave Radar: MQTT and Wi-Fi Configuration

fuxinsuo — Sat, 17 Oct 2026 09:06:33 +0000

After receiving the radar, two things must be configured before it can send data: the MQTT connection and the Wi-Fi connection. The MQTT settings tell the radar where to send its data, and the Wi-Fi settings tell it how to reach your network. Both are configured once and stored inside the module.

This guide covers the complete setup for users outside China: preparing the MQTT environment, configuring the radar through its built-in web page, and connecting it to Wi-Fi with the Android configuration app. No serial cable and no WeChat account are required.

What You Need Before You Start

Item	Requirement	Notes
Android phone	Android 5.0 or later	The configuration app is Android-only; there is no iOS version
Wi-Fi network	2.4 GHz band	5 GHz / 5.8 GHz cannot be used
Wi-Fi password	Known	Needed in Step 4
MQTT broker	Address, port, ClientID, username, password	See Step 1
Configuration app	`BK_BLE5.apk` (2.35 MB)	Download link in Step 3
Power	5 V USB adapter	The module boots automatically when powered

Keep your phone's Wi-Fi switched on during the whole setup. You will connect it to the radar's own hotspot in Step 2 and back to your home network afterwards.

Step 1: Prepare Your MQTT Environment

The radar does not send data to a cloud service by default. It publishes everything to the MQTT broker you specify, so the broker has to be ready before the radar is configured.

What the Radar Needs

Field	Example	Limit
Server address	`tcp://broker.emqx.io:1883`	Up to 64 characters
ClientID	`radar-livingroom-01`	Up to 32 characters
Username	`radar`	Up to 32 characters
Password	your password	Up to 32 characters

Three points to check:

Use a plain TCP endpoint. The module is configured with a tcp:// address, so choose a broker endpoint that accepts plain TCP, normally port 1883.
Use a unique ClientID for every radar. Two devices sharing one ClientID will keep disconnecting each other.
Open the port. If the broker runs on a server outside your local network, make sure the port is reachable from the network the radar joins.

Broker Options

Option	Suitable for	Notes
Self-hosted (EMQX, Mosquitto)	Production and long-term use	Full control, needs a server or a home server
Managed cloud broker	Production without running a server	Check that a plain TCP endpoint is offered
Public test broker `tcp://broker.emqx.io:1883`	First test only	Anyone can read the data; never use it for real deployment

Write the four values down before moving on. You will type them into the radar in the next step.

Step 2: Configure MQTT on the Radar

The radar has a built-in web configuration page. This is the only place where the MQTT settings are entered — the Android app cannot do it.

Press and hold the button on the module for more than 10 seconds.
On your phone, open the Wi-Fi settings and connect to the hotspot named RadarConfig-xxxxxxxxxxxx (the last characters identify the device).
Open a browser and go to 192.168.0.1. The configuration page opens and shows the device ID plus empty MQTT fields.
Fill in the server address, ClientID, username, and password from Step 1.
Tap Modify to save. The page refreshes and shows the values you entered.
Tap Setup complete, exit. The module reboots and leaves configuration mode.

The settings are stored inside the module, so this step is done once. If you change the broker later, repeat Step 2.

Note: while the phone is connected to the RadarConfig hotspot it has no internet access. That is normal — the page is served by the module itself.

Step 3: Install the Configuration App

The radar is provisioned over Bluetooth. The WeChat mini-program used in China is not available outside China, so use the Android app instead.

Download BK_BLE5.apk (2.35 MB) from GitHub: https://github.com/249263431/Android_BK_BLE_WIFI_NEW_2024031901/blob/main/BK_BLE5.apk
If your phone asks, allow installing apps from this source (Settings → Apps → Special access → Install unknown apps).
Open the app. The main screen is titled Network Test and shows three fields: Bluetooth name, Wi-Fi name, and Wi-Fi password.

The app configures Wi-Fi only. It contains no MQTT settings, which is why Step 2 comes first.

Step 4: Connect the Radar to Wi-Fi

Press and hold the button for about 5 seconds, until the LED turns off, then release. The LED starts flashing: the module is now in provisioning mode.
Make sure the phone's Wi-Fi is on, and grant the location permission if the phone asks for it. Android requires it to scan for Bluetooth and Wi-Fi devices.
In the app, tap Choose bluetooth and select Radar_BLE from the list. If the list is empty, wait 10–20 seconds for the scan to finish.
Tap Choose SSID and select your 2.4 GHz network. Type the Wi-Fi password, and use Show Password to check what you typed.
Tap Start confguring network and wait. The whole process takes a few seconds.
When the app reports success, the radar is connected to your router and to your broker.

Two limits to remember:

2.4 GHz only. A 5 GHz / 5.8 GHz network cannot be used. If your router broadcasts both bands under one name, split the bands in the router settings or use a separate 2.4 GHz network.
90 seconds. If provisioning does not finish within 90 seconds it times out. Press and hold the button again to restart.

Note: every step in this section must be done while the LED is flashing. If the LED is not flashing, the attempt has failed and you need to start again.

Step 5: Verify the Connection

Check three things, in order:

Wi-Fi — the app reports a successful configuration.
Broker — subscribe with any MQTT client to the radar's report topic. The topic prefix depends on the model:

Model	Topic prefix
60 GHz sleep radar	`/Radar60SP/`
60 GHz fall radar	`/Radar60FL/`
24 GHz presence radar	`/RadarHP/`
24 GHz sleep radar	`/RadarSP/`
24 GHz fall radar	`/RadarFL/`

The full report topic is <prefix>/<DeviceID>/sys/property/post. The DeviceID is the value shown on the configuration page in Step 2. A healthy radar publishes JSON messages such as:

{"version": "1.0", "method": "post", "params": {"someoneExists": "1"}}

Data — the messages change when the state changes, for example when someone enters or leaves the room.

If Something Goes Wrong

Issue	Possible Cause	Solution
No `Radar_BLE` in the app list	Module not in provisioning mode	Press and hold the button for 5 s until the LED flashes
	Bluetooth or location permission denied	Grant both permissions and scan again
Provisioning times out	Wrong Wi-Fi band	Use a 2.4 GHz network
	Wrong Wi-Fi password	Re-enter the password and check it with Show Password
Cannot open `192.168.0.1`	Phone not connected to the `RadarConfig` hotspot	Reconnect to the hotspot and reload the page
Radar online but no data	Broker address, port, or credentials wrong	Repeat Step 2 and check every field
	ClientID already used by another device	Give every radar a unique ClientID
	Firewall blocking the port	Open the port or use a reachable broker
Bluetooth scan fails on Android 12 or later	Nearby devices permission not granted	Allow the "Nearby devices" permission for the app

Common Mistakes

Mistake	Result	Solution
Configuring Wi-Fi before MQTT	The app has no MQTT fields, so the broker is never set	Do Step 2 first
Using a 5 GHz network	Provisioning always fails	Use 2.4 GHz
Using the public test broker for real use	Data is visible to everyone	Use your own broker
Same ClientID on several radars	Devices disconnect each other	Use a unique ClientID per device
Assuming the app configures everything	The broker is never configured	Complete both steps

Summary

Setting up the radar takes two configurations and nothing else. Prepare the MQTT broker first and write down the address, port, ClientID, username, and password. Then press the button for 10 seconds, join the RadarConfig hotspot, and enter those values at 192.168.0.1. Finally, install BK_BLE5.apk, press the button for 5 seconds until the LED flashes, and send the radar your 2.4 GHz Wi-Fi credentials over Bluetooth.

Use 2.4 GHz Wi-Fi, a unique ClientID for every radar, and a broker you control. Once both steps are done, the radar publishes its data to your broker and the setup is finished.

Why mmWave Radar Takes Seconds to Respond

fuxinsuo — Sat, 17 Oct 2026 09:00:52 +0000

A common question from new users is why the radar feels slow. Breathing rate takes a while to settle. A fall is not reported the instant it happens. Heart rate seems to lag behind what the person is feeling. The suspicion is usually that the sensor is underpowered or the signal is weak.

The opposite is closer to the truth. The delay is the price of not reporting things that did not happen, and it is built into how millimeter wave radar processes a signal. This article explains where the delay comes from, which measurements are genuinely fast, and which are slow by design.

The Trade-off Behind Every Delay

Every millimeter wave radar faces the same choice on every frame: report now, or confirm first.

Report immediately and the reporting rate approaches one hundred percent — nothing is missed. It also means every shower, every squat to pick something up, and every curtain movement becomes an alarm. Report only after confirmation and the false alarm rate collapses, at the cost of a few seconds of latency.

Neither extreme is a product. A sensor that reports everything is unusable because nobody trusts it, and a sensor that reports nothing is unusable because it reports nothing. The delay you notice is the interval the radar spends deciding which side of that line an event falls on.

So latency is not a defect to be engineered away. It is the setting that decides how many false alarms you are willing to accept in exchange for how quickly a real event is published.

How a Second Is Built

The delay starts with how the radar divides time.

A second is split into ten intervals of 0.1 s. Each of those is split again into several sub-frames. The radar does not evaluate a single sub-frame in isolation — it averages across the sub-frames inside one 0.1 s window, and then across the 0.1 s windows inside a second.

Within each window the radar computes:

The average velocity of the target
The average movement amplitude
How many frames show the target approaching
How many show it receding
How many show large movement, and how many show small movement

Combining the 0.1 s windows is what produces a height change, a breathing amplitude, or a heart rate amplitude. Every one of those values is an average, not a measurement of one instant. An average needs several samples before it means anything, and that requirement is the origin of the delay.

Why Frames Drift

The radar transmits and receives continuously. It is closer to a machine gun firing frames than a camera taking one picture at a time, and that has a consequence: no two frames are identical.

Because the transmission is continuous and the target is moving, each frame captures the target at a slightly different phase. The result is a small drift between frames that is not signal and not noise — it is the geometry of sampling a moving object.

To keep the output stable, the radar does not trust a single frame. It recomputes across many frames and publishes only what survives the recomputation. That repetition is the second source of delay, and it is unavoidable: a value computed from one frame would jump around, and a value that jumps around is worse than a value that arrives late.

Why a Fall Takes Seconds

A fall is the clearest example of the trade-off, because the raw signal is unambiguous and the decision is not.

The radar sees the target collapse: a tall reflection at chest height becomes a wide, low reflection on the floor, within about a second. That alone is enough to raise an alarm, and raising it immediately would catch every fall.

It would also catch a person crouching to pick something up, a person sitting on the edge of the bathtub, and a person reaching for a towel on the floor. All of those produce the same collapse.

So the radar confirms before publishing. It checks whether the height change is sustained, whether the target stays low, and whether the posture persists across repeated detections. Only a target that is still down several seconds later is reported.

The finished unit applies fixed rules on top: a body held below 70 cm in a static posture raises the alarm after 30 seconds, and a person who stays completely still raises it after 5 minutes. The configurable fall duration covers everything in between.

That is why a fall takes seconds. The radar already knows something happened; it is spending those seconds making sure it happened to a person and not to someone bending over.

Why Breathing Takes Longer

Breathing has the same structure, plus one extra problem: the signal has natural gaps.

A human breath is not a smooth wave. It is an inhale, an exhale, and a pause, and the pause is the difficulty. During the pause there is no chest movement to measure, so the radar has to decide whether the person has stopped breathing or is simply between breaths.

A single pause is not enough information. The radar has to observe several complete breath cycles — inhale, exhale, pause — before it can establish a rate, and a full cycle takes several seconds. Only after seeing the same rhythm repeat does the published value settle.

This is why the breathing value arrives frequently but stabilises slowly. The radar publishes a number every few seconds from the very first frame, and that number keeps moving until enough cycles have been observed. A rate computed from two breaths is not a rate.

Heart rate follows the same logic, for the same reason: it is a rhythm with gaps, and a rhythm needs repetition before it means anything.

What Is Actually Fast

Not everything is delayed, and knowing which values are fast is useful when designing a system around the radar.

Data	Speed	Why
Body movement amplitude	Near real time, updates every second	A magnitude, not a rhythm — no averaging across cycles needed
Energy level	Near real time	The size of a change is measurable in a single frame
Human position	Within 1–2 seconds	A coordinate, not a pattern
Presence	Within 0.5 s of a person appearing	A state change, not a measurement
Motion status	Within 0.5 s	Same
Breathing rate	Several seconds to stabilise	Requires several full breath cycles
Heart rate	Several seconds to stabilise	Same
Fall alarm	Seconds, by design	Requires sustained-posture confirmation
Dwell alarm	Minutes, by design	Requires sustained stillness
Sleep stage	Every 10 minutes	Evaluated once per window

The pattern is simple. Anything that measures how much is fast. Anything that measures a rhythm or a decision is slow, because both require repetition before they can be trusted.

How to Work With the Delay

The latency is fixed by the detection chain, but a system can be designed around it.

Do not treat a single reading as final. Breathing and heart rate values move for several seconds before settling. Average them on your side, or display them with a settling indicator.
Separate fast signals from slow ones. Use presence and movement amplitude for anything that must feel instant — lighting, extractor fans, occupancy displays. Use breathing, heart rate, and sleep data only for trends and history, where a few seconds of delay is invisible.
Set the fall duration to the event, not to the fastest possible reaction. A short duration catches more real events and produces more false ones. A long duration does the opposite. The right value depends on how much a false alarm costs in your deployment.
Design the escalation path around the dwell alarm, not the fall alarm. The fall alarm is seconds. The dwell alarm is minutes, and it is the one that covers the person who does not fall but stops moving.
Expect the sleep stage to move in steps. It is evaluated once per ten-minute window, so it changes in steps rather than continuously. That is not lag; that is the reporting interval.

Summary

Millimeter wave radar divides a second into ten intervals of 0.1 s, averages across sub-frames and across intervals, and recomputes across many frames to remove drift. Every published value is the product of that averaging, and averaging takes time.

The delay is not a limitation of the sensor. It is the setting that decides how many false alarms you accept in exchange for how fast a real event is published. A radar that reported everything instantly would be useless, because nobody would believe it.

Movement amplitude, energy, and position are near real time, because they measure a magnitude. Breathing rate, heart rate, fall alarms, and dwell alarms take seconds to minutes, because they measure a rhythm or require a confirmed decision.

Design your system with that split in mind: fast values for anything that must respond immediately, slow values for anything that only needs to be right.

The Presence Detection Radar: Range, Sensitivity, and Scene Modes

fuxinsuo — Sat, 17 Oct 2026 08:57:02 +0000

The presence detection radar answers one question continuously: is there a person in this space, and are they moving or still. Unlike a PIR sensor, it detects a person who is sitting, standing, or sleeping without any movement at all. Unlike a camera, it produces no image and works in complete darkness.

This article covers the full range of this radar, how sensitivity and scene modes change what it sees, where to mount it, and how to read the output. All ranges, timings, and values are the ones used by the models sold in this store.

This is a consumer and commercial sensing device. It is not a medical device and does not diagnose, treat, or prevent any condition.

Two Variants, Two Protocols

This radar is available in two forms, and they use completely different protocols. Check which one you have before reading further.

Variant	Frequency	Interface	Protocol	Configuration
Presence radar module	24 GHz	UART only	Frame protocol at 115200 bps	Wired, no network setup
Presence radar	60 GHz	2.4 GHz Wi-Fi + MQTT	JSON property protocol over MQTT topics	Web page for MQTT, Android app for Wi-Fi

Both share the same sensing principle, so the outputs mean the same thing. The coverage, the commands, and the reporting details differ, and every value in this article is marked with the variant it belongs to.

The presence radar module is the bare sensing core for integrators who embed it in their own product; its output is described under Over UART. The presence radar is the finished ceiling-mounted unit that joins your network; its output is described under Over Wi-Fi and MQTT.

Setting up the presence radar, the Wi-Fi variant, is covered step by step in the setup guide. The module needs no network setup at all.

What This Radar Is

The presence radar is a 60 GHz millimeter wave sensor in a housing of approximately 29.5 × 73 × 86 mm, designed to be recessed into a ceiling. It is powered over USB at 5 V and covers a radius of about 2.7 m when ceiling-mounted, with a beam of 100° horizontal and 80° vertical. It is built for small to medium rooms: bathrooms, bedrooms, offices, and hotel rooms.

The presence radar module is a 24 GHz sensing core without the housing and without the Wi-Fi section. It is designed for ceiling mounting up to 2.75 m and covers a much wider area, up to about 12 m across for a moving person. It is intended for corridors, open-plan floors, and large rooms where one unit has to cover everything.

Both detect a stationary person. Both expose a body movement value from 0 to 100 that tells you not just whether someone is there, but what they are doing.

How It Detects a Person Who Is Not Moving

A PIR sensor needs movement. It reacts to a change in infrared pattern, so a person who sits still for a few seconds becomes invisible to it. That is why PIR lights switch off while you are still in the room.

A millimeter wave radar does not need movement. It transmits a continuous wave and analyses the echo, and a human body reflects that signal whether the person is walking, sitting, or asleep. Even a perfectly still person has a chest that rises and falls, and the radar resolves displacements far smaller than that.

The practical consequence is the timing:

Transition	Time to Report
No person to person present	Within 0.5 s
Person present to no person	About 40 s

The asymmetry is deliberate. Declaring a room occupied takes one glance, because a false negative leaves a light off or a room marked empty. Declaring it empty takes 40 seconds of confirmed absence, because the radar keeps checking for micro-movement and breathing before it commits. A PIR sensor has the opposite bias, which is why it gives up on you.

What It Measures

Presence

Value	Meaning
0	No person
1	Person present

Reported on change, within 0.5 s of a person appearing and about 40 s after the last confirmed trace disappears.

Motion Status

Value	Meaning
0	No movement
1	Still (static)
2	Active

Reported on change, within 0.5 s.

Approach and Leave Direction

The presence radar module also reports which way a person is moving relative to the radar:

Value	Meaning
1	No directional movement
2	Approaching
3	Moving away
4	Continuously approaching
5	Continuously moving away

Reported on change, roughly every 2 s while movement continues. This is the value that lets a corridor radar know which direction someone walked, without any camera.

Body Movement Level

A single value from 0 to 100. The presence radar module reports it every 5 s; the presence radar reports it every second over MQTT. The ranges have fixed meanings:

Value	Meaning
0 %	No person in range
1 %	Still: breathing only, no limb movement
2 %–30 %	Micro movement: small head or limb motion
31 %–60 %	Walking or fast limb movement
61 %–100 %	Running or large close-range movement

This is the most useful value for tuning an installation. In a room where someone is sitting at a desk, a correctly configured radar reports values in the 1 %–30 % band and never drops to 0.

Human Distance and Position

The presence radar module can report distance in centimetres and position as x, y, and z coordinates, both about every 2 s. Both are marked as non-critical functions with limited accuracy in the documentation. They are useful for debugging an installation, but they should not be the basis of a product feature.

Sensitivity

The presence radar module exposes a sensitivity setting from 1 to 10, with 7 as the default.

Range	Intended for
7–10	Low-interference spaces where fine motion must be caught: storage rooms, vaults
4–6	Ordinary indoor spaces: homes, hotels, offices (default)
1–3	Spaces with heavy interference: corridors, parking areas, where only large movement should trigger

Higher sensitivity catches smaller movements and also picks up more false triggers from curtains and fans. Lower sensitivity ignores a person who is barely moving.

Scene Mode

The presence radar module ships with seven scene modes. Each mode changes the trigger range, that is, the distance at which a moving person is detected:

Scene mode	Trigger range, wide angle	Trigger range, narrow angle	Static range
Maximum area	12 m	8 m	6 m / 4 m
Office	10 m	7 m	6 m / 4 m
Hotel (default)	9 m	6 m	6 m / 4 m
Living room	7 m	5 m	6 m / 4 m
Bedroom	4 m	3 m	6 m / 4 m
Zone detection	3 m	2 m	6 m / 4 m
Bathroom	1.8 m	1.5 m	6 m / 4 m

The static range is the same across modes; what changes is how far away a moving person is noticed. Choosing the smallest mode that still covers the room is the single most effective way to remove false triggers.

The presence radar exposes scene mode as an MQTT property, but with a different numbering: 0 default, 1 zone detection, 2 bathroom, 3 bedroom, 4 living room, 5 office, 6 hotel. Do not mix the two lists; they are different protocols.

Forced Unmanned

The presence radar module can force an unoccupied output after a fixed time, regardless of what it detects:

Value	Forced unoccupied after
0	Not used
1	10 s
2	30 s
3	1 min
4	2 min
5	5 min
6	10 min
7	30 min
8	60 min

Use this where a lingering signal is worse than a missed one, for example a meeting room that must be released for the next booking.

Reporting Rhythm

Data Point	Range	Reported
Presence	0 / 1	On change, 0.5 s in, ~40 s out
Motion status	0 / 1 / 2	On change, 0.5 s
Approach / leave	1–5	On change, ~2 s
Body movement	0–100	Every 5 s (module), every 1 s (radar)

Detection Range

Presence radar (60 GHz, ceiling-mounted)

Parameter	Value
Detection radius	~2.7 m
Beam, horizontal	100°
Beam, vertical	80°
Mounting	Recessed in ceiling

Presence radar module (24 GHz, ceiling-mounted)

Signal	Maximum distance
Moving person	~12 m
Sitting or micro-movement	~6 m
Sleeping person	~3 m

In practice, the covered area is approximately 8 m × 12 m for a moving person, 4 m × 6 m for a stationary person, and 3 m × 2 m for a sleeping person. The actual area is oval rather than circular.

Installation

Mounting

Both variants are ceiling-mounted. Mounting the module on a wall or at an angle changes the covered shape and is not supported.

For the presence radar module:

Mount horizontally, with the radar's long edge facing the room entrance so a person entering crosses the beam head-on
Keep the horizontal deviation within 3°
Mount at a height of 2.75 m or less
Keep the area in front of the radar clear of obstructions and covers

Tuning the Scene Mode and Sensitivity

The two settings work together, and the module documentation gives a clear procedure:

Compare the room area with the scene mode table and pick a starting mode.
Confirm where people actually spend time; the centre of that area is where the radar belongs.
Find the room entrance and aim the radar's long edge at it.
Check the detection area for interference sources.
If interference exists, shrink the trigger range by moving to a smaller scene mode.
Decide the starting sensitivity from the room type.
If the room is small (15 m² or less), reduce the sensitivity by one step. Small rooms strengthen reflections, so lowering sensitivity keeps the unoccupied judgement stable.
If the room is large (40 m² or more), raise the sensitivity by one step. Large rooms weaken reflections, so raising sensitivity keeps the occupied judgement stable.

When the entrance trigger and the interference resistance conflict, the documentation recommends protecting interference resistance first. A radar that occasionally triggers late is better than one that reports a person who is not there.

What Interferes

Avoid aiming the radar at:

Electric fans
Air conditioners (the internal motor causes false detection)
Curtains that move with air flow
Metal objects
Water pipes or flowing water
Pets moving in the area

What the Signal Passes Through

The signal is not blocked by:

Clothing
Curtains
Thin wooden boards
Glass

Getting the Data Out

Over Wi-Fi and MQTT (presence radar)

The presence radar uses a set of topics per function rather than one pair:

Topic	Direction
`/RadarHP/{DeviceID}/sys/online/post`	Device reports online / offline
`/RadarHP/{DeviceID}/sys/version/post`	Device reports version information
`/RadarHP/{DeviceID}/sys/property/set`	You send settings
`/RadarHP/{DeviceID}/sys/property/set_reply`	Device answers a setting
`/RadarHP/{DeviceID}/sys/active/post`	Device reports fast-changing values
`/RadarHP/{DeviceID}/sys/passive/post`	Device reports configuration values

The main properties:

Property	Meaning	Access
`online`	0 offline, 1 online	post
`radarID`	Device identifier	post, get
`softwareVersion`	Software version	post, get
`firmwareVersion`	Firmware version	post, get
`protocolVersion`	Protocol version	post, get
`movementSigns`	Body movement, 0–100	post
`keepAway`	1 none, 2 approaching, 3 leaving, 4 continuous approaching, 5 continuous leaving	post
`environ`	0 unoccupied, 1 occupied still, 2 occupied moving	post
`thresholdGear`	Sensitivity, 0–9	post, set
`sceneMode`	0 default, 1 zone, 2 bathroom, 3 bedroom, 4 living room, 5 office, 6 hotel	post, set
`forceIntoUnmannedGear`	Forced unoccupied, 0–8	post, set

Values are strings. Settings are sent with "method": "set" to the property set topic, and the device answers on the set reply topic.

Two control commands apply to the fast-changing values:

"method": "control" turns individual reports on or off. A value of 1 allows the report, 0 forbids it. Note that this is the opposite of the convention used by the 60 GHz radars, where 1 means forbidden.
"method": "control_qos" sets the quality of service per topic, using keys such as Qos_movementSigns, Qos_keepAway, and Qos_environ. The default is QoS 1.

Over UART (presence radar module)

The presence radar module exposes a UART interface at 115200 bps, 8 data bits, 1 stop bit, no parity, 3.3 V TTL level.

Header   Control  Command  Length   Data     Checksum  Tail
0x53 0x59  1 Byte   1 Byte   2 Bytes  n Bytes  1 Byte    0x54 0x43

The checksum is the sum of the header, control byte, command byte, length bytes, and data, taking the low 8 bits.

Control byte 0x80 covers human presence. Command 0x01 reports presence, 0x02 reports motion status, 0x03 reports the body movement value, 0x04 reports distance, and 0x05 reports position. Query commands are the same values with the high bit set, for example 0x81 to query presence.

The module also has two hardware outputs that need no protocol at all:

Pin	Output
S1	High = person present, low = no person
S2	High = active, low = still

Both are 3.3 V logic, so a microcontroller can read presence directly without parsing any frame. GP1 to GP4 are parameter selection pins that can be redefined for your own use.

Where It Is Used

Bathrooms and small rooms. One 60 GHz unit covers a bathroom reliably, including a person sitting still on the toilet, which a PIR sensor misses entirely. This is the most common single use: occupancy-based lighting and extractor fans.

Corridors and open-plan floors. The 24 GHz module covers up to 12 m, so one unit watches a whole corridor or an open office, including which direction people walk.

Meeting rooms and desks. Presence plus the movement level distinguishes a room that is genuinely empty from one where someone is quietly working, which is exactly the distinction PIR-based systems get wrong.

Hotels. Occupancy-based climate and lighting control, with no camera in the room and nothing for the guest to object to.

Integrators. The module's S1 and S2 outputs give a two-wire presence signal for products that have no network at all.

What It Cannot Do

It is not a medical device. It reports occupancy and movement. It does not diagnose, treat, or prevent any condition.
It cannot count people reliably. It reports whether at least one person is present, not how many. Two people in the area read the same as one.
It cannot identify people. There is no way to tell who is in the room from the radar output alone.
It cannot see through metal. A metal ceiling panel, a metal light fitting, or a metal cabinet between the radar and the person will degrade or block the signal.
It does not react instantly to an empty room. The 40-second unoccupied delay is built in. A system that needs a room marked empty in 2 seconds will not get it from this radar without forcing it.
High sensitivity is not free. Catching a person who is barely moving also means catching a curtain that is barely moving.
Scene mode is not cosmetic. Leaving a large mode on a small room is the most common cause of a radar that reports people who are not there.

Troubleshooting

Symptom	Possible Cause	Solution
Reports unoccupied while someone sits still	Sensitivity too low	Raise the sensitivity by one step
	Radar too far from the person	Check the scene mode range against the room
Reports occupied in an empty room	Scene mode too large for the room	Move to a smaller scene mode
	Interference source in the beam	Remove fans, curtains, or pets from the area
Person entering is not detected	Radar's long edge not facing the entrance	Re-aim the long edge at the door
Unoccupied state flickers	Room too small for the sensitivity	Reduce sensitivity by one step
Movement value stuck at 0	Person outside the detection area	Move the radar or reduce the scene mode
No data over MQTT	Report forbidden by the control command	Check the `control` settings and the QoS values

Specifications

Presence radar (60 GHz)

Parameter	Value
Radar frequency	60 GHz
Detection radius	~2.7 m
Beam angle	100° horizontal, 80° vertical
Mounting	Recessed ceiling mount
Supply	5 V over USB
Housing size	29.5 × 73 × 86 mm
Wireless	2.4 GHz Wi-Fi
Data output	MQTT over Wi-Fi (JSON)

Presence radar module (24 GHz)

Parameter	Value
Radar frequency	24 GHz
Beam angle	90° horizontal, 60° vertical
Mounting	Ceiling, horizontal, deviation ≤ 3°
Mounting height	2.75 m or less
Moving person range	~12 m
Static or micro-movement range	~6 m
Sleeping person range	~3 m
Presence response	Within 0.5 s
Unoccupied confirmation	About 40 s
Body movement reporting	Every 5 s
Sensitivity	1–10, default 7
Scene modes	7
Hardware outputs	S1 presence, S2 motion, 3.3 V logic
Data output	UART, 115200 bps, 8N1, 3.3 V TTL

Summary

The presence detection radar reports whether a space is occupied and whether the person is still or moving, within 0.5 s of someone appearing and after about 40 s of confirmed absence. It detects a stationary person, which is the one thing a PIR sensor cannot do.

The 60 GHz presence radar covers about 2.7 m from a ceiling and suits bathrooms, bedrooms, and offices. The 24 GHz presence radar module covers up to 12 m and suits corridors and open floors, and it can report presence on two hardware pins with no protocol at all.

Mount it horizontally, aim the long edge at the entrance, choose the smallest scene mode that still covers the room, and set the sensitivity to match the room size. Keep fans, air conditioners, moving curtains, and metal out of the beam, and the radar will hold a stable occupied or unoccupied state for years.

How mmWave Radar Works: From FMCW to Breathing Detection

fuxinsuo — Sat, 17 Oct 2026 08:50:42 +0000

Millimeter wave radar detects human presence, breathing, heart rate, body movement, and sleep stages without any physical contact. It does not need a camera, and the person does not need to wear anything. This makes it a practical sensing technology for homes, elderly care, hotels, and offices.

This article explains how millimeter wave radar works, starting from the FMCW principle, and why the 60GHz band is able to detect chest movement smaller than one millimeter. It also compares millimeter wave radar with PIR sensors, cameras, and wearable devices.

What Is Millimeter Wave Radar

Millimeter wave refers to electromagnetic waves with a wavelength between 1 mm and 10 mm, which corresponds to a frequency range of roughly 30 GHz to 300 GHz. It is simply a segment of the electromagnetic spectrum, in the same way as infrared or visible light.

Millimeter wave has three useful properties for indoor sensing:

Large bandwidth, which allows fine resolution
Narrow beam, which allows accurate direction finding
Good penetration through smoke, dust, and non-metallic materials

For indoor presence detection, sleep monitoring, and fall detection, 60 GHz is the most widely validated and cost-effective choice. At 60 GHz the wavelength is approximately 5 mm, which is short enough to build a compact antenna array and fine enough to resolve small targets.

How mmWave Radar Works: The FMCW Principle

Most indoor millimeter wave sensors use FMCW (Frequency Modulated Continuous Wave). Instead of sending a short pulse, the radar transmits a continuous signal whose frequency sweeps linearly up and down over time. The processing chain has five steps.

1. Transmit

The radar transmits a 60 GHz FMCW chirp through its antenna array. Because the wavelength is only about 5 mm, the antenna can be small enough to fit inside a ceiling-mounted housing.

2. Reflect

The wave hits the target and part of the energy is reflected back. The echo carries information about range, velocity, and angle. A human chest reflects the signal continuously, even when the person is completely still, because breathing moves the chest wall.

3. Receive

The received echo is mixed with the transmitted signal. The mixing produces a beat frequency that is proportional to the target range. The signal is then filtered and sampled by an ADC.

4. Digital Signal Processing

An FFT separates targets in the range domain, and Doppler and phase differences reveal velocity and micro-movement. This is the step that separates a real human from a moving curtain: a curtain has movement but no stable phase structure or breathing rhythm.

5. Output Application Data

The processed result is published as application data: presence status, body movement level, human distance, breathing rate, heart rate, sleep stage, or fall alarm.

Why 60GHz Can Detect Breathing

Breathing moves the chest wall by less than 1 mm. Detecting this requires very fine range resolution and a stable phase reference, and this is where the 60 GHz band performs well.

The reasons:

Wavelength of approximately 5 mm gives centimeter-level range resolution
Narrow, focused beam concentrates energy on the chest area
High sensitivity to micro-motion compared with the 24 GHz band
Small antenna size, which allows compact product design

For comparison, the 24 GHz band has a wavelength of about 12.5 mm, which makes it less sensitive to micro-motion and requires a larger antenna. 24 GHz radar is well suited to presence detection over a wide area, while 60 GHz radar is the better choice when breathing, heart rate, or sleep stages are required.

What mmWave Radar Can Detect

Signal	What It Measures	Typical Range	Report Frequency
Human presence	Occupied / unoccupied	Up to several meters	On change
Motion status	Static / active	—	On change
Body movement	Movement level 0–100	—	Every 1 s
Human distance	0–65535 cm	Non-critical function	Every 2 s
Breathing rate	0–45 breaths/min	~1.5 m	Every 3 s
Heart rate	50–120 bpm	~1.5 m	Every 3 s
Sleep stage	Awake / light / deep	~2.5 m	Every 10 min
Sleep score	0–100	—	On sleep end
Fall alarm	Fall detected	~2.5 m	On change
Dwell alarm	Static dwell detected	~2.5 m	On change

Body Movement Levels

The movement parameter is reported as a value from 0 to 100, with fixed meaning:

Value	Meaning
0%	No person in range
1%	Still (breathing only, no limb movement)
2%–30%	Micro movement (small head or limb motion)
31%–60%	Walking or fast limb movement
61%–100%	Running or large close-range movement

Sleep Stages and Sleep Score

While a person is in bed, the radar evaluates the sleep stage every 10 minutes and reports awake, light sleep, or deep sleep. When the sleep session ends, it reports a sleep score from 0 to 100:

Score	Rating
1–60	Poor
61–75	Fair
76–100	Good

The sleep report includes total sleep duration, awake / light / deep percentages, time out of bed, number of times out of bed, turn count, average breathing rate, average heart rate, and apnea count.

The radar also reports sleep anomalies:

Sleep duration shorter than 4 hours (insufficient sleep)
Sleep duration longer than 12 hours (excessive sleep)
No presence detected for 30 minutes while the person should be in bed

mmWave Radar vs PIR, Cameras, and Wearables

Technology	Detects a Stationary Person	Works in Darkness	Measures Breathing	Privacy Risk	Wearing Required
PIR sensor	No	Yes	No	None	No
Camera	Yes	Needs infrared	No	High	No
Wearable device	Yes	Yes	Yes	Low	Yes
mmWave radar	Yes	Yes	Yes	None	No

A PIR sensor only reacts to movement, so a person sitting still or sleeping is invisible to it. A camera captures images, which raises privacy concerns in bedrooms and bathrooms and needs infrared illumination in the dark. A wearable device measures breathing well, but it must be worn and charged, and many users stop wearing it after a few weeks.

Millimeter wave radar has none of these limitations, and it produces no image data at all. The output is a set of numbers.

What Penetrates and What Blocks the Signal

Millimeter wave passes through most non-metallic materials. It also reacts to any movement inside the detection area.

Penetrates without affecting detection:

Clothing and blankets
Curtains
Thin wooden boards
Glass

Causes interference or false alarms:

Electric fans (moving blades)
Air conditioners (internal motor)
Curtains moving with wind
Metal objects in front of the antenna
Flowing water and water pipes
Pets moving inside the detection area

Note: Do not aim the radar directly at an air conditioner, or install it facing the same direction as the air flow. The internal motor causes false detection.

Where mmWave Radar Is Used

Home sleep monitoring: nightly breathing, heart rate, and sleep score without wearing a device
Elderly care and nursing homes: fall alarm, long absence from bed, reduced activity over several days, no cameras in rooms
Bathrooms: low posture detection and fall alarm in wet environments where a camera is unacceptable
Hotels and offices: presence-based lighting and HVAC control, occupancy statistics
Smart home platforms: standard MQTT integration, including Home Assistant auto-discovery

Common Misconceptions

Misconception	Reality	Solution
"It is just a motion sensor"	It resolves chest displacement below 1 mm through phase analysis	Aim the main beam at the chest area
"60GHz and 24GHz are the same"	60GHz is far more sensitive to micro-motion and needs a smaller antenna	Use 60GHz for breathing, heart rate, and sleep
"Higher sensitivity is always better"	High sensitivity picks up curtains, fans, and pets	Match sensitivity to room size and interference
"It cannot work through a blanket"	Non-metallic materials do not block the signal	Keep metal away from the antenna face
"A camera gives better data"	Cameras fail in darkness without infrared and create privacy risk	Use radar where privacy matters

Getting Reliable Data

Signal quality depends mostly on geometry. For a sleep monitoring radar:

Identify the main sleep area and the bed head position.
Mark a point 0.8–1 m above the bed surface on the wall or ceiling.
Tilt the radar downward at 30°–45°.
Make sure the main beam covers the chest area of the person lying on the bed.
Check the detection area for interference sources and remove them.
Fix the radar in place, power it on, and verify the data.

Testing After Installation

Lie on the bed in a normal sleeping position.
Stay still for at least 10 minutes.
Check that breathing rate and heart rate are reported.
Check that the sleep stage changes from awake to light sleep.
If the data is unstable, adjust the tilt angle or the installation height.

A simple test: confirm that the breathing waveform is visible in the app. If the waveform is flat or missing, the radar is not aimed at the chest correctly.

Summary

Millimeter wave radar uses FMCW to transmit a sweeping 60 GHz signal, mixes the echo with the transmitted signal to obtain range, and uses FFT and phase analysis to extract micro-movement. At a wavelength of about 5 mm, it resolves chest displacement below 1 mm, which makes breathing rate, heart rate, and sleep stages measurable without contact.

Keep three points in mind: use the 60 GHz band for breathing and sleep, keep the radar within 1.5 m for breathing detection and 2.5 m for sleep and presence detection, and keep fans, air conditioners, moving curtains, and metal out of the beam.

A radar that is correctly aimed produces stable data. If the numbers look unstable, check the installation position and angle first.

Bathroom Version or Bedroom Version? Why One Fall Radar Cannot Cover Both

fuxinsuo — Sat, 17 Oct 2026 08:47:56 +0000

A fall detection radar is built to answer one question: has the person in this room ended up on the floor when they should not be. In a bathroom, that question has a clear answer, because the only normal postures are standing and sitting. In a bedroom, the same question has the opposite answer, because lying down is the normal state for most of the night.

Those two rooms need opposite logic, so this radar ships in two versions: a bathroom version and a bedroom version. They are not interchangeable, and using the wrong one produces either false alarms or missed events.

This article explains what each version is tuned for, why the two cannot be merged into one, and how to choose.

Why These Two Scenes, and Only These Two

A public area can be covered by a camera and by staff. A bedroom and a bathroom cannot, and those are precisely the two rooms where an elderly person is most likely to be alone and most likely to fall.

So the problem is not "detect falls everywhere". It is "detect falls in the two rooms where a camera cannot go and where nobody is watching". Both of those rooms are small, enclosed, and have a predictable layout. That is what makes radar-based sensing practical in them.

It is also what makes them different from each other.

The Bathroom Version: One Door, Known Path

A bathroom has no bed. The normal postures are standing and sitting, and anything lower is a problem. That gives the bathroom version a simple rule: a low posture is an event.

The version watches for four conditions:

Condition	What It Means
Lying down	The person is on the floor
Sitting down and not getting up	A collapse onto the toilet or the floor
No movement for a prolonged period	The person has stopped moving entirely
In the room for too long	The person has not left within the expected time

Any one of these raises an alarm.

What makes this reliable is the door. A bathroom has one, and the person enters and leaves through the same one. The radar therefore knows when someone arrived, and knows when the room is empty. That single fact resolves most of the interference in the room: a washing machine, a flushing toilet, or a shower curtain settling after the person has gone can all be discarded, because the radar already knows nobody is inside.

The height and movement-amplitude measurements that radar provides natively do the rest. A tall target becomes a wide, low target, and that transition is the fall.

The Bedroom Version: Inside the Bed vs Outside the Bed

A bedroom has a bed, and that changes everything. Lying down is the normal state for eight hours a night. A radar that treated a low posture as an event would alarm continuously from the moment the person got into bed.

So the bedroom version inverts the rule: inside the bed is normal, outside the bed is an event.

The bed, and any sofa or low platform in the room, is excluded from the monitored zone. Everything else in the room is monitored in full. A person who gets out of bed and collapses on the floor, slips while standing beside the bed, or falls against a wardrobe is detected immediately. The same person turning over, sitting up, or lying still in bed produces nothing.

This is the distinction the bathroom version does not need to make. A bathroom has no bed, so nothing has to be carved out. A bedroom has one, and failing to carve it out would make the product unusable.

Why the Two Cannot Be Merged

The two versions need opposite conclusions from the same measurement.

	Bathroom Version	Bedroom Version
Low posture	An event, reported	Normal inside the bed, ignored
Long stillness	An event, reported	Normal inside the bed, ignored
Key structural feature	The single door	The bed
Zone that must be excluded	Interference sources	The bed and any low furniture
Detection area and zone precision	Tuned for a small wet room	Tuned for a bed plus its surroundings

A single set of parameters cannot satisfy both. Tune it for the bathroom and it alarms all night in a bedroom. Tune it for the bedroom and it misses a collapse on a bathroom floor. The height signal is identical in both rooms; the required answer is opposite.

This is why the product ships as two versions rather than one version with a mode switch, and why the difference is not a firmware setting that a user can change.

Zero Configuration

Neither version requires the user to mark anything.

The user does not define the bed position, the door position, the room boundary, or the monitored zone. Each version ships with its zone logic already configured for the scene it is built for. Mount it, power it on, and it is working.

That is deliberate. Asking a user to draw a bed outline on a floor plan introduces two failure modes at once: the setup is difficult for the people most likely to buy this product, and an incorrectly drawn zone silently removes the protection they paid for. A zone that is drawn slightly too small is worse than no zone at all, because it looks like it is working.

Both versions are configured at the factory for the scene they serve. The only thing the user chooses is which room the radar is going into.

What Happens If You Use the Wrong Version

The two failure modes are symmetric, and both are predictable.

Bathroom version installed in a bedroom. The radar has not been told that a bed exists, so a person lying in bed is a low posture that persists. The result is a fall alarm within minutes of the person going to sleep, repeated every time they turn over. In a room with a tatami platform or a floor mattress, the same thing happens the moment someone lies down to rest.

Bedroom version installed in a bathroom. The radar has been configured to ignore low, persistent targets inside an excluded zone. A person who sits down on the toilet and does not get up, or who collapses and stays down, may fall inside that excluded logic and never be reported.

Neither behaviour is a defect. Both are the direct consequence of asking one version to work in the room the other version was built for.

Which Version Do You Need

Installing in a bathroom, shower room, or toilet — use the bathroom version.
Installing in a bedroom, to monitor someone getting out of bed — use the bedroom version.
Covering both rooms — order one of each. They are separate units for separate rooms, and one unit cannot serve both.
Installing anywhere else — this radar is not the right product. For corridors, living rooms, and open spaces, use a presence radar instead.
Not sure which room your installation matches — describe the room, or send a photo and the room dimensions, before ordering. It takes a message and prevents a return.

The short version: the bathroom version goes in the room with a toilet, and the bedroom version goes in the room with a bed.

What Neither Version Does

Neither is a medical device or an emergency service. Both publish alarms to your MQTT broker. Delivering a notification to a person is done by your own system.
Neither achieves a zero missed-event rate. The design target is the highest practical reporting rate in the intended scene. No sensor of this type eliminates missed events.
Neither eliminates false alarms. Tuning reduces them. The scene is what removes most of them.
Neither replaces human checks. For anyone at real risk, this is an addition to a care routine, not a substitute for one.
Neither works in an open space. Both are specified for a small enclosed room.
A tatami platform, a floor mattress, or a low bed needs a conversation first. If the sleeping surface is at floor level, tell us before ordering so the right version and the right mounting position can be confirmed.

Summary

A fall detection radar has to decide whether a low posture is normal. In a bathroom it never is, so the bathroom version reports it immediately and uses the single door to know when the room is empty. In a bedroom it usually is, so the bedroom version excludes the bed and monitors everything outside it.

Those are opposite requirements, which is why the product ships in two versions, why the zone logic is fixed at the factory, and why the user never has to mark anything.

Choose by room: the bathroom version for the room with a toilet, the bedroom version for the room with a bed. Using the wrong one produces either an alarm every time the person lies down, or no alarm at all when they fall.

Further detail on the alarm fields, timing parameters, and MQTT properties is in the companion article The Fall Detection Radar: How Alarms Work, How to Tune Them, and What to Expect.

Why the Same Fall Radar Behaves Differently in a Bathroom and an Open Office

fuxinsuo — Sat, 17 Oct 2026 08:42:24 +0000

A customer mounts a fall detection radar in an office corner, walks around, lies down on the floor, and gets a reliable alarm. Another customer mounts the same radar in a bathroom and gets a different result. Neither radar is faulty. The radar is tuned for one of those two rooms.

This article explains what "tuned for the bathroom" actually means, which three design decisions depend on it, and what changes when the radar is moved to an open space. It is written for anyone evaluating this radar, and for anyone who has tested it somewhere other than a bathroom and wondered why the behaviour changed.

Why We Optimize for the Bathroom

A bathroom is a small, enclosed room with a single door, hard reflective surfaces, and a handful of predictable moving objects. That combination is unusual, and it cuts both ways.

The same properties that make a bathroom difficult — tiled walls, a waterproof floor, a toilet, an extractor fan, a shower curtain — also make it possible to tune a radar very precisely for it. A room of roughly 2 m × 3 m, about 5 to 6 m², with one door and hard walls, gives the radar a bounded area with a known entry and exit path.

So the tuning is not a limitation added to the product. It is a set of deliberate design decisions that only work because the room has that shape.

Interference Sources in a Bathroom

Four things in a typical bathroom produce radar returns that resemble a person.

Source	Why It Causes a False Reading
Washing machine	A low, vibrating target can resemble a collapsed posture
Toilet flushing	The signal passes through tile; the changing water surface produces a strong return
Shower curtain or towel moving in air flow	A moving soft target looks similar to a moving person
Extractor fan vibration	Continuous micro-movement disturbs the stillness judgement

Each of these has a different signature. A washing machine is low and constant. A flushing toilet produces a brief, strong return from a fixed position. A curtain moves without a consistent phase structure. A fan vibrates at a fixed frequency.

A general-purpose sensor sees all four as ambiguous. A sensor tuned for the room can be told what to expect.

How Entry and Exit Direction Suppresses False Alarms

This is the most important of the three design decisions, and it is the one that stops working first when the radar leaves a bathroom.

The radar tracks which direction a person enters and leaves through. In a bathroom there is exactly one door, so the entry and exit paths are known and short. That single fact is enough to resolve most of the interference table above.

Here is the logic:

A person enters through the door. The radar registers an entry event.
While the person is inside, movement, presence, and posture are evaluated normally.
When the person leaves through the same door, the radar registers an exit event.
From that moment, reports from the room are suppressed for a defined window.

Step 4 is the key. Most false alarms in a bathroom happen at the moment of leaving: the toilet flushes after the person has gone, the curtain settles, the washing machine starts its spin cycle. Without the exit event, the radar has no way to know those returns are not a person on the floor. With it, they are simply discarded.

A washing machine that was a problem all day stops being a problem, because the radar knows nobody is in the room.

Why an Open Room Breaks This Logic

The suppression window depends on there being one door. Remove the door, or add a second one, and two different failures appear.

Failure one: the radar keeps reporting a person who has left. In a corridor or an open office, a person enters from one side and leaves from another. The radar sees an entry without a matching exit, cannot conclude that the room is empty, and continues to treat the space as occupied. The state that should have cleared does not clear.

Failure two: the radar clears a room that still has someone in it. In a busy space, several people enter and leave through different paths. The radar concludes that the occupancy has ended and clears the state to unoccupied, while a person is still inside. The result is the opposite error: someone is present, and the radar reports nobody.

Neither failure is a defect. Both are the direct consequence of applying a single-door assumption to a room with no doors.

This is why the radar is specified for bathrooms and similar small enclosed rooms, and not for corridors, open-plan offices, or any space where people enter and leave through different paths.

Signal Strength: Why Reflections Help

The second design decision is counter-intuitive: the radar performs better in a bathroom than in an empty room, and the reason is the tiling.

A bathroom is full of hard, flat, reflective surfaces. Tile walls, a glazed floor, and waterproof membranes create strong multi-path reflections, and the radar receives the same target through several paths at once. In a bathroom, that means the return from a person lying still is strong and stable.

The same reflections also create what can be called dry interference: returns that arrive from fixed structures rather than from a person. The detection chain filters those out, so the useful signal from the person is kept and the structural returns are removed. The room is reflective enough to give a strong signal, and the filtering is tuned to know which reflections to ignore.

An open room does not have that property. Fewer surfaces, longer distances, and absorptive materials such as carpet, fabric, and plasterboard mean weaker returns and fewer of them. A person lying completely still in an open area produces a weaker signal than the same person in a tiled bathroom, because there is simply less energy coming back.

So an empty office is not a cleaner test environment. It is a different one, with less signal to work with.

Geometry: Why the Range Never Misses in a Bathroom

The third design decision is about shape rather than signal.

A bathroom is bounded. Walls on all sides, a typical floor area of 2 m × 3 m, and a ceiling height of 2.2 to 2.8 m. A fallen person is over a metre long, so within that space a fall lands well inside the detection area. The walls do the bounding for free: there is nowhere in the room for a body to fall outside the covered zone.

An open area has no such boundary. A person can fall with their feet inside the detection area and their torso outside it, or fall just beyond the edge of the coverage. The radar reports what it can see, and what it can see is a partial target at the edge of range.

The detection area of this radar is approximately 3 m × 2 m for a low posture and 3 m × 2.5 m for fall and dwell detection. In a bathroom of 2 m × 3 m, that covers the whole floor. In an open room of the same size or larger, it covers part of it.

This is the difference between a radar that is specified for a room and a radar that is specified for an area. This product is specified for a room.

Periodic Re-Detection and Reporting Rate

Every millimeter wave radar faces the same trade-off. Reporting an event immediately risks reporting it wrongly; waiting to confirm risks missing it entirely.

The standard answer is periodic re-detection: the radar re-examines the target at fixed intervals rather than deciding once. A posture that persists across several consecutive checks is reported; one that does not is discarded. This is what raises the reporting rate, and it is also what keeps the false alarm rate down, because a transient return does not survive the re-checks.

Two parameters control the balance:

Fall duration — how long the posture must persist before the alarm is published. Shortening it catches more events and produces more false ones; lengthening it does the opposite.
Dwell duration — the same idea applied to a person who has stopped moving without falling.

In a bathroom, the entry and exit information removes most of the false candidates before the re-detection stage even runs, so the periodic checks can be tuned aggressively for sensitivity. In an open room, the false candidates are never removed, so the same tuning produces alarms that the re-checks then have to reject.

The result is a radar that feels responsive in the intended scene and hesitant outside it.

How to Test It Properly

If you are evaluating this radar, test it in the environment it is designed for. A bathroom-like setup takes twenty minutes and removes every variable discussed above.

Build or use a space of roughly 2 m × 3 m, with walls on all sides.
Fit a single door, and use it for every entry and exit during the test.
Mount the radar on the ceiling at 2.2 to 2.8 m, sensor face pointing straight down, above the area where a person would fall.
Enter through the door, move around, and leave through the same door. Confirm the presence state follows you.
Test a fall with a real lying posture, held still. Confirm the alarm arrives within the configured fall duration.
Test a dwell: lie still without falling, and confirm the dwell alarm arrives after the configured dwell duration.
Introduce one interference source at a time — a running extractor fan, a hanging cloth, a filled container — and confirm it does not produce an alarm while nobody is in the room.
Leave the room and confirm the state clears, then confirm that subsequent interference does not raise an alarm.

If the radar passes those eight steps in a room of that shape, it will behave the same way in a real bathroom. If it is tested in a corridor instead, steps 4 and 8 will fail for the reasons described above, and the result will not predict the real-world behaviour.

What This Radar Is Not

It is not a general-purpose presence sensor. It is tuned for a small enclosed room with one door. For corridors and open spaces, use a presence radar instead.
It does not achieve a zero missed-event rate. The design target is the highest practical reporting rate in the intended scene, and the tuning is directed at reducing missed events there. No sensor of this type eliminates them.
It will produce false alarms outside the intended scene. Entry and exit suppression is what removes them, and that mechanism requires a single known door.
It is not a medical device and not an emergency service. It publishes alarms to your MQTT broker. What happens next — a notification, a call, a dashboard entry — is built by your own system.
It does not replace human checks. For anyone at real risk, it is an addition to a care routine, never a substitute for one.

Summary

This radar is tuned for a bathroom, and the tuning rests on three things: a single door that makes entry and exit known, reflective surfaces that give a strong return which the detection chain then filters, and walls that bound the detection area so a fall cannot land outside it.

Move it to an open office and all three weaken at once. The entry and exit logic stops resolving, the signal gets weaker instead of stronger, and the coverage no longer covers the whole floor. The radar is not broken; it is being asked to work in a room it was not designed for.

Test it in a 2 m × 3 m space with one door, mounted at 2.2 to 2.8 m facing straight down, and use the door for every entry and exit. If it passes there, it will pass in a real bathroom.

Further detail on the alarm fields, timing parameters, and MQTT properties is in the companion article The Fall Detection Radar: How Alarms Work, How to Tune Them, and What to Expect.

Why Fall Detection Is Harder Than It Looks: Three Failure Modes

fuxinsuo — Sat, 17 Oct 2026 08:40:20 +0000

Fall detection is one of the most requested features in elderly care sensing, and one of the least straightforward to deliver. The name suggests a single clear event — a person falls, an alarm fires — but the sensing problem behind it has three distinct failure modes, and each one behaves differently in a real room.

This article describes those three modes: two kinds of false alarm and one kind of missed event. It also covers a problem that sits above all of them, which is that "a fall" is not a precisely defined acceptance criterion. Understanding these four things is the difference between a fall radar that works in a deployment and one that generates complaints.

Why the Demand Is Real

For an elderly person with reduced mobility — unsteady gait, a cane, limited strength, or partial loss of independence — a fall is not a health metric. It is an event where somebody needs to know, quickly, so that the person can be helped up.

That is a different requirement from sleep monitoring or presence detection. Nobody is harmed by a sleep score that arrives late. A person lying on a bathroom floor for forty minutes is harmed by an alarm that did not fire, and by an alarm that fired three times the previous night for no reason.

So the sensing requirements are strict in both directions at once: the false alarm rate has to be low enough that the alarm is believed, and the missed-event rate has to be low enough that the alarm is trusted. Those two requirements pull against each other, and that tension is the source of everything below.

False Alarm 1: Nobody There, but the Radar Reports Someone

The first failure mode is an alarm raised in an empty room.

A bathroom is full of things that move without a person present. An open window lets a curtain or a towel move in the air flow. A leaking container drips. A toilet flushes. An extractor fan vibrates. Each of these produces a radar return, and a return from a low, stationary-looking target is exactly what a fall looks like.

The sequence is:

An interference source produces a return.
The radar classifies the return as a target rather than clutter.
The target is low and does not move.
A low, stationary target is the signature the fall detector is looking for.
An alarm is published, in an empty room.

This is the failure mode that matters most at scale. A single false alarm is an inconvenience. A deployment of hundreds of units, each producing occasional empty-room alarms, produces a continuous stream of notifications that nobody acts on — and once occupants learn that the alarm is usually wrong, they stop responding to it, including when it is right.

Reducing this mode is mostly about the room, not the algorithm. Knowing whether a person is actually present — through entry and exit tracking, or through a corroborating signal — removes most of the candidates before the posture judgement runs. That is why a single-door bathroom is a much easier sensing problem than an open room, and why the scene matters as much as the sensor.

False Alarm 2: Someone There, but the Posture Is Misread

The second failure mode is an alarm raised while a person is present and doing something entirely normal.

Three examples, all of them ordinary activities:

Activity	What the Radar Sees	What It Concludes
Squatting to wash clothes	Hand and arm movement at low height, head relatively still	A person struggling on the floor
Mopping the floor	A moving object at floor level, low and wide	A low, moving target
Sitting on the toilet, swinging a leg	Foot movement at low height, torso still	Movement near the floor without a head

The common mechanism is a mismatch between what the radar weights and where the person's mass actually is. A radar that over-weights low-level movement and under-weights the position of the torso will read a squatting person as a collapsed one, because the hands are moving and the head is not.

This mode is harder to remove than the first one, because the person really is there. Entry and exit tracking does not help — the person never left. What helps is judging posture from the whole target rather than from a single region: height, centroid, and the ratio of movement at different heights together, rather than any one of them alone.

Missed Events: When There Is No Descent

The third failure mode is the one nobody wants to talk about, because it is the one that matters most.

A fall detector's most reliable trigger is a rapid descent: a tall target collapses into a wide, low one within about a second. That transition is distinctive, and it is what most detection chains are built around.

Not every fall produces it.

A person sitting on a toilet who slowly slides sideways and comes to rest on the floor has not descended in the radar's sense. Their height changed, but gradually, and without the rapid motion the detector is looking for. The same applies to a slow slump against a wall, or a controlled lowering after dizziness.

The result is a missed event in exactly the scenario where the person is least able to get up.

This is a genuine limitation of the approach, not a tuning problem. A detector that requires a rapid descent will miss slow descents. A detector that does not require one will report every sitting-down and lying-down motion as a fall. There is no setting that gives both.

Why "a Fall" Is Not an Acceptance Criterion

Above the three failure modes sits a problem that is easier to state than to solve: nobody agrees on what counts as a fall.

Consider the questions a real deployment has to answer:

Lying flat on the floor is clearly a fall. Is lying prone, face down, also a fall?
Is a person sitting on the floor against a wall a fall, or a rest?
Is a slow slide from a seated position a fall, or a collapse?
Is a person who is down and then gets up unaided a reportable event?

Every one of these is a real scenario, and every one is answered differently by different vendors, different products, and different care providers. The word "fall" in a specification covers all of them and none of them.

The practical consequence is that two products with the same quoted capability can behave completely differently on site, and a buyer cannot tell which from the specification. It also means that a requirement written as "detects falls" cannot be verified on delivery, because there is no shared definition of the thing being verified.

This is why scenario-based acceptance matters more in this category than in any other sensing category. "Detects a person lying flat on the floor within 10 seconds in a 2 m × 3 m bathroom with the door closed" is testable. "Fall detection" is not.

How to Evaluate a Fall Radar

Five checks that separate a product with real deployment experience from one with a specification sheet.

Ask for a test in an empty room with interference. A running extractor fan, a hanging cloth, a dripping tap, and a toilet flush, with nobody present. If the radar alarms, the first failure mode is unaddressed.
Ask for a test of normal low activity. Squatting, mopping, sitting and swinging a leg. These are the second failure mode, and they are easy to demonstrate.
Ask specifically about slow descents. Not "does it detect falls" — ask whether it reports a person who slowly slides from a seated position to the floor. This is the question most vendors will not answer directly.
Ask what environment the quoted false alarm rate was measured in. A rate measured in an empty room with no interference is not a rate. Ask for the room, the installation height, and the interference sources present.
Write the acceptance criteria as scenarios, not capabilities. List the postures, the room, the timing, and the interference sources you expect. A product that passes a scenario list can be verified on delivery; a product that passes a capability list cannot.

The fifth point is the one that changes outcomes. It moves the conversation from what the product claims to what the product does in your room.

What Is Still Open

Three things in this category do not have clean answers, and it is worth being explicit about them.

Slow descents remain the hardest case. Any detector that requires a rapid descent will miss them, and relaxing that requirement raises the false alarm rate. The trade-off is inherent.
The boundary between a fall and a rest is genuinely ambiguous. Sitting on the floor, lying on a sofa, and sliding against a wall are all real behaviours, and no sensing approach classifies them perfectly.
There is no industry-standard definition of a fall. Until acceptance criteria are written as scenarios rather than capabilities, two products with the same specification will continue to behave differently on site.

None of these are solved by a better algorithm alone. They are solved by matching the detection logic to the room, by writing acceptance criteria that can actually be tested, and by being explicit about which cases a given product is and is not specified for.

Summary

Fall detection has three failure modes, and they are different problems with different causes. Empty-room alarms come from interference that resembles a low, stationary person. Misread postures come from weighting low-level movement over the position of the torso. Missed events come from requiring a rapid descent that a slow collapse does not produce.

Above all three sits the definition problem: "a fall" is not a precisely defined event, so a specification that says "detects falls" cannot be verified.

Evaluate a fall radar by asking for the empty-room test, the normal-activity test, and the slow-descent test, and by writing your acceptance criteria as scenarios rather than capabilities. The products that survive those four questions are the ones that have been deployed rather than only specified.

Three Ways mmWave Fall Detection Goes Wrong (and Why 'Detects Falls' Is Not a Spec)

fuxinsuo — Sat, 17 Oct 2026 07:36:48 +0000

title: "Three Ways mmWave Fall Detection Goes Wrong (and Why 'Detects Falls' Is Not a Spec)"
tags: mmwave, radar, iot, homeassistant, embedded
canonical_url: https://249263431.github.io/60GHz-Radar-SDK/fundamentals/2026/10/17/fall-detection-failure-modes.html
You would think "fall detection" is a solved problem. A person falls, the sensor notices, an alarm fires. In practice, the sensing problem behind that sentence has three distinct failure modes, and each one behaves differently in a real room.

This post is a field note from building 60GHz mmWave radar modules for elderly care. No marketing claims — just the failure modes, why they happen, and how to evaluate a device before you put it in someone's bathroom.

Why the demand is real

For an elderly person with reduced mobility — unsteady gait, a cane, limited strength — a fall is not a health metric. It is an event where somebody needs to know, quickly, so the person can be helped up.

That requirement is strict in both directions: the false alarm rate has to be low enough that the alarm is believed, and the missed-event rate has to be low enough that it is trusted. Those two pull against each other, and that tension is the source of everything below.

Failure mode 1: nobody is there, but the radar reports someone

A bathroom is full of things that move without a person present. An open window lets a curtain move. A leaking container drips. A toilet flushes. An extractor fan vibrates. Each produces a radar return, and a return from a low, stationary-looking target is exactly what a fall looks like.

The sequence is:

An interference source produces a return.
The radar classifies it as a target rather than clutter.
The target is low and does not move.
A low, stationary target is the signature the detector looks for.
An alarm fires — in an empty room.

This is the mode that matters most at scale. A single false alarm is an inconvenience. A deployment of hundreds of units, each producing occasional empty-room alarms, produces a stream of notifications nobody acts on — and once occupants learn the alarm is usually wrong, they stop responding to it, including when it is right.

What helps: knowing whether a person is actually present (entry/exit tracking, or a corroborating signal) removes most candidates before the posture judgement runs. A single-door bathroom is a much easier problem than an open room.

Failure mode 2: someone is there, but the posture is misread

Three ordinary activities that get misclassified:

Activity	What the radar sees	What it concludes
Squatting to wash clothes	Hand/arm movement at low height, head still	A person struggling on the floor
Mopping the floor	A moving object at floor level	A low, moving target
Sitting, swinging a leg	Foot movement low, torso still	Movement near the floor without a head

The common mechanism: the radar over-weights low-level movement and under-weights where the person's mass actually is. Judging posture from the whole target — height, centroid, and movement at different heights together — is what reduces this, not any single threshold.

Failure mode 3: when there is no descent

The most reliable trigger for a fall detector is a rapid descent: a tall target collapses into a wide, low one within about a second. That transition is distinctive, and most detection chains are built around it.

Not every fall produces it. A person who slowly slides off a toilet and comes to rest on the floor has not descended in the radar's sense — height changed, but gradually, without the rapid motion the detector expects. Same for a slow slump against a wall.

The result is a missed event in exactly the scenario where the person is least able to get up. This is a limitation of the approach, not a tuning problem: a detector that requires a rapid descent will miss slow ones; one that does not will report every sit-down as a fall. No setting gives both.

The problem above all three: "a fall" is not a spec

Consider what a real deployment has to answer:

Lying flat is clearly a fall. Is lying prone also a fall?
Is a person sitting on the floor against a wall a fall, or a rest?
Is a slow slide from seated a fall, or a collapse?
Is a person who falls and gets up unaided a reportable event?

Every one is a real scenario, and every one is answered differently by different vendors. "Detects falls" in a spec covers all of them and none of them. The practical fix is to write acceptance criteria as scenarios, not capabilities:

Detects a person lying flat on the floor within 10 seconds, in a 2 m × 3 m bathroom with the door closed.

That is testable. "Fall detection" is not.

Before you buy or deploy

Ask for the empty-room test. Running fan, hanging cloth, dripping tap, toilet flush, nobody present. If it alarms, mode 1 is unaddressed.
Ask for the normal-activity test. Squatting, mopping, sitting and leg-swinging. These are mode 2.
Ask specifically about slow descents. Not "does it detect falls" — ask whether it reports a person who slowly slides from seated to the floor.
Ask what environment the false-alarm rate was measured in. A rate from an empty, interference-free room is not a rate.
Write acceptance as scenarios, not capabilities. A product that passes a scenario list can be verified on delivery.

Where this comes from

I maintain the documentation and SDK for a line of 60GHz mmWave radar modules (fall detection, sleep monitoring, presence detection) that speak Wi-Fi + MQTT and integrate with Home Assistant. The full write-up of these three failure modes, including the acceptance-criteria section, is here:

Docs and guides: https://249263431.github.io/60GHz-Radar-SDK/

If you are evaluating mmWave radar for a care deployment, the setup guide and MQTT topic reference there are the practical starting point.