Es wäre ja auch zu leicht, wenn es anders wäre :-)Zitat:
Zitat von nepomuck
Den Fehler habe ich bisher noch nicht gesucht. Werde mal 21x ZVEI Folgen einspielen.Zitat:
Zitat von nepomuck
Druckbare Version
Es wäre ja auch zu leicht, wenn es anders wäre :-)Zitat:
Zitat von nepomuck
Den Fehler habe ich bisher noch nicht gesucht. Werde mal 21x ZVEI Folgen einspielen.Zitat:
Zitat von nepomuck
So, ich wollte eigentlich warten mit einem Test, bis sich hier Meldungen über stabile(re) Versionen ergeben. Nun hat es mich doch in den Fingern gejuckt und ich habe mir den Tarball gezogen.
Ach ja: ich habe ein Linux am Start (alte SuSE 8.2 Version, aber sie tut!).
Nun habe ich den Tarball schön entpackt und "todesmutig" einen make gewagt. Es tut sich auch Einiges. Leider bekomme ich folgende Fehlermeldung:
Kann mir da jemand weiterhelfen? Habe ich einen Fehler gemacht?Code:gcc -c -c -D _DEBUG -O2 -I../jthread-1.2.1/src/ -I../xmlParser -I../simpleopt -I/usr/include/mysql -Wno-deprecated SocketServer.cpp -o SocketServer.o
SocketServer.cpp: In member function `virtual void* SocketServer::Thread()':
SocketServer.cpp:248: error: parse error before `||' token
SocketServer.cpp: At global scope:
SocketServer.cpp:263: error: parse error before `}' token
make[1]: *** [SocketServer.o] Fehler 1
make[1]: Leaving directory `/home/hk/2.1/monitord'
make: *** [all] Fehler 2
Gruß,
Funkwart
Den Mutigen gehört die Welt :-)
Werde mir das mal anschauen. Hatte das gestern dran gearbeitet.
[EDIT]
Bitte gehe mal in die Zeile (248) und ergänze noch zwei Runde klammern:
hinter dem if und am Ende der Zeile.
Es sollten dann
rauskommen.Code:if ((useSocket>=MAX_CLIENTS) || (useSocket<0))
Komisch, daß mein gcc das nicht auch angemeckert hat ...
SVN ist aktualisiert.
@Buebchen: Danke Dir, jetzt löppt er durch!
@jhr_online: Kannst Du bitte nochmal im ersten Beitrag Links auf die wichtigsten Dinge setzen? Es wird nämlich langsam unübersichtlich bei 17 Seiten! Mir fehlt z.B. der Link auf die aktuelle Protokollbeschreibung. Links auf die ersten Beiträge über Interfaces wie für MySQL, Crusader oder FMS32 wären ebenfalls hilfreich.
Danke und Gruß,
Funkwart
Wenn ich mich recht entsinne wurde angeregt die relevanten Teile ins Wiki zu übernehmen. Halte ich für eine super Idee. Damit habe ich mal todesmutig angefangen und lade Dich hiermit ein mitzumachen :)Zitat:
Zitat von funkwart
Ein Teil vom Protokoll ist hier: http://monitor.08k.de/index.php/Devel/Protokoll
Gruß,
Karl
Ich stimme zu. Dafür ist ein Wiki einfach besser als ein Forum.
jhr
Zwischenstand mit Build 94 sieht so aus:Zitat:
Zitat von Buebchen
Ich kapier das aber nicht ganz:Zitat:
300:1185349106:4d6f6e69746f7264:4b616e616c2032:210 40:0:756E6B6C617265204175736C2073756E67
300:1185349106:4d6f6e69746f7264:4b616e616c2032:210 40:0:756E6B6C617265204175736C2073756E67
300:1185349107:4d6f6e69746f7264:4b616e616c2032:210 40:0:756E6B6C617265204175736C2073756E67
300:1185349107:4d6f6e69746f7264:4b616e616c2032:210 40:0:756E6B6C617265204175736C2073756E67
300:1185349108:4d6f6e69746f7264:4b616e616c2032:104 21139:0:756E6B6C617265204175736C2073756E67
300:1185349108:4d6f6e69746f7264:4b616e616c2032:104 21139:0:756E6B6C617265204175736C2073756E67
300:1185349109:4d6f6e69746f7264:4b616e616c2032:211 39:0:756E6B6C617265204175736C2073756E67
300:1185349109:4d6f6e69746f7264:4b616e616c2032:211 39:0:756E6B6C617265204175736C2073756E67
300:1185349110:4d6f6e69746f7264:4b616e616c2032:210 48:0:756E6B6C617265204175736C2073756E67
300:1185349110:4d6f6e69746f7264:4b616e616c2032:210 48:0:756E6B6C617265204175736C2073756E67
300:1185349111:4d6f6e69746f7264:4b616e616c2032:210 48:0:756E6B6C617265204175736C2073756E67
300:1185349111:4d6f6e69746f7264:4b616e616c2032:210 48:0:756E6B6C617265204175736C2073756E67
300:1185349113:4d6f6e69746f7264:4b616e616c2032:210 10:1:4D656C6465726175736C6F6573756E67
300:1185349113:4d6f6e69746f7264:4b616e616c2032:210 10:1:4D656C6465726175736C6F6573756E67
....
300:1185365758:4d6f6e69746f7264:4b616e616c2032:211 93:0:756E6B6C617265204175736C2073756E67
300:1185365758:4d6f6e69746f7264:4b616e616c2032:211 93:0:756E6B6C617265204175736C2073756E67
300:1185365760:4d6f6e69746f7264:4b616e616c2032:211 93:0:756E6B6C617265204175736C2073756E67
300:1185365760:4d6f6e69746f7264:4b616e616c2032:211 93:0:756E6B6C617265204175736C2073756E67
300:1185365760:4d6f6e69746f7264:4b616e616c2032:119 31196:0:756E6B6C617265204175736C2073756E67
300:1185365760:4d6f6e69746f7264:4b616e616c2032:119 31196:0:756E6B6C617265204175736C2073756E67
300:1185365763:4d6f6e69746f7264:4b616e616c2032:211 96:0:756E6B6C617265204175736C2073756E67
300:1185365763:4d6f6e69746f7264:4b616e616c2032:211 96:0:756E6B6C617265204175736C2073756E67
300:1185365763:4d6f6e69746f7264:4b616e616c2032:211 92:0:756E6B6C617265204175736C2073756E67
300:1185365763:4d6f6e69746f7264:4b616e616c2032:211 92:0:756E6B6C617265204175736C2073756E67
300:1185365764:4d6f6e69746f7264:4b616e616c2032:211 92:0:756E6B6C617265204175736C2073756E67
300:1185365764:4d6f6e69746f7264:4b616e616c2032:211 92:0:756E6B6C617265204175736C2073756E67
300:1185365765:4d6f6e69746f7264:4b616e616c2032:119 21180:0:756E6B6C617265204175736C2073756E67
300:1185365765:4d6f6e69746f7264:4b616e616c2032:119 21180:0:756E6B6C617265204175736C2073756E67
300:1185365766:4d6f6e69746f7264:4b616e616c2032:211 80:1:4D656C6465726175736C6F6573756E67
300:1185365766:4d6f6e69746f7264:4b616e616c2032:211 80:1:4D656C6465726175736C6F6573756E67
Da lass ich tagelang den Scanner auf dem einen Dienst laufen und da rauschen lauter fehlerfreie 211*-Alarmierungen durch.
Dann schalte ich auf einen anderen Dienst eines anderen Landkreises und das hier aufgelistete 8-Ton-Phänoment tritt regelmäßig auf.
Empfang ist 1a.
Was kann das bloß sein?
Andreas
Sieht für mich so aus, als ob das immer die mittleren drei Ziffern der vorausgehenden Alarmierung sind.
Bei der "8-Ton Folge" 119 21180 zum Timestamp 1185365765 war z.B. davor 21192
Bei 104 21139 zum Timestamp 1185349108 war davor 21040.
Könnte das mit Sirenenalarm ja/nein zusammenhängen ?
Neue ZVEI-Probleme:
Ich sehe hier gerade folgende Alarmierung:
Auf die folgende (zensierte) FMS-Telegramme folgenZitat:
300:1186005241:4d6f6e69746f7264:4b616e616c2032:121 18:0:756E6B6C617265204175736C2073756E67
300:1186005241:4d6f6e69746f7264:4b616e616c2032:121 18:0:756E6B6C617265204175736C2073756E67
Das kann nicht sein. Der RTW 71/81 wird über 21181 alarmiert. Die Schleife 12118 gibt es in dem zugehörigen LKR überhaupt nicht. Hier fängt alles mit 21 an.Zitat:
310:1186005359:4d6f6e69746f7264:4b616e616c2031:A3x x7181:f:1:0:3
310:1186005366:4d6f6e69746f7264:4b616e616c2031:A3x x7181:3:1:0:3
310:1186005366:4d6f6e69746f7264:4b616e616c2031:A3x x7181:f:1:1:3
310:1186005385:4d6f6e69746f7264:4b616e616c2031:A3x x7181:f:1:0:3
Da muss es im ZVEI-Modul noch mehr Fehler, als den 8-Ton-Bug geben.
(Build 120)
Andreas
Hallo,
Ich habe zwei Probleme.
Zum einen würde ich gerne die Datenbankunterstützung deaktivieren. Geht das?
Außerdem möchte ich gerne das bei bestimmten Tonrufen ein Programm gestartet wird (was eine E-Mail verschickt, msmtp). Wie kann ich das realisieren. Habe schon ein bischen rumprobiert mit der Version 1.8.1, hat aber nicht funktioniert.
Gruß
Sascha.
Hallo,Zitat:
Zitat von s_schuh
Hat niemand eine Idee?
Gruß
Sascha.
Sorry, aber das was Du da suchst ist doch in der 1.8.1 Version alles verfügbar.
1. Datenbankunterstützung gibt es da nicht (nur nach patch)
2. Programm ausführen geht auch (siehe man-page monrc ab Punkt 9=Aktionen).
Hallo,
Erstmal hat mit der 1.8.1 das Ausführen nicht so funktioniert wie ich wollte und der monitor ist nach einer gewissen Laufzeit einfach ausgestiegen und hat sich mit einer Fehlermeldung beendet.
Deshalb wollte ich ne neuere Version probieren, die sich allerdings bei fehlender Datanbank nach der ersten Aktion mit einer Fehlermeldung beendet. Deshalb wollte ich wissen ob man in der .monrc die Datenbankunterstützung ausschalten kann.
Gruß
Sascha.
hi,
ähm ist es machbar das man für zvie genauso wie für fms den -t parameter einbaut?
so das man die schleifen an ein externes programm übergeben kann ?!
danke im vorraus.
Mal so ganz ehrlich: Ich weiss nicht, wovon Du da sprichst. Zur Zeit gibt es keinen Parameter -t für den monitord.Zitat:
Zitat von realshiva
Sicherlich könnte man das Ausführen von Skripte ermöglichen. Aber das kommt erst später.
Sofern es darum geht, daß Du deine Software um einen Auswerter ergänzen willst, wäre das doch auch nicht nötig.
Verbinde dich mit dem TCP-Socket des monitord und werte so lange aus, bis du eine passende ZVEI Folge empfangen hast. Danach kann dann dein Programm tun, was auch immer es tun möchte.
Ist das 2.0x-Redesign-Projekt schon gestorben, obwohl es so verheissungsvoll begann?
Hier passiert momentan gar nichts mehr -- zumindest nichts, was zu Topic gehören würde.
Wo ist das Protokoll, das MiThoTyN bereits vor Monaten fertig machen wollte? Wo sind die dringenden Bugfixes (8-Ton-Alarmierung, Zahlendreher etc) und die noch fehlenden Module? wo die angekündigten Clients?
Das SVN steht seit Wochen auf Build 143.
Besteht überhaupt noch Interesse an einem modularen Monitor 2.x? Oder haben alle beteiligten die Lust daran gänzlich verloren?
Andreas
Ich denke und hoffe, dass die Entwicklung bei dem einen oder anderen erstmal im provaten Bereich weitergeht, um dann ins Repository übernommen zu werden.
Vielleicht können die Herren "Chefentwickler" sich ja mal äußern.
Gruß,
Funkwart
Im Moment wird von meiner Seite aus am "mergewin-Pfad" gearbeitet. Wenn das fertiggestellt ist sind Win32 und Linux-Pfade zusammengeführt und die Arbeit an den anderen Moduln geht weiter.
Was Frontends / Clients etc angeht habe ich keine Aktien drin.
Das ist doch mal eine Aussage, mit der man arbeiten kann.Zitat:
Zitat von Buebchen
Es wäre schön, wenn die "Brot-und-Butter"-Funktionen, spricht das rohe Dekodieren von ZVEI, FMS und POCSAC möglichst schnell funktionieren, dass man dann an weiteren Details feilen kann.
Ich würde mich bereit erklären, die Arbeit am Protokoll fortzusetzen, falls Joachim keine Zeit oder Lust mehr dazu hat. Bis Mitte November habe ich zwar beruflich recht viel zu tun, kann mich danach aber intensiver der Sache widmen.
Ich bräuchte dann aber von den Seiten der Server- UND der Client-Entwicklung Inputs, was gewünschte Funktionen angeht.
Sitzt momentan einer der hier zuhörenden an der Entwicklung eines Clients? Bitte melden!
Es bestehen weiterhin Bugs bei der ZVEI-Alarmierung. Zudem ist mir bei der Sirenenprobe für den Katastrophenalerm letzte Woche aufgefallen, dass monitor den DTFM-Ton für die Katastrophenalarmierung nicht erkennt und eine Melderauslösung statt einem Sirenenalarm anzeigt.
Andreas
Der Win32 Support liegt mir sehr am Herzen - Natürlich schamlos aus persönlichem Bedarf :-)
Ansonsten sehe ich das ähnlich. Ich selbst werde weiter an den Kernfunktion mitarbeiten und versuchen sie zu verbessern. Das Frontend überlasse ich da lieber anderen. Den Ansatz mit den wxWidgets finde ich sehr gut. Wäre auch generell portabel.
Bastelt jeder jetzt im privaten weiter?
Also ich schon :-)
Wobei eben wie bei allen anderen auch die Zeit nicht soo üppig da wäre, daß ich "mal so eben" 20 Stunden pro Woche da rein stecken könnte ...
Umso mehr ein Grund, dass alle (oder ein größerer Kreis) zusammenarbeiten. Es muss doch nicht das Rad x-mal parallel neu erfunden werden!?Zitat:
Zitat von Buebchen
Das Projekt lief doch so schön an und nun trennt sich alles wieder auf... schade!
Gruß,
Funkwart
So ist es nicht gemeint, oder gewollt. Aber es macht aus meiner Sicht keinen Sinn eine Working-Copy ins SVN zu stellen, die noch nicht fertig ist. Ich frage mich nur, wer denn eigentlich noch am Projekt mitwirkt. So wirklich viel "andere" Bewegung ist aus meiner Sicht nicht mehr festzustellen. Beschäftigt sich wirklich jemand anders noch mit dem Quelltext ?Zitat:
Zitat von funkwart
Hmm... SVN bietet doch prima Möglichkeiten, um neben funktionierenden Versionen ebenfalls noch "nicht funktionierende, weil gerade dran entwickelt wird"-Versionen einzustellen - Stichwort "Tags".Zitat:
Zitat von Buebchen
Und ich halte es für wichtig, das du deine Arbeit dort ablegst - erstens kann dir evtl. der eine oder andere dann noch zuarbeiten, zweitens sieht man vielleicht, dass es vorangeht, drittens ist deine Arbeit dann "gesichert" - sprich sollte Dir oder deinem Rechner samt Backups ($Gottheit/Höhere Gewalt behüte) etwas zustoßen, so gäbe es immerhin noch die Kopie im SVN, so dass Deine Arbeit weiterführt werden könnte.
bye
Einhirn
Das mit den Backups würde schon noch gehen :-) Da müßte noch so einiges mehr in Rauch aufgehen als mein PC. Das ist einer der Vorteile, wenn man beruflich mit IT zu tun hat...Zitat:
Zitat von einhirn
Ich hatte schonmal überlegt nen tag dafür zu machen. Wobei das natürlich immer noch die Frage offen läßt, ob sich da überhaupt noch andere mit befassen werden. Werde die Tage nen branch anlegen und hochladen. Ein tag ist nach meinem Verständnis eher ein als "release" eingefrorener Versionsstand (wobei das im Zeitalter des svn technisch betrachtet genau das gleiche wie ein branch ist).
Tja, bei uns in der IT-Abteilung wird immer vermieden, dass über ein Projekt nur genau einer Bescheid weiß, und Passwörter werden an einem sicheren aber für bestimmte Mitarbeiter der IT-Abteilung zugänglichen Ort hinterlegt. Den Aufwand treiben wir - neben normalen Datenbackups - um auch für den Fall "Mitarbeiter von Omnibus überrollt, liegt jetzt glücklicherweise nicht tot, aber dummerweise mit Gedächtnisverlust im Krankenhaus" einen Ausweg haben und z.B. wichtige Systeme weiterhin gewartet werden können.Zitat:
Zitat von Buebchen
Ich warte gespannt - schließlich bin ich sehr an einem ZVEI-Decoder für Windows interessiert, den ich kostenlos erhalten kann - dafür würde ich auch mal in den Code gucken ;)Zitat:
Zitat von Buebchen
bye
Einhirn
So, branch 2.1.1-merginWinLin erstellt und meine working copy importiert.
Zur Zeit arbeite ich mit MSYS und Eclipse/CDT unter Windows XP.
./configure --enable-plugins
baut bei mir ein geeignetes Makefile. Unter Linux hatte ich - wenn ich mich nicht irre - noch ein paar Änderungen gemacht. Ich weiss nicht, ob ich die schon in der Windows working copy drin habe...
über aktive Mitarbeit würde ich mich freuen, da das ja auch ein Ansporn ist, die Sache bis zum Ende zu entwickeln ...
Hallo,
auf der Suche nach einem "simplen" ZVEI-Auswerter für unseren Betriebsfunk bin ich auf Monitor und die aktuelle Entwicklung gestoßen. Die Sourcen des 2.1.1-mergeWinLin habe ich ausgecheckt und mit MSYS kompilieren können. Das Binary ist lauffähig, seine TCP-Ports per Telnet erreichbar. Eine ZVEI-Tonfolge über das Mikrofon am Rechner auszuwerten gab jedoch nichts aus (nach Korrektur der monitord.xml -> eigene IP-Adressen als "ohne Login" eingetragen).
Bevor ich mich jetzt durch alle Sourcen wühle um den bisherigen Funktionsumfang herauszufinden: Gibt es irgendwo eine Liste der bereits implementierten Funktionalitäten des monitord und wo die echen Knackpunkte/Probleme noch vorliegen? Ich habe versucht, mir diese Infos aus den bisherigen Beiträgen dieses Threads herauszudestillieren, aber ich bin irgendwann stumpf gescheitert, wichtige Feature-Wünsche, Bugs und Fernziele von den bestehenden Features zu trennen :/. Die Sourcen sind dann doch recht umfangreich, von daher wären mir kleine "Pointer" sehr wichtig.
Für eine kurze Info darüber hier im Forum wäre ich sehr dankbar, dann wüsste ich genauer, ob und wo ich vielleicht helfen kann (oder ob nicht =)).
Viele Grüße
Martin
Welcher ZVEI Standard wird genutzt ?
In der MonitorModuleZVEI.cpp ab Zeile 80+ werden die Frequenzen der einzelnen Töne definiert. Das ist für ZVEI 1 z.Zt. richtig. Andere Normen werden damit vermutlich nicht klappen. Da wir seit langem mit POCSAG arbeiten ist da mein Wissen ein wenig verblasst :-)
Zum Testen unter windows nehme ich das BOSTool (www.gibma.de). Das erzeugt sehr "klare Töne". Mit Audacity kann man dann ja immer noch ein Rauschen beimischen.
Hallo Buebchen,
das mit dem Standard ist so ein Problem... *g*.
Wir nutzen Fünftonfolgen des ZVEI-1 (wenn ich mich recht entsinne), allerdings haben wir unsere Geräte dahingehend modifiziert, dass die Tonfolge nicht doppelt (wie vorgesehen) gesendet wird: Bei uns geht als erstes die Nummer des Gerufenen raus und dann die des Rufenden (dann sieht der Gerufene gleich, wer denn rief). Entsprechend müsste ich auch schauen, ob die Rufe in moitor einzeln oder zusammen ausgewertet werden. Danach sendet der Gerufene einen Quittungsruf (seine Kennung), ebenfalls als einfachen Fünfton.
Was ich noch gern wüsste ist: Wie weit ist denn der Funktionsumfang unter Windows mittlerweile? Ich habe mal in den Code geschaut und meinte gesehen zu haben, dass da noch keine Weitergabe der Soundbuffer an die Auswerter geht, oder habe ich nicht genau genug hingeschaut? Was kann denn der Windows-Port schon und was noch nicht?
Vielen Dank für die Antwort aber schonmal :)!
Martin
Der Windows-Port kann alles das, was die linux Version auch kann. Wobei es nicht zu 100% der Leistungsumfang des alten monitor-1.8.1 ist, da erst mit der neuen Version ein einigermassen vernünftiges Klassenkonzept dazugekommen ist.
Die ZVEI Auswertung ist ein wenig wackelig. Da wird z.T. der allererste Ruf nach dem Programmstart meist falsch erkannt. Danach ist es dann ok (bis auf einige Aussetzer).
Am besten machst Du ein paar Debug-Ausgaben im ZVEI Modul. Ich würde da mit cout einfach mal alle erkannten Ziffern ausgeben. Das müßte ja zu deiner Einspielung passen. Das ZVEI Modul achtet auch auf die Pausen. Das müßtest Du dann ggf. dann auch noch anpassen.
Übergabe der Sounddaten erfolgt übrigens in SndPipe::DataFromSoundIn() :-)
Hallo Buebchen,
erstmal herzlichen Dank, das war genau das, was mir jetzt weiterhalf :).
Ich habe festgestellt, dass unsere "gemischten" Tonfolgen problemlos erkannt und decodiert werden können, jedenfalls meistens. Auch habe ich gesehen, dass der Monitord so weit gut läuft, allerdings beim Beenden einen Fehler schmeißt (ist nicht als Dienst installiert).
Erstmal möchte ich ein herzliches Dankeschön an alle am monitor für Windows mitarbeitenden Entwickler der Vergangenheit und Gegenwart loswerden :)!
Viele Grüße
Martin
Hallo nochmal von mir,
ich habe jetzt einige Zeit in Ruhe am Code gesessen - und vor allem die demod-Methode des ZVEI-Moduls neu geschrieben.
Es waren einige Merkwürdigkeiten im Verhalten zu beobachten (unter anderem auch bei der Ausgabe, bei der Fünfton-Folgen mit führender Null gar nicht erst angezeigt wurden, da alles unter 10000 mit einem "return" abgebrochen wurde). Ich habe eine neue Logik geschrieben, die bei meinen Tests recht robust war und auch eine längere Alarmierungsfolge problemlos geschluckt und wie gewünscht ausgegeben hat. Eine "Achttonfolge" habe ich mit dem alten Code reproduzieren können, der neue brachte sie bisher nicht an die Oberfläche.
Die Auswertung des Sirenentons beruht zur Zeit lediglich auf der Auswertung der 1240Hz (obere Hälfte des Doppeltons für den Feueralarm); da war vorher ein Spezialfall definiert, der jedoch auch merkwürdige Dreckeffekte bei der generellen Auswertung der Tonfolgen brachte.
Ich achte _grob_ auf Pausen. Perfekt ist das nicht, lässt sich aber vermutlich nachrüsten. Die Pause-Geschichten liefen im mir vorliegenden Code auch nur unrund, schien mir - jedenfalls gab es da unreachable code und ein "#define Pause" vor einem "return PAUSE", dahinter dann irgendwelche Berechnungen von Pausenzeiten in der Methode "get_pause" - die flog jetzt gnadenlos raus.
Die Ausgabe-Bedingungen sind die folgenden:
a) "unklare Ausloesung" (0) bei "eine Fünftonfolge gelesen, neue Ziffer erkannt" (entsprechend der nächsten, in geringem Abstand zur vorherigen geschickten Tonfolge).
b) "Melderausloesung" (1) bei erkannter Fünftonfolge und erkanntem Melderweckton.
c) "unklare Ausloesung" (0) bei zu langer Pause nach Abschluss der Fünftonfolge aber fehlenden Melder/Sirenentönen.
d) "Sirenenausloesung" (2) bei erkannter Fünftonfolge und anschließendem Sirenenton wie oben geschrieben (NUR die 1240 Hz).
Die Fälle 1 und 2 (Melder und Sirene) ignorieren Zeitbeziehungen, sprich sie schlagen an, sobald der Weck- oder Sirenenton innerhalb der Timeout-Zeit erkannt wird. Das sollte OK sein, da der Melderton (2600 Hz, wie der Ton für die Wiederholung) nicht als erstes Zeichen stehen kann und der Sirenenton 1240 zwar der 1270 (Ziffer 3) nahe liegt aber der Abstand ausreichend groß sein müsste. Ich messe keinerlei Längen der einzelnen Töne (70ms wäre Standard für eine Frequenz/eine Ziffer), das ist entsprechend im Code kommentiert - allerdings aufgrund der Geschichte mit dem Wiederholungston auch nicht so wichtig (da nicht zweimal der selbe Ton kommen darf, wäre eine Zeitbeziehung einzubauen im Ergebnis nur der Hinweis auf einen falsch arbeitenden Sender).
Was war noch *grübel* - ach ja: Ich verbrauche jetzt möglicherweise eine Kleinigkeit mehr Speicher, da ich die Fünftonfolge in "int zvei_folge[5]" ablege statt in einem Konstrukt, auf das mit Bits geschossen wurde. Sicherlich war das elegant, macht den Code aber schwerer verständlich. Auf der anderen Seite habe ich einige Variablen gespart - ich habs nicht nachgerechnet.
Ja... Patches sind erstellt, soll ich die jemandem mailen oder selber ins SVN einpflegen (Zugang vorausgesetzt)?
Viele Grüße
Martin
Das klingt ja richtig toll. Ich denke, ein eigener Commit wäre sinnvoll. SVN Zugangsdaten gibts bei jhr-online.
Bin sehr gespannt.
Hallo,
das neue ZVEI-Modul ist von mir eben ins SVN eingecheckt worden (danke für den schnellen Zugang :)!) und sollte damit allen zur Verfügung stehen.
Die von mir geschriebene Sirenentonerkennung stellte sich bei weiteren Versuchen als wackelig heraus, auch wenn nur die 1240Hz als Trigger verwendet wurde. Der Grund dafür ist, dass die Algorithmen zur Frequenzsuche erst eine Matrix aufspannen, diese dann aber durch "find_max_index()" auf ein einzelnes, eindeutiges Zeichen heruntergebrochen wird. Die implementierten Filter für Rauschabstand und Eindeutigkeit verhindern damit die Erkennung der Sirenen-Doppeltöne. Ich werde also auch da noch Hand anlegen müssen (vermutlich werde ich die Energie der 675Hz auf die Energie des oberen Doppeltons aufaddieren, womit wieder eine eindeutige Frequenz auffindbar ist und die anderen Kontrollen weiterhin auch für den Sirenenton aktiv bleiben können).
Seit meinem letzten Posting habe ich ein paar Tests mit abgebrochenen/schlecht übertragenen/unterbrochenen/stark verrauschten Tonfolgen gemacht und noch einige Verbesserungen bezüglich der Fehlerunterdrückung eingeführt.
Nebenbei gleich noch eine andere Frage zum Ablegen/Speichern der Alarmierungen: Gibt es im monitor
a) ein SQLite-Backend?
b) ein Backend für HTTP-Anfragen (GET oder POST) zur Übergabe der Daten an einen Webserver (z.B. via http://server/store_zvei.php?folge=[abcde]&typ=[0|1|2]&time=[timestamp])?
Viele Grüße
Martin
PS: Spricht etwas dagegen, die libcurl als Library für ein HTTP-Backend zu nutzen?
Hallo Martin,
Erst einmal vielen Dank für dein Engagement bei diesem Projekt.
Ich werde den neuen ZVEI-Code gleich unter Linux gehörig stressen.
Ein paar Anregungen hätte ich noch:
Die Rettungsdienste in unserer Gegend lösen Melder generell ohne den alten Melderweckton aus. Nur wenn die Leitstelle nicht über den Computer, sondern manuell über den alten Geber alarmiert, folgt das Piepsen auf die Fünfton-Folge.Zitat:
Zitat von mdi
Die Auswertung sollte daher zwischen a) und c) unterscheiden und unterschiedliche Statusmeldungen für beide Fälle ausgeben. Ich biete euch an dieser Stelle nochmal an, das bestehende Protokoll zu überarbeiten, um diese und andere Kommandos und Statusmeldungen einzupflegen.
Wie aufwändig ist es, andere Dualton-Dekodierungen einzubauen? Neben "Feueralarm" kommen in der Praxis vor allem "Testalarmierung" und "Katastrophenalarm" zum Einsatz. Es wäre schön, wenn der monitor diese Töne erkennt und korrekt auswertet.
Noch nicht. Der unrsprüngliche Plan sah vor, SQL-Datenspeicerung über einen Client abzuwickeln -- der natürlich auf der selben Maschine laufen könnte.Zitat:
Zitat von mdi
Zwischenzeitlich haben wir über eine optionale DB-Anbindung des Backends diskutiert, um den Monitor-Clients History-Funktionen zu ermöglichen. In Sachen Code hat sich hier aber noch nichts getan.
Web-Funktionen liessen sich über ein reguläres PHP-Backend umsetzen.
Ich finde allerdings, dass der monitord-Dienst an sich so klein wie eben möglich gehalten werden sollte, so dass er auf lausigen alten PCs läuft, die ein völlig abgespecktes Linux von CD oder USB booten.
viele Grüße,
Andreas
Hallo Andreas,
gern; ich habe zur Zeit eben selber eine gehörige Portion Interesse daran und bin schon sehr angetan, auf welch breiter Grundlage man hier mitarbeiten kann :)!Zitat:
Zitat von nepomuck
Das ist gut; ich habe zur Zeit leider keine sinnvolle Möglichkeit, den "mal eben" unter Linux zu testen ohne große Aktionen machen zu müssen. Muss dringend mal wieder ein Multiboot-System einrichten ;). Feedback ist gerne genommen; meine C/C++-Programmierkünste sind ein wenig eingerostet in den letzten Jahren.Zitat:
Zitat von nepomuck
Die Geschichte mit dem Unterscheiden der beiden Fälle "unklare Auslösung" wäre vom Code her kein Problem - da sowieso unterschiedliche Stellen für die Ausgabe zuständig sind, bräuchte man nur wie Du schriebst entsprechend eine weitere Definition. Ich weiß allerdings nicht, auf welchen Argumenten die bisherige fußt!
Das ist ein wenig Aufwand aber wie geschrieben noch zu machen und alles andere als vom Tisch, wenngleich bei mir zur Zeit etwas geringer priorisiert (da ich nur die echten Fünftonfolgen brauche -> Betriebsfunk). Notwendig ist dafür die Überarbeitung der process_block()-Methode, da diese zur Zeit nur Einzelfrequenzen erkennen bzw. zurückmelden (return int Frequenz-Index) kann. Lösungsansätze habe ich schon im Kopf, allerdings wird der Eingriff etwas umfassender, weil dafür vermutlich auch die diversen Matrizen erweitert werden müssen und ich in dem Zuge gleich alle im ZVEI-Standard definierten Buchstaben (A, C, J, ...) mit einbauen wollte - vielleicht braucht sie einmal jemand (ich brauche nur das A, das ist prinzipiell schon da, wird aber noch nicht weiter behandelt). Für die Fälle der Sirenentöne müssten dann auch entsprechende Typ-Nummern vergeben und im Protokoll integriert werden (oder gibt es die schon?).Zitat:
Zitat von nepomuck
Hm, dem SVN-Inhalt nach zu urteilen gibt es bereits eine MySQL-Storage-Engine, die entsprechendes für MySQL tun könnte. Wie ist da der Stand der Dinge?Zitat:
Zitat von nepomuck
Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).Zitat:
Zitat von nepomuck
Mir schwebte vor, dass die StoreResult()-Methode in der Lage wäre, eine noch zu schreibende HTTPStorage-Engine zu nutzen, um per HTTP GET (oder auch POST, das kann man ja beliebig ausweiten) die Telegramme/Tonfolgen/... an einen Webserver zu übergeben. Das hätte in meinen Augen den Vorteil, dass diese nicht nur über eine dauerhaft bestehende TCP-Verbindung (entsprechend FMS/Crusader/monitor-Socket) erhältlich wären sondern (in der monitor.xml konfigurierbar) per HTTP an ein PHP-Skript "gepusht" werden könnten, was sie dann wie der Anwender möchte weiterverarbeitet. Oder gibt es etwas ähnliches schon und ich habe Tomaten auf den Augen, weil ich bisher nur die ZVEI-Codes angeschaut habe?
Ja, das wäre gut, keine Frage. Ist halt die Frage, ob die Einbindung von libcurl da schon ein Problem wäre oder ob nicht. Meine Tests eben (Windows only) verliefen sehr vielversprechend und würden genau meinen Wunsch von oben realisieren: Übergabe der Daten an einen Webserver zur Weiterverarbeitung mittels PHP wie auch immer gewünscht.Zitat:
Zitat von nepomuck
Viele Grüße
Martin
Ich werde auch den Ansatz der StorageModule weiter verfolgen. Einfach aus eigenem interesse - Das MySQL Modul war mal so ein Ansatz zwischendurch :-)
Vorher möchte ich aber die Kommunikation der Auswertungsmodule zu den Display und Storagemoduln nochmal überarbeiten. Ich könnte mir gut ein std::map vorstellen, daß durch das Auswertungsmodul gefüllt wird und dann an eine std::list aller StorageModule geht. Der Auswerter kann dann auch neue Daten hinzufügen, die dem StorageModul nicht schaden, wenn es sie nicht versteht.
Ein Beispiel könnte sein, daß der Auswerter folgendes liefert:
data['typ']='zvei'
data['kennung']='12345'
data['Weckton']='Sirene'
Und das Storagemodul aber nur 'typ' und 'Kennung' nutzt (weil es den Eintrag 'Weckton' noch nicht gab, als das StorageModul gemacht wurde).
Nicht so umfangreich wie XML. Aber doch flexibel und vor allen Dingen erweiterbar. Kennt das StorageModul den typ der Daten nicht, kann es ihn ignorieren. Fehlende Felder (aus Sicht des StorageModuls) hätten automatisch einen leeren Wert.
Was halten denn die anderen von dem Ansatz ?
Wobei data['Weckton'] folgende Ergebnisse liefern kann:Zitat:
Zitat von Buebchen
Ohne, Weckton, Feuer, Test, Katastrophe, Warnung, Entwarnung
Dieses Konstrukt läßt aber keinen Platz für "unklare Auslösung". Erkennt der Dekodierer einen möglichen Fehler, wenn das Signal schlecht, verzerrt oder überlagert ist?
Würde dann ein data['klare Auslösung'](Boolean)=1 (Fehlerfreie Dekodierung) oder =0 (mögliche Falsche Codefolge) Sinn machen?
Der Ansatz war hier, das monitor selbst nicht mit dem Web-Server spricht, sondern sich dieser per php aus der Datenbank bedient, die monitor füttert.Zitat:
Zitat von mdi
Bei deinem Vorhaben würde vom monitor aus direkt auf einen Webserver schreiben. Das ist eine gute Idee, aber ich würde diese Funktion lieber in einem Client-Modul sehen als direkt im monotord-Code.
Richtig. Das Problem der existierenden monitor-Version mit mysql-Engine ist nur, dass sie zu monolithisch aufgebaut ist und viele Dependencies hat. Die läuft nicht auf jedem Linux. Deshalb sind wir ja hier, um eine modulare Version zu schaffen. Der bestehende MySQL-Code liesse sich auf einem Client umsetzen.Zitat:
Zitat von mdi
@Buebchen: Wie sieht es eigentlich mit den Soundkartenfunktionen aus?
Wenn ich mich an die Überarbeitung des Protokolls mache, würde ich dabei gerne die Befehle für die Aufzeichnung integrieren. Liesse es das Backend zu, dass mehrere Tasks simultan von ein und dem selben Kanal aufzeichnen? Dann könnten mehrere Clients unabhängi voneinander Aufnehmen.
Wird es nun ein (optionales) MySQL-Modul im Backend geben oder nicht -- irgendwann müssen wir uns entscheiden.
Dann müssten nämlich die passenden Befehle ins Protokoll, wie "SendLastAlarms" oder so.
Mein Vorschlag: Wir lassen für die erste "Final" Version 2.0 von monitord und des Protokolls das SQL-Backend weg und konzentrieren uns auf die Dekodierung. Auch das Recording sollte drin sein.
Für 2.2 nehmen wir uns dann das MySQL-Backend und/oder die HTTP-Push-Engine vor.
Viele Grüße,
Andreas
So ganz zwischendurch melde ich mich zurück... Nach Umzug hat sich der Telekommunikationsdienstleister ordentlich Zeit gelassen. Ich bin aber jetzt wieder online und versuche die Mails und Forenbeiträge der letzten zwei Monate aufzuarbeiten. Ich freu mich schon den aktuellen Stand näher zu betrachten :)
jhr
Eine kurze Frage vom Nicht-C++-Entwickler::
Wenn ich das SVN auschecke: In welchem Verzeichnis muss ich dann meinen Make fahren, um die aktuelle monitord-Version für Linux mit dem neuen ZVEI-Dekoder zu erhalten.
Und was passiert, wenn ich das auf einer x86-64-Kiste mit 64-Bit-Ubunut mache?
Andreas
Hallo,
hm... dass der Dekoder eine "Signalqualität" erkennt, ist zur Zeit so gar nicht vorhanden. Wenn eine Fünftonfolge erkannt werden kann (bei jedem Wechsel des Tons gibt es ein neues Zeichen, Pausen dürfen zwischen den fünf Tönen nicht auftreten), wird diese ausgegeben. Das ist ja auch verhältnismäßig einfach zu realisieren. Wenn man eine etwas fehlertolerantere Lösung schreiben wollte, könnte man die Toleranz von Pausen in der Tonfolge einbauen (so dass z.B. von den 70ms Tonlänge grob 30ms unerkannt bleiben dürfen - generell keine schlechte Idee, so etwas sollte ich machen). Andersherum könnte man das dann vielleicht für die "Signalqualität" nutzen: Wenn weniger als 60% der eigentlichen Tonlänge eines der Töne erkannt wurden, ist das Signal "unklar"). Da stellt sich aber die Frage: Wird so etwas echt benötigt? Ja, ok, es wäre dann nur noch ein BOOL ;D.Zitat:
Zitat von nepomuck
Hm, schade. ;).Zitat:
Zitat von nepomuck
Nein; Spaß bei Seite: Grundsätzlich kann ich die Einstellung gut nachvollziehen. Für mich (aus Anwendersicht) wirkt die MySQL-Geschichte "fetter" als die HTTP-Idee. Im Monitor integriert (als Storage-Engine) hätte es den Vorteil, dass man keinen direkten Zugriff auf eine MySQL-Datenbank braucht um Daten wegzuschreiben, sondern die Daten per HTTP POST an einen Webserver liefern kann (nicht jeder Hoster bietet MySQL-Zugriff von außen an). Auch bräuchte man keinen Client, der über Netz/Sockets dauerhaft connecten muss, sondern hätte entsprechend keinerlei Ports zu öffnen und würde mit dem Monitor keinen "Server" sondern einen "HTTP-Client" aufsetzen. Das wäre auch für Paketfilter/Firewalls einfacher zu händeln. Aber das als Client-Modul (das heißt, es läuft als eigenes Programm im eigenen Prozess und verbindet sich zum Monitor über die Sockets?) zu bauen, sollte ja grundsätzlich nicht problematisch sein und hätte wiederum den Vorteil, dass keine weitere Library für den eigentlichen monitord benötigt wird.
Hier würde ich die Weiterführung des obigen Gedankens vorschlagen: Das MySQL-Modul als Client-Modul bauen und für die History SQLite nutzen (wobei das Datenbank-Design und die SQL-Queries sicher ähnlich wenn nicht gleich sind). Damit könnte der Monitor "von Hause aus" immerhin eine SQL-fähige Datenbank auf Dateibasis mit den aufgefangenen Alarmierungen füttern, die sehr einfach handhab- und auch anderweitig nutzbar ist. Auch ist kein MySQL-Server dafür notwendig, den Monitor einschließlich der History-Funktion zu nutzen. Wer dann MySQL-Unterstützung braucht, kann das MySQL-Modul einbinden und die Daten in einer eigenen Datenbank sonstwo sammeln.Zitat:
Zitat von nepomuck
Ja, ich bin begeistert von SQLite, entschuldigung ;).
Das finde ich sehr gut. Die HTTP-Push-Sache ist bereits in der Mache (basierend auf curl, ich brauche das Feature! ;)).Zitat:
Zitat von nepomuck
Da wir gerade bei der Zukunft sind: Ich habe mir gestern Abend das SVN einmal genauer angeschaut und gesehen, dass in /trunk gar nicht entwickelt wird. Stattdessen gibt es mehrere 2.x-Branches, in denen sich Dinge tun, wobei es den Eindruck macht, als würden die Branches immer wieder voneinander abstammen und "abbrechen", sobald ein neuer Branch gebaut wurde.
Da es ja auch bei der Nutzung von SVN gewisse Standards gibt, möchte ich hiermit vorschlagen, dass /trunk nach /branches/1.9.0 gemoved wird (als Archiv, damit es nicht wegkommt, quasi). Entsprechend ist /trunk dann leer und kann mit den Daten des aktuellen Branches (/branches/2.1.1-mergeWinLin) gefüllt werden, wobei dann hoffentlich keine wichtigen Änderungen aus den anderen 2er-Branches verloren gehen (gut, man könnte nochmal diff-en und nötigenfalls mergen). Damit wäre im /trunk die aktuelle Version 2.0 (ohne die 1en und das mergeWinLin am Ende - brechen wir es auf das eigentliche Ziel herunter), die dann als Feature-Set hat: Plattformunabhängigkeit, Funktionalität (Erkennung, Ausgabe über die drei Sockets in drei Formaten Crusader, FMS32, monitord).
Einen Branch/Branches für die 2.1 oder 2.2 (HTTP-Engine, MySQL-Engine, was auch immer) anzulegen, wäre dann sicher sinnvoll, sobald ein neues Feature implementiert werden soll. Ich möchte auch die Nutzung von Tags anregen, mit denen man ja ganz famos Revisionen im SVN Versionsnummern von Software aufklatschen kann, so dass nach einer Umstrukturierung wie vorgeschlagen direkt der Inhalt von /trunk in /tags/2.0-291107 als lauffähige Version markiert werden könnte und sollte, um lauffähigen Code schnell und einfach auscheckbar zu haben.
Auch möchte ich anregen, dass die tolle Entwicklung des 2er monitor ein bisschen mehr an die Öffentlichkeit kommt. Ich würde gern hier im Forum diesen Thread schließen (er wird doch arg unübersichtlich) und drei neue anfangen:
a) Der Monitor 1.9 (falls existent)
b) Der Monitor 2.0: Aktueller Stand der Entwicklung
c) Der Monitor 2.x: Ausblick
Dabei sollte b) enthalten: Verweise auf die Sourcen/das SVN, die genutzten Entwicklungsumgebungen unter Windows (MSYS/MinGW) und Linux, Protokolle, kompilierte Binaries zum Anschauen als naja, nicht nightly aber "aktueller Stand der Dinge"-Build, Informationen zu den Frontends (die ich mir ehrlich gesagt leider noch gar nicht weiter angeschaut habe).
c) sollte die Vorschläge/Planung für die nächste Version (MySQL-Storage, History-Funktion, HTTP-Push-Mechanismus) enthalten.
Eventuell sollte man auch einen Extra-Thread für die Monitor-Frontends anlegen, in denen diese kurz vorgestellt und ihre Benutzung erklärt werden. Sicherlich könnte man diese aber auch in b) mit integrieren.
Puuh... wieder viel geschrieben und "neue Ideen" eingebracht. Ich hoffe, ich verprelle damit niemanden, aber ich bin echt begeistert vom "neuen Monitor" und finde es ehrlich schade, dass der aktuelle Stand hier doch irgendwie ein Schattendasein fristet :7.
@Buebchen: Die Sache mit dem Überarbeiten der Storage-/Display-Module und dem "Übersehen" unbekannter Parameter finde ich sehr sinnvoll.
Allerdings fiel mir dazu ein: Warum sollte man nicht die Nachrichten, die von den Auswertern kommen, in eigene Objekte kapseln? Damit könnten die Nachrichtenpakete vom Typ "ZVEImsg", "POCmsg" und "FMSmsg" sein, auch wenn sie dann vielleicht nur Attribute enthalten (Datencontainer eben). Damit würde es die Ausgabe-Methoden geben "Output(ZVEImsg out)", "Output(POCmsg out)" und "Output(FMSmsg out)". Das würde auch ein ähnliches Verhalten abbilden wie Du schriebst: Zusätzliche Attribute der Datenobjekte würden zwar bestehen aber nicht ausgegeben (weil die Methode das Feld nicht kennt und eben nicht darauf zugreift - aus die Maus), ohne dass große Eingriffe in den Code (speziell die Definition der Ausgabemethoden) notwendig wären.
Viele Grüße
Martin
Hallo,
ich habe ausgecheckt: svn://jhr-online.de/monitor/monitor/branches/2.1.1-mergeWinLin (HEAD-Revision). Hier führst Du configure und make aus (also einen oberhalb von /monitord im Verzeichnisbaum). Jedenfalls tut das so unter Windows...Zitat:
Zitat von nepomuck
Martin
ast@fkl2:~/monitorsvn/monitor/branches/2.1.1-mergeWinLin$ ./configureZitat:
Zitat von mdi
configure: error: cannot run /bin/bash ./config.sub
Das passiert, obwohl ich die Dateien mit chmod +x ausführbar gemacht habe.
Ich habe mit config.sub angesehen und festgestellt, dass die Textzeilen mit <0d><0a> enden (Windows-Like "CR+LF") statt wie unter Linux üblich mit <0a> "LF" alleine.
Für den Interpreter lautet die erste Zeile von config.sub daher "#1/bin/sh^M" und das geht nicht.
Auch die geänderten Sourcecode-Dateien haben den falschen Linefeed drin -- ich weiss nicht, wie der Compiler darauf reagiert.
Kannst du das in deinem Editor korrigieren und die von dir veränderten Dateien nochmal mit <0d> "LF" alleine einstellen?
Danke,
Andreas
ich habe die ZVEI-Sourcen geändert. An der config.sub habe ich nicht geschraubt; es gibt aber auch das Tool dos2unix oder unix2dos - das macht das auch. :).Zitat:
Zitat von nepomuck
Martin
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 ?Zitat:
Zitat von mdi
Kann ich nur unterstützen. Sofern nichts dagegen spricht werde ich mit jhr-online absprechen, daß wir mal umsetzen. Ich habe auch schon nem Test-PC ohne drauf zu achten den trunk ausgecheckt und war doch etwas verwundert...Zitat:
Zitat von mdi
Kann ich auch so unterstützen.Zitat:
Zitat von mdi
Details zur Umsetzung sind noch ganz offen. Ich denke der Datentyp map<std::string,std::string> hat halt den Charme, daß man ihn wie ein PHPArray ansprechen kann. Das ganze kann ja dann auch Element einer der Klasse wie bei Dir beschrieben sein. Das ganze dann von einer BASEmsg abgeleitet könnte doch recht zukunftssicher sein.Zitat:
Zitat von mdi
Ob drei Ausgabemodule mehr oder weniger Sinn machen als eine einzelne Output-Funktion muss ich mal überlegen.
Um's nicht zu kompliziert zu machen:
Ich bin voll einverstanden und übergebe hiermit mal ausdrücklich buebchen die ehrenwerte Aufgabe, die Änderungen durchzuführen. Vielleicht sollten die Schreiberlinge kurz vom svn die Finger lassen bis buebchen hier die Durchführung bekannt gibt.
Okay?
jhr
trunk ist jetzt die 2.1.1-merginwin.
Die alten branches habe ich in den Ordner branches/discontinued verschoben.
Der alte trunk ist jetzt tags/1.9.0
Hab ich jetzt noch was vergessen ?
Eine kurze, organisatorische Bitte:
Da Ihr offensichtlich gerade mehr unter Windows als unter Linux am Entwickeln seid, fehlt sämtlichen Skripten im SVN das Executable-Flag. Wer den Code unter Linux übersetzen will, muss zunächst einmal in alle Dateien reinschauen und herausfinden, was per chmod +x umgestellt werden muss..
Könntet Ihr bitte alle ausführbaren Skripte so umbennennen, dass sie auf ".sh" enden. Dann genügt es, ein einziges "chmod +x *.sh" zu fahren.
Danke,
Andreas