I am actually quite disappointed with sites/books which talk about circuit "schematics". They are all too basic. What i am looking for is a book which a) Will take a non-trivial schematic for an actual product and walk me through deciphering it b) Will show me a actual PCB and derive its schematic from it. This is kind of like trying to understand the architecture of a system given its codebase and documentation. While there are lots of books which walk you through understanding software (eg. Linux Kernel) i have not found one which will do the same for electronic schematics. As a person self studying Embedded/Electronics systems, i find this a big drawback for real-world understanding. Perhaps some experts here can chime in with suggestions on how i can acquire such a skill.
back
21 comments
I learned to read schematics by doing it. It helps to have the schematic, a working device, and an oscilloscope so you can probe waveforms on the PCB in locations that seem interesting in the schematic.
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.
I actually had a project where i was given a) Prototype PCB for driving a pump (status unknown, no software for the MCU) b) A badly done schematic with no proper functional delineation c) Gerber files and asked to make it all work. I had to quickly ramp up on basic Electronics (am a software guy with no EE/Electronics background), learn to read the schematic, identify the inputs/outputs, map them to the requisite pins on the MCU and program it accordingly. While i did write the MCU firmware and got everything to work by myself (pat on back :-), the process was frustrating. No doubt much of it was standard "learning process" due to my lack of knowledge/experience but i was distinctly annoyed at my difficulty in understanding the schematic and mapping it to the components on the PCB for effective debugging. And of course, some of the component values on the schematic did not match the ones on the actual PCB leading to more painful debug sessions. It was "trial by fire" and i am happy to say that i passed, if i do say so myself. But still a very long way to go to catch-up with the industry professionals :-)
"The Art of Electronics", by Horowitz and Hill, is a respected textbook for this. The ARRL Handbook has many explained schematics for radio.
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.[1] The schematic is here.[2] 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.[3]
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.
[1] https://github.com/John-Nagle/ttyloopdriver [2] https://raw.githubusercontent.com/John-Nagle/ttyloopdriver/m... [3] https://www.analog.com/media/en/technical-documentation/data...
John,
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.
Thank you and appreciate your pointing me to a project that i can learn from. While i agree that modern-day PCBs often have their magic inside an FPGA/ASIC/MCU, the overall system is still defined by the PCB. If something doesn't work and i suspect the problem isn't in the software, then i should still be able to understand the schematic and follow the signals in the PCB at appropriate points to debug the problem. While there are lots of "hardware hacking" info, i can see no systematic approach to the problem. Perhaps with more study and practice i will learn to identify the key areas to look for and understand.
I would wholeheartedly second 'The Art of Electronics'---it is a perfect book to start with. I would add 'The art of designing analog chips' by Camenzind (the inventor of the 555 timer) and 'Multistage Transistor Circuits' (SEEC, vl 5). The last book is a good introduction into the design portion of the process. If one feels particularly adventurous, reading old Bob Pease's columns in ED is also educational.
I'm tinkering with electronics and am finding The Art of Electronics very good. At the same time, I'm going through "Practical Electronics for Inventors" - for non-advanced topics it basically covers the same information as The Art of Electronics but in more of an informal/intuitive style than even the decidedly informal Art.
I found "Designing Embedded Hardware by John Catsoulis" quite good in addition to the above two.
So cool: I have a pet project where I hope to use a Type 28 reperforator and had your repo starred for this. Small world.
You don't need that for a Model 28; it only needs 20mA, and you can still buy 20mA current loop interfaces. It's the 60mA machines, where the current loop directly powers the selector magnet, that need this.
I totally agree with you. There is a deeper problem I think across the board, whether it is electronics books or programming tutorials, mechanical engineering, etc. For example, no one teaches you the way you see in this particular segment of an old EEVBlog episode [1]. Please watch this clip as Dave dives deep into how a simple 555 chip works at the transistor level, breaking down into modules and explaining how each module works.
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!.
> For example, no one teaches you the way you see in this particular segment of an old EEVBlog episode [1].
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.
Maybe I’m not experienced enough, but my ability to do that successfully and rapidly varies dramatically based on a very subjective “how good the schematic was drawn”. Some schematics I look at an easily identify “that’s an input diff pair with current mirrors”, “that’s the gain stage”, “that’s an AB biased output stage”, etc etc. And some are... inscrutable.
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 :)
>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
Very true. This is exactly like spaghetti code and very hard to make sense of for somebody lacking experience.
>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.
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.
What about 'The Art of Electronics', by P.Horowitz and W.Hill? Not only it goes through many real circuits and systems, it has questions like: 'What is wrong with this circuit?' at the end of every chapter. It is a bit light on math (which in my view is a weakness) but has a lot of engineering insight.
More serious designs are basically the same as what's said here, it's just spread over more pages. You often have special labels that designate that it's connecting to something on a different page, or hierarchical/multi-channel blocks which can be confusing because there isn't really a standard way of showing that, so it's often vendor specific. You get used to the main ones after a while though (Mentor Graphics Pads/Xpedition, Cadence Allegro, and Altium).
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
Reading a schematic is a lot like reading a table of contents. It tells you what to expect on the PCBA but it doesn't tell you much about how the PCBA actually performs.
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.
> 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
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.
A Schematic is far more than a simple ToC. It gives the complete "static" structure of a system. It should allow me to identify/map major modules/components on the PCB and make some sense of it before even i turn on the system and probe it to identify "runtime" behaviour.
If you're interested in analogue electronics then you might like the analyses done on the ElectroSmash website. [1]
They reverse engineer schematics from guitar effects pedal PCBs like this Fuzz Face [2], then go through the process of breaking the circuit into blocks of operation. They also simulate the circuits such as with this Tube Screamer [3] and see what effect manipulating component values has on the signal.
[1] https://www.electrosmash.com/ [2] https://www.electrosmash.com/fuzz-face [3] https://www.electrosmash.com/tube-screamer-analysis
As an hobbyist, I find that datasheets usually provide this kind of understanding. They often contain a section called "typical application circuit", (if they don't that's a good sign you shouldn't be using the chip anyway).
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.
Another great source of similar understanding are the old National Semiconductor databooks. Those have really useful app notes and datasheets. By now most are yellowed and pages slipping out but still lovingly tended by the people who acquired them, or their successors.
EDIT: And tended to by the great people at archive.org https://archive.org/details/manuals-nationalsemiconductor
Right, that's what i finally figured out too.
Acquiring skills usually means: practicing, practicing and practicing.
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)
While i agree in general with your post;
> 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.
原话叫：师傅领进门，修行靠个人
Google Translate :
"The original words are: the master leads the door, and the practice depends on the individual."
Two things:
- When you do actual product design, a lot of it is basically copy&paste from example circuits in data sheets. Over time you learn to recognise common patterns. The "trick for young players" though is that often the data sheet examples omit "obvious" aspects that should be added for real-life applications.
- You can find schematics of real-life products in "service manuals", though they are much less common now than in the past. A really good exercise would be to take the schematics of a consumer product like an iPhone (they can be found... either copied from service manuals or reverse engineered), and look up the data sheet for each component (sometimes it will be a similar component from the same manufacturer as Apple will be assigned custom part numbers), and try to understand why it was used in the product the way it is shown on the schematic, based on the information in the data sheet.
> When you do actual product design, a lot of it is basically copy&paste from example circuits in data sheets.
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.
I agree. While nice, this article is like a “how to read a program” article that lists the language’s keywords and what they mean, and stops at that.
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?
Here's an open source project you can sink your teeth into:
May I recommend on YouTube-- bigclivedotcom.
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.
> b) Will show me a actual PCB and derive its schematic from it.
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.
When the magazine "Electronics Australia" was still around, they had a section written by a TV repair engineer. Each month, he would go through a repair scenario. The good thing is that he would describe what he was repairing from the actual doing and from the schematic. The explanation is quite good. From this I can correlate the two quite well.
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.
> 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.
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.
I really enjoyed the level of detail this video goes into, describing how a basic amplifier works:
I once read a really good book about discrete RF circuits (made from transistors/diodes/...). It was composed of ~100 different circuits and explained what each part did. (you could not always easily split the design, because of numerous feedback loops) It was a lot of fun studying it. You'd learn to find oscillating circuits, circuits that used non-linear elements to shift signals between frequency bands, to identify buffers and amplifiers, LP,HP,BG,BP filters, etc.
Similar thing in digital world is trying to understand simple ICs like, operation amplifiers, TTL logic, SMPS control circuits at the low level.
I had a really good experience in this area with the MITx (now Edx) Circuits and Electronics Course. (This is an introductory course.)
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.
Thanks for pointing it out, will take a look at it. Sounds like "my kinda" approach to circuit study.
I don't agree with him on everything, but Louis Rodman has some excellent videos where he goes through a broken Macbook logic board and its schematic and explains how each component ties into overall functionality. They're really interesting and the explanations are pretty good if a little condescending.
This should even be a course in itself. How to parse new complexity.
I was happily surprised to read about Thevenin/Norton rules to turn sub-circuits into a virtual ESR element. Very tree recursive.. very interesting.
The fundamental concepts of parsing new complexity are literally baked right into the core of university EE programs, and introduced at an appropriate time.
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.
Sources please?
forgot which book I read about it in first, but https://en.wikipedia.org/wiki/Th%C3%A9venin%27s_theorem
Here's the general rules of thumb I follow when deciphering a schematic/PCB:
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.
Very nice and Thank you. The pullup/pulldown resistors and decoupling capacitors were some of the first i learnt to identify. But still much more "patterns" to add to the mental database!
You go to school for it.
This is a common platitude but contributes nothing to the discussion. In real life, you don't get a chance to "do over" whenever you wish. As they say, "time and tide wait for no one". You have to do the best with what you have got rather than wishful thinking.