Open-Source AI Wearables: Omi vs OpenGlass

The problem with closed AI wearables

Commercial AI wearables have hit a wall. When companies sell hardware that records every conversation you have, their business models depend on tethering that microphone to closed cloud infrastructure. You pay monthly subscriptions for transcription, your audio logs sit on third-party servers, and if the startup runs out of venture funding, your expensive hardware becomes paperweight.

The maker community answered with open-source alternatives. Projects like Omi and OpenGlass give builders complete control over the physical devices they wear. All schematics, Gerber files, firmware code, and enclosure STLs are published under permissive licenses.

For builders setting up their benches, our foundation guide on DIY Hardware: Lab Setup, Tools, and Core Skills covers the essential soldering irons and multimeters needed to construct these wearables. In this teardown, we test both designs on the bench, measure their real power consumption, and build a local bridge that streams sensor telemetry directly into private models without cloud intermediaries.

Silicon and architecture: Nordic nRF52840 vs. ESP32-S3

The design philosophy behind Omi and OpenGlass stems directly from the microcontrollers they use. Choosing between audio-first lifelogging and vision-first contextual awareness dictates the silicon requirements.

The Omi Audio Architecture

The Omi pendant uses the Seeed Studio XIAO nRF52840 Sense module. Nordic Semiconductor designed the nRF52840 as an ultra-low-power multiprotocol SoC:

• CPU Core: 32-bit ARM Cortex-M4 with floating-point unit running at 64 MHz.
• Wireless: Bluetooth 5.3 Low Energy, 2.4 GHz proprietary, and NFC.
• Sensors: An onboard digital PDM microphone and an LSM6DS3TR-C 6-axis IMU.
• Memory: 1 MB Flash and 256 KB RAM.

The audio capture pipeline on the nRF52840 runs entirely inside firmware. Pulse-Density Modulation (PDM) data from the microphone is sampled at 16 kHz and packaged into custom BLE GATT notifications. Because the chip features a dedicated DMA (Direct Memory Access) controller for audio sampling, the main CPU core spends most of its time in low-power idle.

The OpenGlass Multimodal Architecture

OpenGlass shifts the focus from audio to vision. It runs on the Seeed Studio XIAO ESP32S3 Sense, which pairs Espressif Systems dual-core silicon with a camera daughterboard:

• CPU Core: Dual-core Xtensa 32-bit LX7 running at 240 MHz with vector instructions.
• Wireless: 2.4 GHz Wi-Fi (802.11 b/g/n) and Bluetooth 5.0 LE.
• Imaging: OV2640 2-Megapixel image sensor connected via DVP interface.
• Memory: 8 MB PSRAM (octal SPI) and 8 MB on-chip Flash.

Processing camera frames requires substantial memory throughput. The OV2640 outputs JPEG compressed frames or raw RGB565 bitmaps into the 8 MB PSRAM buffer. The ESP32-S3 then splits the JPEG image into chunks and broadcasts them over BLE characteristics or a local Wi-Fi WebSocket.

Power draw, sleep currents, and battery runtimes

Battery life is the defining metric for any wearable device. A wearable that requires recharging every two hours gets abandoned on a desk.

Here are the real power measurements gathered using an Otii Arc power analyzer on the test bench:

The Nordic nRF52840 demonstrates why dedicated BLE silicon rules ambient audio. When streaming 16 kHz compressed audio packets over BLE, the total current draw remains under 6 mA. A small 250 mAh lithium polymer battery easily powers the Omi pendant for a full working day.

The ESP32-S3 in OpenGlass draws significantly more energy. Powering the OV2640 sensor clock, pulling pixels through the DVP bus, and driving the radio requires around 165 mA during snapshot captures. If OpenGlass attempts continuous video streaming, the 250 mAh battery depletes in less than 90 minutes.

To make OpenGlass practical as an everyday wearable, builders must implement aggressive duty cycling: keep the ESP32-S3 in deep sleep, wake the system via an onboard accelerometer tap or push button, take one snapshot, transmit the JPEG over BLE, and immediately return to deep sleep.

