Which sensors are passive and contactless?

The LD6004 mmWave radar (3D position), the MR60BHA2 mmWave radar (heart rate and breathing), and ESP32 WiFi CSI nodes (presence and rough shape). None are worn or attached to a person.

How many sensors do I need?

Almost nothing works with one. WiFi CSI needs at least 3 nodes (7 ideal) to locate anything; radar is 1-3 depending on room coverage; vitals is 1 per person/spot.

Do I have to flash the sensors first?

ESP32 CSI nodes must be flashed on a Mac/PC and given WiFi credentials before they stream to your Seed. The MR60BHA2 ships pre-flashed (configure WiFi via ESPHome). The LD6004 radar needs no flashing at all — four jumper wires to the host's GPIO header and it streams 3D positions.

Cognitum One Sensor Primer — ESP32, mmWave Radar & WiFi CSI Sensing Explained

Q: What is a Cognitum One Seed?

A tiny, self-contained AI computer that senses the space around it and recognises patterns passively, with no cloud required. It is the brain; the sensors in this guide are its senses.

▶ START HERE

New to all this? Your first 3 steps.

There's a lot on this page, but the actual path is short. Do these three in order — everything below is reference you can dip into whenever you need it. Prefer it all walked end-to-end? Take the full guided walkthrough →

Set up your Seed

~3 minutes in your browser — no app. Get the brain online before any sensors. ↓ jump to it

Get the Starter Kit

~$60 buys the exact sensors + cables for your first signal. ↓ see the kit

Flash & connect

Point your first sensor at the Seed and watch it light up. setup & flashing →

01 — ORIENTATION

What is a Cognitum One Seed?

Before sensors, understand the thing you just unboxed. The Seed is not a sensor itself — it's a brain.

The Cognitum One Seed is a tiny, self-contained AI computer — it runs on-device intelligence with no cloud required. It senses the space around it, remembers what it learns as mathematical "fingerprints," and can recognise patterns passively — just by watching, never by asking you to scan or wear anything.

Out of the box it has a few simple built-in senses. But the moment you want to sense finer things — exactly where a body is, a heartbeat through the air, the shape of a person with no camera — you connect the sensors in this guide. Some wire straight into the Seed's pins; the richer ones connect to the same Seed over USB or WiFi (that's the next section).

▸ Learn more about the Cognitum One Seed at cognitum.one

🎬 Prefer to watch or listen? There's an ~8-minute explainer video, a podcast-style audio overview and two infographics that show how this passive WiFi sensing actually works — play them right here, no download ↓

⚡ DAY ONE — DO THIS FIRST

Just unboxed it? Set it up in your browser — no app, ~3 minutes

Before any sensors, get the Seed itself online and claimed. There's a guided web setup that walks you through it step by step — nothing to install:

Say hello — your laptop connects to the Seed over Bluetooth (so it never touches your WiFi yet).
Prove it's really yours — you match a short fingerprint on screen to the code printed on the device. This is what stops anyone else's device pretending to be yours.
Get it online — pick your WiFi and type the password; it's encrypted on your machine before it's sent to the Seed.
Make it yours — claim it to your account and you get a private address to reach it.

▸ Open the Seed setup wizard → cognitum.shaal.dev

This is the guided first-run flow for the Seed (it links back to cognitum.one). The fingerprint-match step in #2 is your safety check — only continue if the code on screen matches the one on your device. Prefer the official link from your Seed's packaging if it differs.

Wait — why run this on a tiny computer instead of my Mac?

Fair question, and worth answering before anything else: the software is the same everywhere — nothing the Seed runs couldn't run on your Mac, and your Mac is enormously faster. But for this job, power isn't gigahertz. Your Mac is powerful and sealed: the OS locks away its WiFi chip's sensing data, there are no GPIO pins to wire a sensor into, the radio is untouchable, and the whole machine sleeps when you close the lid and leaves the room in your bag. Why use a less powerful computer to run the same software? Because you want more control over the hardware. A humble computer you fully control beats a powerful one you don't.

So use both, each for what it's for. Your Mac stays the brain whenever you want it — dashboards, training, heavy lifting. The Seed is the body that never sleeps: pins exposed, paired with open ESP32 radios, sipping ~2 W in the corner, building a permanent witnessed memory around the clock. That trade — compute you can get anywhere, for hardware control you can't — is the power of the Cognitum One Seed.

Two computers side by side: your Mac/PC is powerful but sealed (CSI locked by the OS, no GPIO pins, sleeps and moves around, untouchable radio) while the Cognitum Seed/V0 is humble but open (GPIO pins to wire sensors directly, pairs with open ESP32 radios, always-on at about 2 watts, permanent witnessed memory, yours to control). Punchline: power here is not gigahertz — power is control over the hardware the software can touch. — Power here ≠ gigahertz. Power = control over the hardware the software can touch.

ASCII version (for AI/accessibility)

YOUR MAC / PC — powerful, but sealed       COGNITUM SEED / V0 — humble, but OPEN
  [LOCKED] CSI — locked by the OS            [OPEN] GPIO pins → wire sensors directly
  [LOCKED] GPIO pins — none                  [OPEN] pairs with open ESP32 radios
  [LOCKED] sleeps / moves around             [OPEN] always-on, sips ~2 W
  [LOCKED] radio you can't touch             [OPEN] permanent witnessed memory
                                             [OPEN] yours to control
  Power here ≠ gigahertz. Power = control over the hardware the software can touch.

Full explanation: Why separate hardware?

🧠 The Seed = the brain

Runs everything locally. Turns raw sensor numbers into memory.

On-device vector memory (remembers patterns as "fingerprints")
Passive recognition — learns what's present without enrollment
Local search & reasoning, no internet needed
A tamper-evident "witness chain" so its memory can be trusted

⟶
SENSES FEED BRAIN

📡 The sensors = the senses

Each one perceives a different slice of physical reality — all contactless.

Radar (LD6004) — where a body is in true 3D, how it moves (no camera, works in the dark)
mmWave vitals (MR60) — heart rate & breathing, through clothing, across a room
WiFi CSI (ESP32) — a body's rough shape & presence, even through walls

The mental model: the Seed is the brain, the sensors are the senses. Everything in this guide plugs into the left side.

02 — HOW IT SENSES

How sensors actually reach the Seed

The part most guides skip. There are two ways a sensor's data gets to your Seed, and picking the right one saves you days.

Two paths in. Simple sensors wire into the Seed's pins; rich radar & WiFi-CSI connect to the same Seed over USB or WiFi.

Path A — wire it straight into the Seed

