My client needs to support Stryd Running Power. However, it seems like Garmin doesn't allow Stryd Sensors to inject Power data as a native power metric. We've tried and if you display the built in Power field on screen it does not show Stryd Power. Maybe this is because many watches now support native Garmin running power? Or maybe I'd need to pair directly with the sensor to pull the non-native user data? Anyway, if you've written a CIQ app to consume data from Stryd, let me know. Thanks!
If that AI is correct, then you can do what I do with the Polar H10 both make the watch record my HR as my HR, and also make my datafield be able to read the more detailed HR data from the strap. I made the ANT+ HRM datafield for this: https://apps.garmin.com/apps/7c83d402-4b68-4f0a-b167-7139788a19b3
So you enable both ANT and BT in your sensor, then you pair and connect your sensor via Bluetooth in the Garmin's system menu, then you start your app or datafield and pair it with the same sensor's ANT broadcast.
We've tried and if you display the built in Power field on screen it does not show Stryd Power. Maybe this is because many watches now support native Garmin running power?
Uhhhhh you asked about this weeks ago and I gave you an *extremely* detailed answer. Guess you did not read it and/or you completely forgot. Not for the first time.
https://forums.garmin.com/developer/connect-iq/f/discussion/421549/stryd-power-and-native-garmin-power ("Stryd Power and Native Garmin Power")
I'm so glad that you decided to trust Google Gemini's AI overview instead of consulting your own memory tho.
However, it seems like Garmin doesn't allow Stryd Sensors to inject Power data as a native power metric
I also explained this before - both at the time of that detailed answer mentioned above *and* a year or two ago when you asked about it before.
- 3rd party running power is not the same as garmin running power. garmin never uses 3rd party sensors as a source for running power
- the ANT+ standard for power meters is specifically meant for cycling power meters. Running power is not standardized and does not have a standard ANT+ profile
Running power is not the same as cycling power.
The first time I explained this, you did not believe me, but as I said at the time, every reference to power in the ANT+ documentation - e.g. standard ANT+ power profile - mentions bikes/cycling. Plus there is no ANT+ standard for running power nor any scientific/technical/practical consensus on the definition of running power. None of the running power vendors produce values that agree with each other
Besides, Stryd sensors deliver a bunch of other metrics, some of which may be specific to Stryd's own definition/implementation of running power, like form power and leg spring stiffness. Notice how Garmin doesn't have those metrics so they can't be used for its own running power
- Stryd sensor does indeed present as a cycling power sensor, but as I explained over and over again, this doesn't help with running power because....wait for it....Garmin treats running power and cycling power differently
- In the past, when Garmin did not implement *native* running power, if you displayed the Power field in a running activity (or any power-related field), the field would indeed display *cycling* power. This is probably one of the reasons that Stryd decided to present as a cycling power meter, in addition to presenting as a standard footpod, and implementing its own proprietary ANT+ profile which is used only by its own apps (including the Stryd Zones data field) - it was probably just a convenience for end users and devs (at a time when it was actually helpful)
- Now that Garmin does implement *native* running power, if you use a Power field in a running activity, it will ONLY ever display native running power in that field, not cycling power and not 3rd party running power
- Related to the previous points, in the past - before garmin native running power - if your app looked at power metrics in ActivityInfo during a running activity, they would indeed reflect cycling power in a natively paired cycling power meter (including Stryd). Now (after garmin native running power) power-related metrics in ActivityInfo will never reflect cycling power during a running activity, but only native running power (and never 3rd party running power sensors)
So the old loophole where you would ask the user to pair the Stryd natively as a (cycling) power meter no longer exists. It won't do anything for running activities. It will work during cycling activities but that won't help you
Or maybe I'd need to pair directly with the sensor to pull the non-native user data?
Yeah, as I explained before over and over again in extreme detail, now if your CIQ data field wants to read and display power from a Stryd sensor in a running activity, it has to make a "direct connection" to the sensor (as you said) using Ant.GenericChannel.
In this way you can read "cycling power" data from the sensor as if it was a standard cycling power meter
HOWEVER, you cannot write native power data to the FIT file, because:
- Garmin does NOT accept any 3rd-party running power sensors for native running power
- Garmin won't use cycling power in place of running power, as I said
You can record power using the "nativeNum" feature but ofc - as discussed OVER AND OVER again at great detail, nativeNum is not used by Connect. So at best, 3rd party sites like Strava will use power recorded in such a way. For Strava, native running power takes precedence, so you will have to disable Garmin native running power if you want your power recorded with nativeNum to be used by Strava. Probably the case for every other 3rd-party service except Stryd itself.
Btw, for power to be accepted by the Stryd backend/app/site, you need to use Stryd Zones data field (or other CIQ Stryd apps), because Stryd will not accept data that was recorded via 3rd party non-Stryd apps because, as they said:
- Stryd doesn't want the responsibility of accepting possibly bad data (because users will blame Stryd)
- The Stryd Zones CIQ app records many more metrics than power, and Stryd needs all of those metrics for its analysis
So you enable both ANT and BT in your sensor, then you pair and connect your sensor via Bluetooth in the Garmin's system menu, then you start your app or datafield and pair it with the same sensor's ANT broadcast.
You don't have to pair natively, as I explained OVER AND OVER AGAIN IN THE PAST because:
- Stryd is able to pair and connect (via ANT/ANT+) in 3 different ways simultaneously: as a standard cycling power meter, as a footpod, and with Stryd's proprietary ANT+ profile (which delivers many Stryd-related metrics, not just running power)
- Stryd's own data field (Stryd Zones) uses the proprietary ANT+ profile (which no one else uses since...durrr...it's proprietary)
Therefore your own CIQ data field can:
- make a direct connection to the sensor as a standard cycling power meter using Ant.GenericChannel
- instruct the end user to unpair (or disable) the sensor as a standard ANT+ cycling power meter in the system menu. They have to do this because your app cannot connect if the watch natively connects via ANT+
Btw all of this can be done while also using the Stryd Zones CIQ data field. In fact the user *must* use Stryd Zones (or some other Stryd CIQ app) if they want to get Stryd data into the Stryd ecosystem (backend servers, Stryd PowerCenter and Stryd phone app), since no one else uses the Stryd proprietary ANT+ profile, no on else records all the data that Stryd needs, and Stryd won't accept 3rd party (non-Stryd) data anyway.
Idk why you assume running power (which is not standardized) is just like HR, which has been standardized forever (in the context of ANT/ANT+ sensors).
----
I explained all of this over and over again in the past, but I can't wait to explain it again in a couple of months or years.
2035: Garmin running power not working with Stryd???!!!
2040: Stryd and running power!?
TL;DR
1) running power is not standardized
2) running power is not the same as cycling power, especially for the purposes of ANT/ANT+ sensors and Garmin native running power
3) Garmin native running power does not work with 3rd party sensors, including Stryd. This includes native data fields and structured workouts.
4a) In the past, when Stryd appeared to work with power in run mode, that's because it was being paired as a cycling power meter and running activities were showing cycling power in run mode, for power fields. In no way did Garmin ever use Stryd as a source for running power.
4b) Running activities no longer shower cycling power for power fields, but only native running power
4c) The previous 2 points also apply to power fields in ActivityInfo
4d) Because of the previous 3 points, there are several old CIQ data fields which no longer work with Stryd, as they relied on the user natively pairing with Stryd as a cycling power meter
5) Stryd supports 3 simultaneous connections/pairings/modes over ANT/ANT+:
- standard cycling power meter
- standard footpod
- proprietary Stryd ANT+ profile (used by Stryd Zones data field and other Stryd apps)
The ANT ID is the same for each mode, but each mode works over a different channel and with a different profile
6) If you want your CIQ app to read (and display) power from Stryd:
6a) you must ask the user to unpair (or disable/disconnect) the Stryd as a power meter in the system sensor menu
(Note that this is the opposite of the previous advice for users to natively pair with Stryd as a power meter, which isn't helpful anymore)
6b) your app must directly connect to Stryd as a cycling power meter using Ant.GenericChannel
7a) There is no way for a CIQ app to write running power to the FIT file in such a way that it will be recognized by Connect, or the Stryd ecosystem. The only way for a Garmin watch to write Garmin running power such that Connect will recognize it is to use the native running power feature.
7b) The only way for a Garmin watch to write running power so it will be recognized by Stryd is to use a Stryd app like Stryd Zones data field
This means that if you write a CIQ data field to work with Stryd, users will probably still want to *also* use Stryd Zones
This is an issue because there are only so many slots for CIQ apps in an activity profile on a Garmin watch (2 for last gen watches, 4 for some current gen watches.)
8) Your app can write power using "nativeNum", and it will be recognized by some 3rd party services/apps like Strava, but Connect will never recognize it. In this case, you may have to disable native running power, otherwise native power will take precedence (this was the case for Strava last time I checked). This means that even if you use Stryd Zones, you need to disable native running power if you want Strava to use power from Stryd.
For 3rd party services (except Stryd), native power in the FIT file generally takes precedence over CIQ nativeNum power.
Sources:
- I own a Stryd footpod and use it pretty much every day when I run. (Stryd sent me one because I made a CIQ data field that works with Stryd.)
- I use the Stryd Zones data field
- I've written a couple of CIQ data fields that work(ed) with Stryd. One of them relied on the user pairing to Stryd natively as a (cycling) power meter, which no longer works. Another one would work either with the native sensor pairing or by making a direct connection using Ant.GenericChannel
- I've talked to Stryd engineers who partly explained the thing about Stryd working like 3 ANT+ sensors in one as described above. But this can also be seen just be looking at how Stryd appears in the native sensors menu, and observing that Stryd Zones still works even if the Stryd is already paired/connected as a cycling power meter and a footpod
- I've used Stryd with Forerunner 935 and Forerunner 955 (which is fairly modern, although it's "last gen" - the key point is that it does support native running power, and the built-in data fields / ActivityInfo reflect only native running power in run mode, as described aove)
- I've seen the change in native power fields (data fields and ActivityInfo) in run mode, from displaying cycling power to native Garmin running power. I saw this both firsthand and I've seen the various forum threads
But you don't have to blindly believe me, you can verify everything I said yourself if you have access to a Stryd footpod
TL;DR
1. It's an interesting take. Even your 2 comment is so long that it needs a 3rd comment with TLDR^2 (or in your case probably an even higher exponent)
2. I'm not sure about DaveBrillhart , but for me the other topic you mention above is definitely related to the TLDR effect. Your comments are so long (plus you often, as now, start to reply to yourself multiple times, and have some monolog with yourself) that I hardly have time or willpower to comprehend them. I do read them if it's a direct answer to my question and sometimes when it's a topic I'm interested in then even in other's threads, but often times it's just TLDR...
3. I also noticed that Dave has a tendency to ask the same question again and again. I also do this mistake sometimes, but I try to search the forum first. One interesting feature of the mind is that the way you think about things and the way you write and search about a topic doesn't change much, so often, when I think: what is the best search phrase to get the best answers (taking in account how bad the forum's search engine is - though that can be mitigated by using Google) I'll search in a way that pops up my old comments or questions. So sometimes I do find an old topic AND some useful answers. I really recommend every forum user to search before asking (though I recognize that this sentence will probably only be ready by flowstate, probably the only user in the forum who reads long comments and doesn't need to be reminded to search the forum ;)
3. Sometimes I wonder if flowstate is an LLM :) Maybe some experimental super top secret AI and we'll never know...
Great info! I just ordered a Stryd v5 and will get this working. I reached out to the author of pbRUN, a field that can also do this, but this post provides all I need. Thank you.
