Drone Sensor Node


Design it as two separate electronic systems: a safety-critical flight stack and a non-critical sensor payload.
Recommended schematic architecture

Text


4S/6S LiPo
  |
  +-- Fuse / anti-spark / TVS
  |
  +-- 4-in-1 ESC --> Motors
  |
  +-- 5.2 V, >=5 A buck --> Autopilot + RC receiver + GNSS
  |
  +-- 5 V, 2 A filtered buck --> Companion computer / payload
  |
  +-- 3.3 V low-noise rail --> Environmental sensors

Autopilot
  +-- DShot/PWM --> ESC
  +-- UART --> GNSS + compass
  +-- UART --> telemetry radio
  +-- UART/CAN --> sensor controller
  +-- I2C/SPI --> rangefinder / optical flow
  +-- ADC <-- battery voltage/current monitor
  +-- GPIO --> buzzer, safety switch, status LEDs

Sensor controller
  +-- I2C --> temperature/humidity and other sensors
  +-- SPI --> local flash or microSD
  +-- UART/CAN --> autopilot
  +-- Wi-Fi/BLE --> setup and post-flight data download
1. Use a proven autopilot
Base the aircraft around a Pixhawk-compatible flight controller running ArduPilot or PX4. Designing the IMU flight controller from scratch requires careful sensor redundancy, vibration control, controlled-impedance interfaces, real-time firmware, and extensive validation.
Your custom schematic should initially cover:
  • Power distribution and monitoring
  • Sensor payload
  • Autopilot interfaces
  • Payload isolation and protection
  • Connectors and service/debug access
2. Power input and distribution
For a 4S LiPo, design for approximately 12–17 V; a 6S system needs approximately 18–25.2 V.
Include:
  • Input fuse sized from measured maximum load
  • Reverse-polarity protection
  • TVS diode selected for the battery voltage and transients
  • Bulk low-ESR capacitance near the ESC
  • Battery voltage divider into the autopilot ADC
  • Bidirectional current/power monitor
  • Separate buck regulators for flight electronics and noisy payloads
  • LC or ferrite filtering for GNSS, sensors, and radios
  • Regulator enable controls and test points
Do not route motor current through the sensor PCB. Keep the high-current battery-to-ESC path short and physically separate.
3. Autopilot interfaces
Expose keyed, locking connectors for:
  • ESC signals and telemetry
  • Dual power input where supported
  • GNSS/compass
  • RC receiver
  • Telemetry radio
  • CAN peripherals
  • Payload UART/CAN
  • SWD/JTAG and console UART
Use 3.3 V logic unless the selected autopilot explicitly specifies otherwise. Add ESD protection on external connectors and series damping resistors on fast clock/data lines.
4. Sensor payload
The existing SiWG917/SHT41 concept can become the payload controller, but it should be revised for drone power and measurement integrity:
  • Add a battery-compatible buck input or accept a regulated 5 V payload supply.
  • Connect to the autopilot through UART or CAN.
  • Add local flash or microSD so measurements survive radio loss.
  • Timestamp each reading and associate it with autopilot position.
  • Add a hardware watchdog and brownout-safe storage behavior.
  • Keep Wi-Fi/BLE for configuration and data retrieval—not flight safety.
  • Mount the SHT41 away from regulators, MCU heat, sunlight, battery airflow, and motor/propeller turbulence.
For accurate ambient readings, consider a remote cabled sensor in a ventilated radiation shield rather than placing it directly on the main PCB.
5. Essential safety behavior
Implement these independently of Wi-Fi/BLE:
  • RC/manual takeover
  • Geofence
  • Return-to-home on lost control link
  • Low-battery warning and landing
  • GNSS-loss behavior
  • Payload failure that cannot reset or power-cycle the autopilot
  • Default-off payload outputs after reset
  • Buzzer and high-visibility status indication
Design process
  1. Freeze battery voltage, aircraft size, payload mass, peak current, sensors, autopilot, and required flight time.
  2. Produce a power budget covering continuous, peak, startup, and stalled loads.
  3. Draw the block diagram and define every connector/pinout.
  4. Capture power protection and regulators first.
  5. Add autopilot interfaces and power monitoring.
  6. Add the sensor controller, storage, and sensors.
  7. Run ERC and review every power domain and failure path.
  8. Lay out high-current power first, then regulators, interfaces, and sensors.
  9. Validate power rails with motors disconnected before installing propellers.
A concrete schematic cannot be safely selected until the battery (4S or 6S), autopilot model, motor/ESC current, sensor list, and required flight time are fixed. No project changes were made. Execution stopped because your ACUs ran out.

Project Specification — USB-C WiFi BLE TH Sensor
Project Overview
Status: Draft schematic in progress.
A consumer USB-C powered temperature and relative humidity sensor node with Wi-Fi and Bluetooth Low Energy connectivity. The board uses a protected USB-C 5 V sink input, local 3.3 V regulation, a low-power Wi-Fi/BLE MCU module, and a digital I2C T/RH sensor.
Intended Use
  • Indoor consumer environmental monitoring node.
  • Powered from USB-C 5 V chargers, hubs, or ports.
  • Designed for prototype-to-production learning; not medical, industrial safety, or outdoor/weatherproof use unless later specified.
What the Device Should Do
  • Measure ambient temperature and relative humidity.
  • Connect over 2.4 GHz 802.11 b/g/n Wi-Fi.
  • Support BLE 5.x provisioning or local telemetry.
  • Power from USB-C default 5 V sources.
  • Survive common consumer input faults with reverse-current, overvoltage, undervoltage, and overcurrent protection.
Main Features
  • USB-C receptacle configured as sink-only with independent CC1/CC2 5.1 kΩ Rd resistors.
  • Protected 5 V input sized for 0.5–3 A capable sources, while the node itself is expected to draw well below 500 mA average.
  • 3.3 V logic rail for MCU and sensor.
  • Native USB data/programming path where supported by the selected MCU.
  • Boot/reset controls, debug/programming access, and status LED.
System Architecture

Diagram


I2C USB D+/D- USB-C Receptacle node_5V Sink VBUS Protection OVP UVLO OCP Reverse Blocking 3.3V Regulator WiFi/BLE MCU Module Digital T/RH Sensor Status LED
Hardware Subsystems
  • Power input: USB-C receptacle, CC pull-downs, VBUS ESD/TVS, protected power switch/eFuse or load switch with OVP/UVLO/OCP/reverse-current blocking.
  • Regulation: 5 V to 3.3 V rail sized for Wi-Fi transmit current peaks.
  • Compute/radio: certified ESP32-family module preferred to avoid custom RF matching and simplify regulatory work.
  • Sensor: digital I2C temperature/humidity sensor with local decoupling and one shared I2C pull-up pair.
  • User/debug: reset and boot controls, status LED, USB programming, optional exposed test/debug header.
Interfaces and Connections
  • External: USB-C 5 V power and USB 2.0 D+/D- for programming/debug.
  • Internal: 3.3 V rail, GND, I2C SDA/SCL, boot/reset, status LED GPIO.
  • RF: integrated 2.4 GHz antenna module; PCB layout must provide the module antenna keepout.
Power and Runtime Expectations
  • Source: USB-C 5 V default power only; no battery in this revision.
  • Source capability planning: tolerate 0.5 A, 1.5 A, and 3 A capable USB-C sources. Do not assume the device may draw 3 A unless CC current advertisement is measured/implemented.
  • Low-power behavior: firmware should sleep between samples and radio transmissions, but USB-powered operation makes absolute sleep current less critical than thermal and regulatory behavior.
Power Tree and Power Budget

Table


RailLoadSleepTypical activePeak
3.3 VWi-Fi/BLE MCU module~10–100 µA deep sleep~80–240 mA radio active~500 mA short Wi-Fi TX burst
3.3 VT/RH sensor<1 µA standby~0.5–1 mA measuring~1 mA
3.3 VStatus LED0 mA off~2 mA on~5 mA configured max
3.3 VPull-ups/leakage~1–2 mA worst when lines lownegligible average~1.4 mA for two 4.7 kΩ pull-ups low
Estimated 3.3 V rail sizing target: 250 mA typical active, 510 mA transient peak. For an LDO from 5 V, input current is approximately output current; thermal at 250 mA is about (5.25 V - 3.3 V) × 0.25 A = 0.49 W, so a small SOT-23 LDO may be marginal during sustained Wi-Fi. Preferred choices are a high-current low-Iq regulator in a thermally capable package or a quiet buck regulator if sustained radio current/thermal limits demand it.
Manufacturing and Assembly Expectations
  • Default assembly: SMD, production-intent consumer PCB.
  • Use stocked, non-EOL parts where available.
  • Add test points for 5 V protected rail, 3.3 V, GND, reset/boot, and I2C if space permits.
Firmware-Relevant Hardware Requirements
  • Define actual GPIO pins for I2C SDA/SCL and status LED.
  • Provide USB programming or serial/JTAG path.
  • Support Wi-Fi + BLE provisioning, periodic sensor reads, and telemetry output.
  • Include boot/reset access for field recovery.
Physical Design Expectations
  • ESP32 module antenna must be placed at board edge with no copper/traces/components in the keepout on all layers.
  • Sensor should be isolated from regulator/MCU heat sources and exposed to ambient airflow.
  • USB-C connector should be board-edge mounted and mechanically reinforced.
Important Design Decisions
  • Use an ESP32-family certified module rather than a bare RF SoC.
  • Use a digital I2C humidity/temperature sensor.
  • Use USB-C sink-only 5 V; no USB-PD negotiation in this revision.
  • Include a protected VBUS front end instead of relying on a fuse alone.
Assumptions
  • Indoor consumer use, ambient operating range roughly 0–50 °C unless later expanded.
  • No enclosure dimensions or board size provided yet.
  • No cloud protocol specified; firmware examples will print readings and include Wi-Fi/BLE placeholders.
Change Notes
  • Initial requirements captured from user request on 2026-07-17.
  • Project Overview

  • Intended Use

  • What the Device Should Do

  • Main Features

  • 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