Well, there's this.
I have Fenix 6s Pro, and recently (most likely after 19.20 update) I have noticed that during running acitvities the watch shows cadence as half of what it usually shows. For example it shows 85 instead of usual 170. However after completing the activity, it shows correct cadence in garmin connect app. I have noticed this both with and without the HRM chest strap. Did anyone else also notice something similar?
Funny how the same problems come up over and over again.
This one is a bit different as cadence was showing half of what it should be start if I recall. started on the va4. Here's the change log for the fix on the va4
Changes made from version 6.30 to 6.33: Updates to Garmin Pay Added Pulse Ox improvements Added golf improvements Added support for HRV from a chest strap -->Fixed an issue were cadence values were halved in Connect IQ data fields Fixed some missing translations Reworked backlight/brightness settings Fixed some scenarios where the backlight could get stuck on Fixed an issue where Connect IQ watch faces could crash
Sorry I didn't mean to imply that it was the exact same problem. It's a problem where cadence in CIQ apps is half of what it should be, whereas the original problem in this thread was that *average* cadence was half of what it should be and current cadence was okay.
My point is that it's not the only time that there's been some sort of 1/2 cadence issue in CIQ.
Hi Garmin,
I just got notified about this bug and I was wondering if more details can be shared?
1) From a developer perspective, is the workaround as simple as "var averageCadence = info.averageCadence * 2" ?
2) Does this bug affect all activities?
3) Does this bug affect all watches?
4) How come the problem does not appear in the simulator?
Even if I disagree that Garmin will not fix it to avoid impacting existing developers, how come you do not come up with another field in the Toybox.ActivityInfo that will have the correct value? Something as simple as Toybox.ActivityInfo.averageCadence2 for example.
Thank you all!
I have this problem. I have a data field which is customizable and can be used for running and cycling. When a user uses it for a running activity info.currentCadence is in steps but info.averageCadence is in strides (2 steps). When a user uses this for a cycling activity info.currentCadence is in RPM info.averageCadence is in RPM. Can this be fixed so that it is consistent within an activity? Ahhh!
Even if I disagree that Garmin will not fix it to avoid impacting existing developers, how come you do not come up with another field in the Toybox.ActivityInfo that will have the correct value? Something as simple as Toybox.ActivityInfo.averageCadence2 for example.
I mean this is the most obvious solution but it's probably never gonna happen.
Since the problem seems to stem from different definitions / requirements for "cadence" in running vs biking, it might even be best if there were two sets of new fields, with clear definitions of their meaning. e.g.
- averageRunningCadence, runningCadence (steps per minute - [insert detailed explanation here])
- averageBikingCadence, bikingCadence (revolutions per minute - [insert detailed explanation here])
3) Does this bug affect all watches?
Don't quote me on this, but IIRC, Fenix watches may have behaved differently than other watches as far as cadence goes, at some point in time. I could be wrong though.
Here's a related issue which was fixed:
4) How come the problem does not appear in the simulator?
Because as some people love to point out, "the simulator is not an emulator". It's written to mimic the devices, it doesn't literally run the same code as the devices.
I can't x2 for Cycling and Running because the API produces different results for Cycling and Running. I am not sure what other Activities will produce as I cannot find any reference from Garmin as to how this is configured. Cycling Cadence = 1 RPM and Running Cadence produces 1 step or 1/2 RPM. Whereas averageCadence give results for 2 steps or 1 RPM whether it is Cycling or Running.
It's been this way for 7+ years, so I doubt a fix is coming. It would actually break a bunch of apps that have work-arounds if this was fixed.
I first saw this with walking and hiking in 2015 and have a work around in the code.. (I double the value based on the sport)