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 30 orders / 0 reviews
Ships from 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. We then brought it to Makerfaire Prague in June 2019, where a lot of people successfully tested it, and in July 2019 we ran a crowdfunding campaign to produce the first batch! In October 2019, we attended Makerfaire Rome with a pre-production version of uECG before finally producing them in November. And we also participated in the 2019 Hackaday Prize (Honorable Mention for Best Design).

We sent uECGs to all our Indiegogo backers in February 2020. We originally planned to produce another device batch in March and sell them, but it was delayed due to COVID-19 and we had to switch to freelance work for the next few months. However, as of July 2020, uECG is finally available in our Tindie store!

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

KiCAD files for receiver base - ultimate_base rev2.6 (produced in November 2019 - first batch production run). With fiducials, pogo pin pads.

Zip Archive - 268.87 kB - 12/06/2019 at 18:50



Centroid file for receiver base - ultimate_base rev2.6 (produced in November 2019 - first batch production run)

pos - 2.62 kB - 12/06/2019 at 18:50



Receiver base PCB leds polarity indication (for manual assembly/useful for factory check)

JPEG Image - 190.93 kB - 12/06/2019 at 18:50



BOM for receiver base - ultimate_base rev2.6 (ready for production, complete with comments and Chinese supplier links, produced in November 2019 - first batch production run).

sheet - 11.78 kB - 12/06/2019 at 18:50


Gerbers for receiver base - ultimate_base rev2.6 (ready for production, produced in November 2019 - first batch production run)

Zip Archive - 94.17 kB - 12/06/2019 at 18:50


