Speak Silently With An Ultrasound Probe

Speaking is much faster than typing, and while it’s an increasingly convenient way to interact with computers, it’s hardly private. Providing speech privacy in a way we haven’t seen before is this prototype tongue-reading system that uses machine learning and ultrasound to read tongue movements and turn them into decoded speech. Not only can a user speak without emitting a sound, since it doesn’t read sound waves it’s completely immune to noisy environments.

Tongues are a far richer source of speech data than reading lip and mouth movements.

It turns out that tongue movements are a very rich source of information about speech, and an ultrasound probe under the chin takes very clear video of a tongue. With a dataset consisting of only around 50 hours of training data, the system has a 15.6% error rate and generalizes across different speakers (as long as they speak with similar accents).

That error rate may seem high at first glance, but keep in mind this is for a prototype system built in a month around a relatively small training dataset. All indications are that better results are just a matter of better training.

Probably the biggest drawback at the moment is the size of the ultrasound probe and the way it must be held under one’s chin like a contact microphone, but at the moment the probe is an off-the-shelf model that is hardly optimized for either size, weight, or wearability. If the system seems promising enough, a probe resembling an adhesive patch might even be possible.

It’s certainly a different approach from others we’ve seen in the past, including whispering while inhaling and reading lip and mouth movements.

A series of simulations of a shape are shown, with that shape traced out in a petri dish with a laser below. The shape is roughly like a 90-degree corner bisected by a third arm.

Printing Fungal Art With Laser Control

Preservationists usually take great care to prevent fungi from appearing the world of art, but in the case of [Kexin Wang]’s Funguy project, the fungus itself is the art. It uses a laser diode to repeatedly trace an outline onto a dish of agar gel in which fungus is growing, and the photophobic fungus grows only up to the edge of the laser-traced figure, potentially creating complex designs.

This project evolved out of a research project in which they developed a computer model for fungal growth, then used its predictions and a laser to control a fungus’s growth pattern. The model has two parts: a temporal convolutional neural network which learns fungi growth patterns from a series of images, and a cellular automaton to simulate these growth patterns under different starting conditions. The cellular automaton’s rules aren’t fixed; each cell runs a small neural network which learns the rules under supervision from the convolutional network. By training these networks on images of the growth stages of three different fungi, it was able to realistically predict the different growth patterns of the different species.

To actually control the growth pattern, the researchers tried a series of different wavelengths and laser powers; shorter wavelengths tended to work better, with a 405 nm laser working best. The growth model complemented the laser setup by predicting in which areas the growth medium had run out of nutrients. Since fungus would no longer spread in these regions, the laser no longer needed to trace these sections. The Funguy kit’s laser system itself is similar to a laser engraver, with an XY-kinematic system seemingly built from a DVD drive frame. It uses fungi from the Mucor genus, though it can print with other photophobic microorganisms, such as slime molds.

This project seems aimed at artistic and educational uses, but considering the various electronic parts that have been made of fungi, more functional applications should be possible.

Software-Defined Vehicles Loom Closer Every Year

Vehicles long ago began to incorporate electronics and software, to the point that modern vehicles increasingly have a sort of architecture problem. The software end of things evolves ever more rapidly, but vehicles and their centralized architecture are poorly-suited to continuous updates. As a result, the automotive industry is moving away from static, hardware-defined designs and more toward dynamic, software-defined platforms. In short, the era of software-defined vehicles looms nearer every year.

Continue reading “Software-Defined Vehicles Loom Closer Every Year”

Porting DOOM To The Casio Loopy

Targeted towards refined female gamers unlike the savagery of the mainstream game consoles of the era, 1995’s Casio Loopy was a bit of an oddity of a game console. Despite being standard enough in its design and backed by the might of Casio, it saw only one year of active software development and hardware manufacturing ceased by the end of 1998. With only eleven titles released for the system, with none of them being Doom, this obviously terribly upset [Throaty Mumbo], who set out to right this egregious wrong.

