HAB (High Altitude Ballooning) is a growing hobby where enthusiasts use standard weather balloons to put small payloads typically 100g-1kg into “near space” at altitudes of around 30km or so, carrying a tracking device (so the balloon position is known throughout the flight) and usually some sensors (temperature, pressure etc) and often a video or stills camera storing to an SD card for later retrieval. The job of the tracker is to read the location from the GPS receiver, possibly also read some sensors, and then format and send a telemetry sentence to the ground over a low power radio link. Flights only happen once the predicted path is known to be safe (avoiding airports and densely populated areas for example) and permission has been gained from (in the UK) the CAA. Here the tracking system uses the 70cm radio band (around 434MHz) using RTTY to send the telemetry down to a number of ground stations run by other enthusiasts. Telemetry from all receivers is sent to a central server that then drives a live map which can be viewed by anyone with an internet connection. The system works extremely well and has been used to track payloads at distances of 800km and more even though the transmitter is limited by UK law to 10mW ERP.
In early May I received my first Raspberry Pi computer, and having flown several high altitude balloons before I thought about using one as a flight computer. In almost all of my previous flights I used Arduino Mini Pro boards, and these are ideal – tiny, weigh almost nothing, simple and need very little power. I looked at the Pi and saw none of these desirable features! What I did see though was a USB port offering quick, easy and inexpensive access to a webcam, meaning that for the first time I could have live images (SSDV) sent down by my payload – something that hasn’t been done very often.
“Near Space” is a fairly hostile environment – less than 1% atmosphere, temperatures down to -50C or so – and if anything goes wrong it’s likely to stay wrong. The radio link is one-way so there’s no chance of remotely doing a “sudo reboot” let alone powering off then on again! Descent can be violent, as can the landing, so even things like SD card sockets can represent a potential failure mode. The Pi is a step up in complexity from the usual boards we use, that have no SD cards, or USB, or even an operating system, so the extra power and capability does come at a price, and the first one is an increase in the power requirement from around 60mA to over 500mA, and that of course means much higher power dissipation. People often worry about the low temperatures in near space, but when your payload is generating a few watts of power that is not likely to be a problem! I was much more concerned with how hot it was going to get inside the payload, so I added some heatsinks to the Pi:
I used special thermal adhesive to glue heatsinks to the USB/ETH chip and to the 3.3V regulator. Both get warm but not hot normally, and I feared that at 1% atmosphere (so less convection) they’d possibly get too hot. You can also see 2 wires carrying 5V directly to the Pi – soldered joints are more reliable than using a connector. Another modification was to remove the S2 video connector to make space for components on my expansion board. The final modification was to short out the USB fuses since my webcam’s current requirement exceeds their rating. I then added a small piece of stripboard carrying a Radiometrix NTX2 radio transmitter to send the telemetry and images down to the ground, and connected that to a simple GPS receiver on a wire tail so it can be kept away from the transmitting devices.
The final item for a basic tracker is a suitable power supply. Energizer Lithium AA cells are the obvious choice since they are specified to work down to -40 degrees C, and are very good at high currents (we need over 500mA for the Pi plus webcam). On the way to 30km the outside will get down to -50C, and even with minimal insulation the batteries will self-heat to stay within their operating range. The Pi needs 5V supplied to it, so I used an external LDO (Low DropOut) linear regulator fed from 6 AAs which will supply enough voltage to the regulator until they are pretty much flat. With the regulator dissipating up to 3 watts it needed and got a heatsink. This is a lot of heat to get rid of a payload (which is insulated because you don’t want it to get too cold either because that can affect other parts). I had some switched mode regulators ordered but they didn’t arrive in time for my flight, so it went up with the linear regulator.
The usual technique with the NTX2 is to send the ‘1’ and ‘0’ values in RTTY by waggling a general purpose I/O pin up and down at the correct rate. e.g. every 20ms for the common 50 baud data rate. This is easy when you’re programming a bare-metal AVR or PIC – just use a delay routine or, as in my trackers, a timer interrupt. However the Pi runs a non-real-time operating system, so I could not rely on accurate timing especially if the operating system is busy taking a photo from the webcam. There are other options but I opted for the simplest one – connect the NTX2 to the serial port. RTTY is just normal RS232-style serial marks and spaces and stop bits etc., so why not let the hardware UART do the timing for me? It didn’t take long to write a small ‘C’ program that opened the serial port at 4800 baud, read enough GPS strings to find the longitude, latitude and altitude, then close the port and re-open at 300 baud (I found that switching baud rates without closing and opening wasn’t always reliable) to send out a formatted telemetry string. Of course to do this I had to disable the login prompt on the serial port, and stop the kernel debug messages being sent to it, but all in all it was simple. All of this was done using the standard Debian image on a 4GB SD card.
Now for the live images. I had to apply a patch to Debian after which it happily recognised the webcam as /dev/video0. I tried a few webcams and settled on the Logitech C270 which is reasonable quality, light and cheap (in case the payload goes missing!). I tried several webcam imaging programs and found fswebcam to be the best (worked without fiddling, yet had enough options to tailor the picture taking). Remember that the radio system has low bandwidth and with a typical flight lasting 2 hours or so we don’t have time to send large images, so there’s no point using the very best webcam and the highest resolution. I settled on 432 x 240 pixels with 50% compression as a good compromise between quality and download speed. I measured the webcam current and it went from 50mA at idle to 250mA peak when taking a picture, hence the need to short out the USB fuse (140mA max). A simple shell script took a photo every 30 seconds, saving them on the SD card so that the tracker program could choose the “best” image (largest jpeg!) for transmission. Each chosen image is then converted to the form for download (split into blocks each with FEC) before being sent 1 block at a time. I interspersed the image data with telemetry – 4 image packets for each telemetry packet). Here’s the Pi making a self-portrait:
With the completed tracker tried and tested, and permission for the flight gained from the CAA, I built a container for the Pi, webcam, GPS, aerials, batteries and regulator. I didn’t want to use too much insulation as the package needed to not get too hot with 3 – 5 watts being generated inside, so I used 10mm thick EPX material. Any thinner would be too fragile.
As the launch day approached the wind predictions consistently showed an S-shaped flight path from the launch site near my home in West Berkshire, initially flying south, then east, then briefly north before turning west at higher altitudes. Then during descent it would go through those directions in the opposite sequence, finally landing somewhere in the Chilterns. With the weather (i.e. rain, as it’s summer now) looking OK if not ideal, I ordered and collected the gas for the balloon. I obtained permission for 2 flights, so a friend and fellow enthusiast Anthony Stirk could come down and fly two new trackers that he’d built. With 3 trackers and 2 flights we opted to fly a large balloon with a small light tracker, and then fly a second balloon with Anthony’s larger tracker and a GoPro HD video camera, then attach the Pi to that. After a bit more thought we decided to add a third tracker as a backup to make sure we got that GoPro back!
The flight day came, and so did the rain, but that was predicted to pass so we waited and then went to the launch site as it eased to a light drizzle. First was the larger balloon with the small payload, so Anthony could make an attempt at the altitude world record. Then came the rather more complicated flight with my Pi payload at the top, then the GoPro payload, and finally my backup “Buzz” tracker which I’d flown before. Here’s “PIE1″ waiting to go:
The entire train of parachute and 3 payloads weighed 1kg (same as my very first payload) and from the balloon to the lowest payload it was around 60 metres in length! The launch was interesting, as initially the wind kept the balloon low and the line was nearly horizontal! After a short wait the wind eased, the balloon lifted and got to an angle where it was safe to launch after running towards the balloon as fast as I could! I was relieved to see it all lift nicely, and that huge train made an impressive sight as it went up towards the clouds.
The launch site is in the village where I live, so afterwards we drove the chase cars back to my house to our “mission control” to watch the tracking and images from there. The predicted landing spots meant there was no hurry to get back into the cars to chase the payloads, so we had plenty of time to watch the images come in and grab some food.
The first flight was the altitude attempt, using a make and size of balloon that from experience either bursts early at around 27km, or exceeds specification to reach 40km or so. In fact the top few places in the altitude record table are all held by that make/size. Anthony was of course watching the altitude reading in the telemetry quite closely!
Meanwhile I of course was much more interested in how well the Raspberry Pi was doing. The GPS position was still showing the position at the launch site, which is a sure sign of interference to the GPS signal. I’ve not determined yet which it is, but the GPS receiver and antenna were quite close to both the Pi and the webcam in the payload. For next time I’ll add screening and increase the distance a little. However, the image data was coming in perfectly, not only through my antenna and receiver at home, but also via other receivers around the country. As the balloon got higher the pictures got better, and more receivers started getting good data, with some image data even being received as far away as Northern Ireland (over 500km away – not bad for 10mW!). Now, a PIE flight isn’t complete without a PIE chart, so here is one, showing the number of image packets received by different listeners (thanks all!):
The first flight meanwhile was creeping up the altitude table, eventually reaching the #4 position only 300-odd metres below the world record. Part of me was hoping it would go higher, but part was happy that it didn’t knock me down from my #2 spot in the table! The balloon then burst, and initially the descent looked perfectly normal. However most of the balloon was still attached and it managed to produce a parachute-like shape which slowed the descent to only 2 metres per second at an altitude where it should have been doing at least 5 times that! Turning to the main flight, it was sending in image after image without errors, and each image being better than the last as the balloon got higher and higher.
For more detail: PIE1 – Raspberry Pi Sends Live Images from Near Space