Qirx - DAB SDR-Software für Windows mit TII Auswertung

[HF-Hase]

Es klappt! Der entscheidende Parameter war -d01, vielen Dank!

Das Filter bringt nicht so viel wie erhofft, da es nicht besonders steil ist. Aber es entscheidet bei mir über lesen oder nicht lesen!
Anbei mal eine Übersicht über die fraglichen Kanäle, von links:
11A SWR
Lücke
11C DAB+ (NL)
11D NRW
12A VRT
12B ein Pirat?
12C NPO
Am schwierigsten ist 12A, der 50 dB Abstand zum Nachbarn hat. Aber mit 1,2 MHz Bandbreite kommt er rein.

@Clem: diese Situation dürfte für die AGC eine echte Herausforderung sein!

[Clem01]

Hallo HF-Hase

Der grüne Phosphor weckt nostalgische Gefühle! Sieht sehr vertrauenerweckend aus, aber stimmen die Zahlen? Wenn ich die Diskussion hier richtig lese, ist der 8-Bit Dynamikumfang (RTL-SDR) kleiner als 50dB. Soll aber keine Kritik an deiner Messung sein. Und deine Kurve ist möglicherweise eine Durchschnittsbildung, dann sieht das Ganze ja wieder anders aus. Absolute Zahlen sind ja auch weniger interessant, Hauptsache die Wirkung ist da!

Was interessant wäre, wäre eine Durchlasskurve des Filters, z.B. für dein starkes 11D (ich nehme an, im grünen Zentrum ist 11D). Wie sieht das an den Rändern aus?

Ich habe auch mal kurz gemessen, und bei mir sehe ich, dass es links, also zu kleineren Frequenzen hin, ziemlich gut funktioniert, rechts (also zu höheren Frequenzen) dagegen so gut wie nicht. Oldenburgers Messung sah auch am rechten Rand gut aus, mit deutlicher Abschwächung.

Hier die Screenshots. Ich habe das Filter mal absichtlich schmal auf 550kHz eingestellt, um zu sehen, was passiert.

rtl_tcp Ausgabe:

Hier Bayern3 mit Filter:

Und hier dasselbe ohne Filter:

Wie sieht bei dir der Empfang von 11C aus, mit und ohne Filter? Wird der 11D rechts abgeschwächt? Das unter dem Aspekt, dass Hayati angemerkt hatte, dass das Ganze möglicherweise nicht symmetrisch ist.

Vielleicht wäre für dich auch nochmal ein Test mit dem Signalgenerator möglich?

Und was die AGC anbetrifft? Die ist doch jetzt aus dem Schneider? Oder nicht?

[oldenburger]

Hallo Clem01,

ich habe das gleiche Ergebnis bekommen wie Du. Wenn ich eine Bandbreite < 1,5 MHz einstelle, wird die Durchlasskurve des Filters unsymmetrisch. Je niedriger die Bandbreite, desto stärker. Es scheint mir so, als wenn in der Formel die Variable int_freq falsch berechnet würde. Der DAB-Kanal liegt dann nicht mehr in der Mitte des Filters, sondern weiter am Rand. Die Breite des Filters scheint dabei immer > 1 MHz zu sein.

HF_Hase hat einen E4000, da funktioniert das alles vielleicht viel besser.

Trotzdem ist diese rtl_tcp-Version von Hayati für mich ein großer Gewinn. Denn jetzt ist es mir endlich möglich, Qirx auch "live" zu benutzen und nicht nur vom File. An der neuen Version 2 von Qirx gefällt mir besonders die neue "Channel Impulse Response", wo man direkt die Entfernungen der empfangenen Sender, relativ zum stärksten Sender, ablesen kann. Das funktioniert jetzt sogar, wenn der stärkste Sender nicht der nächste ist. Vielen Dank dafür!
Die alte Version von rtl_tcp lief bei mir einfach nicht, warum auch immer.

[HF-Hase]

Hallo Clem,


das Ganze wird ja immer interessanter!

Der grüne Phosphor zeigt die mittlere Leistung der DAB-Signale an (Videofilter = 100 Hz), aber die Relationen stimmen sehr genau. Drehe ich die Yagi leicht, kann ich den Unterschied 11D/12A auf gut 40 dB verringern.

