kb-afu:ysf

Anbindung eines MMDVM-Repeaters an DE-SAXONIA unter Verwendung des YSFGateway

Anleitung für Sysops von MMDVM-Repeatern Stand: 09/2021


Bei einem MMDVM-basierenden Repeater oder Hotspot wird bei Nutzung von C4FM für die Anbindung an vernetzte Systeme das YSFGateway benötigt. Bei YSF handelt es sich nicht(!) um das YAESU-eigene, geschlossene WiresX-Netzwerk, sondern um ein auf OpenSource-Basis betriebenes Netzwerk. Alle dafür benötigten Softwarepakete sind somit allen frei zugänglich und nutzbar. Bei YAESUs eigenem, geschlossenen Netzwerk ist das nicht der Fall, außerdem läuft YAESUs Netzwerk bzw. die dazu benötigte Software zur Vernetzung derzeit nur auf WINDOWS-Plattformen, während wir bei YSF weitgehend auf Linux-Systeme setzen. In beiden Fällen wird aber die Funktionalität der WiresX-Steuerbefehle in den C4FM-tauglichen Geräten von YAESU genutzt und die Bedienung beider Netzwerke ist somit gleich.

Bei Vernetzung C4FM-basierter Systeme kommt das Konzept sog. Reflektoren zum Einsatz. Reflektoren sind Server im Inter- oder Hamnet, die einen Sprachraum zur Verfügung stellen. Alle in so einem Sprachraum verbundenen Systeme (Repeater, Hotspots) können mit- und untereinander kommunizieren, alle hören alles. Dieses Konzept kam bereits bei D-STAR zum Einsatz und ist damit ähnlich in dessen Anwendung.

C4FM ist neben D-STAR und DMR sicher der dritte, wichtige DV-Mode im Amateurfunk. Er ist der letzte, der auf den (Amateurfunk-)Markt kam, da gab es DMR und D-STAR im Amateurfunk schon. Aufgrund der Tatsache, das es nur Geräte der Fa. YAESU gibt und keine "billigen Chinaböller" wie das bei DMR der Fall ist, muss man also etwas Geld in die Hand nehmen. Der günstigste Einstieg ist sicher das FT70D, wenn man auf APRS & Co. verzichten kann. Was C4FM ausmacht, ist seine einfache Bedienung und Handhabung bei besserer Sprachqualität gegenüber D-STAR. C4FM und DMR verwenden den gleichen Audio-Codec (zumindest im häufig angewendeten DN-Mode), deswegen sind diese beiden Modi eigentlich identisch. Beide verwenden 4FSK-Modulation, der Hauptunterschied ist FDMA bei C4FM und TDMA bei DMR. Es gibt also keine Zeitschlitze und somit auch nicht die Option, zwei Gespräche zur gleichen Zeit übertragen zu können. Aber das "Handling" trotz digitaler Sprache ist praktisch so einfach wie die Bedienung eines FM-Repeaters. Damit ist die Lernkurve für den Anwender auch relativ flach, man erzielt schnell Ergebnisse - ganz im Gegensatz zu DMR. C4FM ist nicht neu von YAESU erfunden worden, das gab es bereits zu diesem Zeitpunkt, bevor YAESU das in den Amateurfunk überführte und um die WiresX-Funktionen erweiterte, was die Grundlage für die Vernetzung bei C4FM legte.

  1. MMDVM-Modem (Repeatermodem oder Hotspot), meist für den Betrieb an einem Raspberry Pi unter Linux gedacht
  2. Steuersoftware für das MMDVM-Modem, den MMDVMHost
  3. Gateway-Software YSFGateway (meine angepasste Version mit Support für die Übertragung der Fusion-II/DG-ID-Funktionalität) für die Anbindung des Repeaters oder Hotspots an das YSF-Netzwerk
  4. ein C4FM-taugliches Funkgerät, derzeit nur von der Fa. YAESU erhältlich (z.B. HFG: FT70, FT1[X]D/2D/3D - Mobilgeräte: FTM100DE/300DE/400[X]DE/7250 - Stations-TRX: FT-991[A])

