Rekonstruktionsfilter!

[Weide 0]

Hallo Bernhard,

 

tja, wesentlich kürzere Signalwege durch smd's, wesentlich kleinere Brummeinstreuung durch kleinere Oberflächen, in den smd-Op's steckt selbstverständlich derselbe Die, aber es sieht halt nicht so highendig aus, dann klingt's natürlich auch "smd-transparent" ;-)

 

Gruß Weide

 

[Jakob 0]

Hi Bernhard,

 

"so ist es aber bei dem Pass DAC nicht, sondern es ist so

wie von Helge beschrieben: das FSYNC-Signal, das ist die

Referenz für die 2.PLL, wird direkt aus dem SPDIF-Datenstrom

abgeleitet, d.h. die beiden PLLs sind nicht

hintereinandergeschaltet sondern arbeiten unabhängig

voneinander;"

 

Ich kann hier keinen Widerspruch zu Helge erkennen

Das FSYNC-Signal wird aus den Preambeln erzeugt, aber momentan wüßte ich nicht, wie dieses ohne die interne PLL gehen sollte.

Da das FSYNC-Signal für eine weitere PLL benutzt wird, ist diese für mich eine nachgeschaltete zweite PLL.

 

"natürlich wäre eine "sanfte" VCO-Regelung anzustreben, aber

dafür wäre ein Zwischenpuffer notwendig, der den

Dateneingangsstrom von der SPDIF-Schnittstelle gegenüber dem

Datenstrom zum DAC-Baustein entkoppelt. Dieser

Zwischenpuffer fehlt aber bei der Pass-Schaltung. D.h. wenn

die PLL nicht schnell genug nachregelt, kommt es zu

Datenverfälschungen."

 

Ein Puffer kann helfen die Bandbreite der PLL noch geringer zu wählen, aber hier stellt ja die PLL des Receivers bereits sicher, daß der Lock auf den Datenstrom in recht weiten Grenzen funktioniert. Das sanftmütige Verhalten wird über das RC-Filter eingestellt, welches hier etwas merkwürdig gestaltet ist.

 

 

Grüsse

 

[HBt 0]

Hallo ...

 

Was für ein Widerspruch,- zu meinen Äußerungen???

 

Die Preambel ist kein

"BiPhase-Mark-Signal" und kommt vor jedem Subframe!

 

Textauszug, Orginaldatenblatt CS8411/12:

 

FSYNC is directly generated from incoming data stream, its edges are extracted at times when intersymbol interference is at minimum.

This provides a sample frequency clock that is as spectrally pure as the digital audio source clock ...

 

Ist hierzu eine PLL nötig? Und wenn ja oder nein, was dann!?

 

Was ist an dem Schleifenfilter (hier, passives Lag-Filter)merkwürdig?

 

 

Auf gehts

Helge

 

 

 

[Bernhard 0]

Hallo Helge,

 

>>> Ist hierzu eine PLL nötig? Und wenn ja oder nein, was dann!? <<<

 

nein, man braucht zur Erkennung der Preamble ebensowenig eine PLL, wie zur vollständigen Decodierung des SPDIF-Datenstroms; die PLL wird nur zur Generierung des Takts für den D/A-Wandler benötigt. D.h. bei diesem "Direct-Modus" wechselt das FSYNC-Signal seinen Zustand, wenn die Preamble die SPDIF-Schnittstelle erreicht, unabhängig von der PLL.

 

Grüße

 

Bernhard

 

 

 

[Jakob 0]

Hi Helge,

 

"Was für ein Widerspruch,- zu meinen Äußerungen???"

 

Nein, denn "ich kann hier keinen Widerspruch zu Helge erkennen"

 

>Die Preambel ist kein

>"BiPhase-Mark-Signal" und kommt vor jedem Subframe!

 

Die Preambel ist eine bewußte Verletzung der Biphase-Codierung und deswegen detektierbar.

 

"Textauszug, Orginaldatenblatt CS8411/12:

 

FSYNC is directly generated from incoming data stream, its

edges are extracted at times when intersymbol interference

is at minimum.

