01
Product-ready electronics design
Schematic capture, PCB layout, component selection, BOM cleanup, connector strategy, panelization support, and design choices made with assembly, sourcing, test access, and field reliability in mind.
Systems Analysis · Electrical Design · Embedded Products
I turn unclear technical problems into electronics that can be built, tested, and trusted.
I am a systems analyst turned electrical design engineer. I see the whole product: requirements, power, PCB layout, firmware behavior, BLE/device interfaces, production test, user behavior, and the bench evidence that tells you what is actually happening.
Ambiguity → test planUnclear symptoms become knowns, unknowns, measurements, and next actions.
Encapsulate + substituteIsolate the unknown, emulate the boundary, prove one layer at a time.
Concept → productionDesign decisions stay tied to build, test, support, and field behavior.
What I bring
Electrical engineering grounded in systems analysis: the ability to understand the full breadth of a product, isolate the real failure mode, and push through until the result is buildable and defensible.
02
Firmware that respects the circuit
ESP32, AVR/ATmega, BLE products, low-power sleep behavior, RTC-based timing, peripheral drivers, production diagnostics, and firmware structured around how the hardware actually behaves.
03
Systems analysis applied to electronics
Requirements decomposition, signal-path tracing, failure-mode thinking, dependency mapping, substitution tests, measured troubleshooting, and closed-loop validation before parts or code get blamed.
Systems analysis turned electrical engineering
I understand the full breadth of the system.
My advantage is breadth. I think in interfaces, dependencies, constraints, failure modes, and evidence. That lets me move from the customer-facing symptom down through electronics, firmware, mechanical assumptions, test process, and production workflow without losing the real objective.
I turn ambiguity into a test plan.Vague reports become knowns, unknowns, measurements, controlled changes, and verification criteria.
I use encapsulation and substitution.Define the boundary, substitute known-good behavior, emulate inputs, and prove one interface at a time.
I connect hardware to firmware.Current draw, timing, GPIO states, BLE behavior, diagnostics, and visible product behavior are treated as one system.
I push through to a defensible result.The fix has to be repeatable, documented, and strong enough for production or the next engineer to trust.
How I solve hard product problems
Encapsulate the unknown. Substitute the known. Verify the result.
Most product problems do not stay politely inside one discipline. A firmware symptom may be a power issue. A production failure may be a fixture assumption. A PCB change may be a field-support decision. I keep those connections visible until the real cause is proven.
Reduce the unknownsI break vague symptoms into signals, states, interfaces, assumptions, and measurements that can be tested.
Encapsulate and substituteI isolate one layer, substitute known-good behavior, emulate inputs, and prove each boundary before moving on.
Verify before calling it doneThe result has to be repeatable, documented, and defensible enough for production, support, or the next engineer.
Proof points
Areas where systems analysis, electrical design, embedded firmware, and production discipline come together.
Battery-powered inspection products
Annual inspection indicators and similar embedded devices where the success criteria are long service life, predictable wake/sleep behavior, RTC scheduling, GPIO state retention, and battery budgets that survive real-world use.
ESP32RTCLow powerField behavior
Production test and board bring-up
Bench workflows, LED/test fixtures, firmware diagnostics, signal verification, acceptance criteria, and the practical checks that turn “it worked once” into a repeatable production result.
DFTFixturesDebugManufacturing
BLE-connected embedded controls
Connected device behavior, BLE service design, shell/debug commands, callback-driven hardware control, and reliability expectations that continue after the first connection succeeds.
BLEMCU callbacksDiagnosticsReliability
Engineering automation and CAD/BOM cleanup
BOM cleanup, CAD/CAM handoff support, panelization workflows, firmware tooling, and scripts that turn repetitive engineering work into controlled, auditable processes.
C/C++PythonFirmware toolingBOM/CAD workflows
Representative engineering wins
Public-safe examples of the value I add without exposing proprietary product details: turning messy product risk into clear engineering action.
01
Low-power product architecture
Translated a long-service-interval product requirement into a low-power embedded architecture involving RTC scheduling, deep sleep behavior, state retention, and component-level current analysis.
02
Connected-device behavior
Separated BLE communication concerns from product-specific hardware behavior so commands, callbacks, diagnostics, and device actions could be tested and reasoned about independently.
03
Legacy embedded system recovery
Reconstructed and stabilized embedded behavior from hardware observations, UI references, input/output mapping, EEPROM defaults, and measured device behavior.
04
Production-ready validation
Built test and bring-up thinking into the product path so “it works” became repeatable evidence: fixture checks, firmware diagnostics, acceptance criteria, and hardware-visible verification.
05
Manufacturing handoff discipline
Improved the handoff between design and production through BOM cleanup, CAD/CAM preparation, panelization support, and supplier-consumable documentation.
06
Systems-analysis debug method
Applied encapsulation and substitution to complex product failures: isolate the boundary, substitute known-good behavior, test one variable, and verify the result before moving on.
Available for select consulting, prototyping, and design-review work
If the problem crosses hardware, firmware, production, and people, I can help make it solvable.
Good fit: embedded hardware and firmware reviews, prototype planning, PCB/BOM sanity checks, board bring-up strategy, production test criteria, and cross-discipline debugging where the expensive mistake is assuming the problem belongs to only one part of the system.