monitor 1.9.0 - aber richtig :) [Archiv] - Seite 2

nepomuck

25.07.2007, 20:02

Den Fehler habe ich bisher noch nicht gesucht. Werde mal 21x ZVEI Folgen einspielen.
Zwischenstand mit Build 94 sieht so aus:

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

Ich kapier das aber nicht ganz:
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

Buebchen

25.07.2007, 23:03

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 ?

nepomuck

02.08.2007, 00:22

Neue ZVEI-Probleme:

Ich sehe hier gerade folgende Alarmierung:

300:1186005241:4d6f6e69746f7264:4b616e616c2032:121 18:0:756E6B6C617265204175736C2073756E67
300:1186005241:4d6f6e69746f7264:4b616e616c2032:121 18:0:756E6B6C617265204175736C2073756E67

Auf die folgende (zensierte) FMS-Telegramme folgen

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

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.

Da muss es im ZVEI-Modul noch mehr Fehler, als den 8-Ton-Bug geben.
(Build 120)
Andreas

s_schuh

06.09.2007, 10:33

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.

s_schuh

08.09.2007, 18:24

Buebchen

09.09.2007, 22:41

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

s_schuh

09.09.2007, 23:18

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.

realshiva

10.09.2007, 06:13

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.

Buebchen

16.09.2007, 17:55

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.

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.

nepomuck

25.09.2007, 22:57

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

funkwart

26.09.2007, 10:36

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

Buebchen

26.09.2007, 11:16

nepomuck

26.09.2007, 13:27

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.

Das ist doch mal eine Aussage, mit der man arbeiten kann.
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

Buebchen

26.09.2007, 23:53

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.

A.Nero

30.10.2007, 19:54

Bastelt jeder jetzt im privaten weiter?

Buebchen

31.10.2007, 11:41

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

funkwart

01.11.2007, 11:14

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!?
Das Projekt lief doch so schön an und nun trennt sich alles wieder auf... schade!

Gruß,
Funkwart

Buebchen

01.11.2007, 11:35

Umso mehr ein Grund, dass alle (oder ein größerer Kreis) zusammenarbeiten. Es muss doch nicht das Rad x-mal parallel neu erfunden werden!?
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 ?

einhirn

14.11.2007, 18:45

[...]Aber es macht aus meiner Sicht keinen Sinn eine Working-Copy ins SVN zu stellen, die noch nicht fertig ist. [...]
Hmm... SVN bietet doch prima Möglichkeiten, um neben funktionierenden Versionen ebenfalls noch "nicht funktionierende, weil gerade dran entwickelt wird"-Versionen einzustellen - Stichwort "Tags" (http://svnbook.red-bean.com/en/1.4/svn.branchmerge.tags.html).

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

Buebchen

15.11.2007, 01:09

Hmm... SVN bietet doch prima Möglichkeiten, um neben funktionierenden Versionen ebenfalls noch "nicht funktionierende, weil gerade dran entwickelt wird"-Versionen einzustellen - Stichwort "Tags" (http://svnbook.red-bean.com/en/1.4/svn.branchmerge.tags.html).

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

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

einhirn

15.11.2007, 15:40

[...]Da müßte noch so einiges mehr in Rauch aufgehen als mein PC. [...]

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.

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

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 ;)

bye
Einhirn

Buebchen

15.11.2007, 19:18

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

mdi

16.11.2007, 16:30

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

Buebchen

17.11.2007, 22:42

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.

mdi

19.11.2007, 18:53

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

Buebchen

19.11.2007, 19:23

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

mdi

22.11.2007, 01:54

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

mdi

23.11.2007, 03:10

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

Buebchen

24.11.2007, 23:07

Das klingt ja richtig toll. Ich denke, ein eigener Commit wäre sinnvoll. SVN Zugangsdaten gibts bei jhr-online.

Bin sehr gespannt.

mdi

25.11.2007, 16:48

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?

nepomuck

28.11.2007, 13:15

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:

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

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.

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

Noch nicht. Der unrsprüngliche Plan sah vor, SQL-Datenspeicerung über einen Client abzuwickeln -- der natürlich auf der selben Maschine laufen könnte.

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

mdi

28.11.2007, 16:11

Hallo Andreas,

Erst einmal vielen Dank für dein Engagement bei diesem Projekt.

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 :)!

Ich werde den neuen ZVEI-Code gleich unter Linux gehörig stressen.

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.

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!

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.

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

Noch nicht. Der unrsprüngliche Plan sah vor, SQL-Datenspeicerung über einen Client abzuwickeln -- der natürlich auf der selben Maschine laufen könnte.

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?

Web-Funktionen liessen sich über ein reguläres PHP-Backend umsetzen.

Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).
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?

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.

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.

Viele Grüße
Martin

Buebchen

28.11.2007, 23:10

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 ?

nepomuck

29.11.2007, 10:37

Ein Beispiel könnte sein, daß der Auswerter folgendes liefert:
data['typ']='zvei'
data['kennung']='12345'
data['Weckton']='Sirene'

Wobei data['Weckton'] folgende Ergebnisse liefern kann:
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?

Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).

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

Hm, dem SVN-Inhalt nach zu urteilen gibt es bereits eine MySQL-Storage-Engine, die entsprechendes für MySQL tun könnte.

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.

@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

jhr-online

29.11.2007, 11:32

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

nepomuck

29.11.2007, 14:05

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

mdi

29.11.2007, 15:13

Hallo,

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?

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.

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

Hm, schade. ;).
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.

@Buebchen:
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.
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.
Ja, ich bin begeistert von SQLite, entschuldigung ;).

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.

Das finde ich sehr gut. Die HTTP-Push-Sache ist bereits in der Mache (basierend auf curl, ich brauche das Feature! ;)).

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

mdi

29.11.2007, 15:18

Hallo,

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.

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

Martin

nepomuck

29.11.2007, 15:45

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

ast@fkl2:~/monitorsvn/monitor/branches/2.1.1-mergeWinLin$ ./configure
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

mdi

29.11.2007, 15:56

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?

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

Martin

Buebchen

30.11.2007, 00:01

Hallo,
[...viel Text:-) ]

Ja, ich bin begeistert von SQLite, entschuldigung ;).

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 ?

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

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

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.

Kann ich auch so unterstützen.

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

Ob drei Ausgabemodule mehr oder weniger Sinn machen als eine einzelne Output-Funktion muss ich mal überlegen.

jhr-online

30.11.2007, 10:17

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

Buebchen

30.11.2007, 12:35

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 ?

nepomuck

30.11.2007, 12:46

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

nepomuck

30.11.2007, 13:06

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

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:

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

mdi

30.11.2007, 13:16

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

mdi

30.11.2007, 14:37

Hallo,

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

Buebchen

30.11.2007, 22:53

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

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

Buebchen

03.12.2007, 15:22

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)

mdi

03.12.2007, 21:52

Buebchen

03.12.2007, 23:11

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 :-)

nepomuck

05.12.2007, 15:15

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

Buebchen

05.12.2007, 15:57

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

mdi

05.12.2007, 17:01

Hallo,

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

nepomuck

06.12.2007, 17:28

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

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

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

nepomuck

06.12.2007, 18:11

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

SirFS

06.12.2007, 22:57

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.

nepomuck

06.12.2007, 23:19

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

Buebchen

08.12.2007, 16:40

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

Buebchen

08.12.2007, 18:35

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.

nepomuck

09.12.2007, 21:25

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.

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

Buebchen

09.12.2007, 21:43

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:-)

nepomuck

09.12.2007, 23:17

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.

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.

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

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:

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?

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

Buebchen

10.12.2007, 16:20

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) ?

MacLeod

10.12.2007, 18:16

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

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

Buebchen

10.12.2007, 22:54

Den Fehler

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.

MacLeod

11.12.2007, 14:04

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

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*

nepomuck

11.12.2007, 14:34

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

nepomuck

11.12.2007, 15:26

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

MacLeod

11.12.2007, 18:43

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:

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

mdi

11.12.2007, 18:50

Hallo,

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

nepomuck

11.12.2007, 23:45

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.

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.

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

Ich schicke dir einen Link.

Andreas

Buebchen

11.12.2007, 23:52

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:

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.

nepomuck

12.12.2007, 00:24

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.

???

mdi

12.12.2007, 01:43

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

funkwart

12.12.2007, 07:54

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

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!

Trotzdem schonmal danke und Gruß,
Funkwart

;-)

MacLeod

12.12.2007, 13:56

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

MacLeod

12.12.2007, 16:32

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.

mdi

13.12.2007, 13:48

Moinmoin,

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.

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

Buebchen

13.12.2007, 16:37

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

MacLeod

13.12.2007, 17:11

make geht nicht mehr... ???

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$

mdi

13.12.2007, 18:10

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 :)!

Buebchen

13.12.2007, 19:01

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

MacLeod

13.12.2007, 19:52

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

nepomuck

13.12.2007, 22:09

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 :-)

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.

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

was habt ihr denn als frontend angeschlossen?

Noch gibt es kein Frontend. Bislang arbeite ich mit

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.

mdi

13.12.2007, 22:15

Hallo,

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

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.

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.

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.

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

einhirn

14.12.2007, 09:42

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:

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

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

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/svn.tour.cycle.html#svn.tour.cycle.resolve (Direktlink zur Konfliktlösung)

bye
Einhirn

nepomuck

15.12.2007, 00:05

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

Buebchen

15.12.2007, 00:23

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

MacLeod

15.12.2007, 12:12

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

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*

Buebchen

16.12.2007, 19:23

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

nepomuck

16.12.2007, 22:31

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

Buebchen

16.12.2007, 23:24

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

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.

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:

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.

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.

nepomuck

17.12.2007, 00:26

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

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.

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.

(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"?

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.

Die 320 ist jetzt in 320 geändert

das ändert alles :-)

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.

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

Buebchen

17.12.2007, 12:00

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.

Der Gedanke ist, daß der Client dem User anzeigen kann,wie lange er noch auf die Datei warten muss bis sie fertig ist. Wenn zwei Benutzer eine Aufnahme mit unterschiedlichen Aufnahemdauern auslösen kann sich die anfängliche Aufnahmedauer verändern. Das weiss der erste Client aber dann nicht und versucht die Datei zu öffnen, obwohl sie noch im Zugriff ist.

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"?

Ist schon in Arbeit. Bisher war der Pfad fest auf die SVN Ordner verknüpft, da es auch noch kein Install dazu gibt.

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.

Hmm. Dann müßte ich unter Windows die Kartennummer anders hinterlegen (Windows nutzt primär die Gerätenummer, nicht seinen Namen. Würde aber gehen. Werde ich mal Testweise umbauen.

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?

Ich sende dann ein ":" ohne nachfolgenden Text.

nepomuck

17.12.2007, 12:25

Wenn zwei Benutzer eine Aufnahme mit unterschiedlichen Aufnahemdauern auslösen kann sich die anfängliche Aufnahmedauer verändern. Das weiss der erste Client aber dann nicht und versucht die Datei zu öffnen, obwohl sie noch im Zugriff ist.

Hä?
Wenn zwei getrennte Clients ein REC-Kommando absetzen, erstellt der monitord auch zwei getrennte Files. Wenn also Client 1 die Aufzeichnung verlängert, betrifft das nicht die Aufzeichnung von Client 2.
Jeder Client weiss daher, dass die Aufzeichnung nach Ablauf seiner Zeitvorgabe zzgl. Zeit für die Umwandlung von raw nach wav oder mp3 fertig sein muss. Eine Zwischenzeitangabe nützt dem Client nichts, da der monitord die Umwandlungszeit von sox/lame nicht vorhersagen kann. Damit wäre die Zeitangabe auch nur eine bessere Schätzung.

Warum sollte der Client ausserdem versuchen, auf die Datei zuzugreifen, bevor er den passenden 104 erhalten hat? Ich würde im Client eine Eventsteuerung einbauen, die den 104 abwartet und dann die REC-Datei per FTP/NFS/CIFS auf den Client holt.

Ich sende dann ein ":" ohne nachfolgenden Text.
So im Protokoll vermerkt.

viele Grüße,
Andreas

Buebchen

17.12.2007, 13:44

Mit dem 104:0 Status macht natürlich Sinn. Erst ab dann ist die Aufnahme verfügbar. Jetzt aber zum Haken an der Sache. Pro Kanal wird im Moment nur eine Aufnahme laufen. Diese wird mit einem 104:2: Kommando nach Angabe des letzten Clients verlängert. Das teilt monitord dann auch per 104:2 Kommando allen zur Zeit aufnehmenden Clients mit.

Dann habe ich den Parameter 104:2 falsch interpretiert. Werde mal sehen, ob sich das auch mit einzelnen Aufnahmen realisieren läßt.

nepomuck

17.12.2007, 14:16

Das teilt monitord dann auch per 104:2 Kommando allen zur Zeit aufnehmenden Clients mit.

Es macht wenig Sinn, wenn ein Client erfährt, dass ein anderer was aufnimmt. Im Zweifelsfalle geht den Client der betreffende Kanal nicht einmal etwas an. In kommenden Versionen könnte (sollte) es auch eine User-Policy per Kanal geben, so dass nicht jeder Benutzer auch jeden verfügbaren Kanal abhören und auswerten darf.

Ich dachte, der monitord reicht kontinuierlich Datenblöcke von der Soundkarte durch einen Puffer, so dass sich mehrere REC-Tasks simultan daraus bedienen und daher völlig unabhängig voneinander aufnehmen können. Schliesslich greifen ja auch mehrere Auswerter simultan auf den Datenbestand zu.

viele Grüße,
Andreas

Buebchen

17.12.2007, 16:21

Es macht wenig Sinn, wenn ein Client erfährt, dass ein anderer was aufnimmt. Im Zweifelsfalle geht den Client der betreffende Kanal nicht einmal etwas an. In kommenden Versionen könnte (sollte) es auch eine User-Policy per Kanal geben, so dass nicht jeder Benutzer auch jeden verfügbaren Kanal abhören und auswerten darf.

Ich dachte, der monitord reicht kontinuierlich Datenblöcke von der Soundkarte durch einen Puffer, so dass sich mehrere REC-Tasks simultan daraus bedienen und daher völlig unabhängig voneinander aufnehmen können. Schliesslich greifen ja auch mehrere Auswerter simultan auf den Datenbestand zu.

viele Grüße,
Andreas
Es ist schon so, daß pro Kanal aufgezeichnet wird (also Mono). Auch getrennte Kanäle in Unterschiedliche Dateien. Pro Kanal ist zur Zeit aber immer nur exakt eine Aufnahme aktiv. Der Hintergrund ist einfach der, daß sonst noch massiver Multitasking nötig wird.

Wenn also ein Client A den Kanal 3 aufzeichnet hat das nichts damit zu tun (und er wird darüber auch nicht in Kenntnis gesetzt) wenn ein Client B den Kanal 1 aufzeichnet.

Kommt aber nun Client C und will den Kanal 3 aufzeichnen erhält er den gleichen Dateinamen wir Client A. Die Aufnahme wird ggf. entsprechend verlängert, wenn A's Aufnahme zu kurz wäre. Dann erhalten beide die Info 104:2 und auch 104:0. Das meinte ich mit alle. Nicht unbeteiligte Clients.

Disk I/O ist relativ langsam. Ich wollte das nicht zu weit ausbreiten. Einige wollen den monitord auf leistungsschwachen Maschinen einsetzen. Grundsätzlich könnte ich aber sicherlich auch mehrere Dateien innerhalb eines Kanals aufzeichnen. Muss ich aber schreiben. Da Weihnachten naht ist meine Zeit etwas knapp ...

Strukturell gibt es nicht pro Auswerter einen Thread - Nur pro Karte. Die Daten werden nacheinander an die Auswerter vergeben. Danach gehen die Daten dann an die AudioPlugins. Aber alles von einem Thread aus bedient. Ja, ich weiss. Man könnte da ganz toll was mit ThreadPools und WorkerThreads machen ... Wäre was für die Version 2.2 oder so :-)

