DEV Community: fuxinsuo

Delivered Is Not Seen: What a Fall Alert Needs After the Message Arrives

fuxinsuo — Mon, 02 Nov 2026 00:38:10 +0000

The previous article in this series was about getting a fall alert onto the right phone: why the fallback layer should be SMS and a placed call rather than a push notification, and what each channel guarantees on the way there.

This one picks up where that left off, at the moment the message has already arrived. Because arriving is not the same as being noticed, and being noticed is not the same as someone taking responsibility. Most alert systems that fail in the field do not fail at delivery. They fail here.

Three states, and only two of them are observable

A single alert passes through three states:

Delivered — the message reached the device.
Seen — a person actually looked at it.
Answered — a person took responsibility for it.

The first and the third can be observed. The middle one cannot, and this is the single most important thing to accept before designing anything.

Delivered is observable because the operator network reports it: a delivery report for SMS, an answered or unanswered state for a call. Both come from outside your system and both are real.

Answered is observable only because you built a way to record it — an acknowledge action, a digit pressed during a call, a reply. It exists because you decided it should.

Seen has no signal at all. Nothing in any messaging channel tells you a human being read a thing. Read receipts are a partial exception and a weak one: they report that an app was opened, not that a person understood anything, and they are not available on the channels a fall alert actually uses.

So the practical consequence is this: you cannot measure attention, so you must design for a proxy. The only trustworthy proxy is an acknowledge action. Everything in the rest of this article follows from that one sentence.

Why "seen" fails

It is worth being concrete about the ways an alert arrives and is not noticed, because they are ordinary and they are not exotic failures:

Notification grouping. Smartphones sort messages into categories. A message that is not from a person tends to land somewhere other than the place its owner looks first.
Focus and quiet modes. Scheduled automatically overnight — which is a large fraction of the hours a fall happens in.
The phone is not with the person. Charging in another room, face down, on silent.
The alert went to the wrong member of the household. One device was enrolled, several people live there, and the one who was enrolled is not the one who is available.
Several people were notified, and each assumed another was handling it. When a group is told, responsibility spreads across the group and can end up nowhere. This is a well-documented pattern in team coordination, and a family is not immune to it.

None of these is a channel problem. Every one of them happens after a perfectly successful delivery. That is why a better channel does not fix them, and why they need to be designed against rather than engineered away.

Alert fatigue: the one failure that disables every channel at once

Every channel discussed in the previous article — SMS, a placed call, push — works on the assumption that the recipient treats an incoming alert as worth attention. That assumption is the load-bearing part, and it is the part that breaks.

If alerts arrive often enough that they stop meaning anything, the recipient stops looking. Once that happens, every channel fails simultaneously. It does not matter that the SMS was delivered by a carrier-grade store-and-forward network, or that the call was placed by a retry queue you tuned carefully. A message nobody opens is indistinguishable from a message that never arrived.

This is the reason to treat false alarms as an alerting problem and not only a sensing problem. The sources of false alarms, and what has been done about them at the algorithm layer, are covered in Real Demand, Hard Physics. This article is about the other half: what a false alarm does to the delivery chain downstream.

Two design rules follow:

The value of an alert is its rarity, not its volume. An alert that fires ten times a day carries almost no information on the eleventh. An alert that fires once a month is read immediately.

Severity should control intrusiveness, not the reverse. Not every event deserves a phone call. A static-dwell or out-of-bed notice is not the same class of event as a fall. If everything arrives at maximum urgency, urgency stops being a signal.

The cancel path: an alert needs a way to be withdrawn

An alert that cannot be withdrawn is an alert that will eventually be muted.

There are two places a cancellation can come from, and a complete design has both:

From the person on the floor. If the resident is fine, they should be able to say so before anyone is disturbed. On the finished fall radar this already exists: the unit speaks after a fall and accepts a spoken reply, and a spoken confirmation stands the local alarm down — see the fall radar guide for the phrase set and its limits. If you build on a module instead, the local cancel has to be your own hardware or firmware.

From a person who received it. Whoever gets the message needs a way to say "I am handling this" — a digit pressed during the call, a reply, an acknowledge in whatever interface you ship.

Two things are easy to get wrong here:

A cancellation that nobody else hears about is not a cancellation. If four people were notified and one acknowledges, the other three are still worried. Notify the rest that it is handled. This is cheap and it is the difference between a system people trust and one they find exhausting.

The window has to be long enough to be usable and short enough to matter. Too short and nobody can react before the escalation fires. Too long and the escalation is pointless. This is a product decision that belongs in configuration, visible to whoever commissions the installation — not a constant buried in your service.

Escalation parameters: what actually decides whether someone acts

Escalation is usually described as a sequence: notify, wait, escalate. The interesting decisions are all in the parameters.

Escalate on the absence of an acknowledge, not on elapsed time alone. Elapsed time is a fallback for when your acknowledge mechanism is unavailable. If you have an acknowledge mechanism, the absence of one within the window is the real trigger, because it is the one signal that means "nobody has taken this".

Parallel notification spreads responsibility; serial escalation concentrates it. Telling everyone at once is fast, and it is the right choice for the first tier — cheap channels, low intrusion, everybody informed. But if nobody responds, continuing to tell everyone at once rarely helps. Moving to one person at a time, in a defined order, means someone specific is being asked. Stop at the first answer.

Intrusiveness should climb one step at a time. A text that nobody reads is not a reason to immediately place a call; the call is the step after the text has had a fair chance. Escalating straight to the most intrusive channel burns the channel's effectiveness for the genuine emergency.

Decide in advance where escalation stops. Every loop needs a terminus: a maximum number of attempts, a maximum number of people, or both. Without a ceiling, a misconfigured sensor turns into a repeated interruption, and repeated interruption is exactly what produces the fatigue described above.

Say who is responsible when nobody answers. If the chain reaches its terminus with no acknowledge, that state needs to be visible somewhere — a record, an entry, an unresolved item — rather than simply ending. An alert that nobody saw and an alert that nobody acknowledged are the same outcome, and both should leave a trace.

Three kinds of receipt, and which one you can trust

Worth separating clearly, because they get conflated and the conflation produces bad logic:

Receipt	Where it comes from	What it actually proves	Trust it?
Delivery receipt	The operator network	The message reached the handset	Yes
Read receipt	The receiving application, when one exists	An app was opened	No — not evidence of comprehension, and not available on SMS or calls
Acknowledge	Your own design	A person acted	Yes — the only one you control

The delivery receipt tells you your half worked. The acknowledge tells you the whole loop worked. The read receipt tells you very little, and on the channels that matter for a fall alert it does not exist at all.

The practical rule: build your logic on delivery receipts and acknowledges. Anything that depends on inferring attention from silence is guessing.

Monitoring the chain itself

One alert failing is a small problem. The chain failing silently is a large one, because it looks identical to a quiet day.

The counters worth keeping, and they are all simple:

Alerts emitted — how many events your system decided to tell someone about
Delivered — how many the network confirmed
Acknowledged — how many a person took responsibility for
Time to acknowledge — the distribution, not the average
Unresolved — reached the end of the chain with nobody answering

A collapsing acknowledge rate is a much earlier warning than a complaint from a customer. It is the number that tells you the system is on its way to becoming background noise.

Two related traps, both covered in detail elsewhere:

Do not conclude anything from silence. Absence of messages is the normal state of a working installation, because these radars report on change. See Reading Radar Data in Your Own Application.
The alerting service is itself a single point of failure. A device that has lost its network link cannot tell you, and neither can a forwarding service that has stopped. Treat the health of the chain as its own monitored object, with the same discipline described in Online and HeartBeat.

Where to go next

The other half of the chain, choosing the channel: What SMS and Voice Calls Give a Fall Alert That Push Notifications Cannot
Where false alarms come from, and what has been fixed: Real Demand, Hard Physics
The hand-off itself, including the local voice confirmation: the fall radar guide
Escalation across three radars in one home: Building an Aging-in-Place Care System
Device health before you alert on it: Online and HeartBeat
More questions answered: the FAQ

A note on what this is

A fall radar is a sensing device. It does not diagnose, does not treat, does not summon emergency services, and does not replace human checks or a call system. It detects motion it cannot promise to interpret correctly in every room, and it will produce false alarms.

Everything above concerns what happens after a reported event reaches a person. Good alert design makes sure a real event is noticed and owned. It cannot make an undetected event appear, and no amount of escalation logic improves the sensing underneath it.

Evaluation units and modules are on Tindie.

Check out our 60 GHz and 24 GHz mmWave radar modules for fall detection, sleep sensing, and presence sensing.

What SMS and Voice Calls Give a Fall Alert That Push Notifications Cannot

fuxinsuo — Sun, 01 Nov 2026 04:33:43 +0000

Every fall-alarm article on this site ends the same way: step five is yours. The radar detects the collapse, waits out its configured delay, publishes fallStatus, and on the finished units even speaks to the person on the floor. Then it stops. Who gets told, how, and what happens when nobody answers is not in any datasheet, because none of it belongs to the sensor.

This article is about that fifth step — specifically the last leg of it, getting the alert onto the right phone. The argument is unfashionable but practical: the fallback layer of a fall alert should be SMS and a placed call, not a push notification. Here is what each approach actually buys you, and what neither ever will.

This is engineering guidance for integrators. It is not a medical claim and not a safety certification. See the closing note.

Step five is a chain, not a message

"Escalation" gets drawn as one box in an architecture diagram, and then implemented as one call in code — send_notification(). It is really three legs, and they fail differently:

Transport — the alarm travels from the radar to your backend (MQTT).
Reach — your backend gets the alert onto the recipient's device.
Acknowledgment — a human learns about it and takes responsibility.

Most engineering effort goes into leg 1, because it is the leg the datasheet describes. Most field complaints come from legs 2 and 3. "The radar missed it" is very often "the radar reported correctly and nobody found out."

And for our part of the chain, the detail that changes everything: the buyer is usually not the user. An adult child installs this for a parent. The question is not "will our users install our app" — it is whether the person who must be reachable has done their part before the one day it counts.

Two networks, not two vendors

The choice between push and telecom is usually framed as picking a service provider. It is not. It is picking which network carries the last leg.

	App push	SMS / placed call
Carried on	The internet — Wi-Fi or mobile data	The operator's signalling and voice networks
Needs a working data connection	Yes	No
Requires an app installed	Yes	No
Requires notification permission	Yes	No
Requires an account on the recipient's side	Yes	No
Who retries when the device is unreachable	You, or nobody	The operator, for SMS
Delivery evidence	Vendor receipt	Operator delivery report / answered-call state

Two consequences follow directly, and they are the whole argument:

Push asks something of the recipient first. There must be an installed app, a granted permission, and a live session with a push service before your alert has anywhere to land. Every one of those is a condition you do not control.

An alert path that only works when everything else is also working is not a fallback. It is a second copy of the same dependency.

What the telecom path gives you

Six properties, roughly in order of how much they matter here.

1. Nothing is required of the recipient

