Effiziente Implementierung von ARCTAN fuer uCs

Wie kommst du an den TAN (also den Einganganswert für den ARCTAN)?

Ja, wenn man x und y kennt ( oder Real- und Imaginärteil), dann geht das 
einfacher:

Beitrag "Goertzel-Algorithmus und Signed Fractional Format"

Cheers
Detlef

CORDIC ist aber doch gerade für die lumpigen Rechner DIE Methode 
schlechthin.

Was wäre, mit reduzierter Auflösung = weniger Rotationen zu agieren? Mit 
4-5 Schritten müsste sich das doch machen lassen.
http://bsvi.ru/uploads/CORDIC--_10EBA/cordic.pdf

Ansonsten heuristisch annähern, anhand der eigenen Anforderungen, sprich 
lokal erlaubten Abweichungen und der benötigten Bereiche, wobei es sehr 
viel knapper kaum gehen wird. Die billigste Lösung ist wohl die von den 
Telekomikern/Iren hier:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.4931&rep=rep1&type=pdf

Weitere Denkanstösse hier:
http://www.convict.lu/Jeunes/Math/arctan.htm

Bei Näherungen muss man nur aufpassen, dass es keine minimalen Knicke 
gibt und die Kurve monoton bleibt! Je nach Verwendungszweck muss sogar 
auch die Ableitung monoton und vor allem stetig sein, daher darf es 
keine Plateaus geben. Da fallen viele auf die Nase!

Mit dem CORDIC wird es eben am schnellsten genau. Natürlich musst Du 
mehrfach auf eine Tabelle zugreifen, aber das müsste man mit einer 
diskreten Abschnittstabelle eben auch. Bei binärem hashing und Bei 512 
Werten mindestens 9x. In der Zeit arbeitest Du auch 3-4 CORDIC 
Iterationen ab.

Klar kann man mit noch weniger Stellen operieren und interpolieren, wenn 
es die Anwendung hergibt, aber man darf eben nicht erwarten, dass man 
mit dem Winkel nochmal irgendwelche Cosinüsse bilden und z.B. Realteil 
errechnen kann zur weiteren Verwendung. Solche simplen Näherungen sind 
i.d.R. finale Operationen für Anzeigen oder für Schätzungen am Besten 
geeignet.

Ansonsten sind das Sonderfälle:

Ich habe mal eine Implementierung in VHDL gemacht, die sehr schnell sein 
müsste und wobei der CORDIC-CORE einfach zu langsam war. Allerdings war 
die Anwendung recht grob und diente nur der Schätzung einer 
Winkelinformation. Ich habe einfach Werte <1.0 per Division gespiegelt, 
um sie in den anderen Ast zu bekommen und den Ausgang der Division, die 
ja als pipeline die bits von oben herunter sukzessive liefert, zur 
Ansteuerung der hash table genutzt. Dann musste Ich nicht "warten" bis 
das Divisionsergebnis komplett feststeht, sondern hat schon nach 2 
Takten die erste Information, in welcher (lokalen) Hälfte der Tabelle 
das Ergebnis liegt. So kann man das auch für Wurzeln machen.

Der Hauptvorteil war, dass man nur sehr geringe Auflösungen und auch 
keine Multiplier für die Rechnung brauchte.

Die Methode ist aber definitiv mal nichts für Microcontroller.

Possetitjel schrieb:

> Beim Algorithmus für ATAN kann ich nicht helfen; trotz
> der i.d.R. beschissenen Erklärungen habe ich die
> sin/cos-Variante verstanden -- wie man aber den ATAN mit
> CORDIC berechnet, ist mir unklar.

Das Prinzip für die ATAN Berechnung mit Cordic muss so sein, denke ich:
Du zerlegst Deinen Winkel in die Komponenten 45°, 22.5°, 11.25°, 5.65°, 
2.8125°, 1.40625°, 0.703125° und 0.3515625°, das sollte reichen für das 
geforderte halbe Grad Auflösung. Dann nimmst Du die komplexe Zahl 1+j*0 
und drehst sie um diese Winkel nach dem Muster hier, hab ich schon mal 
referenziert:

Beitrag "Goertzel-Algorithmus und Signed Fractional Format"

