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

MCP Server: Comparing Local and Cloud LLMs with Debate Feature
The MCP server enables developers to query local models via Ollama alongside various cloud LLMs, offering features like side-by-side comparison and a structured debate function.

BetterClaw vs OpenClaw: Comparing Tool Calling, Structured Outputs, and Workflow Control
A developer-focused comparison of BetterClaw and OpenClaw covering tool calling, structured outputs, workflow control, and day-to-day agent development.

Klaw.sh: Kubernetes-Style Orchestration for AI Agents
Klaw.sh provides an orchestration solution for AI agent deployment, modeled on Kubernetes. It simplifies management with clusters, namespaces, and channels, achieving memory reduction by rewriting from Node.js to Go.

ClawBridge – Safely Expose Your Home Assistant Entities to OpenClaw
ClawBridge introduces a seamless way to expose Home Assistant entities to OpenClaw, enhancing automation while ensuring safety. Discover its features and benefits.