6490: Millionen von korrigierbaren Fehlern?

[wittmann]

RENEROMANN!!!

Ich dachte ich habe das Baby endlich zum schlafen gebracht!

Spass

[reneromann]

Es muss ja aber gewissermaßen nach der Demodulation passieren.....

Klar, alles passiert nach der Demodulation - aber du demodulierst keine reinen Nutzdaten, sondern die Kombination aus Nutzdaten (MPEG-Transportstrom) und FEC-Daten.
Bei einer FEC von 7/8 im Sat-Bereich folgen quasi auf 7 Bit Nutzinformation 1 Bit für die Fehlerkorrektur. Es sind aber nicht feste Nutzbits und dann feste Fehlerbits, sondern viel mehr ist das eine "Übersetzungsmatrix", bei der gewisse 8-Bit-Codes (auch mehrere) auf einen 7-Bit-Datencode "umgemappt" werden. Erst das was hinter der FEC rausfällt, sind wirklich die Nutzdaten des MPEG-Transportstroms. Du kannst also die FEC nicht überspringen, weil die FEC die Daten nicht nachträglich versucht zu "reparieren", sondern weil die FEC die in das Datensignal eingebetteten "Fehlerkorrekturinformationen" bei der (Rück-)Übersetzung bereits korrigierend auf die Daten "gewirkt" haben.
Und das noch, bevor du überhaupt den (dann bereits hoffentlich komplett korrigierten) MPEG-Transportdatenstrom hast.

[hermann.a]

Hallo,

@lezard:
und welches Problem genau hast Du derzeit????

Mfg
Hermann

[robert_s]

Darf ich fragen, woher diese Erkenntnisse stammen?

Natürlich: Das sind allgemeine Erkenntnisse/Gegebenheiten der Informatik.

Falsches Fachgebiet. Elektrotechnik / Integrierte Schaltungen / Mikroelektronik passt hier (und ist zufällig meins )

Ich störe mich schon an den Bezeichnungen hier: Klassischerweise besteht so ein digitaler Empfänger:

1. Aus einem analogen HF-Tuner, der einen Kanal aus dem Spektrum auf eine feste Frequenz "runtermischt" und die anderen Frequenzen ausblendet, und dabei auch noch mit einem Vorverstärker/dämpfer einen bestimmten Zielpegel erzeugt (AGC).
2. Aus einem digitalen Demodulator, der den HF-Tuner steuert, das analoge Eingangssignal digitalisiert (ADC), Taktrückgewinnung durchführt, demoduliert, fehlerkorrigiert und den digitalen Datenstrom ausgibt.
3. Aus einem SoC, der den digitalen Datenstrom verarbeitet, demultiplext, Audio/Video dekodiert - oder eben DOCSIS-Pakete und -Nachrichten extrahiert.

Tuner und Demodulator hatten früher (so vor ~20 Jahren) hardverdrahtete Logik, die mit ein paar Registern (über I2C) parametriert werden konnte. Entsprechend war auch die gesamte Datenpipeline im Demodulator hardverdrahtet. Die ganze Logik als Programmcode auszuführen wäre mit damaliger Prozessorleistung auch schwer machbar gewesen und wenn doch, sehr ineffizient. Wer will schon einen DVB-C Empfänger, der 100W verbrät...?

Heutzutage ist das alles weitaus weniger spartanisch, da läuft ja selbst auf dem Tuner eine Firmware, und auf dem Demodulator sowieso. Was aber nicht heißt, dass die nicht nach wie vor Hardwarelogik für die Datenpipeline haben. Die Firmware dient eher dazu, die inneren Funktionen zu steuern und als "abstraktes" Interface bereitzustellen - sicherlich auch nicht zuletzt, um "Betriebsgeheimnisse" zu waren.

Wobei man heute so schöne Möglichkeiten hat: Da könnte man glatt auf die Idee kommen, als "Funprojekt" einen Mixed Signal FPGA herzunehmen und in VHDL einen DVB-C Demodulator zu programmieren, in eine Hardwareschaltung zu synthetisieren ("compilen") und das dann in den FPGA zu programmieren und dann mal zu schauen, ob der einen digitalen Fernsehkanal oder einen DOCSIS-Kanal empfangen kann...

Sorry für den Exkurs, ich habe jahrelang Treiber für diese Teile programmiert, und bin jetzt zu spät zur Party gekommen

[Flole]

