Posts by DL8BBY

Hallo Hartmut,

im Manual (man ModuleEchoLink.conf) findet man zum Eintrag PROXY_SERVER lediglich "If set, connect to the given EchoLink proxy server host" und das klingt gar nicht nach Automatik.

Alternative 1:

Für Repeater verwaltet DG8NGN (Referat VHF/UHF/SHF) ein Kontingent von festen Proxy-Adressen. Du meinst vermutlich DB0BHE-L? Da könnte der OV A04 doch mal offiziell nachfragen, vielleicht kannst Du ja auch eine feste Adresse bekommen.

Alternative 2:

Wenn jemand in Deinem Umfeld einen DSL-Anschluss mit öffentlicher IPv4-Adresse hat und einen Raspi dauerhaft bei sich unterstellen würde, dann könntet Ihr einen individuellen EL-Proxy selber einrichten. Auf dem Raspi müsste Java installiert werden und von https://echolink.org/proxy.htm müssten zwei Dateien auf den Raspi kopiert werden. Ein paar Einträge vornehmen, Ports im Router freigeben und fertig ist der Proxy.

Alternative 3:

Je nach Art Deines DSL-Anschlusses und je nach Provider könnte es sein, dass man am Ende doch einen "echten" IPv4-Anschluss eingerichtet bekommt, bei dem man die Ports selbst verwalten kann. Man muss allerdings etliche Versuche starten, bis man in der Hotline einen Techniker erwischt, der den Sinn der Anfrage überhaupt versteht. Konfigurieren kann der Provider viel, nur die knappen IPv4-Adressen werden nicht mehr so gerne herausgerückt.

Gruß und viel Erfolg, Matthias

Hallo Hartmut,

eine fertige Lösung habe ich nicht für Dich, aber ein paar Gedanken zum Thema:

Du hast ein neues OS, verwendest aber eine steinalte Svx-Version (2017). Das kann problemlos funktionieren - muss aber nicht.

Wenn die Meldung "xcb_connection_has_error()" kommt, hat das vielleicht mit PulseAudio zu tun. Du hast Dir PulseAudio vielleicht mit "Pi OS with desktop" eingefangen. In früheren Beiträgen hier im Forum wurde vor PulseAudio gewarnt, weil es im Zusammenhang mit SvxLink Probleme bereitet (siehe alte Beiträge dazu von DL1HRC).

Mit einer kompletten Neuinstallation wärst Du einigen Ballast los, je schlichter, desto besser. SvxLink mit Raspi 4B ist eigentlich übermotorisiert, Du hattest doch auch einen 3er?

Als OS ist "Raspberry Pi OS Lite" genau richtig, die Desktop-Versionen brauchst Du für SvxLink nicht.

Für die anschließende Svx-Installation kannst Du diese Anleitung verwenden: https://github.com/sm0svx/svxlink/wiki/InstallSrcHwRpi

Wenn Du mit PuTTY arbeitest funktioniert copy&paste, bequemer geht es nicht. Der Zeitaufwand für den Installationsvorgang beträgt ca. 10 Minuten mit dem Raspi 4, der 3er braucht 12 Minuten (mit flinken Fingern und etwas Übung).

Die Konfiguration könnte noch etwas Zeit kosten, es gab ein paar Änderungen seit 2017. Im Zweifelsfall hilft ein Blick ins Manual (auf der Konsole: man svxlink.conf). Mache Dir eine neue svxlink.conf auf Basis der neuen Dateivorlage, vergiss das alte Startscript oder Einträge in rc.local und verwende keine alten Konfigurationsdateien in der neuen Svx-Version.

Viel Erfolg und 73, Matthias

Moin Edgar,
in [Rx1] wird SQL_DET=CTCSS gesetzt und bei CTCSS_FQ muss ein Wert, z.B. 88.5 eingetragen sein. Das funktioniert nur vernünftig, wenn die Rx-NF am Diskriminator abgegriffen wird.

73, Matthias

Hallo Ingo,

zu 1: Ja, das Verfahren zur Kalibrierung mit devcal läuft ähnlich wie beim TX Abgleich des MMDVM Repeaters. Allerdings ist ein exakt eingestellter Pegel beim Digitalrepeater zwingend für die Funktion erforderlich, im analogen FM-Betrieb ist eine grobe Einstellung des Hubs nach Gehör ohne devcal problemlos möglich.