Die Drehungen normierst Du so, dass der Realteil 1 bleibt. Der 
Imaginärteil nach den Drehungen ist der gesuchte Wert.

Wäre ein grosser Spass, das mal so zu versuchen.

Cheers
Detlef

Nochmal nachgedacht, das geht viel einfacher. Du rufst einfach die 
Routine aus
Beitrag "Goertzel-Algorithmus und Signed Fractional Format"
so auf:
IntAtan2(foo,1). Eingangsdynamik sind allerdings 16Bit, weiß nicht, ob 
das dem TO reicht.

Cheers
Detlef

Mein Cordic-artiger Algorithmus für atan2(x,y) wobei der Rückgabewinkel 
von 0=0Grad bis 255=360Grad geht.

1

#include <avr/io.h>

2

#include <avr/pgmspace.h>

3

4

5

// generated by scaling with 65536.0 :: CORDIC1.PAS

6

int32_t iCordicSinTab[5]={25080L,12785L,6424L,3216L,1608L} ;

7

int32_t iCordicCosTab[5]={60547L,64277L,65220L,65457L,65516L} ;

8

9

10

int16_t CordicAmplitude ;

11

12

int16_t GetCordicAmplitude(){

13

  return CordicAmplitude  ;

14

  }

15

16

uint8_t iCordic(int32_t x, int32_t y) {

17

// compute angle and radius of point (x,y)

18

// angle is valid from 0 to 255 (256 would mean 2*Pi )

19

// angle is stored in phi and returned via function

20

// radius is stored in Amplitude and mus be lower than 2^15-1

21

// warning, if x near 2^15 and y near 2^15 than radius is too big !

22

23

  int32_t s,c,x0,y0,x1,y1,tmp ;

24

  uint8_t sign,phi,phi1,phiTest,k_cordic ;

25

26

// first rotate until x0,y0 are in octant 0    

27

// 

28

  x0=x ; y0=y ;

29

  phi=0 ;

30

  if ( y0<0 ) { x0=-x0 ; y0=-y0 ; phi=128 ; }

31

  if ( x0<0 ) { tmp=x0 ; x0=y0 ; y0=-tmp ; phi +=  64 ; }

32

  sign=0 ;

33

  if (y0>x0) { sign=1 ; phi += 64 ; tmp=x0 ; x0=y0 ; y0=tmp ; }

34

  // now x0 >= y0 >=0

35

36

 // warning: this scales amplitude !! so leave out

37

 // while (x0>0x7fff) { x0=x0 >> 1 ; y0=y0 >> 1 ; }

38

 // now rotate in 4 SAR steps with phiTest=16,8,4,2,1

39

 // and check that x0,y0 stays in octant 0

40

41

  phiTest=16 ;

42

  phi1=0 ;

43

  k_cordic=0 ;

44

  while (k_cordic<=4){

45

    // get cosine(phiTest)=c and sine(phiTest)=ss from table

46

    c=iCordicCosTab[k_cordic] ;

47

    s=iCordicSinTab[k_cordic] ;

48

    // rotate (x0,y0) by phi into (x1,y1)

49

    x1=( c*x0+s*y0) / 65536L ;

50

    y1=(-s*x0+c*y0) / 65536L ;

51

    // change x0,y0 if valid rotation step meaning that we stay in octant 0

52

    if (y1>=0) { x0=x1 ; y0=y1 ; phi1 += phiTest; }

53

    phiTest = phiTest >> 1 ;

54

  k_cordic++ ;

55

    }

56

  CordicAmplitude=x0 ;

57

  if (sign) { phi -= phi1 ; } else { phi += phi1 ; }

58

  return phi ;

59

  }

R. Lyons: Understanding Digital Signal Processing

Die arctan Approx. von Lyons steht auf S547, Kap. 13.21

Cheers
Detlef

Hier eine Implementierung von mir, die ich vor längerer Zeit einmal für 
einen at89C2051 (8051 Core) geschrieben habe. Mit dem sdcc Compiler 
benötigte diese Routine 307 Byte und bei 12Mhz Taktfrequenz 1.2ms. 
Interne Rechengenauigkeit sind 16Bit. Die sollte man sich gönnen, auch 
wenn das Ergebnis nur 8Bit betragen soll.

1

