Hallo,

wollte mal mein gegenwärtiges "Langzeit-Projekt" an meinem MGF vorstellen.

Und zwar entwickle ich gerade einen Bordcomputer mit Verbrauchsanzeige für meinen MGF MkI. Hört sich verrückt an, ist aber eigentlich garnicht so wild.

Der Bordcomputer soll, wenn er fertig ist, den Momentanverbrauch, den Verbrach je 100 km und die Reichweite anzeigen. Und zwar auf einem kleinen 2-Zoll-TFT-Display, welches im Armaturenbrett unterzubringen sein wird.

Und wenn die Funktionen fertig implementiert sind, dann könnte man vielleicht auch darüber nachdenken, dass man mit diesem Bordcomputer auch Sachen überwacht/misst wie den Wischwasser-Füllstand, die Außentemperatur, die Innenraumtemperatur usw usw.

Basieren wird das ganze auf Atmel ATmega328P-Microcontrollern (möglicherweise auch Attiny85), die mit einem Arduino-Board programmiert werden und dann wenn's fertig ist ihre Arbeit als Standalones leisten. Die Hardware-Architektur wird modular sein, d.h. ich werde ein Modul hintem im Wagen haben was Einspritzzeiten, Geschwindigkeit und Tankinhalt misst, und vorn im Armaturenbrett wird das Haupt-Modul mit der TFT-Anzeige sein, welches per I2C-Bus seine Daten vom Mess-Modul erhält. Bedingt durch diesen modularen Aufbau könnte man das System somit auch später einmal erweitern, z.B. auf eine Lampen-Kontrolle oder die Ansteuerung einer Sitzheizung. Das ist aber noch "Zukunftsmusik".


Bislang habe ich folgendes gemacht:

- Einspritzsignal ausgemessen:

Die Einspritzdüsen werden direkt vom Motorsteuergerät geschaltet. Dort liegen Kabel an die man direkt anzapfen kann, und zwar öffnen die Düsen sich im Mittel jeweils zwei Millisekunden. Die Kapazität der Einspritzdüsen ist bekannt, laut Datenblatt von Bosch, und beträgt beim MPI 137 g/min n-Heptan (ca. 201 ml), und beim VVC 150 g/min n-Heptan (ca. 220 ml).

Beim MPI werden die Einspritzdüsen paarweise geschaltet, d.h. immer Nr. 1 und Nr. 4 zusammen, und Nr. 2 und Nr. 3. Das Öffnen geschieht dadurch, dass die Düsen auf Masse geschaltet werden. Im Oszi kann man das daran sehen, dass die Spannung für einen kurzen Moment auf null sinkt:



Mit steigender Motordrehzahl werden die Abstände zwischen den Einspritzintervallen kürzer und die Einspritzintervalle selbst werden länger.

Das Signal wird mit einem ILD74 Optokoppler gefiltert um ein schön gleichmässiges Rechtecksignal ohne Einschalt-Spannungsspitzen zu haben (welche einen Mikrocontroller beschädigen könnten, da sie laut Literatur +70V betragen können in dem Moment wo die Einspritzdüsen wieder auf 13V geschaltet werden, siehe Oszi).

Hieraus lässt sich zum einen ein Momentanverbrauch in Liter pro Stunde berechnen (wenn der Wagen steht), und zum anderen in Liter pro 100 km wenn der Wagen fährt. In meiner Berechnung addiere ich alle drei Sekunden die Millisekunden auf, während derer die Einspritzdüsen offen waren. Dann habe ich meinetwegen sowas wie einen Wert von 450 Millisekunden pro 3 Sekunden. Dies multipliziert mit der Kapazität der Einspritzdüsen pro Millisekunde liefert mir die eingespritzte Menge pro 3 Sekunden, und das lässt sich wiederum auf eine Stunde hochrechnen. Um die Genauigkeit zu erhöhen, könnte man vielleicht dann noch ein paar mathematische Glättungsverfahren bei der Berechnung einsetzen. Um zum Beispiel "Ausreißer" bei den Messwerten zu eliminieren.

Und zu guter letzt kann man diese Werte mit dem Signal des Tankgebers in Beziehung setzen für eine Reichweiten-Anzeige. Dieser Tankgeber ist nichts anderes als ein Schleifwiderstand, der ca. 10 Ohm bei vollem Tank und 120 Ohm bei leerem Tank beträgt.


- Geschwindigkeitssignal gemessen:

