Hallo, ich programmiere gerade eine Steuerung, bei der ich eine sehr genaue Zeitbasis brauche. Mit meinem 10MHz Quarz klappt es nicht so ganz. Der hat Abweichungen von bis zu 10ms pro Minute (im Vergleich zum 50Hz Netz, welches doch sehr genau ist). Dazu schwankt diese Abweichung unkontrollierbar, ansonsten hätte ich einen Korrekturwert in den Timer einfügen können. Hat von euch jemand eine Idee, wie man diese Schwankungen ausgleichen kann?
Was genau willst Du denn machen? Geht es Dir um die Anzahl der Takte oder willst Du eine zeitliche Verzoegerung realisieren. Da kann es schon sehr viel bringen den Quarz mal genau auszumessen und F_CPU entsprechend zu setzen. Dummerweise lassen sich manchmal minimale Abweichungen nicht vermeiden, wenn der Quotient keine natuerliche Zahl ist. Aber 10ms pro Minute hoert sich schon ein bisschen sehr heftig an... ;) Michael
>>10ms pro Minute
Das sind 3ppm, das darf er, das schwankt allein mit der Temperatur so
stark. GPS oder DCF77 sind genauer.
Cheers
Detlef
Es geht um eine Steuerung, welche in einem 50Hz Netz mit starken Störungen eingesetzt werden soll. Dazu bräuchte ich einen netzsynchronen Takt, allerdings wandert der bei mir immer hin und her, hat also keine gleichmässige Abweichung.
Ein normaler Quarz oder Oszillator hat eine Genauigkeit von ca. +/- 100ppm. 10 Millisekunden von 1 Minute sind ca. 160pm. Insofern liegt Dein Quarz also noch in den Spezifikationen :-) Uhrenquarze 32KHz sind da genauer. So ca. 10 bis 20 ppm. Wenns genauer sein muss, musst Du TCXO nehmen. Genauigkeit ca. +/- 2.5ppm Joachim
@ Phase IV (Gast) >ich programmiere gerade eine Steuerung, bei der ich eine sehr genaue >Zeitbasis brauche. Mit meinem 10MHz Quarz klappt es nicht so ganz. Der >hat Abweichungen von bis zu 10ms pro Minute (im Vergleich zum 50Hz Netz, Aua! Das Netz is alles andere als kurzzeitstabil! Damit zu messen ist Quark. Nimm einen guten Frequenzzähler oder Generator. Ein 0815 Quarz hat ca. +/-100ppm Toleranz ohne Abgleich, das sind 6ms/Minute. Mit einem Abgleich per Trimmkondensator bringt man den locker auf +/-5ppm und besser. Beleibt noch die thermische Drift, die je nach Typ und Temperaturbereich +/-50ppm erreichen kann. Aber beim Abgleich NICHT am Quarz messen, sondern an einem anderen Pin, welches entweder den Takt ausgibt (können einige uCs) oder ein normales IO-Pin, über das mittels konstanter Schleife ein Takt generiert wird. >welches doch sehr genau ist). Dazu schwankt diese Abweichung >unkontrollierbar, ansonsten hätte ich einen Korrekturwert in den Timer Nein, deine Netzfreqeunz schankt, der Quarz steht stabil (wenn die Schaltung nicht völlig vermurkst ist). @ Michael G. (linuxgeek) >vermeiden, wenn der Quotient keine natuerliche Zahl ist. Aber 10ms pro >Minute hoert sich schon ein bisschen sehr heftig an... ;) Nöö, das sind gerade mal 166ppm. Wenn die Lastkapazitäten schlecht auf den Quarz abgestimmt sind ist das normal. MfG Falk
@ Phase IV (Gast) >Es geht um eine Steuerung, welche in einem 50Hz Netz mit starken >Störungen eingesetzt werden soll. Dazu bräuchte ich einen netzsynchronen >Takt, Ja was denn nun? Entweder genau ODER netzsynchron. Ersteres erreciht man mit einem abgelichen Quarz oder genauen Quarzoszillator. Letzteres bvenötigt eine PLL, hier sinnvollerweise in Software. Dazu musst du jeweils die Länge einer Netzperiode messen und das Ergebniss in deiner Tajtgenerierung verwenden. > allerdings wandert der bei mir immer hin und her, hat also keine >gleichmässige Abweichung. Das ist das Netz, welches auf Lasten reagiert. Nicht der Quarz. MfG Falk
http://www.etrans.ch/services/online/frequency/ ein Online-Anzeige der derzeitigen Abweichung der Netzfrequenz http://de.wikipedia.org/wiki/Netzfrequenz da steht dieser Link
Ist das Netz wirklich so ungenau? Habt ihr vielleicht eine Idee, wie man etwas netzsynchron ansteuern könnte, trotz Störungen (extreme Spannungsschwankungen)?
Ich wuerd ein Netzfilter nehmen, dann einen Trafu und hintendran einen PLL, der mit dem Netz mitlaeuft. Der PLL kann mit einem Controller gemacht sein. Der PLL laeuft weiter auch wenn das Netz kurz mal aussetzt.
10 Millisekunden geteilt durch 60 sec ist gleich 1/6 Millisekunde =166 µs Abweichung pro Sekunde also 166ppm
ich würde mal sagen 166 Taktzyklen Abweichung pro Sekunde, macht bei 10MHz dann 16,6 ppm (wegen parts per million)
Ist doch ganz einfach (seth alles oben) 1) Genauer => besser tollerierten Quarz 2) Netzsynchron => Dann muss man natürlich das Netz in Dein Sytem "einfließen" lassen und z.B. auf die Null-durchgänge Triggern und die "Aktionen" anstoßen. Dabei bist Du wieder so "genau" wie Deine Basis, aber eben Synchron !
...gut, wer zählen kann ist besser dran.. wenn man genau hinguckt passt das. Gruß vom halbblinden ts
Aua Dann nimm einen 1000 MHz Quarz, der hat dann nur noch 1,66 ppm Fehler nach deiner Berechnungsmethode
nein sogar nur 0,166... ppm ist eine relative Angabe, völlig unabhängig vom Absolutwert der Frequenz. in dem Bild hatte die Netzfrequenz gerade 49,960/50 = 800ppm Abweichung vom Sollwert, also die 166 ppm sind noch wenig.
@ Phase IV (Gast) >ich würde mal sagen 166 Taktzyklen Abweichung pro Sekunde, macht bei >10MHz dann 16,6 ppm (wegen parts per million) Ja, eben! Parts per Million, nicht zehn Millionen! MFg Falk
Der Quarz liegt -75.75dB daneben: 20*log10(0.01/60) . Inzwischen gelingt es mir auch auf 166ppm zu kommen, nachdem ich die Minute zu 60sec statt zu 3600sec rechne. Wenn man netzSYNCHRON sein will, nützt ein Quarz garnichts, wenn man den nicht entsprechend der Netzfrequenz zieht. Dann kann man aber gleich ne PLL nehmen. Ich würde das mit nem AVR so machen: Taktfrequenz 16MHz variabel über nen fein (fein!, die Genauigkeit muß auch im ppm Bereich liegen) konfigurierbaren Teiler oder ne DDS auf 50Hz runterteilen, dann ne PLL mit der Netzfrequenz. Die Netzfrequenz über nen Trafo galvanisch oder auch über ne Energiesparleute und ne Photodiode optisch auf nen Komparator und einen entsprechenden Eingang. Die PLL kann man digital beliebig träge machen, sodaß kurzfristige Schwankungen nicht nur nichts ausmachen, sondern auch erkannt werden können. Wenn der lokale Oszillator genügend stabil ist, kann man die Schwankungen der Netzfrequenz selbst messen. Damit ist man gut netzsynchron. Cheers Detlef
@ Detlef _a (detlef_a) >Der Quarz liegt -75.75dB daneben: 20*log10(0.01/60) . Inzwischen gelingt Und du liegst 100% daneben. Seit wann werden Frequenzabweichungen in dB angegeben? >Wenn man netzSYNCHRON sein will, nützt ein Quarz garnichts, wenn man den >nicht entsprechend der Netzfrequenz zieht. Oh doch, für eine Software-PWM! >konfigurierbaren Teiler oder ne DDS auf 50Hz runterteilen, dann ne PLL Wozu die DDS? Der Controller kann sowieso "nur" im 16 MHz Raster arbeiten. Dazu braucht man keine externe DDS, ein klein wenig Periodendauermessung + Mathematik reichen aus. MfG Falk
>>Seit wann werden Frequenzabweichungen in dB angegeben? Mach ich immer so. Deswegen habe ich mich bei ppm auch verrechnet. Nein, is natürlich nur nen Witz, Frequnzabweichungen werden selbstverständlich immer und nur in ppm angegeben, da hast Du völlig Recht! >>Oh doch, für eine Software-PWM! Was meinste denn damit? Um netzsynchron zu sein brauchts keinen Q nicht! >> Dazu braucht man keine externe DDS Von extern habe ich nix gesagt, die kann man in Software machen. Kann man aber mit Periodendauer und klein wenig Mathematik auch anders machen, so genau wurde zur realen Aufgabe ja nix gesagt. Cheers Detlef
@ Detlef _a (detlef_a) >>>Oh doch, für eine Software-PWM! Arrggh! Ich meinte natürlich Software-PLL! War in Gedanken schon wieder wo anders. >Was meinste denn damit? Um netzsynchron zu sein brauchts keinen Q nicht! Doch! Schliesslich will er doch ne präzise Steuerung bauen. Da würde ich mich nicht auf den internen RC-Oszillator stützen. Schliesslich kann die PLL (egal ob in Hard-oder Software) sich bestenfalls alle 20ms synchronisieren, praktisch eher weniger. In der Zeit sollte der lokale Oszillator nicht sonst wohin weglaufen. MFG Falk
>>Da würde ich mich nicht auf den internen RC-Oszillator stützen.
Nein, der ist dazu zu instabil. Ich meinte, daß man den Taktquarz des
Prozessors mitbenutzt, also nicht noch einen weiteren Quarz braucht. Ob
man lokale VCOs bauen kann, die ohne Q hinreichend stabil sind, hängt
von der geforderten Genauigkeit ab (und von der Fähigkeit des Bauenden,
stabile VCOs zu bauen).
Cheers
Detlef
Ich wuerd den internen RC Oszillator fuer den PLL nehmen. Diesen RC Oszillator kann man tunen. Man will ja sowieso einen PLL machen, und dies ist der VCO. Der Phasenfehler darf ueber 100 Perioden nicht allzu gross werden. Mehr braucht an nicht.
Das geht so nicht. Die Abstimmbarkeit des internen RC geht beim Mega128 von 50% Nominalfrequenz bis 200% Nominalfrequenz, also Faktor 4 aufgeteilt auf 256 ticks. Ne Frequenz trifft man also mit höchstens 1% Genauigkeit. In 100 Perioden ist Deine 'PLL' dann eine Periode weg. Quarzgetakteten uC nehmen. Prozessortakt mit Zähler runterteilen, damit nen Interrupt treiben, der auf Summe S immer x aufsummiert. Zweiter Interrupt mit Nulldurchgang der Netzspanung, der zieht von Summe S immer y ab. Ne PLL bauen, die Summe S auf Null regelt, indem sie y verändert (y ist >> x, dh. die Zählerinterrupts kommen häufiger). Das Verhältnis x/y entspricht dann dem Verhältnis der Frequenzen. Cheers Detlef
Das ist nicht ganz richtig. Der Bereich des RC ist auch nicht linear. Wenn man den RC mit einem 32k Quarz kontrolliert, hat man keine Probleme mit der Baudrate zB. Aber ja, ein Nachbau eines DDS im Prozessor ist moeglicherweise genauer. Auf den Nulldurchgang zu gehen halte ich fuer unguenstig. Bei einem Rundsteuersignal jittert der ein rechtes Stueck. Dann besser wie ein richtiger PLL beide Signale kontinuierlich Multiplizieren und integrieren. Ein Kilosample auf beiden Kanaelen ist mehr als genug dazu. Der Controller muss ja sonst nicht mehr viel tun.
Der RC hat zwei sich überschneidende einstellbare Bereiche, zumindestens bei neueren AVR ist das so. Ändert aber nichts an der Tatsache das er trotzdem das ungenauste ist. Gruß Hagen
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.