monitor 1.9.0 - aber richtig :)

OK: Ich habe jetzt folgendes unter Ubuntu 7.10 32-Bit gemacht:

Zitat:

---

sudo aptitude install build-essential
sudo aptitude install tofrodos
chmod +x configure config.sub install-sh config.guess
dos2unix config.sub
dos2unix config.guess
./configure

---

Das bringt mich zumindest schon mal bis hier:

Zitat:

---

checking if PIC flag -fPIC works... no
checking if supports -c -o file.o... no
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... ./configure: line 14490: -print-search-dirs: command not found
GNU/Linux ld.so
checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.1... not present.
checking for snd_ctl_open in -lasound... no
configure: creating ./config.status
.infig.status: error: cannot find input file:

---

Was geht hier schief?

Andreas

Hallo,

ich habe gleich mal ins SVN geschaut eben und schonmal eine sehr angenehme und nachvollziehbare Ordnung gefunden :). Toll, danke!

Ich möchte Dich, Buebchen, aber noch bitten, den /tags/1.9.0 zu einem /branches/1.9.0 zu verschieben, da die Tags (rein interpretativ) als "Kennzeichnungspunkte" (in der Regel in Bezug auf /trunk) verstehbar sind und die 1.9-er ja nicht mehr im /trunk entwickelt wird (und an sich auch nie wurde). Im /branches könnte (so jemand wollte) dann auch noch an der 1.9er geschraubt werden (in /tags sollte ja grundsätzlich eher nicht entwickelt werden, wenngleich es dem SVN prinzipiell egal ist, wo was liegt - die Bedeutung interpretiert der Mensch ja hinein).

Außerdem wäre in meinen Augen gleich ein Tag /tags/2.0-301107 gut, um lauffähige Versionen nach größeren Änderungen der aktuellen Entwicklung zu markieren. Der jetzte Stand in /trunk ist (jedenfalls war er es gestern noch ;)) lauffähig und kann daher meiner Meinung nach gut entsprechend als "offizieller Anfang der 2.0" markiert werden. Gut, die Probleme, die nepomuck hier schildert, sollten wir vielleicht vorher noch im Griff haben.

Danke für die Mühe :)!
Martin

Hallo,

Zitat:

---

Zitat von Buebchen

Ich kenne SQLite nicht. Aber ich suche noch eine effektive Methode um die Nachrichten vom Decoder zu den Socketthreads zu queuen oder spoolen. Könnte man nicht sogar eine SQListe-DB (oder mehrere) nehmen ?

---

ja, das könnte man.
SQLite ist eine SQL-Datenbank auf Dateibasis (ein File - eine Datenbank), die mit dem Dateinamen ":memory:" auch rein im Speicher (entprechend flüchtig) Daten halten kann. Das ist allerdings in dem Fall glaube ich nicht so praktisch, da der gesamte Datenbank-Overhead dazu käme, was hier ja nicht nötig wäre.
Wenn aber die Geschichte mit den *msg-Objekten realisiert wird - dann könnte doch einfach eine Datenstruktur (Array, verkettete Liste, ...) die *msg-Objekte pro Thread halten (hält der Thread selber oder soll das gebündelt vor der Übergabe an die Threads passieren?).

Änderung I:
Ich habe mal das anhängende Bild gemalt... ZVEImsg, POCmsg und FMSmsg sind abgeleitet von BASEmsg. Die Display- und Storage-Master sind quasi die Manager der Ausgabe-Module (sprich sie halten eine Liste der bestehenden Display/Storage-Module und geben die eingehenden Nachrichten *msg an die einzelnen Module weiter, können die auflaufenden Nachrichten aber auch queuen, falls bei den Modulen ein Problem auftritt - pro Modul wäre da eine Queue sinnvoll, damit bei fehlerhaftem Verhalten eines Moduls die anderen noch sauber weiterarbeiten können). Ich würde dann bevorzugen, pro Modul eine eigene Ausgabe-Routine pro *msg-Subtyp einzusetzen, damit erst im spezifischen Modul die Ausgabe-Formatierung geschehen muss. Die hier als einzelne Manager gezeichneten "Dinger" könnten auch zu einem Manager zusammengefasst werden, ebenfalls könnte der Manager eine Queue für eingehende *msg haben und die Ausgabemodule bei Bedarf eine eigene Queue halten (das wäre beim HTTP-Push nicht schlecht, weil Antwortzeiten zu berücksichtigen sind, beim monitor-Socket ist das wiederum nicht so wichtig, weil hier keine Zeitgeschichten/Feedbacks zu berücksichtigen sind).

Änderung II:
Mir fiel beim Einkaufen ein, dass genau im Manager (als dem "Sammler" für *msg-Objekte) auch die History-Geschichte (dann gerne in Form einer SQLite-Datenbank im Speicher oder in einer Datei) zu implementieren sinnvoll wäre, das nur als Ergänzung dazu.

Martin

Zitat:

---

Zitat von mdi

Hallo,

Wenn aber die Geschichte mit den *msg-Objekten realisiert wird - dann könnte doch einfach eine Datenstruktur (Array, verkettete Liste, ...) die *msg-Objekte pro Thread halten (hält der Thread selber oder soll das gebündelt vor der Übergabe an die Threads passieren?).

---

Im Moment sind es getrennte Listen (std::list) pro Thread. Geht auch soweit. Ich würde sie dann ggf. nur denmächst mal in eine Klasse einbetten, da ich immer auch über eine Semaphore sicherstellen muss, da immer nur ein Prozeß die Liste ändert. Nach meiner Meinung müssen die Objekte pro Thread in eine eigene (private) Queue. Sonst könnte ich erst das Element aus der zentralen Queue entfernen, wenn alle Threads es abgearbeitet habe (was dann synchronisiert werden müßte).

Zitat:

---

Zitat von mdi

Änderung I:
..., können die auflaufenden Nachrichten aber auch queuen, falls bei den Modulen ein Problem auftritt - pro Modul wäre da eine Queue sinnvoll, damit bei fehlerhaftem Verhalten eines Moduls die anderen noch sauber weiterarbeiten können ...

Martin

---

So in der Art würde ich mir das auch vorstellen können. Dann sollten wir einen Dispatcher als Dreh- und Angelpunkt für die Nachrichten vorsehen. Dieser bedient dann bei ihm registrierte Module (Füllt deren privaten Queues - ggf aber nur bis zu einem Limit von vielleicht 100 Einträge). Ich wüßte im Moment nur nicht, warum ich für Display und Storage verschiedene Dispatcher brauche. Die Daten sind identisch - nur die spätere Verarbeitung nicht. Wenn jedes Modul - wie es schon beim SocketThread ist - seine eigene Queue könnte man die StorageModule genauso behandeln.

Ich habe nun begonnen, noch einen Dispatcher für die Nachrichten der Auswerter zu schreiben.

Vom Ablauf stelle ich mir es dann so vor:

1. Modul meldet Daten in einem einheitlichen Format (z.B. std::map) an Dispatcher (z.B. FMS Auswertung)
2. Dispatcher (eigener Thread, Auswerter läuft also ohne Unterbrechnung weiter) verteilt Daten an SocketServer und Plugins (Jeweils eigene Threads)
3. SocketServer und Plugins erstellen dann für sich die passenden Strings, die dann weiter verarbeitet werden (SocketServer an die einzelnen SocketThreads)

Hallo,

ich habe immernoch ein Problem mir vorzustellen, was und warum genau mit dem <std::map> gearbeitet werden soll :7.

Die Sache mit den Datenobjekten finde ich da einfacher, weil (wie geschrieben) dann eine Oberklasse BASEmsg ausreicht, um egal welche Daten überall im Kern durchzuschieben ohne sich um die innere Struktur kümmern zu müssen (braucht da ja auch niemand).

Vielleicht könnte man es dann auch sinnvoll implementieren, dass diese Daten-Objekte ihre eigene "getFMSProData", "getmonitordData", "getCrusaderData"-Routine mitbringen, so dass die Aufbereitung der Daten für die verschiedenen Ausgabeformate der Kernfunktionalität des monitord prinzipiell dem Autor der jeweiligen Auswerter- bzw. Datenobjekt-Klassen obliegt aber frei anpassbar ist für kommende Entwicklungen ohne dass die Ausgabe-Klassen extra angefasst werden müssen (die bekommen dann ein Datenobjekt BASEmsg bzw. dessen Ableitung in z.B. FMSmsg, und fordern es auf, seine Daten selber sinnvoll auszugeben bzw. sie sinnvoll formatiert als String an das Ausgabemodul zurückzugeben).

