Mysterious Files PH

There are many experimenters who have had a go at a mechanical television, and though there are a few challenges, it’s a relatively straightforward project in 2026. A hundred years ago though it was still beyond the cutting edge of technology, and that’s where [Paul Kocyla] is placing his build. It’s a mechanical TV system, using only parts that would have been available in the 1920s. The project isn’t finished yet, but we suggest following along for some fascinating insights into developments in early electronics.

As it stands he has a wooden chassis, a period power supply and amplifier, a synchronous motor, and of course the Nipkow disk that makes it all possible. The electronics aren’t quite finished, and he’s yet to source a neon lamp. This last party may be particularly tricky, as there were specific flat-plate neon lamps made for this application. It’s interesting to find that the motor would synchronize to the grid frequency and would need to be restarted a few times for the frame to be in the right place.

His last posting contains a particularly interesting nugget of information for anyone using tubes. The amplifier carries a 120 Hz hum, something difficult to trace. The culprit is the early tubes with directly heated cathodes formed from the heaters themselves; they had such a low thermal mass that they would “blink” at 120 Hz if fed with AC. A set of period copper oxide rectifiers solve this by feeding DC to the heaters. There’s a YouTube series to follow, and we’ve placed the most recent one in which he fixes the power supply, below the break.

Back in January, we marked the hundredth anniversary of mechanical TV’s invention. Meanwhile, some of us have been known to experiment in this direction too.

Sometimes, it’s hard to stop picking up your phone every few minutes to check on notifications and scroll endlessly through the slop of the day. [PushpendraC2] has been working on a solution to this problem that would ideally discourage such behavior —  a nifty little smartphone stand!

The concept is straightforward enough—the smartphone stand uses a simple tactile button to determine if your smartphone is sitting on the little 3D printed shelf, or not. However, the smarts inside do a bit more than that, too. An ESP32-S3 is charged with monitoring whether the smartphone is sitting in place, and starts counting “focus time” while it’s there. If the phone is picked up, the OLED display on the shelf starts ticking down a 5-second timer to encourage you to put it back. If you don’t, the focus time is reset and you lose your streak.

It’s also possible to tap a touch sensor on the device which sets a reminder timer, prompting you to put your phone back after a set period of time, between 2 to 30 minutes. A buzzer will then start going off to prompt you to put the phone down. If you want to track the devices impact, you merely need to log in to the web server hosted by the ESP32, which shows your current focus session time, along with a heatmap of your daily productivity.

It’s a simple idea, but one that uses a few neat psychological hooks to encourage compliance and behavioral change. We’ve featured similar projects in this vein before, No surprise, as phone addiction is a problem experienced by many.

Reachy Mini is a limbless desktop robot from Hugging Face made for human interaction experiments, and to give you an idea of what it’s like is a guide on how to implement expressive, local conversational AI complete with head movements and antenna wiggles. It’s conversational in the sense that it aims to feel natural, with low-latency responses and the ability to interrupt, with everything running on local hardware if one so wishes.

The software stack is essentially VAD (voice activity detection) → STT (speech-to-text) → LLM (large language model) → TTS (text-to-speech) which allows users to tweak things to their liking, or independently swap or modify pieces as things evolve.

This also allows users to tailor the services to match whatever their hardware is capable of. For example, one could easily use a frontier AI model via remote API for the LLM while keeping everything else local.

The local models in the example configuration are effective and relatively modest (Qwen3-4B-Instruct for the LLM, and even smaller models for the rest) but it’s nice to have the option to offload parts to remote providers if necessary.

Reachy Mini looked very interesting when it was launched as a kit last year, and since then Hugging Face has built up an impressive software suite and infrastructure through which users can easily share their applications. If you’re curious, there’s a simulator for Reachy Mini which should give you an idea of what it can do.

[Sam Wilkinson] recently installed a Dreo CLF513S ceiling fan in his place — it’s cheap, well-sized, and blows air around as you’d expect it to. The only problem is that it only works with an ugly cloud-only smart home setup out of the box. Never mind, though, because [Sam] figured out how to hack up a custom solution.

