Shoehorning A Slick Spotify Remote Into An ESP8266

July 11, 2018 by Kerry Scharfglass 9 Comments

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.

Continue reading “Shoehorning A Slick Spotify Remote Into An ESP8266” →

Diode Recovery Time Explained

July 11, 2018 by Al Williams 19 Comments

There are at least two phases to learning about electronics. In the first phase, you learn about how components are supposed to work. In the second phase, you learn about how they really work. Wires have resistance and inductance. Adjacent wires have capacitance. Capacitors leak. Inductors have resistance. All of these things matter. [Learnelectronics] has a recent video that explores recovery time for a diode — a phase two conversation.

If you haven’t run into recovery time before, it is the amount of time the diode takes to shut off after it is conducting. This manifests itself as a little undershoot where the signal that the diode should block leaks through briefly.

Continue reading “Diode Recovery Time Explained” →

ERRF 18: Slice Engineering Shows Off The Mosquito

July 11, 2018 by Tom Nardi 26 Comments

With few exceptions, it seemed like every 3D printer at the first inaugural East Coast RepRap Festival (ERRF) was using a hotend built by E3D. There’s nothing inherently wrong with that; E3D makes solid open source products, and they deserve all the success they can get. But that being said, competition drives innovation, so we’re particularly interested anytime we see a new hotend that isn’t just an E3D V6 clone.

The Mosquito from Slice Enginerring is definitely no E3D clone. In fact, it doesn’t look much like any 3D printer hotend you’ve ever seen before. Tiny and spindly, the look of the hotend certainly invokes its namesake. But despite its fragile appearance, this hotend can ramp up to a monstrous 500 C, making it effectively a bolt-on upgrade for your existing machine that will allow you to print in exotic materials such as PEEK.

We spent a little time talking with Slice Engineering co-founder [Dan], and while there’s probably not much risk it’s going to dethrone E3D as the RepRap community’s favorite hotend, it might be worth considering if you’re thinking of putting together a high-performance printer.

Continue reading “ERRF 18: Slice Engineering Shows Off The Mosquito” →

SPIDriver Shows You What’s Going On

July 10, 2018 by Elliot Williams 17 Comments

When you’re debugging two bits of electronics talking SPI to each other, there’s a lot that can go sideways. Starting from the ground up, the signals can be wrong: data not synced with clocks right, or phase inverted. On top of that, the actual data sent needs to make sense to the receiving device. Are you sending the right commands?

When nothing’s working, you’re fighting simultaneously on these two fronts and you might need different tools to debug each. An oscilloscope works great at the physical layer, while something like a Bus Pirate or fancier logic analyzer works better at the data layer because it can do parsing for you. [James Bowman]’s SPIDriver looks to us like a Bus Pirate with a screen — giving you a fighting chance on both fronts.

SPIDriver also has a couple more tricks up its sleeve: a voltage and current monitor for the device under test, so you don’t even have to break out your multimeter when you’re experiencing random resets. We asked [James] if these additions had a sad history behind them. He included this XKCD.

Everything about SPIDriver is open, so you can check out the hardware design, browse the code, and modify any and all of it to your taste. And speaking of open, [James] is also the man behind the Gameduino and an amazing FPGA Forth soft-CPU.

It’s fully crowd-funded, but it closes in a couple of days so if you want one, get on it soon.

And if you want to learn more about SPI debugging, we’ve written up a crash-course. With the gear and the know-how, you at least stand a fighting chance.

A Peek Into A Weed-Eating Robot’s Test Fixtures

July 7, 2018 by Donald Papp 2 Comments

When it comes to production, fast is good! But right the first time is better. Anything that helps prevent rework down the line is worth investing in. Some of the best tools to catch problems are good test fixtures. The folks at Tertill (a solar-powered robot for killing weeds that kickstarted last year) took the time to share two brief videos of DIY test fixtures they use to test components before assembly.

The videos are short, but they demonstrate all the things that make a good test: on the motor tester there are no connectors or wires to fiddle with, the test starts automatically, and there is clear feedback via prominent LEDs. The UI board tester also starts automatically and has unambiguous LED feedback, and sports a custom board holder with a recess just the right shape for the PCB. Once the board is in, the sled is pushed like a drawer to make contact with the test hardware and begin the test. The perfectly formed recesses in both units serve another function as well; they act as a go/no-go test for the physical shape of the components and contacts being tested.

