Golden Cheetah

Le xPower, c'est le même algorithme que la puissance normalisée : Moyenne((puissance lissée sur 30s)**4)**(-4) ?

Je pense que tes efforts à haute intensité de 30'' passent à la trappe à cause du lissage.

Le même tableau avec les kJ et le temps en mouvement :


Pour la puissance kJ/s, on trouve sur les L3, L5, L7, L9, L11 : 296W, 290W, 305W, 302W, 286W.
Déjà, il y a un pb de temps en mouvement sur le L3 : j'ai coupé l'enregistrement (environ 5") en m'arrêtant à un stop, et il me sucre 1' de temps en mouvement...

J'ai pris le tableau de l'éditeur, copié-collé sous excel, et sur les 4'11" de L3 la moyenne des 251 puissances instantanées à chaque seconde me donne bien les 316W.

teamdindon écrit:

Le xPower, c'est le même algorithme que la puissance normalisée : Moyenne((puissance lissée sur 30s)**4)**(-4) ?

Aucune certitude, j'avais compris que xPower et NP étaient équivalents, mais ma compréhension et la réalité sont parfois 2 choses très différentes...

J'ai une première piste : je me suis demandé, à la lecture de l'éditeur, où était l'info "LAP", et je suis allé voir la tête du fichier .json . Celui-ci comporte plusieurs en-têtes, dont un avec le fichier des intervalles.

Précision : mes fichiers ne sont pas importés depuis le Bryton vers GC, mais circulent du GPS -> plateforme Bryton -> Strava -> import GC. Ca peut jouer... ?

Donc voici l'en-tête du fichier .json avec les intervalles :

"INTERVALS":[
{ "NAME":"Lap 1 ", "START": 0, "STOP": 448, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 2 ", "START": 429, "STOP": 518, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 3 ", "START": 457, "STOP": 707, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 4 ", "START": 768, "STOP": 1405, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 5 ", "START": 1405, "STOP": 1642, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 6 ", "START": 1642, "STOP": 2012, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 7 ", "START": 2012, "STOP": 2224, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 8 ", "START": 2224, "STOP": 2511, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 9 ", "START": 2511, "STOP": 2732, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 10 ", "START": 2732, "STOP": 3384, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 11 ", "START": 3384, "STOP": 3607, "COLOR":"#000000", "PTEST":"false" },
{ "NAME":"Lap 12 ", "START": 3607, "STOP": 4815, "COLOR":"#000000", "PTEST":"false" }

Pour mon premier intervalle, j'ai eu un petit souci : j'ai tombé 4 pignons d'un coup, et ça a envoyé la chaîne entre le 1er pignon et le cadre. Donc arrêt, et en fait mon 1er intervalle est L3, et non L2. L2 c'est donc 90 secondes, dont la quasi totalité hors temps en mouvement.
Sauf que si on se demande où GC est allé chercher les 3'09 en mouvement du L3 (-61" par rapport à la durée réelle et en mouvement du L3), on est bien tentés de les trouver entre la marque 518 et la marque 707 (707-518 = 189s = 3'09"). Mon L3 dure bien 250", mais pas entre 457 et 707 : plutôt entre 518 et 768.
Si je calcule la puissance moyenne entre 457 et 707 avec les données de l'éditeur, je trouve bien les 294W du tableau de GC. Il y a donc un problème de constitution de l'en-tête des intervalles du fichier .json, Bryton ou Strava ou GC s'emmêlent les pinceaux quand il y a du temps à l'arrêt, pendant lequel le GPS se met en pause automatique.

Bon, ça explique l'écart sur le premier intervalle, mais par sur les autres où la durée en mouvement est juste. Mais comme le fichier .json exclut les lignes de pause automatique, il y a peut-être un décalage de 29" (durée du L2 - 61" de pause auto) également dans le reste du fichier, si les bornes des intervalles sont les n° de lignes du bloc "samples" et pas les secondes écoulées depuis le déclenchement du chrono.
Je ne sais pas comment régler le problème, mais me voilà rassuré, car je ne comprenais pas ce problème récurrent d'écart entre les moyennes de puissance en live et les données GC. Il suffit que je m'arrête à un feu rouge, et ça décale. Les moyennes affichées sur l'écran sont donc a priori justes, et ça m'arrange !
Moralité : tout est fait pour qu'on ne s'arrête pas au feu rouge...

En 2016, un copain du GMC38 m'avait posé une question similaire sur GC avec son Bryton.

J'avais soumis le bug aux développeurs : est-ce le même bug ?

github.com/GoldenCheetah/GoldenCheetah/issues/2029
groups.google.com/g/golden-cheetah-users/c/vgYehhcMLDE/m/cl5adXH6CQAJ

Est-ce que ce "contournement de bug" fonctionne ?

Ce site est top pour pas mal de choses d'ailleurs... je fais volontiers mon suivi de charge (qui reste très sommaire) dans intervals.icu plutôt que GC.

Je me demande si il ne faut pas cocher une case "Garmin recording" quelque part dans les options de paramétrage d'import des fichiers .fit sous GC pour solutionner le problème. J'ai un Bryton Rider 310 et c'est ce que j'ai fait. Et de base les sorties indoor sont écourtées et tous les tours enregistrés sont décalés, si bien que quand je fais du HT c'est directement Strava et export en .tcx pour ré-importer sous GC.
Depuis que je me suis mis à Intervals.icu, je trifouille moins sous GC (quoique suite à une réinstallation complète du pc je suis en train de ré-importer tous mes .json ).

D'ailleurs j'ai installé la dernière version de GC, j'étais surpris de la ressemblance avec intervals.icu de la nouvelle interface, moi qui avait encore l'ancienne version, suis un peu paumé... Comment affiche t-on les data d'un intervalle sélectionné par exemple ? Pour l'instant je rame je rame

cycloflamand écrit:

Comment affiche t-on les data d'un intervalle sélectionné par exemple ? Pour l'instant je rame je rame

gillesF78 écrit:

En 2016, un copain du GMC38 m'avait posé une question similaire sur GC avec son Bryton.

J'avais soumis le bug aux développeurs : est-ce le même bug ?

github.com/GoldenCheetah/GoldenCheetah/issues/2029
groups.google.com/g/golden-cheetah-users/c/vgYehhcMLDE/m/cl5adXH6CQAJ

Est-ce que ce "contournement de bug" fonctionne ?

Je pense que c'est le même...
Sur le "contournement de bug", il faut se logger pour y avoir accès ?

L'export en .tcx nécessite que tu t'identifie sur la plateforme strava.

Ensuite, la procédure est décrite ici.
support.strava.com/hc/en-us/articles/216918437-E...C5E3278KM8MPK5X49ED3

Exemple :
pour la sortie www.strava.com/activities/11023050227

ajouter à l'URL : /export_tcx
-->
www.strava.com/activities/11023050227/export_tcx

gillesF78 écrit:

L'export en .tcx nécessite que tu t'identifie sur la plateforme strava.

Ensuite, la procédure est décrite ici.
support.strava.com/hc/en-us/articles/216918437-E...C5E3278KM8MPK5X49ED3

Exemple :
pour la sortie www.strava.com/activities/11023050227

ajouter à l'URL : /export_tcx
-->
www.strava.com/activities/11023050227/export_tcx

... pas envie de me coltiner la synchronisation à la mano, moi... Pour l'instant tout ce que GC reçoit c'est du .json, je ne sais pas comment je peux modifier ça et générer en automatique des .tcx ...

Si tu as activé l'import automatique depuis strava, GC reçoit le fichier .fit "original".

La version 3.6 corrige ce bug de lecture des fichiers de Bryton qui comportent plusieurs enregistrements ayant un repère temporel identique.

Pas encore compris les modalités d'échanges entre Strava et GC (Bryton envoie bien des .fit), mais le fait d'exporter du .tcx corrige l'erreur. Maintenant, comment faire pour que GC ne reçoive pas des .json en routine ? A tout hasard, j'ai fait une mise à jour du firmware du Bryton...
Déjà, avec intervals.icu je retrouve rapidement mes petits !

stam écrit:

Maintenant, comment faire pour que GC ne reçoive pas des .json en routine ?

Seuls les import depuis DropBox et depuis un dossier local peuvent être au format json pour éliminer les pertes d'info (notamment les métadonnées)...
( source )

Et j'en profite pour rectifier une erreur dans mon message précédent, l'import strava se fait par l'API de strava qui fait perdre les données d'équilibre G/D du pédalage ( source )

Donc si tu veux tes données d'équilibre G/D, tu dois télécharger le fichier .fit qui vient directement de ton compteur .

Edit : conclusion de tout ça --> une mise à jour vers la version 3.6 me semble préférable.

gillesF78 écrit:

Edit : conclusion de tout ça --> une mise à jour vers la version 3.6 me semble préférable.

Ouais... malheureusement j'ai un conflit de Windows avec le pilote d'un utilitaire Barco qui m'empêche de lancer l'exécutable de GC 3.6...

Je t'ai préparé une version "portable x64" qui comprend le DLL de Visual Studio Redistributable (vc_redist.x64) à télécharger ici .

Il te suffit de :
- sauvegarder ton dossier de données GC pour revenir à la 3.4 facilement
- décompresser le zip dans le dossier de ton choix
- lancer GoldenCheetah.exe

Au cas où ça ne fonctionne pas comme tu veux, si les fichiers GC ont étés migrés vers la 3.6 (mise à jour des .json), alors il te suffira de remplacer ton dossier "3.6" par la sauvegarde de ta 3.4.

Trop classe !
Ca a fonctionné impeccable, merci !