web-ui:gate - PiCQ

Gate -Die Gateway-Einstellungen

Diese Seite wurde noch nicht fertiggestellt! -Sorry

Auf dieser Seite befinden sich alle relevanten Einstellungen zum jeweiligen Gateway. Um das Menü übersichtlicher zu gestalten, habe ich die vielen möglichen Einstellungen der Konfigurationsdatei in logische Blöcke zusammengefasst und nach Relevanz/Häufigkeit des Aufrufes sortiert. Dies bringt den Vorteil, dass man nicht die gesamte Konfiguration durchscrollen muss um lediglich in einen anderen Raum auf dem Server zu wechseln.

Die jeweiligen Rubriken können durch Klick auf das „[+]“- Symbol ausgeklappt werden, sowie bei Nichtbedarf durch Klick auf das „[-]“- Symbol wieder zugeklappt werden. Jeweilige Änderungen werden erst durch Klick auf den grünen Button „Speichern“ übernommen. Um den Komfort weiter zu steigern habe ich die Felder, die nur Ja/Nein Antworten verlangen, durch entsprechende Auswahlboxen ersetzt.

Durch Klick auf „Speichern“ werden sämtliche Einstellungen inkl. eurer Änderungen an den „Saver“ gesendet. Dieser übernimmt sie nun und schreibt sie in die Datenbank des Web-UI zurück. Anschließend ruft er den „Importer“ auf, welcher das entsprechende Gateway zunächst anhält, die neue Konfiguration aus der Datenbank nun in den Gateway-Ordner importiert und schließlich das Gateway mit seinen neuen Einstellungen wieder neu anfährt.

Server

An dieser Stelle wird der Zielserver angegeben, in dessen Raum das Gateway arbeiten soll.

Server Ardesse

Hier wird die Adresse des Zielservers angegeben (z.B. www.1a-funkfeuer.de). Alternativ kann auch die IP-Adresse des Servers verwendet werden (z.B.: 81.20.133.6).

Server Port

Hier soll der Port angegeben werden auf dem der Server angesprochen werden kann.

Raum Name

Dies bestimmt den Raum in dem das Gateway arbeiten soll (z.B. Berghütte).

Sichtbarkeit/Status

Hier wird genau wie bei der Windows Version der Sichtbarkeitsstatus gesetzt. Mögliche Werte sind: AV für QRV, NA für beschäftigt und AS für abwesend/QRT.

Backupserver verwenden

Es kommt immer wieder einmal vor, dass ein Server nicht erreichbar ist und/oder ausfällt. Für solche Fälle sieht das FRN-Protokoll den Backupserver vor, der bei einem Ausfall des Hauptservers vorübergehend an dessen Stelle tritt. Ist diese Funktion mit Ja beantwortet, versucht das Gateway bei einem Ausfall des Hauptservers über den Backupserver weiterzuarbeiten. –Andernfalls versucht es noch eine vorgegebene Anzahl an Neuverbindungen, und stellt danach den Betrieb ein um den Monitorserver nicht unnötig mit neuen Anfragen zu belasten.

Backupserver Adresse / Port

Hier kann nun die Adresse des Backupservers und dessen Port angegeben werden.

Account

Hier werden nun die Daten des FRN-Accounts angegeben, wie sie bereits im Vorfeld auf einem Windows-Rechner registriert wurden. (Hinweise dazu)

Die aus PiGate 2.5 und PiGate 2.6beta bekannte Funktion „ACC+“ wurde bisher noch nicht von mir in PiCQ umgesetzt.

Rufzeichen

in dieser Zeile kann das Rufzeichen (für lizensierte Funk-Amateure) oder der Skip (für CB-, Freenet- oder PMR-Funker) eingegeben werden.

Name

Hier kann der Vorname des Gatewaybetreibers angegeben werden. (Ich persönlich halte jedoch eine andere Angabe für sinnvoller (s. Hinweise dazu))

Deine e-Mail Adresse

Trage bitte an dieser Stelle unbedingt die E- Mail Adresse ein, die Du bei der Registrierung des FRN-Accounts angegeben hast. (s. Hinweise dazu))

Ort/Ortsteil

Der Name des Ortes, in dem dein Gateway steht. (s. Hinweise dazu))

Passwort

Tragt hier bitte das Passwort ein, welches euch nach eurer Registrierung des FRN-Accounts an die angegebene E-Mailadresse gesendet wurde.

