Worked examples — MIL-STD-1553 — military avionics bus

This is the "roll up your sleeves" page for MIL-STD-1553 — military avionics bus. Every timing number, every fault case, every degenerate input the standard can throw at you — we work them all here, from zero. If a symbol shows up, we define it first.

---

The scenario matrix

Before working examples, let us list every kind of situation this topic can put in front of you. Think of it as a checklist: by the end, every row has at least one fully-worked example.

#	Case class	What makes it tricky	Covered by
A	Bus timing — normal message	add up sync/data/gap correctly	Ex 1
B	Word-count boundary (0 encodes 32)	the "zero means max" trap	Ex 2
C	Bus utilisation / limiting value	fraction, must be < 100%	Ex 3
D	Response-time window (min & max edge)	RT too slow → error, RT too fast → also illegal	Ex 4
E	Differential signalling with noise (common-mode AND differential)	positive noise, negative noise, and noise that does NOT cancel	Ex 5
F	Manchester clock-drift limit (degenerate: all-0 / all-1)	worst case string, why edge still appears	Ex 6
G	Redundancy probability (limiting: p→0, p→1)	multiplying probabilities, sanity bounds	Ex 7
H	Real-world word problem (schedule a whole minor frame)	many messages, deadline	Ex 8
I	Exam twist (retry inflates worst-case latency)	the case people forget	Ex 9
J	Passive diagnosis from a Bus Monitor trace	infer the fault, transmit nothing	Ex 10

Ten rows, ten examples. Let us define the two symbols we will reuse everywhere.

---

Example 1 — Case A: a normal transmit transaction

Forecast: Guess now — is the answer closer to $50\mu s$, $150\mu s$, or $500\mu s$? Write it down.

The pieces of a BC-reads-from-RT transaction, in order. Figure s01 is a timeline: the horizontal axis is time in microseconds (0 to about 108), and each coloured rectangle is one block of bus activity occupying its width in time (there is no vertical/value axis — height is purely for labelling). Left to right you see a blue command block (20 μs wide), a thin gray response gap (8 μs), an orange status block (20 μs), then three green data blocks (20 μs each), and a red double-arrow spanning the whole thing labelled "Total = 108 us." Follow the blocks left to right as you read the steps.

1. Command word (BC → RT): 1 word. In the figure, this is the leftmost blue block. Why this step? The BC must first announce "RT #7, transmit 3 words." Nothing on the bus happens without a command. That is 1 word $=20\mu s$.
2. Response gap: $8\mu s$. The thin gray block after the command. Why this step? The RT is not instant. The standard gives it a response-time window (nominally 4–12 $\mu s$) to wake up and start replying. "Middle of the window" $=8\mu s$.
3. Status word (RT → BC): 1 word $=20\mu s$. The orange block. Why this step? The RT must acknowledge and report health before data. This is mandatory even on a clean read.
4. 3 data words (RT → BC), back-to-back, no gaps: $3\times 20=60\mu s$. The three green blocks with no gaps between them. Why this step? Data words follow the status word immediately — gaps here would waste deterministic bus time.

Total: $T=\underset{\text{cmd}}{\underbrace{20}}+\underset{\text{gap}}{\underbrace{8}}+\underset{\text{status}}{\underbrace{20}}+\underset{\text{3 data}}{\underbrace{60}}=108\mu s$

