Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
DAB Digitalradio Forum
Beiträge im Thema:
37
Erster Beitrag:
vor 10 Monaten
Letzter Beitrag:
vor 9 Monaten, 3 Wochen
Beteiligte Autoren:
Spacelab, Basic.Master, Habakukk, Kohlberger91, Japhi, Georg A., Chris_BLN, Winnie2, DH0GHU, raeuberhotzenplotz1, ... und 7 weitere

Sendeparameter, die DAB-Empfänger crashen

Startbeitrag von Chris_BLN am 26.01.2017 01:16

Hallo in die Runde,

ich stecke gerade in einer Diskussion, in der ich von einem Mitarbeiter einer öffentlich-rechtlichen Rundfunkanstalt die Aussage bekam, es gäbe "unbestätigte Gerüchte", daß es DAB+-Empfänger gibt, die mit Bitraten > 96 kbps nicht klarkämen, da sie zu wenig RAM hätten.

Das erinnert mich an eine Stelle im Zwischenbericht des DAB-Versuches bei Radio BeO in der Schweiz:

"Bezüglich Protection Level, welcher auf die Konstanz der Bitanlieferung in Grenzgebieten wirkt, ist "2A" ein sehr guter Kompromiss zwischen Netto Audiorate und Redundanz der Audiodaten. Ausserdem scheint es für alle Gerätschaften der am kompatibelste zu sein. Ein noch höherer Protection Level verursacht 100% CPU load bei gewissen Radioempfängern, wenn mit einer Bitrate von über 96kbit gesendet wird."

(www.dab-swiss.ch/digital_oberland_zwischenbericht_abstrahlversuch.pdf)

Da wird als Bedingung ein Fehlerschutz größer EEP2-A erwähnt.

DKultur läuft mit 112 kbps EEP2-A. Hat jemand aus dieser Runde einen Empfänger erlebt, der das nicht verdaut hätte?

In Sachsen-Anhalt muß es im Rahmen der aktuellen Tests auch 120 kbps EEP2-A gegeben haben. Gab es da zickende Enpfänger?

Habe wir hier nach dem LC-Bug die nächste gerätebedingte Limitierung oder ist das ein Phantom?

Antworten:

Ich hatte mit sämtlichen Geräten nie Probleme mit 112kbps/EEP-2A. Bei EEP-1A sollen Bitraten von mehr als 96kbps kritisch sein, habe das aber nie ausprobieren können.

von Japhi - am 26.01.2017 04:08
Darf jeder auf seinen Elektronikschrott das DAB+-Logo drucken?

Es müssten doch, wie bei "HD Ready", gewisse Standards zu erfüllen sein.

Ein Radio, welches bei einer Ausstrahlung, die zu 100% dem Protokoll entspricht, abstürzt, dürfte meiner Meinung nach nicht verkauft werden.

von Kuli11 - am 26.01.2017 07:05
Ich wurde in letzter Zeit auch schon öfter gefragt wie sich Fehlerschutz und Bitraten auswirken. Auffälligkeiten bei Geräten hätte ich aber gemeldet. Ich habe nun die Bayern 10D und auch die beiden Privaten Sachsen-Anhalt Muxe mit ihnen Tests. Radios habe ich alle möglichen von FS inkl. Slideshow. Zumindest mobil ist zwischen 120kBit/s EEP-2A und 88kBit/s EEP-1A für mich kein feststellbarer Unterschied. Zu EEP-3A ist aber schon eine deutliche Verbesserung festzustellen.

Besserer Fehlerschutz scheint aber auch zu verbesserten SFN beizutragen. Die Quittung gibt es bei Tropo mit dem Schlagerparadies immer wieder oder noch schlimmer Bayern Verkehrskanal den ich bei 160km/h mit EEP-4 und optimaler Dachantenne einfach nicht mal in Sendernähe empfangen kann. Man muß halt langsamer Fahren.

