Nun sind sie ja auch im FM-Bereich angekommen, die aus dem Digitalfunk allseits beliebten Hotspots. Im Grunde handelt es sich um FM-Simplex-Relais, auch wenn sie klein sind und auf einen Raspberry Pi passen.
Da diese ja meist dazu dienen, an einem zentralen Netzwerksystem angeschlossen zu werden wie z.B. dem FM-Funknetz, sollten einige Dinge beachtet werden, um nicht als „Störenfried“ aufgrund schlechter oder ungünstiger Einstellungen eines Hotspots an solchen Netzwerken aufzufallen. Einige der möglichen Probleme und Fallstricke will ich hier etwas genauer darstellen, um Hilfestellungen zu geben, was man tun und was man lieber lassen sollte.

Anders als bei den kleinen digitalen Hotspots, die meist nur 10mW Leistung erzeugen können, haben wir es bei den FM-Hotspots meist mit verschiedenen industriell gefertigten FM-Transeiver-Modulen wie den DRA818U/V, SA818U/V, SR105U oder SR110U zu tun. Das sind komplette FM-Transeiver, wo Audio rein- und rausgeht und auf der HF-Seite ein fertiges FM-Signal an die Antenne geht. Es ist also fast ein kleines Handfunkgerät, denn in diesen kommen solche Module teilweise auch zum Einsatz. Diese Module erzeugen aber nicht nur 10mW, meist sind das 500mW oder sogar 1W. Damit dürfte wohl jedem klar sein, sowas funkt nicht nur in der Wohnung, das geht in Sachen Reichweite deutlich darüber hinaus. Mit 1W kann es schon sein, das ich das SIgnal noch in 10-15km Entfernung wahrnehmen kann.
Überlegt Euch also genau, welche Frequenzen ihr nutzen wollt, prüft diese vorher ab, ob diese auch frei und nutzbar sind und schaut bitte aus Gründen eines Miteinander in den Bandplan, wo man mit diesen Hotspots arbeiten kann, um keine anderen Nutzer zu stören.

Wenn ihr den Hotspot das erste Mal in Betrieb nehmt, macht das bitte im reinen lokalen Betrieb.

Dazu in der /etc/svxlink/svxlink.conf folgendes anpassen:

[GLOBAL]
# Betrieb mit Reflektor
# LOGICS=SimplexLogic,ReflectorLogic
# rein lokaler Betrieb
LOGICS=SimplexLogic
# Reflektor aktiv schalten
# LINKS=ReflectorLink

[SimplexLogic]
TYPE=Simplex
RX=Rx1
TX=Tx1
# MODULES=ModuleHelp,ModuleParrot,ModuleEchoLink
MODULES=ModuleHelp,ModuleParrot

Jetzt könnt ihr mit DTMF 1# die lokale ECHO-Funktion („Papagei“) aufrufen und erste, lokale(!) Tests mit euch selbst machen, um erstmal überhaupt zu prüfen, ob da Audio übertragen wird bzw. ausgesendet wird. Durch die Auskommentierung der ReflectorLogic und dessen Verlinkung ist der Hotspot erstmal nicht mit dem Netzwerk verbunden, ihr stört also niemanden. Wenn das erstmal soweit ok war, schalten wir die ReflectorLogic und dessen Verlinkung wieder zu:

[GLOBAL]
# Betrieb mit Reflektor
LOGICS=SimplexLogic,ReflectorLogic
# rein lokaler Betrieb
# LOGICS=SimplexLogic
# Reflektor aktiv schalten
LINKS=ReflectorLink

[SimplexLogic]
TYPE=Simplex
RX=Rx1
TX=Tx1
MODULES=ModuleHelp,ModuleParrot,ModuleEchoLink
# MODULES=ModuleHelp,ModuleParrot

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
...

Nutzt bitte die Möglichkeiten dieser FM-TRX-Module und verzichtet nach Möglichkeit auf eine trägergesteuerte SQL, die einfach nur auf Signale reagiert. Im Falle von Störsignalen öffnet diese einfach und dann hat bei Vernetzung der ganze Verbund, der auf der eingestellten Talkgruppe arbeitet, auch gleich was davon. Das muss nicht sein.

