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!

Get Over Your Fears

Some projects are just too complex, that’s for sure. But I’d be willing to bet that some things you think are too difficult actually aren’t, and it may be that all you need to get over your personal hurdle is a good demonstration. Here come three cases in point.

I was looking at the new Raspberry Pi Compute Module last weekend. They have a whole bunch of high-speed traces: things like Gigabit Ethernet, HDMI, and those crazy-fast SDI serial camera interfaces. I have no experience in high-speed design and layout at all, and frankly it gives me the willies. But the Raspberries also shipped me an IO demo board, and concomitant KiCAD design files, with the review board. Looking at it, they were just wires — maybe pairwise length-matched and impedance controlled — but also just wires. Opening up the KiCAD board file and clicking on the traces just like I do with my own designs, I’m a lot less scared. That was a revelation for me.

In a great writeup of his experience building ten different Linux single-board-computers from scratch, Jay Carlson had a similar effect on me. I would never have considered breaking out the hotplate for some CPU-and-DRAM action, and I’ve never had to lay out a PCB with a high density BGA chip before either. I’m not quite into Dunning-Kruger territory yet; I still have a healthy respect for the layout intricacies in fanning out a tight BGA CPU into a DRAM. But Jay’s frank assessments of what is easy and what is hard make it all seem within the realm of the doable.

As Mike and I were talking on the podcast about Jay’s work, Mike came clean about his fear of BGAs. I’ve done enough reflow-plate soldering, with parts that have a lead pitch that’s a factor of two finer than the 0.8 mm pitch BGAs in question, so it doesn’t seem implausible to me. And I’m 100% sure Mike could pull it off too, but he is in need of a BGA guru. Any good hobbyist videos out there?

Being a nerdy type, I’m much more focused on the knowledge and the inspiration, but maybe the courage is equally important — at least I think I undervalue it. I don’t need to lay out HDMI lines, or build a from-scratch Linux box, but I am no longer afraid that I couldn’t, and that’s because I’ve seen detailed examples of fellow hackers who’ve done the same. I might not get it right on the first shot, but I’m not afraid to try, and I wouldn’t have said the same before looking over other folks’ shoulders. Forza e corragio!

Spare Parts Express

I’ve got spare parts, and I cannot lie.

This week I’m sending out two care packages to friends and coworkers because I’ve got too many hackables on hand, and not enough time to hack them all. One is a funky keyboard, and the other is an FPGA dev board, but that’s not the point. The point is that the world is too interesting, and many of us have more projects piled up in the to-do box, with associated gear, than we’ll ever have time to complete.

Back in the before-times, we would meet up, talk about our ongoing hacks, and invariably someone would say “oh you need an X, I’ve got half a box of them” and send you one. Or maybe you’d be the one with the extra widgets on hand. I know I’ve happily been in both positions.

Either way, it’s a win for the giver, who gets to take a widget off the widget pile, for the receiver, who doesn’t have to go to the widget store, and for the environment, which has to produce fewer widgets. (My apologies to the widget manufacturers and middlemen.)

This reminded me of Lenore Edman and Windell Oskay’s Great Internet Migratory Box Of Electronics Junk back in the late aughts. Trolling through the wiki was like a trip down memory lane. This box visited my old hackerspace, and then ended up with Bunnie Huang. Good times, good people, good hacker junk! And then there’s our own Brian Benchoff’s Travelling Hacker Box and spinoffs.

These are great and fun projects, but they all end up foundering in one respect: to make sense, the value of goods taken and received has to exceed the cost of the postage, and if you’re only interested in a few things in any given box, that’s a lot of dead weight adding to the shipping cost.

So I was trying to brainstorm a better solution. Some kind of centralized pinboard, where the “have too many h-bridge drivers” folks can hook up with the “need an h-bridge” people? Or is this ad-hoc social network that we already have working out well enough?

What do you think? How can we get the goods to those who want to work on them?

Hardware Vs Software: Fight!

It’s one of the great cliches in the hacker world: the hardware type and the software type. You can tell which of these two you are quite easily. When a project is actually 20% done, but you think it’s 90% done, and you say to yourself “And the rest is a simple matter of software”, you’re a hardware type. Ask anyone who has read my code, and they’ll tell you, I’m a hardware type.

Along with my blindness to the difficulties of getting the code right, I’ve also admittedly got an underappreciation of what powers lie in the dark typing arts. But I am not too proud to tip my hat when I see an awesome application of the soft stuff. Case in point: this Go board sequencer that we ran last week. An overhead webcam parses players’ moves as they put black and white stones down while playing the game of Go, and turns this into music.

The pure software type will be saying “but there’s a webcam and a Go board”. And indeed, that’s true. There are physical elements to this project that anchor it in the shared reality of the two people playing. But a hardware project this isn’t; it’s OpenCV and Max/MSP that make it work.

For comparison, look at the complexity of this similar physical sequencer. It’s got a 16 x 16 array of LEDs and switches and a CNC milled, primed, and painted surface that’s the size of a twin bed. Sawdust and hand-soldering: that’s a hardware project.

What I love about the Go sequencer is that it uses software just right. The piece is still physical. It could have just as easily been a VR world, where the two people would interact with each other only inside their goggles. But somehow that’s not quite as human as putting stones on a wooden board, sitting across from, and maybe even looking at, your opponent. The players aren’t forced to think about the software. They don’t feel like they’re playing a video game.

But at the same time, the software side of things makes all of the horrible hardware problems go away. Nobody is soldering a rat’s nest of 169 switches. There’s a webcam plugged into the USB port of a laptop. There’s a deep simplicity there.

Should you always trade out arcade buttons for OpenCV? Absolutely not! But is it worth considering the soft side when doing it in hardware is just too, well, hard? I’m open.

Paying It Forward

It’s all those little things. A month ago, I was working on the axes for a foam-cutting machine. (Project stalled, will pick back up soon!) A week ago, somewhere else on the Internet, people were working on sliders that would ride directly on aluminum rails, a problem I was personally experiencing, and recommended using drawer-glide tape — a strip of PTFE or UHMW PE with adhesive backing on one side. Slippery plastic tape solves the metal-on-metal problem. It’s brilliant, it’s cheap, and it’s just a quick trip to the hardware store.

Just a few days ago, we covered another awesome linear-motion mechanical build in the form of a DIY camera rig that uses a very similar linear motion system to the one I had built as well: a printed trolley that slides on skate bearings over two rails of square-profile extruded aluminum. He had a very nice system of anchoring the spacers that hold the two rails apart, one of the sticking points in my build. I thought I’d glue things together, but his internal triangle nut holders are a much better solution because epoxy doesn’t like to stick to anodized aluminum. (And Alexandre, if you’re reading, that UHMW PE tape is just what you need to prevent bearing wear on your aluminum axes.)

Between these events, I got a message thanking me for an article that I wrote four years ago on debugging SPI busses. Apparently, it helped a small company to debug a problem and get their product out the door. Hooray!

So in one week, I got help from two different random strangers on a project that neither of them knew I was working on, and I somehow saved a startup. What kind of crazy marvelous world is this? It’s become so normal to share our ideas and experience, at least in our little corner of the Internet, that I sometimes fail to be amazed. But it’s entirely amazing. I know we’ve said it before, but we are living in the golden era of sharing ideas.

Thanks to all of you out there, and Read More Hackaday!