Close
0%
0%

ICeeData

Making heart implant collected data accessible to the patients by sniffing RF transmissions

Similar projects worth following
Sniffing data transmissions between Implanted Cardiac Defibrillator to get data inaccessible for patients. Why? Because patients want it and can improve their lives using that data.

As for now, we're using RTL-SDR and GNU/Radio to collect the data, and Python for processing. Want to know more? Scroll to the details =)

We're a team that got together at Garage48 Health Tech Hackathon, which took place in Latvia, 15-17th of April, 2016. The fact that attracted attention of our team members was that each year, a lot of Implanted Cardiac Defibrillators get inserted into patients to protect them from arrhytmias and other heart conditions. They do that by monitoring the all kinds of parameters of the heart (including but not limited to heart rate, impedances between electrodes and so on) and applying voltage pulses to the heart internally. These implants also collect a lot of data from the monitoring process, which helps doctors make decisions. Overall, it's a noble cause - but noble causes often have little ugly details which get overlooked. The ugly detail in this case is that often patients never get to see that data. Why is it important?

It's all about making informed decisions. A patient knowing about arrhytmias episodes that occured to him/her has the power to change his lifestyle accordingly, by deducing the factors that have influenced his recent attacks and eliminating them - i.e. observing his/her heart condition according to his/her sleep schedule, work rhythm, food choices and participation in sports. As for now, the patients can only hope to get some information on ICD-prevented arrhytmias on scheduled appointments with their doctor, which often occur once a year or even less often. This eliminates any possibility of making informed choices by using patient's lifestyle data for future arrhythmia episode prevention.

So, here we are. A team, assembled by a girl with an implant keeping her heart in shape, holding a base station that collects a lot of information she personally could use to improve her life conditions, but being held back by healthcare providers. What are we going to do now?

We're going to hack it.

The implant sends its data out using a base station connected through ADSL/3G, communicating on 402-405MHz frequency band. Our plan is to:

  1. Intercept the communications between the implant and the base station
  2. Decode them into packets
  3. Decypher their protocol
  4. Understand the representation of the collected data
  5. Make human-readable reports for patients

Our team is halfway through step 1 and working on step 2. We are trying to establish a hardware solution for collecting and processing data so that we have enough for decyphering the protocol and linking it to the representations. We need Hackaday's community help, and we need hardware. We also want to attract media attention to the issue so that we can, with our efforts combined, make the data available through healthcare providers once and for all.

Links to useful information