A phone number is enough. No install step, no sign-up, no permission granted weeks earlier, no app version quietly gone stale. A number works on a decade-old handset and for a relative who visits once a year and appears in nobody's contact graph.

It also removes the most expensive class of support ticket: the one where the alert never arrived because notifications were muted, an app was signed out, or an account was never created. None of those failure modes exist on a path that only needs a number.

2. It does not depend on a data connection

SMS travels on signalling; a call travels on the voice network. Neither needs an active IP session. The cases this covers are ordinary ones:

The recipient has no data allowance left this month.
The recipient is somewhere with one bar of signal — enough for a text and a call, not enough for anything else to load.
The phone is in battery-saving mode, which throttles background data and leaves calls alone.

3. The retry belongs to someone else

This is the one property no application-layer approach can replicate. SMS is store-and-forward: if the handset is off, out of coverage, or underground, the message is held by the network and delivered when the device returns.

It is time-limited — the retention window is set by the operator and by your provider's configuration, so confirm it rather than assume it. But the retry loop runs inside the operator's infrastructure, unattended, whether or not your server is awake. With push, the same offline device is your problem, and whatever the platform holds, it holds briefly and on conditions you do not set.

Know the asymmetry going in: a call has no store-and-forward. An unanswered call is simply unanswered. You build the retry queue, you choose the intervals, and you decide how many contacts deep it goes.

4. An answered call is an acknowledgment

Push and SMS can both report "delivered". Neither tells you a human engaged. An alert sitting unread in a notification tray and an alert nobody received are indistinguishable from your backend's point of view.

An answered call is different in kind: a person picked up. That is the closest thing to proof-of-reach available without shipping an app, and it is why the call belongs at the end of the chain rather than the start.

You can extend that signal to everyone rather than only the first person to answer, and still ship no application: prompt for a digit press during the call and treat it as an acknowledge. Works on any handset that can receive the call, needs no account, and gives your backend a real event to record.

5. Delivery you can measure

SMS returns a delivery report; a call returns answered or unanswered. Both come from the operator's side. So your escalation logic can be built on evidence instead of a timeout guess:

fall event arrives ──> SMS to all contacts in parallel
                  ──> read delivery reports
                  ──> wait a bounded window for an acknowledge
                  ──> none received: place calls in order, stop at first answer
                  ──> nobody answered: next contact, bounded retries

Every branch above is triggered by something arriving. That is worth contrasting with the alternative, where "probably delivered" is the strongest signal you get and silence has to be interpreted.

6. The alerting logic stays yours

When the notification path is somebody else's app, the alert experience — who is told, in what order, what happens when nobody responds — is largely defined by that platform. When you place SMS and calls from your own service, the contact list, ordering, retry policy, and audit trail are software you own.

For an integrator that is the difference between a feature you tune per customer and a feature you request. It is also the part that can be priced and supported, rather than inherited.

What it looks like assembled

Cheapest and most reliable first, escalating only on the absence of an answer.

Layer 0 — on site, with or without a network. Part of this already exists in hardware. The finished fall radar speaks after a fall and accepts a spoken reply, so a resident who says "I am OK" stands the local alarm down — see the phrase set and its limits in the fall radar guide. If you are building on a module instead, R60AFD1-V raises GP1 the moment a fall is concluded, which is enough to drive a local buzzer or relay with no parser at all — see GPIO vs UART and driving a relay from GP1. Know the variant difference up front: the 24 GHz fall module has no hardware alarm output — its S1/S2 are presence and motion only, so for that variant Layer 0 has to be your firmware's job.

Keep this layer even though it looks redundant. It is the only one that still works when the home router has failed, which is not an exotic scenario.

Verify this one on the bench. In the documented alarm chain, fallStatus is published before the local voice step. Confirm what your broker actually sees when a resident cancels locally — if that cancellation does not reach your system, then the stand-down decision lives entirely in your own logic, which is exactly why Layer 2 exists.

Layer 1 — reach. SMS to every contact, in parallel.

Layer 2 — acknowledgment. Wait a bounded window. No acknowledge → place calls, first contact first, stopping at the first answer.

The acknowledge mechanism. Do not skip it. Without a way for the receiving person to say "I am handling it", carers learn to treat alerts as background noise, and that defeats every layer above. The digit press during the call is the cheapest version that needs no app; a reply keyword works too, if your number can receive.

Set the wait window honestly: long enough that someone can read a text and respond, short enough to still be useful. It is a product decision and belongs in the configuration, visible to whoever commissions the installation.

The first half of the chain is not immune

Everything above assumes the fall reached your backend. Worth a short section, because a telecom fallback tends to get blamed for failures upstream of it.

Use QoS 1 on fall events and a persistent session on your consumer, so a restarting backend does not miss the one message that mattered. The settings that actually help are listed in Reading Radar Data in Your Own Application.
Payloads are sparse by design. Everything is reported on change, so no news is the normal state, not a fault.
Device health has a hard limit. An offline device cannot report that it is offline. online is generated by the broker when a session drops, which is real evidence; heartBeat can only ever come from a radar that still has a link to send it with. Read Online and HeartBeat before writing any timeout-based logic — it is the clearest treatment of why silence proves nothing, and it lists what to measure at commissioning instead.
A network outage removes all of it at once. No choice of downstream channel recovers an alert that never left the house. Which is the argument for Layer 0.

What telecom channels do not solve

Stated plainly, because overselling this would be worse than not writing it.

Reach is not attention. This article is about getting the alert onto the phone. Whether somebody notices within thirty seconds is a separate problem, solved by escalation design and by keeping alerts rare enough to still mean something — which is a false-alarm question at the sensor end, covered in Real Demand, Hard Physics. A perfect SMS path delivering constant noise is still a product nobody trusts.

Numbers get filtered. Operator spam filtering and unknown-call screening are real, particularly for numbers that have carried other traffic before. Use a consistent, registered sender identity, and ask recipients to save the number to contacts during setup. Plan for this rather than discovering it.

Templates and consent are paperwork. Signatures and message templates need registration and approval, and voice broadcasting is regulated more tightly than SMS in most places. Get explicit opt-in from the contact at binding time — not buried in terms, but an affirmative "yes, call me for fall alarms". With someone's phone number, that is also simply the decent thing to do.

Bound your retry policy. Cost arrives per message and per call minute. Fine at true-fall frequency; not fine if a misconfigured dwell alarm starts placing calls every few minutes overnight. Put a ceiling on attempts per event.

One regional caveat, stated rather than buried. How wide the gap really is depends on your market. Where handsets carry a system-level push service that is exempt from power management, an app path can perform well and the argument narrows to "installs are still a barrier". Where handsets ship without one — which covers a large share of Android devices — app push depends on per-manufacturer channels and per-device background policy, and the gap is wide. Verify this for the markets you actually ship to rather than taking either sentence from us.

Where to go next

Step five across three radars in one home: Building an Aging-in-Place Care System
The hand-off itself, step by step: the fall radar guide
What genuinely defeats detection: fall detection failure modes
Getting events reliably to your backend: Reading Radar Data in Your Own Application
Device health before you alert on it: Online and HeartBeat
The broker underneath: Apache Artemis setup
More questions answered: the FAQ

A note on what this is

Everything above concerns making sure a reported event reaches a person. That is a communication problem, one layer removed from whether any given fall was caught at all — and no receiving channel, however reliable, improves the detection underneath it.

Evaluation units and modules are on Tindie.

Check out our 60 GHz and 24 GHz mmWave radar modules for fall detection, sleep sensing, and presence sensing.

What Data-Driven Algorithms Changed in Contactless Sleep Sensing, and What They Could Not

fuxinsuo — Fri, 30 Oct 2026 22:39:18 +0000

The largest change in contactless sleep sensing over the last few years has not been in the radio. The same bands, similar front-ends, comparable antenna layouts — what changed is the layer that turns motion, respiration and heart rate into a statement about sleep.

That layer used to be written by hand. It is increasingly learned from data. This article is about what that migration actually bought, and — more importantly — about the part of the problem it does not touch.

The hand-tuned era

A rule-based sleep stage classifier looks like a set of thresholds. Movement below a value for a number of minutes means light sleep; a longer quiet interval with a slower, more regular breathing rate means deep sleep; a burst of movement followed by stillness means a transition. Each threshold is chosen by a person, tested on a handful of nights, and adjusted.

The weakness is not that the rules are wrong. It is that the variables they would need are not expressible as constants:

Individual differences. Resting heart rate, breathing depth and the amount of movement during sleep vary substantially between people, and between an eighty-year-old and a thirty-year-old.
Bedding and season. A thick winter quilt changes both the movement signature reaching the radar and the thermal environment. So does a fan running in August.
One person or two. Two bodies in the same bed produce a composite signal no single-person rule describes.
Body position. Lying on the back, on the side, or curled up changes which parts of the torso move and how much of that motion reaches the antenna.

Each of these would need its own branch, and the branches interact. A system built this way works in the conditions it was tuned in and degrades quietly outside them.

What learning from data changed

The difference is not that a model is smarter than a person. It is that the decision boundary is fitted rather than guessed.

Instead of one person choosing where to put a threshold, a large number of labelled nights are used to find which combinations of features actually separate the states. The features are the same ones the hand-tuned rules used — movement over time, breathing rate and its regularity, heart rate and its variability, time since getting into bed, transitions between positions — but they are considered together, as a pattern over a window rather than as independent conditions.

Three practical consequences follow.

Stability improved first. The most visible change is not a more accurate stage label but fewer of them. A hand-tuned classifier can flicker between light and deep several times in a minute when a value sits near a boundary. A fitted boundary produces a smoother sequence, which is what makes a night's output readable at all.

The edges got better. Falling asleep and waking up are transitions with recognisable signatures — breathing rate changes, the movement pattern changes, and then posture settles. Learned models handle these boundaries better than a rule that waits for a fixed number of quiet minutes.

Individual baselines became usable. Once the model is fitted against many nights from many people, it can adapt to a particular person's typical pattern rather than comparing everyone against one absolute threshold. This is where most of the practical gain has come from.

What did not change

This is the part worth being precise about, because the improvement in stability is easily read as an improvement in accuracy against ground truth.

The inputs did not change. A contactless radar observes body movement, respiration, heart rate, and — depending on the configuration — position and posture. It does not observe brain activity, eye movement, or muscle tone. Those are the signals that sleep stages are defined by.

The clinical definition did not change. Sleep staging comes from polysomnography: EEG for cortical activity, EOG for eye movement, EMG for muscle tone. A stage label produced without any of those three is an inference from correlates, and it stays an inference no matter how the inference is computed. The reasoning is set out in Choosing a Sleep Sensing Approach.

Agreement with a wearable is not accuracy against reality. This distinction matters more as models become better. If a model is trained or tuned so that its output matches a wristband or a ring, what improves is agreement with that device. The wearable is itself estimating stages from an accelerometer and an optical pulse sensor, and its own agreement with polysomnography is limited. Two devices agreeing with each other tells you they are consistent. It does not tell you either is right.

