Prototyping · Study deck

Hardware Prototyping Case Studies

A case study is not a success story to imitate.

Voltage Vera is your guide for this deck.

casestudies

Voltage Vera, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: Decision: The team keeps the same controller but revises the wake sequence, adds a sensor-ready check, moves strain relief, and records the field condition that must be checked again before handoff.
Explain: If the supply -- a marginal LDO, a coin cell, a thin USB cable, or long thin PCB traces -- cannot deliver that surge fast enough, the local 3.3 V rail sags.
Explain: A classic prototyping case: an ESP32 sensor node runs perfectly on the bench, but every time it connects to Wi-Fi it resets -- sometimes looping forever at the join step.

An electrolytic capacitor like this is the "bulk capacitor" this section sizes: the worked example calls for 47-100 uF placed close to the module's power pin so it can supply the 300 mA surge for the 10 us the regulator needs to catch up, without letting the rail droop more than 0.1 V. Photo: Evan-Amos, Public domain

Major section

ESP32 Wi-Fi Reboot Case · Measure Before Code Changes

A classic prototyping case: an ESP32 sensor node runs perfectly on the bench, but every time it connects to Wi-Fi it resets -- sometimes looping forever at the join step.

The instinct is to blame the code, and hours vanish adding delays and rewriting the network logic.

A useful hardware case study keeps the symptom, evidence, revision, verification, and next gate visible instead of jumping straight from failure to fix.

Major section

Measure Current Surge and Rail · Size the Bulk Capacitor

If the supply -- a marginal LDO, a coin cell, a thin USB cable, or long thin PCB traces -- cannot deliver that surge fast enough, the local 3.3 V rail sags.

In this case the question is whether the rail sags toward the stated brownout threshold during radio activity.

An oscilloscope like this is what this section puts directly on the 3V3 pin: triggered on the reset or EN line, it is what shows the rail sagging toward the ESP32's 2.7 V brownout threshold during the 300-500 mA Wi-Fi TX surge -- the single measurement that ends the guessing. Photo: BekundaOff, CC BY 4.0

Major section

Read Case Studies as Evidence · Evidence Timeline

It should show what the team believed, what they built, what failed, what they measured, what changed, and how the change was verified.

A timeline makes it harder to skip from "it failed" to "we know why" without measurement.
That order lets a later reviewer see which observation justified the fix.

Major section

Incremental Examples

Situation: A battery-powered environmental node reads multiple sensors and reports periodically.

The proof board works on the bench, but field tests show missing reports and inconsistent readings.
Reports arrive in clusters instead of at the expected interval.
A case study should not blame a sensor until wake timing, supply stability, bus behavior, and installation details are checked.

Major section

Incremental Examples (continued)

Decision: The team keeps the same controller but revises the wake sequence, adds a sensor-ready check, moves strain relief, and records the field condition that must be checked again before handoff.

The actuator works in isolation, but the controller resets during real load switching.
The symptom is specific: the actuator works alone, but the controller resets when the real load switches.
A command or actuator capture can show whether the control signal changed before or after the reset.

Real photograph of electrolytic capacitor

Major section

Incremental Examples (continued)

That single "active low" line in the reference code was easy to miss and explained the backwards-looking fan behavior long before any wiring was actually wrong.

Reproduce that mode with the smallest setup, then check the power rail and return path while switching occurs.
The flow makes the proposed fix answer the observed failure instead of a general hardware guess.
Electrical proof then records power modes, peak loads, reset behavior, timing, and noise-sensitive readings.

Major section

Incremental Examples (continued)

The team then extended the same node so its readings also went out over the network to a second machine, where they were logged and plotted live instead of only driving the local relay.

A dropped periodic reading was cheap to lose; a stalled TCP connection on a headless sensor node was not something worth recovering from in the field.
Once telemetry is added, a flat reading is ambiguous on its own: pair it with the sensor's known resolution before calling it a fault.
The first-board plan adds test points, programming access, inspection, smoke tests, and rollback.

Major section

Incremental Examples (continued)

The right question is not "Can we make it smaller?" The right question is "Are the interfaces stable enough to commit to layout?".

If those records are missing or still changing, the route returns to an integration prototype or schematic review.
Stable behavior: The required sensing, actuation, communication, sleep, reset, and safe-output behavior are proven.
Stable interfaces: Pin map, bus addresses, connector plan, voltage levels, placement, and service access are not still changing.

PCB readiness depends on stable behavior, interfaces, electrical proof, and a testable first-board plan.

Major section

Incremental Examples (continued)

Decision: If those records are missing, the next revision should be an integration prototype or schematic review, not layout release.

Situation: A prototype works in the lab and is ready for a small field trial.
The risk moves from "Can it function?" to "Can it be installed, serviced, diagnosed, and recovered?".
Decision: A field test is ready only if someone other than the original builder can follow the record.

Major section

Decision Matrix · Case Study Record Template