This provides a sample frequency clock that is as spectrally

pure as the digital audio source clock ...

 

Ist hierzu eine PLL nötig? Und wenn ja oder nein, was dann!? "

 

Mag sein, daß ich mich irre, aber es übersteigt momentan meine Vorstellungskraft, wie der Receiver den Lock auf verschiedene Datenströme zustande bringen soll, ohne die PLL zu aktivieren. Er verfügt doch sonst über keinerlei Takt. Der anschließbare Quarz ist nur optional, wird also grundsätzlich nicht benötigt.

 

"Was ist an dem Schleifenfilter (hier, passives

Lag-Filter)merkwürdig?"

 

Ich kanns auf die Schnelle nicht nachschauen, aber aus der Erinnerung heraus ist für höhere Frequenzen die Filterwirkung auf ein festes Abschwächungsverhältnis begrenzt.

 

 

Grüsse

 

 

[HBt 0]

Hallo Bernhard,

 

"die Frage war rein rhetorisch. Für Jakob." Stimme Deiner Antwort

voll zu, so ist es nämlich.

 

Grüße

Helge

 

[HBt 0]

ohne PLL (und wenn schon, dann ist es halt eine Zweite).

 

Moin Jakob

 

Das, das Schleifenfilter eine konstante Dämpfung (von -15dB)

ab etwa >30Hz besitzt, stellt (weshalb doch gleich) ein/kein

Problem dar?

 

 

Tschüß

Helge

 

Ps.: Wo gibt es den VCO?

 

[Jakob 0]

Hi Helge,

 

>ohne PLL (und wenn schon, dann ist es halt eine Zweite).

 

Ein vorsichtiger Blick in die Datenblätter legt nahe, daß es innerhalb des Receivers nur eine PLL gibt. Ich weiß nicht, wo das Mißverständnis auftrat, deswegen zur Klärung nochmal das, was ich meine:

 

Die PLL muß aktiv sein, damit der Receiver sich überhaupt mit einem einlaufenden Datenstrom synchronisieren kann! Es gibt sonst keinen zur Verfügung stehenden Takt!

 

Wenn die Synchronisierung gelungen ist, kann man aus der Codierungsverletzung das FSYNC-Signal quasi per Gatterhardware gewinnen.

Aber deswegen ist für mich die externe PLL eine nachgeschaltete zweite PLL.

 

Sollte ich mich irren, wäre ich für eine Erklärung des anders ablaufenden Synchronisationsvorganges absolut dankbar

 

"Das, das Schleifenfilter eine konstante Dämpfung (von -15dB)

ab etwa >30Hz besitzt, stellt (weshalb doch gleich) ein/kein

Problem dar?

 

Da man vorab keine Aussage darüber treffen kann, wie hoch der Jitteranteil des Laufwerkes wohl gewesen sein mag, und ohne weitere Messungen auch nicht beurteilen kann, in welchem Frequenzbereich Jitter vorliegt, wäre ein höhere Jitterdämpfung wünschenswert.

 

Grüsse

 

 

[Bernhard 0]

Hallo Jakob,

 

>>> Wenn die Synchronisierung gelungen ist, kann man aus der Codierungsverletzung das FSYNC-Signal quasi per Gatterhardware gewinnen. <<<

 

umgekehrt wird ein Schuh daraus: wenn eine PLL verwendet wird, dann muß diese mit einem Referenztakt versorgt werden und diesen muß man erst aus dem SPDIF Datenstrom gewinnen, und dazu muß man die Preamble auswerten, d.h. man braucht zunächst eine Erkennung der Preamble und kann erst dann einen Referenztakt ableiten und auf diesen Referenztakt synchronisiert sich dann die PLL. Das ist der prinzipielle Ablauf.

 

Es gibt dazu verschiedene Implementierungsvarianten; eine mögliche wäre die folgende:

 

a) Ungefähre Bestimmung der Abtastfrequenz.

