How to Read a Schematic | Hacker News Reader

How to Read a Schematic

learn.sparkfun.com

302 pointsjlturner82 comments

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.

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!.

[1] https://youtu.be/U6qZPx4uD0g?t=2344

> 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:

https://www.imx6rex.com/

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:

https://www.youtube.com/watch?v=x5SSKX74DKg

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.

In all seriousness, the absolute crap that manifests from schematics developed in Eagle coming out of the open source community is a personal pet peeve. An example of almost everything you shouldn't be doing with respect to at least the following can be found here: color, symbology, scale, reference designators, typeface, labeling, orientation, functional grouping, density, overlap, flow, etc. It's a shame there's zero reference to industry standards like IEEE Std 315 and ASME Y14.44.

Abuse of color is probably the one thing that really drives me nuts. I'm of the opinion that if electrical intent cannot be cleanly and unambiguously conveyed in black and white, it's garbage.

I secretly wish EEs in general exercised the same level of meticulous attention to detail and pride that designers in the typeface community do, in the same vein as this comment[1].

[1] https://news.ycombinator.com/item?id=19608359

Haven't ever popped open anything that came in an Amazon box? At least with OSHW you can submit corrections to bring into compliance with any standard you find relevant. Better than firing off a sternly written letter to China (or HN).

The OSHW community has every right to distribute crap schematics, but it isn't immune to criticism.

For the record, I haven't opened an Amazon box of my own purchase since 2016 (dropped that like a bad habit after 10 years of Prime patronage), although I'm admittedly failing to see what the relevance of Amazon and China have to do with this discussion. I don't contribute to the OSHW movement because, quite frankly, if I can't buy the custom hardware solution I need, I'll design it myself.

Do you have a good example of schematics? There's nothing quite like real-life good design (think Tufte), and far too much space is given to how things are done wrong as opposed to how it has been done right.

http://w140.com/tekwiki/images/2/25/070-0398-00.pdf

Tektronix produced the finest schematics ever made.

you can print out your eagle schematics in B/W if you like, it's not hard - just click the "monochrome" box in the print dialog

I think the problem here is using solely color to distinguish connections. Ive definitely seen schematics where, if printed in B/W, are impossible to read.

Yes, that's effectively what I meant when saying:

> ...if electrical intent cannot be cleanly and unambiguously conveyed in black and white, it's garbage.

The problem isn't just constained to connections though: consider adjacent symbols, components symbol elements vs. nets, nets vs. busses, components in which physical color is a salient characteristic, etc.

Some hints on how to get to the meat of a circuit:

The most important thing is to learn what to ignore, stuff that has to be there to help a circuit work, but that don't tell you much about what it does

- ignore all the power stuff

- in particular capacitors oriented with the two lines horizontal are usually decoupling capacitors, ones oriented the other way tend to carry interesting signals

- learn to find and ignore the biasing resistors around transistors

Rules of thumb:

- outputs of transistors are usually inverted from their inputs if taken from the collector/drain

- signals usually move from left to right

- chips vaguely have inputs on the left and outputs on the right (or pins that work together grouped together)

Forgot one of the most obvious:

- Positive voltages tend to be above negative voltages in a schematic (ground is usually more negative than the power rail) nodes between them on the page tend to be between those voltages

I have more experience in reading analogue schematics, and I imagine this is less challenging in purely digital electronics, but to me understanding a schematic is really more about identifying the causal flow of information / signals, by recognising familiar patterns (amplifiers, filters, resonators, etc). This article is more an alphabet chart.

Too bad, the article only deals with how to recognize individual components (like a french dictionnary that would be entitled "how to read french").

One thing to be aware of: spark fun's schematics are generally flaming crap, along with most arduino stuff.

> Sometimes, to make schematics more legible, we'll give a net a name and label it, rather than routing a wire all over the schematic.

Net labels are the anti-readable-schematic. They're basically the electronics equivalent of GOTO. This is total bullshit.

People use net-labels when they don't want to bother spending time to make their schematic flow properly, or they're doing something dumb like drawing their schematic symbols with the pin-positions from the physical IC.

Good schematics should make the overall operation of the system easy to discern. You should have a consistent signal-flow (generally left-to-right, though the opposite also works). More complex systems should also use a hierarchical design with the interfaces between logical sections being clearly defined.

I think you are being quite harsh, net labels are fine for embedded/digital stuff, which generally consists of quite separate functional blocks with few, easily reasoned signals between them (e.g. power + I2C). A lot of Sparkfun's products fall into this category.

The Arduino Uno by contrast uses routing too much in my opinion, and is quite hideous: https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic...

If you look at say laptop or SoC development board schematics, they are full of net names, and they certainly aren't using physical pin positions. In fact quite the opposite, one physical device is often split into multiple schematic symbols (e.g. supply rails are one symbol). For the overall system, they use a block diagram or hierarchical schematic. Here is the BeagleBone schematic, which I think makes good use of net labels, e.g. the BAT connection on page 2: https://beagleboard.org/static/beaglebone/BEAGLEBONE_SCHEM_A...

I will agree with you on net names for analog systems, such as audio amplifiers or complex power supplies. There, net names can quite often be misused, as you need to keep more connections in your head when trying to understand a circuit, and it is much harder to remember all the net names than see a direct connection.