nepomuck

17.12.2007, 18:06

Kommt aber nun Client C und will den Kanal 3 aufzeichnen erhält er den gleichen Dateinamen wir Client A. Die Aufnahme wird ggf. entsprechend verlängert, wenn A's Aufnahme zu kurz wäre. Dann erhalten beide die Info 104:2 und auch 104:0. Das meinte ich mit alle. Nicht unbeteiligte Clients.

Kapiert!
Das kann aber dazu führen, dass ein Client zur Not Minuten oder gar Stundenlang auf seine Aufzeichnung warten muss und dann ein Monster-File erhält.
(Der Kyrill-Tag war ein solcher Extremfall, da ging alle paar Minuten ein Alarm raus)

Vorschlag:
Wir belassen es bei einem Thread pro Kanal für die Aufzeichnung. Der Segmentiert dafür die Aufzeichnung in Blöcke (pro 10 Sekunden ein RAW-File). Vor der Auslieferung an den Client übergibt monitord die Liste der Blöcke an sox, das daraus ein .wav- oder .mp3-File zusammenbaut.
Will ein weiterer Client während einer laufenden Aufzeichnung REC auslösen, läuft der Aufzeichnungs-Thread einfach weiter, monitord merkt sich die Nummern der RAW-Blöcke und denkt sich schon mal einen neuen Namen für den anderen Client aus..
Damit erzeugen wir eine Art pseude Multithread-Aufzeichnung ohne dabei aber die Systemlast zu steigern.
Theoretisch können dutzende verschiedener Clients simultan aufzeichnen so dass jeder seine eigene Datei erhält aber nur ein REC-Thread pro Kanal läuft.

Läßt sich das ohne große Probleme im Code umsetzen?

viele Grüße,
Andreas

Buebchen

17.12.2007, 18:41

Will ein weiterer Client während einer laufenden Aufzeichnung REC auslösen, läuft der Aufzeichnungs-Thread einfach weiter, monitord merkt sich die Nummern der RAW-Blöcke und denkt sich schon mal einen neuen Namen für den anderen Client aus..
Damit erzeugen wir eine Art pseude Multithread-Aufzeichnung ohne dabei aber die Systemlast zu steigern.
Theoretisch können dutzende verschiedener Clients simultan aufzeichnen so dass jeder seine eigene Datei erhält aber nur ein REC-Thread pro Kanal läuft.

Läßt sich das ohne große Probleme im Code umsetzen?

viele Grüße,
Andreas

Ööööh ... Nö :-)

Ich denke, ich werde pro REC Modul eine Liste von Dateien pflegen, die parallel geschrieben werden. Dann braucht der Datenblock nur einmal aufbereitet zu werden und wird dann in die einzelnen Dateien geschrieben. Muss nur angepasst werden, daß Client und Datei nicht verwechselt werden :-)

Ich habe nur Sorge, daß die Bearbeitungszeit für einen Datenblock länger ist, als es dauert der nächste Datenblock von der Soundkarte kommt. Dann müßte ich doch noch eine Queue für die Datenpakete machen. Sonst gehen Daten verloren und die Auswerter und/oder Datei bekommt unvollständige Tondaten (Nicht umsonst hat FMS32 diesen Soundkartenreset drin. Ich vermute, genau wegen solcher Probleme)

[Edit]:
Funktion ist jetzt geändert. In der nächsten Version sollte man das nochmal überarbeiten. Nicht alles so richtig hübsch. Aber egal. Die Funktion macht bei ersten Test zumindest keinen Absturz.

Die Dateinamen sehen jetzt so aus:
{Datum-Uhrzeit}_{Kanalnummer}_{jobID}.raw

Bsp:
20071217230000_0_2.raw

Alles ganz frisch. Bei mir klappt es soweit schon. Wer mag kann ja mal rev.230 austesten. Der Pfad zum Plugin kann jetzt auch im monitord.xml definiert werden. Siehe Datei im SVN.

Buebchen

19.12.2007, 22:40

Hat jemand mehr als eine Soundkarte ? Insbesonder unter Windows würde es mich interessieren , ob das in der Auswertung fehlerfrei läuft. Die SocketThreads kriegen davon noch nicht so viel mit, der Client dementsprechend auch noch nicht.

Windows interpretiert die Device Defintion von Linux in der monitord.xml nun als Gerätenummer. Also

/dev/dsp0 = Erste Soundkarte
/dev/dsp1 = Zweite Soundkarte
/dev/dsp2 = Dritte Soundkarte
/dev/dsp3 = Vierte Soundkarte

Ich habe ausserdem noch einen Support für lame implementiert. Damit kann man direkt in mp3 aufzeichnen. Das geht zwar, ist aber etwas kniffelig zu installieren. Das muss ich mal in einer ruhigen Minuten dokumentieren, bzw. mal als Beispiel darstellen.

Zumindest die configure Option gibt es schon. Muss mich aber mal mit autoconf befassen, wie nun automatisch den Pfad zu den DLLs, bzw. .so's finde (oder deren Existenz abklären kann).

[Edit]
Nachtrag: rev. 233 im SVN ist gemeint.

nepomuck

19.12.2007, 23:07

Nachtrag: rev. 233 im SVN ist gemeint.

Upgedated; make clean; chmod +x config*; ./configure --enable-plugins; make

passiert folgendes:

...
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'virtual void MonitorAudioPlugInRecorder::ProcessAudio(float*, int)':
monitord/plugins/libmplugin_audiorecorder.cpp:211: warning: comparison between signed and unsigned integer expressions
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'void MonitorAudioPlugInRecorder::StartRecording(int, std::string, int)':
monitord/plugins/libmplugin_audiorecorder.cpp:275: error: cast from 'MonitorAudioPlugInRecorder*' to 'int' loses precision
monitord/plugins/libmplugin_audiorecorder.cpp:293: warning: converting to non-pointer type 'long int' from NULL
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'virtual std::string MonitorAudioPlugInRecorder::DoCommand(std::string, SocketThread*)':
monitord/plugins/libmplugin_audiorecorder.cpp:354: warning: comparison between signed and unsigned integer expressions
monitord/plugins/libmplugin_audiorecorder.cpp:359: warning: converting to non-pointer type 'long int' from NULL
make[1]: *** [monitord/plugins/monitord_plugins_libmplugin_audiorecorder_la-libmplugin_audiorecorder.lo] Fehler 1
make[1]: Verlasse Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
make: *** [all] Fehler 2

2. Versuch ohne Plugins:
make clean; ./configure; make

make all-am
make[1]: Betrete Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
g++ -DHAVE_CONFIG_H -I. -Ijthread-1.2.1/src -D_DEBUG -Wall -pedantic -g -O2 -MT monitord/monitord_monitord-Monitor.o -MD -MP -MF monitord/.deps/monitord_monitord-Monitor.Tpo -c -o monitord/monitord_monitord-Monitor.o `test -f 'monitord/Monitor.cpp' || echo './'`monitord/Monitor.cpp
monitord/Monitor.cpp: In member function »void Monitor::InitSndCard()«:
monitord/Monitor.cpp:203: Fehler: »class CSndPipe« hat kein Element namens »loadPlugins«
make[1]: *** [monitord/monitord_monitord-Monitor.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
make: *** [all] Fehler 2

Plattform: Athlon X2 mit Ubuntu 7.10 64-Bit.

any Ideas ?

Andreas

Buebchen

19.12.2007, 23:19

Hmm. Im oberen build sehe ich nur warnings. Die sind soweit auch ok.

Den Fehler im untern Build habe ich vermutlich schon behoben. Fehlte ein #define.
-> Rev.234 (#define in Monitor.cpp)
-> Rev.235 (#define in CSndPipe.cpp)

Den oberen Teil schau ich mir noch mal an.

[Edit]
Ah. War Blind. Habe den error jetzt gesehen. Schau mich mir an.
[Edit2]
Fehler im ersten Build liegt vermutlich am 64Bit System. Die Zeile kann ich aber bedenkenlos streichen, da sie nur für die ersten Debug Aufnahmen wichtig war.

-> Rev. 236 (pointer cast nach int geht unter 64Bit nicht)

nepomuck

20.12.2007, 00:15

Rev. 236
Läuft mit Plugin.
Anmerkung:

104:0:1:rec/20071220001130_0_0.raw
Soll 104 den Dateinamen mit oder ohne Pfad zurückliefern?
Eigentlich ist der Dateiname ein Textfeld und somit in HEX zu codieren.

Edit!
Noch ein großes Problem:
Wenn ich über den Client (telnet localhost 9333) ein paar verschachtelte 204 absetze, bleibt der Client hängen. Die Debug-Anzeige des monitord zeigt an, dass der weiter auswertet, aber beim Client kommt nichts mehr an. Der monitord nimmt auch über die Client-Sitzung keine Kommandos mehr an.
Den 104 übermittelt er aber und dann kann es sein, dass alles wieder geht, oder das nichts geht oder dass Kommandos wie 299 angemommen werden aber die Alarmierungen nicht durchkommen.

viele Grüße,
Andreas

Buebchen

20.12.2007, 11:10

Hex kommt. Die Verschachtelung wird tatsächlich noch nicht laufen. Da ist das alte Konzept noch nicht umgestellt (Alle Clients machen nur eine Aufnahme).

Buebchen

20.12.2007, 23:17

Die verschachtelten Kommandos gehen nun. Tatsächlich stürzte nichts ab. Er wartete aber bis die erste Aufnahme zu Ende war, um die nächste dann zu starten :-)

Die Pfadangabe wird nun in Hexadezimaler Schreibweise ausgegeben. Ich würde sagen, daß wir den Pfad mit angeben. Man den Pfad pro Kanal einstellen (monitord.xml).

Im neuen SVN rev.237

Damit der mp3 Support auch schon mal vorsichtig gestestet werden kann habe lame-3.97 dem Repository hinzugefügt. Bleibt am Ende nur noch folgendes zu tun:

lame erstellen (configure im lame-3.97 Ordner)

monitor: configure --enable-plugins --enable-lame

Windows:
Die libmp3lame-0.dll in den monitord Ordner kopieren

Linux:
den LD_LIBRARY_PATH so anpassen, daß die libmp3lame.so gefunden und geladen werden kann.

Zusätzlich noch den Pfad zum plugin (libmplugin_audiorecorder-0.dll, bzw. libmplugin_audiorecorder.so.0.0.0 )in der monitord.xml prüfen.

Danach sollte er beim Start des monitord die Version der LAME Library ausgeben. In dem Fall dann 3.97:

Start Karte 0
DFromSoundIn ist: 4354368
Links
---------
Plugin-File:0=plugins/.libs/libmplugin_audiorecorder-0.dll
Plugin# 0: lade dll (Audio) aus Datei: plugins/.libs/libmplugin_audiorecorder-0.dll
done
PlugIn Audiorecorder created
enabling lame mp3 support
LAME Library imported
Using LAME Version: 3.97

Rechts
---------
Geraetenummer: 0

nepomuck

26.12.2007, 12:12

den LD_LIBRARY_PATH so anpassen, daß die libmp3lame.so gefunden und geladen werden kann.

Ich habe auf meinem Testsystem bereits lame installiert. Ich habe in /usr/lib eine libmp3lame.so.0.0.0 und einen symbolischen Link darauf namens libmp3lame.so.0.

Eigentlich sollte ich die nutzen können, oder? Ich habe einen link angelegt:

ln -s /usr/lib/libmp3lame.so.0.0.0 /home/ast/monitorsvn/trunk/monitord/libmp3lame.so

Aber das funzt nicht.

Irgendwelche Vorschläge?

weihnachtliche Grüße vom frischen Papa.
Andreas

Buebchen

26.12.2007, 20:07

Ich würde das vorläufig erstmal auf Eis legen. Ich überarbeite den Teil, wie externe DLLs gelinkt werden. Die Autotools sind da nicht so trivial, wie ich das erwartet hatte. Inzwischen kann ich nachgeordnete DLLs automatisch nachladen lassen (early binding). Muss das ganze aber noch abrunden.

Ausserdem haben frische Papas ja auch noch andere Aufgaben ;-)

Buebchen

30.12.2007, 20:43

Ich hätte doch nochmal ne ganz andere Frage zum monitord:

Unter welcher Lizenz werden wir den denn eigentlich fortführen ? GPLv2 oder GPLv3 ? Ich würde die GPL v3 vorschlagen.

Ich schreibe gerade ein kleines Nullsoft Installer File. Da würde ich dann auch gerne schonmal eine Lizenz hinzufügen.

Wie wäre denn dieser Kopf:

The monitord program is released under the GPL v3

* monitord is based on monitor by Markus Grohmann (GPL v2)
http://www.monitor.mgrohmann.de
(C) 1998-2002 (markus_grohmann@gmx.de)
* monitor is based on multimon by Thomas Sailer (GPL v2)
http://www.baycom.org/~tom/ham/linux/multimon.html
(C) 1996,Thomas Sailer (sailer@ife.ee.ethz.ch, hb9jnx@hb9w.che.eu)

the monitord development team
http://www.monitord.de, (C)2007

GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007

jhr-online

30.12.2007, 22:41

Das klingt für mich grundsätzlich gut. Wir sollten dann aber, wenn wir die Domain schon einbauen, bald auch da was stehen haben. :)
Ich bin mit GPLv3 aber sehr einverstanden.

jhr

mdi

01.01.2008, 19:50

Moin,

