Eine ganz andere Möglichkeit gibts noch...

Und zwar funktioniert die Display-Beleuchtung so, dass hinter dem eigentlichen TFT-Bildschirm eine weiße reflektierende Folie angebracht ist, und am Rand des Displays sind zwei superhelle SMD-LEDs.

Hier sieht man mal die Folie an einem Display das ich leider "kaputtgebastelt" hab:



Man könnte am Display irgendwie zusätzliche LEDs in orange anbringen. Die Display-eigene Beleuchtung ist schaltbar und dimmbar. Man könnte also diese Beleuchtung abschalten im Nachtmodus und dafür dann orange LEDs anschalten.

Wird halt nur ein bisschen knifflig sein, da SMD-LEDs so anzubringen, dass es auch wirklich nach was aussieht... die Dinger sind ja so schon nicht einfach zu handhaben weil sie so klein sind...

So, hab mal die Variante mit LED ausprobiert...



Denke mal, das ist wirklich die beste Alternative. Ist ja im Grunde ähnlich wie bei der werksseitigen Digital-Anzeige des Tachos. Die wird auch von hinten rot angeleuchtet. Man müsste jetzt nur noch den richtigen Farbton bei der LED treffen, und die richtige Leuchtkraft. Werd mal die Tage gucken ob ich hier um die Ecke bei Conrad ein paar verschiedene supherhelle LEDs in orangerot bekomme (zahlt sich echt aus, ne Conrad-Filiale in Laufweite zu haben... ). Und beim MkI würde man dann, dem Tacho-Design entsprechend, am besten statt orangerot eine bernsteinfarbene/gelbe LED von hinten reinmachen.

Ansonsten hab ich gestern den Tankgeber ausgemesssen.



Es war notwendig, die Messwerte direkt mit dem Mikrocontroller zu erheben, weil diese Werte im Programmcode nachher auch die Ausgangsbasis sein werden für die Berechnung des Rest-Tankinhalts.

Zwischen 0 und 50 Liter liegen also 340 Zähler. Das bedeutet, wir haben eine Daten-Auflösung von 6,16 Zählern pro Liter, bzw. 6,8 pro Liter bei laufendem Motor. Das ist im Grunde ganz ordentlich, und sollte eine vernünftige Berechnung des Tankinhalts ermöglichen. Man muss dann halt berücksichtigen ob der Motor läuft oder nicht, aber da wir ja unter anderem auch das Kurbelwellen-Signal messen, wissen wir ja ob der Motor an ist oder aus.

Komischerweise hatte ich die gleichen Werte bei komplett leerem Tank und bei 5 Liter Tankinhalt. Es scheint so zu sein, dass der Tankgeber-Schwimmer wirklich erst bei 5 Litern angehoben wird. Oder habt ihr ne Erklärung dafür?

Der Tank hat eine besondere Form ( siehe Bilder ). Deshalb kann man bei Spritmangel einfach durch eine schnell gefahrene Rechtskurve nachtanken, sprich den Sprit von rechts nach links schwappen lassen.

Die Tank-Form hab ich dabei schon berücksichtigt. Der Tankgeber sitzt ja in Fahrtrichtung im linken Teil des Tanks, und da müssten mehr als fünf Liter reinpassen bevor es in die andere Hälfte des Tanks rüberschwappt.

Aber ich hab halt gestern auch den Tank komplett abgesaugt mit nem Schlauch, also dürfte es da eigentlich keine Fehl-Messungen gegeben haben.

Um die Ungenauigkeit der Tanknadel aufgrund der Tank-Form auszugleichen, werd ich wohl zusätzlich ne Funktion einbauen, dass der Bordcomputer sich die verbrauchte Spritmenge merkt (kann man einfach als Wert im EEPROM des Chips speichern). Der Wert wird dann halt jedes Mal aktualisiert, wenn man den Motor wieder ausmacht (um den EEPROM zu schonen, der nur um die 100.000 Schreibvorgänge aushält).

