Back to Vespula Avionics Module

Revision

Revision Architecture

How I audited the inherited pin map and interfaces, figured out which assumptions disagreed across hardware/firmware, and carried the fixes into the PCB.

48 V Bus

Revision Architecture

The Vespula Flight SAM was very much not a clean-sheet project for me. I inherited a board with the 48 V bus, BeagleBone, propulsion sensing, valves, ignition, and Ethernet already in place, but a bunch of the interface assumptions disagreed with the processor, firmware, or PCB.

My job was basically to make all of those assumptions line up well enough that the board could boot, be debugged, and actually be trusted on the vehicle.

What The Audit Found

This was not a cleanup-for-cleanup's-sake revision. The things I found were real bring-up problems:

  • boot-sensitive BeagleBone pins were being driven into invalid states;
  • more than 15 BeagleBone control/interface pins required reassignment;
  • several ADC paths had incorrect polarity or channel mapping;
  • igniter-power regulation was not stable/repeatable;
  • actuation and sensing behavior could not be validated consistently in the inherited configuration.

The annoying part was that none of these lived in one file. Moving a pin touched firmware and routing, an ADC polarity fix touched both the schematic and software scaling, and the power issue crossed component values and the PCB.

Inherited Vespula BeagleBone pinout
The inherited BeagleBone pin assignment before the revision.
Corrected Vespula BeagleBone pinout
The corrected assignment after moving the conflicting and boot-sensitive signals.

Rebuilding Signal Ownership

I audited the controller from the outside in:

  1. vehicle connector and harness signals;
  2. BeagleBone physical pins and boot behavior;
  3. SPI/GPIO ownership;
  4. ADC channel/polarity mapping;
  5. valve/igniter command paths;
  6. regulated power domains;
  7. the corresponding PCB routes.

That process exposed cases where the schematic label was internally consistent but disagreed with what the processor or firmware expected.

Six-Layer Revision

The corrected board uses a six-layer structure:

  • L1 — signal/components
  • L2 — ground
  • L3 — signal
  • L4 — power
  • L5 — ground
  • L6 — signal/components

The layer structure let the new routing preserve continuous references while separating high-current actuation/converter regions from the low-level sensor and controller interfaces.

Vespula BeagleBone routing
PCB routing around the corrected BeagleBone pin assignment and connector interfaces.
Vespula Rev 4 full-board layout
Full-board Altium view of the revised Flight SAM.
Vespula Rev 4 top copper
Rev 4 top-layer copper after the interface changes were carried through the PCB.

Bring-Up

I brought the corrected revision up in stages:

  1. dead-board and controller boot checks;
  2. 48 V-derived regulated rails;
  3. ADC polarity/channel verification;
  4. sensor scaling and acquisition;
  5. valve output and feedback;
  6. igniter power/operation;
  7. Ethernet and integrated Flight Computer operation.

The win was not just “the board turns on now.” Rev 4 booted reliably, read the sensors correctly, and behaved repeatably with the actual propulsion hardware connected.

Assembled Vespula Rev 4 Flight SAM
The assembled Rev 4 board after the interface and routing revision.

Result

This project was mostly about the boundaries people tend to underestimate: boot rules, pin ownership, analog polarity, power behavior, PCB routing, and firmware all had to agree before the board became boring enough to use.