So, dann mal bischen weiter hier.
Deadtime
Aus den bisher gesammelten Daten hat sich ein Trend herauskristallisiert, dass meine Deadtime (Totzeit der Injektoren) und BattVoltCorr (Korrektur der Abhängigkeit der Totzeit von der Versorgungsspannung) womöglich nicht optimal sind. Wäre ja auch fast ein Wunder gewesen, da diese mangels verfügbarer Daten anfangs geschätzt wurden. Ist auch nicht so sehr wichtig, da die berechnete DeadTime lediglich ein kleiner Offset ist, bei dem sich ein (kleiner!) Fehler fast ausschließlich im unteren Lastbereich bei der Feinabstimmung bemerkbar macht. Die Deadtime ist die Zeit, in welcher die Einspritzdüse bei Aktivierung erst mal nichts einspritzt.
Theoretisches Beispiel mit einer Deadtime von 0,8ms:
Soll 1ms lang Kraftstoff eingespritzt werden, muss die Düse insgesamt 1,8ms angesteuert werden - da sie in den ersten 0,8ms ja nichts tut. Würde man sie nur 1ms ansteuern, käme in diesem Fall nur 0,2ms lang Kraftstoff heraus.
Die Deadtime ist abhängig vom Benzindruck und der Spannung, mit welcher die Injektoren angesteuert werden. Da bei starker elektrischer Last und Leerlaufdrehzahlen die Bordspannung etwas abfällt, verändert sich die Deadtime ebenfalls. Aufgrund des gekoppelten Benzindrucks, welcher bei geschlossenen Drosselklappen etwas den Benzindruck senkt ist das ganze nicht ganz so einfach, und das ganze ist auch nicht völlig linear. In der MS2 ist aber lediglich eine lineare Korrektur vorgesehen durch die BattVoltCorr. Ist aber nicht schlimm, da der Einfluss recht gering ist, und diese Bereiche ohnehin nicht besonders interessant sind fürs normale Fahren - wird daher vernachlässigt.
Soweit die grundlegende Theorie.
Vereinfacht dargestellt berechnet sich der einzuspritzende Kraftstoff bzw die Einspritzdauer (Pulsweite, PW) aus 3 bzw 4 Komponenten. VE ist hierbei der Wert im zugehörigen Feld (Abhängig von von Drosselklappenstellung oder Saugrohrdruck und der Drehzahl, je nach Einspritzmethode). MAP ist der Saugrohrdruck. ReqFuel ist ein Als Korrekturen sind, wie der Name vermuten lässt, alle Korrekturen zusammengefasst die eingeschaltet sind. Beispielsweise Ansauglufttemperatur, Kühlmitteltemperatur (Aufwärmphase), Beschleunigungsanreicherung, Lambdaregelung oder der Luftdruck - halt je nachdem, was man alles eingeschaltet hat. Kann auch noch einiges mehr sein, beispielsweise gibt es auch noch die Möglichkeit die ganze Einspritzmap auf einen festen Lamda- bzw. AFR-Wert einzufahren, und danach über eine AFR-Tabelle einen Wunschwert vorzugeben (Incorporate AFR).
PW = Deadtime + (VE*MAP*ReqFuel*Korrekturen)
Wie man aus der vereinfachten Gleichung entnehmen kann, wirken die Korrekturen natürlich nur auf den Bereich ohne Deadtime. Beispielsweise ist in meinem Fall eine Pulsweite von ca. 1,1ms ein üblicher Wert im Leerlauf.
D.h. mein PW ist mit einer Deadtime von 0,8ms wie folgt: 1,1ms = 0,8ms+x ; x ist somit der Bereich der von Korrekturen und dem Map-Sensor beeinflusst wird.
Das Problem ist hierbei hauptsächlich bei Semi-sequenziellem Betrieb zu finden, da hier eben zweimal eingespritz werden muss pro Zyklus. Zum Vergleich, im sequenziellen Betrieb mit nur einer Einspritzung hat die Deadtime und alles damit verbundene einen sehr viel geringeren Einluss. Statt einer Pulsweite von 1,1ms hätte man hier dann 1,4ms, aber die 0,8ms blieben ja gleich - der Anteil x wäre somit doppelt so gross.
Das ist übrigens auch der Hauptnachteil eines überdimensionierten Injektors, denn mit einem kleineren Injektor wäre die Pulsweite eben auch länger...
Nach Versuchen habe ich passendere Werte für meine Düsen ermittelt. Die bisherige Deadtime (Angabe bei 13,2V) von 0,8 wird zu 0,7, und die BattVoltCorr (Änderung Deadtime in ms pro Volt) verringert sich auf fast die Hälfte.
13,2V ist etwa der Wert im Leerlauf, damit greift die BattVoltCorr nicht. Die effektive Änderung ist somit 0,8ms statt 0,7ms, die Korrekturen haben somit zukünftig 1/3 mehr Einfluss.
Bei 14,3V im normalen Fahrbereich ist die effektive Deadtime sehr ähnlich dem bisherigen Wert: 0,568ms (0,7ms-(14,3V-13,2V)*0,12ms/V) gegenüber 0,58ms (0,8ms-(14,3V-13,2V)*0,2ms/V).
Da hier die Pulsweite im mittleren Lastbereich auch eher ca.3ms ist, haben die Korrekturen hier nun einen lediglich um 0,5% höheren Einfluss - damit praktisch wie bisher.
Das deckt sich mit den bisherigen gesammelten Daten, welche sich abhängig vom Wetter immer wieder minimal veränderten im Leerlaufbereich, und den normalen Fahrbereich praktisch nicht beeinflussten.
Auch sind die Werte im SpeedDensity-Bereich nun noch etwas linearer.
Praktisch ist aber ausser in den Datenlogs aber kein wirklicher Unterschied spürbar. Wirklich merken wird man sowas eher in Extremsituationen bei wenig Last, also beispielsweise wenn die Einspritzmap bei völlig untypischem Wetter eingefahren wurde oder die Bordspannung sich signifikant verändert, oder man den AFRTable eben stark umstellt.
So gesehen ist das Meckern auf sehr hohem Niveau, aber wenns es besser geht, dann muss es auch besser werden
Zusatzbarometer Umgebungsdruck/RamAir
Um etwaige Korrelationen von Umgebungsdruck und aufgezeichneten Daten erkennen zu können gibts zukünftig noch ein weiteres Barometer. Aktuell hab ich bereits zwei verbaut. Eines um den Druck im Ansaugkanal zu messen (Map-Sensor), und eines sitzt in der Airbox um den Druckzuwachs durch Ramair zu messen. Bisher hab ich leider erst eine Fahrt in höherer Lage fahren können bei der ich verwertbare Daten sammeln konnte, daher weiß ich noch nicht sicher wie sich das verhalten wird wenns tatsächlich mal deutlich höher gehen sollte. Bei mir in der Gegend schwankt der Umgebungsdruck im Normalfall zwischen 98 und 96kpa, und es ist keinerlei Trend zu beobachten. Aktuell muss ich mich da leider auf eine anfängliche Messung bzw auf die Werte bei offener Drosselklappe beschränken, aber da überall der Map Sensor drinsteckt und der Benzindruck ohnehin kompensiert ist mach ich mir da auch keine großen Sorgen.
Speziell für Ramair hab ich vor kurzem ein paar Hochgeschwindigkeitsläufe auf der Autobahn gemacht. Anfangs war das Problem, dass ich per Kabel ran musste zum Datenloggen und daher nen Rucksack mit Laptop auf dem Rücken hatte. Ab 240 (Originaltacho) ging das einfach nicht mehr wirklich, da der Rucksack zu Flattern begann, trotz ordentlichem Festzurren. Seit ner Weile hab ich ja ein Bluetoothmodul in der MS drin, das ermöglicht mir ein sehr viel einfacheres Loggen. Zudem lieferte der Sensor ein verrauschtes Signal - bei näherer Betrachtung ist das überhaupt kein Wunder, denn bei den Druckänderungen die hier gemessen werden sollen muss der Prozessor im Millivoltbereich messen, und das Nadelöhr ist eindeutig hardwareseitig. Ich hab die Signaldämpfung entsprechend wieder reduziert und glätte das Signal softwareseitig. Damit ist das sauber auswertbar.
Der Drucksensor sitzt übrigens an der Position, wo bei P/N original der Schwimmerkammerdruckausgleich anzapft - das scheint auch ziemlich gut geeignet zu sein.

