Lessons Learned During Operations

While operating the satellite, we're learning a ton! We aim to document many of these lessons.

Firmware: What's worked well

We got a lot right in the design of the firmware. Tons of features built into the firmware haven't been used extensively [yet], but we want to highlight a few that have worked very well. Nearly every sub-optimal circumstance we're encountered has been able to be handled via features in the firmware.

1. Command De-duplication: Having a way to uplink the same command 10x, but have it execute only once, has been imperative.
   • We accomplish this via the @tssent= suffix tag and associated configuration variable (TCMD_require_unique_tssent).
2. Beacons with data: A beacon with tons of system health information is hugely valuable.
3. Friendly message in beacon: Having a configurable friendly message in the beacon (e.g., Hello from CalgaryToSpace FrontierSat, which we've also used to wish members a Happy Birthday) has been super helpful in validating that we're receiving beacons. Text messages like that come through well, even with uncorrectable bit errors, and foster engagement with members of all levels of technical experience.
4. Plain text data: Having the option to downlink data in plain text (e.g., instead of tightly-packed binary) made the initial contact and early operations much, much easier. Our science data is tightly-packed, but one-off commands generally use JSON. An even better option for a satellite built in a more flexible language (e.g., Rust with the serde crate) would be to allow the requester to specify the message format (e.g., JSON, Postcard, tightly-packed C-struct).
5. Telecommand scheduling: Scheduling any telecommand for later execution has been huge. We didn't plan to downlink files over SatNOGS stations, but the scheduling/agenda architecture enabled it perfectly.

Firmware: Opportunities for Next Time

1. More beacon data: Having several types of beacon packets with more data (including ADCS data, per-channel EPS data, etc.) would be helpful.
2. Schedule command to be repeated: Being able to schedule a command to repeat at a constant interval (e.g., every 30 seconds) would have been helpful. For example, fetching live GNSS and downlinking it via SatNOGS, repeatedly starting a file downlink, etc.
3. Global frame counter: Having a global frame counter in all downlinked packets would have been helpful (either 1 or 2 bytes).