New Parts, New Hacks

The biggest news this week is that Raspberry Pi is no longer synonymous with single-board Linux computers: they’re dipping their toes into the microcontroller business with their first chip: the RP2040, and the supporting breakout board, the Pico. It’s an affordable, capable microcontroller being made by a firm that’s never made microcontrollers before, so that’s newsy.

The Hackaday comments lit on fire about this chip, with some fraction of the commenters lamenting the lack of wireless radios onboard. It’s a glass-half-full thing, I guess, but the RP2040 isn’t an ESP32, folks. It’s something else. And it’s got a hardware trick up its sleeve that really tickles my fancy — the programmable input/output (PIO) units.

The other half of the commenters were, like me, salivating about getting to try out some of the new features. The PIO, of course, was high on that list, but this chip also caters to folks who are doing high-speed DSP, with fast multiplication routines burnt into ROM and a nice accumulator. (You know you’re a microcontroller nerd when you’re reading through a 663-page datasheet and thinking about all the funny ways you can use and/or abuse the hardware peripherals.)

All chip designs are compromises. Nothing can do everything. The new peripherals, novel combinations of old elements, and just pleasant design decisions, open up new opportunities if you’re willing to seek them out. When the ESP32 was new, I was looking at their oddball parallel-I2S hardware and thinking what kind of crazy hacks that would enable, and clever hackers have proven me right. I’d put my money on the PIO being similar.

New chips open up new possibilities for hacks. What are you going to do with them?

Hackability Matters

The Unix Way™ provides extreme hackability. The idea is that software should be written as tools to accomplish discrete tasks, and that it should be modular, extensible, and play well with others. It’s like software as a LEGO set — you can put the blocks together however you want, within limits, and make stuff that’s significantly cooler than any of the individual blocks alone.

Clearly this doesn’t work for all applications — things like graphics editors and web browsers don’t really lend themselves to being elegant tools that integrate well with others, right? It’s only natural that they’re bloaty walled gardens. What happens in the browser must stay in the browser, right?

But how sad is it that the one piece of software you use all day, your window into cyberspace, doesn’t play well with the rest of your system? I’d honestly never really been bothered by that fact until stumbling on TabFS. It’s an extension to Chrome that represents the tabs on your browser as if they were files on your local system — The Unix Way™. And what this means is that any other program that can read from or write to a file can open tabs, collect them, change webpages on the fly, and so on. It opens up the browser to you.

This is tremendously powerful. Don’t like the bookmarking paradigm of your particular browser? Writing your own would be a snap in Python — and you could do cleverer things like apply a little machine learning to handle putting them in categories. Want to pop open (or refresh) a set of webpages at a particular time every day? Cron, or its significantly more complicated counterpart systemd, and a couple lines of code will do that. Want to make a hardware button that converts dark mode to light mode and vice-versa for every website starting with “H”? Can do.

I’m picking on browsers, but many large pieces of software are inaccessible in the same way — even if they’re open source, they don’t open up channels for interaction with user code or scripts. (Everything “in the cloud” or “as a service”, I’m looking at you! But that’s a further rant for another day.) And that’s a shame, because most of these “big” pieces of software actually do the coolest things.

So please, if you’re working on a big software package, or even just writing a plug-in for one, do think about how you can make more of its abilities available to the casual scripter. Otherwise, it’s just plastic blocks that don’t fit with the rest of the set.

How Much Is Too Much?

I definitely tend towards minimalism in my personal projects. That often translates into getting stuff done with the smallest number of parts, or the cheapest parts, or the lowest tech. Oddly enough that doesn’t extend to getting the project done in the minimum amount of time, which is a resource no less valuable than money or silicon. The overkill road is often the smoothest road, but I’ll make the case for taking the rocky, muddy path. (At least sometimes.)

There are a bunch of great designs for CNC hot-wire foam cutters out there, and they range from the hacky to the ridiculously over-engineered, with probably most of them falling into the latter pile. Many of the machines you’ll see borrow heavily from their nearest cousins, the CNC mill or the 3D printer, and sport hardened steel rails or ballscrews and are constructed out of thick MDF or even aluminum plates.

All a CNC foam cutter needs to do is hold a little bit of tension on a wire that gets hot, and pass it slowly and accurately through a block of foam, which obligingly melts out of the way. The wire moves slowly, so the frame doesn’t need to handle the acceleration of a 3D printer head, and it faces almost no load so it doesn’t need any of the beefy drives and ways of the CNC mill. But the mechanics of the mill and printer are so well worked out that most makers don’t feel the need to minimize, simply build what they already know, and thereby save time. They build a machine strong enough to carry a small child instead of a 60 cm length of 0.4 mm wire that weighs less than a bird’s feather.

