monitor 1.9.0 - aber richtig :)

[mdi]

Hallo nochmal von mir,

ich habe jetzt einige Zeit in Ruhe am Code gesessen - und vor allem die demod-Methode des ZVEI-Moduls neu geschrieben.

Es waren einige Merkwürdigkeiten im Verhalten zu beobachten (unter anderem auch bei der Ausgabe, bei der Fünfton-Folgen mit führender Null gar nicht erst angezeigt wurden, da alles unter 10000 mit einem "return" abgebrochen wurde). Ich habe eine neue Logik geschrieben, die bei meinen Tests recht robust war und auch eine längere Alarmierungsfolge problemlos geschluckt und wie gewünscht ausgegeben hat. Eine "Achttonfolge" habe ich mit dem alten Code reproduzieren können, der neue brachte sie bisher nicht an die Oberfläche.

Die Auswertung des Sirenentons beruht zur Zeit lediglich auf der Auswertung der 1240Hz (obere Hälfte des Doppeltons für den Feueralarm); da war vorher ein Spezialfall definiert, der jedoch auch merkwürdige Dreckeffekte bei der generellen Auswertung der Tonfolgen brachte.

Ich achte _grob_ auf Pausen. Perfekt ist das nicht, lässt sich aber vermutlich nachrüsten. Die Pause-Geschichten liefen im mir vorliegenden Code auch nur unrund, schien mir - jedenfalls gab es da unreachable code und ein "#define Pause" vor einem "return PAUSE", dahinter dann irgendwelche Berechnungen von Pausenzeiten in der Methode "get_pause" - die flog jetzt gnadenlos raus.

Die Ausgabe-Bedingungen sind die folgenden:
a) "unklare Ausloesung" (0) bei "eine Fünftonfolge gelesen, neue Ziffer erkannt" (entsprechend der nächsten, in geringem Abstand zur vorherigen geschickten Tonfolge).
b) "Melderausloesung" (1) bei erkannter Fünftonfolge und erkanntem Melderweckton.
c) "unklare Ausloesung" (0) bei zu langer Pause nach Abschluss der Fünftonfolge aber fehlenden Melder/Sirenentönen.
d) "Sirenenausloesung" (2) bei erkannter Fünftonfolge und anschließendem Sirenenton wie oben geschrieben (NUR die 1240 Hz).

Die Fälle 1 und 2 (Melder und Sirene) ignorieren Zeitbeziehungen, sprich sie schlagen an, sobald der Weck- oder Sirenenton innerhalb der Timeout-Zeit erkannt wird. Das sollte OK sein, da der Melderton (2600 Hz, wie der Ton für die Wiederholung) nicht als erstes Zeichen stehen kann und der Sirenenton 1240 zwar der 1270 (Ziffer 3) nahe liegt aber der Abstand ausreichend groß sein müsste. Ich messe keinerlei Längen der einzelnen Töne (70ms wäre Standard für eine Frequenz/eine Ziffer), das ist entsprechend im Code kommentiert - allerdings aufgrund der Geschichte mit dem Wiederholungston auch nicht so wichtig (da nicht zweimal der selbe Ton kommen darf, wäre eine Zeitbeziehung einzubauen im Ergebnis nur der Hinweis auf einen falsch arbeitenden Sender).

Was war noch *grübel* - ach ja: Ich verbrauche jetzt möglicherweise eine Kleinigkeit mehr Speicher, da ich die Fünftonfolge in "int zvei_folge[5]" ablege statt in einem Konstrukt, auf das mit Bits geschossen wurde. Sicherlich war das elegant, macht den Code aber schwerer verständlich. Auf der anderen Seite habe ich einige Variablen gespart - ich habs nicht nachgerechnet.

Ja... Patches sind erstellt, soll ich die jemandem mailen oder selber ins SVN einpflegen (Zugang vorausgesetzt)?

Viele Grüße
Martin

[Buebchen]

Das klingt ja richtig toll. Ich denke, ein eigener Commit wäre sinnvoll. SVN Zugangsdaten gibts bei jhr-online.

Bin sehr gespannt.

[mdi]

Hallo,

das neue ZVEI-Modul ist von mir eben ins SVN eingecheckt worden (danke für den schnellen Zugang :)!) und sollte damit allen zur Verfügung stehen.

