A few weeks back, we reported on a research group that figured out how to measure heartrate using perturbations in WiFi signals. [Nick Bild] was interested in this so-called “Pulse-Fi” technique, but noted the paper explaining it was behind a paywall. Thus, he worked to recreate the technology himself so he could publish the results openly for anyone eager to learn.
[Nick] paid for the research paper, and noted that it was short on a few of the finer details and didn’t come with any code or data from the original research team. He thus was left to figure out the finer details of how to measure heart rate via WiFi in his own way, though he believes his method is quite close to the original work.
The basic concept is simple enough. One ESP32 is set up to transmit a stream of Channel State Information packets to another ESP32, with a person standing in between. As the person’s heart beats, it changes the way the radio waves propagate from the transmitting unit to the receiver. These changes can be read from the packets, and processed to estimate the person’s heart rate. [Nick] explains the various data-massaging steps involved to go from this raw radio data to a usable heart rate readout.
It’s a great effort from [Nick] to recreate this research all on his own in his home lab. Files are on GitHub for the curious. If you’re eager to learn more about these innovative measurement techniques, you might like to read our prior reporting on the tech. Also, it’s worth remembering—don’t use your homebrew prototypes for any serious healthcare purposes.
I don’t quite understand what the NN is used for here. The data looks pretty clean already. Basically ready for FFT.
Its often easier to made a basic NN model these days with the processing power that we have. Plus if you’re working with sensors directly and have access to a LOT of training data, its often faster than making sense of the actual data and doing actual DSP.
Wasteful? Probably. Works fine? Also yes.
Step closer to a DSP solution if needed.
A heartbeat is not a pure sine wave and there can be a lot of large transients. Linear filters or FFTs are not always the optimal solution. Perhaps a Kalman filter can work. A ANN might be overkill, but can outperform classical algorithms.
Something worth remembering, if a paper is behind a paywall chances are it’s because the publisher put it there, not the author. If you contact the author directly they often will send you a copy of the full paper with no issues.
Wow very cool
I’d love to see the next generation of fitness bands and smart watches which use radar instead of the blasted green LED and photodiode. I could never get that to work reliably. Plus without a transparent window, the smartbands can be made even better sealed and cheaper!
If anyone is interested in the paper, it is available for free at UC Santa Cruz:
https://news.ucsc.edu/wp-content/uploads/2025/08/Pulse_Fi_short_paper_iotdcoss.pdf
The Tricorder is on its way!
I am detecting life signs 30 meters ahead.
You need a transmitter on one end and a receiver on the other end. Can’t work in one unit.
Yet…
“don’t use your homebrew prototypes for any serious healthcare purposes”
René Laennec begs to differ:
https://en.m.wikipedia.org/wiki/Stethoscope#History
The point being that all healthcare devices started as homebrew prototypes. In the case of a stethoscope being a rolled up sheet of paper.
However, if my “homebrew prototype” indicated a problem somewhere I’d probably go to a doctor who has access to an ASIC encased in injection-moulded plastic.
It is just saying, if you use this device to heal someone but unluckily fail, HaD does not take the responsibility.