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 25

Gaaaanz kurze knackige Anleitung, wie man einen PGP/GPG Key beglaubigt  bzw. signiert (unvollständig, und OHNE Anleitung, wie man den Key auf korrektheit prüft – idealerweise signiert Ihr nur Keys, bei denen Ihr 100%ig sicher seid, dass diese auch vom passenden Keyowner kommen 🙂 )

Shell:

[gpg –list-keys] Pub-Key-ID des zu signierenden keys merken

[gpg –sign-key <pubkeyid>] Das eigentliche Signieren

[gpg –send-keys <pubkeyid>] Signieren dem Keyserver bekanntmachen

OSX / GPGTools:

  • GPG Schlüsselbund (GPG Keychain) starten.
  • Rechte Maustaste auf den zu signierenden Key
  • Beglaubigen anclicken, Details entsprechend wählen und OK drücken
  • Wieder rechte Maustaste, diesesmal “Öffentlichen Schlüssel an Schlüsselserver senden”

Der letzte Punkt – also das Veröffentlichen der Beglaubigung, wird gern vergessen. Ohne diesen Schritt ist das ganze jedoch recht witzlos.

[UPDATE]

Bei mehreren uids (Identitäten) pro Key:

  • Doppelclick auf den Key in der Keychain-GUI
  • Wechsel auf den “Benutzer-ID”-Tab
  • Zu bestätigende Identität OBEN auswählen
  • Unten auf das Plus clicken und beglaubigen
  • Anschliessend wieder raus, und “Öffentlichen Schlüssel an Schlüsselserver senden” (s.o.)
Tagged with:
Jun 17

So, es ist vollbracht. Die ganzen Consumer-Provider in good ‘ol Germany wollen ja irgendwie nicht so richtig mit ipv6 an den Start kommen. Also habe ich mal selbst Hand angelegt. Einen Provider hat man schnell gefunden. Ich habe mich für sixxs.net entschieden.

Bei sixxs.net bekommt man zunächst einen /64er Block für lau zugewiesen, den man hinterher auf /48 upgraden kann (Vorraussetzung: der 64er Tunnel läuft eine Woche durch / Downtimes, bspw. zum basteln, sind nicht tragisch). Einfach anmelden, “aiccu” herunterladen, konfigurieren, starten und glücklich sein. Achtung: Aiccu / sixxs.net prüft die Systemzeit – Ein NTP-Client auf dem lokalen Endpunkt hilft da ungemein !

Das 48er-Subnet benötigt man aber nicht wirklich für den Heimgebrauch. Mit dem 64er kann man die restlichen 2^64 Adressen munter im Netz verteilen. Genau da war Anfangs auch mein Denkfehler. Mir war nicht aufgefallen, dass sixxs.net ein Transfernetz zur Vefügung stellt, durch das dass /64er gerouted werden kann. Konkret sieht das ganze nach dem ersten Start wie folgt aus:

  • PtP-Adresse (Da gehts also zu sixxs): 2001:6f8:100:fea::1/128 (Die beiden :: sind die Platzhalter für gaaanz viele Nullen – ausgeschrieben sähe das ganze so aus: 2001:6f8:100:fea:0000:0000:0000:1/128)
  • Lokale Adresse des ersten “ipv6”-Interfaces: 2001:6f8:100:fea::2/64
  • Und jetzt wird’s spannend. Im Webinterface bei sixxs.net kann man sehen, dass das zur Verfügung stehende Netz 2001:6f8:100:dfea::/64 lautet (Man beachte das “d” bei Octet 7)

Mit dem dfea-Netz (die Adressen sind für den Blogeintrag gefaked) können wir nun intern loslurchen und die Rechner ausstatten. Im simpelsten Falle installiert man sich den radvd (Router Advertising Daemon) und konfiguriert sowie startet ihn. Der verteilt die Dinger dann im LAN. Achtung: Dem LAN-Interface muss man selbst eine (v6-)IP aus dem dfea-Netz verpassen (/etc/network/interfaces) – das macht der radvd nicht. Jetzt noch das ipv6-Fowarding enablen (echo 1 >/proc/sys/net/ipv6/conf/all/forwarding) und schon können alle anderen Rechner per ipv6 mit der Welt in Verbindung treten (oder auch angesprochen werden !!)

Was uns zu einem kleinen Schönheitsfehler bringt. Ich will ipv6, weil ich das genNATte und diese ewige dynamische IP-Vergabe leid bin. Dummerweise vergibt der radvd die IP’s aber höchstdynamisch. Statisch verfügbar wäre in diesem Szenario also allenfalls der Router. Schuld (- Die Diskussion will ich hier nicht führen -) sind die sog. “privacy extensions” die irgendwelche paranoiden Mitmenschen entworfen haben. Ich war schon bei v4 kein Freund von “Würfel”-DHCP. Ganz abgesehen davon möchte ICH, und nicht irgendein Billo-Router regeln, wer wann wie worüber ins Netz geht. Bei IP’s die man nicht kennt, ist das ein grausames Unterfangen.

