The sky is falling. Or more specifically, it was about to fall, according to the security community this week. The MITRE Corporation came within a hair’s breadth of running out of its contract to maintain the CVE database. And admittedly, it would be a bad thing if we suddenly lost updates to the central CVE database. What’s particularly interesting is how we knew about this possibility at all. An April 15 letter sent to the CVE board warned that the specific contract that funds MITRE’s CVE and CWE work was due to expire on the 16th. This was not an official release, and it’s not clear exactly how this document was leaked.

Many people made political hay out of the apparent imminent carnage. And while there’s always an element of political maneuvering when it comes to contract renewal, it’s worth noting that it’s not unheard of for MITRE’s CVE funding to go down to the wire like this. We don’t know how many times we’ve been in this position in years past. Regardless, MITRE has spun out another non-profit, The CVE Foundation, specifically to see to the continuation of the CVE database. And at the last possible moment, CISA has announced that it has invoked an option in the existing contract, funding MITRE’s CVE work for another 11 months.

Android Automatic Reboots

Mobile devices are in their most secure state right after boot, before the user password is entered to unlock the device for the first time. Tools like Cellebrite will often work once a device has been unlocked once, but just can’t exploit a device in the first booted state. This is why Google is rolling out a feature, where Android devices that haven’t been unlocked for three days will automatically reboot.

Once a phone is unlocked, the encryption keys are stored in memory, and it only takes a lock screen bypass to have full access to the device. But before the initial unlock, the device is still encrypted, and the keys are safely stored in the hardware security module. It’s interesting that this new feature isn’t delivered as an Android OS update, but as part of the Google Play Services — the closed source libraries that run on official Android phones.

4chan

4chan has been hacked. It turns out, running ancient PHP code and out-of-date libraries on a controversial site is not a great idea. A likely exploit chain has been described, though this should be considered very unofficial at this point: Some 4chan boards allow PDF uploads, but the server didn’t properly vet those files. A PostScript file can be uploaded instead of a PDF, and an old version of Ghostscript processes it. The malicious PostScript file triggers arbitrary code execution in Ghostscript, and a SUID binary is used to elevate privileges to root.

PHP source code of the site has been leaked, and the site is still down as of the time of writing. It’s unclear how long restoration will take. Part of the fallout from this attack is the capture and release of internal discussions, pictures of the administrative tools, and even email addresses from the site’s administration.

Recall is Back

Microsoft is back at it, working to release Recall in a future Windows 11 update. You may remember our coverage of this, castigating the security failings, and pointing out that Recall managed to come across as creepy. Microsoft wisely pulled the project before rolling it out as a full release.

If you’re not familiar with the Recall concept, it’s the automated screenshotting of your Windows machine every few seconds. The screenshots are then locally indexed with an LLM, allowing for future queries to be run against the data. And once the early reviewers got over the creepy factor, it turns out that’s genuinely useful sometimes.

On top of the security hardening Microsoft has already done, this iteration of Recall is an opt-in service, with an easy pause button to temporarily disable the snapshot captures. This is definitely an improvement. Critics are still sounding the alarm, but for a much narrower problem: Recall’s snapshots will automatically extract information from security focused applications. Think about Signal’s disappearing messages feature. If you send such a message to a desktop user, that has Recall enabled, the message is likely stored in that user’s Recall database.

It seems that Microsoft has done a reasonably good job of cleaning up the Recall feature, particularly by disabling it by default. It seems like the privacy issues could be furthered addressed by giving applications and even web pages a way to opt out of Recall captures, so private messages and data aren’t accidentally captured. As Recall rolls out, do keep in mind the potential extra risks.

16,000 Symlinks

It’s been recently discovered that over 16,000 Fortinet devices are compromised with a trivial backdoor, in the form of a symlink making the root filesystem available inside the web-accessible language folder. This technique is limited to devices that have the SSL VPN enabled. That system exposes a web interface, with multiple translation options. Those translation files live in a world-accessible folder on the web interface, and it makes for the perfect place to hide a backdoor like this one. It’s not a new attack, and Fortinet believes the exploited devices have harbored this backdoor since the 2023-2024 hacking spree.

Vibes

We’re a little skeptical on the whole vibe coding thing. Our own [Tyler August] covered one of the reasons why. LLMs are likely to hallucinate package names, and vibe coders may not check closely, leading to easy typosquatting (LLMsquatting?) attacks. Figure out the likely hallucinated names, register those packages, and profit.

But what about Vibe Detections? OK, we know, letting an LLM look at system logs for potentially malicious behavior isn’t a new idea. But [Claudio Contin] demonstrates just how easy it can be, with the new EDV tool. Formally not for production use, this new gadget makes it easy to take Windows system events, and feed them into Copilot, looking for potentially malicious activity. And while it’s not perfect, it did manage to detect about 40% of the malicious tests that Windows Defender missed. It seems like LLMs are going to stick around, and this might be one of the places they actually make sense.

Bits and Bytes

Apple has pushed updates to their entire line, fixing a pair of 0-day vulnerabilities. The first is a wild vulnerability in CoreAudio, in that playing audio from a malicious audio file can lead to arbitrary code execution. The chaser is the flaw in the Pointer Authentication scheme, that Apple uses to prevent memory-related vulnerabilities. Apple has acknowledged that these flaws were used in the wild, but no further details have been released.

