I recently got interested in the IoT world, home made.
Unfortunately I could not go to far because I am missing an "electronics cookbook".
As an example I wanted to build an internet radio off a Raspberry Pi, hooking a small amplificator "chip" (a pre made circuit with an IN from the rpi and an OUT to small loudspeakers).
There was a buzz from the loudspeakers and I am sure an electronician (of there is such a word) would immediately say "you need a 1 pF capacitor here and a 200 ohm resistor there because this is a basic Schmidt-Landau-Trump bridge, obvious in loudspeakers".
I will never understand why a parallel resistor and a capacitor in series is the way to go, but would love to have a cookbook for such circuits, with some explanation such as "if it buzzes, uncrease the resistance between 100 and 1000 ohm" - for the typical circuits one would make in IoT (say, a plant humidity detector where I have the sensor, the nodemcu and need to kniw what to use in electronic parts to hook them up).
There are different ways to approach electronics. You can spend a few years getting formal background in math and electrical engineering, but I don't think that will necessarily answer the hypothetical question of "why does this buzz". Anecdotally, I struggled to even get digital circuits working after several years of electrical engineering university education until someone who ran our labs told us about bypass capacitors.
Which brings me to another way to learn, which is by hands-on tinkering and picking up theory where it is needed. I am pretty sure the guy that ran our labs didn't have a degree in electrical engineering, but he was amazing at building things and troubleshooting them. Building up intuitive knowledge and experience also takes years though.
Absolutely. This reminds me of a similar difference between a ‘computer scientist’ and a ‘real programmer.’ You do not need any knowledge of the so-called computer science to be an excellent software developer, and I have seen more than a few self-professed computer scientists who couldn’t write a simple program.
I found healthy proportion of designing your own projects, debugging/studying existing electronics and spending time on understanding theory behind what you are working on to be the best way for me.
I could never go far learning just theory because I seem to forget soon after I think I have understood it.
Studying/tinkering with existing electronics is fantastic -- there is so much knowledge in most products that I feel drunk with excitation to see how something can be implemented way better and more efficient than I thought. It is very interesting to see how different designers approach their problems and it builds my repository of solutions I can implement.
This is no proxy for actually trying to solve the problems. I think only after you have really tried to solve a problem you can actually appreciate alternative designs.
"Anecdotally, I struggled to even get digital circuits working after several years of electrical engineering university education until someone who ran our labs told us about bypass capacitors"
You're kidding, right? Electrical engineering from University and never heard of bypass capacitors?
Not kidding. I was a few years in having taken a few analog electrical engineering courses with labs, signals and systems, a course and a lab on power before we got to digital circuits. The first course in digital circuits didn't have a lab. It wasn't until we got to the microprocessors course where we had to work with a Motorola 68HC11 on a breadboard that the concept of bypass capacitors was explained to us in a lab. It was 20+ years ago. Maybe things are different now.
Bypass capacitors are used in analog circuits as well. Not sure what is wrong about that uni. Anyways I am a former physicist and do not have any formal education in electronics. I learned electronics on my own and bypass capacitors were definitely not the last thing to come by.
I think your experience reinforces my point that you can get to be proficient in electronics from either end: formal theoretical education leading to hands-on, or hands-on with theoretical learned as needed. Your case seems like the latter, and you learned about bypass capacitors early on. My case was the former, and I learned about them later.
Same experience in my university. I think the curriculum has analogues with the CS/SW dichotomy. CS programs are not meant to teach you programming. Similarly, EE programs are not meant to teach you how to build stuff.
In fact, the electronics for physicists course often had more practical material than you'd get from an EE course.
Engineering programs in the US are required by accreditation boards to have lots of lab courses. One of the primary reasons is the industry advisors on these boards want graduates to be able to build stuff. And from what I've seen, it's a lot easier to get an engineering degree by being able to build stuff but struggling with the math, versus learning a bunch of math but not being able to build anything. Assessment courses in your final year of school are required to test you at real-world-level tasks.
Similarly CS is required to have labs which force students to be able to program. If someone gets a CS degree but can't write a program, they either cheated their entire way through every programming assignment, or got that degree at some international university that would never be accredited here.
This is pretty much the same in EU, modulo some controversy about the exact point during the course of higher education when you should be expected to be able to design things on your own.
I have no idea how an EE curriculum doesn't cover bypass capacitors. They're in virtually every real-world circuit. Even if it's not an item that's specifically covered in a course, lab or seminar, there's no way you can put a real-world schematic on the projector and not run into one.
I can't point at a specific course I took where they were covered but I am sure everyone who made it to the third year knew what they were. I definitely remember talking about them extensively in at least three courses (Circuit Theory, Digital Circuits and Digital Instrumentation).
> Engineering programs in the US are required by accreditation boards to have lots of lab courses. One of the primary reasons is the industry advisors on these boards want graduates to be able to build stuff.
Let me summarize almost all my engineering lab courses:
"Design and build X" where X could be some kind of amplifier, etc.
The "design" part is identical to a HW problem. You already know in advance the circuit (one of the standard ones in the textbook), and you just need to figure out R/C/L values to get the desired output. Then you build it and show it to the lab TA who'll check it is actually behaving as desired.
This isn't a good lab assignment: It's just a theory problem masquerading as a lab exercise. After the first semester, any idiot can put the circuit together on the breadboard if they already know the circuit topology.
And yes, while I was there, the accredition board actually reaccredited the program. And yes, they looked at the lab assignments we were getting.
After graduating, I visited my department a number of times, and I did give them the feedback that "your lab assignments are useless".
> And from what I've seen, it's a lot easier to get an engineering degree by being able to build stuff but struggling with the math, versus learning a bunch of math but not being able to build anything.
Definitely not the case at my university. If you struggled with the math, you'd get really poor grades. And we had a mandatory requirement to get a B in second semester circuits (and pass the final with a score of 8/12 or better). Until you did that, you were not allowed to take junior level EE courses. The labs were trivial, but the exams were tough.
The only time when not being able to build anything was a barrier was for a Senior Design assignment we all had. And lo and behold everyone either got an electronics book (notably not a textbook), or searched the Internet.
> If someone gets a CS degree but can't write a program, they either cheated their entire way through every programming assignment, or got that degree at some international university that would never be accredited here.
Eh. It's not so much that they couldn't write a program, but that they would forget the stuff fairly quickly. In my university there definitely was a fair amount of nontrivial programming required in some CS courses. But on the EE side most of the lab assignments were just trivial.
I would quibble a little with you on the EE/CS comparison (even though I'm the one who introduced it to this thread). IMO, EE is a lot broader a discipline than EE. Stuff that is considered part of EE: Electromagnetics, control theory, acoustics (believe it or not), information theory, semiconductors, signals (e.g. Fourier transforms, etc), power, electronics, and others. There are quite a few professions that fall within the aegis of electrical engineering but have little to no circuit aspect. This is less true of CS. So it is a tad bit more understandable that someone gets an EE degree but sucks at electronics.
I agree, but I am still missing (naively) the equivalent of the Python or node module fuck will generate UUIDs. Sure I child code it myself knowing the theory (algorithm) but I just want it to work because I am not that interested in the how.
I think this is not really possible in electronics as there are maybe too many cases (though some are probably quite common)
There are at least two O'Reilly "Cookbooks" for electronics.
The best way to do this as a hobbyist, if you don't want to read textbooks, is just to mess around and soak up information from blogs. There is an awful lot of "do this because it works" in electronics. Most of it is backed up by theory somewhere - e.g. why is 100nF so often used as a bypass cap value? - but really you don't care as long as you follow the recommended application circuit in the datasheet.
I thought about electrical engineer but it does not have to be an engineer. Like a driver does not need to be a BMW engineer and know everything about the car.
I think your second example summarizes it quite nicely.
I am a physicist by education and an IT guy by career, so to speak. When my son asks me about basic physics I usually give him an erroneous answer, good enough for him to go ahead. This is what I would love to have in electronics.
But as you say (and with which I agree), years of tinkering is probably what builds a cookbook in your head.
I think there are three main levels in the approach to hobby electronics: 1: do it as the book says so it will work, 2: build experience also by making modifications so one can know in a pure empirical way why it does or doesn't work (for example using an electrolytic cap for RF decoupling), and 3: learn the theory behind parts and how they work, in order to be able to design from scratch or make heavy adaptations. 1 and 2 require time and will, 3 requires also math knowledge, and can be slow to conquer. I have personally been stuck too long time at 2, and now am still somewhere like 5% of 3, which all things considered is not bad at all.
It's a myth that electronics design is math-heavy, because you can do it with pretty much just +-/ and some ² and roots. Even for e.g. filter design you don't actually need to be able to do (or even understand) any of the calculations yourself, because tools automate it away. Analog design with "basic blocks" is pretty straightforward, "free form design" not following basic blocks (usually resulting in part count reductions or performance enhancements) is much harder. The latter is what often produces "trick circuits" which most people cannot analyze on their own and possibly cannot analyze using SPICE.
The art of electronics is pretty good at combining theoretical concepts with practical circuit tips and tricks, definitely worth (non-negotiable!) having on the shelf.
Unfortunately I could not go to far because I am missing an "electronics cookbook".
As an example I wanted to build an internet radio off a Raspberry Pi, hooking a small amplificator "chip" (a pre made circuit with an IN from the rpi and an OUT to small loudspeakers).
There was a buzz from the loudspeakers and I am sure an electronician (of there is such a word) would immediately say "you need a 1 pF capacitor here and a 200 ohm resistor there because this is a basic Schmidt-Landau-Trump bridge, obvious in loudspeakers".
I will never understand why a parallel resistor and a capacitor in series is the way to go, but would love to have a cookbook for such circuits, with some explanation such as "if it buzzes, uncrease the resistance between 100 and 1000 ohm" - for the typical circuits one would make in IoT (say, a plant humidity detector where I have the sensor, the nodemcu and need to kniw what to use in electronic parts to hook them up).