monitor 1.9.0 - aber richtig :)

[Buebchen]

Ich kann auch unter Ubuntu 6.06 keinen Fehler feststellen und würde auch einen neuen checkout vorschlagen.

[MacLeod]

jo!
trunk-ordner gelöscht und neu ausgechecked.
nu lüppt dat. komisch wer weiß was da broken war ....*grübel*

zvei funzt nun um welten besser! selbst die sirenenauslösung wird erkannt :-)))

alarme über den angeschlossenen scanner sind natürlich selten. habe auch nicht immer meinen "arbeitsrechner" am laufen.
gibts denn schon ne entwicklung in sachen "gespeicherter protokolle" zwecks langzeittest meine ich...

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.
ich weiß, ich wiederhole mich...
ich kann leider wie schon gesagt nicht programieren, sonst hätte ich mich da sicher ran gemacht.
ich weiß auch nicht in wie weit das überhaupt machbar ist. kann nur hoffen das es irgendwann klappt.

was habt ihr denn als frontend angeschlossen?

Gruß
Thomas

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

[mdi]

Hallo,

trunk-ordner gelöscht und neu ausgechecked.
nu lüppt dat. komisch wer weiß was da broken war ....*grübel*
(...)
zvei funzt nun um welten besser! selbst die sirenenauslösung wird erkannt :-)))

Fein, dann hat sich die kleine Änderung ja schon gelohnt. Kaputt war da bei Dir wenigstens die Datei MonitorModuleZVEI.cpp :D!
SCNR ;).

gibts denn schon ne entwicklung in sachen "gespeicherter protokolle" zwecks langzeittest meine ich...

Meinerseits nicht. Allerdings (ich wiederhole mich, ich weiß) wäre da mein Ansatz, dass eine SQLite-Datenbank dafür eingerichtet wird. Die Standard-SQL-Syntax ist dabei für die Abfragen nutzbar, so dass für z.B. ein PHP-Frontend lediglich das Öffnen und Schließen der Datenbank (statt MySQL) angepasst werden muss. Auch wären entsprechend freie Anfragen über alle Wege machbar wie "alle Alarmierungen von gestern", "alles zwischen heute, 13 und 14 Uhr", ...

Als Frontend baue ich mir gerade einen Mini-Client, der per Konfigurationsdatei auf eine Schleife (mehrere Schleifen) aktiviert werden kann und bei Empfang derselben entsprechend Alarm gibt. Allerdings habe ich mit dem noch das schon kurz beschriebene Problem, dass bei Schließen meines Programms der monitord plötzlich CPU-Last macht ohne Ende. Gesehen habe ich durch Zufall, dass beim Disconnecten von Telnet (simples Schließen des Fensters) der Socket-Thread beendet wird; wenn ich mein Tool nutze, tut er das nicht. Da muss ich noch genauer schauen, was da wo warum passert.

Zwei Tipps:
(Timing in VMWare), (kein Mikro, keine Lautsprecher, kein Lärm)

Das mit dem Timing-Problem ist komisch. Aber da bei mir eh nix an Sound ankommt, werde ich dem zweiten Hinweis mal nachgehen, THX.

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.

Hm... würde mich grundsätzlich sehr wundern, da im Code entlang des übergebenen Sound-Buffers dekodiert wird und es dem Auswerter schnurz ist, was irgendwelche Uhren sagen. Vielleicht muss ich mir den Code des 1.8.1-ers nochmal anschauen und den Ablauf vergleichen.

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.

Japp, das Feature der Datenbank ist dann eindeutig Kandidat für die 2.1. Ein entsprechendes... ich mags "Feature-Freeze" nennen, ist damit auch in meinen Augen absolut sinnvoll.

Martin