GPS/RTC -Uhr auf Basis eines ‚MEGA 2560‘ mit 5″-TFT-Display

Endlich – nach 1,5 Jahren Entwicklung – gibt es jetzt einen vorläufigen End-Stand. Das ist die Version TFT9_50.ino vom 10.März 2019.

Es handelt sich um ein 5″-Display (Chip: SSD1963), mit Touch-Funktion und SD-Karten-Slot. Hier wurde eine RAW-Datei mit 800×480 Pixel als Hintergrund geladen und zwischenzeitlich eine Vielzahl von Informationen programmiert, die hier dargestellt werden. Das sieht (hier noch) nicht perfekt aus, ist aber auch nur ein Beispiel der Darstellung einer der vielen Vor-Versionen für beliebige Hintergründe.

–> Foto anklicken zum Vergrößern.

Hier ist der Download-Link für den aktuellen Sketch TFT9_50

Neben der Uhrzeit, dem Datum und vielen weiteren Informationen, sind auch die aktuellen Sonnen-Daten zu sehen. Dazu ist dann aber ein ausreichender GPS-Empfang nötig, da die Berechnungen auf den Standort und die aktuelle Uhrzeit aufbaut. Zuletzt hinzugekommen ist die Speicherung der Log-Daten auf der SD-Karte. Als Hinweis darauf, das zumindest die letzte Speicherung fehlerfrei war, wird ein ‚grüner‘ Balken über ‚POS‘, bzw. unter ’sync 2′ angezeigt. Alternativ wäre er ‚rot‘. So zu sehen in der ersten (max. einen) Stunde bis zur ersten Speicherung nach dem Einschalten.

wann ist Sonnenaufgang und
wann ist Sonnenuntergang
wann ist der Höchststand
bei wieviel Grad Höhe
Wie lang ist der heutige Tag
wo genau befindet sich die Sonne aktuell
Und es ist der ‚Maidenhead-Locator‘, oder auch ‚QTH-Locator‘ auf die aktuelle Position errechnet
Bei der Haupt-Anzeige der Uhrzeit habe ich mit einem ‚zusätzlichen‘ Schrift-Font gearbeitet. Es handelt sich um den Font ‚SevenSeg_XXXL‘, der nachträglich in der Bibliothek (UTFT) installiert wurde
Und letztlich gibt es auch eine automatische Synchronisation der RTC auf die GPS-Zeit (aktuell ‚alle 25 Tage‘)
…. wie auch die vollständige Mondphasen-Berechnung und -Darstellung (über 8 Einzel-Bilder)
Mit der SD-Karte nutze ich die Möglichkeit viele verschiedene Bild-Dateien zu hinterlegen, auf die man dann später recht einfach zugreifen kann, ohne etwas wieder auseinander bauen zu müssen. So nutze ich die Karte zum einen bereits für verschiedene Hintergrund-Fotos, wie auch für die 8 Mond-Darstellungen. Zudem schreibe ich den Referenzwert der RTC-Synchronisation darauf und …..
… die Log-Daten aller wesentlichen Anzeige-Werte werden auf der SD-Karte gespeichert (aktuell: 1x stündlich)

Im Augenblick habe ich noch das Problem, dass ich den fertigen Sketch nicht an diese Stelle hochladen kann. Zumindest das Format .ino, aber auch .txt wird nicht zugelassen. Solange ich da noch keine Lösung habe, kann der Interessent mich per E-Mail erreichen (info@bschnare.de). Dann kann ich das zuschicken. Aber ACHTUNG !!! Das ist kein Anfänger-Projekt ! Auch dann noch nicht, wenn ich den Sketch schon fertig zur Verfügung stelle. Allein die einzelnen Komponenten wollen am ARDUINO zusammengebaut werden. Für den, der schon ‚Bastel-Erfahrung‘ hat, kein Problem. Der Anfänger wird sich schwer tun. Und dann sind da die notwendigen Bibliotheken, die vor dem Hochladen auf den ‚MEGA‘ im eigenen Library-Verzeichnis zur Verfügung stehen müssen. Und da die richtige (Einzel-)Bibliothek zu finden ist auch nicht ganz einfach. Zumal es heute sogar Bibliotheken gibt, die inhaltlich nicht mehr mit dem früheren Stand übereinstimmen – und so auch nicht kompatibel sind. Und es gibt Bibliotheken, die bauen auf einer älteren Bibliothek auf. Diese beiden Fälle habe ich im Bereich der TFT-Anzeige ‚ertragen‘ müssen. Es hat einige Zeit gedauert, bis ich die Zusammenhänge verstanden habe.
So etwas kommt dann vor, wenn engagierte Entwickler eine alt-bekannte Bibliothek, wie die „UTFT“ auf neue, besondere Hardware-Ausführungen fit machen. So ist die „UTFT_SdRAW-master“ ein solcher Fall. Hier wurde z.B. die Darstellung und das Hochladen der Hintergrund-Bilder deutlich optimiert. !!! Die „UTFT“ wird trotzdem weiterhin gebraucht !!!
Überhaupt kann jedem, der dieses Projekt nachbauen will, empfohlen werden, zunächst nur das eingesezte TFT-Display alleine in Betrieb zu nehmen. Dabei sollte dann erst einmal ruhig auf die hier in meinem Sketch genutzten Bibliotheken zurückgegriffen werden. Vermutlich wird das alleine schon ausreichend sein eines der schönen Beispiel-Sketche mit bewegter Grafik an den Start zu bringen. Wenn aber nicht – dann ist es eben erst einmal notwendig nur diesen einen Part für sich ans Laufen zu bekommen. Danach können dann die diese speziellen Konfektions-Daten in ‚meinen‘ Sketch übernommen werden und dort dann die vorhandenen Zeilen überschreiben.
Das betrifft in allererster Linie die Zeile : UTFT myGLCD(ITDB50, 38, 39, 40, 41); Hier werden der TFT-Typ, die Bibliothek, sowie die wichtigen Ansteuer-Pins beschrieben. Diese Zeile hat es in sich ! Zwei weitere – darüber liegende, auskommentierte – Zeilen beschreiben beispielhaft eine andere Kombination.
So ist der Display-Treiber oft der Stolperstein. Auch wenn ich das vermeintlich gleiche Display wenige Wochen später nochmals beim gleichen Händler kaufe, kann es schon aus einer anderen Charge sein und hat einen abweichenden Treiber-Baustein verbaut. Dieser Punkt hat mich bei all meinen Projekten immer eine Unmenge an Zeit gekostet. Das nur als Hinweis.

