CarLog — Télémétrie embarquée sur Honda Civic
Tout a commencé avec une Honda Civic EJ9 phase 1.5 et une obsession : comprendre ce qui se passe sous le capot quand on passe à l’éthanol. Cette génération n’avait pas de prise OBD standard. Pour y accéder, j’ai découvert HonDash, une application développée par un Slovaque, avec un dongle dédié. J’ai appris sur le tas le fonctionnement de l’injection, des capteurs, de l’allumage piloté. Pas dans un cours. En lisant des forums, en testant, en comparant des valeurs en temps réel. C’était de l’autodidaxie pure, et j’ai adoré ça.
Quand je suis passé à ma deuxième Civic, une EJ9 phase 2 avec prise OBD standard, j’ai migré vers TorquePro, l’application que j’utilisais déjà sur ma Mini JCW. Sauf que sur cette Honda, quelque chose clochait. Le calibrage de la consommation était impossible à stabiliser. J’ai fini par identifier deux causes : la lenteur inhérente du bus K-Line et la mauvaise gestion des requêtes PID par TorquePro, qui créait des décalages et des approximations en cascade.
C’est en repensant à HonDash et à sa logique propre et dédiée que l’idée a germé : pourquoi ne pas construire mon propre système, avec mon propre ordonnanceur, calé exactement sur mes besoins ?
Hardware embarqué
- ESP32 avec firmware C++ — acquisition capteurs et réseau
- BME280 — météo globale (température, pression, humidité)
- DS18B20 (x2) — température moteur et admission snorkel
- GPS 10 Hz — précision distance, vitesse et consommation
- Klavkarr (ELM327) — données OBD bus K-Line
Stack logicielle
- Firmware C++ ESP32 — réseau UDP broadcast, synchronisation temporelle
- Application Android Kotlin — dashboard temps réel, double flux OBD + ESP32
- Table VE dynamique chargée depuis CSV — calibration sans recompilation
- Python Pandas/NumPy — post-traitement et analyse des logs
- Profils véhicule — A/B testing par modification mécanique
- Fréquence de log : de 1,8 seconde (TorquePro) à 800 ms avec l’ordonnanceur maison
- Écart de consommation mesuré : 0,56 litre sur environ 1 000 km de logs, malgré deux valeurs approximatives
- Calibration VE pondérée par zones réelles d’utilisation (75% du temps entre 1 250 et 2 000 tr/min)
- Multi-flux Klavkarr + ESP32 fonctionnel en tests
- GPS 10 Hz intégré pour la précision des calculs de distance et vitesse réelle
Problème : Le taux d’éthanol varie selon les achats et la saison. Sans capteur dédié, impossible d’avoir une référence fiable.
Résolution : Test de séparation à l’eau pour mesurer le taux réel, saisi manuellement dans l’application. En attente du montage d’un capteur Continental de qualité automobile pour automatiser cette mesure.
Problème : L’erreur de calibration n’est jamais linéaire. Une correction globale lissait les écarts sans les résoudre.
Résolution : Analyse des logs RPM : le moteur passe 75% de son temps entre 1 250 et 2 000 tr/min. Correction pondérée sur cette zone de croisière uniquement, sans toucher au pic de puissance à 4 750 tr/min. Objectif : rester sous les 2% d’écart.
Problème : Les capteurs sont à 3-5 mètres de l’ESP32. Le protocole I2C natif est limité à 50 cm à cause de la capacité parasite des câbles.
Résolution : Architecture inspirée du sport automobile — puces PCA9615 aux extrémités du faisceau pour transformer l’I2C fragile en signal différentiel résistant aux interférences de l’allumage et de l’alternateur. Multiplexeurs TCA9548A pour distribuer le signal localement à moins de 50 cm de chaque capteur.
Problème : Désalignement des logs à cause de la latence variable des connexions sans fil entre l’ESP32 et l’Android.
Résolution : Système de handshake logiciel au démarrage de l’application Android. L’ESP32 synchronise son horloge interne sur le timestamp Unix 64 bits du smartphone et date précisément chaque trame de données depuis ce point de référence commun.
Court terme
- Capteur de position de vitesse enclenchée — vitesse réelle via rapport x RPM, sans consommer un PID OBD
- Capteur d’éthanol Continental — mesure automatique du taux E85, fin du test manuel
- Objectif fréquence de log : 1,3 seconde avec les deux capteurs montés
Long terme
- Fréquence cible 5 Hz — entre 3 et 4 millions de lignes de logs par an sur 15 000 km
- Capteurs additionnels : pression carburant, température carburant, pression et température huile
- Abandon de l’ELM pour connexion directe sur le bus via piggy-back entre ECU et faisceau
- Linux embarqué, SBC type NXP i.MX8, interface Qt/Rust, CAN bus filaire, écran tactile industriel
Chaque modification mécanique est enregistrée comme un profil distinct dans l’application : filtre à air, carburant, réglage de l’avance, modification du circuit d’admission. Chaque changement crée un nouveau mode. Le dashboard Python permettra de comparer objectivement les profils entre eux — mesurer si une modification a eu un impact réel sur la consommation, le régime de croisière ou la courbe de VE. De l’A/B testing sur données réelles, appliqué à la mécanique.
C’est le seul projet où j’ai eu besoin de comprendre la thermodynamique, le câblage automobile, le développement Android, le firmware C++ et l’analyse Python pour que ça fonctionne. Chaque couche nourrit les autres. Et contrairement aux datasets fictifs des projets OC, ici les données sont réelles, le moteur tourne, et les erreurs se paient en litres d’essence ou en calculs faux.