const unsigned int tabelle[12] = {8192, 4836, 2555, 1297, 651, 325,

2

163,  81,   41,   20,   10,  5};

3

unsigned char cordic_steps = 8; /* Zahl der Schritte im Cordic-Verfahren,

4

kann während  des Programmablaufs verändert werden.*/

5

unsigned  int cordic_abs;  /* Länge des Vektors nach der letzten Berechnung.*/

6

unsigned int cordic(int x, int y)

7

{

8

  unsigned char i;

9

  int temp = x;

10

  unsigned int angle = 32768;

11

  if (y < 0)

12

  {

13

    x = - y;

14

    y = temp;

15

    angle += 16384;

16

  }

17

  else

18

  {

19

    x      = y;

20

    y      = -temp;

21

    angle -= 16384;

22

  }

23

  for (i = 0; i < cordic_steps; ++i)

24

  {

25

    temp = x;

26

    if (y < 0)

27

      {

28

        x     -= y >> i;

29

        y     += temp >> i;

30

        angle -= tabelle[i];

31

      }

32

    else

33

      {

34

        x      += y >> i;

35

        y      -= temp >> i;

36

        angle  += tabelle[i];

37

      }

38

  }

39

  cordic_abs = x;

40

  return angle;

41

}

Je nachdem was Du machen willst wär vielleicht auch mein hemdsärmeliger 
Vier-Quadranten-Phasenfehler interessant:

https://gist.github.com/prof7bit/e7d2c7ca6eaa0240e13244bacb915d14

Diese äußerst innovative Funktion meinerseits (prior art!) braucht nur 
eine einzige Division und eine Multiplikation, ist zwar nicht ganz 
linear, geht dafür aber über alle 4 Quadranten und reicht locker für so 
Sachen wie ne simple Tan-Lock-Loop, hab ich zuverlässig in ner 
70m-Lichtschranke mit Software PLL am Werkeln bei 160kSamples/s (40kHz) 
auf nem kleinen Cortex M0+.

Wie groß ist denn da der phase error? Den Scale Factor kann ich nicht 
sehen.

Und warum hast Du den error nicht nochmal korrigiert? Der ist doch quasi 
linear und damit abziehbar.

Ich komme nochmals zu meiner Darstellung weiter oben zurück: Näherung 
gut und schön, aber aufpassen mit den Oberwellen. Wenn der ATAN genutzt 
werden soll, um irgendwelche Winkel zurückzurechnen, auf die dann 
geregelt werden soll, dann sind solche langsamen seichten Wellen, wie 
sie in der phase error Funktion drin sind, mitunter tödlich, weil sie 
Schwingungen vorgeben, die nicht drin sind und wenn dann irgendwo im 
System die richtige Frequenz daherkommt, will heißen, ein Anstieg mit 
dU/dt, dann gibt es Resonanzanregung und -verstärkung.

Jürgen S. schrieb:
> Wie groß ist denn da der phase error?

kann man mit PLL_GAIN einstellen, ist proportional zu PLL_GAIN und in 
erster Näherung proportional zum Winkel den der Vektor (q,i) mit der 
q-Achse einschließt. Es ist invariant gegenüber der Amplitude.

> Den Scale Factor kann ich nicht sehen.

Sehen kann man das Ergebnis unten im Plot.

> Und warum hast Du den error nicht nochmal korrigiert? Der ist doch quasi
linear und damit abziehbar.

Was ist da linear und abziehbar? Was meinst Du?

> dann sind solche langsamen seichten Wellen, wie
> sie in der phase error Funktion drin sind, mitunter tödlich, weil sie
> Schwingungen vorgeben, die nicht drin sind und wenn dann irgendwo im
> System die richtige Frequenz daherkommt, will heißen, ein Anstieg mit
> dU/dt, dann gibt es Resonanzanregung und -verstärkung.

Ich sagte ja: "je nachdem was Du machen willst"

Ich selbst benutze das für eine PLL. Eine leichte Nichtlinearität im 
Phasendetektor ist dort vollkommen irrelevant, man kann man die 
Regelschleife problemlos so gutmütig einstellen daß sie nicht zum 
Schwingen neigt. Schau Dir z.B. nur mal die Kennlinien anderer 
gebräuchlicher Phasendetektoren an, manche sind sogar 
amplitudenabhängig. Diese hier nicht!

