UChaser Follows You Anywhere

If you’ve been making up for lost years of travel in 2023, you might have seen a fellow traveler in the airport terminal or train station walking with their luggage happily careening behind them. [Jesse R] and [Brian Lindahl] wanted more of that. They wanted an open-source, low-cost system that could be put in anything.

The basic principle is that they will have a transmitter that sends both a radio signal and an ultrasonic pulse. The receiver receives the radio signal and uses it as a reference for the two ultrasonic sensors. The time since the radio signal is compared between the two, and a distance and direction are established.

In practice, the radio is an ESP32-S3 using ESP-NOW (which we’ve seen relatively recently on another project), a protocol from Espressif that offers low latency 250 bytes payloads. The ultrasonic transceiver is based on Sparkfun’s HC-SR04. For prototyping purposes on the receiver, they just removed the transmitter to avoid populating the airwaves, as to listen, you had to transmit. The prototype was an electric wheelbarrow that would happily follow you around the yard wherever you go.

With the concept validated, they moved to a custom ultrasonic setup with a custom buffer amp and damp transistor, all centered around 20kHz. The simulations suggested they should have been better than the HC-SR04 from Sparkfun, but the 30-foot (9 meters) range went to 10 feet (3 meters). They ultimately returned to using Sparkfun’s circuit rather than the custom amp.

We’re looking forward to seeing the project continue. There are various challenges, such as variability in the speed of sound, echos and reflections, and ultrasonic line of sight. We love the peak behind the curtain that allows us to see what decisions get made and the data that informs those decisions. All the code and PCB design files are available on GitHub under an MIT and Creative Common license, respectively. This project was submitted as part of the 2o23 Hackaday Prize.

Video after the break.

Continue reading “UChaser Follows You Anywhere”

Screwdrivers And Nuclear Safety: The Demon Core

Harry Daghlian and Louis Slotin were two of many people who worked on the Manhattan Project. They might not be household names, but we believe they are the poster children for safety procedures. And not in a good way.

Harry Daghlian (CC-BY-SA 3.0, Arnold Dion)

Slotin assembled the core of the “Gadget” — the plutonium test device at the Trinity test in 1945. He was no stranger to working in a lab with nuclear materials. It stands to reason that if you are making something as dangerous as a nuclear bomb, it is probably hazardous work. But you probably get used to it, like some of us get used to working around high voltage or deadly chemicals.

Making nuclear material is hard and even more so back then. But the Project had made a third plutonium core — one was detonated at Trinity, the other over Nagasaki, and the final core was meant to go into a proposed second bomb that was not produced.

The cores were two hemispheres of plutonium and gallium. The gallium allowed the material to be hot-pressed into spherical shapes. Unlike the first two cores, however, the third one — one that would later earn the nickname “the demon core” — had a ring around the flat surfaces to contain nuclear flux during implosion. The spheres are not terribly dangerous unless they become supercritical, which would lead to a prompt critical event. Then, they would release large amounts of neutrons. The bombs, for example, would force the two halves together violently. You could also add more nuclear material or reflect neutrons back into the material.

Continue reading “Screwdrivers And Nuclear Safety: The Demon Core”

Automation For The NES

Old hardware might not be anywhere close to as powerful as modern technology, but it does have a few perks. Aesthetics can of course drive the popularity of things like retro gaming systems, but the ease of understanding the underpinnings of their inner workings is also critical. The Nintendo Entertainment System, now nearly four decades old, is a relatively simple machine by modern standards and this lends the system to plenty of modifications, like this controller that allows the system to be somewhat automated.

The original NES controller used a fairly simple shift register to send button presses to the system. The system outputted a latch signal to the controller, the shift register would take as input the current state of the buttons, and then would send them one-by-one to the system at a rate of around 1000 times per second. These signals can be sent without a controller easily enough, too. This build uses a CD4021 shift register, which is the same as the original controller, but instead of reading button states it accepts its inputs from a separate computer via a latching circuit. In this case, the separate computer is a custom design that came about through adapting cassette storage for a 6502-based computer, but it could come from anything else just as easily.