That is not an argument against the practice — comparing against a wearable is often the only large-scale source of labels available outside a sleep laboratory. It is an argument for keeping the two statements separate when describing what a device does.

The population in the training data is still the population it works on. A model fitted on one set of people, in one set of beds, with one range of body types, carries those conditions with it. The failure mode is not random error; it is systematic error on whoever was under-represented.

What the radar actually publishes

The published output for the sleep radar makes the boundary visible, which is useful: the limits are on the surface rather than buried in an opaque score.

Field	Content
`sleepStatus`	Sleep state
`getIntoBed`	In bed / out of bed
`awakeDuration`	Time awake
`lightSleepDuration`	Time in light sleep
`deepSleepDuration`	Time in deep sleep
`sleepScore`	Sleep score
`sleepComprehensiveStatus`	Composite sleep state
`sleepQualityAnalysis`	Sleep quality analysis
`abnormalSleep`	Sleep abnormality flag

Awake, light and deep are present. REM is not. There is no rapid-eye-movement stage in the published protocol, which is the honest outcome of the constraint described above: eye movement is not among the measurable inputs, so a REM label would have to be inferred from heart-rate and movement patterns alone.

The supporting measurements arrive at their own cadences — breathing rate and heart rate roughly every three seconds, the body-movement index about once a second on the finished units — which is why staging is computed over windows rather than from a moment.

How to read the output

Given all of the above, the output is best used as it was built to be used:

As a trend, not a measurement. Nightly time in bed, number of times out of bed, and the distribution across states are meaningful when compared against the same person's previous weeks. A single night's absolute number is much weaker. This is the same principle as Storing Radar Data: Retention, Downsampling, and Why Trends Beat Instant Values.
As a prompt, not a diagnosis. abnormalSleep and sleepScore are flags that something in the night differed from the usual pattern. What follows from a flag is a person checking on a person.
With the stage labels coarse. Three states plus an awake duration describe a night at a resolution that is defensible. Finer claims are not supported by the inputs.

Contactless sensing is useful precisely because nobody has to wear or charge anything, and because it works night after night without anyone remembering to enable it. That is worth a great deal. It is a different thing from a sleep study, and it is better for the comparison to be stated than left implied.

Where to go next

The comparison across four sensing approaches, and where polysomnography sits: Choosing a Sleep Sensing Approach
What the sleep radar publishes, field by field: Sleep Radar Guide
Keeping months of it, and why the trend is the signal: Storing Radar Data
Reading the stream directly: Reading Radar Data in Your Own Application
Treating quoted specifications with care: Three mmWave Radar Specs That Are Almost Always Exaggerated

Contactless sensing observes movement, respiration and heart rate. It does not observe sleep physiology, and a stage label derived from it is an inference.

Check out our mmWave radar modules for sleep and presence sensing

Antenna Channels, Virtual Aperture, and What More of Them Actually Buys You

fuxinsuo — Thu, 29 Oct 2026 22:52:27 +0000

Channel counts are the specification most often quoted when radar modules are compared: one transmit and three receive, four and four, six and six. The comparison is meaningful, but it is often read as a linear quality scale, and it is not one. What a channel buys depends entirely on what the radar is being asked to work out.

This article sets out what channel count determines, what it does not, and how that maps onto the three jobs these modules are built for — presence, breathing and sleep, and fall detection.

What a channel count means

With T transmit antennas and R receive antennas, time-division MIMO produces a virtual array of:

N = T x R

virtual channels. The virtual array, not the physical one, sets the angular capability. Two consequences follow directly, and a third follows from how the elements are placed.

Angular resolution

With elements at half-wavelength spacing, the angular resolution at broadside is approximately:

theta_res ≈ 2 / N  radians  =  114.6 / N  degrees

Configuration	Virtual channels	Approximate angular resolution
1T1R	1	none — no angle at all
1T3R	3	≈ 38°
2T4R	8	≈ 14°
4T4R	16	≈ 7.2°
6T6R	36	≈ 3.2°

These are theoretical figures, at broadside and with good signal-to-noise ratio. Real performance is worse, and it degrades further away from the antenna boresight.

Coherent combining gain

Processing across N channels gives a combining gain of about:

G = 10 x log10(N)  dB

Configuration	Combining gain
1T3R	≈ 4.8 dB
2T4R	≈ 9 dB
4T4R	≈ 12 dB
6T6R	≈ 15.6 dB

Because detection range scales as the fourth root of signal-to-noise ratio, a gain difference of G dB changes range by a factor of 10^(G/40). Going from three virtual channels to sixteen — about 7 dB — extends range by roughly 1.5 times. That is a real improvement, and it is much smaller than the ratio of channel counts suggests.

Elevation

Angular resolution in azimuth is not enough when the question is about height. Estimating elevation requires receive elements distributed in the vertical direction. A single row of elements gives azimuth only, no matter how many there are. An L-shaped or triangular arrangement gives both, at lower resolution than either.

This is the one place where the physical layout matters more than the count. Three elements in a triangle can say something about height; eight elements in a straight line cannot.

What a channel count does not decide

Two of the most important capabilities in these applications are set by other parameters entirely.

Range resolution depends on swept bandwidth, not on channels:

Δd = c / (2B)

Displacement sensitivity depends on wavelength and phase, not on channels:

Δφ = 4π x Δx / λ

At 61–62.5 GHz the wavelength is about 4.9 mm, which gives roughly 144° of phase change per millimetre of displacement. That is what lets breathing be measured, and adding channels does not change it.

A worked example makes the boundary clear. Separating two fingers about 2 cm apart at a distance of 0.5 m needs an angular resolution near 2.3°, which means roughly 50 virtual channels — and it also needs a range resolution better than 2 cm, which needs about 7.5 GHz of bandwidth. Neither is available in a 60 GHz module. Fine spatial detail of that kind is imaging-radar territory, not the territory of a four-by-four or a six-by-six.

What the three jobs actually require

Job	Question being answered	Capability it actually rests on	Does it need angular resolution?
Presence (24 GHz)	Is anyone in the room, including someone sitting still?	Sensitivity, beam coverage, detection of small motion	No
Breathing and sleep (60 GHz)	Breathing rate, heart rate, sleep stage	Phase sensitivity at a short wavelength, signal-to-noise ratio	No
Fall detection (60 GHz)	Is this person upright, seated, or lying down?	Change in height — the elevation dimension	Yes, and it can be coarse

Two of the three do not need angle at all. They need sensitivity and phase, which come from wavelength, bandwidth and combining gain.

The third is the exception. Distinguishing lying from standing is a height question, so fall detection is the only one of the three that requires the elevation dimension — and it requires it only well enough to place a body in one of a few postures, not to resolve it in detail.

This is also visible in the published figures for the fall module: a fall and static-dwell radius of about 1.5 m against a beam of 100° × 100°. The decision radius is far smaller than the illuminated area. The decision is made from signal quality and height change within that radius, not from angular precision across the whole beam.

Why more channels are not automatically better for home monitoring

The classification being asked for is coarse: unoccupied, lying, seated, standing, moving. That is a small number of classes, and it does not require a dense point cloud to separate them.

Adding channels past the point where those classes are separable buys detail that the application cannot use, and it costs in four places:

Cost and die area. Every channel carries its own RF front-end circuitry.
Power. More active channels per frame.
Frame duration. In time-division MIMO the transmit antennas take turns, so the frame grows roughly linearly with the number of transmit channels. Using the relation from Distance and Speed from a Radar Echo, v_max = λ / (4 · T_c), a longer per-antenna repetition interval lowers the unambiguous velocity. A configuration with four transmit channels reaches one quarter of the unambiguous velocity that one transmit channel would, at the same chirp duration. Fast motion then aliases, and a moving target that crosses resolution cells within one coherent interval produces a smeared result.
Array layout constraints. Packing many elements into a small board pushes spacing towards or beyond half a wavelength, which produces grating lobes — false angular responses — and increases mutual coupling between elements. Both degrade the point cloud rather than improving it.

There is also a processing cost: more channels means more data per frame and more work per frame, on hardware that in a domestic product is expected to be inexpensive.

When more channels are genuinely needed

Separating several people in the same space, and tracking each one
Finer posture work than lying, seated and standing
Imaging applications, where the output is a shape rather than a class
Longer range, where the combining gain is what buys the link budget

None of these is required by unattended presence, breathing monitoring, or fall detection in a single-occupant room.

Choosing for the job

If the product must…	Then the design pressure is on…
Say whether a room is occupied, including a still person	Sensitivity and beam coverage, not channel count
Report breathing rate and sleep stage	Wavelength, phase stability and signal quality
Decide whether someone has fallen	An elevation dimension, of modest resolution
Separate and track several people	Angular resolution — genuinely more channels
Produce a shape or a fine posture estimate	Many channels, and bandwidth to match

Checklist

[ ] The question the radar answers written down before the channel count is chosen
[ ] Whether an elevation dimension is needed at all, checked first
[ ] Angular resolution computed as 114.6 / N degrees, and compared against the actual separation required
[ ] Range resolution computed as c / (2B) separately — channels do not affect it
[ ] Combining gain converted into range, not read as a raw dB figure
[ ] Frame duration checked against the fastest motion that must be captured
[ ] Element spacing checked against half a wavelength
[ ] Cost, power and processing budget checked at the higher count

Summary

Channel count sets the virtual aperture, and therefore angular resolution, combining gain, and — if the elements are placed in two dimensions — the ability to estimate height. It does not set range resolution, which is bandwidth, and it does not set displacement sensitivity, which is wavelength and phase.

For presence, breathing and fall detection in a home, the decisions being made are a small number of coarse classes. Two of the three do not use angle at all, and the third needs it only coarsely. Beyond that point, additional channels cost frame duration, area, power and processing, and can degrade the result through grating lobes and motion within the coherent interval.

Where to go next

The equations behind range and velocity: Distance and Speed from a Radar Echo
Turning beam angle and mounting height into floor coverage: Where the Beam Actually Lands
Beam angles, ranges and mounting heights in full: 60 GHz & 24 GHz Radar Modules for OEM Integration
Practical limits on quoted specifications: Three mmWave Radar Specs That Are Almost Always Exaggerated

Angular and range figures here follow from the standard relations for a virtual array at half-wavelength spacing, and are theoretical bounds rather than measured performance.

Check out our mmWave radar modules for sleep and presence sensing

Where the Beam Actually Lands: Coverage from Beam Angle and Mounting Height

fuxinsuo — Wed, 28 Oct 2026 23:41:04 +0000

A datasheet gives you a beam angle and a mounting height. What you actually need to know is how much floor the radar covers, and how much of that footprint is usable. Those are two different questions, and the published figures answer them separately.

This article works the geometry out for the three modules we ship, using published beam angles and published mounting heights. It also deals with the gap that appears when you put the two published numbers next to each other — the geometric footprint and the quoted detection range often do not agree, and when they disagree, one of them is the harder bound.

Two quantities, not one