Worklogs:

  • 1 × RTL-SDR
  • 1 × Linux-based machine With enough CPU power and storage space to process and store waveform data
  • 1 × person with an ICD (inside) and a base station for it (outside)
  • 6 × more guys, trying to make a difference

  • Hardware hacking succeeded

    Arya06/26/2016 at 14:12 4 comments

    Today I was going to make a Python course about using Python with Raspberry Pi at our hackerspace. However, it's a national holiday and nobody came, so I'll work on ICeeData. I'll make a capture routine, integrated with pyLCI, and capture the data using independent capture units...

    Instead, I went on hacking the base station. That looked more interesting.

    Bootlog:

    Post device verification...
    Serial2In string: ATi0
    Serial2In string:
    56000
    Modem Post : Passed with retries = 0
    
    Time taken by POST : [1.197000] seconds
    nand_init: manuf=0x000000EC  device=0x000000F1
    scanning for bad blocks...
    nand_check_blocks: nand_read_page() failed, addr=0x04A20000
    nand_check_blocks: nand_read_page() failed, addr=0x05F80000
    
    Consider yourself BLOBed!
    
    blob version 2.0.5-pre2 for Tanto Basic Device
    Copyright (C) 1999 2000 2001 Jan-Derk Bakker and Erik Mouw
    blob comes with ABSOLUTELY NO WARRANTY; read the GNU GPL for details.
    This is free software, and you are welcome to redistribute it
    under certain conditions; read the GNU GPL for details.
    blob release: d20081014_platform_4_16
    Memory map:
      0x02000000 @ 0xc0000000 (32 MB)
    
    ram_post executing...
    Data Bus Test
    Address Bus Test
    Data Qualifer Test
    Device Test
    c0200000status_next, board type = RF board revision =  (3)
    c1e00000r14_svc = 0x0000034d
    Autoboot in progress, press any key to stop ...
    Loading kernel from flash ........ done
    .
    Starting kernel ...
    
    
    Total blob time : [23.862000] seconds
    Uncompressing Linux........................................................... done, booting the kernel.
    Linux version 2.4.20_mvl31-tantobasic (iyera01@ussy-tanto01) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #d20081014_platform_4_16 Fri Sep 4 22:19:17 PDT 2009
    CPU: ARM926EJ-Sid(wb) [41069264] revision 4 (ARMv?(8))
    CPU: D undefined 14 cache
    CPU: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
    CPU: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
    Machine: Motorola MX2ADS
    On node 0 totalpages: 8192
    zone(0): 8192 pages.
    zone(1): 0 pages.
    zone(2): 0 pages.
    Kernel command line: console=ttyMX0,115200n8 root=/dev/mtdblock6 ip=dhcp BOARD_REVISION=
    boot_leds.c: RF boardRevision =  (3)
    Calibrating delay loop... 119.60 BogoMIPS
    Memory: 32MB = 32MB total
    Memory: 30332KB available (1592K code, 391K data, 64K init)
    Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
    Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
    Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
    Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
    Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
    POSIX conformance testing by UNIFIX
    Linux NET4.0 for Linux 2.4
    Based upon Swansea University Computer Society NET3.039
    Initializing RT netlink socket
    LSP Revision 97
    ikconfig 0.5 with /proc/ikconfig
    Starting kswapd
    Disabling the Out Of Memory Killer
    Journalled Block Device driver loaded
    devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
    devfs: boot_options: 0x1
    JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
    i2c-core.o: i2c core module version 2.6.2 (20011118)
    i2c-dev.o: i2c /dev entries driver module version 2.6.2 (20011118)
    i2c-proc.o version 2.6.2 (20011118)
    pty: 256 Unix98 ptys configured
    Real Time Clock Driver
    cs89x0:cs89x0_probe(0x0)
    eth0: incorrect signature 0x65b4
    cs89x0: no cs8900 or cs8920 detected.  Be sure to disable PnP with SETUP
    loop: loaded (max 8 devices)
    ttyMX%d0 at MEM 0xe400a000 (irq = 20) is a mx2ads
    ttyMX%d1 at MEM 0xe400b000 (irq = 19) is a mx2ads
    ttyMX%d2 at MEM 0xe400c000 (irq = 18) is a mx2ads
    SCSI subsystem driver Revision: 1.00
    kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
    kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
    NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
    Scanning device for bad blocks
    Registering NAND 128MiB 3,3V 8-bit as parts
    Creating 10 MTD partitions on "NAND 128MiB 3,3V 8-bit":
    0x00000000-0x00040000 : "Blob"
    0x00040000-0x00060000 : "Param"...
    Read more »

  • Tearing down the base station

    Arya06/23/2016 at 17:29 1 comment

    This is a third day, and it was awesome. I received the base station. There's this teardown of a Merlin@Home EX1150. It sucks^W is not that good though, so I've made my own.

    PWN'd.

    But first, look at this! This wonderful carry bag that base station was in can contain 3 netbooks! I need to buy more of those bags.

    Disassembling the base station is hella easy. After all, it's not made by Apple. There was a single screw that was not visible:

    Read more »

  • First work weekend (late log)

    Arya06/20/2016 at 17:39 0 comments

    Disclaimer: I got lazy^W late and didn't post this log on time. This log is dated 11st-12nd of June.


    Hello! This is the first "work weekend" for ICeeData project. Today and tomorrow, I'm working on data demodulation.

    This is also a small milestone. What's been ordered so far?

    • Various RTL-SDR versions to make a small test of which is more and which is less suitable for our tasks, as well as to use for capture units.
    • A couple of Raspberry Pi boards for assembling independent capture&decode units, first of which is going to be left at Estonia, with the base station of our participant. + various accessories for these.
    • An EX1150 base station. To immediately be disassembled and hacked into. Shipping costs are a bitch, and I once again thank Hackaday Prize for this. I might order another one - as a spare in case my hardware hacking goes wrong.

    What's to be ordered?

    • A more powerful SDR. Frankly, I'm still overwhelmed with the possible options. HackRF One seems like a good match, but there are many other viable choices for the task. I'm quite curious about LimeSDR, for example - it might just be a much better choice since it's more capable and therefore should provide more for the future research. It's a crowdfunding campaign, though, and there's the problem - a small chance of being left without money.

    As a starting point for working with data I've got, the transmissions I've got contain plenty of empty space. I'd need to remove that with some kind of a visual redactor. However, it doesn't seem to be that simple since all I know for this task is Audacity and it seems to not work well with raw data in the format I've got. What are the options?

    1. Convert to WAV with a GNU/Radio workflow
    2. Use some other visual editor

    But first, let's greate a GitHub repo!

    Read more »

  • Links to useful information

    Arya05/09/2016 at 04:24 0 comments
  • Woohoo, the Hackaday Prize! What now?

    Arya05/09/2016 at 04:06 0 comments

    Wow. It's been a wonderful week.

    I got to know about our nomination this Monday. It's been... Shocking. Both for me and for my teammates. Now, the project feels much more real. We've got the means for doing actual work on it, and I personally can't wait!

    First of all, meet @joeyfreelandjr! He's a volunteer with an impressive background in electronics that has the skills we're looking for. With his help, it's now possible to shine more light on modulation schemes of the data and, consecutively, write a routine that would decode this data.

    As for me, I'm researching opportunities on writing a custom Python block for decoding packet data and outputting it the way we want it to be displayed for our decoding efforts. There's a lot to be learned though, and I need to find a comfortable way for tweaking GNU/Radio routines and actually seeing the results in less time than a minute or so. I'm also looking for a nice book that'd explain all the concepts to me so that I have better understanding of what I'm dealing with. I've found a person in our hackerspace that has a really good understanding of what's going on and I've went through a small crash course involving Audacity, Spek and handling raw data in general. Also, I think I should make a workstation for this project. I have a Pi3 currently just sitting there unused, should handle this task well. I just think I need a bigger microSD card for it, as well as add an external HDD =)

    One of the most interesting things for me so far is getting a EX1150 base station. I can finally afford it and will order one as soon as the money arrives. Then, I'll hack into it! I'll try my best to dump its firmware because I can't wait to take a look at what it can be hiding - such as binaries with the communication algorithms in them! If those binaries are more or less easy to disassemble, I'll have very important information about the data we're dealing with - it's going to save a lot of time and research effort.

    Also, I'll soon be looking for a good SDR. We need some usual RTL-SDR dongles so that we can make sure our project is repeatable using them, but I'll also need something with slightly better hardware and larger bandwidth for initial stages of research where I can't afford to add problems like "hardware-not-good-enough" to problems like "trying-to-understand-the-thing". In other words, when I make sure my software is conceptually working on "perfect" hardware, I can focus on hardware-related problems.

    As for now, it's my Sunday project, meaning that I can spend on average one day at a week on it - which is actually a lot of time, considering all of the projects I'm working on =) I'm also going to have a "field trip" to Estonia - as soon as I get an SDR. Not to mention that writing GNU/Radio blocks perfect enough is going to take more than a week of quite concentrated work. With all the problems we'll solve along the way, we hope to make a good competition in Assistive Technology . At least, now that the funding question is solved, we have the means to participate - thanks to Hackaday Prize!

  • Plans & Hackaday Prize

    Arya04/25/2016 at 11:00 0 comments

    It's been a week since the hackathon ended. What are our plans for now?

    1. Build a GNU/Radio routine that'd capture the signal, apply all the filters that could be necessary and decode the data.

    There's a lot to be learned with GNU/Radio and RF in general. For making a workflow such as the one we could use in an embedded device, there's a lot to be added and plenty of things to be learned.

    2. Get a base station to hack into.

    These seem to be available on eBay quite cheaply, evidently, from deceased patients. Once we get one, tearing it apart and dumping the firmware would be number 1 priority. That could give us plenty of insight into "Decode" and "Intercept" steps - as well as maybe become a hardware solution for interception?

    3. Assemble a hardware solution for sending to volunteers - or defining a kit of software anybody could assemble.

    There are a lot of patients with ICDs who expressed similar concerns about their data and how it could be used. When we have a working hardware solution capable of "Intercept" and "Decode" phases, we can cooperate with other people by collecting a lot of data from their transmissions (anonymously) to facilitate the "Decypher" phase.

    4. Understand why the capture quality suffered.

    Was it something we could fix with postprocessing? Was it something that'd mean the signal has to be captured again? So many questions, so little time...

    5. Make collected data accessible for people who'd want to take a look at it.

    Some RF-savvy people have expressed their interest in seeing the data we managed to capture - to help us fully get through "Intercept" phase. However, we could greatly benefit from the huge Hackaday community and its helpfulness.

    6. Collect feedback from people in the industry.

    We've already attracted the attention of some people, but it's clear this issue needs to be raised among the health professionals.

    7. Get a development kit.

    I wonder if the manufacturers would be cooperative on our project. However, it doesn't hurt to try and it'd help us a lot to have a transmitter-transmitter pair we could control.

    Read more »

  • The hackathon story - third day

    Arya04/25/2016 at 01:45 0 comments

    It was the last day. I went to sleep late again, trying to capture transmissions that'd look at least remotely like DBPSK.

    I had some good news - some parts of what I was receiving certainly looked like clear DBPSK! Moreover, I could decode them just by looking at them long enough. However, only some packets looked like this. Neighbour packets looked like complete garbage. It was clear some filtering would be involved. Not only that, of course - also determining the reasons why packets were looking like garbage and fixing those. Having a couple of croissants with bacon on the table also contributed to my levels of happiness.

    What didn't was the fact that we had no packets decoded. Step 2 was not available without at least filtering some packets, and step 3 wasn't available without any decoded data. We were kinda stuck on step 1 because of some reason I couldn't even determine. Therefore, we didn't have nothing cool to show. For me, it was clear I had to concentrate on after-hackathon development.

    That became a topic of the talk with a mentor from the hackathon mentor team. He came to us to check our development status, and it became a quite valuable discussion. Bullet points about the conclusions we've reached:

    • We, being a research project, should try to get a devkit from the manufacturers who made the communication chips inside both the ICD and the base station. BTW, here's the datasheet, and here's the "datasheet preview".

    Why? Simple. We could get hardware operating on the necessary frequencies so that we could first train our data acquisition techniques, basically, implement "1: Intercept" and "2: Decode" parts using hardware we fully control so that it'd be easier to test all the quirks of our software part before trying to work on the real equipment.

    • We should definitely make a better antenna. Even a piece of wire of the necessary length would do, I wonder why I haven't thought of it earlier.
    • We should get more eyes on the data we collect. The more people are observing it, the more likely we can have suggestions about the possible packet structure, protocol details, or maybe even get some information from the people working in the industry.

    Read more »

  • The hackathon story - second day

    Arya04/25/2016 at 00:00 0 comments

    I woke up on the floor of our cubicle, besides the desk, head resting on my backpack and body covered by my jacket. I have to say, it was relatively comfy, even though I have to say it took some time to understand why I woke up in such a weird position. Then I remembered this was the decision made when I understood I forgot to bring my sleeping bag and had to pick the best of available options. Sigh. At least the floor was comfy.

    It was late, around 12. Well, I went to sleep at 7, so actually it was just 5 hours. I was surprised to find some breakfast-y looking croissants on the desk, along with some Coca-Cola. My teammates didn't want to disturb my sleep, but made sure I wouldn't start my day hungry. <3 They arrived to the cubicle soon.

    It was "Checkpoint №1" by the timetable. It meant the mentors were to come to our cubicle altogether, and they eventually did. Before that, we had a little group chat. Turned out they developed a backup plan. In case we wouldn't get any data, we at least would present a concept showing a smartphone app mockup, that'd show what information we could receive from that data and how patients would be able to use it to make informed decisions. It sounded like a quite good plan, so the other team members had already started to work on that - essentially, show the last step of our plan if the first would fail. Oh, the plan?

    1. Intercept the communications between the implant and the base station
    2. Decode them into packets
    3. Decypher their protocol
    4. Understand the representation of the collected data
    5. Make human-readable reports for patients
    We had barely started the step 1. An app mockup would be step 5, essentially, the only thing we could show if the first step failed. Sounded like a good idea. Mentors came to our cubicle, I booted up my laptop to launch all the software I'd need to continue the work.

    We only have one night left. That'd mean we're screwed if anything fails... If we don't have a way to trigger the communication manually. Let me see what the base station does when it boots up...

    Nothing in particular. Pressing the only button didn't do anything, it was, evidently, trying to get a "fix" on 3G connection before it'd even start to work. How didn't I get to know about its bootup sequence earlier...

    Read more »

  • The hackathon story - first day

    Arya04/24/2016 at 21:56 0 comments

    As you know, hackathons often start with idea pitches. Then, groups assemble for bringing these ideas into reality. The ideas that don't collect enough people, do not continue. This one did, with one hell of a pitch:

    I have this device controlling my heart, and I have no idea what it tells about my condition. It sends some data to my doctors, and I see them once a year only to hear that I've had an attack in February, having no recollection what I did back then and if there was something I could have avoided. 
    I talked with my doctors and they said they have this data accessible, but they basically don't care enough to send it to me. What I want is to hack this device, to myself see the data it collects and make informed decisions about my lifestyle.

    At that point, a roar of applause broke out.

    The pitch brought a lot of attention, but not many participants have come to take part afterwards. However, a small team formed and I got to be a part of it.

    I myself went to this hackathon with one goal - work on something interesting, preferably a learning experience. I work with Raspberry Pi, electronics and Python, but I never got any experience with wireless communication so closely. I had to do some research before joining to make sure the project wasn't a dead end. This is what I've found:

    Naturally, it started to look like a great learning opportunity, as well as a great thought piece for the media. I joined the team without second thoughts.

    Read more »

View all 9 project logs

Enjoy this project?

Share

Discussions

Bob Jones wrote 01/05/2017 at 16:16 point

Wondered if you are still working this, how far you have gotten and what defribrillator you have.

  Are you sure? yes | no

kelu124 wrote 06/28/2016 at 13:12 point

Kudos!

  Are you sure? yes | no

Nick wrote 05/24/2016 at 07:02 point

iI like the idea but can't help comment, an ICD does nothing for Heart Attacks it is designed to prevent dangerous arythmias which could lead to a cardiac arrest. Cardiac arrest and heart attack are two totally different things. Please get the basics correct.

  Are you sure? yes | no

Arya wrote 05/24/2016 at 07:45 point

I've edited the description, thank you very much!

  Are you sure? yes | no

Drnickyoung wrote 07/19/2016 at 09:44 point

excellent. Nice to see things progressing, can't wait to see more

  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