Reprise du message précédent :

Merci Kro, avec l'openrouteur j'ai accès a des modèles frontière, mais y a pas beaucoup d'interêt. Je voulais surtout tester une connexion locale pour valider que ça fonctionnait et que mes 3 cas d'usage étaient fonctionnels (Claude API, Openrouter API et connexion locale).
 
Par contre je suis vraiment curieux de comment tu as pu récupérér ces DGX ? via le boulot ?
 
Quand je vois les tarifs que HPE nous sort pour des serveurs d'inférence en ce moment....

Je les ai eu comme beaucoup de choses par des moyens que je préfère éviter d'ébruiter sur un forum public  

Je sais pas si c'est parce que j'y connais rien mais le boulot joel

J'ai oublié de te répondre sur ce point, oui l'ensemble est en deux parties, un boitier avec l'écran, relié par des cables a un boitier avec le raspberry qui est fixé sous mon tableau de bord
 

 
J'ai juste a démonter ma plaque supérieure, et j'y ai accès. J'ai d'ailleurs du le faire ce WE, car sur mes premiers tests de passage en lecture seule du filesystem du Pi, j'ai perdu le réseau. Donc plus moyen d'accéder en SSH sur le Pi, le dashboard marchait, mais je ne pouvais plus le modifier/upgrade ou quoi que ce soit. J'ai du récupérer la carte SD pour modifier les parametres de boot.
 
J'ai aussi utilisé des connecteurs entre le pi et l'écran, tout est démontable sans aucun problème.  
 
J'avoue que je me dis, bon, y a pas grand chose pour aller a l'étape du dessus et faire un truc "commercialisable"

Ça me semble aussi très abouti et proche des solutions qu'on peut trouver dans le commerce. Reste que le mieux serait de pouvoir gérer les paramètres et le récupération des logs depuis une app de smartphone à mon avis.

Sinon, les écrous à riveter, c'est bien pour fixer des extensions ? Mes side skirt sur la M4 ont été fixés à la vis à bois et à l'autocollant 3M, mais je voudrais dégager ça pour les fixer avec quelque chose de plus sérieux et durable.

Des choses dans le genre:

https://eshop.wurth.fr/v/ecrou-rive [...] bHoK3kqX60

Ça irait dans la tôle fine d'une voiture ? Je pose la question ici car ça me semble être le topic le plus adapté, même si j'imagine qu'elle topic Jacky tuning pourrait aussi faire l'affaire  

 
C'est avec ça que les miennes sont fixées en effet. Pas de soucis mais sur une voiture qui n'est pas pourrie comme la mienne, je ferais gaffe en terme de protection et prévention contre la rouille, traitement des trous, des écrous etc....
Apres le 3M VHB est plutot adapté en doublement des écrous borgnes.

Je compte passer un coup de rustol sur chaque trou percé  

Pas certain de m'emmerder à passer de la cire pour corps creux par contre.

Pour le double face j'ai commandé du DPM Tape équivalent au 3M VHB  

 
C'est ce que j'avais mis sur la mini pour fixer les extensions d'ailes. Normalement à fixer aux rivets mais j'avais aucune riveteuse avec une tête assez fine. Avec des écrous à riveter c'était beaucoup plus facile et démontable au besoin.
 
Par contre il faut prendre des inserts de même qualité que la pince. J'avais acheté des bons écrous à sertir inox mais une pince lambda en chinoisium. J'allongeais les inserts sans pouvoir sertir, au final j'ai mis les écrous à sertir en chinoisium fournis avec la pince.

C'est aussi ce genre de rivets qui sert à fixer les aménagements dans les utilitaires, donc ça tient pas mal

Bon , pour avoir vu le projet de Joël de près dernièrement.
Ouais il s’est sorti les doigts .
Ça rends vraiment bien.
 
Je le fais aussi bosser
 
Je sais qu’il a d’autres idées en tête
Après tu peux compter sur moi pour les coups de main .

J'ai avancé sur les ouies de capot. Impression en PET-CF, on commence a voir la limite de la P2S, ça imprime a 300° c'est la limite max. J'avais aussi la possibilité d'aller sur du PAHT-CF, j'ai essayé le PET qui est moins cher, plus résistant mais nécessite un recuit.

Les deux ouies ont été imprimées

Pour la recuisson, le protocole c'est de le faire dans du sable fin sec, donc je suis allé acheter le plus gros plat a poulet rôti que je pouvais trouver, du sable de jeu, et tu commences par le faire sécher au four pendant deux heures a 100°. Puis tu positionne ta pièce dans le sable, il faut impérativement qu'elle soit bien supportée car elle va gondoler et que le sable recouvre bien la pièce (c'est pas le cas ici, c'était pour la photo)

