Mysterious Files PH

A fun trick with a pole is to try to balance it so that it can stand on one end. This can be done in a few ways, such as by exerting a force on either end to counterbalance any force that threatens to make it fall over. The approach that [Peter Ryseck] chose was to cobble together what is effectively a flying drone for on top of a standing pole, without cheating such as by simply lifting it off the ground.

Getting to the point where the drone could react quickly enough to changes in the pole’s orientation was the hardest part, as the quieter, larger propellers also have a lot more inertia. This ruled out using 10″ blades, while triple 5″ blades seemed to work well enough. For the avionics a standard quadcopter control board and software is used, with the programming such that it’ll react appropriately without causing additional instabilities.

Naturally making this work took some trial and error, with issues like oscillations plaguing the system. One unexpected problem was that the pole – taken from a pool fishing net – was flexible enough to add its own instabilities to the system. In the video all these issues and their solutions are explained in detail, along with the ultimate result. One very neat solution here for example is to have the pole lean into the wind, which is a more stable configuration than insisting on having the pole be at a perfect ninety degrees with the ground.

Delidding a CPU involves removing the integrated heat spreader (IHS) that’s put over the bare die and the substrate that it is mounted on. The reason for this is usually to improve cooling performance, as the IHS is effectively a small heatsink between the die and the large heatsink, adding more problematic thermal interfaces. If delidding is done improperly it can cause severe damage to the substrate, as in the case of a very nice 1.3 GHz Tualatin Pentium III CPU that [Bits und Bolts] got in an eBay lot with nasty delidding damage.

With the delidding enthusiast presumably having used brute force and ignorance combined with a prying implement, around a dozen of tiny traces on the substrate got severed, requiring tedious trace repair to fix. After confirming that with the severed traces the CPU is indeed busted, enough of the soldermask is removed to make a repair.

Any traces that were still good got covered with soldermask, while for the remainders the thinnest available copper wire was used to create new traces. Although very much doable with a good microscope and a steady hand, this is definitely one of those things that’s much easier to prevent than to fix.

With IHSes having become standard on CPUs, delidding continues to this day, with increasing risks of severed traces and ripped-off capacitors should it go wrong. Although those newer CPU substrates are probably not repairable, repairing these older CPUs instead of tossing them as e-waste seems plausible at least.

As the calendar turns a leaf into September, Elliot Williams is joined by Jenny List for our weekly look at all things Hackaday.

In the news, our retrocomputing competition is well under way, but there’s plenty of time to get an entry in if you’ve got a cool old-style project to show us. And then Elliot’s been chasing seismic surveyors in Munich, where they’re looking for geothermal energy.

In the stand-out hacks there’s a discussion of smoothing 3D prints using frickin’ lasers, the effect of unreasonably high RAM and storage prices on the single board computer ecosystem, and an unfortunate air conditioning system that’s tricked into believing it’s a hot day. Finally, we look in depth at PETG, and take a dive into reverse Polish notation.

Download your own personal version of the podcast right here.

Episode 384 Show Notes:

Mailbag:

In out mailbag this week we had [Kevin Opalka] asking about roadtrip hacks and [Matthew Rowberry] explaining that most versatile yet underrated prototyping medium: the humble Lego brick. Which in turn gives us the chance to mention Lego House: Right Next To Denmark’s Legoland, But Way Cooler, a trip we made back in 2019.

Got something to say? Send an e-mail or an audio clip to mailbag@hackaday.com.

News:

• Announcing The 2026 Hackaday Retrocomputing Challenge
• Seismic investigation for Munich’s geothermal project.

Interesting Hacks of the Week:

• Laser Your Way To Smoother FDM 3D Prints
  • Has FDM 3D Printing Hit Its Peak?
• Has the time of esoteric operating systems arrived?
  • Haiku OS Releases Beta 6
  • ReactOS Gets An Upgrade
  • Amiga-Inspired AROS Goes Bare Metal On Raspberry Pi
• Tricking An Air Conditioner Into Cooling
• Wikipedia On A Cheap Yellow Display
• HDMI For The Color Computer 2
• RAM And EMMC Prices Are So High, Pine64 Has Stopped Linux Device Production

