Die Bit error rate wird ja bei vielen theoretischen Betrachtungen oft verwendet, aber wie kann man sie praktisch messen? Ich habe einige Geräte für den GBit-Berwich mit nicht genannten Preisen gesehen, aber wie würde man das z.B. bei einer UART oder einer Funkverbindung machen?
Luky S. schrieb: > Die Bit error rate wird ja bei vielen theoretischen Betrachtungen oft > verwendet, aber wie kann man sie praktisch messen? schau dir doch einfach mal den integrierten Bit Error Rate estimator" in Xilinx-FPGA's an. Dann kann man auch für UARTS nachbauen. https://www.xilinx.com/video/hardware/in-system-ibert.html Das prinzip ist doch simple, schick einfach eine vereinbarte Symbolfolge (bspw. eine PRN) und vergleich die mit dem selben PRN generator am Ziel. Oder nimm ne CRC und zähle hinten die Fehler. Wobei die PRN vom Spectrum her schon sehr realistisch ist. https://theses.hal.science/tel-00978950/document. Oder wenn schon einige Protokollschichten mehr laufen, schick ping-requests und zähl die Fehler
Luky S. schrieb: > aber wie kann man sie praktisch messen? Mit einem BERT: https://en.wikipedia.org/wiki/Bit_error_rate#Bit_error_rate_tester Sowas gibt es als eigenständiges Gerät: https://www.keysight.com/us/en/products/bit-error-ratio-testers.html Oder als Zusatzoption zum Spektrumanalysator: https://www.youtube.com/watch?v=Y8WB6lxCMfc
Die teuren Geräte habe ich ja gefunden... Aber die Frage war ja, wie man das bei geringen Datenraten z.B bei einer UART (RS485) messen kann
Luky S. schrieb: > Aber die Frage war ja, wie man > das bei geringen Datenraten z.B bei einer UART (RS485) messen kann Willst du wirklich messen oder nur prüfen? Mit einem mittelprächtigen, günstigen, modernen Scope ist es keine Kunst, ein Augendiagramm darzustellen, und das sagt schon Einiges aus, ist aber natürlich keine Messung. Würde aber auch nur bei Software-UART Sinn machen. Die UARTs in Hardware funktionieren schon weitgehend fehlerfrei. Wenn da Fehler auftreten, dann liegst in den meisten Fällen an der Software.
:
Bearbeitet durch User
Ich möchte das schon wirklich messen. Also unterscheiden ob die BER bei 10^-9 oder 10^-10 liegt. In der Realität ist die Übertragung nicht fehlerfrei. Wozu bräuchte es z.B. sonst CRC und ähnliches?
Analytisch bei binärer Modulation BER = p(0)P(1|0) + p(1)P(0|1). Lässt sich für Simulationen mithilfe der Error Function schätzen wenn du ein paar Parameter der Pegel wie Standardabweichung von 1en und 0en, Mittelwert 1en und 0en u Schwellwert reinsteckst. Praktische Messung indem du eine lange PRBS überträgst und dann einfach schaust wie viele Bits falsch empfangen worden sind. BER = n_e/N. n_e ist Anzahl der falsch empfangenen Bits, N ist die Zahl der insgesamt übertragenen.
Für einen transparenten Kanal kannst du für wenig Geld einen gebrauchten Bitfehlermessplatz PF-6 von W&G kaufen. Wenn du allerdings bei kleinen Bitraten irgendwas von 10E-11 messen willst, musst du vllt eine Woche warten, bis die Messung fertig ist.
Bernd G. schrieb: > Wenn du allerdings bei kleinen > Bitraten irgendwas von 10E-11 messen willst, musst du vllt eine Woche > warten, bis die Messung fertig ist. Bei z.B. 10E-11 darf es nur einen Bitfehler auf 10E11 Bits geben. Bei einer Bitrate von 9600 bps ergibt das eine Messzeit von: 10^11 / 9600 bps = 10416666,7 s Das sind ca. 4 Monate...
Luky S. schrieb: > Wozu bräuchte es z.B. sonst CRC und ähnliches? Protokolle und CRC nimmt man, um einen Datenstrom nach Übertragungsfehlern wieder synchronisieren zu können. Z.B. bei Funkstörungen, jemand zieht das Kabel, eine Seite bootet neu nach VCC-Schwankungen usw. Solange das Übertragungsmedium genügend Reserve gegenüber der gewünschten Datenrate hat, gibt es keine Bitfehler. Unausgereifte Soft- oder Hardware kann sich auch gerne wie Bitfehler verhalten, z.B. wenn zwischen Film und Werbung umgeschaltet wird.
Luky S. schrieb: > Ich möchte das schon wirklich messen. Also unterscheiden ob die BER bei > 10^-9 oder 10^-10 liegt. Ich hab den Eindruck, du denkst, du bist hier bei "Wünsch Dir was". So ein messgerät, das dir sagt, die Fehlerrate bei dieser Konstruktion ist immer nahezu 0, gibt es nicht. Du musst schon konkrete Zufallsgrößen messen, wie das durchschnittliche SNR ausschaut um gewisse fehlerraten garantieren zu können. Bei UART verbindungen misst mal klassischerweise die Flankensteilheiten und setzt den Abtastzeitpunkt so, das auch bei jittern der einzelnen Oszillatoren (RX und TX) immer noch genug Margin ist, damit das richtige Bit getroffen wird. Und das "immer" weist man näherungsweise durch Temperaturtests und künstliche Alterung nach. https://www.researchgate.net/publication/228309783_Design_Implementation_and_Optimization_of_Highly_Efficient_UART
Peter D. schrieb: > Solange das Übertragungsmedium genügend Reserve gegenüber der > gewünschten Datenrate hat, gibt es keine Bitfehler. Bis auf EMI-Effekte. Lege mal ein serielles Kabel neben ein Hochstromkabel für Motoren. Da hast du Spaß.
Bernd schrieb: > Bei z.B. 10E-11 darf es nur einen Bitfehler auf 10E11 Bits geben. Bei > einer Bitrate von 9600 bps ergibt das eine Messzeit von: > 10^11 / 9600 bps = 10416666,7 s > Das sind ca. 4 Monate... Halt, halt - statistische Größen zu messen, funktioniert etwas anders. Erstmal: 10E-11 bedeutet im Mittel EINEN Fehler auf 1E10 Datenbits. Eine asynchrone serielle Übertragung mit 9600Bd benötigt wegen des Datenrahmens pro Datenbit effektiv minimal 130µs, d.h. 1E10 Datenbits benötigen für die Übertragung damit rund 1,3 Mio Sekunden (1,3E6s) oder 15 Tage. Um daraus eine statistisch signifikante Aussage zu treffen, reicht es bestimmt nicht, beim ersten auftretenden Fehler gleich "εὕρηκα" zu rufen. Wenn man die oben (völlig falsch) berechneten vier Monate ansetzt, ist im statistischen Mittel mit 8 Fehlern zu rechnen, d.h. der mit 4 Monaten ermittelte Messwert hat immer noch eine einfache Standardabweichung von etwa ±3. Wenn die Übertragung durch den Bit-Fehler aus dem Tritt kommt und neu synchronisieren muss, kommt deutlich mehr durcheinander und man darf beim Test nicht nur auf die richtige Übertragung einzelner Bits gucken.
Wolfgang schrieb: > Halt, halt - statistische Größen zu messen, funktioniert etwas anders. Genau so funktioniert aber der PF6 von Wandel und Goltermann. Wenn 10E7 Bits einer Quasizufallsfolge z.B. QZF23 (wählbar) fehlerfrei übertragen wurden, zeigt das Messgerät irgenwann eine BER von < 1 x 10E-7 an. Bei einem UART würde ich allerdings keinen einzigen Gedanken an eine entsprechende Messung verschwenden.
Bernd G. schrieb: > Wenn 10E7 Bits ... 10E7 steht für 10·10^7, so die allgemeine Verwendung vom "E" in Zahlendarstellungen. > ... z.B. QZF23 (wählbar) fehlerfrei einer Quasizufallsfolge übertragen > wurden, zeigt das Messgerät irgenwann eine BER von < 1 x 10E-7 an. Dazu musst du erstmal festlegen, was "übertragen" bedeutet, also ob du dich mit der BER z.B. auf OSI Physical Layer, OSI Data Link Layer oder höher beziehst. Das "irgendwann" muss bei so einer Messung über die tolerierte Standardabweichung und die Übertragungsrate festgelegt werden. Dazu muss diese definiert sein, z.B. in der Konfiguration des Messgerätes.
p.s. Bernd G. schrieb: > Bei einem UART würde ich allerdings keinen einzigen Gedanken an eine > entsprechende Messung verschwenden. Auch eine Datenübertragungsstrecke, bei der ein UART beteiligt ist, verfügt selbstverständlich über eine BER. Und auch da wird die Frage nach der Zuverlässigkeit der Übertragung auftauchen. Ob dein Messgerät das messen kann, steht auf einem anderen Blatt.
Harry L. schrieb: > Würde aber auch nur bei Software-UART Sinn machen. > Die UARTs in Hardware funktionieren schon weitgehend fehlerfrei. > Wenn da Fehler auftreten, dann liegst in den meisten Fällen an der > Software. <ironie>Klar, der Umrichter direkt nebenan oder der Teilchenschauer, ausgelöst durch ein Teilchen der Kosmischen Strahlung mit mehreren PeV hat bei einer asynchronen Übertragung mit HW-UART bestimmt keinen Einfluss.</ironie> Fehler durch schludrige Programmierung haben bei einer Betrachtung der BER doch wohl nichts zu suchen.
Bernd G. schrieb: > Genau so funktioniert aber der PF6 von Wandel und Goltermann. > Wenn 10E7 Bits einer Quasizufallsfolge z.B. QZF23 (wählbar) fehlerfrei > übertragen wurden, zeigt das Messgerät irgenwann eine BER von < 1 x > 10E-7 an. Ja, er zeigt kleiner 10e-7 an. Mehr kann er zu dem Zeitpunkt nicht tun. Das heißt nicht, dass das schon die BER ist. Du musst dann schon noch eine Weile weiter messen. Dann wird aus < 10e-7 vielleicht mal < 10e-9 oder eben auch x * 10e-5 ... Es war ja noch nicht mal ein Fehler aufgetreten. Es sollten schon einige sein, damit man eine Aussage über die BER machen kann. Ich könnte mir vorstellen, dass das im Manual des WaGo-Gerätes ausführlich beschrieben ist. Deine oben genannten vier Monate könnten so leicht zu 40 oder 100 Monaten Messzeit werden 😀.
HildeK schrieb: > Ja, er zeigt kleiner 10e-7 an. Mehr kann er zu dem Zeitpunkt nicht > tun. > Das heißt nicht, dass das schon die BER ist. Du musst dann schon noch > eine Weile weiter messen. Dann wird aus < 10e-7 vielleicht mal < 10e-9 > oder eben auch x * 10e-5 ... > Es war ja noch nicht mal ein Fehler aufgetreten. Es sollten schon einige > sein, damit man eine Aussage über die BER machen kann. > Ich könnte mir vorstellen, dass das im Manual des WaGo-Gerätes > ausführlich beschrieben ist. Alles absolut korrekt. Ich wollte das hier aber nicht in aller Breite auswalzen. Wer diese Messungen schon mal gemacht hat, weiß es. Ich musste bereits bei 155 Mbit/s ellenlang warten, um auf 1 x 10e-10 zu kommen. Der Kunde wollte es so. Wenn dann irgendein Idiot die Etagensicherung wirft...
Also asynchrone Verbindungen macht man eigentlich nicht, wenn man von Bitfehlerraten spricht, denn dort kann ein falsches Start-Bit ja schon mehrere Datenworte kaputt machen. Bei synchronen Verbindungen überträgt man entweder die 10^x Bits, ggf. über Monate hinweg, um Statistiken über die Bitfehler machen zu können, oder man wendet einen Trick an. Bei einer synchronen Verbindung tastet man das Signal auf der Leitung zur Bit-Mitte ab (bzw zur Symbolmitte). Im Augendiagramm ist das die Stelle an der das Auge am weitesten offen ist. Würde man jetzt genau zwischen 2 Bits abtasten, hat man den schlimmst möglichen Punkt erreicht. An diesem Punkt hätte man bei einem Binärsignal 50% Bitfehler. Jetzt kann man von den Abtastzeitpunkten zwischen den Bits ein Stück Richtung Bitmitte gehen, und dann die Bitfehlerrate bestimmen. Man kann so in vertretbar kurzer Zeit die Bitfehlerrate in den Randbereichen des Bits bestimmen. Dadurch ergibt sich eine Funktion der Bitfehlerrate über den Abtastzeitpunkt. Diese Funktion kann man nun extrapolieren um die Bitfehlerrate im optimalen Punkt abzuschätzen, ohne Monate lang Bits übertragen zu müssen.
Das ist ein interessanter Ansatz. Nur hätte ich ein paar Bedenken: - Wenn du auf diese Art zu einem Ergebnis kommst, musst du z.B. dem Kunden auch schlüssig und verständlich erklären können, mit welcher mathematischen Grundlage du zu der BER gekommen bist. Das stelle ich mir nicht ganz einfach vor. - Oftmals wird bei der Übertragung der Abtasttakt aus den Datenwechseln gewonnen. Dabei ist nicht immer sichergestellt, dass du exakt die Augenmitte erwischt. Aber deine Hochrechnung geht davon aus, dass du in Bitmitte abtastest. Was letztlich bedeutet: deine BER kann bestenfalls so gut sein, wie du angegeben hast aber durchaus auch schlechter. Das hilft nicht.
Christian B. schrieb: > oder man wendet einen Trick an. Genau. Man fügt auf der Sendeseite definiert Fehler (Bit-, Block- oder Codefehler) ein und wertet das auf der Empfangsseite aus. Oder man verjittert das Signal definiert auf der Sendeseite und sieht sich die Fehler auf der Empfangsseite an. Damit kann der PF-6 automatisch die Jittertoleranz des Sytems ermitteln. Alles der Schnee von gestern (Stand 1990).
Bernd G. schrieb: > Ich > musste bereits bei 155 Mbit/s ellenlang warten, um auf 1 x 10e-10 zu > kommen. Der Kunde wollte es so. Wenn dann irgendein Idiot die > Etagensicherung wirft... ... ist das irrelevant, weil, keine Übertragung -> keine Übertragungs(|Bit)-Fehler. Oder statistisch betrachtet, die Messdauer beeinflusst nicht den Erwartungswert , aber dessen σ. https://matheguru.com/stochastik/standardabweichung.html#:~:text=Genauer%20gesagt%2C%20gibt%20sie%20an%2C%20wie%20weit%20die,Standardabweichung%20ist%20definiert%20als%20die%20Quadratwurzel%20der%20Varianz.
Bernd G. schrieb: > Man fügt auf der Sendeseite definiert Fehler (Bit-, Block- oder > Codefehler) ein und wertet das auf der Empfangsseite aus. Damit kannst du deine Fehlererkennung und -korrektur überprüfen, nicht aber die BER, die auf Grund von z.B. Rauschbeiträge auf der Übertragungsstrecke verursacht werden und die z.B. die Robustheit des Modulationsverfahrens und die Empfindlichkeit des Empfängers zeigen soll.
HildeK schrieb: > Bernd G. schrieb: >> Man fügt auf der Sendeseite definiert Fehler (Bit-, Block- oder >> Codefehler) ein und wertet das auf der Empfangsseite aus. > > Damit kannst du deine Fehlererkennung und -korrektur überprüfen, nicht > aber die BER, die auf Grund von z.B. Rauschbeiträge auf der > Übertragungsstrecke verursacht werden und die z.B. die Robustheit des > Modulationsverfahrens und die Empfindlichkeit des Empfängers zeigen > soll. Die Frage ist eben ob die BER über die Nutzdaten oder über alles bestimmt wird. Und ob es sind macht die BER unabhängig von der datenrate zu betrachten. Die BER ist von vielen Parameter der RX/TX-module abhängig, Kanalcodierung ist eine davon, Swing, Emphasis, ... sind weitere.
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.