PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : monitor 1.9.0 - aber richtig :)



Seiten : [1] 2 3

jhr-online
30.03.2007, 14:12
So Leute,
im Moment sieht es ja so aus, als würde doch der ein oder andere am Projekt arbeiten. Daher hab ich mir überlegt, das mal in etwas geordnete Bahnen zu lenken und uns eine vernünftige Basis zur Verfügung zu stellen. Für diese Zwecke stelle ich mal (ganz uneigennützig ;)) ein bisschen Platz auf meinem Server zur Verfügung und hoffe, dass es dann etwas flüssiger läuft.
Folgende Möglichkeiten habe ich neu geschaffen: Der Monitor und das Frontend sind nun in einem svn-Repository vorhanden. Lesenden Zugriff hat jeder, schreiben kann jeder, der mir eine PN oder E-Mail schickt. Dann trage ich ihn ein. Zugriff:
monitor:
svn checkout svn://jhr-online.de/monitorFrontend:
svn checkout svn://jhr-online.de/monitor-phpWer sich die Repos anschauen will und vielleicht sogar per RSS verfolgen, kann das unter http://svn.jhr-online.de/ Für unsere Entwickler und alle Interessierten habe ich eine Mailingliste erstellt: monitor@lists.jhr-online.de. Eintragen kann man sich unter http://lists.jhr-online.de/listinfo/monitor Des weiteren uns soll ein vernünftiges BugTrackingSystem das Sammeln von Fehlern und Wünschen erleichtern. Ich habe mir mal ein schönes ausgesucht und eingerichtet. Da "monitor" das Standardprojekt ist, erreicht man es zügig unter http://bts.jhr-online.deOftmals ist es üblich, wenn bereits eine Version 1 öffentlich ist, die Entwicklung zur Version 2 einfach 1.9 zu nennen. Das hab ich jetzt auch mal getan (auch um anzudeuten, dass ich mir eine stablie Version 2 wünsche). D.h. in den Repos liegen jetzt (sowohl vom monitor, als auch vom Frontend) die Version 1.9.0 und jetzt seid ihr dran: entwickelt fleißig! :-)
Ach ja: wer sich im BTS als User registriert und mich anschreibt wegen svn-Schreibrechten, der wird auch da als Developer eingetragen.

Was meint ihr? Wird das so was?

jhr

jhr-online
30.03.2007, 14:20
Man, wie doof. Jetzt hab ich das wichtigste vergessen...

In dieser Version, die jetzt im Repo ist, befindet sich vom Frontend die Version, die im Komplettpaket von Manuel vorhanden ist. Am Besten wär's, wenn du, Manuel, einmal kurz rüberschauen könntest und evtl. Änderungen direkt übertragen könntest. Vom monitor selber ist eine Version drin, die es so bisher nicht gab. Die beiden Änderungen von Paneologe (in demod_zvei.c und fms.c) sind drin (das waren zwei zusätzliche Zeilen insgesamt) und eine Änderung ist drin, die ein Freund von mir neulich fertig gemacht hat: Die SQL-Zugangsdaten stehen jetzt nicht mehr in der mon_mysql.c, sondern in der .monrc und werden beim Programmstart eingelesen. Die Daten müssen in folgendem Format rein:
SQL_HOST localhost
SQL_DB dbname
SQL_USER username
SQL_PASS passwort
SQL_PORT 3306Bei mir scheint's zu laufen :)

jhr

Paneologe
30.03.2007, 15:42
Hi,
klasse Idee.. nur ein Problem:
# svn checkout svn://jhr-online.de/monitor
svn: Can't connect to host 'jhr-online.de': Connection refused

Gruß Paneologe

jhr-online
30.03.2007, 18:21
Jap, ich weiß. Hab den Hinweis bekommen, dass das Repo unsinnig erstellt war. Das muss ich gleich eben korrigieren, dann ist es wieder online... :) Aber erst muss der Mailserver gewartet werden, also bitte ein wenig Geduld noch :)

jhr

jhr-online
30.03.2007, 20:44
Kaum will man was richtig machen, wird es anstengend... :)

Das svn sollte erreichbar sein, allerdings ist jetzt alles in einem.
svn://jhr-online.de/monitorHoffentlich klappt das alles nun. Falls schon jemand versucht haben sollte, sich in die Mailingliste einzutragen, möge er das bitte wiederholen. Mein Mailserver hat sich heute Mittag irgendwie verabschiedet... :(
Derzeit bin ich gut im IRC zu erreichen. Wer also richtig mitmischen will ;), kann das tun auf irc.freenode.net im channel #fms-monitor. Ansonsten bleiben die o.g. Optionen erhalten. Insbesondere auf das BTS weise ich noch mal hin.
@Paneologe: Für dich hab ich schon einen Bug drin; du solltest dich da mal drum kümmern :)

jhr

SirFS
31.03.2007, 01:40
Klasse Sache! Habs mal angepinnt.

jhr-online
31.03.2007, 19:41
Vielleicht könnten sich unsere Entwickler mal kurz zu Wort melden? Buebchen und ManuelW und so? Wäre gut, wenn wir deren Meinung auch hätten, die müssen mit der neuen, von mir eingerichteten und vorgeschlagen Situation ja arbeiten. Ist das okay so? Denn, wenn nicht, dann lassen wir den Spaß einfach!

Diskussionen/Anregungen/Meinungen gerne hier oder auf der o.g. Mailingliste oder, wenn's eine Plauderrunde werden soll, auch gerne in #fms-monitor auf irc.freenode.net!

jhr

nepomuck
04.04.2007, 01:53
Hallo zusammen,

Leider bin ich ein hundsmiserabler Programmierer und werde daher die Finger vom Code lassen. Ich hätte aber ein paar Vorschläge für neue Features der Version 1.9 und würde mich sehr freuen, wenn sich diese umsetzen ließen.

Ich benutze Monitor eigentlich nur für ZVEI-Alarmierungen, da in unserem Landkreis kein FMS verwendet wird. Im ZVEI-Modul fehlen mir ein paar Optionen.

1. Flexibles REC-Kommando
Bisher legt REC_TIME starr fest, wie lange Monitor den Funk nach einer Alarmierung mitschneidet. Könnte man hier das [@REC]-Kommando so erweitern, dass es einen Parameter zur Aufnahmedauer übergibt?
Beispiel:
.monrc
ZVNAME 00001 [@REC] ...
ZVNAME 00002 [@REC500] ...
Löst die Schleife 00001 aus, nimmt Monitor für die unter REC_TIME festgelegte Zeit auf. Löst hingegen 00002 aus, nimmt Monitor für 500 Sekunden auf. Lösen während einer Alarmierung mehrere Schleifen mit @REC aus, zählt die längste Zeitangabe.

2. Mehrere ZVEI-Aktionen
Bislang führt Monitor nur die erste passende Aktion aus, also:
ZVNAME 1* [exec "~/1.sh"]
ZVNAME 11111 [exec "~/2.sh"]
führt immer nur 1.sh aus, auch wenn 11111 alarmiert wird.

ich hätte gerne, dass folgendes funktioniert:
ZVNAME 26* [exec "~/1.sh"]
ZVNAME 26250M [exec "~/melder.sh"]
ZVNAME 26250S [exec "~/sirene.sh"]
Bei einer Alarmierung von 26250 mit Sirene werden 1.sh UND sirene.sh gestartet, bei einer Alarmierung von 26250 ohne Sirene 1.sh und melder.sh und bei 26123 nur 1.sh

3. Make ohne X
Die 1.8.1-Sourcen haben haufenweise dependencies. Selbst wenn ich monitor alleine ohne X betreiben will, bricht make ab, wenn die X-dev-libs fehlen.
Schön wären hier auch Binary-Pakete (RPM, DEB) des "nackten" Monitor-Programms für gängige Distributionen wie Ubuntu oder Fedora Core.

Trennung Backend-Frontend
Nur so eine Idee: Eigentlich könnte man den Monitor (oder eine Sub-Version davon) so weit abspecken, dass es gar keine GUI im Backend-Modul mehr gibt und das Programm im Hintergrund als Daemon lauft. Alle Meldungen, die es dekodiert, schreibt die Software einfach in ein Interrupt-Device, wie /dev/input/monitor0R. Darauf setzen dann ein oder mehrere wie auch immer geartete Fontends auf (X, GTK, MySQL) oder die Anwender schreiben eigene Perl-Skripte, die nur von /dev/input/monitor0R lesen und die Strings direkt weiterverwerten.

Bei dem o.g. Beispiel würde Monitor auf /dev/input/monitor0L bei einer Alarmierung einfach nur "ZVEI:26250S" ausgeben und das getrennte Frontend-Programm kümmert sich dann um die Darstellung oder ein eigenes Skript interpretiert diese Information.

viele Grüße,
Andreas

jhr-online
04.04.2007, 11:49
Schade, dass du nicht selber Hand anlegen willst, aber ich akzeptiere das natürlich (widerwillig)... ;)

Du könntest uns einen Gefallen tun und deine Anregungen ins BugTrackingSystem [1] einfügen*. Wenn ich das richtig sehe, ist Punkt 1 eine Wunschfunktion und die Punkte 2 und 3 sind Bugs. Trag das ruhig so ein - ist nicht schwer zu bedienen und man muss sich zum Eintragen nicht mal registrieren.

Deine gewünschte Trennung von Backend und Frontend wäre ein sehr großer Eingriff. Derzeit ist die Überlegung, dass Version 1.9.x aus dem jetzigen Code besteht und Bugfixes, sowie kleine neue Features enthalten soll. Für große Änderungen ist ein ordentliches Umstrukturieren des Codes angemessen, was auf eine Version 2 hinauslaufen würde. In der Theorie ist die auch geplant, aber es liegt natürlich ganz am Engagement der Entwickler, ob es soweit kommt. Das wäre nämlich richtig viel Arbeit.

jhr

[1] http://bts.jhr-online.de/?do=newtask&project=2

* Das ist deswegen von Vorteil, weil da Kontaktmöglichkeiten zu den Entwicklern gespeichert sind/sein sollen und wir die einzelnen Aufgaben (Bugs/Wunschfunktionen) da zuweisen können. Das gibt dem ganzen etwas Struktur und man kann sich absprechen, wer was übernimmt.

Buebchen
05.04.2007, 01:12
Vielleicht könnten sich unsere Entwickler mal kurz zu Wort melden? Buebchen und ManuelW und so? Wäre gut, wenn wir deren Meinung auch hätten, die müssen mit der neuen, von mir eingerichteten und vorgeschlagen Situation ja arbeiten. Ist das okay so? Denn, wenn nicht, dann lassen wir den Spaß einfach!

Diskussionen/Anregungen/Meinungen gerne hier oder auf der o.g. Mailingliste oder, wenn's eine Plauderrunde werden soll, auch gerne in #monitor auf irc.freenode.net!

jhr

Hab' mal nen checkout gemacht. Könntest Du mal einen branch "windows" anlegen ? Irgendwie muss ich mir nochmal tags und trunks im svn anschauen. Der trunk war die aktuelle version und ein tag war ein Milestone - Richtig ?

Soll im branch 2.0 die Renovierung erfolgen - so versteht ich den BugTrack Eintrag. Dann könnte ggf. später der Windows Ordner entfallen. Der ist stückweise schon modularisiert (wobei ich nicht am Reissbrett angefangen hatte) und sehr auf MFC / MS Visual C ausgerichtet (Bsp: CString).

jhr-online
05.04.2007, 01:23
Hab' mal nen checkout gemacht. Könntest Du mal einen branch "windows" anlegen ?Versteh ich nicht, was soll da drin sein?
Irgendwie muss ich mir nochmal tags und trunks im svn anschauen. Der trunk war die aktuelle version und ein tag war ein Milestone - Richtig ?In trunk ist das, was derzeit entwickelt wird, also das, was ich derzeit 1.9.0 nenne und auf dem Weg zu 1.9.1 ist. Unter den Branches finden sich zusätzliche Entwicklungszweige, die größere Änderungen beinhalten sollen. In diesem Fall (2.0) soll der Code ordentlich um strukturiert werden; in welcher Art auch immer (C++ wohl vermutlich nicht, aber zumindest ordentlich modularisiertes C). In den Tags liegen dann einfach die erreichten Milestones, also als nächstes 1.9.1.

Es ist spät, hoffentlich hab ich mich jetzt nicht verhaspelt... :)

jhr

jhr-online
05.04.2007, 12:48
Channeländerung: auf irc.freenode.net (wie gehabt) Channel #fms-monitor

jhr

nepomuck
07.04.2007, 01:25
Deine gewünschte Trennung von Backend und Frontend wäre ein sehr großer Eingriff. Derzeit ist die Überlegung, dass Version 1.9.x aus dem jetzigen Code besteht und Bugfixes, sowie kleine neue Features enthalten soll.

Ich halte es für den falschen Ansatz, noch mehr Features in da monolithische Programm einzubauen. Die aktuelle Version lässt sich doch jetzt schon kaum auf zeitgemäßen Plattformen compilieren, ohne nicht mindestens ein dutzen "dev" Libraries zu installieren.

Von der Zuverlässigkeit her ist das existierende Backend klasse. Die Dekodierung läuft fehlerfrei, besser als bei kommerziellen Produkten. Was hier im Forum immer wieder bemängelt wird, ist die Auswertung.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Der Output läuft in ein gewöhnliches Char-Device und jeder X-beliebige User-Mode-Prozess kann lesend darauf zugreifen. Die Entwickler der Forntends müssen sich dann gar nicht mehr mit dem alten Code herumschlagen.

Im Backend muss man sich lediglich auf ein Protokoll einigen, welches die Dekodierung auf das Char-Device schreibt wie: "Channel 0:ZVEI:12345:M" oder "Channel 1:FMS:kennung:Status 0". Die eigentliche Auswertung kann dann sogar ein simples Shell- oder Perl-Skript übernehmen.

Andreas

SirFS
07.04.2007, 01:47
Ich halte es für den falschen Ansatz, noch mehr Features in da monolithische Programm einzubauen. Die aktuelle Version lässt sich doch jetzt schon kaum auf zeitgemäßen Plattformen compilieren, ohne nicht mindestens ein dutzen "dev" Libraries zu installieren.

Von der Zuverlässigkeit her ist das existierende Backend klasse. Die Dekodierung läuft fehlerfrei, besser als bei kommerziellen Produkten. Was hier im Forum immer wieder bemängelt wird, ist die Auswertung.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Der Output läuft in ein gewöhnliches Char-Device und jeder X-beliebige User-Mode-Prozess kann lesend darauf zugreifen. Die Entwickler der Forntends müssen sich dann gar nicht mehr mit dem alten Code herumschlagen.

Im Backend muss man sich lediglich auf ein Protokoll einigen, welches die Dekodierung auf das Char-Device schreibt wie: "Channel 0:ZVEI:12345:M" oder "Channel 1:FMS:kennung:Status 0". Die eigentliche Auswertung kann dann sogar ein simples Shell- oder Perl-Skript übernehmen.

Andreas

Also ich muss sagen, dem stimme ich zu 100% zu.
Wenn ich mehr Zeit hätte, würde ich mich da ja mal mit beschäftigen...

ManuelW
07.04.2007, 10:12
Ich finde auch das klingt sehr vernünftig.
Vor allem die Konfiguration sollte einfacher werden, ich habe damals ewig
gebraucht und gebastelt bis es dann endlich mal so lief wie es sollte...

jhr-online
07.04.2007, 14:05
Bin ich ebenfalls dabei.
Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden. Für dich gilt, wie für alle anderen, die mitmachen wollen:
Schick mir eine PN mit einem Wunschpasswort, damit ich Schreibzugriff auf das Repo einrichten kann. Registrier dich im BugTrackingSystem und nenn mir in der PN deinen Namen, damit ich dich da zum Developer machen kann (das erlaubt auch da Änderungen und so) Registrier dich in der Mailingliste Komm ab und zu mal im Channel #fms-monitor auf irc.freenode.net vorbeiWenn alle einverstanden sind, machen wir mal einen Termin ab, an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

jhr

PS: Danke! :)

ManuelW
09.04.2007, 09:31
Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...

Ob Montag um die Zeit klappt weiss ich noch nicht, da wollt ich an nem
Bau-Seminar in SecondLife teil nehmen :P

nepomuck
09.04.2007, 10:14
an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

Da bin ich in der "Offline-Pampa"
Wäre schön, wenn einer das Chat-Protokoll redigiert und den Report hier postet.

Ich werde einfach mal meine Ideen zu einer Wunschliste zusammenschreiben und hier oder in das Code-System einstellen. Ich habe da ein paar Ideen zu Front- und Backends sowie Kommunikationsmodulen, damit der Monitor netzwerkfähig wird. Frond- und Backend könnten dann auf getrennten PCs arbeiten, wie bei FMS Pro.

Andreas

jhr-online
09.04.2007, 15:25
Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...Es ist nur ein Angebot. Wenn wir die nicht brauchen, mache ich sie wieder aus. Ist ja kein Problem. Ich hab mich nur sehr an den Luxus gewöhnt :)

Was den Termin betrifft: Das war auch nur ein Vorschlag. Scheint wohl nix zu werden, wenn sich zwei melden, weil sie nicht da sind. Andere Vorschläge?

jhr

Buebchen
10.04.2007, 23:24
Also, ich war im Osterstreß (der jetzt erstmal fließend in dn Kommunions-Streß übergeht). Würde aber versuchen, dabei zu sein. Am liebsten frühestens um 20:00 Uhr. Besser sogar 21:00 Uhr :-)

Mailingliste würde ich mal abwarten. Ggf. für die Entwickler unter sich. Ansonsten finde ich ist das Forum einfacher und erreicht mehr Leser.

jhr-online
11.04.2007, 00:09
Bin ich dabei!

An alle: Termin für ein IRC-Treffen lieber in der Woche oder am Wochenende?

jhr

Dove
11.04.2007, 23:49
ich behaupte mal sonntag abends 20-21 so um den dreh.
So sollten eigendlich alle zuhause sein. Denke da könnte ich auch :D

Max K.
11.04.2007, 23:57
Es ist nur ein Angebot. Wenn wir die nicht brauchen, mache ich sie wieder aus. Ist ja kein Problem. Ich hab mich nur sehr an den Luxus gewöhnt :)

Hi,

finds ersma toll wie du dich engagierst!

Allerdings fände ich auch toll, wenn dieses Forum hier weiter als hauptsächliche Kommunikationsplattform genutzt werden würde, weil dabei evtl. auch weniger aktive User, die nicht in der mailingliste angemeldet sind, von den Infos u. Diskussionen profitieren können..

Mfg.
Max

jhr-online
12.04.2007, 01:16
finds ersma toll wie du dich engagierst!Ernst zu nehmendes Eigeninteresse... :) Und Ressourcen, die da sind, biete ich gerne für Freie Software. Ich nutze sie ja auch... Hab in den letzten Tagen auch einige GB Traffic per Torrent "geschenkt" anlässlich des neuen Debian Release :)
Wenn man mitmacht, macht es einfach noch mehr Spaß!
Allerdings fände ich auch toll, wenn dieses Forum hier weiter als hauptsächliche Kommunikationsplattform genutzt werden würde, weil dabei evtl. auch weniger aktive User, die nicht in der mailingliste angemeldet sind, von den Infos u. Diskussionen profitieren können..Sehe ich genau so. Allerdings sind E-Mails oft praktischer, wenn sich Entwickler austauschen wollen. Wie buebchen ja meinte, könnte man später als reine Entwickler-Runde drauf zurückgreifen... Dafür biete ich die ML gerne weiter an. Für alles weitere sollte das Forum bleiben... full ack.

jhr

nepomuck
13.04.2007, 02:08
Ich werde einfach mal meine Ideen zu einer Wunschliste zusammenschreiben und hier oder in das Code-System einstellen.

Wie angekündigt poste ich hier mal ein paar konkrete Ideen für eine kommende Monitor-Version. Da meine eigenen Programmierkentnisse in C nicht wesentlich über ein "Hello World" hinausragen und ich mit Objektorientierung gar nichts am Hut habe, kann ich leider nicht aktiv am Code mithelfen, sorry.

Der Grundgedanke ist die strikte Trennung in Font- und Backend, eventuell mit einem Zwischenlayer für Netzwerkfunktionen. Der Vorteil liegt auf der Hand: Die einzelnen Module lassen sich einfacher kompilieren und jeder nutzt nur das, was er benötigt. Zudem können die Entwicklerteams von Front und Backend getrennt voneinander arbeiten, ohne den Code des anderen bearbeiten zu müssen.

1. Backend
Das Backend besteht aus einem Loader, dem Monitor-Daemon plus die Dekodierungsmodule. Die Konfiguration definiert "Channels". Jeder Channel besteht aus einem Input-Kanal wie "/dev/dsp0 links", einem Output-Kanal wie "/dev/fms0" und einer Liste der zu ladenden Module, zum Beispiel:

[channel 0]
input =/dev/dsp0 left
modules = zvei,dtfm,fms
output = /dev/fms0
[channel 1]
input = /dev/dsp1 right
modules = pocsac512
output = /dev/fms2

Der Loader prüft die Konfigurationsdatei und startet dementsprechend ein- oder mehrere "monditord"-Instanzen (eine pro Channel). Vorteil: Stürzt eine Instanz ab (siehe ZVEI-Bug), dekodiert die andere weiter.
Wichtig wäre dabei, dass das /dev/fms-Devices so deffiniert ist, dass mehrere Frondend-Tasks parallel darauf nur-lesend zugreifen können.
Auf dem Output-Device landen die dekodierten Werte im Klartext, so wie sie vom Dekodierer kommen, plus der Angabe, was dekodiert wurde, Beipsiel:
ZVEI:12345
DTFM:F
FMS:1234567:2 (<- Statusmeldung)
FMS:1234567:Text:"der übertragene Text"

Anstelle eines "/dev/fms"-Devices könnte der monitord die Ausgabe auch auf einen TCP-Port schreiben. Das würde die Netzwerkfähigkeit direkt integrieren. Lokale Frontends würden dabei dann z.B. auf 127.0.0.1:10122 hören.
Hier müssen die Entwickler entscheiden, was sich einfacher umsetzen lässt, Device oder TCP-Port.

2. Zwischenlayer
Sollte der monitord auf ein "/dev/fms"-Device schreiben, bedarf es eines Zwischelayers für Netzwerkfunktionen. Dieser würde dann auf dem Server alle Ausgaben von /dev/fms auf einem Netzwerkport bereitstellen. Im Gegenzug würden die Clients auf einem anderen PC per TCP diesen Port abhören und ein lokales /dev/fms-Device beschreiben.
Für Frontend-Anwendungen wäre es damit völlig egal, ob sie direkt auf dem monitord-Rechner oder irgendwo im LAN arbeiten -- sie müssen ja nur ein /dev/fms-Gerät abhören und darauf reagieren.
So könnte auch jemand ein Mac- oder Windows-Frontend schreiben.

3. Frondend
Hier kann jeder im Prinzip machen was er will. Es genügt, den Text-Output des FMS-Devices abzuhören und irgendwie darauf zu reagieren. Allerdings müssen Frontends multithreaded arbeiten, wenn sie mehrere Channels simultan auswerten wollen. Das "Monitor-Classic-Frontnend" würde die .monrc benutzen, um die eingehenden Informationen darzustellen, nötigenfalls umzuschreiben und darauf zu reagieren. Ein MySQL-Frontend, das parallel zu anderen arbeitet, schreibt die Auswertung in eine Datenbank. Dabei müssen sich Classic- und MySQL-Frontend nicht eine Zeile Code teilen und können friedlich nebeneinander werkeln.

Probleme:
Das Konzept berücksichtigt die REC-Funktion nicht. Die lässt sich auch nicht direkt mit dem monitord-Prozess abbilden, da dieser schließlich nur Dekodiert aber nicht auswertet. Hierfür müsste es als ein Extra Modul geben, welches zwangsläufig auf dem selben PC wie monitord arbeitet. Soweit ich weiss gibt's da aber ein Problem, dass unter Linux nur ein Task auf /dev/dsp Zugreifen kann und nicht mehrere. In diesem Fall belegt der monitord das Device exklusiv und ein getrennter recd käme nicht an die Soundkarte.

Was haltet ihr von dem Konzept?
Zumindest das Backend dürfte sich mit dem bestehenden Code sehr einfach bauen lassen. Beim Frontend müsste man den Code auseinandernehmen und die MySQL-Funktionen von "Classic"-Client trennen und als eigene Module bauen.

Andreas

Buebchen
13.04.2007, 02:59
Liest sich soweit ganz gut. Aber warum der Umweg über die Devices ? Ich würde dann direkt den TCP Port nehmen. Wenn es ohne TCP gehen soll wäre noch ein Unix-Filesocket vorstellbar. Ich denke, daß Du das mit dem /dev/fmsXyz meinst.

Die Idee mit den zwei Unterprozessen kann ich nur unterstützen. Habe ich in meiner Eigenentwicklung auch so umgesetzt. Wobei man es nicht 100% trennen kann.

Da man nur ein "komplettes" ein Sound-Device belegen kann muss man Links und Rechts in einem gemeinsamen Haupt-Thread erstmal von Hand trennen und kann erst dann diese Daten an die anderen Subprozesse weitergeben. Ich würde dann über den Haupt-Task auch den TCP Socket Pool verwalten und alle ausgewerteten Daten an die Clients weitergeben.

