Heartbeat Logger

A portable device that logs a snippet of your heart at the push of a button.

Similar projects worth following
Something odd about your fleshy engine? Your heart tumbling like a pair of sneakers in a washing machine?

I thought so myself back in 2014, while still being a student, and decided to make it an exercise in embedded hardware and software design. Since these odd sensations came without warning once a week or so, I needed a device that could measure the electro cardiogram and store it on a memory card to examine later.

The first prototype was successfull and there have been several revisions since. The last revision, 4.0, aimed to more than halve the package size while improving battery performance. There were major wins, but readings from the front end chip are bad and time's up. The project is shelved and the files can be downloaded for whatever purpose.

What makes you tick?

Within each individual muscle cell in our heart there is a difference of charge between the inside and the membrane. Ions start gushing out from the control node in the heart and into the resting cell, making this difference of charge decrease until the cell contracts. A moment later the ions flow back and the cell returns to it's resting state. This will spread like a wave through your heart, and is called a heartbeat!

While this wave of contracting cells is spreading throughout your heart, we can measure the difference of charge between the resting cells and the contracted cells as an electric potential, or voltage if you will. Amplifying this tiny signal and plotting this voltage on paper as it happens is basically the ECG -- the Electrocardiogram.

Simple python script to read the HBL4.00 data files

plain - 914.00 bytes - 02/15/2020 at 21:31


HBL 4.0

Project file for the embedded code. WARNING: Code seem to work, but is not verified properly. Project was shelved. See

x-zip-compressed - 1.95 MB - 02/15/2020 at 21:30


KiCAD design files for version 4.00. WARNING: Contains hardware bugs! See

Zip Archive - 2.12 MB - 06/29/2019 at 16:24



Matlab function to read and plot the logged binary file.

m - 2.83 kB - 02/01/2016 at 15:15



A sample file from the first logger prototype. Noise free, no time stamps.

octet-stream - 12.00 kB - 02/01/2016 at 15:15


