das Feuermodul dann bitte in Verbindung mit einer Löschanlage.
Als reine Anzeige IMHO nur nice to have, denn wenn es von hinten hell und warm wird,
sollte man aussteigen.
http://www.scbvehicledismantlers.co.uk/ ... g-tf/16131

was mir noch so einfiel:
wenn ich mich richtig erinnere, muss bei bei den MEMS bis 1.9 über L-Line ein wake-up getätigt werden,
Kommunikation läuft dann über K-Line. Ab MEMS 2.0 dann alles über K-Line.

hm... man könnte auch nen Feuchtigkeitssensor verbauen, der Wassereinbruch im Motorraum melden kann... wenn man mal wieder im regnerischen britischen Sommer unterwegs ist




So, ich muss jetzt los zu Conrad, neue Kleinteile kaufen für den Bordcomputer


EDIT:



Ja, sowas ähnliches hab ich auch gelesen. Ich glaube das ist dann bei OBDII auch ähnlich, da muss das Steuergerät auch erst mit 12V "gereizt" werden bevor es Daten empfangen und senden kann.

Feuchtigkeitssensor ?
Also der wäre unter dem rechten Teppich wirklich sinnvoll
wobei man es eigentlich schon als Wasserstandsanzeige bezeichnen sollte.

Vielleicht noch ein Relais dran das automatisch die Lenzpumpe einschaltet?

Mal ganz im ernst: durch die modulare Bauweise des Bordcomputers wäre es möglich, irgendwann auch nochmal das System zu erweitern. Man müsste dazu nur weitere Module entwickeln, die dann per I2C-Datenbus an das Head Unit-Modul angeschlossen werden.

Was mir schon seit ein paar Jahren vorschwebt, das wäre dass man das Fach in der Mittelkonsole zu einem Kühlfach aufrüstet, mit Dämmstoff-Ummantelung und einem Peltier-Element und Kühlventilator. So ein Modul könnte dann auch Mikrocontroller-gesteuert sein und selbstständig die Kühlung überwachen... und die gewünschte Nenn-Temperatur könnte man dann über den Bordcomputer einstellen und dann per I2C an das Kühlmodul weitergeben. Im Bordcomputer-Head Unit-Modul würde das nur um die zehn bis zwanzig zusätzliche Code-Zeilen bedeuten.

Aber das ist alles noch in weiter Zukunft. Erstmal wird der Bordcomputer fertig gebaut. Das alleine, mit den jetzt geplanten Funktionen, wird schon bis nächstes Frühjahr dauern. Und dann schauen wir mal, welche Zusatzfunktionen wirklich Sinn machen, von Bluetooth-Anbindung bis hin zu so ner Kühlfach-Steuerung usw.

Ha! Und ich dachte ich bin der Einzige der sich so nen Scheiß überlegt.
Aber die Wärme in der Mittelkonsole ist schon relativ hoch...

also ich hab zuhause im Keller noch ein paar Reste von 12mm Glasfaser-Dämmmatte mit Aluminium-Beschichtung... damit könnte man experimentieren... oder eben man nimmt Heizungsrohr-Dämmschaum.

Damit sich's lohnt, würde ich sagen man vergrößert das Fach dann auch gleich. So dass es quasi unter dem Armlehnen-Scharnier weiter geht. Für zwei Red Bull-Dosen und ne Packung Erdnüsse lohnt es sich nicht, so einen Aufwand zu treiben. Aber in der Mittelkonsole wäre nach hinten raus genug Platz um das Fach fast auf das doppelte des jetzigen Volumens zu vergrößern. Nicht vergessen darf man dabei nen Ablauf für Kondenswasser...

Naja und dann macht mans einfach so, dass die Bordcomputer-Head Unit dem Kühlmodul via I2C sagt "Bitte +2°C halten!"... und den Rest macht die Kühlung dann komplett selbständig. Dafür würde wahrscheinlich ein Attiny85-Controller reichen.

Mal sehen wie ich mit dem Bordcomputer-Projekt vorankomme. Das hat Vorrang. Aber vielleicht werde ich mir irgendwann über den Winter mal ne Mittelkonsole aus nem Schlachtfahrzeug holen um daran ein bisschen zu experimentieren


