Design, Prototyping and Stratospheric Launch of CubeSats for University Competition

ABSTRACT

This work presents the design and prototyping of two 1U standard CubeSats for the First Brazilian MCTI Satellite Olympiad, launching one in a stratospheric helium-filled balloon. The nanosatellites were designed for two missions: Internet of Things connectivity in remote areas based on CubeSat (IoSat) and low-orbit harmful gamma radiation mapping (LOHGRM). The IoSat mission aimed to provide server connectivity for a remote sensor network. The LOHGRM CubeSat was designed for sensing and mapping gamma radiation power levels in the satellite’s orbit to construct a heat map to study the gamma radiation effect on the equipment. The prototype’s performance was evaluated based on physical, mechanical, magnetic, thermal, and transmission characterization, with satisfactory results under test conditions. The LOHGRM mission test was carried out on the ground as proof of concept without flying while a stratospheric balloon launched the IoSat prototype. Due to restrictions imposed by the competition, the IoSat nanosatellite only captured and registered altitude, pressure, and temperature data without testing the communication payload. Instead, this data was sent to the ground station through the competition communication system and stored in a memory card to assess its operation during the flying. The satellite’s maximum altitude was 22.6 km, operating under –23.5 °C.

Keywords
Nanosatellites; Nanosats; Small satellites; IoT connectivity; Gamma radiation

INTRODUCTION

Satellites have been deployed over the years to provide services mainly related to communication systems, global positioning systems (GPS), meteorology, Earth observation and imaging, and research (Minoli 2015). Indeed, Geostationary and Medium Earth Orbit (GEO and MEO) have mastered the satellite industry and organizations. However, recent advancements in microengineering are driven the market interest in nanosatellite and constellation coverage based on the intrinsic advantage over large satellite categories, such as small size, weightlessness, lower power consumption, easy deployment, cost-effective implementation, and launch (Edpuganti et al. 2022; Leppinen et al. 2019).

Nanosatellites are a category that encompasses satellites with a mass lower than or equal to 10 kg, orbiting at lower altitudes (less than 2,000 km), known as Low Earth Orbit (LEO) (Elbert 2008; Minoli 2015). The orbit period of this satellite is between 90 min and 2 h, demanding a constellation deployment to perform global coverage. Nanosatellite launching is cheaper than MEO and GEO, because vehicle launching allows groups of nanosatellites to be sent every launch (Edpuganti et al. 2022; Minoli 2015). Hence, the satellite industry and organizations are working on building nanosatellite constellations to reshape and provide new market solutions, lowering service costs to the final customer (Prol et al. 2022). As a result, the number of nanosatellite launches has consistently increased, with cube satellites (CubeSats) among the most deployed (Kulu c2014-2022). The CubeSat design is considered a modular cube structure (1U) with a 10 cm³ size that can be combined in one direction to form structures with 2U, 3U, and thereon.

The introduction of the small satellite design and development in academia came about 20 years ago with the concept of CubeSats, resulting from a partnership between the Polytechnic of California and the Stanford Space Research Laboratory (Silva 2018). The project, conceived by professors Bob Twiggs and Jordi Puig-Suari, aimed to use this nanosatellite category to disseminate and promote knowledge and discussions of space sciences in academia, preparing professionals to work in this market. In addition, other satellites of even lower mass, such as TubeSats, PocketQubs, CanSats, and FemtoSats, can be developed. Regardless of the category, the small satellite design is complex and combines knowledge from several areas, providing a multidisciplinary environment for teamwork development.

Concerning Brazil, CubeSat design, prototyping, and stratospheric launching aimed at university competitions to promote students’ interest in the space sector have grown. Three main contests take place annually named Latin America Space Challenge (LASC), CubeDesign, and Brazilian MCTI Satellite Olympiad (Olimpíada Brasileira de Satélites do Ministério da Ciência, Tecnologia e Inovação, OBSAT-MCTI) (INPE c2020, LASC c2022; OBSAT 2022). The LASC is an international contest, as well as the CubeDesign, which is promoted by the National Institute for Space Research (Instituto Nacional de Pesquisas Espaciais, INPE). The latter refers to a Brazilian government contest that completed its first edition in 2022, sponsored by the MCTI. This contest mainly works on proposing a joint mission or requesting them freely to the teams under a competition notice. Hence, the team’s performance is evaluated in different phases regarding the ability to develop its mission.

The CubeSat Design Team from the National Institute of Telecommunication (Instituto Nacional de Telecomunicações, Inatel) has been jointing to the First OBSAT, presenting two missions: Internet of Things (IoT) connectivity in remote areas based on CubeSats (IoSat) and low orbit harmful gamma radiation mapping (LOHGRM). The teams worked on developing and prototyping their CubeSats under the contest restriction imposed by the OBSAT organization. The IoSat mission aimed to demonstrate a concept solution to data retransmission through a CubeSat to provide connectivity for network sensors located in rural or remote areas in which terrestrial network coverage is restricted or nonexistent. Furthermore, the IoSat prototype was launched at a high altitude using a stratospheric helium-filled balloon with a platform provided by the OBSAT organization. Due to competition constraints, the IoSat nanosatellite only captured and registered altitude, pressure, and temperature data without testing the communication payload. Instead, this data was sent to the ground station through the competition communication system based on a Wi-Fi communication solution added to the initial CubeSat payload to meet the competition requirements. This data was also stored in a memory card to assess its operation during the flying. Although the designed communication systems were not operated, the mission has offered a proof of concept based on the mission’s requirements to retransmit data to a ground station.