Puis, tu enfourne pendant 5h a 95°, four froid pour que ça monte doucement en température et quand ça s'arrête tu laisses bien refroidir dans le four sans toucher pour ne pas toucher la pièce chaude car elle va se déformer

Et une fois froid tu peux sortir la pièce et la nettoyer

Une des deux pièces a un peu bougé, pas assez bien calée dans le sable. Rien qui ne m'empêchera de la monter. Par contre une fois froid c'est assez remarquable a quel point c'est solide. La recuisson est un peu pénible car ça te limite en taille de pièce a cause de la taille du four et du plat a poulet. Bon bien évidemment j'ai fait ça quand Mme n'était pas la mais en vacances (c'est pour ça que je suis productif ces derniers jours), sinon j'allais me faire défoncer.

Je pense investir fin d'année pour monter en gamme sur l'imprimante, aller probablement sur une H2D ou H2S plus grande et qui permet d'imprimer du filament encore plus technique comme le PPS-Cf

Le poulet du dimanche midi avec Walker Texas Ranger aura peut-être un goût bizarre

Ça me donne beaucoup trop envie d'acheter une Creality K2 Plus ton affaire, alors que j'en ai même pas l'usage  

Des boutons au volant, sans un seul fil
 
Depuis que le dashboard tourne, il me manquait un truc : pouvoir changer de page, poser un repère dans le log ou caler la ligne de départ sans lâcher le volant. Les boutons de la planche, c'est bien à l'arrêt, beaucoup moins en piste
Problème classique : faire passer des fils dans un volant qui tourne, sans contacteur tournant. Du coup j'ai fait sans fil.
 
1. Le principe
Une petite carte ESP32-C3 SuperMini (quelques euros, Bluetooth intégré) se fait passer pour un clavier Bluetooth. Chaque bouton envoie une touche : P pour PAGE, A pour ACTION, F13 et F14 pour les deux autres. Le dashboard savait déjà lire un clavier, donc côté Raspberry aucun pilote à écrire : on appaire une fois, et c'est tout.
Le tout tourne sur une LiPo de 500 mAh, rechargée par un module TP4056 en USB-C. Le niveau de batterie remonte aussi au Raspberry par le Bluetooth.
 
2. La platine
J'ai pris le modèle des platines carbone 4 boutons type MOMO : une plaque plate prise en sandwich entre le volant et le moyeu (perçage 6 × 70 mm), avec des « oreilles » qui viennent derrière les branches et portent les boutons sous les pouces.
Dessinée sous OpenSCAD à partir de photos et de cotes prises sur mon MOMO 3 branches, puis validée par des maquettes imprimées en 3D. Il en a fallu 4 versions : sur les premières, les boutons étaient cachés derrière les branches du volant. Ceux du bas ont fini 25 mm plus bas que prévu.
Petite précision importante : la maquette imprimée ne sert qu'à valider l'ergonomie. Une plaque en plastique ne doit jamais rester serrée dans la fixation du volant : le plastique s'écrase sous le serrage et les vis finissent par se desserrer.
 

 
3. La plaque en carbone
Une fois la forme validée, le dessin sort en gabarit 1:1 (SVG / DXF). Gabarit posé sur le tissu, 9 plis de mat et résine époxy, stratification sous vide, puis détourage au gabarit et perçage.
 



 
4. L'électronique
Tout tient dans un petit boîtier imprimé de 30 mm de large, vissé au dos de la plaque, caché derrière la branche du bas. L'ESP32 et le TP4056 sont au fond, la prise USB-C de charge sort sur le côté. Les fils des boutons passent sous gaine tressée le long des oreilles.
J'ai un peu galéré a tout faire rentrer, mais avec un peu de persuasion, c'est bon
 

 
Le câblage, pour ceux que ça intéresse :

 
Quelques choix pas forcément évidents :
[list]

• Les boutons sont sur GPIO1, 3, 4 et 5 : ce sont les seules broches qui peuvent réveiller l'ESP32-C3 de sa veille profonde
• Un pont de deux résistances de 220 kΩ sur GPIO0 mesure la tension de la batterie, convertie en pourcentage
• Sans liaison pendant 10 minutes (voiture coupée), la carte se met en veille profonde. Un appui sur n'importe quel bouton la réveille et elle se reconnecte en 1 à 2 secondes
• Autonomie estimée : une vingtaine d'heures de roulage avec 500 mAh
• Le boîtier est côté planche de bord : le carbone fait écran aux ondes, il ne faut pas qu'il se trouve entre l'ESP32 et le Raspberry

