Visual walkthrough — MIL-STD-1553 — military avionics bus
We will earn every symbol. By the end you will be able to draw the timeline and predict the total time for any message, not just this one.
Step 1 — One bit takes one microsecond
WHAT. The bus moves data at 1 Mbit/s. "Mega" means million, "bit/s" means bits per second. So one million bits leave the wire every second.
WHY this matters first. Every later number is just a count of bits multiplied by the time for one bit. So we must nail down that one-bit time before anything else.
If one second carries bits, then the time for one bit is one second split into a million equal slices:
- — the duration of a single bit slot (what we're solving for)
- the 1 second on top — our unit of time
- the 1,000,000 on the bottom — how many bits fit in that second
- — "microsecond", one millionth of a second ( s)
PICTURE. Below, one second is a long bar chopped into a million ticks; zoom in and each tick is exactly wide. That width is our atom of time.

Step 2 — Each bit needs an edge in the middle (Manchester II)
WHAT. Inside each slot the voltage does not sit flat — it flips in the middle. Up-flip in the centre = logic 1; down-flip in the centre = logic 0. This is Manchester II (also written Biphase-L), the exact variant MIL-STD-1553B mandates. From here on we always say Manchester II — never bare "Manchester" — because only this variant guarantees a centre transition in every bit, which is the property the timing below rests on.
WHY this tool and not plain levels? If we just held the wire HIGH for a "1", then 100 ones in a row would be 100 µs of nothing changing. The receiver's clock, guessing where each bit starts, would slowly drift and miscount. We need a guaranteed heartbeat. So the question is: what encoding forces the signal to change at least once every bit? Manchester II answers it — the mid-bit flip is mandatory, so the longest the wire can ever stay still is half a bit:
- — the longest stretch with no edge (worst case for the clock)
- dividing by 2 — because Manchester II places its guaranteed edge at the centre of the bit; two adjacent centre-edges are one bit apart, but a bit boundary that happens to not flip leaves at most one half-bit () of flat line before the next mandatory centre-edge arrives
PICTURE. Watch the red trace: whatever the data, a transition lands dead-centre of every slot. The clock recovery circuit latches onto those centre-edges like a metronome.

Manchester II spends one per data bit — it changes the shape of a bit, not its duration. So Step 1's timing survives untouched.
Step 3 — Bundle 20 bit-slots into one "word"
WHAT. Bits never travel alone. The bus groups them into a word: a 3-bit sync marker, 16 payload bits, and 1 parity bit.
WHY 3 + 16 + 1 = 20? The 16 in the middle is the actual number (an angle, a velocity). The single parity bit is a self-check (Step 6). The 3-bit sync is a deliberately illegal Manchester II pattern — 3 µs held one way, which normal data can never produce — so the receiver always knows exactly where a word begins. Count the slots:
- 20 — total bit slots in one word (3 sync + 16 data + 1 parity)
- — carried straight from Step 1
- — the time to send any one word, command, status, or data
PICTURE. A single ruler 20 µs long: a fat sync block on the left, sixteen small data slots, one parity slot. This one bar is the building brick of every message.

Step 4 — The command word starts the conversation
WHAT. The Bus Controller (BC) speaks first, sending one command word that says who speaks next and how much. For our example: address RT 5, T/R = 1 (transmit), subaddress 3, word count 8.
WHY the BC alone starts? Because only one node is ever allowed to initiate, there are zero collisions — nobody else can jump in. That single rule is what makes the timeline predictable. The command costs exactly one word:
PICTURE. The timeline opens with one 20 µs magenta block labelled "BC: CMD (RT5, xmit, 8 words)". Everything after it is a reply to this block.

Step 5 — The response gap: a mandatory pause
WHAT. After the command ends, the addressed RT does not answer instantly. It waits a response time before speaking. MIL-STD-1553B specifies this response time as a window from 4 µs to 12 µs (measured mid-parity-bit of the command to mid-sync of the reply).
WHY a window and not a single number? Different RTs are built from different hardware and turn their transceiver around at slightly different speeds. The spec refuses to pin one value; instead it guarantees the reply lands somewhere in . That guarantee is enough for determinism — because we always plan against the edge of the window we care about.
For the worked example we follow the classic 8 µs so our number matches the parent note:
- — the enforced silence between command and reply
- the range 4–12 µs — the spec window; scheduling proofs use the top (12), illustrations use the middle (8)
PICTURE. A shaded "quiet zone" sits between the command block and everything that follows — flat line, no edges. This is the only silence in the whole transaction.

Step 6 — The reply: status word + data words, back to back
WHAT. RT 5 answers with one status word (its acknowledgement + health report) then 8 data words (the radar readings), with no gaps between them.
WHY status first, then data with no gaps? The status word is the RT saying "heard you, I'm healthy, here it comes" — it carries the parity self-check and error flags. After it, the data streams edge-to-edge because any gap would make the total length depend on the RT's mood, destroying determinism. So the reply cost is one status word plus the counted data words:
- — the word count the command asked for; here
- the first term — the single mandatory status word
- — the payload, one 20 µs brick per data word
Plug in :
PICTURE. After the gap: one violet status block, then eight orange data blocks fused together — no white space between them.

Step 7 — Add it all up: the 208 µs total
WHAT. Lay the four pieces end to end on one line: command, gap, status, data.
WHY summing works. Because there are no collisions and no variable pauses, the total is just addition — the deepest property of the whole standard:
- 20 command · 8 gap · 20 status · 160 = 8 data words × 20 µs
- the answer 208 µs — fixed, predictable, and known before the flight
PICTURE. The full timeline as one strip, each region colour-coded and length-labelled, with the running total ticking to 208 µs at the right edge.

Step 8 — Edge & degenerate cases (nothing is left undrawn)
WHAT & WHY. A timeline you can trust must survive its corners. Four of them:
- (the maximum message). Word count is 5 bits, and the value encodes 32 (the largest a message can carry). Then — still fixed, just longer.
- BC writes instead of reads (T/R = 0). The BC sends command then the data words itself; the RT answers with only a status word. Word count now sits before the gap, but the arithmetic is identical.
- RT never answers (dead terminal).
Now the worked bound for a dead RT. The BC sends the command, listens through the full timeout, hears nothing, and moves on:
- — the command still went out
- — the bounded wait before declaring the RT silent
- the schedule advances after just 34 µs — the dead RT costs less time than a healthy one, and the number is known in advance, so no deadline is threatened.
- A parity bit fails.
The BC discards the bad reply and re-runs the whole 208 µs. With the design limit :
Worst-case latency is larger, but still a known ceiling. Determinism means bounded, not constant.
PICTURE. Four mini-timelines stacked: max-length, BC-write, no-response timeout, and retry — each with its own bounded total.

The one-picture summary
Everything above, compressed: a single bit () → a word () → command + gap + status + data → 208 µs, with the edge cases fanning out from the same skeleton.

Recall Feynman retelling — say it like a story
The bus is a walkie-talkie channel where only the captain (the Bus Controller) is allowed to speak first — so no two people ever talk over each other. Time is chopped into millionth-of-a-second slices; that's one bit. Every bit flips in its own middle so the listener's clock never gets lost — that's Manchester II. Twenty slices make one "word," and a word always costs 20 microseconds no matter what it says. The captain sends one word — "Radar, give me 8 readings" — waits a short, deliberate breath (4 to 12 microseconds; we plan with 12, we illustrate with 8) so the radar can wake up and grab the mic, and then the radar replies with one "okay, I'm fine" word plus 8 reading words, all glued together with no pauses. Add them: 20 + 8 + 20 + 160 = 208 microseconds. Because nobody interrupts and no pause is fuzzy, that total is decided before the plane even leaves the ground. If the radio is dead, the captain waits a fixed 14-microsecond timeout (34 µs total) and moves on; a garbled reply just makes the captain ask again — capped at 3 tries, so 624 microseconds tops. Nothing is ever a surprise, and in a cockpit, no surprises is the whole point.
Recall Quick self-test
What is one bit's duration on the bus? ::: , from bits. Why does every bit flip in its middle? ::: Manchester II guarantees a centre edge each bit so the receiver clock can't drift; longest flat stretch is . How long is any 1553 word and why? ::: = 3 sync + 16 data + 1 parity bits, each . Break 208 µs into its four parts. ::: 20 (command) + 8 (gap) + 20 (status) + 160 (8 data words). Give the general formula for an -word transaction. ::: . Which gap value do you use in a deadline proof, and which for a demo? ::: 12 µs (worst case) for proofs; 8 µs (nominal, mid-window) for illustration. A dead RT — what bounded time does the schedule lose? ::: . A parity error occurs — is timing still deterministic? ::: Yes; with design retry limit the ceiling is , and a known ceiling is what determinism means.
See also: ARINC 429 and CAN Bus (contrast the timing models), RS-485 Protocol (same wires, different discipline — see parent's Mistake 1), Time-Triggered Architectures and Real-Time Scheduling Theory (why a bounded ceiling is priceless), DO-178C Certification (why flight-proven timing wins).