Du calcul de la distance sur la Suunto Ambit

par **cloclo** » 19 Juil 2012, 22:48

Dallas continue, un épisode de plus, le 4 (dans le premier post du fil). Où l'on voit que pour 13 traces de Kikous, même si l'écart entre la distance calculée par l'Ambit et ce que donne SportTracks à partir du fichier xml peut atteindre jusqu'à 23%, la distance recalculée par ST à partir du fichier filtré à la sauce Cloclo est en accord avec l'Ambit au % près. Maintenant, dans le cas des 23%, surement que la distance Ambit est sous évaluée, mais de combien, pas vraiment moyen de savoir :cry:

par **cloclo** » 20 Juil 2012, 10:31

Un très court épisode de plus, le 5, en début du fil: Comment Suunto utilise FuseSpeed pour pallier aux défaillances GPS.

par **montant** » 20 Juil 2012, 11:56

Pour le cas de fix initial très mauvais pour certaines traces qui est évoqué dans les épisodes 4/5 du message initial du fil, pour ce qui me concerne, j'en ai observé le week-end du premier juillet, et il y a eu un bug assez général ce week-end là, qui se concrétisait à la fois avec des fix mauvais et des moves qui ne pouvaient pas être exportés vers movescount.

Après une mise à jour de moveslink et un reset du GPS, le lundi ou le mardi, les deux phénomènes sont rentrés dans l'ordre pour moi.

Peut-être que les traces avec un mauvais fix initial que tu as étudiées ont été créees autour de ce week-end du 1er juillet ?

par **Antoine_974** » 20 Juil 2012, 12:00

cloclo a écrit:Un très court épisode de plus, le 5, en début du fil: Comment Suunto utilise FuseSpeed pour pallier aux défaillances GPS.

@cloclo : bravo pour l'analyse : j'adore.

Par contre, sur l'intérêt de Fusespeed : j'ai un parcours que je connais et qui fait selon Rubitrack 18,96 km avec 1 100 D+ : que je le fasse avec ou sans fusespeed j'obtiens le même mesure par la Suunto 17,4 km et je sais que ce parcours est significatif sur de la perte de vitesse en montée car il y a des passages où t'es pas loin d'être à 4 pattes tellement il est pentu...

Qu'en conclure selon toi ? Que Fusespeed n'a que d'intérêt pour pallier en vitesse élevée ?!?

par **cloclo** » 20 Juil 2012, 12:12

montant a écrit:Peut-être que les traces avec un mauvais fix initial que tu as étudiées ont été créees autour de ce week-end du 1er juillet ?

Oui:
-cga2 01/07
-Romain33 relief: 30/06
Ca commence à conforter l'hypothèse du "leap second" évoquée sur Watchuseek, et auquelle j'avais d'abord du mal à croire.

par **cloclo** » 20 Juil 2012, 12:16

Antoine26 a écrit:Je sais que ce parcours est significatif sur de la perte de vitesse en montée car il y a des passages où t'es pas loin d'être à 4 pattes tellement il est pentu...
Qu'en conclure selon toi ? Que Fusespeed n'a que d'intérêt pour pallier en vitesse élevée ?!?

Attention, ne pas confondre "perte de vitesse" et "perte de signal GPS". Je répète, FuseSpedd entre en jeu pour pallier une perte de signal GPS quelque soit ta vitesse (a tu eu ça?), j'ai rien dit de plus.

par **Antoine_974** » 20 Juil 2012, 12:20

cloclo a écrit:
Antoine26 a écrit:Je sais que ce parcours est significatif sur de la perte de vitesse en montée car il y a des passages où t'es pas loin d'être à 4 pattes tellement il est pentu...
Qu'en conclure selon toi ? Que Fusespeed n'a que d'intérêt pour pallier en vitesse élevée ?!?

Attention, ne pas confondre "perte de vitesse" et "perte de signal GPS". Je répète, FuseSpedd entre en jeu pour pallier une perte de signal GPS (a tu eu ça?), j'ai rien dit de plus.

Effectivement je pensais que Fusespeed servait aussi en cas de perte de vitesse.

Pour les pertes GPS : je sais qu'avant, quand je faisais ce parcours avec un 310XT, il y a un passage de 500m durant lesquels il me disait perte de signal GPS (ce que ne dit pas l'Ambit alors perd elle ou pas et l'indique t elle ou pas ?) : donc si on part du principe qu'il y a perte du signal aussi sur l'Ambit, qu'il y ait Fusespeed ou pas la distance mesurée est la même ?!?

