apex Mk.2/Mk.3: Secure Live Transmission of the First Flight of Trichoplax adhaerens in Space Based on Components Off-the-Shelf

Abstract

After the successful flight of the first Advanced Processors, Encryption, and Security Experiment (apex) Commercial Off-the-Shelf (COTS) On-Board Computer (OBC) during the Propulsion Technologies and Components of Launcher Stages (ATEK)/Material Physics Experiments Under Microgravity (MAPHEUS)-8 sounding rocket campaign, a second generation of COTS OBCs were built, leveraging the knowledge gained. This new concept and improvements are provided. The Mk.2 Science Camera Platform (SCP) has an instrumented high-definition science camera to research the behavior of small organisms such as Trichoplax adhaerens under challenging gravity conditions, while the Mk.3 Student Experiment Sensorboard (SES) represents an Arduino-like board that directly interfaces with the MAPHEUS Service Module and allows for rapid development of new sensor solutions on sounding rocket systems. Both experiments were flown successfully on MAPHEUS-10, including a biological system as a proof of concept, and paved the way for an even more capable third generation of apex OBCs. This study is part one of a three-part series describing the apex Mk.2/Mk.3 experiments, open-source ground segment, and service module simulator.

1. Introduction

Gravity has been, and will remain, the only constant stimulus that has shaped life on Earth since the beginning. To investigate the influence of gravity on life and its processes, ground experiments under simulated weightlessness and increased gravity, as well as experiments in real microgravity, are carried out. In addition to drop towers, parabolic flights, satellites, and space stations, sounding rockets can be used to achieve several minutes of real microgravity for carrying out experiments under these conditions. The experiments conducted here were performed as part of the German Aerospace Center’s MAPHEUS sounding rocket program. A wide range of experiments [1] in the fields of physics, materials science, and life sciences [2] have been performed via unmanned vehicles. In addition to being able to carry out experiments for several minutes of high-quality microgravity (range ${10}^{-6}$ g), the MAPHEUS-10 rocket flight also demonstrated that our hardware components are suitable for sub-orbital or orbital use in Low Earth Orbit (LEO). Because the altered gravity conditions, vibrations, vacuum, and slightly increased radiation may all have an effect on the system tested for usability in space, sounding rockets are ideal for conducting pre-cursor experiments. COTS technology is increasingly being used to minimize costs and development times. In addition to 3D printing and the use of commercially available processors and sensor systems, we have demonstrated that the successful application of COTS technology is a reliable method for setting up sub-orbital life science experiments in space.

In addition, secure transmission of video, image, and sensor data to the Internet during the rocket flight was carried out [3]. This manuscript focuses on the technical structure and realization of the software for this experiment.

Both the sensor systems and the sample environments need to be designed to maximize reliability and scientific output while minimizing the space, weight, and energy consumption needed. Regarding the sensors, previous experiments used old flight-proven components designed for use under space conditions. While reliable, these systems involve higher energy consumption, limited processing power, and a copious price-tag. During the last apex experiment, it was proven that cheaper, more powerful, and more easily obtainable components sourced from the industrial and automotive sector could be successfully used to build experiments that are smaller, lighter, more energy-efficient, and higher-performing—while remaining less expensive than their space-proven counterparts [4]. While the first apex experiment included both a Raspberry Pi Zero W (RPi) and two Espressif Systems ESP32 development boards, these different computing domains have now been split into two separate experiments. The apex Mk.2 SCP (see Figure 1) uses the aforementioned RPi to provide an instrumented camera platform to the Trichoscope—a life-sustaining microscope designed to record single-celled and multicellular organisms under microgravity conditions. This setup serves as the focal point of the present study. The apex Mk.3 SES (see Figure 1), on the other hand, uses a single ESP32 module to allow students and researchers to quickly build their own experiments to be flown with the MAPHEUS sounding rocket while still having easy access to power, telemetry, telecommand, and signal lines provided by the rocket’s service module.

The contributions and novelty of our work are summarized as follows:

• The consequent use of COTS technology and 3D printing to build both experiment platforms, whose OBCs adhere to Consultative Committee for Space Data Systems (CCSDS) standards.
• A Telemetry (TM)/Telecommand (TC) subsystem with integrated hazard-gating.
• Secure live-video transmission of a life-sustaining microscopy system.
• Integrated microgravity detection for increased independence from the service module.
• First flight of Trichoplax adhaerens.
• Successful proof of concept under real space conditions.

