Genaue uC-uptime

[Bingo (Gast)]

Abend zusammen,

tja, mir ist leider kein passender Titel eingefallen.

Ich baue gerade ein Gerät, für dessen Funktion es wichtig ist dass es 
die Zeit kennt. Deswegen hab ich ein DCF77 angebunden und zur 
Überbrückung von schlechter Empfangslage außerdem ein DS1307.

In meiner Software lasse ich mir zyklisch einen Zähler inkrementieren, 
der mir praktisch die "Betriebsdauer" angibt. Könnt vielleicht mal 
wichtig sein für Debugzwecke oder für Laufzeitmessungen.
Dieser Wert ist ja vom Prozessorclock abhängig und dementsprechend 
ungenau. D.h. wenn ich mein Gerät um 12 Uhr Mittags einschalte und um 12 
Uhr Nachts die Betriebsdauer auslese werde ich eine gewisse Abweichung 
haben.
Im Laufe von Tagen/Wochen summiert sich diese Abweichung natürlich auf.

So, mir ist natürlich klar dass ich meine Software auf den Quarz 
kalibrieren könnt. Ich kenne auch den hier gerne verlinkten Artikel "Die 
genaue Sekunde".

Da ich aber sowohl eine (relativ genaue) Taktquelle als auch eine sehr 
genaue absolute Zeitquelle zur Verfügung habe überlege ich ob ich damit 
irgendwie meine Betriebsdauer grade rechnen könnte.
Leider komm ich auf keine Lösung.

Wisst ihr da was? Ist es möglich meinen internen Zähler zu Verbessern 
indem ich auf eins von meinen Peripherie-Geräten zurückgreife?

[Max D. (max_d)]

Troll ?

Du hast eine DCF-Uhr programmiert, weisst aber nicht wie du damit eine 
uptime zählst ?
Das musst du uns mal erklären ....

[Bingo (Gast)]

Nö. Weiß ich nicht.
Ich kann mich ja nicht darauf verlassen dass ich regelmäsig eine neue 
Zeit reinkrieg.

Möglicher Ansatz: Bei Empfang einer neuen Zeit meinen internen Zähler 
wegspeichern, den eigentlichen Zähler weiterinkrementieren.

Bei der nächsten empfangenen Zeit die Differenz zur vorherigen 
Ausrechnen und zum weggespeicherten Zähler draufaddieren.

Oder wie würdest du das machen?

[Mike (Gast)]

Nichts ist häßlicher als eine Uhr, die dauernd Sprünge macht. Entweder 
du erzeugst dir eine genaue Zeitbasis, mit der du zufrieden bist (genaue 
Sekunde) oder du lebst mit der sich aufsummierenden Abweichung. Wenn du 
z.B. nach jeder Minute oder manchmal auch nur alle paar Stunden mit 
DCF77 korrigierst, wirst du blöd beim Auswerten.

[Konrad S. (maybee)]

Du kannst beim Start die Zeit vom DS1307 auslesen.

Du kannst dir vom DS1307 ein "Square Wave"-Signal generieren lassen und 
mit dem Controller die Takte mitzählen.

[Max D. (max_d)]

Du hast deinen DS1307, der hat 56 Batterie-gestütze RAM-Bytes.
Wenn du dein Gerät anschaltest (oder durch welches event deiner Wahl 
auch immer), dann speicherst du die aktuelle Zeit in den RAM (den vom 
DS) rüber.
Entweder bist du schon fertig (der letzte Neustart ist im DS eindeutig 
dokumentiert) oder du willst noch einen zusätzlichen Watchdog, dazu 
kopierst du jede (ungenau ist egal) Sekunde/Minute/Stunden/whatever die 
Zeit im DS hinter deine Startzeit. Wenn jetzt dein Gerät hängt, dann 
siehst du die letzte Zeit zu der es noch funktioniert hat im Speicher.

[wagneth (Gast)]

Klingt doch nicht sooo schwierig,
ich würde es so versuchen.

Wir haben :

-einen Zeittakt (Quarz -> Prescaler -> TimerInterrupt) der mit einen 
Drift behaftet ist.

-Wir haben die Genaue Zeit welche mit einen Offset behaftet ist.
(Übertragungsweg, verarbeitung in Deinem Programm)

