Communication Protocols

Every connected electronic system uses protocols. A protocol is a shared rulebook for electrical levels, timing, addressing, packet structure, error checking, and the meaning of bytes. A temperature sensor, a smart meter, a PLC, a web browser, and a cloud service all communicate this way, but they do it at different layers.

The main skill is not memorizing names. The skill is knowing which layer you are looking at, what that layer promises, and which faults belong there.

Learning Objectives

By the end of this overview, you should be able to:

separate physical wiring problems from data-format and application problems;
place common protocols such as UART, SPI, I2C, CAN, TCP, MQTT, and Modbus on a layer model;
choose a protocol family from distance, speed, device count, reliability, and safety needs;
recognize encapsulation, addressing, framing, and error checking;
debug communication links from the lowest layer upward.

Why Protocols Are Layered

An embedded board might read an ADC over SPI, send measurements to a gateway over RS-485 using Modbus RTU, and publish the same measurements to a server using MQTT over TLS/TCP/IP. Those are not competing names for the same thing. They solve different parts of the communication problem.

flowchart TD APP["Application meaning\nHTTP, MQTT, Modbus, OPC UA\nCommands, topics, objects, registers"] TRAN["Transport behavior\nTCP or UDP\nReliability, ordering, ports"] NET["Network routing\nIPv4 or IPv6\nAddresses across networks"] LINK["Local link\nEthernet, WiFi, BLE, RS-485\nFrames on one medium"] HW["Chip and board buses\nUART, SPI, I2C, CAN\nPins, timing, voltage levels"] APP --> TRAN --> NET --> LINK --> HW

A higher layer depends on the lower layers. If the UART baud rate is wrong, the Modbus parser cannot fix it. If TCP is connected but an MQTT topic is misspelled, the Ethernet wiring is not the problem.

Hardware Protocols: Chip To Chip

Hardware protocols describe wires, voltage levels, timing, and basic frames. They are used inside a product or between nearby devices.

Protocol	Common wires	Typical distance	Typical use
UART	TX, RX, GND	board to a few metres	debug console, GPS, cellular module
SPI	SCK, MOSI, MISO, CS, GND	board level	ADCs, displays, flash, SD cards
I2C	SDA, SCL, GND	board level	sensors, RTCs, EEPROMs
CAN	CAN_H, CAN_L, GND/reference	vehicle or machine harness	automotive and industrial control
RS-485	A, B, reference	tens to hundreds of metres	fieldbus, meters, drives
I2S	bit clock, word select, data	board level	digital audio
4-20 mA	current loop pair	industrial cable runs	process transmitters

Hardware protocols usually do not define the meaning of a measurement, register map, or command. That job belongs to a device data sheet or a software protocol above the link.

Software And Industrial Protocols

Software protocols define what bytes mean: addresses, function codes, topics, payload fields, security, and error handling.

Protocol	Usually runs on	What it defines
Modbus RTU	RS-485 or RS-232	slave address, function code, register data, CRC
Modbus TCP	TCP/IP over Ethernet or WiFi	Modbus data model over an IP connection
MQTT	TCP/IP, usually with TLS	publish/subscribe topics and message delivery level
HTTP/HTTPS	TCP/IP with TLS for HTTPS	request/response resources and APIs
OPC UA	TCP/IP	industrial objects, services, security, subscriptions
BACnet/IP	UDP/IP	building automation objects and services
HART	4-20 mA with digital overlay	smart transmitter commands and diagnostics

The same application idea can move across different physical links. Modbus is the classic example: Modbus RTU commonly uses RS-485, while Modbus TCP uses Ethernet. The register model feels similar, but the framing and transport are different.

The OSI Model

The OSI model is a vocabulary for protocol layers. Real systems do not always map perfectly to seven boxes, but the model is useful for debugging.

flowchart TD L7["7 Application\nHTTP, MQTT, DNS, Modbus data model"] L6["6 Presentation\nTLS, encoding, compression"] L5["5 Session\nconnection state, login, reconnect"] L4["4 Transport\nTCP, UDP, ports, ordering"] L3["3 Network\nIP addresses and routing"] L2["2 Data link\nEthernet frames, WiFi frames, MAC, CRC"] L1["1 Physical\nvoltage, radio, cable, connector, baud"] L7 --> L6 --> L5 --> L4 --> L3 --> L2 --> L1

In practice, the TCP/IP model combines layers 5 to 7 into the application layer, uses TCP or UDP as transport, IP as internet layer, and Ethernet/WiFi/cellular as network access.

Encapsulation: How A Message Travels

When a browser opens https://techarya.net, the request is wrapped several times:

The browser creates an HTTP request.
TLS encrypts and authenticates it.
TCP adds source and destination ports plus sequence numbers.
IP adds source and destination IP addresses.
Ethernet or WiFi adds local frame addresses and a frame check sequence.
The physical layer sends bits as voltages, light, or radio energy.

The receiver unwraps the same layers in reverse. This wrapping is called encapsulation.

flowchart TD DATA["Application data"] TLS["TLS record"] TCP["TCP segment"] IP["IP packet"] FRAME["Link frame"] BITS["Physical bits"] DATA --> TLS --> TCP --> IP --> FRAME --> BITS

Choosing A Protocol

Use engineering constraints first, then pick the protocol.

Constraint	Questions to ask	Common choices
Distance	same PCB, same cabinet, field cable, internet?	SPI/I2C, UART, RS-485, CAN, Ethernet
Speed	bytes per second, samples per second, latency?	SPI for local speed, Ethernet for high data
Device count	one peripheral, many sensors, many controllers?	SPI with chip selects, I2C addresses, CAN, RS-485
Noise	motors, relays, long cable, outdoor wiring?	differential links, isolation, termination, shielding
Reliability	retry needed, ordered stream, real-time deadline?	TCP, CAN arbitration, application ACKs
Security	local trusted board or public network?	TLS, authentication, signed updates

Worked Example: Smart Meter Path

A smart meter may contain several protocol layers at once:

an energy-measurement IC connected to the MCU over SPI;
a local optical port using UART framing;
an RS-485 port running Modbus RTU;
a cellular modem using AT commands over UART;
a head-end connection using TLS and an application protocol.

Debugging starts at the bottom. First confirm power, connector, voltage level, baud rate, polarity, and termination. Then inspect frames. Only after the link is clean should you debug register maps, topics, credentials, or server behavior.

Common Mistakes

Treating a hardware bus name as if it also defines the payload meaning.
Starting with cloud logs while the physical link is not electrically valid.
Forgetting the shared reference or isolation requirement on cabled links.
Mixing voltage levels, for example 5 V UART into a 3.3 V input.
Ignoring termination and biasing on differential field buses.
Assuming TCP guarantees that the application command was accepted.

Summary

Communication protocols form a stack. Hardware protocols move bits locally, link and network protocols move frames and packets across media, transport protocols define delivery behavior, and application protocols define meaning. Debugging is most reliable when you verify each layer from physical signals upward.

Mind Map

mindmap root((Communication Protocols)) Core idea Shared rules Layers Encapsulation Meaning above bits Hardware links UART debug SPI peripherals I2C sensors CAN and RS485 Network layers Ethernet or WiFi IP routing TCP reliable stream UDP datagrams Applications HTTP APIs MQTT topics Modbus registers OPC UA objects Design rules Match distance Match speed Plan device count Add isolation Use security Practical checks Power and ground Voltage levels Baud or clock Frames and CRC Credentials last Common mistakes Wrong layer debug Payload vs transport Missing termination No shared reference