Apr 02

OpenwebRX / WebSDR aufsetzen

Elektronik, Fun, Ham, Linux Kommentare deaktiviert für OpenwebRX / WebSDR aufsetzen

Ziel: Einen SDR aufsetzen, der per Browser erreichbar ist.

Am Ende dieser Anleitung hat man einen WebSDR wie bspw. diesen: https://sdr.dj7nt.de

Neben der eigentlichen WebSDR-Funktionalität, bietet openwebRX u.a. die Möglichkeit, dass WSPR/FT8/FT4/etc. Signale automatisch im Hintergrund dekodiert und auch an die entsprechenden Portale wie pskreporter.info / wspr.rocks weitergeleitet werden. Sehr schön um Langzeitstudien des eigenen QTHs / der eigenen Antenne durchzuführen.

Zutaten:

  • Raspberry Pi 3 oder 4
  • Netzteil für den Pi (5V / 1,5A)
  • SD-Karte (min. 4 GB)
  • SDR-Hardware (Auswahl)
    • RTL-SDR (Für den Anfang ok, aber recht instabil / unsensitiv)
    • SDRPlay (RSPdx bspw.)
    • HackRF
    • PlutoSDR
  • PanAdapter, sofern der SDR an derselben Antenne wie der Shack-TRX betrieben werden soll
  • USB-Kabel
  • Antennenkabel

Kochrezept:

Zunächst openwebrx herunterladen und das ZIP entpacken. Anschliessend den “Raspberry Pi Imager” herunterladen und starten. Dort dann unter “OS wählen” die image-Datei aus dem openwebrx-ZIP auswählen. Da es einige – wenige – Dinge gibt, die wir direkt auf dem Pi ohne das WebInterface zu Anfang erledigen müssen nun auf das Zahnrad unten rechts clicken.

Hier kann bspw. der Hostname u.a. angegeben werden. Wichtig ist aber, dass ein Haken bei “SSH aktivieren” angeclickt wird, und bei “Benutzername und Passwort setzen”. Benutzername/PW ist frei wählbar, sollte man sich jedoch merken 😉

Wer fit in der Linux-Welt ist, kann natürlich auch seinen SSH-PublicKey hinterlegen. WiFi-Konfiguration kann man machen, muss man aber nicht. Ich bin ein Freund von LAN-Kabeln. Ist stabiler als WLAN.

Nun kann man die SD-Karte einlegen und im Imager die korrekte Karte auswählen. Anschliessend auf “schreiben” drücken. Jetzt wird das openwebrx-Image auf die Karte geschrieben.

Aufbau der Hardware hier wie folgt:

Während all das passiert können wir uns der Hardware widmen. Ich nutze hier einen SDRPlay-RSPdx, aber wie oben beschrieben funktioniert auch ein günstiger (<20 Euro) RTL-SDR-Stick. Beim RTL-SDR wird – um die Kurzwellenbänder zu Empfangen – noch ein UpConverter benötigt. Beispielsweise der HamItUp von Nooelec.

Szenario: SDR soll die selbe Antenne wie der Transceiver nutzen:

Blockschaltbild

Kurze Erklärung: Der Panadapter sorgt dafür, dass der SDR zur Antenne durchgeschaltet wird, so lange der TRX nicht auf Sendung ist. Wird am TRX PTT gedrückt, trennt der Panadapter instant das Signal zum SDR. Wird nicht gesendet, so bekommen sowohl SDR als auch TRX das Antennensignal. Ich habe mich für einen simplen Panadapter aus China entschieden. Bei meinem Model musste noch ein Jumper umgesteckt werden, damit die Trennung auch vollzogen wird. Der Adapter verfügt über eine HF-VOX (ich traue diesen VOX-Dingern nicht) oder aber über einen PTT-Cinch-Anschluss womit man den Adapter mit dem TRX verbinden kann (die aktuellen Transceiver haben alle ein PTT-Out). Es empfiehlt sich das ganze unbedingt vor Anschluss des SDRs zu testen. Im Worstcase geht die volle Leistung des TRX nämlich sonst in den SDR – und das wird der garantiert nicht mögen

