Cantennas outperform every consumer-grade Wi-Fi antenna I’ve had the bad luck of purchasing. Cantenna is a mashup of ‘can’ and ‘antenna’ creating the nickname for a directional waveguide antenna built from re-purposed steel cans. For anyone who has yet to build one, it makes an excellent afternoon project. Here are some build instructions and technical details. I went beyond that, and ended up catching a rogue WiFi access point in the process.
When I needed to extend the range of some ESP8266-based sensors, cantennas were right at the top of my list of things to try. It was easy enough to build one, attach it to a Wemos Mini D1 Pro, and call the job done… leaving me with plenty of time to over-engineer it, and I ended up down a bit of a rabbit hole.
The first thing I did was stop using cans. Canned goods are not only expensive in my corner of the world, but more importantly don’t lend themselves that well to making a standardized antenna in volume. I can also only eat so many beans! The latter reason alone is enough to consider an alternative design like a modular dish reflector.
Few things are as frustrating as a WiFi signal that drops in and out. On a public network it is bad enough but at home? Even if you can live with it, your cohabitants will certainly impune your technical abilities if they don’t have solid WiFi. One solution is a WiFi repeater. You can buy one, of course. But you can also make one out of an ESP8266 and some code from GitHub. There is also a video about the project, below.
[Martin Ger’s] code implements NAT, so it isn’t a true WiFi repeater, but more of a bridge or router. Of course, that means performance isn’t stellar, but tests show it can sustain about 5 Mbps, which isn’t bad for a little board that costs a couple of bucks. There is a limit of 8 clients, but that’s more than enough for a lot of cases. Even if you don’t want to use it as a router, it has a mesh mode that could be a basis for some interesting projects all by itself.
Everyone’s favourite IOT module, the ESP8266, is often the go-to choice for any project that needs quick and cheap control over the web. [Andi23456] wanted to control his quadcopter using the luxury of his mobile phone and thought permanently tethering an ESP12-E module to the quadcopter was exactly what he required.
The ESP8266, really showcasing its all-round prowess, hosts both a web server for a HTML5 based joystick and a Websockets server so that a client, such as a phone, could interact with it over a fast, low latency connection. Once the ESP8266 receives the input, it uses interrupts to generate the corresponding PPM (Pule Position Modulation) code which the RC receiver on the quadcopter can understand. Very cool!
What really makes this realtime(ish) control viable is Websockets, a protocol that basically allows you to flexibly exchange data over an “upgraded” HTTP connection without having to lug around headers each time you communicate. If you haven’t heard of Websockets you really should look really check out this library or even watch this video to see what you can achieve.
Identifying ham radio signals used to be easy. Beeps were Morse code, voice was AM unless it sounded like Donald Duck in which case it was sideband. But there are dozens of modes in common use now including TV, digital data, digital voice, FM, and more coming on line every day. [Randaller] used CUDA to build a neural network that could interface with an RTL-SDR dongle and can classify the signals it hears. Since it is a neural network, it isn’t so much programmed to do it as it is trained. The proof of concept has training to distinguish FM, SECAM, and tetra. However, you can train it to recognize other modulation schemes if you want to invest the time into it.
Many automatic air fresheners are wasteful in that they either ceaselessly spritz the room, and manual ones need to be — well — manually operated. This will not do in an era of smart products, so Instructables user [IgorF2] has put together an air freshener that does more than check if you’re around before freshening things up.
The air freshener uses a NodeMCU LoLin and an MG 995 servomotor, with a NeoPixel ring acting as a status light. Be aware — when the servo is triggered there is a significant spike in current, so be sure you aren’t powering the air freshener from a PC USB port or another device. After modeling the air freshener’s case in Fusion 360 — files available here — [IgorF2] wired the components together and mounted them inside the 3D printed case.
Hardware work completed, [IgorF2] has detailed how to set up the Arduino IDE and ESP8266 support for a first-time-user, as well as adding a few libraries to his sketch. A combination of an Adafruit.IO feed and ITTT — once again, showing the setup steps — handles how the air freshener operates: location detection, time specific spritzing, and after tapping a software button on your phone for those particularly lazy moments.
Readers who were firmly on Team Nintendo in the early 2000’s or so can tell you that there was no accessory cooler for the Nintendo GameCube than the WaveBird. Previous attempts at wireless game controllers had generally either been sketchy third-party accessories or based around IR, and in both cases the end result was that the thing barely worked. The WaveBird on the other hand was not only an official product by Nintendo, but used 2.4 GHz to communicate with the system. Some concessions had to be made with the WaveBird; it lacked rumble, was a bit heavier than the stock controllers, and required a receiver “dongle”, but on the whole the WaveBird represented the shape of things to come for game controllers.
Even if you’ve never seen a GameCube or its somewhat pudgy wireless controller, you’re going to want to read though the incredible amount of information [Sam] has compiled in his GitHub repository for this project.
Starting with defining what a signal is to begin with, [Sam] walks the reader though Fourier transforms, the different types of modulations, decoding packets, and making sense of error correction. In the end, [Sam] presents a final summation of the wireless protocol, as well as a simple Python tool that let’s the HackRF impersonate a WaveBird and send button presses and stick inputs to an unmodified GameCube.
Believe it or not, there are quite a few people out there who have purchased gun safes that can be remotely unlocked by Bluetooth. Now we can understand why somebody might think this was a good idea: the convenience of being able to hit a button on your phone and have your weapon available in the heat of the moment is arguably a big selling point for people who are purchasing something like this for home defense. But those with a more technical mind will likely wonder if the inherent risks of having your firearm (or other valuables) protected by a protocol that often relies on security by obscurity outweighs the convenience of not needing to enter in a combination on the keypad.
[Two Six Labs] has not publicly released the complete source code of the software demonstrated in their YouTube video for very obvious reasons, but the page on their site does go into fantastic detail on how they uncovered the multiple vulnerabilities that allowed them to write it. Even if you’re not the kind of person who would ever need a gun safe, the information contained in their documentation about analyzing Bluetooth communications is fascinating reading.
It was discovered that the PIN for the safe was actually being transmitted by the accompanying smartphone application in plain-text, which would be bad enough normally. But after further analysis, it became clear that the safe wasn’t even bothering to check the PIN code anyway.
Scripting app interactions with ADB and Python
For extra style points, [Two Six Labs] also show a way to brute force the PIN using the Vaultek Android application by writing a Python script that punches in codes sequentially until it hits on the right one; the developers didn’t even bother to put in limits on failed attempts.
For a device that is ostensibly designed to contain a deadly weapon, the security flaws the team at [Two Six Labs] discovered are absolutely inexcusable. But there is a positive outcome, as the manufacturer has vowed to update the vulnerable safes and make a better effort in the future to more rigorously design and test their Bluetooth implementation. This is the goal of responsible disclosure, and we’re encouraged to see the manufacturer doing the right thing
