PLL Gleichung lösen

Gordon N. schrieb:
> a + b/c

Das ist keine Gleichung, und da gibt es auch nichts zu
optimieren da du keine Forderungen bzw Kriterien dafür
aufgestellt hast.

Entweder du schreibst den kompletten Berechnungs-Weg hin
oder nennst gleich den Chip (inklusive Datenblatt) den
du verwenden willst.

fairwirrta schrieb:
> Das ist keine Gleichung, und da gibt es auch nichts zu
> optimieren da du keine Forderungen bzw Kriterien dafür
> aufgestellt hast.

a + b/c = d so jetzt ist es eine Gleichung. Es geht um einen MAX2870.

Jürgen S. schrieb:
> 8. Klasse Mathe aufgepasst: Dort hieß das
> "Partialbruchzerlegung"

Hut ab, wenn ihr das Schon ond er 8. Klasse hattet. Du bist einfach 
Mathemann

Gordon N. schrieb:
> a + b/c = d so jetzt ist es eine Gleichung.

Und auf was bitte soll die optimiert werden?

Gordon N. schrieb:
> Ich möchte folgende Gleichung optimieren: a + b/c

Jürgen S. schrieb:
> Ich weiss es deshalb weil es in der 8. den bundesweiten Mathewettbewerb
> gab und dort eine solche Aufgabe dran kam.

Bundesweiter Mathewettbewerb, merkste selber ne?

Es geht darum das algorithmisch möglichst effizient zu machen. Also 
letztendlich b/c=d lösen unter der Bedingung, dass b und c ganze zahlen 
sind und d positiv reelle Zahl. Schön wenn ihr alle promoviert habt und 
Abitur habt. Ich mit meinem Hauptschulabschluss kann da nicht mithalten.

> und d positiv reelle Zahl

Dazu braucht es keine wesentlich mächtigere reelle Zahl.
Bei Brüchen kommen nur rationale Zahlen heraus.

> algorithmisch möglichst effizient

Vielleicht hat Bresenham da was im Angebot.
Echte zahlentheoretsche Geschütze sind schon unhandlich.

Jürgen S. schrieb:
> Gordon N. schrieb:
> 171 / 47 = 3 + 30/47. Die "3" ist der Ganzzahl, die "30" der
> "Modulowert" für 47. Die muss jetzt mit dem Skalierungsfaktor
> multipliziert werden, z.B. 256 ->
>
> = (3 x 256 + 30 * 256 / 47) / 256
> -> 163 / 256 für die "30".
>
> Deine Teiler sind also 163 und ab und zu 164. Gemäß dem Restverhältnis.
>
> Wie man sieht funktioniert das bei meinem Beispiel nicht, weil es eine
> "irrationale" Zahl ist (Klasse 9).

Das ist sicherlich keine irrationale Zahl.

Gordon N. schrieb:
> Fractional N PLL einzustellen

Wurde bereits hier diskutiert, inkl. Lösungsvorschlag: 
Beitrag "Re: RF Sysnthesizer PLL Optimierung".

Mario H. schrieb:
> Gordon N. schrieb:
>
>> Fractional N PLL einzustellen
>
> Wurde bereits hier diskutiert, inkl. Lösungsvorschlag:
> Beitrag "Re: RF Sysnthesizer PLL Optimierung".

Habe mir deinen code zur Einstellung der PLl angesehen. Sehe da mehrere 
Probleme in dem Algorithmus. Da sind so viele Fälle nicht abgedeckt.

> > Wie man sieht funktioniert das bei meinem Beispiel
> > nicht, weil es eine
> > "irrationale" Zahl ist

Auch durch "Gejitter" aka Dithering kann der Wert
nur angenaehert werden.
Und man muss dafuer nicht unbedingt einen FPGA einspannen.

Im uebrigen wird die Zahl dadurch auch nicht irrational.
Es bleibt die Summe zweier rationaler Zahlen mit einer
gewissen Gewichtung.


