Software apps and online services
Hand tools and fabrication machines
My name is Alex Wulff. I’m currently 18 years old. Below is the long-winded answer for the question "what exactly is CastMinder?"
In a nutshell, CastMinder is a system that can monitor conditions inside orthopedic casts and splints to detect conditions associated with the onset of complications. These include skin infection, skin irritation, bleeding, and something called compartment syndrome, where an excess of pressure can lead to circulation loss in the casted limb. Additionally, I’ve incorporated devices into this system that can increase the rate at which new bone is formed, and decrease patient pain during the healing process. Embedded under the cast are small sensors, which collect data about conditions inside the cast or splint. These devices then send data to an iPhone application that I’ve spent hundreds of hours (way too much time) working on. This application can collect and analyze this data and predict the onset of harmful conditions before they arise inside the cast. The whole system is patent-pending!
At the heart of many of the devices in this system is Punch Through Design’s LightBlue Bean. The Bean is literally perfect for my project because it integrates Bluetooth, ultra-low-power operation, and a variety of onboard sensors into one concise package. The devices actually embedded inside the cast utilize a variety of different sensors to determine environmental conditions inside the patient’s cast. These sensors include a force-sensing resistor, homemade moisture sensors, and the Bean’s onboard motion and temperature sensors. The programming for these nodes is actually quite simple — all they do wake up at certain intervals, collect data from the various sensors, package it into one long string, send it via virtual serial to my iOS app for processing, and go back to sleep to save battery.
The iOS app is where things get a bit more complicated. Every time the iOS application receives data, it needs to check to make sure this data falls within defined parameters, but then it needs to add this data to a stack for analysis. I wrote an algorithm that analyzes thousands of sensor logs from this stack to determine not just that something could be immediately wrong inside of a user’s cast, but when complications may be at risk of developing. If so, the application also needs to alert the proper parties that something is wrong, and convey this to the patient. I’ve paired the app’s overhead down from using a quite hefty 50% of the device’s CPU (you could use it as a hand warmer) to a much more manageable 3% on every incoming serial message. The app also has to run in the background to continuously receive sensor data from the Beans, so I had to work really hard to get the energy impact low as well. While all these complex processes are happening, the app needs to display this data in a nice format to the user upon request, without any lag.
The iOS application also has the important task of controlling what I call the “active healing” portion of my project, which involves increasing the rate at which new bone is formed, and decreasing patient pain. I accomplish this through a combination of two separate devices — a transcutaneous electrical nerve stimulation (TENS) device and a bone growth stimulator. Both of these devices are prescribed outside of orthopedic casts and use electrical stimulation; however, this is the first time that someone has actually combined these two devices into one, and integrated them into a cast. The active healing unit is powered by, you guessed it, a LightBlue Bean. The iOS app allows the user to configure and turn on/off either system. It then sends this data to the Bean via virtual serial to interpret it and adjust the electrical output accordingly.
My first concept functioned literally nothing like the polished system I described above. The initial idea I had for this project was to have a variety of sensor nodes inside the cast, wired together, that talk to a box outside the cast that would vibrate if something is wrong. The very first device I made had wires sticking out everywhere, and would probably cause more problems inside of a cast then it would actually prevent.
From here I worked on making the devices smaller and smaller using printed circuit boards, but I quickly realized that this box idea wouldn’t work due to how gangly the whole thing was. I soon developed the idea to make a Bluetooth system — with a companion mobile application. I actually have a mobile app development business that allowed me in part to financially support this project, so iOS was an obvious fit. The system I developed still had sensor nodes wires together under a cast, but rather than being connected to a “dumb” box outside the cast they would talk to a Bluetooth “smart” box, which in turn would send data to the iOS app for processing. This was all well and good in concept, but after wearing the box around and having wires break under the cast, I realized that I needed to get wireless. I soon started designing printed circuit boards, ultimately leading me to a final design that incorporates an ATtiny processor, an RF24 radio, and a coin cell battery. Up to 9 of these could be embedded into a cast, and these devices talk to a very small receiver outside of the cast that vibrates if something is wrong.
This is the first viable system that I developed, and it has the added benefit of costing less than $10. However, I couldn’t exactly perform very complex calculation on the ATtiny85 which I was clocking at 1MHz has a grand total of 512 bytes of RAM, down from the iPhone 6’s 1 billion bytes and processor clock counted in gigahertz. I started to search for a small, compact Bluetooth board to interface with the iPhone application I had partially developed, and came across the Bean, eventually developing the system above.
I entered this project in my local science fair, and out of almost 100 kids, I was awarded the grand prize, the opportunity to present my project at the International Science and Engineering Fair in May in Phoenix. At Phoenix, I recieved a fourth place award in the embedded systems category and a prize from the United States Patent and Trademark Office Society.
A note on the code:
The iOS-Bluetooth system is not yet ready for public consumption, but the software for the nRF24L01-receiver system is available in the code section.