Beiträge von gunter

Zitat von Töfflibueb

Wieso fährst Du eigentlich den Barometer und die Lambdasonde gleichzeitig?

Weil es den Aufwand reduzierte.
Weil nur eine Änderung notwendig war.
Weil es eine einfache Änderung war.
Weil es fehlerträchtig ist, mehrere Parameter gleichzeitig zu ändern.
Weil ich am Unterschied zu vorher interessiert war.
Weil der Motor bereits sauber lief.
Weil ich weiss, wie die Logfiles ohne Barokorrektur ausgesehen haben.
Weil es funktioniert.

Zitat

Beide Systeme verfolgen das gleiche Ziel, die Anpassung des Gemisches auf unterschiedliche Druckverhätnisse. Du fährst also 2 Systeme die einander nicht brauchen weil sie beide dasselbe machen.

Mit der gleichen Begründung könnte auch der Lufttemperatursensor entfernt werden. Und warum überhaupt mehr als eine Zelle in der Map? Unnötiger Aufwand, ein Fixwert für den gesamten CL reicht doch aus, die Gemischregelung macht das schon ...

Zitat

Meine Idee war, das Geruckel und Gespotze beim Warmlaufen, das ich immer noch der Lamdasonde zuordne, zu eliminieren, indem ich auf die Lamdasonde verzichte.

Den Zusammenhang zwischen Warmlaufphase und Gemischregelung sehe ich nicht so ohne weiteres. Logfile?

Ich fahre aus der Garage mit kaltem Motor direkt durch eine 30-km/h-Zone, im zweiten Gang mit 1600 - 1800 rpm, ohne Geruckel oder so. Selbst die Honda könnte es kaum besser. Millionen von Autos machen das genau so, nicht mit Euro 2 oder Euro 3, sondern mit Euro 5, wo die Emissionen noch einmal auf die Hälfte reduziert wurden. Es scheint also nicht an der Gemischregelung zu liegen.

Zitat von gunter

die Reichweite einer Tankfüllung lag innerhalb der gewohnten Streuung.

Derzeit ist die gelochte Airbox mit dem Schnorchel zusammen eingebaut, und als Tendenz ergibt sich eine leicht erhöhte Reichweite (ein Plus von ca. 10 km) pro Tankfüllung (kleiner Tank). Das lässt sich nur mit Änderungen im Open Loop erklären, wahrscheinlich ist die Adaption an den Luftdruck über die Barokorrektur feiner als über AFV, der nach Grundeinstellung um 5% schwankt, und spart so ein bisschen Brennstoff.

Ich denke mal, bis Du Dein Skript fertig hast, speichert EcmSpy auch die Hits mit in der Map ab.
Der Rest wird bereits exportiert, sonst könnte MyMaps nicht gefüllt werden ...

@mods: könntet Ihr vielleicht die EcmSpy postings zu einen eigenen Thread herauslösen? Mit EcmDruid hat das ja gar nichts zu tun. Danke!

Für die paar Zellen würde ich noch nicht mal den Taschenrechner holen.

In die Software wandert das, was ich brauche, weil ich seit 2005 nicht nur 100% meiner Arbeitszeit, sondern dazu auch noch ca. 50% meiner Freizeit vor dem Rechner verbringe.

Schreib Dir doch schnell einen Dreizeiler in VBA, der das .msq-File in Excel einliest. Dort stehen alle wichtigen Daten drin.

Ich hab's noch mal neu hochgeladen, bei der Gelegenheit auch gleich die Tabellen aktualisiert. Ändert sich doch ab und zu noch etwas.

Ich schau es mir heute abend mal an. Wahrscheinlich ist das Archiv kaputt.

Vielleicht noch eine Anmerkung zur Nützlichkeit. Wie Pfeffi auf dem letzen SWS bemerkte: "bei mir geht's in jede Richtung rauf oder runter ... wie soll ich dann mit EGO Corr. ausgleichen?" Das wäre - wenigstens ansatzweise - eine Möglichkeit. Das ist natürlich immer noch ein bisschen ein Henne-und-Ei-Problem, denn die Einstellung der Baro Corr. und ABP Corr. erfordert eigentlich die Kontrolle durch den AFV, aber wenn die Maps noch nicht gut sind, geht das nicht, und umgekehrt natürlich genau so. Aber, sei es wie es sei, die Kurven oben zeigen, das ein Kennfeld mit der dynamischen Druckkorrektur auf jeden Fall besser anzupassen ist, als ohne.

Warum sollte ich den AFV blockieren? Ich habe immerhin zwei Tage investiert, die Einspritzung auf den Nappex abzumappen. Dann ist doch klar, dass der AFV stabil ist.