The Gnome desktop has an interesting problem, where the yelp help browser can be tricked into reading the contents of arbitrary filesystem files. Combined with the possibility of browser links automatically opening in yelp, this makes for a much more severe problem than one might initially think.

And for those of us following along with Google Project Zero’s deep dive into the Windows Registry, part six of that series is now available. This installment dives into actual memory structures, as well as letting us in on the history of why the Windows registry is called the hive and uses the 0xBEE0BEE0 signature. It’s bee themed, because one developer hated bees, and another developer thought it would be hilarious.

When is a crystal not a crystal? When it’s a quasi-crystal, a paradoxical form of metal recently found in some 3D printed metal alloys by [A.D. Iams et al] at the American National Institute for Standards and Technology (NIST).

As you might remember from chemistry class, crystals are made up of blocks of atoms (usually called ‘unit cells’) that fit together in perfect repetition — baring dislocations, cracks, impurities, or anything else that might throw off a theoretically perfect crystal structure. There are only so many ways to tessellate atoms in 3D space; 230 of them, to be precise. A quasicrystal isn’t any of them. Rather than repeat endlessly in 3D space, a quasicrystal never repeats perfectly, like a 3D dimensional Penrose tile. The discovery of quasicrystals dates back to the 1980s, and was awarded a noble prize in 2011.

Quasicrystals aren’t exactly common in nature, so how does 3D printing come into this? Well, it turns out that, quite accidentally, a particular Aluminum-Zirconium alloy was forming small zones of quasicrystals (the black spots in the image above) when used in powder bed fusion printing. Other high strength-alloys tended to be very prone to cracking, to the point of unusability, and this Al-Zr alloy, discovered in 2017, was the first of its class.

You might imagine that the non-regular structure of a quasicrystal wouldn’t propagate cracks as easily as a regular crystal structure, and you would be right! The NIST researchers obviously wanted to investigate why the printable alloy had the properties it does. When their crystallographic analysis showed not only five-fold, but also three-fold and two-fold rotational symmetry when examined from different angles, the researchers realized they had a quasicrystal on their hands. The unit cell is in the form of a 20-sided icosahedron, providing the penrose-style tiling that keeps the alloy from cracking.

You might say the original team that developed the alloy rolled a nat-20 on their crafting skill. Now that we understand why it works, this research opens up the doors for other metallic quasi-crystals to be developed on purpose, in aluminum and perhaps other alloys.

We’ve written about 3D metal printers before, and highlighted a DIY-able plastic SLS kit, but the high-power powder-bed systems needed for aluminum aren’t often found in makerspaces. If you’re building one or know someone who is, be sure to let us know.

This fun PCB from [Nick Brown] features a miniature railroad implemented with 0805-sized LEDs. With an eye towards designing his own fun interactive PCB badge, the Light-Rail began its journey. He thoroughly documented his process, from shunting various late-night ideas together to tracking down discrepancies between the documentation of a part and the received part.

Inspired by our very own Supercon 2022 badge, he wanted to make a fun badge with a heavy focus on the aesthetics of the final design. He also wanted to challenge himself some in this project, so even though there are over 100 LEDs, they are not laid out in a symmetrical or matrix pattern. Instead, it’s an organic, winding railroad with crossings and stations throughout the board. Designed in KiCad the board contains 144 LEDS, 3 seven-segment displays, and over a dozen buttons that all come together in use for the built in game.

The challenges didn’t stop at just the organic layout of all those LEDs. He decided to use Rust for this project, which entailed writing his own driver for the seven-segment displays as well as creating a tone library for the onboard buzzer. As with all projects, unexpected challenges popped up along the way. One issue with how the oscillator was hooked up meant he wasn’t able to use the ATmega32U4, which was the brains of the entire railroad. After some experimenting, he came up with a clever hack: using a pogo pin jig to connect the clock where it needed to go while programming the board.

Be sure to check out all the details of this journey in his build log. If you love interactive badges also check out some of the other creative boards we’ve featured.

[Charmed Labs] are responsible for bringing numerous open-source hardware products to fruition over the years, and their latest device is an adorably small robotic camera platform called Goby, currently crowdfunding for its initial release. Goby has a few really clever design features and delivers a capable (and hackable) platform for under 100 USD.

Goby embraces its small size, delivering what its creators dub “tinypresence” — or the feeling of being there, but on a very small scale. Cardboard courses, LEGO arenas, or even tabletop gaming scenery hits different when experienced from a first-person perspective. Goby is entirely reprogrammable with nothing more than a USB cable and the Arduino IDE, while costing less than most Arduino starter kits.

One of the physical features we really like is the tail-like articulated caster at the rear. Flexing this pivots Goby up or down (and can even flip Goby completely over), allowing one to pan and tilt the view without needing to mount the camera on a gimbal. It also comes into play for recharging; Goby simply moves over the disc-shaped charger and pivots down to make contact.

At Goby‘s heart is an ESP32-S3 and OmniVision OV2640 camera sensor streaming a live video feed (and driving controls) with WebRTC. Fitting the WebRTC stack onto an ESP32 wasn’t easy, but opens up possibilities beyond just media streaming.

