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

Alles zum Thema DAB(+) Digitalradio.
Dana Diezemann
Beiträge: 594
Registriert: So 10. Feb 2019, 20:15
Wohnort: Abstatt (HN)
Kontaktdaten:

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

Beitrag von Dana Diezemann »

Das mit 2-B statt 3-B im BM1 kann ich bestätigen.
Auch das extreme schwanken beim Sync. Hatte ich hier schon mal geschildert. Auch unter Windows tritt das auf ab 3.x. Nicht mit 2.x.
Ich hab 5 Systeme, die hier monitoren können. Und es tritt nur auf:

- wenn ich live abspiele, also keine Record Datei wiedergebe
- Ich ein Audiokanal aus dem Mux angewählt habe
- unabhängig ob ich QIRX oder selbst mit Buffern die rtl Lib starten lasser
- Auch bei starken Sendern, hier steht 150 Watt im Garten
- wird besser bei leistungsfähigeren Rechnern
- wird schlimmer mit CPU Last wie Waterfall und die ganzen anderen Diagramme und dann irgendwas noch auf dem PC aufmachen
- und nach 3x Mux weg und wieder gefangen ist Audio komplett weg

Lässt sich recht gut reproduzieren. Und bei meiner letzen Messfahrt gab es so 3 bis 5 Aussetzer bis hin zum Tonverlust. Was dann Pause auf dem Parkplatz bedeutete.
Ich kann gerne ein Video machen.
andimik
Beiträge: 5696
Registriert: Sa 1. Sep 2018, 19:11
Wohnort: Arnoldstein, Bezirk Villach Land, Österreich
Kontaktdaten:

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

Beitrag von andimik »

Dana Diezemann hat geschrieben: Mi 24. Nov 2021, 18:21 Das mit 2-B statt 3-B im BM1 kann ich bestätigen.
Umgekehrt :D
Der Rest stimmt aber. Ich hab mir ein ETI selbst zusammengestellt (mit selbst gesprochenem Audio) und das RAW geladen. Kann ich gerne auf Bedarf zur Verfügung stellen.
Dateianhänge
Screenshot (295).png
andimik
Beiträge: 5696
Registriert: Sa 1. Sep 2018, 19:11
Wohnort: Arnoldstein, Bezirk Villach Land, Österreich
Kontaktdaten:

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

Beitrag von andimik »

Die Meldung

Code: Alles auswählen

set tuner gain by index 14
set tuner gain by index 13
set tuner gain by index 12
set tuner gain by index 11
set tuner gain by index 10
set tuner gain by index 9
set tuner gain by index 8
set tuner gain by index 7
set tuner gain by index 6
set tuner gain by index 5
set tuner gain by index 4
set tuner gain by index 3
set tuner gain by index 2
set tuner gain by index 1
set tuner gain by index 0
gibt es nur bei cQIRX. Bei Andis DAB-Player oder Qt-DAB kann ich mit der Oldenburger Version alle verfügbaren Muxe auswählen, OHNE, dass diese Zeilen kommen.

Heißt das, dass cQIRX der librtlsdr einen Verstärkerwert mitteilt, den es nicht gibt?
HF-Hase
Beiträge: 467
Registriert: Fr 31. Aug 2018, 20:16
Wohnort: Windeck / RheinSieg

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

Beitrag von HF-Hase »

Die Regelschwingungen habe ich (selten) auch unter Window beobachtet:
Regelschwingen.jpg
Das geht einher mit einem Volllaufen des Ringbuffers, der grüne Balken neben dem Spektrum wird rot. Nach einem Kanalwechsel oder Neustart des Frontends ist dann alles ok.
@Clem: ich hab dir ne Logdatei zu solch einem Ereignis geschickt.
Drehrumbum
Beiträge: 575
Registriert: Mo 1. Jun 2020, 02:28

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

Beitrag von Drehrumbum »

@HF-Hase: Ich glaube, Du hast Recht. Ich habe das bei mir jetzt nicht nachvollziehen können, aber ich erinnere mich an meine Spielereien mit der rtltcp Anfang des Jahres.

