Die Temperatur im Garten, die Regenmenge am Haus und der Wind über dem eigenen Grundstück: Eine Davis Vantage Pro2 liefert Messwerte direkt vom Standort. Für die Hausautomatisierung sind diese Daten besonders interessant. Sie können beispielsweise helfen, die Bewässerung an den tatsächlichen Niederschlag anzupassen oder bei niedrigen Außentemperaturen eine Nachricht auszulösen. Entscheidend ist, wie die Messwerte von der Außeneinheit ins eigene Netzwerk gelangen.

Der klassische Weg über Empfänger, Datenlogger und Computer

Eine etablierte Lösung besteht aus einem Davis-Empfänger, einem WeatherLink-Datenlogger und einem Computer. Beim klassischen USB-Aufbau liest eine Wettersoftware die Daten aus und verarbeitet sie weiter. WeeWX unterstützt dafür Davis-Konsolen und Envoy-Empfänger; mit einer passenden MQTT-Erweiterung lassen sich die Daten auch an die Hausautomatisierung weitergeben. Diese Kombination bietet umfangreiche Möglichkeiten für Wetterarchive und Auswertungen, bringt aber mehrere einzurichtende Bausteine mit. Quellen: Davis Weather Envoy, WeeWX-Anbindung und MQTT-Erweiterung.

Auch die Anschaffungskosten können erheblich sein. Ein konkretes Händlerbeispiel: Die Envoy-Einheit 6316CEU wird für 370 Euro angeboten; der dort empfohlene WeatherLink-Logger mit Software kostet zusätzlich 282 Euro. Zusammen sind das 652 Euro inklusive Mehrwertsteuer, zuzüglich Versand und gegebenenfalls Computer. Dieses Preisbeispiel betrifft ausdrücklich die kabelgebundene Variante. Für Funkstationen gibt es den Funk-Envoy ca 316EU; beide Versionen dürfen beim Vergleich nicht verwechselt werden.

Funk empfangen und per WLAN weitergeben

Das Weather SignalGateway fasst den Empfang und die Weitergabe der Außendaten in einem kompakten Gerät zusammen. Auf Basis eines Heltec empfängt es die unterstützten Funkpakete einer europäischen Davis Vantage Pro2 bei 868 MHz und überträgt die dekodierten Messwerte per WLAN und MQTT. Für diesen Datenweg werden weder eine Davis-Konsole noch ein zusätzlicher USB-Datenlogger oder ein Computer mit WeeWX benötigt.

Home Assistant und der MQTT-Broker bleiben Bestandteil der Hausautomatisierung. Der Broker kann auf demselben System wie Home Assistant laufen. Die optionale Home Assistant Discovery erleichtert die Einrichtung: Bei passend konfigurierter MQTT-Anbindung werden die vom Gateway bereitgestellten Sensoren automatisch angelegt. Home Assistant: MQTT und Discovery.

Was sich damit im Alltag anfangen lässt

Außentemperatur, Luftfeuchte, Windgeschwindigkeit, Windrichtung und Regeninformationen können im Dashboard zusammenlaufen und als Grundlage für eigene Automatisierungen dienen. Bei entsprechend ausgestatteter Außeneinheit kommen UV-Index und Solarstrahlung hinzu. Eine Bewässerungsregel kann beispielsweise die erfasste Regenmenge berücksichtigen; eine Benachrichtigung kann auf Frostbedingungen hinweisen. Solche Abläufe werden in der Hausautomatisierung eingerichtet.

Bis zu zwei MQTT-Broker lassen sich parallel verwenden. Damit können die Daten beispielsweise lokal in Home Assistant und zusätzlich in einer weiteren eigenen Anwendung ankommen. Der lokale MQTT-Betrieb benötigt keinen Wetter-Cloud-Dienst. Wer seine Messwerte öffentlich visualisieren möchte, kann außerdem die integrierten Uploads zu AWEKAS, Weathercloud oder PWSweather nutzen – mit eigenem Konto und Internetverbindung.

Das OLED zeigt ausgewählte Wetterwerte sowie Empfangs- und Verbindungsinformationen direkt am Gerät. Eingerichtet wird das Gateway per Smartphone über einen vorübergehend gestarteten WLAN-Zugangspunkt. Eine Sendersuche hilft dabei, die passende Davis-ID zu finden; das Display lässt sich bei Bedarf automatisch abschalten.

Für welchen Einsatz das Gateway passt

Besonders interessant ist das Gerät für Besitzer einer Vantage Pro2 mit EU-Funk, die ihre vorhandene Außeneinheit in ein MQTT-basiertes Smart Home einbinden möchten. Die bestehende Davis-Konsole kann parallel weiterlaufen. Ein bereits gut eingerichteter Envoy mit Wetterarchiv hat weiterhin seinen Nutzen; der Gewinn des Gateways liegt vor allem in der kompakten Anbindung und dem geringeren Aufwand für zusätzliche Empfangs- und Übertragungsbausteine.

Der Funktionsumfang konzentriert sich auf die Außeneinheit. Luftdruck, Innenwerte und die Vorhersage der Davis-Konsole werden auf diesem Funkweg nicht bereitgestellt. Auch ein vollständiges Langzeitarchiv ersetzt das Gateway nicht. Tagesregen wird aus den empfangenen Regeninformationen berechnet und kann nach einem Start mitten am Tag oder bei Empfangslücken unvollständig sein.

So lässt sich eine vorhandene Wetterstation weiter nutzen und zugleich enger mit dem eigenen Zuhause verbinden: aktuelle Messwerte am Gerät, im Dashboard und dort, wo sie eine Automatisierung sinnvoll ergänzen.

Weather SignalGateway auf Etsy ansehen

Projektvorstellung eines eigenständigen Gateways. Davis, Heltec und die genannten Dienste sind Marken ihrer jeweiligen Inhaber.