The LOHGRM prototype was not launched. Instead, the tests have been conducted on the ground by collecting data on natural radiation using the payload system and sending it to a server for storage and future processing. Although the test did not fully encompass a real scenario, it could provide a proof of concept related to the mission goal while testing the system’s interoperability. Regarding these statements, this work presents and discusses the two CubeSats design, deployment, and launching phases during the first OBSAT. The paper’s main contributions are as follows:

• Dissemination of knowledge about the design and prototyping of CubeSat aiming at University Competition;

• Discussion about the design and deployment of two CubeSat missions, being helpful for teams’ beginners;

• Discussing and evaluating data captured on a stratospheric launching helium-filled balloon as proof-of-concept experimental test.

MISSIONS REQUIREMENTS

This section discusses the two mission and subsystems’ requirements to design and implement the CubeSats aiming at launching in a stratospheric helium-filled balloon platform. The two CubeSats comprise identical subsystems as listed (Coutinho et al. 2022a): on-board data handling (OBDH); telemetry, tracking, and command (TT&C); attitude determination and control system (ADCS); electronic power system (EPS); thermal cycling systems; and mechanics and structure. In addition, the payload subsystems are related to the mission’s requirements, which are discussed in the following section.

IoSat Mission: IoT Connectivity in Remote Areas Based on CubeSats

IoT handles different devices’ interconnection to exchange information with each other through the Internet, offering a wide range of services and applications for different market sectors (Corcoran 2016). Many applications impose different communication constraints to deploy IoT networks, raising various communication protocols (Al-Fuqaha et al. 2015). In addition, IoT networks face coverage challenges in rural or remote regions and rely on other telecommunications networks to extend their connectivity. Mobile networks and satellite communications support the development of IoT applications in these scenarios (Centenaro et al. 2021). However, the former is generally limited to commercially suitable rural areas for deployment. Meanwhile, satellite communications stand out in areas lacking terrestrial network coverage as a geographically and economically feasible solution for developing IoT applications in rural and remote areas.

Concerning the above discussion, the IoSat mission proposes developing a CubeSat to demonstrate a concept solution in support of IoT applications in rural (e.g., applications in Smart Farms) and remote (e.g., environmental monitoring) areas based on relaying the received data from an IoT gateway-based ground station to a server. Note that the footprint of a CubeSat is small to cover vast regions, requiring replicating the prototype to form a nanosatellite constellation to cover larger areas. The initial proposal requirements considered a network model to establish communication among a remote gateway, the CubeSat, and a ground station nearby a terrestrial network. The gateway is positioned near a remote IoT network to capture and adapt the sensor data to transmit to the CubeSat, which receives the upcoming data and relays it to another location. In contrast, the ground station receives and forwards the downcoming data to a monitoring system or a customer application through a terrestrial network.

The initial requirements to achieve the IoSat mission are to implement two ground station segments and a CubeSat. One of the ground stations would send data to the CubeSat on the fly, while the other would receive the relayed stream data and storage for comparison purposes. Primary, the IoSat payload comprises a telemetry, tracking and command (TT&C) subsystem based on the Long Range (LoRa) protocol, which offers a suitable coverage range since the CubeSat launch is limited to the stratosphere region. The gateway and the ground station are also deployed based on LoRa communication. However, the OBSAT organization has imposed some restrictions on communication during the CubeSat launch established during the prototyping phase. Regardless of the mission, any CubeSat suitable for stratospheric launch must send the data via Wi-Fi to an access point (AP) positioned on the platform. Alternative communication systems would be accepted based on an amateur radio license provided by the Brazilian National Agency of Telecommunication (Agência Nacional de Telecomunicações, ANATEL), which was not afforded by the IoSat team.

The restriction imposed by the competition redefined some aspects of the mission’s initial requirement. First, the ground station deployment was unnecessary since the OBSAT ground segment would receive the data through the Wi-Fi communication solution embedded in the stratospheric platform. Regarding the CubeSat subsystems, a Wi-Fi module has been added to the TT&C subsystem to comply with the notice restrictions, thereby providing a Wi-Fi connection instead of supporting the LoRa communication protocol only. Although the LoRa-based communication would not operate on the fly, the team has deployed and ground-tested this module based on the initial mission requirements.

LOHGRM Mission

Alpha radiation, cosmic rays, gamma radiation, and neutrinos can damage electronic components, which can damage crucial satellite systems and space capsules when subject to prolonged exposure (Jung and Choi 2019). The most significant radiation source comes from the Sun when an object is in orbit. The Sun emits energized protons and gamma-laden iron particles violently across the matter, obliterating electronic devices, damaging sensors, corrupting memories, and causing catastrophic failures in systems boards, reducing abruptly the satellite life cycle (Mayo et al. 1963). Thus, it is necessary to conduct tests and develop robust protection systems against radiation. For instance, the U.S. National Aeronautics and Space Administration (NASA) Jet Propulsion Laboratory has facilities for testing radiation effects. The efficiency of systems in mitigating the harmful effects of radiation is determined through tests with controlled radiation emissions.

