Untersuchung defektes VW Türsteuergerät

[Sebastian W. (wangnick)]

Liebe Leute,

bei unserem T5 von 2007 wurde fahrerseitig das Türsteuergerät 6Y2959802 
getauscht. Fensterheber und Zentralverriegelung funktionieren nun 
wieder. Ich habe das defekte Gerät hier vor mir und würde gerne die 
eigentliche Fehlerursache finden. Anbei Fotos der Platine. Dazu einige 
Fragen:

1. Worum handelt es sich bei dem SOT89-3 IC auf dem zweiten Foto mit der 
Aufschrift "452" und "S6N"? Es sollte wohl ein Hallsensor sein?

2. Um welchen Microcontroller handelt es sich bei dem TQFP32 IC auf dem 
dritten Foto mit dem Logo von Freescale und den Aufschriften "SP100", 
"897VFA", "2L31N" und "CTCTANO703"?

3. Wofür sind wohl diese aufgestellten Blechstreifen zwischen dem Relais 
(ein ACT512) und dem Elko gut?

4. Das vierte Foto zeigt die Zuleitung zu Pin 3 des Hallsensors. Diese 
Zuleitung scheint sich von dem Platinensubstrat gelöst und/oder 
zerbröselt zu haben. Das ist aber sehr schwer zu sehen. Die Zuleitung 
lässt sich mit dem Finger wieder glätten. Es besteht auch nach wie vor 
eine elektrische Verbindung. Könnte dies trotzdem eventuell die 
Fehlerursache sein?

LG, Sebastian

PS: Der SIOCW-32 ist ein MC33689 von Freescale.

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> 2. Um welchen Microcontroller handelt es sich bei dem TQFP32 IC auf dem
> dritten Foto mit dem Logo von Freescale und den Aufschriften "SP100",
> "897VFA", "2L31N" und "CTCTANO703"?

Mask Set "2L31N" sollte ein MC68HC908EY16 oder MC68HC908EY8 sein.

[Heinz R. (heijz)]

Sebastian W. schrieb:
> 3. Wofür sind wohl diese aufgestellten Blechstreifen zwischen dem Relais
> (ein ACT512) und dem Elko gut?

Das sind wohl Mess-Shunts, mit denen wird der Motorstrom gemessen, damit 
der Einklemmschutz realisiert

[Michael W. (miks)]

Sieht (zumindest für mich) so aus, als hätte dieser Kamerad " 'n Loch im 
Kopp"...

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Mask Set "2L31N" sollte ein MC68HC908EY16 oder MC68HC908EY8 sein.
Ok, werde ich mal anhand der Beschaltung überprüfen.

Heinz R. schrieb:
> Das sind wohl Mess-Shunts, mit denen wird der Motorstrom gemessen, damit
> der Einklemmschutz realisiert
Kann wohl sein, liegt dann aber im Milliohmbereich.

Michael W. schrieb:
> Sieht (zumindest für mich) so aus, als hätte dieser Kamerad " 'n Loch im
> Kopp"...
Danke für den Hinweis. Aber auch bei genauerer Betrachtung kann ich kein 
Loch erkennen. Höchstens ganz feine kurze Risse in der Mitte des 
Gehäusedeckels.

LG, Sebastian

[Michael W. (miks)]

Jepp - das war dann eine optische Täuschung. 'In groß' sieht das Bauteil 
unbeschädigt aus. Danke für die Aufklärung.

[H. H. (Gast)]

Dem Marking nach würde ich bei dem Hallsensor auf Infineon tippen.

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Ok, werde ich mal anhand der Beschaltung überprüfen.

Das Pinout des MC68HC908EY16/MC68HC908EY8 sollte zu dem passen was man 
auf dem Bild sieht.

Wenn die Spannungsversorgung in Ordnung ist: schauen ob der 
Mikrocontroller Takt bekommt (das sieht nach Quarz auf dem Bild aus). 
Dann die SPI Signale zum MC33689 auf Aktivität prüfen. Der Hall Sensor 
sollte sich mit einem Magnet testen lassen.

Das wären auf den ersten Blick die einfachsten Prüfungen, wenn das alles 
passt wird es aufwändiger (z.B. selber die SPI Kommunikation zum MC33689 
übernehmen und schauen ob man den Relais schalten kann).

[H. H. (Gast)]

H. H. schrieb:
> Dem Marking nach würde ich bei dem Hallsensor auf Infineon tippen.

Und da ist er ja auch: TLE4945-2G.

[Wollvieh W. (wollvieh)]

Sebastian W. schrieb:
> Heinz R. schrieb:
>> Das sind wohl Mess-Shunts, mit denen wird der Motorstrom gemessen, damit
>> der Einklemmschutz realisiert
> Kann wohl sein, liegt dann aber im Milliohmbereich.

Ohmbereich bei 20 A wäre auch eine blöde Idee. Diese gestanzten Mäander 
sind ebenfalls sehr beliebt in Lichtsteuergeräten für die 
Ausfallerkennung. Jedenfalls in der Vor-LED-Zeit als noch mehrere Ampere 
pro Birne glühten.

Interessant finde ich bei dem vierten Bild (4643) die "Schmauchspur". 
Kenne ich von Klingeldraht als (altes analoges) Telefonkabel, der hat 
über die Jahre durch die dauernd anliegende hohe Spannung Staub 
angezogen. Nur eine der beiden Adern. Aber daß der Effekt auch schon bei 
12V funktioniert erstaunt mich. Theoretisch wäre noch denkbar, daß durch 
das Magnetfeld bei Schaltvorgängen ferromagnetischer Staub besonders 
angezogen wird, aber das scheint mir eher zu weit hergeholt.

[Thomas (kosmos)]

so ein Hallsensor hat normalerweise einen Pullup Widerstand und der 
Transistor zieht das dann runter, könnte sein das der Widerstand und 
dadurch auch der Ausgangstransistor des Hallgebers hops gegangen sind 
und deswegen die Leiterbahn etwas viel Strom abbekommen hat.

[Rüdiger (ruedarno2)]

Hallo,

alles richtig wie bisher erklärt. Ich habe das gleiche Module im 
Roomster.
Problem: Bei Kälte gingen beide Fenster nicht mehr auf. An warmen Tage 
war es wieder möglich. Nun ging gar nichts mehr.
Platine bei 120°C für 30 Minuten in den Ofen gelegt. Dann lief es zwei 
Wochen. Dann ging es wieder nicht mehr. Ich vermute eine kalte 
Lötstelle. Habe keine gefunden. Habe die Rückseite nachgelötet und die 
großen Widerstände. Keine Verbesserung
Hatte nach Anleitung aus Internet YouTube den LIN Baustein ausgetauscht. 
Hat das Problem nicht behoben.
Gestern wieder in Ofen gelegt. Bei 130°C eine Stunde. Geht wieder. Mal 
sehen.

Bei YouTube ist der Film von Mr. Selfmaker zu Roomster sehenswert:
https://youtu.be/1EP5U9uHmy0
sehenswert.

Das Relais ist es bei mir nicht. Der Hallsensor auch nicht, weil beide 
Fenster nicht gehen.

Wer bei sich es das gleiche (Kälte-) Problem hat und die Lösung oder das 
Defekte Teil gefunden hat, bitte melden. Ich vermute es muss die 
LIN-Leitung sein, weil bei meinen Defekt beide Fenster nicht mehr gehen.

Viele Grüße

[Wf88 (wf88)]

Mit 120-130° wird das Lot nicht weich und du Quälst  nur sinnlos die 
Hardware.

[Rüdiger (ruedarno2)]

Ja, das stimmt, wobei 105°C für Autoelektronik meist zum Operating Range 
gehört. Und es ist keine Lösung. Allerdings ein Beitrag zur 
Lösungsfindung.

[Rüdiger (ruedarno2)]

Hier noch ein Film, der mit Kältespray und Föhn den uC als empfindliche 
Stelle identifiziert.

https://youtu.be/ZlExAJYp2x4

[Matthias B. (turboholics)]

Wenn nur dir Fensterheber nicht mehr gehen, könnten auch die 
Fensterheberschalter hin sein/kalte Lötstellen haben.
Mal testen, ob die Fenster noch per FFB öffnen/schließen.

VG

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Das Pinout des MC68HC908EY16/MC68HC908EY8 sollte zu dem passen was man
> auf dem Bild sieht.
>
> Wenn die Spannungsversorgung in Ordnung ist: schauen ob der
> Mikrocontroller Takt bekommt (das sieht nach Quarz auf dem Bild aus).
> Dann die SPI Signale zum MC33689 auf Aktivität prüfen. Der Hall Sensor
> sollte sich mit einem Magnet testen lassen.
>
> Das wären auf den ersten Blick die einfachsten Prüfungen, wenn das alles
> passt wird es aufwändiger (z.B. selber die SPI Kommunikation zum MC33689
> übernehmen und schauen ob man den Relais schalten kann).

Zur Zeit versuche ich herauszubekommen wie die digitale Kommunikation 
mit diesen Steuergeräten funktioniert. Das mir vorliegende Steuergerät 
der Fahrertür benutzt ja den LIN-Bus zur Kommunikation mit dem 
Steuergerät der Beifahrertür. Aber wer von beiden ist der Master? Und 
sind die beiden Steuergeräte digital autonom, oder kommunizieren sie 
auch noch mit dem Bordsteuergerät oder dem Komfortsteuergerät? Ich habe 
mich jetzt im tx-board.de angemeldet (und einen Beitrag dort eröffnet, 
siehe 
https://tx-board.de/threads/t5-1-buseinbindung-tuersteuergeraete.156611/), 
und auch über erwin.volkswagen.de die Stromlaufpläne heruntergeladen, 
bin aber immer noch mehr oder weniger so schlau wie zuvor ...

LG, Sebastian

[Matthias B. (turboholics)]

Ist doch gut zu erkennen:

Gilt für Transporter, Multivan evtl anders!:

Beide Fensterhebermotoren reden über LIN miteinander, vmtl zur Steuerung 
des rechten Motors von der Fahrertür aus.
Zusätzlich hängt noch jede Tür am Komfortsteuergerät, das steuert dann 
"Fenster auf/zu per FFB" und die ZV-Funktionen.

VG

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Zur Zeit versuche ich herauszubekommen wie die digitale Kommunikation
> mit diesen Steuergeräten funktioniert.

Weißt Du schon ob der Mikrocontroller noch funktioniert? Wenn Du mit dem 
LIN Bus experimentieren willst muß zusätzlich auch noch der LIN 
Transceiver im MC33689 funktionieren.

Je nach dem wie einfach man an den LIN Bus im Fahrzeug herankommt kannst 
Du dort mitschneiden was passiert wenn man die Fensterheber betätigt und 
dann schauen wie das Steuergerät darauf reagiert.

Diagnose per LIN Bus zu den Türsteuergeräten gibt es wahrscheinlich 
auch, das könnte man ebenfalls mitschneiden.

[Ge L. (Gast)]

Rüdiger schrieb:
> Hier noch ein Film, der mit Kältespray und Föhn den uC als empfindliche
> Stelle identifiziert.
>
> https://youtu.be/ZlExAJYp2x4

Ein alter Freesscale HC08 mit internem EEPROM? Einmal über BDM auslesen 
und neu schreiben, also die Zellen refreshen.

[Dieter S. (ds1)]

Soul E. schrieb:
>
> Ein alter Freesscale HC08 mit internem EEPROM? Einmal über BDM auslesen
> und neu schreiben, also die Zellen refreshen.

Der MC68HC908EY16/8 hat noch kein BDM, das Monitor Module (MON) wäre 
aber vorhanden (falls nicht gesperrt).

[Rüdiger (ruedarno2)]

Sebastian W. schrieb:
> Dieter S. schrieb:
 kann).

> Zur Zeit versuche ich herauszubekommen wie die digitale Kommunikation
> mit diesen Steuergeräten funktioniert. Das mir vorliegende Steuergerät
> der Fahrertür benutzt ja den LIN-Bus zur Kommunikation mit dem
> Steuergerät der Beifahrertür. Aber wer von beiden ist der Master?
...
>
> LG, Sebastian

Hallo Sebastian,

das Steuergerät der linken Seite müsste der Master sein. Es hat den für 
den Master vorgeschriebene Pullup Widerstand von 1kOhm,als 
Parallelschaltung von zwei parallelen 2kOhm Widerständen.
Daher findet wohl auch keine Kommunikation mit der ECU statt, weil diese 
der Master wäre und nicht das Steuergerät in der linken Tür. Es scheint 
also ein autonomer LIN Bus zu sein zwischen den Türen zu sein. Über den 
Diagnose-Stecker des Roomster lässt sich bei mir keine Information über 
die Fensterheber-Steuergeräte auslesen.

Viele Grüße Rüdiger

[Sebastian W. (wangnick)]

Rüdiger schrieb:
> Das Relais ist es bei mir nicht. Der Hallsensor auch nicht, weil beide
> Fenster nicht gehen.
So war es bei uns auch. Nach dem Tausch des fahrerseitigen 
Türsteuergeräts ging auch die Beifahrerseite wieder.

H. H. schrieb:
> Und da ist er ja auch: TLE4945-2G.
Danke, das passt!

Wollvieh W. schrieb:
> Interessant finde ich bei dem vierten Bild (4643) die "Schmauchspur".
Thomas O. schrieb:
> und deswegen die Leiterbahn etwas viel Strom abbekommen hat.
Ja, seltsam. Die Leitung ist die Spannungsversorgung des Hallsensors. 
Strom sollte da nur minimal fließen.