To contrast these contributions with those of our peers, recent open hardware platforms combine microfluidics and live microscopy under altered gravity, enabling real-time phenotyping during flight [5], and show a trend towards open, modular, and live video microscopy systems. This aligns with our work and clearly separates it from other modern miniaturized microscopes that achieve the same level of sustained in-orbit live-cell imaging—but rely on rack-level infrastructure [6]. Autonomous bio-CubeSats with integrated microfluidics have flown in LEO, validating long-duration unattended operations [7] for biological payloads using OBC systems. Similar approaches have been extended beyond LEO by our peers, showcasing deep-space biological nanosatellites for biosensors [8]. This also emphasizes the validity of OBC systems in conjunction with TM/TC systems adhering to CCSDS space packet standards [9], as showcased by their use in International Space Station (ISS) operations [10,11] and also employed in our contributions.

Remark: This study is part one of a three-part series describing the apex Mk.2/Mk.3 experiments, open-source ground segment [12], and service module simulator [13].

2. Materials and Methods

2.1. System Design

Starting off with the simpler system, the Mk.3 SES ESP32 was used in the original apex to provide the instrumentation to the original camera system: two Espressif ESP32-PICO-D4 (Shanghai, China) MCUs each having their own 32 GB $\mu$SD card, card interface reset circuitry, an internal SPI Flash Filesystem (SPIFFS) memory as low-frequency emergency data recorder, and a synchronization bus. This allowed for redundant sampling of the Inter-Integrated Circuit (I2C) sensor bus and recording environmental data like temperature, humidity, atmospheric pressure, acceleration, magnetic field, and rotation.

After the inaugural flight, recorded data showed that both MCUs sampled the same amount of data, logs on both the 32 GB $\mu$SD cards and internal SPIFFS memory were intact, and the $\mu$SD card interface reset circuitries were never triggered as no error occurred. This led to the conclusion that the resilient design worked as intended, but, for more cost-effective missions, a single Microcontroller Unit (MCU) with its own $\mu$SD card and internal SPIFFS memory would be sufficient.

With that, the overall system was simplified to a single Espressif ESP32-WROOM-32U (Shanghai, China) module (240 MHz, 32 bit dual core MCU with multiple cryptographic extensions and an additional “Ultra Low Power” co-processor, 520 KB of RAM, 4 MB of Flash) and a 32 GB $\mu$SD card.

Additionally, a Low-Dropout (LDO) regulator, optocoupler, and RS422 converter were added. This allowed the new module to directly connect to power, signals, and TM/TC interfaces of the MAPHEUS Service Module, making the SES independent from its former mother payload. The reason for SES development lies in a request by the German Aerospace Center (DLR) Institute of Space Operations and Astronaut Training (RB) to create an Arduino-compatible board that could be used under microgravity conditions for training university students, small experiments, and qualification of sensor modules. SES achieves this by providing an open sensor bus, consisting of I2C, Serial Peripheral Interface (SPI), Universal Asynchronous Receiver/Transmitter (UART) and General-Purpose Input/Output (GPIO) connectivity, and a 3.3 V power interface—thus enabling rapid prototyping of simple experiments in a matter of hours. For a detailed overview, please see Figure 2.

As an example, during the MAPHEUS-10 flight, SES was flown with the same environmental sensors already used during the initial campaign on MAPHEUS-8 but without a Real-Time Clock (RTC). As a reference to real world time, milliseconds since power-up of the board were recorded and used after the flight using the logged MAPHEUS Service Module signals.

The Mk.2 SCP continued the tradition of the original apex project by focusing on real scientific application rather than just a technological demonstration, serving as the direct successor to the original camera subsystem. While it was still using the original small, lightweight, low-power, and high-performance Linux Single-Board Computer (SBC) RPi, Mk.2 performed significantly better due to changes regarding the Operating System (OS) used and overall composition of the payload. Starting with the signals and power system, both the flight-proven optocoupler for the service module signals and the DC/DC converter stages were re-used. However, other instrumentation changed: the original apex used multiple resistor dividers and a multichannel Analog–Digital Converter (ADC) to read out voltage levels. This had the drawback of lacking information about current consumption and thus missing overall power draw. To rectify this situation, Mk.2 replaced said ADC with power-gauges for the 5 V and 3.3 V power buses to allow for more precise monitoring of its power consumption. The resulting data was fed into the RPi, which now also directly ingested data of the environmental sensors previously handled by the redundant ESP32 configuration. This made Mk.2 directly and independently aware of its situation, which later proved to be of vital importance during the challenging MAPHEUS-10 campaign and its cold environment. To allow for more flexibility, Mk.2 also presented an open I2C bus in the form of an expansion slot that could accept different sensors to be retrofitted in the field. This could be used if additional sensors needed to be carried to space for certification or additional sensing capabilities were needed to improve scientific output of the specimen under observation (see Figure 3).