Testfahrt Nr. 3, bei einem Luftdruck in Frankfurt von 1028 hPa. Folgende Änderungen wurden vorgenommen: Austausch der geschlossenen Serien-Airbox gegen eine sehr moderat gelochte Airbox, ca. 20 Bohrungen im Durchmesser von 12 mm. Diese Logfahrt ist kürzer als die bisherigen, da die prinzipielle Funktion der Höhenkorrektur bereits geprüft wurde, und umfasst deshalb nur ca. 70% der bisherigen Fahrten. Ich habe mich bemüht, die Grafik so zu skalieren, dass es den früheren Grafiken entspricht. Logfile, Grafik

Die Sondenspannung, angezeigt als Baro ADC, zeigt den Druckabfall zwischen Frankfurt Stadt und dem Wendepunkt, resultierend aus einer Höhendifferenz von ca. 190 m. Die in den früheren Logs sichtbaren Druckschwankungen in der Airbox, bei erhöhter Last und Drehzahl, treten nun fast gar nicht mehr auf (Grafik), die noch vorhandenen Schwankungen haben eine deutlich kleinere Amplitude als in der vorherigen Messfahrt, im direkten Vergleich besonders gut zu erkennen (Grafik).

Schlussfolgerung: augenscheinlich ist der Volumenstrom in die Airbox hinein nun ausreichend, um den Luftbedarf des Motors auch bei hoher Leistung zu decken. Da das Entfernen des Schnorchels keinen sichtbaren Effekt hatte, ist vermutlich nicht unbedingt die Querschnittsfläche der Zuführung durch den Tank der begrenzende Faktor, sondern andere Randbedingungen, wie z.B. die Anströmung, wirken dort limitierend.

Die Übersichts-Grafik zeigt ausserdem zwei kleine Abweichungen im AFV, die aufgrund der moderaten Höhenänderungen nicht auftreten sollten. Im Detail zeigt sich bei der ersten Abweichung, dass sich vermutlich Unregelmäßigkeiten in der Fuel Map auf die Kalibrierung ausgewirkt haben (Grafik). Die zweite Abweichung tritt unter Volllast auf und zeigt eine typische Situation für ein Open Loop Learn (Grafik). Von der Transition nach mager bis zum Anheben des AFV vergehen 3 Sekunden, was der Zeitverzögerung beim OL Learn entspricht. Verursacht wird diese Aktion vermutlich durch zu mager eingestellte Zellen in der Fuel Map für diese Betriebspunkte. Auch diese Abweichung des AFV wird bei der nächsten Kalibrierung wieder korrigiert.

... und ich dachte immer, Bayern seien schon vollständig ironiebefreit ...

Zweite Testfahrt. Vorgenommene Änderungen: der Schnorchel im Ansaugtrakt durch den Tank wurde entfernt, wodurch die zur Verfügung stehende Querschnittsfläche mindestens verdoppelt wurde. Die Testfahrt erfolgte wieder auf den Feldberg und retour. Logfile, Grafik.

In der Grafik wird die Baro-Sondenspannung nun als Baro ADC angezeigt, die dynamische Barokorrektur wieder als Flags 5. Betrachtet man den AFV-Verlauf, dann ist die dynamische Druckkorrektur nicht perfekt abgestimmt, denn an den Rändern, wo der Luftdruck bereits reduziert ist, aber die dynamische Korrektur noch nicht einsetzt, sackt der AFV um eine Stufe (ca. 5%) ab, stabilisiert sich später, nachdem die dynamische Druckkorrektur greift, wieder auf dem alten Wert. Dieses Absinken des AFV sollte eigentlich durch die dynamische Druckkorrektur vermieden werden.

Im Prinzip ist das Aussehen unverändert zu dem letzten Testlauf, auch das Absacken des Airboxdrucks ist weiterhin vorhanden (Grafik), obwohl eine (scheinbare?) Drossel im Ansaugbereich entfernt wurde. Das Absinken des Airboxdrucks deckt sich oft mit dem Erreichen der WOT-Region (Grafik), was die lastabhängige Komponente dieses Effekts verdeutlicht. Die Drosselklappe heisst ja nicht grundlos so, wie sie heisst. Unterhalb einer Drehzahl von ca. 3600 rpm tritt er aber nicht auf, weil eine sinkende Drehzahl den Luftbedarf des Motors reduziert. Plot 1, Plot 2, jeweils ab Datensatz 10.000.

Der Eindruck, dass das Entfernen des Schnorchels keinen Einfluss auf den Airboxdruck hat, wird bestätigt, indem beide Testlogs übereinander gelegt werden, mit Hilfe der "compare to"-Funktion des MLV. Grafik

Die beiden Druckverläufe haben einen gleichbleibenden Abstand voneinander, der wohl nur durch den unterschiedlichen Luftdruck (2. Fahrt bei 1021 hPa) verursacht wurde, in der komprimierten Darstellung ist das gut erkennbar.