Hm... ja. So weit.
Martin

Zitat:

---

Zitat von mdi

Hallo,

ich habe immernoch ein Problem mir vorzustellen, was und warum genau mit dem <std::map> gearbeitet werden soll :7.

Die Sache mit den Datenobjekten finde ich da einfacher, weil (wie geschrieben) dann eine Oberklasse BASEmsg ausreicht, um egal welche Daten überall im Kern durchzuschieben ohne sich um die innere Struktur kümmern zu müssen (braucht da ja auch niemand).
Martin

---

Ich glaube, die abgeleiteten Klassen mit klassischen Membervariablen finde ich in sofern unflexibel, daß jedes neue Feld dann im Source-Code hinzugefügt werden muss, bevor man es verwenden kann. Eine dynamische Struktur wie die map hat hat so ein Problem nicht. Dennoch kann man die map ja in eine Klasse packen, die den Zugriff auf die Daten nochmal kapselt und überwachen kann. Hin- und herschieben kann man so eine Klasse auch ganz prima :-)

Wenn man irgendwann beschließt aus einem optionalen Backend (z.B. Datenbank) ein Feld "Fahrzeugname" in den Datensatz einzufügen wäre das möglich (Durch ein "PreDispatcher" Plugin könnten die Daten ergänzt werden.) Und das ohne, die Klassendefinition anpassen zu müssen. Gleiches gilt dann für ein vorhandenes StorageModul. Es kann die ergänzten Daten lesen und nutzen, wenn es sie abfragt. Und das alles ohne SourceCode Änderung. Und andere Module sind davon unbeeindruckt.

Da fallen mir einige Möglichkeiten ein, um den monitord an ganz verschiedene Bedürfnisse anzupassen. Ich z.B. fände es toll, wenn ein Fahrzeugname schon vor dem Weiterleiten an die Clients ergänzt wird. Oder z.B. auch der POCSAG-Text der letzten Alarmierung. Oder der vorherige Status (wenn es ein FMS Protokoll ist)...

Sagen wir also mal, daß ich denke die map ist kein Erschwernis (sofern man damit leben kann, daß alle Daten als String behandelt werden) sondern eine Option für die Zukunft :-)

Kurze Bitte:

Könnte einer von euch mal prüfen, warum bei mir nicht einmal das configure-Skript durchläuft? Ohne das kein make und ohne Make kann ich aktuell gar nichts testen.

Andreas

2 Fragen dazu:

1. Du hast das aktuelle SVN (jetzt aus dem trunk Pfad) ?
2. Existiert da eine config.h.in ? Diese scheint zu fehlen. Ist aber im Repository vorhanden

Andere möglichkeit wäre mal mit dos2unix config.sub zu bearbeiten. Sieht nach nem Fehler mir [cr] und [cr][lf] aus (das .infig.status macht irgendwie keinen Sinn).

Hallo,

Zitat:

---

Zitat von Buebchen

Sagen wir also mal, daß ich denke die map ist kein Erschwernis (sofern man damit leben kann, daß alle Daten als String behandelt werden) sondern eine Option für die Zukunft :-)

---

ja, da muss ich Dir (nachdem ich endlich verstanden habe, wozu die da sein soll - ich habe da total auf dem Schlauch gestanden) zustimmen, das ist sehr flexibel für mögliche Module, die die von Dir angebrachten Änderungen (Mapping Nummern->Namen, wie auch immer) durchführen. Das würde allerdings bedingen, dass wir drei verschiedene Arten von Modulen haben - Decoder, verarbeitende Module vor der Verteilung an die Ausgabemodule und eben diese Ausgabemodule, richtig?

Da möchte ich doch noch die Frage in den Raum werfen, ob eine derartige Datenzusammenführung nicht clientseitig oder durch eine Datenbank besser aufgehoben wäre.

@nepomuck:
Die Sirenentonerkennung sollte jetzt für alle möglichen Alarme funktionieren, allerdings werden alle zur Zeit noch als Typ 2 deklariert, wodurch der Subtyp nur im Klartext der Message erscheint (Sirenenauslösung: [Probe|Feuer|...]).

Martin

Zitat:

---

Zitat von Buebchen

1. Du hast das aktuelle SVN (jetzt aus dem trunk Pfad) ?

---

Ja. Über Rapidsvn ausgecheckt und unter monitor/trunk den configure gestartet.

Zitat:

---

Zitat von Buebchen

2. Existiert da eine config.h.in ? Diese scheint zu fehlen. Ist aber im Repository vorhanden

---

Die Datei ist da. Ich habe so gut wie alle Dateien im trunk-Pfad auf cr-lf untersucht und mit dos2unix bearbeitet. Zudem habe ich alle executables mit +x geflagged.

Es funktioniert nach wie vor nicht.

Andreas

Wer hat denn in diesem Forum "Häuptlingsrechte"?

Ich würde gerne mein Draft zur Protokollversion 0.2 posten, aber das PDF hat 130KB und ich darf nur 100 KB anhängen.

Kann mir jemand bitte erlauben, 140 KB zu posten?

Danke,
Andreas

Ich habe hier zwar "Häuptlingsrechte" (Moderator) aber ich darf auch nur 100 KB hochladen.

Versuche doch mal die Datei zu packen. (ZIP,RAR, etc)
Oder du versuchst das mit einem "One-Klick-Hoster" (z.B. Rapidshare oder simpleupload) und postest dann den Link hier.

Hallo Zusammen,

Ich habe das bestehende Protokoll etwas erweitert und ein paar kleine Änderungen daran vorgenommen. Das Draft sieht Befehle vor, über die Client und Server ein paar wichtige Konfigurationsdaten austauschen können.
Zudem habe ich Kommandos für den Mitschnitt eingebaut.

Bitte seht euch das Draft an und schickt mir eventuelle Erweiterungen oder Änderungen.
Da das PDF für das Forum zu fett ist :-) habe ich es auf meinem FTP-Server hinterlegt.

ftp://andi.rw-labs.de/pub/monitor-protokoll-02.pdf

Andreas

Die Kommandoliste macht einen guten Eindruck.

Ich würde für die unterstützen Protokolltypen auch eine Liste als Antwort vorsehen. Dann kann der Server die unterstützen Protokolle anbieten und der Client nimmt das für ihn passende. Alternativ könnte/müßte man voraussetzen, daß das Protokoll immer abwärtskompatibel ist (Wenn ein Server Version 2.1 kann muss er auch 1.x bis 2.0 können).

Den Servernamen hatte ich vorgesehen, wenn man mal später eine Relay-Funktion vorsehen würde: Das Relay verbindet sich zu drei Servern. Der Client nur zum Relay. Dann wäre die Info futsch, welcher Server es war (ok, im Moment eher nicht nötig).

SVN Update (trunk, Rev. 205):

Ausgabezeilen für angeschlossene Clients werden nun im SocketThread erstellt.
Die Auswerter geben nun eine Resultset mit einer map<string> zurück als Ergebnisliste.

Der Zugriff auf die globale Nachrichtenkette ist in in einem Dispatcher-Modul gekapselt.
Die Auswerter müssen nun nicht mehr die Queue mit einem Lock belegen, bevor sie darauf
zugreifen. Das erledigt der Dispatcher (MonitorModulesResults.h/cpp).

Unter Windows getestet. Unix noch nicht.

Zitat:

---

Zitat von Buebchen

Ich würde für die unterstützen Protokolltypen auch eine Liste als Antwort vorsehen. Dann kann der Server die unterstützen Protokolle anbieten und der Client nimmt das für ihn passende.

---

Das liesse sich leicht implementieren, Ich halte es jedoch für unnötig. Client und Server fragen gegenseitig die unterstützte Protokollversion ab und dann muss die niedrigste zwangsläufig für die Kommunikation herangenommen werden.
Erfährt der V3.2-Server, dass sein Client nur V2.78a drauf hat, antwortet er entweder mit einem OK und spricht dann 2.78a -- wenn er die Version nicht mehr beherrscht, bricht er den Handshake mit Fehler, Protokoll nicht implementiert ab.