Having direct communication between the SBC and the I2C bus allowed the improvement of the operator handling of the system: A full Red–Green–Blue (RGB) Light-Emitting Diode (LED) with its own MCU and watchdog were added to show the current operations mode in an easily recognizable way (a more detailed schematic of the system composition can be seen in Figure 2). With that, it was possible to distinguish if the Mk.2 was currently recording video data, resetting from a recording, or waiting for a signal to start the next observation phase. Having this feedback tool to interact with the operator during ground reference experiments led to adding additional jumper pins to trigger different functionality upon boot of the system. The original apex contained a jumper to allow the system to boot and erase its internal memory as a means for quickly resetting internal memory before start of a campaign—but had no possibility to show success or error to the operator. Mk.2 took over this DEL jumper and added error and success codes to its RGB LED system to improve the experience. It also elaborated on the overall workflow by adding an additional Transfer (XFER) jumper, which allowed the operator to prompt the Mk.2 to download all internal data onto an external Universal Serial Bus (USB) flash drive. With both those workflows in place, an operator in the field was able to download all the collected scientific data and reset Mk.2 with nothing more than a power source, flash drive, and jumper cable, as presented in Figure 4. Among those two operator jumpers, a third one called Hazardous Commanding Switch (HAZ) was added and hints at the largest improvement—the added TM/TC subsystem.

While the original apex would have been able to talk to the MAPHEUS Service Module, this was not implemented due to the late addition of the payload to the launch manifest as well as an oversubscription of the service module. However, Mk.2 improved upon this by adding its own CCSDS-compatible TM/TC MCU and multiplexer. It also included a live video output to allow for direct downlink of a Phase-Alternating Line (PAL) preview video signal of the camera input via the service module. The video provided the scientist the advantage of judging the overall health of the specimen in real time. Meanwhile, the supplied environmental data via TM was beneficial for informed go/no-go decisions in challenging mission scenarios.

The TM/TC subsystem itself was a 32 bit ARM Cortex-M0+ Microchip ATSAMD21G18 MCU (Chandler, AZ, USA). It had access to the Mk.2 RPi Zero W (32 bit ARMv6), an Mk.2 MCU payload simulator (8 bit Microchip ATTINY85), and the Mk.3 payload (ESP32 with 32 bit Tensilica Xtensa LX6 Cores) via an added multiplexer. As mentioned, the complete communication was achieved using CCSDS-compatible space packets [9]. This allowed for easier integration into current Mission Control Software (MCS) systems and to improve the reliability of communications. An extensive mix of different system architectures were used to prove that the developed firmware was architecture-independent.

The TM/TC subsystem was the main communications endpoint, serving additional uses: in case of issues, it had the capability to reset the payload simulator, RPi, and multiplexer on-board the Mk.2. The last but also most important function was that of a communications filter, which allowed the correct implementation of hazardous commanding capabilities.

In a space context, hazardous commands are TCs that might endanger the safety of an experiment, subsystem, payload, overall mission, or even human life. TCs can be hazardous by design or become hazardous depending on the situation. A good example of this is the reset of the Mk.2 RPi subsystem. While a simple reboot of the system on the ground might be an inconvenience, an accidental reboot during the microgravity phase of a real flight would mean loss of data. In case of an error with the RPi, the reset of the system might be the only chance of recovering the experiment to a functioning state, so there needs to be a way to trigger such a TC—here called “soft” hazardous command—by secure means. Other commands are only allowed during lab operations—for example, enabling radio communications of the RPi, which will be needed for synchronization of the dedicated RTC module or debugging purposes but never allowed on rocket; this would be a “hard” hazardous command.

