App EUC - montres Garmin

[Blkfri]

J'ouvre ce sujet pour sonder un peu au sujet de l'intérêt d'une appli pour nos roues qui tournerait sur des montres Garmin. 🤔

Techniquement l'idée est de se passer d'une app tierce sur téléphone et de lire directement les infos des roues par protocole BLE (Bluetooth Low Energy).

J'imagine qu'il est possible de gérer l'enregistrement d'activités en ajoutant les données récoltées via bluetooth pour avoir des données complètes sur les sorties tel que le propose EUC world ou wheelLog, mais dans l'environnement Garmin.

J'interpelle donc les possesseurs de montres Garmin (qui sont peut être peu nombreux ici) : Est-ce que vous y verriez un intérêt ?

[Cobalt]

Les montres Garmin sont assez courantes, de nombreux wheeleurs doivent être équipés, c'est mon cas avec une fenix 6 pro.

Il existe un SDK (Software Development Kit) pour ces montres, il est donc en théorie possible d'ajouter une fonction EUC sur les Garmin à condition d'y consacrer le temps nécessaire au développement.

Pour la petite histoire, j'avais acheté une montre P8 et installé l'application eucWatch d'Enaon https://www.espritroue.fr/topic/16585-euc-watch-hackable, elle fonctionnait plutôt bien avec ma V8. Un jour je suis passé à proximité d'un poteau métallique qui borde une piste cyclable et mon poignet gauche à heurté gentiment le haut du poteau, la montre a explosé lors du contact avec le poteau. La P8 était une montre à 15 € achetée sur AE, je n'aimerais pas renouveler cette expérience avec la fenix !  

Edited May 13 by Cobalt
correction orthographique

[Blkfri]

Il y a 5 heures, Cobalt a dit :

Il existe un SDK (Software Development Kit) pour ces montres, il est donc en théorie possible d'ajouter une fonction EUC sur les Garmin à condition d'y consacrer le temps nécessaire au développement.

Oui j'ai déjà mis les doigts dedans, après pas mal de tâtonnements (je connaissais assez mal le protocole BLE et je découvre le monkey C de Garmin) j'ai fait une version alpha qui permet de récupérer les données de ma tesla v2.

Prochaine étape, gérer les modes de pedales, la calibration, les lumières et les leds via des menus puis interface du même type que le compagnon wheelLog dont j'ai déjà fait un mod perso (PWM sur l'arc du haut de 0 à 100%, deux seuils d'alarmes par vibration à 80% puis à 90% PWM).

Pour le moment je n'ai axé le développement que sur mes propres besoins (begode et Garmin venu), d'où mon "sondage" pour savoir si d'autres sont intéressés de façon à réfléchir à :

- mettre mes sources à disposition et chacun se débrouille.