Both videos are embedded below; and while there isn’t much detail on the actual test hardware, we do spy a Raspberry Pi and at least two Adafruit logos among other hacker-familiar elements like laser-cut acrylic, 3D printed plastic, pogo pins, and a PVC junction box.

Continue reading “A Peek Into A Weed-Eating Robot’s Test Fixtures” →

Nintendo Switch Gets Internal Trinket Hardmod

July 1, 2018 by Tom Nardi 51 Comments

If you haven’t been following the Nintendo Switch hacking scene, the short version of the story is that a vulnerability was discovered that allows executing code on all versions of the Switch hardware and operating system. In fact, it’s believed that the only way to stop this vulnerability from being exploited is for Nintendo to release a new revision of the hardware. Presumably there are a lot of sad faces in the House of Mario right about now, but it’s good news for us peons who dream of actually controlling the devices we purchase.

To run your own code on Nintendo’s latest and greatest, you must first put it into recovery mode by shorting out two pins in the controller connector, and then use either a computer or a microcontroller connected to the system’s USB port to preform the exploit and execute the binary payload. It’s relatively easy, but something you need to do every time you shut the system down. But if you’re willing to install an Adafruit Trinket M0 inside your Nintendo Switch, you can make things a little easier.

Stemming from work done by [atlas44] and [noemu], the final iteration of this mod was created by [Quantum-cross]. The general idea is to strip down the Trinket M0 board to as small as possible by removing the USB port and a few capacitors, and then install it inside the Switch’s case. By wiring it up to power, the back of the USB-C connector, and the controller connector, the Trinket can interact with all the key components involved in the exploit.

You can even use the Switch’s USB port to update the firmware on the Trinket to load different payloads, though in his walkthrough video after the break, [xboxexpert] mentions eventually this won’t really be necessary as the homebrew software environment on the Switch matures. Indeed, there will almost certainly come a time when performing this exploit on every boot of the system will be made unnecessary, rendering this modification obsolete. But until then, this is a pretty slick way of getting your feet wet in the world of Switch hacking.

It was only six months or so back that we were reading about the first steps towards running arbitrary code on the Nintendo Switch, and just a few months prior to that we saw people experimenting with controlling the system with a microcontroller.

Continue reading “Nintendo Switch Gets Internal Trinket Hardmod” →

This Year, Badges Get Blockchains

June 28, 2018 by Brian Benchoff 11 Comments

This year’s hottest new advance in electronics comes through wearable badges. You can’t have failed to notice another technology that’s getting really hot. It’s the blockchain. What is a blockchain? It’s a linked list where every item in the list contains a cryptographic hash of the previous item in the list. What is a blockchain in English? It’s the most revolutionary technology that’s going to solve every problem on the planet, somehow. It’s the basis for crypto (no not that one, the other one). The blockchain is how you add more Lamborghinis to your Lamborghini account. Even though we’re still trying to figure out how it solves a single problem, one thing is certain: blockchains solve every problem. We were born too late to explore the Earth, born too early to explore the Universe, but just in time for blockchain.

Independent badges are always looking at the latest technology, and perhaps this was inevitable. It’s a badge built on the blockchain. It’s a wearable sneakernet of mining. It’s a game with collaborative proof of work.

The blockchain badge from [Mr Blinky Bling] is an independent badge for this year’s Defcon, and like most independent badges it’s loaded up with RGB LEDs, microcontrollers, and exquisitely crafted FR4. What makes this badge different is the add-ons, or ‘blocks’ that attach to the main badge through 1/8″ phono jacks. These blocks form the basis of the social game, where two badge holders trade blocks for a while, allow their badges to perform a proof of work on each block, and finally, each block is hashed and the score increased. Yes, this is a blockchain, but it’s more of a block-tree, and it runs on sneakernet instead of the Internet.

Yes, this does indeed all sound like a joke. Make no mistake, though: this is real. This is a hardware game built on blockchain technology, that some lucky badge holders will be playing at this year’s Defcon. It’s filled with blinky and blockchain. It’s awesome.

[Mr. Blinky Bling] has already started a project for this badge over on hackaday.io, and right now they’re running a Kickstarter campaign for this badge with delivery at Defcon. This is one of the more interesting badges that will be floating around the con this year, and it has blockchain. This really isn’t one to miss.