Back in early November, my colleague (Matt Long) and I set out to do an experiment. We’re very much into the Internet of Things (IoT) and are always looking to know and understand a little more. The idea was to do as I mentioned, an experiment; not a proof of concept (POC) or some kind of simple demo that you can do on your laptop. We wanted to know better what it takes to create an event-driven IoT solution that operates in near real-time while being able to scale as linearly as possible. We also wanted to be pushed by the fact that if any of it failed, then bad things could happen to the device being controlled.
We chose to visit near-space with a weather balloon packed with sensors and some things to control. Instead of the more traditional plan of sending up a balloon payload device that captured data internally, we aimed to stream telemetry live from the balloon into our cloud-based IoT environment and out to viewing and controlling dashboards. This means anyone can watch the flight data live as the flight happens through a phone or browser. Additionally, we wanted to send commands up to the balloon and make it do what we requested. We chose two operations to add to the payload. First, we wanted to control when the balloon was to head back to earth. Most balloons rely upon “burst altitude” to come down. This is fine but what happens if the wind doesn’t blow where you thought it would? With no control, you can only wait, hope and see what happens. My design for the payload included a mechanical release system that used a servo motor to pull down on a lever to release the balloon. With that, we could decide when the balloon started down. Here’s a diagram showing how it works:
The parachute was the second target for control. Usually, in a balloon like this, either the main chute hangs upside-down ready to use as soon as the payload starts to fall or it is connected inline with the balloon and activates when the balloon bursts or is cut away. For this, I designed a parachute box on top of the payload to hold the main parachute until we decided to deploy (or, if the payload detected the falling altitude was below a preset height in which case the payload would deploy autonomously). I don’t have a good diagram of the mechanism but again, a servo pulled on a lever that released tension on the lid of the parachute box. A small drogue chute maintained an upright position for the payload until we sent the deploy command at which time the servo released the lid and the drogue chute pulled the main out of the box. Now we have a full-out High Altitude – Low Open “HALO” capability. We could decide when to start coming down AND we could control better where we landed by skipping the typical leisurely parachute descent. We could get down quick(er).
Telemetry: After sensor measurements are collected, a 900 MHz radio modem sends the data down to the ground and mobile stations. Those stations send the data over to a “gateway device” which is just a computer that can send the data over the internet up to “Piraeus” (code word for the IoT technology). Piraeus then sent the data in multiple simultaneous directions including storage, but for the end user, they just saw the data appear on the dashboard. Note: This transfer of data from the balloon over to the end user is measured in milliseconds. It’s that fast.
Command and Control: In a similar fashion, just in reverse, the dashboard application can generate a command and send it back through all the internet pipes, over to the gateway, through the ground or mobile stations and up to the balloon. When that happened, an acknowledgement was send from the payload through the telemetry channels.
Launch and “Recovery”:
We launched the balloon on January 28, 2015 in Othello, Washington because it had interesting winds that went straight east and then about halfway up the winds went straight west keeping the balloon fairly close. After launch, the telemetry came every 2 seconds as it was designed. We tracked all of this data:
Internal temp, external temp, humidity, atmospheric pressure, GPS (lat, lon, altitude, ground speed, direction of travel, satellite fix, # of satellites), accelerometer data (x,y,z), balloon release, radio signal level, battery level, and a couple other measurements.
At around 85,000 feet we decided to cut away the balloon. We sent the command up, got the acknowledgement and almost immediately saw the telemetry change dramatically. The balloon release indicator said the balloon was away. The accelerometer x and y values went to their extremes positive and negative, and everywhere in between. Based on altitude change, the speed was over 200 mph. Then, the worst thing happened. We lost GPS in that extremely violent descent. Something must be stressing the antenna connection. The rest of the telemetry kept coming every 2 seconds as it should have. Everything was working except for GPS.
We watched the altitude drop and kept to plan sending the command to deploy the main chute somewhere between 1000-2000 meters. Again, the acknowledgement came, but the telemetry didn’t change much. The altitude (which we were now measuring with air pressure since GPS was out) was dropping way too fast. The last telemetry transmissions indicated the payload was about 300-400 feet up traveling downward around 35 mph. We had a rough idea where the payload landed but since it had traveled well over 20 miles total horizontal distance, there was no way to know for sure. A rough idea still meant a few mile radius and it was getting dark. We went home without the payload. Very disappointing.
A Call for Help:
We thought the only way to get the payload back was for someone out there, east of the little town of Othello, WA to find it and call me. But that didn’t happen. Then, as Matt was reviewing the raw telemetry data, he saw something weird. In its last 30 seconds of life, the GPS came back online for the last 12 telemetry transmissions and it contained GPS coordinates. The payload actually called us with the position just before impact. We reviewed the coordinates and maps, made tons of calculations on wind speed, location, and speed of descent to try to figure out where it was. So one week later with the new info, I drove the 3 1/2 hours to get back out there to look. At first I couldn’t find it but did when I looked about 1000′ north of where it indicated it should be.
The main chute did deploy but somehow in packing it, we must have crossed the shroud lines just right. It couldn’t unravel itself so the drogue chute and the main chute just acted as streamers slowing down the payload just enough to survive.
We now have everything back and except for a slightly dented radio modem everything is good and we are ecstatic. All the technology (streaming event-based telemetry and command & control) worked as good as we hoped which is always better than expected. The mechanics also worked as designed. We thought we lost it but then we got it back. Even the main chute getting tangled didn’t really hurt anything. All in all, a great experiment and great experience.
Here’s the narrated video of the flight:
In the next post I’ll describe some of the technology including payload and ground communications.