USB-C WiFi BLE Sensor Design

flux

I captured the requirements and power budget in project files, and the regulator choice will be based on a ~560 mA 3.3 V peak load rather than a small marginal LDO.

flux

I started the USB-C WiFi/BLE temperature-humidity sensor node and made concrete project progress before tool execution stopped.
Completed:
  • Renamed the project to USB-C WiFi BLE T-RH Sensor Node and updated the description.
  • Created a project specification file capturing the architecture, assumptions, USB-C 5 V input, WiFi/BLE, digital T/RH sensing, protection, and layout expectations.
  • Created a power-budget file. The design is sized around a ~560 mA 3.3 V peak load, so I selected a buck-regulator direction instead of a thermally marginal small LDO.
  • Selected and added main schematic parts:
    • ESP32-S3-WROOM-1 WiFi/BLE module
    • SHT40-AD1B-R2 I2C temperature/humidity sensor
    • USB-C receptacle
    • TPS25210L eFuse/protection IC
    • MP28301 3.3 V buck regulator
    • USBLC6-2SC6 USB data ESD protection
    • Boot/reset switches, status LED, inductor, and required passives
  • Consulted datasheets for the ESP32-S3 module, SHT40 sensor, TPS25210 protection IC, USBLC6 ESD array, and USB-C connector.
Remaining work:
  • Finish datasheet extraction for the MP28301 buck regulator.
  • Wire the schematic: USB-C CC/VBUS/data, eFuse protection, 3.3 V buck, ESP32 USB/I2C/boot/reset, SHT40, LED, and all decoupling.
  • Add or adjust any buck feedback/support parts required by the MP28301 datasheet.
  • Run schematic review/ERC and fix all violations.
  • Create firmware starter and board bring-up project files.
  • Only after the schematic is clean, move to layout with user confirmation.
Finish buck design
Wire full schematic
Run ERC check
Add bring-up notes
Optimize module choice
Sign up to send

Files

Schematic

Layout

3D View

Project Specification — USB-C WiFi BLE T-RH Sensor Node
Project Overview
  • Status: Draft schematic in progress
  • Device: Consumer environmental sensor node measuring temperature and relative humidity.
  • Connectivity: 2.4 GHz WiFi 802.11 b/g/n plus Bluetooth LE 5.x.
  • Power: USB-C 5 V sink input with protected power path and 3.3 V system rail.
Intended Use
  • Indoor consumer environmental monitoring node powered from a USB-C wall adapter, hub, or host port.
  • Prototype-to-production intent using SMD components and module-based RF to reduce RF design risk.
What the Device Should Do
  • Accept default USB-C 5 V input.
  • Protect downstream electronics from reverse current, over-voltage, under-voltage, and over-current events.
  • Power a low-power WiFi/BLE MCU and digital T/RH sensor from a regulated 3.3 V rail.
  • Provide USB data/programming path where supported by the MCU module.
  • Measure and report temperature/humidity over WiFi and BLE.
Main Features
  • USB-C receptacle configured as sink with independent CC pull-downs.
  • 5 V input protection for ESD/surge, OVP/UVLO/OCP, and reverse blocking.
  • 3.3 V regulator sized for WiFi transmit peaks.
  • ESP32-class low-power WiFi/BLE module with integrated antenna.
  • Digital I2C temperature/humidity sensor.
  • Boot/reset buttons and status LED.
System Architecture
Diagram



  
    
  
  
    
  
















USB-C 5 V Input
Input Protection OVP UVLO OCP Reverse Blocking
3.3 V Regulator
WiFi BLE MCU Module
Digital T/RH Sensor
I2C Bus
USB D+ D-
Hardware Subsystems
  • Power input: USB-C sink, 5 V default, planned for 0.5 A to 3 A sources without USB-PD negotiation.
  • Protection: Dedicated protected load-switch/eFuse style input path plus TVS protection.
  • Regulation: 5 V to 3.3 V regulator sized for WiFi/BLE peak current.
  • Compute/radio: ESP32-S3/C3 class module to avoid custom RF matching and simplify certification path.
  • Sensing: Digital I2C temperature/humidity sensor with local decoupling and shared bus pull-ups.
  • User/debug: USB programming, boot/reset controls, status LED.
Interfaces and Connections
  • USB-C VBUS, GND, CC1, CC2, D+, D-.
  • 3.3 V power rail to MCU and sensor.
  • I2C SDA/SCL between MCU and sensor.
  • GPIO for status LED, BOOT, RESET/EN.
Power and Runtime Expectations
  • USB powered only; no battery runtime target.
  • Low-power firmware should use modem sleep/light sleep between measurements when possible.
  • Hardware supports WiFi peak current; actual power depends primarily on radio duty cycle.
Power Tree and Power Budget
  • To be maintained in power-budget project file.
  • Preliminary sizing target: support ESP32 WiFi current peaks plus sensor and LED loads with margin.
Manufacturing and Assembly Expectations
  • Consumer-use, SMD production-intent design.
  • Use module-based RF and keep antenna at board edge during layout.
  • Include test points for VBUS, protected 5 V, 3V3, GND, I2C, EN, BOOT.
Firmware-Relevant Hardware Requirements
  • Firmware should initialize USB serial/debug, WiFi station mode, BLE advertising/service, I2C sensor polling, and status LED.
  • Bootloader access via BOOT and RESET/EN controls.
Physical Design Expectations
  • ESP32 module antenna must face outward at board edge with copper/component keepout per module datasheet.
  • USB-C connector should be placed on board edge.
  • T/RH sensor should be away from regulator heat, MCU heat, and copper heat-spreading areas.
Important Design Decisions
  • Use an ESP32 module rather than bare RF IC for lower RF risk.
  • Use USB-C default-current sink behavior, not USB-PD, unless requirements later demand >5 V or negotiated power.
  • Use I2C digital T/RH sensor for low power and simple firmware.
Assumptions
  • SMD assembly is acceptable for consumer-use production intent.
  • USB-C input remains 5 V only; no USB Power Delivery negotiation required.
  • Sensor is intended for indoor ambient air, not sealed or condensing environments.
Change Notes
  • Initial requirements captured from user request.

  • 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