Also erstmal grossen Respekt an dich! Zieh den Hut vor deinem Vorhaben!!

Ich melde definitv interesse an, auch mal was zu testen wenn es was zu testen gibt!
Bin zwar programmiertechnisch nicht so bewandert aber wenn ich was tun kann.... bisl Fleissarbeit machen oder sonst was, meld dich!

Sehr geil!

Hallo...

Darf ich fragen, wie weit der Computer ist? Würde mich seeeeehr interessieren!

Andreas aus Dortmund...

Hallo,

ich hatte leider den Sommer über sehr viel anderes um die Ohren und außerdem haben sich in den letzten Wochen meine Bandscheiben wieder "gemeldet", sodass ich nicht mehr dazu gekommen bin, das Projekt voranzutreiben.

Trotzdem - ich habe zufällig heute abend wieder mit ein paar Dingen angefangen, damit das Projekt nicht völlig "verstaubt".

Erst einmal habe ich mir einen Logic Analyzer gekauft, um nochmal die Signale für Kurbelwelle und Fahrzeug-Geschwindigkeit zu messen.

Ich habe einen Billig-Klon des "Saleae Logic" aus China über eBay gekauft. Hätte ich wohl eher sein lassen sollen... Neuere Versionen der original Saleae-Software erkennen den Klon und verweigern eine Zusammenarbeit mit der gefälschten Hardware. Nach einigem hin und her hab ich dann mit PulseView doch ein rudimentäres Programm gefunden, welches mit dem Ding was anfangen kann.

Die Original-Analyzer von Saleae kosten ab 120 Euro aufwärts und sind wohl qualitativ sehr hochwertig... und dieser eBay-Klon hat mit Porto halt zehn Euro gekostet... man kriegt halt das wofür man bezahlt...


Hier jedenfalls mal ein Bild von dem Kurbelwellen-Signal:



Wenn man genau hinsieht, dann erkennt man, dass die "Zacken" in dem Graph genau übereinstimmen mit der Zahnung des Kurbelwellenrads, welches zusammen mit dem Kurbelwellensensor das Drehzahlsignal für die Motorelektronik generiert. Schaut besonders auf die "Zahnlücken" am linken und rechten Rand:



Und so sieht dann das Kurbelwellensignal aus im Logic-Analyzer wenn man reinzoomt:



Man sieht also, es ist ein sehr schnelles Rechtecksignal, mit Intervallen zwischen gleichartigen Flanken von 300 µs und weniger.

Ich hatte eigentlich gehofft, dass ich mit dem Logic-Analyzer endlich eine lineare Beziehung herstellen könnte zwischen Kurbelwellensignal und Motordrehzahl. Das scheint aber immer noch nicht der Fall zu sein:



Wie man in den Screenshots sehen kann (siehe Werkzeug-Leiste am oberen Rand), hatte ich eine Sampling-Frequenz von 2 MHz eingestellt. Das heißt, pro Sekunde checkt der Logic-Analyzer 2 Millionen Mal das Signal. Das reicht, um Intervalle von 0,5 µs abbilden zu können, und sollte somit hierfür eigentlich mehr als genug sein. Aber irgendwie haben wir genauso wieder ne Kurve statt einer Geraden. Eigentlich ergibt nur eine lineare Beziehung zwischen Kurbelwellensignal und Drehzahl wirklich Sinn. Und die müsste auch in so nem Graph zu Punkten führen die wie an nem Lineal gezogen aussehen. Denn die Kurbelwelle dreht sich ja nicht auf einmal überproportional schneller mit steigender Motordrehzahl.

Sobald ich wirklich brauchbare Messdaten vom Kurbelwellensensor und vom Geschwindigkeits-Geber habe, wird der nächste Schritt sein, dies in den Quellcode des Motordaten-Messmoduls einzubauen.

EDIT:

Man könnte es am Ende auch anders machen, indem man nicht die Zeitintervalle zwischen zwei gleichartigen Flanken misst, sondern dass man sagt, 32 Zähne, und somit 32 Pulse, sind immer eine Kurbelwellenumdrehung. Dann wäre im Prinzip egal, wie die im Logik-Analyzer gemessenen Intervalle zwischen den Flanken mit der abgelesenen Drehzahl korrespondieren.