Kommt hier wie bei den meisten Anwendern Pi-Star zum Einsatz, entfallen die Punkte 2 und 3, da dort die notwendigen Softwaremodule bereits enthalten sind.

[System Fusion]
Enable=1
LowDeviation=0
SelfOnly=0
TXHang=1
RemoteGateway=0
ModeHang=60
[System Fusion Network]
Enable=1
LocalAddress=127.0.0.1
LocalPort=3200
GatewayAddress=127.0.0.1
GatewayPort=4200
Debug=0
ModeHang=60

Um es gleich vorweg zu nehmen - anders als bei DMR, wo in der MMDVMHost.ini der sog. DMR-Master direkt eingetragen werden kann, benötigen wir zwingend bei YSF/C4FM das YSFGateway. Ohne diesem geht es nicht !

Signalfluss via 127.0.0.1/UDP zwischen MMDVMHost und YSFGateway:

MMDVMHost 127.0.0.1                        YSFGateway 127.0.0.1
[System Fusion Network]                    [General]
LocalPort=3200   UDP>--TX---\ /---TX--<UDP LocalPort=4200
                             X
GatewayPort=4200 UDP<--RX---/ \---RX-->UDP RptPort=3200
          \/                                  \/
      HF via Repeater                    YSF-Reflektor via Netzwerk(Internet, Hamnet)

Der MMDVMHost und das YSFGateway kommunizieren via dem internen Netzwerk 127.0.0.1 im Protokoll UDP miteinander. Laufen müssen also beide Programme, wobei es zu empfehlen ist, zuerst das YSFGateway zu starten und erst danach den MMDVMHost. Hier hängt es von der entsprechenden Linux-Plattform ab, wie das umgesetzt werden kann.

Hier eine als Beispielkonfiguration oder Vorlage YSFGateway.ini von DB0OLL:

[General]
Callsign=DB0OLL
# Suffix ND = Node wenn simplex, RPT = Repeater wenn duplex
Suffix=RPT
RptAddress=127.0.0.1
RptPort=3200
LocalAddress=127.0.0.1
LocalPort=4200
# bei Daemon=1 muss das YSFGateway unter dem User und der Gruppe mmdvm laufen, also nicht(!) als root
Daemon=1
# wir machen zwar kein DMR und brauchen auch keine DMRId, warum das angegeben wird, erschliesst sich mir leider nicht
Id=262939
# notwendig fuer spezielle WiresX-Steuerungen
WiresXMakeUpper=1
WiresXCommandPassthrough=1

[Info]
RXFrequency=430950000
TXFrequency=438550000
Power=5
Latitude=51.0912
Longitude=14.6924
Height=458
# Name=DB0OLL-JO71IC
Name=C4/YSF
Description="Germany"

[Log]
DisplayLevel=1
FileLevel=2
# Logpfad entsprechend anpassen
FilePath=/var/log/pi-star
FileRoot=YSFGateway

# folgendes verwenden, wenn noch nicht das neue APRSGateway verwendet wird (altes Verfahren)
# [aprs.fi]
# Enable=1
# Server=euro.aprs2.net
# Port=14580
# # APRS-Passcode fuer DB0OLL, siehe https://apps.magicbug.co.uk/passcode/
# Password=19363
# Description=DB0OLL-JO71IC

# folgendes beim Einsatz des neuen APRSGateway nutzen
[APRS]
Enable=1
Address=127.0.0.1
Port=8673
Description=DB0OLL_Multimode
Suffix=Y

