Ha! Da kennt noch jemand Music Instructor...

Also, das beste wäre, um Speicherplatz zu sparen, dass man den Gong (der ja immer derselbe ist) in eine einzelne Datei macht, und dann die Sprachmeldungen jeweils einzeln. Wie sich leider inzwischen herausgestellt hat, haben die ESP32-Boards aus China nicht 16 MB Flash-Speicher on-board, sondern nur 4 MB. 16 MB ist das Maximum was an Onboard-Speicher unterstützt wird durch den ESP32-Chip, aber wirklich zu kaufen bekommt man eigentlich nur die 4 MB-Version, auch wenn in den Beschreibungen bei eBay 16 MB steht. Ich hab es bei meinem ESP32 nachgeprüft mit ner Speicher-Check-Software, und hab tatsächlich nur 4 MB angezeigt bekommen. Das ist immer noch eine Menge Speicher und reicht für den Bordcomputer voll aus, aber andererseits heißt es auch, dass man an Speicherplatz nix zu verschenken hat.

Könnte man vielleicht irgendwann nebenher mal implementieren. Hat noch Zeit. Insgesamt sind momentan 13 verschiedene Warnungen vorgesehen:



(bei dem "low fuel"-Icon bin ich einfach noch nicht sicher, ob die Zapfsäule in weiss oder dunkelgrau besser aussieht)

Überschlagsmässig würden alle Sprach-Warnmeldungen zusammen als 16 kHz-8 bit (das ist auch die Qualitätsstufe der Datei in dem Zip-Ordner in meinem vorigen Posting) um die 470 KB belegen.

Momentan wird erstmal bei der Programmierung das Hauptaugenmerk darauf liegen, dass die einzelnen Daten richtig angezeigt werden. Ich werde als nächstes den Code entwickeln dafür, dass man zwischen einzelnen Untermenüs mit den Bedienknöpfen hin und her schalten kann. Bislang hatte ich nur eine "Test-Menü-Seite", und hieraus werden dann halt jetzt die einzelnen Menüseiten entstehen. Wenn das einigermaßen läuft, werd ich auf die Warn-Anzeigen zurück kommen.

Damit werde ich in etwa bis Ende März/Anfang April zu tun haben, und dann wenns wieder wärmer wird, widme ich mich wieder dem Motordaten-Modul. Dort stehen dann so Sachen an wie Korrekturfaktor ermitteln für die Einspritzmenge und Kalibrieren der Kühlwasser- und Öltemperatursensoren.

Ebenfalls wenn es wieder wärmer wird, werde ich die Wischwasserpumpe von Audi mit dem Füllstand-Warnkontakt in meinem Wagen einbauen und den Kühlwasser-Ausgleichsbehälter vom TF mit Warnkontakt, sowie die Temperaturfühler für innen und außen. Und dann fällt auch die endgültige Entscheidung, ob ich Lampenkontrollgeräte einbaue oder nicht.

Sollte ich mich am Ende gegen Lampenkontrollgeräte entscheiden, dann wird das auch Auswirkungen auf die Bauweise der Module des Bordcomputers haben. Dann wird das "Komfort-Modul" wahrscheinlich wegfallen (was bislang Lampenkontrollgeräte, Innen- und Außentemperatur und Wischwasser überwachen soll), und die Funktionen die es ausführen sollte werden vom Display-Modul mit übernommen. Das ESP32 hat so oder so noch jede Menge freie Input-Pins die momentan ungenutzt bleiben. Das würde dann zwar ein paar mehr Kabel bedeuten die zum Display-Modul hin verlegt werden müssen, aber es macht einen Nachbau auch nochmal etwas einfacher, weil dann das gesamte System nur noch aus Motordaten-Modul und Display-Modul besteht. Aber wir werden sehen...




Richtig... auch wieder wahr. Naja, ich meinte auch eher, eine Stimme die klar als "native speaker" erkennbar ist. Aus meiner Sicht würde das im übrigen die user experience bereichern... aber naja. Wenn es sich zwischendurch mal ergibt, dann könnte man mal versuchen wie das ganze wirkt mit Sprachmeldungen. Momentan liegt das Hauptaugenmerk wie gesagt darauf, die einzelnen Untermenüs zu programmieren. Denn das ist ja quasi immer noch die "Kernfunktion" des Bordcomputers.

