Portable Bluetooth speakers have joined the club of ubiquitous personal electronics. What was once an expensive luxury is now widely accessible thanks to a prolific landscape of manufacturers mass producing speakers to fit every taste and budget. Some have even become branded promotional giveaway items. As a consequence, nowadays it’s not unusual to have a small collection of them, a fertile field for hacking.

But many surplus speakers are put on a shelf for “do something with it later” only to collect dust. Our main obstacle is a side effect of market diversity: with so many different speakers, a hack posted for one speaker wouldn’t apply to another. Some speakers are amenable to custom firmware, but only a small minority have attracted a software development community. It doesn’t help that most Bluetooth audio modules are opaque, their development toolchains difficult to obtain.

So what if we just take advantage of the best parts of these speakers: great audio fidelity, portability, and the polished look of a consumer good, to serves as the host for our own audio-based hacks. Let’s throw the Bluetooth overboard but embrace all those other things. Now hacking these boxes just requires a change of mindset and a little detective work. I’ll show you how to drop an Arduino into a cheap speaker as the blueprint for your own audio adventures.

Directing the Hacker Mindset at Myriad Bluetooth Speakers

There’s way too many different speakers out there for one hack to rule them all. But by changing our Bluetooth speaker mindset from “it’s a reprogrammable computer” to “it’s an integrated collection of useful electronic components”, we turn market diversity into our ally.

Look at this from the perspective of Bluetooth speaker manufacturers: they want their Bluetooth speaker to stand out from competitors, and the most obvious way is in their selection of loudspeaker drivers. Surprising the customer with big sound from a little box is key for success, so each product can offer a unique combination for driving the audio, all housed inside an eye-catching enclosure that lets consumers tell one portable Bluetooth speaker from another.

Tailoring for loudspeaker selection has cascading effects through the rest of the system. For best sound, they will need matching audio amplifier modules, which will have their own power requirements, which dictates battery performance, and so on. Catering to these desires, components are excluded from the tightly integrated mystery black boxes. Fortunately for hardware hackers, such an architecture also makes components easy to reuse:

1. A rechargeable battery.
2. Ability to charge that battery from USB.
3. A low-power standby mode to monitor press of the power button.
4. Protecting battery from over-discharge.
5. A voltage regulator supplying battery power to the device.
6. An audio line-in jack.
7. Volume up/down control.
8. Amplifier and driver.

All of these are useful for projects, already neatly packaged in a mass-produced enclosure.

Putting Theory Into Practice With An Example

Now that we have a general background, let’s apply this concept to a specific example. But before we begin, an obligatory note in case it is not obvious to any beginners reading this: This activity very definitely voids the warranty (do it, it’s worth it!), and modern portable electronics use lithium chemistry batteries that can be dangerous if mistreated.

The Bluetooth speaker used in this example is a “Rugged Portable Bluetooth Speaker” sold by North American electronics retailer Best Buy under one of their house brands. A search of its FCC ID pointed to Lightcomm Technology Co. as the manufacturer. The “rugged” claim starts with a layer of soft rubber wrapped around its exterior. That plus reinforcements inside the case allows the speaker to absorb some level of abuse. I wanted to preserve this shock absorbing exterior and, thankfully, it was easy to open non-destructively. Even more care would be needed if it was a waterproof speaker (this one wasn’t) and moisture barriers need to be preserved. Alternatively, if the plan is to transfer the internals to another enclosure, the condition of the original box would not matter.

Once the circuit board has been extracted, the Bluetooth interface module should immediately stand out as the most sophisticated component sitting close to an antenna. A search for ATS2823 confirmed it is a module designed and sold for integration into Bluetooth audio products. Its MIPS M4K core and associated flash storage could be a promising start for firmware hacking, but the point of this example is to demonstrate how to hack a speaker utilizing existing firmware. So we will leave the module as-is.

Solder to the External Audio Input

The easiest way to pipe audio into this system is to pretend to be an external audio source. We want the system to believe we are connected via an audio cable plugged into the line-in jack, but for compactness we’d prefer to do this without using an actual cord. This approach is easy, nondestructive, and preserves the existing volume control mechanism. There are a lot of different ways to implement an audio jack, so some exploration with a multimeter will be required. We need to find the standardized contacts for: audio input left channel, right channel, and ground. (Wikipedia reference: “Phone connector (audio)“)