Wenn rtltcp einen Puffer mit den IQ-Daten (sagen wir 32kB) nicht rechtteitig mittels send() auf die Reise schicken kann, wird erstmal der Eingangspuffer von QIRX leerer. Das ist nicht weiter schlimm, wenn die folgenden Puffer wieder schneller übertragen werden können. Dann füllt sich der 'Eingangspuffeer wieder und alles ist gut.

Wenn es aber länger "klemmt", dann kommt diese (IMHO überflüssige) Linked-List-Geschichte in der rtltcp ins Spiel. Anstatt alte IQ-Puffer zu verwerfen, werden standardmässig bis zu 500 Puffer "angestaut" und dann, wenn send() wieder geht, an QIRX gesendet.

Das Problem dabei: Die Verzögerung wird immer grösser, da man die verlorene Zeit nur bis zum vollständigen Füllen des QIRX-Eingangspuffers wieder "aufholen" kann. Und es ist klar, dass dann die Gain-Regelung aus dem Ruder läuft und zu schwingen anfängt. QIRX bekommt ja dann keine "Echtzeitreaktion" auf eine Änderung der Vorverstärkung im Tuner und regelt wild rum.


Wenn das so wie beschrieben ist, dann gibt es bei andimik wohl so einen Stau zwischen cQIRX und der rtltcp. Das wäre mein Tip.


@andimik: Versuch doch mal den -n Parameter runterzusetzen.

-n max number of linked list buffers to keep (default: 500)
viterbi.dll replacement for QIRX-SDR (all versions): https://github.com/Drehrumbum/viterbi.dll#viterbidll
andimik
Beiträge: 5696
Registriert: Sa 1. Sep 2018, 19:11
Wohnort: Arnoldstein, Bezirk Villach Land, Österreich
Kontaktdaten:

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

Beitrag von andimik »

Ja, werde ich probieren.

Was evtl. auch noch zu überlegen ist, ich habe bisher nur einen USB 3.0 Anschluss genutzt. Der Rechner hat aber auch einen USB 2.0 (an dem ich die Maus angeschlossen habe).

Unter Windows gibt es Hardware, die unter 3.0 einen Bluescreen verursacht, unter 2.0 aber nicht.
Dana Diezemann
Beiträge: 594
Registriert: So 10. Feb 2019, 20:15
Wohnort: Abstatt (HN)
Kontaktdaten:

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

Beitrag von Dana Diezemann »

Schön das nicht nur ich das Schwingungsproblem habe. Die Haken bei der Auto Regelung für Gain , aber auch bei den Frequenzoffsets zu deaktivieren, bring nix. Also muss QIRX hier intern eine Regelung haben, die bei einem Packet Delay hier verständlich aus dem Tritt kommt. Evtl. muss das etwas tröger werden bzw. mit einem Konfig Parameter mal verstellbar sein. Teste ich gerne.
Wenn der Empfang remote ist, kann immer mal was verloren gehen. Robustheit wäre hier von Vorteil.
Zuletzt geändert von Dana Diezemann am Fr 26. Nov 2021, 22:36, insgesamt 1-mal geändert.
andimik
Beiträge: 5696
Registriert: Sa 1. Sep 2018, 19:11
Wohnort: Arnoldstein, Bezirk Villach Land, Österreich
Kontaktdaten:

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

Beitrag von andimik »

Ich glaub, ich hab den Flaschenhals gefunden. Es ist nämlich abhängig davon, wo das cQirx-Verzeichnis ist. Ich hatte das Verzeichnis auf einer Windows-Partition in NTFS (dort, wo ich auch meine übrigen Windowsinstallationen habe).

Was bitte bremst hier? Der NTFS-Treiber??

Habe testweise das Verzeichnis auf /tmp gelegt. Und was soll ich sagen?
a) cQIRX ist rasend schnell geworden.
b) Er lockt und gibt auch den schwächsten Mux wieder, so wie ich mir das erwartet hab.

Code: Alles auswählen

>start=1
Frontend on receiver 1 created and initialized.
>demod=DAB
qirx.DAB.demodulatorDABCore created
demodulator DAB creation successful.