Jedenfalls dann ein paar Läufe durchgeführt, bei denen aus dem sechsten Gang einfach mit Volllast durchbeschleunigt wurde aus sehr niedrigen Drehzahlen auf fast VMax. Zum Vergleich das ganze in einem niedrigeren Gang, wobei mittels Hinterradbremse die Beschleunigung vergleichbar gehalten wurde. Leider ist aufgrund der (unfreiwillig) viel zu kurzen Übersetzung Schluss bei ca. 245 (GPS, ca. 265-270 Originaltacho). Der Witz an der Sache ist der, dass der Staudruck zwar sehr deutlich zunimmt fast 1zu1 auf dem theoretischen Maximalwert, trotz Volllast des Motors UND Druckabfall durch den Luftfilter (der übrigens extrem gering ist - der originale Luftfilter ist scheinbar echt gut) - aber tatsächlich kein Einfluss aufs Gemisch erkennbar ist.
Aufgrund des ITB-Modus, der zwischen SpeedDensity und AlphaN-Hybrid umschaltet, betrachte ich hier die verschiedenen Drosselklappenbereiche getrennt. Vermutet/Befürchtet wurde eine Korrelation zwischen AFR-Wert und Staudruck, auf deutsch, dass die Kiste abmagert.
Im Maximaldrehzahlbereich bei Volllast liegen erst wenige Daten vor, daher ist die Einspritzmap dort noch nicht so fein wie in den anderen Regionen. Ein eindeutiger Trend ist nicht erkennbar. Zwar ist eine geringe Korrelation da, aber je nachdem welchen Bereich man als Modellbasis nimmt (230-245, 235-255, 240-245) magert die Kiste einmal minimal ab, bzw. bei den höchsten Geschwindigkeiten fettets sogar leicht an.
Bei vorherigen Messungen konnte ich zwar beobachten, dass die AFR-Werte abwichen wenn man beispielsweise Daten aus dem vierten und dem sechsten Gang beim Durchbeschleunigen verglich, allerdings habe ich das ganze nochmal wiederholt um den Einfluss der verschieden schnellen Drehzahländerungen und des kurzzeitigen Drosselklappenschliessens rauszubekommen.
Kurz: Kein eindeutiger Trend, und alles unter den Messungenauigkeiten. Falls wirklich Bedarf sein sollte für eine Ramairkorrektur, die über das ohnehin vorhandene hinaus geht, so ists zum derzeitigen Stand einfach nicht erkennbar, weil andere Einflüsse das total überlagern.