Am Ende könnte man in den "Einstellungen" des Bordcomputers halt auch ne Option machen wie Warntöne ausgegeben werden... nur der "Gong", oder mit Sprache, oder wie auch immer.

Während ich hier noch auf ein neues ESP32-Board warte (mein altes hab ich wohl gekillt als ich versehentlich 12V direkt auf nen Pin gelegt hab bei dem Versuch eine Verstärker-Schaltung zu bauen ), kann ich die Zeit übrigens erstmal mit ein bisschen "Sissyphus-Arbeit" überbrücken.

Und die wird darin bestehen, die ganzen Schriften zu erstellen, die das Display nachher zur Darstellung der Anzeigewerte braucht.

Anders als bei Windows-Schriftarten auf einem PC, die im Grunde in der Datei drin nur aus Vektorgrafik-Informationen bestehen, aus denen dann Word oder PowerPoint etc. frei skalierbare und frei einfärbbare Buchstaben und Ziffern errechnen kann, ist es beim ESP32 und auch bei anderen solchen Systemen etwas komplizierter (unter anderem, weil ganz einfach der Arbeitsspeicher nicht ausreicht).

Es müssen quasi für jede Schriftart die Buchstaben und Ziffern einzeln als Bitmaps, jeweils in der gewünschten Größe und Farbe, im Speicher hinterlegt werden. Das bedeutet, man muss wirklich mit einem Grafikprogramm jedes einzelne Zeichen das man haben möchte erstellen und als Bilddatei abspeichern.

Da das ESP32 über ordentlich Speicherplatz verfügt, sind darauf selbst aufwändig schattierte und anti-aliaste Schriftzeichen kein Problem. Mit einer Farbtiefe von 16 Bit pro Pixel, das entspricht 65.536 verschiedenen möglichen Farben, hat ein einzelner Zeichensatz der Zahlen von 0 bis 9 in etwa, je nach Schriftgröße, eine Gesamtgröße von 3 bis 6 Kilobyte. Wohlgemerkt, insgesamt Platz sind auf dem ESP32 immerhin 4 Megabyte. Man kann sich also auf dem Ding mit verschiedenen Schriftarten austoben, wie man Lust hat.

Der Nachteil ist halt, dass es sehr langwierig ist... Denn man muss dies wie gesagt für jede einzelne gewünschte Schriftart, -größe und -farbe wiederholen.

Ich hab bereits damit angefangen, und so sieht das dann quasi bei mir auf dem Rechner erstmal aus:



Da ich aber ohne diese ganzen Ziffern kein Menü darstellen kann, muss ich da halt eben durch. Ich muss die Schriftarten in mehreren Größen in rot und schwarz sowie im Tag- und Nachtmodus erstellen. Da auf dem ESP32 so viel Platz ist, kann ich im Quellcode sowohl die kompletten Zeichensätze für den MkI als auch für den MkII oder sogar noch für den TF abspeichern. Am Ende könnte man es dann wirklich so machen, dass in den Menü-Einstellungen komplett von einem Layout ins andere gewechselt werden kann. Dadurch wird wiederum der Nachbau des Bordcomputers einfacher, weil man für alle Varianten den komplett gleichen Quellcode nehmen kann.

Nur eben wird das ne Weile dauern, das alles zu erstellen... Der einzige Trost ist, dass man sowas dann später mal zu ner universell einsetzbaren Schriften-Library zusammenfassen und anderen Entwicklern zur Verfügung stellen kann, damit die sich drüber freuen...

So, ein letztes Posting nochmal... die nächsten Tage wird wieder etwas "Ruhe" sein...

Gestern kam das neue Display. Macht einen sehr guten Eindruck. Schön kontrastreich. Leider merkt man besonders im Nachtmodus dass die Farben nicht komplett "blickwinkel-stabil" sind, aber man kann nicht alles haben. Aus der gewöhnlichen Sitzposition heraus von der man auf das Display in der Mittelkonsole schauen wird, hat man jedenfalls recht satte Farben.



