Poorly designed PCBs and enclosures that slowly cook the electrolytic capacitors within are a common failure scenario in general, but they seem especially prevalent in so-called Internet-of-Things devices. The SwitchBot Plug Mini that [Denki Otaku] took a look at after many reports of them failing is one such example.
The location of the failed electrolytic cap in the SwitchBot Plug Mini. (Credit: Denki Otaku, YouTube)
These Mini Plugs are ‘smart’ plugs that fit into a regular outlet and then allow you to control them remotely, albeit not integrated into a wall or such like the Shelly 2.5 smart relay that also began dying in droves. Yet whereas with the Shelly relays this always seemed to take a few years to show up, generally in the form of WiFi connectivity issues, these SwitchBot plugs sometimes failed within weeks or start constantly switching the relay on and off.

After SwitchBot started an exchange program for these plugs, [Denki Otaku] decided to examine these failed devices from affected users. Inside a dead unit the secondary side’s 680 µF capacitor was clearly bulging and had cooked off its electrolyte as a teardown of a dead capacitor confirmed. After replacing this one capacitor a formerly unresponsive plug sprung back to life.

This failed capacitor is important as it serves as the buffer for the 3.3 V rail, which otherwise sags below the operational range of the microcontroller during power-hungry WiFi operations, causing it to reset. As for the question of why this failure happened, there are two possibilities: one involves the B- or C-tier capacitor – for which no datasheet could be found – being unsuitable for dealing with the ripple current it was exposed to, the other being the high temperatures in that section of the PCB.
Thermal image of the electrolytic capacitor area in the SwitchBot Plug Mini. (Credit: Denki Otaku, YouTube)
As a thermal image of the working PCB shows, the voltage regulator and switching circuitry present on the PCB – right below where the failed capacitor is located – reach a temperature of up to about 50°C, without taking into account the sealed enclosure that the PCB is located in.

The WiFi module that is located next to the capacitor and sticking up vertically from the PCB also reached a similar high temperature, making sure to bake the affected capacitor from below and the side. Even in open air the capacitor reached a temperature of about 43°C.

While a higher-quality capacitor will very likely cope with ripple current better, ultimately it’s pretty much just an unnecessarily stressful environment for electrolytic capacitors. While investigating two newer batches of these Plug Minis that are not subject to recall, the older unit still had the same flawed capacitor, while the new unit had replaced it with what looks like a polymer capacitor with the same ratings.

Interestingly, one of the failed plugs that [Denki Otaku] got sent did use one of these polymer capacitors, but appears to have another fault that wasn’t further investigated. Either way, the use of a polymer capacitor seems to help with the longevity to get it at least past the warranty period, but without a redesign these units seem doomed to fail due to rapid capacitor aging.

youtube.com/embed/YkI5GK734eI?…

hackaday.com/2026/02/07/a-fail…

Keeping a cool head is difficult at the best of times, least of all when it’s summer and merely thinking of touching bare skin to the pavement already gets you a second-degree burn. Unfortunately, it’s not possible to spend all summer in an air-conditioned room, but what if you took said room with you? Introducing [Hyperspace Pirate]’s air-conditioned vest.

Following on from last time’s adventures with a battery-powered air-conditioner that merely blew cold air onto one’s overheating body, this time the same compressor is used for a more compact build.

Since obviously using your body as part of the condenser would be uncomfortable, instead a heat exchanger was used that transfers the delicious frosty cold to water-filled tubing, zip-tied inside a very fashionable vest.

The basic unit runs on a couple of LiPo packs, but a solar-powered circuit was also built and tested using two small-ish panels. Of course, the requisite backpack-sized setup for that configuration is somewhat bulky, but at least the panels can also provide shade in addition to power for the compressor, hitting two fiery birds with one frosty stone.

Compared to one of those solar-powered caps with a built-in fan, this unit with some refinement could actually be an improvement, as well as keeping you a lot chillier. We’re looking forward to [Hyperspace]’s trial runs in the upcoming Floridian summer, as well as future chilling adventures.

youtube.com/embed/qv0IJM3BV9Y?…

hackaday.com/2026/02/07/making…

