→ Arbeiten an einer Version für Raspberry Pi4 begonnen ←→ Work on a version for Raspberry Pi4 started ←

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. (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. (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)

CBAPRS

Für Informationen zu diesen Feldern bitte 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.

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 (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.

<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.

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 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.

Cookies helfen bei der Bereitstellung von Inhalten. Diese Website verwendet Cookies. Mit der Nutzung der Website erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Computer gespeichert werden. Außerdem bestätigen Sie, dass Sie unsere Datenschutzerklärung gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information




Navigation






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