Da das Kurbelwellenrad "Zahnlücken" hat (ich glaube die braucht die Motorelektronik um OT und UT zu bestimmen), kann dies aber prinzipiell zu Mess-Ungenauigkeiten führen, wenn zufällig direkt nach einer der "Zahnlücken" die Zählung beginnt. Das kann man aber dadurch ausgleichen, dass man sagt, nach 33 durchgelaufenen Zähnen (genauer: nach 33 steigenden Flanken) ist die Kurbelwelle wieder an der gleichen Position und hat eine komplette Umdrehung gemacht.


Wenn ich es schaffe, werde ich heute abend nochmal das Geschwindigkeitssignal neu messen mit meinem neuen Logik-Analyzer. Hatte gestern nen Kabelbruch und bin nicht mehr dazu gekommen...

Äh, es wurde bestimmt schon mal eingeworfen,... aber ist es nicht grundsätzlich besser, weil genauer, die Geschwindigkeit an der nicht angetriebenen Achse (hier also die Vorderachse) abzunehmen, da du dort keinen Schlupf hast. Oder kannst du den rausrechnen (lassen) ?

Da müsste man sich überlegen, ob sich der Aufwand lohnt. Und ob die Abweichung zum einen so groß ist, und zum anderen wie sie sich messen lässt, um nachher irgendsowas wie nen Korrekturfaktor zu berechnen.

Und da kommst du am Ende vom hundertsten ins tausendste... du hast alleine schon Abweichungen zwischen nem neuen Reifen und nem Reifen wo das Profil abgefahren ist. Und dann hast du Unterschiede zwischen 16'' und 15''-Rädern. Die 16-Zöller drehen sich langsamer weil der Abrollumfang größer ist, und der Tacho zeigt allein deswegen schon weniger an. Und zwischen trockener und nasser Fahrbahn hast du auch Unterschiede, wenn du so willst.

Am Ende ist jeder Wert den dir ein Bordcomputer (und auch ein werksseitiger Bordcomputer) anzeigen wird nur ein Kompromiss. Du wirst immer ein paar Prozent Abweichung nach oben oder nach unten haben gegenüber der Realität.

Irrtum, bei 16" ist der Abrollumfang geringer als bei 15".

Ansonsten hast du aber Recht, Gerrit.

Aha ok, das wusste ich nicht. Bei meinem Audi ist es umgekehrt, da haben die 16''-Sommerräder mehr Abrollumfang als die 15''-Winterräder... und man merkt den Unterschied auch deutlich auf dem Tacho.

Hab gerade mal die Abrollumfänge der beiden Bereifungen für den MGF/TF angeschaut (laut reifensuchmaschine.de)... die 16-Zöller (215/40 R16) haben 175,8 und die 15er (185/55 R15) haben 177,7 cm. Das ist eine Abweichung von rund einem Prozent.

Da lohnt sich eigentlich noch nicht mal ein Korrekturfaktor für die Reifengröße, denn allein schon zwischen neuen und abgefahrenen Reifen dürfte der Unterschied im realen Abrollumfang einige Zentimeter sein... und ob man am Ende 190 oder 191,9 km/h fährt, dürfte niemanden jucken. (ist eh viel zu schnell in nem MGF )

ich mache es mal kurz:
http://www.mgfcar.de/reifen/
da etwas runterscrollen (ungefähr 2/3 der Seite ), dann hat man die Vergleichstabelle Reifen ( mit Abrollumfang, Abweichung in %, etc. )

viewtopic.php?p=103040#p103040
in meinem Posting das Thema Getriebe-Ratios,

auch für Berechnungen u.U. interessant:
viewtopic.php?p=102447#p102447
bzgl. Umrechnung Tachosignal und Verhältnis Radumdrehungen bzw. Rückrechnung auf Motordrehlzahl über Final-Drive und Gangübersetzung.