In this solution, “soft” hazardous commands can be allowed by adding an additional bit flag before sending the command. On the operator displays, this is completed by using a toggle switch that needs to be armed before sending a “soft” hazardous command and resets automatically after each command. The TM/TC MCU checks on orbit if the command has any hazardous significance and whether the appropriate bit was set. If so, it forwards the TC to the receiver; otherwise, it rejects it with an error TM. The same principle applies for “hard” hazardous commands; however, there are two toggle buttons that need to be armed within the command displays, and the physical HAZ jumper on the Mk.2 must be in place. This is only the case during lab operations. Afterwards, the “Remove before flight” tag is pulled and the Mk.2 TM/TC system will reject any “hard” hazardous commands.

During regular operations, the TM/TC MCU was also used for quick ping tests and had a primitive scheduler that started acquisition of science TM of the Mk.2 RPi 45 s after initial power-on at pre-configured data rates. Other than reset or similar commands, the hazardous command system also allowed to adjust the illumination of the microscope, start/stop camera recording, or force the OS on the RPi to write any pending filesystem changes to disk.

Regarding the OS, the original apex used balenaOS, a specialized Linux OS that hosted the camera application and RTC functionalities within Docker containers. The downside of this decision was the small resource overhead needed to host those containers—and the larger resource requirements for balenaOS’s own management features. While this was still negligible during the first campaign, later iterations of balenaOS became more resource hungry due to advanced functionalities written in Node.js, so this choice was not feasible anymore. The switch was made to another open-source alternative, Yocto, which allowed to build a custom OS that left more resources to the actual application. By disabling all non-essential services and only running the Secure Shell (SSH) daemon, initial RTC synchronization, and the apex Python 3 application, we could achieve reliable and repeatable boot times of 30 s.

As storage media for both Mk.2 and Mk.3, Samsung Evo Plus $\mu$SD cards were chosen, as during the first campaign, due to their use during the ISS AstroPi program [14] and their X-ray-proof, waterproof, and magnetism- and heat-resistant design.

Both payloads used printed Fused Deposition Modeling (FDM) spacers and structural parts that weighed less than 190 g combined, excluding the Trichoscope (microscope). All of them were mounted to the carrier plate (see Figure 3) within the MExA container (see Figure 5).

2.2. Resilience Design

As with the first mission, resiliency of the created payloads was of utmost importance to safeguard against any loss of science or degradation thereof. Thus, most of the already flight-proven systems stayed untouched, with the exception of alterations caused by the changed mission. As an example, the previous dual redundant ESP32 system in ACTIVE–ACTIVE configuration was changed to a single controller since the experiment platform Mk.3 will be used in the future for student experiments that do not warrant such high availability.

The previous mission revealed that the first apex had shortcomings in regard to power monitoring and system status indication. The first issue was resolved by including power monitors for both internal voltage lines; the latter was addressed by adding the RGB LED and the implemented Watchdog, indicating the current mode of operation of Mk.2 at all times. To allow for more insights, the newly added TM/TC subsystem automatically started forwarding Mk.2 TM towards ground 45 s after power-on, also delivering housekeeping data. All sent TM and TC using the CCSDS space packet standard and a Cyclic Redundancy Check (CRC) to detect and disregard data and commands that were damaged during space-to-ground downlink and uplink. The TM/TC MCU was also allowed to reset all important Mk.2 subsystems in case of errors in a secure way, using the previously described hazardous commanding system.

During the first mission [4], the Rotation of Paramecium Under Microgravity (ROPUM) microscope’s illumination was powered by apex but with no ability to alter the illumination strength. This was changed with Mk.2, which could change or disable illumination during flight if the need arose. In addition to the TM on the environmental status, Mk.2 also introduced live video from its camera using a downlink channel of the service module. This allowed the scientist to see the specimen in real time.

Despite all the new possible ways to interact with the experiments, these were just added features, not necessities. All necessary signals were sent by the service module—and, even in a worst-case scenario (no signals arriving from the service module anymore after starting camera, except power), Mk.2 and Mk.3 would still have been able to complete the mission without loss of science. However, stopping the recording via removal of the Start of Experiment (SoE) signal and the introduced filesystem synchronization improved the reliability of data recording. The change to Yocto OS allowed for more fine control over running services and included increased functionality, which freed up resources, reduced boot time of the Mk.2, and still retained the resiliency of a read-only OS. Since the Polylactic Acid (PLA) FDM-printed support structures had proven successful during the last campaign, they were implemented again. However, the overall design of the circuitry moved from the more delicate hand-wired eurocard prototype board to manufactured Printed Circuit Board (PCB)s, which were subsequently populated by hand and stabilized using two-component epoxy for added robustness.

