Hi,
oder mal die Komunikation mit der Diagnoseuhr mitloggen ... und die Fehler posten die die Uhr dann meldet.
Gruß Frank
Hi,
oder mal die Komunikation mit der Diagnoseuhr mitloggen ... und die Fehler posten die die Uhr dann meldet.
Gruß Frank
Das ist der Plan. Auf den Zuheizer warte ich noch.
Hi,
hab mir mal das Bild genauer angeschaut:
Zitat
sieht für mich nach:
1010000 - 80
0101101 - 45
0001001 - 09
1010010 - 82
1010000 - 80
aus.
Gruß Frank
Nur leider gibt es keine Zuheizerfehler mit den Nummern.
Mit abgezogenem Steuerteil (Vom Zuheizer abgezogen) sollten es 20, 31, 48, 60, 64 oder 71 sein.
Hi,
ganz so einfach wird es auch nicht sein da der Zuheizer der Uhr einen Fehler mitteilen kann oder die Uhr einen Fehler abfragen kann, über die PC Tools kann man auch noch Temperaturen und Betriebsstunden abfragen, es sollte neben den daten auch noch Befehle geben die dann den Datentransfer steuern. Daher wäre es mal gut eine komplette Sequen (Uhr liesst aus) mit und ohne Fehler zu loggen und auszuwerten.
Gruß Frank
Wenn ich es noch richtig im Kopf habe dann ist das Protokoll ungefähr so
Langer Highpegel als Start, 7/8Bit alternierend high low um das Timing vorzugehen gefolgt von eienr Versionsnummer oder Ähnlich individuellen Code, und dann
-Zuheizer neue Version (Torxschrauben, Runder Ampstecker am Steuergerät): ein bis fünf folgen Fehlercodes 7/8Bit codiert je nach dem wieviele Fehler gespeichert sind
_Zuheizer alte Version (Kreuzschlitz, Eckiger Stecker am Steuergerät): ein Fehlercode 7/8Bit codiert.
darauf folgen dann weitere datenfelder die aber nicht mehr Spezifisch auf den Fehlercode rückführbar sind
Die Sequenz wird dann laufend wiederholt wobei sich das Timing immer mehr verlängert, die Übertragungsrate gesenkt wird. Der Startpuls ist vom Timing konstant
Mikrocontroller hatte ich schon mal angefangen mit Programmieren, ich hab den Input pin interrupt genommen mit einem laufenden Timer um die Timing sequenz zu messen. Und dann eben entsprechend zum erwarteten Mittenzeitwert eines Bits den Pegel zu lesen.
Was ich nicht mehr angegangen bin ist das resetten des Fehlerspeichers. Hier muss zusätzlich eine Signalfolge von der Moduluhr gesendet werden, vielleicht sogar auf der Schaltleitung. Denn auf der Diagnoseleitung habe ich nichts mitschneiden können.
Ein Zuheizer gibt auf der Schnittstelle mindestens seinen Typ, die Betriebsstunden und die Fehler aus. Ich werfe nachher mal den Diagnoserechner an und schaue, welche Fehler er ohne Sensorik wirft.
Ralf
Hi,
ganz so einfach wird es auch nicht sein da der Zuheizer der Uhr einen Fehler mitteilen kann oder die Uhr einen Fehler abfragen kann, über die PC Tools kann man auch noch Temperaturen und Betriebsstunden abfragen, es sollte neben den daten auch noch Befehle geben die dann den Datentransfer steuern. Daher wäre es mal gut eine komplette Sequen (Uhr liesst aus) mit und ohne Fehler zu loggen und auszuwerten.
Gruß Frank
Duie daten Temperatur etc sind glaube in den feldern hinter dem Fehlercode abgelegt. Da kommen nämlich noch so sachen die auf Seriennummer etc schließen lassen. Die sind nur nicht so einfach zu dekodieren da man den zustand nicht vorgeben kann.
Ich bin überzeugt das eine erweiterte Kommunikation auch über die Schaltleitung des Zuheizers geht. Das würde auch erklräen warum man mit nem einfachen ISO Interface per KD2000 nur mit der diagnose leitung keinen Fehler resetten kann.
Hi,
ZitatIch bin überzeugt das eine erweiterte Kommunikation auch über die Schaltleitung des Zuheizers geht. Das würde auch erklräen warum man mit nem einfachen ISO Interface per KD2000 nur mit der diagnose leitung keinen Fehler resetten kann.
bei mir geht das Zuheizer Einschaltsignal über das ZHSTG und ich meine das ich trozdem mit der uhr den Fehlerspeicher resetten kann auch den Zuhiezer entsperren kann. Jegliche Komunikation auf dem einschaltsignal würde aber im ZHSTG enden da der Atmel das Signal einliesst und über einen anderen Pin ausgibt.
Gruß Frank
Das ISO-Interface kann keine Fehler löschen, weil die Eberspächer Software den Löschimpuls (der auf die Kommunikationsleitung ausgegeben wird) auf einem Anschluss ausgibt, der bei den meisten Interfaces nicht mit der L-Leitung verbunden ist. Ich habe mein Interface modifiziert, damit geht es. Auch das Reizen für den Kommunikationsaufbau erfolgt so, aber ich kann meine D3LC damit trotzdem nicht ansprechen, das Mistding spricht einfach nicht mit mir... Die Zuheizer spucken ja ungefragt ständig Daten aus.
Durch manuelles 'Reizen' (Diagnoseleitung kurz nach Masse ziehen) konnte ich sie schon zum Ausspucken von Daten animieren, aber nicht mal das macht noch. Aber sie heizt...
Vielleicht wird sie auch nach zig erfolglosen Kommunikationsversuchen gesperrt, ich könnte mal die Sicherung ziehen.
Ralf
ganz so einfach wird es auch nicht sein
Stimmt.
Das ISO-Interface kann keine Fehler löschen, weil die Eberspächer Software den Löschimpuls (der auf die Kommunikationsleitung ausgegeben wird) auf einem Anschluss ausgibt, der bei den meisten Interfaces nicht mit der L-Leitung verbunden ist. Ich habe mein Interface modifiziert, damit geht es. Auch das Reizen für den Kommunikationsaufbau erfolgt so, aber ich kann meine D3LC damit trotzdem nicht ansprechen, das Mistding spricht einfach nicht mit mir... Die Zuheizer spucken ja ungefragt ständig Daten aus.
Durch manuelles 'Reizen' (Diagnoseleitung kurz nach Masse ziehen) konnte ich sie schon zum Ausspucken von Daten animieren, aber nicht mal das macht noch. Aber sie heizt...
Vielleicht wird sie auch nach zig erfolglosen Kommunikationsversuchen gesperrt, ich könnte mal die Sicherung ziehen.Ralf
Ui, wieder was gelernt Welches signal müsste ich bei mir nachbelegen?
Ich habe meine 2 Sekunden Aufnahme von gestern mal auf Muster untersucht. Und ich denke ein paar generelle Sachen kann ich daraus schon schließen:
Ich würde behaupten man kann den Anfang der Übertragung ausmachen. In dem 1. Bild sind gut die 3 langen HIGH Pegel zu erkennen. Sie dauern jeweils gut 25ms. Das würde ich als den Anfang bezeichnen.
Desweiteren ist nach dem langen HIGH Pegel charakteristisch der 4-malige Wechsel von LOW auf HIGH. Ich würde sagen das ist die Taktlängenfestlegung.
Ich habe dann weiter geguckt und meine folgendes Muster zu erkennen: 1 Takt LOW, 4 Takte HIGH, 1 Takt LOW, 7 Takte Nachricht und von vorne. Ich glaube das es eine 7 Bit Nachricht ist, weil bei allen Nachrichten, die ich angeguckt habe, der 1. Takt vor und der 1. Takt nach den 4 Takten HIGH Pegeln ein LOW Pegel war.
Mit dem Wissen werde ich jetzt die Dateien von Mikart auswerten und gucken, ob ich den gegebenen Fehlercode in den Messdaten wiederfinden kann. Ich verspreche mir davon z.B. klären zu können, ob das Bit mit der Wertigkeit 2^0 (LSB) oder 2^6 (MSB) an 1. Stelle kommt.
Ich habe mir die Messdaten von Mikart angeguckt und sehe darin meine Theorie betätigt.
Als Beispiel 2 Messungen:
Diese Messung hieß 72 und ich habe eine 7 Bit Codesequenz gefunden, die, wenn man davon ausgeht, dass das LSB als 1. gesendet wird, eine 72 darstellt. Sorry für die primitive Umsetzung mit Paint
0001001 -> weil LSB zuerst, Zahl umdrehen-> 1001000 = 72
Das gleiche habe ich erreicht bei der Messung mit dem Namen 2 mal 48 gemacht:
0000110 -> undrehen -> 0110000 = 48
Ich habe das auch für meine Messung von gestern gemacht. Erhalte nach dem Prinzip folgende Werte:
64 = Flammfühler Unterbrechung
4
0
0
0
5
90 = Steuergerät defekt (interne Störung)
72 = Überhitzungsfühler Kurzschluss
69
20 = Glühstift Unterbrechung
5
60 = Temperaturfühler Unterbrechung
usw...
Passt durchaus gut für meinen Messaufbau ohne Sensorik.
So, bin mal mit dem Rechner an ein Zuheizersteuergerät. Es kommen ohne Sonsorik 2 Fehler im Wechsel: 20 Glühstift und 48 Dosierpumpe.
KD2000 zeigt freundlicherweise auch den empfangenen String an, siehe Bilder:
hz2.png
hz1.png
Die Strings sind in der untersten Zeile zu sehen, einmal starten sie mit 14h (=20dez) und einmal mit 30h (=48dez)
Den Rest müsst ihr selbst entschlüsseln
Ach ja, in meinem OBD-Kabel werkelt ein FTDI232RL, will man damit Fehlerspeicher löschen muss man an Pin 3 einen nichtinvertierenden Treiber mit offenem Kollektor Ausgang hängen, der dann mit auf die Kommunikationsleitung geschaltet wird (Ich habe dafür einen Doppelkomparator verwendet, bei dem ich beide parallel geschaltet habe). Pin 3 ist das Signal 'RTS' einer seriellen Schnittstelle. Dort geben sowohl KD2000 als auch Edith die Signale für den Kommunikationsaufbau und das Löschen des Fehlerspeichers aus (zumindest nach meiner Einschätzung).
Der Zuheizer benötigt keinen Kommunikationsaufbau, der spricht immer, aus dem Grund klappt ja das Auslesen mit den blauen OBD Kabeln. Aber wegen der fehlenden Verbindung kann man den Fehlerspeicher nicht löschen. Mit der Änderung sollte auch die Kommunikation mit den Luftheizungen funktionieren, aber meine Heizung bleibt stumm
Ralf
Super info, Danke, dann werd ich mal mein interface umstricken
Hi,
Zitat1 Takt LOW, 4 Takte HIGH, 1 Takt LOW, 7 Takte Nachricht und von vorne
so seh ich das auch. Damit könnte man zumindest schon mal einen Atmel so konfigurieren das er die 7 Bit einlesen und abspeichern kann. Damit wäre man dann in der Lage eine Sequenz mit zu loggen und könnte versuchen mit der Sequenz den Zuheizer auszulesen.
Gruß Frank
So, bin mal mit dem Rechner an ein Zuheizersteuergerät. Es kommen ohne Sonsorik 2 Fehler im Wechsel: 20 Glühstift und 48 Dosierpumpe.
KD2000 zeigt freundlicherweise auch den empfangenen String an, siehe Bilder:Die Strings sind in der untersten Zeile zu sehen, einmal starten sie mit 14h (=20dez) und einmal mit 30h (=48dez)
Sehr gut! Vielen Dank dafür!
Es scheint mir so, als ob der Fehler der aktuell anliegt (Fehler AF), in der 1. Nachricht übertragen wird.
Sind die 5 anderen Fehler F1-F5 die aus dem Speicher des Steuergeräts? Ist dem so, würde ich sagen, das die gespeicherten Fehler in Nachricht 3-7 übertragen werden (hexa 3C = 60 dezimal).
Um dass zu bestätigen, wären weitere Oszilloskopaufnahmen (Dauer ~1-2 Sekunden) und dazu die Ausgaben von der Moduluhr hilfreich. Wenn noch jemand außer RobertP die Möglichkeit hat, das zu messen, wäre es super, wenn er das hier beiträgt!
Wenn jemand die Aufnahme vom Oszi in einer .csv Datei auf den PC importieren kann, könnt ihr mir die gerne schicken, dann plotte ich die mit Matlab und werte sie von Hand aus.
Ich habe die anderen Hexadezimalzahlen vom empfangenen String in Dezimalzahlen umgerechnet und konnte leider keinen einfachen Zusammenhang zu den anderen Messgrößen feststellen.
Die Fehlercode Blöcke sind aber am Ende Der Nachrichtensequenz, Alles was davor kommt dürften Messparameter und Modellnummer sein.
Die Fehlercode Blöcke sind aber am Ende Der Nachrichtensequenz, Alles was davor kommt dürften Messparameter und Modellnummer sein.
Vielleicht hat die Software den String umgedreht. Die Messung mit Oszi und Uhr wird Aufschluss geben.