par **cloclo** » 20 Juil 2012, 12:31

Antoine26 a écrit: Pour les pertes GPS : je sais qu'avant, quand je faisais ce parcours avec un 310XT, il y a un passage de 500m durant lesquels il me disait perte de signal GPS (ce que ne dit pas l'Ambit alors perd elle ou pas et l'indique t elle ou pas ?) : donc si on part du principe qu'il y a perte du signal aussi sur l'Ambit, qu'il y ait Fusespeed ou pas la distance mesurée est la même ?!?

Si tu as bien suivi ce que j'ai dit dans 5/, tu peux déterminer par toi même si l'Ambit a perdu le signal ou non: tu ouvres le fichier xml, et tu regardes bien dedans. Dans le cas de perte, tu n'as plus de <sample> avec lat,long pendant un moment, mais par contre la distance est incrémentée toutes les secondes. Au contraire de quand tu as le GPS, où la distance n'est incrémentée dans le xml que toutes les fois où entre points, elle dépasse 2*EHPE.
Maintenant, avec quelle précision elle arrive à calculer la distance pendant l'absence de GPS avec FuseSpeed activée, je dirai moins de 5% d'erreur. Ce qui fait 25 m dans ton cas où la perte est sur 500m. 25m sur 17.4 km, c'est 0.15%, on oublie. Maintenant sans FuseSpeed, elle doit simplement tracer une droite entre les deux points avant/après perte de signal. Si entre les deux, il y a plein de virage, l'erreur peut aller jusqu'à 25% (à la louche), ce qui fait 125 m d'erreur. 125 m sur 17.4 km, c'est toujours en dessous du %. On oublie, ou pas :mrgreen:

par **Antoine_974** » 20 Juil 2012, 12:38

arggghhh je l'ai plus le xml : j'ai pu qu'à retourner faire le parcours !!!!!!

Par contre c'est pas prévu avant début Août car dans ma prépa GRP je vais me faire 2 WE choc à compter de demain et le WE prochain.

par **cloclo** » 20 Juil 2012, 12:43

Antoine26 a écrit:arggghhh je l'ai plus le xml : j'ai pu qu'à retourner faire le parcours !!!!!!

Tous les utilisateurs d'Ambit seraient bien avisés de garder leurs fichier xml (ça coute pas cher, l'espace disque, maintenant), car si vous avez lu ma prose en début de ce fil, vous devriez savoir maintenant qu'avec un peu de jugeotte, on peut y retrouver toutes les infos, même quand FuseSpeed a repris le relais sur le GPS.

par **cloclo** » 20 Juil 2012, 18:32

cloclo a écrit:
montant a écrit:Peut-être que les traces avec un mauvais fix initial que tu as étudiées ont été créees autour de ce week-end du 1er juillet ?

Oui:
-cga2 01/07
-Romain33 relief: 30/06
Ca commence à conforter l'hypothèse du "leap second" évoquée sur Watchuseek, et auquelle j'avais d'abord du mal à croire.

Petite précision:
Si l'Ambit a été sensible à l'introduction de la "leap second" le 30 juin, c'est probablement 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:
http://en.wikipedia.org/wiki/Global_Pos ... ap_seconds
Et dans ce cas, une différence de 1s correspond à environ 500 m sur le terrain.

par **cloclo** » 20 Juil 2012, 22:45

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.

Et voilà, le dernier épisode (6) qui traite de la prise en compte de la pente dans le calcul de la distance réellement parcourue sur le terrain vient d'être ajouté à la saga :wink:

par **montant** » 21 Juil 2012, 09:58

Merci Cloclo pour ce travail d'analyse très impressionnant.

Sur ma trace de la première étape (écourtée, abandon) de l'UTTJ, filtrée grâce à ton édition du script python, puis injectée dans CourseGenerator, la distance passe de 47,9 km à 48,78 km soit un ajustement de 1,8%, ce qui n'est pas rien.

Cela confirme, pour moi, 1) que l'UTTJ était pentu

, et 2) qu'une prise en compte de la pente "à la course generator" serait bienvenue de la part de Suunto, pour ce type de trace.

Je vais faire un retour à Suunto dans ce sens.

(en début de semaine prochaine, je mettrai une version 1.4 du script à disposition de tout le monde, avec tes améliorations)

par **cloclo** » 21 Juil 2012, 10:12

montant a écrit:En début de semaine prochaine, je mettrai une version 1.4 du script à disposition de tout le monde, avec tes améliorations

