WheelDash - App Garmin

[misc]

Le PWM c’est « Pulse width modulation ». Il ne peut donc aller que de 0 à 100% et représente de combien le contrôleur dose la puissance disponible.

(Ou j’ai pas compris la question?)

Duty cycle serai un synonyme, ou il y a une nuance?

édit: correction 

édit 2: Wikipedia PWM: je ne suis toujours pas au clair sur la nuance mais duty cycle serai peut être en effet plus proche de ce à quoi on réfère.

Modifié le 6 septembre par misc

[C0r3th4n]

Pulse Width Modulation ?

[misc]

8 hours ago, Techos78 said:

Excellente idée de mettre le pwm en exergue sous forme graphique

Tout à fait; d’ailleurs ça m’étonne que le PWM ne soit pas plus présent sur les affichages; c’est pourtant une donnée très importante (plus que l’odomètre , la dureté du mode et la température comme affiche Begode..)

[misc]

8 minutes ago, Corethan said:

Pulse Width Modulation ?

Au temps pour moi 👍🏻

Modifié le 6 septembre par misc

[Techos78]

Il y a 2 heures, Blkfri a dit :

Le PWM pourrait être négatif ? Si oui dans quelles circonstances ? 

Oui, le pwm peut être négatif ! Les constructeurs auto l'ont compris.

Je prends un exemple : ma Dacia Spring. Le pwm est sous forme de marguerite, 8 pétales dont 2 rouges en accélération,

et 3 pétales en décélération (régénération) :

Dans la trame de sortie d'une roue, il est effectivement probable que l'info soit non signée, de 0 à 100%. Il faut donc prendre le signe du courant, qui, sur les roues récentes, est signé.

Quand on parle de pwm, on pense surtout à des bêtes systèmes DC-DC, qui se contentent d'une information linéaire réelle. Mais quand on parle d'une commande de moteur brushless, c'est un système vectoriel qui pilote l'amplitude et la phase, en combinaison imaginaire. C'est même un peu plus compliqué car il faut aussi piloter la vitesse du champ tournant...

Bref, on peut simplifier le raisonnement comme ceci : en accélération le pwm est positif, en décélération il est négatif. Pour WeelDash il suffit de changer la couleur... à mon avis, ce serait pratique et pas uniquement pour les montagnards. Bon, il faut voir si les roues sortent un pourcentage en régénération... ce n'est pas évident...

A titre d'exemple, voilà la façon dont eucwatch présente les accélérations/décélérations, à l'aide d'un bare graph-chenillard (ça commence par une longue descente) :

 

 

Modifié le 6 septembre par Techos78

[Blkfri]

il y a 25 minutes, Techos78 a dit :

Oui, le pwm peut être négatif ! Les constructeurs auto l'ont compris.

Je prends un exemple : ma Dacia Spring. Le pwm est sous forme de marguerite, 8 pétales dont 2 rouges en accélération,

et 3 pétales en décélération (régénération) :

Dans la trame de sortie d'une roue, il est effectivement probable que l'info soit non signée, de 0 à 100%. Il faut donc prendre le signe du courant, qui, sur les roues récentes, est signé.

Quand on parle de pwm, on pense surtout à des bêtes systèmes DC-DC, qui se contentent d'une information linéaire réelle. Mais quand on parle d'une commande de moteur brushless, c'est un système vectoriel qui pilote l'amplitude et la phase, en combinaison imaginaire. C'est même un peu plus compliqué car il faut aussi piloter la vitesse du champ tournant...

Bref, on peut simplifier le raisonnement comme ceci : en accélération le pwm est positif, en décélération il est négatif. Pour WeelDash il suffit de changer la couleur... à mon avis, ce serait pratique et pas uniquement pour les montagnards. Bon, il faut voir si les roues sortent un pourcentage en régénération... ce n'est pas évident...

A titre d'exemple, voilà la façon dont eucwatch présente les accélérations/décélérations, à l'aide d'un bare graph-chenillard (ça commence par une longue descente) :

 

 

Je retire ce que j'ai dis, j'ai eu un doute, du coup j'ai relu mon code et le PWM est bien signé ! Je note donc ta proposition pour représenter un PWM négatif !

[deadubed]

Le 06/09/2024 à 18:48, Blkfri a dit :

Je retire ce que j'ai dis, j'ai eu un doute, du coup j'ai relu mon code et le PWM est bien signé ! Je note donc ta proposition pour représenter un PWM négatif !

Si c'est trop chiant de changer tout le layout (surtout que le background est d'origine wheelog companion si je me souviens bien), tu peux p-ê "juste" passer la couleur de l'arc PWM en vert quand il passe en négatif Je le ferais bien mais je trouve aucune info sur le PWM dans les fichiers de layout

EDIT:(not a critcism) Je viens de comprendre que c'est la notion de vitesse dans le layout qui est utilisé pour le PWM... Je sais que faire des schémas et de la doc c'est chiant, en particulier en open source bénévole. Par contre il sera quasi impossible (sans connaissance préalable en monkey C) pour quiconque de filer un coup de main sur un projet si conséquent sans description d'archi, commentaires, et nommage parfois issus de dette techno de projets forkés.

Tu as fait un boulot monstre pour reprendre l'existant de wheelog et le rendre autonome sur les Garmin. Mais si par exemple tu décidais d'arrêter pour quelque raison que ce soit, les éventuels repreneurs vont devoir faire de l'archéologie pour faire vivre ton bébé. Ce serait dommage, et que de temps perdu pour une idée si pertinente.

Modifié le 11 septembre par deadubed

[Blkfri]

il y a une heure, deadubed a dit :

Si c'est trop chiant de changer tout le layout (surtout que le background est d'origine wheelog companion si je me souviens bien), tu peux p-ê "juste" passer la couleur de l'arc PWM en vert quand il passe en négatif Je le ferais bien mais je trouve aucune info sur le PWM dans les fichiers de layout

EDIT:(not a critcism) Je viens de comprendre que c'est la notion de vitesse dans le layout qui est utilisé pour le PWM... Je sais que faire des schémas et de la doc c'est chiant, en particulier en open source bénévole. Par contre il sera quasi impossible (sans connaissance préalable en monkey C) pour quiconque de filer un coup de main sur un projet si conséquent sans description d'archi, commentaires, et nommage parfois issus de dette techno de projets forkés.

Tu as fait un boulot monstre pour reprendre l'existant de wheelog et le rendre autonome sur les Garmin. Mais si par exemple tu décidais d'arrêter pour quelque raison que ce soit, les éventuels repreneurs vont devoir faire de l'archéologie pour faire vivre ton bébé. Ce serait dommage, et que de temps perdu pour une idée si pertinente.

C'est justement ce que j'ai déjà commencé à faire (pour le PWM), j'ai par contre plusieurs interrogations :

