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

[Habakukk]

Das neue Feature, die Kennzeichung der TIIs im CIR, braucht halt etwas Rechenkapazität...CIR-TII.jpg

Das ist aber ein wirklich tolles Festure.

[HF-Hase]

Runtertakten in Windows 10 geht über die Energieoptionen. Dann auf "Erweiterte Energieeinstellungenändern" klicken.

Danke für die Beschreibung, ich kann mich nicht beschweren:

BTW: 3,8 GHz bei 9% Auslastung ist IMHO ein ganz schön hoher "Ruhepuls". Hast wohl auch so ein AKW wie die Hoppenstedts zur Netzstabilisierung im Keller? Nicht die schlechteste Investition dieser Tage.

Hab mal nachgemessen: mein kleiner Desktop-PC genehmigt sich bei laufendem QIRX und 3.8 GHz nur 19 W, da dürfte selbst das Hoppenstedtsche Micro-AKW überdimensioniert sein

[Dana Diezemann]

Ich hab nen 24-Kern Server, auf dem das Monitoring und DAB Playout läuft. Die gesamte CPU Belastung ist keiner wirklichen Aussage Wert, es kommt drauf an, ob die einzelne CPU am Anschlag ist. Also 30% Gesamt bei einer Quadcore zum Beispiel sind da schon zuviel.

[Drehrumbum]

Ich wollte auch gerade in diese Richtung gehen und @HF-Hase fragen, welche CPU in seinem PC werkelt. Das riecht mir nämlich nach vielen Kernen, die die QIRX- und .Net-Threads (es sind 37, wenn sich die viterbi.dll in DllMain unter QIRX 3.2.1 letztens nicht verzählt hat) mehr oder weniger nebenbei und parallel "wegholzen". Das ist natürlich viel "entspannter" als bei einem 2013er i5.

Aber in der Tat, ein nettes Feature mit den TII im CIR. Es liegt auf der Hand, dass damit auch die Bestimmung der Position des Empfängers über Triangulation möglich wird. Das war bekanntlich schon im Standard angedacht, aber kein Sender sendet seine eigene Position.

[Dana Diezemann]

Wenn du dir ein professionelles Tools ansiehst, dann kann Clem noch viel einbauen. Ist aber nicht seine QIRX Richtung. Hier mal das CIR mit den TII Markierungen. Ist schon gängig, der nächste Level wärer noch der Jitter drauf, die weisse Linie. Sowie das 241µs Fenster.

[Clem01]

Ja, die Profis... sind so professionell, dass sie es nicht für nötig halten, Beschriftungen an ihre Skalen zu machen. Da kann der Nicht-Profi nur rätseln, was die Zahlen bedeuten. Aber nur unten. Links an der Seite haben sie es noch geschafft. Vielleicht mal mit den Tools von R&S vergleichen, ob das dort auch der Stand der Technik ist.

Und ganz unten lese ich Sampling 0.005 ppm. Wenn das die Genauigkeit der Abtastrate sein sollte, wäre die auf 0.01Hz genau gemessen. Das sind immerhin 10 Millihertz! Wie machen die das? Wäre interessant zu erfahren.
Nein, was soll die Pedanterie. Profis!

[Dana Diezemann]

Hey Clem, ich bin da ja nen Stück bei dir. Unten rechts ist interessant, Speed vom GPS her, dabei ist es eine Festinstallation... Da gibt es keine Geschwindigkeit, nur eine Ungenauigkeit.

Beschriftungen hat es doch an den Achsen, der Rest kommt mit großen Mouseover Texttafeln...

Professionall ist im Wesentlichen eben der Preis.

[Clem01]

Beschriftungen hat es doch an den Achsen, der Rest kommt mit großen Mouseover Texttafeln...

Sorry, aber Beschriftungen hat es eben keine an den (horizontalen) Achsen. Da stehen zwar Zahlen, aber was bedeuten diese? Dafür hat der Mensch eigentlich mal die Skalenbeschriftung erfunden. Ist halt nicht überall angekommen.

[Dana Diezemann]

Beschriftungen hat es doch an den Achsen, der Rest kommt mit großen Mouseover Texttafeln...

Sorry, aber Beschriftungen hat es eben keine an den (horizontalen) Achsen. Da stehen zwar Zahlen, aber was bedeuten diese? Dafür hat der Mensch eigentlich mal die Skalenbeschriftung erfunden. Ist halt nicht überall angekommen.

Hmmm, ok. Hab ich nie im Betrieb bemerkt. Bei RSSI, MSC, SNR und FIC sind das Sekunden. Spectrum die Träger, CIR die Zeit in µs.
Bei den Constellation, ja, keine Ahnung. 1 und -1 als "Norm" wo die Bits letztlich liegen. Und untere Reihe wieder Sekunden. In der Livedarstellung wird es klarer, ähnlich einem Waterfall.

[HF-Hase]

Ich wollte auch gerade in diese Richtung gehen und @HF-Hase fragen, welche CPU in seinem PC werkelt.

i5-10505

[Clem01]

Danke für die Aufklärung. Mir kann es eigentlich egal sein, was das für Einheiten sind, ich hab das Tool nicht in Benutzung.

Wenn ich mir die Daten auf dem Bild allerdings so anschaue, hätte ich (als Nutzer) schon ein paar Fragen, rein interessehalber. falls das auf dem Bild die Daten von einem echten Signal sein sollten:

Das SNR zeigt fast 30dB (zwei Nachkommastellen, beeindruckend!!), ein sehr starkes Signal, was auch einige starke Peaks im CIR zeigt, mit entsprechend kleinen Fehlerbalken (übrigens sehr ähnlich wie jetzt qirx auch). Constellation sieht auch sehr sauber aus.