Small commercial satellite launch aiming at low-orbit constellations deployment has recently grown based on optimizing manufacturing, testing, assembly, and launch stages to meet the demand (Edpuganti et al. 2022). Researchers and university competition teams are more interested in developing small satellites. Thus, easy access to relevant information for project decision-making should be provided. For instance, radiation level data defines the antiradiation approach used in a mission, considering the satellite construction restrictions (Granja et al. 2016). However, researchers and university competition teams cannot access equipment and facilities for accurate testing.

The only way to develop systems that reduce the effects of radiation is with data provided by missions that map the ionic radiation in different orbits. Unfortunately, only a few databases contain up-to-date information in the public domain on monitoring the broad spectrum of radiation. Most related missions aim at the study and technological validation of components and systems under the effect of radiation emission, whose available data are final research results (Budroweit and Sznajder 2018). Hence, the LOHGRM mission proposes prototyping a 1U CubeSat for sensing and mapping the levels of gamma radiation in low orbit as a proof of concept. The aim is to obtain a heatmap by collecting gamma radiation levels in the satellite’s orbit and crossing with the respective collection position (latitude, longitude, and altitude). Subsequently, the data would be available on a public domain database so that researchers and university competition teams can access them, improving protection systems and developing new technologies against the effects of gamma radiation on systems.

LOHGRM mission initial requirements stand for a CubeSat capable of sensing gamma radiation power level and associating the collected data with the measurement location. In addition, the collected data should be sent to a server for storage and processing, allowing the plot of a heat map based on the satellite orbit. Since these mission requirements are not related to the communication constraints imposed by the OBSAT organization, there was no impact on the initial requirements regarding the TT&C subsystems, which were considered to comply with the notice restrictions.

SUBSYSTEMS DESIGN

The two proposed CubeSats missions have been developed cooperatively between the CubeSat Design Team groups by applying a similar methodology. Considering the constraint mentioned above, the methodology to design and implement the CubeSats has followed the workflow shown in Fig. 1. The initial stage is the mission proposal, specified according to the team’s problem identification and solution treatment, which allows specifying the mission’s requirements. Next, the contest constraints are evaluated to define the subsystem’s design and to fit the communication aspect. Finally, this analysis is extended to the payload subsystem to raise concerns and limitations related to the design. At this point, the general subsystems and the payload are developed and preliminarily tested independently. Since the evaluation succeeded, the integration phase begins by adding the payload subsystems to the final design, following a test. We have developed our methodology since the teams comprised few members, and the interdisciplinary work was highly demanded. Generally, teams are divided into subsystem sectors, each carrying out its system prototyping for further integration after successful tests.

Figure 1
Workflow applied to design and develop the proposed CubeSats.

Following the subsystems, design and prototyping are explained with the CubeSats block diagram shown in Fig. 2a, IoSat mission, and Fig. 2b, LOHGRM mission.

Figure 2
CubeSats block diagram (a) IoSat mission and (b) LOHGRM mission.

OBDH integrates the other subsystems, allowing data reading, processing, and storage to be performed during the mission. It monitors modules and components and manages communications with the AP-based Wi-Fi made available as a point for sending data to the OBSAT ground station. The development board NodeMCU ESP-12 was selected as the OBDH, which has a native Wi-Fi connection through an integrated ESP32 module. For data storage, a memory card module was included. The OBDH routines were written in C++ through the Arduino Integrated Development Environment (IDE) and loaded onto the NodeMCU board. The functions implemented for the IoSat mission are: connecting to the HTTP server via Wi-Fi; handling data collection such as altitude, atmospheric pressure, and temperature; sending data via Wi-Fi through AP; and monitoring battery levels. The LOHGRM mission shares the IoSat functions, including reading and processing data from the gamma radiation sensor; and reading and processing data from the GPS module.

The TT&C subsystem comprises the components to send data collected by the payload to the ground station. Furthermore, relevant data from other subsystems are also transmitted by this system. Due to the OBSAT organization restriction, this subsystem corresponds to the ESP32 Wi-Fi module provided by the NodeMCU board, allowing for establishing connectivity with the AP. The microcontroller treats the collected data and makes it available in JSON (JavaScript Object Notation) format in packets of up to 90 bytes to be sent through HTTP requests. As mentioned earlier, the IoSat also has a LoRa module in the TT&C subsystem as defined by the initial mission requirement.

The ADCS subsystem is responsible for determining the orientation of the CubeSat using data from several sensors to keep the satellite stabilized and perform the pointing correction by the set of actuators (Coutinho et al. 2021; 2022b). The OBSAT organization has ruled out the inclusion of this subsystem in the CubeSat design since the stratospheric launch is accomplished by fixing the satellite on a platform. However, we have decided to partially include this subsystem considering only inertial and noninertial sensors to collect state data from the CubeSat during flight, as requested by the organization. In addition, the team aims to explore the attitude determination process in a natural environment, storing the information on a memory card for future studies. Four sensors were defined to compose the ADCS subsystems: the gyroscope, the 6-axis accelerometer, the atmospheric pressure sensor, and the high-precision thermometer. These sensors are integrated into the GY-87 module, which has been included in the design, as seen in Fig. 2. These sensors provide an accurate estimate of the relative attitude of the CubeSat during the mission. The data coming from the GY-87 module is forwarded to the microcontroller, which determines the angles that describe the satellite’s positioning and stores them on the memory card.