In diesem Beitrag beschreibe ich meine komplette Empfangskette unter Ubuntu. Als Empfänger kommt ein RTL-SDR zum Einsatz. SDRangel übernimmt Empfang, NFM-Demodulation, Satellitenverfolgung und die automatische Doppler-Korrektur. Das Audiosignal wird anschließend über ein virtuelles PipeWire-Audiogerät direkt an QSSTV weitergegeben.

Damit funktioniert der komplette Signalweg rein digital:

ISS / ARISS
     │
     │ 437,550 MHz
     ▼
  RTL-SDR
     │
     ▼
  SDRangel
     │
     ├── Satellite Tracker
     │      └── automatische Doppler-Korrektur
     │
     ├── NFM Demodulator
     │      └── virtuelles Audiogerät "SSTV"
     │
     └── optional: zweiter NFM Demodulator
            └── Lautsprecher zum Mithören
                    │
                    ▼
              PipeWire
                    │
              SSTV.monitor
                    │
                    ▼
                  QSSTV
                    │
                    ▼
                SSTV-Bild

Hinweis: Frequenz und Betriebsart können sich je nach ARISS-/ISS-SSTV-Aktion unterscheiden. Die hier beschriebene Konfiguration verwendet 437,550 MHz. Vor einem geplanten Empfang sollte daher immer geprüft werden, welche Frequenz und Betriebsart für die jeweilige Aussendung angekündigt wurde.

Benötigte Hardware und Software

Für meinen Aufbau verwende ich:

• RTL-SDR
• Ubuntu Linux
• SDRangel
• Satellite Tracker in SDRangel
• NFM-Demodulator in SDRangel
• PipeWire
• QSSTV
• eine geeignete Antenne für das 70-cm-Band

Optional verwende ich einen zweiten NFM-Demodulator in SDRangel, damit ich das SSTV-Signal gleichzeitig über die Lautsprecher mithören kann.

Virtuelles Audiogerät für SSTV anlegen

SDRangel muss sein demoduliertes Audiosignal irgendwie an QSSTV weitergeben. Dafür ist kein physisches Audiokabel und auch keine zweite Soundkarte erforderlich.

Unter aktuellen Ubuntu-Versionen übernimmt PipeWire das Audio-Routing. PipeWire stellt gleichzeitig eine PulseAudio-kompatible Schnittstelle bereit, sodass sich mit pactl sehr einfach ein virtuelles Audiogerät erzeugen lässt.

Im Terminal wird dafür folgender Befehl ausgeführt:

pactl load-module module-null-sink \
  sink_name=SSTV \
  sink_properties=device.description="SSTV"

Anschließend kann kontrolliert werden, ob das Gerät angelegt wurde:

pactl list short sinks | grep SSTV

Bei mir sieht die Ausgabe beispielsweise so aus:

24842   SSTV   PipeWire   float32le 2ch 48000Hz   RUNNING

Damit existiert jetzt ein virtuelles Audio-Ausgabegerät mit dem Namen:

SSTV

PipeWire erzeugt gleichzeitig automatisch einen Monitor-Eingang:

SSTV.monitor

Genau dieser Monitor wird später von QSSTV als Audioeingang verwendet.

Der Audio-Signalweg sieht damit folgendermaßen aus:

SDRangel
   │
   ▼
SSTV
   │
   ▼
SSTV.monitor
   │
   ▼
QSSTV

Vorhandene virtuelle Audiogeräte anzeigen

Alle vorhandenen Ausgabegeräte lassen sich mit folgendem Befehl anzeigen:

pactl list short sinks

Die verfügbaren Audioquellen zeigt:

pactl list short sources

Dort sollten anschließend sowohl SSTV als auch SSTV.monitor auftauchen.

Achtung bei mehrfacher Ausführung

Der Befehl zum Erzeugen des virtuellen Audiogerätes sollte nicht mehrfach hintereinander ausgeführt werden. Bei jedem Aufruf wird ein weiteres Null-Sink-Modul erzeugt. Dadurch können anschließend mehrere Geräte mit ähnlichem Namen vorhanden sein.

Die geladenen Module lassen sich kontrollieren mit:

pactl list short modules

SDRangel einrichten

Als Empfänger verwende ich einen RTL-SDR.

Für meinen aktuellen Aufbau sind die grundlegenden Einstellungen ungefähr:

Frequenz:       437,550 MHz
Samplerate:     1 MS/s
Decimation:     8
Gain:           ca. 37–42 dB
LO ppm:         abhängig vom verwendeten RTL-SDR

Die optimale Verstärkung hängt von Antenne, Standort und verwendetem SDR-Stick ab. In meinem Aufbau liegt der Gain beispielsweise bei ungefähr 40 dB.

NFM-Demodulator für SSTV einrichten

In SDRangel wird im RTL-SDR Device Set ein NFM Demodulator hinzugefügt.

Für meinen Aufbau verwende ich ungefähr folgende Parameter:

RF-Bandbreite:   ca. 15 kHz
AF-Bandbreite:   ca. 3 kHz
FM Deviation:    ±5 kHz
Squelch:         möglichst niedrig bzw. offen

In meiner aktuellen Konfiguration liegt die RF-Bandbreite beispielsweise bei rund 14,9 kHz und die AF-Bandbreite bei 3 kHz.

Der entscheidende Punkt ist die Audioausgabe des NFM-Demodulators.

Als Audiogerät wird nicht der normale Lautsprecherausgang verwendet, sondern das zuvor erzeugte virtuelle Gerät:

SSTV

Damit landet das demodulierte Audiosignal direkt im virtuellen PipeWire-Audiogerät.

Zweiten NFM-Demodulator zum Mithören verwenden