Zitat:

---

Zitat von Buebchen

Den Servernamen hatte ich vorgesehen, wenn man mal später eine Relay-Funktion vorsehen würde

---

Das setzt voraus, dass der Servername in so gut wie jedes Kommando als Paramter eingefügt werden muss.

Gegenvorschlag:
Das Relay weiss, wie es mit den Servern verbunden wurde. Es kann daraufhin virtuelle Kanalnummern vergeben, so dass der Client letztendlich nach wie vor nur die Nummern einsetzt.

Beispiel:
Das Relay sieht drei Server mit Drei Kanälen -- der Client am Relay sieht einen Server mit 9 Kanälen.

Andreas

Zitat:

---

Zitat von nepomuck

Beispiel:
Das Relay sieht drei Server mit Drei Kanälen -- der Client am Relay sieht einen Server mit 9 Kanälen.

Andreas

---

Und wie weiss der Client nun, welcher Kanal wohin gehört ? Ich halte nicht das Einfügen des Servernamens für den Stein der Weisen. Aber der Lösungsansatz jetzt ein Multiplexing einzuführen ist es aus meiner Sicht auch nicht.

Aber sei's drum. Sofern die Gemeinde zustimmt, wird der Servername also erstmal ersatzlos gestrichen.

Das "trial-and-error" Verfahren zu Protokollbestimmung ist nicht gerade eine elegante Lösung. Aber da wären eher die Client-Entwickler dazu zu befragen. Serverseitig wird es eben nur ein NACK geben, wenn's nicht passt:-)

Zitat:

---

Zitat von Buebchen

Und wie weiss der Client nun, welcher Kanal wohin gehört ?

---

Jeder Kanal hat einen eindeutigen Namen. Letzten Endes geht es dem Client um den überwachten Dienst, nicht um irgendeinen Server.

Zitat:

---

Zitat von Buebchen

Aber der Lösungsansatz jetzt ein Multiplexing einzuführen ist es aus meiner Sicht auch nicht.

---

Ich glaube ein Relay ist erst unser überübernächstes Problem. Jetzt sollten wir erst einmal die Basis umsetzen und im nächsten Schritt Sorgen über all die vielen möglichen Zusätze machen.

Zitat:

---

Zitat von Buebchen

Das "trial-and-error" Verfahren zu Protokollbestimmung ist nicht gerade eine elegante Lösung.

---

Zwei Fragen, zwei Antworten: Bei einm "OK/OK" nimmt man die höchste Protokollversion, bei einem "OK/Not Supported" nimmt man die mit OK bestätigte, und bei einem "Not/Not" geht eh nix -- einfacher geht's kaum.
Alternativ könnte die gegenstelle auf den Inquiry mit mehreren Zeilen und mehreren Codes antworten: 111=Name,112=OS,113=ver,114=Proto

Code:

---

210
111:"monitord"
112:"linux"
113:0030
114:0021
114:0020
114:0015
100

---

Oder der 111 bekommt mehrere Paramter, wie der Errorcode, 1=Name, 2=OS, 3=Version, 4=Protokollversion 0="Habe fertig!"
also:

Code:

---

210
111:1:"monitord"
111:2:"linux"
111:3:0030
111:4:0021
111:4:0020
111:4:0015
111:0

---

Dann würde man die Versionsnummer als dritten paramter "Preferred Protocol" an den Login hängen.
Wie wäre das?

Zitat:

---

Zitat von Buebchen

Aber da wären eher die Client-Entwickler dazu zu befragen. Serverseitig wird es eben nur ein NACK geben, wenn's nicht passt:-)

---

Naja -- das ist momentan glaube ich unser Hauptproblem: Keiner befasst sich mit der Cliententwicklung.

Andreas

Zitat:

---

Zitat von nepomuck

Naja -- das ist momentan glaube ich unser Hauptproblem: Keiner befasst sich mit der Cliententwicklung.

Andreas

---

Ich denke auch man kann sich auf die Kanalbezeichnung einigen. Die Cliententwicklung ist halt so 'ne Sache. Ich habe den monitor vor einige Jahren ja nicht so ganz ohne Hintergedanken umgeschrieben :-) Ist aber eher ein Langzeitprojekt - mit Betonung auf lang .. *räusper* ...

Werde also mal anfangen, die Clientkommunikation im Sinne der PDF zu überarbeiten. Sollen wir mit einer Protokollversion 1.0 starten ? Oder 2.0 (parallel zum monitord) ?

uiiii ! hier tut sich wieder was.
gleich mal ausgechecked und configure gestartet.
habe nun das gleiche wie nepomuck:

Code:

---

checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.1... not present.
checking for snd_ctl_open in -lasound... no
configure: creating ./config.status
.infig.status: error: cannot find input file:

---

hm... natürlich auch unter linux
komme da nicht weiter.
unter win scheint's ja zu laufen.
schön wäre es wenn es kompartibel zu win und linux eingestellt wird.

öm zu den clienten...
ist es denn so geplant, dass ich mich mit nem crusader-client verbinden kann und er bekommt dann die letzten 500 auswertungen geschickt? verbinden geht ja schon, ich weiß, aber mich würden eben diese z.B 500 letzten protokolle reizen :-).
wenn das klappen würde wäre ich ultra begeistert.
leider kann ich aber nicht programmieren. kann also nur testen, auf nem headless-linux (ubuntu 6.10-server).

cu
MacLeod

Den Fehler

Code:

---

checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.1... not present.
checking for snd_ctl_open in -lasound... no
configure: creating ./config.status
.infig.status: error: cannot find input file:

---

konnte ich auf das unter windows erstellte configure script reduzieren. Ich habe jetzt unter Ubuntu 6.06 automake und autoconf nochmal gestartet und der Fehler im configure war behoben. Dafür habe ich noch andere Fehler (insbesondere streikt in der VMWare das /dev/dsp Interface im Moment). Könnte also bald wieder unter Linux laufen, sofern ich die Fehler heute noch finden kann :-)

Edit:
Sollte jetzt wieder unter Windows und Linux kompilieren. Fehler sind soweit gefixt. Wäre schön, wenn das mal jemand gegentesten könnte.

das configure lüppt nun durch
nun kommt das make:

Code:

---

make  all-am
make[1]: Entering directory `/home/tom/monitord/trunk'
source='monitord/Monitor.cpp' object='monitord/monitord_monitord-Monitor.o' libtool=no \
        DEPDIR=.deps depmode=none /bin/bash ./depcomp \
        g++ -DHAVE_CONFIG_H -I.  -Ijthread-1.2.1/src -D_DEBUG -Wall -pedantic        -c -o monitord/monitord_monitord-Monitor.o `test -f 'monitord/Monitor.cpp' || echo './'`monitord/Monitor.cpp
./depcomp: line 566: exec: g++: not found
make[1]: *** [monitord/monitord_monitord-Monitor.o] Error 127
make[1]: Leaving directory `/home/tom/monitord/trunk'
make: *** [all] Error 2

---

:-(
aso..
die ausführ-fags (755) mußte ich auch noch setzen, a sonst das configure nicht durchlief.
wäre nett wenn die gleich gesetzt sind ;-)

MacLeod

edit:
guten morgen....
g++ war nicht installiert *rolleyes*

Zitat:

---

Zitat von Buebchen

Ist aber eher ein Langzeitprojekt - mit Betonung auf lang

---

Das ist klar. Aber irgendwann zwischendrin sollte es mal eine ferige lauffähige Version geben auf deren Basis die weitere Entwicklung fußt.

Ich möchte folgendes Vorschlagen:
Lasst uns jetzt einen "Feature Freeze" machen. Wir einigen uns jetzt auf den Funktionsumfang der Version 2.0 und auf den Befehlssatz des Protokolls 1.0. Dann bauen wir dazu den funktionierenden Server für Windows und Linux mindestens einen Client für Windows und Linux. In der Zwischenzeit lassen wir uns nicht mehr von "Ich-hätte-da-noch-ne-Idee"-Postings ablenken, bis 2.0 steht.
Danach können die einen Praxiserfahrung sammeln, Bugs fixen und eine Dokumentation schreiben, während sich die anderen wieder übder den Code hermachen und neue Features ausprobieren.

