NF-Verzögerung nach Auftasten eines Repeaters

Hallo zusammen,

ich habe nun zum allerersten Mal einen Repeater konfiguriert. Bisher hatte ich nur mit Simplex-Zugängen zu tun. Die NF des Repeaters geht dabei über SvxLink, es besteht also keine direkte Audioverbindung zwischen RX und TX. Folgendes ist mir dabei aufgefallen:

Es gibt eine kleine Verzögerung. Das ist aber systembedingt - also völlig normal und soweit auch ok. Nach dem Auftasten des Repeaters (ganz gleich ob 1750Hz oder Trägertastung) ist diese Verzögerung relativ groß. Bei Funkgeräten mit schneller RX/TX-Umschaltung hört nach dem eigenen Durchgang noch seine letzten Wörter bzw. Silben. Nach dem zweiten/dritten Durchgang ist die Verzögerung dann so gering, dass man davon kaum noch etwas bemerkt. Dann ist also alles wieder ok.

Ist dies normal oder habe ich irgendetwas falsch konfiguriert? Da das Problem ja nur kurz nach dem Auftasten des Repeaters besteht, kann man dies vielleicht durch einen Trick irgendwie beheben? Denn ein wenig störend ist es schon ...

Schönen Gruß
Frank, DL3DCW

Hi Frank,

so in der Form ist mir das noch nicht aufgefallen. Die Verzögerung wird in erster Linie durch die Parameter DTMF_MUTING, 1750_MUTING, SQL_TAIL_ELIM, TX_DELAY beeinflußt. Dann kommt noch ein interner fifo dazu, den kannst Du aber nicht beeinflussen. Um die Sache langsam einzugrenzen kommentiere mal das *_MUTING aus und setze die anderen Werte auf 0.

vy 73s de Adi, DL1HRC

Hallo Adi,

ok, danke für die Info. Ich werde das einmal ausprobieren. Merkwürdig ist ja, dass diese Zeit nicht konstant ist. Direkt nach dem Öffenen des Repeaters schätze ich das Audio-Delay auf etwa 1 Sekunde, nach zwei/drei Durchgängen ist es dann im "Normalbereich" von ca. 50-100ms. Heute Abend weiß ich aber mehr ...

Schönen Gruß
Frank, DL3DCW

Hallo Adi,

wenn ich die Werte DTMF_MUTING, 1750_MUTING, SQL_TAIL_ELIM, TX_DELAY auskommentiere bzw. auf "0" setze, kann ich die Verzögerung des NF-Signals absolut minimieren. Es ist dann fast keine Verzögerung mehr spürbar. Aber: Teilweise, oftmals in recht unregelmäßigen Abständen und ohne erkennbares Muster gibt es wieder größere Verzögerungen (bis ca. 500ms). Beim nächsten bzw. spätestens übernächsten (RX-)Durchgang verschwinden diese dann wieder ...

EDIT: Ich bin der Ursache auf der Spur. Mit "dwc_otg.speed=1" tritt das Problem nicht mehr auf. Ein Blick ins Datenblatt zeigt, dass der verwendete Audiochip nur USB 1.1 kann. Bei zeitkritischen Anwendungen - wie im Repeater-Modus - kommt der Chip bzw. das System wohl irgendwie in's Straucheln. Im Simplex-Modus sind bisher keine Probleme aufgetreten. Einen (Pin-)kompatiblen Chip mit USB 2.0 habe ich gerade bestellt. Bin mal gespannt, wie es dann damit aussieht ...

Schönen Gruß
Frank, DL3DCW

Hallo Frank,

so, ich habe mal eine Testumgebung aufgesetzt und konnte das von Dir genannte Verhalten nachvollziehen.
Meiner Meinung nach hängt das mit dem TX_DELAY-Parameter zusammen. Wenn dieser auf z.B. 500 ms gesetzt ist, wird mit dem ersten Auftasten eines Repeaters der gesammte Audiostream um diesen Wert verzögert. Beim nächsten Öffnen der SQL ist diese Verzögerung nicht mehr erforderlich und die Ausgabe der Audiodaten erfolgt zeitnah.
Tip: Wenn Euer Sender nicht gerade mit Röhren gebaut wurde, welche erst mal heizen müssen, würde ich den o.g. Parameter auf 0 setzen. Für digitale Verfahren mag das Sinn ergeben, für ein normales Sprach-Relais sicher nicht so auf den ersten Blick.

vy 73s de Adi, DL1HRC

Hallo Adi,

danke für die Info. Das TX-Delay hatte ich bei meinen Experimenten ja auch auf 0 gesetzt, damit war es dann deutlich besser. Allerdings gab es immer wieder einmal unerklärliche Ausreißer, die erst mit dem Umschalten auf USB1.1 verschwunden waren. Es kann daher wirklich mit dem verwendetem Audiochip zu tun haben und ist vermutlich kein generelles Problem von SvxLink. Ich werde das einmal weiter beobachten bzw. bei Gelegenheit weiter experimentieren und dann an dieser Stelle berichten.

Schönen Gruß
Frank, DL3DCW

Hallo Adi,

nach so einigen Experimenten mit verschiedenen Audiochips und Audioeinstellungen habe ich folgende Feststellung gemacht: Wenn ich alle oben genannten Parameter auf 0 setze, gibt es immer noch eine minimale Restverzögerung. Das ist auch völlig normal, da systembedingt. Durch das nun abgeschaltete TX-Delay ist die "große" Verzögerung direkt nach dem Auftasten des Repeaters verschwunden. Soweit also alles ok.

