Introduction
First of all, I’d like to welcome you to the “Projects” section and to the first article in this category. I hope that reading this and future posts will inspire you to take steps toward creating projects you can be proud of and will gladly share with others.
Getting to the point, the first obvious question is: why the hell is it called STAN? Let me explain. Shortcut „Stan” comes from Stanley. Those who read my first post may already be connecting the dots, but for those who haven’t – Stanley was my grandfather’s name. He played a huge role in the fact that I’m interested in electronics today.
So, to honor him in a way and thank him for what he did, I decided to name my first significant project after him. Of course, STAN also stands for the full project name: Stratospheric Testing and Analysis Nacelle, which I think captures the idea of the project quite well.
Moving on, you might wonder: “Why the hell stratosphere and balloons and all that related things?” Well, ever since I was a child, I was fascinated by astronomy. So much so that when I was six, I received a huge astronomy book – from my grandparents, by the way – titled Kosmos znany i nieznany. (English title Space Encyclopedia) At one point, I even wanted to work for NASA 😛
Life took a different path, but that didn’t mean I had to completely abandon my dreams. I simply had to find a substitute. And stratospheric missions turned out to be exactly what could make me reach for the stars. So I went a long way – from a child’s dream to a stratospheric payload.
To wrap up this part, this project was obviously not my last adventure with the stratosphere, but it was the one that became a milestone for me. It’s also worth mentioning that at the time of writing this article, I’m working on an even more ambitious project, which will also be described on the blog.
Project goals and scope
When creating the project, I wrote down a list of assumptions that guided me while working on the stratospheric payload. Without further discussion, here they are:
- building a payload capable of performing multiple flights to at least the commonly accepted lower boundary of the stratosphere, i.e. 10 km, while enabling experiments and saving results to a data storage
- selecting experiments that would make it possible to collect basic environmental data such as temperature or pressure
- designing and implementing technical solutions dedicated to conditions present at those altitudes and higher
- creating software, including defining how data would be collected and saved
- performing tests to verify the implemented solutions
- drawing conclusions for future missions
Stratospheric missions – history and typical problems
Nowadays, missions using stratospheric balloons are connected with the space industry because the conditions in the stratosphere, especially in its higher layers, are very similar to those found in outer space. This means that by conducting experiments in the stratosphere, we can estimate the chances of success of a space mission with a high degree of confidence.
The stratosphere extends from around 10 km to 50 km above Earth’s surface, depending on latitude. It borders the tropopause from „below” and the stratopause from „above”. Temperatures there can fall even below -50°C, although above a certain altitude the temperature begins to rise, sometimes reaching values close to 0°C.
Another very interesting phenomenon is atmospheric pressure, which at these altitudes is almost nonexistent and reaches values of only a few hPa. Additionally, very low humidity and relatively high UV radiation intensity, combined with a high concentration of ozone, create ideal conditions for advanced experiments.
A device intended to collect data in such an environment must be resistant to external conditions, should provide communication for flight tracking, and should include a storage for saving environmental data.
Stratospheric balloons have been used for over a hundred years to study climate and collect meteorological data. The first balloon equipped with measuring instruments was launched at the end of the 19th century, in 1892, by Gustave Hermite. The balloon envelope was made of paper and filled with a mixture of hydrogen and methane.
This allowed the first measuring equipment to be carried into the atmosphere, consisting of a simple barometer and thermometer. A few years later, sending payloads with radio transmitters became standard in order to make payload tracking easier. Balloons also began to be made from more durable materials, such as rubber with special coatings designed to protect the gas from excessive heating caused by strong sunlight at high altitudes.
Since then, similar missions have become increasingly popular, as shown by the popularity of amateur stratospheric balloon missions today. Apart from amateur flights, payload flights organized by private and government institutions are also common, for example for forecasting climate changes.
At this point, however, it’s worth considering the problems faced by potential constructors and mission planners.
The first major challenge for payloads is temperature. As altitude increases, temperature decreases. It is generally assumed that this decrease is linear, around 0.6°C for every 100 m of vertical ascent. The temperature drop is especially visible in the tropopause. At our latitudes, the minimum temperature can reach around -50°C.
However, this temperature drop is not continuous. At some point, a rather unintuitive phenomenon occurs: the temperature begins to rise. This increase is caused by the absorption of solar UV radiation by ozone, meaning that ozone molecules absorb energy from electromagnetic waves. Since temperature is defined as the average kinetic energy of particle motion, supplying energy causes the temperature at those altitudes to deviate from the assumed model of decreasing temperature with altitude.
This does not mean, however, that we can send electronics sensitive to low temperatures without any protection. Apart from electronics, batteries are also very sensitive to low temperatures, which is why proper payload insulation is so important.
Another factor that must be considered in such missions is pressure. Atmospheric pressure at sea level is assumed to be one atmosphere, or 1013.25 hPa. Similarly to temperature, pressure decreases as altitude increases. Up to around 1000 m above sea level, this decrease is assumed to be linear, around 11 hPa per 100 m, after which it becomes exponential.
To understand why atmospheric pressure can be a problem, we need to understand what pressure actually is. It is the ratio of force acting on a surface to the area over which that force is applied – in this case, the force exerted by a gas mixture. Airtight payload insulation means that as altitude increases, a pressure difference appears between the inside of the payload and the external environment.
In this situation, the gas inside the payload pushes against its walls in an attempt to equalize the pressure difference with the surrounding atmosphere. In the worst case, this can lead to the payload losing its seal.
Another very important factor affecting mission success is real-time payload position data. While tracking the payload during flight may not be the most critical parameter, knowing its location becomes a priority once it lands – especially if the data collected during flight was not transmitted in real time but only saved to onboard storage.
That is why knowing the payload’s position is so important. The most obvious idea is to use a GPS module. However, if the constructor wants to track the payload throughout the entire flight, they must consider that many GPS modules available on the market have imposed limitations. The most common official reason for these restrictions is concern that such modules could be used in ballistic missiles – yes, those are the official arguments.
Despite this, there are modules available on the market that can operate reliably up to altitudes of 40–50 km, which is more than enough for amateur stratospheric missions.
This example shows that although collecting information about the payload’s position is possible, transmitting that data is a separate problem. One solution is to send data using GSM modules. They are easy to use, but they have one major drawback: the maximum altitude at which they can operate.
This is related to the angle of GSM antennas, and it is generally assumed that the upper limit for correct operation is around 10 km – and even that is a very optimistic assumption.
Another interesting solution is amateur radio modules or radio modems. A good example is APRS, or Automatic Position Reporting System. Choosing the appropriate transmission mode allows data to be received by nearby receiver stations and forwarded to its destination.
Radio modems, on the other hand, are specialized radio systems. They are available for both public and licensed bands, and there are many ready-made modules and systems available on the market. And then there is LoRa – but more about that, with a practical application, in the next project.
Payload description
First, I should point out that from the hardware side, the project wasn’t overly complicated. Much more work went into the software.
If I had to summarize the whole thing in a few sentences, I’d put it like this: the PCB schematic was created in EAGLE 9. The board was manufactured by an external company based on generated GERBER files. The microcontroller code, both for testing and for the full system functionality, was written in C using Atmel Studio 7.
To process the data saved in a simple text file, I created a C++ program using Code::Blocks. The entire payload was powered by a battery pack, with voltage stabilized using a simple linear regulator. An additional advantage of this regulator was that it converted excess power into heat.
The regulator powered all elements on the PCB, including the microcontroller, which managed the whole system:
- experiments and sensors collecting environmental data
- the SD card used for saving data
- visual and sound indicators used to locate the payload after landing
I hope this short description got you interested, so now we can move on to the details 😊
The whole system was managed by an ATmega32 microcontroller. It belongs to the still popular and well-tested AVR family, which was one of the reasons I chose it. Other reasons included ease of assembly, ease of programming, and a wide supply voltage range.
Available memory was also an important factor, since the project included SD card logging, and libraries of this type tend to be very „memory-hungry”.
The main purpose of the microcontroller was to manage and coordinate experiments and peripheral devices, as well as save data collected from sensors.
As mentioned earlier, the heart of the entire system was the ATmega32 microcontroller, clocked at 1 MHz and powered by a battery pack stabilized to 3.3 V. This value allowed all components to operate reliably and simplified the entire system.
And maybe someone will ask: why only 1 MHz? The answer is simple. First, the higher the clock frequency, the higher the power consumption. Second, calculations are very easy to do in your head at 1 MHz, for example when working with timers 😛
The microcontroller had to communicate somehow with perpheral modules. Most of them communicated with the microcontroller through the I2C bus, although a few used the 1-Wire bus.
The I2C bus requires only two data lines: SDA, or Serial Data, and SCL, or Serial Clock. All necessary information, such as addresses and data, is transmitted through these two lines. Importantly, they are bidirectional, meaning that both the microcontroller and a sensor equipped with such an interface can transmit and receive messages.
Apart from connecting these lines to the appropriate pins of both the microcontroller and peripheral device, two more things must be remembered: pull-up resistors and assigning or recognizing the device address.
Pull-up resistors must be connected to the positive supply voltage, which allows the line to remain high when no transmission or reception is taking place. In the case of addresses, it is important to assign an address to the device in advance, for example when communicating between two microcontrollers, or to check the datasheet, as manufacturers often assign fixed addresses.
Each device connected to the I2C bus can operate as either a transmitter, also called the master, or a receiver, also called the slave. Devices recognize each other using the aforementioned address, which also allows the number of microcontroller pins to be reduced, since multiple I2C devices can be connected to the same two shared lines.
The situation is different with the 1-Wire bus. Since it uses a single communication line, it is slower than I2C. For this reason, it is often used for communication between small devices where transmission speed is not a priority.
Apart from the communication methods listed above, one of the experiments used a 10-bit ADC converter with an external reference voltage. Additionally, the microcontroller was programmed with a watchdog reset system intended to prevent the program from freezing.
Hardware
As mentioned earlier, the heart of the system was the ATmega32 microcontroller. But even a heart needs blood to do its job. Just as the heart needs blood to function, a microcontroller needs additional components connected to it.
Below, I present these components together with a short description of how they were connected to the microcontroller responsible for controlling the entire payload. The whole system was divided into input and output circuits, along with the pins to which individual elements were connected.
Input circuits:
- sensors using the I2C bus: accelerometer, real-time clock, and pressure sensor – pins PC0 and PC1, corresponding to SCL and SDA
- sensors using the 1-Wire bus: temperature and humidity sensors – pins PD3, PD4, and PD5
- ADC converter with photoresistors connected appropriately for measuring light intensity – pins PA0–PA3
Output circuits:
- sound generator connected to pin PA5. Since the generator could take more current than the microcontroller pin could safely provide, a 1 kΩ gate resistor and an NPN BC547 transistor were added to control the generator and protect the microcontroller pin from excessive current. It was used to locate – or perhaps I should say “listen for” – the payload after landing using an audible signal.
- SD card used to save data collected during measurements and sent to the microcontroller
- LEDs connected to pins PB0–PB3. These were activated after landing to help locate the payload visually, especially after dusk.
It’s also worth adding the names of the modules responsible for measurements or other useful functions during the flight. Here is the list:
- DALLAS DS18B20 – temperature
- AM2302 – humidity
- BMP180 – pressure and altitude calculation based on pressure measurement
- ADXL345 – G forces in three axes: X, Y, and Z
- RTC DS3231 – real-time clock
- photoresistors – sunlight intensity measurement
Software
Since this post is not about learning programming, I decided to describe the software in just a few sentences, without going deep into programming details.
The code was written in C using Atmel Studio 7 and can be divided into several parts:
- main loop
- hardware settings, including registers, timers, and communication
- libraries
- functions
In terms of logic, it was mainly based on values provided by the external real-time clock mentioned in the previous section.
The main loop included an if statement that checked the seconds value provided by the clock. The logging frequency was 10 seconds. During each logging cycle, sensor measurements were performed sequentially: after one measurement finished, the next one started, until all environmental variables had been measured in a single cycle.
Each value was saved in a temporary variable, but to save time during SD card writing, all measurements from a given cycle were parsed into one buffer. The resulting “string” was then saved to the SD card.
This sequence repeated for about three hours. After that, to save energy, the microcontroller managed only the basic systems needed to locate the payload – sound and light signals. As it turned out, this was excessive caution, because the batteries used during the flight still had enough power for many future payload tests.
Testing
Testing is an inseparable part of creating new devices, machines, or even applications. It helps verify different behaviors and identify vulnerabilities to errors, and this case was no different.
The tests were intended to check whether the design assumptions had been met and whether the payload could survive the conditions it would face. Broadly speaking, the tests were divided into two categories: software and hardware tests, and environmental and durability tests.
In the second category, the biggest problem was the inability to simulate conditions found in the upper parts of the stratosphere, so I had to settle for improvised tests.
I considered the factors that could have the greatest impact on correct system operation: temperature below 0°C and humidity. To test this at home, the entire system was cooled down to around -25°C and then gradually warmed up, which caused water droplets to form on the PCB.
The test was repeated several times and each time the result was positive. This also confirmed the performance of the battery pack, since the same pack was used throughout the entire “freezing” period.
The second test in this category involved checking the payload for possible mechanical damage that could occur during flight or at touchdown.
The tests involved spinning the payload in different directions – by the way, the neighbors must have had a good laugh when they saw me waving a line from the second floor with a payload attached to it 😛 – and, to put it bluntly, shamelessly throwing the payload onto grass and concrete.
Modestly speaking, I have to admit I did a pretty good job, because everything worked flawlessly 😊
The second type of testing involved checking the software and sensors installed on the payload. The software created for the project had to meet several conditions. To verify correct operation, tests had to be performed in several areas:
- correct sensor operation
- correct data format in the buffer
- data logging at the defined frequency
- verification of SD card data writing
- saving data to the correct files on the SD card
The most difficult of these criteria to test was correct sensor operation. The test was performed by comparing values from several sensors of the same type, each responsible for the same functionality.
If the values were identical or close to each other, assuming environmental variables remained constant during the test, the sensors passed. One sensor of each type was then selected for the final project.
Another criterion required before allowing the payload to fly was the data logging format while maintaining the correct frequency.
As mentioned earlier, each individual environmental variable was first saved into one shared buffer in the correct format, and then that character sequence was saved as a single string to the SD card. Logging, along with environmental measurements, was supposed to take place every 10 seconds.
To verify the creation of a single data buffer while taking this time interval into account, I used a USB-UART converter. It allows data from the UART communication interface to be easily sent to a computer through USB. Communication in the opposite direction is also possible – sending a string of characters from the computer to the microcontroller.
To manage data received from the microcontroller on the computer, I used free software called RealTerm. It is a simple yet very functional tool that supports data exchange between a computer and a microcontroller.
In the case of UART-USB communication, it allows you to define the computer port to which the converter is connected, the baud rate, and the operation status. In the “Send” tab, you can also define a message to send from the computer to the microcontroller.
This makes RealTerm a very useful tool for testing both software and microcontroller communication.
For testing purposes, I created simple code for the ATmega32 microcontroller. Apart from the standard register configuration required for correct UART operation, an additional data stream was created and then connected to the function responsible for transmitting data.
In this simple way, I managed to modify the printf() function so that after calling it, its content was sent through the UART interface and then displayed in the RealTerm window.
The final stage of testing was checking correct SD card writing, both in terms of data correctness and saving data to the appropriate files.
Someone could notice and might ask why I used the word “files” in plural here. Well, writing to an SD card is not easy. I used an existing library, but I didn’t have enough time to fully understand it. After writing several dozen lines to one file, the next pieces of data would disappear.
So, improvising a bit – or rather, improvising heavily 😛 – I created several dozen files and saved data to them in batches, meaning a dozen or so measurements per file. Maybe not the most efficient or elegant solution, but better than nothing 😛
Summary
As you can see, there was a lot of work involved, but for me it was pure pleasure. I realize that many things were far from perfect, but on the other hand, it was the first time I had created a project that required involvement on so many levels and forced me to consider so many variables.
Of course, there were problems – often right at the very end.
The situation I remember most clearly happened the night before the trip to Toruń. Luckily, I wasn’t the driver, because I probably wouldn’t have made it there alive.
Around 11 PM, while doing the final tests and placing everything inside the payload enclosure, I brought a screwdriver too close to one of the components, close enough to cause an electric discharge. I even saw a tiny electric arc.
Something told me to test the electronics one more time, and that turned out to be the right decision. The whole system was completely out, and even replacing the microcontroller didn’t help.
So I made the decision to solder a second PCB – now I know it’s worth soldering more that one complete set of boards 😛
The result was that I finished at 6 AM, took a shower, and at 7 AM went to the university with the payload, sleeping at most for that one short hour while sitting in the bus.
A few other interesting things happened too, but that’s not what this blog is about.
In the next part, you’ll learn more about the flight preparations, the flight itself, and the landing. I invite you to the second part of the STAN ONE PROJECT 😊