Golden Cheetah

Il faut avoir défini des plages de dates.
Ensuite, dans l'affichage de la courbe de CP, il faut sélectionner la plage de date et la faire glisser vers la courbe. Ça ouvre une liste en bas de la semaine qui permet d'y mettre plusieurs plages de dates et ensuite de sélectionner lesquelles on veut comparer.

Merci Nickel

Bonjour tout le monde,
je vois que pas mal de monde utilise Golden Cheetah ici.
Je m'entraîne aussi avec cet outil en utilisant le mode "Train".
J'ai configuré la disposition des télémétriques mais je n'arrive pas à afficher le couple de force alors que dans les graphiques de compte rendu je peux voir le torque de la séance. J'ai fouillé sur Internet un moyen de pouvoir afficher cette télémétrique en direct pendant l'entraînement mais je n'ai pas trouvé.
Est ce que quelqu'un peut m'aider sur ce sujet ?
Merci

Yves écrit:

Bonjour tout le monde,
je vois que pas mal de monde utilise Golden Cheetah ici.
Je m'entraîne aussi avec cet outil en utilisant le mode "Train".
J'ai configuré la disposition des télémétriques mais je n'arrive pas à afficher le couple de force alors que dans les graphiques de compte rendu je peux voir le torque de la séance. J'ai fouillé sur Internet un moyen de pouvoir afficher cette télémétrique en direct pendant l'entraînement mais je n'ai pas trouvé.
Est ce que quelqu'un peut m'aider sur ce sujet ?
Merci

Je place ma "réponse" ici, ce sera plus approprié que de poursuivre avec un énième sujet intitulé "Golden Cheetah quelquechose" ou "Quelquechose sur Golden Cheetah".
Je n'ai pas de solution à ta question, mais moi non plus je n'arrive pas à exploiter le couple de mes sorties. Dans mon cas, c'est rien-nada-niente-nix. Et quand j'exporte mes données de sortie en csv depuis GC, le couple est à zéro, alors que les données de cadence et de puissance y sont. J'ai bien un graphe de force à la pédale, mais j'en viens à me demander si ce graphe n'est pas fait simplement en divisant Puissance/Cadence ; et je fais l'hypothèse que le couple n'est pas transmis ou se perd dans le transit Bryton Rider 420 -> App Bryton -> Strava -> Golden Cheetah. Hypothèse renforcée par l'export d'un fichier .fit "original" depuis Strava, j'ai la cadence et la puissance, l'équilibre gauche/droite, mais pas le couple.
J'ai cherché à récupérer les .fit directement depuis le Bryton, pour le moment je n'ai pas réussi.

Bonjour Yves

Il n'est pas possible d'afficher le couple dans la vue "Train" (Entrainement).

Seules les métriques décrites sur cette page sont actuellement possibles.

Cependant, il existe le graphe "Coup de pédale" (pédale stroke) qui affiche le couple en fonction de l'angle de la pédale (voir cette page ). Je n'ai jamais essayé.

Je vais faire mon boulet mais Golden Cheetah n’existe pas sous format mobile ? C’est exclusivement en le téléchargeant sur un PC ou Mac qu’on peut y avoir accès ?

Il y a 10 ans, une application d'enregistrement d'activité sur smartphone android a été développée. ( Lien 1 , Lien 2 ).
Très peu d'utilisateurs l'ont utilisée, et elle est abandonnée.

Mais rien d'autre n'a été envisagé.

Golden Cheetah est codé en C++, et utilise les bibliothèques Qt, Python, R, etc.

Le code n'est pas facilement portable vers Android, parce qu'il faut utiliser NDK . Sinon, ce serait déjà fait...

Autre aspect : la puissance de calcul des smartphones est légèrement + faible que celles des ordinateurs. C'est (en partie) pour cela que les opérations demandant des calculs coûteux sont effectuées dans le "cloud", donc dans des data-centers qui consomment énormément de ressources (traffic réseau, énergie, matériel coûteux). Et les applications "cloud" doivent trouver du fric pour payer tout cela : publicité et/ou abonnements et/ou vente de produits liés (compteurs, home-trainers, smartphones, etc).

Pour charger mon "profil" comportant 3144 activités dans Golden Cheetah, il faut attendre environ 20 secondes sur mon PC Portable
Processeur Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz 2.81 GHz
Mémoire RAM installée 16,0 Go (15,4 Go utilisable)

Pour recalculer les métriques utilisateurs (hrIF, hrTSS, hrNP, Puissance_moyenne_sans_les_arrets) sur Golden Cheetah, il faut plus de 15 minutes parce que des intégrales temporelles sont calculées sur les 3144 sorties. Comme les intervalles de temps durent 1 seconde, ça fait 3600 * 5800 = 20 880 000 points de calcul.

