Hacker News Reader

Comment by blippage | Hacker News Reader

I find the problem with a lot of electronics books is that they are either too deep, or too shallow. Gerry Sussman (yes, that Sussman) explained that the way electronics is taught, and the way engineers think about problems are two separate things.

So teaching material tends to fall into two camps: 1) detailed explanations that cover great depth, but are difficult to know how to apply to practical circuits, or 2) circuits that are presented as a fait accompli. They work, but I have no real idea why.

It reminds of statistics, in a way. I've seen biologists, undergrads and industry apply statistics like it was some kind of talisman. "Cargo Cult Statistics", as it were. They don't really "understand" the data that they're looking at.

View on HN

They're not really two separate things because of the way they're taught. They're separate things because they're actually separate.

A fully qualified EE understands circuits at a deep mathematical level.

Analog circuit design is basically a variant of the same theory used to model masses/springs and various other equivalent systems. (Of which there are many.) It's based on diff eqs with various simplifications (specifically the s-plane transformation for simplified analysis and its z-plane equivalent for DSP.)

There are maybe a couple of hundred or so standard circuit configurations to learn with their associated models and properties. The rest can be worked out. But it's essentially undergrad calculus and numerical analysis applied to an unexpectedly large collection of standard configurations which were invented/characterised by researchers with PhDs, often quite some time ago.

There are also specialisms - digital, RF/uWave, component design, data compression and encoding - which have their own lore.

Electronics is cookbook-level circuit design using a small selection of the standard models described with simple pre-calculus algebraic descriptions. It's hugely simplified and watered down. You can get a long way with it, but it's more like LEGO in that you can clip circuits together with only a very superficial idea of how they work.

Anyone who says they can make electronic engineering simple is lying. It's a subset of applied physics, so it's not simple at all.

Cookbook level electronics can be as simple as you want, but doesn't provide a deep understanding of circuit design, or issues like noise, distortion, and RF/shielding problems, data encoding systems, and so on. If you want those you'll need the full course, and that's a lot of work.

Great explanation of the differences! I would argue though that even for noise, distortion, and RF/shielding problems you can get quite far with "cookbook" level knowledge (though I'll grant that it's quite likely to get let astray by leaky abstractions with these, like the many answers to "how/whether you should connect the shield of a USB plug/socket to PCB and/or chassis ground").

When I was young I loved magazines like Popular Electronics.

After getting my EE, I looked back at those magazines in my collection I immediately thought "That's so wrong!" or "That omits so/too much" or "I can't believe I thought this was electronics" or "Baby project! How lame!".

:-)

So it's very much about what can be absorbed and tailoring to the audience. You can't start with the math load that an EE student gets with a broad, general audience.

You see the opposite of this with academic papers - either the level of assumed audience is stratospheric OR it's clearly wording to keep the riff-raff out of the field. Mostly the former but sometimes the latter. You often also see this in STEM textbooks - the audience isn't even freshmen oriented!

One of my mentors said "read all the hobby magazines, you never know what you might learn, sometimes they pick up new technology faster than industry". So did Bob Pease in one of his columns. But yeah, there's a lot of groaners in them.

> You can't start with the math load that an EE student gets with a broad, general audience.

Yeah, it's Wittgenstein's 'ladder', from the Tractatus:

> My propositions are elucidatory in this way: he who understands me finally recognizes them as nonsensical, when he has climbed out on them, over them. (He must - so to speak - throw away the ladder, after he has climbed up on it.)

This cookbook analogy is pretty true for all fields.

There are tons of software engineers who have never taken a higher math course, the "cookbook" and the intuition is enough to get the job done efficiently enough.

Chop wood, carry water. Using cookbook circuits is kind of like that zen story. You come full circle.

There's little enough honestly new in electronics that almost anything you do will look cookbook to an outsider. Designing actual products is exacting and deep, though. An example to look at is the writeup nwavguy did on his O2 headphone amp. He makes it look easy. The core amp is not an app note design or reference design but if he'd chosen the equivalent parts from TI it just about could have been. It's very straightforward. There is nothing exotic in it. The parts are cheap. The layout is even pretty mundane for high end audio. And yet it measures to be just about flawless, it has a nice no-pop turn-on circuit, etc. and there are plenty of headphone amps you can buy that do not. Without specific experience and expertise in audio design most fully qualified EEs would pathetically struggle to make something that nice.

It's one of the best electronic designs for hobbyists I've ever seen. All of you should build one if you think you might want something like that.