Habe bisher unter Linux nur mit Perl TCP Listener erstellt. Aber da sollten sich die C-Version von Windows und Linux hoffentlich nicht zu sehr unterscheiden.

nepomuck
13.04.2007, 12:31
Ich würde dann direkt den TCP Port nehmen. Wenn es ohne TCP gehen soll wäre noch ein Unix-Filesocket vorstellbar. Ich denke, daß Du das mit dem /dev/fmsXyz meinst.

Exakt. Wenn TCP einfacher ist, dann umso besser. So wird Monitor direkt netzwerkfähig und der Zwischenlayer fällt aus. Dann muss allerdings ein Modul dazu, welches die TCP-Connections zu den Clients irgendwie verwaltet und man muss sich ein wie auch immer geartetes LAN-Protokoll einfallen lassen.



Da man nur ein "komplettes" ein Sound-Device belegen kann muss man Links und Rechts in einem gemeinsamen Haupt-Thread erstmal von Hand trennen und kann erst dann diese Daten an die anderen Subprozesse weitergeben.


Das liesse sich auch so abbilden, dass ein "Channel" und damit eine monitord-Instanz zwangsläufig für zwei Sound-Kanäle steht. Dann wäre nur zu überlegen, ob der Output dann auf einem TCP-Port erfolgt, also:
ZVEI:L:12345, FMS:R:1234567:1
oder ob der Output der Sound-Kanäle auf getrennten TCP-Ports endet. Beispiele:

[channel 0]
input = /dev/dsp0
modules left = ZVEI,DTFM,FMS
modules right = POCSAC512
output = 10112
localonly = yes (an und abschalten des LAN-Zugriffes)

oder

output left = 10112
output rigth = 19222
localonly =yes


Was anderes:
Müssen ZVEI und DTFM eigentlich als seperate Module existieren? DTFM kommt doch ohnehin immer nur in Verbindung mit ZVEI zum Einsatz. Da läge es doch nahe, diese Module zu verbinden.

Andreas

jhr-online
13.04.2007, 13:06
Die Thematik übersteigt meine derzeitigen Fähigkeiten ganz ordentlich, aber - nur mal leise angetastet - wäre es nicht möglich den monitord ALSA-fähig zu machen? Das dürfte doch das Sound-Problem lösen, oder nicht?

jhr

Buebchen
13.04.2007, 17:40
Exakt. Wenn TCP einfacher ist, dann umso besser. So wird Monitor direkt netzwerkfähig und der Zwischenlayer fällt aus. Dann muss allerdings ein Modul dazu, welches die TCP-Connections zu den Clients irgendwie verwaltet und man muss sich ein wie auch immer geartetes LAN-Protokoll einfallen lassen.



Wenn alle Stricke reissen, nehmen wir halt XML :-)





Das liesse sich auch so abbilden, dass ein "Channel" und damit eine monitord-Instanz zwangsläufig für zwei Sound-Kanäle steht. Dann wäre nur zu überlegen, ob der Output dann auf einem TCP-Port erfolgt, also:
ZVEI:L:12345, FMS:R:1234567:1
oder ob der Output der Sound-Kanäle auf getrennten TCP-Ports endet. Beispiele:

[channel 0]
input = /dev/dsp0
modules left = ZVEI,DTFM,FMS
modules right = POCSAC512
output = 10112
localonly = yes (an und abschalten des LAN-Zugriffes)

oder

output left = 10112
output rigth = 19222
localonly =yes


Was anderes:
Müssen ZVEI und DTFM eigentlich als seperate Module existieren? DTFM kommt doch ohnehin immer nur in Verbindung mit ZVEI zum Einsatz. Da läge es doch nahe, diese Module zu verbinden.

Andreas

Würde die Ausgabe immer gesammelt über einen TCP Port machen. Man kann ja durchaus den Kanal, von dem die Info stammt mit angeben. Der Client kann dann entscheiden, ob ihn das Ergebnis interessiert.

Der Grund, daß DTMF überhaupt genutzt wird ist die m.E. Sirenentonerkennung (Doppelton). Hätte ich auch eine andere Lösung für parat (Einfach ne FFT genommen).

Ich muss mal meinen Windows C++ Source uns CVS uppen. Mal gucken, ob ich da noch irgendwelche Passwörter hard-coded drin habe. Das wäre dann nicht so geschickt :-)

Mit Alsa müßte man sich mal befassen. Wenn man einigermassen modular arbeitet sollte es nicht dramatisch sein, auf andere "Tonquellen" zugreifen zu können. Das kann ja sogar der monitor schon (Datei).

nepomuck
14.04.2007, 00:38
Wenn alle Stricke reissen, nehmen wir halt XML :-)

In erster Linie geht es darum, wie Client und Server sich überhaupt verständigen ("Helo" -> "Ehlo" und so was), ob es eine wie auch immer geartete Useranmeldung gibt und wie der Client regelmäßig prüft, ob er überhaupt noch zum Server verbunden ist ("ping" -> "pong").


Der Grund, daß DTMF überhaupt genutzt wird ist die m.E. Sirenentonerkennung

Klar, und die gibt's meines wissens sowieso nur bei ZVEI-Alarmierungen


Hätte ich auch eine andere Lösung für parat (Einfach ne FFT genommen).

hä? Was ist eine FFT?


Wenn man einigermassen modular arbeitet sollte es nicht dramatisch sein


Thema modular: Ich habe mir heute mal Teile des Codes angesehen, im speziellen demod_zvei.c auf der Suche nach der möglichen Ursache für das angesprochene ZVEI-Problem.
Ich will ja niemand auf die Füße treten, aber der Code ist ein wildes durcheinander: Hier etwas .monrc auslesen, dort etwas Output formatieren und mittendrin irgendwelche Cosinus-Kurven analysen.

Wenn das Projekt modular werden soll, dann muss jemand diesen Code entwirren -- bevorzugt derjenige, der in geschrieben hat. Es würde *imho* sehr viel helfen, im bestehenden Source die Backend-Funktionen zu kennzeichnen, damit man sie in mitten der Frontend-Funktionen überhapt erkennen und dann auch abtrennen kann.

Andreas

Buebchen
14.04.2007, 03:11
FFT = Fast-Fourier-Transformation (Damit kann man jetzt bei google mal so richtig viel Spaß haben :-) - Im Grunde genommen prüfe ich ob die gesuchten Töne im gesamten Frequenzspektrum vorhanden sind. Dazu muss das "Rauschen" wie bei einem Equilizer Blöcke für die einzelnen Frequenzen zerlegt werden. Das kann eine FFT.

Was das entwirren des Codes angeht. Ich brauch noch bestimmt bis Mittwoch, bevor ich dazu komme ins svn mal was hochzuladen. Ich habe mir die Mühe, den Code zu entwirren schon gemacht. Bin jetzt gerade aber ein bisschen wegen Familie eingespannt.

Ansonsten stimme ich zu 100% zu: Der Code ist ein Paradebeispiel für Spaghetti-Code.

nepomuck
15.04.2007, 22:20
FFT = Fast-Fourier-Transformation (Damit kann man jetzt bei google mal so richtig viel Spaß haben :-) - Im Grunde genommen prüfe ich ob die gesuchten Töne im gesamten Frequenzspektrum vorhanden sind.

Was eine "normale" Fourier-Transformation ist, weiss ich im Groben und Ganzen noch.
Wie funktioniert die ganze Dekodiererei überhaupt vom Prinzip her?

Du greifst permantent Datenblöcke von der Soundkarte ab und prüftst, per FFT, ob einer die vielen gesuchten Töne drinsteck?

Also 11 verschiedene Töne für ZVEI, (?) andere für FMS.

Wie merkt man dann, dass es sich um einen Doppelton handelt?

viele Grüße,
Andreas

Buebchen
16.04.2007, 02:04
Im Grunde genommen genau so, wie Du es beschreibst:

Datenblock vom Soundtreiber füllen lassen. Dann Analyse starten. Dann nächsten Block abwarten und wieder Analyse ...

ZVEI läuft eher über Matrix-Operationen (Diskrete Cosinus Transformation) ab. Aber im Grunde bleibt es eine FT.

Die Verarbeitung ist so gegliedert:

1. Rohdaten vom Sound-Device (float, 16 Bit signed)
2. Auf Frequenzanteile prüfen. Anhand dessen wird bei FMS und POCAG ein Bit erkannt.
3. Das erkannte Bit wird dann wiederum zu einem Wort/Byte/Was-auch-immer zusammengesetzt
4. Ist nun das Telegramm vollständig kann man es noch dekodieren und ist fertig.

Soweit die Theorie. In der Praxis ist das recht aufwändig. Gerade die Synchronisation auf den Bittakt des Senders finde ich, ist eine Herausforderung. Warum FMS z.B. mit 12x "Eins" als Vorlauf arbeitet habe ich nie kapiert. Eine Null-Eins-Folge wäre zur Synchronisation m.E. eheblich einfacher gewesen, da man gerade den Wechsel eines Bits relativ gut detektieren kann. Pocsag hat 576 Bits im Vorlauf. Mit ständigem Wechsel. Sowas ist natürlich perfekt zu sync'en.

Ach so, Doppelton. Eigentlich ganz leicht: Zwei FFTs für die beiden Grundfrequenzen und wenn beide Anschlagen (Fourierkoeffizienten sehr gross) hat man nen Doppelton. Habe an der Analyse selbst lange nicht mehr gearbeiten. Stichwort für wenigen Frquenzen wäre Goertzel-Transformation. Ist eine effiziente FFT Variante wenn man nur wenige Frequenzen sucht.

nepomuck
16.04.2007, 17:15
ZVEI läuft eher über Matrix-Operationen ...
Auf Frequenzanteile prüfen. Anhand dessen wird bei FMS und POCAG ...


Läuft da ein Dekodierer der alles kann?
Oder gibt es eine Art "Vordekodierung", die den Datenblock erst einmal typisiert und sagt, dass muss FMS, Pocsac oder ZVEI sein und den Block dann an eine Subroutine zur endgültigen Dekodierung übergibt?

Wäre es sinnvoll, in einer modularen Version das ganze zu parallelisieren?
Sprich: für jede Funktion (FMS;ZVEI;DTFM;POCSAC) eine eigene, optimierte Dekodierroutine zu schreiben? In der Praxis würden dann mehrere Dekoder parallel ein und denselben Datenblock bearbeiten. Das dürfte etwas mehr RAM kosten aber dafür die Dekodierung verbessern.

Andreas

Buebchen
16.04.2007, 19:27
Ne, Ne. Schon beim monitor waren das getrennte Dekodierer. Für jede "Spezies" einer.

Parallel habe ich bisher nur die Kanäle laufen lassen. Ob es Sinn macht, das auf die einzelnen Auswerter herunterzubrechen ... muss man mal drüber nachdenken. Ich würde Spontan nur linken und rechten Kanal als einzelnen Prozeß laufen lassen. Wobei man natürlich auch mehr als zwei Prozesse bilden kann (um z.B. mehrere Soundkarten auszuwerten).

Dove
16.04.2007, 21:02
ich glaube um die modularsierung zu wahren sollte man die einzelt lassen.
So kann man dann eventuell auch das laden der für mich wichtigen module einstellen und alle anderen module werden außen vor gelassen.

Buebchen
16.04.2007, 22:38
Reden wir jetzt von logischen Modulen oder von real existierenden Prozessen ?

Ich würde die Module trennen, keine Frage. Das ist im monitor sowieso schon so, also keine Änderung. Ich würde nur für den linken und rechten Kanal (ggf. auch weitere) immer einen Unterprozeß (Thread) bilden. Hängt sich ein Kanal weg, läuft der andere weiter. Ausserdem würde man so zumindest ein Stückchen von HT / Dualcore profitieren.

Dove
17.04.2007, 16:27
Reden wir jetzt von logischen Modulen oder von real existierenden Prozessen ?

Ich würde die Module trennen, keine Frage. Das ist im monitor sowieso schon so, also keine Änderung. Ich würde nur für den linken und rechten Kanal (ggf. auch weitere) immer einen Unterprozeß (Thread) bilden. Hängt sich ein Kanal weg, läuft der andere weiter. Ausserdem würde man so zumindest ein Stückchen von HT / Dualcore profitieren.

genauso seh ich das auch.

nepomuck
18.04.2007, 02:00
Mal eine kurze Zusammenfassung:

Der neue Monitor arbeitet mit einem Backend "monirotd", das zwei Soundkanäle eines Devices dekodiert und die Ergebnisse auf einem TCP-Port für Frondend-Anwendungen ausgibt. Das Protokoll wird dabei den Dienst (FMS, ZVEI, POCSAN), den Kanal (L,R) und die jeweiligen Daten angeben. Dieser Port kann simultan von mehreren Fontend-Apllikationen -- auch über das LAN -- abgehört werden. So kann ein MySQL-Frontend getrennt von einem "Classic-Client" arbeiten.

Jetzt hätte ich noch einen Vorschlag für den Daemon:
Das modulare Konzept erlaubt bislang keine @rec-Funktion, da diese vom Frondend gesteuert aber vom Backend ausgefürt werden muss.
Dazu könnte man doch das Backend mit einem TCP-Listener versehen, das auf einem zusätzlichen TCP-Port Kommandos von einem Frontend entgegen nimmt.
Beispiel: monitord gibt seine Infos wie "ZVEI:L:12345" auf localhost:10112 aus, hört aber gleichzeitig auf localhost:10113. Wenn das Frontend nun aufgrund des Regelwerks eine Funkaufzeichung anfertigen möchte, dann sendet sie eine Nachricht via Port 10113 an den monitord mit dem Inhalt:"Bitte Funk für 120 Sekunden aufzeichnen". Die eigentliche Aufzeichung übernimmt dann das Backend, welches ohnehin das /dev/dsp exklusiv belegt. Das Frontend steuert über sein Kommando, wie lange welcher Kanal aufgezeichnet wird und übergibt im Zweifelsfalle auch die sox- oder lame-Parameter an das Backend.

Der zusätzliche Port liesse sich somit auch für weitere Steueranweisungen verwenden, welche das Front- an das Backend übermitteln will.
Einschränkung: Viele Frontends können die Auswertung von Port 10112 verarbeiten aber nur EINE Frontend-Anwendung kann dem Backend zur Laufzeit via 10113 Anweisungen erteilen.

Andreas

Buebchen
18.04.2007, 09:44
Es wäre auch vorstellbar, einen "Decoder" zu schreiben, der die Daten als mp3 Stream aufbereitet und dem Client direkt "live" senden. Wäre für die Aufnahmefunktion natürlich prima, da viele Soundkarten auch den Stereo-Ausgang als Aufnahmequelle selektieren können.

Man könnte die @rec Funktion ansonsten auch über die gleiche TCP Sitzung starten/stoppen. Ist ja Bidirektional. Sollte man ggf. nur als Benutzerrecht definieren können. Ausserdem wäre dann noch zu klären, wie die Aufnahme zum Frontend kommt. Die besten Aufnahme nützt nichts, wenn man sie nicht hören kann :-)

Ich würde das Konzept auch direkt auf mehrere Soundkarten erweitern. Warum nicht direkt zwei oder mehr Soundkarten ermöglichen ? Sofern die Modularisierung da ist, ist das keine soo grosse Tat mehr.

jhr-online
18.04.2007, 10:33
Mir fällt gerade was auf:
Der Thread, in dem wir hier schreiben, ist u.A. betitelt mit "1.9.0". Anfangs dachte ich, das wäre die Beta-Reihe für 2.0, aber da hatten wir uns gegen entschieden, wenn ich das richtig verstanden habe. 1.9.0 ist der jetzige Stand und soll, sofern da noch jemand was dran macht, Bugfixes enthalten. So haben wir eine (mehr oder weniger) lauffähige Fassung vom monitor mit MySQL-Anbindung. Das, was wir hier so beschreiben und als Ideen ansammeln, ist aber alles für 2.0, richtig? Ich möchte das einfach nur aus technischen Gründen auseinander halten. Das macht die Arbeit mit subversion und BTS einfacher...

Außerdem halte ich es für sinnvoll, die Ideen mal konzeptionell zusammen zu fassen. Am Besten wär's, wenn das jemand machen könnte, der auch programmieren kann und versteht, was hier beschrieben ist (buebchen?). Wenn das geschehen ist, sollten wir tatsächlich einmal versuchen, einen gemeinsamen Chat hinzukriegen, sodass man mal abstecken kann, wer was leisten kann und will. Danach (oder meinetwegen auch davor) sollten wir das gesammelte ToDo ins BugTrackingSystem eintragen*.

Auch schön wäre ein grober Zeitplan, aber das sollten wir in den Chat verlegen, weil wir dann wissen, welche Kapazitäten wir haben.

Alles okay so?
jhr

* Aufgaben können da voneinander abhängig gemacht werden. Man kann also große Ziele und kleine als Bugs beschreiben und dann die großen von den kleinen abhängig machen. Außerdem können Aufgaben zugewiesen werden. Dadurch kann man leicht nachvollziehen, wer was macht und an wen man sich wenden muss, wenn sich was überschneidet o.Ä.

Buebchen
18.04.2007, 11:30
Hmm. Im Grunde wären wir dann bei Version 2.0 - Das stimmt wohl :-)

Bei der jetzigen Version 1.9 würde ich wenn nur noch Bugfixes machen. Wartung und Lesbarkeit des Source-Codes ist eine Katastrophe (oder eben nah dran).

Zur Zeit stehen wir ungefähr hier (wie schon nepomuk beschrieben hat):

Trennung von Auswertung und Anzeige / Speicherung in zwei eigenständige Programme. Als Verbindenden Element werden IP/TCP Verbindungen genutzt. Auf gleiche Weise arbeiten inzwischen fast alle Programme (Crusader, FMS32, ELS-PRO,...).

Alles weitere sind Details (grosse und kleine) zur Programmierung. Da wäre z.B. die Frage, ob schon jemand mit den Tools der Boost Lib gearbeitet hat (www.boost.org) oder jthreads (http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jthread). Um das ganze direkt auch auf mehrere Plattformen laufen lassen zu können wären das nach meiner Meinung recht geeignete Mittel (Ich würde gerne direkt eine Windows und Linux Version in C++ entwickeln wollen).

Bei Jthreads gibt auch noch eine RTP Library. Sieht recht vielversprechend aus ( wenn sie denn auch läuft ;-)) für die Live-Übertragung von Sounddaten an die Clients.

Werde mal ein paar Diskussionbeiträge im BTS erstellen. Ist meistens einfacher zu planen, wenn es schon einen groben Plot gibt über den man streiten kann :-)

nepomuck
18.04.2007, 14:33
Das, was wir hier so beschreiben und als Ideen ansammeln, ist aber alles für 2.0, richtig?

Ja. In den 1.x-Spaghetti-Code würde ich nur noch das Minimum an Arbeit investieren. Wenn sich schon ein paar Leute gefunden haben, die aktiv an dem Projekt weiter arbeiten möchten, dann sollten wir gleich die Modularisierung und damit Version 2 in Angriff nehmen.



Auch schön wäre ein grober Zeitplan,

Der dürfte in erster Linie von Buebchen abhängen, da er die eigentlichen Änderungen im Code durchführen muss. Ich bin hier leider nur eine kleine Hilfe, da ich keinen eigenen Code zusteuern kann



aber das sollten wir in den Chat verlegen

Muss das unbedingt im Chat sein? Ich bin da kein Freund davon weil's lange dauert und eigentlich nicht viel dabei rumkommt. Wie wär's mit einer VoIP-Telefonkonferenz, via Skype oder so?



weil wir dann wissen, welche Kapazitäten wir haben.

Fang doch schon mal eine Liste an:
Buebchen: Head of Development und Meister des Codes :-)
Nepomuck: Designvorschläge, schlau daherreden, Bugfixing, Testing, Dokumentation, Live-CD bauen.
Zudem kann ich, falls erwünscht, Web-Space und Internet/Speicher-Kapazität anbieten. Ich verfüge über eine 10 MBit/s Standleitung mit ein paar festen IP-Adressen und kann ins Internet hängen was ich will. Ich würde dazu passend einen oder mehrere (auch virtualisierte) Server stellen.



Es wäre auch vorstellbar, einen "Decoder" zu schreiben, der die Daten als mp3 Stream aufbereitet und dem Client direkt "live" senden.

Machbar ist viel. Wir sollten uns aber für die Version 2.0 nicht zu viel vornehmen. Ich würde diese Funktion als "Kür" einstufen, die "Pflicht" ist jedoch zunächst die grundlegende modularisierung und die Kommunikation Back-Frontend.



Ausserdem wäre dann noch zu klären, wie die Aufnahme zum Frontend kommt.

In der Version 2.0 soll sich da jemand anderes drum kümmern (NFS/SAMBA). Der monitord kann die Aufzeichnungen auf einem File Share sichern und das Frontend holt sie da ab. Stand heute gibt's im Frontend ja auch noch keinen integrierten Player. Das Streaming würde ich erst ein einer späteren Version berücksichtigen.



Ich würde das Konzept auch direkt auf mehrere Soundkarten erweitern. Warum nicht direkt zwei oder mehr Soundkarten ermöglichen ?

Das sollte das modulare Konzept ja ohnehin beherrschen. Das Frondend kann über den Control-Port problemlos Anweisungen für mehr als eine Soundkarte übermitteln und dabei die jeweilige monitord-Instanz instruieren.

Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt. Darüber erhält er @rec-Anweisungen, kann zur Laufzeit konfigurationsänderungen vornehmen oder ferngesteuert einzelne monitord-Instanzen starten und stoppen.
Jede monitord-Instanz steht für ein komplettes Sounddevice und damit für zwei Kanäle. Jede Instanz verfügt über einen eigenen TCP-Port, auf dem sie die Auswertungen an mehrere Frontends übermittelt.



Ich würde gerne direkt eine Windows und Linux Version in C++ entwickeln wollen.

Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.

Ich würde daher folgende Vorgehensweise vorschlagen:

1. Code entwirren und modularisieren (Buebchen)
2. Backend "monitord" und Launcher bauen (Buebchen)
2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
7. Release 2.0
7a. Release Bosix 0.2 :-)
8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

jhr-online
18.04.2007, 18:51
@buebchen: Korrekt. :)
@nepomuck: Nicht zu schnell verteilen! Wir haben noch mehr Entwickler und auch noch eine Menge vor. Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist. Skype kommt mit mir nicht in die Tüte (proprietär), was nicht heißt, dass du nicht jeden anrufen darfst ;)

jhr

nepomuck
18.04.2007, 19:39
Nicht zu schnell verteilen! Wir haben noch mehr Entwickler

Ich wollte nur mal ein paar Basics verteilen, damit mal was vorwärts geht. Selbstverständlich sollen so viele mitarbeiten wie möglich.
Lass uns eine Liste der Projektteilnehmer zusammenstellen und dabei berücksichtigen, was wer tun kann und tun möchte.



und auch noch eine Menge vor.

Hier bitte Vorsicht: Lass uns nicht zu viel auf einmal in 2.0 planen, sonst geht das ganze irgendwann baden. Erst Pflicht, dann Kür -- und ich glaube wir sind uns in so weit einig, dass die saubere Trennung von Frond und Backend absolute Priorität hat -- wenn das steht, bleibe genug Zeit, "eine Menge" anderer Dinge dazuzuprogrammieren.



Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist.

Sehe ich ja ein.
Schlag einen Termin vor, ich kann morgen oder Fraitag sowohl tagsüber als auch mal abends oder spätabends -- immer voraus gesetzt, es brennt nicht :-)

Andreas

Buebchen
18.04.2007, 21:51
Chatten ginge im Grunde auch mal ausnahmsweise während der Arbeit. Sofern sich keiner wundert, daß ich mal für 20 Minuten abwesend wirke (weil dann ggf. ein Anruf reinkommt) - ich würde aber schon weiterhin mitlesen.

Ansonsten wäre mir ab 21:00 Uhr recht. Da ist die Change da, daß ich ein wenig Ruhe habe (Kinder im Bett :-) ).

Buebchen
18.04.2007, 22:08
Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt.


Ähh. Hast Du ne Zeitmaschine oder so ?



Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.


Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)



Ich würde daher folgende Vorgehensweise vorschlagen:

1. Code entwirren und modularisieren (Buebchen)
2. Backend "monitord" und Launcher bauen (Buebchen)
2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
7. Release 2.0
7a. Release Bosix 0.2 :-)
8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

Grundsätzlich würde ich das nicht alleine schaffen können. Deswegen bin ich froh, daß es noch andere Entwickler gitb. Neben diesem Projekt habe ich noch ein Hardware-Projekt laufen (4fach Besprechungsstelle mit Headset-Möglichkeit und PC Fernsteuerung - µC gesteuert) und ausserdem noch meinen "Dauerbrenner" Einsatzunterstützungsprogramm - der läuft schon seit Jahren. Da kommt dann auch der Windows-Port her.

zu 4: Alles was das Frontend angeht ist ManuelW unser Mann (sofern er will). Ich könnte das zwar auch noch machen aber dann würde es wohl noch einige Zeit dauern, bis ich dazu komme...

zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt (monitord). Nun habe ich einen zweiten Dienst (Verarbeitungsserver) der alle "interessanten" Änderungen in der Datenbank erkennt und an die Clients, die sich per TCP verbunden haben meldet. Dies geschieht in der Form: "Änderungen FMS - Zeile 45000 ist neu, Einsatzmittel dazu hat den ID-Wert 5500". Nun kann jeder Client selbst entscheiden, ob ihn das interessiert und holt sich bei Bedarf den kompletten Datensatz aus der Datenbank.

Alles andere ist erstmal ok. Verteilung und Roadmap kommt dann sicherlich im IRC/TelCo/wo-auch-immer.

Dove
18.04.2007, 22:30
Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)


da möchte ich wxWidgets für C++ vorschlagen.
Damit entwickeln wir einen Sourcecode und kompilieren den unter win und unix ohne was dran geändert zu haben.

nepomuck
18.04.2007, 23:20
Ähh. Hast Du ne Zeitmaschine oder so ?
Nein, warum?



zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt

Ach so. Ich dachte, es würde genügen stumpf und uninterpretiert alles was vom Backend kommt erst einmal in eine DB zu schreiben und einem anderen Task das spätere auswerten zu überleassen.

Ich hatte nur die Idee, den MySQL-Teil als eigenes Modul vom bestehenden Frontend zu trennen, so das man den Monitor auch ohne MySQL betreiben kann.

Andreas

Buebchen
19.04.2007, 00:22
Nein, warum?


Weil Du geschrieben hast "es gibt ...". Da bin ich gerade mal ein wenig verwirrt. Gibt es einen Launcher für den monitord ?



Ach so. Ich dachte, es würde genügen stumpf und uninterpretiert alles was vom Backend kommt erst einmal in eine DB zu schreiben und einem anderen Task das spätere auswerten zu überleassen.

Ich hatte nur die Idee, den MySQL-Teil als eigenes Modul vom bestehenden Frontend zu trennen, so das man den Monitor auch ohne MySQL betreiben kann.


Die Trennung finde ich ok. Warum auch nicht. Man muss ja auch nicht in die SQL Datenbank schreiben. Für mich ist die Funktion wichtig. Ich will insbesondere FMS und Alarmierung dokumentiert wissen. Aber andere können bestimmt ohne leben.

@Dove: wxWidgets hatte ich mir mal angeschaut. Sah nicht schlecht aus. War mir zu dem Zeitpunkt aber zuviel Einarbeitung :-( Für das Backend zum Glück auch erstmal nicht erforderlich.

Dove
19.04.2007, 00:27
@Buebchen:
für das Backend ist das wirklich nicht erforderlich.
Für das Frondend sicherlich eine gute möglichkeit.

Muss man gucken wie man das realisiert oder was für andere Vorschläge noch kommen bzw welche, die hier schon vorgestellt wurden, anklang finden.

In wxWidgets bin ich grade drin :D

nepomuck
19.04.2007, 01:04
Man muss ja auch nicht in die SQL Datenbank schreiben. Für mich ist die Funktion wichtig. Ich will insbesondere FMS und Alarmierung dokumentiert wissen.

Mir ist das auch wichtig -- aber auf getrennten PCs. Auf dem eigentlichen Monitor-Rechner soll kein MySQL laufen, da dieser von CD startet (Bosix) und da würde eine aktive SQL-Datenbank nur stören.
Ich habe einen MySQL-Server im Netz und der soll die Daten erhalten.

Andreas

Buebchen
19.04.2007, 01:57
Mir ist das auch wichtig -- aber auf getrennten PCs. Auf dem eigentlichen Monitor-Rechner soll kein MySQL laufen, da dieser von CD startet (Bosix) und da würde eine aktive SQL-Datenbank nur stören.
Ich habe einen MySQL-Server im Netz und der soll die Daten erhalten.

Andreas

Habe ich auch so gemacht. MySQL läuft am besten auf oder "neben" dem Webserver, da diese intensiver Daten austauschen. Der monitord schickt im Vergleich dazu nur geringe Datenmengen.

Die Frage ist also eigentlich, ob der monitord direkt in die SQL-DB schreibt, oder aber ein angemeldeter Client (=Robot) das erledigt.

funkwart
19.04.2007, 10:19
Hallo Forum,

hier tut sich ja gewaltig etwas! Sehr gut, ich bin gespannt, was bei Euren Bemühungen herauskommt.
Leider kann ich nur wenig hier beisteuern, weil ich leider nur begrenzte Ahnung in den Bereichen Programmierung, Netzwerk, DB habe.
Trotzdem denke ich, dass es doch relativ egal ist, wo der MySQL Server läuft, auf dem die Daten gesammelt werden. Wenn man dem Backend angeben kann, unter welcher IP der MySQL-Server erreichbar ist, ist es doch schnurzpiepe, ob der auf 192.168.x.y oder 127.0.0.1 läuft. Der User muss halt nur, wenn er MySQL-Unterstützung auswählt, einen Server einrichten und die Adresse angeben.
Oder habe ich da was falsch verstanden?

Gruß,
Funkwart

PS: Als Tester stehe ich natürlich gerne zur Verfügung. ;-)

Buebchen
19.04.2007, 13:46
Also von meiner Seite aus wäre es gut, daß Kommunikationsprotokoll zügig zu definieren. Denn ohne geht es auf beiden Seiten der Entwicklung wohl nicht so recht weiter :-)

Habe im bts.jhr-online.de dazu mal einen Eintrag erstellt ( http://bts.jhr-online.de/?do=details&task_id=8 ) und wäre für Vorschläge dankbar.

[Edit]
Mein Favorit wäre übrigens XML. Da sind Erweiterungen leicht zu realisieren und ältere Clients finden trotzdem "Ihre" Daten im XML wieder.

MiThoTyN
19.04.2007, 16:26
Tach zusammen!

Zum Thema Datenprotokoll möcht ich mich auch mal einklinken. Ich werde sicher auch den ein oder anderen Client von mir auf den Monitor dann anpassen. Und da z.B. auch der Crusader ein eher schlechtes Protokoll verwendet, sollte das beim monitor tatsächlich sehr durchdacht sein.

Zur Auswahl stehen ja zur Zeit zeilenweise Datensätze mit Trennzeichen, oder XML. Ich sehe in der Zeilenweisen Kommunikation den Vorteil, dass vor allem der Client beim Auswerten der Daten sehr einfach gehalten werden kann. Zeile einlesen, an Trennzeichen trennen, und die einzelnen Parameter verarbeiten. Fertig. Bei XML müsste man einen größeren Umstand betreiben und einen XML-Parser benutzen. Das erhöht den Aufwand zum Empfang und zur Auswertung und vor allem auch den Datenverkehr auf der Schnittstelle. Gerade der Datenverkehr sollte sehr gering gehalten werden, um auch Handys oder PDA's nicht zu benachteiligen. Denn hier bezahlt man nach wie vor hauptsächlich pro Datenmenge.

Den Hauptvorteil von XML, das Protokoll flexibel zu erweitern und dabei Abwärtskompatibel zu halten sehe ich übrigens nicht. Bei ZVEI, FMS und POCSAG sind die zu übertragenden Daten konstant und ändern sich nicht mehr. Auch was Benutzeranmeldung und die wichtigsten Steuerbefehle angeht, kann man hier ein minimum definieren, was jede Version beinhaltet. Somit können alte Clients auch mit moderneren Servern kommunizieren. Die Clients können dann halt die "neuen" Features nicht benutzen und ignorieren diese einfach.

Sollte es tatsächlich mal nötig sein das Protokoll grundlegend zu ändern, kann man im Server ja einen Kompatibilitätsmodus einbauen. Der Client teilt dem Server mit, welche Version er hat und der Server entscheidet dann, welche Protokollversion für diese Verbindung benutzt wird. Ist vielleicht etwas mehr Aufwand im Server, aber sollte meiner Meinung nach nicht sehr schnell akut werden. Bei entsprechend modularisierter Bauweise des Servers, wird dazu dann eh nur ein anderes Protokoll-Modul benutzt. Mit solchen Modulen ließe sich auch nach entsprechendem ersten Handshake eine Datenübertragung per XML einstellen. Je nach Vorlieben des Clients. Vielleicht implementiert man auch die Protokolle von FMS32 und Crusader und kann diese dann pro Channel in der Konfiguration als default aktivieren. (Oder eben "auto" als default, und die Protokollversion wird per Handshake ausgehandelt)

Ich plädiere also dafür, dass das Haupt-Protokoll zeilenweise arbeitet und in beiden Richtungen alle Befehle mit Nummern versehen werden. So wie man das von SMTP oder FTP kennt. Zusätzlich sollten bei der Definition der Datenfelder auch gleich Gültigkeitsbereiche definiert werden, die dann der Client zur überprüfung der Daten verwenden kann. Ggf macht es auch Sinn eine Prüfsumme über die Zeile mitzusenden.

Gruß Joachim

A.Nero
19.04.2007, 16:49
Hi, ich wuerde auch mithelfen beim Programmieren, wobei ich nur relativ wenig php und perl kann. Viel Zeit bleibt mir durchs Studium auch nicht, aber kleine Sachen wuerde ich schon versuchen beizusteuern

Buebchen
19.04.2007, 17:02
Bei XML müsste man einen größeren Umstand betreiben und einen XML-Parser benutzen. Das erhöht den Aufwand zum Empfang und zur Auswertung und vor allem auch den Datenverkehr auf der Schnittstelle. Gerade der Datenverkehr sollte sehr gering gehalten werden, um auch Handys oder PDA's nicht zu benachteiligen. Denn hier bezahlt man nach wie vor hauptsächlich pro Datenmenge.


Das ist ein gutes Argument.



Den Hauptvorteil von XML, das Protokoll flexibel zu erweitern und dabei Abwärtskompatibel zu halten sehe ich übrigens nicht. Bei ZVEI, FMS und POCSAG sind die zu übertragenden Daten konstant und ändern sich nicht mehr.


Nun ja. Ich sehe das halt schon. Weniger an dem FMS Daten. Keine Frage. Aber man könnte dann später z.B. noch den Klartext-Namen Fahrzeugs mitsenden (wenn der monitord eine eigene DB hat). Und was es noch so gibt.



Ich plädiere also dafür, dass das Haupt-Protokoll zeilenweise arbeitet und in beiden Richtungen alle Befehle mit Nummern versehen werden. So wie man das von SMTP oder FTP kennt. Zusätzlich sollten bei der Definition der Datenfelder auch gleich Gültigkeitsbereiche definiert werden, die dann der Client zur überprüfung der Daten verwenden kann. Ggf macht es auch Sinn eine Prüfsumme über die Zeile mitzusenden.
Gruß Joachim

Na, dann mach mal einen Entwurf :-)

Dove
19.04.2007, 17:06
ich würde von XML in der Datenübertragung weg gehen und ein eigenes "Protokoll" schreiben.
D.h. Zeichenketten als Trennzeichen.
Es sollte ein Start und Stop und Trennzeichen geben.
Z.B.

###param1##param2##param3##param4===
sowas in der Art.

oder ähnliches.
So machen wir das bei einem anderen Projekt auch und funktioniert wunderbar.

Buebchen
19.04.2007, 17:07
Hi, ich wuerde auch mithelfen beim Programmieren, wobei ich nur relativ wenig php und perl kann. Viel Zeit bleibt mir durchs Studium auch nicht, aber kleine Sachen wuerde ich schon versuchen beizusteuern

Danke für die Unterstützung. Auch kleine Dinge können eine grosse Hilfe sein. Das wichtigste ist sicherlich, daß Du dich traust zu sagen: "Das versuche ich", wenn Du ein Thema findest, daß Du für machbar hälst. Gerade im Bereich der WebTools gibt bestimmt ne Menge kleiner Gimmicks, die viel helfen können.

jhr-online
19.04.2007, 17:19
Mal wieder was pragmatisches ;)
Wenn ich das richtig überblicke, haben wir derzeit folgende Aktive (alphabetisch):

A.Nero
Buebchen
Dmitri_P
Dove
jhr-online
ManuelW
Max K.
MiThoTyN
nepomuck
Paneologe
SirFS

Ich fänd's total supi (*g), wenn mir alle kurz eine PN o.Ä. schicken könnten, in der sie mir ihren RL-Namen verraten und in zwei Stichworten kurz sagen könnten, was sie beitragen können/wollen. Danach bitte im BTS registrieren und ich trage euch als Developer ein, sodass ihr Aufgaben verändern und zuweisen könnt etc.
Ich will nicht zu viel Bürokratie hier einbringen, aber es wäre schon schön, einmal zu sammeln, was man für Potential hat. Dann mache ich einen groben Überblick fertig über das, was gemacht werden muss, und die, die es könnten.

Einverstanden?

nepomuck
19.04.2007, 18:47
ich würde von XML in der Datenübertragung weg gehen und ein eigenes "Protokoll" schreiben. D.h. Zeichenketten als Trennzeichen. Es sollte ein Start und Stop und Trennzeichen geben.

Das halte ich für eine gute Idee.

Vorschlag:
Wir legen zuerst die Datenfelder und die Reihenfolge fest, wie die Infos vom Backend aus gesendet werden. Beim Trennzeichen müssen wir uns auf was einigen, was nicht in der Meldung vorkommen kann, wie ":". Evtl. sollten wir Texttelegramme in Hochkomma stellen. Alles, was nicht in Hochomma steht ist nicht case-sensitiv. Alle Kommandos sollten möglichst eindeutig sein, dass sich auch fragmente einer Übermittlung zuweisen lassen. In FMS-Textmitteilungen dürfen Steuercodes drin sein. Wir könnten entweder das Telegramm gleich in Hex-Codes übermitteln (und uns die Hochkomma sparen) oder die Steuerzeichen in Spitzklammern angeben.

1. Servername
2. Kanal, Werte L oder R
3. Dienst, Werte ZVEI,FMS,POCSAC,TEST (sonstige?)

ZVEI:
4. Schleife
5. DTFM-Auswertung, Werte OHNE, FEUER, PROBE, WARNUNG, ENTWARN, ZIVIL
6. Abschlusmeldung "ZVENDE" (oder wie wärs mit "HABEFERTIG" :-)

Beispiel:
monitor1:L:ZVEI:12345:FEUER:ZVENDE

FMS:
4. Meldung
optional 5. Wenn ein Folgetelegramm kommt, steht hier TEXT
optional 6. Folgetelegramm in Hochkomma
5,6 oder 7. Abschlussmeldung "FMSEND"

Beispiel:
server07:R:FMS:631172141000:FMSEND
monitor1:R:FMS:631172140000:TEXT:"Kardio{CR}Hauptstrasse 5{CR}Huber{EOT}":FMSEND
(Spitzklammern kriege ich im Forum nicht hin, daher sind hier geschweifte abgebildet)
- oder -
monitor1:R:FMS:631172140000:TEXT:4B617264696F13486 17570747374726173736513487562657204:FMSEND

POCSAC:

damit kenne ich mich nicht aus.

was haltet ihr davon?

Andreas

nepomuck
19.04.2007, 18:50
1. Servername
2. Kanal, Werte L oder R


Ooops, fast vergessen:

1. Server,
2. DATUM/UHRZEIT YYMMDDHHMMSS
3. Kanal ....

also

monitor1:070417034312:ZVEI:26250:FEUER:ZVENDE

funkwart
19.04.2007, 20:34
Die Idee ist gut, aber bei der Auswahl des Zeichens solltet Ihr nochmal gründlich überlegen: Ein Doppelpunkt kann durchaus in Meldungen vorkommen, sogar einigermaßen häufig. Am besten etwas wie § oder ° oder | oder µ oder oder oder nehmen, irgendwas, das mit großer Sicherheit nicht auftaucht. Vielleicht sogar eine Kombination wie §*§ oder §°§.
Ihr findet da schon etwas.

Gruß,
Funkwart

Buebchen
19.04.2007, 21:19
Wir wäre sonst das Konzept, daß auch früher auf dem Amiga mal "IN" war (Bstrings): Da ist das erste Byte ein Längenbyte. Man könnte vor jedem Text dann einfach die Länge vorher angeben. Wäre sogar resistent gegen Nullbytes.

....:050:{50-zeichen}:....

Dove
19.04.2007, 21:27
Die Idee ist gut, aber bei der Auswahl des Zeichens solltet Ihr nochmal gründlich überlegen: Ein Doppelpunkt kann durchaus in Meldungen vorkommen, sogar einigermaßen häufig. Am besten etwas wie § oder ° oder | oder µ oder oder oder nehmen, irgendwas, das mit großer Sicherheit nicht auftaucht. Vielleicht sogar eine Kombination wie §*§ oder §°§.
Ihr findet da schon etwas.

Gruß,
Funkwart

es würden ja auch mehrere trennzeichen genommen werden: §§§ oder so.

das Datum würde ich als datetime übertragen also als unix timestamp.
damit kann man ab besten arbeiten und überall verwenden.

nepomuck
20.04.2007, 01:27
@funkwart
Auch recht. Aber der Doppelpunkt kommt wenn, dann nur in Textmeldungen vor und die sind dann entweder in Hochkomma gestellt oder Hex Dekodiert
@Buebchen
Das Längebyte könnte man in die TEXT-Anweisung einbauen, also: ...FMS:1234567890ab:TEXT(5):6520136565:...

Die Fragen sind

- brauchen wir weitere Felder?
- darf der Cllient was zu Server senden und wenn ja was?
- gibt es dafür einen eigenen TCP-Port oder läuft alles über einen?
- gibt es eine "private" kommunikation zwischen server und client oder nur einen multicast vom server aus

Andreas

funkwart
20.04.2007, 08:57
@funkwart
Auch recht. Aber der Doppelpunkt kommt wenn, dann nur in Textmeldungen vor und die sind dann entweder in Hochkomma gestellt oder Hex Dekodiert
[...]
- gibt es eine "private" kommunikation zwischen server und client oder nur einen multicast vom server aus

Andreas
Zum ersten Punkt: Stimmt, wenn es denn so einfach ist, das auseinander zu halten, meinetwegen. Trotzdem wäre es doch in Ordnung, ein Zeichen mit noch geringerer Auftet-Wahrscheinlichkeit zu wählen.
Zum zweiten Punkt: Ich denke, es sollte schon eine Identifizierung bzw. Authentifizierung von Clients geben, somit müssen diese ja zwangsläufig mit dem Server kommunizieren. Ich weiß, dass das keine Sicherheit darstellt, weil Klartext-Übermittlungen ohne Probleme mit einem Sniffer mitgelesen werden können, aber es ist zumindest nicht so einfach, nur einen Client zu starten, die monitor-Server-IP zu geben und lustig alles mitzulesen.

Gruß,
Funkwart

jhr-online
20.04.2007, 10:42
Wir können die Daten auch gpg-verschlüsseln... *SCNR*

jhr

Dove
20.04.2007, 10:55
kurze frage.

sind daten wie auf welchem kanal das signal anlag für das frondend interesant ?
Ich finde nicht. Ich finde das sowas auch weg gelassen werden könnte, oder nicht ?

MiThoTyN
20.04.2007, 11:49
Doch das ist sehr wichtig. Weil du 2 verschiedene Funkkanäle pro Line-Eingang auswerten kannst. Also muss das Frontend auch wissen, von welchem Kanal die Auswertung stammt.

Zum Datenformat selbst noch was grundsätzliches. Die Länge pro Zeile und pro Datenfeld sollte minimiert gehalten werden. Diese Datenzeile muss vom Menschen nicht gelesen werden können. Auf Klartexte wie bei den DTMF-Tönen FEUER, PROBE und sowas kann man also verzichten. Eher sollte man solche starren Werte einfach mit Nummern belegen. Also 1=Feuer, 2=Probe und so weiter. Verringert erstens die Datenmenge und lässt sich im Frontend leichter auf Richtigkeit überprüfen, denn das Feld mit dem Sirenenton hat dann einfach einen Gültigkeitsbereich von 1 bis 6 (z.B.).

Auch sollten die Befehle kategorisiert und nummeriert werden. Bsp:

100er : Steuerbefehle von Server
200er : Steuerbefehle vom Client
300er : FMS
400er : ZVEI
500er : POCSAG

usw.

Texte würde ich in der Tat gleich Hexadezimal übertragen. Vergrößert zwar die Datenmenge, erledigt aber alle Probleme mit Steuerzeichen im Text. Diese müssen dann nicht erst einzeln durch entsprechende "harmlose" Synonyme ersetzt werden.

Die Angabe einer Länge finde ich überflüssig. Die Daten werden eh von Trennzeichen eingegrenzt. Die Längenangabe ist dann höchstens von Bedeutung, wenn der übergebene Text auf richtig übertragene Länge geprüft werden soll. Aber ob der Inhalt stimmt, kann man mit der Längenangabe nicht prüfen. Sinnvoller wäre es nach wie vor, über die komplette Zeile eine Prüfsumme zu bilden. Dann kann schon das Fehlen eines Bits erkannt werden.

Um das ganze richtig Fehlertolerant zu machen, könnte man noch jede Zeile mit einer eindeutigen ID versehen. Wenn der Client eine Zeile als Falsch erkennt (Checksumme oder Datenfeldgültigkeit), kann er diese Anhand der ID beim Server nochmal anfordern.

Ein paar Zeilen Daten zur Anschauung :

