The Wonderful World of USB Type-C

Despite becoming common over the last few years USB-C remains a bit of a mystery. Try asking someone with a new blade-thin laptop what ports it has and the response will often include an awkward pause followed by “USB-C?”. That is unless you hear “USB 3” or maybe USB 3.1. Perhaps even “a charging port”. So what is that new oval hole in the side of your laptop called? And what can it really do? [jason] at Reclaimer Labs put together a must-read series of blog posts in 2016 and 2017 plumbing the depths of the USB 3.1 rabbit hole with a focus on Power Delivery. Oh, and he made a slick Easy Bake Oven with it too.

A single USB Type-C connector

When talking about USB-C, it’s important to start at the beginning. What do the words “USB-C” entail? Unsurprisingly, the answer is complicated. “USB Type-C” refers only to the physical connector and detail about how it is used, including some of the 24 pins it contains. Then there are the other terms. “USB 3.1” is the overall standard that encompasses the Type-C connector and new high-speed data busses (“USB SuperSpeed” and “SuperSpeedPlus”). In addition there is “USB Power Delivery” which describes power modes and even more pin assignments. We’re summarizing here, so go read the first post for more detail.

The second post devotes a formidable 1,200 words to providing an overview of the electrical specifications, configuration communication, and connector types for USB 3.1.

A GIF of a flipping USB Type C connector
Marketing at its finest

The third post is devoted to USB Power Delivery. Power Delivery encompasses not only the new higher power modes supported (up to 100W!), but the ways to use the extra 10 or 13 pins available on the Type-C connector. This is both the boon and bane of USB-C, allowing apparently identical ports to carry common signals like HDMI or DisplayPort, act as analog audio outputs, and provide more exotic interfaces like PCIe 3.0 (in the form of Thunderbolt 3, which is a yet another thing this connector can be used for).

It should be clear at this point that the topics touched by “USB Type-C” are exceptionally complex. Save yourself the trouble of a 90MB specification zipfile and take a pass through [jason]’s posts to understand what’s happening. For even more detail about Power Delivery, he walks through sample transactions in a separate post.

Shoehorning A Slick Spotify Remote Into An ESP8266

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.

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

ESP8266 Home Computer Hides Unexpected Gems

With a BASIC interpreter and free run throughout their hardware, home computers like the ZX Spectrum and Commodore 64 used to be a pervasive way to light that hacker fire. With the advent of cheap single board computers like the Raspberry Pi, devices purpose built to emulate these classic systems have become fairly commonplace. [uli] built a device in this vein called the BASIC Engine which is driven by a microcontroller and a handful of hardware peripherals. Like other examples it can be attached to a keyboard, programmed in a BASIC, play video and sound, etc. But digging into the BASIC Engine reveals that it’s similarity to other devices is only skin deep.

The current version of the BASIC Engine (“rev2”) lives in a Raspberry Pi 3 case for convenience. It has RCA connectors for NTSC or PAL video output and mono audio, plus a bank of headers to tap into GPIOs, connectors for a keyboard, and more. [uli] wanted to aim for extreme low cost so a relatively beefy board like a Raspberry Pi didn’t fit the bill, and we expect it was an enjoyable challenge. Instead its interpreter runs atop an ESP8266 but with the networking stack removed. [uli] was disheartened by how bloated even a “Hello world” program was and ripped it out, discovering that hidden beneath was a very powerful and disproportionately inexpensive general purpose microcontroller. The video is driven by a VS23S010, sold as a 1 Mbit parallel SRAM with a neat trick; it also includes a composite video controller!

The real treat here is [uli]’s history writeup of how the BASIC Engine came to be. We’d recommend brewing a cup of coffee and sitting down for a full read-through. The first version was inspired by the PlayPower project, which was repurposing clones of Nintendo’s Famicom (NES to Americans) game console to make low cost home computers, complete with keyboard and gamepad input. [uli] started out by building a custom cartridge for a particular Famicom clone that ran a BASIC interpreter but after showing it to disinterested adults the project was left fallow. Years later, [uli] was encouraged to pick up the project again, leading down a twisted rabbit hole to where we are today.

If you want to build a BASIC Engine for yourself, Gerbers and build instructions are available on the pages linked above.

Thanks for the tip [antibyte]!

PIC Powered PicoBat Picks Up Pulsed Power

In 2012, [Bruno] wanted to detect some bats. Detect bats? Some varieties of bat (primarily the descriptively named “microbats”) locate themselves and their prey in space using echolocation, the same way your first robot probably did. The bat emits chirps from their adorably tiny larynx the same way a human uses its vocal cords to produce sound. The bat then listens for an echo of that sound and can make inferences about the location of its presumed prey in the volume around it. Bat detectors are devices which can detect these ultrasonic sounds and shift them into a range that humans can hear. So how would you build such a device? [Bruno]’s PicoBat probably sets the record for component count and code simplicity.