Quantity	Set by	Nature
Geometric footprint	Beam angle and mounting height	Geometry. Calculable, and a hard bound.
Detection range	Signal-to-noise ratio, target size, and the conditions of the measurement	Measured under stated conditions.

The beam decides where energy can reach. Detection range decides whether what comes back is enough to make a decision. A target inside the beam but beyond the detection range is illuminated and still not reported.

The geometry

Axis pointing straight down

For a ceiling-mounted unit at height h with a full beam angle θ on the axis of interest, the footprint half-width on the floor is:

r = h x tan(θ / 2)

The full width is 2r. θ is the full angle as published, not the half angle.

Axis tilted

For a wall-mounted unit, the geometry is easier in terms of the depression angle φ below horizontal. With height h above the reference plane and beam angle θ:

near edge   = h / tan(φ + θ/2)
beam centre = h / tan(φ)
far edge    = h / tan(φ - θ/2)

The useful angles:

Angle	tan
10°	0.176
25°	0.466
30°	0.577
45°	1.000
50°	1.192
65°	2.145

Presence module: R24AVD1, ceiling

published: beam 90° horizontal × 60° vertical, ceiling mounting to 2.75 m, horizontal tilt ≤ 3°.

At 2.75 m:

width  = 2 x 2.75 x tan(45°) = 5.5 m
depth  = 2 x 2.75 x tan(30°) = 3.2 m

The footprint is therefore roughly 5.5 m × 3.2 m, and it is not square — the vertical beam is narrower, so the depth of coverage is smaller than the width. Orienting the board with the long side toward the door, as the integration notes recommend, puts the wide axis where it is wanted.

The published detection figure for this module is much larger — a moving person at up to about 12 m across. That figure is measured for a moving target under stated conditions. The 5.5 × 3.2 m footprint is where the beam puts energy at 2.75 m. Both are real; they are not the same statement, and the geometry is the one you can rely on without qualification.

Fall module: R60AFD1-V, ceiling

published: beam 100° × 100°, mounting 2.2–2.8 m, fall / static-dwell / motion radius ≈ 1.5 m.

At the ends and middle of the published mounting range:

Mounting height	Footprint (square)
2.2 m	5.2 m × 5.2 m
2.5 m	6.0 m × 6.0 m
2.8 m	6.7 m × 6.7 m

Against a detection radius of 1.5 m, the beam covers a floor area several times larger than the area in which a fall can be decided. Raising the unit from 2.2 m to 2.8 m widens the footprint from about 5.2 m to about 6.7 m without extending the radius in which the decision is possible — which is why the mounting height is a configured parameter (DP6, default 2.3–2.4 m) rather than a free choice.

The practical reading: size the room against the 1.5 m radius, not against the beam. A bathroom wider than about 3 m across will have corners the radar illuminates and cannot decide on.

Sleep module: R60ABD1, tilted above the bed

published: beam 40° × 40°, mounted above the bed at 0.8–1.0 m, tilt 30°–45°, with 45° given as the recommended value. Respiration is specified to 1.5 m, presence and sleep to 2.5 m.

Take h = 1.0 m and θ = 40°, so θ/2 = 20°.

At the recommended 45°:

near edge   = 1.0 / tan(65°) = 0.47 m
beam centre = 1.0 / tan(45°) = 1.00 m
far edge    = 1.0 / tan(25°) = 2.14 m

At 30°:

near edge   = 1.0 / tan(50°) = 0.84 m
beam centre = 1.0 / tan(30°) = 1.73 m
far edge    = 1.0 / tan(10°) = 5.67 m

The geometry explains the published recommendation. At 45° the far edge sits at 2.14 m, inside the 2.5 m sleep range, so essentially all of the illuminated area is usable. At 30° the far edge runs out to 5.67 m, well past the 2.5 m figure — most of the beam is falling on floor that the radar cannot report on, and the beam centre has moved to 1.73 m, away from the chest.

Working the same numbers at the lower mounting height, h = 0.8 m with a 45° tilt, gives a near edge of about 0.37 m and a far edge of about 1.72 m — a tighter footprint concentrated on the upper body, which is what breathing detection wants.

For respiration specifically, the 1.5 m limit means the reliably measured band on the bed runs from about 0.47 m to 1.5 m from the wall at h = 1.0 m and 45°. That is the part of the bed to aim at.

Why the two numbers diverge

Beam edge energy is lower than on-axis energy, and off-axis targets return a weaker echo at a worse incidence angle. Decisions that need more than "something is there" — is this person lying down, is this a fall — need more signal than simple presence does, so their usable radius is smaller even inside the same beam.

Published range figures are measured against a defined target under defined conditions. Comparing them directly against a geometric footprint is a category error in both directions: the footprint can be larger than the usable area, and a quoted range can be larger than the footprint at a low mounting height. When the two disagree, treat the geometry as the bound you can compute, and the quoted range as a figure you verify on site.

What geometry does not tell you

The calculation assumes a clear line of sight. It says nothing about:

Occlusion — a cabinet, a shower screen, a plant between the radar and the target
Reflections — metal and glass surfaces that route energy elsewhere and produce returns from places no one is standing; see Ghost Targets and Glass Walls
Target size — a person standing returns more than a person lying down at the same distance
Interference — moving non-living objects inside the beam, such as fans and curtain rails

Verifying it on site

The finished units report distance and position, both about every 2 s and both documented as non-critical with limited accuracy. Walk the edge of the computed footprint and watch where the target is picked up and where it is lost; that gives you the real boundary, including occlusions the calculation cannot see. The method is set out in Using Distance and Position Output to Debug a Radar Installation.

Record the result. It is the number your next installation of the same model starts from.

Checklist

[ ] Beam angle read as the full angle, and halved before use
[ ] Footprint computed at the actual mounting height, not at the nominal one
[ ] For ceiling units: width and depth computed separately when the beam is not square
[ ] For tilted units: near edge, centre and far edge all computed, and the far edge checked against the published range
[ ] Room sized against the detection radius, not the beam footprint
[ ] Occlusions and reflective surfaces checked separately — the calculation assumes clear line of sight
[ ] Boundary confirmed on site with the distance output, and recorded

Where to go next

Where to put a sleep radar, and what to avoid: Sleep Radar Installation — Finding the Right Position
Beam angles, mounting heights and ranges in full: 60 GHz & 24 GHz Radar Modules for OEM Integration
Why published ranges should be treated with care: Three mmWave Radar Specs That Are Almost Always Exaggerated
Commissioning the result: Using Distance and Position Output to Debug a Radar Installation

Computed footprints follow from published beam angles and published mounting heights. Detection ranges are measured figures; where geometry and a quoted range disagree, verify on site rather than assuming either.

Check out our mmWave radar modules for sleep and presence sensing

Distance and Speed from a Radar Echo: Two Equations, and What the Module Datasheets Publish

fuxinsuo — Tue, 27 Oct 2026 23:22:44 +0000

A radar echo carries two kinematic quantities: range — how far away the reflecting target is — and radial velocity, the component of the target's motion along the line between the radar and the target. Both are recovered from the same received signal, by two different routes. Range comes from timing, expressed through frequency. Velocity comes from the Doppler effect, expressed through frequency shift.

This article sets out the two equations, derives the quantities that follow from them for the two bands we ship — 24 GHz and 61–62.5 GHz — and states which parameters the module datasheets publish and which they do not.

The conceptual overview, without arithmetic, is in How mmWave Radar Works: From FMCW to Breathing Detection.

Range

The underlying idea: round-trip time

The radar transmits, the wave travels to the target, part of the energy returns, and the receiver sees it. Electromagnetic waves propagate at c ≈ 3×10⁸ m/s, and the wave covers the distance twice, so the round-trip time t gives the range:

d = c · t / 2

The division by two accounts for the outbound and return legs.

Why the time is not measured directly

For a target at 1 m the round trip is 2 m, which takes about 6.7 ns. Measuring delay at nanosecond resolution directly is not practical in a module of this cost and size.

How it is done instead: FMCW

The modules use FMCW (frequency-modulated continuous wave). The transmit frequency sweeps linearly with time, so the echo received at any instant is a delayed copy of an earlier transmit frequency. Mixing the received signal with the current transmit signal produces a beat frequency proportional to that delay, and therefore to range.

The published radar type confirms this: the fall module and the sleep module are both specified as 60 GHz FMCW, and the fall module as 1T3R (one transmit, three receive channels).

The round-trip-time equation remains the correct way to understand where range comes from. The beat frequency is the engineering route to the same number.

What sets how finely two targets can be separated

Range resolution is set by the swept bandwidth B, not by the carrier frequency:

Δ d = c / 2B

Where a datasheet publishes the transmit frequency band, a figure follows. The fall module publishes a transmit frequency of 61–62.5 GHz, a span of 1.5 GHz:

Δd = c / (2B) = 3x10^8 / (2 x 1.5x10^9) = 0.10 m

So about 10 cm, on the assumption that the published operating band is also the swept span. Two notes on that figure:

It is the separation at which two targets appear as two. The accuracy on a single target is finer, because a single return is localised by interpolation and by phase, not by which resolution cell it lands in.
The 24 GHz datasheet we supply does not publish a swept bandwidth, so no equivalent figure is stated here.

This explains the distinction that is often blurred: a resolution cell of roughly 10 cm, and the detection of chest-wall displacements below 1 mm, are not the same measurement. The second comes from phase within a cell, covered below.

Velocity

The Doppler effect

When target and radar move relative to each other, the echo returns at a frequency offset from the transmitted one. Approaching shifts it upward, receding shifts it downward, and the sign gives the direction.

The equation

With wavelength λ and Doppler shift Δf:

v = Δ f · λ / 2, Δ f = 2v / λ

The factor of two again comes from the two-way path.

Wavelength from the published frequency

Wavelength follows from the carrier: λ = c / f.

Module	Published band	Wavelength
R24AVD1	24 GHz	12.5 mm
R60ABD1, R60AFD1-V, R60ABD2-H	61–62.5 GHz	4.80–4.92 mm

For every 1 m/s of radial velocity, the shift is therefore:

24 GHz: 2 / 0.0125 ≈ 160 Hz per m/s
61–62.5 GHz: ≈ 410 Hz per m/s

Shift magnitudes in practice

Target	Radial velocity	Δf at 24 GHz	Δf at 61–62.5 GHz
Chest wall during breathing	≈ 0.0075 m/s	≈ 1.2 Hz	≈ 3 Hz
Walking	1.5 m/s	≈ 240 Hz	≈ 610 Hz
Running	5 m/s	≈ 800 Hz	≈ 2.0 kHz

The shifts fall in the hertz to kilohertz range. They are small fractions of the carrier, and they are recovered by coherent processing rather than by comparing nominal frequencies.

Where sub-millimetre sensitivity comes from

Phase is the more sensitive quantity. A displacement Δx produces a round-trip phase change of:

Δ φ = 4\pi · Δ x / λ

For a 1 mm displacement this is about 58° at 24 GHz and about 144° at 61–62.5 GHz. The shorter wavelength gives roughly 2.5 times more phase per millimetre, which is the quantitative form of the statement made in How mmWave Radar Works — that 60 GHz is the band to use when breathing or heart rate is required.