Merci, il y en a déjà qui attendent après sur watchuseek :wink:

par **montant** » 21 Juil 2012, 10:51

cloclo a écrit:
montant a écrit:En début de semaine prochaine, je mettrai une version 1.4 du script à disposition de tout le monde, avec tes améliorations

Merci, il y en a déjà qui attendent après sur watchuseek

Ok, ok, devant la demande populaire, j'ai accéléré le mouvement, la version 1.4 d'ambit2gpx.py est disponible dès maintenant ici : http://code.google.com/p/ambit2gpx/downloads/list

Je passe sur watchuseek pour faire la même annonce :-)

par **cloclo** » 21 Juil 2012, 20:44

Eureka!
Dans l'épisode 6, je disais que la corrélation entre "écart de distance Ambit/ST" et "correction de pente" (ex: 23% vs 5% pour la trace paulotrail-bauges) me paraissait purement fortuite. En fait, même si la correction de pente n'explique absolument pas l'écart Ambit/ST, la corrélation n'est pas si fortuite que ça.

Dans un dré dans le pentu, la vitesse moyenne est assez faible (4 km/h dans le cas présent), ce qui fait que les enregistrements sont espacés en moyenne de 1 m en enregistrement à chaque seconde, contre 3 m à 11 km/h. A même erreur de GPS (EHPE, 9 m ici), l'Ambit va filtrer beaucoup plus de points pour les vitesses élevées, alors que ST va additionner la distance de points distants de 1 m (cas 4 km/h) ou 3 m (cas 11 km/h), chacun affecté d'une erreur de 9 m environ. D'où l'augmentation de l'écart distance Ambit/ST plus la vitesse est lente.

Ca explique surement aussi la différence de distance calculée par l'Ambit sur le MMB (noté par paulotrail) suivant le temps mis. Les plus rapides ont une distance mesurée plus longue. Ca parait contre intuitif de prime abord, mais je pense que c'est du au fait que pour les plus rapides, l'Ambit filtre en moyenne moins.

par **montant** » 22 Juil 2012, 09:33

cloclo a écrit:Eureka!
Dans l'épisode 6, je disais que la corrélation entre "écart de distance Ambit/ST" et "correction de pente" (ex: 23% vs 5% pour la trace paulotrail-bauges) me paraissait purement fortuite. En fait, même si la correction de pente n'explique absolument pas l'écart Ambit/ST, la corrélation n'est pas si fortuite que ça.

Dans un dré dans le pentu, la vitesse moyenne est assez faible (4 km/h dans le cas présent), ce qui fait que les enregistrements sont espacés en moyenne de 1 m en enregistrement à chaque seconde, contre 3 m à 11 km/h. A même erreur de GPS (EHPE, 9 m ici), l'Ambit va filtrer beaucoup plus de points pour les vitesses élevées, alors que ST va additionner la distance de points distants de 1 m (cas 4 km/h) ou 3 m (cas 11 km/h), chacun affecté d'une erreur de 9 m environ. D'où l'augmentation de l'écart distance Ambit/ST plus la vitesse est lente.

Ca explique surement aussi la différence de distance calculée par l'Ambit sur le MMB (noté par paulotrail) suivant le temps mis. Les plus rapides ont une distance mesurée plus longue. Ca parait contre intuitif de prime abord, mais je pense que c'est du au fait que pour les plus rapides, l'Ambit filtre en moyenne moins.

Cela tient très bien la route comme analyse.
Et face à ce constat, la question suivante est : quel ajustement les ingénieurs Suunto pourraient/devraient faire à leur algorithme pour l'améliorer pour le cas des sections à forte pente courrues lentement ?

par **Antoine_974** » 22 Juil 2012, 09:42

montant a écrit:
cloclo a écrit:Eureka!
Dans l'épisode 6, je disais que la corrélation entre "écart de distance Ambit/ST" et "correction de pente" (ex: 23% vs 5% pour la trace paulotrail-bauges) me paraissait purement fortuite. En fait, même si la correction de pente n'explique absolument pas l'écart Ambit/ST, la corrélation n'est pas si fortuite que ça.

Dans un dré dans le pentu, la vitesse moyenne est assez faible (4 km/h dans le cas présent), ce qui fait que les enregistrements sont espacés en moyenne de 1 m en enregistrement à chaque seconde, contre 3 m à 11 km/h. A même erreur de GPS (EHPE, 9 m ici), l'Ambit va filtrer beaucoup plus de points pour les vitesses élevées, alors que ST va additionner la distance de points distants de 1 m (cas 4 km/h) ou 3 m (cas 11 km/h), chacun affecté d'une erreur de 9 m environ. D'où l'augmentation de l'écart distance Ambit/ST plus la vitesse est lente.

