Recording Boulder

Hi all,

I am about to write my first app for Garmin watches. It is to record my boulder sessions.
I know there are already apps doing this but as far as I know they all require me to start and stop every single boulder and need to set grades. Way to much to push and press during an activity. My goal is that the app recognises when I am in a boulder and when I finished it. The app is mainly to count boulders and their height and may be a few more things. I nearly finished the basic tasks: I see when I am bouldering and when I am resting. I count the boulder and see their hight. I have a little chart, displaying them during the session.

All my questions are related to the following session configuration:
_activityRecording = ActivityRecording.createSession({
:sport=>Activity.SPORT_FLOOR_CLIMBING,
:subSport=>Activity.SUB_SPORT_BOULDERING,
:name=>"Bouldering"
});
a) Start / Stop Boulder
When I use this configuration, whenever I start the app, it immidiatly starts counting boulder and because I don't plan to use buttons the boulder stops when I stop the app. How can I programmatically start and stop boulder during a running session?
b) Hight of a boulder
When starting an activity, I see the altitude. But when starting at an altitude of lets say 400m then a boulder hight of 2 to 3 meters is not realy visible in the default views of CIQ web portal. In case of a) and I can manage every single boulder, is there a way of setting my own properties for this?
c) Custom FitContributions
When I work with the session settings from above, custom fitcontribution fields aren't displayed in CIQ web portal. But when I use :sport=>ActivityRecording.SPORT_GENERIC for session settings, they are perfectly shown.

