If William Gibson and Bruce Sterling had written an arcade scene into “The Difference Engine”, it probably would have looked a lot like [Pete Wood]’s Meccano Martian Mission, as illustrated in the video below by the [London Meccano Club]. Meccano Martian Mission is an homage to Atari’s 1978 Lunar Lander video game, but entirely electromechanical and made of– you guessed it– Meccano.

You might think Meccano is “too modern” to count as steampunk, but it squeaks just into the Victorian era. The first sets hit stores in 1901, the last year of Queen Victoria’s long reign. Since then, Meccano has developed a large following that has produced some truly impressive constructions, and this arcade game can stand amongst the best of them.

The game has all the features of the original: a swiveling spaceship, two-axis speed control, and even a little yellow flame that pops out when you are applying thrust. There’s a timer and a fuel gauge, and just like the original, there are easier and harder landing pads that offer score multipliers. While the score must be totted up manually, the game will detect a crash and flag it with a pop-down banner. It really has to be seen to be believed. It’s all done with cams and differentials hitting potentiometers and microswitches — not an Arduino in sight; [Pete] does a good job explaining it in the second half of the embedded video, starting about 10 minutes in.

The brains of the operation: cams and gears, and ingenuity.

Sure, might not be new or groundbreaking — these are old, old techniques — but not many people know them well enough to use them anymore, especially not with this degree of sophistication. To see these electromechanical techniques applied anachronistically to replicate one of the great pioneers of the arcade world tickles our fancy. It’s no wonder that perfecting this mechanical marvel has taken [Pete Wood] a decade.

The project reminds us of the Meccano Pinball Machine featured here years ago, but that somehow felt like a more natural fit for the apparently undead building kits. We lamented Meccano’s demise in 2023,but the brand is apparently being revived this year. Hopefully, that means there can be more young members for the [London Meccano Club] and groups like them, to keep the perforated-steel flame alive through another six reigns.

This hack is the bee’s knees, and we’re very thankful to [Tim Surtell] for the tip. Remember, the tip line is always open!.

From Blog – Hackaday via this RSS feed

Many FDM filament dryers have a port through which you can guide the filament. This handy feature allows you to print from the spool without removing it from the dryer, saving time and limiting exposure to (moist) air. Unfortunately, these exit ports aren’t always thought out very well, mostly in terms of the angle with the spool as it unrolls. The resulting highly oblique orientation means a lot of friction of the filament on the side of the port. This issue is addressed in a recent [Teaching Tech] video, with a simple, low-cost solution.

The basic idea is to have a swiveling port, inspired by a spherical bearing. The design shown in the video uses a PC4-M6 pneumatic connector to pass the PTFE tube. Connector choice is critical here, as many PC4-M6 pneumatic connectors won’t accommodate the PTFE.  As a fallback, you can drill out a connector to enable this.

Once the connector is sorted, you need a 13 mm (~0.5″) step drill bit to widen the opening in the filament dryer. This ready-to-print version has 10 degrees of freedom in any direction, but you can adapt it to fit your needs. With this mod installed, the angle with which the filament enters the port should remain as close to zero as possible, preventing both friction and damage to the port and filament.

From Blog – Hackaday via this RSS feed

It’s a common enough problem: you’re hitting the books, your phone dings with a notification, and suddenly it’s three hours later. While you’ve done lots of scrolling, you didn’t do any studying. If only there were a quick, easy project that would keep an eye on you and provide a subtle nudge to get you off the phone. [Makestreme] has that project, an AI study lamp that shifts from warm white to an angry red to remind students to get back to work. See it in action in the demo video below.

The project is pretty simple: the components are an ESP-32c3, a WS2812b addressable RGB LED strip, and a Grove Vision AI module. The Grove Vision AI module is, well, an AI vision module. It’s an easy way to get image recognition into your projects, especially considering the wealth of pre-trained models available from Seeed’s Sensecraft AI. As it turns out, Senscraft had a pre-trained model to identify cell phones that worked with the Grove Vision module, so putting things together probably didn’t take [Makestreme] away from studying for too long. If you want to replicate the project, it will take you even less time, since they were helpful enough to share their code on Hackaday.io.

The camera is placed above [Makestreme]’s desk to watch for phone use, and the lamp itself was made of things they had lying around. You could, of course, 3D Print one, or make it out of plywood if you were looking for a different aesthetic. If you don’t need help studying, you could use the Grove Vision module to make a creepy clock.

From Blog – Hackaday via this RSS feed

With the newer generation of quick and reliable 3D printers, we find ourselves with the old collecting dust and cobwebs. You might pull it out for an emergency print, that is if it still works… In the scenario of an eternally resting printer (or ones not worth reviving), trying to give new life to the functional parts is a great idea. This is exactly what [MarkMakies] did with a simple RC rover design from an old Makerbot Replicator clone. 

Using a stepper motor to directly drive each wheel, this rover proves its ability to handle a variety of terrain types. Stepper motors are far from the most common way to drive an RC vehicle, but they can certainly give enough power. Controlling these motors is done from a custom protoboard, allowing the use of RC control. Securing all these parts together only requires a couple of 3D printed parts and the rods used to print them. Throw in a drill battery for power, and you can take it nearly anywhere! 

With the vehicle together [MarkMakies] tested to a rocketing 0.6 m/s fully loaded 4WD. Of course, less weight proves more exciting. While [Mark] recognizes some inherent issues with a stepper-driven all-terrain vehicle, we could see some clever uses for the drive system.

Broken down 3D printers are a dime a dozen, so you should try making something similar by checking out [Mark]’s design files! 3D printers are machines of fine-controlled movement so it’s no surprise to find reuse in these projects is fairly common. Just like this nifty DIY camera slider!

From Blog – Hackaday via this RSS feed

