Close
0%
0%

Heartbeat Logger

A portable device that will log your ECG - the "waveform" of your heart - to your phone via bluetooth or to a memory card.

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 a couple of years ago 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 (ECG), or the activity of the heart, and store it on a memory card to show a doctor later.

I've brought the prototype back from the shadows of my drawer, and have been working on revising it to make a more complete device. The first revision, the purple board, is able to do the following.

- Measure the electric activity in your heart with 3 leads
- Sample the signal @ 512 Hz, 12-bit and store the data on a microSD card
- Stream the sampled data wirelessly to a mobile device
- Operate for nearly 24 hours on a charge (850mAh battery)
- Save a timestamp with the push of a button

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.

With the ECG you will be given a window into your heart so that serious abnormalities can be revealed. Patients can be examined with stationary equipment for a small period of time, and an analysis of the heart activity can indicate complications that should be thoroughly examined. However, abnormal heart activity in an otherwise perfectly normal heart might occur outside of the examination room.

The Heartbeat Logger is a portable device that that logs your ECG throughout the day and throughout the night, 24/7. While this certainly is nothing new, even as an open source project (see MobilECG), Heartbeat is a project that, aside being of personal value for me, is designed to be simple to use and understand, and might serve a purpose somewhere for someone.

Disclaimer: THIS IS BY NO MEANS A MEDICAL DEVICE. Use at your own risk.

Project index

Current status: Third revision arrived, awaiting time to continue.

Heartbeat Logger hardware and firmware files in GitHub

The heart and the ECG

Hardware

Firmware

ekganalysis.m

Matlab function to read and plot the logged binary file.

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

Download

ecgdata8.bin

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

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

Download

EKG2_v2.zip

Source code for the prototype with Xmega A3BU micro controller.

application/zip - 259.46 kB - 12/23/2015 at 22:43