> mitunter tödlich [...] Schwingungen vorgeben [...] Frequenz daherkommt

Geb mal ein konkretes Beispiel was Du meinst, das Gesagte erscheint mir 
etwas nebulös formuliert, hast Du diese oder eine vergleichbare Funktion 
schon mal in einer Phasenregelschleife eingesetzt? Ich finde keinerlei 
Hinweise in der auffindbaren Literatur daß ein vergleichbares 
Husarenstück jemals versucht wurde, deshalb hat das Ding scheinbar auch 
noch keinen Namen. Die Performance in der Praxis zeigt alle 
Eigenschaften einer "echten" 4Q-Tanlock-Loop.

Der einzige Grund für die Existenz dieses unortodoxen Hacks anstelle 
eines echten 4Q-arctan() ist der geringe Rechenaufwand auch für 
schwachbrüstige CPUs, Ziel der [meiner] Übung war es einen 4Q 
Phasendetektor mit streng monotoner Kennlinie mit dem geringstmöglichen 
Rechenaufwand zu implementieren weil alles andere in dem Fall die zur 
Verfügung stehenden Ressourcen gesprengt hätte, damit ich damit eine 
DPLL bauen kann die noch sparsam nebenher im Interrupt läuft.

Thomas U. schrieb:
> Die Tabelle ist - gerade im kleinen Winkelbereich - zu grob, denke Ich.

Bist du sicher, dass du das Verfahren kennst/verstanden hast? Die 
Auflösung geht bis 0.01% des Vollkreises. Das sollte für eine 
Berechnung, die als Parameter nur mit integer gespeist wird, doch 
reichen.

> Warum keine rekursive Iteration?
Hast du damit eine konkrete Implementierung oder ist das nur so dahin 
geworfen? Das von mir angegebene Verfahren ist an die Leistung eines 
8051 angepasst und verwendet daher nur Addition/Subtraktion und Shift. 
Das ist der Vorteil dieses Verfahrens.

Bernd K. schrieb:
> Jürgen S. schrieb:
>> Wie groß ist denn da der phase error?
> kann man mit PLL_GAIN einstellen,
Das war ja die Frage: Wie groß ist der eingestellt?

>> Den Scale Factor kann ich nicht sehen.
> Sehen kann man das Ergebnis unten im Plot.
Ich sehe da nur einen unskalierten Wert von etwa 2. Was heißt das? 2%?


>> Und warum hast Du den error nicht nochmal korrigiert? Der ist doch quasi
> linear und damit abziehbar.
> Was ist da linear und abziehbar? Was meinst Du?
Wenn der Fehler so verläuft, wie in der roten Kurve, dann ist das so 
ziemlich eine Gerade. Das bedeutet, die Differenz zwischen Falsch und 
Richtig wäre abschnittsweise linear. Damit wäre sie sehr leicht zu 
eliminieren, indem die Näherung noch ein Additiv mit k x X bekommt.


> Geb mal ein konkretes Beispiel was Du meinst, das Gesagte erscheint mir
> etwas nebulös formuliert, hast Du diese oder eine vergleichbare Funktion
> schon mal in einer Phasenregelschleife eingesetzt?
Ja und das Problem ergibt sich sowohl praktisch, als auch theoretisch:

Die Funktion ATAN ist dem Wesen nach monoton, hat also keine lokalen 
Maxima. Baut man in Näherungen keine Knicke, sondern versucht Bögen zu 
bekommen, erhält man mitunter solche Extremstellen. Bei Durchfahren der 
Kennlinie wird dann nicht ein Fehlersignal erster- sondern zweiter 
Ordnung in das System injiziert, welche je nach Dämpfung zu 
Regelschwingungen führt, bzw diese verschärft.

> Ziel der Übung war es einen 4Q
> Phasendetektor mit streng monotoner Kennlinie

Die Fehlerkennlinie scheint dieser Monotonie aber zu widersprechen. ?

Jürgen S. schrieb:
> Bernd K. schrieb:
>> Jürgen S. schrieb:
>>> Wie groß ist denn da der phase error?
>> kann man mit PLL_GAIN einstellen,
> Das war ja die Frage: Wie groß ist der eingestellt?

