Hallo Forum, ich habe zu dem Thema schon ein paar Threads gelesen, bin aber noch nicht richtig schlau geworden. Ich möchte per UART einen MP3-Stream empfangen. Wenn dieser eine Bitrate von 128kBit/s hat, ich die UART mit einem Start- und einem Stoppbit betreibe, kein Paritätsbit verwende, ist meine Rechnung dann richtig, dass ich die UART-Schnittstelle auf mindestens 160 000 einstellen muss? Die Baudrate ist ja ohne Einheit oder? LG
Peter schrieb: > Die Baudrate ist ja ohne Einheit > oder? Baud ist die Einheit, diese besagt dass pro Sekunde ein Symbol übertragen wird. Bei 160000 werden 160000 Symbole pro Sekunde übertragen, entspricht also eine Frequenz 1/s. Die Datenübertragung ist aber etwas anderes, da diese die Einheit Bit/s trägt. Die Datenübertragung eines Symbol dauert z.B. t = 0,5 s also (1/0,5 s) = 2 Baud. Gruß Daniel
:
Bearbeitet durch User
ok aber ein Symbol ist bei UART doch ein Bit oder? Also bei 128000 Bit/s durch den MP3 stream und je 8 bit ein Start und ein Stopbit, sind es 160000 Bit /s, die ich empfangen muss, was bei UART eine Baudrate von 160000 benötigt ?
Peter schrieb: > ok aber ein Symbol ist bei UART doch ein Bit oder? Also bei 128000 Bit/s > durch den MP3 stream und je 8 bit ein Start und ein Stopbit, sind es > 160000 Bit /s, die ich empfangen muss, was bei UART eine Baudrate von > 160000 benötigt ? ja das stimmt erst mal. I.d.R. folgen die Bytes aber nicht unbedingt vollkommen lückenlos aufeinander, so das die Baudrate schon etwas höher sein sollte. 256kBit/s wäre wohl der nächste Standartwert. Sascha
> 256kBit/s wäre wohl der nächste Standartwert.
230400 bit/s wäre es wohl.
ok vielen Dank, ich werde das später ausprobrieren und rückmeldung geben, afaik hat es aber unter 300 000 baud nicht geklappt, aber in der theorie sollten es 160 000 baud sein
Peter schrieb: > ok vielen Dank, ich werde das später ausprobrieren und rückmeldung > geben, afaik hat es aber unter 300 000 baud nicht geklappt, aber in der > theorie sollten es 160 000 baud sein Dann erzähl doch mal was zur verwendeten Hard-/Software! Sascha
Du darfst auch den Fehler deiner Baudrate nicht vergessen. Ohne zu wissen, auf welchem System du das empfängst, musst du dennoch darauf achten, dass deine Taktquelle den Baud-Takt auch erzeugen kann. Ich weiß gerade nicht, ob das nur auf AVR-Controller zutrifft, aber meines Wissens nach darf die Abweichung von der Soll-Baudrate nicht mehr als 2% betragen. Je niedriger der Fehler, desto näher bist du natürlich an deiner Wunschbaudrate. Vielleicht hast du auch die Möglichkeit, bei deinem Setup Hardware-Flusskontrolle zu verwenden. Wenn du nämlich dem Sender sagen kannst, er soll kurz warten mit dem Senden (du hast ja nicht angegeben, was du noch mit dem empfangenen Stream machst), dann dürfte es auch mit deiner theoretischen Baudrate von 160.000 Baud (± ein paar Baud) klappen. Gruß
A.. P. schrieb: > enn du nämlich dem Sender sagen > kannst, er soll kurz warten mit dem Senden (du hast ja nicht angegeben, > was du noch mit dem empfangenen Stream machst) Wenn er den MP3-Stream nicht in Echtzeit braucht, kann er ja gleich langsamer senden. Aber danach war ersichtlich nicht gefragt. Georg
Peter schrieb: > Hallo Forum, > ich habe zu dem Thema schon ein paar Threads gelesen, bin aber noch > nicht richtig schlau geworden. > > Ich möchte per UART einen MP3-Stream empfangen. Wenn dieser eine Bitrate > von 128kBit/s hat, ich die UART mit einem Start- und einem Stoppbit > betreibe, kein Paritätsbit verwende, > > ist meine Rechnung dann richtig, dass ich die UART-Schnittstelle auf > mindestens 160 000 einstellen muss? Die Baudrate ist ja ohne Einheit > oder? > > LG Sender und Empfänger müssen die selbe Bitrate verwenden sonst klappt es nicht. Und zwar deswegen weil der Empfänger sonst die Bits/Bytes nicht lesen kann. Kurt Einheit: Bit pro Sekunde
A.. P. schrieb: > Vielleicht hast du auch die Möglichkeit, bei deinem Setup > Hardware-Flusskontrolle zu verwenden. Wenn du nämlich dem Sender sagen > kannst, er soll kurz warten mit dem Senden (du hast ja nicht angegeben, > was du noch mit dem empfangenen Stream machst), dann dürfte es auch mit > deiner theoretischen Baudrate von 160.000 Baud (± ein paar Baud) > klappen. Na gerade dann wird es damit nicht klappen. Wenn der Sender nämlich warten muss, muss er danach die Daten erstmal schneller übertragen, um wieder aufzuholen. Kurt schrieb: > Einheit: Bit pro Sekunde Die Einheit der Bitrate ist Bit pro Sekunde. Die Einheit der Baudrate ist Baud. Nein, das ist nicht das selbe.
:
Bearbeitet durch User
Rolf M. schrieb: > > Kurt schrieb: >> Einheit: Bit pro Sekunde > > Die Einheit der Bitrate ist Bit pro Sekunde. > Die Einheit der Baudrate ist Baud. > Nein, das ist nicht das selbe. Stimmt! Baud gibt also an wieviel Zeichen pro Sekunde übertragen werden. Das heisst dann das die Bitrate abhängig von der Anzahl Zeichen pro Byte und den Synchron- und Prüfzeichen ist. Kurt
Kurt schrieb: > Rolf M. schrieb: >> >> Kurt schrieb: >>> Einheit: Bit pro Sekunde >> >> Die Einheit der Bitrate ist Bit pro Sekunde. >> Die Einheit der Baudrate ist Baud. >> Nein, das ist nicht das selbe. > > Stimmt! > > Baud gibt also an wieviel Zeichen pro Sekunde übertragen werden. > > Das heisst dann das die Bitrate abhängig von der Anzahl Zeichen pro Byte > und den Synchron- und Prüfzeichen ist. > > Kurt Ergänzung: > Baud gibt also an wieviel Zeichen pro Sekunde übertragen werden. Maximal Zeichen pro Sekunde. Die Bitrate ist davon unabhängig und sagt nur etwas über die Bit pro Sekunde aus. Besser? Kurt
Rolf M. schrieb: > A.. P. schrieb: >> Vielleicht hast du auch die Möglichkeit, bei deinem Setup >> Hardware-Flusskontrolle zu verwenden. Wenn du nämlich dem Sender sagen >> kannst, er soll kurz warten mit dem Senden (du hast ja nicht angegeben, >> was du noch mit dem empfangenen Stream machst), dann dürfte es auch mit >> deiner theoretischen Baudrate von 160.000 Baud (± ein paar Baud) >> klappen. > > Na gerade dann wird es damit nicht klappen. Wenn der Sender nämlich > warten muss, muss er danach die Daten erstmal schneller übertragen, um > wieder aufzuholen. Das ist nur deine Annahme, da der TO ja mit keinem Wort gesagt hat, ob er den Stream auch in Echtzeit verarbeiten will. Wenn er den lediglich abspeichern möchte, kann er den auch mit 100 Baud übertragen. Deswegen schrieb ich ja auch, dass er "vielleicht die Möglichkeit" hat. Mensch, lern doch, das Gelesene auch zu verstehen und richtig zu interpretieren -_-
A.. P. schrieb: > Das ist nur deine Annahme, da der TO ja mit keinem Wort gesagt hat, ob > er den Stream auch in Echtzeit verarbeiten will. Das nehme ich tatsächlich an, wenn jemand schreibt, dass er einen MP3-Stream übertragen will. Dazu kommt dann noch das: > Wenn er den lediglich abspeichern möchte, kann er den auch mit 100 Baud > übertragen. Eben. Das will er aber nicht, sondern er will es ausgerechnet gerade so schnell übertragen, dass es in Echtzeit verarbeitet werden könnte. Nicht großartig schneller, aber auch nicht langsamer. Zufall? Eher nicht. > Mensch, lern doch, das Gelesene auch zu verstehen und richtig zu > interpretieren -_- Dito.
:
Bearbeitet durch User
Kurt schrieb: > Besser? Nein. Baud ist die Zahl der Symbole pro Sekunde. Ein Symbol kann ein Bit sein oder aber auch 2, 4, 8 oder mehr. Das hängt vom Übertragungsverfahren ab und ist nicht auf UART beschränkt. So gibt es z.B. auch eine 256-QAM mit 256 Zuständen pro Symbol, also pro Schritt 8 Bit. Im Falle der binären Übertragung (wie beim UART) ist 1 Bit/s auch 1 Baud. Unabhängig davon ist, wie richtig erkannt wurde, dass ein kontinuierlicher Quelldatenstrom mit z.B. 256kBit/s nur mit einer höheren Rate über UART übertragen werden kann wegen Startbit, 1 oder 2 Stopbits, ggf. Parity. Mit 160kBit/s ist man ohne Toleranzen an der untersten Grenze. Dann muss der UART-Sender aber auch kontinuierlich senden können und zwischen den einzelnen Bytes keine weitere Zeit zur Bereitstellung des nächsten Bytes benötigen. Das hängt von der Sende-Hardware ab.
Rolf M. schrieb: >> Mensch, lern doch, das Gelesene auch zu verstehen und richtig zu >> interpretieren -_- > > Dito. Tue ich. Das Gesagte war auf meine Annahme und die darauf basierende Antwort bezogen. Ich habe nicht versucht, dass von dir Gesagte zu widerlegen, wohingegen du meinst, dass meine Idee nicht funktioniert. Ich will dich nur darauf hinweisen, dass wir unterschiedliche Annahmen vertreten und beide Annahmen in sich logisch sind.
Peter schrieb: > ist meine Rechnung dann richtig, dass ich die UART-Schnittstelle auf > mindestens 160 000 einstellen muss? Wird eng, dann darf genau gar nix schief gehen. 160.000 Baud heisst 160000Bits/Sekunde, und da sind dann auch Start- und Stop Byte mit drin. Diese Datenrate darf nicht unterschritten werden, sonst gibt es Probleme mit Puffer Unterlauf. Der Praktiker erinnert sich das gängige Daten Quellen (SD, PC) gerne mal Pausen machen und nimmt lieber sowas wie 460800 oder 921600 Baud - und größere Puffer. Außerdem bleibt dann Overhead für ein Protokoll übrig.
Jim M. schrieb: > Peter schrieb: >> ist meine Rechnung dann richtig, dass ich die UART-Schnittstelle auf >> mindestens 160 000 einstellen muss? > > Wird eng, dann darf genau gar nix schief gehen. 160.000 Baud heisst > 160000Bits/Sekunde, und da sind dann auch Start- und Stop Byte mit drin. - Bit - > Diese Datenrate darf nicht unterschritten werden, sonst gibt es Probleme > mit Puffer Unterlauf. Vor allem müsste man das Abspielen dann auch mit der UART synchronisieren, denn selbst wenn es nur minimalst schneller läuft als die UART, reicht es ja schon nicht mehr. > Der Praktiker erinnert sich das gängige Daten Quellen (SD, PC) gerne mal > Pausen machen und nimmt lieber sowas wie 460800 oder 921600 Baud - und > größere Puffer. Außerdem bleibt dann Overhead für ein Protokoll übrig. Wobei größere Puffer auch immer zu größeren Latenzen führen - falls das hier ein Problem sein sollte.
HildeK schrieb: > Kurt schrieb: >> Besser? > Nein. > Baud ist die Zahl der Symbole pro Sekunde. Jetzt wird's schon klarer. (ich hab das im Hinterstüberl immer irgendwie auf "Nutzzeichen + der notwenigen Steuerbits" bezogen) > Ein Symbol kann ein Bit sein oder aber auch 2, 4, 8 oder mehr. Das hängt > vom Übertragungsverfahren ab und ist nicht auf UART beschränkt. So gibt > es z.B. auch eine 256-QAM mit 256 Zuständen pro Symbol, also pro Schritt > 8 Bit. > > Im Falle der binären Übertragung (wie beim UART) ist 1 Bit/s auch 1 > Baud. OK, danke fürs darlegen. Kurt
Ziemlich lang darf die Leitung dafür auch nicht sein. Warum muss überhaupt ein UART dafür benutzt werden? Halte ich dafür für die denkbar ungünstigste Schnittstelle.
Peter schrieb: > Ich möchte per UART einen MP3-Stream empfangen. Wenn dieser eine Bitrate > von 128kBit/s hat, ich die UART mit einem Start- und einem Stoppbit > betreibe, kein Paritätsbit verwende, > > ist meine Rechnung dann richtig, dass ich die UART-Schnittstelle auf > mindestens 160 000 einstellen muss? Ja, das ist die theoretische untere Grenze. In der Praxis nimmt aber etwas mehr, sonst können schon minimal unterschiedliche Zeitbasen von Quelle und Ziel für unschöne Buffer-Underruns sorgen.
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.