uECG - a very small wearable ECG

It's cheap, doesn't use a specialized heart rate AFE and can blink LEDs with your pulse :)

Similar projects worth following
Starting from
ultimaterobotics has 0 orders / 0 reviews
Ships from Kyiv, Ukraine
Tired of commercial overencumbered projects using expensive AFEs, we built a simple, cheap ECG wearable. It streams realtime data and works with phones and PCs. We ran tests on it, blinked LEDs and measured stress. In June, at Makerfaire Prague a lot of people successfully tested it and we ran a crowdfunding campaign to produce first batch! The campaign is over now, and we are waiting for funds to be released to start production. As soon as we produce the first batch, we'll have stock on tindie and can send to everyone on the waitlist (hopefully end of October). Tindie page:
Status: 1) waiting for Indiegogo funds to start production and have stock on tindie :)
2) manually assembling uECGs to take to Makerfaire Rome (paste with stencil, twitch hand, clean everything with alcohol, start over)
3) redesigning 3D printed case in FreeCAD

ECG is a simple signal, but few ECG devices can provide raw data and show ECG signal while running. Most are also commercial medical devices - over-engineered, bulky and expensive. Having worked with biosignals, particularly ECG, on several commercial projects, we decided to create our own - simple, efficient, and open source. 

Thus, uECG was born. It can stream realtime ECG signal via BLE or transmit to a desktop PC, using a simple (nRF52832-based) USB receiver that translates radio signal into virtual COM port data stream. 

Our goal was a low cost, low weight, high signal quality open hardware wearable that anyone could use. uECG is intended for makers, students or citizen scientists who want to use biosignals to do practical research - or just create things. It can also be useful as a diagnostic device for medical professionals in remote areas, without access to medical technology. And it’s open hardware - so anyone can build their own, or modify an existing one.

uECG has snap connectors that accept any single-use wet electrodes, as well as HRM straps or reusable electrodes. In a 3D-printed case, it is simple and can be worn for long periods of time. It’s relatively low-powered - enough for 9 hours of battery life at 100 mAh - so weight is also low, about 9 grams.

The system is based on MCP3911 front-end - originally developed for energy metering, but it performs nicely in our case too. It also has an AD8606 buffer precision opamp, an nRF52832 SoC for Bluetooth/RF and signal processing, and a VOS617B-7T optocouple to connect other devices (LEDs are one example, everyone loves them). Without LED indication, device uses less than 10mA even during BLE transmission at 125 Hz. For PC transmission, our custom radio protocol is used at 1 kHz.

The firmware uses our own filtering algorithm to filter out mains noise (both 50 Hz and 60 Hz, without distorting high frequency components of ECG), resulting in a clear, readable ECG graph you can use for anything. The signal quality of this setup is quite high - but there will be more on that in logs.

Here's what you need to build uECG (base station is for streaming to PC, not necessary for smartphone):

PCB files:
uECG v4 PCB design
uECG v4 gerbers
Base station PCB design
Base station gerbers 

uECG firmware 
Base station firmware
Firmware build and upload instruction

Android app and desktop tool:
Android app source code
Android app compiled
PC tool source code

FreeCAD model
Top part for printing
Bottom part for printing


A BOM for the latest v4 version

Microsoft Excel - 11.00 kB - 10/01/2019 at 14:15



Device overview

Portable Network Graphics (PNG) - 125.39 kB - 09/30/2019 at 21:14


uECG v4 KiCAD project

Zip Archive - 425.17 kB - 09/30/2019 at 20:45



uECG v4 schematics in pdf

Adobe Portable Document Format - 140.40 kB - 09/30/2019 at 20:45


uECG v4 gerbers

Zip Archive - 169.82 kB - 09/30/2019 at 20:45


View all 18 files

  • 1 × nRF52832 (on PCB) popular Bluetooth SoC
  • 1 × MCP3911 (on PCB) a generic AFE
  • 1 × BMI160 (on PCB) IMU
  • 1 × RGB led (on PCB)
  • 1 × micro USB