2.3. Experiments

Gravity is a fundamental force that affects all aspects of life on Earth. From the orientation of plants and animals to the development and functioning of entire organisms, gravity plays a central role in shaping biological systems. However, the mechanisms underlying responses to gravity are not yet fully understood, and conventional model organisms have severe limitations when it comes to studying these phenomena.

To identify the most fundamental rules of sensing gravity and its impact on building and repairing tissue architecture, we have turned to the simplest metazoan animal on Earth, the placozoan Trichoplax adhaerens, which represents a living surrogate of the first multicellular animal [15,16]. The first placozoan species, Trichoplax adhaerens, was discovered in 1883 by the German zoologist Franz Eilhard Schulze in a seawater aquarium at the Zoological Institute in Graz, Austria [16]. The species name is derived from the Greek “thrix” (hair) and “plax” (plate) and the Latin “adhaerens” (sticking). Trichoplax is therefore affectionately known as the “sticky hairy plate”, a body plan that is by far the simplest of all multicellular animals (except for some secondarily reduced parasites).

After studying Trichoplax in some detail, Karl Gottlieb Grell found that this animal cannot be grouped into any of the existing phyla, and he designated a new phylum, “Placozoa” for Trichoplax [17]. For almost half a century, Placozoa was the only monotypic animal phylum, and just recently three more placozoan species have been described [17]. In addition, several genetically deviating strains are awaiting their formal description [18].

Trichoplax is a very promising model system for gravitational biology research. It consists of a few hundred to a few thousand cells and has less than ten morphologically distinguishable cell types [19]. The cells are organized in a simple sandwich-like body plan: a lower epithelium facing the substrate and an upper epithelium facing the open water. Placozoa lack any kind of body axis or permanent symmetry but show a clear top–bottom polarity [20]. They have no organs, no nerve or muscle cells, no extracellular matrix, and no basal membrane. Therefore, the nine identified somatic cell types [17] perform all functions of nutrition uptake, stimulus perception, locomotion, and reproduction.

Despite the animal’s extreme simplicity, its genome contains both all the major gene groups fundamental to instruct body plans in “higher animals” (Bilateria) and the major signaling pathways found in humans, although with less complexity [21]. With its genome sequenced and the availability of gene silencing tools such as Ribonucleic Acid Interference (RNAi), Trichoplax represents a novel model organism with tremendous scientific potential to unlock the most fundamental processes underlying the effects of gravity on multicellular life. Importantly, due to its small size, aquatic nature, and robustness, Trichoplax is also an ideal model animal to examine these questions in a space-based environment.

Trichoplax can survive in a wider range of environmental conditions than other model cell systems that need higher temperatures and complex media. The first use of Trichoplax as a model organism for gravity research already delivered promising results, where they exhibit different responses to changes in gravity [22]. By elucidating the underlying molecular and physiological mechanisms, we can gain valuable insights into how gravity affects the basic functioning of biological systems at different levels.

In summary, Trichoplax adhaerens provides a unique and exciting opportunity to explore the intricate relationship between gravity and life. Its simple genetic and morphological structure, simple cultivation in small life support systems, and distinct responses to changes in gravity make it an excellent model system for studying the effects of gravity on living organisms. For this purpose, a small microscope (the Trichoscope), described below, was developed to record the movement behavior of Trichoplax by means of video recording. In addition, these data were transmitted live to the Internet for the first time in the MAPHEUS project. The model organism was cultivated under standard conditions. Approximately 35 individuals were washed twice with sterile filtered artificial seawater and inserted into a stainless steel glass cuvette (see Figure 6 and Figure 7).

As with the first apex, Mk.2 and Mk.3’s main purpose for their flight was to flight-approve the overall systems, changes, and gather scientific data via the Trichoscope. The Trichoscope is an FDM-printed frame, holding an optical cell that was used to conduct behavioral studies under microgravity environments using the Mk.2 camera. Additionally, the Trichoscope was supplied with a TC-controllable LED for illumination and uses a heating foil, temperature sensor, and control circuit to keep the specimen under testing at a constant temperature. The same control circuit also logged the optical cell temperature for later analysis. The overall system was designed in that way so it could be operated toolless.

