SvxServer vs SvxReflector

Hallo,

Mein Name ist Luc, LX1IQ.
Einige kennen mich sicherlich schon aus der digitalen Welt :-).

Ich wollte dieses Thema einfach mal hier anschneiden um zu sehen wo der Zug hinfährt.

Hier in LX haben wir 4 VHF Relais die exklusiv in VHF laufen und mit denen wir quasi 95% von Luxemburg abdecken.
Nun möchten ich diese Relais dynamisch verlinken, sprich alle Relais sollen default mäßig zusammen gelink sein, so dass man durch ganz Luxemburg zu hören ist egal wo man einsteigt.
In D-Star haben wir das ja schon über den XLX.

Damit bei Bedarf ein lokales Schwätzchen aber nicht ganz Luxemburg behelligt wäre es nett wenn man via DTMF gezielt ein Relais zu oder wegschalten könnte.
Soweit ich weiß ist das in SvxServer möglich?
Im Moment beschäftige ich mich mit der letzten SvxReflektor Version die eigentlich schon ganz stabil bei mir auf einem Testserver läuft.
Soll die Reflektor Version am Schluss den Server ersetzen oder sollen beide Lösungen parallel weiter gepflegt werden?

Ich stelle hier die Frage weil ich keine Lust habe das Rad immer wieder neu zu erfinden.
Bitte nicht gleich hauen, sollte das Thema schon mal behandelt worden sein. :mrgreen:

73 aus LX - LX1IQ / Luc

Hallo Luc,

der SvxServer war vor längerer Zeit mal ein Ansatz um Relais per SvxLink zu verbinden. Er wird noch mitgeschleppt aber ich denke, das Teil sollte irgendwann aus den Sourcen entfernt werden.
Inzwischen ist der SvxReflector im Trunk und damit fester Bestandteil des Projektes. Bitte nur den SvxReflector für alle neuen Projekte nutzen!

Viel Erfolg + 73s de Adi / DL1HRC

Hallo Adi,

Danke für die rasche Antwort.
Gut zu wissen, dann verschwende ich keine Zeit mit dem alten Server.
Gibt es schon einen Ansatz zur dynamischen Verlinkung von Relais durch den User oder muss ich mir da selber etwas zusammen stricken?

73, Luc

Quote

Gibt es schon einen Ansatz zur dynamischen Verlinkung von Relais durch den User oder muss ich mir da selber etwas zusammen stricken?

Hi Luc,

ja, per DTMF.Kommando über Funk oder per cronjob per Senden von Zeichen über ein Pseudo-TTY. Der Befehl für Connect und Disconnect einers Repeaters wird im LINK-Abschnitt definiert, Bsp:

[GLOBAL]...LINKS=Link...[Link]CONNECT_LOGICS=RepeaterLogic_70cm:45,RepeaterLogic_2m:46,ReflectorLogic:66...

Im o.g. Beispiel kannst Du per DTMF-Kommando 451# die RepeaterLogic_70cm mit dem Reflector verbinden, 450# trennt RepeaterLogic_70cm. Analog dazu 461# auf der RepeaterLogic_2m bzw. 460#. Der Befehl 66x# auf der ReflectorLogic ist nur der Vollständigkeit halber definiert. Das geht natürlich nicht vom Reflector per Netzwerk.
DTMF-Befehle kannst Du natürlich auch per Pseudo-TTY an eine Logic senden. Hierzu mu Du im Logic-Bereich den Parameter z.B.

DTMF_CTRL_PTY=/tmp/dtmf

definieren, dann kannst Du per

echo "451#">/tmp/dtmf

die betreffende Logic ansteuern.
Achtung: Es wird der Empfang per HF simuliert, wenn der Repeater also erst per ' geöffnet werden muß, damit die DTMF-Kommandos akzeptiert werden, mußt Du das natürlich auch so machen:

echo "*451#">/tmp/dtmf