The EPS subsystem guarantees the power supply demanded by the CubeSat subsystems during the mission. Two lithium batteries (model 18650) associated in series and a voltage converter (model LM 2596) were used to design each CubeSat. The load cell has a capacity of 2200 mAh to supply power to the components during the mission. At the same time, the LM 2596 allows converting a high direct current (DC) voltage to a lower value. This module is essential due to the supply voltage difference among the other subsystem’s modules (between 3.3 and 5 V) and the voltage value provided by the parallel lithium batteries, a maximum value of 8.4 V. Batteries protection modules were not included in the design since the microcontroller was programmed to monitor the battery voltage levels and perform consumption management to avoid damage at low voltage. Another mechanism to avoid damage is through the voltage converter that turns off when it reaches voltages lower than 2.9 V at the input and deactivates all systems in extreme cases.

The thermal control subsystem monitors and controls the satellite’s internal temperatures, ensuring that the mechanical, electrical, and electronic components operate within the indicated temperature ranges to achieve good operation. Thus, it is considered that the subsystem acts actively in thermal control. However, the CubeSat design employed thermal insulating materials to protect sensitive components from extreme temperature variations. Furthermore, passive components were chosen for their simplicity and robustness since those active ones introduce energy expenditure and complexity to the project. The insulating material known as expanded polyethylene (EPE) foam was used to wrap the batteries, which can be easily adjusted for rapid prototyping by controlling the insulating material’s thickness.

The payload subsystem is different for each CubeSat. For example, the IoSat mission has this subsystem suited by the TT&C, as abovementioned. Meanwhile, the LOHGRM mission must measure gamma radiation levels within the CubeSat orbit and its coordinates for generating heat maps. Consequently, this subsystem includes a module for detecting radiation levels, determining latitude, longitude, and altitude measurements, and a microcontroller for data processing corresponding to the NodeMCU. Module SEN-14209 was selected from SparkFun, formed by a high-energy ionizing particle sensor, a pulse measurement circuit, and a low-power electrical circuit integrated into a printed circuit board (PCB).

The SEN-14209 module captures electrical pulses corresponding to gamma radiation with energy levels between 2 and 30 KeV crossing the sensor surface. The microcontroller processes these pulses to determine the power levels (P, in becquerel [Bq]) through the relationship between the quantity (q) of pulses captured in a time interval (t) as disclosed in Eq. 1 (Oak Ridge Institute c2022):

$$P=\frac{1}{t}\underset{i=1}{\overset{t}{\Sigma }}{q}_i \left[\mathrm{Bq}\right]$$ (1)

The GPS module NEO-6M V2 from U-BLOX was chosen to obtain the satellite positioning. This module comprises a system-on-chip model NEO-6M; an electrically erasable programmable read-only memory for storing system settings; an antenna; and a low-power circuit integrated into a PCB. The module collects the data in the form of numerical sequences obtained by the signal from the GPS satellites. Subsequently, the OBDH subsystem processes the data to obtain the CubeSat coordinates referring to the extraction location of the gamma radiation level measurements.

The CubeSat’s mechanical structures have been designed using the Blender 3D computer-aided design program. Figure 3 depicts the design for the two CubeSat missions, highlighting the mounting process, labeled by steps 1 to 5. Initially, the CubeSats base must be fixed by screws on the mounting surface (i.e., the stratospheric platform), followed by the lateral faces integration through screws (IoSat) or metal bars (LOHGRM) as indicated by step 2. Next, the PCB with the integrated subsystems is inserted into the CubeSats mechanical structure by positioning it into the side spaces formed by jointing the lateral faces, as seen in detail in step 3. Finally, step 4 indicates how to close the mechanical structure after the components are embedded, with the final mounted CubeSats displayed in step 5.

Figure 3
CubeSats mechanical structures and mounting process; (a) IoSat mission and (b) LOHGRM mission.

The structure was implemented through 3D printing using acrylonitrile butadiene styrene (ABS) filament to obtain robustness, stabilization against vibrations and impacts, modularity, and thermal protection for the internal components. In addition, a 2 mm extrusion on the side faces of the CubeSat with a covered base of only 1 mm was used to improve resistance against impacts and vibrations. The mass reduction has been accomplished based on the new structural designs of the space launch system vehicles and the cubic extrusions used in the fuel tanks designed by the United Launch Alliance.

The side faces were connected through metallic rods introduced in lateral supports located at the structures’ faces edges, as indicated in Fig. 3. The spacing between the lateral supports is 2.5 mm, allowing PCB attachment and frame assembly with just four points. The bottom and upper faces are attached, introducing screws into the lateral brackets. Hence, the approach avoids the mechanical pressure on the sides exceeding the material point of plastic deformation, distributing the pressure applied to the structure to four points other than the sides of the faces. Following the organization’s recommendations for attaching the CubeSat to the launch pad, extrusions were introduced on the bottom face of the mechanical structure.

CubeSats prototyping

