Close
0%
0%

uECG - a very small wearable wireless 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
$79.00
ultimaterobotics has 151 orders / 2reviews
Ships from Ukraine
uECG is small wearable wireless ECG device that attempts to bridge the gap between modules for prototyping and medical devices. It can be used both as a development platform and a standalone ECG.
It’s low power, very lightweight, can be worn during physical activities. It streams processed ECG signal in real time and also collects raw data. The ECG signal is rather good, not very noisy, and the recent PCB version has a ipex connector for an external sticker antenna, which makes the connection more stable. We wrote an Android app and a node.js (cross-platform) app for it, so the data can be received on the phone or PC. The battery we currently use is enough to stream for 24 hours. We also made a nice 3D-printed case for it.

We made the first prototype of uECG at the end of 2018, after working on several biosignals projects (both commercial and in-house) and becoming annoyed that there was no simple, open source wearable ECG that you can, well, just wear and measure ECG with. We really liked HeartyPatch, but it was a bit large and didn’t have low power mode. We were going in the same direction, but wanted a simpler and smaller device. Since then, we made several versions (it’s currently v4.5) and a lot has happened. We went to several Maker Faires with uECG, launched a small Indiegogo campaign, which was successful, and after shipping the devices to backers we produced another two batches which we sold on Tindie. In June 2021, we produced the most recent PCB v4.5 batch, with most improvements being around the antenna and powering the device. 

The following is both a description of our approach to device’s schematics/PCB design and a changelog for the latest version. As a main analog front-end, in our schematics we used a generic MCP3911 (dual channel), because we didn’t like the specialized overpriced AFEs. It’s originally developed for energy metering, but it performs nicely in our case too. We also added AD8606 in the role of a buffer precision op amp. For the microcontroller, we chose nRF52832, which is low power, has a lot of processing power and memory, and provides us with a stable Bluetooth/RF connection. We also added BMI160 as an accelerometer/gyroscope IMU. For power in the first PCB versions, we used a simple and reliable LDO - MCP1703. Now we use XC6206, because it has better parameters, better in-built protection, and is cheaper. We use MCP73831T as a charging management chip. We also used SIP32810 for protection and power switching, and a 550mA resettable fuse for short circuit/overload protection.

In first versions we had an optocoupler for connecting stuff to uECG (like LEDs), now we have removed it because it’s not used very often by anyone and we have freed more space on PCB for moving components around. Might add it again… not sure about it yet.

One of the hardest parts was actually to find snap ECG connectors that we could solder on board, but after some time we managed to crack the needed Chinese symbols for them on taobao (where we buy a lot). Here’s the symbols for “ECG snap connectors”, in case somebody needs it: 心电扣 We also tested several battery sizes before stopping at 501245 size, which was both sleek enough to occupy space between the micro USB/switch and thick enough to provide the capacity we needed. 

The firmware performs measuring of raw ECG, filters out mains noise using our own algorithm (50/60 Hz, auto-detecting which band is active), detects R peaks (and calculates from them BPM, heart rate variability statistics), measures skin resistance and receives accelerometer, gyro, steps data from IMU chip. Also firmware takes care of detecting R peaks amplitude and sends out correct peak value via BLE connection (in the previous version R peak amplitude could be distorted by averaging since the peak normally fits within 1-2 BLE data points - that’s fixed now). The resulting ECG quality of this setup is quite high with clearly distinguishable P, QRS, T phases when the unit is properly placed - and even during running a lot of details still can be seen (although distorted by body motions).

For more detailed signal, direct RF connection to PC via base station can be used - in this case, data rate is 976 Hz (vs 122 Hz in BLE mode).

uECG_v4_5_KiCAD.zip

KiCAD files for v4_5. This is the latest version for now.

x-zip-compressed - 144.93 kB - 08/16/2021 at 13:06

Download

uECG_v4_5_BOM.xls

uECG BOM for v4.5, produced in June 2021. It has no components links because we supplied our own parts, but the P/Ns we used are all accurate and decent quality

ms-excel - 44.50 kB - 08/16/2021 at 12:58

Download

uECG_v4_5_gerbers.zip

Latest version of uECG gerbers - v4.5, produced in June 2021

x-zip-compressed - 91.36 kB - 08/16/2021 at 12:58

Download

uECG_v4_5-top.pos

