Du calcul de la distance sur la Suunto Ambit

Discussions autour du matériel utilisé en course à pied : running, textile, GPS, cardio, ...

Messagepar cloclo » sa fiche K
» 15 Juil 2012, 11:27

Ceux sui ont suivi le fil Suunto Ambit noire HR sont déjà plus ou moins au courant que j'ai réussi à trouver la méthode de calcul de distance utilisée par Suunto sur l'Ambit, au moins jusqu'au firmware 1.5.

Dans ce fil, je vais vous expliquer pas à pas la méthodologie qui m'a permis de comprendre pourquoi la distance affichée par la Suunto Ambit est systématiquement inférieure à ce que donne des logiciels comme SportTracks(2)/RubiTrack/.... (même Movescount) quand on réimporte la traces dans ces logiciels.

Pour ceux qui ne veulent pas se farcir toute ma prose voici en résumé les conclusions:

-la trace de l'Ambit en enregistrement 1s ressemble souvent à celle d'un ivrogne qui titube de droite à gauche, d'autant plus quand la réception satellite est mauvaise. SportTracks(2), bien que disposant de plein d'options de lissage, n'en a pas pour le calcul de distance, et additionne simplement la distance entre points. Du coup, il va systématiquement surestimer la distance réelle.
-l'Ambit, quant à elle, ne va retenir pour le calcul de la distance que des points distants d'au moins deux fois l'erreur de positionnement GPS, ce qui revient de facto à un lissage de trace. Pour un parcours relativement droit et en terrain découvert, la distance donnée par l'Ambit va être précise. Pour un trail en terrain dense et avec nombreux virages, où la distance entre deux points retenus peut aller jusqu'à 50m (!), elle donnera une distance sous estimée, car aura tendance à couper les virages.
-ni l'Ambit, ni SportTracks(2), ne prennent en compte la correction de pente dans le calcul de distance, la distance étant celle projetée sur l'horizontale. Sur un trail dont la pente moyenne ne dépasse pas 15%, cette correction sera inférieure à 1%. Sur un Kilomètre vertical avec une pente de 50%, il faudra ajouter 10% pour obtenir la distance parcourue sur le terrain.


Avant tout, je tiens à remercier "montant" d'avoir mis gracieusement à disposition un script python qui permet de convertir le fichier log au format xml en gpx. Ca m'a grandement facilité la tâche, merci :D
Je remercie également Guenael,Antoine26,paulotrail,cga2 et Romain de m'avoir fourni quelques traces au format xml, car je ne possède pas moi même ce bijou de technologie.
Et en dernier, je remercie Suunto d'avoir choisi le format xml pour ses log, lisible par n'importe quel éditeur de texte, et surtout d'avoir mis dedans toutes les informations imaginables. Bien mieux que le format .fit propriétaire de Garmin.

Egalement, je tiens à préciser que je ne m'intéresse ici qu'au calcul de la distance, et pas à celui du dénivelé, décrit formidablement par Flo2Cannes. Ceci étant dit, passons à la méthode.

1/D'où il suffit de savoir lire les fichiers xml

Bon, je ne vais pas me la péter, il m'a suffit de lire et d'interpréter le fichier log au format xml pour arriver à mes trouvailles. Bien d'autres ici savent le faire (montant, Antoine26, serge ....), il leur a juste manqué un chouia de méthode pour me devancer :wink:

Ce fichier log de l'Ambit commence par une section <header> (en-tête), qui contient en gros un résumé de la trace:

Image

Entouré en rouge, la distance calculée par l'Ambit. Comment, nous allons voir ça de suite.

Après l'entête, on va trouver des <sample>, qui vont contenir les infos de chaque trace GPS (enregistrées chaque seconde pour les traces que je vais commenter): latitude, longitude, altitude (baro et GPS), ainsi que des paramètres calculés par l'Ambit: distance, vitesse, énergie, ...

Le premier <sample> après l'entête:

Image

On peut voir que la distance calculée reste égale à 0 sur les deux premiers samples. En fait, elle reste égale à 0 jusqu'au 7ème sample, enregistré 7s après le départ de la trace, où elle passe à 16m:

Image

Le plus probable, c'est que 16m est la distance entre le premier "fix gps", et celui obtenu après 7s. C'est à dire que l'Ambit ignore simplement un paquet de "fix gps" trop rapprochés. Pour confirmer cette hypothèse, et comprendre sur quel critère l'Ambit décide d'éliminer certains points, c'est là qu'un peu de méthode scientifique aide.

2/ Extraction des points GPS retenus par l'algorithme Suunto

