In the early 00s there was a tiny moment before the widespread adoption of mobile broadband, after the adoption of home WiFi, and yet before the widespread use of encryption. For this brief time a unique practice arose called wardriving — where people would drive around, document, and use these open wireless networks.
A lot of projects we see around here are built not just because they can be built, but because there’s no other option available. Necessity is the mother of invention, as they say. And for [Jeff] who has many thousands of dollars of food stowed in a chest freezer, his need for something to keep track of his freezer’s status was greater than any commercial offering available. Not only are freezers hard on batteries, they’re hard on WiFi signals as well, so [Jeff] built his own temperature monitor to solve both of these issues.
The obvious solution here is to have a temperature probe that can be fished through the freezer in some way, allowing the microcontroller, battery, and wireless module to operate outside of the harsh environment. [Jeff] is using K-type thermocouples here, wired through the back of the freezer. This one also is built into a block of material which allows him to get more diffuse temperature readings than a standard probe would provide. He’s also solving some other problems with commercially available probes here as well, as many of them require an Internet connection or store data in a cloud. To make sure everything stays local, he’s tying this in to a Home Assistant setup which also allows him to easily make temperature calibrations as well as notify him if anything happens to the freezer.
Although the build is very robust (or, as [Jeff] himself argues, overengineered) he does note that since he built it there have been some additional products offered for sale that fit this niche application. But even so, we always appreciate the customized DIY solution that avoids things like proprietary software, subscriptions, or cloud services. We also appreciate freezers themselves; one of our favorites was this restoration of a freezer with a $700,000 price tag.
If we asked you to name Alexander Graham Bell’s greatest invention, you would doubtless say “the telephone”; it’s probably the only one of his many, many inventions most people could bring to mind. If you asked Bell himself, though, he would tell you his greatest invention was the photophone, and if the prolific [Nick Bild] doesn’t agree he’s at least intrigued enough to produce a replica of this 1880-vintage wireless telephone. Yes, 1880. As in, only four years after the telephone was patented.
It obviously did not catch on, and is not the sort of thing that comes to mind when we think “wireless telephone”. In contrast to the RF of the 20th century version, as you might guess from the name the photophone used light– sunlight, to be specific. In the original design, the transmitter was totally passive– a tube with a mirror on one end, mounted to vibrate when someone spoke into the open end of the tube. That was it, aside from the necessary optics to focus sunlight onto said mirror. [Nick Bild] skips this and uses a laser as a handily coherent light source, which was obviously not an option in 1880. As [Nick] points out, if it was, Bell certainly would have made use of it.
The photophone receiver, 1880 edition. Speaker not pictured.
The receiver is only slightly more complex, in that it does have electronic components– a selenium cell in the original, and in [Nick’s] case a modern photoresistor in series with a 10,000 ohm resistor. There’s also an optical difference, with [Nick] opting for a lens to focus the laser light on his photoresistor instead of the parabolic mirror of the original. In both cases vibration of the mirror at the transmitter disrupts line-of-sight with the receiver, creating an AM signal that is easily converted back into sound with an electromagnetic speaker.
The photophone never caught on, for obvious reasons — traditional copper-wire telephones worked beyond line of sight and on cloudy days–but we’re greatful to [Nick] for dredging up the history and for letting us know about it via the tip line. See his video about this project below.
On the ESP32, there’s a radio, demodulator, and a media access controller (MAC) that takes care of the lowest-level, timing-critical bits of the WiFi protocol. The firmware that drives the MAC hardware is a licensed blob, and while the API or this blob is well documented — that’s how we all write software that uses WiFi after all — it’s limited in what it lets us do. If the MAC driver firmware were more flexible, we could do a lot more with the WiFi, from AirDrop clones to custom mesh modes.
The talk starts with [Jasper] detailing how he reverse engineered a lot of Espressif’s MAC firmware. It involved Ghidra, a Faraday cage, and a lucky find of the function names in the blob. [Frostie] then got to work writing the MAC driver that he calls Ferris-on-Air. Right now, it’s limited to normal old station mode, but it’s definite proof that this line of work can bear fruit.
This is clearly work in progress — they’ve only been at this for about a year now — but we’ll be keeping our eyes on it. The promise of the ESP32, and its related family of chips, being useful as a more general purpose WiFi hacking tool is huge.
As things get smaller, we can fit more processing power into devices like robots to allow them to do more things or interact with their environment in new ways. If not, we can at least build them for less cost. But the design process can get exponentially more complicated when miniaturizing things. [Carl] wanted to build the smallest 9-axis robotic microcontroller with as many features as possible, and went through a number of design iterations to finally get to this extremely small robotics platform.
Although there are smaller wireless-enabled microcontrollers, [Carl] based this project around the popular ESP32 platform to allow it to be usable by a wider range of people. With that module taking up most of the top side of the PCB, he turned to the bottom to add the rest of the components for the platform. The first thing to add was a power management circuit, and after one iteration he settled on a circuit which can provide the board power from a battery or a USB cable, while also managing the battery’s charge. As for sensors, it has a light sensor and an optional 9-axis motion sensor, allowing for gesture sensing, proximity detection, and motion tracking.
Of course there were some compromises in this design to minimize the footprint, like placing the antenna near the USB-C charger and sacrificing some processing power compared to other development boards like the STM-32. But for the size and cost of components it’s hard to get so many features in such a small package. [Carl] is using it to build some pretty tiny robots so it suits his needs perfectly. In fact, it’s hard to find anything smaller that isn’t a bristlebot.
In a recent video, [Chris Edwards] delves into the past, showing how he turned a Commodore Amiga 3000T into a wireless-capable machine. But forget modern Wi-Fi dongles—this hack involves an old-school D-Link DWL-G810 wireless Ethernet bridge. You can see the Amiga in action in the video below.
[Chris] has a quirky approach to retrofitting. He connects an Ethernet adapter to his Amiga, bridges it to the D-Link, and sets up an open Wi-Fi network—complete with a retro 11 Mbps speed. Then again, the old wired connection was usually 10 Mbps in the old days.
To make it work, he even revived an old Apple AirPort Extreme as a supporting router since the old bridge didn’t support modern security protocols. Ultimately, the Amiga gets online wirelessly, albeit at a leisurely pace compared to today’s standards. He later demonstrates an upgraded bridge that lets him connect to his normal network.
We’ve used these wireless bridges to put oscilloscopes and similar things on wireless, but newer equipment usually requires less work even if it doesn’t already have wireless. We’ve also seen our share of strange wireless setups like this one. If you are going to put your Amgia on old-school networking, you might as well get Java running, too.
A quick look around at any coffee shop, city sidewalk, or sadly, even at a traffic light will tell you that people are on their phones a lot. But exactly how much is that? For Americans in 2023, it was a mind-boggling 100 trillion megabytes, according to the wireless industry lobbying association CTIA. The group doesn’t discuss their methodology in the press release, so it’s a little hard to make judgments on that number’s veracity, or the other numbers they bandy about, such as the 80% increase in data usage since 2021, or the fact that 40% of data is now going over 5G connections. Some of the numbers are more than a little questionable, too, such as the claim that 330 million Americans (out of a current estimate of 345.8 million people) are covered by one or more 5G networks. Even if you figure that most 5G installations are in densely populated urban areas, 95% coverage seems implausible given that in 2020, 57.5 million people lived in rural areas of the USA. Regardless of the details, it remains that our networks are positively humming with data, and keeping things running is no mean feat.