Land

Hier muss das Land angegeben werden in dem das Gateway steht. –Und zwar in genau der Schreibweise, wie es auch in den Windows-Versionen von FRN geschrieben wird. Falls dies nicht exakt eingehalten wird, kommt leider keine Verbindung mit dem FRN-Monitorserver zustande, was bedeutet, dass das Gateway auch nicht online geht. (z.B. Germany) TIPP: Falls Du nicht sicher bist, wie das entsprechende Land geschrieben wird, verwende vorerst Germany und erkundige dich später.

Weitere Beschreibung

Beschreibungen zu eurem Gateway. (z.B. verwendetes Funkgerät, Antenne usw. Dieses Feld wird bei anderen PiCQ-Gateways jedoch nicht angezeigt, aber z.B. bei der originalen FRN-Windowssoftware)

Audio

Radio

Hier wird nun angegeben, wie der Raspberry euer Funkgerät steuert. Am einfachsten funktioniert dies mit einem Relais, welches man an den GPIO-Port anschließt. Habt ihr jedoch bereits ein Interface von anderen Anwendungen, solltet ihr auch in der Lage sein, dieses weiter zu verwenden.

Inzwischen habe ich von 2 Leuten die Rückmeldung erhalten, dass das Sturzvogel-Interface v.2 erfolgreich mit PiCQ funktioniert.

Wenn ihr gerne über den GPIO schaltet, so müsst ihr leider strikt die von mir vorgegebenen GPIO-Ports, für das entsprechende Gateway benutzen, da ich nur diese dem System für die Verwendung durch den Clienten abgerungen habe.

PTT