Rüdiger schrieb:
> Hier noch ein Film, der mit Kältespray und Föhn den uC als empfindliche
> Stelle identifiziert.
Ok ...

Matthias B. schrieb:
> Zusätzlich hängt noch jede Tür am Komfortsteuergerät, das steuert dann
> "Fenster auf/zu per FFB" und die ZV-Funktionen.
Rüdiger schrieb:
> das Steuergerät der linken Seite müsste der Master sein. Es hat den für
> den Master vorgeschriebene Pullup Widerstand von 1kOhm,als
> Parallelschaltung von zwei parallelen 2kOhm Widerständen.
> Daher findet wohl auch keine Kommunikation mit der ECU statt, weil diese
> der Master wäre und nicht das Steuergerät in der linken Tür. Es scheint
> also ein autonomer LIN Bus nur zwischen den Türen zu sein.
Ich denke Rüdiger hat hier recht. Der uC kann kein CAN, und der 
(einzige) LIN-Bus geht nur zur anderen Tür, nicht zum 
Komfortsteuergerät. Man kann mit der FFB auch glaube ich die Fenster 
nicht schließen -- das werde ich aber noch überprüfen.

Dieter S. schrieb:
> Das Pinout des MC68HC908EY16/MC68HC908EY8 sollte zu dem passen was man
> auf dem Bild sieht.
>
> Wenn die Spannungsversorgung in Ordnung ist: schauen ob der
> Mikrocontroller Takt bekommt (das sieht nach Quarz auf dem Bild aus).
> Dann die SPI Signale zum MC33689 auf Aktivität prüfen. Der Hall Sensor
> sollte sich mit einem Magnet testen lassen.
>
> Das wären auf den ersten Blick die einfachsten Prüfungen, wenn das alles
> passt wird es aufwändiger (z.B. selber die SPI Kommunikation zum MC33689
> übernehmen und schauen ob man den Relais schalten kann).

Ich habe das Steuergerät jetzt mal mit +12V Spannung versorgt, und sehe 
jetzt auf dem LIN-Bus Stecker Datenübertragung mit 19280 Baud:

0ms: LIN-Bus wird rezessiv (12V)
110ms: Master sendet (A) Wake-up (413us, 8 Bitzeiten dominant 0.85V)
130ms: Master sendet (B) ID 0x26 Data 0x00 0x00 0x40 0x00 ChecksumClassic 0xBF
145ms: Master sendet (C) ID 0x13, keine Antwort
230ms, und dann weiter alle 100ms: Master sendet (B)
345ms, und dann weiter alle 200ms: Master sendet (C)

Sowohl uC als auch MC33689 scheinen also zu funktionieren.

LG, Sebastian

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Sowohl uC als auch MC33689 scheinen also zu funktionieren.
>

Ob die Ansteuerung des Relais funktioniert ist noch nicht klar, das 
macht ebenfalls der MC33689. Der kann auch noch Eingangssignale (Tasten) 
auswerten.

Wohin geht denn das Signal des Hall-Sensor? Eventuell mit einem Magnet 
prüfen ob sich das Signal ändert.

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Der kann auch noch Eingangssignale (Tasten) auswerten.

Der MC33689 wertet an L1 die Plusspannung auf T6ca/2 aus.

T8h/4 (der Türkontakt Fahrerseite) wird nach einer Schutzbeschaltung vom 
uC an Pin 1 (PTA2) ausgewertet. Wenn ich T8h/4 mit Masse verbinde, 
ändert sich (B) in ID 0x26 Data 0x08 0x00 0x40 0x00 ChecksumClassic 
0xB7.

Die anderen drei Eingänge (T8h/5 für F220 "zu" und F241 "auf" der 
Schließeinheit, T8h/7 für den Fensterheberschalter E81, und T6ca/1 für 
den Fensterheberschalter E40) müssen Pegel auswerten, da die Taster mit 
verschiedenen Widerständen für verschiedene Kippzustände arbeiten. Dass 
wird dann auch eher eine Aufgabe für den uC sein. Ich bin aber noch 
dabei den Schaltplan der Platine vollständig zu rekonstruieren.

Dieter S. schrieb:
> Ob die Ansteuerung des Relais funktioniert ist noch nicht klar, das
> macht ebenfalls der MC33689.
> Wohin geht denn das Signal des Hall-Sensor? Eventuell mit einem Magnet
> prüfen ob sich das Signal ändert.

Werd ich auch noch prüfen.

LG, Sebastian

[Rüdiger (ruedarno2)]

Hallo Sebastian,

mir fehlt bei Deinem ersten Beitrag die genauer Beschreibung des 
Fehlerbildes.
Gingen beide Fenster nicht mehr auf und zu oder nur das Linke. Trat die 
Fehlfunktion langsam auf, oder plötzlich 100% Ausfall. War es 
Temperaturabhängig?

Die Teilebezeichnung
6Y2959802
beinhaltet sowohl Platine als auch den Motor. Wurden also der Motor 
zusammen mit der Platine ausgetauscht?
Vielleicht ist auch nur der Motor kaputt, z.B. durch verklemmte oder 
verschmutzte Kohlebürsten und die Elektronik funktioniert.

Viele Grüße
Rüdiger

[Sebastian W. (wangnick)]

Rüdiger schrieb:
> mir fehlt bei Deinem ersten Beitrag die genauer Beschreibung des
> Fehlerbildes.
> Gingen beide Fenster nicht mehr auf und zu oder nur das Linke. Trat die
> Fehlfunktion langsam auf, oder plötzlich 100% Ausfall. War es
> Temperaturabhängig?

Beide Fenster liessen sich plötzlich nicht mehr bedienen. Keine 
Temperaturabhängigkeit.

> Die Teilebezeichnung
> 6Y2959802
> beinhaltet sowohl Platine als auch den Motor. Wurden also der Motor
> zusammen mit der Platine ausgetauscht?
> Vielleicht ist auch nur der Motor kaputt, z.B. durch verklemmte oder
> verschmutzte Kohlebürsten und die Elektronik funktioniert.

Motor und Platine wurden als ein Ersatzteil getauscht. Der Motor des 
"defekten" Geräts funktioniert am Labornetzteil.

Ich habe jetzt mit einem 4k7-Poti zwischen T6ca/1 und T8h/6 den 
Fensterheberschalter vorne links emuliert. Wenn ich die Platine ohne den 
Motor betreibe, dann schalten die Relais dabei auch beide, und die 
LIN-Bus-Nachrichten (B) ändern sich. Allerdings endet der Schaltvorgang 
immer nach 150ms, wohl weil der Hallsensor keine Bewegung und der Shunt 
keinen Stromfluß meldet. Wenn ich die Platine mit dem Motor betreibe, 
dann bricht mir die Versorgungsspannung meines Labornetzteils (max. 5A) 
durch den Motoranlaufstrom innerhalb 1ms auf 1.5V ein und das 
Steuergerät startet neu. Morgen sollte ich ein stärkeres 12V-Netzteil 
erhalten, dann teste ich weiter ...

LG, Sebastian

[Sebastian W. (wangnick)]

Sebastian W. schrieb:
> Morgen sollte ich ein stärkeres 12V-Netzteil
> erhalten, dann teste ich weiter ...

Ok, ich teste jetzt mit einem 12V/30A Netzteil.

Der Eingang T6ca/1 wird über den Fensterheberschalter vorne links E40 
direkt bzw. über drei verschiedene Widerstände mit T8h/6 (GND) 
verbunden, und die Emulation mit einem 4k7-Poti bringt den Motor auch 
entsprechend zum laufen.

Der Motor scheint so 15A Anlaufstrom zu ziehen, bevor er (mechanisch 
unbelastet) mit 2.7A vor sich hinläuft. Passt zur Sicherung S37 mit 30A.

Auf dem LIN-Bus ändern sich während der Betätigung die Nachrichten an ID 
0x26 von 0x00 0x00 0x40 0x00 auf 0x00 0x01 0x40 0x00, 0x00 0x05 0x40 
0x00, 0x00 0x02 0x40 0x00 bzw. 0x00 0x06 0x40 0x00.

Klemme ich das Poti zwischen T8h/7 und T8h/6, um den 
Fensterheberschalter in der Fahrertür für das Beifahrerfenster zu 
emulieren, ändern sich die Nachrichten an ID 0x26 auf 0x00 0x08 0x40 
0x00, 0x00 0x28 0x40 0x00, 0x00 0x10 0x40 0x00 bzw. 0x00 0x30 0x40 0x00.

Auch die Eingänge T8h/5 (F220/F241) und T8h/4 (F2) scheinen zu 
funktionieren, und ändern weitere Bits in den LIN-Nachrichten an ID 
0x26.

Lege ich +12V an T6ca/2, so ändern sich wiederum weitere Bits in den 
0x26-Nachrichten. Zusätzlich fängt das Steuergerät an, LIN-Nachrichten 
an die ID 0x3C zu senden, und Nachrichten von ID 0x3D zu erfragen.

Wollvieh W. schrieb:
> der hat über die Jahre durch die dauernd anliegende hohe Spannung Staub
> angezogen. Nur eine der beiden Adern. Aber daß der Effekt auch schon bei
> 12V funktioniert erstaunt mich.

Dabei scheint es sich um Abrieb der Motorkohlen zu handeln.

Sebastian W. schrieb:
> Ich habe das defekte Gerät hier vor mir und würde gerne die
> eigentliche Fehlerursache finden.

Tja. Mir scheint das Gerät gar nicht defekt zu sein. Ich könnte die ICs 
noch mit Heißluft nachlöten. Ansonsten bleibt wohl nur die Hoffnung, 
dass der Fehler nicht an den Kabelverbindungen im Auto lag und also mit 
dem Ersatzteil nicht erneut auftritt ...

LG, Sebastian

[Ge L. (Gast)]

Sebastian W. schrieb:

> Tja. Mir scheint das Gerät gar nicht defekt zu sein. Ich könnte die ICs
> noch mit Heißluft nachlöten. Ansonsten bleibt wohl nur die Hoffnung,
> dass der Fehler nicht an den Kabelverbindungen im Auto lag und also mit
> dem Ersatzteil nicht erneut auftritt ...

Auch das wäre nicht unüblich. Ein großer Teil der Elektronikfehler im 
Auto sind Steckerfehler (Reibkorrosion). Einmal abziehen und wieder 
draufstecken behebt das Problem. Abziehen, Steuergerät tauschen und 
wieder einbauen natürlich auch.

Wenn Du noch an das Auto drankommst, kannst Du das alte Teil ja nochmal 
einbauen.

[Andreas B. (buyman)]

Die Kabel in der Fahrertür sind ein heißer Tipp für einen Kabelbruch - 
ist auch rel. einfach zu beheben. Ich würde als erstes dort zu suchen 
beginnen.

[Icke ®. (49636b65)]

Rüdiger schrieb:
> Wer bei sich es das gleiche (Kälte-) Problem hat und die Lösung oder das
> Defekte Teil gefunden hat, bitte melden.

Scheint eine VW-Krankheit zu sein, die sich durch alle Typenreihen 
zieht. Bei mir war es vor ~10 Jahren das Komfortsteuergerät:

Beitrag "Tips für Reparatur von VW Komfortsteuergerät?"

Ich konnte den eigentlichen Fehler nicht wirklich identifizieren, aber 
er trat danach nie wieder auf.

[Sebastian W. (wangnick)]

Eine Kabelverbindung, die ich bisher gar nicht verstehe, ist die 
zwischen dem Türsteuergerät J386 an T8h/8 und dem Komfortsteuergerät 
J393 an T23/6.

Auf dem Türsteuergerät ist diese Verbindung zum einen über einen 
Spannungsteiler mit B5/AD5 des Mikrocontroller verbunden, und zwar T8h/8 
- 100k - B5/AD5 - 33k - GND.

Zusätzlich ist T8h/8 aber noch über eine etwas aufwändigere Verschaltung 
aus drei SOT23, einen SOT89, zwei MELFs und zwei Widerständen mit C2 und 
A0 des Mikrocontrollers verbunden.

Anbei der Schaltungsausschnitt. G bedeutet GND, T sind nur Testpunkte.

Kann irgendwer die drei SOT23, den SOT89 und die zwei MELF 
identifizieren, um dem Sinn dieser Schaltung auf die Spur zu kommen?

LG, Sebastian

[H. H. (Gast)]

"BM"= BCX55-16 von Infineon.

"WC"= BCR133 von Infineon.

"A7"= BAV99W von Infineon.

"1B"= ???2222 von Onsemi.

Und die Melfs sind 360 Ohm 1% Widerstände.

[Sebastian W. (wangnick)]

H. H. schrieb:
> "BM"= BCX55-16 von Infineon.
> "WC"= BCR133 von Infineon.
> "A7"= BAV99W von Infineon.
> "1B"= ???2222 von Onsemi.
> Und die Melfs sind 360 Ohm 1% Widerstände.

¡Muchas gracias, señor! Also drei NPN und eine Schutzdiode gegen 
negative Spannung ...

LG, Sebastian

[H. H. (Gast)]

H. H. schrieb:
> "1B"= ???2222 von Onsemi.

Da lag ich daneben, es ist ein BC846B von Onsemi.

