Blkfri

Tiens bizarre ça, j'ai pourtant d'autres utilisateurs de S22 (surtout sur le datafield mais c'est le même code) qui ne m'ont jamais remonté ce souci.

Ah oui, faut qu'on enquête là dessus aussi ! 😁

C'est un peu HS ici mais globalement les modèlent se segmentent en 3 catégories : Santé / bien être : on retrouve ici principalement les modèles Venu et Vivoactive. Sans rentrer dans les détails ces montres ont généralement de beaux écrans (la gamme venu et la dernière Vivoactive utilisent un écran AMOLED), et des fonctionnalitées sportives plus limités (on reste qd même sur une montre typé sport en terme de fonctionnalités). J'ai toujours une Venu (1ère génération) qui marche parfaitement avec WheelDash. Running/Multisport : c'est la gamme des forerunner, et comme leur nom l'indique c'est orienté course et multisport, pour autant quand on monte en gamme (955 et 965), on se retrouve avec un modèle quasi identique en terme de fonctionnalités aux Fenix/Epix de la gamme outdoor Outdoor : Là on retrouve les montres de la gamme Fenix/Epix/Tactix/Enduro qui sont globalement la même chose : Fenix c'est la version orienté sport avec un écran MIPS (moins flatteur mais meilleur en terme d'autonomie batterie et en lisibilité en plein soleil, à nuancer car les nouveau AMOLED sont plutôt bon maintenant), l'Epix c'est la version en écran AMOLED, la Tactix c'est la finition militaire et l'Enduro c'est une version longue autonomie avec un écran noir et blanc. La dernière Fenix vient bousculer un peu cette organisation parcequ'elle est déclinée en modèle AMOLED et MIPS. Tu as aussi la gamme luxe avec la MARQ reste quelques spécificitées liées à la plongée, au golf et à d'autres sports mais c'est généralement plus ou moins une déclinaison d'un modèle existant. Le point déterminant c'est surtout de savoir si tu as besoin d'avoir des fonctionnalitées de navigation et d'autonomie importante. Si ce n'est pas le cas autant s'orienter sur "l'entrée/milieu de gamme" : dans les anciens modèles tu as la forerunner 255 qui fonctionne bien à ma connaissance (notamment avec la S22 qui pose problème pour d'autres modèles Garmin. @deadubed @Hommedesbois vous confirmez ?), rien à redire non plus sur ma vieille Venu. La venu3 fonctionne bien à priori (un utilisateur a eu des problèmes mais il a échangé sa montre dans le cadre de la garantie et tout fonctionne d'après les dernières info que j'ai eu). Je n'ai pas de recul sur les modèles plus récents, je sais juste que la Fenix 8 a des gros soucis côté bluetooth et que Garmin travaille sur un correctif. Si tu as besoin d'avoir la navigation sur la montre c'est plus compliqué, je pense que les forerunner qui supportent la carto (à l'exception des 955/965 qui sont très proches des Fenix/Epix) devraient être OK mais il faudra confirmer. Pour ma part j'ai une Fenix 7 pro qui fait partie des modèles problématiques en terme de connectivité bluetooth. J'ai dû downgrader mon firmware pour pouvoir continuer à l'utiliser normalement. Il faut un peu ruser pour pouvoir installer des applications sans avoir à mettre le firmware à jour (j'utilise une vieille version de connect IQ). Une autre limitation c'est qu'il n'est pas possible d'installer des applications qui utilisent la dernière version du SDK, donc sur le long terme ce n'est pas viable si on veut installer d'autres applications que la mienne. Bref sur android ça peut se faire, sur un iphone c'est plus problématique (à ma connaissance le downgrade d'appli c'est pas simple). Tu l'auras compris c'est une question complexe, j'avais commencé à faire un tableau de compatibilité wheeldash mais les problèmes bluetooth ont un peu mis la pagaille, il faut que je me remette dessus et que je vois avec les utilisateurs pour clarifier tout ça. En tout cas je privilégierai l'achat dans une enseigne/plateforme connue pour être correcte en terme de retour produits et ne pas hésiter à renvoyer sous les 14j après achat en cas de soucis plutôt que de se retrouver coincé avec une montre qui présente des soucis de connection.

Je te rejoins tout a fait Héhé , honnetement ce sont de bonnes montres, robustes et endurantes, le seul soucis qu'on rencontre en ce moment c'est qu'ils ont flingué leur couche bluetooth et que les modèles les plus récents et/ou haut de gamme ont des problèmes de déconnection ou de lag (je ne doute pas que ça soit résolu prochainement mais ça fait plusieurs mois que ça dure, et à moins de downgrader le firmware il n'y a pas de solution). Donc si tu veux passer le pas n'hésites pas à me demander plus d'infos de façon à ce que je puisse t'aiguiller vers un modèle sans problème de bluetooth.

Disclaimer : J'ai reçu des lunettes Activelook Engo après avoir contacté Microoled pour leur faire part de mon intérêt et leur expliquer en quoi je pensais que ces lunettes pouvaient être utiles aux rideurs que nous sommes. J'ai donc reçu un exemplaire de des Engo 1 (le modèle précédent), ce qui m'a permis d'écrire le code requis pour rendre mon app (WheelDash) avec la technologie ActiveLook et de tester pleinement ces lunettes. J'en profite pour dire que cette review n'est pas commandée, j'expose ici mon avis de façon totalement libre 🙂. Comme je le disais j'ai reçu la première version des lunettes Engo. Les fonctionnalités sont cependant les mêmes que la toute dernière version : les Engo 2. Le dernier modèle se distingue par son look mieux réussi (c'est subjectif mais je pense que tout le monde sera unanime là dessus)😄), des deux tailles disponibles (standard et large) et le port de charge (qui remplace le mini usb des Engo 1, qui il faut l'avouer n'est pas du tout pratique). J'ai donc pu me faire une idée précise de ce que donne l'expérience utilisateur. Description rapide des lunettes : On est sur des lunettes typée sport. La philosophie du produit c'est donc de permettre un usage adapté à des conditions sportives type course ou vélo. Comprendre par là que le cahier des charges est la suivant : c'est léger, résistant à la transpiration , endurant et non distrayant. Ce ne sont pas des lunettes à usage multimédia; ici pas question d'écouter de la musique ou de prendre des photos, ni même de regarder des vidéos, on est encore une fois dans une approche sportive : simple et surtout efficace. De ce fait l'écran traduis cette orientation: on est sur une résolution de 304 x 256 pixels, en 16 niveaux de gris ( donc 16 niveaux d'intensité de couleur monochromatique ). Et c'est bien là que réside la philosophie du produit : l'idée n'est pas de distraire l'attention durant l'affichage de l'information, mais de la rendre accessible à l'oeil sans obstruer pour autant le champs de vision. Les lunettes embarquent également un capteur de luminosité ambiante qui permet d'adapter la luminosité de l'écran en fonction des conditions extérieures. Elles sont également dotées d'un capteur de proximité, qui permet de déclencher des actions lorsque l'on passe la main à devant (typiquement faire défiler les différents modes d'affichage des lunettes). Le bouton capacitif (tactile) , présent au centre des lunettes permet d'allumer et d'éteindre les lunettes (mais il est techniquement possible de l'utiliser pour déclencher des actions, comme pour le capteur de proximité, pour peut que l'application utilisée le supporte). Unboxing : Le déballage dégage une impression de produit qualitatif et bien fini. La boite contient tout ce qu'il faut : un câble permettant la recharge, un étui solide, une housse, une attache et des accessoires permettant le nettoyage (et un tournevis pour la version 1 qui dispose de deux emplacement possibles les branches des lunettes de façon à pouvoir les régler au mieux selon sa morphologie. Ce réglage n'est pas disponible sur la deuxième version, probablement améliorée sur ce point également). Pas besoin de plus à mon sens ! Dès la prise en main j'ai été surpris par la légèreté du produit. les V1 font à peine plus de 40g, ce qui n'est pas bien plus lourd que mes lunettes de sport habituelles (bon certes avec un clip pour corriger ma vue, mais même sans ce clip on a seulement 10g de différence) sachant que les Engo embarquent une batterie et un écran, et que les verres sont bien plus couvrants, c'est plutôt impressionnant. On est, comme la majorité des lunettes sportives sur une base plastique, mais les lunettes sont finies. Il faudra bien évidemment voir dans le temps pour se rendre compte de la solidité du matériel mais pour le moment je n'ai rien à en redire (après trois mois d'utilisations). Applications : Les lunettes fonctionnent avec de nombreuses applications et périphériques (plus d'informations ici : https://fr.engoeyewear.com/produits/engo-2). Parmi ces applications, on retrouve le compagnon Activelook (l'application officielle de la marque) qui permet d'effectuer l'intégralité des réglages des lunettes ainsi que les mises à jour du firmware. Dès le démarrage de celle-ci il est proposé un tutorial pour régler ces lunettes. J'en parle ici car le réglage des lunettes est clairement un truc où il faut passer du temps. C'est vraiment critique pour être en mesure de tirer pleinement parti des lunettes (de mauvais réglages peuvent être responsable d'une image un peu floue ou d'un mauvais positionnement de l'écran rendant la lecture des informations difficile voir impossible). Je fais une petite parenthèse pour parler très brièvement d'un point de vue développeur : l'API (dont la doc est dispo sur github) est vraiment bien fichue, et étant développeur sur les périphériques Garmin à mes heures perdues, je peux vous dire que ça change tout ! On sent qu'un vrai effort a été fait pour ouvrir le périphérique à un maximum d'usages à travers le développement, et c'est un effort qui mérite d'être noté et dont on aimerait voir d'autres s'inspirer. Il faut bien évidement intégrer le fait qu'il existe des limitations techniques mais en tant que développeur on est absolument libre pour dessiner son interface et pour peut qu'on définisse ses propres configurations on peut faire à peu près ce qu'on veut. En conclusion côté développement, une grande liberté + un bonne documentation, c'est clairement un combo gagnant. A l'usage ça donne quoi ? Bonne nouvelle pour ceux d'entre nous qui roulent full-gear pour le moindre trajet (c'est mon cas) elles passent facilement dans un casque intégral de moto (pour rappel je n'ai testé que les Engo 1, les Engo 2 existent en deux tailles : standard et large. Les Engo 1 se placent juste entre les deux en terme de gabarit). Je pense que même la version large des Engo2 passe dans un casque de moto, mais cette version a peut être moins de sens dans ce cas précis car la protection au vent est déjà assurée par la visière une bonne partie du temps. La version que j'ai reçue est équipée de verres photochromiques, du coup je peux les utiliser de jour comme de nuit sans aucun problème de visibilité et ça c'est un vrai plus pour moi (j'utilise ma roue également pour des trajets de commuting et je pars et rentre très souvent de nuit). Les lunettes sont suffisamment légères pour ne pas se faire sentir sur de longs trajets. Les branches sont facilement réglables pour éviter tout inconfort au long terme également. Les lunettes sont plutôt larges et protègent bien du vent. L'écran se montre net et lumineux dans la très grande majorité des circonstances. Les rares occasions où j'ai trouvé la luminosité trop faible c'est lorsque je roulais un peu avant le lever du jour. C'est lié au port du casque (celui-ci fait un peu d'ombre au capteur de luminosité ambiante), et un simple réglage du niveau de luminosité règle ce problème (on peut définir un niveau de luminosité automatique plus fort via l'application d'ActiveLook ou tout autre application qui le supporte). Le capteur de lumière ambiante fait sinon plutôt bien son travail. Côté batterie, selon la vitesse de rafraichissement des données, on peut s'attendre à une autonomie d'au moins 10 heures, de quoi suffire pour les rando les plus longues ! Le port du casque rends par contre difficile, voire impossible l'usage du capteur de proximité pour changer la vue affichée; je m'explique : déjà il faudra nécessairement ouvrir la visière pour le déclencher, bon c'est une étape supplémentaire mais soit, ça se fait. Par contre les reflets du soleil dans la visière déclenchent parfois le capteur tout seul et là c'est plus embêtant. Pour palier à ce problème j'utilise le bouton capacitif (tactile) à la place pour passer aux vues suivantes, comme ça plus de déclenchement intempestif. Lorsque l'on porte les lunettes, l'affichage des données ne se fait pas au milieu du champs de vision. De ce fait les données affichées "n'obstruent" pas du tout la vue, il faut d'ailleurs légèrement déplacer son regard sur la gauche pour être en mesure de lire les données. C'est assez difficile à expliquer et c'est une expérience à vivre pour comprendre pleinement mais c'est très efficace : les données qu'on souhaite suivre sont accessibles par un seul coup d'œil, de façon ultra rapide sans avoir à quitter la route des yeux. C'est vraiment sécurisant, et ça a changé ma façon de rouler. Je fais partie de ceux qui scrutent avec attention le PWM de leur roue et leur vitesse, notamment pour moduler mon style de conduite en fonction de l'état de la route ou au type de voie emprunté (de nombreux facteurs pouvant influer sur la perception de la vitesse, je préfère m'en remettre aux chiffres). Je trouvais déjà l'utilisation d'une montre connectée géniale mais là on est encore un cran au dessus puisqu'on ne quitte jamais la route des yeux. Un autre intérêt réside aussi dans la possibilité d'afficher des instructions de navigations. J'ai fait un bout de preuve de concept tout a fait fonctionnelle sur montre Garmin (mais qui nécessite pour le moment pas mal de manipulations), et c'est vraiment pratique d'avoir en permanence les instructions de guidage sous les yeux. Vidéo de la preuve de concept (en english): https://fast.wistia.net/embed/iframe/ms6uzu8eri?scheme=https&wvideo=ms6uzu8eri Implémentation navigation garmin (en english): https://fast.wistia.net/embed/iframe/kjo2ln3qtx?scheme=https Vue principale de WheelDash, de haut en bas : batterie des lunettes et heure, PWM, vitesse, température du controleur et % de batterie: Vue secondaire de WheelDash, de haut en bas : batterie des lunettes et heure, durée de l'activité, distance, vitesse moyenne, vitesse max: vue "Racing" de WheelDash, avec seulement PWM (barre et pourcentage) et vitesse pour assurer un rafraichissement des données toutes les 200 ms 😁 Vue navigation du datafield WheelDash : Évidemment comme toujours tout n'est pas parfait : le gros point négatif de ces lunettes est qu'elles ne sont pas compatibles avec des dispositifs de corrections, on peut essayer de d'intercaler des clips avec des verres correcteurs, voir de les porter par dessus ses lunettes (c'est ce que je fais la majeure partie pendant lorsque je fait du développement) mais personnellement je met des désormais des lentilles lors de mes sorties. Il faudra donc patienter un peu pour les porteurs de lunettes, des solutions sont néanmoins en cours de développement chez Microoled. Combien ça coute ? Les Engo2 coutent 300€ (349 pour la version photochromique), c'est une somme mais quand on sait qu'une paire de lunettes de sport "classique" est généralement autour de 150€, leur prix ne me semble pas déraisonnable. La politique Microoled est louable (même si c'est tout a fait attendu, au moins en Europe, ils sont très clairs là dessus) : si les lunettes ne vous convenaient pas pour n'importe quelle raison, vous pouvez les retourner sous 30 jours après achat. Enfin sachez que c'est un produit Français, fabriqué en France (je ne suis pas particulièrement chauvin mais ça mérite d'être cité). Conclusion Ces lunettes sont pour moi une petite révolution, ça correspond vraiment à ce que je recherchais (pourtant sans trop y croire) : un dispositif tête haute clair, sans fioriture, avec une longue autonomie, et cerise sur le gâteau ouvert aux développeurs (comme je le disais la documentation de l'API est particulièrement bien faite). Ce qui est m'a particulièrement marqué c'est qu'avant de les essayer je ne pensais pas que l'expérience allait être aussi édifiante. Avant je regardais périodiquement ma montre pour avoir accès à ma vitesse, à la température de mon contrôleur etc... Désormais un rapide coup d'œil sur la zone d'affichage des données, sans détourner mon regard de la route, me permet d'avoir l'information. Ça paraitra peut-être inutile à certains, notamment ceux qui roulent à l'oreille (le fameux bruit du vent, je reconnais que ça dépanne😛) mais depuis que je les aies je ne peux tout simplement plus m'en passer. C'est devenu pour moi un élément de sécurité à part entière, et c'est encore plus vrai lorsque l'on roule "engagé". C'est donc un gros coup de cœur pour moi et je suis convaincu qu'elles trouveront leur public parmi la communauté : elles ont un réel intérêt pour ceux qui veulent garder un œil sur les variables de leur roue à tout moment et en toute sécurité. Le fait qu'elles soient très ouvertes en terme de développement est aussi particulièrement intéressant car cela veut dire que de nombreux développeur peuvent contribuer à ajouter de nouvelles fonctionnalités aux lunettes à travers leurs apps. A l'heure où j'écris ces lignes ces lunettes sont compatibles avec WheelDash et WheelDash: datafield (versions dev), les applications que j'ai crées pour les montres garmin (https://apps.garmin.com/search?keywords=wheeldash) et ... Roulements de tambours ... Il se trouve que j'ai embarqué dans l'aventure Seba, le développeur d'EUC World, qui après réflexion a décidé lui aussi de s'engager dans cette nouvelle voie : la version d'EUC World supportant les Engo est sortie il y a quelques jours !! Il partage d'ailleurs pleinement mon avis : https://forum.electricunicycle.org/topic/37649-smart-glasses-support-in-euc-world-app-i-want-your-input/?do=findComment&comment=521431 Enfin, info non négligeable pour ceux qui souhaiteraient sauter le pas, j'ai demandé à Microoled si ils pouvaient proposer une remise spéciale pour la communauté : voici un code promo de 40€ pour l'achat d'une paire d'Engo 2 (en verres teintés ou photochromiques): DSHWHL40

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 😁.

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

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. 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 😀) !

