How Claude Helped Reverse-Engineer Garmin’s BLE Protocols to Fake a Native Running Sensor

A Reddit user documented how they used Claude to solve two hard Garmin integration problems: making a non-Garmin chest sensor appear as a native Garmin strap on a Fenix watch, and getting a single BLE chip to present as two devices simultaneously. The source post details the process, the AI's strengths and weaknesses, and links to two in-depth blog posts.
Problem 1: Fake Running Dynamics on a Garmin Watch
Garmin locks running dynamics metrics (vertical oscillation, ground contact time) to its own straps via undocumented protocols. The developer used Claude to reverse-engineer the protocol by:
- Setting up a Bluetooth sniffer and ESP32 boards he already owned
- Sniffing a real Garmin HRM strap, then emulating it with an ESP32
- Diffing hundreds of log lines to find the single byte difference between working and non-working states
- Porting Gadgetbridge’s checksum and framing code
- Grepping through 57,000 decompiled files to find the field number that cracked the protocol
Claude wrote the code and ran the analysis, but the user had to correct direction when Claude reversed the protocol (which side sends what) and chased wrong assumptions for days. The result: a bare ESP32 with random data makes a Fenix display running dynamics as if from a native strap.
Problem 2: Dual BLE Identity Switching
On Garmin watches, a single BLE sensor often cannot serve both the watch’s native HRM+Garmin Connect IQ app simultaneously — connections fight and flip-flop. Claude suggested a trick from BLE standards: present two different MAC addresses from the same chip by switching addresses mid-connection. The developer’s blog post explains how he made an nRF52832 alternate between two identities without dropping the live link, despite the chip’s docs warning against it. This solved a years-long pain point for many Connect IQ developers.
Claude’s Role: Strengths and Weaknesses
The user notes Claude excelled at two things:
- Search aggregation: It knew about dual-identity switching even though the user didn’t, and suggested the technique.
- Grunt work: Running the diff, porting code, and grepping decompiled files.
But it struggled with direction — it had the protocol backwards and built on wrong assumptions for days. The user stresses that tests, static data, and validation were essential to catch hallucinations.
Learn More
The user published two detailed writeups with full protocol and implementation details:
- BLE identity switching: Two BLE identities, one nRF52832
- Garmin running dynamics RE: Reverse-engineering Garmin HRM600 running dynamics
📖 Read the full source: r/ClaudeAI
👀 See Also

Building a Sub-500ms Voice Agent: Architecture and Performance Insights
A developer built a voice agent from scratch achieving ~400ms end-to-end latency with full STT → LLM → TTS streaming. Key insights include treating voice as a turn-taking problem, using semantic end-of-turn detection, and colocating all components for minimal latency.

OpenClaw memory loss fix using Mem0 plugin
OpenClaw agents experience memory loss due to context compaction rewriting files like MEMORY.md. The Mem0 plugin solves this by moving memory outside the context window with auto-recall and auto-capture features.

Echo-TTS Ported to Apple Silicon with MLX for Native TTS with Voice Cloning
Echo-TTS, a 2.4B parameter diffusion text-to-speech model with voice cloning, has been ported from CUDA to run natively on Apple M-series silicon using MLX. On a base 16GB M4 Mac mini, a 5-second voice clone takes about 10 seconds to generate, while 30-second clones take about 60 seconds.

hiresTI: Native Linux TIDAL Player with OpenClaw/MCP Support
hiresTI is a native Linux desktop client for TIDAL focused on stable playback, high-quality audio output, a GTK4/Libadwaita UI, and OpenClaw integration via MCP for remote control. The app combines a Python UI layer with a Rust audio core.