Three parameters that set precision and span

Each of the following is a sampling constraint, so each is a trade rather than a setting that can be widened independently.

Range resolution follows the swept bandwidth, Δd = c / 2B. More span gives finer separation.

Velocity resolution follows the observation time T_obs over which the phase history is collected:

Δv = λ / (2 · T_obs)

For a one-second observation this gives about 6.3 mm/s at 24 GHz and about 2.4 mm/s at 61–62.5 GHz. Longer observation gives finer velocity resolution, which is why slow periodic motion — breathing — is measured over intervals rather than from single frames.

Unambiguous velocity follows the chirp repetition interval T_c:

v_max = λ / 4 · T_c

This is the one quantity where the shorter wavelength works in the opposite direction. At the same chirp interval, the 61–62.5 GHz band reaches a smaller unambiguous velocity than 24 GHz. A radar tuned to resolve sub-millimetre chest motion and a radar built to measure vehicle speed are therefore sampling the same physics with incompatible timing.

Not published: the modules' internal chirp timing and coherent processing interval do not appear in the datasheets, so no T_c or T_obs value is given here, and the worked figures above are labelled as illustrations of the equations.

Published output cadences

Separate from the radio parameters above are the intervals at which results are reported. These are published, and they are output cadences, not integration times:

Report	R24AVD1 (24 GHz)	60 GHz finished units
Occupied → unoccupied	40 s	about 40 s
Unoccupied → occupied	< 0.5 s	—
Static / active change	< 0.5 s	—
Approach / leave / no lateral movement	2 s	—
Body-movement amplitude 0–100	5 s	1 s
Breathing rate, heart rate	—	about 3 s

The asymmetry — under half a second to declare a room occupied, about 40 seconds to declare it empty — is a deliberate stability choice, described in Three mmWave Radar Specs That Are Almost Always Exaggerated.

Distance and position are reported by the finished units in centimetres and as x/y/z, both about every 2 s, and both documented as non-critical functions with limited accuracy. They are useful while commissioning, as set out in Using Distance and Position Output to Debug a Radar Installation, and are not a basis for a product feature.

The body-movement amplitude is a dimensionless index from 0 to 100 with defined bands, not a velocity. It is not converted to metres per second.

The two bands side by side

Quantity	24 GHz	61–62.5 GHz
Wavelength	12.5 mm	4.80–4.92 mm
Doppler shift per 1 m/s	≈ 160 Hz	≈ 410 Hz
Phase change per 1 mm displacement	≈ 58°	≈ 144°
Phase change per 1 mm, relative	1×	≈ 2.5×
Velocity resolution at 1 s observation	≈ 6.3 mm/s	≈ 2.4 mm/s
Unambiguous velocity at equal chirp interval	larger	smaller
Swept bandwidth published	no	61–62.5 GHz (1.5 GHz span)
Derived range resolution	not stated	≈ 10 cm

What this accounts for

Respiration and heart rate use 60 GHz. Displacement sensitivity scales inversely with wavelength, so the shorter band returns about 2.5 times more phase per millimetre.
Presence over a wide area uses 24 GHz. The longer wavelength and the wider beam cover a larger volume; the published beam for R24AVD1 is 90° horizontal by 60° vertical.
A posture radar is not a speed instrument. The unambiguous velocity limit moves against the higher band, and the same processing budget is spent on deciding what the target is doing. The practical figure for a home posture radar is around 3 m/s, with the reasoning in Three mmWave Radar Specs That Are Almost Always Exaggerated.

Summary

Range comes from round-trip time, recovered in practice from an FMCW beat frequency, and its resolution follows the swept bandwidth. Velocity comes from the Doppler shift, and its resolution and span follow observation time and chirp interval respectively.

The two bands differ by a factor of about 2.5 in wavelength, and that one ratio propagates through every sensitivity figure — phase per millimetre, Doppler shift per metre per second, velocity resolution — while moving the unambiguous velocity limit in the opposite direction.

Where a datasheet publishes a value, that value is used here. Where it does not, the equation is given and the absence is stated.

Where to go next

The conceptual version without arithmetic: How mmWave Radar Works
Practical limits on angle, distance and speed: Three mmWave Radar Specs That Are Almost Always Exaggerated
Module specifications in full: 60 GHz & 24 GHz Radar Modules for OEM Integration
Using distance and position while commissioning: Using Distance and Position Output to Debug a Radar Installation

Derived figures in this article follow from the equations and the published transmit bands. Where a datasheet does not publish a parameter, the equation is given and the absence is stated, rather than filled in.

Check out our mmWave radar modules for sleep and presence sensing

Updating Radar Firmware Without a Cloud: Self-Hosted OTA over MQTT

fuxinsuo — Tue, 27 Oct 2026 22:49:27 +0000

Most connected devices want you to push firmware through somebody's cloud. These do not ask for that. The sleep and fall radars fetch an image from a URL you hand them, and the command arrives on the same MQTT connection the telemetry already uses. Nothing has to leave your network, and there is no vendor account in the path.

This article is the practical shape of that: which units support it, the three commands involved, how to confirm an update actually landed, and the operational precautions the protocol document leaves to you.

Everything below comes from the Wi-Fi protocol documents for the sleep and fall units. Where they do not specify something, this article says so rather than filling the gap.

Scope first

Unit	Over-the-air update via this protocol
Sleep radar (60 GHz, Wi-Fi)	Yes — topic family `/Radar60SP/<DeviceID>/sys/property/{post,set}`
Fall radar (60 GHz, Wi-Fi)	Yes — topic family `/Radar60FL/<DeviceID>/sys/property/{post,set}`
Presence radar (24 GHz, Wi-Fi)	No such command appears in its protocol document

That last row matters. The presence unit's document specifies online, version, active and passive report topics plus a property/set command topic — and no update command at all. If you need to update those, that is a question for the hardware, not for this protocol.

Commands go to the unit's .../sys/property/set topic; everything it reports arrives on .../sys/property/post.

Three commands

1. Select the target module — required before every update.

{"version": "1.0", "method": "ota_set", "params": {"module": "0"}}

0 is the Wi-Fi module, 1 is the radar module; the default is 0. The documentation is explicit that this control command has to be sent before each update — it is not a one-time setting you configure and forget.

2. Hand over the image location.

{"version": "1.0", "method": "ota_set",
 "params": {"otaInform": {"firmwareUrl": "http://192.168.31.88/app.rbl", "port": "8090"}}}

The device fetches the firmware from that URL and port and starts updating. A failure comes back as:

{"version": "1.0", "opt": "otaInform", "res": "fail", "msg": "ota failed!"}

3. Observe progress. The report is described as an active report during update, sent with method ota_post:

{"version": "1.0", "method": "ota_post", "params": {"downloadProgress": "0"}}

Values run 0–100. Subscribe to the unit's report topic before you start; if your particular unit reports it somewhere else, record that during commissioning rather than assuming.

After a successful update, the module restarts and then reports its version number. Treat that report — not the arrival of 100 — as the completion signal.

Confirming the result

The point of verification is that "the transfer finished" and "the unit now runs the new code" are two different statements.

Sleep and fall units carry firmwareVersion and firmwareVersionWiFi in their property list, and the protocol states that the post-restart report carries the version number after updating. Compare against the value you recorded before starting.
Presence units publish a version snapshot on /RadarHP/<DeviceID>/sys/version/post containing radarID, softwareVersion, firmwareVersion and protocolVersion. These are documented as read-only — they cannot be written, only read. There is also a request command for soliciting it on demand: publish {"version":"1.0","method":"get_version","params":{}} to /RadarHP/<DeviceID>/sys/property/set.

Keep the before-and-after version pair in the same commissioning record you keep for everything else. It is the only evidence you have later.

Running an update

import json
import paho.mqtt.client as mqtt

BROKER, PORT = "192.168.1.2", 1883
DEV = "<DeviceID>"                        # the MAC, printed on the label
SET_TOPIC  = f"/Radar60SP/{DEV}/sys/property/set"
POST_TOPIC = f"/Radar60SP/{DEV}/sys/property/post"

IMAGE_URL, IMAGE_PORT = "http://192.168.1.50:8090/app.rbl", "8090"
TARGET = "0"                              # "0" Wi-Fi module, "1" radar module


def command(client, method, params):
    client.publish(SET_TOPIC,
                   json.dumps({"version": "1.0", "method": method, "params": params}),
                   qos=1)


def on_message(client, userdata, msg):
    payload = json.loads(msg.payload.decode())
    params = payload.get("params", {})
    if "downloadProgress" in params:
        print("transfer:", params["downloadProgress"], "%")
    if payload.get("opt") == "otaInform" and payload.get("res") == "fail":
        print("update failed:", payload.get("msg"))
    if "firmwareVersion" in params:
        print("reported version after restart:", params["firmwareVersion"])


client = mqtt.Client()
client.username_pw_set("backend", "...")
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.subscribe(POST_TOPIC, qos=1)
client.loop_start()

command(client, "ota_set", {"module": TARGET})          # select the target first
command(client, "ota_set", {"otaInform": {"firmwareUrl": IMAGE_URL, "port": IMAGE_PORT}})
client.loop_forever()

That is the whole mechanism — two publishes and a subscription. The rest is procedure.

Declare a maintenance window. The unit is unreachable while it rewrites and restarts. Your monitoring will interpret that as a failure unless you suppress it — see Online Says It's Connected, HeartBeat Says It Works.
Select the target deliberately. module defaults to the Wi-Fi module. Sending a radar image to it is a mistake the command will not catch for you.
Make sure the URL is reachable from the device. Same subnet or routable, firewall permits that port, and never localhost or 127.0.0.1 — the address is resolved by the radar, not by the machine issuing the command.
Stage it. One unit first. Watch downloadProgress reach 100, wait for the restart, confirm the version changed, then proceed with the rest.
Keep the previous image served. Given what is not documented below, this is your only fallback.
Do not batch-update overnight in a care deployment. A unit that comes back with a different behaviour at 03:00 is discovered by nobody until morning.

A minimal image host

You need nothing more than a static file server on the management network:

python -m http.server 8090 --directory ./firmware

which makes http://<host>:8090/app.rbl available to the units. Use it on a segregated network or behind whatever reverse proxy you already trust; it is plain HTTP with directory listing enabled, and it is a build artifact service, not a public endpoint.

What the documents do not say

Stated plainly, because guessing here costs hardware:

Transport. Every example uses http://. HTTPS support is not stated. Plan for plain HTTP on a network you control.
Rollback. No rollback command appears. Assume you cannot command a unit back to the previous revision — which is why keeping the old image available and piloting one unit first are not optional.
Duration and interruption. No update duration is given, and the documents describe failure only as the ota failed! response. Behaviour after power loss mid-update is undocumented.

The consequence is a procedural rule rather than a technical one: update when someone is present to observe, one unit first, with the previous image still served.

Checklist