von pomnitz26 - am 26.01.2017 07:23
Das einzige, was ich gehört habe, dass PL1-A bei Bitratren größer 96kbps Probleme bereitet. Das entspricht 144 CU, die zu verarbeiten sind.

Bei PL2-A entsprächen 144 CU dann 144kbps. Mir ist gerade kein Programm bekannt, das im PL2-A mit höherer Datenrate sendet. Könnte mir aber vorstellen, dass das dann ähnliche Probleme bereitet.

Bei PL3-A wären 144 CU dann 192kbps.

von Habakukk - am 26.01.2017 07:55
Vor der MP2 auf AAC Umstellung wurde mal kurz hier im Saarland mit 144kb/s EEP-2A gesendet. Keiner der 4 Testempfänger mit FS Verona, Quantek Q8, NXP und Gyrosignal Modul (neue Version ohne LC Bug) machte auch nur die geringsten Probleme. Beim EEP-1A könnte das allerdings schon wieder anders aussehen. Wobei mich da mal interessieren würde ob es dann an zu schwacher CPU oder zu wenig RAM Speicher liegt. Vorstellbar wäre beides.

von Spacelab - am 26.01.2017 08:44
@Spacelab:
Aber mehr als die 144kbps hattet ihr auch nicht im EEP2-A, oder? Denn das ergibt 144 CU und die scheinen ja (analog zu 96kbps EEP1-A) noch unproblematisch zu sein.

Nichtsdestotrotz ist das ärgerlich, weil man mal wieder Möglichkeiten, die der DAB+Standard bieten würde, wegen irgendwelcher vergurkter Empfänger nicht ausnutzen kann, nämlich beste Klangqualität bei gleichzeitg bestem Fehlerschutz. Wer mal Standorte mit PL1-A empfangen hat, weiß, wieviel stabiler das Signal hier selbst in Randbereichen des Empfangsgebiets gegenüber PL3-A ist.
Gerade in ländlichen Gebieten, wo man künftig eh vielleicht Probleme hat, einen Mux voll zu bekommen, wäre es allemal sinnvoller, mit bestmöglichem Fehlerschutz und Klangqualität zu senden, anstatt den halben Mux sinnlos leer stehen zu lassen.

von Habakukk - am 26.01.2017 08:55
Es soll auch mit 160kb/s funktioniert haben. Aber da war ich selbst nicht dabei. Höher ging man mit der Datenrate allerdings nicht mehr.

Das man wegen vergurkter Empfänger einen Standard nicht voll ausnutzen kann ist doch heutzutage leider schon normal. Man erinnere sich nur mal an DVB-S und die Sache mit der GOP Länge. Obwohl im DVB Standard eine GOP Länge von 30 Frames festgelegt ist steigen die meisten Empfänger bei mehr als 15 Frames bereits aus. Mehr hatten die alten MPEG-2 Encoder damals nicht genutzt also brauchte man das als Receiver Hersteller ja auch nicht zu unterstützen und konnte am RAM Speicher sparen. Das es aber irgendwann mal Encoder geben könnte die die erlaubten 30 Frames ausnutzen könnten, daran dachte keiner oder es war den Herstellern schlicht egal. Dabei ließe sich die Bildqualität mit größeren GOP Längen deutlich steigern wie man damals kurz bei ProSieben sehen konnte bevor die ihren neuen Encoder künstlich ausbremsen mussten weil sich viele Empfänger verabschiedeten.

von Spacelab - am 26.01.2017 09:12
Mit Frontier Modulen gibt es definitiv keine Probleme aber einige Werksautoradios scheinen empfindlich zu sein, was die Muxkonfiguration und die PLs betrifft.
Als anfangs der private Hessenmux im PL-1A sendete gab es auch einige Meldungen hier im Forum wo kurze Aussetzer, als Vermutung, auf den PL geschoben wurden.

