You Can’t Make What You Can’t Measure

What’s the most-used tool on your bench? For me, it’s probably a multimeter, although that’s maybe a tie with my oscilloscope. Maybe after that, the soldering iron and wire strippers, or my favorite forceps. Calipers must rate in there somewhere too, but maybe a little further down. Still, the top place, and half of my desert-island top-10, go to measuring gear.

That’s because any debugging, investigation, or experimentation always starts with getting some visibility on the problem. And the less visible the physical quantity, the more necessary to tool. For circuits, that means figuring out where all the voltages lie, and you obviously can’t just guess there. A couple months ago, I was doing some epoxy and fiberglass work, and needed to draw a 1/2 atmosphere vacuum. That’s not the kind of quantity you can just eyeball. You need the right measurement tool.

A few weeks ago, I wrote about my disappointment in receiving a fan that wouldn’t push my coffee beans around in the homemade roaster. How could I have avoided this debacle? By figuring out the pressure differential needed and buying a fan that’s appropriately rated. But I lacked pressure and flow meters.

Now that I think about it, I could have scavenged the pressure meter from the fiberglassing rig, and given that a go, but with the cheap cost of sensors and amplifiers, I’ll probably just purpose-build something. I’m still not sure how I’ll measure the flow; maybe I’ll just cheese out and buy a cheap wind-speed meter.

When people think of tools, they mostly think of the “doers”: the wrenches and the hammers of this world. But today, let’s all raise a calibrated 350 ml glass to the “measurers”. Without you, we’d be wandering around in the dark.

Degrees Of Freedom, But For Whom?

Opening up this week’s podcast, I told Kristina about my saga repairing our German toilet valve. I’m American, and although I’ve lived here over a decade, it’s still surprising how things can be subtly different from how they worked back home.

But what was amazing about this device was that it had a provision for fine adjustment, and to some extent relied on this adjustment to function. Short version: a lever mechanism provides mechanical advantage to push a stopper against the end of a pipe to block the water flow, and getting the throw of this mechanism properly adjusted so that the floater put maximum pressure against the pipe required fine-tuning with a screw. But it also required understanding the entire mechanism to adjust it.

Which makes me wonder how many plumbers out there actually take the time to get that right. Are there explicit instructions in the manual? Does every German plumber learn this in school? I was entirely happy to have found the adjustment screw after I spent 15 minutes trying to understand the mechanism, because it did just the trick. But is this everyone’s experience?

I often think about this when writing code, or making projects that other people are likely to use. Who is the audience? Is it people who are willing to take the time to understand the system? Then you can offer them a screw to turn, and they’ll appreciate it. But if it’s an audience that just doesn’t want to be bothered, the extra complexity is just as likely to cause confusion and frustration.

Pico-WSPR-tx Does It In Software

What do you need to make a radio transmitter? There are builds that work with just a couple of transistors. But how about a GPS-disciplined small signal beacon? You can actually get the job done for less than the cost of a fancy hamburger, thanks to [RPiks]’s pico-WSPR-tx and the Weak Signal Propagation Reporter Network (WSPR).

WSPR is a digital protocol where a beacon encodes its callsign, location, and transmitting power, and then sends it out to a network of receiving stations worldwide. The idea is to use the data coming from the beacons to determine whether radio propagation conditions are good or not; if you hear a quiet signal from afar, they’re good in that direction. [RPiks]’s beacon design simply includes a Raspberry Pi Pico and a GPS receiver. Everything else is software.

Of course, this means that it’s using the Pico’s GPIO pins for transmission. Maybe you want to add some filtering to take off the rough square-wave edges, and/or maybe you want to boost the power a little bit with an external amplifier. If so, check out our own $50 Ham column’s advice on the topic. But you don’t need to. Just a Pico and a GPS should get you working, if you want to test the WSPR waters.

The Physics Lesson I Keep Re-Learning

One of the most broadly applicable ideas I’ve ever encountered is the concept of impedance matching. If you’re into radio frequency electronics, you’re probably thinking that I mean getting all your circuit elements working to a common characteristic resistance for maximum power transfer. (If you’re not, you’re probably wondering what that jumble of words even means. Fear not!)

But I mean impedance matching in the larger sense. Think about driving a stick-shift automobile. In low gear, the engine has a lot of torque on the wheels, but it can’t spin them all that fast. In high, the wheels turn fastest, but there’s not enough torque to get you started from a standstill. Sometimes you need more force and less motion, other times more motion and less force. The gearbox lets you match the motor’s power to the resistance – the impedance – it’s trying to overcome.