Jetzt gibt es zwei Möglichkeiten aus dem Dilemma herauszukommen.

  1. DHCP-V6 aufsetzen (hab ich noch nicht ausprobiert) und die IP’s statisch den Mac-Adressen im LAN zuordnen.
  2. Den Servern händisch statische IP’s verpassen.
  3. Mischbetrieb aus 2 und radvd

Habe mich erstmal für Variante 3 entschieden. Also jeden Server abgrasen und eine IP aus dem dfea-Netz eintragen, Default(-v6-)Route setzen und testen. Die Arbeitsplatzrechner bekommen die IP’s per radvd, die Server sind statisch verdrahtet. Fein, funktioniert.

Jetzt kommt der fieseste Teil, an dem ich zwei Stunden versenkt habe:

Das ganze ist bei Debian nämlich leider nicht Bootfest, da Linux ganz jeck auf Route-Advertisments ist, und sich dort auch eine IP “ziehen”, wenn sie schon statisch eine abbekommen haben. Hier helft eine Kernel-Einstellung in /etc/sysctl.conf:

net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.autoconf=0

Die alleine macht aber auch noch nicht glücklich, da die sysctls beim booten eingelesen werden sollen. Zu diesem Zwecke linkt man sich die /etc/init.d/procps in die runtimelevel-Dirs (/etc/rcX.d/). Hilft auch noch nicht, weil: Die Einstellungen greifen nur, wenn auch das ipv6-Kernel Modul schon geladen ist – sonst laufen die ins leere 🙁 Hierzu ipv6 in die /etc/modules eintragen. Anschliessend booten – et voila: Es läuft !

Jetzt fehlt eigentlich nur noch eins: Eine ordentliche Firewall mit Connection-Tracking. Gibts wohl demnächst mal einen Blogeintrag drüber. Soviel sei gesagt: Connectiontracking geht erst ab Kernel 2.6.26, redirect (bspw. für transparente Proxies) erst ab 2.6.36…

Somit wäre dieses Blog nun auch via ipv6 erreichbar !

Tagged with:
Aug 26

Mein alter Grill (so ein Baumarkt-Teil für 40 Euro) war schon ein wenig in die Jahre gekommen (ca. 5 Jahre alt). Um den schon durchgerosteten Kohlerost nicht noch weiter zu quälen, haben wir uns mal einen neuen gegönnt. Die Investition von ca. 150 Euro für einen Grill erscheint zwar auf den ersten Blick recht hoch – aber man wird dafür mit einer ganz neuen Sichtweise, was Grillen angeht, belohnt. Dummerweise muss/sollte man das Grillen mit dem Gerät erstmal ganz neu erlernen, denn die Temperaturregelung funktioniert hier etwas anders.

Gibt es beim Baumarktgrill den Rost, der auf- und abgestellt werden kann, so verfügt die Kugel hier über zwei “statische” Roste (Einen für die Kohlen, einen fürs Fleisch). Die Temperatur wird über die Menge der Kohlen und die Stellung zweier Luftklappen geregelt. Prinzipiell lassen sich drei (mal zwei) verschiedene Hitzegrade mit dem guten Stück einstellen:

  1. Grosse Hitze (230-270 Grad): Min. 2 Schichten Grillbriketts übereinander auf den Kohlenrost (vorher mit Anzündkamin durchglühen)
  2. Mittlere Hitze (170-230 Grad): Eine Lage Grillbriketts auf den Kohlenrost (vorher durchglühen)
  3. Niederige Hitze (100-170 Grad): Eine Lage Grillbriketts auf den Rost, vorher durchglühen, oberen Schieber “halb auf”

Die zweite Variante ist dann die indirekte Hitze – Verteilt man die Kohlen nur auf einer Seite des Grills, so hat man auf der Kohlenseite “direkte Hitze”, und auf der anderen “indirekte” – Durch den geschlossenen Deckel kann man dann sogar ganze Braten, etc. auf dem Grill garen. Um die gewünschte Temperatur zu halten, einfach (am besten durchgeglühte) Kohlen nachlegen.

Generell gilt: Den unteren Schieber immer voll aufmachen – geregelt wird allenfalls über den oberen Lüftungsschieber.

Hat man sich einmal an die Temperaturregulierung gewöhnt, gelingen einem Dinge mit dem Grill, von denen man vorher nicht mal wusste, dass man diese überhaupt Grillen kann.

Ich werde mal nach und nach ein paar Rezepte hier einstellen. Zum auf den Geschmack kommen, hier mal ein paar Bilder:

Braten: Braten

Kartoffeln:

Kartoffeln grillen

Tagged with:
preload preload preload