Project Overview and Technical Analysis
1:55
Considering.
Analyzing the schematic.
Running design review.
Reviewing the bill of materials.
Project overview
How the project works
1. Input power and regulation
Areas for improvement
Electrical improvements
This is a dual-tank water level monitoring and control board built around U1. Its main job is to:
- read two ultrasonic level sensors through J11
- optionally drive four 5 V relay modules RL1, RL2, RL3, RL4
- expose an I2C expansion / display interface through J5 and J6
- provide serial/programming access through J3
- accept a 7 V to 30 V input at J4, then generate regulated 5 V and 3.3 V
So the project is not just a sensor reader. It is really an ESP32-based water monitoring and automation controller.
System architecture
The design breaks into four functional blocks:
Table
| Block | Main parts | Role |
|---|---|---|
| Processing | U1, J1, J2, J3, IO0, EN1, R5, R6 | Main control, firmware, boot/reset access |
| Sensor I/O | J11 | Two ultrasonic sensor interfaces |
| Power | J4, U2, L1, D5, C5, C6, U12, C9, C7, C8, C1 | Converts 7-30 V input to 5 V, then to 3.3 V |
| Outputs / indicators | RL1, RL2, RL3, RL4, LED1, LED2, LED3, LED4, R7, R8, R9, R10 | Relay control and status indication |
The board accepts external supply on J4.
- J4 pin 3 feeds the input of U2
- U2 plus L1, D5, C5, and C6 form the buck converter stage
- that stage produces the 5 V rail
- the 5 V rail powers:
- U12 then generates the 3.3 V rail
- C7, C8, and C1 are placed on the 3.3 V rail as bulk/local decoupling
- C9 is on the 5 V to U12 side
U1 is the central controller.
Its key connections in this design are:
- sensor timing inputs/outputs
- IO19 ->
SENSE_TRIGGER 1 - IO5 ->
SENSE_ECHO 1 - IO27 ->
SENSE_TRIGGER 2 - IO13 ->
SENSE_ECHO 2
- IO19 ->
- I2C
- IO21 ->
I2C_SDA - IO22 ->
I2C_SCL
- IO21 ->
- relay control
- UART
- TXD0 and RXD0 go to J3
Boot and reset handling is simple:
- R5 is a 10 kΩ pull-up on IO0
- IO0 is a pushbutton to ground for boot mode selection
- R6 is a 10 kΩ pull-up on EN
- EN1 is a pushbutton to ground for reset
That gives the board a straightforward manual programming path.
3. Ultrasonic sensing section
The dual-sensor interface is centered on J11, a 6-pin header/socket arrangement.
Mapped signals:
- Pin 1 -> 5 V
- Pin 2 ->
SENSE_TRIGGER 1 - Pin 3 ->
SENSE_ECHO 1 - Pin 4 ->
SENSE_TRIGGER 2 - Pin 5 ->
SENSE_ECHO 2 - Pin 6 -> GND
This means the firmware on U1 can sequence the two sensors independently:
- drive trigger pulse
- measure echo pulse width
- convert flight time to distance
- infer tank level from sensor-to-water distance
The board includes four prebuilt relay modules:
Each relay module has:
- VCC = 5 V
- GND
- IN = logic control from U1
- indicator LED output, mirrored by on-board indicator pairs:
Those resistor values are 4.7 kΩ, so the status LEDs are likely intended as low-current indicators rather than bright panel indicators.
5. Expansion and interfacing
The design includes a few useful interfaces:
These are likely intended for OLED display or other I2C peripherals.
- J3 exposes:
- 5 V
- TXD0
- RXD0
- GND
- GND
- IO0
That is a practical debug / flashing / service header.
Design choices and why they matter
Good choices
Cascaded power architecture
Why it helps:
- relay and sensor loads stay on 5 V
- U1 gets a cleaner 3.3 V rail
- the linear drop across U12 is moderate compared with dropping from 24 V directly
The schematic is logically modular:
- sensing
- controller
- display/I2C
- relay outputs
- power
That makes firmware and troubleshooting easier.
Dedicated control outputs
Assigning separate GPIOs for each relay and each sensor channel keeps the firmware simple and deterministic.
Manual boot/reset support
Trade-offs
Buck + LDO vs all-buck rails
- Pro: U12 can help clean up the 3.3 V rail after a noisier 5 V switching stage.
- Con: U12 burns power as heat, especially if 3.3 V current rises.
- Pro: RL1-RL4 simplify design effort and may already include protection/isolation.
- Con: modular relays increase size, power draw, and usually reduce PCB integration efficiency.
- Pro: L1, C5, C6, C1, C7, C8, and C9 let the concept come together quickly.
- Con: production success depends on final selection of ESR, ripple current, voltage rating, and inductor current rating, which are not fully captured by generic symbols alone.
- stable input supply on J4
- correct switching supply behavior around U2, L1, D5, C5, C6
- adequate 3.3 V regulation from U12
- sensor electrical compatibility at J11
- I2C peripheral compatibility at J5 and J6
The firmware must handle:
- trigger/echo timing for two sensors
- filtering and sanity checking of distance data
- relay control policy
- possible display/UI over I2C
- network connectivity and remote reporting if used through U1
Ultrasonic sensing performance will depend heavily on:
- mounting geometry
- condensation, foam, splashing, and tank shape
- cross-talk between the two sensors
- timing separation between trigger events
If both sensors are triggered too closely together, echo pulses can interfere.
2. Noise coupling
Relay switching and the buck converter can inject noise into the system.
Risk sources:
- U2 switching current loop
- relay coil/transient behavior within RL1-RL4
- shared ground return paths between power loads and U1
This matters because ultrasonic echo timing is sensitive to noisy digital thresholds.
3. Thermal behavior
At higher input voltages, total dissipation can become significant:
If Wi-Fi activity, display current, and other 3.3 V loads rise, U12 may run warm.
4. GPIO and voltage-domain safety
This is one of the most important practical concerns.
The sensor header J11 is powered from 5 V, while U1 is a 3.3 V device. If the attached ultrasonic modules drive echo lines to 5 V directly, those echo nets may require explicit level shifting or input protection, depending on the sensor module actually used.
Potential challenges
| Challenge | Why it matters |
|---|---|
| 5 V sensor echo into 3.3 V logic | Could overstress or misread U1 inputs |
| Power-stage generic parts | Final manufacturable choices for L1, C5, C6, C1, C7, C8, C9 still need validation |
| Relay noise | May disturb sensor timing and wireless reliability on U1 |
| High-input operation | Efficiency and temperature become more important near the top of the 7-30 V range |
| Missing explicit pull-ups on I2C in visible schematic | J5 and J6 may rely on external pull-ups |
| Boot robustness | IO0 and EN handling are manual, so programming/reset workflow is not fully automated |
- Add or verify echo line protection / level shifting between J11 and U1
- Validate the full power stage around U2 with finalized, non-generic passives
- Confirm input/output capacitor voltage ratings for C5, C6, C7, C8, C9, C1
- Add explicit local high-frequency decoupling close to U1 if not already present elsewhere in layout/details not fetched here
- Add clearer external connector labeling for tank 1 / tank 2 functions on J11
- Decide whether J5 and J6 are both required, or whether one standardized expansion port is enough
- Consider adding automatic USB-UART programming support instead of relying mainly on J3, IO0, and EN1
- Add tank calibration parameters in firmware
- add fault detection:
- missing sensor
- out-of-range readings
- stuck echo
- relay state mismatch
- add local alarm outputs or status codes
- add nonvolatile logging and cloud telemetry if desired via U1
Possible next steps:
- support more tanks through additional sensor interfaces or I2C/SPI expanders
- add flow sensing and pump state feedback
- add local display/UI using J5 or J6
- replace modular relays RL1-RL4 with more compact integrated driver circuitry in a later revision
- add surge, reverse-polarity, and fuse protection ahead of J4
- add watchdog and failsafe firmware modes for unattended installations
This board is well suited for:
- household water tank monitoring
- pump automation and refill control
- cistern / reservoir level supervision
- agricultural irrigation storage monitoring
- industrial utility tank telemetry
- IoT water infrastructure dashboards
This is a practical ESP32-based sensing + control platform with:
- dual ultrasonic measurement
- 4-channel relay actuation
- dual-rail power conversion
- I2C expansion
- manual programming/debug support
Its strongest design choice is the combination of monitoring plus control in one board. Its main technical risks are sensor voltage compatibility, power-stage validation, and noise management.
If you want, I can also turn this into:
- a block diagram
- a pin/function map
- a power-tree summary
- or a design review with likely issues and fixes
Show a block diagram
Map every ESP32 pin
Review likely issues
48 days
Refine this doc
Ask about this doc
Project Specification
Version: 0.1.0
Date: ...
Author: ...
Status: ...
Tags: ...
1. Executive Summary
What board we're building and the intended outcome in one paragraph.
...
2. Goals and Non-Goals
What must be true in this rev, and what is explicitly out of scope.
...
2.1 Goals
...
2.2 Non-Goals
...
3. System Overview
High-level description of the system and how the board fits into it.
...
3.1 Block Diagram
A space for a simple block diagram (power + data paths).
...
4. Requirements
What the design must do (behaviorally and electrically), independent of implementation details.
...
4.1 Functional Requirements
...
4.2 Electrical Requirements
Power input, rails, currents, interfaces, sensing accuracy, etc.
...
4.3 Environmental and Reliability Requirements
Operating ranges, expected lifetime, handling constraints, safety/compliance.
...
5. Constraints
Hard limits that shape the design choices.
...
5.1 Mechanical Constraints
Size, mounting, connector access, enclosure interactions.
...
5.2 Power and Thermal Constraints
Power source limits, dissipation ceilings, heat-sensitive components.
...
5.3 Layout / Implementation Constraints
High-level layout rules (keepouts, grounding intent, routing classes), without detailed PCB guidance.
...
5.4 Cost and Sourcing Constraints
Target cost range, availability requirements, preferred vendors/alternates policy.
...
6. Assumptions and Dependencies
What we assume is true, and what the design depends on (parts, standards, external systems).
...
7. Validation Criteria
What “done” means in terms of checks and evidence (not task lists).
...
7.1 Acceptance Tests
...
7.2 Review Checklist
...
Appendix (Optional)
Any supporting urls, analysis, datasets, or taxonomy notes that informed this spec.
...
Welcome 👋
Flux helps you build PCBs faster with an AI teammate!
Create your account to collaborate, stay updated, fork your own version, and get instant answers from our AI agent.