After having been involved in an accident, [Kurt Kohlstedt] suffered peripheral neuropathy due to severe damage to his right brachial plexus — the network of nerves that ultimately control the shoulder, arm, and hand. This resulted in numbness and paralysis in his right shoulder and arm, with the prognosis being a partial recovery at best. As a writer, this meant facing the most visceral fear possible of writing long-form content no longer being possible. While searching for solutions, [Kurt] looked at various options, including speech-to-text (STT), before focusing on single-handed keyboard options.

More after the break…

The reason why STT didn’t really work was simple: beyond simple emails and short messages, the voice-driven process just becomes too involved and tedious with editing, rearranging, and deleting of text fragments. [Kurt] couldn’t see himself doing a single-pass narration of an article text or dealing with hours of dictating cursor movements.

One of the first single-hand typing methods he tried is as simple as it’s brilliant: by moving the functional hand a few keys over (e.g. left hand’s index finger on J instead of F), you can access all keys with a single hand. This causes a lot more stress on the good hand, though. Thus, for a long-term solution, something else would be needed.

Thanks to his state loan program (MNStar), [Kurt] was able to try out Maltron’s ‘Key Bowl’, the TIPY ‘Big Fan’, and the Matias Half-QWERTY keyboard, which describes pretty much what they look like. Of these, the Maltron was functional but very clunky, the TIPY required learning a whole new keyboard layout, something which [Kurt] struggled with. Despite its mere 22 keys, the Matias half-QWERTY offered the most straightforward transition from using a full keyboard.

It was the Matias keyboard that worked the best for [Kurt], as it allowed him to use both his left hand normally, along with adapting the muscle memory of his right hand to the left one. Although [Kurt] didn’t select the Matias in the end, it did inspire him to choose the fourth option: using a custom keymap on his full-sized QWERTY keyboard. In the remaining two parts in this series, Kurt] takes us through the design of this keymap along with how others can set it up and use it.

Our own [Bil Herd] found himself on a similar quest after losing a finger to a ladder accident.

Thanks to [J. Peterson] for the tip.

From Blog – Hackaday via this RSS feed

The advent of cheap and accessible one-off PCB production has been one of the pivotal moments for electronic experimenters during the last couple of decades. Perhaps a few still etch their own boards, but many hobbiest were happy to put away their ferric chloride. There’s another way to make PCBs, though, which is to mill them. [Tom Nixon] has made a small CNC mill for that purpose, and it’s rather beautiful.

In operation it’s a conventional XYZ mechanism, with a belt drive for the X and Y and a lead screw for the Z axis. The frame is made from aluminium extrusion, and the incidental parts such as the belt tensioners are 3D printed. The write-up is very comprehensive, and takes the reader through all the stages of construction. The brains of the outfit is a Creality 3D printer controller, but he acknowledges that it’s not the best for the job.

It’s certainly not the first PCB router we’ve seen, but it may be one of the nicer ones. If you make a PCB this way, you might like to give it professional-looking solder mask with a laser.

From Blog – Hackaday via this RSS feed

Both small children and cats have a certain tendency to make loud noises at inopportune times, but what if there were a way to combine these auditory effects? This seems to have been the reasoning behind the creation of the Meowsic keyboard, a children’s keyboard that renders notes as cats’ meows. [Steve Gilissen], an appreciator of unusual electronic instruments, discovered that while there had been projects that turned the Meowsic keyboard into a MIDI output device, no one had yet added MIDI input to it, which of course spurred the creation of his Meowsic MIDI adapter.The switches in the keys of the original keyboard form a matrix of rows and columns, so that creating a connection between a particular row and column plays a certain note. [Steve]’s plan was to have a microcontroller read MIDI input, then connect the appropriate row and column to play the desired note. The first step was to use a small length of wire to connect rows and columns, thus manually mapping connections to notes. After this tedious step, he designed a PCB that hosts an Arduino Nano to accept input, two MCP23017 GPIO expanders to give it enough outputs, and CD4066BE CMOS switches to trigger the connections.[Steve] was farsighted enough to expect some mistakes in the PCB, so he checked the connections before powering the board. This revealed a few problems, which some bodge wires corrected. It still didn’t play during testing, and after a long debugging session, he realized that two pins on an optoisolator were reversed. After fixing this, it finally worked, and he was able to create the following video.Most of the MIDI hacks we’ve seen involved creating MIDI outputs, including one based on a Sega Genesis. We have seen MIDI input added to a Game Boy, though.

From Blog – Hackaday via this RSS feed

We’ve all been there. [Kasyan TV] had a universal adapter for a used laptop, and though it worked for a long time, it finally failed. Can it be fixed? Of course, it can, but it is up to you if it is worth it or not. You can find [Kasyan’s] teardown and repair in the video below.

Inside the unit, there were a surprising number of components crammed into a small area. The brick also had power factor correction. The first step, of course, was to map out the actual circuit topology.

The unit contains quite a bit of heat sinking. [Kasyan] noted that the capacitors in place were possibly operated very near their operating limit. Since the power supply burned, there was an obvious place to start looking for problems.

One of the two synchronous rectifier FETs was a dead short. Everything else seemed to be good. The original FETs were not available, but better ones were put in their place. A snubber diode, though, appeared to be the root cause of the failure. Testing with a programmable load showed the repair to be a success.

Of course, you aren’t likely to have this exact failure, but the detailed analysis of what the circuit is doing might help you troubleshoot your own power supply one day.

We were surprised none of the traces burned out, but that can be fixed, too. Oddly, this cheap supply looked to be better than some of the inexpensive bench supplies we’ve seen. Go figure.

From Blog – Hackaday via this RSS feed

If you’ve worked on a project with small LEDs, you know the frustration of determining their polarity. This ingenious LED Probe from [David] packs a lot of useful features into a simple, easy-to-implement circuit.

Most multimeters have a diode test function that can be used to check LEDs; however, this goes a step further. Not only will the probe light up an LED, it will light up no matter which side of the LED the leads are touching. A  Red/Green LED on the probe will indicate if the probe tip is on the anode or cathode.

