Saw what you want about the wisdom of keeping a 50-year-old space mission going, but the dozen or so people still tasked with keeping the Voyager mission running are some major studs. That’s our conclusion anyway, after reading about the latest heroics that revived a set of thrusters on Voyager 1 that had been offline for over twenty years. The engineering aspects of this feat are interesting enough, but we’re more interested in the social engineering aspects of this exploit, which The Register goes into a bit. First of all, even though both Voyagers are long past their best-by dates, they are our only interstellar assets, and likely will be for centuries to come, or perhaps forever. Sure, the rigors of space travel and the ravages of time have slowly chipped away at what these machines can so, but while they’re still operating, they’re irreplaceable assets.
We love Arduino here at Hackaday; they’ve probably done more to make embedded programming accessible to more people than anything else in the history of the field. One thing the Arduino ecosystem is rarely praised for is its speed. That’s where [Playduino] comes in, with his video (embedded below) that promises to make everyone’s favourite microcontroller run 50x faster.
You might be expecting an unstable overclocking setup, with swapped crystals, tweaked voltages and a hefty heat sink, but no! This is stock hardware. The 50x speedup comes from one simple hack: don’t use digitalWrite();
If you aren’t familiar, the digitalWrite() function is one of the key functions Arduino gives you to operate its boards– specify the pin and the value (high or low) to drive it. It’s very easy, but it’s also very slow. [Playduino] takes a moment to show just how much is going on under the hood when you call digitalWrite(), and shows you what you can do instead if you have a need for speed. (Hint: there’s no Arduino-provided code involved; hardware registers and the __asm keyword show up.)
If you learned embedded programming in an earlier era, this will probably seem glaringly obvious. If you, like so many of us, got started inside of the Arduino ecosystem, these closer-to-the-metal programming techniques could prove useful tools in your quiver. Big thanks to [Stephan Walters] for the tip.
With only two hundred odd days ’til Christmas, you just know we’re already feeling the season’s magic. Well, maybe not, but [Sean Dubois] has decided to give us a head start with this WebRTC demo built into a Santa stuffie.
The details are a little bit sparse (hopefully he finishes the documentation on GitHub by the time this goes out) but the project is really neat. Hardware-wise, it’s an audio-enabled ESP32-S3 dev board living inside Santa, running the OpenAI’s OpenRealtime Embedded SDK (as implemented by ExpressIf), with some customization by [Sean]. Looks like the audio is going through the newest version of LibPeer and the heavy lifting is all happening in the cloud, as you’d expect with this SDK. (A key is required, but hey! It’s all open source; if you have an AI that can do the job locally-hosted, you can probably figure out how to connect to it instead.)
This speech-to-speech AI doesn’t need to emulate Santa Claus, of course; you can prime the AI with any instructions you’d like. If you want to delight children, though, its hard to beat the Jolly Old Elf, and you certainly have time to get it ready for Christmas. Thanks to [Sean] for sending in the tip.
Almost all satellites have some kind of thrusters aboard, but they tend to use them as little as possible to conserve chemical fuel. Reaction wheels are one way to make orientation adjustments without running the thrusters, and [Zachary Tong]’s liquid metal reaction wheel greatly simplifies the conventional design.
Reaction wheels are basically flywheels. When a spacecraft spins one, conservation of angular momentum means that the wheel applies an equal and opposite torque to the spacecraft, letting the spacecraft orient itself. The liquid-metal reaction wheel uses this same principle, but uses a loop of liquid metal instead of a wheel, and uses a magnetohydrodynamic drive to propel the metal around the loop.
[Zach] built two reaction wheels using Galinstan as their liquid metal, which avoided the toxicity of a more obvious liquid metal. Unfortunately, the oxide skin that Galinstan forms did make it harder to visualize the metal’s motion. He managed to get some good video, but a clearer test was their ability to produce torque. Both iterations produced a noticeable response when hung from a string and activated, and achieved somewhat better results when mounted on a 3D-printed air bearing.
Currently, efficiency is the main limitation of [Zach]’s motors: he estimates that the second model produced 6.2 milli-newton meters of torque, but at the cost of drawing 22 watts. The liquid metal is highly conductive, so the magnetohydrodynamic drive takes high current at low voltage, which is inconvenient for a spacecraft to supply. Nevertheless, considering how hard it is to create reliable, long-lasting reaction wheels the conventional way, the greatly improved resilience of liquid-metal reaction wheels might eventually be worthwhile.
Shade is the mortal enemy of solar panels; even a little shade can cause a disproportionate drop in power output. [Alex Beale] reviewed a “revolutionary” shade-tolerant panel by Renology in a video embedded below. The results are fascinating.
While shading large portions of the panels using cardboard to cut off rows of cells, or columns of cells, the shade tolerant panel does very well compared to the standard panel– but when natural, uneven shading is applied to the panel, very little difference is seen between the standard and active panels in [Alex]’s test. We suspect there must be some active components to keep power flowing around shaded cells in the Renology panel, allowing it to perform well in the cardboard tests. When the whole panel is partially shaded, there’s no routing around it, and it performs normally.
It’s hard to see a real-world case that would justify the extra cost, since most shading doesn’t come with perfect straight-line cutoffs. Especially considering the added cost for this “shade tolerant” technology (roughly double normal panels).
Want to give an AI the ability to do stuff in Blender? The BlenderMCP addon does exactly that, connecting open-source 3D modeling software Blender to Anthropic’s Claude AI via MCP (Model Context Protocol), which means Claude can directly use Blender and its tools in a meaningful way.
MCP is a framework for allowing AI systems like LLMs (Large Language Models) to exchange information in a way that makes it easier to interface with other systems. We’ve seen LLMs tied experimentally into other software (such as with enabling more natural conversations with NPCs) but without a framework like MCP, such exchanges are bespoke and effectively stateless. MCP becomes very useful for letting LLMs use software tools and perform work that involves an iterative approach, better preserving the history and context of the task at hand.
Unlike the beach scene above which used 3D assets, this scene was created from scratch with the help of a reference image.
Using MCP also provides some standardization, which means that while the BlenderMCP project integrates with Claude (or alternately the Cursor AI editor) it could — with the right configuration — be pointed at a suitable locally-hosted LLM instead. It wouldn’t be as capable as the commercial offerings, but it would be entirely private.
Embedded below are three videos that really show what this tool can do. In the first, watch it create a beach scene using assets from a public 3D asset library. In the second, it creates a scene from scratch using a reference image (a ‘low-poly cabin in the woods’), followed by turning that same scene into a 3D environment on a web page, navigable in any web browser.
Back in 2022 we saw Blender connected to an image generator to texture objects, but this is considerably more capable. It’s a fascinating combination, and if you’re thinking of trying it out just make sure you’re aware it relies on allowing arbitrary Python code to be run in Blender, which is powerful but should be deployed with caution.
