CubicSDR: jetzt geht es wieder!
Aus irgendeinem Grund hat vor Kurzem unser SDR Empfänger RSPdx von SDRplay keine Signale mehr an den Log-Rechner gesendet. Das Gerät wurde vom Rechner erkannt, es lies sich über Hamlib vom Transceiver steuern und steuerte auch den Transceiver, das Bandspektrum und das Wasserfalldisplay blieben aber leer.
Nachdem alle Kabelverbindungen überprüft worden sind wurde das Gerät kurzerhand mit nach Hause genommen und am Heimat QTH auf Funktionstüchtigkeit überprüft, die sich als gegeben herausstellte. Also ein Softwareproblem. Was nun folgte war eine lange Odyssee des Ausprobierens und des Nachlesens.
Zunächst wurde versucht die Software CubicSDR neu auf dem Linux Rechner zu installieren. Dazu gibt es im Netz glücklicherweise eine Reihe von Anleitungen und sogar ein Installscript, das einem viel Arbeit abnehmen soll. Leider zeigte weder das Abarbeiten des Installscripts noch das gewissenhafte Abarbeiten der einzelnen Schritte in der von SDRplay verlinkten Anleitung den erhofften Erfolg. Die Software und alle benötigten Bibliotheken und Abhängigkeiten wie SoapySDR, SoapySDRplay, wxwidgets und natürlich CubicSDR ließen sich alle fehlerfrei installieren, jedoch blieb der RSPdx taub.
Was sich dann nach einiger Recherche herausstellte war, dass die benötigte und vom Hersteller des RSPdx herausgegebene API in Version 3 nicht mehr mit der Software SoapySDRplay, die ebenfalls vom Hersteller verlinkt war, zusammenarbeitet! Dieser wichtige Hinweis wurde in einer SDRPlay Usergroup gegeben, glücklicherweise zusammen mit dem passenden link auf das git Repository der funktionierenden Software. Der Unterschied für den Benutzer ist nur in dem großen „P“ bei SoapySDRPlay im Gegensatz zur alten Version SoapySDRplay zu erkennen. Auch hier ist noch etwas zum Thema zu lesen.
Nachdem die neue Api zum x-ten Male nachinstalliert, SoapySDR und das richtige SoapySDRPlay kompilliert waren zeigte sich ein weiteres seltsames Fehlerbild: beim am Rechner angemeldete User mit Adminrechten funktionierte der RSPdx einwandfrei, auf der Oberfläche des normalen Users blieb das Wassfalldiagramm aber weiterhin schwarz. Auch die Fehleranalyse mittel SoapySDRUtil –info und SoapySDRUtil –probe zeigten keine Auffälligkeiten, das Gerät wurde einwandfrei erkannt. Wurde CubicSDR aber über das Terminal gestartet wurde sobald der RSDdx als anzuzeigendes Gerät ausgewählt war eine Fehlermeldung ausgeworfen, die auf ein Problem mit der API schließen ließ. Alles in allem sehr seltsam.
Beim durchforsten der Unterschiede in der Dateistruktur zwischen Admin und normalem Benutzer half dann das Glück etwas nach. Die Konfigurationsdateien zu finden unter ~/.CubicSDR/config.xml sahen sehr unterschiedlich aus. Also wurde kurzerhand für den normalen Benutzer diese Datei gelöscht, damit CubiSDR sie wieder neu anlegen kann anstatt aus ihr zu lesen. Und siehe da, da lag der Hase im Pfeffer! Seitdem spielt CubicSDR in der allerneuesten Version 0.2.5 schöner als zuvor und wir können wieder sehen, wo sich auf den Amateurfunkbändern gerade etwas abspielt.
Willkommener Nebeneffekt: um die Zeit während der Softwarecompilierung zu verkürzen, kann man ja auch das ein oder andere QSO fahren. Und so konnten wir z.B. mit Oman ein neu gearbeitetes Land in unsere QSO-Liste für das 15m Band aufnehmen.
Dort bin ich auch der MINT-Beauftragte, betreue die Robotik AG und das MGF-Lab, bin Fachschaftsleiter Physik und Sammlungsleiter sowie der Strahlenschutzbeauftragte, betreibe die Amateurfunk-Schulstation DK0MGF und führe eine Junior-Ingenieur-Akademie der Deutsche Telekom Stiftung.
- DK0MGF bietet Meshtastic Knoten an - 17. Juli 2024
- Europatag 2024 mit vielen kleinen Unwägbarkeiten - 6. Mai 2024
- Endlich etwas Übersicht - 22. April 2024