Wonderful Foldable Printable Dodecahedron

June 20, 2022 by Elliot Williams 14 Comments

Debra Ansell of [GeekMomProjects] fame came up with a neat, 3D design that prints flat and then folds up into everyone’s favorite Platonic solid: a D12.

Why would you want to do this? Well, folding up your 3D prints gives you a third dimension “for free” without using all that support material. Here, all of the outside faces of the dodecahedron are printed flat against the build plate, which is probably the nicest side of your prints. And embedding LEDs in the resulting shape would probably be easy because they’re all in plane. And speaking of LEDs, we kinda expected to see them here, given Debra’s motto: “LEDs improve everything” — that part is up to you.

Debra notes that she likes PETG instead of PLA for the extra strength in the thin-printed hinges, and we’d bet that your printer’s tolerances will need to be spot on for the clips that hold the whole thing together. (We’d be tempted to apply a little super-duper glue.)

As always with Debra’s projects, there’s some creative solutions on display here that’ll help you out whether you need a D12 or a D20, so give it a look!

Thanks [Peter] for the tip.

Continue reading “Wonderful Foldable Printable Dodecahedron” →

Blinking An Arduino LED, In Julia

June 20, 2022 by Elliot Williams 11 Comments

The Julia programming language is a horrible fit for a no-frills microcontroller like the ATMega328p that lies within the classic Arduino, but that didn’t stop [Sukera] from trying, and succeeding.

All of the features that make Julia a cool programming language for your big computer make it an awful choice for the Arduino. It’s designed for interactivity, is dynamically typed, and leans heavily on its garbage collection; each of these features alone would tax the Mega to the breaking point. But in its favor, it is a compiled language that is based on LLVM, and LLVM has an AVR backend for C. Should just be a simple matter of stubbing out some of the overhead, recompiling LLVM to add an AVR target for Julia, and then fixing up all the other loose ends, right?

Well, it turns out it almost was. Leaning heavily on the flexibility of LLVM, [Sukera] manages to turn off all the language features that aren’t needed, and after some small hurdles like the usual problems with volatile and atomic variables, manages to blink an LED slowly. Huzzah. We love [Sukera’s] wry “Now THAT is what I call two days well spent!” after it’s all done, but seriously, this is the first time we’ve every seen even super-rudimentary Julia code running on an 8-bit microcontroller, so there are definitely some kudos due here.

By the time that Julia is wedged into the AVR, a lot of what makes it appealing on the big computers is missing on the micro, so we don’t really see people picking it over straight C, which has a much more developed ecosystem. But still, it’s great to see what it takes to get a language designed around a runtime and garbage collection up and running on our favorite mini micro.

Thanks [Joel] for the tip!

The Box: Think Outside Of It

May 28, 2022 by Elliot Williams 19 Comments

There’s no single recipe for creativity, as far as I know. But this week on the Podcast, Tom Nardi and I were talking about a number of hacks that were particularly inventive, out-of-the-box, or just simply “how did they think of that?”. One possible route to something new is learning from other disciplines.

We were talking about an inspiring video about 3D printing fabrics. At the moment, the design world is going crazy for all things 3DP, so it’s no surprise to see someone with a design background asking herself how to make stuff that comes off the 3D printer more flexible, and fit her needs a little bit better. But what if those of us on the building-purely-functional side of things took what the fabric folks learned and applied it to our work? You’d get something like this hybrid approach to folding mechanisms, or this approach to remove supports from your prints.

I’m continually surprised by how much the home-gamer can learn from industry, and this week was also no exception. [Anne Ogborn]’s piece on handling bulk material draws mostly on the hard work of engineers who are worried about properly emptying gigantic grain silos or feeding tons of screws into small boxes to ship out to customers. But the same physics are at work when you’re designing an automatic dry cat food dispenser for your next vacation, just on a smaller scale.

How about you? What things have you learned from other disciplines, possibly entirely unrelated ones, that have helped you with your hacking?

Show Us Your Odd Inputs And Peculiar Peripherals!

May 24, 2022 by Elliot Williams 17 Comments

Just as the Jedi youngling would have to build their light saber, so is it a rite of passage for a true geek to build their own computer interfaces. And nothing makes a personal computer more personal than a custom keyboard, a bespoke mouse, an omnipotent macropad, a snazzy jog wheel, or a fancy flight yoke.

In this contest, we encourage you to make your strangest, fanciest, flashiest, or most custom computer peripherals, and share that work with all the rest of us. Wired or wireless, weird or wonderful, we want to see it. And Digi-Key is sponsoring this contest to offer three winners an online shopping spree for $150 each at their warehouse! More parts, more projects.

Make It Yours

Anyone can just go out an buy a keyboard, but if you want a custom ergonomic keyboard that’s exactly fit to your own two hands, you probably have to make one with your own two hands. And if you an engraved brass mouse, well, you’ve got some engraving to do — Logitech ain’t gonna make one for you. Maybe you only type in binary, or maybe you need a keyboard for some alien language that has 450 individual letters. Or maybe the tiniest keyboard ever? You’ve got this. Continue reading “Show Us Your Odd Inputs And Peculiar Peripherals!” →

2022 Hackaday Prize: Congratulations To The Planet-Friendly Power Finalists!

May 23, 2022 by Elliot Williams 1 Comment