Sur ces 21 millions de points, le CPU calcule des moyennes mobiles sur 30s des données de puissance pour obtenir la NP ( lien ), des meilleurs pics de puissance sur 5s, 7s, 30s, 1min, 5min, 10min, 20min, 30min, 1h, 4h...

Tu ne le vois pas quand tu utilises le résultats d'appli Android+cloud (telles que strava) venant de data-centers, mais ça consomme des ressources informatiques tout cela... (voir actualité du data center par la firme Digital Realty à Bouc Bel Air ).

Autre aspect : le volume de stockage des données. Pour stocker les 3144 sorties dans le format JSON, Golden Cheetah utilise 4.1 Go. Quand le stockage de ces données est sur les data-center où fonctionne l'application android, ça coûte du fric aussi...

En conclusion : un smartphone serait trop lent pour faire tourner Golden Cheetah, et il faudrait peut-être faire fonctionner la partie calcul sur un serveur... ou alors il faudrait le simplifier en supprimant :
- les métriques utilisateurs qui sont trop couteuses à mettre à jour en cas de changement des formules...
- les graphes R
- les graphes Python
- le code personnalisé pour le résumé des sorties et les tendances des métriques
Comme c'est un logiciel open-source, tu peux reprendre son code disponible sur Github pour faire une application Android qui serait simplifiée et adaptée aux smartphones...

Je pense qu'un smartphone "récent" (~< 4 ans) est capable de faire tourner ça décemment et de stocker les données.
Vu qu'on moissonne toutes les sorties individuellement, ça se parallélise bien et les processeurs de smartphone ont désormais 8 coeurs (presque autant que Pogacar). On peut aussi faire tourner le re-calcul des métriques en fond de tâche si besoin.

Ça c'est pour la partie théorique. Maintenant, pour faire ça, ça nécessite effectivement de recoder beaucoup de choses.

Et la tendance actuelle est plutôt d'aller confier ses données personnelles à un tiers pour qu'il les traite.

teamdindon écrit:

Je pense qu'un smartphone "récent" (~< 4 ans) est capable de faire tourner ça décemment et de stocker les données.
Vu qu'on moissonne toutes les sorties individuellement, ça se parallélise bien et les processeurs de smartphone ont désormais 8 coeurs (presque autant que Pogacar). On peut aussi faire tourner le re-calcul des métriques en fond de tâche si besoin.

Les utilisateurs n'aiment pas les applications qui vident la batterie de leur smartphone. C'est peut-être un autre motif pour faire traiter les calculs couteux sur un serveur "cloud-computing". Si la "tâche de fond" qui recalcule mes métriques utilisateur consomme toute ma batterie, ça ne va pas me plaire...

Intervals.icu est bien foutu. Seulement, le code source n'est pas public.
C'est probablement un choix justifié par un objectif de commercialisation...
Il basculera peut-être d'un mode de financement "volontaire" à un mode de financement par abonnement, du même type que strava...

Si intervals.icu avait été un code open-source, j'aurais bien aimé l'installer sur mon serveur raspberry pi4.

Je ne suis plus assez calé en dev pour les détails techniques (= vous savez mieux que moi)... mais quand je vois les ressources consommées par GC sur mon PC fixe pour charger tout mon histoire depuis 2011 (ça sature mes 8 Go de mémoire sur mon Xubuntu), j'ai du mal à imaginer le truc sur smartphone.
Ou alors une version radicalement allégée.

A moins que je n'ai loupé un paramétrage pour faire une sorte "d'archivage" des anciennes saisons

L'archivage est partiellement fait avec un "cache".
Ce sont les fichier ".cpx" contenus dans le dossier .GoldenCheetah\<user>\cache.
Chacun de ces fichiers contient les métriques de la sortie pour éviter de les recalculer à chaque lancement.
Il y a autant de fichiers que de sorties.

Donc à chaque lancement, GC lit les milliers de fichiers cache correspondants aux sorties de mon profil (taille du cache : 1.36 Go).

C'est indispensable pour afficher dans le mode "Tendance" le "performance management chart", et tout le reste.

Le fonctionnement du cache n'est peut-être pas tout-à-fait optimisé... Les fichiers .cpx sont écrits/relus avec la classe Qt QDataStream . Le code source est ici : RideCache et RideFileCache .

OK, donc chez moi ça fait 2451 fichiers depuis 2015 (et pas 2011), pour 1.2 Go au total.
Heureusement que j'ai un disque SSD sur mon PC fixe (et mon portable), là où je lance GC