Du calcul de la distance sur la Suunto Ambit

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.

Je pense que faire des retours aussi étayés que ceux de ce fil peut aider Suunto à aller dans le bon sens. Ils ont des ingénieurs et des retour d'infos comme celles de ce fil les aident plus qu'un simple "la distance globale mesurée par la montre me semble mauvaise".

J'ai pointé à Suunto ce fil ainsi que les discussions similaires qui se passent sur le forum Suunto de watchuseek, ils ont accusé bonne réception de tous ces retours utilisateurs, j'espère bien qu'ils vont s'y intéresser de près.

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.

Encore un copain à JMK

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.

Ca, ce n'est dit nulle part dans ce post. Je viens de commencer à m'intéresser aux données du Garmin 310XT que je me suis offert récemment, c'est pas non plus tout rose en cas de mauvaise réception satellite sous couvert végétal.

Simplement, on s'intéresse à l'Ambit:
1/ parce que pas mal de gens étaient interloqués par la différence de distance mesurée sur la montre et par SportTracks. Je pense avoir montré que la distance mesurée sur la montre est plus proche de la réalité, mais bon, tu ne captes peut-être pas tout mon charabia.
2/ parce que Suunto a eu le bon gout de mettre toutes ses données en clair dans le fichier xml, ce qui permet un "reverse engeneering" assez facile. Et du coup, on ne s'en prive pas. S'ils avaient voulu éviter ça, ils auraient crypté leur données, comme Garmin le fait.

En résumé, on continuera de s'amuser à décrypter autant que ça nous chante, jusqu'à l'arrivée des avocats Suunto

Je trouve juste dommage que ces écarts génèrent une frustration chez les clients.

Aucune frustration de ma part, je ne suis pas client

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

Intéressant. En regardant de près la trace générée par Openrunner, on se rend aisément compte qu'il applique un filtre ou algorithme sur les points importés (à comparer avec ce que j'ai posté dans l'épisode 2):



Donc clairement mieux que SportTracks. Si tu ajoutes les 800m du à la correction de pente (oui, j'ai vérifié qu'Openrunner ne le fait pas), on obtient 58.4 km. Pile dans la moyenne des Garmin ! Choisis ton camp, camarade

Tout ça pour dire qu'autant sur un marathon avec un espace dégagé on peut s'attendre à une précision de l'ordre de 1-2%, autant sur un trail en montagne avec des lacets et des zones boisées nombreuses, on peut facilement avoir des incertitudes de 5% avec une montre GPS de poignet.

Alors je te laisse imaginer avec une acquisition satellite toutes les mn au lieu de toutes les secondes !!!

Alors je te laisse imaginer avec une acquisition satellite toutes les mn au lieu de toutes les secondes !!!

Je pense que c'est clair pour tout le monde, et Suunto au premier chef, qu'une distance globale basée sur une acquisition toute les minutes ne peut-être qu'une approximation. Dans ce mode-là, la trace que l'on récupère permet de savoir où l'on est passé, approximativement encore une fois, et c'est tout.

Alors je te laisse imaginer avec une acquisition satellite toutes les mn au lieu de toutes les secondes !!!

Je pense que c'est clair pour tout le monde, et Suunto au premier chef, qu'une distance globale basée sur une acquisition toute les minutes ne peut-être qu'une approximation. Dans ce mode-là, la trace que l'on récupère permet de savoir où l'on est passé, approximativement encore une fois, et c'est tout.

Déjà à 1 s c'est une approximation en trail à 5 % donc on va tomber à 60% en mode 60s ?!?

@ cloclo : si tu veux des traces de 310XT j'en ai car j'en avais un avant de passer à l'Ambit... grosse erreur ce changement ?!?

à 1 s, si l'on attend de la part de Suunto que l'ajout de la prise en compte de la pente, la sous-estimation actuelle ne serait que de 1 à 2 %, pas 5%, sur un trail de 50 km, pentu, couru à petite allure (la mienne ).

