Did OneWire of DS18B20 sensor fame ever fascinate you in its single-data-line simplicity? If so, then you’ll like PJON (Padded Jittering Operative Network) – a single-wire-compatible protocol for up to 255 devices. One disadvantage is that you need to check up on the bus pretty often, trading hardware complexity for software complexity. Now, this is no longer something for the gate wielders of us to worry about – [Giovanni] tells us that there’s a hardware implementation of PJDL (Padded Jittering Data Link), a PJON-based bus.

This implementation is written in Verilog, and allows you to offload a lot of your low-level PJDL tasks, essentially, giving you a PJDL peripheral for all your inter-processor communication needs. Oh, and as [Giovanni] says, this module has recently been taped out as part of the CROC chip project, an educational SoC project. What’s not to love?

PJON is a fun protocol, soon to be a decade old. We’ve previously covered [Giovanni] use PJON to establish a data link through a pair of LEDs, and it’s nice to see this nifty small-footprint protocol gain that much more of a foothold, now, in our hardware-level projects.

We thank [Giovanni Blu Mitolo] for sharing this with us!

Admit it or not, you probably have a teddy bear somewhere in your past that you were — or maybe are — fond of. Not to disparage your bear, but we think Bradfield might have had a bigger adventure than yours has. Bradfield was launched in November on a high-altitude balloon by Year 7 and 8 students at Walhampton School in the UK in connection with Southampton University. Dressed in a school uniform, he was supposed to ride to near space, but ran into some turbulence. The BBC reported that poor Bradfield couldn’t hold on any longer and fell from around 17 miles up.  The poor bear looked fairly calm for being so high up.

A camera recorded the unfortunate stuffed animal’s plight. Apparently, a companion plushie, Bill the Badger (the Badger being the Southampton mascot), successfully completed the journey, returning to Earth with a parachute.

There have been some news reports that Bradfield may have been recovered, but we haven’t seen anything definitive yet. Of course, there are plenty of things you can launch on a balloon, but what a great idea to let kids send a mascot aloft with your serious science payloads and radio gear. Because we know you are launching a balloon for a serious purpose, right? Sure, we won’t tell you just want the cool pictures.

No offense to Bradfield, but sending humans aloft on balloons requires a little more care. We aren’t as well-equipped to drop 17 miles. The Hackaday Supercon has even been the site of an uncrewed (and unbeared) balloon launch. Meanwhile, if you are around Reading and spot Bradfield, be sure to give him a cookie and call the Walhampton school.

Have you ever found yourself looking at the insects of the Paleozoic era, including the dragonfly Meganeuropsis permiana with its 71 cm wingspan and wondered what it would be like to have one as a pet? If so, you’re in luck because the mad lads over at [The Thought Emporium] have done a lot of the legwork already to grow your own raven-sized moths and more. As it turns out, all it takes is hijacking the chemical signals that control the development phases, to grow positively humongous mealworms and friends.

The growth process of the juveniles, such as mealworms – the larval form of the yellow mealworm beetle – goes through a number of molting stages (instars), with the insect juvenile hormone levels staying high until it is time for the final molt and transformation into a pupa from which the adult form emerges. The pyriproxyfen insecticide is a juvenile hormone analog that prevents this event. Although at high doses larvae perish, the video demonstrates that lower doses work to merely inhibit the final molt.

That proof-of-concept is nice of course if you really want to grow larger grubs, but doesn’t ultimately really affect the final form as they simply go through the same number of instars. Changing this requires another hormone/insecticide, called ecdysone, which regulates the number of instars before the final molt and pupal stage.

Amusingly, this hormone is expressed by plants to mess with larvae as they predate on their tissues, with spinach expressing a very significant amount of this phyto-ecdysone. For humans this incidentally interacts with the estrogen receptor beta, which helps with building muscle. Ergo bodybuilding supplies provide a ready to use source of this hormone as ‘beta ecdysterone’ to make swol insects with.

Unfortunately, this hormone turned out to be very tricky to apply, as adding it to their feed like with pyriproxyfen merely resulted in the test subjects losing weight or outright dying. For the next step it would seem that a more controlled exposure method is needed, which may or may not involve some DNA editing. Clearly creating Mothra is a lot harder than just blasting a hapless insect with some random ionizing radiation or toxic chemicals.

A common myth with insect size is that the only reason why they got so big during the Paleozoic was due to the high O₂ content in the atmosphere. This is in fact completely untrue. There is nothing in insect physiology that prevents them from growing much larger, as they even have primitive lungs, as well as a respiratory and circulatory system to support this additional growth. Consequently, even today we got some pretty large insects for this reason, including some humongous flies, like the 7 cm long and 10 cm wingspan Gauromydas heros.

The real reasons appears to be the curse of exoskeletons, which require constant stressful molting and periods of complete vulnerability. In comparison, us endoskeleton-equipped animals have bones that grow along with the muscles and other tissues around them, which ultimately seems to be just the better strategy if you want to grow big. Evolutionary speaking this makes it more attractive for insects and other critters with exoskeletons to stay small and fly under the proverbial radar.

The positive upshot of this is of course that this means that we can totally have dog-sized moths as pets, which surely is what the goal of the upcoming video will be.

Apple’s AirPods can pair with their competitors’ devices and work as basic Bluetooth earbuds, but to no one’s surprise most of their really interesting features are reserved for Apple devices. What is surprising, though, is that simple Bluetooth device ID spoofing unlocks these features, a fact which [Kavish Devar] took advantage of to write LibrePods, an AirPods controller app for Android and Linux.

In particular, LibrePods lets you control noise reduction modes, use ear detection to pause and unpause audio, detect head gestures, reduce volume when the AirPods detect you’re speaking, work as configurable hearing aids, connect to two devices simultaneously, and configure a few other settings. The app needs an audiogram to let them work as hearing aids, and you’ll need an existing audiogram – creating an audiogram requires too much precision. Of particular interest to hackers, the app has a debug mode to send raw Bluetooth packets to the AirPods. Unfortunately, a bug in the Android Bluetooth stack means that LibrePods requires root on most devices.

This isn’t the first time we’ve seen a hack enable hearing aid functionality without official Apple approval. However, while we have some people alter the hardware, AirPorts can’t really be called hacker- or repair-friendly.

Thanks to [spiralbrain] for the tip!

Typically, if you happened across a walnut lying about, you might consider eating it or throwing it to a friendly squirrel. However, as [Penguin DIY] demonstrates, it’s perfectly possible to turn the humble nut into a clandestine surveillance device. It turns out the walnut worriers were right all along.

The build starts by splitting and hollowing out the walnut. From there, small holes are machined into the mating faces of the walnut, into which [Penguin DIY] glues small neodymium magnets. These allow the walnut to be opened and snapped shut as desired, while remaining indistinguishable from a regular walnut at a distance.

The walnut shell is loaded with nine tiny lithium-polymer cells, for a total of 270 mAh of battery capacity at 3.7 volts. Charging the cells is achieved via a deadbugged TP4056 charge module to save space, with power supplied via a USB C port. Holes are machined in the walnut shell for the USB C port as well as the camera lens, though one imagines the former could have been hidden purely inside for a stealthier look. The camera itself appears to be an all-in-one module with a transmitter built in, with the antenna installed in the top half of the walnut shell and connected via pogo pins. The video signal can be picked up at a distance via a receiver hooked up to a smart phone. No word on longevity, but the included batteries would probably provide an hour or two of transmission over short ranges if you’re lucky.

If you have a walnut tree in your backyard, please do not email us about your conspiracy theories that they are watching you. We get those more than you might think, and they are always upsetting to read. If, however, you’re interested in surveillance devices, we’ve featured projects built for detecting them before with varying levels of success. Video after the break.

We all know that you can play DOOM on nearly anything, but what about the lesser known work being done to let other species get in on the action? For ages now, our rodent friends haven’t been able to play the 1993 masterpiece, but [Viktor Tóth] and colleagues have been working hard to fix this unfortunate oversight.

If you’ve got the feeling this isn’t the first time you’ve read about rats attempting to slay demons, it’s probably because [Victor] has been working on this mission for years now — with a previous attempt succeeding in allowing rats to navigate the DOOM landscape. Getting the rodents to actually play through the game properly has proved slightly more difficult, however.

Improving on the previous attempt, V2 has the capability to allow rats to traverse through levels, be immersed in the virtual world with a panoramic screen, and take out enemies. Rewards are given to successful behaviors in the form of sugar water through a solenoid powered dispenser.

While this current system looks promising, the rats haven’t gotten too far though the game due to time constraints. But they’ve managed to travel through the levels and shoot, which is still pretty impressive for rodents.

DOOM has been an indicator of just how far we can take technology for decades. While this particular project has taken the meme into a slightly different direction, there are always surprises. You can even play DOOM in KiCad when you’re tired of using it to design PCBs.

The choice of a good keyboard is something which consumes a lot of time for many Hackaday readers, judging by the number of custom input device projects which make it to these pages. I live by my keyboard as a writer, but I have to admit that I’ve never joined in on the special keyboard front; for me it’s been a peripheral rather than an obsession. But I’m hard on keyboards, I type enough that I wear them out. For the last five years my Hackaday articles have come via a USB Thinkpad keyboard complete with the little red stick pointing device, but its keys have started parting company with their switches so it’s time for a replacement.

I Don’t Want The Blackpool Illuminations

For a non keyboard savant peering over the edge, this can be a confusing choice. There’s much obsessing about different types of mechanical switch, and for some reason I can’t quite fathom, an unreasonable number of LEDs.

I don’t want my keyboard to look like the Blackpool Illuminations (translation for Americans: Las Vegas strip), I just want to type on the damn thing. More to the point, many of these “special” keyboards carry prices out of proportion to their utility, and it’s hard to escape the feeling that like the thousand quid stereo the spotty kid puts in his Opel Corsa, you’re being asked to pay just for bragging rights.

Narrowing down my needs then, I don’t need any gimmicks, I just need a small footprint keyboard that’s mechanically robust enough to survive years of my bashing out Hackaday articles on it. I’m prepared to pay good money for that.

The ‘board I settled upon is probably one of the most unglamorous decent quality keyboards on the market. The Cherry G84-4100 is sold to people in industry who need a keyboard that fits in a small space, and I’ve used one to the deafening roar of a cooling system in a data centre rack. It’s promising territory for a Hackaday scribe. I ordered mine from the Cherry website, and it cost me just under £70 (about $93), with the postage being extra. It’s available with a range of different keymaps, and I ordered the UK one. In due course the package arrived, a slim cardboard box devoid of consumer branding, inside of which was the keyboard, a USB-to-PS/2 adaptor, and a folded paper manual. I’m using it on a USB machine so the adaptor went in my hoard, but I’m pleased to be able to use this with older machines when necessary.

