Bluetooth keyboard bridge makes any I2C device think it's a BlackBerry

Bluetooth on a keyboard stops being a novelty the moment it can masquerade as something your firmware already understands. That is the promise of bt2i2c: flash a Raspberry Pi Pico W, pair it with a standard Bluetooth keyboard, and the device on the other end sees a familiar BlackBerry-style I2C input stream instead of a brand-new problem.

For mechanical-keyboard builders, that is the real win. It is not just about getting keypresses onto a bus, it is about preserving existing code, avoiding rewrites, and making custom handhelds, writerdecks, and embedded text devices easier to ship from parts you can actually source.

Why an I2C keyboard bridge matters

I2C keyboards already exist, but they have a reputation for being a little pokey, and they are not always the cleanest fit for a build that started life around a Bluetooth board. bt2i2c takes a different route by acting as a translation layer instead of a new keyboard design. That gives you the convenience of wireless input on one side and a bus your firmware stack may already know how to read on the other.

The practical value shows up fast in niche projects. If your device only needs a handful of buttons, or if your layout is built around a BlackBerry-style input protocol, a bridge like this can be the difference between plugging in and rewriting everything. It is especially appealing in small form factor builds where every extra wire, header, and custom driver adds friction.

How bt2i2c talks to the host

The core idea is simple but elegant: bt2i2c is a BLE HID keyboard to Pico W to I2C to Host bridge. It connects to a standard Bluetooth keyboard, then forwards keystrokes over I2C as a slave using the standard i2c_puppet register protocol. On the host side, it emulates a BBQ20-compatible keyboard endpoint at address 0x1F.

That compatibility trick matters more than it sounds like it should. If your downstream software already knows how to talk to a BBQ20 or BBQ10-style keyboard, the bridge does not force you to invent a new input layer. It presents itself as an existing device class, which is exactly the kind of hack embedded developers and keyboard tinkerers love: small, specific, and immediately useful.

There is also an optional ST7789 display that can be attached over SPI to show connection status. For a text-focused build, that is a smart quality-of-life addition because it tells you whether the keyboard link is alive before you start typing into a microcontroller-powered device that may have little else on screen.

What this unlocks in real builds

The most obvious beneficiaries are writerdecks, custom handhelds, and other DIY systems that already speak BlackBerry-style input. If you have code written for an I2C keyboard endpoint, bt2i2c lets you keep that code and swap in Bluetooth at the front end. That means less time porting input stacks and more time refining the actual device experience.

It also changes the design tradeoff. Instead of choosing between a wired keyboard path and a full Bluetooth stack inside your main controller, you can isolate the Bluetooth work to a low-cost bridge board. For projects where compatibility is more important than shaving every component from the schematic, that is a clean way to keep the rest of the build simple.

A few practical points stand out immediately:

• Latency: direct I2C keyboards can feel sluggish, so a bridge only makes sense when the convenience of Bluetooth and compatibility outweigh the cost of one more translation hop.

• Compatibility: the big advantage is reuse. If your firmware already understands a BBQ20-compatible endpoint, the bridge slots in with far less rewriting.

• Power and complexity: a Pico W adds a radio and a second controller to the chain, so it is best used where the flexibility is worth that overhead.

Why the BlackBerry keyboard path already feels familiar

bt2i2c is not inventing a brand-new ecosystem from scratch. BlackBerry keyboard hardware has already been reused in a steady stream of hobby projects, and that history makes the bridge feel like a natural next step rather than a stunt.

Solder Party’s BBQ20KBD board uses the Raspberry Pi RP2040 MCU to poll the keyboard and trackpad, then places keypress information into a FIFO. Its I2C interface can be used to read that FIFO, reconfigure the chip, and even change the keyboard backlight. That same product line also adds USB HID keyboard and mouse support, along with an injection-molded clear plastic case that gives the board a polished finish instead of a bare dev-board look.

CircuitPython documentation adds another important detail: the BB Q20 keyboard’s I2C interface is compatible with the older BBQ10 module, so the same libraries can be reused. That kind of continuity is exactly what makes a BlackBerry-shaped input endpoint attractive in the first place. It gives builders a known target and a stable software path instead of an endless cycle of one-off glue code.

The community around these boards is broad too. The BB Q20 keyboard with trackpad is based on an RP2040 MCU, and the hardware has shown up in builds using CircuitPython, Arduino, a Raspberry Pi kernel module, and even a tiny USB keyboard project running QMK firmware. That history explains why a bridge that pretends to be a BBQ20 at 0x1F is so effective. It plugs into an established habit pattern in the maker world.

Where the firmware landscape fits in

The wider firmware picture also helps explain why this project lands at the right moment. ZMK Firmware’s Bluetooth features are built around Bluetooth Low Energy, and they are a natural fit for wireless keyboards and split halves. QMK Firmware, by contrast, has historically had more limited and hardware-specific Bluetooth support, which is why many builders prefer a dedicated wireless stack when they want radio input to behave reliably.

The Pico W makes that bridge more accessible. Raspberry Pi says the board supports Bluetooth in both MicroPython and C, which gives small projects a low-cost controller that can speak Bluetooth on one side and I2C on the other. That combination is the enabling detail behind bt2i2c: a compact MCU can now sit between a modern wireless keyboard and a legacy-friendly input bus.

That is why this project feels bigger than a clever demo. It lets a Bluetooth keyboard walk into an I2C world and be mistaken for a BlackBerry, which is exactly the kind of compatibility hack that keeps custom keyboard builds moving without forcing every project to become its own firmware rewrite.