monitor 1.9.0 - aber richtig :)

[mdi]

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

[MacLeod]

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

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]

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

[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