[/list]
 
5. Le montage
Les vis du volant sont rallongées de l'épaisseur de la plaque, en classe 10.9 et au frein filet. Deux boutons en haut, deux en bas, tous sous les pouces.
 


 
Et en vidéo, les changements de page depuis le volant :
https://youtu.be/Mnzx1LmlSRM
 
6. Les galères (il y en a toujours)
[list]

• Sur le Raspberry, le Bluetooth était carrément désactivé depuis le début du projet (pour gagner du temps au démarrage). Il a fallu le réactiver à plusieurs endroits
• Après un redémarrage du Raspberry, le volant ne se reconnectait plus tant qu'on ne débranchait pas sa batterie. La bibliothèque Bluetooth de l'ESP32 ne se signale plus d'elle-même après une déconnexion. Deux lignes de code plus tard, il se reconnecte tout seul

[/list]
 
7. Côté dashboard
Une petite icône volant avec sa jauge de batterie en bas à gauche du compte-tours : verte, jaune puis rouge sous 20 %, grise quand le volant n'est pas connecté. Un message s'affiche aussi à la connexion, et un rappel toutes les 10 minutes quand la batterie est faible.
 

 
La suite
Valider tout ça en roulant, et donner un rôle aux deux boutons restants. J'hésite encore entre tentative de pilotage de mes caméras ou bien activation des clignotants sur mon pad colight, mais la il va falloir vraiment faire de l'électronique, donc je sais pas encore.
 
J'ai également deux addons en cours de construction pour le dashboard, un accéléromètre pour intégrer les G dans les logs et sur mon logiciel d'analyse et surtout un capteur de pression de freinage, un peu plus compliqué a mettre en oeuvre car je dois dériver les durites de LDF, j'attends tout le matériel pour le faire, suite au prochain épisode.
 
 
 
 
 
 
 
 
 
 
 

 
 
Moi je serais parti sur un cable spiralé pour la liaison

Joel qui est parti dans le metavers.
 
Nous on va continuer à serrer des boulons

Il y a du niveau.  

J'y ai pensé, et j'avais trois options :  
 
Cable spiralé : bon c'est pas top quand meme, ça s'use a force, ca bouge
Bluetooth: fun a fabriquer, ça m 'a permis de tester les ESP32 (et ça m'ouvre plein d'idées), mais ca ajoute un point of failure (la batterie, la connexion)
Utiliser un clockspring : c'est la bonne solution, mais ils sont très difficiles a trouver, et coutent une fortune en occasion, j'en avais et je les ai vendu pour faire du profit....
 
J'ai choisi l'option bluetooth en me disant que les boutons ne sont pas des fonctions essentielles, ils ne marchent pas, j'ai les boutons sur le dashboard. Donc aucun soucis.
 
Mais oui ça me donne plein d'idée et j'ai encore 2 ESP32 et 3 ou 4 arduino nano qui trainent, avec des batteries, des controleurs et des écrans, j'ai plein d'idées....

Si ça peut t'arranger, il existe des MCUs faible consommation avec un périphérique BLE, prévus pour être alimentés directement par une pile. De mémoire, j'avais utilisé le TI CC2540 pour un bouzin dont la pile devait durer plusieurs années.

Accéléromètre et pression de freinage sur le dashboard
 
Le chrono, c'est bien, mais ça dit seulement combien on perd, pas où ni pourquoi. Pour progresser, il me manquait deux données : les G (est-ce que j'exploite vraiment le grip en courbe ?) et la pression de freinage (est-ce que je freine assez fort, assez tôt, et est-ce que je relâche proprement ?).
Les deux sont maintenant affichées sur la page chrono et enregistrées dans les logs, à côté des données de la Speeduino et du GPS.
 
1. Le principe
Deux petits modules sur le Raspberry, branchés en parallèle sur un bus I2C :
 

• un GY-521 (MPU-6050, accéléromètre + gyroscope 3 axes)
• un ADS1115, convertisseur analogique 16 bits, qui lit le capteur de pression

Petite subtilité : le bus I2C habituel du Raspberry (GPIO2 / GPIO3) est déjà pris, GPIO3 me sert à détecter le contact pour l'extinction propre. J'ai donc activé un second bus I2C sur GPIO22 / GPIO23 (broches 15 et 16), tout simplement.
 