The only flaw I've found in mine is that the hysteresis on the low battery cutoff is not sufficient for some batteries (as they age and the internal resistance goes up) and it can "motorboat" before the battery cuts out. A really good low battery cutoff circuit is also surprisingly challenging.

“The novice says to the master, ‘What does one do before enlightenment?’ ‘Chop wood. Carry water,’ replies the master. The novice asks, ‘What, then, does one do after enlightenment?’ ‘Chop wood. Carry water.'”

>A fully qualified EE understands circuits at a deep mathematical level.

this is so funny. i have a buddy who's finishing up his phd in ee that works on SDR and who lead a team that won the darpa spectrum challenge a few years ago. he has no idea (absolutely no idea) how odes model LRC systems. i'm closer to CS than EE so he was explaining SDR to me and at some point i said "oh like the ode representation <something something>" and he had no clue what i was talking about. sure he took the class where that was covered but he completely ignored it (probably barely passed).

just one data point.

Of course you can find PhDs that don’t master fundamentals properly, but that remains rare. PhD quals are supposed to root that out. It’s also true that in day to day electronic engineering, any sufficiently complicated circuit would be solved with SPICE or an equivalent. For a PhD student in electronic engineering to not know that SPICE essentially solves ODEs still seems very surprising.

Actually I found that almost no one mastered fundamentals properly when I was an EE undergrad, at least with respect semiconductor physics (and an antenna theory). The "holes and electrons" stuff fundamentally violates conservation of charge because at first the "holes" are stationary but later, with the Hall Effect, suddenly they're moving, that's a bit of sleight of hand that no one cottoned on to. Not the profs, not the legions of grad students. It really does go to show how much of education is cargo cult learning. It turns out that in fact both the 'holes' and the 'electrons' of semiconductor theory are statistical virtual particles and not the fundamental particles that they are purported to be. (Somewhere in my past comments is the similar bit about antennas if anyone is interested)

At university one of the mandatory courses was Computer Organisation, which teaches how computers are built electronically. Two weeks of that course covered DRAM timings. Recently (almost 15 years later) I was trying to design a simple automation system for my home's ventilation system, and for it I needed to pull my logic signal up to 10v using a FET. I had absolutely no idea how to do that.

It's absolutely crazy that at some point I was able to (crudely) design a computer logically to the level of detail of DRAM timings, but at the same time I've never had a deep enough understanding of current to design a circuit that uses a logical signal to switch a 10v line using a FET.