Ca explique surement aussi la différence de distance calculée par l'Ambit sur le MMB (noté par paulotrail) suivant le temps mis. Les plus rapides ont une distance mesurée plus longue. Ca parait contre intuitif de prime abord, mais je pense que c'est du au fait que pour les plus rapides, l'Ambit filtre en moyenne moins.

Cela tient très bien la route comme analyse.
Et face à ce constat, la question suivante est : quel ajustement les ingénieurs Suunto pourraient/devraient faire à leur algorithme pour l'améliorer pour le cas des sections à forte pente courrues lentement ?

Peut être intégrer dans l'algorithme de ne pas corriger avec l'EHPE si la vitesse est trop lente ou ne pas utiliser les données GPS en cas de vitesse lente et n'utiliser que les données Fusespeed ?!?

Des possibilités, il y en a plusieurs encore faudrait-il que Suunto entende nos demandes.

par **cloclo** » 22 Juil 2012, 10:00

Antoine26 a écrit:Des possibilités, il y en a plusieurs encore faudrait-il que Suunto entende nos demandes.

Là, je crois que vous pouvez toujours rêver. Elle est parfaite, cette montre, y'a rien à changer :mrgreen:

par **montant** » 22 Juil 2012, 13:41

Peut-etre que la solution passe par Fusespeed, mais ce serait paradoxal tout de meme : dans la version 1.5 du firmware, Suunto a fait le choix de renoncer a Fusespeed pour les petites vitesses pour ce qui etait du calcul de la vitesse instantanee, et la, il faudrait le reconsiderer, a ces memes petites vitesses, pour le calcul de la vitesse globale ? Peut-etre, mais ce n'est pas gagne.

J'espere que Suunto va prendre en compte nos retours, mais je ne pars pas du principe qu'il suffiit qu'ils se penchent sur nos problemes pour trouver une solution, nos problemes me paraissent assez delicats a traiter numeriquement. Et apres tout, une des choses qui ressort de l'analyse de cloclo, en tout cas pour moi, c'est que l'algorithme en place actuellement est deja assez subtil, et ne souffre pas de choix clairement discutables. Pour l'instant, la piste d'amelioration la plus serieuse que je vois est de rester sur la methode actuelle, avec ajout de prise en compte de la pente, ce qui allongerait la distance globale evaluee pour un trail de 50 km bien pentu, et couru aux allures de modestes trailers comme moi, et pas sur les bases de Kilian, de 1 a 2 %.

par **Antoine_974** » 22 Juil 2012, 13:54

Ils pourraient effectivement calculer une dIstance corrigée à chaque prise de GPS avec le calcul du triangle rectangle. Le côté opposé serait donné par l'altimètre et s'il n''y a pas de différence entre 2 mesures de D+ le calcul aboutirait à une hypothénuse = côté adjacent.

par **cloclo** » 22 Juil 2012, 14:00

FuseSpeed, laissez tomber pour les petites vitesses en trail. Le plus souvent, en montée, on mets les mains dans le dos, et dans ce cas, le concept même d'accéléromètre au poignet ne marche plus.

La seule amélioration possible, en sus de celle de la correction de pente, serait de ne pas avoir un filtre a*EHPE, où a est fixé à 2, mais où a serait fonction de la vitesse moyenne. Mais quelle fonction (surement pas linéaire), et en plus, ça demanderait des mois et des mois de validation. Pour toutes ces raisons, je pense que ça va être statu quo.

par **montant** » 22 Juil 2012, 14:05

cloclo a écrit:FuseSpeed, laissez tomber pour les petites vitesses en trail. Le plus souvent, en montée, on mets les mains dans le dos, et dans ce cas, le concept même d'accéléromètre au poignet ne marche plus.

La seule amélioration possible serait de ne pas avoir un filtre a*EHPE, où a est fixé à 2, mais où a serait fonction de la vitesse moyenne. Mais quelle fonction (surement pas linéaire), et en plus, ça demanderait des mois et des mois de validation. Pour toutes ces raisons, je pense que ça va être statu quo.

Prendre en compte la pente ne casserait pas une patte a un canard pour Suunto et me suffirait personnellement.

par **cloclo** » 22 Juil 2012, 14:12

montant a écrit:Prendre en compte la pente ne casserait pas une patte a un canard pour Suunto et me suffirait personnellement.