Wenn die Abtastfrequenz ungefähr bekannt ist, kann man die Preamble eindeutig (mittels "Gatterhardware") decodieren und davon einen Referenztakt ableiten, der eine PLL speist. Die Preamble unterscheidet sich von allen sonstigen Datenmustern dadurch, daß einzelne Takt-Bits fehlen. Man erkennt dies dadurch, daß für eine gewisse Zeit (abhängig von der Abtastfrequenz) am SPDIF-Eingang kein Zustandswechsel stattfindet, d.h. es gibt eine "Pause".

c) Die PLL synchronisiert nun auf die Preamble und erzeugt einen Hilfstakt, der grob auf den SPDIF-Datenstrom synchronisiert, der aber gerade noch genau genug ist, um Takt-Bits und Daten-Bits des SPDIF-Datenstroms auseinander zu sortieren.

d) Die Takt-Bits aus c) können dazu verwendet werden, um einen weiteren Referenztakt für eine weitere PLL zu erzeugen, die den eigentlichen Mastertakt erzeugt, der hochgenau ist, und mit dem dann Digitalfilter und D/A-Wandler gespeist werden. Wenn man den Mastertakt auf diese Weise erzeugt, hat das den Vorteil, daß die PLL etwaigen Änderungen der Abtastfrequenz sehr gut folgen kann und den Nachteil, daß der so gewonnene Mastertakt nicht ganz frei von dateninduziertem Jitter ist.

 

Deshalb verzichten die neueren Receiver offenbar auf eine PLL die Takt-Bit genau arbeitet, lassen also d) weg und leiten den Mastertakt direkt aus dem Preamble-Takt als Referenz ab (siehe c)); anscheinend funktioniert das in der Praxis auch ausreichend gut und so hat es auch Pass gemacht.

 

Auch wenn in dem Beispiel jetzt eine PLL vorausgesetzt wurde, um Takt- und Daten-Bits zu decodieren, sind auch Schaltungsvarianten denkbar, die gänzlich ohne PLL auskommen.

 

Grüße

 

Bernhard

 

 

 

 

[Jakob 0]

Hi Bernhard,

 

>>>> Wenn die Synchronisierung gelungen ist, kann man aus der Codierungsverletzung das FSYNC-Signal quasi per Gatterhardware gewinnen. <<<

>

>umgekehrt wird ein Schuh daraus: wenn eine PLL verwendet

>wird, dann muß diese mit einem Referenztakt versorgt werden..

 

hatte ich das denn bestritten?

 

>und diesen muß man erst aus dem SPDIF Datenstrom gewinnen,

 

Dankenswerter Weise (deswegen wurde sie u.a. wohl ausgewählt) stellt die Biphasecodierung häufiger Taktflanken zur Verfügung.

 

>und dazu muß man die Preamble auswerten, d.h. man braucht

>zunächst eine Erkennung der Preamble und kann erst dann

>einen Referenztakt ableiten und auf diesen Referenztakt

>synchronisiert sich dann die PLL. Das ist der prinzipielle

>Ablauf.

 

Hier würde ich widersprechen, die Frequenzdetektoren können durch die Taktflanken des S/P-Dif-Datenstroms den VCO in den Lock-bereich der PLL ziehen (ich meine, das wäre auch im Datenblatt so beschrieben);

erst wenn die Synchronisation gelungen ist, gelingt die Erkennung der Frame-Preamble und der Block-Preamble.

 

>Es gibt dazu verschiedene Implementierungsvarianten; eine

>mögliche wäre die folgende:

>

>a) Ungefähre Bestimmung der Abtastfrequenz.

> Wenn die Abtastfrequenz ungefähr bekannt ist, kann man

>die Preamble eindeutig (mittels "Gatterhardware") decodieren

>und davon einen Referenztakt ableiten, der eine PLL speist.

>Die Preamble unterscheidet sich von allen sonstigen

>Datenmustern dadurch, daß einzelne Takt-Bits fehlen. Man

>erkennt dies dadurch, daß für eine gewisse Zeit (abhängig

>von der Abtastfrequenz) am SPDIF-Eingang kein

>Zustandswechsel stattfindet, d.h. es gibt eine "Pause".

 

Diese beiden Möglichkeiten können wir hier wohl ausschließen.