Pour chercher des sous-estimations plus importantes, il faut chercher des cas "extrêmes" comme des courses se résumant à une montée sèche, avec mauvaises conditions de réception satellite (i.e.: le fameux EHPE élevé), etc

Bref, la sous-estimation actuelle peut monter jusqu'à 5%, voir plus, sur des types d'exercices bien précis, mais la sous-estimation constatée en moyenne est bien moindre que ça.

à 60 secondes, la sous-estimation sera plus grande, je ne sais pas de combien (ce serait intéressant de l'évaluer) mais cela me semble assez incontournable.

à 60 secondes, la sous-estimation sera plus grande, je ne sais pas de combien (ce serait intéressant de l'évaluer) mais cela me semble assez incontournable.

Tout à fait d'accord avec toi : incontournable

Tellement incontournable que ce devrait être de même pour toute montre qui annoncerait une fonctionnalité similaire, en étant pourtant basée sur la même puce GPS, à commencer par la Garmin Fenix.

Et on ne parle même pas ici de ce qui doit advenir du mode navigation sur toutes ces montres, quelles qu'elles soient, quand on a un fix gps par minute. Il vaut mieux ne pas avoir passé un croisement de sentiers entre deux fix

Et on ne parle même pas ici de ce qui doit advenir du mode navigation sur toutes ces montres, quelles qu'elles soient, quand on a un fix gps par minute. Il vaut mieux ne pas avoir passé un croisement de sentiers entre deux fix

La je m'adresse aux techniciens : étant donné que Fusespeed est dans la montre pourquoi ne pas l'utiliser pour compléter les mesures toutes les 60s ?

Et on ne parle même pas ici de ce qui doit advenir du mode navigation sur toutes ces montres, quelles qu'elles soient, quand on a un fix gps par minute. Il vaut mieux ne pas avoir passé un croisement de sentiers entre deux fix

La je m'adresse aux techniciens : étant donné que Fusespeed est dans la montre pourquoi ne pas l'utiliser pour compléter les mesures toutes les 60s ?

Je ne suis pas technicien mais je te réponds quand même : tu dois avoir raison, c'est une piste qui mériterait d'être explorée.

Le challenge, c'est de réussir à combiner au mieux les infos du GPS et de l'accéléromètre, et de basculer sur l'un quand on est aux limites de l'autre. Je crois que les ingénieurs Suunto et consorts ont pour des mois de travail (intéressant) devant eux pour trouver les bons réglages, mais peut-être que cela peut aboutir sur quelque chose de pas mal fichu.

Ils ont besoin de temps, et nous de patience

EDIT: il faudra que je fasse le test de voir ce qu'il advient de la navigation en mode 60 s, si ça se trouve Fusespeed intervient déjà (ainsi que la boussole d'ailleurs), et le fait bien, on ne sait jamais.

sauf qu'en quelques mois de "vrais" tests on l'a déjà pas mal éprouvée la montre et que les vrais tests avec de bons réglages auraient pu être faits avant et on en revient à la question de savoir s'ils ne l'ont pas sortie juste pour contre la Garmin...

Oui, et comme il est tout à fait possible que la sortie de la Fenix ait été précipitée à cause de l'Ambit, on n'est pas rendus

Oui, et comme il est tout à fait possible que la sortie de la Fenix ait été précipitée à cause de l'Ambit, on n'est pas rendus

Il me semble que c'est le contraire.

Les deux peuvent être vrais à la fois : sortie précipitée de l'Ambit, puis sortie prématurée de la Fenix. On verra bien !

Bon, j'ai suivi en diagonale le fil entre deux vacances, et de retour de rando, j'ai quelques questions/interrogations à vous soumettre ...

Si j'ai bien compris, la différence de distance entre l'Ambit et ST vient du fait que ST fait la somme de toutes le distances point à point pendant que la montre "filtre" la trace d'ivrogne en attendant que la distance entre deux points soit supérieure à 2*EHPE ...OK.
Pendant une semaine de rando pyrénéenne, j'ai enregistré mes traces en mode 1pt/min. Je sais que la distance est sous-estimée, mais je m'attendais à un écart faible entre Ambit et ST : la durée d'enregistrement est si longue que grosso modo la trace enregistrée est hyper filtrée (on perd les lacets des cols et on obtient plus du tout l'aspect trace titubante). Sauf que la distance mesurée par l'Ambit reste à chaque fois très inférieure à celle calculée par ST (plusieurs km sur une 20aine au total), tandis que la distance calculée par ST est systématiquement infrieure à celle calculée par CG (mais de peu quelques hectomètres).