zu 2: Das ist auch meine Erfahrung, an der Data-Buchse klappt es eigentlich immer. Mit dem FTM-100D hatte ich bislang noch nicht getestet, aber das konnte ich bei dem schlechten Wetter heute nachholen.

Ich konnte mit einer externen Soundkarte (Terratec Aureon) ca. 4,5 kHz Hub erreichen. Mehr schafft der Kartenausgang nicht und die Hubbegrenzung vom FTM-100D sollte dann auch langsam eingreifen. Es ist also durchaus möglich, dass auch Deine interne Soundkarte an ihre Grenzen kommt.

Erläuterungen und Bilder meiner kleinen Messreihe in der Anlage.

Noch eine Anmerkung zu devcal: Bei Parameter -m 5000 wird nicht etwa ein besonders hoher Tonpegel ausgegeben, sondern ein niedriger Pegel. Die Folge: Um Bessel-Null mit niedrigem Pegel zu erreichen, müssen MASTER im Alsamixer bzw. MASTER_GAIN in svxlink.conf relativ hoch eingestellt werden. Damit wird sichergestellt, dass die Soundkarte im Wirkbetrieb auch genug Reserven für Maximalhub hat.

Umgekehrt liefert -m 2500 ein um 6 dB stärkeren Pegel als -m 5000. Um Bessel-Null mit dem schon starken Testsignal zu erreichen. müssen MASTER im Alsamixer bzw. MASTER_GAIN in svxlink.conf relativ niedrig eingestellt werden, damit der Maximalhub im Wirkbetrieb nicht überschritten wird.

73, Matthias

Hallo Ingo,

Dein Ansprechpartner scheint nicht qrv zu sein, ich stelle mal ein paar Punkte zur Diskussion - auch wenn ich Deine Hardware nicht kenne.

• Im Abschnitt Abgleich NF Tx wird nicht erwähnt, dass zur Messung mit devcal ein Spektrumanalyser oder mindesten ein einfacher SDR-Stick mit entsprechender Software zum Betrachten des FM-Spektrums erforderlich ist.
• In DL ist für Repeater und Links ein Maximalhub von 2,5 kHz vorgesehen (Ausnahme 430,25 / 430,050 MHz). Mit den Parametern in der Anleitung wird der Wert von Mastergain für 5 kHz Maximalhub gesucht.
• Die devcal Tx-Messung wird immer mit 2,4 kHz Hub (auf Bessel Null) durchgeführt, auch wenn Du als Parameter -m 5000 beim Start von devcal eingibst. Der angezeigte Wert für MASTER_GAIN zum gewünschten Hub wird lediglich hochgerechnet und dann in svxlink.conf übernommen.
  Willst Du wirklich auf 5 kHz Hub kalibrieren, könnte der um mehr als 6 dB geringere Testpegel für den Bessel-Abgleich noch sauber sein. Es gibt aber keine Garantie, dass im späteren Wirkbetrieb die Soundkarte die maximale NF-Spannung tatsächlich verzerrungsfrei abgeben kann. Auch die Hubbegrenzung des Tx könnte schon zupacken.
• In der Anleitung wird beschrieben, dass der Diskriminatorausgang des RX verwendet wird. Nicht erwähnt wird, dass dafür in svxlink.conf Preemphasis und Deemphasis = 1 zu setzen sind.
  Setzt Du auch GM900 ein, wie in der Anleitung? Wenn ich mich recht erinnere, wird mit der Programmierung auch das Kanalraster (Hubbegrenzung) und der Rx-Ausgang (Diskriminator oder gefilterter Ausgang) festgelegt. Je nach Programmierung könnten Pre- und Deemphasis aber auch genau nicht zu setzen sein. Passen die Einstellungen nicht, wird die NF zu dunkel oder zu hell.

Vielleicht hast Du ein paar Punkte längst geklärt? Du kannst ja mal berichten.

73, Matthias

Hallo zusammen,

