This board is an onboard data acquisition, wireless transport, and motor-control interface board for a small quadcopter.
The onboard controller is ESP32, used primarily for sensor acquisition, communications bridging, housekeeping, and ESC PWM generation.
High-rate flight-control fusion, image processing, and obstacle-avoidance computation are assumed to run off-board on a host computer or mobile/ground station, not on the onboard ESP32.
Updated communications decision
BLE remains available for provisioning, low-rate telemetry, parameter updates, and maintenance.
Real-time video transport shall use Wi-Fi, not BLE.
The camera path is treated as a high-bandwidth subsystem and must not share critical low-noise sensor routing regions without isolation.
USB and programming boundary
Preferred approach: a single USB-C interface may provide 5 V input and ESP32 program/debug access only if USB data integrity, boot control, ESD robustness, and power-path behavior are verified to be reliable in the final architecture.
Approved fallback: separate interfaces are allowed and preferred if the merged USB-C design compromises reliability. In that case:
one connector is dedicated to power or charging input
one connector/header is dedicated to ESP32 programming/debug
This interface split is now an explicit allowed requirement, not an exception.
Sourcing and cost constraints now frozen
Core active and passive devices shall prioritize parts that are easy to purchase in mainland China through common channels such as LCSC, Taobao ecosystem modules, and mainstream local distributor stock.
For each critical function, prefer package options and part families with multiple second-source or drop-in alternatives commonly seen in the China market.
Avoid niche imported-only parts when a commonly available domestic or broadly stocked alternative exists.
The laser distance function shall prioritize low-cost modules over premium precision modules, as long as the module still provides stable short-range altitude assistance suitable for a small quadcopter.
Low-cost ranging and China-market availability are now explicit selection constraints, not soft preferences.
Native USB on ESP32-S3 is the primary programming path through USB-C.
CH343P is retained as a fallback UART download/recovery path and to satisfy the approved split-interface fallback strategy.
IMU, barometer, and ToF sensor share one 3.3 V I2C sensor bus with one resistor pair of 4.7 k pull-ups.
External rotating lidar uses a dedicated UART connector.
Four ESC outputs shall be direct 3.3 V PWM outputs plus ground reference.
The camera connector is now a dedicated 24-pin OV5640 DVP interface.
Power tree constraints
Input source starts from 5 V USB-C sink power.
Primary regulated rail is 3.3 V for ESP32 and sensors.
Wi-Fi activity is treated as a burst-current load and must be budgeted separately from quiet sensors.
Sensitive sensors shall receive local filtering and dedicated decoupling close to each device.
Motor/ESC outputs are logic-level control only unless a later revision explicitly integrates battery-current motor power handling.
USB-C sink configuration uses two 5.1 k pulldowns.
OV5640 camera rail constraints: DOVDD is tied to 3.3 V to match ESP32-S3 I/O, AVDD requires a dedicated 2.8 V rail on CAM_AVDD, and DVDD is assumed internal to the selected camera module variant.
Connector upgrade completed: X1 is now a 24-pin FH12-24S-0.5SH(55) FPC connector.
The design uses the provided generic OV5640 DVP 24-pin signal set in 8-bit mode.
Pin mapping frozen as:
Pin 1: STROBE -> NC
Pin 2: AGND -> GND
Pin 3: SIOD -> I2C_SDA
Pin 4: AVDD -> CAM_AVDD (2.8 V required)
Pin 5: SIOC -> I2C_SCL
Pin 6: RESET -> CAM_RESET
Pin 7: VSYNC -> CAM_VSYNC
Pin 8: PWDN -> CAM_PWDN
Pin 9: HREF -> CAM_HREF
Pin 10: DVDD -> module internal / board NC
Pin 11: DOVDD -> 3V3
Pin 12: D9 -> NC in 8-bit mode
Pin 13: XCLK -> CAM_XCLK
Pin 14: D8 -> NC in 8-bit mode
Pin 15: DGND -> GND
Pin 16: D7 -> CAM_D7
Pin 17: PCLK -> CAM_PCLK
Pin 18: D6 -> CAM_D6
Pin 19: D2 -> CAM_D2
Pin 20: D5 -> CAM_D5
Pin 21: D3 -> CAM_D3
Pin 22: D4 -> CAM_D4
Pin 23: D1 -> CAM_D1
Pin 24: D0 -> CAM_D0
Pins 25 and 26 on the chosen connector footprint are mechanical / shield extras and are not part of the 24-pin logical signal assignment in this interface package.
Camera timing and sequencing requirements
Power sequencing requirement is frozen as:
stabilize DOVDD first
stabilize AVDD second
pull PWDN low and wait at least 5 ms
drive XCLK for at least 1 ms
release RESET and wait at least 20 ms before SCCB initialization
SCCB shares the existing board I2C signal names I2C_SDA and I2C_SCL in this revision.
DVP bus width is frozen to 8-bit mode using D0-D7 only; D8 and D9 are intentionally not connected.
GPIO19/GPIO20 are reserved for native USB on the module implementation
GPIO21 -> LIDAR_RX
TXD0 / RXD0 remain assigned to fallback UART download/debug path
Camera assignments frozen as:
GPIO2 -> CAM_RESET
GPIO4 -> CAM_PWDN
GPIO5 -> CAM_VSYNC
GPIO6 -> CAM_HREF
GPIO7 -> CAM_XCLK
GPIO10 -> CAM_PCLK
GPIO11 -> CAM_D2
GPIO12 -> CAM_D1
GPIO46 -> CAM_D0
GPIO47 -> CAM_D3
GPIO48 -> CAM_D4
GPIO38 -> CAM_D5
GPIO39 -> CAM_D6
GPIO40 -> CAM_D7
System conflict closure list
Resolved conflicts:
PWM4 and lidar TX are no longer shared.
Camera bus does not overlap USB native data pins.
Camera bus does not overlap UART0 fallback programming pins.
Camera SCCB reuses the existing I2C bus intentionally, avoiding extra GPIO consumption.
Accepted constraints:
Camera SCCB sharing means sensor and camera configuration traffic share one bus; firmware must serialize transactions.
GPIO46 is input-capable only on ESP32-S3, so it is intentionally used for CAM_D0, which is camera-to-MCU input.
Remaining implementation items:
A real 2.8 V source for CAM_AVDD must be added in the next schematic pass.
If the selected OV5640 module requires stronger XCLK drive integrity, consider a small series resistor near the ESP32 pin in the next pass.
If SCCB pull-up loading becomes excessive when the camera module is attached, the combined pull-up value must be reviewed.
PCB layout constraint freeze
Place the ESP32-S3 module at a board edge with full antenna keepout.
Keep USB-C and ESD/protection parts grouped at the board edge.
Keep U2, U3, and U4 in the quietest region away from PWM connectors.
Keep the camera connector X1 at a board edge aligned for short DVP bus routing back to U1.
Initial layout outline is now set to 50 mm x 50 mm with 2 mm corner radius as the compact baseline.
The implemented stackup baseline is now Standard 4 Layer because USB 2.0 plus 2.4 GHz ESP32 RF benefit from a solid reference plane and cleaner return paths.
Global prototype-capable minimum rules are now set to 0.15 mm trace width and 0.15 mm keep out.
Known open issues after this update
The fallback UART bridge U5 is powered and partially connected, but its auto-download control lines are not yet implemented.
U6 is a practical baseline regulator choice, but thermal margin and transient headroom for Wi-Fi bursts should be reviewed in the next pass.
CAM_AVDD is now generated by U7, using the ME6211C28M5G-N 2.8 V LDO fed from the 3.3 V rail.
The camera analog rail now includes C17 1 uF at the LDO input and C18 1 uF at the LDO output, matching the selected regulator datasheet guidance.
U7 CE is tied high so the camera analog rail is always enabled in this revision.
PCB routing cleanup grouping and placement freeze
Current DRC snapshot before detailed routing cleanup reports 116 airwire-related errors.
External interfaces: J3 PWM cluster and J2 lidar UART cluster
Camera placement is now intentionally compacted around X1 to shorten CAM_AVDD and CAM_XCLK and to reserve a cleaner escape corridor from U1 to the camera connector.
USB1 remains fixed near the board edge; U5 and U6 are shifted to reduce overlap between USB breakout paths and camera/power escape paths.
J3 and J2 are kept in separate functional regions so PWM outputs and lidar UART traces do not compete for the same narrow routing channels.
U1, X1, and USB1 are marked protected/high-priority anchors for subsequent detailed routing cleanup.