http://tamtech.wordpress.com/digital/cpld-spdif-da...
Der Programmablaufplan unter design ist doch Datensignmal wieder aus dem
BMC code Herauszuholen oder?
Allerdings verstehe ich nicht wofür die 3/2 Perioden gut seien Sollen.
Die Gibt es doch garnicht.
Was passiert eigentlich wenn die Gleiche Bitfolge wie die Präambel auch
im eigentlichen Datensignal vorkommt? Ist eine Synchronisierung dann
unmöglich sprich worst case?
Das ganze kommt mir sehr "fishy" vor. Mit x-fach Oversampling ist es
zwar kein Problem, die Daten aus dem Biphase-Mark zu dekodieren,
Aufnehmen in den Speicher etc. ist also kein Problem. Allerdings kann
man damit nicht den (Sample)Takt rückgewinnen. Und den braucht man, wenn
man das gleich wieder sauber auf einen DAC ausgeben will.
Und nein, ein FIFO und eine starre, an einen "echten" 44.1*x-Quarz
gebundene Ausgabe reicht auch nicht. Durch die Abweichungen des Quarzes
von der Sendefrequenz gibt es Über/Unterläufe. Damit also
verdoppelte/fehlende Samples, typischerweise alle paar Sekunden. Das
hört man, und dafpr braucht es nichtmal audiophile Ohren.
> Was passiert eigentlich wenn die Gleiche Bitfolge wie die Präambel auch> im eigentlichen Datensignal vorkommt?
Der Sinn der Präambel ist es gerade, dass sie im kodierten BMC-Signal
gar nicht vorkommen kann. Da ist spätestens nach einer Bitperiode ein
Wechsel, die Präambel hat aber immer einen Anteil mit 1.5 Bitperioden.
Georg A. schrieb:> Allerdings kann> man damit nicht den (Sample)Takt rückgewinnen. Und den braucht man, wenn> man das gleich wieder sauber auf einen DAC ausgeben will.
Beziehst Du Dich dabei auf den Umstand, dass der Takt jittert und mit
diesem Jitter ausgegeben werden muss?
Ansonsten kann man es ja auch mit einem FIFO lösen und einen selbst
erzeugten Takt zum abspielen nehmen, einen möglichste genauen dann
natürlich.
> Beziehst Du Dich dabei auf den Umstand, dass der Takt jittert und mit> diesem Jitter ausgegeben werden muss?
Ja, wobei man das in dem Fall schon fast nicht mehr Jitter nennen
kann...
> Ansonsten kann man es ja auch mit einem FIFO lösen und einen selbst> erzeugten Takt zum abspielen nehmen, einen möglichste genauen dann> natürlich.
Nein. Nur "möglichst genau" geht nicht, es muss exakt derselbe wie beim
Sender sein, sonst passiert das oben beschriebene. Und das geht
vernünftig nur mit einer Rekonstruktions-PLL. Alternativ könnte man
anhand der FIFO-Füllstände resamplen, das kostet DSP-Leistung und ist
auch nicht bit-transparent. Sowas will man eigentlich nicht, wenn's mit
einer PLL auch geht.
.
>> Nein. Nur "möglichst genau" geht nicht, es muss exakt derselbe wie beim> Sender sein, sonst passiert das oben beschriebene. Und das geht> vernünftig nur mit einer Rekonstruktions-PLL. Alternativ könnte man> anhand der FIFO-Füllstände resamplen, das kostet DSP-Leistung und ist> auch nicht bit-transparent. Sowas will man eigentlich nicht, wenn's mit> einer PLL auch geht.
Bräuchte man für die PLL nich nochmal ne extra synchronisationspräambel,
damit die Phasenrichtig einrastet?
Nein, die SPDIF-Präambel (bzw. die 3 Varianten) reicht aus, sie ist
eindeutig und phasensicher erkennbar. Sie taucht zwar entweder normal
oder (selten) invertiert auf, trotzdem weiss man dann, wann eine
Bitperiode anfängt.
Das Zeug ist inzwischen >25 Jahre alt, da musste es damals einfach und
sicher gehen ;) So komplexes DSP-Gedöns wie bei Ethernet war da nicht
drin...
Die üblichen SPDIF-Receiver haben eine PLL, die auf dem vierfachen der
Bitperiode einrasten. Dann kann man mit den "ungeraden" Takten die Mitte
der Halbbits absamplen (die "geraden" Samplepunkte fallen auf die
Flanken). Die Folge der Werte ist dann per Statemachine zu dekodieren.
Zuerst die Präambel finden (zB. 11100010), danach ist ein Wertwechsel in
der Bitmitte (also 01 bzw 10) eine 1, ansonsten (00 oder 11) eine 0.
Die PLL selbst weiss nichts von der Phase, die wird nur von den Flanken
synchronisiert. Den Rest macht man in der Decoder-Statemachine anhand
der Präambel.
Wo ist die decoder statmachine in dem dokument, wo ich den link
angeschlossen habe?
Wie ist diese logisch aufgebaut. was bringt eine pll wenn die phase
nicht passt?. kann ich sie auch gleich weglassen, außer ich verstehe
gerade nicht ganz worauf du hinaus willst.. denn wie will diese pll
ünerhaupt einrasten? wenn sich dei phasen ändern..
Wichtig ist ja, dass die Statemachine immer die Zustände in der
Bitzellmitte auswertet. Wie kann man diese auf diese Mitten
Synchroniseren?
> Wo ist die decoder statmachine in dem dokument, wo ich den link> angeschlossen habe?
Ich schau jetzt nicht fremden Code durch, aber sie muss auch drin sein.
Da sie nicht vom Sender synchronisiert ist, muss sie etwas mehr
"messen", wie lange die einzelnen 0/1-Zeiten sind.
> was bringt eine pll wenn die phase nicht passt?.
Von welcher Phase (referenziert zu was?) redest du eigentlich? Ich
glaube, da geht bei dir einiges durcheinander.
> kann ich sie auch gleich weglassen, außer ich verstehe> gerade nicht ganz worauf du hinaus willst..
Ohne PLL hast Sampleauslasser/verdoppler, FIFO hilft nix. Du musst also
eine exakte Kopie des Sendetakts (Wordclock, Bitclock, etc.) aus dem
Geholper des BMC rekonstruieren. Das ist die Vorausetzung für eine
jitterarme Ausgabe der Samples. Jitterarmut braucht man, weil der Jitter
eine Art Frequenzmodulation macht und damit am DAC das SNR deutlich
verschlechtert. Einen Jitter von 1-2ns hört man schon deutlich...
> denn wie will diese pll überhaupt einrasten?
Indem man zB. nur die Flanken (zB. XOR mit um 10ns verzögertem Signal)
als Referenztakt nimmt, und die Trägheit zu niedrigeren Frequenzen
deutlich höher ist als "nach oben".
Lies dir doch mal ein Datenblatt zu einem echten SPDIF-Receiver durch.
Zb. den Oldtimer CS8412, gabs so Anfang der 90er...
Ja aber bei BMC sind die Flanken doch nocht konstannt. Also wie soll die
PLL da einrasten? Und was immernoch unklar ist, ist wie hier die Mitte
der Bitperiode gefunden wird??
Dann ist Statemashine PLL usw. Klar mein einziges Problem ist die
Synchronisation sprich das finden der Taktmitten.. sprich die Negative
Taktflanke. Mit Phasenrichtig meine ich, das das Taktsignal auf der
Senderseite gleich der Auf der empfänger seite ist, sprich die Negative
Taktflanke auch auf empfängerseite in de Mitte einer Bitperiode liegt..
Beim verwandten Manchester Code wird eine Präambel gesendet, wie
beispielsweise 1111111111 Dies wäre dann Auf der Empfängerseite das
Taktsignal, und die PLL könnte einrasten. Und wenn sie das einmal ist,
wird sie entweder verriegelt, oder aufgrund der Trägheit sind keine
phasensprünhe mehr möglich...
> Ja aber bei BMC sind die Flanken doch nocht konstannt. Also wie soll die> PLL da einrasten?
Wie sie es auch bei fractional dividern tut, das wird einfach durch die
Regelträgheit ausgeglichen. Du machst aus allen Übergängen 01 oder 10
eine steigende Flanke für die PLL, die mit der steigenden Flanke des
PLL-Ausgangs verglichen wird. Wenn der Fangbereich der PLL nicht auf die
Hälfte runtergehen kann, rastest sie auf derselben Frequenz ein, egal ob
010101 oder 00110011. Bei anderen Anwendungen ist das gern ein Problem,
hier eher ein Feature...
> Und was immernoch unklar ist, ist wie hier die Mitte> der Bitperiode gefunden wird??
In der PLL gar nicht, das geht nachher. Wenn die PLL auf dem vierfachen
der Bitperiode läuft, kann es an zwei Stellen Wertwechsel geben. Den
kann man einfach finden (vorher!=nachher). Den stabilen Wert kann man
gleich oder (wie unten) einen PLL-Takt später absamplen. Damit bekommt
man immer zwei Bit pro Periode. Welches das erste für das übertragene
Datenbit ist, weiss man da noch nicht. Mit der Preamble kann man sich
dann aber auf die Bitperiode eindeutig synchronisieren.
DATA | X preamble | 0 | 1 |
SPIDF ------------____________----____--------____----_
PLL -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Wechsel ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Sample ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
1 1 1 0 0 0 1 0 1 1 0 1
\---------XPreamble---------/ \ 0 / \ 1 /
Also wenn ich es richtig verstanden habe, gibt es eines der zwei Bits
nicht, das kommtaufgrund der fehlenden Synchronisation.
Sprich der dumme Decoder nimmt die Flanke am Takanfang als Änderung
war..
Erst nach der Preamble, weiß derencoder wo die Bitmitten sind?
Aber woher? Die PLL ist nicht synchroner und der Decoder bis auf die
Info was für ein Signal das istnicht klüger..
Ich bin nicht so ganz sicher, ob Du Dich dem Thema richtig näherst. Das
Thema PLL ist (war!) nötig, um langsame Schaltkreise auf den Datenstrom
"einrasten" lassen zu können. Das macht der Transmitterbaustein von sich
aus. Die Anbindung an den DSP (ich bezihe mich auf das topic) erfolgt
eine Ebene höher. Solche Überlegungen wie hier, sind nur von Nöten, wenn
man das Protokoll manuell dekodieren will, was aber dann mit einem PLD
zu machen sein wird. Wenn Du einen FPGA nimmst, sieht es wieder anders
aus. Man wird ein (ganzzahliges) Vielfaches der Frequenz nehmen und
sampeln.
Was hast Du denn genau vor?
Einen D/A Wandler sozusagen, der die SPDIF Signale eines Apple TV
aufnimmt und an meinen Analogen Verstärker ausgibt.
Dafür will ich die SPDIF Signale Sammeln und auf einen DA Wandler u.
Tiefpass geben.
Ich kann jetzt einfach ein SPDIF Decoder kaufen und den DA Wandler am
Ausgang anschließen, aber ich bastle ungerene ohne vorher genau zu
verstehen, was solch ein Chip genau macht.
Momentan habe ich eigentlich alles verstanden, bis auflas Thema, wie die
Bitmitten gefunden Weden um das (blöde) BMC zu decodieren.. warum
benutzt man überhaupt BMC und nicht beispielsweise Manchester, was
einfacher zu decodieren wäre??
Jan R. schrieb:> Momentan habe ich eigentlich alles verstanden, bis auflas Thema, wie die> Bitmitten gefunden Weden um das (blöde) BMC zu decodieren.
In dem Du eine PLL baust, die sich auf die Flankenwechsel synched.
Was Du auch noch brauchst, ist ein gutes AA-Filter am Ausgang nach dem
DAC und zwar einen richtig guten.
Was Du da bauen willst, geht schon ziemlich ins Detail und ins Geld,
wenn die Qualtität hoch sein soll. Gute Geräte kosten da über 1000,-.
Ich beziehe mich nochmals auf diesen Teil der Diskussion:
Beitrag "Re: SP/DIF Audioübertragung"
Angenommen, ich möchte das in einem PLD machen. Wie kann man sich auf
diese Flanken synchronisieren? Mit einer digitalen PLL wird es immer zu
einem jitternden Takt kommen, da man quasi immer wieder "ausmessen"
muss, wie lange die letzte Flanke dauerte und dann einen Zähler laufen
lassen muss, der die nächste Flankenperiode schätzt und auslöst, auch
wenn diese nicht kommt.
Wie bekommt man so einen Takt dann wieder "glatt"?
PLL nachschalten?