Mein konkreter Feature-Vorschlag für die 2.0:

Protokoll
wie Vorgeschlagen -- hier muss noch jemand die Pocsac-Paramter festlegen!

Server
- Bedient pro thread 2 Kanäle
- Decodiert ZVEI mit DTFM, Pocsac und FMS
- kann mehrfach parallel mit mehreren Soundkarten arbeiten
- Kommuniziert bidirektional mit einem oder mehreren Clients über sein eigenes Protokoll
- Kommuniziert optional (nur Alarm-Out) über FMSCrusader und FMS32-Protokoll
- Kann auf Kommando einzelne oder mehrere kanäle aufzeichnen (mit sox)

Client
- Kommuniziert bidirektional mit dem Server
- Zeigt die Auswertungen mehrere Kanäle in einem oder mehreren Fenstern an
- Startet Shell-Skripte und Batch-Dateien in Abhängigkeit von Alarrmmeldung und Konfigurationsdatei
- Setzt @REC-Kommandos in Abhängikeit von Meldung und Config ab
- Offeriert einen Debug-Modus, der die komplette Protokollkommunikations darstellen kann.

Was haltet ihr davon?

Andreas

Die gute Nachricht: Nach einem chmod +x configure läuft config und make durch und der monitord lässt sich unter Ubuntu 7.10 (32Bit) starten: (rev 216)

Die schlechte Nachricht: Das neue ZVEI-Modul läuft nicht richtig -- da ist irgendwas gröberes kaputt.

Ich habe dem Monitor die Aufzeichnung einer Probealarmierung vorgespielt und er hat ungeheuer viele Fehler gemacht. Zum Vergleich habe ich auf der selben Hardware die alte Version laufen lassen, die alles richtig macht.

Diesem Posting hängen zwei Screenshots von 1.8.1 und Build 216 an -- die beide die gleiche Alarmierung vorgespielt bekommtn.

Die Fehler sind gelb markiert.

Andreas

Zitat:

---

Zitat von nepomuck

Das neue ZVEI-Modul läuft nicht richtig[/b] -- da ist irgendwas gröberes kaputt.

---

jupp
kann ich bestätigen, fms klappt wunderbar und zuverlässig zumindest auf der konsole.
zvei wird bei mir nicht erkannt...

mit dem crusader wird bei mir leider garnichts angezeigt.

kann ich noch was testen?

edit:
habe noch was:
wenn ich monitord auf der konsole gestartet habe wird fms ja nun prima ausgewertet.
nur wenn ich dann mich per telnet auf port 7778 anmelde kommt:

Code:

---

Signal setzen... .. done
Waiting for beendet
Dispatcher runnung ...Dispatcher waiting ...Waiting for signal
terminate called after throwing an instance of 'MonitorException'
  what():  monitord/SocketServer.cpp Zeile 512: memLockCreate failed
Aborted

---

komisch, das hat mal gefunzt...

Hallo,

Zitat:

---

Zitat von nepomuck

Die schlechte Nachricht: Das neue ZVEI-Modul läuft nicht richtig -- da ist irgendwas gröberes kaputt.

Ich habe dem Monitor die Aufzeichnung einer Probealarmierung vorgespielt und er hat ungeheuer viele Fehler gemacht. Zum Vergleich habe ich auf der selben Hardware die alte Version laufen lassen, die alles richtig macht.

Diesem Posting hängen zwei Screenshots von 1.8.1 und Build 216 an -- die beide die gleiche Alarmierung vorgespielt bekommtn.

Die Fehler sind gelb markiert.

---