Der nun folgende Text beschreibt einige Entwicklungs-Etappen und kann event. nützlich für den sein, der diese Uhr nachbauen möchte und sich einen Überblick verschaffen möchte, was da auf einen zukommen kann. Wobei – inzwischen habe ich ja schon alle Fehler gemacht und dann behoben. Da kann ich an manchen Stellen mit Rat und Tipps behilflich sein.

Stand: 04.Febr.2019 TFT9_50m.ino
Bereits in einer der vorherigen Versionen wurde die Anzeige strukturiert und das ‚Quermarkenfeuer wieder aktiviert – weiterhin also auch ‚mit blinkendem Feuer‘.
Einiges hat sich in den letzten Versionen und Entwicklungs-Monaten geändert. Vieles ist nunmehr auch über viele Woche im ‚Dauerlauf‘ getestet – und korrigierte, bzw. verbessert worden. Da gab es mancherlei Details, die erst im Dauertest auffallen.

Erst gestern ist die Mondphasen-Systematik fertiggestellt worden. In der Anzeige sieht man nun einerseits die aktuelle Mondphase als Bild, welches sich entsprechend der aktuellen Phase in der wir uns befinden auch ändert. Dazu stehen 8 Fotos als RAW-Dateien auf der SD-Karte zur Verfügung. Zusätzlich wird die aktuelle Sichtbarkeit in ‚%‘ angezeigt, sowie die Information, ob wir uns aktuell in der abnehmenden Phase, oder in der zunehmenden Phase befinden.
Im unteren Anzeige-Bereich, hat es auch Erweiterungen bei Uhrzeit und Datum gegeben. So wird die ‚RTC-Zeit‘, die auch nochmals ganz rechts unten in gelb zu sehen ist, für den Zeitraum in die Hauptanzeige übernommen, wie noch kein gesicherter GPS-Empfang gewährleistet ist. Zu erkennen ist das daran, dass dann auch diese ‚große Anzeige-Schrift‘ gelb-orange ist. Sowie der GPS-Empfang ausreichend ist, wechselt diese Anzeige auf die andere Zeit-Ebene und wird dann auch ‚grün‘ angezeigt. Links davon steht – etwas kleiner – die UTC-Stunde, von der aus die Lokalzeit, unter Berücksichtigung der Sommerzeitregelung, errechnet wird. Rechts in diesem Anzeige-Balken sind die Felder ‚SAT‘ – als Anzeige für den Uhrzeit-Empfang vom Satelliten – zu sehen, sowie ‚Pos‘ als Nachweis, dass auch ein zuverlässiger Empfang der Positionswerte besteht. Und darüber ist eben die ‚dritte‘ Uhrzeit zu sehen, die völlig autark von der ‚RTC‘ (RealtimeClock/Echtzeituhr – DS3231) kommt. Das Besondere an dieser Stelle ist aber – bei ‚vollem‘ GPS-Empfang, das sind 6 – und mehr Satelliten, wird die GPS-Zeit dazu genutzt, die RTC-Komponente in regelmäßigen Zeitabständen automatisiert zu kalibrieren. So ist sichergestellt, dass allein die Echtzeit-Uhr (RTC) auch von Zeit zu Zeit (aktuell alle 25 Tage) synchronisiert wird. Um das auch nach Abschalten, oder Stromausfall der ‚Gesamt-Uhr‘ sicherzustellen,wird ein Referenz-Wert auf die SD-Karte geschrieben und von zeit zu Zeit abgefragt, wenn denn GPS-Empfang vorhanden ist.
Man kann also die Uhr vom Strom nehmen. Sind 25 Kalendertage, oder mehr vergangen und die Uhr wird wieder in Betrieb genommen, dann ist von der Konzeption her sichergestellt, dass trotzdem bekannt ist, wann denn der Echtzeit-Chip das letzte Mal synchronisiert wurde. Und das wird dann auch entsprechend nachgeholt.

