Update 04.01.2022 to 09.01.2022

Last week, from Tuesday 4 January to Sunday 9 January, our focus was on completing the structure, circuit board and main software of the probe. For this we met partly in presence, while on other days we worked individually from home. By using our GitHub repository and some communication programmes, we were able to organise ourselves well. Unfortunately, we were not able to complete the CanSat before the end of the holidays as planned, because some orders for important components were delayed.

As far as the structure is concerned, we had the opportunity to manufacture the necessary metal parts for the lid and base plate of the probe. We chose aluminium as the material for these, as it ensures the required stability without adding too much weight to the probe. In addition, the use of aluminium in the hull had already proven itself in previous projects. There has also been considerable progress in creating a final structural design: Not only has the arrangement of the sensors and placement of the circuit board in the lower part of the CanSat been fully worked out, but we have now also been able to find a suitable solution for attaching the pumping system, especially the gas collection bags, to the outer hull. All in all, we will soon be able to finalise the planning of the structure and turn our attention to the construction of the entire system.

3D model of the probe without
the shell of the upper segments

In the illustration, aluminium parts such as the recently milled lid or the three threaded rods that hold the individual segments of the probe together can be seen in grey.

Immediately below the lid, in blue, is the pump system, consisting of three two-way valves and the air pump itself.

Above the orange segment at the very bottom, which is the outer shell of the lower section, is the circuit board and microcontroller, also in blue. On the right side of the orange area is the on/off switch. For the sake of clarity, the sensor system and the outer shell of the upper section of the probe are not included in this illustration..

Metal parts in manufacturing
Aluminium top cover

The planning of a preliminary board concept, optimised for the structural and technical requirements of our CanSat, was also completed at the beginning of the week. A cost-effective way to have this printed by a professional company is also already in prospect. However, we are still waiting for the expertise of a professional to have our design checked again.

3D model of the PCB during the planning stage

After we found out during the calibration of our sensors in December that the response times of our temperature sensor did not meet our expectations, we ordered a different type of sensor early on and got it working this week. Whereas before we needed more than a minute for temperature fluctuations of several degrees Celsius to be displayed to one decimal place, with the new sensor this happens almost directly within a few milliseconds.

Finally, we have begun to merge the individual programmes of the various components into the main software programme and to incorporate them into the main programme flow. This will require some tests in the near future, which are aimed at determining some time values for controlling the pump system.


Support from MediSense

For our secondary mission, we need three gas collection bags into which we can pump the various air samples. In order for us to get the most unbiased results possible, the bags must be resilient and sterile, so gas collection bags for laboratory use are particularly suitable.

e are very grateful that the Dutch company MediSense reduced the minimum order quantity from ten to six bags for us. This allowed us to use their Tedlar Bags with polypropylene valve for our CanSat. Thank you very much for your support!


Update 03.01.2022

After a somewhat longer break in December, we met again on Monday in Presence to continue working on our probe in the coming week and to complete it as far as possible. The main focus today was on soldering a first prototype for our board. The microcontroller and most of the wiring will be placed on this board to save space. However, since we were still working on the circuitry for the pump system and had difficulties with the soldering equipment, the completion of the board has been delayed.

Furthermore, we were able to test the recently ordered gas collection bags in connection with the pump system today. Thanks to the support of MediSense , we were able to obtain these special polypropylene-coated gas collection bags as private customers and in smaller quantities. Since it is essential for a precise analysis of the air samples that they are sterile, we first selected three bags for testing purposes and marked them accordingly. When starting the probe, we then use the remaining, completely unused and still sterile bags.

Testing of our airpump system

In addition, we directly tried out experimentally how the gas collection bags have to be attached to the outer shell so that they can unfold as easily as possible when inflated. The biggest difficulty here was not to exceed the maximum dimensions described in the requirements. We found a solution to the problem in the use of thin rubber bands, which fix the gas collection bags to the outer shell when unfilled and slip off them when filled. However, since the bags did not lie ideally against the shell during testing and we only had a 3D-printed test cylinder available for the test trials so far, we will have to optimise the concept a bit more.

As already mentioned in the last report, we noticed some errors in the self-test programme of the sensors. For example, it was planned that the readout of a sensor should be aborted if a certain period of time was exceeded in order to prevent the whole programme from hanging up in case of a loose contact. Although we have been able to detect such a timeout so far, we have not yet found a solution to cancel the function for reading out the sensor.