2. L'accéléromètre
Le GY-521 est collé sur le tunnel de transmission, derrière le tableau de bord : c'est rigide et proche de l'axe de la voiture. Pas de mousse ni de velcro épais : il mesurerait ses propres vibrations au lieu de celles de la voiture.
Le gros avantage : pas besoin de l'aligner. Le dashboard apprend son orientation tout seul :
 

• la verticale, dès que la voiture reste immobile 2 secondes
• l'axe avant, pendant les premières accélérations franches en ligne droite, en comparant avec la vitesse GPS

 
 
3. Le capteur de pression de freinage
Un capteur inox 0,5–4,5 V de 1600 psi (110 bar), filetage 1/8 NPT.
Où le mettre ? Sur le circuit avant : le répartiteur ne touche pas à la pression avant, donc on mesure exactement ce que produit le maître-cylindre, c'est-à-dire ce que fait le pied droit. Sur la sortie arrière, la pression est réduite par le répartiteur et la mesure serait faussée.
J'ai donc intercalé un T sur une sortie « F » du répartiteur :
 

• une durite de 10 cm entre la sortie F et le T
• la conduite d'origine revissée sur le T
• une durite de 30 cm entre le T et le capteur, via un manchon inox 1/8 NPT et un adaptateur laiton

Le T et le capteur doivent être fixés : rien ne doit pendre au bout des tubes, les vibrations finiraient par fissurer un évasement. Le capteur est placé plus bas que le T : l'air remonte dans le circuit et part à la purge normale au lieu de rester coincé dans le capteur. Il faut aussi le tenir loin du collecteur, ces capteurs n'aiment pas la chaleur. Étanchéité des filets NPT à la pâte compatible liquide de frein, pas de téflon (des morceaux peuvent partir dans le circuit). Les raccords évasés, eux, se serrent à sec.
 

 
4. L'électronique
Le capteur est alimenté en 5 V par le Raspberry, mais l'ADS1115 est en 3,3 V et ne supporte pas plus que sa tension d'alimentation sur ses entrées. D'où deux ponts diviseurs :
 

• le signal du capteur passe par un pont et arrive sur l'entrée A1
• le 5 V qui alimente le capteur passe par un pont identique et arrive sur A2

Le dashboard divise l'un par l'autre. Résultat : la pression mesurée ne dépend plus des variations du 5 V, et le rapport des ponts s'annule. Le zéro se recale tout seul à chaque fois que la pédale est relâchée.
 

 
Le tout est monté sur une plaque à pastilles, avec l'ADS1115 sur ses broches. Le GY-521 peut aussi s'y raccorder, ce qui évite de doubler les fils sur les broches du Raspberry :
 

 
Et en vrai, l'ADS1115 sur sa plaque avec les deux ponts, résistances montées debout :

 
5. Côté dashboard
Sur la page chrono, une ligne entre le temps du tour et les meilleurs temps : la barre FREIN avec la pression en bar, le G-mètre et l'accélération totale. Le point du G-mètre suit la sensation du pilote : il monte au freinage et part vers l'extérieur du virage.
 


(captures en mode démo, sur un tour de Pouilly rejoué depuis un log)
 
Les trois voies (pression de freinage, G longitudinal, G latéral) sont aussi enregistrées dans les logs .msl, lisibles dans MegaLogViewer avec le reste.
 
Et le premier essai dans la voiture, pédale enfoncée : 42 bar, et l'accéléromètre qui attend de rouler pour apprendre son axe avant (CAL 0 %) :
 

 
6. Les galères (il y en a toujours)
 

• En déballant les raccords, il manquait une pièce : avec un seul tube, impossible de relier le T à la fois au répartiteur et au capteur. Heureusement, j'ai retrouvé une durite de 30 cm dans mes fonds de tiroir,l'avantage de toujours acheter les pièces en double
• Vraiment, j'étais pas serein de toucher a la ligne de freins, ben j'avais raison, j'y ai passé presque une journée complète, le positionnement était pas correct, ça fuyais de partout dès qu'on appuyais sur la pédale, le tout a du être serré d'abord sur l'établi, puis installé avec les durites cuivre qui sont relativement flexibles, c'est pour ça qu'elles sont pas méga droites, ça a été formé dans la voiture, pas en dehors, le seul moyen d'avoir une bonne étanchéité.

 
La suite
Pouilly, WE prochain, je vais pouvoir tout essayer sur piste, pour l'instant la météo est très favorable, j'espère que ça va se tenir.

