monitor 1.9.0 - aber richtig :)

[mdi]

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]

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]

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]

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]

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

[MacLeod]

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]

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]

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]

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 

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 

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

bye
Einhirn