Mysterious Files PH

It’s no real secret that battery packs for power tools aren’t the foremost when it comes to user serviceability, so if said battery pack suddenly stops charging outside of warranty, you generally just e-waste it. That’s what [The Repair Forge] could have done for the Makita battery pack in question, but instead it was opened up for a diagnosis and fix.

Rather than the charger throwing up an error with this specific battery, it would flash its red LED and run its fan, but never actually start the charging process. Apparently the charger seems to think that the battery is either too hot or cold to be charged, which already gives a big hint as to what might be wrong.

Using the open source PocketOBI tool it’s possible to query the battery, which showed that one of the internal thermistors reported the battery being at a chilly -30°C while the other a more reasonable 28°C. After popping open the pack and measuring the thermistors, the faulty one registered as infinite resistance thus confirming that it had failed.

By putting in a temporary resistor this diagnosis was confirmed, thus the next step will be to replace said thermistor. This same procedure was then used with a second battery, whose thermistor read a wild 64°C.

Overall it’s a pretty easy fix, using a 20 cent part, with the entirety of diagnosis to repair taking maybe ten minutes when using a tool like PocketOBI, itself based on the great Open Battery Information project that originally reverse-engineered the Makita battery protocol.

Gears are usually the biggest contributors to backlash in a mechanical system, but they’re far from the only culprits. Ball bearings are a less obvious source of imprecision, since any gaps between the balls and the races can lead to axial wobble. Precision mechanisms can eliminate this by pairing two ball bearings, holding the outer races fixed, and applying a preload force to the inner traces. [Chronova Engineering], however, has a different solution, for which he split a ball bearing in half.

Besides taking up more room, thermal expansion also means that it’s difficult to apply a consistent preload force between two ball bearings. Instead, to make a self-contained preloaded bearing, [Chronova Engineering] first disassembled a single ball bearing. The most difficult part of this is taking apart the ball cage; the two parts of this are normally riveted together, but he managed to find a crimped cage and pry it apart. After taking the bearing completely apart, he cut the outer trace in half along the circumference, then reassembled the bearing. The split outer trace makes it possible to press the two halves together, preloading it and removing slop.

To see how well this worked, [Chronova Engineering] replaced the the ball bearing supporting one end of the feed screw for a milling machine with this new bearing. Before the replacement, it had a backlash of 0.1 to 0.2 millimeters; after the modification, it dropped to 30 to 40 microns. This kind of bearing is already known in the machining world – four-point-contact bearings use a very similar principle – but they don’t seem to be well known.

For more about these common yet remarkable rotary mechanisms, check out our article on bearings. If, on the other hard, precision isn’t a priority, you can always 3D print ball bearings.

In the world of children’s toys there are many offerings which are meant to look like devices used by older kids or even adults, with the Fisher Price Laugh & Learn Lil’ Gamer toy bearing quite the resemblance to Nintendo’s iconic Game Boy. Although this factoid could be filed away as amusing trivia before passing said toy to a child for its requisite physical abuse by said child, a purported adult can still have a lot of fun with this toy by modding it into a real Game Boy, as [KOUZEX] recently did.

Part of the challenge here is to not just treat it as an unconventional replacement shell for a genuine Game Boy, but to retain as much of the child toy’s look and feel as possible. This includes things like buttons and even the weird sliding blocks on the side.

For the functional components a Game Boy Color with a busted screen was chosen as a donor, with the GBC mainboard fitting almost perfectly inside its new shell. Wires were then soldered to bridge Nintendo’s PCB with the toy’s PCB to make the original buttons and speaker work. After blowing a fuse on the GBC mainboard due to likely some power back feeding, the toy’s PCB had its non-essential parts stripped, but fortunately without further damage to the grafted in electronics.

Most of this mod is quite straightforward, just with some creativity required to add a Select and Start button as these were notably absent from the original. The new, rather large replacement OLED screen is a nice upgrade too and actually fits pretty well with the chunky look of the child’s toy. Even as mostly a joke mod, it seems surprisingly functional.

