Lessons Learned from IDEASSat: Design, Testing, on Orbit Operations, and Anomaly Analysis of a First University CubeSat Intended for Ionospheric Science

Abstract

Given the pervasive use of satellite and over the horizon wireless communication technology in modern society, ionospheric disturbances that can disrupt such services are a crucial consideration. Ionospheric irregularities, plasma bubbles and other phenomena can have a great impact on satellite navigation and communications, impacting other systems reliant on such technologies. The Ionospheric Dynamics and Attitude Subsystem Satellite (IDEASSat) was a 3U developed by National Central University (NCU) to measure irregularities in the ionosphere, as well as to establish spacecraft engineering and operations capacity at NCU. The onboard Compact Ionospheric Probe (CIP) could measure high-resolution plasma parameters, which can be used for identifying ionospheric irregularities that can cause scintillation in satellite navigation and communications signals. Part of the spacecraft sub-systems were independently designed and developed by students, who were also responsible for integration, testing, and operations. IDEASSat was successfully launched into low Earth orbit on 24 January 2021, and then began mission operations. The spacecraft successfully demonstrated three-axis attitude stabilization and control, tracking, telemetry and command (TT&C), as well as flight software and ground systems that could support autonomous operation. The spacecraft experienced a critical anomaly 22 days after launch, followed by a 1.5-month communications blackout. The spacecraft briefly recovered from the blackout for long enough to replay flight data, which allowed for the cause of the blackout to be determined as an inability of the electrical power subsystem reset circuit to recover from an ionizing radiation induced single event latch-up. Although the mission was not completed, flight data obtained during the mission will help to improve the designs of future spacecraft in development at NCU. This paper will introduce IDEASSat’s final flight model design and implementation, integration, testing, environmental verification, and failure analysis, and will review the performance of the spacecraft during on-orbit operations. The results and experiences encountered in implementation and operations of the IDEASSat mission are presented here as a reference for other university small satellite teams.

1. Introduction

The 1957/1958 International Geophysical Year saw the launch of the first artificial satellites to study the near-Earth space environment (ionosphere and magnetosphere), as well as the global growth in research and educational institutions focused on the Earth and Space sciences. One of these institutions was National Central University (NCU), which was established in Taiwan in 1962, and has had a strong focus on space physics, satellite remote sensing, and payload development [1]. One important scientific need in the field of space weather is the need for an increased number of in- situ observations of the ionosphere (60–1000 km altitude) [2]. Ionospheric plasma either significantly refracts, attenuates, or both, radio frequency (RF) signals ranging from the medium frequency (MF, 300 kHz–3 MHz) and high frequency (HF, 3–30 MHz) bands that are used for terrestrial over the horizon communication, as well as the L-band (1–2 GHz), S-band (2–4 GHz), C-band (4–8 GHz), and X-band (8–12 GHz) frequencies that are used for satellite navigation and communications [3,4,5,6]. In response to this need, the NCU Department of Space Science and Engineering has developed the Advanced Ionospheric Probe (AIP) in situ plasma sensor that has been operational on the large FORMOSAT-5 spacecraft since September 2017 [7]. To increase opportunities for flight, as well as the number of observations available, AIP has been further miniaturized into the Compact Ionospheric Probe (CIP), with a mass of 0.47 kg and a size of 0.72 U (10 cm × 10 cm × 7.2 cm).

To develop spacecraft engineering capacity at NCU, the Ionospheric Dynamics and Attitude Subsystem Satellite (IDEASSat) was proposed in response to the Taiwan Space Industry Pioneering Project defined by the National Space Organization (NSPO) in 2017. The mission was envisioned to serve as a platform for in-situ ionospheric measurements using CIP, as well as an opportunity for project-based learning in spacecraft design and the first iteration of an NCU developed satellite avionics system. The project was approved and initiated in 2017, with the preliminary and critical design phases taking place between 2017 and 2019, and flight model fabrication, integration, and testing taking place from 2019 to 2020. The delivery deadline mandated by the selected SpaceX Falcon 9 launch was 27 November 2020. The development team was comprised almost entirely of graduate and upper division undergraduate students under the supervision of the PI, totaling approximately 20 students throughout the entire development and operation period. IDEASSat was the first spacecraft to be developed in-house at NCU, but also the second spacecraft of the International Satellite Program in Research and Education (INSPIRE) consortium, of which NCU is a member. As such, IDEASSat is also referred to as INSPIRESat-2 (IS-2) [8].

IDEASSat was successfully launched into orbit on 24 January 2021. After 21 days, the satellite stopped transmitting beacon signals and failed to respond to uplinked commands. After 1.5 months, the satellite resumed communication briefly for three days, which was sufficient time for commands to be uplinked ordering the spacecraft to replay saved flight data, allowing for the cause of the blackout to be pinpointed.

In the second section, this paper will introduce the implementation of the spacecraft sub-systems used in the final flight model (FM). Since the IDEASSat mission concept and critical design was presented by Duann et al., this article will describe the flight model design that was actually implemented, as well as the flight software, and related environmental testing in detail. Due to the limitations in funding and time, a single protoflight model of the full spacecraft was built, as opposed to a separate engineering qualification model of the entire spacecraft system. Section three will discuss relevant experiences encountered during the operation of the satellite on orbit, while also analyzing received flight data to evaluate the on-orbit performance of the spacecraft. The fourth section will review significant incidents encountered during the implementation of the flight model design and operations, as well as the lessons learned.

2. Materials and Methods—Implementation, Integration, and Testing of the IDEASSat Flight Model

IDEASSat was a 3U CubeSat whose mission objective was to observe plasma irregularities in the ionosphere. The elements of a space mission include launch vehicles, payloads, satellites, mission operations (MOS), and satellite tracking telemetry and command (TT&C) [9]. This section will introduce the various elements of the IDEASSat mission, including satellite sub-systems, payload, satellite flight software, and ground communication station and related environmental verifications.

2.1. IDEASSat Satellite Subsystems

As a spacecraft, IDEASSat was an integrated system composed of multiple subsystems, including the electrical power subsystem (EPS), telecommunication system (COMM), attitude determination and control subsystem (ADCS), command and data handling subsystem (CDH), spacecraft flight software (FSW), structure and mechanisms (STR), and thermal control subsystem (TCS). The entire spacecraft system was designed and integrated in-house, using a combination of commercial off the shelf (COTS) and self-developed subsystems.

The solutions used to implement the spacecraft subsystems are shown in

Table 1. Subsystem solutions used to implement IDEASSat FM and TRL at time of decommissioning. Subsystems developed and fabricated in-house are designated by an asterisk (*).

Subsystem	Solution	TRL
ADCS	Blue Canyon Technologies XACT-15 with NovAtel OEM-719 GPS Receiver	9
COMM (UHF)	SpaceQuest TRX-U Transceiver UHF Tape Measure Antenna *	9 9
COMM (S-band)	CPUT STX-C Transmitter CPUT Cubesat S-Band TX Patch Antenna	9 9
EPS	NCU EPS Controller Board * Li-Ion Battery Module * AzurSpace TJ Solar Cell Assembly 3G30A Solar Panel PCB *	8 9 9 9
CDH	Microsemi Smartfusion2 System-On-Module NCU CDH Interface Board *	9 9
FSW	IDEASSat Flight Software *	9
STR	NCU 3U Bus *	9
TCS	Thin Film Battery Heater * Passive Thermal Conduction Pathways *	9 9
Payload	Compact Ionospheric Probe *	8

, as well as their technological readiness level (TRL) at the time of spacecraft decommissioning. Subsystems developed in-house are further denoted with an asterisk. During the preliminary design phase of the mission, it was decided to use self-developed subsystems for those where there was a reasonable level of confidence that the flight model requirements and specifications could be met within a two-year development period. These included the EPS, CDH, FSW, STR, and TCS, as well as the UHF tape measure antenna and the CIP payload. Commercial-off-the-shelf (COTS) solutions were utilized for subsystems where in-house development was not deemed feasible given the time available and requirements defined. In this case, there was a strong preference for COTS solutions with prior successful flight heritage (TRL 9), in order to minimize risk and maximize reliability. Additional details of the individual subsystems will be presented in the following subsections.