hast Du beide Kanäle der Soundkarte mit denselben Daten auf das ZVEI-Modul losgelassen oder kam es nur von einem Kanal? Das sieht irgendwie so aus, als würde er da was verschieben... Ich hatte diesen Fehler zwischendurch einmal relativ zu Anfang meiner Tests, allerdings habe ich irgenwann zwischendurch nur noch von einem der beiden Kanäle ausgewertet (sonst gabs alles doppelt, klar, und das nervte) um erstmal die saubere Erkennung zu haben und ging dann davon aus, dass das entsprechend auch bei zwei Kanälen sauber läuft. War wohl ein Trugschluss, wenngleich sich mir der Fehler jetzt nicht spontan erschließt :(. Lässt man nur von einem Kanal erkennen, tritt der Fehler also augenscheinlich nicht auf; bitte probier das mal aus (abschalten des Moduls von einem der beiden Sound-Kanäle in der Konfigurations-XML-Datei, so dass Du nur noch eine Datenquelle für den ZVEI-Auswerter hast).

Ich habe (nach dem Absetzen des Artikels) die aktuelle Revision (216) ausgecheckt, kompiliert und gestartet. Leider trat bei meinen Tests auch mit zwei Kanälen als Eingang der Fehler nicht auf. Kann ich Dein Testfile mal haben um den Fehler nachzuvollziehen (am liebsten als Download mit Link per pm)?
Mir ist außerdem noch eingefallen, dass ich zur Zeit ausschließlich unter Windows baue und teste, daher sollten wir auch in Sachen Sound-Verarbeitung auf den verschiedenen Plattformen schauen, ob alles glatt läuft (Schuss ins Blaue, klar - aber vielleicht auch ein Ansatz). Leider steht mir momentan kein Rechner mit einem Ubuntu (oder anderem Linux) zur Verfügung um selber zu testen, muss ich noch immer mal einrichten :(.

Ansonsten habe ich eben auch noch eine Merkwürdigkeit entdeckt: Ich habe mir einen kleinen Client geschrieben (wxWidgets), der den monitord connected und seine Ausgaben anzeigt (mit Datum und Zeit, optischer Signalisierung durch rot werdenden ALARM-Button und akustischer Signalisierung durch Abspielen eines Tons). Wenn ich diesen an den monitord hänge und schließe bzw. das ein paarmal mache, generiert der monitord 100% CPU-Last. Hat dazu spontan jemand eine Idee? Es ist dann kein Client mehr connected aber die Verbindungen wurden vom Client nicht sauber disconnected sondern stumpf abgebrochen.

Martin

Zitat:

---

Zitat von mdi

hast Du beide Kanäle der Soundkarte mit denselben Daten auf das ZVEI-Modul losgelassen oder kam es nur von einem Kanal?

---

Meine Config läd ZVEI auf einem, FMS auf dem anderen Kanal.

Zitat:

---

Zitat von mdi

Das sieht irgendwie so aus, als würde er da was verschieben

---

Ich habe da eine Vermutung:
Unsere Alarmierung löst jede Schleife doppelt aus. Wenn kein DTFM-Ton anhängt, kommen die Fünftonfolgen in sehr enger Abfolge -- es gibt keinen Melderton.

Für mich sieht das so aus: Dein Auswerter erkennt die erste Schleife korrekt. Dann wartet er auf einen DTFM- oder Weckerton. Da der nicht kommt, interpretiert er den ersten Ton der folgenden 5-Ton-Folge als DTFM-Ton und beginnt die eigentliche ZVEI-Dekodierung erst beim zweiten Ton.

Das würde erklären, warum so viele Fehlauswertungen mit "6" beginnen, da unsere Schleifen alle mit "26" anfangen. Der Fehler tritt vor allem in dem Bereich der Probelalarmierung auf, in der sehr viele Schleifen ohne Folgeton in sehr schneller Abfolge kommen.
Den zweiten Teil der Probealarmierung, der alle Sirenen auslöst, erkennt der Auswerter fehlerfrei.

Zitat:

---

Kann ich Dein Testfile mal haben um den Fehler nachzuvollziehen (am liebsten als Download mit Link per pm)?

---

Ich schicke dir einen Link.

Andreas

Zitat:

---

Zitat von MacLeod

jupp
kann ich bestätigen, fms klappt wunderbar und zuverlässig zumindest auf der konsole.
zvei wird bei mir nicht erkannt...

mit dem crusader wird bei mir leider garnichts angezeigt.

kann ich noch was testen?

edit:
habe noch was:
wenn ich monitord auf der konsole gestartet habe wird fms ja nun prima ausgewertet.
nur wenn ich dann mich per telnet auf port 7778 anmelde kommt:

Code:

---

Signal setzen... .. done
Waiting for beendet
Dispatcher runnung ...Dispatcher waiting ...Waiting for signal
terminate called after throwing an instance of 'MonitorException'
  what():  monitord/SocketServer.cpp Zeile 512: memLockCreate failed
Aborted

---

komisch, das hat mal gefunzt...

---

Seltsamer Fehler. Könnte sein, daß ich den Fehler dafür gefunden habe (wenn ein Thread beendet wurde habe ich das memlock nicht freigegeben, aber dennoch versucht, es später wieder zu belegen).

Mein kleiner Test war in sofern erfolgreich, daß ich folgendes gemacht habe:
1. monitord unter Ubuntu 6.06
2. BOSTool als Tonquelle
3. Crusader unter Windows mit dem monitord in der VMWare verbunden

Alles soweit ok. Ist der Fehler reproduzierbar ? Ggf. mal ein make clean machen, um sicher zu sein, daß er einige Teil nicht korrekt neu baut.

Edit: SVN aktualisiert.

Sehr seltsam ...

Ich habe gerade den monitord (rev 217) unter Ubuntu 7.10 64-Bit übersetzt und ihm die besagte Probelalarmierung vorgespielt.
Auf der x64-Kiste läuft die ZVEI-Auswertung ohne Fehler.

???

Hallo,

ich habe selber auch einmal geschaut und festgestellt, dass hier keine Auswerte-Fehler (in den ersten drei Minuten, Rücksicht auf meine Nachbarn *fg*) auftreten (naja, jedenfalls keine, die sich nicht durch die Verringerung des Abstands Mikro-Lautsprecher bzw. Lautstärkeanpassung richten ließen... allerdings wurde da dann entweder gar nichts erkannt oder der Sirenenton blieb mal auf der Strecke). Das ganze abgespielt in WinAmp, aufgenommen über PC-Boxen und Mikro als Aufnahmequelle.

Aber schön, jetzt habe ich mal authentische Daten testen können; bisher habe ich mir immer mal etwas gebaut mit Audacity/Rauschen und Ton-/ZVEI-Generator. Ich sehe im Algorithmus auch durchaus noch Verbesserungspotenzial, aber bezüglich des Fehlers bin ich leider nicht weitergekommen jetzt :(.

Zu dem geäußerten Verdacht: Ich habe einen Zustandsautomaten implementiert, dessen Zustand sich entlang der fünf zu erkennenden Ziffern bewegt. Entsprechend gibt es entweder ein "Fünftonfolge aus fünf Ziffern empfangen" oder ein "Fehlerfall: Reset". Wenn eine Fünftonfolge vollständig abgehört und erkannt wurde, wird auf den nächsten Ton (welchen auch immer) eine gewisse Zeit lang gewartet. Besteht dieser nächste Ton aus einer Frequenz der Ziffern, wird die bereits erkannte Folge ausgegeben und direkt mit dieser Ziffer eine neue Folge begonnen. Ist die Mischung der Sirenenfrequenzen zu hören,wird entsprechend der Alarmtyp bestimmt. Wird der Melderweckton innerhalb des Timeouts erkannt (gleich der Wiederholfrequenz, die aber nicht an erster Stelle einer Fünftonfolge stehen kann), wird der Status "Melderalarm" (1) gesetzt. Da kann eigentlich nix verloren gehen; das ganze ist deterministisch, wenn nicht merkwürdige Dinge geschehen (die dazu führen sollten, dass die Folge verworfen und nichts ausgegeben wird).

@McLeod: Bei Dir wird gar nichts erkannt? Es kann sein, dass die Rauschsperre, also der Abstand der erkannten Frequenz zum Grundrauschen bzw. der nächsten, "zweitlautesten" Frequenz zu gering ist. Ich habe einen Default-Wert von "#define SQUELCH_LEVEL 2000" eingestellt (hardcoded in MonitorModuleZVEI.cpp). Das ist recht wenig an sich, kann aber bei leisen oder stark verrauschten Signalen, die möglicherweise Unterbrechungen beinhalten, problematisch werden. Wie hast Du getestet?

Viele Grüße
Martin
PS: Ich habe die Rausschsperre jetzt auch auf die Sirenentöne gelegt, da Störgeräusche (laufende Musik) hier "live" immer mal wieder zur Auslösung des Status 2 geführt haben. Das klappt jetzt besser. War allerdings die einzige Anpassung und hat an der Funktionalität und Logik nichts geändert...

Zitat:

---

Zitat von nepomuck

Wenn kein DTFM-Ton anhängt, kommen die Fünftonfolgen in sehr enger Abfolge -- es gibt keinen Melderton.

---

[Klugscheissmodus]
Bitte, bitte, bitte, schreib doch mal DTMF. Das kommt von "Dual Tone Multiple Frequency". DTFM gibt es nicht. Mir bricht es jedes Mal fast die Augen!
[/Klugscheissmodus]

Trotzdem schonmal danke und Gruß,
Funkwart

;-)

Zitat:

---

Zitat von mdi

@McLeod: Bei Dir wird gar nichts erkannt? .... Wie hast Du getestet?

---

also:
habe nun die rev218. zvei wird bei mir nun erkannt, aber leider nicht alle :-(

folgende konstellation habe ich hier aufgebaut:
ubuntu-server im obergeschoss an dem hängt der scanner welcher per disc. ausgang angeschlossen ist.
scanner steht im erdgeschoss(antenne unterm dach)und ist sowohl am server (disk.ausgang) als auch an einer winkiste(erdgeschoss) LS-ausgang angeschlossen.
gefüttert habe ich den server nun mit ner aufnahme die ich auf der winxp-kiste (erdgeschoss)hatte.
line-in am server ist mit alsamixer auf 100 eingestellt das tut sich aber nicht viel ob halbe lautstärke oder voll...

ich hoffe da steigt einer duch ;-)


crusader zeigt nun auch wieder an :-)

MacLeod

edit:
bei uns werden die 5-ton folgen auch zwei mal hintereinander ausgelöst.
komisch ist ja das fms astrein sauber ausgewertet wird, nur bei zvei ist das ein bissel kritisch.

so hab noch mal n bissel getestet
fms wird opti erkannt. auch in zimmerlautstärke :-)
zvei muß ich derart aufregeln, das mir bald die ohren abfallen, und es kommt auch schon ein wenig zu verzerrungen. ev liegts ja daran das dann der signal/Rauschabstand groß genug ist, nur dann ists schon leicht verzerrt.
könnte ev der sig/rauschabstand eingestellt werden, bzw in der xml eingestellt werden?
wäre doch n versuch, nur leider weiß ich nicht ob das so einfach zu lösen ist ?

cu

edit:
...Ich habe einen Default-Wert von "#define SQUELCH_LEVEL 2000" eingestellt (hardcoded in MonitorModuleZVEI.cpp)...

da habe ich jetzt ein wenig mit gespielt :-)
im moment steht er bei mir auf 20 ! ... nicht hauen... :-)

zvei wird nun erheblich besser erkannt! muß nun mal einen längeren test fahren. alle 5-ton folgen die ich ihm nun vorgesetzt habe seien sie noch so verraucht oder verzerrt, wurden nahezu alle erkannt.und das in zimmerlautstärke :-)
mal sehen was kommt, wenn mein scanner mal was rausjagt.

Moinmoin,

Zitat:

---

Zitat von MacLeod

könnte ev der sig/rauschabstand eingestellt werden, bzw in der xml eingestellt werden?
wäre doch n versuch, nur leider weiß ich nicht ob das so einfach zu lösen ist ?

---

doch, das war schon noch für "die Zukunft" geplant, ich habe mich nur noch nicht ausreichend mit dem XML-Parsing und dem Aufbau des Monitors befasst, sprich: Es wäre ja praktisch, wenn die XML-Config-Datei nur einmal ausgelesen werden müsste und den ZVEI-Modulen dann gesagt wird, wie groß die Parameter sein sollen. Das _geht_ bestimmt... :D.

Zitat:

---

Zitat von MacLeod

...Ich habe einen Default-Wert von "#define SQUELCH_LEVEL 2000" eingestellt (hardcoded in MonitorModuleZVEI.cpp)...

da habe ich jetzt ein wenig mit gespielt :-)
im moment steht er bei mir auf 20 ! ... nicht hauen... :-)

---