[ ] Unit confirmed to be one of the two that document this command
[ ] module selected explicitly before every update — Wi-Fi module vs radar module
[ ] Image URL and port reachable from the device's network, not from yours only
[ ] Subscribed to the report topic before publishing either command
[ ] Monitoring suppression window opened, and closed only after the version report arrives
[ ] downloadProgress observed to 100, restart observed, version compared against the pre-update record
[ ] Previous firmware image still available at a known URL
[ ] Staged: one unit, verified, then the cohort

Where to go next

Not alarming yourself during the restart: Online Says It's Connected, HeartBeat Says It Works
Reading the stream these commands travel on: Reading Radar Data in Your Own Application
Keeping device identities straight at scale: Running Several Radars in One Home
The broker underneath it: Apache Artemis setup

Updating firmware is a maintenance operation, not a feature. Verify every unit before you rely on it, and keep the previous image served until you have.

Check out our mmWave radar modules for sleep and presence sensing

Online Says It's Connected, HeartBeat Says It Works: Reading Two Status Signals Instead of Guessing From Silence

fuxinsuo — Tue, 27 Oct 2026 00:04:27 +0000

Two fields in a radar's MQTT output get mistaken for each other constantly, and mistaking them is how a health monitor ends up trusted when it should not be.

They answer different questions:

online answers "is the link up?"
heartBeat answers "is the radar itself working?"

	`online`	`heartBeat`
Question answered	Is this device reachable?	Is this device operating correctly?
Reported values	`"0"` offline, `"1"` online	`"0"` abnormal, `"1"` normal
Layer	MQTT connection and broker session	The radar's own operating state
Reported when	On state change only	On state change only
Available on	Sleep radar, fall radar, presence radar	Sleep radar, fall radar

The presence radar publishes its online state on a dedicated topic — /RadarHP/<DeviceID>/sys/online/post; the sleep and fall radars publish online as an attribute in the same property payload as everything else. Note the asymmetry: there is no heartBeat in the presence radar's protocol documentation. The other two report it like this:

{"version": "1.0", "method": "post", "params": {"online": "0"}}
{"version": "1.0", "method": "post", "params": {"heartBeat": "0"}}

Why this distinction is not academic

Consider what has to be true for any heartBeat message to reach your code: the radar has power, it is associated with the Wi-Fi access point, its MQTT session is established, and you are subscribed to its topic. A delivered heartBeat therefore already proves the link is working.

From that, one conclusion follows immediately:

heartBeat cannot report a connectivity failure. Physically and logically, it cannot — a radar that has lost its link has no way to deliver that news.

The reverse holds for online. An online: "0" message is not written by the radar that went offline; it is generated by the broker when the session it was holding stops answering. The radar contributes nothing to that judgement.

So neither field overlaps with the other, and neither can substitute for the other:

If you only watch online, you will see "connected" while the radar sits there reporting a fault about itself.
If you only watch heartBeat, every network outage looks like nothing at all.

The trap: silence is not evidence

Both fields are documented as reported on state change, not on a timer. That single sentence is where most monitoring code goes wrong.

Occupancy. The presence state is event-driven. A room whose state does not change for three hours produces no occupancy messages, and that is correct behaviour — not a fault.
Heartbeat. A radar that boots normally and stays normal has no reason to send heartBeat at all, because no state change occurred.
The one periodic attribute. In the sleep and fall protocols, the only attribute the documentation marks as periodically reported is workDuration (4 bytes, value range 0x3C–0xffffffff, unit seconds) — and it is marked "not yet available" in the same line. workDurationReportFrequency carries the same note. Do not build a keepalive on either of them.

So the tempting pattern — "if I have not heard from the device in 60 seconds, it must be gone" — has no foundation here. Absence of messages is the normal state of a working installation.

What you can do instead

`online`	`heartBeat`	Conclusion	Action
1	1	Link up, radar reports normal	—
1	0	Link up, radar reports a fault	Raise the higher-severity alarm; this is the case only `heartBeat` can surface
0	—	Session dropped, as judged by the broker	Investigate the link; the radar's own state is unknown
no messages	no messages	Most likely nothing changed	Nothing can be concluded

Treat the two as different classes of event with different severities. A lost link is an infrastructure ticket; a radar reporting itself abnormal is a hardware ticket, and it is the one that should wake someone up.

Two rules you must not break

1. Do not disable online or heartBeat with limit_set. The Wi-Fi protocols expose a reporting-suppression command: limit_set / limit_get, where 1 means "suppress this attribute" and 0 means "allow it". It exists for the attributes that report frequently — someoneExists, motionStatus, movementSigns, humanDistance, humanPosition — and it is a legitimate way to cut traffic and noise. Both online and heartBeat appear in that list. Suppress them and you remove the only two signals that stand between you and a timeout guess.

2. Do not try to poll heartBeat. Every neighbouring attribute in those documents — initFinish, workDuration, productMode — carries the line "this attribute supports querying" followed by a get example. heartBeat does not. The only ? it ever appears with is inside limit_get, and that question means "is reporting suppressed for this attribute", not "what is its current value". There is no documented way to ask the radar for that value on demand.

That leaves one workable approach for the things you genuinely need on demand: query the attributes that do support it. If you must confirm a radar has finished starting up, initFinish (0 not complete, 1 complete) is queryable. heartBeat is not, and no amount of polling will change that.

A minimal health monitor

Subscribe, merge the sparse payload, and raise the two classes separately:

import json, time
import paho.mqtt.client as mqtt

TOPIC = "/Radar60SP/<MAC>/#"

state = {}
last_any = {}


def on_message(client, userdata, msg):
    try:
        payload = json.loads(msg.payload.decode())
    except ValueError:
        return
    params = payload.get("params", {})
    if not params:
        return

    # Only the fields that changed are present.
    for k in ("online", "heartBeat", "initFinish"):
        if k in params:
            state[k] = params[k]

    last_any["ts"] = time.time()

    # Two different failures, two different severities.
    if params.get("online") == "0":
        raise_alarm("link", device=msg.topic, severity="infra")
    if params.get("heartBeat") == "0":
        raise_alarm("sensor", device=msg.topic, severity="high")

Note the shape: nothing here fires on elapsed time. Every action is triggered by an arriving value.

If you still want a timeout as a last resort, the threshold must come from measurement, not habit. Log the longest interval your real installation goes without any message during normal operation, then add margin to that. A number you made up will either fire constantly or never fire.

Measure these at commissioning

Two things the documentation does not state, and that you should record per installation rather than assume:

Does the radar announce heartBeat: "1" on power-up? A device that boots healthy may never have a reason to report it. Power one up on the bench with a subscriber attached and write down what actually arrives, and how long after power-up it arrives.
Does online: "1" get republished after a reconnect? If it does not, your consumer must treat the absence of a change as "still online" rather than as unknown.

Both belong in the same commissioning note as the empty-room baseline from Using Distance and Position Output to Debug a Radar Installation.

Maintenance looks like a failure

One consequence of all this that catches people out: the sleep and fall protocols support firmware update over the air — ota_set with otaModule (0 Wi-Fi module, 1 radar module, and the command must be sent before every update), otaInform giving a firmware URL and port, and downloadProgress reporting 0–100. On success the module restarts and then reports its new version number.

During that window the device is legitimately unreachable. If your monitoring treats a missing device as an alarm, a firmware update will page someone. Put planned maintenance in a suppression window, and use the version report afterwards — the presence radar's /RadarSP/<DeviceID>/sys/version/post topic, or the firmwareVersion attribute — to confirm the update actually landed.

The update server is one you host yourself; the documentation states plainly that you build the web server the firmware is fetched from.

Two controls worth knowing about

Reporting suppression (limit_set / limit_get): set 1 to suppress an attribute, 0 to allow it. Use it on the high-frequency attributes to cut traffic and clutter. Leave online and heartBeat alone.
Per-attribute QoS (control_qos in the presence protocol, qos_set / qos_get with Qos_post in the sleep and fall protocols): the default is QoS 1, where 0 is QoS 0, 1 is QoS 1 and 2 is QoS 2. The presence protocol additionally exposes per-attribute keys — Qos_online, Qos_movementSigns, Qos_breathRate, and so on. This is worth knowing because it contradicts the usual assumption that QoS is decided only by the subscriber.

Checklist

[ ] online and heartBeat handled as two separate signals with two separate severities
[ ] No logic concludes anything from the absence of messages
[ ] limit_set used, if at all, only on high-frequency attributes — never on online or heartBeat
[ ] No polling of heartBeat; anything needed on demand read from attributes that document query support
[ ] Power-up behaviour of heartBeat measured and recorded
[ ] Reconnect behaviour of online measured and recorded
[ ] Any timeout threshold derived from measured worst-case silence, not assumed
[ ] Firmware updates placed in a suppression window, and verified afterwards by version report

Where to go next

Getting the stream in the first place: Reading Radar Data in Your Own Application
The broker underneath it: Apache Artemis setup
Keeping several devices straight: Running Several Radars in One Home
Keeping the history: Storing Radar Data

This is not a medical device. A status field tells you what a radar reports about itself; it does not guarantee what the radar detects. For anyone at real risk, monitoring is an addition to a care routine, never a substitute for one.

Check out our mmWave radar modules for sleep and presence sensing

Keeping Months of Radar Data: Retention, Downsampling, and Why Trends Beat Instant Values

fuxinsuo — Mon, 26 Oct 2026 07:44:53 +0000

The previous article ends with a dict full of the latest values. That is a working state, not a record: restart the process and everything before the restart is gone. This article is the step after — deciding what to keep, for how long, at what resolution, and which numbers actually answer a question anyone cares about.

It matters more than it sounds, because a single instant reading is nearly useless. "Occupied, still, right now" is a fact you could get by looking into the room. The facts that are worth keeping are the ones nobody can observe: how long she slept, how often she got up, whether tonight's activity looks like last month's. Those only exist if you stored the stream.

Start from what actually arrives

Recapping the JSON contract: finished units publish {"version":"1.0","method":"post","params":{...}} where values are strings and only changed fields are present, while a UART module behind your own gateway publishes whatever flat shape your firmware chose.

Three properties of that stream decide your storage design:

It is sparse. Most messages carry one or two fields. A row-per-field and a row-per-message schema are very different things.
It is heterogeneous. Presence changes on a human timescale; breathing updates every few seconds; a fall event happens once in a blue moon. One retention rule cannot serve all three.
It is a stream of states, not a stream of samples. Between two messages nothing changed. Storing the interval matters more than storing the moment.

Four questions before you write a line of code

How long do you need each kind of data? Presence events might be worth two years; breathing rate might be worth thirty days. A fall alarm is an incident record — keep it as long as you keep any incident record.

At what resolution? Nobody reads three-second breathing samples from four months ago. They read the nightly average.

Who is allowed to see it? This is intimate data, and a great deal of detail is not needed to answer any of the questions above. The safe default is: aggregate early, keep raw shortest, and store it where you own it — see the self-hosted broker rather than a cloud queue.