Die restliche Verzögerungszeit zwischen RX- und TX-Audio ist allerdings nicht konstant, sondern variiert bei jedem Durchgang etwas. Das kann man gut feststellen, wenn man sich selber zurück hört. Manchmal gibt es (seltene) Ausreißer mit besonders großer Verzögerung. Diese schätze ich auf bis zu etwa 500ms.

Wenn ich auf USB 1.1 zurückschalte (dwc_otg.speed=1), ist das Ganze nicht mehr so auffällig. Dann nimmt auch die Verzögerung weiter ab. Die Ausreißer sind dann vielleicht nur noch etwa 250ms und somit kein Problem mehr. Allerdings addiert sich später natürlich noch eine zusätzliche Zeit, wenn ich die Funktionen DTMF_MUTING, 1750_MUTING oder SQL_TAIL_ELIM wieder aktiviere.

Mich interessiert nun, ob dies ein generelles "Problem" bei der Anbindung von Soundkarten via USB bzw. SvxLink ist und damit fast überall auftritt oder ob es an meinem Audiochip liegt bzw. eine spezielle Raspberry-Eigenart ist. Vielleicht ist dieses Verhalten ja auch schon bei anderen Repeatern bzw. Setups aufgefallen. Denn dann brauche ich nicht weiter zu suchen und muss einfach damit leben, hi ...

Schönen Gruß
Frank, DL3DCW

Hallo zusammen,

ich habe nun insgesamt drei unterschiedliche USB-Soundkarten getestet. Bei allen habe ich das gleiche Verhalten festgestellt. Daher müsste dies eigentlich auch bei anderen Repeatern so sein. Zumindest, wenn ein Raspberry (2B) mit der unter http://svxlink.de/?page_id=1606 beschriebene Vorgehensweise eingesetzt wird. Ich tippe auf ein Problem mit dem Soundsystem, kenne mich aber leider kaum damit aus.

[Rx1]AUDIO_DEV=alsa:default[Tx1]AUDIO_DEV=alsa:hw:0

Mit der obenstehenden Konfiguration ist das Audio-Delay nach jedem RX-Durchgang unterschiedlich; dies bewegt sich von wenigen Millisekunden bis manchmal zu fast zu einer Sekunde. Man hört dann seine letzten Silben/Wörter nach dem Loslassen der PTT über den Repeater zurück.

[Rx1]
AUDIO_DEV=alsa:default


[Tx1]
AUDIO_DEV=alsa:default

Mit dieser Konfiguration scheint das Problem behoben zu sein. Dann ist die Verzögerung sehr gering und auch absolut konstant. Leider stürzt SvxLink dabei nach kurzer Zeit ab und wird beendet (sobald z.B. die ID abgespielt wird).

Vielleicht hat ja irgend jemand eine Idee? Oder auch ähnliche Beobachtungen gemacht ...

Schönen Gruß
Frank, DL3DCW

Hi Frank,

habe das bisher noch nicht festgestellt bei mir, wobei ich immer alsa:hw:X nutze. Habe mal ein bisschen gesucht:
http://stackoverflow.com/questions/1584…efault-vs-hw0-0
Mal so eine Idee: Möglicherweise gibt es da Konflikte bei unterschiedlichen Samperaten von SvxLink und dem Alsa-Plugin. Da kenne ich mich aber nicht aus. Wird eine Fehlermeldung ausgegeben oder ist es einfach nur ein Segfault? Hasttest Du SvxLink mal mit gdb gestartet?

vy 73s de Adi, DL1HRC

Hallo Adi,

ja, es hat wohl irgendetwas mit den Sampleraten und/oder den Audio-Devices zu tun. Eine Fehlermeldung wird nicht ausgegeben. Mit gdb habe ich es noch nicht probiert. Ich werde wohl noch etwas experimentieren müssen ...

Schönen Gruß
Frank, DL3DCW

....habe leider erst wieder ab nächste Woche mehr Zeit zum Spielen.

Hallo zusammen,

da ich keine Ahnung von Alsa und Co. habe, bleibt mir nichts anderes übrig, als möglichst systematisch nach der "trial-and-error" Methode vorzugehen. Die folgende Einstellungen scheinen erst einmal zu funktionieren:

[GLOBAL]
CARD_SAMPLE_RATE=16000


[Rx1]
AUDIO_DEV=alsa:hw:0


[Tx1]
AUDIO_DEV=alsa:default

Das Audio-Delay ist nun konstant und sehr gering. Abstürze hat es bisher nicht mehr gegeben. Ich bin also vorsichtig optimistisch ;-).

Schönen Gruß
Frank, DL3DCW

Nachtrag: Nach meinen ersten Experimenten mit USB1.1 (dwc_otg.speed=1) habe ich wieder auf USB2.0 geschaltet (dwc_otg.speed=0).

Hallo zusammen,

nach intensiven Tests mit teilweise bis zu 8 über einen SvxServer vernetzten Stationen (Simplex- sowie Duplex-Systeme) ist festzustellen, dass mit den oben genannten Einstellungen erst einmal alles sehr gut funktioniert. Die Latzenzzeiten sind absolut gering, eine Verzögerung ist eigentlich kaum noch feststellbar. Das Umschalten auf den OPUS-Codec brachte zudem noch einmal eine deutliche Verbesserung; die Audioqualität ist nun wirklich perfekt.

Alle Systeme (auch der SvxServer) laufen jeweils auf einem Raspberry 2B mit HAMServerPi RadioBoard/RepeaterBoard-Aufsteckplatine. Die oben angegebenen Einstellungen gelten also zunächst erst einmal für diese Hardware. Bei anderen Systemen bzw. Soundkarten kann es daher sein, dass eventuell abweichende Einstellungen erforderlich sind. Diese muss man dann möglicherweise experimentell ermitteln.

Schönen Gruß
Frank, DL3DCW