Building a House

We’re building a house and it’s right next door to our current house. That lets us watch the build closely and it also gives us a great place to put a time-lapse camera. Here’s a compressed version of the teardown and build so far.

First the teardown of the previous house:

Next, the foundation is created:

Framing, and now you can see the shape:

Pegasus I: IoT Command and Control

One of the biggest problems with High Altitude Balloons (HAB) is the retrieval of the payload after the flight. This can be a problem for a number of reasons. “Typical” flights have sensors and some on-board way to capture the data plus some form of GPS transmitter such as SPOT GPS or a HAM Radio system using a special frequency (“APRS”). Then, you add a balloon, a parachute and launch. You probably ran some predictions using available online applications to determine where the balloon will burst and where it will land. All that is great as long as the predictions are good and the payload doesn’t land in a lake or in a forest preserve.

For our flight we decided to try to get around the issues of not really knowing where the payload will land. Step 1: Instead of relying on the bursting of the balloon to start the descent, our payload had a mechanical release which will let go of the balloon upon command. This meant we could decide when to come down. If the balloon position is getting too far away or if it is heading anywhere we don’t want, we can send the command to come down early. Now, this only solves part of the problem since the slow ride down under a parachute still can take the payload a long way. Step 2: We went for a “HALO” High Altitude Low Open drop. Attached to the payload are two things for descent: a drogue chute that keeps the payload upright for most of the ride down and a main chute to provide a soft landing. The drogue isn’t very big so it doesn’t slow the drop as much as the main parachute so there’s still a real possibility of destruction when it lands crashes. The main chute is in a box on the payload which we can deploy on command or (just in case we don’t send the command) the on-board processor will release it if the altitude is too low.

The combination of these two capabilities means we can watch the payload and telemetry and make a decision on roughly where to land. Depending on the altitude, it still takes 10-15 minutes to descend low enough to deploy the chute BUT that is much faster than an hour or so under a large chute the whole way down.

Below you can see the payload box. The tube in the center is the balloon release. A line from the balloon goes into the tube and around a simple lever. Pull the lever (or have a servo do it) and the payload comes down. The container on top-back part of the payload is where the main chute is packed. The drogue chute is then connected to the lid of the parachute box and then to the top of the main chute. Here again, you pull a lever and the lid releases and the drogue chute pulls the main chute out. The metal tabs you see on the corners are where the main parachute shroud lines are tied. There’s two more in the back that you can’t see in the picture.

Here’s a diagram of the balloon release:

Mechanically, it all worked as we designed (and hoped). However, being our first flight, we’re obviously not skilled in the art of packing a parachute properly. When the main chute was released, it was tangled and the more the drogue chute pulled, the more the main chute remained in a ball. Thankfully, the drogue and main chute acted as streamers and slowed the payload down enough to survive the landing impact – all still works. Now we have some experience and hopefully, the next flight will see a successful parachute deployment.

To sum up, we decided the “IoT Command and Control” portion of our Internet of Things (IoT) experiment would include the rather large actions of balloon release and parachute deployment. Each of these actions could be initiated by on-board intelligence if the processor determines a problem situation. For example, the balloon will release if the flight time exceeds a preset duration. BTW, that countdown only begins after the balloon is launched and the payload “arms” itself. As for the parachute, I mentioned before that if the payload detects falling AND the altitude is below a preset limit then the main chute will be deployed. Some other side commands allow us to change the behavior of the payload and to use new values for what I mentioned as preset limits. For example, the preset limit for flight duration was coded/configured to be 2 hours. After that the balloon is released automatically. After the balloon was launched I reset the maximum duration to be 1 1/2 hours just to be safe. The commands are simple strings of characters that are parsed for information. Once the parsing happens and the information validated, the command is acknowledged back through the system and executed.

Pegasus I: HAB Payload and Communications

As I mentioned in my previous post, the goal of these experiments is to prove out Internet of Things technology including near real-time telemetry and command & control. Along the way it makes sense to try and have fun with it. Pegasus I is our first attempt/first flight with near-space high altitude balloons (HAB) which sounded like a really interesting exercise in design and execution. We needed to figure out how to get a balloon in the air with a sensor package to capture as many measurements as we could. However, IoT is partially about getting those measurements sent to you on the fly over the internet so that the data or telemetry can be seen and analyzed as needed. IoT is also about the ability to control your environment or at least components of the environment. Therefore, to be complete, we want to see the data being measured by the sensors in the payload, analyze that data, make decisions, send commands to effect the payload, and then see the changes through updated telemetry values. That process would then repeat throughout the flight.

The sensor package (“HAB Payload”) includes some standard sensors such as temperature (inside and outside the payload box), humidity and barometric pressure. A GPS radio was included to get latitude, longitude, altitude, ground speed and direction of travel. Additional values from the GPS (fix and satellites) helped to know when the GPS had a lock and on how many satellites. A battery level sensor showed how much voltage was left in the main battery pack throughout the flight. Accelerometer/gyro/mag values indicated rotation and stresses on the payload. Lastly, a switch held closed by a pin was used to indicate when the balloon released from the payload since the separating balloon would pull the pin.