Es ist richtig, mit 8 Bit sind maximal 48 dB möglich. Aber das darf man sich nicht ganz so statisch vorstellen, wie es oft dargestellt wird. Damit sind wir mitten in der Signaltheorie: Mein Nutzsignal (12A) wird durch das unkorrelierte Rauschen des 11D überlagert. Das Ergebnis wird anschließend über div. Fehlerkorrekturen teilweise wieder korrigiert, was das S/N wieder verbessert... und das kann ich jetzt nicht mehr genau ausrechnen
Was aber in jedem Fall passiert: Durch die kleinere Bandbreite wird ein Teil des Nachbarkananls (11D) weggefiltert, bevor es den AD-Wandler sieht. Damit ist am Wandler das S/N besser als vorher - und es klappt!

Genau wie du hab ich übrigens als erstes mit schmalen Filtern gespielt und auch die Unsymmetrie beobachtet. In irgendeinem Text meine ich gelesen zu haben, dass das Filter aus einem Hoch- und einem Tiefpass besteht. Das würde das Verhalten erklären. Nur passt das nicht zu den Bildern von @Oldenburger: was könntest du anders gemacht haben? Gibt es verschiedene Versionen der rtl_tcp.exe?

Wie meinst du das mit der AGC? Mit Filterung im R820T müsste die besser klappen als vorher, aber bei meinem Extrem hängt sie sich immer noch auf. Da werd ich aber dran bleiben und mal versuchen, mehr über die Möglichkeiten von automatischer und manueller AGC zu verstehen. Und wenn ich wieder etwas Zeit hab, versuche ich mal weitere Messungen mit dem Signalgenerator. Meine neueste Idee: Im Stick das ZF-Signal zwischen R820T und RTL-Chip abgreifen und messen.

Aber wie schon gesagt: es gibt halt viel OT! (ja, zB Frühstückseier)

[Habakukk]

Bei mir mit dem sehr starken 11D und dem eher schwachen 11C bringt es leider nicht allzu viel.

So schaut es mit Andis DAB-Player aus, wenn ich den Original-Realtek-Treiber nutze (Empfang mit Audio)

Das ist dann mit dem Zadig-Treiber / rtl_tcp mit Qirx-Autostart (kein Audio)

Das ist dann mit manuell gestarteter rtl_tcp mit 1,5 MHz Bandbreite, praktisch kaum ein Unterschied:

Und so schaut es mit extremen Einstellungen (0,5 MHz Bandbreite) aus: auf der rechten Seite (also zum 11D hin) tut sich nahezu nichts, aber am Anfang des 11C ist schon ein gutes Stück ziemlich abgeschwächt! Das bestätigt eure Aussagen, dass sich das ganze nicht symmetrisch auswirkt:

Und so, wenn ich mit Andis DAB-Player eine RAW-Datei aufnehme und in Qirx abspiele (quasi identisch zu Andis DAB-Player, also mit Audio und ähnlichem SNR):

Es liegt bei mir offenbar gar nicht so sehr an der Bandbreite, und Qirx scheint mit dem Original-Datenstrom vom Realtek-Treiber genauso gute Ergebnisse rauszuholen wie Andis Player.
Es liegt da wohl auch eher an der AGC... Man sieht bei der RAW-Datei, dass das ganze um einige dB nach oben gerutscht ist...

[HF-Hase]

Hallo Habakukk,

diese Beobachtung hab ich auch gemacht: in der ganzen Auswertung, die hinter der AD-Wandlung passiert, sind der DAB-Player und QIRX absolut identisch!
Der Unterschied muss also zwischen Antennenanschluss und AD-Wandler-Eingängen liegen. Nur: wo?
Vielleicht bringen ja meine Ideen von vorhin neue Erkenntnisse.

[Austria MV]

Bei mir das Gleiche wie bei Clem01...

Getestet mit
5C ca 10 - 11 dB SNR
5D ca 15 - 16 dB SNR

Während beim hören von 5C kein Filtereffekt beim 5D erkennbar ist.
Bei Reduktion der Bandbreite leidet die linke Seite des Nutzsignal.

Bei Nutzung von 5D ließ sich der 5C dämpfen.

Mal sehen ob sich da noch die rtl_tcp.exe etwas an die Bedürfnisse von DAB anpassen lässt?

[hayati]

Wenn ich eine Bandbreite < 1,5 MHz einstelle, wird die Durchlasskurve des Filters unsymmetrisch. Je niedriger die Bandbreite, desto stärker. Es scheint mir so, als wenn in der Formel die Variable int_freq falsch berechnet würde.

Auf welche Formel beziehst Du Dich? In welcher Software? Sachdienliche Hinweise sind gern gesehen!