(§=Trennzeichen //=Kommentar für euch)
XXX- (Mit Bindestrich: Daten nach Befehlsnummer nur zur Info)
XXX (Ohne Bindestrich: Daten nach Befehlsnummer zum Bearbeiten)

// 100 Server Identifikationssting
100 monitord
// 101 Server Versionsstring
101 V1.20
// 200 Client Identifikationsstring
200 Jogis Super Frontend // 200
// 201 Client Versionsstring
201 V3.40
// Client will Protokollversion MON3
202 MON3
// Server stimmt zu
202 MON3

103-Login
203 username§passwort
104-Login correct

// 111 Server Kanal links§rechts
111 kanal501§rettungsdienst
299-OK

// ZVEI Auswertung Kanal§Folge§Doppelton$timestamp
400 1§67223§1§071102192233
299-OK

400 1§67223§1§98733,,,,,,, (Fehler)
298-ERR

Usw usw .... Wenn ich mal ne Stunde ZEit hab heute Abend, kann ich mal bischen Gehirnschmalz da reinstecken. Also ich entwickel mal ne erste Protokollversion und leg die hier zur Ansicht vor.

Gruß Joachim

nepomuck
20.04.2007, 13:13
@funkwart;@jhr-online
Ich glaub, dass abhörsicherein ein Feature mit niedriger Priorität ist. Eine künftige Version könnte das Monitor-Protokoll via SSL übertragen.

@MiThoTyN
Auch eine gute Idee, wobei ich glaube dass es bei der Datenübermittling nicht auf jeden einzelnen Charakter ankommt und ein im Klartext lesbares Protokoll bei Debugging hilft.

Dein Protokoll setzt ein Login voraus und legt damit fest, dass jeder Client über einen eigenen Kanal mit dem Server spricht. Das ist auf jeden Fall die sauberere Variante als ein one-way Multicast. Ich hoffe, dass es kein zu großer Aufwand beim Programmieren des Backends wird.

Vorschläge
Ich würde in das Protokoll auch noch eine Art "Ping" integrieren, damit der Client/Server von Zeit zu Zeit die Verbindung prüfen kann.

Beispiel:
297 Alive
199 OK
oder
197 Alive
299 OK

Vieleicht wäre es auch ganz nett, eine History-Funktion einzubauen, so dass ein Client beim Start die letzten Ereignisse nachfragen kann

123 lastevents 10
401 1§26100§0§datetime (0 ist ohne DTFM also Melderauslösung)
401 1§26250§1§datetime
401 1§26380§1§datetime
401 1§26433§0§datetime
401 1§26104§0§datetime
499 END
299 OK

und für FMS wäre natürlich wichtig, dass der Client nach dem Start den aktuellen Fahrzeigstatus der Flotte abfragen kann:

147 fmsstat
501 63117214§6§datetime
501 63117215§7§datetime
501 63117256§1§datetime
501 63117603§1§datetime
...
599 END
299 OK

Vieleicht würde es den Entwicklern zudem helfen, einige Testkommandos einzubauen:

222 test§1§zvei§12345§1
400 1§12345§1§datetime

Andreas

MiThoTyN
20.04.2007, 14:25
Diese "History-Funktion" wollte ich auch noch ansprechen. Das ist was, was man im Vorfeld auch abklären muss. Die Frage ist, ob diese History vom Auswerter kommt. Eigentlich könnte es auch aus einer Datenbank kommen. Da aber der monitor selbst keine Datenbank ansprechen soll, muss die History aus einem Speicher-Puffer kommen. Dieser kann dann natürlich nicht beliebig groß sein und die Anzahl der enthaltenen Datensätze muss begrenzt sein.

Theoretisch müsste man pro Signal-Art (ZVEI, FMS, POCSAG) einen eigenen Puffer bereithalten. Bei FMS macht es sogar Sinn, zwei getrennte Puffer vorzuhalten. Einen mit den letzten X Telegrammen (chronologisch geordnet) und einen mit dem aktuellen Status pro bekannter Kennung (nach Kennung geordnet).

Das ist aber meiner Meinung nach was, was in eine Datenbank gehört, bzw aus einer Datenbank kommen muss.

Wie sind die Meinungen dazu? Monitor doch gleich mit Datenbankanbingung bauen? Andere Möglichkeiten?

Gruß Joachim

nepomuck
20.04.2007, 15:14
Da aber der monitor selbst keine Datenbank ansprechen soll, muss die History aus einem Speicher-Puffer kommen.


Das stelle ich mit einfacher vor. Das Backend kann wie bisher eine LOG-Datei schreiben. Die enthält die "rohen" Codes, so wie sie auch über das Netz übertragen werden.
Ein History-Query kann des Backend dann ganz einfach aus den letzten Zeilen der LOG-Datei beantworten.

Mann kann diese Funktion ja darauf beschränken, dass der Client nicht explizit irgendwelche Services abfragen kann, so dass das Backend ihm einfach die geforderte Zahl an Zeilen aus dem LOG übermittelt.

Auswerten muss dann das Frontend -- aber dafür ist es ja sowieso konzipiert.

Für FMS könnte mann theoretisch ein Status-LOG generieren. Da schreibt das Monitor-Backend einfach sequentiell alle Status-Meldungen (Fahrzeug, Status,Uhrzeit) rein.
Vor jedem Eintrag prüft das Backend, ob das entsprechende Fahrzeug schon in der Liste steht und löscht einfach die Zeile mit dem alten Eintrag, bevor er den neuen anhängt.

Andreas

Buebchen
20.04.2007, 16:01
Die Angabe einer Länge finde ich überflüssig. Die Daten werden eh von Trennzeichen eingegrenzt. Die Längenangabe ist dann höchstens von Bedeutung, wenn der übergebene Text auf richtig übertragene Länge geprüft werden soll. Aber ob der Inhalt stimmt, kann man mit der Längenangabe nicht prüfen. Sinnvoller wäre es nach wie vor, über die komplette Zeile eine Prüfsumme zu bilden. Dann kann schon das Fehlen eines Bits erkannt werden.

Um das ganze richtig Fehlertolerant zu machen, könnte man noch jede Zeile mit einer eindeutigen ID versehen. Wenn der Client eine Zeile als Falsch erkennt (Checksumme oder Datenfeldgültigkeit), kann er diese Anhand der ID beim Server nochmal anfordern.


CRC und alles vergleichbare ist ein eine TCP Verbindung nicht sinnvoll. Sofern man nicht gerade Man-In-The-Middle Attacken erkennen will sorgt das TCP schon für den korrekten Transport der Daten.

Checksummen würden man bei eher bei RS232 Verbindungen wiederfinden. Gerade wenn ohne Handshake gearbeitet wird geht da öfters mal ein Bit verloren.

Ansonsten bin ich auf die ersten Protokollversion gespannt. History werde ich ermutlich nur über ein SQL Backend machen. Log-File parsen ist nichts, was ich für so richtig toll halte. Zumal man die auch noch rotieren muss ...

MiThoTyN
20.04.2007, 16:46
Die Sache mit dem Log finde ich auch nicht gut. Dann haste plötzlich auch auf Seiten des monitors eine Art Datenhaltung. Das soll ja eben vom monitor getrennt sein und dann von einer Datenbank übernommen werden. Im Endeffekt würd ich also auch sagen, dass der monitor-daemon sturr das weitergibt, was er auswertet. Basta. Um eine History-Funktion muss sich dann ein Client kümmern. z.B. eben die angesprochene mySQL Datenbank, die ja durchaus als Proxy zwischen dem monitor und den weiteren Clients sitzen kann.

Gruß Joachim

nepomuck
20.04.2007, 16:55
History werde ich ermutlich nur über ein SQL Backend machen. Log-File parsen ist nichts, was ich für so richtig toll halte. Zumal man die auch noch rotieren muss ...
Das würde zwangsweise eine MySQL-Datenbank im Backend erfordern. Das würde mir nicht gefallen, da ich dadurch Probleme mit der Live-CD bekomme.

Bislang kann "Bosix" monatelang von CD gebootet arbeiten, wenn es die LOGs sequentiell auf einen simplen USB-Stick schreiben kann. Die permanenten Änderungen an SQL-Tabellen würden das Union-Dateisystem von Knoppix schnell zum überlaufen bringen, so dass die Live-CD wahrscheinlich innerhalb von wenigen Tagen abstürzt.

Ich dränge immer noch auf ein Backend OHNE MySQL.

Das mit dem Logfile-parsen kann doch nicht so komplex sein, oder?

Andreas

MiThoTyN
20.04.2007, 17:24
Nene .. Da haben wir uns schon richtig verstanden. Das eigentliche Backend hat keine MySQL Anbindung. Diese würde ebenfalls per TCP angedockt. Der monitor als Backend übernimmt einzig und alleine die Dekodierung der Funksignale.

Das mit der Logdatei hat meiner Meinung nach zu viele Nachteile. Zum einen ist es echt komplex zu Handhaben. Dateioperationen können immer mal schief gehen. Du musst ständig auf die Datei zugreifen und erzeugst so haufenweise Festplattenzugriffe. Diese kann dann auch nicht in den Standbymodus gehen. Ohne Logdatei läuft der monitor rein im Arbeitsspeicher. Auch musst du die Logdatei rotieren und immer hinten ein Eintrag rauswerfen und vorne einen neuen anfügen. Dazu muss ständig die ganze Datei geladen werden, über nicht wenige Befehle rotiert und wieder gespeichert werden. Rein aus Performance- und Dauerlaufsicht ist ein Dateizugriff in der Form nicht wünschenswert.

Auch sind die Vorteile der Logdatei nicht überzeugend. Sicher ist es für ein Frontend ne feine Sache, wenn es auch Meldungen bekommt, die in der Vergangenheit liegen. z.B. wenn sich das Frontend neu verbinden muss, dann gehen die Meldungen in der Zwischenzeit nicht verloren. Aber was passiert, wenn der monitor selbst mal ne Zeit ausfällt? Dann hast du in den Logdateien noch alte Daten drinne stehen, auf die dann brandneue Daten folgen. Diese werden dann an ein Frontend weitergegeben. Das hat dann plötzlich uralte Daten drinne. Man kann also auch nicht garantieren, dass die Daten aus der Logdatei nicht schon unsinnig sind. Es sei denn man bohrt das entsprechend auf und verwaltet das nach Uhrzeit und alles. Aber das ist ein riesen Aufwand, diesen Datenbestand sinnvoll aktuell zu halten. Und DAS wiederum ist nicht Aufgabe des monitor als solches. Wie gesagt bin ich durchaus für so eine komplexe History. Nur eben als Teil der Datenbank, wo sämtliche Daten eh gespeichert sind.

Gruß Joachim

nepomuck
20.04.2007, 17:39
OK, History entfällt im Backend -> Aufgabe des Frondends.
Das gilt dann auch für den Fahrzeug Status via FMS?

Andreas

jhr-online
20.04.2007, 17:58
OK, History entfällt im Backend -> Aufgabe des Frondends.
Das gilt dann auch für den Fahrzeug Status via FMS?

AndreasIch denke ja; der jeweils aktuelle Status sollte auch aus der DB erfragt werden.

jhr

Buebchen
20.04.2007, 18:09
Ne Ne Ne ... Warum nicht ein externer DB-Server ? Auch die logfiles muss er irgendwo hinschreiben. Da würde CD-Boot auch nicht gehen, bzw. es wäre fast das gleiche.

Mein Vorschlag: Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht. Danach kann man immer noch klären welche Daten die Clients dann vom monitord anfordern können oder nicht. Ggf. können die Clients auch einfach selbst auf dem DB Server zugreifen. Das kann dann jeder Entwickler selbst entscheiden.

Eine Zwischenstufe (TCP Client speichert in DB) wäre denkbar. Aber es ist m.E. nicht sinnvoll, daß die Clients selbst die Daten speichern müssen. Was macht man, wenn man eben erst den Client startet ? Man hätte keine aktuellen Statusinformationen zu den Fahrzeugen. Aber alle in die "6" oder "2" zu stellen ist auch nicht richtig.
Gerade bei der Nutzung in einer nachbesetzten Führungsstelle ist das eine wichtige Information ("Welche Fahrzeuge sind ausgerückt - und wann ?").

nepomuck
21.04.2007, 00:48
Es gibt eine Option für den Backend-DB Server. Entweder ist er aktiv oder nicht.


Folgende Idee, um das Problem zu lösen.

Der eigentliche Backend hat selbst keine DB und schreibt seine Daten per Default in ein klassisches LOG. das kann man auch abschalten.

Es gibt ein SQL-Modul, welches sich regulär per TCP beim Frontend anmeldet und die Auswertungen per ODBC in irgend eine eine SQL-Db schreibt.
Das SQL modul kann auf dem Backend Server oder irgend einer Maschine im LAN arbeiten. Ebenso kann die Db sein wo sie will.

Eine History-Query muss ein Client an das SQL-Modul stellen.
Da sich das SQL-Modul beim Backend anmeldet, kann ein Client-Task bem backend danach fragen und bekommt als Antwort die IP-Adresse des SQL-Moduls.

123 SQL
234 NOPE

oder

123 SQL
234 192.168.23.65:1234

Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.

das hat im gegenzug den vorteil, dass ein task der db-auswertungen mit viel sql-traffic ausführt nicht den backend kanal belastet.

Andreas

Buebchen
21.04.2007, 01:27
Das geht schon eher so in die Richtung, die ich mir vorstellen könnte.

Das TCP-&gt;SQL Modul wäre zwar nicht mein Lieblingsding aber durchaus ok. Dadurch könnte man vor allen Dingen noch ein anderes Problem erschlagen, daß mir in der Praxis schon begegnet ist:

Was macht man, wenn man im Gerätehaus auf einigen Kanälen schlechten Empfang hat ? Richtig: Von einem besseren Standort die ausgewertete Daten holen. Man könnte also in einer Datenbank durch zwei oder mehr solcher Agenten Daten mehrerer monitord sammeln.

Müßte man noch klären, wie die Benutzerdaten verwaltet werden. Ich hatte bisher einfach gegen MySQL Anmeldung geprüft. Konnte man er sich mit den Daten am mysql anmelden (nur als Prüfung), war man auch am "monitord" angemeldet. Der Client konnte sich dann auch am MySQL anmelden (bekam er ähnlich wie nepomuck schon schrieb dann mitgeteilt, wo dieser MySQL zu finden ist).

Hier wäre dann auch direkt das Problem des externen Zugriffs: Hat der MySQL Server eine LAN IP aus Sicht des monitord nützt diese IP einem von aussen (ohne VPN) zugreifenden Client nichts. Man müßte in letzter Instanz auch über ein "masquerading" nachdenken (Fern-Fern-Fernziel).

Ach so:


Vorteil: Die DB ist kein zwingender Bestandteil des backends. Falls die DB ausfällt oder der entfernte sql-server nicht antwortet, funtioniert das Backend regulär weiter.

nachteil: Ein Client der Live-Daten und alte daten auswerten will, muss sich mit zwei TCP-Sitzungen mit dem backend und dem SQL modul verbinden. ausserdem müssen wir ein zweites protokoll zur kommunikation zwischen frontend und sql modul entwickeln.


Nachteil aus meiner Sicht wäre auch, wenn der monitord zwar läuft ich aber im Fall der Fälle keine Auswertungen der Daten machen kann, da der SQL-Agent sich weggehängt hätte.

Ich schaue weniger in die Auswerter aus Neugierde. Eher im Auswertungen zu fahren (Bsp: Ausrückzeiten, Eintreffzeiten) oder Doku zu schreiben.

Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen und direkt auf den Server zugreifen. Alles andere ist ggf. schon wirklich komplex. Gerade wenn auch noch Performance dahinter sein soll. Benutzername und PW dafür sind noch zu klären (dynamisch oder static ...)

nepomuck
21.04.2007, 02:08
Müßte man noch klären, wie die Benutzerdaten verwaltet werden.

Wie wäre es mit "gar nicht". Warum direkt gegen MySQL schreiben? Warum nicht ODBC, dann kann das SQL-Modul gegen jede SQL-Datenbank schreiben und die Login-Verwaltung ist Sache des ODBC-Treibers.



diese IP einem von aussen (ohne VPN) zugreifenden Client nichts.

Da sträuben sich mir die Nackenhaare! SQL via Internet ohne VPN. Warum sollte das jeman tun wollen? Jedes Linux und jedes Windows beherrscht zumindest PPTP.
Ich meine, wenn du ohnehin mit SQL-Server arbeitest, hängst du sowieso ein PHP/WEB-Frontend davor und kommst von außen daran -- warum also SQL direkt?



Als Protokoll zum Backend würde ich vorläufig mysql-Tools nehmen

was zwangsweise einen installierten MySQL-Client im Backend erfordert.



Gerade wenn auch noch Performance dahinter sein soll.

Wenn Funk-Nachrichten mit maximal 1200 Baud eingehen, ist die Performance glaube ich das geringste Problem.

Andreas

Buebchen
21.04.2007, 02:58
Wie wäre es mit "gar nicht". Warum direkt gegen MySQL schreiben? Warum nicht ODBC, dann kann das SQL-Modul gegen jede SQL-Datenbank schreiben und die Login-Verwaltung ist Sache des ODBC-Treibers.


Und woher weiss der SQL Agent, daß die Anmeldung, die da Daten holen will gültig sind ? Wenn ich nen monitor-client habe, der eine History zum Rettungsmittel zeigen soll, dann ist der

* am monitord angemeldet
* am sql angemeldet

... aber mit welchen Benutzernamen und viel wichtiger: wo werden diese zentral gepflegt ? Oder muss man dann immer die Benutzer zweimal anlegen ?



Da sträuben sich mir die Nackenhaare! SQL via Internet ohne VPN. Warum sollte das jeman tun wollen? Jedes Linux und jedes Windows beherrscht zumindest PPTP.
Ich meine, wenn du ohnehin mit SQL-Server arbeitest, hängst du sowieso ein PHP/WEB-Frontend davor und kommst von außen daran -- warum also SQL direkt?

Also mein altes Handy kann mal kein VPN :-)



was zwangsweise einen installierten MySQL-Client im Backend erfordert.


und ? Warum auch nicht ? Wer ihn nicht will kann ihn ja abschalten



Wenn Funk-Nachrichten mit maximal 1200 Baud eingehen, ist die Performance glaube ich das geringste Problem.

Andreas

Wenn ich aus 2 Mio Datensätze die FMS Protokolle eines Standorts für die letzten 24 Stunden filtere und mir anzeigen lassen sind 1200 Baud nicht viel :-)

Wir sollten auf jeden Fall drei Fälle unterscheiden.

1. Ein "Textbasierter Client" wie bisher
Er fragt weder einer Historie ab, noch sonst was. Braucht auch keine DB

2. Ein grafischer Client - Vielleicht eine Mischung aus Crusader und FMS32
Der könnte z.B. schon Daten aus der History-DB abfragen können

3. Ein erweiterter Client, der neben der reinen "Ansicht" der Funkdaten weitere Aufgaben übernimmt (Einsatztagebuch, Meldungsverwaltung, Patientenerfassung,...) und diese mit den Daten der History-DB verknüpft.

Nun ja. Erstmal nicht sooo wichtig. Ich werde definitiv eine Datenbankanbindung schreiben. Wer sie nutzt, kann das tun. Wer sie nicht will schaltet sie eben ab. Wichtiger ist das TCP Protokoll. Sonst gibts auch vorläufig keine Clients.

nepomuck
21.04.2007, 03:29
Und woher weiss der SQL Agent, daß die Anmeldung, die da Daten holen will gültig sind ?

SQL-Agent meldet sich am Backend an -- User meldet sich bei Backend an -- User fragt Backend nach SQL -- Backend übermittelt dem User die IP des SQL-Agenten UND sendet dem SQL-Agenten die IP des Users zu und bestätigt damit, dass er ran darf.



Also mein altes Handy kann mal kein VPN :-)

Einen MySQL-Client wird's dann ja auch nicht haben.



und ? Warum auch nicht ? Wer ihn nicht will kann ihn ja abschalten

Ohne MySQL-Client plus Headers und Libs läuft dann wieder kein Make durch. Oder es kommt ein neues Distributionsupdate mit einem neuen MySQL-Client raus der evtl. nicht zum Code passt und dann hängt wieder alles.
Je weniger Dependencies das Backend hat, umso besser.
Und ich würde Bosix 0.2 liebend gerne von einem USB-Stick anstelle einer CD booten und dafür würde ich die Linux-Distribution gerne so klein wie es irgend geht machen.

MySQL-Client = 5.6 MB. Libs and Headers = 7.3 MB Shared Libs = 1.6 MB
macht 14.5 MB
MyODBC = 2.5 MB



Wenn ich aus 2 Mio Datensätze die FMS Protokolle eines Standorts für die letzten 24 Stunden filtere und mir anzeigen lassen

OK. Aber für das Data-Mining kannst du ja eine Applikation schreiben, die direkt auf MySQL zugreift. Für das Backend würde ODBC genügen.



1. Ein "Textbasierter Client" wie bisher

der nur eine TCP-Verbindung zum Backend herstellt


2. Ein grafischer Client

der per TCP mit dem Backend und dem SQL-Agenten in Verbindung steht


3. Ein erweiterter Client

Der per TCP mit dem Backend und per MySQL-CLient mit der Datenbank in Verbindung steht.

Andreas

Buebchen
21.04.2007, 14:03
Einen MySQL-Client wird's dann ja auch nicht haben.


Aber ein SDK für Java. Und das kann Datenbankzugriffe. Aber eben kein VPN.



Ohne MySQL-Client plus Headers und Libs läuft dann wieder kein Make durch. Oder es kommt ein neues Distributionsupdate mit einem neuen MySQL-Client raus der evtl. nicht zum Code passt und dann hängt wieder alles.
Je weniger Dependencies das Backend hat, umso besser.
Und ich würde Bosix 0.2 liebend gerne von einem USB-Stick anstelle einer CD booten und dafür würde ich die Linux-Distribution gerne so klein wie es irgend geht machen.

MySQL-Client = 5.6 MB. Libs and Headers = 7.3 MB Shared Libs = 1.6 MB
macht 14.5 MB
MyODBC = 2.5 MB


Die Grössen sind aber doch nicht nur die benötigten libraries. Das betrifft doch nur die build Umgebung. Die dll und shared-lib für mysql haben um die 1MB. ODBC weiss ich nicht.

Soll an dieser Stelle auch erstmal egal sein. Ich werde das in eine virtuelle Funktion packen. Das DB Backend wäre dann mal generell austauschbar. Vielleicht auch eine Klasse, die die Daten repräsentiert.



der nur eine TCP-Verbindung zum Backend herstellt

der per TCP mit dem Backend und dem SQL-Agenten in Verbindung steht

Der per TCP mit dem Backend und per MySQL-CLient mit der Datenbank in Verbindung steht.

Andreas

Das hätte mein Full-ACK.

Die Geschichte mit SQL-Agent fragt monitord nach Useranmeldung etc ist vom Gedanken her gut. Bin mir nur noch nicht so sicher, ob das dann im technischen Detail auch ohne Probleme klappt.

Werde mir mal die aktuellen ODBC Varianten bei Gelegenheit mal anschauen. Vielleicht tritt da ja noch ein Sinneswandel bei mir ein.

nepomuck
22.04.2007, 12:36
Die Grössen sind aber doch nicht nur die benötigten libraries. Das betrifft doch nur die build Umgebung. Die dll und shared-lib für mysql haben um die 1MB. ODBC weiss ich nicht.

Ok. Dannn sollte es gehen. Ich muss für den Remaster-Prozess alles installieren, den Make fahren und kann danach die Bulid-Umgebung und Headers wieder entfernen. Ich brauche dann nur eine Liste der shared libs, die bleiben müssen.

Andreas

jhr-online
22.04.2007, 12:42
Wenn ich noch mal was technisches reinwerfen darf:
Wie wäre es damit, wenn ich sich einer derjenigen, die auch wirklich verstehen, was hier geplant ist, mal dranmachen würde, das ganze etwas systematisch im Wiki aufzuarbeiten. Der Thread wird langsam unübersichtlich - die ersten beklagen sich :)
Da ich am Code nicht viel mitarbeiten kann, bin ich gerne bereit, mich weiter in dieses organisatorisch reinzuhängen, aber den ersten Schritt muss wirklich jemand machen, der das alles versteht... Die Vorschläge auseinanderhalten und das, was zusammen gehört, auch zusammen zu formulieren; Backend- von Frontend-Vorschlägen trennen etc.

Hat jemand Lust? Hier geht's los:
http://monitor.08k.de/index.php/Devel bzw. eigentlich erst
hier: http://monitor.08k.de/index.php/Devel/2.0

jhr

Nachtrag: Ich muss ja nicht alles selber machen und auf meinem PC horten... :) Tragt euch ein: http://monitor.08k.de/index.php/Devel/Team

Norad
22.04.2007, 14:35
Moin, ich mische mich hier auch mal ein :)
Mir scheint, dass die Komplexität hier gerade explodiert ;)

Ich würde mir das so vorstellen:
monitor-backend: nimmt Daten von der Soundkarte und stellt diese Dekodiert über TCP zur Verfügung. Kein Logging, keine Datenbank.

Frontends: z.B. Daten in eine Datenbank schreiben, Daten in ein Log schrieben usw.
Ein GUI- (oder Textkonsolen-) Frontend würde aktuelle Ereignisse direkt vom Monitor-Backend bekommen und könnte die Historie entweder direkt aus der Datenbank des DB-Frontends abrufen oder evtl. mit dem DB-Frontend kommunizieren. Für den Direktzugriff auf die DB müssen GUI- und DB-Frontend sich bloß auf eine Datenbankstruktur einigen, für die andere Variante müsste man ein Protokoll entwerfen ...

nepomuck
22.04.2007, 20:20
Für den Direktzugriff auf die DB müssen GUI- und DB-Frontend sich bloß auf eine Datenbankstruktur einigen

Das ist ein wunder Punkt. Ich habe mir gerade die Datenbankstruktur des aktuellen MySQL-Frontends angesehen. Die Tabellen werden wir so nicht beibehalten können. Bislang übernimmt ja der Monitor eine Reformatierung und Filterung der Events. Das ist künftig nicht mehr der Fall da das Backend die Rohdaten in die SQL-Datenbank schickt. Dazü genügt im Prinzip seine sehr einfache Datenbankstruktur.

Soll ich mir da mal was ausdenken, oder möchte das lieber einer der Frondend-Entwickler tun, der später später seine Anwendung an die DB andocken muss?

Andreas

MiThoTyN
23.04.2007, 12:30
Morsche zusammen!

Also bei der Diskussion eben zum Thema Datenbank ist mir auch bischen schwindelig geworden. Die Komplexität ist in der Tat explodiert. Da müssen wir nochmal ansetzen an der Ecke.

Also einig darüber, dass der monitor keine DB-Anbindung hat und auch keine Log's schreibt sind wir uns?

Es bleibt jetzt nur zu klären, wie eine Datenbank an den monitor angebunden wird und wie entsprechende GUI's dann auf die Datenbank zugreifen können.

Mein Vorschlag wäre folgender :

Variante 1 : Es ist keine DB installiert