Verify: Count the words on the wire = 1 + 1 + 3 = 5 words $=100\mu s$, plus one $8\mu s$ gap = $108\mu s$. ✓ Units are all $\mu s$, and $108<208$ (the parent note's 8-word example), which makes sense: fewer data words → shorter. Forecast check: closest to $150\mu s$ side, so "about a hundred" was the right ballpark.

---

Example 2 — Case B: the word-count-zero trap

Forecast: Zero words? Or something else?

1. Read the field literally: it says 0. Why this step? Always start from the raw bits.
2. Apply the 1553 encoding rule. The word-count field is 5 bits, so it can hold values $0$ to $2^5-1=31$. But a message needs to carry 1 to 32 words. That is 32 possibilities, and 5 bits give exactly 32 codes. The standard maps them as: values $\mathrm{1..31}$ mean "that many words," and the value $0$ is reused to mean 32. Why this step? Because you cannot fit 33 meanings (0 through 32) into 32 codes — so "0 real words" is meaningless anyway (why send an empty message?), and the code $0$ is recycled for the useful maximum, 32.
3. Therefore Word Count = 0 means 32 data words.

Data-word time: $T_{\text{data}}=32\times 20\mu s=640\mu s$

Verify: $5$ bits → $2^5=32$ codes, and we need to name $\{1,\dots ,32\}$ which is also 32 items. A perfect bijection, so no code is wasted. ✓ $32\times 20=640$. ✓

---

Example 3 — Case C: bus utilisation (a limiting fraction)

Forecast: Under 1%, a few percent, or over 50%?

1. How much bus time is available per second? Why this step? "Utilisation" = time-used ÷ time-available. One second $=1,000,000\mu s$.
2. How much does one update cost? One transaction $=208\mu s$.
3. How many updates per second? $50$.
4. Time used per second: $T_{\text{used}}=50\times 208=10,400\mu s$
5. Utilisation: $U=\frac{10,400}{1,000,000}=0.0104=1.04\%$

Verify: The parent note claims "1.5% bus utilisation" for a 50 Hz sensor read — same ballpark; the small difference is because they rounded to $\approx 300\mu s$ per read rather than exactly 208. Sanity bound: $U$ must satisfy $0\le U\le 100\%$, and $1.04\%$ sits comfortably inside. ✓ Units: $\mu s/\mu s$ = dimensionless. ✓

---

Example 4 — Case D: both edges of the response-time window

Forecast: Only the too-slow one is a problem, right? Guess before reading.

We must check both boundaries — this is why Case D is on the matrix.

1. RT (a): replies at $2\mu s$. Why check? $2<4$, so it is too fast — before the minimum. The BC's receiver may not yet be listening; this is a timing violation. Illegal.
2. RT (b): replies at $7\mu s$. Why check? $4\le 7\le 12$. Inside the window. Legal.
3. RT (c): replies at $15\mu s$. Why check? $15>12$, past the maximum. The BC declares a no-response timeout and treats the message as failed.

BC action on (a) and (c): the message is marked errored; the BC will retry (typically up to 3 attempts, see Ex 9). If retries also fail, the BC may switch to the other bus.

Verify: The legal interval is the closed set $[4,12]\mu s$. Membership: $2\notin$, $7\in$, $15\notin$. ✓ Both a lower and an upper violation are covered — that is the "every case" requirement for a window.

---

Example 5 — Case E: differential signalling, common-mode AND differential noise

Forecast: Does the huge $+50\text{ V}$ common-mode spike destroy the bit? And can differential noise — noise that is different on each wire — ever threaten the reading?

Figure s02 is a voltage-versus-time plot: the horizontal axis is time (arbitrary units, 0 to 4) and the vertical axis is voltage in volts (from about $-8$ to $+14\text{ V}$). The blue curve is noisy wire A ($+5\text{ V}$ plus a common-mode bump), the orange curve is noisy wire B ($-5\text{ V}$ plus the same bump, so it rides up and down in lockstep with blue), the thick green curve is their difference $V_A^{\prime }-V_B^{\prime }$ pinned flat at $+10\text{ V}$, and the red dashed horizontal line marks the $+1.4\text{ V}$ threshold. The green line staying perfectly flat while blue and orange wobble is the whole point of Part 1 — watch it ignore the bump.

Part 1 — common-mode noise (the noise cancels).

1. Write the receiver's measurement. With equal noise on both wires, $V_A^{\prime }=V_A+\Delta V$ and $V_B^{\prime }=V_B+\Delta V$: $V_{\text{diff}}=(V_A+\Delta V)-(V_B+\Delta V)=V_A-V_B$ Why this step? The two $\Delta V$ terms cancel algebraically — the answer no longer depends on $\Delta V$ at all. This is the magic exploited by twisted pair (see RS-485 Protocol).
2. Plug each noise value: (i) $\Delta V=+3\text{ V}$ → $V_{\text{diff}}=5-(-5)=10\text{ V}$. (ii) $\Delta V=-3\text{ V}$ → still $10\text{ V}$. (iii) $\Delta V=+50\text{ V}$ → still $10\text{ V}$. Why this step? To show positive, negative, and enormous common-mode noise all give the identical clean reading.
3. Compare to threshold: $10>1.4$, so all three read logic 1. No bit flips. This is the green line in the figure, unmoved by the bump.

Part 2 — differential noise (the noise does NOT cancel).

4. Write the measurement with unequal noise. Now $V_A^{\prime }=V_A+1.0\text{ V}$ and $V_B^{\prime }=V_B-1.0\text{ V}$: $V_{\text{diff}}=(5+1.0)-(-5-1.0)=6.0-(-6.0)=12.0\text{ V}$ Why this step? Because the noise is different on each wire ($+1.0\text{ V}$ vs $-1.0\text{ V}$), it survives the subtraction — this is the one noise type differential signalling cannot reject.
5. Interpret. Here the differential noise happened to push us further from the threshold ($12>1.4$), so the bit is still safe. But if it had subtracted $6\text{ V}$ from the difference instead ($10-6=4\text{ V}$), we would be creeping toward the $1.4\text{ V}$ wall. Why this step? To make the honest point: differential signalling is a shield against common-mode noise only. Twisting the pair tightly is what keeps real-world noise common-mode (both wires see the same interference).

Verify: Part 1 — $V_{\text{diff}}=10\text{ V}$ for every $\Delta V$, all $>1.4$ ✓. Part 2 — $6.0-(-6.0)=12.0\text{ V}$, and this depends on the noise (it did not cancel), confirming differential noise is the residual threat. ✓

---

Example 6 — Case F: Manchester worst-case drift (degenerate input)

Forecast: With 100 identical bits, does Manchester really keep giving edges?

The degenerate input (all bits the same) is exactly where naive encodings fail — that is why it is on the matrix.

1. Recall the Manchester rule. Every bit period $T$ has a mid-bit transition (logic 0 = HIGH→LOW at the centre). See Manchester Encoding. Why this step? Because the transition is guaranteed per bit, "all zeros" cannot suppress it.
2. Longest gap without an edge. Within a single bit of length $T$, the guaranteed edge sits at the centre, $T/2$ from each end. The worst run without any edge is therefore: $T_{\max }=\frac{T}{2}=\frac{1\mu s}{2}=0.5\mu s$ Why this step? Even 100 zeros give you an edge every $0.5\mu s$ — the PLL (phase-locked loop, the circuit that re-syncs the clock) never loses lock.
3. NRZ comparison. In NRZ, a "0" is just a steady level. 100 zeros $=100\times T=100\times 1=100\mu s$ with zero transitions. Why this step? To make the payoff concrete: $0.5\mu s$ vs $100\mu s$ is a $200\times$ improvement in edge density.

Verify: $T/2=0.5\mu s$ regardless of how long the run is (100, 1000, or a million zeros). ✓ NRZ gap $=100\mu s$ and $100/0.5=200$. ✓ Degenerate case handled: the all-same-bit input is the worst case and Manchester still passes.

---

Example 7 — Case G: dual redundancy, limiting values of $p$

Forecast: Is the improvement roughly $10\times$, $100\times$, or $1000\times$?

1. Independent failures multiply. Comm is lost only if both buses fail: $P=p\times p=p^2$. Why this step? "Independent AND" multiplies probabilities — a core probability rule, and the whole justification for two buses.
2. (a) Plug $p=0.001$: $P_{\text{dual}}=(0.001{)}^2=0.000001=10^{-6}$
3. (b) Limits.
   • $p\to 0$: $p^2\to 0$. Good — perfect buses give perfect availability.
   • $p\to 1$: $p^2\to 1$. Also correct — if each bus always fails, two of them still always fail. Redundancy cannot save you from certain failure. Why this step? Checking limits catches a nonsense formula: any valid probability must stay in $[0,1]$ and behave sensibly at the ends. $p^2$ does.
4. (c) Improvement factor: $\frac{P_{\text{single}}}{P_{\text{dual}}}=\frac{p}{p^2}=\frac{1}{p}=\frac{1}{0.001}=1000$

Verify: $(0.001{)}^2=10^{-6}$ ✓. Bounds: $0\le p^2\le 1$ for $p\in [0,1]$ ✓. Improvement $1/p=1000\times$ matches the parent note. ✓ This meets DO-178C Certification Level A availability; a third bus would only take you to $p^3=10^{-9}$ — diminishing returns for the added weight.

---

Example 8 — Case H: schedule a whole minor frame (real-world)

Forecast: Comfortably fits, just barely fits, or overflows?

1. Engine read (transmit, 4 data words). Command + gap + status + 4 data: $20+8+20+4\times 20=20+8+20+80=128\mu s$ Why this step? Same recipe as Example 1, with 4 data words instead of 3.
2. Weapons write (receive, 2 data words). For a receive, the BC sends command and the 2 data words, then the RT replies with a status word after the gap: $\underset{\text{cmd}}{\underbrace{20}}+\underset{\text{2 data}}{\underbrace{2\times 20}}+\underset{\text{gap}}{\underbrace{8}}+\underset{\text{status}}{\underbrace{20}}=20+40+8+20=88\mu s$ Why this step? On a write, data flows BC→RT alongside the command; the status word comes back last. Order differs from a read, but the word-count is what drives the time.
3. Sum the frame: $T_{\text{frame}}=208+208+128+88=632\mu s$
4. Fit check. Deadline $=10\text{ ms}=10,000\mu s$. Since $632<10,000$, it fits, with slack $10,000-632=9,368\mu s$.
5. Utilisation: $U=\frac{632}{10,000}=0.0632=6.32\%$

Verify: Word counts on the wire: nav 10, radar 10, engine 6, weapons 4 → 30 words $\times 20=600\mu s$; gaps: 4 $\times 8=32\mu s$; total $632\mu s$. ✓ $U=6.32\%$, well under 100%. ✓ Ample headroom to add more RTs — the essence of deterministic scheduling.

---

Example 9 — Case I: exam twist — retries inflate worst-case latency

Forecast: People quote $208\mu s$. What is the real worst case?

The trap: nominal timing assumes success. Worst case must include the failed attempts too.

1. Cost of one failed attempt. A failed attempt still occupies the bus (command + partial/garbled response) then triggers a timeout. Model it as the full transaction time plus timeout: $208+14=222\mu s\text{ per failed attempt}$ Why this step? The bus is not free during a failure — you still spent the transaction time before detecting the error.
2. Worst case = 2 failures then 1 success. With 3 attempts max, the ugliest legal path is: fail, fail, succeed. $T_{\text{worst}}=\underset{\text{2 failed}}{\underbrace{222+222}}+\underset{\text{final success}}{\underbrace{208}}=444+208=652\mu s$
3. (b) Why $208$ misleads. $208\mu s$ is the best case (first-try success). A real-time deadline analysis must budget the worst case, $652\mu s$ — over $3\times$ larger. Missing this is the #1 embedded-avionics latency bug.

Verify: $208+14=222$; $2\times 222=444$; $444+208=652$. ✓ And $652/208=3.13$, i.e. the naive number under-counts by more than a factor of three. ✓ For a $10\text{ ms}$ frame this still fits ($652<10,000$), but for a tight $1\text{ ms}$ loop it would blow the budget — always schedule for retries.

---

Example 10 — Case J: passive diagnosis from a Bus Monitor trace

Forecast: Did the RT die? Or is this a normal "nothing to send" case?

This is why the BM exists: post-flight, it is often the only record of a fault, since it can eavesdrop without disturbing the deterministic schedule.

1. The RT did respond. A status word appeared at $t=8\mu s$, inside the $[4,12]\mu s$ window (Example 4). So the RT is alive and heard the command. Why this step? Rule out the "dead RT" hypothesis first — a status word is proof of life.
2. But zero data words followed. For a transmit command with word count 4, the RT must send 4 data words back-to-back right after its status word (Example 1's recipe). The trace shows none. Why this step? A legal transmit reply is status + N data with no gap; missing data means the RT aborted mid-message.
3. Diagnosis: the status word's Message-Error bit was set, or the RT hit an internal fault after acknowledging. Either way the RT signalled "I heard you but I have no valid data," and correctly sent no garbage. Why this step? 1553 forbids sending data words when the status word flags an error — silence is the correct protocol behaviour, not a second fault.
4. Wasted bus time before the BC reacts. The BC allotted time for status + 4 data $=20+4\times 20=100\mu s$, but only the status ($20\mu s$) carried information. The BC detects the missing data and declares the message errored. Time consumed on this dead-end: $T_{\text{wasted}}=\underset{\text{gap}}{\underbrace{8}}+\underset{\text{status}}{\underbrace{20}}=28\mu s$ before the BC can start a retry.

Verify: Status arrival $8\in [4,12]$ so the RT is alive ✓. Expected reply would have been $20+4\times 20=100\mu s$, so $100-20=80\mu s$ of data never came ✓. Time to the fault point $=8+20=28\mu s$ ✓, matching the BM's own "status ends at 28 μs" timestamp. The monitor transmitted nothing throughout — it only listened.

---

Recall Self-test (reveal after you answer)

Word Count field reads 0 — how many data words? ::: 32 (the code 0 is reused for the maximum). One 1553 word takes how many microseconds on a 1 Mbit/s bus? ::: 20 μs (20 bits × 1 μs/bit). A common-mode noise spike of +50 V hits a logic-1 line ($V_A-V_B=+10$). What does the differential receiver read? ::: Still +10 V — common-mode noise cancels. Differential noise of +1V on A and −1V on B hits the same logic-1 line. What does the receiver read? ::: 12 V — differential noise does NOT cancel (this is the residual threat). Longest gap without an edge in Manchester II at 1 Mbit/s? ::: 0.5 μs (T/2), regardless of the data. Dual-bus comm-loss probability if each bus fails with p = 0.001? ::: p² = 10⁻⁶ (a 1000× improvement). Why is 208 μs the wrong number for worst-case nav-read latency? ::: It ignores retries; worst case (fail, fail, succeed) is 652 μs. A Bus Monitor sees a status word but no data words on a 4-word transmit — is the RT dead? ::: No — the status word proves it is alive; it correctly sent no data because its status flagged an error.

Recall Where this connects

Same differential trick, different goals ::: RS-485 Protocol, CAN Bus, ARINC 429. Why we lay messages on a fixed schedule ::: Time-Triggered Architectures, Real-Time Scheduling Theory. Why the encoding guarantees clock recovery ::: Manchester Encoding. The certification bar these reliability numbers must clear ::: DO-178C Certification.