Quick Hacks:

• Elliot’s Picks:
  • Doubling Thermal Printer Resolution By Wiggling
  • A Defrag Simulator In Your Browser
  • Reactive Heat And Wind Come To VR, Thanks To Smart Plugs
  • Get Your Monitor Transmitting VHF With A Browser Tool
• Jenny’s Picks:
  • Digital “Film” For Your Pi Camera
  • Giving The NES An Optical Data Storage Add-On
  • How A 1981 RAM Expansion Worked

Can’t-Miss Articles:

• PETG: The PLA Filament Alternative That Just Works
• “I’m Not Dead Yet!” Reverse Polish Notation Calculators You Can Still Buy
  • Teardown With A Twist: 1975 Sinclair Scientific Calculator
  • Reverse Polish Notation And Its Mildly Confusing Elegance

Passive evaporative cooling has been used for centuries to reduce temperatures. Heat is drawn off as water evaporates, which in turn reduces temperature. The more efficiently this process happens the greater the temperature differential, and that’s exactly what the 3D-printed structure pictured above aims for. Created at the Graz University of Technology in Austria, the cubes noticeably reduce surrounding air temperature thanks to their careful construction. As long as they’re kept wet, anyway.

The key is exposing the maximum amount of water to the maximum amount of airflow, and there are two ways the prototype cooling wall — which is 3D printed from a special clay mixture — does this.

First, the macro design of the 3D-printed blocks maximizes surface area. If the cube in the image above looks familiar, that’s because it’s the gyroid infill pattern. Gyroid is a porous pattern with no “dead ends” or closed sections, and the fact that it 3D prints cleanly with no supports also makes it an ideal structural candidate.

The second advantage is the clay used for the blocks themselves. Firing clay at a low temperature keeps it porous, but this particular mixture goes even further. It’s a bio-inspired formulation of clay, fungal mycelium, and wood chips. After printing, the cubes are fired and the fungus and wood chips burn away, leaving a network of thread-like capillaries with occasional larger pockets throughout.

The result is a porous ceramic cube with a massive evaporative surface area relative to its size. A practical test in a hot attic showed the air near a water-laden cube was nearly 7º C lower, a noticeable difference.

A home experimenter might not have access to fancy mycelium-laced clay mixtures, but it still strikes us as something that could be tried out at home. After all, clever hackers have successfully made DIY versions of passive cooling paint.

A surprising number of things we use in everyday life retain most of their design cues from their 19th century ancestors. The bicycle retains the same basic design as it had in 1890, as does the sewing machine, the toilet, the car, and of course, the keyboard and the QWERTY layout from old typewriters. But we aren’t doomed to have our technology perpetually living in the past. [Paul] wanted a keyboard designed around human hands, rather than being designed around a machine, so he built this unique split keyboard.

The design of this specific keyboard went through around 50 iterations before he was comfortable with it. Other design goals here were for it to be portable, and the split nature of this certainly makes it more compact as does the use of low-profile switches. Each finger’s column is angled and spaced based on the needs of that finger, with the ring finger keys sitting higher and the index finger columns angled inward. Each thumb has access to three keys, one of which is the spacebar and the other two layer keys, which is what enables this design to get down to only 36 total keys.

When thinking about it for any length of time, the modern keyboard’s design holdovers from the 1800s are fairly wasteful compared to this split, ergonomic version. Especially when looking at the spacebar, which ties up both thumbs and only performs a single task, there’s a lot of opportunity for modern designs to be more efficient, more portable, and easier on one’s body. Feel free to take this to the extreme and use all three dimensions, as long as you aren’t particularly concerned with portability.

The idea of painting a roof or wall white in order to reflect sunshine and keep the building’s insides cool is hardly a new one, and even in the loosest interpretation of the word ‘white’ it generally works pretty well. This is also what [NightHawkInLight] found after using an off-the-shelf silicone-based coating for his shed’s tin roof, though with a few caveats.