Ich denke der Offset vom DCF77 und deinem Controller/Verarbeitung ist zu 
vernachlässigen ;)

Wenn Du deine beiden Uhren vergleichst wirst Du irgendwann eine 
Abweichung feststellen.

Abweichung = DCF77 Uhr - TimerUhr.



Wenn Abweichung ungleich null wird es spannend :


Ist unsere Abweichung Positiv dann läuft unsere TimerUhr langsamer als 
die DCF77.
Der TimerInterrupt zum weiterzählen unserer internen Uhr muss 
grundsätzlich nach weniger Ticks aufgerufen werden.

Jetzt müssen wir zwei Dinge bedenken :

1. wir müssen den Timmer Interrupt welcher unsere interne Uhr antreibt 
schneller zählen lassen.
Kennt man die aktuelle und die letzte Uhrzeit beider Uhren kann man 
deren Differenz ausrechnen.

DCF77 Uhr lief z.b. 3600s
Timer Uhr lief z.B. 3580s

Unsere TimerUhr muss also 5,6 Promille schneller laufen -> Also 
Comparewert für den Timerinterrupt abändern...

(Achtung bei Tageswechsel, oder UnixZeit benutzen...!!!)


2. Wir können nicht einfach die neue, richtige Zeit übernehmen.
Im extremfall kann dann z.B. unser Wecker nicht mehr anschlagen,
oder was auch immer mit der Zeit gesteuert wird.
(Der "Zeitsprung" springt quasi über den Alarm drüber...)
Im Endeffekt muss unsere Uhr über jede kleinste Zeiteinheit laufen.
(mit der wir rechnen)
Wir wollen uns also gleitend an die richtige Uhrzeit annähern.

Deshalb muss die Uhr eine bestimmte Zeit lang noch schneller laufen.

============--==--==--==--==--==--==--=
          --
        --
     --
  --
--

Die Gleichzeichen stellen die Refernzuhr dar.
Wir nähern uns jetzt mit unserer Timer Uhr, das sind die -- Zeichen 
unserem Zeitnormal an.

Unter punkt eins haben wir den Drift unseres Quarz oder was auch immer 
kompensiert.
Bei Punkt zwei überlagern wir für eine bestimmte Zeit unseren Drift.

Wir gehen jetzt mal davon aus das sich kein neuer Drift ergeben hat.
Theoretisch wissen wir nach wieviel Interrupts/Ticks unsere Uhr beim 
Zeitnormal angekommen ist und nehmen unseren Drift von Punkt2 wieder 
raus.

Beim nächten Abgleich haben wir wahrscheinlich wieder einen kleinen 
drift und das spiel geht von vorne los...

PS :
Die Steigung der "--" Zeichen ist ein Zielkonflikt.
Ist die Steigung zu gross sieht man von aussen das "rennen" der Uhr.
Ist die Steigung zu klein nähert man sich bei steigendem Drift niemals 
wirklich an.
Es mach meiner Meinung nach Sinn die Steigung auf einen bestimmten 
Betrag zu begrenzen.

z.B. 10ms / 1s
Man bräuchte dann 100 Sekunden um 1 Sekunde Abweichung zu ändern.

[Max D. (max_d)]

Er hat doch mit dem DS1307 schon eine RTC mit hoher Genauigkeit.
Damit auch der kleine Drift im DS rausfällt wird der sooft wie möglich 
(aber vlt. etwas vorsicht vor falschen datensätzen) nach DCF 
nachjustiert.
Jede Anwendung (wie sein uptime) die genaue Zeiten braucht wird einfach 
mit der Zeit im DS gefüttert (wenn man ein Sec-tick bruacht hat der doch 
sogar einen Ausgang dafür)...

[Thomas W. (wagneth)]

Er schrieb er braucht ein Datum.
Genaue Anforderungen ? - Unbekannt

Er weiss aber nicht wie er Den Abgleich machen soll.

Wenn er jetzt einfach immer nur Stur die Zeit vom DCF77 Empfänger 
übernimmt kann das bei grösseren Sprüngen in die Hose gehen.

Obiges macht nicht viel Aufwand und tut sein gedöhns, wie er das gerne 
hätte, simpelst gerade rechnen.

Aber ohne das er sich hier nochmal meldet lohnt es sich nicht darüber 
nachzudenken ;)