My third experiment was a success. Last night I set up my BUG to send a message to an online database (in this case BUGnet) where it would be logged for later review. The image above is a snippet of the output. I set the threshold at a heart rate level that I knew I would hit – 65 or below – so lots of data was recorded. This isn’t terribly realistic because in actual use the threshold would be set up much higher and wouldn’t just log a transaction in a database. Rather it would trigger an event in the physical world like turning on a radio or bright light or something with intent of waking someone up. This is the goal of next experiment!
Now that I have these pieces in place I will turn to building a module that has a relay or solenoid included and support circuitry that will respond to a message/trigger sent from the BUG indicating that a threshold has been reached. My timeline has that experiment done by 8/21. I will post updates on it as I go. As usual, please let me know if you have any questions.
This is the rough timeline I will use for the HH1 project. I may be able to do better than this but I think this is a reasonable approach. At the end, I want to have a device + software that I can show works reliably and comfortably and abides by the requirements I articulated earlier. I will then try to make it easy for anyone who wants to duplicate what I’ve done to do so with minimal effort. I’m currently setting up a wiki where all the components – hardware and software – will reside. I’m also trying to find a way to hook up with a community of potential users to set up an “open source” clinical trial of the device. Pls let me know if you have any ideas re that direction.
I’m back from my vacation and will press ahead this week with the next step in my experiment (HH1) – getting alerts sent when specific HR thesholds are met or exceeded. I’ll start simple and take it from there. The first alert will be an email to a pre-defined list of people. I will also try to set it up so I can send SMS msgs too. If I can get that working smoothly then I will get more advanced and try to switch lights on and off in my room, or turn on a loud radio or something. Many things are possible. But I need to get this next piece working first. I will lay out the plan in more detail in my next post.
I’m on vacation this week so I won’t be posting any updates here until next Monday. In the meantime –> www.twitter.com/psemme.
Looks like the second try was the charm. I stayed within range of the Polar radio receiver and was able to pick up a solid six hours of HR data. From the looks of it I got a pretty sound night’s sleep. The graph at the left shows the plot (courtesy of Amie and Brian at Bug Labs). The picture below it shows the setup I used – BUGbase, BUGvonHippel module, custom Sparkfun Polar receiver module and Polar heart rate strap.
What does this prove? It means that I have a solid foundation to work from. The next step will be to build in thresholds that trigger some events. Looking at the graph, maybe I’ll set up a notification if I hit a HR of 65 bpm. The alert would tell anyone interested that I have, in fact, reached a real REM state. I know how important this is to many of you.
What I’m really aiming for is to set up an alarm that has some teeth (remember this is about letting you or someone else know if you’ve reach a dangerously low blood sugar level while sleeping). An email won’t really help. I need to wake people UP. So we have a module here that contains a relay. With it I can potentially switch lights on and off or, probably better, turn on something that makes noise. Need to think more about that.
Once these thresholds are set up and triggers/alarms established I’ll conduct a small “clinical trial” with some volunteers and see how that goes.
I’ve been receiving a ton of great feedback and advice on this project. I very much appreciate it. It’s opened my eyes to some of the possibilities of extending the functions of this device once it’s up an running.
Stay tuned!
The nature of experiments – they succeed or fail. Both offer good information. In this case, my BUG stopped logging my HR data around 30 mins after I fell asleep. Probably because I rolled over and moved out of range of the Polar radio. I’ve now situated my BUG so that I won’t do that tonight. I’ve also strapped myself to the bed so I won’t move 
Will report back tomorrow on the results.
The traditional approach to measuring blood sugar levels is to draw some actual blood from somewhere, usually your finger, deposit it on a special paper strip and then insert it into a device called a glucometer. The device then quickly presents you with the measurement.
This approach works great when you’re awake and can do it yourself. But what if you’re asleep?
I don’t want something that needs a sensor implanted under the skin since that would violate three out of my six Requirements listed in my prior post, safety being the biggest (infection risk). So what are the alternatives?
It seems that there may be a correlation between a very low blood sugar level and heart rate. I am trying to get smarter about this now (if you know anybody who could help please send them my way). But with the online research I’ve done and the diabetics I’ve spoken to a relationship does appear to exist. All I’m really looking for here is a statistically relevant correlation, not a certainty.
So I’ve set up a quick prototype of a device that will monitor my heart rate while I sleep. It includes a BUGbase + BUGvonHippel module (from my company Bug Labs). I’m also using a custom module we put together that uses a Polar radio receiver (from Sparkfun) and a Polar strap that I wear around my chest. Lastly, we wrote a simple program that runs on the BUG to log the data.
If this works, then the next step will be to modify the program to do something if certain trends in heart rate are detected. But I will save that part for another post because I want to see if this first experiment works. I will report back shortly.
My first Hacking Health project, appropriately labeled “HH1″ is to build a simple device that alerts someone, sets off an alarm, or both, when a low blood sugar level is reached, specifically when sleeping. I want the device to be super simple to understand, operate and depend on.
Here are the requirements.
- Safe – must not have potential to harm user in ANY way
- Battery powered – must last through a typical 8-10 hour night
- Comfortable to wear – must not interfere with a good night’s sleep
- Reliable – must not “cry wolf”
- Simple to use – turn it on, check for “ok” status and that’s it
- Extensible – easy to add new functions to so the unit gets better over time
Please let me know if you think I’m missing anything elemental. I will be posting some more info on how I will share my progress shortly.
Last week I was given the opportunity to write a post for the Make magazine blog. I entitled it “Hacking Health” and described what I think is an enormous opportunity for the open source community to effect real, lasting and positive change in the world by rallying around solving some of the global health care issues we all face.
I received a great response – both critical and encouraging. Included in some of the comments I received were areas of focus that I would have never thought of – clinical trials being a great example. I now want to take the next step.
I have started a personal project regarding a diabetic low-blood-sugar monitoring device. I will detail the requirements, spec and usage scenarios on this blog and will also record my progress. I’m hoping it will serve as a good prototype of the types of efforts I’d love to see more of.
I am also setting up a wiki where I will put all the materials, source code, etc that I gather during the process. The hope is it can become a general repository for anyone who wants to start a new project or participate in one already established. More on this initiative next week.
For now, stay tuned for more details on the device/application I will be building. I will be counting on your feedback for guidance!
When I started this new blog I told myself I would not obsess over polishing my posts. I can’t guarantee that I won’t do that but at least I will also throw some less formal stuff in for fun. Here’s something I wrote quickly last night as I contemplated my first “Manifesto” post and what I want to focus on going forward – in a word, tools – and their growing importance in our hyper-connected world.
————————-
Data, first and foremost, is everywhere at all times. The rest is sense. That’s it. That’s the definition of the world (at least as far as we can tell).
Sometimes we want to extend our senses, enhance and expand them. For that we use tools. Tools give us super powers. Tools have allowed our species to rule the world. And even within our own species, he/she with the best tools wins. Always. Because tools help us process data into information we can use more quickly and efficiently than we could on our own.
So I guess we could modify the sentence above to say, he/she with the best information wins. Always.
If that’s true, then we should all be interested in always obtaining the best tools. Because good tools can give you unfair advantage, which, let’s face it, is important and sorta cool. But more importantly, they can improve the quality of your life and that of those around you too.
But how many of us are tool makers? Not many. Which means we forfeit our ability to improve our lives over to others. This is not always a good thing. I think we are going to see many more of us becoming more interested in creating and owning our own tools.