Den stellst Du genau so ein wie Du ihn brauchst: Groß genug daß das 
Ergebnis genügend Auflösung hat und gerade noch klein genug daß das 
Ergebnis in jedem Falle ohne Überlauf in Deinen Integertypen passt, 14 
Bit sollte reichen, das passt noch gut in nen signed short und hat 
massig genug Auflösung. Das übliche Spielchen halt.

>>> Den Scale Factor kann ich nicht sehen.
>> Sehen kann man das Ergebnis unten im Plot.
> Ich sehe da nur einen unskalierten Wert von etwa 2. Was heißt das? 2%?

1

phase_error ≈ 2 * PLL_GAIN * Phasenwinkel/180°

>>> Und warum hast Du den error nicht nochmal korrigiert? Der ist doch quasi
>> linear und damit abziehbar.
>> Was ist da linear und abziehbar? Was meinst Du?
> Wenn der Fehler so verläuft, wie in der roten Kurve, dann ist das so
> ziemlich eine Gerade. Das bedeutet, die Differenz zwischen Falsch und
> Richtig wäre abschnittsweise linear. Damit wäre sie sehr leicht zu
> eliminieren, indem die Näherung noch ein Additiv mit k x X bekommt.

Schreibs bitte vollständig hin und zeig nen Plot vom Deiner Variante, 
ich kann Deinen Ausführungen ansonsten beim besten Willen nicht nicht 
folgen, sie erscheinen mir unvollständig und scheinen keinen Sinn zu 
ergeben. Gib Dir bitte etwas mehr Mühe.

> Die Funktion ATAN ist dem Wesen nach monoton, hat also keine lokalen
> Maxima. Baut man in Näherungen keine Knicke, sondern versucht Bögen zu
> bekommen, erhält man mitunter solche Extremstellen. Bei Durchfahren der
> Kennlinie wird dann nicht ein Fehlersignal erster- sondern zweiter
> Ordnung in das System injiziert, welche je nach Dämpfung zu
> Regelschwingungen führt, bzw diese verschärft.

Nein.

Wenn die Regelung schwingt stellst Du mit Fingerspitzengefühl die 
Regelkonstanten in geeigneter Weise ein, so lange bis sie dem 
gewünschten Verhalten ausreichend nahe kommt. Fertig.

>> Ziel der Übung war es einen 4Q
>> Phasendetektor mit streng monotoner Kennlinie
>
> Die Fehlerkennlinie scheint dieser Monotonie aber zu widersprechen. ?

