Ondol: Korean Underfloor Heating

One of the many aspects of the modern world we often take for granted is the very technology that keeps our accommodation at a habitable temperature. Examples of this include centralized heating systems using hot-water circulation, or blown air ducted to multiple rooms from a central furnace. Certainly in Europe, once the Romans shipped out, and before the industrial revolution, we were pretty cold unless someone lit a fire in the room. Every room. But not in Korea. The Ondol heating principles have been used constantly from about 5000 BC to only a few decades ago, keeping your average Korean countryman nice and toasty.

Having said that, the sophistication has improved a bit. Initially, the idea was to simply heat up a bunch of rocks in the fire, and bring them indoors, but Ondol quickly became part of the building itself. As will be seen from the video embedded below, the house sits on top of an elaborate double stack of serpentine channels, that circulate the hot combustion products from the furnace as thoroughly as possible, slowing down the gases and allowing their heat to transfer into the structure of the floor, and then radiate into the space above. It does bear more than a passing resemblance to the Roman hypocaust system, ruined examples of which can be found all over the UK and Europe. The skill demonstrated in the video is considerable, but must surely be an expensive build reserved for the most culturally aware Koreans who wish to live in simpler (and less hectic) locations in their country.

Maybe for the vast majority of us, this kind of thing is not viable, and we’re more likely to benefit from a more centralized approach, perhaps using waste heat from data centers or geothermal activity. (See: Iceland)

Continue reading “Ondol: Korean Underfloor Heating”

Who Needs Gasoline When You’ve Got Sodium?

YouTuber and serial debunker [Thunderf00t] was thinking about the use of sodium to counteract global warming. The theory is that sodium can be used as a fuel when combusted with air, producing a cloud of sodium hydroxide which apparently can have a cooling effect if enough of it is kicking around the upper atmosphere. The idea is to either use sodium directly as a fuel, or as a fuel additive, to increase the aerosol content of vehicle emissions and maybe reduce their impact a little.

One slight complication to using sodium as a fuel is that it’s solid at room temperature, so it would need to be either delivered as pellets or in liquid form. That’s not a major hurdle as the melting point is a smidge below 100 degrees Celsius and well within the operating region of an internal combustion engine, but you can imagine the impact of metal solidifying in your fuel system. Luckily, just like with solder eutectic mixes, sodium-potassium alloy happens to remain in liquid form at handleable temperatures and only has a slight tendency to spontaneously ignite. So that’s good.

Initial experiments using ultrasonic evaporators proved somewhat unsuccessful due to the alloy’s electrical conductivity and tendency to set everything on fire. The next attempt was using a standard automotive fuel injector from the petrol version of the Ford Fiesta. Using a suitable container, a three-way valve to allow the introduction of fuels, and an inert argon feed (preventing spontaneous combustion in the air), delivering the liquid metal fuel into the fuel injector seems straightforward enough.

[Thunderf00t] started with ethanol, then worked up to pentane before finally attempting to use the feisty sodium-potassium, once the bugs had been shaken out of the high-speed video setup. [Thunderf00t] does stress the importance of materials selection when handling this potential liquid metal fuel, since it apparently just bursts into flames in a violent manner on contact with incompatible materials. Heck, this stuff even reacts with PTFE, which is generally considered a very resistant material. We’re totally convinced we’d not like to see this stuff being pumped from a roadside gas station, at all, but it sure is a fun concept to think about.

Sodium-Potassium alloy doesn’t feature on these pages too often, but here’s a little fountain of the stuff, just because why not?

Continue reading “Who Needs Gasoline When You’ve Got Sodium?”

Supercon 2022: Irak Mayer Builds Self-Sustainable Outdoor IoT Devices

[Irak Mayer] has been exploring IoT applications for use with remote monitoring of irrigation control systems. As you would expect, the biggest challenges for moving data from the middle of a field to the home or office are with connectivity and power. Obviously, the further away from urbanization you get, the sparser both these aspects become, and the greater the challenge.

