Commercialization And Innovation

August 1, 2026 by Elliot Williams 12 Comments

The last year or two has seen relatively affordable multi-material printers hit the market, and the question that [Tom Nardi] and I were kicking around when he was writing up the 2025 year-in-review article was what it was going to mean for our folks. I don’t think he got it wrong per se, but his heading for that section “Grandma is 3D-Printing in Color” only tells half the story.

He did get that part right, though. We’ve certainly seen a flourishing of multi-material designs out there that take advantage of the availability of (usually) four colors. The ability to print in color has given life to the purely decorative models, of course. Think full-color Pokemon desktop toys, for instance. But even functional prints have benefited from contrasting color labels printed right into the box, not to even mention the multi-material supports that pull off easier and cleaner than ever before.

Since most of these multi-filament machines are pretty much locked down as far as hardware tinkering goes, our sights were firmly locked on what the end-user would do with the new capability. But we overlooked the third axis of 3D printering: the software hackers. And it’s precisely in this area of slicer and path-planning that we’ve seen some of the coolest developments this year. Why? Because people have the hardware in their hands that they need to test out the algorithms.

FullSpectrum and the more recent ImageMap are two techniques to get the missing in-between colors out of a four-filament printer, and in particular ImageMap tries to get the job done faster, and with fewer purges. We are amazed to see two different approaches to color blending popping up in just a few months of each other, and we have no doubt that work on this is going to continue.

At the end of the day, this really is just “put new tools in the hands of creative hackers, and they’ll find new ways to use them”, so we shouldn’t have been surprised at all. But if this is what comes out of the commercialization of the multi-material printer, what’s going to come when some of the more esoteric machine designs go mainstream? We can’t wait to find out!

Add Sensors To Everything!

July 25, 2026 by Elliot Williams 25 Comments

“You can’t control what you can’t measure” goes the old chestnut. But that’s a little bit negative, in my opinion. Instead, think of the benefits of sprinkling sensors around everywhere: you gain insight where you simply didn’t have it beforehand.

We were thinking about this in the context of the recent video on pressure advance in 3D printers. Essentially, the unmelted filament acts as a springy piston, and that springiness means that the pressure built up in the melted plastic lags the feedrate of new filament. We usually calibrate this out with a guesstimate constant, but it can be different for every different filament. Measuring that pressure directly with a strain gauge in the hot end makes more sense.

But then there are knock-on benefits of having a sensor in the hot end. You can use the strain gauge as Prusa does to run the nozzle gently into the bed and set the z-axis height. Or you can use over-pressure as a sign that the nozzle is clogged. It’s quite possible that you can use it to signal other things that can go wrong as well, but you can’t tell until you put the sensor on in the first place.

Of course, you don’t want to put a pressure sensor where you want to know the temperature, or vice-versa. But as a general rule, the more you can measure, the more you can discover about the way your system is running. How many strain gauges are too many?

When Changing Scale Isn’t Just More Of The Same

July 11, 2026 by Elliot Williams 22 Comments

[Jenny] and I were talking about [Bitluni]’s experiment in scale, where he will take 65,536 cheap microcontrollers, network them all together, and give each one an RGB pixel. From there, antics will surely ensue. Right now, he’s only got 8,192 of them up and running, and already the novel problems and opportunities are rearing their heads.

We all know it from our own hacking. In theory, doing something ten times is ten times doing it once. But then in practice, entirely new phenomena appear as you scale up that were simply not there in the small. Maybe it happens when you repeat it one hundred times, or a thousand.

Viewed positively, this is the property of emergence: how the whole can be more than the sum of its parts, and how biology isn’t just chemistry multiplied by a few million interactions. In our blinky world, a massive wall of LEDs is a display, not just a bunch of pixels.

On the flip side, going from one microcontroller with a 10 mA current draw to 64 Ki controllers, with 655 A, is more than just a difference in scale. You need to learn a new skill set to handle the problem. Making a single prototype is a different problem from making a run of badges for a conference of 5,000 – you’ll need a team, and won’t be able to just hack it alone – not to even mention the parts sourcing woes.

So I loved watching [Bitluni] going through the upscaling. He certainly had an idea of what he was getting himself into, but as with the emerging properties of a big system, there are often emerging problems, and those you can’t always see ahead of time. Have you gotten into a project that scaled itself into something qualitatively different? Tell us about it.

Yesterday’s Technology, Re-engineered Today