Wer sich wundert warum ich da mit Excel rumfummel, obwohl mit Megalogviewer doch eigentlich eine spezielle Auswertesoftware zur Verfügung steht:
MLV ist auch in der Bezahlversion in manchen Sachen leider eher Spielerei, bzw. produziert zware nette Bildchen, aber für mehr als ne qualitative Analyse taugts meiner Meinung nach leider nicht. Die Filterfunktionen sind doch recht primitiv, und in den Plots lässt sich noch nicht mal zuverlässig erkennen wo denn tatsächlich wieviel Messdaten liegen, geschweige denn ne einfache lineare Regression durchführen.
Beispielplots:


Sehen zwar nett aus, aber ich hatte mir da echt mehr erhofft. Aber hauptsächlich hatte ich die ja eh gekauft wegen der besseren Einspritzmapanalyse, das ist mit der kostenlosen Version kaum durchzuführen. Im dritten Graph wollte ich zum Beispiel schauen, wie die Ansaugtemperaturkorrektur funktioniert. Im Idealfall entsteht da eine Gerade mit der Steigung Null (Konstanter AFR-Wert erwartet), und um die Gerade zeichnet sich eine Normalverteilung der Messpunkte ab. Das Ganze hier nochmal in Excel. Weniger schön anzusehen, aber sehr viel aussagekräftiger.


Erfreulicherweise scheint das sehr gut zu passen. Die Korrekturwerte entstammen übrigens der Idealgas-Formel und scheinen somit erstaunlich gut zu funktionieren.
Hier übrigens die Position des zugehörigen Sensors, funktioniert dort wunderbar. Ist ein geschlossener Plastiksensor aus ner Zx6r.

Umstellung auf Vollsequenz
Auch wenns mehr als zufriedenstellend läuft, besser gehts immer. Damits nicht langweilig wird, plane ich in näherer Zukunft "aufzurüsten" auf sequenziellen Betrieb. Ich erhoffe mir davon in erster Linie Verbesserungen im Teillastbereich und eine weitere Verbrauchsverbesserung durch die Möglichkeit den Einspritzzeitpunkt genau dorthin zu schieben, wo die effizienteste Verbrennung stattfindet. Wobei der Verbrauch von ca. 6,2L aktuell bereits für mich sehr zufriedenstellend ist, obwohl das Gemischziel bis vor kurzem noch recht fett war (AFR 13,2 überall). Der Witz ist, dass der Minimalwert sich von Einspritzung im Vergleich zum Gleichdruckvergaser kaum geändert hat - aber dafür hat sich der Verbrauch stark reduziert, wenn man die Kiste ordentlich fordert. Da ich längerfristig vorhabe einen eigenen Tank zu konstruieren, hat das nicht nur Vorteile für den Geldbeutel (und unsre geliebte Umwelt

), da der Tank dann eben kleiner werden kann.
Zusätzlich werden natürlich auch Zündspulen/Zündkerzen/Injektoren etwas geschont, und es gibt weniger Stromspitzen im Bordnetz.
Hierfür habe ich mir bereits eine Platine geordert, auf welcher ich eine Schaltung für 4 getrennte Injektortreiber aufbauen werde. Da ich die Zündspulen aktuell bereits im WastedCOP-Modus laufen habe, bedarf es lediglich bei den Injektoren einer kleinen Kabelbaumänderung. Ich habe mich entschieden gleich 4 Injektortreiber zu verbauen statt 2 zusätzliche, um den Stromfluss in der MS noch besser trennen zu können.
Unschlüssig bin ich mir aktuell noch, ob ich einen konventionellen Nockenwellensensor verbauen soll, oder das über den Unterdruck im Ansaugkanal erkennen soll. Letzteres habe ich mittlerweile mitbekommen, dass es schon praktisch umgesetzt wurde an nem Moped - der Chefkoch aus dem R4F Forum hat sowas z.B., mit dem hab ich mich auch schon etwas augetauscht. Scheint daher prinzipiell möglich zu sein, und wäre halt etwas mehr elektrische Fummelei statt mechanische... ist mir mittlerweile sogar lieber. Wirklich schlüssig bin ich mir da noch nicht. Alternativ scheint beispielsweise die Zx9r ab Modell C (auch wenns ein Vergaser is) einen Nockenwellensensor zu haben, der direkt einen Nocken auf der Welle erkennt. Das würde das Anschweissen eines Stifts an die Nockenwelle ersparen und wär auch noch eine Option.
Wer sich überlegt auch ne Spritze zu basteln, ich würde wieder das vollsequentielle definitiv nicht am Anfang machen. Ich würde wahrscheinlich nicht mal mehr halbsequentiell (schlimmes Wort übrigens, da es wenig mit sequentiell zu tun hat) anfangen, sondern aufgrund der Möglichkeit nur einmal einzuspritzen sogar zu der Untimed-Variante tendieren.
TableSwitch
2 Tables, Drehzahlbereich mehr Auflösung
Es existiert die Möglichkeit, entweder per Digitaleingang oder bestimmten Bedingungen zwischen verschiedenen Einspritz- oder Zündkennfeldern zu springen. Prinzipiell habe ich damit statt einer 16x16 Tabelle nun eine 31x16 Tabelle zur Verfügung, und kann somit die verschiedenen Drehzahlbereich fast doppelt so hoch auflösen. Wird offenbar öfters gemacht mit Motoren mit großen Drehzahlbändern, aber ist eben von der Wartung und Logauswertung etwas aufwendiger. Wechselbedingung ist in meinem Fall beispielsweise das Erreichen einer Drehzahl >7200 UPM. Mein bisherigers Kennfeld habe ich entsprechend interpoliert und konnte es relativ einfach übernehmen. Von der Funktion hat sich hierdurch nichts geändert, nur dass zukünftig nichtlineare Stellen in der Motorcharakteristik besser erkannt und beschrieben werden können.
Schubabschaltung
Anfangs hatte ich damit schon mal experimentiert, mit wenig Erfolg. Jetzt wie die Map besser ist, scheint das erfreulich gut zu funktionieren. Prinzipiell wird einfach bei höheren Drehzahlen beim Schließen des Gasgriffs nichts mehr eingespritzt. Ein Vorteil ist neben dem gesparten Sprit eine stärkere Motorbremse, wenn man das will. Fährt sich in der Tat finde ich angenehmer, besonders wenn man ausrollen lässt.
Nachteil ist eben, dass die Lambdasonde kurz aus dem Tritt kommt wenn sie so weit hinten sitzt wie bei mir nach dem Sammler - muss man entsprechend aus den Logs rausfiltern. Auf dem Screenshot kann man schön erkennen, wie die Pulsweite (Gelb) temporär auf Null gesetzt wird - es wird also nichts eingespritzt. Schaltpunkt ist eine Drosselklappenstellung <1%, was erreicht wird an dem Schittpunkt vom gelben Graph mit dem weissen Graph (TPS). Ein paar Datenpunkte später registriert die Lambdasonde (AFR, grün) das extrem magere Gemisch (19.9 ist Maximalwert) und normalisiert sich ein paar Zyklen nachdem die Einspritzung wieder aktiv geworden ist.
Dashboard
Wie schon öfters erwähnt fliegen die originalen Instrumente raus.
Fest verbaut wird ein Billigtablet mit Android, das allerdings dennoch über Hardware mit ausreichend Bums verfügt. Anfangs wollte ich eins mit 10" verbauen, Wirklich Platz war eber dann nur für eins mit 8" - aber dann mal tatsächlich angehalten mit Schablone war klar, dass das viel zu groß ist, und gekauft wurde dann ein "kleines" mit 7". Die tatsächliche Bildfläche ist immer noch etwas größer als übliche "echte" Dashboard, und man muss ja nicht unbedingt während der Fahrt Kinofilme drauf gucken