For the two dozen people or so who have one of these systems, you can experience the fruits of his labor yourself via the GitHub repository and something like the FloopyDrive cartridge.. Despite the quite capable Hitachi SH-1 16 MHz CPU and 1 MB of RAM, the main limitation is probably the original 2 MB of ROM space that does not leave a lot of space for DOOM WADs, even after doubling it on the FloopyDrive. Correspondingly you only get a handful of levels out of it.

Overall game performance isn’t too bad, though in the port’s current unoptimized state the resolution is fairly low. That said, even the console’s built-in printer is supported and demonstrated in the video, which is a pretty nice touch. It’s not like Sega or Nintendo consoles allowed you to screenshot those glorious headshots.

Continue reading “Porting DOOM To The Casio Loopy”

Trying To Use A 2007 Samsung UMPC As Wii U Gamepad

As unique the Nintendo Wii U Gamepad may appear to be, at its core it’s pretty much just a tablet with game controls stuck on it. Now that the communication between the Wii U and the Gamepad have been fully reverse-engineered and poured into easy to use software, this opens the possibility of using other tablets with suitable controls on them for Wii U Gamepad purposes, like the Windows-capable Samsung tablet that [Bringus Studios] decided to experiment on.

Originally designed to run Windows XP Tablet PC Edition, the Samsung Q1 series of ultra-mobile PCs (UMPC) was first released in 2007, featuring a 900 MHz Celeron M CPU. Amusingly [Bingus] mixes up mAh and mWh when comparing battery capacities, as the Li-ion battery pack for this UMPC is an 11.1V one, whereas a smartphone battery is 3.7V nominal.

To turn this UMPC into a Wii U Gamepad, first 32-bit Debian 12 is installed along with the Vanilla Wii U Gamepad project. The main challenge then is to find a Wi-Fi adapter that works for this purpose, as the connection uses a slightly non-standard handshake. Naturally the TP-Link USB WiFi adapter that [Bingus] used changed from its previous and better supported Mediatek chipset to a Realtek one with typical poor Linux support, requiring manual driver compiling.

After more troubleshooting, it’s unfortunately found that the 900 MHz Celeron M in this UMPC just isn’t up to the task, with the decoding of the compressed HDMI stream correspondingly pegging the CPU at 100% with all the frame dropping. It’s likely that this is due to a lack of h.264 hardware decoding support, as this would push this burden onto the CPU. The system uses the Intel 915GMS chipset with the GMA 900 iGPU, which appears to just provide hardware acceleration for MPEG 2.

Continue reading “Trying To Use A 2007 Samsung UMPC As Wii U Gamepad”

The First New WW2 Jeep Since 1945

Online publications sometimes work with sponsors. Over at the Autopian, they landed a sponsorship deal with eBay, but due to an unguarded comment, fulfilling the sponsor’s requirements turned out to be something of a handful. Build a brand-new, completely WW2-spec Jeep using only parts sourced from the auction site, and drive it to Moab for an event. [David Tracy] set to work, and the resulting write-up is a build of epic proportions.

Of course, many Jeeps have been built since the war, not least by Willys and its successors, but also by enthusiasts. You can even buy a modern-day visible derivative of the original made in America by the Indian company Mahindra, which has been licensed to build Jeeps since the 1940s. So his claim of making the first new WW2-spec Jeep since the war may be difficult to substantiate, but it’s certain that his attention to period detail is exceptional. For example, most people would either use a more modern engine or find a second-hand original. Instead, he sources a brand new block from France and builds a new engine from scratch. And is that the infamously flawed early Jeep steering system we spy? The vehicle uses second-hand parts for other major drive train components, but the chassis and body are made in the Philippines.

Continue reading “The First New WW2 Jeep Since 1945”

MicroPython Is This Summer’s Hottest Title For The SNES, Thanks To Claude Fable

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their league in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [Fabian Kübler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at 3.58 MHz, and after that you can watch some sprites bouncing around at a blistering 0.8 FPS. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port — if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting Python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense — the kind of micros you run MicroPython on can emulate the SNES.