monitor 1.9.0 - aber richtig :)

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

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