Most amateur flight computers get tested the same way you launch the rocket and see what happens. If your apogee detection has a bug, you find out at 3000 feet. Teams have independently built hardware vacuum chambers for barometer testing, spin rigs for accelerometer testing, drone drop rigs for full system tests. There's no software equivalent of ArduPilot's SITL for high-power rocketry. So I built one.

How it works

The core idea is a hardware abstraction layer (HAL) that sits between your firmware and the outside world. On a real flight computer, the HAL talks to actual sensor chips. In simulation, a different implementation of the same HAL talks to a Python server running a RocketPy 6DOF physics simulation instead. Your firmware never knows the difference.

The server streams sensor data: pressure, accelerometer, gyroscope, GPS. All with datasheet-accurate noise applied per timestep. Your firmware reads it, runs its state machine, detects apogee, fires pyro channels. At the end you get a pass/fail report:

=== TEST REPORT ===
Apogee detection:   PASS  True apogee:      2937.0m at T+18.78s  Detected apogee:  2935.4m at T+18.27s  Time error:       0.51s

PYRO1 single-fire check:    PASS — fired once
PYRO2 single-fire check:    PASS — fired once
PYRO1 -> PYRO2 order:       PASS
PYRO1/PYRO2 separation:     PASS (gap=5.84s, min required=2.0s)

Two modes

SIL (software-in-the-loop): firmware compiles and runs natively on your laptop over TCP. Fastest iteration (rebuild and retest in seconds).

HIL (hardware-in-the-loop): firmware runs on your actual flight computer hardware over USB serial. Tests the actual binary that will fly, on the actual chip, with real hardware timing and interrupts. Drop in two files, implement two serial functions for your platform, flash normally.

The server listens on both TCP and serial simultaneously or whichever connects first wins.

What it catches

The sequence validator is the most practically useful part. It checks three failure modes that can destroy a rocket:

  • Duplicate pyro fires — a channel triggering more than once
  • Wrong deployment order — main deploying before drogue
  • Insufficient separation — both channels firing too close together

It's been validated against real Altimeter Cloud flight logs. Clean flights come back accurate to within 1m of recorded apogee. A flight with a barometer spike correctly produced a larger detection error — the tool reflects real sensor anomalies rather than hiding them.

What it doesn't do

It won't catch the edge cases that only show up in real flights: pressure artifacts at transonic speeds, vibration resonance from your electronics sled, orientation effects on sensor readings. Those require empirical data from real flights to model accurately. The goal isn't to replace test flights, it's to make sure you're not wasting them on bugs you could have caught on a laptop.

Hardware support

Anything with a UART. Arduino, ESP32, STM32, RP2040 the HAL serial implementations for each are in the README. The raw simulation rate benchmarks at ~38kHz so even high-frequency avionics won't bottleneck the sim.

Repo: https://github.com/JustinPronk/AvionicsSimulation

If you're building your own flight computer and want to try it against your firmware, open an issue or reach out.