Telemetry High/Low-Rate Transmission

## Problem

We sample gyroscope, accelerometer, and altitude at **5 Hz**, and temperature, pressure, magnetometer, and estimated apogee at **1 Hz**. Every second, all of this is bundled into one packet. When the payload exceeds the packet size limit, excess bytes are deferred to the next packet — creating a cascading backlog with no recovery mechanism.

## Proposed Solutions

**Option A — Priority-Based Tiered Transmission**
High-rate sensors transmit every packet. Low-rate sensors are interleaved on a round-robin schedule (one per packet), naturally hitting ~1 Hz without ever exceeding the size budget. Requires a field-ID scheme inside `data_bytes` so the parser knows what each packet contains.

**Option B — Separate Packet Types**
Split into two packet types with a single type-flag byte:
```
[start_bytes][timestamp][pkt_num][H][gyro][accel][alt][end_bytes] // 5 Hz
[start_bytes][timestamp][pkt_num][L][temp][pressure][mag][apogee][end_bytes] // 1 Hz
```
Each type is fixed-size and easy to budget. Requires the team to define a packet numbering policy (shared counter vs. per-type).

**Option C — Drop Policy for Non-Critical Data**
High-rate data always transmits. Low-rate data is dropped (not deferred) if the packet is full, and a `dropped_frames` counter is incremented. Overflow becomes structurally impossible. Best suited if occasional gaps in low-rate data are acceptable.

## Considerations

- If a CRC or any other integrity bytes are added in the future, they must be reserved in the size budget
- All three options require ground station parser changes; Option C requires the least

## Open Questions

- [ ] What is the RFD900x's exact max `data_bytes` payload size?
- [ ] Should estimated apogee be promoted to the high-rate tier?
- [ ] Should `dropped_frames` / overflow events be logged on the flight computer or only at the ground station?