View all 8 components

  • New PCBs from factory: uECG (v4) and 16-LED nRF52832 base

    Ultimate Robotics10/01/2019 at 13:47 0 comments

    A package from PCBWay with a new version of uECGs just dropped! Or rather was brought by DHL courier, which deliver better and better by the shipment - previously we shied away from them, because there were too much red tape and they were arrogant, but maybe they're not so bad after all. 
    Anyway, there were three uECG versions before this one:
    - the v1.0, made back in December, 2018, which required some wires to work and had ECG snap connectors salvaged from Chinese cheap wired electrodes bought at a taobao acupuncture shop. We found a shop that sold snap connectors after that, which was a great adventure that took some weeks, but we learned some Chinese words along the way.
    - the working v2.2 - most featured in videos and tests
    - black one, the v3.1 - we had experimented with halvanic skin measurement there, but that didn't work so well. We also planned to add vibe motors to make a gamer feedback device - maybe still do that later.
    - and now the new v4 had all bugs fixed (thanks to hackaday commenters for pointing out some of those!): analog and digital ground is properly connected now, and it also has protection in form of a resettable fuse and a BAV99.

    Read more »

  • Project ideas: uECG for EMG and branching out into AR!

    Lucy Sohryu09/28/2019 at 00:42 0 comments

    Like uECG is a simple solution to a usually overcomplicated problem, we have a few other projects that aim to hack modern technology into small, manageable, open-source pieces. Most of the time they exist in different forms - "good idea" seems to be the most popular. But recently a couple of them moved to the next stage.

    Read more »

  • The honest update

    Lucy Sohryu09/23/2019 at 23:49 2 comments

    Originally, we intended this to be just another standard project log.

    Then we stopped, examined what we were doing, and wrote this instead.

    One week ago, we were super excited about everything going on. Yes, Indiegogo wouldn't release our money, but things were happening all around us - at an alarming rate. We went from nobody to Hackaday Prize finalist (as per our previous update). People have been following our page. We set up our Tindie page and people started pre-ordering uECGs. We had several new devices just about ready for production, with only a few minor touches left (like actually doing the PCB layouts for them). And we were just about ready to solve the Indiegogo problem by setting up a TransferWise account - and then waiting until they do a background check on us to activate that account.

    Then everything changed. 

    Read more »

  • Things are happening! (big update)

    Lucy Sohryu09/11/2019 at 22:31 0 comments

    Hello - and welcome to our 10th project log! Things have been happening, the short version of which is:

    - we've set up our Tindie store, so now you can get uECG pre-ordered there!

    - our crowdfunding campaign is over, and we raised enough to find out people are interested in uECG;

    - we're going to Rome for MakerFaire, October 18-20, and will bring uECG and a couple of new projects;

    - Make:Magazine did a Maker Spotlight on us - here;

    - our website is back, and looking better;

    - and last, but not least, we (suddenly for us) made it into Hackaday Prize finals! Being busy with our Indiegogo campaign in July, and grappling with Indiegogo bureaucracy through August, we kind of completely forgot about Hackaday - until yesterday, when an email arrived, saying that we're one of the 20 finalists for the Hackaday Prize! This was on top of a wave of activity we had in the last few days, so it's probably time for a short recap of what's happened.

    First of all, though, we've decided to set up an online store at Tindie. The store looks a bit raw, but if you want to get your uECG from us, hit this link and it will take you to the product page :)

    Second of all, our Indiegogo campaign concluded in July, raising $2031 over the month - our minimum goal was just $600. The campaign has been in inDemand since August, so we've actually raised a bit more money since then, and will use it to produce and ship more devices than originally intended.

    Sadly, Indiegogo hasn't exactly been forthcoming: it took us several weeks to get our identity verified, and we've yet to get the funds we raised because of some problem or other. That's why we've been exploring other options to get our devices out there, while also getting ready for production - that's a new one, and we're actually looking forward to it.

    Third, we'll be at MakerFaire Rome this October! If you're in the area, come find us at Fiera di Roma from Oct. 18 to 20 :) Rome is a very big event for us, the biggest one in Europe, and we're getting ready for it. We'll be bringing uECG, of course - it's the star of the show. But we also have a few projects in progress that we'll bring as well.

    Also, the MakerFaire Rome team got us in touch with Make:Magazine for their Maker Spotlight feature - the interview went out just yesterday, and you can check it out here - we talk about what drives us, what our future goals are and what we believe in. 

    Fourth, with all the commotion, we finally got to sorting our website out! Now it runs on Ghost and is still under construction, but with the old website in limbo for so long, that in itself is a fascinating project. 

    And last, but not least, the Hackaday Prize - we're honored to have made it into the finals, and we're grateful for the opportunity to participate. Honestly, we never expected that we'd make it. 

    To everyone who's liked and followed our project: thank you! 

  • We're crowdfunding!

    Ultimate Robotics07/03/2019 at 22:11 0 comments

    Finally we got to post on Hackaday! We're back from Makerfaire - it's been a very busy time. Lots of people (20+) tested our device in the field, so to say, and ironically, it could be considered a stress testing for our device, though we couldn't measure its stress level :) Surprisingly, it worked well on most of the people - the only complications were body hair and when some of the clothes made it difficult to stick (for example, on women).

    We were very excited that people could see our device and that it was interesting to them. Mostly they were just excited to try it, and some of the other people fell into two categories: they either didn't understand what's it for, or straight up wanted to work with it. We even had a doctor tell us that he definitely wants to use it to just give patients to wear at home, as a support to hospital diagnostics! 

    And one other person we gave our device and the USB desktop base for it so he could use it for development immediately, which was immensely inspiring. The excitement could probably be better seen on our faces in the photo, if we weren't so tired :P The exhibition is a very noisy, busy place, and we spent a lot of time getting there and preparing and running around, but it was totally worth it!

    (by the way, the big screen shows some EEG, which is our other project, Skulljack)

    We have been planning crowdfunding uECG for some time before the Makerfaire, so we prepared discount coupons with a QR code link to secret perk, but weren't sure if anyone will be interested. But people took around 30-40 of them, so when we returned we decided to do it :)

    The campaign is now live on Indiegogo. It's nothing fancy, just uECG - base price of which is $79 - and a couple options, like adding a 3D printed case, our USB base station and a Chinese STLink clone so you don't have to wait for it from Aliexpress!

    uECG campaign card
    uECG - a very small wearable ECG on Indiegogo!

  • We're at MakerFaire Prague!

    Lucy Sohryu06/22/2019 at 13:43 0 comments

    Hi everyone! We're at MakerFaire Prague, with both uECG and Skulljack! It's been a really hectic month, and it looks like a really hectic weekend here, as well!

  • Of dragons, stress levels and ECGs

    Lucy Sohryu04/15/2019 at 20:04 0 comments

    We're pretty sure nobody tried measuring stress using Skyrim and an ECG device, so we decided to try it ourselves and give uECG another test drive, now with more participants. Unfortunately, since we didn't have any saves with a cave bear or a sabercat (or a spriggan) going off in your face, we had to use a dragon instead. 

    Technically, those were two dragons.

    Fascinating trivia aside, we had a go at the dragon du jour in pairs, one person playing and one person  watching, to see how heart rates and stress levels change depending on how involved you are with the game. The results we've got, after cleaning them up, were wide and varied - about half of the players had elevated stress while fighting dragons, but lower stress while watching; the other half had elevated stress while watching the other fight, but got calmer and focused once it was their turn. For someone, it didn't change much at all! 

    We've got excellent graphs and Poincare plots coming up in the next log, but so far, we've enjoyed this, and are just itching to test ourselves - and our hearts and minds - further, hopefully with something more stressful than a mere dragon. So far, the results were promising.

    Just gonna need more data.

  • Poincare plots are now available! :)

    the_3d604/10/2019 at 18:57 0 comments

    After updating Android app so it stores all consequent beat times, detected on the device, we can build Poincare plots - for two consecutive beats, time of 1st beat is used as X coordinate, time of second beat - as Y coordinate, thus producing one point. A healthy heart has some variations in RR intervals, but they are relatively small, so Poincare plot looks somewhat like ellipse with long axis lying on X=Y line.

    I've tested it before, during, and after running (it was a short ~15 minutes run). This is what I've got:

    It showed a problem that wasn't obvious before: beat detector sometimes skips beats - and thus we see almost perfectly aligned series X=2Y and 2X=Y (and some traces of X=3Y and 3X=Y). In case of real heart problems, there could appear "clouds" in these areas, but they are far from such a perfect straight lines, so this is definitely a problem of detection algorithm. Will work on that!

    Besides this problem, it seems to work really well. Here is a chart of BPM vs time (I've started run after ~50 minutes after I started recording, and during the run, made a pause and then short sprint - all clearly seen on the chart)

  • Uploaded schematics and PCB

    the_3d604/06/2019 at 11:56 0 comments

    Thanks for the followers and likes! :)

    After some more testing of version 2, everything looks good, so we uploaded our schematics and PCB design files (in KiCAD 5). It still is not the final version, but it works as intended and we found no hardware problems (yet) - so if there are some bugs, they are not critical.
    And here is a 3D render of the PCB:

    Firmware is still far from being ready, but we'll share it too when it would work smooth enough.

  • Now we can measure stress!

    the_3d604/04/2019 at 19:18 0 comments

    We added calculation of distribution of differences in consecutive R-R intervals - so now we have a measure of how exactly these intervals change from beat to beat. There are many papers that use percentage of intervals that change by more than 50 millisecond for indicating stress level. But when we got full distribution, it was worth looking at!
    We built a histogram of changes: first bar indicates how many R-R intervals vary by less then 10 millisecond, second bar - from 10 to 20 ms, third bar from 20 to 30 and so on. And I've went through normal, stressed and relaxed states. Here is the result:

    So clearly this histogram is useful for indicating current state - but we need more experiments to determine what exactly it means. For now we just added it in the app interface, in two time scales, and will check how it behaves in different situations. 

    ...also take a look how clear the signal is with the new version, even on the phone with lower data rate and some lost packets! ))

