I am pleased to announce that April 28th we had a successful flight, and it was almost perfect! Despite that the weather was not the dreamed one…
We launched from Zagaje Niegosławskie (50°32'54.3"N 20°20'40.5"E) at 8:30 a.m. Weather conditions were really bad, it was raining and started to be windy - we even thought about aborting the mission. Luckily, the wind calmed right before the launch. Total mass of the whole balloon payload was about 1.5 kg, we used 2000g balloon model and it was filled with hydrogen.
Electronics also caused some trouble - the camera disconnected inside the capsule twice. When we finally connected it properly it unfortunately disconnected after a couple minutes of flight and one whole module of communication failed by the error in the code. A blessing in disguise - it gave us enough time to take one photo from the on-board camera, but it was not able to transmit it via SSTV anyway
The photo taken during flight, as the weather was really bad we mostly can see the clouds in which a balloon flew.
One of biggest surprises for us was the apogee of the balloon - we flew to over 33 km! From this altitude we received our last APRS frame, but we think that apogee could be even higher as the other sensors measurements show even 38 km and at this altitude balloon flies up really fast. If it is true it is the biggest altitude our team have ever reached, so we think this is a big achievement, specially in those weather conditions. It is worth to know that Polish record is 43 km so we definitely want to fly even higher in the next year
About the experiment:
Surprisingly, all honeybee queens onboard came back to us alive. At first moment we thought that at least one of them is dead, but then it appeared that all of them just hibernated due to the low temperature. By now, correctness of queens reproduction is examined by PhD student from Polish Academy of Sciences and qualified beekeepers from apiary we cooperate with - Pasieka Szeligów.
Honeybees in queen mailing cages day before launch
Honeybees after balloon recovery
Before launch, we made couple of simulations, which showed us potential landing zone. Real flight path was very similar to the simulation, as it can be concluded from the following images.
Balloon flight path - simulation:
Balloon flight path - real-life:
Gondola of the stratospheric balloon:
Gondola was made of xps styrofoam 30mm. This material gave us good thermal isolation and xps is very lightweight material. Gondola was designed as maximally modular. This concept gave us opportunity for fast assembling mechanical parts with electronics. All parts were made with tight fitting, so there was no need for glue, what allowed to avoid additional weight.
Two separate and independent systems were responsible for position reporting. First of them was Vaisala Radiosonde RS41, a very commonly used system amongst high altitude balloon missions. RS41 is based on STM32 microprocessor and is capable of transmitting its geographic position, altitude and temperature inside it via APRS and RTTY transmissions. Both of said transmissions were used, and the radiosonde has been configured to carry them out on amateur radio frequencies, which we were able to use thanks to one of our team members being licensed amateur radio operator.
Second systems responsible for position reporting, controlling onboard camera and transmitting images via SSTV protocol was our custom made PCB called Capybara 1.0. The system is based on Raspberry Pi Zero v1.3 microcomputer, which is responsible for image capture, storage, converting images to waveform audio format, controlling RF transmitter module (switching between APRS and SSTV frequencies), gathering data from GPS module, generating APRS (AX.25 AFSK) frames, and piping SSTV and APRS data as audio to RF transmitter module. Ublox NEO 7M GPS module was responsible for GPS/GLONASS data reception and providing it to main microcomputer (RPi Zero). Dorji DRA818V module was responsible for transmitting data on amateur radio frequencies. As both DRA818V and GPS module required UART communication with RPi Zero, and the microcomputer has only one hardware UART interface, we had to somehow overcome this problem. A decision has been made that because DRA818V needs two-way UART communication it will be connected to RPi’s hardware UART, while data from GPS module will be received via software UART provided by Python “pigpio” library utilizing one of RPi’s GPIO pins. In this configuration all systems work seamlessly. Unfortunately, mid-flight, due to high levels of condensation, heavy rain and overall bad weather conditions, the system has been damaged most probably by short-circuit formed by condensed water, and stopped working. During post-flight analysis it has been established, that the system worked seamlessly before the incident.
This PCB is responsible for data acquisition from several sensors such as barometer MS5607, UVC diodes, and humidity, temperature, CO2 sensor placed on one board called SCD30. Measurements are gathered on external Flash memory. The hearth of the PCB board is STM32 microprocessor.
Fig. 0: BeeLogic PCB board
The aim of the research was to examine how the extreme conditions have an impact on the bees. Taking it into consideration, two these same boards were created. One of them was placed in the balloon and the second one as a reference subject, on the Earth.
SCD30 sensors were placed next to the honey bees, to measure the conditions that surround them, CO2 concentration could be used as another parameter to determine the bees stress level.
Fig. 1: Pressure change over the time of research graphFig. 2: Altitude change over the time of research graphFig. 3: Humidity change over the time of research graphFig. 4: Temperature change over the time of research graphFig. 5: CO2 change over the time of research graph
All of the graphs seem to be sensible without the last one - CO2 chart. As we can see, the initial value of CO2 concentration is 40000 ppm, it is the maximum value that this sensor (SCD30) can measure.The possible explanation of this issue is because of high humidity and bad weather condition. It is possible that water could have condensed on the sensor and had an impact on its measurements.
UV-C radiation intensity sensors:
A custom PCBs were designed to obtain measurement of UV-C radiation intensity.
Each of them consists of:
1. Transimpedance amplifier,
2. SG01S-C18 photodiodes (designed for purpose of measuring UV-C radiation),
3. Power supply block,
4. Signal filtering block
On each of the PCB’s there are 2 different measurement paths. Each of them has a different gain (we didn’t know what levels of radiation we should expect on 30-40 km of altitude). Therefore, one measurement path has a “low gain” amplifier and a second one a “high gain" one. Because of that we were able to measure wider range of UV-C radiation intensity. We’ve been trying to design AGC (automatic gain control) for this sensors, but we haven’t got enough time to finish the R&D process. The main idea was to check the level of the signal with internal ADC integrated in to the microcontroller and automatically adjust the gain according to this signal (In the way that the amplifier won't be overdriven / output signal won’t be too small ). In the end, instead of using AGC, permanently set gains were used as described above. Amplified signals were connected to the “BeeLogicPCB” for data acquisition with a bunch of wires and connectors. Analog signal was filtered with a low-pass filter before entering the ADC (just to cancel out some high frequency noise). After sampling, the data was saved to the FLASH memory located on the “BeeLogicPCB”.
One UV-C radiation sensor was placed on the top of the gondola and the second one on the bottom of it (in order to measure how much of this radiation is being reflected by the atmosphere).
The high gain measurement paths have been overdriven (you can see it on the charts), because of that this data is almost useless. Additionally, they might have been affected by the water / high moisture and low external temperature. That’s the most probable explanation of a strange behaviour.
But on the other hand the low gain paths worked flawlessly.
We’ve measured about 1.4 uW/cm^2 of UV-C radiation intensity at the bottom and about 5.5 uW/cm^2 at the top ( radiation intensity remains almost the same during the whole flight).
The radiation levels raised for a short period of time after the landing and then started to drop quickly, the most probable explanation for that is the photodiodes and amplifiers might have got frozen during the flight. After landing they were slowly warming up – that might cause this strange behavior (semiconductors are very sensitive to temperature changes, especially “analog” ones).
The UV-C radiation intensity started to rise very fast at about 3-4 km of altitude. At higher altitudes the intensity of the UV-C radiation remained stable with a tendency for a slow growth.
The charts were generated with MATLAB software after some data processing (mainly noise reduction):
Geiger counter (Beta and Gamma radiation measurement):
Just like in the UV-C radiation sensor, custom PCBs were designed to obtain measurement of Beta and Gamma radiation.
Geiger counter PCB consists of:
1. Power supply block (including high voltage DC-DC converter),
2. Main microcontroller STM32F401RBT6,
3. Analog signal conditioning block (amplifiers, comparators ,etc.),
4. STS-5 geiger tube,
5. SD card used for data saving,
6. Barometer and temperature sensor (MS5607)
Additionally there were a GPS-logger module connected together with the Geiger counter (it was connected to the same battery).
The microcontroller was responsible for several tasks:
1. Calculating radiation levels,
2. Controlling the high voltage DC-DC converter (to maintain about 450V at the tube terminals needed for the correct operation of the whole device)
3. Saving data logs to the SD card through SDIO interface,
4. Monitoring battery voltage,
5. Measuring the pressure, temperature and calculating the altitude independently from other systems
Everything was powered from a standard 9V battery (GPS module and the Geiger counter).
Everything was working flawlessly during the flight, but unfortunately a ‘small problem’ appeared, because of which we’ve lost most of the data from the GPS and Geiger module. Battery which was powering these modules was dead after a short period of time. Voltage dropped so quickly that the Geiger counter module stopped working about 2 km above the ground.GPS module was alive for a little longer (about 24 km of altitude) because it needed lover supply voltage than the Geiger counter.
The most probable explanation for this issue is that there must have been a short circuit inside the SD card socket caused by the water (after the balloon landing we’ve found a lot of water/moisture inside the SD card slot in the Geiger module).The weather was very bad, it was raining (the water might have found a way to the inside of the gondola during the flight). Another possible explanation is that the air moisture was very high and the water started to condense on the PCB during the flight (the temperature was dropping quite quickly despite thermal insulation of gondola).
Unfortunately 2 km of altitude was not enough to obtain satisfactory radiation measurement data (as you can see on the charts down below, average radiation levels stay the same all the time).
Abbreviations on the charts:
1. CPM - counts per minute,
2. CPS - counts per second,
3. CPL - counts per log,
4. CPM pred - A CPM value “predicted” from the time between counts
GPS module charts:
Unfortunately as described before, GPS battery died at about 24km of altitude due to short circuit in the geiger module.
see you in space