Which fields are trustworthy? Distance and position are documented as non-critical functions with limited accuracy, on the sleep and presence radars alike — see Using Distance and Position Output to Debug a Radar Installation. If you store them, store them as commissioning notes, not as a data product.

A retention layout that matches cadence

Tier	Data	Raw window	Then keep
Incidents	Fall events, alarms, alarm acknowledgements	Forever	Forever — this is an audit trail
Sessions	Sleep session start/end, score, stage changes	90 days	Daily summary, indefinitely
Presence	In-bed / occupancy state changes	90 days	Per-day occupancy seconds
Vitals	Breathing rate, heart rate	30 days	Per-minute average, then per-night average
Diagnostics	Distance, position, motion level	7 days	Nothing, except the install-day baseline

Those numbers are a starting pattern, not a rule; the point is that one retention setting for everything guarantees either a sprawling database or a useless one.

Cast before you store

The finished units send everything as strings — {"someoneExists": "1"}. Insert that into a numeric column and you will discover it later, at the worst possible moment. Normalise on the way in:

INT_FIELDS = {"someoneExists", "getIntoBed", "heartRateValue", "breathValue", "sleepStatus"}

def normalise(params):
    out = {}
    for key, value in params.items():
        if key in INT_FIELDS:
            try:
                out[key] = int(value)
            except (TypeError, ValueError):
                continue          # the sensor sometimes reports an unusable value
        else:
            out[key] = value
    return out

Note the continue: a breathing sensor reports "no value" states when it cannot resolve a rate. Storing those as 0 invents a reading that did not happen. Skipping them, and letting your last-known value stand, keeps the database honest — the same rule as in memory, applied one layer down.

Merge, then write

Because payloads are sparse, write only what changed and treat it as valid until something else arrives:

def on_message(client, userdata, msg):
    params = json.loads(msg.payload.decode()).get("params", {})
    row = normalise(params)
    if not row:
        return
    row["ts"] = datetime.utcnow()
    insert_row(row)          # sparse: only the fields in this message

Reading back is then an "as of" query — the most recent value of each field at or before a timestamp — which most column stores handle with last_value(...) OVER (PARTITION BY field ORDER BY ts).

Downsample to what someone will actually read

A per-night row is worth more than the 28,800 three-second samples it came from. Keep a rollup table alongside the raw one and build it once an hour:

night_of      DATE       -- the night, not the timestamp: nights do not start at 00:00
device_id     TEXT
in_bed_at     TIMESTAMP  -- first sustained in-bed reading
out_of_bed_at TIMESTAMP
bed_exits     INT        -- count of in-bed -> not-in-bed transitions
away_seconds  INT        -- total time out of bed
avg_breath    NUMERIC    -- median, not mean: it resists outliers
min_breath    NUMERIC
max_breath    NUMERIC
still_ratio   NUMERIC    -- fraction of samples with body movement at 1 %

Every one of those columns came from values the radars already publish; none of them required a new sensor or a new field. That is the whole argument for keeping history: the interesting features are computed from ordinary state transitions.

Use medians and counts, not means, for vitals. One garbage reading in ninety thousand will drag a mean and leave a median untouched.

How much space, roughly

Worth doing once so nobody is surprised. A sleep radar publishing breathing every 3 s produces about 20 messages a minute, roughly 1,200 an hour, roughly 29,000 a day. At a sparse payload of well under 200 bytes before indexing, that is single-digit megabytes per device per day in a naive row-oriented store — and an order of magnitude less once you drop the raw stream on schedule and keep only the nightly row.

Do the arithmetic with your own payload sizes rather than trusting that figure; it is arithmetic on documented cadences, not a benchmark.

Trends worth computing

Genuinely useful, and derivable from nothing but occupancy and breathing:

Nightly time in bed and number of exits. The classic sleep-quality proxy, and the change in it matters more than its value.
Baseline activity. Once you have weeks, "unusually still today" becomes a computable statement rather than a feeling.
Room usage by hour. An occupancy heat map tells you whether a room is used the way the household thinks it is.
Slow drift over months. Some apparent change is the sensor, not the person — see why radar position drifts. Keep an install-day baseline precisely so you can tell the two apart.

For an elderly-care setting these roll-up rows are also what a carer can digest: not a live graph, a weekly summary. The escalation logic that turns a summary into a call is described in Building an Aging-in-Place Care System with Three 60GHz Radars.

Checklist

[ ] Empty-restart test: does anything survive an application restart?
[ ] Every numeric field cast explicitly; unusable values dropped rather than stored as 0
[ ] Sparse writes, with an "as of" read path that fills from the last known value
[ ] One retention window per tier, not one for all data
[ ] Rollup job scheduled, and verified to produce the same answer as yesterday's data would
[ ] Distance and position marked as diagnostic, pruned aggressively
[ ] Data stored where you control it, and not sent anywhere it does not need to go

Where to go next

Getting the data in the first place: Reading Radar Data in Your Own Application
What each field means: presence, sleep and fall guides
Why some readings take seconds: Radar Latency Explained
The broker underneath it: Apache Artemis setup and Running Several Radars in One Home

Storing occupancy and breathing history is not the same as measuring anything clinical. These are trends from a contactless sensor, useful for spotting change, and not a diagnosis.

Check out our mmWave radar modules for sleep and presence sensing

Running Several Radars in One Home: Two Kinds of ID, One Broker, and How to Group Them

fuxinsuo — Sun, 25 Oct 2026 04:37:17 +0000

Setting up one radar is a single sequence in the setup guide. Setting up five is not the same sequence five times — it is a small design exercise. Almost every multi-radar failure we see traces back to one of four things: a duplicated ClientID, two devices sharing one broker account, topics that cannot be told apart, or two radars looking at the same square metre of floor.

This article is the deployment view: which identifier does what, how to keep them from colliding, where room identity actually lives, and the order to commission in.

Two kinds of ID, and they are not the same thing

	DeviceID	ClientID
What it is	The device's MAC address	The MQTT client identifier
Where you see it	Printed on the device label; shown on the configuration page at `192.168.0.1`	Entered on the same configuration page
Can you change it	No	Yes — it defaults to the MAC
Where it appears	In the topic path: `/Radar60SP/{DeviceID}/sys/property/post`	Nowhere visible; it identifies the connection to the broker
Uniqueness rule	Unique by construction	Must be unique. Two devices sharing one ClientID keep kicking each other off the broker

That last row is the whole reason this article exists. A shared ClientID does not fail loudly — it produces two devices that connect, disconnect, and reconnect in a loop, with data arriving in bursts and gaps that look like a radio problem.

One broker, many clients

Point every device at the same broker, then give each one its own credentials. The Artemis setup guide shows the broker side: one account per client, anonymous access off. From the radar side it is the same four values as always — server address, port 1883, username, password — entered once per device on its own configuration page.

Before you power anything on, build the table. Fill it in from the labels:

Device	DeviceID (MAC, from label)	ClientID (default = MAC)	Account	Room
Fall radar	`AA:BB:...`	default	`radar`	Bathroom
Sleep radar	`CC:DD:...`	default	`radar`	Bedroom
Presence radar	`EE:FF:...`	default	`radar`	Living room

Two habits that save an evening:

Leave the ClientID at its default. The default is already unique, and a custom value is one more thing to get wrong. If you do set one, make it encode the room (bathroom-fall-01) — but then the label is the only place the MAC is written, so record both.
One account per device, or one shared account with a deliberate decision. A shared account is fine for a home; separate accounts matter when you want to revoke one device, or to restrict which topics each one can publish to.

Topics are fixed, so put room identity in Home Assistant

Because the DeviceID is a MAC address, the topic path cannot be renamed per room:

/Radar60FL/<MAC>/sys/property/post      ← fall radar, bathroom
/Radar60SP/<MAC>/sys/property/post      ← sleep radar, bedroom
/RadarHP/<MAC>/sys/property/post        ← presence radar, living room

That is a feature, not a limitation: the MAC is unique forever, so nothing you do later can break the path. The room name belongs in the layer above. In Home Assistant:

Assign each device to the matching area (Settings → Devices & Services → Devices → area).
Rename entities to Bathroom Fall Status, Bedroom Breathing Rate — not Sensor 1, Sensor 2.
Use the device ID to correlate: when a dashboard shows a fall in the bathroom, the entity name and area already say which bathroom.

The result is that a topic full of MAC addresses is still readable to a human, because nobody ever reads the topic.

The gateway is the exception

Everything above applies to finished units, which are configured from their own web page. The ESP32 gateway for UART-only modules is different: it is your firmware. Both the ClientID and the topic — radar/R60ABD1/state — are whatever you set in code, so you are free to name them. See the ESP32-S3 gateway guide.

That freedom deserves a rule, not a free-for-all:

Keep a naming scheme in one place (a comment block, a README, or a spreadsheet) so the next person can decode it.
If you run several gateways, give each a unique ClientID in firmware and a topic that encodes the room, e.g. radar/<room>/state.
Write the scheme on the enclosure label next to the MAC. Six months from now, that label is the only documentation anyone will read.

Stop the radars from arguing with each other

Two radars in adjacent rooms can interfere in ways that look like faulty hardware. The mechanisms are covered in Ghost Targets and Multipath Interference and Radar Position Drift; the practical rules are:

Check coverage before mounting. A finished presence radar covers roughly a 2.7 m radius; the 24 GHz presence module reaches up to about 12 m for a moving person. Two modules in a small apartment will absolutely see each other's rooms.
Shrink the trigger range first. Choosing the smallest scene mode that still covers the room is the single most effective change — see the presence radar guide for the mode table.
Keep metal out of the beam path. Metal doors, mirrors, and appliance housings in the line of sight create reflections that appear as targets.
Aim away from fans, air-conditioner motors, swaying curtains, and pets. These are the usual false-alarm sources in every room.

Commission in this order

Broker first. It has to be running before any radar is configured — that is the prerequisite the setup guide opens with. Confirm with a test client that it accepts a connection.
One radar at a time. Configure it, then verify it on its own: subscribe to /prefix/<MAC>/# with any MQTT client and watch data arrive. Do not add the next device until the first is clean.
Fill in the table (DeviceID, ClientID, account, room) as each device comes online — not afterwards from memory.
Then Home Assistant. Add the MQTT integration, confirm entities appear, assign areas, rename.
Only then build automations. Cross-room logic written before the entities are stable is logic you will rewrite.

Acceptance checklist

[ ] Every device's ClientID is unique (defaults are)
[ ] Every device has credentials that work, and anonymous access is off
[ ] Each device's topic is subscribed and reporting, verified against the MAC on its label
[ ] Two devices left alone for an hour produce no disconnection loop on the broker
[ ] Each room's entities are named and assigned to the right area
[ ] Walk the home once and confirm occupancy, presence and in-bed states change as expected
[ ] Note the mounting position and sensitivity of each unit in the same table

Where to go next