The Seed reads simple sensors bolted to its own pins, 10 times a second, into its memory "fingerprint." Works on the Seed today, no extra computer.

Digital pins (GPIO): motion (PIR), vibration, a door/reed switch
Analog sensors via an ADS1115 ADC on the I²C bus (a ~$5 chip)
Declared in the Seed's sensor-config.json, sampled at 10 Hz

Path B — connect it to the Seed over USB / WiFi

The richer sensing — WiFi-CSI and the 60 GHz vitals — needs more bandwidth (and WiFi itself) than the Seed's GPIO pins can carry, so it connects to your Cognitum One Seed over USB or WiFi and the Seed does the heavier work. The LD6004 radar is the low-rate exception — it's plain serial, so it wires straight to the GPIO header (below).

The LD6004 radar wires to the host's GPIO header (four jumper wires, plain serial)
The MR60 & ESP32 CSI nodes stream to the Seed over WiFi
The Seed fuses everything into its memory

⚠ The honest truth about WiFi CSI & the Seed

A Seed's own built-in WiFi chip cannot produce CSI — that's why WiFi-sensing needs separate ESP32-C6 / S3 nodes (which can) that stream their CSI to the Seed over WiFi. Plan for 7 nodes — not two; one or two can't locate anything (here's how to build the array). The full step-by-step is on the Setup & flashing page →

⚠ Seed vs. V0 — you can't HAT your way to WiFi 6E / WiFi 7 sensing

The base Seed is a Raspberry Pi Zero 2 W. It has GPIO pins (so simple wired sensors are fine), but no PCIe bus — which means no HAT exists that can attach an Intel AX210 (WiFi 6E) or BE200 (WiFi 7) M.2 radio to it. Those cards need the PCIe-to-M.2 E-Key adapter HATs, and those HATs plug into the PCIe ribbon connector found only on the Pi 5.