View all 13 project logs

  • 1
    How to: uECG build and firmware upload process

    We work in Ubuntu 18.04, although this should work with most Linux versions. We have no idea how to do this on Windows, sorry :)


    Nordic SDK version 14.1 (both older and newer versions won’t work without config modification, although functionally it should be compatible with any version at all - we use only very basic SDK functions, no soft device)

    Arm-none-eabi compiler version 8-2018-q4-major or higher

    OpenOCD version 0.10.0 or higher 

    STLink programmer (any clone should work just fine)

    Build process configuration

    1. In Nordic SDK you need to write path to arm-none-eabi compiler tools, it is located in file components/toolchain/gcc/Makefile.posix

    Its content should be following for given compiler version:

    GNU_INSTALL_ROOT := /home/<your user folder>/<path to uncompressed compiler folder>/gcc-arm-none-eabi-8-2018-q4-major/bin/

    GNU_VERSION := 8.2.1

    GNU_PREFIX := arm-none-eabi

    (if you use a different version, adjust folder name and version code accordingly)

    2. After that, inside project folder, you need to adjust SDK path in makefile. Open project Makefile and put correct path in this line:

    SDK_ROOT := /home/<your user folder>/<path to Nordic SDK>/nRF5_SDK_14.1.0_1dda907

    (adjust SDK folder name accordingly if your version is different)

    That’s it for build config. Now you need to run make in project folder and it should produce compiled .hex file.

    Upload process configuration

    Download openocd. Unpack it to some folder (for this document we assume it is located in ~/openocd) and in the terminal, enter the following:

    sudo apt-get install make libtool pkg-config autoconf automake texinfo libusb-1.0-0-dev

    cd ~/openocd

    ./configure --enable-stlink


    sudo make install

    Uploading firmware

    Connect the device to the programmer. Pins on uECG have text labels, check pinout of your particular STLink programmer for proper connections.

    In the project folder (it’s important!) execute openocd command:

    cd ~/<your-project-folder>

    openocd -f interface/stlink.cfg -f target/nrf52.cfg 

    If everything’s ok, command will not return to the shell, so open a new terminal window and enter:

    telnet 4444

    This will establish connection to OpenOCD via telnet. In telnet prompt type:


    nrf5 mass_erase



    flash write_image erase _build/nrf52832_xxaa.hex  (put relative path and name of .hex file)


    And that should be it!

