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

[funkwart]

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

[Klugscheissmodus]
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!
[/Klugscheissmodus]

Trotzdem schonmal danke und Gruß,
Funkwart

;-)

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

[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

[nepomuck]

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]

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