View all 28 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

  • Some more Maker Faire stuff

    Ultimate Robotics10/17/2020 at 07:51 0 comments

    We were so deep in Maker Faire preparations that accidentally posted two logs about the event authored by two different team members. Anyway, the last one has more useful links, so we decided not to delete it and just edited a bit.

    Main Empire State Maker Faire 2020 page. The event is live from 16 to 17th October, with Friday reserved for more student and school-oriented events and the rest for the Saturday. 

    So our stream's today (Oct 17) 10:30 EST. Come chat! 

    Link to the stream here:

    Our project on Make Projects:

    All of the events:

  • Live streaming on Empire State Maker Faire

    Kseniia10/17/2020 at 01:15 0 comments

    We'll be streaming live this Saturday on Empire State Maker Faire! We'll be showing our home workshops, devices new looks and abilities, and generally talking about open source stuff and plans on Saturday, Oct 17, from 10:30 to 11:15 EST (that's 17:30 Kyiv/Eastern European time). 

    There are lots more cool events there, so be sure to check out the Maker Faire schedule. We're personally hyped for the 12,000 masks, Genspace and Public Libraries Print PPE ones - and we'll also be sure to check our as many makerspace tour streams as we can!

  • Wireless firmware upload for uECG!

    Ultimate Robotics10/03/2020 at 13:12 0 comments

    You probably have noticed that updates began to appear more and more often!  To be honest, we are also happy about this...

    The development of the device partly coincides with our development, too, because the technologies we apply here are related to our growth as specialists. For example, a year ago we were able to make only primitive applications - rather, more data output to the screen - and over the past six months the quality and functionality of the application has grown significantly.  

    But today I would like to tell you a little about the technology that we have been trying to implement over the past few years: the bootloader. It is very strange, but no matter how we looked, we hadn't seen a single post covering the whole process, a single implementation available. Possibly it is because Nordic's softdevice has it, and even though this code is closed and proprietary, it gets the job done - so people are more or less ok with it.

    Not us though. And it's in fact a very simple thing - but somehow it is not properly described anywhere! So we had to improve our knowledge of ARM architecture, linker scripts, physical memory layout of the program - and when it was good enough, actual programming of a wireless bootloader took less than two weeks. Yet the whole way to that point took about 2 years, with 5 or 6 failed attempts in the process. Hopefully our code and notes would save this time for anyone trying to do the same:

    So, at the end of August it finally became possible to upload firmware via radio! It is very cool! And we hope reliable... so we advise you not to rush to throw out st-link programmers just yet... We filmed a video review of the firmware upload process and will add this part to the instructions. But we will also record a separate video so that everyone who received the device before September 1 can upload the firmware without a programmer.  

    So we'll be in touch! And write if you have questions / suggestions / and just kind words!

  • uECG now on Windows!

    Olya Gry09/21/2020 at 18:29 0 comments

    Unbelievable, but it is a fact! We have finally released our application for Windows, macOS and Linux!

    Initially, we were not sure that there would be a need for Windows application, but with your feedback we realized our mistake :) The process of installing and launching the application is described in detail in our Instructions section. We added all updates and new features there.

    Also, while we were working on Windows app, we somewhat expanded its functionality. We added new charts, namely temperature (yes, we never told you, but there is a thermometer inside as well - but not really precise, so it's of less use for medical purposes) and battery voltage. And PC app works with x8 higher data rate than Android - which allows to see more details of the signal! But other than that, it is very similar now.

    We invite you to watch our joyful greeting and review of the application in a new video!

  • A major app update (ECG plots, Poincare, HRV, accelerometer data)

    Olya Gry09/08/2020 at 20:21 5 comments

    Over the past six months, we have been biting our nails in hope for feedback on the use of uECG. But the feedback we got was mostly about the fact that the mobile app does not run on one phone or another… so we did a major app rework! 

    And also added new functionality:
    - Poincare plots;
    - HRV, BPM, GSR and accelerometer graphs; 
    - app can now run in the background;
    - a lot of UI updates, like convenient interval choice

    The new app (already on Google Play) works on all of our four phones, on Android 6 and above - we checked up to Android 10 - but there is a trick with Android 6 phones to make it run. We recorded a short video to demo the new features and also show every step from installing to using the app.

    We hope you find this video interesting and useful! 
    ...and that now you will be able to actually use our app :)

  • uECGs in stock on Tindie and last few months recap

    Kseniia07/13/2020 at 08:45 2 comments

    Hi everyone and hope you're in good health! We're back. Spent this time surviving under quarantine and returned to freelance for this, because COVID hit just before we could get the shop going.
    It's been a few hard, but very interesting months. In time left from commercial projects, we tried to develop something useful for COVID and hit some hackathons (including EUvsVirus, which was amazing). This spawned two new projects - a bluetooth oximeter and an Odroid-based patient monitor

    We also made a video with our thoughts on medical certifications featuring the patient monitor - apparently too edgy at the time of making, but look what's happening now. Major stuff all over the world. Maybe we'll see the end of gatekeeping in the medical industry not in several years, but much sooner! 

    Until then, we are going to do what we can from our side, which includes finally opening the shop. Or rather two shops: the Tindie one for global sales and our Ukrainian one for local sales. That'll have to do until we find a good international card payment system that works in Ukraine. With Tindie, we've had two problems: no PayPal (not available for receiving in Ukraine) and no money for paying initial order shipping fees because funds from sales become available on Tindie after one month only and everything we've earned from freelance we've spent on rent and food. Now we managed to secure both - a friend will host PayPal for us, and we also have some extra funds.

    So without further ado, the Tindie shop is now open and uECGs are in stock! We're putting a small amount out for now. We'll add stock gradually if we have money left for shipping! :) Those who are on the waitlist, will receive emails automatically.

  • An Android app adventure

    the_3d602/17/2020 at 20:44 0 comments

    We started writing Android app at the beginning of last year. Since most of the development was on my (Dmitry’s) Meizu phone, that’s the only phone it was tested on. Only after some time we found that not all phones on our team were able to run the application. A lot of things happened - Maker Faire, factory production, then manual assembly, packaging and distribution of devices. Only a couple of weeks ago we realized that a problem with the application could affect many users.

    I’m a beginner Android developer. To be precise, I only wrote one Android app - once I copy-pasted something that works kinda the way I like, and since then I made many variations of that first app for different purposes. Even BLE functions were partially inherited from previous projects (these I proudly wrote myself using Android documentation, because I couldn’t find any example simple enough to understand). With one important difference: in uECG protocol, data stream really pushes capabilities of BLE advertising mode (not theoretical limit, but a practical one, where really a lot of packets could be lost). And I wanted advertising mode because it’s much simpler to implement on the device side. Yes, about the device side: there’s one thing - we are not using softdevice, for a number of reasons (microseconds-precise timing, LEDs driver, 1 ms data processing cycle - all of that is based on interrupts and softdevice would delay them. It kinda can be workarounded and/or reduced - but why restrict future development options?). So I’ve implemented advertising protocol manually. And it worked with my phone just fine (as well as team members’ phones at the moment), everything was going well, until we got a new phone and started to test with it. To my surprise, nothing worked at all - that new phone was just ignoring packets. I’ve started to dig into BLE documentation and wrote a BLE sniffer. In a few days I found and fixed several things that weren’t compliant with BLE specification (yet worked on older phones). And… nope, it still didn’t work on the new phone. Except for some strange cases: once in 10s or 100s of thousands packets something was getting through. I started to suspect that packets that actually got through were corrupted but by chance had correct CRC. Sure enough, after 3 days of experiments I found that custom data field length should be different from what’s described in BLE documentation (at least from that particular document I was using: actually there is no single point where you can get all the data you need). As soon as I changed it, everything started working on all of our phones… except for my own old one! After some more guessing I realized that Android banned my application from using any active form of BLE scanning - so when some other app was scanning BLE in the background, my app also received the data and worked just fine. But as soon as other, non-banned app, was turned off - my app stopped working too. I still have no idea why it happened and what to do about it (not a single hint anywhere), but apparently this is a problem of my particular phone and my Android being not happy with my code. I can live with that! :)

    App in play store:
    Source code:

  • uECG instruction update

    Ultimate Robotics02/11/2020 at 02:22 1 comment

    While the shop is in last stages of development, we uploaded a new instruction for uECG! After sending first devices to Ingiegogo backers, it was time to seriously update the instruction section, cause it only contained information about the firmware. It now has 8 steps - for complete experience, we added lots of pictures and a video:

    The instruction contains info about uECG kits, but it's also useful if you want to assemble your own uECG or just interested in the device, its parts and how everything works. 

    The first step is unpacking - we decided to show in detail what you receive if you order uECG. The second and third steps are power on and usage - turning on the device and placing it on the chest. Simple actions, but better to show them. Step 4 - using the app: we uploaded the app on Google Play and now you can download it (it’s free, of course) and use it to receive data from uECG on the phone. Steps 5 and 6 are power off and charge. And then, steps 7 and 8 - firmware update, showing how to connect the STLink programmer and pogo pins, and the firmware upload process itself.
    Feedback is very important to us, so please write in the comments if you have thoughts or questions (especially if you already have uECG :)

    In the meantime, here’s a video instruction showing how everything works:

  • We are opening an online shop!

    Kseniia02/04/2020 at 00:35 0 comments

    Okay, time to address the elephant in the room: the Tindie waitlist! There are 137 people there currently, and we're sure some of you are reading this log. 

    We watched as it grew, but couldn't do anything cause first we had to send the devices to Indiegogo backers. Now we can! There's around 20 sets that we can pack right now. But it turned out that we can't actually sell them through tindie without lots of effort. That's for two reasons:

    1) In the New Year log, we mentioned capitalism as one of the confusing things that we faced recently. Now, we can elaborate: basically, we can't legally get money for uECG sales on Tindie in our country. That's cause Tindie only makes payouts to PayPal and it's not available in Ukraine. We can pay through it by linking a card, but we cannot withdraw (can't use PayPal balance).

    Theoretically we could use a middleman webservice, but they take commissions of around 5-9% - that, plus Tindie fees, could get them close to 18-20%. That's a lot, cause uECG price is low on purpose to make it affordable, and we can't get it lower. We contacted Tindie support and unfortunately they can't add another payout option for now. We later discovered that a lot of platforms use PayPal primarily, so they don't work with Ukraine and some other countries out of the box. It's a pretty grim picture out there.

    2) The other thing is that even if we had PayPal, we could only get a payout in a month minimum (there's a cooldown time for first-time sellers). So we would have sold all the uECGs at once and have no money for production (we have to borrow from our family for the next round partially anyway, but still need the rest).

    Basically, we were very frustrated by this for the last few weeks. But then we realized we promised uECGs will be available, but it's not that important to everyone it will be on Tindie. What people want, first of all, is to just buy and use them. 

    So we decided to open our own online shop based in Ukraine! A couple of people from our team did web dev and e-commerce in the past, so we've been setting it up for the last couple of weeks and making some more progress just recently. 

    What's next:

    - We plan to open a shop in the next few days; we are on the step of writing the content like delivery pages, fine-tuning the CMS (it's on Prestashop), and soon hopefully will be connecting the payment system. Why are all the e-commerce CMS still on PHP, though? It's been like 10 years! We looked for what's new and trendy in online shops and couldn't believe there was no large JS-based systems available. 

    - We plan to start new production cycle around February, 10 (we'll get new batch of uECGs by March - we plan to make 100 of them). We also hope everything will be okay for the Chinese people because of the virus :( 

    - Last, but not least - we miss actual device development and other projects! Who would've thunk this would take all of our time and more. We really want to return to making stuff in the relatively free time we get while waiting for the next batch production.

  • We sent uECGs to backers! (and some other January news)

    Kseniia02/02/2020 at 19:34 0 comments

    We've not written anything for a whole month! But we have been far from idle.

    First of all, we just sent all of the uECGs to Indiegogo backers (finally!). That brought closure to a large period in our lives and we're really happy that we did it. 

    A LOT of crowdfunding campaigns do not deliver to backers at all, and we were determined that we don't only deliver, but do it on time. That didn't go exactly as planned (if you've been following us, you know that the Indiegogo platform didn't release funds for two months after the campaign was finished). Still, we were determined to ship them as fast as possible without compromising the quality and really tried to do our best on every step.

    This is some of the packages shipping on Ukrposhta:

    In the following weeks, we - among usual news - will write separately about the packaging and PCB production, cause there's a lot of details that won't fit in a usual log!


    Second, we were actually going to send the devices to backers at the start of January, but we've, ugh, been writing a grant application for two weeks straight - from around January, 8 to 23rd. 

    Basically, we ran out of money (AGAIN), and as a team we're in one of those situations when freelance projects are kinda hard to start, because there's not much time anymore, and sales of our own devices aren't profitable yet. So around New Year, we stumbled upon a brand new state-sponsored grant program for small tech companies, and it didn't look so bad. In fact, it looked very inspiring and was led by a team of professionals. The grants were seed money only - $25K-$50K instead of throwing around thousands and millions - and you had to show lots of numbers and write a good application for that, so that's how we knew they meant business. In Ukraine, we have a lot of historical baggage and Soviet legacy infrastructure. Now, after long years of stagnation we have a new government which is much more efficient, but before that, the market here was very limited for professionals. For most people, it was mostly freelance/outsource programming, and not many people started tech businesses. So if you wanted a startup, or if you were a small tech company, you had to pitch at one of the startup challenges or hackathons with investors and the startups were all the same - lots of digital and blockchains and big data. Tangible stuff wasn't pitched or valued, and we considered participating and changing it, but we knew it could cost us a lot of hope in humanity and we probably wouldn't go for it anyway: it was all very cheesy, the mentors and investors weren't usually very professional, sometimes rude, and a lot of strings was attached, so we never did any of that. Long story short, for some years, there was generally an atmosphere of despair on the startup scene here, and it was even worse when you're in hardware development. There's almost no manufacturing in Ukraine. Even the hardware community itself is almost non-existent. We aim to change that and have lots of plans, so we ourselves never despaired  - but that's the current state of affairs.

    Basically, we decided to try and write a good grant application. This took two weeks and we were so exhausted doing it - though we learned a lot in the process and liked the result. Lots of things we just didn't know. We didn't have proper CVs, even, or didn't know how to write about market research and products and how to count financial stuff.

    But in the end, we even managed to do a 5-year financial projection that didn't look too crazy. Well, at least to us. Maybe the professionals will have a laugh reading it, but we really tried. After we were done with the application, we had a couple days of rest and returned to packing and preparing the uECGs for shipping. 

    On January, 28 we finally sent them and now it's time to direct our attention to the future of uECGs that are left, because we promised they'll be in stock. But this was a long one, so we'll write about...

    Read more »

View all 31 project logs

  • 1

    Welcome, everyone!

    This is an instruction on how to use uECG kits that we sell, but it’s also useful if you want to make your own uECG. Or maybe you were just browsing Hackaday and accidentally found our projects. In any case, thank you for being interested in uECG! 

    For clarity, we also made this video to show everything described in the instruction:

    We tried to make the package as simple and environmentally friendly as possible! It doesn’t contain plastic packaging, but is still antistatic and protects well. 

    The devices (uECG, base and programmer) are stored in separate cardboard cutouts; the electrodes, wires and pins are in the smaller box.

    The most popular (Developer’s) uECG kit includes the following:

    • uECG device;
    • 3D-printed case;
    • 10 single-use electrodes;
    • base station for connecting to laptop/PC (a simple nRF52832 USB board designed by us);
    • USB programmer for firmware upload (ST-Link v2, we use a tested Chinese clone);
    • pogo pin adapter (4 pogo pins/2.54 spacing).
  • 2
    Power on
    1. To turn uECG on, use the slider on the side of the device;
    2. After switching it, you should see a series of blinks on the left side - first red, green, blue; then three green flashes; then pink. The pink LED means the device is on and ready to use;
    3. The pink LED should periodically flash when device receives signal - i.e. in contact with the skin.
  • 3
    1. Attach round gel electrodes to the snap connectors on the bottom of uECG;
    2. Peel off the protective layer from them and stick them to the chest as shown in picture below;
    3. Gently press the device onto the skin once to ensure it sticks;
    4. After use, peel off the device and detach the electrodes (they are single-use);
    5. It’s good to minimize the amount of hair and wipe the skin with alcohol for better signal. It will also be easier to remove, too :)

    Please turn off uECG after use! The sleep mode may be glitchy, so the battery may discharge too much.

View all 10 instructions

Enjoy this project?



Ahmed Alsalihey wrote 10/05/2020 at 20:42 point

Thanks for this wonderful effort .. I hope to receive a piece for me, how can I get it .. Thank you again

  Are you sure? yes | no

Lucy Sohryu wrote 10/08/2020 at 20:32 point

Hi Ahmed! We actually saw your email first, and answered there, and only now saw your comment - sorry about that! Anyway, you can get uECG from our Tindie store: - we also sent this link in our email, plus some info on shipping options.

Thanks for getting in touch, and hope you're staying safe!

  Are you sure? yes | no

madmedix wrote 09/03/2020 at 02:44 point

Got mine yesterday! Woohoo!

...and then the app crashes. Repeatedly. So often the One UI wants to put it into deep sleep. Android 10 (Kernel 4.14.113-18615768) will only run the app once, from a cold boot. Even then if I pause or stop recording -> app crashes....Not sure if the reporting it wants to do pipes back to Google or you...


Edit: It's a Samsung A51

  Are you sure? yes | no

the_3d6 wrote 09/04/2020 at 13:34 point

We are rewriting the app right now :) Android 10 handles things quite differently, although we had even current version working there (it won't survive turning the screen off, so not very useful, but still it works until then).

If it doesn't work at all - then please manually give location permission to the app, that is most likely the reason - it should have asked for it, but that doesn't work

  Are you sure? yes | no

madmedix wrote 09/04/2020 at 18:09 point

G'day! I did go through and make sure it has all permissions (storage & location). The storage works b/c the /Documents folder is full of .csv files from when it works from the cold boot. I agree A10 handles things very differently - for me it's really different stepping up from a phone running pie. Also - an old moto e2 running A6 does the very same thing. Cheers!

  Are you sure? yes | no

the_3d6 wrote 09/05/2020 at 09:34 point

Updated app is in the play store - please check (it might show an old version though, try to reload play app if you don't see a new one)

  Are you sure? yes | no

madmedix wrote 09/09/2020 at 01:49 point

Sorry for the delay - Updated the app tonight (here, anyway) and works great so far. (edit) too fast. The UI mgr complained after about 12 minutes that the app keeps stopping [Process Name: com.ultimaterobotics.uecgmonitor4_2]

Crash log:

Exception class name:


Source file:

Source class: android.view.Surface

Source method: checkNotReleasedLocked

Line Number: 662

I have captured the stack trace and send it to you via e-mail.


  Are you sure? yes | no

the_3d6 wrote 09/09/2020 at 08:55 point

Thanks for the report! There was really a reckless behavior in my code - I was drawing on the surface not checking if it's already created (which happens all the time when you switch tasks) - so if OS wasn't fast enough to create it before I first access it, the app crashed. Now fixed - should be live in play store sometime during next 3-12 hours (reload play app if it's been quite a while and it still doesn't show updated version)

  Are you sure? yes | no

bits wrote 06/07/2020 at 09:16 point

Hi, I'm getting stuck with flashing the firmware. After many attempts I finally managed to get openocd to connect (I think in the beginning I was too careful with the pogo pins), but I get stuck on the second telnet command. When I try to execute "nrf5 mass_erase" it complains that "nrf5" is an invalid command name. Just in case it is of any use, I'm using Ubuntu 18.04 with openocd from the package manager and below is the terminal output for both commands:

$ openocd -f interface/stlink-v2.cfg -f target/nrf52.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.155039
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection on tcp/4444
target halted due to debug-request, current mode: Handler External Interrupt(6)
xPSR: 0x01000016 pc: 0x000074f6 msp: 0x2000fe80
invalid command name "nrf5"

$ telnet 4444
Connected to
Escape character is '^]'.
Open On-Chip Debugger
> halt
target halted due to debug-request, current mode: Handler External Interrupt(6)
xPSR: 0x01000016 pc: 0x000074f6 msp: 0x2000fe80
> nrf5 mass_erase
invalid command name "nrf5"

  Are you sure? yes | no

Ultimate Robotics wrote 06/07/2020 at 10:06 point

It could be a bit different version of openocd, and instead of nrf5 you should use nrf52 command prefix.
Also it probably would work even without mass_erase command at all (flash write command overwrites content) but it's safer after mass_erase

  Are you sure? yes | no

Elias Ylänen wrote 03/26/2020 at 10:52 point

I'm having an issue with the firmware update; the update process itself seemed to go through without issues, but after resetting and disconnecting the device, it doesn't seem to turn on anymore. Anything I could do to reverse this?

  Are you sure? yes | no

the_3d6 wrote 04/24/2020 at 18:50 point

Sorry, missed your comment! If you have uploaded the correct file and it went well, it should work - but it could be that process wasn't actually finished. Have you tried to repeat it?

  Are you sure? yes | no

pefs wrote 02/14/2020 at 23:16 point

The incorporation of stlink support as described in your response to the questions below seems to have worked.

But returning to the instructions for updating the firmware, things move only a half step ahead. In response to openocd -f interface/stlink.cfg -f target/nrf52.cfg

I get:

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.176608
Error: init mode failed (unable to connect to the target)

  Are you sure? yes | no

the_3d6 wrote 02/15/2020 at 20:29 point

If all wires are connected the right way - then it's a problem of contact. Try moving pogo pins a bit and run openocd command repeatedly (pressing "up" key repeats last console command so you don't need to type it again) - it's perfectly normal to get connection only after 10+ attempts, especially before you'll find the right way to position them. But if within 20 tries you still can't connect - check wires (and quality of their contact)

  Are you sure? yes | no

pefs wrote 02/17/2020 at 08:36 point

lots of tries later...

A few observations,

the USB controller has two rows of connections, attaching to the upper (nearer the printed side) I consistently received the above error message,

Moving all the jumpers to the lower row,  it did not error and started listening on port 3333 first try. Also, the led on the programmer went from solid red to alternating red and blue

I suggest moving the instruction to open a new terminal to its own line and putting it in bold text (I missed it a couple of passes...)

It might be fine to simply detach the connection and close the terminals, but maybe indicate "exit" on the telnet session and ctrl+C (?) for the openocd session to close out nicely.

for me - working connection to android phone and decent trace displayed

  Are you sure? yes | no

the_3d6 wrote 02/17/2020 at 09:06 point

Interesting! I never realized there is a difference in programmer rows - but somehow always connected them to the lower one, just randomly did it the first time and always followed the same pattern. Maybe there actually is.

Ok, will make new terminal part more visible ))