Due to the nature of the used rocket motor configuration, use of accelerometers was allowed; however, recording of said data was only agreed upon after start of microgravity. This phase was announced by a service module Signal (here Start of Data Storage (SoDS)), or could be sensed by accelerometers without recording. With the Mk.2 possessing its own accelerometer and gyroscope, their data was used to allow for offline microgravity environment sensing. The data acquired by the very conservative detection method could be compared with the real data and the method used in future apex systems to allow for higher independence of the service module or to free up signal lines.

Among the other experiments on Mk.2 was a thorough checkout of the TM/TC MCU, the Telemetry multiplexer, and their attached systems, e.g. the Mk.2 RPi, Mk.2 payload simulator, and the Mk.3—as well as tests of the hazardous commanding system. This was facilitated by commanding the subsystems from ground after launch mid-way to apogee, at apogee, and mid-way to landing again.

The utilized apex ground segment, based on open-source technology, securely connected the relevant experiment TM/TC data streams from the science network in Kiruna, Sweden, with virtualized servers in Cologne, Germany, where all data was processed and sent back to Kiruna for use. Using this method, we were able to test a secure remote commanding concept that simulated the experience of a scientist working remotely at a distance of over 2000 km from Cologne. To measure the mean time between the time a remote scientist issues a command and the time a response is received, 10 ping commands were issued during flight alongside other test commands. Remote video of the Trichoscope and the Swedish Space Corporation (SSC) Countdown Clock were also transmitted like the TM/TC data streams in a secure way.

Additionally, the Mk.2 RPi carried 34 MB of randomized test data with pre-computed SHA256 checksums to check for memory corruption after return.

3. Results

MAPHEUS-10 launched on 12 December, 2021 at 09:07:00 (CEST) from SSC’s Esrange in Kiruna (Sweden). During the flight, 370 s of microgravity was achieved (roll rates < 1.0 °/s; altitude > 90 km). Both the Mk.2 and Mk.3 began recording sensor data by the MAPHEUS Service Module with power-on of the experiment at 07:31:32 (CEST) and continued until power-down at 09:23:00 (CEST) after landing. The data was successfully recorded throughout the flight, which achieved up to 22.3 g of acceleration. Due to harsh weather conditions, payload recovery was postponed until 26 h after launch. During this period, Mk.2 and Mk.3 hibernated in an unpowered state at a temperature of −27 °C, which did not damage the hardware or stored data. The coldest power-on of Mk.2/Mk.3 occurred during the second test countdown and marked a successful boot-up at −3.79 °C.

For the Mk.2 camera, recording slots were planned from T-00:20:00 until T-00:05:00 and again from T-00:03:00 until T+00:15:00. However, due to unfavorable weather conditions of down to −38 °C in the launch area, the first recording slot was initiated early at 07:36:27 (CEST) and lasted until 09:02:19 (CEST). This served both to generate more heat within the experiment container and to obtain more pre-flight data of the specimen. The second recording started at 09:04:16 (CEST) and lasted until 09:22:06 (CEST). Unlike the first mission, recording for the flight phase was not triggered by a Liftoff (LO) signal but activated beforehand by an SoE signal to allow the scientist to observe the specimen minutes before undergoing hypergravity. Likewise, recording was ended via removal of the SoE signal. While Mk.2 employed the same safeguards as the first mission to protect data against corruption in case of an unplanned loss of power, it was more favorable to stop recording and synchronize the filesystem while the power conditions remained stable. This approach reduced potential lost footage from a maximum of one minute (MAPHEUS-8) to none.

Regarding the results of both experiments, the performance was as expected: Mk.3, connected to its own sensors, recorded 20,653 KB (86,826 datapoints). Its ring-memory contained 29 KB (119 datapoints, recording every 101st datapoint after LO). The overall throughput was measured at 12.98 sensor captures/second. This speed could be substantially increased (multiple hundreds of hertz) on an as-needed basis if the used sensors were connected via an SPI.