Ich hoffe, ich konnte Dir helfen, viel Erfolg weiterhin bei Eurem Projekt in Luxemburg!

vy 73s de Adi / DL1HRC

Hallo Adi,

Exzellent !! Genau diese Info habe ich gebraucht.
Gibt es irgendwo eine technische DOC zum SvxReflektor ?

73, - Luc –

Quote

Gibt es irgendwo eine technische DOC zum SvxReflektor ?

Nur die manual page. Du möchtest sicher eine Protokollbeschreibung usw. haben? Nee, leider nicht wirklich. Dokumentation bis ins letzte Detail steht leider bei vielen OpenSource-Projekten nicht an erster Stelle

vy 73s de Adi / DL1HRC

Wahre Worte :-).
Bevor ich aber mit dem Finger auf andere zeige nehme ich mich mal selbst mit der Nase.
Der XLX hat mittlerweilen über 100.000 Zeilen Code und da suchst du auch vergebens nach den Protocol Spezificationen.

Naja, der Sourcecode vom SvxReflektor ist ja noch überschaubar.

Schönes Woenende und danke für die Hilfe - Luc -

Hi Luc,

ich hätte mal noch eine Frage zu den Streams beim XLX, die zwischen den einzelnen Nodes laufen. Wird da nur zwischen DMR-Codec und DStar/C4FM usw. transcoded oder gibt es an einer Stelle auch eine Möglichkeit den decodierten Raw-Audio-Stream abzugreifen?

73s de Adi / DL1HRC

Hallo Adi,

Sollten wir das nicht per E-Mail oder PM machen?
Wir sind ja hier in einem SVX Forum und ich bin mir nicht sicher ob die Leute an dem XLX bzw. der Technik wie wir transcodieren intressiert sind.

LG - Luc -

Hm, ich denke es gibt sehr großes Interesse von OM's für diesen "interkulturellen" Austausch, gerade hier bei einigen SvxLink-Entwicklern. Ich selbst betreibe auch zwei DMR-Relais und hätte gern eine Verbindung zwischen z.B. TG9 oder TG8 und dem SvxReflector-Regionalverbund hier in der Region Mitteldeutschland.

Ok, bin unter meinemcall [ät] gmx.de zu erreichen.

vy 73s de Adi / DL1HRC

Hallo Adi,

Nein kein Problem, ich kann das gerne hier kurz erleutern.
Ich wollte halt nur nicht das Forum mit Offtopic zu spammen.

Also die Transkodierum auf dem XLX erfolgt folgendermassen:

Kommt ein Stream am XLX an, egal ob D-Star oder DMR, wird dieser vom XLX in Daten und Audio Stream aufgeteilt.
Der Datenteil der auch die Call bzw. DMR ID enthält wird direkt vom XLX in das jeweilige Format transkodiert.
Sprich aus einem DMR Header baut der XLX einen D-Star Header und umgedreht, so dass die jeweiligen Endgeräte was damit anfangen können.
In der Zwischenzeit sendet der integrierte AMBE client den AMBE Stream raw an unseren AMBed Server.
Der AMBed Server transcodiert den digitalen PCM Stream dann via unseren USB-3006 ( Eigenentwicklung mit zwei AMBE 3003 Chips) Hardware Transcoder von AMBE2 nach AMBE2+ bzw umgedreht.
Anschliessend wird der transcodierte PCM Stream wieder vom AMBed Server zum XLX zurück geschickt wo er wiederum mit dem transcodierten Header vom XLX zusamengesetzt wird.

Ich hoffe diese Erklärung war verständlich?
Deutsch ist nicht meine Muttersprache und ich bitte um Nachsicht bei Schreibfehlern. :oops:

Das ganze Projekt ist Open Source und man kann es sich in meinem git unter https://github.com/LX3JL inklusive der Platinenlayouts des Hardware USB-3006 anschauen.

LG - Luc -

Hi Luc,

Quote

