Connectivity: how devices reach other systems
Separate the physical/network connection from the protocol and data so Wi‑Fi, cellular, serial, USB, Ethernet, and a tether stop being mixed together.
Why this matters
Many integration diagrams collapse everything into 'connection.' Troubleshooting becomes easier when you can say whether the problem is physical connectivity, network transport, application protocol, authentication, or data structure.
Learn it
A device might connect locally by USB or serial, join a network over Ethernet or Wi‑Fi, reach the Internet through cellular service, or use a tether to a surface computer. TCP and UDP provide transport over IP networks. An application protocol such as HTTP, Matrix, or MAVLink then defines higher-level communication. The same data format can travel over different connections.
Work through an example
A sensor gateway may read a controller over serial, use Wi‑Fi to reach a local network, and send JSON to an HTTP API. Those are three different layers of the path.
device → physical/network connection → transport → protocol/interface → data → destinationPractice
- 1Draw one real connection from device to destination.
- 2Label physical link, network link, transport, application protocol, and data representation separately.
- 3Remove one layer at a time and explain what would stop working.
Try it
Follow data through a workflow
Select each stage. The goal is to keep the source, connection, protocol, data, spatial context, rule, and use understandable instead of collapsing everything into one box.
The real-world fact, device, file, application, person, or system that starts the workflow. If it is an observation, preserve where, when, what, source, value, units, and provenance.
What to watch for
Wi‑Fi is not an API. Cellular is not a data format. USB is not JSON. Keeping layers separate prevents bad architecture and bad troubleshooting.
Where this takes you
This lesson is the bridge from devices and stations into APIs, telemetry, remote operations, and integration workflows.