Optional kann in SDRangel ein zweiter NFM-Demodulator hinzugefügt werden.

Der erste Demodulator schickt sein Audiosignal an QSSTV:

NFM 1 → SSTV → SSTV.monitor → QSSTV

Der zweite Demodulator kann dagegen auf den normalen Audioausgang des Rechners gelegt werden:

NFM 2 → Lautsprecher

Damit kann man das charakteristische SSTV-Signal während des Empfangs hören, ohne die Audioverbindung zwischen SDRangel und QSSTV verändern zu müssen.

Der zweite Demodulator ist für die eigentliche SSTV-Decodierung nicht erforderlich.

SDRangel-Preset für den ISS-Empfang anlegen

Ein etwas weniger offensichtlicher Punkt bei der Einrichtung ist das Preset-System von SDRangel.

Damit der Satellite Tracker später die vorbereitete Empfangskonfiguration auswählen kann, sollte zunächst ein vollständiges Device-Set-Preset gespeichert werden.

Dazu wird zuerst die komplette gewünschte Konfiguration eingerichtet:

RTL-SDR
Center Frequency: 437,550 MHz

NFM Demodulator 1
Audio: SSTV

optional:
NFM Demodulator 2
Audio: Lautsprecher

Wenn alles korrekt eingestellt ist, wird diese Konfiguration als Preset gespeichert.

Im RTL-SDR Device Set – bei mir R0 – befindet sich dafür das Preset-/Stern-Symbol.

Dort wird ein neues Device-Set-Preset angelegt.

Beispielsweise:

Group: ISS-SSTV
Name:  437.550 - ISS-SSTV

Damit wird die vorbereitete Konfiguration einschließlich der zugehörigen Demodulatoren gespeichert.

Das ist wichtig, weil der Satellite Tracker später genau dieses Preset verwenden kann.

Preset dauerhaft speichern

Nach dem Erstellen des Presets sollte die SDRangel-Konfiguration gespeichert werden.

Je nach SDRangel-Version erfolgt das über die entsprechenden Einstellungen beziehungsweise über:

Preferences → Save all

Danach sollte das Preset auch nach einem Neustart von SDRangel weiterhin zur Verfügung stehen.

Warum das Preset wichtig ist

Der Satellite Tracker kann damit beim Satellitenempfang auf eine fertig konfigurierte Empfangskette zurückgreifen.

Das Preset enthält beispielsweise:

• den verwendeten SDR-Empfänger
• die eingestellte Frequenz
• die NFM-Demodulatoren
• Filtereinstellungen
• Audio-Routing

Dadurch muss die komplette Konfiguration nicht vor jedem Überflug neu aufgebaut werden.

Satellite Tracker hinzufügen

Als nächstes wird in SDRangel das Feature Satellite Tracker hinzugefügt.

Als Satellit wird die ISS ausgewählt.

Target: ISS

Außerdem müssen im Tracker die Koordinaten des eigenen Empfangsstandortes eingetragen werden.

Der Satellite Tracker kann anschließend unter anderem folgende Informationen anzeigen:

• AOS
• LOS
• Azimut
• Elevation
• Flugbahn
• maximale Elevation

AOS und LOS

AOS bedeutet Acquisition of Signal.

Das ist der Zeitpunkt, zu dem der Satellit am eigenen Standort über dem Horizont erscheint.

LOS bedeutet Loss of Signal.

Das ist der Zeitpunkt, zu dem die ISS wieder unter dem lokalen Horizont verschwindet.

Azimut und Elevation

Der Azimut gibt die Richtung auf dem Horizont an.

0°   = Norden
90°  = Osten
180° = Süden
270° = Westen

Die Elevation gibt dagegen die Höhe über dem Horizont an.

0°  = Horizont
45° = halbe Höhe
90° = direkt über dem Beobachter

Im Polar-Diagramm von SDRangel lässt sich dadurch sehr gut erkennen, aus welcher Richtung die ISS kommt und wohin sich die Antenne während des Überflugs orientieren muss.

Preset im Satellite Tracker auswählen

Jetzt kommt der wichtige Schritt: Das zuvor erstellte Device-Set-Preset wird mit dem Satellite Tracker verbunden.

Im Satellite Tracker gibt es dafür den Bereich zur SDRangel-Steuerung.

Dort wird sinngemäß eingestellt:

Satellite:   ISS
Device Set:  R0
Preset:      ISS-SSTV / 437.550 - ISS-SSTV

Das zuvor gespeicherte Preset sollte nun in der Auswahlliste erscheinen.

Falls es dort nicht auftaucht, sollte zuerst kontrolliert werden, ob tatsächlich ein Device-Set-Preset gespeichert wurde und ob sich das Preset in derselben SDRangel-Installation beziehungsweise demselben Profil befindet.

Das ist insbesondere dann relevant, wenn mehrere SDRangel-Versionen parallel installiert sind, beispielsweise Flatpak und eine manuell installierte Version.

Automatische Doppler-Korrektur

Die ISS bewegt sich mit ungefähr 28.000 km/h um die Erde.

Dadurch entsteht beim Funkempfang ein deutlich messbarer Dopplereffekt.

Wenn sich die ISS auf den Empfänger zubewegt, erscheint die empfangene Frequenz etwas höher. Nachdem sie den Beobachter passiert hat und sich wieder entfernt, erscheint die Frequenz etwas niedriger.

Das bedeutet vereinfacht:

ISS nähert sich

437,558 MHz
437,556 MHz
437,554 MHz
437,552 MHz
437,550 MHz
437,548 MHz
437,546 MHz

ISS entfernt sich

Die Werte sind hier nur zur Veranschaulichung dargestellt. Die tatsächliche Verschiebung hängt unter anderem von der relativen Geschwindigkeit zum Beobachter ab.