Bei diesen Displays ist es immer schwierig mit dem Abfotografieren... leider sehen Fotos von so nem Display in Aktion meistens nicht mal halb so gut aus wie in natura. So wie ich jetzt hier drauf gucke sieht's echt super aus

Zum Testen hab ich die Grafiken aufgespielt auf den Chip den ich eigentlich jetzt nicht mehr verwenden wollte fürs Display weil er zu schwachbrüstig ist, aber hab ja immer noch keinen Ersatz für meinen zerbratenen ESP32-Chip...

Hab an dieses Posting mal eine Videodatei in nem ZIP-Ordner drangehängt, in der man die Refresh-Rate des Displays sehen kann. Dies ist wohlgemerkt mit einem 8-Bit-Mikrocontroller mit 16 MHz Taktfrequenz. Wenn ich das gleiche mit dem ESP32 mache der 32 Bit und 240 MHz Taktfrequenz hat, dann dürfte die Refresh-Rate mit dem Auge nicht mehr wahrnehmbar sein. Refresh-Rate heißt, wie lange dauert es, bis ein komplett neuer Bildschirm aufgebaut ist (natürlich wird im laufenden Betrieb ein- und derselbe Bildschirm nicht ständig neu aufgebaut... die Refresh-Rate ist vor allem von Bedeutung, wenn es um Menü-Wechsel und das Einblenden von Warnmeldungen im laufenden Betrieb geht). Die Grafiken in dem Beispiel im Video werden direkt aus dem Flash-Speicher geladen, das ist die schnellste Methode die es gibt. Beim Bearbeiten des Videos konnte ich eine Refresh-Rate von knapp 200 Millisekunden für den kompletten Bildschirm feststellen. Das ist sehr gut. Beim ESP32 wie gesagt erwarte ich mit dem Auge nicht wahrnehmbare Refresh-Raten.

Wenn die Programmierung des Displays weiter fortschreitet und es vermehrt Dinge zu sehen gibt die man besser mit nem Video zeigen kann, dann werde ich vielleicht mal nen kleinen Youtube-Channel einrichten dazu. Mal schauen.

Mal ehrlich , Sprachausgabe in Englisch oder Deutsch oder Esperanto ? Warntöne in CD Qualität ?? wie fahrt ihr bitteschön Auto ?
Wenn ich mit meinen F den Thüringer Wald hochfahre dann würde ich werde eine Ansage noch ein Warnton verstehen, weil da hinter mir ein Orchester in FFF Fortissimo Possibile spielt und kein Warnton der Welt meine Aufmerksamkeit erlangen würde . Einzig wenn irgendwo ein Lämpchen angehen würde wäre für mich "Hab Acht " angesagt.

Manchmal steht man halt auch mit geschlossenem Verdeck im Stadtverkehr an der Ampel wenn der Benzintank fast leer ist

"CD-Qualität" ist ja nur die maximal technisch erzielbare Klangqualität. Wenn du daran einen 28mm-Kalotten-Lautsprecher anschließt, so wie ich es vorhabe, dann wird der Bordcomputer damit natürlich nicht zu einem Bang & Olufsen-Soundsystem. Das ist klar. Aber das ist ja auch nicht das Entwicklungsziel.

Aus Platzgründen werden Audio-Files, so sie denn zum Einsatz kommen, wahrscheinlich als 16 kHz-8 bit auf dem Chip gespeichert werden. Das reicht dann bei so nem kleinen Lautsprecher auch aus für verständliche Sprachwiedergabe ("echte" CD-Qualität wäre 44,1 kHz-16 bit, aber das produziert riesige Dateien).

Und Sprachmeldungen wären ganz einfach technisch gesehen sehr einfach zu implementieren.

Aber mal schauen. Die nächste Zeit muss erstmal die Menü-Steuerung programmiert werden. Und da kann man dann nebenbei immer nochmal ausprobieren, wie das ganze mit Sprachmeldungen wirkt.


Hab bei dem SainSmart-Display was ich in meinem letzten Posting gezeigt hab übrigens festgestellt, dass es nicht dimmbar ist. Das ist ein sehr großes Manko, denn es ist standardmässig sehr lichtstark, und besonders nachts würde das wahrscheinlich selbst im Nacht-Modus blenden. Bin gerade am schauen im Internet, ob es dimmbare Displays gibt mit einer ähnlich kleinen Platine.

