Un projet fou [évolution du Ride by Wire]

[Philartis]

J'ai commencé à en parler ici : viewtopic.php?p=816315#p816315 , mais avant toute chose, petit rappel et mise au point :

- Je ne suis pas technicien mais je cherche quand-même une éventuelle solution pour améliorer la réponse des gaz des Hornet et Transalp 750 des années 2023 et 2024 uniquement (celles qui souffrent d'un comportement plus ou moins brutal à très faible ouverture des gaz).
- Il est possible que je m'oriente vers une mauvaise voie, que je fasse des erreurs.. je compte sur ceux qui savent pour me corriger.

Ce que j'ai personnellement constater :
La faible ouverture des gaz est brutale, le mode RAIN améliore en partie cette zone mais rend la moto trop peu réactive ensuite.
Des mesures de tensions en sortie des capteurs (il y a deux circuits en //) montre des choses qui me semblent anormales - habituellement les tensions de sortie des deux circuits sont différentes, ce qui permet une redondance et une sécurité accrue, mais en ce qui nous concerne il y a un détail que je n'ai jamais vu ailleurs : le circuit No2 ne commence à délivrer une tension qu'à partir de plusieurs degrés de rotation.
J'ai pu noter de légers soubresaut lors d'une conduite stabilisé en tentant de garder la poignée fixe autour de 5 ou 6° (les modèles 2023 et 2024 peuvent indiquer l'angle poignée sur le compteur).
Les modèles plus récents ne sont pas impactés par ces accoups - on notera que leur poignée des gaz est différente, au moins en apparence extérieure.

Ici, c'est le sujet traitant de ces relevés de tensions et le tracé des courbes correspondantes : viewtopic.php?t=40037

Mon idée de départ était de simplement (c'est facile à faire sans électronique compliquée) rectifier le canal No2 en utilisant le No1 comme base.
En effet, les tensions du canal 2 sont celles du canal 1 divisées par 2.
Si ça fonctionnait, cela réglerait surement le problème du signal ASP2 en début de course de la poignée des gaz, mais ne changerait rien à la non linéarité (forme chahutée) du signal ASP1.. entre autre..

Pour un résultat plus propre, l'utilisation d'un microcontrôleur permet de linéariser intégralement ASP1 depuis l'angle 0° jusqu'à 67° (poignée tournée au maximum).
Ce signal "nettoyé" est ensuite utilisé pour construire le signal du 2eme canal (ASP2).

Ça, ce sont les signaux d'origines :

c110a.jpg (10.53 Kio) Vu 1372 fois

Et ça, ce que ça donne après "traitement" :

c210a.png (13.95 Kio) Vu 1372 fois

Puisque un microcontrôleur est présent, une personnalisation devient envisageable pour modifier le comportement de la poignée des gaz.
Pour cela, il y a la possibilité d'ajuster la réponse des gaz - un peu à la façon des modes Rain, Standard ou Sport, mais avec des réglages de niveau d’efficacité et de seuils en complément.

Les réglages se font depuis une page web (l'erreur matériel affichée, c'est parce que les ADC et DAC n'étaient pas câblés au moment de la copie d'écran) :

Screenshot_20260801_125747_Chrome[1].jpg (21.48 Kio) Vu 1372 fois

Limite dynamique
Le logiciel applique automatiquement une limite du gain en fonction des réglages A1 et A2.
En cas de réglages extrêmes, l'ECU pourrait voir une décélération alors que le pilote continue d'ouvrir les gaz et à l'inverse, une accélération alors que le pilote décélère..

Le problème survient quand la pente descendante du coefficient est plus forte que la pente montante naturelle de ASP1 et l'inverse peut également se produire dans le 2eme cas.

Solution :
Plutôt que de corriger en temps réel et créer d'autres problèmes, le logiciel empêche les réglages utilisateur qui créent celui-là. Il calcule le coefficient maximum autorisé selon A1 et A2 choisis, puis limite en conséquence la plage autorisée du slider de mode.

Plus A1 et A2 sont proches, plus la plage du coefficient est restreinte avec un message explicatif :
"Coefficient maximum pour ces angles : x0.70 (soft) à x1.30 (hard)" (ce sont les valeurs par défaut), mais le logiciel peut réduire la plage de réglage jusqu'à x0.94 à x1.06 selon les valeurs de A1 et A2.

En d'autres termes, il y a un garde fou qui empêche l'utilisateur de régler n'importe quoi.


Remarques :

Les modes de conduite d'origines de la moto (Rain, Standard, Sport) modifient déjà la relation entre la position de la poignée des gaz et le signal transmis au boitier de papillons.

Le programme proposé ici agit également sur ce même signal (entre la poignée et l'ECU, cette fois-ci). Si un mode de conduite autre que Standard est sélectionné, les modifications apportées par le mode de conduite et celles du programme se cumulent. La réponse de l'accélérateur peut alors être différente de celle attendue et devenir plus ou moins progressive selon la combinaison choisie.

Pour obtenir un comportement prévisible et faciliter le réglage, il est sans doute plus simple d'utiliser le mode Standard de la moto (ou le mode User pour bénéficier des réglages d’efficacité du TC et EB, mais en réglant la puissance sur sa valeur médiane).

Pour faciliter la mise au point, je me suis fait un simulateur reproduisant les signaux de la poignée des gaz, en incluant les défauts de la poignée d'origine, c'est à dire la linéarité imparfaite et le décalage du canal ASP2 en début de rotation.

20260716.jpg (30.62 Kio) Vu 1372 fois

Je suis à disposition pour toute question s'il y en a, et à l'écoute de tout commentaire (ne me traitez pas de fou, il y a déjà ma compagne qui s'en charge..).

[paraglandeur]

Beau travail !!!
J'imagine que tu rajoutes un boitier avec un microcontrôleur style ESP32 entre la poignée de gaz en le câble de commande.
Tu as donc trouvé comment lire les valeurs venant de la poignée de gaz.
Tu peux nous en dire plus ?
C'est "juste" une valeur digitale (ou analogique) qui sort de la poignée ?
Comment intercales-tu ton boîtier de correction dans le circuit de la moto ?

Sinon, l'idée est géniale : tu interviens avant les corrections faîtes par l'ECU de la moto, donc les modes rain/std/sport restent valables.
En fait, le problème viendrait de la poignée elle-même.
Rien que cette découverte devrait pouvoir obliger Honda à proposer un échange standard de cette pièce.

(Rien à voir, mais je suis moi-même en train de batailler avec un ESP32 et plusieurs capteurs/drivers pour réaliser un robot nettoyeur de surface pour piscine.)

[Philartis]

Oui c'est bien un ESP32 - un ESP32 C3 supermini pour être précis.
Il est largement suffisant pour cette application et surtout comme son nom l'indique, super mini en taille, et ça c'est idéal pour le loger sur une moto.

Les signaux en question sont analogiques : viewtopic.php?t=40037

Le boitier (que j'ai appelé "intercepteur") est inséré entre la poignée et l'ECU - En gros le câblage est celui-là mais il n'est pas totalement finalisé :

cablag10.jpg (53.58 Kio) Vu 1359 fois

Garder à l'esprit que je n'ai pas terminé ni rien testé - c'est juste un projet en cours basé sur des suppositions, en ce qui concerne le résultat attendu.

[Chambrial]

Je suis à disposition pour toute question s'il y en a, et à l'écoute de tout commentaire (ne me traitez pas de fou, il y a déjà ma compagne qui s'en charge..).

....

@Philartis Chapeau bas...

J'espère que les tests seront concluants.

[Flan]

C'est complètement fou mais tellement plausible et bien mené que c'est très excitant.

As tu constaté le problème du second signal sur une autre moto ?

Au delà de corriger un problème à la poignée, est ce que ce boitier permettrait aussi de changer le comportement moteur par rapport à la rotation de la poignée pour améliorer le couple sur les bas régime ?

[Philartis]

Non, je n'ai jamais eu l'occasion d'essayer une autre Hornet ou Transalp de 2023 ou 2024. Une Transalp 2025, oui et elle est épargnée de ce défaut mais je n'ai fait aucune mesure.

Au delà de corriger un problème à la poignée, est ce que ce boitier permettrait aussi de changer le comportement moteur par rapport à la rotation de la poignée pour améliorer le couple sur les bas régime ?

Le boitier permettrait en effet de changer le comportement moteur et même si je m'avance (sans doute beaucoup trop, à cette heure) de bénéficier d'un régulateur de vitesse simple.. un doux rêve.

Tel qu'il est actuellement, il permet de corriger un segment seulement de la course de la poignée, mais je pense que c'est déjà suffisant :
Par exemple, dans le cas où on utiliserait le mode "SPORT" de la moto et en ajustant les réglages du boitier tel que sur la 1ere photo de ce sujet, alors on se retrouve grosso modo avec un mode "RAIN" en tout début de course puis un passage en douceur vers le mode "SPORT".
Le taux d’efficacité, le sommet (c'est à dire l'angle de la poignée où l'atténuation/l'amplification est la plus élevée) et la fin de correction (pour un retour transparent à la courbe d'origine) sont tous réglables - il y a largement moyen d'obtenir une réponse correspondant à nos désirs.

Il y a toutefois un aspect que je n'ai pas abordé encore, c'est le coté sécurité - on touche ici à la commande des gaz tout de même, alors je ne sais pas si j'oserais réellement un jour..

Ceci dit, c'est un montage qui ne demande qu'à être amélioré, voir totalement remanié, et dans tous les cas c'est un sujet qui me passionne et ça c'est déjà bien.

Pour ceux qui voudraient se pencher sur le truc, j'ai mis ici le code pour l'ESP32 C3 supermini en version ultra simple et rapide (2 minutes) à installer sur ce lien provisoire : https://helpful-lokum-823e0e.netlify.app/

Dans ces programmes (il y a la version simple et celle avec régulateur de vitesse), le wifi n'est actif que durant 5 minutes. Ce temps sera prolongé par la suite mais il faudra installer un petit refroidisseur sur le microcontrôleur comme je l'ai fait ici :

20260803_002640[1].jpg (6.77 Kio) Vu 1293 fois

Le nom du Wifi est "CB750-Hornet" et le MDP "hornet750".
Ensuite dans la barre d'adresse de votre navigateur, taper : "192.168.4.1" (de la même façon que vous écririez une adresse web) pour accéder à l'interface de réglages.

La version avec régulateur nécessite de câbler quelques autres composants (utilisation du capteur vitesse de la moto, capteur de frein, d'embrayage et d'ajouter la commande au guidon).
A aucun moment je n'utilise le bus CAN (par choix et surtout par incompétence).

[paraglandeur]

@Flan à partir du moment où tu t'intercales entre la poignée de gaz et l'ECU de la moto, tu émules la poignée de gaz, donc théoriquement tu fais ce que tu veux.
Tu pourrais te créer toi même tes propres modes de conduite avec, par exemple, un mode Trial où tu aurais une réponse très très très plate sur une grosse plage de rotation de la poignée, puis une montée en puissance rapide sur la fin.
Et comme @Philartis a pensé à activer le WiFi de l'ESP32, il pourrait ajouter une option pour éditer sois-même les courbes, et les mémoriser dans des fichiers stockés dans la zone SPIFFS de l'ESP32.
Ensuite, un petit commutateur rotatif permettrait de sélectionner le mode voulu en relisant ces données (il existe des commutateurs jusqu'à 16 positions)
La moto serait réglée sur le mode standard, donc linéaire, et c'est le boîtier de Philartis qui gèrerait tout.
Le mode "zéro" du boîtier serait le mode neutre, qui ne changerait rien aux données.

Ensuite, comme le dit Philartis, reste la question de la fiabilité et de la sécurité.
Par exemple :
A l'allumage, lire les données mémorisées, vérifier leur intégrité (donc prévoir la création/lecture d'un checksum pour chaque fichier de réglage)
Prévoir la mise en place d'un flag (mémorisé lui aussi dans la zone SPIFFS) avant toute écriture, puis l'enlever après celle-ci. De cette façon, lors de l'allumage on saura si un fichier était en cours d'écriture au moment de l'arrêt de fonctionnement de l'ESP32. Et si le flag contient le nom de ce fichier, on pourra le remettre à zéro et afficher l'erreur sur l'écran OLED du boîtier (car oui, il devra avoir un écran OLED ).
De cette façon, si l'écriture n'a pas pu être menée à bien (bug ou coupure d'alimentation de la part de l'opérateur) ou si un fichier est corrompu, on devrait pouvoir le savoir.


Nul doute qu'en cas d'accident, adieu la couverture assurance, voir même la possibilité d'inculpation de la part de Honda pour modification non autorisée d'un accessoire de commande essentiel du véhicule.

Je pense que le projet est super intéressant par son côté R&D, mais que cela doit rester un proof of concept.
Ceci dit une fois finalisé (avec la partie édition de courbes perso), pourquoi ne pas proposer cette modification à Honda...

Et encore bravo à l'auteur pour l'idée et la mise en pratique

[Philartis]

Pour améliorer la sécurité, le programme a été modifié (j'ai utilisé Claude).

1. Une surveillance en continu, pas juste au démarrage
Avant, le boîtier vérifiait que tout fonctionnait correctement une seule fois, au démarrage. Si un problème survenait plus tard pendant la conduite (un faux contact, une perturbation électrique), rien ne le détectait.
Maintenant, le boîtier revérifie en permanence, plusieurs fois par seconde, que la communication avec ses capteurs et ses composants internes fonctionne toujours normalement.

2. Une détection des signaux incohérents
Une poignée de gaz ne peut pas physiquement passer d'un angle à un autre de façon instantanée, et le signal électrique du capteur ne peut pas sortir d'une certaine plage de tension normale. Le boîtier vérifie maintenant que le signal reçu reste toujours plausible :
Pas de valeur électriquement impossible (signe d'un problème de câblage ou de parasite)
Pas de saut brutal qui ne correspondrait à aucun mouvement réel de la poignée
Si un signal suspect apparaît, il est ignoré plutôt que transmis tel quel.

3. Une position de repli sûre en cas de problème
C'est le changement le plus important. Si le boîtier détecte un problème persistant, il ne se contente plus de couper ou de rester bloqué sur la dernière valeur : il ramène progressivement la commande transmise à l'ECU vers la position "gaz fermés" — c'est-à-dire l'état le plus sûr possible, celui du ralenti. Pas de coupure brutale, pas de comportement figé sur une valeur au hasard.

4. Un "chien de garde" contre les plantages
Comme n'importe quel petit ordinateur, le boîtier peut en théorie se figer (un bug logiciel, un imprévu). Un dispositif de surveillance interne détecte maintenant ce genre de blocage et force automatiquement un redémarrage propre du boîtier, plutôt que de le laisser figé indéfiniment.

5. Un dispositif de secours matériel (en cours d'intégration)
C'est la protection la plus robuste, parce qu'elle ne dépend pas du programme lui-même : un relais physique, séparé du reste de l'électronique, va être ajouté. Ce relais reste connecté par défaut au signal brut du capteur d'origine, directement vers l'ECU. Il ne bascule vers le signal corrigé du boîtier que si celui-ci confirme activement, en permanence, qu'il fonctionne normalement.

Concrètement : même dans le pire des cas — un plantage complet du boîtier, une coupure de son alimentation — la moto ne se retrouve jamais avec un signal figé ou incohérent envoyé à l'ECU. Elle repasse automatiquement sur le signal d'origine du capteur, exactement comme si le boîtier n'était pas monté.

Cette dernière version du code est prête mais n'est pas encore accessible depuis le lien donné dans le message précédent.

Ce que ça ne résout pas :
Cette fiabilisation protège contre les pannes électroniques et les plantages logiciels. Elle ne remplace pas un entretien correct du câblage et des connecteurs, qui reste la première ligne de défense sur un montage exposé aux vibrations et à l'humidité d'une moto. Un connecteur mal serti restera toujours un point faible, quel que soit le niveau de sophistication du logiciel.

[Charly]

Bravo @Philartis !!!!! Ton truc a l'air vraiment bien pensé !

Très sérieusement, ton boitier m'intéresse mais je n'ai pas les compétences pour le construire. Si par hasard tu en fais quelques uns, je suis preneur !!!!!
Si il faut que je vienne en région bordelaise pour faire des essaies, ça peut se programmer...

Charly

[Philartis]

Il est bien trop tôt encore pour un réel tuto ou un boitier clé en main mais si tout se passe comme j'aimerais alors on en reparlera.

Actuellement c'est juste un projet d'amateur en cours de développement - il n'est pas finalisé encore et ne le sera peut-être jamais si trop de problèmes surviennent.
Dans tous les cas c'est un projet qui me plait et qui m'apprend plein de choses intéressantes.
Je diffuse ces infos surtout dans le cas où d'autres voudraient participer à sa mise au point, auraient des idées, des mises en garde ou autres commentaires, toussa..

[paraglandeur]

Super gestion des erreurs !!!
Je suis intéressé sur la mise en place du watch-dog, d'un point de vue théorique.
Comment gères tu cela sur un ESP32 ?
Sur un ordi, je comprend bien que tu lances un process séparé qui tourne en arrière plan et surveille la présence d'autres processus critiques.
Mais sur un ESP32, c'e n'est pas du multiprocess.

C'est là que ta méthode m'intéresse.

[Philartis]

Comme précisé en 1ere ligne de mon message de 13:25, j'ai fait appel à Claude pour modifier le code existant et intégrer ces sécurités (moi je ne suis pas assez calé pour ça).
Du coup je lui ai transmis ta question et voici ce qu'il me dit de te répondre :


Bonne question, et la remarque est pertinente — il n'y a effectivement pas de multiprocessing au sens où on l'entend sur un PC.

Sur un ESP32, il n'y a pas de "processus séparé" qui surveille les autres au sens où tu l'entends sur un PC (avec un OS qui ordonnance plusieurs processus indépendants en mémoire protégée). Le mécanisme est en fait plus radical, et c'est ce qui le rend fiable : ce n'est pas un logiciel qui surveille, c'est un circuit électronique dédié.

Le composant clé : un timer matériel, séparé du CPU

L'ESP32 contient, à côté du ou des cœurs de calcul, des timers matériels indépendants — de petits circuits qui comptent tout seuls, avec leur propre horloge, sans jamais exécuter la moindre instruction de ton code. On leur dit "décompte à partir de X secondes", et ils décomptent, point final, quoi qu'il arrive au CPU pendant ce temps.

Le principe du watchdog :

Au démarrage, on configure ce timer avec une durée.
Le programme est censé venir "réarmer" ce timer régulièrement (esp_task_wdt_reset() dans mon code), à chaque tour de boucle réussi.
Si le programme plante, se fige, ou se bloque quelque part (par exemple coincé sur un appel I2C qui ne répond jamais), il n'exécute plus la ligne qui réarme le timer.
Le timer, lui, continue de décompter tranquillement en arrière-plan — parce qu'il n'a jamais eu besoin du CPU pour fonctionner, il tourne sur sa propre horloge matérielle.
Quand il arrive à zéro sans avoir été réarmé, il déclenche un signal électrique de reset qui force un redémarrage complet de la puce, au niveau matériel — pas une simple relance du programme, un vrai reboot électronique, comme si on avait coupé/remis l'alimentation.

La différence essentielle avec un PC

Sur un PC, le watchdog software surveille d'autres logiciels (des processus), donc si l'OS entier plante, le watchdog plante avec lui. Sur l'ESP32, le watchdog est un morceau de silicium séparé du CPU qui exécute ton code : même si absolument tout le logiciel est figé — ton programme, le système FreeRTOS qui tourne en dessous (eh oui, même sur un ESP32 mono-cœur comme le C3, il y a un petit OS temps réel qui gère les tâches, c'est lui qui fait tourner loop() en tant que "tâche" en interne) — le timer matériel continue de tourner tout seul et finira par forcer le reset.

C'est en fait le même principe qu'un minuteur mécanique à ressort qu'on doit réarmer régulièrement : tant que quelqu'un vient tourner la clé à temps, rien ne se passe. Le jour où plus personne ne vient, le minuteur sonne quand même, indépendamment de ce qui a mis la personne hors service.

[Flan]

Merci à tous les deux pour les explications.

Effectivement c'est une excellente organisation que d'anticiper les sécurités matérielles et logicielles.

Concernant le simulateur sont tu parles peux tu m'expliquer comment tu as fait et à quoi il te sert exactement ? C'est pour envoyer des situations à ton programme (des tensions ?) et le tester en quasi situation ?

[Philartis]

Oui c'est exactement ça, c'est "juste" une poignée des gaz sous la forme d'un slider à déplacer au lieu d'une véritable poignée à tourner.

L’intérêt est juste de ne pas à avoir à acheter une poignée pour faire des essais "à l'atelier", et puis c'est plus pratique.
Là, je peux figer précisément un angle de rotation et faire des mesures en même temps, par exemple.
Au final, il ne sert qu'à la mise au point et certains tests mais est totalement inutile pour le fonctionnement du projet.

Comment j'ai fait ?
J'ai utilisé une carte ESP32 avec écran tactile et utilisé l'IA pour concevoir le code.
Celui-ci reproduit les tensions que j'ai réellement mesuré sur chacun des 2 canaux de la poignée de ma moto (0 à 67° de rotation, soit 68 valeurs par canal) et donc leurs défauts de linéarité, et donc encore le défaut supposé du début de rotation du canal 2 également pour obtenir une reproduction fidèle.

Les sorties de ce montage (2 convertisseurs DAC) "attaquent" les entrées du boitier "Intercepteur", ce qui me permet de vérifier l’efficacité des corrections (la page web de ce dernier affiche les tensions d'entrées et de sorties corrigées) :

Capture d'écran 2026-08-04 223204.png (21.61 Kio) Vu 1185 fois

[paraglandeur]

Comme précisé en 1ere ligne de mon message de 13:25, j'ai fait appel à Claude pour modifier le code existant et intégrer ces sécurités (moi je ne suis pas assez calé pour ça).
Du coup je lui ai transmis ta question et voici ce qu'il me dit de te répondre :
...

Tu feras une bise à Claude de ma part

Blague à part : je ne connaissais pas cette spécificité de Timer sur l'ESP32.
Il va se coucher moins con, le paraglandeur
Son utilisation est géniale.

[Philartis]

Oui, par contre cela signifie l'ajout d'un relais câblé comme ci dessous et d'un petit monostable (sur la base d'un NE 555).

Au repos, la sortie du 555 (Pin 3) est à l'état BAS. Une impulsion de déclenchement de l'ESP sur Pin 2 su 555 fait passer la sortie à l'état HAUT pour une durée de 240 ms, puis Pin 3 retombe BAS tout seul à la fin du délai — sauf si une nouvelle impulsion arrive avant que le délai soit écoulé, auquel cas le compteur interne repart de zéro et Pin 3 reste HAUT.

C'est exactement ce qu'on exploite dans le montage : le heartbeat de l'ESP32 envoie une impulsion toutes les 10 ms, largement avant que les 240 ms du délai ne soient écoulés. Résultat : Pin 3 n'a jamais le temps de retomber — il reste HAUT en continu, réarmé en permanence par chaque nouvelle impulsion, bien avant l'échéance du délai précédent.

Le seul moment où Pin 3 retombe à BAS, c'est quand aucune nouvelle impulsion n'arrive pendant 240 ms d'affilée — c'est-à-dire quand le heartbeat s'est arrêté (ESP32 planté, bloqué, coupure d'alimentation). Le 555 termine alors son dernier délai enclenché par la dernière impulsion reçue, et comme rien ne vient le réarmer, Pin 3 bascule à BAS à l'échéance de ce délai - ceci désactive le relais qui retombe au repos, et l'ECU retrouve le signal brut du capteur.

2026-08-04 212325.jpg (20.89 Kio) Vu 1147 fois

Ce qui m'embête un peu, ce n'est pas l'ajout du 555 à proprement parler, mais le fait qu'il faille concevoir un petit montage (5 composants) - c'est ce que je voulais éviter car moins facile à mettre en œuvre qu'un module tout fait pour les bricoleurs peu habitués.

[Flan]

J'ai comme impression que les à coups peuvent provenir du problème observé en voie 2 (ASP2 d'ailleurs il veut dire quoi l'acronyme ?) c'est à dire qu'il envoie 0 Volts sur le début de rotation de la poignée.

Tu sais ce que c'est comme capteur à la poignée ? Résistance ? Comme dans un simple montage diviseur de tension.
Es tu sûr que cette anomalie n'est pas que sur TA moto ?
Par exemple la piste d'une résistance variable qui serait défectueuse...

Autre piste pour l'origine des à-coups : Les courbes en réponse pour chaque signal provenant de la poignée qui ne sont pas lissées.
Est ce à chaque fois la même courbe, c'est à dire les mêmes imperfections à chaque mesure ?

[Philartis]

Le capteur est du type "Hall" - il réagit au champ magnétique d'un aimant entraîné par la poignée.
J'ai ouvert la poignée mais je n'ai pas démonté la partie qui enveloppe l'ensemble capteurs et aimant, je n'ai donc pas vu comment s'est foutu exactement.
Je ne sais pas non-plus si c'est uniquement ma moto qui est touchée par cette curiosité du canal 2 et c'est bien dommage, mais en même temps j'ai du mal à imaginer que ce soit une exception.

Comme je n'ai trouvé personne pour faire les mêmes contrôles que moi, je ne suis sûr de rien.

Pour ce qui est du lissage des courbes, la difficulté est que si le compteur indique bien chaque angle de rotation, la tension entre 2 angles affichés évolue.
Sans savoir exactement, le compteur peut indiquer 10° quand la poignée est en réalité entre 9,5 et 10,5° mais la tension elle, évolue.
Ce n'est donc pas hyper facile de tracer une courbe de réponse totalement fidèle.
Même si je me suis appliqué à faire au mieux, les valeurs lues peuvent varier d'une fois à l'autre, mais les "grosses" perturbations sur la courbe restent toujours présentes.

Ceci dit, je ne possède ni le matériel ni les compétences pour faire des contrôles encore plus précis.
J'ai bien pensé acheter une poignée (2025) mais même en admettant que ça règle ce 1er problème, ça ne me donnera toujours pas la possibilité de faire ma propre courbe de réponse, ni d'envisager un régulateur - enfin si, mais ça ne me donnerait pas moins de boulot.

[Charly]

Hello

Je n'ai pas pu faire les mesures de Philartis, mais je constate le même comportement à très bas régime : c'est difficile de rouler sur le couple "tout en bas" car le moteur fait un peu du ON-OFF et cela peut provoquer un calage moteur (vécu...).

Charly

[Flan]

Oui il y bien l'incertitude à prendre en compte mais entre 9 ou 10° ... Ça importe peu. Enfin j'ai impression.
Reste à voir comment c'est envoyé aux moteurs des papillons en fin de chaîne...

Merci pour les réponses en tous cas

Il faudrait pouvoir avoir accès à une Transalp ou une autre Hornet pour avoir une base de comparaison.
Rien sur ton forum ni ici ?

[Philartis]

Sur mon forum, j'ai pas l'impression que ça les passionne.. alors finalement j'en parle moins qu'ici.
Bon, c'est un tout petit forum de 200 membres environ, alors forcément ça ne fait pas beaucoup de candidats potentiels au débat.

Pour faire les mesures sur une autre moto, ce n'est pas forcément simple pour tout le monde et comme ces versions de Hornet et Transalp sont encore récentes, il y a je pense, des craintes "de tout casser".

[Chambrial]

J'ai mis dans mon menu d'affichage l'information angle de poignée pour trouver cette zone comme @Philartis l'a fait.
Verdict: plage de 3 à 5° avec une zone nette à 4° où c'est une purge.

[Charly]

Hello

Que veux tu dire par "purge" stp ??

Charly

[paraglandeur]

moi je comprends : c'est le bordel, c'est du n'importe quoi.
Au moment où la rotation de la poignée est de 4°, les valeurs fluctuent very très beaucoup

[Flan]

Ce n'est pas un hasard car 4° de rotation c'est justement là où la courbe numéro 2 (ASP2) passe de zéro à une valeur "normale"...
Si le calculateur compare les deux signaux il reçoit donc une valeur anormale avant 4° ... Et une plus logique après.

341314884~2.jpg (13.45 Kio) Vu 471 fois

Il faudrait pouvoir mesurer d'autres signaux ASP sur d'autres motos.

@Philartis J'ai comme dans l'idée que simplement renvoyer le Signal ASP2 "simulé" pourrait déjà solutionner le problème... J'espère.

Penses tu que si le calculateur reçoit un signal nul avant 4° de la voie ASP2:
1. Il bascule sur la 1 seule ?
2. Il se met à buguer ? ...
3. ou il en déduit une ouverture bien plus grande de la poignée... ?

[Chambrial]

Pour reprendre vos trois post @Flan @Charly @paraglandeur

Comme le décrit @paraglandeur à 4° c'est là où les à coups culminent, j'ai une conduite plutôt cool et je suis souvent sur cette plage de 3 à 5° d'angle de poignée. C'est ma zone de filet de gaz en rond point, virages et ville, sur des petites relances douces qui deviennent inconfortables, déséquilibrantes et dangereuses. Elles me donnent des à coups moteurs et des à coups sur l'ensemble de la moto du coup.

Et j'ai pensé à quelque chose, que Flan reprend dans son post, à savoir faire un appel à toutes les personnes du forum ayant ce problème, en participant à un questionnaire type.

Année du modèle de la T@750 (le top serait d'avoir le mois et l'année de fabrication)
Ressentez vous des à coups à bas régime (reprise de gaz ou mise de gaz)
Angle de la zone des à coups (c'est simple à voir vu que l'on peut visualiser cette info dans le menu de la T@750)

L'on peut créer un post concernant ce questionnaire où chacun vient déposer ces infos ?

[Flan]

@Chambrial je crois que @mariano avait proposé un topic sondage ici : viewtopic.php?p=805506#p805506

C'est peut être ça dont tu avais envie ?

[Chambrial]

@Chambrial je crois que @mariano avait proposé un topic sondage ici : viewtopic.php?p=805506#p805506

C'est peut être ça dont tu avais envie ?

Non, ce que je voulais dire c'était quelque chose de pas ouvert à la discussion, plus en mode questionnaire médical pour obtenir de la donnée.
Je me demande si l'on peut faire cela avec un lien style Frama ou autre...
Je sais pas, je me dis que cela peut être intéressant ?

[Flan]

Je suis de ton avis...
Il y a aussi les outils Google...

[Philartis]

Juste pour test, j'ai essayé un formulaire là : https://docs.google.com/forms/d/e/1FAIp ... Q/viewform

Il y a peut-être des bugs, à voir..

L'analyse des résultat permettrait d'exploiter ces données :

- le pourcentage de Hornet et de Transalp présentant des à-coups ;
- les résultats par année et kilométrage ;
- les plages de régime les plus concernées ;
- les rapports les plus concernés ;
- l'influence de la remise des gaz après coupure totale ;
- l'influence des modes Rain / Standard / Sport ;
- l'influence de la température moteur ;
- la reproductibilité du phénomène ;
- les résultats des interventions en concession ;
- le niveau de gêne moyen ;
et surtout les croisements permettant de déterminer s'il existe un profil commun aux motos concernées.

Les réponses des propriétaires qui ne constatent AUCUN à-coup sont particulièrement importantes pour pouvoir comparer les motos concernées et celles qui ne le sont pas.