monitor 1.9.0 - aber richtig :)

[mdi]

Moin,

PS: Wie sieht's eigentlich mit einer Dokumentation zum Format der monitord.xml aus?

der Versuch einer Anleitung:
http://www.monitord.de/index.php?article=3 (noch nicht offiziell, aber ich denke, hier im Forum kann mans schon mal zeigen).

Martin

[Buebchen]

Also mir gefällt das Ergebnis vom CMS schon !

Für die XML-Dateien habe ich auch ein hübsches Tool, um das farbig zu machen: Hightlight Code Converter von www.andre-simon.de

Nehme gerne für Dokumentationen :-)

[nepomuck]

Hallo nochmal,

Auf meinem FTP-Server liegt ein Testfile für ZVEI- und FMS-Funktionen zum Download:

ftp://andi.rw-labs.de/pub/fmszveitest.mp3

Das Ganze wurde mit dem BOS-Tool erstellt und besteht aus zwei Komponenten:

ZVEI: Die Testserie beginnt mit einer Reihe von Schleifen mit allen möglichen Sirenentönen. Stand heute dekodiert Monitor die verschiedenen DTFM-Töne noch nicht korrekt.
Anschliessend folgt eine Reihe einzelner Schleifen ohne Wiederholung. Nach den Ziffern 1-9 enthalten diese Schleifen auch die Sonderzeichen A, J, F und U. Diese Schleifen kann der monitor aktuell auch noch nicht dekodieren. Es folgt eine Serie nummerischer Schleifen mit Wiederholung. Die ZVEI-Testserie beendet eine 00000 mit Entwarnungston.

FMS: Am Angang gehen zwei Textmeldungen raus, dann folgen alle Statusmeldungen vom umd zum Fahrzeug. Und am Ende kommen zwei Meldungen mit einem fünfstelligen Folgetelegramm. Die letzten Telegramme dekodiert Monitor noch nicht korrekt.

Das Test-MP3 ist Stereo. Am Anfang kommt der ZVEI-Test rechts und FMS links, später wiederholen sich beide Test auf den jeweils anderen Kanälen.

viel Spass beim Testen,
Andreas

[Buebchen]

Was genau sollte denn rauskommen ?

Er wertet bei mir haufenweise ZVEI und FMS aus. Da ich das Soll nicht kenne, kann ich das Ist nicht bewerten :-(

Was sind z.B. bei FMS die letzten Telegramme, die er nicht erkennt. Die würde ich sonst selbst im BOS-Tool nachbauen.

[nepomuck]

Was genau sollte denn rauskommen ?

Hier der "Bauplan" der Testdatei.

ZVEI:
00000 ohne Folgeton, 00000 Melderton 1, 00111 Feuer, 00112 Test, 00113 Zivilschutzalarm, 00114 Zivilschutzwarnung, 00115 Zivilschutzentwarnung, 00222 Melderton 2
bis hierhin alle Schleifen doppelt. Dann einzeln:
00123, 00234, 00345, 00456, 00567, 00678, 00789, 00890, dann einige Schleifen mit den Sonderzeichen A, C, H, U, L und J, gefolgt von 00111 Test. (MDI erwähnte mal, er wolle die Sondertöne dekodieren und nutzt einzelne Schleifen oder Wiederholung, daher habe ich sie in die Testalarmierung eingebaut)

Dann wieder doppelt: 00111, 00122 bis 00199 ohne Melderton und 00000 Zivilschutzentwarnung als Abschluss.

FMS:
Zwei Mal FMS-Kurztest "Franz jagt im verwahrlosten Taxi quer durch Bayern" an Fahrzeug: 63915401 mit Erreichbarkeitsanfrage, Quittung etc.
Dann FMS-Staus 1 bis 15 zur Leitstelle von Fahrzeug 63915401 mit Quittung und Wiederholung mit Baustufe 2 und TKI I.
Dann FMS-Status A bis u zum Fahrzeug ebenfalls mit Quittung und Wiederholung, Baustufe 2 TKI I.
Das BOS-Tool wiederholt bei einigen Statusmedlungen das Telegramm nicht -- keine Ahnung warum.
Abschliessend mehrfach FMS-Folgetelegramme mit ABCDEF oder 12345 als Folge (werden nicht dekodiert).

Andreas

[Buebchen]

Ah. Also ZVEI lass ich für mich mal aussen vor. Ich würde dann bei FMS schauen. Da geht alles bis auf die Folgetelegramm Fzg->Lst ?

[stadel21]

hihi das finde ich ja mal ganz interessant. Das gleiche würde mich mal für Pocsag interessieren. Ich würd sagen bei mir hat so zu 90 % alles richtig decodiert. :-)

[mdi]

Hallo Andreas,

ZVEI: Die Testserie beginnt mit einer Reihe von Schleifen mit allen möglichen Sirenentönen. Stand heute dekodiert Monitor die verschiedenen DTFM-Töne noch nicht korrekt.

vorweg: Cooles Testfile, gut gemacht :)!

Die Sirenentöne werden nun korrekt erkannt (Rev. 279/SVN).

