skip to content

How do you turn a channel capacity of 0.53 bits per use into a usable payload rate for a downlink?

level: middleimportance: should knowfreq 46%

answer

  1. capacity is per use, not per second
  2. one multiplication by the symbol rate
  3. the rate k/n is the lever
  4. sit strictly under the ceiling
  5. margin absorbs estimation error and short blocks

basics

~20 s

Multiply capacity by the number of channel uses per second to get the reliable bits-per-second ceiling, then pick a code rate k/n strictly under 0.53. Payload throughput is that rate times the symbol rate, with margin left for a worse-than-modelled channel.

solid answer

~40 s

Capacity is per channel use, so the first step is a units conversion: at ten million symbols per second, a capacity of 0.53 gives a ceiling of 5.3 megabits per second of payload. The second step is choosing a code rate `k / n` - payload symbols per transmitted symbol - strictly below 0.53, because the theorem's guarantee is asymptotic in block length and because 0.53 was computed from an *estimated* noise level. A rate-1/2 code gives 5 megabits per second of payload and spends the other half of every block on protection. What you do not do is size the code from the error rate you are seeing: the rate is the lever, and the distance between your rate and the ceiling is the margin.

code

pseudocode · 18 lines
pseudocode
function entropy_bits(p):
    return -p * log2(p) - (1 - p) * log2(1 - p)

p = 0.1                          # symbol-flip probability of the link
C = 1 - entropy_bits(p)          # 0.531 bits per channel use

k = 512                          # payload symbols per block
n = 1024                         # transmitted symbols per block
rate = k / n                     # 0.5

if rate < C:
    report "achievable: block error -> 0 as n grows"
else:
    report "impossible: block error stays bounded away from 0"

uses_per_second = 10000000
report "ceiling", C * uses_per_second        # 5.3 million bits per second
report "payload", rate * uses_per_second     # 5.0 million bits per second

go deeper

for a junior

Get the units right first: capacity is bits per symbol sent, so it becomes bits per second only after multiplying by how many symbols per second the link carries.

for a middle

Explain the code rate k/n as payload symbols per transmitted symbol, compare it with the ceiling, and show the payload arithmetic that follows from the choice.

for a senior

Argue for the margin: name the asymptotic guarantee, the estimated noise level and the burst shape as the three reasons you never operate at the computed number.

for a principal

Treat the gap between the rate and the ceiling as a budget line, traded against latency, decoder cost and the risk appetite for a channel that degrades below its model.

## From bits per use to bits per second Capacity is quoted **per channel use** - per symbol placed on the link - because that is the unit in which it is a property of the noise rather than of the hardware. Turning it into something a capacity plan can use takes one multiplication: - `reliable bits per second = C x channel uses per second` At 0.53 bits per use and ten million uses per second, the ceiling is **5.3 megabits per second** of payload. That figure is the most anybody could ever get across this link at vanishing error, using any code that exists or will ever be invented. ## Choosing the code rate A block code takes `k` payload symbols and emits `n` transmitted symbols. Its **rate** is `k / n`, and the comparison that matters is `k / n` against `C`: - `k / n` well under `C` - reliable codes exist and short blocks suffice, but payload throughput is left on the table. - `k / n` just under `C` - maximum payload, at the cost of long blocks, latency and a heavier decoder. - `k / n` above `C` - no code works at vanishing error, whatever the block length. A rate-1/2 code with `k = 512`, `n = 1024` sits at 0.5, comfortably under 0.531, and yields 5 megabits per second of payload out of the ten million symbols per second - with 512 symbols of every block buying the protection. ## Why you leave margin Engineers pick a rate strictly below the computed ceiling, not at it, for reasons that stack: 1. **The guarantee is asymptotic.** "Rate below capacity" is a statement about behaviour as blocks grow long. At a block length your latency budget actually allows, the achievable error at a given rate is worse than the asymptotic promise. 2. **The capacity number is an estimate.** It is computed from a modelled noise level. Weather, interference, ageing hardware and a mis-measured error probability all move the real ceiling down. 3. **The noise model may be the wrong shape.** A ceiling computed for independent symbol errors says nothing useful if the real impairment arrives in bursts. 4. **Adaptation needs headroom.** A link that measures its own conditions and steps its rate up and down needs somewhere to step. ## What the number does and does not include | Quantity | Inside the capacity figure? | Where it is accounted | |---|---|---| | Symbol errors from noise | Yes - it is what `C` is computed from | The ceiling itself | | Error-correction overhead | Yes - it is the gap between `k/n` and 1 | Your choice of code rate | | Framing, addressing and headers | No | Subtract separately from payload | | Retransmissions after failure | No | A protocol-level cost above the code | | Margin for a worse-than-modelled channel | No | Your chosen distance below `C` | The common sizing error is double-counting or under-counting this table. Subtracting "the errors" from the raw symbol rate - taking ten million symbols per second, calling 47% of them lost, and reporting 4.7 megabits - is wrong twice over: capacity is not a fraction of symbols destroyed, and the corruption is not a deletion you can simply subtract. Equally wrong is quoting 5.3 megabits as deliverable payload while forgetting that headers still have to fit inside it. ## The lever and the dial An interviewer often probes this by describing a link that is losing data and asking what you change. The clean answer separates two things: - **The ceiling** is a property of the channel. You move it only by changing the channel - more power, more bandwidth, a better antenna, a quieter environment. - **The operating point** is your code rate. You move it freely, and lowering it is the only encoder-side action that can restore reliability. That separation also tells you when to stop. If the rate is already well under the ceiling and errors persist, adding redundancy is not the fix: the model of the channel is wrong, or the impairment is bursty in a way the code was not built for, or the decoder is the weak part. Sizing a code is arithmetic against `C`; diagnosing a link that fails despite correct arithmetic is a different exercise.

  • Does the capacity figure already account for framing and header bytes?
    No. Capacity bounds reliable payload symbols against channel noise; it knows nothing about a protocol's headers, addressing or acknowledgements. Those come out of whatever the code delivers, so a link with a 5.3 megabit ceiling running a rate-1/2 code delivers 5 megabits of coded payload, and the protocol's own overhead is subtracted from that.
  • The link is running well under capacity and still losing data. What do you look at?
    Not the code rate. Either the capacity estimate is optimistic because the real noise is worse than modelled, or the impairment is bursty while the code assumed independent errors, or the decoder is weaker than the code permits. All three are diagnosed by measuring the channel, not by adding check symbols.

saying these in an interview costs you the question

  • Quotes capacity in bits per second without a symbol rate
  • Subtracts the error rate from the raw symbol rate
  • Picks a code rate exactly equal to the computed capacity
  • Counts protocol headers as part of the coding overhead
  • Sizes redundancy from observed errors rather than from the rate