Centroid (pos) file for factory/PNP machine assembly. Only top layer needed, cause there's nothing to pick and place on the bottom.

pos - 6.72 kB - 08/16/2021 at 13:06

Download

uECG_v4_5_LED_polarity.jpg

We like to send factory a picture of the board (or a photo, if there are more nuances) where we mark LED polarity more clearly or some other helpful things, mostly regarding component orientation.

JPEG Image - 377.09 kB - 08/16/2021 at 13:06

Preview
Download

View all 11 files

  • 1 × nRF52832 (on PCB) popular Bluetooth SoC
  • 1 × MCP3911 (on PCB) Generic ADC
  • 1 × AD8606 (onPCB) Precision operational amplifier
  • 1 × BMI160 (on PCB) IMU (accelerometer/gyroscope)
  • 1 × RGB led (on PCB) For blinking in all colors of rainbow!

View all 11 components

  • Launch of sales of the second device - uMyo!

    Ultimate Robotics2 days ago 0 comments

    Hi all! For a long time, uECG was the first and only device available for sale on Tindie. But this fall, everything has changed! We launched the second device - uMyo!

    uMyo is a single-channel EMG device that uses two attachment methods (dry and wet electrodes), but also:

    • It's wireless! No more mess of wires when working with EMG
    • Works with any Arduino via nRF24 radio module (we wrote an Arduino library for that)
    • Works with ESP32 with no additional hardware (we wrote an Arduino library for that as well)
    • Multiple units (up to 12 in current version) can send data to the same Arduino/ESP32
    • Sends out detected muscle activity level, 4-bins spectrum and in nRF24 mode - also raw EMG data

    Although uMyo is already on sale, but you can read the history of its creation on the project page, but this is not the end! We plan to come up with and post mini projects from different areas where you can use your muscles (spoiler: their purpose can be very unexpected), the whole process and code will be available for reproduction and inspiration. Subscribe!

  • Orbitrack computer on ESP32 using uECG for heart monitoring

    Ultimate Robotics06/26/2022 at 19:29 0 comments

    At the end of 2021 we got an orbitrack - and immediately wasn't happy about its in-built computer: not only it has poor visibility and no colors - but also its heart rate monitor works only when you keep hands on the bike's handlebar, it has no contacts on vertical moving parts.

    So we replaced it (in fact, did that a couple of weeks before the war hit, so shooting a video took just a bit longer than we anticipated)

    We took advantage of uECG project we are working on - so heart rate measurement is handled by the device, and ESP32 only receives its data via BLE. The project code is rather modular so a different heart rate sensor can be connected there instead (although characteristics UUID and parsing function should be changed for that, as well as advertiser filter), or it can be used without heart rate sensor at all - but then it won't be as useful.

    The main value of that project is that it shows current heart zone as a color (area between resting heart rate and maximum heart rate is divided into areas and zone defines your training mode), so you can run at optimal load for your goal.

    Connection to orbitrack's speed sensor is very simple: sensor is just a switch that is open/closed at different parts of the revolution, from the amount of state changes you can estimate revolution time - and that can be translated into speed in several ways (I'm translating it to bike speed, it can be translated into running speed as well - but orbitrack's load is more similar to cycling than to running, even though not equal to either of those).

    Calories measurement is rather arbitrary - I found some formulas for calculating orbitrack calories rate online and just hope they are reasonably fitting, no idea how true they actually are.

    code link https://github.com/ultimaterobotics/orbitrack_esp32

  • uECG sales reopening (and a few details)

    Ultimate Robotics06/15/2022 at 16:22 0 comments

    Last week, we reopened uECG sales. 

    We’ve been preparing for it for some time before we learned the news on 7th of June. That day was an unexpected blow for us and for some time, we didn’t know when (or how) we would recover. However, it also made us realize that not only is the war no reason to be slower than usual, but that we can’t afford to be slow anymore.

    For this uECG batch, we have, as usual, prepared a huge firmware update - fixed IMU bugs, improved R detection and EMG mode, rewrote the bootloader and added multi-device functionality. We’ll be writing a separate log about the firmware update with more details about the fixes and new features. Of course, the buyers who have previous uECG batches (except for the Indiegogo one - we didn’t check compatibility yet) can update the bootloader/firmware too and enjoy the updates. 

    We also designed and printed new packaging for the devices - a huge step ahead for us, and we will write about them too! - and made some overall quality improvements. Hope the buyers will like them! 

    We’ll be writing about other stuff that’s happened in the meantime, both here on Hackaday and on our social networks - so stay tuned for new updates.

    uECG is available in our shop on Tindie.

  • A tribute to our friend, veteran and fellow maker, Denys Antipov

    Ultimate Robotics06/07/2022 at 20:37 1 comment

    Today, we learned that our friend, Denys Antipov, died at the frontlines from artillery fire on 11th of May. It was near Izum in Kharkiv oblast. We are heartbroken and refuse to believe it. 

    Denys in his video from May 7, talking about the frontline village his unit was stationed in

    To say that he was a good man is an understatement. He was amazing. We met him back in 2014, when he started a large project, a robotic arm prosthesis, when the war first broke out - and joined without a second thought. This is largely how our team formed. The project goal was initially to help veterans who lost arms and hands in battle, and also anybody else. Our uEMG project is a part of it. 

    Denys (center) talking about the robotic arm project in an interview
    An actual post Denys made in the project Facebook group in 2015, perfectly summing everyone's attitudes towards certain russians
    Denys (right) and our team* posing for a photo for an article about the robotic arm project, in 2016

    *Our members have since partially changed: Arsen - second from the left - has left, and two more people have joined, Olha and Lucy

    He started the project just before he himself went to war for the first time, and came back in 2016. Later, he rented and furnished a small workshop with CNC machines and 3D printers. There, he cut wood, leather and other materials with lasers and made things like beautiful wooden puzzles, figurines, gifts, and engravings on objects like wooden boxes and knives. His recent passion was making musical boxes which played folk Ukrainian songs. He even started a Youtube channel and opened an Ebay shop to promote Ukrainian culture to people from different countries. He also 3D printed and sold supplies for 3D printers, and once collected 100 different 3D filament spools which he arranged by colors on a huge wall-sized stand, which made him very amused and proud. Later he bought a huge inkjet printer to expand a bit. The workshop grew quite a lot since 2016, and there were several people working there before the 2022 war broke out. He also created another large project - an online platform where other army veteran makers could have their businesses and sell stuff and promote it. It's called ua.gifts. It is big and has united a lot of people, but it started in that same small workshop.

    The aforementioned 100 filament spools in all of their glory
    Very happy Denys with his very huge inkjet printer
    One of the music boxes Denys started making recently
    All these cardboard cutouts with which we shipped first two uECG batches were laser cut by Denys, in his workshop. You might have gotten those!

    Denys was (it's so hard to write this word!) a bright light, full of energy in everything that he did. He could do anything, and often all at once, and crack jokes in the process. Formally he was a soldier and a Korean translator and university professor. But really he was so much more, and there was something about him that would make you believe you could do anything. He often gave interviews and told news from all over the world about the projects, and lately about war. On 9th of March, he got injured and was in the hospital. Back then, we were worried but really glad he was alive and for some reason we believed nothing else could happen to him, because he was already injured once - and lightning (or shell) doesn't strike twice, does it…

    And we also planned to do so much together. It's hard to understand what to do further. We don't know how to deal with this loss. We just want him to be back so much, to win the war, and then to see him again and continue our projects!

    We’re proud to have known you. We will never forget you. You will always be our friend, and a hero! Glory to the heroes!

    P.S. And here's how the musical box that Denys made sounds... It's playing Chervona Ruta, a popular Ukrainian song written in the 1970s and still catchy today. When people get drunk, they often sing it (which is how we know).
    And this...

    Read more »

  • War update #2 (volunteering and living from day to day)

    Ultimate Robotics03/17/2022 at 13:24 0 comments

    Yesterday we learned that Tindie platform, on which, as you know, we sell uECG, wrote a post about the war in Ukraine and in particular about the experience of our team. They also wrote to us in a separate letter about the reaction of the company itself and the community - that Siemens has had started a €1 million matching donations round for our country, limited sales and shipments for stores from russia and belarus, and that makers from these countries do not support the actions of their governments. It was sudden and very supportive of them! We love Tindie as a platform/community and it's great to have them on our side.  

    But we also realized that we haven't made updates for a long time... I would like to share some events that happened after our previous post. Our intentions to go to Kyiv suddenly became technically impossible - public transport stopped running in full, which made it impossible to leave the railway station. Therefore, we stayed in Lviv to wait until the situation with transport improves.  

    We did not sit idly by. First of all, we took care of ourselves and each other - building up the household infrastructure (buying food, household goods, kitchen appliances, pillows, blankets, slippers, etc.). These actions gave us the opportunity to at least eat hot food, and to recover as much as possible. At the same time, we plunged into volunteer work. Almost every day, together or separately, we bought various kinds of things and handed them over to volunteers, who distributed them further according to their intended purpose. Most of these things were medicines that were needed right now and on the same day they were sent to Kyiv, Kharkiv and other cities. Volunteers distributed lists of what medicine was needed, but they were often long, so we further narrowed them by making a list including the ones that are spent faster and always needed, and some rare ones that are hard to find, and targeted those specifically.

    We also kept an eye out for requests for hard to get or specialized things. A couple days we hunted for pillows and blankets for refugees, as the city suddenly ran out of them, and were able to supply a dozen or so. Then we turned to equipment requests, and were able to get 2 chainsaws to transfer to a military unit (the one that, to our horror, got bombed later near Lviv…) and also 3 oximeters, a blood pressure monitor and a glucometer to a group of wounded military. One day we also randomly got a couple kg of tofu for a vegan cafe which provides food to refugees for free, had to get it from farmers outside Lviv as there was no tofu here… Focus was never our strongest suit. For now, we ran out of money for a little bit, but we’ll continue as soon as we can. Below is a small photo report.  

    Going back to our plans: just recently, we actually still managed to go back to Kyiv for a day and pick up some of the things and components for projects. Now the whole team continues to stay in Lviv and we are trying to understand our next steps. We miss Kyiv a lot and we do not know for how long we will stay in Lviv, but we do not want to go back empty-handed. So we are thinking about something, but it’s not clear for now if we will be able to pull it off.

    We are also trying to shift some of the attention to work, but we have much less resources and focus than before. Although we must say that so far doing even a little work has been grounding.

    It's hard to talk about plans when we don't know how today will go and what events will take place in Ukraine. We’re trying to live one day at a time, as a lot of people here now do - although we try to plan for 2-3 days (or more!) now too. Therefore, we will try to post updates in retrospect whenever possible.

    We also wanted to thank all our customers/buyers who expressed concern and supported us both in words and in deeds! Thank you very much! 

    And for everyone who wants to support Ukraine, we share again the details for...

    Read more »

  • War in Ukraine (that's where we are) update

    Ultimate Robotics02/28/2022 at 13:19 4 comments

    Hi everyone! 

    When the war started on February 24, we woke up at night in Kyiv from explosions. Our first instinct was: what about our tech? We need to make sure nothing happens to it. And we need to prepare so that we can continue our work in another place. Who knows how long it will take? It could take months. We were used to the 8-year slowly simmering war. But actually, it was hard to even think. We couldn’t sleep because of the sounds of air defense and rockets, there were jets and helicopters flying not far from our windows and air strike warnings several times a day.

    Eventually it was hard to make any decisions because we were too sleep deprived and confused. So we packed our projects - a new batch of uECGs, uEMG in various debug stages, other projects. A maker’s survival kit: stuff for soldering, a tester, alcohol, most used passive components, some active ones, some rare ones, some nRF52832s, some EPS32… Lipo cells, connectors, modules. It was surreal to cut the strips from the spools of passives and label them as there was shooting in the streets in our area. We had to avoid windows as per instructions, cause they were shooting at them sometimes. I remember calmly telling my teammate - hey, can you cut the strips a bit further from the window. And they were like - “oh! sorry, okay”. We even packed one of the Creality Ender 3’s with us. And then went to Lviv by evacuation train the next day. 

    The train was full of people, they even slept in the corridors. But as we were on our way, in the train, trying to catch some sleep, we could finally think - and feel something. We already wanted back. It just felt wrong. We wanted to help, to fight, anything. In Lviv, it is safe. It’s too quiet here. There’s volunteering here to be done, yes, and it is helpful. But we want to go home. We’ve been sitting here for almost two days having done almost nothing. So we’re going back to Kyiv tonight, and will help there.

    Hopefully those who wait for uECGs will forgive us if we accidentally lose the latest batch of uECG in some fire or bombing! We know we promised they will be available soon. But we can produce another one when all of this ends. Don’t worry, this should only take a few days.

    P. S. If you want to help, please donate here: https://savelife.in.ua/en/donate/ This is a local non-profit called INTERNATIONAL CHARITABLE FOUNDATION ‘COME BACK ALIVE, they will distribute the funds at once here where needed.

    There’s also a possibility to donate directly to Ukrainian Armed Forces, the methods to donate are here on the official website of Ukrainian Central Bank:

    https://bank.gov.ua/en/news/all/natsionalniy-bank-vidkriv-spetsrahunok-dlya-zboru-koshtiv-na-potrebi-armiyi 

    Any amount helps, but if you can’t, it’s fine too! 

    You can find other ways to help, including locally, here: https://supportukrainenow.org/ 

    In any case, we know you support our country!

    Слава Україні!

  • uECG is back in stock!

    Ultimate Robotics08/17/2021 at 19:59 0 comments

    So, this happened - uECG is again available on Tindie

    It may be a couple months behind our original schedule (we aimed for May/June, now it's mid-August), but it's here now! On the way, we made a new device case 3D model (and 3D printed a lot of them!) and a new packaging design, ordered all kinds of supplies and accessories, shot a new video and took new product pictures, rewrote most of our description here and on Tindie from scratch, and had to figure out how exactly do we sell at all - with the new shipping rules regarding VAT in Europe.

    Now that we did all of this, stock is back, and sales are open again! There's some updates on Tindie regarding shipping, but other than that it's pretty much the same as before - at least where the product and its options are concerned. In regard to the product page content, however... there's major changes. All of the text is rewritten, there's now a very detailed list of features, and the new pictures look nicer! We really like how the page looks now (we didn't before...).

    uECG v.4.5. itself has a few differences with the previous versions - most of which we mentioned in the previous logs - like adding external sticker antenna and an IPEX1 connector and removing optocoupler (more on hardware changes in this log). Software-wise, we added OTA firmware update via Android app and a support for standard BLE connection, so uECG can now be seen as a standard BLE heart monitor in other apps (including popular fitness apps). For that, we rewrote A LOT - the bootloader had almost nothing in common with previous one. Some more good news: the new bootloader will be compatible with all previous uECG versions! We've finished writing it for new devices and will be adding compatibility over the next couple weeks. Meaning theoretically (we're 99% sure) any uECG we made can have the possibility of wireless firmware update and can be seen as a BLE device - possibly including even the 2.2 version. It will require updating the bootloader through wires with a programmer like STLink v2, however.

    Anyway, time to see the new uECG 4.5 trailer! 

  • uECG event log

    Lucy Sohryu08/15/2021 at 13:30 0 comments

    We've decided to create this log to keep uECG-related events and news in a single place. It will be updated whenever something new happens, so keep an eye out!


    Feb 14, 2022 We're back from vacation, although we still wait for a new batch of uECGs. It's due in 7-10 days - until then, we have a few devices in stock. Also, Happy Valentine's Day!

    Jan 19, 2022 New batch of uECGs in early February - we'll reopen then, as we decided that despite still having a couple uECGs left, we better use the time to upgrade our packaging/shipping process and prepare for the spring. See you soon!

    Jan 16, 2022 Extended the break for a few days to take inventory and order new production batch, stay tuned

    Dec 28, 2021 We're taking a break until January, 16! Happy holidays to everybody!

    Nov 16, 2021 We're back from the break! And we also have extra gel electrodes back in stock, as well as a fresh batch of USB bases from the factory. The bases are slightly more expensive now ($14 instead of $10, as the component prices have gone up). Other than that, everything's back to normal!

    Oct 26, 2021 We are on vacation from today to November 14! Time to rest a bit, we've been shipping slower recently. Feel free to sign up for notifications about when we reopen.

    October 13, 2021 update Extra packs of gel electrodes temporarily removed from order options, cause we run out of them and the new ones are arriving in a week or so. We'll still put 10 free gel electrodes with each order, we just can't put more of them.

    August 24, 2021 update Bug with radio mode (about which we wrote on Sunday) is now fixed and all orders until now are shipped! Thank you for your patience!

    August 17, 2021 - uECG returns - with new features! Well, it’s clearly taken longer than a month since we sold out all stock in April - in fact, it’s now late July, but we’re launching uECG sales again! uECG v4.5 has new PCB layout, some new components (and some removed), better antenna, more battery life (24 hours, finally!) and new firmware improvements! We have implemented standard BLE connection (so fitness apps can now recognize uECG as a generic heart rate sensor), better signal packaging for BLE version (previously R peak amplitude in BLE mode wasn't as precise due to the averaging method), and more reliable R peak detector. And we also made another big step - wrote a brand new bootloader, so you can now upload new firmware directly from the Android app!

    April 2, 2021 - New uECG stock in a month Well, we have officially almost run out of uECGs. There's only a couple devices left. We're preparing a new batch to send into production in April, and it'll (probably) be ready at the start of May - but who knows, maybe there'll be delays at the factory. We can hope though!

    Latest app version here:

    uECG monitor app on Google Play.

    Feb 3, 2021 - Arduino library

    Official Arduino library is online.

    Dec 9, 2020 - EMG mode is working!

    We play Cyberpunk 2077 theme cover with EMG gesture control using uECGs in this Hackaday log.

    Sep 9, 2020 - New app functions

    Hackaday log about the app update - Poincare plots, HRV, accelerometer data.

    Sep 1, 2020 - Wireless firmware upload is ready!

    All units ordered after September 1st have wireless firmware upload capability. Older units require uploading new bootloader via ST-Link once, after that they will support wireless update as well.

    A USB base station is required for this process - BLE is not supported yet.

  • New uECG got firmware upload via phone!

    Olya Gry07/23/2021 at 16:38 0 comments

    To turn uECG maintenance from slightly painful to pleasurable activity, we made it possible to update firmware directly from the app! This process currently takes about 2 minutes, but all you need is a phone and uECG.

    How did such a technological breakthrough become possible, you ask?  It's the new bootloader. When we added support for the full BLE protocol, we had the opportunity to reliably (albeit slowly) send data to the device - and this, in principle, is all that's needed to update the firmware. Surprisingly, even with BLE support, bootloader size is still less than 16 kb - so we will use it in the future too.

    Firmware upload process will be described in more detail later in the Instructions section - for now you can watch it in our new video!

  • uECG can be a standard BLE heart rate monitor now!

    Olya Gry07/21/2021 at 12:49 0 comments

    We have been thinking for a long time how to make uECG more accessible, in the sense of making it user-friendly - data processing, a nice multi-functional UI, a cloud for storing user data... But dreams don't always hurry to come true...

    Anyway, in the new uECG version we wanted to do something for everyday use. So we did just that.

    Now uECG can connect as a standard Bluetooth heart rate monitor and display heart rate and RR intervals in a standard format. That is, if you use running app in which you can connect devices / fitness trackers, then you can now add uECG there and monitor heart rate changes - and if the app supports this function, then also the RR intervals!

    We cannot name specific apps because this is considered using someone else's brand for advertising purposes - but we've tested a few popular ones and they all work. In theory, any app of this type should understand our data format - we made a short video of how this works in some of them.

    You can also add uECG support into your own apps much more easily now (we'll write some documentation on this, once we have some time).

    With that, we have at least made uECG more approachable!

View all 45 project logs

  • 1
    Unpacking

    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/off
    1. Turn on the the slider on the side of the device - slider switch is used for shipping and long storage modes, not required for standard use
    2. Press a button - the device will turn on immediately. 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 sees R peaks in ECG - i.e. in contact with the skin.
    4. To power off, press and hold the button for 3 seconds. LED should switch from green to red, then you can release the button
  • 3
    Usage
    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! Current version doesn't automatically turn off when no skin contact is present.

View all 10 instructions

Enjoy this project?

Share

Discussions

moses5407 wrote 10/31/2022 at 08:50 point

Hi, tried to reach you on Tindie via question form but got no response, so trying here.

The info says: " It streams processed ECG signal in real time and also collects raw data."

Can it also stream raw ecg and accel data? How can I customize the on-device ECG and accel processing?

Would LOVE to make use of this but I need to use custom algo's.
Thanks

  Are you sure? yes | no

Ultimate Robotics wrote 10/31/2022 at 12:50 point

Hi! Got no notifications from Tindie about your messages and can't find them anywhere ((

But yes, it streams raw ECG data together with processed info (RR intervals and other stats), there is no on-board memory. On a phone or ESP32 via BLE you get 122 Hz stream with relatively rare acceleration/gyro updates (once per second approximately), on PC via base station or on Arduino via nRF24 module you have 976 Hz ECG stream and accel/gyro data are available at about 20 Hz rate

  Are you sure? yes | no

mario.ianez wrote 07/28/2021 at 13:55 point

Hi and thanks for this wonderful project. I am an electronics engineering student and I had some questions for you. I have implemented your hardware in my own PCB to test the ECG signals. I supose it is normal to have a coupling between the source and the person while measuring with the electrodes. The signals entering to the afe that are cho+ and ch1+ referenced to GNDS (virtual reference +0.6V) that is cho- and ch1- are not filtered in the analog circuit if I am not wrong.

My doubts are:

1. What should be the form and the values measured in both signals entering to the afe? cho+ and ch1+ referenced to GNDS.

2. Analizing the afe, how both signals derive in a final one?

  Are you sure? yes | no

the_3d6 wrote 09/10/2021 at 16:13 point

Sorry, only now noticed that question here - but I believe we discussed it in details on Tindie :)

  Are you sure? yes | no

egonspengleruk wrote 06/09/2021 at 12:27 point

Do you have a part number / source for the surface mount 4mm electrode connectors? Its a neat way of mounting them that I would like to try, but the BOM just lists them as pin header

  Are you sure? yes | no

the_3d6 wrote 06/19/2021 at 22:19 point

I think there still is no part number for them - but we bought them here: https://item.taobao.com/item.htm?spm=a1z09.2.0.0.21012e8dG3MeYB&id=563032312890&_u=b3i3ohmv647f
Overall "ecg snap connector" search gives some useful results

  Are you sure? yes | no

Minkowskii07b wrote 12/01/2020 at 14:48 point

Hi! Iam an Electronics Engineering student. I would like to know if there is a chance to get ECG and GSR data with BLE connection without using the APP. I just need to retrieve ECG  and GSR data and display the graph WITHOUT using the official APP. 

Thanks a lot.

  Are you sure? yes | no

the_3d6 wrote 12/04/2020 at 15:09 point

Hi! Sure, but you still need some app to do it. The best way is to take our app code: https://github.com/ultimaterobotics/uECG/tree/master/uECG_v4_2_monitor/uECG_v4_2/src/main/java/com/ultimaterobotics/uecgmonitor4_2 and extract functions you need - I assume you want BLE communications (file ble_uecg_service.java, half of it is dedicated to BLE processing, another half - to serializing and providing data for other processes) and packet parser (file uecg_ble_parser.java).

Although it could be simpler to use the whole app, and replace UI drawing with your own functions - for that you need to disable drawUITask and touch_process from main.java - in this scenario, function update_ecg_data will be called whenever new data are received, so you can add your processing code at the end of it, but nothing on the UI side will happen.

  Are you sure? yes | no

Baldur Thorgilsson wrote 11/11/2020 at 20:39 point

Hi and thanks for a nice project. I cloned the git project but the apk file constatnly frose. I managed to get the app from playstore, run it and get data. I also liked to try it on windows but was not able to compile the ecg_monitor project. I have installed mingw so I have gcc, but make seems to be called mingw32-make. Running mingw32-make Makefile gives errors and no exe file. Also tried several imports to Eclipse without luck. Could you please explain how to compile the windows application? (Im not fluent in gcc and make).

  Are you sure? yes | no

the_3d6 wrote 11/13/2020 at 18:58 point

Hi! Thanks :)
Not sure why you can't get android app to work - it seems that github has the latest version, possibly some problems with permissions? If you won't be able solve it in a simple way, please send more detailed reports of what exact errors your are getting (and what happens in android studio if you run it in debug mode), we'll try to figure it out.

As for PC program - please don't try to get ecg_monitor running, it is outdated and I'm not sure if we'll continue that branch anytime soon. As of now, our best solution is using node.js version (also on github) - and if you want these data in another app, you can get them via POST requests, browser interface gets data this way (you can look into html code, functions poll_history_data and poll_ecg_data process requests, and call corresponding data parsers - it should be reasonably doable to convert it to other languages. Or alternatively you can look into server.js and use parsing function from it).

Please keep in mind that we will introduce support of multiple devices soon (most likely this year, possibly even this month) and thus requests will use some kind of device ID in them. We'll try to get backward compatibility though

  Are you sure? yes | no

Baldur Thorgilsson wrote 11/14/2020 at 08:24 point

Thanks for your reply.  I am focusing on the PC side now. Looks like I need to investigate the node.js solution, I'm unfamiliar with it. In the meantime I can see on a serial monitor that data is received on the PC side. I would like to interpret them as I am experienced in serial communication and data processing. In a comment you made January 17th you touch on the format. Is there a more precise description of the format or could you explain it?

  Are you sure? yes | no

the_3d6 wrote 11/15/2020 at 01:23 point

If you want to implement serial parser, then it can be done in the following way:

USB receiver sends all packets it gets from radio as virtual COM port data at speed 921600. Packet length can be different in different modes (by default uECG sends BLE-compatible packets and receiver ignores them if not told explicitly to switch into BLE mode - this part isn't working well right now so you won't find code for this mode, although I think it will be there in the next update), with single button press it switches in direct radio protocol with 64 data bytes per packet - a few more header bytes are sent via COM port - and with second button press it switches into 32 bytes per packet, third one returns it into BLE mode).

For direct radio mode, packet structure is the following:
1. first two bytes have fixed values (79, 213) and are used to sync with data stream (we don't know at which point we start listening, and it's possible that some packets will be corrupted, but normally once you've synced with the stream, you know packet length when you parse it)
2. Starting from 3rd byte packet header starts (1 byte per each value): RSSI value, payload length, packet ID (if you are parsing data before whole payload is received, you need to wait - checksum is the last byte of the message)
3. after that, please check function parse_direct_packet_uecg from server.js - while the whole idea is the same for all packets - 4 bytes for unit ID, 1 byte for data points count, 4 bytes for less-realtime parameters (like steps count, battery, accelerometer etc - each packet has some of them, but not all together, first byte indicates which ones are present and this number cycles), and then some bytes for ECG data and checksum - but there are a several variations, I hope the code of this function is self explanatory enough. If you are in doubt what some values mean, I'm ready to explain them in detail.
 - important note: at the moment, each packet is sent several times so if you already got packet with given ID at the previous iteration, current one is duplicate and should be ignored. And it's not a rare case when all packets with given ID are lost, sometimes several in a row, so when interpreting data you want to indicate that one or more time points are missing - in that function, all lost points are filled with the first value from the new packet (you can see it in pack_dist > 1 logic branch).

Right now I'm working on a new radio protocol and packet format will be somewhat different - but I'll try to make as little changes as possible

  Are you sure? yes | no

Baldur Thorgilsson wrote 11/15/2020 at 08:42 point

Thank you so much for your reply. I think this is good enough information,  to start with at least. One more question. Why is there a base station with PC? Can PC's not receive Bluetooth directly? 

  Are you sure? yes | no

the_3d6 wrote 11/15/2020 at 14:02 point

In BLE mode, device sends much less data (122 Hz ECG vs 976 Hz ECG in direct radio mode), and even for that rate we are on the edge of violating BLE standard - possibly some devices won't accept this. In part it is because of BLE advertisement mode we use (we didn't implement direct BLE connection yet).

In direct radio mode, we use non-BLE protocol so PC can't receive it. Instead, 32-byte mode of direct radio is compatible with popular nRF24 module for Arduino, and thus can be used for projects not involving PC (I guess it is hardly usable right now due to poor documentation and lack of examples, but one day it will be there)

  Are you sure? yes | no

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: https://www.tindie.com/products/18040/ - 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...

Ideas?

Edit: It's a Samsung A51

  Are you sure? yes | no

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

Hi!
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:

java.lang.illegalStateException

Source file: Surface.java

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.

Cheers!

  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
        http://openocd.org/doc/doxygen/bugs.html
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 127.0.0.1 4444
Trying 127.0.0.1...
Connected to 127.0.0.1.
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: https://sourceforge.net/p/openocd/code/ci/master/tree/ ), then inside it run
./bootsrap
./configure --enable-stlink
make
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: https://github.com/ultimaterobotics/uECG/tree/master/ecg_monitor - 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 https://git.code.sf.net/p/openocd/code openocd-code

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

https://sourceforge.net/p/openocd/code/ci/master/tree/

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

[deleted]

[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

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

Similar Projects

Does this project spark your interest?

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