The probe is powered by a single CR2032 battery, and you may notice there’s no on/off switch. That’s because the probe enters a very low-current sleep mode between uses. The testing intelligence is handled by either an ATtiny85 or, in the newest version, an ATtiny202, though the basic concept and design are compatible with several other chips. All the design files for the PCB, the ATtiny code, a parts list, and a detailed explanation of how it works are available on [David]’s site, so be sure to check them out. Once you build one of these probes, you’ll want something to test it on, so explore some of the LED projects we’ve featured in the past.

From Blog – Hackaday via this RSS feed

The Francis! Francis! X1 espresso machine in its assembled state. (Credit: Samuel Leeuwenburg)

Recently, [Samuel Leeuwenburg] got his paws on a Francis! Francis! X1 (yes, that’s the name) espresso machine. This is the espresso machine that is mostly famous for having been in a lot of big TV shows in the 1990s. In the early 2000s, the X1 even became a pretty good espresso machine after the manufacturer did some more tinkering with it, including changing the boiler material, upgrading the pump, etc.

In the case of the second-hand, but rarely used, machine that [Samuel] got, the machine still looked pretty good, but its performance was pretty abysmal. After popping the machine open the boiler turned out to be pretty much full of scale. Rather than just cleaning it, the boiler was upgraded to a brass version for better heat retention and other perks.

More after the break…

The best part of this relatively simple machine is probably that it has been reverse-engineered, making modding it very easy. After some thinking, [Samuel] decided to pull the very basic controller PCB and replace it with something capable of tighter temperature control. This turned into a custom PCB featuring the obligatory Raspberry Pi Pico along with a MAX3185 for water temperature measurement. The Pico had to be programmed to handle heater control duty.  There’s even an HTTP API on the WiFi-enabled Pico board.

Unfortunately, the all-metal enclosure also makes for a perfect Faraday cage, putting an end to remote automation dreams for now, at least. With the machine buttoned up, [Samuel] remembered that the primary task of an espresso machine is to make espresso, which it is now, fortunately, even more capable of than before the surgery, and which requires you to be present at the machine anyway.

Thanks to [Milo] for the tip.

From Blog – Hackaday via this RSS feed

The intersection between “woodworkers” and “programmers” is not a densely populated part of the Venn diagram, but [Michael Schiebler] is there with his Kerf Bend Wizard to help us make wood twist and bend like magic.

Kerf bending is a fine technique we have covered before: by cutting away material on the inside face of a piece of wood, you create an area weak enough to allow for bending. The question becomes: how much wood do I remove? And where? That’s where Kerf Bend Wizard comes to the rescue.

More after the break…

From spline (user input in black, expected output in pink)…

You feed it a spline– either manually or via DXF–and it feeds you a cut pattern that will satisfy that spline: just enough wood removed in just the right places that the edges of the cut should touch when the bend is achieved. This means less cut time and a stronger piece than eyeballing the kerfs. It works with both a table saw blade or a tapered end mill on a CNC or manual router. You can specify the kerf width of your table saw, or angle of your end mill, along with your desired cut depth.

… to cuts …

The output is DXF, convenient for use with a CNC, and a simple table giving distances from the edge of the piece and which side to cut, which is probably easier for use on the table saw. (Kerf Bend Wizard is happy to handle complex bends that require kerfing both sides of the material, as you can see.)

… to curved wood.

This was [Michael]’s thesis project, for which he hopefully got a good grade. The code is “semi-open” according to [Michael]; there’s a GitHub where you can grab an offline version for your own use, but no open-source license is on offer. Being a broke student and an artist to boot, [Michael] also can’t promise he will be able to keep the web version available without ads or some kind of monetization, so enjoy it while you can!

If CNCs or table saws aren’t your thing, kerf bending has long been used with laser cutters, too.

Our thanks (which, as always, is worth its weight in gold) to [Michael] for the tip. If you’re in the intersection of the Venn diagram with [Michael], we’d love to hear what you’re up to.

From Blog – Hackaday via this RSS feed

The Switch 2 Pro controller’s battery is technically removable, if you can get to it. (Credit: VK’s Channel, YouTube)

For those of us who have worked on SNES and GameCube controllers, we know that these are pretty simple to get into and maintain. However, in the trend of making modern game controllers more complex and less maintainable, Nintendo’s new Switch 2 Pro controller is giving modern Xbox and PlayStation controllers a run for their money in terms of repair complexity. As shown in a teardown by [VK] on YouTube (starting at nine minutes in), the first step is a disappointing removal of the glued-on front plate. After that you are dealing with thin plastic, the typical flimsy ribbon cables and a lot of screws.

The main controller IC on the primary PCB is an ARM-based MediaTek MT3689BCA Bluetooth SoC, which is also used in the Switch 2’s Joy-Cons. The 3.87V, 1070 mAh Li-ion battery is connected to the PCB with a connector, but getting to it during a battery replacement might be a bit of a chore.

More after the break…

The analog sticks are Alps-branded and do not seem to match any other sticks currently on the market. These are (disappointingly) also still resistive potentiometer sticks, meaning they might have to be replaced before long due to stick drift. Reassembly has a few tricky parts, especially with the two sticks being not identical, yet easy to swap by accident. Which would require a second disassembly round.

There’s also a soft-touch coating on these controllers, which have been known to get… gunky after a few years, so time will tell what the lifespan is here. As is typical, these controllers also only work with the Switch and not with a PC or other consoles. Overall, it seems like a nice, silent controller, but the repairability seems low at best.

From Blog – Hackaday via this RSS feed

Most of us spend our lives within reach of a device that provides a clock, stopwatch, and a timer – you’re almost certainly reading this article on such a device – but there are fewer options if you want a screen-free clock. [Michael Suguitan]’s TOKIDOKI rectifies this situation by combining those three functions into a single, physical, analog clock face.

More after the break…

TOKIDOKI displays time by lighting the appropriate segments of two concentric rings of colored LEDs (Adafruit Neopixel rings); the inner ring indicates hours, while the outer ring displays minutes. There is one clock hand, and while it does indicate the passage of time in some situations, its main function is as a dial to control the clock’s different functions. The hand is connected to a Dynamixel XL-330 servo motor, which also serves as a position sensor. Winding the dial clockwise starts a countdown timer, with each successive full rotation switching to a larger unit of time (a fun/unsettling feature is that the largest chronometric unit is the user’s expected lifetime: 84 years). Winding counterclockwise either starts a stopwatch or sets an alarm, depending on how many full rotations you make.A Raspberry Pi Pico running some MicroPython firmware manages the device and gets the current time from a local network. To soften the light’s quality, the LED rings are pointed backwards to provide back-lighting off of a recessed surface. The entire device is powered by USB-C, and is enclosed in a 3D-printed housing.This project was designed as an experiment in minimal interfaces, and it certainly achieved that goal, though we imagine that it takes a bit of time to get used to using this clock. We always enjoy seeing innovative clocks here, from digital to analogue, and those that split the difference.

From Blog – Hackaday via this RSS feed

The city of London is no stranger to tall constructions today, but long before the first skyscrapers would loom above its streets, Watkin’s Tower was supposed to be the tallest structure in not only London but also the entirety of the UK. Inspired by France’s recently opened Eiffel tower, railway entrepreneur and Member of Parliament [Sir Edward Watkin] wanted to erect a structure that would rival the Eiffel tower, as part of a new attraction park to be constructed near the Middlesex hamlet of Wembley. In a retrospective, [Rob’s London] channel takes a look at what came to be known as Watkin’s Folly among other flattering names.

The first stage of Watkin’s Tower at Wembley Park. The only to be ever completed. (Source: Wikimedia)

After [Gustave Eiffel], the architect of the Eiffel tower recused himself, a design competition was held for a tower design, with the Illustrated Catalogue of the 68 designs submitted available for our perusal. The winner turned out to be #37, an eight-legged, 366 meter tall tower, much taller than the 312.2 meter tall Eiffel tower, along with multiple observation decks and various luxuries to be enjoyed by visitors to Wembley Park.

Naturally, [Watkin] commissioned a redesign to make it cheaper, which halved the number of legs, causing caused subsidence of the soil and other grievances later on. Before construction could finish, the responsible company went bankrupt and the one constructed section was demolished by 1907. Despite this, Wembley Park was a success and remains so to this day with Wembley Stadium built where Watkin’s Folly once stood.

From Blog – Hackaday via this RSS feed

The Portal games were revolutionary not only for their puzzle-based, narrative-driven gameplay, but also for their unique physics engine, which let players open portals anywhere and conserve momentum and direction through them. They’re widely regarded as some of the best video games ever made, but even beyond that they have some extra features that aren’t talked about as much. Namely, there are a number of level editors and mods that allow the in-game components to be used to build things like logic gates and computers, and this project goes even further by building a working NES emulator, all within Portal 2.

The main limitation here is that Portal 2 can only support a certain number of in-game objects without crashing, far lower than what would be needed to directly emulate NES hardware. The creator of the project, [PortalRunner], instead turned to Squirrel, the Portal 2 scripting language, and set about porting an existing NES emulator called smolnes to this scripting language. This is easier said than done, as everything in the code needs to be converted eight bits and then all of the pointers in smolnes need to be converted to use arrays, since Squirrel doesn’t support pointers at all. As can be easily imagined, this led to a number of bugs that needed to be sorted out before the game would run at all.

For those interested in code golfing, porting, or cross-compatibility, this project is a master class not only in the intricacies of the Portal 2 scripting language but in the way the NES behaves as well, not to mention the coding skill needed to recognize unique behaviors of the C language and the Squirrel scripting language. But eventually [PortalRunner] is able to get Super Mario Bros. running in Portal 2, albeit with low resolution and frame rate. Since we heard you like games within games, someone else put DOOM inside DOOM so you can DOOM while you DOOM.

Thanks to [Mahdi] for the tip!

From Blog – Hackaday via this RSS feed

How hard could it be to make a chicken coop door that can be configured to open and close automatically using a straightforward interface? That’s the question that [Jeff Sandberg] set out with, after three years of using a more basic off-the-shelf unit that offered no remote access nor a convenient user interface. The use case for [Jeff] was rather straightforward: the door would be open during the day and closed at night to keep the hens safely inside the coop.

The commercial solution offered an RTC-backed programmable interface as well as a light sensor, but the latter wasn’t always reliable in inclement weather and making simple changes to the programming when e.g. the hens had to stay inside a day due to work on the yard, was much more complicated than needed, plus had to be done on the spot. The new system would solve all these ills.

That said, the existing door mechanism was doing a fine job and could be kept. This just left making a new box with electronics to control it, starting with an ESP32C3 with the ESPHome firmware that is hooked into the local Home Assistant system, along with a motor to lift and lower the door and with magnetic contact sensors.

So far so easy. The hard part came with the installation, which involved trenching to the hen house for mains power, repairing the damage from this, and troubleshooting a power issue that turned out to be due to a dodgy power adapter. The payoff is that now the chicken coop is also part of the smart home and their owner never has to trudge through a soggy garden again to adjust the programming on a dim LC display with far too few buttons.

From Blog – Hackaday via this RSS feed

Today in old school nostalgia our tipster [Clint Jay] wrote in to let us know about this rotary dial.

If you’re a young whippersnapper you might never have seen a rotary dial. These things were commonly used on telephones back in the day, and they were notoriously slow to use. The way they work is that they generate a number of pulses corresponding to the number you want to dial in. One pulse for 1, two pulses for 2, and so on, up to nine pulses for 9, then ten pulses for 0.

We see circuits like this here at Hackaday from time to time. In fact, commonly we see them implemented as USB keyboards, such as in Rotary Dial Becomes USB Keyboard and Rotary Dialer Becomes Numeric Keypad.

One thing that makes this particular project different from the ones we’ve seen before is that it doesn’t require a microcontroller. That said, our hacker [Mousa] shows us how to interface this dial with an Arduino, along with sample code, if that’s something you’d like to do. The schematic for the project shows how to connect the rotary dial (salvaged from an old telephone) to both a 7-segment display and a collection of ten LEDs.