nachdem nun der Weihnachtsstress und die darauf folgende ziemlich eklige Erkältung (blöder Mist) so halbwegs erledigt sind, melde ich mich auch mal wieder zu Wort: Ich bin noch da ;D.

Nein, Scherz bei Seite; neben dem Neujahrswunsch an alle möchte ich loswerden, dass ich mittlerweile so weit mit meinem CMS bin, dass (z.Zt. MySQL-basierter) Login/Sessions komplett funktional sind (ja, man bekommt eine Login-Seite, wenn man den direkten URL zu einem gesicherten Inhalt einträgt, und auch die Navigation zu "sicheren" Seiten wird nicht angezeigt, wenn man nicht eingeloggt ist), Inhalte allerdings noch immer per FTP gepflegt werden müssen.
Das wird sich noch ändern, allerdings scheint mir nach den Postings hier vorrangig, die Inhalte zu erstellen. Entsprechend werde ich mich in der nächsten Zeit ersteinmal damit befassen, so dass ich hoffentlich hm... sagen wir Mitte Januar (10. wäre früh, ich halte den 15. für realistisch, da ich noch einen kirchlichen Neujahrsempfang, ein Homepage-Projekt für einen Verein und ein Jahresabschluss-Treffen für einen anderen Verein zu beharken habe) mal was zum Zeigen anbieten kann. Ich halte (leider) relativ wenig von Previews dahingehend, aber sollte jemand nicht mit dem zufrieden sein, was ich dann verbastelt habe, ist fundierte Kritik kein Problem und meine Arbeit am CMS nicht umsonst :)!

Viele Grüße
Martin

Buebchen

02.01.2008, 00:19

@mdi:
Schön zu hören, daß das CMS vielleicht schon in wenigen Tagen an den Start gehen könnte.

@nepomuck:
Du hast geschrieben, daß Du schon lame installiert hast. Wo liegen dann dann bei Dir die lame.h ? /usr/include/lame/lame.h ? Mir geht es darum, ob ich im Programm nur "lame.h" includen soll oder besser "lame/lame.h".

Ansonsten steht eine neue Version im SVN bereit. Die autotools und einige andere Feinheiten wollten noch "besiegt" werden. Die jetzige Version sollte nun gegen die Standardblibiotheken linken.

Die monitord.xml aus dem Unterordner monitord habe ich aus dem SVN genommen. Stattdessen habe ich einen Ordner sample-config erstellt.

Ausserdem habe ich die lbtool.m4 aus dem Unterordner m4 wieder gelöscht. Das bitte auch machen, sofern ihr die autotools mal starten solltet.

Von meiner Seite aus würde ich nun auch sagen, sind die Features, die ich brauche und komplettieren möchte im Grunde alle angelegt. Aus purem Eigennutz habe ich auch ein mySQL Plugin erstellt, daß ich auch noch in die 2.0er Version packen möchte.

Die nun vorhandenen Features würde ich dann in den nächsten Tagen noch vervollständigen und grundtesten. Danach kann dann eingentlich ein erster beta test starten, der dann die ganzen "kleinen" Fehler offenlegen wird. Eine fertige monitord Version 2.0 könnte ich mir so ab März vorstellen. Ggf auch schon im Februar. Hängt davon ab wie viele kleine Fehler noch auftreten.

Wie sieht es einer Entwicklung im Bereich Frontend aus ? Einige Ansätze habe ich schon gesehen, gelesen oder gehört. Gibt es da noch Aktivitäten ?

jhr-online

02.01.2008, 14:35

Bei linken fällt mir was ein, wovon ich keine Ahnung hab...
Es wird doch einige libs geben, die für den monitord nötig sind, richtig? Werden die von euch immer mitgeliefert, also irgendwie verbaut? Oder greift ihr auf libs zurück, die das System schon liefert. Ich hab da echt keine Ahnung von, bin ja kein Programmierer in dem Bereich... :)
Ich frage, weil ich eben drüber nachdachte, daraus auch ein Debian-Paket zu bauen, wenn ich Zeit habe. Dafür müsste ich dann ja Abhängigkeiten definieren...

Die Antwort hierauf darf sehr kurz sein. Wer Lust hat, kann mir aber gerne ein paar Zeilen für's Verständnis schreiben, oder ein (guten) Link geben, der mir erklärt, was ich für einen Unsinn gerade rede :)

jhr
...der sich gerade seiner Unwissenheit bewusst ist und ihrer schämt.

Buebchen

02.01.2008, 15:25

der "pure" monitord braucht keine besonderen Libraries. Mal abgesehen von den üblichen Verdächtigen, die der Compiler und das Betriebssystem schon mitliefert.

Anders bei der libmysqlclient und libmp3lame. Die werden beim Start des monitord (bzw. des plugins) vom system automatisch hinzugeladen.
Für Windows habe ich die ins Installerpaket hinzugefügt. Für linux nicht. Da kenne ich mich mit RPMs und .deb's auch nicht wirklich gut aus. Man könnte aber sicherlich eine Abhängigkeit zu den benötigten Paketen hinterlegen.

Wenn ich alles richtig gemacht habe wird das configure script auch meckern, wenn kein mysql und/oder lame support vom system gegeben ist.

Wichtig: lame heisst in dem Fall, daß die libmp3lame.(so|dll) gebraucht wird.

DocSteel

03.01.2008, 00:29

Hallo

Es wäre schön wenn mal einer der Entwickler im ersten Beitrag dieses Themas einen aktuellen Link zu einem funktionierenden svn posten könnte (bzw. den vorhandenen anpassen)

Bei jhr-online.de/monitor und bei monitord.de kommen beim Versuch dort svn's auszuchecken Fehlermeldungen bzw. es gibt die Domain im ersten Fall gar nicht mehr.

Das macht es Interssierten schwer an die Quellen zu kommen. Trotzdem ein tolles Projekt.

Gruß

Doc - Der sich über einen Link zu den aktuellen Dev-Quellen freuen würde (gerne auch Vers. 1.9, muss ja nicht 2.0 Beta sein, hauptsache es läuft)

Buebchen

03.01.2008, 01:05

Aktuelles SVN:

http://svn.monitord.de

-> wichtig ist das http Protokoll (für WebDAV)

DocSteel

03.01.2008, 14:32

Ah danke! :)

Buebchen

04.01.2008, 00:22

Eine neue Version ist im SVN eingecheckt. Würde mich interessieren, ob die jeder compilieren kann. Einiges ist geändert. Die meisten Features sind als Kernelement (ohne grosse Tests) vorhanden.

Wichtig:
lame + mysql werden vom configure script getestet, wenn man es nutzen will. Dazu muss die libmp3lame.so und libmysqlclient.so im Linkerpfad liegen. Sonst meldet configure einen Fehler.

Ach ja. Die option --enable-lame habe ich in --with-lame umbenannt (da es auch with--mysql heisst).

Das vollständige Pluginpaket würde also mit --enable-plugins --with-mysql --with-lame erstellt werden.

Gibt es eigentlich jemanden, der rpm bauen kann ?

nepomuck

06.01.2008, 13:38

Du hast geschrieben, daß Du schon lame installiert hast. Wo liegen dann dann bei Dir die lame.h ?

Ich habe die Sourcen von Lame gar nicht auf der Maschine. Nur die fertige Library in /usr/lib.

Andreas

Buebchen

06.01.2008, 14:19

Ich habe die Sourcen von Lame gar nicht auf der Maschine. Nur die fertige Library in /usr/lib.

Andreas

Die lib heist aber libmp3lame.so, richtig ?

Dann versuch vor dem configure ein

export CPPFLAGS="-Ilame-3.97/include"

Dann sollte er die lame.h aus dem svn nehmen. Lame erstellen brauchst du dafür nicht.

mdi

08.01.2008, 15:41

Moin,

ich habe mal eine Frage zu der MySQL-Plugin-Geschichte:

Legt das Plugin selber Tabellen an wenn die nicht da sind? Wenn nein - wie sollen die denn aussehen bzw. ist es möglich, die notwendigen Table-Definitionen hier als SQL-Queries abzulegen um sie generieren zu können ohne dass ich mir die Infos aus dem Code klauben muss? Würd das auch gern mal ausprobieren und entsprechend auch als Info auf die Webseite bappen :).

Viele Grüße
Martin

Buebchen

08.01.2008, 16:30

Die Tabelle wird nicht erstellt. Ebensowenig wie die Datenbank. Das würde ich auch eher als Aufgabe des Frontends sehen.

das plugin ist variabel gehalten. Es liest seine Konfig aus der monitord.xml.

Pro Meldungstyp (pocsag,zvei,fms) gibt es einen mapping Bereich, der Tabelle und Feldzuordnungen definiert. Das posten von XML Dateien ist ja nicht so toll. Deswegen schau mal in den Ordner sample-config rein. Da kann man das einsehen.

Felder sehen so aus:

a) <field name="..feldname-sql"> ..feldname-resultset <field>
b) <field name="..feldname-sql" source="mysql" "> NOW() <field>

a) Weist dem mysql-Feld den Inhalt des Resultset-Felds zu
b) Würde dem mysql-Feld den Funktionswert NOW() zuweisen.

Eine Konstante würde so gehen:

c) <field name="..feldname-sql" source="mysql" "> "FIXWERT" <field>

mdi

08.01.2008, 18:10

Hallo,

OK; das habe ich dann doch so weit verstanden, scheint mir :).

Nach entsprechendem Bau von Tabelle und Mapping stoße ich jetzt jedoch darauf, dass ich zwar korrekte Login-Daten in der monitord.xml angebe, der monitord aber weiterhin versucht, als root zu connecten.

Der Fehler ist in der monitord.xml zu finden; das Feld heißt nicht "login" sondern "username". Ich habe die sample-config-Dateien angepasst.

Martin

Buebchen

08.01.2008, 21:23

Ups :-)

Stimmt. Ich hatte zuerst login angedacht. Fand ich dann aber ungeeignet und habs geändert. Hatte gedacht, ich hätte die samples auch angepasst. Nun ja. So kann man sich irren *schäm*

nepomuck

09.01.2008, 18:11

Hallo Zusammen,

Die Version 0.3 des Monitor-Protokolls ist fertig. Das PDF mit der aktuellen Dokumentation liegt auf:

ftp://andi.rw-labs.de/pub/Monitor%20Protokoll%2003.pdf

Änderungen:

OK: 100/200
Nur noch wenige Kommandos werden per OK bestätigt (@Buebchen)

Inquiry: 111/211
Liefert nun eine mehrzeilige Antwort und kann somit mehrere Paramter wie z.B. mehrere zur Verfügung stehende Protokollversionen angeben (@Buebchen).
Liefert zudem eine Liste der aktiven Module auf dem Server/Client (@Nepomuck)

Login: 220
Braucht nun als dritten Paramter eine vom Client gewünschte Protokollversion (@Nepomuck). Ohne diese Erweiterung macht der erweiterte Inquiry keinen Sinn.

Recording: 104
Liefert Dateinamen *MIT* Pfadangabe (@Buebchen)

ZVEI-Alarm: 300
Übermittelt am Ende ein Textfeld (@Buebchen)

Pocsac: 320
Datenfelder definiert 320:{Zeit}:Kanalnummer:RIC:Subadresse:Text (@Buebchen)

Falls ihr Fehler findet oder weitere Änderungen braucht, lasst es mich wissen.

Andreas
PS: Wie sieht's eigentlich mit einer Dokumentation zum Format der monitord.xml aus?

mdi

09.01.2008, 18:55

Moin,

PS: Wie sieht's eigentlich mit einer Dokumentation zum Format der monitord.xml aus?

der Versuch einer Anleitung:
http://www.monitord.de/index.php?article=3 (noch nicht offiziell, aber ich denke, hier im Forum kann mans schon mal zeigen).

Martin

Buebchen

09.01.2008, 21:47

Also mir gefällt das Ergebnis vom CMS schon !

Für die XML-Dateien habe ich auch ein hübsches Tool, um das farbig zu machen: Hightlight Code Converter von www.andre-simon.de

Nehme gerne für Dokumentationen :-)

nepomuck

10.01.2008, 01:24

Hallo nochmal,

Auf meinem FTP-Server liegt ein Testfile für ZVEI- und FMS-Funktionen zum Download:

ftp://andi.rw-labs.de/pub/fmszveitest.mp3

Das Ganze wurde mit dem BOS-Tool erstellt und besteht aus zwei Komponenten:

ZVEI: Die Testserie beginnt mit einer Reihe von Schleifen mit allen möglichen Sirenentönen. Stand heute dekodiert Monitor die verschiedenen DTFM-Töne noch nicht korrekt.
Anschliessend folgt eine Reihe einzelner Schleifen ohne Wiederholung. Nach den Ziffern 1-9 enthalten diese Schleifen auch die Sonderzeichen A, J, F und U. Diese Schleifen kann der monitor aktuell auch noch nicht dekodieren. Es folgt eine Serie nummerischer Schleifen mit Wiederholung. Die ZVEI-Testserie beendet eine 00000 mit Entwarnungston.

FMS: Am Angang gehen zwei Textmeldungen raus, dann folgen alle Statusmeldungen vom umd zum Fahrzeug. Und am Ende kommen zwei Meldungen mit einem fünfstelligen Folgetelegramm. Die letzten Telegramme dekodiert Monitor noch nicht korrekt.

Das Test-MP3 ist Stereo. Am Anfang kommt der ZVEI-Test rechts und FMS links, später wiederholen sich beide Test auf den jeweils anderen Kanälen.

viel Spass beim Testen,
Andreas

Buebchen

10.01.2008, 10:53

Was genau sollte denn rauskommen ?

Er wertet bei mir haufenweise ZVEI und FMS aus. Da ich das Soll nicht kenne, kann ich das Ist nicht bewerten :-(

Was sind z.B. bei FMS die letzten Telegramme, die er nicht erkennt. Die würde ich sonst selbst im BOS-Tool nachbauen.

nepomuck

10.01.2008, 13:08

Was genau sollte denn rauskommen ?

Hier der "Bauplan" der Testdatei.

ZVEI:
00000 ohne Folgeton, 00000 Melderton 1, 00111 Feuer, 00112 Test, 00113 Zivilschutzalarm, 00114 Zivilschutzwarnung, 00115 Zivilschutzentwarnung, 00222 Melderton 2
bis hierhin alle Schleifen doppelt. Dann einzeln:
00123, 00234, 00345, 00456, 00567, 00678, 00789, 00890, dann einige Schleifen mit den Sonderzeichen A, C, H, U, L und J, gefolgt von 00111 Test. (MDI erwähnte mal, er wolle die Sondertöne dekodieren und nutzt einzelne Schleifen oder Wiederholung, daher habe ich sie in die Testalarmierung eingebaut)

Dann wieder doppelt: 00111, 00122 bis 00199 ohne Melderton und 00000 Zivilschutzentwarnung als Abschluss.

FMS:
Zwei Mal FMS-Kurztest "Franz jagt im verwahrlosten Taxi quer durch Bayern" an Fahrzeug: 63915401 mit Erreichbarkeitsanfrage, Quittung etc.
Dann FMS-Staus 1 bis 15 zur Leitstelle von Fahrzeug 63915401 mit Quittung und Wiederholung mit Baustufe 2 und TKI I.
Dann FMS-Status A bis u zum Fahrzeug ebenfalls mit Quittung und Wiederholung, Baustufe 2 TKI I.
Das BOS-Tool wiederholt bei einigen Statusmedlungen das Telegramm nicht -- keine Ahnung warum.
Abschliessend mehrfach FMS-Folgetelegramme mit ABCDEF oder 12345 als Folge (werden nicht dekodiert).

Andreas

Buebchen

10.01.2008, 13:36

Ah. Also ZVEI lass ich für mich mal aussen vor. Ich würde dann bei FMS schauen. Da geht alles bis auf die Folgetelegramm Fzg->Lst ?

stadel21

10.01.2008, 13:39

hihi das finde ich ja mal ganz interessant. Das gleiche würde mich mal für Pocsag interessieren. Ich würd sagen bei mir hat so zu 90 % alles richtig decodiert. :-)

mdi

10.01.2008, 14:05

Hallo Andreas,

ZVEI: Die Testserie beginnt mit einer Reihe von Schleifen mit allen möglichen Sirenentönen. Stand heute dekodiert Monitor die verschiedenen DTFM-Töne noch nicht korrekt.

vorweg: Cooles Testfile, gut gemacht :)!

Die Sirenentöne werden nun korrekt erkannt (Rev. 279/SVN).

Die Sonderzeichen sind aber noch immer nicht implementiert :´(.
Ich habe mich eben damit befassen wollen - allerdings stoße ich auf das Problem, sie hinterher auszugeben. Die ZVEI-Folge ist als "text5" im Protokoll spezifiziert, erlaubte Zeichen sind aber nur A-F, womit J, U und so weiter rausfallen würden. Was tun? Möglich wäre ein "Mapping" (A=A, B=H, C=C, D=J, E=L, F=U - wobei das P wegfallen würde), was haltet Ihr davon? Oder kann man in dem Feld direkt das Zeichen angeben (z.B. 8A0J6)?

Letzte Änderung:
Ich hatte ab und an Probleme mit der Stereo-Auswertung der ZVEI-Tonfolgen. Warum auch immer. Vielleicht war ich doch nur zu blöd, das Mikro abzuschalten.

Martin
PS: Und nochwas, ich kriege bei der Ausgabe nicht mehr "Kanal 2", wie in der monitord.xml eingetragen, sondern "1" als Kanalbezeichnung.

nepomuck

10.01.2008, 17:11

Ich würde dann bei FMS schauen. Da geht alles bis auf die Folgetelegramm Fzg->Lst ?
Korrekt. Da wir hier noch kein FMS verwenden kann ich dir aber nicht sagen, ob diese Funktion in der Praxis überhaupt genutzt wird.

Das gleiche würde mich mal für Pocsag interessieren.
Läßt sich einfach realisieren (zumindest mit meinem Setup):
Linux-Box mit VMWare. Unter VMWare läuft Windows mit BOS-Tool. Der Linux Mixer stellt den REC-Eingang auf Volume, folglich nimmt der Audiorecoder das auf, was die Soundkarte ausgibt :-)
Unter Linux Audiorecorder starten und Aufnehmen, in der Windows-VM mit dem BOS-Tool die Test-Sounds generieren. Die Demo des BOS-Tools steigt zwar immer wieder aus, aber das macht nichts. Die fertige Aufzeichnung des Audiorecorders läßt sich später mit Audacity oder anderen Tools zusammenschneiden.

Auf die Tour liesse sich auch ein Pocsac-Testfile generieren. Sagt mir Bescheid, wenn ihr sowas braucht und was drin sein soll.

Die Sirenentöne werden nun korrekt erkannt (Rev. 279/SVN).
Das ging ja Superflott! Ich werde es gleich testen.

erlaubte Zeichen sind aber nur A-F, womit J, U und so weiter rausfallen würden. Was tun?
Ich habe im Netz gesucht und das hier gefunden:

ton ZVEI1 ZVEI2
1 1060 Hz 1060 Hz
2 1160 Hz 1160 Hz
3 1270 Hz 1270 Hz
4 1400 Hz 1400 Hz
5 1530 Hz 1530 Hz
6 1670 Hz 1670 Hz
7 1830 Hz 1830 Hz
8 2000 Hz 2000 Hz
9 2200 Hz 2200 Hz
0 2400 Hz 2400 Hz
E/W 2600 Hz 970 Hz
A/N 2800 Hz 885 Hz
C 810 Hz 810 Hz
H 885 Hz 2800 Hz
U 1750 Hz 1750 Hz
L 1860 Hz 1860 Hz
J 2135 Hz 2135 Hz
P 2280 Hz 2280 Hz

Du könntest den Dekoder so programmieren, dass er sowohl 2600 als auch 970 Hz als W(iederholungston) akzeptiert und die Buchstaben "A" als 2800 Hz und "H" als 885 Hz dekodiert. Dann beherrscht Monitor sowohl ZVEI-1 als auch ZVEI-2, wobei ein ZVEI-2-Anwender wissen muss, dass unser Programm dabei A und H vertauscht.

Oder wir setzen es "Super Korrekt" um und führen einen Switch in der monitord.xml ein:

für ZVEI-1 wie gehabt

(module type="zvei")
(/module)
und für ZVEI-2

(module type="zvei2")
(/module)
Wobei fraglich ist, ob das in der Praxis überhaupt irgendjemand braucht.

viele Grüße,
Andreas

Buebchen

10.01.2008, 17:37

Oder wir setzen es "Super Korrekt" um und führen einen Switch in der monitord.xml ein:

für ZVEI-1 wie gehabt

(module type="zvei")
(/module)
und für ZVEI-2

(module type="zvei2")
(module)
Wobei fraglich ist, ob das in der Praxis überhaupt irgendjemand braucht.

viele Grüße,
Andreas

oder vielleicht noch eleganter:

(module type="zvei")
(zveitype) 2 (zveitype)
(/module)

Denn der Rest vom Modul ist doch m.E. identisch. Ändert sich nicht nur die Frequenztabelle ?

mdi

10.01.2008, 17:42

Heyho,

das hier genannte "Problem" ist sicherlich auch ein interessantes, aber es geht erstmal um die Ausgabe der erkannten Zeichenfolge...

Bisher waren das nur Zahlen, so isses auch im monitord-Protokoll problemlos integrierbar. Nun kommen aber Buchstaben "größer als" F hinzu, die angezeigt werden müssten. Das hat mit ZVEI-1 oder ZVEI-2 erstmal nix zu tun. Die Frage ist, ob ich die Zeichenkette "8AJHP" so am Socket ausgeben kann oder ob das codiert werden muss, was dann natürlich mehr Zeichen draus machen würde. Oder bin ich auch dem falschen Dampfer und es wird eh alles codiert und decodiert?

Weiterhin muss ich feststellen, dass das mit den Zeichen noch ein wenig dauern wird, da dafür ein Umsetzen der Frequenz zum auszugebenden Zeichen notwendig wird, das muss ich mir aber in Ruhe überlegen, wie das am sinnvollsten/optimalsten zu implementieren ist.

Martin

nepomuck

10.01.2008, 17:57

oder vielleicht noch eleganter:
(zveitype) 2 (zveitype)

Auch gut. Wenn der Paramter zveitype fehlt, sollte monitord automatisch zvei-1 dekodieren.

Nun kommen aber Buchstaben "größer als" F hinzu, die angezeigt werden müssten.
Kapiert. Da es sich aber nur um ein paar wenige Sonderzeichen handelt, würde ich die im Klartext (Großbuchstaben) ausgeben.
Also Ja: Gib "8AJHP" am Socket aus und ich ändere dir Protokolldoku für 0.4 dementsprechend ab.

Weiterhin muss ich feststellen, dass das mit den Zeichen noch ein wenig dauern wird
Ich glaube, wir können dieses Feature mit geringer Priorität behandeln. Außer dir selbst hat bisher noch kein Monitor-Anwender nach den ZVEI-Sonderzeichen gefragt.
Aber wenn wir diese Funktion schon implementieren, dann halt richtig und mit allen Zeichen.

viele Grüße,
Andreas
PS: Sirenenerkennung funktioniert prima. Dazu aber noch eine aktuelle, wichtige Änderung im Protokoll:

Bisher lautete die Syntax für den Sirenen-Paremter des 300er-Codes:
0 ohne Sirene / Melderauslösung, 1 Feueralerm, 2 Probelalarm, 3 Zivilschutz, 4 Warnung, 5 Entwarnung

Da der Dekoder jetzt aber einen Unterschied zwischen Schleifen ohne und mit Weckton macht, gilt für diesen Paramter folgendes:
0 ohne Sirene, 1 Melderauslösung, 2 Feueralerm, 3 Probelalarm, 4 Zivilschutz, 5 Warnung, 6 Entwarnung.

Bubu80

13.01.2008, 10:27

Hallo zusammen!

Mit großen Interesse verfolge ich ja nun schon einige Zeit, was hier so passiert. Das eine oder andere sagt mir was, vieles davon leider nicht. Mag ja an meiner mangelnden Zeit liegen...

Jetzt wollte ich mal meinen Monitor eine wenig modernisieren.

Ich hab nur kein Plan was ich wie wo anstellen soll. Nun hab ich schonmal versucht rauszufinden
was SVN ist, aber so richtig schlau bin ich nun auch nicht.

Daher die Frage: Gibt es eine Anleitung wie ich mir aus eurer Arbeit einen Monitor bauen kann?
Vielleicht so eine für Noobs :-) ?
Leider hab ich noch nicht eine Idee wo ich anfangen könnte. Was ich kenne ist runterladen, auspacken, make laufen lassen und gucken wo's hängt ;-) Hab hier übrigens ein Ubuntu 7.10 jungfreulich.

Daher würde ich mich freuen wenn ihr mir vielleicht den einen oder anderen Tipp geben könnt,
wo ich am besten Anfange.

Danke!

Bubu

jhr-online

13.01.2008, 11:31

svn ist die Abkürzung zu subversion; das sollte dir bei der Suche weiterhelfen. :) Im Großen und Ganzen ist svn da, um Versionierung vorzunehmen. Einer lädt was hoch und anstatt das vom vorherigen zu überschreiben wird (mehr oder weniger) eine Kopie davon angelegt und dafür ein Zähler hochgezählt. Man hat also alle Entwicklungsstände (Revisionen) gespeichert und kann jederzeit zurück etc.

Aktuell entwickelt wird ein monitord. Das heißt, der "neue monitor" hat kein Frontend, sondern läuft als Deamon und gibt die Daten auf einen IP-Port aus. Neue Frontends müssen noch erstellt werden, um die Daten dann da abzugreifen. Das ermöglicht mehr Flexibilität, insbesondere, da monitord dadurch netzwerkfähig geworden ist. Ich weiß aber nicht, ob es dir gerade weiter hilft... :D

jhr

Buebchen

13.01.2008, 17:21

Habe im ersten Langzeitlauf noch ein Speicherleck entdeckt. (GlobalDispatcher hat die Resultsets nicht gelöscht, nur aus der Queue entfernt). Im SVN gefixt.

@mdi:
monitord-setup.exe steht auch gleich bereit.

skyfire

13.01.2008, 17:53

hallo,

hab mal ne frag wie ich monitor richtig Konfiguriere. ICh möchte das bei einer bestimmten 5Tonfolge ein Programm, eine Sound Datei und das die 5 Tonfolge aufnehmen. In welche datei muss ich das genau reinschreiben?
weiß jetzt nicht ob des hier reingehört aber mit dem wiki bin ich einfach nicht weiter gekommen

mfg skyfire

Buebchen

13.01.2008, 18:09

Dieser Thread passt nicht ganz zu deiner Frage, da es hier um die Entwicklung des Nachfolgers geht (Version 2.0)

Die Antwort auf Deine Frage findest Du in der manpage zur monrc. Du musst die Datei .monrc bearbeiten. Eine ältere Version als PDF findest zu hier: http://www.funkmeldesystem.de/foren/attachment.php?attachmentid=2782&d=1124750750

Auf Seite 11 sind die Aktionen beschrieben (ZVNAME)

skyfire

13.01.2008, 19:36

danke und viel spass noch an monitor 2

mdi

14.01.2008, 15:20

Moin,

ich habe mal ein minimales Frontend gebaut, das die monitord-Ausgaben in Klartext umbastelt (mit der convert-Klasse von Buebchen aus den monitord-Sourcen) und sortiert auf Tabs ausgibt. Es bietet nicht viel, aber das sollte hoffentlich reichen um die Ausgaben nicht mehr im telnet enträtseln zu müssen ;).

Sourcecode und Binary mit wxWidgets-DLLs liegen zum Download bereit unter http://www.monitord.de/index.php?article=5 - die Web-Präsenz braucht noch ein bisschen Feinschliff und kann dann hoffentlich bald "öffentlich" online gehen.

@Buebchen:
Der neue Installer liegt da auch schon.

Martin

funkwart

14.01.2008, 16:05

Moin,

leider produziert der Aufruf des exe nur die Fehlermeldung mit dem Ruf nach der mingwm10.dll

Gruß,
Funkwart

Buebchen

14.01.2008, 17:00

Moin,

leider produziert der Aufruf des exe nur die Fehlermeldung mit dem Ruf nach der mingwm10.dll

Gruß,
Funkwart

der monitord.exe ?

mdi

14.01.2008, 17:39

Moin,

nein, sicher mein Frontend.

Fix ist hochgeladen, neues Zip-Archiv online.

Martin

funkwart

14.01.2008, 18:04

Jipp, danke funktioniert!

Max K.

15.01.2008, 15:18

Hi,

wollte eben mal monitor installieren!
Klappt auch, bis ich es starten will:

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

In der /proc/asound/cards sagt er:

0 [A5451 ]: ALI5451 - ALI 5451
ALI 5451 at 0x8400, irq 5

Also Soundkarte ist vorhanden (und hat mit dem "alten" monitor ja auch funktioniert.)

Ne Idee?

Buebchen

15.01.2008, 23:28

Ich würde mal so starten:

hast du nen Ordner /dev/snd mit Devices drin ? Dann ist also ja korrekt installiert.
Dann fehlt nach meiner Einschätzung die OSS Unterstützung.

