Degrees Of Freedom, But For Whom?

Opening up this week’s podcast, I told Kristina about my saga repairing our German toilet valve. I’m American, and although I’ve lived here over a decade, it’s still surprising how things can be subtly different from how they worked back home.

But what was amazing about this device was that it had a provision for fine adjustment, and to some extent relied on this adjustment to function. Short version: a lever mechanism provides mechanical advantage to push a stopper against the end of a pipe to block the water flow, and getting the throw of this mechanism properly adjusted so that the floater put maximum pressure against the pipe required fine-tuning with a screw. But it also required understanding the entire mechanism to adjust it.

Which makes me wonder how many plumbers out there actually take the time to get that right. Are there explicit instructions in the manual? Does every German plumber learn this in school? I was entirely happy to have found the adjustment screw after I spent 15 minutes trying to understand the mechanism, because it did just the trick. But is this everyone’s experience?

I often think about this when writing code, or making projects that other people are likely to use. Who is the audience? Is it people who are willing to take the time to understand the system? Then you can offer them a screw to turn, and they’ll appreciate it. But if it’s an audience that just doesn’t want to be bothered, the extra complexity is just as likely to cause confusion and frustration.

The Physics Lesson I Keep Re-Learning

One of the most broadly applicable ideas I’ve ever encountered is the concept of impedance matching. If you’re into radio frequency electronics, you’re probably thinking that I mean getting all your circuit elements working to a common characteristic resistance for maximum power transfer. (If you’re not, you’re probably wondering what that jumble of words even means. Fear not!)

But I mean impedance matching in the larger sense. Think about driving a stick-shift automobile. In low gear, the engine has a lot of torque on the wheels, but it can’t spin them all that fast. In high, the wheels turn fastest, but there’s not enough torque to get you started from a standstill. Sometimes you need more force and less motion, other times more motion and less force. The gearbox lets you match the motor’s power to the resistance – the impedance – it’s trying to overcome.

Or think about a cello. The strings are tight, and vibrate with quite a bit of force, but they don’t move all that much. Air, which is destined to carry the sound to your ear, doesn’t take much force to move, and the cello would play louder if it moved more of it. So the bridge conveys the small, but strong, vibrations of the strings and pushes against the top of the resonant box that makes up the body of the instrument. This in turn pushes a lot of air, but not very hard. This is also why speakers have cones, and also why your ear has that crazy stirrup mechanism. Indeed, counting the number of impedance matches between Yo Yo Ma and your brain, I come up with four or five, including electrical matches in the pre-amp.

I mention this because I recently ran into a mismatch. Fans blow air either hard or in large volume. If you pick a fan that’s designed for volume, and put it in a pressure application, it’s like trying to start driving in fifth gear. It stalled, and almost no air got pushed up through the beans in my new “improved” coffee roaster, meaning I had to rebuild it with the old fan, and quick before the next cup was due.

I ran into this mismatch even though I knew there was a possible impedance issue there. I simply don’t have a good intuitive feel how much pressure I needed to push the beans around – the impedance in question – and I bought the wrong fan. But still, knowing that there is a trade-off is a good start. I hope this helps you avoid walking in my footsteps!

Procrastineering And Simulated Annealing

The software for the Supercon badge went down to the wire this year, with user-facing features being coded up as late as Thursday morning. This left “plenty of time” to flash the badges on Thursday afternoon, but they were admittedly still warm as the first attendees filed in on Friday morning. While I’ve always noted that the last minute is the best minute, this was a little close, and frankly there was an uncaught bug that we would have noticed if we had a few more hours to just play with it before showtime.

But we were by no means slacking. On the contrary, a few of us were putting in nights and full weekend days for six or eight weeks beforehand. The problem was hard, and the path to a solution was never clear, and changed depending on the immovability of the roadblocks hit along the way. This is, honestly, a pretty normal hacker development pattern.

What was interesting to me was how similar the process was to simulated annealing. This is an optimization method where you explore more of the solution space in the beginning, when the metaphorical “temperature” is hot. Later, as you’re getting closer to a good solution, you want to refine in smaller and smaller steps – it cools down. This rate of “cooling” is a tremendously important parameter in practice.

And this is exactly the way the badge development felt. We were searching in a very big solution space in the beginning, and many aspects of the firmware infrastructure were in flux. As it got closer and closer to a working solution, more and more of the code settled down, and the changes got smaller. In retrospect, this happened naturally, and you can’t always control or plan for the eureka moments, but I wonder if it’s worth thinking of a project this way. Instead of milestones, temperatures? Instead of a deadline, a freeze date.

Supercon And Soylent Green

The 2023 Hackaday Supercon is all done and dusted, and we’re still catching up on our sleep. I couldn’t ask everyone, but a great time was had by everyone I talked to. It’s honestly a very special crowd that shows up in Pasadena every November, and it’s really the attendees who make it what it is. We just provide the platform to watch you shine. Thank you all!

It all started out on Friday with an open day of chilling out and badge experimentation. Well, chill for those of you who didn’t have a bug in their badge code, anyway. But thanks to some very keen observation and fantastic bug reports by attendees, Al and I figured out what we’d done and pushed a fix out to all 300 of the badges that were given out on the first day. And thanks to the remaining 200 folks who walked in the next day, who fixed their own badges at Tom’s Flashing Station.

From then on, it was one great talk after another, punctuated by badge hacks and all the other crazy stuff that people brought along with them to show off. For me, one of the highlights was on Sunday morning, as the Lightning Talks gave people who were there a chance to get up and talk about whatever for seven minutes. And subjects ranged from a mad explosive propane balloon party, to Scotty Allen’s experience with a bad concussion and how he recovered, to a deep dive into the world of LED strands and soft sculptures from our go-to guru of blinkiness, Debra [Geek Mom] Ansell.

Supercon first-timer Katie [Smalls] Connell gave a phenomenal talk about her wearable LED art things, Spritelights. These are far from simple art pieces, being a combination of medical adhesive, home-mixed Galinstan – a metal alloy that stays flexible at human body temperature, and soon even flexible printed batteries. That this whole project hit us without warning from out of the audience just made it more impressive.

And these were just the folks who stepped up on stage. The true story of Supercon also belongs to all the smaller conversations and personal demos taking place in the alley or by the coffee stand. Who knows how many great ideas were hatched, or at least seeds planted?

So as always, thank you all for coming and bringing your passions along with. Just like Soylent Green, Supercon is made of people, and it wouldn’t be half as yummy without you. See you all next year. And if you’re thinking of joining us, get your tickets early and/or submit a talk proposal when the time comes around. You won’t meet a more warm and welcoming bunch of nerds anywhere.

Impostor Syndrome: It’s Not Your Fault!

[Crispernaki] and I have something in common. We both saw this awesome project that made a scroll wheel out of a VHS head back in 2010, and wanted to make one. We both wanted to put our own spin on the gadget, (tee-hee), discovered that it was harder than either of us wanted to commit to, and gave up.

Flash forward about a million Internet years, and [crispernaki] finally made his and wrote it up. The only problem is that it was too easy. In 2010, making USB gadgets was a lot more involved than it is today. (Back then, we had to chisel device descriptors on stone tablets.) Nowadays, the firmware is just a matter of importing the right library, and the hardware is a magnetic rotation sensor breakout board, a magnet, and super glue. Cheap, and easy.

All of this led our hero to feeling insecure. After all, a hack that beat him a dozen years ago turned out to be dead easy today. Maybe it was too easy? Maybe he wasn’t a “real” hacker? These are the signs of impostor syndrome – that feeling that just because you aren’t the world’s best, or climbing the highest mountain, or hacking the hardest project, you’re not worthy.

Well, listen up. Impostors don’t finish projects, and impostors don’t write them up to share with all the rest of us. By actually doing the thing – hacking the hack – all chances of being a fake are ruled out. The proof is sitting there on your desk, in all its Altoids-tin glory.

And it’s not your fault that it was too easy this time around. You can’t do anything to turn back the hands of time, to make the project any harder these days, or to undo the decade of hacker technical progress on the software side, much less change the global economy to make a magnetic sensor unobtainable again. The world improved, you got your hack done, and that’s that. Congratulations! (Now where do I buy some of those on-axis magnets?)

The Eternal Dilemma

It’s two weeks until Supercon! We can almost smell the solder from here. If you’re coming, and especially if it’s your first time, you’re soon to be faced with the eternal dilemma of hacker cons, only at Supercon it’s maybe a trilemma or even a quadralemma: hang out with folks, work on the badge, go to talks, or show off all the cool stuff you’ve been working on the past year?

Why not all four? That’s exactly why we start off with a chill-out day on Friday, when we don’t have much formally planned. Sure, there’s a party Friday night, and maybe a badge talk or some workshops, but honestly you’ll have most of the day free. Ease into it. Have a look at the badge and start brainstorming. Meet some new people and start up a team. Or just bathe in the tremendous geekery of it all. This is also a great time to show off a small project that you brought along. Having the widget that you poured brain, sweat, and tears into sitting on the table next to you is the perfect hacker icebreaker.

On Saturday and Sunday, there will definitely be talks that you’ll want to attend, so scope that out ahead of time and plan those in. But don’t feel like you have to go to all of them, either. Most of the talks will be online, either right away or eventually, so you won’t miss out forever. But since our speakers are putting their own work out there, if you’re interested in the subject, having questions or insight about their talk is a surefire way to strike up a good conversation later on, and that’s something you can’t do online. So plan in a few talks, too.

You’ll find that the time flies by, but don’t feel like you have to do it all either. Ask others what the coolest thing they’ve seen is. Sample as much as you can, but it’s not Pokemon – you can’t catch it all.

See you in two weeks!

(PS: The art is recycled from a Supercon long, long ago. I thought it was too nice to never see it again.)

Close To The Metal

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!