Wie in allen meinen Programmen/Sketchen, greife ich auch hier umfassend auf eine umfassende Kommentierung, wie auch auf eine umfassende Ausgabe von Referenzwerten über den ’seriellen Monitor‘ zurück.
Hier ist ein Teil des parallel am angeschlossenen PC mitlaufenden ’seriellen Monitors‘ zu sehen, mit dem alle relevanten Berechnungs-Ergebnisse dargestellt sind und so unachzuprüft werden können. –> anklicken zum Vergrößern

Neben den üblichen Entwickler-Problemen bei der Programmierung und der Hardware, liegt hier der wesentliche Schwerpunkt in den komplexen Formeln zur Ermittlung des Sonnenstandes. Deklination, Zeitdifferenz, Zeitgleichung, Azimut, Sonnenhöhe, Julian-Tag, …. als auch die Berechnung von Teil-Ergebnissen, bei denen mit 3 unterschiedlichen Zahlensystemen gerechnet wird. So werden Dezimal-Werte mit Uhrzeit und mit Winkel-Grad kombiniert. Die Zeitverschiebung von MESZ zu MEZ spielt zusätzlich eine Rolle. Und all die durchaus hilfreichen Formeln aus dem Internet, von Menschen, die richtig Ahnung in dem Metier haben, sind dann in die ‚C++‘ ähnliche Arduino-Programmiersprache zu übersetzen. Wer es noch nicht selbst gemacht hat, kann sich gar nicht vorstellen, was für ein Akt das ist. „Nachmittag-füllend !“ Aber danach weiß man wie es geht und hat zudem die Funktion der Berechnung verstanden.

Richtig ‚lustig‘ wird es dann aber – wie ich auch erst heute (04.02.2019) weiß -, wenn es an die Mond-Laufbahn geht. Da ist die Berechnung der Sonnenbahn erheblich leichter. Alleine das hätte ich mir schon vor wenigen Monaten, als ich am Thema Sonne arbeitet, nicht ansatzweise vorstellen können. Beim Mond kommen nämlich noch sehr viel mehr Komponenten zum Tragen. Und da wird mit Begrifflichkeiten gearbeitet ……. So ist die Rede von ‚der gestörten Mondbahn‘, von heliozentrischer – und geozentrischer Bahn, von Evektion und Variation, von Elongation, mittlerer Anomalie, Wirksamkeit der Störbeschleunigung im Peri- und Apogäum, .. zudem variiert die Entfernung zur Erde und der Mond ‚eiert‘ auch im Tagesverlauf neben uns her. Alles Komponenten und Auswirkungen der verschiedenen Anziehungskräfte in seiner Umlaufbahn.
==> S P A N N E N D ! ! !

Diese und viele andere Features und Erfahrungen werde ich hier beizeiten im Detail weiter vorstellen.
So etwa auch: Mit dem 7″-Display (Chip: MD090SD) komme ich nicht klar. Der verbraucht u.a. derart viel Strom, dass mir der ‚kleine Freund (ARDUINO)‘ nur leid tuen kann. Zudem hatte ich Probleme mit der Ansteuerung. Grund: der USB-Port vom Laptop kann derart viel Strom gar nicht liefern. So benötigt das 7″-Display alleine schon 650mA (!). Und wenn ich zur (grundsätzlich notwendigen) Unterstützung ein 12V-Netzteil am Spannungs-Anschluß des ARDUINO anschließe (denn der kann das vertragen), dann ‚raucht mir allen Ernstes der Spannungsregler vom Board ab‘. Hier ist also ein USB-Steckernetzteil mit 2A-Leistung die beste Wahl, oder doch zumindest ein Netzteil, welches möglichst nicht mehr als 7V liefert.

Das ‚°‘ Zeichen (Grad) ist auch so eine Sache. Die Ausgabe von Zahlen auf dem Display ebenfalls.

