When you create a Thing for the Internet of Things, you’ve made a little computer that does a simple job and which probably has a minimal interface. But minimal interfaces leave little room for configuration, such as entering WiFi details. Perhaps if you made the Thing yourself you’ve hard-coded your WiFi credentials in your code, but that hardly translates to multiple instances. So, how to put end-user WiFi credentials easily on more than one Thing? Perhaps [Rob Dobson] has the answer with his technique of sending them as a sequence of audible tones.
There is a piece of Javascript code in a browser into which you enter your WiFi credentials, which are then expressed through the speaker as a set of FSK tones to be picked up by a microphone on the Thing. They can then be decoded into the credentials, and the Thing can connect. All the code is available, on GitHub, should you fancy it yourself.
Of course, this is nothing new, as any owner of an 8-bit machine that had a cassette interface will tell you. And on the face of it it’s much easier than those awkward impromptu hotspots with a web interface to which you connect and pass on your credentials. But while we quite like the convenience, we can’t help wondering whether expressing the credentials in audible free space might be a bit too insecure for many readers. The technique however remains valid, and we’re sure that other less sensitive applications might be found for it. Meanwhile we hope he hasn’t inadvertently shared his WiFi password in the video below the break.
If you’re like us, you probably spend more time browsing Reddit than you’d like to admit to your friends/family/boss/therapist. A seemingly endless supply of knowledge, wisdom, and memes; getting stuck on Reddit is not unlike looking something up on Wikipedia and somehow managing to spend the next couple hours just clicking through to new pages. But we’re willing to bet that none of us love browsing Reddit quite as much as [Saad] does.
He writes in to tell us about the handheld device he constructed which lets him view random posts from the popular /r/showerthoughts sub. Each press of the big red button delivers another slice of indispensable Internet wisdom, making it a perfect desk toy to fiddle with when you need a little extra push to get you through the day. Like one of those “Word a Day” calendars, but one that you’ll actually read.
For those curious as to how [Saad] is scraping Reddit with an Arduino, the short answer is that he isn’t. Posts are pulled from Reddit using an online tool created for the project by his wife (/r/relationshipgoals/), and dumped into a text file that can be placed on the device’s SD card. With 1500 of the all-time highest rated posts from /r/showerthoughts onboard, he should be good on content for awhile.
[Saad] has done an excellent job documenting the hardware side of this build, providing plenty of pictures as well as a list of the parts he used and a few tips to help make assembly easier. Overall it’s not that complex a project, but his documentation is a big help for those who might not live and breathe this kind of thing.
For the high-level summary: it uses an Arduino Pro Mini, a ILI9341 screen, and a 3.3 V regulator to step down 5 V USB instead of using batteries. A bit of perfboard, a 3D printed case, and a suitably irresistible big red button pulls the whole thing together.
There’s a lot going on our virtual spaces, and anyone with a smart phone can attest to this fact. There are pop-up notifications for everything you can imagine, and sometimes it’s possible for the one really important notification to get lost in a sea of minutiae. To really make sure you don’t miss that one important notification, you can offload that task to your own personal dinosaur.
The 3D-printed dinosaur has a rack-and-pinion gear set that allows it to extend upwards when commanded. It also has a set of LEDs for eyes that turn on when it pops up. The two servos and LEDs are controlled by a small Arduino in the base of the dinosaur. This Arduino can be programmed to activate the dinosaur whenver you like, for an email from a specific person, a reply to a comment on Reddit, or an incoming phone call to name a few examples. Be sure to check out the video below the break.
If you are of a certain age, you probably learned to program in Basic. Even if you aren’t, a lot of microcontroller hobbyists got started on the Basic Stamp, and there are plenty of other places where to venerable language still hides out. But if you want to write cool browser applications, you have to write JavaScript, right? Google will now let you code your web pages in Basic. Known as WWWBasic, this is — of course — a Javascript hack that you can load remotely into a web page and then have your page use Basic for customization. You can even import the thing into Node.js and use Basic inside your JavaScript, although it is hard to think of why you’d want to.
According to the project’s documentation — which is pretty sparse so far, we’re afraid — the Basic program is compiled into JavaScript on page load. There are a few examples, so you can generally pick up what’s available to use. There are graphics, the ability to read a keyboard key, and a way to handle the mouse.
If you like to rely on the web to do your electronics and computer math, you’ll want to bookmark FxSolver. It has a wide collection of formulae from disciplines ranging from electronics, computer science, physics, chemistry, and mechanics. There are also the classic math formulations, too.
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.
Triangulated location of “The Buzzer”
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.
2 Bit Cover Art
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.