Der Code zum einstellen der IF-Filter wurde wohl initial von Leif Asbrink (SM5BSZ) erstellt und von Alexander Kurpiers (DL8AAU) ggf. überarbeitet - jedenfalls auf github gestellt. Von letzterem habe ich den Code für https://github.com/librtlsdr/librtlsdr übernommen und über API die eingestellte Bandbreite auch abfragbar gemacht. Das ist jetzt ein paar Jährchen her ..

Die nominelle Bandbreite des Filters ist immer relativ klein .. und gibt die symmetrisch um 0 (bzw. eingestellte Frequenz) verfügbare Bandbreite an. Asymmetrisch liegt eine größere nutzbare Bandbreite vor.

Die alte Version von rtl_tcp lief bei mir einfach nicht, warum auch immer.

In älteren bzw. anderen librtlsdr repositories fehlen die USB IDs zur Erkennung von manchen kompatiblen Dongles.

Genau wie du hab ich übrigens als erstes mit schmalen Filtern gespielt und auch die Unsymmetrie beobachtet. In irgendeinem Text meine ich gelesen zu haben, dass das Filter aus einem Hoch- und einem Tiefpass besteht. Das würde das Verhalten erklären.

Ja, das mit dem Hoch- und Tiefpass ist zumindest für den R820T und R820T2 Tuner richtig.
Für andere Tuner müsste man genauer im Quellcode nachsehen.

Gibt es verschiedene Versionen der rtl_tcp.exe?

Ja, definitiv:

Die Basis ist osmocom und oft das Repository von
* Steve Markgraf auf https://github.com/steve-m/librtlsdr

Dann gibt es einen Haufen interessanterer Erweiterungen, wie z.B. die von
* Alexander Kurpiers (DL8AAU) https://github.com/dl8aau/librtlsdr
oder
* Kyle Keen https://github.com/keenerd/rtl-sdr
und viele weitere

Da osmocom leider keinerlei oder kaum Änderungen re-integriert (warum auch immer) .. gibt es unter
https://github.com/librtlsdr/librtlsdr
den Versuch die Erweiterungen wieder zu bündeln.

Wie meinst du das mit der AGC? Mit Filterung im R820T müsste die besser klappen als vorher, aber bei meinem Extrem hängt sie sich immer noch auf. Da werd ich aber dran bleiben und mal versuchen, mehr über die Möglichkeiten von automatischer und manueller AGC zu verstehen.

Die AGC ist leider ein ziemlich leidiges Thema. Ich hatte das schon vor vor einiger Zeit grob untersucht. Siehe
https://codingspirit.de/RTL-Dongle-prof ... ien-DE.pdf

Fazit ist/war jedenfalls, dass eine geringere Bandbreite der AGC hilft, damit diese in vielen Fällen nicht mehr übersteuert. Für den damaligen Untersuchungsgegenstand war es völlig ausreichend die Bandbreite einfach manuell zu reduzieren, dann war i.d.R. alles wieder gut
Für DAB braucht man aber schlicht die höhere Bandbreite! Nicht so gut

Neuere Erfahrungen - von den Nutzern des FMLIST-Scanner - zeigten leider, dass in etlichen Fällen die AGC des R820T/T2-Tuners trotz kleiner Bandbreiten-Einstellung total übersteuert. Hinzu kam, dass die AGC des E4000 Tuners praktisch total unbrauchbar ist.

Bislang einziger Ausweg: manuelle Regelung der Gain!
Mobil ist dies aus praktischen Erwägungen nicht möglich. Siehe https://www.youtube.com/watch?v=Wh16MugccJQ

Daher arbeite ich "derzeit" an einer Software-AGC, damit man die kaputte Tuner-AGC nicht nutzen muss. Kann sich nur noch um Jahre handeln ..

Und wenn ich wieder etwas Zeit hab, versuche ich mal weitere Messungen mit dem Signalgenerator. Meine neueste Idee: Im Stick das ZF-Signal zwischen R820T und RTL-Chip abgreifen und messen.

Würdest Du mir die Ergebnisse auch zukommen lassen?

[hayati]

Mal sehen ob sich da noch die rtl_tcp.exe etwas an die Bedürfnisse von DAB anpassen lässt?

Wenn jemand eine konkrete Idee hat ..

Alternativ könnte man in der DAB Software versuchen auf die Asymmetrie einzugehen!