Nouveau projet : SpeedGauge, un manomètre digital maison (Speeduino, MegaSquirt, OBD2, CAN)
 
Après le dashboard et le volant, il me restait des composants sur l'établi : quelques cartes ESP32-C3, un Raspberry Pi 3, deux ou trois écrans... Plutôt que de les laisser prendre la poussière, je me suis lancé dans un nouveau projet : un manomètre digital rond de 52 mm, qui se loge dans un support de jauge classique et qui affiche ce que l'on veut, directement depuis le calculateur.
Et comme d'habitude, ça a un peu dérapé Au départ c'était « juste un mano », à l'arrivée c'est une vraie petite carte électronique, un simulateur de calculateur, des tests sur une vraie voiture et une campagne de tests d'endurance.  
 
Ça va être long, désolé
 
1. L'idée
Les manos digitaux du commerce compatibles ECU programmable, c'est soit très cher, soit limité à un seul calculateur. L'objectif : un écran simple, joli, qui se branche sur à peu près tout, et qui reste sous les 100 €. Si le résultat tient la route, l'idée est d'en faire une petite série pour les copains et pour ceux que ça intéresse.
 
Ce qu'il fait :

• Écran rond IPS de 1,28" (240 × 240), style racing inspiré de Haltech (fond noir, jaune et rouge), comme sur le dashboard
• Pages configurables : une grosse valeur, deux, quatre, ou une page diagnostic
• Une shift light sur tout le tour de l'écran : jaune, orange, rouge, puis tout clignote au régime de passage
• Alertes : l'écran bascule tout seul sur la valeur en défaut (eau trop chaude, AFR trop pauvre, pression d'huile...) et clignote en rouge jusqu'à ce qu'on l'acquitte
• Un bouton en façade, plus une entrée pour un bouton déporté (au volant par exemple)
• Tous les seuils, échelles et pages se règlent depuis un petit configurateur sur PC : on branche la jauge en USB, on ouvre la page dans Chrome, et c'est tout. Le même outil fait les mises à jour du logiciel

Les différentes pages, en vrai (ce sont des captures de l'écran récupérées directement par l'USB, mises dans une lunette pour faire joli) :

 
La shift light en action, quand le régime monte :

 
Et l'alerte, quand l'eau dépasse le seuil, impossible de la rater :

 
2. Compatible avec quoi ?
C'est là que le projet a pris de l'ampleur :
 

• Speeduino par le port série, évidemment (c'était le point de départ)
• MegaSquirt : MS1, MS2 / MS3 en série, et MS3 en CAN
• OBD2 sur n'importe quelle voiture récente, soit en filaire sur le CAN, soit sans fil avec un dongle Bluetooth BLE (j'ai un OBDLink CX)
• Et en CAN, les diffusions des calculateurs du commerce : Haltech, Link, ECUMaster et MaxxECU

Côté électronique, la carte accepte du série TTL (5 V ou 3,3 V), du RS232 et du CAN, avec une alimentation 12 V protégée (inversion de polarité, surtensions, fusible).
 
3. Le premier proto
Premier jet sur une plaque d'essai avec une carte ESP32-C3 SuperMini (la même que dans le volant) et un petit module d'écran rond. C'est moche, il y a des fils partout, mais ça permet de tout valider avant de dessiner la carte.
 

(La page diagnostic des premiers essais en OBD2 : là, ça ne marchait pas encore, « SYNC LOST » et 29 erreurs )
 
4. Le simulateur de calculateur
Pour tester une jauge compatible avec dix calculateurs différents, il faudrait... dix calculateurs différents. Pas vraiment dans le budget
Du coup j'ai recyclé le Raspberry Pi 3 et l'écran 7" de mes fonds de tiroir en simulateur de calculateur. Il se fait passer au choix pour une Speeduino, une MegaSquirt, une voiture en OBD2 (filaire ou en se faisant passer pour un dongle OBDLink en Bluetooth), une Haltech, une Link, une ECUMaster ou une MaxxECU.
Il rejoue mes vrais logs de roulage (Pouilly !), on peut forcer n'importe quelle valeur depuis une page web, et surtout il sait simuler des pannes : calculateur muet, trames coupées ou corrompues, valeurs aberrantes, bus saturé... Le but : vérifier que la jauge ne se plante jamais et n'affiche jamais n'importe quoi.
 

(Le banc : le Pi et son écran en haut, le proto en bas, relié en Bluetooth au faux dongle. À droite, les premières pièces imprimées du boîtier.)
 