[YSF Network]
Enable=1
# Quellport UDP fuer ausgehende UDP-Verbindungen
Port=42000
# Pfad zur YSFHosts.txt - wichtig und muss vorhanden sein, sonst koennen keine Reflektoren ausgewaehlt werden !
Hosts=/usr/local/etc/YSFHosts.txt
# Zeit in min, um eine ggf. neuere YSFHosts.txt neu einzulesen
ReloadTime=60
# wenn wir auf die sog. ECHO-Funktion und die Crossmode-Tools verzichten, lassen wir das folgende so auskommentiert
# ParrotAddress=127.0.0.1
# ParrotPort=42012
# YSF2DMRAddress=127.0.0.1
# YSF2DMRPort=42013
# YSF2NXDNAddress=127.0.0.1
# YSF2NXDNPort=42014
# YSF2P25Address=127.0.0.1
# YSF2P25Port=42015

# FCS wird eigentlich nicht benoetigt, wir nutzen ja YSF
[FCS Network]
Enable=0
Port=42001
Rooms=/usr/local/etc/FCSHosts.txt

[GPSD]
Enable=0
Address=127.0.0.1
Port=2947

[Network]
# Rueckfallzeit in min bei Inaktivitaet
InactivityTimeout=30
# Revert 0/1 bestimmt, ob auf einen vordefinierten Reflektor wieder zurueckgeschalten werden soll nach Ablauf InactivityTimeout
Revert=1
Debug=0
Port=42000
# Startreflektor / laesst man das leer also nur Startup= wird einfach der Reflektor getrennt und der Repeater hat keinen mehr verbunden
# funktioniert nur bei Vorhandensein der YSFHosts.txt ! Pruefen !
Startup=DE-SAXONIA

Wichtiger Teil für die Bereitstellung der YSFHosts.txt

Die WiresX-Steuerung zur Auswahl eines Sprachraumes/Reflektors erfolgt grundsätzlich über eine 5stellige Nummerneingabe. Darüber hinaus bieten einige Geräte die Möglichkeit, alle verfügbaren Reflektoren als Text direkt anzuzeigen und dort eine Auswahl zu treffen (nicht möglich beim FT70D und FTM7250D). Damit das funktioniert, wird eigentlich nur die YSFHosts.txt vom YSFGateway gelesen und zum Gerät übertragen.

Dafür muss das Gerät den WiresX-Modus aktiviert haben, das erfolgt normalerweise mit einem Druck auf die sog. Dx-Taste.

Anders als bei DMR sage ich also dem Repeater, welchen Raum/Reflektor er nutzen soll - es geht aber immer nur genau EINER. Die WiresX-Steuerung ist also nichts anderes als eine Art Fernbedienung des Repeaters selbst.
Das geht alles direkt am Gerät, Vorprogrammierung mit einer CPS wie bei DMR ist nicht erforderlich ! Das ist einfach, oder ?!?

Die YSFHosts.txt beinhaltet alle notwenigen Informationen, die dann auch je nach Gerät auf dem Display angezeigt werden:

# Aufbau YSFHosts.txt
# Reflektornummer;Reflektor-Name;Kommentar;IP-Adresse des YSF-Reflektors/Servers;Ziel-UDP-Port;Anzahl aktuell connecteter Gateways;URL des Dashboards des YSF-Reflektors
...
13111;DE-SAXONIA;YSFSachsen;85.214.61.75;42001;000;https://ysf02.bzsax.de/ysf-saxonia/ 
...

a) Basisinformationen findet man hier

b) Wir aktualisieren die YSFHosts.txt am besten per cronjob:

root@SRV:/home/pi# nano /etc/crontab

Dann tragen wir folgendes ein:

*/15 * * * * root /usr/bin/wget -O /usr/local/etc/YSFHosts.txt https://register.ysfreflector.de/export_csv.php

Das aktualisiert aller 15min die YSFHosts.txt

Noch ein kleiner Hinweise wegen der Pegel bzw. des Modulationshubs bei C4FM. Ohne jetzt hier auf grosse Ausführungen und Details einzugehen, ist es sinnvoll, das Pegel für C4FM am Repeater (nicht bei Hotspots !!!) etwas abzusenken.
Hier in der MMDVMHost.ini folgendes anpassen (die Pegel können natürlich bei Euch anders sein als hier im Beispiel ! Es geht aber ums Prinzip.):