@Clemens: meinst Du das wäre möglich ohne einen der DAB Nutzträger komplett abschreiben zu müssen, weil jetzt der DC drin liegt? Man könnte dem ein Stück weit vorsorgen, dass der DC exakt zwischen 2 Unterträgern liegt ..

[Clem01]

Damit sind wir mitten in der Signaltheorie:

Da werde ich mich auf keinerlei Diskussion einlassen, da das für mich nicht gut ausgehen würde!

So schaut es mit Andis DAB-Player aus, wenn ich den Original-Realtek-Treiber nutze (Empfang mit Audio).

Das wäre sehr interessant: wie arbeiten die Original-Treiber bezüglich Bandbreite. Die Dongles waren doch auch für DAB gedacht, und da sind möglicherweise auch entsprechende Filtereinstellungen drin, die vielleicht nicht unsymmetrisch sind. Wo sind die russischen Hacker, wenn man sie braucht?

Zum rtl_tcp "Zoo":

Der rtl_tcp, den ich verteile, ist von 2014, also relativ betagt. Leider erscheint da beim Start weder ein Autor, noch eine Versionsnummer oder sonstwas, was auf den Urheber schliessen lässt. Meine Erfahrungen:

• Die Version des ursprüngliche Erstellers (wohl Steve Markgraf) funktioniert. Steve habe ich versucht, bezüglich der Bandbreitengeschichte zu kontaktieren, leider ohne Erfolg.

• Mit der Version von DL8AAU habe ich einen rebuild gemacht: Dieser funktioniert nicht bei mir, und zwar genau wegen der Bandbreiteneinstellung. Es kommt hartnäckig ein Fehler von -9, bei einem der vielen obskuren I2C Kommandos. Ich bin aber mit dem ursprünglichen Ersteller (Leif, Autor von linrad) in (sehr positivem!) Kontakt, und ich werde das weiter verfolgen.

• Die Version von Kyle Keen funktioniert. Diese habe ich bei meiner Untersuchung über phasenstarr gekoppelte Dongles eingesetzt (dort s. ganz unten in "Conclusion"). In dieser Version kann man das "dithering" ausschalten (was das genau ist, siehe oben bezüglich Signaltheorie). Das "dithering" bedingt offensichtlich eine langsame Phasendrehung im Minutenbereich.

• Und die Version von Hayati, die hier diskutiert wird, funktioniert ebenfalls. Mein Win64 Build steht allerdings noch aus. Dieser wäre nötig, um die Bandbreiteneinstellung zur Laufzeit vornehmen zu können. S. dazu auch Oldenburgers Bemerkung früher hier im Thread. Leider kann der -w Parameter nicht mehr in der qirx.config eingestellt werden, da die Kommandozeile jetzt dynamisch zusammengebaut wird (ich hatte das für eine gute Idee gehalten...). Beides (also Bedienung -w Parameter beim Start als auch dynamische Einstellung per TCP/IP-Kommando) wäre ohne allzu großen Aufwand möglich.

Alternativ könnte man in der DAB Software versuchen auf die Asymmetrie einzugehen!

Davon bin ich - ehrlich gesagt - nicht so sonderlich begeistert. Die Beschränkung auf TCP/IP als Frontend hat ja genau den Zweck, solche Hardware-spezifischen Besonderheiten zu minimieren. Das ist sicher nicht gänzlich möglich. Derzeit sind die einzigen Besonderheiten die Gain-einstellung, die AGC (HW oder SW) sowie beim sdrplay die Möglichkeiten der höheren Abtastraten.

Wenn man Hayatis Vorschlag überlegen sollte, müssten erstmal belastbare Messungen (grüner Phosphor?) vorhanden sein, die dann auch klar verfizieren lassen, ob die Änderungen etwas bringen. Ich habe diese Möglichkeiten leider nicht.

Ich habe auch den E4000 probiert, da sah ich gar keinen Effekt. Auch hat rtl_tcp keine eingestellte Banbreite quittiert.

[hayati]

Das wäre sehr interessant: wie arbeiten die Original-Treiber bezüglich Bandbreite. Die Dongles waren doch auch für DAB gedacht, und da sind möglicherweise auch entsprechende Filtereinstellungen drin, die vielleicht nicht unsymmetrisch sind. Wo sind die russischen Hacker, wenn man sie braucht?