Ai-je raté un truc ?
Un début d'explication ?

Merci pour vos retours

Pendant une semaine de rando pyrénéenne, j'ai enregistré mes traces en mode 1pt/min. La distance mesurée par l'Ambit reste à chaque fois très inférieure à celle calculée par ST (plusieurs km sur une 20aine au total), tandis que la distance calculée par ST est systématiquement infrieure à celle calculée par CG (mais de peu quelques hectomètres).

Ai-je raté un truc ?

Toute mon étude qui m'a permis de trouver l'algo 2*EHPE est basée sur des traces en mode 1pt/s. Donc je n'ai aucune idée comment l'Ambit gère la distance en mode 1pt/min.
Va falloir que je change le titre du fil pour être plus explicite. Tu peux toujours m'envoyer le log xml d'une trace en mode 1pt/min, je regarderai quand j'ai trois minutes.

Même si le fil a changé de titre, je vais verser une pièce au dossier du calcul de la distance en mode 1pt/mn : j'ai effectué une rando dans ce mode mercredi dernier, elle a été mesurée à 13,6 km par l'Ambit et cela devient 13,97 km dans SportTracks. (le lien du move sur movescount). L'écart n'est pas bien grand, on peut dire qu'ils sont d'accord.

Il y a quelques bizarreries de trace sur le move, mais qui correspondent à des pauses (parce qu'on avait soif, ou parce que les Vosges, c'est très beau) où j'avais oublié de mettre en pause le move sur la montre.

Le parcours en question était un parcours balisé par le club vosgien, et ils annonçaient 12 km. En enlevant les bizarreries dues aux pauses mal gérées et quelques aller/retour quand le groupe que nous étions s'étirait, l'Ambit, qui est au dessus de la distance annoncée (ça nous change ), n'aurait pas été loin.

Sinon, par rapport à des questions qui avaient été posées ici, j'ai trouvé la navigation correcte, et je trouve la trace tout à fait correcte pour des allures de marcheur ; elle ne s'est révélée très approximative que dans deux portions d'un kilomètre que j'ai dévalées en courant avec mon fils pour jouer. C'est plutôt une bonne nouvelle je trouve, pour les ultra-trails où le gros du peloton est à 4, 5 km/h, il se pourrait que la trace et la distance ne soit pas si mauvaises dans ce mode, à petite allure, qu'on ne pouvait le craindre.

Pas de problème, Joel, tu peux continuer à poster ici, j'ai juste changé le titre pour ne pas être accusé de vendre des vessies pour des lanternes

Pour une autre expérience sur le mode 1pt/min, allez voir là:
http://forums.watchuseek.com/f233/ambit ... 27213.html

Pendant une semaine de rando pyrénéenne, j'ai enregistré mes traces en mode 1pt/min. La distance mesurée par l'Ambit reste à chaque fois très inférieure à celle calculée par ST (plusieurs km sur une 20aine au total), tandis que la distance calculée par ST est systématiquement infrieure à celle calculée par CG (mais de peu quelques hectomètres).

Ai-je raté un truc ?

Toute mon étude qui m'a permis de trouver l'algo 2*EHPE est basée sur des traces en mode 1pt/s. Donc je n'ai aucune idée comment l'Ambit gère la distance en mode 1pt/min.
Va falloir que je change le titre du fil pour être plus explicite. Tu peux toujours m'envoyer le log xml d'une trace en mode 1pt/min, je regarderai quand j'ai trois minutes.

