Reference.

How to use this page.

This is the chapter to bookmark. The other chapters teach principles. This one collects the lookups, formulas, checklists, and decision frameworks you reach for under time pressure — the things you skim when you need an answer faster than you need an explanation.

Each entry here 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.

Project red flags.

Patterns that show up reliably in projects that are about to slip, fail acceptance, or ship something the customer didn’t actually want. 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 doesn’t work, 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 below is roughly ordered from cheapest to most expensive to check, and from most-likely to least-likely as a root cause. It is intentionally beginner-friendly at the top — the experienced engineer skims it, the new engineer learns to skim it, and both benefit from the discipline of not skipping ahead.

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 — are they within the receiver’s tolerance?
• Look for ringing, overshoot, undershoot, reflections.
• Verify termination on transmission lines (50Ω, 75Ω, 100Ω 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’re cheap, they’re 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 with timing mode.

Layer 5: Software state.

• Is the device in the state you think it’s in?
• Initialization sequence: did every step succeed? Many drivers fail silently in init.
• Is an interrupt enabled? Masked? Stuck?
• Is the buffer overflowing? Underflowing? Wraparound?
• 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 last successful build?
• Has someone “helpfully” updated firmware on the test setup without telling anyone?

Common debug mistakes.

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.

Power and electrical.

RF and link budgets.

Signals and data.

Reliability.

Decision framework: when to act.

When a project shows red flags, the question isn’t “is this bad” (it usually is) but “what action does the severity warrant?” The matrix below maps observed signals to action levels. The action levels are deliberately tiered — not every problem is a fire, and treating everything 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 — not in someone’s head, not in a hallway conversation, in writing. 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, not to give up on reviews.

Common-sense checks.

Before any number you compute leaves your spreadsheet, run it past three quick filters that catch the order-of-magnitude errors that subtle algebra misses. The answer that’s off by 1000× 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. Cancel the units symbolically along with the numbers. If the answer should be in seconds and the units don’t cancel to seconds, the answer is wrong.

Sign and direction.

Is the sign right? A power that came out negative, a velocity in the wrong direction, a phase that went the opposite way — these are usually setup errors, not real results. Check the sign on the way out, not just 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.

Useful acronyms.

Engineering documents are dense with abbreviations. The list below covers the ones most likely to show up in mixed-discipline conversations — not exhaustive, but enough to follow most engineering meetings without having to ask. Each entry has a one-line note on what it actually means in practice, not just what it stands for.