T'as dégainé trop vite, avant que j'ai le temps de rajouter "en sus de la correction de pente". Sur ce point, je suis d'accord avec toi :wink:

par **Antoine_974** » 22 Juil 2012, 15:01

Antoine26 a écrit:Ils pourraient effectivement calculer une dIstance corrigée à chaque prise de GPS avec le calcul du triangle rectangle. Le côté opposé serait donné par l'altimètre et s'il n''y a pas de différence entre 2 mesures de D+ le calcul aboutirait à une hypothénuse = côté adjacent.

Je me la raconte mais j'aime bien me citer car je trouve que mon idée est excellente !!!!!

par **cloclo** » 22 Juil 2012, 15:06

Antoine26 a écrit:Je me la raconte mais j'aime bien me citer car je trouve que mon idée est excellente !!!!!

Et avec ton idée, tu trouves combien pour ton TGV :?:

par **Antoine_974** » 22 Juil 2012, 15:12

j'y suis j'suis !!

par **Antoine_974** » 22 Juil 2012, 15:48

bon j'arrive toujours pas à faire tourner le script python.

cloclo : tu peux m'envoyer le fichier du TGV retravaillé xml par mail stp ?

Merci

par **Antoine_974** » 22 Juil 2012, 19:17

Antoine26 a écrit:
Antoine26 a écrit:Ils pourraient effectivement calculer une dIstance corrigée à chaque prise de GPS avec le calcul du triangle rectangle. Le côté opposé serait donné par l'altimètre et s'il n''y a pas de différence entre 2 mesures de D+ le calcul aboutirait à une hypothénuse = côté adjacent.

Merci à cloclo pour le fichier.

J'ai corrigé les distances avec le théorème de Pythagore qui dit que : c² = a² + b²

: pythagore.JPG (8.72 Kio) Consulté 988 fois

Dans notre analyse le b est la distance calculée par cloclo dans son fichier, la a la différence d'altitude de l'ambit (en valeur absolue) et le c la nouvelle distance calculée.

Donc en appliquant cette formule sur tous les enregistrements du fichier on passe de 55,6 km sur la TGV à : 56,41 km :cry:

je suis déçu !!!!

Il manque le fait que on ne tire pas une ligne droite quand on monte ou quand on descend mais je ne pense pas que cela rajouterait encore 4 km pour atteindre les 61 km annoncés.

par **cloclo** » 22 Juil 2012, 19:24

Antoine26 a écrit:Donc en appliquant cette formule sur tous les enregistrements du fichier on passe de 55,6 km sur la TGV à : 56,41 km

Bravo Antoine :lol:

Mais si tu avais bien lu l'épisode 6, tu aurai su que "Course Generator" de patrovite, qui utilise exactement ta méthode "révolutionnaire", donnait déjà 56.48 km avec correction de pente :wink:

Et pourquoi donc veux tu arriver à 61 km, les organisateurs, c'est comme la police, ils annoncent n'importe quoi (eh, c'est censé être de l'humour) :mrgreen:

par **Antoine_974** » 22 Juil 2012, 19:58

cloclo a écrit:
Antoine26 a écrit:Donc en appliquant cette formule sur tous les enregistrements du fichier on passe de 55,6 km sur la TGV à : 56,41 km

Bravo Antoine Mais si tu avais bien lu l'épisode 6, tu aurai su que "Course Generator" de patrovite, qui utilise exactement ta méthode "révolutionnaire", donnait déjà 56.48 km avec correction de pente
Et pourquoi donc veux tu arriver à 61 km, les organisateurs, c'est comme la police, ils annoncent n'importe quoi (eh, c'est censé être de l'humour)

ok je remballe :oops:

Je n'avais pas lu/compris que CG appliquait cette méthode.

Les 61km sont les km obtenus par plusieurs GPS autres que l'Ambit...

par **cloclo** » 22 Juil 2012, 20:11

Antoine26 a écrit:Je n'avais pas lu/compris que CG appliquait cette méthode.

A ta décharge, j'avais omis d'indiquer la méthode de CG, c'est vrai :wink:

Antoine26 a écrit:Les 61km sont les km obtenus par plusieurs GPS autres que l'Ambit...

Ca veut dire qu'il faudrait aussi se pencher sur:

-le calcul de la distance sur la Garmin 205
-le calcul de la distance sur la Garmin 301
-le calcul de la distance sur la Garmin 305
-le calcul de la distance sur la Garmin 310
-le calcul de la distance sur la Garmin 401
-le calcul de la distance sur la Garmin 405
-le calcul de la distance sur la Garmin 410
-le calcul de la distance sur la Garmin 610
-le calcul de la distance sur la Garmin 910
-le calcul de la distance sur la Polar RCX5
-le calcul de la distance sur la Polar RS300X
-le calcul de la distance sur la Nike+ Sportwatch
-le calcul de la distance sur la Timex Run Trainer
-le calcul de la distance sur la Timex IronMAN
-le calcul de la distance sur la Motorola MOTOACTV
-le calcul de la distance sur la Soleus
................................................................

Au secours, j'ai une autre vie que les GPS, même si certains pensent le contraire :roll:

par **montant** » 22 Juil 2012, 21:02

Quand je vais sur Garmin Connect, que j'utilise la fonction "explorer", je trouve des traces du TGV 2012 avec des montres Garmins. 61 km, c'est la fourchette max de l'échantillon que j'ai pu trouver. La médiane est plutôt à 58,5 km. Cela me donne de gros doutes sur les 61 km annoncés par les organisateurs.

Après prise en compte de la pente avec l'Ambit, on arrive à 56,5 km. Cela reste en dessous de la médiane des Garmins, mais on s'est bien rapproché tout de même, et la vérité est, à mon avis, quelque part dans cette fourchette 56,5-58,5.

C'est un exemple de plus qui me fait penser que, perso, je serais satisfait avec l'algo actuel avec ajout de la prise en compte de la pente.

par **Antoine_974** » 22 Juil 2012, 21:28

D'accord avec montant mais je trouve que 2xEHPE peut être trop fort quand on voit des EHPE à 20m donc ça fait 40 m de marge ça fait un sacré rayon d'erreur quand même.

par **cloclo** » 22 Juil 2012, 21:35

Antoine26 a écrit:D'accord avec montant mais je trouve que 2xEHPE peut être trop fort quand on voit des EHPE à 20m donc ça fait 40 m de marge ça fait un sacré rayon d'erreur quand même.

Alors comme exercice, tu nous calcule la distance de ton TGV avec un algo à 1*EHPE au lieu de 2*EHPE pour voir si tu retrouve "tes" 4 km perdus. Trop facile à partir du fichier xml :wink:

par **Antoine_974** » 22 Juil 2012, 21:42

cloclo a écrit:
Antoine26 a écrit:D'accord avec montant mais je trouve que 2xEHPE peut être trop fort quand on voit des EHPE à 20m donc ça fait 40 m de marge ça fait un sacré rayon d'erreur quand même.

Alors comme exercice, tu nous calcule la distance de ton TGV avec un algo à 1*EHPE au lieu de 2*EHPE pour voir si tu retrouve "tes" 4 km perdus. Trop facile à partir du fichier xml

Je pense pas que ce soit possible avec le fichier filtré que tu m'as envoyé car l'Ambit n'enregistre pas si la distance est < 2xEHPE me semble-t-il ?!?

par **cloclo** » 22 Juil 2012, 21:45

Antoine26 a écrit:Je pense pas que ce soit possible avec le fichier filtré que tu m'as envoyé car l'Ambit n'enregistre pas si la distance est < 2xEHPE me semble-t-il ?!?

J'ai bien dit à partir du xml, non :wink:

par **Antoine_974** » 22 Juil 2012, 21:53

cloclo a écrit:
Antoine26 a écrit:Je pense pas que ce soit possible avec le fichier filtré que tu m'as envoyé car l'Ambit n'enregistre pas si la distance est < 2xEHPE me semble-t-il ?!?

J'ai bien dit à partir du xml, non

Exact !!! Par contre j'arrive pas à lancer le python mais je vais essayer de me debrouiller avec Access...

par **Antoine_974** » 23 Juil 2012, 12:28

Tiens ce qui est marrant c'est que si j'importe le GPX du TGV généré par le script python dans openrunner il trouve 57,6 km !!!!

par **jsp75** » 23 Juil 2012, 22:50

J'ai une proposition
Laissez donc les formules de calcul, suunto ne vous rémunère pas pour votre travail.
Ils ont après tout des ingénieurs embauchés pour cela.

Il est un fait avéré, l'algorithme de cet appareil n'est pas encore totalement au point.
Le pourcentage d'erreur semble plus important que la concurrence.

Je trouve juste dommage que ces écarts génèrent une frustration chez les clients.
En même temps au prix de l'objet, je commence à comprendre pourquoi autant de littérature.

Qui est en ligne ?