In my 2010 Top Ten Predictions my #1 had to do with the future of connected cars. It just seems like too good an opportunity to ignore. Even for me. So we made a quick video with my company Bug Labs to demonstrate a bit of what I’m talking about. You can check it out here – scroll down the AutoBUG panel. Let me know what you think!
Over the past couple weeks I’ve had the opportunity to spend some time with children aged 6 – 8, working with them on technology projects. It’s been said so many times before, but it just needs repeating – a child’s view of the world and how it does/should work are incredibly enlightening. They are not trained. They are not biased nor pre-conditioned. They bring no pre-conceived notions. But they DO bring opinions. And it is these that are so important. For me they are a wake up call for how technology should work. Kids think on the level of “what” first then move to the “how”. They know what they want first. Then proceed to get it. The tools that don’t bog down in the “how” section of the process win big. Think of all the timeless toys that never seem to get old. LEGO immediately come to mind. You want a house? You build it. An Imperial Star Cruiser – build it. The tool works and never gets in the way of the “what”. In software, Scratch has become a standard for this type of approach.
The big take away from all this is simple – in reality we’re all kids at heart. We all want to think that way and engage with the world around us at the “what” level. We love it when we find tools and things that help us accomplish that. It’s fun. It’s satisfying. It’s never a chore. And the technologies we will talk glowingly about 50 years from now will all share that basic quality.
It would be great if I were talking about the new stuff I’ve been seeing and hearing about at CES 2010. But I’m not. I’m just taking the latest headline from Apple’s App Store and repurposing it here to make a point. Hardware innovation is nothing compared to software innovation. Yes, there are some very, very interesting and innovative new electronics here at the show. I’m not taking anything away from them. But it continually strikes me the categorical differences between the worlds of software and hardware. I understand that one is much “harder” than the other. Atoms vs. bits, blah blah. But we can learn a lot from watching how software leverages things to make big leaps in productivity. I will be making a point over the next couple weeks of exploring those ideas here. In the close to four years I’ve been observing and working with the CE world, I can honestly say I think we have some big opportunities in 2010 to change some things fundamentally.
Someday we will see headlines like the title of this post. I’m convinced. And the world will be a much better place for it. Technical innovation is a force for good. We just need to find ways to better unleash it.
What better way to start the year than to stick your neck way out and take a few chances. I’ve decided it’s my theme for the year anyway so what the heck. It will be a whole 12 months before I need to pay the piper, so what have I got to lose?
Some of these are pretty safe bets, others are seriously questionable.
1 – Automobiles become the next Killer App – let’s face it, what other mass market device has as much Internet/Cloud/Social/Hype potential? None. The car is going online in 2010 and the results will be spectacular.
2 – Microsoft becomes cool again – with Bing leading the charge, MS will start to innovate in new and surprisingly useful ways. Extra Credit – Balmer steps down.
3 – The DIY Revolution goes mainstream – Etsy, Make, Open Source (fill in the blank), all these communities point to a single, well known fact – the world’s consumers are rewarding vendors who give them more, not less, control. We will see a surge in manufacturers catering to this crowd.
4 – US carriers realize they need to truly support 3rd party innovation – today it’s still incredibly hard to work with the wireless carriers in this country. This year, they will come to their senses and recognize that the long overdue Mobile Internet is a revolution (still) waiting to happen.
5 – Google’s Android has major growing pains – The hype factor is high and the smart phones coming to market that use it are hot. But with Google now getting into the market directly, and questions brewing about if they’ll play favorites (they already are aren’t they?), Google will have to navigate this year carefully.
6 – The government more publicly embraces Open Source software and hardware – in an effort to innovate faster, respond more rapidly and, in the case of the military, help save lives and defeat tech-saavy enemies, the government will recognize that community-driven approaches to technology innovation trump concerns over secrecy and completely proprietary architectures. I anticipate a couple, large publicly announced wins.
7 – Apple continues to kick ass – what, you don’t believe me? My 70 year old mother just bought an iMac. Nuff said. I’m putting my money where my mouth is and investing in APPL.
8 – Sony continues to produce nothing of interest – I think change will come to Sony, but like most things Japanese, it won’t happen suddenly and certainly won’t happen in 2010.
9 – Obama will get a lot more gray hair – the White House seems to have this effect on its occupants. This isn’t really a prediction more of an acknowledgment of fact. He’s got a lot to do and not much time left to make it all happen.
10 – Peter Semmelhack will pick up his guitar and play live somewhere in Manhattan – this one is a stretch!
I will make sure to re-visit these in 12 months and evaluate my clairvoyance. Will be interesting! Let me know your thoughts.
Photo Credit – foxypar4
Work has been consuming all my free time lately. But the next step in the HH1 project is adjusting the AC cord so that it’s not as inconvenient as the current one (see the pix in the post below). Hopefully will have this complete this week and ready for testing. More soon.
Last night I reached a milestone that gives me pleasure to announce. I was officially (and indelicately) woken up by my custom gadget according to the heart rate threshold programmed into it. This event caps a multi-week effort to build and program this device and I’m gratified that it’s been a success. And I’m basically adhering to the time line I set up
Here are the details of this phase of the experiment. I set my clock radio to RADIO ON (loud) and then unplugged it. This would prepare it so that if it were ever plugged in again, the radio would automatically play. I plugged the radio into the extension cord that was now electrically attached to my BUG (see previous post). The rest of the set up was identical to my earlier experiments – Polar heart strap, Polar radio receiver, BUGbase, BUG von Hippel.
I set the heart rate threshold for 65 bpm, put on the heart rate strap (yes, it’s a little awkward but it has never gotten in the way of me getting comfortably settled and falling asleep). Approximately 30 mins later, my heart rate had slowed enough to trip the programming trigger and I was rudely jarred awake by “He Works Hard for the Money” by Donna Summer. I promptly removed the strap, dropped it to the floor and went back to sleep, happy in the knowledge that the experiment worked, and equally satisfied that it would not be needed again!
This was a simple experiment that proved I can wake someone up based on a pre-programmed heart rate threshold. What I need to do now is adjust that threshold to trap HIGH heart rates, not low, and start up my first open source “clinical trial” I have a few volunteers that I will reach out to. If you or anyone you know would be interested in participating please let me know. Of course, I will continue to make improvements, but I feel like the basic foundation is in place. Stay tuned…
So according to my time line I should be conducting experiments using a BUG to turn on something that would wake me up based on my heart rate. Up till now, I had the set up displayed in the top diagram at left – a device that measured, stored and transmitted my heart rate based on specific threshold criteria. To take the next step, however, I was missing a critical piece of the puzzle; a device to actually turn heart rate information into a physical “on/off” event to activate some external “waker upper”. Luckily I had access to an electrical engineering wiz kid named Andrew Tergis (interning at Bug Labs from RPI) who designed and built the power cord needed. The bottom picture shows it connected to the BUG. With additional programming support from Brian Ballantine, I am set to go.
Now all I need to do is find a suitable device that I can plug in and trigger based on a pre-determined heart rate threshold. I’m thinking I could use a radio set at a high enough volume to wake me up. I’m not a super heavy sleeper so it should work fine. I’m sure I’ll be irritated. But it’s for a good cause!
I’ve gotten a number of questions lately about how this device works, so for the sake of clarity, I’ve posted, at left, the data flow diagram for the HH1 device (see the posts below for more information on what the HH1 experiment is all about). It’s pretty straightforward, which is the point really. I want it to do its one specific function well. We can then expand from there. I’ve already gotten a number of suggestions for enhancing the device. For example, I was told by one person suffering from Type 1 diabetes that in addition to a sudden, rapid heart rate, they start to perspire. They suggested adding some type of skin moisture detector to the set up. I think this is a super idea, but I want to get this initial, very focused version done first. It can always get better!
To that end, I’m well on my way (thanks to a whole bunch of people I will identify later) to getting the next milestone done – activating something like a radio to wake someone up – so stay tuned. I’ll hopefully have something to post by the end of the week.
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.