Vibecode a Drone Telemetry Adapter: AI Scope Limits Guide

MakeIRL's generator treats a drone telemetry adapter prompt as a self-contained project board. Current status: refused.

RF, battery/power interaction, and flight-critical functions are out of scope. A passive wired UART pinout adapter may be considered only with exact cataloged connectors and voltage evidence.

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.

1. Exact flight-controller and telemetry connector MPNs/views, pinouts, UART voltage/direction, baud, grounds, and power pins
2. Whether any radio/module is involved, flight power and transients, battery relationship, isolation, ESD, and fail-safe behavior
3. Mass, mounting, vibration, cable retention, prop-safe test setup, firmware protocol, and non-flight acceptance scope

Block plan:

• No radio, antenna, battery, flight-power, or autonomous-control block
• Possible verified passive wired UART adapter between exact connectors
• Optional level/protection only through a verified block with bench-only scope

Interfaces: bench UART, ground, no RF or flight power. Power plan: Passive/no-power preferred; any VTref sensing is high impedance. The adapter must not source flight-controller or radio power.

• Key both connectors, label from mating views, keep TX/RX and grounds clear, and provide strain relief without pretending the adapter is flight qualified.
• 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. For the safe alternative, compare both pin maps, verify TX/RX crossing and voltage, ensure power pins are isolated, and prove no RF/battery/control paths exist.
2. S1Catalog and exact-MPN provenance. Every drone telemetry adapter 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.

• Review flight safety, connector retention, vibration, protocol/voltage, ground loops, battery transients, RF certification, firmware, and operational procedures.
• 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 mislabeled 5 V telemetry pin can damage a 3.3 V port, while an intermittent adapter can corrupt data or control behavior in flight.
• 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:

• Test the passive adapter only on the bench with current limiting, continuity, voltage and UART traffic; do not authorize flight use from these tests.
• 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.

• Refuse RF, batteries, flight power, autonomous or safety-critical control, motors, and flight-qualified claims.
• A bench UART adapter must be labeled and documented as such, not reframed as a drone telemetry system.

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.