Goby is set up to make launching an encrypted connection as easy as sharing a URL or scanning a QR code. The link is negotiated between bot and client with the initial help of an external server, and once a peer-to-peer connection is established, the server’s job is done and it is out of the picture. [Charmed Labs]’s code for this functionality — named BitBang — is in beta and destined for an open release as well. While BitBang is being used here to make it effortless to access Goby remotely, it’s more broadly intended to make web access for any ESP32-based device easier to implement.

As far as tiny remote camera platforms go, it might not be as small as rebuilding a Hot Wheels car into a micro RC platform, but it’s definitely more accessible and probably cheaper, to boot. Check it out at the Kickstarter (see the first link in this post) and watch it in action in the video, embedded just below the page break.

Running a dairy farm used to be a rather hands-on experience, with the farmer required to be around every few hours to milk the cows, feed them, do all the veterinarian tasks that the farmer can do themselves, and so on. The introduction of milking machines in the early 20th century however began a trend of increased automation whereby a single farmer could handle a hundred cows by the end of the century instead of only a couple. In a recent article in IEEE Spectrum covers the continued progress here is covered, including cows milking themselves, on-demand style as shown in the top image.

The article focuses primarily on Dutch company Lely’s recent robots, which range from said self-milking robots to a manure cleaning robot that looks like an oversized Roomba. With how labor-intensive (and low-margin) a dairy farm is, any level of automation that can improve matters will be welcomed, with so far Lely’s robots receiving a mostly positive response. Since cows are pretty smart, they will happily guide themselves to a self-milking robot when they feel that their udders are full enough, which can save the farmer a few hours of work each day, as this robot handles every task, including the cleaning of the udders prior to milking and sanitizing itself prior to inviting the next cow into its loving embrace.

As for the other tasks, speaking as a genuine Dutch dairy farm girl who was born & raised around cattle (and sheep), the idea of e.g. mucking out stables being taken over by robots is something that raises a lot more skepticism. After all, a farmer’s children have to earn their pocket money somehow, which includes mucking, herding, farm maintenance and so on. Unless those robots get really cheap and low maintenance, the idea of fully automated dairy farms may still be a long while off, but reducing the workload and making cows happier are definitely lofty goals.

Top image: The milking robot that can automatically milk a cow without human assistance. (Credit: Lely)

No doubt many readers have at times wished to try their hand at blacksmithing, but it’s fair to say that acquiring an anvil represents quite the hurdle. For anyone not knowing where to turn there’s a video from [Black Bear Forge], in which he takes us through a range of budget options.

He starts with a sledgehammer, the simplest anvil of all, which we would agree makes a very accessible means to do simple forge work. He shows us a rail anvil and a couple of broken old anvils, before spending some time on a cheap Vevor anvil and going on to some much nicer more professional ones. It’s probably the Vevor which is the most interesting of the ones on show though, not because it is particularly good but because it’s a chance to see up close one of these very cheap anvils.

Are they worth taking the chance? The one he’s got has plenty of rough parts and casting flaws, an oddly-sited pritchel and a hardy hole that’s too small. These anvils are sometimes referred to as “Anvil shaped objects”, and while this one could make a reasonable starter it’s not difficult to see why it might not be the best purchase. It’s a subject we have touched on before in our blacksmithing series, so we’re particularly interested to see his take on it.

How it started: a simple repair job on a Roland drum machine. How it ended: a scratch-built FM drum synth module that’s completely analog, and completely cool.

[Moritz Klein]’s journey down the analog drum machine rabbit hole started with a Roland TR-909, a hybrid drum machine from the mid-80s that combined sampled sounds with analog synthesis. The unit [Moritz] picked up was having trouble with the decay on the kick drum, so he spread out the gloriously detailed schematic and got to work. He breadboarded a few sections of the kick drum circuit to aid troubleshooting, but one thing led to another and he was soon in new territory.

The video below is on the longish side, with the first third or so dedicated to recreating the circuits used to create the 909’s iconic sound, slightly modifying some of them to simplify construction. Like the schematic that started the whole thing, this section of the video is jam-packed with goodness, too much to detail here. But a few of the gems that caught our eye were the voltage-controlled amplifier (VCA) circuit that seems to make appearances in multiple places in the circuit, and the dead-simple wave-shaper circuit, which takes some of the harmonics out of the triangle wave oscillator’s output with just a couple of diodes and some resistors.

Once the 909’s kick and toms section had been breadboarded, [Moritz] turned his attention to adding something Roland hadn’t included: frequency modulation. He did this by adding a second, lower-frequency voltage-controlled oscillator (VCO) and using that to modulate the drum section. That resulted in a weird, metallic sound that can be tuned to imitate anything from a steel drum to a bell. He also added a hi-hat and cymbal section by mixing the square wave outputs on the VCOs through a funky XOR gate made from discrete components and a high-pass filter.

There’s a lot of information packed into this video, and by breaking everything down into small, simple blocks, [Moritz] makes it easy to understand analog synths and the circuits behind them.

