The Payload Interface Board

MonARCH is a collaborative project between the Electric Propulsion Lab (EPL) and the Laboratory for Advanced Space Systems at Illinois (LASSI). The mission features a multi-mode propulsion system that utilizes a novel mono-propellant. This design aims to demonstrate efficient propulsion in a compact form factor to support future small satellite applications.

Choosing Components

Once requirements were understood a functional block diagram was created to identify subsystem interactions and determine required voltage rails, communication protocols, and required functions throughout the payload and bus of MonARCH. Environmental analyzes were performed on the STM32 series to evaluate the radiation effects on the STM32 micro-controller unit using credible resources. Electronics were selected based on reliability, availability,operating temperature range, and existing aerospace usage. Components from STMicroelectronics, Texas Instruments, and Analog Devices were used due to their established reputation and broad availability within the COTS market. More information on how each specific component was chosen is in the research paper linked at the very bottom.

Design Phase

In the design phase, PCB schematics and layouts were developed using KiCad. The process included schematic capture, footprint verification, PCB routing, computing passive electronic values, design rule checking, and ensuring equal length of communication traces. Firmware for the PIBs was developed in STM32CubeIDE using embedded C. Initial firmware functionality included GPIO control for solenoid valve drivers; integrating, and building IC drivers for electronic chips on the PIBs. Lastly, a bill of materials (BOMS) was created to order, assemble, and build prototype PIBs in the final weeks of the Spring 2026 semester in collaboration with LASSI.

Testing & Debugging

Initital testing showcased many flaws in the first revision of the PIB. Testing began with the primary MCU (STM32L4A6) failing basic code execution, such as a simple GPIO LED toggle. Extensive continuity checks, pin probing, and datasheet analysis revealed errors in PCB design causing memory placement errors and constant board resets that prohibited code execution. These flaws were fixable with fragile "bodged" wire connections and thus testing resumed to IC drivers. However, these modifications severely hindered debugging, as loose and intermittent connections introduced noise and bit errors that frequently caused ST-LINK communication failures. After extensive hand-soldering and significant debugging time, the decision was made to develop a new PIB revision. Though the board ultimately succumbed to hardware issues, achieving brief solenoid control and successfully reading device IDs provided the critical baseline knowledge required for the next PIB revision.

With all mistakes documented the hardware redesign was simple and quick. The new revision was built and software drivers were corrected. As a result, temperature, pressure, voltage, and capacitance measurements were all successfully read from sensors. Additionally, a command line interface was implemented for easy commanding. This enabled easy solenoid valve control and will be used for integrating all MonARCH components together, testing feed systems, and propulsion elements in the fall semester

Command Line Interface

Main Flight Software

The main challenges I encountered were designing a system around the space environment using COTS components, and developing compatible drivers for the STM32CubeIDE Hardware Abstraction Library (HAL) library.

MCU Selection

The entire 2026 spring semester I researched how the space environment affects electronics and realized that there were major issues to address, many of which made it difficult to subsequently make design choices. Such as picking out the microcontroller unit (MCU) which involved investigating the trade study between a COTS MCU and a rad-hard mcu. The micro-controller unit (MCU) is the most critical component of the payload interface system and is vulnerable to the space environment. A single event effect could cause mission failure if not taken into consideration during the design process, therefore, MCU selection required careful evaluation. The tradeoff between the risks posed by radiation exposure and the increased cost of radiation-hardened MCUs was the most important consideration. There are lots of commercial off the shelf (COTS) components available on the market that are not inherently designed for space flight nonetheless designed for radiation tolerance. Thus, the driving factors of selecting an MCU from the ST-Microelectronics (STM) series was the documentation behind these MCUs surviving and thriving in the LEO environment. Not only, STMs are very powerful, reliable, and accurate MCUs that we evaluated can perform every task the payload interface system needs to accomplish. Through rigorous research, the STM32L4A6 was chosen for the electrical payload system. The MCU consists of four I2Cs, three SPIs, three USARTs, and two UARTs which are essential communication protocols for interfacing with sensors, OBC, and PPU. The STM32L4A6 is an ultra-low-power processor and thus consumes exponentially less power than an STM32H7 series. The STM32L4A6 typically consumes an average of 20mA with a maximum of 150mA. It is a great processor when power consumption is a concern. Also, it is important to note this MCU has an explicitly defined low power UART which is needed to communicate with the OBC. There are two 16-bit PWM timers which are needed for IEP valve pressure regulation. For power, LASSI has allocated 1 watt for the entire payload interface system. H7s consume around 264 µ/MHz typical value at VDD = 3.3 V and 25 °C in Run mode (peripherals off) almost 3x the amount compared to the L4s which have around a power consumption of 91 µA/MHz run mode (LDO mode). A more through explanaton and validation of the STM32L4A6 is offered in the research paper linked below.

Developing Drivers for STM32 HAL

Every IC had a unique process for integrating its associated driver and bringing it to a functional state. This process differed significantly from high-level Arduino libraries I was accustomed to, which abstracted much of the underlying communication and data handling between ICs. For example, when communicating over I2C, the device address needed to be shifted left by one bit, with the least significant bit indicating a read or write operation. To develop reliable and functional drivers, I used preliminary skeletal drivers as references and adapted their structure to create my own custom drivers or implementations. For the FDC2214, I used an existing Arduino C++ library and converted its functionality into C-based functions compatible with the STM32 HAL. Additionally, I used device datasheets to develop error-detection functions, ensuring that each status and error bit was properly identified and interpreted.