Close

The hackathon story - second day

A project log for ICeeData

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

aryaArya 04/25/2016 at 00:000 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...


I decided to go home. The hackathon place was a half an hour away, and I could take a shower my hair needed oh so badly. I booted my laptop into Windows, loaded my browser with all the relevant info we had found on the web while researching and went home.

About two hours later, I was coming back to the hackathon place. I felt like there had to be a way to make the base station communicate when we wanted it to, and from the texts I had read the solution had to be something simple.

The solution was in the manual I just haven't read thoroughly:

  1. Plug the station in and wait until it establishes a 3G connection, going to the "sleep mode", also described in the manual
  2. Push the only button there is one time, then hold it for 1 second.

I literally forgot to RTFM.

Ah well.

A quick test, and we had captured the signal from the base station! Not only that, but we also recorded it communicating with the implant!

Only that it wasn't *that* good.

I already had known the signal used DBPSK modulation. Well, what we got looked like it, but obviously wasn't up to being decoded. Honestly, it looked like crap.

What was the problem? It was hard for me to understand. One thing was clear for me - this project would have to continue after the hackathon. For that, I also had to make sure I'd have a lot of data captured. Why?

Simple. The girl with implant&base station came to the hackathon from another country. I couldn't really come over for recording sessions anytime I needed more data. And I understood we'd need a lot of data for steps 1 to 3 of our plan. Thus, I began triggering the transmissions, recording them - both with the girl present nearby so the base station could talk with the implant, and with the girl far away so that I'd only capture the base station's requests.

I also was trying to understand what was there that prevented me from receiving clear waveforms. Granted, RF is a noisy thing, but I received crystal clear waveforms when I tried to record the car keyfob signal. Why not this?

I still don't understand. What are my guesses?

  1. 3MHz wide baseband with 10 possible communication channels. The base station was hopping between them while sending its requests for the implant to answer (this was the most visible when the implant was too far away, but I also had problems recording the communication since RTL-SDR best scenario bandwidth is only 2MHz). I also had various glitches with the communication which it would be best to show in a video, but I didn't record one. =(
  2. Unfitting antenna. The one we had was a stock antenna for DVB, AFAIK, so I wouldn't be that surprised to know it wasn't good for the frequencies we needed.
  3. Something bad with the SDR. Well, those things are cheap and, again, mostly made for DVB - so what can one expect?
  4. Something wrong with my GNU/Radio workflow - could as well be. I might have easily omitted something very important. I yet don't know if we could fix that by processing the data again or we'd have to record all the transmittions from scratch.

We had waveforms recorded but no idea what was wrong with them and whether we could fix it. Meanwhile, the app mockup was slowly coming to life.

Simple as that. I'm sure it won't be as simple when it comes to life, but that's a good start.

Me and my teammate talking about some nuances

The final hours were slowly coming, but we had something to show. It was clear the project is much bigger than "48 hours", but it was clear which tasks we had to work on.

Discussions