If you had to guess, what do you think it would take to build an ocean-going buoy that could not only survive on its own without human intervention for more than two years, but return useful data the whole time? You’d probably assume such a feat would require beefy hardware, riding inside an expensive and relatively large watertight vessel of some type — and for good reason, the ocean is an unforgiving environment, and has sent far more robust hardware to the briny depths.

But as Wayne Pavalko found back in 2016, a little planning can go a long way. That’s when he launched the first of what he now calls Maker Buoys: a series of solar-powered drifting buoys that combine a collection of off-the-shelf sensor boards with an Arduino microcontroller and an Iridium Short-Burst Data (SBD) modem in a relatively simple watertight box.

He guessed that first buoy might last a few weeks to a month, but when he finally lost contact with it after 771 days, he realized there was real potential for reducing the cost and complexity of ocean research.

Wayne recalled the origin of his project and updated the audience on where it’s gone from there during his 2024 Supercon talk, Adventures in Ocean Tech: The Maker Buoy Journey. Even if you’re not interested in charting ocean currents with homebrew hardware, his story is an inspirational reminder that sometimes a fresh approach can help solve problems that might at first glance seem insurmountable.

DIY All the Way

As Dan Maloney commented when he wrote-up that first buoy’s journey in 2017, the Bill of Materials for a Maker Buoy is tailored for the hobbyist. Despite being capable of journeys lasting for several thousand kilometers in the open ocean, there’s no marine-grade unobtainium parts onboard. Indeed, nearly all of the electronic components can be sourced from Adafruit, with the most expensive line item being the RockBLOCK 9603 Iridium satellite modem at $299.

Even the watertight container that holds all the electronics is relatively pedestrian. It’s the sort of plastic latching box you might put your phone or camera in on a boat trip to make sure it stays dry and floats if it falls overboard. Wayne points out that the box being clear is a huge advantage, as you can mount the solar panel internally. Later versions of the Maker Buoy even included a camera that could peer downward through the bottom of the box.

Wayne says that first buoy was arguably over-built, with each internal component housed in its own waterproof compartment. Current versions instead hold all of the hardware in place with a 3D printed internal frame. The bi-level framework puts the solar panel, GPS, and satellite modem up at the top so they’ve got a clear view of the sky, and mounts the primary PCB, battery, and desiccant container down on the bottom.

The only external addition necessary is to attach a 16 inch (40 centimeter) long piece of PVC pipe to the bottom of the box, which acts as a passive stabilizer. Holes drilled in the pipe allow it to fill with water once submerged, lowering the buoy’s center of gravity and making it harder to flip over. At the same time, should the buoy find itself inverted due to wave action, the pipe will make it top-heavy and flip it back over.

It’s simple, cheap, and incredibly effective. Wayne mentions that data returned from onboard Inertial Measurement Units (IMUs) have shown that Maker Buoys do occasionally find themselves going end-over-end during storms, but they always right themselves.

Like Space…But Wetter

Early on in his presentation, Wayne makes an interesting comparison when talking about the difficulties in developing the Maker Buoy. He likens it to operating a spacecraft in that your hardware is never coming back, nobody will be able to service it, and the only connection you’ll have to the craft during its lifetime is a relatively low-bandwidth link.

But one could argue that the nature of Iridium communications makes the mission of the Maker Buoy even more challenging than your average spacecraft. As the network is really only designed for short messages — at one point Wayne mentions that even sending low-resolution images of only a few KB in size was something of an engineering challenge — remotely updating the software on the buoy isn’t an option. So even though the nearly fifty year old Voyager 1 can still receive the occasional software patch from billions of miles away, once you drop a Maker Buoy into the ocean, there’s no way to fix any bugs in the code.

Because of this, Wayne decided to take the extra step of adding a hardware watchdog timer that can monitor the buoy’s systems and reboot the hardware if necessary. It’s a bit like unplugging your router when the Internet goes out…if your Internet was coming from a satellite low-Earth orbit and your living room happened to be in the middle of the ocean.

From One to Many

After publishing information about his first successful Maker Buoy online, Wayne says it wasn’t long before folks started contacting him about potential applications for the hardware. In 2018, a Dutch non-profit expressed interest in buying 50 buoys from him to study the movement of floating plastic waste in the Pacific. The hardware was more than up to the task, but there was just one problem: up to this point, Wayne had only built a grand total of four buoys.

Opportunities like this, plus the desire to offer the Maker Buoy in kit and ready to deploy variants for commercial and educational purposes, meant Wayne had to streamline his production. When it’s just a personal project, it doesn’t really matter how long it takes to assemble or if everything goes together correctly the first time. But that approach just won’t work if you need to deliver functional units in quantities that you can’t count on your fingers.

As Wayne puts it, making something and making something that’s easily producible are really two very different things. The production becomes a project in its own right. He explains that investing the time and effort to make repetitive tasks more efficient and reliable, such as developing jigs to hold pieces together while you’re working on them, more than pays off for itself in the end. Even though he’s still building them himself in his basement, he uses an assembly line approach that allows for the consistent results expected by paying customers.

A Tale Well Told

While the technical details of how Wayne designed and built the different versions of the Maker Buoy are certainly interesting, it’s hearing the story of the project from inception to the present day that really makes watching this talk worthwhile. What started as a simple “What If” experiment has spiraled into a side-business that has helped deploy buoys all over the planet.

