fm-funknetz:technik:running_repeaters [Wiki FM-Funknetz]

Hier erfolgen einige Hinweise zur Konfiguration öffentlicher Relaisfunkstellen, die am FM-Funknetz teilnehmen. Um einen störungsfreien Betrieb weitgehend sicherzustellen, auch aus Rücksichtnahme anderer Teilnehmer am FM-Funknetz, werde ich diese hier etwas als Hilfestellung für die Sysops dieser Relais aufbereiten.

Die Frage, wie ich ein Relais anzusprechen bzw. zu öffnen und zu benutzen habe, ist natürlich eine Entscheidung des Sysops bzw. des Betreiberteams.

2.1 Hardware-Squelch mit oder ohne 1750Hz Rufton

Die „klassischen“ Varianten, ein FM-Relais zu öffnen, sind

rein trägergesteuert, also ein anliegendes FM-Signal öffnet den Repeater ohne weiteres Zutun
per 1750Hz Rufton (engl. TBST „Toneburst“) mit einer gewissen Länge der Aussendung
ferner per DMTF

Diese Verfahren werden heute immer noch häufig verwendet, beinhalten aber ein gewisses Problempotential systembedingt in sich. Kommt es aufgrund von Störsignalen auf der RX-Seite zu unerwünschten Öffnungen des Repeaters bei rein trägergesteuerten Relais oder bleibt die Squelch des Repeaters nach Öffnen per 1750Hz auch aufgrund von Störsignalen offen und schließt nicht mehr, führen diese Situationen zu Übertragungen in das gesamte Verbundsystem bzw. der aktiv am Repeater gewählten Sprechgruppe und stört damit gleichzeitig auch alle dort verlinkten und aktiven, weiteren Systeme wie andere Relais oder auch Hotspots.

Da diese Probleme jedem Sysop bewußt sein sollten, sollte man - so meine Empfehlung - generell über eine Steuerung per CTCSS (oder DCS) nachdenken. Bereits im Jahre 2013 wurde von den Mitgliedsländern der IARU Region 1 in einer Konferenz die klare Empfehlung ausgesprochen, FM-Relais prinzipiell mittels CTCSS zu steuern. Diese Empfehlung ist praktisch seit dem 1.1.2015 gültig und gilt eigentlich für alle nach diesem Datum in Betrieb gesetzten FM-Relais. Aber auch eine Umstellung bisheriger FM-Relais ist Bestandteil dieser IARU-Reg.1-Empfehlung. Ja, es ist eine Empfehlung und keine Verpflichtung.

2.2 Einsatz einer CTCSS-Squelch (empfohlen)

Ein CTCSS-Squelch öffnet grundsätzlich nur, wenn der eingestellte Subaudio-Ton decodiert wird und schließt sofort, wenn dieser durch Beendigung der Aussendung fehlt. Störsignale bzw. -träger an sich führen also nicht mehr zu einem unkontrollierten Betriebszustand wie unter 2.1 beschrieben. Moderne Transeiver verfügen auch meist über eine NF-Filterung, so daß dieser Subaudio-Ton im Bereich 67Hz-260Hz nicht im Lautsprecher des Funkgerätes wahrgenommen wird.
SVXLINK bietet hier zwei Optionen, CTCSS-Auswertung zu nutzen:

per Softwaredecodierung direkt im SVXLINK
per Hardware-Decodierung im RX (sofern vorhanden und möglich) und Meldung des SQL-Signalzustands (OFFEN oder GESCHLOSSEN) per Schaltsignal aus dem RX

Meine Empfehlung liegt klar beim Einsatz einer Hardware-Auswertung direkt im RX, meist werden dort Decoder-ICs eingesetzt, die selbst bei sehr schwachen Signalen um S1 noch eine zuverlässige CTCSS-Decodierung ermöglichen, die Softwarelösung im SVXLINK ist nach meinen Tests leider nicht ganz so zuverlässig.

Liebe Sysops, denkt bitte daran, unkontrollierte Aussendungen (z.B. durch Störsignale) sind zu vermeiden, so steht es im AfuG und AfuV für automatisch arbeitende Amateurfunkstellen. Der Lizenzinhaber ist in solchen Fällen letztlich verpflichtet, diese Aussendungen zu unterbinden und muss geeignete Maßnahmen ergreifen, um den weiteren Betrieb eines Relais ohne Funktionsstörungen sicherzustellen. Einfach mal so weiterlaufen lassen, trotz Störungen, ist also nicht.