Or think about a cello. The strings are tight, and vibrate with quite a bit of force, but they don’t move all that much. Air, which is destined to carry the sound to your ear, doesn’t take much force to move, and the cello would play louder if it moved more of it. So the bridge conveys the small, but strong, vibrations of the strings and pushes against the top of the resonant box that makes up the body of the instrument. This in turn pushes a lot of air, but not very hard. This is also why speakers have cones, and also why your ear has that crazy stirrup mechanism. Indeed, counting the number of impedance matches between Yo Yo Ma and your brain, I come up with four or five, including electrical matches in the pre-amp.

I mention this because I recently ran into a mismatch. Fans blow air either hard or in large volume. If you pick a fan that’s designed for volume, and put it in a pressure application, it’s like trying to start driving in fifth gear. It stalled, and almost no air got pushed up through the beans in my new “improved” coffee roaster, meaning I had to rebuild it with the old fan, and quick before the next cup was due.

I ran into this mismatch even though I knew there was a possible impedance issue there. I simply don’t have a good intuitive feel how much pressure I needed to push the beans around – the impedance in question – and I bought the wrong fan. But still, knowing that there is a trade-off is a good start. I hope this helps you avoid walking in my footsteps!

Thanks For Hacking

Hope you’re all having a great Thanksgiving weekend, and are getting your fill of family, food, and maybe even a little bit of fun. Aside from the cranberries, Thanksgiving is probably one of my favorite holidays because of the spirit behind it – thinking about what’s gone well, how you lucked out, and who has done you right over the year.

One of the most poignant expressions of thanks I’ve heard in a while came from Hackaday superfriend [Sprite_tm] in his Supercon talk this year, which he closed by thanking “you all” for pushing him on to keep making crazy projects. “I would never finish these projects without people who would be entertained by seeing all this. This is is effectively art – something that doesn’t make sense. The only way it makes sense is because I want it to exist, and because I know that you all love hearing and reading about stuff like this existing. So thank you very much for that.”

That same sentiment goes for all of us here at Hackaday: Thank you all very much for reading! Without this global community of crazy hackers to write for, we wouldn’t be able to keep doing what we do – it just wouldn’t make sense. And without your hacks, of course, we’d have nothing to write about.

Thanks for sharing, thanks for following along, thanks for inspiring us and for being inspired. Thanks for hacking.

How The WS2812 Is Made

[Scotty Allen] of Strange Parts is no stranger to Chinese factory tours, but this one is now our favorite. He visits the font of all WS2812s, World Semi, and takes a good look at the machines that make two million LEDs per day.

The big deal with the WS2812s, and all of the similar addressable LEDs that have followed them, is that they have a logic chip inside the LED that enables all the magic. And that means die-bonding bare-die ICs into each blinky. Watching all of the machines pick, place, glue, and melt bond wire is pretty awesome. Don’t miss the demo of the tape-and-frame. And would you believe that they test each smart LED before they kick it out the door? There’s a machine that clocks some data in and reads it back out the other side.

Do we take the addressable LED for granted today? Probably. But if you watch this video, maybe you’ll at least know what goes into making one, and the next time you’re blinking all over the place, you’ll spill a little for the epoxy-squirting machine. After all, the WS2812 is the LED that prompted us to ask, three years ago, if we could live without one.
Continue reading “How The WS2812 Is Made”

Procrastineering And Simulated Annealing

The software for the Supercon badge went down to the wire this year, with user-facing features being coded up as late as Thursday morning. This left “plenty of time” to flash the badges on Thursday afternoon, but they were admittedly still warm as the first attendees filed in on Friday morning. While I’ve always noted that the last minute is the best minute, this was a little close, and frankly there was an uncaught bug that we would have noticed if we had a few more hours to just play with it before showtime.

But we were by no means slacking. On the contrary, a few of us were putting in nights and full weekend days for six or eight weeks beforehand. The problem was hard, and the path to a solution was never clear, and changed depending on the immovability of the roadblocks hit along the way. This is, honestly, a pretty normal hacker development pattern.

What was interesting to me was how similar the process was to simulated annealing. This is an optimization method where you explore more of the solution space in the beginning, when the metaphorical “temperature” is hot. Later, as you’re getting closer to a good solution, you want to refine in smaller and smaller steps – it cools down. This rate of “cooling” is a tremendously important parameter in practice.

And this is exactly the way the badge development felt. We were searching in a very big solution space in the beginning, and many aspects of the firmware infrastructure were in flux. As it got closer and closer to a working solution, more and more of the code settled down, and the changes got smaller. In retrospect, this happened naturally, and you can’t always control or plan for the eureka moments, but I wonder if it’s worth thinking of a project this way. Instead of milestones, temperatures? Instead of a deadline, a freeze date.