Den zweiten (!) Seriellen Port (TX1/RX1) für den GPS-Empfänger schalte ich jetzt erst ganz am Ende des Bereiches ‚SETUP‘ dazu, da dieser extrem ‚kommunikativ‘ ist. Dort werden jede Sekunde 10 Zeilen á 50 Zeichen an den Arduino übermittelt. Das kann schon mal beim Start zu ‚Irritationen‘ führen. Durch den separaten Start des zweiten seriellen Ports über diese Anschlüsse (das kann auch mit einer abweichenden Baud-Rate erfolgen) erziele ich einen störungsfreien Programmstart. Zudem habe ich noch ein ‚Delay‘ nach dem Aufruf des Hintergrund-Fotos eingebaut – das stört ja nicht, da es nur anfangs beim Hochladen des Programms einmalig ausgenutzt wird. Ansonsten kann es passieren, dass das Bild nicht fehlerfrei hochgeladen wird.

Zudem überlege ich, ob es denn nicht besser wäre, die Ermittlung der Sensor-Werte und deren Anzeige nicht auf die volle- und halbe Minute zu fixieren, sondern z.B. immer 5 Sekunden danach. Insbesondere zur vollen Minute ist der ARDUINO derart beschäftigt, dass die Sekunde ’00‘ nicht angezeigt wird. Zwar springt nach der 59.Sekunde die Minute korrekt um, aber die nächste angezeigte Sekunde ist dann die ’01‘. Ein Zeichen dafür, dass es zur vollen Minute viel zu tun gibt.

Der Austausch der Puffer-Batterie am DS3231-Board gegen einen Akku ist auch noch eine Variante.

Der Einbau eines Kondensators an die Anschlüsse des DS3231, zum ‚Anfangen‘ von Störimpulsen ist ein weiterer Punkt, auf den ich in der letzten Zeit gestoßen bin.

Die Berechnung der Mond-Laufzeiten – ähnlich denen der Sonnenlauf-Zeiten – ist noch eine Herausforderung.

Und ich möchte alle relevanten Daten ‚halb-stündlich‘ auf SD-Karte speichern. Das sind Barometer, Uhrzeit, Datum, Sonnenstand, SA, SU, Mondphase, …. und was noch wichtig erscheint. Temperatur und Luftfeuchte machen dabei keinen Sinn, da es sich um Innen-Werte handelt.

Und – ich bin aktuell (Okt.2018) in einem parallel laufenden ‚Kunden-‚Auftrag mit einem Mini-MEGA konfrontiert. Das ist ein leistungsidentischer MEGA2560 – mit 38x54mm weniger als halb so groß – für 10,- €. Der ‚MEGA2560‘ hat die Maße 101,5×53,3mm. Aufgrund der geringen Größe sind lediglich die bekannten Anschlußleisten anders angeordnet. Da muß man sich was ‚eigenes‘ bauen. –> Dieses Projekt ist jetzt, am 04.02.2019, bereits erledigt und ’spielt‘ hervorragend auf kleinstem Raum. „Sehr schön !!“

Bei diesem Foto handelt es sich um eines der Vor-Projekte, welches auch mit einem MEGA2560 und einer 2.4″-TFT-Anzeige ausgestattet ist. Ein wesentliches Ziel-Feature besteht aber z.B. darin keinen einfarbigen Hintergrund zu nutzen, sondern ein eigenes Foto. Und das sollte dann zudem auch noch ‚blinken‘.

(Fotos durch anklicken vergrößern)
Hier ist schon die nächste Projekt-Etappe zu sehen, bei der ersichtlich wird ‚wohin die Reise gehen soll‘. Und das Leuchtfeuer blinkt zudem außerhalb des Sekunden-Taktes. Stand: 24.Juni 2018

14.Juni 2018
Ich habe zwar in den letzten drei Jahren schon so manche Arduino-Uhr gebaut – und diese auch mit den unterschiedlichsten Funktionen und Möglichkeiten ausgestattet. Dazu gibt es schon eine Menge Infos auf meiner Seite ,ARDUINO & Co‘ (siehe Verlinkung oben). Dieses Projekt hier soll nun aber ‚die Summe aller bisher gesammelten Kenntnisse und Erfahrungen‘ beinhalten, als auch alle bisherigen Ideen für eine solche Uhr umsetzen. Daher spendiere ich diesem Projekt nun eine eigene Seite, aus der der Interessierte in Einzel-Etappen alles Wissenswerte für sein eigenes ARDUINO-Projekt ableiten kann, oder auch später nur das Gesamt-Projekt für sich runterlädt und selbst nachbaut.

Worum geht es ?

Ich werde hier in einzelnen Etappe beschreiben, wie ich zum Ziel gekommen bin. Denn in Etappen zu arbeiten und zu entwickeln erscheint mir sinnvoll, das das Projekt einen ziemlichen Detail-Umfang hat und jedes einzelne Feature zunächst für sich getestet werden sollte. Es gibt zu viele individuelle Lösungsansätze, die sich aber – abhängig von den eigenen individuellen Bauteil-Komponenten – sehr stark voneinander unterscheiden können. Da habe ich für mich die Erfahrung gemacht, dass es eben besser ist in Teil-Etappen zu arbeiten.