- essayer de faire un truc pour tous sachant que le contenu des frames est déjà bien documenté (mais sans garantie, notamment car il me semble que Garmin ne lit actuellement que les 20 premiers bytes des frames, ce qui peut être problématique en fonction des marques/modèles. Je trouve le projet intéressant mais j'ai une vie déjà bien remplie 😄).

 

 

Edited May 13 by Blkfri

[Cobalt]

Je vois que tu es bien avancé ! sympa tes premières fenêtres 👍. Je n'ai pas le temps à court terme mais dans quelques mois j'aimerai bien mettre les mains dans le SDK Garmin.

L'intérêt de développer sur la plate forme Garmin est de bénéficier d'une gamme de montres pérenne et évolutive, ce qui n'est pas le cas des montres made in china. 

Je suppose que tu es développeur ou d'une manière plus globale informaticien, combien de temps as tu mis pour te familiariser avec le SDK ?

[Blkfri]

Je ne suis pas développeur mais je programme assez souvent dans différents languages (surtout en R et python, je suis dans la bioinformatique, mais j'ai aussi fait du java et un tout petit peu de C).

Bref je tiens plus du bidouilleur averti que du développeur 😅.

Après la structure d'un projet est monkey C est assez rigide  et entre le forum de dev Garmin et les exemples de codes qu'on peut trouver sur GitHub (entre autre), c'est je trouve assez facile à appréhender. D'autant que lorsque tu crée un nouveau projet avec l'extension monkey C de visual studio code, il te fait toute la structure et le code d'une app minimaliste fonctionnelle.

Tout ça pour dire que j'ai commencé il y a 3 semaines, en modifiant le code du companion wheelLog pour Garmin de ggoraa. 

Par contre le développement sans dongle/carte nrf compatible avec le sdk Garmin (pour la communication bluetooth) est un peu relou, pas moyen de tester sans faire un build et de copier sur la montre.

Edited May 14 by Blkfri

[Blkfri]

Bon. Je considère la version 0.1 comme terminée. J'ai dû composer un peu avec certaines limitations liées à ma Garmin Venu (en ce qui concerne les menus).

L'appli est pleinement fonctionnelle (j'ai encore un crash à identifier qui arrive uniquement au lancement de l'application et assez rarement. Il est lié à un problème dans la connexion bluetooth mais je n'arrive pas à identifier le soucis). Prochaine étape du développement : gérer l'enregistrement d'un parcours. Il manque aussi la gestion de profils bluetooth, actuellement l'appli saute sur la première Begode non appareillée. J'imagine que ça peut être problématique lors d'une sortie groupée, en tout cas ça demandera un minimum d'organisation dans l'état actuel 😂.

Je suis assez content de m'être plongé là dedans car j'ai appris pleins de choses plus ou moins intéressantes, notamment que tous les paramètres de la roue qu'on peut modifier ne retournent pas tous un statut via les frame de données principales. Exemple dans mon cas : sur une Begode Tesla v2 (avec une carte mère verte, détail qui aura son importance plus bas), le statut de l'éclairage frontal, de l'angle de cutoff et du volume des bips ne sont pas communiqués via Bluetooth (les applis telles que wheelLog ou EUCworld stockent les réglages sur le téléphone). Ce n'est pas dramatique mais j'ai cherché un moment 😅. 

Tiens tant qu'on y est voilà autre chose : j'ai une tendance naturelle à aimer avoir le maximum de contrôle sur mes appareils ou véhicules quitte à flirter avec les limites du système, donc rouler "au PWM" sans tilt back c'était pour moi une évidence. J'avais lu que les begode communiquaient la vraie valeur de PWM (où en tout cas que cette valeur était remontée par le contrôleur). Et bien c'est vrai mais ce n'est pas aussi simple, j'avais juste lu trop vite. Si la valeur de PWM est bien communiqué, elle l'est sur une frame etendue non accessible lorsque l'on lit les frames principales, et à une fréquence moindre (toutes les 625ms) que ces dernières (sur lesquelles transitent les infos classiques telles que la vitesse, la distance, le voltage, etc...). Bref le PWM normalement affiché par wheelLog ou EUCworld est en fait un PWM calculé et non la "vraie valeur". Je dis normalement puisque grâce à l'arrivée des firmware customs (grâce à Freestyler) pour Begode il est possible d'envoyer la vraie valeur sur les frames principales et donc de l'exploiter.

Tout ça pour dire que j'ai repris la formule de wheelLog pour le calcul du PWM sur mon appli Garmin, j'affinerai l'équation si besoin en faisant des mesures avec euc dashboard qui lit les données de la frame étendue (pas de possibilité de custom firmware dans mon cas, la carte mère de ma Tesla est une version "verte").

Je joins deux vidéos de fonctionnement au passage !

deux edits "audio" de la première video 🤪:

- quand je penche la roue sur le côté et non en arrière.

- pour autoriser ou non le changement et non l'arrêt.

 

   

 

Edited Wednesday at 09:06 PM by Blkfri

[Blkfri]

Bon, pour une fois c'est allé plus vite que prévu, c'est finalement assez simple d'implémenter l'enregistrement des données de la roue d'intégrer tout ça dans une "activité Garmin". Première sortie sur l'établi 😁, pas de tracé car pas de réception GPS dans le garage mais ça permet de vérifier que le reste fonctionne correctement. Il y a deux mesures de vitesse, celle prise par la roue et celle prise par le GPS (d'où l'allure moyenne à 0km/h).

Tests grandeurs nature à suivre, et peut-être ajout de support d'autres marques de roues et modèles de montres si j'ai des beta testeur volontaires !

Je mettrais le code sur Github un peu plus tard, le temps de cleaner un peu le tout et de rendre la capture et l'identification des frames un peu plus propre (actuellement je doute que ma méthode d'identification soit compatible avec des firmware custom). Je ne sais pas encore si je vais la publier sur Connect IQ, il faudrait que je me penche sur le support de nombreuses montres, mais quoi qu'il en soit je mettrais le lien vers le code source ici.

Edited Friday at 08:14 PM by Blkfri

[Cobalt]

Bravo 👍 pour une version 0.1 c'est déjà très avancé ! Je peux tester le fonctionnement avec une Inmotion v8 et une Garmin Fenix 6 pro. Je ne me suis jamais penché sur la structure des données échangées entre une application et la roue, est il facile de trouver la documentation des trames envoyées par chaque modèle de roue ? 

[Blkfri]

Il y a 5 heures, Cobalt a dit :

est il facile de trouver la documentation des trames envoyées par chaque modèle de roue ? 

Sur le GitHub de wheelLog tu as les infos dans le code source (dans un dossier nommé "utils" de mémoire). Pour Begode il y avait une doc du contenu des trames dans le code, pour inmotion il n'y a rien mais le code source permet de savoir comment sont organisés les données.

[deadubed]

Salut.