Fuer PL-1A ist langfristig sowieso kaum Platz in den Muxen, mit Ausnahme einiger lokalmuxe vielleicht. Die Audiodatenrate sollte aber bis 120kbps nirgendwo Probleme bereiten, bzw. da wuerde ich dann wirklich als Programmanbieter keine Ruecksicht auf Exoten nehmen.

von Nordlicht2 - am 26.01.2017 09:22
Ob das damals in Hessen wirklich auf die EEP-1A Konfiguration zurückzuführen war müsste man erstmal wieder ordentlich testen. Das war ja damals, wie du ja auch schon sagtest, nur eine Vermutung.

Zitat
Nordlicht2
Fuer PL-1A ist langfristig sowieso kaum Platz in den Muxen, mit Ausnahme einiger lokalmuxe vielleicht.

Das sehe ich genauso. EEP-1A in Verbindung mit höheren Datenraten wird wohl kaum vorkommen. Dafür ist es zu unwirtschaftlich. Langfristig gesehen wird man sich wohl auf EEP-3A und 2A einschießen. In einem Piratenforum wurde auch mal ausgetestet was so geht und angeblich gab es bis rund 200CUs mit keinem Modul Probleme. Also 128kb/s in EEP-1A bzw. 200kb/s in EEP-2A, gehen auf jeden Fall. Ich würde mir da also keinen allzu großen Kopf machen.

von Spacelab - am 26.01.2017 12:37
Was sagen denn die DAB+ Spezifikationen? Sollte nicht die höchste zulässige Datenrate zusammen mit dem höchsten Fehlerschutz funktionieren?

Die 144er Rate von BR-Klassik war noch für keines meiner Geräte ein Problem bisher.

von radneuerfinder - am 26.01.2017 13:08
BR Klassik sendet ja auch nur mit EEP-3A. Das sind also nur 108CU.

Bei DAB(alt) mussten die Empfänger jeden Fehlerschutz bis 192kb/s unterstützen. Bei DAB+ wären das beim höchsten Fehlerschutz EEP-1A 288CU. Was jetzt bei DAB+ als höchste Datenrate festgelegt wurde weiß ich so aus dem Stehgreif gar nicht. Der Audio CODEC selbst hat ja keine Grenze nach oben. AAC kann ja auch lossless Encodieren. Nehmen wir der Einfachheit halber mal an man hat sich an MP3 orientiert und die höchste Datenrate auf 320kb/s über DAB+ festgelegt. Das wären mit EEP-1A 480CU. Wenn es nicht gerade einen Softwarebug gibt dürfte das aber selbst für leistungsschwache CPUs mit geringem RAM Speicher kein größeres Problem sein. Ich vermute da auch weniger ein Hardwareproblem, als viel mehr unsauber programmierte Software mit viel viel Optimierungspotential.

von Spacelab - am 26.01.2017 13:24
Es gab ja auch genug DAB-Alt-Empfänger, die Bitraten über 192kbps nicht dekodieren konnten (Pure Evoke 1 von 2001 z.B.). WDR 3 sendete damals mit 224kbps.

von Japhi - am 26.01.2017 15:01
Das mussten sie ja auch nicht. 224kb/s war außerhalb des Standards.

von Spacelab - am 26.01.2017 15:06
Zitat
Spacelab
Das mussten sie ja auch nicht. 224kb/s war außerhalb des Standards.


Nö nach meinen informationen ist standardisiert bei DAB+ (AAC) bis192 kbps. bei DAB(alt) dagegen bis 256 kbps. In Spanien sendet Radio Clasica mit 224 kbps in mp2. Keine Probleme bei aktuellen Geräten, nur uralte Schicken steigen aus, oder sind dann sehr träge, die erfüllen die Norm nicht.

mp2: 32- 48 – 64 – 96 – 128 – 160 – 192 – 256