Exit on telnet isn't really needed (it auto closes with openocd), although ctrl+c in openocd probably is worth mentioning.

Glad it worked! :)

  Are you sure? yes | no

pefs wrote 02/13/2020 at 22:05 point

I'm one of the unlucky ones with an android phone that doesn't see the uecg, nor does BLE scanner.

It seems installation of openocd went fine (on linux), but the command:

openocd -f interface/stlink.cfg -f target/nrf52.cfg
gives me an error that interface/stlink.cfg isn't found.

Where should I get it from and where does it need to go?

Is there something else that needs to be with it?

while I'm here...

Does the white nub / button of plastic sticking out of the back do something?

I would suggest moving the second photo before instruction 1  in the firmware update, and redoing the photos in instruction 3 to show both the programmer end and the uecg end more clearly, and  using a uecg with a white case so the holes are visible. Switching the orientation so green is near the snap connector in one and away in the other is a bit confusing since the other end is connected to the same pin on the programmer.

Instructions for use with the usb basestation?

  Are you sure? yes | no

the_3d6 wrote 02/13/2020 at 23:04 point

It seems that your openocd build doesn't have ST-link support :( It was the case for most Linux distributions a couple of years ago, now some has it, some still don't. I'm afraid you'll have to compile it from source code in order to make it work. For that, download openocd version 0.10.0 or higher (master branch should work too, here: ), then inside it run
./configure --enable-stlink
sudo make install

 - that should make it work.