Although there are a few robots on the market that can make life a bit easier, plenty of them have closed-source software or smartphone apps required for control that may phone home and send any amount of data from the user’s LAN back to some unknown server. Many people will block off Internet access for these types of devices, if they buy them at all, but that can restrict the abilities of the robots in some situations. [Max]’s robot vacuum has this problem, but he was able to keep it offline while retaining its functionality by using an interesting approach.

Home Assistant, a popular open source home automation system, has a few options for voice commands, and can also be set up to transmit voice commands as well. This robotic vacuum can accept voice commands in lieu of commands from its proprietary smartphone app, so to bypass this [Max] set up a system of automations in Home Assistant that would command the robot over voice. His software is called jacadi and is built in Go, which uses text-to-speech to command the vacuum using a USB speaker, keeping it usable while still offline.

Integrating a voice-controlled appliance like this robotic vacuum cleaner allows things like scheduled cleanings and other commands to be sent to the vacuum even when [Max] isn’t home. There are still a few limitations though, largely that communication is only one way to the vacuum and the Home Assistant server can’t know when it’s finished or exactly when to send new commands to the device. But it’s still an excellent way to keep something like this offline without having to rewrite its control software entirely.

hackaday.com/2026/02/07/robots…

Before PCBs, wiring electronic circuits was a major challenge in electronics production. A skilled person could make beautiful wire connections between terminal strips and components with a soldering iron, but it was labor-intensive and expensive. One answer that was very popular was wire wrapping, and [Sawdust & Circuits] shows off an old-fashioned wire wrap gun in the video below.

The idea was to use a spinning tool to tightly wrap solid wire on square pins. A proper wrap was a stable alternative to soldering. It required less skill, no heat, and was easy to unwrap (using a different tool) if you changed your mind. The tech started out as wiring telephone switchboards but quickly spread.

Not all tools were guns or electric. Some used a mechanical handle, and others were like pencils — you simply rotated them by hand. You could specify levels for sockets and terminals to get a certain pin length. A three-level pin could accept three wire wrap connections on a single pin, for example. There were also automated machines that could mass-produce wire-wrapped circuits.

The wire often had thin insulation, and tools usually had a slot made to strip the insulation on the tiny wires. Some guns created a “modified wrap” that left insulation at the top one or two wraps to relieve stress on the wire as it exited the post. If you can find the right tools, wires, and sockets, this is still a viable way to make circuits.

Want to know more about wire wrapping? Ask [Bil Herd].

youtube.com/embed/TzlM8yZR5RI?…

hackaday.com/2026/02/07/hes-a-…

Although often tossed together into a singular ‘retro game’ aesthetic, the first game consoles that focused on 3D graphics like the Nintendo 64 and Sony PlayStation featured very distinct visuals that make these different systems easy to distinguish. Yet whereas the N64 mostly suffered from a small texture buffer, the PS’s weak graphics hardware necessitated compromises that led to the highly defining jittery and wobbly PlayStation graphics.

These weaknesses of the PlayStation and their results are explored by [LorD of Nerds] in a recent video. Make sure to toggle on subtitles if you do not speak German.

It could be argued that the PlayStation didn’t have a 3D graphics chip at all, just a video chip that could blit primitives and sprites to the framebuffer. This forced PS developers to draw 3D graphics without such niceties like a Z-buffer, putting a lot of extra work on the CPU.

This problem extends also to texture mapping, by doing affine texture mapping, as it’s called on the PS. This mapping of textures is rather flawed and leads to the constant shifting of textures as the camera’s perspective is not taken into account. Although this texture mapping can be improved, the developers of the game have to add more polygons for this, which of course reduces performance. This is the main cause of the shifting and wobbling of textures.

Another issue on the PS was a lack of mipmapping support, which means a sequence of the same texture, each with each a different resolution. This allows for high-resolution textures to be used when the camera is close, and low-resolution textures when far away. On the PS this lack of mipmapping led to many texture pixels being rendered to the same point on the display, with camera movement leading to interesting flickering effects.

When it came to rendering to the output format, the Nintendo 64 created smooth gradients between the texture pixels (texels) to make them fit on the output resolution, whereas the PS used the much more primitive nearest neighbor interpolation that made especially edges of objects look like they both shimmered and changed shape and color.

The PS also lacked a dedicated floating point unit to handle graphics calculations, forcing a special Geometry Transformation Engine (GTE) in the CPU to handle transformation calculations, but all in integer calculations instead of with floating point values. This made e.g. fixed camera angles as in Resident Evil games very attractive for developers as movement would inevitably lead to visible artefacts.