Szenario: SDR bekommt eine eigene Antenne:

Das alles entfällt natürlich, wenn man dem SDR eine eigene Antenne gönnt. In dem Falle wird die (eigene) Antenne einfach an das SDR-Gerät geklemmt, und der SDR per USB an den RaspberryPi und fertig.

Der erste Start / Boot:

Nachdem alles wie oben beschrieben verkabelt/angeschlossen ist (LAN nicht vergessen ;), können wir den Pi das erste mal mit Strom über die USB-Buchse versehen. Sobald der Raspberry hochgefahren ist, suchen wir uns die IP-Adresse die das Gerät bekommen hat. Hier gibt es mehrere Wege, die von der Architektur des (Heim-)Netzwerks abhängen:

  • Suchen des Geräts in der Fritzbox/Speedport/Plastikrouter der die IPs im LAN vergibt und jeweilige IP merken.
  • Je nach Netzwerk ist der Pi sogar schon über den o.g. Hostnamen (siehe Kochrezept, zweiter Absatz) erreichbar.

Ein kurzer Test ob das Gerät anpingbar ist (ping [hostname] (s.o.) bzw. ping [IP] auf der Kommandozeile des PC’s/Mac) gibt Aufschluss ob die Maschine erreichbar ist. Jetzt wird es – für nicht Linuxer – ganz kurz etwas komplexer, denn wir müssen auf dem Pi einen neuen Nutzer/Kennwort für das Websdr anlegen.

Nutzer anlegen

Linux und Mac-User haben es einfach, hier wird ein Terminal/Shell aufgemacht und anschliessend kann man sich per ssh [user]@[hostname] (user/hostname bitte den verwenden, der unter Kochrezept Absatz 2 vergeben wurde) auf den Pi verbinden.

Als Windowsnutzer wird noch ein SSH-Client benötigt. Als Leichtgewichtig hat sich Putty herausgestellt. Also herunterladen und unter Host den Hostnamen bzw. die IP-Adresse eintragen, sowie anschliessend unten im Fenster auf “Connect”/”Verbinden” drücken.

Ist man auf der Shell des Pis angekommen, lässt sich nun ein Nutzer anlegen. Das geschieht durch die Eingabe des folgendes Befehls/Kommandos:

sudo openwebrx admin adduser adminuser

Es wird also ein neuer (Web-)Nutzer mit dem Namen “adminuser” angelegt. Andere Namen sind natürlich auch möglich. Nach dem Abschicken des Befehls fragt das Tool nach einem zu vergebenden Passwort. Ist das erledigt, kann man die Shell wieder schliessen (logout).

Damit wäre das komplizierteste geschafft.

Login/SetUp/Test

Unter http://[hostname oder IP] kann man sich nun auf dem WebSDR einloggen. Der zuvor genannte Admin-Nutzer wird für den Login der Settings-Seite (oben rechts im Webinterface) benötigt. Dort lassen sich Bänder/Profile und Co. für die jeweiligen SDR-Empfänger einstellen. Wer hier tiefer einsteigen mag, dem sei die Doku von openwebRX ans Herz gelegt. Auch Funktionen wie die eingangs erwähnte Dekodierung der DigiModes ist dort erklärt.

Weitere Dinge, wie bspw. Update des Raspberries oder explizite Konfiguration der SDRs sind in der Regel nicht erforderlich. Die Images von openwebRX werden sehr häufig aktualisiert, sodass man an sich immer eine aktuelle Version bei der Installation vorfindet. Die SDRs werden direkt beim booten erkannt, Feineinstellungen können über die bereits erwähnte Settings-Seite (Zahnrad oben rechts) erledigt werden.

Settings-Seite von openwebRX

Viel Spass mit dem eigenen WebSDR

Fallstricke:

Ein kleiner “Annex” über die Fallstricke, die es beim aufsetzen geben kann:

