Rename project, create specification, and record initial requirements/power budget
Select library parts for MCU, T/RH sensor, USB-C input, regulator, and protection
Add main components and supporting passives to the schematic
Wire USB-C power/protection, 3.3 V rail, MCU boot/debug, USB data, I2C sensor, and indicators
Create firmware/regulatory/bring-up project files
Run schematic/design checks and fix actionable issues
Thought for a moment
Planning firmware documentation
I need to create documentation for the firmware starter. Since the SIWG917 isn’t an ESP32, there’s no common Arduino framework here. I’ll use the Silicon Labs Simplicity SDK instead. I might need to write C starter code with the Gecko SDK, which can be tricky to compile. I'll create the main C file, incorporating the em_i2c while using the WiseConnect SDK as well. It’s essential to include SHT4x low-level I2C and consider regulatory documents like the TCF.
Organizing regulatory documentation
I’m wondering if creating four documents might be overkill. What's the minimum regulatory documentation we actually need? It looks like I should produce a top-level Technical Construction File that includes checklists, RF notes, and a block diagram. I also consider adding a Preliminary Safety/FMEA, but given that this device is USB powered and doesn’t deal with mains or battery charging, it might not be needed. I can produce deliverable documents like the Declaration of Conformity and a user manual outline. Overall, I need to create concise
I select parts by matching requirements—electrical limits, interfaces, package, availability, certifications, and datasheet recommendations—against Flux’s component library and verified manufacturer data.
For this project, no additional component search or design edits were completed in this turn, and the project remains in its prior state. Execution stopped because your ACUs ran out.
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
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
Rail
Load
Sleep
Typical active
Peak
3.3 V
Wi-Fi/BLE MCU module
~10–100 µA deep sleep
~80–240 mA radio active
~500 mA short Wi-Fi TX burst
3.3 V
T/RH sensor
<1 µA standby
~0.5–1 mA measuring
~1 mA
3.3 V
Status LED
0 mA off
~2 mA on
~5 mA configured max
3.3 V
Pull-ups/leakage
~1–2 mA worst when lines low
negligible 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.