Preface#
This notebook grew out of a need to assemble practical electronics knowledge into a working reference — not oversimplified, not overly theoretical, but pitched at the right level to be productive at the bench and able to scale from quick reminders to deeper explanations depending on what the situation demands.
At the bench, you are always in the driver’s seat.
Regardless of experience level, the moment you are looking at real hardware — powered or unpowered, working or broken — responsibility rests with you. You decide what you are looking at, how to interact with it safely, what assumptions you are making, and whether you understand enough to proceed. Experience changes how quickly patterns are recognized, but it does not remove the need to observe carefully, reason deliberately, and know when your understanding is incomplete.
This EE Notebook exists to support that reality.
It is not a textbook, and it is not meant to be read front to back. It is designed to be entered anywhere. The emphasis is not just on what to do, but on why circuits behave the way they do, what can go wrong, and how an experienced engineer might approach an unfamiliar situation with discipline rather than guesswork.
A major motivation for collecting and formalizing this material was repair — particularly high-power analog electronics such as car amplifiers. These systems can fail in subtle ways, and casual troubleshooting or uncontrolled power-up can easily turn a repairable fault into a smoke-filled basement. This notebook exists to impose structure: understanding circuit topology, forming testable hypotheses, measuring safely, controlling risk during first power-up, and making a solid, defensible attempt at repair before applying full operating conditions.
That same mindset applies equally to design. New builds often stall not because the knowledge is missing, but because it is scattered, implicit, or not connected in a way that makes the next step obvious. Many of my own projects sat on the bench in exactly that state. Formalizing this notebook was partly about unblocking those efforts by organizing the mental models, patterns, and verification steps that bridge idea to working hardware.
This material is written primarily for my own use at the bench, but it is structured so that others can benefit from it as well. Everything here is for educational and practical reference purposes only. Real hardware, real voltages, and real systems can injure people or fail in expensive ways if handled carelessly. Nothing here replaces proper training, safety practices, datasheets, or professional responsibility.
Some portions of this notebook are developed with the assistance of modern AI-based tools used as research aids, writing accelerators, and sounding boards. These tools help with structuring ideas, surfacing edge cases, and improving clarity — but they are not authorities. Not all content has been independently verified in every possible context, and errors or omissions are possible. Final judgment, validation, and responsibility for safe application rest with the human reader — and with me as the author.
The organization reflects how I think about electronics in practice:
- physics first,
- engineered behavior built on top,
- design as the bridge between idea and hardware,
- and measurement, debugging, and repair running through all of it.
This notebook is intended to be my reference nucleus. Over time, deeper dives branch off — focused volumes on specific domains, technologies, and projects — but this remains the center I return to when assumptions need to be reset, context reestablished, and forward motion depends on clarity rather than momentum.
If it helps you do the same, all the better.
— Chris Deever