Update 02.12.2021

Thanks to the support of our project supervisor and physics teacher, Dr Schmidt, we were able to compare the sensors we had programmed in the past weeks with more accurate measuring devices for air pressure, humidity and temperature at our school. To do this, we carried out several series of measurements in which we read out the data from our sensors in parallel to the respective measuring device of the value being checked. Afterwards, we calculated an average value for each sensor read out and compared it with that of the more accurate measuring instrument as a reference value. In case of larger deviations from the determined guideline value, we can only use a corresponding factor in the software for the respective sensor to adjust the values obtained to those of the more accurate measuring instrument and thus simultaneously adjust all our sensors to each other.

As we were able to measure a high relative humidity of almost 85% outside today due to the rainy weather in Baden-W├╝rttemberg, which contrasted with the internal humidity in the school building of about 35%, no further experimental setup was necessary to obtain several series of measurements with different values. The calibration of the temperature sensors was also easy to manage at the frosty outdoor temperatures of 6┬░ C.

Measurement sequence indoors with all sensors
Measurement sequence outdoors with all sensors

For the air pressure, however, we relied on the use of a vacuum bell jar in order to obtain further values besides the 968 hPa at the height of our school. However, we did not have enough time for this, so we will complete the calibration of the air pressure sensor in the near future.

Air pressure measurement under the vacuum bell jar

Furthermore, during today's series of tests we noticed errors in the programme for checking the individual components, which we will correct in the coming weeks.


Update 21.11.2021

After surviving the first 2 weeks after the autumn holidays, we are really pumping away this Sunday. In the meantime, the test equipment for our air sample collection system has arrived.

To test our concept for collecting the air, we ordered an air pump together with switchable valves and a non-return valve, as well as several metres of hose.

The first test was of the pump itself, for which we tied a balloon directly to our air pump.

Here you can see the last moments of our test subject

However, since we want to collect three air samples from different heights, we still have some work to do: First, our probe has to calculate the flight altitude independently in order to then trigger the respective pumping processes. Since we have neither the space nor free weight for three pumps, we connect our tanks via three switchable 2-way valves. One burnt transistor later, we could reliably control the first valve:

Since we always try to uncover all possible sources of error in all construction stages, we conducted some experiments with our first valve. Among other things, we noticed that the switching process fails if one of the two outputs is under pressure, which is why we were able to adjust the configuration accordingly and thus avoid a critical error.

At the same time, we configured our motor driver. We need this so that our motor does not run from start to finish, as the Arduino can neither supply the required voltage nor the necessary current for a motor. By sending simple signals to the driver, it can, among other things, supply the motor with current that can be switched on and off, similar to a transistor.

If you've been following our development blog for a while, you may know that we used a larger development board called the Arduino Uno when programming our sensors, as this is perfect for developing due to the large pins. However, this board would take up too much space in our CanSat, which is why we use a smaller Arduino with a different chip architecture in our probe.

microcontroller size comparison

It may have been a mistake not to start with this architecture straight away, as we have now noticed that a library we used, which is effectively a driver for a sensor, does not work with the new chip. Rewriting the code took a whole morning of work, which could have been avoided.

After all the sensors were working with the new chip, we took a close look at the code that stores all the measurements on our two redundant SD cards, as the entire primary mission depends on it. When we noticed that the saving of files fails if there are already files on the memory cards, we were able to eliminate another source of error.

The programming of our sensors and processes will soon be completed, but we will continue to carry out tests and optimisations to increase reliability.


Update 04.11.2021

On Thursday we met again in Presence to continue the development of our CanSat. Now that we have completed the programming of the individual sensors, today we started on the software for the SD modules. With these, the collected data is redundantly written to two micro SD cards with 32GB data memory each. The redundant storage ensures that if a failure occurs with one of the modules, we will still be able to get data from the other data carrier after the mission and not go out empty-handed. The data is sorted into five different files per SD card for temperature, air pressure, humidity, acceleration and angular velocity, and given the respective mission time. Since we can read out some data, such as the temperature, several times via different sensor modules, we are currently still considering whether the increased measurement accuracy through several independent measurement series is worth it in view of a higher microcontroller load and possibly lower measurement frequency of the other sensors. However, we can only weigh this up after we have tested the entire system with all sensors and the SD modules.

