It’s Not Unusual To Love Hacking

Most of what we do here at Hackaday is look out for cool projects and then write them up so that you all know about them. Nothing is better than being really stoked about a clever hack and then being able to share it with tens of thousands of like-minded folks. Sure, it’s our job, but we really do it because we love to share. And it’s clear that you all do too! After all, we write up the hacks that you document for us.

We recently featured a hack where the guy who did the work in question said that he didn’t think it was “worthy of Hackaday”. (Of course, it was!) And I don’t like that sentiment at all, honestly, because a hack that you enjoyed doing is a hack worth sharing, even if just for sharing the joy of doing it, and that came across fully.

Of course we gladly feature the ultra-bravado hacks where the nearly impossible is made real. But there’s equal value in the simple hacks that inspire others to pursue one odd path or another. Or even pieces where there’s no hack involved, but simply the sharing of something cool.

This week, [Arya Voronova] wrote a piece about her experience using MicroPython on embedded devices, and it apparently resonated with a lot of our readers. It’s not a deep-dive into MicroPython, or a mind-bending abuse of the language. Instead, it’s a simple “this is what I love about doing things this way”, and that’s a great perspective that often gets lost when we get deep in the technical weeds.

I had the same realization a few months back at Hackaday Europe. In the lightning talks, most everyone gave talks about cool projects that they are working on, and they’re absolutely worth watching for that. [Jaap Meijers] gave a wonderful talk about making animated QR codes, but it wasn’t about how he invented animated QR codes, because he was just using someone else’s project. Instead, it was about how neat he thought someone else’s work was, and how he really wanted to share it with us. (And now you know too.)

Epic hacks are fantastic, no question. But the simple expression of the love of hacking, whether in words or in the doing, is equally important. Show us your work, but don’t forget to show us your joy along the way.

Halfway Between Inspiration And Engineering

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

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!

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

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!

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

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.