Schlussfolgerung aus dieser Messfahrt: ob mit oder ohne Schnorchel ist eigentlich egal. Ein wirklicher Unterschied ist in den Messwerten nicht erkennbar.

Ich hole mal diesen Thread aus der Versenkung hervor. Ich habe vor der Fahrt nach Lerici noch einen Bosch-Sensor aus einer 1125R verbaut, der aber im Unterschied zur 1125 den Druck in der Airbox misst. Bild

Ich dann habe eine Logfahrt auf den Großen Feldberg gemacht. Logfile, Grafik

Von Frankfurt/M. auf den Feldberg entspricht einer Höhendifferenz von ca. 750 m, daraus resultiert eine theoretische Druckdifferenz von ca. -94 hPa, in Absolutwerten zur Zeit des Logs: Frankfurt 1014 hPa, Feldberg 945 hPa (lt. Barometer im Tankrucksack). Das deckt sich nicht ganz mit der Theorie, aber egal. In der Grafik lässt sich deutlich sehen, wie die dynamische Druckkorrektur (ABP Corr., aufgezeichnet in Flags 5) von 101% auf 94% abfällt, was sich mit der Realität gut deckt. Nicht so gut ist die statische Druckkorrektur (Baro Corr., aufgezeichnet in Flags 6), die immer ca. 4% zu niedrig ist, Stored Baro im EEPROM ist ebenfalls entsprechend zu niedrig. Im Closed Loop wurde die Abweichung über die Lambdakorrektur egalisiert, im Open Loop durch den AFV. Die blaue Kurve zeigt die Sensorspannung in 8-bit Auflösung (Baro ADC, aufgezeichnet in unknown-63).

Warum diese Abweichung aufgetreten ist, weiss ich nicht, dass müsste noch genauer geprüft werden. Ich habe sie über die Sensordaten im EEPROM korrigiert. Verglichen mit den technischen Daten des Sensors wird nun immer ein etwas höherer Druck ausgegegeben.

Auf meiner Fahrt über die Alpen habe ich keinerlei Unterschied im Fahrverhalten bemerkt, auch die Reichweite einer Tankfüllung lag innerhalb der gewohnten Streuung. Ob es sich lohnt, einen Barosensor nachzurüsten, kann ich daher weder eindeutig bejahen noch verneinen.

Bei der Messfahrt ist mir noch etwas aufgefallen. Grafik

Der Ausschnitt zeigt eine Autobahnfahrt mit erhöhter Last und Drehzahl. Man sieht wie der Airboxdruck an einigen Betriebspunkten deutlich abfällt, was darauf hindeutet, dass der Zufluss zur Airbox zu restriktiv ist. In gezeigten Fall handelt es sich um die Serien-Airbox von 2004 mit installiertem Schnorchel. Sobald ich Zeit finde, werde ich mal ohne Schnorchel probefahren, und vielleicht noch eine gelochte Box von 2004 sowie die geschlitzte Airbox von 2006 oder 2007, abhängig davon, an welche ich rankomme. Die Grundplatte bleibt aber in allen Fällen die gelochte Version, mit dem Ansaugkanal durch den Tank, insofern werden Ergebnisse nicht ohne weiteres auf spätere Modelle ab 2006 übertragbar sein.

Zitat von RainMan

Da sieht man wieder, was im Web für ein $%&/ steht -> http://www.hillbilly-motors.com/html/fatq.html

Dabei handelt es sich aber um ein anderes Thema (Adaption). Und Verkäufer wollen verkaufen, Kundenwissen ist dabei gewissermassen kontraproduktiv.

Zitat von RainMan

Du kannst doch im MLV (MegaLogViewer) unter den Advanced Setting einen Min RPM und einen Max RPM eingeben. Genauso die Load mit Min. Load und Max. Load. Dann filtert der MLV Dir die Daten weg ohne dass Du einen Krampf in der rechten Gashand bekommst.

Das ist aber genau falsch (und zeigt die Schwächen des Gesamtkonzepts). Es soll nicht aus der Datenwüste ein bestimmter Wert herausgefiltert werden, sondern die Daten müssen den zu optimierenden Betriebspunkt darstellen. Das bedeutet: konstante Last, konstante Drehzahl bis sich die Lambdakorrektur eingependelt hat, dann der nächste Betriebspunkt, am einfachsten durch runterschalten. Sind 5000 rpm erreicht, ist die nächste Last dran. Nur dann erhält man Daten, die Aussagekraft besitzen. Ein unsteter Fahrzyklus kann nicht zu sinnvollen Ergebnissen führen, weil Last und Drehzahl einander nicht entsprechen.

Zitat von RainMan

stimmt dann denn wenigstens der Algorithmus für die Breitbandsonden?

