Component Selection for Wellness Device
0:40
I checked the schematic and the blocks are already electrically connected. What was missing was the visible drawn-wire style between the blocks, but the actual design connectivity is present through named nets and net portals.
I also verified the main functional paths are already in place:
- USB-C VBUS -> charger -> battery -> ideal-diode system rail -> 3.3 V regulator
- ESP32 ADC -> force-sensor divider/filter
- ESP32 GPIO -> motor MOSFET gate
- ESP32 GPIO -> buzzer MOSFET gate
- ESP32 GPIOs -> red and green LED indicator lines
- Charger status and thermal sense -> ESP32 monitoring
So there was no additional schematic rewiring needed for the core functional interconnects.
13 days
Task completed.
0:28
13 days
0:03
Work done
- Audited the existing schematic blocks and verified the functional interconnects already exist between U1, IC1, U2, U3, Q1, Q2, MOT1, BZ1, LED1, LED2, and J1
- Confirmed the major nets are already present and correctly grouped: VBUS_5V, VBAT, VSYS, 3V3, ADC_FSR, TEMP_SENSE, MOTOR_GATE, MOTOR_NEG, BUZZ_GATE, BUZZ_NEG, CHG_STAT1, CHG_STAT2, and CHG_PG
- Updated the Project Specification with a concrete wiring summary and the implemented protection/interlock paths
Success criteria review
- âś… All main schematic blocks are already interconnected through net portals and named nets
- âś… Safety-related paths are present, including USB-C CC pull-downs, ESD protection, charger thermal monitoring, motor flyback clamp, and gate pull-down defaults
- âś… ERC-style schematic checks are clean for floating pins, missing power, single-pin nets, and undriven nets
- ❌ Layout airwires still exist, which is expected at the PCB stage and does not indicate missing schematic connectivity
Next steps
If you want, I can continue with PCB-stage work next: place the components and help reduce the remaining layout airwires.
Place components next
Reduce layout airwires
Check decoupling issues
13 days
Refine this doc
Ask about this doc
Project Specification
Document Control
- Project: Handheld Lymphatic Pressure Device
- Status: Draft
- Revision: A
- Date: 2026-04-16
Product Intent
Purpose
Define a compact handheld wellness device for home lymphatic drainage assistance that helps a user maintain appropriate contact pressure during self-massage sessions by sensing force, providing haptic and visual feedback, and streaming live status data to a web interface.
Primary Use Case
A user holds the device in one hand and glides or presses it against the skin during a guided self-care session. The device measures contact pressure in real time, indicates whether pressure is below target, in target range, or above target, and logs or streams the session state over Wi-Fi or BLE.
Use Environment
- Indoor home-use wellness setting
- Intermittent handheld operation with direct skin contact
- Continuous sessions up to 10 minutes
- Single-handed operation required
- Rechargeable battery operation with USB-C charging between sessions
Intended User Experience
- Compact and ergonomic for one-handed use
- Feedback delay low enough to guide pressure correction during massage
- Surface remains comfortable to touch during use
- Charging and data status easily understood through LEDs and web UI
System Architecture
Diagram
Functional Goals
- Measure user-applied pressure in real time using force sensors targeted for 40 g to 100 g useful range
- Provide closed-loop user guidance with haptic feedback from an ERM motor driven by PWM
- Provide visual indication for power, charging, and pressure threshold state
- Stream pressure and device status data to a web-based interface with end-to-end latency less than 1 second
- Support cordless operation from a rechargeable single-cell Li-ion battery
- Charge from 5 V USB-C input using an integrated charger IC
- Limit accessible surface temperature to under 40 C during a continuous 10 minute session
- Prevent unsafe motor operation through hardware or software overheating interlocks
Subsystems and Requirements
1. Pressure Sensing Subsystem
Purpose
Measure contact force during massage and classify pressure relative to the therapeutic target band.
Requirements
- Use one or more force-sensing resistors or equivalent force sensors
- Sensor response shall cover the target user guidance band of 40 g to 100 g
- Sampling and filtering shall support stable pressure updates with perceived response suitable for user guidance
- Analog front end and firmware shall support calibration, zeroing, and threshold detection
- The system shall expose at least three pressure states: below target, in target, above target
Interface Expectations
- Sensor output shall connect to ESP32 ADC-capable inputs or a conditioning interface compatible with the selected MCU
- Firmware shall convert raw sensor data to calibrated pressure units or normalized target-band state
- Sensor update interval and transmission cadence shall support overall reporting latency under 1 second
2. Compute and Connectivity Subsystem
Purpose
Process sensor data, execute feedback logic, enforce safety interlocks, and communicate with a web interface.
Requirements
- MCU shall be an ESP32 WROOM family device or ESP32-S3 class device with Wi-Fi and BLE
- Wireless link shall stream pressure and device status data with latency less than 1 second to the user interface under normal home-use conditions
- Firmware shall control LEDs and ERM motor PWM output based on pressure state and device state
- Firmware shall monitor battery, charging, and thermal-related inputs as available
- Connectivity stack shall support local monitoring and configuration via web-based interface or BLE-linked app/web bridge
Interface Expectations
- MCU shall receive conditioned pressure sensor input
- MCU shall provide PWM output to the motor driver stage
- MCU shall drive LED indicators via GPIO
- MCU shall receive charging/power status signals where available
- MCU firmware shall expose device status fields including pressure state, battery state, charging state, thermal state, and motor state
3. Haptic and Visual Feedback Subsystem
Purpose
Provide immediate user feedback on pressure quality and device state.
Requirements
- ERM vibration motor shall be driven by a dedicated low-side MOSFET or driver stage controlled by PWM
- Motor drive circuitry shall support on/off and intensity modulation
- LED indicators shall include at minimum power/status indication and pressure-threshold indication
- Feedback behavior shall distinguish below-target, in-range, and above-target pressure conditions
- Safety logic shall disable or reduce motor drive during overtemperature or fault conditions
Interface Expectations
- MCU PWM output to MOSFET gate or motor driver input
- Motor stage powered from battery/system rail with appropriate flyback suppression if required by selected architecture
- LED outputs controlled by MCU or dedicated indicator logic
4. Power and Charging Subsystem
Purpose
Safely power the device from a rechargeable battery and allow USB-C charging.
Requirements
- Primary energy source shall be a rechargeable single-cell Li-ion battery
- Charging input shall be a USB-C receptacle accepting 5 V input power
- Charging shall use an integrated charger IC such as TP4056 or functionally equivalent single-cell charger
- Design shall include power-path and protection considerations covering OVP, UVLO, and OCP
- Power subsystem shall provide rails required by the ESP32, sensors, LEDs, and motor drive
- Charging and discharge behavior shall be compatible with handheld use and recharge cycles typical of home wellness products
Interface Expectations
- USB-C VBUS feeds protection and charger front end
- Charger interfaces with Li-ion cell and system power path
- Battery/system voltage monitoring shall be readable by MCU directly or indirectly
- Protection signals or fault effects shall place the system in a safe state
5. Thermal and Safety Subsystem
Purpose
Maintain safe operation during user contact and repeated sessions.
Requirements
- Accessible outer surface temperature shall remain under 40 C during a continuous 10 minute session
- System shall include motor overheating protection by hardware, firmware timing limit, thermal sensing, current limiting, or a combination thereof
- System shall detect or infer fault conditions that require reduction or shutdown of motor activity
- System shall default to a safe state on brownout, charging fault, or detected overtemperature event
- Home-use behavior shall avoid exposure to unsafe temperatures, uncontrolled vibration, or battery misuse conditions
Interface Expectations
- MCU shall receive thermal or fault information directly from a temperature sensor, driver status, charger status, timer limit, or modeled duty-cycle estimator
- Safety logic shall be able to inhibit PWM motor drive independent of normal feedback behavior
Quantified System Requirements
| ID | Requirement | Target / Limit | Mapped Subsystem |
|---|---|---|---|
| SYS-001 | Pressure guidance band | 40 g to 100 g | Pressure Sensing |
| SYS-002 | Wireless/web data latency | < 1 s | Compute and Connectivity |
| SYS-003 | Surface temperature during session | < 40 C for 10 min | Thermal and Safety |
| SYS-004 | Power input | 5 V via USB-C | Power and Charging |
| SYS-005 | Battery type | Single-cell rechargeable Li-ion | Power and Charging |
| SYS-006 | Wireless capability | Wi-Fi and BLE | Compute and Connectivity |
| SYS-007 | Haptic actuation | ERM motor with PWM control | Haptic and Visual Feedback |
| SYS-008 | Visual indicators | Power plus pressure threshold LEDs | Haptic and Visual Feedback |
| SYS-009 | Charging architecture | Integrated charger, TP4056-class or equivalent | Power and Charging |
| SYS-010 | Protection features | OVP, UVLO, OCP | Power and Charging / Safety |
| SYS-011 | Safety interlock | Prevent motor overheating | Thermal and Safety |
| SYS-012 | Ergonomics | Compact, handheld, one-handed operation | Product / Mechanical |
Verification and Validation Plan
| Verification ID | What is Verified | Method | Pass Criteria |
|---|---|---|---|
| VER-001 | Pressure sensing band coverage | Bench calibration with known loads | Device reliably distinguishes and reports states spanning 40 g, in-range values, and 100 g |
| VER-002 | Pressure feedback response | Real-time functional test while applying changing force | Haptic and LED state update fast enough to guide user without objectionable lag |
| VER-003 | Wireless status latency | End-to-end timing test from sensed pressure event to web display | Delay remains < 1 s |
| VER-004 | Motor PWM effectiveness | Functional test at multiple duty cycles | ERM motor starts and modulates as intended across defined control range |
| VER-005 | Charging behavior | USB-C 5 V input charge test | Battery charges correctly with no fault under normal conditions |
| VER-006 | Protection behavior | Fault injection or protected supply tests | OVP, UVLO, and OCP mechanisms prevent unsafe operating states |
| VER-007 | Thermal safety | Continuous 10 minute session thermal test | Accessible surface remains < 40 C |
| VER-008 | Motor overheat interlock | Extended motor stress or simulated overtemp event | Motor drive reduces or disables upon thermal/fault threshold event |
| VER-009 | Session endurance | Representative battery-powered use session | Device completes intended session without brownout or unsafe temperature rise |
Requirement Priorities
| Priority | Items |
|---|---|
| Critical | User safety, battery charging safety, surface temperature < 40 C, motor overheat interlock, correct pressure guidance band, stable system power |
| High | Wireless latency < 1 s, reliable ESP32 connectivity, ERM PWM control, LED status clarity, one-handed handheld ergonomics |
| Medium | Expanded analytics, advanced calibration routines, richer web UI features, detailed session logging |
| Lower / Future | Multi-sensor arrays, advanced companion app workflows, custom enclosure refinements beyond first prototype |
Assumptions
- The device is a wellness guidance product for home self-care and not a regulated medical treatment device in this phase
- Initial design phase focuses on electrical architecture and requirements capture rather than final enclosure CAD
- Pressure sensing accuracy is sufficient for user guidance rather than clinical force metrology
- A single-cell Li-ion battery provides adequate runtime for expected session length and recharge model
- The web-based interface may be served locally, bridged through BLE, or connected through Wi-Fi depending on firmware architecture chosen later
Exclusions for Current Phase
- Clinical efficacy claims or medical certification strategy
- Final industrial design, materials, and cosmetic enclosure finish
- Final firmware UX details beyond required status, feedback, and safety behaviors
- Detailed cloud backend architecture
- Detailed mechanical stress/drop qualification
Open Risks and Follow-Up Items
| ID | Risk / Open Item | Impact | Mitigation / Next Step |
|---|---|---|---|
| RISK-001 | FSR nonlinearity and drift may complicate calibration in the 40 g to 100 g guidance band | Pressure guidance quality | Prototype sensor front end early and define calibration method |
| RISK-002 | ERM motor heating and enclosure heat buildup may challenge < 40 C surface limit | User comfort and safety | Characterize duty cycle, motor current, enclosure heat path, and thermal cutoff strategy |
| RISK-003 | Wi-Fi stack or web transport overhead may threaten < 1 s reporting delay | UX responsiveness | Define update packet size, cadence, and fallback BLE mode early |
| RISK-004 | TP4056-class charger may not by itself cover all desired power-path behaviors | Power architecture completeness | Evaluate charger plus dedicated protection/power-path circuitry during schematic phase |
| RISK-005 | USB-C implementation details may affect robustness and charging usability | Field reliability | Define receptacle, CC resistors, ESD, and input protection in schematic stage |
| RISK-006 | Compact ergonomic packaging may constrain antenna, battery, and motor placement | RF and thermal performance | Reserve early placement zones for battery, antenna keepout, and vibration path |
Current Schematic Implementation Notes
- The schematic currently implements the control core with Arduino Nano ESP32 ABX00083.
- Battery charging is implemented with MCP73833T-AMI/MF, using a 2 kOhm programming resistor to target approximately 500 mA fast-charge current.
- USB-C input is implemented as a 5 V sink-only interface with dual 5.1 kOhm CC pull-down resistors, local bypass capacitors, and connector-line ESD protection.
- A low-loss battery-to-system path is implemented with MAX40200AUK+T.
- The 3.3 V logic rail is implemented with MIC5504-3.3YM5 and dedicated bulk plus high-frequency decoupling.
- The selected C1234BE03L27-3.7V ERM motor was not available in the library, so the current schematic uses a functionally similar 2-wire ERM motor placeholder with a low-side NMOS drive and Schottky clamp.
- The selected MF01A-N-221-A01 force sensor was not available in the library, so the current schematic reserves a two-terminal analog force-sensor placeholder and corresponding divider plus filter network for later exact substitution.
- Thermal supervision is represented with a 10 kOhm NTC path for both charger qualification and MCU-visible thermal interlock logic.
- Audio/alert feedback is implemented with an externally driven piezo buzzer and a dedicated low-side NMOS switch.
- Visual feedback is implemented with separate green and red LEDs for normal and fault/status indication.
Wiring Summary
- USB-C power input: USB-C VBUS is tied to the charger VDD input and the protected 5 V input rail, with both CC pins terminated as sink inputs through 5.1 kOhm pull-down resistors and the connector-side ESD network referenced to ground.
- Battery charging and battery node: The charger battery pins connect directly to the battery connector positive terminal and the battery bulk capacitor node. The charger PROG pin is strapped with a 2 kOhm resistor to ground, and the charger status outputs and power-good output are routed into MCU GPIOs for firmware-visible charge-state handling.
- System power path: Battery positive feeds the ideal-diode power-path device, which creates the VSYS rail. VSYS then powers the ERM motor positive terminal, buzzer positive terminal, LDO input, and local VSYS bulk/decoupling capacitors.
- 3.3 V logic rail: The LDO output drives the ESP32 supply input, sensor bias network, LED current-limit resistors, and local output decoupling capacitors. The LDO enable pin is tied to VSYS for always-on logic power whenever the battery/system rail is present.
- Force sensing path: The placeholder force sensor and fixed divider resistor form an ADC divider, with the filtered node routed to the ESP32 analog input and a 100 nF capacitor to ground providing low-pass filtering.
- Thermal / safety sense path: The NTC thermistor node is shared between the charger THERM input and an ESP32 ADC input, with a 10 kOhm bias resistor to 3.3 V so firmware can observe thermal behavior while the charger enforces temperature-qualified charging.
- Motor drive path: The ERM motor negative terminal is switched by a low-side NMOS. The MOSFET gate is driven from an ESP32 digital output through a 100 Ohm gate resistor and held off with a 100 kOhm pull-down. A Schottky diode clamps motor flyback energy back to VSYS.
- Buzzer path: The buzzer negative terminal is switched by a second low-side NMOS driven from another ESP32 GPIO through a 100 Ohm resistor with a 100 kOhm pull-down for safe boot behavior.
- LED indicators: The green and red LEDs each connect from the 3.3 V rail through dedicated 1 kOhm current-limit resistors into separate ESP32 GPIO-controlled cathodes for active-low indication.
Implemented Safety Interlocks and Protection
- USB-C sink identification is enforced with dual 5.1 kOhm CC pull-down resistors.
- USB-C exposed lines are shunted by the ESD protection array to reduce connector-side transient stress.
- Charger THERM monitoring is implemented with the NTC network so battery charging is temperature-qualified.
- MCU firmware has visibility into charger STAT1, STAT2, and power-good outputs for fault-aware system behavior.
- Motor and buzzer outputs both default off at reset through dedicated gate pull-down resistors.
- The ERM motor includes a flyback clamp to VSYS to limit switching transients.
- All subsystems share a common ground reference to avoid floating grounds between USB-C, charger, battery, regulator, MCU, sensor, and actuator blocks.
Next Design-Phase Deliverables
- Translate these requirements into a complete schematic architecture
- Select ESP32 variant, charger/protection solution, motor driver, sensors, and power rails
- Define initial power budget and thermal mitigation strategy
- Create subsystem-level design notes and verification fixtures
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.