Communication protocols

Serial Studio supports 10 communication protocols across wired serial links, wireless radios, network sockets, industrial buses, and local inter-process channels. This page describes each one, covers when to pick it, and highlights the configuration parameters and platform details that matter in practice. For deeper per-protocol primers (theory, framing, common pitfalls, references), see the Drivers section of the docs.

Protocol landscape

The diagram below maps all supported protocols by throughput range and license tier.

flowchart TD
    Q{"Connection type?"}
    Q -->|USB cable| A1["Serial/UART"]
    Q -->|WiFi / Ethernet| A2["TCP/UDP"]
    Q -->|Wireless sensor| A3["Bluetooth LE"]
    Q -->|Cloud / IoT| A4["MQTT · Pro"]
    Q -->|Vehicle / PLC| A5["CAN · Modbus · Pro"]

Protocol summary

Free protocols

Serial/UART

Serial/UART is the most common way to connect microcontrollers to a computer. It covers USB-to-serial adapters (CH340, FTDI, CP210x, PL2303), native hardware UARTs, and RS-232/RS-485 transceivers.

When to use it:

• Arduino, ESP32, STM32, or any board with a USB-serial bridge.
• Direct hardware UART wiring between two devices.
• RS-232 lab instruments and RS-485 industrial sensors.
• Quick prototyping where simplicity matters most.

Key configuration parameters:

• Baud rate. Has to match the device. Common values: 9600, 115200, 921600. Serial Studio supports custom rates up to 1 Mbps and beyond.
• Data bits. 5, 6, 7, or 8 (8 is standard for nearly all modern devices).
• Parity. None, Even, Odd, Space, or Mark. Most devices use None.
• Stop bits. 1, 1.5, or 2. Almost always 1.
• Flow control. None, RTS/CTS (hardware), or XON/XOFF (software). Use None unless your device needs it.
• DTR signal. Some boards (notably Arduino) use DTR to trigger a reset on connect. Enable or disable based on whether you want auto-reset.
• Auto reconnect. Reconnects automatically if the device is unplugged and replugged.

Platform considerations:

• Linux: The user has to belong to the dialout (or uucp) group to access /dev/ttyUSBx and /dev/ttyACMx without root.
• Windows: CH340 and PL2303 adapters may need a manually installed driver. FTDI and CP210x drivers are bundled with Windows 10+.
• macOS: Most USB-serial adapters work without setup. Older CP210x chips may need a signed kext or VCP driver.

TCP/UDP network

The Network driver connects to devices over TCP or UDP sockets. It's the natural fit for WiFi-enabled microcontrollers (ESP32, ESP8266), Ethernet-connected instruments, and remote data acquisition systems.

When to use it:

• ESP32/ESP8266 sending telemetry over WiFi.
• Ethernet-connected lab instruments or PLCs.
• Receiving multicast or broadcast sensor data on a LAN.
• Remote monitoring where the device and computer aren't in the same place.

TCP vs UDP:

Key configuration parameters:

• Socket type. TCP or UDP.
• Remote address. IP address or hostname of the device. Default: 127.0.0.1.
• TCP port. Remote port for TCP connections. Default: 23.
• UDP remote port. Port the device is listening on or sending from. Default: 53.
• UDP local port. Port Serial Studio binds to for receiving. Set to 0 for automatic assignment.
• UDP multicast. Join a multicast group specified by the remote address.

Platform considerations:

• Firewall rules on any OS may block incoming UDP datagrams or outgoing TCP connections. Allow Serial Studio through if connections fail.
• On macOS, the first network connection may trigger a system permission dialog.
• DNS resolution runs asynchronously. A spinner appears while the hostname is looked up.

Bluetooth Low Energy

The BLE driver talks to Bluetooth Low Energy peripherals via GATT. It auto-discovers advertising devices, enumerates their services and characteristics, and streams notification data into Serial Studio's pipeline.

When to use it:

• Battery-powered wireless sensors (temperature, humidity, IMU, heart rate).
• Wearables and fitness trackers.
• BLE modules like HM-10, nRF52, or ESP32 BLE.
• Any scenario where wiring isn't practical and low power matters.