View all 6 files

  • Some last pics

    Ole Andreas Utstumo02/15/2020 at 20:41 0 comments

    Front. There's a groove to feel the push button on the silicone casing.


    Backside. There's a slot at the top where the PCB can be squeezed in.


    Undressed backside.

  • Shelvin'

    Ole Andreas Utstumo02/15/2020 at 19:45 0 comments

    I made sure the PLL cap was a NP0 type and added 10µF decoupling to the analog supply of the MAX30003 with no improvement. This project has been dragging on for too long, so it's time to cut the losses and move on. A little summary won't hurt, though:

    What works:

    • Sampling real time data to the microcontroller's RAM and, upon button
      push, store the entire RAM buffer to a file on the external flash file system
    • Using the STM32 with external flash as an USB mass storage device to access saved files (or any files!)
    • Runtime: approx a week on a single CR2032 cell
    • Silicone casing is smooth!

    What doesn't work:

    • The readings from the MAX30003 swing from rail to rail and makes no sense
    • The smoke escapes from the 3.3V LDO when there's no USB power... Seems like reverse conditions don't make these things happy!
    • The MCU is unsuccessful in recovering fully from deepest STOP mode

    Lessons learnt:

    • Tiny components in packed spaces are a bitch to patch and rework
    • Don't do hard to hand solder SMD components on the backside of PCBs in hobby projects with hobby tools
    • Include reset pin on debug connector if you plan on using sleep modes...
    • Segger has some truly excellent debugging software

    ... and lastly:

    • Ease down on scope on simple hobby projects, don't introduce too much new or tricky stuff or it's gonna be hard to keep up momentum, and as a result, motivation will suffer.

  • Nonsensical data and an unlockable PLL

    Ole Andreas Utstumo02/10/2020 at 00:10 0 comments

    There is this slightly tiny issue where all the logged data makes no sense. A bit unfortunate for a data logger, yes, and one that's a bit harder to debug when dealing with a integrated circuit and not discrete components as previuously.

    After clearing away the metadata the logged data looks like this, electrodes attached or not:

    Just something that looks like a saturated signal going from rail to rail in a random fashion. I've verified the SPI transmissions with a logic analyzer so there's nothing wrong with the way data is handled, it's all fine there.

    The 1.8V supply is stable with only 3.3mV of digital ripple:

    Looking at the PCB design I cannot see any impedance or noise issues with the ground plane either. In addition, the MCU is basically sleeping when the front end is sampling data from the amplifiers..

    All registers are at default value, ECG channel is ON, sync register is cleared, the only thing reported in the logged metadata is FIFO END (but no overwritten values). Thinking it was some impedance or cross talk issue at the inputs I disconnected the inputs internally using the OPENP and OPENN bits in the CNFG_EMUX register, but with the same results..

    Reading from the MAX30003's status register might give us a slight clue, though: The PLL lock bit never clears from it's position, meaning the device never reaches a stable clock.

    The internal clock of the MAX30003 is generated from the incoming 32.768kHz clock from the STM32's crystal driven LSE clock:

    We can check the incoming clock for jitter:

    A closer look at one period's worth of jitter:
    So we have a period of ~30.5us +/- 0.2% which doesn't seem like too much, but I'm afraid my knowledge falls short here..

    A cause for the PLL issue might be the PLL capacitor which may or may not be a C0G / NP0.. If that's not it, I'm out of ideas, and to be honest, I'll also be out of motivation to dig further into the issue. It's been a cool little project, but to be honest there's nothing too interesting about it to warrant more hours sunk into it.. I'll order some new caps and give it one last shot before I shelve the project and move on.

  • Moldin' 2

    Ole Andreas Utstumo01/26/2020 at 22:55 0 comments

    Didn't mix enough silicone and ended up with only half an enclosure.. Feels pretty damn fascinating, though.

    Letting gravity to its work on the silicone through that narrow opening in the mould proved to be impossible, so I resorted to the cordless drill to modify the resin printed mould a little...

    Whops. Brittle stuff, this is. Fret not, though, because my colleague Borut modified the cad files and my other colleague Börje printed a new mould with his cheap resin printer. The prints are slightly deformed but the level of detail and sharpness is on a whole other level from filament prints.

    Vaseline is again used to keep the mould from leaking.

    The negative filler..

    I used a pipette to push the silicone mix into the mould. Not ideal since air bubbles are easily introduced into the mix, but it'll work.

    Silicone doesn't take long to become unworkable.. I tried attaching a vibration motor to shake the bubbles out, but it didn't do much. A vacuum chamber would have given some solid results.

    Some rough edges, but it will be functional.

    Snug fit! As a bonus, the silicone works very well with the indicator LED.

    There will be a crack in the casing where the PCB slides in, though.

  • Moldin'

    Ole Andreas Utstumo12/04/2019 at 23:41 0 comments

    Ok, no measurements have been done to verify the functionality, but that doesn't mean we cannot be allowed to get ahead of ourselves... Discussing the casing with my great colleague Borut we had some ideas on plastic casings and then soft casings made out of silicone. It turns out, of course it does, that there is a kind of silicone resin to be bought that is "medical grade". According to Wikipedia:

    Medical grade silicones are silicones tested for biocompatibility and are appropriate to be used for medical applications. (...) Medical grade silicones are generally grouped into three categories: non implantable, short term implantable, and long-term implantable.

    The list of examples given are

    • Tubing
    • Drains
    • Feeding tubes
    • Catheters
    • Implants for long and short term use
    • Seals and gaskets
    • Syringe pistons
    • Scar Treatment Silicone Sheets (FDA Class 1 Medical Device) and gels.
    • Condoms
    • Menstrual cups
    • Sex toys
    • Non-Stick Containers
    • Respiratory masks

    Some fun examples here :-)

    So Borut came back the next day with some pretty well thought out ideas on how the casing should work, how the edges should bevel with a shallow angle so the casing can integrate better with the skin of the user, how the PCB can be slid into the elastic casing with the USB port still accessible, how the mold would look in detail with a insert as negative space for the PCB and how the leads for the logger would also need to be printed on the insert. Few days later and he's made CAD models for the mold!

    Botton half of the mold
    Top half of the mold
    Botton half of the mold
    USS Enterpr... I mean the insert

    Brilliant! There's even a small indentation for the tactile button to be felt on the outside of the soft casing :-)

    And what do you know, some other great colleague by the name Börje recently purchased a cheap SLA printer and a ultrasonic cleaner, and presented us with an amazingly sharp print of the mold over the weekend.

    I opted for some "food and skin grade" silicone resin (shure A 15, ebay link) and got down to business with syringes free from the pharmacy.

    To be continued..

  • Consumin'

    Ole Andreas Utstumo10/25/2019 at 13:47 0 comments

    Did a crude test on current consumption during runtime. During runtime, the MAX ECG circuit is the only thing running constantly, waking the MCU up from Stop mode every 32 samples so it can receive these via SPI and store them in the RAM buffer.

    180 ish uA on average. On a 240 mAh coin cell battery that should provide well over a week of runtime. All components are selected to operate below the "knee" of the battery discharge profile.

  • Loggin'

    Ole Andreas Utstumo09/07/2019 at 20:14 0 comments

    Fatfs is working with the new flash chip, the USB MSC services are running, the ECG front end is now also running smoothly via SPI and we're logging data to files.

    Binary data straight from the front end obviously won't look good in a text editor...

    And if you're working with STM32 and haven't tried out SEGGER's excellent software packages, I strongly urge you to. They provide by far the most handy tools I've used yet for embedded debugging. The real time variable graphing tool is damn cool:

  • Blinkin'.

    Ole Andreas Utstumo09/01/2019 at 17:51 0 comments

    All good so far.

  • Mounted.

    Ole Andreas Utstumo09/01/2019 at 17:48 0 comments

    Three cards were mounted a while back. Hand mounting SMD components on a PCB backside is as usual a pain in the arse... I will hopefully never fall for that one again.

  • Design files uploaded

    Ole Andreas Utstumo06/29/2019 at 17:35 2 comments

    ... And can now be found on the main project page. I hope I didn't leave anything important out of the project folder :-)