Nein, warum hauen? Du hast mich auf einen wesentlichen Denkfehler hingewiesen! Die Geschichte war angepasst auf die bei mir auftretenden Wertebereiche. Das war Unsinn (eigentlich logisch ;D).
Ich habe den Filter jetzt angepasst durch Angabe einer Größe relativ zur Gesamtenergie des betrachteten Spektrums zur gegebenen Zeit (also ist nicht mehr die absolute 2000 oder 20 der Strich im Diagramm sondern ein 0.4 * gemessene_Gesamtenergie). Der Faktor 0.4 ist anpassbar, zur Zeit noch per define. Auch habe ich eine Debug-Möglichkeit eingefügt (default: false), ebenfalls per define anknipsbar. Die generiert dann ein Logfile der Energien der betrachteten Frequenzen. Klingt wüst, ist auch wüst und nicht zu empfehlen, es mit Logging länger als sagen wir ein, zwei Minuten laufen zu lassen.

Die Version steht im SVN.

Martin

Habe ein neue Version im SVN bereitgestellt. Im wesentlichen Designänderungen. Die SocketThreads, also die Komponentem, die mit dem verbunden Client spricht ist jetzt pro möglichem Client eine eigene Klasse. Damit ist es leichter spezifische Anpassungen durchzuführen, ohne die anderen Module berücksichtigen zu müssen.

Gerade für die angedachten Versionierungen beim monitord erscheint mir das sinnvoll. Ausserdem sind damit die crusader und FMS32 Module vom kommenden Ballast der Aufnahmesteuerung befreit :-)

Die neuen Klassen sind:

* SocketThreadMonitord
* SocketThreadCrusader
* SocketThreadFMS32

make geht nicht mehr... ???

Code:

---

s/monitord_monitord-MonitorModuleZVEI.Tpo -c -o monitord/monitord_monitord-Monit                  orModuleZVEI.o `test -f 'monitord/MonitorModuleZVEI.cpp' || echo './'`monitord/M                  onitorModuleZVEI.cpp
monitord/MonitorModuleZVEI.cpp:37: error: expected unqualified-id before â<<â to                  ken
make[1]: *** [monitord/monitord_monitord-MonitorModuleZVEI.o] Error 1
make[1]: Leaving directory `/home/tom/monitord/trunk'
make: *** [all] Error 2
tom@TomServer:~/monitord/trunk$

---

Hallo,

ich habe die aktuelle Revision 220 eben neu ausgecheckt und kein Problem finden können. Dein Fehler-Log besagt, dass in der Zeile 37 ein "<<"-Operator stehen soll. Das ist definitiv nicht korrekt; kann es sein, dass der Checkout irgendwie korrumpierte? Besteht die Möglichkeit, den /trunk bei Dir lokal zu löschen und neu auszuchecken?

Ich habe mittlerweile auch eine Ubuntu-Box (in einer virtualbox) laufen, allerdings tut der Mikro-Eingang nicht (Mist!). Auch dort konnte ich sauber auschecken und ./configure, make laufen lassen, was ein funktionsfähiges Binary ergab.

Martin
PS: Wow. Ich bin absolut fasziniert, wie schnell es hier mit allem möglichen weitergeht und wie kurz die Antwortzeiten bei Problemen sind :)!

Ich kann auch unter Ubuntu 6.06 keinen Fehler feststellen und würde auch einen neuen checkout vorschlagen.

jo!
trunk-ordner gelöscht und neu ausgechecked.
nu lüppt dat. komisch wer weiß was da broken war ....*grübel*

zvei funzt nun um welten besser! selbst die sirenenauslösung wird erkannt :-)))

alarme über den angeschlossenen scanner sind natürlich selten. habe auch nicht immer meinen "arbeitsrechner" am laufen.
gibts denn schon ne entwicklung in sachen "gespeicherter protokolle" zwecks langzeittest meine ich...

für den crusader oder fms32, wäre es doch toll wenn die protokolle irgendwie zwischengespeichert werden, muß ja nicht in ner datenbank sein, und beim aufruf des programms werden diese protokolle an das frontend übergeben.
ich weiß, ich wiederhole mich...
ich kann leider wie schon gesagt nicht programieren, sonst hätte ich mich da sicher ran gemacht.
ich weiß auch nicht in wie weit das überhaupt machbar ist. kann nur hoffen das es irgendwann klappt.

was habt ihr denn als frontend angeschlossen?

Gruß
Thomas

Zitat:

---

Zitat von mdi

Ich habe mittlerweile auch eine Ubuntu-Box (in einer virtualbox) laufen, allerdings tut der Mikro-Eingang nicht (Mist!).

---

Zwei Tipps:
Ich weiss nicht, wie es unter VBox aussieht, aber unter VMWare läuft bei mir weder monitor noch fmspro32 richtig. Da gibt´s wohl Timingprobleme.
Du brauchst den Mikroeingang gar nicht. Unter Linux kannst du im Mixer einstellen, dass der Soundkarten-Ausgang zugleich das Record-Device ist. Du spielst einfach nur die Alarmaufzeichnung mit irgend einer Playersoftware ab und der Monitor auf der selben Kiste wertet aus -- kein Mikro, keine Lautsprecher, kein Lärm :-)

Zitat:

---

Zitat von MacLeod

für den crusader oder fms32, wäre es doch toll wenn die protokolle irgendwie zwischengespeichert werden, muß ja nicht in ner datenbank sein, und beim aufruf des programms werden diese protokolle an das frontend übergeben.

---

Neue Featurewünsche bitte für das nächste Release.
Ein Protokoll kannst du über einen Client auf dem Server aufnehmen.

Zitat:

---

Zitat von MacLeod

alarme über den angeschlossenen scanner sind natürlich selten

---

Mir hat mal jemand erzählt, dass auf den Frequenzen des Rettungsdienstes andauernd rumalarmiert wird und permantent FMS-Meldungen über den Funk rauschen. Ich hör da natürlich nicht hin .....

Zitat:

---

Zitat von MacLeod

was habt ihr denn als frontend angeschlossen?

---

Noch gibt es kein Frontend. Bislang arbeite ich mit

Code:

---

telnet localhost 9333 > protokoll.log

---

Ich habe den Build 220 auf zwei Maschinen getestet, einem AMD x2 mit Ubuntu 7.10 64-Bit und dem IBM Thinkpad T43p mit Ubuntu 7.10 32-Bit.

Die ZVEI- und DTMF- (war`s so richtig) Erkennung ist deutlich besser geworden. Dennoch treten bei mir nach wie vor die Zahlendreher bei ZVEI-Alarmen auf.
Allerdings habe ich den Fehler NUR auf dem Notebook. Dort funktioniert 1.8.1 aber problemlos. Kann es sein, dass der neue ZVEI-Decoder mit den System-Timern auf einem Notebook Probleme haben könnte? Ich hatte da mal vor langem Schwierigkeiten mit einer anderen Real-Time-Anwendung, die mit den ständig wechselnden CPU-Frequenzen des Notebook-Powersavings nicht zurecht kam.

Die FMS-Erkennung geht recht gut, bei mir allerdings nur bei einem höheren Eingangspegel. Ich habe aber auch keinen Diskriminatorausgang. Gegenüber der 1.8.1 fällt mir allerdings auf, dass das FMS-Modul sehr häufig irgendwelche Störgeräusche als FMS-Meldung interpretiert. Ich habe folglich sehr viele Falschmeldungen im Log.

Andreas
PS: Ich habe von euch noch keine Rückmeldung zu den Themen Codefreeze und Syntax des Pocsac-Kommandos. Ich fände es gut, wenn wir so langsam mal fokussiert auf eine vollständige Version hinarbeiten könnten.

Hallo,

Zitat:

---

Zitat von MacLeod

trunk-ordner gelöscht und neu ausgechecked.
nu lüppt dat. komisch wer weiß was da broken war ....*grübel*
(...)
zvei funzt nun um welten besser! selbst die sirenenauslösung wird erkannt :-)))

---

Fein, dann hat sich die kleine Änderung ja schon gelohnt. Kaputt war da bei Dir wenigstens die Datei MonitorModuleZVEI.cpp :D!
SCNR ;).

Zitat:

---

Zitat von MacLeod

gibts denn schon ne entwicklung in sachen "gespeicherter protokolle" zwecks langzeittest meine ich...