Entweder Du installierst diese für deine Distro nach oder aber ändert /dev/dsp0 man zum testen in /dev/snd/pcmC0D0c in der monitord.xml. Könnte dann auch gehen.

nepomuck

16.01.2008, 00:32

ich habe mal ein minimales Frontend gebaut
Da geht bei mir gar nix. Ich starte das Frondend, gebe die Server-IP an und sehe in "Other" die OK-Meldung des Servers -- das wars.
Auch wenn ich den monitord mit Alarmierungen bombardiere, das Frontend zeigt nichts an, eine Telnet-Verbindung zum Server auf Port 9333 hingegen listet alles auf.

Ich hab es auf einer VM mit XP Prof. und einer physischen Maschine mit XP MCE probiert.

viele Grüße,
Andreas

Buebchen

16.01.2008, 00:54

Da geht bei mir gar nix. Ich starte das Frondend, gebe die Server-IP an und sehe in "Other" die OK-Meldung des Servers -- das wars.
Auch wenn ich den monitord mit Alarmierungen bombardiere, das Frontend zeigt nichts an, eine Telnet-Verbindung zum Server auf Port 9333 hingegen listet alles auf.

Ich hab es auf einer VM mit XP Prof. und einer physischen Maschine mit XP MCE probiert.

viele Grüße,
Andreas

Das telnet machst Du vom gleichen Client aus ? Ansonsten wartet der monitord auf einen Login. Das kannst Du in der monitord.xml anpassen.

mdi

16.01.2008, 11:32

Moin,

dass da die OK-Zeile kommt heißt ja (genau wie Buebchen vermutet hat), dass die Verbindung grundsätzlich steht aber man nix zu sehen kriegt, weil kein Login erfolgt (das kann das Ding nicht).

Also sehe ich als sinnvoll an, folgende ToDos zu erkennen:
a) Das Mini-Frontend muss Username und Passwort abfragen und sich entsprechend am monitord anmelden können.
b) Der monitord muss zum Login auffordern.

a) baue ich ein, wie wäre b)? Ich selber bin auch schon mehrmals an der Sache gescheitert, dass ich eine IP-Einstellung falsch gesetzt habe und mir der monitord nicht kund tut, dass ein Login notwendig wäre, von daher hielte ich den Hinweis durch den monitord für eine gute Sache, was meint Ihr dazu?

Martin

nepomuck

16.01.2008, 12:13

dass da die OK-Zeile kommt heißt ja (genau wie Buebchen vermutet hat), dass die Verbindung grundsätzlich steht aber man nix zu sehen kriegt, weil kein Login erfolgt
Korrekt, das war mein Fehler

Der monitord muss zum Login auffordern.
Das Protokoll sieht hier nichts vor. Ich habe den Sonderfall, dass sich Clients ohne Login verbinden dürfen nicht berücksichtigt.

Ich würde das folgendermassen umsetzen. Wenn die Verbindung steht sendet dein Client ein "202" (Keepalive) an den Server. Wenn ein 100 (OK) als Antwort zurückkommt, darf der Client ohne Login eine Verbindung aufnehmen (Infobox: Verbindung steht). Bekommt er hingegen ein 101:001 zurück (Fehler: Not logged in), dann muss dein Programm ein Fenster öffnen und Benutzernamen und Passwort abfragen.

@Buebchen: Wie weit sind hier die Protokolländerungen von 0.3 umgesetzt? Kennt der monitord schon den Login mit Protokollversionsparamter? Ist 202 komplett implementiert?

viele Grüße,
Andreas

Buebchen

16.01.2008, 15:22

Korrekt, das war mein Fehler

Das Protokoll sieht hier nichts vor. Ich habe den Sonderfall, dass sich Clients ohne Login verbinden dürfen nicht berücksichtigt.

Ich würde das folgendermassen umsetzen. Wenn die Verbindung steht sendet dein Client ein "202" (Keepalive) an den Server. Wenn ein 100 (OK) als Antwort zurückkommt, darf der Client ohne Login eine Verbindung aufnehmen (Infobox: Verbindung steht). Bekommt er hingegen ein 101:001 zurück (Fehler: Not logged in), dann muss dein Programm ein Fenster öffnen und Benutzernamen und Passwort abfragen.

@Buebchen: Wie weit sind hier die Protokolländerungen von 0.3 umgesetzt? Kennt der monitord schon den Login mit Protokollversionsparamter? Ist 202 komplett implementiert?

viele Grüße,
Andreas

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

nepomuck

16.01.2008, 18:51

So, jetzt habe ich auch mal ein paar Zeilen Code geschrieben!
Der ist zwar nicht besonders toll, sollte uns aber beim Entwickeln etwas helfen.

ftp://andi.rw-labs.de/pub/bosix/poni.pl

"Poni", das Perl Monitor Frontend, stellt eine Verbindung zu einem Monitor-Server her und gibt die ankommenden Alarme in lesbarer Form auf der Kommandozeile aus -- mehr macht das Tool im Moment nicht.

Bei den Tests mit Poni (und dem BOS-Tool auf der Gegenseite) ist mir was aufgefallen:

Pocsac geht hier nur mit 512 Baud, 1200 Baud-Alarme werden nicht angezeigt.
Bei nummerischen Pocsac-Alarmen übermittelt Monitor die Ziffern im Klartext und nicht Hex-Kodiert. Der Client kann aber nicht wissen, ob was Alphanummerisches (Hex-codiert) oder was nummerisches (nicht HEX-codiert) ankommt.
Hier sollte Monitor auch die nummerische Ausgabe HEX-Kodieren, dann können die Clients das Text-Feld pauschal durch den HEX-Dekodierer jagen.
Oder wir müssen ein zusätzliches Feld "Alarmtype" beim Kommando 320 einführen, so dass der Client weiss was ihn erwartet.

viele Grüße,
Andreas

nepomuck

17.01.2008, 16:15

Schlechten Perl-Code schreiben macht Spass!

Ich habe gleich noch was nachgelegt: einen Mini-Client der Alarme im CSV-Format in separate Dateien schreibt und eine kompakte Darstellung auf dem Schirm ausgibt.

Das Perl-Programm ponilog.pl wertet die poni.cfg-Datei aus, um die Infos zum Server, Port etc. zu erhalten. Tool und Demo-Config liegen auf
ftp://andi.rw-labs.de/pub/bosix/

viele Grüße,
Andreas

Max K.

18.01.2008, 15:52

Hi,

zuerst mal danke für die Antwort!

Ich würde mal so starten:

hast du nen Ordner /dev/snd mit Devices drin ? Dann ist also ja korrekt installiert.
Ja, existiert.

Dann fehlt nach meiner Einschätzung die OSS Unterstützung.

Kann eigentlich auch nicht sein, ein "cat /proc/asound/oss/sndstat" bringt:

Installed drivers:
Type 10: ALSA emulation

Card config:
ALI 5451 at 0x8400, irq 5

Audio devices:
0: ALI 5451 (DUPLEX)

Synth devices: NOT ENABLED IN CONFIG

Midi devices: NOT ENABLED IN CONFIG

Timers:
7: system timer

Mixers:
0: Conexant Cx20468 rev 1,Conexant

Entweder Du installierst diese für deine Distro nach oder aber ändert /dev/dsp0 man zum testen in /dev/snd/pcmC0D0c in der monitord.xml. Könnte dann auch gehen.
Selber Fehler leider. :(

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

Buebchen

18.01.2008, 18:45

Hi,

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

Müßte da jetzt nicht /dev/snd/pcmC0D0c stehen ? Muss mir mal den Linux Alsa Teil angucken ... Da scheint die Konfig nicht zu funktionieren.

Max K.

18.01.2008, 18:48

Hi,

klar, stehts auch. ;-) Habe nur die Fehlermeldung ausm 1. Beitrag kopiert, damit der Bezug schnell ersichtlich ist.

Buebchen

18.01.2008, 22:34

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

So. Versuche da jetzt mal beim Login weiter zu kommen. Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

Ich könnte jetzt zwei Wege gehen:

a) Im configure.ac werden nur noch Zahlen mit einer Nachkommastelle als Programmversion genutzt
b) Wir lassen als Programmversion auch Text zu und können auch wie bisher svn / stable / dev / beta / sonstige Text als Version im configure.ac eintragen.

Spontan halte ich sowas für einen reinen Infotext. Oder wird der Client jemals mit dem "Versionswert" rechnen ? Interessant ist doch die Protokollversion für ihn. Ob das nun ein 2.1a oder 2.2svn monitord ist ist doch eher uninteressant und mehr etwas als Information für den Benutzer, oder ?

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ? Denn das ist im Moment noch nicht weiter definiert und ich möchte mich noch nicht festlegen, wie und wo die Modulnamen festgelegt sind.

Wenn nicht, ist die Antwort vorläufig:

111:5:"[leer]"

Buebchen

18.01.2008, 23:03

Kleiner Fehler in der Protokollversion 0.3 (Seite 3, Beispiel für Logins):

Ein Login mit unbekannter Version sollte m.E. nicht mit 101:004 (Protokollfehler, nicht verstanden) beantwortet werden, sondern mit 101:008 (Versionsfehler)

nepomuck

19.01.2008, 11:57

Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

Der Parameter ist -- wie du schon sagst -- reiner Infotext, da können wir eigentlich machen, was wir wollen. Ich ändere die Protokolldefinition für 0.4 ab, so dass der Paramter Programmversion ein Textfeld wird.

Bei der Protokollversion möchte ich allerdings das vierstellige nummeriesche Feld lassen, wenn's dir recht ist.

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ?

So hatte ich das gedacht. 111:5 kann entfallen oder mehrfach vorkommen. Da wir 111:0 als Ende-Kommando festgelegt haben, weiss der Client wann die Inquiry-Antwort fertig ist und wird nicht vergeblich auf ein 111:5 warten.

Ein Login mit unbekannter Version sollte m.E. nicht mit 101:004 (Protokollfehler, nicht verstanden) beantwortet werden, sondern mit 101:008 (Versionsfehler)

Ich hatte 008 als Fehler der Programmversion und 004 als Fehler der Protokollversion gedacht. Ein Login mit falschem Protokoll ist demnach ein Protokollfehler und kein Problem der Softwareversion. Oder ist das unlogisch?

viele Grüße,
Andreas

Buebchen

19.01.2008, 13:21

Der Parameter ist -- wie du schon sagst -- reiner Infotext, da können wir eigentlich machen, was wir wollen. Ich ändere die Protokolldefinition für 0.4 ab, so dass der Paramter Programmversion ein Textfeld wird.

Bei der Protokollversion möchte ich allerdings das vierstellige nummeriesche Feld lassen, wenn's dir recht ist.

das vierstellige Protokollfeld finde ich so prima. Das sollte ruhig bleiben.

Da wir 111:0 als Ende-Kommando festgelegt haben, weiss der Client wann die Inquiry-Antwort fertig ist und wird nicht vergeblich auf ein 111:5 warten.

Prima. So hatte ich mir das auch vorgestellt. Dann lass ich das vorläufg erstmal weg.

Ich hatte 008 als Fehler der Programmversion und 004 als Fehler der Protokollversion gedacht. Ein Login mit falschem Protokoll ist demnach ein Protokollfehler und kein Problem der Softwareversion. Oder ist das unlogisch?

viele Grüße,
Andreas

Ich, glaube dann stehe ich auf dem Schlauch :-)

Ein Login mit falschem Format (kein Protokollwunsch oder fehlendem Passwortfeld, oder nur "220:" ) wird jetzt doch mit 101:004 (nicht verstanden) beantwortet - richtig ?

Ein Login mit passender Protokollversion aber falschem Benutzernamen oder Password mit 101:003 (incorrect login)

Aber wie beantworten wir einen Login mit richtigen Benutzerdaten und nicht passender Protokollversion ? Bei 101:004 könnte man vom 1. Fall nicht unterscheiden.

Deswegen hätte ich dann intuitiv 101:008 genommen. Dann kann dem User als Meldung gesagt werden, daß die Protokollversion geändert werden muss. Die Anmeldedaten sind zu dem Zeitpunkt ja noch ungeprüft.

Die eigentliche Programmversion sollte m.E. für die Kommunikation unerheblich sein. Da ist aus meiner Sicht nur die Protokollversion entscheidend.

nepomuck

19.01.2008, 13:56

Ein Login mit falschem Format (kein Protokollwunsch oder fehlendem Passwortfeld, oder nur "220:" ) wird jetzt doch mit 101:004 (nicht verstanden) beantwortet - richtig ?

Wir können für so etwas ja auch einen "Client-Software-Programmierer-unfähig"-Fehler einführen :-)

Scherz beiseite: du hast recht, es gibt keine Unterscheidung zwischen Protokoll fehlerhaft verwendet und Protokollversion falsch. Also nehmen wir wie vorgeschlagen den 008 als Protokollversionsfehler und den 004 als Protkollbenutzungsfehler, ok?

Falls wir im weiteren Verlauf noch einen eigenen Fehlercode für den Server an sich benötigen, erweitern wir einfah die Protokolldefinition.
Andreas

mdi

22.01.2008, 22:55

Moinmoin,

ich wollte nur mal ein kurzes Lebenszeichen von mir geben: Ich habe zur Zeit Prüfungen und dem entsprechend deutlich weniger Zeit, mich um die monitord-Sache zu kümmern. Ist nicht vergessen und ich bin noch da! :).

Martin

Max K.

23.01.2008, 17:57

Hi,

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

Das Problem existiert leider nach wie vor.

-ALSA-Soundkarte ist korrekt eingerichtet
-Soundausgabe auf /dev/dsp funktioniert

Jemand ne Idee? Weil alle anderen Programme haben keinerlei Probleme..

nepomuck

26.01.2008, 23:02

Moin,

Mal 'ne grundsätzliche Frage:

Das vollständige Pluginpaket würde also mit --enable-plugins --with-mysql --with-lame erstellt werden.

Braucht es diese ganzen Parameter beim Build wirklich? Geht das nicht einfacher, so dass der Anwender nur über die monitor.xml entscheidet, welche Module er starten will. Ein einfaches ./configure und make baut dann einfach alles.

lame + mysql werden vom configure script getestet, wenn man es nutzen will. Dazu muss die libmp3lame.so und libmysqlclient.so im Linkerpfad liegen

Braucht es diese Libs zum Build oder erst zur Laufzeit? Es sollte doch genügen, wenn in der monitor.xml der Pfad zu den Libs angegeben wird, falls der Anwender diese Module nützen möchte.
Das würde es erheblich vereinfachen, den monitord als Binärdatei auf einer Distribution zu installieren (per RPM oder DEB).

Liesse sich überdies eine Option einbauen, die nach einer Ausnahme die Audiodatei an ein externes Skript übergibt? Dann könnte man die Aufzeichnung beispielsweise durch einen Filter jagen, der Ruhepasen entfernt.

