Décalage horaire Suunto Ambit et Skitour

sagamartha a dit :Pïerre* a dit :Movescount, on ne peut pas décharger la montre directement

Dès que tu branches l'ambit à ton PC, les moves sont déchargés via moveslink directement dans le dossier ci-dessous sans même avoir besoin de connexion internet et donc avant même d'être transférés sur movescount:
Users ton_nom_utilisateur AppData Roaming Suunto Moveslink2

Les fichiers sont au format sml que tu peux ouvrir directement avec le bloc-note. L'heure de début du move apparaît en 2ème ligne.
Comme ces fichiers ne sont pas modifiés par movescount, en comparant les heures du fichiers sml et du gpx issu de movescount, tu pourras voir si l'erreur a lieu dès l'enregistrement ou uniquement après traitement par movescount.

Sais-tu où je peux trouver ce dossier sur mac ?

@sagamartha: intéressant je ne savais pas que les fichiers intermédiaires étaient stockés là-bas.

Alors très étonnant, dans le fichier SML, dans l'en-tête est stockée l'heure locale correcte (11:34 dans mon test) et ensuite les échantillons sont stockés en heure GMT correcte (10:34Z). C'est donc Movescount qui applique une modification au fichier de la montre pour sortir un GPX erroné.

Je vais quand même transmettre ça au support SUUNTO, parce que c'est quand même un bug manifeste de leur coté.

alexlio a dit :
Sais-tu où je peux trouver ce dossier sur mac ?

Je n'y connais rien au mac mais après recherche sur le net, le dossier d'installation de moveslink est celui-ci:

OSX : /Users/VOTRE-ID/Library/Application Support/Suunto

J'imagine que les moves sont déchargés dans ce dossier.

@Pïerre: à tout hasard, as-tu vérifié dans ton profil movescount que le pays était correctement enregistré et que la case "synchroniser la date et l'heure" dans moveslink était bien cochée?

sagamartha a dit :
@Pïerre: à tout hasard, as-tu vérifié dans ton profil movescount que le pays était correctement enregistré et que la case "synchroniser la date et l'heure" dans moveslink était bien cochée?
Oui et en plus je ne pense pas que cela puisse être ça parce que si on voyage le décalage peut ne pas correspondre au pays enregistré.

J'ai soumis le problème au support en leur transmettant les fichiers SML et GPX. Je reviens par ici si j'ai une réponse.

sagamartha a dit :@Pïerre: à tout hasard, as-tu vérifié dans ton profil movescount que le pays était correctement enregistré et que la case "synchroniser la date et l'heure" dans moveslink était bien cochée?

Certainement, sinon toutes ses traces ne seraient pas affichées à l'heure locale dans movescount, et en plus ça n'a (théoriquement) aucun impact pour le fichier GPX exporté, qui est en UTC, donc indépendant de l'heure locale.

Bonjour,

J'ai le même problème depuis le changement d'heure. En comparant les différents fichier gpx, le problème vient de Movescount. Le fichier téléchargé .sml (Merci sagamartha pour l'indication !) sur mon ordinateur est à la bonne heure UTC.

Par contre le fichier exporté directement de Movescount est décalé d'une heure et le même décalage est transféré vers Strava.

Le problème ne vient pas de la montre mais de Movescount qui introduit une erreur qui n'était pas présente au départ !

Pour que ce bug soit modifié, il faut sûrement écrire en nombre au support suunto.

Une solution manuelle est de convertir le .sml (format xml propriétaire suunto) en un gpx standard sans l'envoyer vers movescount. Voici un lien vers un script qui fait ça : h**p://www.bouge-ton-corps.info/2013/05/conversion-de-fichiers-xml-suunto-ambit-vers-le-format-gpx-75/. C'est un script python sur GitHub qui ne semble pas trop actif et chez moi, le script retourne une erreur. Je n'ai pas encore cherché plus loin mais ça donne la possibilité, a priori, de complètement se passer de Movescount (si le site est en rade ou carrément ferme).

Si qq'un veut bien me transmettre un fichier .sml issu de Suunto sur admin@..., je peux rapidement vous proposer un truc.

Jeroen a dit :Si qq'un veut bien me transmettre un fichier .sml issu de Suunto sur admin@..., je peux rapidement vous proposer un truc.

C'est fait.

Pour info comme j'ai une Ambit depuis plusieurs années, ce problème de décalage se corrige la plupart du temps 2-3 mois après le changement d'heure, puis revient au changement d'heure suivant dans l'autre sens. Du gros n'importe quoi 🤢

Ca serait super ! 😄

Je viens d'envoyer un .SML

Merci beaucoup !

Here you are www.skitour.fr/divers/sml2gpx.php

Super !

Avec un premier essai, cela marche très bien ! 😄

Merci beaucoup. 🙂

Sur mac je ne trouve pas le fichier sml dans Application Support, si un utilisateur mac s'y connait...

Dans le dossier application support, il y a un sous dossier Suunto où se trouve le dossier Moveslink avec les fichiers sml (Suunto Markup Language).

Jeroen a dit :Certainement, sinon toutes ses traces ne seraient pas affichées à l'heure locale dans movescount, et en plus ça n'a (théoriquement) aucun impact pour le fichier GPX exporté, qui est en UTC, donc indépendant de l'heure locale.
Pïerre* a dit :Oui et en plus je ne pense pas que cela puisse être ça parce que si on voyage le décalage peut ne pas correspondre au pays enregistré.
C'est pas faux! 😜

Sinon, apparemment, le pb a été réglé pour certains soit par une simple déconnexion/reconnexion sur movescount soit par la désactivation de l'option GPS timekeeping (déjà proposé par Vince88).

h**ps://strava.zendesk.com/entries/52181094-Manual-GPX-import-from-Suunto-displays-incorrect-activity-start-time

h**p://www.kikourou.net/forum/viewtopic.php?f=22&t=32078

sagamartha a dit :Sinon, apparemment, le pb a été réglé pour certains soit par une simple déconnexion/reconnexion

Je viens de tester et c'est apparemment ça la solution du problème. Se déconnecter de Movescount et se reconnecter à chaque changement d'heure. J'étais connecté en permanence, je viens de faire une déconnexion/reconnexion et là les GPX téléchargés sont corrects. Tant qu'on ne s'est pas déconnecté, Movescount ne s'adapte pas à l'heure d'hiver ou d'été.