Smartphone App Uses AR To Visualize The RF Spectrum

January 9, 2019 by Dan Maloney 21 Comments

Have you ever wished you could see in the RF part of the radio spectrum? While such a skill would probably make it hard to get a good night’s rest, it would at least allow you to instantly see dead spots in your WiFi coverage. Not a bad tradeoff.

Unwilling to go full [Geordi La Forge] to be able to visualize RF, [Ken Kawamoto] built the next best thing – an augmented-reality RF signal strength app for his smartphone. Built to aid in the repositioning of his router in the post-holiday cleanup, the app uses the Android ARCore framework to figure out where in the house the phone is and overlays a color-coded sphere representing sensor data onto the current camera image. The spheres persist in 3D space, leaving a trail of virtual breadcrumbs that map out the sensor data as you warwalk the house. The app also lets you map Bluetooth and LTE coverage, but RF isn’t its only input: if your phone is properly equipped, magnetic fields and barometric pressure can also be AR mapped. We found the Bluetooth demo in the video below particularly interesting; it’s amazing how much the signal is attenuated by a double layer of aluminum foil. [Ken] even came up with an Arduino with a gas sensor that talks to the phone and maps the atmosphere around the kitchen stove.

The app is called AR Sensor and is available on the Play Store, but you’ll need at least Android 8.0 to play. If your phone is behind the times like ours, you might have to settle for mapping your RF world the hard way.

Continue reading “Smartphone App Uses AR To Visualize The RF Spectrum” →

Underclocking The ESP8266 Leads To WiFi Weirdness

January 4, 2019 by Tom Nardi 39 Comments

Sometimes the best hacks come from the most basic of questions. In this case, [CNLohr] was wondering what would happen if he started to reduce the clock speed of the ESP8266’s Baseband PLL (BBPLL) while still trying to communicate with it. You know, as one does. The results ended up being fairly surprising, and while it’s not immediately clear if there’s a practical application for this particular trick, it’s certainly worth some additional research.

The idea here is that the BBPLL is the reference clock for the entire system, including all of the peripherals. So underclocking it doesn’t just slow down code execution as you might expect, but it also slows down the chip’s interactions with the outside world. [CNLohr] demonstrates this concept in the video below, showing how the baud rate used to view the serial output from the ESP8266 needs to be adjusted to match the chip’s frequency or else you’ll only get garbage on the line.

But what happens to the WiFi? As [CNLohr] discovered, while the center frequency itself doesn’t change, the channel width gets narrower as the clock rate is lowered. When viewed on the waterfall display of a software defined radio (SDR), the transmission can be seen “compressing” in a step pattern as the clock rate is reduced. As one might expect, the 802.11 packets become indecipherable to a normal WiFi device running in monitor mode. The signal is still at the correct frequency, but the devices can no longer understand each other.

Now it was time for another of those basic questions. What would happen if you did the same thing to a second ESP8266? Much to his surprise, [CNLohr] discovered that the two devices could still communicate successfully as long as their BBPLL clock speed was the same. From an outsider’s perspective it looked like gibberish, but to the two ESPs which had been slowed by the same amount, everything worked as expected even though the 802.11 standards say it shouldn’t.

So what can you do with this? The most obvious application is a “stealth” WiFi connection between ESP8266s which wouldn’t show up to normal devices, a communications channel invisible to all but the most astute eavesdropper. [CNLohr] has made all the source code to pull this trick off public on GitHub, and it should be interesting to see what kind of applications (if any) hackers find for this standards-breaking behavior.

If your thing is devices being forced into operations they were never intended to by particularly twisted hackers, check out our recent coverage of the USB serial adapter turned SDR by [Ted Yapo].

Continue reading “Underclocking The ESP8266 Leads To WiFi Weirdness” →

Pi Zero Gives Amateur Astronomer Affordable Control Of Telescope

January 3, 2019 by Dan Maloney 18 Comments

Like many other hobbies, astronomy can be pursued on many levels, with equipment costs ranging from the affordable to the – well, astronomical. Thankfully, there are lots of entry-level telescopes on the market, some that even come with mounts that automatically find and track heavenly bodies. Finding a feature is as easy as aligning to a few known stars and looking up the object in the database embedded in the remote.

Few of the affordable mounts are WiFi-accessible, though, which is a gap [Dane Gardner]’s Raspberry Pi interface for Celestron telescopes aims to fill. For the price of a $10 Pi Zero W and a little know-how, [Dane] was able to gain full control over his ‘scope. His instrument is a Celestron NexStar, a Schmidt-Cassegrain reflector with a 150-mm aperture, has a motorized altitude-azimuth mount. The handheld remote had enough room for him to add the Zero, powering it from the mount’s battery pack. The handset has an RS-232 serial port built-in, but with the level differences [Dane] just connected the Pi directly to the handset before the UART. Running INDI, a cross-platform astronomical instrument control library, he now has total control of the scope, and he can use open source astronomy software rather than the limited database within the handset. As a neat side trick, the telescope can now be controlled with a Bluetooth gamepad.

Astronomy and electronics go hand in hand, whether in the optical or radio part of the spectrum. We like the way [Dane] was able to gain control of his telescope, and we’d like to hear about what he sees with his new tool. Assuming the Seattle weather ever cooperates.

Continue reading “Pi Zero Gives Amateur Astronomer Affordable Control Of Telescope” →

HD Video And Telemetry Link Uses Standard WiFi Hardware

December 27, 2018 by Donald Papp 3 Comments

[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.

Giving An Old Mac Spotify

December 21, 2018 by Brian Benchoff 15 Comments

The Macintosh SE/30 is the greatest computer ever made, and I’m not saying that just because I’m sitting on a cache of them, slowly selling them to computer collectors around the world. No, the SE/30 is so great because of how powerful it is, and how much it can be expanded. A case in point: here’s an SE/30 that’s a Spotify player. Oh, it does it over WiFi, too.

You might be asking yourself how a computer from 1989 (it’s late enough in the year that we can safely say this computer is thirty years old) can possibly play music over the Internet. While the SE/30 supported an astonishing 128 Megabytes of RAM, it’s still just a bit too slow to play MP3s or any modern audio codec. The 68030 CPU just wasn’t fast enough to play audio, to say nothing of streaming it over a network connection. The trick is that this SE/30 is simply a remote for Spotify Connect. You could theoretically get the Mac to speak, “Alexa, play Despacito” and get the same functionality, but that’s not fun, is it? You need to do it wirelessly.

This is a continuation of one of [ants] earlier hacks that basically put a WiFi to Ethernet bridge inside an SE/30. Tie that together with a Finder extension and you have System 7, with WiFi. That’s a connection to the Internet, but [ants] actual wrote an app to connect to a Spotify playlist, browse tracks, and display album art in beautiful 1-bit color. Writing the app involved dealing with OAuth, which means the MacPlayer isn’t entirely standalone; some of it must be done on a ‘modern’ device. This, along with porting a conversion utility that translates UTF-8 text encoding into something the Mac can understand ties everything together.

With all those pieces, the SE/30 becomes a handsome, functional piece of art. Apple is never going to release a computer like this again, and you’re not going to find a touchbar MacBook being used like this in thirty years time.

Tired Of Killing Houseplants? Try Using WiFi.

December 17, 2018 by Ted Yapo 50 Comments

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

December 17, 2018 by Brian Benchoff 39 Comments

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.