>ens=6A
Creating Ensemble 6A 
DAB Synced after 1 seconds
Block: 6A, Name: DAB+ Austria, EId: A101
Available Services:
Stephans Klassik
Mein Kinderradio
ERF Plus
#Technikum ONE
Rock Antenne
jö.live
* 88.6 *
arabella RELAX
KLASSIK RADIO
ENERGY
-AUSTRIA
Radio Flamingo
Antenne Österrei
arabella HOT
WELLE 1
EPG ORS
Radio Maria


>conn
Connected to: [::ffff:127.0.0.1]:1234

>dev
R820T

>serv=Radio Flamingo
Service Radio Flamingo available after 0 seconds
Service: Radio Flamingo, SId: AD5A, Bitrate: 72kbps
Es hat überhaupt nichts mit der rtl_tcp zu tun. Den Parameter n hab ich wieder auf 500 gesetzt.
Drehrumbum
Beiträge: 575
Registriert: Mo 1. Jun 2020, 02:28

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

Beitrag von Drehrumbum »

Kann es sein, dass da irgendwelche Quoten/ Kontingente greifen? Anders ist das Verhalten ja bald nicht erklärbar.
viterbi.dll replacement for QIRX-SDR (all versions): https://github.com/Drehrumbum/viterbi.dll#viterbidll
Clem01
Beiträge: 282
Registriert: Fr 31. Aug 2018, 17:24

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

Beitrag von Clem01 »

andimik hat geschrieben: Fr 26. Nov 2021, 21:23 Ich glaub, ich hab den Flaschenhals gefunden.
Freut mich! Danke für deine Harnäckigkeit!
Drehrumbum
Beiträge: 575
Registriert: Mo 1. Jun 2020, 02:28

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

Beitrag von Drehrumbum »

Es gibt etwas Interessantes zum Thema "Sync" zu berichten. Bemerkt habe ich das Ganze am Wochenende, nachdem ich die rtltcp-Source auf meinem Rechner mit der Fähigkeit zum Ändern der Samplefrequenz des SDR-Sticks mit 1/100 ppm Genauigkeit versehen habe.

Einen einfachen Algo zur Auffinden des Nullsymbols in den Puffern vom Stick hatte ich ja schon drin, denn Anfang des Jahres hatten wir ja noch mit Sampleverlusten zu kämpfen, die QIRX, je nach Anzahl der verlorenen Samples, mächtig aus dem Tritt brachten. Im Prinzip habe ich am Ende eines Nullsymbols die fehlenden Samples duch Nullbytes ersetzt, damit der folgende Frame zeitlich wieder "passt". Das hat schon viel geholfen, damit QIRX nicht den Sync verliert. Zum Glück brauchen wir das heute nicht mehr.

Aber wenn das ganze Zeug schon drin ist, dann kann man den Drift des Nullsymbols in den Puffern auch in ppm umrechnen und anzeigen. Gesagt getan. Damit man auch was sieht, habe ich die ppm Anzeige oben im Konsolenfester mit etwas grösserer Schrift angeheftet. Das sieht nach dem Start und der Aufwärmphase des Sticks so aus:

original_ppm.jpg

Mein Stick ist schon sehr gut, liegt weit unter den 0,5 ppm laut Datenblatt. Früher bestand also kein Grund, den Stick von QIRX kalibrieren zu lassen. Das ging auch nicht, da ja nur 1 ppm Schritte möglich waren.

Der zweite Wert ist übrigens der ppm-Wert nach 300 Nullsymbolen, also nach einer Messzeit von genau 57,6 Sekunden. Trotzdem ist es sehr "mutig", nach dieser Zeit drei Stellen nach dem Komma anzuzeigen. Man müsste noch länger messen (1000), damit sich Messfehler entsprechend wegmitteln. In "Real-World-Nullsymbolen" ist ja immer etwas Rauschen, letzte Signale weiter entfernter SFN-Sender am Anfang des Nullsymbols oder irgendwelche Störungen drin, was sich in Jitter äussert.

An dieser Stelle möchte ich Dana zu Wort kommen lassen. Sie schrieb (etwas gekürzt):
Dana Diezemann hat geschrieben: Mi 24. Nov 2021, 18:21 Auch das extreme schwanken beim Sync. ... Auch unter Windows tritt das auf ab 3.x. Nicht mit 2.x.
Ich hab 5 Systeme, die hier monitoren können. Und es tritt nur auf:

- wenn ich live abspiele, also keine Record Datei wiedergebe
- unabhängig ob ich QIRX oder selbst mit Buffern die rtl Lib starten lasse
- wird besser bei leistungsfähigeren Rechnern
Ich fange mal mit dem ersten Punkt an, denn der erscheint mir sehr wichtig für die Fehlersuche. Wenn QIRX ein File abspielt, wird das Timing intern generiert. Die "Abspielgeschwindigkeit" ist also völlig unabhängig vom SDR-Stick. Den kann man ja notfalls auch abziehen. Ich gehe jetzt davon aus, dass man ein IQ-File nur aufzeichnet, wenn der Sync auch "steht". Ein solches File wäre dann beim Replay auch erstmal in Ordnung...

Der zweite Punkt deutet darauf hin, dass Dana die rtltcp mitunter auch über eine Batchdatei startet. Das könnte darauf hindeuten, dass evt. nicht die rtltcp im QIRX-Programmverzeichnis gestartet wird. An dieser Stelle komme ich wieder ins Spiel, denn meine rtltcp lag ja zunächst im Release-Verzeichnis vom VisualStudio und dort lag noch eine rtlsdr.dll vom Juli rum. Mal sehen, ob das Programm funktioniert. Ich lasse also meinen Stick von QIRX "kalibrieren"...


adjusted_ppm.jpg


0,14 ppm sagt QIRX und zeigt das auch an. In Wahrheit sind es aber 100x soviel. Und da hab ich noch Glück mit meinem Stick. Es gibt auch Sticks mit einem grösseren Frequenzfehler. Sagen wir "läppische" 1,5 ppm. Dann wird es schnell kritisch mit dem Sync:


adjusted_150ppm.jpg

Das Problem entsteht also nur dadurch, weil ich zunächst die falsche (ältere) rtlsdr.dll benutzt habe und auch nur, wenn die Korrektur !0 ist. Es riecht mir verdammt danach, dass das bei Dana ebenso ist. Wie soll Dana später auch erkennen, dass der Stick völlig "verstimmt" ist? Klar, im "Sync-Tab" spielen die Zahlen verrückt, und das kann bekanntlich mehrere Gründe haben.

Ein bekannter "Held" in dieser Beziehung ist bekanntlich "Firefox". Beim Aufruf einer "schweren" Webseite kann man darauf wetten, dass der Sync flöten geht. Und es hilft auch nichts QIRX und die rtltcp mit High-Priority laufen zu lassen. Firefox würgt kurzzeitig alles ab. Da ist wohl ein CPU-Hog drin. Dieser Zirkus gibt sich nur, wenn man im Taskmanager die beiden Firefox-Tasks mit dem höchsten Speicherverbrauch (gut sichtbar über 100MB, die anderen sind unwichtig) auf niedrigste Priorität setzt. Normalerweise nimmt man diese Prio für Bildschirmschoner. :D


Aber zurück zu den ppm-Werten mit der richtigen rtlsdr.dll aus dem aktuellen QIRX-Verzeichnis. Ich hätte ja gedacht, dass die gesamte Frequenz-Mover-Geschichte am Anfang der DAB-Dekodierung gegen Null strebt, wenn der SDR-Stick mit möglichst exakt 2,048 MHz sampled. Das scheint aber nicht der Fall zu sein. Mein Stick läuft nach der Kalibrierung definitiv langsamer. Das zeigt nicht nur meine rtltcp an, man sieht es auch im IQ-Data Fenster. Das Nullsymbol wandert ganz langsam nach links aus dem Fenster.

adjusted_by_qirx.jpg

Langer Text- wenig Inhalt. :danke: für Eure Aufmerksamkeit! :cheers:
viterbi.dll replacement for QIRX-SDR (all versions): https://github.com/Drehrumbum/viterbi.dll#viterbidll
Dana Diezemann
Beiträge: 594
Registriert: So 10. Feb 2019, 20:15
Wohnort: Abstatt (HN)
Kontaktdaten:

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

Beitrag von Dana Diezemann »