[Sebastian W. (wangnick)]

H. H. schrieb:
> Da lag ich daneben, es ist ein BC846B von Onsemi.
Ist aber auch ein NPN.

Also: B5 ist ein uC-Eingang für die Spannung an T8h/8. A0 ist ein 
uC-Ausgang und zieht T8h/8 über 180R auf GND.

Aber was macht C2 und die Schaltung aus BC846B, BCX55-16, 3k3, 10k und 
10R? C2 scheint ja auch ein uC-Ausgang zu sein. Aktiviert C2 einen 
Konstantstrom zu GND?

LG, Sebastian

[H. H. (Gast)]

Sebastian W. schrieb:
> Aber was macht C2 und die Schaltung aus BC846B, BCX55-16, 3k3, 10k und
> 10R?

Schaltplan zeichnen!

[Sebastian W. (wangnick)]

H. H. schrieb:
> Schaltplan zeichnen!

C2, B5 und A0 sind alles Ports des M68HC908EY Mikrocontrollers.

Aber was genau bewirkt C2 bei dieser Schaltung ... ?

LG, Sebastian

[Dieter S. (ds1)]

Sebastian W. schrieb:
> Eine Kabelverbindung, die ich bisher gar nicht verstehe, ist die
> zwischen dem Türsteuergerät J386 an T8h/8 und dem Komfortsteuergerät
> J393 an T23/6.
>

Wenn ich es richtig sehe (Siehe Bild) gibt es Varianten des T5 bei denen 
an T23/6 von J393 die "Auf" und "Zu" Schalter liegen (Unterscheidung per 
Widerstand). Eventuell wird ja genau das über die Schaltung 
nachgebildet.

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Wenn ich es richtig sehe (Siehe Bild) gibt es Varianten des T5 bei denen
> an T23/6 von J393 die "Auf" und "Zu" Schalter liegen (Unterscheidung per
> Widerstand). Eventuell wird ja genau das über die Schaltung
> nachgebildet.

Das könnte sein. Gute Idee! Das Auf- und Zuschließen der Fahrertür muss 
ja irgendwie an ein CAN-fähiges Steuergerät übermittelt werden.

B5 würde dann zur Erkennung der Steuerspannung von J393 dienen, A0 würde 
die Betätigung von F220 "Auf" über den 180R-Widerstand signalisieren, 
und C2 müsste dann die Betätigung von F241 "Zu" als Schaltverbindung zu 
GND emulieren. Tut C2 das in dieser Schaltung?

Mein Steuergerät übernimmt ja die Türschlossüberwachung insofern, als 
bei meiner T5-Variante F220 als direkter Schalter, und F241 als Schalter 
mit Widerstand, zwischen T8h/5 und GND (T8h/1) verbunden ist.

Ich werde also erstens mal die Schaltschwelle an T8h/5 auf einen 
möglichen Widerstandswert von 180R untersuchen. Und zweitens werde ich 
mal 12V über einen Pullup-Widerstand an T8h/8 anlegen und schauen, ob 
das Steuergerät bei Simulation von "Auf" oder "Zu" an T8h/5 diese 
Zustände an T8h/8 "weiterreicht".

LG, Sebastian

[Sebastian W. (wangnick)]

Sebastian W. schrieb:
> Tut C2 das in dieser Schaltung?

Die Schaltung scheint tatsächlich bei C2 High T8h/8 relativ niederohmig 
auf GND zu ziehen, dabei aber den maximalen Strom auf 70mA zu begrenzen.

LG, Sebastian

[Sebastian W. (wangnick)]

Sebastian W. schrieb:
> Und zweitens werde ich
> mal 12V über einen Pullup-Widerstand an T8h/8 anlegen und schauen, ob
> das Steuergerät bei Simulation von "Auf" oder "Zu" an T8h/5 diese
> Zustände an T8h/8 "weiterreicht".

Tatsächlich scheint, bei Vorhandensein eines 12V-Pegels an T8h/8 über 
einen 2k2 Pullup, mein Steuergerät das Türschloss-Signal von T8h/5 an 
T8h/8 weiterzuleiten.

LG, Sebastian

[Dieter S. (ds1)]

Jetzt fehlt noch ein Dump der Firmware, wenn der Chip nicht gelockt ist 
sollte das per MON (Monitor Module) machbar sein. Dann kann man sich 
genau ansehen was alles gemacht wird.

[Sebastian W. (wangnick)]

Sebastian W. schrieb:
> Tatsächlich scheint, bei Vorhandensein eines 12V-Pegels an T8h/8 über
> einen 2k2 Pullup, mein Steuergerät das Türschloss-Signal von T8h/5 an
> T8h/8 weiterzuleiten.

Anbei die Messungen.

Noch nicht ganz klar ist mir der Pegel von 2.2V an T8h/5 bei Verbindung 
über 180 Ohm zu GND. Wenn dort also 12mA fließen, dann ergibt sich für 
den Spannungsabfall zwischen den internen 12V (eigentlich 11.3V der 
Verpolschutzdiode wegen) und diesen 2.2V ein Widerstand von 760 Ohm. Die 
Schaltung benutzt aber einen Pullup-Widerstand von 2k ... ?

LG, Sebastian

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Jetzt fehlt noch ein Dump der Firmware, wenn der Chip nicht gelockt ist
> sollte das per MON (Monitor Module) machbar sein. Dann kann man sich
> genau ansehen was alles gemacht wird.

Da muss ich mich erst einmal einarbeiten. Aber ein Dump und 
anschließender Re-Flash soll ja verjüngend wirken.

Also, wenn ich es richtig verstehe, dann wird !IRQ vom MC33689 über 3k3 
auf 5V gezogen. Also sollte ich A1 über 10k auf GND legen, und dann kann 
ich nach einem Reset über A0 und einen USB-TTL-Wandler irgendwie mit dem 
Prozessor im "Forced Monitor Mode" kommunizieren?

LG, Sebastian

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Also, wenn ich es richtig verstehe, dann wird !IRQ vom MC33689 über 3k3
> auf 5V gezogen. Also sollte ich A1 über 10k auf GND legen, und dann kann
> ich nach einem Reset über A0 und einen USB-TTL-Wandler irgendwie mit dem
> Prozessor im "Forced Monitor Mode" kommunizieren?

"Forced Monitor Mode" passiert ja nur wenn der Chip noch nicht 
programmiert ist (Reset-Vector 0xFFFF). Wenn er schon programmiert ist 
muss IRQ auf 9 Volt (V TST) um in den Monitor Mode zu kommen. Falls IRQ 
mit dem MC33689 verbunden ist wird man die Verbindung vorher auftrennen 
müssen.

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Falls IRQ mit dem MC33689 verbunden ist wird man die Verbindung vorher
> auftrennen müssen.

Ok. Das 1mA durch die Schutzdiode wird den 33689 wohl nicht kratzen, 
aber warum nicht den 3k3 sicherheitshalber vorher auslöten.

Aber brauche ich, bevor ich den Flash auslesen kann, dann nicht auch 
noch diese 8 Sicherheitsbytes? Oder ist das bei dem Mikrocontroller 
optional? Im Datenblatt zumindest hab ich keinen Weg drumherum gefunden 
...

LG, Sebastian

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Aber brauche ich, bevor ich den Flash auslesen kann, dann nicht auch
> noch diese 8 Sicherheitsbytes? Oder ist das bei dem Mikrocontroller
> optional? Im Datenblatt zumindest hab ich keinen Weg drumherum gefunden
> ...

Wenn die Security Bytes programmiert sind ist das Auslesen gesperrt 
falls man deren Wert nicht kennt. Die Frage ist ob man sich an die 
Empfehlung im Datenblatt gehalten hat und die Security Bytes gesetzt 
hat, sonst sind diese Bytes leer (0xFF).

Es kommt darauf an ob Du noch weiter mit dem Steuergerät experimentieren 
möchtest, dann könnte man schauen ob der Monitor Mode Zugriff auf den 
Flash erlaubt. Ansonsten ist das eher Spielerei, die Firmware scheint ja 
zu funktionieren. Da der MC68HC908EY16/MC68HC908EY8 keinen internen 
EEPROM hat sehe ich auch keine Notwendigkeit den Chip neu zu 
programmieren, es wird im Betrieb ja nichts in den Flash geschrieben 
wodurch eventuell die Haltbarkeit der Daten beeinträchtigt wird.

Nachtrag: ich sehe gerade dass sich der Flash des 
MC68HC908EY16/MC68HC908EY8 im Betrieb programmieren läßt. Daß das 
gemacht wird halte ich aber für eher unwahrscheinlich. Da das 
Steuergerät nicht per Diagnose zu erreichen ist gibt es eigentlich 
keinen Grund im Betrieb regelmäßig irgendetwas abzuspeichern.

[Dieter S. (ds1)]

Was anderes: Welche Teilenummern stehen denn auf dem Steuergerät (das 
können mehrere sein, z.B. Hardware und Software)?

Ich frage weil man bei VW die Software teilweise findet, wobei ich aber 
bei einem Steuergerät, daß nicht per Diagnose erreichbar ist, eher nicht 
davon ausgehe.

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> im Betrieb regelmäßig irgendetwas abzuspeichern.

Das Gerät "lernt" die Öffnungs- und Schließwege. Die müssen aber nach 
Ausfall der Batterie neu angelernt werden, werden also eher nicht im 
Flash gespeichert.

Dennoch kann ich es ja mal bezeiten mit 8*0xFF versuchen ...

LG, Sebastian

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Was anderes: Welche Teilenummern stehen denn auf dem Steuergerät (das
> können mehrere sein, z.B. Hardware und Software)?

Bild anbei.

LG, Sebastian

[Dieter S. (ds1)]

Software dazu konnte ich keine finden. Das war eigentlich zu erwarten, 
wenn das Steuergerät nicht per Diagnose zu erreichen ist kann man auch 
nicht auf diesem Weg neue Software aufspielen und die Software wird 
nicht veröffentlicht.

Nochmal zu den Security Bytes: Ich nehme an daß selbst dann, wenn nicht 
explizit wegen der Flash-Security dort Werte gesetzt wurden, nicht alle 
acht Bytes 0xFF sein werden. Die Bytes 0xFFF6–0xFFFD enthalten ja auch 
Interrupt Vektoren. Alle davon sind vermutlich nicht belegt aber selbst 
wenn es nur einer im Bereich der Security Bytes ist kommt man nicht mehr 
ohne weiteres an den Inhalt des Flash.

Was aber dennoch geht wenn man damit herumspielen will: Man kann Code in 
den RAM laden und ausführen. Damit könnte man z.B. per SPI den Relais 
schalten (über den  MC33689). Inwieweit das Sinn macht ist eine andere 
Frage, das funktioniert ja bei Deinem Gerät.

Wenn man mit dem Monitor Mode experimentieren will sollte man den 
Watchdog des MC33689 deaktivieren damit man nicht ständig einen Reset 
bekommt.

[Frank O. (frank_o)]

Vielleicht ist ein Defekt auch "programmiert"?
Erfahrungsgemäß, und ich mache schon seit 35  Jahren Fahrzeugtechnik, 
ist da eher alles was mechanisch bewegt wird, kaputt.
Ganz vorne Schalter, dann Kabel, Motoren (gerade bei mit der Zeit immer 
schwerer gehenden Fensterhebern). Wenn was an den Steuerungen kaputt 
ist, dann oft Leistungsteile und das sieht und riecht man dann.

Als ich mit Mikrocontrollern und richtiger Elektronik angefangen habe, 
hatte ich im  Anfang auch schon mal hier und da, einen einfachen Fehler 
verkompliziert.

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Der Motor scheint so 15A Anlaufstrom zu ziehen, bevor er (mechanisch
> unbelastet) mit 2.7A vor sich hinläuft. Passt zur Sicherung S37 mit 30A.
>
Ich habe ein sehr ähnliches Steuergerät aus einem Polo von 2006 in die 
Hände bekommen (siehe Bilder, Einbauort hinten rechts).

Bei dem ist der Anlaufstrom des Motor unter 5 Ampere (die 
Strombegrenzung eines 5 Ampere Netzteil spricht nicht an) und der Motor 
zieht im Leerlauf 1.6 Ampere.

Ich weiß nicht ob die Motoren so unterschiedlich sind oder ob das 
eventuell etwas mit dem ursprünglichen Problem zu tun haben könnte.

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Ich weiß nicht ob die Motoren so unterschiedlich sind oder ob das
> eventuell etwas mit dem ursprünglichen Problem zu tun haben könnte.

Mmh. Ich messe bei meinem Motor 0,45Ω von einer Seite des Kommutators 
zur anderen, und 0,5Ω von Kontaktblech zu Kontaktblech. Er läuft bei 1V 
an, und zieht im Stillstand bei 0.9V 1.6A. Beim Anlauf mit 12V regelt 
mein LNT bei 5.1V kurz ab, im laufenden Betrieb mit Getriebe aber ohne 
Last am Zahnrad sind es 2.5A. Den Anlaufstrom von 15A habe ich als 
Spannungsabfall über einem 100mΩ-Widerstand gemessen (Stromversorgung 
war hierbei ein 12V/30A Noname-Netzteil). Kommutator und Bürsten sind 
mit Druckluft und Iso von Kohlenstaub und Fett gereinigt.

Vielleicht hat dein Motor trotz gleicher Abmessungen eine andere 
Wicklung mit weniger Stromaufnahme?