Figure 1 shows the location distribution of the spacecraft components implemented in the flight model. The figure does not include the wiring and harnessing. The lower right corner defines the body frame coordinates for the spacecraft.

From the −Z to +Z direction, we use different colors to mark the different components inside the spacecraft, which are respectively the Compact Ionospheric Probe (CIP) payload, S-band transmitter module, CDH, EPS power control board, battery module, ADCS, UHF transceiver, UHF antenna deployment module. On the +Y side, there is an S-band patch antenna, a body-mounted solar panel on the −Y side, and a GPS receiving antenna and coarse sun sensor are also arranged near the +Z end of the +Y face.

IDEASSat’s main task was to perform in situ measurements of the ionosphere. Its orbit was set to a 500 km sun-synchronous orbit, which could pass over the same ground station 4 times a day. Of these four passes, two were at relatively low elevation angles where only limited communication was possible. The local time of descending node (LTDN) was constrained to being between 10:00 and 12:00. This was motivated by a desire to combine the IDEASSat observations with those of the FORMOSAT-5 Advanced Ionospheric Probe (AIP) at 720 km and 10:30 LTDN to resolve measurements at two altitudes with similar local time.

2.1.1. Structure and Mechanisms (STR)

The IDEASSat spacecraft structure was designed and fabricated in-house. The main material of the IDEASSat structure was made of aluminum alloy 6061-T6. The deployment mechanism of the solar panels was realized by metal 3D printing technology. The UHF antenna deployment module was made with Delrin based on the design of MinXSS-2.

All self-made hardware was connected with the PC-104 connector, while ADCS and UHF modules needed to use micro or nano D-sub connectors as the control interface. The assembly was divided into the −Z group and +Z group with ADCS as the midpoint. The assembly process was formulated to consider the configuration of the cables and harnessing, and the steps of staking the cabling to prevent unwanted motion during launch. The IDEASSat flight model underwent more than 10 fit-checks during the integration phase to check for tolerances, as well as to formulate the final FM assembly procedure. Considering the time required for the epoxy to cure in a 50 °C bake out, it took a total of 3 days to complete the assembly of the spacecraft FM.

2.1.2. Thermal Control Subsystem (TCS)

IDEASSat’s thermal control design was based on passive temperature control. According to the thermal analysis and the recommendations of the sub-system datasheets, some of the sub-systems were to be augmented with heat conducting metal for use as heat distributors or polyimide film heaters to maintain temperatures within the operating temperature range. Take the battery module as an example, since the battery operating temperature range was 0–40 °C, a thin film heater was added as a heat source in the design of the battery module. Considering that the battery itself was a stable heat source while operating, a pressurized heat dissipation pad was also added between the battery and the securing fixture as a passive heat dissipation element. In the case of the S-band transmitter, an aluminum block was added to serve as a heat conductor between the transmitter and the spacecraft chassis. The UHF transceiver was directly mated to the inside of the spacecraft chassis to facilitate heat conduction.

All sub-systems were equipped with temperature sensors, allowing FSW to determine the temperature status of each sub-system and switch the corresponding operation mode.

2.1.3. Electrical Power Subsystem (EPS)

The electrical power subsystem had 4 functions, including power generation, storage, distribution, and subsystem protection. The two deployable solar panels each had a string of 7 solar cells connected in series. The single body mounted panel had a string of 6 solar cells. The AzurSpace 3G30A Triple Junction Solar Cell Assembly was selected for the solar panels owing to its extensive flight heritage on university CubeSats such as the Miniature X-Ray Solar Spectrometer (MinXSS) from the University of Colorado, the solar panel design of which was also shared by IDEASSat [10,11]. In order to avoid damage to a single cell rendering an entire string unusable, a bypass circuit design was utilized between adjacent cells.

The EPS contained a self-made power distribution control board, with the flight model being the fourth revision since the initiation of the IDEASSat mission. Many of the revisions were based on the consideration of reducing power consumption from individual components. Most of the solid-state relay (SSR) subsystem power switches used in earlier revisions were replaced by power metal–oxide–semiconductor field-effect transistors (MOSFETs), and gate source resistors were added to the switch design to prevent damage caused by high currents, such as the possible electrostatic effects during assembly. The blocking diodes of the solar panels were also replaced by MOSFET elements. Based on the consideration that the power source and the load share the same ground, the switches of the subsystems were changed from the low-voltage side to the high-voltage side, after it was found that an earlier revision with the switches on the low-voltage side resulted in an inability to power off connected loads.

Table 2. Power consumption of IDEASSat subsystems.

Subsystem	Input Voltage (V)	Power (W)
ADCS	12	6.74
GPS Receiver	3.3	1.8
CDH	3.3	1.4
UHF Tx/Rx	6	10/0.2
S-Band Tx/Stand-by	Battery Voltage	5/0.6
CIP	12	3.5

shows the input voltage and power consumption of each subsystem. The operating range of the EPS is 3.3–8 V. The telecommunications subsystem had two frequency bands: an S-band transmitter and a UHF transceiver, with variable power consumption depending upon whether or not they were in transmit mode.

2.1.4. Telecommunication Subsystem (COMM)

IDEASSat used S-Band and UHF as dual-frequency satellite communications bands. The high-bandwidth S-Band transmitter was used for the downlink of scientific data and bulk replay of saved flight data. The UHF transceiver used the 70 cm amateur radio band for command uplink and beacon broadcasting. The beacon packets contained flight and tracking data, and were routinely transmitted by the spacecraft at 30 or 60 s intervals, depending upon operational mode. Beacon packets were also saved by CDH to the two onboard SD cards at the same time they were transmitted for potential future replay.

IDEASSat used the STX-C CubeSat S-Band transmitter module developed by the Cape Peninsula University of Technology (CPUT) for high bandwidth scientific and flight data transmission. According to “State-of-the-Art Small Spacecraft Technology [12]”, the technology readiness level (TRL) of this module had reached 7+. For the detailed configuration and related description of STX-C please refer to the description in [2]. S-band data packets were formatted according to Consultative Committee for Space Data Systems (CCSDS) specifications and encoded using half rate convolutional encoding for error correction.

The SpaceQuest TRX-U transceiver module was used to realize the execution of command uplink and beacon broadcasting using the UHF amateur radio frequency band. The antenna design was based on the monopole antenna made with spring steel tape in the MinXSS mission [11]. IDEASSat had three beacon formats as shown in

Table 3. IDEASSat beacon types.

Beacon Type	Beacon Size (Byte)	Description
Lite	360	Normal packet split into 9 consecutive 40-byte packets (default).
Normal	204	Format similar to AX.25. Content includes housekeeping data.
Short	48	The short version, only includes critical state of health data.

.

In the preliminary design, the packet format was similar to AX.25 and contained the housekeeping data of each subsystem. Cyclic redundancy check (CRC) 16 checksums were included for error detection. However due to lack of prior experience with spaceborne packet radio, the preamble specified in the AX.25 structure was not implemented [13]. The purpose of the preamble is to allow for more reliable signal acquisition. During testing, as a result it was found that the packet error rate (PER) of the original (normal) packet was unacceptably high. Since the PER is proportionate to packet size, an unconventional quick fix solution was implemented whereby the size of the beacon packet was reduced. Through end-to-end communication tests, it was found that arranging the original packet into nine smaller packets for transmission (lite packet type) resulted in a lower PER. This also proved that the lite format of multiple headers was helpful for the detection of packets at the reception end.

2.1.5. Attitude Determination and Control Subsystem (ADCS)

