Telemetry CRC

[Elan456]

Currently, our telemetry implementation does not include any application-level error checking.

Current Flow:

1. Stream bytes to the RFD900x via UART: [start_bytes][timestamp][packet_number][data_bytes][end_bytes]
2. The RFD900x automatically breaks the stream into packets and sends them with error checks
3. The ground-station RFD900x receives the packets and reconstructs the byte stream sent to the laptop
4. The ground-station RFD900x transmits the stream to the laptop via UART
5. The laptop parses: [start_bytes][timestamp][packet_number][data_bytes][end_bytes]

The problem

We currently rely on the RFD900x to correct errors and ensure the over-the-air transmission is reliable, which is generally fine. However, bits can still be flipped on the UART links (steps 1 and 4). Additionally, the RFD900x could occasionally introduce errors.

Adding an end-to-end integrity check would improve overall telemetry reliability and make it easier to quantify packet corruption. Right now, signal integrity is inferred mainly from packet numbers and whether packets arrive, not whether the payload is correct.

Solution

Add a CRC checksum, specifically CRC-16-CCITT. It adds 2 bytes per packet, is fast to compute, and provides much stronger error detection than a simple XOR checksum.

New format:
[start_bytes][timestamp][packet_number][data_bytes][crc_bytes][end_bytes]

The CRC would be calculated over:
[timestamp][packet_number][data_bytes]

If the ground station decodes a packet with an invalid CRC, it can increment a bad_crc counter and display how many of the last 100 packets failed the CRC check in the GUI. This provides an estimate of the packet corruption rate.

Considerations

When calculating how much space is left in the packet, the room needed for the CRC needs to be accounted for.