Ohne Doppler-Korrektur würde das Satellitensignal während des Überflugs durch das Empfangsfilter wandern.

SDRangel kann diese Frequenzverschiebung automatisch kompensieren.

Doppler-Korrektur im Satellite Tracker konfigurieren

Im Satellite Tracker wird der verwendete Demodulator mit der Satellitenverfolgung verbunden.

Für meinen Aufbau ist das:

Satellite: ISS
Channel:   NFMDemod

Zusätzlich wird die tatsächliche Sendefrequenz angegeben beziehungsweise die im Preset gespeicherte Frequenz überschrieben.

Override preset frequency:

437.550 MHz

Der Satellite Tracker verwendet diese Frequenz als Referenz für die Berechnung der Doppler-Korrektur.

Während des Überflugs kann die im SDR angezeigte Frequenz deshalb beispielsweise bei:

437,558 MHz

liegen, obwohl die eigentliche Sendefrequenz:

437,550 MHz

beträgt.

Das ist kein Fehler, sondern genau die gewünschte Doppler-Korrektur.

Der komplette Zusammenhang sieht damit so aus:

Device-Set-Preset
ISS-SSTV
       │
       ▼
Satellite Tracker
       │
       ├── Satellite: ISS
       ├── Device Set: R0
       ├── Preset: ISS-SSTV
       │
       └── Referenzfrequenz: 437,550 MHz
                         │
                         ▼
                Doppler-Berechnung
                         │
                         ▼
                     NFMDemod

QSSTV installieren und einrichten

Die eigentliche Bilddecodierung übernimmt QSSTV.

QSSTV bekommt dabei keinen direkten Zugriff auf den RTL-SDR. Das Programm erhält nur das bereits von SDRangel demodulierte Audiosignal.

Dafür verwenden wir den Monitor unseres virtuellen Audio-Sinks:

SSTV.monitor

Für die Kontrolle des Audio-Routings ist pavucontrol sehr hilfreich.

Falls es noch nicht installiert ist:

sudo apt install pavucontrol

Anschließend starten:

pavucontrol

Nun QSSTV starten.

Im Bereich für aktive Aufnahmeprogramme von pavucontrol sollte QSSTV erscheinen.

Als Aufnahmequelle wird dort eingestellt:

Monitor of SSTV

beziehungsweise:

SSTV.monitor

Damit steht die Audioverbindung:

SDRangel
   │
   ▼
SSTV
   │
   ▼
SSTV.monitor
   │
   ▼
QSSTV

QSSTV-Einstellungen

In QSSTV verwende ich den normalen SSTV-Empfang mit automatischer Synchronisation.

Unter anderem sind bei mir folgende Optionen aktiviert:

Auto Slant:   aktiviert
Autosave:     aktiviert
Sensitivity:  Normal

Solange kein gültiges SSTV-Signal empfangen wird, zeigt QSSTV:

No sync

Das ist völlig normal.

Sobald ein korrektes SSTV-Signal anliegt und die Synchronisationssignale erkannt werden, beginnt QSSTV automatisch mit dem Aufbau des Bildes.

Audioweg vor dem ISS-Überflug testen

Vor einem echten Überflug sollte kontrolliert werden, ob die komplette Audiokette funktioniert.

Zunächst:

pactl list short sinks

Dort sollte das Gerät:

SSTV

auftauchen.

Anschließend:

pactl list short sources

Dort sollte:

SSTV.monitor

vorhanden sein.

In pavucontrol kann zusätzlich kontrolliert werden, ob während der Wiedergabe aus SDRangel ein Audiopegel vorhanden ist.

Auch QSSTV sollte einen entsprechenden Audiopegel anzeigen.

Frequenzfehler des RTL-SDR und Doppler sind zwei verschiedene Dinge

Eine wichtige Unterscheidung ist der Unterschied zwischen Doppler-Korrektur und einem Frequenzfehler des verwendeten SDR-Sticks.

Die Doppler-Korrektur kompensiert:

Bewegung ISS ↔ Empfänger

Die PPM-Korrektur des RTL-SDR kompensiert dagegen:

Frequenzfehler des Oszillators im SDR-Stick

Wenn ein RTL-SDR beispielsweise dauerhaft einige Kilohertz neben der tatsächlichen Frequenz liegt, sollte dieser Fehler über die entsprechende PPM-Korrektur kalibriert werden.

Dadurch muss während eines ISS-Überflugs nicht zusätzlich manuell nachgestimmt werden.

Typischer Ablauf vor einem ARISS-/ISS-SSTV-Überflug

1. RTL-SDR anschließen.
2. Virtuelles Audiogerät SSTV kontrollieren.
3. SDRangel starten.
4. ISS-SSTV-Preset laden.
5. Satellite Tracker öffnen.
6. Als Satellit die ISS auswählen.
7. Device Set und ISS-SSTV-Preset auswählen.
8. 437,550 MHz als Referenzfrequenz kontrollieren.
9. Doppler-Korrektur für den NFM-Demodulator aktivieren.
10. Audioausgang des SSTV-Demodulators auf SSTV stellen.
11. QSSTV starten.
12. QSSTV mit SSTV.monitor verbinden.
13. Audiopegel kontrollieren.
14. Auf AOS der ISS warten.

Ab diesem Zeitpunkt übernimmt SDRangel die laufende Anpassung der Empfangsfrequenz.

Fehlersuche

QSSTV zeigt dauerhaft „No sync“

Zunächst prüfen, ob überhaupt Audio bei QSSTV ankommt.

In pavucontrol sollte beim laufenden SDRangel ein Pegel am entsprechenden Aufnahme-Stream sichtbar sein.

Außerdem kontrollieren:

SDRangel NFM
        ↓
Audio Device: SSTV
        ↓
QSSTV Input: SSTV.monitor

