Hallo alle,
ich freue mich sehr, wenn junge OMs Ihre Bereitschaft erklären an einem Projekt mitarbeiten zu wollen. Ich denke man kann hier noch jede Menge Arbeit reinstecken und das SvxLink-Projekt wird trotzdem niemals fertig werden. Ein paar Ideen, die der ganzen Sache ein bisschen Vorschub verleihen könnten habe ich schon. Ich will das einfach mal so als Punkte aufführen, wohlwissend, dass viele dieser Punkte mehr oder weniger tiefe Änderungen/Erweiterungen im C++-Sourcecode nach sich ziehen werden und nicht jeder da mithelfen kann.
Das ist aber oft gar nicht notwendig, manchmal hilft auch einfach nur ein Tip eines OM's mit etwas (Lebens-)Erfahrung.
1) SvxServer
Das Ding ist eigentlich eine Krücke, weil es momentan zwingend kompatibel zum RemoteTRX-Protokoll sein muß, damit die ganze Sache funktioniert. Ich sehe hier sehr viele Verbesserungsmöglichkeiten:
- Umbau auf UDP-Protokoll, möglicherweise solche Erweiterungen wie Multicast
- Nur ein Netzwerk-Adapter für RX und TX, statt zwei getrennter Andock-Mechanismen für RX und TX
- Aufbohren des NetTrxMsg-Protokolls, Übergabe weiterer Parameter wie z.B. Rufzeichen, Bemerkungen zwischen RepeaterLogic/SimplexLogic und NetLogic, keine "Generierung" eines SQL-Kriteriums mehr auf Grund eines einsetzenden Audiostreams
- Erweiterung um einen SvxServer-2-SvxServer-Adapter, d.h. die zentralen SvxServer-Instanzen sollen in der Lage sein, weitere Anfragen von SvxServern entgegenzunehmen und wenn validiert an alle angeschlossenen Clients weiterzuleiten
Das Problem hier ist, dass der Chef (Tobias) - wie ich denke - noch nicht so ganz die Vorteile einer solchen Implementierung erkannt hat. Somit fristet diese Erweiterung momentan ein mehr oder weniger klägliches Dasein. Eventuell könnt Ihr ja noch ein paar mehr Ideen einbringen wie man diesen Ansatz weiterverfolgen könnte und möglicherweise auch in dieser Richtung argumentieren. Es ist momentan nicht der Weisheit letzter Schluß was ich da zusammengeklickt habe, das weiß ich natürlich. Aber ich denke, dass die Leute, welche sich damit beschäftigt haben schon den ein oder anderen Vorteil gegenüber klassischen Verfahren wie EchoLink erkannt haben.
2) Erweiterung um einen SIP-Clienten
3) Co-Channel
Eine Gleichwellenerweiterung könnte dem SvxLink-Projekt auch ganz neue Impulse verleihen. Hier ist es wichtig die lokalen Zeiten und das Audiosteaming extrem genau zu synchronisieren (GPS, DCF77, ..). Unsere Freunde aus PA sind hier schon sehr weit und haben jede Menge Erfahrung. Ich würde gerne den co-channel-Code in das SvxLink-Framework überführen.
4) weitere Sprachen
Bitte testet die vorhandenen verfügbaren Pakete, z.B. Italienisch. Ich bin der Sprache nur marginal mächtig, finde sie einfach nur schön. Paßt die tcl's bitte dem Umgebungssprachgebrauch an und erweitert die Ausgaben, bin gern behilflich falls neue Ansagen generiert werden müssen. So kann man die Akzeptanz der "neuen Relaisgeneration" mit Modulen und Funktionen bewirken.
5) Notfunkproblematik
Ich hatte ja auf einigen Relais die Unwetterwarnungen als inoffizielles Modul implementiert. Bitte schaut auch außerhalb DL's nach Möglichkeiten wie man derartige Informationen (Unwetter, Hitze, Hagel, Sturm,...) auf die Relais bekommt um eine Art Not-Informationssystem zu implementieren. Ich denke solche Sachen könnten den Status des Amateurfunks schon ein bisschen stärken. Ganz sicher nicht in meiner Heimat Sachsen-Anhalt - da habe ich jegliche Hoffnung, Relaisbetrieb auf gleicher Augenhöhe einfach so zu akzeptieren aufgegeben aber eventuell ist ja in allen anderen Teilen der Welt Hopfen und Malz noch nicht ganz verloren.
6) Verbindung mit anderen Systemen wie DMR, DStar
Liegt definitiv nicht an den SvxLink-Entwicklern
Die Punkte ab 7) kommen dann in den nächsten Wochen Step-by-Step
vy 73s de Adi, DL1HRC