Weiss ich nicht, habe ich nie dafür benutzt. Lambda habe ich immer ganz normal gemessen und dann nach Augenschein, oder, jetzt eben, nach Durchschnittswert korrigiert.

Zitat von RainMan

Kann man den MLV damit grundsätzlich in die Tonne treten in Bezug VE-Analysis?

Bei mir ist der 2008 rausgeflogen, weil ich keine Konvergenz gesehen habe. Wobei der Rest immer noch super ist, ohne die Diagramme wäre die Fehlersuche eine Katastrophe.

Zitat von RainMan

vermutlich kommen da noch von Dir Erweiterungen, denn das geht ja gerade mit der Logfile Analysis sehr erfreulich in Richtung Map-Optimizer.

Nein, da wird es ganz sicher keine Erweiterungen geben. Eine Map auf Knopfdruck ist Utopie. Punkt und aus. Bei Klick in eine Map-Zelle werden die zugehörigen Werte (Hits, Weight, Correction und ggf. Lambda) angezeigt. Da braucht man nichts abzuschreiben. Steht da Corr = 1.05, klickt man "+5%", "=", und fertig. Ist Hits nicht ausreichend oder die Zelle auf dem Rand, dann eben nur "+1%" zwei Mal. Den Rest der Dokumentation erledigt My Maps. Wenn alles sorgfältig gemacht wird, erreicht man mit 4 Testfahrten auf dem gemessenene Zylinder eine Lambdakorrektur innerhalb der 2% Grenze und einen stabilen AFV, der sich nicht mehr ohne äusseren Grund ändert. Nebenher kann der Leerlauf gemapt werden, Werte gibt's an jeder Ampel. Und fertig. Sonde umklemmen und der nächste Zylinder.

Zitat von Faebu

wo tendenziel zu fett, wo tendenziell zu mager.

Aber genau das sagt einem das ECM über die Lambdakorrektur, und letztlich ist die dann auch das Mass aller Dinge. Die Lambdakorrektur ist mit Sicherheit ein weit besserer Indikator als der VE Analyzer.

Nein, weil der VE Analyzer liefert keine konstanten Ergebnisse, sie nähern sich nicht dem Bestwert an, sondern beginnen zu schwingen. Es beginnt schon damit, dass er die Lambdasondenspannung mit auswertet, was technischer Blödsinn ist. Kontrollfahrten haben deutlich gezeigt, dass es keinen Zusammenhang zwischen AFR und Sprungsondenspannung gibt. Bei der alten Version konnte der Berechnungsterm noch angepasst werden, bei der neuen geht das nicht mehr. Es ist noch nicht einmal klar, was genau in die Berechnung einfliesst, wo die Grenzen gesteckt sind usw. So etwas braucht kein Mensch, der ein echtes Ergebnis und nicht nur eine neue Map erzielen möchte. Es ist einfach zu prüfen: mit einer erwiesenermaßen gut eingestellten Map (EGO Corr. Abweichungen < 2%) beginnen, und dann den VE Anal yzer drauf los lassen. Dass sich eine Map auf Knopfdruck anpassen lässt, ist sowieso eine Utopie. Das musste ich auch erst lernen. Aus dem Grund bin ich wieder zurück auf die Basics - erst messen, dann einstellen, und habe die Logfile-Analyze selbst programmiert. Die liefert nur eine Übersicht über die Messwerte und funktioniert deshalb auch.

Wer den VE Analyzer aus dem MLV verwendet hat sowieso selbst schuld, das ist die grösste Sch***** für die Buell. Es funktioniert nicht. Insofern braucht man auch nichts umzusetzen. Wer sich stattdessen aber lieber rumquälen und Zeit verschwenden will: Options -> Y Axis -> Load oder, wenn Load nicht aufgelistet ist, Options -> Y Axis -> Other -> Load (eingeben).

EcmSpy für Mono sollte sowohl die Text- als auch die Binärdatei anlegen. Aus der Binärdatei lässt sich die Textdatei erzeugen, am einfachsten über das Bin2Msl-Tool von hier: http://www.ecmspy.com/download.shtml Der Konverter, der mal mit EcmSpy mitkam (mitkommt? Weissnichmehr.) ist nicht mehr so richtig auf dem letzten Stand. Das Java-Tool schon, weil das verwende ich auch.

Vielen Dank! Hatte das ganz aus den Augen verloren ...

Könnte jemand mit BUE2D mal nachschauen, ob im Leerlauf das Idle-Bit gesetzt wird (Flags 1, zweites Zeichen von links = 1) oder mir ein kurzes Log + EEPROM schicken? Mein Test-ECM will das einfach nicht setzen, und ich weiss nicht warum oder ob das sowieso nicht mehr gesetzt wird.

Danke!