You’ve undoubtedly seen the stories and read about the contests: there is a lot of serious interest among educators, families, and companies in encouraging STEM-related (science, technology, engineering, and math) interest among students from elementary school through high school and more. That’s good news, in my view, because we probably need more individuals working across the array of STEM disciplines. You never know which ones will develop innovative or insightful approaches to solving the many design challenges out there.
Even if they don’t develop into leading-edge innovators, there are plenty of basic engineering tasks, such as squeezing more “stuff” into ever-smaller boxes while using less power, that will require solid, basic engineering know-how and skills (Note: I am not including the STEAM enhancements to the STEM program, which adds “art” to the acronym, as I think art has its own place and already gets plenty of attention.)
There is a viable counterargument to the “we need more engineers and scientists” claim, in that there really is no such shortage and that having so many technology practitioners drives wages down. There may be some validity to that, and the cry of “imminent engineering shortage” has been going on for decades. The problem is that is it impossible to know what constitutes a shortage, or how having more or fewer engineers would affect working conditions and more.
So, I’m happy to see all this STEM interest, with much of it related to robotics-type projects. That makes sense since, as those are the kinds of projects which get the imagination going, keep student interest alive, and yield a tangible, demonstrable end-project.
However, there’s one thing that bothers me about many of the STEM projects and courses I see: much of the time is spent in “programming” using platforms such as the well-known Arduino family. As a result, a lot of the STEM exposure that these students get is via the keyboard only, as if everything is just a chunk of code or an app, and nearly engineering issues can be solved with a bit of programming.
Sorry, that’s not the case at all. Experienced engineers know that many of the real design challenges are at the physical and interface level, with issues of drive current and voltage, sourcing and sinking, transients, dissipation, parasitics, leakage, load idiosyncrasies, noise, timing, glitches — the list is pretty long – and which can’t be solved in most cases by some clever code. Instead, it involves getting “down and dirty” with analog circuit functions and components (active and passive). Even if the circuit is nominally digital, the reality is that at the physical level, all systems are analog; that’s just the physics of the situation.
The best way to learn about physical-layer circuitry, of course, is to build some circuits and work with them, while minimizing or even eliminating the processor/software aspects, as least at the start. That’s why I found this small circuit in the July issue of QST (the official publication of ARRL, the American Radio Relay League) to be a good fit, see Figure1 (the article is behind a paywall; go to your library or find a ham-radio enthusiast and ARRL member). It’s from an article “Go No-Go Continuity and Leakage Detector” and is easy to breadboard, as it has no critical components, layout or build issues, or risky voltages and currents, and indicates under 1/2 mΩ as a short circuit and above ½ MΩ as an open. Anyone who builds it can measure the various currents and voltages with a basic DVM or scope and can also explore the effects of changing component values. What’s not to like?
This relatively simple and useful analog circuit, for an audio/LED continuity and leakage detector, can teach STEM students about the reality of components and their functions, due to its simplicity and ease of risk-free probing. (Reprinted with permission, July QST, Copyright ARRL)
Many of the STEM-program students will decide engineering and science are not for them, and that’s OK. If nothing else, they may get an appreciation and respect for just how hard it is to create all this “magic” that engineers and scientists do make. Perhaps next time they see a product, they will better understand a little of what it took to design, prototype, debug, and bring it to market.
Equally important, they may also develop a sense of the overriding reality of design: in the end, it’s often largely about tradeoffs and constraints. So, when they see a product that has a feature or function they don’t like, or is missing, they won’t ask with that simplistic view, “why the heck didn’t ‘they’ do it this way, what would have been the big deal?” Excuse me, adding or changing that “little” item turns out to actually have a “ripple effect” that does make it a big deal.
What are your feelings about STEM projects which rely heavily on keyboarding versus hands-on circuitry and interfaces that can be probed and modified?
Also of interest