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.

About Right

I really enjoyed reading Anne Ogborn’s piece on making simple DIY measurement devices for physical quantities like force, power, and torque. It is full of food for thought, if you’re building something small with motors and need to figure out how to spec them out.

A Push Stick

Aside from a few good examples, what I really took home from this piece is how easy it can be to take approximate measurements. Take the push stick, which is a spring-loaded plunger in a transparent barrel. You use it to measure force by, well, squeezing the spring and reading off how far it deflects. That’s obvious, but the real trick is in calibration by pushing it into a weighing scale and marking divisions on the barrel. That quickly and easily turns “it’s pressing this hard” into an actual numerical force measurement.

The accuracy and precision of the push stick are limited by the quality of your scale and the fineness of the pen tip that you use to mark the barrel. But when you’re just looking to choose among two servo motors, this kind of seat-of-the-pants measure is more than enough to buy the right part. Almost any actual measurement is better than a wild-ass guess, so don’t hold yourself to outrageous standards or think that improvised quantitative measurement devices aren’t going to get the job done.

Al Williams quoted a teacher of his as saying that the soul of metrology is “taking something you know and using it to find something you don’t know”, and that sums up this piece nicely. But it’s also almost a hacker manifesto: “take something you can do and use it to do something that you can’t (yet)”.

Got any good measurement hacks you’d like to share?

Institutional Memory, On Paper

Our own Dan Maloney has been on a Voyager kick for the past couple of years. Voyager, the space probe. As a long-term project, he has been trying to figure out the computer systems on board. He got far enough to write up a great overview piece, and it’s a pretty good summary of what we know these days. But along the way, he stumbled on a couple old documents that would answer a lot of questions.

Dan asked JPL if they had them, and the answer was “no”. Oddly enough, the very people who are involved in the epic save a couple weeks ago would also like a copy. So when Dan tracked the document down to a paper-only collection at Wichita State University, he thought he had won, but the whole box is stashed away as the library undergoes construction.

That box, and a couple of its neighbors, appear to have a treasure trove of documentation about the Voyagers, and it may even be one-of-a-kind. So in the comments, a number of people have volunteered to help the effort, but I think we’re all just going to have to wait until the library is open for business again. In this age of everything-online, everything-scanned-in, it’s amazing to believe that documents about the world’s furthest-flown space probe wouldn’t be available, but so it is!

It makes you wonder how many other similar documents – products of serious work by the people responsible for designing the systems and machines that shaped our world – are out there in the dark somewhere. History can’t capture everything, and it’s down to our collective good judgement in the end. So if you find yourself in a position to shed light on, or scan, such old papers, please do! And then contact some nerd institution like the Internet Archive or the Computer History Museum.

Tool-Building Mammals

It’s often said of us humans that we’re the only “tool-using mammals”. While not exclusive to the hacker community, a bunch of us are also “tool-building mammals” when we have the need or get the free time. I initially wanted to try to draw some distinction between the two modes, but honestly I think all good hackers do both, all the time.

We were talking about the cool variety of test probes on the podcast, inspired by Al Williams’ piece on back probes. Sometimes you need something that’s needle-thin and can sneak into a crimp socket, and other times you need something that can hold on like alligator clips. The infinite variety of jigs and holders that make it easier to probe tiny pins is nothing short of amazing. Some of these are made, and others bought. You do what you can, and you do what you need to.

You can learn a lot from looking at the professional gear, but you can learn just as much from looking at other hackers’ bodge jobs. In the podcast, I mentioned one of my favorite super-low-tech hacks: making a probe holder out of a pair of pliers and a rubber band to hold them closed. Lean this contraption onto the test point in question and gravity does the rest. I can’t even remember where I learned this trick from, but I honestly use it more than the nice indicator-arm contraptions that I built for the same purpose. It’s the immediacy and lack of fuss, I think.

So what’s your favorite way of putting the probe on the point? Home-made and improvised, or purpose-built and professional? Or both? Let us know!

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?