Der Einsatz einer CTCSS-Squelch würde also eine Menge Probleme vermeiden helfen, der Nutzen ist letztlich erheblich höher als die Nachteile. Außerdem schützt es auch den ganzen Verbund vor unerwünschten Übertragungen durch gestörte Repeater, deren SQL eben offen bleibt und dann einfach Rauschen oder gar das empfangene Störsignal in den ganzen Verbund transportiert. Wir können davon ausgehen, das diese Problematik künftig an Häufigkeit zunehmen dürfte, besonders im VHF-Bereich ist das jetzt schon, Tendenz leider zunehmend, zu beobachten.

Also meine klare Empfehlung, wenn keine anderweitigen triftigen Gründe dagegensprechen, nutzt generell CTCSS als SQL-Auswerteverfahren.

Jetzt kommt der wichtige Teil bei FM - das zu übertragende Audio, also dessen Lautstärke und Qualität, sowohl RX-seitig als auch TX-seitig.
Der übertragende Audio bzw. dessen Qualität ist unsere Visitenkarte des Repeaters !
In einem Verbund ist es wichtig und notwendig, das alle Systeme annähernd auf gleichem Pegel laufen, um gravierende Lautstärkeunterschiede möglichst zu vermeiden.
Bitte unbedingt beachten:

macht keine Tests auf reichweitenstarken TG wie der 777 oder den Regional-TGs wie 262x
nutzt bitte dafür die TG20 und bittet andere OM, euer Audio zu bewerten (auf dieser TG)

Einige Soundkarten haben Effektprozessoren eingebaut wie 3D-Audio, AGC oder regelbare Vorverstärker (ADC). Nach Möglichkeit diese Effekte alle AUSSCHALTEN bzw. Pegel für Signalverstärkung möglichst auf 0db einstellen ! Andernfalls kann es ebenfalls zu Verzerrungen oder unerwünschten Nebeneffekten bei der Audiosignalverarbeitung kommen. Leider hilft hier nur, sich einzulesen, was der eingesetzte Soundchip so an Zusatzfunktionen mitbringt. Es hilft auch schon, mal alle ALSAMixer-Einstellungen durchzugehen (F5 drücken) und zu schauen, was da so alles möglich ist und was man ggf. nicht benötigt bzw. deaktivieren kann.

Generell ist es ja nun so, das FM-Relaisfunkstellen per Lizenzauflagen eine Kanalbandbreite von 12.5kHz einzuhalten haben. Das gilt generell für 2m-Relais, aber inzwischen auch für 70cm-Relais, die im Bereich 438.550-439.5875 MHz bei -7.6Mhz Ablage genehmigt werden. Einzige Ausnahme sind Relais im Bereich 439.8125-439.975 MHz bei einer Ablage von -9.4MHz, wo immer noch 25KHz Bandbreite zulässig sind. Letztere sind eher selten anzutreffen, aber es gibt sie.

Im Verbund müssen wir aber davon ausgehen, das wir alle mit 12.5kHz unterwegs sind. Das bedeutet, der max. FM-Hub beträgt 2.5kHz und nicht wie früher bei 25kHz 5kHz. Weniger FM-Hub bedeutet systembedingt auch weniger Laustärke, es „klingt“ also etwas leiser. Gefällt nicht jedem - muss aber so sein. Es betrifft aber beide Teile eines Relais, sowohl den RX als auch den TX, um Störungen anderer Relais im Nachbarkanal zu vermeiden.

Stellt also bitte die Audiopegel am SVXLINK so ein, das die Bandbreite bei Aussendungen nicht 12.5kHz überschreitet und überprüft das am besten mit einem Spektrumanalyzer oder, wenn nicht verfügbar, mit einem guten SDR-Empfänger, der das ebenfalls sichtbar machen kann (bei Messungen im Nahfeld ein Abdämpfen des SDR-RX nicht vergessen, um den SDR-RX nicht zu übersteuern, sonst ist die Messung nicht brauchbar aufgrund unerwünschter Mischprodukte im SDR-RX bei Übersteuerung).

Hier mal eine Messung per SDR (SDRPlay RSP2Pro), das grüne Rechteck markiert die Bandbreite von 12.5kHz, gemessen wurde hier ein YAESU DR1XE im FM-Betrieb:

Was wir unbedingt prüfen sollten, ist das Level des Audio-IN, welches vom RX kommt. Dazu ist es notwendig, dessen SQL ganz zu öffnen, damit wir das Rauschen des RX bzw. dessen Pegel messen können.
Dafür können wir uns einem VU-Meter bedienen, was auf der Konsole den Pegel anzeigen kann.
Zuerst müssen wir dafür das SVXLINK stoppen, sonst haben wir keinen Zugriff auf den Audio-IN:

$ sudo systemctl stop svxlink.service

