The modern hacker and maker has an incredible array of tools at their disposal — even a modestly appointed workbench these days would have seemed like science-fiction a couple decades ago. Desktop 3D printers, laser cutters, CNC mills, lathes, the list goes on and on. But what good is all that fancy gear if you don’t put it to work once and awhile?
If we had to guess, we’d say dust never gets a chance to accumulate on any of the tools in [Ed Nisley]’s workshop. According to his blog, the prolific hacker is either building or repairing something on a nearly daily basis. All of his posts are worth reading, but the multifaceted rebuilding of a Anker LC-40 flashlight from a couple months back recently caught our eye.
Originally Android apps were only developed in Java, targeting the Dalvik Java Virtual Machine (JVM) and its associated environment. Compared to platforms like iOS with Objective-C, which is just C with Smalltalk uncomfortably crammed into it, an obvious problem here is that any JVM will significantly cripple performance, both due to a lack of direct hardware access and the garbage-collector that makes real-time applications such as games effectively impossible. There is also the issue that there is a lot more existing code written in languages like C and C++, with not a lot of enthusiasm among companies for porting existing codebases to Java, or the mostly Android-specific Kotlin.
The solution here was the Native Development Kit (NDK), which was introduced in 2009 and provides a sandboxed environment that native binaries can run in. The limitations here are mostly due to many standard APIs from a GNU/Linux or BSD environment not being present in Android/Linux, along with the use of the minimalistic Bionic C library and APIs that require a detour via the JVM rather than having it available via the NDK.
Despite these issues, using the NDK can still save a lot of time and allows for the sharing of mostly the same codebase between Android, desktop Linux, BSD and Windows.
As USB-C PD becomes more and more common, it’s useful to have a tool that lets you understand exactly what it’s doing—no longer is it limited to just 5 V. This DIY USB-C PD tool, sent in by [ludwin], unlocks the ability to monitor voltage and current, either on a small screen built into the device or using Wi-Fi.
This design comes in two flavors: with and without screen. The OLED version is based on an STM32, and the small screen shows you the voltage, current, and wattage flowing through the device. The Wi-Fi PD logger version uses an ESP-01s to host a small website that shows you those same values, but with the additional feature of being able to log that data over time and export a CSV file with all the collected data, which can be useful when characterizing the power draw of your project over time.
Both versions use the classic INA219 in conjunction with a 50 mΩ shunt resistor, allowing for readings in the 1 mA range. The enclosure is 3D-printed, and the files for it, as well as all the electronics and firmware, are available over on the GitHub page. Thanks [ludwin] for sending in this awesome little tool that can help show the performance of your USB-C PD project. Be sure to check out some of the other USB-C PD projects we’ve featured.
Modern retrocomputing tricks often push old hardware and systems further than any of the back-in-the-day developers could have ever dreamed. How about a neural network on an original Mac? [KenDesigns] does just this with a classic handwritten digit identification network running with an entire custom SDK!
Getting such a piece of hardware running what is effectively multiple decades of machine learning is as hard as most could imagine. (The MNIST dataset used wasn’t even put together until the 90s.) Due to floating-point limitations on the original Mac, there are a variety of issues with attempting to run machine learning models. One of the several hoops to jump through required quantization of the model. This also allows the model to be squeezed into the limited RAM of the Mac.
Impressively, one of the most important features of [KenDesigns] setup is the custom SDK, allowing for the lack of macOS. This allows for incredibly nitty-gritty adjustments, but also requires an entire custom installation. Not all for nothing, though, as after some training manipulation, the model runs with some clear proficiency.
If you want to see it go, check out the video embedded below. Or if you just want to run it on your ancient Mac, you’ll find a disk image here. Emulators have even been tested to work for those without the original hardware. Newer hardware traditionally proves to be easier and more compact to use than these older toys; however, it doesn’t make it any less impressive to run a neural network on a calculator!
It’s likely that many Hackaday readers will be aware of UTF-8, the mechanism for incorporating diverse alphabets and other characters such as 💩 emojis. It takes the long-established 7-bit ASCII character set and extends it into multiple bytes to represent many thousands of characters. How it does this may well be beyond that basic grasp, and [Vishnu] is here with a primer that’s both fascinating and easy to read.
UTF-8 extends ASCII from codes which fit in a single byte, to codes which can be up to four bytes long. The key lies in the first few bits of each byte, which specify how many bytes each character has, and then that it is a data byte. Since 7-bit ASCII codes always have a 0 in their most significant bit when mapped onto an 8-bit byte, compatibility with ASCII is ensured by the first 128 characters always beginning with a zero bit. It’s simple, elegant, and for any of who had to deal with character set hell in the days before it came along, magic.
We’ve talked surprisingly little about the internals of UTF-8 in the past, but it’s worthy of note that this is our second piece ever to use the poop emoji, after our coverage of the billionth GitHub repository.
As the saying goes, “if it can’t be grown, it has to be mined”– but what about all the metals that have already been wrested from the bosom of the Earth? Once used, they can be recycled– or as this paper charmingly puts it, become ore for “urban mining” techniques. The technique under discussion in the Chemical Engineering Journal is one that extracts metallic silver from e-waste using fatty acids and hydrogen peroxide.
This “graphical abstract” gives the rough idea.
Right now, recycling makes up about 17% of the global silver supply. As rich sources of ore dry up, and the world moves to more sustainable footing, that number can only go up. Recycling e-waste already happens, of course, but in messy, dangerous processes that are generally banned in the developed world. (Like open burning, of plastic, gross.)
This paper describes a “green” process that even the most fervant granola-munching NIMBY wouldn’t mind have in their neighborhood: hot fatty acids (AKA oil) are used as an organic solvent to dissolve metals from PCB and wire. The paper mentions sourcing the solvent from waste sunflower, safflower or canola oil. As you might imagine, most metals, silver included, are not terribly soluble in sunflower oil, but a little refining and the addition of 30% hydrogen peroxide changes that equation.
More than just Ag is picked up in this process, but the oils do select for silver over other metals. The paper presents a way to then selectively precipitate out the silver as silver oleate using ethanol and flourescent light. The oleate compound can then be easily washed and burnt to produce pure silver.
The authors of the paper take the time to demonstrate the process on a silver-plated keyboard connector, so there is proof of concept on real e-waste. Selecting for silver means leaving behind gold, however, so we’re not sure how the economics of this method will stack up.
Is it finally time to cue up the Bowie? Or was the NASA presser on Wednesday announcing new findings of potential Martian biosignatures from Perseverance just another in a long line of “We are not alone” teases that turn out to be false alarms? Time will tell, but from the peer-reviewed paper released simultaneously with the news conference, it appears that biological activity is now the simplest explanation for the geochemistry observed in some rock samples analyzed by the rover last year. There’s a lot in the paper to unpack, most of which is naturally directed at planetary scientists and therefore somewhat dense reading. But the gist is that Perseverance sampled some sedimentary rocks in Jezero crater back in July of 2024 with the SHERLOC and PIXL instruments, extensive analysis of which suggests the presence of “reaction fronts” within the rock that produced iron phosphate and iron sulfide minerals in characteristic shapes, such as the ring-like formations they dubbed “leopard spots,” and the pinpoint “poppy seed” formations.