As far as desktop microcomputers for mere mortals went in the first half of the 1980s, there was a sharp distinction between home computers such as the many 8-bit machines we regularly see here, and what you might call professional computers such as a CP/M word-processor or the earliest IBM PCs. These were conservative machines, boring even, with command line interfaces and mostly text-mode software.

When the middle of the decade saw the arrival of mass-market machines such as the Macintosh or the Amiga with their beautiful GUIs, a PC with DOS couldn’t yet compete. [Jggonz] then is over four decades late with the beautiful os8088, a fully-functional OS for 8088 IBM PCs and clones, with a very slick Mac-style GUI.

os8088 is a single-floppy OS that provides preemptive multitasking and fully loadable software alongside that GUI, unlike other similar projects we’ve seen it’s not an all-in-one compiled application that just looks like an OS. There’s a second floppy with a suite of software that would have been seriously impressive back in the day, with games, graphics, and demos. It’s a shame that this thing appeared in 2026 when there is little need of it.

You can try it for yourself either on real hardware, your own emulator, or even in an in-browser emulator. Sadly it’s not OS enough to fulfill the requirements for a Daily Drivers test drive, but it’s definitely fun to play with. Bonus, if you run it on a Book8088.

A recent addition to mountain bikes is the dropper seat post. This invention is in the vein of office swivel chairs, allowing the seat height to be adjusted with a simple handlebar mounted lever. They are rather fascinating inventions ranging in complexity from simple mechanical systems, to electronic monstrosities actuated by Bluetooth. Inspired by the panoply of possibilities, [kane components] set forth to create such a home-built dropper post. 

Inspired by woodworking bar clamps, [kane’s] design utilizing angled plates binding against a rail inside the dropper post. Two pairs of plates sitting at opposite angles resist opposite forces from either the rider sitting on the post, or the return spring. A simple cable actuated cam moves the plates to a nonbinding position when the lever is actuated, and springs return the plates to a binding rest-state. The return is handled by an air spring pressurized against a piston at the bottom of the shaft.

Though 3D printing could be used for a cursory test the mechanism, properly machined parts are needed to handle the loads running through a typical seat post. But instead of machining everything from scratch, [kane] reused the lower post and bushings from a broken post. To fit everything together, the lower post got thread milled so the entire mechanism can be threaded into the seat post as a replaceable cartridge. The upper telescopic section consists of aluminum tubing and a custom machined seat clam mechanism press-fit together.

As is the case with all engineering projects, a number of issues came forth once the dropper post made it onto a bike. Issues ranged from the cable pull causing the seat post to move slightly, to all manner of mechanical jamming. Filing down the ball end of the cable so it didn’t rub against the outer-housing of the seat post fixed that particular issue. The two-piece upper design also proved problematic with the press-fit having a bad tendency to come apart.

Despite these particular issues, did it end up working? No, not consistently. The binding mechanism does not consistently produce enough force to keep the dropper post from falling under a rider’s weight. Regardless, we really enjoyed following along with [kane] for the journey of creating such a mechanically complicated bicycle component!

To our surprise, this isn’t the first dropper post hack we have come across. So make sure to check out this bodge of a fix for a far more complex (and expensive) dropper next!

For most people the term ‘DNA sequencing’ probably brings to mind large, expensive laboratory equipment in sterile rooms, but over the past decades technological progress really has had its way with it, to the point where it’s now just another small portable device. Something like the Oxford Nanopore MinION unit that [Mike] recently took to bits to ogle at the intricate insides.

This device was trialed in 2014 in a limited release before its commercial release in 2015, with this paper by [Miten Jain] et al. in Genome Biology detailing the workings of this nanopore sequencer. At a mere $2,000 it’s rather remarkable how affordable it is, though this comes with the caveat of the consumables, which are also shown in the video. These come in at a cool £690 per unit, can sequence either RNA or DNA and can be used at most a few times before they need to be replaced.

