What is Logb

Logb is a self-describing binary format for time-series measurement, bus-trace and simulation recording — designed to be written by embedded loggers and read by analysis tools. The name is `log` plus `b` for binary, the convention that makes

extension `.logb`.

The format is version 0.1, draft, for discussion. It is not frozen. What is implemented, what is not, and the reasoning behind each decision are written down on the status page, and the questions where the design is still genuinely undecided are on the open questions page.

The format is the artifact

Logb is a format, not a library. The specification is the normative document: twelve sections, complete enough to implement from, published under the same MIT terms as the code. A conforming reader is roughly a thousand lines plus a decompressor.

One implementation happens to exist today — a reference library in Go — and it is one possible implementation, not the definition. Where the two disagree, the specification wins and the implementation is the bug. Other implementations are welcome and belong on the implementations page.

There is nothing to buy, no consortium to join, and nobody to ask.

The design in one image

The design is a varve: one season's sediment couplet in a lake bed, laid down in sequence, never rewritten, each layer self-dating, and readable from any cut face of the core — including a core that snapped. Geologists date events by counting them. That is the design rather than a decoration on it, and §1 of the specification is the same idea stated as six rules:

1. Nothing points forward. A frame may reference earlier bytes, never later ones. A writer never seeks back to patch a field it already emitted.

2. Append-only, crash-safe. A file truncated at an arbitrary byte is a valid file containing every record up to the last intact frame. No repair tool, no recovery mode.

3. Cut anywhere, decode. A reader handed the middle of a file, with no access to the start, resynchronises and decodes records with full schema. Schema is repeated, not stated once.

4. No dependencies. No XML, no external schema registry, no library that must still exist in 2050.

5. Raw is preserved. Stored values are the bits the sensor or bus produced; physical values are derived by a declared conversion, so a read-modify-write round trip is byte-identical.

6. Fixed cost per record. Adding a channel does not change the cost of decoding an unrelated channel.

If a proposed feature breaks one of these, the feature loses.

The shape of a file

file    := file-header segment* [index-frame] [end-frame]
segment := sync-frame schema-frame+ run-frame* (meta | attach | data)*

A segment is a self-contained decode unit: it restates every schema needed by the data frames it contains. Within a segment, DATA frames carry batches of fixed-size records; a schema declares the record's bit layout, its axis, and its identity. A writer starts a new segment periodically — that is writer policy, not a rule of the format.

Both the index frame and the end frame are optional by construction: a file that lost power simply lacks them and still reads.

Where it sits

Two families of format already exist, and each solves half of the problem a bus or bench recording poses.

General-purpose containers solve the file and punt on the payload. MCAP, Avro and their relatives get chunking, appending and compression right, but their messages are opaque bytes decoded according to a schema the file does not carry for bit-level signals. Record a CAN bus into one and you have stored the frame; naming `EngineSpeed` still needs the DBC sidecar.

Measurement formats solve the payload and are closed, or fall short. MDF4 has a real bit-level signal model and is paywalled. TDMS is openly documented and streaming — and then its metadata turns out to be incremental, so a cut file loses everything stated earlier.

Logb takes both halves: the container properties of the first family and the bit-level signal model of the second, with the specification readable by anyone. The long version of this argument, with the formats named and the near misses explained, is on the rationale page.

Not an automotive format

Logb was born in an automotive context, but the domain axis is general rather than time-specific: a transient sweeps time, an AC analysis sweeps frequency, a sweep can be angle or distance. Bus traces, bench measurements and simulator output are the same kind of file here. §11 of the specification is a complete mapping from SPICE `.raw` files onto Logb — and under Logb a simulator emits frames as it solves, so a long transient analysis becomes watchable while it runs.

Where to go next


MD5 signature: d9b9a6cba289a9a27a553d576e495ed6