> Da sind so viele Fälle nicht abgedeckt.

Dann nur zu! Frisch ans Werk.

Gordon N. schrieb:
> Habe mir deinen code zur Einstellung der PLl angesehen. Sehe da mehrere
> Probleme in dem Algorithmus. Da sind so viele Fälle nicht abgedeckt.

Sicher? Welcher Fall ist denn nicht abgedeckt? Und was sind die Probleme 
mit dem Algorithmus?

Vielleicht sollte ich zur Vermeidung von Missverständnissen und für 
zukünftige Anfragen einmal kurz erklären, was der in 
Beitrag "Re: RF Sysnthesizer PLL Optimierung" 
referenzierte Code macht.

Die Sache ist wirklich sehr einfach: Wenn man eine Dezimalzahl wie z.B. 
1,23456789 in eine gemischte Zahl (d.h. eine ganze Zahl plus einen 
echten Bruch) umwandeln will, muss man den ganzzahligen Teil abtrennen, 
d.h. 1 + 0,23456789, und den echten Dezimalbruch (d.h. mit einer Null 
vorm Komma) mit einer hinreichend großen Zehnerpotenz erweitern, hier 
z.B. 1000000000. Dann erhält man für dieses Beispiel

Im nächsten Schritt kann man dann den Bruch dann in einen irreduziblen 
(d.h. einen vollständig gekürzten) Bruch umwandeln, indem man Zähler und 
Nenner durch den größten gemeinsamen Teiler (greatest commen divisor -- 
gcd) von 234567890 und 1000000000 teilt. Da gcd(234567890, 1000000000) = 
10, erhält man für das Beispiel

Die Zehnerpotenz in diesem Beispiel, also 100000000 = 1e8, hat man 
natürlich geeignet zu wählen. Sie darf für Fraktional-N-PLL-Anwendungen 
nur so groß sein dass sie in das entsprechende Register des 
PLL-Synthesizers passt. Wenn die Zehnerpotenz kleiner ist als die 
Dezimalzahl Stellen hinter dem Komma hat, muss man im Zähler Stellen 
abschneiden, und man bekommt nur eine Näherung. Für z.B. 1e6 anstatt 1e8 
hat man

und es ist gcd(234567, 1000000) = 1, d.h. der Bruch ist bereits 
irreduzibel.

In dem oben referenzierten Code sieht das so aus:

1

double pll_div = (double)f_vco_tgt / ( f_pfd_curr * pre );

2

params.pll_int = floor( pll_div );

3

double  pll_frac = pll_div - params.pll_int;

4

const uint32_t precision = 1000000000;

5

uint32_t gcd_val = gcd( round(pll_frac*precision), precision );

6

7

params.pll_num = round(pll_frac*precision) / gcd_val;

8

params.pll_den = precision / gcd_val;

Dabei ist pll_div der Dezimalbruch, der in eine gemischte Zahl 
umgewandelt werden soll, params.pll_int ist der ganzzahlige Anteil 
(32-bit unsigned integer) und pll_frac der echte Dezimalbruch; precision 
ist die Zehnerpotenz, mit der erweitert wird. Durch das Teilen mit 
gcd_val erreicht man, dass der Bruch, der schließlich in die Register 
des PLL-Chips geschrieben wird, irreduzibel ist, genau wie oben in dem 
einfachen Beispiel.

Man sieht, dass man vermutlich ein wenig Laufzeitoptimierung betreiben 
könnte, indem man round(pll_frac*precision) nicht zweimal ausrechnet, 
sondern beim ersten Mal wegspeichert.

Die Berechnung des gcd ist Standard und folgt dem euklidischen 
Algorithmus:

1

static uint32_t gcd(uint32_t a, uint32_t b)

2

{

3

  uint32_t remainder;

4

  while(b != 0)

5

  {

6

    remainder = a % b;

7

    a = b;

8

    b = remainder;

9

  }

10

  return a;

11

}

