Payload

StormSat — 1U CubeSat Avionics Prototype

STM32F411 · 3 custom PCBs · Embedded C · SPI/I²C/UART · LoRa TT&C · GNSS · IMU · FATFS · ESP32-CAM · Python

StormSat was my final-year Aerospace Engineering team project: a functional 1U CubeSat engineering prototype built around three custom PCBs — OBC, EPS and Payload — with onboard sensing, navigation, data logging, imaging, LoRa telemetry/telecommand and ground-side mission analysis.

My main responsibility was the electronics hardware. I designed and routed all three PCBs, prepared them for manufacturing, integrated them into the final stack and took part in bring-up and debugging. I was also one of the two main contributors to the STM32 firmware and independently developed the Python mission-analysis application.

System architecture

The system is split into three stacked boards connected through a common 40-pin interface. The OBC is the central controller: it acquires sensor data, manages power states, stores telemetry/images, controls the camera and handles the mission logic. The Payload provides the main sensors, GNSS and LoRa radio; the EPS distributes and monitors power.

flowchart LR
    EPS[EPS\nBattery · regulation\nINA219 · switched rails] <--> OBC[OBC\nSTM32F411\nMission logic · storage]
    OBC <--> PAYLOAD[Payload\nMPU6500 · BMP280 · VEML7700\nNEO-7M GNSS · SX1278 LoRa]
    OBC <--> CAM[ESP32-CAM\nImage capture]
    OBC --> SD[microSD\nFATFS · telemetry · images]
    PAYLOAD <--> GS[Ground Station\nLoRa TT&C]
    GS --> PC[Mission Analysis\nPython dashboard · Excel export]

The complete data chain implemented in the prototype is:

Sensors / GNSS / EPS telemetry
            ↓
      STM32F411 OBC
      ↙            ↘
 microSD/FATFS     LoRa TT&C
      ↓                ↓
 stored data       Ground Station
                       ↓
                Python analysis

Hardware

The avionics stack uses three matching approximately 85 × 85 mm, 2-layer PCBs. I designed the schematics and PCB layouts in KiCad and defined the electrical interface between the three boards.

OBC — On-Board Computer

The OBC is based on an STM32F411CEU6 BlackPill and acts as the processing and data-handling board. It connects the STM32 to the other two PCBs and integrates microSD, the ESP32-CAM interface, debugging/programming access and all inter-board buses/control signals.

OBC PCB layout	OBC schematic

KiCad project and schematic PDF →

EPS — Electrical Power System

The EPS provides the battery/charging path, 3.3 V regulation, INA219 housekeeping measurements and independently controlled supply domains for the main avionics loads. Test points and bypass provisions were included to support bring-up and fault isolation.

EPS PCB layout	EPS schematic

KiCad project and schematic PDF →

Payload

The Payload PCB contains the main sensing, navigation and TT&C devices: MPU6500, BMP280, VEML7700, u-blox NEO-7M and SX1278/Ra-02.

Payload PCB layout	Payload schematic

KiCad project and schematic PDF →

Buses and MCU interfaces

The final firmware/hardware mapping is:

The MPU6500 and SX1278 share the SPI3 data/clock lines and are selected independently using dedicated chip-select/control signals. The BMP280, VEML7700 and INA219 share I²C2 using their individual addresses.

More hardware/interface detail →

Flight firmware — how the system actually runs

The final firmware targets the STM32F411CEU6 at 100 MHz and uses STM32 HAL/CMSIS and FATFS.

Despite the task_* filenames, this version does not use FreeRTOS. It uses a cooperative superloop/state-machine architecture. main.c manages the satellite/mission state, and each subsystem module exposes operations such as Init, Run, Sleep, Wake and data access.

Startup and main loop

At boot the STM32 configures GPIO, ADC, timers, I²C2, SPI2, SPI3, FATFS and the three UARTs. After that, the main loop continuously executes three layers of logic:

1. Mission decision logic
   ├─ read latest sensor / GNSS / EPS data
   ├─ evaluate battery state
   ├─ evaluate geographic mission zones
   └─ select IDLE / SCIENCE / DOWNLINK

2. System configuration
   ├─ enable/disable GPS and camera power
   ├─ put sensors/radio in sleep or wake them
   ├─ trigger telemetry logging
   └─ trigger image capture / pending downlink

3. Cooperative task manager
   ├─ TaskMPU_Run()
   ├─ TaskBMP_Run()
   ├─ TaskVEML_Run()
   ├─ TaskINA_Run()
   ├─ TaskGPS_Run()
   ├─ TaskLoRa_Run()
   ├─ TaskSD_Run()
   └─ camera handling

Timing is mainly based on HAL_GetTick(), so individual modules execute at different rates without requiring an RTOS scheduler.

Satellite and mission modes

The firmware supports three top-level satellite modes:

• MANUAL — subsystem settings can be controlled directly;
• MISSION — automatic mission behaviour based on GNSS, health and mission parameters;
• MISSION_DEMO — simulated position progression for demonstrating the complete mission sequence without requiring the real orbital trajectory.

Automatic mission operation uses three mission states:

stateDiagram-v2
    [*] --> IDLE
    IDLE --> SCIENCE: GNSS enters science zone
    SCIENCE --> DOWNLINK: GNSS enters ground-station zone
    SCIENCE --> IDLE: leaves science zone
    DOWNLINK --> SCIENCE: enters science zone
    DOWNLINK --> IDLE: leaves operational zone

IDLE minimises active loads. The environmental sensors, IMU, LoRa, camera and SD can be placed inactive while the GNSS is periodically enabled to determine the current mission zone.

