DStar-Gateways DB0RPL / DB0LJ

Der D-Star-Repeater DB0RPL auf dem Köppel im Westerwald ist vor einigen Tagen ausgefallen.
Das Modem empfängt problemlos und sendet auch, aber das Signal ist unbrauchbar. Nur wenige Geräte empfangen ab und an Bruchstücke.

Daran lässt sich leider von Remote nichts ändern. Wir hatten das gleiche Problem schonmal vor einigen Monaten, nach einem Neustart lief alles wieder.
DB0RPL arbeitet noch immer mit dem alten Sender und Empfänger aus Packet-Radio-Zeiten und einem DV2-Modem aus den Anfangstagen der Eigenbau-DV-Modems.
Es ist kein eigenes Gateway vor Ort eingerichtet, das System arbeitet ohne irgendeinen Rechner.
Wer den Umsetzer nutzt kennt die daraus resultierende und für unsere Breiten etwas unübliche Konfiguration mit RPT1: DB0RPL B / RPTR2: DB0LJ G, also Mitnutzung des Gateways von DB0LJ per Linkstrecke.
Seinerzeit hatte das nicht nur den Vorteil, dass wir dort oben keinen Rechner brauchten, als die Raspberries noch nach jedem 2. Neustart ihre SD-Karte zerschossen. Ein weiteres Problem war damit auch gelöst, denn wir hatten 3 Repeater-Standorte, DB0LJ, DB0MYK und DB0RPL, aber nur 2 Internet-Zugänge und damit nur 2 unterschiedliche IP-Adressen im Netz. Einige Reflectoren hatten damit Probleme, da sie Repeater anhand der IP-Adresse verwaltet haben.
Inzwischen sind die Raspberries stabiler, die Software besser vorbereitet für Stromausfälle, und wir haben einen kleinen Reflector im Hamnet (XLX/DCS262) vorgeschaltet, der als eine Art Proxy arbeitet. Beliebig viele Gateways können damit mit ihrer unterschiedlichen Hamnet-Adresse darin anbinden und der Reflector linkt die beliebtesten und gemeinsam an verschiedenen Standorten genutzten Sprechräume gesammelt alle über einen zentralen Internet-Zugang mit einer einzigen IP-Adresse an die Internet-Reflectoren.
Die Statusseite findet man bei xlx.prgm.org

Ich will den jetzigen Ausfall zum Anlass nehmen das Relais komplett neu auf zu bauen.
Die Hardware ist inzwischen fertig zusammengebaut, es fehlt noch der Abgleich am Wochenende.
Eingesetzt werden wie bei DB0LJ 2 Motorola GM340 BOS-Transceiver.
Dazu ein Raspberry Pi3+ mit aufgesetztem STM32-HAT-Modem und MMDVM-Firmware und MMDVM-Host (Pi-Star 4).

Dadurch ergeben sich 2 Änderungen:

• Die MMDVM-Multimode-DV-Software ermöglicht den wechselweisen Betrieb von DSTAR und DMR (… und YSF/C4FM, P25, u.v.m.).
  Wir hatten bei DB0RPL ein separates DMR-Relais geplant, das von DM0NR in Neuwied sollte nach DB0RPL umziehen, allerdings erfordert das mehr Aufwand, Antenne/Kabel, Weiche, Filter für den Parallelbetrieb mehrerer Repeater, Standortgenehmigung, Lizenz-Erweiterung, Zeit und Kosten…
  Zum einen dauert sowas länger, zum anderen stellt sich bei der aktuellen Nutzung der Relais, vor allem in DMR, die Frage, ob das wirklich gebraucht wird.
  Auf der anderen Seite birgt die Nutzung eines Repeaters für mehrere Modes einige Nachteile, die man klar sehen muss. So kann man sinnvollerweise keine häufig belegten Reflectoren per Default dauerhaft aufschalten, denn solange jemand irgendwo auf der Welt auf dem geschalteten DSTAR-Reflector spricht lässt sich der Repeater nicht in DMR oder anderen aktivierten Modes ansprechen (und umgekehrt wenn ein DMR-Reflector aufgeschaltet ist).
  Aber auch das sehe ich bei der aktuellen Nutzung nicht unbedingt als Problem an, wir werden dann mit XLX/DCS262_U einen lokalen Reflector aufschalten, so dass der Repeater in langen Pausen für DMR nutzbar ist.