Die von mir geschriebene Sirenentonerkennung stellte sich bei weiteren Versuchen als wackelig heraus, auch wenn nur die 1240Hz als Trigger verwendet wurde. Der Grund dafür ist, dass die Algorithmen zur Frequenzsuche erst eine Matrix aufspannen, diese dann aber durch "find_max_index()" auf ein einzelnes, eindeutiges Zeichen heruntergebrochen wird. Die implementierten Filter für Rauschabstand und Eindeutigkeit verhindern damit die Erkennung der Sirenen-Doppeltöne. Ich werde also auch da noch Hand anlegen müssen (vermutlich werde ich die Energie der 675Hz auf die Energie des oberen Doppeltons aufaddieren, womit wieder eine eindeutige Frequenz auffindbar ist und die anderen Kontrollen weiterhin auch für den Sirenenton aktiv bleiben können).

Seit meinem letzten Posting habe ich ein paar Tests mit abgebrochenen/schlecht übertragenen/unterbrochenen/stark verrauschten Tonfolgen gemacht und noch einige Verbesserungen bezüglich der Fehlerunterdrückung eingeführt.

Nebenbei gleich noch eine andere Frage zum Ablegen/Speichern der Alarmierungen: Gibt es im monitor
a) ein SQLite-Backend?
b) ein Backend für HTTP-Anfragen (GET oder POST) zur Übergabe der Daten an einen Webserver (z.B. via http://server/store_zvei.php?folge=[abcde]&typ=[0|1|2]&time=[timestamp])?

Viele Grüße
Martin

PS: Spricht etwas dagegen, die libcurl als Library für ein HTTP-Backend zu nutzen?

[nepomuck]

Hallo Martin,

Erst einmal vielen Dank für dein Engagement bei diesem Projekt.
Ich werde den neuen ZVEI-Code gleich unter Linux gehörig stressen.

Ein paar Anregungen hätte ich noch:

a) "unklare Ausloesung" (0) bei "eine Fünftonfolge gelesen, neue Ziffer erkannt" (entsprechend der nächsten, in geringem Abstand zur vorherigen geschickten Tonfolge).
b) "Melderausloesung" (1) bei erkannter Fünftonfolge und erkanntem Melderweckton.
c) "unklare Ausloesung" (0) bei zu langer Pause nach Abschluss der Fünftonfolge aber fehlenden Melder/Sirenentönen.
d) "Sirenenausloesung" (2) bei erkannter Fünftonfolge und anschließendem Sirenenton wie oben geschrieben (NUR die 1240 Hz).

Die Rettungsdienste in unserer Gegend lösen Melder generell ohne den alten Melderweckton aus. Nur wenn die Leitstelle nicht über den Computer, sondern manuell über den alten Geber alarmiert, folgt das Piepsen auf die Fünfton-Folge.

Die Auswertung sollte daher zwischen a) und c) unterscheiden und unterschiedliche Statusmeldungen für beide Fälle ausgeben. Ich biete euch an dieser Stelle nochmal an, das bestehende Protokoll zu überarbeiten, um diese und andere Kommandos und Statusmeldungen einzupflegen.

Wie aufwändig ist es, andere Dualton-Dekodierungen einzubauen? Neben "Feueralarm" kommen in der Praxis vor allem "Testalarmierung" und "Katastrophenalarm" zum Einsatz. Es wäre schön, wenn der monitor diese Töne erkennt und korrekt auswertet.

Nebenbei gleich noch eine andere Frage zum Ablegen/Speichern der Alarmierungen: Gibt es im monitor
a) ein SQLite-Backend?
b) ein Backend für HTTP-Anfragen (GET oder POST) zur Übergabe der Daten an einen Webserver

Noch nicht. Der unrsprüngliche Plan sah vor, SQL-Datenspeicerung über einen Client abzuwickeln -- der natürlich auf der selben Maschine laufen könnte.

Zwischenzeitlich haben wir über eine optionale DB-Anbindung des Backends diskutiert, um den Monitor-Clients History-Funktionen zu ermöglichen. In Sachen Code hat sich hier aber noch nichts getan.
Web-Funktionen liessen sich über ein reguläres PHP-Backend umsetzen.

Ich finde allerdings, dass der monitord-Dienst an sich so klein wie eben möglich gehalten werden sollte, so dass er auf lausigen alten PCs läuft, die ein völlig abgespecktes Linux von CD oder USB booten.