Verwendet am besten Verfahren wie CTCSS (oder auch DCS), 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 der Hotspot öffnet nicht mehr unkontrolliert seine SQL. Die Relaisbetreiber, Sysops und auch die anderen Nutzer werden es euch danken.

Betreibt ihr möglicherweise mehr als einen Hotspot, nutzt bitte verschiedene(!) CTCSS-Töne pro Hotspot, damit es nicht eine unkontrollierte gegenseitige Beeinflussung gibt. Das kann im Nahfeld schon vorkommen, auch wenn verschiedene Frequenzen pro Hotspot eingestellt sind.

Es kann an den FM-TRX-Modulen vorkommen, das diese „Spikes“ oder „Bursts“ produzieren, also auf der SQL-Signalleitung ein Öffnen der Rauschsperre melden (was aber nicht zutrifft) und damit den TX hochtasten. Im Falle eines Verbundes gehen dann gleich mal alle angeschlossenen Systeme wie Relais oder andere Hotspots mit auf.
Das lässt sich vermeiden, indem wir in der /etc/svxlink/svxlink.conf folgendes eintragen:

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

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.
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)

Und hier meine dringende Bitte speziell an die Hotspot-Betreiber:
Wenn man ein öffentliches Relais betreibt, bekomme ich bei Lizenzerteilung von der Behörde Auflagen, die ich ohne Wenn und Aber einzuhalten habe, wie korrekte Bandbreite aber auch fehlerfreie Funktion meines Relais. Ihr als Hotspot-Betreiber unterliegt diesem Zwang erstmal nicht direkt. ABER: Ein Verbundsystem wie das FM-Funknetz besteht nun mal aus beiden Kategorien, den „echten“ Relais und eben auch den Hotspots. Deswegen können wir da nicht mit zweierlei Maß messen, es muss also auch die Hotspot-Fraktion dafür sorgen, das der eigene Hotspot wenigstens annähernd die gleiche Qualität liefert wie die echten Relais, denn die funktionieren in 99,9% aller Fälle so wie es sein soll oder besser muss. Gebt Euch bitte Mühe, auch im Sinne aller Nutzer, das das Audio so gut eingestellt ist, das man sich dafür nicht schämen muss oder - was schlimmer wäre - der QSO-Partner sagt, wegen schlechter Audioqualität möchte er das QSO nicht fortsetzen. Nehmt euch bitte die Zeit, das qualitativ so weit hinzubekommen, das es wirklich passt. Ich kann sagen, das ist möglich und keinesfalls ein unlösbares Problem.

Das ist das „wichtigere“ der zwei Audiopegel, denn dieses Audio empfängt euer Hotspot und es ist auch das, was in den Verbund übertragen wird und andere zu hören bekommen. Also letztlich meine(!) Visitenkarte, wenn ich mit jemanden ein QSO fahre oder fahren will.
Verarbeitet wird der Audio bei SVXLINK von einer Soundkarte, die eigentlich nichts anderes als ein ADC („Analog-Digital-Converter“) ist. Dieser hat technische Grenzen, kann also analoge Eingangsignale nur bis zu einer gewissen Maximalamplitude verarbeiten. Ist die Amplitude zu groß, also das Audiolevel zu hoch, führt das im ADC zu Overflows, das Signal wird also „zerstört“ und kann dann nicht mehr so zurückgewonnen werden, wie es mal digitalisiert wurde. Wir müssen also den Ausgangspegel des RX/Empfängers betrachten und den Eingang der Soundkarte, dem sog. Capture-Device. Dafür hat die Soundkarte einen Mixer, der in gewissen Grenzen dieses Eingangssignal durch eine Art Abschwächer an den optimalen Betriebszustand des ADC der Soundkarte anpasst.
Ist das Eingangssignal zu gering und schafft es nicht, die Soundkarte genügend auszusteuern, wird unser Audio zu leise klingen. Ist es zu groß, „überfahren“ wir den ADC und es kommt zu den eben beschriebenen negativen Effekten bei der Signalverarbeitung. Um es weitgehend optimal einzustellen, bietet uns selbst die Linux-Console ein VU-Meter als Hilfe an, auch „Austeuerungsanzeige“ genannt.