The main unit is fairly simple, featuring a Xilinx Spartan 6 FPGA and a rather nice slim fan-based cooling solution. For the nanopore unit you get the typical microfluidics system, to guide the deposited fluid containing the genetic material to sequence over the nanopore system. In here we see the actual magic as well, in the form of the high-density pitch ICs on both sides of the PCB inside the consumable sequencer unit.

Although this particular unit got discontinued already, the consumables are still available for it if you are feeling the sequencing itch. Of course, we’re likely to see the costs for DNA and RNA sequencing to keep plummeting, as what were once complex chips get overtaken once again by the progress of technology.

If you’ve done much networking, you surely know the frustration of trying to connect to something, say a Raspberry Pi, that lives behind your consumer router. There are a number of solutions for this, ranging from opening ports on your router along with dynamic DNS. Or, you can operate a VPN server on your network. Modern Linux has a facility called Wireguard that lets you create secure network tunnels very easily, but it is a little difficult to set up. But there are tools like Tailscale that can do most of the work for you. There’s only one problem: Tailscale is sorta-kinda free, but not really. But it turns out, you can build your own Tailscale network, and it is easier than you might imagine.

In all fairness, Tailscale’s free tier is good and recently got even more generous, allowing unlimited nodes and up to six users. That’s plenty for most hackers. However, as we’ve seen before, what they can give they can also take away. Besides, there are some extra services you still have to pay for if you want them, but overall, the free tier is more than enough for most people.

On the other hand, no matter how great the free tier may be, some people don’t want to run things on other people’s hardware. Or you need that 7th user. Or you need paywalled features. No worries. Headscale is a self-hosted service that can do nearly everything the cloud portion of Tailscale does, and if you have a place to host it, you can be your own Tailscale server.

For the client side? That’s the best part. Headscale works seamlessly with the existing Tailscale clients. You simply have to point them to your server instead of the defaults.

The Original: An Overview

WireGuard itself is wonderfully simple. Each peer has a public/private key pair and a list of networks reachable through the peer. The difficulty isn’t WireGuard’s cryptography; it is managing a useful network of machines that move around. Each node gets a 100.x.x.x IP address and a DNS name that allows you to talk to it over an encrypted tunnel directly (at least, usually).

Suppose your laptop is at a coffee shop, your Raspberry Pi is behind your home router, and a server is sitting in a VPS somewhere. None necessarily has a convenient fixed public address. Both of them may be behind carrier-grade NAT. Their addresses may change. Somehow they need to discover one another, exchange enough information to establish secure connections, and update that information as circumstances change.

Tailscale operates what is usually called the control plane. The clients register with it, authenticate, learn which other machines they are allowed to see, and how to reach them. This distinction is important: your actual traffic does not flow through the Tailscale control server. The clients attempt to establish direct WireGuard connections to one another. Under normal circumstances, your data doesn’t go anywhere else.

If NAT or firewalls make that impossible, Tailscale can fall back to one of its DERP relay servers. DERP stands for Designated Encrypted Relay for Packets. The relay can pass your encrypted packets along, but it can’t decrypt them.

This architecture explains why Tailscale works so well. You get a private address for every participating machine and, with MagicDNS, convenient names instead of addresses. You can also designate a machine as an exit node (that is, route all network traffic through the remote node), advertise an entire LAN through a subnet router, control access with policies, SSH into a remote node, and do several other tricks.

With generous free limits, why bother standing up your own server? Most Hackaday readers can already answer that question. You can make any number of justifications for why you want to run your own DNS, mail server, or Git servers. Privacy. Extra features. Total control. But the truth is we just want to, and that’s ok.

Enter Headscale

Headscale describes itself as an open source, self-hosted implementation of the Tailscale control server intended primarily for self-hosters and hobbyists. It supports the basic things you’d expect, including MagicDNS, IPv4 and IPv6, subnet routers, exit nodes, tags, ACLs, Tailscale SSH, and file sharing. It doesn’t reproduce every commercial Tailscale feature, so checking the compatibility list is worthwhile if you depend on something exotic.

