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