Als erstes benötigen wir ein Signal vom RX - und zwar einfach Rauschen. Rauschen hat das höchste Audiopegel, damit stellen wir den Eingang der Soundkarte ein. Der RX ist soweit vorzubereiten, das die SQL offen ist und Dinge wie CTCSS oder DCS ausgeschalten sind. Bei den FM-TRX-Modulen lässt sich das entsprechend programmieren, die genauen Anweisungen bitte dem jeweiligen Datenblatt des FM-TRX-Moduls entnehmen .

Ich empfehle, ohne jetzt hier darüber eine Grundsatzdiskussion zu führen ob dem Warum und Wieso, die Module auf 25kHz Bandbreite zu setzen für besseren Audio.
Hier ein Beispiel für die SA818/DRA818 (Befehle bei anderen Modulen wie dem SR110U können eine andere Syntax haben!):

AT+DMOCONNECT
AT+DMOSETGROUP=1,430.0250,430.0250,0,0,0

Das Format zum Programmieren lautet:
AT+DMOSETGROUP=GBW,TFV,RFV,Tx_CXCSS,SQ,Rx_CXCSS
GBW: Bandbreite 0=12.5kHz, 1=25kHz
TFV: TX-FREQ z.B. 430.0250, kHz immer 4stellig angeben
RFV: RX-FREQ z.B. 430.0250, kHz immer 4stellig angeben
Tx_CXCSS: CTCSS TX entsprechend den Werten der Tabelle aus dem entsprechenden Datenblatt, z.B. CTCSS 77Hz wäre 0004
SQ: Einstellung Squelch, Bereich 0~8, 0=SQL immer offen
Rx_CXCSS: CTCSS RX entsprechend den Werten der Tabelle aus dem entsprechenden Datenblatt, z.B. CTCSS 77Hz wäre 0004

Den Audiopegel am Ausgang des FM-TRX-Moduls können wir auch anpassen, Werte zwischen 1~8 sind möglich, je höher desto mehr Pegel. Wir starten mit dem Wert 7:

AT+DMOCONNECT
AT+DMOSETVOLUME=7

Um das VU-Meter der Konsole zu verwenden, muss SVXLINK gestoppt/beendet werden:

$ sudo systemctl stop svxlink.service

Zum Einstellen benötigen wir ZWEI Fenster der Linux-Console, also 2 SSH-Verbindungen. Auf der einen Konsole zeigen wir uns das VU-Meter an, auf der zweiten bedienen wir den ALSAMixer, stellen das also nebeneinander dar.
Zuerst die Konsole für das VU-Meter:

$ sudo arecord -D hw:1 -V mono -f S16_LE -c1 -r48000 /dev/null

Die Parameter für arecord sind leider abhängig von der eingesetzten Soundkarte. Das Beispiel eben gilt für die CM108 wie sie im „Aliexpress“-Hotspot verwendet wird (hat nur einen Kanal und ist als Sounddevice 1 im System gelistet). Zum Test kann man sich die Sounddevices auflisten lassen:

$ sudo arecord -l
**** Liste der Hardware-Geräte (CAPTURE) ****
Karte 1: Device [USB Audio Device], Gerät 0: USB Audio [USB Audio]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0

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:

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

Jetzt verändern wir in der zweiten Konsole den Eingangspegel mit dem ALSAMixer so, dass das VU-Meter max. bis 95% ausgesteuert wird . Wird dauerhaft 99% angezeigt, ist es schon zu hoch eingestellt, dann am Mixer den Pegel absenken, bis wir wieder bei max. 95% sind. Das ist eben genau der Punkt, wo wir vermeiden, das der ADC übersteuert wird bzw. Overflows produziert .
Reicht die Aussteuerung selbst bei voll aufgeregelten Mixer nicht aus, muss das Ausgangspegel des RX weiter erhöht werden . Optimal wäre es, wenn der Mixer so zwischen Stellung 50..75 eine Aussteuerung bis max. 95% zeigt. Dann passt es und wir haben den Eingangspegel zwischen RX-Ausgang und Soundkarten-Eingang optimal eingestellt.

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.