sie ist streng monoton steigend und stetig im gesamten 
Definitionsbereich von [-180°, +180°[ wie unschwer am Plot zu erkennen 
ist.

Bernd K. schrieb:
> phase_error ≈ 2  PLL_GAIN  Phasenwinkel/180°

Heiland! Die Formel sehe Ich auch. Die entscheidende Frage ist, wie es 
hier im konkreten Beispiel eingestellt war.

Die Skala für die rote Fehlerkurve hat keine Einheit. Sie geht nur von 0 
.. 2.

Was heisst hier 2?

2 Grad Phasenfehler?  Hoffentlich nicht.
2% Phasenfehler. Hoffentlich nicht.

2 Digit nehme ich an?


Bernd K. schrieb:
> Wenn die Regelung schwingt stellst Du mit Fingerspitzengefühl die
> Regelkonstanten in geeigneter Weise ein, so lange bis sie dem
> gewünschten Verhalten ausreichend nahe kommt. Fertig.
Jaha, das belastet aber die Regelreserve und Stabilität. Es gibt ja noch 
mehr Schwingungen im System, die in die Regelung eingeprägt werden und 
Regelbedarf erzeugen - nicht zuletzt die von Außen und jede 
Nichtlinearität des Systems erzeugt ein zusätzliches Problem und da sind 
die Schwingungen erster und vor allem zweiter Ordnung in vielen Systemen 
ein Punkt.

Eine Näherung mag im Proportional monoton sein, ist es aber schon bei 
der ersten Ableitung nicht mehr.

Jürgen S. schrieb:
> Heiland! Die Formel sehe Ich auch. Die entscheidende Frage ist, wie es
> hier im konkreten Beispiel eingestellt war.

Steht doch alles schwarz auf weiß da, guggst Du: PLL_GAIN=1, hast Du 
eine Sehschwäche oder willst Du trollen? Langsam kommts mir so vor.

> Die Skala für die rote Fehlerkurve hat keine Einheit. Sie geht nur von 0
> .. 2.

Erstens geht sie von -2 bis 2 und zweitens ist die Einheit volkommen 
irrelevant denn die interessiert keinen denn die kann man sich 
einstellen wie man sie braucht, am besten so daß die Integer immer gut 
gefüllt sind, der Wert hat die Dimension eines Winkels und bei der 
Konfiguration im Beispiel wäre die Einheit 1 "Viertelkreis", Also geht 
der Wertebereich von -Halbkreis bis +Halbkreis, oder allgemeiner ist die 
Einheit Kreis/(4*PLL_GAIN) oder meinetwegen auch pi/(2*PLL_GAIN) oder 
90°/PLL_GAIN

> Was heisst hier 2?

Mein Gott, das steht doch da! 2 heißt in dem Fall 180° hinterher, -2 
heißt 180° voraus und 0 heißt "der Zeiger steht so wie er soll" und wäre 
zum Beispiel der Sollwert eines Phasenreglers, der Fehler wäre null. Ich 
hab nen schönen Plot hinmalen lassen hast Du den nicht gesehen?

Was ist jetzt mit Deiner verbesserten Formel wo Du irgendwas von 
irgendwo abziehen willst um es linear zu bekommen, wo kann man sich die 
mal anschauen?

Außerdem will der OP gar keine PLL bauen sondern irgendwas anderes 
machen, also schweifen wir sowieso vom Thema ab.

Bernd K. schrieb:
> Steht doch alles schwarz auf weiß da, guggst Du: PLL_GAIN=1,

Es ging mir nur um die Sicherstellung, dass Ich Deine Grafik richtig 
interpretiere.

Üblicherweise enthalten Diagramme im wissenschaftlichen Bereich eine 
Skalierung der Y-Achse oder einen sonstigen Hinweis, damit man das 
eindeutig ablesen kann und hier konkret ergibt sich nicht zwangsläufig, 
dass Fehler unskaliert dargestellt sind, weil sie in der Regel so klein 
sind, dass man sie 10fach oder 100fach einblenden muss, um den Verlauf 
zu sehen.

Dass sich das aus dem PLL Gain errechnen lässt, konnte Ich nicht 
ersehen, zumal Ich nirgendwo etwas von einem Setting mit "1" erspähen 
konnte.
Momentan kann man gar nichts lesen, weil die Grafik verschwunden ist - 
jedenfalls führt der link auf den Ich mich bezog ins Nichts. Ist das 
wieder weggenommen worden?

Wie auch immer, Ich entnehme Deiner Darstellung dass es skalierbar ist.

Ich hatte mich innerlich etwas gewehrt, die Zahl 2 so zu lesen, dass es 
Digit sind.

Fragen wir daher mal anders herum: Wie weit ließe sich das denn 
verbessern? Erzähle mir jetzt itte aber nicht, dass Ich den PLL-GAIN 
hochstellen muss.

Vielleicht frage Ich deshalb mal gleich direkter, dass Dir das Problem 
etwas deutlicher wird:

Wie genau muss man Deine Lösung machen und wie umfangreich wird sie 
dabei, um an die Qualität der Definition aus den Wiki heranzukommen?

Zu Deiner anderen Frage:

Falls Du meinen Vorschlag der abschnittsweisen Annäherung meinst: Diese 
ist skalierbar, arbeitet also mit eine genügenden Anzahl von Schritten 
und zwar so, dass der lokale Fehler optimiert wird. Ein Fehler von z.B. 
2 Grad benötigt mit der einfachen Interpolation (aus der Erinnerung) so 
etwa 12 Bereiche / Stützstellen und damit 4 Abfragen ("If Then"s)

Falls Du meinen Vorschlag der weiteren Unterteilung der Wiki-Annäherung 
meinst: Man kann (und sollte!) speziell den Übergangsbereich zwischen 
den Formeln um die Werte -0,28 und 0,28 jeweils mit einer Quadratischen 
Kurve überbrücken / glätten. Das macht dann 5 Terme / Bereiche statt 3 
beseitigt aber der Sprung an den Übergängen.

Jürgen S. schrieb:

> Dass sich das aus dem PLL Gain errechnen lässt, konnte Ich nicht
> ersehen,

Das ist doch offensichtlich wenn man sich die Funktion anschaut.

> zumal Ich nirgendwo etwas von einem Setting mit "1" erspähen
> konnte.

Steht da schwarz auf weiß, dick und fett, willst Du mich verschaukeln? 
Sprechen wir überhaupt von der selben Sache? Wieso kritisierst Du etwas 
das Du gar nicht verstanden, bzw überhaupt noch nicht mal gesehen 
geschweige denn gelesen hast?

Lukas schrieb:
> Ich glaube das Missverständnis kommt vom gewählten Namen phase error mit
> welchem hier nicht der tatsächliche Fehler zu atan2 gemeint ist.
Das ist das Problem, daher hatte Ich in meinem Beitrag der ersten 
Nachfrage schon konkret nach dem realen Fehler gefragt.


> Ich hab das mal kurz ausprobiert und komme mit Bernds funktion auf einen
> maximalen Winkelfehler von +- 4°
Ja, soweit lässt sich das grafisch ablesen (+2/-2).

Aber damit ist die Frage immer noch offen:

Was ist der minimale Fehler?

Die Genauigkeit kann man nicht beliebig steigern, auch nicht durch den 
PLL-Gain, weil - wenn man sich die "phase-Funktion" mal anschaut und 
gedanklich nach unten klappt - irgendwann dahin kommt, dass die 
Welligkeit relevant wird und die Monotonie verletzt.

Jürgen S. schrieb:
>> Ich hab das mal kurz ausprobiert und komme mit Bernds funktion auf einen
>> maximalen Winkelfehler von +- 4°
> Ja, soweit lässt sich das grafisch ablesen (+2/-2).

Nein, das ist der Rückgabewert der Funktion. Der Winkelfehler wäre die 
Differenz zwischen diesem und einem echten atan2() wenn man man sie 
beide auf den selben Wertebereich skalieren und vergleichen würde.

ich habe sie damals phase_error() genannt weil das den Zweck beschreibt 
für den ich sie damals eingesetzt habe: Der Zweck war: wie weit und in 
welche Richtung ist das abgetastete Signal phasenverschoben zu einem 
festen Sollwert, also in welche Richtung und wie stark muss ich den 
Oszillator nachführen. Das "wie weit" ist einfach eine Zahl, beliebig 
skaliert, einzige 2 Bedingungen: sie soll 0 erreichen wenn die 
Phasenlage genau dem Soll entspricht und sie soll halbwegs 
proportional zur Abweichung vom Sollwert sein. Skaliert wird der Wert 
per Fingerspitzengefühl so daß sich die Regelschleife nicht daran 
verschluckt und daß das Regelverhalten zufriedenstellend ist, also 
welche absoluten Zahlen dabei herauskommen ist letztendlich vollkommen 
egal, Hauptsache sie passen größenordnungsmäßig zur Verstärkung der 
Regelschlefe so daß man den Regler so justieren kann daß es vernünftig 
funktioniert. Sobald es sich eingeregelt hat hängt es dann eh nur noch 
bei +- null herum.

Ich denke, das Prinzip der Methode ist hinreichend verstanden. Eine 
ähnliche Herangehensweise findet sich z.B. bei analogen Frequenzteilern 
und Suboszillatoren in Synthesizern.

Im Prinzip macht die PLL eigentlich das, was der CORDIC auch tut, er 
berechnet den Wert aufgrund der aktuellen Annahme des Fortschritts und 
"regelt" den Fehler auf Null. Der CORDIC geht den Weg halt zu Ende und 
gibt den finalen Wert erst nach Erreichen des konvergierten Zielwertes 
aus, die PLL gibt permanent einen Wert aus.

Was eben interessant wäre, ist die tatsächliche Abweichung gegenüber 
sich z.B. dynamisch ändernden Eingangswerten. Die PLL entwickelt ja ihr 
Eigenleben bis hin zur Resonanz, wenn dem Eingangsignal ein 
entsprechendes Spektrum überlagert ist.