Ich hab neulich zufällig mal ein Foto gemacht wie das 1,8''-TFT-Display in die Umrandung der Mittelkonsole passt (hier mit meiner alten MkI-Mittelkonsole... hab bei mir inzwischen eine aus nem MkII drin):



Ein Display was den gesamten runden Ausschnitt abdecken würde, wäre nicht um Welten größer.

Die Grafiken und Schriften sind in ihrer jetzigen Form eigentlich groß genug, dass man sie als Fahrer mit einem flüchtigen Blick während der Fahrt erfassen kann.

Außerdem muss der Fotowiderstand-Helligkeitssensor auch noch irgendwo untergebracht werden. Wenn das Display den ganzen Ausschnitt abdeckt, dann ist für den kein Platz mehr.

Die Fotowiderstände und das neue Display aus meinem letzten Link kamen übrigens heute morgen bei mir an. Die Fotowiderstände sind tatsächlich nur 3 mm im Durchmesser. Die dafür notwendige Bohrung im Zifferblatt der Öltemp-Anzeige wird also wirklich ziemlich unauffällig sein. Das Display werd ich wohl am Wochenende mal testen, macht auf jeden Fall für das Geld nen guten Eindruck.

Wenn ich das Foto vom Display in der Mittelkonsole sehe frage ich mich, ob die Folie der Öltemperaturanzeige sich so ausschneiden lässt oder in 4 Teile zerfällt.

Die Frage hab ich mir auch schon gestellt. Andererseits, das Zifferblatt der Öltemp-Anzeige in vier Teile zu zerschneiden mit nem anständigen Feder- oder sogar Teppichmesser dürfte einfacher sein als in das ganze Zifferblatt hinein einen rechteckigen Ausschnitt zu machen.

Mir kommen immer die besten Ideen bei sowas, wenn ich etwas tatsächlich direkt in der Hand habe... da hat man oft leichter die wirklich zündende Idee als wenn man es sich nur im Kopf vorstellt. Werde mir also demnächst tatsächlich mal ne Öltemp-Anzeige bei eBay holen.

Habs übrigens geschafft, die SF Fourche für das Display des MkII um einiges enger zu ziehen. Sieht dann so aus (könnte man auch noch enger oder wieder etwas breiter machen):



Man kann mit der Freeware-Software "FontForge" die ich hier gefunden habe dann die Schriftzeichen mit ein bisschen Feintuning so verschmälern, dass sie die exakt gleiche Breite haben wie die News Gothic Condensed. Das würde das Umschalten zwischen MkI und MkII-Modus um einiges vereinfachen, weil dann wirklich ein- und derselbe Mikrocontroller-Code beide Designs steuern kann. Man müsste dem Code nur einmal mit irgendner Variable sagen welches Design momentan aktiv sein soll, und der Rest geht voll automatisch.

Hab die von mir generierte Schriftart mal als ZIP-Datei an diese Mail drangehängt.

So, hab dann mal die erste Schriftart der Schriftarten-Library fertig gemacht.

Findet sich im ZIP-Ordner am Ende dieses Postings.

Das wird dann so laufen, dass es eine Funktion in Mikrocontroller-Code geben wird die ungefähr so aussieht:



Die Funktion könnte dann zum Beispiel so aufgerufen werden:



In dieser Funktion wird dann der Text "Dies ist ein Text" der auf dem Display ausgegeben werden soll in seine einzelnen Schriftzeichen zerlegt, und wenn wir die Schriftart "SF19PtRed" haben wollen (siehe dazu jetzt die Datei aus dem ZIP-Archiv), dann wird für jedes einzelne Schriftzeichen der Reihe nach geguckt, an welcher Stelle im Array const charData_SF19PtRed SF19PtRed[][] das betreffende Schriftzeichen steht. Dort steht dann auch gleich, vieviel Pixel mal wieviel Pixel das Schriftzeichen sein soll. Als nächstes wird dann das dazu passende Array-Element aus dem darüber stehenden Array const uint16_t SF19PtRed[][] herausgesucht, welches schon aus jeweils fix und fertig bereitgehaltenen Pixel-Farbinformationen für die darzustellenden Schriftzeichen besteht, die dann nach und nach Zeichen für Zeichen auf dem Bildschirm ausgegeben werden.

