The D.T.MUX format, and how it compares to Chapter 10

Why a house format still exists

D.T.MUX is older than the general adoption of Chapter 10. It was designed for a recorder that had to write heterogeneous channels — analog, buses, serial links, video, discretes — first onto magnetic tape, then onto disk, then onto solid-state memory, without the file structure changing underneath the tools.

It is not a competitor to the standard. ETEP recorders write both, and the same acquisition can produce either. The interesting question is not which format wins, but what each one is for.

A house format buys two things. It can specify what the standard deliberately leaves open — physical units, calibration, acquisition quality — and it can follow the hardware without waiting for a committee. What it costs is equally clear: you have to supply the reader. Which is why a viewer and a converter are part of the product rather than an accessory to it.

Blocks instead of packets

Everything in a D.T.MUX recording is a block: a fixed-size header followed by the data of one channel. Blocks are emitted at regular intervals, and there is no constraint on the order in which channels appear — a writer serves each channel as its buffer fills, which is exactly what an acquisition system wants to do.

The header opens with a synchronisation pattern four 32-bit words long. Chapter 10 uses sixteen bits for the same job. That length is a tape-era decision, and it turns out to be a gift on a live stream: the chance of the pattern appearing by accident inside data is negligible, so a reader joining a stream mid-flight locks onto the next block boundary immediately and without ambiguity.

The format thinks in 32-bit words rather than bytes. Samples are packed most-significant-first, and the last word of a block may be only partly filled — which is why the header carries two lengths: the total size of the block and the number of words that actually carry data. Filling words are allowed between blocks, so a writer can align to whatever the medium prefers, and the reader strips them using the useful-word count.

Blocks that contain nothing but a header are legal, and they are not waste. They keep the per-channel block counter and the time base moving while a channel has nothing to say, which means a gap in a channel is visible as a gap rather than inferred from an absence.

A recording that describes itself

Every recording opens with a setup block — historically called the secretariat — that describes the acquisition in plain text fields: which channels are present, how each card is configured, the sample rates, the acquisition mode, the date and time. It plays exactly the role TMATS plays in a Chapter 10 file.

Optional blocks follow, and this is where the format goes further than the standard. A user-information block carries the name of each channel, its unit, and the A·x + B conversion from raw counts to a physical quantity. A card-calibration block carries the gain and offset of the acquisition path itself. A sensor-calibration block carries what turns volts into a physical measurement.

A few more service blocks complete the picture: a table of contents listing the recordings held on the medium, an event-marker block listing the positions that were flagged during the flight, an identification block for the medium itself, and an end-of-record marker so that one medium can carry several recordings back to back.

Time, and the health of time

Each block header carries 48 bits of time — the same width as the Chapter 10 relative time counter, and a completely different idea. Chapter 10 counts ticks at 10 MHz and needs separate time packets to tie that count to a calendar. D.T.MUX writes the calendar itself: day of year, hours, minutes and seconds, plus the sub-second part, as the date of the first sample in the block.

The consequence is that a block is self-dating. Cut a file anywhere, lose the beginning, recover a fragment from a damaged medium: every block you can still read knows when it was acquired, with no need to find a preceding time packet.

And the header carries something rarer. A flag identifies which generator produced that time — internal system clock, IRIG time, GPS time — and, distinctly, whether IRIG or GPS had been lost. Absolute, relative and microsecond variants are distinguished too.

That deserves emphasis, because it is the kind of detail you only appreciate after a campaign has gone wrong. In most formats, "the GPS dropped out for forty seconds somewhere in the second sortie" is something you reconstruct afterwards from a status channel, assuming somebody thought to record one. Here it travels with every block: you know, block by block, which clock dated the data and whether that clock was healthy. That is the difference between a doubt and an answer.

A further header field locates a particular sample inside the block — the start of a user frame, or the exact instant of a video image — which is how a stream of blocks can be aligned to something finer than the block itself.

Side by side with Chapter 10

Read that comparison in both directions. Chapter 10 wins on universality: any compliant tool opens the file, which is worth a great deal on a programme with five companies in it, and it is why customers mandate it. D.T.MUX wins on self-containment: the units, the calibration, the time source, the health of that source and the acquisition quality are all inside the file.

Neither of those advantages is rhetorical. They correspond to two different failure modes — "nobody can open my file" and "nobody can tell me what this file means" — and a serious campaign is exposed to both.

Recording only what matters: acquisition modes

The setup block also declares how the acquisition was triggered. Continuous is one option. A simple trigger with a declared post-trigger duration is another. A burst mode captures a defined number of triggered segments, and a two-rate mode records a different number of samples before and after the event.

This matters more than it sounds. On a shock or vibration campaign you do not want hours of continuous recording of nothing happening; you want the segments around the events, with enough pre-trigger to see what led in. Because the mode is declared in the file, a reader knows it is looking at a set of segments rather than a continuous stream, and can present it as such instead of drawing a misleading straight line across the gaps.

Honesty about a format that has lived

The format accepts both byte orders, and there is a variant in which the two halves of every 32-bit word are swapped — a scar left by the machines that once read the tapes. A reader detects it on the synchronisation pattern itself, which is one more argument for having a long one.

Any format that has survived from magnetic tape to solid-state memory accumulates that kind of history. Being explicit about it is more useful than pretending otherwise: a reader worth using detects the variant, adapts, and says nothing about it. The alternative — a format with no history — usually means a format with no fleet behind it.

So which one should you record?

• Chapter 10 when the deliverable crosses a company boundary, when the customer analysis chain already speaks it, when a programme mandates it, or when the file must still open in twenty years with tools nobody has written yet.
• D.T.MUX when you want the file to carry its own calibration, units and time diagnostics, when the campaign is trigger-based, or when the whole chain from sensor to report is inside the same toolset.
• Both, which is the usual answer, because the choice is not exclusive and the cost of writing the second one is close to zero.
• And in every case, convert rather than re-fly: turning one container into the other after the flight is a software operation, and a second sortie is not.