Mysterious Files PH

Candles are pretty to look at, but they tend to be rather a fire risk and a negative influence on air quality, too. If you want the vibe without the hassle, you might enjoy this skeuomorphic electronic candle from [Marek.]

The build is deceptively simple for what it achieves. There is just one transistor, one thermistor, an LED, and a couple of resistors. You can “light” the candle just like a real one by heating the NTC thermistor. That’s because it makes the thermistor’s resistance drop such that the gate voltage on the MOSFET goes high enough to turn on the LED. There’s a resistor in series with the LED, which gets warm enough to keep the thermistor conductive enough to keep the MOSFET conducting in turn. However, if you blow on the assembly, you’ll cool the thermistor enough that the MOSFET stops conducting and the LED turns off.

[Marek] notes that the design is finnicky and quite subject to the vagaries of heat transfer between components; it took some fine tuning to get it working as well as it does. There’s an advanced version with a voltage regulator that helps the circuit run more reliably across a range of battery voltages if you so desire. Funnily enough, it’s also available in an SAO version as well, if you fancy an ersatz candle on your Hackaday conference badge. Neat, huh?

The only thing about [Marek’s] candle is that it doesn’t flicker like a real candle. One wonders if one of those integrated flickering LEDs could add that functionality without drastically changing the circuit, though. We’ve featured such flickery circuits before, too. Video after the break.

[Evan Monsma], the prolific experimenter with cameras, found himself with an issue: he had a small Sony action camera with good performance in every respect but battery life, which was as low as twenty minutes. This was too short for practical everyday use, so [Evan] built an external adapter to add a larger battery and a few other features.

In fairness to the camera’s designers, it wasn’t really meant for consumer use; it was meant as more of a stunt camera, where endurance is less of a concern than size and weight. [Evan] wanted to use it for more general situations, hence the new battery. He first attached a small CNC-machined aluminium half-cage, which provided mounting points for additional hardware, including a screw-mount for a neutral-density filter.

[Evan] next designed, 3D-printed, and attached a mount and battery clip for a larger Sony camera battery; the mount also held a voltage converter to step the battery’s 7.2 V down to the original battery’s 3.7 V. A USB power adapter slotted into the battery compartment and broke out the power leads to the converter. Unfortunately, short battery life isn’t the camera’s only issue; it also eventually overheats with continuous use, which kept [Evan] from running a real battery-life test. He is, however, confident that it will last long enough for practical use.

We’ve seen a similar action camera mod before, as well as a mod to allow the use of third-party batteries in a vendor-locked camera. For larger cameras, we’ve even seen a hot-swappable battery pack.

Thanks to [Luis Mercado] for the tip!

The Amazon Echo Dot is one of Amazon’s so-called ‘smart speaker’ offerings that tie into their larger Alexa-fueled ecosystem, designed to be a pretty minimalistic device that gives you access to this voice assistant and also the Amazon AWS cloud access to your home. If that latter part isn’t really your jam, you can always try to unshackle the device from the Amazonian cloud by rooting the device, as [Andy] recently did with a 2018 Echo Dot 3.

In addition to the video there is also a blog post in which the steps required to root the device are covered. This is then used to turn the device into a Home Assistant voice satellite, using a Claude-vibecoded project created by [Julian Imhof]. As [Andy] notes, this code seems to work, but it’s completely unaudited so YMMV. Device support is also limited to only certain Echo Dot and Echo Show devices as listed on the project page.

The first step is to gain USB access to the board inside the device, which for USB-less devices like the Dot in question requires opening the device to solder a USB connector onto the test pads that are available on the PCB. For other Echo devices you can just use the existing USB port, which makes this first step slightly easier.

These devices run Fire OS, so basically Android, which means a fairly standard process of unlocking the bootloader and installing the hassmic application that replaces Alexa. During testing [Andy] noticed that voice processing was rather slow, requiring switching from Whisper to Speech-to-Phrase to make simple things like turning a light on not take a minute.

Overall it seems like a pretty decent way to repurpose these devices as ESPHome devices, with a few gotchas when it comes to the resources required for local voice processing.

It’s no big secret at this point that we are looking at the final years of the two venerable Voyager spacecraft. With their power supplies diminishing and their 1970s-era electronics still giving it all they got, their teams are working miracles to stretch out the time to the final goodbye for as long as possible. Despite these efforts Voyager 1 went silent for more than 24 hours on October 18 and 19, with the team still trying to figure out what happened.

The most recent change to Voyager 1 was the same ‘big bang’ switching of multiple instruments to lower-power versions, while keeping an eye on keeping the electronics and fuel at reasonable temperatures. This should give both spacecraft a few more years before power reserves fall below usable levels. Whether this switch is related to this communication blackout is currently unknown.