Jede einzelne Etappe wiederum ist für sich alleine oft auch schon wieder eine interessante Hilfe bei anderen Projekten und kann so später einmal als Einzel-Modul für weitere Projekte genutzt werden.

Letztlich ist es so, dass ich zu Ostern 2015 erstmalig damit begonnen hatte mich mit dem ARDUINO aktiv zu befassen. Und seit dem hatte ich auch immer diesen Faible ‚Uhren zu bauen‘. Und immer dann, wenn eine Uhr gerade fertig geworden war, hatte ich schon die Idee für neue Erweiterungen – an denen ich dann wieder weiter entwickelt habe. Und das hier soll nun (erst einmal) das letzte dieser Uhren-Projekte sein. Aber auch das wird sicher nochmals revidiert wenn diese Uhr dann fertig ist. –> Größeres Display, umsetzen auf RasPi, zusätzliche weitere Features, …

Projekt-Beschreibung

ARDUINO-MEGA basierender Aufbau, mit 2.4″-TFT-Display, SD-Karten lesen und schreiben, Touch-Screen-Einbindung, Temperatur-Messung, Luftfeuchte-Messung und Luftdruck-Messung. Aussenwerte-Übertragung via Funk (433 MHz, oder 2.4 GHz). RTC (RealTimeClock)-Chip, welcher sich mittels eines GPS-Empfängers bei ausreichendem Empfang automatisch synchronisiert, Foto-Hintergrund auf dem Display, Berechnung von Sonnenauf- und Untergangszeiten, wie auch der Mond-Laufzeiten, Berechnung des aktuellen Locator (Maidenhead-Locator). Alles auf Basis der aktuellen Geo-Position. Berechnung des Taupunktes und der Wolkenhöhe (macht nur Sinn über die Aussen-Sensorik). Speicherung der Meß- und Berechnungswerte.

Anzeige von Datum, Wochentag, sowie der Uhrzeit in UTC (UT, oder GMT), als auch der aktuellen Uhrzeit vor Ort, einschließlich der automatischen Umrechnung auf MEZ und MESZ.

Das die Uhr mit zwei Zeit-Systemen ausgestattet werden soll, hat seinen Grund darin, dass diese Uhr vielfach von Amateurfunkern genutzt werden wird, die ihren ‚Shack‘ im Keller haben. Dort gibt es aber keinen SAT-Empfang für das GPS-Signal. Damit wäre die Uhr wertlos. Deshalb wird die Uhr auf Basis des RTC-Chip DS3231 konzipiert und stellt sich bei ausreichendem GPS-Empfang automatisch nach. Was an sich aber kaum jemals nötig sein wird, da der ‚DS3231′ nach meiner Erfahrung keine 5 Sekunden im Jahr nachgeht. Aber …… ich möchte es ja absolut exakt haben. Und bei bspw. WSPR-Betrieb kommt es schon auf die Sekunde an.
Zudem ist es so, dass die Maidenhaed-Koordinaten (QTH-Locator), als auch die Sonnen-Umlaufberechnungen, den genauen Standort für die Berechnungen benötigen. Den liefert ebenfalls der GPS-Empfänger. Für den Fall, dass der nicht mit einem ausreichenden Signal verfügbar ist, könnten an dieser Stelle auch Fixwert-Variablen ,mit den eigenen Koordinaten‘ eine zusätzliche Alternative darstellen.

Und dann noch die Begründung ‚Warum ein ‚MEGA2560‘ ? –> Weil all das, was da an Programm-Script benötigt wird, nicht ansatzweise auf einen ‚UNO‘ passt. Man muß dabei nur mal an die vielen Bibliotheken denken, die mitgeladen werden müssen.

(bisherige) Teile-Liste

ARDUINO MEGA 2560
ARDUINO UNO R3 (für die ersten drei Etappen und dann als mögl. Aussensensor und -sender; als Alternative zu einem Leonardo)
2.4″-TFT-Display, mit Anschlüssen an den Längsseiten, Touch-Screen und SD-Karten-Slot auf der Rückseite.
240×320 Pixel, ILI9341(ILI9342 geht auch) –> Kostenpunkt: ab 5,- €
Verbindungs-Shield vom MEGA auf ein großes Display –> ca. 11,- €
7″-TFT-TouchSD-Display, mit MD090SD-Chip –> ca. 55,- €, bei Eckstein
5″-TFT-TouchSD-Display, mit SSD1963-Chip –> ca. 42,- €, bei Eckstein
RTC-Board: DS3231
Temp/Feuchte-Sensor : DHT11, oder DHT21, oder DHT22
Druck-Sensor : BMP085, oder BMP180, oder ähnlich
GPS-Empfänger : Crius NEO m8n –> Kostenpunkt : ab ca. 19,- €
USB-Kabel, Arduino-Editor, ggf. Netzteil, Steckboard, Jumper-Kabel, …. was man halt so braucht

