Hardware · Experiment
A two-chip radar board built around a 60.5 GHz sensor, designed to measure movement in microns. It is built to do two things: read a heartbeat through still air, and recover a sound from a surface it never touches. This is a look at what it does, the firmware that makes it happen, and the board underneath. My first piece of hardware.
A 60.5 GHz radar has a wavelength of about 5 mm, which sounds far too coarse to be interesting. But the sensor does not just report how far away something is. It reports the phase of the wave that returned, and phase is exquisite: one degree of it is 6.9 micrometres of movement, roughly a tenth of the width of a hair. The wavelength is millimetres, the measurement is microns, and everything the board does lives in that gap.
phase
126°
movement
867.2 µm
one sample reads
126°
turns unwrapped
0
ràdá is radar carried into Yoruba the way the language carries any borrowed word: heard, respelled, and given its tones, the same move that turns radio into rédíò and motor into mọ́tò.
Two applications, from the same sensor and the same micron-scale sensitivity. They differ only in how fast the radar has to look and what the movement means once you have it. A button on the board switches between them.
Mode one · vitals
A heartbeat through the air
A chest moves a few microns with every beat, and a slow, gentle radar rate is plenty to see it. Pointed at a person from across a small room, the board reads that motion and reports a pulse, no contact and no wearable. This one works regardless of how the hardware measurement below turns out.
Mode two · sound
Sound off a surface
When a surface vibrates with sound, a windowpane, a bag, a throat, it moves by exactly the micron scale the radar can see. Sample the movement fast enough and you have reconstructed the sound itself, without a microphone. This is the demanding mode, and the one gated on the link speed.
The part at the centre of the board is Acconeer's XM125: a 60.5 GHz radar die and a small Cortex-M4 in one pre-certified module. Choosing it is the single most consequential decision in the whole design. Laying out a millimetre-wave antenna and its feed on a hand-built two-layer board is a way to lose months to physics I have never practised; buying a module that has already solved that trades away raw flexibility for a real chance of the first board working at all.
The tradeoff it forces is bandwidth, and it lands squarely on the sound mode. The module speaks over a serial link, and the arithmetic says that link is three to four orders of magnitude narrower than talking to the bare radar die directly. That matters because the audio you can recover is only ever half the sweep rate, so the sound application is gated on a number nobody can calculate honestly in advance: how fast the link really sustains. The sensor answers for itself, because every frame it returns carries a flag that means I could not deliver that one on time, and the first program written for the project does nothing but push the rate up until that flag starts firing. Above a threshold the sound mode is viable; below it, the heartbeat mode still works, and sound would need the bare die and a much harder board.
There are two processors on the board, so there are two firmwares, designed as one system and sharing exactly one file: the protocol they speak. The radar module runs a thin program that does one job, stream raw sensor readings up the wire. Everything intelligent happens on the nRF52840, which brings the module out of reset, holds it awake, and turns what comes back into a result.
The first step on the nRF is the one both modes share and the one that is easy to get quietly wrong: turning phase into distance. The radar hands over a complex number per sample; the firmware takes its angle, unwraps it across successive readings so a movement larger than one wavelength does not fold back on itself, and scales it by the fixed physical constant that says how many microns a radian is worth. Out of that comes a clean stream of displacement, in microns, and from there the two modes diverge.
For a heartbeat, that displacement is filtered down to the narrow band a pulse lives in, a fraction of a hertz up to a few, and a peak detector with an adaptive threshold and a refractory floor counts beats and reports a rate. The board notifies it over Bluetooth and pulses its light once per beat. For sound, the displacement stream simply is the audio: it is high-passed to the audible range and streamed out over USB as ordinary 16-bit samples, which a laptop can play straight back, while a coarse dominant tone is summarised over Bluetooth. Threaded through both is that on-time flag: the firmware counts every late frame and surfaces it, because a sound stream with dropped time is a lie, and the device should say so rather than hide it.
None of that waits for hardware to be trusted. The maths is the delicate part, so it is checked on a laptop against synthetic radar data first: the exact code that will run on the chip recovers a 200 Hz tone as 200 Hz and a 72 beat pulse as 72 beats. The number it will report in the field is already the number it should.
That check is below, moved somewhere the knobs turn. It is the firmware's own chain, ported line for line, running on radar data synthesized in the browser: unwrap the phase, scale it to microns, then either hunt for beats or rebuild the sound. The only synthetic part is the sensor.
dsp.c · ported
band-passed 0.8 to 3.0 Hz · first 8 s of a 30 s capture · ticks are accepted beats
the smoothed estimate, beat by beat, across the whole capture
true pulse
72 bpm
reported
72.2 bpm
beats accepted
36
error
0.2 bpm
A 40 µm chest movement at the pulse rate, turned into complex samples the way the sensor reports them, then run through the ported chain: unwrap, strip drift below 0.3 Hz, band-pass 0.8 to 3.0 Hz, and accept peaks that clear a decaying fraction of recent energy with a 0.33 s refractory floor. The reported rate is an exponential average, so it needs around twenty seconds to settle, which is why the capture is 30 s and why the second trace matters more than the final number.
Two limits worth naming, both found by running it here. Push breathing much past 300 µm against a 40 µm pulse and the estimate breaks: the band-pass attenuates 0.25 Hz but does not remove it, and the peak detector starts finding breath crests instead of beats. And the bottom of the band is softer than its number suggests. The filter runs from 0.8 Hz, which is 48 bpm, but the detector starts double-counting within about ten bpm of that edge, so this slider begins at 58 and everything above it lands within a bpm or so of the truth.
The schematic is not drawn by hand. It is emitted by a Python script that places every symbol and attaches every connection as a named net rather than a routed wire, so correctness reduces to a question a script can answer exactly: is this label sitting on that pin? It passes the electrical rule check with zero errors. The interesting content is not the drawing, it is the netlist underneath it.
Most of the parts count is power. USB-C charges a single lithium cell through a dedicated charger, and two low-dropout regulators split that cell into a 3.3 V logic rail and a 1.8 V rail. That second rail is not optional: the radar module cannot make its own 1.8 V, and its draw jumps from 3 mA to 75 mA the instant it wakes, so the rail has to be there and has to be stiff. The rest is a USB-C data path, two status LEDs, a button, and four test points that bring out the programming and debug pins.
The whole board is really two processors and the wire between them. They talk over one serial link plus three control lines the nRF owns: a reset, a wake, and an interrupt the radar raises when it has data. Five nets, and the entire behaviour of the device flows through them.
Reading a schematic against its own build is where the small, expensive mistakes hide. Doing exactly that turned one up here: a comment claimed the radar's receive line sat on one nRF pin, while the netlist the tool actually built wired it to the pin next door. The generated artifact is the source of truth, so the firmware follows the netlist and the discrepancy is flagged for the next revision. It is a one-pin error that would have cost a silent bring-up failure and a day of staring at a dead link.
Placement is generated too, and validated before anything else runs: the script refuses to continue if two parts collide. The radar module takes the left of the board with its 28 pads and a keep-out for the antenna; the nRF and the power section fill the right.
One layout decision is really an antenna decision. Acconeer's guidance is explicit that radar loop gain rises with the size of the ground plane beneath the sensor, so a solid ground pour is a performance requirement rather than a convenience. It also happens to do a third of the wiring for free, because ground is by far the largest net on the board. The remaining signal routing is the honest next job: the board passes its design-rule check and its manufacturing files are ready, but the individual traces are not laid yet, because there is a more important thing to do first.
The chip is chosen, the schematic passes its checks, the board is placed and ground-poured with fabrication files ready, and the firmware for both modes exists with its signal processing already validated in software. What does not exist yet is a physical unit, and that is on purpose.
The next step is not to order parts. It is to take the one measurement the whole architecture hinges on, the real sustained rate of that serial link, and let the answer decide whether the signal traces get laid for the easy job or the hard one. It is my first hardware project, and I wanted the first one to be honest about the line between what I have proven and what I have only assumed. Everything above that line is done.