Welcome Back, Voyager

In what is probably the longest-distance tech support operation in history, the Voyager mission team succeeded in hacking their way around some defective memory and convincing their space probe to send sensor data back to earth again. And for the record, Voyager is a 46-year old system at a distance of now 24 billion kilometers, 22.5 light-hours, from the earth.

While the time delay that distance implies must have made for quite a tense couple days of waiting between sending the patch and finding out if it worked, the age of the computers onboard probably actually helped, in a strange way. Because the code is old-school machine language, one absolutely has to know all the memory addresses where each subroutine starts and ends. You don’t call a function like do_something(); but rather by loading an address in memory and jumping to it.

This means that the ground crew, in principle, knows where every instruction lives. If they also knew where all of the busted memory cells were, it would be a “simple” programming exercise to jump around the bad bits, and re-write all of the subroutine calls accordingly if larger chunks had to be moved. By “simple”, I of course mean “incredibly high stakes, and you’d better make sure you’ve got it right the first time.”

In a way, it’s a fantastic testament to simpler systems that they were able to patch their code around the memory holes. Think about trying to do this with a modern operating system that uses address space layout randomization, for instance. Of course, the purpose there is to make hacking directly on the memory harder, and that’s the opposite of what you’d want in a space probe.

Nonetheless, it’s a testament to careful work and clever software hacking that they managed to get Voyager back online. May she send for another 46 years!

The Long And The Short Of It

Last weekend was Hackaday Europe 2024, and it was great. Besides having some time to catch up with everyone, see some fun new badge hacks, and of course all the projects that folks brought along, I also had time to attend most all of the talks. And the talks were split into two distinct sections: long-format talks on Saturday and a two-hour session of seven-minute lightning talks on Sunday.

I don’t know if it’s our short attention spans, or the wide range of topics in a short period of time, but a number of people came up after the fact and said that they really appreciated the short-but-sweet format. One heretic even went so far as to suggest that we only have lightning talks in the future.

Well, we’ve done that before – the Hackaday Unconferences. One year, we even ran three of them simultaneously! I was at Hackaday’s London Unconference the year later, and it was a blast.

But I absolutely appreciate the longer talks too. Sometimes, you just have to give a speaker free rein to dig really deeply into a topic. When the scope of the project warrants it, there’s just no substitute for letting someone tell the whole story. So I see a place for both!

If you were at Hackaday Europe, or any other conference with a lightning talks track, what do you think? Long or short? Or a good mix?

Too Much Over-optimization Is Never Enough!

A discussion came up on the Hackaday Discord PCB design channel about resistor networks, and it got me thinking about whether we (the hacker community) use them in designs or not. These handy devices often take the shape of an IC, SMD or otherwise, but between the pins are a bunch of resistors instead of active silicon. They come in all sorts of configurations and tolerances, but the point is usually the same: When you need a bunch of similar resistors, it’s cheaper to go with a network package.

But how much cheaper? I did a quick search for 1 kΩ resistors and the corresponding network, and came up with similar prices for the resistors and networks – but the network has eight resistors in it! That’s an eightfold savings! Which, at a price of roughly one cent per piece, is less than a dime. While it’s certainly true that if you’re making a million widgets, saving a penny per widget matters. But do you spend the time to optimize your projects down to such margins? I want to say “of course not!” but maybe you do?

For me, worrying about seven cents in a PCB design that I may make ten of is foolishness. But still, I’ve used resistor networks for their other side effects: the resistors in a common package tend to be very tightly matched, even if their overall tolerance isn’t. If you’re making something like an R-2R DAC, that’s a definite advantage. Or if you’re space constrained, or just hate placing lots of tiny resistors, the networks shine.

I often forget about resistor networks, and when I do think of them, I think of them in terms of cost savings in industrial applications. But maybe that’s not fair – maybe they do have their hacker uses as well. Are there other parts like this that we should all know about?

It’s About Time

I’m pretty good with time zones. After all, I live in Germany, Hackaday’s server is in Los Angeles, and our writers are scattered all over the globe. I’m always translating one time into another, and practice makes (nearly) perfect. But still, it got me.

I was in the states visiting my parents, when Daylight Saving Time struck, but only in the USA. Now all my time conversions were off by an hour, and once I’d worked through the way the sun travels around the globe, I thought I had it made. And then my cell phone started reporting a time that was neither CEST nor EDT, but a third time zone that was an hour off. Apparently some cell towers don’t transmit time zone information, and my phone defaults to UTC. Who knew? For a short while, my phone lied to me, the microwave oven clock in the hotel lied to me, and I felt like I was going nuts.

But this all got me thinking about clocks and human time, and possibly the best advice I’ve ever heard for handling it in your own programs. Always keep time in something sensible like UNIX time – seconds elapsed since an epoch – because you don’t have to worry about anything more than adding one to a counter every second. When and if you need to convert to or from human times, you can write the function to do that simply enough, if you don’t already have a library function to do so.

Want to set an alarm for 2 hours from now? That’s easy, because you only need to add 7,200 seconds, and you don’t need to worry about 59 wrapping around to 0 or 23:59 to 0:00. Time math is easy in seconds. February 29th? That’s just another 86,400 seconds. It’s only us humans who make it complicated.

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.)