Los geht’s mit den ersten Etappen

TFT-Display auf dem Board in Betrieb nehmen –> mit dem UNO
Dazu ist einer der Beispiel-Sketche aus dem Library-Ordner SPFD5408_master zu verwenden. Es sind ggf. Anpassungen bei der Pin-Belegung vorzunehmen.
SD-Karte lesen, schreiben, löschen , prüfen –> mit dem UNO
Hier kann eines der Beispiel-Sketche aus der Arduino-EDI ‚SD‘ genommen werden – z.B. ReadWrite.ino. Vor dem Kompilieren und Hochladen ist jedoch die Definition des CS-Pin von ‚4‘ auf ’10‘ zu ändern, da das seitens vom Display her Hardware-seitig vorgegeben ist.
beides zusammen für das Laden eines Hintergrund-Fotos auf den ‚UNO‘ nutzen
… und – in dem beschriebenen Beispiel – blinkt das Quermarkenfeuer sogar (!) Das Programm heißt Quermark.ino

Nachdem das bisher erst auf dem ‚UNO R3‘ passiert ist, erfolgt nun die Umsetzung der drei vorherigen Etappen auf den ‚MEGA2560‘.

Und das ist erwartungsgemäß wieder ein immenses Problem mit unzähligen Fehlversuchen. Erstaunlich ist in solchen Situationen auch immer wieder zu sehen, dass andere auch diese Probleme haben. Aber ein Forum zu finden, oder einen Thread, in dem mal eine Lösung präsentiert wird, sowie ein einfache, nachvollziehbare Erklärung, ……. Ich habe bei meiner Recherche über die letzten Jahre nichts gefunden. Die Lösung war immer auch die Summe aller Antwort-Details. Irgendwann hat es dann irgendwie funktioniert – Ich habe aber nie herausgefunden ‚Warum ?‘. Jetzt bin ich schlauer und kann dieses Wissen kurz und bündig weitergeben:

Die Anschlüsse für MISO, MOSI und CLK sind grundsätzlich ‚fest verdrahtet‘ und beim ‚UNO‘ abweichend von denen auf dem ‚MEGA‘ !!

Grund: Diese 3 Anschlüsse sind einerseits auf den Boards (neben dem SPI-Bus) ‚fest verdrahtet‘ und können nicht geändert werden. Daher ist es auch so, dass es nicht nötig ist diese 3 Pins im Sketch zu definieren (das ist mir zwar schon früh aufgefallen – ich konnte es mir aber bisher nicht erklären). Unglücklicherweise – und das ist eben das Dilemma bei der Suche nach Erklärungen im Netz – auf dem ‚UNO‚ sind es die Anschlüsse: MOSI = Pin11, MISO = Pin12, CLK (oder SCK) = Pin 13. Der CS (oder SS) = Pin10, ist frei konfigurierbar und muß daher auch immer definiert werden. Beim ‚MEGA‚ ist das aber anders verdrahtet (!!!). Da ist MOSI an Pin51, MISO an Pin50 und SCK an Pin52. CS = Pin53 (oder wahlweise ein anderer Pin). Und darum kommt es in allen Foren immer wieder zu dieser Konfusion. Über diese Erkenntnis kann man dann auch lange diskutieren. Ist aber Blödsinn – „Wir sind hier nicht bei ‚Wünsch-dir-was‘ , sondern bei ‚So isses‘.

Damit habe ich hier das Problem beschrieben, sowie den Grund – und damit die Erklärung geliefert. Jetzt muss aber auch noch eine Lösung für meinen Aufbau gefunden werden. Da gibt es nach kurzer Überlegung ‚3 Varianten‘ : 1. (die nehme ich auch, sofern nicht weitere Probleme an anderer Stelle auftauchen – z.B. beim TouchScreen) Vergiss den SD-Slot auf der Rückseite des Displays und verwende ein separates Breakout-Board für die SD-Karte. Den Platz habe ich, da ich ohnehin eine separate Platine für die Sensorik und die RTC benötige. Die SD-Karte dann problemlos mit Pin50-53 (CS=53) verkabelt werden. –> Klappt !
2. Möglichkeit ist : Das gesamte Display nicht auf den ‚MEGA‘ aufzustecken, sondern separat betreiben. Auch dann kann ich die Anschlüsse Pin50-53 problemlos verkabeln (CS könnte dann auch weiter auf Pin10 bleiben).
Und die 3.Möglichkeit ist ein interessanter Zwitter aus beiden vorherigen Lösungen: Nur die 3 Anschluß-Pins am Display für MOSI, MISO und SCK sind vor dem Aufstecken auf den ‚MEGA‘ seitlich wegzubiegen. Diese drei Anschlüsse sind dann mit entsprechenden Jumper-Kabeln auf die Anschlüsse 50, 51 und 52 zu führen. ‚CS‘ kann weiter an Pin10 angeschlossen bleiben. Der Sketch kann genau so bleiben wie bisher, ausser ich wähle für den CS-Pin die ’53‘ – dann ist das entsprechend im Sketch zu definieren (!).