kleiner Nachtrag zum Thema: Die Mühe mit Debian 11 Bullseye auf dem Raspi hätte man sich sparen können. Zwei Tage nach dem letzten Beitrag wurde das neue Raspberry Pi OS auf Basis von Debian Bullseye freigegeben. Mit der neuen Lite-Version für den Raspi funktionieren die bekannten Anleitungen wie gewohnt. SvxLink ist nach wenigen Minuten auf einem frischen Image per Script installiert und läuft bei mir nun seit knapp vier Wochen ohne Probleme.

73, Matthias

Hallo Armin,

die Installation von DEB 11 will bei mir nicht so recht klappen. Anleitung von hier: https://wiki.toenniges.net/wik…t_-_Upgrade_auf_Debian_11

Ich habe mir ein eigenes, sehr einfaches Script gebaut, dass ich für die Svx-Installation auf Raspi OS lite verwende. Das funktioniert definitiv auch mit dem Raspi OS 64 Bit, nach ca. 9 Minuten ist die Installation auf einem Raspi 4 erledigt. Ein erster Test mit Headset und Parrot hat funktioniert.

Ich lade Dir das Image zum Ausprobieren hoch, vielleicht funktioniert es auch mit Debian 11 . Die Datei muss nach /home/pi kopiert werden und wird dort mit ./svxinstall gestartet. Das zweite Script deaktiviert die Onboard-Soundkarte (Start mit ./alsablack). Die USB-Soundkarte läuft dann als alsa:plughw:0 passend zur Grundkonfiguration svxlink.conf.

svxinstall.zip

Über eine Rückmeldung nach Deinem Test würde ich mich freuen.

Gruß, Matthias

Hallo zusammen,

wenn man für seinen Simplex-Link mit Raspi eine SQL-LED einrichten möchte, aber keinen SQL-Ausgang des Rx nutzt (SIGLEV, CTCSS, VOX), kann man sich dafür die Prozedur squelch_open aus dem TCL-Script Logic.tcl erweitern:

proc squelch_open {rx_id is_open} {
variable sql_rx_id;

set sql_rx_id $rx_id;

if {$is_open==1} { exec echo 1 >/sys/class/gpio/gpio9/value; }

if {$is_open==0} { exec echo 0 >/sys/class/gpio/gpio9/value; }

}

In Zeile 4 bzw. 5 wird der jeweilige Wert von $is_open abgefragt und GPIO9 mit der SQL-LED entsprechend gesetzt.

Ganz ähnlich lässt sich eine Status-LED für das Modul EchoLink realisieren. Dazu werden die Prozeduren activating_module und deactivating_module aus dem TCL-Script EchoLink.tcl jeweils um eine Zeile erweitert, die GPIO11 auf 1 bzw. auf 0 setzt.

proc activating_module {} {

variable module_name;

Module::activating_module $module_name;

exec echo 1 > /sys/class/gpio/gpio11/value;

}

Meine geänderten Prozeduren schicke ich als Anlage mit. Wer die Änderungen ausprobieren möchte, sollte sie nach /usr/share/svxlink/events.d/local kopieren. Dort gespeicherte TCL-Scripte werden beim Programmstart nach den originalen Systemfunktionen eingelesen und überschreiben sie damit. Wenn eine geänderte TCL-Datei aus dem Ordner /local nicht mehr benötigt wird (oder nicht zufriedenstellend funktioniert), löscht man sie einfach oder verschiebt sie in einen Bereich außerhalb von /usr/share und hat damit den Originalzustand wiederhergestellt.

Die zusätzlichen GPIO müssen natürlich noch in /etc/svxlink/gpio.conf eingerichtet werden. Die neuen Status-LED (-GPIO) stehen dann nach dem nächsten Neustart oder nach Restart von svxlink_gpio_setup zur Verfügung.

Weitere Info dazu gibt es unter Tips und Tricks bei: https://svxlink.de

Status_LED.zip

Gruß, Matthias

Moin Peter,

mit Deiner Anleitung kann man es kaum falsch machen. Remote.php hat sofort funktioniert, bei keyboard.php war mir zunächst ein } im Weg (Zeile 14), danach funktioniert auch das.

Der Code ist so einfach und übersichtlich, dass man schnell eigene Befehle realisieren kann.
"Relais an" und Relais aus" steuert bei mir keinen Repeater, sondern GPIO18. Damit könnte einen Lüfter, ein Antennenrelais oder die Kaffeemaschine geschaltet werden. Dazu muss GPIO18 nur in /etc/svxlink/gpio.conf aktiviert werden und in der PHP-Datei angesteuert werden:

Relais ein: shell_exec('echo 1 >/sys/class/gpio/gpio18/value');

Relais aus: shell_exec('echo 0 >/sys/class/gpio/gpio18/value');

Also vielen Dank für die Anregungen und das zusätzliche Bauklötzchen auf der unendlichen Spielwiese.

Gruß, Matthias

Moin Peter,

endlich mal wieder eine interessante Anleitung. Bin in Sachen PHP völlig ahnungslos, aber Deine Steuerung wird demnächst ausprobiert.

Gruß, Matthias

Hallo René,

das neue Image ist fertig für einen Test und Dank pishrink und 7zip mit 677 MB nicht zu groß. Kontaktdaten und Link für den Download habe ich Dir über die Konversationsfunktion geschickt.

Gruß, Matthias

Moin René,

man muss auch mal vergessen können. Hatten wir tatsächlich schon Rufnummern ausgetauscht (grübel…)? Mein letzter Stand ist unser QSO im Relaisverbund vor ca. 2 Wochen:

• Du bestellst irgendwann einen neuen MOSFET für die PTT-Leitung Deiner RepeaterBox und baust ihn ein.
  Alternativ: PTT-Anschluss im Verbindungskabel umlöten auf eine funktionierende Steuerleitung (RepeaterBox Pin12, Pin13?) und entsprechende GPIO-Änderung in der Konfiguration.
• Ich erstelle für mein neues Image eine zusätzliche Repeaterkonfiguration, die dann sicherlich auch mit der RepeaterBox spielen wird (wenn Du auf die anderen Programme auf dem Image HamServerPi 1.5 verzichten kannst).
  Status: Fast fertig, noch ein paar Tests und dann auf eine Größe < 1 GB bringen.
• Das fertige Image kann ich Dir irgendwie zur Verfügung stellen (Kartenversand per Post wäre unsportlich).
• Da ich nicht 30 Seiten Doku schreiben möchte, ist für die finale Konfiguration wohl Support erforderlich. Das können wir dann per Telefon machen. Gleichzeitig wärst Du mein Versuchskaninchen, denn die RepeaterBox kenne ich nur nach „Aktenlage“.

Die RepeaterBox und HamServerPi sind hier vor einigen Jahren intensiv diskutiert worden. Mich würde interessieren, wie andere OMs die fälligen Updates gemacht haben.

Gruß, Matthias

EL 181970#

Moin René,

den Schaltplan hatte ich mal im HamNet gefunden, siehe Anhang.

Verwendest Du noch das HAMServerPi-Image von 2015/16, oder hast Du ein neues Image für die RepeaterBox gemacht?

repeaterbox_schematic.pdf

Gruß aus HB, Matthias

Hallo Martin,

wenn Du CTCSS dekodieren kannst und in der Konfig DEEMPHASIS=1 gesetzt ist, greifst Du die Rx-NF vermutlich direkt hinter dem Diskriminator ab. An dieser Stelle des Signalwegs wirkt der SQL normalerweise noch gar nicht. Hast Du am Rx-Ausgang ein Dauerrauschen?

Das wäre sehr gut, denn dann könntest Du für den zweiten Teil der Messung einen offenen SQL vortäuschen, indem Du Deinen SQL-Pin an der seriellen Schnittstelle auf Masse legst (evtl. vorher vom Rx trennen). Beim ersten Teil der Messung mit "...full signal strength..." wird der SQL durch Deinen Messsender ganz normal geöffnet, da sehe ich keine Probleme.

Wenn das klappt, solltest Du auch vernünftige Parameter von siglevdetcal bekommen.

Gruß, Matthias

Moin Jan,

im Nordwesten sind einige Repeater über das Hamnet angebunden und sind bei echolink.org zu sehen.

Die auf der Seite angezeigten Standort- und Stationsdaten kommen nicht aus ModuleEchoLink.conf, sondern aus den Einträgen im Abschnitt LocationInfo in der Datei svxlink.conf. Ist die LocationInfo bei Dir aktiv?

73, Matthias

Hallo Hans,

