Has the currentCadence handling changed?

Is the version of CIQ on the watch 3.2.6?  A couple odd things happen with that, including starting a timer in a watch face results in a crash.  You can use monkeyVersion to see if you're running on a 3.2.6 VM, as this could revert back to the way it was for a VM newer than 3.2.6.

Hi Jim, yes, I am running 3.2.6 on my watch. But I haven't understand what I can do against the problem.
Could you please give me some directions? Thanks for the help.

If monkeyVersion is 3.2.6, double currentCadence

else don't

System.getDeviceSettings().monkeyVersion

It returns an array, like [3,2,6] in this case

Ah, got it now. Thanks for sharing. I was
at the size limit with some datafields which uses this. Hopefully this additional statement will not crash on some watches...

Hi Jim, how would you compare two arrays? This here is working but feels not very smart:

            if (System.getDeviceSettings().monkeyVersion.toString().equals([3,2,6].toString()) ) { curCad *= 2; }

There's no built-in way to compare two arrays by contents -- you'd have to write your own helper function. Since an array could contain objects of several different types, this is the kind of thing that would be non-trivial if you wanted to handle every possible case (e.g. you'd have to handle arrays that contain strings, arrays, and other objects).

In your case, another solution would be:

The only advantage I can see with this code over the other solution is it would probably use less CPU, probably consume less "resting" memory (in the form of code), and probably use less memory in the form of a spike at runtime (when converting each array to a string).

But in most cases, it's probably down to personal preference.

You could also make the call once at initialize time (since the version isn't going to change) and save the result, in which case most of those differences become even more irrelevant.

(As a matter of fact, the memory spike caused by getDeviceSettings() is gonna be a lot more significant than anything you do with monkeyVersion. In some of my apps which are very tight on memory, I definitely avoided some problems by avoiding calling getDeviceSettings() anywhere other than init.)

Thanks for sharing. You are right, I could place the statement in the ini function and store it the result in a variable.
Thanks for sharing.

My datafields are affected as well. Cadance is halved now. Afterwards in Garmin connect the cadance is correct, also in the native cadance metric, so it is a bug in the API. Using the sensor history still gives the correct value, I have heard, but I am afraid that that requires more memory.

Here’s a related post in the Fenix 6 forum and a comment from a Garmin employee asking people to PM them to help gather more information. 

forums.garmin.com/.../1312107

The 3.2.6 check is no longer valid since this is happening in 4.0.0+ devices.  Also this is bandaid Garmin should provide what is in the API across all models and version.   

If that is the case why is the Sensor.Info.Cadence the actual value.   The walk and Run activities in the Activity.Info.currentCadence and Activity.Info.averageCadence are 2:1.   What is this? one leg cadence? 

 The bike, InlineSkate, row activities in the Activity.Info.currentCadence and Activity.Info.averageCadence are 1:1.  

Either Fix the CIQ bug at the root or Correct the API for all devices.  

From what is written in the API below it is RPM not RPM/2.    

the API from connectiq-sdk-mac-4.0.5-2021-08-10-29788b0dc  

Activity.Info

var currentCadence as Lang.Number or Null

This is the Sensor.Info Class API