Single-unit setup: Wi-Fi Provisioning & MQTT Setup Guide
The broker: Apache Artemis setup
A worked three-radar example: Aging-in-Place Care System
Hardware wiring without a parser: GPIO vs UART and presence relay wiring
Module specs: 60 GHz / 24 GHz module spec sheet

Finished radars and modules are on Tindie.

Powering and Enclosing a 60GHz Radar Module: Ripple, Grounding, and Antenna Keep-Out

fuxinsuo — Fri, 23 Oct 2026 23:39:31 +0000

The module spec sheet tells you the electrical and mechanical numbers. This article is about what to do with them, because in our experience the first time a radar product fails a test lab, the cause is almost never the sensor — it is the supply, the ground, or the enclosure sitting too close to the antenna.

Everything below applies to the three bare modules we sell. Where a value differs per module it is stated; where the datasheet is the authority, it says so.

Power: the window, the current, and the ripple

Module	Supply	Current	Ripple
R60AFD1-V (fall, 60 GHz)	4.5–5.5 V, typ. 5.0 V	≤ 100 mA avg, ≤ 300 mA peak	≤ 100 mV
R60ABD1 (sleep & breathing, 60 GHz)	4.5–5.5 V, typ. 5.0 V	≥ 200 mA	≤ 100 mV
R24AVD1 (presence, 24 GHz)	see datasheet	see datasheet	see datasheet

Three things to take from that table:

The 3.3 V figure on the pinout is the I/O level, not the supply. UART, S1/S2 and the GP pins are 3.3 V TTL logic. Powering the module from 3.3 V because "the pins say 3.3 V" is a classic mistake.
Ripple ≤ 100 mV is a real constraint. A bare switching regulator at the edge of its tolerance will not meet it. Use an LDO after the switcher, or a linear supply where heat allows.
Budget for peaks, not averages. The fall module draws up to 300 mA in peaks while averaging 100 mA; the sleep module needs 200 mA available. A supply that sags on the peak is a supply that resets the module at the worst moment.

Practical layout order: bulk reservoir → LDO → module VCC, with the decoupling capacitor as close to the module pins as the layout allows. Keep the supply trace short and direct; do not route it past a relay coil or a motor driver.

Two power domains, and they stay separate

If your product switches a load — a light, an HVAC contactor, a buzzer — the module and the load live in separate power domains, as shown in the presence relay article and the PLC dry-contact article:

   Module domain                 Load domain
   5 V, clean  ──► radar          5/12 V ──► relay ──► load
        │                              │
        └──────── single-point ────────┘
                  ground

One ground point where the two domains meet. Two grounds joined in two places make a loop, and the loop current rides on your ground reference exactly where the sensor is most sensitive.
The GPIO pins are weak. S1, S2 and GP1/GP2 are 3.3 V logic at milliamp level. They drive a transistor gate, never a relay coil or a lamp directly — with a flyback diode across any coil you switch.
Opto-isolation is available when the load side is nasty. A high-voltage or long-cable load is worth an optocoupler; the GPIO then only has to drive an LED.

The enclosure is part of the antenna

The 60 GHz modules radiate through their own PCB. The housing around them is part of the RF path, which is why the mounting notes in the guides read like RF instructions:

Non-metallic over the antenna face. Plastic, not aluminium. A metal face in front of the antenna changes the beam and can detune it.
Flat, not curved. A curved surface over the antenna is not supported; keep the face flat and parallel to the board.
3–5 mm from the antenna face to the inner shell surface. Closer loads the antenna; further away wastes the space you needed for the lens or window.
Keep the radar component at least 1 mm above the surrounding PCB parts. The antenna must not be shadowed by a taller component or a ground pour cut that was not planned.
Nothing metallic directly behind or beside the antenna — mounting screws, brackets, and heatsinks all count.

If your product has a lens or radome over the antenna, treat its material and thickness as a design variable and confirm the effect with your own measurements rather than assuming.

EMC basics that matter for this sensor

The radar is a sensitive receiver sitting next to whatever else your product contains. In order of impact:

Distance from switching power. Keep the switcher, its inductor, and its loop area away from the antenna end of the board. This is the single biggest source of broadband noise in a compact product.
Motors and solenoids. A buzzer, a lock, or a fan in the same enclosure couples straight into the measurement. If they must share a board, keep them at the far end and give them their own return path.
Cable routing. Keep the UART pair and any GPIO wires away from the supply wires and from anything switching current. Twist the UART pair if the run is long.
Antenna area is keep-out. No traces, no vias, no pours under or beside the antenna unless your design rules explicitly allow it.
Ground discipline. One solid ground reference for the analog/sensor domain; noisy return currents kept off it.

Why your lab will ask about all of this

These are the same items that decide whether the product passes. The enclosure and the supply determine radiated emissions and band-edge behaviour, and the lab will want your technical file to reflect the configuration you actually ship. The full picture is in Certification Support: Get CE and FCC Made Out to Your Own Name — including what we supply and what stays yours.

Two items from this article are worth telling your lab up front, because they are the ones most often discovered late: the enclosure must be non-metallic and flat over the antenna face, and the modules specify power-supply ripple limits.

A pre-layout checklist

[ ] Supply inside the module's voltage window, with ripple ≤ 100 mV at the module pins
[ ] Peak current budgeted, with a reservoir for the fall module's 300 mA peaks
[ ] LDO after any switcher, decoupling close to the pins
[ ] Module domain and load domain separately supplied, single-point ground
[ ] GPIO driving a transistor, never a coil directly; flyback diode on every coil
[ ] Antenna face over non-metallic, flat material, 3–5 mm from the inner shell
[ ] Radar component ≥ 1 mm above surrounding PCB parts; no metal behind the antenna
[ ] Switcher, inductor and motors at the opposite end of the board
[ ] Mounting height and tilt per the product guide for the variant you chose

Where to go next

All three modules' numbers: 60 GHz / 24 GHz module spec sheet
Wiring a load without writing a parser: presence relay wiring, fall alarm relay, PLC dry contact
Certification path: CE / FCC support
Getting first frames: Bring-Up Checklist

Modules and evaluation units are on Tindie.

Using Distance and Position Output to Debug a Radar Installation

fuxinsuo — Fri, 23 Oct 2026 23:37:32 +0000

Our product guides flag the distance and position outputs the same way every time: they are non-critical functions with limited accuracy. That sentence is often read as "ignore these fields". It means the opposite of what integrators need — these are the most useful numbers you have while installing the sensor, precisely because they are raw and unsmoothed.

This article is the method: what to subscribe to, what a healthy reading looks like, and how to decide between moving the sensor, changing a setting, or removing an interference source.

These values are diagnostic only. Do not build a product feature on them — the documentation is explicit that their accuracy is limited, and a customer-visible feature needs the primary outputs (presence, motion, fall state, breathing) instead.

What you can subscribe to

Signal	Range / cadence	What it tells you
Human distance	0–65535 cm, about every 2 s	Roughly how far the detected target is
Human position	x, y, z, about every 2 s	Where in the beam the target sits
Motion status	0 none / 1 still / 2 active	Whether the target is moving at all
Body-movement level	0–100 (5 s module, 1 s finished)	How much movement, in fixed bands
Approach / leave	1–5, about every 2 s (presence module)	Direction of travel relative to the radar
Presence energy & threshold	fall radar, switchable	How strong the presence detection is firing

The body-movement bands are worth memorising, because they turn a number into a sentence:

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

A correctly aimed radar on a person lying still should sit at 1 %. That single number answers the most common installation question — "is it actually seeing the person?" — without any interpretation.

The method

1. Empty-room baseline

Before anyone is in the room, subscribe and watch for a minute. A healthy sensor in an empty room reports no target: distance absent, body movement at 0 %, motion status 0. If you see a distance, a position, or movement above 0 % with nobody present, you have interference — a fan, an air-conditioner motor, a curtain, or a reflective surface. Find it now, not after the customer calls.

2. Walk the room

Walk slowly from the door to the far wall, then back. Watch three things:

The distance trace should rise and fall smoothly and end near the far wall's real distance.
Body movement should read 31–60 % while walking and drop to 1 % when you stand still.
Motion status should follow: 2 while walking, 1 while standing still.

If the distance stops changing while you keep walking, you have left the beam — that is your coverage edge.

3. Map the coverage edge

Repeat the walk along different paths and mark where the sensor stops reporting. Compare with the documented coverage for your variant: the finished presence radar covers roughly a 2.7 m radius; the 24 GHz presence module reaches about 12 m for a moving person, 6 m for someone sitting, 3 m for a sleeping person; the sleep radar's breathing detection degrades beyond about 1.5 m and disappears before presence detection does.

If the edge is short of where people actually are, that is a mounting or scene-mode problem, not a fault.

4. Verify the aim

For a bed installation, the beam must hit the chest, not the wall: the sleep radar is side-wall mounted at 1.8–2.2 m, or above the bed head tilted 30°–45°, with 45° recommended. Position x/y/z and the body-movement value together tell you whether you got it right — a target that only ever reports 1 % at the edge of the range is a target you are barely seeing.

5. Confirm the empty transition

Leave the room and time it. Declaring a room empty takes about 40 s of confirmed absence, by design; declaring it occupied takes under 0.5 s. If your "empty" transition is much faster, something is being missed.

Red flags and what they usually mean

What you see	Likely cause	First move
Target reported in an empty room	Fan, AC motor, curtain, pet, reflective metal	Remove or re-aim away from the source
Distance jumps around with nobody moving	Multipath from a metal surface or a second radar	Check line of sight; see ghost targets
Distance pinned at a round number (0 or max)	Out of range or field saturated	Move the sensor closer / reduce range
Body movement never drops below 30 %	Beam too wide for the room, or interference	Use a smaller scene mode; lower sensitivity
Still person reads 0 %	Beam missing the chest, or sensitivity too low	Re-aim; raise sensitivity one step
Readings change over weeks with nothing moved	Position drift — new furniture, hanging objects	See radar position drift

Decide in this order

Can I remove the interference? Cheapest fix. Fans and air-conditioner motors in the beam cause most false readings.
Can I move the sensor? Coverage that misses the occupied area is usually a position problem.
Can I shrink the range? The smallest scene mode that still covers the room is the most effective single change — the mode table is in the presence radar guide.
Only then change sensitivity. One step at a time, and note the change. Higher sensitivity catches micro-movement and also picks up curtains and fans.
Room-size adjustment. Below about 15 m², drop sensitivity one step; above about 40 m², raise it one step — small rooms strengthen reflections, large rooms weaken them.

Keep the baseline

Save the empty-room reading and the walk-through trace for every installation. It is the only objective record of what the sensor saw on day one, and it turns "it worked when you left" into a comparison you can actually make.

Where to go next

The fields in full: presence radar guide, sleep radar guide, fall radar guide
Why it behaves this way: How mmWave Radar Works and Radar Latency Explained
Setting expectations on the numbers: Three mmWave Radar Specs That Are Almost Always Exaggerated
Mounting geometry: Sleep Radar Mounting Position
Multiple radars in one home: Running Several Radars in One Home

Finished radars and modules are on Tindie.