Fundamentals.

If you can’t quantify these, restart.

Engineering starts with feasibility. Before architecture, before component selection, before any of the work people associate with the word “design,” there’s a smaller, more important question: can this thing physically exist on the constraints we have? The four budgets in this chapter — power, mass, link, timing — answer that question. They are not paperwork. They are the difference between a project that can ship and a project that cannot, told in numbers.

A budget in this context is the same thing your bank account is: an accounting of what is coming in versus what is going out, with margin telling you how much room you have before something breaks. For a satellite the bank account is power, mass, RF link, and CPU time. For an embedded sensor it is likely the first and last. For aerospace, all four. The unit changes; the discipline does not.

What follows is one budget per section. Each has the same shape: what it is, why it exists, what goes into it, a worked example, and what the numbers tell you. The figures in the examples are illustrative — your project’s numbers will be different, but the way you read them will not.

Power budget.

What it is. Every component in your system consumes power. Every source of power has a limit. A power budget is a spreadsheet that lists every consumer and every source, accounts for the duty cycle of each, and tells you whether the system can run on the source under worst-case combined load.

Why it exists. Power is the most common silent killer of new designs. Hardware that “should be fine” browns out under transmit load. A perfectly-functioning sensor stops returning data when the radio fires because the regulator can’t keep up. The processor reboots when motors actuate. None of these are bugs in the traditional sense — they are symptoms of a missing budget. The system was never proven to fit, and physics doesn’t care that nobody checked.

The mental model. Imagine a household electrical panel. Every appliance has a continuous draw and a peak draw — the moment the compressor kicks in, the moment the printer warms up. The panel has a total capacity and a per-circuit capacity. If the sum of continuous draws exceeds the panel’s continuous capacity, the breaker trips eventually. If the peak combinations exceed it, the breaker trips immediately. A power budget is the spreadsheet version of asking: are we going to trip the breaker?

What goes into it. Every component’s nominal current draw, peak current draw, and standby current — pulled first from the datasheet, then verified on the bench, because datasheets often understate. Duty cycle, the fraction of time each component spends in each operating mode, because a 10W radio that transmits 5% of the time costs 0.5W on average but spikes to 10W during transmit. Average power and peak power calculated from those two. Source capacity — battery watt-hours, solar wattage at expected angles and degraded efficiency, wall power available. Conversion losses, because every regulator loses some fraction; an 85%-efficient buck regulator means 15% of the power going through it becomes heat. And margin — the gap between what you need and what you have, because real components don’t read their datasheets.

Worked example.

What this table tells you. Average demand is 10.8 watts. Solar generation under daylight is 15 watts. The difference, 4.2 watts, is your margin — about 28% headroom. That is healthy. If the number had come back at 5%, you would be one cable, one undocumented LED, one cold-start current spike from a brownout. If it had come back negative, you would have a system that physically cannot run on its source, and the right response is to redesign — fewer components, lower duty cycles, a bigger source — before any more work is done.

How it fails. The most common mistake isn’t bad math. It is missing components. A first-pass power budget always undercounts: people forget the LEDs, the pull-up resistors, the leakage current of a disconnected sensor, the heater that turns on below freezing, the bias current of an op-amp chain. Real systems eat 10–30% more than the first pass suggests, which is exactly why margin is non-negotiable. The discipline is to revisit the budget every time the design changes — every component swap, every feature add — and watch the margin, not the total.

Mass budget.

What it is. The total mass of every component in the system, summed and compared against whatever platform-level limit you have to live within — the launcher’s maximum payload, the airframe’s capacity, the drone’s lift envelope, the handheld product’s ergonomic ceiling.

Why it exists. Launch costs scale with mass. Flight dynamics depend on mass and where it sits. Airframes have center-of-gravity windows that aren’t negotiable. Handheld products live or die on whether the user wants to hold them. Going over your mass allocation in any of these contexts means the project doesn’t fly — literally, in some cases. Mass is the constraint that turns engineering into a constant negotiation, because once you commit to a launcher or an airframe, the number is set in stone and everything else flexes around it.

The mental model. A car packed for a long road trip. Every bag has a weight. The trunk has a limit. You can’t bring everything you want; you bring what fits. The mass budget tells you what fits.

What goes into it. Every subsystem’s mass — from CAD if you have it, from datasheets if you don’t, from a kitchen scale if you must. Structural mass: the chassis, the brackets, the standoffs. The fasteners (every screw is real grams; a typical assembly has hundreds). Cables, connectors, harnessing — these almost always come in heavier than people estimate. Thermal interface material, potting compound, conformal coating — nonzero. Margin, because the integration team will discover at least three things you didn’t account for.

Worked example.

What this table tells you. You’re tracking 95% of your mass allocation across known subsystems, with 5% margin remaining. That is dangerous, not safe. Real parts always weigh more than datasheets suggest. Fasteners, cables, connectors, potting compound, thermal paste — all add up. Industry standard for early-phase design is 20–30% margin precisely because the unknown unknowns at the start of a project are not small. At 5% margin you are one heavy cable harness away from a launch slip.

How it fails. Mass budgets fail by accumulation. No single decision blows it — it’s the cumulative effect of fifty small “just a few extra grams” choices that nobody pushed back on. The discipline is to allocate mass to subsystems early and treat those allocations as inviolable: the comms team gets 1.2 kg, and if their antenna actually weighs 1.4, they cut something else, they don’t silently add to the total. Without subsystem allocations, the budget becomes a free-for-all, and the first-pass total is always wrong by ten percent or more.

Link budget.

What it is. A signal-strength accounting that traces a transmitted signal through every loss it encounters between the transmitter and the receiver, comparing the final received power against the noise floor and the SNR your demodulator needs to actually decode the data. The output is a margin in decibels — how much headroom your communications link has under worst-case conditions.

