TechyMagThings

Walking around the alley at Hackaday Supercon 2024, we noticed an interesting project was getting quite a bit of attention, so we got nearer for a close-up. The ‘Circuit Graver’ by [Zach Fredin] is an unconventional PCB milling machine, utilizing many 3D printed parts, the familiar bed-slinger style Cartesian bot layout and a unique cutting head. The cutting tool, which started life as a tungsten carbide lathe tool, is held on a rotary (‘R’) axis but can also move vertically via a flexure-loaded carriage driven by a 13 kg servo motor.

The stocky flexure took a lot of iteration, as the build logs will show. Despite a wild goose chase attempting to measure the cutting force, a complete machine solution was found by simply making everything stiff enough to prevent the tool from chattering across the surface of the FR4 blank. Controlling and maintaining the rake angle was a critical parameter here. [Zach] actually took an additional step, which we likely wouldn’t have thought of, to have some copper blanks pre-fabricated to the required size and finished with an ENIG coating. It’s definitely a smart move!

To allow the production of PCB-class feature sizes compatible with a traditional PCB router, the cutting tool was sharpened to a much smaller point than would be used in a lathe using a stone. This reduced the point size sufficiently to allow feature sizes down to 4 mils, or at least that’s what initial characterization implied was viable.  As you can see from the build logs, [Zach] has achieved a repeatable enough process to allow building a simple circuit using an SMT 74HC595 and some 0402 LEDs to create an SAO for this year’s Supercon badge. Neat stuff!

We see a fair few PCB mills, some 3D printed, and some not. Here’s a nice one that fits in that former category. Milling PCBs is quite a good solution for the rapid prototyping of electronics. Here’s a guide about that.

This week, Jonathan Bennett and Randal Schwartz chat with Daniel Stenberg about curl! How many curl installs are there?! What’s the deal with CVEs? How has curl managed to not break its ABI for 18 years straight? And how did Daniel turn all this into a career instead of just a hobby? Watch to find out!

• https://daniel.haxx.se/
• https://curl.se/

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Humans first visited the Moon in 1969.  The last time we went was 1972, over 50 years ago. Back then, astronauts in the Apollo program made their journeys in spacecraft that relied on remarkably basic electronics that are totally unsophisticated compared to what you might find in an expensive blender or fridge these days. Core among them was the Apollo Guidance Computer, charged with keeping the craft on target as it travelled to its destination and back again.

Marc Verdiell, also known as CuriousMarc, is a bit of a dab hand at restoring old vintage electronics. Thus, when it came time to restore one of these rare and storied guidance computers, he was ready and willing to take on the task. Even better, he came to the 2023 Hackaday Supercon to tell us how it all went down!

Restoration

You might have heard whispers of this effort before, or seen some of our prior coverage. Indeed, the effort to resurrect this Apollo Guidance Computer (AGC) began in earnest back in late 2018. This particular example of the AGC was found in an electronics recycler in 1976, and the plan was to restore it prior to the 50th anniversary of the first Moon landing in 1969. Marc worked with Carl Claunch, Ken Shirriff, and Mike Stewart on the project, and documented much of it on his YouTube channel under the name [CuriousMarc].

As Marc explains, Apollo actually had four main computers. There was the Launch Vehicle Digital Computer (LVDC) which was charged with steering the Saturn V from launch, along with the Flight Control Computer which was actually an analog machine. There were then two identical Apollo Guidance Computers (AGC)—one was in the Apollo Command Module (Apollo CM), and one was in the Lunar Excursion Module (LEM). There was also the Abort Guidance System for handling any situation where things got out of hand. With the aid of old NASA diagrams, Marc shows us where the AGC lived in the Command Module and the LEM.

The Apollo program marked the first time humans had trusted the piloting a spacecraft or aircraft to a computer system. The AGC was designed by MIT, built by Raytheon, and it weighed 70 pounds and drew 50 watts. While it looks bulky and heavy by today’s standards, it was wildly compact and efficient by 1960s standards. The interface for the AGC was the DSKY—short for “Display and Keyboard.” It’s how the astronauts controlled and interacted with the AGC during the mission. The AGC was absolutely mission critical. In the words of NASA engineer Dan Lickly, ‘The AGC did everything.” It was responsible for orienting the spacecraft, controlling rocket burns and guiding the craft into orbit, and for handling the landing of the lunar module as well as re-entry into the Earth’s atmosphere.

Marc tells us how one example of the Apollo Guidance System ended up at an electronics scrapper in 1975, by order of one of NASA’s engineers. It soon ended up in the hands of hacker Jimmie Loocke, who got his hands on a full two tons of Apollo program hardware. Years later, one Mike Stewart reached out to Jimmie, hoping to look at a real AGC and take some measurements for the sake of working on a replica. When this was happening, Jimmie in turn asked if the device could be powered on, and eventually a team was assembled to try and make that happen. The first attempt happened in a Houston hotel room in October 2018, and the project took off from there.

