Why Revision B Is Not Failure: Turning PCB Bugs into Better Hardware
Series navigation: Episode 1: The Roadmap · Episode 7: Reading Arduino Pin-Current Specifications · Episode 16
The problem: A wire patch makes Revision A work, but the next board may repeat the same mistake.
The goal: Convert symptoms and workarounds into traced design changes and regression tests.
The result: A Revision B process that preserves evidence instead of hiding failure.
AI-generated illustration of hardware iteration. The boards and defect notes are not artifacts from a physical project.
The wire patch worked—so was the board fixed?
Revision A would not start reliably. A wire was added, one resistor changed, and the board began working.
That is a valuable diagnostic result, but it is not yet a controlled design revision. The patch may create a new antenna, bypass protection, depend on assembly skill, or fix only the one unit on the desk.
In software, a quick production patch should eventually become a reviewed source change and regression test. Hardware needs the same discipline, except another PCB order makes forgotten assumptions slower and more expensive.
Revision B is not evidence that engineering failed. It is evidence that learning reached the design files.
Preserve Revision A before changing it
Archive:
- schematic, PCB, libraries, and generated manufacturing files;
- BOM and approved substitutions;
- firmware revision and configuration;
- board serial number or unique identifier;
- assembly photos and rework map;
- measurement captures and instrument settings;
- test procedure and environment;
- known defects and unresolved questions.
Without that baseline, comparing A and B becomes a memory exercise.
Write symptoms before causes
Start with what was observed:
Symptom: board resets when the motor starts.
Condition: motor connected, 60% PWM command, USB power present.
Evidence: 3.3 V rail dips during startup; reset line follows.
Reproduction: 5 of 5 starts on board A-003.
Do not begin with “the capacitor is too small.” That is a hypothesis.
List competing explanations: supply current limit, connector resistance, ground path, regulator transient response, missing local capacitance, motor suppression, firmware reset configuration, or measurement setup. Design a test that distinguishes them.
A workaround is an experiment
A bodge wire, resistor swap, added capacitor, cut trace, or firmware delay changes the system. Treat it as a controlled experiment:
- photograph and label the change;
- change one variable where possible;
- predict the result before testing;
- repeat the original failure condition;
- check side effects and temperature;
- remove the workaround to see whether the failure returns.
If adding capacitance appears to fix resets, verify that the rail waveform changes as predicted. Otherwise coincidence may become a permanent design rule.
Build a change table
| ID | Revision A evidence | Root cause | Revision B change | Verification |
|---|---|---|---|---|
| PWR-01 | Rail dips during load step | To be confirmed | Do not release change yet | Reproduce and isolate first |
| CON-01 | Connector can be reversed | Unkeyed interface | Add keyed connector and pin-1 marking | Mate real cable and inspect 1:1 print |
| TEST-01 | Reset node inaccessible | Missing test point | Add labeled reset test point | Probe with enclosure constraints |
The first row demonstrates an important rule: not every symptom is ready to become copper. If the root cause remains uncertain, keep investigating or design a safe experiment into the next prototype.
Update every dependent artifact
A component change may require more than replacing one symbol:
- requirement and calculation;
- schematic value and part number;
- footprint and courtyard;
- PCB placement and routing;
- BOM and approved alternatives;
- firmware pin, threshold, or timing;
- assembly instructions;
- test limits and procedure;
- enclosure or cable drawing;
- user-facing specification.
Trace each change through those dependencies. A new connector footprint with an old cable drawing is still a broken system.
Review the change, then review the whole board
Diff tools help locate edited nets, components, tracks, and files. Review the local change first, then rerun the full release process:
- ERC and DRC;
- footprint and polarity checks;
- power and thermal calculations;
- mechanical and enclosure checks;
- manufacturing-file inspection;
- independent design review;
- updated bring-up and regression plan.
A small fix can move a component into a keep-out, break a return path, change an address, or remove probe access elsewhere.
Regression tests belong in hardware too
Revision B must prove two things:
- the original defect is fixed under the original and worst-case conditions;
- behaviours that passed on Revision A still pass.
Useful test categories include power-up and brownout, idle and peak current, thermal limits, communications, sensor ranges, load startup and stall, reset recovery, firmware update, connector misuse, and long-duration operation.
Record pass criteria before seeing the result. “It works now” is not a measurable acceptance criterion.
Release notes for a physical product
Create a concise revision note:
Revision: B
Reason: resolve verified Revision A defects and improve test access
Changes: linked change IDs and affected artifacts
Compatibility: firmware, cables, enclosure, manufacturing process
Verification: test report and unresolved risks
Rollback: retained Revision A package and known-good units
Mark the physical PCB revision in copper or silkscreen so a photograph, returned unit, and test log can be tied to the correct files.
Completion checklist
- [ ] Revision A files and evidence are immutable and identifiable.
- [ ] Symptoms are recorded separately from hypotheses.
- [ ] Workarounds are controlled, reversible experiments.
- [ ] Every change links evidence, root cause, implementation, and test.
- [ ] Dependent firmware, BOM, mechanical, and test artifacts are updated.
- [ ] Full-board checks are rerun after local edits.
- [ ] Regression tests cover old functions as well as the repaired defect.
- [ ] The physical board clearly identifies its revision.
- [ ] Unresolved risks remain visible in the release record.
What comes after Revision B?
The next phase combines these skills into a small product: requirements, sensing, power, firmware, schematic, PCB, bring-up, enclosure, and verification. AI can accelerate explanations and drafts, but measurements and accountable engineering decisions remain the evidence.
Comments
Post a Comment