Mysterious Files PH

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.

Making a radio is so often a case of taking tried and tested designs and working with them to create something new. It’s a safe way to make something that works. [Riyas] however has gone for an entirely different tack, creating an entirely modern transceiver with as much as possible going on in the silicon.

At its heart are three integrated circuits, the familiar Si5351 as a transmit VFO, an Si4372 receiver, and an RP2040 tying it all together. This microcontroller functions both as controller, and as an ADC to provide a software defined radio via its USB port. The Si4372 having an internal SDR architecture and its output being digitized again is not lost on us.

It’s for digital modes and CW only, but we’d venture the opinion that those are where the interesting stuff is anyway. We certainly like it for its simplicity, and also for the one-cable solution it offers. So many other designs need a sound card and extra cables, this one makes for a lot less clutter. We hope we’ll see more development on this design over time, it could become a favorite in the homebrew rig stakes.

Meanwhile the Si5351 is notoriously annoying to program. A while back we covered a library that might help, if you get stuck.

Thermal printers are still extremely common today, using small heating elements in combination with temperature-sensitive paper to create a dot matrix-like effect without messing with ink ribbons and complex mechanisms. Of course, even with just a line of elements you still needed one of these per pixel, which at least in the 1970s when the Sears 12 calculator was released added significantly to the cost. The solution here was to wiggle the elements, doubling the resolution of the print head, as detailed in this video by [Danalog].

Using a contemporary Texas Instruments TI-5015 calculator as comparison with its non-wiggling print head, it’s easy to see the advantages here. In an era where electronic calculators didn’t have displays but a thermal printer, this print quality was the selling point, yet adding more thermal elements added to the price tag of the final device and more complexity to the design in terms of driving circuitry.

In this regard adding a way to make the print head move side-to-side at a set rate and tying this fact into the printing would save about half of that circuitry. Inside the Sears 12 is a fairly standard Mitsubishi M58671 calculator IC, but also the whole printer mechanism. When operating, as demonstrated in the video with the cover removed, you can see the whole print head moving rapidly.

With this mechanism this much cheaper Sears 12 definitely gives the TI-5015 a run for its money, even if as noted by [Danalog] the timing would go off a bit after a longer session, resulting slightly wavy printing. Presumably with the massive cost savings of buying a Sears calculator over a TI one, this was deemed an acceptable trade-off.

As fun as mucking about with simulated environments in a laboratory is, at some point you have to do those field tests to demonstrate that your prototype actually works in the real world, under real conditions. This is what the [Plasma Channel] recently did for their fog harvesting system by setting it up in the Namib desert.

We previously covered the atmospheric water harvesting attempts, using electrostatic precipitation to draw the moisture in the air onto the collectors where it can then be harvested. This is rather different from existing approaches with e.g. fine meshes and hoping that enough water molecules bump into your mesh, so theoretically it should be much more efficient. In the lab it worked well, but reality always has the last word.

The Namib desert is at the top of the world’s most arid regions, competing with the Atacama desert. What it does have going for it is regular fog rolling in that lasts until sunrise, providing a good target for water harvesting. Interestingly, this field test was performed together with the University of Namibia.

Of course, moving the prototype in check-in luggage for the flight to Namibia took some redesigning and testing. Fortunately everything, including the solar panel, arrived intact, allowing trials to commence. This initially took place at the campus of the University of Namibia, joining a number of other atmospheric water harvesting projects that had been previously installed there.

Unfortunately the fog proved to be rather elusive, leading to a few fruitless attempts. It also proved that the salt in the air from the ocean spray, even a few kilometers inland, was highly corrosive, especially to high-voltage electronics. Although the system basically worked, happily harvesting water under the right conditions, it does need some redesign before it’ll be tested next in the Atacama desert.

This week Jonathan chats with Benjamin Samuels of Trail of Bits! The conversation focuses on Patch the Planet, a new initiative to help Open Source projects deal with the fallout from AI coding and vulnerability research. What’s the unexpected dichotomy driving the polarized response to LLMs? And what does the future look like for Open Source in the age of AI? Watch to find out!

• https://trailofbits.com/patch-the-planet/
• https://blog.trailofbits.com/2026/07/02/field-reports-from-patch-the-planet/

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License