[Irak] solves his connectivity problem by assuming there is some WiFi network within range, building a system around the Blues Wireless WiFi note card. Substituting their cellular card would be an option for applications out of WiFi range, but presumably without changing too much on the system and software side of things. Leveraging the Adafruit FeatherWing INA219, which is a bidirectional current sensor with an I2C interface, for both the power generation and system consumption measurements. For control, [Irak] is using an Adafruit ESP32 board, but says little more about the hardware. On the software side, [Irak] is using the Blues Wireless NoteHub for the initial connection, which then routes the collected data onto the Adafruit IoT platform for collation purposes. The final part of the hardware is a LiPo battery which is on standby to soak up any excess power available from the energy harvesting. This is monitored by an LC709203f battery fuel gauge.

Continue reading “Supercon 2022: Irak Mayer Builds Self-Sustainable Outdoor IoT Devices”

SUPERCON 2022: Kuba Tyszko Cracks Encrypted Software

[Kuba Tyszko] like many of us, has been hacking things from a young age. An early attempt at hacking around with grandpa’s tractor might have been swiftly quashed by his father, but likely this was not the last such incident. With a more recent interest in cracking encrypted applications, [Kuba] gives us some insights into some of the tools at your disposal for reading out the encrypted secrets of applications that have something worth hiding.  (Slides here, PDF.)

There may be all sorts of reasons for such applications to have an encrypted portion, and that’s not really the focus. One such application that [Kuba] describes was a pre-trained machine-learning model written in the R scripting language. If you’re not familiar with R, it is commonly used for ‘data science’ type tasks and has a big fan base. It’s worth checking out. Anyway, the application binary took two command line arguments, one was the encrypted blob of the model, and the second was the path to the test data set for model verification.

The first thing [Kuba] suggests is to disable network access, just in case the application wants to ‘dial home.’ We don’t want that. The application was intended for Linux, so the first port of call was to see what libraries it was linked against using the ldd command. This indicated that it was linked against OpenSSL, so that was a likely candidate for encryption support. Next up, running objdump gave some clues as to the various components of the binary. It was determined that it was doing something with 256-bit AES encryption. Now after applying a little experience (or educated guesswork, if you prefer), the likely scenario is that the binary yanks the private key from somewhere within itself reads the encrypted blob file, and passes this over to libssl. Then the plaintext R script is passed off to the R runtime, the model executes against the test data, and results are collated.

[Kuba]’s first attack method was to grab the OpenSSL source code and drop in some strategic printf() function calls into the target functions. Next, using the LD_PRELOAD ‘trick’ the standard system OpenSSL library was substituted with the ‘fake’ version with the trojan printfs. The result of this was the decryption function gleefully sending the plaintext R script direct to the terminal. No need to even locate the private key!

Continue reading “SUPERCON 2022: Kuba Tyszko Cracks Encrypted Software”

A Low Budget DIY Vibrotactile Stimulator For Experimental CRS

Modern techniques of Coordinated Reset Stimulation (CRS), which is usually administered with invasive deep brain stimulation, can have a miraculous effect on those suffering from Parkinson’s disease. However, the CRS technique can also apparently be administered via so-called vibrotactile CRS (vCRS) which essentially means vibrating certain nerve endings corresponding to brain regions that have a large cortical representation.

An example is vibrating the tips of the fingers using special gloves. This is a medical technique and as such is governed by the FDA. With ongoing trials, patients all around the world will simply have to wait. [HackyDev] has been working with a group of people on developing an open source vCRS glove.

This neuromodulation technique seems so promising, that this upfront effort by hackers around the world is simply a joy to see. Patents be dammed; we can work around them. Interested parties can follow the (very long, tricky-to-follow) thread here.

The hardware [HackyDev] put together uses a nodeMCU as the controller, driving eight motor coils via MOSFETS. The finger-mounted actuators are constructed by ripping the electromagnet out of a relay and mounting it in a 3D printed frame, with a magnet suspended on a spring. This part is mounted on each finger. The nodeMCU presents a simple web form that enables the configuration of the pulse parameters.

A permanent magnet is housed in the spring’s top section

The way the gloves appear to work is due to the way the body perceives sensory input, with a massive bias towards the hands and mouth region, referred to as the cortical homunculus. Each finger has an individual haptic element, which is actuated in a specific sequence with a carefully formed pulse at approx. 250 Hz.

This appears to activate similar in-brain effects as traditional (and invasive) DBS therapy by effectively de-synchronizing certain over-synchronized brain pathways and alleviating the overactive ß-wave activity in the brain. And this calms the tremors as well as many other PD symptoms. It’s all very exciting stuff, and we’ll be following this story closely.