You’ll also need somewhere to put it. The official documentation expects a Linux or BSD server with a public IP address and recommends making Headscale available over HTTPS on port 443. That sounds more intimidating than it is. A tiny VPS is ideal. If you already have a public server doing other jobs, Headscale can sit behind a reverse proxy such as Apache, nginx, or Caddy.

If you are really on a budget, consider using something like Oracle’s OCI Free Tier. Of course, now you are trading one free plan for another. And, in all fairness, Oracle just cut some free limits in half this month. But it is easy enough to change servers quickly if the need arises. You can just as well use a local machine with dynamic DNS and a port forward.

There is one wrinkle: the Tailscale control protocol uses a somewhat unusual WebSocket upgrade, so don’t assume that every arbitrary HTTP proxy configuration will work. The Headscale documentation provides working configurations for the usual suspects.

Installation is straightforward, particularly on Debian or Ubuntu, where official packages provide a user account, default configuration, and systemd unit. The important file is normally:

/etc/headscale/config.yaml

A basic installation will use SQLite, so no need for a big database package. You’ll need to create your first user:

headscale users create hackaday

The trick to connecting a client is to tell it to use your coordination server. For Linux:

tailscale --up --login-server https://your-server-url

Usually, it will bring up your browser for you to log in. You might notice you haven’t provided a password. To log in, you’ll get a command you have to run on the server. However, you can also create keys to preshare if that’s not feasible. There are also options to set up SSO with something like Google.

Even the Android client can take an alternative server, although it is tricky to find. In the accounts page, you have to open the “three dot” menu to reveal “use alternative server.”

What About DERP?

Even with this set up, you are still using the public DERP servers, or, at least, you might be. If you look at the status of an active connection, you’ll see something like this:

active; offers exit node; direct 158.61.222.64:41641, tx 428 rx 348

The direct keyword means your computer and that node are directly connected. In that case, you aren’t using any DERP server at all. It is possible to run your own DERP server, but that may or may not be a performance problem. If your cheap VPS is running halfway around the world, pushing packets back and forth could get slow. Keep in mind, the DERP servers only handle encrypted packets they can’t read, so for most people, you are probably better off at least starting with the public servers.

HeadPlane

Headscale itself is unapologetically server software. Administration is primarily through configuration files and the headscale command.

I don’t mind that, but Tailscale’s web dashboard is undeniably convenient. Headplane offers something similar. It is a separate open source project that provides a web administration interface for Headscale. It can display and manage machines, routes, users, ACLs, tags, DNS settings, and other parts of the network. It also supports OpenID Connect for authentication and can even provide browser-based SSH access.

If you’ve used the official Tailscale administration interface, Headplane makes a self-hosted installation feel much more familiar. The usual deployment is in a container. Headplane talks to Headscale using an API key, which you can generate as part of the install process.

Exactly how you set it up depends on how you have Headscale deployed, so the exact steps I took may or may not help you. And, of course, you probably want to secure the interface either behind https or keep it accessible only via the Headscale network.

One thing that Headplane can do is allow you to have a tailscale ssh session into a machine via the browser. This turns out to be a pain to set up, but it does work. If Headplane doesn’t suit you, there are other options.

Summary

If you want to experiment, I’d suggest this order. If you haven’t used Tailscale before, get a free account and try it out for a bit. If it isn’t for you, you’re done. If you don’t mind the free tier limits, you are, again, done.

But if you are like me, you’ll get the itch to do your own setup. Get your public server ready and install Headscale. Administer it with the command line. Make sure it is working for a bit. The biggest thing that I appreciated was having better control over my DNS setup, but there are other features you might appreciate if you use, for example, ACL security.

Then, if you don’t like the CLI, try headplane. Once you are bored, you can work on single sign-on and your own DERP servers, if you like.

Headscale a nice example of something Linux has always been particularly good at. Start with an application that hides a complicated technology behind an easy interface. Pull back one layer. Discover that the complicated part is actually composed of several understandable pieces. Replace one of those pieces with an open source implementation.

We’ve looked at wireguard and tailscale before.