Sowas hier zum Beispiel... Klick mich... hat keinen SD-Karten-Steckplatz, brauchen wir aber auch nicht. Aber hat dafür einen praktischen Stecker-Anschluss. Und die links und rechts überstehenden Kanten der Träger-Platine könnte man wegdremeln, weil da wohl keine lebenswichtigen Leiterbahnen drauf entlang laufen. 13 Euro ist ok für sowas.

Wie geschlossen ? Seit wann darf man mit geschlossenen Verdeck fahren ? in meinen Papieren steht Personenkraftwagen offen

also unter 20 Grad fahr ich nicht offen. Ist mir etwas zu kalt. Verstehe auch die Leute nicht, die Anfang März bei zehn Grad mit dicker Mütze und Schal offen fahren, nur weil zwischendurch mal zwei Stunden die Sonne scheint...

Ein Grund mehr, ne Außentemperaturanzeige im Bordcomputer zu haben...

Hab mich übrigens jetzt entschlossen, dass das separate Komfortmodul weg kommt, welches ja die Lampenkontrollgeräte überwachen sollte sowie den Wischwasser-Kontakt und die Innen- und Außentemperatur. Sofern es vordere und hintere Lampenkontrollgeräte geben wird, werden sie über noch freie Pins am Motordaten-Modul und Display-Modul überwacht. Und die Innen- und Außentemperatur und der Wischwasser-Sensor werden ans Display-Modul angeschlossen.

Das spart eine komplette Schaltung die nicht gebaut werden muss und somit ca. 15-20 € Teilekosten, und macht das System als ganzes ein wenig einfacher.

Da übrigens die Lampenkontrollgeräte ja nur anschlagen wenn wirklich eine Lampe kaputt ist (im Ruhezustand ist an den Signal-Pins der Lampenkontrollgeräte 0V, bei kaputtem Lämpchen +12V), kann man sie auch ohne Probleme weglassen, wenn man denn mag. Das gleiche gilt im Grunde für den Wischwasser-Sensor. Da wird auch einfach ein Kontakt auf Masse gelegt wenn das Wischwasser niedrig ist.

Hier noch ein "Schmankerl" für ne (mögliche) Warnmeldung, die wahrscheinlich wieder geteiltes Echo auslösen wird...



Bei vielen modernen Bordcomputern (auch beim FIS von meinem 99er Audi) wird man nach zwei Studen durchgehender Fahrt daran erinnert, dass man mal ne Pause machen sollte... nicht lebensnotwendig, aber wenn man schon im Programmcode eine Echtzeit-Uhr mitlaufen lässt, kann man sie auch für sowas nutzen...

Pause gefällt mir, da brauche ich keinen Raucher, der nervös wird als Quasi-Anzeige im Korso

Aber wenn schon, dann TEE bitte

Wenn der dow WLAN-kann, kann der dann nicht mit allen anderen im Umkreis ein Mesh aufbauen?

In der Kolonne merke ich hinten dann, dass der vorne den Blinker gesetzt hat und so.

Das wär mal ein cooles feature.

gruss kai

Apropos Sound-Datei, ich kann da gerne einen meiner Kollegen fragen, die aufzusprechen. Wenn ulaw reicht (ISDN-Telefon), dann geht das quasi ad hoc.

Möglich sind sicherlich britischer Aktzent, aber auch Boston, Texas, Chinese.

gruss kai

Das mit den Sound-Dateien hat wirklich noch Zeit. Ich muss erstmal sehen, wieviel Platz der Programmcode wirklich beanspruchen wird, mit allen Zeichensätzen und sonstigen Grafiken und so.

Der beste Kompromiss zwischen Dateigröße und Klangqualität scheint 16-kHz 8-bit .wav zu sein. Das sind knapp 16 Kilobyte pro Sekunde. 8 kHz-8 bit ist schon etwas wenig. Hab mal zwei Audio-Dateien in nem Zip-Archiv an dieses Posting drangehängt. Am besten mal auf guten Lautsprechern anhören, dann merkt man den Unterschied.