Da die Messkurve nicht linear ist, warum auch immer, wäre eine Kontrollvergleich der U/min ( in Excel-Tabelle als "abgelesen" bezeichnet ) mit anderen Werten ( Zündungfunke, Einspritzung ( Anzahl ) denkbar.

Wenn die Werteverarbeitung nicht so zeitkritisch sind ( µs ), wäre ein Counter überlegenswert.
Haben wir mal bei einer Windmesseinheit so realisiert ( Auswerteintervall = 1s bzw. 5 s), um Ist-Windwerte mit DIN- bzw. EN-Berechnungsvorgaben in Vergleich zu setzen. Damals war es eine Lichtschranke ( statt wie hier Hallsonde ).

Da sich das Kurbelwellen-Signal im Mikrosekunden-Bereich bewegt, wollte ich hier auf einen der eingebauten Counter/Timer des Mikrochips zurückgreifen. Das kann man dann direkt per Input Capture auswerten. Das war eine der letzten Sachen an denen ich gearbeitet hab bevor das Projekt dann diesen Sommer auf Eis lag. Hab mich heute abend schon mal wieder etwas eingelesen, kann aber etwas dauern bis ich nen fertigen Code haben werde um das mal zu testen.

Hab hier zwei Tutorials gefunden, wo das wesentliche drin stehen dürfte:

https://www.mikrocontroller.net/article ... er_des_AVR
https://www.mikrocontroller.net/article ... mega_Timer

Einspritz-Signal und Geschwindigkeitssignal bewegen sich im Millisekunden-Bereich, da wird man so einen Aufwand nicht treiben müssen. Das wird viel einfacher über die normalen pin change interrupts erfassbar sein.

Was das immer noch nicht lineare Signal angeht - ich hatte schon gedacht ob es vielleicht daran liegt dass mein altes Netbook (Intel Atom N450 single-core 1,6 GHz) einfach zu langsam ist und dass es deswegen Zeitverzögerungen gibt. Andererseits geschieht die Messung der Signale ja direkt im Logik-Analyzer. Und eine nicht-lineare Kurve hatte ich genauso beim sehr viel langsameren Geschwindigkeitssignal. Aber naja, mal schauen.

So, ich sitze gerade in meinem MG und bin dabei, ein wenig weiter zu forschen.

Scheint so, als hätte ich tatsächlich eine Zeitverzögerung bei mir in meinem alten Laptop, und dass deshalb ein Oszi oder Logik-Analyzer einfach nicht hinterherkommt, das ganze schnell genug auf dem Bildschirm darzustellen.

Ich hab vorhin ein kleines Programm ausprobiert, was die Ausschläge des Nockenwellensensors tatsächlich über die eingebauten Hardware-Timer des Atmega-Mikrocontrollers unter sehr geringer Prozessor-Auslastung registriert, und daraus die Motordrehzahl errechnet und auf dem Laptop ausgibt. Und dieses kleine Script lieferte absolut genau die Drehzahl wie ich sie auch auf dem Drehzahlmesser im Kombiinstrument ablesen konnte.

Somit hätten wir das Problem wohl gelöst. Dieses komische Phänomen der Nicht-Linearität liegt an meinem Laptop, nicht an dem Sensor.

Ich werd hier jetzt gleich noch ein kleines Programm schreiben um auf ähnliche Art und Weise die Intervall-Längen beim Geschwindigkeitsgeber neu zu messen in Abhängigkeit von der Geschwindigkeit. Wenn meine Vermutung stimmt, dann wird sich auch damit eine absolut lineare Beziehung darstellen lassen.

Außerdem habe ich mir gerade nochmal das Einspritzsignal am Motorsteuergerät angeguckt. Das Motorsteuergerät schaltet ja beim MPI die Einspritzdüsen paarweise (ich glaube immer 1. und 4. / 2. und 3. Zylinder), indem sie kurz auf Masse geschaltet werden. Dadurch öffnen sie sich und spritzen Kraftstoff ein.

Siehe Bild:



Jeder "Zacken" nach unten ist also einmal Einspritzventil öffnen.

Das ist ja mit Vorsicht zu genießen weil mein Laptop zu langsam ist, aber das Grundprinzip wird deutlich: je niedriger die Drehzahl, desto länger die Intervalle zwischen den Einspritzungen. Gibt man Gas, dann verringern sich sowohl die Intervalle zwischen den Einspritzungen, als auch die Einspritzintervalle selbst. Lässt man den Motor aber dann auf konstant höherer Drehzahl, dann werden die Intervalle zwischen den Einspritzungen kürzer und die Einspritzintervalle selber werden länger.

Der Spritverbrauch wird dann halt am Ende dadurch ermittelt, dass man guckt, wie lange die Einspritzdüsen insgesamt (kumuliert) offen waren innerhalb eines bestimmten Zeitraums (ich nehm bei mir 3 Sekunden), und das multipliziert man dann mit der Durchflussmenge der Einspritzdüsen laut Bosch-Datenblatt. Die VVC-Düsen spritzen etwas mehr pro Minute als die MPI-Düsen, aber das kann man später problemlos berücksichtigen.

Ich habe vorhin Einspritzintervall-Längen zwischen 700 Mikrosekunden und 3 Millisekunden beobachtet. Es dürfte von der Leistung des Atmega-Chips her langen, diese mit den normalen externen Interrupts zu erfassen.

So, jetzt muss ich noch etwas Code zusammenbasteln, und dann mach ich nochmal ne Testfahrt um die Werte vom Geschwindigkeits-Geber neu zu erfassen.

So, bin gestern noch ne kleine Runde gefahren und hab dabei den Geschwindigkeitsgeber ausgemessen.

Der Graph dazu ist immer noch nicht linear, obwohl ich die Intervalle zwischen steigenden Flanken wirklich mit minimaler Prozessor-Last ermittelt habe. Die Daten sollten also diesmal stimmen.



Ich habe so die Vermutung, dass der Geber kein Hallsensor ist, sondern ein Reed-Kontakt. Ein Hallsensor beruht auf dem Hall-Effekt, und der besagt, dass eine elektrische Spannung in einem Leiter induziert wird, wenn ein Magnet darüber bewegt wird. Diese Spannungsdifferenzen führen zur Erzeugung eines Rechtecksignals. Ein Reed-Kontakt ist dem gegenüber ein physischer Ein/Aus-Schalter, dessen Kontakt geschlossen und geöffnet wird wenn ein Magnet angelegt wird.

Meine Vermutung ist, dass der Reed-Kontakt in dem Geschwindigkeitsgeber eine gewisse Latenz/Trägheit hat, die begründet liegt in der Masseträgheit der beweglichen Teile. Diese könnte dazu führen, dass mit zunehmender Fahrzeuggeschwindigkeit, wo es dann um wenige Millisekunden Intervall-Länge geht, der Reed-Kontakt einfach nicht mehr mithalten kann und sich somit die Kurve zwischen gesteigerter Geschwindigkeit und verkürzter Intervall-Länge immer weiter abflacht.

Für die These könnte auch sprechen, dass der Geber dreipolig ist. Normalen Hall-Sensoren wie dem Kurbelwellensensor reichen zwei Pole um ein Rechtecksignal zu induzieren. Aber die drei Anschlüsse von meinem Geber den ich gekauft habe sind ja +12V, Masse und geschaltete Masse.

Also sind die Messdaten wohl doch richtig, dass wir eine zunächst stark fallende Kurve haben, die sich mit steigender Geschwindigkeit immer weiter abflacht.

So, bin jetzt so weit, dass ich das Motordaten-Modul zum ersten Mal so weit fertig habe dass ich es an meinen MG anschließen und voraussichtlich dieses Wochenende eine Probefahrt machen kann.

Momentan existiert das ganze erst auf einer Breadboard-Steckplatine, aber es ist auch nicht praktikabel zum jetzigen Zeitpunkt schon was auf ne Lochrasterplatine aufzulöten, denn es kann immerhin sein, dass sich an den Steckverbindungen so wie ich sie mir dachte noch was ändern wird:



Unten rechts im Bild fein säuberlich geordnet die ganzen Steckkontakte mit den Kabeln die zu den Kontakten bzw. Sensoren des MG hin laufen. Als da wären sowas wie Einspritzdüsen, Kurbelwellensensor und Tankgeber.

Oben links ist ein FTDI-Serial-Connector (auch wenn das hier ein gefälschter aus China ist ), der quasi die Verbindung zwischen meinem Laptop und dem Chip auf der Steckplatine ist. Als MC für das Motordaten-Messmodul findet ein Atmel Atmega328P-PU Verwendung. Ist ein Allround-Chip, der die ganzen Funktionen alle einigermaßen gut bewältigen wird.

Im momentanen Stadium frage ich die Daten die das Ding ermittelt über den seriellen Schnittstellen-Monitor ab. Das sieht dann auf meinem Laptop so aus:



Momentan sind keine Sensoren angeschlossen, also gibts auch keine Werte zum Anzeigen. Ach ja, und die Verbrauchs-Anzeige wechselt selbständig von "l/h" auf "l/100 km" wenn Geschwindigkeiten über 5 km/h registriert werden. So ist das bei neueren Autos meistens auch.

Nach wie vor ungelöst ist die ganze Sache mit den Temperatursensoren für Öl und Wasser. Da weiß ich echt noch nicht wie ich das machen soll. Das einfachste wäre immer noch, direkt die Sensoren des Wagens anzuzapfen. Aber da wissen wir halt nicht, welche Widerstände zu welchen Temperaturen gehören. Sicherlich gibts im Netz einige Quellen wo das schon mal wer überschlagsmässig durchgemessen hat, aber damit die Genauigkeit so gut ist dass der ganze Aufwand sich überhaupt lohnt, bräuchte ich schon ne einigermaßen aussagekräftige Messreihe.

Wir hatten ja schon mal darüber gesprochen, PT100-Sensoren zu verwenden. Aber da bleibt halt immer noch die Frage, wie bringt man die so am Kühlwasser- oder Ölkreislauf an, dass sie brauchbare Werte liefern.

So, gestern abend habe ich eine Probefahrt gemacht mit dem Motordaten-Modul.

Es liefert bereits ein paar Werte:



Dass der Geschwindigkeits-Geber nicht-linear verläuft, hat sich bei der Testfahrt bestätigt. Mit der Gleichung die ich aus meinen Messpunkten erstellt habe konnte ich erreichen, dass die Geschwindigkeit jetzt sehr genau angezeigt wird. Bezugspunkt wird die GPS-Geschwindigkeit sein, die ich auch zugrunde gelegt habe bei meinen Messungen.

Die Motordrehzahl-Anzeige ist erfreulicher Weise auch absolut exakt.

Bei der Messung des Spritverbrauchs bin ich mir noch nicht so sicher. Das kann eigentlich nicht so hinhauen wie es angezeigt wird. Im "mittleren" Bereich, um die 100 km/h, liefert die Verbrauchsanzeige plausible Werte, aber nach unten hin, so bei 60 im 3. Gang oder so, zeigt sie viel zu wenig an, so um die 4 l/100 km und bei Tempo 150 dann sowas wie 50l/100 km.


Vielleicht kann der eine oder andere mal "mitdenken", was die Berechnung angeht so wie ich sie bisher mache:

Ausgangspunkt ist die Fördermenge der Einspritzdüsen vom MPi-Motor. Laut Datenblatt von Bosch sind das 200 ml/min. Das ist die Kapazität, wenn sie konstant offen sind (oder wären).

Mit meinem Messmodul messe ich alle zwei Sekunden, wie lange die Einspritzdüsen offen waren. Multipliziert mit der Einspritzmenge pro Millisekunde laut Datenblatt bekomme ich also alle zwei Sekunden einen Wert dafür, wieviel Sprit tatsächlich eingespritzt wurde. Dieser wird mit 4 multipliziert weil wir ja vier Einspritzdüsen haben.

Um dann den (hochgerechneten) Spritverbrauch pro Stunde zu bekommen (wird angezeigt bei Geschwindigkeiten von 5 km/h und weniger), rechne ich:

Verbrauch pro Stunde (l) = Einspritzmenge in 2 Sekunden (ml) * 30 Zeitintervalle pro Minute * 60 Minuten pro Stunde,

geteilt durch 1000 um von Milliliter auf Liter zu kommen.


Somit haben wir dann den Verbrauch pro Stunde.

Um hieraus den Verbrauch in l/100 km in Abhängigkeit von der Geschwindigkeit zu bekommen, rechne ich:

Verbrauch (l/100km) = Verbrauch pro Stunde (l/100 km) * Geschwindigkeit (km/h) / 100.


Diese Rechnung liefert z.B. bei 100 km/h plausible Werte, weil wir ja quasi eine Stunde lang 100 km/h fahren:


(l/100km) = Liter pro Std. * 100 (km/h) / 100.


Fahre ich aber mit 60 km/h, dann bekomme ich mit dieser Gleichung einen Verbrauch angezeigt der viel zu niedrig ist, und bei Autobahn-Geschwindigkeiten dann Werte von 30-50 Litern. Kann also eigentlich nicht sein.

Hat von euch wer ne Idee, wie man das besser rechnen kann?

Ich glaube die Formel muss lauten:

(l/100km) = Liter pro Std. * 100 / Geschwindigkeit

bzgl. der Formel stimme ich mit Der Wolf überein.

warum die Daten des Geschwindigkeitsgebers nicht linear sind, ist für mich ein Rätsel.
Der Geber sitzt ja am Final-Drive, also pro Umdrehung 1,8 m * Über-/Untersetzungsverhältnis ( ist vermutlich 1,15 ), siehe auch Dieters Thread bzgl. Tempomat.

Angaben Bosch bzgl. Einspritzmenge:
ich stelle mal die Frage in den Raum, ob diese Werte von 200ml/Minute ein definierte Ist-Wert ist, oder nur die Mindestspezifikation, die nach oben streuen kann, ist.
Geben die Datenblätter etwas über die Toleranzgrenzen her ?
Ich gehe mal stark davon aus, dass dieser Kennwert bzgl. Motorsteuerung nicht herangezogen wird.
Das ECU regelt ja die Einspritzdauer und die Einspritzmenge und somit die Dauer der Einspritzung über diverse Sensoren.
Zudem gehe ich davon aus, dass bei Öffnen die Einspritzmenge nicht sofort 100 % beträgt bzw. bei Schließen umgekehrt ebenso, also man die Einspritzdauer nicht zu 100% als Zeitfaktor * 200ml/min rechnen kann.

Keine Ahnung wie es heutzutage seitens der Hersteller berechnet wird, was mir aber gerade wieder in den Sinn kommt:
vor vielen, vielen Jahren ( Jahrzehnten ) hatte ein Elektronik-Magazin ( war es ELV oder Elektor ) mal einen Bord-Computer vorgestellt.
Da wurde, wenn ich mich richtig erinnere, in der Benzinleitung ein Durchflussmessgeber eingebaut. Verbrauch wurde damals für ein größeres Zeitfenster berechnet.
Wollte das mal in meinen Jetta I einbauen. Aber der 2. Versuch von Verkehrsteilnehmern aus einem geparkten Jetta eine Golf zu machen, war bzgl. der Fahrzeuglänge dann letztendlich doch recht erfolgreich und brachte das Ende des Jettas mit sich.

Durchflussmengenmesser hatte mein Trabant damals auch . Der müsste doch verlässlicher Werte liefern als die Düsen auszulesen .

Ich glaube mit dem Durchflussmengenmesser passen die Werte aber nicht, gibts nicht auch einen Rücklauf? Die Spritpumpe fördert ja konstant und wenn die Düsen in langsamer Sequenz "feuern" wird ja nur ein Teil vom geförderten Sprit genutzt, der Rest muss ja dann wieder zurück. Da könnte man dann mit 2 Mengenmessern arbeiten und aus der Differenz dann vielleicht die effektiv genutzte Spritmenge messen?

Ich habe mal bei einem Audi 80 B4 einen Bordcomputer nachgerüstet. Die alten Audi-Bordcomputer hatten auch eine Durchschnitts- und Momentanverbrauchs-Anzeige.

Das Verbrauchssignal für den Bordcomputer kam von einem dünnen Kabel vom Motorsteuergerät her. Es handelte sich dabei um ein PWM-Rechtecksignal, welches vom Motorsteuergerät generiert wurde. Im Audi 80 gabs keinen Durchflussmesser, das heißt, das Motorsteuergerät muss das auch irgendwie aus den Öffnungs- und Schließzeiten der Einspritzventile errechnet haben.

Ob die Elektronik da noch nen "Korrekturfaktor" oder so mit eingebaut hat, keine Ahnung.

Das Kraftstoffsystem is bei den meisten Autos, auch beim MG, ein Kreislauf-Fördersystem, das heißt, der Sprit wird ständig im Kreis gepumpt und läuft wieder zurück. Deshalb hat man auch Vor- und Rücklauf am Tank. Und da der Druck auf dem System mit dem Druckregler konstant gehalten wird, wird es da auch nicht unbedingt Schwankungen in Abhängigkeit von der Motordrehzahl oder -last geben.

Was den Tacho-Geber angeht... keine Ahnung wieso der nicht linear ist. Ergibt eigentlich keinen Sinn. Aber ich lasse das Geber-Signal über einen externen Interrupt im Mikrocontroller messen, und der hat zumindest keine Lags, denn wenn der Interrupt ausgelöst wird, dann lässt der MC den restlichen Code stehen und liegen und arbeitet nur die Interrupt-Routine ab. Der Controller arbeitet mit 16 MHz Taktfrequenz, das heißt, pro clock cycle braucht er 62,5 Nanosekunden. Interrupt-Routinen benötigen je nach benutzten Befehlen um die 50 bis 200 clock cycles. Das Tachosignal liefert aber Werte im oberen Mikrosekundenbereich (ich glaube selbst bei 250 km/h ist die Pulslänge nur 2,5 Millisekunden). Es ist also um mehrere Größenordnungen langsamer.

Mein Verdacht ist wirklich, dass es sich bei dem Geber um irgendeine Form von Reed-Kontakt handelt, wo die beweglichen mechanischen Teile eine gewisse Trägheit/Latenzzeit haben, die mit steigender Geschwindigkeit zunimmt. Oder so.

Wirklich spannend wäre es, den Geber vom MGF MkII mal auszumessen, ob der auch so eine nicht-lineare Kurve hat. Das wird eines der nächsten "Projekte" werden.

EDIT:

Hab mal im Netz geguckt zum Thema Einspritzventile und Latenzzeiten.

Scheint so, als gibts da doch Latenzzeiten beim öffnen und schließen, die immerhin ein paar Zehntel Millisekunden ausmachen können. Wenn die Einspritzintervalle maximal zwei Millisekunden lang sind laut meinen Messungen, dann kann das schon ein paar Prozent Unterschied machen.

Ich werd deswegen mal Bosch eine E-Mail schreiben, denn dazu gibt es in dem Datenblatt zu den Einspritzdüsen nicht mal auf der Website von Bosch irgendwelche Informationen.

Am Ende müsste man es dann wahrscheinlich so machen, dass man nicht nur zählt wieviele Millisekunden pro 2 Sekunden die Einspritzdüsen offen waren, sondern man muss auch zählen wie oft sie geöffnet und geschlossen wurden. Und das dann halt multiplizieren mit den Latenzzeiten.

Stichwort Latenzzeiten, hab mal geschaut ob sich die Latenzen beim Geschwindigkeitssignal vielleicht durch andere Bauteile in meiner Schaltung erklären lassen. Ich habe zwischen dem 12-Volt-Signal vom Geber (der läuft wirklich nur mit 12V, schon ausprobiert) und meinem Mikrocontroller einen Optokoppler geschaltet, der das ganze halt in ein 5-Volt-Signal übersetzt. Laut Datenblatt des Optokopplers gibt es da zwar Latenzen, aber selbst bei dem 1 kOhm-Widerstand den ich vorgeschaltet habe scheint es da maximal um 100-200 Mikrosekunden zu gehen (selbst bei 250 km/h, wie ich oben schrieb, ist die Pulslänge immer noch 2,5 Millisekunden), und offenbar sind diese Latenzen auch konstant und nicht von der Frequenz des Input-Signals abhängig:

http://www.produktinfo.conrad.com/daten ... _8_FSC.pdf

Scheint also wirklich am Geschwindigkeits-Geber selbst zu liegen. Aber hab das ja in meinem Code berücksichtigen können, und er zeigt jetzt trotzdem sehr genau die Geschwindigkeit an.