How to Stream Video, Pictures, and Data From 90,000ft

"Don't undertake a project unless it is manifestly important and nearly impossible."

- Edwin H. Land

For the eclipse last month, I decided to try to fly a high-altitude balloon in an attempt to stream videos and pictures of the eclipse for the duration of the flight. Unfortunately, I lost my communications link with the balloon payload about a half hour after the launch, so my best eclipse pictures were from the ground, but this Instructable will serve as a means to document the accomplishments and failures from the flight and show how the technology demonstration (however brief) from this flight could be used for future flights to get a 400+ Mbit/s WiFi link with small, amateur, high-altitude balloon payload.

I hope it is useful for you all in your efforts to plan, build, and fly your own payloads.

Also, I have a small amount of experience in Mission Operations from a NASA-funded mission, so I tried to break the steps of this Instructable into some of the different subsystems you would see on NASA-like space missions.

Finally, I wanted this project to be as COTS as possible, so nearly all of the payload electronics can be found on Amazon and eBay. The only things that aren't on Amazon or eBay are the amateur radio beacons from Byonics and the fill gas (either hydrogen or helium depending on what is more accessible to you) you can get from a local welding supply store.

**IMPORTANT**

Safety is very important, so attempt this project at your own risk, and handle all equipment and materials with care. Also, make sure you follow all laws and regulations for where you are planning on flying.

Step 1: Materials and Supplies

This materials list is for starting high-altitude balloon launching from scratch. If you are able to successfully recover your payload, it makes future launches substantially less expensive. In this list, I have denoted which items are expendable and which items can be reused for future launches.

- 1kg latex balloon (expendable)

- Fill gas* (expendable)

- 1.25" PVC pipe, coupler, cross, and bushing** (expendable)

- Air quick connects** (expendable)

- Kite line (expendable)

- Radar reflector (re-usable)

