Ryan Ranjitkar Speaker Project

Modular Bluetooth Speaker

Overview

The goal of this project is to build a rechargeable Bluetooth speaker that is low power, reliable, and has physical knobs for control. The bigger idea is making it modular: the speaker has an expansion interface so you can snap on extra components and turn it into other things, like a guitar pedal, an amp, or a rig where you plug in an instrument and play along with music streaming from your phone.

Project Goals

• Rechargeable, battery powered Bluetooth speaker with an emphasis on low power draw
• Physical knobs and switches on the unit itself
• A modular design where add-on components connect through pogo pins to the main MCU. Planned modules:
  • Guitar pedal / effects module
  • Instrument input so you can play along with streamed music
  • Amp module

Work Completed

So far the work has been research. I looked into what actually goes into building a speaker, what separates good parts from cheap junk, and which components would fit a low power battery powered design. I also spent time figuring out how the modular part should work, and landed on pogo pins as the connection between modules and the main MCU.

What Makes a Good Speaker

Things I learned while researching speaker design:

• The driver matters more than anything else in the audio path. Bigger drivers move more air and produce better bass, but they eat more power and need a bigger enclosure. A single full-range driver keeps things simple (no crossover), while a woofer + tweeter setup sounds better but adds cost, complexity, and power draw.
• The enclosure is almost as important as the driver. Sealed boxes give tighter bass but are less efficient. Ported boxes get more bass out of the same power but sound boomy if the tuning is off. A flimsy enclosure that flexes or rattles will ruin the sound no matter how good the driver is. A lot of small portable speakers use passive radiators instead of a port, which gets you similar bass extension in less space without port noise.
• Sensitivity (dB of output per watt in) matters a lot for battery life. A more sensitive driver plays just as loud on less power.
• The amp has to match the driver. Impedance should match (usually 4 or 8 ohms), and power should be in the right range. Too little power and the amp clips, which sounds bad and can actually damage the driver. Too much and you're wasting battery headroom.
• Distortion specs (THD) are often measured at low volume to make the numbers look good. What matters is how clean the output is at the volume you'll actually listen at, so I compared THD at realistic output levels.

Hardware Tradeoffs

• Class D vs Class AB amps: Class D is the obvious pick for battery power. It runs around 85-95% efficient vs maybe 50-60% for Class AB, which directly means longer battery life and less heat. The downside is switching noise and EMI, so the PCB layout and output filter need some care. Class AB is still common in guitar amps because of its analog character, which might matter for the amp module later.
• Battery: lithium-ion has the best energy density but needs protection circuitry and a charging IC. A single cell is simpler to charge but needs a boost converter to get enough voltage for the amp. Multiple cells give the amp more headroom but then you need cell balancing. Charging over USB-C is basically expected at this point even though it adds cost.
• DAC/codec: the DACs built into most Bluetooth chips are fine but not great. An external I2S codec gets better signal to noise and also gives us the analog input path we need for the instrument module. Costs board space and power.
• Pogo pins: I picked pogo pins for the expansion interface because they're tool-free, self-aligning, and keep the main enclosure sealed (no open sockets collecting pocket lint). The downsides: each pin only carries so much current, so power to modules has to be spread across several pins, and you need magnets or a mechanical latch to keep contact. They cost more than plain headers but survive way more connect/disconnect cycles.
• Knobs: regular analog pots are cheap and feel good, but the firmware can't read or change them. Rotary encoders cost a bit more and need debouncing, but the MCU reads them, which means the same knob can control different things depending on what module is attached. That fits the modular idea much better.

Software Tradeoffs

• Codec: since we're going the LE Audio route (see MCU section), the codec is LC3. It sounds better than SBC (the A2DP baseline) at lower bitrates and uses less power. The catch is that the phone has to support LE Audio, covered below.
• Latency: normal Bluetooth audio has 100-200+ ms of latency. Fine for listening to music, completely unusable for playing guitar through it. This forced a real architecture decision: the instrument signal never goes over Bluetooth. It stays analog / local DSP on the device, so the player hears themselves instantly, mixed with the (slightly delayed) streamed music. LE Audio latency is much better than A2DP but the instrument path staying local is still the right call.
• DSP: EQ, compression, and bass enhancement can make a small driver sound way bigger than it is, but it costs CPU and power. Fixed point DSP is more efficient, floating point is easier to write. Whatever MCU we use needs headroom left over for this.
• RTOS vs bare metal: an RTOS makes it much easier to juggle the Bluetooth stack, audio, battery monitoring, and knob inputs at the same time. Nordic's ecosystem is built on Zephyr so that's what we'd use. Bare metal is leaner but would get painful once module hot-plug detection and multiple audio paths are in the mix.
• Power management in firmware matters as much as the hardware choices: sleep when idle, auto-shutoff, kill the LEDs, etc. The risk is audible pops/artifacts when waking the audio path back up.
• Module discovery: modules need to tell the main unit what they are. The cheap way is an ID resistor read by an ADC pin. The better way is an I2C bus where each module has a small EEPROM identifying itself. I2C costs each module a little bit of logic but supports much more capable modules down the road, so that's the direction.