Hello My Old Data Centre Friend

For my money, I got a keyboard described as “compact”, or 75%. It’s 282 by 132 by 26 mm in size, which means it takes up a little less space than the Thinkpad one it replaces, something of a win to my mind. It doesn’t have a numeric keypad, but I don’t need that. The switches are Cherry mechanical ones rather than the knock-offs you’ll find on so many competitors, and they have something of the mechanical sound but not the racket of an IBM buckled spring key switch. Cherry claim they’re good for 20 million activations, so even I shouldn’t wear them out.

The keymap is of course the standard UK one I’m used to, but what makes or breaks a ‘board like this one is how they arrange the other keys. I really like that their control key is in the bottom left hand corner rather than as in so many others, the function key, but I am taking a little while to get used to the insert and delete keys being to the left of the arrow keys in the bottom right hand corner. Otherwise my muscle memory isn’t being taxed too much by it.

There are a couple of little feet at the back underneath that can be flipped up to raise the ‘board at an angle. Since after years of typing the heel of my hand becomes inflamed if I rest it on the surface I elevate my wrist by about an inch with a rest, thus I use the keyboard tilt. I’ve been typing with the Cherry for a few weeks now, and it remains comfortable.

The Cherry G84-4100 then. It’s not a “special” keyboard in any way, in fact its about as utilitarian as it gets in a peripheral. But for me a keyboard is a tool, and just like my Vernier caliper or my screwdrivers I demand that it does its job repeatably and flawlessly for many years to come. So its unglamorous nature is its strength, because I’ve paid for the engineering which underlies it rather than the bells and whistles that adorn some others. Without realising it you’ll be seeing a lot of this peripheral in my work over the coming years.

Hackaday Editors Elliot Williams and Al Williams met up to cover the best of Hackaday this week, and they want you to listen in. There were a hodgepodge of hacks this week, ranging from home automation with RF, volumetric displays in glass, and some crazy clocks, too.

Ever see a typewriter that uses an ink pen? Elliot and Al hadn’t either. Want time on a supercomputer? It isn’t free, but it is pretty cheap these days. Finally, the guys discussed how to focus on a project like Dan Maloney, who finally got a 3D printer, and talked about Maya Posch’s take on LLM intelligence.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download the human-generated podcast in mostly mono, but sometimes stereo, MP3.

Episode 349 Show Notes:

News:

• Failed 3D Printed Part Brings Down Small Plane

What’s that Sound?

• What is that sound? Al didn’t guess, but if you can, you could win a coveted Hackaday Podcast T-Shirt.

Interesting Hacks of the Week:

• Bridging RTL-433 To Home Assistant
  • GitHub – merbanan/rtl_433: Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
• The Key To Plotting
• Reverse Sundial Still Tells Time
• Trace Line Clock Does It With Magnets
• Volumetric Display With Lasers And Bubbly Glass
  • Wiremap, A Volumetric Display
• The Engineering That Makes A Road Cat’s Eye Self-Cleaning

Quick Hacks:

• Elliot’s Picks:
  • Production KiCad Template Covers All Your Bases
  • RP2350 Done Framework Style
    • https://github.com/semitov/SemiTOV-MCL
  • Neat Techniques To Make Interactive Light Sculptures
• Al’s Picks:
  • Super Simple Deadbuggable Bluetooth Chip
  • LED Hourglass Is A Great Learning Project
  • Your Supercomputer Arrives In The Cloud

Can’t Miss Articles:

• Ask Hackaday: Solutions, Or Distractions?
• Why LLMs Are Less Intelligent Than Crows
  • What Is ChatGPT Doing … and Why Does It Work?

The Landel Mailbug was a weird little thing. It combined a keyboard and a simple text display, and was intended to be a low-distraction method for checking your email. [CiferTech] decided to repurpose it, though, turning it into an AI console instead.

The first job was to crack the device open and figure out how to interface with the keyboard. The design was conventional, so reading the rows and columns of the key matrix was a cinch. [CiferTech] used PCF8574 IO expanders to make it easy to read the matrix with an ESP32 microcontroller over I2C. The ESP32 is paired with a small audio output module to allow it to run a text-to-speech system, and a character display to replace the original from the Mailbug itself. It uses its WiFi connection to query the ChatGPT API. Thus, when the user enters a query, the ESP32 runs it by ChatGPT, and then displays the output on the screen while also speaking it aloud.

[CiferTech] notes the build was inspired by AI terminals in retro movies, though we’re not sure what specifically it might be referencing. In any case, it does look retro and it does let you speak to a computer being, of a sort, so the job has been done. Overall, though, the build shows that you can build something clean and functional just by reusing and interfacing a well-built commercial product.

Microsoft has published a patch-set for the Linux kernel, proposing the Hornet Linux Security Module (LSM). If you haven’t been keeping up with the kernel contributor scoreboard, Microsoft is #11 at time of writing and that might surprise you. The reality is that Microsoft’s biggest source of revenue is their cloud offering, and Azure is over half Linux, so Microsoft really is incentivized to make Linux better.

The Hornet LSM is all about more secure eBPF programs, which requires another aside: What is eBPF? First implemented in the Berkeley Packet Filter, it’s a virtual machine in the kernel, that allows executing programs in kernel space. It was quickly realized that this ability to run a script in kernel space was useful for far more than just filtering packets, and the extended Berkeley Packet Filter was born. eBPF is now used for load balancing, system auditing, security and intrusion detection, and lots more.

