Ich möchte das Pendel einer Uhr zu DCF77 synchronisieren. Lassen wir den mechanischen Teil über einen kleinen Elektromagneten mal außen vor. Mir geht es hauptsächlich um die Bereitstellung eines genauen, jitterarmen Sekundentaktes. Über einen DCF77 Empfänger bekommt man zwar auf lange Sicht einen stabilen Sekundentakt, allerdings jittert das um ein paar ms hin und her. Diesen Jitter möchte ich am Pendel nicht haben. Also könnte man sich eine PLL vorstellen die einen 1Hz Oszillator so nachstellt, dass er den DCF77 Signalen folgt aber nur sehr langsame Änderungen des Referenzoszillators zulässt. Implementiert werden soll das in Software auf einem Cortex M3. Hat jemand so eine ähnliche Aufgabe schon mal gehabt bzw. gelöst?
:
Gesperrt durch Moderator
Ich hab mal vor langer Zeit das DCF77 Signal einer UART (50bd) in C ausgewertet und damit ein Zeit-Server gefüttert. Statt dessen ein Pendelantrieb triggern tönt trivial. Die Genauigkeit üblicher µC/Quarze sollte Deine Jitterforderung erfüllen.
Viele GPS-Empfänger haben einen PPS-Ausgang (ein präziser Sekundentakt). Der ist für diesen Zweck einfacher nutzbar.
Ein freischwingendes passendes Pendel ist doch schon ein mechanischer 1Hz Oszillator. Den mit ein bischen Jitter zu verstimmen dürfte aufwendiger sein als Du vermutest.
NichtWichtig schrieb: > Die Genauigkeit üblicher µC/Quarze sollte Deine Jitterforderung > erfüllen. Macht sie natürlich. Es geht ja darum das per Quarz erzeugte Signal (langzeit) synchron zu DCF77 zu halten. Man kann da also nicht in groben Sprüngen ausgleichen sondern nur schön langsam.
Horst schrieb: > Ein freischwingendes passendes Pendel ist doch schon ein mechanischer > 1Hz Oszillator. Den mit ein bischen Jitter zu verstimmen dürfte > aufwendiger sein als Du vermutest. Ja, das ist ein berechtigter Einwurf. Da macht dann der Versuch klug, den es aber erst noch geben muss.
temp schrieb: > Ich möchte das Pendel einer Uhr zu DCF77 synchronisieren. Warum auch immer... > Über einen DCF77 Empfänger bekommt man zwar auf lange > Sicht einen stabilen Sekundentakt, allerdings jittert das um ein paar ms > hin und her. Diesen Jitter möchte ich am Pendel nicht haben. Also könnte > man sich eine PLL vorstellen die einen 1Hz Oszillator so nachstellt, > dass er den DCF77 Signalen folgt aber nur sehr langsame Änderungen des > Referenzoszillators zulässt. Kann man machen, geht aber sicherlich auch sehr viel einfacher (auch wenn im Prinzip natürlich dasselbe rauskommen wird). Aber selbst, wenn man es wirklich nach Schulbuch so macht, ist > Cortex M3. Dafür maßlos überdimensioniert. Die verfügbare Rechenleistung steht in einem völlig unvernünftigen Verhältnis zur klitzekleinen Aufgabe. Das ist was für einen kleinen 8-Bitter. Aber natürlich kann man auch mit einem 40-Tonner zum Bäcker fahren, um die Sonntags-Brötchen für die Familie zu holen. Es wird funktionieren. Wenn man grundsätzlich fahren kann...
Wenn die DCF-Sendefrequenz von 77,5kHz auch aus dem Zerfallsprozess der Cäsiumatome generiert wird, dann könnte man damit einen freischwingenden 77,5kHz Oszillator über eine PLL synchronisieren (BB204 mit einem großen Tiefpass davor). Als Frequenzvergleicher genügt ein CD4046. Die Schwierigkeit besteht jetzt aber darin, diese neu gewonnenen jitterfreien 77,5kHz wiederum jitterfrei auf 1Hz runterzuteilen. An der Stelle beißt sich die Katze in den eigenen Schwanz.
c-hater schrieb: > Dafür maßlos überdimensioniert. Die verfügbare Rechenleistung steht in > einem völlig unvernünftigen Verhältnis zur klitzekleinen Aufgabe. > > Das ist was für einen kleinen 8-Bitter. > > Aber natürlich kann man auch mit einem 40-Tonner zum Bäcker fahren, um > die Sonntags-Brötchen für die Familie zu holen. Es wird funktionieren. > Wenn man grundsätzlich fahren kann... Troll dich und spiel weiter mit deinem avr Assembler. Das war hier nicht die Frage und was ich mit den Sachen mache die ich rumliegen habe geht dich genau nichts an. c-hater schrieb: > Warum auch immer... Auch das geht dich ganz speziell nichts an und das werde ich auch nicht diskutieren.
Horst schrieb: > Ein freischwingendes passendes Pendel ist doch schon ein > mechanischer 1Hz Oszillator Leider nein, sondern 1.001 oder 0.99995 Hz. Und Pendel verstimmen sich hauptsächlich durch die Wärmeausdehnung der Pendellänge. Man muss dann entweder die Pendellänge oder das Pendelgewicht ändern. Da Pendelgewicht wohl schwierig ist, wohl besser die Pendellänge, um sehr kleine Beträge, z.B. ebenfalls durch Wärmeausdehnung.
MaWin schrieb: > Man muss dann entweder die Pendellänge oder das Pendelgewicht ändern. > > Da Pendelgewicht wohl schwierig ist, wohl besser die Pendellänge, um > sehr kleine Beträge, z.B. ebenfalls durch Wärmeausdehnung. Oder das Pendel zum synchronisieren mit geringer Energie abbremsen bzw. "anschubsen". Klar, damit kann man nur geringe Abweichungen ausgeglichen.
MaWin schrieb: > Und Pendel verstimmen sich hauptsächlich durch die Wärmeausdehnung der > Pendellänge. > Man muss dann entweder die Pendellänge oder das Pendelgewicht ändern. Oder die Amplitude; man darf doch davon ausgehen, dass nur Temperatur- und Druckschwankungen ausgeregelt werden müssen. Wobei man die Temperatur auch konstant halten könnte.
Helmut Hungerland schrieb: > könnte man damit einen freischwingenden > 77,5kHz Oszillator über eine PLL synchronisieren (BB204 mit einem großen > Tiefpass davor). Als Frequenzvergleicher genügt ein CD4046. > > Die Schwierigkeit besteht jetzt aber darin, diese neu gewonnenen > jitterfreien 77,5kHz wiederum jitterfrei auf 1Hz runterzuteilen. Mit dieser Lösung sehe ich den Schiffbruch schon kommen; das dürfte ein größerer Eisberg sein, als der, der die Titanic zum Sinken brachte. Die Schwierigkeit besteht vielmehr in der Integration des empfangenen DCF-Signals. Die Phasen-Schwankungen am Tag sind noch "Kindergarten", in der Dunkelphase/Nacht wird es erst richtig problematisch. Da muss man mit Integrations-Zeitkonstnaten von etlichen Stunden rangehen. Das geht absolut nur digital; jede analoge Lösung versagt an dieser Stelle. Das kann ein uC mit passender SW sicherlich...
:
Bearbeitet durch User
Interessantes Problem... wie kommt man auf sowas? Wenn der DCF-Jitter schon ein Problem ist, handelt es sich vermutlich nicht um eine Wohnzimmeruhr, oder? Um den cycle-to-cycle-Jitter aus dem pps rauszufiltern, kannst du die Periodendauer mitteln, und den Mittelwert über z.B. die letzten 10 Zyklen (oder vieviele auch immer) dann als Periodendauer für einen Timer nutzen, der die Pendelfrequenz hinzieht. Allerdings ist die Frage, ob das Pendel nicht schon von alleine eine solche Tiefpasswirkung hat. Pendel sind ja aus dem Grund meistens recht schwer, um kleine Störungen wegzubügeln. Zudem kann es sein, dass du dir durch Softwareeffekte im Prozessor einen noch größeren Jitter einfängst, z.B. wenn die Auflösung der Counter/Timer nicht groß genug ist. Ist eine Phasenverschiebung zwischen Pendel und dem DCF-PPS erlaubt?
temp schrieb: > Troll dich und spiel weiter mit deinem avr Assembler. Ich spiele auch mit anderen Sachen. Genau deswegen kann ich auch den ganzen Schwachsinn ermessen, den der Einsatz eines M3 an dieser Stelle darstellt. > Das war hier nicht > die Frage und was ich mit den Sachen mache die ich rumliegen habe geht > dich genau nichts an. Doch, geht mich was an. Seit dem Moment, als du es in einem öffentlichen *DISKUSSIONS*-Forum gepostet hast. Wenn dir nicht klar ist, was der Begriff Diskussion bedeutet, dann lies' einfach nach. > Auch das geht dich ganz speziell nichts an und das werde ich auch nicht > diskutieren. Sehr interessant. Du postest also in ein Diskussionsforum mit der festen Absicht, nicht zu diskutieren? Mir scheint, der Unsinn hat Methode. Troll?
Nachtrag: Den Sekundenimpuls vom DCF kannst du eh inder Pfeife rauchen; heißt: Garnicht erst probieren, den als Ref zu nehmen, sondern nur die Trägerschwingung. ^^
Pendel Mutteruhren in Großanlagen wurden schon anfangs der 1900er Jahr ferntechnisch synchronisiert. Hier einige Referenzen und durchgeführte Methoden: https://wp.clockdoc.org/search-the-document-archive/ https://clockdoc.org/Default.aspx?aid=4872 https://clockdoc.org/gs/handler/getmedia.ashx?moid=33100&dt=3&g=1 https://clockdoc.org/gs/handler/getmedia.ashx?moid=33099&dt=3&g=1 https://clockdoc.org/gs/handler/getmedia.ashx?moid=23684&dt=3&g=1 https://www.elektrouhren-freaks.de/elektrouhren/uhrenanlagen/rft-uhrenanlage-metall/index.html http://www.muenchen-surf.de/remuc/synchronome/synchronome.html https://at.vvikipedla.com/wiki/William_Hamilton_Shortt https://docplayer.org/111912702-F-m-fedchenko-und-seine-astronomischen-pendeluhren.html https://patents.google.com/patent/DE202007000557U1/de https://docplayer.org/24514566-Synchronisation-von-pendeluhren-und-metronomen-vortrag-von-fabian-hannig.html http://www.uhrenhanse.org/sammlerecke/elektro/eu_viredaz/Elektrische%20Grossuhren_021110.pdf https://collections.rmg.co.uk/collections/objects/79644.html https://wp.clockdoc.org/animations/ http://www.brandt-uhren.de/entwicklungen.html
MaWin schrieb: > Man muss dann entweder die Pendellänge oder das Pendelgewicht ändern. Gewicht?! Das reale Pendel verhält sich asynchron zum Pendelausschlag. Je weniger "ideal" das Pendel in der Massenverteilung ist (Gewicht vs Aufhängung/Arm), um so größer der Einfluss. Ob das ausreicht, hier was zu bewirken ... kA.
temp schrieb: > Ich möchte das Pendel einer Uhr zu DCF77 synchronisieren. Welche Stabilität peilst du überhaupt an?
Michael M. schrieb: > Den Sekundenimpuls vom DCF kannst du eh inder Pfeife rauchen; heißt: > Garnicht erst probieren, den als Ref zu nehmen, sondern nur die > Trägerschwingung. ^^ Nö. Über hinreichend lange Zeiträume geht das schon recht gut. Aber klar, die Verwendung des Trägers erlaubt natürlich wesentlich bessere Kennwerte. Allerdings wäre auch dafür ein kleiner 8-Bitter noch locker schnell genug... Aber der TO hat sich ja (trotz entsprechender Rückfragen) bisher nichtmal dazu geäußert, was ihm eigentlich an Kennwerten vorschwebt. Ist halt wohl nur ein Troll.
temp schrieb: > Oder das Pendel zum synchronisieren mit geringer Energie abbremsen bzw. > "anschubsen Blödsinn, das bringt Jitter, genau den will er ja loswerden. Bauform B. schrieb: > Oder die Amplitude; Nein, natürlich NICHT, das ist die Grundlage des Pendels dass die Schwingungsfrequenz nicht von der Amplitude abhängt. Diese Ahnungslosigkeit hier ist frappierend, das deutsche Bildungssystem hat an dir versagt.
MaWin schrieb: > Bauform B. schrieb: >> Oder die Amplitude; > > Nein, natürlich NICHT, das ist die Grundlage des Pendels dass die > Schwingungsfrequenz nicht von der Amplitude abhängt. Diese > Ahnungslosigkeit hier ist frappierend, das deutsche Bildungssystem hat > an dir versagt. https://de.wikipedia.org/wiki/Pendel
c-hater schrieb: >> Den Sekundenimpuls vom DCF kannst du eh inder Pfeife rauchen; heißt: >> Garnicht erst probieren, den als Ref zu nehmen, sondern nur die >> Trägerschwingung. ^^ > > Nö. Über hinreichend lange Zeiträume geht das schon recht gut.... Wieder nöö... Wie lange willste denn dann integrieren? Die PTB spricht selbst von Unsicherheiten bis zur Größenordnung von 100us, und zwar bei Empfang der Bodenwelle. Im Grenzgebiet Boden-/Raumwelle wird's dann interessant, weiter entfernt noch viel mehr.
Das Pendel des TOs muss, wenn es synchron zum Sekundentakt des DCF77 laufen soll, in der Geschwindigkeit beeinflusst werden. Ist dann selbstverständlich kein Pendel im klassischen Sinn mehr. Für die Aufgabe sollte ein ATTiny o. ä. ausreichend sein. Gegen anständige Entlohnung, die auf dem µCNet nicht zu erwarten ist, kann ich ein passendes Programm schreiben.
DCF77 direkt zu nehmen, ist ne ganz blöde Idee. Man weiß dann nicht, ob man die Pendeluhr mit dem Fernseher, Staubsauger, Gewitter oder sonstwas synchronisiert. Die richtige Lösung ist daher, eine Quarzuhr zu nehmen, um zu prüfen, ob das Signal fehlerfrei ist und nur dann damit die Quarzuhr zu stellen. Man kann auch automatisch Gangfehler des Quarzes korrigieren, indem man den 32kHz Teiler mal um 1 verkürzt oder verlängert. Das ist mit Sicherheit weniger Jitter, als eine PLL macht. Den Korrekturwert legt man im EEPROM ab. Je länger man den Korrekturwert mißt, umso genauer wird die Quarzuhr. Und die Quarzuhr erzeugt dann die garantiert sauberen Pulse für das Pendel.
Peter D. schrieb: > Die richtige Lösung ist daher, eine Quarzuhr zu nehmen,... Wenn ich die Fragestellung des Themenstarters recht wörtlich nehme und einräume, dass dieser geforderte Sek.-Takt nicht unendlich stabil und genau sein muss (könnte er vlt nochmal preisgeben?): Ein sehr guter OCXO + Teilerkette täte es auch; man muss ihn dann nur auch regelmäßig an einem Sekundärnormal kalibrieren.
Angehängte Dateien:
-
Modern_TN_master__3_.jpg
48 KB
Die gezeigte elektronisch angetriebene Pendelmutteruhr läßt sich mit einem DC-Strom in der oberen Antriebsspule in der Nähe der Pendelaufhängung fremdsteuern. Diese Spule treibt über die Impulse von der Elektronik auch das Pendel an. Der Pendelnulldurchgang wird durch den Aluminiumbügel unten der durch Rückkopplungsunterbrechung einen Kontrolloszillator steuert, erkannt und zum Antrieb und Sklavenuhren Impulserzeugung herangezogen. Ich habe so eine Uhr bei mir im Betrieb und die Fernsteuerung funktioniert prinzipiell obwohl ich nicht die Notwendigkeit einer externen Synchronisation dazu sehe weil die Uhr im Monat alleine einige Sekunden genau ist. Im Jahr gleichen sich die kleinen Gangunregelmäßigkeiten aus und es läßt sich bei sorgfältiger Einstellung des DC-Kontrollstroms mit dem Trimpoti eine unabhängige Genauigkeit von ca. einer Minute per Annum(!) erzielen. Das Pendel ist aus Invarstahl gemacht und weitgehend temperaturstabil. Da ist auch ein DS3131 nicht wesentlich besser. https://clockdoc.org/Default.aspx?moid=49041 Was mich betrifft, finde ich die gewollte Synchronisation als etwas kontraproduktiv weil gerade die unabhängig mögliche hohe Ganggenauigkeit einer Präzisionspendeluhr den Reiz der Anordnung ausmacht.
:
Bearbeitet durch User
Peter D. schrieb: > DCF77 direkt zu nehmen, ist ne ganz blöde Idee. Will er ja garnicht. Insofern ist das im OT dargelegte Konzept durchaus schlüssig. Das kann und wird funktionieren. Fraglich ist eigentlich nur, welche Kennwerte der Ziel-Schwinger (also das Pendel) damit erreichen kann und vor allem: welche eigentlich gefordert sind. > Man kann auch automatisch Gangfehler des Quarzes korrigieren, indem man > den 32kHz Teiler mal um 1 verkürzt oder verlängert. Das ist mit > Sicherheit weniger Jitter, als eine PLL macht. Du hast offensichtlich nicht verstanden, dass dein Konstrukt letztlich auch nur eine PLL (oder vielmehr FLL) ist. Was aber letztlich naturgemäß so ziemlich auf's Selbe hinausläuft, da wechselseitig ineinander transformierbar. Nur zwei Betrachtungsweisen ein und derselben Sache.
MaWin schrieb: > Nein, natürlich NICHT, das ist die Grundlage des Pendels dass die > Schwingungsfrequenz nicht von der Amplitude abhängt. Diese > Ahnungslosigkeit hier ist frappierend, das deutsche Bildungssystem hat > an dir versagt. Einzig und allein von der Pendellänge!!! t = 2 π √ l / g Wir dürfen mal g als stationär konstant ansehen. Controller, Software, alles pillepalle. Ich sehe eher das Problem hier die Pendellänge zu verändern. Ein Ansatz wäre das Gewicht an einen u-förmig verlaufenden Draht zu hängen und mit einem geregelten Strom durch den Draht die Länge zu ändern. Das wird interessant, vórher ein bischen rechnen wäre angebracht.
Nochmal schrieb: > Wir dürfen mal g als stationär konstant ansehen. Ooops... Die Existenz von Gezeiten sagt etwas deutlich anderes aus. Offensichtlich ist g doch von erheblicher Variabilität. Und ich würde meinen Arsch darauf verwetten, dass auch Pendel darauf (leicht messbar) reagieren werden. Umso spannender wird das Warten auf die Ansage des TO-Troll, was genau er eigentlich erreichen möchte...
Was ist eigentlich mit Berücksichtigung der Latenz ab DCF77? Müsste doch nö Verzögerung über die Laufzeit (Signalerzeugung-> Sender-> Empfänger-> Verarbeitung/Ausgabe) drin sein?
german-bash.org/356836 schrieb: > Was ist eigentlich mit Berücksichtigung der Latenz ab DCF77? Müsste > doch nö Verzögerung über die Laufzeit (Signalerzeugung-> Sender-> > Empfänger-> Verarbeitung/Ausgabe) drin sein? Ich weiß nich? Auch noch die Urzeit übers Pendel einstellen, wird dann wohl doch deutlich zu lange dauern. ;D
c-hater schrieb: > Und ich würde meinen Arsch darauf verwetten, dass auch Pendel darauf > (leicht messbar) reagieren werden. Hier sind ein paar Berichte: https://hgss.copernicus.org/articles/11/215/2020/ http://trin-hosts.trin.cam.ac.uk/clock/theory/rcl_report.pdf http://leapsecond.com/hsn2006/pendulum-tides-ch1.pdf
german-bash.org/356836 schrieb: > Was ist eigentlich mit Berücksichtigung der Latenz ab DCF77? > Müsste > doch nö Verzögerung über die Laufzeit (Signalerzeugung-> Sender-> > Empfänger-> Verarbeitung/Ausgabe) drin sein? Wie Peter schon ausgeführt hat, ist es dringend notwendig zuerst die andauernden Phasenstörungen des Langwellensignals durch eine sehr langsame Nachführungsschleife ueber viele Stunden zu stabilisieren damit die Phase des Pendels nicht andauernd unregelmäßig gestört wird. Ich habe die Laufzeitvariationen von WWVB auf 60kHz beobachtet und es treten stetig Laufzeitstörungen der 60kHz Welle von einigen +/- PI auf. Ohne mehrstündige Mittlung macht man das Pendel direkt nur schlechter. Wer das auf dem Oszi gegen einen lokalen Standard vergleicht weiß genau von was ich rede. Deshalb rate ich, die Wellenausbreitungsgewohnheiten ausreichend genau zu studieren. Die Wellen haben relativ zu einem lokalen Standard keine Phasenstarrheit. Auch bei GPS Nachführung sind lange Mittelungsperioden notwendig um hohe Genauigkeiten erzielen zu können.
MaWin schrieb: > Bauform B. schrieb: >> Oder die Amplitude; > > Nein, natürlich NICHT, das ist die Grundlage des Pendels dass die > Schwingungsfrequenz nicht von der Amplitude abhängt. Diese > Ahnungslosigkeit hier ist frappierend, das deutsche Bildungssystem hat > an dir versagt. halte den Ball lieber flach, die Schwingungsdauer hängt durchaus auch von der Amplitude ab. Die Formel aus der Schule ist nur eine Näherung für kleine Amplituden. Mit zunehmender Amplitude wird die Schwingungsdauer größer, weil die Rückstellkraft bei einem Pendel nicht proportional zur Auslenkung ist.
Nochmal schrieb: > Ein Ansatz wäre das Gewicht an einen u-förmig verlaufenden Draht zu > hängen und mit einem geregelten Strom durch den Draht die Länge zu > ändern. Oder einfach nur den Schwerpunkt des Pendels künstlich verändern, indem man am unteren Totpunkt (max. kinetische Energie) einen Elektromagneten ohne Eisenkern auf eine Grundplatte platziert, der einen am Pendel angebrachten Permanentmagneten anzieht. Dadurch wird die Pendelfrequenz leicht erhöht. Wenige mA könnten schon ausreichen. Der E-Magnet muss nicht im Takt des Pendels geschaltet werden. Ein kontinuierlicher Gleichstrom genügt. Der Strom sollte sich lediglich innerhalb von Stunden leicht rauf oder runter regeln lassen.
Wer Interesse an Pendeluhr Engineering Design hat, findet hier viel: https://www.amazon.ca/Accurate-Clock-Pendulums-Robert-Matthys/dp/0198529716 Ich kaufte dieses Buch vor Jahren für wesentlich weniger Geld. In diesem Buch wird in Detail auf alle wichtigen Designaspekte eingegangen. Obwohl ich im Augenblick keine Zeit habe, habe ich vor ein paar Jahren ein Pendeluhrprojekt mit digitaler/optischer Steuerung eines Pendels nach dem Hipp Impuls Verfahren angefangen. Der Pendelausschlag wird digital gemessen und wenn der Ausschlag einen gewissen Grenzwert unterschreitet, dann alle paar Minuten, gemessen durch einen elektromagnetisch induzierten Impuls, wieder angestoßen. Ja, dieses Projekt basiert auf uC Steuerung;-) Allerdings ist das Pendel immer freischwingend und die Digitalsteuerung ist nur für den Energiehaushalt des Pendels verantwortlich und Uhrwerkschaltimpulserzeugung. Um Pendelungenaugigkeiten durch Isochronismusfehler zu minimieren wird die Ausschlagauslenkung unter +/- 2 Grad gehalten. Das Invarpendel hat eine 0.75s Periode. Der uC synthetisiert durch FW ein 1s Pendel Impuls für die Steuerung des Uhrwerks durch die ohnehin notwendige Errechnung der Pendelperiode. Auf diese Weise ist die Anordnung etwas kleiner und braucht keinen so schweren Pendelkörper. Das Pendel ist vollkommen freischwingend und der Ausschlagwinkel wird optisch gemessen und kontrolliert. Synchronisation ist über den uC möglich der behutsam das Pendel bremsen oder beschleunigen kann um die Phase des Pendels angleichen und an eine genaue Zeitreferenz anbinden zu können. Die natürliche Periode des Pendels wird nach genauer Einstellung nicht mehr verändert. An sich sollten Pendeluhren in konstanten Unterdruck betrieben werden um die atmosphärisch-barometrischen Schwankungen des Pendelkörperauftriebs zu vermeiden.
:
Bearbeitet durch User
Helmut Hungerland schrieb: > Oder einfach nur den Schwerpunkt des Pendels künstlich verändern Oder einfach nur die Länge des Pendels künstlich verändern. Andere Leute bauen aufwendig temperaturkompensierte Pendel und versuchen die Umgebungstemperatur konstant zu halten. Also befindet sich ein Pendel klassischer Weise in einem heizbaren Gehäuse. Wenn man statt Invar Alu verwendet, kann man mit der Heizung die Frequenz einstellen. Leider war das überhaupt nicht die Frage: temp schrieb: > Ich möchte das Pendel einer Uhr Eigentlich wäre mal ein Foto dieser Uhr angesagt...
Beitrag #6696296 wurde von einem Moderator gelöscht.
Helmut Hungerland schrieb: > Wenn die DCF-Sendefrequenz von 77,5kHz auch aus dem Zerfallsprozess der > Cäsiumatome generiert wird Da machen wir uns aber bitte nochmal schlau wie das Cäsium Frequenznormal funktioniert.
Zu viele Vollidioten schrieb: > Helmut Hungerland schrieb: >> Wenn die DCF-Sendefrequenz von 77,5kHz auch aus dem Zerfallsprozess der >> Cäsiumatome generiert wird > > Da machen wir uns aber bitte nochmal schlau wie das Cäsium > Frequenznormal funktioniert. Viel lustiger wäre es, wenn Er sich über die Atomare-Zerfallsprozesse informieren würde! ;D
Angehängte Dateien:
-
DCF77-Sender.png
26 KB
Jetzt seid doch nicht so pingelig mit den Worten. Natürlich wird auch die Trägerfrequenz aus Caesium gemacht ;) https://www.ptb.de/cms/fileadmin/internet/fachabteilungen/abteilung_4/4.4_zeit_und_frequenz/pdf/2004_Piester_-_PTB-Mitteilungen_114.pdf
Aus meiner Sicht ist die 99€-Frage noch nicht beantwortet! Welche Frequenz hat Dein Pendel überhaupt? Alles was aus einer DCF77-Uhr herauskommt hat was mit 77,5kHz, 1S oder 1Min. (gap) zutun. Ich glaube nicht, dass ein "normales" Pendel irgendwas damit anfangen kann. Willst Du das aber herunterteilen, so relativiert sich auch ein eventueller Jitter sehr stark.
Zu viele Vollidioten schrieb: > Da machen wir uns aber bitte nochmal schlau wie das Cäsium > Frequenznormal funktioniert. Ich bin ja schon froh, dass ich das Element Cäsium richtig geraten habe, geschweige denn richtig geschrieben habe. 😄
Da ich hier eine ganz schöne Lavine losgetreten habe, ein paar Klarstellungen. Das Pendel ist das Pendel unserer Kirchturmuhr. Ausgehend von diesem Gerät: http://www.brandt-uhren.de/entwicklungen.html soll das um das automatische Stellen der Uhr erweitert werden. Es ist auch kein kommerzielles Projekt sondern Selbsthilfe in der Kirchgemeinde. Der Herr von Brand-Uhren hat da auch ein Patent drauf wo das Prinzip erleutert wird. Wie gesagt, es geht hier nicht um dieses Prinzip, sondern nur um einen gleichmäßigen Sekundentakt der nicht mehr als eine Sekunde vom DCF77 abweicht. Nach meinem Wald und Wiesen DCF Empfänger messe ich einen Jitter von bis zu 5ms, was mir recht lang erscheint. Ob das problematisch ist, wird der Versuch zeigen. Bei DCF muss man ja auch mit Störungen oder Ausfällen rechnen. Klar mit einem besseren Quarz oder Oszillator würde das ganze Problem erst garnicht auftreten. Allerdings ist da übers Jahr sicher von -20°C bis +40°C alles möglich. Das Stellen soll über gezieltes Anhalten und Freigeben des Pendels erfolgen, aber dieser Part steht hier nicht zur Debatte. Und ja, es wird in Kauf genommen, dass die Uhr auch mal max. 12 Stunden steht bevor sie wieder in die richtige Zeit einrastet. (Sommer- Winterzeitumstellung). Jetzt muss sich nach jedem Stromausfall jemand die vielen steilen Treppen hochquälen. Und wenn der eine der das im Dorf macht im Urlaub ist, steht die Uhr auch mal ne Woche. Um nochmal auf den Anfang zurück zu kommen, mir geht es darum einen Sekundentakt aus einem Quarz zu generieren und den (wenn vorhanden) mit DCF77 zu synchronisieren. Die absolute Phasenlage spielt natürlich keine Rolle. Die Anzahl der Sekunden soll aber innerhalb eines halben Jahres nicht von der DCF Zeit abweichen. Hinkriegen tue ich das auch alleine, ich wollte nur nicht eine simple existierende Lösung übersehen. Und bitte keine Diskussion über Controllertypen. Ich habe im letzten Jahrtausend lange genug AVRs und PICs eingesetzt, deren Zeit ist für mich endgültig vorbei, selbst für einfachste Sachen.
c-hater schrieb: > Die Existenz von Gezeiten sagt etwas deutlich anderes aus. > Offensichtlich ist g doch von erheblicher Variabilität. Setzen 5. Nein ich erkläre es Dir nicht!
Bauform B. schrieb: > Eigentlich wäre mal ein Foto dieser Uhr angesagt... Was hat das mit meiner Ausgangsfrage zu tun? Die bezog sich absichtlich auschließlich um einen Sekundentakt der softwareseitig mit DCF77 syncrcroniesiert werden soll, und das ohne Sprünge in Phase und Frequez. Punkt. Alles andere war nicht gefragt und ich werde es auch nicht mehr weiter beantworten oder kommentieren. Dann macht den Thread zu aber nervt nicht mit Abhandlungen wie man ein Pendel leichter oder schwerer macht o.ä.
temp schrieb: > Um nochmal auf den Anfang zurück zu kommen, mir geht es darum einen > Sekundentakt aus einem Quarz zu generieren und den (wenn vorhanden) mit > DCF77 zu synchronisieren. Ich würde vorschlagen es besser mit GPS zu machen. Fast jedes GPS hat einen hochgenauen Sekundenimpuls mit Jitter im us bzw. ns Bereich und dürfte für diese Anwendung zuverlässig genug sein. Warum den ganzen DCF77.5 Aufwand? Der Vollständigkeit halber: In England hatten sie den leistungsfähigen Pulsesynetic Waiting-Train Kraftuhrwerk der minütlich ein paar Sekunden vor der vollen Minute in den Leerlauf gebracht wurde und dann mit dem Eintreffen der genauen Minutenkennung dann wieder freigegeben wurde. Das Uhrwerk wurde absichtlich etwas schneller eingestellt. Das schwere Pendel hatte genug Kraft für so ziemlich alle großen Turmuhrzeigerwerke. Soll sich sehr bewährt haben und könnte auch heute noch mit modernen Zeit-normalen getriggert werden. Wer Interesse daran hat, kann hier nachsehen: https://youtu.be/zw5_8jjyCMw https://waitingtrain.blogspot.com/2008/08/wating-train-mechanism.html https://waitingtrain.blogspot.com/2014/08/ https://waitingtrain.blogspot.com/2008/09/wt-video.html
:
Bearbeitet durch User
c-hater schrieb: > Was aber letztlich naturgemäß > so ziemlich auf's Selbe hinausläuft Nö. Ein Quarz mit nachgeführtem Teiler hat viel weniger Jitter, als ein RC-Oszillator, z.B. im CD4064. Der Hauptpunkt ist aber, daß ein MC als Quarzuhr erstmal prüft, ob der DCF77-Empfänger nicht Mumpitz empfängt und damit die Pendeluhr nur aufs Glatteis geführt wird. Im worst case kann die Pendeluhr dabei sogar stehen bleiben.
Ist es nicht möglich die Pendluhr stillzulegen und den eigentlichen Antrieb selber mit Pulsen zu füttern. So Spielzeuge, wie in Deinen Bildern gezeigt, können keine Kirchenuhr antreiben. Allerdings könnten sie den Takt angeben. Also sag (zeig) mal was die Uhr wirklich am Leben hält. Von da her könnte auch ein Foto hilfreich sein.
temp schrieb: > Troll dich und spiel weiter mit deinem avr Assembler. Das war hier nicht > die Frage und was ich mit den Sachen mache die ich rumliegen habe geht > dich genau nichts an. Du bist ein grober Flegel, willst eine Idee und vergreifst Dich im Ton. Teo schrieb: > Zu viele Vollidioten schrieb: >> Da machen wir uns aber bitte nochmal schlau wie das Cäsium >> Frequenznormal funktioniert. > Viel lustiger wäre es, wenn Er sich über die Atomare-Zerfallsprozesse > informieren würde! ;D Auch, wenn es Dir nicht gefällt, er hat Recht, man integriert über mehrere Tage, um Stabilität zu erzielen. Bei käuflichen Frequenznormalen ist es üblich, den Sekundentakt zu verwenden. Gerhard O. schrieb: > Ich würde vorschlagen es besser mit GPS zu machen. Fast jedes GPS hat > einen hochgenauen Sekundenimpuls mit Jitter im us bzw. ns Bereich und > dürfte für diese Anwendung zuverlässig genug sein. Warum den ganzen > DCF77.5 Aufwand? Nee. GPS funktioniert nur dann sauber, wenn man eine Außenantenne mit freier Sicht hat und auch da fährt man Integrationszeiten von zumindest mehreren Stunden. DCF77 ist in Deutschland auch Indoor gut empfangbar - wenn die Antenne schmalbandig ist und man nicht Unmengen an Schaltnetzteilen im Umfeld hat.
temp schrieb: > es geht hier nicht um dieses > Prinzip, sondern nur um einen gleichmäßigen Sekundentakt der nicht mehr > als eine Sekunde vom DCF77 abweicht. Also erwartest du eine zu DCF synchron laufende Uhr, die jederzeit weniger als eine einzige Sekunde abweicht. Brauchst du auch die absolute Zeitinformation (von DCF) oder nur den Takt? Gut, ob man die Genauigkeit für eine Kirchturmuhr unbedingt braucht, lasse ich mal dahingestellt... ;-) Warum bist du so "erschrocken", dass dein "Simple"-Empfänger 5 ms Jitter zeigt? Das ist bei einfachen Schaltungen nun mal so; jedoch würde dieser dein Problem doch schon lösen, oder verstehe ich das nicht richtig? Folgendes ist wesentlich schlimmmer: > Bei DCF > muss man ja auch mit Störungen oder Ausfällen rechnen. Das kannst du nur umgehen, wenn du einen Quarz mit dem (irgendeinem) Normal synchronisierst und den gewünschten Takt ableitest. > Klar mit einem > besseren Quarz oder Oszillator würde das ganze Problem erst garnicht > auftreten. Allerdings ist da übers Jahr sicher von -20°C bis +40°C alles > möglich. Die Temperaturschwankungen lassen sich sicher "wegdämpfen". Fragen: Wie oft darf die Apparatur denn "Pflege" im Jahr beanspruchen? Gar nie mehr oder ein bis zwei Male pro Jahr? Muss es DCF sein oder ist ein anderes Normal auch denkbar? EDIT: Auf's Jahr gesehen: Ein Jahr zählt gut 31,5 Mio. Sekunden. Ein OCXO (auch einfache, nicht soo teure) erreicht immer eine Stabilität von weniger als 1exp(-8), mit ein wenig Aufwand eine Potenz niedriger. Das würde (Irrtum vorbehalten) im Jahr eine Abweichung von 31,6 ms bedeuten. :-)
:
Bearbeitet durch User
Eigentlich ist diese ganze externe Anbindung etwas Overkill. In meiner Wetterstation verwende ich eine DS1304 RTC. Ich baute sie vor rund acht Jahren ein um den vorherigen DS1306 zu ersetzen. Seitdem habe ich den RTC nicht mehr nachgestellt. Im Augenblick ist die Abweichung nach acht Jahren gerade mal 71s. Dabei ist die RTC Temperaturextremen von -46 Grad bis +35 Grad ausgesetzt gewesen und die Langzeitkonstanz finde ich zumindest adäquate. Eine Turmuhr würde mit dieser Langzeitgenauigkeit durchaus verwendungsfähig sein. Ich bin nicht so sicher ob diese externe Anbindung viel Sinn hat. Man betreibt ja nicht Astronomie. Jedenfalls hätte auch DCF77.5 bzw GPS nur Sinn mit einem disziplinierten lokalen Standard der dann unabhängig den Sekundentakt ausgibt und nur langfristig vom externen zugelieferten Frequenz-normal nachgestellt wird. Es ist aber ja so ziemlich alles gesagt worden und die Lösung der Aufgabe ist klar. Diese alten Turmuhren sind ein Kulturgut. Es ist schön, daß man vielfach versucht sie zu pflegen und retten. Hier ein nostalgisches "Einsatzbild" einer Waiting-Train Anlage mit Mutteruhr: https://4.bp.blogspot.com/_6k-wLqmhRSk/TQp_804YCFI/AAAAAAAAEaM/P_rpk0zs7G0/s640/wt+images+126+rsz.bmp
Michael M. schrieb: > Das kannst du nur umgehen, wenn du einen Quarz mit dem (irgendeinem) > Normal synchronisierst und den gewünschten Takt ableitest. Das macht doch jeder "normale" Funkwecker so. Einmal nachts wird der Wecker synchronisiert.
Michael M. schrieb: > EDIT: > Auf's Jahr gesehen: > Ein Jahr zählt gut 31,5 Mio. Sekunden. Ein OCXO (auch einfache, nicht > soo teure) erreicht immer eine Stabilität von weniger als 1exp(-8), mit > ein wenig Aufwand eine Potenz niedriger. Das würde (Irrtum vorbehalten) > im Jahr eine Abweichung von 31,6 ms bedeuten. :-) Wolle G. schrieb: > Das macht doch jeder "normale" Funkwecker so. Einmal nachts wird der > Wecker synchronisiert. Das geht bei ihm nicht weil das Pendel mit dem elektronischen Steuergerät bei jedem Nulldurchgang durch Bremsung oder Beschleunigung korrigiert wird. Deshalb ist ein zuverlässiger Sekundentakt ausreichender Genauigkeit andauernd notwendig. Korrektur: Eigentlich ist diese ganze externe Anbindung etwas Overkill. In meiner Wetterstation verwende ich eine DS1304 RTC. Der DS1304 ist falsch - es war ein DS3234 mit SPI.
:
Bearbeitet durch User
OT @Gerhard: Respekt! Danke für die Verlinkungen, damit werde ich wochenlanges Futter haben :D
Michael M. schrieb: > Warum bist du so "erschrocken", dass dein "Simple"-Empfänger 5 ms Jitter > zeigt? Es kommt auf den Empfänger an, Jitter habe ich bei Consumer-Superhets gesehen. Nicht übersehen darf man, dass Funk eine variable Ausbreitungsgeschwindigkeit je nach Wetterlage haben kann. Mein Geradeausempfänger jittert nicht, hat dafür aber eine nicht zu vernachlässigende Laufzeit. Das heißt, dass meine dauersynchrone Digitaluhr etwa 17ms nachgeht. Wolle G. schrieb: >> Das kannst du nur umgehen, wenn du einen Quarz mit dem (irgendeinem) >> Normal synchronisierst und den gewünschten Takt ableitest. > > Das macht doch jeder "normale" Funkwecker so. Ja, und je nach Auslegung mehr oder noch mehr schlecht. > Einmal nachts wird der Wecker synchronisiert. Richtig, das Billigding von Pearl rennt über den Tag 3 Sekunden weg. Für den Wecker ist das gerade noch akzeptabel, für irgendwelche Messungen ...
2aggressive schrieb: > OT > @Gerhard: Respekt! Danke für die Verlinkungen, damit werde ich > wochenlanges Futter haben :D You are welcome;-)
OT: Manfred schrieb: > Mein Geradeausempfänger jittert nicht, hat dafür aber eine nicht zu > vernachlässigende Laufzeit. Das heißt, dass meine dauersynchrone > Digitaluhr etwa 17ms nachgeht. Gegen was verglichen/gemessen?
Möglicherweise willst Du gar keine Synchronisation des Sekundentaktes, sondern eine Synchronisation zwischen der DCF-Uhrzeit mit der "Pendel-Uhrzeit". D.h. Du hast zwei Uhren: Eine "Pendel-Uhr", die mit dem Sekundentakt den Du ganz banal aus dem Quarz vom Mikrocontroller erzeugst, mit dem das Pendel der Kirchenuhr gesteuert wird, zählt. So dass Du immer weißt, wie spät es auf der mechanischen Kirchenuhr ist. Dazu gibt es dann noch eine DCF-Uhrzeit. Die wird durch das Funksignal eben gesteuert, so lange ein DCF-Signal vorhanden ist, zählt sie auch damit, wenn nicht, schaltet auch diese DCF-Uhr auf Quarzbetrieb um. Deine Aufgabe ist nun, die "Pendel-Uhr" zu beschleunigen, falls sie gegenüber der DCF-Uhr nachgeht, oder eben zu bremsen, wenn die "Pendel-Uhr" vorgeht. Diese Beschleunigung und Verzögerung limitierst Du, eben so wie es die Mechanik der Kirchenuhr zulässt. Es gibt noch ein paar Randbedingungen und Sonderfälle, wenn Du die Elektronik startest und Du die genaue Uhrzeit der Pendel-Uhr nicht kennst usw. Nichts was man nicht in den Griff bekommt. Kommt halt auf das gewünschte Verhalten drauf an.
Sorry, mein Text ist wirr. Ich bin müde... Aber das Prinzip sollte klar sein.
Manfred schrieb: > Mein Geradeausempfänger jittert nicht, hat dafür aber eine nicht zu > vernachlässigende Laufzeit. Das kann ich bestätigen. Wenn man so ein LW Signal mit einem lokalen 10MHz Quarzoszillator Standard mittels einem Oszilloskop vergleicht kann man den atmosphärisch bedingten Laufzeitjitter von einigen +/- PI auf 10MHz bezogen beobachten. Natürlich ist der 10MHz Jitter um das 10MHz/60kHz(77.5kHz) Verhältnis multipliziert. Z.B. bei +/- 4 Perioden auf 10MHz (Delta=400ns) wäre dann auf LW (60kHz) der LW Jitter +/- 10ns. (10MHz/60K = 167) Allerdings habe ich von Ft. Collins, Colorado nach Edmonton ein sehr starkes Signal. Die Entfernung von mir ist übrigens rund 1500km. Ich kann z.B. das 60kHz aktiven Ferrit Antenne (Spectracom) Signal direkt am Oszi sehen, so stark ist das Antennensignal. Um Sonnenuntergang und Aufgang herum gibt es stundenlang starke Phasenverwerfungen. Während der Nacht ist das Signal phasenstabil als am Tag. Bei 24-Stündigem Phasenvergleich (Mittag zu Mittag) kann ich die Stabilität eines RB85 Frequenznormals auf einige Stellen um 10e-11 observieren.
:
Bearbeitet durch User
Experte schrieb: > Aber das Prinzip sollte klar sein. Prinzip verstanden, aber dieser Aufwand wird nicht gleich all seine Erwartungen erfüllen, wenn ich mich so an meine DCF77-Empfangerlebnisse mit Störimpulsen erinnere. Im Prinzip muß er alle Signale immer erst gründlich auf Plausibilität prüfen bevor er einen Korrekturversuch an seinem Pendel durchführen kann.
Michael M. schrieb: >> Das heißt, dass meine dauersynchrone Digitaluhr etwa 17ms nachgeht. > Gegen was verglichen/gemessen? Garnicht gemessen, Berechnungen der freundlichen Herren aus Braunschwig, wo ich immer freundlich aufgenommen wurde und von denen das Schaltungskonzept stammt.
Eigentlich ist die Frage des TO ja interessant! Aber um die Pendelfrequenz optimal nach seinen Vorstellungen auf den (langfristig) hochgenauen DCF-Takt zu bringen, sind schon ein paar Randbedingungen zu beachten... - Nachfragen oder Diskussionsansätze werden vom TO (warum auch immer?) giftig abgewehrt. Schade - auch für ihn. Grundsätzlich wäre meine Idee: 1) Möglichst große Masse! das bestimmt nicht die Frequenz, aber vergrößert die Trägheit gegenüber Änderungen der Frequenz. 2) Die Energiezufuhr gegen das Ausklingen der Pulsamplitude sollte nur im Takt der "natürlichen" Pendelfrequenz erfolgen: Ein Sensor erkennt (optisch / magnetisch) den Durchgang der Pendelmasse und führt (magnetisch) etwas Bewegungsenergie dazu. Die Energiezufuhr sollte z.B. durch optische Erkennung der Amplitude auf das notwendige Maß geregelt werden, da die "Pendelformel" nur für kleine Amplituden gilt . 3) Die Pendelfrequenz wird natürlich nur mit den MASSGEBLICHEN Parametern g, oder l reguliert. Die Erdbeschleunigung g können wir nicht beeinflussen - bleibt die Länge l. Da ist Phantasie gefragt: Hängt die Pendelmasse über eine Rolle an einem Seil, könnte man mit einem Stepper mit ORDENTLICH Untersetzung (Schneckentrieb...) die Seillänge beeinflussen. Diese Vorgehensweise würde bei Energieausfall weiter funktionieren - eigentlich müsste sie nur von Zeit zu Zeit aktiviert werden, um Temperatur, Luftdruck, Alterung und sonstige kleine Einflüsse nachzuregeln. Achja - es ging noch um den DCF-Jitter: ECHT Pillepalle! A) 10 MHz MHz Quarzoszillator auf +/- 10...50 ppm abgeglichen. B) Teiler 1 : etwa 10.000.000 (24 Bit), um daraus 1 s zu erzeugen. C) Ist der DCF-Takt zu schnell, wird der Teilerfaktor um 1 Step verringert, ist er zu langsam: + 1 Step. Das mittelt sich locker in wenigen Minuten zurecht: Der Sekundentakt jittert um schreckliche 1/10.000.000 pro Sekunde (Delta_phi = 36 µ°) Ja, mikro-Grad, MILLIONSTEL! Den Digitalteil samt 10 MHz würde ich bequem in einem 14-poligen Tiny24 unterbringen. Ein M3 wird das dann wohl auch wuppen Es könnte natürlich noch der Wunsch aufkommen, dass der Nulldurchgang des Pendels DCF-synchron ist: Woran dreht man da am besten? Auch an der Länge. Wird aber einige Zeit (Stunden?) brauchen. Die Antwort des vergrätzten TOs werden wir wohl nie bekommen. Aber SOOOO interessant ist seine Frage ja auch wieder nicht. Na dann: Gute Nacht
Manfred schrieb: > Du bist ein grober Flegel, willst eine Idee und vergreifst Dich im Ton. Nein ich habe nur keinen Bock auf Controllerdiskussionen und auch nicht damit angefangen. Und schon gleich garnicht vom c-hater, das endet immer gleich. Leute, ich sehe, hier komme ich nicht weiter. Also um es auf den Punkt zu bringen, diskuttiert meinetwegen weiter um Uhren, um GPS oder sonstwas. Die bisherige Diskussion bringt absolut nichts zur Ausgangsfrage. Ich denke ich löse mein Problen selbst, da bin ich schneller fertig als hier die Zeit zu verbraten. Leider ist das hier aber der Normalzustand im Forum. Also Moderatoren, bitte um Schließung des Threads. Kurt schrieb: > Nachfragen oder Diskussionsansätze > werden vom TO (warum auch immer?) giftig abgewehrt. > > Schade - auch für ihn. > ... > Aufzälung Punkt 1 bis 3 sind Antworten auf nicht gestellte Fragen. Ich habe mit Absicht ganz am Anfang nicht konkret erwähnt um was für ein Pendel es geht. Da ich es inzwischen erleutert habe, erübrigt sich die Diskussion darum komplett. An der bestehenden historischen Uhr werden keinerlei irreversible Veränderungen vorgenommen. Nicht mal ein Loch zusätzlich ins Gehäuse darf und wird gebohrt werden. Punkt A bis C der Aufzählung geben die Frage wieder nur anders formuliert. Und beantworten die nicht gestellte Controllerfrage.
temp schrieb: > Ich denke ich löse mein Problen selbst Das wird wahrscheinlich auch am Besten sein. Einige brauchbare Vorschläge gab es ja. Viel Erfolg noch.
temp schrieb:
> Ich denke ich löse mein Problen selbst
Wenn du eine Lösung gefunden hast, bitte hier einen kurzen Bericht
veröffentlichen. Viel Erfolg!
temp schrieb: > Horst schrieb: >> Ein freischwingendes passendes Pendel ist doch schon ein mechanischer >> 1Hz Oszillator. Den mit ein bischen Jitter zu verstimmen dürfte >> aufwendiger sein als Du vermutest. > > Ja, das ist ein berechtigter Einwurf. Da macht dann der Versuch klug, > den es aber erst noch geben muss. Oder man versucht zu Rechnen: 5ms Jitter im Sekundenimpuls bedeutet für die Sinusschwingung des Pendel im Nullpunkt +- 0,0025 * 360 Grad = +- 0,9 Grad. Bei einer Pendelamplitude von +- 250mm legt das Pendel um den Nullpunkt im 5ms eine Strecke von 2*sin(0,9Grad)*250 = 7,85mm zurück. Das ist sicher nicht mehr im vernachlässigbarem Bereich (wenn ich mich nicht verrechnet habe).
Horst schrieb: > Ein freischwingendes passendes Pendel ist doch schon ein > mechanischer > 1Hz Oszillator. Das ist ganz gelinde formuliert einfach nur falsch und großer Käse.
Zu DDR-Zeiten gab es Uhrenanlagen mit 2 Pendeluhren. http://www.ddr-rechentechnik.de/html/uhrenanlagen.html Die Magnetspule zur Synchronisation ist auf etwa halber Pendelhöhe gut zu erkennen. Die linke Uhr erregte durch den Sekundenkontakt den Magnet der rechten Uhr. Bei einer Störung trennte sich die Synchronisation. Nach der Wartung mußten beide Uhren erstmal getrennt justiert werden. Im Betrieb schwangen dann beide Pendel exakt synchron. Man erkennt auch das temperaturkompensierte Pendel. Die Kompensation erfolgte durch die Aufhängung zwischen den beiden Massen.
temp schrieb: > Jetzt muss sich nach jedem Stromausfall jemand die vielen steilen > Treppen hochquälen. Wie soll das mit deinem temp schrieb: > genauen, jitterarmen Sekundentaktes. Ü besser werden ? Stellen geht nach wie vor doch nur manuell: temp schrieb: > Das Stellen soll über gezieltes Anhalten und Freigeben des Pendels > erfolgen Automatisiere lieber diesen Teil, zum Stellen auf die DCF mitgeteilte Zeit, eine Turmuhr hat wohl eh nur einen Minutenzeiger. Und dann lass die Uhr immer (bei Kälte und Wind) etwas zu schnell laufen, dann muss man nur manchmal 1 Minute anhalten (skippen).
Die üblichen Synchronisationsmagnete haben nur wenig Kraft, um die Pendelfrequenz leicht zu ziehen. Das Pendel anhalten und wieder in Gang setzen, können sie nicht. Dazu müßte man einen Servomotor nehmen, der seitlich gegen die Pendelmasse drückt.
Peter D. schrieb: > Dazu müßte man einen Servomotor nehmen, der > seitlich gegen die Pendelmasse drückt. Wie wäre es, das soweit oben wie möglich, mittels Riegel zu stoppen. Das bisschen Energie, das dann fehlt, sollte wohl kein Problem darstellen!(?)
Aber warum Bremsen? Wurde doch schon so oä. vorgeschlagen. Das Pendel etwas zu schnell einstellen und das dann alle paar o. jede Stunde über den Pendelhub nachjustieren.
temp schrieb: > Bei einer > Pendelamplitude von +- 250mm Ein Sekundenpendel mit einer Amplitude von 25cm? klingt unrealistisch
Teo schrieb: > Wie wäre es, das soweit oben wie möglich, mittels Riegel zu stoppen. Man darf nur ganz unten dagegen drücken. Ansonsten wird die Pendelaufhängung zu stark belastet. Zum Anschwingen faßt man ja das Pendel auch unten an und läßt los. Wenn man das Pendel oben anstieß, gabs vom Meister eins hinter die Ohren.
Nochmal schrieb: > MaWin schrieb: >> Nein, natürlich NICHT, das ist die Grundlage des Pendels dass die >> Schwingungsfrequenz nicht von der Amplitude abhängt. Diese >> Ahnungslosigkeit hier ist frappierend, das deutsche Bildungssystem hat >> an dir versagt. > > Einzig und allein von der Pendellänge!!! > t = 2 π √ l / g Das stimmt leider nicht. Diese Formel ist nur eine Annäherung und keine EXAKTE Lösung der Pendelgleichung. > Wir dürfen mal g als stationär konstant ansehen. > > Controller, Software, alles pillepalle. > Ich sehe eher das Problem hier die Pendellänge zu verändern. > Ein Ansatz wäre das Gewicht an einen u-förmig verlaufenden Draht zu > hängen und mit einem geregelten Strom durch den Draht die Länge zu > ändern. > > Das wird interessant, vórher ein bischen rechnen wäre angebracht. Nochmal! Du hast keine Ahnung von einem Pendel und Pendeluhren.
Für die Berechnung wird nicht die Pendellänge benötigt, sondern der Pendelschwerpunkt. Bei einfachen geometrischen Körpern stimmt die Lage des Schwerpunkts meistens mit der halben Pendellänge überein.
Peter D. schrieb: > Teo schrieb: >> Wie wäre es, das soweit oben wie möglich, mittels Riegel zu stoppen. > > Man darf nur ganz unten dagegen drücken. Ansonsten wird die > Pendelaufhängung zu stark belastet. Sorry, damit meinte ich natürlich den Pendelhub, nicht die Position des Riegels....
temp schrieb: > Ich denke ich löse mein Problen selbst, da bin ich > schneller fertig als hier die Zeit zu verbraten. Ja, schade, dass wir dann aufgrund der unsinnig ausufernden Diskussion über Länge, Gewicht und blahblah eines mechanischen Pendels samt persönlichen Angriffen deinen Lösungsansatz nicht (mehr) erfahren werden. Das hätte mich schon interessiert, welchen Weg du einzuschlagen gedenkst. ;-) Viel Erfolg!
Teo schrieb: > Das Pendel etwas zu schnell einstellen und das dann alle paar o. jede > Stunde über den Pendelhub nachjustieren. Warum immer alles maximal kompliziert machen. Ein Elektromagnet bremst automatisch, wenn das Pendel zu schnell ist, bzw. beschleunigt, wenn es nach geht. Es ist kein komplizierter Eingriff in das Pendel nötig. Es ist auch keinerlei Regelung nötig, denn die Amplitude des Pendels bestimmt die Hemmung.
temp schrieb: > Über einen DCF77 Empfänger bekommt man zwar auf lange > Sicht einen stabilen Sekundentakt, allerdings jittert das um ein paar ms > hin und her. Diesen Jitter möchte ich am Pendel nicht haben. Das Pendel, betrachtet als schwingfähiges System, ist so schmalbandig, dass der Jitter kräftig weggedämpft wird. Wieso stört der sich? Mit jedem DCF77-Puls darf dem Pedel nur so viel Energie zugeführt werden, wie verlustig geht.
Peter D. schrieb: > Es ist auch keinerlei Regelung nötig, denn die Amplitude des Pendels > bestimmt die Hemmung Damit kann er aber nicht die Zeit der Turmuhr stellen, nach Stromausfall oder Sommer/Winterzeit. Könnte er hingegen die Zeit automatisiert (durch anhalten bis die Zeigerstellung passt) stellen, dann braucht er die sekundengenaue Synchronisation nicht mehr. Aber warum einfach wenn es auch aufwändig geht, nur aufwändige Lösungen halten die Wirtschaft in Schwung ...
Beitrag #6697034 wurde von einem Moderator gelöscht.
Moin, In Anbetracht der nun vorliegenden Informationen haben wir nun eine historische Turmuhr die ausser mit dem elektromotorischen Gewichtsaufzug im Originalzustand belassen werden muß. Das Anbringen der Brandtschen Synchronisiereinrichtung ist die einzige Veränderung die erlaubt ist. Die alten Turmuhren waren einfach nicht für Fernsteuerung konzipiert. Die einzige Maßnahme um Stehenbleiben zu verhindern ist eigentlich nur eine Notstromversorgung. Dann wissen wir auch nicht ob das Uhrwerk ein Tages- oder Wochenläufer ist. Beim Wochenläufer wäre das Risiko eines Stehenbleiben relativ tragbar. Früher mussten ja die armen Uhrwärter/Messner auch immer den Turm hochsteigen. Die alten Turmuhren waren meistens notorisch ungenau. Isochronism war aus mechanischen Gründen meist nicht realisierbar. Bestenfalls verwendete man bei kleineren Uhrwerken Hartholzpendelstangen zur besseren Gangstabilität. Man darf nicht vergessen, wie viel Kraft so eine Turmuhr aufbringen muß. Wenn man also Genauigkeit wünscht, dann muß man hoffen, daß die Brandtsche Gangregulierung ausreichend die andauernd anfallenden Gangungenauigkeiten beherrscht. Dann bleibt nur noch die Stromnotversorgung zu berücksichtigen. Die Ganggenauigkeit alter Turmuhren ist mit heutigen Standards nicht vergleichbar. Die mußten früher vom Messner andauernd nachgestellt werden. Was DCF77.5 Anbindung betrifft muß mit angebundenen Quarznormal gearbeitet werden um die relative Unzuverlässigkeit des DCF77.5 Impulsstrom zu minimieren und damit nur die Langzeitgenauigkeit der Quarzzeitbasis zu garantieren. Ob sich der Aufwand lohnt? Direkte Ausnützung des DCF Signals ist absoluter Quark. Warum also nicht einen hochgenauen DS3231 zur Bereitstellung eines 1Hz Uhrentakts zur Ansteuerung der Brandtschen Synchronisiereinrichtung zu verwenden? Der DS3231 hat eine garantierte Ganggenauigkeit über den vollen Temperaturbereich von +/- 4ppm. Das sind +/- 2 Minuten per Annum. Wie mein DS3234 in meiner Wetterstation bewiesen hat sind die Abweichungen nicht akkumulativ sondern mitteln sich. Deshalb die geringe Abweichung von nur 71s in acht Jahren. Ist das nicht gut genug? Das Turmuhrwerk muß ja auch regelmäßig gewartet werden. Da kann man dann auch die Uhr zwei Mal bei der Sommerzeitumstellung im Jahr nachstellen. Die alten Turmuhrwerke waren ja nicht für Fernsteuer-Einstellen konzipiert. (Wäre für mich sehr interessant Bilder und Hersteller, Alters Daten zu erfahren). Wenn das Turmuhrwerk aus historischen Gründen nicht verändert werden darf, würde ich ein Differenzialgetriebe am Hauptziffernantriebsschaft der Turmuhr einschleifen der zum Vierfach Umlenk-Räderwerk der vier Ziffernblätter führt und dann mittels DC Getriebemotor die Zeiger manuell mittels +/- Druckknopf von aussen nachstellen. Auf diese Weise braucht die Turmuhrwerk nur als genauer Motor arbeiten. Mit der Differenzialgetriebenachsteuerung lässt sich auch Bei-annuelle Zeitumstellung bequem bewerkstelligen. Theoretisch könnte man das elektronisch noch automatisieren. Sind nur meine Gedanken dazu. Es wäre besser gewesen, am Anfang zu sagen: Ich möchte ein historisches Turmuhrwerk mittels einer Brandtschen Synchronisiereinrichtung an DCF anbinden. Wie mache ich das mit DCF77.5 am besten? Das Turmuhrwerk darf aus historischen Gründen sonst nicht verändert werden. Nur der Gewichtsaufzug wurde elektrifiziert. Ferner wären auch Bilder und historische Details hilfreich gewesen. Dann wären die ganzen Spekulationen vermeidbar gewesen und hättest die dadurch entstehenden Diversionen und Lösungsansätze nicht gehabt. Die Salamitaktik war jedenfalls eher kontraproduktiv. Auch sollte so ein Turmuhrwerk von einem geschützten Holzkasten umfasst werden um Staub und Verschmutzungen zu verhindern. Der Dreck von Vögeln ist auch nicht zu unterschätzen wenn die durch Gitter nicht abgehalten werden können. Turmuhren müssen oft unter erbärmlichen Bedingungen ihr armseliges Werk verrichten. Gerhard
:
Bearbeitet durch User
Wolfgang schrieb: > Mit jedem DCF77-Puls darf dem Pedel nur so viel Energie zugeführt > werden, wie verlustig geht. Falsch. Das ist eine Turmuhr mit eigener Hemmung, und die sorgt dafür dass das Pendel am Laufen bleibt. Peter D. schrieb: > Es ist auch keinerlei Regelung nötig, denn die Amplitude des Pendels > bestimmt die Hemmung. Genau. Gerhard O. schrieb: > Sind nur meine Gedanken dazu. Es wäre besser gewesen, am Anfang zu > sagen: Ich möchte eine historische Turmuhr mittels einer Brandtschen > Synchronisiereinrichtung an DCF anbinden. Wie mache ich das mit DCF77.5 > am besten? Das Turmuhrwerk darf aus historischen Gründen sonst nicht > verändert werden. Nur der Gewichtsaufzug wurde elektrifiziert. Ferner > wären auch Bilder und historische Details hilfreich gewesen. Dann wären > die ganzen Spekulationen vermeidbar gewesen und hättest die dadurch > entstehenden Diversionen und Lösungsansätze nicht gehabt. Die > Salamitaktik war jedenfalls eher kontraproduktiv. Danke für deine Ausführungen, die allerdings auch komplett an meiner Frage von ganz weit oben vorbei gehen. Ich habe niemanden gefragt wie man eine alte Turmuhr stellt oder synchronisiert. Meine einzige Frage war wie man softwareseitig einen Sekundentakt erzeugt der synchron zum DCF77 läuft aber nicht so stark jittert. Punkt. Nicht mehr und nicht weniger. Jede andere Diskussion war von mir nicht erwünscht, aber dieses Forum weicht immer zum Rundumschlag aus. Und wenn man die ganzen tollen Vorschläge, die nichts mit der Frage zu tun haben, hört und das kommentiert steht man gleich wieder am Pranger. Und es ist keine Salamitaktik wenn man die Sachen um die es nie ging, erst gar nicht erwähnt. Ich weiss gar nicht, ob Sie's wussten schrieb im Beitrag #6697034: > Man könnte zur Aufhängung des Pendels eine sog. Pendelhubstichsäge > verwenden. Die ist (wie der Name schon sagt) wie gemacht dafür. Am besten man hängt sich gleich neben dem Pendel auf, da kann man durchs Fenster gucken und anhand des Sonnenstandes den Finger ins Getriebe stecken...
Gerhard O. schrieb: > Warum also nicht einen hochgenauen DS3231 zur Bereitstellung eines 1Hz > Uhrentakts zur Ansteuerung der Brandtschen Synchronisiereinrichtung zu > verwenden? Der DS3231 hat eine garantierte Ganggenauigkeit über den > vollen Temperaturbereich von +/- 4ppm. Das sind +/- 2 Minuten per Annum. Moin Gerhard, wenn du von hochgenauer RTC sprichst: Was hältst du im Vergleich dazu von meinem Vorschlag: Beitrag "Re: Pendel mit DCF77 synchronisieren" ??
:
Bearbeitet durch User
temp schrieb: > Meine einzige Frage > war wie man softwareseitig einen Sekundentakt erzeugt der synchron zum > DCF77 läuft aber nicht so stark jittert. Punkt. Nicht mehr und nicht > weniger. Das wurde ja schon gesagt: Eine direkte DCF77.5 Anbindung ohne Quarznachfuehrung ist von vorn herein unzuverlässig und zum Scheitern verurteilt. Wenn man das nicht kaufen will muß man sich überlegen wie man das am Besten selber realisiert. In der untenstehenden Link ist ein funktionierender Ansatz. Spectracom macht das beim 8161 mit einem Synchrondetektor der eine digitale PLL auf 10 Mhz synchronisiert. Dieses so angebundene 10MHz hat die gleiche Langzeitstabilität wie WWVB bzw DCF77.5, weist aber den gemittelten Jitter auf, der bei mir +/-10ns auf 60kHz bezogen aufweist oder +/-400ns bei 10MHz. (Die 60kHZ oder 77.5kHz tun hier nichts zur Sache). Von den 10MHz kann man dann den Sekundentakt ableiten. Ich rate auf alle Fälle ab, das DCF77.5 Signal ohne Quarznachfuehrung zu verwenden. Dieses Quarzsignal agiert auch als Schwungrad um kurzzeitige Störungen abzuschwächen und hat den Vorteil, daß der Sekundentakt nie unterbrochen wird. Als Schaltungsbeispiel schaue mal hier: https://www.orolia.com/sites/default/files/document-files/8161_manual.pdf In den alten UKW Berichten war ein kompletter Bauvorschlag für ein DCF77.5 Frequenznormal.
temp schrieb: > Meine einzige Frage > war wie man softwareseitig einen Sekundentakt erzeugt der synchron zum > DCF77 läuft aber nicht so stark jittert. Punkt. Dann wäre es sehr hilfreich, wenn du auf (evtl. hilfreiche?) Hinweise auch mal eingehst. Die nicht zielführenden Hinweise kann man ja geflissentlich ignorieren. ;-) Frage nochmals dazu: Muss der Takt unbedingt mit einem uC erzeugt oder gesteuert werden? Oder ist es nur dein Wunsch, weil du evtl. Spaß daran hast?
:
Bearbeitet durch User
Gerhard O. schrieb: > Ich rate auf alle Fälle ab, das DCF77.5 Signal ohne Quarznachfuehrung zu > verwenden. Dieses Quarzsignal agiert auch als Schwungrad um kurzzeitige > Störungen abzuschwächen und hat den Vorteil, daß der Sekundentakt nie > unterbrochen wird. Zu keiner Zeit wurde etwas davon gesagt dass der Cortex M3 keinen Quarz hat. Natürlich hat der den und wird auch genutzt.
Michael M. schrieb: > Gerhard O. schrieb: >> Warum also nicht einen hochgenauen DS3231 zur Bereitstellung eines 1Hz >> Uhrentakts zur Ansteuerung der Brandtschen Synchronisiereinrichtung zu >> verwenden? Der DS3231 hat eine garantierte Ganggenauigkeit über den >> vollen Temperaturbereich von +/- 4ppm. Das sind +/- 2 Minuten per Annum. > > Moin Gerhard, > wenn du von hochgenauer RTC sprichst: Was hältst du im Vergleich dazu > von meinem Vorschlag: > Beitrag "Re: Pendel mit DCF77 synchronisieren" > ?? Meinst Du den OCXO Vorschlag? So lange er richtig eingestellt wurde, besser als der RTC mit dem DS3231. Da könnte man wahrscheinlich bei einem guten Modell eine 10 Jahre Alterung von weniger als eine Minute erwarten. Die meisten (erschwingbaren) OCXOs altern unter 0.01-0.1ppm/Annum. 1ppm wären gleich rund 33s Abweichung/Annum. Der z.B. https://docs.rs-online.com/6dfb/0900766b81476f7d.pdf hat 50ppb/A, das wäre eine Abweichung von unter 1.7s/A. Anbindung an einen externen Standard wie DCF ist bei richtiger Einstellung nicht wirklich notwendig. Wenn die Richtung der Alterung bekannt ist, kann man diesen OCXO so einstellen, daß er am Anfang um die Hälfte langsamer läuft und so nur 0.85s/A praktisch nach einem Jahr abweicht.
Gerhard O. schrieb: > Die meisten (erschwingbaren) OCXOs altern unter > 0.01-0.1ppm/Annum. Meine (absolut erschwinglichen) Isotemps sind genauso (+/-100ppb/a) spezifiziert. Die Kurzzeit-Stabilität liegt bei ca. < 1*10exp(-8), ohne sie jetzt z.B. mit einem Rb-Normal verglichen zu haben; das Ganze ohne besondere hochstabile, rauscharme Stromversorgung (nur LNG) und zusätzlichem Dämm-Aufwand, m.a.W. nackig auf dem Labortisch liegend.
Michael M. schrieb: > Gerhard O. schrieb: >> Die meisten (erschwingbaren) OCXOs altern unter >> 0.01-0.1ppm/Annum. > > Meine (absolut erschwinglichen) Isotemps sind genauso (+/-100ppb/a) > spezifiziert. > Die Kurzzeit-Stabilität liegt bei ca. < 1*10exp(-8), ohne sie jetzt z.B. > mit einem Rb-Normal verglichen zu haben; das Ganze ohne besondere > hochstabile, rauscharme Stromversorgung (nur LNG) und zusätzlichem > Dämm-Aufwand, m.a.W. nackig auf dem Labortisch liegend. Eigentlich vieeel zu schade für eine Uhrenanwendung;-)
Ich habe sie ja mit Sicherheit auch nicht für eine Uhr-Anwendung angeschafft... :-D
:
Bearbeitet durch User
temp schrieb: > Zu keiner Zeit wurde etwas davon gesagt dass der Cortex M3 keinen Quarz > hat. Natürlich hat der den und wird auch genutzt. Eigentlich sollten wir uns jetzt alle an der Nase fassen. Ich habe nochmals den Eingangspost gelesen und da hat temp klar ausgedrückt, dass es um einen uC Lösungsansatz mit einem Cortex uC geht. Ich habe mal schnell geguckt: https://www.diva-portal.org/smash/get/diva2:1016340/FULLTEXT01.pdf https://wirelesspi.com/phase-locked-loop-pll-in-a-software-defined-radio-sdr/ https://www.ti.com/lit/ug/spru233c/spru233c.pdf?ts=1621360687876 https://trace.tennessee.edu/cgi/viewcontent.cgi?article=4030&context=utk_gradthes Vielleicht findet sich hier etwas Brauchbares.
Michael M. schrieb: > Ich habe sie ja mit Sicherheit auch nicht für eine Uhr-Anwendung > angeschafft... :-D Das glaube ich Dir auf's Wort;-) Ich habe auch ein paar Schätzchen in meiner Bastelkiste. Als Laborfrequenznormal dient bei mir ein RB85 LPRO mit 10MHz Verteilerverstärker der ab und zu über 60kHZ WWVB verglichen wird. https://www.mikrocontroller.net/attachment/51136/Rubidiumfrequenznormal3.jpg https://www.mikrocontroller.net/attachment/51139/10MHZ_Verteilerverstaerker3.jpg https://www.mikrocontroller.net/attachment/279522/FSG742A.jpg
:
Bearbeitet durch User
Gerhard O. schrieb: > Eigentlich sollten wir uns jetzt alle an der Nase fassen. Nicht wirklich. > Ich habe > nochmals den Eingangspost gelesen und da hat temp klar ausgedrückt, dass > es um einen uC Lösungsansatz mit einem Cortex uC geht. Und ganz genau das ist doch der Unsinn. Das Problem selber war (sehr) unvollständig dargestellt und die Lösung von vornherein auf einen spezielle µC-Architektur zu verengen, ist gleich kompletter Schwachsinn. Das könnte man vielleicht machen, wenn das Problem den genannten µC bis zum letzten fordern würde und deswegen eine triviale Lösung damit nicht möglich ist. Dann wäre die natürliche Lösung: nimm' was Schnelleres oder optimiere. Das ist aber nicht der Fall. Das Teil hat geradezu unanständig viel Rechenleistung im Vergleich zur Trivialität der (tatsächlichen!) Aufgabe. Sprich: der Typ kann einfach nur nicht selber programmieren. Weder einen Cortex M3 noch irgendwas anderes und er sucht einfach nur eine Vorlage für C&P. Sprich: grenzenlos faul und/oder dramatisch unfähig. Vermutlich beides, denn ersteres führt praktisch unweigerlich zu letzterem.
Peter D. schrieb: > Nö. > Ein Quarz mit nachgeführtem Teiler hat viel weniger Jitter, als ein > RC-Oszillator, z.B. im CD4064. Hmm... Es war nirgenwo die Rede von einem prähistorischen CD4064. Er wollte die PLL in Software umsetzen. Und das geht tatsächlich. Mit oder ohne Quarz für den µC. Ein Quarz kann hier nur genau eins leisten: Bessere Sicherheit gegen längeren Ausfall des DCF77-Empfangs. Ob man das Werk dann ganz konkret PLL oder FLL umsetzt, ist ein Implementierungsdetail. Klar ist hier eine FLL einfacher zu realisieren. Aber wie schon gesagt: vom theoretischen Standpunkt aus ist es am Ende (also im Ergebnis) dasselbe. FLL ist nur unter dem Aspekt der einfacheren Implementierung vorzuziehen.
Gerhard O. schrieb: > Ich habe mal schnell geguckt: Ich habe auch mal schnell durchgeguckt... Ich finde keinen der Links wirklich hilfreich zum Thema, sorry, falls ich es auf die Schnelle nicht erfasst haben sollte. Was für ein Aufwand... HW + SW + PLL entwickeln, ... nur für einen einfachen stabilen Taktgeber. Da bevorzuge ich die pragmatische, althergebrachte Einfach-Lösung: OCXO + adäquate (= hochstabil, rauscharm) Stromversorgung + Pufferakku, Taktsignal-Aufbereitung hinten dran, wenn nötig, zusätzliche Dämmung gegen die Temperatur-Einflüsse. Wenig HW-Aufwand, d.h. auch wenig Fehlerquellen möglich, absolut ausreichend stabil für den Einsatzzweck bzw. die Anwendung. Das Ganze bei Inbetriebnahme am Rb-Normal justiert und dann maximal jährlich überprüfen, ggf. notwendigerweise nachkalibrieren. Feddisch...
c-hater schrieb: > Gerhard O. schrieb: > >> Eigentlich sollten wir uns jetzt alle an der Nase fassen. > > Nicht wirklich. > >> Ich habe >> nochmals den Eingangspost gelesen und da hat temp klar ausgedrückt, dass >> es um einen uC Lösungsansatz mit einem Cortex uC geht. > > Und ganz genau das ist doch der Unsinn. Das Problem selber war (sehr) > unvollständig dargestellt und die Lösung von vornherein auf einen > spezielle µC-Architektur zu verengen, ist gleich kompletter Schwachsinn. Ich habe bei mir einen Spectracom 8164 in Betrieb der exakt das macht was temp machen will. Nur hat das Spectracom schon in den 1980ern gemacht und auf einem 8051 Derivat. https://www.orolia.com/sites/default/files/document-files/8164_manual.pdf > > Das könnte man vielleicht machen, wenn das Problem den genannten µC bis > zum letzten fordern würde und deswegen eine triviale Lösung damit nicht > möglich ist. Dann wäre die natürliche Lösung: nimm' was Schnelleres oder > optimiere. > > Das ist aber nicht der Fall. Das Teil hat geradezu unanständig viel > Rechenleistung im Vergleich zur Trivialität der (tatsächlichen!) > Aufgabe. In Referenz zu Spectracom: Ja! Der 8051 hat damit keine Probleme und es funktioniert sehr gut. Auch der Spectracom braucht 1000s nominal zum Lockup und Mittlung. Allerdings ist die Langzeitnachreglung des internen OCXO sehr gut. > > Sprich: der Typ kann einfach nur nicht selber programmieren. Weder einen > Cortex M3 noch irgendwas anderes und er sucht einfach nur eine Vorlage > für C&P. Sprich: grenzenlos faul und/oder dramatisch unfähig. Vermutlich > beides, denn ersteres führt praktisch unweigerlich zu letzterem. Ich könnte es ohne grundlegende Recherche auch nicht und darüber zu kommentieren wage ich mich nicht;-) ...
Michael M. schrieb: > Wenig HW-Aufwand, d.h. auch wenig Fehlerquellen möglich, absolut > ausreichend stabil für den Einsatzzweck bzw. die Anwendung. > > Das Ganze bei Inbetriebnahme am Rb-Normal justiert und dann maximal > jährlich überprüfen, ggf. notwendigerweise nachkalibrieren. > Feddisch... Deshalb hätte ich an seiner Stelle es mit dem DS3231 oder DS32 gemacht. Ich bin Pragmatiker;-) Eine Minute mögliche Abweichung im Jahr ist doch genau genug wenn man auch bedenkt, daß die Uhr zweimal im Jahr wegen der Zeitumstellung angefaßt werden muß. Wenn das zu viel Arbeit ist, dann würde ich halt die Turmuhr als technisches Kulturgut zur Bewunderung in den Kirchenfoyer stellen wo es sich jeder ansehen kann und anstatt ein zeitgemäßes modernes Uhrwerksystem einbauen, das sich ferntechnisch einstellen laesst. Es gibt genug Industrielösungen. Auch Lösungen für historische Uhrwerke gibt es dort. https://turmuhren.de/turmuhrsteuerung (Siehe DCF-Pendel)
:
Bearbeitet durch User
c-hater schrieb: > Und ganz genau das ist doch der Unsinn. Das Problem selber war (sehr) > unvollständig dargestellt und die Lösung von vornherein auf einen > spezielle µC-Architektur zu verengen, ist gleich kompletter Schwachsinn. Nein ist es nicht, ich hatte ein Teilproblem und die Frage so formuliert: "Hat jemand so eine ähnliche Aufgabe schon mal gehabt bzw. gelöst?" Fakt ist doch eins, keiner von denen die geantwortet haben, hatte so ein Teilproblem geschweige denn es gelöst. Und c-hater schon gleich gar nicht. Macht nichst, dann mach ich es selbt. c-hater schrieb: > Das könnte man vielleicht machen, wenn das Problem den genannten µC bis > zum letzten fordern würde und deswegen eine triviale Lösung damit nicht > möglich ist. Dann wäre die natürliche Lösung: nimm' was Schnelleres oder > optimiere. > > Das ist aber nicht der Fall. Das Teil hat geradezu unanständig viel > Rechenleistung im Vergleich zur Trivialität der (tatsächlichen!) > Aufgabe. > > Sprich: der Typ kann einfach nur nicht selber programmieren. Weder einen > Cortex M3 noch irgendwas anderes und er sucht einfach nur eine Vorlage > für C&P. Sprich: grenzenlos faul und/oder dramatisch unfähig. Vermutlich > beides, denn ersteres führt praktisch unweigerlich zu letzterem. Hab ich dir nicht oben schon gesagt, scher dich zum Teufel. Auf deine Kommentare jeglicher Art kann ich verzichten. Und für die anderen, für solche Einmalprojekte, bei denen kein einziger Cent rüberkommt, nehme ich das was im Schrank liegt. Und das sind ein Sack voll Platinen mit CS32F103 die mal anstelle von STM32F103 geliefert wurden und für sowas wie geschaffen sind. Und auch noch ein paar DCF77 Empfänger für die ich sonst auch keine Verwendung mehr habe. Das 2. ist die Entwicklungsumgebung. Nur weil ein Projekt eventuell auch in einen 8bitter passt, wechsle ich nicht ständig hin und her. Es reicht wenn die Uhr historisch ist, da müssen es die Controller nicht auch noch sein. Gerhard O. schrieb: > Deshalb hätte ich an seiner Stelle es mit dem DS3231 Ja, an und für sich ein schöner Baustein dessen Genauigkeit reichen würde. Allerdings muss ich den wenn überhaupt bei Mouser o.ä. kaufen für >7€ pro Stück Netto plus Versand. Bei den Modulen, die neben der Milch und der Klobürste überall verkauft werden, scheint das gleiche zu sein wie bei den Bluepill Boards. Fakes oder Ausschuss. Jedenfalls ist das Internet voll mit Berichten über die Gangungenauigkeiten dieser Teile. Gerhard O. schrieb: > Wenn das zu viel Arbeit ist, dann würde ich halt die Turmuhr als > technisches Kulturgut zur Bewunderung in den Kirchenfoyer stellen wo es > sich jeder ansehen kann und anstatt ein zeitgemäßes modernes > Uhrwerksystem einbauen, das sich ferntechnisch einstellen laesst. Also, das ist eine evang. Kirche, keine Moschee. Mit dem Klingelbeutelumsatz eines Jahres kriegt man vielleicht ein Angebot aber keine neue Uhr. Michael M. schrieb: > Da bevorzuge ich die pragmatische, althergebrachte Einfach-Lösung: > > OCXO + adäquate (= hochstabil, rauscharm) Stromversorgung + Pufferakku, > Taktsignal-Aufbereitung hinten dran, wenn nötig, > zusätzliche Dämmung gegen die Temperatur-Einflüsse. > > Wenig HW-Aufwand, d.h. auch wenig Fehlerquellen möglich, absolut > ausreichend stabil für den Einsatzzweck bzw. die Anwendung. > > Das Ganze bei Inbetriebnahme am Rb-Normal justiert und dann maximal > jährlich überprüfen, ggf. notwendigerweise nachkalibrieren. > Feddisch... Über das Feddisch muss ich jetzt aber schmunzeln... Ich bin auch pragmatisch, deshalb kommt ein vorhandener DCF77 Empfänger aus dem letzten Jahrtausend an ein China-Bluepill für 1.50€ und gut. Keine hochstabile rauscharme Stromverstärkung, kein Pufferakku, keine Dämmung und keine Kalibrierung. Nur ein paar Zeilen Software, und bald ist's Feddisch.
Könntest Du dein Geschwurbel mal zusammenfassen? Liest sich dann besser.
temp schrieb: > Fakes oder Ausschuss. Jedenfalls ist das > Internet voll mit Berichten über die Gangungenauigkeiten dieser Teile. Da hatte ich bis jetzt nur damals mit den DS3234 Modulen Probleme, da ich nicht aufgepaßt hatte und versehentlich die N Version mit 0-70 Grad gekauft habe. Für den vollen Temperaturbereich muß es SN sein. Da bei mir -46 Grad im Winter keine Seltenheit sind, ging das natürlich in die Hose.Nach Ersatz von Digikey erzielte ich die erwähnten 71s Gangfehler. Ansonsten hatte ich mit den China DS3231 Modulen (mit EEPROM) noch nie irgendwelche Probleme. Ist halt Glücksache. Meine Nixie-Uhr, die seit Mitte letztes Jahr nicht mehr nachgestellt wurde, läuft jetzt 20s schnell. Was uC Entwicklungsumgebung betrifft sehe ich das ähnlich. Da nehme ich halt auch etwas das sich schon bewährt hat.
temp schrieb: > Über das Feddisch muss ich jetzt aber schmunzeln... Das ist noch ganz bescheiden. In Kalifornien gibt es Leute die haben Caesium Maser und andere exotische Zeit-normale bei sich zu Hause oder in der Garage;-) http://leapsecond.com/ http://leapsecond.com/hpclocks/ http://www.prc68.com/I/PClock.shtml http://leapsecond.com/ptti2003/tvb-Amateur-Timekeeping-2003.pdf https://www.wired.com/2007/12/time-hackers/
auf den billig(er)en DS3231 Modulen sind oft "nur" DS3231_M_ bestückt. Der Unterschied ist ein darin integrierter billigerer MEMS Oszillator, der im Temperaturbereich -40..85°C nur +/-5ppm anstatt der +/-3.5ppm erreicht, allerdings mit deutlich höherem Jitter. Wer sicher gehen will kauft halt den Chip bei einem Vertragshändler ... ist mit den DS18B20 ja das selbe.
temp schrieb: > Ich bin auch pragmatisch, deshalb kommt ein vorhandener DCF77 Empfänger > aus dem letzten Jahrtausend an ein China-Bluepill für 1.50€ und gut. Dann führe doch bitte vor, welche Stabilität du mit dem von dir ausgewählten Material erreichen wirst. Eine rechnerische Darstellung reicht ja erst einmal. Ich bezweifle, dass du weder die Kurz-Stabi noch die Alterung mit einer PLL-Anbindung eines Quarzes an DCF wirklich sauber hinbekommst. Von Ausbreitungsbedingungen (Fading, Phasenfehlern und -Drift) des DCF-Trägersignals und Problemen beim Senderausfall noch garnicht gesprochen. Es gibt zwar keine Röhrenfernseher mit ihrer 5. Oberwelle der Zeilenfrequenz mehr, dafür aber z.B. eine Unmenge von "Wandwarzen" und SNTen, die ihren Müll-Lattenzaun in die Gegend pusten. Und dagegen soll ein "Einfach"-DCF-Empfänger gewappnet sein? :-O Wenn du "viel Glück" hast, synchronisiert die PLL u.U. vielleicht gar nicht oder nur selten. Oder die örtlichen QRM-Verhältnisse ändern sich unvorhersehbar.... Ich sehe dich bildlich schon die Stufen erklimmen... :-( Bei so vielen Unwägbarkeiten -die mit einem anderen Lösungsweg auszuschließen wären- kann ich nur zum darüber Nachdenken raten. Falls von Interesse, stelle ich dir gern mal ein Empfangsteil vor, was nicht mal eben kurz "zwischen 12h und Mittag" entstanden ist und mich recht viel Recherche-Arbeit gekostet hat. Dies kann diesen Schwierigkeiten wenigstens einigermaßen gerecht werden (NUR HF-Teil, ohne die zusätzlich erforderliche Maßnahmen für die Ausblendung von Störungen). Ich fürchte, du gehörst zu den Menschen, deren Heiligstes die SW eines u-Professors ist. Das mag in vielen Fällen zutreffen, jedoch manche Aufgaben erfordern grundsätzlich eine passende HW als Basis. Stabilität und Genauigkeit in der Horologie erreicht nicht durch Beten, Hoffen und Warten (samt Korrektur), sondern ausschließlich mit der richtigen/passenden Wahl der Funktionsblöcke sowie deren konstruktiven Details. Die sehe ich bei deinem Vorhaben bis jetzt nicht gegeben. Du wolltest ein jitterarmes, im Ideal jitterfreies Sekundensignal. Der DCF-Empfänger kann es nicht bieten; sein Sek.-Puls ist für die Tonne. Bei Träger-Ausfall hilft dir nur ein "Schwungrad", das jederzeit 100% mitläuft. Nun kannst du das Schwungrad (= Quarz-Oszillator) mit der SW beeinflussen und regeln und du hoffst, dass du auf diesem Weg von hinten durch die Brust in's Auge eine Stabilität erreichst, die dem Pendel gerecht wird. Alleine deine Regelung dieser PLL wird dir wahrscheinlich mehr Dreck produzieren als der/ein Q.-Osz. selbst und vor allem dir lieb ist. Viel Erfolg dabei (auch beim Suchen der Fußangeln) .... Ich habe immer mehr den Eindruck, dass hier eine nicht unerhebliche Beratungs-Resistenz vorliegen könnte? Den einfachen, zudem preiswerten und zielführenden (sowie einzigen) Weg willst du anscheinend nicht und auch dementsprechend nicht anerkennen: Nämlich einen Taktgeber, dessen einzige Aufgabe von Geburt an ist, einen hochstabilen Takt mit nur geringstmöglicher f-Wanderung (Alterung) zu bieten. Die Zahlen (zum Beweis) stehen bereits w.o., wobei noch nicht berücksichtigt ist, dass das OCXO-Signal ja noch durch 10exp7 geteilt wird, bevor der Sek.-Puls herauskommt. Übrigens: Auch an dieser Stelle ist zu prüfen, ob die Teilung vom einem uC gemacht wird oder ein schulmäßig aufgebauter Synchronteiler nicht deutlich überlegen ist. ^^ Da jittert am Steuersignal für's Pendel nix mehr, nada, niente... (wenn man keine groben Schnitzer einbaut). Was Schöneres kann dem Pendel nicht passieren. ;-) Letzte Anmerkung: Wenn ich von dir "...kein Pufferakku..." lese, kommen leider Befürchtungen hoch. :-( Nein nein, mir ist schon klar, dass bei Stromausfall die Uhr wahrscheinlich auch nicht angetrieben würde...
:
Bearbeitet durch User
Falls es interessiert kann man im Video des Anhangs die Laufzeitvariationen des WWVB 60kHz Signals auf 10MHz bezogen beobachten. Die Variation ist im Mittel 5-6 10MHz Perioden, also rund 0.5us. Da das Frequenzverhältnis rund 167:1 ist, sind die tatsächlichen Verwerfungen um diesen Faktor geringer. Die SE Entfernung ist rund 1500km und um 9 Uhr früh aufgenommen. Das untere Oszi Signal ist von einem hochwertigen OCXO (Spectracom 8164) auf WWVB synchronisiert und 1MHz zur Triggerung. Der obere Strahl ist das 10MHz OCXO Signal. Falls temp es softwaremässig angehen will, hat er damit einen Anhaltspunkt inwieweit der uC damit leben muß.
Moin Gerhard, ich (zumindest) bekomme das Video nicht gestartet... :-(
Michael M. schrieb: > Moin Gerhard, > ich (zumindest) bekomme das Video nicht gestartet... :-( bei mir läuft es (mit VLC media player)
Angehängte Dateien:
Moin, Gerade wieder zuhause. Freut mich, daß es mit dem Video doch noch geklappt hat. Habe es mit dem iPad aufgenommen. Falls sich jemand wundert wie man am besten 60kHz von 10MHz erhält, hat Spectracom das so gelöst indem sie zuerst den Costas VCXO auf 10MHz durch 500 auf 20kHz teilten und dann wieder auf 60kHz zu verdreifachen um das Frequenzverhältnis von 166.6667 zu erhalten. Auf 77.5kHz könnte man sinngemäß ähnlich vorgehen. Das Bild zeigt auch die von mir verwendete aktive abgestimmte Ferrit-Antenne. Der RX im Spectracom ist ein Costas Loop Synchron Empfänger wo ein Produkt Detektor zur Erzeugung der PLL Steuerspannung herangezogen wird und der andere zur Amplitudenerfassung die AGC erzeugt und zur WWVB Timecodedemodulation herangezogen wird. Ich mußte meinen Spectracom wegen der seit 2012 zugesetzten BPSK Timecode Modulation umrüsten indem ich die 60kHz verdppelte um die BPSK zu entfernen. Damit funktioniert so ein Gerät wieder mit WWVB. Bei DCF77.5 wäre das nicht notwendig. (A=sin(wt)) -> (A=cos(2wt)). Damit wird die BPSK entfernt. Es wäre durchaus möglich die Spectracomgeräte (8160-64) für 77.5kHz umzurüsten und hätte dann eine Alternative zu GPSDO. was mich betrifft finde ich das LW Frequenznormalkonzept nostalgisch sympathischer. Ich habe mich zwar auch mit GPSDO befasst und Erfolg gehabt, verwende aber lieber die Spectracom Technik. Das lebt irgendwie mehr als das abstrakte hochkomplizierte GPS Konzept das extrem viel Rechenaufwand und dedizierte High-Tech erfordert. Allerdings hat GPSDO bessere möglicze Genauigkeit, hochwertige Empfänger vorausgesetzt. Aber mir reicht es für den Hausgebrauch wenn ich 1GHz mit 0.01-0.1Hz Genauigkeit messen kann. Für die meisten Zwecke ist das Dicke genug. Ich finde jedenfalls die DCF/WWVB LW Technik doch irgendwie interessanter weil es im Detail technisch zugänglicher und nachbaufähig ist. Abgesehen davon wird DCF77.5 in DE domestisch betrieben und kann von anderen Ländern nicht kontrolliert werden was man von GPS und GLONASS nicht behaupten kann. Gut, das betrifft auch mich mit WWVB. Gerhard
:
Bearbeitet durch User
Warum so viel Aufwand? Es gibt einen Uhrmachermeister in Thüringen, der hält ein Patent auf die Beeinflussung eines Pendels einer Turmuhr Elektromagneten. Dieses wird dadurch mit dem Zeitzeichensender synchronisiert . Neben dem diskret aufgebauten Empfänger besteht die Ansteuerung für den Elektromagneten nur aus einer kleinen Leiterplatte.
Nautilus schrieb: > Es gibt einen Uhrmachermeister in Thüringen, der hält ein Patent auf die > Beeinflussung eines Pendels einer Turmuhr Elektromagneten.... Wenn du die Kosten trägst, wird der Fragesteller sich das vielleicht überlegen. ;-) Übrigens: Dieser Uhrmachermeister wurde vom Themenstarter selbst bereits verlinkt. :( Lesen hilft also..
Nautilus schrieb: > Warum so viel Aufwand? > Es gibt einen Uhrmachermeister in Thüringen, der hält ein Patent auf die > Beeinflussung eines Pendels einer Turmuhr Elektromagneten. Dieses wird > dadurch mit dem Zeitzeichensender synchronisiert . Neben dem diskret > aufgebauten Empfänger besteht die Ansteuerung für den Elektromagneten > nur aus einer kleinen Leiterplatte. Ich weiß, meine Ausführungen sind etwas OT und hier nur peripheriell relevant. Die erwähnte Lösung ist natürlich für temps Zwecke im Prinzip der richtige Ansatz und ich würde es ähnlich realisieren. Temp geht es aber um Information wie man das DCF Signal softwaretechnisch aufbereitet um für die Synchronisation zuverlässiger zu sein. Allerdings hört es sich von Dir so an, als ob das Thüringer Konzept diesbezüglich wegen dem Schwungradverhalten eines Pendel tolerant genug ist um zufällige Impulsausfälle verkraften zu können. Versuch macht kluch;-)
Gerhard O. schrieb: > Pendel Mutteruhren in Großanlagen wurden schon anfangs der 1900er Jahr > ferntechnisch synchronisiert. Hier einige Referenzen und durchgeführte > Methoden: Wow, danke für die Linkliste.
Gerhard O. schrieb: > Gerade wieder zuhause. Freut mich, daß es mit dem Video doch noch > geklappt hat. Habe es mit dem iPad aufgenommen. Es ist leider 90° nach links verdreht. Kann ich im MPC Home Cinema oder vlc drehen, ist aber lästig, weil sich beide dann diese Einstellung merken. Gerhard O. schrieb: > Falls es interessiert kann man im Video des Anhangs die > Laufzeitvariationen des WWVB 60kHz Signals auf 10MHz bezogen beobachten. > > Die Variation ist im Mittel 5-6 10MHz Perioden, also rund 0.5us. Damit bestätigst Du die Aussage anderer Schreiber, dass man es nicht direkt verwenden kann. Mit dem Signal muß ein hochstabiler Quarz nachgeführt werden, möglichst langsam über lange Zeit. Wir hatten früher für die HF-Fertigung ein Rubidiumnormal, was gegen Loran nachgeführt wurde, die Senderkette scheint nicht mehr zu existieren. Später kam dort DCF77 hin, das Ding will aber auch mindestens einen Tag laufen, bevor es Stabilität signalisiert.
Angehängte Dateien:
Manfred schrieb: > Es ist leider 90° nach links verdreht. Kann ich im MPC Home Cinema oder > vlc drehen, ist aber lästig, weil sich beide dann diese Einstellung > merken. Danke für die Notiz. Leider gibt mir der iPad keinen Anhaltspunkt weil es bei mir richtig gedreht abspielt. Ich habe noch nicht versucht den hochgeladenen Video vom PC herunterzuladen. Also muß man den iPad beim "Filmen" in Landschaftsmodus halten;-) Mein umgebauter Spectracom 8161/4 funktioniert sehr gut. Ich überwache damit auch mein Rb85 Frequenznormal. Falls von Interesse: Der eingebaute Streifenschreiber ist dafür sehr nützlich. Leider sind die Schreibrollen heutzutage mit $50 oder mehr unerschwinglich. Als Abhilfe verwende ich daher bald einen Arduino der einen thermischen Kioskdrucker ansteuert. Damit verbilligt sich das Streifenschreiberproblem beträchtlich. PC und Data-Acquistion ist ja dafür zu umständlich. Wenn das Teil einbaufertig ist baue ich den neuen Recorder anstelle des Simpsonrecorders fest ein. Im Anhang ist ein Beispiel der Konzept-Testarbeiten. Siehe auch hier: Beitrag "Re: Zeigt her eure Kunstwerke (2020)" Dies Streifenaufzeichnungen erlauben bequeme Erfassung der Abweichung zweier Präzisionsoszillatoren. Die Skala hat 50us oder 10us Skalierung.
Manfred schrieb: > Wir hatten früher für die HF-Fertigung ein Rubidiumnormal, was gegen > Loran nachgeführt wurde, die Senderkette scheint nicht mehr zu > existieren. Später kam dort DCF77 hin, das Ding will aber auch > mindestens einen Tag laufen, bevor es Stabilität signalisiert. Damit hatte ich mich vor dreissig Jahren auch befasst. Damals verwendete ich einen Stanford Research Loran RX FS700. https://www.govinfo.gov/content/pkg/GOVPUB-C13-ba6252da8fa1b5362650272868260926/pdf/GOVPUB-C13-ba6252da8fa1b5362650272868260926.pdf
:
Bearbeitet durch User
Nautilus schrieb: > Dieses wird > dadurch mit dem Zeitzeichensender synchronisiert . Neben dem diskret > aufgebauten Empfänger besteht die Ansteuerung für den Elektromagneten > nur aus einer kleinen Leiterplatte. So wie ich das auf der Webseite lese, ist da kein Zeitzeichensender im Spiel, sondern ein genauerer Takt als der von einem Standardquarz. Es selbst gibt 1/2min pro halbes Jahr an. Wir wollen neben der Synchronisation auch das Stellen nach Stromausfällen zur Sommer/Winterzeitumstellung realisieren. Deshalb ist der DCF Empfänger sowieso an Bord. Gerhard O. schrieb: > Allerdings hört es sich > von Dir so an, als ob das Thüringer Konzept diesbezüglich wegen dem > Schwungradverhalten eines Pendel tolerant genug ist um zufällige > Impulsausfälle verkraften zu können. Versuch macht kluch;-) Der Jitter (ein paar ms) bedeuten bei unserem Pendel immerhin schon ein paar mm Pendelweg, und das war für mich gefühlt zu viel. Mit meiner Software bin ich schon weiter. Zum einen Messe ich die Ticks eines 32bit Counters bei 72MHz zwischen den Flanken des DCF Signals, die 59 mal 1s (72000000) und ein mal 2s (144000000) lang sein sollten. Alle Samples die innerhalb einer geringen Toleranz liegen werden weiter in ein Mittelwertfilter geschickt. Nach vielen Sekunden die das Ganze zum Einschwingen braucht habe ich einen stabilen Zustand der bei mir bei 720043xx liegt. Damit hat der Quarz einen Grundfehler von ca. 60ppm. Diesen Mittelwert kann man nun als Teiler nehmen um den Sekundenimpuls zu generieren. Damit hängt man schon ziemlich nah an der richtigen Zeit. Zusätzlich messe ich noch die Ticks des Phasenversatzes, mittle den auch und gebe einen kleinen Teil davon dem Teiler hinzu. Damit ergibt sich eine Regelschleife die den Phasenversatz ausgleicht. Der Grundteiler von ca. 72000000 ändert sich bei diesem gesamten Vorgang nur in den letzten 3 Stellen (im eingeschwungenem Zustand, sonst 4 aber sehr sehr langsam). Damit ist das Jitter für das Pendel um 2 Zehnerpotenzen besser. Fällt DCF aus läuft alles mit dem letzten Teiler einfach weiter. Solange der DCF Empfänger halbwegs brauchbare Signale liefert sollte ich damit keine einzige Sekunde verlieren oder gewinnen. Es sieht eigentlich schon ganz gut aus, der Code ist aber noch nicht auf dem Stand zum Vorzeigen. Mal sehen ob ich das über Pfingsten schaffe.
temp schrieb: > Solange der > DCF Empfänger halbwegs brauchbare Signale liefert sollte ich damit keine > einzige Sekunde verlieren oder gewinnen. Das ist der Punkt der mir Sorgen macht weil die LW Signale leicht gestört werden können. Es genügt eine LED Lampe oder SNT welche zufällig in den Bereich von DCF driftet und man hat temporären Totalausfall der Impulsfolge. Deshalb wäre ein kräftiges Schwungrad (PLL) so notwendig. Der FTM im Spectracom funktioniert ähnlich wie Dein Ansatz. Nur überbrückt ein DAC mit dem letzten guten Wert mindestens einige Stunden Totalausfall des LW Signals. Da der OCXO dort von sehr hoher Gangstabilität ist, verursachen temporäre Signalausfälle keinen großen Phasendriftfehler. Ein Stratum III Quarzoszillator wäre hier eine gute Wahl. Beim Spectracom werden einige Stunden Frequenzdaten gemittelt bis der Steuerwert dem DAC übergeben wird. Dadurch wird das ganze System sehr robust gegen Signalausfälle. Deiner Beschreibung nach müsstest Du bei Ausfall due letzten Werte weiterverwenden bis sich die Reglung von selbst wieder einpendelt. Vielleicht solltest Du erwägen einen stabilen TCXO oder besser OCXO/Stratum III Oszillator als Zeitbasis für den uC zu verwenden weil der typische 8MHz uC Quarz normalerweise im Vergleich zu solchen Oszillatoren sehr unstabil ist. Jedenfalls bin ich der Ansicht, daß bei Deinem Konzept, um erfolgreich zu sein, ein besserer Taktoszillator verwendet werden sollte, der ohne Nachsteuerung lang genug stabil ist um Deine Erwartungen bei LW Ausfall zu erfüllen. Ein uC Quarz ist in der Regel nicht gut genug um nicht innerhalb einiger Stunden einen >1s Gangfehler zu verursachen. Dann ist auch zu berücksichtigen, daß DCF nur 99.5% "Availability" garantiert. Deshalb muß Deine Lösung lange genug autonom funktionieren können um solche Ausfälle seitens DCF zu überbrücken. Solche Ausfälle passieren in gewissen Wettersituationen wo die Antenne durch Eis oder Schnee fehlabgestimmt wird und gewisse Probleme verursachen. Ich schlage Dir deshalb vor mindesten 24 Std. designmässig überbrücken zu können. Vielleicht überlege Dir ob Du nicht lieber einen DS3132 mit Deinem uC softwaretechnisch an DCF anbinden möchtest. Der hat nämlich die notwendige Stabilität um stundenlang autonom agieren zu können. Da Deine Korrekturwerte von Deinem Algorithmus originieren, kannst Du im Falle eines DCF Ausfalls mit den gespeicherten aktuellen Korrekturwerten solche Ausfallzeiten überbrücken. An sich müsste Dein Konzept bei voller Implementation gut funktionieren können. Da ich bei Dir jetzt den "Weg als Ziel" erkenne, empfinde ich das durchaus als ein sehr interessantes Projekt. Pragmatisch gesehen würde allerdings ein (guter) DS3131 zwischen zwei Zeitumstellintervallen in aller Wahrscheinlichkeit genau genug laufen;-)
:
Bearbeitet durch User
Fernsteuermässig das Turmuhrwerk stellen zu wollen wird wahrscheinlich in die Hose gehen weil Pendel viel Energie zum Start benötigen und besser gleichbleibend in Betrieb sein sollten. Die mechanischen Probleme werden da nicht trivial sein. Da wäre es besser eine Elektrokupplung einzubauen um das Zeigerwerk vom Uhrwerk trennen zu können und dann rechtzeitig wieder einkuppeln. Das geht natürlich schlecht im Frühjahr wo die Zeiger zurückgestellt werden müssen und dan 23 Std gewartet werden müssen. Deshalb wäre ein Differenzialgetriebe hier günstiger um dieses Problem zu lösen weil man dann mittels eines weiteren Motors manuell das Zeigerwerk in jede gewünschte Position bringen kann ohne das eigentliche Turmuhrwerk zu stören. Wenn man das mit uC mit Positionsrückgabe macht, liesse sich so eine Funktion automatisieren. Diese alten Turmuhrwerke mussten nicht mit bi-anno Zeitumstellungen leben. Dann kommt noch der historische Hinblick dazu.
Gerhard O. schrieb: > temp schrieb: >> Solange der >> DCF Empfänger halbwegs brauchbare Signale liefert sollte ich damit keine >> einzige Sekunde verlieren oder gewinnen. > > Das ist der Punkt der mir Sorgen macht weil die LW Signale leicht > gestört werden können. Es genügt eine LED Lampe oder SNT welche zufällig > in den Bereich von DCF driftet und man hat temporären Totalausfall der > Impulsfolge. Ich habe leider Leuchten, die mir den DCF-Empfang stören, klar. Seit ich nun öfter zuhause bin, sehe ich aber auch Ausfälle, die nicht mit lokalen Störungen korrelieren und meist nur wenige Minuten andauern. Wenn ich am PC bin, gucke ich auf https://dcf77logs.de/live, der sitzt rund 210 km Luftlinie von mir entfernt und praktisch immer protokolliert auch der Thomas Ausfälle. Es ist damit eindeutig, dass der DCF öfter mal für kurze Zeit ausfällt, und auch dann, wenn die unwetterzentrale.de keine kritischen Wetterlagen zeigt.
@ temp Hast du die Untersuchungen bzw. Messungen tagsüber oder während der Dunkelphase gemacht? Bedenke, dass die Phasenfehler von DCF nachts bedingt durch die Ausbreitung bzw. Boden-/Raumwellen-Überschneidungen locker 10-mal so groß sind... Sieh dir die Veröffentlichungen der PTB dazu an. Bedeutet, dass extreme Mittelungs- bzw. Integrationszeiten nötig sind, damit diese Tag-/Nachtschwankungen nicht zu periodischen Schwingungen führen. Bedeutet auch: Dein Mittelwert ist zwar über genügend lange Beobachtungszeit richtig, aber die (Kurzzeit-)Stabilität ist *absolut beschissen* (auch wenn man das als gebildeter Mensch "feiner" formulieren kann). Ob das für dein Pendel wünschenswert ist, überlasse ich deiner Entscheidung. temp schrieb: > Wir wollen neben der Synchronisation auch das Stellen nach > Stromausfällen zur Sommer/Winterzeitumstellung realisieren. Deshalb ist > der DCF Empfänger sowieso an Bord. Dann würde ich so vorgehen (=keine Arbeitsanweisung!): Sekundentakt aus einer absolut stabilen Quelle beziehen und die absolute Zeit (zur Korrektur des Werks) aus dem vorhandenen DCF-Empfänger auslesen. Dann entfällt der ganze Quatsch mit Ticks zählen, über etliche zig Stunden mitteln und und... Wie bereits gesagt: Ein OCXO mit max.(!!) 100 pbb/a (= 1*exp(-7)) Drift liefert bei Weitem stabilere Sek.-Pulse über einen langen langen Zeitraum. Das ist einfach ein anderer Schnack als ein Q.-Oszillator mit 60 ppm Grundabweichung und sehr wahrscheinlich deutlich schlechterer Stabilität, der mit PLL nachgezogen werden muss. Der OCXO (z.B. meine gebrauchten (!!) Isotemp) kostete nicht mal 25€ und läuft von Anfang an nach dem Einschalten (= nach 5 Min.) mit <10exp(-8) los und liegt nach <1h stabil auf wenigen 10exp(-9), und zwar ohne weitere Stabilisierungs-Maßnahmen (Spannung, Temperatur) "nur" am einfachen LNG. Eine vergleichbare Stabilität wirst du mit der DCF-PLL kaum bzw. nicht erreichen, wenn du nicht erheblichen Aufwand am Empfänger, dessen Auswertung und der Regelschaltung treibst; da bin ich 100% sicher. Nur meine Meinung dazu. Aber wenn die dir Programmiererei samt Anpassung/Optimierung sooo viel Spaß macht, dann sei es so und dann mach es so... Es ist ja nicht mein Projekt.
WWVB hat sich in den letzten dreissig Jahren bei mir als extrem zuverlässig erwiesen. Die Signalstärke ist immer robust, obwohl ich das jetzt nicht messtechnisch belegen kann. Im Oszi sieht das Signal am Antennenverstärkerausgang immer recht solide aus. Die aktive Ferrit Antenne ist bei mir im Keller in ungefähr Erdhöhe und führt über 20m RG-58AU zum Hauptgerät. Der RX ist vom Synchron Costas-Loop Typ der wahrscheinlich besser funktioniert als einfachere Filter Empfänger mit Bit Slice Datentrenner. Kann da leider nicht wirklich vergleichen. Das Datenausfall-LED am Spectracom war bei mir noch nie an. Die Lock-Bandbreite des Systems ist nur +/- 2Hz (mit Synthesizer erforscht). Darüber hinaus versagt der Costas PLl-Lock. Die PLL-Zeitkonstante ist um 30+ s. Wenn ich die Antenne abklemme dauert es 1m bis das UNLOCK LED angeht. Nachtrag: Im Anhang ist ein Video mit 10Mhz im Lissajous XY-Modus. https://www.govinfo.gov/content/pkg/GOVPUB-C13-511e61ddbd62d1cdd99ca3e94e258eff/pdf/GOVPUB-C13-511e61ddbd62d1cdd99ca3e94e258eff.pdf
:
Bearbeitet durch User
temp (Gast) macht großes Pendel-Regulierungs-Gefasel und vergrätzt alle Leute, die dazu sinnvolle Beiträge machen. Auch weil die bemerken, dass das natürlich keinen Cortex M3 benötigt. Anschließend rudert er zurück auf ein Tiny-11-Problem: > Um nochmal auf den Anfang zurück zu kommen, mir geht es darum einen > Sekundentakt aus einem Quarz zu generieren und den (wenn vorhanden) mit > DCF77 zu synchronisieren. Die absolute Phasenlage spielt natürlich keine > Rolle. Die Anzahl der Sekunden soll aber innerhalb eines halben Jahres > nicht von der DCF Zeit abweichen. Und erklärt seine hochwissenschaftliche auf 72 MHz aufgelöste Erfassung der DCF-Pulse. Wobei er "in einem halben Jahr keine Sekunde verlieren will". Da können wir helfen: Ein halbes Normaljahr hat 15.768.000 Sekunden ;-) OK, das erfordert eine Genauigkeit des Oszillators von 0,00634 ppm. Habe ich schlechten DCF-Empfang und einen Quarz-Sekundentakt mit 50 ppm, so läuft der Quarz-Timer in 5.5 h bis zu eine Sekunde falsch. Jede Stunde synchronisieren wäre nicht verkehrt! Wenn ich den Teilerfaktor (jeden DCF-Puls nur um einen µs-Step) in Richtung des aktuellen DCF-Takts nachführe, lande ich in kurzer Zeit unweigerlich bei einem Fehler von < 5 ppm: Dann reicht es schon, alle 10 Stunden zu synchronisieren... Mache ich das mit einem 72 MHz Quarz, der nur +/-10 K ausgesetzt ist, und einem passend auf 1/72 µS einstellbaren Teiler, lande ich kurzfristig bei Genauigkeiten, wo die DCF-Synchronisierung auch mal einige Tage ausfallen darf. Alles kalter Kaffee, das habe ich schon kurz mit 10 MHz skizziert, viel besser ist das schon vor Jahren in der Artikelsammlung im µC-Net "AVR - Die genaue Sekunde / RTC" zu finden. Aber - oweh, AVR ist ja sein Reizwort! Also viel Spaß bei der Neuerfindung des Rads mit dem M3 Schlaft gut!
temp schrieb: > Ich möchte das Pendel einer Uhr zu DCF77 synchronisieren. Lassen > wir den > mechanischen Teil über einen kleinen Elektromagneten mal außen vor. Mir > geht es hauptsächlich um die Bereitstellung eines genauen, jitterarmen > Sekundentaktes. Über einen DCF77 Empfänger bekommt man zwar auf lange > Sicht einen stabilen Sekundentakt, allerdings jittert das um ein paar ms > hin und her. Diesen Jitter möchte ich am Pendel nicht haben. Also könnte > man sich eine PLL vorstellen die einen 1Hz Oszillator so nachstellt, > dass er den DCF77 Signalen folgt aber nur sehr langsame Änderungen des > Referenzoszillators zulässt. Implementiert werden soll das in Software > auf einem Cortex M3. Hat jemand so eine ähnliche Aufgabe schon mal > gehabt bzw. gelöst? Eine Präzisions Pendeluhr mit einem Sekundenpendel schwingt mit 0,5 Hz. Das Pendelgewicht hat durchaus eine Masse von über 10 Kg. Daraus errechnet man eine Güte des Schwingkreises von x, bitte selber ausrechnen. An diese Güte wird mit man mit Elektronischem Firelanz niemals herankommen.
Kurt schrieb: > Habe ich schlechten DCF-Empfang und einen Quarz-Sekundentakt mit 50 ppm, > so läuft der Quarz-Timer in 5.5 h bis zu eine Sekunde falsch. Jede > Stunde > synchronisieren wäre nicht verkehrt! Klar, jede Stunde synchronisieren geht vielleicht bei einer Digitaluhr, aber nicht bei einem Pendel. Bei deiner Rechnung mit 1s in 5,5h und stündlicher Synchronisation müsste ich das Pendel jede Stunde einmal ca. 1/6tel des Pendelhubs auf einmal verrücken. Also alle Vorschläge, die nicht auf eine kontinuierliche, langsame Nachführung hinauslaufen scheiden aus. Kurt schrieb: > Alles kalter Kaffee, das habe ich schon kurz mit 10 MHz skizziert, > viel besser ist das schon vor Jahren in der Artikelsammlung im µC-Net > "AVR - Die genaue Sekunde / RTC" zu finden. > > Aber - oweh, AVR ist ja sein Reizwort! Nein kein Reizwort, nur für mich ein NoGo. Punkt. Ich zwinge niemanden diese Meinung auf, jeder kann machen was er will. Also ich auch. Ende der Diskussion, warum mich dein AVR Kram nicht interessiert habe ich schon ein paar mal erläutert. Also was soll das? > Also viel Spaß bei der Neuerfindung des Rads mit dem M3 Wenn du mit Rad deinen Artikel in der Artikelsammlung meinst, habe ich nicht vor ein Rad zu erfinden. Nicht alles was keine Ecken hat ist ein Rad. Die Anmerkungen bezüglich des Einsatzes eins OCXO oder bessern Taktgebers habe ich zur Kenntnis genommen. Dieser Weg ist immer offen und die erzielte Genauigkeit proportional zum Preis. Danke an alle die dazu Ausführungen gemacht haben. Zu meiner Ausgangsfrage kamen insgesamt eine halbe Antwort. Akzeptiert einfach, dass ist ein Spaßprojekt und es geht mir nicht nur darum, dass die Turmuhr richtig geht, sondern wie man diese PLL ähnlichen Fragen in Software löst. Und da brauche ich keinen Rat von einem der Anfängerartikel für AVRs verfasst. Hätte ich das dort beschriebene Trivialproblem, hätte ich hier keine Frage gestellt.
Beitrag #6699372 wurde von einem Moderator gelöscht.
Beitrag #6699373 wurde von einem Moderator gelöscht.
Beitrag #6699389 wurde von einem Moderator gelöscht.
Beitrag #6699415 wurde von einem Moderator gelöscht.
Beitrag #6699481 wurde von einem Moderator gelöscht.
temp schrieb: > Die Anmerkungen bezüglich des Einsatzes eins OCXO oder bessern > Taktgebers habe ich zur Kenntnis genommen. Immerhin ein Lichtblick. Man könnte meinen, dass ein RTC-TCXO ein Mittelding zwischen uC-Quarz und OCXO wäre. Im Gegensatz zu letzteren liefert ein digital kompensierter Oszillator aber einen Sägezahn oder noch was schlimmeres. Ein Mittelweg wäre ein guter uC-Quarz, d.h. mit optimalem Schnitt für den tatsächlichen Temperaturbereich im Turm. Die Frequenz kann man sich dann nicht mehr aussuchen, aber die ist bei einem Cortex-M3 auch egal.
Beitrag #6699586 wurde von einem Moderator gelöscht.
Beitrag #6699648 wurde von einem Moderator gelöscht.
Beitrag #6699708 wurde von einem Moderator gelöscht.
Beitrag #6699748 wurde von einem Moderator gelöscht.
Beitrag #6699749 wurde von einem Moderator gelöscht.
Beitrag #6699753 wurde von einem Moderator gelöscht.
Hm, hat die Turmuhr einen Sekundenzeiger? Oder einen springenden Minutenzeiger? Ich würde die Anforderung, dass die Turmuhr max. um eine Sekunde von der richtigen Zeit abweicht, etwas großzügiger auslegen. Ich vermute, selbst einen Unterschied von 20s könnte man kaum ablesen. Allerdings müsste diese Differenz das MAXIMUM darstellen, kein akkumulierendes "20s pro 24h". Ich würde nicht mit dem Sekundentakt von DCF77 synchronisieren, sondern mit der übertragenen Zeitangabe. Dann machen auch längere Ausfälle kein Problem. Über einen Vergleich "DCF-Zeit" mit "Eigenzeit des µC" (aufgrund des Quarz erzeugt) sollte man die "echte" Frequenz des Quarz ermitteln können --- laufend und durchaus mit Mittelungsperioden von Tagen, oder Wochen? In dieser Zeit sollte der kaum mehrere Sekunden weglaufen. Dann die Turmuhr etwas schneller laufen lassen, und wenn der Abstand etwas zu groß wird (über Vergleich Turmuhrpendel - µC-PPS), also regulär vielleicht ein- oder zweimal pro Tag, kurz das Pendel anhalten, und mit dem Beginn des richtigen Ticks wieder freigeben. Über "Kurz anhalten" kann man die Frequenz des Pendels ja gut verringern. Hat der Mechanismus auch eine Möglichkeit, die Frequenz irgendwie zeitweilig zu erhöhen?
Beitrag #6699813 wurde von einem Moderator gelöscht.
Beitrag #6699816 wurde von einem Moderator gelöscht.
Beitrag #6699827 wurde von einem Moderator gelöscht.
Angehängte Dateien:
Hier ist das Schaltbild
Achim H. schrieb: > Hm, hat die Turmuhr einen Sekundenzeiger? Oder einen springenden > Minutenzeiger? Ich würde die Anforderung, dass die Turmuhr max. um eine > Sekunde von der richtigen Zeit abweicht, etwas großzügiger auslegen. Ich > vermute, selbst einen Unterschied von 20s könnte man kaum ablesen. > > Allerdings müsste diese Differenz das MAXIMUM darstellen, kein > akkumulierendes "20s pro 24h". > > Ich würde nicht mit dem Sekundentakt von DCF77 synchronisieren, sondern > mit der übertragenen Zeitangabe. Dann machen auch längere Ausfälle kein > Problem. Über einen Vergleich "DCF-Zeit" mit "Eigenzeit des µC" > (aufgrund des Quarz erzeugt) sollte man die "echte" Frequenz des Quarz > ermitteln können --- laufend und durchaus mit Mittelungsperioden von > Tagen, oder Wochen? In dieser Zeit sollte der kaum mehrere Sekunden > weglaufen. Hallo Achim, damit liegst du richtig. Niemanden interessieren ein paar Sekunden Abweichung, solange sie sich nicht aufsummieren. Wichtig ist halt nur, dass alle Frequenzveränderungen so langsam gemacht werden, dass das Pendel immer hinterher kommt. Selbst wenn du nicht an jeder Sekundenflanke syncronisieren willst wie beschrieben, sondern nur auf die Minutenflanke (nur dann kannst du die Zeit entnehmen), es bleibt die Flanke. Also ich sehe kein Problem das mit ein paar Zeilen Code zu bewerkstelligen. Aber nein, die HW Fraktion nervt mit OCXOs bis zum Erbrechen. Das mag zwar eine sauber Lösung sein, den billigsten bei Mouser gibts für 37€ + MwSt. und Versand. Billige Ebay oder Aliexpresslinks brauche ich auch nicht mit 8 Wochen Lieferzeit und unbekannter Qualität oder Echtheit.
Beitrag #6699868 wurde von einem Moderator gelöscht.
Moin, Was ich eigentlich nicht ganz verstehe ist Folgendes: OK, temp möchte den Jitter von DCF softwaretechnisch verringern. Nun, wenn ich das Prinzip der Brandtschen Synchronisierung rictig verstehe, vergleicht es den einkommenden (DCF) Sekundentakt mit den Nulldurchgängen des Sekunden-Pendels und reagiert dann mit bremsenden oder beschleunigend Impulsen von der Pickupspule die direkt unter dem BDC des Pendels angebracht ist und mit dem am unteren Ende des Pendel angebrachten Magneten bis das Pendel so gut wie möglich mit den DCF Sekundenpulsen übereinstimmt. Die Antriebsspule unter dem Pendel fungiert doppelt als Nulldurchgangsdetektor für die Steuerelektronik und Antriebsspule. Da da Pendel eine enorme Inertia aufweist ist ein DCF Jitter vollkommen bedeutungslos. Wie meine Observationen gestern aufweisen ist der Jitter bei mir unter einer Mikrosekunde auf 10MHz bezogen. Der tatsächliche 60kHz Jitter ist dann folglich um den Faktor 167 kleiner. Wenn man nun annimmt, daß der Ausbreitungsjitter von DCF ähnlich wie bei mir mit WWVB ist, wäre der DCF Jitter auf der Trägerwelle nur ein 129igstel auf meine Anlage bezogen und folglich nur ein paar wenige ns. Da lohnt sich Deine SW Aufbereitung eigentlich nicht. Wieso wird dem DCF Jitter dann so viel Bedeutung beigemessen? Die Inertia des Pendels kümmert sich da überhaupt nicht darum. Auch sind die Größenordnungen zwischen DCF Jitter und Pendelperiode lächerlich massiv. Auch kurzzeitige Ausfälle des DCF Sekundentakt haben lediglich zur Folge, daß das Pendel dann mit seiner natürlichen Periode als schweres Schwungrad weiterschwingt. Es macht absolut nichts aus wenn zeitweise unregelmäßige Synchroniersignale eintreffen. In der Hinsicht dürfte das Brandtsche Konzept sehr robust sein. Es ist meiner Meinung nach nicht notwendig auf eine ununterbrochene Synchronisierimpulsfolge zu bestehen. Was sagt übrigens das User Manual zu empfohlenen Qualität der externen Taktquelle? Sind kurzzeitige Unterbrechungen erlaubt? Gibt es einen Link zur Brandtschen Dokumentation? Es würde mich interessieren wie er sich zu dieser Problematik stellt. Nichts für ungut. Ich sehe Dein Projektansatz als eher ein bisschen Overkill und eher ein explorerisches Projekt mit dem Weg als Ziel. Das ist auch in Ordnung. Ich frage mich aber wie viel Sinn es hat ein traditionelles Uhrwerksystem ins 21. Jahrhundert zu zwängen wo man perfekte Operation erwartet. Gerade die zweimaligen Zeitumstellungen sind für ein einfaches Pendelwerk überaus intrusiv. Eine Pendeluhr sollte niemals angehalten werden. Ohne trennbare Zeigerwerkkupplung ist das aber notwendig. Und nan hält so ein schweres Pendel nicht einmal nur so an um es dann wieder losschwingen zu lassen. Es braucht einige Zeit um sich wieder zu stabilisieren. Hat das Uhrwerk übrigens tatsächlich ein Sekundenpendel? Irgendwie kommt mir das ungewöhnlich vor. Viele alten TUWs hatten oft langsamere Pendel mit mehr Kraft. OK, ich muß jetzt weg und für mich ist erst einmal Funkstille. Schönen Tag noch, Gerhard
:
Bearbeitet durch User
temp schrieb im Beitrag #6699868: > Es wird doch wohl reichen > wenn ich einmal sage, dass es mir um was anderes ging. Jaja, wir wissen schon... :-D temp schrieb: > Niemanden interessieren ein paar > Sekunden Abweichung, solange sie sich nicht aufsummieren. Soso, "ein paar Sekunden" interessieren nicht, jedoch "lange" vorher... temp schrieb: > es geht hier ..... nur um einen gleichmäßigen Sekundentakt der nicht mehr > als eine Sekunde vom DCF77 abweicht. Aha, nicht mehr als eine Sekunde. Da ist nun plötzlich das großzügige Fenster zum "engen Höschen" mutiert (oder umgekehrt, egal). :-D "Was interessiert mich mein Geschwätz von gestern.." Du widersprichst dir selbst, merkst du das nicht? Die Wiederholungen von mir haben nur das eine Ziel, dass es endlich in deine Birne reingeht. Aber du willst anscheinend nicht begreifen, auf welchem Holzweg du dich mit deiner SW-Idee befindest, die niemals eine annähernd vergleichbare Stabilität erreichen wird. Wenn deine entwickelte SW genauso viele "Jederzeit-flexibel-Variablen" wie eben gezeigt enthält, na dann "Gute Nacht Marie". :-))) Und wer anstatt mit stichhaltigen Argumenten nur noch mit Anfeindungen und "Fremdwörtern" argumentieren kann, dem ist eh nicht zu helfen. __________ Übrigens: Um mich zu (Ausfälligkeiten) provozieren, müssen andere kommen.. :-D
Beitrag #6699966 wurde von einem Moderator gelöscht.
Beitrag #6699984 wurde von einem Moderator gelöscht.
Achim H. schrieb: > Ich würde nicht mit dem Sekundentakt von DCF77 synchronisieren, sondern > mit der übertragenen Zeitangabe. Dann machen auch längere Ausfälle kein > Problem. Über einen Vergleich "DCF-Zeit" mit "Eigenzeit des µC" > (aufgrund des Quarz erzeugt) sollte man die "echte" Frequenz des Quarz > ermitteln können --- laufend und durchaus mit Mittelungsperioden von > Tagen, oder Wochen? In dieser Zeit sollte der kaum mehrere Sekunden > weglaufen. So ähnlich läuft es bei mir zwischenzeitlich schon Jahrzehnte, allerdings noch mit integrierten Schaltkreisen (Zähler, Schieberegister usw). Mittels eines einfachen 32768 Quarz wird ein 1Hz Signal erzeugt, welches die Sekunden usw antreibt. Über einen DCF77 Geradeausempfänger wird die Uhr synchronisiert. Da es natürlich bei Gewitter usw. zu Störungen und damit zu Aussetzern kommt, habe ich folgendes Verfahren angewendet: Die übertragene Zeit wird als richtig bewertet, wenn das Zeitdiagramm der folgende Minute genau um 1 höher ist, als das der aktuellen Minute, wobei nur 16 Bit, also nur ein Teil des gesamten Diagramms (ab Sekunde 20), verwendet wird. Damit läuft die Uhr nun schon jahrelang sekundengenau. Allerdings gibt es bei Stromausfall keine Überbrückung, sodass die Uhr erst einige Zeit braucht, um wieder die richtige Uhrzeit anzuzeigen. Lang lang ist es her, aber ich hoffe, dass ich das Verfahren richtig dargestellt habe.
:
Bearbeitet durch User
Beitrag #6700071 wurde von einem Moderator gelöscht.
Beitrag #6700128 wurde von einem Moderator gelöscht.
Beitrag #6700150 wurde von einem Moderator gelöscht.
temp schrieb im Beitrag #6700071: > Ich denke der 2. Fehler ist, dass ich vom Jitter der massgebenden 1sec > Flanke eines DCF Empfängers rede, du das aber mit dem Jitter der 77kHz > Grundwelle vermischst. Und Jittern der Grundwelle ist ist komplett > Wumpe. > Die 1sec Impulse jittern aber bei meinem Empfänger um bis zu 5ms, was > sich im Mittelwert komplett eliminiert. Ich hatte halt nur die > Befürchtung die 5ms gehen in Richtung weniger mm Pendelweg und das > könnte zu viel sein. Das war mir nicht bewußt, daß Du mit der dekodierten Zeitinformation als Taktquelle arbeiten willst. Das ist sehr sportlich weil natürlich alle dies LW Systeme beträchtliche Ausbreitungsvariation haben. Ich habe Dein Projekt falsch verstanden weil ich immer davon ausging, mit der Trägerwelle zu arbeiten die tatsächlich sehr wenig Jitter aufweist. NIST spricht sich darüber auch aus, daß Systeme die auf Zeitdaten basieren, diesen Jitter aufweisen der nicht wirklich gut eliminiert werden kann. Die besten Ergebnisse einer Jitterverminderung nach der PTB waren 2ms. Ich hing davon aus, daß der Brandtsche Apparat nur eine verlässliche Pendelperiodentaktquelle benötigt. Die von 77.5kHz abzuleiten hat mehr Sinn weil Du dann Atomfrequenznormalgenauigkeit direkt hast. Ich bin der Ansicht, von dem was mir über Zeitdatenerfassung mittels LW Bekannt ist, DCF und WWVB nur für die Tagessynchronisation von Radio kontrollierten Uhren eingesetzt wird. Um das Jitterproblem zu vermindern hat man bei DCF eine Spread Spectrum Modulation hinzugeführt um eine genauere Zeitkorrelation zu ermöglichen da diese SS Phasen Modulation mit dem Träger in Realzeit existiert. Mit dieser Methode und entsprechend aufwendiger Technik und Software lässt sich angeblich der Jitter auf 2ms reduzieren. Vielleicht hätte es Sinn darüber mehr zu erfahren und Ansätze in dieser Richtung zu unternehmen. https://www.ptb.de/cms/en/ptb/fachabteilungen/abt4/fb-44/ag-442/dissemination-of-legal-time/dcf77/dcf77-phase-modulation.html ftp://ftp.ptb.de/pub/time/DCF77Lit/Hetzel_DCFBPSK_1988_EFTF_.pdf http://endorphino.de/projects/electronics/timemanipulator/index_en.html Jedenfalls ist diese Angelegenheit nicht trivial. Vielleicht wären einfachere Lösungen doch zweckmässiger. Die Bottom Line ist einfach die: Wenn die mitgelieferte Zeitinformation nicht zur totalen absoluten Zeiteinstellung wie bei Radiouhren herangezogen wird, was bei Deinem Turmuhrwerk niemals vorgesehen war, dann wäre es besser DCF als genaue Trägerbasierte Taktquelle auszunützen oder eine andere autonome genaue Taktquelle einzusetzen. Zeitdatensätze von DCF sind dafür in der Timing einfach zu ungenau wenn man nicht die SS Technik einsetzt. Es ist anzunehmen, daß ein Eigenentwicklungsaufwand in dieser Richtung beträchtlich sein dürfte.
:
Bearbeitet durch User
temp schrieb im Beitrag #6700150: > Gerhard O. schrieb: >> Da er einen Magnet unter dem >> Pendelkörper angebracht hat > > Hat er nicht, steht im Patent. Nur eine Mutter aus Stahl... > > Der Magnet zieht das Pendel immer nur an, ist es schon knapp am Magneten > vorbei wird es abgebremst, ist es kurz davor wird es beschleunigt. Steht > es genau drüber, wird es nur "gestreckt". Steht auch so im Patent. > > Das geht aber nur immer in einer Pendelrichtung, in beiden macht das > Verfahren keinen Sinn. Bei mir am Ende 2sec. Hört sich plausibel an. Da dachte ich vielleicht zu kompliziert.
:
Bearbeitet durch User
Beitrag #6700323 wurde von einem Moderator gelöscht.
temp schrieb: > allerdings jittert das um ein paar ms > hin und her. Diesen Jitter möchte ich am Pendel nicht haben. Das wirst du kaum an das Pendel übertragen können, es sei denn du schaltest deine Magneten digital an und aus und sie haben ein so massiv hohes Magnetfeld, dass sie das Pendel vollständig führen. Ich würde stattdessen empfehlen, einen Sinusgenerator laufen zu lassen und den auf den E-Magneten zu geben und zwar so, dass er das Pendel nur im Promille-Bereich beschleunigt. Dann ist das Pendel zwar immer etliche 100ms hinterher (idealerweise um die 40°-60°) es hat aber dann permanent Zeit, sich auszugleichen, weil sich die ms mit eben einen minimalen Faktor beschleunigend übertragen. Das Pendel wird quasi erst auf Dauer um die ms nach vor geschoben, wenn sich eine statische Zeitdifferenz aufbaut. Du hast quasi eine elektrische Dämpfung mit hohem (magnetischen) Innenwiderstand vorgeschaltet, welche der mechanischen Dämpfung vorgelagert ist. Das reict so völlig aus, solange das Pendel von sich aus eine ausreichende Grundgenaugikeit im Bereich von Prozenten hat, also ohne Eingriff schon einigermassen korrekt schwingt. Du brauchst also nur einen digitalen Zähler, der z.B. 32 Werte einer DDS steuern kann und selber ein 1S-Signal abgibt, das mit dem einfallenden 77er verglichen wird und anhand dessen der interne Zähler sich im Tempo anpasst. Es reicht völlig wenn der das zu 2-3% genau verfolgt und selber massiv jittert, wenn er nur einen Bruchteil seiner Energie auf den Empfänger überträgt.
Beitrag #6700348 wurde von einem Moderator gelöscht.
Vor fast 30 Jahren habe ich das Synchronisationsproblem so gelöst, dass ein Pendel oben über einen Faden angehoben und somit verkürzt werden konnte. Der Faden wurde verkürzt oder verlängert und somit auch die Pendeldauer verändert. Dazu wurde jeder zweite Durchgang (0,5s) über einen Durchgang durch eine Lichtschranke ausgewertet und je nach Zeitverzug verlängerte oder verkürzte ein Schrittmotor die Fadenlänge. Jitter hat dabei keine Rolle gespielt. Die maximale Abweichung vom Gong der Tagesschau lag über einen Monat gefühlt unter unter 1/10 Sekunde, gemessen an der Zahl der Schritte des Schrittmotors, wenn um 20 Uhr eine Korrektur erforderlich war. CPU war 6809, alle Software in Assembler im EEPROM.
temp schrieb im Beitrag #6700150: > Der Magnet zieht das Pendel immer nur an, ist es schon knapp am Magneten > vorbei wird es abgebremst, ist es kurz davor wird es beschleunigt. Das ist eine oft gemachte, aber sehr unglückliche Lösung, weil sie ein systematisches Problem enthält: Ein Pendel, dass schon sehr früh dran ist und kaum noch Beschleunigung braucht, ist damit viel näher am Magneten, als das spätere, welches mehr Beschleunigung braucht, weil es mehr hinterher ist. Dummerweise bekommt aber diese entferntere Pendel infolge des Abstandes und des schnell abnehmenden Magnetfeldes weniger ab, während das nahe/früher zuviel abbekommt. Damit funktinoiert die on/off Technik nicht und induziert massive Oberwellen in die Schwingung, die beim nächsten Durchlauf wieder weggeregelt werden müssen. Richtig wäre es, das Magnetfeld nichtlinear zu steuern, dass beim Annähern erst eine hohes und dann ein immer kleiner werdendes Magnetfeld herrscht, sodass im Nulldurchgang das Pendel frei schwingt und gar nicht beschleunigt wird. Angetrieben oder gebremst werden damit nur Pendel, die ausreichend weit weg sind. Dies zu regeln ist aber nicht so einfach, weil die Wirkung des Streufeldes schwierig einzuschätzen ist, daher sollte man das einfach statisch steuern, indem man eine permanente Sinus-Schwingung der doppelten Frequenz auf den Magneten gibt. Das Verhalten ist dann dasselbe, wie man es von einem Nagel kennt, an dem eine Saite befestigt ist: Der schwingt auch mit der doppelten Frequenz und regt einmal nach unten und einmal nach oben an. Das sollte hier reichen, obwohl das Pendel keinen echten Sinus macht. Wer es genauer will, muss Annahmen über das System machen (Reibung, Resonanzen) und passend Vorsteuern. Man muss dann einen autodapativen Sinus-Generator bauen und dem die passenden Oberwellen beimischen, sodass sich über das entstehende Feld hinweg eine gleichförmige Beschleunigung ergibt. Diese Technik findet so in einem elekromechanischen System eines Kunden Anwendung und ist meines Wissens als Methode nirgends patentiert. Es wurde damals recherchiert woweit ich weiß. Patentiert ist lediglich das System des Kunden, das einen etwas anderen Fokus hat und bei dem die geschickte Steuerung des Aktors nur ein Beiwerk ist - wenn auch ein nicht ganz Unwichtiges! Dieser steuernde Teil der Lösung wurde mehr oder weniger 1:1 aus meiner Musikworkstation entnommen und findet sich inzwischen auch in meiner Piano-Emulation sowie einer Lautsprecher-Membran-Steuerung, zudem gibt es ähnliche Mechanismen auch im Bereich der adaptiven Rastmomentkompensation bei Schrittmotoren. Das Thema ist nach meinem Kenntnisstand weitgehend abgegrast und durchgekaut und sollte daher ohne Patentverstoss einfach nachbaubar sein.
Meine Uhr schrieb: > Der Faden wurde verkürzt oder verlängert und somit auch die Pendeldauer > verändert. Auch eine Idee, eine mechanische PLL zu realisieren. Ich kann dazu noch eine Idee beisteuern, das Pedel mit Luftdämpfung zu regeln, indem eine geschlossene Uhr, bei der das Pendel Luft verdrängen muss, wenn es zum Rand kommt, ein Loch hat das mit einem Ventil verschlossen ist. Die minimale Änderung der Bremsung des Pendels macht sich gan gehörig bemerkt bar. Ich halte aber die Magnetmethode für die Einfachste, zumal sie das Potenzial hat, das Pendel dauerhaft im Tempo zu halten, ohne die Uhr nochmal aufziehen zu müssen.
Beitrag #6700362 wurde von einem Moderator gelöscht.
Jürgen S. schrieb: > Das wirst du kaum an das Pendel übertragen können, es sei denn du > schaltest deine Magneten digital an und aus und sie haben ein so massiv > hohes Magnetfeld, dass sie das Pendel vollständig führen Klar wird der Elektromagnet digital angesteuert für wenige ms. Der ist auch nicht besonders groß. Er muss das Pendel auch nicht vollständig führen, der stete Tropfen höhlt den Stein. Das Pendel selbst hat nun an der Stelle wo der Elektromagnet sitzt seine höchste Geschwindigkeit und die genannten 5ms Jitter entsprechen ein paar mm Pendelweg. Dann mittelt sich das eventuell auch über die Zeit, aber einen Ersatz wenn DCF ausfällt brauche ich ohnehin. Jürgen S. schrieb: > Das reict so völlig aus, solange das Pendel von sich > aus eine ausreichende Grundgenaugikeit im Bereich von Prozenten hat, > also ohne Eingriff schon einigermassen korrekt schwingt. Das ist ein Uhrenpendel, 1 Prozent entsprechen 14,4 Minuten am Tag. Wenn die so verkehrt gehen würde, wäre der Vorschlaghammer das einzig sinnvolle Werkzeug. Also weniger als 1% ist es immer. Jürgen S. schrieb: > Du brauchst also nur einen digitalen Zähler, der z.B. 32 Werte einer DDS > steuern kann und selber ein 1S-Signal abgibt, das mit dem einfallenden > 77er verglichen wird und anhand dessen der interne Zähler sich im Tempo > anpasst. Es reicht völlig wenn der das zu 2-3% genau verfolgt und selber > massiv jittert, wenn er nur einen Bruchteil seiner Energie auf den > Empfänger überträgt. Das ist sicher ein Weg. Ich habe aber, und das betone ich jetzt auch gebetsmühlenhaft nicht nach denkbaren Lösungsansätzen gefragt, sondern ob jemand das Problem schon mal hatte und gelöst hat. Wie gestern schon berichtet, habe ich mein Problem für mich gelöst. Mit ca. 100 Zeilen Code incl. Kommentaren. Die DCF Nachführung läuft jetzt einen Tag durch, Jittert im 100µs Bereich, ist im ms Bereich phasengleich und ändert was es zu ändern gibt ausreichend langsam. Also das was ich wollte. Und eigentlich war nur das das Thema des Threads. Wenn es jemanden ernsthaft interessiert, bitte melden. Nach diesem Thread, in dem sowieso alles nur Softwarehasser und c-hater vertreten waren, werde ich mich hüten irgendwas in diesem Forum öffentlich zu machen. Privat gerne.
Beitrag #6700391 wurde von einem Moderator gelöscht.
Beitrag #6700402 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten
