monitord erkennt ZVEI-Alarmierungen doppelt

Druckbare Version

15.04.2009, 17:32
cwh

monitord erkennt ZVEI-Alarmierungen doppelt

Hi,

ich hab derzeit nen monitord laufen und mußte feststellen, daß er leider ZVEI-Alarmierungen doppelt erkennt. einmal als unklare Auslösung und direkt danach dann mit der entsprechenden Sirenenauslösung.

Ich vermute mal monitord erwartet eine kürzere Pause zwischen der Fünftonfolge und deren Wiederholung?

Einfach konfigurieren kann man das anscheinend nicht, an welcher stelle im Code kann ich denn die Pausenlänge verändern?

Ich hab trunk ausgecheckt und schätze mal es ist in MonitorModuleZVEI.cpp in Zeile 261 die 64?

Christopher
15.04.2009, 22:48
mdi

Hallo Christopher,

des Pudels Kern wird sein, dass die Fünftonfolge ja tatsächlich zweimal ausgesendet wird, um die Alarmierungssicherheit zu erhöhen. Der Sirenen-Steuerton wird erst nach dem zweiten Ablauf der Fünftonfolge (mit etwas Abstand) gesendet. Damit erkennt der monitord einmal eine unklare Alarmierung (weil direkt danach eine weitere Fünftonfolge kommt) und meldet beim zweitenmal dieselbe Folge _mit_ Sirenenton (2 - Sirenenalarm Feuer oder halt was kommt). Eine Unterdrückung "doppelter" Erkennungen derselben Tonfolge ist monitord-seitig nicht vorgesehen (und würde auch nur bedingt Sinn ergeben, da er schlicht nur decodieren und ausgeben soll, was er bekommt). Das Ausblenden von doppelten Erkennungen ist entsprechend Client-Sache. Weiterhin ist im monitord keinerlei Logik zum Erkennen "gleicher, aufeinander folgender" Fünftonfolgen implementiert.

Die von Dir gefundene "64" bedeutet: "Wenn zu 64 aufeinander folgenden Zeitpunkten kein Signal decodiert werden konnte, vorher aber eine gültige Fünftonfolge decodiert wurde, gib diese als unklare Alarmierung aus, da kein Sirenen- oder Melderweckton kam, der ungefähr ins notwendige Zeitmaß passt". Damit wird Dir eine Änderung der benannten Pausenlänge bei dem Problem nicht helfen.

Viele Grüße
Martin
17.04.2009, 16:43
cwh

Hi Martin,

laut http://www.berli.net/funk/selekt-2.html ist doch eine Alarmierung über ZVEI mit eben zwei aufeinander folgenden, identischen Fünftonfolgen gefolgt von einem (oder keinem) Sirenendoppelton definiert. Insofern hätte ich schon gedacht, daß das im Zuständigkeitsbereich von monitord läge, die zwei Fünftonfolgen als zusammengehörig zu erkennen.

Nachdem ja ein Sirenenton auch der vorherigen Fünftonfolge zugeordnet wird, wäre es konsequent, daß er auch die beiden aufeinanderfolgenden Fünftonfolgen einander zugeordnet werden.

Würde man deine Interpretation konsequent verfolgen, mußte der Sirenenton auch separat gemeldet werden und erst vom Client den vorangegangenen Fünftonfolgen zugeordnet werden.

Andererseits isses natürlich wirklich trivial das im Client abzufangen und ich will eigentlich auch nicht Kniefieseln. ;)

Noch was anderes:
Ich stricke grade in Perl nen Mail/SMS Alarmierclient für monitord.
Ich hatte schon vor zwei Jahren mal angefangen das mit monitor zu machen und mir damals schon vorgenommen aus monitor nen daemon zu bauen. Hab ich nur aus Lust/Zeitmangel nie angefangen. Daher bin ich jetzt umso erfreuter, daß Ihr das schon sehr gut erledigt habt. :)

Außerdem versuche ich grade im openSUSE Buildservice ein RPM vom monitord zu bauen. Ich stolpere dabei grade über automake/autoconf Probleme. Bekomm ich aber schon noch hin und werd das hier dann posten.

Christopher
17.04.2009, 21:19
mdi

Hallo Christopher,

Zitat:

Zitat von cwh

Nachdem ja ein Sirenenton auch der vorherigen Fünftonfolge zugeordnet wird, wäre es konsequent, daß er auch die beiden aufeinanderfolgenden Fünftonfolgen einander zugeordnet werden.

Würde man deine Interpretation konsequent verfolgen, mußte der Sirenenton auch separat gemeldet werden und erst vom Client den vorangegangenen Fünftonfolgen zugeordnet werden.

naja, grundsätzlich ist die Argumentation schon logisch - sie vergisst aber in meinen Augen, dass der Sirenensteuerton zwangsweise einer vorhergehenden Fünftonfolge zugeordnet werden muss, da sonst nicht bekannt ist, welche Sirene denn nun auslösen soll. Im Gegensatz dazu ergeben Fünftonfolgen auch ohne Wiederholung einen Sinn, da ihre doppelte Aussendung bei den BOS die Alarmierungssicherheit erhöhen soll, z.B. im Betriebsfunk aber Selektivruf-Empfänger und -Absender markieren (einzeln). Auch bei fehlerhafter Erkennung einer Ziffer im ersten oder zweiten Durchlauf wird im momentanen Verfahren immer noch einmal die richtige und einmal die falsche Folge decodiert und direkt ausgegeben. Würde man immer doppelte Folgen erwarten, müsste man die komplette Alarmierung der Schleife sowie die Pausenzeit zwischen Tonfolge und Sirenensteuer- oder Melderweckton abwarten, bevor man eine "sinnvolle" Entscheidung hinsichtlich der Ausgabe treffen kann. Das macht es dann deutlich weniger zeitnah. Ein anderer Aspekt wäre dann, nicht im "Einzugsbereich" liegende Fünftonfolgen unterdrücken zu können, da es sich nur um fehlerhaft erkannte Folgen handeln kann. Letztendlich wäre das ein Fass ohne Boden (und wäre wie man es macht auch nicht jedem recht ;))... von daher wurde ganz bewusst die derzeitige Funktionalität implementiert.

Zitat:

Zitat von cwh

Andererseits isses natürlich wirklich trivial das im Client abzufangen und ich will eigentlich auch nicht Kniefieseln. ;)

Lass mein Knie in Frieden ;D! BTW: So weit ich mich erinnere, ist auch beim FMS32 Pro z.B. ein Switch vorhanden, der "Doppelte Tonfolgen ausblendet" (sprich annahmehalber und ohne das zu verfizieren wohl die Dopplung erkennt, die erste verwirft und dann auf die zweite die Sirenen- oder Meldergeschichte wirft respektive die entsprechend bereits ausgegebene Anzeige anpasst - diese Möglichkeit, die Ausgabe des Clients anzupassen, hat der monitord jedoch definitiv nicht).

Zitat:

Zitat von cwh

Noch was anderes:
Ich stricke grade in Perl nen Mail/SMS Alarmierclient für monitord.
Ich hatte schon vor zwei Jahren mal angefangen das mit monitor zu machen und mir damals schon vorgenommen aus monitor nen daemon zu bauen. Hab ich nur aus Lust/Zeitmangel nie angefangen. Daher bin ich jetzt umso erfreuter, daß Ihr das schon sehr gut erledigt habt. :)

*g* - ich schreibe mal ein "dankeschön, gern geschehen", wenngleich meinereiner sich da lediglich die Butter für den aktuellen Fünftonfolgen-Decoder vom Brot nehmen darf.

Zitat:

Zitat von cwh

Außerdem versuche ich grade im openSUSE Buildservice ein RPM vom monitord zu bauen. Ich stolpere dabei grade über automake/autoconf Probleme. Bekomm ich aber schon noch hin und werd das hier dann posten.

Das klingt gut; in dem Bereich sind wir leider noch nicht besonders weit.

Viele Grüße
Martin