Oui oui, j'avais bien compris que tu parlais du 1pt/s ... mais il me semblait qu'on pouvait extrapoler certains résultats sur 1pt/min
Je t'envoie un xml par mail dans les min qui viennent.
(Merci d'avance )

Pas de problème, Joel, tu peux continuer à poster ici, j'ai juste changé le titre pour ne pas être accusé de vendre des vessies pour des lanternes

Pour une autre expérience sur le mode 1pt/min, allez voir là:
http://forums.watchuseek.com/f233/ambit ... 27213.html

Il a pas l'air super satisfait des mesures sur watchuseek.

Cloclo : dans ton titre tu peux rajouter du calcul de la distance et DU D+ : en effet j'ai systématiquement des différences de D+ entre la montre et Rubitrack avec toujours - sur l'Ambit que sur Rubitrack.
Même si j'ai bien compris que les différences de distances étaient liées à la "trace de l'ivrogne" : l'ivrogne prend pas 100 m de D + en 2xEHPE ?!?

Pas de problème, Joel, tu peux continuer à poster ici, j'ai juste changé le titre pour ne pas être accusé de vendre des vessies pour des lanternes

Pour une autre expérience sur le mode 1pt/min, allez voir là:
http://forums.watchuseek.com/f233/ambit ... 27213.html

Il a pas l'air super satisfait des mesures sur watchuseek.

Cloclo : dans ton titre tu peux rajouter du calcul de la distance et DU D+ : en effet j'ai systématiquement des différences de D+ entre la montre et Rubitrack avec toujours - sur l'Ambit que sur Rubitrack.
Même si j'ai bien compris que les différences de distances étaient liées à la "trace de l'ivrogne" : l'ivrogne prend pas 100 m de D + en 2xEHPE ?!?

Si Rubitrack mange les xml de l'Ambit mais se base sur l'altitude issue du GPS, et que l'Ambit est réglée pour donner ses indications, elle, en mode alti-baro, je fais plus confiance à la mesure de l'Ambit qu'à la mesure de Rubitrack.

Depuis mars, je n'ai rien à dire au D+ indiquée par l'ambit. On peut discuter de la distance, d'ailleurs on le fait , mais le D+ est plutôt nickel.

Je t'envoie un xml par mail dans les min qui viennent.

J'ai jeté un coup d'oeil vite fait sur le gaz, ouch, malgré une distance entre fix (1pt/min) supérieure en moyenne de 66 m (4 km/h), l'Ambit décide encore d'ignorer un paquet de points GPS pour le calcul de la distance. Mais pourquoi diable? Et dire qu'il y en a qui pensent que le problème principal de Suunto, c'est le marketing

Cloclo : dans ton titre tu peux rajouter du calcul de la distance et DU D+ : en effet j'ai systématiquement des différences de D+ entre la montre et Rubitrack avec toujours - sur l'Ambit que sur Rubitrack.
Même si j'ai bien compris que les différences de distances étaient liées à la "trace de l'ivrogne" : l'ivrogne prend pas 100 m de D + en 2xEHPE ?!?

Ola, j'ai jamais dit que l'algo 2*EHPE s'applique au calcul de D+. Et je viens juste de vérifier, il n'y a pas de filtre d'algo sur l'altitude. Mais le calcul du D+, je botte en touche, Flo2Cannes fait ça mille fois mieux que moi, t'as qu'à lui demander

J'ai jeté un coup d'oeil vite fait sur le gaz, ouch, malgré une distance entre fix (1pt/min) supérieure en moyenne de 66 m (4 km/h), l'Ambit décide encore d'ignorer un paquet de points GPS pour le calcul de la distance.

Illustration en images (trace filtrée, et originale):

Capture d’écran 2012-07-29 à 22.14.40.png (241.75 Kio) Consulté 2065 fois

Capture d’écran 2012-07-29 à 22.14.23.png (255.66 Kio) Consulté 2065 fois

Même la trace originale qui donne 22.78 km dans ST coupe déjà pas mal de lacets.
La trace filtrée, qui donne 19.38 km sur la montre et 19.32 dans ST, coupe encore plus.

C'est bien ce que je me disais : y a un loup

En regardant de plus près la trace de Guenael en mode 1pt/min, je m'aperçoit qu'il y a plein de points où l'EHPE atteint 40-50m, et que l'algo 2*EHPE est toujours utilisé dans ce mode. La raison pourquoi il y a plus de valeurs élevées d'EHPE en moyenne qu'en mode 1pt/s s'explique par le fait que, pour économiser la batterie, l'Ambit désactive le GPS entre deux fix, ce qui fait qu'en le redémarrant avant la minute où il faut faire le fix, l'erreur GPS est encore élevée.

Je suggère fortement à Suunto s'il nous lit (on peut toujours rêver) de passe son algo à 1*EHPE au lieu de 2*EHPE. Je n'ai pas le temps, ni l'envie de le prouver, mais je pense que ça pourrait résoudre à la fois le problème des distances trop courtes en mode 1pt/s, et surtout 1pt/min. Et ça, ça ne doit pas prendre plus qu'entre 1s et 1mn pour adapter le firmware en conséquence.

Je suggère fortement à Suunto s'il nous lit (on peut toujours rêver) de passe son algo à 1*EHPE au lieu de 2*EHPE. Je n'ai pas le temps, ni l'envie de le prouver, mais je pense que ça pourrait résoudre à la fois le problème des distances trop courtes en mode 1pt/s, et surtout 1pt/min.

Il semble que or_watching arrive à des conclusions quasi similaires sur le forum Watchuseek:
http://forums.watchuseek.com/f233/about ... 824-2.html

Sur un test statique, la meilleure régression semble être 2*SQRT(EHPE). Faut voir ce que ça donne en test réel, mais ça, on va laisser les ingénieurs Suunto départager 1*EHPE et 2*SQRT(EHPE). Il est quasi clair que l'un ou l'autre donnera des distances calculées par l'Ambit plus proche de la réalité que l'agressif 2*EHPE. Sans oublier de rajouter la correction de pente pour les fadas de pentes à plus de 20%

ah ah ah ah

"Je suggère fortement à Suunto s'il nous lit (on peut toujours rêver) de passe son algo à 1*EHPE au lieu de 2*EHPE"

Moi ça fait longtemps que je le suggère aussi !!!

Sur ma demande, or_watching sur Watchuseek a essayé différents algorithmes de calcul de distance pour la trace de Paulotrail dans les Bauges:
http://forums.watchuseek.com/f233/about ... ost5302776

Comme c'est difficile de connaitre la longueur exacte de cette trace, difficile de conclure, mais 1*EHPE ou 2*SQRT(EHPE) me semblent un meilleur choix que 2*EHPE. Mais j'admets que c'est un peu subjectif, il faudrait conduire une telle comparaison d'algo sur un grand nombre de traces en terrain couvert et de distance connue pour vraiment départager. Donc on n'est pas encore rendu pour présenter un dossier complètement argumenté envers Suunto pour une demande de changement d'algo de calcul de distance.

Sur ma demande, or_watching sur Watchuseek a essayé différents algorithmes de calcul de distance pour la trace de Paulotrail dans les Bauges:
http://forums.watchuseek.com/f233/about ... ost5302776

Comme c'est difficile de connaitre la longueur exacte de cette trace, difficile de conclure, mais 1*EHPE ou 2*SQRT(EHPE) me semblent un meilleur choix que 2*EHPE. Mais j'admets que c'est un peu subjectif, il faudrait conduire une telle comparaison d'algo sur un grand nombre de traces en terrain couvert et de distance connue pour vraiment départager. Donc on n'est pas encore rendu pour présenter un dossier complètement argumenté envers Suunto pour une demande de changement d'algo de calcul de distance.

Un autre élément de réflexion à verser à ce dossier :

Quand j'ai discuté sur le forum de SportTracks avec l'auteur de ce logiciel, il y a plusieurs semaines de ça, de différences de calcul de distance globale, en lui montrant l'exemple d'une trace de l'Ambit, il m'avait fait le retour suivant : 1) la trace elle-même était de bonne qualité 2) s'il y avait un point toutes les 5 secondes plutôt qu'un point toutes les secondes, ce serait probablement mieux pour le calcul de distance.

