v0.1 draft — published early, in public, on purpose
DSX (Drone Show eXchange) is an open, vendor-neutral file format for drone light shows — designed to be flight-capable and machine-validatable, not just viewable.
What is not true yet
No aircraft has flown a DSX file. The specification, the JSON Schemas and the normative sampler are tested today; the .dsb binary encoding is still an outline; sampler vector coverage is not exhaustive. Stating this plainly is the point — a format that overstates its maturity reproduces the exact behaviour this project exists to replace.
The gap
Every format in use sits in one of two states: open but not flight-ready, or flight-ready but undocumented. The consequences are not hypothetical — shows get exchanged as CSV and lose their safety metadata, geofence fields exist but are never populated, altitude reference (AGL / AMSL / ellipsoid) is left implicit, and axis handedness differs silently between tools. Each of those has a known failure mode.
| Format | Open & documented | Flight-capable | Third-party validatable |
|---|---|---|---|
| VVIZ | yes | no — a visualisation format, not intended as a source of flight-ready path data | no |
| .skyc / .skyb | source-readable (GPL), no public spec | yes | no |
| .dac, .bin, .path/.path3, .essp, vendor .json | no public specification located | yes | no |
| CSV | trivially open | partially | no |
| DSX | yes | designed for it — not yet flown | container, schema, §10 rules and sampler vectors, tested today |
“Located” is the accurate claim: the absence of a public specification is not something this project can prove, only fail to find (searched 2026-08).
Design
Mixing exchange and upload into one file is the mistake most formats make. DSX separates them, and specifies the compiler between them as deterministic: identical input must produce byte-identical output. That is what makes a show file auditable.
Exchange, archive, review, regulatory submission.
ZIP + JSON — diffable, human-readable
Upload to the aircraft.
Binary TLV — MCU-parseable
What a given aircraft or payload can actually do.
JSON — shipped inside the .dsx
Every conforming .dsx MUST be reducible, through a normative sampling algorithm, to t, x, y, z, R, G, B at any frame rate — bit-identically in every implementation. Any existing system therefore has an import path on day one, without understanding polynomials.
t, x, y, z, R, G, B
Backed by a reference implementation and six hand-computed test vectors, not by prose alone.
A show references a device profile by stable UUID and declares the mode it was authored for. A tool can therefore refuse to upload a show whose declared flight envelope exceeds the aircraft’s published limits — instead of discovering it in the air.
Safety
Termination escalation, geofences, link-loss behaviour, GNSS-integrity policy and payload interlocks are fields in the file — playback-independent and evaluable on board, without a connection to the show player.
Reversible. The show stops where it is.
A return the file declares as feasible — or honestly declares as not.
Controlled descent, wherever the aircraft is.
Irreversible. The fall must already be contained by the safety area.
This requirement exists because of a documented accident: a pilot let the show continue while aircraft were already falling into a crowd, because pausing it would have required too many steps. An abort path that is too expensive to use is not a safety feature. DSX therefore treats “how many actions does this rung cost” as part of the file.
A return-to-home is not available at every moment of a show. DSX makes the infeasible windows explicit, with a reason and the escalation rungs that remain available instead — rather than letting a ground station discover it under time pressure.
The declared safety area MUST enclose the fall trajectory of a disarmed aircraft from every position the show reaches. The disarm rung is only usable if that has been established beforehand.
Profiles
A manufacturer does not have to implement everything to be conformant. Each level is a complete, testable commitment.
Positions and RGB only. CSV-equivalent. Any controller can do this.
Segment trajectories, light programs, safety envelope, takeoff grid, RTH.
Yaw, payloads (pyro, recovery, dispensers), multi-fleet, audio sync, signature.
Conformance
Licensing
Specification, schemas, examples, device profiles
Community Specification License 1.0
Its patent grant covers implementing the specification — which is the whole point, and which a software licence does not reliably give.
Code, reference tools, conformance suite
Apache-2.0
Embeddable in proprietary firmware, with a patent grant whose scope genuinely fits code.
The name “DSX” and the .dsx extension
No trademark held, and none needed
A format name is a technical designation, like .zip or .json. Anyone may implement; conformance is defined by the public test suite, not by a mark.
Explicitly not GPL: a reference implementation under GPLv3 cannot be embedded in the proprietary firmware that has to read the format, and a standard whose reference code its own audience cannot link has an adoption ceiling. Explicitly not MIT: no patent grant. Explicitly not Apache-2.0 for the specification text: its §3 licenses patents to “otherwise transfer the Work” — the document — not to implement what the document describes.
Issue creation is open. Proposals are discussed, not closed as “not planned”. Contributors are credited by name in the specification. That is a commitment, stated so it can be held against us.