Bei 12 Sprach-Warnmeldungen à 2 Sekunden sind wir bei 16 kHz bei um die 400 kB. Will man dann das ganze auch nochmal in Deutsch haben, dann sinds halt nochmal 400 kB. Die Warnmeldungs-Icons kommen zusammen auf 600 kB, die Zeichensätze wohl auf 200-300 kB. Das sind schon an die 1,7 MB. Der eigentliche Programmcode wird m.W. im SRAM (512 kB) ausgeführt und nicht in Flash... also ist der außen vor.

Aber wir behalten das mal im Hinterkopf. Wenn ich mit der eigentlichen Menü-Steuerung und den Grafiken und Zeichensätzen aus dem gröbsten raus bin, so Mitte März oder so, dann geb ich dir deswegen mal definitiv bescheid.

Aus Audacity heraus lassen sich übrigens Mikrofon-Aufnahmen zum Beispiel direkt in diesem Format speichern.

Was WLAN angeht... das ESP32-Modul kann sich als WLAN-Client in ein bestehendes WLAN anmelden wenn WLAN-Name und Passwort bekannt sind. Als WLAN-Server kann es aber nur mit zusätzlicher Hardware fungieren. Es gibt dazu spezielle Module die man anschließen kann, aber da ist halt die Frage wiederum, was bringts...

EDIT:

Hab mir mal ein wenig die Dokumentation zum ESP32 durchgelesen, das Kapitel Speicherplatz und so...

Hier der Link zum Download:

http://espressif.com/sites/default/file ... eet_en.pdf

So wie ich es sehe, stehen tatsächlich 520 (!) kB separat für den eigentlichen Programm-Quellcode zur Verfügung. Und dann hat das Ding halt eben noch weitere 4 MB Flash.

Das Ablegen im Flash-Speicher funktioniert dann so, dass solche Daten wie Icons und Zeichensätze und so in Arrays im Quellcode gespeichert werden, und diese Arrays bekommen dann das Attribut PROGMEM in der Variablen-Definition zugewiesen.

Zum Beispiel:



Durch das Attribut PROGMEM weiß dann der Compiler, dass die Daten nicht im SRAM sondern im Flash-Speicher abgelegt werden sollen.

Und dort stehen halt 4 MB zur Verfügung. Das sollte also eigentlich dicke ausreichen für alles was man mit dem Bordcomputer so anstellen möchte...

Während die eigentliche Programmierung des Display-Moduls wohl diese Woche erstmal "auf Eis" liegen wird, habe ich jetzt noch zwei Komponenten für das Display-Modul bestellt:

Das hier wird das endgültige Display werden:

https://www.ebay.de/itm/1-8-inch-SPI-TF ... 2379375750

Ein kostengünstiges, aber dabei nicht schlechtes Display. Mit relativ kleinen Abmessungen der Trägerplatine, was wichtig ist damit das ganze auch in ein Öltemperaturanzeigen-Gehäuse passt. Trotzdem wird man wohl an der einen Seite den überstehenden Teil der Platine wegdremeln müssen. Dort liegen eh nur die Anschlüsse für den SD-Karten-Steckplatz, und eine SD-Karte brauchen wir eh nicht bei diesem Projekt, da ja alle Grafiken direkt aus dem Flash-Speicher des ESP32 geladen werden.

Direkt aus China sind diese Displays (mit zwei drei Wochen Lieferzeit) sogar für 5 Euro zu haben.

Und dann hab ich auch noch nen Schwung Fotowiderstände bestellt:

http://www.ebay.de/itm/321271252789

Ich hab glaub ich auf einer der vorigen Seiten in diesem Thread geschrieben, dass die Unterscheidung zwischen Tag- und Nachtmodus des Displays nicht nur aufgrund des Lichtschalters passieren soll (dafür wird einfach das Beleuchtungs-Kabel der Mittelkonsoleninstrumente angezapft), sondern auch danach, ob es wirklich dunkel ist.

Ich fahre mit meinem MG fast ausnahmslos immer mit Licht an, auch tagsüber bei hellstem Sonnenlicht. Werden die meisten hier wohl auch so machen. Im Nacht-Modus ist aber die Display-Hintergrundfarbe dunkelbraun und die Ziffern bernsteinfarben, um das Erscheinungsbild der daneben liegenden Öltemperaturanzeige nachzuahmen. Fahre ich aber bei Tageslicht mit Licht an, dann hätte ich somit ein dunkelbraunes Bordcomputer-Display und rechts daneben ein weißes bzw. beim TF silbernes Ziffernblatt der Öltemp-Anzeige.

