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.
Where I fit
Embedded products that are too cross-disciplinary for a narrow specialist.
Good fit for teams where hardware behavior, firmware behavior, test strategy, production constraints, and user-visible symptoms all affect the outcome. I help turn that messy middle into measurements, decisions, and a buildable path forward.
Problems I help solve
These are the situations where systems-analysis-driven electrical engineering matters most.
✓
A prototype works once but cannot be repeated reliably.I help separate luck from proven behavior with controlled bring-up, measurements, and pass/fail criteria.
✓
Battery life is worse than expected.I trace the current budget across regulators, peripherals, wake sources, firmware states, leakage paths, and real duty cycle.
✓
A firmware symptom may not be a firmware problem.I follow the failure across power, timing, signal integrity, PCB assumptions, firmware logic, fixtures, and operator workflow.
✓
A design needs to move from bench prototype to production-ready build.I connect design intent to BOM quality, test access, firmware diagnostics, fixture strategy, and supplier-ready handoff.
✓
Engineering files and expectations are too messy for clean handoff.I turn scattered requirements, board notes, CAD/BOM outputs, firmware behavior, and test expectations into a controlled evidence trail.
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.
My operating method
A simple discipline for keeping complex embedded-product problems honest.
Define the system boundary.Identify what is inside the problem, what is outside it, and which interface needs to be proven first.
Separate knowns from assumptions.Keep measurements, observations, requirements, and guesses visibly separate so the debug path stays defensible.
Substitute known-good behavior.Emulate inputs, bypass uncertain layers, or force controlled states so one boundary can be tested at a time.
Measure one variable at a time.Make changes small enough that the result teaches something instead of creating a new mystery.
Tie the fix back to product risk.A correction matters when it improves battery life, reliability, manufacturability, supportability, or user-visible behavior.
Leave evidence the next person can trust.Document what was verified, what remains unknown, and how to repeat the result.
Proof points
Concrete places where systems analysis, electrical design, embedded firmware, and production discipline turn into product value.
Battery-powered embedded devices
Low-power products where service life depends on the whole design: sleep-current budget, regulator quiescent current, wake sources, peripheral shutdown, firmware state, and measured battery draw.
Sleep-current budgetWake-source designPower-state firmwareMeasured battery draw
Production test and board bring-up
Bring-up and test workflows that connect schematic intent to measurable board behavior: fixture strategy, firmware diagnostics, signal verification, and pass/fail criteria.
Fixture strategyFirmware diagnosticsSignal verificationPass/fail criteria
BLE-connected embedded controls
Connected-device systems where GATT design, command routing, connection lifecycle, diagnostics, and hardware abstraction have to remain testable after the first successful connection.
GATT designCommand routingConnection lifecycleHardware abstraction
Engineering automation and CAD/BOM cleanup
Engineering workflow cleanup that makes design data easier to build from: BOM normalization, CAD/CAM handoff, panelization support, firmware tooling, and scripted checks.
BOM normalizationCAD/CAM handoffPanelizationScripted checks
Mini case-study patterns
Public-safe examples of how I frame work: situation, action, and value instead of empty skill lists.
Low-power device architecture
SituationA battery-powered product needed long service life, but success depended on hardware leakage, regulator current, wake behavior, firmware state, and measured duty cycle.
ActionI decomposed the product into power states, current paths, wake sources, peripheral behavior, and firmware responsibilities.
ValueThe battery-life discussion became measurable and testable instead of speculative.
Intermittent embedded failure
SituationA visible product symptom could have come from firmware logic, board behavior, timing, power, or the way the test was being run.
ActionI isolated boundaries, substituted known-good behavior, and verified one signal path or state transition at a time.
ValueThe team gets a defensible cause, not a pile of guesses and part swaps.
Prototype to production path
SituationA design worked on the bench but needed stronger evidence before it could be built, tested, and supported repeatedly.
ActionI connected schematic intent, firmware diagnostics, test access, BOM quality, fixture strategy, and acceptance criteria.
Value“It worked once” becomes a repeatable build and test path.
Representative engineering wins
Examples of the value I add: turning messy product risk into clear engineering action without losing the whole-system context.
01
Low-power product architecture
Translated a long-service-interval product requirement into a low-power embedded architecture involving sleep-current budgeting, wake-source control, state retention, and component-level current analysis.
02
Connected-device behavior
Separated connection behavior from product-specific hardware behavior so commands, 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, configuration 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
Have an embedded product stuck between hardware, firmware, and production?
I can help turn the problem into measurements, decisions, and a path forward. Good fit: embedded hardware and firmware reviews, prototype planning, PCB/BOM sanity checks, board bring-up strategy, production test criteria, and cross-discipline debugging.