IDEASSat required high attitude stability when performing scientific measurements using CIP, as well as to orient the S-band patch antenna towards the ground station. Pointing knowledge and control requirements were to 0.25 degrees accuracy. Therefore, ADCS was a more critical part of the IDEASSat spacecraft. IDEASSat used the Blue Canyon Technologies XACT-15 ADCS for attitude determination and control, which is TRL-9 [11]. The XACT-15 includes three magnetorquers and reaction wheels for attitude control; a star tracker, coarse sun sensor, and magnetometer for attitude determination, and an integrated GPS receiver (NovAtel OEM-719) as a source of orbit state and GPS time information that could be used with a built-in orbit propagator, and an inertial measurement unit (IMU) for attitude propagation. Under the requirements of high pointing and high altitude for stable attitude, the XACT-15 met the ADCS requirements of IDEASSat. XACT execution was divided into two modes. Upon separation from the launch vehicle, the spacecraft would enter emergency operation mode at first. The coarse sun sensor and IMU would be used to execute sun point mode to maximize power generation. When the spacecraft entered the nominal operation mode, XACT would switch to the fine reference mode where surface, inertial, and local velocity local horizon (LVLH) pointing capabilities were available. At this time, the information received by the star tracker would be used as the basis for the absolute attitude, and the time and position information obtained by the GPS would be used to determine and propagate the orbit.

2.1.6. Command and Data Handling (CDH)

IDEASSat used the industrial-grade SmartFusion2 M2S050-FG484I System-on-Module (SOM) from Emcraft as the processing core of CDH. The SmartFusion2 System on Chip (SoC) combines a 32-bit ARM Cortex-M3 processing core, integrated hard IP I/O and FPGA architecture on a flash memory base on a single chip [14]. The SmartFusion2 also incorporates features attractive for use in space operations, especially considering the need for autonomous operation in a high ionizing radiation environment. These features include built-in single error correction/double error detection (SECDED) that can assist in the correction of data corruption from single event upsets, built-in watchdog timer to recover from software hangs [14,15], as well as past radiation test results indicating resilience to single event effects [16,17]. The SOM was mounted on a self-made interface card, which provided physical connections with other subsystems through the PC/104 and D-sub interface.

The self-developed interface card was equipped with a spare real time clock (RTC) as a redundancy for satellite restart; and had two SD memory cards as storage space for scientific data, beacon data, and important parameters. In order to assist in ground testing, the interface card also had a software burn-in function and a test interface for ground support equipment (GSE).

Table 4. IDEASSat data interface.

Protocol	Implementation	Number
I2C	RTC/S-band/EPS	3
SPI	Micro SD card/S-band	3
UART	GSE/ADCS/UHF/CIP	5

shows the communication protocols that IDEASSat used. The data interface protocols supported by CDH included I2C, SPI, and UART. Due to the limited number of serial interfaces of the SOM itself, some serial interfaces were provided by synthesizing related communication protocols through the FPGA.

2.2. Payload: Compact Ionospheric Probe (CIP)

CIP is an in-situ plasma sensor which was developed by the National Central University Space Payload Laboratory. Its predecessor was the scientific payload of FORMOSAT-5: the Advanced Ionospheric Probe (AIP). CIP reduces the volume of the instrument to 1 U and retains all the functions of ionospheric observation available with AIP. The sensor needs to point to the ram direction of the spacecraft in order to perform scientific measurements.

CIP integrates a number of technologies for measuring the ionosphere.

Table 5. CIP built-in observation modes and corresponding plasma parameters.

Instrument	Plasma Parameters
Planar Langmuir Probe (PLP)	Electron temperature
Ion Trap (IT)	Ion density
Retarding Potential Analyzer (RPA)	Light/heavy ion mass ratio Ion temperature Ion ram speed
Ion Drift Meter (IDM)	Ion arrival angles

shows the operational modes included in CIP in a time-sharing manner, as well as the plasma parameters that can be derived.

From the composition of the CIP structure, it can be understood that the CIP is a laminated structure integrating multiple PCBs. Figure 2 shows the overall architecture of CIP, which is composed of the front-end aperture and meshes module (AMM), analog preprocessing unit (APU), digital control unit (DCU), and power management unit (PMU). The corresponding functions are:

• AMM: A sensor for measuring plasma, which converts the measured variable into a voltage/current signal.
• APU: Converts the analog voltage/current of the sensor into a digital signal.
• DCU: Controls all of the analog to digital converters (ADCs) and digital to analog converters (DACs) of the APU. It monitors the temperature of CIP circuit boards and communicates with CDH.

2.3. Spacecraft Flight Software (FSW)

The spacecraft autonomous flight software (FSW) was developed in-house using C, Verilog, and assembly language. FSW could continuously check the status of all subsystems running in the background of the program, and transition between the corresponding operation mode according to the state of the subsystem telemetry. When the spacecraft passed within the line of sight of ground stations used for command and control, it could perform related actions in response to the commands from the ground station and also adjust the spacecraft attitude to orient the S-band patch antenna at the ground station when needed. IDEASSat’s flight software had two major modes: emergency and nominal. There were 2 sub-modes in emergency and 3 sub-modes in nominal, as shown in

Table 6. IDEASSat operating modes.

Major Mode	Sub-Modes
Emergency	Phoenix mode, Safe mode
Nominal	Charging mode, Transition mode, Science mode

. Mode transitions were based on the state of charge (SOC) and whether the spacecraft was located in sunlight or eclipse.

FSW variables were normally stored in the OBC SRAM and are protected by the built-in single error correction and double error detection (SECDED) feature of the SmartFusion2 [14,18,19]. To reduce the recovery time needed following spacecraft hard resets, FSW setting variables normally stored in volatile SRAM were written to the OBC SD cards every six hours or at mode transitions. Since SD Cards are a nonvolatile storage medium, the logged FSW settings could be read and re-implemented by FSW upon reboot, removing the need for manual reset by flight controllers.

The emergency mode was a low power consumption mode intended to facilitate rapid recovery from low SOC, while also minimizing actions not related to survival. The corresponding sub-modes are phoenix and safe.

Phoenix mode was an extremely low power consumption mode to deal with emergencies caused by extremely low SOC or rapid decline in satellite SOC. FSW would enter phoenix mode following boot-up, with a 30 min passive wait time upon the first boot-up. This satisfied launch provider requirements for the spacecraft to remain in a passive state for 30 min following launch vehicle separation. Most sub-systems would not be powered on in phoenix mode, with the only subsystems powered on (EPS, CDH, UHF) related to the bare survival of the spacecraft.

Safe mode was responsible for handling the protection settings of low SOC or anomalous subsystem telemetry under nominal mode. This mode would keep the spacecraft in a safe condition of basic operation and timely charging. Different from phoenix mode, this mode would enable the ADCS into a sun pointing mode using the coarse sun sensor (CSS) to rapidly charge the spacecraft batteries. The use of the CSS reduced the number of sensors required to find the sun.

Nominal operations consisted of a charging mode using fine reference sun pointing in sunlight, as well as autonomous ground station pointing for S-band data downlink. Charging mode was a configuration for fast charging of satellites and scientific data transmission in the day side sector. Compared with safe mode, ADCS would perform fine sun pointing using more ADCS sensor inputs to charge the satellite more efficiently [11]

Science mode meant that the satellite could collect scientific data when in the night side sector and the total power was sufficient. Scientific observations were to be performed when the spacecraft was in eclipse, which is consistent with scintillation causing equatorial plasma bubbles being a nighttime phenomenon [20].

Transition mode was responsible for handling the situation in which the spacecraft was in eclipse but the total power was insufficient for complete scientific data collection. In this mode, CIP would not be turned on, but the spacecraft would pass through the eclipse sector with lower power consumption to avoid total power reduction to safe mode.

Figure 3 shows a flow chart of the transition conditions between the different operating modes, while

Table 7. Subsystem status in all operating modes. ADCS operating mode denoted in parentheses. “On Command” refers to activation by command uplinked from ground station.

Subsystems	PHOENIX	SAFE	CHARGING	SCIENCE
EPS	ON	ON	ON	ON
CDH	ON	ON	ON	ON
UHF	ON	ON	ON	ON
ADCS	OFF	ON (Sun Point)	ON (Fine Reference Point)	ON (Fine Reference Point)
S-Band	OFF	On Command	On Command	OFF
CIP	OFF	OFF	OFF	ON