Je suis justement en train de foutre la zone dans un fork du companion de wheellog histoire de faire un build pour ma ForeRunner 255.

J'ai passé pas mal de temps à réparer des bouts de code et rebuild le gestionnaire de projet kumitateru que ggoraa a construit en rust (tuez-moi) pour faciliter (théoriquement) les builds des app ciq. Pour rien simplifier je bosse sur une archi arm, histoire de rigoler plus fort.

Bref j'ai réussi à faire revivre ce fork (j'ai pondu un beta cracra que je vais bourrer sur ma montre et tester asap) MAIS je trouverais ça cool de mettre le nez dans ton code histoire d'aller plus loin dans le bypass de l'app mobile puisque le point à point est probablement bien plus intéressant que de jouer au Dr Frankenstein. D'autant que j'ai fait ça en mode terminal sans me casser le cul avec VScode ni décortiquer les docs des sdk etc.

 

P.S : J'ai réussi mais j'ai dû fork WheelLog Android pour changer les UUID du companion (en dur dans le code 🫠) vers ma version beta. Donc c'est possible mais franchement chiant pour qui n'est pas ingénieur informaticien.

Edited yesterday at 02:51 PM by deadubed

[Blkfri]

Il y a 4 heures, deadubed a dit :

J'ai réussi mais j'ai dû fork WheelLog Android pour changer les UUID du companion (en dur dans le code 🫠) vers ma version beta. Donc c'est possible mais franchement chiant pour qui n'est pas ingénieur informaticien.

Oui le plus simple c'est de modifier l'id de ta version modifiée du compagnon garmin (en utilisant l'id de la beta ou non en fonction des paramètres de wheel log pour le compagnon dans le fichier manifest). Ça évite de faire deux builds 😅

[Blkfri]

Bon sinon voilà l'adresse du projet sur GitHub : https://github.com/blkfribourg/EUC_GarminApp.

Je viens de le faire un peu à la va vite pour ceux qui veulent y jeter un œil, je documenterais et cleanerais un peu dans un second temps !

[deadubed]

il y a 59 minutes, Blkfri a dit :

Oui le plus simple c'est de modifier l'id de ta version modifiée du compagnon garmin (en utilisant l'id de la beta ou non en fonction des paramètres de wheel log pour le compagnon dans le fichier manifest). Ça évite de faire deux builds 😅

Agreed. J'ai pas eu le choix puisque j'ai pas trouvé de moyen de faire des sideloads en cherchant assez succinctement sur les internets. Je suis donc obligé de pousser ma beta sur ConnectIQ, avec.... un UUID unique x)

J'en déduis que tu arrives à accéder au storage de ta Venu directement ?

Edited yesterday at 06:55 PM by deadubed

[Blkfri]

il y a 55 minutes, deadubed a dit :

J'en déduis que tu arrives à accéder au storage de ta Venu directement ?

Oui, je n'ai pas de mérite je suis sous Windows mais elle apparaît dans l'explorateur dès que je la branche, c'est d'autant plus simple pour debugger sur la montre car l'accès aux log est facile

[deadubed]

il y a 4 minutes, Blkfri a dit :

Oui, je n'ai pas de mérite je suis sous Windows mais elle apparaît dans l'explorateur dès que je la branche, c'est d'autant plus simple pour debugger sur la montre car l'accès aux log est facile

Ah oui j'ai pas pensé à tenter un passage sur windaube

[Blkfri]

Il y a 2 heures, deadubed a dit :

Ah oui j'ai pas pensé à tenter un passage sur windaube

Parfois une souffrance en évite une autre 😜

[deadubed]

Je réfléchis sérieusement à centraliser le retroengineering BLE de WheelLog des différentes roues dans un Monkey Barrel, histoire de faciliter la maintenance et surtout la réutilisation pour d'autres use case. J'ai pas l'impression qu'il y ait de compatibilité avec e.g les libs jar. Ce qui serait vachement mieux puisqu'un jar serait probablement bien plus réutilisable 🤔

 

[Blkfri]

Il y a 1 heure, deadubed a dit :

Je réfléchis sérieusement à centraliser le retroengineering BLE de WheelLog des différentes roues dans un Monkey Barrel, histoire de faciliter la maintenance et surtout la réutilisation pour d'autres use case.

Très bonne idée, pour autant à ma connaissance pas de compatibilité java, il faudra se refrapper le tout en monkey C. Du coup pour les autres use case c'est mort 🙃

[deadubed]

Il y a 1 heure, Blkfri a dit :

Très bonne idée, pour autant à ma connaissance pas de compatibilité java, il faudra se refrapper le tout en monkey C. Du coup pour les autres use case c'est mort 🙃

Ce sera pas pour tout de suite de toute façon, j'aurai plus de temps cet été. Ça fait un moment que j'ai envie de remettre le nez dans des protocoles bas niveau, donc... x)