5. La carte électronique
Une fois le proto validé, j'ai dessiné une vraie carte sous KiCad : un PCB rond de 48 mm, en composants CMS, assemblé directement chez JLCPCB. C'est mon premier PCB de ce niveau, et franchement le résultat est bluffant.

• Un module ESP32-C3 (Bluetooth intégré), antenne en bordure de carte
• Un convertisseur 12 V → 3,3 V automobile (supporte jusqu'à 40 V en continu), avec ses protections
• Un transceiver CAN, un convertisseur RS232 qui s'active par cavalier, et la terminaison CAN de 120 Ω sur pont à souder
• Une prise USB-C pour la configuration et les mises à jour
• Un bornier débrochable 8 voies : +12 V, masse, éclairage, bouton déporté, RX, TX, CANH, CANL
• L'écran se monte de l'autre côté, avec le bouton

Le boîtier est en PETG imprimé sur la Bambu, une lunette fine et une bride en U pour le support de jauge.
 

 
La commande est partie : 5 cartes, dont 2 assemblées pour valider avant de lancer la petite série. En attendant, le logiciel tourne déjà sur le proto, prêt pour la vraie carte.
 
6. Premier essai sur une vraie voiture : la 206+
Le simulateur c'est bien, mais rien ne vaut une vraie voiture. Premier cobaye : la 206+ de 2011, avec l'OBDLink CX branché sur la prise OBD et le proto posé sur le siège passager.
Et première surprise : la 206+ ne cause pas en CAN comme je le pensais, mais en KWP2000 sur la ligne K, un protocole bien plus ancien et beaucoup plus lent. Petite séance de mise à jour dans la voiture, et c'est reparti : environ 10 mesures par seconde, avec des valeurs cohérentes avec le combiné. Pour un protocole des années 2000, ça le fait
 

 
Du coup, la jauge sait maintenant parler les 9 protocoles OBD2 existants (CAN 11 et 29 bits à 250 ou 500 k, KWP2000, ISO 9141, et les deux J1850 des américaines).
 
Et en vidéo :
https://youtube.com/shorts/llYqu6HG0QA
 
 
7. Les tests d'endurance (les « burndown tests »)
Avant de proposer ça à qui que ce soit, je voulais être sûr que ça tient. Donc on a laissé tourner le banc pendant des heures, sans intervention :
 

• 42 voitures simulées en OBD2 : Peugeot, Renault, VW, BMW, Mercedes, Ford, Toyota, Mini, Volvo hybride, électriques... Chacune avec ses petites manies : calculateur diesel lent qui répond « patientez », papillon refusé chez BMW, bus CAN chargé, protocoles anciens, etc. Testées en Bluetooth, et 26 d'entre elles aussi en CAN filaire
• 11 configurations passées une par une : Speeduino, MegaSquirt (3 variantes), OBD2 filaire et Bluetooth, Haltech, Link (2 formats), ECUMaster, MaxxECU
• Pour chacune : démarrage, exactitude des valeurs moteur froid, chaud et en conditions normales, 4 minutes de relecture de log, puis 5 types de pannes injectées

Résultat de la première campagne de 1 h 35 : 175 tests sur 175 conformes. Aucun plantage, aucun redémarrage, pas de fuite mémoire, et la jauge retrouve ses valeurs en moins de 2 secondes après chaque panne. La première valeur s'affiche entre 6 et 16 secondes en Bluetooth (le temps de se connecter au dongle), et presque instantanément en filaire.
 
Et pour ceux qui aiment les chiffres, en mesures par seconde : 166 en OBD2 filaire, 48 en Haltech et MaxxECU, 25 en Speeduino. Largement assez pour un mano
 
Les tests ont aussi servi à trouver de vrais bugs, que l'on n'aurait jamais vus sans le banc : un filtre CAN qui bloquait la MegaSquirt sur la vraie carte, ou les diesels lents dont la réponse « patientez » était prise pour un refus.
 
8. Les galères
 

• Le Wi-Fi de la petite carte SuperMini était quasi invisible à pleine puissance. Au final j'ai carrément retiré le Wi-Fi, au profit de la configuration en USB : plus simple, et plus de mémoire pour le Bluetooth
• Le dessin des arcs de cercle prenait 200 ms par image : une jauge qui rame, ça ne pardonne pas. Réécrit autrement, l'affichage d'une image prend maintenant 9 ms
• Écrire sur l'USB quand aucun logiciel n'écoute côté PC figeait complètement le processeur... Bien vicieux à trouver, celui-là
• Les cheap ELM327 Bluetooth à 10 € ne marchent pas : ils sont en Bluetooth « classique », l'ESP32-C3 ne parle que le BLE. Il faut un dongle BLE, comme l'OBDLink CX
• L'OBDLink CX n'accepte un nouvel appairage que pendant les 5 minutes qui suivent son branchement. On s'en est rendu compte après un moment à se demander pourquoi plus rien ne se connectait

 
9. Et la suite : une V2 « premium »
La V1 est pensée rapport qualité / prix. Mais tant qu'à faire, je réfléchit déjà à une V2 plus haut de gamme :
 

• Un boîtier de 60 mm, avec un écran rond bien plus grand et plus fin : 1,85" en 360 × 360, voire de l'AMOLED en 466 × 466
• Un processeur plus costaud (ESP32-S3)
• Et surtout un enregistrement des logs sur carte micro SD, au format MegaLogViewer, que l'on récupère en branchant simplement la jauge en USB sur le PC

Le module 1,85" est commandé pour faire les premiers essais.
 
En attendant
Prochaines étapes : recevoir les cartes, les valider, puis essayer sur la Mini R53, la Volvo V60 T8 et la barquette. Si certains roulent en Haltech, Link, ECUMaster ou MaxxECU et veulent jouer les cobayes, ça m'intéresse beaucoup : c'est la seule partie que je n'ai pas pu tester en vrai
Et si vous êtes intéressés par une jauge, dites-le-moi, ça m'aidera à dimensionner la série (je suis parti sur une première série de 30 PCB, c'est la limite qui me permettrait d'avoir un prix sous les 90 euros je pense)

Ah c’est marrant je suis en train de faire a peu près le même style de jauge avec un écran similaire.
Merci pour les updates !
Pas forcément hyper fan du mega pavé Claude (même si je comprends que ça fait gagner du temps)

Merci pour le feedback, j'apprécie.
 
En effet, ça me permettait de dicter plutot que taper, mon cerveau va probablement un peu plus vite que mes doigts, ça faisait la mise en page, mais comme je parle beaucoup, ça fait en effet un peu trop diarhée verbale. Meme si je relisais et corrigeait ça fait un peu trop pavé, j'avoue, je vais changer ça donc.

La conception des speedjauge avance bien, j'ai reçu un LCD proto en en 1,85" qui ne sera pas la V2 premium mais sur base de la carte V1 juste avec un écran plus grand. Je voulais tester que cet écran soit compatible avec l'ESP32 C3 de la carte car la mémoire reste limitée et je voulais vérifier que l'affichage est toujours fluide, c'est le cas, meme si ça a demandé pas mal de boulot. Par contre la taille plus importante est vraiment cool
 

 
Et surtout, j'ai reçu les deux premiers PCB assemblé et les 3 PCB nus, je suis super content de la qualité c'est vraiment top, les deux cartes ont été testés sur le bench sans écran pour l'instant, ça fonctionne sans soucis (lecture en mode debug via l'USB)
 

 
L'insertion et l'assemblage de l'écran nu dans le boitier semble aussi parfaite, bref, il ne me reste plus qu'a souder.
 

 
Je vais essayer d'assembler une première jauge demain, Dimanche je vais a Pouilly, et si ça peut etre l'opportunité pour montrer le produit et le faire tester a quelques copains dans leurs voitures en OBD2, ça serait pas mal déjà

Qui c'est qui vient de découvrir sur piste qu'il avait oublié de mettre un limiteur de régime dans sa carto ?    
 
Bon ben un moteur de VVT peut encaisser 7 947 trs/min, combien de fois je sais pas.
 
Merci Claude, alors qu'il venait de me résoudre mon problème de coupure d'injection en plein charge (j'en parlerai plsu en détail dans mon CR) de me dire "Au fait, j'ai aussi regardé dans les logs, t'as tapé 7 947 trs/min et je vois pas de hardcut dans ta carto, va peut etre falloir y penser   "
 
Ca fait deux ans que je roule sans limiteur de régime  

T’as pas besoin de limiteur de régime
 
C’est pas mal avec l’écran plus grand ! Si seulement ils pouvaient en sortir des OLED ou en lcd transflectif… pour ce genre de projet ce serait idéal

C'est pas la poulie VVT qui me ferait peur, mais les poussoirs hydrauliques.

A tous hasard Claude gère pas les fichiers bin de carto d'origine   ?  
Je / on pédale pour mon Sirius 34 , pas de fichier tunerpro sinon ça serait trop facile

Les Llm de nature sont efficaces sur ce qui est textuel, et documenté a un endroit. Donc c'est pour ça que ça excelle sur le code, et que ça marche aussi super bien sur tuner studio/megasquirt/speeduino. Les cartos sont globalement en fichier texte, les logs c'est grosso modo du csv et c'est ouvert et documenté et ils ont meme accès au code source. Donc idéal.

Donc des ecu d'origine, en binaire, non documenté et dans un milieu qui partage pas grand chose (le monde de la reprog d'écu oem). J'ai des doutes mais je veux bien essayer

Oui trouver un fichier adx est une misère  
Winols / ecm titanium des version hors d'âge incomplète  
Je t'envoie ça par mp    
Si ça te coûte rien hein , ni temps ni argent pour mes bêtises

Le transflectif, j'en suis un grand fan pour montre, mais pour un truc aussi réactif ne serait pas trop lent ?

À priori ça dépend pas mal des écrans, mais clairement ce ne sont pas les plus réactifs  
https://youtu.be/MziW1InJwa4?si=Kkx [...] wbG7&t=391

Regardes dans ta boite mail, tu vas avoir une bonne surprise  

Oh oui   merci  
 
Confirmé par le mappeur   c'est les bonnes tables  
 
La c'était un exemple "parfait" avec un fichier xdf déjà créé  
Et rien n'est créer , aucune table sur la gestion papillon électronique par exemple  
Forcément c'était pas présent sur la clio 172 d'exemple    
 
Mais les possibilités   c'est ouf sur une gestion d'origine

C'est pas tout a fait ça, le xdf que tu m'avais fourni était en effet décalé :  
 
Clio RS. Ton XDF « Clio RS Sirius 34 » correspond en fait à ce calculateur : la calibration commence à 0x70000 dans le dump de 512 Ko, et les adresses du XDF tombent juste en ajoutant 0x70000. J’ai aussi corrigé deux erreurs du XDF d’origine :
 
Limiteurs de régime : ce sont trois valeurs de 16 bits à 0x7477A, 0x7477C et 0x7477E, soit 6700, 7400 et 7400 tr/min.
Table VVT : elle commence à 0x73BFA. Elle était décalée de 3 octets.
 
Pour la Megane il l'a recréé :
 
Mégane. C’est un logiciel différent, donc la calibration est décalée par zones. J’ai retrouvé chaque table en suivant dans le code les instructions qui chargent son adresse, puis en comparant les données avec celles de la Clio :
 
Table Clio RS Mégane
Avance 1 à 4 0x7144D / 0x71501 / 0x715B5 / 0x71669 0x71447 / 0x714FB / 0x715AF / 0x71663
Injection 1 à 4 0x7190E / 0x719C2 / 0x71A76 / 0x71B2A 0x71866 / 0x7191A / 0x719CE / 0x71A82
Charge partielle 0x728D9 0x727F1
VVT 0x73BFA 0x73A51
Axe régime 0x743F6 (730 à 7500) 0x74396 (700 à 6000)
Axe pression 0x71DA8 0x71CC0
Limiteurs 6700 / 7400 / 7400 6500 / 6500 / 6500
 
Les tables 95 et 98 RON de la Mégane sont presque identiques, ce qui reste plausible pour ce moteur. Je n’ai pas repris dans l’XDF Mégane trois tables non identifiées de la Clio, faute d’avoir pu les retrouver de façon fiable.
 
Donc il t'a recréé les bons fichiers xdf

   merci pour l'explication au complète
J'avais chercher l'offset via des logiciel sans le trouver en comparant manuellement les fichiers  
Tu va pouvoir vendre les xdf aux jeunes bolideurs de clio    
 
Dans le sens créer , je parlais from scratch ( même si ça serait un bon exercice de refaire la même chose sans le xdf de départ pour voir si c'est aussi abouti )  
Quoi que si t'a du temps je peux te fournir celui du f5r  

Vasy, je le ferai peut etre que ce we par contre, histoire d'épuiser mes tokens (ça se reset le dimanche)
 
mais tu m'a donné des idées, je vais tenter un dump de la carto de ma mini cooper S  

La caisse roule pas donc c'est pas urgent , essaie la mini et dis nous    
 
Plus qu'à convaincre ManX de faire une bi carto e85 avec un kkl pour injecter a la volé  

 
À 40 balles le calculo Sirius 34 sur Ovoko, ça serait sympa à tester .

T'a même des projets depuis Android avec le câble kkl pour flash par odb