Der in dem Projekt verwendete PLL-Baustein hat übrigens für den Nenner 
des fraktionalen Anteils des PLL-Teilers einen Wertebereich von 2^32-1; 
die verwendete precision = 1000000000 ist die größte Zehnerpotenz, die 
dort hinein passt. Man könnte allerdings theoretisch auch einen noch 
größeren Wert nehmen, der keine Zehnerpotenz ist.

Warum die Gymnastik mit dem gcd und dem Kürzen zu einem irreduziblen 
Bruch? Man könnte den Bruch auch ungekürzt lassen, d.h. einfach mit 
precision erweitern und im Zähler eventuell verbleibende 
Nachkommastellen abschneiden. Der verwendete PLL-Baustein hat aber einen 
Delta-Sigma-Modulator, bei dem die führende Integer Boundary Spur bei 
f_PFD/Nenner liegt. D.h. je kleiner der Nenner, desto weiter rückt die 
Störlinie vom Träger weg.

Ich bin mir allerdings bei erneuter Betrachtung nicht sicher, ob es 
überhaupt einen Einfluss auf die Störlinien hat, wenn man den Bruch im 
fraktionalen Anteil erweitert, d.h. ob für die Störlinie nur der Nenner 
des irreduziblen Bruchs zählt. Ausprobiert habe ich das nicht. Es lohnt 
sich eventuell, mal wieder im Lehrbuch unter Delta-Sigma-Modulator 
nachzulesen.

Mario H. schrieb:
> Der verwendete PLL-Baustein hat aber einen Delta-Sigma-Modulator
Worauf bezieht sich diese Aussage? Kann dieser den ungenauen Bruch so 
ändern, dass es im Mittel stimmt? Weil so richtig genau "hin" kriegt man 
es ja auch mit noch so großem Nenner nicht.

> 1,23456789 ~ 1 + 1234567 / 1000000
Ich korrigiere mal kurz:

1,23456789 ~ 1 + 1234568 / 1000000  wegen Rundung

Der Modulator müsste also die hintere 7 gegen die 8 so austauschen, daß 
der richtige Wert herauskommt.

Olf schrieb:
>> Der verwendete PLL-Baustein hat aber einen Delta-Sigma-Modulator
> Worauf bezieht sich diese Aussage?

Auf den LMX2582. Dieser verwendet einen Delta-Sigma-Modulator. Das ist, 
neben dem traditionellen Pulse Swallower, eine weitere Möglichkeit, eine 
Fraktional-N-PLL zu realisieren.

> Kann dieser den ungenauen Bruch so ändern, dass es im Mittel stimmt?

Nein, den "ungenauen Bruch" nicht. Der Bruch, genauer gesagt die ganzen 
Zahlen N, M, D, werden in der Software zu einem gegebenen Dezimalbruch a 
berechnet, so dass a = N + M/D ist, und dann in den PLL-Baustein 
geschrieben. Von den Näherungen, die dabei eventuell gemacht wurden, 
weiß der PLL-Baustein natürlich nichts.

> Weil so richtig genau "hin" kriegt man es ja auch mit noch so
> großem Nenner nicht.

Doch, für endliche Dezimalbrüche schon. Siehe das obige Beispiel

Das Gleichheitszeichen ist ernst gemeint, da ist nichts genähert.

> Ich korrigiere mal kurz 1,23456789 ~ 1 + 1234568 / 1000000
> wegen Rundung

Okay, man kann hier natürlich runden, was sicher auch sinnvoll ist. Der 
oben gepostete Code macht das auch, vermöge der round() Funktion. 
Außerdem müsste es dann

heißen.

> Der Modulator müsste also die hintere 7 gegen die 8 so austauschen, daß
> der richtige Wert herauskommt.

Der Delta-Sigma-Modulator hat mit der Berechnung, wie gesagt, erstmal 
nichts zu tun, das passiert alles im Mikrocontroller. Der Modulator ist 
im PLL-Baustein.