Sämtliche Clients (GUI's bzw. Frontends) verbinden sich direkt an den monitor. Da der monitor keine Benutzerverwaltung hat, gibt es nur einen Standarduser zum Verbinden. monitor und Frontend unterhalten sich über das "normale" Monitor-Datenprotokoll. Nachteil ist, dass der Client nur die Live eingehenden Daten anzeigen kann, da es ja eben keine Datenbank gibt. Für eine SMS-Alarmierung oder ähnliches ist dieser Zustand aber durchaus in Ordnung, da hier eh keine History-Daten interessieren.

Variante 2 : Es gibt eine DB-Middleware

Eine entsprechende DB-Middleware hat sich per TCP an den monitor angedockt und bekommt von dort die Rohdaten, um diese in die Datenbank zu schreiben. Sämtliche Frontends verbinden sich nun mit dieser DB-Middleware direkt, die nach außen hin jetzt als Backend fungiert. Sich über einen zweiten Kanal nochmal mit dem monitor verbinden halte ich für sinnlos, da alle Daten vom monitor eh an die Datenbank geschickt werden. In der Datenbank sind jetzt verschiedene Benutzerkonten und Benutzerrechte konfigurierbar und die Frontends können per Sessionhandling überwacht und gesteuert werden. DB-Middleware und Frontends unterhalten sich jetzt auch über das Monitor-Protokoll, welches um Befehle für den Datenbankzugriff (History) erweitert wurde. So kann ein Frontend jetzt aus der Datenbank z.B. die letzten 100 Statis eines Fahrzeugs abfragen o.ä.

Prinzipiell bleibt egal bei welcher Methode zu klären, WAS genau die Datenbank speichert und was man Abfragen kann. Reicht es die Daten in einer Tabelle als Rohdaten abzulegen oder muss/soll/kann die DB-Schicht schon erste Auswertungen vornehmen und die Daten in unterschiedliche Tabellen speichern? (Letzter Status eines Fahrzeugs z.B.) Und welche Funktionen kann ein Frontend dann von der DB benutzen? Gibt es vorgefertigte Funktionen wie "HoleLetzteXXEinträge" oder gestalten wir das so flexibel, dass man SQL-Anfragen an die Datenbank schicken kann?

Gruß Joachim

PS.: Heut Abend kommt irgendwann ne erste Protokollversion.

MiThoTyN
24.04.2007, 00:01
Hier meine Vorlage zum Protokoll. Ich denke es ist soweit alles grundsätzliche drinne erstmal. Über die Befehlsliste müsst ihr mal drüber gucken. Fürn Anfang sind mir nicht mehr eingefallen. Wenn wir uns dann über einen Mindestsatz an Befehlen geeinigt haben, mach ich Punkt 6 ausführlich. Dann bekommt jeder Befehl ne eigene Beschreibung.

Soweit erstmal!

Gruß Joachim

Buebchen
24.04.2007, 23:05
Hi MiThoTyN,

ich habe mir das Protokoll seit mal angeschaut. Ist doch ein wenig anders als z.B. SMTP, da die erste Ziffer nicht "Info, Warnung, Fehler" signalisiert, sondern direkt spezifisch auf die genutzten Funktionen eingeht.

Wenn man (bzw. ich) das kapiert hat, dann versteh' ich das ganze soweit auch. Einiges ist auch für die Zukunft noch frei. Werde das - sobald ich an dem Punkt bin - also mal anfangen umzusetzen. Dabei ergeben sich zwangsläufig weitere Fragen. Aber die Struktur ist ja nun klar.

jhr-online
25.04.2007, 00:12
Du willst anfangen umzusetzen, also Code zu produzieren? Hälst du es nicht für besser, erst dafür zu sorgen, dass das Konzept allen willigen Entwicklern klar ist und dann ein wenig abzusprochen, wie entwickelt werden soll und wer was macht und so?

jhr

Buebchen
25.04.2007, 01:38
Du willst anfangen umzusetzen, also Code zu produzieren?

Hmmmmmmmm --- Ja !

Den Kern habe ich relativ schnell umgesetzt, da ich einiges an Vorarbeit geleistet habe. Alles andere ist ja erstmal nicht meine Baustelle.

Und bei den Frontends ist genug zu tun. Aber wie soll jemand ein Frontend entwickeln, wenn es kein Backend gibt ?

Das Backend wird sich ebenso weiterentwickeln. Es ist aber sicherlich einfacher, wenn ein mögliches Backend erstmal da ist, um es anzupassen und weiterzuentwickeln.



Hälst du es nicht für besser, erst dafür zu sorgen, dass das Konzept allen willigen Entwicklern klar ist und dann ein wenig abzusprochen, wie entwickelt werden soll und wer was macht und so?


Mir geht es auch nicht darum direkt mit allem fertig zu sein. Aber ich habe die Module für ZVEI/POC und FMS als C++ Klassen umgesetzt. Wenn das als Basis bereitsteht ist die Arbeit an Dingen wie der Datenhaltung und Client-Kommunikation erheblich einfacher.

Mein Beitrag ist im Grunde auch nur eine Fleissarbeit. Ich habe den monitor entwirrt und die Decoder als C++ Klassen gekapselt. Alles andere steht noch nicht fest und wird ja auch fast täglich neu diskutiert.

funkwart
25.04.2007, 08:25
wenn die Essenz des Ganzen, das Protokoll, steht und von allen Entwicklern abgesegnet ist, kann doch nicht mehr viel schiefgehen. Egal, ob das Back- oder die diversen Frontends noch geändert werden, solange sie sich an das Protokoll halten, sollten alle miteinander auskommen. Nur diese gemeinsame Sache sollteunbedingt festgemacht werden von allen Beteiligten.
Danke Dir Buebchen, dass Du schon so viel Vorarbeit geleistet hast - auch wenn es nach Deiner Aussage nur Fleißarbeit ist, gemacht werden muss sie ja.

Gruß,
Funkwart

jhr-online
25.04.2007, 10:28
Mir geht es auch nicht darum direkt mit allem fertig zu sein. Aber ich habe die Module für ZVEI/POC und FMS als C++ Klassen umgesetzt. Wenn das als Basis bereitsteht ist die Arbeit an Dingen wie der Datenhaltung und Client-Kommunikation erheblich einfacher.

Mein Beitrag ist im Grunde auch nur eine Fleissarbeit. Ich habe den monitor entwirrt und die Decoder als C++ Klassen gekapselt. Alles andere steht noch nicht fest und wird ja auch fast täglich neu diskutiert.Ich verstehe! Genau das festzuhalten (was du bereits gemacht hast und wie der Stand ist, an dem andere anknüpfen können), war mir sehr wichtig.

Ich halte dich also nicht davon ab, jeglichen Rummel ins svn hochzuladen :). Dann schauen wir mal, wer wo weiter macht. Wenn es etwas klarer wird und die anderen deinen Code kennen, lässt sich sicherlich ein Paln im Wiki aufstellen und vernünftige Bugs schreiben, die zugewiesen werden können.

Danke,
jhr

Dove
25.04.2007, 16:52
wenn das backend steht und ich es habe schieß los ^^

ne nu ma richtig.

es ist sher loblich das du buebchen dir die Arbeit gemacht hast, den monitor in einen dienst zu ändern und in c++ konvertiert hast.

Ich denke das umschifften und um modelieren ist schon mal eine gute idee um die zeit des "diskutierens" zu überbrücken in der dann das Kommunikationsprotokoll besprochen und entwickelt wird.

Und ich denke das wir irgendwann an einem Punkt stehen, wo wir mit "deinem" backend "unser" frontend entwickeln können. Und ich hoffe das ziemlich zeit nah :D

denn ich freue mich ehrlich gesagt schon den monitor auf einer grafischen Umgebung zu sehen !!!!!

Das Protokoll von MiThoTyN ist ein sehr guter ansatz. Sicherlich kommen dort noch neue Punkte hinzu. Aber der Anfang ist da und das ist gut. Thx MiThoTyN :D

so nu will ich mitm quacksalbern aufhören denn ich muss weiter arbeiten, dis die tage

nepomuck
25.04.2007, 18:55
Hier meine Vorlage zum Protokoll.
Danke für die Mühe und den Entwurf

Ich hätte da noch ein paar Punkte anzumerken:

Befehle 101,201 Error, Datenfelder 0
Ein Error ohne Beschreibung hilft in der Regel nicht weiter. Ich empfehle, dass wir dem Befehl ein Datenfeld mit einem Fehlercode anhängen und in der Protokolldefinition fehlercodes deklarieren, Beispiel:

101:001
Error:Server kann auf Sounddevice nicht zugreifen
101:034
Error:Benutzeranmeldung fehlgeschlagen
201:124
Error:Client unterstützt Protokollversion nicht

Dazu auch ein Vorschlag für ein weiteres Kommando:
111 Versionsnummer (Serverversion)
112 Protokollversion

Befehle 330,430 DTFM
Da sollten wir klären, ob wir diese Befehlsgruppe überhaupt brauchen. DTFM kommt sowieso nur in Verbindung mit einer ZVEI-Alarmierung vor, daher könnte man den DTFM-Code direkt mit der ZVEI-Alarmierung übertragen. Das hätte den Vorteil, dass der Client nach einem 5-Ton Alarm nicht eine gewisse Zeit warten muss, ob noch eine DTFM-Anweisung folgt oder nicht.



inklusive Trennzeichen und Zeilenende nicht länger als 512 Byte ist.

Da sollte bitte mal jemand, der sich mit FMS auskennt prüfen, wie lange Folgetelegramme sein dürfen. Da könnten 512 Byte evtl nicht reichen, vor allem, da wir die textmeldung hex codieren und daher pro character zwei Byte brauchen.

Andreas

Fernmeldedienst
30.04.2007, 11:57
Hallo!

Kann zwar leider nicht programmieren..

aber hätte da noch 2 Vorschläge...

das wäre zum einen die Einbindung des FMS-AuftragsText der Leitstelle

und zum anderen die Positionsmeldungen der einzelnen Fz an die Leitstelle via GPS (Stat 10)

73,

Daniel

Dove
02.05.2007, 22:53
ich möchte noch mal auf die datenbank anbindung ansprechen.
Wie wäre es wenn wir ein Modul schreiben das im monitord verankert ist das auf wunsch zu geschaltet werden kann.

Ich finde es einbischen umständlich wenn ich die daten in einer db speichern möchte, es über den deamon zu gehen das zu eines clienten zu schicken der das in eine Datenbank schreibt.

Buebchen
03.05.2007, 02:22
Fällt mir geradeso auf :Im TCP Protokoll fehlt noch ein Logout Kommando vom Client zum Server. Wäre im Bereich 2xx anzusiedeln. Ich würde 299 vorschlagen.

Wie soll ein Login eines Clients zum Server aussehen ? Erstmal im Klartext, richtig ? Also ungefähr so:

Server:
120:Please login !:

Client:
220:Harry:Hirsch:

Wobei "Harry" der User ist und "Hirsch" sein PW.

Danach käme dann

Server: 121:Login accepted:

oder

Server: 122:Login incorrect !:

Schließen wir die letzten Parameter mit ":" ab ? Ist in der PDF nicht ganz eindeutig. Aber sieht danach aus.

Dove
03.05.2007, 11:10
ich mit : am ende abschließen, damit man weiß, es ist wirklich zu ende.

Thema Login:
Ich würde das PW trotzdem irgendwie verschlüsselt rüberschicken. Sei es jetzt md5 oder base64 oder was auch immer.
Auch in der Probephase bzw Programmierphase

MiThoTyN
03.05.2007, 11:18
Hallo zusammen!

Habe momentan wenig Zeit, deswegen melde ich mich jetzt erst. Zu den ganzen Anmerkungen zum Protokoll:

@nepomuck

Die Sache mit dem Fehlercode ist gut. Das kann man als Datenfeld noch eintragen. Werd ich mal ins PDF aufnehmen.

111 als Version ist ja schon drinne. Eine Protokollversion ist auch sinnvoll. Den Befehl sehe ich auf beiden Seiten vor. Der Server teilt seine Protokollversionen mit und der Client bestimmt, welche genommen werden soll.

Ob DTMF drinne sein soll oder nicht hängt davon ab, ob der monitor ein reiner BOS-Auswerter sein soll, oder sich wie bisher durch die Module auch erweitern lassen soll. Dann kannste DTMF auch eigenständig laufen lassen. Der Sirenendoppelton wird beim ZVEI mit ausgegeben.

FMS-Text besteht aus maximal 99 Zeichen. Sagen wir 100 Byte. Als Hex 200 Byte. Bleiben 312 für den Rest. Langt dicke. POCSAG hat keine definitive Längenvorgabe, sollte aber auch dicke mit 512 Byte auskommen. Aber zur Not nehmen wir einfach 1024 Byte. Sollte halt Problemlos in den Zeilenpuffer des Frontend-Auswerters passen.

@Buebchen

Abschließender Doppelpunkt wird nicht benötigt. Die Zeile wird ja mit CR/LF abgeschlossen. Der Doppelpunkt trennt nur aufeinanderfolgende Datenfelder.

Solche Klartextübertragungen wie "Please login" sind eigentlich nicht nötig. Oder was meinst du? Ein Login sähe nach meiner Meinung z.B. so aus :

120
220:Harry:Hirsch
122

Passwort kann auch gerne verschlüsselt werden. Da die Passwörter auf beiden Seiten ja bekannt sind, kann man hier ne Einweg-Verschlüsselung nehmen und die beiden dann einfach miteinander vergleichen. Müssen wir nur jetzt im Vorfeld festlegen und uns auch auf eine Verschlüsselung einigen, die in vielen Programmiersprachen vorhanden ist. Oder wir lassen über einen zweiten Befehl auch das Anmelden im Klartext zu.

Logout Kommando wird auch noch eingefügt. Auch auf beiden Seiten. So kann auch der Server die Verbindung zum Client beenden.

Gruß Joachim

nepomuck
03.05.2007, 13:01
Die Sache mit dem Fehlercode ist gut. Das kann man als Datenfeld noch eintragen.

Mir fallen dazu spontan folgende Fehler ein:
Vom Server: Problem mit Soundkarte; Fehler in Konfig-Datei; Softwarefehler (kann Module nicht laden etc..); User ungültig; Passwort falsch; No anonymous Login(siehe unten); Netzwerkfehler; Server voll (evtl. Login-Limit)

Ping/Pong:
Ich würde einen Ping von beiden Seiten einrichten, so dass sowohl der Server als auch der Client die Verbindung überprüfen können. Dem Pong-Befehl sollte zudem als Datenfeld Datum und Uhrzeit der jeweiligen Maschine anhängen, dann können sich Client und Server synchronisieren.


Der Sirenendoppelton wird beim ZVEI mit ausgegeben.

Bei einer Sirenenalarmierung gäbe es also eine doppelte Ausgabe?
300:26250:1
330:1
Macht as Sinn?



Ein Login sähe nach meiner Meinung z.B. so aus :
120
220:Harry:Hirsch
122

Jagen wir da den Benutzernamen als ASCII durch? Oder bleiben wir dabei, dass wir Konsequent alle Textübertragungen Hex-Codieren?



Da die Passwörter auf beiden Seiten ja bekannt sind, kann man hier ne Einweg-Verschlüsselung nehmen

Das sollte genügen. Es müßte ja passende crypt-Funktionen geben, die als Output ein Hex-kodierten Code liefern.
Ich würde zudem vorschlagen, dass der Monitor-Daemon je nach Konfiguration auch anonyme Logins ohne PW zulassen kann.



Oder wir lassen über einen zweiten Befehl auch das Anmelden im Klartext zu.

Würde ich nicht. Entweder gleich anonym (für Server die ohnehin nur im Intranet laufen) oder mir sauber verschlüsseltem Hash. Da könnte man über die Konfigurationsdatei regeln, wer sich wie anmelden darf. Es könnte eine "Trusted-Hosts"-Liste geben mit IP-Adressen die anonym reinkommen während maschinen von außen sich anmelden müssen.

Andreas

MiThoTyN
03.05.2007, 15:35
Ping/Pong:
Ich würde einen Ping von beiden Seiten einrichten, so dass sowohl der Server als auch der Client die Verbindung überprüfen können. Dem Pong-Befehl sollte zudem als Datenfeld Datum und Uhrzeit der jeweiligen Maschine anhängen, dann können sich Client und Server synchronisieren.

Brauch man eigentlich nicht. Der Client prüft in regelmäßigen Zeitabständen die Verbindung. Das Ergebnis ist ja auch Aussagekräftig für den Server. Da muss der nicht auch noch den Client anpingen.

Die Uhrzeit zum synchronisieren würde ich damit nicht übertragen. Die Zeiten der Auswertungen werden bei der Datenübertragung selbst mitgesendet. Und Client und Server müssen ihre Zeit nicht über den monitor synchronisieren. Dazu gibt es bessere Wege und sollte auch standard sein mittlerweile.




Bei einer Sirenenalarmierung gäbe es also eine doppelte Ausgabe?
300:26250:1
330:1
Macht as Sinn?


Ja wie willst du das sonst machen? Der Sirenenton ist ein gültiger DTMF-Ton. Wenn also jemand das DTMF-Modul aktiviert hat, wird er so eine doppelte Anzeige bekommen. Was er damit im Endeffekt macht bleibt ja ihm überlassen. Richtig wäre es so auf jeden Fall.



Jagen wir da den Benutzernamen als ASCII durch? Oder bleiben wir dabei, dass wir Konsequent alle Textübertragungen Hex-Codieren?

Alles HEX-Codieren. Da sollte man in der Tat konsequent sein. Sonderzeichen kann es ja auch im Usernamen geben.


Würde ich nicht. Entweder gleich anonym (für Server die ohnehin nur im Intranet laufen) oder mir sauber verschlüsseltem Hash. Da könnte man über die Konfigurationsdatei regeln, wer sich wie anmelden darf. Es könnte eine "Trusted-Hosts"-Liste geben mit IP-Adressen die anonym reinkommen während maschinen von außen sich anmelden müssen.

Wäre ne Möglichkeit. Da der reine monitor-Server eh nur EIN Login hat und eine Benutzerverwaltung erst in der Datenbank geschieht. Es macht also Sinn zusätzlich zu dem einen Login auch eine Trusted-Host Liste anzulegen.

Gruß Joachim

Buebchen
07.05.2007, 01:47
Ich hätte da jetzt nochmal ne Frage zum TCP Protokoll. Ist es jetzt entschieden, wie z.B. eine FMS Zeile (CMD=310) aussieht? - Ich meine, welche Parameter in welcher Reihenfolge auftauchen sollen ?

Die Frage zielt dahin ab, daß ich den Socket-Server in einem ersten Stadium fertig habe. Jetzt würde ich gerne die interne Verbindung Auswerter -> Client-Socket testen. Da kann ich zwar auch jeden beliebigen Text ausgeben, aber da könnte ich dann auch direkt einen syntaktisch korrekten String generieren. Wäre sicherlich für alle Entwicker interessant, damit die auch starten können.

Nächste Frage, ob es schon Ideen / Vorschläge für den default TCP-Port gibt. Wie bei vielen anderen auch einen Port um die 9000 ? Ich nutze zum Testen 9400.

nepomuck
07.05.2007, 20:02
Ja wie willst du das sonst machen? Der Sirenenton ist ein gültiger DTMF-Ton. Wenn also jemand das DTMF-Modul aktiviert hat, wird er so eine doppelte Anzeige bekommen.

Soweit ich weiß, kommt DTFM sowieso NUR in Verbindung mit einer ZVEI-Alarmierung zum Einsatz. Also braucht es meines Erachtens kein eigenes DTFM-Modul, es genügt die DTFM-Erkennung als Teil des ZVEI-Moduls laufen zu lassen.


Nächste Frage, ob es schon Ideen / Vorschläge für den default TCP-Port gibt. Wie bei vielen anderen auch einen Port um die 9000 ? Ich nutze zum Testen 9400.
Es gibt da eine Liste im Internet unter
http://meineipadresse.de/html/ip-ports.php
oder auf anderen Seiten.

Da steht, dass 9400 von Samsung für Netzwerkscanner verwendet wird. Das sollte kaum zu Problemen führen.
Um allen Eventualitäten aus dem Weg zu gehen, kannst du einen der aufgelisteten Ports verwenden, der laut Liste nicht benutzt wird.
9322-9342 Unassigned
9347-9373 Unassigned
9375-9395 Unassigned
9398-9399 Unassigned
9402-9417 Unassigned

wie wär's mit 9333? Kann man sich leicht merken.

Andreas

MiThoTyN
09.05.2007, 17:34
Soweit ich weiß, kommt DTFM sowieso NUR in Verbindung mit einer ZVEI-Alarmierung zum Einsatz. Also braucht es meines Erachtens kein eigenes DTFM-Modul, es genügt die DTFM-Erkennung als Teil des ZVEI-Moduls laufen zu lassen.

Ja aber auch nur DANN, wenn der monitor ein reiner BOS-Auswerter werden soll. DANN kannste dir DTMF und andere Rufverfahren sparen. Soll der monitor weiterhin universell sein, müssen auch weitere Verfahren im Protokoll berücksichtigt werden. Das ist die entscheidende Frage.


wie wär's mit 9333? Kann man sich leicht merken.

Klingt gut.

Ich werd am Wochenende mal die Schnittstellenbeschreibung verfeinern. Dass wir da die genaue Syntax pro Zeile definiert haben.

Gruß Joachim

nepomuck
23.05.2007, 00:52
Hallo Monitor-Freunde,

In diesem Thread herrscht gerade gespenstische Stille. Ich hoffe nicht, dass die Bemühungen um die modularisierte Version 2.x zwischenzeitlich eingeschlafen sind.

@MiThoTyN
Wie ist der aktuelle Status des Backend-Protokolls? Davon hängt im Moment eigentlich alles ab.

@Buebchen
Wie sieht's mit dem Code-Redesign und dem Backend aus?

Andreas

Buebchen
23.05.2007, 17:59
Wie Du schon sagst: Ohne Protokolldefinition komme ich erstmal nicht so recht weiter. Zumindest will ich nicht in einem Luftgebilde testen. Lieber mit nem "echten" Client.

Aber ich denke, Joachim hat im Moment genug zu tun. Sonst hätte er das Protokoll bestimmt schon fertig.

[Edit]
Die Einteilung in einzelne Komponenten ist als Basis vorhanden. Im Moment habe ich FMS als Test sowohl unter Windows, als auch unter Linux laufen. Auch der Socketserver für die TCP Sockets ist als erste Version lauffähig. Wenn das Komm-Protokoll steht kann ich den Socketserver fertig machen. Danach wollte ich die anderen Module angehen. Das KommProtokoll hat Einfluss auf die Struktur der Daten, die die Module an die TCP Sockets weitergeben. Deswegen wollte ich das erst nach dem Protokoll weiterschreiben.

Schewal
29.05.2007, 14:56
Ich griegs unter Ubuntu einfach nicht zum laufen, ich verzweifel hier noch...

nepomuck
29.05.2007, 16:40
Ich griegs unter Ubuntu einfach nicht zum laufen, ich verzweifel hier noch...
Mit dem Problem bist du hier im falschen Thread. Die Lösung zum Ubuntu-Problem gibt's hier:

http://www.funkmeldesystem.de/foren/showpost.php?p=236094&postcount=12

Weitere Nachfragen bitte in diesem Thread.

Andreas

Buebchen
31.05.2007, 01:19
@MiThoTyN:

wie siehst mit dem Protokoll aus. Ich könnte neben der HEX Kodierung auch base64 anbieten. Würde bei FMS Text ein paar Bytes sparen.

@alle:
Welche Information gehören denn sinnvollerweise nun in ein FMS Datenpaket rein ?

310 : [Uhrzeit in Sekunden seit 01.01.1970] : [Servername] : [Kanalbezeichnung] : [FMSKennung] : [Status] : [Baustufe] : [Richtung] : [TKI] : [ggf: FMSText]

was habe ich denn jetzt eigentlich vergessen ?

kfire
04.06.2007, 14:15
Der Protokoll-Vorschlag sieht doch gut aus. Mehr Informatonen hat das Backend nicht, die weitere Verarbeitung geschieht im Frontend.

Ich finde mich nicht wirklich zurecht: Gibt es schon ein Backend zum testen ?

Ich hätte eher Interesse an der Pocsag-Auswertung..

Weiter so,
kfire

Buebchen
04.06.2007, 14:37
Generell findet man die tagesaktuelle Version im CVS / SVN. Natürlich nur was für die mutigen :-)

Wobei die Pocsag und ZVEI Anbindung noch nicht im TCP SocketServer drin ist. Ausserdem fehlt halt noch die Formatierung der Ausgabe. Ggf. werde ich da einfach nach persönlichem Empfinden eine Vorgabe machen. Muss man später vielleicht nochmal anpassen.

Die Module für ZVEI / POC512 und FMS sind in Bearbeitung (Entwickelt unter Ubuntu 6.06 LTS).

jhr-online
04.06.2007, 18:57
Ich schreib's mal hier, da es ja für alle interessant ist, die mitwirken möchten, aber im Moment hätte wohl eine PN an buebchen auch gereicht ;)
Mir wär's ganz lieb, wenn ihr beim Übertragen ins svn-Repo einen Kommentar fürs Log mitschicken könntet. Im Moment ist das ziemlich schnuppe, dass da nix steht, aber wenn du, buebchen, langsam das Gefühl bekommst, dass sich mal jemand anders einmischen kann, dann sollten wir (oder besser: solltest du) anfangen, Logeinträge mitzuschicken. Das macht es nachher erheblich einfacher, zu überblicken, was passiert...

So, vielen Dank für Ihre Aufmerksamkeit und viel Spaß noch bei der Arbeit ^^

jhr

Buebchen
04.06.2007, 19:28
Finden denn eigentlich schon checkout statt ? Ich fange dann vorsichtshalber mal an, ins Log zu schreiben.

Strukturbeschreibung starte ich aber wohl erst, wenn alle Module dem Grunde nach laufen. Doxygen-File ist schon erstellt - Fehlen halt noch die Kommentare dafür :-)

Medic
21.06.2007, 15:23
Hallo NG,

Ich beteilige mich jetzt auch mal. Bin gerade dabei nen Java-basierten Converter für FMS32-Pro und den Crusader zu schreiben und wollte fragen ob ich das hier gepostete KommProtokoll so nutzen kann oder gibts hier schon eine neue Fassung wo man besser sieht wie der Datenstrom aussieht?

Gruß

Medic

Buebchen
21.06.2007, 23:57
Im Moment wird dir das KommProtokoll in der vorliegenden Version (PDF) vermutlich nicht so sehr helfen, da nur die Kommandos definiert sind. Nicht aber die Parameter.

Die vorläufige Version (die aber noch nicht weiter abgestimmt ist und somit nur "mal so" von mir festgelegt wurde) sieht im Moment so aus:

Für FMS Telegramme:

310:[Uhrzeit]:[H:servername]:[H:kanalbezeichnung]:[fahrzeugkennung]:[status]:[baustufe]:[richtung]:[tki]

Für ZVEI:
300:[Uhrzeit]:[H:servername]:[H:kanalbezeichnung]:[ZVEI-Folge]:[Typ]:[H:Text]

Für POC:
320:[Uhrzeit]:[H:servername]:[H:kanalbezeichnung]:[RIC]:[Sub]:[H:Text]

Wobei die Uhrzeit immer ein Unix timestamp ist, also die Sekunden seit 1970.
Einträge mit H: sind in Strings, die in als Hexadezimalzahlen übertragen werden.