With this system in place, it’s possible to automate gameplay to some extent. Since the system can’t get feedback about the game in its current state, it requires some precise timing to get it to play the game well, and a lot of tuning needs to go into it. This isn’t just a one-off, either. Similar methods are how we get tool-assisted speedruns of games and although these are often done in emulators instead of on real hardware, they can result in some interesting exploits.

Continue reading “Automation For The NES”

Low Res Arduino Thermal Camera

Do you know how you see those cheap telescopes at the department store? The box has beautiful pictures that probably came from the Hubble. What you will see is somewhat different. You have to carefully look at [upir’s] Arduino thermal camera project because it intersperses pictures of what you expect an 8×8 sensor will produce with images produced by a much better camera.

The actual project — watch the video below — is undoubtedly neat. An inexpensive 8×8 IR sensor and an 8X8 LED panel join to form a crude but usable thermal camera.

Continue reading “Low Res Arduino Thermal Camera”

A Guide To Field Stripping Your Voyager Tricorder

For the last few years, [Mangy_Dog] has been working on what is easily the most technically and aesthetically impressive Star Trek tricorder prop the world has ever seen. With each new version of the hardware we’ve gotten the occasional peek under the hood or source code walk-through, but these limited presentations have made it somewhat difficult to really appreciate the scale of this undertaking.

But now thanks to this epic hour-long tour of the hardware and software that makes up version 2.5 of hisĀ Voyager tricorder, we can finally see just how incredible the engineering that’s gone into this project really is. Every detail has been meticulously considered to deliver a final product that’s not only as visually accurate as possible, but reliable enough to actually carry around. Continue reading “A Guide To Field Stripping Your Voyager Tricorder”

Thin Client Wysens Up To Become OpenWrt Router

For some of us, unused hardware lying around just calls to be used. It seems like [Miles Goodhew] heard the call, and wanted to put a Dell Wyse 3040 thin client to use — in this case as a wireless router. It seems simple enough. OpenWrt supports x64_64 targets, and the thin client has 2G of ram and 8G of flash. It should make for a very capable router.

And before you tell us that it’s just another computer, and that installing OpenWrt on a miniature x86 machine isn’t a hack, note that there were some speedbumps along the way. First off, the motherboard has integrated storage, with the not-very-useful ThinLinux installed, and the system BIOS locked down to prevent reinstall. There is a BIOS clear button on the system’s diminutive motherboard. With the BIOS lock out of the way, a real Linux system can be installed on the small 8 GB mmcblk device.

The next issue the the CPU. It’s an Intel Atom x5 z-series. OpenWrt won’t actually boot on that oddball, not-quite- processor, so [Miles] opted to install Fedora and test via virtualization instead. If that statement makes you do a double-take, you’re not alone. The initial explanation sounded like the mobile-centric processor was missing instructions to make OpenWrt run, but virtualization doesn’t add any instructions for a guest to use. It turns out, the problem is a missing serial port that OpenWrt uses as a debugging output by default.

After a custom OpenWrt compile, the device comes up just as you’d expect, and while it would be underpowered as a desktop, OpenWrt runs happily shuffling bits from Ethernet to wireless adapter at respectable speeds. As [Miles] points out, there’s nothing ground-breaking here, but it’s nice to have the details on re-using these machines compiled in one place. And if you too love the idea of putting OpenWrt in places where nobody intended, we’ve got you covered.

A Speaker With Dancing Ferrofluid

A speaker project isn’t usually very different, but we couldn’t help but notice [Electronoob’s] latest speaker not for its audio performance but because it features dancing ferrofluid and is an unusual work of art. The housing is 3D printed and includes some translucent portions for LEDs.You can see and hear the speaker at work in the video below.

Apparently, not all ferrofluid is created equal. You can get just the fluid, but then you have to work up some sort of carrier fluid. You can also get the material already in a glass with a carrier fluid, which is a better option. Apparently, you can also get cheap material that is little more than iron filings suspended in a liquid. That’s not really ferrofluid.

Continue reading “A Speaker With Dancing Ferrofluid”