Wie sagte Garth damals...

Nachdem ich die letzten Wochen keine Zeit für das Bordcomputer-Projekt hatte, hier ein kleines Update.

Hab gestern mal die Warnmeldungen für den Tag- und Nachtmodus neu gemacht. Das sind jetzt alles Icons in 128x70 Pixeln. Und sie werden für MGF MkI und MkII dieselben sein, und auch für den TF falls es mal einen Bordcomputer für den TF geben wird (dafür müsste man quasi ein OBDII-Schnittstellen-Modul entwickeln anstatt des Motordaten-Moduls, aber das ist ein anderes Thema).



Die Anzeige wird dann also jedesmal zusammengesetzt aus verschiedenen Icons. Dem Kopf-Icon, dem Textmeldungs-Icon, und dem eigentlichen Piktogramm das zur Warnmeldung gehört. In etwa so wie ich es auf einer der vorigen Seiten gezeigt hab:



(wobei mir halt gerade einfällt, dass ich das "Pause"-Icon bei meinen neuen Icons vergessen hab...)

Im großen und ganzen ist damit alles ein bisschen vereinfacht, da es halt für alle Modellvarianten die gleichen Icons geben wird, nur eben die sonstigen Design-Elemente wie Bildschirm-Kopfzeilen oder Schriften können sich unterscheiden. Außerdem wird es nur noch ein einzelnes Icon geben für alle Meldungen eines möglicherweise angeschlossenen Lampenkontrollgeräts.

Der Hintergrund-Farbton für den Nachtmodus sollte in etwa farblich hinkommen im Vergleich zu der Öltemperaturanzeige bei eingeschaltetem Licht. Im Nachtmodus ist das rot etwas heller, denn nach ersten Tests hier auf dem TFT-Display hebt sich der dunkelrote Farbton in den Tagmodus-Icons nicht sehr gut vom dunkelbraun des Hintergrundes ab.