So umgesetzt klappt es nun auch mit dem ‚Quermarkenfeuer‘ auf dem ‚MEGA‘. Zudem habe ich schon jetzt die komplette Verdrahtung aller anderen Bauteile – mit Ausnahme noch des ‚Crius m8n‘ – vorgenommen und jeweils in einzelnen, vorhandenen Beispiel-Sketchen auch getestet. ==> Alles läuft. Stand: 15.06.2018

Das nächste – vermutlich kleinere – Problem kündigt sich aber schon an. Den letzten Sketch (TFT8_24.ino >> auf dem ersten Foto oben zu sehen ), der bei (vermeintlich) gleicher Hardware bestens lief, läuft jetzt nicht mehr in diesem – gewissermaßen 2. Aufbau. Im ’seriellen Monitor‘ sind jedoch sämtliche Sensor-Werte korrekt aufgeführt. Damit läuft das Programm an sich auch schon fehlerfrei. Hier fehlt jedoch jetzt die komplette Display-Anzeige.
Trotzdem das beide bisher verwendeten Displays äußerlich vollständig gleich sind, liegt die Problematik offenbar darin, dass ich zuletzt ein 2.4″-Display (von 2018) verwendet hatte, welches von seinem Chip-Satz her die Libraries SPFD5408_ADAFRUIT_GFX.h, sowie die SPFD5408_ADAFRUIT_TFTLCD.h benötigte. Jetzt aber verbaue ich (zufällig) ein 2.4″-Display von 2016, welches faktisch die ADAFRUIT_GFX.h und xxxx benötigt. Und somit stimmen dann eben die bisherigen Ansteuerungen seitens der Software nicht mehr. Aber dem Varianten-Reichtum von Board – Shield – Display – Chipsatz – Bibliothek sind ohnehin kaum Grenzen gesetzt. Das muß man immer beachten.

die RTC einbinden und auf dem Display mit Foto darstellen (23.06.2018)

Bis hierhin ist das der bereits erreichte Projekt-Stand. An dem Folgepunkt arbeite ich als nächstes.

TouchScreen einbinden
Zweiten Bildschirm mit weiterem Foto-Hintergrund aufbauen
es folgen die Anzeige der (Innen-)Sensoren
astronomische Berechnungen einbinden (siehe dazu auch die CQ-DL 06/2018, den Beitrag von Thomas, DL1DUZ)

Ab hier ist das noch nicht weiter umgesetzt und stellt damit die weiteren Etappen da

GPS-Empfang einbinden
RTC mit GPS verbinden
Aussen-Sensorik und Funk-Modul aufbauen
… und dann im Haupt-Programm mit einbinden
Gehäuse-Bau

Stand: 22.Okt.2018 >> TFT9_70.ino <<

In den letzten Monaten hat sich einiges getan. Die Weiterentwicklung der 2.4″-Version ist zunächst einmal gestoppt. Stattdessen arbeite ich bei gleicher Zielsetzung an der Entwicklung mit einem 7″-Display, da ich schlicht nicht all das, was ich angezeigt bekommen möchte, auf ein 2.4″-Display bringen kann. Zudem habe ich noch immer Probleme mit dem Touch-Screen.

Der heutige stand ist der: 7″-Display wird vermutlich kurzfristig gegen ein 5″-Display ausgetauscht. Aktuell habe ich gar kein Display angeschlossen, sondern mache die bisherige Programm-Entwicklung über Ergebnis-Ausgaben an den ‚Seriellen Monitor‘. Grund dafür ist das ’spannende Erlebnis‘, dass derart viel Strom vom Display gezogen wird, dass einerseits der USB-Port am Laptop abschaltet und damit der ARDUINO nichtmals in der Lage ist, sein Programm hochzuladen. Die Alternative mit einer separaten, zusätzlichen Stromversorgung am Board, führte leider dazu, dass zumindest der Spannungsteiler auf dem ‚MEGA2560‘ abgeraucht ist. Und was das Shield, sowie das Display dabei mitbekommen haben, kann ich aktuell noch nichtmals sagen.

Ansonsten ist es so, dass ich – wenn auch sehr langsam in vieler Stunden Entwicklungsarbeit bei der Programm-Erstellung – recht zielgerichtet vorankomme.
Zwar ist die TFT-Anzeige noch nicht wieder am Start, aber es ist grundsätzlich kein Problem mehr, ein eigenes Foto (was zuvor, z.B. mit ‚GIMP‘, auf die korrekte Pixel-Größe gebracht werden muß) als Hintergrund von der rückwärtigen SD-Karte zu laden. Und ich habe sämtliche Wahnsinns-Formeln und Berechnungen für den Sonnenlauf zusammengetragen und auf den ARDUINO umgeschrieben. So stehen bereits die Daten für die Uhrzeit von Sonnenaufgang, -untergang, Sonnenhöchststand mit Höhenwinkel zur Verfügung, als auch die aktuellen Azimut- und Höhenwinkel der Sonne und die Tageslänge.