The prototyping phase integrated the subsystem components using protoboards and jumpers to connect the modules and the NodeMCU. The connections of each system component were defined with the General Purpose Input/Output pins or peripherals of the ESP32 microcontroller. Since the subsystem operation was successful, the electrical schematic was designed in the EasyEDA program to manufacture the PCB and solder the necessary modules and components.

Figure 4 shows the subsystems integrated into the two missions’ manufactured boards. The microcontroller provides two sets of pins for serial communication with universal asynchronous receiver/transmitter (UART) protocol, two sets for communication with serial peripheral interface (SPI) protocol, and one set for communication with inter-integrated circuit (I²C) protocol. Although a UART and an SPI set are only necessary to integrate the modules, a second set of pins was used to introduce redundancy communication to the project. Routines were programmed to select the serial communication used at a given moment, affording communication path switching by detecting communication errors and bypassing problems related to the PCB. This approach was also applied to the signal pins of the SEM-14209 radiation sensor and the battery resistors through pins with ADC functions to manage charge levels correctly.

Figure 4
CubeSats PCBs (a) Upper view of the IoSat PCB, (b) Bottom view of the IoSat PCB, (c) Upper view of the LOHGRM PCB, (D) bottom view of the LOHGRM PCB.

Regarding the nonessential pins, light emitter diodes (LEDs) were connected to indicate operating and battery charge states or inform other system aspects, constituting a simple user interface. All components were directly connected to the V_CC, the output pin of the converter, because the microcontroller’s internal regulator is incapable of supplying the system. Furthermore, some components require a 5 V power supply, making it necessary to supply the load directly from the DC-DC voltage amplifier. Practical tests were carried out to measure the energy consumption of the system in operation and transmitting data. There was a consumption of 240 mAh with the GPS module active and 180 mAh when the GPS was inactive. Despite the GPS module energy requirements, the overall consumption is adequate to support the missions. Figure 5 exhibits the CubeSat’s final mounting with the PCB housed by the mechanical structures.

Figure 5
CubeSats external view, with standard 1U mechanical structure. View of partially open frame and PCB with integrated subsystem components (a) IoSat mission, (b) LOHGRM mission.

Figure 6 shows the flowcharts related to the routines developed to enable the joint operation of the subsystems and the mission’s feasibility with sending data via Wi-Fi to the AP available in the stratospheric platform. Initially, the libraries are included, the global variables are declared, and the sensors, serial communication, and Wi-Fi connection are configured. Then, the subsystem sensors are read, and the data are processed and stored on the memory card. Finally, the data is forwarded to the ground station every 4 min through the Wi-Fi-based AP, as requested in the notice. Subsequently, routines for checking the Wi-Fi connection, functioning, and integrity of the modules and sensors are started for corrections prior to the next reading period. For straightforward code writing, functions were created to house some routines.

Figure 6
Flowchart of code implemented to enable missions: (a) IoSat, (b) LOHGRM.

EVALUATION TEST, LAUNCHING, AND DISCUSSIONS

This section carries out the proposed CubeSats’ test results and launching process. The tests encompass physical characterization, mechanical, electromagnetic, and thermal robustness, data capture, storage, and transmission. The launching event comprises the IoSat mission.

Physical characterization was performed based on the mass and dimensions measured. The IoSat structure weighed 309.6 g, while the LOHGRM CubeSat presented a total value equal to 364.5 g, as seen in Fig. 7, including all components arranged internally and the insulating material. Regarding the physical structure size, the face side measured around 9.9 cm. Therefore, the theoretical design presents dimensions of 10 cm³. The reduction of about 1 mm is due to the thermal contraction of the 3D printing filament after complete cooling. This contraction is between 1% and 2% for the ABS material, complying with physical model measured values.

Figure 7
Physical characterization of the two CubeSats.

Mechanical robustness has been pursued based on approaches introduced in the structure design, such as the modularity of the PCB for easy coupling, as seen in Fig. 8. Metallic rods were inserted in lateral connections that extend for about 25% of the side of the respective face, providing a distribution of forces by the structure. Finally, fixing the upper and bottom faces used another set of connections to reduce the mechanical stress on the corner of the cube walls.

Figure 8
Details of the fixing point and the slide in concept to easy attach the PCB.

The electromagnetic robustness test involved placing a magnetic field source in different regions close to the prototype and monitoring the magnetic field measured by one of the axes of the magnetometer in the GY-87 module. The CubeSats were introduced into a wooden support chamber, as shown in Fig. 9. The tests were carried out with the PCB directly exposed to the magnetic field source and installed inside the CubeSat’s mechanical structure. Then, a magnet was moved between 0 and 7 cm away from the support.

Figure 9
Experimental setup for electromagnetic robustness characterization.

Figure 10 shows the field strength captured by one magnetometer axes concerning the distance from the magnetic field source for the LOHGRM CubeSat. As expected, the field strength reduces as the magnet moves away. There is greater field intensity with the presence of the structure, resulting from the interaction between the metal rods and the magnetic field generated by the magnet. During the experiment, the CubeSat remained connected to capture the intensity levels, which resulted in curves consistent with the expected results. Thus, it was demonstrated the satellite does not suffer significant magnetic interference for magnetic field intensities lower than or equal to 12 μT. Similar results were found for the IoSat CubeSat.

Figure 10
Magnetic field intensity measured for different positions of the magnetic source (magnet), with the exposed PCB and housed by the mechanical structure of the CubeSat.