viele Grüße,
Andreas

[mdi]

Hallo Andreas,

Erst einmal vielen Dank für dein Engagement bei diesem Projekt.

gern; ich habe zur Zeit eben selber eine gehörige Portion Interesse daran und bin schon sehr angetan, auf welch breiter Grundlage man hier mitarbeiten kann :)!

Ich werde den neuen ZVEI-Code gleich unter Linux gehörig stressen.

Das ist gut; ich habe zur Zeit leider keine sinnvolle Möglichkeit, den "mal eben" unter Linux zu testen ohne große Aktionen machen zu müssen. Muss dringend mal wieder ein Multiboot-System einrichten ;). Feedback ist gerne genommen; meine C/C++-Programmierkünste sind ein wenig eingerostet in den letzten Jahren.

Die Geschichte mit dem Unterscheiden der beiden Fälle "unklare Auslösung" wäre vom Code her kein Problem - da sowieso unterschiedliche Stellen für die Ausgabe zuständig sind, bräuchte man nur wie Du schriebst entsprechend eine weitere Definition. Ich weiß allerdings nicht, auf welchen Argumenten die bisherige fußt!

Wie aufwändig ist es, andere Dualton-Dekodierungen einzubauen? Neben "Feueralarm" kommen in der Praxis vor allem "Testalarmierung" und "Katastrophenalarm" zum Einsatz. Es wäre schön, wenn der monitor diese Töne erkennt und korrekt auswertet.

Das ist ein wenig Aufwand aber wie geschrieben noch zu machen und alles andere als vom Tisch, wenngleich bei mir zur Zeit etwas geringer priorisiert (da ich nur die echten Fünftonfolgen brauche -> Betriebsfunk). Notwendig ist dafür die Überarbeitung der process_block()-Methode, da diese zur Zeit nur Einzelfrequenzen erkennen bzw. zurückmelden (return int Frequenz-Index) kann. Lösungsansätze habe ich schon im Kopf, allerdings wird der Eingriff etwas umfassender, weil dafür vermutlich auch die diversen Matrizen erweitert werden müssen und ich in dem Zuge gleich alle im ZVEI-Standard definierten Buchstaben (A, C, J, ...) mit einbauen wollte - vielleicht braucht sie einmal jemand (ich brauche nur das A, das ist prinzipiell schon da, wird aber noch nicht weiter behandelt). Für die Fälle der Sirenentöne müssten dann auch entsprechende Typ-Nummern vergeben und im Protokoll integriert werden (oder gibt es die schon?).

Noch nicht. Der unrsprüngliche Plan sah vor, SQL-Datenspeicerung über einen Client abzuwickeln -- der natürlich auf der selben Maschine laufen könnte.

Hm, dem SVN-Inhalt nach zu urteilen gibt es bereits eine MySQL-Storage-Engine, die entsprechendes für MySQL tun könnte. Wie ist da der Stand der Dinge?

Web-Funktionen liessen sich über ein reguläres PHP-Backend umsetzen.

Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).
Mir schwebte vor, dass die StoreResult()-Methode in der Lage wäre, eine noch zu schreibende HTTPStorage-Engine zu nutzen, um per HTTP GET (oder auch POST, das kann man ja beliebig ausweiten) die Telegramme/Tonfolgen/... an einen Webserver zu übergeben. Das hätte in meinen Augen den Vorteil, dass diese nicht nur über eine dauerhaft bestehende TCP-Verbindung (entsprechend FMS/Crusader/monitor-Socket) erhältlich wären sondern (in der monitor.xml konfigurierbar) per HTTP an ein PHP-Skript "gepusht" werden könnten, was sie dann wie der Anwender möchte weiterverarbeitet. Oder gibt es etwas ähnliches schon und ich habe Tomaten auf den Augen, weil ich bisher nur die ZVEI-Codes angeschaut habe?

Ich finde allerdings, dass der monitord-Dienst an sich so klein wie eben möglich gehalten werden sollte, so dass er auf lausigen alten PCs läuft, die ein völlig abgespecktes Linux von CD oder USB booten.

