Stroke rate problem for paddling app

Former Member over 6 years ago

Hi all,
I've programmed custom kayaking app for essentially one reason : since I'm kayaing quite often (at least twice a week), I'm tired of having to change the type of activity to "canoe-kayak" when using SUP (stand up paddle) application.
However I have problems getting correct stroke rate (and thus meter per strokes...) in my app where at it seems correct in SUP app.
In my app I almost have no strokes recorded (just a few from time to time). Here is a picture with the stroke rate I get from SUP app and my Own app for a similar kayak session. You can see the difference in the attached image...
in my own app I get the stroke rate each seconds with :

activityInfo = Act.getActivityInfo();
activityInfo.currentCadence;

Do you have an idea of the problem ? community.garmin.com/.../1414248.jpg

Former Member over 6 years ago

Nobody has an idea ?

lcj2 over 6 years ago

This is most likely related to the SUP activity type enabling the correct algorithms for detecting stroke rate. If you don't want to record as that activity type you'll need to code your own stroke detection algorithm. This of course will throw you into the dreaded native number field non implementation crowd. Someone with more knowledge will need to comment but I suspect activity type is the problem with native stroke detection being enabled or it is using a non-related sport algorithm.

Former Member over 6 years ago

Do you mean the currentCadence is a "preprocessed" value for which the "preprocessing" depends on the activity type ?

That would mean that if I declare my app as a "SUP" activity I should have correct values ? That's easy to test... but t it works like that I then have to find a way to change my "activity type" back to canoe kayak after recording in the watch...

There is also the possibility of my own stroke detection algorythm but when I talked about that everybody pointed me to the currentCadence parameter...

lcj2 over 6 years ago

Do you mean the currentCadence is a "preprocessed" value for which the "preprocessing" depends on the activity type ?

I'm suggesting that how the value is processed depends on the activity type, I don't have any idea when it is processed.

That would mean that if I declare my app as a "SUP" activity I should have correct values ? That's easy to test... but t it works like that I then have to find a way to change my "activity type" back to canoe kayak after recording in the watch...

I thought you were suggesting you already did that but yes I would try that first. I'm un-aware of a programmatic way to alter the activity type of a recording activity, you can change it in Connect after it has uploaded.

There is also the possibility of my own stroke detection algorythm but when I talked about that everybody pointed me to the currentCadence parameter...

This is the easiest solution.