Avionics Firmware and Protocols

The Problem

You have a bunch of STM32 nodes spread around a rocket and an ESP32 handling communications. They all need to share data, log events, and save telemetry to flash. If every developer writes their own CAN bus implementation from scratch, you end up with incompatible packet formats, timing issues, and dropped messages. Network code is the last thing you want to be debugging when you're supposed to be reading a pressure sensor or firing an actuator.

What I built

The team built a shared foundation called av-libraries. It handles the messy infrastructure so developers can focus on their application logic — a logger (AimLogger) that tags messages with timestamps and severity, a flash table manager (AimFlashTable) for dumping flight data to serial memory, and at the core, AimNetwork.

AimNetwork handles CAN bus communication and abstracts the hardware — whether you're on the STM32 HAL or ESP32 TWAI — behind a single interface. The packet structure is entirely locked down: 3 bits for origin, 3 bits for destination, 4 bits for packet type. Payload is always 64 bits, either raw data or a timed format that packs a 27-bit timestamp with a 32-bit payload. Everyone agrees on exactly what a packet looks like.

Highlights

• STM32 CAN core uses no dynamic memory — fixed 16-frame TX and RX queues, with a max of 8 iterations per poll cycle to prevent infinite loops if the bus gets flooded.
• Heartbeat health table tracks which nodes are alive and when they last checked in.
• Automatic time synchronization across the bus so events on different boards share a common clock.
• STM32 driver skips Arduino libraries and talks directly to the HAL — gives precise control over hardware mailboxes and pulls detailed error telemetry like dropped queues and bus-off events.
• WiFi and LoRa telemetry forwarding for ground station visibility.

Media