Lokaler Simplex-Link mit EchoLink

Wer einen Simplex-Link betreibt, wird seinen Link-TRX am eigenen Standort vermutlich mit einem Handfunkgerät ansprechen. Ein OM, der in einiger Entfernung zum Link über HF in ein Echolink-QSO einsteigen möchte, hört zwar den Gesprächspartner über Echolink, aber oft nicht den Linkbetreiber mit seinem Handfunkgerät – und umgekehrt.

Um nun den Funkverkehr aus dem weiteren Umkreis und den Funkverkehr im unmittelbaren Nahbereich des EL-Hotspots zusammenzuführen, benötigt man nicht zwingend eine RepeaterLogic. Man kann auch zwei Transceiver mit jeweils eigenständigen Simplex-Logiken so verlinken, dass ein Empfangssignal von Rx1 auf Tx2 und Rx2 auf Tx1 wiedergegeben wird.

Im Gegensatz zur Funktion X-Band-Repeater einiger Transceiver ist das Logic-Linking bei SvxLink steuerbar: Mit DTMF-Kommandos können die einzelnen Logiken – und damit die TRX – zusammengeschaltet oder getrennt werden. Mit einer zusätzlichen Mike-Speaker-Logic lässt sich zusätzlich ein ortsfestes Bedienteil für QSOs vom Schreibtisch oder aus dem Bastelkeller realisieren.

Nachfolgend wird ein erprobter Aufbau beschrieben:

Auf einem Hauptrechner läuft eine aktuelle Svxlink-Version mit drei Simplex-Logiken.

  • Die erste Logik ist die bekannte SimplexLogic aus der Standard-Konfiguration mit einem Echolink-Modul. Sie steuert den eigentlichen EL-Hotspot mit Rx1, Tx1 auf 430.050 MHz im Nahbereich.
  • Die zweite Logik (RemoteLogic) hat kein Modul EchoLink und greift auf einen 2m-Remotetrx größerer Reichweite zu. Als Remotetrx-Server dient ein Raspberry Pi. Anregung aus http://svxlink.de/?page_id=1228
  • Die dritte Logik ist eine MicSpkr-Logik, die hier http://svxlink.de/?page_id=139 schon beschrieben worden ist. Sie läuft ebenfalls remote auf einem Rechner im Büro.

Die hier gewählte Realisierung über Remotetrx ist nicht zwingend erforderlich, der zweite TRX lässt sich auch direkt über den zweiten Kanal der Soundkarte am Hauptrechner betreiben.

Logic_Remote_Linking

 

Für die Konfiguration sind folgende Schritte durchzuführen:
Zunächst müssen Kopien der Datei SimplexLogic.tcl in /usr/share/svxlink/events.d angelegt werden. Die Dateien werden sinnvoll umbenannt, in der Deklaration von namespace eval …Logic im Kopf der tcl-Datei muss allerdings der exakte Name der jeweiligen neuen Logik eingetragen werden.

Danach ist die svxlink.conf zu ergänzen. Wer seine alte Konfigurationsdatei erhalten möchte, erstellt davon eine Kopie mit dem Dateinamen „svxtest.conf“ (oder ähnlich) und arbeitet damit weiter.

[GLOBAL]
 ...
 LOGICS=SimplexLogic,RemoteLogic,MicSpkrLogic
 LINKS=RemoteLink,MicSpkrLink
 ...

Beschreibung der zusätzlichen Simplex-Logiken

[RemoteLogic]
 TYPE=Simplex
 RX=PiRx1
 TX=PiTx1
 MUTE_TX_ON_RX=0
 # restliche Konfiguration aus SimplexLogic kopieren

[MicSpkrLogic]
 TYPE=Simplex
 RX=NetRx2
 TX=NetTx2
 MUTE_RX_ON_TX=0
 # restliche Konfiguration aus SimplexLogic kopieren

Beschreibung der möglichen Logik-Verlinkungen

