doc/help/About.md
Background, philosophy, and history of the project. Useful if you want to know who wrote it, why it exists, and how it ended up the shape it is now.
Serial Studio is built by Alex Spataru ([email protected]). The project started as a one-person tool for satellite and rover ground-station work, and is still primarily developed by Alex, with contributions from the open-source community on GitHub. Anyone can read the source, file issues, and submit patches under GPL-3.0. The optional Pro edition funds full-time development.
Before Serial Studio, Alex worked on a CanSat competition and later on the NASA Human Exploration Rover Challenge during college. The CanSat work came with its own ground-station software, custom-written for that competition's telemetry format. Every protocol tweak meant another late night in the dashboard code instead of on the hardware. The pattern repeated across teams and semesters: a microcontroller printed sensor values over a serial cable, and somebody had to build a custom GUI around them.
The first attempt at a generic answer was a personal project called SigLAB. It worked. The data model was already protocol-agnostic, and the dashboard was already data-driven. The reason it was eventually renamed wasn't technical. Alex wanted the project to live under its own organization rather than buried in a personal list of side projects, with room for outside contributors and a clean GitHub identity.
On October 18, 2020 the SigLAB codebase was imported into a new repository under github.com/Serial-Studio. The literal first commit message in this repo is "Initial commit from SigLAB codebase", and the project took on its current name.
The launch blog post, Introducing Serial Studio (December 29, 2020), opens with the line that still describes the project:
Did you ever have the need to display data from a microcontroller on a dashboard, and spent more time developing (and fixing) your dashboard software, than working on your MCU project?
Three ideas have stayed constant since 2020.
Serial Studio grew driver-by-driver as users brought new hardware to it. Most additions were not planned in advance. They came from a specific request and got generalized once they worked.
.dbc files decode signals automatically.socat, nc, a Python script, anything that writes to stdout. Both shipped together as the "experimental" tier of drivers.The widget set started with line plots, gauges, bar charts, and a GPS map in late 2020, and slowly grew into the current set of 15+ widgets. The bigger inflection points were:
paint(ctx, w, h) callback, May 2026) for visualizations that don't fit any of the standard widgets.Serial Studio 1.x was a working dashboard, but the architecture had clear ceilings. Frame parsing was hard-coded around the JSON and CSV split from the original blog post, so any new frame layout meant patching C++ and shipping a new release. The UI was assembled out of the original SigLAB widgets and didn't scale cleanly as new visualizations were added.
The 2.0 release was effectively a new application sharing a name with the old one. The whole UI was rebuilt from scratch on Qt Quick. Plotting moved to Qwt, which gave Serial Studio its first real headroom for fast time-series rendering. The biggest change was the addition of the JavaScript frame parser. Every project now carried a small parse(frame) function running inside a QJSEngine, so any framing convention (delimited, fixed-length, key/value, custom binary) could be handled without recompiling. That single decision is what turned Serial Studio from a CSV/JSON viewer into a general-purpose telemetry tool.
Where 2.0 was a UI and parser rewrite, 3.0 was a data-path rewrite. The IO layer dropped its singletons. FrameBuilder and FrameReader were redesigned around a lock-free single-producer/single-consumer pipeline. The dashboard moved to a zero-allocation hot path that targets 256 kHz+ frame rates.
Qwt was retired and replaced by QtGraphs plus a set of custom Qt Quick widgets. That removed a heavy third-party dependency, unified styling across the app, and let widgets share a single render loop with the rest of the QML scene. The visible feature set didn't change much across that boundary. The invisible one (throughput, memory behavior, threading, dependency footprint) changed completely.
The 3.x line that followed (v3.0.0 in October 2024 through v3.2.7 in March 2026) was additive rather than another rewrite. The data-path work paid off as headroom, and the project spent that headroom on breadth. Most of the connectivity and visualization growth listed above landed here: Audio input and the FFT pipeline, the 3D and XY plots, and the first explicitly industrial drivers (Modbus and CAN Bus). Two changes from this period are worth calling out on their own. The dashboard became a small windowing environment: a taskbar and window manager arrived in mid-2025, so dashboard widgets could float, snap, and tile like application windows instead of living in one fixed grid (the "mini OS" feel the dashboard still has). And the first automation surface appeared: the MCP/TCP API (July 2025) opened the project and live data to external programs, the groundwork the next era built on.
Where the 2.0 → 3.0 work was a data-path rewrite under a roughly fixed feature set, the 3.0 → 4.0 work (4.0 is the current HEAD) is a rewrite of scope. The aim shifted from "show telemetry well" to "run a workstation someone can be handed for a shift," and that pulled in the pieces an industrial deployment expects:
None of this is a clean break the way the earlier rewrites were. The data path from 3.0 is unchanged and 3.x projects load as-is; what grew is the surface area around it. The sections below describe each piece.
The features below are the 4.0 surface in detail. Together they are what turned Serial Studio from a viewer into a small industrial platform.
Datasets are no longer islands. Every project carries an auto-generated system table with raw:<id> and final:<id> registers for every dataset, plus user-defined tables of Constant (project-time) and Computed (per-frame) registers. Frame parsers, value transforms, and output widgets all read and write the same registers, which means a sensor calibration written once is reusable everywhere. See Data Tables.
Each dataset can carry a small Lua or JavaScript snippet, function transform(value) → number, that runs every frame. Transforms compile once when the project loads and call into a shared engine per source, so an EMA, a unit conversion, or a calibration curve costs roughly a function call per frame. Transforms can derive virtual datasets (no frame index, computed entirely from other registers), which is how things like running averages, rate-of-change, and derived KPIs become first-class datasets. See Dataset Value Transforms.
Buttons, toggles, sliders, knobs, text fields, and a freeform Output Panel send data back to the device. Each one runs a JavaScript template (GCode, SCPI, Modbus, NMEA, CAN, SLCAN, GRBL, custom binary packets) to convert UI state into bytes. There's a Transmit Test Dialog so you can preview the wire output before firing the real command. See Output Controls.
Output widgets cover button-press commands; the Control Loop covers automation. A project carries one setup() / loop() script, the same mental model as an Arduino sketch, that Serial Studio runs on a worker thread over the life of a connection. Through the I/O scripting SDK (io.*: device writes, deviceWriteAndWait handshakes, latest-frame capture, dashboardTick) the loop can send wake-up sequences, poll registers on a timer, keep a link alive, or step a state machine, without touching firmware. The loop runs off the data hotpath and is bounded by a watchdog, so a slow script can't stall parsing or the UI. See Control Loop.
Sessions can be recorded into a SQLite .db file. Parsed frames, raw bytes, data-table snapshots, and project metadata all live in one file. The Database Explorer browses, tags, and exports sessions. The SQLite Player replays a stored session through the live FrameBuilder pipeline so dashboards and reports work identically on recorded data. Session Reports turn the same database into a styled PDF with cover, test info, summary, and per-parameter chart sections. See Session Database and Session Reports.
XMODEM, YMODEM, and ZMODEM are built in for firmware uploads, log retrieval, and any device that talks one of the classic file-transfer protocols. ZMODEM includes ZRPOS-based crash recovery. See File Transmission.
Two features aimed at the engineer-hands-off-to-operator workflow. A deployment is a saved native launcher (.lnk / .app / .desktop) that opens a specific project with a fixed set of runtime flags (toolbar hidden, optional auto-connect and fullscreen), so an operator gets a single-icon entry point instead of hunting for the right .ssproj. A Project Lock puts a password gate (salted PBKDF2-SHA256, stored in the project file) in front of the Project Editor, so an operator can run the dashboard but can't rewire parsers or move widgets mid-shift. Neither pretends to be a security boundary; both are about operator/engineer separation. See Operator Deployments and Project Lock.
Two complementary surfaces:
The Assistant uses the same command surface as the MCP API, so anything the API can do, the Assistant can do, and vice versa. The Assistant runs read-only commands automatically and asks for approval on anything that mutates the project. Connection control (connect/disconnect, io.* device settings) stays blocked unless the Allow device control toggle is on, and even then every such call requires an explicit confirmation, so a wrong answer cannot knock you offline mid-shift.