Im Falle der ELENATA, die 2 Kanäle besitzt, meist als Sounddevice 0 gelistet wird, würde das VU-Meter so aufzurufen sein:

$ sudo arecord -D hw:0 -V stereo -f S16_LE -c2 -r48000 /dev/null

Was wir jetzt sehen, ist die Aussteuerung der Soundkarte, wenn wir das Rauschen vom RX messen:

Aufnahme: WAVE '/dev/null' : Signed 16 bit Little Endian, Rate: 48000 Hz, mono
######################################       +     | 89%

Es sollte nicht wesentlich über 90% gehen, anderenfalls ist der Audio-IN am ALSAMIXER etwas abzusenken. Das vermeidet Übersteuerungen der Soundkarte bzw. deren ADC.
Übersteuerungen sollten vermieden werden, das führt zu Verzerrungen in der Signalverarbeitung und damit zu einer Verschlechterung unserer Audioqualität des Repeaters. Das wollen wir ja möglichst vermeiden.

4.1 Unerwünschte Aussendungen in den Verbund vermeiden !

Funktionen wie die ECHO-Funktion („Parrot“) oder die Info-Ansagen können, wenn sie nicht richtig konfiguriert sind, unerwünschte Übertragungen in den ganzen Verbund verursachen. Das gilt es in jedem Fall zu vermeiden, denn es ist nicht erwünscht - das Störungspotenial ist einfach zu hoch. Ungünstigerweise sind diese Optionen per default leider auskommentiert und damit eben NICHT aktiv, es würde also ohne die folgenden Anpassungen eine Übertragung in den Verbund/die Sprechgruppe erfolgen.
Dazu bitte in folgenden, beiden(!) Konfigurations-Dateien

/etc/svxlink/svxlink.d/ModuleParrot.conf
/etc/svxlink/svxlink.d/ModuleHelp.conf

folgende Änderung unbedingt eintragen bzw. anpassen:

# 1 bedeutet stummschalten also Verbund automatisch deaktivieren oder 0 Verbund bzw. Sprechgruppe bleibt aktiv
MUTE_LOGIC_LINKING=1

Im Grunde gilt das weiterführend auch für andere Module wie ModuleTclVoiceMail.conf, ModuleMetarInfo.conf, ModulePropagationMonitor.conf - sofern diese überhaupt genutzt werden sollen. Es schaltet natürlich nicht diese Funktionen ab - sie bleiben weiterhin nutzbar - aber es wird eben nicht in den ganzen Verbund/aktuelle Sprechgruppe übertragen, sondern nur lokal am Hotspot/Relais.

Bei aktiviertem ECHOLINK:
Auch in der /etc/svxlink/svxlink.d/ModuleEchoLink.conf gibt es diese Option MUTE_LOGIC_LINKING. Hier allerdings ist die Ausgangslage etwas anders, denn der Sysop muss entscheiden, ob für eingehende/ausgehende ECHOLINK-Verbindungen eine Aufschaltung in den ganzen Verbund bzw. der aktiven Sprechgruppe gewünscht sind (MUTE_LOGIC_LINKING=0) oder nicht (MUTE_LOGIC_LINKING=1).

Weiterhin sind in der /etc/svxlink/svxlink.conf Aussendungen wie DTMF-Töne und 1750Hz-Rufton stummzuschalten, um diese nicht in den ganzen Verbund zu übertragen:

[Rx1]
...
DTMF_MUTING=1
1750_MUTING=1
...

4.2 Rauschsperre richtig anwenden und einstellen !

Verwendet am besten Verfahren wie CTCSS, denn diese Verfahren öffnen den SQL nur dann, wenn ein entsprechendes Auswertesignal vorliegt, wie im Falle CTCSS eben der eingestellte Subaudioton. Somit bleiben Störsignale außen vor und das Relais öffnet nicht mehr unkontrolliert seine SQL. Die anderen Relaisbetreiber, Sysops und auch die anderen Nutzer werden es euch danken.

In der /etc/svxlink/svxlink.conf dazu folgendes eintragen/anpassen:

[Rx1]
# Relais: stoppt unkontrolliertes Auftasten des Senders, SQL muss mind. 200ms lang offen sein
SQL_DELAY=200
# SQL_ZU sofort signalisieren ohne Verzug
SQL_HANGTIME=0
# SQL schliesst evtl zu langsam, also schneiden wir 100ms Audio weg, reicht das nicht, dann auf 150 bis 200 stellen und testen
SQL_TAIL_ELIM=100