SNR_BER_Profitool.jpg (10.7 KiB) 866 mal betrachtet

Trotzdem scheint das ein extrem fehlerbehaftetes Signal zu sein, wenn man die BER von 1.98e-2 sieht. Ein Signal mit 30dB SNR sollte eigentlich ein BER von fast 0 haben, auf jeden Fall deutlich besser als 1e-7, s. unten(Diplomarbeit "DAB" von A.Müller, ETH Zürich, 2008):

Ich will das nicht fortsetzen, aber es gäbe noch einiges zu hinterfragen, z.B. wie die Verhältnisse von SNR, BER und MER im Tool entstehen. Das MER ist ja eine Art von SNR und sollte sich daher in etwa in derselben Größe bewegen, nach meinem allerdings sehr laienhaften Verständnis.

Können die Profis sicher alles ganz plausibel erklären.

[Dana Diezemann]

Hier mal ein "ordentliches Signal", selbst erzeugt. BER ist da wie du sagst 0. MER liegt je nach Linearität und nicht-Linearität des Verstärkers immer über 20 dB. Bzw. mind. 10 dB unterm SNR. Bin momentan nicht onAir, kann ich gerade nur so aus dem Kopf bestätigen.

Die MER Geschichte gestern vom 11B war eine Schnellmessung mit der Hand Yagi in verschiedene Tx Richtungen. Im SFN gab es eine "Synchronitäts"-Störung eines Tx. Die sich dann in einer niedrigen MER und auch einer schwierigeren TII Dekodierung bemerkbar machte. MER sollte immer mind. 12 dB haben....

Und als Nachtrag nochmal ein zerschossenes SFN:

Sowie: Ich kann ja den Programmierer mal fragen, ob er mir Infos zu seinen Werten und der Berechnung gibt. Die Zusammenarbeit ist recht gut, denn wir sind dran, das bei den Small Scale ODR DAB Ensembles der CIF korrekt ist. Oben zu sehen. Normal 0,2. Bei ODR irgendwas. Ich bin dran, das zu korrigieren, damit nicht jeder gleich sieht, das DAB vom selbsterstellten Linux kommt.

[Drehrumbum]

i5-10505

Okay - "Waffe". Kein Wunder, dass QIRX bei Dir nicht weiter "auffällt."

Weil ich es letztens geschrieben habe: Die Position des Empfängers sollte sich jetzt (automatisch) berechnen lassen, wenn mindestens drei Sender in einem SFN empfangen werden. Gegeben sind ja indirekt die geo. Positionen der drei Sender über die TII in der Sendertabelle und die relativen Laufzeiten laut CIR. Das wäre dann ein TDOA-Problem (siehe evt. https://github.com/ucnl/UCNLNav), wenn man annimmt, dass die Sender untereinander kein Delay haben. Die Frage ist, was "überhaupt rauskommt", wenn Delays vorhanden sind, und ob sich evt. vorhandene Delays später herausrechnen lassen würden, wenn die Position des Empfängers bekannt ist. Klingt jedenfalls sehr interessant.

[Clem01]

Navigation über DAB war mal das alte Thema, dass das über TII Information GPS-unabhängig möglich sein sollte. Dazu gibt es z.B. dieses Patent von vor 20 Jahren.

Die Delays sind dafür nötig, daher waren die damals zusammen mit den Geo-Koordinaten der Sender in der FIG0/22 drin, die leider mit der 2017-er Version des Standards ersatzlos gestrichen wurde.

@Drehrumbum: Du hattest ja mal eine alte qirx Version 1.x ausgegraben, da wird die 0/22 ausgewertet und auch angezeigt. Damals hatte diese Info noch der hr drin, und die Auswertung der FIG0/22 brachte auch die richtigen Koordinaten raus.

Soviel zum "History Channel".

Wenn die Senderkoordinaten bekannt sind, und die TII zu CIR Zuordnung korrekt ist, bekommst du den Delay sehr leicht ausgerechnet. Die Sender wollen sich da wohl nicht in die Karten schauen lassen, da die Delays ein wesentliches Element der Netzwerkplanung sind.

Das Bild zeigt den 11D Bayern, mit einem SNR von ca. 15dB von meinem Standort.

Die relative Geo-Entfernung zwischen 6/8 und 6/2 steht in der TII-Tabelle und ist ca. 37km. Die Distanz im CIR zeigt aber nur ca. 25km. D.h. dass z.B. der 6/2 12km "früher" eingeschaltet wird als der 6/8. 12km entsprechen ganz grob 12000/300us, d.h. ca 40us.

Der 6/8 hat also 40us Verzögerung gegnüber dem 6/2. Das sagt nur etwas über die relativen Zeitdiffernzen aus, nichts über die absoluten Delays der Sender. Und bestätigt gleichzeitig, dass bei unbekannten Standorten die Distanzen im CIR mit Vorsicht zu betrachten sind.

[Dana Diezemann]

Der 11B hier in BW hat momentan keinen Delay auf seinen 16 Tx Stationen. Wer das also mal in der Praxis testen möchte...
Im unteren Bild meines Posts vom 1.3. sind neben den 3 Trägern im CIR auch ein 4. ausserhalb zu erkennen. Der Raichberg steht fast mittig in BW und haut hier theoretisch eigentlich alles kaputt. Bis 300 / 320µs geht ein SFN noch recht gut, es ist aber an der Grenze. Hier also die umstehenden mal mit einem Delay zu versehen, könnte im Empfang etwas bringen. Momentan aber seitens der OAS nicht geplant. Wenn mal alle 26 Tx in BW fertig sind, kann hier die Netzplanung das mal erneut auf den Tisch packen. Soweit ich weiß, muss der BM1 schon im Randbereich Delays fahren.