shows the power state of each subsystem in each operating mode. SOC was judged by the open circuit voltage, and the open circuit voltage was calculated by the equivalent series resistance (ESR). The open circuit voltage would not be changed by the actual circuit switching, so there was no problem that the SOC would rise or fall immediately when a subsystem was turned on or off.

Table 8. IDEASSat operating mode transition levels.

Mode Transition	SOC (%)	Vop	Actions on Transition
Safe to Phoenix	25	7.0	Beacon period set to 60 s.
Phoenix to Safe	40	7.2	Turn on ADCS. Beacon period set to 30 s.
Charging to Safe	50	7.4	ADCS to coarse sun pointing.
Transition to Safe	50	7.4	ADCS to coarse sun pointing.
Science to Safe	50	7.4	Turn off CIP. ADCS to coarse sun pointing.
Safe to Charging	75	7.8	ADCS to fine reference sun pointing.
Charging to Science	82	8	Turn on CIP. ADCS to LVLH.
Science to Charging	-	-	Triggered by transition from eclipse to sunlight. ADCS to fine reference sun pointing.
Charging to Transition	<82	8	ADCS to LVLH.
Transition to Charging	-	-	Triggered by transition from eclipse to sunlight. ADCS to fine reference sun pointing.

shows the transition standards for various operating modes, as well as notable actions taken upon transition. Through the actual measurement result of the SOC corresponding to the open circuit voltage ($V_{op}$) of the battery module (Figure 4) and the simulation of the total power change of the spacecraft starting from safe mode (Figure 5), it was decided to set a 15–20% difference between the SOC entry point and the SOC exit point of the operational mode transitions from phoenix to safe and safe to nominal.

Figure 5 shows the simulated variation in spacecraft SOC as a function of time using the mode transition levels previously defined in Figure 3, starting from the lowest possible SOC for safe mode of 40%. Mode transition levels are denoted by the horizontal lines, which are defined along the right y-axis. A high frequency see-saw variation in SOC can be seen, corresponding to rapid battery charging under sunlight and discharge during eclipse. It can be seen that spacecraft SOC first reaches the nominal mode threshold of 75% (safe to charging) approximately 16 h after the start of the simulation, further reaching the changing to science transition level of 82% approximately 20 h after the start of the simulation. Although the spacecraft SOC continues to fluctuate depending upon sunlight conditions in the time following, the SOC does not fall below the charging to safe transition level of 50%, which would cause the spacecraft to cease nominal operations and return to safe mode. These mode transition levels therefore make individual operating modes “easy to enter but difficult to exit”.

2.4. Ground Station

A TT&C ground station was installed at NCU for the purpose of supporting the IDEASSat mission as well as future small satellite missions. The UHF and S-band components of the ground station will be introduced in the following subsections.

2.4.1. S-Band Ground Station

The S-band ground station at NCU uses a COTS solution provided by Comtech Telecommunications Corp and the QubeFlex satellite modem from Teledyne Paradise Datacom for signal reception and signal processing [21,22]. The use of the COTS modem was motivated as a result of the self-developed GNU Radio signal processing software exhibiting an unacceptably high bit error rate when operated at S-band. The demodulated S-band data packets are transmitted to a PC using the user datagram protocol (UDP), and depacketized using self-developed Matlab processing software.

The IDEASSat S-Band ground system only had a receiving function. Figure 6 is the ground receiving station architecture of IDEASSat S-band. A 3.4 m diameter parabolic dish antenna with an L-band/S-band feed is installed on a rotator inside a radome. A 2200–2400 MHz bandpass filter (BPF) was also installed behind the feed in order to block interference from S-band Wi-Fi and Bluetooth signals. A low noise amplifier (LNA) is included as part of the COTS Comtech antenna solution, serving to amplify signals received by the antenna feed to make up for losses while propagating along the cable connecting the antenna to the satellite modem. The satellite tracking software included as part of the COTS Comtech system can automatically update the two line elements (TLEs) for tracked satellites via the Internet, and can continuously receive GPS time as the basis for clock synchronization. A photograph of the S-band ground station during construction is shown in Figure 7, with the antenna exposed prior to completion of the radome.

2.4.2. UHF Ground Station

The UHF/VHF ground station at NCU consists of COTS amateur radio antenna equipment and amplifiers combined with a COTS software-defined radio transceiver and self-developed signal and data processing software. The construction and integration of the aforementioned components was performed in-house in collaboration with local radio amateurs. The outside components of the UHF/VHF ground station are comprised of Hygain VHF and UHF cross Yagi antennas, as well as a YAESU G-5500 rotator. The free Gpredict software package was used to implement spacecraft orbit prediction, Doppler correction, and satellite tracking control. An RF switch is used as the transmit/receive (Tx/Rx) link conversion, and a National Instruments USRP-2900 Software Defined Radio (SDR) is used for signal reception and command transmission. The open-source GNU Radio software package is used for signal processing for the SDR, including modulation and demodulation [23]. Matlab was used to implement the front end of the mission operations software, which was used for depacketization and visualization of the received bitstream from the SDR, as well as encoding of commands to be transmitted. Received beacon packets were stored in text and binary format.

The block diagram of Figure 8 is the architecture of the UHF ground station. The NI USRP-2900 SDR is used for both downlink Rx (NI USRP-2900 Rx) and as the signal source for command Tx (NI USRP-2900 Tx). A low noise amplifier (LNA) is installed on the Rx line to mitigate line loss, while two preamplifiers are implemented on the Tx line, the first of which (preamp 1) is required to boost the low output power of the USRP-2900 to a level high enough to drive the larger 80 W amplifier (preamp 2). In the future, it will be simplified to reduce the number of RF switches. In order to reduce introduced noise, the amplifiers on the Tx line will also be replaced with one that can accept a lower input, so that only one preamplifier is needed to achieve the required transmit power.

2.5. Environmental and Functional Test

In addition to functional testing during the integration of IDEASSat, the spacecraft also needed to comply with certification requirements imposed by funding agencies and the launch provider. IDEASSat was initially assembled in flatsat format to verify subsystem compatibility. The assembled flight model then underwent end-to-end communication tests, as well as vibration, sinusoidal burst quasi-static load, and thermal vacuum tests before delivery. Due to funding constraints, there was no engineering model for separate qualification and acceptance testing. Therefore, protoflight test standards were used for flight model verification [24].

2.5.1. Flatsat

A flatsat refers to a complete tabletop integration test of spacecraft subsystems before the final flight model is assembled [25]. The purpose is to confirm that there will be no interference or abnormality between sub-systems in all operating modes. Since the correct ADCS information cannot be obtained, virtual ADCS information was provided in FSW test code when performing the ground test for operating mode transitions. The flatsat layout of IDEASSat as partly assembled is shown in Figure 9. During the flatsat stage, the main task was to confirm whether the subsystem functions are normal in various operations, and whether the corresponding subsystems are normally turned on. Additional functional testing also took place at this stage to ensure that the spacecraft EPS was capable of charging the batteries under sunlight, as well as regulating power distribution to the spacecraft subsystems. FSW mode switching, as well as subsystem and system level reset and power cycling capability, were also verified. The spacecraft deployment switches and mechanisms were also tested to verify that the spacecraft was capable of powering on following launch vehicle separation and deploying the UHF antenna and solar panels.

2.5.2. End-to-End Test

In addition to the functional verification of the COMM subsystem itself, end-to-end tests were performed to verify two-way communications between IDEASSat and the NCU ground station. Tests were performed with ranges of 10 km and 40 km performed prior to and following FM integration. While initial tests were relatively successful, anomalously high bit errors in UHF beacon packets received by the ground station were encountered following successive tests. The spacecraft UHF transceiver ultimately failed to transmit, although it was noted that the transceiver was still capable of receiving commands transmitted by the ground station in this state. This fault necessitated partial disassembly of the spacecraft FM to de-mate the UHF transceiver and antenna. It was found that due to the poor impedance matching of the self-made antenna, the transmit line of the UHF transceiver was ultimately destroyed by the reflected energy from the antenna during signal transmission. After emergency servicing by the manufacturer and replacement of the UHF antenna with a properly impedance-matched model, the UHF transmission and reception functionality were successfully verified using a 40 km end-to-end test.

