OnMove200 - laps & cardio support

[dinbo31]

Bonjour Colin,

Tout d'abord, je tiens à te remercier pour ce programme qui m'a permis de récupérer mes traces sur ma montre OnMove200.

La OnMove200 permet de faire des laps manuels, et aussi des fractionnés au temps.
Je ne connaissais pas la programmation en c++, mais j'ai suivi quelques cours de programmation en c il y a une dizaine d'années, je connaissais donc un peu l'architecture de ce type de programme.
En me basant sur le code de la OnMove710, j'ai modifié le code de la OnMove200, et il me génère maintenant les laps quand je lance le programme. Le nouveau code n'est sans doute pas conforme à la norme de ce type de programme, mais je retrouve les bonnes distances et les bons temps (les points ne s'affichent par contre pas au bon endroit sur une carte).
Certains laps s'affichent sans distance, ni vitesse, mais avec le filtre "EmptyLaps" permet de résoudre ce problème.
Je n'ai pas de cardio, donc je n'ai pas pu fixer le cardio dans le programme, mais c'est assez simple à rajouter si l'emplacement des bytes du cardio sont identifés.

J'ai mis deux fichiers omd et omh en pièces jointes pour faire les tests, ainsi que la composition du fichier omd que j'ai trouvé.

Je vais continuer à travailler sur le fichier pour essayer de ficher la vitesse max, ce qui doit être possible par lap, et essayer de faire en sorte que les points de départs et d'arrivées des laps correspondent à la réalité (la distance et le temps collent parfaitement).

Les laps sont identifiés sur le fichier omd par l'affichage de 3 points identiques pour la lap manuel, et par deux points identiques pour le lap du fractionné.

Je te laisse regarder mes modifications et revenir vers moi si nécessaire,

Cordialement,

Thomas

omd.txt
20160831_124700.gpx.txt
20160903_220600.gpx.txt
ACT_0000.OMD.txt
ACT_0000.OMH.txt
ACT_0002.OMD.txt
ACT_0002.OMH.txt

OnMove200.cc.txt

[ColinPitrat]

Super ! Cette contribution m'intéresse.

Si je comprends bien, chaque point contient l'information du temps courant (que je décodais déjà), du temps de début du lap (bytes 32 et 33) et de temps du fin du lap (bytes 52 et 53) c'est ça ?

J'ai l'impression que tu n'es pas parti de la dernière version du code (repository git) car il manque le support du cardio. Ce n'est pas gênant car c'est très localisé. Mais si tu fais la modif en partant du repository git, tu peux ensuite soumettre une pull-request qui me facilite le travail pour l'integration et facilite aussi les commentaires.

Le code me semble bon, et ne casse pas les tests existant (enfin, il y a l'information de lap en plus avec 1 seul lap ce qui est attendu). Il va falloir que j'ajoute un test avec tes fichiers pour tester plusieurs laps. Ou si ça t'intéresse et que tu veux faire une pull-request, tu peux écrire le test toi même en t'inspirant de ce qui est fait dans le sous répertoire test/integrated.

Quelques remarques sur le format:

• le code utilise des espaces pour indenter, pas des tabulations
• à certains endroits, l'indentation n'est pas bonne (contenu d'un for au même niveau que le for) ce qui nuit un peu à la lecture
• les commentaires sont en français alors que tout le reste du projet est en anglais :-)
• il y a quelques retour à la ligne de type DOS/Windows à des endroits

Quelques remarques sur le contenu:

• Il y a un commentaire // déclaration de la variable chunk qui n'est pas très utile, on s'attend à ce que quelqu'un qui lit du code sait ce qu'est une déclaration de variable
• Dans la Recherche du nombre de points, il n'est pas nécessaire de faire chunk = &bytes[i] puisque chunk n'est pas utilisé ensuite. D'autre part, la boucle for revient à faire la division totalPoint = length / 30; (en fait pour être précis c'est l'équivalent de totalPoint = (length + 29)/30-1 mais je ne pense pas que length puisse ne pas être un multiple de 30 ni que le cas totalPoint = -1 soit vraiment voulu.
• Il y a du code dupliqué pour créer le lap selon que c'est le dernier (dernier point atteint) ou un autre (comparaison des temps). Il est possible de l'éviter en faisant if((time == time2) || (time == time3) || (endPoint == totalPoint)). Cette partie pour le coup mériterait un commentaire expliquant à quoi correspondent time2 et time3.
• Il y a encore une duplication de plusieurs ligne dans la partie Recherche de points juste pour différencier la façon de décoder la vitesse. Il suffit de mettre un if autour de la ligne décodant la vitesse (en déclarant la variable avant) pour éviter la répétition. C'est ce que j'ai fait pour le heartrate qui est disponible dans le repo git mais apparemment pas dans la version dont tu es parti.
  • Le test if((numPoints % 3 == 1)||(numPoints == 1)) est redondant (idem pour 2) car 1 % 3 vaut 1 (et 2 % 3 vaut 2).

Encore merci pour cette contribution.

[ColinPitrat]

Il y avait un autre problème dans le test que j'ai oublié de mentionner: l'altitude apparaissait avec la valeur 0. C'est simplement que le FieldUndef correspondant à l'altitude avait été remplacé par 0 dans le new Point. Ou alors c'est peut être lié au fait que la version de départ du code était ancienne.

[ColinPitrat]

Le résultat des tests ne semble pas bon.
Par example, dans 20160831_124700.gpx:

• elapsedTime pour le lap 1 est 2851 secondes (47 minutes) mais le startTime est 2016-08-31T10:47:05.000Z et le starttime du lap 2 est 2016-08-31T11:18:37.000Z, soit 31 minutes
• AverageSpeed est 11.9 pour le lap 1 ce qui semble acceptable mais inf pour le lap 2, 1902 pour le lap3, etc ...
• Les coordonnées des points ne semblent pas bonne non plus, on devrait au moins en avoir un tout à la fin et ils devraient être mieux répartis sur tout le parcours

La distance semble cohérente si les laps ont été réglés pour être pris automatiquement tous les km. Elle vaut en général ~9500.

Serait-il possible d'avoir les fichiers obtenus avec le logiciel 'officiel' pour comparer ?

[microwan]

Bonjour Colin ,

Voici mes fichiers, j'ai le meme souci que dinbo31
La dernière coordonnée se retrouve au pole nord

(cf attachement)

 <trkpt lat="71.502537" lon="0.000588" >

    <time>2016-09-06T10:56:00.000Z</time>
    <extensions>
      <gpxdata:hr>0</gpxdata:hr>
    </extensions>
  </trkpt>

20160906_125600_kalenjireader.gpx.txt
20160906_125600_mygeonaute.gpx.txt

        Cordialement

                     Erwan

PS 👍 bravo pour ton outil ;-)

[microwan]

Bonjour Colin ,

Voici mes fichiers, j'ai le meme souci que dinbo31
encore bravo pour ton outil ;-)
La dernière coordonnée se retrouve au pole nord

(cf attachement)

 <trkpt lat="71.502537" lon="0.000588" >

    <time>2016-09-06T10:56:00.000Z</time>
    <extensions>
      <gpxdata:hr>0</gpxdata:hr>
    </extensions>
  </trkpt>


        Cordialement

                     Erwan

2016-09-07 13:09 GMT+02:00 Colin Pitrat [email protected]:

Hmm, le problème pourrait être lié au fait que le nombre de point est
calculé en divisant par 30 alors que la longueur d'un point est de 20.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#55 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACnXO7FLnrKgNChgWSS5X1oK9Exb-K_Aks5qnptggaJpZM4J2QmW
.

[ColinPitrat]

Le problème du dernier point devrait maintenant être rêglé.