The 2022 Hackaday Prize is focused on lightening our load on the planet, and one obvious way to do so is to get and store renewable power locally — the theme of our first challenge round: Planet-Friendly Power. Our judges have studied all the entries and their votes are in. All of these ten projects will receive $500 right now and are eligible for the Grand Prize of $50,000, to be announced in November.

Most of the alternative energy sources you’d expect to see were represented: solar, wind, and water. But everyone brought their own twists to the topic. For instance, the Low Cost Solar Panel Solution demonstrates that there’s a lot more to a DIY solar project than just the panel. You need to support it, protect it, turn it to face the sun, and convert and store the power harvested. And [JP Gleyzes] even goes so far as to use recycled water bottles to make the 3D-printed parts. Sun Chaser 2 puts the panel on wheels, driving it out of the shade to collect maximum energy in a real-world backyard situation. Cute!

Finally, we had two great kite projects to harvest wind with minimal setups on the go: Kite Propulsion and Energy Independence While Travelling. Both are still in the experimental stages, but both have great documentation of where the research projects stand.

Finally, Moss Microbial Fuel Cell is really out there on the edge of current research. Combining the reasonably well established microbial fuel cell with the photosynthetic power of moss, [Guru-san] is able to light an LED for a few seconds at a time. It’s not much, but it’s also a desktop-scale project. And who can say no to leaf-shaped capacitor circuit sculptures to store the energy?

Hacker Power!

Those are just a few of the ten finalists, listed here in no particular order. Congratulations to all of you! We’re excited to follow your projects along their journey, and wish you all the best.

Ten Finalists from Planet-Friendly Power

One Solution, Many Problems

May 21, 2022 by Elliot Williams 7 Comments

You might think you’re lucky when one of your problems has multiple solutions, and you get to pick and choose, but you’re even luckier when one solution has many problems! This week I stumbled on an old solution in a new place. The project was a fantastic old MIDI guitar build, the Tryndelka by [Aleksandr Goltsov]. And the old solution? Switch matrix diodes.

You see, [Aleksandr] is making an electric guitar where the strings are pulled up to a certain voltage and then make contact with metal frets. Each fret is cut into six pieces, so that the strings can be read out individually, and the microcontroller scans each string in succession to test if it’s pressed down or not. Done, right? Wrong! The problem comes when two or more strings are pressed at once — the electrical path from the string you want will travel through the closed switch on a string that you’re not scanning. The solution is a ton of diodes.

I learned this problem the hard way in wiring up a MAME cabinet, at about 3 A.M. the night before we were going to bring it to Shmoocon. We finally got the whole USB/button code working, so we played some celebratory rounds of Street Fighter. We eventually noticed that hitting one button, or even moving the joystick in a particular direction, would block some of the other buttons from working, or change their function entirely. Quick Internet search later, and we were hand soldering 64 diodes until dawn. Good times!

But the fact that switch matrices need diodes, and exactly why, is forevermore burned in my brain. It’s fun to see it pop up in all sorts of contexts, from DIY keyboards to MIDI guitars, to Charliplexing. (It’s the “D” in LED!) It’s one of the classics — a solution to many problems.

Who Is Thinking About Open Source Firmware?

May 14, 2022 by Elliot Williams 23 Comments

Yesterday, we ran a post on NVIDIA’s announcement of open-source drivers for some of its most recent video cards. And Hackaday being huge proponents of open-source software and hardware, you’d think we’d be pouring the champagne. But it’s trickier than that.

Part of the reason that they are able to publish a completely new, open-source driver is that the secrets that they’d like to keep have moved into the firmware. So is the system as a whole more or less open? Yeah, maybe both.

With a more open interface between the hardware and the operating system, the jobs of people porting the drivers to different architectures are going to be easier. Bugs that are in what is now the driver layer should get found and fixed faster. All of the usual open-source arguments apply. But at the same time, the system as a whole isn’t all that much more transparent. The irony about the new NVIDIA drivers is that we’ve been pushing them to be more open for decades, and they’ve responded by pushing their secrets off into firmware.

Secrets that move from software to firmware are still secrets, and even those among us who are the most staunch proponents of open source have closed hardware and firmware paths in our computers. Take the Intel Management Engine, a small computer inside your computer that’s running all the time — even while the computer is “off”. You’d like to audit the code for that? Sorry. And it’s not like it hasn’t had its fair share of security relevant bugs.

And the rabbit hole goes deeper, of course. No modern X86 chips actually run the X86 machine language instructions — instead they have a microcode interpreter that reads the machine language and interprets it to what the chip really speaks. This is tremendously handy because it means that chip vendors can work around silicon bugs by simple pushing out a firmware update. But this also means that your CPU is running a secret firmware layer at core. This layer is of course not without bugs, some of which can have security relevant implications.

This goes double for your smartphone, which is chock-full of multiple processors that work more or less together to get the job done. So while Android users live in a more open environment than their iOS brethren, when you start to look down at the firmware layer, everything is the same. The top layer of the OS is open, but it’s swimming on top of an ocean of binary blobs.

How relevant any of this is to you might depend on what you intend to do with the device. If you’re into open source because you like to hack on software, having open drivers is a fantastic resource. If you’re looking toward openness for the security guarantees it offers, well, you’re out of luck because you still have to trust the firmware blindly. And if you’re into open source because the bugs tend to be found quicker, it’s a mix — while the top level drivers are made more inspectable, other parts of the code are pushed deeper into obscurity. Maybe it’s time to start paying attention to open source firmware?