QSSTV bekommt das Mikrofon statt SDRangel

In pavucontrol bei QSSTV die Aufnahmequelle von Mikrofon beziehungsweise Standardgerät auf:

Monitor of SSTV

ändern.

Mehrere SSTV-Audiogeräte vorhanden

Vermutlich wurde der Befehl:

pactl load-module module-null-sink ...

mehrfach ausgeführt.

Die geladenen Module können mit:

pactl list short modules

kontrolliert werden.

Preset erscheint nicht im Satellite Tracker

Prüfen, ob tatsächlich ein Device-Set-Preset gespeichert wurde.

Außerdem kontrollieren, ob Preset und Satellite Tracker innerhalb derselben SDRangel-Installation verwendet werden.

Wer beispielsweise gleichzeitig eine Flatpak-Version und eine manuell installierte SDRangel-Version verwendet, kann unterschiedliche Konfigurationen und Preset-Speicher besitzen.

Das Signal wandert trotz Satellite Tracker

Kontrollieren:

• ist die ISS als Satellit ausgewählt?
• sind die Standortkoordinaten korrekt?
• ist der richtige NFM-Demodulator für die Doppler-Korrektur ausgewählt?
• ist die Referenzfrequenz korrekt?
• ist das richtige Device Set ausgewählt?

Signal ist ständig neben der Sollfrequenz

Dann liegt möglicherweise zusätzlich ein Frequenzfehler des RTL-SDR vor.

Dieser sollte über den LO-PPM-Wert des RTL-SDR korrigiert werden.

Fazit

Mit SDRangel, PipeWire und QSSTV lässt sich unter Ubuntu eine komfortable Empfangsstation für ARISS-/ISS-SSTV aufbauen.

Der große Vorteil von SDRangel ist die Integration des Satellite Trackers. Dadurch kann die Doppler-Verschiebung der ISS automatisch kompensiert werden, anstatt während des gesamten Überflugs die Frequenz manuell nachzuführen.

Auch das Audio-Routing bleibt vollständig digital:

RTL-SDR
   │
   ▼
SDRangel
   │
   ├── Satellite Tracker
   │      └── Doppler-Korrektur
   │
   ▼
NFM Demodulator
   │
   ▼
virtuelles PipeWire-Gerät "SSTV"
   │
   ▼
SSTV.monitor
   │
   ▼
QSSTV
   │
   ▼
SSTV-Bild

Ist die Konfiguration einmal als Preset gespeichert, reduziert sich die Vorbereitung eines Überflugs im Wesentlichen auf das Starten von SDRangel und QSSTV sowie die Kontrolle des Audio-Routings.

Damit eignet sich der Aufbau sowohl für eigene Experimente mit Amateurfunksatelliten als auch für den Empfang von SSTV-Aussendungen im Umfeld von ARISS-Projekten.

Wenn das Passwort eines lokalen Benutzers auf einer Synology DiskStation direkt über die Konsole geändert werden soll, geht das schnell per SSH.

Zuerst per SSH auf der Synology anmelden:

ssh deinuser@192.168.5.3

Anschließend eine Root-Shell öffnen:

sudo -i

Dafür wird noch einmal das Passwort des angemeldeten DSM-Administrators abgefragt.

Ob der gewünschte Benutzer existiert, lässt sich mit folgendem Befehl prüfen:

synouser --get BENUTZERNAME

Alle lokalen Benutzer können so angezeigt werden:

synouser --enum local

Das eigentliche Passwort wird anschließend mit dem Synology-Werkzeug synouser geändert:

synouser --setpw BENUTZERNAME 'NEUES_PASSWORT'

Beispiel:

synouser --setpw ki 'MeinNeuesPasswort123!'

Warum synouser statt passwd?

DSM verwaltet seine Benutzer über eigene Systemwerkzeuge. Deshalb sollte für lokale Synology-Benutzer bevorzugt synouser --setpw verwendet werden, anstatt direkt mit dem klassischen Linux-Befehl passwd zu arbeiten.

Damit lässt sich ein vergessenes oder zu änderndes Benutzerpasswort schnell direkt über die SSH-Konsole der Synology setzen.

Wer einen Yaesu FT-991A besitzt, weiß seine Vielseitigkeit zu schätzen. Kurzwelle, 6 Meter, 2 Meter und 70 Zentimeter in einem Gerät – damit gehört der FT-991A seit Jahren zu den beliebtesten Allround-Transceivern im Amateurfunk.

Weniger beliebt ist allerdings die Speicherverwaltung. Direkt am Gerät größere Änderungen vorzunehmen, kostet Zeit und Geduld. Viele Funkamateure haben sich deshalb schon lange eine Unterstützung durch CHIRP gewünscht. Genau daraus ist dieses Projekt entstanden.

Warum überhaupt ein neuer CHIRP-Treiber?

CHIRP unterstützt eine beeindruckende Anzahl von Funkgeräten. Beim FT-991A gibt es jedoch eine Besonderheit: Yaesu stellt keinen klassischen Clone-Modus zur Verfügung, wie ihn CHIRP normalerweise verwendet. Genau deshalb existierte bislang keine vollständige Unterstützung.

Anstatt auf undokumentierte Tricks zurückzugreifen, verfolgt dieses Projekt einen anderen Weg. Der Treiber kommuniziert ausschließlich über die dokumentierte CAT-Schnittstelle und erstellt daraus ein CHIRP-Image. So lassen sich Speicherkanäle und zahlreiche Geräteeinstellungen bequem am Rechner bearbeiten.

Das Ergebnis fühlt sich für den Anwender wie ein normaler CHIRP-Treiber an – technisch steckt jedoch deutlich mehr dahinter.

Was der Treiber bereits kann

Auch wenn sich das Projekt noch in der Entwicklung befindet, funktioniert bereits ein großer Teil der gewünschten Funktionen.