Du coup, le filtrage qu'il préconisait était on ne peut plus simple : point de calcul élaboré basé sur une indication d'erreur, on prend en compte un point toutes les cinq secondes, et basta. Ce serait rustique, mais si ça se trouve ce serait pas mal aussi (?).

Du coup, le filtrage qu'il préconisait était on ne peut plus simple : point de calcul élaboré basé sur une indication d'erreur, on prend en compte un point toutes les cinq secondes, et basta. Ce serait rustique, mais si ça se trouve ce serait pas mal aussi (?).

Ca, je l'avais implémenté dans une des versions de ton script, mais jusqu'ici, je ne me suis pas lancé encore dans une comparaison d'algos. J'ai demandé à or_watching de me fournir sa version modifiée avec filtre 1*EHPE, 2*SQRT(EHPE), moyenne glissante. Dans ce cas, je pourrai ajouter un épisode:
7/Comparaison de différents algos de calcul de distance.
Si or_watching ne daigne pas me le filer, va falloir que je me coltine la reproprammation moi-même, moyennement motivé

"Du coup, le filtrage qu'il préconisait était on ne peut plus simple : point de calcul élaboré basé sur une indication d'erreur, on prend en compte un point toutes les cinq secondes, et basta. Ce serait rustique, mais si ça se trouve ce serait pas mal aussi (?)."

N'est-il pas prévu dans une prochaine maj du software de l'Ambit d'avoir le choix de la fréquence des points entre 1s et 60s ?!?

Je pense que oui donc à partir de cette maj avec un peu de "chance" en mode 1pt/5s le calcul Ambit devrait être plus correct...

"Du coup, le filtrage qu'il préconisait était on ne peut plus simple : point de calcul élaboré basé sur une indication d'erreur, on prend en compte un point toutes les cinq secondes, et basta. Ce serait rustique, mais si ça se trouve ce serait pas mal aussi (?)."

N'est-il pas prévu dans une prochaine maj du software de l'Ambit d'avoir le choix de la fréquence des points entre 1s et 60s ?!?

Je pense que oui donc à partir de cette maj avec un peu de "chance" en mode 1pt/5s le calcul Ambit devrait être plus correct...

Oui, je crois que c'est prévu et que ça ne pourrait pas faire de mal.

En fait, je me demande si l'enregistrement à la seconde ne fait pas plus de mal que de bien : cela donne une trace plus bruitée qu'autre chose ("la démarche d'ivrogne" mentionnée dans un post de cloclo), cela impacte l'autonomie, la place mémoire, etc. Pour de la marche ou de la course à pied, typée trail à tout le moins (peut-être pas pour des gaillards qui filent à 18 km/h sur route), un échantillonage toutes les 5 secondes serait probablement un bien meilleur compromis à tout point de vue.

En fait, je me demande si l'enregistrement à la seconde ne fait pas plus de mal que de bien : cela donne une trace plus bruitée qu'autre chose ("la démarche d'ivrogne" mentionnée dans un post de cloclo), cela impacte l'autonomie, la place mémoire, etc. Pour de la marche ou de la course à pied, typée trail à tout le moins (peut-être pas pour des gaillards qui filent à 18 km/h sur route), un échantillonage toutes les 5 secondes serait probablement un bien meilleur compromis à tout point de vue.

T'af dak avec toi Sauf pour l'autonomie, passer d'un enregistrement de 1s à 5s ne change rien, car il faut laisser le GPS en route dans ce cas de toute façon, car l'éteindre sur 4s, et le rallumer, bonjour la précision dans ce cas.

