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

✍️ OpenClawRadar📅 Published: June 23, 2026🔗 Source
How Claude Helped Reverse-Engineer Garmin’s BLE Protocols to Fake a Native Running Sensor
Ad

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.

Ad

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:

📖 Read the full source: r/ClaudeAI

Ad

👀 See Also