July 4, 2026 by Elliot Williams 12 Comments

Watching [sprite_tm]’s build of a handheld 486-based gaming computer, we got to thinking about retro computers and the eternal questions of how much of the computer needs to be actually “old” for it it be retro. Where is the soul of a retro computer? The CPU? The old yellowing plastic case? Maybe it depends on what you’re trying to get out of the hobby.

There is of course a spectrum of people playing around with old computers. For some people, let’s call them “vintage computer enthusiasts”, half of the fun is in keeping the actual old hardware running. This group tends to know what teletype lubricant smells like, and how to tell which capacitors need replacing.

For others, “team retro”, the joy is in using the machine itself, whether that be teaching the old dogs new tricks, or simply loading up nostalgic video games. Team retro is more content with emulations or emulations that are wrapped up neatly in hardware workalikes. They know which registers need POKEing, and whether or not Commander Keen is running at the right framerate.

I think [sprite_tm]’s project falls in with yet another camp, the retro-reengineers. Here, the idea is to step through the engineering lessons of the past by re-designing something from a bygone era. So when [sprite_tm] went with a period 486 CPU backed up by a modern FPGA, perhaps ironically borrowing code from the modern MiSTer project, it makes sense for his goals. Retro-reengineers know the bus architecture and the memory timings, and they are reinventing the wheel as a learning experience. Or in the case of [Voja Antonic]’s imaginary four-bit machine, it’s a teaching experience.

How you work often reflects what you’d like to get out of the project, and at Hackaday, of course, we love all of the above! We’ve identified at least three broad schools of fooling around with old computers. Are we missing any?

Hacking Routers Like It’s 2008

June 27, 2026 by Elliot Williams 19 Comments

How long have we been hacking routers? To some of you who’ve been in the Hackaday audience for a while, the answer is “nearly forever”. In the early 2000s, they were one of the few consumer gadgets that had the trifecta of hackability: WiFi and networking built in, a user-friendly Linux operating system, and a few spare GPIOs that could control from the OS. Back when the Linksys WRT54GL was the king of the hill, we saw some pretty absurd hacks.

Take this example robot from October 2008. Link-rot hasn’t been kind to the original project, but from what we can tell, it used the GPIOs to drive servo motors hacked for continuous rotation, and features the equally anachronistic CD-ROM wheels. Where would you even get those today?

But the OS that this 18-year-old hack uses is still around: OpenWRT Linux. Although it still takes its name from the lovable purple router of old, it hasn’t supported that particular model in over a decade because of growing memory requirements. But it’s still the go-to distro for any modern router hacks, and it provides a lot more general-purpose Linux than you might expect on otherwise constrained platforms. As Tom pointed out in the podcast, if you see a used router for cheap, see if it’s supported by OpenWRT, and if it is, buy it.

While the project that got us thinking about routers again, Al’s recent networking hack, basically uses the router as a souped-up router, that’s by no means a given. OpenWRT is a real Linux OS, and can make use of most peripherals that your router find has available. Networking? Of course. USB? No problem. If you find a serial port and some GPIOs, you’re most of the way to a Linux SBC, although very likely a headless one.

There are a lot of hacks we see go in and out of style, and we see software projects come and go. But here we tip our hat to the router hacks, and to the plucky Linux OS that’s been ported to them all. Long may it keep old devices out of the landfill!

Featured image: My old baby, about a year or so before something in the radio modem finally gave up the ghost.

Home Automation: Simple Vs Easy

June 20, 2026 by Elliot Williams 39 Comments

We’ve been talking a bunch of home automation on the Podcast lately, and this week, in the Mailbag segment, a reader asked us about our setups. Neither Kristina nor I are poster children for the home automation movement: she has absolutely no smart anything because she didn’t want her data up in “the cloud”, and I have an entirely local system that’s really nothing more than a bunch of ad-hoc scripts that talk to an MQTT broker, everything fully DIY but held together with metaphorical duct tape. Neither of us are doing it right, but we’re doing it wrong in interestingly different ways.

Kristina thought, probably because of the range of commercial devices out there that tie you into using their remote data storage services, that giving up control of her data was necessary to use it. And it might be, if you insist that setting up the system be as easy as possible. But the tradeoff for this ease is a drastic reduction in simplicity. You shouldn’t need a remote server in some foreign country to turn your lights on and off. Adding “the cloud” into the mix brings a lot of complexity, mostly in the form of servers that have to be paid for somehow by whatever company is providing the service. It needs to be secure. You might even have to create accounts, remember passwords, and manage that whole deal. Sure, that’s easy enough, but it’s a lot of moving parts, and you can’t blame her for rejecting that complexity.