Thermal robustness tests were conducted using a sealed wooden box and a heat gun. The wooden box has dimensions of 30 cm³ with a hole in the lateral perimeter to insert heated air. The CubeSats were inserted into the wooden box and initialized to capture and send the internal temperature to a local storage server outside the air retention structure. After the thermal stabilization of the CubeSat, the air blower was positioned in the side opening to introduce hot air inside the wooden box with the satellite in operation. The heat was transferred to the CubeSat structure through direct contact between air and the outer surface of the cube faces. The experiment was conducted for about 10 min, recording the internal temperature. Using a blower configured at the same temperature was considered for two test scenarios: without and with the EPE foam. Figure 11 displays the captured temperature, verifying that the foam’s introduction delays the temperature increase inside the CubeSat’s mechanical structure. It is also shown that the components can operate at temperatures close to 55 °C without losing communication with the server.

Figure 11
CubeSat thermal curves for 120 measurements collected in an interval of 10 min in a heat environment.

Due to the significant thermal variation found in space and its critical influence on the functioning of circuits and other materials, the CubeSat’s robustness and thermal stability at lower temperatures were also aimed. Therefore, the CubeSat’s temperature and health were monitored by introducing the structures in a refrigerated environment. Through the temperature sensor present in the GY-87, the variations perceived by the environment’s structure were captured for 15 min. Figure 12 shows the measured temperature curve for the CubeSat with and without the EPE foam. As a result, the foam delayed the structure’s cooling by up to 10 °C, with the subsystems operating without packet loss in the communication.

Figure 12
CubeSat collected thermal curves for 180 measurements at intervals of 15 minutes in a refrigerated environment.

The transmission test was executed by capturing telemetry and mission data sent to a local HTTP server, considering the prototype operating in an indoor environment under temperature around 23 °C. The prototypes were completely mounted and powered supplied by its own batteries, sending data to the server and storing in the embedded card memory during 1hour to validate its operation and the battery performance. Regarding the HTTP protocol, the data is sent via the air interface without encrypting the text, allowing easy capture and reception through the Wireshark program. Thus, the tool captures and decodes the packet sent to the server while simulating the transmission between the NodeMCU Wi-Fi module and the AP. For instance, Fig. 13 exhibits the capture and decoding for the LOHGRM mission, indicating the use of the HTTP protocol, a packet in JSON format with a payload size of 70 bytes.

Figure 13
LOHGRM stream capture using the WireShark program and decoding.

IoSat mission transmission test

The IoSat prototype has been tested by collecting and transmitting data using a transmitter and a receiver with the satellite as a relay between these endpoints. The data was transmitted through LoRa and Wi-Fi protocols to the CubeSat, which received the message and sent a response back to the receiver. Furthermore, the results were directly evaluated by the Serial Monitor of the Arduino IDE, in which the receiver NodeMCU was connected. Figure 14 depicts the communication results with the USB COM6 port connected to the CubeSat and the COM5 port connected to the NodeMCU representing the ground station. The results validated the IoSaT payload based on LoRa (initially included in the mission’s requirements) and the Wi-Fi communication link, which was inserted according to the competition constraints discussed in Missions Requirements Section. Regarding the LOHGRM mission, the communication assessment has also provided results to validate the TT&C subsystem.

Figure 14
Communication test between the LoRa device of the ground station and CubeSat.

LOHGRM mission transmission test

The LOHGRM mission aims to collect data related to the gamma radiation power levels, storing them together with the satellite’s latitude, longitude, and altitude. Subsequently, the information is processed to obtain a heat map with radiation levels. Although the LOHGRM was not launched, the prototype was ground-tested to prove the mission concept. Hence, we proposed to move the CubeSat along the Inatel Campus to collect data on natural radiation using the SEN-14209 module and send it to the server. Since the LOHGRM TT&C subsystem comprises a Wi-Fi module embedded in the NodeMCU, the CubeSat transmitted data by connecting with the local Wi-Fi APs disposal along the Campus buildings. Figure 15 shows a post-processing heat map of the measurements superimposed on the campus map. Although this CubeSat was not launched at high altitudes to carry out its mission adequately, the proposed test reveals that the CubeSat worked on and sent data to the server during its operation.

Figure 15
Natural gamma radiation levels read by the SEN-14209 module in different locations of the Inatel campus.

IoSat stratospheric launching and data collected

The IoSat mission has been launched in a stratospheric helium-filled balloon platform provided by the OBSAT organization. The event occurred on October 9^th (2022) in São Carlos/SP, Brazil, carried out by the Zenith Team (a group devoted to developing and launching a stratospheric helium-filled balloon platform). Note that the launching allowed evaluation of the CubeSat operation under the troposphere and stratosphere conditions. Unfortunately, due to the contest transmission restrictions, the LoRa module’s connectivity could not be assessed. Figure 16 shows the CubeSat fixed on the platform, the launching moment, and the recovery process. According to the Zenith and OBSAT organization, the recovery point was located around 80 km from the launching point.

Figure 16
Launching event of the CubeSat designed for the IoSat mission and recovery.