The talk includes tons of glorious internal shots of the AGC, serial number RAY 14, which was built for an engineering test series. The AGC was assembled from stacks of neatly-arranged modules full of integrated circuits, all connected through an elegantly wire-wrapped backplane. In fact, this was one of the earliest computers that relied on integrated circuits. All of these were dual 3-input NOR gates or analog amplifier ICs. As non-flight hardware, most of the modules in this AGC weren’t potted, which had the benefit of making them easier to work on. However, two of the modules for the core memory did have potting which would make them harder to work on.

Repairing and restoring the AGC was aided by official schematics, so the team knew what they were working with. Modules were tested, and the core memory—essentially the RAM—was found bad. There was also no core rope memory—essentially the ROM for the AGC which stored the program. A rope memory emulator from Raytheon was used instead for this engineering test article. This was for ease of development, as it allowed changing the stored program more easily than rewiring a core rope memory device. However, the Raytheon emulator device was undocumented, which took some reverse engineering work to figure out. Still, powering up the device with no RAM or ROM was a positive experience—the AGC still tried to boot and there were some minor signs of life.

The rest of the talk outlines how the AGC was brought fully back to life. The team improvised an FPGA memory emulator, X-rayed failed components, and built replicas of things they couldn’t replace, all in service of the final goal. Sneaky hacks were used to get bits and pieces functional again against the ods.Even connectors had to be remade from scratch since the AGC used long-forgotten standards that are no longer in use. The fact that Marc works for connector supplier Samtec proved particularly useful in this case. Prepare to choke on your beverage when he explains how much that cost.

We won’t spoil the whole journey here, because Marc’s talk is worth watching from start to finish. There are plenty of twists and turns, and all along, you’re waiting for that ultimate delight—the joy every hacker knows when the beleagured machine finally roars into life. Never mind the wonderful heartwarming moments at the end.

It’s simply wonderful to see a dedicate team bring this storied hardware back to life—and even better to see them flying simulator missions with the real AGC hardware doing its thing. It’s a fantastic restoration effort and one that was documented in intimate detail, and it’s joyous that we get to see everything that went into making this happen.

As we all know, when developing software for any platform or simply hacking a bit of code to probe how something works, the ability to deploy code rapidly is a huge help. [Martin Donlon], aka [wickerwaka], is well known in retro gaming and arcade hardware reverse engineering circles and had the usual issues figuring out how an arcade CPU board worked while developing a MiSTer core. Some interesting ASICs needed quite a bit of poking, and changing the contents of socketed ERPOMs is a labour-intensive process. The solution was PicoROM, a nicely designed ROM emulator in a handy DIP-32 form factor.

As the title suggests, PicoROM is based on the Raspberry Pi RP2040. It emulates an 8-bit ROM up to 2MBits in size with speeds up to 100ns. Since it uses the RP2040, USB connectivity is simple, enabling rapid uploading of new images to one (or more) PicoROMs in mere seconds. A vertically orientated USB-C connector allows multiple PicoROMs to be cabled to the host without interfering with neighbouring hardware. The firmware running on core 1 passes data from the internal 264K SRAM, using the PIO block as a bus interface to the target. A neat firmware feature is the addition of a mechanism to use a ROM region as a bidirectional control channel, which the software running on the target can use to communicate back to the host computer. This allows remote triggering of actions and the reporting of responses. Responses which may not be physically observable externally. [Martin] is using this feature extensively to help probe the functionality of some special function chips on the target boards, which is still a slow process but helped massively by reducing that critical software iteration time. The PCB was designed with KiCAD. The project files foe which can be found here.

This isn’t the first time we’ve seen the RP2040 used for ROM emulation; here’s a pile of wires that does the same job. It just isn’t as pretty. Of course, if you really must use EPROMs, then you could give this sweet programmer a look over.

Here’s a design for a split-flap clock that doesn’t do it the usual way. Instead of the flaps showing numbers , Klapklok has a bit more in common with flip-dot displays.

It’s an art piece that uses custom-made split-flaps which flutter away to update the display as time passes. An array of vertically-mounted flaps creates a sort of low-res display, emulating an analog clock. These are no ordinary actuators, either. The visual contrast and cleanliness of the mechanism is fantastic, and the sound they make is less of a chatter and more of a whisper.

The sound the flaps create and the sight of the high-contrast flaps in motion are intended to be a relaxing and calming way to connect with the concept of time passing. There’s some interactivity built in as well, as the Klapklok also allows one to simply draw on it wirelessly with via a mobile phone.

Klapklok has a total of 69 elements which are all handmade. We imagine there was really no other way to get exactly what the designer had in mind; something many of us can relate to.

Split-flap mechanisms are wonderful for a number of reasons, and if you’re considering making your own be sure to check out this easy and modular DIY reference design before you go about re-inventing the wheel. On the other hand, if you do wish to get clever about actuators maybe check out this flexible PCB that is also its own actuator.

Besides Pokémon, there might have been no greater media franchise for a child of the 90s than the Transformers, mysterious robots fighting an intergalactic war but which can inexplicably change into various Earth-based object, like trucks and airplanes. It led to a number of toys which can also change shapes from fighting robots into various ordinary objects as well. And, perhaps in a way of life imitating art, plenty of real-life robots have features one might think were inspired by this franchise like this transforming quadruped robot.

