USB C WiFi BLE Sensor Node
Worked for 7 mins 17 sec
Created 4 project docs
Design Notes — USB-C WiFi BLE Environmental Node
Input: USB-C receptacle J1, 5 V sink-only, USB 2.0 D+/D- routed to ESP32-C3 native USB Serial/JTAG. USB-C configuration: R1/R2 = 5.1 kΩ Rd f...
Firmware Starter — ESP32-C3-WROOM-02-N4
MCU/module: ESP32-C3-WROOM-02-N4 Framework: Arduino on PlatformIO
Board Bring-Up Plan — USB-C WiFi BLE Environmental Node
Equipment: current-limited 5 V USB supply or USB power meter, multimeter, oscilloscope, USB-C cable, ESD-safe workstation, PlatformIO firmwa...
Technical Construction File — USB-C WiFi BLE Environmental Node
Draft, schematic-stage. FCC Part 15 intentional radiator integration using pre-certified module conditions.
Implemented the schematic for the USB-C powered Wi‑Fi/BLE temperature/humidity node and created the supporting project files:
Open items:
- PCB layout has not been started yet; airwires are expected until placement/routing.
- Generic passives/testpoints still need production MPN assignment before manufacturing export.
- Layout must enforce ESP32 antenna keepout and keep the SHT40 away from heat sources.
Suggested next steps:
- Set board size/stackup and antenna/sensor placement constraints.
- Place components with the ESP32 antenna at the board edge.
- Route USB, buck power, and I2C nets.
- Assign production MPNs for generic passives and test pads.
Create layout constraints
Assign passive MPNs
Run schematic review
Start PCB placement
Prepare layout intent
Refine this doc
Ask about this doc
Project Specification — USB-C WiFi BLE Environmental Node
Project Overview
Status: Draft schematic in progress.
A consumer environmental sensor node powered from USB-C 5 V. It measures ambient temperature and relative humidity with a digital sensor and reports data over Wi-Fi and Bluetooth Low Energy using a low-power ESP32-class radio module.
Intended Use
- Indoor consumer environmental monitoring.
- Powered from USB-C chargers, hubs, or ports providing default 5 V sink power.
- Prototype-to-production-intent design with consumer safety and RF compliance considerations.
What the Device Should Do
- Accept 5 V power from a USB-C receptacle in sink/device mode.
- Tolerate common 0.5 A to 3 A USB-C source advertisements without requiring USB Power Delivery.
- Protect downstream electronics from reverse current, overvoltage, undervoltage, and overcurrent events.
- Generate a regulated 3.3 V rail for the MCU/radio and sensor.
- Measure temperature and relative humidity digitally.
- Communicate over 2.4 GHz Wi-Fi 802.11 b/g/n and BLE 5.x.
- Support firmware flashing/debug over USB or a programming/debug header.
Main Features
- USB-C 5 V sink input with independent CC1/CC2 Rd resistors.
- Protected 5 V input path: ESD/TVS, overvoltage protection, reverse blocking, UVLO, and current limiting.
- 3.3 V low-noise supply for Wi-Fi/BLE radio bursts.
- ESP32-C3/S3 class pre-certified module with integrated antenna.
- I2C digital temperature/RH sensor.
- Reset/boot controls, status LED, and test points.
System Architecture
Diagram
Hardware Subsystems
- Power input: USB-C sink-only default 5 V input, no USB PD negotiation.
- Protection: current-limited eFuse/power switch with OVP/UVLO/OCP/reverse-blocking behavior plus ESD protection.
- Regulation: 5 V to 3.3 V regulator sized for ESP32 Wi-Fi transmit peaks.
- MCU/radio: ESP32-class module supporting 2.4 GHz 802.11 b/g/n and BLE 5.x.
- Sensor: I2C temperature and humidity IC with local decoupling.
- Firmware/debug: USB serial/JTAG or boot/reset controls, plus optional test points.
Interfaces and Connections
- USB-C receptacle: VBUS, GND, CC1, CC2, D+, D-.
- 3.3 V rail: MCU module, T/RH sensor, pull-ups, status LED.
- I2C bus: SDA/SCL with one pull-up pair.
- User/service: BOOT and RESET buttons, status LED, exposed test points.
Power and Runtime Expectations
- Always-powered from USB-C; no battery runtime target.
- Low-power firmware should use modem sleep/light sleep when not actively transmitting.
- Design must survive source capabilities from 0.5 A to 3 A but firmware/hardware should not assume 3 A without CC/current-limit policy.
Power Tree and Power Budget
Table
| Rail | Load | Sleep | Typical Active | Peak |
|---|---|---|---|---|
| 3.3 V | ESP32 Wi-Fi/BLE module | ~10-100 uA configured sleep | ~80-240 mA | ~500 mA radio burst |
| 3.3 V | Digital T/RH sensor | <1 uA standby | <1 mA during measurement | <2 mA |
| 3.3 V | Status LED | 0 mA off | 2-5 mA | 5 mA |
| 3.3 V | Pull-ups/debug leakage | negligible | <1 mA | <1 mA |
Design target: size the 3.3 V rail for at least 600 mA peak. Input path target: at least 1 A continuous/current-limit capability with components rated for 5 V USB-C operation and tolerance of 3 A-capable sources.
Manufacturing and Assembly Expectations
- SMD assembly, consumer-product-oriented.
- Use a pre-certified radio module to reduce RF certification risk.
- Add test points for VBUS_PROT, 3V3, GND, I2C, EN/RESET, and boot/debug signals.
Firmware-Relevant Hardware Requirements
- Arduino/ESP-IDF compatible Wi-Fi + BLE firmware.
- I2C T/RH sensor driver.
- Bootloader entry and reset controls.
- Wi-Fi/BLE status indication.
- Optional low-power mode strategy for idle intervals.
Physical Design Expectations
- Place the radio module antenna at a board edge with full antenna keepout on all layers.
- Keep USB-C connector accessible at board edge.
- Keep sensor away from regulator heat, USB connector heat, and the ESP32 module if possible.
- Provide ventilation/opening guidance for final enclosure.
Important Design Decisions
- Use an ESP32-C3/S3 module rather than a bare RF chip to reduce RF/layout/certification risk.
- Use native USB-capable ESP32 variant if available to avoid an external USB-UART bridge.
- Use a 3.3 V regulator sized for ESP32 radio bursts; consider buck if LDO thermal dissipation is too high.
- Use an eFuse/power switch for combined OVP/UVLO/OCP/reverse-blocking input protection.
Assumptions
- Indoor consumer environment, non-safety-critical sensing.
- USB-C is power input and programming/debug interface; USB PD is not required.
- Compact SMD implementation is acceptable.
- No display, battery, external probes, or enclosure dimensions specified yet.
Change Notes
- Initial specification created from user requirements.
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
