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 !

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 😅

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.

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.

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. PXL_20230524_150604849~2.mp4 SGCAM_20230524_151021410~2.mp4

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.

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 😄).

Edit 07/01/2024 (actualisation des infos) : Le site de WheelDash est enfin en ligne ! Il est disponible à l'adresse suivante : https://blkfribourg.github.io/ -------------------------- Bon je fais un édit du premier message pour permettre une meilleure lecture de l'info suivante : Comme je suis arrivé à une version que j'utilise maintenant à chaque trajet et pour attirer potentiellement d'autres dev sur le sujet grâce à une visibilité accrue (pas sûr que ça fonctionne😁), j'ai décidé de rendre disponible l'appli sur le store Garmin. Pour rappel cette app est une app standalone et non un compagnon pour wheelLog ou EUC World, elle ne nécessite donc ni l'un ni l'autre. Elle est donc complètement indépendante (même exclusive, au moins dans le cas que j'ai pu observer : il n'est pas possible d'appareiller ma Tesla avec ma montre et mon téléphone en même temps) et profite de l'environnement Garmin pour l'enregistrement des sorties (avec tracé) et le stockage des données remontées par la roue (c'est donc intégralement gratuit et stocké chez Garmin). A ce jour deux types d'applications WheelDash : une app à proprement parler (avec un peu plus de fonctionnalités) et un datafield à coupler à une "activité Garmin" (plus limité mais compatible avec la navigation Garmin, donc idéal pour les long rides vers l'inconnu ). Le tracé et les données associés à chaque sortie sont ainsi disponibles sur l'appli ou le portail Garmin Connect. Il est également possible de gérer directement les paramètres de la roue sur la montre (mode des pédales, LED, Lumières, etc...) et de définir des alarmes (vibration ou audio) de vitesse, PWM et température contrôleur. Si vous disposez d'une montre qui peut générer des alertes sonores il est également possible d'avoir les alarmes audio via un casque/écouteur/intercom bluetooth connecté à la montre. L'application est dispo ici : https://apps.garmin.com/fr-FR/apps/0f55f691-d9a2-4d9a-aec1-cc728798c86b Marques de roues actuellement supportées : - Gotway/Begode/Extreme Bull firmware custom ou non - Leaperkim - Kingsong - Inmotion (uniquement à partir de la V11, à cause d'un problème de compatiblité Garmin/Inmotion, fonctionnel mais en cours de développement) - Tout ce qui tourne avec un VESC, firmware 6.02 uniquement (fonctionnel mais en cours de développement) Montres actuellement supportées : - Toutes les montres qui supportent le protocole BLE (Bluetooth Low Energy). Si WheelDash n'apparait pas dans Garmin Connect IQ ou que vous avez un message comme quoi l'adresse est indisponible c'est que votre montre n'est pas supportée, si elle est bien compatible avec le BLE envoyez moi un MP. Données de la roue enregistrées lors d'un ride : - Speed - PWM (calculé ou hardware selon modèle de roue) - Voltage - Current - Motor Power - Motherboard temperature - Et tout un tas d'autres info dérivée de ces valeurs ou non 😛 Quelques images : WheelDash (app): WheelDash: datafield (Compatible navigation native Garmin): Données enregistrées sur Garmin Connect: Message original : 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 ?

Perso j'ai mis une alerte à 80% pwm sur wheelLog, ça klaxonne joyeusement dans les enceintes de ma Tesla et même avec un casque de moto j'arrive à l'entendre 90% du temps. Je prévois de rajouter une alerte par vibration sur ma montre (parceque mon téléphone, entre les fois où je le sens pas et où il vibre pour autre chose...) dès que je dépasse les 80% pwm comme ça aucune chance de pêcher par excès de confiance 😁 (à moins que Seba ne me prenne de vitesse si il implémente cette fonctionnalité et sort une app garmin pour euc world, mais pour l'heure je préfère wheelLog).

Désolé je n'avais pas vu ce message et je pensais que tu t'adressais à InMoWh75 précédemment. Je ne roule pas en T3, j'ai une V2 qui n'a jamais dépassé les 46° (pendant des tests d'accélérations/freinages, mais je ne l'ai pas depuis très longtemps, je n'ai pas encore roulé pendant la période estivale). Il me semble que les ventilos se mettent en marche vers 40°. En conditions de conduite "normale" je ne dépasse pas 42°C. Mais je doute que ça soit transposable à une T3 car le moteur et la carte mère ne sont pas les mêmes...

Merci pour ce retour ! Pour l'histoire du bruit de sifflement il n'y avait pas une histoire d'update du firmware qui réglait le problème (ou alors c'était encore pire avec les premières versions du firmware) ?

Oui j'en suis ravi, tellement que je fais des sorties juste pour le plaisir de rouler et de perfectionner ma maîtrise de la roue 😁. Je ne pourrais que difficilement m'en passer maintenant 😂.

Ça m'a intrigué je suis parti retourner l'internet😅. J'ai vu des exn comme ça aussi, certaines avait des écrans rouge, d'autres des écrans vert et rouge .

Ahah, j'avoue que depuis que les premières frayeurs des wobbles sont passées, j'ai tendance à rouler de façon plutôt sportive 😁 !

Appartement il existe un display rouge, (en tout cas le visuel le laisse penser) : https://revrides.com/products/begode-lcd-version-1. Après reste à savoir si c'est voulu ou si c'est une erreur dans un batch de production 🫠

@ValpanJe suis curieux d'avoir ton ressenti sur les differences entre la V2 et la T3, notamment au niveau du couple ! D'après les chiffres présentés par WW (cf https://m.youtube.com/watch?v=XsXG8OY_n5g&t=294), la T3 arrache bien plus le bitume, mais ces chiffres pour la V2 me laissent un peu dubitatif... J'ai relativement peu d'expérience et malgré cela j'arrive à faire des 0-40 en 5 secondes (soit la même chose que Adam) sans avoir l'impression de réaliser le test d'accélération parfait.

Ok, alors dans le cas de Begode la valeur de voltage maximale que la roue retourne est toujours relative à une batterie en 67.2V. Ne me demande pas pourquoi c'est comme ça chez Begode, en fonction de la roue utilisée les applis appliquent un facteur de 1, 1.25, 1.5 ou 2 pour corriger et afficher une valeur correcte. En fonction de la méthode de calcul de pourcentage choisi wheellog applique les aglo suivant : if (useBetterPercents) { if (voltage > 6680) { battery = 100; } else if (voltage > 5440) { battery = (voltage - 5380) / 13; } else if (voltage > 5290) { battery = (int) Math.round((voltage - 5290) / 32.5); } else { battery = 0; } } else { if (voltage <= 5290) { battery = 0; } else if (voltage >= 6580) { battery = 100; } else { battery = (voltage - 5290) / 13; } } Voilà ce que ça donne d'un point de vue visuel, la version "améliorée" est un peu plus pessimiste mais est probablement plus juste dans la mesure ou le 100% de batterie correspond à un voltage > 66.8V contre 65.80V. Dans tous les cas on est tributaire de la fiabilité des valeurs de tensions retournées par la roue.

Le pourcentage est calculé par rapport au voltage remonté par la roue vs le voltage théorique à une charge de 100%. Si ça t'intéresse je peux te donner les méthodes de calculs de wheelLog (sachant qu'il y a un mode de calcul "fabricant" et un "amélioré")

Si j'en crois le code source (tronqué ci dessous) c'est par rapport à la distance totale parcourue sur la sortie en cours au moment où tu regarde : double distance = getDistanceFromStart(); if (distance != 0) { return getAverageBatteryConsumption() * 1000 / distance; Sachant que getAverageBatteryConsumption() retourne la différence entre le % de batterie au départ et le % de batterie actuel.

J'irais pas te dire que tu racontes n'importe quoi 🤪, mais clairement ton dernier paragraphe résume tout a fait la problématique : tu veux comparer des machines qui sont différentes et les variables sont trop nombreuses. C'est justement là où je trouve que wheellog voit juste dans son calcul de consommation d'énergie : c'est un pourcentage de batterie consommé/km, tu sais donc combien tu crame (de façon relative par rapport à la capacité de ta batterie) par km, point ! Je serais tenté de faire une extrapolation par rapport aux caractéristiques de la batterie, mais c'est peut être complétement faux également : si sur 1 km on consomme 10% d'une batterie spécifiée à 850Wh on est à 85Wh/km ? 🤔

Tu peux aller voir du côté de chicway, généralement les prix sont intéressants. Le seul conseil que je peux te donner c'est d'acheter en boutique en France si tu veux limiter au maximum la prise de risque. Après ça ne va pas forcément de paire avec un SAV sans faille, c'est très boutique dépendant.

Tout ce que je peux te dire c'est que pour wheelLog, en ce qui concerne begode, la valeur absolue de la "phase current" est utilisé comme mesure de courant. L'absence de valeurs négatives est donc logique dans ce cas, mais je ne sais pas si des valeurs négatives sont bien produites en cas de freinage. Malheureusement impossible de savoir comment Seba a calculé la consommation comme les sources sont non consultables depuis 4 ans... Pour kingsong à cette époque il calculait des Wh sur un delta t donné (en multipliant le courant et le voltage remontés, j'imagine que le delta t était relatif à la fréquence de remontée des infos par la roue) pour avoir une estimation des Wh consommés ou rechargés. Si il n'a pas changé de méthode j'imagine qu'il divisive simplement les wh consommés - rechargés par la distance parcourue. Edit : bah non en fait, formule maison pour les begode ! Un peu de lecture ici : https://euc.world/blog/battery-current-vs-motor-phase-current/

Personnellement je n'ai jamais vu dans mes logs de tesla v2 de puissance négative. J'imagine que ça dépends des marques, @InMoWh75 tu as pu tester avec ta T3 ? Pour en revenir à la conso d'énergie, effectivement pas de wh/km, c'est techniquement facilement implémentable sachant que les anciennes sources d'euc world sont encore dispo sur github mais il faut mettre les mains dedans, idem pour la partie synthèse vocale de messages. Je m'y collerais bien mais je n'ai pas suffisement de temps à y consacrer actuellement, et la version actuelle de wheellog me convient pour ce que j'en fais (je ne roule qu'en surveillant le % PWM sur la montre, j'ai souvent peur de rater les bips en zone bruyante ou lorsqu'il y a un peu de vent).

@koto Ravi que mon message ait réveillé ta curiosité, j'espère qu'il en sera de même pour d'autres 😁. @Ryushinkei Je te rejoins, j'aime particulièrement wheellog, je le trouve plus épuré et plus agréable à l'usage que son fork bien connu !

Je me sens obligé de déterrer ce fil pour rappeler qu'il n'y a pas que darkness bot et euc world dans la vie 😁. Wheel log est toujours mis à jour et a le mérite de proposer les fonctionnalités indispensables (à mon sens) et d'être open source. C'est à ma connaissance la seule solution sur Android à actuellement proposer une app companion garmin et ça c'est vraiment cool !