Je ne suis pas certain que l'intégralité des marques retournent un PWM négatif, si ce n'est pas le cas je peux effectivement utiliser le signe du courant comme l'a suggéré @Techos78. Par contre à part d'avoir un indicateur de freinage je n'en vois pas bien l'utilisé pour être tout a fait honnête (je n'ai pas la conviction qu'il puisse être utilisé en tant qu' "indicateur de recharge"). Je n'ai aucune certitude non plus quand au sens du PWM négatif : je vais peut-être dire des énormités, vous m'excuserez ce n'est pas mon domaine 😜 :

En cas de gros freinage, est-ce que le PWM reste informatif ? Car une partie du courant généré part en dissipation thermique et dans les batteries via le BMS. Le BMS ne risque-t-il pas de couper avant un PWM de 100%, idem pour le contrôleur qui peut cramer ou se mettre en protection avant d'atteindre un PWM au max, non ?

Je note l'observation constructive de ton edit, et quand je dis "je note" ça ne veut pas dire que je compte m'assoir dessus 😁. Je vais tacher d'être plus rigoureux, j'ai un petit côté artiste quand je code, je pars un peu en freestyle (je n'ai pas de formation de dev) 😅.

J'en profite pour lancer une bouteille à la mer : j'ai eu 0 retours aux sujet du limiteur de vitesse de la version beta, je ne sais donc pas si mon code déconne et/ou si ça fonctionne pour toutes les marques supportées actuellement pour cette fonctionnalité. Vos retours sont précieux, je n'ai  pas la possibilité d'avoir accès à une roue de chaque marque pour faire du développement 😁

[deadubed]

il y a 29 minutes, Blkfri a dit :

C'est justement ce que j'ai déjà commencé à faire (pour le PWM), j'ai par contre plusieurs interrogations :

Je ne suis pas certain que l'intégralité des marques retournent un PWM négatif, si ce n'est pas le cas je peux effectivement utiliser le signe du courant comme l'a suggéré @Techos78. Par contre à part d'avoir un indicateur de freinage je n'en vois pas bien l'utilisé pour être tout a fait honnête (je n'ai pas la conviction qu'il puisse être utilisé en tant qu' "indicateur de recharge"). Je n'ai aucune certitude non plus quand au sens du PWM négatif : je vais peut-être dire des énormités, vous m'excuserez ce n'est pas mon domaine 😜 :

En cas de gros freinage, est-ce que le PWM reste informatif ? Car une partie du courant généré part en dissipation thermique et dans les batteries via le BMS. Le BMS ne risque-t-il pas de couper avant un PWM de 100%, idem pour le contrôleur qui peut cramer ou se mettre en protection avant d'atteindre un PWM au max, non ?

Je note l'observation constructive de ton edit, et quand je dis "je note" ça ne veut pas dire que je compte m'assoir dessus 😁. Je vais tacher d'être plus rigoureux, j'ai un petit côté artiste quand je code, je pars un peu en freestyle (je n'ai pas de formation de dev) 😅.

J'en profite pour lancer une bouteille à la mer : j'ai eu 0 retours aux sujet du limiteur de vitesse de la version beta, je ne sais donc pas si mon code déconne et/ou si ça fonctionne pour toutes les marques supportées actuellement pour cette fonctionnalité. Vos retours sont précieux, je n'ai  pas la possibilité d'avoir accès à une roue de chaque marque pour faire du développement 😁

Je rejoins ton avis. C'est probablement possible d'implémenter ça, mais il faudrait qu'un sacheur en électro donne la formule exacte à implem basée sur les données brutes dont on dispose à savoir Voltage, Amperage, Vitesse, etc, etc.) L'idée étant de pouvoir implem une fonction de PWM temps réel qui intègre la notion de valeur relative => Standardisation des calculs.

Je me suis pris une motive. J'ai fork le projet, je mets le nez dedans, sérieusement pour cette fois, désolé

[Blkfri]

Il y a 3 heures, deadubed a dit :

L'idée étant de pouvoir implem une fonction de PWM temps réel qui intègre la notion de valeur relative => Standardisation des calculs.

Dans le cas de Begode, qui ne juge toujours pas necessaire de diffuser le PWM sur les trame principales, je calcule le PWM sur la base d'une formule qu'avait défini Freestyler et qui n'est pas trop à la rue (à vérifier sur les modèles récents, je doute que ça reste valable si on utilise le field weakening par exemple). Pour les autres je ne m'embête pas, je prends la valeur reportée par la roue, après est-ce qu'on peut faire mieux avec les valeurs de la roue je n'en suis pas sûr 😅. 

[deadubed]

il y a 48 minutes, Blkfri a dit :

Dans le cas de Begode, qui ne juge toujours pas necessaire de diffuser le PWM sur les trame principales, je calcule le PWM sur la base d'une formule qu'avait défini Freestyler et qui n'est pas trop à la rue (à vérifier sur les modèles récents, je doute que ça reste valable si on utilise le field weakening par exemple). Pour les autres je ne m'embête pas, je prends la valeur reportée par la roue, après est-ce qu'on peut faire mieux avec les valeurs de la roue je n'en suis pas sûr 😅. 

En parlant des trames, ca reste (à mon sens) la partie la plus velue à comprendre. Y a des docs quelque part pour essayer de comprendre comment c'est foutu (exit les docs du protocole de base) ? Parce que les

 enum {
    D_READ,
    D_WRITE,
    C_READ,
    C_WRITER,
    C_WRITENR,
    UPDATE,
  }

Comment dire ... x)

Monkey C souffre d'un gros problème : Le typage strict semble être pas trop au goût du jour, sauf qu'avec le SDK 7.xx c'est la fête aux warning à la compilation parce qu'il est pas content que certains objets soient pas typés

[Blkfri]

Il y a 1 heure, deadubed a dit :

En parlant des trames, ca reste (à mon sens) la partie la plus velue à comprendre. Y a des docs quelque part pour essayer de comprendre comment c'est foutu (exit les docs du protocole de base) ?

Tu veux dire les trames bluetooth en général ou plus spécifiquement les bytes qui composent les trames selon les differents modèles de roue ?

Après j'avoue mon code n'aide pas, c'est du frankencode 😆, j'assemble, j'adapte, je recode mais je pars rarement de rien du tout. Genre ce que tu cite c'est un relicat d'une fonction de gestion de queue bluetooth (parceque Garmin ne le gère pas et si tu envoies 2 requetes bluetooth trop rapidement tu crash ton app). Le gars en question avait fait un système de queue qui gérait aussi bien la lecture que l'ecriture sur les characteristic et les descriptor bluetooth. J'ai gardé le squelette mais on pourrait tout a fait cleaner le code car je n'utilise finalement que C_WRITE_NR (Characteristic Write Without Response) et cet Enum ne sert in fine à rien du tout.  (EDIT: je vais le faire rapidement en fait, ça n'a aucun sens de laisser ça 😁) 

En gros toutes les roues fonctionnent pareil, grossièrement tu as une characteristic qui sert à la lecture et à l'ecriture des données (un peu comme un TX/RX en UART). Pour Inmotion tu as une characteristic pour la lecture de donnée et une pour l'écriture.

La connection type : scan des periphériques -> connection puis activation des notifications sur une characteristic donnée. A partir de là on peut commencer à lire les infos (via la methode onCharacteristicChanged qui est appelée à chaque fois qu'une nouvelle notification est envoyée) qui proviennent de la roue pour Begode et Leaperkim. Pour Kingsong il faut d'abord faire une requete pour obtenir le modèle de roue, ça initie ensuite l'envoie de données en continu sur la characteristic d'interêt. Et pour inmotion, c'est comme pour les VESC (ils ont vraiment le même type de mode de communication c'est troublant) : Il faut envoyer une requete périodique sur la characteristic qui autorise l'écriture pour continuer à recevoir les paquets via la characteristic qui a la notification activée.

Je ne sais pas si ça répond à ta question, ni même au niveau de précision attendu . Je suis un autodidacte, je te recrache ce que j'en ai compris, avec le jargon que je me suis approprié avec probablement quelques libertés 😆 

Modifié le 11 septembre par Blkfri

[deadubed]

Il y a 15 heures, Blkfri a dit :

Tu veux dire les trames bluetooth en général ou plus spécifiquement les bytes qui composent les trames selon les differents modèles de roue ?

Après j'avoue mon code n'aide pas, c'est du frankencode 😆, j'assemble, j'adapte, je recode mais je pars rarement de rien du tout. Genre ce que tu cite c'est un relicat d'une fonction de gestion de queue bluetooth (parceque Garmin ne le gère pas et si tu envoies 2 requetes bluetooth trop rapidement tu crash ton app). Le gars en question avait fait un système de queue qui gérait aussi bien la lecture que l'ecriture sur les characteristic et les descriptor bluetooth. J'ai gardé le squelette mais on pourrait tout a fait cleaner le code car je n'utilise finalement que C_WRITE_NR (Characteristic Write Without Response) et cet Enum ne sert in fine à rien du tout.  (EDIT: je vais le faire rapidement en fait, ça n'a aucun sens de laisser ça 😁) 

En gros toutes les roues fonctionnent pareil, grossièrement tu as une characteristic qui sert à la lecture et à l'ecriture des données (un peu comme un TX/RX en UART). Pour Inmotion tu as une characteristic pour la lecture de donnée et une pour l'écriture.

La connection type : scan des periphériques -> connection puis activation des notifications sur une characteristic donnée. A partir de là on peut commencer à lire les infos (via la methode onCharacteristicChanged qui est appelée à chaque fois qu'une nouvelle notification est envoyée) qui proviennent de la roue pour Begode et Leaperkim. Pour Kingsong il faut d'abord faire une requete pour obtenir le modèle de roue, ça initie ensuite l'envoie de données en continu sur la characteristic d'interêt. Et pour inmotion, c'est comme pour les VESC (ils ont vraiment le même type de mode de communication c'est troublant) : Il faut envoyer une requete périodique sur la characteristic qui autorise l'écriture pour continuer à recevoir les paquets via la characteristic qui a la notification activée.

Je ne sais pas si ça répond à ta question, ni même au niveau de précision attendu . Je suis un autodidacte, je te recrache ce que j'en ai compris, avec le jargon que je me suis approprié avec probablement quelques libertés 😆 

Je veux dire que c'est pas clair haha.

On sent le côté artisanal dans le code, mais c'est pas censé être trop un problème. C'est plus le typage dynamique de Monkey C (entre autres) qui rend la relecture spicy.

Par contre modifie pas forcément trop vite les enums parce qu'en l'etat C_WRITE_NR est mappé à l'entier de valeur 4 (par  défaut pour les enum à valeurs implicites c.f )

En me motivant fort, j'ai bon espoir de pouvoir rendre l'ensemble plus durable niveau technique. Par contre on a pas le cul sorti des ronces.

[Blkfri]

il y a une heure, deadubed a dit :

Par contre modifie pas forcément trop vite les enums parce qu'en l'etat C_WRITE_NR est mappé à l'entier de valeur 4 (par  défaut pour les enum à valeurs implicites c.f )

J'ai beau être un sauvage côté coding skillz, si je dis que ça ne sert à rien c'est que ça ne sert à rien (dans la queue on ne fait que des requestwrite sur des characteristics, pas de read, et rien sur les descriptor. D'ailleurs on pourrait aussi probablement se passer de la queue, j'ai récemment découvert un autre moyen (durant le dev pour la partie support des Engo de chez activelook) pour éviter que les requêtes ne se télescopent )  😜. Il ne suffit pas juste de virer l'enum, il faut évidemment modifier toutes les fonctions et les appels de méthodes qui y font référence.

il y a une heure, deadubed a dit :

En me motivant fort, j'ai bon espoir de pouvoir rendre l'ensemble plus durable niveau technique. Par contre on a pas le cul sorti des ronces.

N'hésite pas à pointer du doigt les trucs douteux ou qui te paraissent tordus et/ou incompréhensible, ça ne peut que servir l'app 😁. Je serais ravi d'avoir un contributeur sur ce projet, donc si je peux te faciliter la tâche en travaillant certains aspects (commentaires, bonnes pratiques, etc... Et n'ai pas peur d'être critique, je ne me vexerai pas 😀) !

[deadubed]

il y a 2 minutes, Blkfri a dit :

J'ai beau être un sauvage côté coding skillz, si je dis que ça ne sert à rien c'est que ça ne sert à rien (dans la queue on ne fait que des requestwrite sur des characteristics, pas de read, et rien sur les descriptor. D'ailleurs on pourrait aussi probablement se passer de la queue, j'ai récemment découvert un autre moyen (durant le dev pour la partie support des Engo de chez activelook) pour éviter que les requêtes ne se télescopent )  😜. Il ne suffit pas juste de virer l'enum, il faut évidemment modifier toutes les fonctions et les appels de méthodes qui y font référence.

Tu me rassures haha.

D'ailleurs, tu debug comment l'app ? j'aimerais bien pouvoir faire du debug bluetooth etc et faut dire que leur simulateur de montre est bien claqué. Si je peux éviter d'acheter du matos...

il y a 2 minutes, Blkfri a dit :

 

N'hésite pas à pointer du doigt les trucs douteux ou qui te paraissent tordus et/ou incompréhensible, ça ne peut que servir l'app 😁. Je serais ravi d'avoir un contributeur sur ce projet, donc si je peux te faciliter la tâche en travaillant certains aspects (commentaires, bonnes pratiques, etc... Et n'ai pas peur d'être critique, je ne me vexerai pas 😀) !

Bah le mieux pour moi c'est ce que j'ai fait. A savoir un fork ou je détricote ce que je peux pour essayer de concevoir de la doc d'archi, et proposer un nouvel agencement du code pour

1. Essayer de mettre de la CI sur github
2. Faire du code cleansing (virer les redondances, améliorer l'interoperabilité, la lisibilité, la maintenabilité)
3.  Proposer une architecture fiable et documentée
4. Intégrer les modifs de ton projet au fur et à mesure
5. Faire une pull request quand on aura une version propre (donc pas demain la veille. Peut-être dans 1 an xD)

[Blkfri]

 

il y a 8 minutes, deadubed a dit :

D'ailleurs, tu debug comment l'app ? j'aimerais bien pouvoir faire du debug bluetooth etc et faut dire que leur simulateur de montre est bien claqué. Si je peux éviter d'acheter du matos...

Avant je faisais des builds que je sideloadais sur ma montre (si tu mets un fichier txt avec le même nom que ton app dans le dossier log tu auras les sorties des print dans le txt, limité à quelques kb de donnés mais ça dépanne). Après j'en ai eu marre et j'ai investi dans un dongle nrf (20€, j'ai ce modèle là : https://www.amazon.fr/gp/product/B07MJ12XLG/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1. Je dirais pas qu'il est formidable mais il fonctionne). Il faut le programmer mais c'est documenté sur le site de Garmin (selon les firmware c'est aussi con que de copier un fichier sur le dongle). Du coup je peux me connecter à mes roues directement via le simulateur (qui reste capricieux). C'est vrai qu'il est parfois un peu chiant mais globalement je trouve qu'il fonctionne à peu près convenablement.

il y a 19 minutes, deadubed a dit :

Tu me rassures haha.

D'ailleurs, tu debug comment l'app ? j'aimerais bien pouvoir faire du debug bluetooth etc et faut dire que leur simulateur de montre est bien claqué. Si je peux éviter d'acheter du matos...

Bah le mieux pour moi c'est ce que j'ai fait. A savoir un fork ou je détricote ce que je peux pour essayer de concevoir de la doc d'archi, et proposer un nouvel agencement du code pour

1. Essayer de mettre de la CI sur github
2. Faire du code cleansing (virer les redondances, améliorer l'interoperabilité, la lisibilité, la maintenabilité)
3.  Proposer une architecture fiable et documentée
4. Intégrer les modifs de ton projet au fur et à mesure
5. Faire une pull request quand on aura une version propre (donc pas demain la veille. Peut-être dans 1 an xD)

Ok je te laisse de dépatouiller alors, mais si tu as des questions ou si tu souhaite que je commente un peu plus n'hésites vraiment pas  

[deadubed]

il y a 14 minutes, Blkfri a dit :

 

Avant je faisais des builds que je sideloadais sur ma montre (si tu mets un fichier txt avec le même nom que ton app dans le dossier log tu auras les sorties des print dans le txt, limité à quelques kb de donnés mais ça dépanne). Après j'en ai eu marre et j'ai investi dans un dongle nrf (20€, j'ai ce modèle là : https://www.amazon.fr/gp/product/B07MJ12XLG/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1. Je dirais pas qu'il est formidable mais il fonctionne). Il faut le programmer mais c'est documenté sur le site de Garmin (selon les firmware c'est aussi con que de copier un fichier sur le dongle). Du coup je peux me connecter à mes roues directement via le simulateur (qui reste capricieux). C'est vrai qu'il est parfois un peu chiant mais globalement je trouve qu'il fonctionne à peu près convenablement.

Ok je te laisse de dépatouiller alors, mais si tu as des questions ou si tu souhaite que je commente un peu plus n'hésites vraiment pas  

Hesite pas à commenter l'utilité globale de chaque fichier (au dela du nom des fichiers, y a surement des choses en plus à dire). Et idéalement ce que chaque classe est censée représenter / permettre.

Ca reste relativement macro mais ca permet d'entrapercevoir l'archi sémantique

[deadubed]

Typical (bad) Software Engineering Problem. ca fait 1h que j'essaie de construire une conf de build monkey C sur linux en essayant de lier tous les chemins du SDK pour que ca tourne. Garmin etant Garmin, a aucun moment ils n'explicitent quelles sont les variables d'environnement qu'ils utilisent pour faire une compile à la main de manière explicite.

En plus ils forcent la gestion du SDK avec leur app en GUI qui est précompilée (uniquement pour x86 bien sûr), ce qui empêche tout téléchargement du sdk en standalone ET des devices data.
Franchement, j'ai rarement bossé avec un environnement de dev aussi merdique

[Blkfri]

il y a 54 minutes, deadubed a dit :

Typical (bad) Software Engineering Problem

C'est la marque de fabrique Garmin, ça te prépare pour la suite 😂.

J'ai suivi bêtement les instructions d'installation et sur une distro Manjaro j'ai pas eu de soucis. Par contre quelques updates plus tard le simulateur a cessé de fonctionner. J'ai fini par lâcher l'affaire et je suis repassé en environnement de dev zindozs (et je te rassure même là c'est merdique, sur mes install light (j'utilise un windows modifié, pratique discutable) je ne par peux accepter l'user agreement, du coup je suis obligé de modifier les fichiers de conf à la main). Bon passé ça, le reste ça va 😁.

[Blab]

Hello les Incroyables ! (surtout le créateur de Wheeldash). 

J'ai sauté la pas cette semaine : achat d'une roue sans savoir en faire, en me disant qu'avec un peu de persévérance je pourrai reléguer mon pass navigo au placard avec joie et rapidement🤞.

Je me présenterai dès que je pourrai (1er post...) pour un peu de contexte mais je suis particulièrement intéressée par ce post car j'ai une Garmin (blingbling peut-être mais c'est surtout ce que j'ai trouvé de mieux pour des prépas marathon) - Epix pro gen 2 42mm (petit poignet).

En termes de roue, j'ai une V8S inmotion, parce qu'apparemment c'était le mieux pour débuter. Et aussi parce que les autres font quasiment mon poids alors bon.

j'ai attentivement lu les 3 premières pages du post, et le site https://blkfribourg.github.io/, évidemment c'est un peu du chinois (comme ma roue je suppose), mais :

1/ si ça fonctionne un jour sur V8S sachez que je serai prête à payer pour ce genre d'app ;

2/ si ça ne fonctionne pas encore mais qu'il faut tester, je suis dispo (mode bidouille niveau 2/10 je pense ; déjà savoir naviguer dans une Garmin requiert un peu de patience). Enfin, dès que je ferai plus de 100m sans tomber évidemment. 

Encore une fois, c'est vraiment un super projet et j'admire ceux qui savent créer/bidouiller/imaginer ces usages et qui en plus les partagent ainsi.

Bon we à tous !

Modifié le 26 octobre par Blab