Problemggf. Abhilfe
Stick wird nicht erkannt– Stick im Webinterface nicht aktiv(iert) -> Aktivieren
– Pi neu booten
– tiefere Analyse auf der Shell durchführen (lsusb, syslog, etc.)
– Stick ggf. inkompatibel
WebSDR nicht aus dem Internet erreichbarWar auch nicht Teil dieser Anleitung 😉
Stichpunkte zum googlen / selber erarbeiten:
portforwarding, fritzbox, dyndns, ...
Bänder in der Auswahl fehlenBänder unter Setttings / passender SDR hinzufügen
Wasserfall zu “rot”/”dunkel”In Settings / “SDR Devices & Profiles” / passender SDR mit dem Wert “Gain” herumspielen
SDR wird erkannt, aber es wird kein/ein zu gedämpftes Signal angezeigtIn Settings / “SDR Devices & Profiles” / passender SDR über “Additional / Optional Settings” den richtigen Antenneneingang wählen (bspw. bei SDRPlay oder Geräten mit mehreren Antenneneingängen)
Dekodierung/Spotting funktioniert nicht.In Settings die Einstellungen zum “Background-Decoding” sowie “Spotting und Reporting” prüfen. Ferner unter “SDR Devices & Profiles” / passender SDR einen “Scheduler” hinzufügen und bei “Run Background-Services” einen Haken setzen.
Tagged with:
Jan 18

TTT – Trampel to Talk mit dem iCOM SM-30

Elektronik, Fun, Ham Kommentare deaktiviert für TTT – Trampel to Talk mit dem iCOM SM-30

Wenn es mal hektisch im PileUp wird, nervt es ziemlich, dass man die Hände nicht zum mitscribbeln/loggen frei hat.

Von einigen erfahrenen DXern hörte ich bereits von Fusspedalen. Kurz gegoogled und festgestellt dass es nichts bezahlbares “aus dem Regal” gibt. Aaaaaaber: Wofür hat man die Lizenz zum Löten? Selbstbau ist also angesagt. Vorweg: Der folgende Spaß hat unter 30 Euro gekostet.

Kurz mal das Innenleben und den Schaltplan des SM-30, sowie die iCOM-Steckerbelegung angesehen: Aha:

Wir wollen also Pin6 und Pin5 haben. Jetzt gibt es zwar fertige Kabel & Co. die die Pins herausführen, alllerdings scheinen da auch die Kontakte vergoldet zu sein – anders kann ich mir die Preise nicht erklären.

Mein Ansatz: Auf der Platine des SM30 ist ein Steckverbinder, wo alle Adern ankommen. Diese durchmessen. Bei mir war dann “blau” = PTT und der “obere schwarze” GND. An diese beiden Punkte habe ich mir eine Mono-3,5mm-Klinkenbuchse angelötet und diese im SM-30-Gehäuse festgeschraubt. Schaut dann so aus, und ist wirklich “minimalinvasiv” (Funktion des Mics in seiner Urform nachwievor gegeben):

Parallel habe ich mir – für einen schlanken Taler – einen Fusstaster für gerade mal 20 Euro geordert. Hier sollte man darauf achten, dass dieser möglichst schwer/massivst ist. In der Standardausführung kommt aus dem Taster eine Leitung mit drei Adern mit denen man den Taster wahlweise als “öffner” oder auch “schliesser” benutzen kann. Bei mir war “weiss” gegen “rot” die Schliesserfunktion. Sollte man – bei Nachbau – noch mal mit einem Multimeter prüfen. An das Ende der Leitung habe ich mir also einen 3,5mm Klinkenstecker gelötet und diesen dann in die neue Buchse des SM-30 gesteckt. Fertig ist der Fusstaster (TTT) mit dem man nun beim QSO die Hände frei hat.

Tagged with:
Jan 12

Plattformübergreifendes HAM-Setup

Ham Kommentare deaktiviert für Plattformübergreifendes HAM-Setup

Ich mag kein Windows / Closed Source. Da mache ich auch keinen Hehl draus. Allerdings bringt das Hobby Hamradio da so einige Herausforderungen mit sich mit, da es viel Software leider nur für das Betriebssystem aus Redmond gibt. Zeit da mal etwas gegenzuwirken. Hier also ein grober Überblick über mein SetUp:

Abb. 1

Nun, womit haben wir es hier zu tun?

Alles was blau ist, läuft auf meinem Ham-PC (muss es jedoch nicht zwangsweise). Das Schöne daran: Alle Software kann auch unter Windows laufen, muss es aber nicht (Linux, MacOs geht genau so)

FLRig ist quasi die “Brücke” zum TRX. Unterstützt sehr viele Transceiver und bietet ein kleines aber feines UI, mit dem sich alle Dinge, die man am TRX einstellen kann, auch dort einstellen lassen. Zusätzlich bietet es die Möglichkeit eine Verbindung per TCP/IP (und nicht über (virtuelle) Serielle Schnittstellen) zu anderen Tools zu schaffen. Dazu im folgenden mehr:

CloudLogCat (für Windows) oder CloudLogCatQT (Linux/MacOs) ist ein Tool welches die aktuelle QRG und den Mode aus FLRig zieht und meinem Logbuchtool “CloudLog” bekannt macht. Man dreht also am VFO (Egal ob Hardware oder in der FLRig GUI) und im Log steht direkt alles richtig.

CloudLog selbst ist halt ein Logbuchprogramm, dass man selbst hosten kann. Benötigt wird PHP und ein wenig Linux-KnowHow, wenn man es “onPremise” hosten will. Muss man nicht, kann man auch als SaS für wenig Geld einkaufen.

DXHeat2FLRig habe ich selbst geschrieben. Es handelt sich um ein kleines Browserplugin, mit dem man eine Frequenz aus dxheat.com mit einem Click zum TRX “beamen” kann. Sehr hilfreich!

Für Freunde der DigiModes gibt es WSJT-X. Um nicht jeden Abend die ADIF-Logs aus WSJT-X per Hand in CloudLog hochzuladen, habe ich ein kleines Script modifiziert, was das quasi “live” übernimmt. Sprich: Nach jedem QSO wird automatisch über das kleine Helferlein das Logbuch befüllt.

Tagged with:
Sep 01

SDRConsole / Abbrüche beim TX / Buffer

Ham Kommentare deaktiviert für SDRConsole / Abbrüche beim TX / Buffer

Bei Direktverbindung des PC’s (SDRConsole) mit dem Adalm-Pluto (SDR) spielen beide Komponenten einwandfrei miteinander. Latenz ist erträglich (<=100ms) und auch sonst kommt es zu keinen Abbrüchen. Das jedenfalls war meine Erfahrung, wenn man das SetUp ausserhalb des Heimnetzwerks “portabel” betreibt. (Macht übrigens Spass).

Im LAN hier daheim allerdings gab es immer wieder “stuttering”, “cut off transmissions”, “TX Problems” die sich dadurch bemerkbar gemacht haben, dass der TX-Stream immer mal wieder für 100-300ms abreisst.

Erster Workaround: In der Console auf “Half-Duplex” umschalten. Ist allerdings eher suboptimal, da die AFC in der Zeit, in der gesendet wird, nicht arbeiten kann. Ausserdem will man ja ggf. auch mal sein eigenes Signal prüfen.

Abhilfe brachte dann der Tip von DG7YEO (Elmar), doch mal in den Settings der (Managed-)Switches im LAN zu schauen. Eine fast vergessene Funktion (802.3x – FlowControl), die man eigentlich nur noch aus 10MBit-HalfDuplex-Zeiten kennt, soll – bei Aktivierung – das Problemchen lösen.

Genau so war es dann auch. 802.3x auf den relevanten Ports aktiviert, und siehe da – die Probleme sind fort.

Tagged with:
preload preload preload