- Kapton tape (expendable, but one 1" roll will last for many launches)

- Zip ties (expendable)

- Orange spray paint (expendable, but similar to kapton tape)

- Styrofoam cooler (re-usable)

- Ubiquiti 5GHz LiteBeam dish (re-usable)

- Ubiquiti 5GHz LiteBeam Sector (re-usable)

- Eclipse glasses (re-usable)

- Gigabit switch (re-usable)

- Action cameras (x3) (re-usable)

- APRS beacon (x2) (re-usable)

- Morse code beacon (re-usable)

- Hanging scale (re-usable)

- Micro-USB cables (x2) (re-usable)

- RPi heatsink (x2) (re-usable, but coupled to RPi)

- 64GB micro-SD (x2) (re-usable)

- u.fl to SMA adapter (re-usable)

- 20AWG silicone hookup wire (expendable, but similar to kapton tape)

- 9V lithium battery (expendable - specifically for Morse code beacon)

- GPS antenna (re-usable)

- GPS breakout (re-usable)

- USB phone battery (re-usable)

- Digital temperature sensors (re-usable)

- AA lithium batteries (expendable)

- RPi 3 (x2) (re-usable)

- RPi webcam (x2) (re-usable)

- 1080p webcam (x3) (re-usable)

- 2.1mm barrel jacks (re-usable)

- PoE injector (re-usable)

- DC-DC stepdown converter (re-usable)

- 6" ethernet cable (x2) (re-usable)

- 12" ethernet cable (re-usable)

- 4AA battery holder (x4) (re-usable)

- 500W power inverterter (re-usable)

- 8AWG power cable (re-usable; for ground system batteries)

- 8AWG ring terminals (x4 +/- pairs) (re-usable; for ground system batteries)

- 12V 20Ah SLA batteries (x2) (re-usable)

- 2-part epoxy (expendable, the more the better...)

In all,

expect to pay between $1k and $2k for a first-time balloon launch.

* I prefer using hydrogen because it is much cheaper than helium and provides a pinch greater lift, but helium is safer to use, and thus likely to be more easily accessible in educational settings

** The PVC for the fill nozzle could be reused, but personally, I like keeping he fill nozzles and whatever balloon is left attached as a memento for each launch I do.

Step 2: The Plan

The core of this project is a pair of Ubiquiti access points functioning as a WiFI bridge between the ground system and the balloon payload. They can be configured as a simple bridge, making a seamless connection between the network on the ground and the network on the balloon payload. With this configuration, you only need to worry about setting up IP addresses on a single subnet and don't have to deal with gateways and the like.

In addition, I built the payload with two Raspberry Pi 3's as separate flight computers, one serving primarily as a data logger with a GPS unit and a set of temperature sensors, and the other serving primarily as an image capturing system with three separate webcams. One of them was modified with a solar filter in an attempt to capture the eclipse.

Both Raspberry Pi's were powered with a 5V USB battery pack, and both the ethernet switch and the access point were powered by a 24V bank of lithium batteries.

Finally, on the ground, I had my laptop with an Ubuntu virtual machine plugged directly into the Ubiquiti LiteBeam dish. This allowed me to easily set up a static IP for the VM and not have to to deal with any networking configuration on my Windows laptop. Both the dish and my laptop (as well as an obligatory extra monitor) were powered off of 12V SLA batteries and a small power inverter.

Green - Sensors

Blue - Flight/Ground Computers

Grey - Communications

Orange - Power Sources

Step 3: Networking (Comms Subsystem)

Communications subsystem

As mentioned previously, the backbone of this project is a pair of Ubiquiti LiteBeam AC access points. They are rated at a 450+Mbit/s data rate at 30km, which happens to be right around the burst altitude of the high-altitude balloons I fly. On the payload, there is an additional gigabit switch, allowing more than one Raspberry Pi to connect to the one port on the Ubiquiti access point.

For the payload, I chose the LiteBeam sector antenn due to it's incredibly light weight and large (120-degree) beamwidth. On the ground, I had a LiteBeam 5AC-23, which is a smaller satellite dish with much narrower beam width and a much higher gain. In theory, it would be more cost effective to have a more omnidirectional antenna on the balloon payload and make up for that with a high-gain antenna on the ground that you can manually point*. Also, the dish is much heavier than the sector antenna, and it would have required a substantially higher mass budget to build a tracking system that would fit on the balloon payload and work for the duration of the flight.

With the sector antenna on the bottom of the payload, the effective field of view is a 120-degree cone with the tip at the payload. Then, as long as the ground station is within the footprint of the cone, you can point the dish at the payload and establish a link.

That being said, this kind of setup is really difficult to use in practice if you do not either have a mobile ground system or a balloon path that is mostly vertical. For a mobile system, you'll need some sort of tracking mechanism for the dish.

Not pictured in the subsystem diagram is a set of amateur radio beacons I used for backup tracking and payload recovery. I had redundant APRS beacons providing near-real-time GPS positioning data that I was able to use to track the payload in flight. I also had a morse code beacon that basically just functioned as an RF source for tracking after the payload landed. Using a directional antenna and a handheld radio, it's fairly easy to triangulate the location of the morse code beacon. I haven't had a flight where I have needed it yet, but this is really really valuable in cases where the APRS beacons cut out early and the payload could be anywhere in a several-mile radius.

Network Configuration

Configure the dish and the sector antennas as pictured above. Start with configuring the dish and giving it a static IP of 192.168.1.99, and then configure the sector antenna with an IP address of 192.168.1.20 so they will not have conflicting IP addresses. Aside from the IP addresses, decide on a network name an password, and set the channel width the 10MHz. Additionally, max out the power output, set the max data rate to auto, and check auto adjust distance. Make sure the network configurations match (aside from the IP addresses), and you should be ready to go.

More information about the Ubiquiti LiteBeam systems can be found here: https://www.ubnt.com/airmax/litebeam-ac/

The amateur radio beacons can be found here: https://www.byonics.com/microtrak/

* This is largely because of the rotational instability of the payload during flight. Some passive measures can be taken to slow the rotation like momentum arms, but in order to use a directional antenna on the payload, you would need an active rotation management system, like a reaction wheel, but the added mass might push the Ubiquiti payload over it's weight cap.

Step 4: Batteries (EPS Subsystem)

Electronic Power Systems subsystem

The power system for the payload is really simple. There were three voltage requirements: 5V for RPi's, 12V for the ethernet switch, and 24V for the PoE injector needed for the Ubiquiti access point.

The 5V requirement is satisfied with a USB phone battery and some micro-USB cables.

Both the 12V and 24V requirements are satisfied with a 24V bank of lithium batteries. Lithium batteries were chosen over normal alkaline batteries due to their better electrical performance in addition to their superior temperature ratings (unrelated side note: they also have a 20yr shelf life). In order to get 12V, I used a variable regulator that converted 24V down to 12V. This ensures that all batteries are drained equally, as opposed to having a 12V tap halfway through the battery bank that only drains half of the batteries to power the ethernet switch.

The other option to get 12V would have been to add a separate set of batteries to the payload, but it would have added too much additional mass to the payload. Also, the 24V set provided enough of a margin with power estimates to power the electronics for the duration of at least two flights, so the extra batteries were unnecessary in that regard as well.

Assembling the payload EPS

The phone battery is ready to go once charged. Just plug the RPi's in when you are running through your pre-flight prep.

As for the battery bank, solder 4 of the 4AA packs in series. Then, you can solder one of the 2.1mm jacks to the output for the PoE injection and just run jumper wires to the DC-DC regulator input. To power the ethernet switch, I added an additional 2.1mm jack to the output of the regulator in order to simplify payload prep.

Step 5: Raspberry Pi's (CDH and FSW Subsystems)

Communication and Data Handling and Flight Software subsystems

For the flight computers, I used Raspberry Pi 3's. One had a default Raspbian OS for use with the GPS sensor and temperature sensors, and the other had MotionEye OS for use with the USB webcams.

There's not too much to talk about here other than my experience with the two OS's during the flight. Raspbian is simple and easy to use if you have experience with bash. There is also quite a bit of documentation online for it, so if you run into a problem trying to program or set something up with Raspbian, it's likely that someone else has run into that problem and documented the solution somewhere. MotionEyeOS has a nice web interface for the webcams and seems fairly configurable, but I ran into data bottlenecks with trying to run three webcams simultaneously. This may be more of a hardware limitation with the Raspberry Pi, so further analysis is needed to optimize that portion of the payload.

FSW Setup

There is not much to do other than installing the two OS's on the micro-SD cards. You should be good to go at this point since MotionEyeOS automatically picks up the cameras, and the the default installation size for Raspbian should be good enough for a handful of metrics. That being said, if you want to maximize your storage potential on a 64GB micro-SD card, you can follow the steps here: https://raspberrypi.stackexchange.com/questions/49...

Also, make sure to assign static IP addresses to your RPi's that are different than the Ubiquiti access points.

The downloads for Raspbian and MotionEyeOS can be found here:

https://www.raspberrypi.org/downloads/raspbian/

https://github.com/ccrisan/motioneyeos

Step 6: Cameras and Sensors (Sci Subsystem)

Science subsystem

Without some sort of data collection, what is the point of flying high-altitude balloons?

I had three USB webcams, a GPS sensor, and a set of temperature sensors for my science payloads on this flight. Since I was trying to capture the eclipse, I cut up a pair of eclipse glasses and hot glued them in front of the webcam, like in the pictures above. I tested it on the ground and was hoping there would be a big enough difference during the eclipse to see it with the webcam. Unfortunately, it did not work very well, and the best picture of the eclipse I got was from my phone right after launch. Instead, I should have added a solar filter to a Raspberry Pi camera an not on the 1080p webcam. In this case, camera resolution is far more important than the image rate.

As for the temperature sensors and the GPS receiver, they use the RPi's GPIO pins and are really simple to set up. Right after launch, I was able to ssh to the RPi and use both the GPS and temperature sensors, but after the link was broken, they were not much use. For future launches, I plan on adding startup scripts that will continuously grab those metrics whether there is a connection to the ground station or not.

Not pictured in the subsystem diagram is a set of action cameras I was able to get off of eBay for ~$30 each. They definitely aren't as good as GoPros, and all three of them died within a half hour of takeoff.

Science Payload Assembly

Add one of the solar glasses to one of the imaging sensors on the flight. I chose one of the webcams, but one of the RPi cameras would have been a better choice.

GPS (on your data logging RPi):

Run the following commands:

- sudo apt-get install gpsd gpsd-clients python-gps

- sudo systemctl stop gpsd.socket

- sudo systemctl disable gpsd.socket

- sudo gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock

Then, you can run:

- cgps -s

to get the GPS coordinates. If you want it to just dump all the output into a single file, instead, you'll want to run:

- cgps -s > output.txt

Temperature sensors:

Run the following commands:

- echo "dtoverlay=w1-gpio" >> /boot/config.txt

- sudo reboot

- sudo modprobe w1-gpio

- sudo modprobe w1-therm

In my case, the temperature sensors were accessible under "/sys/bus/w1/devices/28*", so to see the output, you would need to run the following:

- cat sys/bus/w1/devices/28*/*

As above, to dump this into a single file, append the command with "> output.txt"

Info about the temperature sensors can be found here: https://pimylifeup.com/raspberry-pi-temperature-se...

And info about the GPS unit can be found here: https://learn.adafruit.com/adafruit-ultimate-gps-...

Step 7: Payload Assembly

This isn't really a subsystem, but it loosely corresponds to the Testing and Integration phase of normal missions and ideally touches every subsystem in the mission.

The payload body is a styrofoam cooler. You can use the cheap ones from gas stations and grocery stores, but I prefer giving up a bit more of the overall mass budget to use coolers with denser stryofoam. It's more structurally sound, so you can fasten your electronics directly to the cooler walls. For assembly, I like running zipties through the walls of the cooler to fasten down my electronics.

I painted the payload orange so it's easier to spot after landing.

The fill nozzle is probably a bit more extravagant than it really needs to be, but having the PVC intersection gave me a really solid assembly to tie off the start of the payload line. The same could likely be achieved with just a tee, but it's more there for peace of mind. Additionally, I have a quick connect to hook up the gas fill line without any hassle. I find this method substantially less stress-inducing than trying to hang on to the balloon after filling it and folding the neck before actually tying it off to the payload line.

Finally, for this flight, I added a camera boom to the side in order to get a selfie view of the payload and a slightly better view of the balloon. In order to do this, cut a small notch out of the corner of the Styrofoam cooler for the boom and epoxy it into place. Then, ziptie the cameras into the desired position and add epoxy to fasten them into place as necessary.

Overall, payload assembly is probably one of the simplest parts of the whole project. That being said, there aren't many times it doesn't occur within 48hrs of the flight, so it's often the most stressful and rushed portion of the project. Test early and test often.

Step 8: Launch Planning, Launching, and Recovery (Ops Subsystem)

Mission Operations subsystem (my personal favorite)

For planning flights, habhub is your one-stop-shop for burst and flight predictions.

http://habhub.org/

Once you have a rough idea of what you want to do for you payload and have an idea of how much it weighs, you can start planning your launch site. Start with the burst calculator to find your ascent rate and burst altitude, and then use that information to run predictions for different launch sites. The flight predictions can only be run 180hrs out from the planned launch, so my recommendation is to run flight predictions about once per week until you reach that 180hr window and then start running them daily until the flight. Depending on the time of year, the winds can shift rather dramatically over the course of a week, so the more often you check predictions leading up to your flight, the better.

As for the actual launch and recovery, the best launch site for me on the morning of the eclipse was right on the edge of the Mogollon Rim in northern AZ. I found an open campsite right on the rim with a clearing large enough to let the balloon go without too much of a risk of getting it caught in a tree. Pre-launch payload prep took about 45 minutes, and the flight was roughly 2.5hrs. The payload ended up landing in a small clearing about 1/4 mile off of a service road.

For filling the balloon, there isn't really an easy way to measure the flow of gas out of your large air cylinders. As such, I rely on measuring the neck lift of the balloon as a means of determining the proper balloon fill. I found a small hanging weight used for weighing fish that is really useful for this. Tying one end to the fill nozzle and the other to a small anvil or a bag of rocks, you can get a fairly accurate measurement of the neck lift. Oh, I should also mention here that target neck lift is something provided by the habhub burst predictor.

Pre-launch prep includes:

- Plugging in and booting RPi's

- Turning on action cams

- Turning on other electronics

- Securing payload lid

- Setting up payload train (Balloon fill nozzle --> parachute --> radar reflector/backup beacon --> main payload)

- Filling the balloon

- Setting up the ground system (if any)

This does not necessarily occur in a specific order, but if you are launching with a small team, usually, you'll want to have some people working on filling the balloon and the others prepping the payload and ground system

Additional Notes

This part of the project will depend entirely on the weight of your payload, your launch location, and the time of year for your launch. No two launches are the same, so expect this step of the project to be the most volatile. That being said, recovery can be simplified by running frequent flight predictions and watching your RT telemetry like a hawk. All of my launches had successful recoveries because of the final two or three GPS coordinates listed on the APRS website, but if your APRS beacon cuts out too early, having a Morse code beacon can make all the difference.

Launch Recommendations:

- Early morning launches typically have lower ground wind speeds

- Prep as much as you can before the launch (mainly payload assembly and measuring the main payload line)

Step 9: Future Improvements and Closing Remarks

As an engineer, I believe engineering is all about pushing the boundaries of what is possible and constantly iterating on our work to make our dreams a reality.

This eclipse flight, while far from an absolutely perfect flight, was the perfect test for payload equipment that has never flown on small amateur balloon before.

Tracking ground system

One of the biggest things I want to explore is building an active tracking system for the Ubiquiti dish that would allow me to make the ground system a mobile ground system. This will have the biggest impact ion being able to maintain a link through the flight since I could drive around to keep the ground system within the footprint of the balloon's access point. There are many commercial tracking systems out there for satellite TV, but I think it would be fun and beneficial to engineer one small enough for the access point and fast enough to track a moving payload while travelling down bumpy and winding forest and desert roads.

Payload system metrics

Another interesting sub-project would be to implement a collectd/graphite/grafana stack on the RPi's and ground system computers to collect and visualize system-level metrics for all of the computers used for the flight. If there are multiple RPi's on the payload, you could use one as a designated Graphite server and then have another graphite server on your ground computer to pull metrics down when possible. This monitoring stack has been implemented on RPi's before, so it would just be a matter of getting the architecture defined and setting up any init scripts needed to reboot everything in the event of power faults.

Payload-localized WiFi

What if there are multiple payloads that need a connection with the ground? It would be really straightforward to replace the gigabit switch with a small WiFi router, providing the entire payload train with a localized wireless network. Even if the link to the ground system is broken, all of the RPi's connected to the network would still be able to communicate with each other, allowing for the possibility (building off the previous idea) of having a dedicated metric collection server for an entire payload train. Imagine creating your own mini-internet of RPi servers and web applications and API's for hosted payloads at 100k+ ft.

Improved fault tolerance

This mainly just consists of having init scripts for every process necessary for data collection in case of random faults during the flight. Also, I want to develop more metric collection scripts for sensors and peripherals attached to the RPi data logger.

Multiple ground systems

Since the Ubiquiti LiteBeam sector antenna is designed as a point-to-multipoint network adapter, multiple ground systems should be able to connect to the payload simultaneously. Maybe a series of ground systems could be set up throughout the flight path so that the payload is in view of a stationary ground system at any point during the flight. Maybe it would be interesting to try to get multiple ground systems communicating over a balloon link where they aren't able to communicate with each other otherwise.

Video streaming to YouTube

If the ground system has a connection to the internet, I think it would be entirely reasonable (assuming a reliable ground-to-balloon link) to stream video directly out to YouTube from the payload. Out of all of the improvements, I think this will be the one I work towards the most.

-------------------- Closing Remarks -----------------------

Balloons are a great platform for experimenting with radios, imaging, and general electronics in a space-like setting without having to spend hundreds of thousands of dollars or even tens of thousands of dollars on payload electronics and test equipment. It's something that can be done in your garage with electronics off of Amazon and eBay. Also, remember that with every success there are likely numerous failures you are bound to encounter, so don't get discouraged if things don't go entirely as planned. Often times failures are the greatest opportunities to learn more about your project and push forward to a greater success or a more robust solution, so keep on keeping on.

If you have any questions or comments about this project or others like it, feel free to comment or message me.