Admittedly, not every project has that same potential for growth. But hearing Wayne tell the Maker Buoy story is the sort of thing that makes you want to go dust off that project that’s been kicking around in the back of your head and finally give it a shot. You might be surprised by the kind of adventure taking a chance on a wild idea can lead to.

We’re suckers here for projects that let you see the unseeable, and [Ayden Wardell Aerospace] provides that on a budget with their $30 Schlieren Imaging Setup. The unseeable in question is differences in air density– or, more precisely, differences in the refractive index of the fluid the imaging set up makes use of, in this case air. Think of how you can see waves of “heat” on a warm day– that’s lower-density hot air refracting light as it rises. Schlieren photography weaponizes this, allowing to analyze fluid flows– for example, the mach cones in a DIY rocket nozzle, which is what got [Ayden Wardell Aerospace] interested in the technique.

This is a ‘classic’ mirror-and-lamp Schlieren set up.  You put the system you wish to film near the focal plane of a spherical mirror, and camera and light source out at twice the focal distance. Rays deflected by changes in refractive index miss the camera– usually one places a razor blade precisely to block them, but [Ayden] found that when using a smart phone that was unnecessary, which shocked this author.

While it is possible that [Ayden Wardell Aerospace] has technically constructed a shadowgraph, they claim that carefully positioning the smartphone allows the sharp edge of the case to replace the razor blade. A shadowgraph, which shows the second derivative of density, is a perfectly valid technique for flow visualization, and is superior to Schlieren photography in some circumstances– when looking at shock waves, for example.

Regardless, the great thing about this project is that [Ayden Wardell Aerospace] provides us with STLs for the mirror and smartphone mounting, as well as providing a BOM and a clear instructional video. Rather than arguing in the comments if this is “truly” Schlieren imaging, grab a mirror, extrude some filament, and test it for yourself!

There are many ways to do Schlieren images. We’ve highighted background-oriented techniques, and seen how to do it with a moiré pattern, or even a selfie stick. Still, this is the first time 3D printing has gotten involved and the build video below is quick and worth watching for those sweet, sweet Schlieren images.

This project by [Miro] is awesome, not only did he build a replica Enigma machine using modern technologies, but after completing it, he went back and revised several components to make it more usable. We’ve featured Enigma machines here before; they are complex combinations of mechanical and electrical components that form one of the most recognizable encryption methods in history.

His first Enigma machine was designed closely after the original. He used custom PCBs for the plugboard and lightboard, which significantly cleaned up the internal wiring. For the lightboard, he cleverly used a laser printer on semi-transparent paper to create crisp letters, illuminated from behind. For the keyboard, he again designed a custom PCB to connect all the switches. However, he encountered an unexpected setback due to error stack-up. We love that he took the time to document this issue and explain that the project didn’t come together perfectly on the first try and how some adjustments were needed along the way.

The real heart of this build is the thought and effort put into the design of the encryption rotors. These are the components that rotate with each keystroke, changing the signal path as the system is used. In a clever hack, he used a combination of PCBs, pogo pins, and 3D printed parts to replicate the function of the original wheels.

Enigma machine connoisseurs will notice that the wheels rotate differently than in the original design, which leads us to the second half of this project. After using the machine for a while, it became clear that the pogo pins were wearing down the PCB surfaces on the wheels. To solve this, he undertook an extensive redesign that resulted in a much more robust and reliable machine.

In the redesign, instead of using pogo pins to make contact with pads, he explored several alternative methods to detect the wheel position—including IR light with phototransistors, rotary encoders, magnetic encoders, Hall-effect sensors, and more. The final solution reduced the wiring and addressed long-term reliability concerns by eliminating the mechanical wear present in the original design.

Not only did he document the build on his site, but he also created a video that not only shows what he built but also gives a great explanation of the logic and function of the machine. Be sure to also check out some of the other cool enigma machines we’ve featured over the years.

If your shop comes complete with a MIG welder, an acetylene torch, and an air hammer, then you have more options than most when it comes to removing broken bolts.

In this short video [Jim’s Automotive Machine Shop, Inc] takes us through the process of removing a broken manifold bolt: use a MIG welder to attach a washer, then attach a suitably sized nut and weld that onto the washer, heat the assembly with the acetylene torch, loosen up any corrosion on the threads by tapping with a hammer, then simply unscrew with your wrench! Everything is easy when you know how!

Of course if your shop doesn’t come complete with a MIG welder and acetylene torch you will have to get by with the old Easy Out screw extractor like the rest of us. And if you are faced with a nasty bolt situation keep in mind that lubrication can help.

How would you go about determining absolute zero? Intuitively, it seems like you’d need some complicated physics setup with lasers and maybe some liquid helium. But as it turns out, all you need is some simple lab glassware and a heat gun. And a laser, of course.

To be clear, the method that [Markus Bindhammer] describes in the video below is only an estimation of absolute zero via Charles’s Law, which describes how gases expand when heated. To gather the needed data, [Marb] used a 50-ml glass syringe mounted horizontally on a stand and fitted with a thermocouple. Across from the plunger of the syringe he placed a VL6180 laser time-of-flight sensor, to measure the displacement of the plunger as the air within it expands.