AAC: 8 – 16 – 24 – 32 – 40 - 48 - 56 – 64 – 72 – 80 – 88 – 96 – 104 – 112 – 120 - 128 – 136 – 144 – 152 – 160 – 168 – 176 – 184 – 192

von Kohlberger91 - am 26.01.2017 17:13
Ich hab eben mal hier auf der Arbeit in den TechSpecs geblättert und DAB(alt) wurde tatsächlich nur bis 192kb/s spezifiziert. Bei DAB+ gibt man hingegen nur die CUs an die unterstützt werden müssen. Das wären dort 192CU. Bei EEP-1A wären das 128kb/s, EEP-2A 192kb/s und bei EEP-3A schon irgendwas über 224kb/s.

Als damals bei uns im L-Band (LG) mal sogar mit 256kb/s gesendet wurde gabs eigentlich keine größeren Probleme. Nur mein Albrecht Empfänger mit Radioscape Modul wurde von der Bedienung her schwer zäh und fraß noch mehr Batterien wie eh schon.

von Spacelab - am 26.01.2017 18:20
hmmm, laut alten Dokumenten von Instituts für Rundfunktechnik (IRT) ist bis 256 kbps in mp2 spezifiziert.
[attachment 8717 BitratenDAB.JPG]
Es hieß auch mal das 320 oder 384 kbps wie bei DVB-S über DAB nicht möglich sei, da dort nur bis 256 kbps spezifiziert wäre.

von Kohlberger91 - am 26.01.2017 18:41
Die Limits stehen alle in den Specs:

MP2:
Maximal 384 kBit/s nach EN 300 401 und auch entsprechender Decoder-Support Pflicht.

AAC:
Maximal 192 kBit/s nach TS 102 563.

Grundsätzlich (z.B. Datenkanäle):
Maximal 1824 kBit/s (EEP 4-B mit 855 CUs) nach EN 300 401.

MP2 werde ich mal testen; AAC wird ein Problem, weil der ODR-Encoder ab ca. 144 kBit/s momentan nur Mist ausgibt.

von Basic.Master - am 26.01.2017 19:21
Habe jetzt vier verschiedene Radios getestet - alle spielen MP2 384 kBit/s (mit UEP-3) ab.

von Basic.Master - am 26.01.2017 19:55
Hm... Also ich hab hier nur das Paper der ARD vorliegen und da steht bei DAB(alt) 192kb/s. Ich kann mich auch noch daran erinnern das es oberhalb schon Radios gab die herumzickten. Moderne DAB+ Empfänger hingegen dürften sich vom verhältnismäßig harmlosen MP2 CODEC kaum beeindrucken lassen.

von Spacelab - am 26.01.2017 20:36
Was für ein Paper ist das genau?

In der ersten EN 300 401 von 1995 sind dieselben Bitraten für MP2 drin. Wenn man Mono benutzt, besteht halt eine Beschränkung auf 192 kBit/s.

von Basic.Master - am 26.01.2017 20:44
Boah so aus dem Kopf... Wenn ich morgen bei den Technik Jungs vorbei komme schau ich nach. Ich hatte mein Handy nicht dabei sonst hätte ich einfach ein Bild gemacht.

von Spacelab - am 26.01.2017 20:53
Das mit die 192 wird wohl eine Empfehlung sein, damit auch Radios laufen die nicht nach Normkonform über 192 kbps reibungslos funktionieren.

von Kohlberger91 - am 26.01.2017 20:53
Zitat
Basic.Master
Was für ein Paper ist das genau?

In der ersten EN 300 401 von 1995 sind dieselben Bitraten für MP2 drin. Wenn man Mono benutzt, besteht halt eine Beschränkung auf 192 kBit/s.


Genau! Hier steht's drin (S. 5): 192 kbit/s gilt für mono, für stereo dann das Doppelte, also 384 kbit/s.