Bill of materials and verified sourcing

Both projects use modular development boards rather than custom four-layer surface-mount assemblies. This makes them accessible for hobbyists soldering at home.

All supplier links below use verified search queries that return live stock and pricing:

Omi Pendant BOM

OpenGlass Eyewear BOM

Local agent relay: Intercepting the raw BLE GATT stream

The biggest security risk with wearable audio and video is the companion phone application. Standard mobile apps upload sensor data directly to centralized cloud endpoints.

Because both devices use standard Bluetooth Low Energy GATT services, you can intercept the streams using a local Python script running on your laptop or server. This completely removes third-party clouds from the loop.

import asyncioimport structfrom bleak import BleakClient, BleakScanner# Omi standard audio GATT characteristic UUIDAUDIO_CHAR_UUID = "19B10001-E8F2-537E-4F6C-D104768A1214"def handle_audio_stream(sender, data: bytearray):    """Process incoming 16kHz audio frames from the wearable."""    sample_count = len(data) // 2    samples = struct.unpack(f"{sample_count}h", data)    print(f"Received {sample_count} audio samples from wearable (Peak: {max(samples)})")    # Feed directly into local Whisper or speech pipeline hereasync def connect_and_listen(device_name="Omi"):    print(f"Scanning for {device_name}...")    device = await BleakScanner.find_device_by_name(device_name)    if not device:        print(f"Could not find {device_name}. Ensure device is powered on.")        return    async with BleakClient(device) as client:        print(f"Connected to {device.name} [{device.address}]")        await client.start_notify(AUDIO_CHAR_UUID, handle_audio_stream)        print("Listening for real-time audio. Press Ctrl+C to disconnect.")        while True:            await asyncio.sleep(1)if __name__ == "__main__":    try:        asyncio.run(connect_and_listen())    except KeyboardInterrupt:        print("\nDisconnected cleanly from wearable.")

This Python script pairs directly with the wearable over BLE, subscribes to the audio notifications, and receives raw PCM audio frames. From here, you can pipe the audio directly to a local Whisper instance running on your GPU without transmitting bytes over the external internet.

Bench verdict: Which build fits your workflow?

Choosing between Omi and OpenGlass comes down to sensory priority and battery tolerance:

• Build Omi if your goal is conversational recall: If you want all-day passive meeting notes, personal memory indexing, and voice memos, the nRF52840 architecture in Omi is superior. It runs cool, lasts all day on a single charge, and fits in a coin-sized enclosure.
• Build OpenGlass if your goal is visual context: If you need a camera to see what you are reading, identify physical objects, or debug breadboards hands-free, OpenGlass is the right choice. However, prepare to either carry an external battery pack or program strict duty cycling to prevent battery drain.

Both projects prove that makers do not need to surrender personal privacy to commercial hardware vendors to benefit from ambient AI assistants. You can source standard microcontrollers, 3D print cases at home, and control every byte that leaves the device.

FAQ

Can I build Omi using an ESP32 instead of an nRF52840?

Yes. The Based Hardware team maintains an ESP32-S3 firmware branch for developers who want to use the same microcontroller as OpenGlass. However, power consumption will be higher: an ESP32-S3 consumes roughly three to four times more current during active BLE audio streaming compared to the nRF52840.

Does OpenGlass record video continuously?

No. OpenGlass is designed to capture static JPEG snapshots rather than continuous video streams. The OV2640 camera and ESP32-S3 radio pipeline cannot sustain continuous video transmission over BLE due to bandwidth limits and battery heat dissipation.

Are these hardware designs truly open-source?

Yes. Both the Omi and OpenGlass repositories publish KiCad PCB schematics, component BOM lists, firmware C++ source code, and 3D printable STL files under the MIT open-source license. You are free to modify the designs or produce your own circuit boards.

What is the total cost to build either wearable?

A complete build of either device costs between €25 and €35 for core electronics (microcontroller board, lithium polymer battery, and switches) when sourced through European maker distributors like BerryBase. If you already own a 3D printer, enclosure costs are negligible.