Hallo Clemens,
die Original Treiber arbeiten höchstwahrscheinlich NICHT auf dem "Behelfsausgang", der von den Entwicklern für Debug-Zwecke eingebaut wurde. Die ganze Open-Source basierte RTL-SDR Gemeinde hat nur dieses Behelfssignal in I/Q.
Mit NDA (oder dergleichen) mit Realtek haben die Original Treiber Zugang zum OFDM Demodulator, der ebenfalls im RTL2832 Chip sitzt .. und brauchen sich um vieles gar nicht mehr kümmern.
Die Filter-Beschränkung des Tuners bleibt zwar .. aber auf dem mit 28.8 MHz abgetasteten Signal tauchen dann keine Aliase mehr auf.

Alternativ könnte man in der DAB Software versuchen auf die Asymmetrie einzugehen!

Davon bin ich - ehrlich gesagt - nicht so sonderlich begeistert. Die Beschränkung auf TCP/IP als Frontend hat ja genau den Zweck, solche Hardware-spezifischen Besonderheiten zu minimieren. Das ist sicher nicht gänzlich möglich. Derzeit sind die einzigen Besonderheiten die Gain-einstellung, die AGC (HW oder SW) sowie beim sdrplay die Möglichkeiten der höheren Abtastraten.

Über RTL-TCP würde das noch gehen, indem man eine versetzte Frequenz anfordert .. und anschließend in Software zurück-mischt. Wenn man die Bandbreiten zur Laufzeit einstellbar macht, muss man "eh schon" auf den RTLSDR besonders eingehen.
ABER: Da die Asymmetrie erst bei kleineren Bandbreiten zuschlägt ist die Frage nach Sinnhaftigkeit für DAB durchaus offen.

[Clem01]

die Original Treiber arbeiten höchstwahrscheinlich NICHT auf dem "Behelfsausgang", der von den Entwicklern für Debug-Zwecke eingebaut wurde. Die ganze Open-Source basierte RTL-SDR Gemeinde hat nur dieses Behelfssignal in I/Q.

Jein. Die Open-Source Gemeinde hat auch das Interface analysiert (auf welcher Grundlage auch immer), mit dem der Chip kommandiert werden kann. Dazu gehört die Bandbreite. Wer sagt, ob das korrekt analysiert wurde und ob nicht in den erwähnten Treibern weitere Informationen stecken? Wenn das alles korrekt erkannt wurde, welchen Sinn sollen asymmetrische Bandbreiten haben?

[VillachDX]

Hier sind es auch ca. 1dB Unterschied zwischen Realtek-Treiber und rtl_tcp. Und es gibt bei mir im gesamten Band nur ein Signal auf 10D. Sonst nichts.

Eine Datei wurde mit Qt-DAB (rtl_tcp) auf einem RASPI aufgenommen. Die andere mit dem DABPlayer (Realtek-Treiber) auf einem Laptop.

(Es gibt bei Qt-DAB bereits eine Funktion zum Aufnehmen von 8bit-Dateien, wenn man rtl_tcp verwendet.)

[oldenburger]

hayati hat geschrieben:
Auf welche Formel beziehst Du Dich? In welcher Software? Sachdienliche Hinweise sind gern gesehen!

In Deiner Software Datei src\tuner_rx82xx.c, Zeilen 1219 - 1256.
Da würde ich gern mal experimentieren und auch die Variable int_freq ändern. Über 1 GByte QT-Code habe ich schon gesaugt, mal sehen ob es damit irgendwie geht.

hayati hat geschrieben:
In älteren bzw. anderen librtlsdr repositories fehlen die USB IDs zur Erkennung von manchen kompatiblen Dongles.

Die Version von 2014, die Clem01 mit Qirx ausliefert, läuft bei mir im Prinzip auch. Wegen häufiger Datenverluste synchronisiert der DAB-Empfang aber nur selten.

[Habakukk]

Bei Überreichweiten des 10C Nürnberg hatte ich vor einiger Zeit sogar die Situation, dass mit dem Original-Realtek-Treiber ein schwaches, aber sauberes DAB-Spektrum zu sehen war, Dekodierung gerade noch aussetzerfrei mit Audio, während mit dem Zadig-Treiber und RtlTcp im Spektrum absolut nichts zu erkennen war (als wäre nichts da), mit dem entsprechenden Ergebnis (kein Ensemble gefunden). Das war nur auf diesem einen Kanal so, sonst lagen die Ergebnisse näher zusammen (1-2dB Unterschied). Das fand ich höchst seltsam, zumal dieser Kanal keinerlei Nachbarn hat, die stören könnten, 10D ist völlig frei, 10B geht auch nur bei Überreichweiten und war damals deutlich schwächer...