This unique ability to load scripts from user space into kernel space has made eBPF useful for malware and spyware applications, too. There is already a signature scheme to restrict eBPF programs, but Hornet allows for stricter checks and auditing. The patch is considered a Request For Comments (RFC), and points out that this existing protection may be subject to Time Of Check / Time Of Use (TOCTOU) attacks. It remains to be seen whether Hornet passes muster and lands in the upstream kernel.

Patch Tuesday

Linux obviously isn’t the only ongoing concern for Microsoft, and it’s the time of month to talk about patch Tuesday. There are 57 fixes that are considered vulnerabilities, and additional changes that are just classified internally as bug fixes. There were three of those vulnerabilities that were publicly known before the fix, and one of those was known to be actively used in attacks in the wild.

CVE-2025-62221 was an escalation of privilege flaw in the Windows Cloud Files Mini Filter Driver. In Windows, a minifilter is a kernel driver that attach to the file system software, to monitor or modify file operations. This flaw was a use-after-free that allowed a lesser-privileged attacker to gain SYSTEM privileges.

Gogs

Researchers at Wiz found an active exploitation campaign that uses CVE-2025-8110, a previously unknown vulnerability in Gogs. The GO Git Service, hence the name, is a self-hosted GitHub/GitLab alternative written in Go. It’s reasonably popular, with 1,400 of them exposed to the Internet.

The vulnerability was a bypass of CVE-2024-55947, a path traversal vulnerability that allowed a malicious user to upload files to arbitrary locations. That was fixed with Gogs 0.13.1, but the fix failed to account for symbolic links (symlinks). Namely, as far as the git protocol is concerned, symlinks are completely legal. The path traversal checking doesn’t check for symlinks during normal git access, so a symlink pointing outside the repository can easily be created. And then the HTTPS file API can be used to upload a file to that symlink, again allowing for arbitrary writes.

The active exploitation on this vulnerability is particularly widespread. Of the 1400 Gogs instances on the Internet, over 700 show signs of compromise, in the form of new repositories with randomized names. It’s possible that even more instances have been compromised, and the signs have been covered. The attack added a symlink to .git/config, and then overwriting that file with a new config that defines the sshCommand setting. After exploitation, a Supershell malware was installed, establishing ongoing remote control.

The most troubling element of this story is that the vulnerability was first discovered in the wild back in July and was reported to the Gogs project at that time. As of December 11, the vulnerability has not been fixed or acknowledged. After five months of exploitation without a patch, it seems time to acknowledge that Gogs is effectively unmaintained. There are a couple of active forks that don’t seem to be vulnerable to this attack; time to migrate.

Blinkenlights

There’s an old story I always considered apocryphal, that data could be extracted from the blinking lights of network equipment, leading to a few ISPs to boast that they covered all their LEDs with tape for security. While there may have been a bit of truth to that idea, it definitely served as inspiration for [Damien Cauquil] at Quarkslab, reverse engineering a very cheap smart watch.

The watches were €11.99  last Christmas, and a price point that cheap tickles the curiosity of nearly any hacker. What’s on the inside? What does the firmware look like? The micro-controller was by the JieLi brand, and it’s a bit obscure, with no good way to pull the firmware back off. With no leads there, [Damien] turned to the Android app and the Bluetooth Low Energy connection. One of the functions of the app is uploading custom watch dials. Which of course had to be tested by creating a custom watch face featuring a certain Rick Astley.

But those custom watch faces have a quirk. The format internally uses byte offsets, and the watch doesn’t check for that offset to be out of bounds. A ridiculous scheme was concocted to abuse this memory leak to push firmware bytes out as pixel data. It took a Raspberry Pi Pico sniffing the SPI bus to actually recover those bytes, but it worked! Quite the epic hack.

Bits and Bytes

Libpng has an out of bounds read vulnerability, that was just fixed in 1.6.52. What’s weird about this one is that the vulnerability is can be triggered by completely legitimate PNG images. The good news is that is vulnerability only effects the simplified API, so not every user of libpng is in the blast radius.

And finally, Google has pushed out an out-of-band update to Chrome, fixing a vulnerability that is being exploited in the wild. The Hacker News managed to connect the bug ID to a pull request in the LibANGLE library, a translation layer between OpenGL US calls into Direct3D, Vulkan, and Metal. The details there suggests the flaw is limited to the macOS platform, as the fix is in the metal renderer. Regardless, time to update!

When the orbit of NASA’s Mars Atmosphere and Volatile EvolutioN (MAVEN) spacecraft took it behind the Red Planet on December 6th, ground controllers expected a temporary loss of signal (LoS). Unfortunately, the Deep Space Network hasn’t heard from the science orbiter since. Engineers are currently trying to troubleshoot this issue, but without a sign of life from the stricken spacecraft, there are precious few options.

As noted by [Stephen Clark] over at ArsTechnica this is a pretty big deal. Even though MAVEN was launched in November of 2013, it’s a spring chicken compared to the other Mars orbiters. The two other US orbiters: Mars Reconnaissance Orbiter (MRO) and Mars Odyssey, are significantly older by around a decade. Of the two ESA orbiters, Mars Express and ExoMars, the latter is fairly new (2016) and could at least be a partial backup for MAVEN’s communication relay functionality with the ground-based units, in particular the two active rovers. ExoMars has a less ideal orbit for large data transfers, which would hamper scientific research.

