Bug: range of average cadence is half of the range of cadence

I concur. Comment in my own complex data field:

if (mUseTicker) {
if (!mTicker) {
mHeartRate = mAvgHeartRate;
//! Either there is a bug in connectiq-sdk-win-1.2.6/1.2.9
//! or in the FR630 firmware 4.10/4.20/4.30/4.60 but as of now
//! (May 2016) the info.averageCadence displays as for a
//! cyclist on the watch, with only one leg counted, while
//! info.currentCadence counts both legs. A .fit file of the
//! run is correct in the SDK "Connect IQ Device Simulator"
//! for both data streams, but a "Simulate Data" session shows
//! just "0" for averageCadence. Therefore doubling the value
//! here, for now...
mCadence = 2 * mAvgCadence;
}
}


That's correct. It's stride cadence. If you want step cadence, just multiply it by 2.

That's correct. It's stride cadence. If you want step cadence, just multiply it by 2.

Why change the definition of cadence when taking the average?

This looks like a bug, and more importantly, produces an inconsistent user experience.

Pardon a Swede, but "stride" vs "step"? Anyway, the documentation muddles it even more by talking about "revolutions" - like in cycling:

[...]
- (Number) currentCadence
The current cadence in revolutions per minute
Returns:
(Number)
Since:
1.0.0
[...]
- (Number) averageCadence
The average cadence in revolutions per minute
Returns:
(Number)
Since:
1.0.0

Something is obviously not correct. Perhaps currentCadence should be halved as well in Connect IQ so we all had to multiply by two to get 'running' values?

There is nothing wrong with the FR630 handling of internal cadence while running; current, average for whole activity or average for last lap etc - it is only the CIQ info.averageCadence that reports 'half' a value.

It's actually been that way since SDK 1.0.0, and it's not just avg, but max. And maybe cadence itself based on what you're recording:

if(actInfo.averageCadence!=null) {
lastAvgCadence=(actInfo.averageCadence*2).format("%d")+" spm";
}

if(actInfo.maxCadence!=null) {
lastMaxCadence=(actInfo.maxCadence*2).format("%d")+" spm";
}

if(actInfo.currentCadence!=null) {
if(recordTypes[recordType][0]==Record.SPORT_HIKING) {
lastCadence=(actInfo.currentCadence*2).format("%d")+" spm";
} else {
lastCadence=(actInfo.currentCadence).format("%d")+" spm";
}
}


Can we request that this be fixed please?

I.e. that the definition of cadence be the same whether it's current, average or max? And that it be consistent between the default selectable fields in a data screen and a programmed CIQ data field using currentCadence, averageCadence, and maxCadence.

From the users point-of-view, these are all the same thing. From a developers point-of-view, it's frustrating to have to guess the different definitions for the same thing that then requires special clauses in your code to make them consistent (so you don't have your users complaining).

I posted this issue a year+ back, and today, changing it would impact a boatload of existing apps. My 2c is that it's best to just code for it the way it is.....

I posted this issue a year+ back, and today, changing it would impact a boatload of existing apps. My 2c is that it's best to just code for it the way it is.....

As annoying as it will be for those developers who have had to compensate for Garmin's slow response here, that's a really bad idea and terrible way to manage a platform. That is, assuming Garmin sees the current CIQ SDK as just the beginning of something much bigger, and not the end.

We're aware of this situation and have decided to leave things the way they are for now to avoid impacting the existing developers. I can't say for sure right now, but I suspect we'll implement a better solution relatively soon and deprecate the existing one. Our policy is to allow deprecated APIs to exist throughout the next major release, and then remove them in the subsequent major release (e.g. something deprecated in 1.x will remain in 2.x and be removed in 3.x). Since we try for one major release roughly each year, it allows the new and deprecated APIs to be used side-by-side for a while and gives developers plenty of time to adjust to the changes.

OK time to add some x2's to my code then. I look forward to version 2 of the SDK.