EDIT: Thorsten ("Jim Knopf 123") hat übrigens auch schon seit ein paar Jahren die gleiche Idee, ne Kühlung in die Mittelkonsole einzubauen...

Ich hätte ja ne Idee was das Schriftbild im Bordcomputer angeht...

Man könnte versuchen, die Schriftart des Tachos zu kopieren und daraus Ziffern zu basteln, die das Display dann als Monochrom-Bitmaps verwenden kann zur Darstellung der ganzen Messwerte.

Hab schon mal versucht, das aus einem Foto eines MkII-Tachos zu isolieren, aber das wird wohl nicht so ohne weiteres klappen... die Ziffern sind farblich viel zu inhomogen und dazu (auch bedingt durch das Smartphone-Objektiv) noch perpektivisch verzerrt in einer Weise, die sich wahrscheinlich nicht mit Entzerrungs-Tools einer Bildbearbeitungs-Software vollständig beheben lässt:



Frage deshalb: Hat von euch wer die Möglichkeit, eine MGF MkII-Tachoscheibe auszubauen und auf nen Scanner zu legen, und mir das als hochauflösende Datei (sollten schon ein paar Megapixel sein) zu schicken?

Für nen Bordcomputer im MkI-Tacho sollte ne simple Windows-Serifen-Schriftart reichen, und nen TF-Tacho hab ich selbst, von dem ich die Tachoscheibe einscannen kann...

Schick mir doch das vollständige Bild des Tacho. Vielleicht spuckt ne Fontanalyse etwas verwertbaren aus.

Sie haben Post

dito.

der Font ist gefunden.

Hier dann mal der welcome screen mit der MG-Schrift:




Was den Einsatz dieser Schriftart für die ganzen Warnmeldungen angeht, bin ich etwas skeptischer...



Da wäre es vielleicht besser, man nimmt eine schnörkellose Schrift (ich hab bei dem zweiten Bild einfach Arial genommen), da diese einfach schneller "erfassbar" ist. Wenn man im Auto unterwegs ist, dann hat man nur immer Sekundenbruchteile um eine Fehlermeldung geistig erfassen zu können, da man sich ja auf die Straße konzentrieren muss. Der Inhalt so einer Meldung muss also sofort in dem Augenblick klar sein wo sie erscheint. Wenn so eine Warnmeldung - begleitet von einem Piepton - im Display erscheint, kann es ne halbe Sekunde länger dauern bis man eine eher "schnörkelige" Schrift entziffert hat. Und diese halbe Sekunde kann schon sicherheitsrelevant sein.

Dies gilt nicht unbedingt dafür, dass man die Nummern-Ziffern nimmt um Zahlenwerte darzustellen. Da bin ich noch am experimentieren. Werden wir sehen...

Hab mich heute abend nochmal mit dem Design des Tachos vom MkII auseinandergesetzt...

Die bisherigen Entwürfe wären wahrscheinlich für den MkII etwas zu altbacken. Im MkI ok, aber der MkII sieht ja im Innenraum an vielen Stellen anders aus, insbesondere am Cockpit. Da sollte man vielleicht das Design ein wenig mehr am recht modern gehaltenen Stil des Tachos anpassen:




Und das würde dann in etwa so aussehen im Tacho:



Und so könnten dann die Warnmeldungen aussehen:

Hier dann nochmal ein aufgehübschter welcome screen für den MGF MkII...



so, nu is aber Feierabend für heute... genug Pixel geschubst...

Schaut doch gut aus ähm den Tacho kenn ich doch das war bei einer Probefahrt
Mfg. Thorsten

Hier nochmal die neuesten Updates des Artworks für den MGF MkII...

Der welcome screen:



Und hier die Header für die einzelnen Untermenüs:



Es wird also Menüs geben für die Motordaten (Öl- und Kühlwassertemperatur, Drehzahl und was mir sonst noch einfällt), für Sprit-Daten (z.B. Momentanverbrauch, Durchschnittsverbrauch, verbrauchte Kraftstoffmenge, restlicher Tankinhalt, Reichweite etc), für Geschwindigkeitsdaten, und für "Settings". Bei "Settings" ist geplant, dass man Sachen einstellen kann wie die Reifengröße (für Geschwindigkeit und Spritverbrauch), die Display-Helligkeit, und die Lautstärke von Warntönen. Und vielleicht noch ein paar andere Sachen. Diese Settings werden dann im EEPROM des Chips gespeichert.

