Das SPI ECU TestBook Projekt

  • Moin Stefan,


    ich hab dein Anliegen nicht vergessen, war nur bislang nicht wieder am Testbook um das Kabel zu messen. Wird aber diese Woche noch was werden. ;)


    Wegen ECU: ich habe gestern eine Packung MOSFET Transistoren vom Typ IRF530 bestellt, die die IRL510 ersetzen sollen. Ich traue den IRL nicht so recht über den Weg, nachdem ich jetzt aus mehreren zuverlässigen Quellen gehört habe, das diese schon mal Ärger machen.
    Die Transistoren kommen heute im Laufe des Tage an, dann werde ich mich mal dran setzen.


    VG
    Ralf

  • Danke Ralf, ich weiß, daß ich mich auf dich verlassen kann!


    Ich wollte hier nur kundtun, daß ich ein MPI Kabel doppelt habe und dieses gegen ein SPi Kabel tauschen wollte. Vielleicht kann man auf diesem Wege eine ganze menge Arbeit sparen, da ich befürchte es gibt in diesem Adapter noch irgendwelche Prüfschleifen.


    Viele Grüße!


    Stefan

  • ...nach längerer Pause mal wieder ein kleines Update:


    Hab endlich das richtige DataSheet für den Intel Prozessor gefunden:


    http://www.datasheet4u.com/htm…AN87C196KD_Intel.pdf.html


    Damit kann man sich zumindest schon mal einen Überblick über die Lage der Pins und deren Funktion verschaffen. Nicht viel, aber auch wichtig!


    Dann hab ich mir mal meine eigene ECU vorgenommen (die das Main-Relay nicht mehr betätigt hat) und einfach mal den Treiber Mosfet vom Typ IRL510 ausgelötet. Natürlich sofort getestet und..... funktioniert einwandfrei. Hab trotzdem einen neuen IRF530 eingebaut.


    Als nächstes suche ich das Datenblatt des Motorola MAP Sensors, damit wir die auch mal prüfen können... Oder hat das schon jemand?

  • Quote

    Oder hat das schon jemand?


    Nee...aber hättest Du mir eher Bescheid gesagt, dass Du das Datenblatt vom 87C196 nicht finden konntest, hätte ich es Dir schon vieeeel eher zukommen lassen können. Ich hatte meins damals von http://www.datasheetcatalog.com gezogen.


    Zu dem Unterdrucksensor. Ich habe zwar noch nicht eingehender nach dem "Nummernchaos" auf dem MAP Sensor gesucht, aber weiter oben hatte ich ja letztens schonmal vorsichtig angemerkt, dass die Ingenieure damals wohl viele Chips "umgestempelt" haben. Beim MAP-Sensor ist das ähnlich: Der hat als Suffix-Typencode auch ein "T02", ähnlich wie T01, G01 usw. bei den anderen.


    Einen dieser Pseudo-IC Codes habe ich ja oben schon relativ zweifelsfrei identifiziert.


    Ralf, kannst Du mir vielleicht noch kurz etwas zu Deiner ECU sagen, die Du ganz zu Anfang abgelichtet hast? Und zwar interessiert mich die Revisionsnummer, die auf der Rückseite der Platine steht, weil ja doch ein paar Sachen in ihrer Anordnung verschieden sind.


    Bis später,
    Hannes

  • ich hab irgendwo auf dem computer die prozessordatenblätter von intel selber, such ich mal wenns hilft

  • Also für den Prozessor habe ich erst mal alles. Ohne das "Programm" kommt man hier eh erst mal nicht viel weiter. So viele A/D Wandler..... :rolleyes:


    Wegen des MAP Sensors: natürlich könnte man den auch am Testbook testen, aber das Teil mal eben Auslöten und auf Herz und Nieren Prüfen wäre ja auch nicht schlecht.


    Versionsnummer der ECU Platine suche ich nachher noch raus...

  • Super Info! Genial!


    Hat auch schon mal jemand das Gehäuse des MAP Sensors in der ECU auf gemacht? Werde das sonst demnächst mal mit einem versuchen.
    Wenn die obigen Sensoren kompatibel sein sollten, dann sollte es möglich sein, defekte MAP Sensoren zu erneuern. Die Teile gibts bei Spoerl für 20 Euro...

  • Ich habe in der letzten Zeit mal etwas mit meiner Zweit-ECU rumgespielt...und herausgefunden, welche Pins für die Datenübertragung zuständig sind, bzw wichtiger: Die Richtung der Datenübertragung.



    Pin#15 vom ECU Stecker ist der Dateneingang (RxD von der ECU aus) - Kabelfarbe ist schwarz-grün.


    Mit einem 74HC14 (Schmitt Trigger Inverter) wird das Signal zwischengepuffert und etwas "gesäubert".
    Das ist auf dougie's Bild der 40T01 direkt links neben dem Unterdrucksensor.


    Demnach ist Pin#10 der Datenausgang (TxD von der ECU aus gesehen) - Kabelfarbe weiß-gelb.
    Der Ausgang wird mit einem P-MOS Transistor auf 5V geschaltet - das ist der Transistor im SOT223 gehäuse, der bei dougie's Bild fast nicht erkennbar unter dem Unterdrucksensor liegt (Typ BSP205, wie der andere unter dem mysterious Philips chip).
    Auf der Platinenrückseite gibt's noch einen Transistor (oder Klemmdioden) im SOT23 Gehäuse, der den den Datenausgang irgendwie mit Masse verbindet. Allerdings hat dieser Chip ein völlig wirres Verhalten: Es ist weder NPN, noch PNP Transistor - zumindest nicht, wenn er Standard-Belegung hätte. Dann ist zwischen dem MOSFET und dem Pin#10 noch ein 1,3k Widerstand mit einem Kondensator (Kapazität = ??nF) nach Masse geschaltet. Warum dort fast jedes einkommende Signal mit einem Kondensator nach Masse beschaltet ist, ist mir ein Rätsel...
    Es sei denn, diese rosa Pinöppels sind gar keine Kondensatoren...hm.


    Das pink-schwarze Kabel, das auch zu den ganzen Sensoren geht, wird in der ECU auf Masse gelegt - dh, wenn man mit einem Durchgangsprüferr auf Pin#29 und Pin#30 geht, wird's höllisch piepsen.
    Hieran sieht man auch die Wichtigkeit des pink-schwarzen Kabels. Da alle wichtigen, analogen Sensoren über diese Analog-Masse geführt werden, ist es für einen guten Motorlauf sehr wichtig, dass dieses Kabel und dessen Steckverbindung in gutem Zustand sind! Die dort angeschlossenen Sensoren sind: Ansauglufttemperatur, Kühlwassertemperatur, Drosselklappenpotentiometer und auch die Masse für den Diagnosestecker. Nach meinen Erfahrungen beißt sich sowas immer. Dh. man trennt normal die verschiedenen Massen (Analogmasse, Digitalmasse) so lange, wie möglich, um bei der "sensiblen" Analogmasse Digitalsprünge von bspw. Datenleitungen zu vermeiden - naja, wie auch immer...



    Also im Endeffekt geht ECU-Pin#15 auf Pin17 des Intel-Prozessors (=RxD). ECU-Pin#10 geht auf Pin18 des Prozessors (=TxD). Und das war halt der Ausschlag gebende Punkt, warum man die Datenrichtungen so gut zuordnen konnte. Hoffentlich kann's wer gebrauchen.. :)


    Kurze Frage an Klas...wieso denkst Du, dass es gerade der MPX4415 der Sensor aus der ECU ist? Ich frage das deshalb, weil ich sehe, dass die Gehäuse schon unterschiedlich sind.


    MfG
    Hannes

  • ...Es wird Zeit das wir das Thema auch mal wieder nach oben holen und neuerdings gewonnene Informationen hinzufügen.


    Also noch mal zusammengefasst:


    Das Problem der entladenen Batterie rührt davon, das das Hauptrelais in der Relaisbox angezogen bleibt, und dieses somit die Batterie mit ca. 300mA innerhalb von 2 Tagen leersaugt.


    Das das Relais nach Abschalten der Zündung noch eine Weile angezogen bleibt, ist eigentlich völlig korrekt, weil die ECU ev. noch den Lüfter einschalten möchte, falls sich irgendwo ein Hitzestau gebildet hat.


    Eigentlich funktioniert das auch, denn es gibt einen merklichen Unterschied zwischen dem korrekt angesteuerten Relais (Der Relais-Kontakt hält richtig fest) und dem "hängenden" Relais (ein Klopfen auf die Relaisbox reicht mitunter schon, damit das hängende Relais abfällt).


    Das bedeutet, das wahrscheinlich ein Reststrom durch das Relais fliesst. Das werde ich aber noch genauer verifizieren.


    Das Thema ist noch nicht zu Ende!!! Nur vielleicht bis zum Winter zurück gestellt. :D

  • hallo hatt nun eigentlich schon jemand den date austausch mitgeschnitten
    weil dann kömmte mann ja leicht was programieren so in c oder vb ist das ja dann einfach oder?

  • Nope...mangels Testbook sieht das zumindest bei mir schlecht aus.


    Das Problem dürfte aber woanders liegen: Ich habe mal gelesen (frag mich bloß nicht wo), dass dieses "Testbook"-Protokoll neben den Command und Datenabschnitten auch noch eine Art Schlüssel haben. Dh. es wird eine Check-Summe angehängt, deren Inhalt abhängig von vorher übertragenen Daten ist. Und wenn man diesen falsch setzt, dann merkt das der Kommunikationspartner und bricht (wahrscheinlich) ab.


    Kannst Du C(++) oder VB? Könnte in Zukunft vielleicht doch hilfreich sein. :)


    Das eigentliche Datenschnüffeln dürfte sich theoretisch relativ einfach gestalten, weil die beiden Datenpins von dem Stecker über einige Puffer in der ECU direkt auf spezielle RxD/TxD Pins des Intel-Controllers gehen - somit hat man zumindest auf der untersten Ebene schonmal eine klare Struktur: RS232.

  • Auch nope! Leider nein...


    Das Protokoll zwischen ECU und Testbook ist alles andere als RS232. Verwendet wird ein 3-Draht Protokoll mit den Signalen K, L und GND
    Die Signale K & L sind auch noch miteinander verknüpft, wobei L so etwas wie einen Takt vorzugeben scheint.
    Die HP Testkarte im PC ist auch alles andere als "standard" ... ich stell nachher mal ein paar Bilder rein.

  • Oki ich versteh Drei-Draht Protokoll da könnte man ja was mit nem pic oder avr was tüteln
    und das mit der checksum wie könnte mann das lösen ?

  • der hersteller weiß es bestimmt. nur zweifel ich das der was sagen wird, grade bei einem gerät was noch aktiv am markt ist. schließlich kann man das TB noch kaufen

  • ...bei dem abgebildeten Gerät handelt es sich um ein Testbook T3.
    Dieses wird nicht mehr hergestellt und auch nicht mehr supported. Groosses Problem! Ich kämpfe da seit Weihnachten mit...


    Anbei auch mal ein kleiner Einblick in das was da auf den Leitungen abläuft.


    Dies ist das Signal zwischen TestBook und Interface Box (oben K, unten L)
    Kannman so interpretieren, das das testbook via L einen Takt gibt, und die ECU dann antwortet.


    http://www.miniestate.de/testbook/mov00601.mpg


    Und hier noch mal das gleiche zwischen Interface-Box und ECU


    http://www.miniestate.de/testbook/mov00602.mpg

  • gut, beim t3 hast das gleiche problem wie beim microcheck, es gibt keine daten die man haben könnte, teile sowieso nicht mehr, aber man kann gerne ein t4 kaufen ....

  • ...Hersteller des T4 ist die Fa. OMITEC in U.K. ... mit denen hab ich aber schon telefoniert, keine Sorge.


    Quote from k.o23

    Sehe ich das richtig die t3 sendet nen clock signal aul L und K empfängt alle daten die die ecu so weis ?



    Nein. K ist eine Bi-Direktionale Leitung und das Video zeigt nur den idle-Zustand. Vorher geht aber schon was schief, wenn das Testbook versucht den ECU Typ zu ermitteln. Die Signale die da hin und her zischen, sind um ein vielfaches schneller. Ich versuch das in den nächsten Tagen noch mal aufzuzeichnen.


    Das besondere ist übrigens, das diese Probleme nur mit SPI / ECU 1.6 auftreten. Mit MPI oder WFS gibt es keine Probleme.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!