Unter anderem können aktuell:

• Speicherkanäle ausgelesen werden
• PMS-Speicher übernommen werden
• mehr als 150 Menüeinstellungen gesichert werden
• komplette CHIRP-Images erstellt werden
• Speicherlisten als CSV exportiert werden
• Einstellungen offline bearbeitet werden
• unterstützte Änderungen wieder zurück auf das Funkgerät übertragen werden

Besonders angenehm ist dabei der Arbeitsablauf: Zunächst werden alle Daten vom Funkgerät gelesen. Anschließend kann das Gerät getrennt werden und sämtliche Änderungen erfolgen in Ruhe am Computer. Erst wenn alles fertig ist, werden die gewünschten Änderungen wieder auf den FT-991A übertragen.

Sicherheit statt Experimente

Gerade beim Schreiben auf ein Funkgerät gilt: Lieber etwas vorsichtiger als ein beschädigter Speicher.

Deshalb verwendet der Treiber ausschließlich dokumentierte CAT-Befehle. Auf undokumentierte Schreibzugriffe wurde bewusst verzichtet. Wo Yaesu über die CAT-Schnittstelle Grenzen setzt, akzeptiert der Treiber diese auch. Das macht die Entwicklung zwar aufwendiger, sorgt aber für ein deutlich besser nachvollziehbares und sichereres Verhalten.

Ein Projekt für die Community

Open Source lebt vom Mitmachen.

Da es zahlreiche Firmwarestände und unterschiedliche Gerätekonfigurationen gibt, ist Feedback aus der Praxis besonders wertvoll. Wer einen FT-991A besitzt, kann das Projekt bereits heute ausprobieren und mit Tests, Fehlerberichten oder Verbesserungsvorschlägen unterstützen.

Je mehr unterschiedliche Geräte getestet werden, desto stabiler und vollständiger wird der Treiber.

Auch Entwickler sind natürlich herzlich eingeladen, sich mit Pull Requests oder eigenen Ideen einzubringen.

Installation

Die Installation ist bewusst unkompliziert gehalten. Das Repository kann direkt von GitHub geklont oder als ZIP-Datei heruntergeladen werden. Für Linux steht zusätzlich ein Installationsskript bereit, das den Treiber automatisch in CHIRP integriert.

Eine ausführliche Dokumentation erklärt außerdem Installation, Bedienung, bekannte Einschränkungen und den technischen Hintergrund.

Dieses Projekt soll eine Lücke schließen, die viele FT-991A-Besitzer seit Jahren kennen. Ziel ist es nicht, bestehende Software zu ersetzen, sondern eine offene und transparente Lösung bereitzustellen, die sich möglichst nahtlos in den gewohnten CHIRP-Workflow integriert.

Noch ist nicht jede Funktion umgesetzt, doch der aktuelle Entwicklungsstand zeigt bereits, was mit der dokumentierten CAT-Schnittstelle des FT-991A möglich ist.

Wer das Projekt ausprobieren oder sich an der Weiterentwicklung beteiligen möchte, findet den Quellcode auf GitHub:

GitHub:
https://github.com/g3orgs/FT-991A-YAESU-chirp

Über Feedback, Tester und Mitstreiter aus der Amateurfunk-Community freue ich mich jederzeit. Gemeinsam lässt sich die Unterstützung des FT-991A Stück für Stück weiter verbessern.

Grundlage ist der angepasste Adafruit nRF52 Bootloader mit verbessertem
OTA/DFU-Support, wie er hier beschrieben ist: (optional)
https://meshcore-de.fyi/meshcore:allgemeines:adafruit-nrf52-bootloader-mit-verbessertem-ota-dfu

Voraussetzungen

• Meshcore Repeater mit nRF52840
• Installierter OTA-fähiger Bootloader
• Android-Smartphone
• App nRF Device Firmware Update
• Meshcore Firmware im passenden DFU-Format

Repeater in den OTA-Modus versetzen

Bevor das Android-Tool genutzt werden kann, muss der Repeater manuell in den
OTA-Modus gebracht werden.

Dazu auf der Kommandoebene (CLI) des Repeaters folgenden Befehl eingeben:

ota start

Der Repeater wechselt anschließend in den OTA-/DFU-Modus und wartet auf eine neue
Firmware. Erst jetzt ist er für das Android-Tool sichtbar.

OTA-Update mit Android durchführen

Die App nRF Device Firmware Update auf dem Android-Gerät starten

1. Den Repeater aus der Geräteliste auswählen
2. Einmalig die Settings korrekt setzen
3. Die neue Firmware-Datei auswählen
4. Flash-Vorgang starten

Während des Updates sollte die Bluetooth-Verbindung nicht getrennt werden und
die App im Vordergrund bleiben. Geduld ist ebenfalls gefragt.

Und ganz wichtig: Daumen drücken nicht vergessen

Wenn alles erfolgreich abgeschlossen ist, startet der Repeater automatisch neu
und läuft anschließend mit der neuen Firmware.

Versuch mit Adafruit_nRF52_Bootloader_OTAFIX

Ich habe zusätzlich versucht, den alternativen Bootloader https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX zu verwenden, um OTA-Fixes einzuspielen.

Ergebnis:
Der Bootloader ließ sich nicht zuverlässig „fixen“ bzw. patchen.

Somit ist dieser Weg zwar dokumentiert, aber nicht stabil nutzbar. Er birgt das Risiko, dass das Gerät im Bootloader-State hängen bleibt, was bedeutet:

Du müsstest das Gerät dann über USB direkt ansprechen, um es wiederherzustellen

Was ich allerdings nicht reparieren kann, ist die konsequente Entscheidung vieler Leute, ihre Bildschirme mit dem Handy zu fotografieren.