With no domain expertise the most conspicuous way to build a bat detector is probably to combine the glut of high performance microcontrollers with a similarly high performing analog to digital converter. With a little signal processing knowledge you sample the sounds at their native frequency, run them through a Fast Fourier transform, and look for energy in the ultrasonic frequency range, maybe about 20 kHz to 100 kHz, according to Wikipedia. With more knowledge about signal interference it turns out there are a surprisingly large number of ways to build such a device, including some which are purely analog. (Seriously, check out the Wikipedia page for the myriad ways this can be done.)

[Bruno] did use a microcontroller to build his bat detector, but not in the way we’d have expected. Instead of using a beastly high performance A/D and a similarly burly microcontroller, the PicoBat has a relatively tame PIC12 and a standard ultrasonic transducer, as well as a piezo buzzer for output. Along with a power rail, that’s the entire circuit. The code he’s running is similarly spartan. It configures a pair of GPIOs and toggles them, with no other logic. That’s it.

So how does this work? The ultrasonic transducer is designed mechanically to only receive sounds in the desired frequency range. Being piezoelectric, when enough sound pressure is applied the stress causes a small voltage. That voltage is fed into the PIC not as a GPIO but as a clock input. So the CPU only executes an instruction when ultrasonic sound with enough intensity hits the transducer. And the GPIO toggling routine takes four clock cycles to execute, yielding a 1:4 clock divider. And when the GPIOs toggle they flip the potential across the buzzer, causing it to make human-audible sound. Brilliant!

Check out [Bruno]’s video demo after the break to get a sense for how the device works. You might be able to do this same trick with other components, but we’re willing to be that you won’t beat the parts count.

Continue reading “PIC Powered PicoBat Picks Up Pulsed Power”

Buttery Smooth Fades with the Power of HSV

In firmware-land we usually refer to colors using RGB. This is intuitively pleasing with a little background on color theory and an understanding of how multicolor LEDs work. Most of the colorful LEDs we are use not actually a single diode. They are red, green, and blue diodes shoved together in tight quarters. (Though interestingly very high end LEDs use even more colors than that, but that’s a topic for another article.) When all three light up at once the emitted light munges together into a single color which your brain perceives. Appropriately the schematic symbol for an RGB LED without an onboard controller typically depicts three discrete LEDs all together. So it’s clear why representing an RGB LED in code as three individual values {R, G, B} makes sense. But binding our representation of color in firmware to the physical system we accidentally limit ourselves.

The inside of an RGB LED

Last time we talked about color spaces, we learned about different ways to represent color spatially. The key insight was that these models called color spaces could be used to represent the same colors using different groups of values. And in fact that the grouped values themselves could be used to describe multidimensional spacial coordinates. But that post was missing the punchline. “So what if you can represent colors in a cylinder!” I hear you cry. “Why do I care?” Well, it turns out that using colorspace can make some common firmware tasks easier. Follow on to learn how!

Continue reading “Buttery Smooth Fades with the Power of HSV”

A Close Eye on Power Exposes Private Keys

Hardware wallets are devices used exclusively to store the highly sensitive cryptographic information that authenticates cryptocurrency transactions. They are useful if one is worried about the compromise of a general purpose computer leading to the loss of such secrets (and thus loss of the funds the secrets identify). The idea is to move the critical data away from a more vulnerable network-connected machine and onto a device without a network connection that is unable to run other software. When designing a security focused hardware devices like hardware wallets it’s important to consider what threats need to be protected against. More sophisticated threats warrant more sophisticated defenses and at the extreme end these precautions can become highly involved. In 2015 when [Jochen] took a look around his TREZOR hardware wallet he discovered that maybe all the precautions hadn’t been considered.

Continue reading “A Close Eye on Power Exposes Private Keys”

An Electromagnet Brings Harmony to this Waving Cat

We’ve noticed waving cats in restaurants and stores for years, but even the happy bobbing of their arm didn’t really catch our attention. Maybe [Josh] had seen a couple more than we have when it occurred to him to take one apart to see how they work. They are designed to run indoors from unreliable light sources and seem to bob along forever. How do the ubiquitous maneki-neko get endless mechanical motion from one tiny solar cell?

Perhaps unsurprisingly given the prevalence and cost of these devices, the answer is quite simple. The key interaction is between a permanent magnet mounted to the end of the waving arm/pendulum and a many-turn wire coil attached to the body. As the magnet swings over the coil, its movement induces a voltage. A small blob of analog circuitry reacts by running current through the coil. The end effect is that it “senses” the magnet passing by and gives it a little push to keep things moving. As long as there is light the circuit can keep pushing and the pendulum swings forever. If it happens to stop a jolt from the coil starts the pendulum swinging and the rest of the circuit takes over again. [Josh] points to a similar circuit with a very nice write up in an issue of Nuts and Volts for more detail.

We’ve covered [Josh]’s toy teardowns before and always find this category of device particularly interesting. Toys and gadgets like the maneki-neko are often governed by razor-thin profit margins and as such must satisfy an extremely challenging intersection of product constraints, combining simple design and fabrication with just enough reliability to not be a complete disappointment.

For more, watch [Josh] describe his method in person after the break, or try flashing his code to an Arduino and make a waving cat of your own.

Continue reading “An Electromagnet Brings Harmony to this Waving Cat”