Table 9. 40 km end-to-end test result.

Beacon Format	Short	Lite	Normal
Full Packet Loss (%)	0	0	0
Partial Packet Loss (%)	-	50	-
Packet Error (%)	56.5	100	100

is the result of the 40 km end-to-end test, the packet format used by the satellite and the reception results from the ground station. Full packet loss means that the ground station did not receive the beacon packet sent by the satellite at all. Because the lite beacon is composed of 9 packets, as long as one of the packets is missing, it is classified as partial packet loss. Packet error refers to any bit errors present in the received packet, as determined via the CRC-16 checksum test. Although the three packet formats could be received over a distance of 40 km, the lite beacon format was found to have the most complete content. Even if the packet error of lite is 100%, lite could actually be parsed as 9 independent packets, so it was easier to parse the result than the other two formats. The shorter packets also forced continuous resynchronization and clock recovery, which benefitted signal acquisition in a similar manner as the AX.25 preamble that was not implemented [13].

2.5.3. Vibration Test

Per launch provider requirements [24], IDEASSat was subject to vibration testing [26], which consisted of a sine burst (quasi-static load) test [27] and random vibration test [28] on all 3-axes. The specifications of the sine burst test are shown in Figure 10 and Figure 11, which show the g-force acceleration of the vibration table as a function of time for the spacecraft Z-axis and X/Y-axes, respectively. The acceleration is in units of g = 9.8 m s⁻². In order to reach the 100% vibration level shown in these figures, the amplitudes of the vibration table had to be sequentially ramped up from 25%, 50%, and 75% levels. As a result, the spacecraft was actually subjected to four sine bursts of increasing amplitude along each axis. It can be seen that per launch provider requirements, the Z-axis was subject to a maximum g-force load of 9.369 g, compared to 14.99 g along the two other axes.

The specification of the random vibration test is shown in

Table 10. Random vibration test specification.

Band	Power Spectral Density (g2 Hz−1)
20 Hz	0.0088
100 Hz	0.0088
300 Hz	0.0252
600 Hz	0.0252
740 Hz	0.07
850 Hz	0.07
2000 Hz	0.01288
GRMS	7.75 g
Duration	1 min

, which shows the profile of the power spectral density envelope at different frequency bands between 20 and 2000 Hz. These test levels were defined according to launch provider protoqualification requirements, which specified a 3 dB margin above the maximum predicted environment (MPE) [24]. During the random vibration test, the spacecraft was subjected to a spectrum of multiple vibration frequencies defined by this envelope with the overall g-force acceleration level defined by the GRMS (root mean square) being 7.75 g. The duration of the test was 1 min along each of the three axes of the spacecraft.

During testing, the spacecraft was enclosed inside a COTS ISISpace 3U TestPOD approximating the mechanical interface between the spacecraft and the deployer, as shown in Figure 12 [29]. The sine burst and random vibration tests on each axis were preceded by a resonance survey to identify the normal modes of the spacecraft. These results were compared to a resonance survey performed after the two vibration tests, with the pass criteria being shifts in the normal mode frequencies of less than 10%, which was successfully attained.

After the first vibration test of the IDEASSat flight model, the spacecraft showed no signs of visible damage, it was found to power up normally, and functional verification was successfully completed. However, when the UHF transceiver was damaged due to poor impedance matching, the spacecraft had to be partially disassembled for de-mating, and was subjected to a second vibration test following re-integration.

During the second vibration test, a single nut used to secure a connector inside CIP separated, due to lack of epoxying. After the functional testing, it was found that although the separated nut did not affect the function of CIP, partial disassembly would again be necessary to retrieve the separated component to mitigate the risk of possible short circuit. During this process, the nut was reattached and properly epoxied. A survey was also performed to verify that all fasteners and connectors were properly epoxied or staked. After discussions and evaluations by the launch provider, the spacecraft team, and the payload team, it was determined that a third vibration test would not be necessary as the noncompliant fixture had been corrected and the spacecraft was verified to be functional.

2.5.4. Thermal Vacuum Cycling Test (TVCT)

Per NSPO recommendations, IDEASSat was subjected to thermal vacuum testing following flight model integration. The temperature range selected corresponded to the maximum and minimum predicted temperatures from thermal analysis with an additional margin added [30]. Figure 13 shows the temperature cycle setting of TVC. The temperature was cycled between 0 and 40 °C during the initial survival cycle, followed by 8 TVCT cycles. The TVCT temperature range was between 5 and 35 °C, with each cycle lasting a total of 5 h and hot/cold soaks lasting 1 h. The selected hot and cold temperatures were based on the operating temperature range of the battery module, which had the narrowest temperature range of all the subsystems. These temperatures were attained during the TVCT test, with the pressure maintained at below 3.75 × 10⁻⁵ Torr. The spacecraft was powered on during the TVCT test. A limited performance test (LPT) was performed at room temperature and at the beginning and end of each hot/cold soak. The LPT consisted of using the OBC to poll the various temperature sensors throughout the spacecraft to establish whether the operating temperature limits were exceeded, while also individually commanding soft resets of the individual spacecraft subsystems to verify that they were functional and would respond to commands.

Heat exchange for the TVCT was by way of heat conduction from a heat exchange plate located in a vacuum chamber. In order to prevent the solar cells from rupturing, the +/−X-sides and +Y-side of the spacecraft chassis were used as the thermal interface, as shown in Figure 14. Red copper blocks with lower heat capacity were used as heat distributors to the +/−X-sides, while stainless steel plates were used to apply pressure on these copper blocks to achieve a uniform heating effect.

To avoid multi-path interference which occurs when the communication subsystem transmits inside the closed vacuum chamber, no signals were transmitted during TVCT. Before and after TVCT, the weight of the spacecraft was measured to ensure that the spacecraft was compliant with outgassing requirements of less than 1% total mass loss. The communications subsystem was also subject to functional verification.

2.6. Delivery, Launch Vehicle Integration, and Launch

Following re-integration and the second vibration test, permission to ship was granted to the spacecraft team by the launch services provider ISILaunch. IDEASSat was delivered to ISILaunch integration facilities in the Netherlands for deployer integration on 1 December 2020. Due to pandemic travel restrictions, the spacecraft team viewed the integration process remotely, providing input to the launch provider operators when needed.

At the time of delivery, it was found by ISILaunch operators that the deployable solar panels were warped, potentially due to deficiencies in PCB materials, as shown in Figure 15. The red circle in Figure 15 shows the stopper at the edge of one of the warped solar panels, which was not anodized and would be pressing against the deployment rail of the deployer once inserted. This would increase the risk of cold welding between the stopper and the deployment rail when subjected to vacuum, while also increasing the friction between the stopper and the rail during the deployment process. Both of these factors would increase the risk of unsuccessful deployment.

The ISISPACE QuadPack was used as the spacecraft deployer for IDEASSat, which has one dynamic rail that slides forward and outward when the deployer door is opened [31]. After discussion between the spacecraft team and ISILaunch engineers, it was suggested that the risk of deployment failure would be reduced if the spacecraft could successfully be induced to move through the application of sufficient force at deployment time. This is because dynamic friction coefficients are generally smaller than static friction coefficients.

ISILaunch engineers proposed a solution to use the dynamic rail to provide an additional impulse at deployment. Figure 16 shows the orientation of the spacecraft inside the deployer. The red circle indicates the position of the QuadPack dynamic rail. In order to reduce the risk of cold welding and friction, while also providing an initial impulse to the spacecraft upon deployment, the spacecraft was oriented such that stoppers on the solar panel with the largest deflection due to warping were in contact with the dynamic rail of the deployer. Improvised testing on the ground was difficult, since the spring coefficient of the deployer pusher plate was insufficient to counter the additional friction along the deployment rails at 1 g gravity. However, it was verified that the motion of the dynamic rail was sufficient to induce the spacecraft into motion from rest. The solution was therefore considered to be the best available option in terms of risk mitigation, since the return of the spacecraft for solar panel replacement was not possible programmatically.

