monitor 1.9.0 - aber richtig :)

[nepomuck]

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]

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$