[RemoteLink]
 CONNECT_LOGICS=SimplexLogic:91:DL8BBY,RemoteLogic:92:DL8BBY
 DEFAULT_ACTIVE=0
 TIMEOUT=60
 #AUTOACTIVATE_ON_SQL=RemoteLogic
 ## Achtung: Bei DEFAULT_ACTIVE=1 wird die Verlinkung bei manueller
 ## Abschaltung  nach 60 Sekunden automatisch wieder hergestellt
[MicSpkrLink]
 CONNECT_LOGICS=SimplexLogic:93:DL8BBY,MicSpkrLogic:94:DL8BBY
 DEFAULT_ACTIVE=0
 TIMEOUT=60
 AUTOACTIVATE_ON_SQL=MicSpkrLogic
 # SQL ist hier die PTT und die MicSpkrLogic an den EL-Rechner

Beschreibung der zusätzlichen TRX

[NetRx2]
 #futro2 mit Mic=Rx2
 TYPE=Net
 HOST=192.168.1.50
 TCP_PORT=5212
 AUTH_KEY=********
 CODEC=OPUS
 # oder CODEC=S16 bei Verlinkung im häuslichen LAN

[NetTx2]
 #futro2 mit Spkr=Tx2
 TYPE=Net
 HOST=192.168.1.50
 TCP_PORT=5212
 AUTH_KEY=********
 CODEC=OPUS

[PiRx1]
 #raspi1
 TYPE=Net
 HOST=192.168.1.36
 TCP_PORT=5236
 AUTH_KEY=********
 CODEC=OPUS

[PiTx1]
 TYPE=Net
 HOST=192.168.1.36
 TCP_PORT=5236
 AUTH_KEY=********
 CODEC=OPUS

Bei den remote betriebenen Logiken muss jeweils noch die remotetrx.conf auf den abgesetzten Rechnern erstellt werden. Dafür sollte man zunächst die svxlink.conf soweit bearbeiten, dass damit die Funktionen von SQL und PTT sowie die Audioeinstellungen mit der vorgesehenen Hardware am abgesetzten Rechner getestet werden können (z.B. mit Parrot). Aus einer lauffähigen svxlink.conf können dann die Beschreibungen für Rx und Tx in die remotetrx.conf übernommen werden.

[GLOBAL]
 TRXS=NetUplinkTrx
 TIMESTAMP_FORMAT="%c"

[NetUplinkTrx]
 TYPE=Net
 RX=NetRx2
 TX=NetTx2
 LISTEN_PORT=5212
 AUTH_KEY=********

[NetRx2]
 # hier die Rx-Beschreibung aus der svxlink.conf einfügen
 …

[NetTx2]
 # hier die Tx-Beschreibung aus der svxlink.conf einfügen

Nach gleichem Muster wird die remotetrx.conf für den Remote-Transceiver angelegt (im Beispiel PiRx1 und PiTx1).

Die Konfiguration ist damit abgeschlossen und kann ausprobiert werden. Dazu wird auf den abgesetzten Rechnern remotetrx und auf dem Hauptrechner svxlink gestartet. Wenn die Änderungen in einer Kopie „svxtest.conf“ vorgenommen wurden, startet man SvxLink mit

svxlink --config=svxtest.conf

Auf der Konsole sollte man jetzt sehen können, wie neben der bisherigen SimplexLogic auch die neuen Logiken hochgefahren werden. Wenn alles geklappt hat, sind nun die Statusmeldungen von SQL und PTT der lokalen und abgesetzten TRX zu sehen, auch wenn die Logiken noch nicht aktiviert sind.

Sind Module aktiv, z.B. bei einer Echolink-Verbindung, können bestimmte Funktionen wie Logic-Linking oder der QSO-Recorder nicht mehr per DTMF gesteuert werden können. In diesen Fällen müssen die DTMF-Sequenzen mit dem Sternchen * eingeleitet werden. Andere Module, z.B. Parrot, lassen sich bei bestehender EL-Verbindung mit diesem Trick nicht starten.