The launching process involved the CubeSat mounting, energizing, and communication test to guarantee the data sent. The team conducted this stage while the Zenith team carried out balloon inflating and launching. Furthermore, the structure was fixed on the platform and launched, recovered intact and working, as seen in Fig. 16. The flying duration lasted around 3.5 h, while the time window until the prototype recovered was around 6 h. The capture data has been analyzed in terms of altitude, atmospheric pressure, and temperature, displayed in Fig. 17. Although LoRa communication assessment would be feasible, it was possible to validate the CubeSat performance in an experimental environment, contributing to the team’s knowledge and experience. The results show that the CubeSat achieved an altitude of around 22.6 km under –23.5 °C.

Figure 17
Data collected during the launching event of the CubeSat designed for the IoSat mission (a) Altitude, (b) Atmospheric pressure, (c) Temperature.

The graphics display all the collected data samples, with a period of 4 min between each one. Platform ascending is between samples 12 and 27, while samples within 27 and 41 values represent descending data. Regarding altitude and atmospheric pressure, invariable sample values were stored at the beginning and end. In contrast, the temperature record data varies around 32 °C before the launching and 23 °C after the platform land. These behaviors were expected since the CubeSat was lying on the ground waiting for launch or recovery, exposed to environmental conditions that impose temperature variation, such as solar incidence (before launching) and rain (after platform landing). The atmospheric pressure and altitude samples show an expected profile during the platform ascending and descending since, at higher altitudes, the former lowers its value. The temperature profile lowered its value as the platform ascended and increased in the descending stage. However, it started to increase between samples 23 and 30. The authors hypothesize that the platform flew above the clouds and got direct incident sunlight that warmed the structure since the weather was cloudy after launch. The slightly decreasing temperature samples support this assumption as the platform descended, indicating that it was passing through the clouds again.

CONCLUSION

This work discussed designing and developing two 1U standard CubeSats structures to perform two missions at the First Brazilian MCTI Satellite Olympiad. The IoSat mission proved a concept solution to data retransmission through a CubeSat to provide connectivity for sensors network located in rural or remote areas. Meanwhile, the LOHGRM small satellite has been implemented for sensing and mapping the gamma radiation power levels in low orbit. The CubeSats were built based on the design requirements of the contest, complying with the notice constraints. Therefore, we reported the design, prototyping, and test stages with the subsystems integrated into a mechanical structure in a 1U pattern. In addition, the physical, mechanical, magnetic, thermal, and transmission characterization was discussed to evaluate the final prototype’s performance. Finally, a ground test was performed for each mission, with the IoSat prototype launched to validate its operation experimentally.

Shortly, this work constitutes a means to expose the Inatel CubeSat Design Team’s experience in all the stages of developing a CubeSat for a university contest. It allows the dissemination of knowledge about the design and prototyping of CubeSats aiming at university contests by exposing a point-by-point methodology that can be used for other teams as a guide. In addition, this paper encompasses essential information about the CubeSat subsystems and components that might be used to design each of them, supporting team beginners.

ACKNOWLEDGEMENTS

The authors thank the Centro de Segurança Cibernética do Inatel (CxSC Telecom) for supporting this work, the OBSAT organization for the opportunity to participate in the contest, and the Zenith team for providing the stratospheric platform and supporting the launch and recovery.

• Peer Review History: Single Blind Peer Review.

