Reference

How to use this page#

The other chapters teach principles. This one collects the lookups, formulas, checklists, and decision frameworks you reach for under time pressure. Each entry is short on purpose. If you want the full teaching, follow the links into the relevant chapter. If you just need to remember whether kTB is in dBm or watts, or how to compute a Doppler shift for a low-Earth-orbit pass, this page is where the answer lives.

Where do I find…#

The questions readers come back for, each linked to the paragraph that answers it rather than the chapter that contains it. The Find box in the contents panel does the same job for anything missing from this list.

Project red flags#

Patterns that show up reliably in projects that are about to slip, fail acceptance, or ship something the customer never wanted. None of these are proof of trouble on their own. Two or three together, especially across categories, is signal worth acting on.

Troubleshooting checklist#

When something fails, the temptation is to start with the most interesting hypothesis: the bug must be in the new code, in the protocol, in the architecture. Most of the time the bug is in something boring. The discipline is to check the boring things first, in order, before reaching for the interesting ones. The list is roughly ordered from cheapest to most expensive to check, and from most likely to least likely as a root cause. Problem solving is the full method.

Layer 0: is it actually broken?#

• Did you check the right device? Wrong board, wrong port, wrong terminal: very common.
• Is the symptom new, or did you just notice it?
• Can you reproduce it deliberately, or is it intermittent?
• What changed since it last worked?

Layer 1: power#

• Is it plugged in? Is the supply on? Is the LED lit?
• Measure voltage at the input. Is it the rated voltage?
• Measure voltage at the load. Did it sag under load?
• Check current draw. Is the regulator current-limiting?
• Check the fuse, the protection diode, the polarity.

Layer 2: signal integrity#

• Put a scope on the signal. Does it look clean?
• Check rise and fall times at the load against the receiver’s tolerance.
• Look for ringing, overshoot, undershoot, reflections.
• Verify termination on transmission lines: 50, 75, 100 ohms differential.
• Check for ground bounce, common-mode noise, ground loops.

Layer 3: cabling and connectors#

• Is the cable seated all the way? Connector locked?
• Continuity-test the cable end to end with a multimeter.
• Check for bent pins, damaged shielding, contamination.
• Swap cables. Cables are unreliable for the same reason fasteners are: they are cheap, they are moved often, and they fail silently.

Layer 4: protocol and framing#

• Capture the protocol: logic analyzer for digital, scope for analog, sniffer for network.
• Are bits being transmitted at all? At the right rate? With the right framing?
• Check addresses, IDs, framing markers, checksums, CRC.
• Verify endianness on both sides. Surprisingly common, surprisingly slow to find.
• Check timing: setup time, hold time, propagation delays. Logic analyzer in timing mode.

Layer 5: software state#

• Is the device in the state you think it is in?
• Initialization sequence: did every step succeed? Many drivers fail silently in init.
• Is an interrupt enabled? Masked? Stuck?
• Is the buffer overflowing? Underflowing? Wrapping?
• Check for race conditions, especially at startup or under load.

Layer 6: configuration#

• Are you running the version of code you think you are? See configuration management.
• Is the configuration file the one in source control, or the modified one on the test fixture?
• Build flags, defines, optimization levels: same as the last successful build?
• Has someone “helpfully” updated firmware on the test setup without telling anyone?

Common debug mistakes#

Margin thresholds at a glance#

The numbers the guide uses when it says “healthy” or “thin,” in one place. They are rules of thumb for early-phase design; a specific program may set its own, and the written ones win.

Formulas worth knowing#

The handful of formulas below come up often enough in everyday engineering that having them memorized, or at least bookmarked, saves real time. Each is paired with the situation where you reach for it. None of them substitute for understanding the underlying physics; they exist to remind you what you already know.

Decibels#

Power and electrical#

RF and link budgets#

Signals and data#

Real-time scheduling#

Reliability#

Decision framework: when to act#

When a project shows red flags, the question is what action the severity warrants, since the answer to “is this bad” is usually yes. The matrix below maps observed signals to action levels. The levels are deliberately tiered: treating every problem as a fire drains the meaning out of the response.

Project kickoff checklist#

Before any project kicks off, the answers to a small set of questions need to be in writing: in a document, rather than in someone’s head or a hallway conversation. Each of these is cheap to answer at the start and expensive to answer later, when the project is in motion and the answer matters.

Code review checklist#

A peer review by someone who understands the problem domain catches different things than a peer review by someone who only knows the language. The checklist below is a starting point, ordered roughly by impact: correctness first, design second, testing third. A review that surfaces only items from the third category and never the first is a signal to reach for reviewers with more domain context.

Common-sense checks#

Before any number you compute leaves your spreadsheet, run it past four quick filters that catch the order-of-magnitude errors subtle algebra misses. The answer that is off by a thousand will pass every formal check and fail every common-sense one.

Order of magnitude.

Does the answer make sense in human-scale units? A satellite with a 10 kilowatt continuous draw is wrong. A 50-meter-long handheld antenna is wrong. A controller running at 100 GHz on a board that costs $20 is wrong. If your answer would surprise an experienced colleague at a glance, the answer is wrong before the colleague checks the math.

Units.

Are the units consistent through the calculation? Most catastrophic errors come from mixing units: meters with feet, dB with linear ratios, watts with volts. The Mars Climate Orbiter was lost to this exact mistake. Annotate every variable with its unit and cancel the units symbolically along with the numbers.

Sign and direction.

A power that came out negative, a velocity in the wrong direction, a phase that went the opposite way: these are usually setup errors rather than results. Check the sign on the way out, along with the magnitude.

Limits.

What does the formula predict at the extremes, at zero, at infinity, at the boundary cases? If the answer at zero or infinity is nonsensical, the formula or the model is wrong somewhere. The limits are cheap sanity checks that catch errors the middle range hides.

The sentinel at a glance#

The forest sentinel runs through the whole guide. Every artifact it produces is listed here, in the order a project would produce them, with a link to the chapter that builds it.

Useful acronyms#

Engineering documents are dense with abbreviations. The list below covers the ones most likely to show up in mixed-discipline conversations, with a one-line note on what each actually means in practice.