# Flight Operation

## Flight sequence

```mermaid
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:

```text
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:

```ini
FIRE_PYRO_APOGEE=TRUE
```

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

If:

```ini
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.