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.

sensortesting

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.

en_GBEnglish (UK)