Bin sehr gespannt wann du selber auf den Trichter kommst, dass jeden Pendelausschlag zu loggen die bessere Methode ist.
Das wäre nur sinnvoll, wenn man den Zeitpunkt des Pendeldurchgangs 300 mal so genau messen könnte.
Bin sehr gespannt wann du selber auf den Trichter kommst, dass jeden Pendelausschlag zu loggen die bessere Methode ist.
Die Frage ist, wann die Knalltüte auf den Trichter kommt, daß sie nichts zum Thema beiträgt.
Die Daten dieser Nacht:
Aktuell ist noch ein recht konstanter Nachgang von
4 Hundertstel-Sekunden in 5 Minuten.
Muss ich mal besser regulieren.
Das ist bei so einer Pendeluhr nicht ganz einfach.
Mit der Reguliermutter sind noch die Hundertstel-Sekunden
möglich.
Dazu muss aber das Pendel angehalten werden. Dann braucht
es 1-2 Stunden zum Einschwingen.
Beim Auflegen oder Wegnehmen von Gewichten muss ich das Pendel
nicht anhalten, aber auch hier entsteht erstmal eine messbare Störung.
Grüße Bernd
:
Bearbeitet durch User
gegen 01:10 Uhr ist der Counter für die Mikrosekunden übergelaufen.
:
Bearbeitet durch User
gegen 01:10 Uhr ist der Counter für die Mikrosekunden übergelaufen.
Wo kommt dieser merkwürdiger Wert her, bei dem der Zähler überläuft?
Mit dem Zahlenbereich einer Ganzzahl-Variablen passt das nicht zusammen.
Ich denke, das wird vom Systemzähler der Mikrosekunden zählt abgeleitet sein. Und der läuft irgendwann über. In Micropython gibt es dafür die Funktion time.ticks_diff(t1, t2) welche die Differenz auch dann richtig ausrechnet, wenn der Zähler übergelaufen ist. Ich verstehe nichts von Arduino-Sprech (C++) und weiss nicht, ob es das da auch gibt.
https://docs.micropython.org/en/latest/library/time.html#time.ticks_diff
:
Bearbeitet durch User
Ich denke, das wird vom Systemzähler der Mikrosekunden zählt abgeleitet sein.
Ein Mikrosekundenzähler kann es nicht sein, der da überläuft. Dieser Überlauf muss durch die Software entstehen. Ein binärer Zähler läuft nicht bei 1.000.000 über.
Aktuell ist noch ein recht konstanter Nachgang von 4 Hundertstel-Sekunden in 5 Minuten.
Ich sehe aus den Daten zwischen 19h und 4h, d.h. in dem Bereich mit konstantem Gang, einen zehnfach kleineren Gangfehler von 4,3 Tausenstel Sekunden in 5 Minuten (also 5,1cs/h oder 1,23s/d).
:
Bearbeitet durch User
Ein Mikrosekundenzähler kann es nicht sein, der da überläuft. Dieser Überlauf muss durch die Software entstehen. Ein binärer Zähler läuft nicht bei 1.000.000 über.
Ein Systemzähler (also Hardware) kann sehr wohl überlaufen. 1 Mio ist natürlich zu wenig für Mikrosekunden, deswegen schrieb ich ja auch "abgeleitet", also vermutlich eine Differenz zwischen 2 Systemticks.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
Was ist an dem Überlauf so schwer zu verstehen? Da wird der Abstand zwischen 1PPS Impuls und dem Pendeldurchgang berechnet, der kann maximal 1 Sekunde groß sein. Ein kurzer Blick in den Source Code genügt. Wenn die Pendelschwingung nicht exakt zum 1PPS Impuls passt gibt es einen Über-/Unterlauf.
Ein Systemzähler (also Hardware) kann sehr wohl überlaufen.
Natürlich kann der Überlaufen, aber nicht bei 1.000.000.
In Micropython gibt es dafür die Funktion time.ticks_diff(t1, t2) welche die Differenz auch dann richtig ausrechnet, wenn der Zähler übergelaufen ist. Ich verstehe nichts von Arduino-Sprech (C++) und weiss nicht, ob es das da auch gibt.
Einen Überlauf bei einer Differenz korrekt zu berücksichtigen, ist nun wirklich kein Hexenwerk. Bei echten Überläufen von Binärzählern müsste man sogar genau gar nicht eingreifen, um korrekte Differenzen zu erhalten.
Nur so ein Überlauf bei 1.000.000 erfordert eine Zeile Software in C++. Das ist kaum mehr als dein Python-Aufruf, nur denken müsste man selber. Die Software auf dem µC von Bernd ist C++, nicht Python.
Was ist an dem Überlauf so schwer zu verstehen?
Es ist also gar kein Zählerüberlauf - gut beobachtet.
Der Pendeldurchgang erfolgt ledig nicht knapp 1s nach dem 1PPS-Puls, sondern einen 1PPS-Puls später.
:
Bearbeitet durch User
Im Sourcecode finde ich folgende Zeilen:
1 |
|
2 |
|
3 |
|
4 |
|
und micros() ist eine Systemzeit, die überlaufen kann.
https://docs.arduino.cc/language-reference/de/en/functions/time/micros/
Im Sourcecode finde ich folgende Zeilen:
// Nur beim exakt 1800. Impuls frieren wir die Zeiten ein
if (gesamtImpulsZaehler % SPEICHER_INTERVALL_IMPULSE == 0) {
eventMicros = micros();
eventPpsRef = ppsMicrosRef;
und micros() ist eine Systemzeit, die überlaufen kann. https://docs.arduino.cc/language-reference/de/en/functions/time/micros/
micros()
Gibt die Anzahl der Mikrosekunden zurück, die seit dem Start des aktuellen Programms auf dem Arduino-Board vergangen sind. Dieser Wert läuft nach etwa 70 Minuten über (springt zurück auf null).
Diese Zeitfunktion bietet verschiedene Auflösungen, die mit unterschiedlichen Arduino-Produktfamilien kompatibel sind. Syntax
Du kannst ja sogar abschreiben und einen Übersetzer bedienen: TOLL!
:
Bearbeitet durch User
Bitte nicht aufregen.
Das Endergebnis meiner Bemühungen sieht später so aus:
Grüße Bernd
Angehängte Dateien:
und micros() ist eine Systemzeit, die überlaufen kann.
Du kannst aufhören, zu suchen.
In den Daten gibt es um 01:10 gar keinen Überlauf von irgendeinem Mikrosekundenzähler. Die Spalte gibt die Anzahl der Mikrosekunden-Ticks zwischen dem letzten 1PPS-Puls vor dem Pendeldurchgang und dem Pendeldurchgang an. Das ist ein Messwert, keine Zeitskala. Man weiß also gar nicht, wie groß der Sprung ist, weil die Mikrosekunden-Ticks nicht exakt im 1µs-Abstand kommen, sondern der Abstand von der exakten Quarz-/Resonatorfrequenz auf dem µC-Board abhängt. Vielleicht sollte man die besser mit messen.
:
Bearbeitet durch User
Der Datenlogger hat den Sekundenimpuls über seinen eingebauten
Gps-Empfänger.
In der Zwischenzeit wird wohl auf eine interne Uhr zurückgegriffen.
Grüße Bernd
In der Zwischenzeit wird wohl auf eine interne Uhr zurückgegriffen.
Eben - und die interne Uhr ist bestenfalls nur so genau, wie der Quarz bzw. der Resonator auf dem µC-Board, hat aber bestimmt nicht Atomuhrgenauigkeit, wie der 1PPS-Puls des GPS.
Bernd F. schrieb:
In der Zwischenzeit wird wohl auf eine interne Uhr zurückgegriffen.
Eben - und die interne Uhr ist bestenfalls nur so genau, wie der Quarz bzw. der Resonator auf dem µC-Board, hat aber bestimmt nicht Atomuhrgenauigkeit, wie der 1PPS-Puls des GPS.
Damit werde ich leben müssen.
Es geht ja eigentlich um Messungen über Wochen/ Monate.
Messungen in kurzen Intervallen sind für gewisse Einstell-
arbeiten recht praktisch, aber nicht das Ziel des Loggers.
Grüße Bernd
:
Bearbeitet durch User
Die Spalte gibt die Anzahl der Mikrosekunden-Ticks zwischen dem letzten 1PPS-Puls vor dem Pendeldurchgang und dem Pendeldurchgang an. Das ist ein Messwert, keine Zeitskala. Man weiß also gar nicht, wie groß der Sprung ist, weil die Mikrosekunden-Ticks nicht exakt im 1µs-Abstand kommen, sondern der Abstand von der exakten Quarz-/Resonatorfrequenz auf dem µC-Board abhängt.
Und da kommt ein Sprung von nahezu 1.000.000 Mikrosekunden vor, also 1 Sekunde?
Schau Dir mal die Werte und die Grafik an https://www.mikrocontroller.net/attachment/706866/DATENLOG_13.10.txt die Micros beginnen um 17:17 Uhr bei 598086, diese steigen kontinuierlich nahzu linear auf nahe zu 10^6 an und fallen um ca 01:10 Uhr auf nahezu 0, wie ist denn das erklärbar? Da muss ein Überlauf o.ä. die Ursache sein zumal Arduino in seiner Spezifikation selbst angibt, dass micros() überlaufen kann.
Angehängte Dateien:
-
bernd2_micros.png
(21 KB)
:
Bearbeitet durch User
Und da kommt ein Sprung von nahezu 1.000.000 Mikrosekunden vor, also 1 Sekunde?
Nu mecker nich', dass stammt von einer KI. Da muss es so richtig sein. ;-)
Hätte man elegant im µC lösen können, so muss man in der Nachbearbeitung auf die jeweilige Differenz zum Vorwert schauen. Ist sie größer als 500ms, dann eine 1e6µs subtrahieren. Und da es ja auch um den 0 Wert fluktuieren kann, dann auch noch den anderen Fall testen und gegebenenfalls 1e6µs addieren. Ganz einfach und gradlinig.
Ich bin doch "nur" der Mechaniker.
Ein besserers Programm? Nur zu.
Das Teil macht das, was ich brauche. Eine bessere Version ist
gleich aufgespielt.
Grüße Bernd
Ein besserers Programm? Nur zu.
Ne, ne, lass mal. Ich baue das morgen in die Import Routine ein.
Und da kommt ein Sprung von nahezu 1.000.000 Mikrosekunden vor, also 1 Sekunde?
Ja, in einer Sekunde tickt der Mikrosekundenzähler des Arduino etwas 1.000.000 mal.
Schau Dir mal die Werte und die Grafik an https://www.mikrocontroller.net/attachment/706866/DATENLOG_13.10.txt die Micros beginnen um 17:17 Uhr bei 598086, diese steigen kontinuierlich nahzu linear auf nahe zu 10^6 an und fallen um ca 01:10 Uhr auf nahezu 0, wie ist denn das erklärbar?
Schrieb ich doch oben.
In den Daten gibt es um 01:10 gar keinen Überlauf ...
Dass die Wert kontinuierlich steigen, liegt daran, dass die Uhr von Bernd aktuell noch etwas zu langsam läuft, eben um die besagten 4ms pro 5 Minuten.
Da muss ein Überlauf o.ä. die Ursache sein zumal Arduino in seiner Spezifikation selbst angibt, dass micros() überlaufen kann.
Nein, der Sprung in den Mikrosekunden-Messdaten tritt immer dann auf, wenn der 1PPS-Puls das Pendel überholt, d.h. wenn zwischen zwei Pendeldurchgängen zwei 1PPS-Pulse liegen. Mit der micros()-Funktion hat das nichts zu tun.
Ist sie größer als 500ms, dann eine 1e6µs subtrahieren.
Nein, das ist falsch. Du weißt gar nicht, wieviel Mikrosekunden-Ticks innerhalb einer Sekunde kommen. Alles, was man ohne Messung weiß, ist, dass es im Rahmen der Quarz-/Resonatorgenauigkeit UNGEFÄHR 1E6 sind. Wenn du stur 1e6µs subtrahierst, erzeugst du einen Ausreißer, weil du die genaue Zahl nicht kennst.
@Bernd
Du solltest in deinem Programm nicht nur den Abstand zwischen 1PPS-Puls und Pendeldurchgang messen, sondern auch den Abstand zwischen zwei 1PPS-Pulsen.
Oder man ignoriert den Wert einfach. Für die Statistik spielt ein einzelner Wert keine Rolle.
:
Bearbeitet durch User
Nein, das ist falsch. Du weißt gar nicht, wieviel Mikrosekunden-Ticks innerhalb einer Sekunde kommen.
Ich rede von der Differenz. Die ist 0 wenn die Uhr präzise geht. Ansonsten eine geringe µs Abweichung im positiven oder negativen Bereich. Wenn also die Differenz mehr als +/-500ms pro Sekunde beträgt, darf man getrost von einem wrap around ausgehen.
:
Bearbeitet durch User
Ich rede von der Differenz. Die ist 0 wenn die Uhr präzise geht.
Die Uhr geht aber nicht präzise, sondern zu langsam. Deshalb liegt zwischen zwei Pendeldurchgängen mehr als eine Sekunde, so dass sich die 1PPS-Pulse gegenüber dem Durchgang verschieben. Dadurch kann es vorkommen, dass zwischen zwei Pendeldurchgängen mehr als ein 1PPS-Puls liegt. Das ist gegen 01:10 der Fall.
(im Pulsdiagramm übertrieben dargestellt)
Wenn also die Differenz mehr als +/-500ms pro Sekunde beträgt, darf man getrost von einem wrap around ausgehen.
Da wrapt nichts around. Es wird einfach die zeitliche Differenz zum falschen 1PPS-Puls gemessen. Die Anzahl der Mikrosekunden-Ticks zwischen zwei 1PPS-Pulsen kennt man leider nur ungefähr, so das eine Korrektur um 1000000 Ticks etwas willkürlich wäre.
Angehängte Dateien:
-
Zeitdiff_1PPS_Pendel.png
(2,9 KB)
:
Bearbeitet durch User
Ja Rainer, das ist schon seltsam. Denn hier funktioniert es bereits.
Ja Rainer, das ist schon seltsam. Denn hier funktioniert es bereits.
Was findest du seltsam und was ist "es"?
Woher bekommst du den richtigen Wert zur Korrektur des Differenzwertes?
:
Bearbeitet durch User
Man kann natürlich auf dem Standpunkt stehen, dass man bei einer Standardabweichung der Messwerte für den Gang von knapp 100µs über 5 Minuten mit dem nominellen Wert für die Mikrosekunden-Ticks rechnen kann. Bei einem Keramikresonator auf dem Arduino-Board läge die zu erwartende Genauigkeit etwa in dieser Größenordnung.
Da es aber wenig Aufwand ist, sollte es nicht schaden, einmal nachzumessen.
Angehängte Dateien:
:
Bearbeitet durch User
Wenn ich mich nicht vertan haben…
Sieht schon verdammt gut aus!
Angehängte Dateien:
-
output.png
(140 KB)
:
Bearbeitet durch User
Sieht schon verdammt gut aus!
Wenn man nicht nur die Zeitserien darstellt, sondern den Gang über die Temperatur auswertet, sieht man das am Korrelationskoeffizienten von R²=0,00. Die Temperaturabhängigkeit geht im Messrauschen für den Pendeldurchgang unter.
(in der Graphik Daten zwischen 19h und 6h)
Angehängte Dateien:
:
Bearbeitet durch User
Hat jemand eine Erklärung dafür, warum die Kurve DATENLOG_13.10_Diff_Mikrosekunden.png auch am Ende nach unten geht? Am Anfang kann das Einschwingen des Pendels sein, aber am Ende?
Hat jemand eine Erklärung dafür, warum die Kurve DATENLOG_13.10_Diff_Mikrosekunden.png auch am Ende nach unten geht? Am Anfang kann das Einschwingen des Pendels sein, aber am Ende?
Das passiert bei einem recht steilen Temperaturanstieg. Nur eine Mutmaßung, aber vielleicht erwärmen sich die Teile mit positivem und negativem Ausdehnungskoeffizienten unterschiedlich schnell?
Stephan S. schrieb:
Hat jemand eine Erklärung dafür, warum die Kurve DATENLOG_13.10_Diff_Mikrosekunden.png auch am Ende nach unten geht? Am Anfang kann das Einschwingen des Pendels sein, aber am Ende?
Das passiert bei einem recht steilen Temperaturanstieg. Nur eine Mutmaßung, aber vielleicht erwärmen sich die Teile mit positivem und negativem Ausdehnungskoeffizienten unterschiedlich schnell?
Die Vermutung habe ich auch.
Ich werde mal das Aluröhrchen mit Bohrungen/Schlitzen versehen,
damit der innere Stahlstift nicht so abgeschottet ist.
Anbei noch eine grobe Excel-Grafik.
Von der geraden Linie bin ich noch etwas weg.
Aber: Völlig auf Null soll das Pendel gar nicht sein.
Der alte Harrison sagt: "Kürzer, wenn warm". Warum? Bei Hochdrucklage gibt es auch hohe Luftdichte, die bremst. Hoher Luftdruck bedeutet auch meist hohe Temperaturen.
Da kann man dann etwas gegenarbeiten, wenn das Pendel etwas schneller wird.
Grüße Bernd
Angehängte Dateien:
-
log_14.10.png
(23 KB)
Norbert schrieb:
Stephan S. schrieb:
Hat jemand eine Erklärung dafür, warum die Kurve DATENLOG_13.10_Diff_Mikrosekunden.png auch am Ende nach unten geht? Am Anfang kann das Einschwingen des Pendels sein, aber am Ende?
Das passiert bei einem recht steilen Temperaturanstieg. Nur eine Mutmaßung, aber vielleicht erwärmen sich die Teile mit positivem und negativem Ausdehnungskoeffizienten unterschiedlich schnell?
Die Vermutung habe ich auch. Ich werde mal das Aluröhrchen mit Bohrungen/Schlitzen versehen, damit der innere Stahlstift nicht so abgeschottet ist. Anbei noch eine grobe Excel-Grafik. Von der geraden Linie bin ich noch etwas weg. Aber: Völlig auf Null soll das Pendel gar nicht sein. Der alte Harrison sagt: "Kürzer, wenn warm". Warum? Bei Hochdrucklage gibt es auch hohe Luftdichte, die bremst. Hoher Luftdruck bedeutet auch meist hohe Temperaturen. Da kann man dann etwas gegenarbeiten, wenn das Pendel etwas schneller wird. Grüße Bernd
Nun, als Schlosser solltest du dich mit Bemaßungen auskennen. Ich sehe hier drei Linien, keine ist beschriftet... hmmm. Ein wenig mehr Sorgfalt solltest du dir aneignen. Ich sage nur, hingerotzt!
Ein Mikrosekundenzähler kann es nicht sein, der da überläuft. Dieser Überlauf muss durch die Software entstehen. Ein binärer Zähler läuft nicht bei 1.000.000 über.
Nö das tut er tatsächlich nicht. Der angezeigte Wert ist halt der Wert nach dem Überlauf. Allerdings läßt sich der Überlauf einfach herausrechnen. Dazu muß man erstmal feststellen, ob ein Überlauf stattgefunden hat. Das geht relativ einfach, wenn man sich den letzten Counterwert merkt und die Differenz aus aktuellem Wert und dem letzen Wert bildet. Wenn dieser kleiner 0 ist, dann ist der Zähler übergelaufen. Da man den Punkt kennt wann der Counter überläuft, könnte man sich den aktuellen Zählerstand berechnen bzw. die Differenz zwischen den Zählerständen berechnen.
Ich würde gleich die Differenzen der Zählerstände speichern.
Codesnippet:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
:
Bearbeitet durch User
Schau Dir mal die Werte und die Grafik an https://www.mikrocontroller.net/attachment/706866/DATENLOG_13.10.txt die Micros beginnen um 17:17 Uhr bei 598086, diese steigen kontinuierlich nahzu linear auf nahe zu 10^6 an und fallen um ca 01:10 Uhr auf nahezu 0
Weil der Counter halt übergelaufen ist und der Bernd das in seinem Code nich abfängt.
Gerade gesehen der Bernd speichert ja die Differenz.
Allerdings läßt sich der Überlauf einfach herausrechnen. Dazu muß man erstmal feststellen, ob ein Überlauf stattgefunden hat.
Es hat KEIN Überlauf stattgefunden. Es wurde der Abstand zum falschen 1PPS-Puls ausgemessen. Guck dir die Graphik noch einmal an.
Zeitdiff_1PPS_Pendel.png
Weil der Counter halt übergelaufen ist ...
Es IST kein Counter übergelaufen.
:
Bearbeitet durch User
Die Erklärung von Rainer hat was für sich und erklärt auch, warum der Sprung ungefähr bei 10^6 µs = 1 s stattfindet. Da müsste dann bald ein erneuter Sprung stattfinden, wenn sich die Pendelschwingung und der Timer wieder "kreuzen".
:
Bearbeitet durch User
Da müsste dann bald ein erneuter Sprung stattfinden, wenn sich die Pendelschwingung und der Timer wieder "kreuzen".
So sehe ich das im Prinzip auch. Wenn die Uhr so weiter läuft, wie in dem Datenfile DATENLOG_13.10, müsste der nächste Sprung 19,5 Stunden später stattfinden.
Es überholen sich allerdings nicht Pedel und irgendein Timer, sondern Pendel und 1PPS vom GPS.
:
Bearbeitet durch User
müsste der nächste Sprung 19,5 Stunden später stattfinden. Es überholen sich allerdings nicht Pedel und irgendein Timer, sondern Pendel und 1PPS vom GPS.
Bedeutet das nicht auch, das pro 19,5h eine Sekunde Abweichung auftritt? Das ist ja dann noch ein bissel bis zur 1s/100d...
Bedeutet das nicht auch, das pro 19,5h eine Sekunde Abweichung auftritt? Das ist ja dann noch ein bissel bis zur 1s/100d...
Aller Anfang ist schwer.
Ja, stimmt, hab noch mal nachgedacht.
Mein Irrtum war die Annahme, das die Kiste alle 19,5h einen "Überlauf" hat (so wie Rainer W. es so schön gemalt hat) und dann sollten doch 19,5h an GPS-Zeit und 19,5h an Pendelzeit zueinander passen, passt aber nicht weil eins von beiden einen GPS-Puls mehr auf dem Zähler hat. Der zählt ja aber nicht als volle Sekunde, sondern der überzählige Puls wurde um 1,7ms gewertet. scheisendreck ADS, menno.
Ist doch wesentlich besser als ich dachte, ich hab mich schon gewundert.
Bedeutet das nicht auch, das pro 19,5h eine Sekunde Abweichung auftritt?
Ja, ein Gangfehler von 4276 Mikrosekunden in 5 Minuten summiert sich übers Jahr zu 7min30s auf.
So wie ich Bernd verstanden habe, geht es erstmal um die Temperaturkompensation, und das sieht doch jetzt schon recht anständig aus.
Das ist Kaffeesatzleserei und sonst nix!
Norbert schrieb:
Ich rede von der Differenz. Die ist 0 wenn die Uhr präzise geht.
Die Uhr geht aber nicht präzise, sondern zu langsam. Deshalb liegt zwischen zwei Pendeldurchgängen mehr als eine Sekunde, so dass sich die 1PPS-Pulse gegenüber dem Durchgang verschieben. Dadurch kann es vorkommen, dass zwischen zwei Pendeldurchgängen mehr als ein 1PPS-Puls liegt. Das ist gegen 01:10 der Fall. (im Pulsdiagramm übertrieben dargestellt)
Das ist vollkommen richtig.
Wenn man messen will, dann muß das Messgerät in Ordnung sein. Das wäre wie mit dem "Lügenstift" Spannung messen zu wollen.
Hübsch, nicht wahr? 😉
Angehängte Dateien:
-
Zwischenablage01.jpg
(230 KB)
Hübsch, nicht wahr
Fehlt jetzt nur noch das mehrdimensionale Display um das Ding auch verständlich anschauen zu können...
Fehlt jetzt nur noch das mehrdimensionale Display um das Ding auch verständlich anschauen zu können...
Eine Anaglyph 3D-Darstellung würde schon helfen.
Eine Anaglyph 3D-Darstellung würde schon helfen.
Die Älteren haben ja vielleicht noch die Brille, damals, von Tutti Frutti. ;-)
Die Älteren haben ja vielleicht noch die Brille, damals, von Tutti Frutti. ;-)
Die tut doch nur sofern sich das Bild bewegt.
Girls are made for dancing, that's why God gave them parts that jiggle...
Und 3D-Monitore mit Wechselbild oder Doppelpolarisation waren vor ein paar Jahren der heiße Scheiß, jetzt gibt's da nix mehr von. Nur im Kino wird man noch abgezockt um die Doppelpolfilterbrille zu benutzen, zuhause kann man das nicht mehr.
Die tut doch nur sofern sich das Bild bewegt.
Da irrst du. Selbst statische Bilder bekommen eine ziemlich gute Tiefe. Aus dem Monitor heraus oder in den Monitor hinein. Blender mit Anaglyph Brille ist schon ohne Bewegung erstaunlich.
Selbst statische Bilder bekommen eine ziemlich gute Tiefe.
Ich hab da einen eigenartigen Effekt bemerkt: Ich habe eine günstige Lupenleuchte, die starke Farbränder verursacht: Kanten sind links orange, rechts blau (wobei das natürlich auch vom hell-dunkel-Wechsel abhängt, wenn der andersrum ist sind die Farbränder vertauscht, und oben/unten ist es natürlich ebenso).
Wenn ich damit ein LCD anschaue, fällt mir auf, das rote/gelbe/orange Farben knapp unter dem Glas zu sein scheinen, blaue/grüne dagegen deutlich tiefer, Weiß ist in der mitte, jeweils auf schwarzem Grund. Wiekompassherrkapitän? Ich vermute, die Aberration ist da mitverantwortlich, denn es tritt nur auf wenn ich mit beiden Augen schaue. Ja ich weiß, mit einem Auge kann man nicht 3D-kucken. Es sieht aber so aus als ob die Schrift die Ebenen wechselt wenn ich ein Auge zukneife, und ich muss neu fokussieren.
Zurück zur Anaglyphbrille: Wenn du damit eine Rot/Grün-Brille meinst: die nimmt ja die Farbe aus dem Bild weil die ja die Tiefe quasi steuert. Die Tuttifruttibrille war (auf einem Auge?) neutralgrau, damit man auch ohne Brille zuschauen konnte. Aber der Effekt war eben nur sichtbar wenn sich das Bild gleichmäßig bewegte. Gibts auch heute als Optische-Täuschung-Bild für's Handy: ein heller meist roter Ring mit einem dunklen meist blauen Innenleben. Wenn man das Handy etwas bewegt sieht man ein Loch.
Du hast natürlich recht mit der damaligen Brille. Da hat mir die Erinnerung einen Streich gespielt. War 'ne Pullfrich Brille, die anders als eine Anaglyph Brille wirkt.
Ich hab da einen eigenartigen Effekt bemerkt: Ich habe eine günstige Lupenleuchte, die starke Farbränder verursacht: Kanten sind links orange, rechts blau (wobei das natürlich auch vom hell-dunkel-Wechsel abhängt, wenn der andersrum ist sind die Farbränder vertauscht, und oben/unten ist es natürlich ebenso).
Kennt man auch von richtig gurkigen Objektiven. Kumpel hatte mal eine Serie geschossen die dieses colour fringing zeigte. Wir konnten das teilweise beheben in dem wir die Bilder in Farben zerlegten und einen jeweils korrigierten Zoom (eigentlich sogar speziellen Linseneffekt) auf die Teile losließen. Dann wieder zusammen gefügt. Wurde deutlich besser, aber schön ist anders. ;-)
Alte Weisheit: "Wer viel misst, misst Mist".
Ich habe mal versucht, das Pendel auf "Sollgeschwindigkeit"
einzuregulieren. Da komme ich an meine Grenzen.
Das sind zwar zehntausendstel Sekunden, aber immer noch viel
zu ungenau, die Sache.
Grüße Bernd
Angehängte Dateien:
-
zehntausendstel_sekunden.png
(7,7 KB)
Das ist gerade mal eine gute Stunde, du willst doch zu 100 Tagen, das kannst du nicht einfach hochrechnen. Ein Pendel ist kein TCXO.
Das ist gerade mal eine gute Stunde, du willst doch zu 100 Tagen, das kannst du nicht einfach hochrechnen. Ein Pendel ist kein TCXO.
Stefan,
weiß ich ja, irgendwie stört es mich aber, nicht mal eine Stunde
genau zu bekommen.
Temperatur usw. ändern sich ja auch.
Ein längerer Log gibt mehr Infos.
Ich bin eigentlich saumäßig Geduldig, aber etwas schneller wäre
auch nicht schlecht.
Ich werde meinen privaten Zeitplan ändern:
Die Uhr eher nebenbei, ansonsten mal die Modellbahn (Spur 0) putzen
und reaktivieren. (Die Enkel kommen bestimmt wieder vorbei).
Dann gibt es ja noch das Restfragment des großen Gartenteiches.
( 2 Nutrias + meine Frau, haben beschlossen, der Teich muss weg).
Grüße Bernd
Ein Pendel ist kein TCXO
Richtig, Bernd erforscht den ECPO:
Environmentally
Compensated
Pendulum
Oscillator
weiß ich ja, irgendwie stört es mich aber, nicht mal eine Stunde genau zu bekommen. Temperatur usw. ändern sich ja auch.
Dann miss doch mal wirklich jeden Pendeldurchgang und guck dir die Statistik an. Über eine Stunde kann man das mal machen.
Er kann halt nicht kapieren das seine Vorgehensweise nichts taugt. Vom Verständnis einmal abgesehen.
Ui. Was ist denn hier passiert?
Da bin ich ein paar Tage weg und plötzlich ist das Loggen jedes Pendeldurchgangs plötzlich erlaubt? Verblüffend. Hier werden die Meinungen ja noch schneller verschoben, als es die Grünen und Sozialen bei der Linkskoalition schaffen. ;-)
Da bin ich ein paar Tage weg und plötzlich ist das Loggen jedes Pendeldurchgangs plötzlich erlaubt?
Es geht darum, den Jitter der Lichtschranke zu bestimmen, nicht die Abhängigkeit des Gangs von Temperatur oder Luftdruck. Manchmal bedarf es unterschiedlicher Methoden, um unterschiedliche Fragestellungen zu beantworten.
Die Diskussion um die Qualität der Lichtschrankendaten ist gut anderthalb Monate alt. Insofern kann es nicht verkehrt sein, die einmal nachzumessen.
Man kann natürlich immer alles messen, aber das ist nur sinnvoll, wenn man mit den Datenmengen hinterher auch klar kommt.
:
Bearbeitet durch User
Eine Messung jedes Pendeldurchgangs gab es bereits:
Beitrag "Re: Datenlogger Pendeluhr"
Der Aufbau der Daten ist etwas anders, Details siehe Source Code:
:
Bearbeitet durch User
Eine Messung jedes Pendeldurchgangs gab es bereits:
Yep, darin konnte man auch schön sehen, dass eine kleine Asymmetrie zwischen Pendel hin und Pendel her existiert.
Man muss daher jeden geraden Eintrag untereinander vergleichen, ebenso jeden Ungeraden.
:
Bearbeitet durch User
Yep, darin konnte man auch schön sehen, dass eine kleine Asymmetrie zwischen Pendel hin und Pendel her existiert.
"kleine Asymmetrie" ist gut, immerhin um die 6 ms.
Aber die hebt sich weg, wenn man bei der Auswertung immer die Zeit für eine volle Pendelperiode (ca. 2 Sekunden) betrachtet.
Beitrag "Re: Datenlogger Pendeluhr"
Wenn das vom Zeitverhalten dem aktuellen Stand entspricht, schwanken die Messungen in der Tat noch arg.
Auffällig ist, dass auch bei Mittelung über 1 min die Standardabweichung nur wenig abnimmt, d.h. die Streuung entsteht IMHO nicht durch Rauschen der Flanke an der Lichtschranke. Zumindest bei normalverteilten Messwerten müsste es sonst bei Mittelung über 60 s gegenüber den 2 s Einzelpendelzyklen um gut einen Faktor 5 kleiner sein.
Angehängte Dateien:
-
DATENLOG_sec_2026-09-13__s_pro_s.png
(190 KB)
:
Bearbeitet durch User
Wenn ich das richtig erinnere, dann erfolgt der Energieeintrag in das Pendel über per Lichtschranke und Transistoren gesteuerte Elektromagnete. Jede noch so geringe Änderung (Spannung, Dauer, Startzeitpunkt) wird auch für eine Änderung der Amplitude und damit für eine Störung des Gleichlaufs/Anisochronismus sorgen. Das könnte noch eine große Baustelle sein.
:
Bearbeitet durch User
Wie weit kann ich den Messwerten trauen?
Hier der Log der letzen Nacht. An der Feinregulierung habe ich
etwas geändert, jetzt gibt es eine Aufzeichnung über mindestens
3 Tage.
Grüße Bernd
Angehängte Dateien:
-
scan_19.10.png
(540 KB)
Wenn ich das richtig erinnere, dann erfolgt der Energieeintrag in das Pendel über per Lichtschranke und Transistoren gesteuerte Elektromagnete. Jede noch so geringe Änderung (Spannung, Dauer, Startzeitpunkt) wird auch für eine Änderung der Amplitude und damit für eine Störung des Gleichlaufs/Anisochronismus sorgen. Das könnte noch eine große Baustelle sein.
Da hoffe ich, dass das lange Pendel mit seiner schweren Pendellinse
(ca. 3 kg), schon für Gleichlauf sorgt.
Der elektromagnetische Antrieb sollte eigentlich auch besser sein,
als ein mechanisches Uhrwerk.
Grüße Bernd
Zur Streuung der Schwingungsdauer als Vergleich Messwerte meines Experiments mit einem Pendel mit elektromagnetischem Antrieb, Details siehe hier:
Beitrag "Messung an einem Pendel mit elektromagnetischem Antrieb"
Das sind 1800 Werte der Schwingungsdauer (Durchgang des Pendels "von links" und Durchgang des Pendels "von rechts" durch die Lichtschranke). Die zweite Kurve ist der gleitende Mittelwert über jeweils 30 Werte, man beachte die unterschiedliche Skalierung der Y-Achse.
Der Vollständigkeit halber: die Messwerte sind nicht von der obigen Messung sondern ein Ausschnitt von einer weiteren Langzeitmessung über zwei Wochen bei der ich auch noch jede Minute Temperatur, Druck und relative Luftfeuchtigkeit aufgezeichnet habe.
Angehängte Dateien:
-
Schwingungsdauer.PNG
(28 KB)
Dieter,
das liegt am Pendel. Ein schweres Pendel, hinter Glas, würde nicht
so starke Abweichungen zeigen.
Dann noch Temperaturkompensation und.......
Wenn ich meine Scheibe öffne, um Einstellarbeiten zu machen, wird
das Öffnen schon deutlich gemerkt.
Wenn ich jeden LKW, der in 50 Meter Entfernung vorbeifährt, als Gang-
änderung merke, fehlt nicht mehr viel, bis zur Gravitationsmessung :-)
Grüße Bernd
Das sind 1800 Werte der Schwingungsdauer (Durchgang des Pendels "von links" und Durchgang des Pendels "von rechts" durch die Lichtschranke). Die zweite Kurve ist der gleitende Mittelwert über jeweils 30 Werte, man beachte die unterschiedliche Skalierung der Y-Achse.
Bei dir ist das Rauschen der Einzelmessungen schon eher normalverteilt, soweit man das aus einem PNG abschätzen kann: Durch die Mittelung über die 30 Werte nimmt die Standardabweichung kräftig ab. Das ist bei Bernds Messungen vom 13.9. nicht so.
p.s.
Was bedeuten eigentlich die durchgezogenen Linien bei deinen Einzelmessungen. Hast du da irgendwelche Zwischenwerte oder was willst du damit darstellen?
Vom Rauschen der Einzelwerten erwartet man doch eigentlich, dass keine Korrelation zwischen den Werten besteht, also auch kein Verlauf zwischen den Werten.
:
Bearbeitet durch User
Mir ist klar dass die Streuung bei meiner Messung deutlich besser ist. Und da das ein ganz einfaches Pendel ist habe ich keine Ansprüche an die Langzeitgenauigkeit, ganz abgesehen davon dass schon vor Jahren andere die maximal 1 Sekunde Abweichung in 100 Tagen erreicht haben (siehe z.B. "Clock B" von Martin Burgess unter https://en.wikipedia.org/wiki/Martin_Burgess) und das mit ganz "normaler" Mechanik.
Es ging mir darum herauszufinden wie genau man mit relativ geringem Aufwand die Pendelschwingung messen kann. Wenn man das Ganze wirklich optimieren will wäre das aber machbar, die Höhe der Versorgungsspannung für den elektromagnetischen Antrieb beeinflusst die Amplitude der Pendelschwingung und damit auch die Dauer. Der STM32 legt bereits über einen DAC und nachfolgendem OpAmp Buffer die Versorgungsspannung fest und man könnte nun anhand der gemessenen Umgebungswerte (Temperatur, Luftdruck usw.) deren Auswirkung auf die Schwingungsdauer kompensieren. Aber das ist Spielerei und hat keinen Einfluss auf die Genauigkeit der eigentlichen Messung.
Mir ist klar dass die Streuung bei meiner Messung deutlich besser ist.
Es geht nicht nur um besser oder nicht besser, sondern um die spektrale Verteilung des Rauschens, d.h. die Frage, warum eine Mittelung über 1min die Standardabweichung bei Bernds Messungen nur so wenig verringert.
Andere Baustelle aufmachen:
Mein Pendelantrieb ist lautlos, mein mechanisches Zählwerk nicht.
Stilbruch?
https://www.grossuhren.de/de/wanduhren-modern-quarz/digital-wanduhren/42-526-551.html
Natürlich viel zu teuer, aber ich denke mal über eine lautlose Anzeige nach.
Grüße Bernd
Stilbruch?
Absolut JA! Man mag da gar nicht hinschauen. Das wäre eine Uhr, welche man einmal kurz zu Halloween enthüllt.
Wenn es denn elektronisch sein muss, dann die Zeiger mit kleinen Schritt-Motoren ansteuern. Das ist nahezu lautlos und der analoge Charakter wird beibehalten.
Wie laut wird so ein Schrittmotor?
Übliche haben 1,8 Grad Schritte. Um die 6 Grad für die Sekunde zu
erreichen müsste ich z.B. 4 Schritte (7,2°) nehmen und 2 Zahnräder
10/12 Zähne.
Mit passenden Zahnrädern gingen auch 2,3 oder 5 Schritte.
Wird das auch schnell genug, um den Eindruck einer springenden Sekunde zu haben?
Grüße Bernd
Wie laut wird so ein Schrittmotor?
Ich mach später mal ein Video mit Tonaufnahme. Praktisch unhörbar.
Übliche haben 1,8 Grad Schritte. Um die 6 Grad für die Sekunde zu erreichen müsste ich z.B. 4 Schritte (7,2°) nehmen und 2 Zahnräder 10/12 Zähne.
Ich benutze hier einen billi^H^H^H^H preiswerten :
1 |
|
2 |
|
3 |
|
an einem Pi Pico für 4,10€. Der kann selbstverständlich auch zwei, drei oder noch mehr Schrittmotoren ansteuern. Die Dinger sind zwar auf 5V ausgelegt, laufen hier aber problemlos an 3.3V (dann nur noch mit ca. 300 Schritten pro Sekunde. Sonst ca. 1000 Schritte pro Sekunde)
Mit passenden Zahnrädern gingen auch 2,3 oder 5 Schritte.
Völlig egal, kann man alles per Software anpassen. Wie gesagt, man hat 2048 Schritte pro volle Umdrehung. Man muss nur einmal die Verhältnisse definieren
Wird das auch schnell genug, um den Eindruck einer springenden Sekunde zu haben?
Das Ding ist schnell genug um einen hart springenden, einen weich an- und ablaufenden Sekundezeiger oder auch einen gleichmäßigen Rundlauf. Oder alles dazwischen. Beschleunigung und Abbremsung zudem auch asymmetrisch möglich.
Übliche haben 1,8 Grad Schritte. Um die 6 Grad für die Sekunde zu erreichen
Könntest du den Motor selbst bauen, mit 6° Schrittwinkel.
Wird das auch schnell genug, um den Eindruck einer springenden Sekunde zu haben?
Das kommt drauf an, wieviel Masse (inklusive dem eigenen Rotor) in Bewegung versetzt werden muss und wieviel Strom durch den Motor geschickt wird.
:
Bearbeitet durch User
Eine Sekundenbewegung -> 34 Schritte.
Das ist bei 3.3V, also nur einem Drittel der erreichbaren Geschwindigkeit (bei 5V).
:
Bearbeitet durch User
Wie schnell ein Stepper drehen kann, kann man bei Zabex sehen. Der hat einen Leuchtturm gebaut, der dank Kabel an der Lampe nicht runddrehen kann und daher zurückdrehen muss. Das geht so schnell, das die Lampe nur kurz flackert. Leider kein Ton dabei, aber wenn das keine springende Sekunde ist weiß ich nicht. Video und Beschreibung unter https://www.zabex.de/site/leuchtturm.html
Das lässt mir jetzt keine Ruhe. Ich muss ohnehin mal den längeren
Datenlog abwarten.
So ein Teil ist wahrscheinlich völlig überdimensioniert:
Einen Arduino habe ich noch rumliegen. Einen Steppertreiber muss ich noch besorgen. Loslegen.
Der Drehwinkel/Schritt passt schon, ich müsste ohnehin 2 Zahnräder einbauen, um die Drehung in mein "Zählwerk" einzukoppeln.
Das Ziel: Leiser als ein handelsübliches Quarzuhrwerk (Wanduhr).
Grüße Bernd
:
Bearbeitet durch User
So ein Teil ist wahrscheinlich völlig überdimensioniert:
Für eine Dreiachs-Fräsmaschine sicher gut geeignet. Oder falls die Zeiger mit einem Meter Gussstahl verwechselt werden könnten.
Das lässt mir jetzt keine Ruhe. Ich muss ohnehin mal den längeren Datenlog abwarten. So ein Teil ist wahrscheinlich völlig überdimensioniert: https://www.oyostepper.de/goods-14-Nema-14-Schrittmotor-10-Volt-18-Grad-5Ncm-04A-10V-4-Dr%C3%A4hte-Bipolar-Hybrid-Schrittmotor.html Einen Arduino habe ich noch rumliegen. Einen Steppertreiber muss ich noch besorgen. Loslegen. Der Drehwinkel/Schritt passt schon, ich müsste ohnehin 2 Zahnräder einbauen, um die Drehung in mein "Zählwerk" einzukoppeln. Das Ziel: Leiser als ein handelsübliches Quarzuhrwerk (Wanduhr). Grüße Bernd
Hast Du mit deinem Pendel nicht schon genug zu tun? Schließe doch erst einmal damit ab.
Das Ziel: Leiser als ein handelsübliches Quarzuhrwerk (Wanduhr).
es gab früher von TN lautlose Nebenuhren (Studiouhren), die hatten Zahnräder aus Gummi. Es gab die mit 2 Motoren mit springender Sekunde und springender Minute, oder mit 1 Motor mit springender Sekunde und schleichender Minute, wie bei einem handelsüblichen Quarzuhrwerk. Vielleicht findest du noch irgendwo eine.
Leiser als ein handelsübliches Quarzuhrwerk
Wenn man das was du da hast hört, ist es kaputt. Ein normales Uhrwerk mittlerer Qualität hört man nur in absoluter Ruhe und aus nächster Nähe, d.h. der Kopp ist nah am Glas, es ist nachts und du lebst in der Pampa. Das zu unterbieten wird schwer.
Oder sind meine ganzen Aldi/Lidl-Funkwerke alle Sonderlocken "Xtreme Silent Edition"?
Leiser als ein handelsübliches Quarzuhrwerk
Wenn man das was du da hast hört, ist es kaputt. Ein normales Uhrwerk mittlerer Qualität hört man nur in absoluter Ruhe und aus nächster Nähe, d.h. der Kopp ist nah am Glas, es ist nachts und du lebst in der Pampa.
Ja, wenn man zuvor in der Disco oder später per Walkman seine Gehör demoliert hat.
Oder sind meine ganzen Aldi/Lidl-Funkwerke alle Sonderlocken "Xtreme Silent Edition"?
Ich habe in jedem Raum eine analoge-DCF-Wanduhr und bei jeder ist der Sekundenschritt hörbar. Sie sind unterschiedlich leise, aber keinesfalls geräuschlos. Ein seltenes Exemplar erzeugt zudem täglich kurz vor 12 ein Geräusch.
Tatsächlich werden Uhrwerke angeboten, die mit "schleichendem Sekundenzeiger" extrem leise sein sollen.
Das Thema heißt: Datenlogger Pendeluhr
Ein Update:
Den Code habe ich der KI gegeben, um ein paar Anpassungen vorzunehmen.
Leider noch nicht perfekt. Das Programm stoppt zwar nicht mehr beim
Entnehmen der Karte, aber da fehlt immer ein Datensatz.
Grüße Bernd
Angehängte Dateien:
-
Code_23.10.png
(67 KB)
:
Bearbeitet durch User
So sieht es jetzt aus: Jeder fehlende Datensatz ist durch ein Entnehmen der Karte bedingt.
Grüße Bernd
Angehängte Dateien:
-
log_23.10_a.png
(20 KB)
:
Bearbeitet durch User
Da sollte der Fehler sein.
Es gibt keinen Monitor.
So ein Uno R 4 sollte doch etwas Speicher haben, um einen Datensatz
zu überbrücken?
Grüße Bernd (Schlossermeister seit 1978)
Angehängte Dateien:
-
fehler_23.10.png
(81 KB)
Da sollte der Fehler sein. Es gibt keinen Monitor.
Der Schnittstelle ist es egal, ob am anderen Ende jemand zuhört.
Das ist jetzt kein gravierender Fehler, wenn beim Auslesen
der Karte ein Datensatz fehlt, aber das muss doch nicht sein.
Mittlerweilen macht es mir Spaß, die KI mit meinen Problemchen
zu füttern.
Das "neue" Programm kam von der KI. Zehn Minuten später erzählt
mir das Teil, dass meine Änderungen suboptimal wären.
(Ich hatte nichts geändert).
KI ist blöd.
Grüße Bernd
:
Bearbeitet durch User
KI ist blöd.
Deswegen verwendet man die nicht mit "Datei hochladen", "ändern lassen", "wieder herunterladen", sondern lässt die KI direkt auf dem Repository arbeiten, sei es in einer IDE oder mit opencode u.Ä. auf der Kommandozeile.
Da hat die KI die Historie, was sie geändert hat, kann gezielt an einzelnen Stellen editieren, ohne jedesmal die ganze Datei von Anfang an neu generieren zu müssen, macht sich Notizen zu deinen Vorgaben, Änderungen, Versuchen die fehlgeschlagen sind, kann direkt mal den Compiler anwerfen, um zu prüfen ob der aktuelle Stand auch kompiliert usw.
Hier mal ein aktueller Log. Da sieht man, wie schwierig die
Regulierung ist. Am Pendel wurde nichts verändert.
Die Einschwingzeit sind doch etliche Stunden.
Grüße Bernd
Angehängte Dateien:
-
traegheit_pendel.png
(58 KB)
Hier mal ein aktueller Log.
Lieber Bernd,
es wäre besser, wenn Du keine Screenshot einstellst sondern ACSII-Daten
:
Bearbeitet durch User
Bernd F. schrieb:
Hier mal ein aktueller Log.
Lieber Bernd, es wäre besser, wenn Du keine Screenshot einstellst sondern ACSII-Daten
Mache ich, wenn es die nächste längere Datenreihe gibt. So ein paar Stunden sind nicht relevant.
Grüße Bernd
Hier mal ein aktueller Log. Da sieht man, wie schwierig die Regulierung ist. Am Pendel wurde nichts verändert. Die Einschwingzeit sind doch etliche Stunden. Grüße Bernd
Na, schau kuck. Es Geht wieder mit dem Thema voran. Gut.
Nur beim 700sten Post arg spät.
Nur beim 700sten Post arg spät.
Wenn man deine sinnfreien Beiträge streichen würde, wären es deutlich weniger ;-)
Wenn man ein Foucaultsches Pendel möglichst sauber starten möchte, hält man es mit einem Faden in der ausgelenkten Position und brennt den dann berührungslos durch.
Bei einer Pendeluhr ist das allerdings ungleich schwieriger, weil man die Pendelebene der Uhr richtig treffen muss.
:
Bearbeitet durch User
Jetzt habe ich ein Problem:
Das Pendel geht mit dem neuen Code deutlich zu schnell.
(Ob es am Pendel liegt? Eher an der neuen Berechnungsart der
Sekundenbruchteile. Jetzt wird der Quarz auf dem SD-Karten-
Aufsatz genutzt).
Alle Gewichte vom Teller genommen, immer noch zu schnell.
Pendel an der Mutter regulieren. Das ist ein längerer Prozess. Die Auswirkungen sind erst nach ca.4 Stunden sicher bestimmbar.
Das Ziel ist, das Pendel eine Spur zu langsam einzustellen.
Dann wird mit aufgelegten Gewichten wieder beschleunigt.
Grüße Bernd
Das Pendel geht mit dem neuen Code deutlich zu schnell.
Ich lehne mich mal weit aus dem Fenster und behaupte, dass deinem Pendel der zusammengegurkte KI-Code am Ar… vorbei geht.
Norbert,
ich kann mir das nur so erklären: Das Pendel ging ja auch vorher
längerfristig zu schnell. Die ersten Stunden des Log haben mir
aber angezeigt, das Zielgeschwindigkeit erreicht wäre.
Anscheinend wird jetzt sofort gemeldet, dass das Pendel zu
schnell ist. ( Es geht um tausendstel Sekunden/ Stunde).
Grüße Bernd
Prima Beispiel für KA ("Keine Ahnung") trifft auf KI: In "sketch_oct23a.ino" wird nun der "ppsInterrupt()" nicht mehr vom 1PPS Impuls ausgelöst sondern vom 1 Hz Signal einer DS3231 RTC. Soll die DS3231 etwa genauer sein als der 1PPS Impuls vom GNSS Modul?
Das Pendel ging ja auch vorher längerfristig zu schnell.
Ich habe mir mal deinen etwas älteren Sekundenlog angesehen. Schon da stiegen die Mikrosekunden-Timestamps (gemittelt) stetig an. Also schwang das Pendel schon da zu langsam. Es hätte also um die gezeigten ppm/ppb schneller gemacht werden müssen.
Und noch eines, wenn man den damaligen Sekundenlog zugrunde legt dann erkennt man auch, dass man gefahrlos nach ein bis zwei Minuten einen deutlichen Trend bei Änderungen sehen können sollte. Geht natürlich nicht mit halbstündigen Messungen.
Norbert,
ich habe das Messintervall auf 10 Minuten gesetzt. Das kann ich
auch leicht ändern.
Dieter, das ist mir aufgefallen, aber ich habe es erstmal bewusst ignoriert.
Worum geht es im Kern? Ein Pendel auf 1Sek/100Tage zu bringen.
Das ist 1/100 Sekunde pro Tag. 0,0004 Sekunden/Stunde.
Ambitioniert, aber nicht unmöglich.
Der Logger soll ja grundsätzlich dazu dienen, die Wechselwirkungen
von Temperatur, Druck usw. zu klären, um da mechanisch
gegenzusteuern.
Grüße Bernd
Norbert, ich habe das Messintervall auf 10 Minuten gesetzt. Das kann ich auch leicht ändern.
Bernd, wenn du nicht jedes mal einen Kuchen zwischen zwei Messungen backen möchtest, braucht's einfach eine andere Schlagzahl. Selbst bei 10 Minuten ist es nun einmal so, dass du eine Messung nimmst und fünfhundert-neunundneunzig andere, ebenfalls gut nutzbare Messungen verwirfst bzw. ignorierst. Das mag vielleicht auch dem für seine Winzigkeit relativ überteuertem Arduino-AVR geschuldet sein.
Aber wenn das tatsächlich so gewollt ist, dann ist das selbstverständlich völlig OK. Vor allem weil die Einstellungsarbeiten dann auch eher Zen-mäßig stattfinden und man der Farbe so schön beim Trocknen zuschauen kann. ;-)
Die alte Version hatte auch deutliche Macken.
Hier die Zeitangabe mit Sekundenbruchteilen.
Da passt doch Einiges nicht
Grüße Bernd
Angehängte Dateien:
-
unklare_zeit.png
(50 KB)
Die alte Version hatte auch deutliche Macken.
Ist halt nicht die beste Software, aber mit Abstand die Lustigste.
Bernd F. schrieb:
Die alte Version hatte auch deutliche Macken.
Ist halt nicht die beste Software, aber mit Abstand die Lustigste.
Das ist doch auch schon was.
Wo es doch so wenig zum Lachen gibt.
Viele Grüße Bernd
Bernd F. schrieb:
Norbert, ich habe das Messintervall auf 10 Minuten gesetzt. Das kann ich auch leicht ändern.
Bernd, wenn du nicht jedes mal einen Kuchen zwischen zwei Messungen backen möchtest, braucht's einfach eine andere Schlagzahl. Selbst bei 10 Minuten ist es nun einmal so, dass du eine Messung nimmst und fünfhundert-neunundneunzig andere, ebenfalls gut nutzbare Messungen verwirfst bzw. ignorierst. Das mag vielleicht auch dem für seine Winzigkeit relativ überteuertem Arduino-AVR geschuldet sein. Aber wenn das tatsächlich so gewollt ist, dann ist das selbstverständlich völlig OK. Vor allem weil die Einstellungsarbeiten dann auch eher Zen-mäßig stattfinden und man der Farbe so schön beim Trocknen zuschauen kann. ;-)
Norbert,
ich kann natürlich auch im 2 Sekundentakt loggen.
Aber: Was bringt es? Nach jeder Einstellarbeit am Pendel sind
mehrere Stunden Geduld gefragt. Ist halt so.
Das ist ein sehr träges System.
Grüße Bernd
Nach jeder Einstellarbeit am Pendel sind mehrere Stunden Geduld gefragt. Ist halt so. Das ist ein sehr träges System.
Und ein schnelles Live-loggen sagt dir, sobald ein Gleichgewicht erreicht ist. Und es zeigt dir dabei sogar den Prozess. Aber iss ja auch egal, war halt nur ein Gedanke.
Hier die Zeitangabe mit Sekundenbruchteilen. Da passt doch Einiges nicht
Was passt da nicht?
Der Datensatz mit der Uhrzeit kommt vom GPS mehr oder weniger IRGENDWANN - etwas überspitzt formuliert. Wahrscheinlich fand in dem rot markierten Bereich dein Pendeldurchgang gerade zu einem Zeitpunkt statt, wo vom GPS mal der alte Datensatz mit der Uhrzeit verfügbar war und mal der neue. Die Sekundenanzeige springt sozusagen gerade um. Wenn dein Pendel 1/10s später durch geht, sind die Sekunden vermutlich stabil. Du sieht ja auch, dass vor und nach dem markierten Zeitfenster, also wenn dein Pendel eine etwas andere Phasenlage zum 1PPS besitzt, die im Log abgelegten Sekunden bereits wieder stabil sind.
:
Bearbeitet durch User
Und ein schnelles Live-loggen sagt dir, sobald ein Gleichgewicht erreicht ist.
Tut es nicht, jedenfalls nicht, falls die Rauschamplitude der gemessenen Pendeldauern sich seit dem 2026-09-13 nicht geändert hat. Die Standardabweichung für 1 min-Messungen lag dort bei fast 50µs, für die Pendelperiode war sie 1,4 mal so hoch, falls ich mich nicht irgendwo verrechnet habe. Das würde bedeuten, dass man anhand von 1-Minuten Messungen die Uhr nicht besser als auf 30s/a justieren kann,
DATENLOG_sec_2026-09-13__s_pro_s.png
:
Bearbeitet durch User
Tja, jeder sieht halt etwas anderes in den vorliegenden Daten. Ich sehe hier zum Beispiel das unterschiedliche timing bei Pendel hin und her Bewegung. Und einen sich mit zunehmender Zeit deutlich abzeichnenden Trend. Exemplarisch mal mit den Rohdaten, dann nach jeweils 100, 200, 500 und 1000 Sekunden. Und selbst 1000 Sekunden sind nur etwas mehr als eine Viertel Stunde.
Aber wie gesagt, jeder sieht was anderes.
Angehängte Dateien:
-
output.png
(160 KB)
Tja, jeder sieht halt etwas anderes in den vorliegenden Daten.
Was sind das für Daten, d.h. reden wir von der selben Aufzeichnung?
(nur wegen der Vergleichbarkeit konkreter Zahlen)
Du hattest schnelles Live-Logging vorgeschlagen, also wäre es doch nicht schlecht, sich darauf zu konzentrieren.
Und ein schnelles Live-loggen sagt dir, sobald ein Gleichgewicht erreicht ist. Und es zeigt dir dabei sogar den Prozess.
Ich sehe hier zum Beispiel das unterschiedliche timing bei Pendel hin und her Bewegung.
Das haben inzwischen wohl alle verstanden. So ist das nun einmal, wenn die Schaltpunkte der Lichtschranke nicht exakt in der Mitte liegen.
Bei Betrachtung der Pendelperiode (Durchgang des Pendels von der selben Seite) stört das nicht für weitere Auswertungen.
Und einen sich mit zunehmender Zeit deutlich abzeichnenden Trend.
Ach - dieser Trend nennt sich bei einer Uhr auch "Gang" (Steigung deiner Kurven).
Wenn sich der Pendeldurchgang innerhalb von 1000s um 4,5ms verschiebt, bedeutet das einen Gang der Uhr von 0,4s/d oder 140s/a.
Der langfristige Trend ist nebensächlich, solange es um die Justage anhand KURZER Messungen geht. Da spukt einem viel mehr das Rauschen auf den Daten in die Suppe.
Soweit ich Bernd verstanden habe, ist es Ziel der Justage, den Gang auf einen definierten Wert etwas unter 0 zu bringen.
:
Bearbeitet durch User
Was sind das für Daten, d.h. reden wir von der selben Aufzeichnung?
Bernd hat meines Wissens nur einmal sekündliche Daten zur Verfügung gestellt.
Das haben inzwischen wohl alle verstanden. So ist das nun einmal, wenn die Schaltpunkte der Lichtschranke nicht exakt in der Mitte liegen.
Das habe wohl tatsächlich alle verstanden. Musst du nicht noch einmal zusätzlich machen. Dennoch ist es deutlich in der Grafik zu sehen. Sozusagen als kostenlose Beigabe.
Ach - dieser Trend nennt sich bei einer Uhr auch "Gang".
Jetzt geh's aber weg. So nennt sich das? Dieses Forum ist ein Quell der Erkenntnis. Faszinierend!
Der langfristige Trend ist nebensächlich, solange es um die Justage anhand KURZER Messungen geht. Da spukt einem viel mehr das Rauschen auf den Daten in die Suppe.
Sag mal, kannst oder willst du nicht sehen, dass die Linien alle einen deutlichen Trend für kurze Korrekturen des Ganges zeigen? Und je länger man wartet, oh Wunder, desto besser(glatter) werden diese Trendlinien. Schon nach 200s, sicher aber nach 500s sind die verdammt gut.
Und nun muss man nur noch die Linien waagerecht bekommen.
Steigen sie ──▶ Pendel zu langsam.
Fallen sie ──▶ Pendel zu schnell.
Soweit ich Bernd verstanden habe, ist es Ziel der Justage, den Gang auf einen definierten Wert etwas unter 0 zu bringen.
Und dazu braucht er Informationen. Entweder jeden Mondumlauf eine Messung oder halt richtig.
Sag mal, kannst oder willst du nicht sehen, dass die Linien alle einen deutlichen Trend für kurze Korrekturen des Ganges zeigen?
Guck dir die Zahlen an. 140s/a ist noch WEIT weg vom Ziel. Stell dir einmal eine um einen Faktor 50 geringere Steigung vor (3s/a) und dann guck dir die Wirkung des Rauschens auf die Aussagekraft einer kurzen Messung an.
Noch mal kurz zu der "tollen" Idee (KA trifft KI...) anstelle des 1PPS Impuls vom GNSS Modul das 1 Hz Signal einer RTC zu verwenden: auch wenn da in "sketch_oct23a.ino" DS3231 steht dürfte es sich um eine DS1307 auf einem Data Logging Shield handeln.
Eine DS3231 RTC hätte im Idealfall eine Genauigkeit von 2 ppm, wenn es Fake ist (z.B. DS3231M anstelle DS3231) nur 5 ppm.
Bei einer DS1307 RTC bestimmt der externe Quarz die Genauigkeit, das dürften so um die 20 ppm bei "normalen" Quarzen sein.
Die vom TO gewünschte Genauigkeit von 1 Sekunde auf 100 Tage sind ca. 0.1 ppm (1 Sekunde Abweichung alle 3600 * 24 * 100 Sekunden).
Ich frage mich ob der TO bei seiner Uhr auch mit dem Meterstab misst wenn er auf 1/10 mm genau messen möchte...
Und vielleicht sollte sich der TO auch mal ansehen wie andere bereits vor Jahren die 1 Sekunde Genauigkeit auf 100 Tage erreicht haben.
Guck dir die Zahlen an. 140s/a ist noch WEIT weg vom Ziel. Stell dir einmal eine um einen Faktor 50 geringere Steigung vor (3s/a) und dann guck dir die Wirkung des Rauschens auf die Aussagekraft einer kurzen Messung an.
Ich bin zwar einigermaßen sicher, dass sich eine Weiterführung dieser Diskussion nicht lohnt, aber…
Wir sind hier bei der GROB-Einstellung! GROB
Selbstverständlich (und das meine ich nun wirklich im wahrsten Sinne des Wortes) muss man bei zunehmenden Genauigkeitsansprüchen, also wenn sich der Gang dem Optimum nähert, auch längere Intervalle messen.
Es gibt aber keinen wie auch immer gelagerten Grund die Grobeinstellung schon jetzt mit tagelangen sporadischen Messungen durchzuführen.
PS. Müsst ihr eigentlich pro Messung ein Schutzgeld an die Log-Mafia zahlen?
PPS. Das war eine rhetorische Frage.
Ja, man zieht sich hier an Banalitäten hoch ohne die grundsätzlichen Dinge verstanden zu haben, wie ich schon mehrmals hier erwähnt habe.
Keiner hier hat sein Pendel jemals gesehen, beziehungsweise einen genauen Plan davon.
Der TO schrieb etwas von Bleiplatten die sich in der Linse des Sekundenpendels befinden sollen.
Das ist eindeutig zu wenig an Information.
Mich interessiert z.B auch wie genau das Meßgerät überhaupt mißt.
Der TO sollte etwas mehr aus dem hoch geheimen Projekt erzählen.
Dieter S. schrieb im Beitrag #8107745: ...
Die vom TO gewünschte Genauigkeit von 1 Sekunde auf 100 Tage sind ca. 0.1 ppm (1 Sekunde Abweichung alle 3600 * 24 * 100 Sekunden). Ich frage mich ob der TO bei seiner Uhr auch mit dem Meterstab misst wenn er auf 1/10 mm genau messen möchte...
Sein Anspruch war hier: Beitrag "Re: Das Hundertstausendstel Millimeter messen?"
Und vielleicht sollte sich der TO auch mal ansehen wie andere bereits vor Jahren die 1 Sekunde Genauigkeit auf 100 Tage erreicht haben.
BirnKichler 🧐 S. schrieb:
Nur beim 700sten Post arg spät.
Wenn man deine sinnfreien Beiträge streichen würde, wären es deutlich weniger ;-) Wenn man ein Foucaultsches Pendel möglichst sauber starten möchte, hält man es mit einem Faden in der ausgelenkten Position und brennt den dann berührungslos durch. Bei einer Pendeluhr ist das allerdings ungleich schwieriger, weil man die Pendelebene der Uhr richtig treffen muss.
Hast du deinem Glaser schon mitgeteilt, daß du einen Großauftrag für ihn hast? 🤣
Ich bin zwar einigermaßen sicher, dass sich eine Weiterführung dieser Diskussion nicht lohnt, aber… Wir sind hier bei der GROB-Einstellung! GROB
Es gibt drei Ziele der Messungen:
- Abhängigkeit des Gangs von der Temperatur
- Abhängigkeit des Gangs von der Luftdicht
- (Grob)Justage des Gangs
- Justage des Jahresgangs
Die Messungen über ein paar Tage dienen, zusammen mit der Nachtabsenkung der Raumtemperatur, hauptsächlich 1.
p.s.
Dank deines Plots hat sich das vermeintlich merkwürdige statistische Verhalten bzgl. Standardabweichung bei Mittelung in meiner gezeigten Auswertung der Sekundendaten geklärt (korr. Version im Anhang). Nun sieht es nach "vernünftigem" Datenrauschen aus:
Standardabweichungen der Einzelpendelzyklen ist 22 µs/s, die der 1 Min-Werte 1,8 µs/s.
Angehängte Dateien:
-
DATENLOG_sec__s_pro_s_korr.png
(240 KB)
:
Bearbeitet durch User
Das Datenfile hatte ich glatt übersehen.
Angehängte Dateien:
-
Zwischenablage01.jpg
(140 KB)
Zwischenablage01.jpg (140 KB)
Könnte von Picasso sein: "Alte Dame mit Handtasche und Pudel"
:
Bearbeitet durch User
Das ist doch keine kontinuierliche Messung, oder?
Angehängte Dateien:
-
Zwischenablage01.jpg
(140 KB)
-
Zwischenablage02.jpg
(180 KB)
-
Zwischenablage03.jpg
(81 KB)
DATENLOG_sec__s_pro_s_korr.png
dto., mit gespreizter Gang-Skala, Vorzeichen 5 Min Mittel korrigiert.
(Standardabweichung 5Min-Messungen: 0,85 µs/s)
Das ist doch keine kontinuierliche Messung, oder?
Nein, vier.
Du solltest einmal in die Daten reingucken, bevor du auswertest.
Bei einem Neustart geht es immer mit Impuls_Nr=1 los.
Angehängte Dateien:
:
Bearbeitet durch User
Rainer W. schrieb im Beitrag #8107815: ...
Nein, vier. Du solltest einmal in die Daten reingucken, bevor du auswertest. Bei einem Neustart geht es immer mit Impuls_Nr=1 los.
Nicht wirklich dein ernst, das ist die Aufgabe desjenigen der das logfile zur Verfügung stellt. Und da ist der TO sehr, sehr schlampig!
So kann ich da nicht weitermachen. Da ist gewaltig der Wurm drin.
Hier 2 kurze Messungen. Einmal alter, einmal neuer Code.
Am Pendel wurde nichts verändert!
Die Unterschiede sind ja drastisch.
Grüße Bernd
Angehängte Dateien:
-
Schneller.png
(50 KB)
-
Langsamer.png
(31 KB)
@TO: Einfach mal das lesen was man Dir hier schreibt:
@TO: Einfach mal das lesen was man Dir hier schreibt: Beitrag "Re: Datenlogger Pendeluhr"
Mit der Elle kann man den Erdumfang schlecht messen.
So ungenau kann das doch nicht sein?
Ich besorge mir für 5,-€ ein zweites GPS-Modul und logge
den Sekundenimpuls.
Grüße Bernd
So ungenau kann das doch nicht sein? Ich besorge mir für 5,-€ ein zweites GPS-Modul und logge den Sekundenimpuls. Grüße Bernd
Endlich
So ungenau kann das doch nicht sein?
Was ist Was willst du mit der RTC?
Der GPS-Empfänger liefert dir Sekundenpulse mit wahrscheinlich um die 70ns (falls der Modulhersteller nichts verbockt hat) und er liefert dir Datum und Uhrzeit im Klartext.
Bei deinem neuen Code driftet irgendwer mit 4,8 ms pro Minute, beim alten sind es 4,4 ms. Da wird im neuen Programm die Differenz wohl anders gerechnet.
:
Bearbeitet durch User
Der PPS-Interrupt wird von der RTC ausgelöst -> Mist! (Zeile 79 sketch_oct23a.ino)
Bei deinem neuen ...
p.s. ... Je nachdem, ob vom Sekundenimpuls zum Pendeldurchgang oder vom Pendeldurchgang zum Sekundenimpuls gemessen wird, bekommst du steigende oder sinkende Werte für die Mikrosekunden. Was das für den Gang deine Uhr bedeutet (zu langsam oder zu schnell), häng davon ab, was genau im Programm passiert. Das wird allmählich etwas zu unübersichtlich, um das beim Überfliegen nachzuvollziehen.
Die Zeitsprünge durch die Synchronisation mit dem GPS machen die Sache nicht übersichtlicher für die Auswertung.
:
Bearbeitet durch User