Radio direction finding is one of those things that most Hackaday readers are likely to be familiar with at least on a conceptual level, but probably without much first-hand experience. After all it’s not everyday that you need to track down a rogue signal, let alone have access to the infrastructure necessary to triangulate its position. But thanks to the wonders of the Internet, at least the latter excuse is now a bit less valid.
The RTL-SDR Blog has run a very interesting article wherein they describe how the global network of Internet-connected KiwiSDR radios can be used for worldwide radio direction finding. If you’ve got a target in mind, and the time to fiddle around with the web-based SDR user interface, you now have access to the kind of technology that’s usually reserved for world superpowers. Indeed, the blog post claims this is the first time such capability has been put in the hands of the unwashed masses. Let’s try not to mess this up.
To start with, you should have a rough idea of where the signal is originating from. It doesn’t have to be exact, but you want to at least know which country to look in. Then you pick one of the nearby public KiwiSDR stations and tune the frequency you’re after. Repeat the process for a few more stations. In theory the more stations you have the better, but technically three should be enough to get you pretty close.
With your receiving stations selected, the system will then start Time Difference of Arrival (TDoA) sampling. This technique compares the time the signal arrives at each station in relation to the KiwiSDR’s GPS synchronized clock. With enough of this data from multiple stations, it can estimate the origin of the signal based on how long it takes to reach different parts of the globe.
It’s not perfect, but it’s pretty impressive for a community run project. The blog post goes on to give examples of both known and unknown signals they were able to triangulate with surprising accuracy: from the US Navy’s VLF submarine transmitter in Seattle, Washington to the mysterious “Buzzer” number station hidden somewhere in Russia.
In 2017 Spotify finally deprecated their public vanilla C SDK library, libspotify, and officially replaced it with dedicated SDKs for iOS and Android and this new-fangled web thing we’ve all heard so much about. This is probably great for their maintainability but makes writing a native application for a Linux or a hardware device significantly harder, at least without an application process and NDA. Or is it? Instead of using that boring slab of glass and metal in their pocket [Dani] wanted to build a handy “now playing” display and remote control interface but was constrained by the aforementioned SDK limitations. So they came up with a series of clever optimizations resulting in the clearly-named ESP8266 Spotify Remote Control.
The Spotify Remote Control has a color LCD with a touchscreen. Once attached to a Spotify account it will show the album art of the currently playing track (with a loading indicator!) and let you play/pause/skip tracks from its touch screen, all with impressively low latency. To get here [Dani] faced two major challenges: authorizing the ESP to interact with a user’s Spotify account, and low latency LCD drawing.
If you’re not on iOS or Android, the Spotify web API is the remaining non-NDA’d interface available. But it’s really designed to be used on relatively rich platforms such as fully featured web browsers, not an embedded device. To that end, gone are the days of asking a user to enter their username and password in a static login box, the newer (better) way is to negotiate for a per-user token (which is individually authorized per application), then to use that to authenticate your interaction. With this regime 3rd party applications (in this case an ESP8266) never see a user’s password. One codified and very common version of this process is called OAuth and the token dance is called a “workflow”. [Dani] has a pretty good writeup of the process in their post if you want more detail about the theory. After banging out the web requests and exception handling (user declines to authorize the device, etc) the final magic ended up being using mDNS to get the user’s browser to redirect itself to the ESP’s local web server without looking up an IP first. So the setup process is this: the ESP boots and displays a URL to go to, the user navigates there on a WiFi connected device and operates the authorization workflow, then tokens are exchanged and the Remote Control is authorized.
The second problem was smooth drawing. By the ESP’s standards the album art for a given track at full color depth is pretty storage-large, meaning slow transfers to the display and large memory requirements. [Dani] used a few tricks here. The first was to try 2 bit color depth which turned out atrociously (see image above). Eventually the solution became to decompress and draw the album art directly to the screen (instead of a frame buffer) only when the track changed, then redraw the transport controls quickly with 2 bit color. The final problem was that network transfers were also slow, requiring manual timesharing between the download code and the display drawing routing to ensure everything was redrawn frequently.
Check out [Dani]’s video after the break, and take a peek at the sources to try building a Spotify Remote Control yourself.
The Border Gateway Protocol (BGP) is one of the foundations of the internet. It’s how the big routers that shift data around the Internet talk to each other, passing info on where they can send data to. It’s a simple protocol, with each router sending text messages that advertise the routes that they carry. The administrators of these routers create communities, each with an individual code, and this information is passed between routers. Most top-level ISPs don’t spread this data far, but [Ben Cox] realized that his ISP did. and that he could use this as an interesting way to transmit data over the Internet. What data to send? He decided to play battleships.
When you think of world-changing devices, you usually don’t think of the washing machine. However, making laundry manageable changed not only how we dress but how much time people spent getting their clothes clean. So complaining about how laborious our laundry is today would make someone from the 1800s laugh. Still, we all hate the laundry and [Andrew Dupont], in particular, hates having to check on the machine to see if it is done. So he made Laundry Spy.
How do you sense when the machine — either a washer or a dryer — is done? [Andrew] thought about sensing current but didn’t want to mess with house current. His machines don’t have LED indicators, so using a light sensor wasn’t going to work either. However, an accelerometer can detect vibrations in the machine and most washers and dryers vibrate plenty while they are running.
The four-part build log shows how he took an ESP8266 and made it sense when the washer and dryer were done so it could text his cell phone. He’d already done a similar project with an Adafruit HUZZAH. But he wanted to build in some new ideas and currently likes working with NodeMCU. While he was at it he upgraded the motion sensor to an LIS3DH which was cheaper than the original sensor.
[Andrew] already runs Node – RED on a Raspberry Pi, so incorporating this project with his system was a snap. Of course, you could adapt the approach to lots of other things, as well. The device produces MQTT messages and Node – RED subscribes to them. The Pushover handles the text messaging. Node – RED has a graphical workflow that makes integrating all the pieces very intuitive. Here’s the high-level workflow:
You might wonder why he didn’t just have the ESP8266 talk directly to Pushover. That is possible, of course, but in part 2, [Andrew] enumerates some good reasons for his design. He wants to decouple components in the system for easier future upgrades. And MQTT is simple to publish on the sensor side of things compared to API calls which are handled by the Raspberry Pi for now.
It was only a matter of time. Everything else is getting its data logged and reported to the Internet for detailed analysis, so why should our rodents be any different? The cover story is that [Nicole Horward] hooked her pet hamster Harold up to the web because she wanted to see if he was getting as much exercise as he should. The real reason is, of course, that Harold wanted to show off to his “friends” on Hamsterbook.
The hardware side of this hack is very simple, a magnetic door sensor (like the kind used in alarm systems) is used to detect each time the wheel makes a complete rotation. The sensor is hooked up to the GPIO pins of a Raspberry Pi, where it’s read by a Python script. A small LCD screen was added to give some visual feedback on Harold’s daily activity, and the whole thing was boxed up in a laser cut enclosure.
That gave [Nicole] a cute little display next to Harold’s cage, but it didn’t do much for analyzing his activity. For that, a script is used to upload the data every minute to a ThingSpeak channel via MQTT. This automatically generates attractive graphs from the raw data, making it much easier to visualize what’s happening over the long term.
The browser you are reading this page in will be an exceptionally powerful piece of software, with features and APIs undreamed of by the developers of its early-1990s ancestors such as NCSA Mosaic. For all that though, it will very probably be visually a descendant of those early browsers, a window for displaying two-dimensional web pages.
Some of this may be about to change, as in recognition of the place virtual reality devices are making for themselves, Mozilla have released Firefox Reality, in their words “a new web browser designed from the ground up for stand-alone virtual and augmented reality headset“. For now it will run on Daydream and GearVR devices as a developer preview, but the intended target for the software is a future generation of hardware that has yet to be released.
Readers with long memories may remember some of the hype surrounding VR in browsers back in the 1990s, when crystal-ball-gazers who’d read about VRML would hail it as the Next Big Thing without pausing to think about whether the devices to back it up were on the market. It could be that this time the hardware will match the expectation, and maybe one day you’ll be walking around the Hackaday WrencherSpace rather than reading this in a browser. See you there!
They’ve released a video preview that disappointingly consists of a 2D browser window in a VR environment. But it’s a start.
If you have not had children, stop reading now, we implore you. Because before you’ve had kids, you can’t know how supremely important it is that they take care of going to the bathroom by themselves. [David Gouldin] knows how it is. But unlike most of us, he resorted to using an Amazon IoT button and Twilio. No, we are not kidding.
The problem he was trying to solve is when his younger child would need to use the potty in the middle of the night, calling out for assistance would wake the older child. [David] said it best himself:
Behind the smiling emoji facade is an Amazon IoT button, a variant of Amazon’s dash button. When my kid presses this button, it triggers an AWS Lambda function that uses Twilio’s Python Helper Library to call my iPhone from a Twilio number. The Twilio number is stored in my contacts with “emergency bypass” turned on, so even when it’s 2am and I’m on “do not disturb” I still get the call.