Also nochmals zusammengefasst die Schritte in logischer Reihenfolge:

1. am RX den SQL öffnen, dabei CTCSS usw. ausschalten
2. SVXLINK stoppen
3. den Eingangspegel bei Rauschen des RX messen und den Mixer so einstellen, das max. 95% Aussteuerung erreicht wird
4. im Anschluß den RX/das Modul wieder normal einstellen/programmieren mit SQL, CTCSS für den normalen Betrieb

Ja, es ist etwas Aufwand notwendig. Aber so messen(!) wir etwas und stellen es nicht „nach Gefühl“ ein, was immer die bessere Wahl ist. Messen ist immer besser als „Raten“, das wissen wir Funkamateure eigentlich genau. Wie ich immer sage, so ein Hotspot ist kein Plug'n'Play-Gerät. Man muss lernen, dieses technisch beherrschen zu können.

Hier können wir etwas flexibler agieren, denn den Sende-(TX-)Audio hören nur wir selber über den Hotspot. Das TX-Audio ist an der Soundkarte der Playback-Regler, am besten man vergleicht die Sende-Lautstärke mit einem Relais, was man in der Nähe hat. Sind beide in etwa auf gleichem Laustärkeniveau, sollte es schon passen. Mehr Aufwand muss man TX-seitig eigentlich nicht treiben, die RX-Seite ist viel wichtiger, wie ich das unter Pkt. 5.1 bereits ausführlich beschrieben habe.

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.
Module wie das SR110U (neuere Aliexpress-Hotspots) oder das SR105U (DJSpot) können kein „flataudio“, bei den DRA/SA818 lässt sich das per Programmierung zwischen „flataudio“ und Audio pre-/deemphased auswählen. Hier hängt also die Einstellung im SVXLINK davon ab, wie das Modul programmiert wurde. Ich bevorzuge „flataudio“ in den Modulen zu programmieren, mit den Optionen DEEMPHASIS=1 und PREEMPHASIS=1 im SVXLINK. Das klingt für mich „runder“ und ausgewogener. Wie gesagt, diese Option steht nicht bei allen FM-TRX-Modulen zur Verfügung.

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.

Wie wir auch lernen müssen, einen richtigen Transeiver z.B. für Kurzwelle richtig einzustellen, damit wir damit die Ergebnisse erzielen, die wir erwarten, gilt das auch für solche Systeme wie einen Hotspot. Das ist ebenfalls ein vollwertiger Transeiver und dieser erfordert ebenfalls technisch korrekte Einstellungen. Das erwarten unsere QSO-Partner auch von uns. Auch wenn es häufig so aussieht, kaufen - einschalten - nutzen, NEIN so einfach ist das nicht. Es sind und waren nie steckerfertige Lösungen, man MUSS sich also damit beschäftigen „was man da so erworben hat“. Das gilt für alle bekannten Hotspot-Lösungen wie DJSpot, SPSpot/Danielspot, den SHARI von Aliexpress oder den von F8ASB. Im Grunde folgen alle dem gleichen Prinzip, auch wenn diese sich im Detail unterscheiden (z.B. als HAT-Lösung für den Pi wie der DJSpot oder der F8ASB, als USB-Lösung wie der SHARI von Aliexpress oder der Lösung aus SP, bestehend aus OrangePi und einem HAT mit SA818 und Soundchip):
Rechner(z.B. Pi) <–> Soundkarte <–> FM-TRX
und sind per se FM-Simplex-Repeater, wie sowas eigentlich bezeichnet wird.

Die Akzeptanz für Vernetzung bleibt nur dann erhalten, wenn alle, die daran teilnehmen, sich bemühen, ein Mindestmaß an Übertragsqualität und Funktionssicherheit gewährleisten. Dazu muss aber jeder Teilnehmer wissen, was er da betreibt und wie das (technisch) funktioniert. Wie es nicht sein soll, habe ich zur Genüge im Digitalfunk erlebt, wo teilweise die QSOs nur noch aus „hört mich jemand“ oder „kann mich jemand aufnehmen“ bestand. Das kann es nicht sein.

In dem Sinne,
73 Heiko, DL1BZ

zurück zur Startseite