Jürgen S. schrieb:
> Rezy schrieb:
>>> Wie man sieht funktioniert das bei meinem Beispiel nicht, weil es eine
>>> "irrationale" Zahl ist (Klasse 9).
>> Das ist sicherlich keine irrationale Zahl.
> Die Anführungszeichen hast du aber schon gelesen, oder?

Jep. Wenn ich also schreibe: Ich bin "Ingenieur", bin ich eigentlich gar 
kein Ingenieur? Interessant. Wer so prahlt, sollte mit den 
Begrifflichkeiten einfach auch korrekt umgehen.

Gordon N. schrieb:
> Ich möchte folgende Gleichung optimieren: a + b/c
> Dies ist die Ausgangsbasis um die Frequenz einer Fractional N PLL
> einzustellen.

Du schreibst zwar Wirrwarr (das oben ist ein Ausdruck aber keine 
Gleichung), aber ich meine dennoch den eigentlichen Sach-Hintergrund 
darin zu erkennen.

Im Prinzip geht es darum, eine echt gebrochene Zahl (b/c) mit b<c so zu 
finden, daß sie dem gewünschten Verhältnis ausreichend nahe kommt. Egal 
ob nun ein bissel kleiner oder größer. Und zwar ohne daß man dafür viel 
Rechenaufwand im DAP bzw. µC erzeugt. Und was "ausreichend" ist, muß 
noch festgelegt werden.

Also die Frage
"Welche ganzen Zahlen b und c ergeben ein Teilerverhältnis b/c, das 
einem beliebigen Wert x (mit 0 <= x < 1) möglichst nahe kommt.
Randbedingungen:
 b < c
und c < 1024  (beispielsweise)
und wie errechnet man am einfachsten b und c bei Kenntnis von x ?"

Mir kommen da noch andere Randbedingungen in den Sinn, so z.B. wie 
sinnvoll ist es, die Größen von b und c möglichst klein zu halten, wenn 
man zugleich auf den wahrscheinlich auftretenden Jitter des 
Ausgangssignales achtet? Gibt es da ein Optimum, wo sich Ablage und 
Jitter die Waage halten?

Ich hatte das Problem vor einigen Jahren schon mal, als ich einen LO für 
einen kleinen Empfänger (so von 9 kHz bis etwas mehr als 30 MHz) mit 
einem SI5351 konstruiert hatte. Wenn ich mich recht erinnere, dann hatte 
ich damals mit Eingabeln gearbeitet. Aber das war für manuelle 
Abstimmung per Knopf am Gerät. Entsprechend niedrig waren die 
Geschwindigkeits-Anforderungen.

W.S.

W.S. schrieb:
> Mir kommen da noch andere Randbedingungen in den Sinn, so z.B. wie
> sinnvoll ist es, die Größen von b und c möglichst klein zu halten, wenn
> man zugleich auf den wahrscheinlich auftretenden Jitter des
> Ausgangssignales achtet? Gibt es da ein Optimum, wo sich Ablage und
> Jitter die Waage halten?

Bei einer einfachen Fraktional-N-PLL mit Pulse Swallower bzw. einem 
Delta-Sigma-Modulator erster Ordnung kommt es nicht darauf an, welche 
Darstellung des Bruchs man verwendet.