I took the opposite approach, building as light and as minimal as possible from the ground up. (Which is why my machine still isn’t finished yet!) By building too little, too wobbly, or simply too janky, I’ve gotten to see what the advantages of the more robust designs are. Had I started out with an infinite supply of v-slot rail and ballscrews, I wouldn’t have found out that they’re overkill, but if I had started out with a frame that resisted pulling inwards a little bit more, I would be done by now.

Overbuilding is expedient, but it’s also a one-way street. Once you have the gilded version of the machine up and running, there’s little incentive to reduce the cost or complexity of the thing; it’s working and the money is already spent. But when your machine doesn’t quite work well enough yet, it’s easy enough to tell what needs improving, as well as what doesn’t. Overkill is the path of getting it done fast, while iterated failure and improvement is the path of learning along the way. And when it’s done, I’ll have a good story to tell. Or at least that’s what I’m saying to myself as I wait for my third rail-holder block to finish printing.

Why You Need To Finish

Mike and I were talking about an interesting smart-glasses hack on the podcast. This was one of those projects where, even if you don’t need a pair of glasses with LEDs on them to help you navigate around, you just couldn’t help but marvel at a lot of the little design choices made throughout.

For instance, I love the way the flex PCB is made to do double duty by wrapping around the battery and forming a battery holder. This struck me as one of those quintessential hacks that only occurs to you because you need it. Necessity is the mother of invention, and all that. There was a problem, how to fit a battery holder in the tiny space, and a set of resources that included a flex PCB substrate. Cleverly mashing that all together ended up with a novel solution. This wouldn’t occur to you if you were just sitting at the beach; you’d have to be designing something electronic, space-constrained, and on a flex PCB to come up with this.

Mike made an offhand comment about how sometimes you just need to finish a project for the good ideas and clever solutions that you’ll come up with along the way, and I think this battery holder example drives that point home. I can’t count the number of my projects that may or may not have been dumb in retrospect, but along the way I came up with a little trick that I’ll end up using in many further projects, outliving the original application.

Finishing up a project on principle is a reasonable goal just on its own. But when the process of seeing something to conclusion is the generator of new and interesting challenges and solutions, it’s even more valuable. So if you’re stuck on a project, and not sure you want to take it all the way, consider if the journey itself could be the destination, and look at it as an opportunity to come up with that next long-lasting trick.

Bad News: Arecibo

If you read the newsletter last week, you heard me wondering aloud if the damage to Arecibo Observatory had crossed the threshold into where it’s no longer economically viable to keep it running, and the sad news has just come in and the battle for Arecibo has been lost. We said we’d shed a tear, and here we are. Sic transit gloria mundi. Here’s hoping something cooler replaces it!

What Is Worth Saving?

When it rain, it pours. One of the primary support cables holding up the Arecibo Observatory dish in Puerto Rico has just snapped, leaving its already uncertain fate. It had been badly damaged by Hurricane Maria in 2017, and after a few years of fundraising, the repairs were just about to begin on fixing up that damage, when the cable broke. Because the remaining cables are now holding increased weight, humans aren’t allowed to work on the dome until the risk of catastrophic failure has been ruled out — they’re doing inspection by drone.

Arecibo Observatory has had quite a run. It started out life as part of a Cold War era ICBM-tracking radar, which explains why it can transmit as well as receive. And it was the largest transmitting dish the world had. It was used in SETI, provided the first clues of gravitational waves, and found the first repeating fast radio bursts. Its radar capabilities mean that it could be used in asteroid detection. There are a number of reasons, not the least of which its historic import, to keep it running.

So when we ran this story, many commenters, fearing the worst, wrote in with their condolences. But some wrote in with outrage at the possibility that it might not be repaired. The usual suspects popped up: failure to spend enough on science, or on infrastructure. From the sidelines, however, and probably until further structural studies are done, we have no idea how much a repair of Arecibo will cost. After that, we have to decide if it’s worth it.

Per a 2018 grant, the NSF was splitting the $20 M repair and maintenance bill with a consortium led by the University of Central Florida that will administer the site. With further damage, that might be an underestimate, but we don’t know how much of one yet.

