200 20v - K-Line Schnittstelle auslesen

[Martin_78]

Hi,

ich bau gerade ein Diagnosegerät mit Arduino. Fehlerspeicher und Stellglieddiagnose ist easy, kein Problem. Aber jetzt wollte ich doch mal versuchen die Daten der K-Line Schnittstelle zu lesen, also Drehzahl, Kühlertemperatur, usw. (10 Werte sind das).

Verbindung klappt soweit mithilfe eines l9637d, so dass ich Daten mit 9600 Baud anfordern kann und auch was zurückbekomme. Leider kann ich mit den Daten bisher wenig anfangen. Eine 5 Baud Startsequenz scheint gar nicht nötig zu sein, bzw. macht es bei meinem Code gerade keinen Unterschied. Weiß jemand ob da das KW1281 Protokoll verwendet wird oder doch was ganz anderes?

Gruß
Martin

[Gerhard]

KWP ja. allerdings ist die Baudrate sehr empfindlich. 9600 darf es maximal sein. Mit VCDS auslesen ist auch immer nicht immer erfolgreich

[Martin_78]

Ich bin ja doch viel weiter am Anfang als ich dachte... Ich krieg nämlich nur dieselbe Antwort zurück die ich geschickt habe und genau das passiert auch wenn das K-Line Kabel ab ist

[Steve44]

Vielleicht irgendwie die Spezifikationen des VAG 1551 und wie deren "Schnelle Datenübertragung" funktioniert, ausfindig machen? Vielleicht hat jemand mal "reverse engineering" gemacht?

[Martin_78]

Vielen Dank schon mal für die Infos!

Zum VAG 1551 habe ich auch lange gesucht aber nichts gefunden...

Für KWP1281 gibt es hier schon interessante Informationen:
https://www.blafusel.de/obd/obd2_kw1281.html#5

Hier hat das auch schon mal jemand für den Arduino umgesetzt, zwar für ein anderes Auto aber so ähnlich müsste es für den 20V auch gehen:
https://github.com/OneB1t/ardKWP1281

Mein Plan ist sobald ich Daten bekomme, alles auslesen was geht. Dann beim Kollegen die Daten mit dem Laptop auslesen, die Daten abgleichen um rauszufinden welche Werte für was stehen...

Aber so weit bin ich leider noch nicht. Weil das Programmieren im Auto ziemlich umständlich ist habe ich jetzt noch ein Steuergerät aus dem Keller geholt.

Das habe ich dann wie unten im Bild zu sehen verkabelt. Allerdings kann ich damit nicht mal Ausblinken, die Lampe
ist immer aus, egal ob die Drahtbrücke gesetzt ist oder nicht. Habe ich da Mist gebaut?


Die Pin-Belegungen habe ich von da:
http://www.sjmautotechnik.com/trouble_s ... 0vpin.html

10. Ground (Brown Wire)
13. Diagnostic plug connector (L wire) (Brown/Green stripe wire)
18. Terminal 30 (+12V) supply, Fuse #27 (White/Black stripe)
22. Diagnostic plug connector (output) (Green/Red stripe wire)
27. ECU Power supply Terminal #15 (Ignition +12V)
55. Diagnostic plug connector (K wire) (White/Blue stripe wire)

Wenn das Projekt fertig ist kann ich auch ne Anleitung machen falls es jemand nachbauen will

diagnosegeraet.png (341.28 KiB) 2490 mal betrachtet

[Martin_78]

Ground muss 14 sein und nicht 10, dann kann man auch ausblinken.

14. Control Unit ground (Brown wire)

[Kapitaen Pluto]

Interssantes Projekt.
Was ist dein Ziel bzw. welchen Zweck verfolgst du?

Ich werde auf jeden Fall mit lesen!

Gruß
Andreas

[Steve44]

Ich habe, zum bequem und schnell den 20V‘s Blinkcodes auslesen zu können, den „Check Engine“ Lampe im KI aktiviert.
viewtopic.php?f=6&t=167364

Ware das nicht einfacher und „gut genug“?

[Martin_78]

Hi,

das ganze ist ein Spaßprojekt... Ob man das jetzt brauch oder nicht weiß ich nicht

Ich hab mir eine kleine Box aus PETG gedruckt mit OLED-Display und zwei Buttons. Fehlerspeicher und Stellglieddiagnose dann über Menüführung, Reizleitung über Relais, so dass man nicht viel überlegen muss und nicht aus Versehen im falschen Programm landet. Fehler werden dann im Kurztext und gescrollt als Langtext angezeigt. Ist dann halt einfacher als ausblinken, ich hatte da jedes Mal neu lesen müssen wie ich es verkabeln muss, usw.

