monitor 1.9.0 - aber richtig :)

Hallo zusammen,
ich habe mich in den letzen Stunden mal "eben" durch diese Threads gehangelt... Das ist ja furchtbar :-)

Jetzt habe ich aber immernoch eine Frage:
Bis vor einigen Wochen lief auf meinem Server der alte monitor mit MySQL Plugin. Dazu das hier irgendwo gefundene Webinterface zur Datenbank.

Jetzt habe ich einen neuen Server (mehr Leistung, fast nur VM's) und wollte die Gelegenheit nutzen auf den monitord umzusteigen.
Das hat bis jetzt auch alles geklappt, die Datenbank kann weiterverwendet werden, die Konfig muss halt nur entsprechend angepasst werden. Jetzt fehlt mir jedoch eine wichtige funktion:
In der .monrc konnte man wunderbar filtern. Sprich: RIC's aus dem Bereich, nicht mehr und nicht weniger soll angezeigt werden. In unserem Netz werden z.B. alle 120 Sekunden Testnachrichten verschickt, die allein bringen das Webinterface schon zum überlaufen und ruinieren auch das letzte Stück Übersicht. Programmierung ist leider garnicht mein ding (im entsprechenden Bereich meines Hirns laufen die Synapsen irgendwie ins Leere), daher traue ich mir auch nicht zu da über die Konfig Dateien hinaus durch den Code zu crawlen. Sicher ließe sich das auch im PHP vom Webgui erledigen, aber auch dafür reichts in meinem Kopf nicht... Also: Gibt es eine Funktion nach RICs zu filtern? Wenn ja wo? Ließe sich sowas "schnell" einbinden?


Wenn interesse besteht kann ich gern mehr Infos und Beispieldateien liefern um das (meiner Meinung nach sehr gute) Webinterface zu implementieren.


Gruß,
Bene

Seit kurzem wertet monitord bei mir jeden Status der über 9 geht als Status 0 aus. Egal welche Richtung ob LST->FZG oder umgekehrt.
Hat jemand von euch eine Idee woran das liegen könnte?

hallo,

eine linux anwendung zum dekodieren von POCSAG und co. würde mir gerade wirklich weiterhelfen.

AABER:

svn checkout svn://jhr-online.de/monitor
svn: Can't connect to host 'jhr-online.de': Connection refused

http://grohmann.gmxhome.de/mon/monitor-1.8.1.tar.gz
Error 404 - Not found
Die angegebene Seite konnte nicht gefunden werden.

help!

funktioniert der Monitor mit Kubuntu 9?

Das SVN gibts unter:

http://svn.monitord.de/monitor/

Weitere Infos zu der Entwicklung gibts unter:

http://monitord.de/

wie stabil läuft das ganze denn?

gibts es irgendwo eine installationsanleitung?



ich habe hier noch die monitor 1.8.1 -- irgendwie bekomme ich kein pocsag1200 dekodiert. sollte ich es weiter probieren? oder ist das evtl. garnicht möglich?

Zitat:

---

Zitat von pocfreak

hallo,

eine linux anwendung zum dekodieren von POCSAG und co. würde mir gerade wirklich weiterhelfen.

AABER:

svn checkout svn://jhr-online.de/monitor
svn: Can't connect to host 'jhr-online.de': Connection refused

http://grohmann.gmxhome.de/mon/monitor-1.8.1.tar.gz
Error 404 - Not found
Die angegebene Seite konnte nicht gefunden werden.

help!

funktioniert der Monitor mit Kubuntu 9?

---

Ich habe hier Monitor 1.8.1 auf Karmic Koala laufen und dekodiere POCSAG 512 damit.

Den Source gibt es hier:
http://www.funkmeldesystem.de/downlo....php?i=95&c=10

Gemaked und läuft, Sonderzeichen sind verwurschtelt, da wird man wohl in den Code gehen müssen, Ubuntu rennt ja UTF-8 auf der Konsole...

Ich verstehe nicht wieso so viele immer noch mit der alten 1.8.1er Version ankommen. die SVN Version läuft inzwischen einigermaßen stabil und zuverlässig und ist wesentlich flexibler als die 1.8.1er. Link zu dem SVN: siehe mein Beitrag oben.

Tja, woran könnte das wohl liegen??? Ich persönlich nutze auch noch die alte 1.8.1, weil ich einfach eine Ausgabe haben möchte, ohne dass ich mir noch ein entsprechendes Frontend erstellen muss. Ich möchte auch nicht in eine Datenbank schreiben, sondern nur in Logfiles. Frontends gibt es ja auch noch nicht so sonderlich viele, oder hab ich da was verpasst? Das Debug-Frontend ist ja wirklich nur zum debuggen gut und alles Andere ist doch noch arg in der Entwicklung. Und ein FMS-Crusader oder FMS32 Frontend bekommt man ja nur mit dem entscprechenden Programm käuflich erworben...

Soweit also meine Gründe.

Gruß,
Funkwart

PS: POCSAG 1k2 funktioniert mit 1.8.1 auch gut.

Zitat:

---

Zitat von DocSteel

Ich verstehe nicht wieso so viele immer noch mit der alten 1.8.1er Version ankommen. die SVN Version läuft inzwischen einigermaßen stabil und zuverlässig und ist wesentlich flexibler als die 1.8.1er. Link zu dem SVN: siehe mein Beitrag oben.

---

Nö, ist sie nicht.

Zumindest für POCSAG will ich einfach Meldungen empfangen und ein Skript ausführen lassen. Ich schreib mir doch keinen Client, der Socket-Kommunikation machen muss für so was Primitives? Dafür hab ich im Moment wirklich keine Zeit.

Ja klar, dafür ist monitor 1.8.1 wiederum nicht gut geeignet um im Hintergrund zu laufen, aber das könnte man beheben, indem man die Ausgabe umbaut von diesem bescheuerten ncurses-Zeug auf was Primitiveres.

Allgemein sehe ich:

- Monitor 1.8.1:

aufgesetzt mit configure make make install, .monrc editiert, fertig

- Monitor 1.9:

aufgesetzt - oh, wie? Das fängt bei Links auf nicht mehr existierende svn-Repositories an, geht weiter über ein Wiki im "Wartungsmodus", das mehrere Jahre alte Infos zu einer "Entwicklerversion" liefert, einen Thread hier im Forum, der mehrere hundert Seiten lang ist, keinerlei sonstiger Buildanleitung, Dokumentation, fehlenden Clients und hört da noch lange nicht auf.

Das schöne an der 1.8.1:

- Es ist quasi eine fertige Distribution.
- Man kann sich darüber unterhalten, da andere sie auch verwenden.
- Sie funktioniert offenbar (auch wenn ich weiterhin Startschwierigkeiten habe).
- Sie hat ein Frontend, das mir zeigt, was passiert.
- Es gibt eine Installationsanleitung, die funktioniert.

Ich bin mir sicher, dass der monitord irgendwann soweit sein wird, dass er ebenfalls breiter akzeptiert wird. Aber die Sache ist für mich, und für viele andere wahrscheinlich auch, etwas zu undurchsichtig.

Ich habe noch ein Problem mit der .monrc , bei dem mir vielleicht jemand weiterhelfen kann.

Zum aktuellen Stand: es werden sporadisch Nachrichten, wenn auch unvollständig dekodiert.

Zwei (wichtige) Zeilen in der .monrc sind mir ein Rätsel:

POCSAG:ZEIT8 KANAL 1 NAME22 NUMMER7 FUNC1 Pager

Was genau sagen mir die einzelnen Elemente? Weiß das jemand? In dem Manual steht was von "man kann sich dort etwas zusammenbasteln". Aber was denn??

PAGER ******** [echo %R:%T >> /home/username/testfile.txt] TEST

Müsste hier nicht was in die Datei geschrieben werden? Funktioniert irgendwie nicht. Sieht jemand den Fehler?

Alle paar Minuten gibt es im POCSAG-Netz Testsignale. Diese werden überhaupt nicht erkannt. Werden die irgendwo ausgeschlossen?

Gibts weitere wichtige Einstellungen? Als Grundlage habe ich die .monrc genommen, die automatisch generiert wird...

Erstes Ziel ist: alles einkommende POCSAG1200, egal welche RIC, egal welcher Funktionstyp in die Datei schreiben. Alles andere solle ich dann wohl hinbekommen..

Den richtigen Lautstärkepegel zu finden, ist auch wie immer mühsam.

Naja, wird schon

Bis dann

Also soweit ich das sehe, sind die Zahlen wohl die Länge - und die einzelnen Elemente sind halt die, die dir raussuchen kannst. In der Manpage sollte was stehn, IMHO ist in der .monrc default auch eine zweite POCSAG: Zeile drin mit noch weiteren Elementen.

Das ist doch nun so schwer nicht. Schaut doch mal in die manpage:

Zitat:

---

Zitat von Manpage

5. Formatierung von Zeilen
Die FMS-Formatierung beginnt mit FMS:
Danach kann man sich etwas zusammenbasteln, Wörter wie ZEIT, BOS, LAND,
ORT, KFZ, STATUS, DIR, BST (Baustufe), TKI (Taktische Infos) und KANAL
(Soundkarteneingang) in Großbuchstaben, jeweils gefolgt von einer ein-
oder zweistelligen Zahl für die Länge. Diese werden dann bei der Aus-
gabe ensprechend ersetzt. Die Länge der ZEIT ist konstant, eine Zahl
muss trotzdem angegeben werden. z.B.
FMS:ZEIT8 BOS4 ORT5 KFZ25 STATUS28TKI3 KANAL1

Die ZVEI-Formatierung beginnt mit ZVEI:
Die Wörter ZEIT, NAME, NUMMER, TYPE und KANAL (Soundkarteneingang) -
plus Längenangabe - werden ersetzt. TYPE ist hier die Alarmierungsart
(Melder, Sirene). z.B.
ZVEI:ZEIT8 NAME37TYPE15 NUMMER5 KANAL1

Die POCSAG-Formatierung beginnt mit POCSAG:
Die Wörter ZEIT, NAME, NUMMER, FUNC und KANAL (Soundkarteneingang) -
plus Längenangabe - werden ersetzt. FUNC ist hier der Funktionstyp.
z.B.
POCSAG:ZEIT8 KANAL1 NAME38 NUMMER7 FUNC7 Pager

---

Ich übersetze es Auch dann mal. Mit den Zeilen, die mit FMS:, ZVEI: und POCSAG: beginnen, könnt Ihr festlegen, wie die Meldungen für FMS, ZVEI und POCSAG im Frontend aussehen werden.
Am Anfang der Zeile steht das entsprechende Kürzel mit Doppelpunkt dahinter. Alles was dann kommt, ist Eure Entscheidung. In der hier beispielhaft gezeigten POCSAG-Zeile wird z.B bestimmt, dass bei einem Pocsag Ereignis eine Zeile mit zunächst 8 Stellen Zeitangabe (xx:xx:xx), dann einem Leerzeichen, dann der Kanalbezeichnung (1stellig), dem in der monrc gegebenen Namen zur RIC mit 34 Stellen usw. angezeigt wird. Alles, was kein Codewort (s. Liste) ist, wird als Text ausgegeben. Hier als Beispiel das Wort "Pager" am Ende der Zeile. Beachten: Die Zeitangabe kann zwar weggelassen oder an andere Stelle gesetzt werden, ist aber immer 8 Stellen lang. Der Eintrag für die Zeit lautet also immer "ZEIT8".

Ich hoffe, es ist jetzt klarer...

Gruß,
Funkwart

"das entsprechende Kürzel mit Doppelpunkt dahinter."

"Codewort (s. Liste)"




wo ist diese Liste entsprechender Kürzel menschenlesbar hinterlegt?

hat jemand antworten auf meine anderen Fragen?

Bitte lest doch mal genau, was in der Manpage steht!
Es gibt drei Kürzel für die drei "Ereignisarten":
FMS: für eine FMS-Auswertung,
ZVEI: für eine Fünftonauswertung und
POCSAG: für eine POCSAG-Auswertung.
Was ist daran so schwer zu verstehen???
Bei FMS gibt es dann zur Definition der Ausgabezeile die Variablen ZEIT, BOS, LAND,
ORT, KFZ, STATUS, DIR (Richtung), BST (Baustufe), TKI (Taktische Infos) und KANAL
(Soundkarteneingang).
Bei ZVEI gibt es die Variablen ZEIT, NAME, NUMMER, TYPE und KANAL (Soundkarteneingang).
Bei POCSAG gibt es die Variablen ZEIT, NAME, NUMMER, FUNC und KANAL (Soundkarteneingang).
Die Variablen sind doch selbsterklärend und werden dann im laufenden Programm in der Ausgabezeile durch den entsprechenden Wert ersetzt. Dafür wird so viel Platz (in Zeichen) eingeräumt, wie man selbst vorgibt. Leerzeichen und Buchstaben, die nicht zu einer der Variablen gehören, werden in der Ausgabezeile so ausgegeben, wie sie in der Vorgabe stehen.

Steht doch alles genau so in der Manpage - bitte mal genau lesen.

Danke und Gruß,
Funkwart

PAGER ******** [echo %R:%T >> /home/username/testfile.txt] TEST

Müsste hier nicht was in die Datei geschrieben werden? Funktioniert irgendwie nicht. Sieht jemand den Fehler?

Alle paar Minuten gibt es im POCSAG-Netz Testsignale. Diese werden überhaupt nicht erkannt. Werden die irgendwo ausgeschlossen?

Kann mir jemand Tips für die Pegeleinstellung geben?

Hi zusammen,

2.0-070808-RC1 compiliert hier nicht:

Zitat:

---

root@SERVER2:~/2.0-070808-RC1# make
cd . && /bin/bash /home/thomas/2.0-070808-RC1/missing --run autoconf
aclocal.m4:16: warning: this file was generated for autoconf 2.61.
You have another version of autoconf. It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.
/usr/bin/m4:configure.ac:51: bad expression in eval: use_plugins=${enableval}+0
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 7 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 20 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 27 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 35 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 44 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 47 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 51 > (use_plugins=no)
autom4te: /usr/bin/m4 failed with exit status: 1
make: *** [configure] Fehler 1

---

What the heck ist denn das?

configure lief so:

./configure --enable-plugins --with-mysql

qutoconf:

Zitat:

---

root@SERVER2:~/2.0-070808-RC1# autoconf --version
autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

---

System ist Ubuntu 9.10

Kann mir jemand helfen?

Die Antwort steht doch schon deinem Post drinnen. Du besitzt die autoconf version 2.64 und monitord erwartet die Version 2.61.

Deswegen erscheint auch die folgende Zeile:
aclocal.m4:16: warning: this file was generated for autoconf 2.61.

Eine mögliche Abhilfe steht ja ebenfalls schon in der "Fehler"meldung:
If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'.

Zitat:

---

Zitat von A.Nero

Die Antwort steht doch schon deinem Post drinnen. Du besitzt die autoconf version 2.64 und monitord erwartet die Version 2.61.

Deswegen erscheint auch die folgende Zeile:
aclocal.m4:16: warning: this file was generated for autoconf 2.61.

Eine mögliche Abhilfe steht ja ebenfalls schon in der "Fehler"meldung:
If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically `autoreconf'.

---

autoreconf bricht mit folgender Fehlermeldung ab:

Zitat:

---

root@SERVER2:~/2.0-070808-RC1# autoreconf
/usr/bin/m4:configure.ac:51: bad expression in eval: use_plugins=${enableval}+0
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 7 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 20 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 27 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 35 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 44 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 47 > (use_plugins=no)
/usr/bin/m4:configure.ac:51: bad expression in eval (bad input): 51 > (use_plugins=no)
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

---

Ergo: Da scheint was verwutzt zu sein.

Oh yeah, offenbar falsche Klammersetzung in configure.ac:

damit rennt es:

Code:

---

AC_ARG_ENABLE(plugins,
        AC_HELP_STRING([--enable-plugins], 
        [enable experimental plugin support (default is no)])],
        [use_plugins=$enableval
        plugins=true],
        [use_plugins=no])

---

Vorher stand da

Code:

---

AC_ARG_ENABLE(plugins,
        AC_HELP_STRING([--enable-plugins], 
                                        [enable experimental plugin support (default is no)],
                                        [use_plugins=${enableval}], [use_plugins=no]),
        [ plugins=true
        ])

---

AC_HELP_STRING sieht falsch geklammert aus! Und AC_ARG_ENABLE hat drei Parameter, nicht vier! "plugins=true" gehört doch sicher in den "wenn gesetzt" Parameter....

Noch ein Vorschlag:

die monitord.xml sollte unter UNIX in /etc liegen - man wird ja wohl den monitord als init-Prozess starten und nicht als User..

MonitorConfiguration.cpp:

Code:

---

bool MonitorConfiguration::ResetConfiguration()
{
        int i ;

        m_sMonitordName="default" ;
        m_Daemonize=true ;
        m_ConfigFile="/etc/monitord.xml";
#ifdef WIN32
        m_service_install=false;
        m_service_run=false;
        m_service_uninstall=false;
        m_ConfigFile="monitord.xml";
#endif
        m_crusaderUsername="crusader" ;

---

bekommt jemand dieses

http://www.kb9ukd.com/digital/pocsag12.wav

signal dekodiert?

wenn ja, mit welchem eingangspegel??

das signal lässt sich bei mir unter windows und linux (wine) mit PDW dekodieren.

aber nicht mit monitor.

ich wäre für hilfe echt dankbar!!

Hallo Forum,
hallo Entwickler,

gibt es eigentlich irgendwelche Entwicklungen bezüglich der Dekodierung von POCSAG 1200 Baud? Das letzte Posting, das ich dazu gefunden habe, hatte im Prinzip zum Inhalt: Dekodierroutine geändert, monitord dekodiert 1k2 deutlich schlechter als vorher.
Es ist doch schade, dass ein so universell und fortschrittlich aufgebautes Programm nicht genutzt werden kann, weil eine Komponente nicht tut, was sie soll.
Ich habe leider weder von C++ noch von POCSAG-Dekodierung genug Ahnung, um mich selbst an den Code zu setzen.
Könnte nicht einer der Programmierer die Dekodierroutine vom alten 1.8.1 einbauen und wie bei fms per Tag in der XML-Datei zur Auswahl stellen? Bitte, habt doch ein Herz für die User, die so fürchterlich auf dem Schlauch stehen aktuell!

Vielen Dank und bested Grüße,
Funkwart

Hallo zusammen,

ich habe eben einmal nachgesehen, was da in den Sourcen drin steht:

Code:

---

        bool crccheck=getNodeBool(*pConfig,"crc-check",true) ;
        bool errorcorrection=getNodeBool(*pConfig,"ecc",false) ;
        int minpreambel=getNodeInt(*pConfig,"minpreambel",0) ;
        int maxerrors=getNodeInt(*pConfig,"maxerrors",0) ;
        int algorithmus=getNodeInt(*pConfig,"algorithm",0) ;

---

Das heißt, man kann im POC1200-Bereich der Konfigurationsdatei einstellen:
- crc-check (0/1) (geschrieben: <crc-check> 1 </crc-check>), default true
- ecc (0/1) (Fehlerkorrektur) , default false
- minpreambel (Länge der Präambel), default 0
- maxerrors (maximale Anzahl an Fehlern vor Verwurf des Telegramms), default 0
- algorithm (0/1), default 0/"der alte"

Probier doch mal, den Auswerte-Algorithmus zu ändern (0/1). Es sind derzeit zwei implementiert, 0 ist wohl der alte (aus dem 1.8.1er, so weit ich das sehe), 1 der neue (von Buebchen hier im Forum, wenn ich das richtig zuordne). Ansonsten kann es auch schon deutlich helfen, die "maxerrors" hoch zu setzen (wenigstens auf eins oder zwei); wie sieht denn da Deine Konfiguration aus derzeit?

Viele Grüße
Martin

Hallo Martin,

danke für den Tipp.
Ich hatte auch schon versucht, mich durch den Code zu hangeln und war vor wenigen Minuten genau an der Stelle angekommen. Somit müsste also ein

Code:

---

<algorithm> 1 </algorithm>

---

im Abschnitt poc1200 der monitord.xml den 1.8.1-er Algorithmus wieder aktivieren?!
Standardmäßig (0) wird wohl der neue Algo aktiviert.
Denn:

Code:

---

void MonitorModulePocsag1200::demod(float *buffer, int length)
{
        switch (m_iAlgorithmus)
        {
        case 0:
                demod_mg(buffer, length) ; // war demod_se ...
                break ;
        case 1:
                demod_se(buffer, length) ; // war demod_se ...
                break ;
        default:
                demod_mg(buffer, length) ;
        } ;
}

---

Dann dürfte es ja theoretisch keinen Unterschied zur 1.8.1-Variante auf ein und derselben Hardware kommen, richtig?

Danke und Gruß,
Funkwart

Hallo nochmal,

dem Switch()-Statement und den Namen der Methoden nach müsste 0 und default der alte Algorithmus (mg) sein. 1 als einziger Fall ist der neue (se).

Mit der "Unterschied"-Überlegung solltest Du recht haben: Wenn der Algorithmus 1:1 übernommen wurde, dann müsste bei Parameter "Algorithmus 0" die Auswertung identisch sein.

Genaueres kann Dir da Buebchen sagen, ich habe meine Finger bisher nur im ZVEI-Auswerter gehabt... ;). Aber ich bin gespannt was bei Deinen Versuchen heraus kommt :)!

Viele Grüße
Martin

Der Kommentar

Code:

---

//war demod_se ...

---

legt die Vermutung nahe, dass es sich hierbei um den originalen Algo handelt. Außerdem habe ich bisher nichts in der monitord.xml stehen gehabt. Somit sollte der Default-Algo verwendet werden. Es wird aber bei 1k2 nichts dekodiert, somit vermute ich, dass default = demod_mg = neuer Algo ist.
Ich verstehe schon mg=Martin Grohmann und se=Stephan Effertz, aber dann würde das bedeuten, dass bei mir der Default-Algo, also der alte Algo von M. Grohmann unter monitord nicht tut, während er es unter monitor-1.8.1 nahezu perfekt tut...

VERWIRRUNG!!!

Gruß,
Funkwart

Hallo,

ich habe eben nochmal in die Sourcen auch des 1.8.1-er geschaut. Die "_mg" ist die Methode von Markus Grohmann, beim schnellen Überfliegen augenscheinlich nur angepasst an die C++-Struktur des monitord 2.0. Die _se ist die neue von Stefan. Warum die alte natürlich dann gar nicht tut, ist eine gute Frage... :(.

Ich selber habe leider keine POCSAG-Geschichten genutzt bisher, bei einem Test mit dem Algorithmus 1 tats aber (BOS-Tool -> Aufnahme Stereomix) gerade. Vielleich reicht der Pegel da bei Dir für die Auswertung mit dem monitord nicht (oder ist zuviel)?

Martin

Den neuen Algo habe ich noch gar nicht ausprobiert. Ich wusste ja nicht, dass es zwei verschiedene Algos gibt und habe den Standardmäßigen (also den mg-Algo) genutzt. Ich denke mal, in 512 wird der auch genutzt, oder? Dort funktioniert er nämlich einwandfrei. Nur bei 1k2 nicht. Vielleicht ist ja ein Bug drin?!?
Ich werde heute Abend mal den 1er (also den von Stefan) probieren.
Ich berichte...

Danke und Gruß,
Funkwart

Moinmoin,

nach weiteren Blicken in den Code... ;):

pocsag-modul: default = 0 (mg)
poc512: default = 1 (se)
poc1200: default = 0 (mg)

Im 512er wird also idR das neue, im 1200er das alte Auswerte-Codestück genutzt. Der "globale" default-Wert in der POCSAG-Basisklasse wenn man sie so nennen will, ist 0 (mg), der wird aber durch die Klassenhierarchie dann überladen. Sollte er jedenfalls ;). Ist der algorithm-Wert in der monitord.xml explizit gesetzt, hat der eh gewonnen.

Für FMS gilt übrigens: 0 (mg) ist der Standard, hier heißt das Feld in der Konfigurationsdatei allerdings "algorithmus" (bei POCSAG "algorithm")! Bei Algorithmus 1 gibts wieder eine Neuentwicklung "_se", die scheinbar besser tut, wenn man dem Grundrauschen hier im Forum Glauben schenken kann ;).

Viele Grüße
Martin

Moin Martin,

danke für Deine Mühen mit dem Code.
So detailliert hatte ich das nicht herausgelesen. Leider haben meine Tests nicht so ein wirklich gutes Ergebnis gebracht.
Ich habe beim Blick in den Code auch festgestellt, dass der Grohmann-Algorithmus wirklich fast 1:1 übernommen wurde. Was ich jetzt nicht begreife, ist, dass er mit monitor-1.8.1 hervorragend bei poc1k2 tut, mit monitord überhaupt nicht. Gleiches Gerät, gleiche Soundkarteneinstellungen etc. Zusätzlich blöde: Auch der SE-Algorithmus funktioniert keinen Deut besser. Mir kam es schon so vor, als ob das Auswählen des Algos überhaupt keinen Effekt hat... Vielleicht ist es ja so?! Ich habe in der monitord.xml folgende Eintragung stehen:

Code:

---

        <module type="poc1200">
                <crc-check> 1 </crc-check>
                <ecc> 0 </ecc>
                <algorithm> 1 </algorithm>
        </module>

---

Sowohl mit "0", als auch mit "1", als auch ohne die Zeile für den Algo kommt immer das Gleiche dabei heraus: Die Feldstärke-RIC wird als RIC korrekt erkannt, liefert aber keinen Text mit, obwohl monitor-1.8.1 immer [i]<EOT><DLE>[/] bzw. [i]<NUL><DLE>[/] dekodiert.
Wenn eine "normale" Nachricht kommt, wird eine völlig andere RIC dekodiert, aber ebenfalls kein Text. Dieses Verhalten ist mit beiden Varianten in der monitord.xml identisch. Sehr merkwürdig!

HILFE!!!

Danke und Gruß,
Funkwart

Hallo Funkwart,

schreib bitte probehalber den "<maxerrors> 3 </maxerrors>" dazu. Nur um auszuschließen, dass er gleich alles unterdrückt sobald er einen Fehler bei der Decodierung findet...

Hast Du mal versucht, z.B. mittels BOSTool etwas "zu senden" und das zu decodieren? Wenn das gehen sollte, könnte es an Eingangspegeln oder soetwas liegen; irgendwelche Pegel-Minima könnten da "reinhauen".

Ansonsten fürchte ich, müsste man genauer schauen, was der Auswerter wann wo findet und verarbeitet... da fehlt mir aber momentan der Durchblick; wie gesagt habe ich bisher nur im ZVEI-Code rumgefingert, auch in Sachen Debugging.

Viele Grüße
Martin

Hallo Martin,

die Sache scheint doch etwas tiefer zu gehen.
<maxerrors> bringt beim Algo 0 (default) nur mehr Falschauswertungen, trotzdem keine übermittelten Nachrichten. Bei Algo 1 bringt es gar nix. Keine Auswertungen.
Ich habe mal auf einem Windows-Rechner den minitord installiert, bos-tool dazu und getestet. Auch dort wird 512Baud perfekt, 1200 Baud gar nicht dekodiert. Sogar noch grottiger als auf Linux.
Ich vermute das Problem irgendwo in einem Bug in der 1k2-Dekodierroutine.
Ich habe nur wirklich absolut nicht genug Ahnung, um dazu etwas zu finden. Könnte höchstens mal einen zeilenweisen Vergleich zwischen 1k2 und 512 anstellen, aber ob das was bringt.

Gruß,
Funkwart

---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---

Ich habe tatsächlich mal die MonitorModulePocsag512.cpp und die MonitorModulePocsag1200.cpp miteinander verglichen und festgestellt, dass es einige Unterschiede gibt. Zwar kann man für die 512er Variante auch in der xml den Tag <algorithm></algorithm> formulieren, daraus folgt aber keine Entscheidung für einen Algorithmus - obwohl beide im Code vorhanden sind.
Weiterhin gibts in der 512er Variante noch einen großen Abschnitt, in dem ein IIR Filter programmiert wurde. Den gibts in der 1k2er Variante nicht.
Das erst einmal als grober Vergleich der beiden Versionen.

Zitat:

---

Zitat von funkwart

Moin Martin,

Die Feldstärke-RIC wird als RIC korrekt erkannt, liefert aber keinen Text mit, obwohl monitor-1.8.1 immer [i]<EOT><DLE>[/] bzw. [i]<NUL><DLE>[/] dekodiert.
Wenn eine "normale" Nachricht kommt, wird eine völlig andere RIC dekodiert, aber ebenfalls kein Text. Dieses Verhalten ist mit beiden Varianten in der monitord.xml identisch. Sehr merkwürdig!

HILFE!!!

Danke und Gruß,
Funkwart

---

Hallo zusammen,
habe ähnliche Probleme mit dem lieben poc1200. Wenn ich mit BOS-Tool per Klinke vom Notebook in den Server sende ist die Auswertequote bei so ca. 66%, RIC wird erkannt und Text auch vollständig. Wenn ich dann per Empfangsgerät und riesen Antenne dekodiere, z.b. von unserem Testsender aus dekodiert die Sau die Rics in fast 75% richtig, jedoch ohne Text. Das ist schwer nervig...
Nächstes Ding: wenn man auf DEBUG loggt bekomme ich immer von der MonitorModulePocsag.cpp ein "Sync gefunden (line 165)"
Dies passiert wenn ich mit dem Sender sende oder "normal" empfange, allerdings auch wenn weder ne RIC noch irgendwas anderes erkannt wird.

Ich hoffe es wird langsam besser, weil so, alles in allem ist der monitord schon schwer cool geworden...
Gruß rhein-erft

Nach einer recht langen Pause tut sich ja doch wieder was zum monitord. Bisher habe ich aus purem Eigennutz primär den 512 Baud Algoritmus optimiert. Gerade was den IIR angeht weiß ich nicht so recht, ob der bei 1200 Baud auch noch so gut funktioniert. Werde ich wohl mal testen müssen.

Werd mal nen Checkout machen und sehen, was ich mit BOSTool so aus 1200 Baud rausholen kann. Der 1.8.1 Algo ist ziemlich verstrickt gewesen. Da waren mitten drin dann auch mal Textausgaben und sowas eingeflochten. Das hatte ich soweit entheddert, daß der Auswerter von der Ausgabe selbst getrennt ist.

Was ich mal im laufe der nächsten Tage testen werden: IIR auf 1200 Baud ausprobieren. Und mal sehen, wo sich ggf. das Original und die 2.0-Version von (MG) unterscheiden.

Edit:
Das "Sync gefunden" hatte ich eingebunden um zu sehen, ob es Probleme gibt beim Einschwingen auf den Bit-Takt. Das ist doch recht empfindlich. Manchmal waren die Geschwindigkeitskorrekturen so groß, daß der PLL sinngemäß direkt wieder ausgerastet war. Dann wurde natürlich nix mehr erkannt.

Ein SYNC leitet immer eine Aussendung ein. Danach käm dann ein Adresswort und ggf. Datenwörter für den Inhalt.

Tach zusammen!

Folgendes mal als Hinweis:

Ich lese hier arbeiten doch einige mit dem POCSAG-Teil des BOS-Tools zum Testen der Auswerter.

Leider hat das BOS-Tool in der letzten Version ein Timing-Problem. Das Ausgleichen der Rundungsfehler funktioniert nicht richtig, das komplette POCSAG-Signal ist etliche Millisekunden kürzer als es sein müsste.

Im Detail:

Bei einer Samplefrequenz der Soundkarte von 44100 Hz und einer Baudrate von 1200 Bps hat ein Bit die Länge von 36,75 Samples. Das runde ich auf 36 und summiere den Rest von 0,75 auf. Jedes Mal, wenn dieser Rest > 1 wird, füge ich ein Füllsample ein. Das klappt beim BOS-Tool nicht. Dort ist jedes Bit nur exakt 36 Samples lang.

Die Abweichung in Samples ist also:

AbweichungSamples = (nBits * 0,75)

Dann kann man auf die Millisekunden umrechnen.

Ich stell euch demnächst mal einen korrigierten POCSAG-Geber zur Verfügung.

Gruß Joachim

Zitat:

---

Zitat von MiThoTyN

Bei einer Samplefrequenz der Soundkarte von 44100 Hz und einer Baudrate von 1200 Bps hat ein Bit die Länge von 36,75 Samples. Das runde ich auf 36 und summiere den Rest von 0,75 auf. Jedes Mal, wenn dieser Rest > 1 wird, füge ich ein Füllsample ein. Das klappt beim BOS-Tool nicht. Dort ist jedes Bit nur exakt 36 Samples lang.

---

Moin,

das heißt mit 48.000 Hz müsste es gehen weil das genau 40*1200 ist?

Das würde auch gehen.

Aber nichts desto trotz müsste ich das in der Programmierung des BOS-Tools ändern. Bei 48 Khz bin ich mir aber nicht sicher, ob es nicht noch Hardware gibt, die das nicht unterstützt. Ich tendiere da eher wie besprochen dazu, die fehlenden Samples auszugleichen. Das würde auch bei Sampleraten von 11025 und 22050 noch funktionieren.

Wie auch immer, ihr bekommt demnächst eine Version, mit der die Timings richtig sind.

Gruß Joachim

Es gibt ja auch noch folgendes Programm zum En- und Decodieren:
http://www.dsp4swls.de/sorfmon/sorfmon.html

Weiß hier zufällig jemand, wie die Decodierung in PDW, zu finden unter http://www.gsm-antennes.nl/PDW/ funktioniert?

Ich habe das mal testweise installiert und bekomme exorbitante Auswertungsergebnisse. Leider aber eben ein Windoof-Programm und nicht monitord ;-)

Das Ganze kann auch noch FLEX und ACARS. Wenn man das bei monitord mit drin hätte, hätte man sicherlich auch eine gute Unterstützung von Programmierern aus den Niederlanden...

Nur so als Anregung.

Gruß,
Funkwart

Hallo zusammen,

ich hoffe, ich bin hier nicht ganz off-topic, da ich den monitord 2.0 nutze. Leider haben wir hier massive Probleme bei der Pocsag 512 Auswertung auf einem Debian System.

Derzeit hängen zwei Scanner (2m/4m) an dem Line-In der Soundkarte (wobei am Mic das gleiche Verhalten auftritt) und bei der digitalen Alarmierung brechen die Meldungen immer nach ca. 24-30 Zeichen ab. Es kommt also keine Nachricht vollständig an.
Inzwischen bin ich hier so einige Vorschläge durchgegangen: Pegeleinstellungen kontrollieren (über alsamixer, div. Pegel durchprobiert), maxerrors auf 5 bzw. 6 erhöht, crc und ecc Einstellungen verändert, etc. Leider brachte bisher alles nichts.
Wenn ich auf einem anderen System eine Nachricht generiere und direkt über Kabel auf dem Server in die Soundkarte einspeise wird die Nachricht vollständig und korrekt dekodiert und in die DB geschrieben.

Hänge ich die Scanner an einen anderen Rechner (Win XP, monitord 2.0) werden alle Nachrichten vollständig und korrekt dekodiert. Das bedeutet, dass das Signal der Scanner eigentlich "gut" sein sollte. Warum hakt es dann auf dem Debian-System?

Hat jemand evtl. noch einen heißen Tipp? Ich bin über jeden Vorschlag dankbar, da ich im Moment keine Ideen mehr habe. Vielen Dank für die Mühen im voraus.

Gruß, Bastian.

Nur mal als kleine Anregung: Probiere doch bitte einfach mal den monitor-1.8.1 aus. Lässt sich ohne Weiteres parallel installieren (nur nicht gleichzeitig nutzen). Versuche dort mal die Dekodierung. Wäre interessant zu wissen, wie es da aussieht und ob sich daraus Rückschlüsse ziehen lassen. Bei mir z.B. funktioniert POC1200 auf monitor-1.8.1 ohne Probleme und astrein, mit monitord geht nix!

Gruß,
Funkwart

Vielen Dank für den Tipp. Werden wir mal antesten und dann werde ich berichten. Wäre zu schön, wenn das die Probleme beseitigen würde. :-)

Moin,

Zitat:

---

Zitat von Thorongil

Noch ein Vorschlag:

die monitord.xml sollte unter UNIX in /etc liegen - man wird ja wohl den monitord als init-Prozess starten und nicht als User..

---

klingt schlüssig an sich. Wäre ich dafür. Gegenstimmen ;)?

Viele Grüße
Martin

Zitat:

---

Zitat von mdi

Gegenstimmen ;)?

---

Na, wenn Du so fragst... :)

1) @sysconfdir@ (autoconf standard, default=${prefix}/etc, das verbiegen die paketbauer dann je nach gusto)
2) da wo die exe liegt (so richtets z.B. der windowsservice ein)
3) da von wo aus der monitor gestartet wird

Gruß,
Karl

PS: am schönsten fände ich gar keine externe konfig sondern eine embedded db für protokoll, konfig und ein paar funktionen die anders nicht so einfach umzusetzen sind

Hallo, ich habe nun nach einigem versuchen und lesen den monitord auf meinem ubuntu Rechner laufen. Ich sehe im Logfile das auch Meldungen rein kommen und meine das alles soweit gut aussieht. Nur leider weigert sich die Software beharlich die Meldungen in meiner SQL Datenbank zu speichern. Alle Tabellen sind eingerichtet, der Benutzer hat passende Berechtigungen aber es passiert nix. Habe die orginal Konf. aus dem Handbuch genommen und danach alles aufgesetzt.
Hat jemand eine Idee was ich tun muss damit die Daten in der DB landen?

Moinmoin,

Zitat:

---

Zitat von xjoergw

Hat jemand eine Idee was ich tun muss damit die Daten in der DB landen?

---

setz mal das mySQL-Plugin auf "DEBUG" und schau, was im mysql-Logfile steht. In der Regel sollte das helfen :).

Martin

Hallo,
hab es inzwischen hin bekommen. In der Konfig. war eine .dll eingetragen, was unetr Linux natürlich nicht geht.

Zitat:

---

Zitat von mdi

Moinmoin,



setz mal das mySQL-Plugin auf "DEBUG" und schau, was im mysql-Logfile steht. In der Regel sollte das helfen :).

Martin

---

Ich habe nun den monitord soweit am laufen das ich pocsag Alarme rein bekomme. Dazu benutze ich die 1200Baud variante. Wie gesagt die Alarmierungen bekomme ich, monitord schreib die auch in die mysql DB, soweit alles prima. Nur das wichtigste, die Alarmtextmeldung die fehlt immer. Hat jemand eine Idee woran das liegt. Alarmeirungen ans sich kommen alle rein, nur die Textmeldungen fehlen immer komplett. Leider sind genau diese Textmeldungen der Kernpunkt um den sich am Ende alles dreht. Ich habe schon mit den Parametern aus der Config gespielt CRC rein und raus..., Anzahl Fehler rauf und runter , hat alles nichts gebraucht. Habe auch schon die Sampelrate im POSAG1200 Modul verändert, alles ohne Erfolg.
Hat noch jemand eine Idee wie ich die 1200Baud sauber ans Laufen bekomme?

Vielen Dank schon einmal
Jörg

Moin,

ich habe im BTS den Bug #274 zum selben Thema. Bisher habe ich da nicht weiter drauf geschaut mangels Zeit und weil den POCSAG-Teil nicht geschrieben habe. Ich werfe mal ein Auge.

Edit: Auge geworfen, ich habe den Fehler so mit dem BOS-Tool leider nicht nachvollziehen können. Bei mir wird der Kram so weit ausgewertet und landet in der DB; ist sicher dass ein Text gesendet wird und wie sieht Deine mySQL-Konfiguration aus? Passen die Datenbank-Felder zum POCSAG-Inhalt?

Viele Grüße
Martin

Hi,
war im urlaub deshalb erst jetzt die Antwort. Sicher ist das Texte mit gesendet werden. Anders als ich es aber vermutet habe, werden die geamten nachrichten nicht gespeichert. Also, Alarmierungen ohne Text kommen an/durch, die mit text werden komplett verworfen.
An der DB denke ich liegt es denke ich nicht. Das habe ich X-Fach kontrolliert. Ich hatte den CRC Check im verdacht, der war es aber auch nicht.

Zitat:

---

Zitat von mdi

Moin,

ich habe im BTS den Bug #274 zum selben Thema. Bisher habe ich da nicht weiter drauf geschaut mangels Zeit und weil den POCSAG-Teil nicht geschrieben habe. Ich werfe mal ein Auge.

Edit: Auge geworfen, ich habe den Fehler so mit dem BOS-Tool leider nicht nachvollziehen können. Bei mir wird der Kram so weit ausgewertet und landet in der DB; ist sicher dass ein Text gesendet wird und wie sieht Deine mySQL-Konfiguration aus? Passen die Datenbank-Felder zum POCSAG-Inhalt?

Viele Grüße
Martin

---