Darefore Run: the BLE trick that gets third-party data into Garmin natively

Extreme close-up of a running shoe mid-stride about to toe-off, filling most of the left side of the frame, cutting off the leg entirely or showing only the faintest hint of ankle at the top edge.How a developer tricked a Garmin watch into accepting running data it was never meant to receive

BLE-only third-party sensors have generally been unable to feed Garmin’s native Running Dynamics pipeline, leaving their data confined to Connect IQ fields that Garmin’s own analytics never read. A Belgian developer named Sam Dumont has changed that, and the product at the centre of the story is one I reviewed here in early 2025, after which I introduced Sam to the team building it.

Dumont reverse-engineered the proprietary Bluetooth protocol Garmin uses internally for its HRM 600 chest strap. This protocol integrates Running Dynamics natively into the watch’s recording stack and uses it to enable a non-Garmin sensor to speak that protocol fluently. The result is a third-party chest strap that a Garmin watch treats as its own Running Dynamics source, feeding vertical oscillation, ground contact time, left/right balance, step length, and cadence directly into Garmin’s native recording and analytics pipeline.

Why was this a BLE problem specifically

It is worth being precise about what was actually locked.

Running Dynamics over ANT+ has had an open profile since 2017. Stryd uses it. Any manufacturer willing to implement that ANT+ profile could feed native Running Dynamics to a Garmin watch. The problem is that ANT+ is now effectively a legacy protocol with no active development and declining support among new sensor manufacturers. Garmin ended its ANT+ membership and certification programmes on 30 June 2025. No new profiles are being written. Every sensor manufacturer building new hardware today builds for Bluetooth LE.

No documented, interoperable BLE path existed for third-party manufacturers to deliver Garmin-native Running Dynamics. A BLE-only sensor was locked out of Garmin’s native recording pipeline, regardless of its data quality. Dumont’s work closes that gap at exactly the moment it became the only gap worth closing.

What the lock is

Running Dynamics over BLE has required a Garmin strap for the richer metrics, not because no other sensor could measure them, but because the Bluetooth path into the watch’s native recording was undocumented and proprietary.

It is worth noting that newer Garmin watches from the Fenix 7 and Forerunner 955 generations onwards can generate Running Dynamics data from the watch’s internal sensors. A chest strap adds balance data and can improve accuracy, but is no longer the only source on those models. On older hardware, the strap was the only path entirely. In both cases, third-party BLE sensors were forced into Connect IQ data fields: visible on screen, logged in the FIT file, but outside Garmin’s native Running Dynamics set and the analytics features linked to it.

Techie Talk: Dumont decoded the stack layer by layer: a Bluetooth multiplexer, a Garmin-specific framing protocol, and a protobuf message schema extracted from a decompile of the Garmin Connect Android app. He also leaned on prior work from Gadgetbridge, the open-source watch companion project that had already mapped significant portions of the transport layer. The watch does not check if Garmin made the sensor. Instead, it checks whether the sensor is speaking the right language. Speak it correctly, and the watch lets you in. Dumont’s sensor identifies itself as OpenRD and received the full native treatment.

What the Darefore running sensor does with this

Darefore: Running Dynamics currently misses important metrics linked to the torso.

The Darefore sensor is worn on the chest. In running mode, it produces the standard Garmin Running Dynamics set natively, so vertical oscillation, ground contact time, balance, step length, and cadence go into Garmin’s native recording pipeline the same way an HRM 600 feeds them. Beyond that, it produces three metrics that the HRM 600 cannot: torso stability, fatigue drift, and asymmetry. Darefore’s own marketing argues that these reveal structural degradation in running form before pace and heart rate respond, thereby catching the mechanical signal of a runner tiring in real time.

Those additional metrics land in developer fields because Garmin has no standard data bucket for them. The usual Running Dynamics numbers go into the native pipeline. The combination means Garmin’s analytics are properly fed, while the runner gets a layer of structural insight that no Garmin strap can provide.

Both standard and proprietary metrics are derived from a single sensor.

The sensor also resolves a second problem Dumont had been working on for years. A Garmin watch refuses to let one Bluetooth device simultaneously pair as the native HR monitor and supply data to a Connect IQ app. The connections fight, and one wins. His fix is to make the single chip inside the sensor appear as two devices at two different Bluetooth addresses. The watch pairs the HR monitor, and the Connect IQ field connects to what it believes is a separate device.

