Stryd Power is high after 6.0 fw upgrade

Have any of you guys tried Appbuilder5+? It should be able to support up to 6 fields with F5+. I guess it should fairly easy to write a simple formula to ignore values higher than 2000.

Here is one possible one to try, just took from the examples page at: https://ciq-appbuilder.blogspot.com/p/examples.html

avg(if(cadence gte 10, cadence, null))

This only shows cadence values higher than 10, and otherwise returns null. So we could just switch it the other way around for power:

avg(if(power lte 2000, power, null))

or for laps

lapavg(if(power lte 2000, power, null))

For instant power you would get -- each time power spikes, but you could try setting averaging window of 5s (or more), so as long as the spikes take less time than this you should get a stable power reading.

timeavg(if(power lte 2000, power, null),5)

Stryd has a built in lag of 5s anyway so you shouldn't loose much anything at all if you use 5s averaging. You could even get a bit smoother power readout as a result.

I don't have a F5+ (yet) so not able to test this. But I guess it's worth a try, unless you simply choose to downgrade your watch firmware. You could for example use Appbuilder5+ for power display, and Stryd data field for recording.

Seems to me this is a bug if it happens with all power meter connections. A clear sign is that older firmware apparently was not affected by this. Is there anyone with new firmware that doesn't experience the spikes btw?

I just got my F5+. Still a bit undecided whether I'll keep it or not, as I haven't fully yet tested all the features, but one thing is certain, the sensor connection to Stryd is much stronger than with F5. I can get the F5 drop out if I cover the watch with my hand long enough (5 or 10 secs is enough). But I never had any issues otherwise with it, no spikes or drops. When I got the F5+ first test was to cover it with my hand but power did not drop out even holding on a full minute.

Anyway mine came with 5.10 and I turned the automatic update off, just in case. So far did only short tests so no spikes yet.

At risk of being accused of being a Garmin fanboy, it appears from what Stryd have said is that while the problem is related to the recent update from Garmin, the issue lies more with how some Stryd users are using the Stryd pod. When connected as a cycling power meter there are problems apparently. When used as a footpad using Stryd's 1st part apps the problem is not there. Seems to me the solutions are:
1. Use the Stryd foot pod as a foot pod as intended.
2. Prevail upon the 3rd party providers to fix the issue with their data fields and apps.

Or is that being too simplistic?

At risk of being accused of being a Garmin fanboy, it appears from what Stryd have said is that while the problem is related to the recent update from Garmin, the issue lies more with how some Stryd users are using the Stryd pod. When connected as a cycling power meter there are problems apparently. When used as a footpad using Stryd's 1st part apps the problem is not there. Seems to me the solutions are:
1. Use the Stryd foot pod as a foot pod as intended.
2. Prevail upon the 3rd party providers to fix the issue with their data fields and apps.

Or is that being too simplistic?

Very happy to do that as soon as Garmin supports Running Power natively, then no need to create work arounds to get the watch to do what we want it to.

In the meantime, it seems that if you turn off the Power Meter pairing for Stryd and then turn it back on it clears something and then the Lap Power displays correctly. I only had time to test this for about 5 minutes so far, but before I did this I immediately had Lap Power showing over 2000, but afterwards it was correct during 5 minute testing. Will test further later during my run and will post back if results differ.

OK no joy :( Worked for all tests, but actual 45 minute run failed.

At risk of being accused of being a Garmin fanboy, it appears from what Stryd have said is that while the problem is related to the recent update from Garmin, the issue lies more with how some Stryd users are using the Stryd pod. When connected as a cycling power meter there are problems apparently. When used as a footpad using Stryd's 1st part apps the problem is not there. Seems to me the solutions are:
1. Use the Stryd foot pod as a foot pod as intended.
2. Prevail upon the 3rd party providers to fix the issue with their data fields and apps.

Or is that being too simplistic?

Yes, that is being too simplistic. (Never ask a rhetorical question if you aren't prepared for the answer.)

1. This bug has also hit users who usea cycling power meter as a cycling power meter.

2. There is no bug in the data fields or apps, so we can't wait for the providers to fix the issue. The data fields and apps receive incorrect information from the Ant+ connection.

If you want simplistic, you can use this:
Garmin In, Garbage Out.

2. There is no bug in the data fields or apps, so we can't wait for the providers to fix the issue. The data fields and apps receive incorrect information from the Ant+ connection.

Does the issue appear to be limited to ANT+ sensors?

This bug has also hit users who usea cycling power meter as a cycling power meter.

And the common theme is - cycling. As Stryd note, if you use it as running power using their app it is not a problem. So yes, Garmin have something to fix, but for those using running power, the workaround appears to be to use the Stryd app.

As an aside, I'd be interested to know if this affects only 3rd party power meters and not the Garmin Vectors, or all power meters.

Garmin In, Garbage Out.

I don't think it's quite that bad.

My Elite Direto trainer PM is affected. My Stages Gen 2 is not. The error came with FW 5.57. I have downgraded to 5.10, and everything is OK.

Stig.

And the common theme is - cycling. As Stryd note, if you use it as running power using their app it is not a problem. So yes, Garmin have something to fix, but for those using running power, the workaround appears to be to use the Stryd app.

We already know the workaround, thank you.

The presence of a workaround is a rather good indication that there is a problem. So the problem should be solved:
The problem is that since somewhere around 5.57, the watch will feed unreliable power data to data fields from some Ant+ power meters.

Simple as that.

You can discuss all you want whether it is wrong or not to use running power meters as cycling power meters. But this discussion is just a red herring. Nothing useful will come out of it.