---

Meinerseits nicht. Allerdings (ich wiederhole mich, ich weiß) wäre da mein Ansatz, dass eine SQLite-Datenbank dafür eingerichtet wird. Die Standard-SQL-Syntax ist dabei für die Abfragen nutzbar, so dass für z.B. ein PHP-Frontend lediglich das Öffnen und Schließen der Datenbank (statt MySQL) angepasst werden muss. Auch wären entsprechend freie Anfragen über alle Wege machbar wie "alle Alarmierungen von gestern", "alles zwischen heute, 13 und 14 Uhr", ...

Als Frontend baue ich mir gerade einen Mini-Client, der per Konfigurationsdatei auf eine Schleife (mehrere Schleifen) aktiviert werden kann und bei Empfang derselben entsprechend Alarm gibt. Allerdings habe ich mit dem noch das schon kurz beschriebene Problem, dass bei Schließen meines Programms der monitord plötzlich CPU-Last macht ohne Ende. Gesehen habe ich durch Zufall, dass beim Disconnecten von Telnet (simples Schließen des Fensters) der Socket-Thread beendet wird; wenn ich mein Tool nutze, tut er das nicht. Da muss ich noch genauer schauen, was da wo warum passert.

Zitat:

---

Zitat von nepomuck

Zwei Tipps:
(Timing in VMWare), (kein Mikro, keine Lautsprecher, kein Lärm)

---

Das mit dem Timing-Problem ist komisch. Aber da bei mir eh nix an Sound ankommt, werde ich dem zweiten Hinweis mal nachgehen, THX.

Zitat:

---

Zitat von nepomuck

