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: 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.
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: For an ESP32 brownout case, the decisive evidence is usually a 3.3 V rail capture during association or transmit, plus a log that shows the reset reason.

Major section

ESP32 Wi-Fi Reboot Case

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

ESP32 Wi-Fi Reboot Case (continued)

The real fault is almost always power: the Wi-Fi radio's current surge is browning out the supply.

The symptom lives in software (a reset), but the cause is a volt-drop.
A case study should preserve what was observed before it claims why the observation happened.
For an ESP32 brownout case, the decisive evidence is usually a 3.3 V rail capture during association or transmit, plus a log that shows the reset reason.

Major section

Measure Current Surge and Rail

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.

Trigger on the reset line, the EN pin, or the falling edge of the rail so the capture shows the moment before reboot.

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

Size the Bulk Capacitor

The fix is a local bulk capacitor near the module's power pin that supplies the fast current surge until the regulator catches up.

Worked example.: Suppose the radio pulls an extra 300 mA and the regulator takes ~10 us to respond, and you can tolerate a 0.1 V droop.

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

Size the Bulk Capacitor (continued)

Equally important, the regulator (or battery) must be rated for the peak, not the average -- a 250 mA LDO cannot sustain a 400 mA burst no matter how large the capacitor.

The pictured paired radial leads makes setup reproducible.
The conclusion in size the bulk capacitor now has a named boundary.
The deeper point is that the revision must follow the measurement.
Verification should repeat the failing operating mode, not only confirm that the device boots once.

Major section

Evidence Timeline

A timeline makes it harder to skip from "it failed" to "we know why" without measurement.

To challenge the claim in evidence timeline, use it to distinguish: Assumption from step 4.
The remaining question is step 8.
Assumption: The team states what the hardware is expected to prove.

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)

For advanced example: pcb readiness review, record the result beside: The review stops layout when evidence is missing.

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.
Stable behavior: The required sensing, actuation, communication, sleep, reset, and safe-output behavior are proven.

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.

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.
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.
Stable interfaces: Pin map, bus addresses, connector plan, voltage levels, placement, and service access are not still changing.

Major section

Incremental Examples (continued)

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 right question is not "Can we make it smaller?" The right question is "Are the interfaces stable enough to commit to layout?".
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?".

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.

The real fault is almost always power: the Wi-Fi radio's current surge is browning out the supply.
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.
The fix is a local bulk capacitor near the module's power pin that supplies the fast current surge until the regulator catches up.

Retrieval practice

Recall check 1 of 4

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

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

AA power brownout - the radio's current surge drops the supply voltage below the reset threshold.

BA subtle logic error somewhere in the network-connection code that only manifests after the device has successfully associated with the access point and begins to exchange the very first data packets over the link.

CThe Wi-Fi access point is rejecting the device.

DThe flash memory is corrupt.

Show answer

Answer: A A reset tied to radio activity points to the power rail, not the firmware.

Retrieval practice

Recall check 2 of 4

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

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

AScope the 3.3 V rail during a connection attempt and see whether it dips below the brownout threshold as the radio transmits.

BAdd progressively longer delay statements throughout the connection routine and keep recompiling and reflashing the firmware until, by trial and error, the device happens to stop resetting during the Wi-Fi association step.

CReplace the Wi-Fi library with a different one.

DAssume the chip is defective and order a new one.

Show answer

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

Retrieval practice

Recall check 3 of 4

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

Q3A radio surge of 300 mA lasts ~10 us and you allow a 0.1 V droop. Roughly what bulk capacitor is needed, and what else must hold?

AAbout 30 uF (C = I x dt / dV), so use ~47-100 uF - and the regulator must be rated for the peak current, not the average.

BPace transmissions further apart instead of adding capacitance, because a longer idle interval gives the regulator time to recover before the next radio packet.

CAbout 30 F, a supercapacitor.

DUse ~47-100 uF near the radio and size the regulator for average current, since the capacitor supplies the brief peak current during transmission.

Show answer

Answer: A The charge math sizes the cap, and the supply must sustain the peak or no cap will save it.

Retrieval practice

Recall check 4 of 4

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

Q4A 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, then document measurements only if the second field trial fails

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

CTreat field failures as operations issues that should never change hardware choices

DReplace the controller only after launch, regardless of what the prototype evidence shows

Show answer

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

Print reference

Answers

Answer key.

A · A reset tied to radio activity points to the power rail, not the firmware.
A · Measuring the rail directly confirms the volt-drop and ties the reset to the TX current surge.
A · The charge math sizes the cap, and the supply must sustain the peak or no cap will save it.
B · A useful case study should show why the chosen revision follows from measured evidence.