Abend zusammen, ich will im Rahmen einer kleinen Projektarbeit ein Matlab/Simulink programm mit GUI schreiben, dass die DVB-T Übertragung simuliert. Grundkenntnisse sind vorhanden(komplexes Basisband, Modulation etc.) Folgende Funktionen soll die Software haben: Einlesen einer Videodatei Codieren und Modulieren "Übertragung" im Kanal mit Störeinflüssen (Multipath, shadow, AWGN und evtl. weitere Sender) Decodieren und Demodulieren Anzeigen beider Videodateien im Vergleich Mich interessiert hier besonders der Grenzbereich in dem das Empfangssignal zusammenbricht (digitale Signale haben ja quasi eine konstante Qualität bis ab einem bestimmten SNR garnix mehr geht) und die dazugehörige Analyse in der IQ-Ebene. Meine eigentliche Frage: Wie umfangreich schätzt ihr dieses Projekt ein? Offiziell sollen c.a. 60h investiert werden. Einerseits denke ich dass ein paar Sachen recht heftig sind, andererseits wird es vieles auch schon vorgefertigt in Matlab/Simulink geben. Danke für eure Meinungen
Hallo Frank, direkt gesagt halte ich das für unrealistisch. Es hängt aber stark mit deinem Wissen über den Aufbau von Empfängern zusammen und welches Parameter Du in deinem Empfänger als bekannt vorraussetzt. Ein echter Empfänger muss zunächst diverse Synchronisationsaufgaben durchführen. Nimmst Du aber an, dass dein Modell die zeitliche Lage der OFDM-Symbole kennt und die Symbolrate exakt bekannt ist, wird es schon ein deutliches Stück einfacher (aber leider auch unrealistischer, da die notwendigen Synchronsationsalgorithmen ja auch mit Störungen hinweg Fehler erzeugen). Nächster Punkt ist die Kanalschätzung. Ist der Frequenzgang des Kanals unbekannt, musst Du mit Hilfe der Pilotträger eine Schätzung der Kanal-Impulsantwort durchführen. Nimmst Du den Kanal als A-Priori bekannt an, wird der Empfänger wieder deutlich einfacher. Wenn ich dein Posting richtig verstehe, willst Du gerade Störungen im Kanal einfügen. Wenn die Zeit- oder Frequenzselektiv sind, kommst Du um eine Kanalschätzung nicht herum. Aber gerade OFDM hat hier seine Stärke, da pro OFDM-Symbol von einem eingeschwungenen Kanal ausgehen kannst (Durch das Guard-Intervall). Nach der Kanalschätzung bleibt noch die Decododierung der Nutzinformation. Wenn mich da mein Gedächtnis nicht täuscht, werden bei DVB-T Turbo-Codes verwendet, d. h. du musst noch einiges über die Decodierung von Turbo-Codes wissen (Stichpunkte sind Maximum-A-Posteriori-Sequence-Estimation, Scrambling). So nebenbei musst Du noch das Encoding des Sendesignals lösen, was bestimmt auch einige Zeit kostet. Ich habe vor vielen Jahren mal an der Defintion eines DVB-T Empfängers in einem FPGA gearbeitet und da steckt eine Menge an Know-How drin. Vielleicht gibt es aber irgendwo ein fertiges Simulink-Model, dass Du analysieren kannst. Wenn Du Dir mehr Zeit nimmst, ist es ein tolles Projekt. OFDM macht richtig Spass und ist ja heute die State-Of-The-Art Modulationstechnik. Gruss Markus
> Wenn mich da mein Gedächtnis nicht täuscht, werden bei DVB-T > Turbo-Codes verwendet, Erst bei T2. T hat nur Convolutional Coding und Reed-Solomon. > andererseits wird es vieles auch schon vorgefertigt in > Matlab/Simulink geben. Willst du Malen nach Zahlen oder es wirklich verstehen? 60 Stunden sind aber ein Witz. Wenn du (jetzt mal von FFT und Filtern abgesehen) alles selbst schreiben willst, wird das nichtmal für den Transmitter ausreichen. Und das ist nur der Poppel-Teil, der Empfänger ist aufgrund der schon erwähnten Sychronisation/Kanalschätzung viel aufwendiger. Und die sind wesentlich für die Performance... > Einlesen einer Videodatei Das gehts schon los. Wenn du echtes DVB-T haben willst, dass auch ein realer Empfänger wieder darstellen soll, muss der Videostream schon im TS-Format mit mind. 2 PIDs und vernünftiger AV-Synchronisation vorhanden sein. Zustätzlich braucht es eine ganze Menge SI-PIDs, damit die Streamverwaltung passt. Für die reine Analyse ist das also eher sinnlos, dafür reichen schon Pakete mit lauter FFs. > Codieren und Modulieren Also Scrambling, Interleaving, RS, Convolutional Coding, Carrier Mapping, Pilotenwanderung, etc. Allein das Lesen, Verstehen und Umsetzen der diversen Permutations/Mapping-Regeln/Tabellen im Standard dauert. > "Übertragung" im Kanal mit Störeinflüssen Nicht zu vergessen Nichtlinearitäten, der Todfeind von OFDM. > und die dazugehörige Analyse in der IQ-Ebene. Naja, ist eher unspannend. Die Kanalschätzung verschätzt sich halt, die Konstellation sieht nach Müllhaufen aus und der Viterbi hat auf einmal 30 gleichgrosse Metriken, aus denen er auswählen soll ;) BTW: Ich will's dir nicht abspenstig machen, es ist nur deutlich aufwendiger, als du dir jetzt vorstellen willst...
Vielen Dank Markus und Georg für eure Antworten: MJF schrieb: > Nimmst Du aber an, dass dein Modell die zeitliche Lage der OFDM-Symbole > kennt und die Symbolrate exakt bekannt ist, wird es schon ein deutliches > Stück einfacher Durch die "diskrete" Natur von Matlab/Simulink ist die Lage der Symbole doch immer gleich? Symbolrate ist fix. MJF schrieb: > Aber gerade OFDM hat hier seine Stärke, da > pro OFDM-Symbol von einem eingeschwungenen Kanal ausgehen kannst (Durch > das Guard-Intervall). Ein weiterer Punkt den ich "untersuchen" will: Was passiert, wenn eine transiente Störung länger als das Guardintervall ist. Was die Kanalschätzung angeht, bin ich mir auch nicht ganz sicher. Sollte aber letztlich kein Problem sein. MJF schrieb: > d. h. du musst noch einiges über die > Decodierung von Turbo-Codes wissen Nun natürlich muss ich mich in das Thema einlesen, aber Simulink bietet dafür garantiert vorgefertigte Blöcke. Damit komm ich direkt hierzu: Georg A. schrieb: > Willst du Malen nach Zahlen oder es wirklich verstehen? > 60 Stunden sind aber ein Witz. Wenn du (jetzt mal von FFT und Filtern > abgesehen) alles selbst schreiben willst, wird das nichtmal für den > Transmitter ausreichen. Ich finde, 60h sind kein Witz. Das sind in der Arbeitswelt immerhin ~1.5 Wochen. Ich will nicht alles selber schreiben, das würde wesentlich mehr Zeit kosten da stimme ich zu. Deinen ersten Punkt finde ich etwas verwirrend, heisst das ich muss von jedem kleinsten Detail alles wissen um etwas wirklich zu verstehen? Georg A. schrieb: > Wenn du echtes DVB-T haben willst, dass auch ein > realer Empfänger wieder darstellen soll, muss der Videostream schon im > TS-Format mit mind. 2 PIDs und vernünftiger AV-Synchronisation vorhanden > sein. Ich hatte ein Simulationsmodell für RDS gesehen, bei dem ein string übertragen wurde. Daher dachte ich ich könnte einfach eine (avi)Videodatei einlesen und diese übertragen. Ob die dann noch MPEG2/4 codiert wird, wollte ich je nach Zeitaufwand entscheiden. Die Analogseite will ich weglassen(!!). Georg A. schrieb: > Nicht zu vergessen Nichtlinearitäten, der Todfeind von OFDM. Wie kann man die modellieren? Georg A. schrieb: > Naja, ist eher unspannend. Sagst du ;) Was fändest du denn interessant?
> Durch die "diskrete" Natur von Matlab/Simulink ist die Lage der Symbole > doch immer gleich? Symbolrate ist fix. Damit vereinfachst du den Empfangsprozess auf eine Weise, mit der du gewonnene Erkenntnisse eigentlich gleich wieder vergessen kannst, weil das nichts mehr den DVB-T "da draussen" zu tun hat. Multipath ist nicht alles. Es gibt in der Realität noch Carrier- und Symbol/Samplerate-Offset, und die Qualität der Korrektur beeinflusst das SNR. > Deinen ersten Punkt finde ich etwas verwirrend, heisst das > ich muss von jedem kleinsten Detail alles wissen > um etwas wirklich zu verstehen? Ich persönlich finde es vorteilhaft, wenn man den Teil hinter den Kulissen auch kennt. Sicher gibts irgendwo eine Toolbox, wo gleich ein ganzer DVB-T-Modulator als eine Funktion drin ist. Warum nicht gleich die nehmen? > Ich hatte ein Simulationsmodell für RDS gesehen, bei dem ein string > übertragen wurde. Naja, RDS ist ja so simpel, da ist die Verpackung des Strings schnell gemacht. Bei DVB-T ist es für die Analyse aber recht egal, was da gesendet wird. "Zwischendurch" gibt es eh keinen Zusammenhang mit dem TS, mit dem man was anfangen könnte. Und ob der TS jetzt reale Daten (samt SI&Co) hat oder einfach nur Dummy-Pakete, macht am Ausgang keinen Unterschied. Da wären Dummy-FFs sogar besser, weil man mit blossen Auge sieht, was faul ist. > Wie kann man die modellieren? Für den Anfang sollte was mit exp(-x) gehen, halt so typische Transistor-Sättigungen. Produziert dann munter ICI durch Intermodulationen aller Träger... > Sagst du ;) Was fändest du denn interessant? Ich finde das deswegen unspannend, weil ein "schlechtes" Konstellationsdiagramm zu einem Zeitpunkt eigentlich noch keine wirklichen Rückschlüsse auf das Endergebnis zulässt. Durch Symbolmapping/Interleaving/Viterbi/RS wird da ja noch eine riesige Historie miteinbezogen. Spannend sind eher die Probleme mit der Realisierung der Kanalschätzung und die Möglichkeiten, sie maximal robust mit minimalem Aufwand zu machen. Da scheint ja schon nach einiges zu gehen, wenn man so die Paper/Patentflut anschaut oder neuere Demods mit älteren vergleicht.
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.