Obendrüber kommt der kleine Tacho, der tatsächlich mit ABE ausgestattet ist und die Kiste damit zumindest äußerlich relativ legal erscheinen lässt, und auch ein paar Leds beinhaltet für das übliche Straßengeraffel - Licht, Blinker, Öldruck etc. Da im Originaltank keine Reserveerkennung integriert wird, ist der Tageskilometerzähler auch recht praktisch.

Gespeist wird das Tablet über einen kleinen Regler, der aus der Bordspannung geregelte 5V macht. Da man das Tablet bei Bedarf aber auch rausnehmen können soll, hab ich mich dazu entschieden die Spannungsversorgung über den originalen USBPort zu realisieren, mit einem angepassten Kabel. Mein 20 Jahre altes Moped hat somit tatsächlich nun auch einen USBPort

Original war der Regler so ein 1,50€ Teil für den Zigarettenanzünder, wie mans als Chinaware massenhaft kriegt. Nach Austausch einiger Bauteile die mir fragwürdig sparsam dimensioniert erschienen und Wegfall allen Plastigeraffels ist das kleine Ding übrig geblieben, neben dem Tacho rechts. Aktuell soll er nur dafür sorgen, dass das Tablet dauerhaft betrieben werden kann ohne es selbst laden zu müssen.
Gewicht von Tacho, Tablet und Regler zusammen ist übrigens ca. 300g - ich hatte da mehr befürchtet. Aber selbst wenn, so eine flexible Anzeige ist sehr wertvoll wenn man gezielt ein paar Datenpunkte anfahren will, oder eben einfach nur alles wichtige auf einen Blick sehen will. Und im Bedarfsfall lässt sich eben auch einfach mal kurz alles am Motor umstellen, oder man kann ein Navi dazuschalten.
Das Ganze wird als Sandwich in Carbonplatten und Moosgummi gepackt und hoffentlich sogar noch recht gut aussehen, zumindest aber ordentlich geschützt sein vor Schlägen und Vibrationen.
Weiterer Grund für die Aufrüstung des Reglers ist, dass ich in naher Zukunft auch einen Schaltblitz bauen will auf Basis eines Mikrokontrollers. Der verarbeitet dann einfach ein Drehzahlsignal, und kann über verschiedene Pwm-Ausgänge ein paar Leds genau so ansteuern wie ichs will. Die MS hat da zwar auch was, aber das ist vergleichsweise primitiv. Vorteil bei meiner Lösung wird übrigens auch sein, dass ich sowas bei Bedarf auch recht einfach als Zusatzinstrument für originale ZX(7)R anbieten kann. Hoffe ich kann das in ein paar Wochen vorstellen, aktuell ist aufgrund Klausurphase relativ wenig Zeit.