Missing reports call for a wake log, power trace, and communication log before changing retry behavior.

Noisy readings instead need an analog capture, placement photo, and grounding check; a reset under load needs a rail and reset capture at the load start.
An enclosure-only fault needs a test with the enclosure closed.

Major section

Common Failure Patterns

Guessed root cause: The team changes a part before reproducing the symptom or measuring the failing mode.

Numbers without context: Measurements are listed without setup, operating mode, firmware version, or acceptance rule.
Late field reality: Cable strain, installation, enclosure, temperature, moisture, service access, or user handling appears after the lab build is declared complete.
No rejected causes: The record does not explain what alternatives were checked and ruled out.

Deck summary

Key takeaways

A classic prototyping case: an ESP32 sensor node runs perfectly on the bench, but every time it connects to Wi-Fi it resets -- sometimes looping forever at the join step.

If the supply -- a marginal LDO, a coin cell, a thin USB cable, or long thin PCB traces -- cannot deliver that surge fast enough, the local 3.3 V rail sags.
It should show what the team believed, what they built, what failed, what they measured, what changed, and how the change was verified.
Situation: A battery-powered environmental node reads multiple sensors and reports periodically.

Retrieval practice

Recall check 1 of 5

Voltage Vera says: answer from memory, then check your reasoning.

Q1A radio reset is blamed on the controller board. How should the team compare a regulator fix and a board swap?

AChoose the new board for its features without reproducing the reset or comparing rail traces.

BTest both against the same fault, rail trace, reset log, requirement, and remaining risk.

CChoose the regulator before repeating the fault and assume the controller's residual risk is gone.

DIgnore the old rail trace after either change, using feature count as the new acceptance evidence.

Show answer

Answer: B Comparable measurements distinguish a real fix from a guess.

Retrieval practice

Recall check 2 of 5

Voltage Vera says: answer from memory, then check your reasoning.

Q2An ESP32 resets every time it connects to Wi-Fi. What should you suspect first?

AA logic fault after association that triggers resets when the first data packet is sent.

BA supply brownout as radio current surges and the rail drops below reset threshold.

CAn access point rejecting Wi-Fi association before the radio joins the network.

DCorrupt flash contents causing resets only during the Wi-Fi connection step.

Show answer

Answer: B A reset tied to radio activity makes the power rail the first suspect; confirm it with a rail trace and reset log.

Retrieval practice

Recall check 3 of 5

Voltage Vera says: answer from memory, then check your reasoning.

Q3What is the best way to confirm a suspected Wi-Fi brownout on an ESP32 prototype?

AAdd delays to connection code repeatedly and judge brownout by whether resets stop.

BSwap Wi-Fi libraries and infer a supply problem if the new library connects.

CScope the 3.3 V rail during connection and check whether radio bursts cross the reset threshold.

DReplace the ESP32 because a faulty controller explains the reset during radio transmission.

Show answer

Answer: C Measuring the rail directly confirms the volt-drop and ties the reset to the TX current surge.

Retrieval practice

Recall check 4 of 5

Voltage Vera says: answer from memory, then check your reasoning.

Q4A radio surge of 300 mA lasts ~10 us and you allow a 0.1 V droop. Under this chapter's release rule that the regulator must be rated for the peak load, roughly what bulk capacitor is needed, and what else must hold?

ALonger idle intervals instead of sizing the capacitor or peak regulator current.

BA 30 F supercapacitor, from treating the 10 µs surge as 10 seconds.

CA 47–100 µF capacitor with a regulator rated only for average radio current.

DA roughly 30 µF minimum, with 47–100 µF selected and the regulator rated for the peak.

Show answer

Answer: D see answers page

Retrieval practice

Recall check 5 of 5

Voltage Vera says: answer from memory, then check your reasoning.

Q5A case study says a prototype failed in the field and the team immediately changed the controller board. What is the main review concern?

AChange the sensor first and collect measurements only if another field trial also fails.

BIt skipped symptom reproduction, measurement evidence, and rejected causes before revision

CTreat field failures as operations issues, leaving hardware causes outside the revision review.

DReplace the controller after launch because a new board will resolve the prototype's observed fault.

Show answer

Answer: B A useful case study should show why the chosen revision follows from measured evidence.

Print reference

Answers 1 of 2

Answer key.

B · Comparable measurements distinguish a real fix from a guess.
B · A reset tied to radio activity makes the power rail the first suspect; confirm it with a rail trace and reset log.
C · Measuring the rail directly confirms the volt-drop and ties the reset to the TX current surge.

Print reference

Answers 2 of 2

Answer key.

D · Using C = I × Δt / ΔV, 0.300 A × 10 µs / 0.1 V = 30 µF, so a practical bulk choice is about 47–100 µF. The regulator must still supply the 300 mA peak current; the capacitor only bridges the short surge.
B · A useful case study should show why the chosen revision follows from measured evidence.