-
-
Notifications
You must be signed in to change notification settings - Fork 12
FAQ
This is the single biggest change in v6.x and worth answering in depth. The short version: the dual-device architecture added latency we couldn't tune away, friction at install time, and was solving a problem the LD2450 makes go away by itself.
v6.0.0 (the dual-device release on main) shipped a peer mesh:
- Every device read its own LD2410 (single-target distance sensor) over UART, smoothed it locally, and broadcast the result on ESP-NOW at 5 Hz to its peers.
- Every device ran the same fusion algorithm locally on the merged peer stream — so every device arrived at the same "where is the active person" estimate without needing a leader to compute it.
- A coordinator (lowest-MAC peer) hosted the canonical web UI; mDNS resolved
ambisense.localto whoever was elected. - The user paired devices by holding a 3-second BOOT-button press, which opened a 30-second pairing window and accepted broadcasts from new peers.
- A
topologyblob in NVS described which device owned which LED segment range (for asymmetric stairs — e.g. a 3-step landing + 12-step main flight).
It worked. It also took five HTTP endpoints, two FreeRTOS components (mesh/ and topology/, ~600 lines each), a Mesh tab in the web UI with pairing countdown SVG and identify-blink button, two NVS namespaces, and four LED status patterns.
Two structural problems surfaced when we benched it on real U-shape and L-shape stair installs:
1. ESP-NOW round-trip jitter cost too much of the LED-render budget.
For "lights follow you" to feel instant, sensor → MCU → LED needs to complete inside ~50 ms. Inside one device, that budget breaks down roughly:
| Stage | Time |
|---|---|
| Radar UART parse | ~5–10 ms |
| Motion Kalman update | ~1–2 ms |
| LED render + WS2812 refresh | ~3–5 ms |
| Total local | ~10–17 ms |
When the second sensor's reading was authoritative (which depends on the fusion mode), an ESP-NOW round-trip got added on top:
| Stage | Time |
|---|---|
| ESP-NOW best case (no retry) | 5–15 ms |
| ESP-NOW with retry under busy 2.4 GHz | 50–100 ms |
So the fused-frame latency was 15–117 ms depending on RF conditions. The Kalman filter could mask brief outliers, but sustained jitter under retry storms (microwave on, neighbour's Wi-Fi camera streaming, etc.) was visible as "lag" — installers reported it as "the lights take a moment to catch up sometimes". On a hallway it was ignorable; on stairs, where you're focused on foot placement, it was annoying.
2. The LD2450 made the second sensor redundant.
The HiLink LD2450 reports up to 3 simultaneous targets as (x_mm, y_mm, v_mm/s) within a 60° horizontal cone, ~6 m range — i.e. real 2-D position, not just distance. Mounted at the inside corner of an L or the centre-back of a U, both arms of the LED run sit inside that cone. One sensor with x/y data covers what two single-target LD2410 sensors needed mesh fusion to do.
The dual-device architecture made sense when the only affordable radar was the LD2410 (single-target distance). With LD2450 ~$15 in 2026, we no longer pay for two sensors + two MCUs + the wireless hop to cover an L or U.
3. The install friction wasn't worth what it bought.
A real install with v6.0 went:
- Buy 2× C3 + 2× LD2410 + 2× LED PSUs + 2× enclosures.
- Wire and mount both, both somewhere with line-of-sight to the LED segment they own.
- Power on both, navigate the captive portal twice.
- Hold BOOT 3 s on either one to open the pairing window.
- Wait for the mesh to converge and decide who's coordinator.
- Open the Mesh tab on the coordinator, edit topology kind + segment ranges + per-segment distance windows.
- Hope the two sensors stay synced and one doesn't drop off Wi-Fi.
A real install with v6.x:
- Buy 1× C3 + 1× LD2450 + 1× LED PSU + 1× enclosure.
- Mount at the inside corner / centre-back with line-of-sight to both arms.
- Power on, captive portal once.
- Done.
Single-sensor mode requires the LD2450 to have line-of-sight to both arms of the LED run. That's a real installation constraint — for an L-shape stair, you mount at the inside corner, not anywhere on the outside arm. For arms longer than 5 m, you range-test at the far end before locking the kit configuration, because the LD2450's effective range degrades for off-axis targets at long distance.
We chose to take that constraint in exchange for: simpler firmware (−1569 lines), simpler install, lower BOM cost, and ~30 ms shaved off worst-case latency. It's the right trade for a kit product. See the LD2450 Mounting Guide for the geometric details.
For consumer kits, no — we want a single supported topology so the install instructions are unambiguous. For tinkerers who want to experiment with multi-sensor in their own builds, the v6.0.0 source is preserved on main and the v5 Arduino source is on legacy/v5-arduino.
The LD2410 is single-target distance-only. With v6.x's single-sensor architecture, we need (x, y) position to map a target to a 2-D LED layout — distance alone can't tell you which arm of an L-shape strip to light up. The LD2450 reports x/y/speed natively. Removing the LD2410-family drivers (ld2410, ld2412, ld2420) was the right call once we locked single-sensor: those drivers existed in v6.0 to support cheap single-target sensors that fused via the mesh.
The sim driver (synthetic distance traces) is retained for desk testing without a radar attached.
v6.0 recommended the ESP32-S3 because dual-device peer mesh + per-peer fusion + ESP-NOW broadcast on a single C3 core ran hot under load. With the mesh removed, the C3's single core has plenty of headroom for radar UART + Kalman + LED render + Wi-Fi/HTTP. The C3 SuperMini has the smallest package, native USB-Serial-JTAG (no CH340 driver hassle), and ~$3 BOM cost — making it the right default for a kit product.
The S3 / classic ESP32 / C6 board profiles still build clean and you can run the firmware on those if you have one, but the v6.x kit PCB is targeting the C3.
Picture a moving spotlight ~30 cm wide that tracks your position on the strip. As you walk forward, the bright cluster slides forward; as you stop, it stops. There's a soft trailing fade behind you (configurable). When two people are on the strip, the LD2450 sees both and a future v6.x release will support multi-target rendering — for now the firmware tracks the closest target.
You can also pick from 10 other light modes: rainbow, breathing, comet, chase, etc. — see LED Modes.
Tested up to 300 LEDs per device. The architectural limit is ~1500 LEDs (RMT framebuffer), but you'd need careful power injection at multiple points and the visual effect of a 1500-LED hallway is its own design problem. For most installs (a staircase, a hallway, under-bed) you're well under 100.
LED current draw rule: budget 60 mA × N at full white. A 100-LED strip wants a 5 V / 6 A PSU; in practice with brightness ≤ 100/255 you're well under that. Do not power LEDs from the C3's 5 V pin — use a separate PSU for the strip and tie grounds.
MQTT publisher with Home Assistant auto-discovery is on the v6.x roadmap. Toggle in System → Integrations once shipped. Until then, the HTTP API works with HA's REST sensor:
sensor:
- platform: rest
resource: http://ambisense-XXXX.local/api/distance
name: AmbiSense Distance
unit_of_measurement: cm- Web UI auth: PBKDF2-SHA256 (250k rounds). Off by default until you set a password (banner in the UI nags you until you do).
- Wi-Fi password storage: stored in NVS plaintext in v6.x. Encrypting with a chip-derived key is on the roadmap.
-
OTA: unsigned in v6.x. Signed-OTA with
esp_secure_bootis on the roadmap. - Telemetry / phone-home: never. The firmware doesn't talk to anything except your local network and the radar.
Today: LD2450 only on shipping hardware (or sim for testing). The driver registry in firmware/components/radar/ is set up so adding a new sensor is +1 file + 1 dropdown entry. If you want to bring up an LD7901 or a Seeed Studio mmWave module, it's a self-contained change. PRs welcome.
A lot. v6 is a ground-up rewrite onto ESP-IDF + FreeRTOS:
- Independent FreeRTOS tasks for radar, motion, LED render, web — no more cooperative
loop()starving the LEDs under HTTP load. - NVS-based settings (atomic, journaled, typed) — no more EEPROM byte-offset hacking.
- OTA, captive portal, auth — none of which v5 had.
- Modern Preact web UI on phone + desktop instead of v5's plain HTML.
- LD2450 multi-target tracking instead of LD2410 distance-only.
The visual modes carry over with v6's improvements (real Kalman smoother, 60 Hz render, no rebuild-the-strip-on-every-config-change cost).
If you want to keep running v5, the source is preserved on the legacy/v5-arduino branch and under legacy/AmbiSense/ in the repo. v5.1.1 binaries are still attached to the v5.1.1 release.
Open an issue — we read all of them. PRs welcome too.
Get started
Use it
Help
Upgrading
Reference