Der Samplingbereich der Receiver liegt zwischen 25 kHz/30 kHz und 50 kHz.

Das man z.B. mit Mikrocontrollern die Abtastrate ermitteln kann, ist klar, aber wir haben hier keine anderen Referenztakte zur Verfügung, sondern müssen auf die interne PLL/VCO-Geschichte vertrauen.

 

>c) Die PLL synchronisiert nun auf die Preamble und erzeugt

>einen Hilfstakt, der grob auf den SPDIF-Datenstrom

>synchronisiert, der aber gerade noch genau genug ist, um

>Takt-Bits und Daten-Bits des SPDIF-Datenstroms auseinander

>zu sortieren.

>d) Die Takt-Bits aus c) können dazu verwendet werden, um

>einen weiteren Referenztakt für eine weitere PLL zu

>erzeugen, die den eigentlichen Mastertakt erzeugt, der

>hochgenau ist, und mit dem dann Digitalfilter und

>D/A-Wandler gespeist werden. Wenn man den Mastertakt auf

>diese Weise erzeugt, hat das den Vorteil, daß die PLL

>etwaigen Änderungen der Abtastfrequenz sehr gut folgen kann

>und den Nachteil, daß der so gewonnene Mastertakt nicht ganz

>frei von dateninduziertem Jitter ist.

>

>Deshalb verzichten die neueren Receiver offenbar auf eine

>PLL die Takt-Bit genau arbeitet, lassen also d) weg und

>leiten den Mastertakt direkt aus dem Preamble-Takt als

>Referenz ab (siehe c)); anscheinend funktioniert das in der

>Praxis auch ausreichend gut und so hat es auch Pass gemacht.

 

Denn die PLL des Receivers stellt hier sicher, daß der LOCK erhalten bleibt (sofern die Grenzen des ICs nicht überschritten werden)

Ansonsten stimme ich natürlich zu, denn schließlich haben wir ja die gleichen Papers gelesen

 

>Auch wenn in dem Beispiel jetzt eine PLL vorausgesetzt

>wurde, um Takt- und Daten-Bits zu decodieren, sind auch

>Schaltungsvarianten denkbar, die gänzlich ohne PLL

>auskommen.

 

Prinzipiell schon, aber eben nicht ohne weitere Referenztaktversorgung.

Das war die eigentliche Grundlage für die Formulierung "nachgeschaltete 2. PLL"

 

Grüsse

 

[Bernhard 0]

Hallo Jakob,

 

>>> Hier würde ich widersprechen, die Frequenzdetektoren können durch die Taktflanken des S/P-Dif-Datenstroms den VCO in den Lock-bereich der PLL ziehen <<<

 

nur, wie soll das geschehen? Wenn man zu einem Zeitpunkt x auf den Datenstrom schaut, ist zunächst nicht erkennbar, welche Flanken des SPDIF-Datenstroms einem Taktbit und welche einem Datenbit zuzurechnen sind; dann gibt es auch noch die Spezialfälle, daß die Datenbits alle Null sind oder alle Eins sind (das ist gar nicht mal so selten). Das SPDIF-Signal ist in beiden Fällen im Datenbereich exakt das gleiche, wenn das Signal mit den Nullen die doppelte Samplingfreqenz besitzt. In solchen Fällen ist die Preamble das einzige Unterscheidungskriterium. D.h. ohne Zuhilfenahme der Preamble wäre in solchen Fällen die Abtastfrequenz nicht bestimmbar.

 

Ich habe keine Ahnung wie der Crystal-Baustein intern implementiert ist, aber wenn von Frequenzdetektoren die Rede ist, könnte auch gemeint sein, daß die Abtastfrequenz anhand der Zeitdauer zwischen zwei Preambles bestimmt wird, denn die Preamble ist anhand ihres charakteristischen Datenmusters immer detektierbar (ein sequentielles Schaltwerk ist dafür allerdings schon erforderlich); das würde aber dann wieder auf meine ursprüngliche Implementierungsidee hinauslaufen.

 

Grüße

 

Bernhard

 

[Jakob 0]

