The aim of this project is to release a microprocessor-powered data-recording capsule into the upper atmosphere, attached to a helium-filled weather balloon. This launch has not yet taken place, but much work has been done on the capsule. As the team had experience with using a small single-board Raspberry Pi computer (also referred to as Pi), this was used as the microprocessor. Temperature, air pressure and the GPS data will be recorded at regular intervals during the ascent using sensors wired to the Raspberry Pi, and the data broadcast to the ground via a radio module. This will also allow the calculation of the balloon’s altitude and its location as it returns to Earth. A small camera is also fixed to the capsule to record the flight. Preliminary research into similar projects indicated that the balloon would reach an approximate height of 37 km, at which point the balloon should burst, releasing the capsule. The Raspberry Pi’s descent will be controlled by a parachute and the impact of landing lessened by a shock-resistant casing of some kind.
A standard helium-filled weather balloon will be used and the capsule containing the Pi and modules attached to it. The dimensions of the balloon will be determined based on the mass of the final load.
Coding and Raspberry Pi
Since the Pi must conduct multiple tasks, the components of the capsule are split into modules, each of which could be developed on multiple Pis. This solves potential issues like wiring conflicts and makes bug fixing easier – minor coding or wiring modifications can cause lots of problems, but any work done on one set of modules will not affect the others. The grouping of the modules is based on which components are dependent on each other. For example, the temperature and pressure sensors are configured using the same Pi, as data will be logged to the same text file. The temperature and pressure file will be completely independent from image files, so the camera can be part of a separate module. Setting up the workflow like this means that multiple people can code at once on separate Pis. All the scripts that are created this way will be collected together and run by a single master script, making debugging a lot easier. Each development Pi and its corresponding breadboard of components will be combined to a single 256MB Pi, to which a high data capacity SD card with all the scripts and master script on it will be inserted.
All of the functions and data collection from various sensors need to be programmed so the Pi can carry out the desired functions exactly. Python, a programming language that comes preinstalled on Raspbian (Raspberry Pi’s operating system), was chosen for the project, as it is relatively easy for less experienced programmers to pick up. As most Pi users also use Python, there are many tutorials and existing codes on the internet that are useful for this project.
The first element the project tackles is recording the ambient environment of the capsule and storing this data in a text file, beginning with the connection of the physical sensors to the Pi so they could communicate. A Raspberry Pi has two rows of 13 General Purpose Input/Output (GPIO) pins that can be used to connect the Pi to anything that does not have a USB. Sensors must be attached to these. Research into how the components should be attached is summarised in figure 1.
The BMP085 pressure sensor (Figure 2) is much more complex, consisting of its own small circuit board. However, it does have labelled pins which can be easily be connected to the right parts of the Pi.
After accessing the right data GPIO ports for each sensor and calling the right part of the output data, temperature and pressure data is output to a single text file. The programme can also be looped and a time stamp added to each reading to aid interpretation.
The next challenge is integrating the GPS module (Figure 3) into the other sensors and writing the capsule’s latitude and longitude to the same text file. The GPS module is another stand-alone component with comprehensive pre-installed software that outputs a range of data from location to velocity. After connecting the GPS to the correct GPIO pins, the Adafruit website became very useful in helping to extract the latitude and longitude from the data the module provided. The data could then easily be inserted into the temperature and pressure text file. A minor setback faced whilst trying to work with the GPS unit is that in order to test and troubleshoot the code, a GPS signal was required which was not always available within the school building.
There is also the possibility of using GPS to calculate altitude, though further testing and research would be needed to confirm if it would work above a certain altitude.
For the casing of the Raspberry Pi and the modules, high-density closed-cell foam will be used. There were concerns about the impact of low pressure on the foam and whether this would cause it to expand, possibly resulting in structural damage and an inability to hold all the components safely. However, tests on the foam in a vacuum jar showed that the foam was not affected by the extremely low pressure in any way and retained its strength on repressurisation.
The Raspberry Pi and other components were measured to determine appropriate dimensions that would leave enough space for all the components. The foam was cut using a scroll saw and will be finished with the belt sander to ensure straight edges. The casing can be seen in figure 4.
The casing will be finished at a later date after bringing all the different components together onto one Raspberry Pi. It will also be drop-tested with the small parachute. After this, any modifications for strength or fit, such as adding a space on the outside for the camera, will be added. This will be done later as all of the modules need to be brought together to determine how it will all fit, before foam inserts are added to ensure snug, gapless fit, so nothing can be damaged.
The broadcast of data back down to Earth has been one of the biggest challenges. The NTX2 transmitter from Radiometrix (Figure 5) is small, light and, crucially, broadcasts on a frequency outside that of any radio station, removing the likelihood of encroaching on any regulations. Connecting the transmitter to the Pi was a straightforward procedure.
A laptop was used to receive and interpret the data rather than another Pi, as this would require much more processing power than available on a Pi, and there are no weight limits. This also allows the broadcast of the minimum amount of data from the Pi, as the data can be processed into graphs on the ground.
The difficulty was getting the Pi to use this transmitter to communicate with a laptop at a distance. The language Radioteletype (RTTY) was used for transmission, as it can convert data into basic binary that can be received and easily decoded into the relevant data. Thanks to the University of Southampton, who procured a transceiver that could receive the signal and output data to the computer (Figure 6), the laptop is able to receive at the frequency the Pi is broadcasting. Weeks of deliberation and research into which of the many output ports on the transceiver should be used, involving laptop chipsets and complex specifications, showed that an audio jack would work perfectly.
At this stage, the 435.075-10MHz radio frequency from the transmitter could be converted into an audio format, and outputted to a computer via the microphone port. To interpret the audio, Dl-FLdigi, a downloadable interpretation programme that even came with a high-altitude ballooning edition, allowed us to take this signal and translate it into readable numbers. The programme required a programming language, baud rate, frequency band, and the desired frequencies to be set. It would then convert any sound the laptop picked up to a string of letters and numbers.
The next and most challenging task so far is to code the Pi to convert a text file to RTTY, then broadcast this encoded file’s 1 and 0s as high and low frequencies. To demonstrate control of the transmitter, with assistance from a technician, a variation of turning the GPIO pin to which the transmitter was connected on and off was used. This involved a simple code consisting of a loop which set the pin to on (true), waited half a second, then set it to off (false), then waited before repeating. This would produce a regular oscillation between two frequencies, which could be received as two distinct pitches through the transceiver. However, work on how to encode and transmit the initial text file is still ongoing. It is a matter of finding the right code on the internet and adapting it to the needs of the project.
There will be a camera on the capsule which will be used to take photos at regular intervals of the ascent and descent. This will be Raspberry Pi’s own camera module (Figure 7), with a fixed focus and 5-megapixel sensor. The pictures will be used to create a time-lapse which will be corrected for stabilisation and exposure in post-processing on the ground with a video editing suite.
The camera has been coded with a loop that will repeat for the number of photos wanted. Within the loop there is a command to take a photo, after which the programme waits for a set length of time. This will be the interval between photos.
The Pi camera came with its own set of commands which, after downloading, can be called in any script to take video and images. The python-picamera commands by Dave Jones were used as they best fitted this project’s needs. Raspberry Pis come with a camera slot attached to their circuit board, so connecting the camera consisted only of plugging it in.
In Python the ‘for’ loop repeats a user-defined number of times. In the loop, the picamera.capture function was used, which was imported at the start of the script. The function being used takes a photo and then names it x.jpg in any chosen location, ‘x’ being the iteration number of the loop. This means that no pictures will be written over, and we are able to set location allowing multiple time lapses to be recorded during testing and be stored in separate folders. After the picamera.capture has completed the loop moves onto the time.sleep function which pauses the code for a set amount of time which can be controlled by changing the variable. Once time.sleep has completed the code the loop ends and starts again from the beginning until the code is told to stop or until the loop has reached the end.
The images taken by the camera that are stored on the SD card will be used to create a time lapse using Adobe Premiere Pro. They will then be stabilised and colour corrected using Adobe After Effects.
The Raspberry Pi, for normal use, requires a DC power input via a standard micro USB. Whilst programming a wall socket adapter has been used, but unfortunately there are no wall sockets 30 kilometres up, so battery power is required. Rather than buying one of the increasingly popular USB battery chargers, a battery pack was designed and built (Figure 8), which uses a step down DC transformer to convert the 9 volts produced by 6 AA batteries to the 5 volts the Pi needs for a sufficient duration of time.
Discussion and Conclusion
This paper is far from a complete description of our high altitude balloon flight and its results, but more a summary of our endeavours up to this date, and how we intend to proceed.
The biggest issue and the main task that has slowed progression is the problem of getting the Pi to communicate with the laptop. With the ability to code and transmit in RTTY, the rest of the project can proceed. With all of the components assembled and coded on individual Pis, the master code can be assembled, and coded to run on start-up. This will go on a large 64MB SD card, and then in a super-lightweight Raspberry Pi model A (Figure 9), which has less RAM but also fewer unnecessary sockets such as the Ethernet port the other models have. The challenge then will be integrating the wiring for the various sensors, resistors and other components onto a single tiny breadboard (Figure 10), and soldering each join in place. This will involve some code editing as different components need to use the same GPIO pins, but should not be too difficult. A spreadsheet on the ground will also be necessary to process the received data and output graphs, including changes in pressure, temperature and speed. While the GPS data will give a rough idea of altitude, the pressure sensor will provide much more accurate data, but raw pressure data must be converted into an equivalent altitude. The current set-up is pictured in Figure 11.
The aim is to launch from Exmoor this summer once the weather becomes more appropriate for a balloon launch. The capsule and the modules within it will be tested rigorously beforehand to ensure there is no sudden malfunction at any point.
Baud rate: a measure of how many times per second a signal changes (or could change).
Breadboard: a board of holes that are connected underneath in rows, allowing pins to be inserted in columns to connect to each other.
Import: tells the code to use a certain library of commands which can be called later in the programme.
RTTY: RadioTeleTYpe, a communications system.