Finally, the cartridge-based games of the N64 could load data from the mask ROMs about 100x faster than from the PS’s CDs, and with much lower latency. All of these differences would lead to entirely different games for both game consoles, with the N64 being clearly superior for 3D games, yet the PS being released long before the N64 for a competitive price along with the backing of Sony would make sure that it became a commercial success.

youtube.com/embed/0psAfIFPtVI?…

hackaday.com/2026/02/06/why-pl…

Before the Internet, there was a certain value to knowing how to find out about things. Reference librarians could help you locate specialized data like the Thomas Register, the EE and IC Masters for electronics, or even an encyclopedia or CRC handbook. But if you wanted up-to-date info on any country of the world, you’d often turn to the CIA. The originally classified document was what the CIA knew about every country in the world. Well, at least what they’d admit to knowing, anyway. But now, the Factbook is gone.

The publication started in 1962 as the classified “The National Basic Intelligence Factbook,” it went public in 1971 and became “The World Factbook” in the 1980s. While it is gone, you can rewind it, including a snapshot taken just before it went dark on Archive.org.

Browsing the archives, it looks like the last update was in September of 2025. It would be interesting to see a project like Wikipedia take the dataset, house it, and update it, although you can presume the CIA was better equipped. The data is public domain, after all.

Want to know things about Croatia? Unfortunately, the archive seems to have missed some parts of some pages. However, there are other mirrors, including some that have snapshots of the data in one form or another. Of course, these are not always the absolute latest (the link has data from 2023). But we would guess the main languages (Croatian and Serbian) haven’t changed. You can also find the internet country suffix (.hr) and rankings (for example, in 2020, Croatia ranked 29th in the world for the number of broadband internet subscribers scaled for population and 75th in total broadband usage.

We are sorry to see such a useful reference go, but reference books are definitely an endangered species these days.

hackaday.com/2026/02/06/cias-w…

[Jer Schmidt] needed a way to put a lot of M8 bolts into a piece of square steel tubing, but just drilling and tapping threads into the thin steel wouldn’t be strong enough. So he figured out a way to reliably weld nuts to the inside of the tube, and his technique works even if the tube is long and the inside isn’t accessible.
Two smaller holes on either side. Weld through the holes. A little grinding results in a smooth top surface.
Essentially, one drills a hole for the bolt, plus two smaller holes on either side. Then one welds the nut to the tubing through those small holes, in a sort of plug weld. A little grinding is all it takes to smooth out the surface, and one is left with a strong threaded hole in a thin-walled tube, using little more than hardware store fasteners.

The technique doesn’t require access to the inside of the tube for the welding part, although getting the nut back there in the first place does require a simple helper tool the nut can slot into. [Jer] makes one with some scrap wood and a table saw, just to show it doesn’t need to be anything fancy.

Another way to put a threaded hole into thin material is to use a rivnut, or rivet nut (sometimes also used to put durable threads into 3D prints) but welding a plain old nut to the inside was far more aligned with what [Jer] needed, and doesn’t rely on any specialty parts or tools.

[Jer]’s upcoming project requires a lot of bolts all the way down long tubing, which is what got him into all of this. Watch it in action in the video below, because [Jer] has definitely worked out the kinks, and he steps through a lot of tips and tricks to make the process painless.

Thanks [paulvdh] for the tip!

youtube.com/embed/nC161Ni67-E?…

hackaday.com/2026/02/06/weldin…

Simulator-style video games are designed to scale in complexity, allowing players to engage at anything from a casual level to highly detailed, realistic simulation. Microsoft Flight Simulator, for example, can be played with a keyboard and mouse, a controller, or a huge, expensive simulator designed to replicate a specific airplane in every detail. Driving simulators are similar, and [CNCDan] has been hard at work on his DIY immersive driving sim rig, with this hand brake as his latest addition.

For this build, [CNCDan] is going with a lever-style handbrake which is common in motorsports like drifting and rallying. He has already built a set of custom pedals, so this design borrows heavily from them. That means that the sensor is a load cell, which takes input force from a lever connected to it with a spring mechanism. The signal is sent to an Arduino for processing, which is set up to send data over USB like any joystick or controller. In this case, he’s using an Arduino that was already handling inputs from his custom shifter, so he only needed to use another input and add some code to get his handbrake added into his sim.

[CNCDan] built a version of this out of laser-cut metal parts, but also has a fully 3D printable one available as well. Plenty of his other videos about his driving rig are available as well, from the pedal assembly we mentioned earlier to the force-feedback steering wheel. It’s an impressive set of hardware with a feel that replicates racing about as faithfully as a simulator could. Interestingly, we’ve also seen this process in reverse as well where a real car was used instead as a video game controller.

youtube.com/embed/xzpE0UGo8F0?…

hackaday.com/2026/02/06/drivin…

Fidget toys are everywhere these days. A particularly popular type simply puts some keyboard switches on a plate to provide a certain type of clicky satisfaction. [wjddnjsdnd] took that concept a step further, building a keychain-sized fidget toy that actually has games on it.

The build is based around six key switches in a 2 x 3 array. The key switches are notable in this case for being magnetic shaft keys. Rather than using a mechanical switch to indicate a keypress, the keycap instead merely moves a magnet which triggers a signal in a hall effect sensor beneath the key. In this case, the build uses A3144 hall effect sensors, which are read by the Arduino Nano running the show. The Nano is also hooked up to a small SSD1306 OLED display over I2c, which it uses for displaying the game state. There’s also a TP4056 module to handle charging the attached 380 mAh lithium-ion battery which powers the pocket-sized device.

The Arduino Nano is not a powerful platform for gaming, but it can handle the basics. The Gamebox Clicker, as it’s called, features a Pong clone, a stairs game, and a recreation of Snake. Think early mobile phone games, and you’d be on the money.

It’s an interesting build, and one that would be a great way to get used to using magnetic key switches as well as small embedded displays. We’ve seen Arduino boards turned into microconsoles many times before, too. If you’d like to sound off about magnetic vs. mechanical key switches, jump into the comments, or otherwise let us know about your best electronic fidget projects on the tipsline. Happy hacking.

hackaday.com/2026/02/06/fidget…

This week, Hackaday’s Elliot Williams and Kristina Panos met up over coffee to bring you the latest news, mystery sound results show, and of course, a big bunch of hacks from the previous seven days or so.

We found no news to speak of, except that Kristina has ditched Windows after roughly 38 years. What is she running now? What does she miss about Windows? Tune in to find out.

On What’s That Sound, Kristina thought it was a jackhammer, but [Statistically Unlikely] knew it was ground-tamper thingy, and won a Hackaday Podcast t-shirt! Congratulations!

After that, it’s on to the hacks and such, beginning with 3D printing on the nano scale, and a couple of typewriter-based hacks. Then we take a look at the beauty of the math behind graph theory, especially when it comes to circuit sculptures and neckties.

We also talk display hacking, macro pads with haptic feedback knobs, and writing code in Welsh. Finally, we discuss the Virtual Boy, and ponder whether vibe coding is killing open source.

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!

html5-player.libsyn.com/embed/…

Download in DRM-free MP3 and savor at your leisure.

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Episode 356 Show Notes:

News:

• No news is good news, except that Kristina ditched Windows after ~38 years!

What’s that Sound?

• Congrats to [Statistically Unlikely] who knew this was an Earth-stomping machine!

Interesting Hacks of the Week:

• The Latest From RepRapMicron – Nail Gel, First Objects, And More
• Lego Typewriter Writes Plastic Letters
• Comprehensive Power Management For The Raspberry Pi
• Crouching Typewriter, Hidden PC
• The Graph Theory Of Circuit Sculptures
  
  • The 85 Ways to Tie a Tie
  • The Mathematics of Tie Knots

  
  

• DIY Macropad Rocks A Haptic Feedback Wheel
  
  • Simplifying The SmartKnob

  
  

Quick Hacks:

• Elliot’s Picks:
  
  • 5K IMac Turned Into 5K Display
  • CPU Scheduler Divines The Will Of The Heavens
  • An Event Badge Re-Imagined As A Cyberdeck
  • Ysgrifennu Côd Yn Gymraeg (Writing Code In Welsh)

  
  

• Kristina’s Picks:
  
  • Ordering Pizza On Your Sega Dreamcast Is Very Clunky Indeed
  • Need A Curved Plastic Mesh? Print Flat, Curve Later
  • Running DOOM And Super Mario 64 Inside A PDF File

  
  

Can’t-Miss Articles:

• After 30 Years, Virtual Boy Gets Its Chance To Shine
• How Vibe Coding Is Killing Open Source

hackaday.com/2026/02/06/hackad…

The joy of camera hacking lies for many at the low end of the market. Not working with many-thousand-dollar Leicas, but in cheap snapshot cameras that can be had for next to nothing at a thrift store. [Marek Sokal] has a perfect example, in a 3D printed 35mm camera body using the lens and shutter assembly from a vintage Soviet Lomo Smena 8M.

The build is a work in progress, a printed assembly that holds the 35mm film cartridge, provides the focal plane for the film, and houses the take-up reel. It fits together with M2 screws, as per the Lomo lens.

We like this build, because we can see beyond the Lomo. In a box above the desk where this is being written there is a pile of old plastic snapshot cameras from the 1960s through 1980s, none of which is worth anything much, but all of which have a similar shutter and lens assembly. In many cases it’s not a huge task to do with them what [Marek] has with the Lomo and mount them to a back like this. The LEGO film camera may not have gained approval, but this prove that making cameras of your own is still pretty easy.

hackaday.com/2026/02/06/its-no…

When it comes to seaborne propulsion, one simple layout has largely dominated over all others. You pair some kind of engine with some kind of basic propeller at the back of the ship, and then you throw on a rudder to handle the steering. This lets you push the ship forward, left, and right, and stopping is just a matter of turning the engine off and waiting… or reversing thrust if you’re really eager to slow down.

This basic system works for a grand majority of vessels out on the water. However, there is a more advanced design that offers not only forward propulsion, but also steering, all in the one package. It may look strange, but the Voith Schneider propeller offers some interesting benefits to watercraft looking for an edge in maneuverability.

Spinning Underwater Wings

A modern Voith-Schneider propeller. Credit: Voith AG, Heidenheim
The Voith Schneider propeller design looks rather unlike any propeller you might have seen before. Perhaps the most obvious reason is because of its axis of operation. Traditional propellers tend to operate in an axis parallel with the waterline, or at least within a few degrees or so. However, the Voith Schneider design spins about the vertical axis instead. This is because it uses vertically-oriented blades mounted on a rotating plate. Each blade has a hydrofoil profile, which enables it to generate thrust when moving through the water. By spinning these blades at speed and varying their angle of attack, it’s possible to create a thrust vector in any direction on the horizontal plane. A special gear system is used to vary the angle of each blade as the plate rotates, such that the overall net thrust generated by all the blades is in the desired direction of travel.
The angle of attack of each blade changes as the disc rotates, providing thrust in the desired direction. Controlling the angle of attack of all the blades in this way allows the thrust vector to be pointed in any direction in a full 360 degrees of rotation. It thus provides a great deal of flexibility when controlling a vessel on the water. Credit: Voith AG, Heidenheim
This design has certain key advantages over a traditional maritime propulsion setup. Namely, by fitting a vessel with Voith-Schneider propellers, it’s possible to add a great deal of maneuverability, to the point where a traditional rudder becomes entirely unnecessary. Instead of having to thrust the ship forwards and then turn, it’s possible to directly push the vessel with each individual thruster in the direction that is desired. This can be particularly useful for low-speed operations like docking, and provides a much more instantaneous change of direction than is possible with a regular propeller and rudder setup.

Voith Schneider thrusters are particularly useful for ships like tugs where precision maneuverability is a huge aid to operations. Numerous thrusters are often to a given vessel, providing greater total thrust and additional control. It’s also typical to fit Voith Schneider propellers with a guard underneath, which prevents grounding damage and can act as a sort of nozzle that improves low-speed performance. These propellers are perhaps not the ideal choice for watercraft aiming for outright speed, but for lower-speed work, they can offer great benefits in control.
A pair of Voith Schneider propellers fitted to a tug. Note the protective plate underneath the thrusters which protects against damage. Credit: Voith AG, Heidenheim
The design looks somewhat unintuitive and even futuristic, but it actually goes back a long way. The first prototype was actually designed as a water turbine for generating electricity. However, it proved unexceptional in this role. It was only when the device was tested as a pump that engineers realized it could be repurposed as a combined thruster to replace a traditional propeller and rudder. A patent was issued in Germany in 1972, and the first prototype was tested on the water all the way back in 1928, on a small 60-horsepower vessel known as the Torqueo. The design soon found use on a number of German vessels in the interwar period, including minesweepers. The Voith Schneider design can be operated quite slowly while still providing thrust, minimizing cavitation and thus sound signature, which is considered advantageous for this role. In some German designs, such as the failed Graf Zeppelin aircraft carrier, the thrusters were even installed alongside regular propulsion systems, and made retractable so they wouldn’t present additional drag when not in use. Some decades later, the US Navy itself would later field similarly-equipped minesweepers in the 1990s, though all examples were dismantled and sold off by the early 2000s. Beyond military uses, the thruster has found application in a number of ferries and tugs around the world, and remain in production today.
The US Navy’s Osprey class minehunters used twin Voith Schneider propellers, including the USS Raven pictured here in the North Arabian Gulf. Top speed of the class stands at 12 knots, a hair slower than the Italian Lerici class the type is based on, which uses conventional propulsion and rudders. Credit: public domain, DOD
Despite their unique abilities, Voith Schneider propellers remain a curio rather than a fixture in the shipping world. In the past century of their existence, just 4,500 examples have been built, near exclusively by Voith AG, and thus they are equipping a relatively small amount of the global maritime fleet. They compete with more familiar designs, such as azimuth thrusters, which are widely popular and more intuitive to understand. Given their oddball nature, and moderate level of mechanical complexity, they’re perhaps never going to supplant the tried-and-true prop and rudder that propels most conventional vessels. Still, if you’re looking to build a ship that can elegantly strafe in any direction you want to go, it’s hard to go past the Voith Schneider concept for all the benefits it brings.

hackaday.com/2026/02/06/the-we…

Much like how BusyBox crams many standard Unix commands and a shell into a single executable, so too does BreezyBox provide a similar experience for the ESP32 platform. A demo implementation is also provided, which uses the ESP32-S3 platform as part of the Waveshare 7″ display development board.

Although it invokes the BusyBox name, it’s not meant to be as stand-alone as it uses the standard features provided by the FreeRTOS-based ESP-IDF SDK. In addition to the features provided by ESP-IDF it adds things like a basic virtual terminal, current working directory (CWD) tracking and a gaggle of Unix-style commands, as well as an app installer.

The existing ELF binary loader for the ESP32 is used to run executables either from a local path or a remote one, a local HTTP server is provided and you even get ANSI color support. Some BreezyBox apps can be found here, with them often running on a POSIX-compatible system as well. This includes the xcc700 self-hosted C compiler.

You can get the MIT-licensed code either from the above GitHub project link or install it from the Espressif Component Registry if that’s more your thing.

youtube.com/embed/wlDsaQgWCaI?…

hackaday.com/2026/02/06/breezy…

When you think of a toy tractor, what probably comes to mind is something with fairly simple lines, maybe the iconic yellow and green, big rear tires, small front ones. Well, that’s exactly what [James] built, with simple, clean lines and a sturdy build that will hold up to driving around off-road in the garden. This Tractor is a great build, combining CAD, metal and wood work, some 3D printing, and electronics.

Starting at the power plant for the build, [James] went with a 350W DC motor powered by a 36V Li-ion battery from an e-bike. The motor turns a solid rear axle he made on a mini-lathe, connected to a set of riding lawn mower wheels. The mini-lathe spindle bore was too small to accommodate the shaft, and the lathe was not long enough to use the tailstock, so [James] had to get creative, using a vice and a piece of wood to make a stand–in tailstock, allowing him to turn this custom rear axle. The signature smoothly curved bonnet was made possible with plywood and body filler, rather than the sheet metal found on full-sized tractors. In fact, most of the build’s frame used plywood, giving it plenty of strength and, once painted, helping give it the appearance of a toy pulled out of a toybox.

This build had a bit of many domains in it, and all combined into a fantastic final result that no doubt will bring a smile to any face that gets to take the Tractor for a ride. Thanks [James] for documenting your build process, the hacks needed to pull off the tough bits along the way in making this fun toy. If you found this fun, be sure to check out another tractor related project.

hackaday.com/2026/02/05/toybox…