würdest Du mir vielleicht auch ein Bild davon senden ? Mich interessiert das natürlich sehr - auch wenn hier jemand, der nach eigenem Bekunden keine Ahnung von Arduino & Co. hat, schon 80 mHz Taktung für "lustig" hält (weil ich einen Wemos D1R2 für sowas benutze). Der D1R2 ist übrigens quarzgetaktet - ist das der Giga auch ?
LG - Martin
Hallo Martin,
ich wollte mich bestimmt nicht über irgendjemanden oder irgendetwas "lustig" machen.
Für mich standen nur die Einfachheit und die Möglichkeiten im Vordergrund. Mit meinem Vorschlag hat man schon recht schnell drei wichtige Grundpunkte eines Datenloggers abgearbeitet:
1. Datenspeicherung enormer Datenmengen (USB-Stick) 2. Datendarstellung (großes Display oder per Wlan an PC) 3. Datenverarbeitung (der Controller selbst natürlich oder per Wlan/USB-Stick auf PC)
Das liegt dann als kompaktes und robustes System vor. Jumperkabel sparen ist gerade am Anfang eine große Erleichterung.
Dazu kommen jede Menge Schnittstellen, teils in mehrfacher Ausführung.
Ob das Board einen gut stabilisierten Quarz hat, kann ich nicht sagen. Eine interne Real Time Clock liegt vor. Wie genau das Ding ist, weiß ich nicht. Aber auch das wurde schon von anderen gelöst.
Um einem möglichen Missverständnis vorzubeugen: Ich habe bereits Datenlogger für analoge und digitale Signale gebaut, aber eben nicht für Uhren. Lösungen zur Optimierung der Langzeitstabilität wurden in diesem Forum schon gefunden, glaube ich. Da bin ich aber nicht ganz auf dem Laufenden.
Die Entwicklung des Datenloggers geht voran. Die Hardware ist als Testaufbau funktionsfähig.
Die Eingänge der Pendel-Lichtschranke und des "PPS" (= Puls pro Sekunde) vom GPS-Empfänger werden mittels Interruptroutinen überwacht. Dies ergibt deutlich zuverlässigere Werte als bei einer Abfrage der Eingänge innerhalb der normalen Programmschleife loop().
Dabei habe ich etwas Ungewöhnliches festgestellt: Obwohl beide Eingänge durch identische Interuptroutinen bearbeitet werden, ist der gemessene Zeitintervall an einem der beiden Eingänge stets 128 Mikrosekunden länger, als am anderen Eingang. Dieser Fehler ergibt sich nicht dadurch, dass beide Eingänge beispielsweise gerade zum selben Zeitpunkt ein Signal erhalten. Er ist immer konstant und kann somit bei der Messwertverarbeitung berücksichtigt werden.
Ich wurde darauf hingewiesen, dass der Prozessortakt im Arduino MEGA nicht mit einem Schwingquarz, sondern mit einem sogenannten "Resonator" gebildet wird. Sowohl Quarz als auch Resonator werden mittels des (umgekehrten) piezoelektrischen Effekts in Eigenschwingung gebracht. Trotzdem ist die Frequenzstabilität und Wärmebeeinflussung bei beiden Bauelementen unterschiedlich groß. Normalerweise bietet ein Schwingquarz eine geringere Frequenzdrift bei Temperaturänderungen.
Zum Vergleich habe ich mit dem Arduino eine Tonfrequenz von 10 kHz erzeugt und diese mit einem digitalen Frequenzzähler gemessen. Solange noch der Resonator verbaut war, ergab sich eine Frequenz von 9.994,9 Hz. Das entspricht einem Fehler von 510 ppm.
Nach der Umrüstung des Controllers auf eine Takterzeugung mit einem Schwingquarz war laut Frequenzmesser die gemessene Tonfrequenz 10.000,1 Hz, hatte also nur noch 10 ppm Abweichung.
Durch den Vergleich mit dem PPS konnte ich schließlich einen Frequenzfehler des Controllers von 7,5 bis 8 ppm ermitteln. Dieser entspricht einem Fehler von 69 ms pro Tag, also rund zweier Sekunden pro Monat.
Doch auch der Schwingquarz wird bei einer Temperaturänderung seine Eigenfrequenz geringfügig verändern. Die gemessene Pendelfrequenz würde dadurch einen Temperatureinfluss erfahren, der gar nicht durch die Uhr und ihr Pendel verursacht wird. Da aber der PPS-Intervall ununterbrochen erfasst wird, kann die Abweichung der Controllerfrequenz von ihrem Sollwert ständig errechnet und bei der Messung der Pendelfrequenz berücksichtigt werden.
Während das Speichern von Messdaten auf der SD-Karte bereits grundsätzlich funktioniert, bin ich gerade dabei, Log-Dateien mit chronologisch geänderten Dateinamen zu verwalten. Dies soll verhindern, das nach der dem Wiedereinsetzen der Speicherkarte oder nach einem Ausfall der Spannungsversorgung eine vorhandene Datei überschrieben wird.
Es ist geschafft! Der Datenlogger RDL-25 ist fertig.
Für seine Entwicklung (Programmierung, Platinen-Layout) und mechanische Fertigstellung habe ich fast 1000 Arbeitsstunden absolviert. Wie ich es schon vor mehreren Jahren erahnte, ist das Gerät eigentlich ein eigenes Projekt innerhalb meines "PPU"-Projektes geworden.
In der Anfangsphase, als ich die Programme für einzelne Komponenten (Anzeige, Sensor, SD-Karte, DCF-Dekodierung, GPS-Dekodierung) zu einem Steuerprogramm zusammenfassen musste, ging einiges schief: - Eine Library zur Verwendung von SD-Karten als Datenspeicher funktionierte stets nur für einen Schreib- oder Lesevorgang. Dann musste man die Karte entfernen und erneut einstecken. Ein Mitglied dieses Forums empfahl mir daraufhin, eine bestimmte, ziemlich alte Version dieser Library zu verwenden und dann funktionierte die SD-Karte auch mehrmals. - Beispielsweise vertrugen sich einige Bibliotheksprogramme, die sog. "Libraries" nicht miteinander, so dass ich diese verändern musste. - Für die DCF-Dekodierung nutzte ein Programm von H.-J. Berndt, das ich noch um einige Funktionen erweiterte. - Für die Behandlung von Dateinamen (gültige Schreibweise, Versionnummern) schrieb ich eine eigene Library.
Der gesamte vor mir geschriebene C-Code enthält rund 4000 Programmzeilen, einschließlich rund 30 Prozent optional aktivierbarer Zeilen für die Ausgabe von Testinformationen auf den PC-Bildschirm, die bei der Fehlersuche helfen sollen.
Die Beschaffung eines geeigneten Gehäuses für den Datenlogger stellte sich mir als unlösbares Problem dar. Ich suchte ein Kunststoffgehäuse, das etwa die Abmessungen eines großen Multimeters hatte. Im Web fand ich aber letztendlich bei vielen Anbietern immer den selben Typ mit den Maßen 200 x 120 x 75 mm, viel zu hoch für meinen Zweck.
Also legte ich selbst Hand an und brachte ein vorhandenes Gehäuse dieser Art auf die von mir gewünschte Höhe.
Träger aller Einzelteile ist eine Lochraster-Platine mit GFK-Kern. Das Anordnen der Bauteile auf ihr war ein Geduldsspiel, wie es dieses Bild ahnen lässt, denn unter den sichtbaren Platinen und dem LC-Display befinden sich weitere Bauteile.
Auch die örtliche Verteilung der Drahtbrücken kostete einige Zeit. Aus Platzgründen (Höhe) wollte ich Kreuzungen von Brücken vermeiden. So ergab sich schließlich ein Layout, mit dem man eine echte doppelseitige Printplatine fertigen könnte.
In einem Beitrag in diesem Forum hatte ich etwas über Decal-Folien gelesen und mir solche beschafft, um damit die Beschriftungen auf dem Gehäuse zu gestalten. Es hat mich etliche Probedrucke gekostet, bis der Ausdruck die von mir gewünschten Maße hatte, die sich durch den Abstand der LED-Löcher ergaben.
Doch all diese Mühe war umsonst, denn die Folie ist durch das Einweichen (nur 15 bis 30 Sekunden!) um 6,6 % gewachsen. Zudem ist ihre Haftung auf der glatten ABS-Oberfläche nur gering. Das Fixieren mit Zaponlack sorgt wenigstens für einen gewissen Schutz der Oberfläche und der Kanten der Folie.
Für die Peripheriegeräte des Datenloggers, also Lichtschranke, Temperatur-/Drucksensor und GPS-DCF-Konverter, habe ich unterschiedliche DIN-Buchsen eingesetzt, damit eine Verwechslung der Anschlussleitungen ausgeschlossen ist.
Da ich weiß, dass ich mich nach einigen Monaten wahrscheinlich nicht mehr genau an Details zur Technik und Programmierung meines Datenloggers erinnern kann, habe ich in der vergangenen Woche auch ein Handbuch dazu verfasst.
Einige Features des Gerätes: - Spannungsversorgung über USB oder Stecker-Netzteil 7,5 V. - Arduino MEGA 2560 als Controller, 16 MHz-Schwingquarz für Systemtakt nachgerüstet. - LC-Textdisplay mit 4 Zeilen x 20 Zeichen, angesteuert mit I2C, Hintergrund beleuchtet. - Drei LCD-Zeilen werden für Statusanzeigen genutzt. Es sind mehrere solcher Ansichten auswählbar, u.a. + "Controller": mit Höhe der Systemspannungen und der Spannungsversorgung + "SD-Karte": Kapazität der Karte, aktuelle Größe der Logdatei + "Datum+Zeit": Zeiten von Controller, DCF, GPS, überwachte Uhr + "Umwelt": Temperatur, Luftdruck, rel. Luftfeuchte + "Pendel": Halbschwingungsdauer, Amplitude, täglicher Gang - Dreht-/Tastknopf als Bedienelement und Eingabegerät. - Einfarbige LEDs zur Anzeige empfangener Pulse von Lichtschranke, DCF und GPS. - Mehrfarb-LED signalisiert Zustände der SD-Karte (fehlt/gefunden/angemeldet/Fehler). - Interner GPS-Empfänger, externer GPS-Empfänger anschließbar. - Der Intervall der Datenaufzeichnung ist einstellbar von 10 bis 9999 Sekunden, Standard: 600. - Das Programm kontrolliert in regelmäßgen Zeitabständen, ob die SD-Karte noch vorhanden und benutzbar ist. - Aufzeichnung von Datum, Zeit und Messdaten erfolgt in eine CSV-Textdatei auf eine SD-Speicherkarte. - Sollte nach dem Starten der automatischen Datenaufzeichnung der Ausfall der SD-Karte auftreten, schreibt das Programm bis zu 14 Datensätze in einen RAM-Puffer und kopiert dessen Inhalt nach dem Wiedererkennen einer Karte auf diese. Es ist somit möglich, zeitweilig die Karte auszulesen oder auszuwechseln. - Die Systemzeit lässt sich wahlweise manuell eingeben oder mittels DCF-Signal automatisch einstellen. - Die für Messzwecke zeitkritischen Signale von Lichtschranke, DCF-Empfänger, GPS-Empfänger (intern) und GPS-Empfänger (extern) werden von Interrupt-Eingängen des Controllers überwacht. Dies minimiert die Fehler von Zeitmessungen auf wenige Mikrosekunden. Für die Aufzeichnung von Messwerten wird jeweils ein gleitender Durchschnittswert verwendet. Dadurch verringert sich der Einfluss von Kurzzeitfehlern. - Stehen DCF- oder GPS-Pulse zur Verfügung, vergleicht der Controller diese mit seinem vom Systemtakt abhängigen Sekundenpuls. Der daraus errechnete Korrekturwert wird zur Fehlerkompensation bei den Zeitmessungen für die Lichtschranken-Impulse verwendet und in längeren Zeitabständen im EEPROM gespeichert. Somit kann der Korrekturwert (mit eingeschränkter Genauigkeit) auch dann zur Fehlerkompensation dienen, wenn zeitweilig weder DCF- noch GPS-Impulse vorhanden sind.
Der Datenrecorder ist seit heute im ständigen Einsatz. Endlich habe ich nun vielleicht auch mal wieder Zeit, mich mit Uhren zu befassen.
Zitat von Enno im Beitrag #424Für seine Entwicklung (Programmierung, Platinen-Layout) und mechanische Fertigstellung habe ich fast 1000 Arbeitsstunden absolviert
Also bei Ansatz des Mindestlohns hätte es Dich ca. 14000 gekostet? Da wäre Willys ausentwickelter Datenlogger ja das totale Schnäppchen gewesen…
Aber ich weiss natürlich, Erfahrungsgewinn und maßgeschneidertes Selbermachen sind unbezahlbar 😉
Gruß, Frank ______________ Fliegeruhren - Hanhart Vintage Service PCZW - PC Zeitwaage der Profis
Heute habe ich die ersten Messwerte ausgelesen und mit einer Tabellenkalkulation grafisch dargestellt. Dies ist die Ampltitude:
Die starken Schwankungen hatte ich ja bereits bei der manuellen Messwerterfassung gesehen. Die Nachbearbeitung einiger Klemmstellen hatte zwar etwas Besserung gebracht, konnte die eigentlichen Probleme nicht beheben, die sich aus meinem mechanischen Konzept und meinen Fertigungstoleranzen ergaben.
Hier habe ich Teile der oberen Kurve übereinander kopiert. Dabei ist zu erkennen, dass es Ähnlichkeiten nach jeweils 13 bzw. 26 Stunden gibt:
Für den visuellen Vergleich habe ich alle Messwerte normiert, also auf Beträge um 1 gebracht. Das nächste Diagramm zeigt die normierten Werte von Halbschwingungsdauer und Pendelamplitude, die von 31.1.2026 23:30 bis 3.2.2026 9:30 gemessen wurden.
Es zeigt sehr deutlich, dass bei einem realen Pendel die Pendelfrequenz auch von der Amplitude abhängt. Da werde ich, wenn die Temperaturen es wieder zulassen, verschieden starke Pendelfedern austesten.
Zitat von Enno im Beitrag #427 Die starken Schwankungen hatte ich ja bereits bei der manuellen Messwerterfassung gesehen. Die Nachbearbeitung einiger Klemmstellen hatte zwar etwas Besserung gebracht, konnte die eigentlichen Probleme nicht beheben, die sich aus meinem mechanischen Konzept und meinen Fertigungstoleranzen ergaben.
Hmm ... es war abzusehen. Evolventenverzahnung und auch noch auf Taschenuhrniveau ... Winzige Amplitude und Ankerhemmung, aber das ist vergossenene Milch. Und da der Fehler prinzipieller Natur ist, kannst Du auch nichts dagegen machen, es ist nicht Deine "mangelnde Präzision". Es ist ein quasi religiöses Problem.
Zitat Es zeigt sehr deutlich, dass bei einem realen Pendel die Pendelfrequenz auch von der Amplitude abhängt. Da werde ich, wenn die Temperaturen es wieder zulassen, verschieden starke Pendelfedern austesten.
Also Du hast da eine ganze Reihe Fehler die lustig miteinander wechselwirken. Der "Allgemeine Pendelfehler" reagiert auf Amplitude und Geschwindigkeit, der Kreisbogenfehler auf die Amplitude, Der Hemmungsfehler reagiert auf das Antriebsdrehmoment und die Amplitude, und auch noch die Aerodynamischen Fehler, die auch noch mit der Geschwindigkeit der Amplitude und dem Luftdruck wechselwirken.
Die Probleme kommen zu ~60% aus Verzahnung und Lagerung, und zu ~35% aus der Hemmung, und deren prinzipbedingten Mängeln. Das hat nichts mit der Pendelfeder zu tun. Und Du kannst mit Deiner Zeitwaage, die Amplitude, garnicht messen. Aus der Geschwindigkeit im Lot, darauf zu schliessen, ist im Anbetracht der Probleme, vorsichtig ausgedrückt abenteuerlich. Auch die Drehmomentprobleme kannst Du nicht messen, obendrein steht auf der Abweichung nicht drauf, wer gerade sie verursacht hat, und mit was es sonst noch vermischt wurde.
Ermittele langlaufende Durchschnittsraten, für Zeit und Temperatur und korigiere die Pendellänge und Kompensation dementsprechend. Und lebe damit. Werde nicht zum Dauerregulator, der jeden Tag die Zeitwaage ablesen muss um den Pendelteller zu füttern. Und opfere nicht noch mehr Zeit. Du hast ein wirklich schönes Teil gebaut, und viel dabei gelernt. Es ist Zeit loszulassen, vielleicht findest Du einen Liebhaber,damit wenigstens das Material reinkommt und sowas ein 1Eurojob für Deinen Fleiß und die vielen Stunden.
Ach, das Zykloidenpendel nach Huygens... So bestechend es mathematisch auch ist, praktisch ist es wenig brauchbar: Die Krümmung der Zykloiden ist im obersten Punkt unendlich, d.h. die Pendelfeder würde dort geknickt und hätte vermutlich keine lange Lebensdauer. Macht man die Feder aber so stark, dass sie wie bei einer gewöhnlichen Pendelfeder nicht geknickt wird, läge sie nicht mehr an den Zykloiden an. Nicht von ungefähr wird das Experiment mit einem Faden ausgeführt. Praktikabel mit einer Feder hingegen wären kreisbogenförmige Backen nach Harrison, diese schützen zum einen die Feder, können zum anderen im Radius so gewählt werden, dass der dadurch gestaltbar gewordene Amplitudenfehler den barometrischen Fehler gegenkompensiert. Aber das ist eine andere, sehr lange Diskussion, die wir schon öfters in anderen Threads hatten und meines Erachtens hier nicht hergehört. Wenn ich Ennos Graphen richtig interpretiere, sehen wir dort zyklische Amplitudenschwankungen um etwa 20%(?), die aus dem Räderwerk zu stammen scheinen. Da braucht man mit barometrischer Kompensation wohl leider gar nicht zu beginnen.
Zitat von praezis im Beitrag #431Ennos letztes Diagramm (Ampl+ SchwgDauer/2) ist interessant. Erstmal habe ich selten derart spiegelbildlich kongruente Kurven beider Messwerte gesehen, kaum zu glauben. Zum zweiten scheint das Pendel mit steigender Amplitude schneller zu werden - Respekt. Frank
Das Ergebnis hat mich zunächst auch überrascht. Darum habe ich noch einmal beide Messgrößen ungeglättet übereinander gelegt, doch es bleibt dabei: Die Frequenz wächst mit steigender Amplitude:
Meine Vermutung ist, dass dies an der Haldiman-Hemmung liegt: Der Anker wird ja in beiden Richtungen von Justierschrauben gestoppt. Beim Weiterschwingen spannt das Pendel die Koppelfeder, also den äußeren Teil der Pendelfeder-Baugruppe. Das sorgt für ein Rückstellmoment, das mit der Amplitude wächst.
Zitat von Enno im Beitrag #433 Meine Vermutung ist, dass dies an der Haldiman-Hemmung liegt: Der Anker wird ja in beiden Richtungen von Justierschrauben gestoppt. Beim Weiterschwingen spannt das Pendel die Koppelfeder, also den äußeren Teil der Pendelfeder-Baugruppe. Das sorgt für ein Rückstellmoment, das mit der Amplitude wächst.
Da kann man lustig rumspekulieren. Der Hauptfehler sind die 25% erratischen Drehmomentfehler aus Deinem Räderwerk, und deren Wiederspiegelung in der Hemmung, bzw deren bauartbedingten Fehlern.
Die Feder wirkt wie etwas mehr Schwerkraft weiter nichts.
Deine Uhr ist in etwa so gut wie das Teil das Du Dir als Vorbild auserkoren hast. Lerne was daraus und baue eine neue, bessere Uhr. Frag mal den Moritz, der weiss wie es geht, Du weist nun wie es nicht geht. Ist auch eine ganz wichtige Erkenntnis.
dass die Uhr bei antriebsbedingt steigender Amplitude schneller wird, wundert mich nicht und ist bei meiner aktuellen Grasshopper-PU bis mindestens 4° Amplitude genauso. Bei Deiner Uhr sollte auch fallende Luftdichte zu steigender Amplitude und trotzdem schnellerer Uhr führen. Erst ab etwa 3,5° Amplitude ist bei der Luftdichte eine Umkehrung des Effekts zu erwarten. Andererseits liegen mir Messwerte an einer Tankuhr (konstante Dichte) mit einer Schwerkrafthemmung (Riefler-Nachbau) vor, die bei bei steigender Amplitude ein Nachgehen der Uhr zeigen. Auch da könnte man argumentieren, dass die Schwerkraft-Hebelchen wie zusätzliche Schwerkraft wirken, was sich aber eben nicht zeigt. Von daher ist Matthias' Beitrag zu einfach gedacht.
Zitat von Enno im Beitrag #427... Hier habe ich Teile der oberen Kurve übereinander kopiert. Dabei ist zu erkennen, dass es Ähnlichkeiten nach jeweils 13 bzw. 26 Stunden gibt: ...
So richtig überzeugend finde ich das noch nicht. Evtl. könntest Du eine Fourier-Analyse versuchen? Dafür sollte es doch im Netz Tools geben und Excel kann das wohl auch. Mein Tipp ist aber eher alle Rad-Trieb-Paarungen auf mindestens 0,05, eher 0,1 mm Spiel zu untersuchen und das ggf. durch Nacharbeit zu erreichen.
Kontakt
Moderatoren
Foren-Regeln
Links
Xobor-Interview
Uhrenwerkstattforum
Thema drucken
15.10.2025 18:05
Antworten
