Getting Started With Hardware Design

Worked for 1 min 48 sec
Thought for 8 sec
Completed design checks — found 2 issues.
Thought for 21 sec
Thought for 20 sec
Awaiting 2 tasks
"GHOST TAP UART Schematic" completed.
"GHOST TAP Schematic Review" completed.

flux

GHOST TAP UART — partial schematic built
I renamed the project and created an actual 33-component, 26-net circuit, not just a block diagram. It includes:
  • A U1 configured electrically for local 3.3V logic.
  • USB-C with separate CC resistors, USB ESD protection, and decoupling.
  • Cross-coupled DTR/RTS auto-program circuitry, manual BOOT/RESET buttons, and an optional disconnectable EN timing capacitor.
  • A J2 for TX, RX, GND, BOOT, and EN—no target power connection.
  • POWER/TX/RX LED circuits and voltage-monitor test points. TX/RX indicators still require verified bridge configuration instructions.
The auto-reset DC simulation matched all four DTR/RTS states. This verifies static logic, not successful flashing or reset timing on your Levoit.
Not finished
  • ERC still reports two undriven USB VBUS pin errors; USB host power explains them, but their formal disposition remains unresolved.
  • PCB layout has 68 reported airwires. Intentional placement, routing, silkscreen, final DRC, and manufacturing exports are not complete.
  • Readable schematic cleanup was blocked by unavailable symbol-arrangement capabilities; Contact Support for that platform limitation.
  • Final connector footprint audit, LED provisioning, power/inrush checks, and independent review results have not been reconciled. Do not order this PCB yet.
The requirements are saved in the project files: Project Specification. The next steps are to finish schematic verification and cleanup, approve the board plan, then place, route, and validate the PCB.
Safety: this adapter is not isolated. Do not connect it to a mains-referenced appliance controller; verify an isolated low-voltage target supply and the actual Levoit signal points first.
Execution stopped because your ACUs ran out.
Sign up to send

Files

Schematic

Layout

3D View

Project Specification
Project Overview
  • GHOST TAP UART: real USB-C to 3.3 V TTL UART programmer/interface PCB, not a replacement Levoit controller or power supply.
  • Status: schematic build authorized; physical board plan and layout awaiting approval.
Intended Use
  • Android phone in USB host/OTG mode communicates with and flashes an existing independently powered Levoit ESP32 module.
  • Prototype for bench use; target physical pinout must be verified by the user, never inferred.
  • SAFETY: adapter is non-isolated. Do not connect to a mains-referenced appliance controller. Disconnect appliance mains and use only a verified isolated low-voltage target power arrangement without backfeeding the original supply.
What the Device Should Do
  • Enumerate as an Android-supported USB serial bridge and exchange 3.3 V UART data.
  • Assert target GPIO0/BOOT and EN/RESET with an Espressif-compatible auto-program circuit, plus manual buttons.
  • Expose accessible, labeled target connections without supplying target power.
Main Features
  • USB-C USB 2.0 device connector, independent CC resistors, ESD protection.
  • Power indicator; TX/RX activity indicators if documented native bridge outputs or buffered sensing permit them without UART loading.
  • Target header: TX, RX, GND, BOOT/GPIO0, EN/RESET.
  • Test points and clearly separated USB 5 V monitor pad if implemented; never a target supply connection.
Mechanical System Architecture
  • Bare PCB, no enclosure in scope.
  • Mechanical block flow: USB-C cable -> board -> 2.54 mm target jumper/solder header -> verified target test points.
  • Buttons and LEDs visible/reachable on top; exact outline and edge assignment proposed after measuring populated footprints.
Electrical System Architecture
  • Android USB host -> USB-C connector/protection -> USB-UART bridge -> series-protected 3.3 V TX/RX -> target.
  • Bridge DTR/RTS -> authoritative cross-coupled two-NPN auto-reset logic -> target BOOT and EN.
  • Manual switches connect BOOT/EN to common ground.
  • Preferred bridge family CP2102N, exact MPN/package selected and verified during build; no blind CP2102 substitution.