It’ll be a little tricker to decipher the plug detection scheme, as it is not standardized. In this particular example, there is a fourth pin that floats in the absence of an audio plug. When an audio plug is present, the pin is grounded. Soldering a wire to always ground that detection pin will keep this speaker constantly in “playing external audio” mode.

Or Connect To Amplifier Directly

An alternative approach is to bypass existing input and volume control, sending audio directly to the amplifier chip. To find this chip, we start with the voice coil wires and backtrack. It’ll likely be the largest component near those voice coil wires. Once the amplifier chip is found, consult the datasheet to find the input pins to cut free from the circuit and rewire for audio input that bypasses existing control.

But even if we wish to maintain existing volume control, it is still useful to locate the audio amplifier chip. It is the most power-hungry component on the circuit board, and peak power requirements for the system are dictated by the amount of power this amplifier will draw when playing loudly. Therefore it is half the puzzle of calculating our available power. This particular Bluetooth device uses a Mixinno MIX2052 chip sitting adjacent to the voice coil wire connector, with a peak power of 6 watts.

Tap Into Power Supply

The other half of the puzzle is the voltage regulator delivering power to the amplifier chip. Similar to how we look for our amplifier near our voice coil wires, we can look for our regulator sitting near inductors, capacitors, and diodes. Once the power module is found, read its data sheet to determine peak power output.

The power budget for our hack would be constrained by power figures for those two components. Most microcontrollers consume maximum power during bootup. So as long as the audio source stays quiet during this time, we would have a little extra power to support boot. Somewhere between the regulator and the amplifier is also the best place to tap power. It allows us to piggyback on the existing power management circuit that shuts down the amplifier when entering low power mode, cutting power to our hack at the same time.

In the case of this board, there was one prominent coil and a Techcode TD8208 step-up regulator was found next to it. Configured to deliver 5 volts, this regulator can deliver 1A and tolerate brief spikes not to exceed 2A. This wouldn’t be enough to feed a Raspberry Pi 4, but plenty for an Arduino Nano.

Repurpose Control Button

So far functionality for three of the four buttons on this speaker has been preserved: power, volume up, and volume down. The fourth button initiates Bluetooth pairing, or to pick up a phone call. We’re cutting BT out of the equation so this is no longer useful and can be repurposed.

On this speaker, SW4 is normally open and pulls to ground when pressed, making it trivial to reuse. I cut the trace leading to the Bluetooth interface module and soldered a wire so the switch now pulls an Arduino pin to ground when pressed.

Tuck Everything Back In

A few pieces of internal plastic reinforcements for ruggedness were cut away to create enough volume for an Arduino Nano inside this enclosure. It is no longer quite as rugged, but now it is far more interesting as a platform for sound hacks. To conclude this proof of concept, the Arduino Nano is using the Mozzi audio library to play the classic Wilhelm scream whenever our repurposed button is pressed.

Build Your Own Bleepy Bloopy Buzzy Box

What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.

There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the  shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.

Selecting Unpredictable Seeds

Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.

The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.

Noisy Hardware or a Jittery Clock

As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.

The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.

So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.

The subject of entropy and generating random numbers is one that has appeared on these pages many times. [Voja Antonic] made a in-depth study using uninitialized RAM as an entropy source for microcontrollers. If you have an insatiable appetite for understanding Linux entropy, we point you at [Elliot Williams]’ comprehensive examination of the subject.

[Arduino image: DustyDingo Public domain]

In a recent post, I talked about using the “Blue Pill” STM32 module with the Arduino IDE. I’m not a big fan of the Arduino IDE, but I will admit it is simple to use which makes it good for simple things.

I’m not a big fan of integrated development environments (IDE), in general. I’ve used plenty of them, especially when they are tightly tied to the tool I’m trying to use at the time. But when I’m not doing anything special, I tend to just write my code in emacs. Thinking about it, I suppose I really don’t mind an IDE if it has tools that actually help me. But if it is just a text editor and launches a few commands, I can do that from emacs or another editor of my choice. The chances that your favorite IDE is going to have as much editing capability and customization as emacs are close to zero. Even if you don’t like emacs, why learn another editor if there isn’t a clear benefit in doing so?