Etwas kniffliger ist die Erfassung des Geschwindigkeitssignals. Der MGF MkI hat eine mechanische Tachowelle, und diese generiert zwar über einen Magnetkontakt im Tachomodul ein Rechtecksignal welches man in der Bordelektronik anzapfen kann, aber dieses ist viel zu ungenau für eine Verbrauchsmessung mit auch nur annähernd befriedigender Genauigkeit... hier mal z.B. bei 30 km/h:



Nach oben hin wird die Varianz zwischen den einzelnen HIGHs und LOWs zwar geringer, aber es nützt ja nix wenn der Bordcomputer nur verlässliche Werte anzeigt wenn man über 100 km/h fährt...

Deshalb habe ich heute bei eBay einen Hallsensor gekauft der direkt zwischen Getriebe und Tachowelle geschraubt werden kann und direkt von der Quelle ein - hoffentlich homogeneres - Rechtecksignal liefern wird.


Vielleicht werde ich auch noch das Drehzahlsignal vom Kurbelwellensensor verarbeiten um eine exakte Motordrehzahl auf dem Display anzeigen zu können, aber da weiß ich noch nicht ob sich der zusätzliche Aufwand lohnt, da dies ein sehr schnelles Signal im Mikrosekunden-Bereich ist. Und nen Drehzahlmesser haben wir ja sowieso...


- Test Rig gebaut:



Das Breadboard ganz links ist ein Bitbanger, d.h. es simuliert die Rechtecksignale von Einspritzung, Geschwindigkeitssensor und Kurbelwellensensor (und den Tankinhalt). Auf dem mittleren Board nimmt gerade das Mess-Modul Gestalt an, welches diese Werte misst und dann per I2C-Datenbus an das rechte Board weiterleitet, wo die Werte aufbereitet und auf einem Display dargestellt werden. Das ist nicht das endgültige Display was nachher im Wagen montiert sein wird... als Bildschirm wird wahrscheinlich ein Adafruit 2.2''-Display dienen:

https://www.adafruit.com/product/1480


Und so sieht es aus, wenn man mit dem Auto auf "Messfahrt" ist, um die ganzen Werte zu ermitteln die man später für den Bordcomputer braucht:




Momentan ist alles noch in der Frühphase, und ich habe bisher die Schaltungen nur auf Breadboards aufgebaut. Die Schaltung an sich ist zu ca. 65 Prozent fertig konzipiert, der Programmcode in etwa zu 45 Prozent. Nachher wird alles fein säuberlich auf Platinen aufgelötet, in Modulgehäuse verpackt und im Wagen verbaut.

Ich bin bislang gut bei dem Projekt vorangekommen, aber ich denke, es wird in etwa bis nächstes Frühjahr dauern bis das Endprodukt fertig und präsentierbar ist. Aber wie heißt es so schön... mühsam nährt sich das Eichhörnchen...

Ich werd mit Sicherheit noch ein paar Fragen haben zur Technik des MGF, also wärs schön wenn ich mich während des Projekts an einige von euch hier wenden könnte die sich gut auskennen...



Viele Grüße,

MGF74

Na wenn du das dann mal ordentlich kompakt hinbekommst, dann könnte ich mir überlegen es zu kaufen.

Ich hatte eigentlich eher vor, das als "open source" zu machen. Soll heißen, ich veröffentliche am Ende die Baupläne und die Programmiercodes zum Selbermachen. Könnte aber trotzdem die fertig programmierten Mikrocontroller beisteuern, dafür würde ich dann nen kleinen "Selbstkostenbeitrag" nehmen.

Ich hab allerdings gleich mal ne Frage... ist hier wer der nen VVC hat und ein Oszilloskop, und mal zum Vergleich das Einspritzsignal und das Signal vom Kurbelwellensensor vom VVC messen könnte? Auch interessant wäre, wie das Geschwindigkeitssignal bei MkII/TFs aussieht, die ja einen elektrischen Geschwindigkeitssensor haben anstatt der Tachowelle vom MkI.

Der nächste Schritt bei meinem Wagen wird jetzt sein, den Hallsensor zu verbauen den ich bei eBay gekauft habe. Hier mal der Link:

http://www.ebay.de/itm/Tachogeber-Gesch ... 1620489105