One might say that this is mostly a problem for people who live in non-desert climates — like Michigan in this case — yet it’s undeniable that having a cooler indoors in a high-humidity climate will inevitably lead to a higher indoor humidity level. This was the first issue that was encountered, though it mostly meant that instead of running an air conditioner eight hours a day, a weekly dehumidifier session was required, which was at least less expensive in terms of kWh.

While the current silicone-based paint on the roof stays above ambient, in a subsequent test both [NightHawkInLight]’s DIY sub-ambient cooling paint and a commercial option get a sample panel down to around ambient temperature, which could cool down the roof even more. Of course, in this case the humidity issues would get worse, with likely condensation forming that would have to be dealt with.

Overall, a cooling paint on the roof is a pretty thing even if you’re not living in the desert, but you have to be able to tame the resulting humidity and condensation issues.

Oftentimes, when we’re using a microcontroller, we’re whipping up some very specific code focused on executing a particular task. The device is set up to execute code that does exactly what we want with minimal overhead. However, sometimes, there are scenarios where it pays to go with a somewhat heavier setup, wherein the microcontroller runs an operating system for the benefits that offers.

Federico Terraneo came to Hackaday Europe to discuss this very topic. He talks about kernel architecture, real-time operating systems, and how to best use C++ in the world of microcontrollers.

Microcontrolling

The talk begins in a helpful place. Federico starts by explaining what an operating system actually is. Basically, it’s the software that exists between the hardware and the applications that run upon it. Breaking it down into parts, an operating system typically consists of a main kernel, atop which sits things like the basic system services, libraries, and device drivers, along with utility programs necessary to maintain and work with the system. The user interface sits on top of all that, which allows the user to select and run applications and generally use the operating system to get things done.

Of course, different operating systems differ in the specifics of their architectures. Monolithic kernels, such as Linux relies on, keep a split between kernelspace and userspace. This is where where the kernel has full hardware access running on the CPU in system mode, while the applications run in user mode without such direct access. Monolithic kernels typically only run on architectures with memory management units (MMU)—think full-scale computers with proper CPUs, like your laptop or desktop. Unikernel operating systems, like FreeRTOS, are a little different, where applications and the operating system are collapsed down into a single executable binary that runs with raw hardware access. There is no abstraction, no memory protection, or anything like that, which makes the architecture easier to run on typical microcontrollers. There are also microkernels, which aim to minimize the amount of code that runs in system mode, pushing things like drivers and filesystem access into userspace. This architecture still needs an MMU, and is mostly only seen in niche uses where high security and/or attention to safety is critical.

When it comes to microcontrollers, unikernels are the most relevant architecture to think about. However, they have limitations–in stability, in security, in the fact that there is no run-time code loading or any way to easily partially upgrade the system. The fluid kernel, which Federico came to explain, aims to solve some of these issues. It hopes to offer a scalable operating system solution that works across the world of embedded computing, where sometimes microcontroller resources are limited and where memory management units seldom exist. It’s also intended to be compatible with standard APIs—think POSIX, C++ standard libraries, and all that. Federico calls it the “UNIX on a chip” concept.

The fluid kernel aims to exist at the intersection of the monolithic kernel and the unikernel. It allows hosting applications in kernelspace or in userspace as needed. A fluid kernel is also built to be POSIX compliant twice—with the same API whether you’re operating in kernelspace or userspace. The fluid kernel concept is designed around achieving process abstraction via the hardware Memory Protection Unit (MPU) common in modern 32-bit microcontrollers. It’s not quite an MMU, and can’t do all the same fancy virtual memory tricks, but it’s enough to provide a basic level of memory protection on a microcontroller platform. The fluid kernel can also become a unikernel if so desired as a compile-time option, which takes away process support while reducing code size significantly. It allows for unikernel devleopment that can be upgraded into a fluid kernel later by flipping the compile-time option the other way.

Federico does a great job of explaining the pros and cons of the fluid kernel architecture, and explores the security implications inherent in going this route. The Miosix RTOS is discussed as the practical implementation of this philosophy, and there’s even a helpful diversion into the efficient use of C++ on microcontrollers. If you’re getting serious about embedded development, or you just want to learn about a new architecture you might find useful one day, it’s a great talk to dive into on your next lunch break.