OMEN Flight Event Detection Schemas

Background

  • NMFC “Backplane” gathering mainly inertial data

  • “Grim Reefer” gathering some inertial, mainly high-speed analog data

  • “POTATO” gathering high-speed analog data

Measurement storage schema

  • Bin measurements by rate

  • Highest frequency grouped into several measurements

  • 24 bits requires us to define our own endianness, error-prone

  • Microsecond accuracy reasonable

  • Down-convert inertial measurements to 16 bit ints because that’s how they start

    • Fundamentally, 32 bits of precision is too many for 16 bits of information

  • Store only one of the several temperature readings

Events of interest

  • Everyone detects boost, because we can’t store all the high-frequency measurements

  • Everyone detects landing, to save power and have less garbage at the end

  • Grim and Potato need to capture before and after apogee, to get load measurements

Detection options

Boost

  • Acceleration

    • Not affected by venting or wind

    • Potentially affected by bumping, but powered on at the pad

  • Altitude

    • Less reliable than acceleration due to venting issues

      • May be overblown

      • Testable

    •  

  • RRC3s capable of live serial output

    • Reliable because of COTS

    • Adds complexity to code

    • Adds complexity to wiring harness

Choice:

For all, OR gated:

  • 5 gees for 0.25s

    • Magnitude

      • Insensitive to orientation changes

      • Insensitive to programming errors

    • 5 half (arb) of expected g

    • 0.25s worked for SCRAP

  • Altitude reaches 500 ft above ground level in less than 3s

    • 500ft common arming alititude for altimeters

    • 3s double (arb) of simulated 1.6s

Pre-Apogee

  • Timer after boost

  • Timer after burnout

    • Slightly less simple

  • Altitude slowly changing

Choice, for Backplane:

  • After boost, <50 fps gives 2 (arb) seconds leading up

Choice, for Grim:

  • Not needed, enough data rate

Choice, for POTATO:

  • After boost, <50 fps gives 2 (arb) seconds leading up

  • OR backplane detecting pre-apogee

Apogee

  • Not specifically helpful during the flight

Main

  • Pure timer

  • Altitude on the way down

Choice, for Backplane:

  • Main + 500ft (arb)

Choice, for Grim:

  • Not needed, enough data rate

Landing

  • Timer

  • Acceleration

  • Altitude

Choice, for all:

  • Timer is the simplest, no loss to over-timing

Final CONOPS

Backplane

  • Stores a 3s rolling buffer

  • Detects boost OR gated measurements

    • 5g 0.25s

    • >500ft <3s

  • Detects 3s before apogee

    • <50 fps vertical velocity

  • Detects 10s before main

    • 500 ft above main

  • Detects landing by 400s timer

Grim Reefer

  • Stores a 3s rolling buffer

  • Detects boost OR gated measurements

    • 5g 0.25s

    • >500ft <3s

  • Detect landing via 400s timer

POTATO

  • Stores a 3s rolling buffer

  • Detects boost OR gated measurements

    • Sensor module command

    • Own altimeter 500ft <3s

  • Detects 3s before apogee

    • Sensor module command

    • <50 fps vertical velocity

  • Detects 10s before main OR gated

    • Sensor module command

    • 500 ft above main

  • Detects landing by 400s timer

To do

Is LittleFS file-growing overhead a problem?
How much data do the currently set thresholds eat up?
What ranges in descent rate does this timing allow for?