Ich weiß nicht, wann das angefangen hat. Vielleicht wurde das heimlich in einem Update ausgerollt. Vielleicht gibt es irgendwo einen geheimen Kurs mit dem Titel „Digitale Kommunikation für Fortgeschrittene – Modul 3: Wie ich Support maximal ineffizient gestalte“. Anders kann ich mir das kaum erklären.

Typischer Ablauf: Ich bekomme eine Nachricht mit dem Inhalt „Mein PC geht nicht mehr“. Dazu ein Foto. Dieses Foto wurde offensichtlich während eines mittelschweren Erdbebens aufgenommen, leicht diagonal aus der Hüfte geschossen, mit perfekter Spiegelung der Wohnzimmerdecke und einem Fokus, der sich entschieden hat, lieber den Staub auf dem Monitorrahmen scharf darzustellen als die Fehlermeldung selbst. Die Fehlermeldung ist natürlich halb abgeschnitten, denn warum sollte man das komplette Problem zeigen, wenn man auch nur den spannendsten Teil fotografieren kann – zum Beispiel die Worte „Fatal Error“, ohne den komplett unwichtigen Rest wie Ursache oder Fehlercode.

Ich sitze dann davor und versuche aus diesem visuellen Rätsel die technische Realität zu rekonstruieren. Es fühlt sich ungefähr so an, als würde man versuchen, einen Kriminalfall zu lösen, bei dem alle Beweise durch einen Instagram-Filter geschickt wurden.

Screenshots sind keine Raketenwissenschaft

Was viele nicht wissen: Betriebssysteme besitzen seit geraumer Zeit eine eingebaute Funktion namens Screenshot. Diese funktioniert erstaunlich zuverlässig. Sie erstellt ein Bild des Bildschirms. Scharf. Gerade. Lesbar. Ohne Reflexionen von Stehlampen oder verschwommene Katzen im Hintergrund. Diese Technologie existiert übrigens nicht erst seit gestern. Sie begleitet uns schon so lange, dass selbst Windows sie irgendwann verstanden hat.

Ein echter Screenshot hat außerdem den angenehmen Nebeneffekt, dass man Dinge lesen kann. Manchmal kann man Fehlermeldungen sogar kopieren. Ich weiß, das klingt futuristisch, aber tatsächlich beschleunigt das Fehlersuche enorm. Ein unscharfes Handyfoto hingegen zwingt mich dazu, kryptische Pixelmuster zu entziffern wie ein Historiker, der versucht, eine beschädigte Keilschrifttafel zu übersetzen, während jemand im Hintergrund nervös fragt, ob das Problem nicht „mal schnell“ gelöst werden kann.

Kontext ist kein optionales Feature

Besonders faszinierend wird es, wenn das Foto ohne jeglichen Kontext verschickt wird. Dann folgt auf meine vorsichtige Nachfrage meist eine Antwort wie „Na, geht halt nicht“. Das ist ungefähr so hilfreich, als würde man beim Arzt erscheinen, schweigend auf den eigenen Körper zeigen und erwarten, dass sofort die richtige Diagnose gestellt wird.

Betriebssystem, Version, Programm oder eine kurze Beschreibung dessen, was eigentlich passieren sollte, wirken auf den ersten Blick vielleicht wie unnötige Details, erhöhen aber die Wahrscheinlichkeit einer erfolgreichen Problemlösung dramatisch.

Ein sehr klares Statement zu Sprachnachrichten

Ein weiteres Kapitel dieser epischen Saga sind Sprachnachrichten. Ich möchte das hier einmal sehr klar formulieren, um spätere Missverständnisse zu vermeiden: Ich höre keine Sprachnachrichten ab. Wirklich nicht. Auch nicht später. Auch nicht „wenn ich mal Zeit habe“. Auch nicht in doppelter Geschwindigkeit, rückwärts oder unter Zuhilfenahme forensischer Audiotechnik.

IT-Support lebt davon, Informationen nachlesen zu können. Eine fünfminütige Audioaufnahme, in der irgendwo zwischen Kaffeemaschine, Straßenlärm und Rascheln einer Jacke beiläufig eine Fehlermeldung erwähnt wird, ist für Fehlersuche ungefähr so geeignet wie Morsecode über einen Presslufthammer.

Desktop-Kommunikation – Der unterschätzte Endgegner

Dabei wäre alles so einfach. Moderne Messenger lassen sich auf Desktops öffnen. Dort kann man Screenshots einfügen, Texte vernünftig schreiben und Fehlermeldungen direkt übernehmen. Es ist ein gewaltiger zivilisatorischer Fortschritt gegenüber der Methode „Ich fotografiere meinen Monitor wie ein seltenes Naturphänomen und schicke das dann kommentarlos weiter“.

Zum Abschluss ein ehrlicher Gedanke

Ich verstehe ja, dass viele Dinge schnell gehen sollen. Ich verstehe auch, dass nicht jeder täglich mit Technik arbeitet. Aber glaubt mir: Ein sauberer Screenshot spart Zeit, Nerven und erhöht massiv die Wahrscheinlichkeit, dass ich das Problem erkenne, bevor mein Kaffee kalt wird und meine Geduld in den Energiesparmodus wechselt.

Ich helfe wirklich gern. Ehrlich. Aber wenn ich irgendwann anfange, Fehlermeldungen anhand der Spiegelung eurer Wohnzimmerlampen zu analysieren, dann ist das kein Zeichen besonderer Kompetenz, sondern ein Hilferuf.

Netzwerkkarte und Knotendarstellung

Eine der zentralen Funktionen ist die Kartenansicht. Dort werden aktive Nodes mit ihrer Position sowie deren Verbindungen dargestellt. Besonders hilfreich ist die Hop-Darstellung zwischen den Knoten. Damit lässt sich schnell erkennen, welche Nodes besonders wichtig für das Routing sind und als zentrale Weiterleitungsstation fungieren. Ebenso fallen Funklöcher oder schlecht angebundene Regionen oft sofort auf.

