Druckbare Version
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
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.
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.
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
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
Mir fallen dazu spontan folgende Fehler ein:Zitat:
Zitat von MiThoTyN
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.
Bei einer Sirenenalarmierung gäbe es also eine doppelte Ausgabe?Zitat:
Zitat von MiThoTyN
300:26250:1
330:1
Macht as Sinn?
Jagen wir da den Benutzernamen als ASCII durch? Oder bleiben wir dabei, dass wir Konsequent alle Textübertragungen Hex-Codieren?Zitat:
Zitat von MiThoTyN
Das sollte genügen. Es müßte ja passende crypt-Funktionen geben, die als Output ein Hex-kodierten Code liefern.Zitat:
Zitat von MiThoTyN
Ich würde zudem vorschlagen, dass der Monitor-Daemon je nach Konfiguration auch anonyme Logins ohne PW zulassen kann.
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.Zitat:
Zitat von MiThoTyN
Andreas
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.Zitat:
Zitat von nepomuck
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.
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.Zitat:
Zitat von nepomuck
Alles HEX-Codieren. Da sollte man in der Tat konsequent sein. Sonderzeichen kann es ja auch im Usernamen geben.Zitat:
Zitat von nepomuck
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.Zitat:
Zitat von nepomuck
Gruß Joachim
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.
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.Zitat:
Zitat von MiThoTyN
Es gibt da eine Liste im Internet unterZitat:
Zitat von Buebchen
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
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.Zitat:
Zitat von nepomuck
Klingt gut.Zitat:
Zitat von nepomuck
Ich werd am Wochenende mal die Schnittstellenbeschreibung verfeinern. Dass wir da die genaue Syntax pro Zeile definiert haben.
Gruß Joachim
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
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.
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:Zitat:
Zitat von Schewal
http://www.funkmeldesystem.de/foren/...4&postcount=12
Weitere Nachfragen bitte in diesem Thread.
Andreas
@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 ?
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
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).
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
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 :-)
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
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
Code: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
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
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.
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.
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.
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.
thx habs an PROGS dran gehangen nu gehts.
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() ,;
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.
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?
Exakt!Zitat:
Zitat von Medic
Gruß,
Funkwart
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:
[channel part="left"]
[name]Kanal 1<[/name]
[/channel]
[channel part="right"]
[name]Kanal 2[/name]
[/channel]
... bin mir aber gerade nicht sicher, ob ich das überhaupt schon mit ausgeben :-)
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 :-)Zitat:
Zitat von Medic
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 ?
jetzt schon. SVN geupdated (Nur unter Win32 getestet. Sollte unter linux aber genauso compilieren).Zitat:
Zitat von Buebchen
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
{soundcard num=0}Zitat:
Zitat von Buebchen
{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...
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.Zitat:
Zitat von PolyMorPhisMus
Welchen Kompiler nutzt du ?
Hmm.Die demod_se() Funktion war mal so ein Test. Hatte aber nicht so richtig geklappt (bisher). Deshalb erstmal fest die demog_mg().Zitat:
Zitat von PolyMorPhisMus
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.
Die Auswerter sind aber abgeleitete Klassen. Aber eigentlich sollte das gehen...Code:class MonitorModule ;
typedef std::vector<MonitorModule*> MonitorModuleArray ;
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 ?Zitat:
Zitat von PolyMorPhisMus
heist das, monitor kann jetzt als server für den crusader laufen?Zitat:
Zitat von Medic
ist das jetzt im svn-repository schon enthalten? oder läuft der converter extra...
das wäre ja ultra-klasse
cu
MacLeod
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.
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.
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.
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
nen Client zum speichern in die mysqldb hab ich auch fertig.
Er speichert es in die DB von dem "alten" frontend von ManuelW.
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.Zitat:
Zitat von Dove
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.
weil mein Problem ist nach convertHexToString() bekomm ich bei der Alamierung folgendes raus: udabare AusbEsudg
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... :/
... ich glaube ich sollte mir da meine Funktion auch nochmal anschauen ...Zitat:
Zitat von Dove
warum das Wort "unklare" zerschreddert wird habe ich nicht direkt verstanden ...
Einer seits das anderer seits Auslösung = AusbEsudgZitat:
Zitat von Buebchen
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.
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