Key configuration parameters:

• Device. Selected from the auto-discovered list. Scanning starts automatically when BLE is chosen.
• Service. If the device exposes multiple GATT services, pick the one carrying your data.
• Characteristic. The specific characteristic that sends notifications or indications with your telemetry payload.

How discovery works. Serial Studio uses a shared static discovery agent. All BLE driver instances share the same device list, so scanning happens once no matter how many sources reference BLE. The device list is append-only during a scan, and device indices stay stable, so combobox selections aren't disrupted by new discoveries.

Platform considerations:

• Windows: Needs Windows 10 version 1803 or later with a Bluetooth 4.0+ adapter.
• macOS: Needs macOS 13+ and Bluetooth entitlement. The system may prompt for Bluetooth permission.
• Linux: Needs BlueZ 5.44+ and a Bluetooth 4.0+ adapter. The user may need to be in the bluetooth group. Some distros require bluetoothd to be running.
• All platforms: The BLE device must be advertising and not already connected to another host. Move it closer if it doesn't show up in the scan.

Pro protocols

These protocols need a Serial Studio Pro license.

MQTT

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol designed for constrained devices and unreliable networks. Serial Studio Pro can act as an MQTT subscriber (receiving telemetry from a broker) or as a publisher (forwarding received frame data to a broker).

When to use it:

• Cloud-connected IoT devices publishing to AWS IoT, Azure IoT Hub, or a self-hosted Mosquitto broker.
• Distributed sensor networks where multiple subscribers need the same data.
• Remote monitoring over the internet without direct device access.
• Bridging Serial Studio data to other MQTT-aware applications.

Key configuration parameters:

• Hostname. Broker address. Default: 127.0.0.1.
• Port. Broker port. Default: 1883 (plaintext) or 8883 (TLS).
• Client ID. Auto-generated 16-character random string. Regenerate via the button.
• Username / password. Broker authentication.
• MQTT version. 3.1, 3.1.1, or 5.0.
• Topic filter. Topic the subscriber listens on. Supports MQTT wildcards (+ single level, # multi-level). The publisher uses a separate per-project topic base configured on the MQTT Publisher page.
• TLS/SSL. Optional encryption with configurable protocol version, peer verification mode, peer verification depth, and CA certificates.
• Keep alive. Interval in seconds for PING packets. Supports automatic keep-alive.

Subscriptions are made at QoS 0, and Last Will configuration is not exposed. The subscriber and publisher are configured separately: the subscriber is a per-source bus type, the publisher a project-level export.

Platform considerations:

• Needs network or internet access to the broker.
• TLS connections need valid CA certificates. Load system certificates or point to a custom CA bundle.
• MQTT 5.0 extended authentication is supported when the broker requires it.

For the protocol vocabulary, see MQTT Topics & Semantics. The inbound side (per-source subscriber) is documented at MQTT Subscriber; the outbound side (project-level publisher) at MQTT Publisher.

Modbus

Modbus is an industrial communication protocol for reading and writing registers on PLCs, SCADA devices, and other industrial equipment. Serial Studio Pro supports both Modbus RTU (over RS-485 serial) and Modbus TCP (over Ethernet/IP).

When to use it:

• Reading holding registers, input registers, coils, or discrete inputs from a PLC.
• Industrial automation monitoring and factory floor dashboards.
• Building management systems (HVAC, power meters).
• Any Modbus-enabled equipment with a documented register map.

Key configuration parameters:

• Protocol. Modbus RTU or Modbus TCP.
• Slave address. Device address on the bus (1 to 247).
• Register groups. One or more groups, each specifying a register type (coil, discrete input, input register, holding register), start address, and count.
• Poll interval. How often to query registers, in milliseconds.
• RTU-specific: serial port, baud rate, data bits, parity, stop bits.
• TCP-specific: host address, port (default 5020).

Register types:

Platform considerations:

• Modbus RTU needs an RS-485-to-USB adapter. Make sure A/B terminal polarity is correct and use 120-ohm termination resistors at each end of the bus.
• Modbus TCP runs over standard Ethernet. No special hardware beyond network access.
• The serial port list is refreshed automatically. On Linux, make sure the user has permission to access /dev/ttyUSBx.

CAN Bus

Controller Area Network (CAN) is a vehicle and industrial bus standard. Serial Studio Pro reads and writes CAN frames through the host platform's CAN interface layer.

When to use it:

• Automotive diagnostics and OBD-II data logging.
• Racing or electric vehicle telemetry.
• Industrial machinery with CAN networks.
• CAN FD (Flexible Data-rate) applications needing up to 64 bytes per frame.

Key configuration parameters:

• Plugin. The CAN backend. Platform-dependent:
  • Linux: socketcan.
  • Windows: peakcan, vectorcan, systeccan.
  • macOS: limited. Needs third-party drivers.
• Interface. The CAN interface name (for example can0, PCAN_USBBUS1).
• Bitrate. Has to match the network exactly. Common: 125, 250, 500 kbps, 1 Mbps.
• CAN FD. Enable for Flexible Data-rate frames (up to 64 data bytes per frame).

CAN frame format emitted by the driver. The driver converts each received CAN frame into a byte array. Standard frames (11-bit identifiers) use [ID_high, ID_low, DLC, data_0, data_1, ...]; extended frames (29-bit identifiers) carry the full identifier in four bytes with bit 7 of the first byte set: [0x80|ID_28..24, ID_23..16, ID_15..8, ID_7..0, DLC, data_0, ...]. Standard identifiers never exceed 0x7FF, so the first byte's top bit tells the two forms apart. This array is passed to Serial Studio's frame parser for decoding.

Platform considerations:

• Linux: SocketCAN is a kernel-level CAN interface. Configure with ip link set can0 type can bitrate 500000 && ip link set up can0. No extra drivers needed for most USB-CAN adapters.
• Windows: Needs vendor-specific drivers (PEAK, Vector, Systec). Install the driver before connecting the adapter.
• macOS: Native CAN support is limited. Third-party CAN adapters with their own drivers may work through the Qt CAN bus plugin system, but support isn't guaranteed.

Audio input

The Audio Input driver captures raw PCM audio from the computer's sound input (microphone, line-in, audio interface) and feeds it into Serial Studio's data pipeline. It uses the miniaudio library for cross-platform low-latency audio capture.

When to use it:

• Audio spectrum analysis and FFT visualization.
• Vibration monitoring via audio-coupled accelerometers or piezo sensors.
• Acoustic measurements and sound-level monitoring.
• Analog signal visualization within the audio frequency range (roughly 20 Hz to 24 kHz).

Key configuration parameters:

• Input device. Pick from enumerated audio capture devices.
• Sample rate. Depends on the device. Common: 44100, 48000 Hz.
• Sample format. Bit depth (for example 16-bit integer, 32-bit float).
• Channel configuration. Mono or stereo.

The driver also exposes output device settings for audio passthrough, though the primary use case is capture.

Platform considerations:

• macOS: May need Microphone permission in System Settings > Privacy & Security.
• Windows: May need "Stereo Mix" enabled or a specific input in Sound Settings.
• Linux: Works with ALSA and PulseAudio. Use arecord -l to list capture devices.
• For sensor measurement, prefer line-in over microphone input to avoid automatic gain control.

Raw USB

The Raw USB driver gives direct access to USB device endpoints via libusb, bypassing operating system serial and HID drivers. It supports bulk, control, and isochronous transfer modes.

When to use it:

• Custom USB firmware with bulk endpoints (STM32, TinyUSB, PIC, and so on).
• High-bandwidth sensors that exceed UART throughput.
• Devices that need vendor-specific USB control transfers.
• Isochronous USB devices for fixed-rate streaming (audio endpoints, custom DAQ).

Transfer modes:

Key configuration parameters:

• Device. Pick from the enumerated list (VID:PID and product string).
• IN endpoint. The endpoint to read data from.
• OUT endpoint. The endpoint to write data to.
• Transfer mode. Bulk Stream, Advanced Control, or Isochronous.
• ISO packet size. Packet size for isochronous transfers (only relevant in Isochronous mode).

Platform considerations:

• Linux: Needs udev rules granting the user access to the USB device, or root privileges. Hotplug detection is supported natively.
• macOS: The system may hold a kernel driver claim on some devices. libusb will try to detach it. Hotplug is supported.
• Windows: Needs a WinUSB or libusb-compatible driver installed for the target device (for example via Zadig). Hotplug is supported on Windows 8+.
• A dedicated event thread runs libusb_handle_events_timeout() continuously to service hotplug callbacks and isochronous completions.

HID

The HID driver accesses Human Interface Devices via the hidapi library. It reads interrupt reports from gamepads, joysticks, custom USB HID firmware, and HID-class sensors without custom OS drivers.

When to use it:

• Gamepad or joystick telemetry for robotics dashboards.
• Custom HID firmware on Arduino (HID library), STM32, or nRF52.
• Sensors and measurement instruments that enumerate as USB HID.
• Any USB device where you want driver-free cross-platform access.

Key configuration parameters:

• Device. Pick from the auto-enumerated list, shown as Product Name (VID:PID) (or just VID:PID when no product string is available).
• Usage Page / Usage. Shown after device selection for reference (identifies the HID function).

How enumeration works. The driver re-enumerates all HID devices every 2 seconds via a QTimer. The device list updates automatically when devices are plugged in or removed.

Platform considerations:

• Windows: Uses WinAPI (hid.dll). Most HID devices work without extra drivers.
• macOS: Uses IOHIDManager / IOKit. No extra drivers needed.
• Linux: Uses the hidraw kernel interface. The user may need udev rules to access /dev/hidrawX without root. The hidraw backend avoids conflicts with the libusb-based Raw USB driver.
• HID reports are 65 bytes (1 report ID byte + 64 data bytes). The driver forwards the full report to the data pipeline.

Process I/O

The Process I/O driver captures data from child processes or named pipes, so Serial Studio can visualize output from scripts, simulators, and external programs.

When to use it:

• Python, Node.js, or shell scripts that aggregate sensor data and print CSV to stdout.
• Physics engines or flight simulators emitting telemetry.
• Protocol bridge programs translating proprietary formats to Serial Studio frames.
• Testing dashboards with synthetic data generators.
• Reading from a named pipe (FIFO) written by an external app.

Modes:

Launch mode parameters:

• Executable. Path to the program. Supports browsing via file dialog. Serial Studio searches standard PATH locations plus platform-specific extras.
• Arguments. Command-line arguments passed to the process.
• Working directory. The directory the process runs in. Supports browsing.

Named pipe parameters:

• Pipe path. Filesystem path to the named pipe or FIFO. Supports browsing.

Platform considerations:

• Linux and macOS: Named pipes are created with mkfifo. Make sure the pipe exists before connecting.
• Windows: Named pipes use the \\.\pipe\PipeName convention.
• If the child process crashes or exits unexpectedly, Serial Studio shows a warning and triggers a disconnect.
• The process's stdout and stderr are merged into a single stream. Make sure your script writes only data frames to stdout if you want clean parsing.

Picking the right protocol

By situation:

By priority:

• Simplest setup: Serial/UART, then HID, then Process I/O.
• Highest throughput: Raw USB, then CAN Bus (FD), then TCP Network.
• Longest range: MQTT (global via internet), then TCP/UDP (LAN/internet), then BLE (~100 m).
• Lowest power on the device side: Bluetooth LE.
• No special hardware: Process I/O (just a script), Audio Input (just a microphone).

Hardware requirements

See also

• Protocol Setup Guides: step-by-step instructions for each protocol.
• MQTT Topics & Semantics: protocol vocabulary used by both the subscriber driver and the publisher.
• MQTT Subscriber: the inbound, per-source side of MQTT.
• MQTT Publisher: the outbound, project-level side of MQTT.
• Getting Started: first-time setup tutorial.
• Troubleshooting: fixes for common connection problems.
• Pro vs Free Features: compare protocol availability across editions.