Flight Operation

Flight sequence

flowchart TD
    launch[Launch detection] --> boost[Boost]
    boost --> coast[Coast]
    coast --> apogee[Apogee detection]
    apogee --> landing[Landing detection]
    landing --> landed[Landed]

This sequence summarizes detection and state changes. Automatic deployment at apogee depends on FIRE_PYRO_APOGEE and the other safety conditions described below.

Sensor sampling

During flight, AstroNav Nano continuously samples its sensors.

Measured data includes:

• Acceleration
• Rotation
• Pressure
• Temperature

Derived information includes:

• Altitude
• Vertical velocity
• Orientation

Launch detection

Launch is not triggered from a single acceleration sample.

The firmware requires sustained acceleration above the configured launch threshold.

The default threshold is:

1.35 g

Boost

After launch confirmation, the board enters Boost.

The vehicle is considered to be in powered ascent.

Coast

When boost ends, the board transitions into Coast.

The vehicle continues climbing without powered acceleration.

Apogee detection

The firmware evaluates multiple conditions when determining apogee.

These include:

• Drop from peak altitude
• Downward vertical velocity
• Low acceleration
• Minimum flight time

Confirmation samples are used so one noisy sensor reading does not immediately trigger an apogee event.

Pyro behavior

When apogee is confirmed:

If:

FIRE_PYRO_APOGEE=TRUE

the pyro channel can receive a one-second pulse when the other safety conditions permit it.

If:

FIRE_PYRO_APOGEE=FALSE

the apogee event is still detected and logged, but the automatic pyro output is blocked.

Landing detection

After the apogee event, the firmware monitors for landing.

Landing detection considers:

• Low altitude trend
• Low vertical velocity
• Low acceleration
• Stable gravity alignment

These conditions must remain stable before Landed is confirmed.

After landing

Once landing is confirmed:

1. The mission log is finalized.
2. Buffered data is written to storage.
3. Flight records are updated.

Sensor fallback

The firmware may continue using healthy sensor paths when another reading becomes invalid.

Sensor fallback is intended to improve robustness.

It does not mean warnings or sensor failures should be ignored.