Bis das alles fertig ist, werde ich an dem Code wahrscheinlich alleine schon zwei drei Monate sitzen. Aber ich hatte mir ja als Zielzeitpunkt für die Fertigstellung des Bordcomputers erst den nächsten Sommer gesetzt, also ist noch alles im Zeitplan...

Und hier die Warnmeldungen im Design des MkII im Überblick:



("Check top" und "Frost" sind mir am besten gelungen, wie ich persönlich finde... )

Und hier nochmal ein Update des Layouts der Menü-Screens. Erreichen angezeigte Werte ein kritisches Niveau, dann werden sie rot angezeigt, z.B. wenn weniger als 5 Liter im Tank sind. Gleichzeitig wird dann in der untersten Zeile das betreffende Warnsymbol angezeigt, welches sich dann alle fünf Sekunden abwechseln wird mit der Innen- und Außentemperaturanzeige die dort normalerweise zu sehen ist.




Nochmal vielen Dank an Andreas, der den "heißen Tip" hatte wie die Tacho-Schriftart vom MGF MkII heißt...


Neben dem Code für die Head Unit wird in den nächsten Wochen die Kalibrierung des Motordaten-Messmoduls anstehen. Momentan kann das Motordaten-Modul zwar schon Werte messen und an die Head Unit zur Darstellung weitergeben, aber diese Werte bedeuten noch nichts. Man muss halt genau schauen, bei welchen Temperaturen welche Sensoren welche Widerstände haben usw. Ich werde dafür demnächst mal Thorsten besuchen, und dann werden wir die ganzen Sensoren am MkII mal durchmessen dafür.

Tolle Sache. Super Arbeit. Weiter so.

Momentan hängt's etwas... ich muss eigene Schriftarten-Libraries schreiben, damit die Schriften nachher auch schön abgerundet aussehen. Was es an Schriftarten für das Display bereits fertig gibt, taugt im großen und ganzen nix und sieht sehr pixelig aus, weil es auf Monochrom-Bitmaps basiert. Anders als bei 24-bit gibt es bei 8-bit monochrom keine Möglichkeiten des Anti-Aliasing, da man eben nur ein Byte pro Pixel hat. Das heißt, ein Pixel wird nur entweder "schwarz" oder "weiß" dargestellt, es gibt keine weichen Übergänge.

Hier mal ein Vergleich:




Eigene Software-Libraries schreiben geht schon etwas mehr ans Eingemachte als einfach nur ein bisschen Code zusammenzubacken und "fertige" Libraries einzubinden. Aber was solls... ich finde, der Aufwand lohnt sich. Man kann das ganze auch lassen und die 8-bit-Schriftarten nehmen. Aber das würde bedeuten, dass man sich dann jedes Mal beim Blick auf das Display wieder über die pixeligen Ziffern ärgert und weiß, dass man es hätte besser machen können...

Moment... das muss anders heißen. War schon etwas spät am Abend gestern... Die Farbtiefe (z.B. 24, 16 oder oder 8 bit) ist nicht das vorrangige Problem, man kann auch mit 8-bit "bunte" Bilder malen. Aber wenn man es halt in monochrom macht, dann wird das eine Byte pro Pixel nur für zwei unterschiedliche Farben verwendet, meinetwegen "weiß" oder "schwarz". Man hat dann also sehr harte Übergänge zwischen einzelnen Strukturen eines Bildes. Aber auch wenn man alle verfügbaren Farben bei einer 8-bit-Darstellung verwenden würde, dann würde man lange noch nicht ein so gutes Anti-Aliasing damit erzielen können wie mit höheren Farbtiefen.

Lange Rede, kurzer Sinn: um wirklich schöne und abgerundete Grafiken und Ziffern-Darstellungen zu haben, muss ich eine höhere Farbtiefe nehmen, und mit monochrom wird das nix. Das Display was ich verwende arbeitet mit RGB565, das ist ein 16-bit-Farbmodell. Und damit lassen sich bereits sehr gut "abgerundete" Formen und Ziffern darstellen.