Notes / Communication Protocols
Protocol design: making your own communication rules
Header, length, command, data, CRC. Design rules that cut packets reliably out of a stream of bytes.
UART and BLE only deliver a flow of bytes; they do not tell you where one message starts and ends. Deciding that rule is protocol design.
Basic packet structure
| Field | Size | Role |
|---|---|---|
| Start bytes | 1 to 2 | Marks the start of a packet (for example 0xAA 0x55) |
| Length | 1 | Length of the data that follows |
| Command / ID | 1 | Which message this is |
| Data | N | Content |
| CRC | 2 | Detects corruption |
Write the receive parser as a state machine
Wait for the start byte → length → command → N data bytes → check the CRC. If something unexpected arrives partway, go back to the beginning. If the gap between bytes is too long, reset on a timeout.
Design checklist
- Endianness: state the byte order of multi-byte values in the document (usually little-endian)
- Retransmission: important commands get a response (ACK), and are sent again if none arrives within a set time. Attach a sequence number to prevent duplicate execution
- Version field: so the format can change later and stay compatible
- Byte stuffing: so a start byte appearing inside the data causes no confusion, use an encoding such as COBS or SLIP
- Do not send a struct as it is: padding and endianness problems (see the note on C structs)
Before making a new one, first check whether an already proven protocol such as Modbus, MAVLink or CANopen fits.