monitor 1.9.0 - aber richtig :)

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

[MacLeod]

jupp make lüppt unter linux durch und text wird angezeigt:

textuebertragung = "&12:03: 258..*wlnotf*hunf*.......*.........*...........*>* **"

wobei ich ort*straße*name mit ...... rausgenommen habe

wie du schon sagtest, es fehlt nur noch die implementierung der einzelnen socketthreads
:-))))
klasse arbeit :-))))

wäre es nicht möglich debug in eine logdatei zu schieben?

Thomas

ach ja, hatte ich vergessen...
featurewünsche erst für die version 2.1 ... *rolleyes*

[Buebchen]

So, nächte Rev. liegt im SVN. Irgendwie war mein Eclipse Plugin ein wenig verwirrt. Aktuell ist jetzt rev.226. Neu ist jetzt die Aufnahmesteuerung (Kommando 204 vom Client). Schreibt im Moment im raw Format.

Namesschema ist fest eingestellt:
[Kanalnummer]_[DATUM_UHRZEIT].raw im monitord Ordner.

Wobei die Kanalnummer so vergeben sind:
0 = Links der ersten Soundkarte
1 = Rechts der ersten Soundkarte

2 = Links der zweiten Soundkarte
3 = Rechts der zweiten Soundkarte

usw.

Auch die anderen Kommandos laut letztem Entwurf sollen nun gehen. Ebenso sind nun die Ausgaben für FMS,ZVEI und POCSAG an das neue Format angepasst.

Die Plugins für die Audioaufnahme sind nur verfügbar, wenn man mit configure --enable-plugins deren Übersetzung anfordert. Vorher am besten ein make clean, damit auch wirklich alles neu übersetzt wird. Wer ein 101:005 auf ein 204er Kommando bekommt hat wohl etwas falsch gemacht:-)

Zur Zeit läßt sich der monitord unter Windows nur per Task-Manager beendet. Unter Linux klappt weiter STRG-C. Das warum werde ich mir nochmal anschauen...

[nepomuck]

Auch die anderen Kommandos laut letztem Entwurf sollen nun gehen. Ebenso sind nun die Ausgaben für FMS,ZVEI und POCSAG an das neue Format angepasst.

Bei mir arbeitet die Version ohne Plugin (auf dem Thinkpan mit Ubuntu 7.10 32Bit). Mit Plugin stürzt Monitord mit einem Segmentation Fault ab. Ich probiere das gleich noch auf der 64-Bit-Plattform.

Der 203 liefert aktuell immer 8 Kanäle zurück, auch wenn nur zwei in der Config stehen.

Die Zvei-Alarme kommen mit einem 320. Der sollte aber für Pocsac zuständig sein (und wir haben noch keine Syntax dafür). Zvei sollte aber einen 300 auslösen.
Der 300er (momentan 320) gibt noch Text als Sirenencode zurück, das Protokoll sieht eine nummerische Ausgabe vor.

Wir sollten uns noch ein Paar xml-Paramter für die Config ausdenken, mit der wir Pfad und Dateinamen für die Aufnahme steuern.

viele Grüße,
Andreas

[Buebchen]

Bei mir arbeitet die Version ohne Plugin (auf dem Thinkpan mit Ubuntu 7.10 32Bit). Mit Plugin stürzt Monitord mit einem Segmentation Fault ab. Ich probiere das gleich noch auf der 64-Bit-Plattform.

Poste da bitte mal die letzten Ausgaben vor dem SegFault. Unter meinem Ubuntu 6.06 (32Bit) klappt das Probleme. Vermutlich kann er die Plugins nicht laden (Die Plugins sind als eigene Dateien ausgelagert und werden zur Laufzeit dazugeladen).

Der 203 liefert aktuell immer 8 Kanäle zurück, auch wenn nur zwei in der Config stehen.

Oh. da war die Debugeinstellung noch nicht wieder raus. Jetzt werden wieder nur aktive Karten angezeigt. Was später noch in der Doku aufgeführt werden muss: Man darf niemals eine Karte "überspringen". Also nicht die erste und dritte aktiv schalten, die zweite aber nicht. Dann würde das herunterzählen nicht funktionieren. Die Kanale 2 und 3 würden fehlen.

Die Zvei-Alarme kommen mit einem 320. Der sollte aber für Pocsac zuständig sein (und wir haben noch keine Syntax dafür). Zvei sollte aber einen 300 auslösen.
Der 300er (momentan 320) gibt noch Text als Sirenencode zurück, das Protokoll sieht eine nummerische Ausgabe vor.