Das mit dem K-Line wäre schon echt cool, wenn ich das noch hinkrieg. Zumindest habe ich jetzt ein Steuergerät auf dem Tisch und kann einfacher testen...

Ich hab auch nicht so den Überblick was es neben VAG1551 für Diagnosetools gibt und was die dann anzeigen können.

Mit der "Check Engine" Lampe is natürlich auch sehr cool!

[Fussel]

Hallo Martin,

leider ist das Thema K-Line bei mir schon so lange her. Ich habe damit in 2005 bzw 2006 beruflich programmiert, und seitdem garnicht mehr. Daher kann ich Dir da adhoc leider nicht weiterhelfen, weil die Info zu weit hinten im Hirn liegen - und da ich beim 100er das K-Line nicht nutzen kann, fehlt mir ehrlich gesagt aktuell etwas der Elan mich da reinzudenken. Ich habe mit meinem noch einiges vor mir, damit ich ihn endlich wieder durch den TÜV bekomme. Der steht schon wieder über 2 Jahre und der TÜV ist seit Sommer 2024 abgelaufen...

Das Thema Arduino finde ich allerdings sehr spannend. Beruflich bin ich leider nun auch weiter weg vom Programmieren und fülle mittlerweile meist nur noch Excel und PowerPoint Dokumente... Nachdem es keinen passenden Multifuzzi mehr gibt, hab ich mir auch schon überlegt, einen normalen Sensor zu verbauen, der dann von einem Arduino ausgelesen wird und dann die entsprechenden Werte mittels Lockup-Tabelle weitergibt. Ist zwar etwas aufwändig, sollte aber besser funktionieren, als die nicht nutzbaren Multifuzzis, die dann Käse ausgeben.

Dir viel Erfolg!

[Martin_78]

Ja, mit Arduino kann man sehr viel machen, den Multifuzzi ersetzen bestimmt auch. Manchmal ist sowas einfach und manchmal sucht man tagelang nach dem Fehler

Eigentlich gibt es genug Infos im Netz für K-Line mit KWP1281 auslesen... Ich hoffe da ist nix spezielles bei der Motronic vom 20v. Es gab wohl auch mal KWP71 von Bosch, aber mit der Startsequenz davon krieg ich auch keine Antwort. Vielleicht ist es doch noch ein Hardware-Problem...

[Fussel]

Hallo Martin,

hast Du Dir schonmal die Datenübertragung am Oszilloskop angeschaut, was auf der K-Line überhaupt los ist - oder was eben nicht? Evtl findest Du auf diese Art und Weise den Fehler.

Quattrogetriebene Grüße,
Fussel

[Martin_78]

Hi,

ja, und das ist merkwürdig. Die Signale kann ich am Oszilloskop sehen, allerdings überall Das Signal was ich sende, also die Start Bytes, sind am K-Line zu sehen, was ja ok ist, am sendenden TX aber auch am empfangenden RX-Pin. Dasselbe messe ich auch wenn ich das K-Line Kabel am Steuergerät entferne. Deswegen dachte ich da is was falsch verkabelt. Hab aber schon alles zig mal geprüft. Jetzt steht aber auf der Blafusel-Seite das hier:

"Jedes vom µC gesendete Zeichen wird mit einem ECHO quittiert. Das bedeutet, das gesendete Zeichen wird automatisch an den Sender zurück geschickt. Dabei hat das Steuergerät nicht die Finger im Spiel und die Echos gehen stets sofort nach dem Abschicken ein, noch bevor Daten vom Steuergerät kommen. Diese Echos sind einfach zu ignorieren."

Deswegen blick ich jetzt gar nicht mehr durch...

[Fussel]

Überall? Die K-Line hat doch nur eine Leitung und ist bi-direktional.... Oder hast Du auf der TX- und RX-Leitung am Controller gemessen, nach der Umsetzung? Dass beim Senden das Signal auch auf der Receive-Leitung zu sehen ist, kenne ich so nur vom CAN: auf diese Weise erkennt ja das Steuergerät, ob jemand höher priorer Busteilnehmern den gerade sendenden überstimmt und somit dann vom Bus geht und es später erneut versucht. Das gibt's aber ja bei der K-Line nicht.

Bevor eine Kommunikation stattfindet, kann ich mich noch an eine Reizung zur Initialisierung der Kommunikation erinnern. Erst wenn die korrekte Reizung empfangen wurde, kann eine Kommunikation aufgebaut werden. Wenn ich mich zudem auch noch richtig erinnere, gibt es für die Reizung aber keine Vereinheitlichung, sondern das kann durchaus unterschiedlich ablaufen.

Quattrogetriebene Grüße, Fussel

[Martin_78]

Hi Fussel,

das Bild ist jetzt ausm Netz, die Pins vom Steuergerät sind bei mir andere, quasi die von meinem selbstgemalten Bild weiter oben . Die Messungen hab ich an den Pins von dem Bus-Treiber L9637 gemacht. Ich hab mir jetzt nochmal einen bestellt, vielleicht ist damit ja doch was nicht in Ordnung.

Die Reizung ist ja das Senden der 5 Baud Init Sequenz. Und da sollte es mit dem KWP-Protokoll 1281 (wo ich erstmal davon ausgehe, dass das auch beim 20v verwendet wird) eigentlich so gehen wie hier beschrieben:
https://www.blafusel.de/obd/obd2_kw1281.html#5

Also Baudrate 5 und 0x01 schicken und darauf sollte dann das Steuergerät mit Baudrate 4800, 9600 oder 10400 antworten. Hab da auch schon mal alle möglichen Baudraten durchiteriert aber hat nix geholfen...

Ich warte jetzt mal auf das neue Teil und teste dann nochmal.

Gruß
Martin

[BAUM4477]

Hallo! Ein spannendes Projekt

Ich wundere mich über den Schaltplan. Haben wir nicht K und L Leitung? Der Pin 8 ist hier einfach offen. M.E. müsste da die L-Leitung ran.
Hier hat jemand eine Umsetzung auf USB aufgezeigt. Könnte als Basis für die korrekte Beschaltung des L9637D dienen.
https://www.drive2.ru/c/2032328 (weit runter scrollen)

Und hier => https://www.s2forum.com/forum/technical ... e-scanners noch die Übersicht zum OBD <-> KL Adapter.

Ich nutze den Adapter von Blasfusel und WBH-Diag. Habe allerdings ein Steuergerät aus dem AAN im 200 20V hängen.

VG
BAUM4477

[Martin_78]

Super, vielen Dank! Ich dachte tatsächlich die ganze Zeit, dass man nur die K-Line brauch. Aber ich glaub du hast recht. Ich bau das die Tage mal so nach!

Viele Grüße
Martin

[Martin_78]

Hi,

hier mal der aktuelle Stand... Mit dem Schaltplan von der russischen Seite klappt es jetzt tatsächlich! Vielen Dank nochmal!
Ich kann jetzt mit dem Steuergerät reden. Ich krieg wie auf der blafusel-Seite (https://www.blafusel.de/obd/obd2_kw1281.html#5) beschrieben 4 Byte-Sequenzen wo mir das Steuergerät erzählt wie es heißt.

447 907 404 A
MOTOR
2MC 1
0261200451

Die Daten machen auch Sinn. Danach sollte mir das Steuergerät aber eigentlich diesen Datenblock schicken:
0x03
0x?? (Block Counter)
0x09
0x03

Das tut es leider nicht. Es schickt mir stattdessen ein D (HEX) = 13. Nach ein paar Millisekunden schickt es mir dann nochmal ein D und das wars. Wenn ich das D mit dem entsprechenden Komplement beantworte bekomme ich 9, wenn ich das beantworte wieder D, dann wieder 9, das Spiel geht dann so für immer weiter...

Ich vermute, dass das "Fehler"-Bytes sind und ich nach dem Empfang der Steuergerät-Info-Bytes doch noch was anderes schicken muss als bei blafusel beschrieben. Aber leider finde ich dazu im Netz einfach gar nix und chatgpt kann man bei sowas ja auch vergessen....

Das Steuergerät auf meinem Tisch verhält sich dabei genauso wie das im Auto. Habt ihr noch eine Idee was ich machen könnte?

Viele Grüße
Martin

[Martin_78]

Hab noch Code auf github gefunden der nun auch bei mir läuft... da kommt noch eine Seriennummer mehr als bei mir. Sensordaten oder Fehler kann ich damit zwar auch nicht auslesen aber damit kann ich bisschen rumprobieren. Ich melde mich wieder wenn der Gerät fertig is

[BAUM4477]

Super, dass der Plan funktioniert hat
Du machst ja echt Fortschritte Martin. Großartig.

VG
BAUM4477

[Martin_78]

Hi,

das Diagnosegerät ist jetzt fertig, funktioniert alles einwandfrei. Ich finde es ist ziemlich gut geworden

Funktionen:
- Fehlerspeicher auslesen über K-Line
- Fehlerspeicher ausblinken
- Fehlerspeicher löschen
- Sensorenwerte auslesen
- Stellglieddiagnose
- Speichern/Laden der letzten Werte
- idiotensichere Menüführung
- Stromversorgung über Diagnosekabel oder USB
- Easteregg

Ich werde jetzt noch ne kleine Doku schreiben. Bauplan, Code und die Dateien für den 3D-Druck lade ich dann auf Github hoch falls es jemand nachbauen will. Vielleicht mach ich noch ein kleines Video wo man sieht wie das Gerät funktioniert.

Das Gerät sollte so für 3B und AAN Motoren funktionieren. Mit kleinen Änderungen könnte man das aber auch für NF und MC Motoren verwenden. Die Fehlertexte (Kurz- und Langtext) habe ich schon mal hinterlegt. Ich glaube dann geht aber nur das Ausblinken.

Gruß
Martin

[BAUM4477]

Hallo Martin,

genial !!! Du hast es zum Abschluss gebracht! Sehr cool geworden Und ich freue mich, dass Du Dir die Mühe machen möchtest und das Projekt auf GitHub veröffentlichen willst. Bitte den Link dann hier teilen. Ich bin schon sehr gespannt.

Hast Du bei den Sensordaten schon ein Mapping implementiert oder erstmal nur Rohdaten in der Anzeige?

VG
BAUM4477

[Martin_78]

Hi,

ja, mit den Werten fand ich schwierig, das hatte ich schon ganz vergessen. Die Spalten "Beschreibung" und "Zusatzinfos" und "Spec" sind aus dem RLF. Da ich ja nicht so viel Platz auf dem Display habe musste ich ein paar Sachen abkürzen. Ich hoffe das macht so Sinn.

Wegen den Berechnungen habe ich aus Mangel an Kenntnis chatgpt gefragt, oft und viel Die KI war der Meinung, dass man die meisten Werte nicht korrekt umrechnen kann. Da wo es zumindest annäherungsweise richtig wäre habe ich das dann gemacht.

Ich weiß nicht wie und ob man hier Tabellen einfügen kann. Daher leider als Bild:

[Martin_78]

Ich hab das übrigens so gemacht, dass man auf einer Übersicht alle Werte auf einmal sieht und auch wie die sich in Echtzeit verändern, das geht tatsächlich. Wo es ok ist wird ein Haken gesetzt, sonst ein X. Bei meinem Auto schwanken die Werte sehr stark und dass wirklich alle Werte im Spec-Bereich sind ist selten Kann aber auch an meiner Karre liegen

[Kapitaen Pluto]

Das ist sehr cool geworden!

[BAUM4477]

Ich hab das übrigens so gemacht, dass man auf einer Übersicht alle Werte auf einmal sieht und auch wie die sich in Echtzeit verändern, das geht tatsächlich. Wo es ok ist wird ein Haken gesetzt, sonst ein X. Bei meinem Auto schwanken die Werte sehr stark und dass wirklich alle Werte im Spec-Bereich sind ist selten Kann aber auch an meiner Karre liegen

Ja, viele Daten schwanken schnell. Es ist ja ein geregeltes System. Ich hab für Messfahrten ein altes Laptop mit WBH-Diag und den Kabel-Adapter von Blafusel. (Der mit Bluetooth hatte immer Probleme mit dem Timing.)

Über WBH-Diag wähle ich die Kanäle, die gelesen werden sollen und schreibe die als CSV weg. Analyse geht dann nur nachträglich.
Da der die Werte sequentiell ausließt passen die Messwerte dann nur mit Versatz zusammen. Je mehr Werte ich weg schreibe, um so größer ist damit der zeitliche Abstand zwischen den Werten.

Gerade bei Werten, die sehr dynamisch sind muss ich daher auf Infos verzichten und mich auf wenige Messwerte beschränken. Last und Zündwinkel z.B. Oder Drehzahl und Einspritzung.

Die Auswertung der Daten erfolgt dann später per Excel.

Als Idee: Du könntest die Werte in einem Diagramm (wie beim Oszi) darstellen und die Abtastung virtuell anpassen. D.h. nur jeden x-ten Wert darstellen, obwohl alle gemessen werden.

Für Analysen könntest Du einen Trigger definieren und die Messerwerte in einem Ringpuffer zwischenspeichern

Z.B. Wenn Zündwinkel (t) <> Zündwinkel (t-1)*x% => schreibe alle Daten des Ringpuffers + die länge das Puffers an aktuellen Messwerten in eine CSV ( bzw. auf dem Display darstellen )

So hättest Du dann alle Werte, die vor und kurz nach dem Ereignis waren.
Ich bin so der Tankstelle auf die Schliche gekommen. Angebliche 98 Oktan. Aber stimmte nicht. Hat unter Last geklopft, wie ich über die Messwerte dann sehen konnte. Wo anders getankt - kein Klopfen mehr.

VG
BAUM4477

PS
Wenn ich dazu komme, dann schaue ich mal in die Mapping Datei von WBH-Diag. Ich glaube, da sind Umrechungen der Werte hinterlegt. Evtl. auch zu welchen, zu denen Du keine Daten finden konntest.

[Martin_78]

Hi BAUM4477,

du hast ja sehr viele gute Ideen und kannst scheinbar auch wirklich was mit den Sensordaten anfangen! Da ich mit meiner eigenen Implementierung irgendwie nur an die Informationen gekommen bin die das Steuergerät am Anfang sendet (Serialnummer, usw) habe ich ja irgendwann eine externe library eingebunden: https://github.com/domnulvlad/KLineKWP1281Lib

Damit bekomme ich alle 200ms neue Daten, die library liest alle 10 Werte auf einmal. Könnte aber auch sein, dass man die Werte einzeln lesen kann. Das müsste ich mir genauer angucken. Wenn man das Display jedes Mal aktualisiert sind es schon 290ms. Das ist dann vielleicht schon zu lang? Geht das denn mit deinem Tool schneller? Evtl. sind in der library auch irgendwelche delays eingebaut die man gar nicht brauch.

Mit den Diagrammen und Triggerpunkten wäre natürlich alles machbar. Aufgrund der 128 x 64 Pixel und da es nur schwarz/weiß ist wäre man natürlich da auch etwas limitiert. Daten an den Laptop übertragen wäre auch machbar, z.B. über USB/Putty oder auch über Bluetooth.

Gruß
Martin

[BAUM4477]

Hallo Martin,
die 200ms sind deutlich flotter, als bei meinem WBH-diag + Blafulse Adapter. Tolle Sache!
Ich erhalte ca. alle 450-500ms eine Gruppe aus 4 Messwerten. Die Zeit zwischen den Messwerten schwankt dann auch noch
Sehr unschön und aufwändig in der Analyse.

Die Zusammenhänge der Messwerte hab ich mir mit Hilfe der SSP angeeignet. Mit jedem Fehler am Fahrzeug lernt man etwas mehr dazu
Die Bedeutung der Messwerte wird mittels s.g. Label Files in WBH-Diag ermittelt. Und WBH-Diag akzeptiert konvertierte Label Files von VAGCOM.
Dazu folgender Beitrag klick mich!https://www.blafusel.de/phpbb/viewtopic ... 4234#p4234[/longurl]

Das mit dem Wegschreiben auf USB ist ein guter Ansatz. Wenn Du den noch umsetzt, dann kannst Du die Daten nach erfolgter Messfahrt auswerten.
Die Werte einfach so zu betrachten ist cool, aber hilft bei der Diagnose noch bedingt. Man muss das zwangsläufig in Ruhe und im Zusammenhang betrachten.

VG
BAUM4477

[Martin_78]

Hi BAUM4477,

danke, das mit den Labels gucke ich mir mal an. Ich bin jetzt erstmal im Urlaub. Danach guck ich mal was man noch so machen könnte. Du hast mir auf jeden Fall schon sehr viel geholfen!

Gruß
Martin

[Martin_78]

Hi,

für die Auswertungen der Sensorwerte baue ich gerade noch ein kleines Python-Programm, das ist auch fast fertig. Datenübertragung/-anzeige geht dann über USB zum Laptop zur Echtzeit und man kann dann auch csv-Dateien speichern/laden.

Eine Frage hätte ich noch... Weiß jemand wie groß die Unterschiede sind bei den einzelnen Motoren? Für den AAN wird mein Tool wohl sehr sicher auch funktionieren, da finde ich genug Infos im Netz. Da gibt es auch genau die 10 Sensorwerte wie beim 3B. Aber gibt es noch irgendwelche Unterschiede zu ABY und RR? Hab ich noch eine Motorkennung vergessen? Danke!!

Gruß
Martin