As I said, net labels are like GOTO. There are very specific situations where GOTO (or net labels) are useful.

They're also used in lots and LOTS of other situations where they're actively harmful.

Contexts like spark-fun designs, where the layout is almost always only one page is a situation where they're actively harmful.

------

I've done large, complex system designs without using net-labels at all. It takes a lot of thought about how to structure your component symbols, and was considerably helped by my EDA tool (Altium) having a facility to bundle multiple logically associated but non-bus wires into a single logical connection ("signal harnesses" - they're great), as well as very robust hierarchical design facilities.

It's absolutely possible to do, and you wind up with a much nicer schematic in the end, but it does take longer.

On the other hand, a site like spark-fun in particular sells educational components. The fact that they don't have decent schematics is really extremely disappointing.

Net labels are situation dependent. They can incerase or decrease readability depending on the signal flow. For example I would not like to see a complex board with a central microprocessor where each signal is wired up directly! OTOH having to chase a signal through 3 different sheets is a huge pain (this was especially bad when I had to read PDF exports from a (very expensive) tool where the net labels were not searchable nor linked in any form!).

For example I would not like to see a complex board with a central microprocessor where each signal is wired up directly!

this was especially bad when I had to read PDF exports from a (very expensive) tool where the net labels were not searchable nor linked in any form!

...like the majority of laptop schematics out there seem to be structured, where the CPU, GPU, and chipset are sitting on their own page with nothing but net labels attached to them? At least the ones I've come across have a list of the other page numbers where the net can be found, next to the label.

Very true. About the only time I find net labels acceptable is buses (otherwise the multiple lines clutter the schematic) and multi-sheet connections. Can't find it now, but back in around 2005 I found a basic 555 circuit for beginners with every connection to the chip besides power & ground being a net. IIRC, the pins weren't even laid out to match the chip. Every time I run across a spark fun schematic I have flashbacks to that. Which is a real shame, since the company's goal is to educate newbies. And it isn't impossible, Adafruit generally does a good job of this.

Would this schematic here be readable without the use of net labels?

http://files.pine64.org/doc/SOPINE-A64/SOPINE-A64-Schematic-...

A question: How many people are there out there that understand what these devices are whom are in need of a(nother) symbol reference?

I’m always having to double check where arrow (body diode) is on a Pch vs Nch mosfet... so... at least one.

I think the market of people just learning that would like a nice reference like this is probably larger than the number of people who would complain about educational resources being availble. :)

where arrow (body diode) is on a Pch vs Nch mosfet...

P points to N. This general rule applies to the symbols for diodes, BJTs, UJTs, JFETs, and other semiconductor components too.

Not many I suspect. What I'm sure of is that you can't learn to interpret schematics using a symbol reference. A circuit is a composition of components that follow a number of idioms that must be understood to grasp the intent.

Probably already mentioned, but looking at the "schematic symbols" - I noticed they didn't mention the (usually international) form of values - ie 2k5 - meaning 2.5k.

Also - they show symbols for potentiometer and variable resistor, but they don't show how if you connect the wiper to one end of the potentiometer, that means "variable resistor" (and is how you usually make one - unless using the potentiometer as an actual rheostat, which means connecting between one end and the wiper, leaving the other end free; electrically it's equivalent to not leaving the wiper floating with respect to the other end, but in a real rheostat, there is no "other end" to connect with - not without modification of the rheostat).

Then the battery symbols - and this isn't on them, but more the "standard"; yes, positive is the long side for a series of cells - but on virtually every standard consumer battery cell (C, D, AA, AAA), which end is the positive end? Yep - the one with the "bump" or "short end".

Even on the 9 volt battery, the smaller terminal is the positive end.

The only time things are "proper" are with coin cells, where the positive end is the flat plate (usually with writing), with the negative being the smaller plate surrounded by the edge of the positive plate on the other side. Knowing humans, though, I wouldn't be surprised if there was a coin-style cell where that was reversed...

I expect, though I don't know, that the battery stuff is the result of history (much like how positive and negative aren't really correct per physics as to how current really "flows").

I'm sure there's more weird stuff in Sparkfun's tutorial; it seems mainly geared for an American audience, and also toward older-styled symbols (like you'd find on schematics from the 1960s-80s). Most of the newer style haven't changed too dramatically - but there are some differences (they did note the resistor differences - but I've seen some others).

I'll have to read this in more detail later...

'.' and ',' generally can be rubbed off or overlooked if the font is too small or if printed on paper/plastic, etc, hence the more reliable notation you mentioned.

The text shows US and international symbols for things like resistors. But when it comes to logic gates don't mention the IEC standard gate symbols. Like these:

https://commons.wikimedia.org/wiki/Category:IEC_Logic_Gates

I'm fairly sure no one uses those, I've never seen them in the wild anyways, and I live in a country where they use the international symbols otherwise.

I love this use of "in the wild".

The electronics jungle. Intreprid explorers peering through the gaps between the cables.

Simulink uses similar symbols to IEC, they just write the actual name of the operation, like "AND", rather than the logic symbol, "&".

I'm fairly sure they are being used. I see them in the wild quite often.

Oh wow, I just found it few weeks ago. It was really helpful for me.

"I understand how to read a schematic!" - John Hammond

Reply on news.ycombinator.com