• Pi-Star aktiviert ein lokales Gateway „DB0RPL G“.
  Das erfordert dann in Zukunft eine Umstellung der Konfiguration der DSTAR-Endgeräte:
  • MY: <das eigene Call>
  • UR: CQCQCQ (mit Gateway aktiviert – „Gateway-CQ“ oder was auch immer das jeweilige Gerät im Setup anbietet)
  • RPTR1: DB0RPL_B
  • RPTR2: DB0RPL_G <— hier nicht mehr „DB0LJ__G“ !

Ohne diese Einstellungen wird der Datenstrom nicht ins Netz geleitet, es funktionieren dann nur lokale Gespräche.
Egal ob ohne Gateway oder mit falschem, man hört zwar die anderen aus aller Welt, die OMs hören einen selbst aber nicht weil man das Gateway und damit den Weg ins Netz dahinter nicht nutzt. Man taucht auch nicht in der Lastheard-Liste des Gateways auf, da das Gateway den Betrieb nicht sieht wenn es nicht eingebunden wird.
Man muss mit korrekten Einstellungen dem Repeater in jeder Aussendung mitteilen, dass er das Gateway, d.h. den Weg ins Netz zuschalten soll.

Wer die Konfiguration seines Gerätes sowieso mal wieder updaten will, der kann das jetzt schon tun, DB0RPL wird mit der alten Konfiguration nicht wiederkommen (… es sei denn das Ding erholt sich von sich aus plötzlich und unerwartet in den nächsten Tagen bevor wir es austauschen).

Der Listen-Generator der ircddb.net-Webseite liefert schon die neuen Einstellungen mit „DB0RPL_G“. Das wurde automatisch upgedatet als das Gateway in der aktuellen Testinstallation erstmals im Netz gesehen wurde.
Man kann sich bei dem Listen-Generator sicher sein, dass genau das in den Listen steht was aktuell tatsächlich aktiviert ist. Er erzeugt die Listen direkt aus der Repeater-Datenbank des Netzes und die wird von den Repeatern selbst über das Netz gepflegt. Das gilt auch für Texte, Standortangaben etc., die Verantwortung für die Korrektheit der Daten liegt im ircDDB-Netz komplett bei den jeweiligen Sysops. Es gibt keine zentrale Stelle für die Datenpflege, keine Webseite, die Settings kommen aus der Konfigurationsdatei jedes einzelnen Gateways.
Andere Ersteller solcher Frequenzlisten, die die Information aus dieser Datenbank holen, bekommen die Updates auch ab jetzt sofort.
Die Listen, die Icom teilweise zum Download zur Verfügung stellt, sind mehrere Jahre alt.

Ich werde für das neue DSTAR-Gateway DB0RPL dann auch eine eigene Statusseite analog zu den existierenden von DB0LJ und DB0MYK einrichten:

• für DB0LJ: http://db0lj.prgm.org/

• für DB0MYK: http://db0myk.prgm.org/
• für DB0RPL: http://db0rpl.prgm.org/

Da die Daten dieser Statusseiten zum Teil direkt online vom Gateway kommen sind sie erst verfügbar wenn das Gateway aktiv im Hamnet ist.

Eine andere Baustelle:
Parallel ist leider kürzlich dann auch DB0LJ ausgefallen. Auch da scheint ein neuer Abgleich sinnvoll, der Fehler sieht ganz genauso aus wie bei DB0RPL.
Dort ist bereits MMDVM im Einsatz mit einem Raspberry-PI und Teensy-3.6-Modem.
Ich werde auch den Repeater am Wochenende neu abgleichen. Dann lohnt sich der Messaufbau wenigstens. 😉

Wenn nichts anderes defekt ist wird DB0LJ hoffentlich sehr kurzfristig wieder On-Air sein.
Bei DB0RPL kann es noch einige Tage länger dauern bis wir an den Standort kommen und den Austausch vor Ort vornehmen können, alle Stecker passen, kein Kabel fehlt oder zu kurz ist…

Vy 73

Hans-Jürgen DL5DI