View all instructions

Enjoy this project?



Jacob MacLeod wrote 10/01/2019 at 10:22 point

Cool! What... exactly is an ECG?

  Are you sure? yes | no

the_3d6 wrote 10/01/2019 at 13:51 point

ElectroCardioGram :) In other words, heart electrical activity. We record it (send to PC or smartphone), and also detect heartbeats with onboard algorithm, so it can be used for blinking LEDs or something without any PC/phone connection

  Are you sure? yes | no

ksk wrote 09/18/2019 at 21:08 point

Hi, I've uploaded the KiCAD to MacroFab and am populating the BOM. I am guessing that SW1 is from Ali[baba,Express], but can't find a good reference. Same question for the micro USB, though I might be able to make a good guess for it by looking at the footprint. Can you provide part numbers for both?

  Are you sure? yes | no

Lucy Sohryu wrote 09/19/2019 at 17:46 point

Hi! SW1 is MSS3-V-T/R from Diptronics (also known as SS-1290 or IS-1290A-W), SW2 is just standard 4.5*4.5*3.8 tact switch, but can be found under part number K2-1109SP-A4SA-04, from Korean HROParts. Micro USB is U-F-M5SW-Y-3, also from Korean HROParts. 

These should fit. But maybe there are more popular part numbers for those switches and USB that we don't know about yet. We're just preparing for factory assembly, and previously used these switches and USBs that we bought earlier. 

  Are you sure? yes | no