Hier noch ein paar Bemerkungen zu der Option SQL_TAIL_ELIM :
Diese ist dazu gedacht, um ein verzögertes Schließen des SQL und die meist damit verbundene kurze „Rauschschleppe“ weitgehend zu eliminieren. Dazu wird der RX-Audio um den dortigen Zeitwert in ms gepuffert und dem entsprechend verzögert verarbeitet, aber am Ende um genau diesen Zeitwert in ms abgeschnitten. Damit schneidet man quasi die „Rauschschleppe“ einfach weg. Diese Verfahren birgt aber ein kleines Problem in sich, stellt man den Wert zu hoch ein (>500ms) hört der OM nach Loslassen der PTT noch eine kurze Aussendung seines eigenen Audio. Das ist kein Fehler, sondern leider verfahrensbedingt notwendig. Der max. Wert beträgt 1s, also 1000ms, ich rate aber nicht dazu, das bis zum Ende auszureizen, das führt nur zu Irritationen bei den Nutzern.

4.3 Preemphasis (Vorverzerrung) und Deemphasis (Rückentzerrung)

Es ist ein Verfahren zur Verbesserung der Sprachverständlichkeit und Rauschminderung und hat seinen Ursprung im UKW-Rundfunk. Die technischen Hintergründe können bei Wikipedia mal nachgelesen werden.
Der Einsatz einer Deemphasis reduziert das Nutzsignal inkl. Rauschen bei 3kHz um ca. 9dB, und bei 6kHz um ca. 15dB gegenüber dem Pegel bei 1kHz Audiofrequenz bei gleichem Signal-/Rauschabstand. Als Ergebnis ist das Rauschen jetzt relativ gleichmäßig über das Audiospektrum verteilt und klingt dadurch deutlich angenehmer.
Im Sender muss dagegen eine Preemphasis eingesetzt werden, um die oberen Töne wieder entsprechend anzuheben, was zu einem besseren S/N-Abstand für die oberen Töne führt. Also nochmals kurz zusammengefasst: Bei Frequenzmodulation lassen sich die hohen Frequenzen eines Nutzsignals schlechter übertragen, da der Phasenhub mit steigender Signalfrequenz kleiner wird. Um dem entsprechend schlechteren Signal-Rausch-Verhältnis hinter dem Modulator entgegenzuwirken, wendet man eine Preemphasis im Sender auf das Nutzsignal an. Diese Preemphasis wird mit einer Deemphasis im Empfänger wieder rückgängig gemacht.
Ich will jetzt hier nicht auf alle Aspekte eingehen, das Thema ist etwas komplexer, speziell bei Schmalband-FM (FM-narrow mit 12.5kHz und max. 2.5kHz Hub) wird die Frage Pre-/Deemphasis ja oder nein etwas schwieriger zu beantworten, da wir dort kaum über die 3kHz NF rauskommen, ohne die Bandbreite von 12.5kHz zu „reißen“. Ich habe es also bewusst etwas vereinfacht dargestellt. Wer da genauer einsteigen will, liest das bitte in entsprechenden Fachartikeln und Publikationen entsprechend nach.

Was bedeutet das nun hier in unserem Anwendungsfall ?

Arbeite ich mit Audiosignalen direkt aus bzw. zum Diskriminator (engl. „flataudio“, in DL auch als „9k6-Audio“ bezeichnet), sollte ich im SVXLINK die beiden Optionen DEEMPHASIS=1 (RX) und PREEMPHASIS=1 (TX) setzen.

Arbeite ich mit bereits im RX bzw. TX aufbereiteten Audio, können wir davon ausgehen, das Preemphasis und Deemphasis dort bereits über entsprechende NF-Filter intern angewendet wird. in Diesem Fall setzen wir DEEMPHASIS=0 (RX) und PREEMPHASIS=0 (TX) - denn es ist ja bereits angewendet worden. Eine erneute, zusätzliche Aktivierung im SVXLINK würde also den Frequenzgang nachteilig bzw. ungünstig/unnötig erneut beeinflussen.

Zur Ergänzung sollte noch gesagt werden, es gibt auch Mischsituationen. Eine solche haben wir am DR1XE, dem Repeater von YAESU. Stellt man diesen auf „9k6-Packetspeed“, was also „flataudio“ entspricht, kann ich das nur auf der NF-In-Seite machen. Am NF-Ausgang, den ich für FM verwenden sollte, kommt aber Audio raus, der bereits intern mit Deemphasis versehen wurde. Hier müsste ich dann also DEEMPHASIS=0 und PREEMPHASIS=1 wählen.

Welche Einstellung man auswählen sollte, hängt also letztlich davon ab, wie der RX und/oder TX eingestellt ist bzw. sein Audio verarbeitet. Es wirkt sich aber in jedem Fall entscheidend auf die Audioverarbeitung bzw. der Audioqualität des Repeaters aus. Hier also genau überlegen und das korrekt einstellen.