test wäre also 74657374 bei einer solchen Übertragung. Die eckigen Klammer deuten nur an, daß es Platzhalter sind. Sie sind nicht Teil des Protokolls.

Ein vollständiger Dialog (mit einer Anmeldung als User "test" mit den Passwort "test") sieht so aus:

(Servername=monitord, Kanal=channel01)

1. Habe nen POCSAG Text mit 512 Baud gesendet, RIC=1298921, Text="Guten Tag"
2. ZVEI Sirenenalarm auf 42257
3. FMS "Sprechwunsch" (5) und "Sprechaufforderung" (J) , FMS=D4010461



110:monitord 2.0.0 READY
120:74657374:74657374
101:Login ok
320:1182459144:6d6f6e69746f7264:6368616e6e656c3031 :1298921:2:4737574656E20546167202E2E2EC454F543E
300:1182459171:6d6f6e69746f7264:6368616e6e656c3031 :42257:0:756E6B6C617265204175736CEFBFBD73756E67
300:1182459172:6d6f6e69746f7264:6368616e6e656c3031 :42257:2:536972656E656E6175736CEFBFBD73756E67
310:1182459194:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:5:1:0:0
310:1182459194:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:f:1:1:0
310:1182459195:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:5:1:0:0
310:1182459195:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:f:1:1:0
310:1182459200:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:6:1:1:0
310:1182459200:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:e:1:0:0
310:1182459200:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:6:1:1:0
310:1182459201:6d6f6e69746f7264:6368616e6e656c3031 :D4010461:e:1:0:0

PolyMorPhisMus
23.06.2007, 16:26
So zwei Sachen habe ich schon mal:
1. Ich würde vorschlagen statt #include "iostream.h" #include <iostream> vorschlagen, da die alten Libs als deprecated/antiquated deklaiert ist.

2. Welche XML Lib hast du in der Config Klasse? Ich bekomme das bei mir nicht compiliert...