Die Lösung ist, einen Helligkeitssensor zu verbauen. So ein Fotowiderstand wie oben da bei eBay funktioniert so, dass sein elektrischer Widerstand mit der auf ihn einwirkenden Lichtintensität variiert. Und diese Unterschiede des elektrischen Widerstands kann man mit nem Mikrocontroller messen, und dann im Programmcode dafür nutzen, zum Beispiel zwischen Tag- und Nachtmodus automatisch umzuschalten. Um den besten "Schwellenwert" zwischen Tag- und Nacht-Modus zu finden, wird sicherlich ein wenig "trial and error" nötig sein.

Am besten wird man diesen Widerstand mit im Bordcomputer-Gehäuse unterbringen, so dass er direkt neben dem Display sitzt. Die Version die ich bestellt habe hat einen Durchmesser von 3 mm, das sollte ein relativ unauffälliges Loch im Zifferblatt ermöglichen.

EDIT: Hab übrigens ne Möglichkeit gefunden, vollautomatisch die gewünschten Zeichensätze zu generieren, von denen ich weiter oben schrieb, ich müsste für jede einzelne Schriftart jedes einzelne Schriftzeichen mit nem Grafikprogramm layouten.

Die freie Software "LCD Image Converter" macht dies vollautomatisch, und rechnet jede beliebige TrueType-Windows-Schriftart in gebrauchsfertigen Code um.

Ich bin grad ein bisschen baff, denn das wird ungelogen schätzungsweise nen Monat Entwickungsaufwand einsparen.

Ich hatte bislang zum Testen mal einen Zeichensatz mit 72 Zeichen layoutet, und dann jedes einzelne Zeichen in C-Code umrechnen lassen. Selbst wenn man flink ist, braucht man dafür im ganzen sechs Stunden pro ganzem Zeichensatz. Benötigt werden aber für das Layout wie ich es mir vorstelle allein schon für MGF MkI und MkII zusammen 24 Zeichensätze à 72 Zeichen, also hätte ich 1728 Zeichen einzeln layouten und in Code umrechnen müssen

24 Zeichensätze, weil ich mehrere Schriftgrößen haben will. Außerdem sollen alle Zeichensätze in rot und schwarz vorliegen, und dann auch noch getrennt in Tag- und Nachtdesign. Und das ganze nicht nur für MGF MkI, sondern auch MkII.

So sieht das ganze im LCD Image Converter aus:




Und so sieht dann ein einzelnes Schriftzeichen in "gebrauchsfertigem" C-Code aus, den der Mikrocontroller direkt zur Darstellung ans TFT-Display schicken kann:



Jeder einzelne mit "0x..." beginnende Eintrag in diesem Array stellt die Farbinformation für einen einzelnen Pixel dar. Man geht dann im Programmcode einfach Stück für Stück die Einträge durch, und "schiebt" nach und nach, Zeile für Zeile, die Farbinformationen Pixel für Pixel auf das TFT-Display.

Wer's genauer wissen will: Der hier verwendete Farbraum ist RGB565. Das ist ein 16-Bit-Farbmodell das man vor allem noch von den ersten Windows 9x-Rechnern kennt. Nahezu alle kleinen TFT-Farbdisplays die man heute in solchen embedded systems hat (wie diesem Bordcomputer) beruhen noch darauf.

Das ist auch der Grund, warum ich bisher dachte, jedes Zeichen einzeln layouten zu müssen. Es gibt zwar viele vergleichbare Programme die automatisch Zeichensätze generieren können, aber kein anderes scheint dies in gebrauchsfertigem RGB565-Code zu können.



Werd mich jedenfalls da mal dran machen am Wochenende. Jetzt werden alle Zeichensätze zusammen bis sie gebrauchsfertiger Code sind noch um die drei, vier Stunden dauern