Ja, das wäre gut, keine Frage. Ist halt die Frage, ob die Einbindung von libcurl da schon ein Problem wäre oder ob nicht. Meine Tests eben (Windows only) verliefen sehr vielversprechend und würden genau meinen Wunsch von oben realisieren: Übergabe der Daten an einen Webserver zur Weiterverarbeitung mittels PHP wie auch immer gewünscht.

Viele Grüße
Martin

[Buebchen]

Ich werde auch den Ansatz der StorageModule weiter verfolgen. Einfach aus eigenem interesse - Das MySQL Modul war mal so ein Ansatz zwischendurch :-)

Vorher möchte ich aber die Kommunikation der Auswertungsmodule zu den Display und Storagemoduln nochmal überarbeiten. Ich könnte mir gut ein std::map vorstellen, daß durch das Auswertungsmodul gefüllt wird und dann an eine std::list aller StorageModule geht. Der Auswerter kann dann auch neue Daten hinzufügen, die dem StorageModul nicht schaden, wenn es sie nicht versteht.

Ein Beispiel könnte sein, daß der Auswerter folgendes liefert:

data['typ']='zvei'
data['kennung']='12345'
data['Weckton']='Sirene'

Und das Storagemodul aber nur 'typ' und 'Kennung' nutzt (weil es den Eintrag 'Weckton' noch nicht gab, als das StorageModul gemacht wurde).

Nicht so umfangreich wie XML. Aber doch flexibel und vor allen Dingen erweiterbar. Kennt das StorageModul den typ der Daten nicht, kann es ihn ignorieren. Fehlende Felder (aus Sicht des StorageModuls) hätten automatisch einen leeren Wert.

Was halten denn die anderen von dem Ansatz ?

[nepomuck]

Ein Beispiel könnte sein, daß der Auswerter folgendes liefert:
data['typ']='zvei'
data['kennung']='12345'
data['Weckton']='Sirene'

Wobei data['Weckton'] folgende Ergebnisse liefern kann:
Ohne, Weckton, Feuer, Test, Katastrophe, Warnung, Entwarnung
Dieses Konstrukt läßt aber keinen Platz für "unklare Auslösung". Erkennt der Dekodierer einen möglichen Fehler, wenn das Signal schlecht, verzerrt oder überlagert ist?

Würde dann ein data['klare Auslösung'](Boolean)=1 (Fehlerfreie Dekodierung) oder =0 (mögliche Falsche Codefolge) Sinn machen?

Öh... das habe ich jetzt nicht ganz verstanden, muss ich ehrlich sagen ;).

Der Ansatz war hier, das monitor selbst nicht mit dem Web-Server spricht, sondern sich dieser per php aus der Datenbank bedient, die monitor füttert.
Bei deinem Vorhaben würde vom monitor aus direkt auf einen Webserver schreiben. Das ist eine gute Idee, aber ich würde diese Funktion lieber in einem Client-Modul sehen als direkt im monotord-Code.

Hm, dem SVN-Inhalt nach zu urteilen gibt es bereits eine MySQL-Storage-Engine, die entsprechendes für MySQL tun könnte.

Richtig. Das Problem der existierenden monitor-Version mit mysql-Engine ist nur, dass sie zu monolithisch aufgebaut ist und viele Dependencies hat. Die läuft nicht auf jedem Linux. Deshalb sind wir ja hier, um eine modulare Version zu schaffen. Der bestehende MySQL-Code liesse sich auf einem Client umsetzen.

@Buebchen: Wie sieht es eigentlich mit den Soundkartenfunktionen aus?
Wenn ich mich an die Überarbeitung des Protokolls mache, würde ich dabei gerne die Befehle für die Aufzeichnung integrieren. Liesse es das Backend zu, dass mehrere Tasks simultan von ein und dem selben Kanal aufzeichnen? Dann könnten mehrere Clients unabhängi voneinander Aufnehmen.
Wird es nun ein (optionales) MySQL-Modul im Backend geben oder nicht -- irgendwann müssen wir uns entscheiden.
Dann müssten nämlich die passenden Befehle ins Protokoll, wie "SendLastAlarms" oder so.

Mein Vorschlag: Wir lassen für die erste "Final" Version 2.0 von monitord und des Protokolls das SQL-Backend weg und konzentrieren uns auf die Dekodierung. Auch das Recording sollte drin sein.
Für 2.2 nehmen wir uns dann das MySQL-Backend und/oder die HTTP-Push-Engine vor.


Viele Grüße,
Andreas