Und dann könnte man halt den am Tankgeber gemessenen Tankinhalt immer vergleichen mit der aus dem Verbrauch errechneten Rest-Menge. Und dann kann man das so machen, dass der Bordcomputer den Wert im EEPROM entweder auf null setzt wenn er merkt dass man vollgetankt hat, oder man macht es so dass man es von Hand nach dem Volltanken einstellen kann.

Aber mal schauen...

Hab mal mit den Werten meiner Tankgeber-Messung ein bisschen rumgerechnet...

Ich habe mal online mit ein paar Regressionsanalysen-Tools rumprobiert, und hier die Regressionsgerade für y = mx + c:



Macht man das ganze aber als exponentielle Regression mit y = a*b^x, dann hat man einen etwas besseren "Fit" zwischen Datenpunkten und Gleichung, mit einer Korrelation von fast 99 Prozent gegenüber 96 Prozent bei der linearen Regression:



(in meiner Tabelle oben muss es übrigens "16 Liter" heißen für den ersten Wert, nicht 14)

Bin mir momentan noch nicht ganz sicher, woran das liegt. Möglicherweise drückt das Eigengewicht des Benzins den Tank auseinander mit zunehmender Spritmenge, und dieser multiplikative Effekt wird dann wiederum wieder kleiner (1. Ableitung negativ) mit zunehmender Füllmenge...

Am Ende ist es wohl im "täglichen Betrieb" egal ob wir 99 oder 96 Prozent Korrelation haben. Bei vollem Tank macht es ca. einen Liter Unterschied, und bei 10 Litern Tankfüllung etwa ein Wasserglas voll. Ganz zu schweigen davon, dass wir wegen der Tank-Form eh große Schwankungen beim Tankgeber-Stand haben (was sich aber wie oben erwähnt wahrscheinlich "rausrechnen" lässt wenn der Bordcomputer sich immer die kumulierte Einspritzmenge merkt). Aber wenn man sich schon die Mühe macht ne Tankinhalt-Anzeige in den Bordcomputer einzubauen, dann kanns nicht schaden es auch "rechnerisch" möglichst genau zu machen.

Werd aber wohl demnächst nochmal ne zweite Tankgeber-Messung machen. Mir ist momentan noch nicht klar, wieso der Tankgeber die gleichen Messwerte hat bei 0 Liter und 5 Litern. Kann sein, dass ich beim Messen in der Zeile verrutscht bin beim Eintragen der Werte... keine Ahnung.

