Modern devices have the most interesting parts inside chips, so it's easier on an older device like a 1970s Hi-Fi amplifier. They were designed to be repairable, so they often came with schematics (!) and had corresponding labels on the PCB.
Reverse-engineering a PCB back to a schematic is painful, for the same reason that converting object code back to source code is: the schematic is nicely organized for human comprehension.
For modern commercial products, mostly you'll have some big special purpose ICs plus some minor components for power and noise management. The schematic won't tell you much because all the action is inside the ICs.
Here's something of mine you can look at, a design on Github made with KiCAD. The schematic is here. All the files to make a board are there, and both I and others have had working boards fabbed from those files.
The application is unusual - it's an interface for antique Teletype machines that need signals of 60mA at 120V. There are no off the shelf ICs for that. So there's a custom switching power supply to make that voltage from a 5V USB port. The README file for the project explains how it all works. It has all the extra parts you need in the real world to handle USB hot-plugging, keep the switcher noise out of the USB connection, keep RF noise down, and protect the circuit against a shorted output or a big inductive kick-back from the load.
The data sheet for the LT3750, the controller for the switching power supply, is essential when reading the schematic.
You can download KiCAD and play with the files. You can also download LTSpice and run a simulation; the files for that are in the repository.
This is complex enough to be non-trivial, yet simple enough to be understandable.
The depth and breadth of your knowledge is fascinating. I first replied to a comment of yours here years ago about Nagle's Algorithm.
I've gotten deep into EE lately so this is very helpful to me as well. I didn't even realize who wrote it until I saw the GitHub username.
Just wanted to say thanks for sharing the wisdom.
What we need is a book that does the following: Break down REAL circuits from the wild, explain each module in isolation, then explain how it fits into the larger system. No one does this, not in my 15 years of experience in engineering. It is the same everywhere regardless of the subject, teaching is difficult thing to master. 3Blue1Brown is a rare exception, a unicorn of a guy. Richard Feynman's physics lectures are also an example.
Programming books are littered with content pages that list: 1. Variables, 2. Loops, 3. Conditionals, 4. Strings, 5. Functions, 6. Objects,..I am already asleep. YAWN. This is a wrong way to teach people how to program. I couldn't emphasize it enough. Most people won't remember what all these things are and they'll lose interest as they grind through this mindless mess of syntax that they have never seen before.
Instead programming should be taught by building a goal to automate something. Start out by hard coding everything, then introduce variables. Add functions to make your code modular. Then introduce objects, etc. As you build through a program...a real fricking program! with a real goal!.
That's odd. EE students in any ABET-accredited program should be formally trained to identify discrete analog design patterns like this without the aid of functional outlines. I know I was (even if I don't design analog circuits for a living). It's also standard practice in industry to segement a given system into simpler functional blocks as a first step in any analysis, discrete analog or VLSI alike.
Like an experienced developer who can often infer design intent by looking at a few lines of well written code, so too can a professional analog designer with circuits that look like magic to the untrained eye.
My “one trick” though is that I have a drawer full of different coloured highlighters. When I encounter a “badly drawn” schematic, I pull out the highlighters and start colouring the nodes in the circuit and working through what functions each part may serve. One common thing I’ve seen, which I consider very sloppy, is that a circuit can still be made up of common topologies, but the designer didn’t put a lot of effort into making them look like their textbook versions; they realize “I need 4 resistors, a transistor, and a diode”, plop those down, and then draw wandering connections between them. It’s still correct and functional, but not very ergonomic for the user. Sometimes the parts are a long way from each other with big long nets drawn between them (or worse! Labelled nets that don’t actually draw a full line)
And writing all of this, I’ve realized that it’s exactly the same as code. High cohesion and loose coupling and all that :)
Very true. This is exactly like spaghetti code and very hard to make sense of for somebody lacking experience.
Exactly! As an example, textbooks give the schematic for RC/RL/LC/RLC circuits and their functionality in a isolated manner. But in a real-world product they are amongst a whole other mass of modules and probably drawn badly in a schematic. How do i identify these combinations, infer their input/output and make sense of the overall PCB functionality? I would imagine this knowledge would be most practical and useful in the real-world.
A good source of schematics for learning is often development boards - for example, the BeagleBoard ones - https://beagleboard.org/hardware/design
This YouTube series is quite good if you want to see a very complicated design - it takes you through the schematic/layout of a dual-Xeon server motherboard: https://www.youtube.com/watch?v=FXZJ6jrpIKU
Electronics is much more practical than Software so you'll find that EEs and embedded software engineers take the pragmatic approach of looking at the physical signals to figure out what's happening instead of trying to understand the system from the schematic and first-principles. There's a huge amount of behavior that can only be observed, not anticipated. For example, capacitive coupling between lines on a board only presents itself in the physical PCBA. The schematic isn't going to tell you anything about that.
Think of it this way--the ICs and components are combined like functions in a program on the schematic. They're abstracted as taking a set of input signals and providing a set of output signals. The physical characteristics only make themselves known at the implementation level, which is like the PCBA layout. Even so, you actually have to power the board on or run the program before the performance characteristics and behaviors make themselves apparent.
wat? With software, you can basically probe the workings of a system without affecting it, as well as easily roll back state. Whereas when some rare transient fries several codependent components and desolders a transistor from the board, you're stuck abstract reasoning about what the heck happened, if only to make sure you've actually replaced everything that broke.
FWIW if you have reason to worry about capacitive coupling, you should most definitely have the parasitic capacitance on your schematic, at least the one in your head.
But yes, there is a lot of measuring and not being proven until something is actually built. Heck, many types of circuits can't even be built on an easy medium like a breadboard. But needing to invest more effort means applying more forethought.
They reverse engineer schematics from guitar effects pedal PCBs like this Fuzz Face , then go through the process of breaking the circuit into blocks of operation. They also simulate the circuits such as with this Tube Screamer  and see what effect manipulating component values has on the signal.
Often there are also evaluation board and they usually have some particularly interesting datasheet, because they are quite minimal but exhaustive.
Open-source electronic projects usually are very instructive.
EDIT: And tended to by the great people at archive.org https://archive.org/details/manuals-nationalsemiconductor
I had the very same problem in software dev - I knew how to code, I knew how to read source code, but I had no clue how I should structure my program, build an architecture, etc. And yes, while there are books which will talk you through certain architectures, you still need to acquire an understanding on a much broader base. You might not want to structure your bread-and-butter software in a way the linux kernel is structured, for example - for reasons that become obvious once you've gathered enough knowledge to understand why certain things are working the way they are working.
So I just kept practicing stuff, kept reading pattern books, kept reading source code - and tried to find the patterns I learned. Also, I tried to read a lot of "post-mortems" of failed and successful projects, so that I could get a clue what works and what doesn't. At the end, though, I got most of the knowledge while actually building programs and failing at them.
I'm pretty sure there is something like "patterns" in electronics. It might make sense to dig books that resembles these. While I'm not that knee-deep into electronics, I think you might be able to recognize certain patterns after a lot of practicing.
My advice would be: Grab an easy to understand electronic device, disassemble it, and try to rebuild the schematic with your components. You might want to start with your radio clock, for instance. This would be how I'd acquire the skills necessary. You didn't mention your existing skill set, so replace "radio clock" with whatever you think might work for you.
However, keep in mind that you are a) a single person and b) have only a certain amount of time at hand. I wouldn't expect a hobbiyst to decipher and fully rebuild a modern, high-tech device. Also, to keep yourself motivated, you might want to set smaller milestones.
Maybe digging through some repair guides could help? E.g.: http://www.industrial-electronics.com/Diagnose-Repair-Elec_0... or https://www.amazon.com/How-Diagnose-Everything-Electronic-Se... ?
Oh, and: Once you are done, write a book about it. Maybe you just discovered a niche that isn't filled yet. :)
(sorry for that wall of text, it grew while writing)
> Acquiring skills usually means: practicing, practicing and practicing.
I really disagree with this much repeated simplistic prescription. This is sort of a pet peeve of mine and so let me elaborate. "Mindless" practice is worse then useless. You need full involvement of your mind asking the What/Why/How and building a mental framework as you practice else you cannot build on what you learn. As an example, note all the time wasted by students solving Maths problems using the "plug and chug" method. Another example is the vast army of Arduino programmers doing "copy & paste" programming. Both have their places but you cannot really grow with such an approach. The right way to Practice is what the researcher Anders Ericsson calls as "Deliberate Practice" in his book "Peak: Secrets from the New Science of Expertise".
One of my favourite quotes (from Chinese Martial Arts) that i periodically remind myself of goes;
"To show one the right direction and the right path, oral instructions from a master are necessary, but mastery of a subject comes only from one's own incessant self-cultivation".
There is a lot to unpack and learn from the above deceptively simple quote.
"The original words are: the master leads the door, and the practice depends on the individual."
Right, that's what i have now realized. It is very similar to how the MCU code is written; you take the vendor's sample code for all its boilerplate stuff and "fill in the blanks" with your custom logic.
It’s great that I know what several flavors of resistor look like. Fine. But how do I know this circuit blinks lights in succession and that one produces a sine wave?
Most commonly, the guy disassembles a device, reverse engineers it, and then explains the circuit to you. The concept is this-- he said when he was apprenticed he learned a tremendous amount about electronics from watching his masters work. And that in this day and age, that system does not exist anymore.
I've learned more from his channel than two years of EE I took at a UC.
So, not quite what you're asking for, but
Have a read of this: http://research.cs.tamu.edu/prism/lectures/mbsd/mbsd_l16.pdf
And watch this video: https://www.youtube.com/watch?v=4dWNP6igNCY
Then look at this circuit diagram and create a memory map for the ram from it. https://github.com/jefftranter/68000/blob/master/TS2/v2/ts2....
I'm using this example because it's genuinely complex, but simple enough that you should be able to get it.
Other people have mentioned the 555, and that's a nice IC to experiement with because they're cheap and simple and versatile and you can see the output easily with any oscilloscope you buy.
I made the mistake of thinking I can also do some TV repair myself until I realised of the dangerous voltages floating about inside the TV.
This is similar to the what Louis Rossman is doing with his Youtube videos repairing Mac but without the cussing and the attitude.
These days, I doubt if any of these type of magazines are being published any more.
Yep. Unlike the popular belief, it's not the high voltage in the tube, which can be easily discharged, the real danger comes when you need to probe the live circuit.
Similar thing in digital world is trying to understand simple ICs like, operation amplifiers, TTL logic, SMPS control circuits at the low level.
The final question of their end of course exam involves reading a real schematic for a real product and answering questions about it (I won't say what product, because they are still running the course).
Quite tricky and very satisfying to work out.
Other reasons I enjoyed the course: excellent virtual lab tools, and side lectures from Gerald Sussman.
I was happily surprised to read about Thevenin/Norton rules to turn sub-circuits into a virtual ESR element. Very tree recursive.. very interesting.
Thevenin and Norton equivalence is the stuff of circuits 1. It wouldn't be appropriate to introduce this tool in e-circuits 1, where the primary focus is analysis of primitives like the diode, BJT, FET, and op amp.
Likewise, the digital side of the house has concepts like sum-of-products/products-of-sums, K-maps, and builds primitive logic gates/flip flops up into SSI, MSI, LSI and VLSI abstractions. It wouldn't make sense to introduce these concepts in courses which focus on analysis of LTI circuits.
The tools at an EE's disposal for handling complexity abound; the above examples barely scratch the surface. Context and practice are the keys to retention, and I would posit that a single course which attempts to teach a smorgasbord of them across various sub-domains has little value if only that students would struggle to discover their relevance. As it stands, many students already struggle to see why the Laplace transform might be introduced in a first course in ordinary differential equations.
1) Ask yourself: what's the application? What should this board be capable of doing? If you can't answer this question from the start, it's much more difficult to frame further analysis.
2) Ask yourself: what are the inputs? What are the outputs? You don't need to analyze them in detail immediately; focus on the enumeration. USB or UART? I2C or SPI? Switches or plugs? Get a model in your head (or on paper) of what protocols will be sent to and from the board.
3) Ask yourself: what are the most important elements of the board? You're usually looking for schematic blocks with lots of pins. Identify what those blocks are and what their purpose is.
4) Ask yourself: where does the energy come from? How are the board's components getting powered? If the power system doesn't work, nothing will, so it pays to understand this sooner rather than later. Enumerate the power rails. Are all rails coming from off-board, or are there power supplies on-board? If the latter, where does they get their energy from, and where does it go to?
5) Ask yourself: where do the input and output pins go to? Think of how information propagates through the board.
If you've followed these steps, you should be able to describe the functional operation of the board and understand why large components are generally connected the way they are.
Inevitably, you'll encounter smaller, "discrete" elements like resistors, capacitors, inductors, diodes, transisors, ferrite beads, and more oddities which may leave you perplexed. Sometimes, these will be included as required supporting circuitry for an IC, so it may pay to dig through the datasheet and look for recommended layouts and required circuitry. Sometimes, these elements are used to improve a design in a particular way (pullup/pulldown resistors, voltage divider resistors, decoupling capacitors, debouncing capacitors, DC-filtering capacitors, and many more). I'll provide some basic ways to identify the ones I've listed above.
- Pullup/pulldown resistors: often connected to a trace carrying data. Ensures the trace isn't left in a "floating" state. One end on trace, the other on VCC (pullup) (if DC signal, will be same voltage as line voltage) or GND (pulldown). Typically ranges from 1k-10k ohms but may leave this range, depending on your requirements.
- Voltage divider resistors: a cheap way to get a lower voltage. Imagine two resistors connected in series. Something is hooked up to the connection between the two resistors. One resistor is often hooked up to VCC, and the other is often hooked up to GND. The voltage divider formula will tell you what the voltage is between the two resistors.
- Decoupling capacitors: typically located near where things are happening (input, output, IC). The idea is that they act as local energy buffers. For an IC, this means it doesn't always need to reach all the way to the battery or supply for juice; it's got some nearby. This is the "decoupling." Expect 0.1uF - 10uF values. For certain applications, different types of caps (tantalum, electrolytic, film, ceramic, etc.) may be used to improve frequency response, so keep an eye out for groups of caps of different values.
- Debouncing capacitors: usually used for cheap input devices like certain pushbuttons. One end of the cap is on the input line, and the other is connected to GND. Springiness in the input device can cause the contact to imperfectly connect and fluctuate the line voltage, creating an undesirable AC component to the signal. These caps reduce sensitivity, so you're probably going to see caps around the 10pF range.
- DC-filtering capacitors: the compliment to the debouncing cap. Often seen on antenna lines. In these situations, you care most about the signal's AC component rather than the DC. The cap will be found bridging the signal line. The specific value will vary based on your application.
Ultimately, there are many little things you'll need to learn, especially on complex boards. However, I hope this information gives you a mindset by which you can begin to approach even the most complex boards.