3. On Orbit Operations and Anomaly Analysis

IDEASSat was successfully launched into a near circular orbit of 525 km altitude from Cape Canaveral, Florida on 24 January 2021 aboard the Transporter 1 SpaceX Falcon 9 launch. Upon power on and activation, IDEASSat FSW would enter safe mode or phoenix mode depending on the battery SOC, entering nominal operations only when the SOC allowed and a ground station command permitting nominal operations was received. During this period, the spacecraft would broadcast a beacon signal over the UHF amateur band at a fixed period. Amateur radio operators around the world could receive IDEASSat beacon signals, and could also help to provide tracking data through the open-source satellite ground station receiving network—SatNOGS.

The first beacon signal from IDEASSat was received at T + 4 h by an amateur radio station in Germany, indicating that the spacecraft had survived launch, deployment, and had powered on successfully [32]. The flight data in this beacon packet as displayed by the IDEASSat mission operations software interface is shown in Figure 17. The content of the satellite beacon packets was mainly housekeeping data for the spacecraft, including the temperature and power status of the spacecraft subsystems, as well as reboot counts, received command counts, as well as bad command counts. Notably, the spacecraft was confirmed to have booted in safe mode, with the expected subsystem power states. The temperatures, voltages, and current draws of the spacecraft subsystems were within acceptable operational ranges. It should be noted that the anomalously low S-band temperatures were not real, and were due to the S-band transmitter not being powered on in safe mode. The spacecraft ADCS was confirmed to be engaged in Sun point mode, indicating that 3-axis attitude control had been activated. The battery state of charge was also found to be a very healthy 95.28%.

Although IDEASSat was tracked successfully by ground stations in the SatNOGS network, as well as at INSPIRE partner institutions, the UHF ground station at NCU was initially unable to successfully communicate with the spacecraft following launch. This was found to be due to long-term environmental degradation of the outside components of the ground station, as well as the output power of the USRP-2900 being insufficient to drive the Tx amplifier. This was not detected during the end-to-end test, as the range of the spacecraft on-orbit was considerably farther than during the end-to-end test, ranging from 522 to 2600 km.

This anomaly was rapidly corrected through replacement of the antennas and cabling, as well as the installation of a preamplifier between the SDR and the primary UHF amplifier. These problems were factors not considered in the link budget calculation during the design phase. Figure 18 shows the content displayed by the NCU ground station software upon receiving the satellite beacon for the first time on 1 February 2021. Immediately following launch, the spacecraft was maintaining a stable safe mode, with a high SOC of 97.34% and 3-axis attitude control. It is notable that FSW had autonomously rebooted the UHF transceiver twice by this time, while the ADCS had been rebooted once.

Table 11. IDEASSat on-orbit event log.

Date	Satellite Operation	Ground Station Operation
2021-01-25	Safe mode.	Flight data downlink from SatNOGS. Anomaly: NCU ground station unable to receive beacon.
2021-01-26	Safe mode.	Flight data downlink from SatNOGS. NCU ground station servicing start.
2021-02-01	Safe mode.	NCU ground station servicing complete. Flight data downlink from NCU ground station and SatNOGS.
2021-02-02	Safe mode. Anomaly: Autonomous beacon format change into Normal mode.	Flight data downlink from NCU ground station and SatNOGS.
2021-02-15	Anomaly: COMM blackout.	No signal received at NCU ground station and SatNOGS.
2021-02-25	Anomaly: COMM blackout.	UHF SDR power output found to be insufficient to drive primary UHF amplifier at NCU ground station. Preamplifier added.
2021-03-03	Anomaly: COMM blackout.	Ground station Tx power verified to be nominal following preamplifier installation.
2021-04-02	Safe mode. Beacon Tx resumes. Beacon is changed into Lite mode after receiving command.	Commanded IDEASSat to replay saved flight data. Commanded IDEASSat to change beacon format to Lite. Flight data downlink from NCU ground station and SatNOGS.
2021-04-04	Anomaly: COMM blackout.	No signal received at NCU ground station and SatNOGS.
2021-09-02	Decommissioning Review

shows a log of notable events during the periods of spacecraft contact, indicating the status of the NCU ground station and the spacecraft at key time points, as well as key events occurring at that time. The spacecraft maintained a stable safe mode with high SOC from launch until 15 February 2021, during which flight data was continuously downlinked via SatNOGS and the NCU UHF ground station. Contact was lost with the spacecraft between 15 February and 2 April, during which ground stations that had previously been able to receive IDEASSat beacon packets were unable to do so, indicating that the cause of the anomaly was on the spacecraft end. Detailed analysis of this critical anomaly will be presented in more detail in Section 3.3. The spacecraft briefly recovered between 2 April and 4 April, during which commands were successfully uplinked to the spacecraft commanding the replay of saved flight data. Contact was again lost with the spacecraft following this period, with no recovery detected in the following months. The spacecraft was decommissioned on 2 September 2021, following the conclusion of the previously defined six months mission lifetime. Key events during the on-orbit lifetime of the spacecraft will be described in the following sections.

3.1. Apparent Single Event Effect

The spacecraft maintained a stable safe mode from launch till February 15. During this time, a few anomalies were detected in the received flight data that were not critical, but were nonetheless unexpected. Following deployment, the spacecraft began beaconing every 30 s using the lite packet format previously defined in Table 3. FSW was designed such that the beacon packet format could only be changed upon received command. The satellite beacon format autonomously changed from lite to normal on February 2, a situation that persisted, even following the 1.5 month COMM blackout, and was not corrected until reception of a ground station command resetting the packet format on 2 April.

It is likely that this anomaly was caused by a single event effect (SEE) caused by high-energy particles. There are many ways in which high-energy particles can affect spacecraft electronics [33]. In this case, it is likely that the culprit was a single event upset (SEU), which caused corruption of the OBC SRAM memory address where the FSW variable controlling the beacon packet format was mapped. Although single error correction and double error detection (SECDED) was implemented on the OBC SmartFusion2 SRAM [15,18,19], an SEU affecting more than one bit would not be correctable. Additionally, the corrupted variable would be logged to the SD cards every six hours in safe mode, causing the error to persist following a power cycle. In such an event where the beacon format variable was corrupted, FSW would default to broadcasting the normal packet format. An important lesson learned is related to SEU precautions. For future OBCs designed using a similar hardware architecture with periodic logging of FSW variables to the SD-cards, we will prefer to use a higher-level SmartFusion2 model, such as the M2S090, with built-in error correction code (ECC) memory or implement error correction algorithms such as BCH code or Reed–Solomon code. Considering the use of SD cards for non-volatile data logging, the SEU rate in SD cards is very low, according to NASA/TP—2020–5008734, State-of-the-Art, Small Spacecraft Technology [12]. If the SD card is to be replaced by an even more robust option with respect to SEUs, magnetoresistive random-access memory (MRAM) or ferroelectric random-access memory (FRAM) can be considered [12].

3.2. UHF Communication Anomalies

While operating, the IDEASSat FSW would monitor the operating status of each spacecraft subsystem in the background, and restart a subsystem if its operational telemetry exceeded the defined operating limits. Figure 19 shows the time distribution of the UHF transceiver reboot count from spacecraft deployment to 14 February. Before 2 February, the UHF transceiver was restarted a total of four times. By 14 February, the number of UHF reboot counts had grown to 13 times, surpassing the number of resets of all of the other spacecraft subsystems. Conditions that would trigger a reset of the UHF transceiver by FSW are command timeout, electrically erasable programmable read-only memory (EEPROM) error, anomalous frequency settings, or undervoltage/overcurrent as detected by the EPS. The number of resets after 2 February shows a linear distribution, suggesting that the reason for the restarts was likely to be from a persistent source, such as that caused by electromagnetic interference within the spacecraft or abnormalities in the UHF module itself. Unfortunately, FSW was configured in such a way that the cause for any subsystem reset was only logged in beacon packets for the 15 min following the reset. This is a lesson learned, with later revisions of FSW logging reboot causes in a rolling stack.