Die 320 ist jetzt in 300 geändert (jaja, cut & paste :-) ). Der Weckton ist numerisch vorhanden. Danach habe ich einen Text ergänzt. Den bitte zum Protokoll hinzufügen. Der Grund ist ganz einfach: Ein ggf. irgendwann zentral verfügbares Modul kann da auch noch den Namen des Empfängers oder sonstiges hinzufügen. Generell bin ich in fast allen Produkten die ich betreue der Meinung, daß ein Freitext Feld immer vorhanden sein sollte. Man kann sich zu Beginn oft nicht vorstellen, was der Benutzer später gerne noch als kleinen Hinweis hinterlegen möchte (und was tatsächlich sinnvoll ist).

Für POCSAG wäre die Struktur:

320:{Zeitangabe}:{RIC}:{Subadresse}:{Text}

Die Unterscheidung Nur-Ton, Numerisch und Alphanumerisch ist auf der Empfängerseite relevant, wie er die Daten anzeigt. Im POCSAG Code unterscheiden sie sich nur darin, ob nach dem Adresswort noch Datenworte folgen oder nicht. Hier würde es sich für den monitord Client also daran unterscheiden, ob der Text leer ist oder nicht.

Wir sollten uns noch ein Paar xml-Paramter für die Config ausdenken, mit der wir Pfad und Dateinamen für die Aufnahme steuern.

Bis auf Kleinigkeiten (z.B. ein Präfix) würde ich den Dateinamen in der Version 2.0 so lassen.

In der Version 2.1 kann man dann z.B. noch eine zweite Datei schreiben, die die Daten zur Aufnahme enthält (Welcher Client hat es angefordert, ggf. ein Freitext vom Client, Dauer, Start, Ende , ...).

Pfadangabe ist selbstredend notwendig. Werde ich einpflegen.

[nepomuck]

Noch ein Beitrag zum Kommunikationsprotokoll:
Bei der Channel-Info (Kommando 203) sollte noch ein Bit 2^3 eingefügt werden. Damit man 2^2 für 512Baud POCSAG und 2^3 für 1200 Baud POCSAG nehmen kann.

Übernehme ich in das Protokoll wie vorgeschlagen

Inquiry (Kommando 210,110):
Macht es Sinn die Antworten zu "quittieren" ?

Das ist tatsächlich nicht nötig. Ich ändere Die Dokumentation entsprechend und streiche die Quittung bei den Kommandos, die darauf verzichten können.

Bei den Aufnahmekommando könnte man ggf. bei einer Antwort, daß die Aufnahme schon läuft, bzw. die Aufnahme beendet ist, noch die geplante (gesamte) Aufnahmedauer mitgeben.

Wäre möglich, aber macht das Sinn? Der Client hat ja die Zeit selbst vorgegeben und erwartet einen "Aufnahme beendet". Er braucht die "Zischenzeit"-Angabe vom Server nicht auszuwerten.

(Die Plugins sind als eigene Dateien ausgelagert und werden zur Laufzeit dazugeladen).

OK. Da liegt wahrscheinlich der Fehler. Ich move das Executable monitord nach erfolgreichem make in ein anderes Verzeichnis, in dem sonst nur die .xml drin steht. Da kann er die Module nicht finden.
Wie heissen die Moduldateien? Kann man einen Failsafe einbauen, so dass monitord eine klingende Fehlermeldung ausgibt wie "Module nicht gefunden"?

Man darf niemals eine Karte "überspringen". Also nicht die erste und dritte aktiv schalten, die zweite aber nicht.

Um Fehler zu vermeiden, sollte monitord.xml dann gar keine Nummern sondern nur Namen deklarieren. Die Nummerierung erledigt monitord dann intern gemäß der Reihenfolge der Kanäle in der Config.

Die 320 ist jetzt in 320 geändert

das ändert alles :-)

Danach habe ich einen Text ergänzt. Den bitte zum Protokoll hinzufügen.

OK. Dan bekommt der 300 ein Textfeld am Ende. Was machen wir, wenn es keinen Text zu übermitteln gibt? Lassen wir das Feld weg oder sendet der 300 in dem Fall ein einzelnes ":" am Ende?
Die Pocsac-Struktur übernehme ich ins Protokoll wie vorgeschlagen.

... würde ich den Dateinamen in der Version 2.0 so lassen ...
Pfadangabe ist selbstredend notwendig. Werde ich einpflegen.

Damit können alle gut leben.

Das überarbeitete Protokoll poste ich im Laufe der nächsten Tage,
Grüße,
Andreas