Thorsten von Eicken wrote 09/15/2019 at 04:27 point

Does the uECG work with a HRM strap, or does it require special electrodes? If so, are they reusable?

  Are you sure? yes | no

the_3d6 wrote 09/15/2019 at 06:27 point

Yes, we checked it several days ago - it gets really good signal. Although it has an opposite type of connector (uECG uses female, and straps have female on them) so we had to solder a male-to-male connector to attach it (simply by soldering two connector parts together, it was surprisingly easy)

  Are you sure? yes | no

forthprgrmr wrote 09/10/2019 at 20:28 point

There are a lot of op amps that I'd choose before the 8606: ADA4528 is much quieter, but slightly higher cost and current, the MCP6V62 is also quieter in the 0.1 to 10Hz band, cheaper, and much lower in current.  The nice thing about these zero drift amps is that there is no 1/f noise.  You say that you're just using the HF content so the 1/f noise might not be important.

Also pay some attention to the noise generated by resistors.  A 100k series resistor is quite noisy in these applications.

My work is more focused on EEG rather than ECG so I'm more focused on noise.  You might be just fine.

What I notice in projects like this (and inexpensive 'scopes) is the analog section is weak while the micro/rf/software is nicely done.  I know good analog engineers are hard to find, but try.

  Are you sure? yes | no

the_3d6 wrote 09/10/2019 at 21:43 point

MCP6V62 looks good, thanks! ADA4528 is way too expensive here.
As for resistor noise - you are right, we forgot about it. Before we added DC shift for measuring skin resistance it was safe to ignore (we didn't have input 100k then and no 10M pull ups), but in the latest revision we added DC shift, and even though in measurements it didn't show any noticeable difference, it really has to be properly estimated.

  Are you sure? yes | no

the_3d6 wrote 09/10/2019 at 21:52 point

*although a quick estimate gives about 1.2 uV in our frequency window, while our ADC gives 1.1 uV per meaningful bit, so it doesn't look really worth worrying about

  Are you sure? yes | no

Marcos Chaparro wrote 08/03/2019 at 15:02 point

I'm wondering where are GND and GNDA joined together. Inside the ADC chip?

  Are you sure? yes | no

the_3d6 wrote 08/04/2019 at 15:53 point

Wow, you've spotted it! :) No, in fact we forgot it in this design version and had to connect via additional wire (it was convenient to connect grounds of analog and digital LDOs, they have relatively large pads for soldering a wire). But it will be fixed in the production version!

  Are you sure? yes | no

Marcos Chaparro wrote 08/04/2019 at 20:29 point

A 0 ohm resistor there lets you easily try a choke to see if noise goes down.

Also I see no ESD protection at the input terminals, the OpAmp input is exposed.

Anything else should be fixed? I may give this schematic a try these days

  Are you sure? yes | no

the_3d6 wrote 08/04/2019 at 20:53 point

This opamp has in-built ESD protection so it's fine.
We missed GND bug in 2 consequent revisions because surprisingly it doesn't really affect signal - analog LDO keeps AGND at 3.3V distance from battery positive rail, and that is still within the range of ADC. I really can't tell any difference between fixed unit and the one with this bug (but it still is a serious bug, we just got lucky here).
Not sure if choke would make any difference - it seems that nearly all noise is external, digital part takes too little power with too small fluctuations to really affect the signal.

  Are you sure? yes | no

Marcos Chaparro wrote 08/04/2019 at 23:51 point

Yeah I figured it would still work, I asked because maybe it was on purpose.

Most chips have some light ESD protection, but its usually not enough. Try zapping that input with an ESD gun, or a stove lighter to prove its enough, because I'm pretty sure it isn't.

You don't need this... but I designed medical grade ECGs a few years ago and they needed to survive a defibrillator discharge -and recover in <5 seconds-. A series resistor + beefy tvs was enough protection and didn't skew the signal ;-)

  Are you sure? yes | no

the_3d6 wrote 08/05/2019 at 03:04 point

I think it won't survive stove lighter discharge :) Never thought that it might need to withstand defibrillator - but you are right, something as simple as 100k resistor and TVS would do just fine (and we have resistor on one side already), so probably we should add it

  Are you sure? yes | no

Marcos Chaparro wrote 08/07/2019 at 03:21 point

Another tip: missing bypass caps on both supply pins of the ADC ;-)