Dans l'épisode précédent, on a vu que la distance calculée par l'Ambit ne changeait pas à chaque "fix gps", mais que de temps en temps. Pour comprendre plus en avant, on va donc simplement modifier un poil le script python de "montant", et lui faire écrire dans un fichier gpx que les points gps où la distance change (entouré en vert dans l'image précédente). On va donc se retrouver avec un fichier gpx qui va contenir nettement moins de points que le fichier original qui contient un point par seconde. On va également écrire en parallèle un fichier au format csv, qui sera plus simple pour continuer une analyse scientifique.

Ceux qui ont bénéficié de ces fichiers gpx "filtrés" en avant première savent déjà qu'en important ce fichier gpx dans SportTracks(2), on retrouve bien la distance calculée par l'Ambit (sauf à une exception près que j'ai fini par comprendre). Mais ça ne nous explique pas le pourquoi du comment.

Donc nous allons analyser ici un des fichiers csv (en fait xls) du TGV d'Antoine26 (dans l'épisode 1, c'était un fichier de Guénael). Voici le début du fichier, avec l'enregistrement des 45 premiers fix gps filtrés:

Image

Les deux premières colonnes sont simples à comprendre (latitude et longitude en degrés).
La troisième colonne correspond à la distance entre les points N et N-1, calculée comme suit:

a = sin²((lat(N)-lat(N-1))/2) + cos(lat(N-1)).cos(lat(N)).sin²((long(N)-long(N-1))/2) (haversine)
c = 2.atan2(?a, ?(1?a))
d = R.c, où R est le rayon moyen de la terre = 6371km.

Pour ceux qui auraient des doutes, ça correspond à mieux que 10E-6 près à la distance à vol d'oiseau, projeté en horizontal, c'est à dire sans prendre en compte la différence d'altitude. C'est une précision importante pour la suite, car ça écarte mon hypothèse initiale que j'avais émise dans le fil Ambit noire.

La quatrième colonne donne la distance entre les deux points comme évaluée par l'Ambit, les deux colonnes suivantes les distances cumulées, puis EHPE et alti baro. La colonne avec le temps a sauté dans une manip de conversion d'image, elle servait à illustrer que chaque point correspondait à des intervalles de temps qui s'échelonne typiquement de 5 à 15s, mais pas toutes les secondes.

On peut voir que j'ai bien conservé les bon points GPS, car la distance calculée correspond à l'arrondi près à celle de l'Ambit. De temps en temps, l'écart entre mon calcul et Ambit dépasse l'arrondi au mètre, je pense que c'est du au fait que parfois, le bon fix GPS n'est pas toujours enregistré entre les deux samples où la distance Ambit change, va savoir, Charles.

Voici la fin du fichier, où on peut comparer ma distance cumulée avec celle de l'Ambit:

Image

Ambit: 55.40 km
Cloclo (xml): 55.62 km
SportTracks(2) gpx 1s Ambit: 60.55 km
SportTracks(2) gpx filtré Cloclo: 55.68 km

Pour vous donner une idée de l'origine de la différence, voici une vue de la trace originale et filtrée affichée dans SportTracks(2) par dessus OpenStreetMap (l'originale ressemble à celle d'un ivrogne qui titube de gauche à droite, alors que la filtrée est bien plus lissée):

Image
Image

3/ Décryptage de l'algorithme de calcul de distance sur l'Ambit

Résumé de l'épisode précédent: on y a vu et démontré que Suunto n'utilise qu'une fraction des enregistrements GPS pour déterminer la distance totale d'un parcours. Sur quel algorithme se base Suunto sur le choix de ces points GPS, c'est ce que nous allons voir de suite.

Pour arriver à mes fins, je ma base sur le fichier xml que j'ai décrit dans 2/, où j'ai enregistré et calculé la distance entre les points retenus par Suunto, ainsi que le fameux EHPE. Non, ce n'est pas la dernière molécule dopante à la mode, mais simplement l'erreur de position associé à l'enregistrement GPS: Estimated Horizontal Position Error.

C'est là qu'il m'a fallu le seul soupçon de jugeotte, pour réaliser que la distance entre deux points retenus était corrélée à ce fameux EHPE. Voici le graphe montrant cette corrélation pour la trace du MMB de paulotrail:

Image

On se rend immédiatement compte qu'il n'y a quasi pas de points dont la distance est inférieure à 2*EHPE. Donc mon postulat est que l'alogrithme Suunto est grosso merdo le suivant:

-je part du premier point GPS enregistré
-j'attends d'avoir un second point distant de plus de 2*EHPE du premier, et je calcule la distance avec le point précédent
-je boucle ainsi jusqu'à la fin de la trace.

Voilà, je m'arrête là pour l'instant, le secret de Suunto est dévoilé pour l'essentiel.

4/ Analyse de traces xml de Kikous et bugs Suunto

Passons aux travaux pratiques, à savoir l'application du filtre développé en 2/ à 13 traces gentiment fournies par quelques Kikoureurs. Voici le tableau des résultats:

Image

Explications des colonnes:
-D Ambit: distance en km mesurée par l'Ambit
-D ST 1s: distance en km calculée par SportTracks(2) à partir du fichier original
-D CG 1s: distance en km calculée par Course Generator à partir du fichier original
-ST 1s/Ambit %: écart en % entre la distance calculée par l'Ambit et ST à partir du fichier original
-D ST filtré: distance en km calculée par SportTracks(2) à partir du fichier filtré
-D CG filtré: distance en km calculée par Course Generator à partir du fichier filtré
-ST filtré/Ambit %: écart en % entre la distance calculée par l'Ambit et ST à partir du fichier filtré

Petite précision: ici, j'ai désactivé la correction de pente prise en compte par défaut dans CG, en le flouant avec un fichier gpx où j'ai remplacé les valeurs d'altitude par 0 dans le champ <ele>.

Sur les 13 traces analysées, 11 ont d'emblée un écart entre la distance calculée par l'Ambit et ST à partir du fichier filtré de moins du %, même si l'écart entre l'Ambit et ST à partir du fichier original peut atteindre jusqu'à 23% pour la trace de Paulotrail dans les Bauges. Donc le filtrage marche nickel chrome ! Quand l'écart entre la distance calculée par l'Ambit et ST à partir du fichier original est inférieure à 5%, je dirai que ce que donne l'Ambit ne doit pas être loin de la vérité. Mais quand ça atteint 23%, l'Ambit doit surement un poil sous évaluer la distance, mais de combien? 1% 2% 5% ???

Mais deux traces posent problème:

-celle de cga2 du 01/07, où il manque de l'ordre 600m après filtrage. Une inspection de la trace dans le log xml révèle de suite le blème. L'Ambit n'a pas enregistré de fix gps pendant environ 5 minutes, pendant lesquelles le compteur de distance a pourtant tourné jusqu'à 618m. Il semble qu'il est possible de démarrer une trace sur l'Ambit même si la qualité de réception satellite est très mauvaise. D'ailleurs la première valeur EHPE loggée est de 52m !!! Voici la trace en question, cga2 m'a affirmé que c'est un aller/retour sur le même chemin. Même le premier fix gps est à 200m du bon endroit, ça se stabilise seulement au bout d'un certain temps ;-( D'ailleurs, sur ce fil sur le forum watchuseek, un gars a une trace qui a débuté à 6 km du départ réel !!!!!!

Image

En corrigeant la distance du fichier gpx de ces 618m, on obtient un bon accord Ambit/ST filtré.

-la trace de Romain33-relief (reconnaissance du MMB si je ne me trompe):

Image

Ici, le log xml montre qu'il y a un fix GPS au démarrage, mais au bout de 7s, plus d'enregistrement de rien du tout (même distance) pendant 3'29", où il y a un nouveau fix gps, mais la distance calculée par l'Ambit est toujours de 0, alors qu'il a parcouru 705m dans l'intervalle. Le plus probable, c'est qu'il y a peut-être eu un STOP après 7s, er de nouveau START après 3'29", mais l'Ambit a concaténé le petit morceau au reste de la trace, va savoir, Charles. Ce qui compte, c'est si on prend en compte de ces 705m, tout rentre dans l'ordre.

Edit suite à un commentaire de "montant":
Ces deux traces à "problème" sont du 30/06 et 01/07 2102, ce qui correspond à la date où une seconde additionnelle a été rajoutée à UTC:
http://en.wikipedia.org/wiki/Global_Pos ... ap_seconds
L''Ambit a pu être sensible à l'introduction de la "leap second" le 30 juin, mais dans ce cas, c'est parce qu'elle a mis du temps à assimiler le message inclus dans le train d'infos GPS qui donne l'écart entre le temps GPS et le temps UTC, et du coup à réinitialiser cet écart utile dans le calcul de la position.
Et dans ce cas, une différence de 1s correspond à environ 500 m sur le terrain.

5/ Fusespeed au secours du GPS

Comme vu en 4/, la trace de cga2 du 01/07 n'a pas de donnnées GPS enregistrée pendant les premières 5 minutes, car la qualité de réception satellite était trop mauvaise au démarrage. Un update hier soir du post sur le forum watchuseek avec une trace qui a commencée à 6 km du point de départ réel, et qui n'a retrouvé le bon chemin qu'au bout d'une heure permet d'expliquer ce qui s'est passé.

Suunto a bien vendu Fusespeed pour non seulement améliorer la précision de la mesure de vitesse, mais aussi pour pallier à une perte momentanée du signal GPS (genre sous les ponts), et comme l'accéléromètre est calibré en permanence sur le GPS, permet de continuer à calculer la distance dans ce cas. Très bien. En analysant le fichier xml (encore lui), le gars sur watchuseek s'est rendu compte que quand Fusespeed prend le pas sur le GPS, il n'y a évidemment pas d'enregistrement GPS (comme sur le début de trace de cga2), mais la distance est updatée toutes les secondes. Donc facile à voir dans le xml. Et effectivement, c'est le cas pour la trace du 01/07 de cga2.

Donc Suunto a pris le choix délibéré de pouvoir commencer l'enregistrement, même s'il n'y a pas de fix GPS au départ, en utilisant dans ce cas FuseSpeed. Le hic, c'est que:
1/FuseSpeed n'est pas calibré, car il n'y a encore eu de mesure GPS. Pas très grave, il doit prendre la dernière calibration de la séance précédente.
2/Pas d'enregistrement de la trace GPS comme dans le cas cga2, et au retour, on retouve une drôle de trace tronquée.

Je trouve que pour le prix de l'engin, c'est moyen. Suunto devrait au moins proposer dans le menu une option d'initialisation GPS plus longue, mais plus sure, pour les traileurs qui ne sont pas à 5 minutes près.

6/ Correction de pente pour le calcul de distance

Pour illustrer l'effet de la prise en compte de la pente dans le calcul de la distance (et ne plus avoir des distances projetées sur l'horizontale comme jusqu'ici), je m'appuie à nouveau sur les 13 traces discutées en 4/et moulinées avec l'excellent Course Generator de patrovite, qui inclue la correction de pente par défaut. Voici le tableau des résultats:

Image

Explications des colonnes:
-D Ambit: distance en km mesurée par l'Ambit
-D+, D-: cumul de dénivelé en montée et en descente
-D CG 1s: distance en km calculée par Course Generator à partir du fichier original sans correction de pente (proj. hor., <ele>0</ele>)
-D CG filtré: distance en km calculée par Course Generator à partir du fichier filtré sans correction de pente (proj. hor., <ele>0</ele>)
-D CG cor pente: distance en km calculée par Course Generator à partir du fichier filtré avec correction de pente (par défaut dans CG)
-D CG 1s/Ambit %: écart en % entre la distance calculée par l'Ambit et CG à partir du fichier original (proj. hor.)
-Cor pente CG %: écart en % entre la distance calculée par CG à partir du fichier filtré avec et sans correction de pente

Pour que Course Generator donne des résultats fiables concernant la correction de pente, il faut lui entrer des données lissées en altitude. C'est le cas ici, car on part du fichier filtré, qui ne retient en moyenne qu'un point toutes les 7s, et en plus, j'ai bien évidemment utilisé l'alti baro qui a des variations bien plus douces que l'alti GPS. Les traces pour lesquelles la correction est la plus forte (jusqu'à 5%) sont évidemment celles où ça monte dré dans le pentu. Le TGV, c'est de la gnognotte à coté ;-).

Ce qui m'avait induit sur une fausse piste au départ sur le fil de la black Suunto, c'est l'apparente corrélation entre le % de correction de la pente, et l'écart entre la distance Ambit/ST à partir de la trace originale (ici CG 1s). Mais en fait, c'est purement fortuit:
-aussi bien l'Ambit, que SportTracks, ou CG si je mets le champ <ele> à 0, calculent des distances projetées à l'horizontale
-la correction de pente est au moins 5 fois plus petite dans les cas étudiés que l'écart de distance mesurée par l'Ambit et SportTracks à partir du fichier avec enregistrement toutes les secondes, et ne suffit absolument pas à expliquer la différence Ambit/ST 1s

En fait, il se trouve que c'est en montagne, avec des vallées escarpées (ou en terrain arboré dense), que l'Ambit a la précision GPS la pire: effet de réflexion d'ondes mal filtrés, dégradation du signal GPS, ...

Pour les curieux, explication de la dernière colonne (Cor pente bis %): c'est basé sur l'hypothèse que le D+ et D- sont répartis en moyenne sur les 2/3 du parcours, et le 1/3 restant est plat. Du coup, la distance "réelle" (Dr), est obtenue à partir de la distance projetée sur l'horizontale (Dh), en appliquant le théorème de Pythagore:
Dr = Dh/3 + ?((D+ + D-)²+4/9*Dh²) et (Cor pente bis %) = (Dr/Dh-1)*100
Avec cette petite formule "ad hoc", vous pouvez calculer vous même la distance corrigée de la pente à mieux que le %, avec juste la distance mesurée par l'Ambit, et le D+ et D-.

Voilà, tout, tout, tout, vous savez tout sur le calcul de distance de l'Ambit.
Dernière édition par cloclo le 29 Juil 2012, 18:49, édité 26 fois au total.

Messagepar Antoine_974 » sa fiche K
» 15 Juil 2012, 11:47

Je m'étais confortablement installé dans mon fauteuil pour lire tout le post en me disant que cloclo allait mettre beaucoup de temps à nous expliquer et en fait il nous la joue à la série américaine avec des épisodes !!!

arggghhhhhh

Messagepar cloclo » sa fiche K
» 15 Juil 2012, 18:29

Regroupement des épisodes dans le 1er post pour plus de lisibilité.
Dernière édition par cloclo le 16 Juil 2012, 18:20, édité 3 fois au total.

Messagepar Eric Kb » sa fiche K
» 15 Juil 2012, 19:41

J'ai déjà compris qu'il faut partir 16 mètres avant la ligne de départ :D :D

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 09:38

Regroupement des épisodes dans le 1er post pour plus de lisibilité.
Dernière édition par cloclo le 16 Juil 2012, 18:20, édité 1 fois au total.

Messagepar Antoine_974 » sa fiche K
» 16 Juil 2012, 10:07

C'est hyper intéressant à mon goût : merci.

Par contre, sur quelles bases est déterminé l'EHPE ? c'est une donnée empirique de l'Ambit, c'est lié à un calcul en fonction de la vitesse ?

et pourquoi avoir décidé que l'on ne tient pas compte des points si la distance est < 2 x EHPE ??

Plein de questions se bousculent !!

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 10:17

Antoine26 a écrit:Sur quelles bases est déterminé l'EHPE ? c'est une donnée empirique de l'Ambit, c'est lié à un calcul en fonction de la vitesse ?


Non, c'est une donnée standard GPS. Voir ici si intéressé:
http://en.wikipedia.org/wiki/Error_anal ... ing_System

Antoine26 a écrit:Pourquoi avoir décidé que l'on ne tient pas compte des points si la distance est < 2 x EHPE ?

C'est pour justement écarter les points qui ressemblent à un parcours d'ivrogne, et ainsi lisser la trace. Tant que les points sont trop rapprochés, l'erreur de position GPS va influer sur le calcul de la distance. Maintenant, pourquoi Suunto a choisi 2*EHPE, et pas simplement EHPE, va savoir. Et je n'ai aucune envie de décrypter ce que fait Garmin, si jamais tu avais cette question en stock :mrgreen:

Messagepar Antoine_974 » sa fiche K
» 16 Juil 2012, 11:21

Donc on est bien d'accords que Suunto fait 2x EHPE alors que d'autres ont un coefficient multiplicateur plus faible ?!?

Et, si je comprends bien, sur le parcours du TGV ce filtre a diminué la distance de 5 km (55 km sur la Suunto pour 60 km en réalité) ?!?

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 11:36

Antoine26 a écrit:Donc on est bien d'accords que Suunto fait 2x EHPE alors que d'autres ont un coefficient multiplicateur plus faible ?!?

Houla, tu vas vite en besogne dans tes conclusions. Je crois avoir démontré ce que Suunto fait, mais aucune idée de ce que les autres font, et je n'ai aucune envie de la savoir. :wink:

Antoine26 a écrit:Et, si je comprends bien, sur le parcours du TGV ce filtre a diminué la distance de 5 km (55 km sur la Suunto pour 60 km en réalité) ?!?

Exact. Mais ici aussi, comment savoir où se trouve la réalité? Je pense honnêtement que ni 55, ni 60 sont bons. 55 un poil trop faible, car avec l'algo de Suunto que je viens de décrypter, c'est probable que ça coupe quelques lacets (à moins que ce soit toi qui ai coupé les lacets :wink: ). Mais de là à être plus court de 5 km, pas sur. Par contre, il reste la piste de la prise en compte du dénivelé dans le calcul de la distance, dont je n'ai pas encore parlé. Juste vite fait sur le gaz, ni l'Ambit, ni aucun autre logiciel SportTracks/RubiTrack/... ne prend en compte le dénivelé (ou pente si tu préfères) pour le calcul de distance, excepté Course Generator. Mais cette correction ne va dépasser 1% que si la pente moyenne du trail dépasse les 15%. Si tu me dégotes la trace de ce même TGV d'un mec qui avait une Garmin 310XT, peut-être que je me pencherai sur la différence 55/60, pas sûr :roll:

Messagepar montant » sa fiche K
» 16 Juil 2012, 11:38

Antoine26 a écrit:Donc on est bien d'accords que Suunto fait 2x EHPE alors que d'autres ont un coefficient multiplicateur plus faible ?!?

Et, si je comprends bien, sur le parcours du TGV ce filtre a diminué la distance de 5 km (55 km sur la Suunto pour 60 km en réalité) ?!?


Toutes les informations dégottées par cloclo sont super intéressantes, et elles nous font rentrer dans des subtilités que nous ne pouvions pas effleurer avant. Et pour ce qui est du cas du TGV, 55 km avec le filtre Suunto semble une sous-estimation de la réalité, mais si les 60 km sont mesurées à partir de "la trace de l'ivrogne", ils semblent discutables eux aussi. La vérité est peut-être entre ces deux valeurs, 55 et 60 ?

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 11:42

montant a écrit:Toutes les informations dégottées par cloclo sont super intéressantes, et elles nous font rentrer dans des subtilités que nous ne pouvions pas effleurer avant.

Merci, mais je ne dirai jamais assez comment ton script python (un poil modifié) m'a permis de dégotter tout ça :D

Messagepar montant » sa fiche K
» 16 Juil 2012, 11:49

Autre élément d'information : j'ai participé à "Un Tour en Terre du Jura", il y a une semaine.

Tout le long du parcours du samedi, et jusqu'à mon abandon :oops: au km 48, j'étais dans les clous avec l'Ambit au poignet par rapport aux indications de l'organisation. Si j'avais été au bout, vu ce qui c'était passé aux divers points de contrôle que j'ai ralliés, j'aurais trouvé les 58 km annoncés officiellement.

Les montres Garmin du peloton ont trouvé une distance plus grande, mais portée à 59-60, pas plus.

Bref, sur le cas de cette course, l'Ambit est restée en dessous de ce que les Garmin annonçaient, mais pas si loin que ça en dessous et en gros les montres étaient plutôt d'accord. Si j'envoie ma trace dans Sporttrack, mon 48 km se mue en 52 km, ce qui ressemble au +5 km observé sur la trace du TGV, mais les montres Garmin proposent elles, une mesure intermédiaire entre la Suunto Ambit et Sporttrack, et leur mesure intermédiaire m'a l'air... un bon compromis.

Et c'était un parcours très pentu : 3200D+ au km 48 quand j'ai jeté l'éponge.

Messagepar montant » sa fiche K
» 16 Juil 2012, 11:51

cloclo a écrit:
montant a écrit:Toutes les informations dégottées par cloclo sont super intéressantes, et elles nous font rentrer dans des subtilités que nous ne pouvions pas effleurer avant.

Merci, mais je ne dirai jamais assez comment ton script python (un poil modifié) m'a permis de dégotter tout ça :D


Merci à mon tour, je suis content à chaque fois que ce script rend service :)

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 12:57

montant a écrit:Et c'était un parcours très pentu : 3200D+ au km 48 quand j'ai jeté l'éponge.

A la louche, la correction due à la pente est de sqrt(1+(3.2/24)^2), soit 0.8%.
Pentu certes, mais pas de quoi changer ta conclusion :wink:

Messagepar Antoine_974 » sa fiche K
» 16 Juil 2012, 13:11

montant a écrit: mais si les 60 km sont mesurées à partir de "la trace de l'ivrogne", ils semblent discutables eux aussi. La vérité est peut-être entre ces deux valeurs, 55 et 60 ?


Pourtant les logiciels tels que Rubitrack ou Sportrack filtrent aussi les traces et suppriment les écarts de l'ivrogne non ? le phénomène de lissage si je ne me trompe pas...

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 13:16

Antoine26 a écrit:Pourtant les logiciels tels que Rubitrack ou Sportrack filtrent aussi les traces et suppriment les écarts de l'ivrogne non ? le phénomène de lissage si je ne me trompe pas...

Justement non (encore une légende urbaine :P ). Je me suis amusé à estimer la distance comme je l'ai fait dans mon fichier excel (simple somme des distances, sans lissage aucun), avec cette fois la trace originale avec l'enregistrement toutes les secondes. Et pour ton TGV, je trouve 60.31 km, contre 60.55 pour SportTracks. SportTracks a plein d'options de lissage, sauf pour le calcul de la distance.
D'autres questions :mrgreen:

Messagepar Antoine_974 » sa fiche K
» 16 Juil 2012, 13:49

cloclo a écrit:
Antoine26 a écrit:Pourtant les logiciels tels que Rubitrack ou Sportrack filtrent aussi les traces et suppriment les écarts de l'ivrogne non ? le phénomène de lissage si je ne me trompe pas...

Justement non (encore une légende urbaine :P ). Je me suis amusé à estimer la distance comme je l'ai fait dans mon fichier excel (simple somme des distances, sans lissage aucun), avec cette fois la trace originale avec l'enregistrement toutes les secondes. Et pour ton TGV, je trouve 60.31 km, contre 60.55 pour SportTracks. SportTracks a plein d'options de lissage, sauf pour le calcul de la distance.
D'autres questions :mrgreen:


Mon Dieu on nous aurait menti alors ???? on est tous des ivrognes selon nos GPS et en fait on court beaucoup moins que ce que l'on croyait ?!?

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 15:54

Antoine26 a écrit:Mon Dieu on nous aurait menti alors ???? on est tous des ivrognes selon nos GPS et en fait on court beaucoup moins que ce que l'on croyait ?!?

A l'insu de notre plein gré :mrgreen:

Messagepar gdraid » sa fiche K
» 16 Juil 2012, 17:53

cloclo a écrit:
Antoine26 a écrit:Mon Dieu on nous aurait menti alors ???? on est tous des ivrognes selon nos GPS et en fait on court beaucoup moins que ce que l'on croyait ?!?

A l'insu de notre plein gré :mrgreen:


D'où l'utilité du contrôle de l'alcoolémie dans les prochaines épreuves de montagne :mrgreen:
Les alcoolos ne sont donc pas que sur la route :wink:

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 18:21

Regroupement des épisodes dans le 1er post pour plus de lisibilité. Nous en sommes pour l'instant à 3 épisodes, Dallas va continuer pendant tout l'été. Ah ben non :wink:

Messagepar Flo2Cannes » sa fiche K
» 16 Juil 2012, 20:13

Félicitations Cloclo pour ta démarche. Très instructif.
Après la "face cachée du calcul du D+", la face cachée du calcul du km :wink:

Messagepar cloclo » sa fiche K
» 16 Juil 2012, 20:19

Flo2Cannes a écrit:Après la "face cachée du calcul du D+", la face cachée du calcul du km :wink:

Merci Flo, mais je n'en suis qu'aux prémices. Après Suunto, il faudrait que j'attaque Garmin. Mais là, c'est autrement plus ardu, car Garmin ne livre pas ses données de façon aussi transparente que Suunto :?

Messagepar Guénaël » sa fiche K
» 17 Juil 2012, 07:49

Bravo et merci cloclo pour ce travail !
Je suis en vacances pour le moment, mais je le favorite (sic) pour lire tout ça à tête reposée.

HS (encore que) : j'ai l'impression depuis quelques temps (2 sem ?) que l'écart de distance entre l'Ambit et ST est plus faible (certaines fois ST donne une distance plus faible que la Suunto :shock: ) ... personne n'a remarqué ça ?

Messagepar cloclo » sa fiche K
» 17 Juil 2012, 08:31

Guénaël a écrit:HS (encore que) : j'ai l'impression depuis quelques temps (2 sem ?) que l'écart de distance entre l'Ambit et ST est plus faible (certaines fois ST donne une distance plus faible que la Suunto :shock: )

Il faudrait me donner quelques précisions techniques:
-version de firmware Ambit?
-version de SportTracks?
Je n'ai que la 2, et ne vais pas m'acheter la 3 juste pour ces études à la c.. :mrgreen:
Sinon, renvoies moi cette trace, je jetterai un coup d'oeil.

Messagepar cloclo » sa fiche K
» 17 Juil 2012, 08:35

Pour ceux qui ne veulent pas se farcir toute ma prose, j'ai rajouté en tête de gondole mes conclusions:

-la trace de l'Ambit en enregistrement 1s ressemble souvent à celle d'un ivrogne qui titube de droite à gauche, d'autant plus que la réception satellite est mauvaise. SportTracks(2), bien que disposant de plein d'options de lissage, n'en a pas pour le calcul de distance, et additionne simplement la distance entre points. Du coup, il va systématiquement surestimer la distance réelle.
-l'Ambit, quant à elle, ne va retenir pour le calcul de la distance que des points distants d'au moins deux fois l'erreur de positionnement GPS, ce qui revient de facto à un lissage de trace. Pour un parcours relativement droit et en terrain découvert, la distance donnée par l'Ambit va être précise. Pour un trail en terrain dense et avec nombreux virages, où la distance entre deux points retenus peut aller jusqu'à 50m (!), elle donnera une distance sous estimée, car aura tendance à couper les virages.
-ni l'Ambit, ni SportTracks(2), ne prennent en compte la correction de pente dans le calcul de distance, la distance étant celle projetée sur l'horizontale. Sur un trail dont la pente moyenne ne dépasse pas 15%, cette correction sera inférieure à 1%. Sur un Kilomètre vertical avec une pente de 50%, il faudra ajouter 10% pour obtenir la distance parcourue sur le terrain.

Messagepar Antoine_974 » sa fiche K
» 17 Juil 2012, 08:44

cloclo a oublié de conclure : c'est donc le bordel !!!

Ne vaut-il pas mieux un bon vieux footpod ?

Messagepar peky » sa fiche K
» 17 Juil 2012, 08:52

Bonjour,

tout d'abord un grand merci à cloclo pour le travail de décryptage et de formulation clairement compréhensible pour tous.

Il faut simplement courir et attendre les ravitos pour savoir à peu prés où on se situe.

Une fois franchi le porche d'arrivée, c'est fini!

Étonnant ce manque de précision surtout en regard du prix payé.
On en reste toujours à une estimation de la distance, qui en soit me convient.
Dernière édition par peky le 17 Juil 2012, 08:54, édité 1 fois au total.

Messagepar cloclo » sa fiche K
» 17 Juil 2012, 08:52

Antoine26 a écrit:cloclo a oublié de conclure : c'est donc le bordel !!!

Non, je crois simplement que certains attendent des miracles que la technologie GPS avec une antenne de surface aussi riquiqui que celle de l'Ambit ne peux pas fournir (idem à mon avis pour Garmin 610, fenix...).
Quant au footpod, c'est précis sur du plat, où la foulée est répétitive, mais peut-être moins sur un trail. Mais c'est un débat qui sort du cadre de ce fil :wink:

Messagepar montant » sa fiche K
» 17 Juil 2012, 09:01

Antoine26 a écrit:cloclo a oublié de conclure : c'est donc le bordel !!!

Ne vaut-il pas mieux un bon vieux footpod ?

Un footpod a ses limites aussi, et j'écris ça après avoir eu au poignet un polar rs800sd pendant 4 ans.
À partir des résultats de cloclo, j'aurais envie de penser qu'avec la methode actuelle de l'Ambit, mise à jour pour prendre à compte la pente, on aurait quelque chose de mieux que ce qu'on a aujourd'hui, et de pas mal du tout.

Messagepar Antoine_974 » sa fiche K
» 17 Juil 2012, 09:06

montant a écrit:
Antoine26 a écrit:cloclo a oublié de conclure : c'est donc le bordel !!!

Ne vaut-il pas mieux un bon vieux footpod ?

Un footpod a ses limites aussi, et j'écris ça après avoir eu au poignet un polar rs800sd pendant 4 ans.
À partir des résultats de cloclo, j'aurais envie de penser qu'avec la methode actuelle de l'Ambit, mise à jour pour prendre à compte la pente, on aurait quelque chose de mieux que ce qu'on a aujourd'hui, et de pas mal du tout.


ok je remballe mon footpod !! :)