With neither the Chinese nor UAE orbiters capable of serving as a relay, this puts the burden on a potential replacement orbiter, such as the suggested Mars Telecommunications Orbiter, which was cancelled in 2005. Even if contact with MAVEN is restored, it would only have fuel for a few more years. This makes a replacement essential if we wish to keep doing ground-based science missions on Mars, as well as any potential manned missions.

What if you find yourself as an iPhone owner, desiring a local backup solution — no wireless tech involved, no sending off data to someone else’s server, just an automatic device-to-device file sync? Check out [Giovanni]’s ios-backup-machine project, a small Linux-powered device with an e-ink screen that backs up your iPhone whenever you plug the two together with a USB cable.

The system relies on libimobiledevice, and is written to make simple no-interaction automatic backups work seamlessly. The backup status is displayed on the e-ink screen, and at boot, it shows up owner’s information of your choice, say, a phone number — helpful if the device is ever lost. For preventing data loss, [Giovanni] recommends a small uninterruptible power supply, and the GitHub-described system is married to a PiSugar board, though you could go without or add a different one, for sure. Backups are encrypted through iPhone internal mechanisms, so while it appears you might not be able to dig into one, they are perfectly usable for restoring your device should it get corrupted or should you need to provision a new phone to replace the one you just lost.

Easy to set up, fully open, and straightforward to use — what’s not to like? Just put a few off-the-shelf boards together, print the case, and run the setup instructions, you’ll have a pocket backup machine ready to go. Now, if you’re considering this as a way to decrease your iTunes dependency, you might as well check out this nifty tool that helps you get out the metadata for the music you’ve bought on iTunes.

There are a million and one MIDI controllers and synths on the market, but sometimes it’s just more satisfying to make your own. [Turi Scandurra] very much went his own way when he put together his Diapasonix instrument.

Right away, the build is somewhat reminiscent of a stringed instrument, what with its buttons laid out in four “strings” of six “frets” each. Only, they’re not so much buttons, as individual sections of a capacitive touch controller. A Raspberry Pi Pico 2 is responsible for reading the 24 pads, with the aid of two MPR121 capacitive touch ICs.

The Diapasonix can be played as an instrument in its own right, using the AMY synthesis engine. This provides a huge range of patches from the Juno 6 and DX7 synthesizers of old. Onboard effects like delay and reverb can be used to alter the sound. Alternatively, it can be used as a MIDI controller, feeding its data to a PC attached over USB. It can be played in multiple modes, with either direct note triggers or with a “strumming” method instead.

We’ve featured a great many MIDI controllers over the years, from the artistic to the compact. Video after the break.

If you get a chance to visit a computer history museum and see some of the very old computers, you’ll think they took up a full room. But if you ask, you’ll often find that the power supply was in another room and the cooling system was in yet another. So when you get a computer that fit on, say, a large desk and maybe have a few tape drives all together in a normal-sized office, people thought of it as “small.” We’re seeing a similar evolution in particle accelerators, which, a new startup company says, can be room-sized according to a post by [Charles Q. Choi] over at IEEE Spectrum.

Usually, when you think of a particle accelerator, you think of a giant housing like the 3.2-kilometer-long SLAC accelerator. That’s because these machines use magnets to accelerate the particles, and just like a car needs a certain distance to get to a particular speed, you have to have room for the particle to accelerate to the desired velocity.

A relatively new technique, though, doesn’t use magnets. Instead, very powerful (but very short) laser pulses create plasma from gas. The plasma oscillates in the wake of the laser, accelerating electrons to relativistic speeds. These so-called wakefield accelerators can, in theory, produce very high-energy electrons and don’t need much space to do it.

The startup company, TAU Systems, is about to roll out a commercial system that can generate 60 to 100 MeV at 100 Hz. They also intend to increase the output over time. For reference, SLAC generates 50,000 MeV. But, then again, it takes two miles of raceway to do it.

The initial market is likely to be radiation testing for space electronics. Higher energies will open the door to next-generation X-ray lithography for IC production, and more. There are likely applications for accelerated electrons that we don’t see today because it isn’t feasible to generate them without a massive facility.

On the other hand, don’t get your checkbook out yet. The units will cost about $10 million at the bottom end. Still a bargain compared to the alternatives.

You can do some of this now on a chip. Particle accelerators have come a long way.

Photo from Tau Systems.

Cycloidal drives have an entrancing motion, as well as a few other advantages – high torque and efficiency, low backlash, and compactness among them. However, much as [Sergei Mishin] likes them, it can be difficult to 3D-print high-torque drives, and it’s sometimes inconvenient to have the input and output shafts in-line. When, therefore, he came across a video of an industrial three-ring reducing drive, which works on a similar principle, he naturally designed his own 3D-printable drive.

The main issue with 3D-printing a normal cycloidal drive is with the eccentrically-mounted cycloidal plate, since the pins which run through its holes need bearings to keep them from quickly wearing out the plastic plate at high torque. This puts some unfortunate constraints on the size of the drive. A three-ring drive also uses an eccentric drive shaft to cause cycloidal plates to oscillate around a set of pins, but the input and output shafts are offset so that the plates encompass both the pins and the eccentric driveshaft. This simplifies construction significantly, and also makes it possible to add more than one input or output shaft.

