makeIRLPCB engineering field guide

Vibecode AI hardware guides

Vibecode a Temperature Logger PCB with AI and Gate Checks

Generate a temperature-logger carrier by defining sensor accuracy, placement, sample rate, storage, RTC, power loss, ready for explicit human gate review.

Practical PCB integration · KiCad 9 · Manufacturing gate

Vibecoding a temperature logger: what the generator can and cannot do

MakeIRL's generator treats a temperature logger prompt as a self-contained project board. Current status: in envelope needs block.

A USB-powered logger using cataloged I²C sensor, RTC, and storage blocks could fit. Those blocks are not in the current seed catalog, and battery operation/charging is not generated.

Create a USB-powered temperature logger with a cataloged I²C sensor, RTC with removable backup provision, SPI flash, status LED, UART export, and no lithium battery.

MakeIRL V2 extracts a strict CarrierSpec from the prompt, applies a deterministic scope policy, resolves only cataloged blocks, composes deterministic connectivity and exact-MPN BOM data, emits KiCad artifacts, and runs the manufacturing gate. The language model does not invent pins, topology, parts, placement, routing, or substitutions.

What the prompt must specify

  1. Sensor MPN, range, accuracy, thermal response, location, sample interval, and calibration method
  2. Storage type/capacity/endurance, timestamp source, power-fail behavior, data format, and extraction interface
  3. Power source, sleep target, enclosure, sensor airflow/contact, programming, test points, and retention requirement

Block plan:

  • Cataloged controller/module carrier
  • Verified temperature-sensor, RTC, and nonvolatile-storage blocks
  • Cataloged USB power, status, service connector, and optional removable backup interface

Interfaces: I²C sensor/RTC, slow SPI storage, UART or USB-via-supported-module data export. Power plan: USB power for current scope; any backup cell must be non-charging and reviewed, while lithium charging is refused.

Layout priorities and gate checks

  • Separate the sensor from heat sources, keep RTC/storage bypassing local, expose a current-measurement link, and make data/programming access serviceable.
  • Freeze the board outline, mounting holes, connector faces, component height zones, test access, and keepouts before evaluating generated placement or routing.

Gate checks:

  1. S1Generated connectivity and schematic parity. Check sensor/RTC addresses and voltages, storage write/hold-up behavior, backup-cell isolation, pull-ups, exact flash MPN, and all power-fail nets.
  2. S1Catalog and exact-MPN provenance. Every temperature logger block, footprint, pin map, required companion, BOM line, and block-status claim must resolve to the pinned catalog version; the prompt cannot create missing hardware.
  3. S2PCB DRC, fabrication profile, and release identity. Run KiCad DRC and schematic parity, compare geometry with one quoted fab profile, regenerate Gerbers/drills/BOM/CPL from the approved revision, and inspect both local and supplier previews.

Human review, failure modes, and validation

  • Review sensor thermal coupling, calibration uncertainty, storage endurance, filesystem/power-loss recovery, RTC drift, backup chemistry, and enclosure response.
  • A reviewer must check primary datasheets, exact symbol-to-footprint mapping, power and protection, return paths, connector orientation, mechanical fit, test coverage, and every gate waiver before release.

Failure modes:

  • A logger can sample accurately yet lose or corrupt the latest records when power falls during a flash write or RTC backup is wired incorrectly.
  • ERC and DRC can prove encoded consistency but cannot prove requirements, component source truth, analogue stability, RF/EMI, thermal margin, firmware, safety, compliance, or delivered product function.

Validation plan:

  • Calibrate across range, cycle power during writes, fill/read storage, measure timestamp drift and sleep current, and test response in the final enclosure.
  • Bring up first articles with current limiting, measure every rail before fitting expensive modules, program minimal test firmware, exercise every interface and fault assumption, and retain measurements against the released revision.

Refusal boundary and generator envelope

  • Refuse invented sensor accuracy, uncataloged storage/RTC pinouts, lithium charging, or safety-critical cold-chain claims.
  • MakeIRL composes supported hardware; it does not validate logging firmware, calibration traceability, or data integrity by assertion.

The intended carrier envelope is 2-layer FR-4, at most 100 × 100 mm, at most 40 BOM lines, at most 12 V SELV and 2 A, with cataloged modules and low-speed I²C, UART, GPIO, slow SPI, or power-only USB-C connections. The current catalog is narrower than that intended envelope.

Deterministic policy refuses unsupported or hazardous requests, including mains, motors, lithium charging, RF design, switch-mode power, high-speed buses, excessive size/current, and unknown modules. A refusal is a safety and truthfulness result, not a failed attempt to improvise a circuit.

The current seed catalog contains ESP32-C3 carrier, USB-C power, and Qwiic/status-LED blocks at checked status. They have passed deterministic checks but are not yet physically verified through the documented two-lot bring-up ladder; pages must not call those current seeds verified.

The output is a gated design candidate for engineering review. Current placement/routing can still produce blocking or review findings, so a generated board is not automatically fab-ready, functionally validated, certified, or safe to order. MakeIRL does not autonomously place a fabrication order from a prompt. Human review, source and output inspection, gate resolution, order-specific fab confirmation, and physical bring-up remain required.

Generate a gated candidate, not a blind board

Try a temperature logger prompt in the generator and review every gated artifact before ordering.

Generate a carrier board