The project write-up includes links to the PCB design files. The guts of the project are a 4017 decade counter and a 4026 7-segment display adapter. Good, honest, old school digital logic.

From Blog – Hackaday via this RSS feed

When a wrist mounted keyboard floated past in the Hackaday feed, a mental image surfaced, perhaps something like a Blackberry keyboard mounted on a wrist cuff, maybe with some kind of display. It’s impressive indeed then to open the link and see [AdamLeBlanc]’s Schist01. It’s a wrist mounted keyboard, but with its bracket curving in front of the had to support a custom ergonomic chording keyboard, it’s definitely a break from the norm.

The wrist mount has clearly taken a lot of thought, and despite looking something like the arm of a Star Trek Borg, appears comfortable. It’s extremely adjustable, and can be demounted into several different parts. Meanwhile the keyboard itself has been formed to his hand by a trial and error process involving keycaps and a clay model. there’s even a thumb-operable touchpad.

We like this peripheral a lot, for the huge attention to detail that has gone into its design, for its boldness, and because we can’t help seeing ourselves using it as the input device for a futuristic head-mounted display. For now though we don’t have any futuristic silver clothing in the wardrobe, so that will have to wait. If you’d like to see more, there’s a video.

Thanks [Shotgun Moose] for the tip.

From Blog – Hackaday via this RSS feed

In the Blackberry-keyboard-based project lineage story last week, I covered how a series of open-source projects turned into Beepy, a cool Linux PDA with a lively community. To me, it’s yet another demonstration of power that open-source holds, and more importantly, it shows how even a small pet project of yours could cause big moves in the hardware world, provided you publish it – just ask [JoeN], [WoodWorkeR] and [arturo182].

The journey didn’t end there. For all its benefits, Beepy had some flaws to take care of, some board-killing flaws, even. The 5 V boost regulator was never intended for 4.7 V input it gets when charger is connected, and would occasionally cook itself. A charging current resistor was undersized, leading people to either bodge resistors onto their Beepy boards, or have their battery charge for 30 hours until full. A power path diode was undersized, too, and has burned out on more than a few devices. Also, Beepy’s feature package left things to be desired.

Beepy never made it beyond v1. If I had to guess, partially because of BB Q20 keyboard sourcing troubles, but also definitely some sort of loss of interest. Which is a shame, as the plans v1.5 of the hardware were pretty exciting. In the meantime, other players decided to take up the mantle – here’s a tale of three projects.

Improved, Colorful, Closed

I like to talk about all sides of open-source hardware, good and bad. We’ll start with the bad here. Sometimes, you’ll publish a project under an open license that requires other people to share their work if it’s based on your project files. Then, someone takes your files, makes none to minimal changes, closes the sources, maybe even completely removes the attribution, and starts selling them. That’s the story of Colorberry.

Left: OG Beepy, right: Colorberry; spot 10 differences. If one of them is “stripped of all attribution”, you get bonus points.

It was one of the first Beepy derivatives — seemingly fixing two of the three Beepy bugs, and adding support for a color display from JDI. Unfortunately, it also removed some important elements: namely the attribution to the Beepy on product or project pages – and closed-sourced the files.

Beepy’s PCB is licensed under a reciprocal (copyleft) license, which means that derivative product designers are supposed to share any changes they make. Without access to the source, it’s difficult to confirm that Colorberry really fixed the upstream Beepy bugs. It also makes it harder to diagnose and repair the hardware, and limits the chances the Colorberry would live on should its creator step away from the project.

Unfortunately, the problems don’t stop there. The code to drive the color screen is heavily based upon a driver produced by people in the Beepy community. Like the Beepy hardware, the license for the driver (GPL) requires that changes made to the code be made public. But when Alex, the Colorberry developer, was asked about publishing the code for this driver, he responded that it would happen “once the driver is ready.” A year later, the new story is apparently that he will release the sources once his personal stock of color screens runs out.

Because the driver is only published as (non-stripped) binaries on GitHub, it needs to be recompiled and republished by Alex with every Linux kernel update or distro that Colorberry could be used with. It’s also markedly harder to install (to the point people had to concoct multi-step install scripts), and I have it on good authority that the driver contains a bug that will actually reduce the lifetime of the display. But without the source for the driver, the community can’t fix it.

I confirmed this later on, having looked at the binary files myself – indeed, even the typos from someone else’s open-source driver are still present in Colorberry driver code.

From what I’ve seen, the Beepy open-source design has been a crucial factor for its community to flourish and keep thriving even two years later. Colorberry’s puzzling closed-source decisions just don’t add up to the same value, and I gather that’s a big part of why the project didn’t gain more traction.

The Colorberry isn’t the only Beepy clone to keep the hardware source to itself. The PiBerry from CarbonComputers doesn’t fix the bugs from the original handheld, unfortunately, but it does bring a higher resolution color display to the party. It also doesn’t try to erase its lineage, with both the PCB silkscreen and the documentation referencing the fact that it’s based on the Beepy. Even still, the board design files aren’t included in the PiBerry repository.

What’s interesting in this case is that CarbonComputers later made a newer PiBerry version in same form-factor, aimed at assembly from more off-the-shelf components, and that version does have its KiCad files published. I’m willing to give the creators the benefit of the doubt here, and say that not including the source files for the previous versions of the hardware might simply be an omission on their part and not intentional.

These two weren’t the only projects coming to life because of Beepy’s success – at times, if you get someone inspired enough with a project of yours, they could end up building an entire lineup of gadgets. Such is the case of Hackberry Pi, a project coming from a hacker named Zitao.

The Hackberry Family

Ever wanted the power of a Pi 5 in a portable package? That’s where you reach for the Hackberry Pi. The CM5 version is way sleeker than this one, I gotta say.