The Mk.2, as reported, recorded 17:50 min of flight footage in black and white at 25 frames/second with a resolution of 1640 × 1232 pixels to facilitate the complete field of view of the implemented Sony IMX219 sensor. Additionally, it logged the timestamps of its own boot-up, as well as all three signals (LO, SoE, and SoDS) and the sensor data. It should be noted that, with the exception of the hardwired LO signal, all the other signals could be sent according to the operator’s need. We used SoE to control camera recording and SoDS to mark the start and end of the microgravity phase. With this data, it is now possible to analyze the changes in the specimen’s behavior under microgravity and to demonstrate the feasibility of the Trichoscope.

Overall, Mk.2 yielded data and video of the same specimens under the following conditions: control recordings in lab environment (01:11:25 min), control recordings integrated into MAPHEUS (01:25:52 min), and flight recordings (17:50 min, of that: 900 s of microgravity). Apart from reduced movement due to prolonged exposure to the cold, the Trichoplax specimens showed no obvious signs of stress either during hypergravity or microgravity. The video data is meant to complement ongoing ground-based (clinostat-controlled) movement analyses (Schmidt et al., in prep.).

The Mk.2 microgravity detection system detected microgravity 1238 ms after the MAPHEUS Service Module and identified its end 2277 ms later. There were no false positive detections during the flight.

The hazardous commanding system was successfully tested during flight using test commands.

Connectivity to all the subsystems via TM/TC MCU and multiplexer was achieved.

Remote command testing via a Virtual Private Network (VPN) yielded response times of 598.4 ms (pre-apogee/~150 km height), 560.2 ms (apogee/259 km height), and 491 ms (post-apogee/~150 km height), with an average of 549.87 ms. These values represent complete end-to-end testing times and are well within acceptable limits, even for material science experiments.

The remote video system functioned as intended, allowing the scientist to select sample pictures from the incoming video for public presentation. MAPHEUS-10 was the first Mobile Rocket Base (MORABA) flight to be streamed in real time via YouTube and Twitch [3]. This provided public insight into selected TM data from apex Mk.2, both live still images of the specimen being tested and live video of Earth during specific flight intervals.

As for the sample payload of 34 MB of randomized test data, no corruption on the $\mu$SD card could be detected after recomputing the SHA256 checksums on Earth.

4. Conclusions

The two new experiments worked reliably and produced the expected results, even under adverse environmental conditions and outside of their intended environments. Nevertheless, these conditions revealed opportunities for improvements. While the Trichoscope had its own control circuit to regulate the thermals of the optical cell, this also meant that both temperature readings and heater status were transparent to Mk.2, which became a disadvantage. A potential new apex version would include more temperature sensors (which would also be attached to the optical cell and experiment container walls), a switching circuit for the heating block, and a software controller with TC override to allow fine-tuning of the needed heating profiles according to mission requirements.

To allow for better identification of the environmental profile early in the mission, a Mk.3 placeholder could be built to use the integrated temperature sensors within the experiment container to allow for detecting adverse environmental conditions before integrating the main payload with the specimen during the late access period. This would also eliminate the occurrence of ghost TM during ground testing without an integrated payload.

The integrated sensors within Mk.2 allowed for better synchronization of recorded video and environmental data but at the cost of lower sensor throughput. To allow for both higher-frequency sensor data and direct integration into Mk.2 data channels, a secondary co-processor would be added to pre-process all the sensor data and relay this in higher volume to the camera system.

Especially with life science experiments, live video proved to be invaluable to more accurately judge the current status of the specimen. As live video is not available during all mission types, a TM-based system has already been developed and lab tested to allow for downlink of still images of the video system, even if the analog video channels are not available. This system also implements encryption to safeguard downlinked data. The same scheme can be integrated with regular TM and TC messages to allow for higher operational security and resiliency.

In combination with complementary fixation systems such as MiniFix, which has repeatedly flown on MAPHEUS and enabled chemical preservation of Trichoplax adhaerens under microgravity [24], our platform closes the gap regarding integrated pipelines: live observation during flight, followed by fixation for post-flight molecular analysis.

In the future, apex has the flexibility to be developed into different kinds of systems. As a support tool for life science experiments, two new apex-powered microscopes are planned. The first iteration would be a more tightly integrated version that could be used within the standardized CubeSat platforms. The second iteration would be more feature-rich, allowing for the integration of artificial intelligence/neural networking processors and multi-camera setups to increase the scientific yield per flight. Another possible development—thanks to the successful test of the TM/TC MCU—would be generalization into a multi-experiment controller, allowing for easy and fast integration and control of smaller experiments within a single experiment container, including their cascaded remote control.