Bedenkt, dass in den Anfangszeiten von DAB (wir reden hier von Mitte der 90er) noch sehr hohe Bitraten geplant waren. Damals ging man wohl von 256 kbit/s für jedes Programm aus; was später daraus wurde, ist bekannt. MP2 ist halt erst ab 192 kbit/s wirklich gut, also wäre es unlogisch gewesen, hier schon die Grenze zu machen.

von GLS - am 26.01.2017 21:28
Geht es tatsächlich um DAB+-Empfänger oder Autoradios mit Internetempfang. Die sollen Probleme mit höheren Bitraten haben.

von Seltener Besucher - am 26.01.2017 23:12
Ich vermute wie Kohlberger91 dass das mit den 192kb/s MP2 lediglich eine Empfehlung war. Denn bis dahin spielte noch jeder Empfänger problemlos. Darüber klappte das nicht immer.

von Spacelab - am 26.01.2017 23:28
Das IRT hatte ja mal explizit einen DAB-Testkanal mit 256kbps/MP2 laufen, vermutlich um genau das auszutesten.

von Habakukk - am 27.01.2017 08:02
Klingt irgendwie lächerlich, dass manche Radios aussteigen...

Aber nachdem ich es selbst erlebt habe, dass 96 kBit LC katastrophal klingen können und daher RTV Slovenija auf 128 kBit gehen musste, kann ich mir denken, dass es mit DAB auch so ähnlich war.

von andimik - am 27.01.2017 08:07
Zitat
Habakukk
Das IRT hatte ja mal explizit einen DAB-Testkanal mit 256kbps/MP2 laufen, vermutlich um genau das auszutesten.

Ja das ist anzunehmen. Macht ja auch Sinn.

Wie schon gesagt, das sich Empfängerhersteller nicht immer an die gesetzten Standards halten ist leider schon fast normal. Versuch nur mal einen DVB-S2 Receiver zu finden der AAC Ton in 5.1 wiedergeben kann. Wie man ja bei den diversen Radiokanälen hören kann machen verschiedene Receiver ja sogar schon bei normalem Stereo Probleme.

Ich habe mal gehört das der SR anfangs, für seine 3 Hauptprogramme, über DAB(alt) mit 224kb/s senden wollte, es aber gelassen hat weil es Probleme mit vereinzelten Empfängern gab. Keine Ahnung ob das stimmt. Das war noch weit vor meiner Zeit.

von Spacelab - am 27.01.2017 08:32
Es gibt da wohl mehrere Knackpunkte.

Das eine ist der benötigte Speicher (bzw. die Geschwindigkeit) fürs Viterbi-Backtracking (Fehlerkorrektur), das trifft auch schon DAB-alt. Gab AFAIR auch nur einen Empfänger, der wirklich alles dekodieren konnte, das war das DFIRE von Bosch (DR-Box1...). Alle anderen aus der Zeit hatten AFAIR Probleme wegen dem Viterbi.

Dann ist es bei DAB+ ja so, dass aus 5 DAB-Frames ein AAC-Superframe zusammengesetzt wird. Allerdings sind das immer noch nur ein paar KByte. Da kann ich mir nicht vorstellen, dass das irgendwie Probleme machen soll. Schon eher aber die Reed-Solomon-Fehlerkorrektur darauf. Das ist recht rechenaufwendig, allein zur Berechnung der Syndrome brauchts 10 Operationen (XOR, Modulo, 2-3*Memoryzugriff) pro Empfangs-Byte. Die Fehlerkorrektur bei erkannten Fehlern kommt dann noch dazu. Evtl. reicht dann die Zeit inkl. potentieller Fehlerkorrektur bis zum nächsten Superframe nicht mehr aus, wenn der Superframe zu gross ist.

Dass es an der AAC-Rate an sich liegen soll, kann ich mir wieder weniger vorstellen.

