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.