So the rule of thumb: high-fidelity WiFi-6 CSI from ESP32-C6 nodes works with any Seed (the nodes stream over your network — the Seed's own radio never matters). Mounting an Intel card in the brain at all requires the V0 appliance (the Pi 5 + Hailo-8 unit), where the M.2 card rides a PCIe HAT — and even then, treat it as an experiment: the public CSI tools for the AX210 (PicoScenes, FeitCSI) are built for x86 Linux and are unproven on the Pi 5's ARM, and no public tool extracts CSI from the BE200 (WiFi 7) yet — on any machine. If you only have a Seed, stick to the ESP32 node path; if you have a V0, the Intel cards are a frontier to explore, not a supported feature.

"But why an Intel card at all? My Mac's WiFi is way beefier." Beefier for networking, useless for sensing — and the reason is software, not silicon. CSI lives deep inside the radio chip, and macOS/Windows drivers simply never expose it (Apple's especially). The only reason the AX210 exists in this story is that Linux research tools (PicoScenes, FeitCSI) can pry CSI out of that specific chip on an x86 Linux box. Your Mac's gorgeous card has no such door. And one more honest layer: RuView doesn't ingest AX210 CSI anyway — its supported host-NIC research paths are the older Intel 5300/Atheros; on a Mac/PC, RuView's host mode is RSSI-only (coarse presence, no vitals). So the practical mapping is simple: ESP32 nodes are your sensors, they stream to wherever the sensing server runs (laptop or V0), the Seed stores the memory — and the Intel cards stay in the drawer until you deliberately want a Linux CSI research detour.

Your mileage may vary: the exact pins, ports and config names here come from one reference build. Always confirm against your own device's config and firmware.

02.5 — WHY SEPARATE HARDWARE?

Your Mac has WiFi. Why do I need these little boards at all?

The question everyone is too polite to ask — and the single most useful thing to understand before you buy anything. Your laptop's WiFi card is bigger, faster and more expensive than a $5 ESP32. So why can't it do the sensing?

Networking sees signal strength. Sensing needs the wave itself.

Everything you've ever done with WiFi — the bars on your phone, "connected, good signal" — runs on RSSI: a single number that answers is there a signal, and how strong is it. RSSI can tell you a router exists. It cannot tell you that a person just walked between you and it.

Sensing needs CSI — Channel State Information: the per-frequency amplitude and phase of how the radio wave bent, bounced and stretched around bodies on its way to the antenna. That's where the "seeing" lives — dozens to hundreds of measurements per packet instead of one number — and it lives inside the radio chip.

⚠ Your Mac computes CSI right now — and will never give it to you

Here's the maddening part. Every WiFi chip must compute CSI constantly just to decode WiFi at all — it's how the receiver undoes what the room did to the signal. Your Mac, your PC, your phone: all of them calculate exactly the data this hobby needs, thousands of times a second, and then throw it away inside the chip. The OS and drivers simply never hand it to you — Apple's especially. The door is locked in software, not missing in silicon. That's why buying a "beefier" WiFi card changes nothing: you'd be buying a fancier chip with the same locked door.

The ESP32 is the magic exception

A $5 chip whose maker, Espressif, ships an official API that hands you the raw CSI. That is the entire reason this hardware exists. An ESP32 is not a better radio than your Mac's — it's a far worse one, by every networking measure. It's an open one. You're not buying performance; you're buying the key to the door every other chip keeps locked.

And the Seed? Nothing magical there either

The Seed's own WiFi is just as locked as your Mac's — its radio never senses anything. The Seed is the memory / witness / MCP appliance. If you have ESP32 nodes and any laptop, you can run the full sensing experience — dashboards, vitals, pose — with no Seed at all (that's network-only mode). The Seed adds permanent queryable memory, not sensing ability.

Radio	Networking	Sensing (CSI)	Role in this stack
Your Mac / PC / phone WiFi	excellent	RSSI only — CSI is computed but locked by the OS	The brain: runs the dashboards & sensing server. Never the antenna.
ESP32-C6 / S3 the sensor	basic (doesn't matter)	full raw CSI exposed via Espressif's API	The only affordable open radio — ~$5 each, the whole point
Cognitum Seed	ordinary	no sensing role — its radio never senses	Memory + witness chain + MCP — the part that remembers
Intel AX210 on Linux	excellent	CSI via research tools (PicoScenes / FeitCSI) — x86 Linux only	A research door, not used by RuView — stays in the drawer

So when you see Ruv's demos: the WiFi doing the seeing is always ESP32s. Your computer is the brain reading them, never the antenna.

If it looks like…	It's…	It does…
A stamp-sized board with a metal shield + pin headers + USB-C	ESP32-C6 / S3 CSI node	WiFi sensing
A small radar board with a 4-pin cable (jumper wires)	LD6004	3D position & movement tracking
A small black module behind a textured cover, USB-C	MR60BHA2 (Seeed XIAO)	Heart & breathing
A small grey stick with a screen, a button & USB-C	M5StickS3	Motion / vibration

04 — THE FOUNDATION

The ESP32 family: the chip behind almost everything

Most affordable sensors are built around an ESP32 — a cheap WiFi/Bluetooth microcontroller from Espressif. Knowing the variants tells you what a sensor can and can't do.

Chip	Architecture	Cores / Clock	SRAM	WiFi	Bluetooth	Standout feature	~Price
ESP32 original	Xtensa LX6	2 · 240 MHz	520 KB	802.11n · 2.4 GHz	Classic + BLE 4.2	The mature, do-everything default	$3–10
ESP32-S2	Xtensa LX7	1 · 240 MHz	320 KB	802.11n · 2.4 GHz	none	USB-OTG; far better deep-sleep	~$6
ESP32-S3 used here	Xtensa LX7	2 · 240 MHz	512 KB	802.11n · 2.4 GHz	BLE 5.0	AI/vector instructions; 64-subcarrier 802.11n CSI	~$4
ESP32-C2	RISC-V	1 · 120 MHz	272 KB	802.11n · 2.4 GHz	BLE 5.0	Smallest & cheapest, 4×4 mm	~$4
ESP32-C3	RISC-V	1 · 160 MHz	400 KB	802.11n · 2.4 GHz	BLE 5.0	Best-in-class low power (~5 µA sleep)	~$4
ESP32-C5	RISC-V	1 · 240 MHz	400 KB	Dual-band WiFi 6 · 2.4 + 5 GHz	BLE 5.2	First ESP32 with 5 GHz — but no RuView firmware support	~$18
ESP32-C6 buy this one	RISC-V	1 · 160 MHz	512 KB	WiFi 6 (ax) · 2.4 GHz	BLE 5.3	242-tone HE-LTF CSI (4× the detail) · 802.15.4 mesh time-sync · also inside the MR60	~$5
ESP32-H2	RISC-V	1 · 96 MHz	256 KB	none	BLE 5.0	Dedicated Thread/Zigbee mesh radio	~$3
ESP32-P4	RISC-V ×2 + LP	2 · 400 MHz	768 KB	none	none	H.264 video, MIPI camera/display	n/a

The one fact that bites everyone first

Notice the 2.4 GHz vs. 5 GHz column. The ESP32-S3, C6 and the original ESP32 are 2.4 GHz only — by silicon. They physically cannot join a 5 GHz-only WiFi network, no matter what you configure. If a board "won't connect" to your fast network, that's almost always why — it's not broken, it's the wrong band.

⚡ June 2026 buying verdict: skip the C5, go straight to the C6

This changed in the last few weeks, so older advice (including ours) is out of date. Two facts decide it: (1) RuView has no ESP32-C5 firmware — the CSI node firmware builds for the S3 and C6 only, so a C5 simply can't join your sensing array today. (2) The C6 became the fidelity king — RuView's v0.8.0-esp32 release (June 11, 2026) unlocked true WiFi-6 HE-LTF CSI on the C6: 242 active tones, 4× the spectral detail of the S3's best, on any 802.11ax 2.4 GHz router. Ruv's own release notes call the C6 "the precision instrument of the fleet."

So the play is: C6 nodes for fidelity (~$5, e.g. the Seeed XIAO ESP32-C6), S3 nodes as cheap workhorses, and the C5 only if you specifically want to experiment with 5 GHz capture outside RuView. C6 caveats: build with ESP-IDF 5.5.2+, you need WiFi 6 enabled on your router's 2.4 GHz band for full fidelity, and there's no over-the-air update — reflashing is by USB.

05 — THE SENSES

The sensors — and what each one gives you

An ESP32 is just the brainstem of a sensor. What matters is the physics module bolted to it. Here are the sensors you can buy and use today — start with the ESP32-S3 / C6 WiFi-CSI nodes (the core of the system), then the radar, vital-signs and legacy options. Each has the real product photo and a direct buy link.

A human body sensed by invisible radio waves, reconstructed as a glowing point cloud — Radar and WiFi can "see" a body with no camera — by reading how radio waves bounce off it.

⚠ Read this first: one sensor is almost never enough

The expectation-setter nobody tells you. A single sensor gives a single, narrow viewpoint — a lone WiFi node can tell "something moved" but not where. Plan for multiples from the start, or you'll be disappointed.

Sensor	Bare minimum	Recommended	Why one won't do
ESP32 WiFi CSI	3 nodes	7 (3 on 2.4 GHz + 4 on 5 GHz)	One node only senses "something changed." Position & shape need several sightlines to triangulate; 7 wraps the room with a spare.
LD6004 radar	1	1 per room	One corner-mounted unit covers the activity cone in 3D. A second only helps mounted across the room on its own host (occlusion cover) — phase-2, not starter.
MR60BHA2 vitals	1	1 per seat/spot	It reads one subject facing it — it can't follow someone moving around the room.
M5StickS3 (IMU)	1	1–2	One reads an object's motion; two let you compare two points (e.g. how vibration travels from a source to a body).

Minimums are physics: three is the geometric minimum to locate a point in 2D (you need sightlines from three directions to triangulate); seven gives full wrap-around coverage with a spare node. "Recommended" reflects a working whole-room build.

WiFi CSI · presence & shape

ESP32 CSI nodes

ESP32-C6 (WiFi 6, 242-tone — the pick) & ESP32-S3 (workhorse)

The cleverest trick here: an ordinary WiFi chip reads how radio waves scatter off your body (Channel State Information). With several nodes you get rough body shape, presence, and breathing — through walls, with no dedicated radar at all.

NEED: 3 minimum · 7 ideal
SENSES: Presence, coarse pose, breathing, identity hints
SETUP: Flash on a Mac/PC, then WiFi (see Setup)
CONNECTS: WiFi → Seed over UDP 5005

Gotcha → Use a mesh of nodes; one node alone can't tell left from right. These must be flashed first — see the Setup & flashing page.

Buy XIAO ESP32-C6 3-pack (buy 7 nodes total) ↗ Buy ESP32-S3 3-pack (workhorse nodes) ↗

CSI node + camera · the pose teacher

XIAO ESP32S3 Sense

ESP32-S3 + detachable OV2640 camera + mic

The intriguing one: a thumb-sized S3 CSI node with a camera on board. Why that matters: RuView's highest-accuracy pose comes from camera-supervised training — a camera acts as a temporary teacher for ~40 minutes, then goes away forever and the model runs on WiFi alone. This board is both halves of that story in one $27 part: teacher during training, ordinary S3 CSI node after.

NEED: 1 (only during pose training)
SENSES: WiFi CSI (as S3 node) + 1600×1200 camera + PDM mic
SETUP: Flash as a normal S3 node; camera workflow on the pose ladder
CONNECTS: WiFi → UDP 5005; camera frames to your training host

Honest note → RuView's documented teacher workflow uses a host webcam (MediaPipe). Using the Sense's own camera as the teacher means streaming its video to the host first — a fun experiment, not a documented path. Worst case: it's still a perfectly good S3 array node.

Buy XIAO ESP32S3 Sense ↗

60 GHz mmWave · TRUE 3D position · THE PICK

LD6004 — the movement-tracking pick

HLK-LD6004 · 60 GHz FMCW · X / Y / Z tracking

Reports a person's position in true 3D — including the vertical Z axis. Squat depth, sway, fall trajectories, micro-tremor — measured directly, no training, no camera, works in total darkness, sees through clothing. 60 GHz gives finer resolution than older 24 GHz radar. Field-proven here: 7+ weeks continuous uptime wired to a Pi's GPIO.

NEED: 1 (tracks one primary target)
SENSES: Position X/Y/Z (meters), presence heartbeat
SETUP: 4 jumper wires to the Pi's GPIO — pinout on the Setup page
CONNECTS: GPIO UART /dev/serial0 @ 115200

Gotcha → It ships with bare 0.1" pins — you need 4 female-female Dupont jumpers (you probably have them). One target at a time, ~5 m range. Wire it to GPIO, not a USB hub — that's the brown-out story on the Setup page.

Buy LD6004 on Amazon ↗

60 GHz mmWave · vital signs

MR60BHA2

Seeed XIAO MR60BHA2 · ADT6101P radar + ESP32-C6

Measures heart rate and breathing rate contactlessly — it senses the millimetre-scale motion of your chest and skin via 60 GHz Doppler. No chest strap, no watch. Sits facing you within ~1.5 m.

NEED: 1 per person / spot
SENSES: Heart rate, breathing rate, presence
SETUP: Ships ready; set WiFi via ESPHome
CONNECTS: WiFi → Seed over TCP 6053

Gotcha → The XIAO has two USB-C ports. The case-edge one is power only — to configure it, open the case and use the inner port. It reads null for ~60 s after power-on while it "warms up." That's normal.

Buy on Amazon ↗

LD2450 24 GHz mmWave radar USB kit — radar board with cable and USB adapter

24 GHz · 2D position · LEGACY

LD2450 — legacy, only for two edge cases

HLK-LD2450 · 24 GHz FMCW radar · USB kit · superseded by the LD6004 above

Use the LD6004 above instead — unless you specifically need one of the LD2450's two remaining niches: (1) you can't touch the Seed's GPIO pins and need a pure plug-in-over-USB radar, or (2) you must track 3 people at once in 2D (the LD6004 tracks one). Otherwise it's older 2D-only 24 GHz radar with no Z axis.

NEED: 1 (only if a niche above applies)
SENSES: Position (X/Y), distance, speed — 2D only
SETUP: No flashing — plug the USB kit into the Seed
CONNECTS: USB-serial @ 256000 baud

Gotcha → If you do buy it, get the USB kit (radar + cable + USB adapter), not a bare module, or you'll be soldering — and note the unusual 256000 baud. But for almost everyone, the LD6004 above is the right choice.

Buy the legacy USB kit ↗

IMU · motion & vibration

M5StickS3

M5Stack M5StickS3 · ESP32-S3 + 6-axis IMU

The one sensor here you attach to an object — it measures that object's motion, tilt and vibration with a built-in accelerometer. Battery-powered, streams over WiFi. Not contactless like the other three, but the way to capture how something physically moves.

NEED: 1 · (2 to compare two points)
SENSES: Acceleration, tilt, vibration (6-axis)
SETUP: Flash on a Mac/PC (ESP32-S3) or M5 UIFlow
CONNECTS: WiFi (UDP) · USB-C · built-in battery

Note → This is the in-stock successor to the now-discontinued M5StickC PLUS2. It's the only sensor here you mount on the thing you're measuring — the radar, vitals and CSI sensors are all contactless.

Buy on Amazon ↗

06 — DECISION GUIDE

Radar vs. CSI vs. vitals — which do I use?

They overlap, but each is best at one job. Here's the cheat sheet.

Technology	Frequency	Best at	Spatial detail	Through walls?
LD2450 radar	24 GHz	Precise 2D position & speed · 3 people	±5 cm XY	Limited
LD6004 radar	60 GHz	True 3D movement (X/Y/Z) · 1 person	fine, incl. vertical	Limited
MR60BHA2	60 GHz	Heart rate & breathing	n/a (vitals)	Limited
ESP32 WiFi CSI	2.4 GHz (WiFi 6)	Presence & skeleton-after-training, anywhere	Coarse (~30 cm)	yes
M5StickS3 (IMU)	—	Motion/vibration of an attached object	n/a (on-object)	on-object

🦴 Tracking people & skeletons — the myth, the reality, and exactly how long training takes

The myth: you watched Ruv's demos, so you plug in some ESP32s and instantly see a skeleton through every wall. The reality: out of the box you get presence, person count, breathing, heart rate and motion — genuinely impressive, and real. The skeleton you saw is the end of a training journey. Nobody tells beginners this, so here is the entire timeline, honestly:

Stage	How long — really	What you get after
1 · Empty-room calibration	60 seconds. Not 3 minutes, not 3 hours, and definitely not 3 days — one minute with the room empty (pets out too)	Presence stops flickering; everything downstream gets accurate
2 · Room enrollment	~4 minutes — the system coaches you through 8 poses (stand, sit, lie, walk…)	Six specialists tuned to your room: presence, posture, breathing, heartbeat, restlessness, anomaly
3 · Specialist training	Seconds (it's six tiny models, not a giant network)	Reliable vitals + posture classification in that room
4 · Real skeletal pose	~40 min recording + ~1 hour training. A webcam acts as a one-time teacher while you move through varied activities; then it's WiFi-only forever	A trained 17-keypoint skeleton from WiFi alone
(Re-calibration)	60 s again — only after moving furniture or nodes	—

"How many LD6004s do I need?" The straight answer: ONE. A single LD6004 mounted high in a corner, facing the activity area, gives true X/Y/Z for one person across its ~5 m cone — complete trajectory-in-a-room tracking, no training. Do not buy a second one for the same Pi. Here's why: a second radar only adds information if it sees the person from a different angle — but wired to the same GPIO header it sits inches from the first, two nearly identical views of the same scene (and the Pi's standard header exposes one hardware UART pair; wiring more means device-tree overlays — an expert detour, not a beginner path). The real failure mode is occlusion — your own body or a couch blocking the beam — and the only cure is a second radar mounted across the room, which means a second host carrying it (a Pi Zero, or a spare ESP32 forwarding the serial stream over WiFi). Good phase-2 project; not a starter requirement. Tracking several people at once is simply not this radar's job (one primary target per unit) — that's the LD2450's niche (3 targets, 2D) or one LD6004 per room.

"Why only a 17-point skeleton? MediaPipe does 33!" Fair question — and it's not laziness. Three reasons. (1) Physics: a 2.4 GHz WiFi wave is ~12.5 cm long — the radio literally cannot resolve fingers, facial landmarks or foot detail; those are most of MediaPipe's extra 16 points. The C6's 242-tone CSI sharpens the picture but doesn't change the wavelength. (2) Benchmarks: 17 points is the COCO standard every WiFi-pose dataset (MM-Fi) and every published result is scored on — a 33-point model couldn't be honestly compared to anything. (3) Training signal: the camera teacher could emit 33 labels, but you'd be training the radio to predict detail it can't sense — the model would memorize noise. The honest path to finer grain isn't more keypoints from WiFi; it's sensor fusion — the LD6004's true Z-axis, 60 GHz mmWave, the camera-CSI point-cloud pipeline. That's exactly the direction RuView is built around.

Reach for the LD6004 RADAR when…

you need to know where a body is, precisely — in 3D
you want speed / direction / vertical movement (falls, squats, sway)
lighting is bad or privacy rules out cameras
you need heart rate (that's the MR60's job)
you must track 3 people in one zone (the legacy LD2450's one remaining niche)

Reach for WiFi CSI when…

you want coverage through walls / whole-room
you can place several nodes for triangulation
rough presence & shape is enough
you need centimetre-accurate position (too coarse)

Reach for the MR60 VITALS when…

you want heart rate & breathing with nothing worn
the subject is roughly still, facing the sensor
they're moving around the room (use radar instead)

Reach for the M5StickS3 (IMU) when…

you can attach a sensor to the moving thing
you want fast, raw motion / vibration / tilt
it must be contactless (an IMU has to be on the object)

The real power is combining them

radar says where, CSI says roughly what shape
the vitals radar says how hard the heart works
the Seed fuses them — sharper, harder to fool
start with one, add more as you grow

07 — BUILD THE ARRAY

How to place your ESP32 sensor array

This is the step that makes or breaks WiFi sensing — and it's where most people fail. Buying the nodes is half of it; how you arrange them in the room is the other half. You can't pile them on a desk in front of you and expect a 3-D picture.

Plan on 7 ESP32 nodes

Three is the bare minimum to locate anything (you need sightlines from three directions to triangulate). Seven is the sweet spot — it wraps a proper sensing "cloud" all the way around a person (front, back and sides) with enough overlap that furniture and bodies don't create blind spots, plus a spare node or two so one dropout doesn't ruin your coverage. They're cheap, and that headroom is what keeps setup from being frustrating. (Ruv's rule of thumb is 7 — a prime number, and the count where it just works.) The June 2026 split: 4× ESP32-C6 (WiFi-6 high-fidelity, 242-tone CSI) + 3× ESP32-S3 (cheap workhorses) — all on your 2.4 GHz network.

"But how many do I actually need?" — and why mix S3s in at all?

Nodes	What you can honestly do	Who it's for
1	Presence, motion, breathing at one spot. No location — one viewpoint can't triangulate.	"Is someone in this room?" — a fine first weekend
3 (one 3-pack)	The minimum to locate anything: three sightlines = triangulation in one room. Zero spare — one dropout and you're blind.	Single-room experiments on a budget
5	Solid single living-space coverage with one node's worth of slack.	A serious one-room install
6 (two 3-packs)	Genuinely fine! The "prime number" part of Ruv's rule is folklore — what matters is ≥3 sightlines, wrap-around angles, and spares. Six works.	The pragmatic two-3-pack build
7 ★	Wraps a sensing cloud around a person from all sides plus dropout headroom — the count where multistatic fusion stops feeling fragile.	Ruv's recommendation; whole-floor ambitions

Why not just seven C6s? You can — it's a valid build, maximum fidelity everywhere. The 4+3 mix buys three practical things: (1) OTA updates. The C6 has no over-the-air update — every firmware release means walking around with a USB cable, seven times. S3s update over the air. (2) Failure-domain diversity. If a router quirk ever breaks WiFi-6 HE capture (it's the newest code path), the S3s' battle-tested HT path keeps your array alive — the same heterogeneity logic that saved our radar rig when USB adapters froze but GPIO kept running. (3) Extras. Only the S3 line offers the display option and the mmWave-fusion host role. If none of those move you, buy seven C6s with our blessing — just budget the USB-reflash ritual.

Top-down: ring the nodes around the subject and aim each antenna inward. Raise them to roughly torso height and keep clear line-of-sight — the goal is sightlines from every direction, not one wall.

✓ Do

Ring them around the space — front, back, both sides
Point each PCB antenna toward where people will be
Raise them off the floor to ~torso height
Keep line-of-sight; spread across both WiFi bands

✕ Don't

Pile them all on one desk facing the same way
Hide them behind metal, TVs, or in drawers
Bunch them in one corner (no triangulation)
Lay antennas flat on the floor

The deployment workflow

Flash them all first. Each node gets firmware on your Mac/PC before it goes on the wall (see the Setup & flashing page).
Number each one (node ID 1–7). Set a unique ID when you flash it, and physically label the case — so when the dashboard says "#5 is dead," you know which one to walk over to.
Place them in the ring per the diagram — antennas inward, off the floor.
Power each one (small battery or USB — see Batteries below).
Verify on a status dashboard that all seven are live before you trust the data.

"I plugged it in — how do I know it's working?"

This is the question every beginner hits, and the answer is simple: build yourself a status screen. Point a small dashboard at the Seed's live data stream so you can watch every sensor — radar, vitals, and all your ESP32 nodes — arrive, flow into the Cognitum One Seed, and get consolidated in RuVector into one picture. If a tile is green, that sensor's data is making it all the way through. If it's red, you know exactly which one to go fix.

The pipeline your dashboard lets you see: every sensor's data flows into the Seed, gets fused and remembered in RuVector, and becomes one consolidated picture.

Example health view — different sensors (radar, vitals, CSI nodes) all reporting in, plus a Fusion → RuVector tile showing they're being consolidated into one picture. Green = data is flowing all the way through; the amber #5 tells you exactly what to go fix. (Illustrative — modeled on a real deployment dashboard.)

08 — UNTETHER IT

Batteries: powering ESP32s you scatter around a room

The detail everyone forgets. The instant you place WiFi-CSI nodes away from a wall outlet — in corners, on shelves, around a room for a mesh — each one needs its own small, light, rechargeable power source. Here's how to do it cheaply.

Small sensor nodes scattered around a room, connected by glowing wifi mesh arcs — A whole-room CSI mesh: a handful of little nodes, each needing its own small battery.

easiest · recommended

LiPo pouch + a board that charges it

Pick an ESP32 board with a built-in battery connector and charger, then plug in a flat LiPo pouch. Recharge in place over USB — no extra electronics. Lightest option, perfect for scattering.

BATTERY: 3.7 V LiPo pouch, 1000–2000 mAh
CONNECTOR: JST-PH 2.0 mm (the common one)
BOARDS: FireBeetle ESP32, LOLIN D32

Why this one → No soldering, recharges itself, and a 2000 mAh pouch runs a WiFi-streaming ESP32 for roughly 10–16 hours.

longest runtime

18650 cell + holder board

An ESP32 board with an onboard 18650 holder (the AA-sized lithium cell from laptops). Cheap cells, big capacity, drop-in. Heavier than a pouch, but runs longest.

BATTERY: 1× 18650 Li-ion, 2000–3500 mAh
RUNTIME: ~16–28 h streaming
CHARGING: USB on the holder board

Heads up → Buy reputable cells. Bargain-bin 18650s often lie about capacity and can be unsafe.

zero-knowledge · watch the trap

A small USB power bank

The no-thinking option: a pocket power bank + a USB cable into the ESP32. Works instantly. But there's one infamous gotcha that makes them mysteriously die.

BATTERY: 5000 mAh USB power bank
CONNECTS: USB-C / micro-USB cable
RUNTIME: days (but see gotcha)

The trap → Many power banks auto-shut-off when current drops below ~50–100 mA for ~35–60 s. An ESP32 node sips 30–80 mA — squarely in the dead zone — so the bank powers down and your node "mysteriously" dies an hour in. Worse: the famous fix, Anker-style "trickle mode," auto-exits after 2 hours — fine for earbuds, useless for a 24/7 sensor. See the solutions below.

DIY · most flexible

Roll your own: LiPo + TP4056

If your board has no charger, add a TP4056 charging module (about $1) between a bare LiPo and the board. It safely charges over USB and protects the cell.

PARTS: LiPo pouch + TP4056 module
SKILL: light soldering (3–4 joints)
COST: ~$3–6 per node

Tip → Use the "TP4056 with protection" variant so the cell can't over-discharge and die permanently.

How long will it last? Quick runtime math

A CSI/streaming ESP32 keeps its WiFi radio on, so budget roughly 120–160 mA average. Runtime ≈ battery mAh ÷ average mA:

1000 mAh LiPo → ~6–8 hours
2000 mAh LiPo → ~12–16 hours (a full day)
3500 mAh 18650 → ~22–28 hours

For an always-on mesh, plan to recharge daily, or wire nodes to USB wall power where outlets allow.

⚠ Battery safety — three rules

(1) Never charge unattended on flammable surfaces. (2) Never puncture, crush, or fold a pouch — if it swells, retire it. (3) Always use a proper charger (TP4056 or onboard), never raw voltage. For a room full of nodes, lean toward boards with built-in protection.

Power parts — where to buy

These are ⌕ search links — battery listings churn constantly, so we point you at the right product category. Confirm voltage (3.7 V), connector (JST-PH 2.0), and capacity before buying.

FireBeetle ESP32 (battery-ready)

~$8

Built-in LiPo charger, low sleep current

search: FireBeetle ESP32

3.7 V LiPo pouch (1000–2000 mAh)

~$8

JST-PH 2.0 connector — match your board

search: 3.7V LiPo JST-PH

ESP32 18650 dev board

~$9

ESP32 with onboard 18650 holder + charging

search: ESP32 18650 board

TP4056 charging module (protected)

~$1

DIY LiPo charging + protection

search: TP4056 protected

Voltaic V50 "Always On" bank

~$74

The only battery here verified to never sleep · use its USB-A port (the USB-C PD port still sleeps!) · pass-through charging = mini-UPS

voltaicsystems.com/V50 on Amazon

USB keep-alive dongle

~$8–15

Budget fix: pulses ~100 mA load to keep ANY bank awake (costs ~10 mA average) · inline on the cable · adjustable version if your bank is stubborn

Pi Hut KeepAlive USB-C search: USB keep-alive dongles

Plain USB wall adapter

~$5

The real answer for any node near an outlet: wall adapters have no load detection — they never sleep, ever. Batteries are for placement freedom only

search: 5V USB-C adapter

18650 Li-ion cells (quality)

~$10

Reputable brand, true capacity

search: 18650 cells

10 — SHOPPING LIST

Buy it: the kit that actually works

Beginner-friendly, plug-and-play versions only. ▸ direct links were correct when last checked; ⌕ search links point at a product category. Always open the page and confirm before buying.

⭐ JUST WANT TO START? — THE STARTER KIT

Buy exactly this — about $60 and you're sensing

You already have the Seed (the brain). This is the smallest set of sensors + cables that gets you a first real signal: one WiFi-CSI 3-pack for whole-room presence & motion, one radar for instant no-flash movement tracking, and the cables to connect them. Add more CSI nodes later for a full 7-node array.

Part	What it gives you	Price	Buy
1× Seeed XIAO ESP32-C6 3-pack	Your first 3 WiFi-CSI nodes — presence & motion across a room	~$24	B0DJ6N55FX ↗
1× LD6004 radar	Fastest no-flash win — true 3D movement, plugs in over USB-UART	~$19	B0GKNCY7G7 ↗
USB-C data cables	Data-capable (not power-only) — needed to flash the ESP32s	~$10	search ↗
Dupont jumper wires	4 jumpers to wire the radar to your host's GPIO	~$7	search ↗
Total to start sensing · Seed not included — you have it		~$60

Want vital signs (heart/breath) or camera-supervised pose training too? Add the MR60BHA2 (~$25) or the XIAO ESP32S3 Sense (~$27) from the full list below. Not sure what you want to sense? See “which sensor do I use?”

The full menu · pick by what you want to sense

LD2450 radar — USB kit (legacy)

~$16

Only if you need 3-person 2D tracking or can't touch GPIO — otherwise buy the LD6004 above

B0CQ2P4RVP

LD6004 radar — true 3D movement

~$19–38

60 GHz · X/Y/Z position · wires to Pi GPIO (4 Dupont jumpers) · the movement-tracking pick

B0GKNCY7G7 alt: B0GKNYXWCK

Seeed XIAO MR60BHA2

~$25

60 GHz heart/breath kit · ESP32-C6 · USB-C

B0F3CCM5P6

Seeed XIAO ESP32-C6 3-pack (CSI node — the pick)

~$24 / 3

WiFi 6 · 242-tone HE-LTF CSI · buy 7 nodes for a full array (mix with S3s)

B0DJ6N55FX or LONELY BINARY S3 3-pack

Seeed XIAO ESP32S3 Sense (camera S3 — pose teacher)

~$27

S3 CSI node + OV2640 camera + mic · the camera-supervised pose-training teacher

B0DRNW6KMG

M5StickS3 (motion / IMU)

~$41

ESP32-S3 + 6-axis IMU · attach to an object · in-stock M5StickC successor

B0GZK27GN4 or M5Stack official (~$32)

The brain (your host)

The Cognitum One Seed

the brain

On-device intelligence + the host your sensors connect to

cognitum.one ↗

Power supply for your Seed

essential

Use the supply specified for your Cognitum One model — underpowering causes dropouts

see cognitum.one ↗

Cables & tools (you'll need these to flash & connect)

USB-C data cables

essential

Must carry data, not just power — for flashing

search: USB-C data cable

CP210x USB-to-UART bridge

~$7

Spare adapter for bare UART radars

B00LODGRV8

Dupont jumper wires

~$7

For any GPIO wiring (F-F, M-F, M-M)

search: Dupont jumpers

Powered USB hub

~$20

When you add several USB sensors to the Seed

search: powered USB hub

Next: how to flash & set it all up →

10.5 — DROP-IN AI PRIMER DOCS

Skip the research: drag these into your own project

When you build with Claude Code (or any AI assistant), it burns time and tokens re-discovering Ruv's stack from scratch. These pre-digested reference documents are the output of an exhaustive AI deep-dive — drag one into your repo or paste it into a chat and your assistant starts already knowing everything.

🟢

Knowledge bases & primers — last rebuilt June 14, 2026

ruvector KB → ruvnet/ruvector @ 4dedde8 · RuView KB → ruvnet/RuView @ 3d7530f0 (v1701)
29,439 + 7,174 full-text chunks · now in two versions each — a sharper 768-dim build for your Mac/PC and a lighter 384-dim build for the Seed · auto-rebuilds whenever ruvector or RuView publish — so a download today and a download in six months both carry the latest source.

📄 The RuVector Primer ruvector-primer.md

The complete map of ruvnet/ruvector ↗ — every crate (183 workspace members / 139 crate dirs), the capabilities and how to actually call them, every npm package, the RVF file format, ADRs, tutorials, integration commands, and an honest performance-claims table. Generated June 14, 2026 by Claude (Fable 5) sweeping a same-day checkout (main @ 4dedde8); the document explains exactly how it was made and how to regenerate it when it ages.

Download the primer ↓ view raw →

📄 The RuView / WiFi-DensePose Primer ruview-primer.md

The deep one — focused entirely on RuView ↗ (the renamed wifi-densepose), the software your sensors actually feed. Every crate (~38), the complete REST/WebSocket API, all seven 0xC511 UDP packet formats with byte layouts, the full CLI including the calibrate→enroll→train-room pipeline, all 163 ADRs, the 90 scripts, the firmware tree, and every capability graded works-today / experimental / stub — with code paths, so your AI assistant knows exactly where to look instead of guessing. Generated June 14, 2026 from the same-day build (v1701, 3d7530f0); includes its own staleness check and regeneration prompt.

Download the primer ↓ view raw →

🧠 The RuView & ruvector Knowledge Bases — make your AI an instant expert

In one sentence: a free, downloadable "brain" that already knows the entire RuView and ruvector codebases — so when you build with an AI assistant, it answers from the real source code instead of guessing.

Wait — what even is this? (the plain version, assuming you've never heard of an "RVF")

Here's the honest situation. You bought a Seed — maybe after seeing a WiFi-DensePose video — expecting it to just work. It doesn't work by magic out of the box; you have to build a little, and to build you'll lean on an AI like Claude. The catch: the software that runs your Seed (RuView, built on ruvector) is an enormous open-source project — thousands of files across folders, sub-folders, and Rust "crates."

When you ask an AI about something that big, it tends to skim and summarize — and skimming means it misses details and sometimes makes things up. That's the #1 reason people get stuck: their AI confidently gives them a wrong answer about RuView and they don't know it's wrong.

So we did the patient work for the AI. A tool reads every single file in those projects — walking every folder, sub-folder and crate, going deep instead of skimming — and turns the whole thing into one searchable file. That file is the "RVF" knowledge base (RuVector's own format; think of it as a PDF that stores meaning instead of pages). You download it, drag it into your project, point Claude at it, and ask your questions. Now Claude looks up the real answer in the complete project instead of guessing — so it genuinely helps you get your Seed doing what you wanted, faster.

And because Ruv improves RuView and ruvector almost every day, this rebuilds itself every night — so whatever you download is always the latest, never stale. (That's what "evergreen" means here: grab it once, and it keeps up with the project for you.)

Why would I want this? Ask Claude / Cursor / Copilot "how does RuView tell an empty room from an occupied one?" and it doesn't actually know Ruv's code — so it guesses, and often gets it wrong. Hand it this and it answers with the real files and real APIs in seconds. It turns a guessing assistant into a RuView expert.

Who's it for? Anyone who starts building on their Seed with AI help — even your first sensor dashboard. If you're only plugging in sensors right now, you don't need it yet; grab it when you start writing code. It's an optional accelerator, not a required step.

What's actually in it? Everything in both projects — every design doc, every README, and the actual source code — made searchable by meaning. Ask in plain English and it finds the right document even if you don't know the exact keyword. (ruvector: 29,439 searchable pieces; RuView: 7,174.)

How do I use it? Download → unzip → point your AI editor at it (3 steps below), then just ask. Or query it from the command line. Everything runs on your machine — no cloud, no account, your questions never leave your computer.

Two versions in every bundle — grab the one that fits where you'll use it:

🖥️ BIG (*-kb.big.rvf, 768-dim bge-base-en-v1.5) → use it on your Mac/PC — sharper, more accurate answers.
🌱 SMALL (*-kb.rvf, 384-dim MiniLM) → use it on the Cognitum One Seed — lighter, built to run on the device itself.
Both answer the same questions. The tools auto-pick BIG if it's present, else SMALL — you don't have to choose by hand. Not sure? You're probably on a laptop → BIG.

How to use them — three exact steps. You'll need Node 18+ and an AI editor that speaks "MCP" (Claude Code or Cursor). New to all this? The README inside the zip explains every term from scratch and also shows a no-AI command-line way.

Unzip into your project as kb/, then cd kb && npm i (installs @ruvector/rvf + @xenova/transformers).
Create .mcp.json in your project root with exactly this — it runs the bundled, working kb-mcp-server.mjs (one server, both KBs):
{"mcpServers": {"cognitum-kb": {"command": "node", "args": ["<ABS-PATH>/kb/kb-mcp-server.mjs"]}}}⚠ Do not use @ruvector/rvf-mcp-server — that published package is a stub that never reads a prebuilt .rvf and returns no text.
Paste this into your project's CLAUDE.md — it makes the KB a mandatory verification gate so your AI stops skimming the repos and guessing wrong:
MANDATORY — ruvector/RuView verification gate: these repos are far too large to skim, and summarizing them from memory produces wrong answers. BEFORE answering ANY question about ruvector or RuView — or writing/changing code that uses them — you MUST query the `cognitum-kb` MCP server (tool `search_kb`, store="ruvector" or "ruview") and ground your answer in the files it returns. Do NOT rely on training memory or a summary of these repos. Treat `cognitum-kb` as the source of truth and cite the file(s) it returns.

Confirm it works: restart Claude Code, type /mcp (you should see cognitum-kb · connected), then ask "using cognitum-kb, which crate implements dynamic min-cut?" — a working setup calls search_kb and answers with real paths like crates/ruQu/src/mincut.rs and the full passage text in seconds, instead of grep-sampling 1.7M lines. No MCP? Same answer from the CLI: node kb/ask-kb.mjs ruvector "dynamic min-cut" 5. From Node: import searchKb from ask-kb.mjs (embed → .rvf query → join full passage).

Each bundle is self-contained and runnable: the .rvf database, the .passages.jsonl full-text sidecar, the .json metadata sidecars, the manifest, the working kb-mcp-server.mjs + ask-kb.mjs scripts, package.json, and the README that walks you through it.

📦 One download — two halves, a little something for everyone

It unzips into a single kb/ folder with two halves: one for you to read & watch, one for your AI to search. Both ship together, both stay current.

For humans — a person watching the video explainer, audio overview, slides and infographics

👤 For you — the human

Understand RuView & ruvector in a few minutes — no code required.

kb/
├ ruvector-primer.md  — the AI engine, plain English
├ ruview-primer.md    — the WiFi sensing, plain English
└ studio/for-humans/
  ├ video-explainer.mp4 — ▶ ~8-min watch
  ├ audio-overview.mp3  — 🎧 podcast-style listen
  ├ slides-….pdf        — 🖼 15-slide deck
  └ infographic-*.png  — 📊 2 posters

For AI — an assistant wired into the searchable knowledge base and command-line tools

🤖 For your AI

Point Claude / Cursor at it — it answers from the real code, not guesses.

kb/
├ *-kb.big.rvf       — 768-dim brain (Mac/PC)
├ *-kb.small.rvf     — 384-dim brain (the Seed)
├ *.passages.jsonl   — every doc + all source
├ ask-kb.mjs         — query it from the CLI
├ kb-mcp-server.mjs  — wire into Claude/Cursor
└ studio/for-ai/
  ├ *.transcript.txt  — video + audio as text
  └ notebook-summary.md — machine-readable recap

1 · Drop it in
Unzip into your project as kb/.

2 · Keep your repo clean
Add kb/ to your .gitignore so it doesn't clog your project.

3 · You're all set
Point your AI at it (2-line .mcp.json, steps above) — done.

▶ See it and hear it — right here, no download

The same human-facing media that ships inside the ruview bundle, playable right on this page — an explainer video, a podcast-style audio overview, two infographics, and the slide deck. Grok how seeing-through-walls actually works without reading a line of code.

🎬 The explainer — ~8 min

🎧 Audio overview — podcast-style, ~22 min

Tip: hit play and keep scrolling — it streams as you read.

🖼 Slide deck

Open the slide deck (PDF) ↗

📊 The two infographics — click either to open full size

Infographic: how passive WiFi sensing turns radio reflections into a sense of the room

Infographic: seeing through walls with WiFi — what spatial intelligence can and can't do

ruvector KB bundle (both versions: big 768-dim + small 384-dim · full-text + tools + README · 155 MB) ↓ ruview KB bundle (both versions: big 768-dim + small 384-dim · full-text + tools + README · + studio media pack · 138 MB) ↓ START HERE: the KB README (what it is · what's in it · 3 ways to use it) →

🔗 The whole stack, one link each

What	Link	Why you'd go there
Cognitum One Seed	cognitum.one/seed ↗	The brain itself — specs, founding-member pricing
Cognitum V0 appliance	cognitum.one/appliance ↗	The Pi 5 + Hailo-8 LAN core (RuVector + RuView + RuFlo in one box)
RuView (= WiFi DensePose — same repo, renamed)	github.com/ruvnet/RuView ↗	The sensing software; ruvnet/wifi-densepose redirects here
RuVector	github.com/ruvnet/ruvector ↗	The Rust vector/AI engine underneath everything (see the primer above)
Cognitum One Learn	learner-rv-site.vercel.app ↗	Got a Seed? Use it to build your own personal expertise — turn any topic into a queryable knowledge base you own
RuView live demo	ruvnet.github.io/RuView ↗	Try the visualizations in your browser, no hardware
Firmware releases	RuView/releases ↗	Prebuilt ESP32 binaries (use v0.7.1-esp32+; v0.8.0 for C6)
Pretrained models	HF: wifi-densepose-pretrained ↗ · mmfi-pose ↗	CSI encoder + presence head; SOTA MM-Fi pose model

Tutorials buried deep in the repos (worth the dig)

RuView User Guide ↗ — the 2,400-line master document our walkthrough distills
Cognitum Seed pretraining tutorial ↗ — camera-free pose training with the Seed's 10 fused signals
Pi 5 cluster: cognitive RF observer ↗ — multi-Pi RuView deployment (the V0 path)
Home Assistant integration ↗ — MQTT auto-discovery + automation blueprints for alerts
ADR-069: the Seed CSI pipeline ↗ — the design doc behind our "Seed memory" phase
RuVector: Getting Started ↗ · Basic Tutorial ↗ · AgenticDB Quickstart ↗