Hardware Subsystems
  • USB interface: USB2 D+/D- duplicated receptacle pins correctly joined, independent 5.1 kohm CC pulldowns, low-capacitance USB ESD device near connector.
  • Power: USB powers only adapter. Exact bridge bus-powered reference, VBUS sensing, regulator and decoupling required.
  • UART: 3.3 V logic only. Series resistors provide limited fault mitigation, NOT isolation or guaranteed protection of an unpowered peer.
  • Programming: cross-coupled auto-reset circuit, target-owned EN/BOOT pullups, no pullups to adapter rail. Optional disconnectable EN timing capacitor if target existing RC is unknown.
  • Indicators: POWER plus native/buffered TX/RX if feasible and configured explicitly.
Interfaces and Connections

Table

Adapter connectionTarget connection
TXverified target RX
RXverified target TX
GNDverified isolated target GND
BOOTverified GPIO0, per user's target requirement
ENverified ESP32 enable/reset
  • Do not assume ESP32 variant or board pin locations. If actual module uses a different boot strap, target integration must be revisited.
  • USB 5 V must never connect to UART, BOOT or EN.
Power and Runtime Expectations
  • USB-bus-powered adapter; target retains existing proven 5 V input and onboard regulation.
  • No target power supplied by bridge regulator; no target 3.3 V supply pin.
  • Both devices must be powered before connecting signal leads; disconnect signal leads before removing either supply. Hot-plug/power-loss tolerance is not guaranteed.
Power Tree and Power Budget
  • Phone VBUS -> adapter protection -> bridge manufacturer-recommended power arrangement -> local 3.3 V logic and indicators.
  • Independent isolated 5 V source -> existing target regulator -> target 3.3 V circuitry; common GND only at verified interface.
  • Budget and USB input capacitance to be verified from exact selected parts during schematic build; no speculative rated current claim.
Manufacturing and Assembly Expectations
  • Real MPNs and verified pin numbers/footprints; accessible 2.54 mm plated through-holes for hand-soldering/jumpers.
  • Prefer common passives and compact portable PCB. Surface-mount bridge/USB connector may require reflow; hand-solder-friendly target connections are the priority.
  • Proposed layer count, size, mounting and part sides will be settled at PCB plan checkpoint.
  • Final release requires no airwires and resolved critical ERC/DRC; export only after routing/review.
Firmware-Relevant Hardware Requirements
  • No onboard MCU firmware required.
  • Android application must separately support bridge driver, ESP32 flashing protocol, DTR/RTS timing, and disabled hardware flow control.
  • Library support is not proof of successful flashing; bench verification mandatory.
Physical Design Expectations
  • Silk: GHOST TAP UART, TX, RX, GND, BOOT, EN and USB 5V as applicable, with separation/warning for USB power monitor.
  • Keep USB pair short over a continuous ground return; choose practical controlled-impedance geometry from approved stackup.
  • No invented Levoit mounting geometry or target board footprint.
Important Design Decisions
  • Keep adapter and target power paths separate.
  • Use target-side existing pullups for released BOOT/EN; do not backfeed them from adapter 3.3 V.
  • Use manufacturer/Espressif source topology, not a simplistic two-grounded-emitter circuit.
  • No galvanic isolation claim; safe bench arrangement is a prerequisite for connection.
Assumptions
  • Target really supports the requested GPIO0 + EN programming interface, has appropriate pullups, and its UART is 3.3 V.
  • Phone supports USB host/OTG and has an appropriate data cable and compatible application.
  • Existing target reset timing is unknown; automatic programming remains target-dependent until tested.
Change Notes
  • Initial specification transcribed from user attachment; safety and independent-power limitations added after architecture review.
Reference Sources

  • Project Overview

  • Intended Use

  • What the Device Should Do

  • Main Features

  • Mechanical System Architecture

  • Electrical System Architecture

  • Hardware Subsystems

  • Interfaces and Connections

  • Power and Runtime Expectations

  • Power Tree and Power Budget

  • Manufacturing and Assembly Expectations

  • Firmware-Relevant Hardware Requirements

  • Physical Design Expectations

  • Important Design Decisions

  • Assumptions

  • Change Notes

  • Reference Sources