Data from the TOF sensor and the thermocouple were recorded by a microcontroller as the air inside the syringe was gently heated. Plotting the volume of the gas versus the temperature results shows a nicely linear relationship, and the linear regression can be used to calculate the temperature at which the volume of the gas would be zero. The result: -268.82°C, or only about four degrees off from the accepted value of -273.15°. Not too shabby.

[Marb] has been on a tear lately with science projects like these; check out his open-source blood glucose measurement method or his all-in-one electrochemistry lab.

These days even a lowly microcontroller can easily trade blows with – or surpass – desktop systems of yesteryear, so it is little wonder that DIY handheld gaming systems based around an MCU are more capable than ever. A case in point is the GK handheld gaming system by [John Cronin], which uses an MCU from relatively new and very capable STM32H7S7 series, specifically the 225-pin STM32H7S7L8 in TFBGA package with a single Cortex-M7 clocked at 600 MHz and a 2D NeoChrom GPU.

Coupled with this MCU are 128 MB of XSPI (hexa-SPI) SDRAM, a 640×480 color touch screen, gyrometer, WiFi network support and the custom gkOS in the firmware for loading games off an internal SD card. A USB-C port is provided to both access said SD card’s contents and for recharging the internal Li-ion battery.

As can be seen in the demonstration video, it runs a wide variety of games, ranging from DOOM (of course), Quake, as well as Command and Conquer: Red Alert and emulators for many consoles, with the Mednafen project used to emulate Game Boy, Super Nintendo and other systems at 20+ FPS. Although there aren’t a lot of details on how optimized the current firmware is, it seems to be pretty capable already.

This short video from [ProShorts 101] shows us how to build a variable speed disc sander from not much more than an old hard drive.

We feel that as far as hacks go this one ticks all the boxes. It is clever, useful, and minimal yet comprehensive; it even has a speed control! Certainly this hack uses something in a way other than it was intended to be used.

Take this ingenuity and add an old hard drive from your junkbox, sandpaper, some glue, some wire, a battery pack, a motor driver, a power socket and a potentiometer, drill a few holes, glue a few pieces, and voilà! A disc sander! Of course the coat of paint was simply icing on the cake.

The little brother of this hack was done by the same hacker on a smaller hard drive and without the speed control, so check that out too.

One thing that took our interest while watching these videos is what tool the hacker used to cut sandpaper. Here we witnessed the use of both wire cutters and a craft knife. Perhaps when you’re cutting sandpaper you just have to accept that the process will wear out the sharp edge on your tool, regardless of which tool you use. If you have a hot tip for the best tool for the job when it comes to cutting sandpaper please let us know in the comments! (Also, did anyone catch what type of glue was used?)

If you’re interested in a sander but need something with a smaller form factor check out how to make a sander from a toothbrush!

Whenever the topic is raised in popular media about porting a codebase written in an ‘antiquated’ programming language like Fortran or COBOL, very few people tend to object to this notion. After all, what could be better than ditching decades of crusty old code in a language that only your grandparents can remember as being relevant? Surely a clean and fresh rewrite in a modern language like Java, Rust, Python, Zig, or NodeJS will fix all ailments and make future maintenance a snap?

For anyone who has ever had to actually port large codebases or dealt with ‘legacy’ systems, their reflexive response to such announcements most likely ranges from a shaking of one’s head to mad cackling as traumatic memories come flooding back. The old idiom of “if it ain’t broke, don’t fix it”, purportedly coined in 1977 by Bert Lance, is a feeling that has been shared by countless individuals over millennia. Even worse, how can you ‘fix’ something if you do not even fully understand the problem?

In the case of languages like COBOL this is doubly true, as it is a domain specific language (DSL). This is a very different category from general purpose system programming languages like the aforementioned ‘replacements’. The suggestion of porting the DSL codebase is thus to effectively reimplement all of COBOL’s functionality, which should seem like a very poorly thought out idea to any rational mind.

Sticking To A Domain

The term ‘domain specific language’ is pretty much what it says it is, and there are many of such DSLs around, ranging from PostScript and SQL to the shader language GLSL. Although it is definitely possible to push DSLs into doing things which they were never designed for, the primary point of a DSL is to explicitly limit its functionality to that one specific domain. GLSL, for example, is based on C and could be considered to be a very restricted version of that language, which raises the question of why one should not just write shaders in C?

Similarly, Fortran (Formula translating system) was designed as a DSL targeting scientific and high-performance computation. First used in 1957, it still ranks in the top 10 of the TIOBE index, and just about any code that has to do with high-performance computation (HPC) in science and engineering will be written in Fortran or strongly relies on libraries written in Fortran. The reason for this is simple: from the beginning Fortran was designed to make such computations as easy as possible, with subsequent updates to the language standard adding updates where needed.

Fortran’s latest standard update was published in November 2023, joining the COBOL 2023 standard as two DSLs which are both still very much alive and very current today.

The strength of a DSL is often underestimated, as the whole point of a DSL is that you can teach this simpler, focused language to someone who can then become fluent in it, without requiring them to become fluent in a generic programming language and all the libraries and other luggage that entails. For those of us who already speak C, C++, or Java, it may seem appealing to write everything in that language, but not to those who have no interest in learning a whole generic language.