Auf "Dieter's" MGF-Seite ist im Bereich "Navi-Nachrüstung" der Tipp zu sehen, einen Hallsensor von VDO einzubauen für ein Geschwindigkeitssignal. Dieser ist allerdings bei VDO inzwischen entfallen, ich habe gestern jede Menge rumtelefoniert deswegen aber es war nix zu machen. Das Teil da bei eBay sollte allerdings den gleichen Zweck erfüllen, es scheint "optisch" zumindest baugleich zu sein.

Da dieser Hallsensor im Gegensatz zu dem VDO-Teil nicht drei- sondern zweiadrig ist, schätze ich mal, dass er ganz einfach Masse durchschaltet. Damit wird die Verkabelung etwas anders sein als bei dem VDO-Hallgeber, aber am Ende dürfte es aufs gleiche hinauslaufen und er dürfte ein brauchbares Geschwindigkeitssignal liefern.

Geschwindigkeitssignal gibt der F doch elektrisch aus . Warum nutzt du das nicht ?

Tu ich doch.

Nur eben ist das beim MkI etwas knifflig, da das Geschwindigkeitssignal von der mechanischen Tachowelle erzeugt wird. Ab MGF MkII wurde das Geschwindigkeitssignal direkt am Getriebe elektrisch erzeugt mit nem Hallgeber. Bedingt durch die Tachowelle ist das Signal halt zu ungenau. Fürs ABS und andere Aggregate im MkI ist es vielleicht nicht so tragisch, aber wie man oben sehen kann bei dem Screenshot vom Geschwindigkeitssignal, bekommt man kein stetiges Rechtecksignal bei einer konstanten Geschwindigkeit hin. Die Highs und Lows schwanken in ihrer Intervalldauer wie es ihnen passt.

Klar könnte man auch einfach sagen, man nimmt ganz einfach den Mittelwert der Intervall-Längen. Aber genauer wird die Kraftstoffverbrauchs-Berechnung damit nicht.

Das Signal vom Hallgeber ab MY1999 würde ich dann auch nicht nehmen. Nicht ohne Grund ist beim Stepspeed noch ein zweiter “genauerer” Geschwindigkeitsgeber verbaut worden.

Ich hab mir jetzt halt erstmal den hier geschossen bei eBay:

http://www.ebay.de/itm/Tachogeber-Gesch ... 1620489105



Wird leider erst nächste Woche geliefert (hab leider nicht gesehen dass die so ne lange Lieferzeit haben) aber werd dann nächstes Wochenende mal das Ding einbauen und einfach mal schauen was es für Werte liefert. Dieser Geber wird anscheinend bei neueren Chevrolet (d.h. früher Daewoo) verbaut.