[Modem]
...
D-StarTXLevel=60
DMRTXLevel=60
# C4 um ca. 3-5 gegenueber DMR absenken, ggf. probieren
# Die Pegel sind dann korrekt, wenn die WiresX-Funktionen vom Geraet sofort und ohne mehrfache Wiederholungen gelesen werden
YSFTXLevel=55
...

Nach nunmehr fast 4 Jahren als Sysop kann ich folgende Feststellung treffen - und die ist ziemlich eindeutig:
Auch wenn wir weltweit vernetzt sind und praktisch unbegrenzte Reichweite verfügbar ist - 90% der QSOs in den verschiedenen DV-Modi und auch das Nutzerverhalten
zielen ganz klar und eindeutig immer auf starken regionalen Bezug ab ! Man möchte hier seine Funkfreunde treffen - in der Nähe, in der Region.

Multimode-Betrieb stellt im Gegensatz zum Single-Mode-Betrieb andere Ansprüche an einen Repeater. Deswegen hier ein paar Tipps, um das sinnvoll auszugestalten.
Denkt als Sysops immer daran: "Kommen die Nutzer damit klar oder benötigen Sie eine 100seitige Anleitung für diesen Repeater ?" Das ich das als Sysop alles draufhabe,
dürfte wohl klar sein. Aber ein öffentliches Relais ist ja keine reine Privatveranstaltung. Macht es also den Usern möglichst einfach und strukturiert.
Interessen liegen auf verschiedenen Schwerpunkten, versucht, möglichst ALLE abzuholen. Das zahlt sich aus !

  • DMR

Hier ist eine sinnvolle Bereitstellung von statisch gebuchten Talkgruppen zu überlegen. "Viel hilft viel" macht keinen Sinn. Eine Lösung wäre: TS1 komplett leer lassen und auf dem TS2
vielleicht EINE Regio-TG wie die 2629 bereitstellen. Zu viele statische TG, besonders die mit viel Traffic, machen eigentlich den Multimode-Betrieb unmöglich.
Auch betreiben wir ja keinen Rundfunksender, sondern ein Kommunikationssystem, was eine gewisse Interaktion der Nutzer erfordert.
Wenn alle nur zuhören und sich berieseln lassen (wollen), gibt es kaum noch Aktivität. Diese Erfahrung haben bereits viele DMR-Repeater machen dürfen.
Wollen wir das wirklich ?

  • C4FM/YSF

Um Einsteigern das Leben leicht zu machen, ist es sinnvoll, einen Reflektor vorzuwählen. Hier in Sachsen empfehlen wir natürlich den DE-SAXONIA. Hier sind bereits viele Repeater wie DB0OLL, DB0SPB, DB0GRZ, DB0NLS, DB0LS, DB0AF, DB0FIB und DB0ERZ ständig verbunden. Reichweite mit starkem regionalen Bezug ist also bereits vorhanden.

  • D-STAR

Hier gilt in etwa das Gleiche wie für C4FM. Als Reflektor käme sicher der Reflektor DL-Ost DCS001T infrage.


Natürlich sollte man die verschiedenen Modi sinnvoll verriegeln. Hier meine Empfehlung für die MMDVMHost.ini:

[D-Star]
...
ModeHang=30


[DMR]
...
CallHang=3
TXHang=4
ModeHang=15

[System Fusion]
...
TXHang=1
ModeHang=60

[D-Star Network]
...
ModeHang=30

[DMR Network]
...
ModeHang=15

[System Fusion Network]
...
ModeHang=60

Das berücksichtigt die Spezifika der einzelnen DV-Modi und bietet dem Anwender/User eine zuverlässige Nutzung des Repeaters im Multimode. Diese Werte haben sich speziell bei DB0OLL/SPB/GRZ bestens bewährt.

Viel Spass mit C4FM !
73 Heiko, DL1BZ

  • kb-afu/ysf.txt
  • Zuletzt geändert: 29.09.2021 17:11
  • von DL1BZ