There are effectively two major reasons why a DSL is the better choice for said domain:

• Easy to learn and teach, because it’s a much smaller language
• Far fewer edge cases and simpler tooling

In the case of COBOL and Fortran this means only a fraction of the keywords (‘verbs’ for COBOL) to learn, and a language that’s streamlined for a specific task, whether it’s to allow a physicist to do some fluid-dynamic modelling, or a staff member at a bank or the social security offices to write a data processing application that churns through database data in order to create a nicely formatted report. Surely one could force both of these people to learn C++, Java, Rust or NodeJS, but this may backfire in many ways, the resulting code quality being one of them.

Tangentially, this is also one of the amazing things in the hardware design language (HDL) domain, where rather than using (System)Verilog or VHDL, there’s an amazing growth of alternative HDLs, many of them implemented in generic scripting and programming languages. That this prohibits any kind of skill and code sharing, and repeatedly, and often poorly, reinvents the wheel seems to be of little concern to many.

Non-Broken Code

A very nice aspect of these existing COBOL codebases is that they generally have been around for decades, during which time they have been carefully pruned, trimmed and debugged, requiring only minimal maintenance and updates while they happily keep purring along on mainframes as they process banking and government data.

One argument that has been made in favor of porting from COBOL to a generic programming language is ‘ease of maintenance’, pointing out that COBOL is supposedly very hard to read and write and thus maintaining it would be far too cumbersome.

Since it’s easy to philosophize about such matters from a position of ignorance and/or conviction, I recently decided to take up some COBOL programming from the position of both a COBOL newbie as well as an experienced C++ (and other language) developer. Cue the ‘Hello Business’ playground project.

For the tooling I used the GnuCOBOL transpiler, which converts the COBOL code to C before compiling it to a binary, but in a few weeks the GCC 15.1 release will bring a brand new COBOL frontend (gcobol) that I’m dying to try out. As language reference I used a combination of the Wikipedia entry for COBOL, the IBM ILE COBOL language reference (PDF) and the IBM COBOL Report Writer Programmer’s Manual (PDF).

My goal for this ‘Hello Business’ project was to create something that did actual practical work. I took the FileHandling.cob example from the COBOL tutorial by Armin Afazeli as starting point, which I modified and extended to read in records from a file, employees.dat, before using the standard Report Writer feature to create a report file in which the employees with their salaries are listed, with page numbering and totaling the total salary value in a report footing entry.

My impression was that although it takes a moment to learn the various divisions that the variables, files, I/O, and procedures are put into, it’s all extremely orderly and predictable. The compiler also will helpfully tell you if you did anything out of order or forgot something. While data level numbering to indicate data associations is somewhat quaint, after a while I didn’t mind at all, especially since this provides a whole range of meta information that other languages do not have.

The lack of semi-colons everywhere is nice, with only a single period indicating the end of a scope, even if it concerns an entire loop (perform). I used the modern free style form of COBOL, which removes the need to use specific columns for parts of the code, which no doubt made things a lot easier. In total it only took me a few hours to create a semi-useful COBOL application.

Would I opt to write a more extensive business application in C++ if I got put on a tight deadline? I don’t think so. If I had to do COBOL-like things in C++, I would be hunting for various libraries, get stuck up to my gills in complex configurations and be scrambling to find replacements for things like Report Writer, or be forced to write my own. Meanwhile in COBOL everything is there already, because it’s what that DSL is designed for. Replacing C++ with Java or the like wouldn’t help either, as you end up doing so much boilerplate work and dependencies wrangling.

A Modern DSL

Perhaps the funniest thing about COBOL is that since version 2002 it got a whole range of features that push it closer to generic languages like Java. Features that include object-oriented programming, bit and boolean types, heap-based memory allocation, method overloading and asynchronous messaging. Meanwhile the simple English, case-insensitive, syntax – with allowance for various spellings and acronyms – means that you can rapidly type code without adding symbol soup, and reading it is obvious even as a beginner, as the code literally does what it says it does.

True, the syntax and naming feels a bit quaint at first, but that is easily explained by the fact that when COBOL appeared on the scene, ALGOL was still highly relevant and the C programming language wasn’t even a glimmer in Dennis Ritchie’s eyes yet. If anything, COBOL has proven itself – much like Fortran and others – to be a time-tested DSL that is truly a testament to Grace Hopper and everyone else involved in its creation.

With vector network analyzers, the commercial offerings seem to come in two flavors: relatively inexpensive but limited capabilities, and full-featured but scary expensive. There doesn’t seem to be much middle ground, especially if you want something that performs well in the microwave bands.

Unless, of course, you build your own vector network analyzer (VNA). That’s what [Henrik Forsten] did, and we’ve got to say we’re even more impressed by the results than we were with his earlier effort. That version was not without its problems, and fixing them was very much on the list of goals for this build. Keeping the build affordable was also key, which resulted in some design compromises while still meeting [Henrik]’s measurement requirements.