einfachster Schritt wäre zunächst die Deaktivierung der CTCSS-Ansage in der svxlink.conf per # vor REPORT_CTCSS.

Bei (m)einem frisch Installiertem SvxLink wird als short_ident keine CTCSS Frequenz ausgegeben. Eine Ansage der CTCSS Frequenz bekomme ich bei mir nur über DTMF *, bzw. über die Prozedur „manual_identification“ aus der Datei Logic.tcl. In keiner anderen Prozedur und definitiv nicht in der Prozedur „send_short_ident“ habe ich das hier gefunden:

global report_ctcss;

playMsg "Core" "pl_is";

playFrequency $report_ctcss

Wenn Du SvxLink nicht selbst als aktuelle Version von github geholt und installiert hast, sondern ein fertiges Image verwendest, könnte der Aufruf von playFrequency $report_ctcss zusätzlich in die Prozedur „send_short_ident“ vom Verfasser eingebaut worden sein. Das muss nicht unbedingt in der Logic.tcl gemacht worden sein, sondern könnte auch in anderen TCL-Dateien passiert sein (Pfadnamen „…/local“ sind verdächtig).

Ein Announcement File müsstest Du selbst erstellt und in der Konfiguration als SHORT_ANNOUNCE_FILE=/irgendwo/announce.wav (oder so ähnlich) angelegt haben, diese Datei wird nicht fertig von SvxLink geliefert - also vermutlich nicht das Problem.

73 und viel Erfolg bei der weiteren Suche, Matthias

Moin Chris,

welche Versionen von SvxLink verwenden Deine Repeater und welche Version hat der SvxReflector?

Wenn die Installation vor September 2019 erfolgt ist (SvxLink v. 1.6xx), musst Du die Verbindung zum SvxReflector nach meinem Verständnis an jedem Repeater aktivieren. Eine automatische und selektive Aktivierung des zweiten Repeaters wird wohl nicht funktionieren.

Wenn die Installation nach September 2019 erfolgt ist (SvxLink v. 1.7.xx), werden beim SvxReflector Talkgroups unterstützt, die Du natürlich auch in der svxlink.conf einrichten musst, damit es funktioniert (wie bei DMR).

73, Matthias

Moin Peter,

beim Update werden vorhandene *.config nicht überschrieben und dann fehlen gelegentlich die Parameter für hinzugekommene Funktionen.

Ich hatte den Effekt am Wochenende auch, der EL-Verkehr kommt lokal durch, aber der Reflector ist weg, solange das Modul EchoLink aktiv ist. Neuerdings muss man in ModuleEchoLink.conf folgende Zeile einfügen:

MUTE_LOGIC_LINKING=0

Danach ist alles wieder ok

73, Matthias

Hallo Peter,

wenn Du eine ein Svxlink älter als März 2019 updatest, musst Du nicht nur libjsoncpp-dev, sondern auch noch libcurl4-openssl-dev nachinstallieren. Das wird hier aber nicht das Problem sein. Bist Du beim Update im richtigen Verzeichnis gestartet, z.B. /home/Rufzeichen/svxlink, wenn Du Svxlink nach der Anleitung von DL1HRC installiert hast?

Aktuell ist hier ein Betrieb:

- Raspi 3 mit Buster, cmake 3.13.4-1 armhf , svxlink 1.7.99.36
- Futro S400 mit Debian GNU/Linux 9 (stretch), cmake 3.7.2-1 i386, svxlink 1.7.99.38 (seit 10 Minuten).

Ein alter Banana Pi ist noch in der Kiste, vielleicht kann ich den noch zum Leben erwecken…

73, Matthias

Hallo Stefan,

wo es doch gestern bei Dir schon so schön lief...

Ich habe auf meinem Reserve-Raspi2 mal eben schnell ein Update auf V 1.7.99.36 durchgeführt. Die svxlink.conf und meine tcl-Sonderlocken in /../events.d/local habe ich unverändert übernommen: Die neue Version läuft ohne Probleme!

Hast Du an Deiner Konfiguration etwas geändert? Ich verstehe nicht, warum sich ohne "Linking" der LinkManager meldet. Deinem Linux-Rechner geht es sonst gut?

Bin etwas ratlos, wünsche Dir trotzdem ein schönes Wochenende.

73, Matthias