===== 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.// {{ :web-ui:einstellungen.png?400 |}} ===== 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. [[http://www.1a-funkfeuer.com|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. (//In der Regel bestimmt der Admin des Hauptserver auch den Backupserver. Dieser wird dann beim ersten richtigen Connect mit dem Hauptserver an PiCQ übertragen.//) 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. __**Neu, ab Version 1.4**__ gibt es hier die Option "Eigenen erzwingen". Dadurch ist es möglich selbst einen Backupserver zu benennen, auch wenn der Hauptserver eigentlich einen anderen vorgibt. Befindet sich PiCQ im Modus "Lokaler Offlinebetrieb" stellt PiCQ ja selbst einen lokalen Server. Durch die Option "Eigenen erzwingen" ist es nun auch möglich PiCQ automatisch auf diesen (//"localhost"//) umzuleiten. So arbeitet PiCQ dann ganz normal als FRN-Gateway und im Falle eines Ausfalls der Internetverbindung eben als Repeater oder Offline-Gateway weiter. ==== 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. (**[[einfuehrung:starthilfe#accounts_anlegen|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. **[[einfuehrung:starthilfe#accounts_anlegen|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. **[[einfuehrung:starthilfe#accounts_anlegen|Hinweise dazu]]**))// ==== Ort/Ortsteil ==== Der Name des Ortes, in dem dein Gateway steht. //(s. **[[einfuehrung:starthilfe#accounts_anlegen|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//) ==== CBAPRS ==== Für Informationen zu diesen Feldern bitte [[web-ui:aprs|HIER]] klicken. Für eine bessere Übersicht, habe ich mich entschlossen dazu eine eigene Seite zu erstellen. ===== Audio ===== ==== Eingangs Gerät ==== **__Egal was hier bereits eingetragen ist, hier tragt ihr bitte selbst die Soundkarte ein, welche PiCQ in euerem System findet!__** Auf der dem Menü gegenüber liegenden Bildschirmhälfte befindet sich ein Kästchen in dem PiCQ auflistet welche Audiogeräte es gefunden hat. Je nach Anzahl der bei euch verwendeten Soundkarten (1 oder 2) tauchen unter "**AUDIO INPUT DEVICES**" 1 oder 2 Zeilen auf, an deren Ende in Klammern "**hw:0,0**" oder "**hw:1,0**" steht. //Linux beginnt bei seiner Nummerierung von Dingen immer mit der Null.// {{:web-ui:soundkarte_auswählen.png?400|}} Markiert nun diese Zeile (//bei 2 Soundkarten eben eine dieser beiden//) mit der Maus, klickt mit der **rechten Maustaste** darauf und wählt "**kopieren**". Anschließend klickt ihr im Menü in das Feld "Eingangsgerät" (//ebenfalls mit der rechten Maustaste//) und wählt "**einfügen**". //Ihr könnt das Ganze natürlich auch abtippen, jedoch muss Buchstabe für Buchstabe, Leerzeichen für Leerzeichen und Groß- & Kleinschreibung überein stimmen. // __**Hinweis:**__ In dem Kästchen wird bei "AUDIO INPUT DEVICES" nur eine Soundkarte angezeigt, die nicht gerade aktiv von einem Gateway verwendet wird. Das bedeutet: Wenn das Gateway läuft und die Soundkarte nutzt, wird diese bei "AUDIO INPUT DEVICES" **NICHT** mehr angezeigt, jedoch immer bei "Output Devices". Wie man in meinem Beispiel sehen kann, läuft Gateway 1 und bei "AUDIO INPUT DEVICES" wird also die Karte "...HW:0,1" nicht angezeigt. Gateway 2 ist gerade deaktiviert (//Icon ist grau//), daher wird Soundkarte "...HW:1,0" auch angezeigt. ====Samplerate==== Hier wird eingetragen mit welcher Samplerate eure Soundkarte angesprochen wird. Jedoch lässt sich hier jedoch kein genauer Wert von mir voraussagen. Im Idealfall würde man hier 8000 eintragen, weil dann PiCQ die Samplerate für FRN nicht extra umwandeln müste. -Dies kann jedoch kaum eine USB-Soundkarte. Versucht es einmal mit **48000**. In manchen Fällen (ganz alte Karten) kann man auch einmal 44100 versuchen. ====Qualität==== Wie zuvor bereits beschrieben, wandelt PiCQ die Samplerate von der tatsächlichen (für die Soundkarte eingestellten) in die von FRN verlangte Samplerate von 8000 um. Hier kann nun angegeben werden, in welcher Qualität dies geschieht. Ein Raspberry Pi2 sollte schon mit "**H**" für High klarkommen. Bei einem Raspberry Pi1 oder dem Zero würde ich es aber bei "**M**" für Middle belassen. Und wenn ihr den Pi1 oder Zero gleich mit 2 Gateways belastet, würde ich sogar auf "**L**" für Low heruntergehen. ====Faktor==== ====Voraufnahme- Time==== Diese Zeit bestimmt die Größe eines kleinen Puffers. PiCQ benötigt ja etwas Zeit (//bei VOX- Betrieb zB. um den Signalpegel auszuwerten und darauf zu reagieren, oder aber das COS- Signal auszuwerten und darauf zu reagieren//). Daher wird das Audiosignal also in diesen Puffer geladen, um diese Zeit einzuräumen. Ist diese zu klein gewählt kann es vorkommen, dass bei einem Durchgang der Anfang des Satzes verschluckt wird. -Jedoch sollte man ihn auch nicht zu groß wählen, sonst wird das Gateway zu träge und langsam. Ich habe hier für mich einen Wert von **500** ms als praktisch ermittelt. ====(HpF) einschalten==== HpF steht für "High pass Filter". Mit ihm werden unerwünschte Brummlaute unterdrückt. ====(HpF) Order==== Die Order bestimmt die Flankensteilheit des Filters. Ein Wert von **5** hat sich bei mir als günstig herausgestellt. ==== (HpF) doppelt anwenden==== Wird dies mit Ja beantwortet, soll die Wirkung verdoppelt werden. (//hmm, naja//) ====(AGC) einschalten==== AGC steht für "Automatic Gain Control". Dies soll dafür sorgen, dass unterschiedlich laute Stationen doch recht gleich Laut über euer Gateway übertragen werden. Diese Funktion bewirkt bei manchen Konfigurationen jedoch ein starkes "Pumpen" der Lautstärke. (Besonders in Wechselwirkung mit der, in der Soundkarte eingebauten AGC (//siehe Mixer//).) ====(AGC) Niveau==== Das ist ein Prozetwert zu einem theoretisch ideal ausgepegelten Signal. (//Sagen wir einmal 0db.//) Jedoch auch wenn ich Prozentwert geschrieben habe, sollte dies nicht über **99** gestellt werden. ====(AGC) maximale Verstärkung==== Die AGC ist also stets bemüht den angegebenen Prozentwert von 0 db zu erreichen. Nun macht es jedoch nicht unbedingt Sinn ein zu leises Signal unendlich zu verstärken um unbedingt auf einen Pegel von 0 db zu kommen. Dann währe es zwar schön laut, jedoch total verzerrt. -Daher kann man hier eine maximale Verstärkung eintragen, welche die AGC beim Versuch anwenden darf an die 0 db zu kommen. ====Ausgabe Gerät==== Alle Beschreibungen //siehe Eingangs Gerät//. ===== 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)// * **GPIO:6:gpio6:NORMAL** //(Bei Gateway3 wenn die PTT an den Schließerkontakt des Relais angeschlossen ist (empfohlen)// * **GPIO:6:gpio6:INVERTED** //(Bei Gateway3 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. // Das Level der VOX steht in direktem Zusammenhang mit der Lautstärke eures Funkgerätes und der im "MIXER" eingestellten Lautstärke des entsprechenden Einganges ([[web-ui:mixer|Mic/Line Capture]]). -Wenn ihr z.B. nun andauernd "Empfange über HF" in der RX-Zeile stehen habt, so solltet ihr den Wert für Vox immer mal wieder um 100 erhöhen (//und auf "Speichern" klicken//), bis in der RX-Zeile wieder "QRV" steht. -Wenn ihr später einmal an den Einstellungen für diesen Eingang im MIXER, oder aber die Lautstärke eures Funkgerätes ändert, denkt bitte daran auch das Level für die VOX anzupassen. ==== 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. **;;** {{ :web-ui:dtmf.png?600 |}} 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 [[einfuehrung:starthilfe#samba|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. ===== Ansage Server-/Raumname ===== Damit PiCQ bei verschiedenen Servern oder Räumen jeweils eine entsprechende Ansage machen kann, müssen natürlich dafür einzelne Ansagetexte aufgenommen und eingespielt werden. Der Speicherort dafür ist die Freigabe "Net". Neben den einzelnen .WAV Dateien befindet sich auch die "connsound.cfg" Datei, welche die Verwendung steuert. //Auch wenn diese -.cfg Datei ein wenig umständlich erscheint, halte ich dies für eine ausgezeichnete und sehr gute Idee von Vallery. Dadurch müssen diese Dateien jetzt nicht mehr zwangsläufig so heißen, wie der Raum/Server den sie ansagen. Dies ist bei Räumen mit Leerzeichen im Namen von Vorteil, aber auch wenn man eine Datei mehrfach für verschiedene Server nutzen möchte.// In der mitgelieferten connsound.cfg weise ich auf die Schreibweise der Einträge hin. Meine Grundkonfiguration wurde so gewählt, dass sie quasi für jeden Einsatzfall auch ein Beispiel darstellt. Wichtig ist an dieser Stelle, dass ihr einen Linux konformen Texteditor dafür verwendet. Näheres dazu und einen Download-Link findet ihr unter [[einfuehrung:download|PiCQ Download]] unter "**Text Editoren**". Grundsätzlich, kann man festhalten, ist eine Zeile folgend aufgebaut: ''server | port | network | sound_file_name.wav'' * **server** -Hier tragt ihr die Adresse des Server ein. (//Bsp.: 1a-funkfeuer.de//) * **port** -Hier tragt ihr den Port ein, unter dem der Server zu erreichen ist. (//Bsp.: 10024//) * **network** -Hier wird der Raum eingetragen, für den die Ansage erfolgen soll. (//Bsp.: Berghütte//) Es ist auf Groß- /Kleinschreibung zu achten. Als "Joker" oder "Wildcard" lässt man einen Parameter einfach unbesetzt. Beispiele: ''||Test|/opt/PiCQ/net/AnsageTest.wav'' Server und Port wurden hierbei leer gelassen, aber network wurde mit "Test" definiert. Also spielt PiCQ bei jedem "Test" Raum (//egal welcher Server, egal welcher Raum//) die Ansage "/opt/PiCQ/net/AnsageTest.wav" ab. ''1a-funkfeuer.de||Berghütte|/opt/PiCQ/net/AnsageBerghütte.wav'' Der Port wurden hierbei leer gelassen, aber server wurde mit "1a-funkfeuer.de" und network wurde mit "Berghütte" definiert. Also spielt PiCQ beim Server "1a-funkfeuer" und Raum "Berghütte" (//egal welcher Port//) die Ansage "/opt/PiCQ/net/AnsageBerghütte.wav" ab. Und so weiter.