Power, mass, link, timing. Four budgets that decide whether a system is physically possible. Fill them in honestly and you have a design. Skip them and you have a wishlist with a schedule attached.
The sensor stopped returning data at exactly the moment the radio keyed up. Everyone looked at the sensor driver, because the sensor was the thing that had stopped. A week went into the driver. The driver was fine. What had happened was simpler and older than software: the radio’s transmit burst pulled the rail down, the regulator could not keep up, and the sensor browned out for forty milliseconds while the radio talked. Nobody had written down what the system drew when everything was on at once, so nobody had noticed that it drew more than the source could give.
That is what a budget is for. Before architecture, before component selection, before any of the work people associate with the word “design,” there is a smaller, more important question: can this thing physically exist on the constraints we have? The four budgets in this chapter answer it. They are the difference between a project that can ship and a project that cannot, told in numbers.
A budget here is the same thing your bank account is: an accounting of what is coming in against what is going out, with margin telling you how much room you have before something breaks. For a satellite the accounts are power, mass, RF link, and CPU time. For an embedded sensor, usually the first and last. The unit changes; the discipline does not.
As a technical program manager I once tried to make the budgets a gate: no design review passes until throughput, latency, and power have numbers next to them. The engineers half-filled the sheets, then stopped. When I pushed, management told me to move on; it was a younger team, and the gate was slowing them down. The numbers I had put on the program myself went untested and undesigned-to, and the program found out what they should have been the way programs always do, at integration, with the customer watching.
The lesson. A budget nobody is required to fill in is a budget nobody fills in. The gate is the point. It feels slow for a week and saves a quarter.
If you cannot fill in the numbers in any of these budgets for your project, you have a plan that has yet to be checked against physics. Going further before checking is how teams build for six months on something that will never work, then start over.
What follows is one budget per section, each with the same shape: what it is, why it exists, what goes into it, a worked example, and what the numbers tell you. The figures are illustrative. Your project’s numbers will be different; the way you read them will be the same.
And the way you read every one of them is the same: find the margin, then place it on this scale.
Negativeredesign now
Under 20%thin, flag it
20% and uphealthy, room to be wrong
Margin is the most important number on the page. Below zero, the system cannot exist as drawn. Under twenty percent, one forgotten cable or one cold-start spike eats the rest. Twenty and up gives the design room to survive the deviations reality always brings.
Here is how the four worked examples in this chapter land on that scale, same reading, four different units:
PowerHealthy28% headroom
MassThin5% remaining
LinkAcceptable6 dB (3 / 6 / 10)
TimingHealthy33% of a 70% ceiling
Four budgets, one reading: find the margin, and below twenty percent the design is still a wish.
What it is. Every component consumes power. Every source has a limit. A power budget 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. The processor reboots when the 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 does not care that nobody checked.#
The mental model. 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. If the sum of continuous draws exceeds it, 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?#
The radio from the example below, over twenty seconds. The battery has to supply the average. The regulator and the wiring have to survive the peak. Both numbers belong in the budget.
Each component’s nominal, peak, and standby current, from the datasheet first and the bench second, because datasheets understate.
Duty cycle: the fraction of time each component spends in each mode. A 10 W radio that transmits 5% of the time costs 0.5 W on average and 10 W during transmit.
Source capacity: battery watt-hours, solar wattage at the real angles and degraded efficiency, wall power available.
Conversion losses. An 85%-efficient regulator turns 15% of what passes through it into heat.
Margin, because real components do not read their datasheets.
What this table tells you. Average demand is 10.8 watts against 15 watts of daylight solar. The difference, 4.2 watts, is about 28% headroom, and that is healthy. At 5% you would be one cable, one undocumented LED, one cold-start spike from a brownout. Negative means a system that physically cannot run on its source, and the right response is to redesign, with fewer components, lower duty cycles, or a bigger source, before any more work is done.#
How it fails. The most common mistake is missing components rather than bad math. A first pass always undercounts: the LEDs, the pull-up resistors, the leakage of a disconnected sensor, the heater that turns on below freezing, the bias current of an op-amp chain. Real systems eat 10 to 30% more than the first pass suggests, which is exactly why margin is non-negotiable. Revisit the budget every time the design changes, and watch the margin rather than the total.#
Eclipse periods, battery charging losses, degradation over time, thermal effects on efficiency, and fault scenarios: one solar panel fails, one regulator dies. Model worst case. The day your system needs the most power is the day it is also the coldest, the panel is dirty, and the battery has been cycled a hundred times.
The table below starts with the example above and recomputes as you change it. Type in your own components, duty cycles, and source, and read the margin off the gauge.
Component
Power (W)
Duty cycle (%)
Average (W)
5.20
1.28
1.53
2.10
0.70
Average total
10.81 W
Source available (W)
Margin
28%
Negativeredesign now
Under 20%thin, flag it
20% and uphealthy
28% margin. Healthy. The design has room to absorb the components the first pass forgot.
The battery pays the average and the regulator pays the peak; budget both, and expect the first pass to be 10 to 30% light.
What it is. The mass of every component, 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. Handheld products live or die on whether the user wants to hold them. Going over the allocation means the project stays on the ground, literally in some cases. 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 bring what fits, and the box left on the driveway is the feature you cut.#
The same table as a bar. The known subsystems fill 95% of the allocation; the healthy band for a design this early sits well to the left of where this one is.
What this table tells you. You are tracking 95% of your allocation across known subsystems, with 5% remaining. That is dangerous rather than safe. Real parts always weigh more than datasheets suggest. Industry practice for early-phase design is 20 to 30% margin precisely because the unknown unknowns at the start of a project are large. At 5% 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 is 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 firm: the comms team gets 1.2 kg, and if their antenna actually weighs 1.4, they cut something else rather than silently adding to the total.#
A typical aerospace assembly has hundreds to thousands of fasteners. At a few grams each, the total runs into kilograms. Almost no first-pass mass budget includes them, because nobody has the bill of materials yet. That oversight is fine if you carry 25% margin. It ends the project if you carry 5%.
Nobody has ever been surprised by how light the cable harness turned out to be.
Allocate mass to subsystems early, hold the allocations firm, and carry 20 to 30% for the fasteners and harness nobody has counted yet.
What it is. A signal-strength accounting that traces a transmitted signal through every loss between the transmitter and the receiver, then compares what arrives against the noise floor and the signal-to-noise ratio your demodulator needs. The output is a margin in decibels: how much headroom the 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 is indifferent to your effort. Free-space path loss grows with the square of distance and the square of frequency. Noise is set by temperature and bandwidth. Shannon caps how much information fits in a given bandwidth at a given SNR. A link budget tells you whether you have enough margin to absorb the bad days, rain, low elevation, pointing error, or whether the link will simply drop when conditions degrade.#
The mental model. Calling across a noisy room. Your voice has a level. The room takes some of it, absorbed by walls and masked by other conversations. The listener has a threshold. After all the losses, is what arrives strong enough to be understood above the background? That is a link budget, in dB.#
The example as a waterfall. Power climbs with the transmit antenna, falls off a cliff at the path loss, loses a little more to weather and pointing, climbs with the receive antenna, and lands 15.8 dB above the noise. Ten of those are spoken for; 5.8 are yours.
Parameter
Value
Notes
Transmit power
+30.0 dBm
1 watt output
Transmit antenna gain
+2.0 dBi
Omnidirectional dipole
Free-space path loss
-139.2 dB
500 km at 435 MHz
Atmosphere, polarization, pointing
-3.0 dB
Low elevation pass
Receive antenna gain
+15.0 dBi
Ground station Yagi
Received power
-95.2 dBm
Receiver noise floor
-111.0 dBm
kTB in 1 MHz, 3 dB noise figure
Required SNR
10.0 dB
For BER below 1 in a million
Link margin
5.8 dB
Acceptable
What this table tells you. Your signal arrives about 6 dB above what the receiver needs. That is acceptable for the conditions modeled, and far from generous. Read it like this: 3 dB means barely working, where one bad pass loses data. 6 dB is acceptable for most cases. 10 or more is comfortable. Negative means the link does not close, full stop. The number matters less than the question behind it: have I accounted for the things the model does not capture?#
How it fails. Link budgets fail in the assumptions rather than 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. Rain at the operating frequency can add 3 to 6 dB. Antenna gain is the boresight figure, and off-axis you have less. The discipline is to budget for the conditions you will actually operate in, and to add margin specifically for the things your model is silent about.#
3 dB means the link works on a good day and fails on a bad one. 6 dB means most days are good. 10 dB means you can take a hit and still make the link. Below 3 dB you have a hope rather than a link.
Enter a link and read the margin. Path loss uses the free-space formula with distance in kilometers and frequency in megahertz; put everything the free-space model leaves out, foliage, rain, multipath, pointing, cable loss, into the extra-losses line.
Free-space path loss
139.2 dB
Received power
-95.2 dBm
Noise floor
-111.0 dBm
SNR available
15.8 dB
Link margin
5.8 dB
5.8 dB of margin. Acceptable. Most days are good; budget specifically for the losses your model is silent about.
The arithmetic is easy and the assumptions are where links die; budget for the environment you will actually operate in, and read 3, 6, and 10 dB as barely, acceptable, and comfortable.
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 is supposed to run every 10 milliseconds must actually run every 10 milliseconds, every time, and an average is no comfort. Miss a deadline and you get unstable control loops, dropped data, missed sensor reads, and in safety-critical systems, dangerous behavior. 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 window, some flexible, some tight. The driver has eight hours. The question is whether every stop can be made and every window met. If the math says the route is 110% of the available time, a window will be missed. Which one depends on the order, but one will be missed.#
The five tasks from the table below, laid on a 100 millisecond timeline. Each bar is one run at its worst-case length, starting at its release tick. Stacked up, they keep the processor busy a third of the time.
Task
Period (ms)
WCET (ms)
Utilization
Attitude control
10
2.1
21.0%
Sensor reading
50
1.8
3.6%
Telemetry generation
1000
15.0
1.5%
Command handler
100
5.2
5.2%
Health monitor
500
8.0
1.6%
Total CPU utilization
33%
Target ceiling
70%
Headroom
37 points
What this table tells you. The processor spends 33% of its time on these tasks under worst-case execution. The target ceiling for a hard real-time system is around 70%, which is where rate-monotonic scheduling stops guaranteeing every deadline for a large task set (the exact bound for five tasks is 74%). You are carrying 37 points of headroom. That is comfortable: room for another task, an interrupt storm, a feature add. At 65% you would be one feature from a system that misses deadlines under load.#
How it fails. Timing budgets fail when WCET is wrong, and WCET is hard. It is the slowest the task can possibly be, with branches taken in their worst order, caches cold, interrupts firing, and a typical run tells you little about it. Most teams measure the average and multiply by some factor, which works until it does not. The other common failure is forgetting interrupt overhead, which can be 10 to 20% of the CPU on its own. The discipline is to measure WCET adversarially: construct the worst-case input on purpose, run with the cache flushed, fire every interrupt you can, and believe the number you get.#
A sample stream was underrunning a FIFO on the way to a DAC, and the first instinct in the room was that it could not be the software: the FIFO on the fabric side drained at 120 MHz, so surely there were microseconds of slack. The FIFO that mattered drained at the sample rate, 120 thousand samples a second, which gave the software 68 milliseconds of runway. Seemed like plenty. I wrote a small C tool to record the loop’s worst-case latency and let it run overnight, and it came back with spikes of 30 to 50 milliseconds, well inside the runway on paper and far too close for comfort in practice. The spikes lined up with a stall column in the trace, which pointed at scheduler jitter on the core and away from the DMA path everyone had been staring at. The fix was isolation and characterization, and the standard deviation of the jitter became the proof that the buffer would never underflow.
The lesson. The runway is only as long as the slowest drain, and the worst case only shows up if you leave the measurement running long enough to catch it. An afternoon’s numbers are an anecdote. Overnight is evidence.
Worst-case execution time is neither the average nor the 99th percentile. It is the slowest the task can possibly run, full stop. Add 20 to 30% on top for interrupt handling, context switches, and cache misses. Use rate-monotonic analysis or a similar schedulability check for hard real-time systems. “It worked when I measured it” is an anecdote, and a timing budget is a proof.
32.9% utilization against a 74.3% bound. Every deadline is guaranteed under rate-monotonic priorities, with room for the interrupt overhead the table leaves out.
The bound is the Liu and Layland limit, n(2^(1/n) - 1): 100% for one task, 83% for two, and down toward 69% as the task count grows. Utilization under the bound guarantees every deadline when priorities follow the periods, shortest period highest. Utilization above the bound is a maybe, and a maybe is a failed budget.
Measure the worst case on purpose and overnight, add 20 to 30% for interrupts, and stay under the 70% ceiling, because a deadline met on average is a deadline missed.
Every number in a first-pass budget is a guess dressed in datasheet clothing. The budget earns its authority when the guesses get replaced by measurements, one line at a time, and the discipline of measuring is cheap compared to the discipline of being wrong. A few habits cover most of it.
Average current and peak current are different measurements and need different instruments. For the average, put a logging meter or a coulomb-counting monitor in series with the battery and let it run for a representative duty cycle, overnight if the device sleeps most of the time. For the peaks, put a small sense resistor in the supply line and watch the voltage across it on an oscilloscope while the radio transmits or the motor starts; that is where brownouts are born, and the average hides them completely. Measure in the real operating mode, with the real firmware, at the real temperature if you can. A microcontroller that draws 15 microamps asleep on the evaluation board draws 300 when one pull-up was left floating on your board, and only the meter will tell you.
Weigh the assembly as it will fly, and weigh the harness separately. Cables and connectors are the line item that surprises every first-time mass budget, and they are also the easiest thing to put on a scale. Keep the measured number next to the estimated one in the spreadsheet; the gap between them is your calibration for every estimate still in the sheet.
Walk the link. Put the real transmitter at one end and a receiver that reports signal strength at the other, then move the receiver out in steps and log received power against distance, in the real environment, in the weather you will operate in. A dozen points plotted against the free-space line tell you the excess loss your environment actually imposes, which is the number the model could only guess at. Wet foliage, ground reflections, and a detuned antenna on a steel mast all show up in that plot, and the plot is what you take back to the budget.
Toggle a spare output pin at the start and end of the task and watch it on a scope or logic analyzer; the high time is the execution time, with no instrumentation overhead worth mentioning. Then make it worse on purpose: feed the longest input, take the rare branch, flush the cache, and fire every interrupt that can fire. The longest high time you can provoke is your working WCET. Count interrupts per second while you are there, since that overhead is the line most timing budgets forget.
Bench measurements are facts. Every budget should show both columns, and the discipline is to keep replacing the first with the second until the estimate column is empty.
Keep an estimate column and a measured column, and keep moving lines from the first to the second until the first is empty.
The sentinel’s geometry: nodes on the trunks relay an alert from one to the next, up to a gateway on the ridge tower, and on to the ranger post. Every number below comes from this picture.
The project summary for the forest sentinel made two promises and withheld a third. It promised a node that runs for a season on a cheap battery, it promised an alert that reaches the post, and it declined to promise that both could be true at once until someone measured. Here is the arithmetic behind that honesty, worked the way you would work it on a Tuesday afternoon with a datasheet and a spreadsheet.
Start from the source, because the source sets the allowance that everything else must fit inside.
Capacity. One 18650 lithium-ion cell, 3000 mAh at 3.6 V nominal: 10.8 Wh. Derate to 80% for cold mornings, self-discharge, and the cutoff voltage the regulator needs: 8.6 Wh usable.
Duration. A season is 180 days: 4320 hours.
Allowance. 8.6 Wh over 4320 h is 2.0 mW average, which at 3.6 V is 0.55 mA. Every consumer in the node shares that half-milliamp.
Now the consumers. The honest move at this stage is two columns, because the datasheet gives a range and the firmware has yet to be written. The optimistic column assumes everything goes as planned; the pessimistic column assumes the detector needs a faster clock and longer windows, and that this node also relays traffic for a neighbor.
Consumer
Assumption
Optimistic (mW)
Pessimistic (mW)
Sleep floor
MCU, radio, and regulator asleep: 15 to 40 uA
0.05
0.14
Listening
Microphone, ADC, and feature math; 1.5 mA at 10% duty, or 4 mA at 12%
0.54
1.73
Radio channel check
A 10 mA listen for 5 to 10 ms every 2 s, so a neighbor’s packet can wake it
0.09
0.18
Heartbeat and relaying
120 mA for 0.2 s every 10 min, alone or carrying three neighbors’ traffic too
0.14
0.58
Alerts
120 mA for 1.5 s per event; a dozen events a season rounds to zero
0.00
0.01
Average demand
0.82
2.64
Allowance
2.00
2.00
Margin
+59%
-32%
What the two columns say together. The spread runs from comfortably healthy to physically impossible, and the two lines that swing it are the listening draw and the relay traffic. That is the whole finding. The budget cannot yet say yes or no; what it can say, precisely, is which two numbers decide the answer. Those two numbers come from a bench and a forest, which is why the summary proposed a three-month research phase instead of a delivery date. A spreadsheet that tells you what to measure first has done its job.#
Notice, too, the lever each line exposes. Listening cost is duty cycle times active current, so shorter windows or a lighter detector pay directly. Relay cost is traffic times airtime, so a slower heartbeat or a shorter packet pays directly. The optimistic column is a design target; the pessimistic column is the risk register.
The summary said a single long-range hop straight to the post did not quite close, and that the near miss pointed at a mesh. Here is that link budget. The radio is a 915 MHz LoRa module at its slowest, most sensitive setting, where the datasheet promises -137 dBm sensitivity and a 20-byte alert takes about a second and a half of airtime.
Transmit side. +20 dBm from the module, +2 dBi from a quarter-wave whip on the trunk: +22 dBm leaving the node.
Free-space loss. The far corner of the preserve is 8 km from the post. At 915 MHz: 32.45 + 20 log(8) + 20 log(915) = 109.7 dB.
Excess loss. Both antennas sit under wet canopy, a couple of meters up a trunk, with a fold of terrain between them. The free-space model knows nothing about any of that. Measured forest paths at this frequency run 30 to 55 dB worse than free space; take 45 dB and write down that it is a guess to be walked.
Receive side. A +5 dBi antenna on a mast at the post.
Received power. 22 - 109.7 - 45 + 5 = -127.7 dBm.
Raw margin. -127.7 against a -137 dBm sensitivity: 9.3 dB.
Fade margin required. Wet-to-dry swings, seasonal growth, and an antenna detuned by a rain-soaked trunk: 15 dB is a sober allowance under canopy.
Path
Distance
Free-space
Excess
Received
Raw margin
After 15 dB fade
Node straight to the post
8.0 km
109.7 dB
45 dB
-127.7 dBm
9.3 dB
-5.7 dB
Node to node, mesh hop
1.5 km
95.2 dB
35 dB
-106.2 dBm
30.8 dB
+15.8 dB
Node to gateway on a 30 m tower
3.0 km
101.2 dB
20 dB
-94.2 dBm
42.8 dB
+27.8 dB
What the table tells you. The direct hop is short by about 6 dB once a realistic fade allowance is applied: close enough to be tempting and far enough to lose alerts on the wet nights when the chainsaws come. The mesh changes the geometry rather than the physics. Shorter hops cut the free-space term by 14 dB and the canopy term by 10, and lifting the gateway above the trees takes another 15 off the final hop. Every row in the mesh plan closes with room to spare. That is the whole reason the summary chose it.#
The reserve option. Dropping to 433 MHz cuts free-space loss by 6.5 dB and foliage loss by several more, which would likely turn the direct hop’s shortfall into a small positive margin. It stays in reserve because a small positive margin under canopy is still a thin one, and because the mesh buys coverage flexibility the direct link never will.#
The budgets talk to each other. The mesh that closes the link is the same mesh that puts relay traffic into the power budget’s pessimistic column. A decision in one sheet moved a number in the other. That is normal, it is why the budgets live in one workbook, and it is why the research phase measures range and relay power on the same nodes, in the same forest, in the same week.#
The sentinel’s budgets could not say yes or no, but they said exactly which two numbers decide it, and that is what a research phase is for.
Across all four budgets, the same patterns hold. The numbers will be wrong on the first pass; that is expected rather than 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 breaks the moment reality deviates from the model. A system designed to 70 or 80% survives the deviations.
If your margins are negative or you cannot fill in the numbers#
You have a wishlist. Go back to requirements and make hard trade-offs. Cut features, choose lower-power components, reduce data rates, simplify algorithms. Engineering is the discipline of satisfying constraints. The team that pushes through with negative margins is the team that ships late or never ships.
Open a spreadsheet and list every consumer in your current design, including the ones you are sure are negligible. Put a duty cycle next to each. Total it against the source and write the margin at the top of the sheet.
Pick the one line you are least sure of and measure it, with a meter, a scale, a walk, or a scope, before the end of the week. Replace the estimate and watch what the margin does.
If you have a radio in the design, run the link calculator above with your real distance and frequency, then add the extra losses you have been hoping were small. Write down the margin you would need to feel comfortable, and compare.
Keep the budgets alive, review them as a gate, and treat a negative margin as a message from physics rather than a problem for integration.
This chapter on one page
Each line is the sentence to remember from its section. The number takes you back to it.
2.1Four budgets, one reading: find the margin, and below twenty percent the design is still a wish.
2.2The battery pays the average and the regulator pays the peak; budget both, and expect the first pass to be 10 to 30% light.
2.3Allocate mass to subsystems early, hold the allocations firm, and carry 20 to 30% for the fasteners and harness nobody has counted yet.
2.4The arithmetic is easy and the assumptions are where links die; budget for the environment you will actually operate in, and read 3, 6, and 10 dB as barely, acceptable, and comfortable.
2.5Measure the worst case on purpose and overnight, add 20 to 30% for interrupts, and stay under the 70% ceiling, because a deadline met on average is a deadline missed.
2.6Keep an estimate column and a measured column, and keep moving lines from the first to the second until the first is empty.
2.7The sentinel’s budgets could not say yes or no, but they said exactly which two numbers decide it, and that is what a research phase is for.
2.8Keep the budgets alive, review them as a gate, and treat a negative margin as a message from physics rather than a problem for integration.