Tout a fait, toutes les roues n'ont pas les mêmes paramètres accessibles. EUC World n'est ici que le messager, il transmet les infos à la roue, mais c'est bien le firmware qui détermine les possibilités. Quant à la limitation de vitesse par tiltback c'est à ma connaissance toujours pas possible sur les Leaperkim, je crois par contre qu'on peut par contre définir, via les app, un certain PWM à partir duquel le tiltback se déclenche et ce depuis la patton.

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 😆

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 😅.

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 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 !

Merci pour les compliments 😁. Pour répondre à ta question la valeur de PWM est non signée. Je crois d'ailleurs que le terme PWM est un abus de langage largement répandu dans la communauté, si j'ai bien compris de quoi on cause, on devrait plutôt utiliser le terme "duty cycle". Etant complétement naif dans le domaine je me risque à la question suivante 😅 : Le PWM pourrait être négatif ? Si oui dans quelles circonstances ?

Ok ça fait un bon moment que c'est plus ou moins prêt mais je recule l'échéance à chaque fois 😅. La fonctionnalité de limiteur de vitesse (pour Begode, Kingsong et Inmotion) est prête mais non testée (j'ai pu tester une version précédente sur ma Tesla, c'était fonctionnel mais pas exempt de bugs. J'ai fais des modifs depuis mais entre temps j'ai vendu ma Tesla). J'ai donc besoin de testeurs avertis pour me faire un retour sur les éventuels bugs qui seraient présents. Pour des raisons de sécurité le mode de limiteur de vitesse n'est actuellement activable/désactivable qu'à faible vitesse (<3km/h). Si vous souhaitez tester cette fonctionnalité il faudra installer la version beta de wheeldash (v0.6.4) disponible ici : https://apps.garmin.com/fr-FR/apps/363ecacc-1b86-4863-a13c-49453303e900 J'ai choisi de la détacher de la version dev en attendant les premiers retours. Pour utiliser le limiteur de vitesse il faut : 1-associer un bouton à l'action limiteur de vitesse (pour un profil donné) 2-definir une limite de vitesse, n'est (pour un profil donné, paramètre "speed limit") Il est également possible de définir une vitesse de tiltback via les paramètres de wheeldash (tiltback speed). Ce paramètre a pour valeur par défaut -1 et doit normalement être remplacé par la valeur de vitesse de tiltback actuel de la roue. C'est cette valeur qui sera utilisée pour "restaurer" la valeur de tiltback après désactivation du limiteur de vitesse. La première chose est donc de s'assurer qu'elle ne reste pas à -1 après le premier démarrage ou que la vitesse de tiltback soit correctement définie ! La valeur 0 désactive le tiltback (quand c'est possible). Il faut absolument (et je pèse mes mots) tester la vitesse tiltback, que le limiteur de vitesse soit actif ou non. A ce stade de développement un bug est tout a fait possible et pourrait entraîner une désactivation (réversible) du tiltback. Si ça arrive merci de vérifier vos paramètres et de m'en informer au plus tôt. Un simple paramétrage de la vitesse de tiltback via une autre application remettra les choses dans l'ordre en attendant que je corrige le problème.