Ich brauche halt ein möglichst genaues und stetiges Signal, denn ich muss die Geschwindigkeit "reverse engineeren" aus dem Rechtecksignal, d.h. ich muss tatsächlich gucken, wie sieht das Signal aus bei 10, 20, 30, 40, 50, 80, 100, 130... usw km/h... die Intervall-Längen bei den jeweiligen (mit GPS aufm Smartphone) gemessenen Geschwindigkeiten werd ich mir aufschreiben, und dann wird damit mithilfe des statistischen Verfahrens der Regressionsanalyse eine lineare Funktionsgleichung bestimmt (nach dem Motto y = m*x+b, wie man's noch aus der Schule kennt ), die mir mit annähernder Genauigkeit die jeweilige Geschwindigkeit in km/h bei gegebener Intervall-Länge liefert.

Nur eben sind solche Verfahren wie die Regressionsanalyse wenn man Pech hat "garbage in - garbage out"... wenn meine erhobenen Messwerte nicht einigermaßen genau sind, dann bildet nachher auch die Funktionsgleichung den Zusammenhang zwischen Rechtecksignal und km/h nicht richtig ab, und dann kann man sichs gleich sparen...

Um die Genauigkeit zu erhöhen, wäre später auch noch denkbar, einen Korrekturfaktor bezüglich verschiedener Reifengrößen einzubauen. Das wäre dann ja quasi nur eine einfache multiplikative Konstante, die man in die Funktionsgleichung mit einsetzt. Ich plane bei dem Bordcomputer ein "Setup"-Untermenü, bei dem man sowas vielleicht dann alles einstellen kann vor der ersten Inbetriebnahme. Das alles wird ne Weile dauern... aber ich sagte ja bereits, vor nächstem Frühjahr wird der Bordcomputer eh nicht fertig...

Außerdem hab ich gestern per GPS festgestellt, dass mein Tacho 8 Prozent vorgeht... also bei 100 km/h laut GPS sind's 108 km/h laut Tacho... sowas muss man auch noch berücksichtigen...

Update:

Habe mich entschlossen, die Motordrehzahl ebenfalls mit dem Bordcomputer zu messen.

Dies wird aber nicht mehr der Atmega328P-Controller machen können, weil der schon genug damit zu tun hat, die Einspritzzeiten und das Geschwindigkeitssignal zu überwachen.

Stattdessen wird die Motordrehzahl über einen separaten Attiny85-IC gemessen, der NUR die Takte des Kurbelwellensensors zählt und nix anderes macht, und daraus die Motordrehzahl errechnet.

Das Signal vom Kurbelwellensensor ist nämlich sehr schnell und bei 6000/min dürfte eine Intervall-Länge um die 200 Mikrosekunden betragen.

Hier mal ein Kurbelwellensignal-Screenshot, bei 3000 rpm:



Damit sich der Atmega328P nicht dabei "verzählt", so ein schnelles Rechtecksignal zu überwachen und parallel dazu wie gesagt auch noch auf die Einspritzzeiten und die Geschwindigkeit zu zählen, werden Atmega328 und Attiny85 in meinem Messmodul parallel laufen.

Hier mal die beiden ICs im Vergleich, oben der Attiny85, unten der Atmega328P-PU:



Die Refresh-Rate für das Drehzahlsignal werde ich wohl bei 250 ms ansiedeln, das heißt wenn das Bordcomputer-Display im "Engine Stats"-Modus ist und Motordaten wie Öltemperatur, Wassertemperatur usw. anzeigt, dann wird jede Viertelsekunde die angezeigte Drehzahl geupdated. Die Drehzahl werde ich wohl immer als gleitenden Mittelwert der letzten zehn Kurbelwellensensor-Takte bestimmen oder so.

Öltemperatur und Kühlwassertemperatur muss ich irgendwann demnächst mal ausmessen. Die Temperaturgeber sind ja eigentlich nur Thermistoren die unterschiedliche Widerstände bei unterschiedlichen Temperaturen haben. Diese Widerstände kann der Atmega328P-PU direkt an seinen speziellen analogen Eingangs-Pins messen als Spannungsdifferenz gegenüber einer Referenzspannung, und daraus dann die Öltemperatur etc. errechnen. Aber da werde ich noch einiges an "Grundlagenforschung" vor mir haben...

Cooles Projekt!

So, gestern wurde das TFT-Display geliefert, welches ich mir bei eBay zu Testzwecken geschossen hatte.

Nach einigem Fluchen über eine nicht vorhandene Bedienungsanleitung und die verzweifelte Suche nach dem passenden Treiberpaket (dafür hat das TFT auch nur sieben Euro gekostet ), konnte ich heute abend endlich mal ein bisschen experimentieren:



Der fertige Bordcomputer wird dies in etwa als Einschaltbildschirm haben. Leider kommen auf dem Foto die Farben nicht so gut raus, aber es sieht wirklich nicht schlecht aus. Gestochen scharf und schön kontrastreich. Rotbraunes MG-Logo, dazu das "Welcome" in blau, und das "MG Driver Info System" in schwarz.

Dieser Startbildschirm kann natürlich vollkommen personalisiert werden, falls irgendwer von euch wirklich mal Interesse hat sowas bei sich einzubauen...

(sollten sich wirklich genug Interessenten finden wenn ich den Bordcomputer fertig habe, dann könnte man überlegen, die Hardware in ner Kleinserie herzustellen... falls irgendwer von euch Ahnung hat von SMD-Platinen-Design, bitte irgendwann zwischendurch mal ne PM an mich )

Als nächstes wird wohl zum Wochenende hin der Hallgeber bei mir ankommen für das Geschwindigkeitssignal vom Getriebe... das wird nochmal eine spannende Angelegenheit, den zu begutachten und umfangreich zu testen...

EDIT:

Hier nochmal ein hochauflösendes Bild:



Für ein TFT in dieser Größe, zumal für 7 Euro, geht die Qualität absolut in Ordnung.

In meinem eigenen MG werde ich aber am Ende wohl eher ein AMOLED- oder uLCD-Display verbauen, so ähnlich wie es moderne Smartphones haben. Kostenpunkt dann so um die 35-50 Euro, wahrscheinlich mit 2,4 Zoll Bilddiagonale. Da wird dann die Bildauflösung auch nochmal um Klassen besser sein.

Hohe Auflösung schön und gut - ich würde bei der Displaywahl jedoch 'Lesbarkeit bei Sonneneinstrahlung' den Vorrang geben...

Cooles Projekt btw!

Da kannst du AMOLED eigentlich schon vergessen . Glaub auch nicht das die auf Dauer mit den Temperaturen im Innenraum klarkommen . Den wird da ganz fix die Puste ausgehen.

Ja, Lesbarkeit ist ein wichtiger Punkt... das Display soll untergebracht sein in der Mittelkonsole, zwischen Uhr und Öltemp-Anzeige. Ich werde dazu den Warnblinkschalter in die Mittelkonsole verlegen und die Aussparung des Warnblinkschalters etwas vergrößern damit ein 2.4''-Display reinpasst.

Das ist natürlich eine Stelle an der das Display viel Wärme ausgesetzt ist. Einmal durch die Sonne wenn man offen fährt, aber auch durch die Abwärme der Heizung. Wahrscheinlich ist dann TFT oder uLCD doch besser. Obwohl man das Display ja zumindest gegen die Abwärme der Heizung schützen könnte mit ein bisschen Schaumstoff drumherum...

Der "Mercedes" unter den Displays scheint das hier zu sein:

http://www.4dsystems.com.au/product/uLCD_24PTU/

Das Display hat einen eigenen Prozessor on-board... damit würde der MC in meinem Display-Modul einfach nur die Messdaten aus dem Auto einsammeln und ans Display schicken zur grafischen Aufbereitung... das Ding hat sogar nen eingebauten Mini-Lautsprecher für akustische Signale... und es gibt ne eigene Software Suite dazu um Menü-Bildschirme per Drag & Drop zu erstellen.

Der Touchscreen würde auch bedeuten, dass man keine physischen Bedienknöpfe braucht... obwohl ein 2.4''-Touchscreen vielleicht doch etwas fummelig wäre...

Aber so weit bin ich erstmal noch nicht. Momentan entwickle ich immer noch das Mess-Modul, welches hinten im Wagen die ganzen Daten misst wie Einspritzzeiten, Geschwindigkeit, Motordrehzahl etc etc... wenn das Modul zuverlässig die Daten erheben kann, dann wird der nächste Schritt sein, die Daten per I2C an den MC im Display-Modul des Bordcomputers zu schicken.

EDIT:

So, gerade kam mein Hallgeber mit der Post.



Anders als auf dem Bild bei eBay, hat dieser ein dreiadriges Kabel. Und ist somit offenbar ein vollwertiger Ersatz für den entfallenen VDO-Geber, welchen Dieter auf seiner MGF-Website abgebildet hat.

Wer an seinem MkI die Nachrüstung eines Hallgebers für ein verlässliches Geschwindigkeitssignal fürs Navi plant, hier mal die Artikel-Details:



Der Geber wird so offenbar bei Chevrolet-Kleinwagen (Ex-Daewoo) verbaut.

So, inzwischen ist der Bordcomputer so weit, dass er Rechtecksignale von Einspritzung, Kurbelwelle und Geschwindigkeitssensor erfassen und mit ihnen rechnen kann.

Momentan werden diese Rechtecksignale immer noch künstlich erzeugt von einem IC der an den Eingängen des Bordcomputers diese Rechteck-Signale erzeugt, aber diese künstlichen Signale sind schon recht wirklichkeitsnah.

Hier mal ein Blick auf die Anzeige so wie sie jetzt ist:



Zum einen muss man sagen, dass Bilder immer nur sehr schlecht wiedergeben können, wie so ein TFT-Display in natura aussieht. So wie das TFT jetzt hier auf meinem Schreibtisch in Betrieb ist, ist der Hintergrund ein sehr gleichmässiges Weiß ohne groß erkennbare Pixelung.

Andererseits gefällt mir nicht, wie die Schriften gerendert werden. Bei diesen TFT-Displays sind bei der Treiber-Software immer ein paar Schriften mit dabei, aber die taugen irgendwie nicht so viel... wie man sehen kann, haben die einzelnen Ziffern manchmal einen oder zwei Pixel vertikalen Versatz zueinander oder sind nen Pixel größer oder kleiner. Bei Buchstaben ist es weniger schlimm, aber irgendwie sehen Zahlen komisch aus.

Man muss sich das anders vorstellen als bei ner vektorbasierten True Type Windows-Schriftart wie man sie aus MS Word oder aus seinem Browser oder so kennt... bei so nem TFT-Display werden die Schriftarten als matrixartige Ansammlung von 8-Bit-Werten in den Speicher des Mikrocontrollers geladen, die konkret für bestimmte Bildpunkte einer jeweiligen Ziffer stehen. Sie sind deshalb auch nicht in der Schriftgröße skalierbar so wie True Type-Schriftarten. Und taugt die (oft aus einer Windows-Schriftart erstellte) Matrix nix, dann taugt auch das Schriftbild nix.

Wahrscheinlich werde ich eine Funktion im Programmcode unterbringen, die Zahlenwerte in ihre einzelnen Ziffern zerlegt, und dann für jede Ziffer eine vorgefertigte Bitmap-Grafik von der Speicherkarte lädt, die ich vorher selber mit nem Grafikprogramm erstellt hab. So könnte man gut "saubere" Schrifttypen hinbekommen. Das scheint bei der Arduino-Entwicklungsumgebung die ich verwende etwas kniffliger zu sein als z.B. beim Webdesign mit PHP oder auch JavaScript. Und die Rechenleistung des Atmega328-MCs sollte man bei sowas auch nicht überschätzen. Aber wenns schön aussehen soll...

So, momentan arbeite ich gerade an Lampenkontrollgeräten für den MGF.

Die Idee ist, dass nachher im TFT-Display eine Warnmeldung kommt, wenn eine Glühlampe von Rücklicht, Bremslicht oder Frontscheinwerfern kaputt ist.

Lampenkontrollgeräte gibt es "fertig" unter anderem von Hella, sie wurden verbaut bei VW und Audi. Und ich werde wohl auch so eines benutzen dafür:



Der Vorteil ist, dass man somit "geprüfte" Technik verbaut, und daher halt auch die Betriebssicherheit des Autos nicht gefährdet wird. Diese Lampenkontrollgeräte sind nämlich "invasiv", das heißt, der Laststrom geht direkt durch sie hindurch. Um soetwas wirklich mit eigenen Teilen nachzubauen, müsste man sich schon ein wenig anstrengen damit das betriebssicher ist. Zumal die Frontscheinwefer immerhin 2x55 Watt da durch saugen. Ganz zu schweigen davon, dass es diese LKGs schon for 7 Euro bei eBay gibt... dafür kann ichs nicht selber bauen

Ich werde aber wahrscheinlich noch ein klärendes Gespräch mit dem TÜV suchen, bevor ich das mache. Prinzipiell sollte es, wenn man die Kontrollgeräte ordentlich verkabelt, keinen Nachteil für das Fortbestehen der Betriebserlaubnis geben. Genau genommen erhöht es ja sogar die Verkehrssicherheit, wenn ich weiß, dass mein Rücklicht kaputt ist oder so. Nur eben muss der Einbau dann quasi "nach allen Regeln der Kunst" geschehen, und dafür holt man sich am besten vorher Rat beim TÜV (bis hin zu dem möglichen Rat, es lieber sein zu lassen... )

Kannst Du den Bordcomputer in ein Autoradio integrieren? Das wär supi...

wie soll das denn gehen?

Geplant ist, dass ich ein Exemplar für den Forum-User "jim_knopf123" mache, welches in den Drehzahlmesser integriert wird. Deshalb auch der 1,44''-Bildschirm, er wird genau in die obere Hälfte des DZM passen:



Der Drehzahlmesser besteht aus einer Kunststoff-Folie die auf relativ dünnes Plastik aufgeklebt ist. Die Tachofolie müsste man mit einem guten Federmesser und einem Metall-Lineal sauber ausschneiden können, und das Plastik dahinter sollte sich gut rausdremeln lassen. Hinter dem Drehzahlmesser ist genügend Platz im Kombiinstrument-Gehäuse für den Bildschirm und den Mikrocontroller der das Herzstück des Systems bildet.

Inzwischen habe ich in der Versuchs-Anordnung zuhause auf meinem Schreibtisch den Atmega328P-PU ersetzt durch einen Atmega1284P-PU. Da in der Bordcomputer-Head Unit so viele Informationen zusammen laufen und verarbeitet werden müssen und auch noch optisch aufbereitet werden für das Display, waren die 32KB des 328 einfach zu wenig. Jetzt hab ich 128KB RAM zur Verfügung, und das bedeutet, dass man beim Entwickeln des Programmcodes nicht so knausern muss...