OMEN Flight Event Detection Schemas

This Confluence space has been migrated and is no longer current. The content on this space has been set to read only.

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?