SCIENCE enables the sensing/data-acquisition path. The OBC logs telemetry and evaluates the measured attitude and light level. An image capture can be triggered when roll, pitch and illumination satisfy the configured mission thresholds. If the INA219 indicates a critical battery level, the firmware reduces active loads.

DOWNLINK keeps the LoRa, GNSS and SD path available while non-essential sensing/camera loads are disabled. If a captured image is pending, the file is queued for LoRa transfer.

Subsystem modules

The MPU6500 code calibrates accelerometer/gyroscope offsets and combines accelerometer-derived angles with integrated gyro rates using a complementary filter (alpha = 0.95) to generate roll and pitch estimates used by the mission logic.

Firmware source → · Detailed firmware architecture →

GNSS and navigation data

The NEO-7M is connected to USART6. Data is received asynchronously into a FIFO and then processed by the GPS task. Development progressed from raw NMEA output to an application-specific stream:

NEO-7M @ 9600 baud
       ↓
UART interrupt reception
       ↓
FIFO / buffering
       ↓
NMEA filtering + checksum/parsing
       ↓
RMC / GGA fields
       ↓
latitude · longitude · altitude · fix · satellites · UTC
       ↓
mission logic + logging + telemetry

Unnecessary NMEA messages can be disabled and the receiver update period is configurable. The mission logic uses the decoded coordinates to determine when the prototype is in a configured science zone or ground-station/downlink zone.

LoRa TT&C

The Payload uses an SX1278/Ra-02 radio on SPI3. The final configuration in firmware is 433 MHz, 17 dBm, SF7, 500 kHz bandwidth, coding rate 4/5, CRC enabled and preamble length 10.

The application-level TTC packet is:

[ dst ][ src ][ type ][ seq ][ len ][ payload ... ]

Implemented packet types include:

DATA       telemetry / stored data
ACK        data acknowledgement
CMD        ground command
ACK_CMD    command acknowledgement
IMG_START  image-transfer metadata
IMG_BLOCK  image data
IMG_ACK    received-block bitmap
IMG_END    transfer completion

The command handler supports operations including GPS/camera enable, satellite-mode changes, telemetry-period configuration, system reset and camera capture/resolution/quality/brightness control.

The link is half-duplex. TaskLoRa_Run() moves through a state machine:

IDLE
  ↓ period elapsed
TX telemetry/data
  ↓
RX WINDOW (~2 s)
  ├─ valid command → execute + ACK_CMD
  ├─ received packet → process
  └─ timeout → return to IDLE

Source/destination IDs and sequence numbers are used to associate packets and acknowledgements instead of treating any received response as valid.

Image path

Image handling is a complete multi-device data path rather than a single UART command:

ESP32-CAM
   ↓  USART1 @ 921600
capture metadata + image blocks
   ↓
STM32 OBC
   ↓
FATFS / microSD
   ↓  when downlink is available
read image file
   ↓
150-byte LoRa image blocks
   ↓
windowed ACK bitmap / retransmit missing blocks
   ↓
Ground Station

The LoRa image-transfer implementation uses 150-byte data blocks, windows of up to 32 blocks, timeout/retry handling and retransmission of missing blocks.

Sensor and housekeeping chain

Validation

The project was brought up incrementally from individual devices to the complete integrated stack.

Recorded examples included a GNSS 3D fix with HDOP ≈ 1.6, FATFS sensor logging, and INA219 measurements used to compare the contribution of the connected payload loads.

Detailed validation and known issues →

Mission-analysis software

I independently developed the Python application used to visualise and analyse mission telemetry.

It processes live/recorded telemetry and provides position/map visualisation, attitude and sensor plots, battery/mission information, summaries and Excel export.

Mission-analysis source → · Example export →

A separate image-analysis application is preserved in software/image-analysis/ because it formed part of the team workflow; it was developed by another team member and is not presented as my work.

My contribution

My main work on StormSat was:

• complete schematic and PCB design of the OBC, EPS and Payload boards;
• common 40-pin interface definition, peripheral/pin planning and PCB routing;
• fabrication preparation, physical integration, bring-up and hardware debugging;
• substantial STM32 firmware development as one of the two main contributors;
• integration/adaptation of sensor, storage, GNSS, camera and TT&C functionality;
• independent development of the Python mission-analysis application.

Detailed contribution record →

Known hardware issue

During final EPS bring-up, the TPS27081A switched IMU/LoRa power path presented a short-circuit condition. The board included a bypass provision, so the affected switched path was isolated and bypassed to continue validating the rest of the system.

I keep this documented because fault isolation and continuing the integration campaign were part of the actual engineering work.

Repository structure

StormSat-CubeSat/
├── hardware/              KiCad projects, schematics, PCB layouts and Gerbers
├── firmware/              complete STM32F411 CubeIDE project
├── software/              mission-analysis + team image-analysis applications
├── examples/              sample mission export
├── docs/
│   ├── engineering.md     deeper hardware/firmware/system description
│   ├── verification.md    tests, measurements and known issue
│   ├── my-contributions.md
│   └── assets/
├── NOTICE.md
└── THIRD_PARTY.md

Scope

StormSat is an engineering prototype, not flight-qualified hardware. I do not claim ECSS qualification, radiation tolerance, thermal-vacuum/vibration qualification or formal EMC/EMI compliance.

The objective of this revision was to take a complete embedded avionics system through requirements interpretation, schematic/PCB design, manufacture, firmware integration, bring-up, debugging and end-to-end functional validation.