custom-embedded-communication-protocol

# HOWER Protocol ## What I Built HOWER is a custom, lightweight, one-way communication protocol designed for transmitting commands from a central controller to multiple addressed receivers over a digital radio or infrared (IR) communication link. The protocol supports up to five receivers, each assigned a fixed address between 1 and 5. The controller transmits a command packet to each receiver in sequence, while each receiver validates incoming packets and responds only to commands addressed to it. The protocol was designed with a focus on simple implementation, fixed-length packet framing, pulse-width encoding, device addressing, and error detection. ### Key Features * **Custom communication protocol:** Implements a defined packet structure rather than relying on a high-level communication protocol. * **Device addressing:** Supports five individually addressed receivers. * **Pulse-width encoding:** Represents binary data using different HIGH pulse durations. * **Fixed-length packets:** Uses a consistent packet structure without a length field. * **Checksum validation:** Uses an 8-bit XOR checksum to detect certain transmission errors. * **One-way communication:** Transmits commands without requiring acknowledgements from receivers. * **Automated command transmission:** Cycles through the five receiver addresses. * **Receiver-side filtering:** Each receiver processes only valid packets addressed to its configured address. ### System Architecture The system consists of two main components: **1. Controller (Transmitter)** The controller constructs and transmits packets. It calculates the checksum, encodes each byte into pulse-width-modulated bits, and sends commands to receivers with addresses 1 through 5. **2. Receiver** Each receiver continuously listens for incoming packets, identifies the start byte, reads the destination address and command, validates the checksum, and checks whether the packet is intended for that receiver. When a valid command is received, the receiver turns on its onboard LED and moves a servo motor to 90°. After 10 seconds, the receiver turns off the LED and returns the servo to its rest position of 180°. ## How It Works ### 1. Bit Encoding The protocol uses pulse-width encoding to represent binary data. Each bit occupies a total of 2,000 microseconds, consisting of a HIGH pulse followed by a LOW interval. | Bit | HIGH Duration | LOW Duration | Total Duration | | --- | ------------: | -----------: | -------------: | | `1` | 1,500 µs | 500 µs | 2,000 µs | | `0` | 500 µs | 1,500 µs | 2,000 µs | The receiver measures the HIGH pulse duration to determine the transmitted bit. A measured HIGH pulse greater than 1,000 µs represents a `1`, while a pulse of 1,000 µs or less represents a `0`. Bytes are transmitted most-significant bit first. ### 2. Packet Structure Each packet contains 14 bytes, arranged as follows: | Field | Size | Description | | ------------------- | -------: | ------------------------------------------ | | Preamble | 10 bytes | Ten repetitions of `0xAA` | | Start Byte | 1 byte | `0x7E`, marking the beginning of the frame | | Destination Address | 1 byte | Receiver address from 1 to 5 | | Command | 1 byte | `0xAB`, representing the HOWER command | | Checksum | 1 byte | XOR of the destination address and command | The preamble provides a repeated signal pattern before the main frame. The start byte helps the receiver identify the beginning of the packet. ### 3. Checksum Calculation The protocol uses an 8-bit XOR checksum calculated from the destination address and command byte. For example, when transmitting to receiver address `3`: ```python destination_address = 3 hower_command = 0xAB checksum = destination_address ^ hower_command print(hex(checksum)) ``` Expected output: ```text 0xa8 ``` The receiver independently calculates the checksum and compares it with the received value. If they differ, the packet is rejected. The XOR checksum provides basic error detection but does not detect every possible combination of transmission errors. ### 4. Controller Operation The controller cycles through the configured receiver addresses: ```cpp DEVICE_ADDRESSES = {1, 2, 3, 4, 5}; ``` For each address, it: 1. Calculates the checksum. 2. Constructs the packet. 3. Transmits the preamble. 4. Sends the start byte, destination address, command, and checksum. 5. Waits approximately two seconds before proceeding to the next receiver. After sending commands to all five receivers, the controller repeats the sequence. ### 5. Receiver Operation Each receiver is configured with a fixed address. The receiving process follows these steps: 1. Listen for incoming pulses. 2. Decode the received bits into bytes. 3. Search for the start byte `0x7E`. 4. Read the destination address, command, and checksum. 5. Validate the checksum. 6. Compare the destination address with the receiver's configured address. 7. Execute the command only when the packet is valid and correctly addressed. Packets with invalid checksums or incorrect destination addresses are ignored. ### 6. Command Execution When a receiver accepts a valid HOWER command: * The onboard LED turns on. * The servo moves to 90°. * A timer records the start of the operation. * After 10 seconds, the LED turns off and the servo returns to 180°. The return operation is controlled locally by the receiver rather than by a second command from the transmitter. ## Code Example The following example illustrates the checksum and addressing logic used by the protocol. ```cpp #include <Arduino.h> const uint8_t HOWER_BYTE = 0xAB; const uint8_t START_BYTE = 0x7E; const uint8_t MY_ADDRESS = 3; uint8_t calculateChecksum(uint8_t address, uint8_t command) { return address ^ command; } bool validatePacket( uint8_t destination, uint8_t command, uint8_t receivedChecksum ) { uint8_t expectedChecksum = calculateChecksum(destination, command); if (expectedChecksum != receivedChecksum) { return false; } if (destination != MY_ADDRESS) { return false; } if (command != HOWER_BYTE) { return false; } return true; } void setup() { Serial.begin(115200); } void loop() { // Packet reception and pulse decoding // are handled by the protocol implementation. } ``` This example demonstrates the validation logic only. The complete implementation also requires the transmitter's pulse-generation functions and the receiver's packet-decoding routines. ## Results The HOWER protocol defines a structured communication method for sending a fixed command to multiple individually addressed receivers. The design incorporates: * A fixed 14-byte packet format. * Pulse-width encoding for binary transmission. * Five available receiver addresses. * An 8-bit XOR checksum for basic error detection. * Receiver-side packet validation and address filtering. * Timed command execution using LED and servo outputs. * A repeatable controller transmission sequence. The protocol provides a foundation for simple embedded communication applications where a small command set and straightforward implementation are priorities. ## Design Limitations * **No acknowledgements:** The controller cannot confirm whether a receiver successfully received a command. * **Fixed command:** The current implementation defines only one command value, `0xAB`. * **Basic error detection:** The XOR checksum can miss certain multi-bit errors. * **Timing sensitivity:** Accurate pulse measurement and consistent timing are important for reliable decoding. * **Sequential transmission:** Receivers are addressed one at a time rather than through simultaneous command delivery. * **No authentication or encryption:** The protocol is not designed to protect against malicious or unauthorised transmissions. ## Technologies Used * Arduino * Embedded C++ * Digital signal timing * Pulse-width encoding * Bit-level data transmission * Packet framing * Device addressing * XOR checksum validation * Digital radio or infrared communication interfaces ## Conclusion HOWER demonstrates the design of a custom embedded communication protocol, from bit-level signal encoding and packet construction to receiver-side validation and command execution. The project combines low-level digital communication, embedded programming, error detection, and hardware control in a compact protocol intended for communication between a controller and multiple receivers.