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?
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.
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...
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. ^^
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.
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.
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.
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
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.
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...
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
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_8jjyCMwhttps://waitingtrain.blogspot.com/2008/08/wating-train-mechanism.htmlhttps://waitingtrain.blogspot.com/2014/08/https://waitingtrain.blogspot.com/2008/09/wt-video.html
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. :-)
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.
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
...
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.
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.
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.
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 ...
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
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"
??
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?
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;-)
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)
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.
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.
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...
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,
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
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.
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.
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;-)
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
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.
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.
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?
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.
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
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
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.
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.
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.
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.
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.
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.