From the diagnostic data that the team obtained after communications were restored it’s clear that a group of thrusters went offline with backup units kicking in, indicating that the onboard computer detected some kind anomaly with the former. Whether this is a recurrence of the clogged fuel lines that has been observed before will have to be investigated.

We still fervently hope that both Voyagers can make it into the 2030s before both of them will fall silent forever. Final goodbyes are never easy, but we are most grateful to the Voyager teams over the decades for going above and beyond to make sure that literally everything has been attempted before those fateful days arrive.

Thanks to [Mark Stevens] for the tip.

[Roni Bandini]’s JEV WiFi Analyzer is an interesting experiment that glues together a single-board Linux computer, a USB WiFi adapter, and a specialized AI model to create a new kind of automated tool that passively monitors WiFi activity to measure and profile coverage, congestion, and suggest possible optimizations.

Here’s how it works: a Python program connects to WiFi, cycles through available channels, and uses scapy to gather details like signal strength, number of clients, WiFi frames per second, and similar data about each given channel. That data is fed to Jev, a highly efficient sort of decision-making AI model responsible for interpreting that data on an ongoing basis.

Briefly, Jev is a new kind of AI that is completely unable to generate text or images. It outputs only numbers representing bounded decisions. We covered these decision-making models earlier, including locally-installed versions. Jev is cheap enough to throw at a variety of problems, but it’s also practical to run your own model on your own hardware.

In [Roni]’s analyzer, Python gathers the raw numbers and Jev takes care of classifying the WiFi network’s coverage, congestion level, and basic remedial actions if applicable. There’s a brief video embedded below (Spanish only) that shows the Jev WiFi Analyzer in action.

The AI isn’t making particularly deep analyses, but it doesn’t take much to imagine Jev taking a more active role like deciding which channels to spend more (or less) time monitoring. Using a decision-making model in this way is interesting, and makes us wonder if similar models integrated with other kinds of hardware is a branch of projects waiting to happen.

When it comes to internal combustion engines (ICEs), it’s generally accepted that each cylinder doesn’t have more valves to let in a fresh fuel mixture and to exhaust the aftermath than absolutely necessary. You could argue in favor of this also because it reduces the amount of valve seat surface and thus the potential for leaks, but there is historical precedent for higher valve counts. Hence [Alexander’s Laboratory] had to give a ten-valve engine a shake, just to see what effect adding more valves has.

A cited historical example is the Yamaha FX750, which features a five-cylinder engine that has three inlet and two outlet valves per cylinder, making for a 20-valve design that is claimed to improve performance, also because each valve can be smaller and lighter than with a single valve per side. Other motorbike manufacturers would also try such configurations, with some fascinating examples shown in the video.

What [Alexander] tries here is to create a 10-valve version, for a symmetric five valves intake and five for exhaust. Rather than building an entire engine from scratch, the largely 3D-printed ICE that was featured in previous videos will be modified with a new cylinder head, replacing the current four-valve one.

For the custom valves large wood screws are used, after making sure that they can take the heat of the combustion. Making even ten of these small valves fit was a challenge, but ultimately got squeezed into a CNCed aluminium and nylon-printed hybrid cylinder head. The existing camshaft was reused by using an adapter that simply drives five valves at the same time.

After some troubleshooting and tuning the engine actually runs pretty well, though sadly no comparison metrics were provided versus the four-valve version of the cylinder head. Hopefully we’ll see this in an upcoming video.

In the history of object-oriented (OO) computer languages, Smalltalk has a special place. It wasn’t the first OO language, and it hasn’t spread as well as some others. But it was the first OO language many people encountered, and it influenced many other languages you’ve probably seen. Developed at the famed Xerox PARC, it also introduced many people to the “model/view/controller” (MVC) architecture. Cuis Smalltalk is a free and portable modern Smalltalk-80 environment. It replaces the traditional MVC framework with Morphic, but otherwise, it would be very familiar to someone who used Smalltalk in the 1990s. The project’s goal is to stay simple at the core, although you can add complexity via packages.

The software has been around for a while, but it is on a rolling release model, so the install page suggests you clone the Git repo. You can, however, get a stable release, which might be important if you were deploying applications. Running the program results in a Cuis desktop where you can open various things like workspaces, help documents, and the transcript.

Smalltalk throws some people because it takes OO to an extreme. For example, you don’t add two and three using an operator. You send the object two a message that includes another object, three. You can think of sending a message as calling a method on an object. As with virtual functions in C++, different objects can respond differently to the same request. For example, an Animal class might have a speak message that causes a cow to print “moo” and a chicken to print “cluck.”

You get used to it, and there’s a very nice class browser that lets you examine classes and what you can do with them. There are even packages to work with an Arduino over a serial port. They haven’t been updated lately, so they might (or might not) need a little work.

We’ve looked at GNU Smalltalk before. We’ve also seen a version that runs directly on a Raspberry Pi.