USB-Tuner für Digitalradio DAB+ (und DVB-T)

  • Hier baut es auch erst nach folgenden "Hotfix" und nach eines Kopieren/Linken der Datei "gruel_common.i"



    #> ln -s /usr/include/gruel/swig/gruel_common.i /usr/include/gnuradio/swig/gruel_common.i
    Siehe auch http://www.ruby-forum.com/topic/4040797


    #> apt-get install gnuradio-dev libcppunit-dev libgnuradio-core3.5.3.2 swig
    #> autoreconf -i
    #> ./configure
    #> make



    @andr: rtl_fm funktioniert doch ganz passabel, wenn man -W für Wide FM mit angibt.


    Danke für den Hinweis, mein "Checkout" ist wohl zu alt gewesen, verantwortlich ist wohl der Commit vom 23.10.2012 (http://cgit.osmocom.org/cgit/r…7f186e19746658ade01632589)

  • danke! An dem fehlenden Link hats gehangen. Das bringt mich auf jeden Fall einen Schritt weiter.
    Ich habe allerdings statt der for Schleife oben bei der Initialisierung von CRC den Vektor übegeben, dann funktioniert es auch, also:
    char CRC = {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};


    Wenn ich allerdings autoreconf -i mache, funktioniert das ./configure nicht mehr. Dann bekomme ich nur noch:
    checking build system type... configure: error: cannot guess build type; you must specify one


    Ohne das autoreconf konnte ich das Paket aber inzwischen bauen und installieren, jetzt muss ich nur noch die Python Skripte anpassen und hoffen, dass ich wenigstens die Senderlabels angezeigt bekomme.

  • ich habe die LabelRealtime angepasst, aber viel mehr als durchrauschende CRC Fail Messages ist nicht zu sehen. :(


    Warum wird eigentlich ein Resampling von 2000 MS/s auf 2048 MS/s durchgeführt? Warum wählt man nicht gleich die richtige Samplerate?


    Edit: Also das Resampling müssen wir scheinbar nicht machen, das UHD kann nur 2000 MS/s und deshalb muss dieses Resampling durchgeführt werden, wir können gleich mit 2048 MS/s abtasten.

  • Hallo,


    ich beschäftige mich auch schon einige Zeit mit DAB+ unter Linux. Ich möchte meinen CarPC damit aufrüsten, denn DAB und die Beibehaltung des originalen Innenraums waren die Hauptgründe für den CarPC.


    Eine interessante, bereits funktionierende Software habe ich unter
    http://openmokast.org/home.html
    gefunden.
    Die Software kann mit einem Testdatenstrom getestet werden und ist relativ vielseitig einsetzbar (Datenein- und ausgabe per Stream, Steuerung per Telnet und DBus...)
    Leider haben Mplayer und FAAD den DAB+ Stream des "Testensembles" nicht dekodieren können. Einen Sundtek DAB/DVBT-Stick habe ich schon und warte auf die Implementierung der DAB-Funktionalität in den Treiber. Laut einer aktuellen Antwort in deren Forum könnte es bald soweit sein.
    Meiner Meinung nach müsste nichtmal ein Treiber für Openmokast geschrieben werden, es würde reichen, über IP der Software den kompletten Datenstrom zuzuführen.
    Dann fehlt "nur" noch die Dekodierung von DAB+.


    Gruß

  • 68070 : ich habe deinen Beitrag bereits vor einiger Zeit im Sundtek Forum gelesen.


    Hast du den Referenzstream schon einmal den Jungs von www.audiocoding.com, also den Machern des FAAD2 zukommen lassen? Es ist durchaus möglich, dass die noch einen Bug in ihrem Code haben.


    Ansonsten wäre noch interessant, ob der FAAD2 überhaupt LATM Streams dekodieren kann, ansonsten müsste man den LATM Stream erst noch in einen LAOS Stream konvertieren.


    Ich hänge ja bereits viel weiter Vorne in der Dekoderkette fest. Weißt du mit welcher HW die Openmokast zusammen spielen soll, insbesondere welcher SDR Chip?


    Fraunhofer hatte ich gelesen, wollte doch auch mal einen DAB Decoder für Linux herausbringen.

  • Den Datenstrom habe ich noch nicht weiter analysieren lassen, ich wollte erst den Empfang hinbekommen um einen "echten" Stream liefern zu können.
    In Bayern habe ich viele DAB+ Programme von denen ich Proben erzeugen könnte.


    Openmokast unterstützt soweit ich das überschaue nur einige ältere Empfänger, die leider nicht mehr erhältlich sind:


    Terratec DR Box 1
    Albrecht DR 403 baugleich MTech UDR-A3L...
    Fraunhofer PC-Card 563


    Das interessante ist aber die Möglichkeit, einen ETI-Datenstrom (das Multiplex) per TCP zuzuführen.
    Dazu muss das Signal zuerst demoduliert werden...


    Die Meldung von Fraunhofer ist auch schon recht alt, wenn ich mich nicht irre. Darauf hoffe ich nicht mehr.

  • Mal aus der Perspektive von jemand der jetzt neu DAB+ im Autoradio hat:
    - Egal wo man in Deutschland ist, dürfte man mehr verschiedene Sender über DAB+ bekommen als über UKW
    - mit ner vernünftigen Antenne am Auto funktioniert selbst in schwächeren Gebieten der Empfang recht gut
    - in Bayern klingt DAB+ richtig interessant (48 (!!) Stationen)
    - bei erst 2 belegten Transpondern ist da noch richtig Luft nach oben


    negativ:
    - viele private Stationen klingen auf DAB+ sehr ähnlich zu UKW - ich bin nicht sicher ob das an falschen Einstellungen der Sender liegt
    oder hier Kompressionsartefakte durchschlagen (schlechter als UKW empfinde ich es nicht)


    Alles in allem sehr interessant.


    Momentan ist mir nicht ganz klar: Soll DAB+ innerhalb des DVB Framework kommen ? Soll es es ein eigenes geben ? In jedem Fall sollte das auf linux-media ML diskutiert werden oder ?
    Die beste Hoffnung hat man IMHO im Moment das Sundtek irgendeine Abkürzung geht um es zur Verfügung zu stellen (zB DAB+ -> Netzwerkstream in deren Softwarestack, auch Treiber genannt :))
    Hat jemand schonmal linux-media angeschrieben und nach DAB+ gefragt ? Ich habe nichts aktuelles finden können.

  • naja, momenten haben wir ja noch nicht mal den Rohdatenstrom von DAB.


    Die OFDM Demodulierung muss ja komplett in Software alsso als DSP erfolgen, wenn wenigstens schon einmal die Demodulierung beim RTL2832 funktionieren würde wären wir schon einen großen Schritt weiter.


    Ich bin mir auch nicht sicher, ob man bei einem SDR Empfänger die Demodulierung in den Kernel setzen sollte.

  • Unter


    http://dl2stg.de/stefan/dab/gr-dab.tgz


    liegt eine Erweiterung für GNURadio, die bei mir DAB+ live decodiert.


    Das ganze funktioniert auch mit dem RTL2832-USB-Stick, wobei das Teil hier in Berlin durch diverse starke UKW-Sender Probleme hat. Man hat überall IM-Mischprodukte. Vorraussetzung ist GNU-Radio (aktuell aus git), libfec (ist im tgz-File enthalten) und libfaad2. Für libfaad liegt ein Patch bei, damit man aus dem AAC-Datenstrom die Zusatzdaten (DLS(Radiotext), Bilder, etc.) bekommt. Wenn man den Patch anwendet kann man in dab_audio_decoder.cpp den auskommentierten Abschitt wieder aktivieren und bekommt dann den Radiotext auf die Konsole.


    Ansonsten kann die Erweiterung wie üblich mit "cd build", "cmake ..", "make" und "make install" übersetzt werden. Das Combine.py-Script startet die Suche nach den den Sendern im Packet, Die Frequenzeinstellung ist sehr kritisch und muss auf +-20 Hz stimmen, dazu einfach mal am Regler schieben. Der Kanal kann im Skript eingestellt werden. Nun kann das Fenstger geschlossen werden, es wird nach dem Sender gefragt und die Dekodierung wird gestarte (Frequenz nochmal fein einstellen!). Das ganze ist noch sehr experimentell: einige Sender benutzen eine Samplereate von 32k, das wird nicht berücksichtigt, bei schlechen Empfang kommt es auch hin und wieder zum Absturz, DAB (ohne +) wird nicht live decodiert und nur in eine Datei geschrieben, ..


    Aber man kann es schon benutzen.

  • stego :


    vielen Dank dafür. Habe leider noch nicht die richtige Frequenz gefunden. Wie groß ist denn dein Offset? Ich bin mit dem Slider in 20er Schritten in beide Richtungen gegangen bis jeweils -200 und +200 aber ohne Erfolg.

  • ach ja bevor ich es vergesse, ist evtl. auch der Grund warum es hier nicht läuft.


    Ich habe Probleme mit dem fec_3.0.1-2 Patch.
    Wenn ich diesen anwende funktioniert das ./configure nicht mehr. Im Makefile werden dann die Variablen wie nicht mehr substituiert, so bleibt z.B. folgendes stehen, was später zu einem Fehler beim make führt:


    makefile:
    AR=@AR@
    RANLIB=@RANLIB@
    DLLTOOL=@DLLTOOL@
    RUN_ENV=@RUN_ENV@


    Oder fehlt auf meiner Seite noch ein Paket. automake und autoconf wurden installiert.

  • Wenn man die gepatchte libfec Version wie im README beschrieben mit "debuild -b -us -uc" baut sie bei mir, configure geht scheinbar bei der gepatchten version nicht mehr. Ist aber auch egal, notfalls kann man auch die RS-Fehlerkorrektur abschalten. Dazu die for-Schleife in lib/dab_dabplusdec.cc ab Zeile 187 auskommentieren. Es werden dann keine Fehler mehr korrigiert und man braucht die libfec nicht mehr.


    Ansonsten ist entweder der Empfang zu schlecht oder die Frequenz stimmt nicht. Zur Kontrolle des Empfangs kann man in GNURadio einfach mal eine OSMSdr-Source mit einem WX GUI Waterfall Sink verbinden. Wichtig ist es auch die ppm-Korrektur zu ermitteln, ab besten die Empfangsfrequenz gegen einen bekannten Träger testen, vorher den Stick warm laufen lassen. Im Combine-Script ist dieser Wert dann als freqCorr einzutragen. Die -102 passen nur zu meinem Stick.


    Der Slider ist nur zur Feinkorrektor nötig, wenn der Stick nicht so temperaturinstabil wäre, könnte man ihn auch weglassen. Den Slider innerhalb einiger Sekunden von einem Ende zum anderen ziehen, damit sollte man die passende Frequenz recht schnell finden. Der Empfang ist optimal, wenn 4 Wolken von Abtastwerten angezeigt werden, in jeden Quadranten eine (links oben, rechts oben, links unten und rechts unten).

  • Ansonsten ist entweder der Empfang zu schlecht oder die Frequenz stimmt nicht. Zur Kontrolle des Empfangs kann man in GNURadio einfach mal eine OSMSdr-Source mit einem WX GUI Waterfall Sink verbinden. Wichtig ist es auch die ppm-Korrektur zu ermitteln, ab besten die Empfangsfrequenz gegen einen bekannten Träger testen, vorher den Stick warm laufen lassen. Im Combine-Script ist dieser Wert dann als freqCorr einzutragen. Die -102 passen nur zu meinem Stick.

    also der Waterfal Sink ist ja nur da, um zu sehen ob überhaupt ein Eingangssignal vorliegt oder stellst du darüber auch den ppm Wert fest und wenn ja wie?
    Ich habe jetzt mal multimode einmal mit --ppm=0 und einmal mit --pm=-102 gestartet und jeweils den gleichen FM Sender getunt, kann da keine Spürbaren Veränderungen feststellen.

  • Hallo zusammen,
    ich habe jetzt auch einen Noxon rev. 2 hier, SDR# etc. funktioniert super.
    Gute Nachricht für Linux-User: In Kernel >=3.7 müssen nur noch die USB-IDs hinzugefügt werden, danach wird der Stick sofort als DVB-Gerät erkannt und DVB-T funktioniert! Der passende Patch ist auch schon für Kernel 3.8 committed worden, bald wird DVB-T also "out of the box" funktionieren.
    Wenn man dann wieder SDR machen möchte, heißt das natürlich vorher Module entladen / blacklisten.


    Nun wollte ich auch einmal DAB / DAB+ testen. Der Download von stego klappt leider nicht mehr. Gibt es ansonsten etwas Neues, oder das Modul auch woanders zum Download?

  • also bei mir funktioniert der Link. Evtl war ja der Server down, also einfach noch mal probieren.

    Danke! Der Fehler ist gefunden: Ich habe hier schon IPv6 im Dual-Stack. Der DNS-Server zur Adresse dl2stg.de ist praktischerweise so konfiguriert, dass er auf AAAA-Record-Anfragen mit "::1" (das ist bei IPv6 quasi 127.0.0.1, also localhost) antwortet, sowas habe ich auch noch nie gesehen...
    Jetzt, wo ich es weiß, kann ich natürlich direkt die IPv4-Adresse besuchen.
    Dann kann ich in den nächsten Tagen auch mal das DAB-Modul testen, danke nochmal!

  • Sonst niemand da, der das ganze mal ausprobieren möchte? ;)


    doch, hätte ich!
    aber ich möchte immer nur 1 Baustelle zur Zeit!
    Aber Danke für den Fortschritt!

    ASUS H87-PRO (Intel G3220+4GB RAM), 3x PCI-E CineS2 Dual DBS2 Ver. 5.5,
    64bit Ubuntu 16.04.4 LTS-Server, VDR 2.3.8 (mit DDCI2+streamdevserver+vompserver+vnsiserver)
    Diskless-Clienten: 4x Raspberry-Pi als Vomp-client in HD, 2x Fire TV (Stick und Box) mit Kodi per VNSI
    DVB-S-Radio per streamdev + externremux + ffmpeg + mpd auf Internetradios (mit Reciva-Barracuda-Chipsatz)