SD-card-module programming

While one part of the team was busy with the data storage, other team members informed themselves about the composition and detection of so-called VOCs - gaseous substances of organic origin in the air. These are of great relevance for our secondary mission, as we will analyse our gas samples collected during the launch campaign for these using a KIT proton transfer mass spectrometer.

We also made progress with the structure of our probe and were able to construct a first CAD model of the lower part of the envelope. In this open area, the sensors will be located in order to measure directly in the ambient air and not inside our CanSat. Since we have not yet received the necessary components of the pump system for the gas collection bags, possible changes to the arrangement of the sensors must be taken into account.


Update 03.11.2021

The day before, we had already got three of four sensors working successfully, but we are not satisfied with that yet. Since a space mission places high demands on the reliability of the sensors, we installed several protective mechanisms in the morning to ensure success:

Before the probe is launched, it has to be transported a long way and loaded onto the launch vehicle. Both sensors and our cable connections can be damaged in the process. To guarantee that the probe launches fully functional, each of our codes includes a self-test in the initialisation, which warns the launch team in case of problems and thus prevents the launch of a faulty probe. The attached image shows the self-test for one of our sensors, where we explain the process in a simplified way in comments next to it.


Even if our probe launches fully functional, this does not mean that nothing can happen during the flight. The launch of the rocket loads the construction with up to 20G, and anyone who has ever had back pain after a roller coaster ride knows how much damage even just 3G can cause. To simulate the behaviour of defective sensors, we deliberately manipulated the connections to our sensors and observed the behaviour. In fact, we were able to identify several cases where a defect stopped our entire programme, for example because it waited in vain for the response of a non-existent sensor. By adding maximum waiting times for sensors, a defective sensor is skipped so that all other systems can continue to run undisturbed.

At the same time, the last sensor was programmed in the morning, which means that we can start writing our main code, which combines all our programs. This is necessary because a microcontroller cannot run several programs at the same time independently. To put it very simply, you can think of the main code as the operating system on a computer that allows you to run multiple programs at the same time.

In the photo of the main code below, we call up the functions in our individual programmes for the sensors, which, thanks to excellent communication within the team, all work according to the same scheme and have standardised names for excellent clarity. Now we set about connecting all the sensors at the same time, resulting in a bit of spaghetti cable nara.

Here all sensors were combined for the first time

At this point, our built-in self-tests have already paid off, as the controller has reported to us that the temperature sensor is inoperable. Some tests showed us that the temperature sensor works properly when it is running in isolation, from which we were able to deduce within a few minutes that there was interference between the codes on the connection we were using. In a very short time, we were thus able to control all sensors in one code, just as it happens in the mission. What makes our programme even more different from the final code is that we get all the values displayed on the computer instead of documenting them on two redundant memory cards.

Main code. On the left the measured values, on the right our main program

On closer inspection, it is also noticeable that the values of our four temperature sensors do not match. As soon as we have access to precise measuring devices, we can calibrate our sensors to them.


Update 02.11.2021

Our second day of work together began with setting up a 3D printer to print parts of the outer shell of our probe.

Along the way, part of the team started programming our sensors with the Rasperry Pi, but unexpected problems arose. For this reason, we decided to switch from the Raspberry microcontroller to an Arduino, with which more team members already had programming experience.

new Arduino-Microcontroller

After this change, we started programming most of the sensors and some of them already achieved very good readout results. While some members were busy programming, others continued to work on the 3D model of the shell and we were finally able to look at the first part printed out for testing purposes.

3D printer belonging to a team member
First 3D-printing-tests

Report 01.11.2021

On Monday, 01.11.2021, we met to continue the planning of our CanSat and to divide up the work assignments.
First we unpacked all the parts that had arrived and sorted them.
Then we went through our Second Mission again and made a detailed plan for our valve system.
As these parts had not yet arrived, we could not continue working on them and could not carry out any tests with the pump and the valves.
So we created a Github repository to distribute and organise all the tasks that could be done.

Raspberry Pi pico

While one part of the team prepared the microcontrollers so that the sensors could be tested, other team members looked more closely at the structure of our probe and constructed an initial concept for the outer shell, which is to be divided into a structure of several floors so that changes can be incorporated more easily and with less material.

en_GBEnglish (UK)