You might’ve seen the Hackberry Pi around – it’s a Beepy-like device with a 720×720 DPI screen derived from Adafruit’s Hyperpixel design and a Q20 keyboard. A number of parts in the first Pi Zero-based versions of the Hackberry Pi were visibly derived from the Beepy design. However, at least the later versions have been re-drawn from scratch in EasyEDA, with a number of diverging design paths, and Zitao has been prolific in building newer and generally better versions of the platform.

From a Pi Zero-based version with Nokia batteries, to Pi 5-based device powered by 18650s, the Hackberry has gone through quite a journey. Just a couple days ago from the time of this writing, the Compute Module-based version of the Hackberry Pi has become available, and it’s been selling like hotcakes.

Zitao’s hardware is inspiring in a few ways. For instance, the ways in which these devices avoid driver installation requirements, with keyboard connected over USB instead of I2C, powerbank chips with LED battery level display instead of the Beepy’s RP2040, and it goes even to the point of soldering a small Bluetooth receiver module onto the board to drive the onboard speakers from the Pi running the show. It’s a kludge, but at the same time, it’s hard to argue with things that work well in practice!

Hackberry Pi devices are also closed source, but at least schematics have been made available. This is good enough to spot most bugs, and those schematics have already been useful for people pointing out poor design decisions in the first versions. Of course, it’s still against the spirit of open-source and in particular the project that made Hackberry Pi possible in the first place – but at least it’s a step in the right direction.

Our Radically Open Beepy Clone

As you might have guessed, I don’t like closed-source devices. In particular I dislike devices that benefit from an open-source ecosystem and then burn the goodwill provided, as if to sterilize and salt the land that would otherwise serve other projects in the future.

Two v1 Blepis units: one assembled with a Sharp display, another with a cheaper color SPI one.

Over the last half a year, I’ve had the privilege of working on the Blepis, a Beepy successor built by a hacker collective I’m a part of, called HackMods. We’ve designed, planned out, and assembled the first versions of these boards together, with the goal of having a fleet of Linux PDAs.

Made by hackers for hackers, it’s an experiment in just how far you can push the Beepy design, and we’re keeping things as open-source as we found them – arguably even more so! In particular, even our case design is in FreeCAD and open-source, with .FCstd files included.

First major improvement we made was in screen support. Sharp Memory screens can be expensive and are often out of stock for months, and JDI screens are even more expensive than that, often the only options are overpriced eBay listings. This is somewhat okay for a one-off, but it is very sub-optimal if you’re building a fleet of a dozen hacker PDAs for you and your friends.

That’s why we’ve added support for the commonly available 3.2″ 320×240 18-pin SPI color screens in addition to Sharp and JDI screens. We even have touchscreen controller support for the 18-pin panels that come with a touch layer, and support backlight on displays which have it. Of course, the known Beepy bugs are fixed as well. Our 5 V boost is operating within spec, and we have a switch-mode battery charger expected to give off barely any heat at all while providing a fair bit of charging current.

The PCB, done mainly by [LinaLinn] and me, with others’ contributing to it in various ways. It would probably be easier to talk about what we didn’t add. Thankfully, for those things, we have an expansion connector!What else? Just for a start, we added an RTC, a vibromotor driver, and an onboard buzzer, not to mention things like QWIIC connectors for I2C and USB.

The Beepy didn’t have any onboard USB peripherals – you were expected to make use of the Pi Zero’s microUSB port. But we’ve added a whole USB ecosystem onto all the free space on the board – including a microSD reader, a slanted USB-C slot letting you connect a small USB-C 3.5 mm dongle soundcard for music playback (or other devices), and a USB hub chip to tie it all together. Apart from that, we support host mode on the bottom “charging” USB-C port, too – complete with 5 V power output.

Some of these features, like power output on the main USB-C port, are not supported by the firmware yet, But we’ve gotten pretty familiar with Beepy firmware while building v1, so, adding firmware support for those features is not expected to be that complicated.

Our expansion connector is also unparalleled when it comes to interfaces we expose. A single-row 23-pin header has 3.3 V, 5 V and VBAT power rails with over-current and backflow protection, plus I2C, SPI, UART, SDIO, PWM, and I2S, all ESD-protected.

We’ve already had a LoRa expansion module contributed by someone from the Beepy community, and one of our members has designed a DECT board. We plan on doing doing boards aimed at general-purpose hacking & BIOS chip flashing soon. If you ever wanted a PDA with a powerful expansion header for hardware hacking purposes, this is the design for you.

The Gift Of Giving Back

If you’re looking for a Linux PDA board, I hope you can appreciate the Blepis hardware design we bring to you, only possible because of a string of open-source projects before it. Our design files and driver/firmware sources are all on GitHub and GitLab, with a summary available on [Michael]’s BBKB ecosystem website.

Blepis is meant to work with JLCPCB PCBA, and we have a GitLab integration for exporting the project files – all the JLC part numbers are input into the schematics, so just upload the files and get a batch of motherboards delivered to your doorstep. To complete it, get a Pi Zero, a battery, a Blackberry Q20 keyboard, a display out of the list of supported ones, print the shell (v2-compatible shell coming soon), and off you go.

Seeing entirely new projects happen, each cooler and more advanced than the previous one, all because people kept publishing their code and PCB files, and then, getting to build a dream device for me and my friends thanks to someone else’s work – these kinds of experiences are what radicalized me in favour of being fervently pro-open-source. I see open-source philosophy live and thrive through dreams of hackers and barrels of viral licenses, through publishing despite imperfections, and building off each other’s dreams to turn the tide of tomorrow. I hope you get to experience it, too.

From Blog – Hackaday via this RSS feed

When home computers first appeared, disk drives were an expensive rarity. Consumers weren’t likely to be interested in punch cards or paper tape, but most people did have consumer-grade audio cassette recorders. There were a few attempts at storing data on tapes, which, in theory, is simple enough. But, practically, cheap audio recorders are far from perfect, which can complicate the situation.

A conference in Kansas City settled on a standard design, and the “Kansas City standard” tape format appeared. In a recent video, [Igor Brichkov] attempts to work with the format using 555s and op amps — the same way computers back in the day might have done it. Check out the video below to learn more.