The Bill of Materials includes dual-channel broadband RF mixer chips, high-speed 12-bit ADCs, and a fast FPGA to handle the torrent of data and run the digital signal processing functions. The custom six-layer PCB is on the large side and includes large cutouts for the directional couplers, which use short lengths of stripped coaxial cable lined with ferrite rings. To properly isolate signals between stages, [Henrik] sandwiched the PCB between a two-piece aluminum enclosure. Wisely, he printed a prototype enclosure and lined it with aluminum foil to test for fit and function before committing to milling the final version. He did note some leakage around the SMA connectors, but a few RF gaskets made from scraps of foil and solder braid did the trick.

This is a pretty slick build, especially considering he managed to keep the price tag at a very reasonable $300. It’s more expensive than the popular NanoVNA or its clones, but it seems like quite a bargain considering its capabilities.

We’ve all had times where we knew we had some part but we had to go searching for it all over as it wasn’t where we thought we put it. Organizing the numerous components, parts, and supplies that go into your projects can be a daunting task, especially if you use the same type of part at different times for different projects. It helps to have a framework to keep track of all the small details. Binner is an open source project that aims to allow you to easily maintain a database that can be customized to your use.

In a recent video for DigiKey, [Byte Sized Engineer] used Binner to track the locations of his components and parts in his freshly organized workshop. Binner already has the ability to read the labels used by well-known electronics suppliers via a barcode scanner, and uses that information to populate your inventory. It even grabs quantities and links in a datasheet for your newly added part. The barcode scanner can also be used to retrieve the contents of a location, so with a single scan Binner can bring up everything residing at that location.

Binner can be run locally so there isn’t the concern of putting in all the effort to build up your database just to have an internet outage make it inaccessible. Another cool feature is that it allows you to print labels, you can customize the fields to display the values you care about.

The project already has future plans to tie into a “smart bin” system to light up the location of your component — a clever feature we’ve seen implemented in previous setups.

The General Instruments AY-3-8910 was a quite popular Programmable Sound Generator (PSG) that saw itself used in a wide variety of systems, including Apple II soundcards such as the Mockingboard and various arcade systems. In addition to the Yamaha variants (e.g. YM2149), two cut-down were created by GI: these being the AY-3-8912 and the AY-3-8913, which should have been differentiated only by the number of GPIO banks broken out in the IC package (one or zero, respectively). However, research by [fenarinarsa] and others have shown that the AY-3-8913 variant has some actual hardware issues as a PSG.

With only 24 pins, the AY-3-8913 is significantly easier to integrate than the 40-pin AY-3-8910, at the cost of the (rarely used) GPIO functionality, but as it turns out with a few gotchas in terms of timing and register access. Although the Mockingboard originally used the AY-3-8910, latter revisions would use two AY-3-8913 instead, including the MS revision that was the Mac version of the Mindscape Music Board for IBM PCs.

The first hint that something was off with the AY-3-8913 came when [fenarinarsa] was experimenting with effect composition on an Apple II and noticed very poor sound quality, as demonstrated in an example comparison video (also embedded below). The issue was very pronounced in bass envelopes, with an oscilloscope capture showing a very distorted output compared to a YM2149. As for why this was not noticed decades ago can likely be explained by that the current chiptune scene is pushing the hardware in very different ways than back then.

As for potential solutions, the [French Touch] project has created an adapter to allow an AY-3-8910 (or YM2149) to be used in place of an AY-3-8913.

Top image: Revision D PCB of Mockingboard with GI AY-3-8913 PSGs.

If we asked you to name Alexander Graham Bell’s greatest invention, you would doubtless say “the telephone”; it’s probably the only one of his many, many inventions most people could bring to mind. If you asked Bell himself, though, he would tell you his greatest invention was the photophone, and if the prolific [Nick Bild] doesn’t agree he’s at least intrigued enough to produce a replica of this 1880-vintage wireless telephone. Yes, 1880. As in, only four years after the telephone was patented.

It obviously did not catch on, and is not the sort of thing that comes to mind when we think “wireless telephone”. In contrast to the RF of the 20th century version, as you might guess from the name the photophone used light– sunlight, to be specific. In the original design, the transmitter was totally passive– a tube with a mirror on one end, mounted to vibrate when someone spoke into the open end of the tube. That was it, aside from the necessary optics to focus sunlight onto said mirror. [Nick Bild] skips this and uses a laser as a handily coherent light source, which was obviously not an option in 1880. As [Nick] points out, if it was, Bell certainly would have made use of it.

The receiver is only slightly more complex, in that it does have electronic components– a selenium cell in the original, and in [Nick’s] case a modern photoresistor in series with a 10,000 ohm resistor. There’s also an optical difference, with [Nick] opting for a lens to focus the laser light on his photoresistor instead of the parabolic mirror of the original. In both cases vibration of the mirror at the transmitter disrupts line-of-sight with the receiver, creating an AM signal that is easily converted back into sound with an electromagnetic speaker.

The photophone never caught on, for obvious reasons — traditional copper-wire telephones worked beyond line of sight and on cloudy days–but we’re greatful to [Nick] for dredging up the history and for letting us know about it via the tip line. See his video about this project below.

The name [Nick Bild] might look familiar to regular readers. We’ve highlighted a few of his projects on Hackaday before.