Telemetry High/Low-Rate Transmission

[jstikel]

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?

[Elan456]

For Option A, we can track which streams get added to the packet and which don't without adding more to the packet itself, just more to the internal state of telemetry or the SSDs themselves. Every item in the packet already has an ID (which is why altitude is 5 bytes instead of 4), that's how we get the flexible structure within the payload section of the packet.

Whenever an SSD gets added, we already call

streams[i]->markWasSent(currentTime);

Telling it the time it was sent, and then the stream uses that time to know when it wants to be sent again.

When building the packet, we check if (streams[i]->shouldBeSent(currentTime)) { to see if the SSD wants to be sent. Whether it returns true depends on how long it has been since it was last sent.

Instead of a simple true or false, we could use a priority system where the longer something has overrun its desired send time, the higher its priority to send it.

The higher-frequency data (5 Hz vs 1 Hz) will naturally have a higher priority more often, as their desired send time will be sooner after it's sent. Although the slow data's priority will eventually build up and be sent.

Thoughts? I'm not sure how this would work out in practice.

Option B

We can't do option B because it would make it challenging to add new data streams and damage the generic structure of Avionics. The current system lets us have tons of random streams that are sent at different rates. Option B would require us to bundle things into common rates (which I guess we kinda already do).