Nach dem Studium diverser Webseiten bin ich mir immer noch nicht 100% im Klaren, was ich damit wie übertragen kann. Laut Wiki werden je Sample jeweils 2 Subframes a 32 bits übertragen und diese in 192er Blocks. Wenn ich die resultierenden 64 Bits (bei Stereo logisch) den üblichen Takten zuordne, erhalte ich die auf enorama angegebenen Datenraten: 32000 Hz -> 2048000 bps 44100 Hz -> 2822400 bps 48000 Hz -> 3072000 bps Siehe: http://www.epanorama.net/documents/audio/spdif.html Nun habe ich 2 Probleme: 1) Wie übertrage ich 96kHz? Sind das dann 96000, 6144000 bps? Das ist nirgends erwähnt. 2) Woher stammt die Sollfrequenz für S/PDIF auf Hamsterworks von 5644800? Ist das falsch, oder was Besonderes? http://hamsterworks.co.nz/mediawiki/index.php/SPDIF_out Habe ich noch Statusinfos innerhalb oder ausserhalb der 192er-Blocks übersehen?
Frank P. schrieb: > Nun habe ich 2 Probleme: > > 1) Wie übertrage ich 96kHz? > Sind das dann 96000, 6144000 bps? Das ist nirgends erwähnt. Ja. Bei 192kHz entsprechend 12,288Mbps. > > 2) Woher stammt die Sollfrequenz für S/PDIF auf Hamsterworks von > 5644800? > Ist das falsch, oder was Besonderes? > http://hamsterworks.co.nz/mediawiki/index.php/SPDIF_out Das liegt an der Manchestercodierung, bei einer '1' findet ein Pegelwechsel statt, eine '0' wird durch einen gleichbleibenden Pegel codiert, zwischen 2 Bits findet immer ein Pegelwechsel statt (ausser bei den Preambles). Der minimale Abstand zwischen 2 Signalflanken beträgt die halbe Bitlänge, daher wohl der um den Faktor 2 höhere Wert der Sollfrequenz.
Stimmt, die auf H.W. gefundene Frequenz ist exaktmdas Doppelte von den 2822400 (44,1kHz). Tomaten auf den Augen gehabt. Ich nehme an, wegen des tooglens der Freuqnz am Ausgang mit 50:50 wird das benötigt. Für die 96kHz und 192kHz brauche ich also entsprechen mehr Frequenz. Fragt sich, wie man die krummen Werte exakt hinbekommt, ohne Spezialquarz.
@ Frank P. (frankyp) >Für die 96kHz und 192kHz brauche ich also entsprechen mehr Frequenz. >Fragt sich, wie man die krummen Werte exakt hinbekommt, ohne >Spezialquarz. Wieso krumm und spezial? 12,288 bzw. das Doppelte 24,576MHz sind Standardquarze im Audiobereich. Gibt es überall.
...und selbst die 22.5792 bekommt man inzwischen deutlich besser als vor 20 Jahren, wo ich mein erstes SPDIF-Interface für den Atari Falcon gebaut habe (mit CS8402 und CS8412). Da musste ich aber auch gleich eine ganze Tüte abnehmen. Liegt immer noch eine ganze Menge rum ;)
Ihr habt schon recht mit den Quarzen, aber ich will nicht noch mehr EIngänge und PLLs, sondern möglichst einen Takt für das Subsystem. Der Rest vom FPGA will ja auch noch arbeiten und braucht PLLs und Takte.
Läuft halt nicht alles so wie du willst ;) 192/96/48 gehen schon mit nur einem Mastertakt für die 192, das lässt sich ja bequem in der Statemachine durch 2/4 teilen. Aber die 44.1 (die Vielfachen davon sind IMO recht unüblich) braucht einen Extraquarz oder mindestens eine rekonfigurierbare PLL. Aus Qualitätsgründen sind zwei externe Quarze für 44.1/48 aber vermutlich am Besten. Ungünstig konfigurierte oder gestörte PLLs können das Audio-SNR durch Jitter deutlich reduzieren.
ok, ich sehe das Problem, wobei ich nur jeweils eine S/PDIF Frequenz für z.B. 96kHz bzw alternativ eine andere, aber nicht gleichzeitig brauche. Die Anforderungen sind hier aber nicht so hoch, dass man nicht etwas ungenau sein und etwas Jitter hinnehmen könnte. Ich möchte halt um zusätzliche Taktdomänen herum kommen und möglichst eine interne PLL nutzen. Wie genau muss denn S/PDIF sein?
Also wenn Du das kommerziell machst, dann solltest Du Dir beim IEC die IEC60958-1 für das physische Interface und die IEC60958-3 für die Kommunikation auf Bitebene kaufen. Alternativ die IEC60958-4 für die commercial/professional audio Übertragungsverfahren. Wenn das eine private Spielerei ist, dann google mal nach den obigen Normen und Du findest z.B. in der IEC60958-1 "7.1.3.2.5 Intrinsic jitter" The peak intrinsic output jitter measured at all the data transition zero crossings shall be less than 0,05 UI when measured with the intrinsic jitter measurement filter. Da steht also bezüglich Signalformen und Abweichungen alles drin, was Du suchst, genauso steht in der -3 drin, welche Bits gesetzt sein müssen, damit die Gegenseite auch 192kHz oder andere Samplerates akzeptiert. Gruß Ulrich
:
Bearbeitet durch User
Also ich hatte irgendwas mit 20ns in Errinnerung, was den Jitter angeht. Das dürfte sich aber auf die 48kHz beziehen. Ich bin aber nicht sicher! Das sollte aber mit einem modernen Baustein eh kein Thema sein. Solange der Takt digital verarbeitet wird und nicht als Zeitbasis z.B. für einen Wandler dient, ist der Jitter ach unkritisch, solange er innerhalb gewisser Grenzenn bleibt. Ansonsten gilt, was Georg sagt, dass der Jitter die Signalqualitität reduziert, wobei es nicht eigentlich SNR ist, sondern eher THDN. Du musst auch erstmal klären, ob Du den Takt vorgeben darfst oder Dich nicht auf einen anderen Takt synchen musst. Wenn Du selber am Dücker bist, kannst die klassischen S/PDIF Frequenzen, bzw. Vielfache davon mit einer 25MHz-PLL erzeugen: 25 MHz x 29 / 59 = 12.881 MHz mit Fehler im Bereich des Quarz / Jitters. Wenn Du auf einen Fremdtakt synchen musst oder es genau brauchst, nimmst du einen externen Quarz, synchst Deinen internen Audiogenerator auf den eingehenden S/PDIF Takt, lässt ihn mit irgendeiner PLL-Konfiguration etwas schneller (also asynchron) laufen und benutzt ein ASYNCH FiFo am Ausgang, das mit dem Fremdtakt (oder eben dem OSC) geleert wird. Das ist signaltechnisch das Beste, weil die PLLs im FPGA so grandios grossartig stabil nicht sind.
Mr. Claudius schrieb: > Ja. Bei 192kHz entsprechend 12,288Mbps. ok, also falls es noch jemanden interessiert: Es gehen physisch sogar 12.5 MHz, wenn man nicht unbedingt die SPEC einhalten will. Die externen Geräte machen da mit, zumindestens einige :-) Danke nochmals an all für Ihre Erklärungen.
Frank Petelka schrieb: > Die externen > Geräte machen da mit, zumindestens einige :-) Ich hatte damals Probleme, S/PDIF ans Laufen zu bekommen. Mit 12,5 MHz (wäre ja auch zu schön) ging es bei meinem Equipment nicht. Daher habe ich mir das krumme Übersetzungsverhältnis für die PLL oben einfallen lassen. Mein erster Synthie lief so. Passt dann auch genau zu den 256 Stimmen (48kHz).
Frank P. schrieb: > ok, also falls es noch jemanden interessiert: Es gehen physisch sogar > 12.5 MHz, wenn man nicht unbedingt die SPEC einhalten will. Da würde mich aber doch nochmal interessieren, wie das funktioniert haben will? Wenn die Frequenz nicht passt, stimmen die ganzen Sampleraten nicht miteinander überein und damit auch nicht etwa die Zeiten oder Frequenzen. Wenn einer damit Audio abspielt, wird alles ein "bizli" daneben sein. Für den Ungeübten mag es angehen, aber Musiker werden da rebellieren, oder?
Wenn es sich um Material dreht, das ursprünglich mit korrekten Frequenten aufgenommen wurde und nun stur abgespielt wird, dann ja, dann ist das ein Problem. Anders ist es, wenn es darum geht, neues Audiomaterial zu generieren: Die zu erzeugenden Frequenzen können auf die Samplefreuenz umgerechnet werden und damit auf jede beliebige Abtastfrequenz angepasst werden.
Rolf S. schrieb: > Wenn die Frequenz nicht passt, stimmen die ganzen > Sampleraten nicht miteinander überein und damit auch nicht etwa die > Zeiten oder Frequenzen. > Wenn einer damit Audio abspielt, wird alles ein "bizli" daneben sein. > Für den Ungeübten mag es angehen, aber Musiker werden da rebellieren, > oder? Ich glaube ehrlich gesagt nicht, dass man DEN geringen Unterschied hören kann. Das sind nicht einmal 2% und es gab Cassetten und Tonbänder, die größere Gleichlaufschwankungen haben und die hat auch keiner gehört.
Denker und Hörer schrieb: > Ich glaube ehrlich gesagt nicht, dass man DEN geringen Unterschied hören > kann. Das sind nicht einmal 2% und es gab Cassetten und Tonbänder, die > größere Gleichlaufschwankungen haben und die hat auch keiner gehört. 6% sind eine Note. Musiker rechnen in cent, das sind 0,6 Promille.
soul e. schrieb: > 6% sind eine Note. Musiker rechnen in cent, das sind 0,6 Promille. So ist es und man kann im AB-Vergleich schon 10% erkennen und die höhere von zwei Tonspuren festlegen.
Habt ihr mal gesehen, wie alt der Tread ist?
Knut B. schrieb: > Habt ihr mal gesehen, wie alt der Tread ist? Ein Zehntel so alt, wie das immer noch aktuelle S/PDIF Protokoll. :-) Und mit Bezug zur Thematik noch dies: Man kann sogar den oben angesprochenen Jitter im S/PDIF Signal hören. Nicht als Frequenzhub, sondern als Unsauberkeit in den Klängen - teilweise als verwaschenes Stereobild, besonders, wenn der hochfrequente primäre Jitter im Signal durch Glättungsmaßnahmen der PLL in untere Bänder geschoben werden. Beitrag "Kriterien zur Charakterisierung der Klangqualität eines Audiosignalverarbeitenden Systems"
:
Bearbeitet durch User
soul e. schrieb: > 6% sind eine Note. Eine HALBE Note. :-) Jürgen S. schrieb: > Man kann sogar den oben angesprochenen Jitter im S/PDIF Signal hören. ... und den Sauerstoff in den Kabeln können auch einige hören, hinzu kommt der Grad der Verdrillung, die Länge des Kabel sowie die Haarfarbe der chinesischen Arbeiterin, die das Kabel gebaut hat. Manche Audioleute hören viel, wenn der Tag lang ist. Mal eine kleine Frage zum Thema: Jürgen S. schrieb: > Die zu erzeugenden Frequenzen können auf > die Samplefreuenz umgerechnet werden und damit auf jede beliebige > Abtastfrequenz angepasst werden. Das würde ich gerne mal wissen, wie das gehen soll, wenn doch die Tonhöhe festliegt und nicht variiert werden kann, bzw kleine Änderungen nicht akzeptabel sind, wegen dem Raushören. Damit liegt doch die Frequenz des Tons ebenfalls fest. Wie und wo soll es da einen Freiheitsgrad geben, um sich auf die Abtastfrequenz anzupassen?
Jürgen S. schrieb: > Das ist signaltechnisch das Beste, weil die PLLs im FPGA so grandios Für einen solchen Fall würde auch keineswegs eine FPGA-PLL empfehlen.
Was mich interessieren würde: Wie prozessiert man das im FPGA so, dass es mit der richtigen Taktfrequenz funktioniert? Es muss ja irgendeine Art von Taktrekonstruktion her. Können das die PLLs in FPGAs?
Audiomann schrieb: > Das würde ich gerne mal wissen, wie das gehen soll Schau mal nach Samplerate-Converter. Gruß Jobst
Thomas W. schrieb: > Was mich interessieren würde: Wie prozessiert man das im FPGA so, dass > es mit der richtigen Taktfrequenz funktioniert? Es muss ja irgendeine > Art von Taktrekonstruktion her. Können das die PLLs in FPGAs? Wenn die Daten nur verarbeitet werden sollen, reicht eine asynchrone Interpretation der Daten. Dann kann man eine Ratenkonversion einsetzen und mit jedem beliebigen Takt arbeiten. Besser und sinnvoller ist aber, sich an den Takt der Quelle drankzuhängen und sich drauf zu synchen. Das geht in FPGAs erfordert aber etwas Trickserei. Man muss den taktgebenden Oszillator ziehen und eine digitale PLL aufziehen. Die verfügbaren Audio-Chips machen das aber direkt mit. Vorzugsweise sollte man die verwenden und sich über z.B. über I2S an den Sampletakt dranhängen.
:
Bearbeitet durch User
Denker und Hörer schrieb: > Rolf S. schrieb: > Ich glaube ehrlich gesagt nicht, dass man DEN geringen Unterschied hören > kann. Das sind nicht einmal 2% und es gab Cassetten und Tonbänder, die > größere Gleichlaufschwankungen haben und die hat auch keiner gehört. Das haben schon manche gedacht und mussten sich überzeugen lassen. Gleichlaufschwankungen sind auch nicht so, daß die Tonhöhe so stark wechselt. Ein guter Recorder liegt unter 1%.
soul e. schrieb: > 6% sind eine Note. Musiker rechnen in cent, das sind 0,6 Promille. Kaum zu fassen! Bei ernst zu nehmender Musik kommt es auf höchste Präzision an. Wie sollen denn Geigen zusammen klingen, wenn sie nicht im Spektrum aufeinander abgestimmt sind? Da sind wenige Promille Abweichung schon entscheidend für Schwebungen und den Akkordklang. Gleichlaufschwankungen oder digitaler Jitter sind da sehr störend. Wenn, müssten alle Kanäle gleich angehoben werden, bzw übertragen werden. Jobst M. schrieb: > Mein Akai GX-95 soll 0,04% haben. Bei einem Japaner tut man sich schwer, an Qualität zu denken, aber die Marke war eine Gute, das kann ich bestätigen. Wie man hört und liest, produzieren die aber jetzt auch in Singapur und konzentrieren sich aufs Digitale.
Andreas F. schrieb: > Bei einem Japaner tut man sich schwer, an Qualität zu denken, Naja, Ende der 80er fand man im Hifi-Bereich ganz oben nur die Japaner. (Nakamichi, Akai, Aiwa, Pioneer, Sony, Teac, Technics, Yamaha, Denon ...) Ein Spitzengerät von Telefunken, Grundig oder Philips war da auf jeden Fall nicht dabei. Aus Europa allerhöchstens Revox oder B&O. Ende der 80er waren die Japaner qualitativ echt gut. Im Automobilbereich sogar so gut, das VW Angst bekam und externe Mitarbeiter und Firmen mit japanischem Wagen nicht auf das Gelände gelassen hat. Mittlerweile bekommt man ja kaum noch japanische Qualität, weil die Japaner, wie alle Anderen auch, in China produzieren lassen. Gruß Jobst
Als Massstab für gute Bandqualität und Gleichlauf würde ich aber nicht unbedingt "HiFi" hernehmen, sondern vielleicht an Firmen wie Studer denken.
Ich hätte eine Frage zum Thema, die auch hier reinspielt: Beitrag "S/PDIF Daten interpretieren" Es werden im Netz zahlreiche Jitterverbesserer angeboten. Hat jemand eine Vorstellung, was da geht und wie die arbeiten? Ich meine, außer einem langen FIFO und einer guten PLL, die es hinten ausliest, kann man wohl kaum was tun, oder? Kennt jemand wissenschaftliche Untersuchungen dazu, ab wann sich Jitte auswirkt?
Thomas W. schrieb: > Es werden im Netz zahlreiche Jitterverbesserer angeboten. Hat jemand > eine Vorstellung, was da geht und wie die arbeiten? > > Ich meine, außer einem langen FIFO und einer guten PLL, die es hinten > ausliest, kann man wohl kaum was tun, oder? Also das Teil von elektor hatte ein FlipFlop und zwei ziehbare Quarze. Das empfangene Halb-Bit wurde zwischengespeichert und dann mit Quarztakt wieder rausgetaktet. So groß wie ein Bit wird der Jitter nicht. Wenn doch, ist was grob faul. > Kennt jemand wissenschaftliche Untersuchungen dazu, ab wann sich Jitte > auswirkt? Ich denke, das ist von Person zu Person und von Musikmaterial zu Musikmaterial unterschiedlich. Wissenschaftliche Untersuchungen sind mir nicht bekannt, mag es aber sicher geben. Evtl. mal selber einen Versuch starten? Bisher hatte ich mit Jitter allerdings nie wirkliche Probleme. Machst Du an Deinem PLD-Projekt weiter? Benutze eine externe PLL! :-) Gruß Jobst
Wie funktioniert das mit den ziehbaren Quarzen? Ja, ich mache gfs weiter.
Angehängte Dateien:
Varicap parallel zum Quarz. Evtl. entfallen dadurch die normalen Lastkondensatoren. Gruß Jobst
Thomas W. schrieb: > Es werden im Netz zahlreiche Jitterverbesserer angeboten. Da würde sich mir zuallererst die Frage stellen wozu? Abgesehen davon, dass meine Quellen sicher nur sehr wenig jittern, mein einziges Ziel für S/PDIF ist für mich mein Surround Verstärker. Und der macht das intern sicher 100x besser als irgendeine externe Bastelschaltung. > Kennt jemand wissenschaftliche Untersuchungen dazu, ... Zu was? So auf die Art der Denon verträgt soviel % Jitter bevor er aussteigt und der Yamaha soviel? Oder willst du ver-jittertes ( :-( ) Signal direkt auf deinen selbstgebastelten DAC und AMP legen? Dann stellt sich die Frage, wie produzierst du eigentlich den vielen Jitter der dir Sorgen macht und sollte man da dann nicht eher an der Quelle ansetzen?
Andi B. schrieb: > Thomas W. schrieb: >> Es werden im Netz zahlreiche Jitterverbesserer angeboten. > > Da würde sich mir zuallererst die Frage stellen wozu? Abgesehen davon, > dass meine Quellen sicher nur sehr wenig jittern, mein einziges Ziel für > S/PDIF ist für mich mein Surround Verstärker. Und der macht das intern > sicher 100x besser als irgendeine externe Bastelschaltung. > >> Kennt jemand wissenschaftliche Untersuchungen dazu, ... > > Zu was? So auf die Art der Denon verträgt soviel % Jitter bevor er > aussteigt und der Yamaha soviel? Oder willst du ver-jittertes ( :-( ) > Signal direkt auf deinen selbstgebastelten DAC und AMP legen? Dann > stellt sich die Frage, wie produzierst du eigentlich den vielen Jitter > der dir Sorgen macht und sollte man da dann nicht eher an der Quelle > ansetzen? Wahrscheinlich sollte man auf jeden Fall optische S/PDIF-Kabel mit vergoldeten Steckern verwenden. Sascha
Andi B. schrieb: > Abgesehen davon, dass meine Quellen sicher nur sehr wenig jittern, Du hast das Problem offensichtlich nicht verstanden. Die Quellen sind es nicht. > mein einziges Ziel für S/PDIF ist für mich mein Surround Verstärker. > Und der macht das intern sicher 100x besser als irgendeine externe > Bastelschaltung. Ich fürchte, dass ich Dich entäuschen muss. Der wird in dieser Richtung sicherlich gar nichts machen. Andi B. schrieb: >> Kennt jemand wissenschaftliche Untersuchungen dazu, ... > > Zu was? So auf die Art der Denon verträgt soviel % Jitter bevor er > aussteigt und der Yamaha soviel? Nein, die Hardware steigt nicht aus. Es klingt nur doof. > stellt sich die Frage, wie produzierst du eigentlich den vielen Jitter > der dir Sorgen macht und sollte man da dann nicht eher an der Quelle > ansetzen? Für jemanden, der überhaupt keine Ahnung hat, hast Du eine verdammt große Klappe. Der Jitter entsteht vor allem in den Leitungen. Vor allem optisch. Es ist mess- und hörbar. Auch ohne Hifi-Voodoo. Gruß Jobst
> Es ist mess- und hörbar. Auch ohne Hifi-Voodoo.
Effektiv produziert der Jitter eine Frequenzmodulation des
DA-gewandelten Signals. Gab dazu mal ein gutes Paper in einem
Crystal/Cirrus-Datenbuch, in dem das genau besprochen wurde. War aber
prä-PDF-Zeiten, im Web findet sich das zumindest nicht auf Anhieb.
Aus meinen SPDIF-Bastelzeiten so gegen '93 rum weiss ich jedenfalls
noch, dass ein PLL-Jitter von ca. 0.5ns (der auf einem HM604 gerade so
erkennbar war) bereits ein deutlich hörbares Zusatzrauschen (also sicher
<-60dB) auf dem DAC-Ausgang produziert hat. Fand ich dann doch
erstaunlich und hat mich genötigt, sich doch mal eingehender mit
Schleifenfiltern zu beschäftigen ;)
Georg A. schrieb: > Effektiv produziert der Jitter eine Frequenzmodulation des > DA-gewandelten Signals. Gab dazu mal ein gutes Paper in einem > Crystal/Cirrus-Datenbuch, in dem das genau besprochen wurde. War aber > prä-PDF-Zeiten, im Web findet sich das zumindest nicht auf Anhieb. http://audioworkshop.org/downloads/AES_EBU_SPDIF_DIGITAL_INTERFACEaes93.pdf
Jobst hat schon recht: Durch den Jitter kann es sowohl zu analogen, als auch digitalen Problemen kommen. Die Geräte haben allesamt irgendeine Art von PLL, die den Takt glättet und damit externen Jitter reduziert und internen induziert. Das genau produziert die falschen Zeitinformationen, die sich dann auf den Wandler übertragen, der gar nichts anders tun kann, als falsch zu wandeln. Je besser (= träger) die PLL ist, desto besser ist die externe Jitterunterdrückung, was sicher jedem einleuchtet. Dummerweise führt eine sehr träge PLL aber dann in der Tat zu einem so großen Offset zwischen dem Takt und dem zu sampelnden Signal, dass Lesefehler auftreten. Sehr ärgerlich ist es, dass auf diese Weise ausgerechnet hochwertiges Studioequipment gerne mal aussteigt, wenn es von Consumersignalen gefüttert wird, während der 99,- Euro Billigrecorder das miese Signal tolerant frisst. Den dreimal höheren Jitter hört der Nutzer nicht. Ein FiFo ist, wie vermutet, dann in der Tat sehr hilfreich, aber nur, wenn er mit dem Eingangstakt gefahren wird, der ja unbekannt ist. Beim S/PDIF z.B. muss dieser Takt erst gebildet werden. Die saubere Lösung ist daher nach meiner Auffassung die, eine schnelle und wenig glättende PLL zu realisieren, die dem Takt gut folgt und die Datenbits sauber und hochtolerant interpretiert. Das kann mit entsprechender Logik und Überabtastung total asynchron erfolgen. In einem zweiten Schritt werden die Daten in das Fifo geschoben, das hinten von einem sehr trägen Takt ausgelesen wird. Über die Pointer im Fifo muss eine Regelung, die den Ausgangstakt ganz weich nachstellt. Leider braucht es da FiFos von wenigstens mal 100ms und mehr, um die Regelung träge genug halten zu können, damit Tonhöhenänderungen im Bereich von wenigen Cent / Sekunden stattfinden und nicht etwa Klangveränderungen erzeugen. Leider sind / waren nicht alle Audiogerätehersteller, die ich so kenne(ngelernt habe) für diese Argumentation empfänglich und bauen mit kleinem Fifo, oder ohne und nehmen das als Takt, was der Dekoderchip als solchen ausgibt. Und es gibt halt den Fall der Echtzeitanwendungen, wo man keine große Verzögerung haben will.
:
Bearbeitet durch User
Hm, wie kann bei einem gleichverteiltem Jitter im Bereich einiger ns eines ansonsten konstanten (Quarz)Takts auch eine langsame PLL langfristig soweit weg von der realen Samplerate sein, dass man zig ms an Buffer braucht? Mag sein, dass das beim Einschwingen der PLL nötig wäre. Aber zum einen kann man den Sync-Zeitraum ignorieren, zum anderen könnte man den Schleifenfilter fast/slow umschalten (wie es diverse RF-Frontend-PLLs auch machen).
Georg A. schrieb: > Hm, wie kann bei einem gleichverteiltem Jitter im Bereich einiger ns > eines ansonsten konstanten (Quarz)Takts auch eine langsame PLL > langfristig soweit weg von der realen Samplerate sein, dass man zig ms > an Buffer braucht? Braucht man auch nicht. Siehe oben die angehängte Schaltung. Man benötigt ein Bit / FlipFlop. Dort macht man einfach:
1 | ___ ________ ___ |
2 | ___// \\________// \\___// |
3 | ____ _________ ____ |
4 | ______| |_________| |____| |
Gruß Jobst
Damit detektierst Du aber nur die Flanken im Signal. Das reicht noch nicht so ganz für den Takt :-) Zu der FiFo-Länge: Es geht nicht nur um den digitalen Jitter auf Taktebene, sondern auch um den Gleichlauf. Wenn man einen Quarz einfach nur laufen lässt, dröhnt der mit SEINER Frequenz und die ist leicht daneben. Daher gibt es in hochwertigen Systemen eine Regelung, die den Takt hinzieht. Ich habe das z.B. für einen Sender realisiert, der sich auf die Atomuhr der PTB synchronisieren kann. Das Signal wird dazu exakt vermessen und der Grundtakt des Quarzes bestimmt und durch Ziehen korrigiert. Alternativ kommt noch eine eventuelle zweite Information aus externen Geräten, die den Sender auf den Systemtakt einstellen wollen. Im Studio ist das der Work clock. Im beiden Fällen gibt es Störungen im Bereich hörbarer Frequenzen, mit denen der Takt driftet. Wenn die PLL im Endgerät jetzt zu schnell folgt, und das tut sie in der Regel, übernimmt sie den Jitter. Also legt man die Grenzfrequenz der Regelung dort auf 5Hz und darunter, lässt die PLL entjittern, selber jittern und zieht sie im Mittel zurecht. Wenn dann das externe Signal ein wenig wegläuft, geht der Empfänger unhörbar mit. "Ein wenig weglaufen" können hier ohne Weiteres 50 ppm Verstimmung und mehr sein, die es beim Audiostart aufzuholen gilt. Massgeblich ist der neue Takt nach z.B. Umschalten in broad cast Einrichtung oder bei digitalen Mikrofonen etc ... Das sind bei z.B. 192kHz S/PDIF >600 Takte in der Sekunde, die man weich nachziehen muss. Je nach Regelung entstehen dann dynamische Differenzen von einigen hundert Takten in beide Richtungen. Das erfordert zunächst ein FIFO von "nur" rund 10 Worten. Wenn aber wie im Fall des unsynchronisierten Betriebes der Jitter verschwinden- und der Datenstrom in die neue Domäne gerechnet werden soll, braucht man zusätzlich den Betrachtungszeitraum der Regelung also 200ms für 5Hz, um den Jitter rückzurechnen und zu interpolieren. Üblicherweise werden aber nur die üblichen 20ms spendiert, die zur Erfassung und Berechnung des Audiosignals an sich erforderlich sind. Beim Radar macht es aber genau so und auch beim Ultraschall verfährt man so, wenn es um die Korrelation der gesendeten Welle und der empfangenen geht. Ist aber jetzt zu Speziell.
Jürgen, schau Dir bitte die Schaltung an. Die funktioniert. Mit einem Flip-Flop. Bau sie auf und wundere Dich. Gruß Jobst
Jobst M. schrieb: >> mein einziges Ziel für S/PDIF ist für mich mein Surround Verstärker. >> Und der macht das intern sicher 100x besser als irgendeine externe >> Bastelschaltung. > > Ich fürchte, dass ich Dich entäuschen muss. Der wird in dieser Richtung > sicherlich gar nichts machen. > .... > Für jemanden, der überhaupt keine Ahnung hat, hast Du eine verdammt > große Klappe. Und das alles weißt du weil du für die namhaften Hersteller die Eingangselektronik entwickelst und die DSPs programmierst? Respekt. Ich wusste gar nicht, dass die dafür den Flip-Flop Jobst brauchen damit er ihnen die Welt erklärt :-)
:
Bearbeitet durch User
Andi B. schrieb: > Und das alles weißt du weil du für die namhaften Hersteller die > Eingangselektronik entwickelst und die DSPs programmierst? Respekt. Ich verrate Dir jetzt mal einen Tipp, bevor Du weiter Deine Unwissenheit zur Schau stellst: Service Manuals. Da kann man reinschauen, wie der Hersteller das gelöst hat. Und der DSP wird meist mit dem fertig aufbereitetem Problem konfrontiert. > Ich > wusste gar nicht, dass die dafür den Flip-Flop Jobst brauchen damit er > ihnen die Welt erklärt :-) Nur kein Neid. Aber die brauchen den nicht. Denn Jitter ist gar nicht deren Problem. Deren Problem ist, wie verkauft man möglichst billigen Kram für viel Geld. Aber kein Problem, dafür gibt es Leute, die fest daran glauben, dass der DSP Jitter beseitigt. Gruß Jobst
Jobst M. schrieb: > schau Dir bitte die Schaltung an. Die funktioniert. Mit einem > Flip-Flop. Bau sie auf und wundere Dich. Worauf beziehst Du Dich hierbei? Auf die komplette oben gelinkte Entjitter-Schaltung aus dem Elektor oder nur auf das FlipFlop? Was genau soll das leisten? Ich hatte die Skizze so verstanden, daß der S/PDIF-Datenstrom mit dem Takt des Empfängers einsynchronisiert wird und damit eine typische Flankenerkennung realisiert wird. Wie sollte der Jitter beseitigen? Man erhält ein mit der halben Rate wechselndes FlipFlop, welches Jitter nur im Rahmen der Dauer der Flankenwechsel reduziert, weil es praktisch aufintegriert, das aber noch keinen 50:50 Takt liefert, mit dem man eine PLL sauber takten könnte. Daran angeschlossen werden müsste eine digitale PLL, die die Bits sampeln kann und sie in ein FIFO schreibt. Das kann komplett aysnchron geschehen. Alternativ braucht es eine einigermassen tolerante PLL mit deren Takt man das bit mittig erwischt. Mit der Bit-Schaltung oben kannst Du zunächst mal nur das bit selbst aus dem MBC extrahieren.
:
Bearbeitet durch User
Jürgen S. schrieb: > Worauf beziehst Du Dich hierbei? Auf die komplette oben gelinkte > Entjitter-Schaltung aus dem Elektor oder nur auf das FlipFlop? Auf die Schaltung von Elektor. > Was genau soll das leisten? Vom Eingangssignal wird in einer recht pfiffigen Schaltung der Takt zurück gewonnen. Dabei wird nur zu jedem 8. Takt auf die Flanke geschaut. Da muss immer eine sein! Sollte die Flanke nicht ungefähr dort sitzen, wird der Quarz nachgeregelt oder im Extremfall auf einen anderen umgeschaltet. Die Quarzfrequenz wird auf 128fs geteilt und zusammen mit den Eingangsdaten auf ein D-FF gegeben, aus welchem die sauberen Bits purzeln. Die 128fs aus dem Quarz treffen mit steigender Flanke immer die Mitte der Bits. Mit Bits meine ich immer die Kanalbits, nicht die Datenbits im Datenstrom. Noch einmal ein Diagramm:
1 | ___ ___ _________ ___ |
2 | (1) \\\___/// \\\_________/// \\\___/// \\\_____ |
3 | _ _________________________________________ ___ |
4 | (2) |_____| |_____| |
5 | _ ___________________________________________ _____ |
6 | (3) |_/// |_/// |
7 | _______________________ ______ |
8 | (4) ____| |_______________________| |
9 | __ __ __ __ __ __ __ __ __ __ |
10 | (5) _| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__ |
11 | _______ _____ ___________ _____ |
12 | (6) |_____| |___________| |_____| |_____ |
1. Eingangssignal (/// = Jitternde Flanken) 2. Fenster, in dem der Frequenzkomperator nach Flanken schaut (Low) 3. Rücksetzen des Frequenzkomperators durch Flankenwechsel im Eingangssignal. 4. Geteilte Quarzfrequenz (16fs) mit welcher (3) im 4046 verglichen wird. Die Regelung ist träge und sowieso nur mit wenig Wirkung, da ein Quarz gezogen wird. 5. 128fs aus dem Quarz an Clock vom D-FlipFlop (IC3b) 6. Eingangssignal nach FlipFlop um einen halben Takt verzögert. Die Daten werden bei positiver Flanke der 128fs übernommen. Gruß Jobst
Das dachte Ich mir :-) Und das ist genau das, was ich angesprochen habe: Das Sampeln des S/PDIF-Daten-Bits, also das "richtig reinkriegen" ist nicht das Problem. De-Jittering braucht zwei Dinge: Toleranz gegen den ankommenden Jitter und die Fähigkeit, einen stabilen Takt auszugeben. Mit nur einer Architektur, die taktmäßig zusammenhängt (und das tut die Elektorschaltung) bildet sich ein Kompromiss: Je träger die PLL, desto besser der Ausgang, aber desto weniger budget gegenüber dem Eingang. Daher sind PLLs oft auch einstellbar (inzwischen auch in FPGAs). Konkret liefert die Elektorschaltung wenn sie jedes 8 Bit aufnimmt, einen digitalen Impuls auf (die Steuerung der) PLL, die dann träge reagiert. Sie darf dabei maximal ein halbes Sample weglaufen, weil sonst ein Aussetzer droht. Konkret sind das z.B. 48kHz x 64 / 8 = 384kHz, die von der PLL tiefpassgefiltert werden. Die daraus resultierenden Frequenzen liegen voll im Audioband. Das ist der Standard, oft anzutreffen und in zahlreichen Geräten realisiert - durchaus auch intelligenter, als im Elektor :-) Mein Vorschlag trennt aber die beide Aspekte, hält also die GF der Schaltung für den Eingang hoch und setzt sie gleichsam für den Ausgang hinab. Diese Konfiguration ist stabiler gegen analoge Schwankungen. - Im Fall der Nutzung einer digitalen PLL am Eingang kann man zudem Aussetzer und sogar physikalische Fehler im Primärsignal überlesen. Dazu muss der Datenstrom entsprechend reinterpretiert werden. Was dann bereits einen längeren Fifo also die erwähnten "ca 10 Samples" (siehe mein Beitrag oben) erfordert. - einen noch größeren FiFo braucht es, wenn man den im Primärsignal enthaltende Jitter beseitigen will, der durch die Aufnahme entstanden ist, der also durch den jitternden Wandler erzeugt wurden und nicht durch die Übertragung kommen. Das sind die erwähnten Anteile im unteren Band 5 Hz abwärts, wobei das natürlich eine Spezialanwendung ist.
Jobst M. schrieb: > Mein Akai GX-95 soll 0,04% haben. > Jobst Ok, dann verschärfe Ich meine Aussage dahingehend, dass die guten Rekorder unter 1Promille Gleichlauf haben. Ich glaube aber, dass bei den Angaben auch getrickst wird, weil der Bezugspunkt ja willkürlich ist. Man könnte die Abweichung ja auf einen größeren Zeitraum beziehen.
Die Angabe soll nach DIN sein. Akai gibt außerdem noch 0,025% WRMS an. Der Nakamichi Dragon hat 0,04% peak und 0,019% rms Das Revox B 77 HS Spulentonbandgerät schafft gerade 0,05% nach DIN. Akai Tonbandgeräte habe ich mit 0,07% nach DIN gefunden. Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Der Nakamichi Dragon hat 0,04% peak und 0,019% rms > Das Revox B 77 HS Spulentonbandgerät schafft gerade 0,05% nach DIN. > Akai Tonbandgeräte habe ich mit 0,07% nach DIN gefunden. Ja, diese Geräte haben teilweise erstaunliche Qualitätswerte, die jene der einfachen Digitaltechnik bequem übertreffen. Vor allem wenn man sich den Jitter bei Soundkarten und AD-Wandlern in Billigdigitalrecordern ansieht. Es gibt heute noch Toningenieure, die mit analogen Bandmaschinen arbeiten.
Eine Frage in die Runde zur Schaltungsphysik: Wenn Ich die Tabelle des TE im Eingangsposting weiterzähle, müssten die derzeit gültigen 192kHz, mit 12,288bps arbeiten. Schon dafür bekommt man kaum einen Übertrager oder einen TOSLINK-Adapter. Wie machen das die Leute, die mit 384kHz arbeiten? Geht symmetrisch über EBU mehr?
Rolf S. schrieb: > müssten die derzeit gültigen 192kHz, mit 12,288bps arbeiten. > > Schon dafür bekommt man kaum einen Übertrager oder einen > TOSLINK-Adapter. ? 12MHz sind für Übertrager lächerlich. Damit kann man bis in den GHz Bereich. Übertrager für SPDIF wickelt man mit wenigen Windungen selbst. Toslinks mit 15Mb/s findet man sowohl bei Sharp, als auch bei Toshiba problemlos. Da hast Du offenbar nicht gut genug gesucht. > Wie machen das die Leute, die mit 384kHz arbeiten? Kompression oder Mono-Mode. Oder welche hochqualitative (also unkomprimierte) 384kHz-Quelle soll das sein? > Geht symmetrisch über EBU mehr? Mit Koax kann man bei korrekter Auslegung und vernünftigem Kabel mit SPDIF genau so schnell wie symetrisch ('EBU'). Gruß Jobst
Für 384kHz wird es optisch aber schon ein bissl eng. Elektrisch geht das aber durchaus. Habe Ich schon gemacht. Geräte gibt es da allerdings keine soweit Ich weiß. Die werden nur zur Abtastung genutzt. Die neue RME macht das z.B. , übertragen aber über MADI. Die Übertrager sind bei hohen Frequenzen erstaunlicherweise zunehmend weniger das Problem, weil man die kapazitiv trimmen oder gleich so auslegen kann. Fertige Übertrager arbeiten auch oft schon mit ihren parasitären Kapazitäten. Das hatten wir heute schon mal irgendwo in einem anderen thread. >Mit Koax kann man bei korrekter Auslegung und vernünftigem Kabel mit >SPDIF genau so schnell wie symetrisch ('EBU'). Aber nicht so weit und nicht so störsicher. EBU ist RS422.
Zum Thema Resampeln: Audiomann schrieb: > Jürgen Schuhmacher schrieb: >> Die zu erzeugenden Frequenzen können auf >> die Samplefreuenz umgerechnet werden und damit auf jede beliebige >> Abtastfrequenz angepasst werden. > Das würde ich gerne mal wissen, wie das gehen soll, wenn doch die > Tonhöhe festliegt und nicht variiert werden kann, bzw kleine Änderungen > nicht akzeptabel sind, wegen dem Raushören. Damit liegt doch die > Frequenz des Tons ebenfalls fest. Wie und wo soll es da einen > Freiheitsgrad geben, um sich auf die Abtastfrequenz anzupassen? Indem man die Klänge generisch erzeugt und sich auf die "falsche" Frequenz anpasst. Gibt eben dann bei der digitalen Aufnahme ein Problem, weil die Aufnahmehardware sich zwar drauf synched, später das Audio aber normal abspielt. In dem Fall wäre es besser, die Audiodaten ungeändert abzuspielen, um sie zwar zu schnell zu überspielen, aber dann richtig im Kasten zu haben. Ich habe das schon so gemacht, 48kHz-Daten als 96kHz zu überspielen und zu bearbeiten. Klappt, wenn man die Zeitbasis der bearbeitenden Prozessoren auch entsprechend ändert, z.B. die Attack-Zeiten von Kompressoren und die Grenzfrequenzen der Equalizer. Hört sich dann real Mickey-Mouse-like an :-) später passt es. Das geht mit jeder krummen Frequenz: Beim Access Virus z.B. gab es mal eine Diskussion zur Abtastrate der Wandler. Die hat keine 44,1 oder 48k, sondern 49kirgendwas. Das Problem war, daraus digitale Daten zu ziehen. Die musst man quasi resampeln. Um das zu umgehen, habe Ich die Daten als 48k Daten reingenommen und unverändert gespeichert. Damit war das abgespielte Stück zu lang und tief. Um das zu kompensieren, dreht man beim Abspielen die Tonhöhe und den Speed etwas hoch.
Jürgen S. schrieb: > Aber nicht so weit und nicht so störsicher. EBU ist RS422. Wie weit möchtest Du? Mit Antennenkabel für Radio- und TV-Installationen schafft man über 1km. Was will man mehr? Gruß Jobst
Jobst M. schrieb: > 12MHz sind für Übertrager lächerlich. Damit kann man bis in den GHz > Bereich. > Übertrager für SPDIF wickelt man mit wenigen Windungen selbst. Muss man nicht mal. Ich habe mit gutem Erfolg Ethernet Übertrager benutzt bei 48kHz Samplerate und der Pegel und die Flanken machten dabei nicht den Eindruck, als würden sie bei 96kHz einbrechen oder verrundet werden. Das ganze habe ich dann auf 10m Koaxkabel R/G-59U geschickt und mit der Terratec Phase 88 PCI empfangen. Null Probleme dabei. Gebuffert wurde das 3,3V S/PDIF Signal aus dem DSP meines Bassverstärkers dabei von 5 parallel geschalteten Gattern des 74HC14 und dann auf den Übertrager geschickt.
:
Bearbeitet durch User
Jürgen S. schrieb: > Um das zu kompensieren, dreht man beim Abspielen die Tonhöhe und den > Speed etwas hoch. Was ist das anderes als Resampeln?
Matthias S. schrieb: > Ethernet Übertrager Stimmt, die habe ich zu diesem Zweck auch schon eingesetzt. Allerdings tatsächlich auch auf Ethernet-Leitungen. (Vorhandene Infrastruktur nutzen). Kleiner Nachteil der Ethernet-Übertrager: Sie haben meist ein Windungsverhältnis von 1:1 oder 1:1,25 oder sowas. Gruß Jobst
Andi B. schrieb: > So auf die Art der Denon verträgt soviel % Jitter bevor er > aussteigt und der Yamaha soviel? Es geht glaube Ich nicht, um das "Vertragen des Jitters" dass er aussteigt oder nicht, sondern daraum, wie er sich dazu verhält. Das Thema gibt es bekanntlich bei jeder digitalen Synchronisation. Langfristig muss sich die Senke auf die Quelle angleichen und dazu wird immer eine PLL aktiv sein müssen, die Schwankungen glättet. Das Spektrum, das sie dabei erzeugt, ist das Wesentliche dabei.
Warum hat es sich eigentlich nicht durchgesetzt, den Bittakt wie z.B. 24,576MHz als Sinus auf Coax von zentraler Stelle aus an alle Geräte zu verteilen? So ähnlich wie die 10 MHz Referenztakt im HF-Labor, da klappt das doch auch gut. Statt dessen wird im Studio Wordclock verteilt. Die ist aber so langsam daß ich wieder eine PLL nehmen muss um da den Bittakt draus zu erzeugen - und die erzeugt gleich wieder Jitter.
Gerd E. schrieb: > daß ich wieder eine PLL nehmen muss um da den Bittakt draus zu erzeugen > - und die erzeugt gleich wieder Jitter. Nein, die Übertragung erzeugt Jitter. Es ist die Frage, wie viel Aufwand (=Kosten) man in die PLL steckt, um den Jitter gering zu halten. Das ist bei einem festen Takt ein kleineres Problem, als bei einem Takt, den man erst aus einem Datenstrom fischen muss. Es gibt PLL-Bausteine, die extra sehr Jitterarm sind. z.B. TI CDCE421 Gruß Jobst
Gerd E. schrieb: > Warum hat es sich eigentlich nicht durchgesetzt, den Bittakt wie z.B. > 24,576MHz als Sinus auf Coax von zentraler Stelle aus an alle Geräte zu > verteilen? Tja, das ist eine gute Frage, es liegt sicher an mehreren Gründen wie Anspruch auf Qualität und Kosten sowie das der Historie: - Die ersten Soundkarten hatten zwar einen digitalen Ausgang, aber keinen Eingang. Die meisten Klangerzeuger der 90er haben ebenfalls einen Ausgang, aber keinen Synch-Eingang. - Die meisten Mikrofone haben bis heute keinen digitalen Ausgang und wenn keinen der sich auf einen Referenz synchen lässt und in den wenigen Applikationen, in denen das geht, braucht es Spezialgeräte. - Digital war lange im Studio als schlecht, kalt und unbrauchbar verpöhnt. Daher gab es da auch wenig Bedarf für digitalen Synch. Im Prinzip wird es so gemacht, wenn sich Digitalpulte und andere Geräte auf das Aufnahmegerät synchronisieren. Das ging schon mit DAT(48kHz) und klappt auch mit normalen Soundkarten. > So ähnlich wie die 10 MHz Referenztakt im HF-Labor, da klappt > das doch auch gut. Der ist aber auch ein Zusatzsignal von dem aus höhere Raten abgeleitet werden müssen und PLLs eingesetzt werden - und dies schon deshalb, um nicht nur Störungen zu stabilisieren sondern vor Allem intern fein einstellbare Delays zu haben, um Laufzeiten zu kompensieren. Aus dem gleichen Grund braucht man oft auch eine PLL im Gerät. Hinzu kommt, dass es mehrere Aufnahmetakte gab, nicht selten kamen Audiowandler mit krummen Frequenzen daher, die erst übersetzt werden mussten und es gibt ja 44,1 und 48,0 Systeme neben 32kHz etc. Eine PLL haben die Geräte also so oder so. > Statt dessen wird im Studio Wordclock verteilt. Die ist aber so langsam Das könnte auch an der Verfügbarkeit von Chips liegen: 25MHz über weite Strecken zu verteilen ist teurer und aufwändiger, als Audiotakte. Mithin müsste man bei einem Vielfachen auch ein Protokoll aufsetzen, welches das Nullbit ist, weil sonst wieder Synchronisation erfolgen muss. Also nimmt man eben gleich den word clock und erhält explizit den Wordtakt auf den sich das Gerät synchen kann und spart sich eine Frequenzberechnung. > daß ich wieder eine PLL nehmen muss um da den Bittakt draus zu erzeugen > - und die erzeugt gleich wieder Jitter. Der ist egal, wenn die PLL im Empfänger sie ausgleicht. Es liegen ja Puffer auf beiden Seiten, die eine entsprechende Toleranz haben. Damit ist es möglich, auch sehr instabile Verbindungen zu betreiben, und die PLL weich zu stellen, sodas sie mitjittern kann und immer schon 1 bit liest, wenn eines geschrieben wird. Hochgenau und gut glättend ist da sogar kontraproduktiv oder man braucht zwei Pfade. Direkte Verbindungen wie oben beschrieben verlieren dagegen schon mal den Takt, d.h. die PLL im Empfänger kommt aus dem Tritt. Einige Endgeräte, z.B. mein SPDIF-Mixer arbeiten daher vollkommen asynchron und Takten alles ein, in der Annahme, daß die Frequenzen stimmen. Dann braucht es eben einen einfach zu interpretierenden Takt. Ich gebe Dir aber prinzipiell Recht und aus genau diesen Erwägungen heraus arbeite Ich ja auch hinsichtlich MIDI mit 25.x MHz. MIDI-Jitter ist noch heute das Problem in vielen Studios. Die Taktrate ist einfach zu gering und erlaubt nur eine grobe automatische Synchronisation. Bei mir rasten die Units exakt aufs Bit 0 im S/PDIF Datenstrom ein und reagieren auf MIDI samplegenau.
Jobst M. schrieb: > Nein, die Übertragung erzeugt Jitter. Aber doch vor allem bei steilflankigen Digitalsignalen, weniger bei einem Sinus. Und bei S/PDIF kommt noch hinzu daß ich da ja Signal und Takt in einem übertrage und hinterher nicht beide optimal wieder rausbekomme. Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel zu verlegen und darüber eine jitterarme Bitclock zu verteilen. Beim Empfänger brauche ich nur einen Komparator um die Clock wieder auf ein Digitalsignal zu bringen und dann ein Flipflop um das S/PDIF-Signal (oder vielleicht besser gar das daraus wieder regenerierte I2S) vom Jitter zu befreien. > Es gibt PLL-Bausteine, die extra sehr Jitterarm sind. z.B. TI CDCE421 Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt sich aber mit der Anforderung von geringer Latenz.
:
Bearbeitet durch User
Gerd E. schrieb: > Aber doch vor allem bei steilflankigen Digitalsignalen, weniger bei > einem Sinus. Wieso sollte eine Leitung einen Sinus anders behandeln? > Und bei S/PDIF kommt noch hinzu daß ich da ja Signal und > Takt in einem übertrage und hinterher nicht beide optimal wieder > rausbekomme. Natürlich bekommt man beides wieder sauber heraus. Man muss sich aber eben Mühe geben. > Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel > zu verlegen und darüber eine jitterarme Bitclock zu verteilen. Naja, Du hast nicht als erster die Idee. Es gibt allerdings auch Leute, die übertragen den Bitclock vom Empfänger zum Sender. > Beim > Empfänger brauche ich nur einen Komparator um die Clock wieder auf ein > Digitalsignal zu bringen ... und dort wieder Jitter zu haben ... > und dann ein Flipflop um das S/PDIF-Signal > (oder vielleicht besser gar das daraus wieder regenerierte I2S) vom > Jitter zu befreien. Dann brauchst Du erstmal wieder ... eine PLL. >> Es gibt PLL-Bausteine, die extra sehr Jitterarm sind. z.B. TI CDCE421 > > Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt > einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt > sich aber mit der Anforderung von geringer Latenz. Ich habe noch nie einen Jitter bei SPDIF gesehen, der länger als ein halbes Bit war. Reicht also, wenn die PLL innerhalb eines Bits 'atmet' Gruß Jobst
Jobst M. schrieb: > Wieso sollte eine Leitung einen Sinus anders behandeln? Ein reiner Sinus hat nur die gewünschte Frequenz. Das scharfflankige Digitalsignal hat jede Menge Oberwellen deutlich darüber. Nicht optimale Terminierung oder Anpassung der Leitung wirken sich da viel stärker aus. >> Und bei S/PDIF kommt noch hinzu daß ich da ja Signal und >> Takt in einem übertrage und hinterher nicht beide optimal wieder >> rausbekomme. > > Natürlich bekommt man beides wieder sauber heraus. Man muss sich aber > eben Mühe geben. So daß man das Signal interpretieren und die Clock in eine PLL werfen kann, ja. Aber direkt damit z.B. einen DAC füttern? >> Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel >> zu verlegen und darüber eine jitterarme Bitclock zu verteilen. > > Naja, Du hast nicht als erster die Idee. Es gibt allerdings auch Leute, > die übertragen den Bitclock vom Empfänger zum Sender. Ich behaupte nicht daß ich der erste bin der auf die Idee kommt. Gab glaube ich mal den Namen "Superclock" dafür. Ist aber definitiv nicht Standard. Ich frage mich jetzt halt warum, denn mir erscheint es sinnvoll. >> Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt >> einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt >> sich aber mit der Anforderung von geringer Latenz. > > Ich habe noch nie einen Jitter bei SPDIF gesehen, der länger als ein > halbes Bit war. Reicht also, wenn die PLL innerhalb eines Bits 'atmet' Dann brauchst Du eine sehr schnell reagierende PLL. Deren Clock willst Du aber nicht auf einen DAC geben, denn dann hörst Du die Sprünge. Du bräuchtest eine langsam regelnde PLL und einen Puffer, der die Zeit ausgleicht in der die PLL langsam auf die Frequenz der Quelle wandert.
Gerd E. schrieb: > Dann brauchst Du eine sehr schnell reagierende PLL. Nein. Die empfangene Frequenz wandert ja nicht wild durch die Gegend, sondern ist im Mittel stabil. Und dort bleibt die PLL und regelt nur langsam dem Mittel hinterher. Das sind dann aber tatsächliche Frequenzänderungen! Das bedeutet natürlich, dass der Lock-Vorgang länger dauert. Und erst wenn das passiert ist, gibt man Audio aus. Gruß Jobst
@Gerd E. (robberknight) >> Wieso sollte eine Leitung einen Sinus anders behandeln? >Ein reiner Sinus hat nur die gewünschte Frequenz. Das scharfflankige >Digitalsignal hat jede Menge Oberwellen deutlich darüber. Nicht optimale >Terminierung oder Anpassung der Leitung wirken sich da viel stärker aus. Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter). >So daß man das Signal interpretieren und die Clock in eine PLL werfen >kann, ja. Aber direkt damit z.B. einen DAC füttern? Davon redet kein Mensch! >> Ich habe noch nie einen Jitter bei SPDIF gesehen, der länger als ein >> halbes Bit war. Reicht also, wenn die PLL innerhalb eines Bits 'atmet' Eben. >Dann brauchst Du eine sehr schnell reagierende PLL. FALSCH!!! Es braucht 2 Dinge. 1. Clock and Data Recovery (CDR), die muss immer schnell sein und muss auch auf ggf. vorhandenen Jitter reagieren. Die schreibt ihre Daten in einen FIFO und liefert den zurückgewonnen, jitterbehafteten Takt (nicht clock!, Scheiß Denglisch!). 2. PLL. Die synchronisiert sich auf den zurückgewonnen, jitterbehafteten Takt und filtert mit einer SEHR geringen Bandbreite (Schleifenfilter) eben diesen, sodaß (hochfrequenter) Jitter entfernt wird. Mit diesem Takt wird das FIFO gelesen und der DAC betrieben.
:
Bearbeitet durch User
Falk B. schrieb: > Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die > ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung > den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter). Naja, eine Störung kann ja durchaus lang genug sein um 10 Taktflanken zu treffen. Das Problem ist einfach der kleine Hub der im Signal steckt. Bei einem steilen dU/dt macht der weniger aus, weil Ich das Eingangsfilter für diesen Takt entsprechend auf HF auslegen kann. Ist im Prinzip wie beim Oszilloskop der HF-Trigger. Damit würde ein Sinus nur schlecht funktionieren. Trotzdem hat Gerd nicht ganz Unrecht, denn: Gerd E. schrieb: > Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel > zu verlegen und darüber eine jitterarme Bitclock zu verteilen. Es ist in der Tat so, dass es einfacher ist, einen jitterarmen Sinus zu produzieren und den zu verteilen, als Rechtecksignale, wenn es nur um einen Takt geht, denn die PLL könnte sich genau auf diese Frequenz konzentieren. Zudem erzeugen steile Signale eben auch andere Probleme, wie Reflektionen, die dann den Takt wieder verbiegen. Die Qualität einer Sinusverbindung ist letztlich höher. Es wäre aber in der Tat dann ein Extratakt. Liefe im Prinzip auf das Synchen auf die DCF77 Atomuhr hinaus: Ganz langsam filtern. Den Aufwand will man halt nicht treiben und vor allem keine Extrakabel. > Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt > einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt > sich aber mit der Anforderung von geringer Latenz. Nicht, wenn man das parallel macht: Falk B. schrieb: > 1. Clock and Data Recovery (CDR), die muss immer schnell sein und muss > 2. PLL. Die synchronisiert sich auf den zurückgewonnen, jitterbehafteten Ja, exakt so. Die Chips machen das, fressen vorne so ziemlich alles und sind bis auf Viertel-Bits genau. Trotz ordentlicher PLL kriegen sie aber den Takt nicht beliebig gut hin, weil S/PDIF eben auch stark niederfrequente Anteile hat, nicht zuletzt weil der Sender oft von mässiger Qualität ist. Aus vielen Geräten, die beides zur Verfügung stellen, bekommt man das gleiche logische Signal über die AES/EBU Buchse erheblich besser angeliefert.
@Jürgen S. (engineer) >> Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die >> ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung >> den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter). >Naja, eine Störung kann ja durchaus lang genug sein um 10 Taktflanken zu >treffen. Kann sein, ändert aber nichts am Grundproblem. >> Daher wäre meine Idee parallel zum S/PDIF-Signal ein weiteres Coax-Kabel >> zu verlegen und darüber eine jitterarme Bitclock zu verteilen. >Es ist in der Tat so, dass es einfacher ist, einen jitterarmen Sinus zu >produzieren und den zu verteilen, als Rechtecksignale, Naja. > wenn es nur um >einen Takt geht, denn die PLL könnte sich genau auf diese Frequenz >konzentieren. Das kann sie auch mit einem Rechtecksignal! >Zudem erzeugen steile Signale eben auch andere Probleme, >wie Reflektionen, die dann den Takt wieder verbiegen. Auch das ist ein lösbares Problem. Die Terminierung von HF-Leitungen ist schon erfunden. > Die Qualität einer Sinusverbindung ist letztlich höher. Jaja, wenn es ein Physiker unter quantenmechanischen Bedingungen betrachtet. Dein Sinus muss aber am Empfänger wieder in ein Rechteck gewandelt werden. > Es wäre aber in der Tat dann ein >Extratakt. Liefe im Prinzip auf das Synchen auf die DCF77 Atomuhr >hinaus: Ganz langsam filtern. Kann man auch mit einer PLL. >Den Aufwand will man halt nicht treiben und vor allem keine Extrakabel. Eben. >> Wie Jürgen schon schrieb, brauchst Du für das Reclocking auf den Takt >> einer langsamen und sauberen PLL etwas Pufferzeit zum "atmen". Das beißt >> sich aber mit der Anforderung von geringer Latenz. >Nicht, wenn man das parallel macht: Man kann nicht alles parallel machen. >Die Chips machen das, fressen vorne so ziemlich alles und sind bis auf >Viertel-Bits genau. Trotz ordentlicher PLL kriegen sie aber den Takt >nicht beliebig gut hin, weil S/PDIF eben auch stark niederfrequente >Anteile hat, Wo kommen die her? Hat nicht jeder S/PDIF Sender einen Quarzoszillator, welcher auch die Sendeendstufe taktet? Klar, man kann auch einen vergurkten Quarzoszillator bauen, der niederfrequent jittert (aka Wander). > nicht zuletzt weil der Sender oft von mässiger Qualität >ist. Aus vielen Geräten, die beides zur Verfügung stellen, bekommt man >das gleiche logische Signal über die AES/EBU Buchse erheblich besser >angeliefert. Wieso? Die Taktquelle ist doch die gleiche?
Falk B. schrieb: >>Ein reiner Sinus hat nur die gewünschte Frequenz. Das scharfflankige >>Digitalsignal hat jede Menge Oberwellen deutlich darüber. Nicht optimale >>Terminierung oder Anpassung der Leitung wirken sich da viel stärker aus. > > Quark. Der kritische Parameter ist die Flankensteilheit. Je größer die > ist, um so kürzer ist die Flanke und damit die Zeit, in der eine Störung > den Schaltzeitpunkt im Empfänger verfälschen kann (== Jitter). Am Empfänger kannst Du bei einem Sinussignal einen steilen Bandpassfilter verwenden, der die Störungen auf anderen Frequenzen sehr deutlich dämpft. Bei einem Rechteck geht das nicht, da kannst Du höchstens einen Hochpass einbauen. Warum verwendet man wohl bei der klassischen 10MHz-Laborreferenz auch Sinus und kein Rechteck? > 2. PLL. Die synchronisiert sich auf den zurückgewonnen, jitterbehafteten > Takt und filtert mit einer SEHR geringen Bandbreite (Schleifenfilter) > eben diesen, sodaß (hochfrequenter) Jitter entfernt wird. Mit diesem > Takt wird das FIFO gelesen und der DAC betrieben. Da hast Du wieder den FIFO der zusätzliche Latenz hinzufügt. Wenn man wirklich rausholen möchte, was mit verfügbaren Komponenten möglich ist, bleibt die Frage womit man weniger Jitter hinbekommt: mit einem Komparator aus dem gut gefilterten Sinus oder mit einer PLL. Und ob man den für die PLL nötigen FIFO mit seiner Latenz akzeptieren kann. Aber warum sich das im Studioumfeld nicht durchgesetzt hat, hat denke ich Jürgen beantwortet: Jürgen S. schrieb: > Den Aufwand will man halt nicht treiben und vor allem keine Extrakabel.
Falk B. schrieb: >>Naja, eine Störung kann ja durchaus lang genug sein um 10 Taktflanken zu >>treffen. > Kann sein, ändert aber nichts am Grundproblem. Das Grundproblem ist nicht, wie viele meinen, dass etwaige Störungen eine Flanke zertören. Das würde eine PLL "überlesen". Das Problem ist, dass durchaus geringe Störungen niederfrequenter Art einen Hub auf das Signal machen und den Schaltzeitpunkt verschieben. Dem geht der PLL hinterher und kann das nicht filtern. >>Es ist in der Tat so, dass es einfacher ist, einen jitterarmen Sinus zu >>produzieren und den zu verteilen, als Rechtecksignale, > Naja. Ja. Ist so. Haben wir bei einem ganz konkreten Projekt im Bereich TDC genauestens untersucht. >> wenn es nur um >>einen Takt geht, denn die PLL könnte sich genau auf diese Frequenz >>konzentieren. > Das kann sie auch mit einem Rechtecksignal! Das ist erstens nicht ganz so trivial und zweitens kommt kein Rechteck an. Das ist das Problem. >>Zudem erzeugen steile Signale eben auch andere Probleme, >>wie Reflektionen, die dann den Takt wieder verbiegen. > Auch das ist ein lösbares Problem. Die Terminierung von HF-Leitungen ist > schon erfunden. Du hast doch sicher Erfahrungen, wie 100% Terminierungen wirken, oder ? :-) >> Es wäre aber in der Tat dann ein >>Extratakt. Liefe im Prinzip auf das Synchen auf die DCF77 Atomuhr >>hinaus: Ganz langsam filtern. > Kann man auch mit einer PLL. Nicht "kann man" sondern "muss man". Es ging darum, ob eine PLL so träge sein kann, dass sie sehr gut filtern kann und trotzdem den Takt nicht an den Daten vorbeiregelt. Und das ist, wie schon erörtert kein Problem, weil Taktrückgewinnung zur Weiterverarbeitung - sowie Einlesen der Daten mit dem lokalen jitternden Takt sich nicht widersprechen. >>Nicht, wenn man das parallel macht: > Man kann nicht alles parallel machen. Mit "parallel" meinte Ich genau den Satz obendrüber, der Deiner Erklärung vom Beitrag weiter oben entspricht: 1. Schnelle PLL zur Interpreation des Bits 2. Langsame PLL zur Erzeugung eines internen Taktes >>Die Chips machen das, fressen vorne so ziemlich alles und sind bis auf >>Viertel-Bits genau. Trotz ordentlicher PLL kriegen sie aber den Takt >>nicht beliebig gut hin, weil S/PDIF eben auch stark niederfrequente >>Anteile hat, > > Wo kommen die her? Hat nicht jeder S/PDIF Sender einen Quarzoszillator, Von 1. der Quelle und 2. der Leitung. Sicher hat jeder seinen Taktgenerator, aber auch der ist a) nicht 100% stabil und muss sich gfs ... b) auf einen externen Takt synchen, hoppelt also um eine Vorgabe herum. >> Aus vielen Geräten, die beides zur Verfügung stellen, bekommt man >>das gleiche logische Signal über die AES/EBU Buchse erheblich besser >>angeliefert. > Wieso? Die Taktquelle ist doch die gleiche? Ja, aber die Leitungsqualtität ist bei symmetrischer Signalführung eben besser, es kommt also weniger zusätzlicher Jitter rein. Die gesamte Frage ist also weniger, OB es geht, sondern immer WIE GUT es geht. Und bei S/PDIF kann man den Jitter bei schlechten Geräten und Verbindungen durchaus hören. Das bestreiten manche, ist aber so.
Ah, da war jemand schneller: Gerd E. schrieb: > Warum verwendet man wohl bei der klassischen 10MHz-Laborreferenz auch > Sinus und kein Rechteck? Wie oben schon festgestellt, weil die Filterung mit weniger Aufwand zu erledigen - und ein besseres Ergebnis zu erzielen ist. Das geht vor allem auch Analog noch sehr gut. Natürlich kann man das auch digital machen und da ist der Aufwand hin zu einer Rechteckprozessierung nicht viel höher - aber es gibt auf Leitungen eben kein Rechteck. Man muss also immer irgend eine Annahme über die Anstiegszeit machen. Das macht es dann letztlich nicht besser. > Da hast Du wieder den FIFO der zusätzliche Latenz hinzufügt. Den braucht man aber, weil der das Problem löst. Praktisch sind das aber nur ein paar Bits, weil die tieffrequenten Gleichlaufschwankungen, die sich durch Jitter ergeben, im Bereich von Promille bleiben. Und ein paar bits sind bei digitalen Audio im Grunde Null, weil erst 64 ein volles Stereosample ergeben. Der Fifo ist kein Problem. Digitale Audiogeräte haben Latenzen im Bereich von etlichen Samples, selbst wenn sie ein Signal nur durchreichen. > Wenn man wirklich rausholen möchte, was mit verfügbaren Komponenten > möglich ist, bleibt die Frage womit man weniger Jitter hinbekommt: mit > einem Komparator aus dem gut gefilterten Sinus oder mit einer PLL. Bei den Meisten liegt kein ausreichendes Detailverständnis vor, daher nutzen viele im Studio nicht mal word clock.
:
Bearbeitet durch User
@Gerd E. (robberknight) >Am Empfänger kannst Du bei einem Sinussignal einen steilen >Bandpassfilter verwenden, der die Störungen auf anderen Frequenzen sehr >deutlich dämpft. Bei einem Rechteck geht das nicht, da kannst Du >höchstens einen Hochpass einbauen. OK. >> eben diesen, sodaß (hochfrequenter) Jitter entfernt wird. Mit diesem >> Takt wird das FIFO gelesen und der DAC betrieben. >Da hast Du wieder den FIFO der zusätzliche Latenz hinzufügt. Wir reden hier über wenige Bits, also unterhalb einer Samplezeit!
Vielleicht noch ein Nachtrag zum Eingangspost: Auch wenn es nicht ganz offiziell ist, inzwischen wird S/PDIF mit 384kHz (25 MHz) rausgeblasen, boardintern auf meiner Platine sogar mit 768kHz -> 50MHz. Das Problem ist, es über längere Strecken zu übertragen. Gelungen ist das bisher nur mit einem Coax über knapp 1m. Optisch gibt es da keine Treiber für, zumindest nicht im klassischen TOSLINK-Glasfaserstandard.
@Jürgen S. (engineer) >offiziell ist, inzwischen wird S/PDIF mit 384kHz (25 MHz) rausgeblasen, >boardintern auf meiner Platine sogar mit 768kHz -> 50MHz. Muss man es immer übertreiben? Höher, schneller, weiter? Wo bleibt die Cleverness? >Das Problem ist, es über längere Strecken zu übertragen. Gelungen ist >das bisher nur mit einem Coax über knapp 1m. Optisch gibt es da keine >Treiber für, zumindest nicht im klassischen TOSLINK-Glasfaserstandard. TOSLINK hat keine GLASfaser, bestenfalls Lichtwellenleiter aus Plastik, aka POF (plastic optical fibre). ;-)
Falk B. schrieb: > Muss man es immer übertreiben? Höher, schneller, weiter? Was die Bandbreite angeht, kann es eigentlich nicht hoch genug sein, weil man ja auch die Zahl der Kanäle erhöhen kann. ADAT z.B. überträgt über ein optisches Kabel standardmäßig 8x48kHz oder 4x96 und was den Einwurf von MIDI über S/PDIF angeht, sind auch da mehr Kanäle möglich, z.B. mehrere Dutzende Tastenänderungen (Orchester-Arrangement) mitsamt Parametern deutlich unter 1ms, also praktisch gleichzeitig, während mit normalem MIDI gerade 1 Note+Paramter übertragen wird. > Wo bleibt die Cleverness? In meinem Fall ist das Hochtreiben auch ein wenig der Historie geschuldet. Ich habe damals mit S/PDIF angefangen, Audio-Module zu verschalten und das der Einfachheit immer beibehalten. Würde Ich es heute nochmal neu ansetzen, würde Ich gfs was anderes nehmen. Zumindest in Richtung PC geht mit USB2.0 mehr, allerdings mit mehr Latenz: Das S/PDIF ist auf den ersten Blick ein etwas unnötig kompliziertes Protokoll, bringt aber nach 1/64 der Taktfrequenz das erste Doppeldatum in die Senke. Gerade bei den hohen Taktfrequenzen ist das serielle Protokoll sogar ein Vorteil. > TOSLINK hat keine GLASfaser, bestenfalls Lichtwellenleiter aus Plastik, > aka POF (plastic optical fibre). ;-) Das ist richtig, allerdings gibt es (oder gab es) im Profibereich auch Glasfaserübertragung für MIDI und Audio, wenn es um Distanzen geht. Die Plastikoptik, wenn man sie so nennen darf, ist auch in der Tat nicht so 100% betriebsstabil.
Jürgen S. schrieb: > inzwischen wird S/PDIF mit 384kHz (25 MHz) rausgeblasen, > boardintern auf meiner Platine sogar mit 768kHz -> 50MHz. > > Das Problem ist, es über längere Strecken zu übertragen. Gelungen ist > das bisher nur mit einem Coax über knapp 1m. 1m ist ja jetzt nicht mal eine "kürzere Strecke", das reicht nicht mal von ganz unten im Rack bis oben. Ein eindeutiges Zeichen daß das Protokoll dafür nicht mehr passt. Auf Kupferbasis müsste man wohl einen anderen Leitungscodec verwenden, so ähnlich wie bei Ethernet. > Optisch gibt es da keine > Treiber für, zumindest nicht im klassischen TOSLINK-Glasfaserstandard. Bei den Geschwindigkeiten kannst Du PoF dann auch vergessen. Unter Preis/Verfügbarkeitsgesichtspunkten würde es vermutlich Sinn machen SFP-Slots zu verwenden, wie sie an Ethernet-Switchen gängig sind. Da bekommt man z.B. für 20-30 EUR ein SX-Modul. Damit kann man dann 1 GBit/s auf Multimode-Glasfaser übertragen, es sind Strecken bis 500m möglich. Für kürzere Strecken (und hier meine ich hier bis vielleicht 50m) gibt es fertige Patchkabel mit LC-Buchsen für wenige Euro. Wenn man mehr braucht, steckt man halt in den selben Slot ein LX-Modul rein und kommt dann mit Monomode-Fasern bis 10km weit.
Moin, Gerd E. schrieb: > Ein eindeutiges Zeichen daß das > Protokoll dafür nicht mehr passt. Na, lass das mal nicht die SDI-Equipment Hersteller hoeren; die machen 12GBit/sec ueber 75 Ohm Koax... z.B.: http://semtech.com/broadcast-video/configurable-eq-cd/gs12090/ Gruss WK
Dergute W. schrieb: >> Ein eindeutiges Zeichen daß das >> Protokoll dafür nicht mehr passt. > > Na, lass das mal nicht die SDI-Equipment Hersteller hoeren; die machen > 12GBit/sec ueber 75 Ohm Koax... Aber ist das denn der selbe Biphase Mark Code wie bei S/PDIF? Wenn man sich mit mehreren Trägern, QAMsoundsoviel etc. austobt, bekommt man ohne Probleme ein paar GBit über Koax, siehe z.B. Kabelfernsehen. Genau das meinte ich damit, daß das Protokoll nicht mehr passt.
:
Bearbeitet durch User
Moin, Gerd E. schrieb: > Aber ist das denn der selbe Biphase Mark Code wie bei S/PDIF? Natuerlich nicht. Aber es ist ein NRZI - also auch stumpf Einser und Nuller als 2 verschiedene Spannungen (0 und 800mV) ueber's Kabel getackert. > Wenn man sich mit mehreren Trägern, QAMsoundsoviel etc. austobt, bekommt > man ohne Probleme ein paar GBit über Koax, siehe z.B. Kabelfernsehen. Ist schon klar. Aber genau deshalb hab' ich SDI als Beispiel genommen und eben nicht Kabelfernsehen oder irgendwelches Ethernet-over-Powerline-Gedoens. Gruss WK
Gerd E. schrieb: > Auf Kupferbasis müsste man wohl einen anderen Leitungscodec verwenden, > so ähnlich wie bei Ethernet. Ja, das ist wohl war. Mit dem einfachen BMC ist das Ende der Fahnenstange wohl erreicht. Dergute W. schrieb: > Wenn man sich mit mehreren Trägern, QAMsoundsoviel etc. austobt, bekommt > man ohne Probleme ein paar GBit über Koax, siehe z.B. Kabelfernsehen. > Genau das meinte ich damit, daß das Protokoll nicht mehr passt. Das ist halt eine andere Hausnummer, inklusive Echokompensation. Eigentlich müsste man alle Geräte auf Ethernet umstellen und mit Phys ausstatten, aber wer will das tun?
Ich habe mir nun die letzten Beiträge der vergangen Monate durchgelesen und die Argumente pro und contra Rechteck <-> Sinus durchgegelesen. Ich halte es nach wie vor für offen, ob es zweckmässiger ist einen Takt als Sinus oder Rechteck zu übertragen. Rechteck auf der Grundwelle scheint mit informationsreicher, als die Sinuswelle. Auf der anderen Seite kann die Sinuswelle auf der höchsten Frequenz der Oberwelle des Rechtecks laufen, die gerade noch übertragen werden kann. Was also ist besser?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.