Called the CYOBot, the robot has four articulating arms with a wheel at the end of each. The arms can be placed in a wide array of positions for different operating characteristics, allowing the robot to move in an incredibly diverse way. It’s based on a previous version called the CYOCrawler, using similar articulating arms but with no wheels. The build centers around an ESP32-S3 microcontroller, giving it plenty of compute power for things like machine learning, as well as wireless capabilities for control or access to more computing power.

Both robots are open source and modular as well, allowing a range of people to use and add on to the platform. Another perk here is that most parts are common or 3d printed, making it a fairly low barrier to entry for a platform with so many different configurations and options for expansion and development. If you prefer robots without wheels, though, we’d always recommend looking at Strandbeests for inspiration.

USB 2 hubs are, by now, omnipresent. it doesn’t cost much to add to your board, and you truly have tons of options. The standard option is 4-port hubs – one uplink port to your host, four downlink ports to your devices. If you only have two or three devices, you might be tempted to look for a hub IC with a lower amount of ports, but it’s not worth bothering – just use a 4-port chip, and stock up on them.

What about 7-port chips? You will see those every now and then – but take a close look at the datasheet. Some of them will be two 4-port chips inside a single package, with four of the ports bottlenecked compared to the three other ports – watch out! Desktop 7-port hubs are basically guaranteed to use two 4-port ICs, too, so, again, watch out for bottlenecks. lsusb -t will help you determine the hub’s structure in case you don’t want to crack its case open, thankfully.

Recommendations? I use SL2.1 chips – they’re SO16 package, very unproblematic, to-the-point pinout and easily hand-solderable. CH334 is a close contender, but watch out – there’s like ten different variants of this chip, which differe by both package and pinout, so if you’re buying a chip with a certain letter, you will want to stick to it. Not just that, be careful – different variants run out at different rates, so if you lock yourself into a CH334 variant, consider stocking up on it.

There’s no shortage of Western-origin chips, either – Texas Instruments is a leader here no doubt. If you ever fear of running out of hub ICs in your stock while assembling something, you can prepare for this in advance by leaving 0R footprints under the hub’s package. USB2 doesn’t care for stubs much, and such a hack is very easy to do with SL2.1 in particular. Got two extra ports left over? Put them on a PC-case style dual USB2 9-pin header – there’s never a shortage of fun accessories compatible with it!

Powering USB2 hub ICs is easy – they tend to include a 5 V to 3.3 V linear regulator inside, so you can power them from a 5 V source directly. On the other hand, if you don’t have any 5 V to spare, the overwhelming majority of hub ICs can be powered from 3.3 V directly – usually, that requires shorting the hub’s 5 V input to 3.3 V, but not necessarily. If the datasheet is unclear on 3.3 V-only operation, leave in some 0R jumpers. And, of course, make sure to add 100 nF or similar capacitors – one per hub IC’s power pin. Remember the disclaimer about built-in RC oscillators in MCUs being imprecise? Same goes for hubs – if your hub boasts an internal RC oscillator, don’t trust it, make sure you have a crystal footprint you can populate if you get stability issues.

Putting some USB port pins to the outside world? You will want to protect them from harm – or, rather, you will want to protect your expensive CPU from harm.

Please, Consider ESD Diodes

Bringing USB somewhere far, or even just using it as your link to the external world? You should really use ESD diodes – or at least plan them in and give yourself the option to populate them later. There’s no shortage of USB2-capable ESD diodes, after all, and ESD problems are closer than you might expect.

For instance, I’ve recently built a pocket device consisting of a battery-powered Pi Zero and a USB soundcard connected to wired headphones, with a pretty standard kind of long cable. I wear a lot of synthetic clothes, in particular, hoodies and jackets, and I kept having the Pi reboot every time I took my jacket off or put it on, through static electricity induced into the headphone wires through the cable insulation, going into the USB port on the Pi Zero.

So, I went and put ESD diodes on the USB 2 pins, using the footprint I previously added to my board “just in case” but didn’t populate, and this failure mode has instantly disappeared for good. Remember, footprints are free, and bodges cost time. Want a recommendation? The four-channel diodes are pretty good for USB 2; look for the SRV-05 footprint in KiCad, in the SOT-23-6 package. It’s a generic enough footprint that there’s no shortage of ESD diode packs in the same footprint, they’re low-capacity enough that you can even use it for purposes like captouch pad protection, and they will also work for applications like Ethernet or externally available GPIOs.

Do you need ESD diodes? Yes, just add the footprint. Same goes for over-current control switches, by the way – I’ve already talked about the SY6820, but it bears repeating. Your entire system doesn’t have to reboot when you short-circuit a USB port on the board, and a cheap current-limited switch IC will let you ensure that’s the case, while also letting you switch the port power on and off, as a nice bonus.

This was just a few tips on and around USB 2 hubs and connectors, but I hope it helps you out with your projects.