• FUNDING

  Conselho Nacional de Desenvolvimento Científico e Tecnológico
  [https://doi.org/10.13039/501100003593]

Data Availability Statement

All dataset were generated or analyzed in the current study.

REFERENCES

• Al-Fuqaha A, Guizani M, Mohammadi M, Aledhari M, Ayyash M (2015) Internet of things: A survey on enabling technologies, protocols, and applications. IEEE Commun Surv Tutor 17(4):2347-2376. https://doi.org/10.1109/COMST.2015.2444095
  » https://doi.org/10.1109/COMST.2015.2444095
• Budroweit, J., Sznajder, M. (2018) Total ionizing dose effects on a highly integrated RF transceiver for small satellite radio applications in low earth orbit. Paper presented 2018 IEEE International Symposium on the Physical and Failure Analysis of Integrated Circuits (IPFA), Singapore. https://doi.org/10.1109/IPFA.2018.8452610
  » https://doi.org/10.1109/IPFA.2018.8452610
• Centenaro M, Costa CE, Granelli F, Sacchi C, Vangelista L (2021) A survey on technologies, standards and open challenges in satellite IoT. IEEE Commun Surv Tutor 23(3):1693-1720. https://doi.org/10.1109/COMST.2021.3078433
  » https://doi.org/10.1109/COMST.2021.3078433
• Corcoran P (2016) The internet of things: Why now, and what’s next? IEEE Consum Electron Mag 5(1):63-68. https://doi.org/10.1109/MCE.2015.2484659
  » https://doi.org/10.1109/MCE.2015.2484659
• Coutinho DA, Vilela SF, Conceição AA, Paulino PLS, Aquino GP, Ferreira Junior AA, Boas ECV (2022a) Desenvolvimento de um CubeSat para mapeamento de radiação gama em órbita baixa. Paper preented XL Simpósio Brasileiro de Telecomunicações e Processamento de Sinais-SBrT. https://doi.org/10.14209/sbrt.2022.1570823215
  » https://doi.org/10.14209/sbrt.2022.1570823215
• Coutinho DA, Conceição AA, Ferreira Junior AA, Boas ECV (2022b) A fast centroiding algorithm for digital sun sensors for nanosatellite applications. IEEE Sens 6(4):6001104. https://doi.org/10.1109/LSENS.2022.3154349
  » https://doi.org/10.1109/LSENS.2022.3154349
• Coutinho DA, Conceição AA, Ferreira Junior AA, Boas ECV (2021) Algoritmo rápido para cálculo de centroide de imagem com sensores digitais de sol do tipo CMOS para aplicação em pequenos satélites. Paper presented XXXIX Simpósio Brasileiro de Telecomunicações e Processamento de Sinais-SBrT. In Portuguese. https://doi.org/10.14209/sbrt.2021.1570734179
  » https://doi.org/10.14209/sbrt.2021.1570734179
• Edpuganti A, Khadkikar V, Moursi MSE, Zeineldin H, Al-Sayari N, Al Hosani K (2022) A comprehensive review on CubeSat electrical power system architectures. IEEE Trans Power Electron 37(3):3161-3177. https://doi.org/10.1109/TPEL.2021.3110002
  » https://doi.org/10.1109/TPEL.2021.3110002
• Elbert BR (2008) Introduction to satellite communication. 3rd edition. Norwood: Artech House.
• Granja C, Polansky S, Vykydal Z, Pospisil S, Owens A, Kozacek Z, Mellab K, Simcak M (2016) The SATRAM Timepix Spacecraft Payload in Open Space on Board the Proba-V Satellite for Wide Range Radiation Monitoring in LEO Orbit. Planet Spa Sci 125:114-129. https://doi.org/10.1016/j.pss.2016.03.009
  » https://doi.org/10.1016/j.pss.2016.03.009
• [INPE] Instituto Nacional de Pesquisas Espaciais (c2020) CubeDesign Virtual 2021. [accessed 2022 Oct 20]. http://www.inpe.br/cubedesign/2021/
  » http://www.inpe.br/cubedesign/2021/
• Jung S, Choi JP (2019) Predicting system failure rates of SRAM-based FPGA on-board processors in space radiation environments. Reliab Eng Syst Saf 183:374-386. https://doi.org/10.1016/j.ress.2018.09.015
  » https://doi.org/10.1016/j.ress.2018.09.015
• Kulu E (c2014-2022) Nanosats Database. [accessed 2022 Oct 20]. https://www.nanosats.eu/
  » https://www.nanosats.eu/
• [LASC] Latin American Space Challenge (c2022) [accessed 2022 Oct 20]. https://www.lasc.space/
  » https://www.lasc.space/
• Leppinen H, Niemelä P, Silva N, Sanmark H, Forstén H, Yanes A, Modrzewski R, Kestila A, Pranks J (2019) Developing a Linux-based nanosatellite on-board computer: Flight results from the Aalto-1 Mission. IEEE Aerosp Electron Syst Mag 34(1):4-14. https://doi.org/10.1109/MAES.2019.170217
  » https://doi.org/10.1109/MAES.2019.170217
• Mayo JS, Mann H, Witt FJ, Peck DS, Gummel HK, Brown WL (1963) The Command System Malfunction of the Telstar satellite. Bell Syst Tech J 42(4):1631-1657. https://dx.doi.org/10.1002/j.1538-7305.1963.tb04044.x
  » https://doi.org/10.1002/j.1538-7305.1963.tb04044.x
• Minoli D (2015) Innovations in Satellite Communications and Satellite Technology: The Industry Implications of DVB-S2X, High Throughput Satellites, Ultra HD, M2M, and IP. New Jersey: John Wiley & Sons.
• Oak Ridge Institute (c2022) How to measure radiation. [accessed 2022 Oct 20]. https://orise.orau.gov/resources/reacts/guide/measuring-radiation.html
  » https://orise.orau.gov/resources/reacts/guide/measuring-radiation.html
• [OBSAT MCTI] Olimpíada Brasileira de Satélites do Ministério da Ciência, Tecnologia e Inovações (c2022) 1^a Olimpíada Brasileira de Satélites MCTI. [accessed 2022 Oct 20]. https://www.obsat.org.br/
  » https://www.obsat.org.br
• Prol FS, Ferre RM, Saleem Z, Valisuo P, Pinell C, Lohan ES, Elsanhoury M, Elmusrati M, Islam S, Çelikbilek K, Selvan K, Yliaho J, Rutledge K, Ojala A, Ferranti L, Praks J, Bhuiyan MZH, Kaasalainen S, Kuusniemi H (2022) Position, navigation, and timing (PNT) through low earth orbit (LEO) satellites: A survey on current status, challenges, and opportunities. IEEE Access 10:83971-84002. https://doi.org/10.1109/ACCESS.2022.3194050
  » https://doi.org/10.1109/ACCESS.2022.3194050
• Silva MDS (2018) Metodologia para o desenvolvimento de CubeSat 1U Acadêmico (MSc. Dissertation). Belo Horizonte: Universidade Federal de Minas Gerais. In Portuguese.

Edited by

Section editor: Alison Moraes. https://orcid.org/0000-0002-6493-1694

Publication Dates

• Publication in this collection
  17 Apr 2023
• Date of issue
  2023

History

• Received
  21 Oct 2022
• Accepted
  26 Feb 2023