As the name indicates, these drives use three plates 120 degrees out of phase with each other; [Sergei] tried a design with only two plates 180 degrees out of phase, but since there was a point at which the plates could rotate just as easily in either direction, it jammed easily. Unlike standard cycloidal gears, these plates use epicycloidal rather than hypocycloidal profiles, since they move around the outside of the pins. [Sergei] helpfully wrote a Python script that can generate profiles, animate them, and export to DXF. The final performance of these drives will depend on their design parameters and printing material, but [Sergei] tested a 20:1 drive and reached a respectable 9.8 Newton-meters before it started skipping.

Even without this design’s advantages, it’s still possible to 3D-print a cycloidal drive, its cousin the harmonic drive, or even more exotic drive configurations.

As technology marches on, gear that once required expensive lab equipment is now showing up in devices you can buy for less than a nice dinner. A case in point: those tiny displays originally sold as Nintendo amiibo emulators. Thanks to [ATC1441], one of these pocket-sized gadgets has been transformed into 2.4 GHz spectrum analyzer.

These emulators are built around the Nordic nRF52832 SoC, the same chip found in tons of low-power Bluetooth devices, and most versions come with either a small LCD or OLED screen plus a coin cell or rechargeable LiPo. Because they all share the same core silicon, [ATC1441]’s hack works across a wide range of models. Don’t expect lab-grade performance; the analyzer only covers the range the Bluetooth chip inside supports. But that’s exactly where Wi-Fi, Bluetooth, Zigbee, and a dozen other protocols fight for bandwidth, so it’s perfect for spotting crowded channels and picking the least congested one.

Flashing the custom firmware is dead simple: put the device into DFU mode, drag over the .zip file, and you’re done. All the files, instructions, and source are up on [ATC1441]’s PixlAnlyzer GitHub repo. Check out some of the other amiibo hacks we’ve featured as well.

Not only are pianos beautiful musical instruments that have stood the test of many centuries of time, they’re also incredible machines. Unfortunately, all machines wear out over time, which means it’s often not feasible to restore every old piano we might come across. But a few are worth the trouble, and [Emma] had just such a unique machine roll into her shop recently.

What makes this instrument so unique is that it’s among the first electric pianos to be created, and one of only three known of this particular model that survive to the present day. This is a Vivi-Tone Clavier piano which dates to the early 1930s. In an earlier video she discusses more details of its inner workings, but essentially it uses electromagnetic pickups like a guitar to detect vibrations in plucked metal reeds.

To begin the restoration, [Emma] removes the action and then lifts out all of the keys from the key bed. This instrument is almost a century old so it was quite dirty and needed to be cleaned. The key pins are lubricated, then the keys are adjusted so that they all return after being pressed. From there the keys are all adjusted so that they are square and even with each other. With the keys mostly in order, her attention turns to the action where all of the plucking mechanisms can be filed, and other adjustments made. The last step was perhaps the most tedious, which is “tuning” the piano by adjusting the pluckers so that all of the keys produce a similar amount or volume of sound, and then adding some solder to the reeds that were slightly out of tune.

With all of those steps completed, the piano is back in working order, although [Emma] notes that since these machines were so rare and produced so long ago there’s no real way to know if the restoration sounds like what it would have when it was new. This is actually a similar problem we’ve seen before on this build that hoped to model the sound of another electric instrument from this era called the Luminaphone.

Thanks to [Eluke] for the tip!

Back in the mid 1990s, the release of Microsoft’s Windows 95 operating system cemented the Redmond software company’s dominance over most of the desktop operating system space. Apple were still in their period in the doldrums waiting for Steve Jobs to return with his NeXT, while other would-be challengers such as IBM’s OS/2 or Commodore’s Amiga were sinking into obscurity.

Into this unpromising marketplace came Be inc, with their BeBox computer and its very nice BeOS operating system. To try it out as we did at a trade show some time in the late ’90s was to step into a very polished multitasking multimedia OS, but sadly one which failed to gather sufficient traction to survive. The story ended in the early 2000s as Be were swallowed by Palm, and a dedicated band of BeOS enthusiasts set about implementing a free successor OS. This has become Haiku, and while it’s not BeOS it retains API compatibility with and certainly feels a lot like its inspiration. It’s been on my list for a Daily Drivers article for a while now, so it’s time to download the ISO and give it a go. I’m using the AMD64 version.

A Joy To Use, After A Few Snags

This isn’t the first time I’ve given Haiku a go in an attempt to write about it for this series, and I have found it consistently isn’t happy with my array of crusty old test laptops. So this time I pulled out something newer, my spare Lenovo Thinkpad X280. I was pleased to see that the Haiku installation USB volume booted and ran fine on this machine, and I was soon at the end of the install and ready to start my Haiku journey.

Here I hit my first snag, because sadly the OS hadn’t quite managed to set up its UEFI booting correctly. I thus found myself unexpectedly in a GRUB prompt, as the open source bootloader was left in place from a previous Linux install. Fixing this wasn’t too onerous as I was able to copy the relevant Haiku file to my UEFI partition, but it was a little unexpected. On with the show then, and in to Haiku.

In use, this operating system is a joy. Its desktop look and feel is polished, in a late-90s sense. There was nothing jarring or unintuitive, and though I had never used Haiku before I was never left searching for what I needed. It feels stable too, I was expecting the occasional crash or freeze, but none came. When I had to use the terminal to move the UEFI file it felt familiar to me as a Linux user, and all my settings were easy to get right.