von Georg A. - am 27.01.2017 13:53
Kleine technische Anmerkung:
Viterbi alleine braucht nicht viel Speicher, weil das über eine Reihe von Schieberegistern u. Logikgatter realisiert werden kann u. da ist kein zusätzlicher Speicher notwendig.
Was bei DAB allerdings hinzukommt ist das Interleaving.
Für Frequenz- und Zeitinterleaving müssen das schon einige kByte zwischengespeichert werden.

Nachtrag: Natürlich nicht nur Schieberegister sondern auch ein paar Logikgatter (AND, XOR, Not)

von Winnie2 - am 27.01.2017 15:15
Hm, man muss doch beim Erstellen der Metriken im Vorwärtslauf die Decisionbits speichern, die man dann im Traceback rückwärts wieder braucht. Zumindest habe ich das so gemacht... Wenn man das ein einem Rutsch macht, gibt das schon einiges an Speicher. AFAIK gibt es Optimierungen, die da überlappenen Blöcken arbeiten, die sind aber langsamer.

Aber stimmt schon, das Interleaving kommt auch noch dazu. Aber mal ehrlich: Bosch hat das schon 1998 in einem ASIC mit einem externem SRAM+Flash geschafft, da kann das doch jetzt echt kein Problem mehr sein...

von Georg A. - am 27.01.2017 21:42
Ich denke mal dass es davon abhängt wie viele CU ein DAB Empfangsgerät maximal verarbeiten kann.
Die Anzahl der CU pro Mux ist zwar konstant, aber die Anzahl der CU pro Service muss begrenzt sein damit ein DAB-Radio diese verarbeiten kann.
Möglicherweise erreichen ältere Geräte da schneller Grenzen.
Seit der Spezifikation von den 3 DMB/DAB-Profilen, wovon das Profil 3 in Europa praktisch keine Rolle spielt weil die für Videoübertragung vorgesehen ist, sollten alle normgerechten Empfangsgeräte mit den in Profil 1 festgelegten Werten umgehen können.
Probleme könnten(?) Geräte haben die in der Übergangsphase hergestellt wurden haben, also Geräte die bereits für DAB+ ausgelegt sind aber vor der Definition der Profile gefertigt wurden.
Ältere DAB-Empfangsgeräte können mit DAB+ Audioservice (AAC-Codec) ohnehin nichts anfangen.

Zum Thema Viterbi. Viterbi kann auf unterschiedliche Art und Weise implementiert werden. Da gibt es mehrere Verfahren (u.a. Soft- u. Hard-Entscheidung)
Und es gibt Viterbi Decoder die ohne RAM auskommen.
https://ece.uwaterloo.ca/~elmasry/papers/Memoryless%20veterbi%20decoder.pdf

von Winnie2 - am 27.01.2017 22:37
Als Ergänzung (320kbps mp2): http://radioforum.foren.mysnip.de/read.php?35326,915434

von Japhi - am 28.01.2017 16:25
Vielen herzlichen Dank für alles, was hier zusammengetragen wurde! Das ist sensationell und eine große Hilfe. Mangels Geräte-Zoo konnte ich dazu nämlich nullkommagarnix sagen.

von Chris_BLN - am 28.01.2017 19:29
Es gibt Fahrzeuginfoteinmentsysteme, die sind ab einer bestimmten Anzahl an empfangbaren DAB Ensembles abgestürzt. In Deutschland entwickelt, kein Problem beim Test. In London mit mehreren Multiplexen dann abgestürzt.

Der Fehler lag aber ganz woanders (MOST Bus) und nicht im DAB Tuner. Ist auch per Softwareupdate mittlerweile behoeben worden :-)

von raeuberhotzenplotz1 - am 30.01.2017 12:02
Müssen dann wohl von Porsche, VW oder Mercedes eingesetzt worden sein? In Rüsselsheim, Ingolstadt oder München gibts doch eigentlich genug Muxe ;)
Oder war das Problem schon zwischen DAB-Modul und Infotainment-Zentralrechner?

von DH0GHU - am 30.01.2017 13:31
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.