As for the base station, PC program is still in progress but it is kinda usable already. You can download it here: - then just run make and then you can launch it with
sudo Release/ecg_monitor (sudo might be required for USB access - depends on system config, but by default it typically is needed). App can switch between BLE and direct link modes (should be more or less clear from the interface). Detailed description will be ready a bit later - right now we are trying to compile it for Windows.

White button switches uECG between BLE and direct link mode (and long press switches it into EMG mode, in the PC app you can see the result, but it's far from ready).

Thanks for the feedback on the instruction - will try to make it more clear! Yes, those two photos contradict each other, the best reference is schematic image at the beginning of part 7.

  Are you sure? yes | no

pefs wrote 02/14/2020 at 22:18 point

for any other git novices - better to use:

git clone openocd-code

instead of downloading a snapshot (using the convenient button) at:

as the latter leaves you having to track down a number of uncooperative modules and libraries.

  Are you sure? yes | no

pefs wrote 02/14/2020 at 22:53 point

I see you've eliminated one of the confusing photos,

But now the text for the Firmware update is in Russian, which dare I say is even more of an obstacle.

  Are you sure? yes | no

the_3d6 wrote 02/15/2020 at 10:32 point

Sorry about that! Apparently one of our team members had auto translate turned on while editing the post. The good news is, we added some improvements while writing it back (didn't have a backup copy) :)

  Are you sure? yes | no

pefs wrote 02/17/2020 at 08:35 point

for the base-station on Ubuntu18.0.4 I needed sudo to make the connection work

then open connection and tick the BLE box to get the trace up.

  Are you sure? yes | no

the_3d6 wrote 02/17/2020 at 09:09 point

Yes, sudo is required... BLE box is needed for bluetooth mode - without it, it will receive data via direct protocol (for switching uECG into direct protocol mode, press button on it once for a short time. Second press switches it back into BLE)

  Are you sure? yes | no

quadradic wrote 01/16/2020 at 15:58 point

I haven't found anything on your site showing or explaining where to attach the electrodes to the human body.  Do the electrodes need to attach to the chest to get a reliable signal while exercising?  Is the device ready to use when I receive it?  Do I have to install firmware on the ECG sensor part before I can use it?  Does the device come with the battery and electrode pads.  Do I order replacement pads and batteries from you?  Can I read the received heart rate data from a laptop's USB port and use the data in my own custom program in real-time?  How do I read your data, what format is it in?  Is it just a stream of bytes representing a series of consecutive heart rate readings?  How often are the readings taken and transmitted?

  Are you sure? yes | no

the_3d6 wrote 01/16/2020 at 22:15 point

Sorry about that - really didn't have time yet to write anything comprehensive, even though first batch is ready, we couldn't stop improving it firmware-wise, only 2 weeks ago we became satisfied with its state (not fully yet, but it's something we are not ashamed to share now).

It is optimized for standard gel electrodes (10 pcs are supplied with the unit, and almost any readily available ones would fit - we plan to sell them too for convenience, after we establish regular serial production of the units). Also it is possible to use chest strap, but as of now you would need to manually solder adapter connector (we will supply them later too). Electrodes must be on the chest, yes - placing them in different areas would highlight different aspects of the heart activity, and some places work well during exercising, some don't (skin shouldn't move too much in electrode area, or it won't hold well).

Device is ready to use, right now you will get raw data, BPM, HRV stats, skin conductivity (also step count and body position). It is quite useful if you know how to look at it, and of limited use if you don't. We definitely will add a server side for automatic analysis - but that would take months.

Firmware is installed - we supply programmer for further updates and custom builds, but it is fully functional as is (over the air update is not supported yet though). Battery (rechargeable LiPo) is installed, and charging is done via usb. You can replace it with any other lipo cell if you want more capacity (would need to solder 2 wires for that, for much larger capacity - also replace one resistor to speed up charging).

Default pack includes USB base station that receives device data in both BLE and direct connect modes (direct connect has 8 times higher time resolution - might be useful for research). Data includes raw ECG signal, RR interval, BPM and HRV detected by on-board algorithm, skin conductivity, steps counter, device orientation, battery level. Everything is packed as a byte array (and not all fields are present in every packet in order to save bandwidth) - you can take function that unpacks it from our PC tool code and use for your project (if you will be doing that anytime soon - contact me, I'll try to clean it up and write comments).

In BLE mode, ECG data are sent at 122 Hz rate (packet with ~25 meaningful bytes is sent every ~10 milliseconds, so there is a lot of redundancy - in order to increase reliability). In direct connection mode, ECG data are sent at 976 Hz rate (32-byte packet is sent every few milliseconds, so still a lot of redundancy).

We made quite a few improvements since last github code update, soon will upload it there - but right now our main problem is finding money to run a production of the next batch. First batch was only 50 units and most of them are for Indiegogo bakers, in a few days we'll make remaining ones available on Tindie (wanted to make it before Christmas, unfortunately it took much longer than we could anticipate), but it's by far not enough to cover our waitlist.

  Are you sure? yes | no

quadradic wrote 01/17/2020 at 01:01 point

Thanks for answering all my questions and providing such clear and comprehensive answers.   I want to buy a unit as soon as possible, so I signed up to be notified when they become available to the public.  Will the price remain under a hundred U.S. dollars for the full package?    I've bought so many ECG units that aren't accurate at all, especially when jogging or exercising.  I have high hopes that your device will work better based on the information you've provided.    If it really works, then I'll incorporate it into my product.   I may need some custom software to interface and integrate your data with my software, which is currently running on a laptop.   I can hire people to do that, but I'd prefer to hire your team to do it if that's  something you have the manpower to handle?    By the way, I read somewhere that your company is located in the Ukraine, but your English is better than most Americans.

  Are you sure? yes | no

the_3d6 wrote 01/17/2020 at 11:26 point

We intend to keep price the same - in the worst case, if we'll meet more problems with money processing, it might increase like 10% to compensate additional fees, but that's it (it turned out that paypal not only doesn't work with Ukraine as a country, but with Ukrainians as well even if they have a legal entity in Estonia and bank in Finland - finding a way around may cost us).

Well, as far as we tested - the signal is accurate. When jogging, it has motion artifacts of course, quality depends a lot on exact placement and electrodes (that's where difference between electrode manufacturers really shows - with some it practically doesn't work) - but I was observing very clearly how my T wave changed shape under load. P wave might be not clear enough for analysis due to motion.

As for customization - definitely yes. Basically, we funded this whole effort by working as freelancers for other electronics project :) And for a while we'll need to continue to operate this way. Also, one of the reasons to create uECG at all was to make it a starting point for other projects - so we'd really like to see it working for that purpose.

Thanks :) Well, we really are from Ukraine (and live here), but by our team standards, my English is, to say the least, not outstanding )) As freelancers, we use it basically every day, for quite a few years now.

  Are you sure? yes | no

quadradic wrote 01/17/2020 at 14:28 point

My VISA credit card works world wide, why can't you use that for payment?   And, you can always accept payment by Bitcoin.  

  Are you sure? yes | no

the_3d6 wrote 01/17/2020 at 19:43 point

When we sell on Tindie, they transfer payments to us only via paypal (we specifically asked for any other option - they don't support it as of now). Setting up our own online shop is possible and probably we'll do it - but Tindie is a specialized platform for maker-friendly hardware, we'd like to work with them...

  Are you sure? yes | no

quadradic wrote 01/17/2020 at 20:48 point

Now I understand, it's a PayPal issue between you and Tindie, because there's no other way for the public to purchase from you.  Hopefully, if I use your team for consulting work in the future (to integrate your device with my project), then I can pay you directly and the Tindie/PayPal problem won't make any difference.   

  Are you sure? yes | no

Thomas Rose wrote 01/08/2020 at 23:55 point

Very interesting project! Do you guys think this could be miniaturized even more and set up to measure a cats ECG continually?

There are so many people having cats with HCM or other cardio-illnesses that would love to have an option for continuous monitoring.

  Are you sure? yes | no

deʃhipu wrote 01/09/2020 at 22:17 point

How would you attach it to a cat?

  Are you sure? yes | no

Thomas Rose wrote 01/09/2020 at 23:01 point

thinking about anything possible like a collor, to something like a harness or something, maybe put this on a collar, and connect to an HRV-Strap? :)

  Are you sure? yes | no

the_3d6 wrote 01/16/2020 at 21:34 point

It's a very interesting suggestion! Really not many options are available for pets - and, well, for uECG the only limiting factor is attaching it (size can be made 2 times smaller if we remove these large electrode connectors). I guess some areas of fur should be shaved for this, without it I don't think it could be reliable. Collar could work to some degree - but signal on the neck area might be not detailed enough for diagnostics purpose. Anyway, it is a great idea to consider, thanks :)

  Are you sure? yes | no