For more on the backstory check out the 2017 paper by Peter A. Tass, as well as this later one, and this one. We’ve seen some recent success with diagnosing or at least detecting PD, by smell as well as via audio, so the future might look a little brighter for quite a number of people.

Like Chording But Not

Repetitive strain injuries (RSI) can be a real pain. You’ve got a shiny new laptop, and everything’s going smoothly, but suddenly you can’t use it without agonizing (as in typing-speed reducing) pain caused by years of keyboard bashing or just plain bad posture. All of us hacker types will likely have or will experience this at some point, and luckily there are many potential solutions.

[Zihao Wang] writes to show us kseqi, another chord-like textual input method, with a focus on the input sequences, as opposed to any particular mechanical arrangement of keys. The idea is to make use of two sets of independent inputs, where the sequence of actuation codes for the keystrokes to be emitted into the application.

Left-hand-first to select a column of the left character set. Right-hand-first selects the other set.

An example interface would be to arrange two sets of five keys as the input mechanism. One can arrange characters in a matrix. The left key is pressed and held first which selects a column (1 out of 5) then the right key is pressed to select a row, and thus a character. Next, you release in the same order, left, then right, to send the character.

Swapping left and right allows a different set of characters. In this simple scheme, fifty characters can be coded. Check out this web assembly demo for how this operates. Swapping out the physical inputs for a pair of joysticks is another option, which may be better for some folks with specific physical difficulties, or maybe because it just looks fun. As [Zihao] mentions in the write-up, the sequence order can be changed to code for other character sets, so this simple scheme can handle many more character codings than this simple example. All you have to do is remember them. Interested parties may want also wish to dig into the kseqi Rust crate for information.

Chorded keyboard projects are plentiful out there, here’s a nice Bluetooth-connected keeb, and another one that’s all wiggly.

Continue reading “Like Chording But Not”

Ploopy Builds Open Source RP2040-Powered Headphones And You Can Too!

We’ve seen many DIY headphones projects on these fair pages over the years, but not many that are quite as DIY as the Ploopy Headphones. What makes this project interesting is the sheer depth of the construction, with every single part being made from what we might call base materials. Materials such as 3D printer filament, foam and felt, and the usual metallic vitamins.

The electronics are fairly straightforward, with an RP2040 functioning as the USB audio interface and equalizer function. Audio samples are emitted as I2S into a PCM3050 24-bit stereo codec which generates a pair of differential output audio signals. These are then converted from differential to single-ended signals and passed on to the coil drivers. The coil drivers consist of no fewer than eight-paralleled opamps per channel. All of this is powered by the USB-C connection to the host computer. Whilst a kit of parts is available for this, you can make your own if you wish, as the full source (Altium designer needed for tweaks) is available on the Ploopy headphone GitHub.

A pretty ploopy response

Many DIY headphone builds would likely be using off-the-shelf speaker units, with large parts of the ear cups being taken from spare parts kits for commercial offerings. But not the Ploopy. The drivers are constructed from flex PCB coils with a standard TRRS jack on each side. Magnets for these coils to react against are held in a 3D-printed frame that is attached to the outer cover. The coils are aligned with a special jig and bonded to the ‘driver foam’ with some 3M VHB tape.

The ear cups are constructed with some 3D printed rings, foam pieces, and simple woven material. The resonator plates push into the inner side of the cup, and the assembly simply screws to the driver assembly. The incredibly detailed assembly wiki makes it look easy, but we reckon there are a few tricky steps in there to trip the unwary. The headband again consists of printed spring sections, some woven material, and foam with a few metallic vitamins thrown in. That makes it sounds simple, but it isn’t.

On the whole the build looks fantastic, but what does it sound like? The Ploopy team has tested them against a pair of Sennheiser HDRXX giving a broadly comparable response, but we’re no audio experts, and the proof, as always, is in the wearing. This project seems to be the ultimate in audio tweakability, with the punchy RP2040 capable of running six audio filters at the full 48 KHz, 16-bit audio, though, the PCM3050 is capable of more.

Want to build some headphones, but need a Bluetooth interface? We got you covered. Can 3D printed headphones ever compare to the big names? We’ll see.