viele Grüße,
Andreas

Buebchen

27.01.2008, 00:02

Moin,

Mal 'ne grundsätzliche Frage:

Braucht es diese ganzen Parameter beim Build wirklich? Geht das nicht einfacher, so dass der Anwender nur über die monitor.xml entscheidet, welche Module er starten will. Ein einfaches ./configure und make baut dann einfach alles.

Im Moment - solange die Module nicht als Default=yes eingetragen sind braucht es die Optionen. Da alles noch kein "stable" Status hat ist es m.E. richtig die Module erstmal nicht automatisch zu bauen.

Braucht es diese Libs zum Build oder erst zur Laufzeit? Es sollte doch genügen, wenn in der monitor.xml der Pfad zu den Libs angegeben wird, falls der Anwender diese Module nützen möchte.
Das würde es erheblich vereinfachen, den monitord als Binärdatei auf einer Distribution zu installieren (per RPM oder DEB).

Die Libs braucht es beim schon beim Bauen, da die Plugins gegen die Bibliotheken gelinkt werden (vereinfacht gesagt). Im Grunde braucht er nicht die komplette DLL/Lib. Aber das macht an der Stelle keinen Unterscheid.

Liesse sich überdies eine Option einbauen, die nach einer Ausnahme die Audiodatei an ein externes Skript übergibt? Dann könnte man die Aufzeichnung beispielsweise durch einen Filter jagen, der Ruhepasen entfernt.

viele Grüße,
Andreas

Das läßt sich mit Sicherheit einbauen. Sollten wir im BTS eintragen.

mdi

30.01.2008, 15:21

Moin mal wieder von mir,

ich habe mich nach einigen Problemen mit der Erkennung der von unseren Handfunkgeräten ausgesandten ZVEI-Fünftonfolgen nocheinmal daran gemacht, die Logik zu verbessern. So weit ist mir das auch gelungen; es wird jetzt immer über einen Block von sieben Sound-Puffern nach einem "klaren" Ton gesucht. Wird dieser eindeutig (>50% entsprechend 4 Blöcken) gefunden, wird der Ton als erkannt weitergereicht und in der Fünftonfolge abgelegt. Der 7er-Puffer arbeitet als Ring, erkannte Blöcke werden markiert, so dass Töne nur selten doppelt erkannt werden können - wenn das passiert, werden die Dopplungen vor der Eintragung in die Tonfolge erschlagen (zweimal dieselbe Frequenz darf nicht erkannt werden - müsste dann der Wiederholton sein). Umgesetzt wird die "korrekte" Ausgabe der wiederholten Ziffern erst bei der Ausgabe, solange liegen die Daten in Rohform (Array-Index der erkannten Frequenz vor).

Die bisherigen Versuche laufen gut und bis auf tatsächlich ernsthaft gestörte Signale sehr gut (was soll man in Müll auch erkennen...), allerdings fehlt die Sirenentonerkennung noch komplett.

Vor allem habe ich diesbezüglich eine Frage an Buebchen: Ich würde das Binary/den Installer gern selber bauen können, damit ich das Komplettpaket testen kann; kannst Du hier veröffentlichen, wie Du das gemacht hast und was für die Kompilierung einschließlich der Pugins noch benötigt wird?

Viele Grüße
Martin

Buebchen

30.01.2008, 22:44

Vor allem habe ich diesbezüglich eine Frage an Buebchen: Ich würde das Binary/den Installer gern selber bauen können, damit ich das Komplettpaket testen kann; kannst Du hier veröffentlichen, wie Du das gemacht hast und was für die Kompilierung einschließlich der Pugins noch benötigt wird?

Viele Grüße
Martin

Mal so aus dem Kopf (da ich gerade nicht nachgucken kann):

a) Du brauchst die Nullsoftinstaller: nsis.sf.net
b) Im SVN gilt es nen order der auch irgendwas mit nsis heisst. Da ist die "Quelldatei" für den Installer drin. Ich meine ich habe alles relativ zu diesem Ordner adressiert. Also solltest Du dann direkt dieses Skript mit dem nsis kompilieren können. Raus kommt dann ein fertiges Installationspaket. Die Datei nimmt er dazu aus dem Ordner, wo diese nach einem Build fertig liegen. Die muss man nicht weiter verschieben o.ä.

c) Falls Du das Binary selbst nicht bauen kannst ist das dann doch etwas umständlicher, da man die MySQL DLLs für den gcc unter MSYS/MinGW ein wenig anpassen muss. Das muss ich dann nochmal zusammenstellen.
d) Ausserdem muss ich seltsamerweise für das configure Skript die libmysql.a bei mir umbenennen, damit das configure Skript MySQL-Support erkennt. Später beim build brauch die aber gerade (was m.E. auch so richtig ist).

Aber auch das muss ich nochmal zusammensuchen. Da wir uns den närrischen Tagen nähern bin ich nur gerade etwas mit Arbeit überhäuft. Denn die nächsten Einsätze stehen schon an ... :-)

mdi

01.02.2008, 12:53

Moin,

a) und b) sind klar :).

Bei c) ist aber das Problem - in MSYS kriege ich den MySQL-Raffel nicht gebaut und wäre da für einen Hinweis sehr dankbar. Versucht habe ich auch cross compiling von meinem Ubuntu aus... da aber MySQL auch nach Konsultation von Foren und Bugtrackern augenscheinlich nicht cross compilierbar ist, starb auch dieser Weg.

Ich habe einen neuen Branch angelegt (/branches/2.0-ZVEIrewritten-mdi), der meine Änderungen enthält. Die Sirenentonerkennung ist da noch nicht vorhanden. Da ich annehme, dass es weniger Zeit kostet, diesen Branch einmal auszuchecken und einen Installer daraus zu bauen (sofern man das passende Environment erstmal hat) als herauszusuchen und zu veröffentlichen, was alles zu ändern ist, möchte ich Dich genau darum bitten: Checkst Dus einmal aus, kompilierst es mit mysql und lame und lässt mir den Installer zukommen? Wär mir wichtig, da bald weiterzukommen, weil ich den mysql-Support durchaus auch nutzen möchte und sehr angetan bin davon - da ist es echt nervig, wenn mans nicht selber kompilieren kann weil $Ding fehlt aber man nicht herausfindet, welches ;).

Ansonsten kurz was ich eben noch gemacht habe:
1. Installation der Libraries aus dem aktuellen Installer von mysql.
2. reimp -d libmysql.lib
3. dlltool -k --input-def libmysql.def --dllname libmysql.dll --output-lib libmysql.a

Fehler ist:
checking for mysql_init in -lmysql... no
configure: error: --with-mysql was given, but test for mysql failed

Ich würd mich da sehr über einen Hinweis freuen, denn irgendwie ist das "bisschen" unbefriedigend so :7.

Viele Grüße
Martin

Buebchen

01.02.2008, 15:27

Fehler ist:
checking for mysql_init in -lmysql... no
configure: error: --with-mysql was given, but test for mysql failed

Ich würd mich da sehr über einen Hinweis freuen, denn irgendwie ist das "bisschen" unbefriedigend so :7.

Viele Grüße
Martin

Benenn mal während des configure die libmysql.a um, daß sie nicht gefunden wird. Seltsamerweise klappt sonst der Test vom configure nicht ... k.A. warum. Aber auch im Moment nicht so wichtig. Das configure braucht man ja nicht so oft.

[Edit]
ich gehe mal davon aus, daß LDFLAGS richtig gesetzt ist :-)

mdi

01.02.2008, 15:38

Moin,

gerade umbenannt - selber Fehler.

ich gehe mal davon aus, daß LDFLAGS richtig gesetzt ist :-)

Hm, was ist "richtig"? Ich habe mich bisher zwar nicht von C/C++ und dem Drumherum fern gehalten, aber da fehlts mir echt noch an Wissen :7.

Martin

Buebchen

01.02.2008, 16:26

Um bei einem configure Lauf die -L Parameter des gcc zu setzen nutzt man die Umgebungsvariable LDFLAGS

z.B. LDFLAGS="-L/lib -L/igendwo/lib"

Wenn da die libmysql.dll nicht drin ist wird es vermutlich fehlschlagen. Ich werde heute abend aber vielleicht wieder Zeit finden mein MSYS anzuwerfen. Dann kann ich mal meine Parameter "mitschreiben", die ich für den Build nutze.

mdi

01.02.2008, 18:06

Moin,

Wenn da die libmysql.dll nicht drin ist wird es vermutlich fehlschlagen.

*mich in die Ecke stell und schäm*.

Martin

PS: Danke! Manchmal sieht man den Wald vor lauter Bäumen nicht :7.

mdi

15.02.2008, 16:33

Moin,

ich habe ja neulich geschrieben, dass ich den ZVEI-Decoder nochmal überarbeitet hätte. Das ist mittlerweile so weit durch und im SVN (Rev. 293). Proben haben gut funktioniert; die Erkennung sollte jetzt bisschen sicherer laufen (weil ich in einem sieben Buckets breiten Puffer 4x dieselbe Frequenz in Folge erkennen will um das codierte Zeichen zu erkennen).

Viele Grüße
Martin
PS: @Stefan, ich habe gesehen, dass die Lame-Sourcen komplett mit im SVN zu liegen scheinen, ist das a) eine wahre Aussage und soll das b) so sein?

Buebchen

15.02.2008, 19:33

Viele Grüße
Martin
PS: @Stefan, ich habe gesehen, dass die Lame-Sourcen komplett mit im SVN zu liegen scheinen, ist das a) eine wahre Aussage und soll das b) so sein?

a) Ja
b) Vorläufig ja (insbesondere unter Windows gibt es kein lame-devel Paket, da müßte das makefile sonst einen sinnvollen Hinweis geben, wie man an die richtigen Sources kommt)

mdi

16.02.2008, 12:04

Moinmoin,

da ich die Sourcen erst später "entdeckt" (naja, realisiert) habe, bin ich folgenden Weg gegangen für den Lame:

a) Download der Sourcen von http://lame.sourceforge.net/download.php
b) Entpacken in ein beliebiges Verzeichnis
c) in MSYS: ./configure im entsprechenden Verzeichnis
d) in MSYS: make
e) in MSYS: make install

Tat problemlos.

Viele Grüße
Martin

Buebchen

16.02.2008, 13:30

Ist schon klar, daß das geht. ich denke halt, daß ein Entwickler sowas hin bekommt. Der "normale User" wird da schon schwierigkeiten bekommen. Insbesondere da eben noch kein Hinweis auf Notwendigkeit des zusätzlichen Downloads vorhanden ist. Ansonsten würde auch die lame.h fehlen. Und die braucht man natürlich auf jeden Fall :-)

Ich befasse mich gerade damit wie man automake dazu bewegt rekursiv zu arbeiten. Dann könnte man im configure prüfen, ob der lame sources ordner gefüllt ist und da zusätzlich das configure ausführen. Ebenso könnte man sonst einen Hinweise bringen.

Deswegen meinte ich ja auch, daß es vorläufig erstmal so bleiben sollte. Weniger für die Unix, aber mehr für die Windows User :-)

mdi

16.02.2008, 13:51

Hallo schon wieder ;),

Ist schon klar, daß das geht. ich denke halt, daß ein Entwickler sowas hin bekommt. Der "normale User" wird da schon schwierigkeiten bekommen. Insbesondere da eben noch kein Hinweis auf Notwendigkeit des zusätzlichen Downloads vorhanden ist. Ansonsten würde auch die lame.h fehlen. Und die braucht man natürlich auf jeden Fall :-)
das stimmt, die ist allerdings auch mit im lame-src-Paket enthalten. Bisschen fummelig ist das Ganze eh, spätestens wenn man sich MySQL-Support bauen möchte. Aber ich muss insofern zustimmen als das bisher nirgendwo erwähnt ist.

Deswegen meinte ich ja auch, daß es vorläufig erstmal so bleiben sollte. Weniger für die Unix, aber mehr für die Windows User :-)
*g* - ja, ok; mir fiel eben gerade ein, ob es denn überhaupt User gibt, die sich den Kram selber kompilieren, wenn sie den Aufwand scheuen, sich ein entsprechendes Build-Environment zu bauen. Da wäre ich mittelfristig dafür, nur noch die monitord-Sourcen in /trunk zu haben und entsprechende Hinweise anzubringen, dass für die Plugins etwas fehlt. Für Entwickler sollten wir dann dann eine Anleitung (vorläufig in http://www.funkmeldesystem.de/foren/showthread.php?t=35783) und für die User zum Download fertige Binaries/Installer im Komplettpaket einschließlich Plugins bereitstellen.

Ist das mehrheitsfähig? :D

Martin

nepomuck

26.03.2008, 22:18

Es herrscht mal wieder gespenstische Stille im Forum.
Seid ihr alle noch da? Geht was vorwärts oder droht das Projekt Monitord 2.0 einzuschlafen?

viele Grüße,
Andreas

mdi

02.04.2008, 01:10

Moin,

ich bin noch da, ab und an ;).

Martin

funkwart

02.04.2008, 13:27

...das ist sehr schön.
Interessanter wäre natürlich eine Antwort auf die Frage, ob noch jemand aktiv an dem Projekt arbeitet?
Es ging ja sehr schnell mit sehr vielen Dingen los, aber ganz plötzlich tut sich (nach außen) so gut wie nichts mehr.
Entwickelt Ihr alle fleißig oder habt Ihr aufgegeben?

Gruß,
Funkwart

Buebchen

02.04.2008, 18:11

Also ich für meinen Teil habe im Moment recht viel auf der Arbeit zu tun. Da leidet dann doch die Motivation auch noch in der Freizeit zu programmieren. Ausserdem habe ich die wxWidgets entdeckt (da das einige hier auch verwenden) - da hatte ich dann auch noch Zeit investiert (wie ich denke war das keine so schlechte Idee :-) ).

Ich lade dann doch immer wieder mal den Source. Aber wirklich viel daran arbeiten tue ich zur Zeit ehrlich gesagt nicht. Aber da mir das ganze sehr am Herzen liegt wird das bei mir nicht sterben, sondern liegt nur eine Zeit lang auf Eis.

Als ruhig weiter Ideen posten. Wird dann irgendwann umgesetzt werden :-)

PS: Und zu guter letzt hat mich ein Freund auch noch auf World of Warcraft aufmerksam gemacht. Was man da an Zeit verbringen kann ... Ne Ne Ne ...

jhr-online

02.04.2008, 18:17