Ich wollte halt nur nicht das Forum mit Offtopic zu spammen.

keine Sorge, es ist immer gut mal über den Tellerrand zu schauen. SvxLink hat ja auch jede Menge digitale Algorithmen eingebaut.
Vielen Dank auch für die Ausführungen zum XLX-Verfahren.
OK, also habt Ihr da beim XLX-Adapter an keiner Stelle einen raw-Audiostream zum Abgreifen z.B. als Monitor-Funktion, sondern konvertiert von DStar nach DMR und umgekehrt.

Ich habe vor einiger Zeit mal angefangen mit einem ThumbDV-USB-Stick von NW-Digital zu experimentieren. Ziel soll sein, einen analogen Audiostream zu En-/Decodierung und dann in das Rewind-Protokoll des BM-Netzwerks zu verpacken um damit einen Gateway zu realisieren. Ein erster Branch ist auf meinen github-Account zu sehen.
Nun muß ich leider gestehen, dass ich recht wenig Kenntnisse in C++ habe und entsprechend ist sicher auch die Umsetzung. Des weiteren gibt es noch ein paar Fragen, insbesondere mit dem En-/decoder-Chip, beispielsweise das eigenartige "Rauschen", welches beim Encoden des analogen Streams entsteht. Da fehlen mir leider noch ein bisschen mehr Informationen, aus dem Manual kann ich da leider nicht viel entnehmen. Soweit dazu.
Im Übrigen schreibst Du ein hervorragendes Deutsch, ich kann wirklich nicht erkennen, dass es nicht Deine Muttersprache ist
Ich stöbere gerade mal ein bisschen in Deinem github-Repo.

vy 73s de Adi / DL1HRC

Hi Andi,

Quote

keine Sorge, es ist immer gut mal über den Tellerrand zu schauen. SvxLink hat ja auch jede Menge digitale Algorithmen eingebaut.

Das sehe ich genau so.

Quote

OK, also habt Ihr da beim XLX-Adapter an keiner Stelle einen raw-Audiostream zum Abgreifen z.B. als Monitor-Funktion, sondern konvertiert von DStar nach DMR und umgekehrt.

Eine Monitor Funktion macht in meinen Augen bei 26 Modulen, die ja theoretisch gleichzeitig genutzt werden können, auf einen XLX Reflektor nicht wirklich Sinn.
Man könnte sicherlich das XLX Interlink Protokoll für svxReflektoren erweitern.
Allerdings hätte man dann das Problem der eindeutigen Call Zuweisung die es ja im analog Betrieb nicht gibt, hingegen für Digital Funk gebraucht wird.
In dem Fall müsste man ein dummy call für svxlink Verbindungen verwenden.
Mit so einer Lösung könnte ich mich nur sehr schlecht anfreunden.

Quote

Ich habe vor einiger Zeit mal angefangen mit einem ThumbDV-USB-Stick von NW-Digital zu experimentieren. Ziel soll sein, einen analogen Audiostream zu En-/Decodierung und dann in das Rewind-Protokoll des BM-Netzwerks zu verpacken um damit einen Gateway zu realisieren.

Ja, damit hatte ich auch schon rumgespielt, allerdings mit der seriellen 3000er Platine du man direkt auf den Raspi aufstecken kann.
Ich hatte damit die 1. DMR -> D-Star Bridge auf dem XLX gebaut.
Den Stream hatte ich direkt am Repeater über die API Schnittstelle abgegriffen.
Allerdings habe ich das wieder schnell verworfen wegen der schlechten Qualität.
Die Relais geben nämlich den decodierten PCM nur komprimiert raus was in meinen Augen nicht wirklich nutzbar ist zum Weiterverarbeiten.

Auf dem XLX bleibt alles voll digital und wird nur von AMBE2 nach AMBE2+ und umgekehrt transcodiert. Die Grätsche über eine analoge Schnittstelle entfällt so was wiederum die exzellente Sprachqualität der Transcodierung erklärt.