Das wird an der Uni unter dem begriff "technische Informatik" gelehrt, Prozessordesign (was anderes ist ein IC ja auch nicht), daher hatte ich das jetzt mal als Informatik abgetan, aber Mikroelektronik wäre wohl richtiger gewesen.

Was heißt das ganze denn nun für die Fehlerkorrektur: Geht dabei etwas Zeit verloren oder nicht? Wenn man die Reihenfolge im Modulator so abarbeitet wie du beschrieben hast wäre es prinzipiell ja egal ob die Datenrate dann da plötzlich variabel wird, die Erklärung von reneromann ist aber auch sehr einleuchtend (und auch verständlich, danke dafür!) wobei ja irgendwas die Fehler korrigieren müsste (also einen Schreibvorgang auf ein fehlerhaftes Bit ausführend müsste, was Zeit in Anspruch nimmt), egalisiert kann das ganze ja wiederum nur durch eine Pipeline werden wie ich sie vor einigen Posts beschrieben hab (nen Takt gibts ja durch die Taktrückgewinnung dafür auch).

[robert_s]

Klar, alles passiert nach der Demodulation - aber du demodulierst keine reinen Nutzdaten, sondern die Kombination aus Nutzdaten (MPEG-Transportstrom) und FEC-Daten.
Bei einer FEC von 7/8 im Sat-Bereich folgen quasi auf 7 Bit Nutzinformation 1 Bit für die Fehlerkorrektur. Es sind aber nicht feste Nutzbits und dann feste Fehlerbits, sondern viel mehr ist das eine "Übersetzungsmatrix", bei der gewisse 8-Bit-Codes (auch mehrere) auf einen 7-Bit-Datencode "umgemappt" werden.

Das ist aber die innere "Viterbi" FEC. Darauf folgt dann die äußere "Reed-Solomon" FEC, und die besteht eben aus 188 Bytes MPEG-2 Frame + 16 Bytes Redundanz.

DVB-C (und EuroDOCSIS) hat keine innere FEC, nur die Reed-Solomon FEC. Die kabelgebundenen Signale kommen eben so gut an, dass man sich den Aufwand sparen konnte. Viterbi in Hardware war in den frühen 1990ern übrigens noch eine ziemliche Herausforderung...

[robert_s]

Das wird an der Uni unter dem begriff "technische Informatik" gelehrt, Prozessordesign (was anderes ist ein IC ja auch nicht), daher hatte ich das jetzt mal als Informatik abgetan, aber Mikroelektronik wäre wohl richtiger gewesen.

Geht ja alles fließend ineinander über. Ich habe das einst im Studiengang Elektrotechnik gemacht (mit TI hat man damals wohl erst angefangen), und konnte mir die Fächer im Hauptstudium so aussuchen. Programmieren ist ja nur Handwerkszeug, das muss man nicht studieren Witzigerweise arbeite ich heute als Softwareentwickler

Was heißt das ganze denn nun für die Fehlerkorrektur: Geht dabei etwas Zeit verloren oder nicht? Wenn man die Reihenfolge im Modulator so abarbeitet wie du beschrieben hast wäre es prinzipiell ja egal ob die Datenrate dann da plötzlich variabel wird,

Nein, das ist eine getaktete Datenpipeline, der Takt richtet sich nach der Symbolrate. Stell es Dir wie Fließbandarbeit vor, oder wie einen Datenflussrechner, wobei Fließband oder Datenfluss nie angehalten werden (außer im Standby). Bei einem 256-QAM Signal ist eben alle 204 Takte ein MPEG-2 Frame fertig - ggf. als fehlerhaft markiert (TEI-Bit gesetzt) und der Fehlerzähler hochgezählt. Wie gesagt, das passiert alles "im Fluss" - die Daten laufen durch die Funktionseinheiten im Chip, und liegen eben nicht wie bei einer CPU im Speicher rum, wo ein Algorithmus über sie iteriert.

[Flole]

Ja gut, dann ist es also tatsächlich so (oder so ähnlich) wie ichs vorhin mit der Pipeline beschrieben hab und die FEC kann da solange dran rumdoktorn bis die Daten "weiterrücken" (bedingt durch die Symbolrate wie ich jetzt weiß) und es gibt tatsächlich keinerlei Verzögerungen dadurch.

Sorry @wittmann, da hab ich dich dann wohl zu unrecht korrigieren wollen, tut mir Leid . Dieses "Wissen" kam auch aus irgendeinem Forum wenn ich das richtig weiß, aber jetzt weiß ichs ja besser! Danke euch dreien für die Erklärungen!