I’m an electrical engineer working at the boundary between hardware and software. My work spans electronics design, embedded firmware, systems integration, test fixtures, and the desktop or web tools that make a system usable and diagnosable.

My route here was not conventional. I spent several years in mid- to high-level IT before moving into electronics as a technician and then into electrical engineering. That background made me comfortable tracing a problem across layers: from a board, harness, or power rail; through firmware and an RTOS; into the tooling, test process, and infrastructure around it.

What I work on

I am especially interested in projects where ownership crosses those boundaries. The interesting failures are rarely confined to one layer, and the best fix is often a better interface, test, or validation plan—not just a code change.

What this site is for

This is a technical portfolio and a working record of how I approach engineering problems. Some posts cover older projects that helped shape the way I work today; others document current work in embedded systems, test, and integration.

I do not want this to be a collection of polished victory laps. When the evidence is incomplete, a design assumption was weak, or a project would benefit from a different architecture today, I will say so. That is not a disclaimer—it is part of the engineering story. The goal is to show the reasoning behind a design, the validation that supports it, and what I would improve with another opportunity.

Current direction

I am building deeper experience as an embedded systems engineer, with a focus on electrical design, firmware, hardware/software integration, and test. I am looking for increasingly complex projects where careful technical judgment, practical troubleshooting, and end-to-end ownership matter.

If you are here to understand how I work, start with the project write-ups. They are where I can be most specific: what I built, what was tested, what I learned, and where I would take the next revision.