Konfiguration
Die Konfiguration des monitord geschieht ausschließlich über eine Konfigurationsdatei namens "monitord.xml", die im Programmverzeichnis liegen sollte. Zur Vorverarbeitung von Daten können LUA-Skripte genutzt werden, dazu mehr in einem späteren Kapitel.
Allgemeiner Aufbau der monitord.xml
Die Konfigurationsdatei beginnt mit einem allgemeinen Block. Hier sind die XML-Strukturangaben, der Name des monitord-Servers, Ort und Name des Logfiles des Hauptprogramms, der Loglevel und die Lage zweier Filterskripte definiert. Ausführlich werden die Angaben in weiteren Kapiteln erläutert.
<?xml version="1.0" encoding="ISO-8859-1"?> <monitordconfig version="1.0"> <name> Monitord </name> <logfile> monitord.log </logfile> <!-- screen = Bildschirm --> <loglevel> INFO </loglevel> <SocketFilterScript> socketfilter.lua </SocketFilterScript> <PluginFilterScript> pluginfilter.lua </PluginFilterScript> (... auth, tcpsocket, soundcard, dataplugins ...) </monitordconfig>
Die Einstellungen zum Thema Authentifizierung (auth), dem Serververhalten und den Auswertungen und Speicherorten in dieser Datei sind speziellerer Natur. Daher sind ihnen eigene Unterkapitel gewidmet, als Platzhalter für diese Blöcke seien die (...) oben zu erkennen.
Logfile und Loglevel
logfile und loglevel sind zwei Tags, die auch bei den Plugins verwendung finden. Sie regeln die Ausgabe von Informationen durch den Auswerter und die Plugins. Da der monitord als Dienst konzipiert ist, schreibt dieser seine Ausgaben in der Regel eher in ein Logfile als sie am Bildschirm auszugeben. Auch das ist durch Angabe von "screen" jedoch möglich. Das Loglevel kann enthalten DEBUG, ERROR und INFO, wobei DEBUG sehr viele Ausgaben generiert und diese Einstellung nicht für den Dauereinsatz empfohlen ist.
Einzelne Abschnitte der monitord.xml
<auth>-Sektion
Die Auth-Sektion definiert, welche Clients welchen Zugriff auf die Sockets haben. Die Zugriffssteuerung geschieht entweder nach IP-Adressen oder durch Angabe von Benutzername und Kennwort. Pro Benutzer muss eine "login"-Sektion eingetragen werden. Mittels "deny" können Hosts auch generell ausgeschlossen werden.
<auth> <login> <name>test</name> <password>test</password> </login> <login> <name>crusader</name> <password>pw</password> </login> <!-- Bisher nur IP Adressen. Keine Netze oder Bereiche ! --> <!-- Mehrfachnennungen sind aber moeglich, sofern sie Sinn machen --> <!-- Suchreihenfolge: allow, login, deny --> <ip action=allow>192.168.0.1</ip> <!-- Diese IPs muessen sich nicht einloggen --> <ip action=allow>127.0.0.1</ip> <!-- Diese IPs muessen sich nicht einloggen --> <ip action=login> any </ip> <!-- Diese IPs muessen sich einloggen --> <ip action=deny> any </ip> <!-- Diese IPs koennen sich nicht einloggen --> </auth>
<tcpsocket>-Sektion
Hier wird definiert, auf welchem Netzwerk-Interface bzw. welcher IP-Adresse der monitord erreichbar sein soll ("bind"). Die Port-Angaben stellen den TCP-Port dar, der Parameter "mode" definiert das auszugebende Format. Wie bereits in der Feature-Liste erwähnt, kann der monitord als Funkauswerter an bestehende Programme wie den FMS Crusader oder FMS32/FMS32 PRO gehängt werden. Das monitord-Protokoll ist im Bereich "Ressourcen" zum Download verlinkt.
<tcpsocket> <bind> * </bind> <port mode="monitord"> 9333 </port> <port mode="fms32pro"> 9300 </port> <port mode="crusader"> 7778 </port> </tcpsocket>
<soundcard>-Sektion
Für jede im PC vorhandene Soundkarte wird eine "soundcard"-Sektion angegeben. In ihr werden die unten stehenden Angaben gemacht und sie damit für den Betrieb der eigentlichen Auswerter vorbereitet; die Platzhalter "(... Auswerter-Module rechter/linker Kanal ...)" werden im Anschluss erläutert. Sowohl die Soundkarte als auch die Kanäle enthalten ein "Name"-Attribut.
<soundcard num=0> <device>/dev/dsp0</device> <!-- das /dev/dsp0 meint die erste Soundkarte --> <status>1</status> <!-- 1=aktiv, 0=deaktivert --> <baud>22050</baud> <name> Erste Sondkarte </name> <channel part="left"> <name>Kanal 0</name> (... Auswerter-Module linker Kanal ...) </channel> <channel part="right"> <name>Kanal 1</name> (... Auswerter-Module rechter Kanal ...) </channel> </soundcard>
(Auswerter-)Module im CHANNEL-Block
Die Module verrichten die eigentliche Arbeit. Entsprechend wird ihnen hier jeweils eine einzelne Erklärung gewidmet. Jedes Modul kann, muss aber nicht, pro Kanal aktiviert werden.
ZVEI
<module type="zvei"> <squelch> 25 </squelch> <debugmodus> 0 </debugmodus> </module>
Durch diese Angabe im Platzhalter "(... Auswerter-Module rechter/linker Kanal ...)" der Soundcard-Sektion wird es für den jeweiligen Kanal aktiviert. Der Parameter 'Squelch' ist eine Art Rauschsperre (0-100), der 'Debugmodus' ist hilfreich bei Problemen - interessante numerische Angaben sind hier 3, 6 und 10, wobei 10 sehr viele Ausgaben auch aus den Tiefen des Auswerters bewirkt und keinesfalls für den Dauereinsatz zu empfehlen ist.
FMS
<module type="fms"> <algorithmus> 1 </algorithmus> <syncbits> 12 </syncbits> <crc-check> 1 </crc-check> <maxerrors> 3 </maxerrors> </module>
Diesem Modul können verschiedene Parameter mitgegeben werden, die die Auswertung beeinflussen. In der Regel sind "crc-check" und "maxerrors" entscheidend, um fehlertolerant auszuwerten. maxerrors beschreibt dabei die maximale Anzahl von Decodierfehlern innerhalb eines Telegramms, ab denen es verworfen werden soll, der crc-check (0/1) wird (de-)aktiviert, um eine Checksumme über das Telegramm zu berechnen. Das Feld Algorithmus kann 0 oder 1 enthalten; 0 ist ein alter Algorithmus, 1 ein neu implementierter mit im Test deutlich besseren Ergebnissen.
POCSAG
POCSAG ist in zwei Varianten implementiert: 512 und 1200 Baud. Hier exemplarisch die Konfiguration für die 1200-Baud-Variante:
<module type="poc1200"> <algorithm> 1 </algorithm> <crc-check> 1 </crc-check> <ecc> 0 </ecc> <maxerrors> 3 </maxerrors> </module>
Diesem Modul können verschiedene Parameter mitgegeben werden, die die Auswertung beeinflussen. Zur Beschreibung siehe die Angaben für den FMS-Auswerter.