En fait, je me demande si l'enregistrement à la seconde ne fait pas plus de mal que de bien : cela donne une trace plus bruitée qu'autre chose ("la démarche d'ivrogne" mentionnée dans un post de cloclo), cela impacte l'autonomie, la place mémoire, etc. Pour de la marche ou de la course à pied, typée trail à tout le moins (peut-être pas pour des gaillards qui filent à 18 km/h sur route), un échantillonage toutes les 5 secondes serait probablement un bien meilleur compromis à tout point de vue.

T'af dak avec toi Sauf pour l'autonomie, passer d'un enregistrement de 1s à 5s ne change rien, car il faut laisser le GPS en route dans ce cas de toute façon, car l'éteindre sur 4s, et le rallumer, bonjour la précision dans ce cas.

Ok, je retire l'autonomie de la liste des avantages d'un mode 5s

En tout cas, si Suunto propose l'échantillonage à 5s dans une prochaine mise à jour, ce serait important que dans ce mode là ils désactivent le filtrage mis en place actuellement, ou qu'ils en trouvent un mieux fichu. En laissant le filtrage actuel en place par dessus un mode 5s, nous pourrions finir avec une distance globale encore plus sous-estimée que celle produite par le mode 1 s actuel, quand un mode 5s non filtré pourrait être très bien, lui.

Dans la même logique, en mode 60s, il faudrait couper le filtrage actuel également. Dans ce mode-là, on est assez "filtré" comme ça, ça suffit

Dans la même logique, en mode 60s, il faudrait couper le filtrage actuel également. Dans ce mode-là, on est assez "filtré" comme ça, ça suffit

Ca, pour sur, je ne comprends pas la logique de l'équipe ingénierie de Suunto
Pour le mode 5s non filtré, faudrait vraiment se coltiner l'étude comparative dont j'ai parlé pour voir ce qui est mieux.

Bonjour Cloclo,
Je me suis permis d'envoyer au support de Suunto le lien de Kikourou pour leur montrer le problème de la distance, et j'ai fait un copié collé de leur réponse, car il y a vraiment un problème de distance.
Sportivement.

Nous vous remercions d'avoir contacté Suunto Service Clients.

Suunto vous remercie pour l'analyse des données parfaitement exécutée. Nos experts étudient la question. Nos experts de l'équipe de développement du logiciel Ambit seraient intéressés si vous pouvez nous envoyer vos logs xml, les identifiant sur votre site Internet (viewtopic.php?f=22&t=25539% 3E % 20 & t = 25539) sont cga2 01/07 et Romain33. Justement donner un reply a cet email et attachiez les logs afin de pouvoir les identifier plus rapidement.

Bonjour Cloclo,
Je me suis permis d'envoyer au support de Suunto le lien de Kikourou pour leur montrer le problème de la distance, et j'ai fait un copié collé de leur réponse, car il y a vraiment un problème de distance.
Sportivement.

Nous vous remercions d'avoir contacté Suunto Service Clients.

Suunto vous remercie pour l'analyse des données parfaitement exécutée. Nos experts étudient la question. Nos experts de l'équipe de développement du logiciel Ambit seraient intéressés si vous pouvez nous envoyer vos logs xml, les identifiant sur votre site Internet (viewtopic.php?f=22&t=25539% 3E % 20 & t = 25539) sont cga2 01/07 et Romain33. Justement donner un reply a cet email et attachiez les logs afin de pouvoir les identifier plus rapidement.

Salut Anji,

De ce que je comprends de leur réponse, seules les 2 traces pathologiques de "cga2 01/07" et "Romain33 relief" semblent les intéresser. Je ne suis pas convaincu qu'ils pensent que leur algo 2*EHPE soit un poil trop agressif. D'ailleurs, or_watching m'a envoyé des scripts VBS avec lesquels je pourrai essayer d'autres algos, mais je n'ai plus vraiment envie, je suis en vacances du coté du GRP, et ça fait un bien fou de courir dans les sentes pyrénéennes au lieu de se prendre le chou pour une montre que je n'ai même pas

Allez cloclo, il faut continuer à peaufiner le truc stp car avec la prochaine mise à jour et la possibilité de personnaliser le truc : on serait peut être capable de créer un calcul de distance personnalisé ..