Halfway Between Inspiration And Engineering

July 6, 2024 by Elliot Williams 7 Comments

We see a lot of hacks where the path to success is pretty obvious, if maybe strewn with all sorts of complications, land-mines, and time-sinks. Then we get other hacks that are just totally out-of-the-box. Maybe the work itself isn’t so impressive, or even “correct” by engineering standards, but the inner idea that’s so crazy it just might work shines through.

This week, for instance, we saw an adaptive backlight LED TV modification that no engineer would ever design. Whether it was just the easiest way out, or used up parts on hand, [Mousa] cracked the problem of assigning brightnesses to the LED backlights by taking a tiny screen, playing the same movie on it, pointing it at an array of light sensors, and driving the LEDs inside his big TV off of that. No image processing, no computation, just light hitting LDRs. It’s mad, and it involves many, many wires, but it gets the job done.

Similarly, we saw an answer to the wet-3D-filament problem that’s as simple as it could possibly be: basically a tube with heated, dry air running through it that the filament must pass through on it’s way to the hot end. We’ve seen plenty of engineered solutions to damp filament, ranging from an ounce of prevention in the form of various desiccant storage options, to a pound of cure – putting the spools in the oven to bake out. We’re sure that drying filament inline isn’t the right way to do it, but we’re glad to see it work. The idea is there when you need it.

Not that there’s anything wrong with the engineering mindset. Quite the contrary: most often taking things one reasonable step at a time, quantifying up all the unknowns, and thinking through the path of least resistance gets you to the finish line of your project faster. But we still have to admire the off-the-wall hacks, where the way that makes the most sense isn’t always the most beautiful way to go. It’s a good week on Hackaday when we get both types of projects in even doses.

Danger Is My Middle Name

June 29, 2024 by Elliot Williams 75 Comments

Last week, [Al Williams] wrote up a his experience with a book that provided almost too much detailed information on how to build a DIY x-ray machine for his (then) young soul to bear. He almost had to build it! Where the “almost” is probably both a bummer because he didn’t have an x-ray machine as a kid, but also a great good because it was a super dangerous build, of a typical sort for the 1950s in which it was published.

Part of me really loves the matter-of-factness with which “A Boy’s First Book of Linear Accelerators” tells you how you (yes you!) can build a 500 kV van der Graff generator. But at the same time, modern me does find the lack of safety precautions in many of these mid-century books to be a little bit spooky. Contrast this with modern books where sometimes I get the feeling that the publisher’s legal team won’t let us read about folding paper airplanes for fear of getting cut.

A number of us have built dangerous projects in our lives, and many of us have gotten away with it. Part of the reason that many of us are still here is that we understood the dangers, but I would be lying if I said that I always fully understood them. But thinking about the dangers is still our first and best line of defense. Humility about how well you understand all of the dangers of a certain project is also very healthy – if you go into it keeping an eye out for the unknown unknowns, you’re in better shape.

Safety isn’t avoiding danger, but rather minimizing it. When we publish dangerous hacks, we really try to at least highlight the most important hazards so that you know what to look out for. And over the years, I’ve learned a ton of interesting safety tricks from the comments and fellow hackers alike. My ideal, then, is the spirit of the 1950s x-ray book, which encourages you to get the hack built, but modernized so that it tells you where the dangers lie and how to handle them. If you’re shooting electrons, shouldn’t the book also tell you how to stay out of the way?

Thanks For The Great Comments!

June 22, 2024 by Elliot Williams 41 Comments

Every once in a while, there’s a Hackaday article where the comments are hands-down the best part of a post. This happened this week with Al Williams’ Ask Hackaday: How Do You Make Front Panels?. I guess it’s not so surprising that the comments were full of awesome answers – it was an “Ask Hackaday” after all. But you all delivered!

A technique that I had never considered came up a few times: instead of engraving the front of an opaque panel, like one made of aluminum or something, instead if you’re able to make the panel out of acrylic, you can paint the back side, laser or engrave into it, and then paint over with a contrast color. Very clever!

Simply printing the panel out onto paper and laminating it got a number of votes, and for those who are 3D printing the enclosure anyway, simply embossing the letters into the surface had a number of fans. The trick here is in getting some contrast into the letters, and most suggested changing filament. All I know is that I’ve tried to do it by painting the insides of the letters white, and it’s too fiddly for me.

But my absolute favorite enclosure design technique got mentioned a number of times: cardboard-aided design. Certainly for simple or disposable projects, there’s nothing faster than just cutting up some cardboard and taping it into the box of your desires. I’ll often do this to get the sizes and locations of components right – it’s only really a temporary solution. Although some folks have had success with treating the cardboard with a glue wash, paint, or simply wrapping it in packing tape to make it significantly more robust. Myself, if it ends up being a long-term project, I’ll usually transfer the cardboard design to 3DP or cut out thin plywood.

I got sidetracked here, though. What I really wanted to say was “thanks!” to everyone who submitted their awesome comments to Al’s article. We’ve had some truly hateful folks filling the comment section with trash lately, and I’d almost given up hope. But then along comes an article like this and restores my faith. Thanks, Hackaday!

Giant Brains, Or Machines That Think

June 15, 2024 by Elliot Williams 8 Comments

Last week, I stumbled on a marvelous book: “Giant Brains; or, Machines That Think” by Edmund Callis Berkeley. What’s really fun about it is the way it sounds like it could be written just this year – waxing speculatively about the future when machines do our thinking for us. Except it was written in 1949, and the “thinking machines” are early proto-computers that use relays (relays!) for their logic elements. But you need to understand that back then, they could calculate ten times faster than any person, and they would work tirelessly day and night, as long as their motors keep turning and their contacts don’t get corroded.