These days, it would be dead simple to digitize audio and process it to recover data. The 1970s were a different time. The KC standard used frequency shift method with 2.4 kHz tones standing in for ones, and 1.2 kHz tones were zeros. The bit length was equal (at 300 baud), so a one had 8 cycles and a zero had 4 cycles. There were other mundane details like a start bit, a minimum stop bit, and the fact that the least significant bit was first.

The real world makes these things iffy. Stretched tape, varying motor speeds, and tape dropouts can all change things. The format makes it possible to detect the tones and then feed the output to a UART that you might use for a serial port.

There were many schemes. The one in the video uses an op-amp to square up the signal to a digital output. The digital pulses feed to a pair of 555s made to re-trigger during fast input trains but not during slower input trains. If that doesn’t make sense, watch the video!

The KC standard shows up all over the place. We’ve even used it to hide secret messages in our podcast.

From Blog – Hackaday via this RSS feed

Facebook and Yandex have been caught performing user-hostile tracking. This sort of makes today just another Friday, but this is a bit special. This time, it’s Local Mess. OK, it’s an attack with a dorky name, but very clever. The short explanation is that web sites can open connections to localhost. And on Android, apps can be listening to those ports, allowing web pages to talk to apps.

That may not sound too terrible, but there’s a couple things to be aware of. First, Android (and iOS) apps are sandboxed — intentionally making it difficult for one app to talk to another, except in ways approved by the OS maker. The browser is similarly sandboxed away from the apps. This is a security boundary, but it is especially an important security boundary when the user is in incognito mode.

The tracking Pixel is important to explain here. This is a snippet of code, that puts an invisible image on a website, and as a result allows the tracker to run JavaScript in your browser in the context of that site. Facebook is famous for this, but is not the only advertising service that tracks users in this way. If you’ve searched for an item on one site, and then suddenly been bombarded with ads for that item on other sites, you’ve been tracked by the pixel.

This is most useful when a user is logged in, but on a mobile device, the user is much more likely to be logged in on an app and not the browser. The constant pressure for more and better data led to a novel and completely unethical solution. On Android, applications with permission to access the Internet can listen on localhost (127.0.0.1) on unprivileged ports, those above 1024.

Facebook abused this quirk by opening a WebRTC connection to localhost, to one of the ports the Facebook app was listening on. This triggers an SDP connection to localhost, which starts by sending a STUN packet, a UDP tool for NAT traversal. Packed into that STUN packet is the contents of a Facebook Cookie, which the Facebook app happily forwards up to Facebook. The browser also sends that cookie to Facebook when loading the pixel, and boom Facebook knows what website you’re on. Even if you’re not logged in, or incognito mode is turned on.

Yandex has been doing something similar since 2017, though with a different, simpler mechanism. Rather than call localhost directly, Yandex just sets aside yandexmetrica.com for this purpose, with the domain pointing to 127.0.0.1. This was just used to open an HTTP connection to the native Yandex apps, which passed the data up to Yandex over HTTPS. Meta apps were first seen using this trick in September 2024, though it’s very possible it was in use earlier.

Both companies have ceased since this report was released. What’s interesting is that this is a flagrant violation of GDPR and CCPA, and will likely lead to record-setting fines, at least for Facebook.

What’s your Number?

An experiment in which Google sites still worked with JavaScript disabled led to a fun discovery about how to sidestep rate limiting and find any Google user’s phone number. Google has deployed defensive solutions to prevent attackers from abusing endpoints like accounts.google.com/signing/usernamerecovery. That particular endpoint still works without JS, but also still detects more than a few attempts, and throws the captcha at anyone trying to brute-force it.

This is intended to work by JS in your browser performing a minor proof-of-work calculation, and then sends in a bgRequest token. On the no-JavaScript version of the site, that field instead was set to js_disabled. What happens if you simply take the valid token, and stuff it into your request? Profit! This unintended combination bypassed rate-limiting, and means a phone number was trivially discoverable from just a user’s first and last names. It was mitigated in just over a month, and [brutecat] earned a nice $5000 for the effort.

Catching Reflections

There’s a classic Active Directory attack, the reflection attack, where you can trick a server into sending you an authentication, and then deliver that authentication data directly back to the origin server. Back before 2008, this actually worked on AD servers. The crew at RedTeam Pentesting brought this attack back in the form of doing it with Kerberos.

It’s not a trivial attack, and just forcing a remote server to open an SMB connection to a location the attack controls is an impressive vulnerability. The trick is a hostname that includes the target name and a base64 encoded CREDENTIAL_TARGET_INFORMATIONW all inside the attacker’s valid hostname. This confuses the remote, triggering it to act as if it’s authenticating to itself. Forcing a Kerberos authentication instead of NTLM completes the attacker magic, though there’s one more mystery at play.

When the attack starts, the attacker has a low-privileged computer account. When it finishes, the access is at SYSTEM level on the target. It’s unclear exactly why, though the researchers theorize that a mitigation intended to prevent almost exactly this privilege escalation is the cause.

X And the Juicebox

X has rolled out a new end to end encrypted chat solution, XChat. It’s intended to be a significant upgrade from the previous iteration, but not everyone is impressed. Truly end to end encryption is extremely hard to roll out at scale, among other reasons, because users are terrible at managing cryptography keys. The solution generally is for the service provider to store the keys instead. But what is the point of end-to-end encryption when the company holds the keys? While there isn’t a complete solution for this problem, There is a very clever mitigation: Juicebox.

Juicebox lets users set a short PIN, uses that in the generation of the actual encryption key, breaks the key into parts to be held at different servers, and then promise to erase the key if the PIN is guessed incorrectly too many times. This is the solution X is using. Sounds great, right? There are two gotchas in that description. The first is the different servers: That’s only useful if those servers aren’t all run by the same company. And second, the promise to delete the key. That’s not cryptographically guaranteed.

