# novafc-data-format

The flight computer -> ground station data logging format.

This format is a one to one mapping of the fields that are available on the ground station

## Overview
Flight computer data can be thought of as a stream of messages.
Each message carries a piece of information about the flight computer along with a timestamp
of when that message was generated.

Because standardizing time on embedded system is hard, this format uses a ticks based system,
where the tick rate can be changed inside the format itself. This gives the flight computer
lots of flexability to manage its time, while being able to very percisely report exactly when
data samples were recorded.
Tick 0 is when the flight computer wakes up and there are 1024 ticks per second by default.

The data stream generally starts with [`BarometerCalibration`], so that the
ground station has the calibration constants it needs, and [`Data::TicksPerSecond`] to
establish a custom data rate other than 1024.
This is because these actions are done when the flight computer wakes up.
The order of messages follows very closley with what the flight computer is doing at any one time,
because the current implementation simply reads data, and then immediately records it.

## Associated State

Any state change on the flight computer (such as a change in calibration constants, or tick
rate) that would effect the reconstruction of the data format is always emitted and must be
handled.
Because of this, decoding implementations must maintain a certain abount of state and update it
as new state messages are recieved in order to accuratly reconstruct what happened from the
flight computer's point of view.

## Assumptions

This is the gereral format, however implementations must not make assumptions about the order
or quantity of each message type, with the following exceptions:
1. [`Data::BarometerData`] messages will only follow after [`Data::BarometerCalibration`] messages have been
   sent before.

## Ticks State Example

If the first message is a calibration message with [`Message::ticks_since_last_message`] set to 1024,
because the default tick rate is 1024, we know that this message was emitted 1 second after
flight computer woke up.
If the second message is a `TicksPerSecond` message which changes the tick rate to 1,000,000/s,
and `ticks_since_last_message` is set to 1024, this change happened 1 second after the calibration
message, so 2 seconds total since wakeup.
Once this message is processed, all future tick calculations must use the new tick rate.
If the third message is a `BarometerData` message recieved 500,000 ticks after the
`TicksPerSecond` message, because the new tick rate is 1,000,000 ticks per second,
it has been 0.5 seconds since the last message or 2.5 seconds total since wakeup.

## Format on the Wire

The format of the actual data on the wire is unstable and subject to change, however we plan
to use postcard plus serde with these structs until a more efficent bit for bit format can be
implemented. Perhaps we could make a crate that automates this process using smaller bit wrapper
types U14, U20, u6, etc. to give hints to a proc macro so that enum tags can be packed with data
more efficently.

License: MIT