Why it exists. You can build perfect hardware on both ends and still fail to communicate, because radio links are governed by physics that doesn’t care about your effort. Free-space path loss grows with the square of distance and with the square of frequency. Atmospheric attenuation eats more signal at low elevation angles. Noise is non-negotiable. Shannon’s limit caps how much information you can push through a given bandwidth at a given SNR. A link budget is what tells you whether you have enough margin to absorb the bad days — rain, low elevation passes, antenna pointing errors — or whether the link will simply drop when conditions degrade.

The mental model. Yelling across a noisy room. Your voice has a level. The room takes some of it — absorbed by walls, masked by other conversations. The listener has a sensitivity threshold. The question is: after all the losses, is what arrives at the listener’s ears strong enough to be understood above the background? That’s a link budget, in dB.

What goes into it. Transmitter output power. Transmit antenna gain. Free-space path loss for the geometry you actually fly. Atmospheric loss at the operating frequency and the worst-case elevation angle. Receive antenna gain. Receiver noise floor, calculated from kTB plus the receiver’s own noise figure. The required signal-to-noise ratio for the modulation you’re using and the bit-error-rate you’ll accept. Margin — for fading, multipath, Doppler shift, pointing error, and the things you didn’t think of.

Worked example.

What this table tells you. Your signal arrives at the ground station 6 dB above what your receiver needs to demodulate cleanly. That is acceptable for the conditions modeled, but not generous. Read it like this: 3 dB of margin means barely working — one bad pass and you lose data. 6 dB is acceptable for most cases. 10 or more is comfortable. Negative margin means the link does not close, full stop, and you redesign. The number itself is less important than the question: have I accounted for the things the model doesn’t capture?

How it fails. Link budgets fail in the assumptions, not the arithmetic. Free-space path loss is fine if you actually have free space; in a city, multipath and ground reflection eat several dB more. Atmospheric loss in the worked example assumes clear weather; rain at the operating frequency can add another 3–6 dB. Antenna gain is the boresight gain — off-axis, you have several dB less. Pointing errors during a satellite pass are real. The discipline is to budget for the conditions you will actually operate in, not the textbook conditions you wish you had, and to add margin specifically for the things your model is silent about.

Timing budget.

What it is. An accounting of how much CPU time each task consumes, how often each task runs, and whether the processor can keep up with all of them under worst-case combined load while still meeting each task’s deadline.

Why it exists. Real-time systems have hard deadlines. A control loop that’s supposed to run every 10 milliseconds must actually run every 10 milliseconds — not on average, every time. Miss a deadline and you get unstable control loops, dropped data, missed sensor reads, and in safety-critical systems, dangerous behavior. Soft real-time systems are forgiving; hard real-time systems are not. A timing budget proves the processor can meet every deadline before you commit to the architecture.

The mental model. A delivery driver with a route. Each stop has a delivery window — some are flexible, some are tight. The driver has eight hours. The question isn’t whether they can do every stop — the question is whether they can do them all and meet every window. If the math says the route is 110% of the available time, they will miss something. Which window they miss depends on the order, but they will miss one.

What goes into it. Each task’s worst-case execution time — not average, not typical, but the slowest the task can be under maximum load with all branches taken and all cache cold. Each task’s period (how often it must run) and deadline (how soon after it’s released it must complete). Interrupt-handling overhead, because interrupts steal CPU from whatever was running. Context-switch costs, including cache and TLB effects. Margin, because nobody’s WCET measurement is exhaustive on the first pass.

Worked example.

What this table tells you. The processor spends 33% of its time on these tasks under worst-case execution. Your target ceiling for a real-time system is 70% (above which scheduling guarantees start to break down even with rate-monotonic analysis). You’re carrying 37 percentage points of headroom. That is comfortable. It tells you the system has room for an additional task, an interrupt storm, a feature add, without falling off the cliff. If your number had come back at 65%, you’d be one feature from a system that misses deadlines under load.

How it fails. Timing budgets fail when WCET is wrong. WCET is hard. It’s not what you measure on a typical run — it’s the slowest the task can possibly be, with branches taken in their worst order, with caches cold, with interrupts firing. Most teams measure average and multiply by some factor, which works until it doesn’t. The other common failure is forgetting interrupt overhead, which can easily be 10–20% of CPU on its own and gets stolen from whatever task was running. The discipline is to measure WCET adversarially: deliberately construct the worst-case input, run with the cache flushed, fire all the interrupts you can, and watch the number you get.

The reality check.

Across all four budgets, the same patterns hold. The numbers will be wrong on the first pass — that’s expected, not a sign of failure. What matters is that you have the budget at all, that you maintain it as the design changes, and that you treat the margin as the most important number on the page. A system designed to 100% utilization is a system that breaks the moment reality deviates from the model. A system designed to 70–80% utilization survives the deviations.

How to maintain budgets.

The budgets aren’t one-time documents. They are living spreadsheets, updated continuously as the design evolves. The discipline is mechanical:

• Create the spreadsheets on day one, before any hardware decisions are locked in.
• Update the budgets every time a requirement or design choice changes.
• Review the budgets in every design review meeting — not as a status item, but as a gate.
• Track allocations to subsystems, not just totals. Subsystem budgets prevent local overruns from becoming project overruns.
• Measure actual values when hardware exists, and update the model. Datasheet values are estimates; bench measurements are facts.
• Maintain margin. Never design to 100% utilization, because real systems don’t read their datasheets.
• Document assumptions explicitly — temperature, efficiency, degradation over time, fault scenarios — so future-you knows what model you were working in.