To be able to receive the telemetry and send commands we needed two-way communications. This is usually very difficult to do in IoT (i.e., in a secure and scalable way). In our case it took the addition of a 900 MHz radio modem in the payload talking to a duplicate radio in the ground station. The ground station talked to an application on a laptop acting as a gateway device. The laptop application received the data from the ground station, transformed the CSV data into JSON and sent the new data into the cloud IoT technology where it was directed to multiple end locations. To perform command & control the process is reversed. A web application generates a command message, sends it through the IoT cloud environment where it is routed down to the gateway device, transferred to the ground station and sent via radio up to the payload. When the payload received a command and validated it, an acknowledgement was returned down to the ground stations.

Here’s a picture of the payload. In it you can see the Mega with the GPS shield (Adafruit), a power regulator (red board at the top from SparkFun), blue relays that I used to send power to the servos only when needed, the white/silver Digi 900 MHz radio, and the solderable breadboard containing many of the sensors and servo connections.
Our Achilles heel in the electronics design was the thin GPS antenna wire/connection at the top of the GPS shield. It works just fine in typical situations but under the stress of falling/spinning back to earth that connection lost contact and we lost GPS for most of the trip back to earth. How it came back in the last 30 seconds of flight is a mystery but why look a good horse in the mouth?

This diagram shows the fully redundant communication channels. The payload simultaneously talked to two ground stations. One used a tracking directional antenna and remained at the launch location for the entire flight. The second was a mobile station that the chase team used as they followed the balloon for retrieval. Both stations received the same data and could send commands. And, in practice, both stations maintained a good solid signal throughout the entire flight.

We used the 900 MHz XTend radios from Digi between the ground stations and the payload. They advertise a range of 40 miles in a “real” line of sight configuration. A balloon certainly provides that line of sight requirement. In our first flight we didn’t push the 40 mile range limit. We did exceed 20 miles and the radios performed well. There was some lost data here and there but I would say they were more than 95% effective across the whole flight.

To provide the processing, Arduino Mega’s were used in the payload and in both ground stations. The Mega was chosen partly because of increased memory as the programs grew to exceed the capacity of an Arduino Uno. Additionally, the Mega has four serial ports. The Digi radios communicate over a UART port as does the GPS radio I used from Adafruit. Add debugging in there and that’s three serial ports required. The Mega did all that and had one left over and performed well in all cases. In the tracking directional antenna station, there is an additional Arduino UNO. It is there to manage the positioning of the directional Yagi antenna while the Mega is free to work with telemetry and the commands that come through the system. The two Arduinos communicate using the I2C interface and I made the Mega the slave and the UNO is the master. The UNO calls over to the Mega and asks for the GPS positional data and the Mega responds with the latest information. With this setup, the Mega is only bothered periodically for the data and the UNO can spend its time moving the 2 servos into position so the antenna is always pointed at the balloon. Below is a picture of the directional antenna on top of a simple tripod made from some wood lying around:
The component rising up from the top of the Yagi antenna is a 9 DOF (accelerometer/magnetometer/gyroscope) sensor that allows the UNO to know if the antenna is pointed in the right direction. If not, the servos shift the antenna until the antenna is in line. The sensor is raised above the antenna and servos to get it farther away from metal and anything magnetic. Initially, the compass values were off as something (magnets in the motors, magnetized metal, etc.) was interfering with the values. Here’s a picture of the internals of the ground station including the Mega, UNO, power regulator and solderable breadboard. The Digi radio is beneath the UNO so you can’t see it in the picture.

The mobile ground station is a subset of the one I just described and does include a directional antenna but instead of a Yagi, I used a flat panel “patch” antenna that can be mounted to the roof of a vehicle so that it always points up. Also, since the antenna is “stationary” on top of the vehicle, there’s no need for servos and the UNO to control them so it is simpler in design. One addition to this station is GPS. With this extra positional data, we can track the position of the balloon in relation to the chase vehicle. Online mapping takes that data and puts icons on the map and even makes suggestions on the best path to take to get to the balloon’s current position.
In the picture you can see the black project box that contains the electronics (Mega, GPS, Digi 900 MHz radio), the large white patch antenna, the GPS antenna, communication cable, and the 12V power cable that just plugs into the vehicle’s lighter outlet.

So, if you look back at the communication diagram you can see that I’ve described the balloon payload/sensor package (at the top), the tracking stationary ground station (on the bottom left) and the mobile ground station (lower right). The “gateway devices” used to move all the data up into our cloud applications are just laptops with some local applications. Above, I described the Achilles heel in the payload. The Achilles for the ground stations is a consistent internet connection. Launching and retrieving balloons is usually done in very remote areas and keeping that internet connection is difficult. This is another reason for the two ground stations. Both can and do send data to the cloud and we just ignore anything that has a duplicate or “old” timestamp. In the first flight, connections dropped but we were always able to recover.

The next post will be about the “Command and Control” operations on the payload.

Pegasus I: The Mission

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).

Payload and Communication:

Here’s a diagram of the overall communication flow:

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.

It was generally intact.

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 a pic from 85,000 feet – just before we sent the command to release the balloon (very serene):

This one is about 30 seconds after balloon release. You can see the drogue chute we used to keep the payload upright:

Here’s the narrated video of the flight:

Matt’s site with more info, pics and video:

In the next post I’ll describe some of the technology including payload and ground communications.