Hacking And Working On The Go

I’m off visiting my parents for a while, and have managed to bring nearly everything along with me that I need to get work done, and it all fit in a small backpack! This includes a portable audio interface to run my podcast mic, two (count them) two Linux computers, and all manner of simple hacking tools. Microcontrollers with USB/serial adapters built in are a godsend.

But putting together the minimal setup was no easy task! Alone the USB cable assortment I had to bring was astounding. And in the end, it looks like I forgot a USB-B mini, and good luck finding that at the local drug store. (I know! But the Zoom recorder wants mini. Don’t ask me why.)

And then there’s the power adapters — brick for the laptop, USB-C fast charger for the Steam Deck, another wall-plug USB for recharging the power banks. And of course, this silly custom keyboard which I’m so used to typing on, and which embodies so much muscle memory in its macros that I’m practically helpless without it.

So fundamentally, I’m astounded by the amount of functionality I could cram into my pack, but I’m also aghast at all the little things that add up around the edges. And I’m sure that I’ll find stuff that I’m missing in the next few weeks.

Do you need to travel for work with your full kit? What’s your approach? Minimal? Maximal? Leave us your hacker travel kit tips in the comments.

Sometimes It’s The Little Things

I had one of those why-didn’t-I-think-of-it moments this week, reading this article about multiplexing I2C on the ESP32 microcontroller. The idea is so good, and so simple, that it’s almost silly that it’s not standard hacker practice. And above all, it actually helps solve a problem that I’ve got. This is why I read Hackaday every day.

I2C is great in that it lets you connect up multiple devices to a pair of wires using a very bus architecture. Every device has its own address, the host calls them out, and hopefully all other devices keep quiet while just the right one responds. But what happens when you want to use a few of the same sensors, where each IC has the same address? The usual solution is to buy a multiplexer chip.

But many modern microcontrollers, like the ESP32, have an internal multiplexer setup that lets you map the pins with the dedicated hardware peripherals, usually at initialization time. Indeed, I’ve been doing it as an “init” task so long, I never thought to do it otherwise. But that’s exactly the idea behind [BastelBaus]’s hack – if you dynamically reassign the pins, you can do the I2C multiplexing with the chip you’ve got. This should probably work for any other chips that have multiple assignable pins for hardware peripherals as well.

Cool idea, but really simple. Why hadn’t I ever thought of it? I think it’s because I’ve always had this init / mainloop schema in my mind, which for instance the Arduino inherited and formalized in its setup() and loop() functions. Pin mappings go in the init section, right?

So what this hack really amounts to, for me, is a rethinking of what’s static and what’s dynamic. It’s always worth questioning your assumptions, especially when you’re facing a problem that requires a creative solution. Sometimes limitations are only in your mind. Have you had your mind opened recently by a tiny little hack?

Want To Learn Binary? Draw Space Invaders!

This was the week that I accidentally taught my nearly ten-year-old son binary. And I didn’t do it on purpose, I swear.

It all started innocently enough. He had a week vacation, and on one of those days, we booked him a day-course for kids at our local FabLab. It was sold as a “learn to solder” class, and the project they made was basically a MiniPOV: eight LEDs driven by a museum-piece AVR ATtiny2313. Blinking lights make a pattern in your persistence of vision as you swipe it back and forth.

The default pattern was a heart, which is nice enough. But he wanted to get his own designs in there, and of course he knows that I know how to flash the thing with new code. So I got him to solder on an ISP header and start drawing patterns on grids of graph paper while I got the toolchain working and updated some of the 2000’s-era code so it would compile.

There’s absolutely no simpler way to get your head around binary than to light up a row of LEDs, and transcribing the columns of his fresh pixel art into ones and zeros was just the motivation he needed. We converted the first couple rows into their decimal equivalents, but it was getting close to dinner time, so we cheesed out with the modern 0b00110100 format for the rest. This all happened quite organically; “unintentional parenting” is what we call it.

While we were eating dinner, I got the strangest sense of deja vu. When I was around ten or eleven, my own father told me about the custom fonts for the Okidata 24-pin printer at his lab, because he needed me out of his hair for a while, and I set out to encode all of the Hobbit runes for it. (No comment.) He must have handed me a piece of graph paper explained how it goes, and we had a working rune font by evening. That was probably how I learned about binary as well.

Want to teach someone binary? Give them a persistence of vision toy, or a dot-matrix printer.

(Art is from a much older POV project: Trakr POV — a hack of an old kids’ toy to make a long-exposure POV image. But it looks cool, and it gets the point across.)

Wireless All The Things!

Neither Tom Nardi nor I are exactly young anymore, and we can both remember a time when joysticks were actually connected with wires to the computer or console, for instance. Back then, even though wireless options were on the market, you’d still want the wired version if it was a reaction-speed game, because wireless links just used to be too slow.

Somehow, in the intervening years, and although we never even really noticed the transition as such, everything has become wireless. And that includes our own hacker projects. Sure, the ESP8266 and other WiFi-capable chips made a big difference, but I still have a soft spot in my heart for the nRF24 chipset, which made at least point-to-point wireless affordable and easy. Others will feel the same about ZigBee, but the point stands: nothing has wires anymore, except to charge back up.

The reason? As this experiment comparing the latency of many different wireless connections bears out, wireless data links have just gotten that good, to the point that the latency in the radio is on par with what you’d get over USB. And the relevant software ecosystems have made it easier to go wireless as well. Except for the extra power requirement, and for cases where you need to move a lot of data, there’s almost no reason that any of your devices need wires anymore.

Are you with us? Will you throw down your chains and go wireless?

One Project At A Time, Or A Dozen?

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

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?

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.

Long Live the WRT54G

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?