tritbool

Dans ce cas, ne t'engage pas, et oriente-toi vers la KingSong 16x par exemple

Elle se trouve très facilement sur e.g AliExpress. Pour peu qu'on souhaite passer par cet intermédiaire. Difficile de savoir pourquoi les revendeurs français (à fuir par ailleurs) ne l'ont plus en stock en revanche.

Bel effort. Pas mal de monde pourra te confirmer que cette roue existe bel et bien. Moi y compris.

Verbeux/20 mais c'est un bon début merci !

J'ai pas pensé en effet que lors du handshake initial les 2 parties puissent définir le cadre de communication mais ça ferait sens. Si qqn a un cours / tuto BLE accessible (i.e pas une doc technique ou du raw code commenté. etc) ça pourrait être cool, j'ai rien trouvé d'utilisable immédiatement et lire les cahiers de specs franchement c'est en dernier recours.

C'est très Meh cette affaire. Si pour toutes les roues les infos de base : voltage, vitesse, temp rentrent dans les 20 premiers octets, alors on s'en contentera. Vaut mieux du minimal fonctionnel que vouloir tout faire mais mal. Pour le reste, à voir le code, sans connaissance préalable du protocole bluetooth. C'est incompréhensible (wheelLog tout autant que le companion garmin d'origine et même que ton app (en parciulier le profile manager 🫣) sans y passer vraiment du temps à tête reposée, et là j'ai pas le temps tout de suite.

A dire vrai je n'ai pas encore la vision exacte de ce qui est possible. Pour ce qui suit, je pars du principe que mes interlocuteurs sur ce sujet ont un minimum de connaissances en génie logiciel. En GRAS les infos principales pour ceux qui parlent surtout le langage naturel. Dans l'idéal je souhaite proposer une librairie ARCHITECTURÉE qui permette au client (ici l'app de la montre) de communiquer avec un ensemble de roues de manière transparente (avec e.g un factory X strategy et probablement des couches d'adapter). En d'autres termes ça reviendrait à proposer une librairie dont le seul objectif est d'encapsuler les communications avec les roues à travers une interface unique et derrière c'est l'app qui gère les données qu'elle envoie/reçoit comme elle l'entend. La délégation ne se fait donc pas sur le fond mais sur la forme. Selon les limitations / contraintes du protocole BLE, il est possible en effet que ce soit faisable ou pas, impliquant peut-être des contournements architecturaux pour e.g assurer que c'est bien l'app qui réifie les instances de communication pour garder le contrôle dessus et éviter les timeout ou échecs de handshake.

J'ai commencé à regarder le code de WheelLog. Mon dieu la phase de rétro-doc que je vais devoir me taper rien que pour reconstruire la partie d'architecture logicielle dédiée au bluetooth. En plus du protocole BLE que je dois comprendre, la doc métier est inexistante (offuscation volontaire ou non ? étrange pour de l'open source), et l'architecture du projet est... très lacunaire. ça va être rigolo x)

Oui. c.f : 3. Comme dit avant, les ports de charge sont des entrées ouvertes, si ta roue a fait un séjour dans l'eau, alors l'eau est entrée dans le contrôleur. PIRE Comme le contrôleur est posé directement sur les packs batteries, l'eau aura pu aller faire un séjour dans les packs batteries, et sera restée au fond, qui est normalement étanche.

Tu peux utiliser de l'alcool isopropylique, mais bien que l'alcool soit soluble dans l'eau (et mes faibles connaissances en chimie), je vois pas bien où tu veux en venir.

Faut quand même faire gaffe à une chose en particulier : La fragilité de la visserie. Les vis pêtent très facilement, et les filetages sont fragiles (aluminium mou à souhait). Au premier démontage c'est souvent très dur à dévisser sans percussion ou chaleur (en particulier les vis du support moteur). Du reste. C'est vrai que tout est accessible assez rapidement. Au prix d'une étanchéité très relative et fonctionnelle uniquement pour des pluies légères au roulage. En effet. Vu la structure de la roue, on a plusieurs points d'entrée d'eau à peu près certains: 1. Le passage de câble au niveau de l'axe moteur. Souvent très mal étanchéifié (d'ailleurs, ne roulez pas dans plus que des petites flaques d'eau avec vos S22 🙏) 2. Le sommet des packs batteries: Les point d'étanchéité entre le bloc contrôleur et les passages des câbles des feux ne sont clairement pas pensés pour une immersion, quelques gouttes sont forcément passées. 3. Comme dit avant, les ports de charge sont des entrées ouvertes, si ta roue a fait un séjour dans l'eau, alors l'eau est entrée dans le contrôleur. PIRE Comme le contrôleur est posé directement sur les packs batteries, l'eau aura pu aller faire un séjour dans les packs batteries, et sera restée au fond, qui est normalement étanche.

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)

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 🤔

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

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 ?

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.