Par contre, la maj nécessaire pour la prise en compte de la pente ne me semble pas très bien engagée quand je vois les échanges que j'ai eu avec le support qui me dit que le mauvais calcul de la distance est lié à une altitude de départ non calibrée... :evil:

Messagepar cloclo » sa fiche K
» 17 Juil 2012, 09:19

Antoine26 a écrit:Par contre, la maj nécessaire pour la prise en compte de la pente ne me semble pas très bien engagée quand je vois les échanges que j'ai eu avec le support qui me dit que le mauvais calcul de la distance est lié à une altitude de départ non calibrée... :evil:

Je crois que je vais demander à JMK de me faire embaucher chez Suunto :mrgreen:
Blague à part, la prise en compte de la pente est quant à elle loin d'être évidente à appliquer, car il faut super bien filtrer les micro variations d'altitude, sinon, tu vas te retrouver avec bien plus de distance que voulu.

Messagepar cga2 » sa fiche K
» 17 Juil 2012, 09:30

Bravo Cloclo pour le travail réalisé.

Ca permet de rélativisé un peu...

Nos montres se "trompent", les organisateurs aussi, c'est ce qui fait le charme de la course nature :wink:

Messagepar montant » sa fiche K
» 17 Juil 2012, 09:52

cloclo a écrit:
Antoine26 a écrit:Par contre, la maj nécessaire pour la prise en compte de la pente ne me semble pas très bien engagée quand je vois les échanges que j'ai eu avec le support qui me dit que le mauvais calcul de la distance est lié à une altitude de départ non calibrée... :evil:

Je crois que je vais demander à JMK de me faire embaucher chez Suunto :mrgreen:
Blague à part, la prise en compte de la pente est quant à elle loin d'être évidente à appliquer, car il faut super bien filtrer les micro variations d'altitude, sinon, tu vas te retrouver avec bien plus de distance que voulu.


La première approche que je tenterais si j'étais embauché chez Suunto également :-), ce serait de retenir les mêmes points pour l'altitude que ceux qu'ils retiennent actuellement pour le calcul de distance... et d'utiliser les variations d'altitude de l'alti-baro, pas celle du GPS. Cela pourrait donner une sélection d'altitudes pas mal pour prendre en compte la pente.

Messagepar gdraid » sa fiche K
» 17 Juil 2012, 09:58

cloclo a écrit:
Antoine26 a écrit:Par contre, la maj nécessaire pour la prise en compte de la pente ne me semble pas très bien engagée quand je vois les échanges que j'ai eu avec le support qui me dit que le mauvais calcul de la distance est lié à une altitude de départ non calibrée... :evil:

Je crois que je vais demander à JMK de me faire embaucher chez Suunto :mrgreen:
Blague à part, la prise en compte de la pente est quant à elle loin d'être évidente à appliquer, car il faut super bien filtrer les micro variations d'altitude, sinon, tu vas te retrouver avec bien plus de distance que voulu.


