Bei mir im "Entwicklungs-Labor" hatte Ich nur mit dem OnBoard-Serial getestet,
Ich habe gerade mal in meinem Lager gekramt und zwei Varianten: USBtoSerial und USBtoTTL gefunden werde das hier mal austesten und den Fehler suchen und beheben. 

Hab jetzt seit Beginn der Addon für Linux zwei Gateways über Linux Mint laufen.  Als Interface nehme ich nur mit FTDI Chip.  Ansteuerung USB Com ohne Probleme.

Wie wirkt sich ROGER_LEN und BAKE-LEN aus? Rogerbeep oder Bake geht ja solange wie das Wavefile ist. Soll LEN die Länge sein und welche auswirken hat dies mit der Länge vom File selber?

Zwei Sachen habe ich Probleme:
- Beim aussenden über HF wird öfter mal der Rogerbeep ausgesendet, obwohl die Sendung noch läuft und ich eine TX Delay von 900 habe sowie ROGER_LEN 400
- Ab und zu hängt sich TS3 Grundlos auf und die Fehlerberichtssendung kommt.

Aber sonst soweit top.

Auch die neue Windows Version habe ich getestet sowie andere Funkkollegen. Kein Aufhängen mehr. Läuft Prima.

73 Speedfire Dominik 

zuletzt bearbeitet: 5.06.2025 / 22:03 MEZ

Die Funktion Funk hat Vorrang würde noch fehlen, wie bei der Windows Version.  

Andi ist aktuell nicht verfügbar und wird sich zeitnah dazu äussern. Wir haben es zur Kenntnis genommen. Danke für deinen Post

Mit freundlichen Grüßen
Tim de SA7BNT 
Admin AD 

Moin Dominik,
die Config-Werte   "BAKE_LEN & ROGER_LEN" stellen die Länge der Wave-Datei dar. (in Millisekunden) 
Da dieses Plugin mein erster Versuch war unter Linux zu programmieren, und Ich da Probleme hatte die Länge der Wave-Datei automatisch im Programm zu berechnen habe ich das erstmal über die manuelle Einstellung gelöst, inzwischen ist das Problem aber gelöst, in der nächsten Version wird diese Einstellung entfallen.
Kurze Erklärung: wenn der ROGER-BEEP 500mSek. lang ist muss bei "ROGER_LEN=500" rein das TX_DELAY ist dann die Zeit die danach gewartet wird bis der TX abschaltet. (gleiches gilt für BAKE_LEN) wenn die Bake z.b. 10 Sek. lang ist muss "BAKE_LEN=10000" rein. 

Aktuell bin Ich in der "Sommerpause" - Haus, Hof, Garten, Familie, Urlaub hat Vorrang daher pausieren die Programmier-Arbeiten bis zum Herbst, also noch etwas Geduld bis zur nächsten Veröffentlichung.

Das sich der Teamspeak-Client manchmal aufhängt (scheinbar grundlos) muss evtl. genauer beobachtet werden ob es am Plugin liegt oder andere Ursachen hat.

73 von DO5ALF/Andreas 
     

Guten Morgen,
ich habe auch eine Frage bzgl. des Plugins. Ich habe vorher eine Yaesu FT710 verwendet über die internen COM Schnittstellen. Das hatte super mit "TXRTS=1" funktioniert. Nun habe ich Xiegu X6100 mit der das nicht so funktioniert.

Digitale Betriebsarten wie JS8Call und WSJTX funktionieren hingegen super.
Die COM Schnittstellen werden sowohl in Windows als auch bei Linux mit COM13, COM14 bei Windows und bei Linux mit "/dev/ttyACM0" bzw. "1" angezeigt.

Die Soundkarten sind auch vorhanden. Nur bekomme ich es mit dem Plugin weder bei Linux noch bei Windows zum laufen. Die COM Schnittstellen werden angezeigt und stehen zur Verfügung, lösen aber nicht aus. Die Xiegu X6100 arbeitet mit CI-V CAT Schnittstelle. Kann mir einer sagen, wie ich das zum laufen bekomme? Ob Windows oder Linux ist relativ egal, da ich beide zur Verfügung habe.


Ein anderer OM meinte, in der Config Datei bei Linux könnte ich anstelle von "TXRTS=1" auch "TXTXD=1" verwenden oder ähnliches. Das funktioniert jedoch nicht.


Bei Windows finde ich leider keine Config Datei, sondern nur über den Teamspeak das bereitgestellte Pluginmenu worin ich die Einstellungen vornehmen kann. 

zuletzt bearbeitet: 12.09.2025 / 7:18 MEZ

Hi Andreas,
für ein neues Gateway habe ich einen kleinen Linux-Mint-Rechner mit einem USB2SER-Adapter. Trotz gesetzter Rechte bekomme ich im Log fortwährend Port-Error auf /dev/ttyUSB0.

Der Port läuft in anderen Anwendungen. Irgendeine Ahnung?
Auszug vom dmesg



VG
Carsten 

zuletzt bearbeitet: 9.12.2025 / 8:54 MEZ

Meine Rechte-Problematik scheint sich von allein erledigt zu haben. Vielleicht habe ich nicht lang genug gewartet.
Beste Feiertagsgrüße
Carsten 

Hey Carsten, manchmal lösen sich Probleme auch von selbst auf, wenn man nur lange genug wartet  