MonitorConfiguration.h:41: error: ‘XMLNode’ does not name a type
MonitorConfiguration.h:67: error: ‘XMLNode’ has not been declared
MonitorConfiguration.h:68: error: ‘XMLNode’ has not been declared
MonitorConfiguration.h:69: error: ‘XMLNode’ has not been declared
MonitorConfiguration.h:71: error: ‘XMLNode’ has not been declared
MonitorConfiguration.h:72: error: ‘XMLNode’ has not been declared
MonitorConfiguration.h:75: error: ‘XMLNode’ has not been declared
MonitorConfiguration.cpp:75: error: ‘std::string MonitorConfiguration::getNodeText’ is not a static member of ‘class MonitorConfiguration’
MonitorConfiguration.cpp:75: error: ‘XMLNode’ was not declared in this scope
MonitorConfiguration.cpp:75: error: expected primary-expression before ‘childName’
MonitorConfiguration.cpp:75: error: expected primary-expression before ‘defaultValue’
MonitorConfiguration.cpp:76: error: expected ‘,’ or ‘;’ before ‘{’ token
MonitorConfiguration.cpp:88: error: ‘int MonitorConfiguration::getNodeInt’ is not a static member of ‘class MonitorConfiguration’
MonitorConfiguration.cpp:88: error: ‘XMLNode’ was not declared in this scope
MonitorConfiguration.cpp:88: error: expected primary-expression before ‘childName’
MonitorConfiguration.cpp:88: error: expected primary-expression before ‘int’
MonitorConfiguration.cpp:88: error: initializer expression list treated as compound expression
MonitorConfiguration.cpp:89: error: expected ‘,’ or ‘;’ before ‘{’ token
MonitorConfiguration.cpp:104: error: ‘std::string MonitorConfiguration::ReadChannel’ is not a static member of ‘class MonitorConfiguration’
MonitorConfiguration.cpp:104: error: ‘XMLNode’ was not declared in this scope
MonitorConfiguration.cpp:104: error: expected primary-expression before ‘int’
MonitorConfiguration.cpp:104: error: expected primary-expression before ‘int’
MonitorConfiguration.cpp:105: error: expected ‘,’ or ‘;’ before ‘{’ token
MonitorConfiguration.cpp:139: error: variable or field ‘ReadSoundCard’ declared void
MonitorConfiguration.cpp:139: error: ‘int MonitorConfiguration::ReadSoundCard’ is not a static member of ‘class MonitorConfiguration’
MonitorConfiguration.cpp:139: error: ‘XMLNode’ was not declared in this scope
MonitorConfiguration.cpp:139: error: expected primary-expression before ‘int’
MonitorConfiguration.cpp:139: error: initializer expression list treated as compound expression
MonitorConfiguration.cpp:140: error: expected ‘,’ or ‘;’ before ‘{’ token
MonitorConfiguration.cpp:169: error: variable or field ‘ReadAuthenticationData’ declared void
MonitorConfiguration.cpp:169: error: ‘int MonitorConfiguration::ReadAuthenticationData’ is not a static member of ‘class MonitorConfiguration’
MonitorConfiguration.cpp:169: error: ‘XMLNode’ was not declared in this scope
MonitorConfiguration.cpp:170: error: expected ‘,’ or ‘;’ before ‘{’ token
MonitorConfiguration.cpp:221: error: variable or field ‘ReadTCPConfiguration’ declared void
MonitorConfiguration.cpp:221: error: ‘int MonitorConfiguration::ReadTCPConfiguration’ is not a static member of ‘class MonitorConfiguration’
MonitorConfiguration.cpp:221: error: ‘XMLNode’ was not declared in this scope
MonitorConfiguration.cpp:222: error: expected ‘,’ or ‘;’ before ‘{’ token
MonitorConfiguration.cpp: In member function ‘bool MonitorConfiguration::ReadConfiguration(std::strin g)’:
MonitorConfiguration.cpp:242: error: ‘XMLNode’ was not declared in this scope
MonitorConfiguration.cpp:242: error: expected `;' before ‘xNode’
MonitorConfiguration.cpp:243: error: expected `;' before ‘config’
MonitorConfiguration.cpp:246: error: ‘config’ was not declared in this scope
MonitorConfiguration.cpp:248: error: expected `;' before ‘tcpNode’
MonitorConfiguration.cpp:250: error: ‘tcpNode’ was not declared in this scope
MonitorConfiguration.cpp:257: error: expected `;' before ‘authNode’
MonitorConfiguration.cpp:259: error: ‘authNode’ was not declared in this scope
MonitorConfiguration.cpp:268: error: expected `;' before ‘sndNode’
MonitorConfiguration.cpp:271: error: ‘sndNode’ was not declared in this scope
make[1]: *** [MonitorConfiguration.o] Error 1

Buebchen
23.06.2007, 17:08
Aus Tradition include ich das iostream noch gerne "falsch" :-)

Mal abgesehen davon, daß z.B. mein gcc 4.0.3 nur "iostream" nicht findet. muss mal den include prüfen.

Ansonsten habe ich das Makefile aktualisiert. Der Build sollte nun auch mit den "Haupt"-Makefile laufen. Habe vorläufig ein -Wno-deprecated eingebaut.

SVN ist aktualisiert.

[EDIT]
Kurzer Info zum Stand:
* Die Module für FMS,ZVEI und Pocsag512 sind in der ersten Version umgesetzt. Pocsag1200 Baud fehlt noch.
* ALL: Der Socketserver läuft nun auch.
* ALL: Vorläufg erstmal nur eine Soundkarte
* LINUX: Noch kein forken in einen daemon Modus
* Win32: Installation als Dienst möglich
* Win32: Konfig muss auf c:\test-config.xml liegen
* LINUX: Die Konfiguration kommt zur Zeit aus einer xml Datei: test-config.xml. Das ist noch fest im Code so hinterlegt. Alle Optionen (und einige, die noch nicht genutzt werden) sind da schon drin.

Buebchen
23.06.2007, 21:14
Noch ne Änderung am Makefile gemacht (monitord doch glatt als Target für "all" vergessen).
Ausserdem kann man den monitord nun mit dem Parameter -c [config-file] aufrufen.
configfile meint ein XML File, wie z.B. das monitord.xml im SVN.

Dove
24.06.2007, 21:28
huhu, wollte grade den monitor kompilieren nur sagt er mir das ../xmlParser/xmlParser.o nicht gefunden wurde, was auch stimmt, nur wie erstelle ich diese Datei ?

in der Makefile von xmlParser gibs kein Target dafür.

Buebchen
25.06.2007, 00:27
Das sollte durch das Makefile vom monitord gebaut werden.

Das Projekt xmlParser selbst baut kein xmlParser.o. Zur Übersicht will ich aber die Ordner erstmal erhalten.

Da ich die xmlParser.o schon mal von Hand gebaut hatte fällts bei mir natürlich nicht auf.

Einfachste Lösung im Makefile ist es, ../xmlParser/xmlParser.o aus LIBS nach Progs zu verschieben. Dann baut er es selbst mit.

Werde das Makefile gleich nochmal ändern.

Dove
25.06.2007, 09:16
thx habs an PROGS dran gehangen nu gehts.

PolyMorPhisMus
25.06.2007, 16:49
Das ist echt ein tolles Projekt, ich bin begeistert! Weiter so!

FMS und ZVEI dekodiert er bei mir ohne Probleme, nur POCSAG 512 geht irgendwie nicht...

Da ist immer noch ein kleiner Syntax-Fehler:
base64.cpp: In function »std::string base64_encode(const std::string&)«:
base64.cpp:60: Fehler: expected unqualified-id before »;« token
> unsigned int in_len = in_string.length() ,;

Buebchen
25.06.2007, 23:49
Danke im Namen des Teams.

Den Fehler im base64 kannst Du leicht beheben. Das Komma vor dem Semikolon gehört da nicht hin. Loeschen. Danach sollte es sich kompilieren.

Die POC512 Auswertung habe ich bisher nur mit dem BOS-Tool getestet. Aber wenn er so garnichts auswertet finde ich das schon seltsam. Du könntest als Test mal den Kanal fest im Scanner auswählen. Bleibt der Scanner recht spät auf dem POCSAG Signal stehen und die Sync kommt nicht mehr mit. Einige Werte werden noch nicht als dem XML ausgelesen.

Andere Frage, wäre was in Deiner monitord.xml drin steht. Ich werte bei mir nur den linken Kanal aus. Ggf hast Du POCSAG auf dem rechten Kanal ?

Wobei POCSAG auch gerne mal ein paar Fehlauswertung noch einer korrekten ausgibt. Das muss ich mich auch nochmal angucken.

Medic
26.06.2007, 12:20
Was steht eigentlich in der Kanalbezeichnung drin?
Ist das Links oder Rechts für den Audiokanal wo es rein kam oder wie muß ich mir das vorstellen?

funkwart
26.06.2007, 12:28
[...]
Ist das Links oder Rechts für den Audiokanal wo es rein kam[...]?
Exakt!

Gruß,
Funkwart

Buebchen
26.06.2007, 13:20
Du kannst auch statt "Links" und "Rechts" auch z.B. keine Kanalnummer oder einen Namen "Leistelle BlaBlaBla" nehmen.

Sofern du diesen Teil hier meinst: (Spitze Klammern durch eckige ersetzt). Ich habe hier Kanal1 und Kanal2 drin.

monitord.xml:


Kanal 1<



Kanal 2


... bin mir aber gerade nicht sicher, ob ich das überhaupt schon mit ausgeben :-)

Medic
26.06.2007, 14:17
Ok, dann sollte ich die funktion für die Nutzung doch drin lassen. Hatte sie nämlich gerade auskommentiert ;)

Wie sieht eigentlich die Übertragung von FMS-Text aus im neuen Kommprotokoll aus?

Buebchen
26.06.2007, 16:54
Ok, dann sollte ich die funktion für die Nutzung doch drin lassen. Hatte sie nämlich gerade auskommentiert ;)

Wie sieht eigentlich die Übertragung von FMS-Text aus im neuen Kommprotokoll aus?

Keine Ahnung. Die Funktion exisitiert noch nicht :-)

Aber ich denke, ich hänge das an den FMS-Eintrag einfach hinten dran. Wenn der Status 10 (A) ist folgt halt noch der Text in Hex kodiert.

Ich weiss jetzt gerade nicht, was Du da auskommentieren wolltest ? Den Eintrag in der Konfig Datei ?

Buebchen
26.06.2007, 17:08
... bin mir aber gerade nicht sicher, ob ich das überhaupt schon mit ausgeben :-)

jetzt schon. SVN geupdated (Nur unter Win32 getestet. Sollte unter linux aber genauso compilieren).

Medic
26.06.2007, 17:14
Ich hatte die Funktion die die Kanalbezeichnung auswertet in meinem Converter auskommentiert. Ist jetzt aber wieder drin. Damit wird auch auf dem Crusader Client dann richtig angezeigt von welchem Kanal die Daten stammen.

Zur Info: Der Converter convertiert bereits FMS- und ZVEI-Telegramme korrekt in das Crusaderformat und der Client akzeptiert auch die Daten vom Converter.

Gruß

Medic

PolyMorPhisMus
26.06.2007, 21:00
Andere Frage, wäre was in Deiner monitord.xml drin steht. Ich werte bei mir nur den linken Kanal aus. Ggf hast Du POCSAG auf dem rechten Kanal ?

Wobei POCSAG auch gerne mal ein paar Fehlauswertung noch einer korrekten ausgibt. Das muss ich mich auch nochmal angucken.

{soundcard num=0}
{status}1{/status} {!-- 1=aktiv, 0=deaktivert --}
{baud}22050{/baud}
{name} Erste Sondkarte {/name}
{!-- Linker Kanal --}
{channel part="left"}
{name}Kanal 1{/name}
{module type="fms"}
{vorlaufbits} 8 {/vorlaufbits}
{crc-check} 1 {/crc-check}
{/module}
{module type="poc512"}
{crc-check} 1 {/crc-check}
{ecc} 0 {/ecc}
{/module}
{/channel}

{!-- Rechter Kanal --}
{channel part="right"}
{name}Kanal 2{/name}
{module type="zvei"}
{/module}
{/channel}
{/soundcard}

{soundcard num=1}
{device}/dev/dsp1{/device}
{status}0{/status} {!-- 1=aktiv, 0=deaktivert --}
{baud}22050{/baud}
{name} Zweite Sondkarte {/name}
{!-- Linker Kanal --}
{channel part="left"}
{name}Kanal 1{/name}
{module type="fms"}
{vorlaufbits} 8 {/vorlaufbits}
{crc-check} 1 {/crc-check}
{/module}
{module type="poc512"}
{crc-check} 1 {/crc-check}
{ecc} 0 {/ecc}
{/module}
{module type="zvei"}
{/module}
{/channel}

{!-- Rechter Kanal --}
{channel part="right"}
{/channel}
{/soundcard}

Ich habe es auf beiden Kanälen ausprobiert, werde mir nachern nochmal den Code reinziehen...

EDIT1:
Achso, bei meckert der Compiler auch noch ntserv.cpp:1729 an, da fehlt noch ein int, da das noch nicht deklariert wurde (ausser in der for Schleife davor, wa ja nach C++ Standard nicht zählt)

EDIT2:
Könnte es wohl daran liegen, das demod_mg noch nicht wirklich implementiert ist?
void MonitorModulePocsag::demod(float *buffer, int length)
{
switch (m_iAlgorithmus)
{
case 0:
demod_mg(buffer, length) ; // war demod_se ...
break ;
case 1:
default:
demod_mg(buffer, length) ;
} ;
}

void MonitorModulePocsag::demod_mg(float *buffer, int length)
{

}

EDIT3:
Wäre es nicht besser Threads als neue Prozesse und Linux zu nehmen?
Möglich währe der Einsatz der Posix libpthread die auch unter Windows funktionieren sollte...

Buebchen
26.06.2007, 23:10
EDIT1:
Achso, bei meckert der Compiler auch noch ntserv.cpp:1729 an, da fehlt noch ein int, da das noch nicht deklariert wurde (ausser in der for Schleife davor, wa ja nach C++ Standard nicht zählt)


Seltsam. Das ist dem Compiler von VC 7.1 egal und er findet's ok. Ich glaube VC 6.0 hatte damals sogar sonst nen Fehler gemeldet. Wobei das schon stimmt. Die Initialisierung gilt eigentlich nur innerhalb der for-Schleife. Werde das SVN beim nächsten mal dahingehend updaten.

Welchen Kompiler nutzt du ?



EDIT2:
Könnte es wohl daran liegen, das demod_mg noch nicht wirklich implementiert ist?
void MonitorModulePocsag::demod(float *buffer, int length)
{
switch (m_iAlgorithmus)
{
case 0:
demod_mg(buffer, length) ; // war demod_se ...
break ;
case 1:
default:
demod_mg(buffer, length) ;
} ;
}

void c::demod_mg(float *buffer, int length)
{

}


Hmm.Die demod_se() Funktion war mal so ein Test. Hatte aber nicht so richtig geklappt (bisher). Deshalb erstmal fest die demog_mg().

Die Funktion ist für POC512 in MonitorModulePocsag512.cpp definiert. die demod_-Funktion sind als virtual definiert. Ggf. ein Problem, wenn im std::vector Zeiger auf die Basisklasse definiert sind, daß zur Laufzeit dann der Klassentyp nicht korrekt erkannt wird ? Dann genau würde er nämlich die leere demod_ Funktionen aufrufen.



class MonitorModule ;

typedef std::vector<MonitorModule*> MonitorModuleArray ;


Die Auswerter sind aber abgeleitete Klassen. Aber eigentlich sollte das gehen...



EDIT3:
Wäre es nicht besser Threads als neue Prozesse und Linux zu nehmen?
Möglich währe der Einsatz der Posix libpthread die auch unter Windows funktionieren sollte...

Eigentlich hätte ich jetzt gedacht, daß ich statt Prozesse Threads bildet. Unter linux habe ich noch nicht nachgeschaut. Aber unter Windows wird CreateThread aufgerufen. aber ein pthread_t als Datentyp für linux würde doch auf die pthreads hinweisen, oder ?

MacLeod
27.06.2007, 19:43
...Der Converter convertiert bereits FMS- und ZVEI-Telegramme korrekt in das Crusaderformat und der Client akzeptiert auch die Daten vom Converter....

heist das, monitor kann jetzt als server für den crusader laufen?
ist das jetzt im svn-repository schon enthalten? oder läuft der converter extra...

das wäre ja ultra-klasse

cu
MacLeod

Buebchen
27.06.2007, 19:46
Grundsätzlich finde ich die Idee nicht schlecht.

Warum nicht einfach die Socket Klasse um einen Tarnkappenmodus erweitern. Dann könnten die Meldungen tätsachlich direkt von da aus im passenden Format ausgegeben werden. Dürfe ja nicht allzukomplex sein.

Medic
28.06.2007, 09:51
Ja der Monitor kann das als Backend für den FMS-Crusader und FMS32-Pro dienen.
Also zur Zeit entwickel ich den Convert unabhängig vom monitor. Ich schreibe in Java weil ich ihn C nicht so wirklich fit bin, aber ich kann natürlich meine bisherige Arbeit zur Verfügung stellen wenn das gewünscht wird. Ich fänd es cool wenn das Backend von sich aus schon Crusader und FMS32 sprechen würde, dann bräuchte man kein extra Programm zur Convertierung.

Ich habe gestern von Herrn Jahn die Schnittstellenbeschreibung für FMS32-Pro bekommen so das ich mich jetzt daran machen werde dem Converter auch FMS32-Pro bei zu bringen.

Update:

Der Converter spricht jetzt auch FMS32-Pro.

Allerdings bisher nur "normales" FMS und ZVEI. POCSAG werde ich heute oder morgen integrieren und ja FMS-Text liefert das Backend ja noch nicht.

2. Update:

POCSAG wurde sowohl für FMS32-Pro als auch für den Crusader inplementiert. Sprich der Converter wandelt jetzt den puren Datenstrom um.
Was noch fehlt wären Steuerbefehle vom Client zum Server und das Login aber ich würde damit gerne warten bis wir uns geeinigt haben ob wie die Converterfunktion in das Backend übernehmen wollen oder nicht.

Dove
29.06.2007, 09:13
So dann möchste ich auch etwas von der wx Front verkünden.
Hab die Auswertung fertig und in die Tabellen wirds auch schon eingetragen, also Status sowie alamierung.
Das erste bild ist im Anhang.
Nen paar bug sind noch drin, so wie z.b. der Datenmüll der in den Vars steckt, oder das Datum, dass falsch ausgewertet wird.

Wenn ihr noch Kreative Ideen habt, her damit

@Buebchen:
Könnte man es realisieren, dass man Umlaute durch oe ue oder ae ersetzt ?
weil bei mir kommen nur Kästchen an :D
Oder man müsste es passend umkodieren.

funkwart
29.06.2007, 09:53
Ich muss schon sagen: Was Ihr da reißt, ist eine ziemlich coole Sache!!!
Jetzt schon einen herzlichen Dank an alle, die hier so aktiv an dem neuen Projekt arbeiten. Toll, wenn man sieht, dass aus einer Idee, die hier im Forum aufgekommen ist, binnen so kurzer Zeit eine maßgeschneiderte und super-variable Lösung entsteht.
Ich wünschte, ich hätte Zeit, mich da etwas einzubringen. Aber momentan weiß ich leider nicht mehr, wo mir der Kopf steht. Ich ertrinke in Arbeit.

Wenn ich zumindest moralisch oder als Tester unterstützen kann, wäre es klasse, wenn mir die entsprechenden Personen einfach eine PM zukommen lassen.

Herzlichen Dank und viele Grüße,
Funkwart

Dove
29.06.2007, 11:02
nen Client zum speichern in die mysqldb hab ich auch fertig.
Er speichert es in die DB von dem "alten" frontend von ManuelW.

Buebchen
29.06.2007, 11:38
So dann möchste ich auch etwas von der wx Front verkünden.
Hab die Auswertung fertig und in die Tabellen wirds auch schon eingetragen, also Status sowie alamierung.
Das erste bild ist im Anhang.
Nen paar bug sind noch drin, so wie z.b. der Datenmüll der in den Vars steckt, oder das Datum, dass falsch ausgewertet wird.

Wenn ihr noch Kreative Ideen habt, her damit

@Buebchen:
Könnte man es realisieren, dass man Umlaute durch oe ue oder ae ersetzt ?
weil bei mir kommen nur Kästchen an :D
Oder man müsste es passend umkodieren.

das sieht alles schon richtig prima aus. Ich glaube, wir sollten dafür im svn auch auf jeden Fall noch Projekte anlegen, natürlich nur sofern Ihr zustimmt, eine dafür geeignete Lizenzform (GPL,BSD,...) euren Projekten zu geben.

Tja. Umlaute könnte ich schon ersetzen. Aber warum sollte man sowas machen :-)

Dann lieber auf einen Zeichensatz einigen. Entweder wir nehmen iso-8859 (was Windows sehr entgegenkommt) oder UTF-8 (was eher ein allgemeiner Standard ist).

Werde auch mal schauen, was es denn da so an fertigen Tools zur Konvertierung gibt. Erste Idee wäre GNU libiconv. Werde mir das mal anschauen.

Dove
29.06.2007, 12:18
weil mein Problem ist nach convertHexToString() bekomm ich bei der Alamierung folgendes raus: udabare AusbEsudg

jhr-online
29.06.2007, 13:23
1. UTF-8, bitte... :)
2. Ich freue mich über jede Änderung im svn. Projekte sollten ja problemlos hinzuzufügen sein. Denkt aber an die Struktur (Branches, Tags und Trunk). Wir wollen ja die Form wahren ;)

jhr

PS: Sollte in der nächsten Zeit mal der Webserver ausfallen, dann bitte nicht wundern. Ich werde alles daran setzen, dass das svn stabil ist, aber es steht ein Wechsel der Hosters an... :/

Buebchen
29.06.2007, 13:27
weil mein Problem ist nach convertHexToString() bekomm ich bei der Alamierung folgendes raus: udabare AusbEsudg

... ich glaube ich sollte mir da meine Funktion auch nochmal anschauen ...

warum das Wort "unklare" zerschreddert wird habe ich nicht direkt verstanden ...

Dove
29.06.2007, 14:35
... ich glaube ich sollte mir da meine Funktion auch nochmal anschauen ...

warum das Wort "unklare" zerschreddert wird habe ich nicht direkt verstanden ...

Einer seits das anderer seits Auslösung = AusbEsudg
Also da ist das Aus (ok) dann lö versteh ich wenn dort das zeichen vorher sowie 1-2 dannach flöten gehen
nur dann bleibt da noch nen udg :D


PS.: ich hab mir nur deine convert.h kopiert.

Medic
29.06.2007, 15:28
Zur Info der Converter mach fortschritte. Die einzelnen Teile werden jetzt in seperaten Threads gestartet und es gibt auch nur noch einen seperaten Verbindungthread zum Backend.

Das einzige was noch Probleme macht ist die Multiclientfähigkeit aber daran arbeite ich noch.

Wenn ich das Programm auf den SVN schieben soll sagt gerade bescheid.

Gruß

Medic

nepomuck
29.06.2007, 17:34
Hallo zusammen,

Es freut mich zu sehen, wie das Projekt wächst und gedeiht. Ich möchte mich daher so langsam an die nächste Version der Monitor-Live-CD "Bosix" machen.

@Buebchen
Ich müsste wissen, welche Dependencies die fertig kompilierte Version des monitord hat. Dann könnte ich eine Super-Kompakte Linux-Distri bauen ( <64 MB) die vom USB-Stick ohne X bootet und direkt den Server startet. (Bosix-Server)
Dazu gäbe es dann eine "full featured" Live-CD mit monitord, Gnome oder KDE und Frontend(s).

Andreas

Buebchen
29.06.2007, 19:17
Einer seits das anderer seits Auslösung = AusbEsudg
Also da ist das Aus (ok) dann lö versteh ich wenn dort das zeichen vorher sowie 1-2 dannach flöten gehen
nur dann bleibt da noch nen udg :D


PS.: ich hab mir nur deine convert.h kopiert.

ok. Ich schäm mich ja schon. Aber der Fehler war mal so richtig dämlich, daß ich den nicht direkt gesehen habe:



inline int convertNibbleToInt(const char& c)
{
int x ;
if (c >='0' && c<='9')
{
x=c-'0' ;
} else if (c >='A' && c<='F')
{
<b> x=c-'A'+10 ;</b>
} else if (c >='a' && c<='f')
{
<b> x=c-'a'+10 ; </b>
} else {
throw BadConversion("convertNibbleToInt");
}
return x ;
}


Der Fehler war bei den Zeichen A-F. Das +10 am Ende fehlte (ja ja ja ja ja .... war bestimmt schon spät )

Dove
29.06.2007, 19:40
Buebchen dürfte ich leise erfragen ob die alamierungs text (Bzw FMS-Texte) schon mit geschickt werden ?
Wenn ja, wie kommt das an ?
Wenn Nein, wann planst du es ein zu bauen ?

Florian Feuerbaer
29.06.2007, 19:53
FMS Text sollte dabei sein.... wie schaut es aus mit unterdrückung doppelter Alarme?

Buebchen
30.06.2007, 00:35
FMS Text ist noch nicht implementiert. Wird aber als eins der nächsten Themen kommen. Ich wollte jetzt erstmal Pocsag mit 1200 Baud machen. Das geht im Moment einfach überhaupt nicht. Warum weiss ich aber noch nicht.

Ich denke, FMS Text ist in den nächsten 1-2 Wochen drin. Wird dann als weiteres Feld hinten an die FMS-Zeile drangehängt. Als Text mit HexToString konvertiert.

@Florian Feuerbaer:
Die Unterdrückung doppelter Meldungen - wie auch alle anderen Filteroptionen - sind m.E. Aufgabe des Frontends.

Buebchen
30.06.2007, 00:55
@Buebchen
Ich müsste wissen, welche Dependencies die fertig kompilierte Version des monitord hat. Dann könnte ich eine Super-Kompakte Linux-Distri bauen ( <64 MB) die vom USB-Stick ohne X bootet und direkt den Server startet. (Bosix-Server)
Dazu gäbe es dann eine "full featured" Live-CD mit monitord, Gnome oder KDE und Frontend(s).

Andreas

Es wird erstmal nicht mehr als beim klassischen monitor sein. Eher weniger, da ich definitiv weder ncurses, noch X nutze.

Buebchen
30.06.2007, 12:36
Da ich den Fehler im POC1200 Modul noch nicht finden konnte habe ich den FMSText vorgezogen. FMS Text sollte jetzt übertragen werden.

Update ist im svn. Muss ich unter linux aber noch prüfen ...

[edit]
kompiliert auch unter linux.

Dove
30.06.2007, 15:27
Also auswerten (convert String To Hex) geht immer nochj nicht so richtig.
Aus Sosi macht er Sesi und unklare Auslösung: udabare AusbEsudg

Aber der FMS-Text geht schon 1000 pro :D

Das ist echt subba

Dove
30.06.2007, 16:25
ich habe grade mal nen bissl geforscht.

Also da rennt irgendwas mit den 10 noch falsch. Ob +10 oder -10 sind ka :D

und wo auch ka :D

Buebchen
30.06.2007, 19:43
Also bei meinem Test war es danach ok.

Wichtig: Du musst deine convert.h erneuern. Der monitord hatte den Fehler "nur" bei der Auswertung von Benutzername und Passwort.

Der Fehler trat konstant bei allen Zeichen mit "A" bis "F" auf. Das "a" wurde zu Null berechnet. Das "F" zu fünf. Deswegen trifft es eben nicht nur die Sonderzeichen und Umlaute sondern alle ASCII Zahlen mit nen Buchstaben im Hexcode.

Ich habe einige Zeichenketten umkonvertiert und wieder zurück. Versuch' einmal ein "make clean" und bau dein Projekt nochmal neu.

Dove
01.07.2007, 01:34
hab ich heute nach dem checkout getan. kommen irgendwie nur komische konstruke bei raus.

Buebchen
01.07.2007, 02:08
hmm, ok.

Nur zur Sicherheit ein kleiner Test:



std::string ergebnis ;
std::string hex="6f6e" ;

convertHexToString(hex,ergebnis) ;


... das ergebnis sollte "on" sein. Das wäre richtig. Wenn du "ed" erhälst ist es noch die alte convert.h.

Dove
01.07.2007, 15:01
lol ich bin nen depp.

Hab SVN updated und neu kompiliert.
So den client habsch sicherlich nit neu gemacht ...

Gebt mir nen Orden ^^

Florian Feuerbaer
01.07.2007, 15:32
lol ich bin nen depp.

Gebt mir nen Orden ^^

Nix da.. geb gas und mach fertisch, dann schauen wir mal ;)

Dove
01.07.2007, 15:37
ohhhh :(

bei rennt es :D und bei dir ?! ^^

Dove
02.07.2007, 13:17
@Buebchen.

die badConverion Exception die beim decoden geworfen wird tritt doch dann auf, wenn er auf, wenn er zeichen findet die (<0&&>9)||(<A&&>F)||(<a&&>f)
Nur das das doch rein Theoretisch gar nicht passieren, wenn ich daten von dir bekomme (monitord)

Ich versteh nicht warum er dort ständig rein brät.

Buebchen
02.07.2007, 15:35
Wird vielleicht wird der Doppelpunkt als Trennzeichen noch mitübergeben ? Sonst lass dir die Zeichenkette vorher mal ausgeben. Aber wie du schon schreibst. Die Exeception wird nur bei Zeichen geworfen die nicht [0..9], [a..f] oder [A..F] sind.

Dove
02.07.2007, 16:44
also die Exception kommt bei sowas hier:
Error: &TRN03195967E00847EB5 -EOL- æ2ÔTôÂÒ

Error musste dir davor wegdenken, das ist noch ausgabe vorher.
Error: 67 73 f0 7d -EOL- RRô´ÄRõ¤'&öæ2ââââÔTôÂÒ

sowas kommt da auch bei raus bzw rein.

Entweder bekomm ich das so vom daemon (was ich nicht glaube) oder ich hab irgendwo noch schrott in den vars stehen.

Buebchen
02.07.2007, 17:24
Aha. Der Fehler liegt im monitord. Der Text ist ja nicht verschlüsselt, sondern klartext. Seltsam. Habe ich bestimmt wieder mal beim Testen vergessen 'was zurückzustellen.

Die zweite Aussendung ist vom Fahrzeug aus. Die sollten eigentlich überhaupt nicht auftauchen.

Werde das heute abend mal prüfen ...

Die "Schrott am Ende" liegt vermutlich daran, daß die Zeichenkettenvariable nicht bei jedem Aufruf "genullt" wird.

Dove
02.07.2007, 18:13
ja hab ich mir eigendlich auch gedacht, aber da ich die laufzeit var (mein vector mit dem jeweiligen param) erst in der While erstelle kanns daran nicht liegen.

Und der Buffer wird am ende der while auf buffer[0] = '\0'; gesetzt.

Buebchen
02.07.2007, 18:58
Nimm lieber ein



memset(buffer,0,_BUFFERGROESSE_) ;


-EDIT1-
Ich habe den -EOF- jetzt entfernt und die Datentelegramme Fahrzeug->Leitstelle sollten nun auch angezeigt werden (Ohne Leerzeichen zwischen den Zahlen).

Frage dazu:
kann mal jemand prüfen, ob die Reihenfolge der Zeichen stimmt bei Telegrammen Fzg->Leitstelle.

Damit ich die Daten aus dem BOSTool korrekt empfangen kann mußte ich die Nibbles (4Bit Werde=Einzelne Ziffern) paarweise tauschen.

So wird 12345678 tatsächlich als 21436587 bei mir empfangen.
-EDIT2-

@Dove:
Wenn Du std::string nutzt kannst du auch die .Empty Methode nutzen.

Medic
03.07.2007, 17:25
Falls ihr es noch nicht in der aktuellen Revision gesehen habt; der monitord kann jetzt auch fms32pro und crusader sprechen.
Ich habe die funktionen unter der "Aufsicht" und tatkräftiger Mithilfe von buebchen heute implementiert.
Damit die Ports aktiv werden bitte in der monitord.xml die entsprechenden Auskommentierungszeichen entfernen.
Ein Passwort wird zur zeit nicht benötigt.
Also wer lust und zeit hat, bitte testen.

Gruß

Medic

MacLeod
03.07.2007, 20:17
wow!
das ist ja klasse!

wie kann ich das denn nun ausprobieren mit dem crusader?
wenn ich indem verzeichniss monitord ein "make" mache kommt dies:

macleod@MacLeod:~/monitor/monitor/monitor/branches/2.1/monitord$ make
gcc -c -c -D _DEBUG -O2 -I../jthread-1.2.1/src/ -I../xmlParser -I../simpleopt -Wno-deprecated MonitorModules.cpp -o MonitorModules.o
gcc -c -c -D _DEBUG -O2 -I../jthread-1.2.1/src/ -I../xmlParser -I../simpleopt -Wno-deprecated MonitorModuleFMS.cpp -o MonitorModuleFMS.o
MonitorModuleFMS.cpp: In member function ‘void MonitorModuleFMS::DisplayResult()’:
MonitorModuleFMS.cpp:778: error: ‘_strdate’ was not declared in this scope
MonitorModuleFMS.cpp:779: error: ‘_strtime’ was not declared in this scope
MonitorModuleFMS.cpp: In member function ‘void MonitorModuleFMS::DisplayResult(std::string)’:
MonitorModuleFMS.cpp:1002: error: ‘_strdate’ was not declared in this scope
MonitorModuleFMS.cpp:1003: error: ‘_strtime’ was not declared in this scope
make: *** [MonitorModuleFMS.o] Fehler 1
macleod@MacLeod:~/monitor/monitor/monitor/branches/2.1/monitord$

oder hab ich da nun etwas total falsch verstanden...

wäre nett wenn einer die schritte kurz erläutern würde.

vorab schonmal
besten dank!

MacLeod

sschaebe
03.07.2007, 21:41
wow!
das ist ja klasse!

wie kann ich das denn nun ausprobieren mit dem crusader?

Hab das gleiche Problem:
suse10.2, gcc-Version: 4.1.2 aktuelle Libs

Zusatz:
meinen jetzigen recherchen nach ist in der aktuellen Version der time.h diese Funktion nicht mehr enthalten (lt. manpage auf meinem System zur time.h)
Die unter Suse 10.2 aktuellen Funktionen dazu lauten:
asctime(localtime(t)) wobei t für eine Strucktur steht



struct tm {
int tm_sec; /* seconds */
int tm_min; /* minutes */
int tm_hour; /* hours */
int tm_mday; /* day of the month */
int tm_mon; /* month */
int tm_year; /* year */
int tm_wday; /* day of the week */
int tm_yday; /* day in the year */
int tm_isdst; /* daylight saving time */
};

Da ich aber an der Stelle auf die schnelle nichts rumfingern möchte, und ich auch noch keinen schreibzugang zum Repository habe, werde ich bei gelegenheit es mal ausprobieren und dann posten.
Evtl. gibt ja auch noch andere Lösungen.

gruß
Simon

Buebchen
03.07.2007, 23:40
war ja klar, dass es wieder mal unterschiede in den Implementierungen gibt. Werde die Funktion für linux noch eben anpassen.

Heute auf der Arbeit kam ich einfach nicht dazu, es auch unter linux zu kompilieren.

jhr-online
03.07.2007, 23:55
und ich auch noch keinen schreibzugang zum Repository habePM an mich mit Wunschpasswort und fertig :)

jhr

Buebchen
04.07.2007, 00:11
Fehler ist jetzt korrigiert. Auf beiden Plattformen wird jetzt die Standardfunktion strftime genutzt. asctime/ctime ist weniger geeignet, da es einen sehr lange Zeichenkette einschließlich Wochentag generiert. Ich vermute, daß würde der Crusader nicht verstehen.

SVN aktualisiert.

[EDIT]
Noch kleine Fehler im Crusader-Modus. Sind aber auch weitestgehend gelöst. Update folgt noch
[Update]
SVN wieder aktuell. Crusader Client zeigt mir die Daten jetzt an. FMS32Pro als Client ebenso.

MacLeod
04.07.2007, 14:54
so, neu ausgechecked
make ist durcgelaufen.
nur wie starte ich monitord dann?

macleod@MacLeod:~/monitor/monitor/branches$ cd 2.1
macleod@MacLeod:~/monitor/monitor/branches/2.1$ cd monitord
macleod@MacLeod:~/monitor/monitor/branches/2.1/monitord$ monitord
bash: monitord: command not found
macleod@MacLeod:~/monitor/monitor/branches/2.1/monitord$

so siehts dann aus...

kann mir das mal einer beleuchten?
wäre nett

MacLeod

Buebchen
04.07.2007, 15:12
Der aktuelle Ordner ist nicht im Suchpfad,wie es scheint. Starte den monitor mit "./monitord".

Zum testen ein telnet auf dem Port 9333 machen. Sollte sich der monitord melden. Alternativ auf 9300 wg. FMS32Pro.

jhr-online
04.07.2007, 15:18
Auch auf die Gefahr hin, dass man mich für sehr dämlich halten wird...
for i in monitord ; do \
( cd $i ; make all ; ) done
make[1]: Entering directory `/home/jhr/Projekte/FMS-Monitor/foobar/monitord'
gcc -c -c -D _DEBUG -O2 -I../jthread-1.2.1/src/ -I../xmlParser -I../simpleopt -Wno-deprecated MonitorModules.cpp -o MonitorModules.o
gcc: error trying to exec 'cc1plus': execvp: Datei oder Verzeichnis nicht gefunden
make[1]: *** [MonitorModules.o] Fehler 1
make[1]: Leaving directory `/home/jhr/Projekte/FMS-Monitor/foobar/monitord'
make: *** [all] Fehler 2Hä?

Buebchen
04.07.2007, 15:21
Wenn da mal kein Stück vom gcc fehlt. Bin gerade nicht so sicher, in welchem Paket der cc1plus steckt. Aber such mal nach g++ in den Beschreibungen.

jhr-online
04.07.2007, 15:26
Kaum auf "Antworten" geklickt, kam's mir in den Sinn: man sollte schon einen Compiler installieren ^^

Kein Wunder, dass ich den Fehler nicht kannte. Ich hab noch nie an einem System ohne Compiler gesessen ;)

jhr

funkwart
04.07.2007, 15:36
Auch auf die Gefahr hin, dass Ihr mich jetzt für blöd haltet: Wo finde ich die aktuelle(n) Version(en)? Ich habe schonmal http://monitor.08k.de/index.php/Devel probiert, komme da aber nicht zum gewünschten Inhalt.

Danke für Eure Hilfe...

Funkwart

jhr-online
04.07.2007, 15:41
//edit: Was hier dazu stand, wo es die aktuelle Version gibt, bitte vergessen... :)
Ich antworte gleich in diesem Thread noch mal was sinnvolles. Siehe unten!

nepomuck
04.07.2007, 16:46
monitor-2_1-rev81.tar.bz
Ich habe mal eine erste Testinstallation unter Ubuntu 7.04 gemacht, und den Monitord mit einer Aufzeichnung einer Monatsalarmierung (ZVEI) konfrontiert.

Dabei sind mir zwei Sachen aufgefallen:
Nur der Monitor-Port 9333 wertet Melder/Sirenenalarmierungen aus. Der FMS- und Crusader-Port geben auch bei Sirenenalarm nur eine Melderauslösung aus.

Kommt im direkten Anschluss an eine ZVEI-Folge kein Sirenen oder Melderton, dauert es mehrere Sekunden, bis die Ausgabe der Widerholung erfolgt.

Sprich: Bei einer Alarmierung von 12345 ohne Folgeton gibt Monitor zunächst ZVEI 12345 aus, dann dauert es mehrere Sekunden, dann kommt ZVEI 12345 nochmal.

Dieses Problem habe ich übrigens auch bei der monitor-Version 1.8.1 unter Ubuntu. Da kann es bis zu zehn Sekunden nach der Alarmierung dauern, bis die Schleife im Frontend erscheint. Komischerweise tritt das Phänomen bei der Bosix-Variante auf Basis Knoppix 3.0 nicht auf.

Andreas

Buebchen
04.07.2007, 16:56
Nur der Monitor-Port 9333 wertet Melder/Sirenenalarmierungen aus. Der FMS- und Crusader-Port geben auch bei Sirenenalarm nur eine Melderauslösung aus.

Kommt im direkten Anschluss an eine ZVEI-Folge kein Sirenen oder Melderton, dauert es mehrere Sekunden, bis die Ausgabe der Widerholung erfolgt.



Deinem Post entnehme ich, daß der Test generell erfolgreich war :-)

Der Text "Melderauslösung" ist (noch) fix hinterlegt. Das ist aber recht leicht zu ändern. Kommt in Kürze.

Die Zeitverzögerung ist gewollt und erforderlich, da auf den Weckton/Sirenenton gewartet wird. Erst damit kann ja eine Ausgabe mit "Sirenenalarm" erfolgen. Kommt eine zweite ZVEI-Folge war es offensichtlich keine Sirenenalarmierung und dann wird es direkt ausgegeben (Melderauslösung). Ich meine, es waren keine 10 Sekunden. Aber da sind vielleicht noch andere Timer an deinem Ergebnis beteiligt.

nepomuck
04.07.2007, 17:10
Deinem Post entnehme ich, daß der Test generell erfolgreich war :-)

Na klar, ich bin ganz begeistert. Danke.
Ich werde mal einen längeren Live-Test auf einem Server-PC mit Scanner starten und ein paar VMs als Clients davor hängen. Dank selbstgebastelter Außenentenne habe ich nun auch im Serverzimmer einen störungsfreien Empfang, der für FMS und ZVEI genügt.
Gibt's denn schon ein Frontend für das Monitor-Protokoll?



Die Zeitverzögerung ist gewollt und erforderlich, da auf den Weckton/Sirenenton gewartet wird.

Das ist klar, aber der Timeout erscheint mir etwas arg lang. Eigentlich sollten 100ms "Stille" genügen, oder?

Andreas

Buebchen
04.07.2007, 17:58
Also wenn ich ehrlich bin müßte ich das mal nachlesen...

Sind 100ms eine Schätzung, oder ist das in der ZVEI Norm so vorgesehen ?

[EDIT]
100ms ist zu knapp. Die Pause nach der 5-Tonfolge kann schon 600ms sein.

Dann noch mindestens 2Sekunden Doppelton damit es ein Sirenenalarm ist. Diese Zeit wartet er auf jeden Fall ab, um sicher zu sein, daß es kein Sirenenalarm ist.

Gut. Da könnte man versuchen eine Abbruchbedingung reinzubauen. Werd' das mal notieren.

Dove
04.07.2007, 18:01
ich bin grade an einer am entwickeln, nen screenshot solltest du 1 oder 2 vllt auch 3 seiten vorher sehen :D

jhr-online
04.07.2007, 18:12
Jetzt noch mal richtig:
Wer mitmachen will, muss sich jeweils den aktuellen Stand aus dem subversion-Repository holen:
svn co svn://jhr-online.de/monitor/monitor/branches/2.1Wer sich zum Testen einfach eine aktuelle Version daraus ziehen will, kann auf den subversion-Kram verzichten und dafür den Zweig im Repository einfach exportieren:
svn export svn://jhr-online.de/monitor/monitor/branches/2.1Da vielleicht nicht jeder damit umgehen kann oder will, habe ich mal eine aktuelle Version exportiert und bereit gestellt unter: http://downloads.jhr-online.de/monitor/
In dem Verzeichnis kann man sich die Dateien online angucken; wer's lokal haben will, also zum Kompilieren und Testen, kann sich den bzip-komprimierten Tarball runterladen:
http://downloads.jhr-online.de/monitor/monitor-2_1.tar.bz

Und jetzt das Beste: Zwei mal am Tag (um 8.30 und um 20.30 Uhr) wird das Verzeichnis und der Tarball automatisch neu exportiert. Wenn sich also was geändert hat, ist man um die Zeit gut bedient ;)
Wenn jemand eine aktuellere Version braucht, kann er sich die ja exportieren oder mir auf gut Glück ne Mail schicken.

Ist das Service? ;)

jhr

//edit: Für einige, die es noch nicht bemerkt haben... Der Tarball wird mittlerweile im 3-Stunden-Takt gebildet.

sschaebe
04.07.2007, 18:17
Ist das Service? ;)

jhr
Soweit so gut. Leider bekomme ich mit dem aktuellen Rep. nach dem erfolgreichen kompilieren nur einen Segmentaition fault.
EDIT: Das Problem mit dem Segmentation Fault habe ich gefunden: monitord.xml war defekt.
Gibt es ein Logfile oder kann ich irgendwelche trace-Ausgaben aktivieren?

Gruß
Simon

nepomuck
04.07.2007, 18:22
Sind 100ms eine Schätzung?

Ja -- ich habe keine Ahnung, was die Norm vorsieht.

Noch ein paar "Bugs":

1.
Meine Testaufzeichnung besteht NUR aus ZVEI-Alarmen. Dennoch gibt der monitord ab und zu FMS-Telegramme aus.

2.
Die Verbindung zu FMS-PRO32 funktioniert nicht richtig. Ich spiele dem Monitor serienweise ZVEI-Alarme vor und nach einer gewissen Zeit kommen nicht mehr alle Schleifen beim FMS-PRO32-Client an. Interessanterweise zeigt eine andere Maschine mit "telnet <monitor-server> 9300" alle Schleifen korrekt an.

Konfig: SRV: Ubuntu 7.04, CLT1: Ubuntu 7.04 mit Telnet, CLT2: VM unter VMWare 6 mit XP und FMS-PRO32 3.2.2

Andreas

MacLeod
04.07.2007, 18:30
huhu!
also, bei mir klappt das irgendwie nicht :-((((
ich habe ne verbindung sowohl mit nem crusader- als auch mit FMS32-client. aber er wertet nix aus. ich habe ihm mal ne 5tonfolge auf den line in gegeben, wertet er aber nicht aus.

mache ich noch was falsch?
habe ich was übersehen?

edit:
wenn ich telnet >server-ip< 9300 ausführe, wird dort auch nichts angezeigt.
konfig mit der soudkarte des servers nicht i.O? sollte aber... mit nem crusader server hats dort so mal gefunzt...

MacLeod

jhr-online
04.07.2007, 18:39
wenn ich telnet >server-ip< 9300 ausführe, wird dort auch nichts angezeigt.
konfig mit der soudkarte des servers nicht i.O? sollte aber... mit nem crusader server hats dort so mal gefunzt...Nur um sicher zu gehen, dass es nicht an einem Tippfehler liegt... Wir hatten Port 9333 angepeilt IIRC.

jhr

MacLeod
04.07.2007, 19:11
ups, ja, meine natürlich den 9333 ;-)

Medic
04.07.2007, 21:21
Ich hab das gleich Problem wie MacLeod,

Ich kann verbindung aufbauen aber er wertet nichts aus. Auch auf der console erscheint vieleicht mal 1 Eintrag und das war es dann.

Dove
04.07.2007, 21:53
ist das sound device belegt ?

bei mir läuft das alles einwandfrei.

Gucktmal auf welchem Kanal die Daten ankommen und auf welchem Ihr auswertet.

Buebchen
04.07.2007, 22:32
Gibt es ein Logfile oder kann ich irgendwelche trace-Ausgaben aktivieren?

Gruß
Simon

Logfile ist bisher Fehlanzeige. Das Execption-Handling ist bis auf wenige Ausnahmen auch noch nicht implementiert.

Was es gibt, ist ein "#define DEBUG " zu machen. Wenn es eine solche Definition gibt macht er ein paar Ausgaben mehr. Aber ob die bei einem segfault helfen werden ... Muss man dann mal probieren.

Am besten direkt im Makefile des monitord mit -D hinterlegen. Dann wird es auch überall gesetzt.

Ist halt noch alles vorm Beta-Stadium. Da ist der Forscher gefragt :-)

Medic
04.07.2007, 22:32
Also die Sounddevice ist ok bei mir kommt nur das:

Display :6 762 3744: 2
310:1183577422:4d6f6e69746f7264:4b616e616c2031:676 23744:2:1:0:3
1183577422

und das war es dann.
Es werden keine Daten über einen Port ausgegeben

Buebchen
04.07.2007, 22:47
Entweder bist du nicht angemeldet oder die IP des Client ist gesperrt.

[Edit]
Anmeldung als User "test" mit dem Passwort "test":

120:74657374:74657374

sschaebe
05.07.2007, 07:22
120:74657374:74657374

Lt. KommProtokoll sollte der Authentikationstring vom Client mit 220 eingeleitet werden. Oder habe ich jetzt die Schnittstellenbeschreibung falsch verstanden? Bin da nämich auch schon darüber gestolpert.

Gruß
Simon

Medic
05.07.2007, 09:43
soll ich das direkt senden? weil ich krieg z.b. auch die welcome message vom monitor nicht

jhr-online
05.07.2007, 10:40
Und kann es sein, dass der Login überhaupt nicht geprüft wird? Oder gibt der monitord auch nach fehlgeschlagenem Login ein "Login OK" zurück?

jhr

Medic
05.07.2007, 10:55
Also ich hab die 120er anmeldung mal gesendet aber es passiert einfach nix, wie gesagt ich krieg nichtmal die welcome message.
vieleicht liegts an meinem system, ich werd mal schauen ob ich ein anderes auftreiben kann

@nepomuk

Der Text "Melderalarmierung" ist fester bestandteil des Komm.Protkolls vom Crusader. Es gibt keinen Text "Sirenenalarmierung", da der Crusader das nicht unterscheidet.

Im Regelfall wird dieser Text auch durch den Schleifennamen ersetzt soweit er in der Crusader-Config hinterlegt ist.

jhr-online
05.07.2007, 11:19
@all:
Mir und einigen anderen hier fällt es mittlerweile schwer, Informationen wieder zu finden, die irgendwo hier im Thread oder im Forum verschollen sind. Ich will niemanden bequatschen, aber meint ihr nicht auch, dass es sinnvoll wäre, jetzt so langsam auf die Verwendung der Mailingliste umzusteigen? Wir haben jetzt ein paar Leute, die an verschiedenen Stellen das Projekt aktiv begleiten (Client- und Serverseitig), und hinzu kommen einige Tester, die jetzt ihre Probleme mit den neuen Modulen berichten und Wünsche äußern. D.h. es wird definitiv noch mehr und damit noch unübersichtlicher werden in naher Zukunft!
Prinzipiell wäre für sowas natürlich das BTS gut, aber ich denke, darauf können wir in der Alpha-Phase erstmal verzichten (wenn ich überlege, wie viel man da schon eintippen müsste ^^).

Also, was meint ihr? Das Archiv der Liste ist selbstverständlich öffentlich, sodass weiterhin jeder Interessierte mitlesen kann (und das sogar mit vernünftigen Threads, sofern jeder richtig E-Mails schicken kann).

jhr

Die Liste abonnieren: http://lists.jhr-online.de/listinfo/monitor
Das Archiv: http://lists.jhr-online.de/pipermail/monitor/

sschaebe
05.07.2007, 11:42
Und kann es sein, dass der Login überhaupt nicht geprüft wird? Oder gibt der monitord auch nach fehlgeschlagenem Login ein "Login OK" zurück?

jhr

Jepp. So ist es. Du bekommst ein 102:LOGIN OK glaube ich, kann es leider im Moment nicht prüfen. Und danach kommen die Telegramme/Statusmeldungen, Alamierungen kommen IMHO noch nicht an.

Gruß
Simon

nepomuck
05.07.2007, 12:39
so langsam auf die Verwendung der Mailingliste umzusteigen?

Ich glaube nicht, dass es dann übersichtlicher wird.

Vorschlag:
Wir trennen die aktuellen Anfragen auf verschiedene Threads auf und der jeweilige Thementitel beginnt mit "2.1". So weiss jeder, dass es sich dabei um ein Thema zur Entwicklung der 2.x handelt.

Andreas

jhr-online
05.07.2007, 12:42
Ich glaube nicht, dass es dann übersichtlicher wird.Ich wohl, sehr sogar, aber wir leben ja keine Diktatur...
Vorschlag:
Wir trennen die aktuellen Anfragen auf verschiedene Threads auf und der jeweilige Thementitel beginnt mit "2.1". So weiss jeder, dass es sich dabei um ein Thema zur Entwicklung der 2.x handelt.Das funktioniert nur so lange, wie sich jemand darum kümmert, dass das auch so durchgehalten wird. Ich hab auch keine Lust, in jedem Thread als erste Antwort zu lesen "Wir hatten uns darauf geeinigt..."

More opinions?

Buebchen
05.07.2007, 14:27
Wir können die Mailinglisten ja - wie vorgeschlagen - für die Entwickler nutzen und generelles im Forum lassen.

Ich bin zwar kein Freund von Mailinglisten, weil ich eher mal "nebenbei" surfe, als meinen privaten E-Mailclient zu starten, aber die Übersicht leidet ja tatsächlich ein wenig.

nepomuck
05.07.2007, 16:12
@Buebchen
Sieh dir bitte mal den angehängten Screenshot des FMS-Clients an.
Dort siehst du reguläre ZVEI-Alarmierungen -- wie üblich gehen die 5-Ton-Folgen zweimal direkt hinteinander raus.

Achte auf die Zeitdifferenz zwischen dem ersten und zweiten Eintrag pro Schleife. Da sind einmal 60 ein anderes mal 22 Sekunden zwischen den Schleifen, obwohl bei beiden Alarmierungen die Schleifen wie üblich in direkter Folge aber ohne Melderton am Ende gesendet wurden.

Irgendwas kann da am Timing im ZVEI-Modul nicht ganz stimmen.

Andreas

nepomuck
05.07.2007, 16:16
Kurze Frage:

Wenn ich das MySQL-Backend des monitord verwenden will, kann ich dann einfach eine leere DB erstellen und monitord legt automatisch die Tabellenstruktur an?

Oder kann jemand mal die erforderliche SQL-Datei mit den "Create Tables" posten, ich finde im Tarball der aktuellen Version keine.

Andreas

sschaebe
05.07.2007, 16:17
Ich bin zwar kein Freund von Mailinglisten, weil ich eher mal "nebenbei" surfe, als meinen privaten E-Mailclient zu starten, aber die Übersicht leidet ja tatsächlich ein wenig.
Das Archiv ist ziemlich flott von JHR. Du kriegst das Quasi onTheFly mit wenn jemand an die Mailingliste geschrieben hat.

Gruß
Simon

Buebchen
05.07.2007, 17:27
Irgendwas kann da am Timing im ZVEI-Modul nicht ganz stimmen.

Andreas

Leider komme ich erst heute abend dazu, mir das mal anzusehen. Eine gewisse Verzögerung wird immer drin sein, da ich die Daten durch zwei Message-Queues schicke. Aber ne ganze Minuten ist wirklich definitiv zu lang. Selbst die 20 Sekunden. Aber ich vermute, daß das mit den Queues zusammenhängt.

sschaebe
05.07.2007, 19:33
Kurze Frage:

Wenn ich das MySQL-Backend des monitord verwenden will, kann ich dann einfach eine leere DB erstellen und monitord legt automatisch die Tabellenstruktur an?

Oder kann jemand mal die erforderliche SQL-Datei mit den "Create Tables" posten, ich finde im Tarball der aktuellen Version keine.

Andreas
IMHO funktioniert das DB-Backend nch nicht. Ich habe es zumindest nicht zu laufen bekommen. Im ganzen monitord-Code gibt es den Begriff mysql nicht.

Gruß
Simon

Dove
05.07.2007, 22:12
ich hab mir einen client gebaut der zum monitord connected und dort die daten dann in die db klatscht.

Wenn ihr wollt, kann ich das gerne auf den svn schieben.

A.Nero
05.07.2007, 23:06
@dove : gerne

@dove & buebchen : koennte man diese funktion nicht auch noch optional in den monitord miteinbauen?

Dove
05.07.2007, 23:08
hatte ich schon mal vorgeschlagen, da ich das auch von vorteil sehe.

Ich lad das gleich hoch

A.Nero
05.07.2007, 23:12
cool, danke fuer deinen Einsatz. Demnaechst muss ich hier auch mal was machen, wenn ich endlich wieder ne Linux Kiste habe :)

Dove
05.07.2007, 23:23
also ich hab das bis heute nur unter linux am laufen, ob das unter win geht hab ich ka.

Buebchen
06.07.2007, 00:11
Geht grundsätzlich auch unter windows. Ist halt noch nicht dokumentiert. Ansonsten kann man das binary (sofern man es erstellt hat :-)) wie folgt als Dienst installieren/deinstallieren:



monitord -install
monitord -remove


Die monitord.xml wird dann IMHO aus dem System32 Ordner gelesen.

Ruft man die .exe ohne Parameter auf startet es auch. Kann dann aber nur über den Task-Manager beendet werden, da kein Fenster erstellt wird.

Der Rest sollte identisch sein. Wobei das sollte durchaus den Charakter von "vielleicht" hat. Ich debuggen aber z.B. mehr unter Windows, als unter linux.

MySQL ist fest im Plan aber im Moment noch nicht umgesetzt. Es gibt aber in fast allen Modulen schon einen Funktion StoreResult. Diese ist dafür gedacht.

Buebchen
06.07.2007, 00:29
@dove : gerne

@dove & buebchen : koennte man diese funktion nicht auch noch optional in den monitord miteinbauen?

Ist ja mein Reden :-)

Deswegen auch schon mal als Option vorgesehen.

Buebchen
06.07.2007, 01:14
So, ZVEI sollte jetzt keine so langen Pausen mehr machen. Meine Test sehen da auf jeden Fall besser aus (telnet auf FMS32 Port < 5 Sekunden, wenn kein Weckton folgt).

Ausserdem muss man sich für FMS32Pro nun mit "PASS:<password>" anmelden.

Es wird gegen einen Login mit dem festen Namen "fms32pro" das Passwort (ohne spitze Klammern) geprüft.

Medic
06.07.2007, 10:26
Äh Buebchen...FMS32Pro hat keinerlei Passwort-Authentisierung mit drin. Der Crusader ja, aber nicht FMS32Pro

Buebchen
06.07.2007, 13:04
Oh.. Wer war das denn mit dem PASS:<xyz>

Dann habe ichs gerade falschrum gemacht :-)

Sollte einfach nicht mehr so spät arbeiten ...

nepomuck
06.07.2007, 13:11
Dann habe ichs gerade falschrum gemacht :-)
Im Code scheint's zu stimmen. Habe die source von heute früh 8 Uhr bei JHR geladen und die funzt mit FMS32 ohne Probleme.

Andreas

Buebchen
06.07.2007, 13:34
Das kann ja auch am "whitelist" liegen. Das geht auf jeden Fall immer. Ansonsten war es trotzdem falsch. FMS32Pro kennt kein PW. Der Crusader schon.

Habe das jetzt auch korrigiert und im SVN aktualisiert.

nepomuck
06.07.2007, 14:57
So, ZVEI sollte jetzt keine so langen Pausen mehr machen.

Ist der Code bereits im Tarball von heute morgen 8:00 Uhr drin?
Mit dem Build ist der Effekt schlimmer als gestern -- siehe Anhang.

Andreas

jhr-online
06.07.2007, 16:47
Ist der Code bereits im Tarball von heute morgen 8:00 Uhr drin?
Mit dem Build ist der Effekt schlimmer als gestern -- siehe Anhang.Wenn ich jetzt aufgepasst habe, war das nicht drin. Ich habe eben neu exportiert. Man kann jetzt die aktuelle Fassung (15:43 Uhr) als tar.bz runterladen.

MacLeod
06.07.2007, 17:16
hi!
ich muß da noch mal nachhaken....
wenn ich also "telnet >server-ip< 9333" auf der dos-box meines clienten eingebe soll eine welcome message erfolgen?
also bei mir ists so, dass die box dann gelöscht wird und oben links in der ecke blinkt der dos-promt. nix mit meldung oder so. danach erfolgt rein gar nichts...
mache ich da nun was falsch, oder habe ich irgendwas übersehen?

MacLeod

Buebchen
06.07.2007, 17:19
Ist der Code bereits im Tarball von heute morgen 8:00 Uhr drin?
Mit dem Build ist der Effekt schlimmer als gestern -- siehe Anhang.

Andreas

Werde mir das mit dem FMS32Pro Client mal prüfen. Am ZVEI Timing liegt es defintiv nicht.

[Edit:]
So, habe jetzt mal ein bisschen mit dem BOS-Tool gespielt. Auf den ersten Blick kapier ich nicht, warum das bei Dir so seltsam aussieht.

Ist das Verhalten denn NUR beim ZVEI so ?

Buebchen
07.07.2007, 17:25
hi!
ich muß da noch mal nachhaken....
wenn ich also "telnet >server-ip< 9333" auf der dos-box meines clienten eingebe soll eine welcome message erfolgen?
also bei mir ists so, dass die box dann gelöscht wird und oben links in der ecke blinkt der dos-promt. nix mit meldung oder so. danach erfolgt rein gar nichts...
mache ich da nun was falsch, oder habe ich irgendwas übersehen?

MacLeod

Generell beantwortet der monitord alle Verbindungsanfragen mit der welcomeMessage. Egal ob man sich von dieser IP aus überhaupt einloggen kann. Ggf. ein Problem mit ner Firewall ?

MacLeod
07.07.2007, 17:44
Generell beantwortet der monitord alle Verbindungsanfragen mit der welcomeMessage. Egal ob man sich von dieser IP aus überhaupt einloggen kann. Ggf. ein Problem mit ner Firewall ?

hm...
firewall ist nicht aktiv.
was ich auch mache, er spricht nicht mit mir.
ubuntu 6.10 server lüppt auf der kiste.

edit
hab mal per vmware nen ubuntu 6.10 client gestartet und dadrauf monitord gestartet. dort bekomme ich :
110:monitord 2.0.0 READY

komisch...

MacLeod
07.07.2007, 18:39
so...
also er wertet aus!
das erscheint auf dem server:

Display :6 8xx xxxx: 2
310:1183821515:4d6f6e69746f7264:4b616e616c2031:68x xxxxx:2:1:0:2
1183821515
Display :6 8xx xxxx: f
310:1183821515:4d6f6e69746f7264:4b616e616c2031:68x xxxxx:f:1:1:3
1183821515
Display :6 8xx xxxx: 2
310:1183821515:4d6f6e69746f7264:4b616e616c2031:68x xxxxx:2:1:0:2
1183821515
Display :6 8xx xxxx: f
310:1183821516:4d6f6e69746f7264:4b616e616c2031:68x xxxxx:f:1:1:3
1183821516

das ist doch schon mal klasse :-)

gleichzeitig habe ich per telnet geschaut, dort blieb aber nur "110:monitord 2.0.0 READY" demnach dann auch keine anzeige auf dem crusader :-(

warum nur geht das bei mir nicht...
*heul*

MacLeod

Buebchen
07.07.2007, 19:23
Der Crusader würde den Port 7778 nehmen. Nicht 9333. Am 9333 musst Du dich anmelden:

/User=test,PW=test)

220:74657374:74656374

oder deine IP in der monitord.xml freischalten, daß kein Login nötig ist.

Wo du gerade Crusader sagst: Ich glaube da muss ich mal den festgelegen Benutzernamen fms32pro ändern. Da war ich mal ein wenig geistig verwirrt.

nepomuck
07.07.2007, 19:26
Ist das Verhalten denn NUR beim ZVEI so ?
Ja, aber mit dem Build von gestern Nachmittag sieht das ganze Besser aus.

Dafür habe ich jetzt einen anderen ZVEI-Fehler gefunden:



...
300:1183802454:4d6f6e69746f7264:4b616e616c2032:210 24:0:756E6B6C617265204175736C2073756E67
300:1183802455:4d6f6e69746f7264:4b616e616c2032:210 24:0:756E6B6C617265204175736C2073756E67
300:1183802456:4d6f6e69746f7264:4b616e616c2032:102 61023:0:756E6B6C617265204175736C2073756E67
300:1183802457:4d6f6e69746f7264:4b616e616c2032:210 23:1:4D656C6465726175736C2073756E67
...
300:1183813665:4d6f6e69746f7264:4b616e616c2032:210 31:0:756E6B6C617265204175736C2073756E67
300:1183813666:4d6f6e69746f7264:4b616e616c2032:210 31:0:756E6B6C617265204175736C2073756E67
300:1183813667:4d6f6e69746f7264:4b616e616c2032:103 31056:0:756E6B6C617265204175736C2073756E67
300:1183813668:4d6f6e69746f7264:4b616e616c2032:210 56:0:756E6B6C617265204175736C2073756E6
....


8-stellige 5-Ton-Alarmierungen sind mir bislang undbekannt :-)

Der Fehler kommt auf Port 9333 und 9300 an.

viele Grüße,
Andreas

Buebchen
07.07.2007, 20:10
So, crusader muss sich jetzt auch anmelden. Da es dort keine Benutzernamen gibt habe ich das so integriert:

Es wird nach einem Benutzer "crusader" gesucht. Mit dessen Passwort kann sich der Crusader anmelden (in der Standard-Version ist das Passwort "pw"). So habe ich es auch in der monitord.xml hinterlegt.

@Nepomuck:
Auch nicht schlecht :-) Werde mir das mal anschauen. Sieht ein bisschen so aus, als ob da irgendein Zähler nicht zurück auf "Null" geht. Die letzten 4 Ziffern stimmen ja vermutlich dann wieder.

MacLeod
08.07.2007, 14:02
hm..
nun steigt er mir beim make aus:

-Wno-deprecated SocketServer.cpp -o SocketServer.o
SocketServer.cpp: In member function âvoid SocketThread::checkLoginCrusader(std::string)â:
SocketServer.cpp:709: error: no match for âoperator<<â in âstd::operator<< [with _Traits = std::char_traits<char>]...
...
eam<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std::char_traits<char>]
make[1]: *** [SocketServer.o] Error 1
make[1]: Leaving directory `/home/macleod/2.1/monitord'
make: *** [all] Error 2

Buebchen
08.07.2007, 16:04
Kleiner Fehler bei den Debug-Ausgabe. Ist jetzt behoben. SVN aktualisiert.

MacLeod
08.07.2007, 20:16
jo, make lüppt jetzt durch :-)

nur zeigt mir crusader immer noch nichts an :-(((
wenn's bei anderen geht, aber bei mir nicht, muß ich doch was falsch machen, bzw an irgendetwas nicht gedacht haben. nur was???

ideen?

MacLeod

Buebchen
08.07.2007, 23:40
Um den Crusader-Port zu testen folgenden machen:

1. Telnet auf den Port 7778
2. PASS:pw

(oder statt pw das in der monitord.xml angegebene Passwort für den crusader Benutzer)

Jetzt sollten Ausgaben erfolgen, wenn etwas neu ausgewertet wird. Der Crusader Server macht keine Meldung, wenn man sich mit dem Port verbindet.

Das gleiche beim FMS32Pro:

1. Telnet auf den Port 9300

Fertig

Für den monitord:

1. telnet auf den Port 9333
2. Es sollte die Meldung "110:monitord 2.0.0 READY" kommen.
3. mit 220:&lt;User-In-Hex&gt;:&lt;Passwort-in-Hex&gt; anmelden

Jetzt sollten auch hier ausgaben erfolgen. Die erfolgreiche Anmeldung wird bestätigt.

WICHTIG.
in der monitord.xml kann man IPs sperren:



&lt;auth&gt;
&lt;login&gt;
&lt;name&gt;test&lt;/name&gt;
&lt;password&gt;test&lt;/password&gt;
&lt;/login&gt;
&lt;login&gt;
&lt;name&gt;crusader&lt;/name&gt;
&lt;password&gt;pw&lt;/password&gt;
&lt;/login&gt;

&lt;!-- Bisher nur IP Adressen. Keine Netze oder Bereiche ! --&gt;
&lt;!-- Mehrfachnennungen sind aber moeglich, sofern sie Sinn machen --&gt;
&lt;!-- Suchreihenfolge: allow, login, deny --&gt;
&lt;ip action=login&gt; any &lt;/ip&gt; &lt;!-- Diese IPs muessen sich einloggen --&gt;
&lt;ip action=allow&gt;192.168.0.1&lt;/ip&gt; &lt;!-- Diese IPs muessen sich nicht einloggen --&gt;
&lt;ip action=allow&gt;192.168.0.2&lt;/ip&gt; &lt;!-- Diese IPs muessen sich nicht einloggen --&gt;
&lt;ip action=allow&gt;192.168.0.3&lt;/ip&gt; &lt;!-- Diese IPs muessen sich nicht einloggen --&gt;
&lt;ip action=deny&gt;any&lt;/ip&gt; &lt;!-- Diese IPs koennen sich nicht einloggen --&gt;
&lt;/auth&gt;

MacLeod
09.07.2007, 15:44
@Buebchen
jo, begriffen :-)

jupp, per telnet bekomme ich nun auch daten angezeigt *freu*
problem bei der sache ist aber das nur die v4.50Demo fuktioniert
ich habe noch ne alte V4.30... die zeigt nichts an...
benötigt sie ev etwas anderes? kann ich mir aber nichtz vorstellen


MacLeod

Edit:
@Buebchen ich könnte sie dir zur verfügung stellen falls benötigt ;-)

Buebchen
09.07.2007, 18:12
Setzt die IP, mit der der Crusader sich meldet mal auf

&lt;ip action=allow&gt;192.168.0.1&lt;/ip&gt;

in der monitord.xml. Keine Ahnung, was die V4.30 da anders macht.

MacLeod
09.07.2007, 20:05
es klaptt! ich werd verrückt!
@Buebchen: danke für die geduld!

was jetzt natürlich noch der hit wäre, wenn beim aufruf von crusader oder fms32 die letzten meinetwegen 1000 protokolle eingelesen werden. ich weiß ja nicht obs möglich ist, das umzuseten. aber das wäre der knüller!

klasse arbeit die ihr dort hingelegt habt. vielen dank schon mal.
wenn ich was helfen kann, gerne. nur wird leider nicht mehr als testen gehen.
ich hoffe das dieses projekt weiter wächst!

bis dahin
MacLeod

Buebchen
09.07.2007, 20:18
Das mit den 1000 letzten Einträgen wäre dann m.E. die kontrovers diskutierte MySQL Datebank :-)

Mal sehen, was da noch kommt ...

Dove
09.07.2007, 20:30
Dank Anero ist mein monitordb hoch geladen.

monitordb ist nen c++-programm zum auslesen der monitordb das die daten in eine mysqldb postet.

und ein PHP-Frontend.

MacLeod
09.07.2007, 22:49
kann das nicht kombiniert werden?

Buebchen
12.07.2007, 17:29
kann das nicht kombiniert werden?

Das wird irgendwann als Option kommen. Alleine weil ich das für eigene Entwicklungen gut nutzen könnte. Bleibt nur zu klären, wie die Datenbank dann aussehen soll.

Ansonsten würde mich mal interessieren, ob jemand schonmal versucht hat POCSAG mit 1200 Baud auszuwerten. Bei mir passiert mal so gut wie nix, wenn ich mit dem BOSTool 1200 Baud erzeuge. Aber vielleicht liegts auch nur an meinen Einstellungen. Ich habe leider keine Audiodatei mit 1200 Baud zum testen .

nepomuck
13.07.2007, 01:01
Hallo zusammen,

Gibt es verschiedene FMS-Übertragungsmethoden?

Folgendes Problem: Der Monitord 2.1 rev 88 lauscht auf dem Funk. Dabei wertet er, dank gutem Empfang, nahezu alle FMS-Statusmeldungen korrekt aus.

Aber: Da funken einige Fahrzeuge umher, deren Statusmeldungen klingen akkustisch anders und Monitord wertet nix aus. Die Leitstelle hingegen scheint alles mitzubekommen.

Was kann das sein?

Andreas

Buebchen
13.07.2007, 03:17
Es werden von diesen Fahrzeug überhaupt keine FMS Telegramme erkannt ? Oder nur einige bestimmte nicht ?
Werden denn die Quittungen LST->Fzg ausgewertet ?

Es könnte Folgetelegramme sein. Ggf. GPS-Koordinaten ? Gibt es sowas in eurem Funkkreis ?

Generell ist FMS in einer TR genormt. Was nicht heisst, daß es da Unterschiede in der Implementierung gibt. Einige FMS-Hörer senden Ihren Status z.B. manchmal nur einmal, statt wie meistens zweimal. Einige Auswerter-Optionen sind noch fest hinterlegt. Die werden jetzt aber so langsam nachgerüstet. So zum Beispiel die Länge der Präambel für FMS. Die macht manchmal Ärger.

nepomuck
17.07.2007, 00:51
Es werden von diesen Fahrzeug überhaupt keine FMS Telegramme erkannt ?
Gar nichts, kein Status.


Es könnte Folgetelegramme sein. Ggf. GPS-Koordinaten ?

Nein. Die Leitstelle setzt nur Statusmeldungen ein.


Einige FMS-Hörer senden Ihren Status z.B. manchmal nur einmal, statt wie meistens zweimal.

Das könnte es sein. Die FMS-Übertragungen dieser Fahrzeuge sind viel kürzer. Evtl arbeitet die Rauschsperre des Scanners zu träge und bekommt deshalb die Präambel nicht richtig mit. Es wird allerdings schwerfallen, diesen Fehler nachzuvollziehen. Er tritt leider bei Fahrzeugen auf, die nicht so häufig alarmiert werden.

Was ist übrigens aus dem Fehler mit acht Ziffern für Fünf-Ton alarmierung geworden? Der tritt in meiner Testsinstallation recht häufig auf, besonders bei Ziffernfolgen die mit 210, 211 oder 212 beginnen.

Andreas