Das hat – im Nachhinein besehen – sehr viele Erkenntnisse über die Berechnung der Sonnenbahn gebracht. Es hat auch mathematisch manches wieder aus der Schulzeit hervorgeholt. So sind in den Berechnungen ‚drei Zahlensysteme‘ miteinander zu verknüpfen. Zum einen ist das natürlich das Dezimal-System, aber auch das Stunden-Minuten-System mit seiner 60er-Teilung und das Winkel-Grad-System, mit seiner 360er-Teilung. Hinzu kommt immer auch noch die Berücksichtigung von Sommer- und Winterzeit.
Und der anfängliche Irrglaube, ich könnte eine EXCEL-Formel aus dem Internet ‚mal eben‘ in die ARDUINO-ähnliche Programm-Sprache C++ übernehmen. Dem ist überhaupt nicht so. Diese dort verfügbaren Formeln sind natürlich inhaltlich extrem wichtig und eine erhebliche Hilfe. Ich selbst wüsste niemals wie der Sonnenlauf zu berechnen ist ! Aber die Syntax ist bei C++ völlig anders. Wer also Spaß an solchen Tüfteleien hat, der hat nur allein mit der Umsetzung von Teil-Formeln zur Sonnenberechnung wie der Deklination, dem ‚Tag des Jahres‘, der Zeitgleichung, der Zeitdifferenz, der Sonnenhöhe, dem Radianten der Breite, etc. schon ein zweifellos ‚Nachmittag-füllendes Programm‘ vor sich.
Wen’s nicht interessiert, der läd schlicht diesen Sketch auf seinen Mega hoch – und gut ist.
Dabei ist dann aber noch an einigen Variablen der Inhalt auf die eigenen individuellen Gegebenheiten zu ändern. Das sind das Rufzeichen und die Standort-Koordinaten.

Hier sind die Stolpersteine aufgeführt, die dieses Projekt im Laufe der Zeit mit sich gebracht hat:

Trotz identischem Aussehen, gleicher Größe und gleicher Anschlußbelegung hatte ich zwei unterschiedliche 2.4″-Displays. Das eine hatte ich 2016 gekauft, das andere war von 2018. Beide zum direkten Aufstecken auf den ARDUINO. Der Sketch funktionierte nur bei dem einen Display – nicht mehr bei dem anderen.
Grund: Baujahr-bedingt wurde ein anderer Anzeige-Chip verwendet –> und der benötigt eine andere Library.

Der SD-Karten-Slot funktioniert zwar in Verbindung mit dem ‚UNO‘, nicht aber mit ‚MEGA‘.
Grund: siehe oben

Ursprünglich wollte ich das Sensor-Board ‚GY-87‘ einsetzen. In Verbindung mit dem ‚DS3231‘ ist das aber nicht möglich.
Grund: Der Lage-Sensor nutzt die gleiche I2C-Adresse wie ‚RTC‘. Das klappt so nicht.

Da es sich um eine Uhr handelt, möchte ich auch die Sekunden sehen. Entsprechend läuft auch der ‚Loop‘-Bereich. Bei den Sensor-Werten habe ich es so programmiert, dass diese nur alle 30 Sekunden aktualisiert werden. Das spart Rechner-Kapazität. Bei dem Umfang an Funktionen merkt man das doch schon (.. wenn die Sekunden schon mal springen). Zudem werden Minuten, Stunden, Datum und Monat nur dann neu auf das Display geschrieben, wenn sich dieser Wert auch ändert. Auch das spart Ressourcen.
Nun möchte ich aber im Hintergrund parallel das Leuchtfeuer blinken lassen – und zwar abweichend vom Sekundentakt. Naheliegend ist dann erst einmal mit ‚delay()‘ zu arbeiten. Vergiss es !!!
Die Lösung: arbeite mit ‚millis‘ ! Dabei wird mehrfach pro Sekunde abgefragt, ob der eingegebene Intervall (welcher auch immer) schon erreicht ist. Wenn nicht, dann arbeitet das Programm im ‚LOOP‘ weiter wie gewohnt. Nur dann, wenn der Zeitintervall erreicht ist, wird ‚mal eben‘ der neue, folgende Status-Wert gesetzt. –> Bei nachträglicher Überlegung auch logisch: 1 Sekunde hat 1.000 Milli-Sekunden. Da kann so ein Prozessor schon manches andere tun und muß nicht mittels ‚delay()‘ eine Zwangspause einlegen.

ARDUINO-Uhr