Hi Andi,
ich habe nun einen neuen Rechner für das CB-GW aufgebaut. Die DTR-Schaltung läuft problemlos mit einem Relais dazwischen, weil viele Geräte beim RX eine Receive-Control gegen Masse benötigen, wie auch PTT gegen Masse.
Nun aber folgendes Problem:
der TS3Client im Linux stellt komplett willkürlich unmodulierte Träger ins Netz, also zum Server. Auch wenn NICHTS am Eingang anliegt. Wenn ich die Verbindung SpkOut-CB nach Sound-In-PC trenne, hört das auf. Ich selber höre es nicht, aber die angeschlossenen Kunden am Server hören wohl ein leises Rauschen.
Dieser "Impuls" kommt nach ein paar Sekunden und hält für 1 oder auch mal mehrere Sekunden.

Kennst du das, oder kennst jmd, der einen kennt, der das schon mal beseitigt hat?

LG für die Feiertage!
Carsten 

Das liegt wahrscheinlich an der VOX vom TS3-Client, wir hatten diesen Effekt früher auch schon unter Windows beobachtet in Verbindung mit der VOX.
Zwei mögliche Ursachen könnten dafür verantwortlich sein.
1. VOX ist zu empfindlich eingestellt
2. es liegt ein leichtes Potenzial auf der Audio-Leitung (leises Brummen oder rauschen) was sporadisch die VOX auslösen tut.


Gruß Andi 

Vielen Dank Andreas für diese technische Information.
VY 73 aus Hamburg DO6HM Wolfgang 

Leichtes Brumm oder Rauschen:
Ja, die Rauschsperre schaltet nicht vollständig den Ton aus. Es kommt tatsächlich noch ein leichtes Rauschen durch, wenn auch sehr leise. Danke für diesen Tip. Aber...
Wie müsste denn die VOX-Einstellung am TS3-Client und/oder in der config.ini des PTT-Plugins eingestellt sein? Gibt es da Richtwerte?

VG
Carsten 

Hallo Carsten. Die Rauschsperre ist von System zu System individuell, jedoch kann in deinem Fall eine Entkopplung – zum Beispiel durch einen Entstörfilter, wie er früher häufig in PKW-Hifi-Equipment verwendet wurde – helfen und sollte das Problem eigentlich beseitigen. 

Ich habe gerade den Linux-Rechner nicht am laufen aber Ich denke auch beim TS3 für Linux hast Du in den VOX-Einstellungen die Möglichkeit den "Mode" einzustellen. Dort lässt sich umstellen ob die VOX nur auf einen Audio-Level oder auf Sprache reagiert. 
Damit lässt sich die VOX umstellen das sie nur schaltet wenn auch wirklich Sprache erkannt wird, eventuell lässt sich damit das Problem beheben.

Gruß Andi  

Ja!
Genauso war das. Der Vox-Trigger war ganz unten und hat ständig ausgelöst. Nun hab ich ihn etwa bei "0" in der Mitte stehen. Das sollte erstmal reichen und die willkürlichen Träger haben sofort aufgehört.
Vielen Dank für eure Unterstützung. Und tolle Feiertage noch!

LG
Carsten

ps.
gehört eigentlich nicht in diesen Thread, weil Grundlagen TS3-Client. 

zuletzt bearbeitet: 26.12.2025 / 13:40 MEZ

Nachdem wir mit dem Profilic-Adapter unter Linux zur PTT-Steuerung auch immer unsere Probleme hatten, habe ich festgestellt, dass sich der Adapter ab und zu einen anderen Symlink gezogen hatte.
Unter /dev/ttyUSB0 läuft ja noch alles sauber. Ein Neustart kann aber dazu führen, dass dieser Link noch da ist, und sich der Adapter einen anderen zieht: /dev/ttyUSB1.
Wenn nun der TS3-Client auf ttyUSB0 eingestellt ist und der Adapter aber unter ttyUSB1 läuft, geht logischerweise keine PTT mehr.
Abhilfe schafft hier eine Zuweisung mittels einer udev-Regel in Bezug auf den Adapter, der am Rechner angeschlossen ist. Profilic hat die Vendor-ID 067b und die Product-ID 2303. Diese Info ist mit lsusb oder lsusb -v zu erfahren.
Man nimmt nun diese Informationen, packt sie in eine neue Datei, zum Beispiel:
/etc/udev/rules.d/11-usb2serial.rules
Der Inhalt der Datei sieht dann so aus:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", NAME="ttyUsb2Serial", SYMLINK+="ttyUsb2Serial"
Nach einem Neustart des Rechners, sollte nun ein neuer Symlink auftauchen:
ls /dev/ttyU*
/dev/ttyUSB0  /dev/ttyUSB1  /dev/ttyUsb2Serial

Unter Linux kann nun genau dieser Profilic-Adapter unter /dev/ttyUsb2Serial angesprochen werden. Natürlich nicht vergessen das TS3-PTT-Plugin mit dieser Info in der Config zu versorgen.
Ich möchte hier noch auf das Tool statserial verweisen, mit dem man den Comport monitoren kann.
Aufruf dann mit: statserial /dev/ttyUsb2Serial 

zuletzt bearbeitet: 25.02.2026 / 12:13 MEZ