Quarzgenauigkeit

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

@ 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

Nur um das aus der Welt zu schaffen:

10 Millisekunden geteilt durch 60 sec ist gleich 1/6 Millisekunde
=166 µs Abweichung pro Sekunde also 166ppm

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

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

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