novafc-data-format

飞行计算机 -> 地面站数据记录格式。

此格式与地面站上可用的字段一对一映射。

概述

飞行计算机数据可以被视为一条消息流。每条消息都携带有关飞行计算机的信息以及该消息生成的时间戳。

由于在嵌入式系统中标准化时间很困难，此格式使用基于滴答的系统，滴答率可以在格式内部更改。这为飞行计算机提供了大量的灵活性来管理其时间，同时能够非常精确地报告数据样本何时被记录。滴答0是飞行计算机唤醒的时候，默认情况下每秒有1024个滴答。

数据流通常以 BarometerCalibration 开头，以便地面站拥有所需的校准常数，以及 Data::TicksPerSecond 来建立除1024以外的自定义数据率。这是因为这些操作是在飞行计算机唤醒时进行的。消息的顺序与飞行计算机在任何给定时间所做的事情非常接近，因为当前的实现只是读取数据，然后立即记录它。

相关状态

飞行计算机上的任何状态变化（例如校准常数的更改或滴答率）都会影响数据格式的重建，必须始终发出并处理。因此，解码实现必须维护一定量的状态，并在接收到新的状态消息时更新它，以便准确重建从飞行计算机的角度发生的事情。

假设

这是通用格式，但是实现不得对每种消息类型的顺序或数量做出假设，但有以下例外

1. Data::BarometerData 消息将仅在 Data::BarometerCalibration 消息之前发送后才会发送。

滴答状态示例

如果第一条消息是一个校准消息，并且 Message::ticks_since_last_message 设置为 1024，因为默认的滴答率是 1024，我们知道这条消息是在飞行计算机唤醒后 1 秒发出的。如果第二条消息是一个将滴答率改为 1,000,000/s 的 TicksPerSecond 消息，并且 ticks_since_last_message 设置为 1024，那么这个变化发生在校准消息后 1 秒，所以总共唤醒后 2 秒。一旦处理了这个消息，所有未来的滴答计算都必须使用新的滴答率。如果第三条消息是一个在 TicksPerSecond 消息后 500,000 滴答接收到的 BarometerData 消息，因为新的滴答率是每秒 1,000,000 滴答，那么从最后一条消息以来已经过去了 0.5 秒或总共唤醒后 2.5 秒。

有线格式

有线上的实际数据格式不稳定，可能会发生变化，但我们计划在实现更高效的位对位格式之前，使用 postcard 加 serde 和这些结构。也许我们可以制作一个 crate，它使用较小的位包装类型（如 U14、U20、u6 等）来自动化此过程，为 proc macro 提供提示，以便更有效地打包枚举标签。

许可证：MIT