There are ways, of course, to use other tools with the Arduino and other frameworks and I decided to start looking at them. After all, how hard can it be to build Arduino code? If you want to jump straight to the punch line, you can check out the video, below.

Turns Out…

It turns out, the Arduino IDE does a lot more than providing a bare-bones editor and launching a few command line tools. It also manages a very convoluted build process. The build process joins a lot of your files together, adds headers based on what it thinks you are doing, and generally compiles one big file, unless you’ve expressly included .cpp or .c files in your build.

That means just copying your normal Arduino code (I hate to say sketch) doesn’t give you anything you can build with a normal compiler. While there are plenty of makefile-based solutions, there’s also a tool called PlatformIO that purports to be a general-purpose solution for building on lots of embedded platforms, including Arduino.

About PlatformIO

Although PlatformIO claims to be an IDE, it really is a plugin for the open source Atom editor. However, it also has plugins for a lot of other IDEs. Interestingly enough, it even supports emacs. I know not everyone appreciates emacs, so I decided to investigate some of the other options. I’m not talking about VIM, either.

I wound up experimenting with two IDEs: Atom and Microsoft Visual Studio Code. Since PlatformIO has their 2.0 version in preview, I decided to try it. You might be surprised that I’m using Microsoft’s Code tool. Surprisingly, it runs on Linux and supports many things through plugins, including an Arduino module and, of course, PlatformIO. It is even available as source under an MIT license. The two editors actually look a lot alike, as you can see.

PlatformIO supports a staggering number of boards ranging from Arduino to ESP82666 to mBed boards to Raspberry Pi. It also supports different frameworks and IDEs. If you are like me and just like to be at the command line, you can use PlatformIO Core which is command line-driven.

In fact, that’s one of the things you first notice about PlatformIO is that it can’t decide if it is a GUI tool or a command line tool. I suspect some of that is in the IDE choice, too. For example, with Code, you have to run the projection initialization tool in a shell prompt. Granted, you can open a shell inside Code, but it is still a command line. Even on the PlatformIO IDE (actually, Atom), changing the Blue Pill framework from Arduino to mBed requires opening an INI file and changing it. Setting the upload path for an FRDM-KL46 required the same sort of change.

Is it Easy?

Don’t get me wrong. I personally don’t mind editing a file or issuing a command from a prompt. However, it seems like this kind of tool will mostly appeal to someone who does. I like that the command line tools exist. But it does make it seem odd when some changes are done in a GUI and some are done from the command line.

That’s fixable, of course. However, I do have another complaint that I feel bad for voicing because I don’t have a better solution. PlatformIO does too much. In theory, that’s the strength of it. I can write my code and not care how the mBed libraries or written or the Arduino tools munge my source code. I don’t even have to set up a tool chain because PlatformIO downloads everything I need the first time I use it.

When that works it is really great. The problem is when it doesn’t. For example, on the older version of PlatformIO, I had trouble getting the mBed libraries to build for a different target. I dug around and found the issue but it wasn’t easy. Had I built the toolchain and been in control of the process, I would have known better how to troubleshoot.

In the end, too, you will have to troubleshoot. PlatformIO aims at moving targets. Every time the Arduino IDE or the mBed frameworks or anything else changes, there is a good chance it will break something. When it does, you are going to have to work to fix it until the developers fix it for you. If you can do that, it is a cost in time. But I suspect the people who will be most interested in PlatformIO will be least able to fix it when it breaks.

Bottom Line

If you want to experiment with a different way of building programs — and more importantly, a single way to create and build — you should give PlatformIO a spin. When it works, it works well. Here are a few links to get you started:

• The PlatformIO IDE (requires Atom)
• PlatformIO Core (not needed if you install an IDE package)
• Visual Studio Code (install PlatformIO from within the IDE)

Bottom line, when it works, it works great. When it doesn’t it is painful. Should you use it? It is handy, there’s no doubt about that. The integration with Code is pretty minimal. The Atom integration — while not perfect — is much more seamless. However, if you learn to use the command line tools, it almost doesn’t matter. Use whatever editor you like, and I do like that. If you do use it, just hope it doesn’t break and maybe have a backup plan if it does.

Read the full article on MAKE