Pegasus I: HAB Payload and Communications

PegasusAfterRelease85K
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.
WP_20150126_006
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.
Pegasus-Communication-Paths

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:
WP_20150127_008
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.
WP_20150127_010

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