Nachdem wir ja schon über Lizenzen gesprochen haben, hier noch der Hinweis, dass ein MG keine Microsoft Windows Lizenz hat und daher Fonts von Microsoft nicht auf dem MG laufen dürfen. Das ist nur erlaubt, wenn das Endsystem diese direkt von Microsoft selber runterlädt. Ist ja kein Problem, mußt Du den Konverter ja nur auf den Bordcomputer portieren, WLAN ist ja bereits an Bord.

Es gibt aber sicherlich auch frei verfügbare Fonts ....

Duck und weg,
gruss kai, der mit Linux

Hab über das Thema "Lizenzen" auch schon mal ein bisschen gelesen, als ich die Schriftarten ausgewählt hab für den Bordcomputer.

Die Schriftart beim MkI-Design heißt News Gothic Bold Condensed. Die kostet in der Tat Lizenzgebühr, und zwar auch für "embedded systems", d.h. wenn man sie in Apps und anderen mobilen Anwendungen oder embedded systems einsetzt.

Das würde in etwa 30 Euro kosten, aber dann ist man quasi auch "worry free" und hat einmal bezahlt und kann sie unbegrenzt für den Anwendungszweck benutzen.

Ich hab lange gesucht, aber keine andere Schriftart gefunden, die so gut zum Schriftbild des MkI-Tachos passt wie News Gothic. 30 Euro Lizenzgebühr ist aus meiner Sicht zu verschmerzen.

Die MkII-Schriftart wird wahrscheinlich "SF Fourche" heißen. Der Urheber ShyFonts sagt auf seiner Website, dass er dafür 19 US-Dollar haben will. Allerdings gilt das für "commercial use".


Wo wir gerade bei dem Thema "Lizenzen" sind:

Den Bordcomputer wird es zumindest von meiner Seite aus nicht "kommerziell" geben. Da stellt sich dann auch die Frage, ob man wirklich "commercial use"-Lizenzen für die Schriftarten braucht. Wie ich schon mehrfach gesagt hab, werde ich nach der Fertigstellung des Projekts (d.h. wenn mein Prototyp bei mir eingebaut ist und fehlerfrei läuft) eine komplette Dokumentation veröffentlichen mit allen Schaltskizzen, Teilelisten und dem Quellcode, so dass ihn jeder nachbauen kann. Insbesondere nach den letzten Vereinfachungen die ich vorgenommen habe sollte es auch nicht mehr schwer sein, das nachzubauen. Jedenfalls, möchte dann jemand aufgrund dieser Dokumentation den Bordcomputer am Ende doch kommerziell in ner Kleinserie fertigen, dann möchte ich am Umsatz beteiligt werden. Das werde ich dann aber alles noch in meine eigenen Lizenzbedingungen in der Dokumentation schreiben.

Was ich anbieten würde, das wäre, dass ich - zum Selbstkostenpreis - die Quellcodes auf die beiden benötigten Mikrocontroller flashe. Wenn man sich damit nicht auskennt, ist das ist fummelig und nicht frei von Fehlerquellen. Ich würde also anbieten, dass es die beiden MCs bei mir gibt, und ich würde dafür meinen Einkaufspreis plus 10 Euro Aufwandsentschädigung plus Porto nehmen. Das wären dann um die 25 Euro.


In jedem Fall lohnt es sich jetzt noch nicht, schon Lizenzen für die Schriftarten zu kaufen während der Display-Programmcode noch längst nicht fertig ist und sich vieles noch ändern kann. Das kann man immer noch machen wenn das Ding fertig ist und sich wirklich die Frage stellt, will der Urheber der Schriften für diesen speziellen Zweck Lizenzgebühr haben.

Mit den Lizenzen ist das so eine Sache. Das hängt von der Gesetzgebung im Land des Lizenzgebers ab (US/UK hat ein fair-use system), über die Nutzung kommerziell /nicht-kommerziell (die auch unterschiedlich geregelt ist), hin zu speziellen free-licenses/closed-licenses.

Ich glaube, wir unterscheiden rund 300 unterschiedliche Varianten alleine im Open Source. Das lasse ich dann gerne von einem Spezialisten machen, der hat uns auch ein Tool geschrieben, was halb-automatisiert Code analysiert. Aber das ist eine andere Baustelle.

