Pin-Belegung ECU / Can-Bus

Hab nur das...

Gibt kein CAN, nur ne K-Line. Ist die gelb-rote am Diagnostic Connector laut Schaltplan.

Zitat von C390

Ohne DBC ist es nahezu unmöglich sinnvolle Daten aus den Can Frames zu lesen.

Streiche "nahezu unmöglich" , setze "aufwändig und erfordert Fachwissen".

DBC-Files (zumindest die für Racedatalogger relevanten Teile davon) zu erstellen ist grade bei älteren Fahrzeugen durchaus im Bereich des machbaren, da ist auf dem Bus noch nicht viel los und die Kommunikation meist noch wesentlich übersichtlicher gestaltet.

Ich glaube aber, aus den Aussagen von OP zu entnehmen, dass dieser nicht vorhatte, einen CAN-Bus Sniffer zu verwenden, der die im Betrieb ausgetauschten Frames loggt. Viel mehr glaube ich, dass er einfach die SAE-standardisierten OBD-PIDs loggen wollte, läuft ja auch über CAN und CAN und OBD wird ja gerne mal vermischt, wenn man sich nicht so auskennt (kein Vorwurf/Unterstellung).

Mo!n Vllt kannst du uns ja über deine ursprünglichen Plan aufklären (samt Link zum Projekt)?

Na ja, selbst wenn die Drosselklappeneinheit ein eigenes kleinesSteuergerät hätte, das mit der ECU über CAN kommuniziert, wäre das nix geworden.

Warum?

Nu ja, hier sollte man den angesprochenen Unterschied zwischen CAN und OBD2 kennen:

-CAN ist ein serielles Bussystem. Definiert wird hier Hardware sowie das Übertragungsverfahren. Kommuniziert wird hier mit sogenannten Frames, die Daten enthalten. Wie diese Daten aussehen (kodiert sind), kann der Benutzer/Hersteller frei definieren. Das wird dann z.B. in DBC-Files festgelegt, der Inhalt ist meist proprietär und wird von den Herstellern nicht veröffentlicht => man muss dies durch reverse Engineering erstellen, das ist je nach Teilnehmeranzahl und Aktivität auf dem Bus mehr oder weniger aufwändig bis fast unmöglich für Privatpersonen.

Dann kann man einfach bei der Kommunikation der Steuergeräte "mithören", ist aber davon abhängig, dass die Daten von Interesse denn auch tatsächlich von den Steuergeräten ausgetauscht werden und auf die Intervalle dieses Austausches hat man auch keinen Einfluss (im unserem Falle würden über den Bus sinnvollerweise nur mit der Drosselklappe zusammenhängende Daten ausgetauscht werden, also Drosselklappenstellung Ist-,Sollwert und Einspritzzeiten, aber z.B. keine Geschwindigkeit o.ä.).

-OBD2 ist eine höhere Protokollschicht. Hier wird definiert, welche und wie Diagnosedaten über verschiedene Bussysteme (heute meist CAN) ausgelesen werden können. Das funktioniert wie folgt: Dein Datalogger sendet ein definiertes Frame, darin enthalten sind sogenannte Parameter-IDS (PIDs). Das Steuergerät im Fahrzeug antwortet dann mit einem Frame, in dem der Wert des Parameters enthalten ist. Praktisch gesehen also bei Betrachtung von CAN ein DBC-File + Vorschrift, dass auf ein Requestframe mit dem zur PID gehörigen Parameter geantwortet werden muss (das ist dann in der Programmierung des Steuergerätes umgesetzt).

Dieses Protokoll wird nicht auf jedem x-beliebigen CAN-Bus unterstützt. Bei modernen Autos hast du teilweise mehrere Busse, und nur der am Diagnosestecker unterstützt dieses Protokoll, also irgendwo Stichleitung ran und los gehts ist nicht. Entweder du hast CAN_h und CAN_l am Diagnosestecker oder es es wird nix, weil bei Bussen, die nicht für OBD2-Diagnose vorgesehen sind werden die Steuergeräte nicht wissen was sie mit deinen PID-Requests machen sollen, schlimmstenfalls kann das sogar Probleme geben weil falsch interpretiert.

(Bei Motorrädern gibt es meist nur einen Bus, über den kommunizieren die Steuergeräte untereinander, aber über Pins im Diagnosestecker können über diesen auch OBD2-Requests gesendet werden, die dann eines der Steuergeräte beantwortet.)

Der Diagnosestecker ist übrigens da auch standardisiert. Allerdings sei hier gesagt, dass Motorräder erst ab 2024 OBD 2 gesetzlich vorgeschrieben bekommen, weshalb man häufig noch proprietäre Stecker findet, aber trotzdem schon die standardisierten PIDs verwendet werden (allerdings auch nicht immer alle).

OBD 2 definiert auch 2 Protokolle für K-Line Busse, wsl. findet bei der SD990 ISO14230 Anwendung. Dafür gibts auch Projekte auf Github von denen du dich inspirieren lassen kannst, funktioniert ähnlich ist halt aber recht langsam im vgl zu CAN.

TLDR: stell dir OBD2 als eine mögliche Sprache vor, die du über ein Telefon (CAN, K-Line) überträgst. Nur weil dein Gegenüber (Steuergerät) ein Telefon hat, versteht und spricht es nicht zwangsläufig deine Sprache.

Viel Spass bei deinem Projekt, nicht unterkriegen lassen Und halt uns auf dem laufenden, sowas ist immer interessant falls es mal einer nachmachen will.

Jo, ist A17, der geht zum Diagnostic Stecker per gelb rotem Kabel.

Aber immerhin wissen wir jetzt dass das ISO9141 Protokoll verwendet wird (und nicht ISO14230 wie ich oben vermutet hatte). Pinout im Anhang.

Echt? Welche ist denn das?

TLDR am Anfang: Stimme dir zu.

Funktionen der Displayeinheit + Warnleuchten samt Pins:

-Blinker (PINS 3,4)

-Fernlicht (PIN 5)

-Öldruckwarnung (PIN 7)

-Speed Sensor (PINS 9,15,16) , ODO-Wert wird nicht mit ECU kommuniziert, d.h. auch für ODO und Tripmeter

-Fuel Level (1)

-Neutral (PIN 6)

-FI-Licht/MIL (PIN 8)

-12V (PIN 10)

-GND (PIN 2)

-Uhrzeit (intern)

Drehzahlmesser seperat.

Frei bleibt PIN 12 (K-Line Dashboard an der ECU, da PIN 34) und an Funktionen die Anzeige der Wassertemperatur, diese wird also mindestens über die K-Line übermittelt.

Läuft noch mehr drüber? Ne, eher nicht. Wie komm ich drauf? Nu ja, zusätzlich zu kein weiterer Datenbedarf kommt folgendes:

Ab MJ 2007 (Wechsel der Tachoeinheit) ist PIN 34 an der ECU unbelegt (deshalb war ich auch überrascht), der (neue) Wassertemperatursensor ist nun direkt mit dem Display verbunden.

Dieses kann übrigens nachgerüstet werden (wie ich bei Recherche erfahren habe), dazu muss man, um den 07er Headlight Wiring Harness verwenden zu können, einen für die 12 PIN-Verbindung einen Zwischenstecker basteln, der Tacho auf PIN 8 (Main Harness Seite) legt und PIN 9 statt mit der K-Line der ECU mit dem neuen 3. Pin des zu tauschenden 07-Wassertemperatursensors verbindet. Der neue Sensor enthält einen Thermistor für die ECU und einen Thermistor auf GND für das Display.

Wer die (ab 07 neue) Frostwarnung auch funktional haben will, muss noch den Umgebungstemperatursensor für das Display (die ECU hat ab 07 einen separaten) kaufen und anschliessen (seperater Stecker am Headlight Harness).

Es gibt auch keine Fehlermeldung wenn man die K-Line trennt, wsl. ist das ganze also unidirektional, die ECU sendet nur und wie gesagt, das Display braucht nur noch die Wassertemperatur. Ob da dann überhaupt ein Protokoll wie ISO9141 verwendet wird? Müsste man mal analysieren, kann mir auch vorstellen das für unidirektionale Kommunikation das ganze wesentlich simpler gemacht ist.

Bleibt festzustellen: für deinen Datalogger ist diese K-Line eher uninteressant, du musst über die K-Line am Diagnosestecker OBD2-Abfragen tätigen (dies ist bei der 990 SD möglich). Musst mal schauen (ausprobieren), welche PIDs KTM unterstützt, normalerweise sind alle Werte, die die ECU kennt, auch abfragbar. Dokumentation der PIDs findest du im Internet (auch auf Wikipedia), oder du besorgst dir halt die entsprechende Norm.

Wie gesagt, ich freue mich auf Berichte wenns klappt Grade die Kamera ist interessant, kenne ich noch nicht

PS: Ach ja, was ich dir noch mitteilen wollte. ISO9141 ist im Gegensatz zu CAN arschlangsam. Educated guess: pro PID-Abfrage (gehen nur einzeln, ausser bei CAN) gehen da 50ms drauf, willst du also z.B. Geschwindigkeit, Drehzahl, Drosselklappe loggen hast du schon nur noch ca. 6-7Hz. Hängt aber davon ab, was die ECU für Limits bei den Timing Parameters hat.

Für höhere Abfragefrequenz musst du einen Datalogger entwerfen, der die Sensorwerte parrallel zur ECU selbst aufnimmt.

Zitat von KlainerFaigling

Das wäre aber wenig sinnvoll.

Ist aber so. Über einen Bus werden im Normalbetrieb nur tatsächlich für den Betrieb benötigte Daten übermittelt (in meinem Beispiel eines Busses ECU-Drosselklappeneinheit (sonst nix) also nur für Werte dies betreffend), warum auch mehr? Wäre nur unnötiger Traffic. Und da sind (bei Motorrädern) nicht immer alle Daten von Interesse bei.

Sind über den Bus z.B. OBD-Abfragen möglich, forderst du die Steuergeräte auf, dir eine Antwort zu geben. Dann kannst du natürlich auch an Daten kommen, die von den Steuergeräten im Betrieb nicht ausgetauscht werden, weil sie nur eines davon benötigt. Dies ist allerdings nicht auf jedem Bus zwangsläufig möglich. Moderne Autos haben meist mehrere Busse (also nix von wegen jedes Gerät am selben Bus), die meist über ein Gateway verknüpft sind (das sit aber auch nicht zwangsläufig der Fall). An diesem hängt auch ein CAN-Bus für Diagnose/Updatezwecke, und nur auf diesem sind OBD-Abfragen möglich (Das Gateway fragt dann über den richtigen Bus o.ä. das entsprechende Steuergerät ab und sendet dann die OBD-Response über den Diagnosebus).

Die meisten Mopeds sind weniger komplex, hier gibt es meist einen Bus, der sowohl zum Datenaustausch als auch für OBD-Abfragen dient (Bsp. meine 790). Es gibt aber auch welche wo das nicht so ist, die alte Generation Daytonas hatte z.B. einen CAN-Bus zur Kommunikation Tacho-ECU, aber eine K-Line zur Diagnose. Über den CAN-Bus werden da nur für den Tacho relevante Daten ausgetauscht, dies kann man mitlesen. Abfragen sind nicht möglich...

Die 990 hat aber erstens keinen CAN-Bus zum Display (also auch kein Can Database file (DBC) ), sondern eine K-Line (da heisst das anders) un über diese wird auch lediglich die Wassertemperatur übermittelt (also bis 06, bei 07 ist sie dann nicht mehr angeschlossen). Die könnte man da mitlesen, Möglichkeit für Abfragen bezweifle ich stark, ob überhaupt ein komplexes Signalprotokoll und nicht eher in Richtung PWM da drüber läuft müsste man auch erstmal analysieren. Für die Übertragung eines vllt sogar nur 3Bit Wertes (8 Striche für die Temperatur im Display, kann natürlich auch eine höhere Auflösung übermittelt und dann umgerechnet werden) ISO9141 hätte ich ja nicht gemacht....