Beim Schalten über GPIO sind hier folgende Werte einzutragen:

  • GPIO:24:gpio24:NORMAL (Bei Gateway1 wenn die PTT an den Schließerkontakt des Relais angeschlossen ist (empfohlen)
  • GPIO:24:gpio24:INVERTED (Bei Gateway1 wenn die PTT an den Öffnerkontakt des Relais angeschlossen ist (nicht empfohlen aber machbar)
  • GPIO:4:gpio4:NORMAL (Bei Gateway2 wenn die PTT an den Schließerkontakt des Relais angeschlossen ist (empfohlen)
  • GPIO:4:gpio4:INVERTED (Bei Gateway2 wenn die PTT an den Öffnerkontakt des Relais angeschlossen ist (nicht empfohlen aber machbar)

Bei Schaltung über ein USB→RS232 Interface nutzt bitte folgende Werte:

  • COM:/dev/ttyUSB0:RTS:I (Wenn das Interface mittels RTS-Leitung schaltet)
  • COM:/dev/ttyUSB0:DTR:I (Wenn das Interface mittels DTR-Leitung schaltet)

Auch hier kann mit dem Schalter „N“ (für NORMAL) oder „I“ (für INVERTED) die Schaltlogik gewechselt werden. Linux beginnt bei der Nummerierung grundsätzlich bei „0“. Wenn also 2 Interfaces zum Einsatz kommen hat das erste Gerät die Adresse ttyUSB0 und das zweite die Adresse ttyUSB1. Leider kann nicht immer genau vorausgesagt werden, welche Nummer nun welches Interface nach dem Boot bekommt. Daher ist es empfohlen nur ein solches Interface zu verwenden und das zweite Gateway mittels GPIO zu schalten. -Klingt jetzt doof, ist aber so. ;-) Gerne könnt ihr mir aber eure Erfahrungen beim Einsatz dieser Interfaces schreiben, denn da ich ausschließlich mit GPIO schalte, kann ich daher keine eigenen Experimente machen.

COS

Hier gilt im Grunde das Gleiche wie auch bei PTT. -Zusätzlich gibt es hier jedoch auch noch die Möglichkeit mittels VOX zu schalten. (Nutze ich persönlich sehr gerne da es den Schaltungsaufwand verringert)

Die entsprechenden Werte für GPIO sind folgende:

  • GPIO:17:gpio17:NORMAL (Bei Gateway1)
  • GPIO:27:gpio27:NORMAL (Bei Gateway2)

Sollte die Schaltlogik bei euch nicht stimmen, kann diese auch hier mit „NORMAL“ oder eben „INVERTED“ umgeschaltet werden.

Die entsprechenden Werte für die Verwendung eines USB→RS232 Interfaces sind:

  • COM:/dev/ttyUSB0:CTS (Wenn die CTS-Leitung verwendet wird)

Nutzt ihr anstelle dessen lieber die VOX-Funktion, so lautet der entsprechende Eintrag:

  • VOX:1200 (1200 ist ein erster Richtwert)

Die 1200 in diesem Beispiel ist ein erster Richtwert, mit dem die Vox grundsätzlich einmal funktionieren sollte. Je nach verwendeter Soundkarte, Beschaltung und Lautstärke eures Funkgerätes, muss diese jedoch angepasst werden. Hierbei gilt: Je höher der Wert, desto höher die benötigte Lautstärke zum Schalten.

STATIC

Verschiedene, wie auch der alterFRN Client, bieten weitere Einstellungen (Static & Light) an. Um ehrlich zu sein, habe ich diese bisher noch nicht gebraucht und kann mir daher auch keinen Reim daraus machen, wozu sie gut sind. Der Vollständigkeit halber habe ich sie jedoch ins Web-UI übernommen. Werte die ihr hier eintragt, werden also auch in die Konfiguration übernommen. Vielleicht kann mir ja jemand von Euch einmal schreiben, was hier genau eingestellt wird.

LIGHT

Verschiedene, wie auch der alterFRN Client, bieten weitere Einstellungen (Static & Light) an. Um ehrlich zu sein, habe ich diese bisher noch nicht gebraucht und kann mir daher auch keinen Reim daraus machen, wozu sie gut sind. Der Vollständigkeit halber habe ich sie jedoch ins Web-UI übernommen. Werte die ihr hier eintragt, werden also auch in die Konfiguration übernommen. Vielleicht kann mir ja jemand von Euch einmal schreiben, was hier genau eingestellt wird.

Träger Aufbauzeit

Betätigt ihr bei eurem Funkgerät die PTT-Taste, so benötigt der Sender eine gewisse Zeit, bis das Trägersignal steht und euer Audiosignal aufmoduliert werden kann. Damit also beim Senden in dieser Zeit nicht der Anfang eures Satzes abgeschnitten wird, wartet PiCQ eine gewisse Zeit nach betätigen der PTT bis es das Audio an das Funkgerät sendet. Diese Verzögerung kann hier (in Millisekunden) eingetragen werden.

200 ist hier ein recht guter Ausgangswert.

Warten ob Träger ...

Es kommt immer wieder einmal vor, dass euer Funkgerät kurze Störungen empfängt. Damit jetzt nicht jedes Knistern und Knacken beim Empfang als Nutzsignal erkannt und in das FRN-Netz weitergeleitet wird, kann hier ein Schwellwert (in Millisekunden) eingetragen werden, ab welchem ein Signal als sinnvolles Nutzsignal behandelt wird. (Trägt man hier also 200 ein, werden alle empfangenen Signale die kürzer als 200ms dauern einfach ignoriert)

200 ist hier ein recht guter Ausgangswert.

Warten auf Träger bei Unterbr...

Gerade bei Verwendung der VOX, kommt es hin und wieder einmal vor, dass wenn jemand einmal leiser spricht, oder eine Atempause macht, die VOX schon wieder schließt. Dies kann jedoch auch bei Verwendung von COS vorkommen, wenn etwa ein Mobil durch Häuserschluchten fährt und ganz kurzzeitig nicht mehr über eure Squelch (Rauschsperre) kommt. Auch hier würde euer Gateway sofort umschalten, Quittungstöne senden und sich bereit machen wieder etwas von HF oder auch FRN weiterleiten zu können. Dabei können jedoch Wortfetzen oder ganze Worte verloren gehen. Um dieses etwas zu entschärfen kann hier also eine Wartezeit (in Millisekunden) eingetragen werden, während der das Gateway auf eine Fortsetzung des Satzes wartet, wenn eine Unterbrechung stattfand. Dieser Wert sollte jedoch nicht zu groß gewählt werden, da das Gateway bei jedem Empfang über HF, diese Zeitspanne wartet. Bei zu großen Werten wird das Gateway daher also zu träge und schwehrfällig im Ansprechverhalten.

500 bis 600 Millisekunden haben sich bei mir hier als recht guter Ausgangswert herausgestellt.

Warten nach Senden ...

Bei vielen Funkgeräten wirkt die Rauschsperre (Squelch) nach Loslassen der PTT-Taste nicht wieder sofort. Daher ist nach Loslassen der PTT-Taste manchmal auch sofort ein ganz kurzes Rauschen zu hören. Dieses kurze Rauschen würde jedoch dafür sorgen, dass die VOX zum Beispiel sofort wieder anspricht, weil sie denkt es würde ein Nutzsignal empfangen. In einem solchen Fall spricht man auch gerne von einem „Nachtasten“ des Gateway. Um diesem entgegen zu wirken, kann hier eine Wartezeit (in Millisekunden) eingetragen werden, in der sich das Gateway direkt nach dem Senden taub stellt. Somit wird das kurze Rauschen wirkungsvoll ausgefiltert. Der Wert sollte hier jedoch auch nicht zu groß gewählt werden, da das Gateway sonst zu träge wird. Jedoch auch nicht zu klein, da es sonst nachtastet.

200 hat sich bei mir und meinen Geräten als brauchbarer Ausgangswert herausgestellt.


Manager

Hier könnt ihn nun festlegen mit welchem Monitorserver sich euer Gateway verbinden soll.

Monitorserver Adresse

Hier wird die URL des zu verwendenden Monitorservers eingetragen. Ihr habt hier die Wahl zwischen:

sysman.freeradionetwork.eu Das ist der originale FRN Monitorserver von Edwin

oder

sysman.freeradionetwork.de Das ist der alternative FRN Monitorserver —-

Monitorserver Port

Der Port ist bei beiden Monitorservern gleich 10025

Internet

Sollte eure Verbindung mit dem Internet über einen sogenannten Proxy-Server erfolgen, so kann dieser hier eingetragen werden. Verwendet ihr soetwas nicht, tragt einfach NONE in das Typ Feld. Ich verzichte hier auf eine detailierte Beschreibung der Felder, da sie perse schon selbsterklärend sind.

ProxyCharsetName gibt die Codierung an, in der euer Proxyserver Fehlermeldungen zurücksendet. Der Standartwert hier lautet UTF-8 und greift auch, wenn man nichts eingibt.

HINWEIS: Manche Proxyserver haben Zugriffsbeschränkungen auf manchen Ports. Dies kann dazu führen, dass über diesen keine Verbindung zum FRN-Zielserver aufgebaut werden kann. Befragt im Einzelfall den Administrator eures Proxyservers danach, wenn es hier zu Problemen kommt.

Private Message

Hier könnt ihr eine Standartantwort eingeben, die das Gateway automatisch nach FRN zurücksendet, wenn jemand dem Gateway eine Privatnachricht schickt.

DTMF-Funktionen

Da Valery nun auch die DTMF-Funktion in seinem alterFRN-Klienten integriert hat, auf den PiCQ aufbaut, ist PiCQ nun endlich auch mit der sehr praktischen DTMF-Funktion bedienbar. Durch diese kann ein Gateway nun auch über HF (also von einem Funker der darüber funkt) in einen anderen Raum oder einen anderen Server geschickt werden. Ebenfalls ist es möglich hiermit ein Action-Skript von PiCQ zu starten, und somit weitere Funktionen auszulösen (z.B. einen GPIO-Pin zu schalten, oder was man eben in diesem Action-Skript so programmiert).

DTMF Funktion aktivieren

Hier legt man fest, ob das Gateway überhaupt empfangene DTMF-Töne auswerten soll.


DTMF Kommandos

Hier legt ihr die verschiedenen DTMF-Kommandos fest, die euer Gateway befolgen soll. Dies folgt jedoch einer strikten Syntax. Ich versuche es einmal an einem Beispiel zu erklären wie sich das ergibt. Ich beschreibe es mit meinen eigenen Worten, der Programmierer hat es sicher anders benannt, jedoch kann ich es nicht ordentlich aus dem Russischen übersetzen und auch noch erklären. Ich bitte daher um Nachsicht.

Die Komandozeile, wie ich sie nenne, setzt sich aus den einzelnen Kommandoblöcken zusammen. (Wenn mehrere Befehle programmiert werden sollen.) Die einzelnen Kommandoblöcke werden durch ein „;“ (Semikolon) voneinander getrennt. Alles wird in einem Rutsch, ohne Leerzeichen, geschrieben.

<Kommandoblock>;<Kommandoblock>;<Kommandoblock>

Die Kommandoblöcke setzen sich aus dem DTMF-TEXT, der AKTION und den ATRIBUTEN zusammen und werden durch „:“ (Doppelpunkte) voneinander getrennt. Auch einzelne Atribute werden wieder durch Doppelpunkte getrennt, wie

z.B. Server-Adresse:Server-Port:Raum-Name.

DTMF-TEXT meint die Tastenfolge bei der das Gateway eine Aktion ausführen soll. (z.B. *01#)

AKTION meint die Aktion, die das Gateway ausführen soll, wenn es die Tastenfolge empfängt. Hier gibt es 3 unterschiedliche Aktionen.

  • NET wechselt auf dem selben Server lediglich in den angegebenen Raum. (Bleibt aber auf dem Server)
  • CONN wechselt zu einem angegebenen Server in einen angegebenen Raum
  • EXEC führt ein Action-Skript aus

ATRIBUTE benennen den Server, Port und Raum oder das auszuführende Skript.

Im obigen Beispiel bewirkt also „*01#“, dass das Gateway wegen „NET“ in den Raum Berghütte, auf dem gleichen Server wechselt.

Durch „*11#“ verbindet sich das Gateway wegen „CONN“ mit dem Server www.1A-funkfeuer.de an Port 10024 auf Raum Test.

Und „#99#“ läßt das Gateway wegen „EXEC“ das Skript /opt/PiCQ/action/ftmf.sh ausführen.

Der Pfad „/opt/PiCQ/action/“ sollte einfach immer für die Action-Skripts genutzt werden, weil ihr auf diesen über die Samba-Freigabe zugreifen und bequem euer Skript dort hochladen könnt. (Siehe Samba)


DTMF Timeout

In der Praxis zeigt sich, dass es weniger von Vorteil ist einen einzelnen DTMF-Ton als Kommando zu programmieren (Stöhranfälligkeit). Vielmehr macht es Sinn ein Kommando als eine Kombination zu definieren (z.B. *10#). Nachdem der DTMF-Decoder nun einen Ton erkannt hat, wartet er eine definierte Zeit auf die folgenden Töne, die das Kommando vervollständigen. Das DTMF Timeout bestimmt nun die Zeit, die der Decoder wartet, bis er den Versuch verwirft.

Sounds

PiCQ kennt eine ganze Reihe von Tönen, die es zu gegebenem Anlass über HF aussendet. Rogerpiep, Quittungstöne, Fehlertöne u.s.w.. Um euch die Bearbeitung der Töne so einfach zu machen wie es eben nur geht, habe ich PiCQ dafür den Samba-Server spendiert. Er erstellt in eurem Netzwerk eine Windows-Freigabe in deren Ordner „sounds“ ihr die entsprechenden Töne ganz einfach speichern könnt. (Es ist sogar möglich mit einem Audio-Bearbeitungsprogramm direkt auf die Dateien in der Freigabe zuzugreifen.) Im Linux-Dateisystem eures Raspberry liegt dieser Ordner dann hier: „/opt/PiCQ/sounds/“.

Speicherpfad für Sounds

Wie bereits oben beschrieben gehören die Soundfiles also in den Ordner „/opt/PiCQ/sounds/“.

Rogerpiep (HF)

Diesen Ton bekommt ein Funker von eurem Gateway als Bestätigungston gesendet, wenn euer Gateway seinen Funkspruch erfolgreich an den FRN-Server weiterleiten konnte.

Als Standart wählte ich eot.wav. (end of transmission)

Rogerpiep (FRN)

Diesen Ton hängt euer Gateway an jeden Funkspruch an, den es vom FRN-Server an euren Funker per HF weitergesendet hat.

Als Standart wählte ich eot.wav. (end of transmission)

Fehlerton bei keiner Verbindung...

Dieser Ton wird an einen Funker per HF gesendet, wenn das Gateway seinen Funkspruch zwar empfangen hat, ihn jedoch nicht weiterleiten konnte, da es mit keinem Server verbunden ist.

Als Standart wählte ich error.wav. (Ein „Oh, ohhhh“ welches Ältere von Euch vielleicht noch vom ICQ-Messager her kennen)

Sound für zurückgewiesen

Dieser Ton wird von eurem Gateway an euren Funker per HF gesendet, wenn sein Funkspruch vom Server zurückgewiesen wurde. Dies kann mehrere Ursachen haben. Entweder euer Gateway wurde von einem Serveradmin gemuted (stumm geschaltet) oder aber es hat zum Zeitpunkt des Sendebeginns eures Funkers jemand anderes Über FRN gesprochen und er hätte so also „gedoppelt“ oder „stereo gedrückt“.

Als Standart wählte ich busy.wav. (Das „Besetzt“-Zeichen was wir vom Telefon her kennen, aus Zeiten in denen noch kein Schwachsinniger das „Anklopfen & Makeln“ erfunden hatte) ;-)

Sound für Fehler

Dieser Ton wird vom Gateway über HF gesendet wenn ein, nicht näher deklarierter, Fehler auftritt.

Als Standart wählte ich error.wav. (Ein „Oh, ohhhh“ welches Ältere von Euch vielleicht noch vom ICQ-Messager her kennen)

Rogerpiep bei leerem Raum

Diesen Ton sendet euer Gateway über HF aus, wenn es zwar einen Funkspruch von eurem Funker empfangen hat und auch mit einem Server verbunden ist, jedoch außer eurem Gateway niemand anderes im Raum ist, der es empfangen könnte.

Als Standart wählte ich roger.wav. (Ein ganz normales „Piep“)

Ankündigungston vor ...

Diesen Ton sendet euer Gateway (über HF) bevor es mit der Aussendung eines Funkspruches aus FRN beginnt.

Als Standart wählte ich bot.wav. (begin of transmission)

Hinweise: Die Töne für BOT und EOT haben eine Bewandniss. Es gibt einige Rauschsperre-Mechanissmen oder auch HF-Relais-Steuerungen, die mit solchen Tönen arbeiten um umzuschalten. Bei manchen PMR-Geräten kann z.B. eine DTMF-Tonfolge geschickt werden, damit die Squelch aufmacht, und nach dem Durchgang wird wieder eine Tonfolge gesendet, damit die Squelch wieder zu macht. Natürlich könnt ihr auch solche Töne hier entsprechend speichern.

Und noch etwas zu den von mir gewählten Tönen bot.wav und eot.wav: Ich entschied mich hier für die Quindar Töne. Diese Töne führte die NASA damals bei den Apolloflügen ein, um damit Relais-Stationen auf dem Boden schalten zu können. (Zitat aus Wikipedia: Der Startton hat 2.525 Hz und signalisiert das Drücken der PTT-Taste. Der Endton ist mit 2.475 Hz geringfügig tiefer und signalisiert das Freigeben der PTT-Taste.)

Hours

Hier könnt ihr eine automatische Zeitansage für euer Gateway definieren. Genau wie die Sounds können auch die Zeitansagen in der Freigabe „sounds“, jedoch in dem Unterordner „hours“ gespeichert werden.

Das Vorgehen ist vergleichbar mit dem des FRNClient.exe von Edwin.

Für später habe ich noch ein „externes Script“ vorgesehen, was Zeitansagen auf die Minute möglich macht. Dazu aber zu gegebener Zeit mehr.

Verzeichniss für Zeitansage

Hier wird der Ordner angegeben, in dem die Soundfiles für die Zeitansage liegen. Habt ihr diese mit der Freigabe hochgeladen, befinden sie sich in /opt/PiCQ/sounds/hours/.

Zeitansage einschalten

Hier könnt ihr festlegen ob euer Gateway die Zeit überhaupt ansagen soll

Intervall

Hier wird das Intervall angegeben, in welchem eine Ansage der Zeit erfolgt. Die Berechnung beginnt bei 0 Uhr. Möchtet ihr also zu jeder vollen Stunde die Uhrzeit ansagen lassen, so beträgt die Intervall-Zeit 60 Minuten.

Bedenkt, wenn ihr z.B. alle 30 Minuten eine Ansage machen möchtet, benötigt ihr auch die nötigen Soundfiles dazu. Diese werden dazu nach folgendem Muster, im 24h Format, benannt: hh_mm.wav. Also zum Beispiel für 20:30 Uhr muss das Soundfile 20_30.wav benannt werden.

Korrektur

Da ich das Image für den Betrieb in Mitteleuropa vorgesehen habe, ist es eben nötig die Zeitzone entsprechend zu korrigieren. Der Raspberry verfügt im Gegensatz zu einem normalen Rechner über keine eigene Uhr. Er entnimmt die aktuelle Zeit und Datum einem Zeitserver im Internet. Dadurch läuft die Uhr in PiCQ immer mit der deutschen Zeit, egal wo das Gateway auch gerade ist.

ExtEnabled

Hier kann ein externes Script aktiviert werden, welches die nötigen Soundfiles für die Zeitansage jeweils zum benötigten Zeitpunkt selbst erstellt (mit künstlicher Stimme) und nach der Durchsage später wieder löscht um Platz zu sparen. Dieses habe ich jedoch derzeit noch nicht integriert.

ExtScript

Hier wird der Name des externen Skriptes eingegeben, sobald es verfügbar ist.

ExtScriptDir

Hier wird der Pfad des externen Skriptes angegeben, sobald es verfügbar ist.

ExtTempDir

Bestimmt den Pfad, in dem das Skript die vorübergehenden Soundfiles zum Abspielen ablegt und nach Abspielen wieder löscht. (Auch erst notwendig, sobald verfügbar)

Informer

Hier habt ihr die Möglichkeit Ansagen zu platzieren, die von Zeit zu Zeit ausgesendet werden, um die QRG auf dem Kanal über euer Gateway zu informieren. Hier könnt ihr zum Beispiel auch mitteilen welchen CTCSS-Ton ein Funker verwenden muss, um über euer Gateway sprechen zu können, u.s.w.

Die Netzagentur schreibt beim Betrieb eines unbemannten CB-Gateways zum Beispiel die Nennung der KENNUNG die eurem Gateway bei seiner Anmeldung zugewiesen wurde, alle 10 Minuten. Glücklicherweise wird dort kein Wort verloren auf welche Art und Weise dies zu geschehen hat. Also könnt ihr euch nun selbst überlegen ob ihr alle 10 Minuten einen halben Roman per Sprache ansagen lasst, die Kennung eben per flotten Morsecode durchheizt oder eben auch per AFSK Nachricht in unter einer Sekunde. Oder ob ihr es auch gleich bleiben lasst ;-)

Informer einschalten

Ich glaube das erklährt sich von selbst, oder?

Dir

Das Verzeichnis in dem die Soundfiles für den Informer liegen. Wenn ihr sie mit der Freigabe hochgeladen habt, liegen sie bei den Sounds im Unterordner Informer. Also bei /opt/PiCQ/sounds/informer.

Intervall

Die Zeitspanne in Sekunden in der eine Ansage erfolgt. (Beispiel für Rechenkünstler 15 Minuten sind 900 Sekunden)

Modus

Es gibt 2 Wiedergabe-Modi. Sequenz (die Files werden der Reihe nach wiedergegeben wie sie im Ordner liegen) und Zufällig (es wird per Zufall ein Soundfile ausgewählt, welches in dem Ordner liegt.)

SilenceEnabled

Manchmal macht es Sinn, das Intervall zu ändern, wenn gerade Betrieb auf dem Gateway ist, und wenn wieder Stille herrscht. Daher kann das Gateway die Stille erkennen und dann eben ein anderes Intervall nutzen.

SilenceIntervall

Hier wird nun also die Intervall-Zeit eingestellt, in welcher das Gateway die Infos sendet, wenn Stille herrscht.

SileceTime

Hier wird die Zeitspanne angegeben, in der kein Betrieb stattgefunden haben soll, bis das Gateway es als Stille erkennt.

ExtEnabled

Ich arbeite zu einem späteren Zeitpunkt ein Skript aus, welches die Ansage auch durch eine Text2Speach-Engine selbst generieren kann. Oder aber die Ansage selbst als Morsecode oder AFSK Nachricht erstellen kann. Wenn es soweit ist, kann dies hier ein- oder ausgeschaltet werden.

ExtScript

Der Dateiname den das Skript dann haben wird.

ExtDir

Der Datei-Pfad in dem das Skript dann liegen wird.

ExtTempDir

Der Datei-Pfad in den das Skript das auszusendende Soundfile vorübergehend ablegt, bis es gesendet wurde und anschließend aus Platzgründen wieder löscht.

LCD-Display

Hier kann ausgewählt werden ob ein LCD-Display am I2C-Bus angeschlossen ist und benutzt werden soll.





Navigation




Drucken/exportieren
Werkzeuge
QR-Code
QR-Code web-ui:gate (erstellt für aktuelle Seite)