Ich hab zuerst ein wenig mit cremefarbenen Hintergründen experimentiert für den MkI weil die Instrumente ja nicht rein weiß sind, aber das TFT-Display kann das im Grunde von der Farbtiefe her nicht darstellen. Man müsste da schon ziemlich in Richtung gelb oder rosa gehen bevor man einen Unterschied zu weiß sieht. Und dann sieht es auch schnell kitschig aus. Also hab ich mich entschieden, dass für alle Modelle im Tag-Modus die Hintergrundfarbe rein weiß (Hex-Farbcode #FFFFFF bzw. RGB 255,255,255) ist.

Werde wohl die nächsten Tage wieder ein bisschen anfangen ein paar Sachen zu machen am Programmcode des Display-Moduls. Und dann mal schauen...

Ich kann mir Ehrlich gesagt nicht vorstellen das du da ohnehin irgendetwas siehst sobald das Dach auf ist . Nachts und bei geschlossenem Dach mag ja sein . Aber Sommer und Dach offen und dann noch von der Seite da rauf schauen ? Da seh ich schon am Radio fast garnix und du willst da Warnmedungen an der Stelle einblenden.

Was bedeutet das 9te Symbol? Da kann ich mir gerade keinen Reim drauf machen, außer "Der Nachttopf ist voll"...

Wasserstandswarnung?

Das neunte Symbol ist die Kühlwasserstand-Warnmeldung.

Außerdem wird die Warnung über dem Icon drüber sowieso nochmal in Textform ausgegeben.

Schon richtig, TFT-Displays haben mit hellem Sonnenlicht zu kämpfen was die Erkennbarkeit angeht... ich werde demnächst mal ein paar Tests machen in der prallen Sonne deswegen. Aber normalerweise sollte man im Tag-Modus wenn die Sonne direkt drauf scheint zumindest die Umrisse der Icons noch gut erkennen können. Ausserdem, wenn das Display in der Mittelkonsole sitzt, dann wird es ja noch ein bisschen "zurückgesetzt" liegen und nicht direkt in der prallen Sonne sein so wie meinetwegen das Display von nem Radio.

Hab bei mir im MG auch ein Radio wo ich jedesmal fluche wenn die Sonne drauf scheint. Hab das Kenwood KDC-BT92SD. Klasse Radio, astreiner Klang, randvoll mit Features. Aber hat ein Display in Hochglanzoptik, und da drauf siehst du mit offenem Verdeck manchmal schon an bewölkten Tagen garnix mehr...

Werd da wohl kommende Saison mal irgendwie so ne Antireflex-Folie draufkleben oder so.

Oben links das erste Symbol ist übrigens ne Warnmeldung für einen Lesefehler vom Motordaten-Modul. Wenn aus welchen Gründen auch immer kein Datenleitungs-Kontakt besteht zwischen Motordaten-Modul und Display-Modul. Am Motordaten-Modul wird es am Gehäuse ausserdem eine kleine Kontroll-LED geben. Die wird im Betrieb dauerhaft an sein, und wird jedesmal kurz für ein paar Millisekunden ausgeschaltet wenn das Motordaten-Modul Daten ans Display-Modul sendet. Was für Abfrage-Intervalle für die Motordaten sinnvoll sind, weiss ich noch nicht. Ich denke, einmal pro Sekunde wird reichen.

Hätte ich drauf kommen können. Spiegel die Außenlinie noch nach oben, dann hats schon fast perfekt die Form vom Kühlwasserbehälter.

Das hatte ich auch schon mal versucht, aber die Bedeutung des Piktogramms ist tatsächlich besser durch nen flüchtigen Blick erfassbar wenn quasi nur die untere Hälfte zu sehen ist.

Außerdem können diese Piktogramme halt nur so um die 128x70 Pixel groß sein damit das Bildschirm-Layout so klappt wie ich es mir vorstelle, und ein kompletter Kühlwasserbehälter als Piktogramm wäre dann nen Tick kleiner und dann vielleicht auch schwieriger mit nem "Sekunden-Blick" erfassbar.

Ist halt ein Grenzfall. Solche Piktogramme müssen quasi von der Gestaltung her so eindeutig sein, dass jeder sofort begreift was gemeint ist. Das hast du ja auch bei den ganzen Arbeitsschutz-Gebotszeichen in Fabriken und so. https://de.wikipedia.org/wiki/Gebotszeichen

Aber in ner Fabrikhalle hast du zur Not fünf Sekunden Zeit um ein Piktogramm zu verstehen, und im Auto weniger als ne Sekunde. Und wie gesagt, das ganze wird ja zusätzlich als Textmeldung rausgegeben.

Weiss nicht ob ich schon mal gefragt hab... was die Batteriespannungs-Warnung angeht: was ist ein sinnvoller Schwellenwert um deswegen zu warnen... 10 Volt? 11 Volt?

Dipl. Ing. Wikipedia sagt dazu:

>12,8 V = voll geladen
ca. 12,6 V = normal geladen (70 %)
ca. 12,4 V = schwach geladen (50 %)
ca. 12 V = normal entladen (20 %)
<11,8 V = ent- und tiefentladen (0 %)

… vorausgesetzt die Zellen sind alle intakt und die Spannung bricht unter Last (Startermotor) nicht ein.

Diese ganzen Füllstands-Fehlermeldungen (Benzin, Wischwasser, Kühlwasser) sind eh so programmiert, dass mehrmals hintereinander geprüft wird in Abstand von mehreren Sekunden. Und das gilt auch für die Batterie. Ich glaube, ich hab im Code "dreimal prüfen" eingegeben bevor dafür jeweils ne Warnmeldung rausgegeben wird. Und es wird auch nur ne Fehlermeldung ausgegeben wenn direkt dreimal hintereinander ein Sensor anschlägt. Sonst wird der Zähler wieder auf null gesetzt. Damit sollte man eigentlich alle "Wackler" die so ein Sensor haben kann rausfiltern können.

Ich arbeite gerade daran, schon mal die Mehrsprachigkeit des Bordcomputers vorzubereiten. Richtig zu programmieren habe ich momentan noch keine Lust, also gibt's erstmal ein bisschen "Kleinarbeit".

Das sieht dann im Code zum Beispiel so aus für die Warnmeldungen:



Wir haben dann also quasi ganz einfach eine Tabelle, wo hintereinander weg für jede Fehlermeldung der passende Text steht der mit der Warnmeldung auf den Bildschirm ausgegeben wird.

So oder so ähnlich werden dann auch die ganzen anderen Sprach-Tabellen für den Bordcomputer aussehen. Je nachdem welche Sprache in den Einstellungen/Settings aktiviert wurde, wird dann halt immer der passende Begriff aus der Tabelle herausgefischt und als Text auf dem Display dargestellt. Die deutschen Begriffe sind immer besonders lang, aber eine zweizeilige Darstellung wird am Ende kein Problem sein. Ich arbeite gerade an einer Funktion, die beliebigen Text mit passendem Zeilenumbruch auf dem Bildschirm ausgeben kann, und dazu noch je nach Wunsch zentriert oder links- oder rechtsbündig. Und zwar in den Spezial-Schriftarten, die ich für die Darstellung erstellt habe.

Fürs erste dachte ich erstmal an die drei europäischen Hauptsprachen Englisch, Deutsch und Französisch. Wobei meine Französisch-Kenntnisse ziemlich mies und sehr eingerostet sind. Falls von euch wer ganz gute Französischkenntnisse hat, der kann mir da gern ein bisschen helfen... Wahrscheinlich kommt dann noch Spanisch dazu. Das kann ich inzwischen selber ganz gut

Kurze Bitte mal an die Leute hier mit nem MGF MkII... könnte mal jemand schnell mit nem Smartphone ein Bild machen von der Uhr in der Mittelkonsole?

Ich wollte heute mal die Grafiken machen für den Analoguhr-Bildschirm vom MkII, das soll ja quasi das Design der Uhr imitieren, so wie hier beim MkI:



Und der Zifferblatt-Hintergrund von der MkII-Uhr soll halt entsprechend genauso dem "realen" MkII-Zifferblatt ähneln.

Danke

"mailbox unavailable"

sorry & gruss kai

Kurzes Update mal:

Momentan habe ich null Zeit für das Projekt, außerdem "hängts" an ein paar Dingen wo ich nicht weiter komme.

Eigene Schriftarten-Libraries zu generieren für dieses Projekt bereitet mir immer noch Kopfzerbrechen. Hab ich noch nie gemacht sowas, und da geht's ziemlich ans Eingemachte mit Arrays, Array-Pointern usw. usf. in C-Code. Anders als insbesondere manche web-orientierte Programmier- und Skriptsprachen ist C sehr penibel, was Variablentypen angeht. Verstößt man gegen die sehr starren Regeln des Compilers, dann gibts jede Menge Compile-Errors.

Das Problem ist halt, ich will meine Schriftarten in 16-bit Vollfarbe. Ansonsten gibts komplett fertige Libraries zuhauf mit Buchstaben und Zahlen in 8-bit monochrom, aber die sehen auf nem Display ausnahmslos sch... aus, weil sie eben nicht anti-aliased sind. Also führt kein Weg vorbei an Schriftarten in 16-Bit-Farbe.

Ein weiteres Problem ist die Sache mit den Sounds. Das ESP32-Modul ist noch ziemlich neu auf dem Markt, und obwohl es die Wiedergabe von Sound unterstützt, und das sogar in 16-Bit Stereo wenn man denn unbedingt will, gibt es so gut wie keine Dokumentation bisher, wie man das praktisch anstellt. Ich hab schon in ein paar Foren Fragen dazu gestellt, aber bisher konnte mir niemand ein Code-Beispiel zeigen das wirklich auf meinen Zweck zugeschnitten gewesen wäre.

Vielleicht werd ich in ein paar Wochen dazu kommen, das Projekt weiter voranzutreiben. In der Zwischenzeit werd ich auch immer mal wieder schauen, ob es Möglichkeiten gibt, diese beiden Probleme zu lösen. Aber momentan tut sich bei dem Bordcomputer-Projekt erst einmal nichts.

Hatte jetzt wider Erwarten doch mal ein bisschen Zeit am Wochenende um mich dem Thema "Schriftarten-Darstellung" und Audio-Wiedergabe zu widmen.

Meine Schriftarten-Library ist jetzt in Grundzügen fertig, es sind nur noch nicht alle Schriftarten erstellt. Aber Text darstellen kann ich damit schon auf dem Bildschirm.

Außerdem bin ich auf eine Library gestoßen, mit der man Sound auf das ESP32 direkt als MP3 hochladen und dann wiedergeben kann. Das verkleinert natürlich den Speicherplatzbedarf der Soundfiles beträchtlich. Da kann man sogar mit 64 kbps (mono) arbeiten. Selbst ein 12 Sekunden langes Sample (siehe Beispiel-Datei unter diesem Posting ) in sehr guter Qualität hätte nur 100 Kilobyte. Momentan kommt es noch extrem verzerrt aus dem Lautsprecher (denke mal ist noch ein Treiber-Problem), werd wohl noch ein paar Feineinstellungen machen müssen. Aber rein prinzipiell funktioniert das wohl.

Eine Einschaltanimation wird es auch geben. Dazu werden die Einzelbilder als jpegs im Flash-Speicher abgelegt und dann der Reihe nach abgerufen und auf dem Bildschirm dargestellt. Wird dann in etwa so aussehen, oben Tag-Design, unten Nacht-Design:






Hab mir vor ewigen Zeiten mal Flash MX gekauft für Webseiten-Animationen, damals als das in Mode war... das hab ich vor ner Weile wieder bei mir auf den Rechner gemacht... damit hab ich die Animationen gemacht. Für solche Zwecke immer noch ganz praktisch.

Da wir ja nen Fotowiderstand an dem Ding dran haben der immer nebenher die Umgebungshelligkeit misst, kann somit also passend zu den Lichtverhältnissen die Tag- oder Nacht-Einschlaf... äh Einschaltanimation gezeigt werden.

Jetzt wo die Sache mit den Schriften-Libraries größtenteils geklärt ist und ich ne Idee hab wie man die Audio-Ausgabe umsetzen kann, könnte sich das Entwicklungstempo wieder etwas beschleunigen. Der nächste Schritt wird sein die Anzeige-Bildschirme zu layouten, dazu muss man halt die einzelnen Icons und angezeigten Werte so lange auf dem Bildschirm Pixel für Pixel hin- und herschieben bis es stimmig aussieht... also Pixelschubserei im besten Sinne... . Steht das Layout, dann kann man sich Gedanken machen, wie man die Navigation gestaltet zwischen den einzelnen Menüs. Und so weiter dann...

Wenn's wieder wärmer wird, dann werde ich auch wieder Tests machen mit dem Motordaten-Modul. Da kommt ja noch einiges an Arbeit auf mich zu bei der Feinjustierung der gemessenen Werte und so... ich sag nur, Stichwort reale Einspritzmenge und realer Verbrauch und so...

So, unten angehängt an dieses Posting findet ihr wie gesagt mein "Test-Sample" mit dem ich gerade die Audio-Funktion teste... eins meiner absoluten Lieblingslieder übrigens zum MG-Fahren...

Nachdem das Projekt jetzt wieder eine Weile auf Eis lag (hatte einfach nicht die Zeit und den Kopf frei dafür), hab ich jetzt wieder mit ein paar Sachen angefangen um alles wieder ein bisschen voranzutreiben.

Momentan sitze ich daran, eine Funktion zu coden in C, mit der ich Text auf den TFT-Bildschirm bringen kann mit meinen eigens erstellten Schriftarten-Libraries.

Die Funktion sieht in etwa so aus:



Dies ist quasi DIE zentrale Funktion, mit der der Bildschirm mit Daten gefüllt wird. Sie wird alles von Text bis Messwerte mit und ohne Kommastellen anzeigen.

Wie man an den Funktions-Argumenten sehen kann, kann diese Funktion verschiedene Schriftarten benutzen, links- und rechtsbündigen und zentrierten Text darstellen, man kann einen Abstand zum Bildschirmrand wählen, die y-Startposition des Textes auf dem Bildschirm, den Abstand zwischen einzelnen Zeichen, und man kann definieren, wieviel Pixel ein Leerzeichen breit sein soll.

Ist noch nicht fertig, hat noch ein paar Bugs bei der Darstellung von rechtsbündigem und zentriertem Text.

Anderes Thema ist die Stromversorgung des Display-Moduls. Da wir ja in dem ESP32-Mikrocontroller aus dem das Anzeige-Modul besteht eine Echtzeituhr haben, wäre die Überlegung, dass man das so macht, dass man die Uhr möglichst selten neu einstellen muss.

Alle Messdaten an sich werden ja in den Speicher geschrieben wenn der Motor ausgemacht wird, und die bleiben somit erhalten egal ob der Bordcomputer Saft hat oder nicht. Außerdem hängt der Bordcomputer an Dauer-Plus von der Batterie, wird also im Normalfall immer eine Stromversorgung haben.

Aber damit die gegenwärtige Zeit auch weiter gezählt wird wenn die Autobatterie mal abgeklemmt ist, könnte man eine 3-Volt-Knopfzelle mit auf die Platine machen. Im Deep Sleep-Modus (d.h. wenn alle anderen Funktionen ausgeschaltet sind und nur noch im Inneren des Prozessors die Echtzeituhr weiter raufgezählt wird) zieht das ESP32-Modul laut Datenblatt 10 uA. Eine CR2477-Knopfzelle mit 950 mAh würde somit über zehn Jahre den Bordcomputer im Tiefschlaf mit Strom versorgen können...

Wohlgemerkt im Tiefschlaf, also würden wirklich nur Datum und Zeit weiter gezählt, als UNIX-Timestamp. Wahrscheinlich reicht eine sehr viel kleinere Batterie, da man ja wohl nicht in die Verlegenheit kommen wird, dass der Wagen jahrelang am Stück von der Batterie abgeklemmt sein wird. Um die Batterie aber doch mal wechseln zu können, kann man sie ja so im Gehäuse des Bordcomputers platzieren, dass sie getauscht werden kann, ohne dass man gleich die ganze Mittelkonsole ausbauen muss. Wenn man beim F/TF die Lüftungsdüsen in der Mittelkonsole raushebelt, kommt man ja gut von hinten an die Uhr und Öltemp-Anzeige dran, also könnte man die Knopfzelle so im Bordcomputer-Gehäuse platzieren (welches ja dann an der Stelle der Analoguhr sitzen wird), dass man dort von oben durch die Lüftung dran kommt.

Bin nur am grübeln, wie man so eine Knopfzelle beschaltet. Falls da jemand etwas mehr Ahnung von euch hat, sagt mal bescheid. Sie darf ja nicht direkt an den 3,3V anliegen, die das Modul "im Normalbetrieb" vom Spannungsregler her bekommt. Aber sie muss trotzdem den Vcc-Pin des Mikrocontrollers direkt und ohne Unterbrechung mit ihren 3V versorgen können, wenn vom Spannungsregler kein Saft mehr kommt, also wenn die Autobatterie abgeklemmt ist. Einfach eine Sperrdiode zwischen schalten geht nicht, denn das ESP32 braucht als absolutes Minimum 2,7V und ne Sperrdiode verringert die Spannung ja immer so ca. um 0,6-0,7V.

EDIT:

So könnte wohl eine Backup-Stromversorgung aussehen, bei der die Knopfzelle augeblicklich einspringt wenn die 3,3V von der Autobatterie wegfallen:



Hier wird genau das Thema diskutiert:

https://electronics.stackexchange.com/questions/244335/implementing-a-low-cost-battery-backup-circuit-for-internal-rtc-in-stm32f030r8