Die ZVEI- und DTMF- (war`s so richtig) Erkennung ist deutlich besser geworden. Dennoch treten bei mir nach wie vor die Zahlendreher bei ZVEI-Alarmen auf.
Allerdings habe ich den Fehler NUR auf dem Notebook. Dort funktioniert 1.8.1 aber problemlos. Kann es sein, dass der neue ZVEI-Decoder mit den System-Timern auf einem Notebook Probleme haben könnte? Ich hatte da mal vor langem Schwierigkeiten mit einer anderen Real-Time-Anwendung, die mit den ständig wechselnden CPU-Frequenzen des Notebook-Powersavings nicht zurecht kam.

---

Hm... würde mich grundsätzlich sehr wundern, da im Code entlang des übergebenen Sound-Buffers dekodiert wird und es dem Auswerter schnurz ist, was irgendwelche Uhren sagen. Vielleicht muss ich mir den Code des 1.8.1-ers nochmal anschauen und den Ablauf vergleichen.

Zitat:

---

Zitat von nepomuck

PS: Ich habe von euch noch keine Rückmeldung zu den Themen Codefreeze und Syntax des Pocsac-Kommandos. Ich fände es gut, wenn wir so langsam mal fokussiert auf eine vollständige Version hinarbeiten könnten.

---

Japp, das Feature der Datenbank ist dann eindeutig Kandidat für die 2.1. Ein entsprechendes... ich mags "Feature-Freeze" nennen, ist damit auch in meinen Augen absolut sinnvoll.

Martin

Zitat:

---

Zitat von MacLeod

Code:

---

monitord/MonitorModuleZVEI.cpp:37: error: expected unqualified-id before "<<" token

---

---

Das überzählige "<<" ist in diesem Fall wohl eine gewünschte Eigenschaft von Subversion.
Was passiert ist:

Subversion konnte einen Unterschied zwischen der aktuellen Revision und deiner Arbeitskopie nicht "mergen", es ist ein Konflikt aufgetreten - das sieht man beim Checkout an dem Buchstaben "C" vor dem Dateinamen.

Bei einem Konflikt legt Subversion 3 temporäre Dateien an, das sieht dann hinterher z.B. so aus:

Code:

---

MonitorModuleZVEI.cpp.r1
MonitorModuleZVEI.cpp.mine
MonitorModuleZVEI.cpp.r5
MonitorModuleZVEI.cpp

---

Die ".r1"-Datei (Revision 1, Beispiel) ist die Revision, die Du ursprünglich ausgecheckt hattest. Da Du die Datei geändert hast, wird die geänderte Kopie als .mine-Datei gesichert. Die ".r5"-Datei (Revision 5, Beispiel) ist die aktuelle Revision vom SVN-Server. Zu guter letzt gibt es noch die Datei ohne zusätzliche Endung: In dieser Datei sind die entscheidenden Zeilen von sowohl Deiner Änderung, als auch der Änderung die durch den SVN-Checkout in die Datei kommen sollen. Getrennt wird dabei mit Zeilen wie "<<<<<<< .mine" "=======" ">>>>>>> .r5".

Um diesen nicht automatisch behebbaren Konflikt zu beseitigen, machst du entweder ein

Code:

---

svn revert <dateiname>

---

um die Originalversion wiederherzustellen oder du editierst die Datei ohne zusätzliche Endung derart, dass die SVN-Konfliktmarker raus sind und der "Konflikt" behoben ist. Das musst du SVN dann noch sagen und zwar mit

Code:

---

svn resolved <dateiname>

---

Mehr (Ausführlicheres) zu dem Thema gibts (scheinbar nur in Englisch) im SVNBook unter:
http://svnbook.red-bean.com/ (Einstiegsseite)
http://svnbook.red-bean.com/en/1.4/s....cycle.resolve (Direktlink zur Konfliktlösung)

bye
Einhirn

Zitat:

---

Zitat von nepomuck

Die FMS-Erkennung geht recht gut

---

Soeben bemerkt: Das FMS-Modul dekodiert keine Folgetelegramme (längere Textübertragungen).
Einige Leitstellen in der Umgebung nutzen das Feature, um Einsatzdaten als Text zum Fahrzeug zu übermitteln. Monitor (Build 220) zeigt dabei aber nur, FZ-Kennung, Status A, Lst -> FZ
Version 1.8.1 zeigt den Folgetext.

Fehler oder noch nicht implementiert?

Andreas

Zitat:

---

Zitat von nepomuck

Soeben bemerkt: Das FMS-Modul dekodiert keine Folgetelegramme (längere Textübertragungen).
Einige Leitstellen in der Umgebung nutzen das Feature, um Einsatzdaten als Text zum Fahrzeug zu übermitteln. Monitor (Build 220) zeigt dabei aber nur, FZ-Kennung, Status A, Lst -> FZ
Version 1.8.1 zeigt den Folgetext.

Fehler oder noch nicht implementiert?

Andreas

---

Gut beobachtet. Ist aber im Moment leider noch nicht implementiert. Kommt aber bald ins SVN (sofern sich meine WorkingCopy mal wieder vollständig kompilieren läßt), d.h. Innerhalb des Debugs wird es dann uebertragen werden. Fehlt nur noch die Ergänzung der SocketThreads, damit diese die Info auch ausgeben.

Edit:
WC läßt sich nun kompilieren. Die Mutigen können also die ersten Erfahrungen damit sammeln (rev 221). Noch nicht unter linux getestet, ob make durchläuft (sollte aber m.E.).

jupp make lüppt unter linux durch und text wird angezeigt:

Code:

---

textuebertragung = "&12:03: 258..*wlnotf*hunf*.......*.........*...........*>* **"

---

wobei ich ort*straße*name mit ...... rausgenommen habe

wie du schon sagtest, es fehlt nur noch die implementierung der einzelnen socketthreads
:-))))
klasse arbeit :-))))

wäre es nicht möglich debug in eine logdatei zu schieben?

Thomas

ach ja, hatte ich vergessen...
featurewünsche erst für die version 2.1 ... *rolleyes*

So, nächte Rev. liegt im SVN. Irgendwie war mein Eclipse Plugin ein wenig verwirrt. Aktuell ist jetzt rev.226. Neu ist jetzt die Aufnahmesteuerung (Kommando 204 vom Client). Schreibt im Moment im raw Format.

Namesschema ist fest eingestellt:
[Kanalnummer]_[DATUM_UHRZEIT].raw im monitord Ordner.

Wobei die Kanalnummer so vergeben sind:
0 = Links der ersten Soundkarte
1 = Rechts der ersten Soundkarte

2 = Links der zweiten Soundkarte
3 = Rechts der zweiten Soundkarte

usw.

Auch die anderen Kommandos laut letztem Entwurf sollen nun gehen. Ebenso sind nun die Ausgaben für FMS,ZVEI und POCSAG an das neue Format angepasst.

Die Plugins für die Audioaufnahme sind nur verfügbar, wenn man mit configure --enable-plugins deren Übersetzung anfordert. Vorher am besten ein make clean, damit auch wirklich alles neu übersetzt wird. Wer ein 101:005 auf ein 204er Kommando bekommt hat wohl etwas falsch gemacht:-)

Zur Zeit läßt sich der monitord unter Windows nur per Task-Manager beendet. Unter Linux klappt weiter STRG-C. Das warum werde ich mir nochmal anschauen...

Zitat:

---

Zitat von Buebchen

Auch die anderen Kommandos laut letztem Entwurf sollen nun gehen. Ebenso sind nun die Ausgaben für FMS,ZVEI und POCSAG an das neue Format angepasst.

---

Bei mir arbeitet die Version ohne Plugin (auf dem Thinkpan mit Ubuntu 7.10 32Bit). Mit Plugin stürzt Monitord mit einem Segmentation Fault ab. Ich probiere das gleich noch auf der 64-Bit-Plattform.

Der 203 liefert aktuell immer 8 Kanäle zurück, auch wenn nur zwei in der Config stehen.

Die Zvei-Alarme kommen mit einem 320. Der sollte aber für Pocsac zuständig sein (und wir haben noch keine Syntax dafür). Zvei sollte aber einen 300 auslösen.
Der 300er (momentan 320) gibt noch Text als Sirenencode zurück, das Protokoll sieht eine nummerische Ausgabe vor.

Wir sollten uns noch ein Paar xml-Paramter für die Config ausdenken, mit der wir Pfad und Dateinamen für die Aufnahme steuern.

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

Bei mir arbeitet die Version ohne Plugin (auf dem Thinkpan mit Ubuntu 7.10 32Bit). Mit Plugin stürzt Monitord mit einem Segmentation Fault ab. Ich probiere das gleich noch auf der 64-Bit-Plattform.

---

Poste da bitte mal die letzten Ausgaben vor dem SegFault. Unter meinem Ubuntu 6.06 (32Bit) klappt das Probleme. Vermutlich kann er die Plugins nicht laden (Die Plugins sind als eigene Dateien ausgelagert und werden zur Laufzeit dazugeladen).

Zitat:

---

Zitat von nepomuck

Der 203 liefert aktuell immer 8 Kanäle zurück, auch wenn nur zwei in der Config stehen.

---

Oh. da war die Debugeinstellung noch nicht wieder raus. Jetzt werden wieder nur aktive Karten angezeigt. Was später noch in der Doku aufgeführt werden muss: Man darf niemals eine Karte "überspringen". Also nicht die erste und dritte aktiv schalten, die zweite aber nicht. Dann würde das herunterzählen nicht funktionieren. Die Kanale 2 und 3 würden fehlen.

Zitat:

---

Zitat von nepomuck

Die Zvei-Alarme kommen mit einem 320. Der sollte aber für Pocsac zuständig sein (und wir haben noch keine Syntax dafür). Zvei sollte aber einen 300 auslösen.
Der 300er (momentan 320) gibt noch Text als Sirenencode zurück, das Protokoll sieht eine nummerische Ausgabe vor.

---

Die 320 ist jetzt in 300 geändert (jaja, cut & paste :-) ). Der Weckton ist numerisch vorhanden. Danach habe ich einen Text ergänzt. Den bitte zum Protokoll hinzufügen. Der Grund ist ganz einfach: Ein ggf. irgendwann zentral verfügbares Modul kann da auch noch den Namen des Empfängers oder sonstiges hinzufügen. Generell bin ich in fast allen Produkten die ich betreue der Meinung, daß ein Freitext Feld immer vorhanden sein sollte. Man kann sich zu Beginn oft nicht vorstellen, was der Benutzer später gerne noch als kleinen Hinweis hinterlegen möchte (und was tatsächlich sinnvoll ist).

Für POCSAG wäre die Struktur:

Code:

---

320:{Zeitangabe}:{RIC}:{Subadresse}:{Text}

---

Die Unterscheidung Nur-Ton, Numerisch und Alphanumerisch ist auf der Empfängerseite relevant, wie er die Daten anzeigt. Im POCSAG Code unterscheiden sie sich nur darin, ob nach dem Adresswort noch Datenworte folgen oder nicht. Hier würde es sich für den monitord Client also daran unterscheiden, ob der Text leer ist oder nicht.

Zitat:

---

Zitat von nepomuck

Wir sollten uns noch ein Paar xml-Paramter für die Config ausdenken, mit der wir Pfad und Dateinamen für die Aufnahme steuern.

---

Bis auf Kleinigkeiten (z.B. ein Präfix) würde ich den Dateinamen in der Version 2.0 so lassen.

In der Version 2.1 kann man dann z.B. noch eine zweite Datei schreiben, die die Daten zur Aufnahme enthält (Welcher Client hat es angefordert, ggf. ein Freitext vom Client, Dauer, Start, Ende , ...).

Pfadangabe ist selbstredend notwendig. Werde ich einpflegen.

Zitat:

---

Zitat von Buebchen

Noch ein Beitrag zum Kommunikationsprotokoll:
Bei der Channel-Info (Kommando 203) sollte noch ein Bit 2^3 eingefügt werden. Damit man 2^2 für 512Baud POCSAG und 2^3 für 1200 Baud POCSAG nehmen kann.

---

Übernehme ich in das Protokoll wie vorgeschlagen

Zitat:

---

Zitat von Buebchen

Inquiry (Kommando 210,110):
Macht es Sinn die Antworten zu "quittieren" ?

---

Das ist tatsächlich nicht nötig. Ich ändere Die Dokumentation entsprechend und streiche die Quittung bei den Kommandos, die darauf verzichten können.

Zitat:

---

Zitat von Buebchen

Bei den Aufnahmekommando könnte man ggf. bei einer Antwort, daß die Aufnahme schon läuft, bzw. die Aufnahme beendet ist, noch die geplante (gesamte) Aufnahmedauer mitgeben.

---

Wäre möglich, aber macht das Sinn? Der Client hat ja die Zeit selbst vorgegeben und erwartet einen "Aufnahme beendet". Er braucht die "Zischenzeit"-Angabe vom Server nicht auszuwerten.

Zitat:

---

Zitat von Buebchen

(Die Plugins sind als eigene Dateien ausgelagert und werden zur Laufzeit dazugeladen).

---

OK. Da liegt wahrscheinlich der Fehler. Ich move das Executable monitord nach erfolgreichem make in ein anderes Verzeichnis, in dem sonst nur die .xml drin steht. Da kann er die Module nicht finden.
Wie heissen die Moduldateien? Kann man einen Failsafe einbauen, so dass monitord eine klingende Fehlermeldung ausgibt wie "Module nicht gefunden"?

Zitat:

---

Zitat von Buebchen

Man darf niemals eine Karte "überspringen". Also nicht die erste und dritte aktiv schalten, die zweite aber nicht.

---

Um Fehler zu vermeiden, sollte monitord.xml dann gar keine Nummern sondern nur Namen deklarieren. Die Nummerierung erledigt monitord dann intern gemäß der Reihenfolge der Kanäle in der Config.

Zitat:

---

Zitat von Buebchen

Die 320 ist jetzt in 320 geändert

---

das ändert alles :-)

Zitat:

---

Zitat von Buebchen

Danach habe ich einen Text ergänzt. Den bitte zum Protokoll hinzufügen.

---

OK. Dan bekommt der 300 ein Textfeld am Ende. Was machen wir, wenn es keinen Text zu übermitteln gibt? Lassen wir das Feld weg oder sendet der 300 in dem Fall ein einzelnes ":" am Ende?
Die Pocsac-Struktur übernehme ich ins Protokoll wie vorgeschlagen.

Zitat:

---

Zitat von Buebchen

... würde ich den Dateinamen in der Version 2.0 so lassen ...
Pfadangabe ist selbstredend notwendig. Werde ich einpflegen.

---

Damit können alle gut leben.

Das überarbeitete Protokoll poste ich im Laufe der nächsten Tage,
Grüße,
Andreas