Coder Legion - Recent posts tagged radar

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

Sun, 01 Nov 2026 04:34:41 +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

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 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.

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

Fri, 30 Oct 2026 22:40:58 +0000

title: "What Data-Driven Algorithms Changed in Contactless Sleep Sensing, and What They Could Not"
published: true
tags: radar, iot, sleep, health
canonical_url: https://249263431.github.io/60GHz-Radar-SDK/fundamentals/2026/10/31/ai-sleep-staging-radar-limits.html

description: "Sleep staging on a contactless radar went from hand-tuned thresholds to learned models. Here is what that migration actually improved, and the part of the problem it does not touch."

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.

{% cta https://www.tindie.com/stores/fuxinsuo/ %} Check out our mmWave radar modules for sleep and presence sensing {% endcta %}

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

Thu, 29 Oct 2026 22:55:08 +0000

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

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

Full documentation: https://249263431.github.io/60GHz-Radar-SDK/

Modules and finished units: https://www.tindie.com/stores/fuxinsuo/

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

Wed, 28 Oct 2026 23:41:43 +0000

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

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

Full documentation: https://249263431.github.io/60GHz-Radar-SDK/

Modules and finished units: https://www.tindie.com/stores/fuxinsuo/

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

Tue, 27 Oct 2026 23:24:14 +0000

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

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

Full documentation: https://249263431.github.io/60GHz-Radar-SDK/

Modules and finished units: https://www.tindie.com/stores/fuxinsuo/

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

Tue, 27 Oct 2026 23:05:42 +0000

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

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 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 says so rather than filling the gap.

Scope first

Unit	OTA 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. 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 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

"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 read-only — they cannot be written, only read. There is also a request command to solicit 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. Monitoring will read 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 different behaviour at 03:00 is discovered by nobody until morning.

A minimal image host

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 procedural rather than technical: 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

Reading the stream these commands travel on: Reading Radar Data in Your Own Application
Managing many units: Running Several Radars in One Home
The broker underneath it: Apache Artemis setup

Full documentation: https://249263431.github.io/60GHz-Radar-SDK/

Modules and finished units: https://www.tindie.com/stores/fuxinsuo/

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

Tue, 27 Oct 2026 01:03:42 +0000

title: "Online Says It's Connected, HeartBeat Says It Works: Reading Two Status Signals Instead of Guessing From Silence"
published: true
tags: iot, mqtt, radar, monitoring
canonical_url: https://249263431.github.io/60GHz-Radar-SDK/guide/2026/10/27/online-heartbeat-radar-health.html
description: "Two fields in a mmWave radar's MQTT output — online and heartBeat — look like the same health check and are not. One proves the link; the other proves the sensor. And neither supports a timeout."

cover_image:

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.

Radar: A New Kubernetes IDE Worth Knowing About (vs OpenLens, FreeLens)

Wed, 29 Jul 2026 10:00:00 +0000

If you’ve been following Kubernetes tooling, you’ve probably already been through the Lens saga: Lens went commercial, OpenLens emerged as the community fork, then FreeLens appeared when OpenLens maintenance slowed. The pattern is familiar — a useful desktop tool, a licensing decision, a fork, another fork.

Radar is not a fork. It’s a different approach to the same problem: giving engineers a useful interface for Kubernetes clusters without the friction of kubectl for every task. Built by Skyhook (YC-backed, Google Cloud Partner), it’s been live since 2025, has 1.7k+ GitHub stars, releases weekly, and the founder reaches out to the community directly. That’s usually a good signal that someone is genuinely building in public.

This article covers what Radar actually does, where it pulls ahead of OpenLens and FreeLens, and when those tools are still the right choice.

The State of Kubernetes Desktop Tooling in 2026

Before getting into Radar specifically, it’s worth naming the landscape clearly:

Lens — the original. Electron-based, polished, now commercial (Mirantis). The free Personal tier is non-commercial only. Pro is ~$22-35/user/month.
OpenLens — the community fork of Lens before Mirantis closed exec/logs/shell in v6.3 (January 2023). Maintenance has slowed significantly. No active release cadence.
FreeLens — a more active community fork, filling the gap left by OpenLens’ decline. Restores the missing features. No commercial backing.
k9s — terminal TUI, fast, keyboard-driven, single-cluster. Different audience.
Headlamp — CNCF Sandbox project, plugin-extensible, web-based.
Radar — Go binary, Apache 2.0, team-oriented, topology and event timeline focused.

The problem with OpenLens and FreeLens is not that they’re bad tools — they’re genuinely useful for the solo developer with one or two clusters. The problem is that they’re single-cluster-at-a-time desktop apps with no concept of team, no persistent state, and no awareness of the modern Kubernetes ecosystem (ArgoCD, Flux, Karpenter, KEDA). As your infrastructure grows, you outgrow them.

What Radar Actually Is

Radar is available in two forms:

Radar OSS — a single ~30MB Go binary, Apache 2.0, free forever. Can run locally (desktop app) or deployed in-cluster via Helm. No sidecars, no feature gates.
Radar Cloud — same binary, adds a hosted control plane with fleet aggregation, 30-day event retention, SSO/SCIM, scoped RBAC, and shared URLs for team incident response. Priced per cluster ($99/cluster/month for Team), not per user.

The per-cluster pricing is a deliberate design decision — teams don’t pay more as they add engineers, only as they add clusters. For a 20-person platform engineering team managing 5 clusters, Radar Cloud runs $495/month. The equivalent Lens Pro seats would cost $2,200-4,200/month.

For most self-hosted environments, the OSS version is sufficient and costs nothing.

Key Features

Topology View

This is the most visually distinctive feature. Radar renders a live service graph for your cluster: deployments, services, ingresses, cross-namespace dependencies, and east-west traffic flows — all in a single view without running kubectl get all -A and stitching the output together mentally.

OpenLens and FreeLens have resource list views. They show you what exists. Radar shows you how things connect — which is what you actually need when debugging why Service A can’t reach Service B.

Persistent Event Timeline

Kubernetes events are ephemeral by default — they expire after approximately one hour. When something breaks at 2am and you’re looking at it at 9am, the events that explain what happened are gone. Logs may still be there if you’re running a log aggregator, but the Kubernetes-level events (pod restarts, scheduling failures, node pressure events, probe failures) are gone.

Radar retains events. The OSS version extends this beyond the default 1-hour cluster retention. The Cloud version retains 30 days. You can rewind the timeline to any point and reconstruct what the cluster looked like at that moment.

Neither OpenLens nor FreeLens have any event retention beyond what the cluster itself provides.

GitOps Integration (ArgoCD + Flux)

Radar auto-detects ArgoCD and Flux and surfaces sync state, drift, and health directly in the UI. You can see whether a deployment is in sync, when it last synced, and whether it drifted from the desired state in Git.

In OpenLens and FreeLens, ArgoCD resources appear as generic Kubernetes custom resources. You can see the CRDs, but there’s no purpose-built understanding of what they mean — no sync status visualization, no diff view, no rollback trigger.

Helm Management

Radar tracks Helm releases with full revision history and supports one-click rollbacks from the UI. This is similar to what OpenLens/FreeLens offer via the Helm releases view, but Radar adds revision diffing — you can see what changed between release 5 and release 6 before deciding to roll back.

Image Filesystem

You can browse container image filesystems through Radar without needing kubectl exec into a running pod or access to the container registry. Useful for security audits and debugging — you can verify what’s actually in an image at rest.

MCP Server (AI Integration)

Radar ships with an MCP (Model Context Protocol) server, which means you can connect Claude, Cursor, or GitHub Copilot directly to your cluster context and ask questions about it in natural language. The MCP server is token-optimized — it doesn’t dump raw YAML at the model, it structures cluster state into meaningful context.

This is something neither OpenLens nor FreeLens have. It’s also something that’s genuinely useful if you’re already using AI assistants for development work.

Cluster Audit

30 built-in best-practice checks — resource requests/limits, RBAC permissions, image pinning, network policies, security contexts. The checks are labeled by compliance framework. This is not a replacement for dedicated security tooling (Trivy, Falco, Polaris), but it’s a useful first-pass audit without leaving the tool you’re already using.

Multi-Cluster Support (Cloud)

The Cloud tier adds fleet-level visibility: a single view across all clusters, cross-cluster search, and drift detection between environments (e.g., staging vs. production). This is the feature that changes the calculus for platform engineering teams managing 5+ clusters.

OpenLens and FreeLens require you to switch cluster context manually. There is no fleet view.

Architecture: Why a Go Binary Matters

OpenLens and FreeLens are Electron apps — Chromium + Node.js wrapped in a desktop shell. This means:

200-500MB install size
1-2 second startup time on a fast machine, more on slower ones
Memory footprint in the hundreds of megabytes
Local kubeconfig required on each engineer’s machine

Radar’s in-cluster deployment is a single Go binary (~30MB) that runs as a Pod with a ServiceAccount. It connects to the hosted control plane over outbound WebSocket + TLS. No inbound firewall rules, no kubeconfig distribution, no per-engineer setup.

The local desktop app is also a lightweight Go binary — 65-second startup was demonstrated on a 322-node cluster. That’s not a typo.

For in-cluster deployment, the architecture means security is handled at the ServiceAccount level, not by distributing kubeconfigs to engineer laptops. That matters for teams with security requirements around credential management.

Feature Comparison

Feature	Radar OSS	Radar Cloud	OpenLens	FreeLens
License	Apache 2.0	Proprietary (hosted)	MIT/GPL	MIT
Maintenance	Active (weekly releases)	Active	Stalled	Active (community)
Architecture	Go binary / in-cluster	In-cluster + hosted	Electron	Electron
Multi-cluster	Basic	Fleet view
Event retention	Extended	30 days	Cluster default (~1h)	Cluster default (~1h)
Topology view
GitOps (ArgoCD/Flux)			CRDs only	CRDs only
Helm management
kubectl exec / logs / shell			(restored)
MCP / AI integration
Cluster audit
SSO / SCIM
Shared incident URLs
Image filesystem browser
Cost tracking	(OpenCost)
Price	Free	$99/cluster/month	Free	Free

When Radar Makes Sense

You’re managing multiple clusters. Even with the OSS version, the topology view and event timeline make Radar more useful than OpenLens/FreeLens at 3+ clusters. The Cloud fleet view is the compelling option at 5+.

Your team uses GitOps. If ArgoCD or Flux is part of your workflow, Radar’s native understanding of sync state and drift is meaningfully better than seeing CRDs in a generic list view.

You need post-mortem capability. If your incident review process involves looking at what the cluster was doing when the alert fired, you need event retention. Radar has it; OpenLens and FreeLens don’t.

You’re adopting AI tooling. The MCP server is the most forward-looking feature here. If you use Claude Code, Cursor, or Copilot for your infrastructure work, having cluster context available to those tools without copy-pasting YAML is a genuine productivity improvement.

You have a platform engineering team. Per-cluster pricing, SSO, SCIM, and shared incident URLs are features that only matter if you have more than one person managing infrastructure.

When OpenLens or FreeLens Still Makes Sense

You’re a solo developer with one or two clusters. OpenLens and FreeLens are familiar, local, and have zero setup overhead. If you don’t need team features, event retention, or topology views, they remain perfectly functional tools.

You’re deeply invested in the Lens UX. The resource tree, the terminal integration, the way Lens presents namespace-scoped resources — if your muscle memory is built around that interface, switching has a real cost. Radar is different, not just better.

You need maximum customi

Coder Legion - Recent posts tagged radar

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

Step five is a chain, not a message

Two networks, not two vendors

What the telecom path gives you

1. Nothing is required of the recipient

2. It does not depend on a data connection

3. The retry belongs to someone else

4. An answered call is an acknowledgment

5. Delivery you can measure

6. The alerting logic stays yours

What it looks like assembled

The first half of the chain is not immune

What telecom channels do not solve

Where to go next

A note on what this is

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

description: "Sleep staging on a contactless radar went from hand-tuned thresholds to learned models. Here is what that migration actually improved, and the part of the problem it does not touch."

The hand-tuned era

What learning from data changed

What did not change

What the radar actually publishes

How to read the output

Where to go next

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

What a channel count means

Angular resolution

Coherent combining gain

Elevation

What a channel count does not decide

What the three jobs actually require

Why more channels are not automatically better for home monitoring

When more channels are genuinely needed

Choosing for the job

Checklist

Summary

Where to go next

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

Two quantities, not one

The geometry

Axis pointing straight down

Axis tilted

Presence module: R24AVD1, ceiling

Fall module: R60AFD1-V, ceiling

Sleep module: R60ABD1, tilted above the bed

Why the two numbers diverge

What geometry does not tell you

Verifying it on site

Checklist

Where to go next

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

Range

The underlying idea: round-trip time

Why the time is not measured directly

How it is done instead: FMCW

What sets how finely two targets can be separated

Velocity

The Doppler effect

The equation

Wavelength from the published frequency

Shift magnitudes in practice

Where sub-millimetre sensitivity comes from

Three parameters that set precision and span

Published output cadences

The two bands side by side

What this accounts for

Summary

Where to go next

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

Scope first

Three commands

Confirming the result

Running an update

A minimal image host

What the documents do not say

Checklist

Related reading

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

cover_image:

Why this distinction is not academic