One Project At A Time, Or A Dozen?

February 10, 2024 by Elliot Williams 34 Comments

We got a bunch of great food for thought in this week’s ask-us-anything on the Hackaday Podcast, and we all chewed happily. Some of my favorite answers came out of the question about how many projects we all take on at once. Without an exception, the answer was “many”. And while not every one of the projects that we currently have started will eventually reach the finish line, that’s entirely different from saying that none of them ever do. On the contrary, Tom Nardi made the case for having a number of irons simultaneously in the fire.

We all get stuck from time to time. That’s just the nature of the beast. The question is whether you knuckle down and try to brute-force power your way through the difficulty, or whether you work around it. A lot of the time, and this was Dan Maloney’s biggest bugaboo, you lack the particular part or component that you had in mind to get the job done. In that situation, sometimes you just have to wait. And what are you going to do while waiting? Work on Project B! (But take good notes of the state of Project A, because that makes it a lot easier to get back into the swing of things when the parts do arrive.)

Al and I both weighed in on the side of necessity, though. Sometimes, no matter how many attractive other projects you’ve got piled up, one just needs to get out the door first. My recent example was our coffee roaster. Before I start a big overhaul, I usually roast a couple days’ worth of the evil bean. And then the clock starts ticking. No roasting equals two unhappy adults in this household, so it’s really not an option. Time pressure like that helps focus the mind on the top-priority project.

But I’m also with Tom. It’s a tremendous luxury to have a handful of projects in process, and be able to hack on one simply because you’re inspired, or in love with the project at that moment. And when the muse calls, the parts arrive, or you finally figure out what was blocking you on Project A, then you can always get back to it.

In Praise Of “Simple” Projects

January 27, 2024 by Elliot Williams 9 Comments

When I start off on a “simple” project, experience shows that it’s got about a 10% chance of actually remaining simple. Sometimes it’s because Plan A never works out the way I think it will, due to either naivety or simply the random blockers that always get in the way and need surmounting. But a decent percentage of the time, it’s because something really cool happens along the way. Indeed, my favorite kind of “simple” projects are those that open up your eyes to a new world of possibilities or experiments that, taken together, are nothing like simple anymore.

Al Williams and I were talking about water rockets on the podcast the other day, and I realized that this was a perfect example of an open-ended simple project. It sounds really easy: you put some water in a soda bottle, pressurize it a bit with air, and then let it go. Water gets pushed down, bottle flies up. Done?

Oh no! The first step into more sophistication is the aerodynamics. But honestly, if you make something vaguely rocket-shaped with fins, it’ll probably work. Then you probably need a parachute release mechanism. And then some data logging? An accelerometer and barometer? A small video camera? That gets you to the level of [ARRO]’s work that spawned our discussion.

But it wasn’t ten minutes into our discussion that Al had already suggested making the pressure vessel with carbon fiber and doctoring the water mix to make it denser. You’d not be surprised that these and other elaborations have been tried out. Or you could go multi-stage, or vector-thrust, or…

In short, water rockets are one of those “simple” projects. You can get one basically working in a weekend day, and then if you’re so inclined, you could spend an entire summer of weekends chasing down the finer points, building larger and larger tubes, and refining payloads. What’s your favorite “simple” project?

Hardware Should Lead Software, Right?

January 20, 2024 by Elliot Williams 26 Comments

Once upon a time, about twenty years ago, there was a Linux-based router, the Linksys WRT54G. Back then, the number of useful devices running embedded Linux was rather small, and this was a standout. Back then, getting a hacker device that wasn’t a full-fledged computer onto a WiFi network was also fairly difficult. This one, relatively inexpensive WiFi router got you both in one box, so it was no surprise that we saw rovers with WRT54Gs as their brains, among other projects.

Of course, some people just wanted a better router, and thus the OpenWRT project was born as a minimal Linux system that let you do fancy stuff with the stock router. Years passed, and OpenWRT was ported to newer routers, and features were added. Software grew, and as far as we know, current versions won’t even run on the minuscule RAM of the original hardware that gave it it’s name.

Enter the ironic proposal that OpenWRT – the free software group that developed their code on a long-gone purple box – is developing their own hardware. Normally, we think of the development flow going the other way, right? But there’s a certain logic here as well. The software stack is now tried-and-true. They’ve got brand recognition, at least within the Hackaday universe. And in comparison, developing some known-good hardware to work with it is relatively easy.

We’re hardware hobbyists, and for us it’s often the case that the software is the hard part. It’s also the part that can make or break the user experience, so getting it right is crucial. On our hacker scale, we often choose a microcontroller to work with a codebase or tools that we want to use, because it’s easier to move some wires around on a PCB than it is to re-jigger a software house of cards. So maybe OpenWRT’s router proposal isn’t backwards after all? How many other examples of hardware designed to fit into existing software ecosystems can you think of?

New Year’s Resolutions

January 6, 2024 by Elliot Williams 18 Comments

As we stand here looking at the brand-new year ahead, we find ourselves taking stock, and maybe thinking how we can all be better people in the next year. More exercise, being nicer to your neighbors, consuming more or less of this or that, depending on whether it’s healthy or un. Those are the standard fare. But what’s your hacker new year’s resolution?

Mine, this year, is to branch out into a new microcontroller family, to learn a new toolchain, and maybe to finally dip my toes into Bluetooth Low Energy. Although that last one is admittedly a stretch.

But the former is great resolution material, if you allow me. New programming tooling is always a little unpleasant to set up, but there’s also payoff at the end of the ordeal. It’s a lot like picking up a new exercise – it makes you stronger. Or course, it helps to have an application in mind, the equivalent of that suit you want to be able to fit into at the end of the diet. I’ve got one. I’ve also been out of programming in straight C for a year or so, and I’m faced with a new HAL, so there’s bound to be enough of a challenge to make it worthwhile.

Honestly, I’m looking forward to getting started, but with the usual mix of optimism, over-optimism, and mild dread. It’s the perfect setup for a resolution! What’s yours?

(And yes, the art is from another story, but setting up a good backup regime isn’t a bad resolution either.)

You Can’t Make What You Can’t Measure

December 16, 2023 by Elliot Williams 30 Comments

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.