MCU Selection and Module Architecture

Main Unit MCU

The main MCU has to handle Bluetooth audio, mixing, battery monitoring, the knobs, and module detection. Options I looked at:

• Nordic nRF5340 / nRF54H20 (what I'm going with): Nordic's chips have the best low power BLE around, which is the whole point of this project. They're BLE only, no Bluetooth Classic radio, so audio streaming happens over Bluetooth LE Audio with the LC3 codec instead of old-school A2DP. Nordic has an official reference design for exactly this (the nRF5340 Audio DK) with working LE Audio firmware. LE Audio also gets us better quality per bitrate and lower latency than A2DP, which helps the play-along use case. The nRF5340 has two Cortex-M33 cores so the radio stack and the audio/control code stay separated, and the newer nRF54H20 has a lot more horsepower if the mixing/DSP load needs it. Everything runs on Zephyr.
• ESP32 (original dual core): the usual hobbyist Bluetooth speaker chip, and one of the only cheap MCUs with Bluetooth Classic and A2DP. Tons of reference designs. I'm not using it because idle power is worse and it's built around the legacy protocol, but it's the fallback if phone compatibility ends up mattering more than power.
• Commercial Bluetooth audio SoCs (Qualcomm QCC, Actions, BES): these are in most real Bluetooth speakers, but the dev tools and documentation are basically unavailable to individuals, so not realistic for this project.

The tradeoff to be upfront about: LE Audio needs support on the phone side. Recent Android flagships (Pixel 8 and up, newer Samsung and Xiaomi phones) can stream over LE Audio. iPhones cannot, as of 2026. Apple hasn't turned on LE Audio streaming in iOS even on hardware that technically supports LC3. An iPhone can still connect to the nRF chip over regular BLE, so a companion app for EQ or module settings would work fine, but the speaker won't show up as an audio output on an iPhone. I'm accepting that limitation as a bet on where Bluetooth audio is going. If it becomes a dealbreaker, the fix is a hybrid design: keep the nRF as the system controller and add a separate Bluetooth Classic receiver chip for older sources.

Bottom line: nRF5340 (or nRF54H20) with LE Audio, plus an external I2S codec for audio quality and the analog instrument input.

MCUs for Each Module

Not every module needs a brain. Here's how it breaks down:

• Amp module: it's basically all analog power hardware. No processor needed. A small I2C EEPROM for identification is enough, and the main MCU controls gain digitally. If it ever needs local logic (like protection monitoring), a tiny STM32G0 or nRF54L class chip is plenty.
• Instrument input module: mostly analog front end (preamp, impedance matching) feeding into the main unit's codec. The mixing can happen on the main nRF since the instrument signal never touches Bluetooth, so latency isn't an issue. A local MCU is optional. If we wanted one for headroom, the RP2350 is a good cheap pick and its PIO blocks handle I2S nicely.
• Guitar pedal / effects module: this is the one that genuinely needs its own processor. Real-time effects (reverb, delay, amp modeling) need floating point DSP and consistent low latency that the main MCU can't guarantee while also running a Bluetooth stack. The best fit is an STM32H7, and the easiest way to get one is the Electrosmith Daisy Seed (STM32H750 at 480 MHz with hardware floating point). It's built specifically for audio effects and there's a whole DIY pedal community around it. Effects run entirely on the module and the processed analog signal goes back to the main unit for mixing.

Does Every Module Need Its Own MCU?

No. The plan is a split between dumb modules and smart modules:

• Dumb modules (amp, basic instrument input) just carry an ID EEPROM on the shared I2C bus plus analog signal lines. Cheap, no standby drain, and no firmware to maintain.
• Smart modules (the effects pedal, and anything future that needs real processing) carry their own MCU/DSP and show up to the main unit as an I2C device plus an analog audio insert point.

Putting an MCU in every module would mean more cost, more standby power, and multiple firmware images to keep updated. There's also a sneaky technical reason to keep audio between the main unit and modules analog: passing clock-synced digital audio (I2S) across pogo pins is fragile, and analog sidesteps the whole clocking problem. Where a module does earn its own processor, it pays off by taking load off the main MCU and letting the module be developed and updated on its own.

Future Work

• Finalize component selection and put together a full parts list
• Prototype the core speaker (audio path, LE Audio streaming, battery charging)
• Test LE Audio streaming from a real Android phone to the nRF5340 Audio DK
• Design and test the pogo pin expansion interface
• Build the first modules (instrument input, then the effects pedal)

WPI Student Contributors

• 2026: Ryan Ranjitkar

External Links

NA for now