Und, obwohl das PCB gleich zu sein scheint, unterscheidet sich die 
Bestückung deiner Platine in einigen Punkten. Die drei 2201-Widerstände 
fehlen, von den drei 1601-Widerständen fehlt der mittlere, und auch die 
Schaltung zur Türschloßemulation auf T8h/8 scheint zu fehlen.

Ist denn die Typbezeichnung dieselbe?

LG, Sebastian

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Und, obwohl das PCB gleich zu sein scheint, unterscheidet sich die
> Bestückung deiner Platine in einigen Punkten. Die drei 2201-Widerstände
> fehlen, von den drei 1601-Widerständen fehlt der mittlere, und auch die
> Schaltung zur Türschloßemulation auf T8h/8 scheint zu fehlen.

Das Teil ist ein LIN Slave und empfängt vermutlich nur die Fenster 
hoch/runter Kommandos (die kennen ich allerdings noch nicht). Es fehlt 
außerdem der Quarz, für den LIN Slave reicht vermutlich der interne 
Oszillator (ICG) des MC68HC908EY. Nur die Tasten (kodiert per 
Widerstand) und der Türkontakt sowie LIN ist am Stecker belegt.

> Ist denn die Typbezeichnung dieselbe?

Die Teilenummer ist 6Y0959812.

Ich denke daß auch bei Dir die Platinen der anderen Fensterheber 
Unterschiede zum ersten Bild (20230515_215134_small.jpg) haben werden.

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Das Teil ist ein LIN Slave und empfängt vermutlich nur die Fenster
> hoch/runter Kommandos (die kennen ich allerdings noch nicht). Es fehlt
> außerdem der Quarz, für den LIN Slave reicht vermutlich der interne
> Oszillator (ICG) des MC68HC908EY. Nur die Tasten (kodiert per
> Widerstand) und der Türkontakt sowie LIN ist am Stecker belegt.

Ah ja, klar. Hinten sind ja auch keine Türschlösser ...

Spannend wäre für mich noch ein Vergleich der Motoren. Es kann natürlich 
sein, dass bei mir ein Wicklungsschluß die Stromaufnahme leistungslos 
erhöht. Allerdings sind die Türfenster des T5 schon schwerer als die 
hinteren Türfenster des Polo ...

LG, Sebastian

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Spannend wäre für mich noch ein Vergleich der Motoren.

6Y0959812 bekommt man gebraucht recht günstig (unter EUR 20).

Zu den LIN Messages: Der LIN Slave reagiert auf Bits im ersten Byte der 
ID 0x26 und schaltet den Motor. Auf den Request mit ID 0x15 liefert er 
zwei Bytes die normalerweise beide 0x00 sind, im ersten Byte sind bei 
Schalterbetätigung Bits gesetzt.

Nachtrag: Der LIN Slave reagiert auch auf ID 0x3C/0x3D, also Diagnose 
über LIN. Ich werde mal sehen welche SIDs unterstützt werden.

[Sebastian W. (wangnick)]

Dieter S. schrieb:
> Zu den LIN Messages: Der LIN Slave reagiert auf Bits im ersten Byte der
> ID 0x26 und schaltet den Motor. Auf den Request mit ID 0x15 liefert er
> zwei Bytes die normalerweise beide 0x00 sind, im ersten Byte sind bei
> Schalterbetätigung Bits gesetzt.
>
> Nachtrag: Der LIN Slave reagiert auch auf ID 0x3C/0x3D, also Diagnose
> über LIN. Ich werde mal sehen welche SIDs unterstützt werden.

Interessant. Mein LIN Mastergerät aus der Fahrertür verschickt ID 0x26 
mit 4 Bytes. Dabei wird der Fensterheberschalter E40 (in Fahrertür für 
Fenster vorne links) mit 0x01, 0x05, 0x02 bzw. 0x06 im zweiten Byte 
kodiert, der Fensterheberschalter E81 (in Fahrertür für Fenster vorne 
rechts) mit 0x08, 0x28, 0x10 bzw. 0x30 im zweiten Byte, die 
Türschloßkontakte mit 0x10, 0x14, 0x20 bzw. 0x22 im ersten Byte, der 
Türkontakt mit 0x08 im ersten Byte, und die Spannungsversorgung R82 an 
T6ca/2 über 0x40 bzw. 0x41 im ersten Byte.

Auf welche Bits im ersten Byte reagiert denn dein LIN Slave hinten 
rechts?

Ich habe hier ausserdem mal eine Sequenz von ID 0x3C Nachrichten 
mitgeschnitten: 01021A9B 0110205A 01213935 01222020 01233600 01240000 
01255347 01264D52 01272048. Die ersten zwei Bytes scheinen ein Adresse 
zu sein, die folgenden zwei Bytes ein Inhalt an der Adresse. "SGMR H" 
bzw. "GSRMH " sagt mir erstmal aber nichts ...

LG, Sebastian

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Auf welche Bits im ersten Byte reagiert denn dein LIN Slave hinten
> rechts?

Das habe ich noch nicht im Detail geprüft weil der Motor momentan nicht 
angeschlossen ist und daher der Relais nur kurz anzieht bis bemerkt wird 
daß keine Reaktion über den HAL Sensor kommt. Es sind aber relativ 
sicher nur die drei unteren Bits im ersten Byte von Bedeutung.

> Ich habe hier ausserdem mal eine Sequenz von ID 0x3C Nachrichten
> mitgeschnitten: 01021A9B 0110205A 01213935 01222020 01233600 01240000
> 01255347 01264D52 01272048. Die ersten zwei Bytes scheinen ein Adresse
> zu sein, die folgenden zwei Bytes ein Inhalt an der Adresse. "SGMR "
> bzw. "GSRMH " sagt mir erstmal aber nichts ...

Der LIN Slave hat die Adresse (NAD) 0x04. Ich bekomme z.B. die typische 
"Negative Response" wenn die SID nicht unterstützt wird (Beispiel 
Response: "04 03 7F 01 11 00 00 FF" bei der SID 01). Ich muß das aber 
noch genauer untersuchen.

[Dieter S. (ds1)]

Sebastian W. schrieb:
>
> Ich habe hier ausserdem mal eine Sequenz von ID 0x3C Nachrichten
> mitgeschnitten: 01021A9B 0110205A 01213935 01222020 01233600 01240000
> 01255347 01264D52 01272048. Die ersten zwei Bytes scheinen ein Adresse
> zu sein, die folgenden zwei Bytes ein Inhalt an der Adresse. "SGMR H"
> bzw. "GSRMH " sagt mir erstmal aber nichts ...

Ich bekomme etwas ähnliches als segmentierte Antwort auf SID 0x1A:

04 10 30 5A 9B 36 59 30    ..0Z.6Y0      First Frame (FF)
04 21 39 35 39 38 31 32    .!959812      Consecutive Frame (CF)
04 22 20 20 20 B0 33 32    ."   .32      CF
04 23 31 00 00 00 00 00    .#1.....      CF
04 24 00 00 00 00 00 54    .$.....T      CF
04 25 53 47 20 48 52 20    .%SG HR       CF
04 26 4D 52 36 20 20 20    .&MR6         CF
04 27 20 48 57 30 30 32    .' HW002      CF
04 28 20 FF FF FF FF FF    .( .....      last CF (Fill Byte 0xFF)

Das sind neun Response Frames mit ID 0x3D, die gesamte Länge der Daten 
ist 0x30. Bei Dir ist die NAD wohl 0x01 anstelle 0x04.

Die Daten sind u.a. die Teilenummer und weitere Angaben auf dem Label.

[Frank O. (frank_o)]

Sebastian W. schrieb:
> Vielleicht hat dein Motor trotz gleicher Abmessungen eine andere
> Wicklung mit weniger Stromaufnahme?

Glaube ich nicht. Jedenfalls werden die nicht so große Unterschiede 
haben.
Das bestätigt meine Annahme.
Da es die Fahrertür betrifft, die ungleich mehr bedient wird, ist das 
noch etwas, was für meine Annahme spricht, dass der Fehler eher in den 
mechanischen Teilen liegt. Vielleicht ist der Motor (mit Getriebeteil) 
hin, was ich aber auch noch nicht glaube. Die Hebemechanik ist sicher 
schwergängig oder ausgeschlagen. Das führt dann zum klemmen und zu dem 
hohen Strom.

[Sebastian W. (wangnick)]

Frank O. schrieb:
> Das führt dann zum klemmen und zu dem hohen Strom.

Den hohen Strom habe ich aber auf dem Schreibtisch, ohne Fenstermimik, 
nur mit dem Getriebezahnrad ...

LG, Sebastian

[Heinz R. (heijz)]

Sebastian W. schrieb:
> Den hohen Strom habe ich aber auf dem Schreibtisch, ohne Fenstermimik,
> nur mit dem Getriebezahnrad ...

vielleicht hat sich ja ein Tropfen Öl verklemmt? :-)

Miss doch den Motor mal einfach direkt am Labornetzteil?

[Sebastian W. (wangnick)]

Heinz R. schrieb:
> Miss doch den Motor mal einfach direkt am Labornetzteil?

Sebastian W. schrieb:
> Er läuft bei 1V an, und zieht im Stillstand bei 0.9V 1.6A. Beim Anlauf
> mit 12V regelt mein LNT bei 5.1V kurz ab, im laufenden Betrieb mit
> Getriebe aber ohne Last am Zahnrad sind es 2.5A.
All diese Messungen waren am LNT.

LG, Sebastian

[Frank O. (frank_o)]

Sebastian W. schrieb:
> Den hohen Strom habe ich aber auf dem Schreibtisch, ohne Fenstermimik,
> nur mit dem Getriebezahnrad ...

Dann wirst du wohl den "Fehler" auf deinem Schreibtisch liegen haben.

[Jürgen H. (dg7gj)]

Hallo Leute!

Ist bei diesem eingeschlafenen Thema zwischenzeitlich etwas 
herausgekommen?

Das exakt selbe Problem hat mich nun ereilt. Ein Skoda Roomster von 
2007.
Beim letzten TÜV funktionierten plötzlich die elektrischen Fensterheber 
nicht mehr (wenige Tage zuvor gingen die noch.

Das selbe Türsteuergerät wie hier im Thema (J386 6Y2959802).
Exakt dieses Teil scheint es nirgends mehr als Ersatzteil zu geben.
Der Kabelbaum in der Fahrertür wurde von der Skoda-Werkstatt 
ausgetauscht, weil dort ein Kabelbruch diagnostiziert wurde.
Allerdings ohne Erfolg, die Fenster sind weiterhin tot.

Am LIN-Bus war ich bislang weder mit Oszi noch mit einem Logicanalyzer 
dran.

Und auch bei mir der Effekt:
J386 liegt gerade nackt vor mir auf dem Tisch. 12V Netzteil dran und 
scheint zu funktionieren.
Jedenfalls bei Tastbefehl "Fahrerfenster auf GND" klackert sauber das 
Relais.
Genau das aber macht er nicht, sobald er im Auto am Kabelbaum hängt.

Anfangs glaubte ich noch an einem weiteren Kabelbruch in einer der drei 
anderen Türen. Hinten sind zwar keine elektrischen Wagenheber, aber der 
LIN wird eben auch dort im Kabelbaum in die Türen geführt.

Also Kurzschluß nach Masse auf dem LIN?
Mitnichten, eher gegensätzlich:
Ruhespannung auf dem Lin ohne J386 im Fahrzeug Ubatt -1V etwa (Abfall 
Verpolungsschutzdiode).
Als ich den Strom gemessen habe erhielt ich 34mA.
Am Stecker in der Fahrertür scheint es also das bei 11,6V Ruhepegel da 
PullUps von insgesamt rund 340 Ohm dran wären ?????

Wenn ich den LIN-Bus richtig verstanden habe sind für Master 1K und für 
Slaves 30k PullUp's vorgeschrieben.

Und da kommt in mir die Frage auf:
Am LIN selber hängen noch Türsteuergerät Beifahrerseite (J387) sowie das 
zentrale Komfort-Steuergerät J393, sonst nix außer die ungenutzten 
Busenden in den hinteren Türen.

Wie kann es sein das dort am Ende 34mA fließen?
Im Datenblatt des LIN-Transceivers MC33689 fand ich die Angabe:

Output Current Shutdown Threshold Ioutsd 50  75  150mA.

Was sagt das aus? Das ein LIN-Transceiver sich resettet wenn beim 
pulldown ein Strom von >50mA fließt?

Jürgen Hüser

[Frank O. (frank_o)]

Ich würde so aus dem Bauch raus sagen, dass da ein Motor (vorzugsweise 
die Fahrertür) einen Kurzschluss hat und das Steuergerät hat abgeregelt.

[Jürgen H. (dg7gj)]

Hallo!

Naja, wenn ich den Motor direkt ans Netzgerät hänge, läuft er in beide 
Richtungen (je nach polarität eben) und zieht dabei knappe 2,4A an 
meinem Netzteil @ 12,65V.
Im Auto ist er über 25A abgesichert.
Wenn man bedenkt das "Leerlauf" im demontierten Betrieb den Antrieb des 
strammen Schneckengetriebes mit einschließt, sehen diese 2,4A für mich 
gar nicht mal so verdächtig aus.

Wäre schön wenn der OT mal eine Rückmeldung geben könnte ob er sein 
Türsteuergerät wieder hinbekommen hat oder nicht.

Mit Oszi oder Analyzer war ich noch nicht dran.
Und da der Tag heute schon fast zuende ist, sitze ich gerade am 
Notfallplan:
Mit schiebelehre die Pinnings der kritischen Stecker und deren Posizion 
ausmessen und in Target einpflegen.

Die eingentlich wichtige Funktion "Fahrerseite Fenster öffnen/schließen" 
ist lokal ja kein Akt.
Und da die Zentralverriegelung durchweg funktioniert, egal ob die 
Türsteuergeräte intakt oder gar ausgebaut sind, kann ich auf den LIN-Bus 
verzichten.

Zumal die letzten Tage mehrfach bei der Fehlersuche via OBD ausgelesen, 
auch alle Kanäle des Komfort-Steuergerätes J393 abgefragt:
Keine Fehlermeldungen, keine Meckerrei über fehlende LIN-Geräte.

Ehrlich gesagt...wenn ich die kommenden Tage das Steuergerät nicht ans 
laufen bekomme, wird es halt nach-entworfen und durch eine eigene 
Schaltung ersetzt.
Das selbe dann demnächst nochmal mit der Beifahrertür.

Etwas irritierend war aber das Verhalten gestern Vormittag:
Da hing nach provisorischen Anschluss des Tursteuergerätes lose am 
Kabelstrang, so das ich von oben messen konnte.
Sinn der Übung war zu gucken ob die Tastersignale überhaupt am 
Steuergerät ankommen. Also entweder 11V, 2,6V oder 0V.
Als ich mit dem Messstrippen des Multimeters zwischen Masse und 
Tastereingang Fahrerseite hing und den Taster betätigte....lief der 
Motor plötzlich!
Selbst die Fernsteuerung zur Beifahrerseite funktionierte.

War kurz am überlegen ob ich dem Motor einfach direkt wieder montieren 
sollte. Allerdings deutete dieses Verhalten für mich auf ein 
Kontaktproblem zwischen Kabelbaumstecker und Steuergerätebuchse hin.
Daher wieder abgestöpselt, mit Kontaktspray, Glasfaserstift und 
Interdentalbürste alle Kontakte am Steuergerät poliert.

Danach ging hingegen wieder nix.
Zum Haare Raufen!

Jürgen Hüser

[Andreas B. (buyman)]

Schonmal probiert, ob es noch per Fernbedienung klappt? Bei meinem A4 
(BJ 2002) war es ein Kabelbruch in der Fahrertür. Taster haben nicht 
funktioniert, per Schlüssel aus der Ferne aber schon.

Kabelbruch (bzw. brüche) gerichtet, alles ging wieder. Master war in der 
Fahrertür, das ist auch die am meisten verwendete Tür und damit auch der 
anfälligste Teilkabelbaum.

[Jürgen H. (dg7gj)]

Hallo!

Das ist es ja...:
Als letzte Woche der Wagen durch den TÜV sollte hat die Werkstatt 
gemeint - geht nicht! Fahrerfenster lässt sich nicht öffnen - so kommt 
er nicht durch den TÜV.
Werkstatt hat dann den Fehler gesucht und einen Kabelbruch im Kabelbaum 
der Fahrertür gefunden - und dann den kompletten Tür-Kabelbaum bis zum 
Türstecker in der A-Säule ausgetauscht.
Brachte aber nix. Werkstatt meint der Motor (mit Steuergerät J386) wäre 
kaputt.
Gäbe es aber seit 2014 nicht mehr.

Tja, und nun hänge ich da....
Kabelbruch in der Beifahrertür? Irgendwo anders irgendwas am LIN?
Oder wirklich Türsteuergerät.

Und wie gesagt...34mA bei Messung zwischen LIN und GND kommt mir für LIN 
ziemlich heftig vor.
Wenn Zentralsteuergerät und Türsteuergerät Beifahrerseite jeweils Slaves 
sein sollten, müssten diese bei LIN mit 30k PullUp arbeiten.
Beide parallel also 15k was dann nur maximal 0,8mA sein dürften.

Was noch bliebe: Isolationsfehler LIN zu Ubatt, mit stabilen 353 Ohm????

Halte ich eher für Fragwürdig...

Jürgen Hüser

[Sebastian W. (wangnick)]

Jürgen H. schrieb:
> Exakt dieses Teil scheint es nirgends mehr als Ersatzteil zu geben.

Gebraucht findet man die schon noch.

Jürgen H. schrieb:
> Wäre schön wenn der OT mal eine Rückmeldung geben könnte ob er sein
> Türsteuergerät wieder hinbekommen hat oder nicht.

Das liegt hier noch irgendwo, ist höchstwahrscheinlich gar nicht defekt, 
und wartet auf den Ausfall des Austauschteils der 600€-Reparatur bei der 
Spezialexpertenfahrzeugelektronikfachwerkstatt.

LG, Sebastian

[Dieter S. (ds1)]

Jürgen H. schrieb:
>
> Und wie gesagt...34mA bei Messung zwischen LIN und GND kommt mir für LIN
> ziemlich heftig vor.

Verstehe ich das richtig, Du misst den Kurzschlussstrom auf dem LIN Bus? 
Was soll das aussagen, laut Datenblatt liegt der "Output Current 
Shutdown Threshold" des LIN Transceiver zwischen 50 und 150 mA.

[Jürgen H. (dg7gj)]

Hallo...

Sebastian W. schrieb:
> Gebraucht findet man die schon noch.

Puh, im Internet finde ich auf der Suche nach 6Y2959802 SK5 allerlei 
Fenstermotoren die aber weitgehend nicht kompatibel sind.
Übrig bleiben dann vielleicht zwei oder maximal drei Hits die laut 
Typennummer passen könnten, alles im Bereich 390-599€ und mit Status 
"aktuell nicht verfügbar".

Sebastian W. schrieb:
> Das liegt hier noch irgendwo, ist höchstwahrscheinlich gar nicht defekt,
> und wartet auf den Ausfall des Austauschteils der 600€-Reparatur bei der
> Spezialexpertenfahrzeugelektronikfachwerkstatt.

Ah ja, also Fehler durch Werkstatt behoben ohne Info was dort abseits 
des Steuergerätes gefunden wurde. Schade....

Dieter S. schrieb:
> Verstehe ich das richtig, Du misst den Kurzschlussstrom auf dem LIN Bus?
> Was soll das aussagen, laut Datenblatt liegt der "Output Current
> Shutdown Threshold" des LIN Transceiver zwischen 50 und 150 mA.

Ja, das hast du richtig verstanden.
Ich erhoffte mir Klarheit über die Erkenntnis was da wo genau verbaut 
ist und wie die Verhältnisse am LIN-Bus sind.
So habe ich bei der Fehlersuche im Fahrzeug die letzten Tage aufgrund 
einer falschen Systembeschreibung Verwirrung erlebt.
Für den Roomster 2007 finde ich zwar Schaltpläne und Studienprogramme.
Aber das Komfortsystem wird nur von der Oktavia-Baureihe genauer 
beschrieben.
Blöder weise ist da aber das Zentralgerät J393 der LIN-Master welcher 
alle 100ms die Türsteuergeräte (LIN-Slaves) anpollen soll, alles mit 
19k2.

Blöd aber: Mein Fehler sieht eher so aus als ob das J386 wichtiger wäre 
als ein simpler Slave.
Und hier im Topic fand ich dann erstmals die klaren aussagen das der 
J386 der tatsächliche LIN-Master sei.
Das erklärt so manches.

Allerdings...34mA...ich hoffte 0,4mA oder 0,8mA oder auch 12mA zu 
finden.
Weil das hätte mir klar gezeigt das J393 und und J387 Slaves sind 
(0,4-0,8mA) oder ob J393 ein Master ist (12mA).
Statt dessen messe ich da 34mA was rechnerisch einen PullUp von 353 Ohm 
ergäbe! Was ist da los?

[Jürgen H. (dg7gj)]

Nachtrag:

Aufgrund des selben Problemes wie bei Sebastian letzes Jahr konnte ich 
gestern im ersten Anlauf das Türsteuergerät nicht testen.
An meinem 6A Schaltnetzteil sorgte der Anlaufstrom des Motors zu einem 
kurzen Spannungsabfall welcher das gesamte Steuergerät resettete.

Nun an einem voll geladenen 18Ah PB (gute 13,95V) geht es jetzt.
Hier dann direkt mal die selbe Messung des LIN-Stromes gegen Masse 
gemessen:
11,6mA! Passt! Da werkelt also ein LIN-konformer PullUp im 
Türsteuergerät Fahrerseite als LIN-Master mit 1k PullUp.

Um so verstörender die 34mA im Auto.
Wenn J387 (Beifahrertür) und J393 (Zentralsteuergerät Komfort) also 
LIN-Slaves wären, sollten sie je 30k PullUp haben. Zusammen also 15k.
Das passt so gar nicht zu 34mA.

Na Toll, dann darf ich nachher wieder den Wagen zerlegen und gucken ob 
ich irgendwelche Isolationsfehler am LIN finde.
Vorher aber will ich den LIN-Bus am J386 loggen.

Jürgen Hüser

[Dieter S. (ds1)]

Jürgen H. schrieb:
>
> Nun an einem voll geladenen 18Ah PB (gute 13,95V) geht es jetzt.
> Hier dann direkt mal die selbe Messung des LIN-Stromes gegen Masse
> gemessen:
> 11,6mA! Passt! Da werkelt also ein LIN-konformer PullUp im
> Türsteuergerät Fahrerseite als LIN-Master mit 1k PullUp.

Und was passiert wenn Du den Zustand im Fahrzeug auf dem LIN Bus 
nachbildest (das ist dann wohl ein zusätzlicher Pullup), läßt sich der 
Motor dann immer noch bedienen? Damit könntest Du eventuell herausfinden 
ob der LIN Bus die Ursache für den Fehler ist.

[Sebastian W. (wangnick)]

Jürgen H. schrieb:
> Um so verstörender die 34mA im Auto.
> Wenn J387 (Beifahrertür) und J393 (Zentralsteuergerät Komfort) also
> LIN-Slaves wären, sollten sie je 30k PullUp haben. Zusammen also 15k.
> Das passt so gar nicht zu 34mA.

Wenn ich es recht erinnere, ist bei unserem T5 der LIN-Bus der 
Türsteuergeräte autonom, die Fahrertür ist der Master, und das 
Zentralsteuergerät ist NICHT an diesen LIN-Bus angeschlossen.

LG, Sebastian

[Soul E. (soul_eye)]

Jürgen H. schrieb:
> Dieter S. schrieb:
>> Verstehe ich das richtig, Du misst den Kurzschlussstrom auf dem LIN Bus?
>> Was soll das aussagen, laut Datenblatt liegt der "Output Current
>> Shutdown Threshold" des LIN Transceiver zwischen 50 und 150 mA.
>
> Ja, das hast du richtig verstanden.
> Ich erhoffte mir Klarheit über die Erkenntnis was da wo genau verbaut
> ist und wie die Verhältnisse am LIN-Bus sind.

Du hast einen Kurzschluß gegen KL30 gemacht -- richtig? Der Stromfluß 
wird in diesem Fall nur durch den Rds,on des Transistors begrenzt. Der 
würde also relativ schnell durchbrennen, wenn er nicht chip-intern 
überwacht würde. Dort wird der Kurzschluß erkannt und der Ausgang 
abgeschaltet. Du siehst also einen kurzen Peak, und dann geht der 
Stromfluss auf Null.

Bei einem Kurzschluß nach Masse machst du genau das gleiche, wie der 
Transistor im LIN-Transceiver: Du legst einen dominanten Pegel (low) an. 
In diesem Fall fließen durch den 1 kOhm-Pullup ca 13 mA nach Masse. Wenn 
dieser Zustand länger als einige 10 ms andauert, wird ein DTC für "LIN 
dominant timeout" (Kurzschluss) abgelegt.

[Jürgen H. (dg7gj)]

Hallo!

Dieter S. schrieb:
> Und was passiert wenn Du den Zustand im Fahrzeug auf dem LIN Bus
> nachbildest (das ist dann wohl ein zusätzlicher Pullup), läßt sich der
> Motor dann immer noch bedienen? Damit könntest Du eventuell herausfinden
> ob der LIN Bus die Ursache für den Fehler ist.

Genau das habe ich vor. Knappe 350 Ohm werde ich zusammen bekommen aus 
meinem Widerstandsvorrat.
Derzeit plane ich gerade geeignete Abgriffpunkte wo ich möglichst 
einfach an die 5V-Seite des UART's sowie an die PullUp-Spannung (ca. 1V 
unterhalb Vbatt) Abgreifdähtchen anlöten könnte.

Sebastian W. schrieb:
> Wenn ich es recht erinnere, ist bei unserem T5 der LIN-Bus der
> Türsteuergeräte autonom, die Fahrertür ist der Master, und das
> Zentralsteuergerät ist NICHT an diesen LIN-Bus angeschlossen.

Beim Roomster Bj. 2006-2010 (meiner ist von 2007) reicht der LIN-Bus 
über alle Türen sowie am Zentralsteuergerät Komfort J393.
Wozu das gut sein soll weis ich nicht, denn Sachen wie Türkontakt und 
Zentralverriegelung liegen zwar auch an den Türsteuergeräten, aber eben 
auch parallel an den Türsteuergeräten vorbei direkt am J393.
Das Heißt, das die Funktion Türkontakt und Zentralverriegelung autonom 
auch ohne Türsteuergeräte funktioniert, sowie bei fehlerhaften LIN-Bus.
Der tiefere Sinn könnte vielleicht damit zusammenhängen das J393 
geöffnete Fenster erkennen möchten könnte, um der Klimaanlage diese 
Information via CAN mit zu teilen.
Das aber ist nur eine Mutmaßung.

Jürgen Hüser

[Jürgen H. (dg7gj)]

Hallo!

Soul E. schrieb:
> Du hast einen Kurzschluß gegen KL30 gemacht -- richtig? Der Stromfluß
> wird in diesem Fall nur durch den Rds,on des Transistors begrenzt.

Aber selbstverständlich NICHT von Kl.30 zu LIN! Ich bin doch nicht 
wahnsinnig! Jedes LIN-Gerät am Bus welches dabei seinen Transistor 
schaltet würde direkt in den Halbleiterhimmel aufsteigen.

Soul E. schrieb:
> Bei einem Kurzschluß nach Masse machst du genau das gleiche, wie der
> Transistor im LIN-Transceiver:

Jawoll, genau das habe ich gemacht! Mit Amperemeter die Rolle eines 
LIN-Transistors gespielt um zu erfahren wie viele und welche PullUp's am 
Bus hängen. Ergebnis: 34mA entsprechend etwa 350 Ohm...*grübel*.

Aber wie eben schon geschrieben:
Werde wenn ich mein J386 Master nachher verkabelt habe gucken wie er 
reagiert wenn ich ihm einen zusätzlichen PullUp von 350-360 Ohm dran 
hänge.
Steigt er dann aus, sendet nicht mehr auf LIN und weigert sich den Motor 
zu schalten, dürfte genau das dass Problem sein.

Jürgen Hüser

[Sebastian W. (wangnick)]

Jürgen H. schrieb:
> 2007) reicht der LIN-Bus über alle Türen sowie am Zentralsteuergerät
> Komfort J393

Ok, dann ist das anders als bei unseren T5 mit gleichem Baujahr, bei dem 
die Türsteuergeräte auf ihren mit J393 verbundenen Ausgängen analoge 
Schaltersignale emulieren ...

LG, Sebastian

[Soul E. (soul_eye)]

Jürgen H. schrieb:
> Jawoll, genau das habe ich gemacht! Mit Amperemeter die Rolle eines
> LIN-Transistors gespielt um zu erfahren wie viele und welche PullUp's am
> Bus hängen. Ergebnis: 34mA entsprechend etwa 350 Ohm...*grübel*.

Dann solltest Du aber eher 12-15 mA messen, denn der Pullup beträgt 1 
kOhm. Der sitzt im Master-Steuergerät.

350 Ohm ist doch etwas sehr niedrig. Das verletzt die LIN-Spec und lässt 
eher auf einen Fehler schließen.


> Steigt er dann aus, sendet nicht mehr auf LIN und weigert sich den
> Motor zu schalten, dürfte genau das dass Problem sein.

Entweder Dein Steuergerät ist der Master, dann ist da der 1k Pullup 
eingebaut. Oder es ist ein Slave, und dann wird es ohne Master überhaupt 
nichts senden. Egal ob der Pullup da ist oder nicht. Beim LIN gibt es 
nur remote frames. Der Header kommt immer vom Master, und der jeweils 
angesprochen Slave füllt lediglich seine Datenbytes in den Frame.

[Jürgen H. (dg7gj)]

Hallo nochmal,

Kurze Rückmeldung für heute - bin ein wenig weiter oder doch nicht...

Also der J386 hier auf dem Tisch ist verdrahtet und durchgetestet.
Zum sniffen der LIN-Schnittstelle bin ich am TXD des MC33689 (Pin 32) 
gegangen, da sowohl der Logic2 als auch meine FTDI-UART's nur 5V 
abkönnen.

Einen zusätzlichen Spannungsteiler um die 10-13V des LIN-Busses auf 5V 
zu teilen wollte ich mir sparen.

Wie die Erkentnisse vor knapp einem Jahr hier kann ich bestätigen: Der 
J386 vom Roomster 2006-2010 ist der LIN-Master.
In den ersten zwei Sekunden nach Anlegen der Spannung kommen nur 
abgehackte PID's 26 und 31 ohne irgendwas an Folgedaten.
Ab der 3. Sekunde ist das Teil dann stabil.

Es sendet unermüdlich h26 41 00 40 00 7E, also an PID 26 vier Bytes 41 
00 40 00 + CRC
Die hier berichtete PID 3C sendet mein Master nur nach einem Neustart 
(anlegen von Spannung) - danach nicht mehr - zumindest nicht in den 10 
Minuten die ich mitgeloggt habe.

Diese Vier Bytes an PID 26 kommen im Abstand von ca. 100ms zwei mal 
nacheinander, und jeweils als drittes Frame eine Abfrage an PID 13 
welche aber unbeantwortet bleibt (hängt noch im Auto).

Was ich mir aber erhoffte traf nicht ein:
Den Fehler im LIN-Bus des Autos emuliert durch hinzulöten eines 333R 
PullUps am LIN.
Dem J386 macht das aber scheinbar nix aus. Er meckert nicht, er sendet 
weiter Pakete unbeirrt über den LIN und nimmt auch Tasterbefehle 
entgegen.

Soul E. schrieb:
> Dann solltest Du aber eher 12-15 mA messen, denn der Pullup beträgt 1
> kOhm. Der sitzt im Master-Steuergerät.

Jawoll, hier am J386 messe ich 11,6mA was sehr gut zum 1k PullUp passt 
welcher ein Master haben soll.

Soul E. schrieb:
> 350 Ohm ist doch etwas sehr niedrig. Das verletzt die LIN-Spec und lässt
> eher auf einen Fehler schließen.

Das ist genau die Sache die mir seit Tagen durch den Kopf geht.
Nur welche Art von Fehler?
Das ein Slave-PullUp von 30k absacht auf deutlich unter 500 Ohm kann ich 
mir kaum erklären. Ausser er badet gerade im Elektrolyt eines 
ausgelaufenen Elkos.

Isolationsfehler im Kabelbaum der übrigen drei Türen?
Der Kabelbaum in der Fahrertür zum J386 wurde bereits ausgetauscht und 
ist keine Woche alt.
Allerdings ein Isolationsproblem mit über Tage stabilem Widerstand trotz 
regelmäßiger Öffnung der diversen Türen?
Würde da eher irgendwas zwischen hochohmig und Kurzschluß 
umherspringenden Fehlerwiderstand erwarten und nicht über Tage stabile 
352 Ohm.

Aber das alleine ist es nicht.
Hier alleine auf dem Tisch werkelt der J386 anstandslos selbst am 333 
Ohm PullUp.

Weis der Geier warum das Teil hier auf den Tisch funktioniert, aber 
nicht im Auto.

Aber mal ganz generell zum Thema LIN-Bus:
Abgesehen vom Pegel 0V/12V und den PullUp's von 1k für Master und 30k 
für Slaves.
Gibt es irgendwo im Internet zugänglich eine PDF mit dem exakten 
Standard?
Die Links bei Wikipedia liefern keinerlei brauchbare Spezifikationen und 
direkt über Google nur Fragmente.

Jürgen Hüser

[Soul E. (soul_eye)]

Jürgen H. schrieb:
> Das ein Slave-PullUp von 30k absacht auf deutlich unter 500 Ohm kann ich
> mir kaum erklären. Ausser er badet gerade im Elektrolyt eines
> ausgelaufenen Elkos.

Der Slave-Pullup ist kein Bauteil, sondern ein Depletion-FET im Inneren 
des LIN-Transceivers. Der darf in den rezessiven Pegel maximal 600 µA 
reindrücken. 30k entspricht ca 400 µA.


> Isolationsfehler im Kabelbaum der übrigen drei Türen?

Oder ein abgesoffener Stecker, oder Elektromigration in einem der 
anderen Steuergeräte. Wobei es da aber wenig Bauteile gegen KL30 gibt, 
die gammeln können. Der 220 pF ESD-Kondensator geht ja gegen Masse.

Du kannst ja mal, sofern zugänglich, die anderen Teilnehmer abstecken 
und Deinen Test im Fahrzeug wiederholen.


> Gibt es irgendwo im Internet zugänglich eine PDF mit dem exakten
> Standard?

lin-subbus.org ist tatsächlich nicht mehr aktiv, die verweisen nun auf 
die ISO, und die will Geld sehen. Es gibt die Spec aber noch an anderen 
Stellen im Netz. Z.B. 
https://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf

[Jürgen H. (dg7gj)]

Hallo!

Soul E. schrieb:
> Der Slave-Pullup ist kein Bauteil, sondern ein Depletion-FET im Inneren
> des LIN-Transceivers. Der darf in den rezessiven Pegel maximal 600 µA
> reindrücken. 30k entspricht ca 400 µA.

Ahja, gut zu wissen.

Soul E. schrieb:
> der ein abgesoffener Stecker, oder Elektromigration in einem der
> anderen Steuergeräte. Wobei es da aber wenig Bauteile gegen KL30 gibt,
> die gammeln können.

Ähem, ich erwähnte es schon....es ist bei mit verdächtiger.
Dieser ominöse 353 Ohm Shunt irgendwo auf dem Bus geht nicht auf Klemme 
30 oder Klemme 15!
Sondern exakt auf die Spannung, welche auch von den LIN-Geräten 
werwendet wird: Klemme 30 über Verpolungsschutzdiode und paar weitere 
Entstörmimiken, also bei mir im Auto als auch am J386 hier auf dem Tisch 
ziemlich genau 1V unter Klemme 30/15/Batterie...zwischen 997-1002mV 
dadrunter.
Dieser isolationsfehler muss also gegen eine Leitung sein, die ebensolch 
eine Schutzschaltung hat für irgendein Signal.
Das einzige was mir da einfiele wäre Türkontakt oder Sensorleitung zur 
Zentralverriegelung.

Soul E. schrieb:
> Du kannst ja mal, sofern zugänglich, die anderen Teilnehmer abstecken
> und Deinen Test im Fahrzeug wiederholen.

Ja, wenn das Wetter mitspielt mache ich das mal.
Zumindest an das Türsteuergerät in der Beifahrertür käme ich ran.
Wenn ich ein paar Innenverkleidungen abnehme käme ich auch an die 
Türstecker für die hinteren Türen.

Beim J393 Zentralsteuergerät war ich noch nicht dran.
Da graut es mich auch etwas vor.
Soll hinter einer Abdeckung und einem Lüftungskanal oberhalb des 
Bremspedals sitzen.
Um da ran zu kommen braucht es voraussichtlich akrobatische 
Verrenkungen.

Soul E. schrieb:
> lin-subbus.org ist tatsächlich nicht mehr aktiv, die verweisen nun auf
> die ISO, und die will Geld sehen. Es gibt die Spec aber noch an anderen
> Stellen im Netz. Z.B.
> 
https://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf

Spitze! Sowas habe ich gesucht! Danke!

Jürgen Hüser

[Dieter S. (ds1)]

Nur mal als Idee: sollte denn der Fensterheber immer funktionieren oder 
gibt es Zustände (z.B. offene Türe oder abgesperrte Türe) bei denen es 
beabsichtigt ist dass er nicht läuft? Falls das so ist könnte ja 
eventuell so ein Zustand im Fahrzeug signalisiert werden.

[Jürgen H. (dg7gj)]

Hallo

Dieter S. schrieb:
> Nur mal als Idee: sollte denn der Fensterheber immer funktionieren
> oder
> gibt es Zustände (z.B. offene Türe oder abgesperrte Türe) bei denen es
> beabsichtigt ist dass er nicht läuft? Falls das so ist könnte ja
> eventuell so ein Zustand im Fahrzeug signalisiert werden.

Danke für den Wink mit dem Zaunpfahl.
Ob es das ist oder nicht werde ich versuchen irgendwie zu testen.
Denn diese dumme Idee kam mir auch letzte Nacht beim einschlafen.

Laut Schaltplan liegt der Türkontakt sowohl am Türstecker zum 
Zentralsteuergerät J393 als auch am Türsteuergerät J386, und zwar an 
Kontakt T8h/4. Und ja, bei geöffneter Tür wird der Motor gesperrt.

Allerdings....:
Hier auf dem Tisch, gerade eben versucht:
Türkontakt T8h/4 wird vom J386 auf High (11,85V) gezogen -Motor ist 
steuerbar.
Wenn ich T8h/4 auf Masse lege, lässt sich der Motor trotzdem ansteuern.
Also jetzt hier auf dem Tisch ignoriert das Türsteuergerät merkwürdiger 
weise den Status des Türkontaktes.

Merkwürdig...

Jürgen Hüser

[Dieter S. (ds1)]

Jürgen H. schrieb:
>
> Wenn ich T8h/4 auf Masse lege, lässt sich der Motor trotzdem ansteuern.
> Also jetzt hier auf dem Tisch ignoriert das Türsteuergerät merkwürdiger
> weise den Status des Türkontaktes.

Der Türkontakt ist ganz sicher eine Verbindung nach Masse und geht nicht 
eventuell über einen Widerstand? Ich frage weil ja vielleicht ein 
Kurzschluss nach Masse auf der Leitung erkannt werden soll.

Alternativ: Wird eventuell "Zündung ein" oder "Motor läuft" ausgewertet 
und nur dann verhindert dass der Fensterheber bei offener Tür läuft?

[Jürgen H. (dg7gj)]

Hallo!

Ich werd wahnsinnig, weiß der Geier nach welcher Logik die Firmware des 
J386 gestrickt ist.

Also nach dem das J386 seit nun knapp 3 Tagen ausgebaut bei mit auf dem 
Tisch anstandslos funktionierte heute mal eingebaut.
Diesmal erstmalig bei geschlossener Fahrertür.

Und siehe da....es tut!
Er dreht nun nicht nur den eigenen Motor, sondern auch brav den auf der 
Beifahrerseite korrekt.
Kurioser weise allerdings auch bei geöffneter Fahrertür.

Der LIN-Master scheint also zwingend bei einem POR einen geschlossenen 
Türkontakt sehen. Ist er dann fehlerfrei gestartet, ignoriert er den 
Türkontakt.

Dieter S. schrieb:
> Der Türkontakt ist ganz sicher eine Verbindung nach Masse und geht nicht
> eventuell über einen Widerstand? Ich frage weil ja vielleicht ein
> Kurzschluss nach Masse auf der Leitung erkannt werden soll.

Zumindest laut Schaltplan geht der Türkontakt auf Masse.
Eine Widerstandskodierung wird hingegen bei den Tastern für die Fenster 
auch für die Zentralverriegelung (0 Ohm oder 180 Ohm gegen Masse) 
benutzt.

Dieter S. schrieb:
> Alternativ: Wird eventuell "Zündung ein" oder "Motor läuft" ausgewertet
> und nur dann verhindert dass der Fensterheber bei offener Tür läuft?

Auch "Zündung Ein" wird am Türsteuergerät ausgewertet, allerdings 
Timergesteuert.
Die Fenster sind für bis zu 10 Minuten nachdem Zündung weg ist weiter 
steuerbar.

Tja, nun sitze ich hier und hoffe.
Also Türverkleidung liegt noch auf der Rückbank, weil der Schalter für 
die Außenspiegelsteuerung beim Wechsel des Türkabelbaumes von der 
Werkstatt zerstört wurde. Hatte eigentlich gestern darauf gehofft das 
der kommt, aber dauert wohl noch.
Ich hoffe das in einigen Tagen die Fenster noch immer funktionieren.

In jedem Fall ist noch eine Überprüfung der hinteren Türkabel und für 
die Beifahrerseite eher ein komplett neuer Kabelbaum fällig.
Denn der Isolationsfehler am LIN muss da irgendwo an einer dieser drei 
Türschnittstellen sein.

Also Hauptproblem erledigt - ohne irgendwas verändert zu haben.
Nebenproblem Isolationsfehler am LIN kümmere ich mich nach dem TÜV.

Dazu nochmal eine ganz blöde Frage zum Thema LIN-Bus:
Wolle man sich einen Diagnose-Sniffer bauen, gibt es ja das Problem mit 
dem LIN-Break (13Tbit Low).
Dümmere, oder sagen wir "tollerantere" UART-Schnittstellen (z.B. mein 
FT230XS USB-Adapter) erkennen einfach das Break als h00 gefolgt von 
einem h55 als Sync.

Würde ich da aber mit dem RxD eines ATmega328PB dran gehen, vermute ich 
das der bei einem Break aus dem Tritt käme.
Ja, ich weis, wäre lösbar indem man die Break-Auswertung abseits des 
UART's  erledigen könnte der dann den UART einschaltet.
Aber gibt es kein LIN-Transceiver der diese Break-Erkennung nicht schon 
eingebaut hat?

Denn das verwendete Protokoll dieser LIN-Steuerung habe ich bislang nur 
bruchteilhaft:

An Pid 26 werden ständig die Betriebszustände in vier Bytes + CRC 
gesendet.
Regelmäßig, alle ca. 300ms wird ein Slave mit Pid 13 abgefragt - Antwort 
unbekannt.

Zusätzlich 6 Sekunden nach einem POR wird einmal an Pid 3C eine 
Nachricht mit 80Bytes gesendet, aufgeteilt in 10 Subframes zu je 8 Bytes 
+ CRC.

Knappe 100ms nach dem letzten dieser 10 Pakete: (3C 02 02 1A 9B FF FF FF 
FF 46) wird zwei mal die Pid 3D angepollt.

Also ganz klar:
Pid 13 wird das J387 in der Beifahrertür sein.
Diese Antwort wäre interessant zu sniffen.

Pid 3C ist eine ASCII-Nachricht an das Zentral-Komfortgerät J393 und 
enthält praktisch das, was auch auf dem Typenschild steht: 
Ersatzteilnummer und Softwareversion.

Pid 3D ist offensichtlich eine Abfrage nach Konfigurationsdaten aus dem 
J393.
Wäre zumindest logisch, denn nur das J393 hängt am CAN-Bus und 
beinhaltet die über OBD konfigurierten Funktionen für die Fensterheber.
Auch dieser Datensatz wäre interessant zu sniffen.

Warum? Nun hätte ich das das Protokoll erst mal komplett, könnte ich mir 
bei zukünftigen Problemen die Türsteuergeräte auch komplett selbst 
bauen.

Jürgen Hüser

[Soul E. (soul_eye)]

Jürgen H. schrieb:
> Wolle man sich einen Diagnose-Sniffer bauen, gibt es ja das Problem mit
> dem LIN-Break (13Tbit Low).
> Dümmere, oder sagen wir "tollerantere" UART-Schnittstellen (z.B. mein
> FT230XS USB-Adapter) erkennen einfach das Break als h00 gefolgt von
> einem h55 als Sync.

Der Sync Break liefert einen frame error. Manche Controller können damit 
einen Interrupt auslösen.

Die 0x55 werden dann wieder normal empfangen.

Wenn Du Master bist, zum senden, schaltest Du die Baudrate einen Gang 
runter und sendest 0x00 als Break. Auf die genaue Länge kommt es nicht 
an, die gucken alle nur auf die 0x55.


> Aber gibt es kein LIN-Transceiver der diese Break-Erkennung nicht schon
> eingebaut hat?

Richtige Controller mit LIN-Unterstützung erkennen den Break und regeln 
ihren internen Oszillator anhand des 0x55 nach. So kommt man ohne Quarz 
aus.


> Zusätzlich 6 Sekunden nach einem POR wird einmal an Pid 3C eine
> Nachricht mit 80Bytes gesendet, aufgeteilt in 10 Subframes zu je 8 Bytes
> + CRC.

3C/3D ist eigentlich Diagnose. Diese IDs sendet auch der Werkstattester. 
Der eine ist Anfrage, in den anderen packt der adressierte Slave seine 
Antwort.


> Warum? Nun hätte ich das das Protokoll erst mal komplett, könnte ich mir
> bei zukünftigen Problemen die Türsteuergeräte auch komplett selbst
> bauen.

Gut, dann weiss ich schonmal wo ich die nächsten H-Brücken-ASICs 
loswerde ;-)

[Dieter S. (ds1)]

Soul E. schrieb:
>
> Richtige Controller mit LIN-Unterstützung erkennen den Break und regeln
> ihren internen Oszillator anhand des 0x55 nach. So kommt man ohne Quarz
> aus.

Ja, bei den Slave Steuergeräten fehlt der Quarz, siehe das Bild hier (im 
Vergleich zum Bild des ersten Beitrag, der Quarz ist unterhalb des 
MC68HC908EY):

Beitrag "Re: Untersuchung defektes VW Türsteuergerät"

> 3C/3D ist eigentlich Diagnose. Diese IDs sendet auch der Werkstattester.
> Der eine ist Anfrage, in den anderen packt der adressierte Slave seine
> Antwort.

Das ist Diagnose, beim Slave sieht das z.B. so aus:

Beitrag "Re: Untersuchung defektes VW Türsteuergerät"

[Soul E. (soul_eye)]

Jürgen H. schrieb:
> An Pid 26 werden ständig die Betriebszustände in vier Bytes + CRC
> gesendet.

Dimmung, Klemmenstatus ("Zündung ein"), Spiegel anklappen, ...

> Regelmäßig, alle ca. 300ms wird ein Slave mit Pid 13 abgefragt - Antwort
> unbekannt.

Früher hingen die Lenkradtasten mit am Tür-LIN. Wobei  300 ms dafür 
eigentlich zu langsam ist.

> Also ganz klar:
> Pid 13 wird das J387 in der Beifahrertür sein.
> Diese Antwort wäre interessant zu sniffen.

Die vier TSG sollten aufeinanderfolgende IDs und ähnliche 
Datenstrukturen haben. Status Fensterheberschalter, Motor normiert oder 
nicht, Fensterposition in % oder unbekannt falls denormiert, ggf 
Türgriff und Türschloss.

Zum Sniffen kannst Du einen Saleae nehmen, mit seriellem Decoder. Einen 
TJA1021 zum Pegelwandeln davor. Das tut's erstmal, bis die eigene SW 
fertig ist. Dann die Funktionen durchprobieren und schauen wo sich was 
ändert.


An sich ist die Elektronik kein Hexenwerk. Die Kunst ist halt die 
sensorlose Sensorik und der Einklemmschutz. Man muss aus dem Verlauf des 
Motorstromes erkennen was die Scheibe macht. Wind, Dreck in der 
Dichtung, Hand dazwischen oder oben am Anschlag?

[Jürgen H. (dg7gj)]

Hallo!

Soul E. schrieb:
> Der Sync Break liefert einen frame error. Manche Controller können damit
> einen Interrupt auslösen.
>
> Die 0x55 werden dann wieder normal empfangen.
>
> Wenn Du Master bist, zum senden, schaltest Du die Baudrate einen Gang
> runter und sendest 0x00 als Break. Auf die genaue Länge kommt es nicht
> an, die gucken alle nur auf die 0x55.

Ja, muss mir nochmal detaillierter das Datenblatt zu meinen ATmega328PB 
anschauen was er zum Thema Break als frame error-Erkennung sagen würde.
Als Master würde ich einfach mittels N-FET oder Diode den TXD für eine 
definierte Zeit runter ziehen.

Soul E. schrieb:
> 3C/3D ist eigentlich Diagnose. Diese IDs sendet auch der Werkstattester.
> Der eine ist Anfrage, in den anderen packt der adressierte Slave seine
> Antwort.

Tja, über h3C sendet das Türsteuergerät seine Ersatzteilnummer und 
Softwareversion.
Die Antwort über h3D könnte nun ebenso ernüchternd sein, oder aber auch 
Konfigurationsdaten beinhalten.
Immerhin gibt das zentrale Komfort-Steuergerät J393 über OBD vor 
definieren zu können wie viele LIN-Slaves verbaut sind (keine, 2 
Fensterheber oder 4 Fensterheber).
Könnte aber auch sein das dieses eher über die Pid h13 läuft.
Denn so wie ich das sehe mit der Pid h26:

h41 00 40 00
h41 06 40 00
h40 30 40 00
.......
Da steckt eigentlich alles drin was nötig ist. Die meisten (oder alle?) 
Fensterwerte sind im 2. Byte, Informationen zu Türkontakten scheinbar 
irgendwo im oberen Nibbel des 1.Bytes

Somit scheint Pid 26 nicht als konkrete Slaveadresse sondern eher als 
Broadcast-Adresse genutzt zu werden.
Denn es stecken da eben sowohl lokale Informationen aus der Fahrertür 
drin, als auch Befehle an das Steuergerät Beifahrertür.
Und ich könnte fast wetten - auch bei Vollausstattung mit vier 
elektrischen Fensterhebern wäre Pid 26 ausreichend.

Soul E. schrieb:
> Gut, dann weiss ich schonmal wo ich die nächsten H-Brücken-ASICs
> loswerde ;-)

Nee, so aufwändig nicht.
Als ich vor einigen Tagen das J386 ausbaute und in meine Werkstatt 
schleppte, ging ich auch eher davon aus das da eine durchgeschmorte 
H-Brücke die Ursache wäre.
Aber mitnichten...Relais, richtig kleines Biest mit 10 Pins.
ACT512, quasi zwei unabhängige Wechler in einem Kompaktgehäuse.
Ich weis zwar nicht wie die das schaffen mit 12V/20A schalten - aber das 
Originalrelais (nun 17 Jahre alt) tut' noch.

Soul E. schrieb:
> Zum Sniffen kannst Du einen Saleae nehmen, mit seriellem Decoder. Einen
> TJA1021 zum Pegelwandeln davor. Das tut's erstmal, bis die eigene SW
> fertig ist. Dann die Funktionen durchprobieren und schauen wo sich was
> ändert.

So hatte ich es hier auf dem Tisch gemacht.
Saleae ist zwar ein mächtiges Tool zum Sniffen solcher Sachen.
Allerdings auch Mühsam.
Egal ob I²C-Verkehr oder nun dieses LIN-Zeugs muss man sich für ein 
wenige Minuten langes Log mitunter mehrere Stunden dran setzen, sich 
durchscrollen und die Bytes einzeln raussuchen.
Effektiver und deutlich Hilfreicher wäre es hier, ein Gerätchen zu haben 
welches mir die aktuellen Statusbytes anzeigt ohne überbordendes 
Firlefanz.
Also einen meiner Mega328PB mit 2x16 LCD.

Was Pegelwandler angeht:
Einen extra Chip als LIN-Transceiver würde ich davor setzen, wenn er mir 
die Breakerkennung abnehmen würde.
Da es das aber nicht gibt würde ich eher Vorwiderstand mit Zehnerdiode 
bevorzugen. ZD 3,3V müsste ich noch irgendwo rumfliegen haben.

Soul E. schrieb:
> An sich ist die Elektronik kein Hexenwerk. Die Kunst ist halt die
> sensorlose Sensorik und der Einklemmschutz. Man muss aus dem Verlauf des
> Motorstromes erkennen was die Scheibe macht. Wind, Dreck in der
> Dichtung, Hand dazwischen oder oben am Anschlag?

Ja, die Variante welche bei den Skoda Roomster verbaut wurden überwachen 
sowohl den Motorstrom via Shunt sowie zusätzlich die Motordrehzahl 
mittels Hallsensor.
Laut der eher ernüchternden Dokumentation gibt es keine Endschalter oder 
vorgegebene Endwerte für Auf/Zu.
Vielmehr muss bei einem POR (Batteriewechsel) jedes Fenster bis zum 
Anschlag auf, und anschließend bis zum Anschlag zu gefahren werden.
Anhand Motorstromverlauf und Drehzahl / blokierter Motor lernt so jedes 
Türsteuergerät wo die Endpunkte sind.

Jürgen Hüser

[Dieter S. (ds1)]

Jürgen H. schrieb:
>
> Die Antwort über h3D könnte nun ebenso ernüchternd sein, oder aber auch
> Konfigurationsdaten beinhalten.

Das ist Diagnose und wurde hier schon beschrieben.

> Denn so wie ich das sehe mit der Pid h26:

Auch das wurde hier schon beschrieben, über PID 0x26 versendet der 
Master seinen Status:

Beitrag "Re: Untersuchung defektes VW Türsteuergerät"

Und der Status des Slave Fensterheber wird mit PID 0x13 bis 0x15 
abgefragt.

[Jürgen H. (dg7gj)]

Hallo...
Eine Rückmeldung noch mal:

Nachdem der Master in der Fahrertür gestern einwandfrei funktionierte, 
wollte ich heute die Türverkleidung wieder dran machen.
Was soll ich sagen...schon wieder tot!

Also nochmal die Beifahrertür auf gemacht und dort den Stecker gezogen.
Neugieriger weise geguckt ob ich dort LIN gegen Masse auch >50Ohm messe.

Mitnichten! 11,95mA bei 11,98V!
Passt also perfekt zu dem 1k PullUp des Masters.
Es war also dieser Slave in der Beifahrertür welcher den 
Isolationsfehler gegen LIN-High verursachte.
Statt 30k eben nur 350 Ohm PullUp.

Knappe 10 Minuten brauchte ich um die fiese Ursache zu finden, siehe 
angehängtes Bild.
Es zeigt die Pins 5-12 des MC33689 von oben nach unten.
Direkt zu erkennen das reichlich Flußmittel zwischen den Pads sitzt.
Schaut man genau zwischen Pads 10 & 11 (10 = VS1 und 11 = LIN) sieht man 
Lötmittelreste.
Offenbar haben diese, zusammen mit dem Flußmittel und möglicherweise 
Luftfeuchtigkeit eine Leitfähigkeit entwickelt die ich als 350 Ohm 
messen konnte.
Zwischen diesen Pins 10 & 11 etwas mit einem Skalpell gekratzt und 
nochmal LIN gegen GND gemessen. 0,34mA statt 54mA!

Fies....richtig fies.

So, der LIN-Bus läuft nun zumindest was den PullUpWiderstand angeht 
innerhalb der LIN-Spezifikation.
Dennoch kommt es da zu neuen Fehlern.

Mucken macht jetzt wieder der Master, und zwar ganz neue.
Seit Reparatur des Slaves kann er das lokale Fahrerfenster zwar noch 
problemlos runter fahren, aber beim hochfahren ignoriert er den Befehl.
Und nein, keine Überstrom- oder Blokierschutzschaltung.
Vielmehr wird das Relais für die Hochfahrrichtung nicht mehr 
angesteuert.

Daher die Frage:
Kennt jemand diese Stecker in Bild 2?
Gibt es da irgendwelche Datenblätter zu, oder besser Hinweise wie man 
diese so entriegelt das man dort einen einzelnen Kontakt entfernen kann?

Würde nämlich notfalls den LIN totlegen wenn er weiter Fehler 
fabriziert.

Jürgen Hüser

[Frank O. (frank_o)]

Jürgen H. schrieb:
> Kennt jemand diese Stecker in Bild 2?

Ja!
Morgen, bei der Arbeit suche ich dir alle Informationen raus und mache 
Bilder vom Werkzeug und wie man das entriegelt.

[Frank O. (frank_o)]

So, die Stecker findest du unter dem Begriff "Saab-Stecker".
Weitere Informationen, die bei uns unter "Bezeichnung" steht, ist "JPT" 
und "MicroT2+JPT".
Für Bilder habe ich leider keine Zeit, aber du wirst sie sowieso mit den 
Suchbegriffen finden.

[Soul E. (soul_eye)]

Frank O. schrieb:
> und "MicroT2+JPT".

Das Steckersystem heisst Micro Timer II und ist von TE Connectivity (AMP 
Tyco).

https://www.te.com/de/plp/connectors-micro-timer-ii/Y30DqX26Ax.html

[Jürgen H. (dg7gj)]

Hmm....
Genau die Steckerserie die ich meine habe ich nicht gefunden.
Nur ähnliche die aber durchweg zwei Verriegelungsebenen haben.

Aber gut, ich werde mich da mal mit Brille und Werkzeug dran setzen.
Werde schon merken wie weit ich diese rote Arretierung rausziehen muss.
Was Ausstechdorne angeht um die Federlaschen solcher Crimpgehäuse aus zu 
stechen habe ich zwei Größen. Eine davon wird wohl passen.

Jürgen

[Alexander (alecxs)]

Ich komm nicht drüber hinweg dass die Werkstatt einfach einen Kabelbaum 
erneuert hat.

[Rüdiger (ruedarno2)]

Folgende Erkenntnisse hatte ich bei meiner langen Reparatur-Odysee.
Skoda Roomster 2007
nur vorne elektrische Fensterheber.

Links vorne: Lin-Master (1k Pullup)

Rechts vorne: Lin-Slave

Das LIN-Fensterhebersystem schien mir nicht am 
LIN-Zentralverriegelungssystem zu hängen, sondern unabhängig davon zu 
sein.

Insbesondere bei Kälte und Feuchtigkeit hat das LIN-Master-Steuergerät 
ausgesetzt und die LIN Kommunikation eingestellt. Im Ofen 100°C für 30 
Minuten hat es wieder für eine Woche funktioniert.
Letztendlich war es eine (nicht sichtbare) kalte Lötstelle beim 
Arbeitswiderstand des Quarzes des Microcontroller im LIN Master.

Daher empfehle ich nach kalten Lötstellen im Master zu suchen und/oder 
verdächtige Lötstellen mit Lötkolben nachzulöten. Das Nachlöten bei mir 
war erfolgreich und es läuft wieder seit 1.5 Jahren.

Deine 300Ohm in der Beifahrerseite sind zwar nicht konform mit der LIN 
Spec, aber eher nicht die Wurzel Deines "instabilen" Problems, weil der 
LIN Open Drain Treiber ziemlich stark ist. Wahrscheinlich bist Du schon 
länger damit so gefahren.

Viel Glück

[Frank O. (frank_o)]

Jürgen H. schrieb:
> Was Ausstechdorne angeht um die Federlaschen solcher Crimpgehäuse aus zu
> stechen habe ich zwei Größen.

Wir haben jetzt Stecker mit gelben Laschen, da sollte das größere 
Werkzeug eigentlich passen. Passt aber nicht. Mit Mühe und Not habe ich 
den einen Kontakt raus bekommen. Dafür musste ich das Werkzeug aber 
nachbiegen.
Bei diesen ganzen Steckern ist das mit dem richtigen Werkzeug ganz 
einfach und mit falschem Werkzeug (es kann ruhig dafür angegeben sein 
und trotzdem ist es nicht passend genug) quälst du dich und das 
Material.

[Jürgen H. (dg7gj)]

Hallo!

Alexander schrieb:
> Ich komm nicht drüber hinweg dass die Werkstatt einfach einen Kabelbaum
> erneuert hat.

Ja, mir kommt langsam die Idee das dieses nicht nötig war.
Aber es half mir etwas, weil ich den Türkabelbaum als Fehlerursache 
ausschließen konnte.

Rüdiger schrieb:
> Folgende Erkenntnisse hatte ich bei meiner langen Reparatur-Odysee.
> Skoda Roomster 2007
> nur vorne elektrische Fensterheber.

Passt perfekt, genau wie meiner!

Rüdiger schrieb:
> Das LIN-Fensterhebersystem schien mir nicht am
> LIN-Zentralverriegelungssystem zu hängen, sondern unabhängig davon zu
> sein.

Mir scheint es auch so zu sein.
Zwar sagt der Schaltplan das der LIN mit am zentralen Kompfortsystem 
J393 hängt, allerdings kann ich den am Bus nicht messen!
Wenn ich J386 (Master, Fahrertür) und J387 (Slave, Beifahrertür) 
abklemme ist der LIN auf 0,00V. Wäre J393 ein Slave, müsste er den LIN 
ja weiter auf High liegen.

Rüdiger schrieb:
> Letztendlich war es eine (nicht sichtbare) kalte Lötstelle beim
> Arbeitswiderstand des Quarzes des Microcontroller im LIN Master.
>
> Daher empfehle ich nach kalten Lötstellen im Master zu suchen und/oder
> verdächtige Lötstellen mit Lötkolben nachzulöten. Das Nachlöten bei mir
> war erfolgreich und es läuft wieder seit 1.5 Jahren.

Ahja...das wäre noch ein Versuch.
Dann baue ich den Master mal wieder aus.

Seit dem ich den Slave repariert habe ist das neue Fehlerbild nämlich 
nervig:
Nach Neustart Kann der Master über LIN das Beifahrerfenster komplett 
bedienen.
Das lokale Fahrerfenster allerdings nur...runter.
Tastbefehle für hochfahren ignoriert er.
Außer - es ist der erste Tastbefehl nach Anlegen der Betriebsspannung.

Nervig!

Frank O. schrieb:
> Bei diesen ganzen Steckern ist das mit dem richtigen Werkzeug ganz
> einfach und mit falschem Werkzeug (es kann ruhig dafür angegeben sein
> und trotzdem ist es nicht passend genug) quälst du dich und das
> Material.

Ja, kenne ich von üblicheren Systemen von gecrimten Steckkontakten wie 
JST und so.
Aber durch den Beitrag von Rüdiger werde ich dann den Master erst mal 
wieder ausbauen.

Jürgen

[Jürgen H. (dg7gj)]

Hallo!

Rüdiger schrieb:
> Daher empfehle ich nach kalten Lötstellen im Master zu suchen und/oder
> verdächtige Lötstellen mit Lötkolben nachzulöten. Das Nachlöten bei mir
> war erfolgreich und es läuft wieder seit 1.5 Jahren.

Das genau war ein richtig guter Tip!

Ich fand selbst mittels USB-Mikroskop keine wirklich verdächtigen 
Lötstellen auf dem Master. Also nachgelötet, allerdings ohne Zugabe von 
frischem Lötzinn.
Das habe ich bewusst vermieden da für mich nicht feststellbar war welche 
Legierung dort ursprünglich verwendet wurde.
Gröbere Lötstellen (Relais, Steckerkontakte usw) mittels Lötkolben, den 
rest mit meiner Heißluftlötanlage so abgegangen das alle lötstellen 
wieder geschmolzen waren.

Tja...danach fief es wieder....seit Drei Tagen sitzt der LIN-Master 
wieder in der Fahrertür und läuft ohne Probleme.

Vielen dank an Rüdiger!

Jürgen

[Rüdiger (ruedarno2)]

Das freut mich. :-)
Viel Glück das es wieder wie bei mir dauerhaft läuft.
LG

[Matthias K. (kostelectronics)]

Hallo zusammen,
Ich habe auch so ein Steuergerät hier auf dem Tisch, welches natürlich 
nur dann spinnt, wenn ich es aus den Händen gebe. Aber das ist nicht das 
Thema.

Ich habe mit dem Picoscope den LIN-Bus überwacht. Leider fehlt mir die 
Erfahrung mit solchen Sachen. Deshalb die Frage: Woran erkenne ich, ob 
das Steuergerät einen "request" zu einem anderen Teilnehmer macht und 
dieser unbeantwortet bleibt, Siehe Beitrag von @Jürgen.H

Ich habe mal einen Screenshot angehängt, was mein Steuergerät dauernd 
sendet ausserhalb des Fahrzeugs.
Hier meine Interpretation.
als erstes wird an die Adresse 0xA6 die 4 Bytes 0x49 0x00 0x40 0x00 + 
CRC gesendet.
Als zweites wir die Adresse 0xD3 angefragt, aber da kommt nichts zurück.

Stimmt das in etwa oder was verstehe ich falsch?

Es geht mir nur darum etwas zu lernen :)

LG Matthias

[Dieter S. (ds1)]

Zur Bedeutung der ID 0x26 wurde hier ja schon einiges geschrieben (0xA6 
ist der "Protected Identifier" von 0x26).