Diagnostique Klavkarr 210 pour Defender TD5

[Lud_Def_110]

Bonjour à tous,

J'ai acheté le Klavkarr 210
J'ai un Def 110 TD5 de 2004
C'est censé être compatible..
Il coûte 140€

J'ai un diagnostique dont je mets le résultat dessous.
Mais le reste des fonctionnalités n'est pas accessible.

----------
Land Rover - Engine 11 fault(s) 8 Nov 2024 13:51:43 (Land Rover)

Trouble Code(s)
0304
Land Rover: Driver Demand 1 Logged Low
0407
Land Rover: Ambient Pressure Circuit Fault Logged Low
0506
Land Rover: Air flow circuit (Confirmed)
0600
Land Rover: Inlet air temperaturecircuit (Confirmed)
0602
Land Rover: Coolant temperature circuit (Confirmed)
1200
Land Rover: Air conditioning fan drive open load (Confirmed)
1202
Land Rover: Tachometer open load (Confirmed)
1206
Land Rover: Glow plug relay drive open load (Confirmed)
1207
Land Rover: Glow plug relay drive open load (Confirmed)
1A07
No description available for this trouble code
1C05
No description available for this trouble code

Last Trouble Code(s)
P0000
No trouble code

Permanent Trouble Code(s)
P0000
No trouble code

[The Pater]

J'ai un diagnostique dont je mets le résultat dessous.
Mais le reste des fonctionnalités n'est pas accessible.

S'il se connecte et lit les codes défauts, il doit pouvoir lire les indications des capteurs en temps réel.

Ta deuxième image indique que KlavKarr ne peut pas se connecter, mais tu donnes une liste de code défaut du diagnostique moteur, juste avant. Etrange.

A+

[Normand 1400]

Même remarque que Pater : si le rapport de diag sort, c'est que l'interface parvient — même partiellement — à dialoguer avec le calculateur moteur. Et donc que la prise OBD peut se brancher sur le 4x4.

C'est déjà ça.

Première chose : tu peux choisir le français comme langue par défaut, ça facilitera les choses pour nos lecteurs...

J'ai de temps en temps la même réaction que ta première copie d'écran : je n'ai pas d'explication démontrée au phénomène, mais il se pourrait que l'initialisation de la transmission des données ne soit pas totalement synchro avec celle de l'outil. Du coup, l'initialisation n'aboutit pas et débouche sur le message d'erreur.

Je m'en sors en remettant le contact, puis en débranchant/rebranchant le câble USB et en relançant la connexion avec l'ECU. A cet égard, le premier écran qui passe te donne un déroulé complet de la procédure de communication avec l'ECU : tu vois ainsi apparaître diverses références informatiques ainsi que les débits théoriques en Bauds.

Ensuite, pour un même véhicule, l'outil permet d'attaquer plusieurs bases de données, généralement deux. La première est une base générique (codes et terminologies issus de la norme « OBD ») et l'autre une base « Constructeur ». Ces bases ne contiennent pas nécessairement les mêmes infos et il peut être utile de jongler avec les deux pour affiner certains diagnostics.

Dans la mesure où les défauts confirmés (un défaut confirmé est un défaut qui persiste suffisamment longtemps pour avoir été inscrit dans les registres de l'ECU) portent la mention Land Rover, il y a fort à parier que la base sous-jacente soit la seconde (base spécifiquement Land Rover). Ce qui semble logique puisque, comme indiqué précédemment, je ne suis pas certain qu'à cette époque, l'ECU du Td5 était réellement sous protocole OBD.

Lors de l'initialisation, le logiciel te propose de sélectionner une des bases ; tu dois donc avoir vu passer un onglet en ce sens.

Relance donc la procédure d'initialisation : logiquement elle doit aboutir. Si oui, enchaîne directement sur le menu « Mesures » : c'est lui qui te permettra de lire les valeurs prises par tous les capteurs dont les données remontent et, éventuellement, de les mettre sous forme graphique.

Note que si le protocole de communication entre le µ-contrôleur de l'outil et celui de l'ECU ne fonctionne qu'en partie, il se peut que les variables temps réel ne soient pas accessibles. En d'autres termes, le KlavKarr ne peut peut-être lire que les registres contenant les défauts, pas les flux de données traités par l'ECU en temps réel.

Lorsque, sur le Forum, on s'est attelés à la question de l'ABS du même Td5, on s'est rendu compte que la lecture des flux temps réels de l'ECU d'ABS ne passait pas, même avec le Nanocom, au delà d'une certaine vitesse du véhicule.

Question de puissance de calcul et du nombre de tâches exécutables en simultané par l'outil de diag.

Pour en revenir au KlavKarr, dans le cadre d'un usage de base (listage des DTC), ça peut suffire ; par contre, pour un usage plus fin, ce sera insuffisant.

C'est tout l’enjeu de ce type d'outil, sans parler de la gestion des procédures de calibrage de certains actuateurs ou capteurs (plus communément appelée « apprentissage ») qui exige de pouvoir commander en direct certains organes via le calculateur puis d'écrire les valeurs mesurées par le ou les capteurs dans ses registres (calibration d'une vanne papillon, par exemple, qu'il faudra fermer entièrement puis ouvrir entièrement tout en notant dans les registres de l'ECU les valeurs successivement renvoyées par ses capteurs de position lors des mises en butée mini/maxi).

Ces manips se font via des requêtes pré-paramétrées, sachant que l'on doit pouvoir rédiger des lignes de code à la demande via le menu « Terminal » de l'outil (à la condition de maîtriser le sujet car sinon on peut planter l'ECU... ). Même principe, donc, que pour les µ-contrôleurs Arduino ou PIC (je crois d'ailleurs que le KlavKarr fait appel à un PIC puisque, comme toutes les valises, il tourne dans l'univers logiciel ELM 327).

C'est donc le nœud du problème et c'est là où j'ai eu, comme par hasard, toutes les peines du monde à obtenir les infos claires de la part des constructeurs de « valises ».

Enfin, si un possesseur de Nanocom passe par là, il serait intéressant de voir si les données constructeurs retranscrites par l'outil (au hasard les codes Land Rover suivants :

• Air flow circuit (Confirmed) 0600 ;

• Land Rover: Inlet air temperaturecircuit (Confirmed) 0602)

lui disent quelque chose.

[Lud_Def_110]

Merci pour vos réponses !!
Normand je suis connecté en bluetooth avec Android app. L'initialisation de fait comme tu le décris.
En effet, c'est cette utilisation plus fine que j'aimerais avoir.. lecture des capteurs en temps réel.
J'ai aussi cherché sur internet la liste des codes, mais elle ne semble pas exister..
Je vais essayer de redémarrer etc pour voir si ça change.
Le support ne répond pas pour le moment.
À suivre !

[Lud_Def_110]

Hello!
Alors j'ai fait d'autres tests et j'ai réussi à voir les valeurs en temps réel. Il n'y en a pas bcp mais je vous mets le résultat.

Il y a aussi les graphs où on peut comparer les valeurs ci-dessus en temps réel.
Voici un exemple avec le nombre de tours par minute (rpm) et le turbo

Je pensais avoir la conso en temps réel, le débit d'air pour voir si le capteur MAF fonctionne mais visiblement pas dispo..

Qu'est ce qui fait que le nanocom est plus performant ??
A+

[Normand 1400]

Bon, on avance...

Tout d'abord, pour mieux te rendre compte, tu peux, grâce à l'excellent travail de recherche de disco2magoliv , prendre connaissance des fonctionnalités du Nanocom.

Ici...

Ensuite, il semblerait qu'on puisse déjà conclure sur les points suivants pour le KK :

• la connectivité tourne ;

• la lecture se fait en statique (récupération de fichiers dans les mémoires de l'ECU) comme en dynamique (tu récupères des graphes temps réel).

Je trouve que ça a plutôt bonne gueule à ce stade.

Pour le reste, il te faut encore farfouiller dans les arcanes du KK.

Quel que soit le système d'exploitation faisant tourner le logiciel (Androïd, Windows...) tu as nécessairement la liste des variables que le logiciel et l'ECU partagent. Liste qui ressemble à ça :

Sur la Clio, la liste fait 4 pages pour la base OBD et 6 pages pour la base constructeur. Y de quoi faire, mais c'est un moteur Euro 6, donc y a du monde!

Informatiquement, cette planche constitue ce que l'on appelle une génération d'état. En clair, c'est le résultat d'une requête balancée dans la base de données dont je parlais hier : il en sort ce que contient la fameuse base pour le véhicule concerné, le calculateur qui l'équipe et, in fine, tout ce qui peut passer par l'interface homme machine (le logiciel proposé par KK).

La première colonne (PID) constitue l'identifiant du sous-programme qui va s'exécuter, soit pour lire et transférer les données figurant dans les registres de l'ECU, soit pour lire les registres en séquentiel, soit pour capter le flux de données si on opère en temps réel.

Les suivantes concernent la description des variables, les grandeurs correspondantes et les unités dans lesquelles elles sont exprimées.

Pour être complet dans ma description, je précise que j'ai lancé une lecture séquentielle de l’ensemble des paramètres contenus dans la base afin d'en archiver le contenu à cet instant. En d'autres termes, le logiciel a balayé l'un après l'autre les variables qu'il connaît et en a retourné la valeur, que j'ai consignée dans un coin et dont je me sers aujourd'hui comme illustration du propos.

La manip ayant été exécutée avec le contact mis (moteur non tournant) une bonne partie des variables sont à zéro.

J'accorde de l'importance à cette étape, car l'intérêt des variables constructeur est notamment de suivre, en grandeur et en signe, les corrections apportées par le calculateur à la commande d'organes sensibles, par exemple les variations d'ouverture du papillon des gaz et les corrections injecteurs (c'est un moteur essence) et qui sont consignées dans des registres dédiés tenus à jour en permanence par l'ECU.

On peut donc, à partir d'un point 0 valant situation de référence, suivre l'historique des corrections, donc leurs dérives éventuelles et intervenir bien avant l’apparition d'un code défaut — en nettoyant la vanne papillon, par exemple.

Pour en revenir à nos moutons, que tu sois en lecture des mémoires de l'ECU, en balayage séquentiel des variables ou encore en lecture de flux, si la ligne correspondant à ce sous-programme ne figure pas dans la base, tu n'obtiendras évidemment rien (au mieux un message du genre « non supporté »).

La première des choses à faire est donc de trouver l'intégrale de cette génération d'état et de la comparer à la liste du Nano.

Formulé autrement, on a une variable par capteur et très souvent au moins une par actuateur. Si tu connais ton moteur sur le bout des doigts, tu pourras alors reconstituer ce que devrait être le contenu de la base de données, plus précisément la description ainsi que « l'unité d’œuvre » des paramètres suivis par l'électronique.

C'est là où le sujet, par le couplage mécanique/informatique qu'il oblige à établir, est intéressant!

Pour la petite histoire, je vais incessamment sous peu interroger l'équipe KK, car j'ai plus de variables informatiques que de composants physiques, notamment de capteurs. Et en plus, leur résultats ne concordent pas (sinon, je ne m'en serais jamais préoccupé)!

Bref, je trouve que toute cette cuisine est bien compliquée pour ce qu'elle représente réellement.

Et concernant ta question, je sais que l'équipe de KK est assez volontaire pour compléter sa base de données (vu le nombre de modèles de bagnoles — et autant de calculateurs possibles pour la même bagnole — ça doit même constituer une part majeure de leur boulot) ce qui, en d'autres termes, pourrait signifier que s'il manque des lignes dans la base, il est certainement possible de les ajouter.

Faudra-t-il simplement rajouter une ligne dans la base ou alors aussi gratter le sous-programme nécessaire à la récupération des données manquantes puis l'ajouter à la bibliothèque de programmes du logiciel — surtout qu'on n'est peut-être pas dans du protocole OBD pur et dur — je n'en sais rien pour l'instant.

S'il y a du boulot — je parle de lignes de code à pisser — on peut s'attendre à ce qu'il coincent. Dans le cas contraire, c'est un éclat de rire.

C'est aussi l'intérêt de ce sujet...

Quoi qu'il en soit, cela nécessite d'être carré sur l'inventaire relatif aux forces en présence afin de cibler la demande auprès des concepteurs de l'outil.

Tiens-nous au jus!

[Lud_Def_110]

Hello Normand,

La copie d'écran s'appelle "complète list" donc je suppose que c'est la liste complète des indicateurs.
La fonction "custom list" n'en fournit pas plus..
Donc je vais les contacter pour voir s'ils peuvent en rajouter. Si le Klavkarr peut répondre aux besoins de la communauté Def, il y a un marché à saisir et donc potentiellement un investissement qui peut valoir le coup

[Lud_Def_110]

Je les ai contactés.
Ils confirment que 7 indicateurs ce n'est pas beaucoup. Un de leur développeur va regarder... Mais ça met du temps ....

[Normand 1400]

Ça confirme ce que je pensais.

Je ne suis pas sûr que le parc de Td5 constitue un enjeu économique de taille, mais c'est eux qui voient, comme on dit...