http://praxistipps.chip.de/lizenzfreie- ... iten_30957
http://www.google.com/fonts/
http://www.fontsquirrel.com/
http://www.1001fonts.com/

Anonsten ist das aber eher theoretische Überlegung, ich würde mir da bei diesem Zielkreis (Hobbyisten, nicht-kommerziell) wenig Sorgen machen.

Da habe ich im Bereich von Arduiono und Co schon ganz andere Lizenz-Issues gesehen (und teilweise auch Autoren drauf hingewiesen.

gruss kai, fonts von openSUSE oder Fedora stehen unter einer Open Source Lizenz, gehen also auch

Ich denke auch. Immerhin ist ja wirklich alles was ich anbieten werde eine Dokumentation zum Selbermachen. In der auch stehen wird, dass jeder Nachbau auf eigene Gefahr und rechtlich eigenverantwortlich geschieht. Lizenzkosten für Schriften und so werden vermutlich eher jemanden treffen, der den Bordcomputer kommerziell vertreiben will.



also wenn du ne freie Schriftart findest die genauso aussieht wie News Gothic Condensed (Bold), dann immer her damit.

Der Teufel steckt da aber im Detail... da müsstest du genau jede Ziffer mit dem Tacho von nem MkI vergleichen. Es gibt sehr viele Schriftarten die sich alle sehr ähnlich sind, aber bei keiner hab ich bisher so ne gute Übereinstimmung mit dem MkI-Tacho gefunden wie bei der News Gothic.

Naja und SF Fourche ist komplett "free for personal use".

Das Design des MkII-Bildschirms wird erstmal nachrangig sein bei mir, aber es wird wohl so aussehen:



Die SF Fourche ist allerdings um einiges breiter als die News Gothic Condensed. Damit die Designs wirklich problemlos umschaltbar sind und ein- und derselbe Code am Ende beide Schriftarten darstellen kann, muss die SF Fourche um etwa 60 Prozent horizontal gestaucht werden. Aber auch dafür gibt es Software die das automatisch kann...

Ursprünglich war mal geplant, die Anzeige in ner Sieben-Segment-"Digital"-Schrift zu machen. Das war, als die Idee noch war, das Display in den Drehzahlmesser zu integrieren. Aber wenn man's in die Mittelkonsole macht, dann find ichs besser wenn es in der Tacho-Schrift vom MkII ist. Spart ganz einfach ne Menge Aufwand, weil ich sonst am Ende zwei verschiedene Schriftbilder beim MkII hätte, und dann auch noch in verschiedenen Größen. Der MkI kommt immerhin mit nur einem Schriftbild in mehreren Größen für alles aus, eben News Gothic Condensed.

Ich habe mir noch mal ein paar Gedanken zum Display und den Einbau in die Mittelkonsole gemacht.
Warum verwendest du nicht ein Display das komplette Loch der Anzeige ausfüllt? Dann braucht man das Display nicht in ein Gehäuse einer Anzeige reinstecken, da man die komplett weglassen kann.

Ich finde, es kann nicht schaden, wenn die Platine und das TFT-Display des Display-Moduls in einem festen Gehäuse eingebaut sind, als Staubschutz und als Schutz vor Nässe/Feuchtigkeit.

Ist unwahrscheinlich, dass jemand nen Kaffee verschüttet genau über die Instrumente in der Mittelkonsole, aber man kann nie wissen

Außerdem werden Uhr und Öltemp-Anzeige von hinten mit einer Halterung aus Plastik und ein paar Schrauben in ihrer Position gehalten. Ich weiß nicht genau, ob diese Halterung sich noch richtig befestigen lässt wenn nur eine Anzeige da drin steckt.

So ne gebrauchte Öltemperaturanzeige kostet bei eBay um die 15 bis 20 Euro. Insgesamte Teilekosten für alles werden bei dem Bordcomputer übrigens am Ende überschlagsmässig 75 bis 100 Euro sein. Da ist ne Öltemp-Anzeige schon mit eingerechnet.

Um das Geld für die gebrauchte Anzeige ging es mir nicht, sondern um das größere Display. Dementsprechend könnten deine Grafiken auch größer sein.
Vor das Display selbst muss schon eine Scheibe aus Acrylglas oder Makrolon. Die Displays sind viel zu kratzempfindlich.