Hacking efforts began with the included remote control. [Sam] identified that the remote had to be RF, since it didn’t need line of sight to work properly. The FCC ID on the back of the device further indicated this was the case. Armed with that knowledge, it was simply a case of figuring out the commands sent by the remote, building something to replay them, and then hooking that into [Sam]’s existing Home Assistant setup.

The remote ran on 433.92 MHz, a not-uncommon bit of spectrum for these sort of appliances. An RTL-SDR was thusly enlisted to capture the output, with a spectrogram indicating the remote used simple on-off keying to send commands. Once commands were captured, [Sam] grabbed an ESP32-C6 microcontroller, hooked it up to a RFM69HCW radio transceiver, and programmed it to replay the fan on/off command. From there, a little dabbling with MQTT got the ESP32 controlling the fan as desired from within the Home Assistant ecosystem.

Sometimes, it’s hard to find smart home gear that actually suits your tastes and budgets. Often, a bit of tinkering can shape existing appliances to bend to your will instead. If you’re tweaking your own gear to better fit your smart home, don’t hesitate to notify the tipsline.

If you’re a fleshy human, you probably learn to play video games by looking at the screen and pressing the buttons, and maybe copying the way you’ve seen others play the game before. [tryfonaskam] has recently been trying to teach an AI to play games in much the same way.

[tryfonaskam] built PILA—short for Polytrack Imitation Learning Agent. As you might have guest from the name, it’s an AI agent designed to play a simple racing game called PolyTrack. Rather than manually programming the agent’s behavior, PILA instead trains itself through supervised learning, where it observes the gameplay state via screen capture and monitoring the keyboard inputs made by human players as they drive the tracks. It then uses this to guide its own behavior, and learns to play the game by itself. The model receives live frames from the graphics engine while playing, and then predicts the appropriate actions and makes the right keyboard inputs in turn to steer the car through the track.

This project reminds us of similar efforts to teach a raw AI how to play Trackmania, or the Drivatar technology in the Forza series of racing games.

YouTube streaming typically involves a camera with an HDMI output, a USB3 HDMI digitiser, and a suitably beefy PC to run it all. It’s quite a process, and for [Coreymillia], more complex than it needs to be. He’s come up with something simpler, a dedicated self-contained streaming rig using a Raspberry Pi 4.

As you might expect it uses the Raspberry Pi HQ camera at the optical end, but it’s the software surrounding it that transforms it from a mere camera into a streaming rig. There’s a web based user interface, but perhaps more interesting are the companion dashboard peripherals. A Raspberry Pi or an ESP32 Cheap Yellow Display can both serve as a small in-view dashboard and controller.

We know from experience that a stream can be a difficult thing to get right even with high-end hardware, and we’re interested to see this standalone device allowing , we hope, an easier way to do it. If you’re a streamer we’re guessing you’ll be taking a closer look. Even so, this is surprisingly, not the simplest Raspberry Pi based streaming device we’ve seen.

Swift is a relatively modern program language, appearing in 2014 as a replacement for Objective-C. Since then, it’s become a popular solution for programming apps across Apple platforms. That led [Yeo Kheng Meng] to a simple yet fun idea—porting Swift to the oldest Apple platform of all.

Yes, [Yeo] managed to build a development environment for Swift that targets the Apple II platform. Not just one machine, either—everything from the original Apple II up to the IIe and a little beyond. Now, the Apple II is very different from modern Macs and iPhones and the like, having debuted in 1977 with a 1 MHz 6502 CPU and a minuscule 4 KB of RAM. But that doesn’t mean you can’t use a modern language to develop for it!

[Yeo] does a great job of explaining how it all works, and how Claude Code and GPT 5.5 Codex were used to help piece things together. The compiler is set up to spit out bytecode that’s executed by a virtual machine running on the 6502. The target was to allow the setup to work on a standard 1977 Apple II from the factory, which would allow it to then run on subsequent models without issue. However, there is a small note— [Yeo]’s implementation requires the RAM to have been upgraded to 48 KB.

We love seeing modern stuff ported to the Apple II. This Portal port was a particular highlight.