My system is hosted on a now-ancient OrangePi in the corner, and the network in question is an old WiFi router that it sits on. Nothing needs to leave my four walls, but actually some of it does – I bridge some of the MQTT topics out to an external server for my own amusement. There is no protocol, and no real “system” frankly. Each device in the network has its own topic, and I’m responsible for knowing what it means. The thermometer in the basement has an ESP8266 that transmits on the home/basement/temperature topic, and it puts out its temperature in degrees Celsius. It was the simplest system I could think of, but I have to write whatever software I want to log, display, or act on the data. Of course, that’s simple if you can write some four-liner scripts on the OrangePi broker, but it’s not easy enough that my wife wants to hack on it.

So if the full-buy-in commercial systems are easy but overly complex, and my DIY network is transparently simple but requires a level of hands-on that isn’t easy for “normies”, is there a middle ground? I know half of you are already screaming Home Assistant or Domoticz, and you’re also thinking of which client device libraries you like the most for all your DIY applications: ESPHome vs Tasmota, for instance. And you’re all right!

We are living the in the golden age of the home automation projects. Open-source software and firmware, combined with an abundance of online tutorials and worked examples, have made huge strides toward bridging the gap between simplicity and ease of use. You can set up a hub for everything on a single-board computer, upload the software of your choice, and you don’t need the complexity or loss-of-support liability of a cloud provider. At the same time, setup is easy enough if you’re willing to roll up your sleeves a little bit, and when it’s not, chances are good that someone else has already figured it out for you. These days, interoperability with popular commercial products is shockingly easy to boot.

I need to spend some time and rationalize my system: given the state of the art, it’s simply too simple, and taking a step into an open-source solution would make it easier to use for the rest of the family, without overly complexifying things, adding sketchy dependencies, or losing our data sovereignty. I haven’t finished exploring my options yet, but from what I can see, the community has converged on some goldilocks setups: not too simple or too easy, but rather just right. Thanks, y’all!

Patterns Everywhere

June 13, 2026 by Elliot Williams 23 Comments

I studied physics in college, and I’m always surprised how fundamental some of the concepts are. Take waves for example. You really wouldn’t expect the same underlying concept to be at work on surface of a pond, the string of a guitar, light passing through two slits, and then in the probabilistic behavior of electrons orbiting inside nuclei. But here we are, in a world filled with wave-like phenomena.

What little control theory I know, I’ve learned in the school of hard knocks. But it’s equally amazing that the same basic concepts govern the tuning of car shock absorbers, PID controllers, active audio filters, and other more complex systems where feedback matters. Crucial in all of these systems is the judicious balance of amplification and damping.

And last week on vacation, learning to drive a covered wagon pulled by a heavy draft horse, I saw the same patterns again. The horse likes to pull, and when the wagon comes over the crest of the top of a hill, it starts to roll forward into his harness, pushing him from behind. This makes the horse uneasy, and he slows down, the wagon pushes him harder, and positive feedback gets out of control.

The man who was teaching me to drive the wagon said, “it’s not like a car” in that you don’t tap the brakes to slow down and then let go. Rather, you hold on the brakes for a lot longer than you think is necessary – until the horse tells you that he feels like pulling again – and then you let up only a tiny bit at a time. Otherwise, you end up in the under-damped case, where you let the wagon go too much, it slows the horse, you slam the brakes, the horse pulls hard, and you let up on the brakes, and the cycle continues anew.

What he meant by “not like a car” was that the brakes aren’t just slowing down the wagon, they’re adding damping to keep the horse-wagon system from oscillating. Once that clicked in my mind, everything was smooth sailing. After a couple of days, I even started adding some feed-forward to my mental PID controller, letting the brakes go a little bit more when the horse was approaching the bottom of a hill, and he obviously wanted to pick up a little more speed before the grade ahead.

The horse seemed happy that I was finally getting it, but I don’t think he had any understanding of tuning PID loops. He did have me pondering, on a long stretch of rolling hills on a summer morning, if there were a good minimal set of patterns that explained a maximal breadth of phenomena. I’m starting with the physics of waves and the control of feedback systems, but what’s next?