There is some indication that X is running a pair of Hardware Security Modules (HSMs) as part of their Juicebox system, which significantly helps with both of those issues, but there just isn’t enough transparency into the system yet. For the time being, the consensus is that Signal is still the safest platform to use.

Bits and Bytes

We’re a bit light on Bits this week, so you’ll have to get by with the report that Secure Boot attacks are publicly available. It’s a firmware update tool from DT Research, and is signed by Microsoft’s UEFI keys. This tool contains a vulnerability that allows breaking out of it’s intended use, and running arbitrary code. This one has been patched, but there’s a second, similar problem in a Microsoft-signed IGEL kernel image, that allows running an arbitrary rootfs. This isn’t particularly a problem for us regular users, but the constant stream of compromised, signed UEFI boot images doesn’t bode well for the long term success of Secure Boot as a security measure.

From Blog – Hackaday via this RSS feed

Despite the repeated warnings of system administrators, IT personnel, and anyone moderately aware of operational security, there are still quite a few people who will gladly plug a mysterious flash drive into their computers to see what’s on it. Devices which take advantage of this well-known behavioral vulnerability have a long history, the most famous of which is Hak5’s USB Rubber Ducky. That emulates a USB input device to rapidly execute attacker-defined commands on the target computer. The main disadvantage of these keystroke injection attacks, from the attacker’s point of view, is that they’re not particularly subtle. It’s usually fairly obvious when something starts typing thousands of words per minute on your computer, and the victim’s next move is probably a call to IT. This is where [Krzysztof Witek]’s open-source Rubber Ducky clone has an advantage: it uses a signal detected by a SYN480R1 RF receiver to trigger the deployment of its payload. This does require the penetration tester who uses this to be on the site of the attack, but unlike with an always-on or timer-delayed Rubber Ducky, the attacker can trigger the payload when the victim is distracted or away from the computer.This project is based around the ATmega16U2, and runs a firmware based on microdevt, a C framework for embedded development which [Krzysztof] also wrote. The project includes a custom compiler for a reduced form of Hak5’s payload programming language, so at least some of the available DuckyScript programs should be compatible with this. All of the project’s files are available on GitHub.Perhaps due to the simplicity of the underlying concept, we’ve seen a few open source implementations of malicious input devices. One was even built into a USB cable.

From Blog – Hackaday via this RSS feed

Do you like Nintendo games? How about handhelds? Do you prefer the now-venerable Game Boy Advance (GBA) to more modern platforms, but wish your aging eyes could enjoy its content on a large CRT instead of a dinky LCD? If you answered yes to all those questions, you are exactly the type of person [GouldFish on Games] made this custom console for, and you should probably be friends.

The external appearance of this hack is slick: a 3D printed console with the contours of the GBA in that iconic purple, but with a cartridge bay door like an NES and a SNES controller port. It’s the GBA console Nintendo never made, sitting next to a period-appropriate CRT. Playing GBA game on a CRT with an SNES controller is already hacky; what makes it really hacky is the guts are yet another Nintendo system — the DS Lite.

Why a DS Lite? Two reasons: one, it is cheaper to get a busted DS Lite than an old GBA mainboard. Two, as we covered before, the DS Lite can do composite-out with a relatively cheap add-on board. [GouldFish] really is hacking on the shoulders of giants, and they acknowledge it in the video. Aside from the composite-out board, he also makes use of community knowledge on how to make the DS Lite boot without screens or batteries.

Should you be interested in putting your own version of this console together, [GouldFish] was kind enough to share the STLs for the 3D printed enclosure, as well as the Gerber files for the custom PCB that interfaces with the SNES controller port.

We featured a CRT mod for an original Game Boy before, but this seems a lot more practical, if a lot less portable. [GouldFish] has no shortage of old titles and newer homebrew to chose from for this console, but they could always use more. We once featured a primer on how to get into the GBA homebrew scene, if you want to make a game.

Thanks to [Kris] for the tip.

From Blog – Hackaday via this RSS feed

What do you do when you’re a starving student and you need a 400 MHz logic analyzer for your digital circuit investigations? As [nanofix] shows in a recent video, you find one that’s available as an open hardware project and build it yourself.

The project, aptly named LogicAnalyzer was developed by [Dr. Gusman] a few years back, and has actually graced these pages in the past. In the video below, [nanofix] concentrates on the mechanics of actually putting the board together with a focus on soldering. The back of the build is the Raspberry Pi Pico 2 and the TXU0104 level shifters.

If you’d like to follow along at home, all the build instructions and design files are  available on GitHub. For your convenience the Gerber files have been shared at PCBWay

Of course we have heaps of material here at Hackaday covering logic analyzers. If you’re interested in budget options check out $13 Scope And Logic Analyzer Hits 18 Msps or how to build one using a ZX Spectrum! If you’re just getting started with logic analyzers (or if you’re not sure why you should) check out Logic Analyzers: Tapping Into Raspberry Pi Secrets.

From Blog – Hackaday via this RSS feed

[Bhuvanmakes] says that he has the simplest open source photobioreactor. Is it? Since it is the only photobioreactor we are aware of, we’ll assume that it is. According to the post, other designs are either difficult to recreate since they require PC boards, sensors, and significant coding.

This project uses no microcontroller, so it has no coding. It also has no sensors. The device is essentially an acrylic tube with an air pump and some LEDs.

The base is 3D printed and contains very limited electronics. In addition to the normal construction, apparently, the cylinder has to be very clean before you introduce the bioreactant.

Of course, you also need something to bioreact, if that’s even a real word. The biomass of choice in this case was Scenedesmus algae. While photobioreactors are used in commercial settings where you need to grow something that requires light, like algae, this one appears to mostly be for decorative purposes. Sort of an aquarium for algae. Then again, maybe someone has some use for this. If that’s you, let us know what your plans are in the comments.

We’ve seen a lantern repurposed into a bioreactor. It doesn’t really have the photo part, but we’ve seen a homebrew bioreactor for making penicillin.

From Blog – Hackaday via this RSS feed