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.

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.

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.

Email address ready — mail client opening.