Never Mind My Network Card

I hit a problem when it came to network setup though, I found its wireless networking to be intermittent. I could connect to my network, but while DHCP would give it an IP address it failed to pick up the gateway and thus wasn’t a useful external connection. I could fix this by going to a fixed IP address and entering the gateway and DNS myself, and that gave me a connection, but not a reliable one. I would have it for a minute or two, and then it would be gone. Enough time for a quick software update and to load Hackaday on its WebPositive web browser, but not enough time to do any work. We’re tantalisingly close to a useful OS here, and I don’t want this review to end on that note.

The point of this series has been to try each OS in as real a situation as possible, to do my everyday Hackaday work of writing articles and manipulating graphics. I have used real hardware to achieve this, a motley array of older PCs and laptops. As I’ve described in previous paragraphs I’ve reached the limits of what I can do on real hardware due to the network issue, but I still want to give this one a fair evaluation. I have thus here for the first time used a test subject in a VM rather than on real hardware. What follows then is courtesy of Gnome Boxes on my everyday Linux powerhouse, so please excuse the obvious VM screenshots.

This One Is A True Daily Driver

With a Haiku install having a working network connection, it becomes an easy task to install software updates, and install new software. The library has fairly up-to-date versions of many popular packages, so I was easily able to install GIMP and LibreOffice. WebPositive is WebKit-based and up-to-date enough that the normally-picky Hackaday back-end doesn’t complain at me, so it more than fulfils my Daily Drivers  requirement for an everyday OS I can do my work on. In fact, the ’90s look-and-feel and the Wi-Fi issues notwithstanding, this OS feels stable and solid in a way that many of the other minority OSes I’ve tried do not. I could use this day-to-day, and the Haiku Thinkpad could accompany me on the road.

There is a snag though, and it’s not the fault of the Haiku folks but probably a function of the size of their community; this is a really great OS, but sadly there are software packages it simply doesn’t have available for it. They’ve concentrated on multimedia, the web, games, and productivity in their choice of software to port, and some of the more esoteric or engineering-specific stuff I use is unsurprisingly not there. I can not fault them for this given the obvious work that’s gone into this OS, but it’s something to consider if your needs are complex.

Haiku then, it’s a very nice desktop operating system that’s polished, stable, and a joy to use. Excuse it a few setup issues and take care to ensure your Wi-Fi card is on its nice list, and you can use it day-to-day. It will always have something of the late ’90s about it, but think of that as not a curse but the operating system some of us wished we could have back in the real late ’90s. I’ll be finding a machine to hang onto a Haiku install, this one bears further experimentation.

Looking for an educational microcontroller board to get you or a loved one into electronics? Consider the tinyCore – a small and nifty octagon-shaped ESP32 board by [MR. INDUSTRIES], simplified for learning yet featureful enough to offer plenty of growth, and fully open.

The tinyCore board’s octagonal shape makes it more flexible for building wearables than the vaguely rectangular boards we’re used to, and it’s got a good few onboard gadgets. Apart from already expected WiFi, BLE, and GPIOs, you get battery management, a 6DoF IMU (LSM6DSOX) in the center of the board, a micro SD card slot for all your data needs, and two QWIIC connectors. As such, you could easily turn it into, say, a smartwatch, a motion-sensitive tracker, or a controller for a small robot – there’s even a few sample projects for you to try.

You can buy one, or assemble a few yourself thanks to the open-source-ness – and, to us, the biggest factor is the [MR.INDUSTRIES] community, with documentation, examples, and people learning with this board and sharing what they make. Want a device with a big display that similarly wields a library of examples and a community? Perhaps check out the Cheap Yellow Display hacks!

We thank [Keith Olson] for sharing this with us!

After you have written the code for some awesome application, you of course want other people to be able to use it. Although simply directing them to the source code on GitHub or similar is an option, not every project lends itself to the traditional configure && make && make install, with often dependencies being the sticking point.

Asking the user to install dependencies and set up any filesystem links is an option, but having an installer of some type tackle all this is of course significantly easier. Typically this would contain the precompiled binaries, along with any other required files which the installer can then copy to their final location before tackling any remaining tasks, like updating configuration files, tweaking a registry, setting up filesystem links and so on.

As simple as this sounds, it comes with a lot of gotchas, with Linux distributions in particular being a tough nut. Whereas on MacOS, Windows, Haiku and many other OSes you can provide a single installer file for the respective platform, for Linux things get interesting.

Windows As Easy Mode

For all the flak directed at Windows, it is hard to deny that it is a stupidly easy platform to target with a binary installer, with equally flexible options available on the side of the end-user. Although Microsoft has nailed down some options over the years, such as enforcing the user’s home folder for application data, it’s still among the easiest to install an application on.

While working on the NymphCast project, I found myself looking at a pleasant installer to wrap the binaries into, initially opting to use the NSIS (Nullsoft Scriptable Install System) installer as I had seen it around a lot. While this works decently enough, you do notice that it’s a bit crusty and especially the more advanced features can be rather cumbersome.

This is where a friend who was helping out with the project suggested using the more modern Inno Setup instead, which is rather like the well-known InstallShield utility, except OSS and thus significantly more accessible. Thus the pipeline on Windows became the following:

1. Install dependencies using vcpkg.
2. Compile project using NMake and the MSVC toolchain.
3. Run the Inno Setup script to build the .exe based installer.

Installing applications on Windows is helped massively both by having a lot of freedom where to install the application, including on a partition or disk of choice, and by having the start menu structure be just a series of folders with shortcuts in them.

The Qt-based NymphCast Player application’s .iss file covers essentially such a basic installation process, while the one for NymphCast Server also adds the option to download a pack of wallpaper images, and asks for the type of server configuration to use.

Uninstalling such an application basically reverses the process, with the uninstaller installed alongside the application and registered in the Windows registry together with the application’s details.

MacOS As Proprietary Mode

Things get a bit weird with MacOS, with many application installers coming inside a DMG image or PKG file. The former is just a disk image that can be used for distributing applications, and the user is generally provided with a way to drag the application into the Applications folder. The PKG file is more of a typical installer as on Windows.

Of course, the problem with anything MacOS is that Apple really doesn’t want you to do anything with MacOS if you’re not running MacOS already. This can be worked around, but just getting to the point of compiling for MacOS without running XCode on MacOS on real Apple hardware is a bit of a fool’s errand. Not to mention Apple’s insistence on signing these packages, if you don’t want the end-user to have to jump through hoops.

Although I have built both iOS and OS X/MacOS applications in the past – mostly for commercial projects – I decided to not bother with compiling or testing my projects like NymphCast for Apple platforms without easy access to an Apple system. Of course, something like Homebrew can be a viable alternative to the One True Apple Way if you merely want to get OSS o MacOS. I did add basic support for Homebrew in NymphCast, but without a MacOS system to test it on, who knows whether it works.

Anything But Linux

The world of desktop systems is larger than just Windows, MacOS and Linux, of course. Even mobile OSes like iOS and Android can be considered to be ‘desktop OSes’ with the way that they’re being used these days, also since many smartphones and tablets can be hooked up to to a larger display, keyboard and mouse.

How to bootstrap Android development, and how to develop native Android applications has been covered before, including putting APK files together. These are the typical Android installation files, akin to other package manager packages. Of course, if you wish to publish to something like the Google Play Store, you’ll be forced into using app bundles, as well as various ways to signing the resulting package.

The idea of using a package for a built-in package manager instead of an executable installer is a common one on many platforms, with iOS and kin being similar. On FreeBSD, which also got a NymphCast port, you’d create a bundle for the pkg package manager, although you can also whip up an installer. In the case of NymphCast there is a ‘universal installer’ built into the Makefile after compilation via the fully automated setup.sh shell script, using the fact that OSes like Linux, FreeBSD and even Haiku are quite similar on a folder level.

That said, the Haiku port of NymphCast is still as much of a Beta as Haiku itself, as detailed in the write-up which I did on the topic. Once Haiku is advanced enough I’ll be creating packages for its pkgman package manager as well.

The Linux Chaos Vortex

There is a simple, universal way to distribute software across Linux distributions, and it’s called the ‘tar.gz method’, referring to the time-honored method of distributing source as a tarball, for local compilation. If this is not what you want, then there is the universal RPM installation format which died along with the Linux Standard Base. Fortunately many people in the Linux ecosystem have worked tirelessly to create new standards which will definitely, absolutely, totally resolve the annoying issue of having to package your applications into RPMs, DEBs, Snaps, Flatpaks, ZSTs, TBZ2s, DNFs, YUMs, and other easily remembered standards.

It is this complete and utter chaos with Linux distros which has made me not even try to create packages for these, and instead offer only the universal .tar.gz installation method. After un-tar-ing the server code, simply run setup.sh and lean back while it compiles the thing. After that, run install_linux.sh and presto, the whole shebang is installed without further ado. I also provided an uninstall_linux.sh script to complete the experience.

That said, at least one Linux distro has picked up NymphCast and its dependencies like Libnymphcast and NymphRPC into their repository: Alpine Linux. Incidentally FreeBSD also has an up to date package of NymphCast in its repository. I’m much obliged to these maintainers for providing this service.

Perhaps the lesson here is that if you want to get your neatly compiled and packaged application on all Linux distributions, you just need to make it popular enough that people want to use it, so that it ends up getting picked up by package repository contributors?

Wrapping Up

With so many details to cover, there’s also the easily forgotten topic that was so prevalent in the Windows installer section: integration with the desktop environment. On Windows, the Start menu is populated via simple shortcut files, while one sort-of standard on Linux (and FreeBSD as corollary) are Freedesktop’s XDC Desktop Entry files. Or .desktop files for short, which purportedly should give you a similar effect.

Only that’s not how anything works with the Linux ecosystem, as every single desktop environment has its own ideas on how these files should be interpreted, where they should be located, or whether to ignore them completely. My own experiences there are that relying on them for more advanced features, such as auto-starting a graphical application on boot (which cannot be done with Systemd, natch) without something throwing an XDG error or not finding a display is basically a fool’s errand. Perhaps that things are better here if you use KDE Plasma as DE, but this was an installer thing that I failed to solve after months of trial and error.

Long story short, OSes like Windows are pretty darn easy to install applications on, MacOS is okay as long as you have bought into the Apple ecosystem and don’t mind hanging out there, while FreeBSD is pretty simple until it touches the Linux chaos via X11 and graphical desktops. Meanwhile I’d strongly advise to only distribute software on Linux as a tarball, for your sanity’s sake.