But once you get past the futuristic speculation, there’s actually a lot of detail about how the then-cutting-edge machines worked. Circuit diagrams of logic units from both the relay computers and the brand-new vacuum tube machines are on display, as are drawings of the tricky bits of purely mechanical computers. There is even a diagram of the mercury delay line, and an explanation of how circulating audio pulses through the medium could be used as a form of memory.

All in all, it’s a wonderful glimpse at the earliest of computers, with enough detail that you could probably build something along those lines with a little moxie and a few thousands of relays. This grounded reality, coupled with the fantastic visions of where computers would be going, make a marvelous accompaniment to a lot of the breathless hype around AI these days. Recommended reading!

Happy Birthday, Tetris!

June 8, 2024 by Elliot Williams 6 Comments

Porting DOOM to everything that’s even vaguely Turing complete is a sport for the advanced hacker. But if you are just getting started, or want to focus more on the physical build of your project, a simpler game is probably the way to go. Maybe this explains the eternal popularity of games like PONG, Tetris, Snake, or even Pac-Man. The amount of fun you can have playing the game, relative to the size of the code necessary to implement them, make these games evergreen.

Yesterday was Tetris’ 40th birthday, and in honor of the occasion, I thought I’d bring you a collection of sweet Tetris hacks.

On the big-builds side of things, it’s hard to beat these MIT students who used colored lights in the windows of the Green Building back in 2012. They apparently couldn’t get into some rooms, because they had some dead pixels, but at that scale, who’s complaining? Coming in just smaller, at the size of a whole wall, [Oat Foundry]’s giant split-flap display Tetris is certainly noisy enough.

Smaller still, although only a little bit less noisy, this flip-dot Tetris is at home on the coffee table, while this one by [Electronoobs] gives you an excuse to play around with RGB LEDs. And if you need a Tetris for your workbench, but you don’t have the space for an extra screen, this oscilloscope version is just the ticket. Or just play it (sideways) on your business card.

All of the above projects have focused on the builds, but if you want to tackle your own, you’ll need to spend some time with the code as well. We’ve got you covered. Way back, former Editor in Chief [Mike Szczys] ported Tetris to the AVR platform. If you need color, this deep dive into the way the NES version of Tetris worked also comes with demo code in Java and Lua. TetrOS is the most minimal version of the game we’ve seen, coming in at a mere 446 bytes, but it’s without any of the frills.

No Tetris birthday roundup would be complete without mentioning the phenomenal “From NAND to Tetris” course, which really does what it says on the package: builds a Tetris game, and your understanding of computing in general, from the ground up.

Can you think of other projects to celebrate Tetris’ 40th? We’d love to see your favorites!

Sometimes It’s Not The Solution

June 1, 2024 by Elliot Williams 54 Comments

Watching a video about a scratch-built ultra-precise switch for metrology last week reminded me that it’s not always the projects that are the most elegant solutions that I enjoy reading about the most. Sometimes I like reading about hackers’ projects more for the description of the problem they’re facing.

A good problem invites you to brainstorm along. In the case of [Marco Reps]’s switches, for instance, they need to be extraordinarily temperature stable, which means being made out of a single type of metal to avoid unintentional thermocouple joints. And ideally, they should be as cheap as possible. Once you see one good solution, you can’t help but think of others – just reading the comments on that article shows you how inspiring a good problem can be. I’m not worried about these issues in any of my work, but it would be cool to have to.

Similarly, this week, I really liked [Michael Prasthofer]’s deep dive into converting a normal camera into a spectrometer. His solutions were all very elegant, but what was most interesting were the various problems he faced along the way. Things that you just wouldn’t expect end up mattering, like diffraction gratings being differently sensitive across the spectrum when light comes in from different angles. You can learn a lot from other people’s problems.

So, hackers everywhere, please share your problems with us! You think that your application is “too niche” to be of general interest? Maybe it’s another example of a problem that’s unique enough to be interesting just on its own. Let’s see what your up against. A cool problem is at least as interesting as a clever solution.

About Right

May 18, 2024 by Elliot Williams 2 Comments

I really enjoyed reading Anne Ogborn’s piece on making simple DIY measurement devices for physical quantities like force, power, and torque. It is full of food for thought, if you’re building something small with motors and need to figure out how to spec them out.

Aside from a few good examples, what I really took home from this piece is how easy it can be to take approximate measurements. Take the push stick, which is a spring-loaded plunger in a transparent barrel. You use it to measure force by, well, squeezing the spring and reading off how far it deflects. That’s obvious, but the real trick is in calibration by pushing it into a weighing scale and marking divisions on the barrel. That quickly and easily turns “it’s pressing this hard” into an actual numerical force measurement.

The accuracy and precision of the push stick are limited by the quality of your scale and the fineness of the pen tip that you use to mark the barrel. But when you’re just looking to choose among two servo motors, this kind of seat-of-the-pants measure is more than enough to buy the right part. Almost any actual measurement is better than a wild-ass guess, so don’t hold yourself to outrageous standards or think that improvised quantitative measurement devices aren’t going to get the job done.

Al Williams quoted a teacher of his as saying that the soul of metrology is “taking something you know and using it to find something you don’t know”, and that sums up this piece nicely. But it’s also almost a hacker manifesto: “take something you can do and use it to do something that you can’t (yet)”.

Got any good measurement hacks you’d like to share?