Quote

Im Übrigen schreibst Du ein hervorragendes Deutsch, ich kann wirklich nicht erkennen, dass es nicht Deine Muttersprache ist
Ich stöbere gerade mal ein bisschen in Deinem github-Repo.

Danke für die Blumen ich hoffe mein Repo gefällt dir.

73, Luc

Hi Luc,

sri für die Verzögerung, im Moment hab ich ein bisschen mehr um die Ohren hier

Quote

Eine Monitor Funktion macht in meinen Augen bei 26 Modulen, die ja theoretisch gleichzeitig genutzt werden können, auf einen XLX Reflektor nicht wirklich Sinn.
Man könnte sicherlich das XLX Interlink Protokoll für svxReflektoren erweitern.

So ganz blicke ich da noch nicht durch, 26 Module? Wenn ich mich recht erinnere kann ein AMBE3xxx-Chip wohl gleichzeitig duplex en/decodieren. Muß mir das noch mal genau anschauen.

Quote

Allerdings hätte man dann das Problem der eindeutigen Call Zuweisung die es ja im analog Betrieb nicht gibt, hingegen für Digital Funk gebraucht wird. In dem Fall müsste man ein dummy call für svxlink Verbindungen verwenden.
Mit so einer Lösung könnte ich mich nur sehr schlecht anfreunden.

Im DMR existiert nirgendwo im Protokoll das Amateurfunk-Rufzeichen, nur die DMR-ID. Diese ID hat aber nicht den Status einer offiziellen Rufzeichenzuteilung. Zumindest für DL sehe ich hier keine Probleme, das war ja oft das Argument weshalb man analoge und digitale Systeme nicht verbinden dürfe.

Quote

Den Stream hatte ich direkt am Repeater über die API Schnittstelle abgegriffen.
Allerdings habe ich das wieder schnell verworfen wegen der schlechten Qualität.

Bei SvxLink wird ja auch ein Mal ganz am Anfang digitalisiert, danach bleibt es das auch erst mal - zwischen den Nodes wird meist Speex oder Opus verwendet. Gesampelt wird mit 16k, 22k05 wären auch machbar. Das sollte für eine ordentliche Qualität ausreichen.
So richtig habe ich mich, ehrlich gesagt, noch nicht an den digitalen Klang von DMR gewöhnt :lol: An DStar bin ich gar nicht rangekommen.

Ich denke, dass es im Dezember etwas ruhiger wird, dann krame ich meine DMRLogic noch mal raus und baue weiter daran.
vy 73s de Adi / DL1HRC

Hallo Adi,

In D-Star kann ein XLX Reflektor 26 Module handeln, sprich es können 26 QSO‘s gleichzeitig auf einem Reflektor laufen was dann wiederum TG4001-4026 in DMR entspricht.
Diese Zuordnung hat aber weder mit dem DMR+ Netz noch mit Brandmaster etwas zu tun.

Ein AMBE 3003 hat drei Kanäle.
Zur Transcodierung werden jeweils die Kanäle paarweise genutzt.
Es können also mit einem 3003 zwei QSO‘s gleichzeitig transcodiert werden.

Mit dem Rufzeichen hast du zwar recht, allerdings wird die DMR ID genuzt um auf der D-Star Seite ein gültiges Rufzeichen zu erstellen.
Ohne Call funktioniert D-Star nicht.
Würde man also ein svxlink Signal via Interlink auf einem XLX einspeisen, müsste dieser für D-Star ein Rufzeichen bzw. für DMR eine ID generieren.
Da diese Info aber im Svxstream nicht enthalten ist, müsste man mit dummy Rufzeichen und ID‘s arbeiten damit ein QSO auf DMR und D-Star zustande käme.

Der Audiostream ansich ist wie du siehst nicht das Problem sondern die Generierung der jeweiligen digitalen Header.

73, Luc