Any help is appreciated
Thanks in advance

  • my code looks like this. Depending on the state of the session I start or stop it. And the Lap/Back button is used only to exit in case the session was stopped before otherwise it is ignored. No addLap function called.

        function onKey(keyEvent) {
            switch (keyEvent.getKey()) {
                case _Start_Stop_Key:
                    if ((Toybox has :ActivityRecording && (_Session == null) || (_Session.isRecording() == false))){
                            _Session = new $.SessionController();
                            _Session.start();

                    } else if ((Toybox has :ActivityRecording) && (_Session != null) && (_Session.isRecording() == true)) {
                            _Session.stop();
                    }break;
                case _Back_Lap_Key:
                    if ((_Session == null) || (_Session.isRecording() == false)) {
                            System.exit();
                    }
                    else{
                        return;
                    }break;
                default:                
                    return;
            }
        }
  • When you do a return from a callback like onKey(), you always want to do

    return true;

    or

    return false;

    to indicate if your app handled it or not,  On some devices, it very much matters.

    for example, with onBack(), return true, and your app keeps running (your app handled it),  return false, and the default system action occurs, where your app terminates.

    You may not see all cases in the sim., but I recall the vivoactive and venu devices are really picky about this.

    So, instead of onKey() I'd use onBack(), like this and maybe use onSelect() instead of Start_Stop_Key

     

    function onBack() {
        if(_Session!=null) {
            _Session.addLap();
            return true;        //handled
        else {return false;}    //not handled
    }
    
    function onSelect() {
        if(_Session==null) {
            //start the session
        } else {
            //stop the seesion
            _Session=null;
        }
        return true;            //always handled
    }

  • Just wanted to check.  When you are testing, you are installing from the app store and not using a sideload, correct? (it can be a beta app in the store so only you can install it).

    With a sideload, your user/fitcontib fields won't show in Garmin connect. as the info on how the data is displayed from the xml gets turned into a json file that's included in the iq file and isn't part of your app.  Garmin Connect then gets the info from the app store.

    This is similar to app settings where they are not available with a sideload.

    See https://forums.garmin.com/developer/connect-iq/w/wiki/4/new-developer-faq#app-settings

  • It doesn't make any difference wheter I side load the app or download it from app store as beta. I can see the value of total boulders in the summary correct but no laps. ist only shown as one boulder.

    I also can return true with no other result.

  • wouldn't implementing function onBack() mean that I have to push the button to activate it? This is what I try to avoid. If this would be needed I push my app into the trash bin because all this is about is to avoid pling with my whatch during a boulder session. My absolut goal is having an app which detects and writes results of a session without any interaction.

  • If you never call addLap, nor click the lap button then how do you imagine the watch to guess when you want a new lap?

  • yes you are right but I do for sure call addLap() every 20 seconds.

    _LapTimer.start(method(:lapPoC), 2000, true);
    function addLap() as Void {
            _fitFieldBoulderHight.setData(_LapMaxHight);
            var result = _Session.addLap();
     }
  • never the less there must be something wrong with the way I save lap data as you can see from the picutures.

    Elevation is ok

    Elevation in monkeygraph

    but laps are wrong

    Lap1

    Lap2

    while summary is ok

    Summary

    Boulder count is saved in laps althouh it shouldn't. 

    There are always only 2 laps shown in monkeygraph altgough in this case addLaps was called 5 times, which you can see in the amount of rows and the correct summary value

  • (Sorry for the off-topic discussion, I just wanted to provide my perspective on why I don’t think Garmin cares if you record a field that is similar to some native field, contrary to another opinion.)

    Can you clarify something? When you pair Stryd then how many cadence fields you see? And are they in sync?

    You didn’t really specify what you mean by “pair”. The short answer is that if you install the Stryd Zones CIQ field (which is necessary for correct operation of the Stryd wrt data gathering for the Stryd mobile app), the CIQ field will record a second Cadence field (in addition to the native one), and the two cadence fields aren’t necessarily in sync. (e.g. The native field may use the wrist as a cadence source and the CIQ field always uses the Stryd footpod as a cadence source.) Furthermore, native running power and Stryd power will always be different, yet they can co-exist in the same fit file as a native power field and a CIQ developer field called “power” (which uses the nativeNum for power.)

    I’ll reiterate what I said before.

    - Stryd has three ways to “pair” with your Garmin. Natively as a power sensor, natively as a footpod, and via the CIQ Stryd Zones data field. Stryd can make multiple connections simultaneously, so it’s possible to pair as more than one thing at a time.

    - there’s no point in pairing as a power sensor unless you use another 3rd party field which supports power, since Garmin does not accept running power from 3rd party sensors. (It won’t use the data for metrics or workouts, and it won’t write it to the FIT file.)

    - If you pair as a footpod, then native cadence will come from the Stryd as you suggested

    - If you install the Stryd Zones data field, it will discover the Stryd footpod (via ANT+) and it will write several Stryd-related CIQ FIT fields, including Power and Cadence, which are clearly similar in name to native fields. 

    - The cadence field reported by Stryd Zones is “one foot” cadence, so its magnitude is half of what would be reported by the native field

    - If you use Stryd Zones *and* you pair Stryd as a footpod, then the native cadence field and the Stryd cadence field will naturally be in sync, except that the Stryd field will have half the magnitude of the native field. It could be argued that data which is presented in different units (or based on a different definition of the metric — one foot versus two foot cadence) is still confusing to the end user, if the premise is that Garmin doesn’t want the user to be confused by a similar-sounding field.

    - If you use Stryd Zones and you don’t pair Stryd as a foodpod (this is the normal way of using Stryd btw), then there will still be two cadence fields, but they won’t necessarily be in sync, since Garmin cadence will come from the wrist (or perhaps some other accessory like the HRM-Run) while Stryd cadence will come from the Stryd. Again I’ll use the example of a runner who keeps their running arm unnaturally still for a portion of their run — during this period of time, clearly cadence from the wrist will be different from cadence from Stryd.

    - if you use Stryd Zones and enable native running power, now you will have a native power field and a stryd IQ power field which are not in sync, since the former comes from Garmin’s calculations and the latter comes from calculations on the Stryd footpod.

  • Hi, please do not open a new topic in this thread. It is all and only about adding laps to a boulder activity. nothing else.

    Thanks, Henry