View all 57 project logs

Enjoy this project?



helge wrote 05/23/2016 at 21:08 point

It's so encouraging and satisfying to witness you seeing this project through. Thanks man.

  Are you sure? yes | no

Ole Andreas Utstumo wrote 05/24/2016 at 07:11 point

Thanks for your feedback, helge, that means a lot! I'll update with a video of the logger as soon as I get more electrode pads in the mail.

  Are you sure? yes | no

Jana Marie wrote 01/03/2016 at 19:54 point

Hi, if you're planning to also do some ECG recordings after wilson, you can also monitor the patients respiration by measuring the resistance between the electrodes.

It will increase as the patient will breath in.

  Are you sure? yes | no

Ole Andreas Utstumo wrote 01/03/2016 at 20:14 point

Thanks for the tip, Jan Henrik, I'll look into it, though I'm generally cautious of driving any current into the body for measurement as long as I'm not 110% sure of what I'm doing ;)

  Are you sure? yes | no

Jana Marie wrote 01/03/2016 at 21:02 point

Dont worry, you dont need to drive current into the body, you can measure the resistance in other ways :)

  Are you sure? yes | no

Ole Andreas Utstumo wrote 01/05/2016 at 17:18 point

You could apply a voltage, but I'd be even more careful with that. Otherwise I can't think of any other way... You wanna share your secret? :)

I did google this a bit and found an app note from Texas Instruments detailing this kind of measurement: Seems like the prevalent way is by injecting a high frequency current below 100µA into the chest and then measure the impedance.  

Another way of measuring respiration derives the respiration from the ECG readings themselves, and is shared here: This method doesn't require any additional hardware :)

  Are you sure? yes | no

dim liakos wrote 11/30/2015 at 22:06 point

Hi Ole Andreas,

Good Job!

I'm working on a similar project to receive an ecg with xmega a3bu  xplained board.

Will you post the c code? need to see the adc reading for ecg and bat status


  Are you sure? yes | no

Ole Andreas Utstumo wrote 11/30/2015 at 23:23 point

Thanks, dim!

I'm afraid that code is stored somewhere on my old laptop back home. I won't be able to post it untill the 23th of December.

The software employed DMA (Direct Memory Access) to read the ADC values and store them in RAM. I had some trouble with it, but this blog post sorted it all out:

For reading the ADC in an ordinary manner I would suggest creating an example project based on your Xplained board in Atmel Studio and build upon that. There are examples of reading the ADC and of sending the values over CDC to your computer.

Good luck, and check back in Christmas!

  Are you sure? yes | no

Peter Wasilewski wrote 09/14/2015 at 19:45 point

I have a question about the PCB. How did You manage to do so well-looking vias ? Are they a special kind of rivets ? 

Have You tried the lichtenberg's alloy ? It covers the board with a beautiful silver coating, very easy to solder at any time. I think it would preserve the copper  from oxidation.

  Are you sure? yes | no

Ole Andreas Utstumo wrote 09/14/2015 at 23:08 point

Well, thank you! It's just copper rivets carefully inserted with what I suspect is an ordinary riveting tool :) 

Oxidation is starting to become very visible by now, but the prototype already
contains several hardware bugs that should be corrected, so this thing
doesn't need to last long. I'll consider fixing them and order up some
crisp PCBs on the internet with solder mask and all. Making PCBs by etching copper boards, drilling and riveting is great for understanding the raw simplicity of electronics, it is however a lot of work... Thanks for the tip, though!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates