Verstärker tot nach Software-Update
Nach langem mitlesen hier im Forum - und vielen Dingen die ich von Euch gelernt habe und wofür ich mich hiermit recht herzlich bedanken möchte - muss ich nun auch mal eine Frage stellen bzw. Euren Rat suchen:
Hatte meinen E60 BJ 2008 diese Woche beim Freundlichen zum Software Update des gesamten Fahrzeugs. Leider hat der Verstärker das Update nicht mitgemacht und ich habe nun keinen Ton (Musik, FSE, PDC, etc.). Ist ein HIFI Professional DSP ab Werk - keine Nachrüstung oder Modifikation. Der Freundliche bietet mir einen neuen Verstärker (65129181743) und weil er ihn geschossen hat mit großzügigem Rabatt, womit das Teil aber immer noch mehr als 500 EUR kosten dürfte.
Nun frage ich mich wie die Chancen stehen, dass man das vorhandene Teil vielleicht noch retten könnte. Ich habe einen Laptop mit DCAN Interface womit ich hier und da mal eine Diagnose mache und auch schon mal was codiert habe. An's Flashen habe ich mich bisher aber nicht getraut, weil mein Laptop schon etwas älter ist und auch weil ich kein Batterieladegerät habe. Deswegen bin ich ja für's Software-Update lieber zum Freundlichen gefahren ...
Nachdem der Verstärker aber im Moment gar nicht funktioniert denke ich könnte ich mit einem Flashversuch vielleicht nicht mehr viel kaputt machen. Oder doch? Bzw. geht das jetzt überhaupt noch? Würde natürlich nur den Verstärker flashen wollen ohne irgendein anderes Steuergerät anzutasten (wenn das geht). Habe WinKFP auf meinem Laptop was recht schlank zu sein scheint und auf meinem alten Laptop noch einigermaßen flott laufen sollte. Vergleich Identifikation vor bzw. nach dem Update:
ADR Gen. name JobStatus SGBD GROUP Part No. VarI DiaI CoI HwI SW-No FSV SW-No OSV SW-No MCV SW-No res Date Supplier Name
VORHER: 37 AMP OKAY AMP_60 D_AMP 9166899 464E 0670 3 A23 8.3.2 3.1.3 0.9.114 0.0.0 10.06.2008 Harman Becker Au Top HIFI Verstärker
NACHHER: 37 AMP OKAY AMP_60 D_AMP ********* 464E 0670 3 A23 8.9.0 3.1.3 0.9.114 0.0.0 10.06.2008 Harman Becker Au Top HIFI Verstärker
Ich kann auch die komplette Identifikation posten wollte meinen Beitrag nicht unnötig aufblasen.
Adr Grobname SGBD HW-Nr. ZB-Nr. Teile-Nr CoI HwI SW-Nr FSV SW-Nr OSV SW-Nr MCV SW-Nr RES
37 AMP AMP_60 6935700 9166897 ********* 3 A23 8.9.0 3.1.3 0.9.114 0.0.0
Wie schätzt Ihr meine Chancen? Könnte ich Glück haben und das Ding wieder zum Leben erwecken? Ginge das eventuell tatsächlich ohne irgendwelche anderen Steuergeräte antasten zu müssen (und vielleicht noch mehr kaputt zu machen)? Worauf müsste ich denn dann bei der Software-Version achten? Wie oben ersichtlich war ja ab Werk Version 8.3.2 drauf und der Versuch des Freundlichen 8.9.0 aufzuspielen ist scheinbar gescheitert. Vermute ich muss darauf achten auch irgendwie 8.9.0 draufzuspielen damit sich die Software mit den anderen Steuergeräten verträgt?
Habe hier und da Hinweise gelesen, dass ein ICOM Interface verwendet werden soll wenn man Geräte flashen will die am MOST-Bus hängen. Wie sieht das denn bei einem E60 BJ 2008 und meinem Verstärker aus? Geht das gar nicht ohne ICOM?
Und wie steht's ohne Ladegrät? In einem anderen Thread hier im Forum habe ich gelesen dass jemand mit WinKFP und DCAN Interface seine IHKA in 3 Minuten geflasht hat. Okay das heißt ja nicht dass AMP flashen genauso schnell geht wie IHKA. Und die hängt auch nicht am MOST. Meine 91 Ah AGM-Batterie ist erst zwei Jahre alt und noch gut in Form. Ich würde einen Versuch natürlich nur bei voller Ladung wagen.
Vielleicht noch einen Hinweis zu meiner Umgebung: ich wohne nicht in der EU und kann schlecht mit meinem Auto mal eben bei jemandem in Deutschland vorbeikommen der mir vielleicht freundlicherweise Hilfe anbietet oder den Verstärker mal schnell irgendwo zur Reparatur hinschicken. Unmöglich ist der Versand zwar nicht aber mit relativ hohem Aufwand (Kosten und Zollbürokratie) verbunden. Ähnlich schwierig gestaltet es sich jemanden zu finden von dem ich mir ein Batterieladgerät leihen könnte. Und mit Leuten die codieren und flashen können sieht es hierzulande auch eher schlecht aus. Ich kenne zwar die eine oder andere Werkstatt die ein ICOM bei sich rumliegen haben aber sonderlich vertrauenserweckend verliefen meine Gespräche mit denen bisher nicht. Da ziehe ich es vor wenn möglich was dazuzulernen und selbst Hand anzulegen.
Beste Antwort im Thema
Die Software fürs Schiebedach muss auf den aktuellsten Stand gebracht werden da die Anlernkurve mit der neueren Dichtung eine Andere ist und somit der Motor mehr Strom benötigt. Und bei altem Softwarestand geht das Schiebedach dann in den Einklemmschutz da der Motorstrom die Sollwerte übersteigt.
Keine Codierung sondern der aktuellste Softwarestand ist nötig.
Dichtung wechseln und dann einfach das Dach komplett neu anlernen - mehr muss nicht getan werden wenn du die aktuellste Software auf das Schiebedach geflashst hast.
47 Antworten
Bin mir nicht sicher ob ich richtig verstanden habe in welchem Menü ich prüfen soll ob alle Häkchen bei beiden Schlüsseln an sind. Habe bei mir im CCC nur das Menü gefunden welches auf beiliegendem Screenshot zu sehen ist. Die Einstellungen dort müssten ja passen.
Hatte mir das erneute Initialisieren der Lenksäulenverstellung / Hallsensoren mit dem Laptop für's Wochenende vorgenommen aber unter der Woche noch schnell mal folgende Methode ausprobiert die ich hier gefunden habe:
1. Motor an, Lenkrad nach ganz unten, dann Zündung aus und Tür auf
2. Tür zu, Motor an, Lenkrad nach ganz oben. Motor aus, Tür auf
3. Tür Zu, Motor an, alles wie gewünscht einstellen und danach sollte alles wieder gehen
Was soll ich sagen? Es hat funktioniert! 🙂
In Anbetracht der Tatsache, dass ich die Lenksäulenverstellung bereits mit dem Laptop/Diagnosesystem angelernt/initialisiert hatte und das Problem nicht gelöst wurde, hatte ich mir von dieser simplen Vorgehensweise nicht viel versprochen. Dass es damit funktioniert hat hat mich total überrascht. Somit auch ein ganz herzliches Dankeschön an Krypton aus dem E60-Forum der diesen Tipp dort gepostet hatte.
Das Prozedere mit der Tür öffnen, etc. ist nicht notwendig. Manuell initialisieren (und tatsächlich verliert das Steuergerät ab und zu die genaue Position, mit der Zeit entwickeln die Sensoren wohl ein kleines Genauigkeits-Problem, denn der Soll-Positions-Speicherinhalt bleibt bestehen) reicht:
https://www.newtis.info/.../20DNlMP
Danke für den Link. Interessanter Einblick in die Details der Lenksäulenverstellung. Ich guck zwar auch öfter in's TIS, den Artikel hatte ich aber nocht nicht gesehen.
Jetzt wo das Problem mit der Lenksäulenverstellung gelöst ist bleibt noch die zweite Baustelle: dass sich meine FSE-Telefongesprächspartner mit einer gewissen Verzögerung selbst hören. Zu meinen oben erwähnten Versuchen 2 a) bis h) gesellt sich nun noch die Erkenntnis, dass der Freundliche mir mein Baby nicht nur mit 'nem toten Verstärker sondern auch einem CCC mit Programmierabbruch zurückgegeben hat. Den Verstärker konnte ich ja dank Hilfe von CCC88 hier im Tread wieder zum Leben erwecken.
Dass mit dem CCC was nicht stimmt hätte ich gar nicht gedacht weil eigentlich alles funktioniert. Da ich ISTA noch nicht allzu oft verwendet habe ist mir der blaue Hintergrund um's CCC erst gar nicht aufgefallen. Dann dachte ich noch das ist ja 'ne nette grafische Darstellung der Eigenschaft dass das CCC fünf Steuergeräte enthält ... bis ich dann im Kleingedruckten / der Legende gelesen hatte dass blau für "ECU with programming abort" steht.
Jetzt frage ich mich natürlich ob das was mit dem FSE Problem zu tun haben könnte? Und vielleicht auch mit der Tatsache, dass ich nicht mehr per DCAN auf die TCU zugreifen kann obwohl ich 2016 mit dem DCAN-Kabel auf noch ein Backup der TCU erstellt hatte. Könnte also das Gateway im CCC was abbekommen haben?
Denke den Programmierabbruch sollte ich doch auf jeden Fall versuchen in Orndung zu bringen, oder? Habe die Woche schon begonnen über das CCC zu lesen und gleich verstanden dass ich da höllisch aufpassen muss, weil dessen 5 Steuergeräte nur in bestimmter Reihenfolge geflasht werden dürfen und das Flashen teilweise Stunden dauert. Mit den Stunden hätte ich zwar kein Problem aber mit der Tatsache, dass ich nach wie vor keine externe Spannungsversorgung habe. Somit stellt sich die Frage ob ich mit meiner aktuellen Ausrüstung DCAN-Kabel, NCS-Expert, WinKFP, etc. noch was ausrichten kann? Zum Beispiel durch Auslesen bestimmter Daten (Fahrzeugauftrag?/Identifikation?) den Fehler auf ein bestimmtes Steuergerät im CCC einzugrenzen oder vielleicht sogar noch eine Komponente (Gateway?) zu flashen bei der der Vorgang nicht allzu lange dauert?
Freue mich über Tipps und Ratschläge während ich gleichzeitig mal versuche mehr über das CCC zu lesen und zu lernen.
Bei meinem Studium der Softwarestände und ZB-Nummern ist mir aufgefallen, dass bei meiner Rettungsaktion für den Verstärker dessen AIF nicht aktualisiert wurde. Da steht noch immer ZB-Nummer 9166897, VIN ÿÿÿÿÿÿÿ und 10.06.2008 drin obwohl ich erfolgreich auf 9181743 geflasht habe und die Identifikation auch 9181745 listet.
Könnte das daran liegen, dass bei meinem WinKFP der Haken für "AIF Schreiben" nur bei Daten und Programm und nicht bei Experten- und Komfortmodus gesetzt ist? So ganz verstehe ich diese vier Optionen ehrlich gesagt auch nicht. Wenn man flasht schreibt man dann nicht Daten und Programme? Gibt es auch Steuergeräte bei denen nur Daten ohne Programme geschrieben werden? Und wenn der Haken im Experten- und Komfortmodus aus ist dann bringt es auch nichts wenn er bei Daten und Programme an ist?
Kann ich das AIF eigentlich im Nachhinein aktualisieren ohne das komplette Gerät neu flashen zu müssen? Habe mal was von Tool32 gelesen aber fürchte das ist sehr kompliziert/kryptisch zu bedienen.
Wofür ist ein aktuelles AIF eigentlich wichtig? Glaube irgendwo gelesen zu haben, dass das AIF nur für die Diagnose relevant ist aber nicht für die Funktion/Zusammenarbeit der Geräte untereinander im Fahrzeug. Ist das korrekt? Dann kann es wohl nicht der Grund dafür sein, dass sich meine Bluetooth-FSE Gesprächspartner mit etwas Verzögerung selbst hören. 🙁
Und wieso gibt es eigentlich zwei getrennte Datensätze: Identifikation und Anwenderinformationsfeld? Da steht doch fast das gleiche drin. Das AIF soll sogar bei manchen Steuergeräten nur eine begrenzte Anzahl beschrieben werden können, oder habe ich da was falsch verstanden? Ist das AIF dann so eine Art "Logbuch" der Softwarestände während die Identifikation der aktuelle Stand der Dinge ist? Falls ja wozu braucht man so ein "Logbuch"? Und wiese nennt man es "Anwender"-Informationsfeld? Was für ein "Anwender"?
Ähnliche Themen
Ich grätsch mal dazwischen. Wenn der Händler dir einen großzügigen Angebot macht für einen neuen Verstärker, dann würde ich den auf jeden Fall annehmen. Dann hast du ja einen neuen Verstärker drin. Den den du jetzt hast du es ja über zehn Jahre alt, denk mal darüber nach
Aber der Verstärker funktioniert doch schon längst wieder. Der war ja auch nie wirklich kaputt. Dem Freundlichen war er halt beim Softwareupdate des Gesamtfahrzeugs "abgeschmiert" und mit seinen Methoden (ISTA) nicht widerzubeleben. Mit WinKFP, den Tipps und der Ermutigung von CCC88 konnte ich den Verstärker wie hier im Thread berichtet problemlos und innerhalb von 9 Minuten flashen. Seitdem läuft er wieder einwandfrei.
Warum stelle ich dann jetzt noch Fragen zum AIF?
1) Erstens weil nach dem Softwareupdate des Gesamtfahrzeugs die Gesprächspartner meiner Bluetooth-Freisprecheinrichtung ein Echo von sich selbst hören. Ob das noch mit dem Verstärker zu tun hat bin ich mir nicht sicher (ISTA zeigt z.B. auch einen Programmierabbruch beim CCC und die TCU ist per DCAN nicht erreichbar). Ich bezweifle sogar dass das FSE-Problem vom Verstärker kommt. Ich versuche aber der Reihe nach alle möglichen Ursachen auszuschließen und fange halt mal beim Verstärker an. Da ist mir aufgefallen dass bei meinem Flashvorgang das AIF nicht aktualisiert wurde. Könnte den Verstärker jetzt natürlich einfach noch einmal Flashen und "AIF schreiben" dabei anklicken. Aber warum mit Kanonen auf Spatzen schießen wenn man das AIF vielleicht auch einzeln updaten kann? Ob das geht das hatte ich hier gefragt. Und auch ob das AIF überhaupt irgeneine Relevanz für die Zusammenarbeit unter den Steuergeräten im Fahrzeug hat. Ich glaube nämlich mal irgendwo gelesen zu haben, dass das AIF nur für die Diagnose relevant ist. Falls dem so ist, kann es ja nicht die Ursache des FSE-Problems sein. Falls es doch eine Rolle spielt könnte die fehlende Aktualisierung vielleicht der Grund dafür sein dass hier ein paar Steuergeräte "aneinader vorbei reden" und es somit zu dem Echo kommt. Nagel mich nicht fest, aber könnte mir vorstellen dass für die einwandfreie FSE-Funktion TCU, CCC (ASK? MOSTGW?) und AMP fehlerfrei miteinander kommunizieren müssen.
2) Zweitens weil sich bei meinem Studium der Themen Flashen, Codieren, FA, AIF, ZB-Nummern, Identifikation, etc. einige Fragen ergeben haben die mich unabhängig von meinem Problem 1) auch einfach interessieren würden. Es gibt in zig Foren hunderte von Beiträgen zu diesen Themen. Aber die meisten sind sehr darauf fokussiert Probleme zu lösen nach dem Motto "wie finde ich die passende ZB-Nummer?". Da beschäftigt man sich weniger damit warum manche Dinge so sind wie sie sind. Wenn Du mal nach einer vernünftigen Erklärung suchst wie ZB-Nummern eigentlich zustande kommen und wie sie mit Teilenummern zusammenhängen und wie letztere eigentlich aufgebaut sind, dann wird die Luft schon dünn. Ich hatte mal vor längerer Zeit in einem englischen Thread was dazu gelesen. Jetzt suche ich ihn wieder - leider bisher erfolglos. Hier hatte ich mir erlaubt mal so eine provokante Frage wie die zu stellen, warum man zusätzlich zur Identifikation noch ein Logbuch à la AIF braucht, das noch dazu nur eine begrenzte Anzahl von Aktualisierungen erlaubt und wer eigentlich der "Anwender" des Anwenderinformationsfelds ist.
Wenn CCC ein Programmierabbruch hat und ist blau sollte zu erst mal das behoben werden. Und das ganze wird mit einem ICOM über MOST geflasht. Und wenn kein Haken gesetzt wurde bei AIF Komfortmudus wird das ganze auch nicht im AIF geschrieben.
Ich stimme Dir zu. Geht bei mir allerdings nicht so schnell, weil ich dafür noch ein ICOM und Labornetzteil bestellen muss. 🙂
Könnte man fragen warum gehe ich nicht zum Codierer? Na ja, weil ich in Israel bin und hier keinen Codierer kenne. Ein Gespräch mit einer freien Werkstatt die ein ICOM hatte verlief nicht sehr vertrauenserweckend und ich glaube die Chancen stehen schlecht hier einen Codierer zu finden der das Thema mit der Sorgfalt und Gewissenhaftigkeit angeht wie wir das aus Deutschland kennen. Für das Softwareupdate des gesamten Fahrzeugs bin ich deswegen ja extra zum Freundlichen gegangen. Von dem hieß es dann zuerst drei Steuergeräte hätten das Update nicht überlebt. Danach hätten sie noch zwei davon retten können aber der Verstärker wäre tot ...
Dass ich den Verstärker mit meinem DCAN-Flash wieder zum Leben erwecken konnte (dummerweise ohne das AIF geschrieben zu haben) wisst Ihr ja. Und so langsam kristallisiert sich heraus was mir das Update beim Freundlichen noch so beschert hat (Programmierabbruch CCC). Ich hänge hier mal meine Identifikation, AIF und Infospeicher dran. Vielleicht erkennt hier jemand noch weitere Probleme. Beim CCC fällt mir auf, dass nur das CCC-A aktuell ist. Die anderen vier sind noch auf dem Stand von 2008. Funktionieren tut überraschenderweise alles einwandfrei. Nur Gesprächspartner der Bluetooth-FSE hören ihr Echo und ISTA zeigt einen Programmierabbruch.
Eventuell könnte ich nochmal zum Freundlichen gehen und betteln den Programmierabbruch des CCC zu beheben. Sonderlich begeistert wird der aber nicht sein weil das Update ausdrücklich unter Ausschluss jeglicher Gewähr erfolgt war. Auch waren die froh von den ursprünglich drei toten SG noch zwei "gerettet" zu haben - sofern man ein CCC mit Programmierabbruch noch als "gerettet" bezeichnen mag. Wenn ich da hingehe müsste ich denen wahrscheinlich schon ganz genau sagen was sie machen sollen damit die da nochmal Hand anlegen. Fragt sich natürlich auch ob die mit ihrem ISTA da überhaupt noch was ausrichten können. Was meint Ihr?
Ansonsten ergibt sich die Frage ob ich noch irgendwas mit meinem DCAN-Kabel und ohne Labornetzteil ausrichten kann? AIF vom AMP schreiben? Fehler per Diagnose weiter eingrenzen? TCU ist per DCAN nicht erreichbar (obwohl ich mal ein Backup von der Konfiguration per DCAN gemacht habe) und FSE-Telefonieren geht (nur mit Echo).
Sonst müsste ich halt als nächstes ein Labornetzteil bestellen und auch ein ICOM wenn Ihr sagt das es per DCAN und mit gutem Netzteil auch bei größter Sorgfalt zu riskant wäre zu Versuchen den Programmierabbruch des CCC zu beheben.
Beim Labornetzteil habe ich ein Auge auf das hier geworfen: QJ-PS60SWIII. Was meint Ihr? QJE scheint der Hersteller zu sein, der auch das Maas PS50 hergestellt hat von dem es mittlerweile nur noch vereinzelte Restposten gibt. Preislich scheint das Teil so zwischen 150 und 200 EUR zu liegen und 60A sind ja auch nicht schlecht.
Beim ICOM sehe ich das richtig, dass für meinen Fall (nur E60) ein China-Klon ICOM A2+B für 200 EUR das vernünftigste Preis-Leistungsvehältnis darstellt?
AIF ist alles aktuell
Entscheitend ist was im FS drin steht und ob SG blau ist.
TCU sollte komplett abgeklemmt werden und LWL verbunden werden.
Oder eine gebrauchte TCU kaufen und mit ICOM codieren.
CCC besteht aus 5 Steuergeräten welcher Teil hat hier einen Programmierabruch ?
Gpanter, danke dass Du mein AIF durchgesehen hast. 🙂
Nur das CCC ist blau (Screenshot anbei). Anbei noch der FS. Da steht aber nichts drin was nicht vor dem Update auch schon drin war. Im IS den ich gestern hochgeladen hatte sind aber ein paar Kommunikationsprobleme.
Wie finde ich denn raus welcher Teil des CCC den Programmierabbruch hat? Bin im SG-Baum auf jedes SG aber ISTA wollte mir so nicht verraten welches SG den Abbruch hat. Und in der Identifikation von jedem Gerät stand "ECU responding properly" (Screenshots anbei). Genau genommen zeigt der Baum ja nur vier (GW, ASK, ANT und BO). Was ist eigentlich mit dem fünften (CCC-A)?
Die TCU antwortet übrigens auch "properly" und ist grün.
Zitat:
@TLV schrieb am 10. September 2019 um 17:39:22 Uhr:
Gpanter, danke dass Du mein AIF durchgesehen hast. 🙂Nur das CCC ist blau (Screenshot anbei). Anbei noch der FS. Da steht aber nichts drin was nicht vor dem Update auch schon drin war. Im IS den ich gestern hochgeladen hatte sind aber ein paar Kommunikationsprobleme.
Wie finde ich denn raus welcher Teil des CCC den Programmierabbruch hat? Bin im SG-Baum auf jedes SG aber ISTA wollte mir so nicht verraten welches SG den Abbruch hat. Und in der Identifikation von jedem Gerät stand "ECU responding properly" (Screenshots anbei). Genau genommen zeigt der Baum ja nur vier (GW, ASK, ANT und BO). Was ist eigentlich mit dem fünften (CCC-A)?
Die TCU antwortet übrigens auch "properly" und ist grün.
Mit Tool32 kann man jedes Steuergerät auf den Flash Status prüfen.
Hier ist aber kein Steuergerät blau.
Also alles passt hier.
Das CCC ist hier blau Umrandet und ist ganz normal.
Hey das ist ja eine echt gute Nachricht! Da fällt mir ein Stein vom Herzen dass mein CCC keinen Programmierabbruch hat. Aber irgendwo ist ja noch der Wurm drin, denn meine FSE Gesprächspartner hören mit etwas Verzögerung ein Echo von sich selbst und im Infospeicher sind ein paar Hinweise auf Kommunikationsprobleme unter den Steuergeräten.
Wenn's nicht am CCC liegt, dann vielleicht doch an der TCU? Bis auf das Echo funktioniert die TCU aber einwandfrei. Mit NCS (und DCAN) kann ich aber nicht auf dessen Codierung zugreifen (Fehlermeldung anbei) was in der Vergangenheit ging. Mir fällt auf dass die TCU beim Softwareupdate ein neues Produktionsdatum (15.10.2009) erhalten hat. Vorher war das der 7.8.2007. Ist das nicht komisch? Es kann doch nur ein Datum geben an dem eine Komponente hergestellt wurde, oder? Kann da der Freundliche vielleicht was Falsches draufgeflasht haben?
Coole Sache übrigens dieses Tool32, dass Du da erwähnt hast. Da kann man ja echt viel damit machen. Hab gleich mal den Programmierstatus aller CCC-Komponenten und der TCU überprüft: ist auf "1" - also wohl in Ordnung. Sah so aus also könnte ich mit dem Tool32 auch das AIF vom AMP aktualisieren ohne das ganze SG nochmal flashen zu müssen. Liege ich da richtig und sollte ich da etwas bestimmtes beachten? Falls nicht könnte ich das ja mal in Ordnung bringen. Vielleicht hilft's auch beim FSE Problem? Bisher hat mir keiner geantwortet ob AIF nur zur Diagnose ist oder auch für die Zusammenarbeit von SG untereinander.
Zitat:
@TLV schrieb am 10. September 2019 um 22:25:15 Uhr:
Hey das ist ja eine echt gute Nachricht! Da fällt mir ein Stein vom Herzen dass mein CCC keinen Programmierabbruch hat. Aber irgendwo ist ja noch der Wurm drin, denn meine FSE Gesprächspartner hören mit etwas Verzögerung ein Echo von sich selbst und im Infospeicher sind ein paar Hinweise auf Kommunikationsprobleme unter den Steuergeräten.Wenn's nicht am CCC liegt, dann vielleicht doch an der TCU? Bis auf das Echo funktioniert die TCU aber einwandfrei. Mit NCS (und DCAN) kann ich aber nicht auf dessen Codierung zugreifen (Fehlermeldung anbei) was in der Vergangenheit ging. Mir fällt auf dass die TCU beim Softwareupdate ein neues Produktionsdatum (15.10.2009) erhalten hat. Vorher war das der 7.8.2007. Ist das nicht komisch? Es kann doch nur ein Datum geben an dem eine Komponente hergestellt wurde, oder? Kann da der Freundliche vielleicht was Falsches draufgeflasht haben?
Coole Sache übrigens dieses Tool32, dass Du da erwähnt hast. Da kann man ja echt viel damit machen. Hab gleich mal den Programmierstatus aller CCC-Komponenten und der TCU überprüft: ist auf "1" - also wohl in Ordnung. Sah so aus also könnte ich mit dem Tool32 auch das AIF vom AMP aktualisieren ohne das ganze SG nochmal flashen zu müssen. Liege ich da richtig und sollte ich da etwas bestimmtes beachten? Falls nicht könnte ich das ja mal in Ordnung bringen. Vielleicht hilft's auch beim FSE Problem? Bisher hat mir keiner geantwortet ob AIF nur zur Diagnose ist oder auch für die Zusammenarbeit von SG untereinander.
Schon mal das Handy aus dem CCC gelöscht und neu eingerichtet ?
Bluetooth Antenne auch geprüft ?
Handykopplung hatte ich schon mal gelöscht, aber nun vorsichtshalber nochmal das CCC geresettet (2 Eject + Lautstärkeknopf) und zwei verschiedene Handys erneut mit dem Fahrzeug gekoppelt. Problem besteht weiterhin.
Bluetooth Antenne habe ich noch nicht geprüft. Werde ich mich heue einlesen. Aber eigentlich funktioniert die Bluetooth-FSE ja. Man kann durchaus damit telefonieren. Nur werden meine Gesprächspartner wahnsinnig weil sie jedes ihrer Worte mit kurzer Verzögerung selbst noch einmal hören.
Die TCU scheint also größtenteils - wenn nicht gar ganz - zu funktionieren. Fragt sich ob dieses Echo-Problem in der TCU entsteht oder durch irgendein Abstimmungsproblem mit anderen beteiligten SG [CCC(ASK?,GW?), AMP?, ...?]. Stutzig macht mich die Tatsache, dass ich per NCS und DCAN nicht auf die Codierung der TCU zugreifen kann obwohl dies in der Vergangenheit ging und bei anderen SG im MOST Verbund auch geht.
So, habe nun am Wochenede einen "Ausflug" in die Beschreibungen von TCU/MULF im TIS unternommen. War wie eine Reise zurück in die Mobilfunk-Steinzeit - vor allem wenn man sich anschaut für welche Modelle von Handys es Snap-in Adapter gab. 🙂
Hab auch gelesen, dass die am Dach verbaute Mobilfunkantenne GSM 900/1800 unterstützt und mich gefragt inwiefern es dann überhaupt noch nützlich (oder vielleicht sogar kontraproduktiv?) wäre heute ein modernes Mobiltelefon in einen Universal-Snap-In-Adapter zu stecken wo die Dinger in Ballungsräumen doch vermutlich viel lieber per 3/4/(5)G verbunden sind als per GSM 900/1800.
Ansonsten ist die TCU scheinbar ein richtiger Tausendsassa - unglaublich was da an Funktionen hineingepackt sind. Dauert zu flashen sicher eine Ewigkeit? Und cool was man da mit Tool32 so alles lesen und schreiben kann (z.B. Service-Zentrale/Notrufnummern). Hab' noch nichts geschrieben, bin aber beeindruckt. Und jetzt kenne ich auch endlich die fachmännische Bezeichnung für mein Problem: scheinbar funktioniert bei mir die für die "Vollduplexübertragung erforderliche Echokompensation" nicht. Leider bringt mich das nicht näher an die Lösung des Problems. 🙁
Im Großen und Ganzen hatte ich den Eindruck dass mein Problem eigentlich nicht an der Bluetooth-Antenne liegen sollte weil man ja telefonieren kann - nur mein Gesprächspartner hört alles was er sagt mit kurzer Verzögerung noch einmal. Habe gelesen in der TCU steckt ein Sprachverarbeitungssystem. Dummerweise hat mein CCC auch eines und das TIS war nicht eindeutig welches von beiden nun eigentlich die Telefonate verarbeitet. Weiss das jemand? Hier steht wenn die Headunit ein Sprachverarbeitungssystem hat hängt das Mikrofon da dran. Hier steht (zugegeben nicht exakt für den E60) dass die Anwendungssoftware des Radios schuld sein kann wenn der Gesprächspartner beim Telefonieren ein Echo hört. Hier steht, dass man die TCU neu codieren muss wenn TCU, ASK oder CCC getauscht wurde (okay wurde nicht getauscht aber geflasht). Hätte gerne probehalber eine leere MAN-Datei an die TCU geschickt - geht aber nicht weil ich per DCAN keinen Zugriff auf die TCU habe. Kann ich die Kodierung eigentlich auch anders (Tool32?) auf Werkseinstellungen zurücksetzten?
So langsam schwirrt mit der Kopf bei all den komplexen Zusammenhängen und was noch so alles die Echokompensation vermurksen könnte. Also dachte ich ich bringe zur Abwechslung mal das AIF vom AMP in Ordnung - jetzt wo ich mich nach dem Hinweis von Gpanter auch mal etwas mit dem Tool32 beschäftigt hatte. Habe auch einiges an Recherche betrieben welche Argumente ich schreiben muss. Leider klapp's trotzdem nicht (zuerst "ERROR_TESTER_SERIAL_NR", dann "ERROR_EXHAUST_REGULATION_OR_TYPE_APPROVAL_NR"😉. Hat jemand Tipps warum?
Hier meine 9 Argumente:
apiJob("AMP_60","aif_schreiben","meine17stelligeVIN;230519;9181743;9181744;0000000;000000;087661247;222554;0499PB0F330A",""😉