Hi Bernhard,

 

 

"nur, wie soll das geschehen? Wenn man zu einem Zeitpunkt x

auf den Datenstrom schaut, ist zunächst nicht erkennbar,

welche Flanken des SPDIF-Datenstroms einem Taktbit und

welche einem Datenbit zuzurechnen sind; dann gibt es auch

noch die Spezialfälle, daß die Datenbits alle Null sind oder

alle Eins sind (das ist gar nicht mal so selten). Das

SPDIF-Signal ist in beiden Fällen im Datenbereich exakt das

gleiche, wenn das Signal mit den Nullen die doppelte

Samplingfreqenz besitzt. In solchen Fällen ist die Preamble

das einzige Unterscheidungskriterium. D.h. ohne Zuhilfenahme

der Preamble wäre in solchen Fällen die Abtastfrequenz nicht

bestimmbar."

 

Sehe ich auch so, ohne die Preamble geht es nicht, der LOCK-Status basiert konsequenterweise auch auf dem Empfang von Preambles.

 

Nur, ohne ein Synchronisationssignal wüßte ich auch nicht, wie man eine Verletzung der Biphase-Codierung feststellen sollte.

Deswegen ergab sich die Schlußfolgerung, daß die PLL versucht, den richtigen Takt einzustellen, wonach dann auf Dekodierung der Preamble geprüft wird.

Ich weiß auch nicht, wie der Receiver auf die von Dir angesprochenen Spezialfälle reagiert. Könnte sein, daß die Synchronisation tatsächlich länger dauert, da zunächst der falsche Takt produziert wird.

 

"Ich habe keine Ahnung wie der Crystal-Baustein intern

implementiert ist, aber wenn von Frequenzdetektoren die Rede

ist, könnte auch gemeint sein, daß die Abtastfrequenz anhand

der Zeitdauer zwischen zwei Preambles bestimmt wird, denn

die Preamble ist anhand ihres charakteristischen

Datenmusters immer detektierbar (ein sequentielles

Schaltwerk ist dafür allerdings schon erforderlich).."

 

Ist die Preamble denn wirklich, d.h. ohne Vergleichstakt, ohne Synchronisationssignal detektierbar?

 

"..; das

würde aber dann wieder auf meine ursprüngliche

Implementierungsidee hinauslaufen. "

 

Grüsse

 

 

 

[Bernhard 0]

Hallo Jakob,

 

>>> Ist die Preamble denn wirklich, d.h. ohne Vergleichstakt, ohne Synchronisationssignal detektierbar? <<<

 

wohl kaum, irgendeinen "zeitlichen Vergleichsmaßstab" braucht es schon; aber dazu reicht ein unsynchronisierter Takt genügend hoher Frequenz, der auch chipintern ohne äußere Beschaltung bereitgestellt werden kann.

 

Grüße

 

Bernhard

 

 

 

[Jakob 0]

Hi Bernhard,

 

 

>wohl kaum, irgendeinen "zeitlichen Vergleichsmaßstab"

>braucht es schon; aber dazu reicht ein unsynchronisierter

>Takt genügend hoher Frequenz, der auch chipintern ohne

>äußere Beschaltung bereitgestellt werden kann.

 

Wir werden es wohl doch nicht klären können; aus reinen Effizienzerwägungen hätte ich gedacht, wenn doch schon Frequenzvergleicher und PLL "on Chip" , die die Aufgabe erledigen können, warum dann noch weitere Vergleichstakte erzeugen ?!

 

Ansonsten, war mal wieder nett

 

Grüsse

 

[HBt 0]

Ich danke Euch auch, war nett. Falls ich mehr (also Interessantes)

über die Interna der Crystal Receiver erfahre, dann ... etc.

 

Grüße Helge

 

[Bernhard 0]

Hallo,

 

>>> Ich danke Euch auch, war nett. Falls ich mehr (also Interessantes)

über die Interna der Crystal Receiver erfahre, dann ... etc. <<<

 

ich schließe mich Euch an; vielleicht bekommen wir noch etwas heraus.

 

Grüße

 

Bernhard