When do you decide to pull the plug on something like this? Although the biggest, Arecibo isn’t the only transmitter out there. The next largest transmitters are part of Deep Space Network, though, and are busy keeping touch with spacecraft all around our solar system. For pure receiving, China’s FAST is bigger and better. And certainly, we’ve learned a lot about radio telescopes since Arecibo was designed.

I’m not saying that we won’t shed a tear if Arecibo doesn’t get repaired, but it’s not the case that the NSF’s budget has been hit dramatically, or that they’re unaware of the comparative value of various big-ticket astronomy projects. Without being in their shoes, and having read through the thousands of competing grant proposals, it’s hard to say that the money spent to prop up a 70 year old telescope wouldn’t be better spent on something else.

Tired Of The Cat-and-Mouse

Facebook just announced their plans for the Oculus Quest 2 VR headset. You probably won’t be surprised, but they want more of your user data, and more control over how you use the hardware. To use the device at all, you’ll need a verified Facebook account. Worse, they’re restricting access to the wide world of community-developed applications by requiring a developer account to be able to “sideload” non-Facebook software onto the device. Guess who decides who gets to be a developer. Hint: it’s not the people developing software.

Our article suggests that this will be the beginning of a race to jailbreak the headset on the community’s part, and to get ahead of the hackers on Facebook’s. Like every new release of iOS gets a jailbreak within a week or two, and then Apple patches it up as fast as they can, are we going to see a continual game of hacker cat-and-mouse with Facebook?

I don’t care. And that’s not because I don’t care about open hardware or indie VR developers. Quite the opposite! But like that romance you used to have with the girl who was absolutely no good for you, the toxic relationship with a company that will not let you run other people’s games on their hardware is one that you’re better off without. Sure, you can try to fix it, or hack it. You can tell yourself that maybe Facebook will come around if you just give them one more chance. It’s going to hurt at first.

But in the end, there is going to be this eternal fight between the user and the company that wants to use them, and that’s just sad. I used to look forward to the odd game of cat and mouse, but nowadays the cats are just too well bankrolled to make it a fair fight. If you’re buying a Quest 2 today with the intent of hacking it, I’d suggest you spend your time with someone else. You’re signing up for a string of heartbreaks. Nip it in the bud. You deserve better. There are too many fish in the sea, right?

What are our options?

Scratching That Itch

I did something silly. I bought a lot of ten “broken” cheesy indoor quadcopters on eBay — to hopefully cobble one working one together and to amuse my son. At this point, I’ve got eight working. The bad news is that they all come with dirt-cheap transmitters that aren’t really conducive to flying at all. They’d be a lot more fun if they could be controlled with a real remote. Enter the hackers.

Most all of the cheap quads are based on one of a handful of radio chipsets, although they use different protocols. An enterprising hacker could conceivably just bundle together this handful of radio modules, and the rest would be a simple matter of software. That’s exactly what Pascal Langer’s DIY Multiprotocol TX and supporting firmware does. This hobby project was so successful that compatible hardware is manufactured by more than a few Chinese companies, and non-geeks have them installed in their radios. The module lets you control virtually anything that uses 2.4 GHz. Of course, I’ve got one of them.

I opened up the cheesy drone’s transmitter, found that it used a popular chipset, and worked through all the different supported protocols that used it. No dice. But the radio module did have nicely labeled SPI lines, so I reached out to Pascal. A couple of Sigrok sessions later, he’d figured out that it was trying to bind on a different channel, I’d recompiled the firmware, and was playing with the drone’s other functions.

I just love a good SPI-sniffing session. sigrok-cli -d fx2lafw -c samplerate=4000000 -P spi:clk=D0:mosi=D1:cs=D2 -A spi="mosi transfer" --continuous | grep A0 | uniq reads the SPI lines, decodes the packets, filters out the commands, and removes duplicates, in real-time. All that’s left to do is wiggle the sticks, mash buttons, and take good notes.

None of this was hard, and certainly none of it was expensive. I got my drones under the control of my fancy-schmancy remote, and have a good foothold into controlling them algorithmically later on thanks to everyone’s previous work on reverse engineering these protocols. Support for DF Drone’s SkyTumbler will be included in the next DIY Multiprotocol TX release, and I spent about four or five pleasant hours on this project. Maybe only a handful of people will stumble on this particular protocol — or maybe it will just be me. I did it mostly just to scratch my own particular itch.

But that’s one way open source works, thrives, and grows. Here’s to you all out there, from the Deviation team, who did a lot of the early drone protocol reverse engineering, to Pascal for the DIY Module, to the Sigrok folks who made the tools accessible for me to piggyback on everyone’s previous work. Keep on hacking!