Another non-critical anomaly identified from IDEASSat flight data was a persistent increase in the command reject count logged by FSW. Figure 20 shows the variation in command reject count as a function of time. The IDEASSat UHF transceiver identified valid received signals as those prefixed with the appropriate sync word. The bit stream from such signals was then passed to the OBC and FSW for processing, If the received bitstream did not match the formatting or length of a valid IDEASSat command, it would be rejected by FSW and the command reject count incremented.

According to the linear distribution trend in Figure 20, it can be seen that the spacecraft encountered about 45 command rejections per day. Assuming that the content of what is identified as a command packet by UHF using the sync word did not correspond to any valid command, that is, only the first three bytes of the command string were correct, the expected probability according to the binomial distribution is $1/2^{8\times 3}$. Considering that the data rate of UHF was 9600 bps, the expected command reject count in a day due to random noise matching the sync word would be $9600 bps \times 86,400{ \mathrm{s} day}^{-1}\times \frac{1}{2^{24}}\cong 49.34{ day}^{-1}$. The result can be regarded as being slightly over-estimated, but is nonetheless close to the command reject rate in Figure 20. Random noise in the environment may have been the main reason for linear growth in the command reject count.

3.3. Thermal Performance

Figure 21 shows the temperature ranges of the various IDEASSat subsystems during on-orbit operations (light blue bars) compared to their respective operational temperature ranges (orange bars), as well as those measured during thermal vacuum testing (dark blue bars), and values predicted using the Thermal Desktop analysis software (green bars). From top to bottom, the subsystems shown include the battery module, the body mounted (PV0) and deployable solar panels (PV1 and PV2), the UHF transceiver, the EPS controller board, the CDH OBC, as well as the ADCS inertial measurement unit (IMU), star tracker (Track), and exterior.

It can be seen that the on-orbit temperature ranges all fell within the operational limits, indicating that good thermal margins were achieved. It can also be seen that the actual on-orbit temperatures generally trended higher than those predicted by the thermal analysis and encountered during thermal vacuum testing. In the case of the solar panels, the discrepancy between thermal vacuum and on-orbit temperatures is not surprising, given that the panels were not illuminated in the thermal vacuum chamber, or subject to extreme radiation to cold space. In the case of the EPS, CDH, ADCS IMU, and the battery module however, this suggests that the heat dissipation of these subsystems on orbit may have been higher than in the thermal vacuum testing or assumed during thermal analysis, potentially due to differences in operating state.

The relatively small on-orbit temperature ranges of the UHF transceiver and the battery module are worth mentioning, given the unique operating conditions and constraints of these two locations. The UHF transceiver was subject to a relatively high level of power dissipation due to regular beaconing every 30 s. The UHF transceiver was therefore attached directly to the inside of the spacecraft chassis, allowing the chassis to serve as a heat sink for the transceiver, which proved to be effective in constraining the transceiver on-orbit temperatures to relatively benign values. The lithium-ion battery module had one of the narrowest operational temperature ranges of the entire spacecraft. As such, the battery cells were kept relatively thermally isolated from the rest of the spacecraft, with the main thermal interface being the electrical connector and the standoffs connecting the module to the EPS controller board. Although the on-orbit temperature range of the batteries was slightly higher than predicted using Thermal Desktop, the range of values was nonetheless relatively constrained and well within the operational limit, as well as that predicted during thermal vacuum testing.

The on-orbit temperature ranges of the solar panels are worth exploring in more detail. Since the body-mounted solar panel (PV0) was located on the same face as the ADCS coarse sun sensor, it can be assumed to have been directly pointed at the Sun during sunlit segments of the spacecraft orbit. Although the average temperature of PV0 was predicted to be higher than that of the two deployable panels (PV1, and PV2) in thermal analysis, it can be seen from Figure 21 that the temperature discrepancy between the body mounted and deployable panels was significantly higher in on orbit data compared to in thermal analysis.

Figure 22 shows the temperature variation of three solar panels during the on-orbit operations. The temperature of the body-mounted panel was always greater than deployable panels which could represent the anomaly of incomplete deployment. This anomaly can also be discussed in more detail from the variation of state of charge (SOC) in spacecraft.

Figure 23 is the comparison about the SOC measurements in flight data and a power simulation assuming full solar panel deployment. The measured values exceeding 100% are because of the assumption that the battery ESR is constant. Therefore, when the battery reaches the CV state of charge, the measured value would be higher than the actual value. The SOC simulation value assumes that the solar panels were fully deployed. The median of the SOC error is 0.816%. If we consider the effect of different deployment angles, the correlation coefficient between the simulated and observed SOCs are shown in Figure 24. The greatest correlation is shown on when the deployment angle is set to 60 degrees. This means a deployment angle of almost 60 degrees during on-orbit operations cannot be totally excluded.

3.4. ADCS Reboot

Following spacecraft deployment, the ADCS was initially unable to obtain a valid attitude estimate at the beginning of operations. This was resolved following an autonomous ADCS reboot triggered by FSW at T + 3 days (27 January). Following this reboot, the rate of invalid attitude estimates was greatly reduced, as shown in Figure 25. The reasons that would cause FSW to reboot the ADCS include: (1) Power voltage anomaly; (2) ADCS abnormal shutdown; and (3) ADCS anomaly reported in telemetry. As in the case of the anomalous UHF reboots, the exact reason cannot be identified due to the FSW only being able to maintain 15 min of log information. However, the invalid attitude solutions still continued to occur following the reboot, which means that there were still other factors adversely affecting attitude determination.

According to the system configuration in Figure 1, the incomplete deployment of the solar panels would affect the field of view of the star tracker, which would affect the determination of the absolute attitude. As mentioned in the previous section, partial solar panel deployment between 60 and 90 degrees cannot be definitively excluded and is a possible factor in invalid attitude estimates.

3.5. Critical Anomaly–Loss of Communication

Contact was lost with IDEASSat during the second pass over the NCU ground station at 13:34 UTC on 15 February, following a successful overpass at 01:40 UTC earlier that day. Despite the high elevation angle of the second overpass, no beacon signals were received by the NCU ground station. The last contact with a SatNOGS ground station was with a ground station in Canada at 04:09 UTC that day [34], after which no further signals were received for a period of close to 1.5 months. Ground stations that were previously able to receive IDEASSat beacon signals were unable to do so during this time, indicating that the fault was on the spacecraft end. Efforts to transmit the system reset command from the NCU ground station were unsuccessful in producing a response from the spacecraft. During this time, geomagnetic and solar activity were quiet (Figure 26), although the spacecraft did pass through the auroral ovals and South Atlantic Anomaly (SAA) multiple times per day.

The spacecraft began beaconing again on 2 April 2021, which was detected by the SatNOGS network [35], as well as the NCU ground station. Commands were successfully uplinked to the spacecraft from the NCU ground station the same day resetting the beacon packet format to lite, as well as commanding the replay of flight data saved to the CDH SD cards over UHF. The spacecraft remained active for a few days, with the final transmission received on 4 April 2021, after which there was no further contact.

The retrieved flight data yielded a number of clues that allowed for the cause of the communications blackout to be identified to a high level of confidence:

• FSW was not operating and logging data during the blackout, indicating that the spacecraft was likely powered off for the 1.5 month interval. As observed previously during the impedance mismatch anomaly on the ground, FSW would continue to function even in the event of a transceiver anomaly.
• The subsystem reset counters in flight data were reset, indicating that a power cycle and FSW reboot had taken place. However, there was no record of commanded reboots of the spacecraft by FSW, indicating that the power cycle and reboot were un-commanded.
• The 1.5-month blackout time, as opposed to a commanded or watchdog reboot, which would be completed within seconds.
• The first beacon packet received following the blackout showed an SOC of 85%, which was much lower than that observed during the first 22 days of operation. This suggests the possibility of reboot through full or deep battery discharge.
• The second blackout after three days of operation.