Chapeau l'ami cloclo :!: :roll:
Quelle culture :mrgreen:
Dommage que tu sois au chômage :cry:

J'espère pour toi, que Suunto et bien d'autres, consultent Kikouroù :lol: :lol: :lol:
JC

Messagepar cloclo » sa fiche K
» 17 Juil 2012, 10:03

montant a écrit:La première approche que je tenterais si j'étais embauché chez Suunto également :-), ce serait de retenir les mêmes points pour l'altitude que ceux qu'ils retiennent actuellement pour le calcul de distance... et d'utiliser les variations d'altitude de l'alti-baro, pas celle du GPS. Cela pourrait donner une sélection d'altitudes pas mal pour prendre en compte la pente.

Tout à fait. Et si tu veux tester ce protocole, tu peux utiliser Course Generator de patrovite qui prend en compte la correction de pente dans le calcul de distance, en lui injectant le fichier gpx filtré à la sauce Cloclo. D'ailleurs, n'hésite pas à me demander la version de ton script modifié par mes soins.

Messagepar Antoine_974 » sa fiche K
» 17 Juil 2012, 10:16

gdraid a écrit:
J'espère pour toi, que Suunto et bien d'autres, consultent Kikouroù :lol: :lol: :lol:
JC


J'espère aussi pour nous ! ils corrigeraient l'Ambit selon les recherches de cloclo et de montant !