Bei Delta-Sigma mit höherer Ordnung jedoch schon. In den Datenblättern 
von Texas Instrumens (LMX2582 z.B.) sowie in dem Opus Magnum von Dean 
Banerjee (https://www.ti.com/cn/lit/ml/snaa106c/snaa106c.pdf) finden 
sich ein paar Hinweise dazu. Man kann mit größerem Zähler und Nenner 
(bei gleichem Verhältnis natürlich) die Sub-Fractional Spurs positiv 
beeinflussen, was allerdings zu Lasten des Phasenrauschens (bzw. Jitter 
im Zeitbereich) geht.

Da ich möglichst geringes Phasenrauschen erreichen wollte, habe ich den 
in Beitrag "Re: PLL Gleichung lösen" 
gezeigten Code so gestaltet, dass Zähler und Nenner immer relativ prim 
sind (d.h. der Bruch vollständig gekürzt ist).

Ob das auch bewirkt, dass bei einer Delta-Sigma-PLL die Störtöne weiter 
vom Träger weg liegen, was meiner Anwendung auch zupass käme und ich 
eigentlich damit erreichen wollte, ist mir momentan nicht klar. Da 
müsste ich, wie gesagt, die Nase mal etwas in die Bücher stecken. Ich 
finde dazu auf die Schnelle auch keine Hinweise in den Unterlagen von 
TI.

Jürgen S. schrieb:
> Ich würde immer zusehen, dass es gerade Zahl ist, weil sich dadurch ein
> zwangsweise symmetrischer Takt ergibt. Es gibt einen Fall, wo man
> ungerade Verhältnisse benötigt und zwar dann, wenn man eine DDS
> antreiben will, die eine definierte Zielfrequenz hat, die zudem in der
> Nähe von Nyquist liegt. Damit kann man dafür sorgen, dass sich die
> Schwebung, die sich bildet in hohen, besser filterbaren Frequenzen
> abbildet.

Ich bin mir nicht sicher, ob ich verstanden habe, was Du damit meinst. 
Aber für eine PLL-Anwendung sollte es darauf nicht ankommen. Schließlich 
kann man auch nach dem Kürzen des Bruchs einen ungeraden Nenner 
bekommen.

Jürgen S. schrieb:
> Gordon N. schrieb:
>> Es geht darum das algorithmisch möglichst effizient zu machen.
> Wir wissen immer noch nicht welche Zahlen es sind. Dann kann dir auch
> jemand eine Lösung liefern.
Gordon hat sich schon lange verabschiedet, wie es scheint und ich frage 
mich auch, wo hier der Hase im Pfefferliegt?

Und:

Mario H. schrieb:
> Bei einer einfachen Fraktional-N-PLL mit Pulse Swallower bzw. einem
> Delta-Sigma-Modulator erster Ordnung kommt es nicht darauf an, welche
> Darstellung des Bruchs man verwendet.
Es ist grob gesagt egal, wie genau der Nenner zu definieren ist, wenn er 
aufgrund der Wunschtaktverhältnisse nicht als INTEGER darstellbar ist. 
Da hilft das beste Kürzen nicht. Die Frequenz stimmt nicht(?)

Ob und in welcher Weise sich höhere Zahlen positiv auswirken, hängt von 
der PLL ab. Es dürfte bei einem stabilen Takt ziemlich egal sein, ob es 
eine gerade oder ungerade Zahl ist.

Thomas U. schrieb:
> Gordon hat sich schon lange verabschiedet, wie es scheint und ich frage
> mich auch, wo hier der Hase im Pfefferliegt?

Ganz einfach:
Es ist ein generelles Problem, wie man irgendwelche Integerzahlen 
kombiniert, um sowohl einem gewünschten Teilerverhältnis möglichst nahe 
zu kommen, als auch den Rechenaufwand in Grenzen zu halten, als auch 
möglichst Jitter, Spurs usw. klein zu halten.

Das ist eine Rechen- und Optimierungsaufgabe, vor der andere Leute auch 
stehen und die es gründlich zu diskutieren wert ist.

W.S.

W.S. schrieb:
> Das ist eine Rechen- und Optimierungsaufgabe, vor der andere Leute auch
> stehen und die es gründlich zu diskutieren wert ist.

Ja, wobei man meinen sollte, dass das gelöst sein müsste.

Lese ich aber diese links:
Beitrag "Re: PLL Gleichung lösen"
scheint das nicht unbedingt so zu sein.

Diese "spurs" sind ja am Ende immer irgendwie vorhanden. Als nix 
"Verschwindibus". ?