Je désapprouve fortement: les pads sont un immense atout pour la précision de la conduite. Ils mettent le pilote en capacité de complètement contrôler sa roue. Excusez la métaphore ci-après: les pads c'est comme la master sword dans (certains) Zelda. On débute sans, on apprend sans. Puis, on peut finir le jeu sans mais c'est quand même vachement mieux avec. Je disparais.

La plupart des douleurs aux genoux proviennent d'un mauvais positionnement du pilote. Si on fait un parallèle avec les vibrations reçues par les genoux d'un skieur confirmé voire même d'un skieur en ski de bosses, la gyroroue est bien moins violente. Pourtant je ne connais que bien peu de skieurs qui se plaignent de leurs genoux à cause du ski, moi y compris. Il m'arrive aussi d'avoir des douleurs au genou droit. Et c'est systématiquement dû à un mauvais alignement pied-genou-hanche, qui implique une tension dans le genou dans les virages. Si je corrige la posture la douleur disparaît d'elle même. Si je ne la corrige pas, elle s'amplifie, perdure, et m'oblige à faire une pause de plusieurs jours pour éviter d'aller vers une tendinite ou autre douleur chronique. Les genouillères sont un garde fou utile si on doit rouler alors qu'on a mal. Mais les porter en permanence va créer un phénomène de compensation sur la jambe opposée en cas de port unique, voire déporter la compensation sur e.g les hanches, chevilles, lombaires, ... Écouter les signaux de son corps au lieu de vouloir les faire taire est un bon moyen de comprendre quoi faire pour rouler longtemps et sereinement. P.S: Je parle ici de personnes ayant, de base, les genoux "sains".

La roue y est rarement pour quelque chose. C'est une machine. Elle fait ce que le pilote lui demande, dans le cadre pour lequel elle est en capacité de répondre. Hormis le cas (qu'on espère le plus rare possible) où une défaillance machine advient (MoBo, Controleurs, Capteur Hall, etc...) Dans l'immense majorité des cas, une chute est dûe au pilote qui aura trop poussé sa machine, mal anticipé une situation, pas assez d'expérience, etc... J'en veux pour preuve, l'autre jour j'ai été faire une bonne grosse sortie en S22 dans les chemins par chez moi. Je me suis pris 2-3 belles bûches (RàS rassurez-vous) sur terrain boueux parce que ce dit terrain n'était pas composé du même sol (argile visiblement, ça collait bien au pneu, en sous bois, avec lunettes, je voyais pas trop la diff. de couleur/texture) que les terrains précédents sur mon parcours, boueux aussi mais bien moins glissants (humus, terre végétale, n'accroche pas au pneu). Evidemment je roulais à 10-15 en essayant de rester le plus droit possible et de ne donner aucune inclinaison à la roue. ça n'a pas suffit=> Pilote en tort (mauvaise compréhension de l'environnement) Il m'arrive aussi de faire tomber la roue quand je fais des demi-tours sur place. Parce que la roue a un centre de gravité logistique: si on dépasse un seuil d'inclinaison U vitesse, le centre de gravité monte d'un coup et la roue va irrémédiablement se coucher sur le flanc. Y a rien d'autre à faire que d'apprendre à comprendre ce comportement => Pilote en tort, encore. Et je pourrais citer nombre d'exemples avec e.g la Z10, qu'on aura tendance à considérer stochastique, ce qui n'est pas le cas. Son comportement est relativement déterministe, mais il convient de l'apprendre pour le réaliser. Finalement, les roues "difficiles à rouler" ont ça pour elles qu'elles exigent du pilote qu'il soit constamment en train de douter de sa capacité à rester debout sur sa machine, et donc, éviter de ressentir une illusion de sécurité en roulant à 40 kmh en gyroroue. P.S: PAVE CAESAR, CEUX QUI N'ONT PAS LU TE SALUENT.

Ah je croyais que les bretons étaient une denrée rare par ici ! Bienvenue à toi, @Boutdumonde!

FYI: Une MàJ du BMS vers 2.19 est dispo. Je l'ai faite, ça s'est bien passé. Pas encore roulé avec cette nouvelle version des BMS, mais j'imagine que ça doit pas changer lourd.

J'allais suggérer exactement la même chose.

Je viens de vérifier sur ma MTEN4, le trolley de la A2 semble avoir un étage supplémentaire. Ce qui est... con ?

Il s'agit vraisemblablement ici une tentative de construction mémétique (https://fr.wikipedia.org/wiki/Mémétique) autour des gyroroues. Un mème étant un "objet" qui se reproduit par mimétisme (https://fr.wikipedia.org/wiki/Mème) au sens large du terme (sur internet, donc, c'est les trucs types images, gif ou vidéos qui deviennent viraux e.g )

Le canal d'ille et rance amène à Saint Malo. Après il est possible de suivre certains sentier côtiers, mais de bonnes parties sont interdites aux cycles.