Accel should have a bypass as well.

A fuse right at the battery connection is usually both wanted and required.

  Are you sure? yes | no

the_3d6 wrote 08/07/2019 at 07:12 point

In schematics you can see decoupling capacitor only on analog supply of ADC, but in fact on PCB it shares digital supply decoupling cap with one of NRF's. IMU also has decoupling cap placed next to its supply (it's not specifically outlined in schematics, but I kept placement in mind during PCB design). Although analog supply cap is too far from the pin, I really should change that (it still works, frequencies are relatively low there, but it isn't optimal).

Adding a fuse is a good idea, thanks! The main problem is possibility of accidental contact of battery wires with random PCB pads during soldering process (and fuse would save only power chips in such case, sensitive analog ones won't survive anyway), but I don't think it could be improved.

  Are you sure? yes | no

John Loefler wrote 06/09/2019 at 14:28 point

I have been looking for those kind of connectors for grounding. Do you have a supplier/Part Number

  Are you sure? yes | no

Ultimate Robotics wrote 06/11/2019 at 11:33 point

Oh, these are indeed hard to find, we've been trying to find them under various names until we guessed the correct keyword :) We bought ours on taobao, shipped to us with Meest-China (it's a freight forwarder). Here:

They're called "ECG snap connectors", the Chinese keyword is 心电扣. I believe I also saw them on aliexpress, but it's often faster (not to mention cheaper) to buy them in China directly and forward after that. Also, there is more choice, so for example I could buy our snap connectors from manufacturer directly. To find difficult stuff you can google by various keywords in Google images and then do an image search by uploading most prominent pictures.
Also here's some snap connectors on aliexpress:
(but they cost $24 here, while I bought the same amount for $5.5 on taobao)

  Are you sure? yes | no


[this comment has been deleted]

the_3d6 wrote 04/26/2019 at 19:07 point

Thanks! We are getting it ready for production, hope to start crowdfunding really soon (we almost finished development, now the main goal is to get some visibility so we'll have enough bakers to produce the first batch)

  Are you sure? yes | no

Mark wrote 05/24/2019 at 21:36 point

Interesting.   Where are you crowdfunding and how much are you trying to raise?

  Are you sure? yes | no

Bud Bennett wrote 04/09/2019 at 20:00 point

I really hate it when people comment negatively on my projects, but I really love it that they are interested enough to make a comment. My background includes design of medical equipment in the olden days: 1977-1983. I took a look at your schematic and have a couple of questions, or comments for improvement.

1. It doesn't appear that you need to use a unity gain amplifier (the AC8606) to buffer the ADC. U1B is biased near GND and might have problems tracking signals below GND. U1A doesn't do anything at all, except draw current via the 10Ω load of R3.

2. The MCP3911 has a PGA that should eliminate the need for the AD8606. If you biased the CH0- input a few mV above GNDA and AC-coupled CH0+ it should be all that is needed. Yes, there is some uncertainty as to the input impedance of the MCP3911, but that doesn't worry you with regards to the time constant of C17. which uses that impedance.

3. The need for the onto-isolator U7 escapes me. Please elaborate.

4. The ADC doesn't include a 50-60Hz notch filter. Many other ∑-∆ converters include a 50-60 Hz notch. A notch would make the subsequent signal processing easier.

5. D2 is a mystery to me. Please explain.

Overall I'm impressed with your progress. I like it a lot.

  Are you sure? yes | no

the_3d6 wrote 04/09/2019 at 20:50 point

Hi! No problems with negative comments - but yours aren't negative at all :) Quite the contrary, thanks for taking a deep look at our schematics!

It seems that you've missed that we have not 2 but 3 grounds: GND is digital ground, GNDA is analog ground, and GNDS is a virtual "ground" which is actually at +0.6V and we measure all analog signals around it. Probably our symbols are misleading ))

1. U1A generates virtual ground - divider on its input sets level of about 0.6V and U1A repeats it (via 10R resistor just in case if something goes wrong, no real need in it since amplifier survives short circuit). That level of 0.6V is our zero point around which we work (and normally we stay within a few mV around).

2. MCP3911 has input impedance of about 30k when PGA is set to 32 amplification - and skin has impedance in a few MOhm area (measured that for gel pads and placement we are using) - so without buffering input with AD8606, it works like a voltage divider. Actually in our first iteration we made a mistake and had to omit amplifier completely - and it worked somehow, but signal was much, much worse and very sensitive to contact quality.

3. It is for connecting to external Arduino or other microcontroller: we are detecting heart beats onboard, and send them as short pulses there. Optocoupler makes external connection simple, eliminating possible problems (you can just connect it, and if it doesn't work - connect with opposite polarity). 

4. Yes - but check project logs, I'm really proud of the filter I've made! :) It's better than anything I saw before - including max30003 AFE which is specifically designed for ECG. Our result is seriously better (we work on another project based on max30003 in parallel, so I can compare them in identical conditions). And MCP3911 is the cheapest 16 bit AFE out there! )) (also uploaded illustration of how it works in extreme conditions: )

5. MCP3911 can be damaged if input voltage exceeds +2.0V on any ADC input. Normally we work around 0.6V point, but when the unit is not on the body, input can get anywhere. As soon as it exceeds approximately 1.2V, LED turns on, protecting the input and, at the same time, visually indicating that there is overload! And it actually works, when it's charging via usb, you really can turn it on by touching only one input! ))

  Are you sure? yes | no

Bud Bennett wrote 04/10/2019 at 00:48 point

Fair enough. I grok it now. There is a reason for everything in a schematic, if not entirely obvious. I'm an old school EE, so schematics should have wires connecting components instead of tags. It's easier for those not familiar with the design to understand what's going on. 

Thanks for the answers. Carry on. It obviously works.

  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