Ähm, ich bin absolut begeistert über deine Tiefe, wie genau du etwas analysierst. Ich habe auch mit 3.1.8 das Problem auf fast allen Systemen noch nicht im Griff. Ob stark oder schwach, ich schaffe es nicht, sauber und stabil ein Signal zu halten. Es wäre schon, wenn das auch mal wer bestätigen könnte. Ich werde nun mal getrennte PCs verwenden. Sticks habe ich 4 Bauarten da.
Und die RTL_TCP mit nix anderem auf einen einzelnen PC packen. QIRX dann auf den anderen Systemen übers Netz. Ich kann nur sagen, es liegt definitiv an der CPU Last. Die anderen 4 Monitorsysteme, die ebenso über SDR laufen, haben überhaupt kein Thema mit starken oder schwachen Signalen. Wie ich schrieb, ich denke es ist der "PLL" Algo, der sich auf das Signal einschwingt.
HF-Hase
Beiträge: 467
Registriert: Fr 31. Aug 2018, 20:16
Wohnort: Windeck / RheinSieg

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

Beitrag von HF-Hase »

Drehrumbum hat geschrieben: Mi 1. Dez 2021, 18:54 Aber zurück zu den ppm-Werten mit der richtigen rtlsdr.dll aus dem aktuellen QIRX-Verzeichnis. Ich hätte ja gedacht, dass die gesamte Frequenz-Mover-Geschichte am Anfang der DAB-Dekodierung gegen Null strebt, wenn der SDR-Stick mit möglichst exakt 2,048 MHz sampled. Das scheint aber nicht der Fall zu sein. Mein Stick läuft nach der Kalibrierung definitiv langsamer. Das zeigt nicht nur meine rtltcp an, man sieht es auch im IQ-Data Fenster. Das Nullsymbol wandert ganz langsam nach links aus dem Fenster.
Jetzt stellt sich die Frage, welchen Stick du hast. Es gibt Modelle mit einem Quarz und solche mit zwei Quarzen. QIRX ermittelt den Frequenzfehler und schickt das Kommando "set frequency correction", das auf Frequenzabstimmung und Samplingrate im Stick wirkt. Leider führt das bei Sticks mit getrennten Quarzen dazu, dass die Samplingrate zwar verschoben, aber nicht unbedingt genauer wird. Eine getrennte Anpassung von Frequenz und Samplingrate ist in der rtl_tcp (bis jetzt) nicht vorgesehen.
Clem01
Beiträge: 282
Registriert: Fr 31. Aug 2018, 17:24

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

Beitrag von Clem01 »

Drehrumbum hat geschrieben: Mi 1. Dez 2021, 18:54 0,14 ppm sagt QIRX und zeigt das auch an. In Wahrheit sind es aber 100x soviel.
Du hast das Problem selbst identifiziert. Die rtl_tcp aus dem Download sollte diesen Effekt nicht zeigen. Er kommt wohl einfach daher, dass qirx die ppm's nicht als float überträgt, sondern multipliziert mit 100 als int.
Drehrumbum hat geschrieben: Mi 1. Dez 2021, 18:54 Ein bekannter "Held" in dieser Beziehung [Sync-Verlust] ist bekanntlich "Firefox"
Das ist ein bekannter Effekt, der auch hier schon erwähnt wurde. Einmal scrollen, und Tschüss. Auch Visual Studio hat gelegentlich negative Einflüsse. Möglicherweise liegt es an der GUI. Hier sollte die Konsolenversion Aufschluss geben können. Diese ist zwar auf Windows vorhanden, aber noch nicht verteiltl
Drehrumbum hat geschrieben: Mi 1. Dez 2021, 18:54 Trotzdem ist es sehr "mutig", nach dieser Zeit drei Stellen nach dem Komma anzuzeigen
Die dritte Stelle hinter dem Komma ist der Faulheit des Programmierers geschuldet, da der Punkt eigentlich ein Tausender Trenner ist und die letzte Stelle nicht so ganz einfach wegzuradieren war. Wenigstens ist sie konstant auf 0.
Die zweite Stelle nach dem Komma ist aber nötig. Zumindest bei den RSPs, die ja deutlich stabiler sind als die Dongles. Ohne diese Stelle kommt man nicht auf die erzielbare Genauigkeit von fast 1e-8 in der Frequenz. Mit einer enormen Langzeitstabilität, natürlich bei konstanter Temperatur, und nach einer Einlaufzeit von mindestens 15 Minuten.
Drehrumbum hat geschrieben: Mi 1. Dez 2021, 18:54 Mein Stick läuft nach der Kalibrierung definitiv langsamer
Du meinst, die Prozessorlast steigt durch die Kalibrierung? Die Kalibrierung macht nichts anderes, als die ppm-Korrektur an die Hardware zu schicken. Die Grösse der Frequenzabweichung ist - vom Programm her gesehen - irrelevant für die Prozessorlast. Egal, ob 30.456kHz oder 3Hz Abweichung, die Zahl der Tabellenzugriffe (für die Berechnung der Frequenzverschiebung) ist identisch. Falls der Effekt real ist, habe ich dafür keine Erklärung.
Dana Diezemann hat geschrieben: Mi 1. Dez 2021, 21:15 Wie ich schrieb, ich denke es ist der "PLL" Algo, der sich auf das Signal einschwingt.
Welchen PLL Algo meinst du? Es gibt keine PLL.
Drehrumbum
Beiträge: 575
Registriert: Mo 1. Jun 2020, 02:28

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

Beitrag von Drehrumbum »

Ich habe einen Nooelec "nesdr sharp" (V2?) mit TXCO@28.8MHz. "Ziehen" fässt sich das Teil jedenfalls bis knapp 500ppm. Mehr nimmt der Stick nicht an.
nooelec.jpg
@Clem01:
Mit "mutig" und den drei Stellen nach dem Komma meinte ich eigentlich die Anzeige in meiner rtltcp. Denn damit täusche ich eine Genauigkeit vor, die über 300 Nullsymbole gemessen einfach nicht gegeben ist. Das ist vergleichbar mit DCF77 und der sehr variablen "Anstiegszeit" (Flankensteiheit) am Ausgang eines DCF-Moduls. Richtig "genau" wird es erst, wenn man die Messzeit extrem verlängert. Dann spielen diese kleinen Messungenauigkeiten keine Rolle mehr.

Mit "läuft langsamer" meinte ich, dass der Stick nach der Kalibrierung durch QIRX mit weniger als 2048 kHz sampled. Man sieht es im Screenshot: Qirx ist zufrieden (Fine Frequency Correction bei 1 Hz), die rtlsdr sagt aber, dass nach einer Messdauer von 210 Sekunden schon über 60 Bytes (SDrift) im Datenstrom fehlen. Das Nullsymbol wandert also nach links im Puffer (NSOffset) und auch im IQ-Fenster von QIRX. Das ist für mich sehr verwunderlich.

Und klar, ich weiss das mit dem Faktor 100, denn ich habe ja die letzten Änderungen im Quelltext vom Kollegen Oldenburger in der Hand gehabt. Ich war nur _etwas_ überrascht, dass die beim Testen versehentlich geladene alte rtlsdr.dll diese Wirkung entfaltet. Dabei musste ich sofort an Dana und ihre Sync-Probleme denken. Es bestand ja die Möglichkeit, dass sie eben auch versehentlich die alte DLL benutzt.

Die Nummer mit dem Firefox ist wirklich interessant. Ich hatte den Eindruck, dass keine Samples verloren gehen, wenn Firefox "wilder Mann" spielt. Natürlich ist der Sync weg, aber lusigerweise verrutschte das Nullsybol nicht im Puffer. Als würde alles nur kurz stillstehen. Aber das kann man ja mit dem Testsignal vom Stick einfach checken.


EDIT, bevor ich es vergesse: Die FrameTime wird bei mir mitunter kurz "gelb", obwohl die rtltcp absolut nichts dergleichen feststellt und alles im "grünen Bereich" ist. Keine Ahnung, was das sein könnte. Ich mach bei Gelegenheit mal ein Video mit dem Handy.

Gute N8 @ all
viterbi.dll replacement for QIRX-SDR (all versions): https://github.com/Drehrumbum/viterbi.dll#viterbidll
Antworten