KLC hat geschrieben:Und wo ist da das Problem ?
Als Laie stelle ich mir das so vor, daß ich mich, wenn ich ein Gateway habe, nicht auf die Laberplattform gehe, sondern "schließe mich mit einem Gleichgesinnten kurz". Soviel Maschinerie und Rechnerleistung brauch ich doch wohl nicht, wenn ich nicht aufzeichne....
Oder habe ich da einen Denkfehler eingebaut.
Kann man dazu nichts vom VCBF mißbrauchen ?
Ich meine der Jürgen Decker hat da was in der Richtung an den Start gebracht.
Rolf
Sowas wäre bestimmt für EINIGE aus dem Forum interessant.
Hallo,
wenn das so einfach wäre, dann hätten wir vielleicht schon brauchbare reine HF-GW-Netze.
Gibt es überhaupt genug "Gleichgesinnte" die sich mit den komplexen Fragestellungen eines vernüftigen HF-Gateway-Netzes auseinandersetzen wollen und finanziell und zeitlich ein entsprechendes GW betreiben würden???
Es reicht ja nun mal nicht, einfach mal schnell ein GW aufzuziehen, es stellen sich Fragen wie:
-Ist der Standort überhaupt sinnvoll? Decke ich damit einen ausreichenden RAdius ab?
-Wenn es am Heimat QTH aufgebaut werden soll, was ist mit einer Parallelnutzung d.h. was mache ich wenn ich selbst direkt QRV sein will? Doppeltes Equipment? Gegenseitige Beeinflussung?
-Wie kann man die Betriebskosten abdecken oder minimieren? (Miete zus. Internetkosten bei abgesetztem Standort, Stromverbrauch, Equipment)
Hier muss man mal über Alternativen suchen. Könnte ein Schulstandorte (weiterführende oder Berufsbildende) eine Möglichkeit sein? Manchmal existieren in solchen Standorten schon Clubstationen des Amateurfunk und Internetanbindung gibt es meist auch. Haben wir hier Leute die dorthin gute Kontakte haben?
Das Softwarethema ist nicht so ganz trivial wenn bestimmte Funktionen machbar bzw. erweiterbar sein sollen und das Netz rein für HF-User und möglichst auch HF-Seitig administrierbar sein soll.
Ich denke da an Funktionen wie z.B.
-DTMF AUftastung falls CTCSS nicht ausreichend sein sollte oder noch nicht verbreitet genug ist
-Zyklisches Aussenden der eigenen Kennung
-GW-Kennung per DTMF abfragen
-Erkennen und entsprechende Ansage wenn die Internetverbindung verloren geht
-Erkennen und entsprechende Ansage wenn am Gateway ein Fehler vorliegt (z.B. Temperaturgrenze überschritten)
-DTMF-Abfrage des S-Wertes (sofern das GW-Funkgerät einen externen Ausgang besitzt)
-Voicebox, per DTMF anmelden und einem anderen User eine Voicenachricht hinterlassen. DIe Voicenachrichten sollen jeweils auf dem GW des Empfängers abgelegt werden und bei Abfrage der eigenen Voicebox dieses auch nur auf dem GW ausgeben auf dem man abfragt.
-Labersperre, also eine Empfangszeitbegrenzung. Bei mehrfachem Ansprechen der Labersperre eine Ansage ausgeben, danach bei weiterem mehrfachen Ansprechen (Warum auch immer z.B. DX-Bedingungen) eine temporäreres automatisches Muting dieses Empfängers
-Signal-/Rauschabstand bewerten mit einstellbarer Grenze
-ALC Angleich der NF-Pegel in beiden Richtungen
-Bandbreite konfigurierbar
-ggf. P2P-Konzept also ohne zentralen Server auskommend, d.h. die verfügbaren GW machen untereinander automatisch einen Master aus
- ...
Die meiste SW ist nicht Opensource, somit nicht flexibel erweiterbar. Meine Programmierkenntnisse reichen leider nicht aus, um solche Anforderungen mal eben selbst runter zu programmieren
SVXLInk stimmt mit meinen Vorstellungen schon recht gut überein. Allerdings sind dann beim GW-Betreiber Unixkenntnisse erforderlich, das kann sicher nicht immer vorausgesetzt werden.
Gruß
Jörg
