Superheterodyne Radios Explained

The general public thinks there is one thing called a radio. Sure, they know there are radios that pick up different channels, but other than that, one radio is pretty much like the other. But if you are involved in electronics, you probably know there are lots of ways a radio can work internally. A crystal set is very different from an FM stereo, and that’s different still from a communications receiver. We’d say there are several common architectures for receivers and one of the most common is the superheterodyne. But what does that mean exactly? [Technology Connection] has a casual explanation video that discusses how a superhet works and why it is important. You can see the video, below.

Engineering has always been about building on abstractions. This is especially true now when you can get an IC or module that does most of what you want it to do. But even without those, you would hardly start an electronics project by mining copper wire, refining it, and drawing your own wire. You probably don’t make many of your own resistors and capacitors, neither do you start your design at the fundamental electronic equations. But there’s one abstraction we often forget about: architecture. If you are designing a receiver, you probably don’t try to solve the problem of radio reception; instead you pick an architecture that is proven and design to that.

Continue reading “Superheterodyne Radios Explained”

35C3: Finding Bugs In Bluetooth

[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.

In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.

As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the address handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.

All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.

Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.

You might know [Jiska] from her previous FitBit hack. If not, be sure to check it out.

Continue reading “35C3: Finding Bugs In Bluetooth”

RFID Doing More Than ID

RFID is a workhorse in industrial, commercial, and consumer markets. Passive tags, like work badges and key fobs, need a base station but not the tags. Sensors are a big market and putting sensors in places that are hard to reach, hostile, or mobile is a costly proposition. That price could drop, and the sensors could be more approachable with help from MIT’s Auto-ID Lab who are experimenting with sensor feedback to RFID devices.

Let’s pretend you want to measure the temperature inside a vat of pressurized acid. You’d rather not drill a hole in it to insert a thermometer, but a temperature sensor sealed in Pyrex that wirelessly transmits the data and never runs out of power is a permanent and cheap solution. The researchers have their sights set on glucose sensing and that news come shortly after Alphabet gave up their RFID quest to measure glucose through contact lenses. Shown the top of this article is a prototype for a Battery Assisted Passive (BAP) RFID sensor that uses commodity glucose testing strips, sending data when the electrochemical reaction occurs. It uses six of these cells in parallel to achieve a high enough peak current to trigger the transmission. But the paper (10.1109/RFID.2018.8376201 behind paywall) mentions a few strategies to improve upon this. However, it does prove the concept that the current spike from the test strips determines the time the tag is active and that can be correlated to the blood glucose detected.

How many of our own projects would instantly upgrade with the addition of a few sensors that were previously unobtainable on a hacker budget? Would beer be brewed more effectively with more monitoring? How many wearables would be feasible with battery-free attachments? The sky is the figurative limit.

Thank you, [QES] for the tip [via TechXplore]

Pushbutton → Push Notification

How many mundane devices upgrade to IoT because they let you monitor a single data point or a variable? That little nudge over the communication precipice allows you to charge 500% more. Now, if you are as handy as a Hackaday reader, you can throw a lazy afternoon at the problem and get the same effect from a “dumb” appliance. If IoT is as simple as getting a notification when your laundry is dry, or your water is boiling, all you really need is a WiFi device and a push notification, right? Does it need to be more complicated than that? [Gianni] believes it is that simple (machine translation) and has built up an easy-to-implement version on Raspberry Pi, Arduino, and ESP8266.

[Gianni] leverages the aptly named Pushover (a paid app with a 1-week trial period) to convert your bits, bytes, words, or strings to a push notification. This idea is born of the desire for a home security system which doesn’t require constant monitoring but instead alerts you to problems. The minimum requirement you need is for your phone to chime with a notification saying, “Your front window sensor has been tripped.” Now it is time to launch your IP camera app or call someone nearby.

It’s not revolutionary, it may be the “Hello World” of IoT, but that is all some people need. The general idea is the same no matter the framework you want to use. For instance, if you Google Suite account, you can set up a chatroom just for your alert notifications; Google’s quickstart takes about 3 minutes to test it out in Python. The same setup is also available for Slack, and [Tom Nardi] did a guide for doing this with Discord. These tackle the receiving side, but the sending side is really flexible too — that MQTT broker you built could easily be the source of the alerts.

Build a handful of these in a weekend and keep them nearby to step up your next project to IoT status with a couple of solder joints. Maybe it will be a motion sensor for your own security system.

HD Video And Telemetry Link Uses Standard WiFi Hardware

[GlytchTech] decided to implement his own Digital Data Link (DDL) for his drone experiments, and by using a Raspberry Pi Zero and some open-source software, he succeeded in creating a mostly self-contained system that delivers HD video and telemetry using an Android phone as a display.

USB tethered Android phone used as a display and touch interface.

The link uses standard WiFi hardware in a slightly unusual way to create a digital data link that acts more like an analog system, with a preference for delivering low latency video and a graceful drop-off when signal quality gets poor. A Raspberry Pi Zero, Alfa NEH WiFi card, external antenna, battery, and a 3D printed enclosure result in a self-contained unit. Two are needed: one for each end of the link. One unit goes on the drone and interfaces to the flight controller, and the other is for the ground station.

A companion android app allows for just about any old Android phone to serve as video feed, on-screen display of telemetry data, and touchscreen interface.

The software is DroneBridge (GitHub repository) and it implements Wifibroadcast which uses WiFi radios, but without the usual WiFi functionality. A Raspberry Pi is the usual platform, but there’s also an ESP32 port. The software is capable of even more, but so far suits [GlytchTech]’s needs just fine, and he was able to refine his original Watch_Dogs-inspired hacking drone with it.

Tired Of Killing Houseplants? Try Using WiFi.

Here at Hackaday, we have to admit to neglecting a few houseplants in our time. Let’s face it… a cold, hard, thinking machine can care for our green friends better than you can. Why not team up? [cabuu]’s WiFi-enabled soil moisture sensor will do the trick in case you, too, want happy plants.

This is one of those projects which would have been much more difficult even five years ago, and really shows how lucky we are to have accessible technology at our fingertips. It’s conveniently constructed from off-the-shelf electronics modules, and nestled inside a 3D-printed case. The design is attractive as well as functional, showing the status LED and allowing access to the USB charging port.

The brain is a WeMos D1 mini, while a D1 battery shield and 14500 Li-ion battery supplies power. A key point of this build is the use of a capacitive moisture sensor, which doesn’t suffer the same long-term corrosion problems that destroy cheaper resistive probes. And no project is complete without an LED, so a WS2812 shows green for good, red for dry and blue for too wet. To extend battery life, the sensor supports a sleep mode, which tests the soil periodically, and presumably disables the LED.

Of course, if you’re a habitual plant-neglector, simply having a moisture probe won’t help; those can be as easy to ignore as the plant itself. That’s where WiFi comes in. [cabuu] wrote a Blynk app to monitor the sensor on a smartphone. The app shows current moisture levels and allows you to change the wet and dry warning thresholds. When the reading exceeds these levels, the app notifies you — this feature is the one that will keep your plants around.

Continue reading “Tired Of Killing Houseplants? Try Using WiFi.”

A Deep Dive Into Low Power WiFi Microcontrollers

The Internet of Things is eating everything alive, and the world wants to know: how do you make a small, battery-powered, WiFi-enabled microcontroller device? This is a surprisingly difficult problem. WiFi is not optimized for low-power operations. It’s power-hungry, and there’s a lot of overhead. That said, there are microcontrollers out there with WiFi capability, but how do they hold up to running off of a battery for days, or weeks? That’s what [TvE] is exploring in a fantastic multi-part series of posts delving into low-power WiFi microcontrollers.

The idea for these experiments is set up in the first post in the series. Basically, the goal is to measure how long the ESP8266 and ESP32 will run on a battery, using various sleep modes. Both the ESP8266 and ESP32 have deep-sleep modes, a ‘sleep’ mode where the state is preserved, a ‘CPU only’ mode that turns the RF off, and various measures for sending and receiving a packet.

The takeaway from these experiments is that a battery-powered ESP8266 can’t be used for more than a week without a seriously beefy battery or a solar panel. Run times are much longer with an open network as compared to a secured network, and that security eats up a ton of power: connecting to a secure network every now and again means your ESP might only run for a day, instead of a week.

There is another option, though: the ESP32. While the ’32 is vastly more powerful and more capable than the ESP8266, it also has a few improved features that help with power consumption. Importantly, there’s a bug in the ESP8266 where it drops into modem sleep instead of light sleep about half the time. This error was fixed in the ESP32, but all that power does come at a cost. On the whole, if you’re concerned about security, the ESP32 is slightly better, simply because it does the ‘security’ part of connecting to a WiFi network faster. This is really a remarkable amount of testing that’s gone into this write-up, so if you’re developing something battery-powered with any ESP, it’s well worth the read.