Messagepar cloclo » sa fiche K
» 17 Juil 2012, 10:23

Antoine26 a écrit:
gdraid a écrit:Dommage que tu sois au chômage :cry:
J'espère pour toi, que Suunto et bien d'autres, consultent Kikouroù :lol: :lol: :lol:
JC

J'espère aussi pour nous ! ils corrigeraient l'Ambit selon les recherches de cloclo et de montant !

Bon, vous avez pas fini un peu :D La découverte du boson de Higgs m'assure quelques subsides :mrgreen:
Et je pense avoir montré qu'il n'y a finalement pas grand chose à corriger à l'Ambit, la correction de pente, ce n'est nécessaire que pour les grands malades qui se tapent des trails au moins du calibre de la Montagn'Hard :P

Messagepar montant » sa fiche K
» 17 Juil 2012, 11:23

cloclo a écrit:
montant a écrit:La première approche que je tenterais si j'étais embauché chez Suunto également :-), ce serait de retenir les mêmes points pour l'altitude que ceux qu'ils retiennent actuellement pour le calcul de distance... et d'utiliser les variations d'altitude de l'alti-baro, pas celle du GPS. Cela pourrait donner une sélection d'altitudes pas mal pour prendre en compte la pente.

Tout à fait. Et si tu veux tester ce protocole, tu peux utiliser Course Generator de patrovite qui prend en compte la correction de pente dans le calcul de distance, en lui injectant le fichier gpx filtré à la sauce Cloclo. D'ailleurs, n'hésite pas à me demander la version de ton script modifié par mes soins.


Cela m'intéresse d'avoir la version modifiée du script et de jouer avec Course Generator. Si cela mène quelque part, je pourrais ajouter une option en ligne de commande pour que le gpx généré soit celui filtré selon ta méthode, et tout ça pourrait servir de base à un retour utilisateur très argumenté auprès de Suunto.

Messagepar cloclo » sa fiche K
» 17 Juil 2012, 13:57

montant a écrit:Cela m'intéresse d'avoir la version modifiée du script.

Ok, envoie moi par MP ton adresse E-mail, et je t'envoies ça se soir.

Messagepar Antoine_974 » sa fiche K
» 19 Juil 2012, 08:21

Petite réponse du support Suunto :

Hello Antoine,

Thanks for your feedback. We will be further investigating the distance calculation after the summer period.

Regards,

The Suunto Ambit team

Suivant Retour vers [Matos] Matériel

Accueil - Haut de page - Aide - Contact - Mentions légales - Version grand écran - 0.01 sec