Download

  • STM32 and SWD connection

    Ole Andreas Utstumo03/09/2019 at 19:18 0 comments

    I reckon this might be to use for some of you. The diagram shows how to connect the ST-Link V2 to your STM32 device.


    If you haven't got a Cortex M3, M4 or M7, then you won't have any SWO pin to connect.

    Here's how I hooked it up IRL:

    The SWO pin is a feature for streaming data from the microcontroller for debugging purposes. I'm a bit excited to try this out as UART ain't always the quickest and most convenient way of retrieving runtime data from the controller. There's a more indepth article about this at dzone.com.

  • Soldered up, plugged in

    Ole Andreas Utstumo03/07/2019 at 22:00 0 comments

    Nice! 0.12 mm stencil is a bit too thick for these small pitches, so I had to wick away some bridges at the USB connector and MCU.

    That crystal pad is large enough to be welded...

  • Choosing crystals

    Ole Andreas Utstumo03/06/2019 at 20:13 0 comments

    For selecting a crystal that is compatible with their microcontrollers, STM has a design guide that comes in handy:

    https://www.st.com/content/ccc/resource/technical/document/application_note/c6/eb/5e/11/e3/69/43/eb/CD00221665.pdf/files/CD00221665.pdf/jcr:content/translations/en.CD00221665.pdf


    Under section 4.2 we find a handy checklist we can follow:

    Step 1

    The oscillation loop maximal critical gain parameter (Gm_critmax) is indeed specified in the STM32L432KB datasheet:

    So let's go straight to section 4.2:

    Let's check out one of the crystals I went with in the KiCAD library:So C_0 is between 2.0 and 0.6 pF. For the ESR:

    We can set ESR = 35 k. We settle for a mid range load capacitance of 6 pF, which means our g_mcrit is calculated to be

    g_mcrit = 0.28 µA/V

    Which seems to be within the limits of the lowest drive level specified in the datasheet.

    Speaking of drive level...
    There is a section in the guideline document detailing this. In short, the current flowing in and out of the crystal needs to be limited for safe operation. I might look at that when the circuit is constructed. I might also turn a blind eye to it, and assume it's going to work out well.

    Step 2

    Skipping to section 3.3:
    Which should mean that with a C_L= 6 pF and an assumed C_s = 5 pF, we're short of 1 pF, which we'll add by using two 2 pF caps in parallel (as seen by the crystal). We're not going to fine tune the crystal.

    Step 3
    Hopping to section 3.8:
    Further reading reveals that determining R_ADD involves adding resistance in series with the crystal until the oscillator is unable to start. Looking at the safety factor comparison table, it seems like LSE oscillators like this might  be more stable in general... I feel I'm going to not bother unless there are any obvious issues ;-)

    Step 4
    We're assuming the lowest drive level of the STM32 won't overdrive the crystal. We could check on that when it's all soldered up, but we're done here for now.

    In summary:
    Crystal of choice: Seiko Epson MC-405
    https://www.mouser.se/datasheet/2/137/C-405_en-1109182.pdf
    Load compensation caps: 2 x 2 pF (assumed 5 pF parasitic load)
    No further trimming or tuning

  • Test board ready-ish

    Ole Andreas Utstumo02/24/2019 at 16:58 0 comments

    For components I stuck to the KiCAD library except the 2Mbit Flash IC.

    • STM32L432KBUx
    • SST25VF010A
    • LP2985-3.3 (just some random LDO)

    It's been a while since last time I used KiCAD.. I gotta say, the schematics are some of the best looking of any ECAD software!

    I'll do some bug combing later.

  • New revision scheduled up

    Ole Andreas Utstumo02/23/2019 at 15:32 0 comments

    I had shelved this project for lack of time after starting a new career in another country, but I recently got a text from a friend of mine telling me his heart was acting up, and he wanted a logger to what was going on.

    So I'm picking up this project again, and for extra learning, I'm changing the scope a bit.

    • I'm scrapping the bluetooth connectivity
    • I'm optimizing for power efficiency
    • I'm moving away from the hand solderability to standard reflow pads
    • The device will only log short intervals of data upon request from the user

    I'll also do the following changes

    • Shorten the electrode leads as much as possible
    • Scrap the SD card and implement a USB mass storage device coupled with an external flash IC
    • Switch to the STM32 platform

    So I've already got the analog front end working adequately. Now I will make a test PCB for the MCU and flash IC setup, and get the mass storage working. 

    I'll use this source as a guide:

    https://microtechnics.ru/en/stm32-i-usb-mass-storage-sd-card/

    The MCU will be a STM32L412xx. Off we go!

  • All soldered up

    Ole Andreas Utstumo02/02/2017 at 11:22 4 comments

    It wouldn't be a successful migration to a new PCB tool without introducing a new hardware bug, would there? ;) That's why pad[1] of the SERCOM module is connected to RX of the BT module. However, pad[1] cannot be configured as SERCOM TX, only pad[0] and pad[2]. To solve that we could

    a) configure the pin connected to the RX of the bluetooth module as an input (high impedance), configure one of the unused pad[0] pins as the SERCOM TX and run a wire between them.

    b) emulated UART in the firmware like the SoftwareSerial library of Arduino. Since we're only sending data, this could work out all right.

    Going for a would be the quickest solution. However, I'll give b a try, keep the PCB clean and learn something new.

  • KiCAD files uploaded to GitHub

    Ole Andreas Utstumo01/28/2017 at 20:16 0 comments

    I removed the link to the old CircuitMaker project, and uploaded all project files to GitHub.

    Help yourselves:

    https://github.com/Utstumo/Heartbeat-Logger/

  • PCBs for rev 3 arrive

    Ole Andreas Utstumo01/24/2017 at 11:36 0 comments

    Looking good! I couldn't resist, I just had to solder some of the components on it :)The bottom ground layer is without any major traces, set aside for the pads and traces for the memory card reader and the BT module where I removed all unnecessary pads, in order to improve the EMC.

    With the 3rd revision still using a discrete components in the analogue front end, the question might beg of why I didn't go for a packaged ECG front end IC. Well, I still wanted this project to be mostly educational, and I believe working with discrete, analogue components like opamps and inamps promotes a broader knowledge in circuit design. I added test points to the PCB now, so that tracking the signal, testing and verifying becomes much easier.

  • Fixed, smaller, a bit better

    Ole Andreas Utstumo11/22/2016 at 12:13 0 comments

    The logger is now redone in KiCad:

    Hardware bugs should be fixed, the bluetooth module can now be soldered directly to the backside of the PCB, there are mounting holes for the enclosure (if the battery allows it) and the whole board shrank in the process. Will be on the way to my mailbox soon.

    3.3V rail distribution is still not too great, but for any major improvement of that, the board should have been 4 layer, which costst a whole lot more.

    I did consider other more current efficient modules than the HC-06, but for now I know it works and is readily available at every Chinese silicon corner. It would have been fun to get acquainted with Nordic's nRF5xxx SoCs, though.

  • Streaming heartbeats

    Ole Andreas Utstumo10/28/2016 at 13:57 6 comments

    Giffed above is the Logger streaming data to my Surface via the HC-06 bluetooth module. All the bytes are sent to the virtual COM port and displayed using a processing sketch. It works out really well, in fact. The only issue is that there are no synchronization bytes, and since each sampled value is packaged into two bytes, there's a 50/50 chance of the sketch grabbing the correct byte first when you start it.

View all 39 project logs

Enjoy this project?

Share

Discussions

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

Jan--Henrik 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

Jan--Henrik 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: http://www.ti.com/lit/an/sbaa181/sbaa181.pdf. 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: https://www.physionet.org/physiotools/edr/. 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

thanks

  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: http://blog.world3.net/2011/11/using-the-xmega-dma-controller/

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