Following the above findings, an extensive review was performed of the IDEASSat EPS to identify single failure points that could result in a systemwide power down that would still be recoverable after an extended period of time. The latter factor ruled out the components in the 3.3 V power bus used by the CDH, as radiation failures in the power MOSFETs used as DC/DC converters and power switches would be nonrecoverable single event burnouts (SEBs) and single event gate ruptures (SEGRs) [36]. Additionally, the aforementioned components had been subject to testing on the ground, were derated according to NASA EEE standards [37], had previous flight heritage from the MinXSS mission [11], and had shown no anomalies in received flight data, making spontaneous on-orbit failure much less likely.

The likely cause of the extended power down and communications blackout was identified to be a single gate CMOS Schmitt trigger inverter used in the EPS reset circuit. The purpose of the reset circuit was to allow CDH to power cycle the spacecraft in the event there was an anomaly that could not be resolved by a soft reset, such as watchdog timeout or repeated subsystem resets. Figure 27 is a schematic of the IDEASSat EPS reset circuit. The CMOS Schmitt trigger inverter IC (G1) was the control element used to realize the hardware restart, and was connected to the solid-state relay serving as the main power switch (Q4), connecting the spacecraft avionics load (VBAT) to the battery (VBAT_Reset). The CMOS input was connected to the output of a solid-state relay (Q2), which was normally held in the low voltage (off) state. Under such normal operating conditions, the low voltage at the CMOS input would hold the enable pin (EN) of the main switch (Q4) at a high voltage, thereby ensuring that the main power switch was turned on. If CDH were to send the reset signal, the CMOS input terminal would turn to a high voltage, resulting in a low voltage output to the main power switch, causing the spacecraft avionics to be disconnected from the battery. The capacitor (C42) would initially be charged, and would hold the main power switch in an off state until it discharged sufficiently through resistor R74 to return the potential to the original level and return the main power switch to the on state.

CMOS ICs are at risk of single event latch-up (SEL) when exposed to ionizing radiation [38,39], causing the component to lose functionality, while also exhibiting a low impedance state between power and ground. If an SEL were to occur in G1, the EN of Q4 would also be affected, causing a spacecraft power down until the latch-up could be cleared. An SEL can be cleared by power cycling the component, or will persist until the power supply cannot provide the source voltage and current required. Since G1 was directly connected to the battery following spacecraft deployment (kill switch Kill_SW-RTN would be permanently enabled), the only way of clearing an SEL would be for the battery to discharge sufficiently, which is consistent with the 1.5 month blackout, as well as the signs of battery discharge following power on. The high currents and joule heating resulting from an SEL could cause irreparable degradation and damage to the component if not cleared quickly, and would result in reduced component lifetime.

The need to ensure that all key circuits are latch-up-proof is an important lesson learned. Revisions have been made to the EPS design to implement overcurrent protection across the inverter power line to ensure that any latch-up will result in the inverter power supply being cut. A two-step reset concept is also being implemented, wherein the inverter is normally in a powered down state, being powered up only in the event a reset is commanded. The inverter is not at risk of latch-up when in a powered down state. Radiation tests using proton bombardment will also be performed for the revised CDH/EPS stack to verify the new design, as well as longer duration stress tests.

4. Conclusions

In this paper, we report the design, integration, testing, and on-orbit performance of IDEASSat—the first of many spacecraft that will be developed at NCU. As a first exercise in spacecraft design capacity building, the lessons learned during integration, test, and on-orbit operations have been documented and presented. Several key lessons were learned as a result of this first experience in spacecraft development, integration, testing, and operation:

• At both a system and subsystem level, many bugs and faults are more easily detected and identified after prototyping and testing. Rapid design, fabrication, testing, and revision of self-developed subsystems and flatsat construction should be commenced as early as possible in the project.
• COTS components or subsystems can be an effective method of resolving difficulties that cannot be handled in-house. It is critical to obtain a test report from the COTS manufacturer to cross compare with in-house test conditions and results, while also understanding the operating conditions under which the COTS component will behave nominally.
• Issues with AX.25 header implementation and UHF antenna impedance matching could have been resolved in a more efficient manner had outside experts been consulted earlier. Some problems encountered during spacecraft development may require expertise that does not yet exist in-house. Although unconventional solutions can sometimes be devised, it is best to consult with experts to understand how to correctly implement accepted solutions.
• Battery voltages can show rapid fluctuations when various subsystems are switched on and off. This should be taken into account when designing FSW mode transition thresholds and conditions to prevent rapid shifts in operating mode.
• Given the number of components comprising a spacecraft and the number of steps required for assembly, formulation of a complete step-by-step integration procedure is crucial to ensure successful integration. Inspection points should be clearly defined and listed to ensure all connectors and fasteners are properly staked and epoxied. These also need to be communicated to other teams responsible for fabricating other subsystems.
• Mechanical tolerances are critical to ensuring successful system integration, as well as interfacing with the launch vehicle. The spacecraft solar panel PCBs from the same manufacturer used on this mission were found to warp significantly with time, even after refabrication with increased PCB thickness. This should have served as a warning to seek an alternate provider, even if more expensive.
• FSW settings that persist following a power cycle should be used sparingly and with extreme caution. Measures should be taken to prevent corrupted settings from being logged, such as the implementation of ECC algorithms.
• SatNOGS is an invaluable resource for spacecraft tracking and monitoring, effectively providing worldwide coverage. Incorporating features to the beacon signal that will allow for the spacecraft state to be determined even without demodulation and decoding (e.g., directly from the received waterfall plots) is very useful for increased situational awareness. A successful example in the IDEASSat beacon signal was the use of different beaconing periods depending upon operational mode.
• A three-byte sync word was to distinguish uplinked commands from noise. However, this did not prevent cases of random noise from periodically matching the sync word, causing a persistent increase in the command reject count. A longer sync word might be considered in the future to reduce such anomalies.
• Some anomalies will only manifest after extended operation of the spacecraft. An example is the repeated UHF transceiver reboots, which did not manifest until T + 4 to T + 5 days. Longer duration burn-in tests of multiday duration on the ground could be helpful in identifying such anomalies on future missions.
• Ground stations, especially elements exposed to the elements, require routine maintenance and testing, especially considering that the free space loss on-orbit is much greater than that can be realistically attained without the use of attenuators during end-to-end tests on the ground. Routine tracking and reception of beacon signals from spacecraft already on-orbit will be helpful for functional testing of the ground station and its quality factor.
• While expensive, ionizing radiation tests for total ionizing dose and single event effects is still crucial for verifying the robustness of spacecraft avionics and validating the ability of the spacecraft to recover from single event effects. Power cycling recovery mechanisms need to be present for individual electrical circuits in the EPS, in addition to for other subsystems.
• Documentation and discussion of lessons learned during the development process and operational period are just as valuable as design reviews, ensuring that the experiences gained are passed on and applied to the development and improvement of future spacecraft systems and missions.

IDEASSat demonstrated success in surviving launch and verifying ADCS, autonomous operation, and duplex communication capabilities. The spacecraft also showed healthy thermal, power, and structural margins, validating the design and workmanship abilities of the student team. The spacecraft was found to be sensitive to single event latch-ups in the EPS reset circuit design, which is an important lesson learned for future spacecraft. Corrections have been applied to the EPS design to ensure that this fault is not present on future spacecraft developed at NCU. Persistence of flight software variables damaged by SEU following power cycling also indicate the need for careful consideration in the use of regular variable logging to non-volatile memory, as well as the need for more regular application of error correction and detection methods in such cases. The positive and negative lessons learned from IDEASSat will be implemented in the continued development of NCU spacecraft, to ensure that future spacecraft learn from the experiences of this first mission.