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