This doesn’t really count as a Garmin exploit, as it follows the standard BLE protocol.

The full technical details are in Dumont’s own write-ups: reverse-engineering the HRM 600 Running Dynamics protocol and the dual BLE identity technique.

What it cannot do

Running power is the obvious question that Stryd users will have already thought of.

Sorry, No. Garmin’s running power metric is computed by the watch rather than accepted as a native external input, using pace, grade, and Running Dynamics values depending on sensor availability. There is no writable external field for it, and this work does not change that.

Availability

Darefore Run is in pre-launch. Launch priority registration is open at darefore.com/run. Pricing, timeline, and hardware requirements will be confirmed at launch.

The wider point

Dumont has published the full protocol and is contributing the sensor-side code to Gadgetbridge this week. Gadgetbridge had mapped the watch-to-phone transport direction for years. The sensor-to-watch direction, the part that feeds Garmin’s native pipeline, was missing until now. For any developer building a BLE-only sensor, the engineering cost to add native Garmin RD integration is now measured in days rather than months.

Whether there is a large enough market for a chest-worn running biomechanics sensor remains an open question. History is littered with failed insole running gait sensors.

The cycling version of Darefore is technically capable and remains niche. But clearly running is a bigger market and a decent chunk of it may want new form-related metrics – physios and coaches spring to mind. The technology is no longer the constraint.

FAQ

Does Darefore Run work with all Garmin watches?

The protocol has been tested on the Epix Gen 2 Pro, which is Fenix 7-generation hardware, and is expected to work on any Garmin watch on the official Running Dynamics-compatible device list. That list includes Fenix 7 series, Forerunner 955, and newer models. Compatibility with older hardware is being confirmed.

Can Darefore Run send running power to my Garmin watch?

No. Garmin’s running power metric is computed by the watch itself rather than being accepted as an external input. That is an architectural limit; this work does not change it.

What is the difference between native fields and developer fields on a Garmin watch?

Native fields are recorded and read by Garmin’s own analytics features. Developer fields are visible on screen and logged in the FIT file, but sit outside Garmin’s own algorithms. Until now, all third-party BLE sensor data has been captured only in developer fields. The Darefore running sensor puts the standard Running Dynamics set into native fields, with its additional biomechanical metrics in developer fields as well.

Why did this require reverse engineering rather than using Garmin’s developer tools?

Garmin’s Connect IQ developer platform gives third parties access to custom data fields and Connect IQ apps, but not to the native sensor protocols that feed Garmin’s own analytics. The Running Dynamics BLE protocol is undocumented and not available through official developer channels. Reverse engineering was the only path.

Last Updated on 10 June 2026 by the5krunner


My favourite kit and nutrition

  • Maurten — the race nutrition trusted by elite athletes. Gels and drink mix engineered to be easy on the stomach.
  • Garmin 90-degree charging adapter — the small adapter that keeps your charging cable tidy at the stem. Essential for race day.
  • Garmin charging puck — the fastest and most reliable way to top up your Garmin before a session.
  • Ravemen FR300 — front light that mounts directly under your Garmin or Wahoo head unit. Keeps your bars clean and your beam pointed where it matters.
  • Garmin Varia RTL515 — radar rear light that alerts you to vehicles approaching from behind. Pairs with your Edge or Garmin watch.
  • Stryd — the footpod that brings running power to your Garmin. The single most useful running upgrade I have made.
  • Favero Assioma Pro RS2 — the power meter pedals most serious cyclists end up choosing. Accurate, easy to move between bikes.


Reader-Powered Content

Buy me a coffee

This content is not sponsored. It’s mostly me behind the labour of love, which is this site, and I appreciate everyone who supports it.

Support the site: Follow (free, fewer ads) · Subscribe (paid, ad-free) · Buy Me A Coffee ❤️

All articles are written by real people, fact-checked, and verified for originality. See the Editorial Policy. FTC: Affiliate Disclosure — some links pay commission. As an Amazon Associate, I earn from qualifying purchases.

1 thought on “Darefore Run: the BLE trick that gets third-party data into Garmin natively

  1. Very interesting feat, even if it doesn’t pan out hardware wise. I’ve registered for the pre-order.

Leave a Reply

Your email address will not be published. Required fields are marked *