Die Sonderzeichen sind aber noch immer nicht implementiert :´(.
Ich habe mich eben damit befassen wollen - allerdings stoße ich auf das Problem, sie hinterher auszugeben. Die ZVEI-Folge ist als "text5" im Protokoll spezifiziert, erlaubte Zeichen sind aber nur A-F, womit J, U und so weiter rausfallen würden. Was tun? Möglich wäre ein "Mapping" (A=A, B=H, C=C, D=J, E=L, F=U - wobei das P wegfallen würde), was haltet Ihr davon? Oder kann man in dem Feld direkt das Zeichen angeben (z.B. 8A0J6)?

Letzte Änderung:
Ich hatte ab und an Probleme mit der Stereo-Auswertung der ZVEI-Tonfolgen. Warum auch immer. Vielleicht war ich doch nur zu blöd, das Mikro abzuschalten.

Martin
PS: Und nochwas, ich kriege bei der Ausgabe nicht mehr "Kanal 2", wie in der monitord.xml eingetragen, sondern "1" als Kanalbezeichnung.

[nepomuck]

Ich würde dann bei FMS schauen. Da geht alles bis auf die Folgetelegramm Fzg->Lst ?

Korrekt. Da wir hier noch kein FMS verwenden kann ich dir aber nicht sagen, ob diese Funktion in der Praxis überhaupt genutzt wird.

Das gleiche würde mich mal für Pocsag interessieren.

Läßt sich einfach realisieren (zumindest mit meinem Setup):
Linux-Box mit VMWare. Unter VMWare läuft Windows mit BOS-Tool. Der Linux Mixer stellt den REC-Eingang auf Volume, folglich nimmt der Audiorecoder das auf, was die Soundkarte ausgibt :-)
Unter Linux Audiorecorder starten und Aufnehmen, in der Windows-VM mit dem BOS-Tool die Test-Sounds generieren. Die Demo des BOS-Tools steigt zwar immer wieder aus, aber das macht nichts. Die fertige Aufzeichnung des Audiorecorders läßt sich später mit Audacity oder anderen Tools zusammenschneiden.

Auf die Tour liesse sich auch ein Pocsac-Testfile generieren. Sagt mir Bescheid, wenn ihr sowas braucht und was drin sein soll.

Die Sirenentöne werden nun korrekt erkannt (Rev. 279/SVN).

Das ging ja Superflott! Ich werde es gleich testen.

erlaubte Zeichen sind aber nur A-F, womit J, U und so weiter rausfallen würden. Was tun?

Ich habe im Netz gesucht und das hier gefunden:

ton ZVEI1    ZVEI2
1   1060 Hz  1060 Hz 
2   1160 Hz  1160 Hz 
3   1270 Hz  1270 Hz 
4   1400 Hz  1400 Hz 
5   1530 Hz  1530 Hz 
6   1670 Hz  1670 Hz 
7   1830 Hz  1830 Hz 
8   2000 Hz  2000 Hz 
9   2200 Hz  2200 Hz 
0   2400 Hz  2400 Hz 
E/W 2600 Hz  970 Hz 
A/N 2800 Hz  885 Hz 
C   810 Hz   810 Hz 
H   885 Hz   2800 Hz 
U   1750 Hz  1750 Hz 
L   1860 Hz  1860 Hz 
J   2135 Hz  2135 Hz 
P   2280 Hz  2280 Hz

Du könntest den Dekoder so programmieren, dass er sowohl 2600 als auch 970 Hz als W(iederholungston) akzeptiert und die Buchstaben "A" als 2800 Hz und "H" als 885 Hz dekodiert. Dann beherrscht Monitor sowohl ZVEI-1 als auch ZVEI-2, wobei ein ZVEI-2-Anwender wissen muss, dass unser Programm dabei A und H vertauscht.

Oder wir setzen es "Super Korrekt" um und führen einen Switch in der monitord.xml ein:

für ZVEI-1 wie gehabt

(module type="zvei")
(/module)

und für ZVEI-2

(module type="zvei2")
(/module)

Wobei fraglich ist, ob das in der Praxis überhaupt irgendjemand braucht.

viele Grüße,
Andreas

[Buebchen]

Oder wir setzen es "Super Korrekt" um und führen einen Switch in der monitord.xml ein:

für ZVEI-1 wie gehabt

(module type="zvei")
(/module)

und für ZVEI-2

(module type="zvei2")
(module)

Wobei fraglich ist, ob das in der Praxis überhaupt irgendjemand braucht.

viele Grüße,
Andreas

oder vielleicht noch eleganter:

(module type="zvei")
(zveitype) 2 (zveitype)
(/module)

Denn der Rest vom Modul ist doch m.E. identisch. Ändert sich nicht nur die Frequenztabelle ?

[mdi]

Heyho,

das hier genannte "Problem" ist sicherlich auch ein interessantes, aber es geht erstmal um die Ausgabe der erkannten Zeichenfolge...

Bisher waren das nur Zahlen, so isses auch im monitord-Protokoll problemlos integrierbar. Nun kommen aber Buchstaben "größer als" F hinzu, die angezeigt werden müssten. Das hat mit ZVEI-1 oder ZVEI-2 erstmal nix zu tun. Die Frage ist, ob ich die Zeichenkette "8AJHP" so am Socket ausgeben kann oder ob das codiert werden muss, was dann natürlich mehr Zeichen draus machen würde. Oder bin ich auch dem falschen Dampfer und es wird eh alles codiert und decodiert?

Weiterhin muss ich feststellen, dass das mit den Zeichen noch ein wenig dauern wird, da dafür ein Umsetzen der Frequenz zum auszugebenden Zeichen notwendig wird, das muss ich mir aber in Ruhe überlegen, wie das am sinnvollsten/optimalsten zu implementieren ist.

Martin