So, hab mir dann heute bei Conrad mal ein paar SMD-LEDs besorgt für die Nacht-Beleuchtung (siehe hier: https://www.conrad.de/de/smd-led-plcc2- ... 50357.html )

Wie man sehen kann, sind sie von der Größe her in etwa an der Grenze des von Hand Lötbaren :



Der Farbton haut jedenfalls in etwa hin:



Und das müsste man dann am Ende so machen, dass die LEDs in den Rahmen des Displays seitlich eingebaut werden, denn die LEDs die jetzt schon im Display verbaut sind leuchten dieses auch von der Seite her aus.



Momentan bin ich mir noch nicht sicher, ob die Leuchtstärke von 180 mCd genug sein wird. Werd mir wohl eher nochmal ein paar hellere LEDs besorgen zum Ausprobieren.

Für den MkI könnte man dann statt oranger LEDs vielleicht gelbe/bernsteinfarbene nehmen, weil das wohl besser zur Instrumentenbeleuchtung des MkI passt.

Hab die letzten ein zwei Abende damit verbracht, die Warnmeldungen auf das Display zu bringen.

Schlägt ein Sensor an, dann wird das betreffende Warn-Icon von der Speicherkarte geladen und auf dem Bildschirm angezeigt. Im Programmcode ist festgelegt, welche Warnung wie lange angezeigt wird und in was für Zeitabständen an den Fehler erinnert wird. Bei zu niedrigem Kühlwasserstand gibt es z.B. alle zwei Minuten (d.h. 120.000 Millisekunden) eine Warnmeldung mit 10 Sekunden Piepton, weil das ziemlich wichtig ist. Bei Wischwasser wird nur einmal mit nem 5-Sekunden-Piepton gewarnt, und dann 10 Minuten später wird nur noch das Bild erneut angezeigt, weil es ja von nachrangiger Bedeutung ist und deshalb der Fahrer nicht jedes Mal mit nem Piepton genervt werden muss.

So sieht das dann im Programmcode aus... ein zweidimensionales Array:



Um "Fehlsignale" zu eliminieren, ist auch festgelegt dass ein Sensor mehrmals hintereinander auslösen muss, bevor eine Warnmeldung rausgegeben wird (siehe Felder "error counter" und "max. error counter"). Und schließlich sollen die Warnungen auch noch funktionieren wenn die Speicherkarte mal versagt, und dann wird der "alt text" auf dem Bildschirm angezeigt.

Die "small icons" sind Miniatur-Versionen bestimmter "wichtiger" Fehlermeldungen in 20x20 Pixel Größe, zum Beispiel Öl und Kühlwasser und Beleuchtung, die im laufenden Betrieb dann bei Fehlern am unteren Bildrand der Menü-Bildschirme als Erinnerung zusätzlich angezeigt werden.

Ein paar Sachen an dem Code laufen noch nicht ganz rund; aber ich denke, zu Weihnachten könnte eine Beta-Version des kompletten Programmcodes des Display-Moduls fertig sein


Hier mal ein Video dazu, wie das dann "in natura" aussieht:

http://www.filedropper.com/20161013155254-2

(leider sieht sowas als Video-Datei immer sch... aus wenn man ein TFT-Display abfilmt... in "echt" kommt es viel besser rüber...

@MGF74
Nimms mir nicht Übel . Auf den Link gedrückt , bunte Bilder , Werbung , Link suchen, und sofort weg gedrückt . Ist mir echt Schleierhaft warum in der heutigen Zeit mit Dropbox , One drive und wie sie alle heissen jemand sein Video auf so ne Werbeverseuchte Seite lagert.

Ich halte nicht viel von Dropbox. Und so extrem ist das ja bei dem Freehoster da auch nicht mit Werbebannern und so. Da gibts deutlich schlimmere.

Vielleicht werde ich aber mal einen Youtube-Account aufmachen wenn das Projekt weiter vorangeschritten ist und es noch ein paar andere Sachen gibt die sich lohnen per Video festzuhalten.

Die Fehlermeldungen laufen jetzt stabil und werden anhand der Daten in der Fehlertabelle abgearbeitet. Für die ganzen Verbrauchs-Daten und so werd ich wohl eine ähnliche Tabelle machen. Darin könnten dann jeweils die sich ändernden Daten festgehalten werden. Und wenn dann der Motor ausgemacht wird, dann werden sie aus der Tabelle in den EEPROM des Chips geschrieben, und beim nächsten Anlassen von dort wieder ausgelesen und neu in die Tabelle geschrieben. So hätte der Programmcode sozusagen eine rudimentäre Datenbank-Funktion.

Falls man nachher wirklich eine Bluetooth-Anbindung ans Smartphone macht, könnte man die Fehlermeldungen vielleicht sogar mit Uhrzeit und Datum in der betreffenden Smartphone-App speichern. Denkbar wäre, dass das Smartphone dazu nen Unix-Timestamp an das Haupt-Modul schickt jedesmal beim Anlassen wenn das Smartphone mit dem Bordcomputer gepaired wird, und dass dann der interne Timer des Chips die einmal abgeglichene Unix-Zeit verwendet. Aber bis es so weit ist, wird noch viiiiiiel Zeit vergehen.

So, nachdem dieses Thema ja ein bisschen "eingeschlafen" ist (hatte auch nicht wirklich viel Zeit um das Projekt deutlich weiterzuentwickeln), hier nun mal ein "status quo"...

Ich habe angefangen, das Bordcomputer-Hauptmodul einfache Berechnungen machen zu lassen mit den Daten die aus den anderen Modulen geliefert werden. Sowas wie Momentanverbrauch, Reichweite und Durchschnittsgeschwindigkeit. Denke mal, in etwa Ende Januar könnte die Software des Hauptmoduls in ner Beta-Version fertig sein. Und dann wird es halt daran gehen, dass man zum Frühjahr hin einen ersten Prototyp baut der an den MG angeschlossen wird.

Bis dahin muss ich aber noch ein bisschen forschen an diversen Sensoren. Ich werde nochmal den Tankgeber ausmessen, und außerdem müssen noch die Öl- und Wassertemperatur-Sensoren ausgemessen werden.

Am "braunen" Kühlwassersensor im MG muss man einfach nur eins von beiden Kabeln anzapfen, dort liegt direkt eine variable Spannung in Abhängigkeit von der Temperatur an. Bei mir ist das das weiß-grüne Kabel:




Mit dem Öltemperatursensor ist das etwas kniffliger. Dort geht nur ein Kabel rein und auf dem sind konstant 12V. Es wird wohl so sein, dass das Gehäuse des Öltemperatur-Sensors selbst einen Massekontakt hat, der über die Ölwanne und den Motorblock geschlossen wird. Aber auch damit kann man ja was anfangen, indem man einen Spannungsteiler baut auf den man 5 Volt Referenzspannung gibt (der MC läuft eh auf 5V), und den erdenden Widerstand R2 dann mit dem Kabel des Sensors verbindet (mit ner Sperrdiode, weil sonst am Mikrocontroller direkt 12V anliegen, womit ich beim Testen bereits einen Chip gebraten hab ). Verändert sich dann der Widerstand des Ölsensors, dann verändert sich auch die hinter dem Spannungsteiler gemessene Spannung.

Eigentlich war ja geplant, mit Thorstens Laptop die Sensoren auszulesen und halt nebenher zu messen wie die Widerstände sich mit zunehmender Temperatur verändern. Aber da wir jetzt erstmal nicht bei meinem Wagen ins OBD reingekommen sind, wird der Plan B so aussehen, die Sensoren im ausgebauten Zustand zu vermessen. Und dann werd ich sie entweder auf dem Herd in warmes Wasser tauchen oder sie auf so ner Art Ständer montieren und dann mit einer Kerze oder so vorsichtig immer näher dran gehen.

Ich hab dazu, also nur um die Sensoren erstmal auswerten zu können, ne rudimentäre Schaltung gebaut mit der dann über Mikrocontroller der genaue Widerstandswert gemessen wird (indirekt als Spannungswert zwischen 0 und 5V, bzw. als numerischer Wert zwischen 0 und 1023). Gleichzeitig werd ich mit einem DS18B20-Temperatursensor fortlaufend die Temperatur protokollieren. Aus dem laufenden Programm des Mikrocontrollers heraus könnte man dann einfach einen data dump erzeugen, in dem fortlaufend die Sensor-Widerstands-Daten zwischen -18°C und +120°C protokolliert werden. Und darauf aufbauend kann man dann eine lineare Beziehung zwischen Temperatur und Widerstandswert ermitteln, mit der ich später im Code des Bordcomputer-Hauptmoduls dann die Kühlwasser- und Öltemperatur errechnen kann.

Flamme? und mit 2. Sensor dann Temp-Werte aufnehmen ? ob das genau wird ?

bis 100°C würde ich vielleicht noch Wasser nehmen, oder gleich Sensoren in Ölbad erwärmen, das ist sicherlich homogener als ne Flamme, und geht auch über 100°C.
Ölpfännchen erhitzen, oder gleich ne Friteuse nehmen.

Reichen die Daten von Dieter und Toms Seiten nicht ?
http://www.mgfcar.de/sensor/
http://www.tom-seven.stillgame.ch/wiki/ ... put_to_ecu
andere Sensoren auch auf Toms Seite

Ist halt die Frage, was ist praktischer... Kochtopf oder Flamme? (Speise-)Öl oder Wasser im Topf?

Anfangen werd ich wohl in jedem Fall damit, die Sensoren über Nacht ins Gefrierfach zu legen bis sie -18°C haben.

Eine "Kniffligkeit" kommt noch dazu... der DS18B20-Sensor geht nur bis 120°C... mir ist jetzt grad eingefallen dass beim MG der rote Bereich der Öltemperatur ja erst bei 150°C anfängt...

Hab grad gesehen, der Rauchpunkt von Speiseöl ist je nach Sorte 100-180°C... müsste man mal schauen was man am besten nimmt, ohne sich damit die ganze Küche einzunebeln... Motoröl möcht ich im Zweifelsfall nicht nehmen in nem Topf mit dem ich normalerweise mein Essen koche...

Zumindest die Werte auf Dieters MG-Seite sind mir etwas zu vage für die Temperatursensoren... mit meinem Versuchsaufbau könnte ich viel genauer die Beziehung zwischen Temperatur und Widerstand ermitteln. Der zweite Link ist schon interessanter, kann man auf jeden Falls als Eckdaten nehmen um die Plausibilität der eigenen Messungen zu überprüfen. Allerdings steht da auch nix zum Ölsensor.

Auf die Schnelle:
ich würde eine Dose Ravioli oder Chilli con Carne essen, dann hast Du ne Konservendose.
Speiseöl-> einige Öle kannst Du sehr hoch erhitzen, Pommes in der Friteuse geben ja bis 200 Grad.
Motorradketten haben wir mit Bunsenbrenner in Dosen gekocht, nachdem wie wegen der Sauerei Küchenverbot erhielten. Motor- oder Getriebeöl kannst Du sicherlich auch nehmen.

Nur Sensoren in das Gefrierfach ? ich vermute, das wird dann aufgrund der Unterschiedlichen Erwärmung unter Umständen im Minusbereich für beide Sensoren nicht gleiche Werte liefern.
Besser Dose mit Öl ins Gefrierfach, muss halt bei -18 Grad noch flüssig sein.

bei Dieters Seite sind je nach VIN unterschiedliche Sensoren für das Öl angegeben. Eventuell andere Werte bei anderem Sensor ? eventuell sind die Abweichungen zu vernachlässigen.

DS18B20 bis 120 Grad. Dann würde ich einfach einen anderen Sensor nehmen.
manche gehen bis 150 Grad, andere bis 600 Grad.

Keine Ahnung ob die Messung mit IR-Temperatur-Messgerät funktioniert, wahrscheinlich schon.
Wenn Du die Daten nicht Rechner mitschreiben musst, dürfte dies machbar sein, oder ?

bei Tom ist der Öl-NTC zwar auch vorhanden, Messwerte aber dort nur von 40 - 80 Grad.

Gehärtetes Erdnussöl hat bei 230 Grad den Rauchpunkt.

Hab nochmal recherchiert, es gibt für die Arduino-Platform mit der ich den Bordcomputer entwickle Thermoelement-Sensoren:

http://www.ebay.de/itm/MAX6675-Module-K ... 3641.l6368

Damit könnte man dann auch Temperaturen oberhalb von 120°C ganz bequem mit dem Mikrocontroller loggen und dann weiter auswerten.



Ja, hab ich auch gesehen. Aber der Knackpunkt scheint wohl eher zu sein, dass der Öltemp-Sensor vom MPI ein anderer ist als der vom VVC. Sollen sich wohl auch in den Widerstandswerten unterscheiden... z.B. 574 Ohm bei 60°C beim MPI, 221 Ohm bei 60°C beim VVC.


Werd mir wohl für die Messungen die zwei verschiedenen Öltemperatur-Sensoren besorgen. Man könnte dann die Unterschiede nachher beim Bordcomputer in den "Settings" berücksichtigen. Dass man halt einstellen kann ob der Bordcomputer an nem MPI oder VVC angeschlossen ist. Wird man ohnehin machen müssen, weil der VVC andere Einspritzdüsen hat (höhere Durchflussmenge) als der MPI und die Düsen zudem beim VVC einzeln angesteuert werden (beim MPI werden sie paarweise geöffnet).

Hauptsache Du ruinierst die Küche nicht mit einem Fettbrand. Und bitte nicht mit Wasser löschen.

Ich hab nen Gas-Herd... hab schon oft genug ne kleine Stichflamme in der Pfanne gehabt wenn ich mal ein Schnitzel scharf angebraten hab... gehört dazu

Ist aber ein berechtigter Einwand. Da muss man schon vorsichtig sein.

Zur Not könnte man ja auch die Messungen bis 100°C mit Wasser im Kochtopf in der Küche machen, und dann die Hochtemperatur-Messungen bis 170°C mit Öl auf nem stabilen Camping-Kocher draußen im Garten. Dann sollte man aber wirklich Speiseöl nehmen und kein Motoröl... wenn der Topf umkippt und das Zeug ins Erdreich gelangt dann hat man sonst noch ganz andere Probleme...

Bei nem Mk1 könntest du natürlich auch einfach die Sensoren komplett gegen klar definierte Teile aus dem Zubehör tauschen. Wasser- und Öltemperaturanzeige brauchst du ja im Prinzip dann nicht mehr, und bei MEMS 1.9 wird die Öltemperatur vom MSG eh nicht ausgelesen.

Mal so'n Einwurf von der Seitenlinie zu Temperatursensorik und Genauiglkeit.
Die Standardsensoren mit NTC erreichen höchstens +-10% und bei 150° ist Schluß. Es geht von Natur aus bei den für Endverbraucher erhältlichen Dingern kaum was besser und die Langzeitstbilität ist übel.
http://blog.wika.de/know-how/pt100-pt10 ... -richtige/
PT 100 oder PT1000, mal hingucken.
https://www.sensorshop24.de/temperaturs ... -5-stueck/

Das Problem hat man ja immer... wer misst, misst Mist...

Das mit der Langzeit-Genauigkeit ist tatsächlich ein Problem. Außerdem ist ja im Fall von Kühlwasser und Öl auch die Temperatur nicht an allen Stellen der Kreisläufe gleich. Und das Öl in der Ölwanne, wo der Öltemperatur-Sensor beim K-Series-Motor sitzt, wird ja zusätzlich durch den Fahrtwind und die in die Ölwanne eingearbeiteten Kühlrippen gekühlt...

Die Frage ist halt jetzt, macht man es sich einfach und zapft einfach die fahrzeug-eigenen Sensoren an, und übernimmt ihre Messungenauigkeit mit in die Bordcomputer-Software wo damit dann ungenaue Berechnungen gemacht werden, oder misst man das ganze wirklich extern. Bei einer externen Messung mit eigenen Sensoren, von mir aus auch Pt100 oder Pt1000, wird man das Problem haben, dass man sie irgendwie im Öl- oder Wasserkreislauf anbringen muss sodass sie von der Flüssigkeit umströmt werden. Da beide Systeme unter Druck stehen, wird das halt schwierig sein. Und es ist die Frage, ob sich der Mehraufwand lohnt.

Am Ende hat man eh immer nur Schätzeisen. Genauso wie der Tacho im F und TF kein geeichtes Präzisions-Instrument ist. Und die Kühlwassertemperaturanzeige hat ja nicht mal ne richtige °C-Skala...

Aber der Tip mit den Pt1000-Sensoren ist nicht schlecht, muss ich mir merken. Hab gesehen, dass es die bei eBay auch in gekapselter wasserdichter Ausführung gibt für wenig Geld. Für unsere Zwecke hier wäre ein Pt1000 am besten, weil ja der Mikrocontroller eh alle Messungen eher hochohmig macht.

Für die Innenraum- und Außentemperaturanzeigen werden aber die DS18B20-Dinger erstmal reichen. Die haben zudem den Vorteil, dass sie die gemesene Temperatur direkt in °C per Datenleitung an den Mikrocontroller weitergeben.