(this is how you do it btw: https://tinyurl.com/ydsgmdvh)

There is a real case where someone could go a whole career in EE knowing a ton about DRAM timings and nothing about pulling up FET switches to the proper voltage.

I know - I've met them!

Real world effects of parasitics are underated. Found out the hard way that there's a whole lot of pain involved with hot plugging a battery into a board when there's a modular switch mode power supply onboard. Oh, you have a low esr ceramic cap on the input? Lol, the parasitic inductances of your wire and traces have formed a tank circuit and pushed the input voltage well above the unhappy voltage of something. K, you fixed that part, nope, lol, your inrush current is actually 15A because you had 68uF on the output of the smps and somehow you burnt out the internal fet of the smps module. Goddam nearly flipped a table.

Inrush is a real bitch. I make it a rule to include simple inrush current control circuits whenever I do DC input that sinks more power than, say, a USB cable.

Lotsa surprise inductances out there. I've felt your pain re: inductance + input cap creating a resonant tank, too. That's a nasty surprise when you manage to create that resonance with your wiring.

The worst is when the other guys think you're crazy because they're not suffering the same problems because either the smps they have had a soft start or they overspeced the living crap out of their input stage. I gave up and just spend the 5$ for the IC that provides slew rate control, single IC with a single fet? Oh hell yeah.

https://falstad.com/circuit/ - there goes my afternoon ...

Also, Micro-Cap is now free; not Open Source, still better than nothing. Windows only (although I seem to recall a Micro-Cap software running under the Mac Classic in the early 90s), but it works perfectly under Linux+WINE.

http://www.spectrum-soft.com/index.shtm

LTSpice is probably better for beginners, and my impression is that it is faster at the things it can do. Micro-Cap is really nice and does a whole lot more, though. And they're free, so you can have both!

Just wait till you put a bigger load on your fet than that 100K resistor, try to PWM it, and discover the Miller effect.

That's an absolutely trivial "how do you use a transistor" sort of example, though. If that's not covered I'd say it's because you're not learning electronics at all. You're just learning how a CPU talks to the RAM at a logical level, and what exactly you're actually doing when you're fiddling with the CAS latency setting in the BIOS.

That's my point exactly, that my entire curriculum from highschool until my CS degree I always have gotten away with only logic design. I'm pretty sure at some point we've learned what a FET is and how it works, but I guess designing a circuit that involved one was deemed either too advanced, or not advanced enough.

I even had courses in verilog. I'm pretty sure I'd do better designing a CPU in verilog, than designing a home automation controller. It's almost like a challenge of how close can you get to learning about electronics, without actually learning about electronics..

CS and EE are very different fields, there's lots to learn in each field.

My curriculum was a blend of EE and applied maths/phys: I made carbon nanotubes in a lab, used quantum tunneling microscopes to look at atoms of gold, used VHDL to write games and generate the signals to display them in VGA, used control theory and electromechanical models to make a webcam rotate and move to track a face via PID, applied Kalman filters, etc..

But at no point did I learn how a compiler works, how linting works, what are fundamental differences between main programming paradigms, what data structures to pick for different kinds of problems, what are the fundamentals of an OS, how to be comfortable with LISPs, etc..

Once I was out of the academic environment without a PhD or a strong specialization (and just struggling to find any work), it was much more valuable to know binary trees and SQL than all of the EE stuff. So I was on the other end of what you experience, where at one point we covered without gaps quantum physics/chemistry --> barebones CPU, yet I wouldn't have known how to make something robust with it afterwards.

And obviously, despite doing 'some' applied mathematics, any mathematician would look at what I did and probably roll their eyes at the amount of convenient assumptions made.

There's just so much to learn out there that most of what we do in our lives is rely on abstractions, and it doesn't even have to be specific to computers: most people can use a bicycle without being able to draw a functional one[0].

[0] https://www.fastcompany.com/3059089/it-turns-out-its-almost-...

Something I've always disliked about electronics instruction, is discussion of actual applications.

Consider the esteemed Art of Electronics. By chapter, it covers Fundamentals, Transistors, Op Amps, Filters, and Oscillators.

That's all well and good. Except, in my case, while these are all interesting in isolation, I don't know what I am supposed to do with these components. How do I turn these components in to, say, a radio, or a garage door opener, or whatever else folks do with electronics?

No doubt it probably doesn't help to approach it without an application. That said, when learning programming, we had all of these contrived exercises to illustrate a programming concept. I remember an early Fortran exercise was computing the date for Easter in any particular year. Did I have a particular need to know where Easter fell? No, but it was nice to see math, and expressions, and variable, and input/output in operation vs just being presented with operators and precedence rules. We had to apply it to a "real world" task.

I took an electronics class in High School. And, frankly, we didn't build anything. We wired components together and took measurements. I learned Ohms Law, the resistor color code, etc. I did build, I think, an AM transmitter kit. Discrete components, PC board, soldered it all up. But I had no idea how it worked. Just an array random components soldered together.

Honestly, I think the success of modern hobby digital electronics, centered around mostly interfacing Things to a microcontroller, has such good velocity due to how little actual "electronics" knowledge you need to get your LED blinking or servo moving. It's mostly wiring up black boxes.

> How do I turn these components in to, say, a radio

The problem is that you have so many models of the same components, that can be connected together in so many configurations, to obtain so many results, that even if the book had a recipe to build a radio, it won't tell you a lot of how to build the radio for your given application (freq. range? power? bands? noise correction? etc.). It would probably be better to explain different components and how to use tools to probe them and tell whether they are behaving with the right voltage, current, resistance, frequency, timing, logic, etc.

Radio is the traditional hobby application and is a good place to start. The ARRL publications vary in quality and level but are generally pretty good. You can go as deep as you want into RF design at the hobby level as a ham. It's sort of a new golden age with good-enough test equipment so cheap these days and the sheer range of parts available on the internet.

Electronics is a big field. I think it really depends what you want to do in it that will determine the best way to learn it. I'd recommend people start with basic circuit theory then build up to op amps and then diodes, transistors, etc. That was the order I studied it at university at least.

With the trend towards ICs, you can get far using by learning to read datasheets, source parts, design and order PCBs, solder, and program MCUs. If working with high frequencies (RF etc), you'll eventually run into trouble with interference, at which point it makes sense to reference a text or course.

If you'd like to peak behind the epoxy curtain, or design ICs yourself... then you need to dive deeper.

Reply on news.ycombinator.com