Ich seh's den Tag kommen... Die Software ist perfekt; jede Kleinigkeit ist durchdacht; es gibt kein Klicken mehr auf dem BOS-Funk, das nicht entschlüsselt und sachgemäß verarbeitet wird... und dann ruft der Ortsbrandmeister an und meldet sich mit den Worten: "Endlich ist es soweit: der Digitalfunk wird morgen aktiviert - nie wieder Scannerkids!" ;-)

jhr

nepomuck

07.04.2008, 13:25

und dann ruft der Ortsbrandmeister an und meldet sich mit den Worten: "Endlich ist es soweit: der Digitalfunk wird morgen aktiviert

Ich glaube, das dauert noch ein paar Jahre. In unserer Region soll Tetra zwischen 2011 und 2014 kommen. Theoretisch könnten dann alle drei Dienste POL, RD und FW sofort umstellen.
Ich zweifle daran aber stark. Die Grundausbaustufe Tetra sieht vor, dass der Funkverkehr nur außerhalb von Gebäuden funktioniert. Somit läßt sich über Tetra nicht zuverlässig alarmieren (das geht nach meinem Wissensstand erst ab der zweiten Stufe mit mehr Funkmasten). Zudem werden die Landkreise nicht auf einmal hunderte Piepser und dutzende Sirenensteuerungen austauschen.
Also selbst wenn Tetra schon 2011 kommt, werden wir ein paar Jahre das 4m-Netz zumindest für die Alarmierung weiter betreiben.
Bei uns kommt 2009 erst einmal FMS und bis dahin sollte der Monitor 2.x hoffentlich zuverlässig arbeiten :-)

Andreas

mdi

09.04.2008, 18:49

Moinmoin,

ich formuliere es von meiner Seite einmal so: "Meine" ZVEI-Komponente scheint relativ zuverlässig ihren Dienst zu tun (jedenfalls tut sie das bei meiner Installation hier seit mehr als 50 Tagen im Dauerbetrieb mit Datenbankanbindung durch das MySQL-Plugin). Entsprechend habe ich jetzt keinen großen Einsatz mehr gezeigt, daran noch etwas zu ändern, sofern nicht gravierende Bugs gemeldet werden.

Ich habe mich ein wenig damit befasst, einen minimalistischen Client zu bauen (da ist noch offen, wie und ob der im SVN erscheinen soll oder ob nicht) und bin langsam nebenbei dabei, für "meinen Verein" ein Modell einer GUI basierend auf wxWidgets zu entwickeln. Das geht aber recht langsam zur Zeit, weil andere Dinge einfach Vorrang haben (die Einsatz-Saison mit Laufveranstaltungen und dergleichen hat begonnen).

Es wäre schön, wenn wir nochmal darstellen würden, was jetzt eigentlich direkt noch fehlt (ich erinnere mich dunkel an ein nicht vollständig implementiertes Protokoll auf Serverseite, ist das noch richtig?) für die 2.0 - allerdings nehme ich recht stark an, dass wohl vor allem ein Client sowie die History-Funktion am wesentlichsten sind, richtig?

Viele Grüße
Martin

nepomuck

09.04.2008, 19:13

"Meine" ZVEI-Komponente scheint relativ zuverlässig ihren Dienst zu tun

Mal abgesehen von einer meiner Testmaschinen (Thinkpad T43p mit Ubuntu 7.10 x86) wo die ZVEI-Komponente nach wie vor Zahlendreher liefert, während 1.8.1 auf der selben Kiste funktioniert. Aber so lange der Fehler nirgendwo anders auftritt, kann man das wahrscheinlich nicht nachvollziehen.

Ich habe mich ein wenig damit befasst, einen minimalistischen Client zu bauen

Da sehe ich aktuell den größten Bedarf. Hier müßte es doch möglich sein, das bestehende, altmodische aber zuverlässige Text-Frondend der 1.8.1 zu übernehmen. Vieleicht sogar so, das die bestehende .monrc mit minimalen Änderungen weiter funktioniert.

die Einsatz-Saison mit Laufveranstaltungen und dergleichen hat begonnen).
RD? Kardia 1-4?
Irgend eine Saison ist doch immer. Bei uns (FW) beginnt in Kürze die "Sommerreifen-anständig-Probefahren"-Saison, die nahtlos an die Kaminbrand-Saison anschließt.

Es wäre schön, wenn wir nochmal darstellen würden, was jetzt eigentlich direkt noch fehlt

- Frontend
da wäre es schön, wenn einer was systemunabhängiges in Java schreiben könnte. Ein netter Display-Client mit Logbuch und Event-Triggeriung.
- Pocsac (hat noch keiner richtig getestet, speziell 1200er)
- History-Funktion im Server
- Vollständige Protokoll-Implementierung (mit Inquiry, Versionsverhandlung und rec-Funktion)
- Vereinfachte Installation (ohne ./configure --with dies --ohne jenes --modulesoderauchnicht)
- evtl. sogar mit Binary Installer (win) oder Packetmanager (linux deb, rpm)
- Das Ganze auf einer direkt startfähigen Live-CD (Bosix 0.2)

viele Grüße,
Andreas

DocSteel

09.04.2008, 19:45

- Pocsac (hat noch keiner richtig getestet, speziell 1200er)

Läuft hier seit mehreren Wochen problemlos im Dauerbetrieb mit der aktuellen SVN Version als Testobjekt.

nepomuck

09.04.2008, 22:36

Läuft hier seit mehreren Wochen problemlos im Dauerbetrieb mit der aktuellen SVN Version als Testobjekt.
Toll. Ein Punkt weniger auf der Liste. Danke für die Info.
Was nimmst du als Frontend?

Andreas

Buebchen

10.04.2008, 00:28

Also POCSAG mit 512 Baud läuft hier auch schon seit vielen Wochen ohne zu murren (SVN, Windows 2k3 Server als Dienst). Frontend ist selbstgehäkelt und extrem minimalisitisch ( aber immerhin web-basiert :-) ). Selbst kurzfristige Verbindungsunterbrechung zum MySQL Server machten ihm nichts mehr aus.

DocSteel

10.04.2008, 01:03

Toll. Ein Punkt weniger auf der Liste. Danke für die Info.
Was nimmst du als Frontend?

Andreas

Ein minimales PHP Frontend was die SQL DB abfragt und das ganze dann farbig unterlegt und ausgibt mit Auto Refresh und lauffähig auf iPhone und Nokia Handys.

Eine kleine Sache stört aber noch: da ich hier 2 Digis höre (einen schwach einen sehr klar) wird manchmal der schwache ausgewertet und dann der starke nicht mehr so das die Meldungen ab und an mit abgeschnittenem Text in der DB stehen. Wäre schön wenn sich dafür eine Lösung finden würde.

nepomuck

10.04.2008, 12:21

Also POCSAG mit 512 Baud läuft hier auch schon seit vielen Wochen

Wie siehts mit POC1200 aus? Da geht bei mir gar nichts.

Frontend ist selbstgehäkelt und extrem minimalisitisch ( aber immerhin web-basiert :-)

Dennoch wäre es schön, wenn du den Code dafür zur Verfügung stellen könntest. Mach das Frontend nur POC oder auch ZVEI und FMS?

Ein minimales PHP Frontend was die SQL DB abfragt und das ganze dann farbig unterlegt und ausgibt mit Auto Refresh und lauffähig auf iPhone und Nokia Handys.

Auch da wäre es nett, wenn du den Code irgendwo publizieren würdest.

viele Grüße,
Andreas

Buebchen

10.04.2008, 12:53

Zu POCSAG mit 1200 Baud kann ich nix sagen, da wir auf 512 Baud laufen.

Den PHP Code suche ich mal raus. Ist natürlich alles hard-wired :-)

nepomuck

10.04.2008, 15:18

Zu POCSAG mit 1200 Baud kann ich nix sagen, da wir auf 512 Baud laufen.

Soweit ich mich erinnere, stammt der Code von dir. Hast du das noch nie mit poc1200 probiert?

Den PHP Code suche ich mal raus. Ist natürlich alles hard-wired :-)
Macht nix. Ein paar erklärende Kommentarzeilen im Code wirken Wunder.

viele Grüße,
Andreas

DocSteel

10.04.2008, 15:50

Ich hab lediglich das PHP Frontend aus dem Thread hier genommen (Danke an den Urheber) und es um ein paar Kleinigkeiten verfeinert insbesondere:

- Automatische Aktualisierung (alle xx Sekunden) via PHP Header
- Eine Anzeige wann das Frontend zum letzten mal aktualisiert wurde
- Anpassen der HiOrg Liste auf die Bedürfnisse des Kreises
- RIC Filter (Rics die nicht in die DB geschrieben werden sollen) siehe dazu auch meine Lösung hier: http://funkmeldesystem.de/foren/showpost.php?p=284878&postcount=3

Ansonsten funktioniert wie schon geschrieben die 1200 Baud Pocsag Auswertung mit einigen kleine Problemchen. FMS und ZVEI wird hier mangels Eingangssignal momentan nicht betrieben.

Das Frontend stelle ich zum Download bereit sobald ich dazu komme da ein Paket draus zu packen.

Buebchen

10.04.2008, 21:44

Soweit ich mich erinnere, stammt der Code von dir. Hast du das noch nie mit poc1200 probiert?

viele Grüße,
Andreas

Nein - der Code ist nicht von mir. Der Code selbst stammt aus dem monitor Projekt (bzw. multimon). Ich habe zwar einige Teile bearbeitet, aber die Kernkomponenten sind erhalten geblieben. Ich hätte auch zu wenig Erfahrung in Software PLLs um eine anständige und gleichzeitig CPU schonende Sync "mal eben" zu schreiben :-) Da bleibe ich bei dem, was ja schon lange läuft. Ich habe den C Spaghetti-Code nur einmal kräftig entwirrt, damit das Ding überhaupt vernünftig bearbeitet werden kann.

nepomuck

11.04.2008, 15:55

SVN, Windows 2k3 Server als Dienst
Ich würde mir das Ganze gerne auch mal unter Windows ansehen. Was brauche ich an Software, um monitord unter Windows 2003 zu bauen?

Danke,
Andreas

Buebchen

12.04.2008, 14:26

Du kannst zum einen die Installer-Version für Windows nehmen oder aber wenn Du selbst bauen müßtest findest Du hier eine tolle Anleitung von mdi:

http://www.funkmeldesystem.de/foren/showthread.php?t=35783

oldesloer

17.04.2008, 15:14

funkwart

19.04.2008, 00:52

Wenn ich es könnte, dürfte ich es nicht.

Aber mach Dich doch mal im Internet schlau, z.B. hier:
http://www.funkfrequenzen01.de/bos3sh.htm

Gruß,
Funkwart

HeckenPenner

06.08.2008, 15:13

Hi,
könnt ihr mal aus dem aktuellsten Trunk einen neuen Windows Installer kompilieren und veröffentlichen?
Die Version auf der HP ist ja inzwischen ein halbes Jahr alt. Selber kompilieren geht leider nicht da ich nur 64 bit Systeme habe und ich die Anwendung auf ein 32bit Windows portieren muss auf dem ich nicht kompilieren kann.

Und im Anhang noch ein Bild auf ein Frontend für den monitord an dem ich die letzten Tage etwas rumgeschrieben hab. Wenn interresse besteht kann ich davon mal eine Version veröffentlichen.

http://www.projekt-webspace.de/pic/screen_gui4monitord.jpg

Gruß
HP

mdi

06.08.2008, 18:35

Moin,

könnt ihr mal aus dem aktuellsten Trunk einen neuen Windows Installer kompilieren und veröffentlichen?
ist oben. http://www.monitord.de/?article=5

Und im Anhang noch ein Bild auf ein Frontend für den monitord an dem ich die letzten Tage etwas rumgeschrieben hab. Wenn interresse besteht kann ich davon mal eine Version veröffentlichen.[/url]
Gern! In welcher Sprache hast Du das geschrieben?

Viele Grüße
Martin
PS: Ich habe ein Tag im SVN eingerichtet: Aktueller Stand heute, oben genanntes Binary, Name: 2.0-060808-RC1.

ToffiFee

06.08.2008, 20:14

Ah, verdammt, jetzt muss ich euch hier doch belästigen.
Seit vielen vielen Stunden versucher ich monitord ans Laufen zu bekommen. Das tuts auch so weit, aber offenbar funktioniert etwas mit den Servern nicht. Es werden keine Ports geöffnet, nmap sagt mir alles ist dicht (sowohl 127.0.0.1 als auch "reale" ip) und telnet kommt auch nicht durch. Woran kanns liegen?
Mein tcpsocket sieht soweit richtig aus, habe mal zwischen bind sowohl das interface als auch die ip gesetzt
(bind) eth0 (/bind)
(bind) 192.168.178.23 (/bind)
so etwa.
Würde mich über Hilfe freuen,
Gruß,
Bene

P.S. Das system ist logischerweise Linux, also ein Sidux 2008-02.
Vielen Dank an die und Hut ab vor den Leuten die ihre Freizeit opfern um der Welt so geniale Programme zur Verfügung zu Stellen =)

EDIT: Verdammt, da war ja was mit den Spitzklammern... Runde Klammern sind in meiner monitord.xml spitz ;)

mdi

07.08.2008, 02:26

Moinmoin,

Ah, verdammt, jetzt muss ich euch hier doch belästigen.
na also sowas aber auch ;)!

Mein tcpsocket sieht soweit richtig aus, habe mal zwischen bind sowohl das interface als auch die ip gesetzt
(bind) eth0 (/bind)
(bind) 192.168.178.23 (/bind)
so etwa.

Ich habe den Code nicht geschrieben, daher ganz direkt drei Fragen:
a) sind Mehrfachangaben zum jetzigen Zeitpunkt erlaubt? (-> Buebchen?)
b) welche Eingaben können hier getätigt werden (eth0 eher nicht, wenn ich den Code richtig interpretiert habe)?
c) hast Du, ToffiFee, es mal beim * belassen und tut der monitord dann etwas?

Viele Grüße und gute Nacht
Martin

ToffiFee

07.08.2008, 02:41

habs auch mal mit dem vorkonfigurierten "*" belassen, der monitord tut aber dasselbe wie mit allen anderen einstellungen:
<code>
toffifee@siduxbox:~$ monitord
02:36:54.255 INFO: monitord/SocketServer.cpp(660) SocketManager erstellt
02:36:54.256 DEBUG: monitord/MonitorSignals.cpp(21) Signal erstellt...
02:36:54.256 INFO: monitord/MonitorModulesResults.cpp(51) Dispatcher startet
02:36:54.259 DEBUG: monitord/MonitorModulesResults.cpp(88) Dispatcher waiting
02:36:54.260 DEBUG: monitord/MonitorSignals.cpp(60) Waiting for signal
02:36:54.273 DEBUG: monitord/MonitorSignals.cpp(21) Signal erstellt...
Loglevel: INFO
</code>
sieht fuer mich danach aus als waere alles in ordnung, nur wie gesagt, nmap und co. sagen mir saemtliche ports sind zu. Die firewall ists nicht, die ist hardwaremaessig erst ab gateway, software habe ich keine (meiner Meinung nach obsolet).

