Angenommen, ich habe mehrere Datenlogger, die Sensordaten empfangen, wie kann ich diese Signale anschließend synchronisieren? Der naheliegendste Weg wäre das Hinzufügen von Zeitstempeln zu den Daten, aber sie haben unabhängige Uhren, sodass ich die Signale nicht wirklich synchronisieren kann, selbst mit diesen Zeitstempeln.
Wäre es möglich, dafür einen kleinen Satelliten-Zeitchip zu verwenden, damit die Stempel alle aus derselben Quelle stammen? Oder wie würdet ihr das lösen?
Für unabhängige genaue Uhren können Sie GPS-Empfänger oder die Langwellen-Zeitempfänger wie für WWVB ausprobieren.
Eine andere Möglichkeit besteht darin, vernünftige Quarzoszillatoren auf jeder Einheit anzubringen und sie als Teil des Daten-Upload-Prozesses zu synchronisieren. Das System, das die Daten empfängt, kennt die aktuelle absolute Zeit und extrapoliert rückwärts unter Verwendung der aktuellen Zeit und der Zeitstempel des Datenloggers. Wenn es die absolute Zeit des letzten Uploads kennt, könnte es versuchen, jeden Fehler, den es findet, gleichmäßig über das letzte Intervall zu verteilen.
Sie können in jeden Datenlogger eine einigermaßen anständige relative Zeitmessung eingeben. Beispielsweise sind 32768-Hz-„Uhren“-Kristalle billig, stromsparend und mit guter Genauigkeit erhältlich. Sie können leicht eine gute bis 20 ppm bekommen.
Angenommen, Daten werden von jeder Einheit etwa einmal im Monat hochgeladen. Zwischen den Uploads versieht das Gerät jeden Datensatz mit einem Zeitstempel von seiner lokalen Uhr. Diese Zeitstempel sind nicht mit der Echtzeit synchronisiert, haben jedoch einen akkumulierten Fehler von maximal 20 ppm in Bezug aufeinander. 20 ppm über einen Monat sind etwa eine Minute.
Der Computer, der die hochgeladenen Daten empfängt, kennt die Echtzeit und die aktuelle Zeit des Datenloggers und kann daher bestimmen, wie er rückwärts arbeiten muss, um die Echtzeit jedes der Datensätze mit bis zu 20 ppm Fehler rückwärts zu finden. Beispielsweise sind die ältesten Daten von vor einem Monat nur innerhalb von etwa 1 Minute bekannt. Die Daten von vor einem halben Monat auf eine halbe Minute genau usw. Wenn ein Fehler von 1 Minute akzeptabel ist, muss wenig mehr getan werden.
Indem jedoch die Echtzeit des Upload-Ereignisses gespeichert und natürlich wie gewohnt mit einem Zeitstempel versehen wird, kann der Worst-Case-Fehler erheblich reduziert werden. Dazu muss nach jedem Hochladen nur ein einziges Ereignis in das Protokoll geschrieben werden. Dies ist das erste Ereignis im Protokoll beim nächsten Upload. Bei jedem Upload kennen Sie dann die absolute Zeit zu Beginn und Ende der Upload-Daten. Die Worst-Case-Drift von einem bekannten Zeitpunkt liegt jetzt mitten in der Upload-Periode, die nur einen halben Monat von einer Referenz oder nur etwa eine halbe Minute entfernt ist.
Noch besser ist, dass der Fehler jetzt unabhängig vom absoluten Fehler der lokalen Uhr ist. Zeitfehler hängen nur von Verschiebungen in der lokalen Taktfrequenz ab. Da Sie die Echtzeit zu Beginn und am Ende der Upload-Daten kennen, können Sie feststellen, wie schnell oder langsam die lokale Uhr während dieser Zeit gelaufen ist, und dies berücksichtigen. Wenn der lokale Oszillator beispielsweise die ganze Zeit über genau 20 ppm schnell war, zeigen die Zeitstempel einen Zeitraum an, der 1 Minute länger als die bekannte Zeit zwischen dem Start und dem Ende der Daten ist. Wenn Sie den Zeitstempelfehler linear proportionieren, um die Enden passend zu machen (da sie bekannt sind), sind die Daten in der Mitte genau, solange sich der lokale Oszillator nicht geändert hat. In der Mitte des Monats ziehst du etwa eine halbe Minute ab usw.
Kristalle werden oft für einen absoluten Fehler und einen relativen Fehler über die Zeit spezifiziert. Mit dem zweiten Schema hebt sich der absolute Fehler auf. Jeder verbleibende Zeitfehler ist nur eine Funktion dessen, wie stark sich der Kristall während des letzten Monats verändert hat , was erheblich geringer sein kann als sein durchschnittlicher absoluter Fehler.
Benutzer3624
Olin Lathrop
Benutzer3624