Thomas Rose wrote 01/16/2020 at 23:00 point

happy to help! its not not very un-egoistical, as we have a cat with HCM which I would love to contiouous monitor, but there is not even one product availabe for this. even a device would help with streaming data to a database - even DIY style would be pretty great to learn more about the heart of the pet. shaving wouldnt be a problem either. I even thought about something like implanted electrodes, but this might be way too invasive 0:D

  Are you sure? yes | no

Pranav Kompally wrote 01/07/2020 at 06:21 point

That's quite impressive! Can we attach this device onto the wrist and get optimum results instead of putting it on chest? 

  Are you sure? yes | no

the_3d6 wrote 01/20/2020 at 21:19 point

No, it's impossible to read ECG from the wrist (if you are not touching the device with other hand all the time). Normally wrist devices measure PPG - it's very different and has much less diagnostic value

  Are you sure? yes | no


[this comment has been deleted]

the_3d6 wrote 12/20/2019 at 20:32 point

Hi! Both electrical path from USB to skin have 100k resistors on them, so even in the worst case scenario it still would be safe. But for proper operation, uECG never should be connected to USB while in use - only when disconnected from skin for recharging

  Are you sure? yes | no

razorfish_sl wrote 10/22/2019 at 01:22 point

 this setup may have potential dangers due to the way that the device is not isolated electrically from the USB port.

There is potential for defective switched power supplies(or indeed "normal" switched PSU) to introduce mains power into the PCB & to the  human body under test.

simple test.. take a mac portable in aluminum
plug the mac computer into the charging power supply.

ISOLATE your body completely.
run a DRY finder across the surface of the case in strokes. feel how smooth it feels.
now with your other hand ground your body
if you repeat the experiment you should feel you finger stuttering across the surface of the case.
This is mains leakage thru the psu into the "Grounded" computer case(and by default the USB).

It's also WHY some USB cable "spark"  when the "grounded" case to case is touched to another device
I have seen voltages as high as 197V with reference to "real" ground

There are VERY strict rules relating to medical equipment and this leakage.

  Are you sure? yes | no

the_3d6 wrote 10/23/2019 at 17:45 point

You are absolutely right about potential danger. However in version 4 (which is going in production) we anticipated this (with help of Marcos Chaparro actually), and electrodes are connected to everything else via 100k resistors - so in the worst possible case current flowing through the body won't exceed 4.4 mA, which is considered safe (unpleasant feeling, but no shock).

In practice though device should never be charged via USB when it's on the body (it introduces huge electrical noise), so it's more of a safety measure.

  Are you sure? yes | no

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