upgrading to a Taptic Engine (LRA) for premium clicks & speakerless audio

[thesohamdatta]

Hey everyone! 👋

I've been digging into the haptic code and current hardware setup in the repository, and I wanted to throw an idea out here for the next hardware iteration of Omi.

Right now, the Omi Consumer uses a standard 3V coin vibration motor (ERM). It works for simple buzzes, but it has that sluggish, spinning-mass feel that can make a device feel a bit like a buzzy toy rather than a premium AI companion.

What if we upgraded this to a Linear Resonant Actuator (LRA) driven by a dedicated TI DRV2605L haptic driver? It sounds fancy, but here is why it could be a game-changer for Omi's user experience—and why it's actually surprisingly easy to build.

---

The Cool Part: 2-in-1 Haptics + Speakerless Audio 🔊

An LRA is basically a voice-coil actuator. While it vibrates beautifully at its resonant frequency (delivering that satisfying Apple-style "click"), we can also drive it at higher frequencies (500 Hz to 2 kHz) to act as an acoustic transducer.

This means the Taptic Engine itself can emit clean, audible beeps, chimes, and alarms without us needing to add a physical speaker to the device. We get sound output for free with zero extra weight, cost, or enclosure changes!

We can use this to create a private, tactile language:

• A crisp double-click when the AI successfully commits a memory.
• A gentle, organic heartbeat pulse while the AI is thinking.
• A sharp, clear tick if Bluetooth drops, so the user knows instantly without looking at a screen.

---

How We Can Do It (Without Extra Pins or Space Issues) 🛠️

I went through the nRF5340 board configurations and device trees to see if this is feasible. It turns out we can integrate it with zero new pins on the SoC:

• Bus Sharing (I2C2): The DRV2605L runs over I2C. Since its address is 0x5A and the onboard LSM6DS3TR-C IMU sits at 0x6A, they can safely share the existing I2C2 bus (pins P1.14 and P1.15) with zero conflicts.
• Recycling the Motor Pin: The current motor pin is P0.25. We can repurpose this as the active-high Enable (EN) pin for the DRV2605L. This drops the driver's standby current to < 1 µA when not vibrating, protecting our small 150mAh battery.
• Physical Fit: The current motor is D5.0mm x H2.5mm. A miniature 6mm coin LRA (like the Vybronics VG0640001D) is D6.0mm x H2.5mm. Since the thickness is identical, it fits perfectly under the casing covers. It only requires a tiny 1mm widening of the inner plastic frame slot.

---

What the Code Looks Like (Zephyr RTOS)

Zephyr has native, out-of-the-box driver support for the DRV2605. We can declare the driver node under &i2c2 in our DTS overlays:

&i2c2 {
    status = "okay";
    
    drv2605l: drv2605l@5a {
        compatible = "ti,drv2605";
        reg = <0x5a>;
        enable-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
        label = "HAPTIC_DRIVER";
        status = "okay";
    };
};

And in prj.conf:

CONFIG_I2C=y
CONFIG_GPIO=y
CONFIG_HAPTIC=y
CONFIG_HAPTIC_DRV2605=y

For Bluetooth, we can extend the current single-byte haptic characteristic (CAB1AB96-2EA5-4F4D-BB56-874B72CFC984) to take a 3-byte command:

1. Byte 0: Mode Selector (0x01 = ROM waveform, 0x02 = Real-time playback, 0x03 = Frequency tone).
2. Byte 1: Payload (ROM effect index 1 to 117, or sound frequency in Hz).
3. Byte 2: Playback duration.

---

Proposed Rollout Plan

• Phase 1: Get a cheap DRV2605L breakout board, wire it to the extension header of a DevKit2 (nRF52840), and test the ROM library effects.
• Phase 2: Drop the driver and LRA footprints into the Altium mainboard design files for the next PCB revision (v1.3/v2.0).
• Phase 3: Integrate the Zephyr DTS configurations and update haptic.c to parse the new BLE packets.
• Phase 4: Wire the Flutter and Swift apps to trigger subtle clicks during scrolling, confirmations, and alerts.

I'd love to hear what the community and the hardware team think about this. Let's make Omi feel even more alive! 🚀