Gerade beim Aufbau von Repeatern oder Gateways hilft diese Übersicht bei der Standortplanung. Oft zeigt sich erst in der Praxis, dass ein vermeintlich guter Standort durch Gelände, Bebauung oder Abschattungen schlechter funktioniert als erwartet.

Packet-Tracking und Ausbreitungsanalyse

Ein spannender Bereich im Analyzer ist das Nachverfolgen einzelner Nachrichtenpakete. Hier sieht man, über welche Nodes eine Nachricht transportiert wurde und wie viele Hops nötig waren, bis sie ihr Ziel erreicht hat.

Das ist besonders praktisch bei Reichweitentests: Wenn man zwei Standorte miteinander verbinden möchte, kann man nachvollziehen, ob Nachrichten direkt oder über Zwischenstationen laufen. Gleichzeitig lassen sich ineffiziente Routingpfade oder Paketverluste sichtbar machen. Für Feldtests liefert das wertvolle Hinweise, wie sich Funkwellen in unterschiedlichen Umgebungen ausbreiten.

Observer Nodes

Damit der Analyzer überhaupt Daten anzeigen kann, werden Observer benötigt. Das sind Nodes, die Netzwerkdaten sammeln und an die Analyseplattform weitergeben. Diese Observer können zum Beispiel auf Repeatern oder festen Standorten betrieben werden.

Kurzanleitung

1. Die Observer-Seite im Analyzer öffnen.
2. Das gewünschte Gerät bzw. den Node-Typ auswählen.
3. Die generierte Konfiguration übernehmen.
4. Die Konfiguration in der MeshCore Firmware eintragen.
5. Node neu starten und kurz warten, bis Daten im Analyzer auftauchen.

Typische Einsatzszenarien

• Standortplanung für neue Repeater
• Optimierung bestehender Verbindungen (Antenne, Höhe, Position)
• Langstrecken-Tests zwischen Städten oder Regionen
• Überwachung wachsender Community-Netze
• Fehlersuche bei Routing- und Verbindungsproblemen

Gerade bei größeren Mesh-Netzen zeigt eine Visualisierung oft erst, wie sich das Netzwerk tatsächlich verhält – und welche Nodes wirklich entscheidend für Stabilität und Reichweite sind.

Unter Ubuntu 22.04 kann es vorkommen, dass der Standard-Dokumentenbetrachter Evince keine Dokumente mehr druckt. Besonders auffällig ist dabei, dass der Drucker selbst korrekt funktioniert und Testseiten problemlos ausgibt – normale Dateien wie PDFs jedoch nicht gedruckt werden.

Mögliche Ursache

Häufig liegt das Problem an fehlerhaften oder beschädigten Druckeinstellungen, die Evince lokal speichert.

Lösung 1: Druckeinstellungen zurücksetzen

Die gespeicherten Druckeinstellungen lassen sich einfach löschen. Beim nächsten Start werden diese automatisch neu erstellt.

rm -r ~/.config/evince/print-settings

Anschließend sollte der Dokumentenbetrachter neu gestartet und ein erneuter Druckversuch durchgeführt werden.

Lösung 2: Alternativen PDF-Betrachter verwenden

Falls das Problem weiterhin besteht oder häufiger auftritt, kann es sinnvoll sein, auf einen alternativen PDF-Betrachter auszuweichen. Bewährte Alternativen sind:

• Atril
• qpdfview

Diese lassen sich bequem über die Paketverwaltung installieren:

sudo apt install atril

sudo apt install qpdfview

Fazit

Wenn der Drucker Testseiten ausgibt, liegt das Problem meist nicht an der Druckerkonfiguration, sondern an lokalen Einstellungen des Dokumentenbetrachters. Das Zurücksetzen der Evince-Druckeinstellungen oder der Wechsel auf eine alternative Anwendung behebt das Problem in den meisten Fällen schnell.

Viele nutzen ihre DiskStation nicht nur als Datenspeicher, sondern auch zur Automatisierung von Backup-Prozessen. In meinem Setup wird ein externes Backup-NAS bei Bedarf automatisch per Wake-on-LAN (WOL) durch ein benutzerdefiniertes Skript gestartet. Dadurch läuft das Backup nur dann, wenn es wirklich benötigt wird – energiesparend und effizient.

Nach dem Update auf DSM 7 musste ich allerdings feststellen, dass die bekannte Binary ether-wake nicht mehr Bestandteil des Systems ist. Synology hat diese Funktion inzwischen in das interne Tool synonet integriert. Wake-on-LAN lässt sich damit weiterhin problemlos nutzen, nur mit einem anderen Befehl.

Wake-on-LAN mit synonet verwenden

Um einen entfernten Rechner oder ein NAS über die DiskStation aufzuwecken, kann man sich per SSH auf der DiskStation anmelden und folgenden Befehl ausführen:

sudo synonet --wake E8:D8:D1:42:27:73 eth0

Hinweise:

• Die MAC-Adresse muss durch die Adresse des Zielgeräts ersetzt werden.
• eth0 beschreibt das Netzwerkinterface, über das das Wake-Signal gesendet wird.

Bestehende Automationen funktionieren damit weiterhin zuverlässig – es muss lediglich der neue Befehl berücksichtigt werden.

Obwohl ihr euch sicher seid, dass ihr das richtige Kennwort nutzt, kommt ihr nicht in den Cloud Key?
Versucht doch mal den Zugang per

ssh root@IP

ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 106820 Feb  2 00:24 /usr/bin/sudo
chmod u+s /usr/bin/sudo

Danach sollte der Zugang zum Webinterface wieder funktionieren.