<code>
Starting Nmap 4.62 ( http://nmap.org ) at 2008-08-07 02:37 CEST
Interesting ports on localhost (127.0.0.1):
Not shown: 1707 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
631/tcp open ipp
3000/tcp open ppp
3306/tcp open mysql
</code>
Gruß,
Bene

HeckenPenner

07.08.2008, 09:45

ist oben. http://www.monitord.de/?article=5

Super! Danke!

Gern! In welcher Sprache hast Du das geschrieben?

Ich habs in Python und wxWidgets geschrieben weil ich die UI Gerne auf allen Platformen nutzen würde. Aber ohne Anpassungen gehts leider nicht.

Gruß
HP

HeckenPenner

07.08.2008, 10:20

Und gleich nochmal was...

Der Server sendet jetzt zur Begrüßung ein "100" ['100', 'monitord 2.0svn READY']
Früher hat er ein "110" gesendet!

Ist das gewollt?

Gruß
HP

ToffiFee

07.08.2008, 14:12

Aaaalso:
Der Server läuft jetz... Mit derselben Konfiguration wie vorher, nur habe ich den Port jetzt einfach mal auf 111 gestellt. Telnet sagt mir:
110:monitord 2.0svn READY
Also bei mir nix 100. Weiß jemand woran das liegt das es auf den Standardports nicht läuft?
Gruß,
Bene

mdi

07.08.2008, 15:10

Moin,

Der Server sendet jetzt zur Begrüßung ein "100" ['100', 'monitord 2.0svn READY']
Früher hat er ein "110" gesendet!

Ist das gewollt?
fuck, hatte ich hier zu schreiben vergessen und auch nicht im SVN eingecheckt sondern nur lokal bei mir geändert und aus den Sourcen den Installer gedreht.
Ja, das ist so gewollt, jedenfalls von mir und ich sollte das mal ins SVN einchecken. 110 ist laut Protokoll-Defnition "Inquiry" und nicht "OK". Daher muss hier eine 100 hin.

Martin
PS (edit): Noch was zum Inquiry, ist es überhaupt sinnvoll, dass der Server ein inquiry macht? Normalerweise muss der Client ja den Server connecten und fragen, was er kann und schauen, ob das zu seinem Befehlssatz matcht. Wenn nicht... pech ;).

mdi

07.08.2008, 15:12

Moin,

Der Server läuft jetz... Mit derselben Konfiguration wie vorher, nur habe ich den Port jetzt einfach mal auf 111 gestellt. Telnet sagt mir:
110:monitord 2.0svn READY
Also bei mir nix 100. Weiß jemand woran das liegt das es auf den Standardports nicht läuft
die 100/110 habe ich ein Posting eher erklärt ;). Ich checks ein gleich...

Dass er nicht auf "seinem" Port läuft, ist komisch. Hast Du dahin auch mal per telnet connected?

Martin

ToffiFee

07.08.2008, 15:59

.

Dass er nicht auf "seinem" Port läuft, ist komisch. Hast Du dahin auch mal per telnet connected?

Klaro. Aber wie gesagt, alles dicht. Wenn ich per telnet auf 111 connecte kommt das protokoll richtig an, er decodiert richtig, die Befehle laufen usw. Habs grad mal mit Port 5000 probier (einfach mal irgendeinen zum Testen genommen, völlig random), da funktionierts auch. Keine Ahnung woran das liegen könnte, wie gesagt, firewall und son Schmarrn hab ich nicht ;)

Übrigens, kann mir jemand ein fähiges Webinterface empfehlen?

Gruß,

Bene

EDIT:
Es geht! Man weiss nicht warum, aber nachdem ich den Port nochmal auf 9333 gesetzt habe laeuft es. Verdammt, ich versteh das nicht, aber mir egal, er läuft =)
Danke Danke Danke für alle vergeblichen versuche mir unter die Arme zu Greifen, manchmal bedarf es eben einer höheren Macht ;)

Aber son Webinterface interessiert mich dennoch ;)

HeckenPenner

07.08.2008, 16:40

Moin,

fuck, hatte ich hier zu schreiben vergessen und auch nicht im SVN eingecheckt sondern nur lokal bei mir geändert und aus den Sourcen den Installer gedreht.
Ja, das ist so gewollt, jedenfalls von mir und ich sollte das mal ins SVN einchecken. 110 ist laut Protokoll-Defnition "Inquiry" und nicht "OK". Daher muss hier eine 100 hin.

Martin
PS (edit): Noch was zum Inquiry, ist es überhaupt sinnvoll, dass der Server ein inquiry macht? Normalerweise muss der Client ja den Server connecten und fragen, was er kann und schauen, ob das zu seinem Befehlssatz matcht. Wenn nicht... pech ;).

Ok, danke!
Find ich jetzt zwar schade, denn das bringt mir den gesamten Login Vorgang durcheinander, macht aber auch mehr Sinn.

Inquiry ist Sinnvoll in so fern, dass der Server abwärtskompatibel ist und auch mit älteren evtl. nicht mehr gepflegten Programmen zusammenarbeiten kann. Dazu müssen sich die beiden halt auf eine Protokoll Version einigen und das geht dann nur per Inquiry.

Gruß
HP

mdi

07.08.2008, 18:40

Moinmoin,

Es geht! Man weiss nicht warum, aber nachdem ich den Port nochmal auf 9333 gesetzt habe laeuft es. Verdammt, ich versteh das nicht, aber mir egal, er läuft =)
Danke Danke Danke für alle vergeblichen versuche mir unter die Arme zu Greifen, manchmal bedarf es eben einer höheren Macht ;)
wem sagst du das... ;D!

Aber son Webinterface interessiert mich dennoch ;)
Dazu gab es hier im monitor-Forum auch schon einige Diskussionen; wie weit die aktuellen Vorhaben derzeit sind, kann ich Dir nicht genau sagen - im SVN gibts aber auch ein Web-Frontend zu finden (PHP).

Find ich jetzt zwar schade, denn das bringt mir den gesamten Login Vorgang durcheinander, macht aber auch mehr Sinn.
Ja, das glaube ich Dir aufs Wort :7. Tut mir leid.

Inquiry ist Sinnvoll in so fern, dass der Server abwärtskompatibel ist und auch mit älteren evtl. nicht mehr gepflegten Programmen zusammenarbeiten kann. Dazu müssen sich die beiden halt auf eine Protokoll Version einigen und das geht dann nur per Inquiry.
Ja sicher, nur ist die Frage: Warum sollte der Server den Client fragen, was der kann? Dass der Client den Server fragt und dann sagt, er möchte mit Version xy sprechen, ok. Aber dass der Server den Client fragen kann und/oder sollte, hat mich grad verwirrt ;).

Viele Grüße
Martin

nepomuck

08.08.2008, 09:29

Moinmoin,
Ja sicher, nur ist die Frage: Warum sollte der Server den Client fragen, was der kann? Dass der Client den Server fragt und dann sagt, er möchte mit Version xy sprechen, ok. Aber dass der Server den Client fragen kann und/oder sollte, hat mich grad verwirrt ;)
Martin

Strenggenommen sollte das eigentlich aussehen:
Wenn die Verbindung steht, sendet der Server ein nacktes 100 als OK, ohne Versionsnummer oder Sonstwas, denn der Befehl 100 hat keine Parameter.

Der Client soll dann einen 210 (inquiry vom Client) an den Server schicken, welcher als Antwort mehrere 111er liefert und dem Client so mitteilt, was der Server alles kann.

Der Server könnte im Gegenzug vom Client ein Inquiry 110 einfordern, auf das der Client mit 211ern antwortet. Diese Funktion ist dafür gedacht, falls jemand auf dem Server eine Liste aktuell angemeldeter Clients verwalten will. Soweit ich weiss, ist das Feature aber im server noch nicht implementiert.

Danach soll von Seiten des Clients der Login "220" erfolgen, der als Paramter den Usernamen, das Passwort und die gewünschte Protokollversion enthält.

Aktuell arbeiten die Test-Setups ohne Logins und daher antwortet der Server momentan direkt mit 100 und Version -- das ist strenggenommen so nicht zulässig.

Die Protokolldefiniton 0.3 berücksichtigt den Sonderfall "Autologin" nicht -- hier sollten wir uns überlegen, wie wir das künftig korrekt handhaben.

viele Grüße,
Andreas

Buebchen

08.08.2008, 18:41

Warum ist ein 100 ...ready unzulässig ? Im Grunde genommen wird der TCP Connect damit bestätigt. Aber wir können da auch gerne einen anderen Code nehmen - Sozusagen für die welcome message ( Vgl. SMTP: "220 Server ready" - nach dem connect ).

Was genau beim bind geht muss ich nachsehen. Ich meine im Moment gehen ausschließlich IP Adressen. Ggf. noch hostnamen. Interfacenamen aber bestimmt nicht. Wäre auch nicht unter windows und Unix kompatibel in dem Fall.

nepomuck

09.08.2008, 02:08

Warum ist ein 100 ...ready unzulässig ?

Wir hatten und bei der Protokolldefinition auf etliche Standards geeinigt:
- Alle Kommandos und Quittungen sind rein nummerisch, Parameter sind durch ":" getrennt und, falls alphanummerisch, in Ascii codiert.
- Das Kommando "100" ist nicht mehr als eine positive Quittung auf ein vom Client abgesetztes Kommando. Laut unserem Standard gibt es bei "100" einfach keine Folgeparamter.

Folglich ist "100 Version xyz Ready" eine unzulässige Antwort.

Für die Beta-Versionen ist sowas ganz nett, da man viel mit einem Telnet-Client arbeitet und sehen will, was los ist. Aber wenn die ersten, richtig funktionellen Forntends da sind, müssen sich die Backend- und Frondend-Entwickler exakt an die Protokolldefinition halten -- sonst wird das ganze nicht funktionieren.

Aber wir können da auch gerne einen anderen Code nehmen - Sozusagen für die welcome message
Das Thema hatten wir schon einmal und haben uns damals gegen eine "lesbare" Welcome-Message entschieden, da ein trockenes "100" als positive Verbindungsbestätigung völlig ausreicht. Und für den Austausch der exakten Versionsinformationen haben wir deshalb das Inquiry-Kommando (210 vom Client an den Server oder 110 vom Server an den Client) mit einer mehrzeiligen Antwort festgelegt. Wobei die Klartextmeldungen Ascii codiert werden müssen.

Ich zitiere das Protokollmanual:

Beispiel (in allen Beispielen wird der Text zwecks der Lesbarkeit in „“ angegeben, statt in ASCII
kodiert):
210 (=Inquiry-Anforderung vom Client)
111:1:“monitord“ (sieht in wirklichkeit so aus: 111:1:6D6F6E69746F7264)
111:2:“LINUX“ (111:1 = Name des Servers, 111:2=OS des Servers 111:3 = Version )
111:3:0021
111:4:0010
111:4:0020 (111:4 = unterstützte Protokollversionen)
111:4:0021
111:5:"REC" (111:5 = unterstützte Module dieses Servers)
111:5:"MYSQL"
111:0

Alle Programmierer müssen sich an die Protokollstandards halten. Wenn jeder eigene Protokollvarienten implementiert, wird die Kommunikation zwischen Client und Server einfach nicht funktionieren.

viele Grüße,
Andreas

Buebchen

09.08.2008, 02:44

Wenn ich das mal so sagen darf:

1. Ich sehe zum einen kein Frontend, daß in absehbarer Zeit zur Verfügung steht
2. Das aktuelle Frontend muss zwangsläufig mit diesem Protokollbruch schon umgehen können, um zu funktionieren. Demzufolge ist es mehr Aufwand die Programme an das Protokoll anzupassen als andersherum.

nepomuck

09.08.2008, 14:16

Das aktuelle Frontend muss zwangsläufig mit diesem Protokollbruch schon umgehen können, um zu funktionieren. Demzufolge ist es mehr Aufwand die Programme an das Protokoll anzupassen als andersherum.
Wozu haben wir uns dann überhaupt auf einenen Protokollstandard geeinigt, wenn sich keiner dran hält?

Client/Server-Applikationen können nunmal nur dann richtig funktionieren, wenn das Protokoll eindeutig vorgegeben ist und sich alle daran halten.

Natürlich können wir jederzeit eine neue Protokollversion 0.4 deklarieren, welche diese Änderungen berücksichtigt.

Ich sehe darin aber keinen Sinn. Warumm sollte der Server klar lesbare Meldungen von sich geben? Das Ziel dieser ganzen Entwicklung ist es doch, dass Client-Tasks mit dem monitord kommunizieren und nicht die Anwender per Telnet die Kommandoausgabe verfolgen, oder?

Dein Änderungswunsch hebelt gleich mehrere Syntaxregeln aus, auf die wir an dieser Stelle vor etlichen Monaten gemeinsam geeinigt hatten:
Dazu gehört, dass Paramter mit ":" getrennt sind und dass wir keinen Klartext übermitteln. Zudem haben alle Kommandos klar deklarierte Paramter. Woran soll der Client erkennen, wann ein OK mit oder ohne Paramter daher kommt und was soll er überhaupt damit anfangen?

Willst du du diese durchaus durchdachten Syntaxregeln auf den Kopf stellen, nur damit der Server freundlich "Hallo" sagen darf?

Ich persönlich halte das für einen absolut kontraproduktiven Vorschlag, weil es die Programmierung von Frondends verkompliziert und das Fehlerrisiko bei der Kommunikation zwischen Client und Server erhöht.

Ich möchte einen Gegenvorschlag machen:
So lange das hier alles im Beta-Stadium ist, fügen wir dem Protokoll zu Debug-Zwecken eine Art Kommentarfeld hinzu:
Am Ende eines Kommandos kann ein ";" als Trennzeichen kommen und dahinter steht, was immer du auch möchtest. Die Client-Entwickler können sich darauf einstellen und einfach alles, was nach dem ";" kommt ignorieren.

Beispiel:

S->C nach Verbindungsaufbau
100;Hallo von CVS 0.5.6a-xy auf Debian
C->S
220;sag mir, wer du bist
111:1:6D6F6E69746F7264;CVS 0.5.6a-xy auf Debian
....

Dann haben wir den freundlichen "Hallo" ohne das Protokoll zu vermurksen. Bei Erreichen einer Final-Release können wir das Kommentarfeld einfach sausen lassen, ohne dass die Clients umprogrammiert werden müssen.

Ist das ein akzeptabler Vorschlag?

viele Grüße,
Andreas