Change software without losing the working mission

The mission timeline describes an August 2018 software upload spread over three days, followed by a consistency check and changeover. It associates the update with improved image delivery and denser beacon data. A November update added further telemetry, file-indexing and scheduling improvements. These are dated participant reports, not proof of current operation.

This history illustrates an important engineering opportunity: software can change what existing hardware can accomplish. It also introduces risk. A new version that handles images efficiently but prevents health reporting could make the mission harder to operate. Treat desired improvements and preservation of essential functions as separate requirements.

Consider an invented update divided into 100 blocks. A receiver has 98 distinct valid blocks and two duplicates. It has received 100 blocks in total, but the update is incomplete. The missing identities must be recovered before any whole-file check can establish the expected content. A consistency check should not be confused with authorization to install software.

A cautious teaching sequence is: stage the complete file, verify its integrity and approved identity, activate it at a planned time, and confirm required functions afterward. These are general principles, not a disclosure of the flight’s bootloader or security design. The actual system determines whether it can retain an old version, switch back automatically or recover through ground commands.

A transfer is only the first step

Suppose an invented camera scheduler must preserve a health report at least once every ten minutes. The old version met that requirement. After an update, the team should measure the interval again while exercising the new image workload; old evidence does not automatically cover new scheduling behavior.

Define recovery criteria before activation. In a fictional design that supports returning to a known working image, missed health reports can trigger that recovery procedure. Retain logs from both versions so the team can diagnose the fault. A successful rollback preserves service but still leaves the proposed improvement needing repair and another test.