monitord auf Linux / Auswertung verbessern?

Moin,

habe auf einem Linux Server monitord laufen. Dazu ein normaler Handscanner mit Diskriminator und Aussenantenne. 1a Verkabelung und Empfang und es geht NUR um die FMS Auswertung und Anzeige.

monitord schreibt das dann in eine SQL Datenbank auf dem Server (lokal) und eine lokale PHP Datei liest dem Kram wieder aus und zeigt ihn an.

Nun zum Kern:

Nun habe ich da wohl bei monitord ein Problem mit der AUSWERTUNG. Trotz prima Empfangsanlage (gute Kabel, gute Antenne, Diskriminator) fehlen in der Auswertung immer mal wieder Telegramme bzw Quittungen.
In der angefügten Datei kann man das exemplarisch ganz gut erkennen.

Anbei auch noch ein Ausschnitt aus der monitord.xml. Wenn man in der xml Datei allerdings die Parameter für die Auswertung noch lockerer gestaltet werden soviele ""Fehlauswertungen" in die Datenbank geschrieben, dass diese in die Knie geht (>10000 DS). Das kann nicht die Lösung sein.

Kann man da irgendwo anders noch die Einstellungen optimieren um die Auswertung zu verbessern?

-andere Soundkarte?
-Samplingrate in der xml ändern?
-mehr Hauptspeicher?

Schönen Gruß

Stephan

€dit by Mod.:
Bildanhang "Bild1.jpg" entfernt.
Bitte keine Screenshots mit sichtbaren Rufkennungen anhängen.

Die kurze Antwort:

Vermutlich kannst Du nicht mehr viel anhand der Parameter verbessern. Es wäre noch möglich mit dem Soundpegel zu spielen. Die Samplerate ist mehr als ausreichend für die Baudrate von FMS.

Die lange Antwort:

Mit dem FMS Algorithmus habe ich mich bisher noch nicht näher befasst. Der ist im Kern unverändert übernommen worden. Dennoch sind mir schon einige Schwachstellen aufgefallen, die zu Problemen führen können (sofern ich den Algo richtig verstanden habe):

Die Bittaktsynchronisation erfolgt nach meinem Eindruck anhand von 0->1 und 1->0 Übergängen. Das ist bei FMS natürlich nicht so sehr sinnvoll, daß der Vorlauf aus einer Folge von einsen besteht. Der wird also zur Bittakt-Sync nicht genutzt.

Damit beginnt eigentlich das Einregeln erst beim Sync-Wort. Wenn er da aber aufgrund von Zufällen ungünstig einschwingt geht der Anfang verloren und damit die gesamte Übertragung.

Im Moment versuche ich erstmal die POCSAG Auswertung zu optimieren. (Rein persönliches Interesse). Aber auch FMS wäre es wert. Die ZVEI Auswertung ist nach meinem Verständnis schon sehr gut.

Da POCSAG und FMS sich grundlegend unterscheiden die die Daten übertragen werden kann ich nur wenige Erkenntnisse aus dem POCSAG Sync auf den FMS Teil übertragen. Aber vllt. findet sich ja jemand, der sich das im Vorfeld schon mal angucken kann/will.

Der zweite verfügbare Algo basiert auch auf dem 1/0 Unterschied, oder? Das würde dann wohl auch nichts bringen.

Besteht die Chance, dass Du Dir die Tage mal den speziellen Teil des Algo vornimmst und mal schaust ob da was zu drehen ist?

Schönen Gruss

Stephan

Also "die Tage" wird schwierig. Das ist eine relativ grosse Änderung. Und den POCSAG Teil will ich vorher fertig machen.

Ich muss auch erstmal sehen, welcher Phasendetektor bei nem Software-PLL für ein FSK Signal am besten passt und das implementieren. Vom Low-Pass-Filter ganz zu schweigen. In der Dimensionierung solcher Bauteile habe ich wenig Erfahrung. Bei Zeiten schau' ich da rein. Aber Zeit ist wie bei so vielen ein knappes Gut :(

Ich hab' mal versucht aus dem rtty Projekt den decoder in den FMS Teil einzubinden. Mit dem BOS Tool schon ganz brauchbare Ergebnisse.

Ich hab das ganze - obwohl nicht sehr weit getestet - mal ins svn eingestellt (357). Einfach mal testen, ob es damit unter realen Bedingungen besser geht. Naja. Erstmal ob es unter linux überhaupt baut :)

[edit] Das ganze also algorithmus 1 in der monitord.xml konfigurieren. Sonst wird der alte algorithmus genutzt.

[edit2] maxerrors ist dann vollkommen egal. Syncbits irgendwo zwischen 8 und 12 ist ganz gut. Je grösser syncbits ist, desto früher muss die Rauschsperre öffnen. Sonst "verschluckt" die Rauschsperre des FuG's die ersten Bits. Aber mit 8 sollte es auf jeden Fall gehen.

[edit3] das Projekt heisst rtty. Nicht mrtty wie ich vorher schrieb. Hier zu finden: http://bellota.ele.uva.es/~jesus/rtty/

Moin,

Ich habe noch ein anderes FMS-Problem.
Bei uns fahren Fahrzeuge mit der Ortskennung "A1" rum und deren FMS wertet weder die alte Monitor-Version 1.8.1, noch der neue monitord aus. Hänge ich parallel zum Monitord-PC einen FMS32-PC an den Scanner, kann ich auf dem FMS32-Rechner die Statusmeldungen der "A1"-Autos sehen.

Warum kann der Monitor diese FMS nicht auswerten?

Falls sich der Fehler finden läßt, wäre ich auch für einen Fix der Version 1.8.1 dankbar. Die läuft hier immer noch völlig zuverlässig auf zwei Rechnern mit der Bosix-CD im 24*7-Betrieb.

Andreas

Kannst ja mal versuchen, was der aktuelle build aus dem svn zu diesem Sonderfall sagt. ( Algorithmus auf 1 stellen in der monitord.xml). Bei mir wird das in nahezu gleicher Qualität wie bei FMS32 ausgewertet. Bei schlechtem Empfang manchmal sogar noch ein Telegramm mehr.

Warum das am Code liegen sollten verstehe ich spontan nicht. Aber ich schliesse es natürlich erstmal nicht aus :)

Zitat:

---

Zitat von Buebchen

Kannst ja mal versuchen, was der aktuelle build aus dem svn zu diesem Sonderfall sagt.

---

Der compiliert bei mir nicht.

Für mich wäre es momentan echt wichtig, dass die alte 1.8.1-Version die Codes anständig dekodiert. Damit läuft ein wichtiges Projekt, welches monitord mangels passendem Frontend auch nicht ersetzen kann.

Ich haben den Fehler nachvollzogen auf Bosix (Knoppix 3.9 mit monitor 1.8.1) und Ubuntu 9.04 32-Bit mit 1.8.1

Folgendes funktioniert:
Kennungen mit Buchstaben im Landescode wie:
6Dxxx401
decodiert 1.8.1 ohne Schwierigkeiten

Buchstaben im Ortscode gehen nicht:
639C0xxx (Kennung für Werkfeuerwehr)
93A171xx (Kennung für ehrenamtliches BRK-FZ der Leistelle Erding).

Könnte da vielleicht mal jemand in den alten FMS-Decoder-Quellcode schauen -- so komplex kann der Fehler eigentlich nicht sein.

viele Grüße,
Andreas

Ich werde mal einige Kennung per BOS-Tool generieren und schauen, was passiert.

Da das compilieren zur Zeit nicht immer mag (falls einer mal ein logfile zum build hätte wäre das toll) habe ich im svn rev. 373 mal das configure eingestellt, daß ich unter ubuntu erstellt habe. Vielleicht macht das ja einen unterschied. Unter win32 habe ich mal die libtools auf Version 1.5 geupdated.

Beim Erstellen der dlls für mysql gab es da sonst Beschwerden vom libtool, es würde die mysql.dll nicht finden.

Zum Thema Ortskennungen mit Buchstaben. Laut TR-BOS sind m.E. Buchstaben im Ortscode nicht zulässig. Zumindest in meiner Fassung sind Ortscodes nur dezimal, nicht hexadezimal zulässig. Deswegen werden diese auch durch das Regelwerk des monitor ausgefiltert.

Zu finden ist das in der fms.c (bzw. MonitorModuleFMS.cpp):

Code:

---

int fms_rules(struct l1_state_fms sfms) {

        /*        ungültige Telegramme:
        *        Ort        : > 9* && > *9
        *        BOS        : 0        */

        if (*sfms.fms->ort > 9)                return 0;
        if (sfms.fms->ort[1] > 9)        return 0;
        if (*sfms.fms->bos == 0)        return 0;
        return 1;
}        /*        rules

---

Wenn Du aus der 9 ein 0xf machst wird er auch die nicht TR-konformen Telegramme ausgeben.

Zitat:

---

Zitat von Buebchen

Laut TR-BOS sind m.E. Buchstaben im Ortscode nicht zulässig.

---

Vielleicht ist das mal wieder einer der vielen Sonderwege der Bayern :-(
aus: fms_kenng_fw_anl1.pdf (Richtline für FMS Feuerwehr in Bayern von www.stmi.bayern.de)

Code:

---

                    Block 2    Block 3    Block 4  Block 5 
...
Regierungen            3        1 mit 7        F          F
StMI                    3          0          F          F
SFS                    3        0, B, E        E          F
Werkfeuerwehr    wie entsprechende Gemeinde  C und D    0 mit F

---

das ergibt für die erste Werkfeuerwehr im Landkreis den Code 639C0xxx

fms_kenng_rd_anl3.pdf (Richtline für FMS Rettungsdienst in Bayern von www.stmi.bayern.de)

Code:

---

Ortskennungen der
Rettungsdienstbereiche
RDB              öff./rechtl. org.-eigen
Erding                11        A1
Fürstenfeldbruck      12        A2
Ingolstadt            13        A3
München                14        A4
München-Land                      A8
....

---

Somit funken HvO-Fahrzeuge und sonstige ehrenamtliche Retter im Bereich Erding mit 93A1xxxx

Dies bitte bei der weiteren Entwicklung des FMS-Dekoders berücksichtigen. Bayern setzt Hex-Ziffern im Ortscode ein.

Zitat:

---

Zitat von Buebchen

Zu finden ist das in der fms.c (bzw. MonitorModuleFMS.cpp):
Wenn Du aus der 9 ein 0xf machst wird er auch die nicht TR-konformen Telegramme ausgeben

---

Probiere ich sofort aus und gebe dir eine Rückmeldung

viele Grüße,
Andreas

Zitat:

---

Zitat von Buebchen

Wenn Du aus der 9 ein 0xf machst wird er auch die nicht TR-konformen Telegramme ausgeben.

---

Perfekt!

Probiert mit monitor-1.8.1 unter Ubuntu 9.04 x32.
Funktioniert bestens.

Jetzt muss ich das überarbeitete Binary nur noch irgendwie auf meine Bosix-Live-CD drauf bekommen.

Danke,
Andreas

Hab mal im svn die Codes a-f auch zugelassen.

Zitat:

---

Zitat von nepomuck

Probiert mit monitor-1.8.1 unter Ubuntu 9.04 x32.
Funktioniert bestens.

---

Zweite positive Rückmeldung:
Build 373 läuft problemlos durch den Compiler. Nur das .configure-Skript musste ich von Hand auf executable setzen.

-> svn up; chmod +x configure; make clean; ./configure --enable-plugins und make.

(Lame und MySQL-Plugin habe ich nicht mitübersetzt.)

Kennungen mit Hex-Code werden anstandslos dekodiert. Wobei Algorithmus 1 auf meiner Kiste deutlich bessere Ergebnisse abliefert, als der Default 0.

System: IBM Thinkpad T43p, Ubuntu 9.04.

viele Grüße,
Andreas

Zum Algorithmus 1 kann ich auch nur sagen, daß er bei mir eindeutig besser läuft.

Die Filter und der angepasste PLL bringen da einiges. Ich habe hier nur sehr schlechten FMS Empfang. FMS32 schweigt sich da bei mir fast ganz aus. monitord mit den neuen Algorithmus hört da schon besser hin. Auch den fms-Text von der M.Grohmann / monitor 1.x Seite wertet der neue Algorithmus bei mir besser aus.

Ggf. versuche ich den mal in den 1.8.1 reinzuquetschen.

Zitat:

---

Zitat von Buebchen

Ggf. versuche ich den mal in den 1.8.1 reinzuquetschen.

---

Wäre toll.
Die 1.8.1 (auf Bosix) unterstützt sehr aktiv die KBI bei der FMS-Einführung für die Feuerwehren in meinem Landkreis. Damit merzen wir falsch programmierte Fahrzeugkennungen noch vor dem offiziellen IlSt-Start aus.
Daher muss ich auch so dringend die Werkfeuerwehr-Kennung dekodieren können.

viele Grüße,
Andreas

Eine neue Bosix-Version mit einer "classic 1.8.2" mit den genannten Verbesserungen wäre toll!
Gibt es eigentlich auch schon eine Bosix-Variante mit dem monitord?
Bei mir will der nicht wirklich laufen. Erst hatte ich übelste Probleme, zu kompilieren, jetzt hat er compiliert, wertet aber nullkommanix aus... Unter Windows das Binary läuft hervorragend.

Danke und Gruß,
Funkwart

Eigentlich ist der monitord ja noch übelst alpha-stadium. Aber dieser hack ist da noch übler :)

Die kannst in der MonitorModulePOCSAG.h mal das #ifdef POCDEBUG anschmeisen. Der monitor macht dann im POCSAG Modul ne RAW Aufnahme dessen, was er da so präsentiert bekommt. Kann ja sein, daß es ein Problem im Audiosubsystem ist.

Die Aufnahme läuft so lange das POC512 / POC1200 Modul ausgeführt wird (also ständig). Die Datei wird auch dementsprechend gross. Aber um zu sehen, was da überhaupt ankommt ist das sehr hilfreich.

Die Datei heiss _in.raw und kann z.B. mit Audacity Importiert werden (Rohdaten). Format: 32bit float, Sample-Rate 22050. Ich nehm immer little-endian. Mono. Dann ist zumindest mal sicher, daß die richtige Aufnahmequelle eingestellt ist :)

[EDIT]
Thema 1.8.2 classic Variante. Die Ergänzung der Ortscodes ist kein Thema. Das Anpassen des Algorithmus dann schon. Naja. Werd' da am WE mal weiter schauen. Ich kann noch nichtmal sagen, was da genau nicht geht. Aber geht auf jeden Fall noch nicht :)

Zitat:

---

Zitat von funkwart

Eine neue Bosix-Version mit einer "classic 1.8.2" mit den genannten Verbesserungen wäre toll!

---

Die wird es geben, da ich die selber dringend brauche. Ich warte jetzt nur noch, ob Bübchen den Algo-1-Code in die 1.8.1 einpflegen kann.
Dann baue ich eine Bosix 0.2 mit den FMS-Korrekturen aber mit der alten Sox-Parametrierung. Das Ganze packe ich wieder auf Basis der Knoppix 3.9, die hat sich als Plattform bewährt und läuft über 200 Tage ohne Probleme (never touch a running system).
Als Bosix-Bugfixes integriere ich einen Automount für den ersten gefundenen USB-Stick als /home/knoppix und die automatische Ausführung eines "bosix.sh", falls so etwas auf dem USB-Stick vorhanden ist.

Zitat:

---

Zitat von funkwart

Gibt es eigentlich auch schon eine Bosix-Variante mit dem monitord?

---

Nein, weil sich fast täglich der Build ändert. Mit der monitord-Bosix warte ich auf einen stabilen Build.

viele Grüße,
Andreas

OK, klingt doch alles super! Auf den geänderten Algo bin ich auch schon gespannt. Ich probiere den auch gerne "schnell mal" ohne Bosix aus, abe Bosix ist schon ne feine Sache.
Dass die weiteren "Bugfixes" (sind ja eigentlich keine) mit reinkommen, finde ich super!

Danke und Gruß,
Funkwart

Der neuere Algorithmus mag noch nicht so richtig laufen, wie ich mir das vorstelle. Ist aber soweit schon mal ins alten Konstrukt eingehäkelt. Erstmal ein wenig warten und dann nochmal aufmerksam lesen, was ich wohl noch falsch gemacht habe. Man wird ja doch ein wenig "blind" wenn man da zu oft draufschaut.

Also der Debug output sieht bei mir so aus:

den original input habe ich mehrfach verstärkt, damit der dementsprechend siehtbar ist. Ich habe das Problem, dass auf meinem PC (Laptop, winXP) nichts decodiert wird. Erzeugen tue ich die Nachrichten mit dem POCSAG Encoder von www.dsp4swls.de.

Ich wollte mir mal ein paar Sachen im monitord anschauen und versuchen zu verstehen... ab und zu erkennt er auch noch 1 oder 2 SYNCs das wars dann aber auch.

Grund des ganzen ist, dass auf meinem Linux System Nachrichten immer nur halb, bzw sehr schlecht decodiert werden. Aus diesem Grund war ich dabei mir eine Testumgebung aufzubauen. Mit mäßigem Erfolg, zur Zeit.

Wie testet ihr denn die Funktion, und Algos?

Vermutlich hast du die Komponenten schon zuordnen können. Für die anderen noch kurz zur Erklärung:

_in: Das aufgezeichnete Signal

_trigger: Der Flankendetektor, der im _in nach 0/1 Wechseln sucht = Zacken nach oben. Die Zacken nach unten tauchen immer dann auf, wenn eine 1 oder 0 dekodiert wird (1=lange Zacke, 0=kurze).

_takt: der interne Takt des PLL (sozusagen der Takt mit dem der monitord auswertet) - der sollte sich mit dem trigger Signal an das _in anpassen

_pfd: Der Phasendetektor-Output. Je grösser das ist, des weiter ist Takt vom Referenzsignal entfernt (_trigger) und umso mehr verändert sich die Frequenz vom takt Signal. Es holt auf (läuft schneller, positive Wert im _pfd) oder wartet ein wenig (läuft langsamer, negative Werte im _pfd). Am Ende sollte das eigentlich so gut wie Null sein. Dann ist der PLL eingerastet. (auf das regenierte _trigger Signal und damit auf den Takt im _in).

In dem Fall fällt mir auf, daß der PLL scheinbar nicht einrastet sondern driftet (_pfd wird nich kleiner sondern driftet hin- und her). Ich versuche mal von diesem encoder ne Aufnahme zu machen und probiere das bei mir auch mal aus.

Ich teste mit dem BOS-Tool. Unter Vista scheint der von dir genutzte Encoder nicht zu laufen. Oder ich hab ihn nicht verstanden :) Wenn ich auf "Auswahl" oder 512/1200/2400 drücke friert das Programm ein (= keine Rückmeldung)
[edit] Lösung für den encoder: +Meldung drücken .. war doch keine Lösung - scheint nur einmal senden zu können. Beim nächsten mal: friert's ein

[edit] mit 512 Baud wird das bei mir fehlerfrei decodiert.
[edit2] Wenn ich 1200 Baud einstelle wertet er nix aus. Aber da bin ich in guter Gesellschaft poc32 hält davon auch nix. Zumindest in meinem Test-Setup hier

Zitat:

---

Zitat von Buebchen

[edit] mit 512 Baud wird das bei mir fehlerfrei decodiert.

---

ich nehme an, dass du auch den letzten Stand aus SVN benutzt. Dann werde ich mal bei Gelegenheit schauen, was bei mir nicht tut. Zumindest versuchen.

Die VS Solution gibts nicht mehr für das Projekt? Nur noch minigw? Was war denn der Grund, dass man keine VS Solution mehr hat?

Da ich im Moment kein VS nutze gibt es keinen Supporter mehr für die Pflege der VS sln files. Das ist der Grund im Moment. Der ambitionierte Entwickler kann natürlich mal ein Projekt im VS dafür erstellen und im svn commit'en :)

Version im svn ist aktuell und sollte das können. Wichtig: Algorithmus auf 1 stellen. Sonst wird der nicht genutzt.

Zitat:

---

Zitat von Buebchen

_pfd: Der Phasendetektor-Output. Je grösser das ist, des weiter ist Takt vom Referenzsignal entfernt (_trigger) und umso mehr verändert sich die Frequenz vom takt Signal. Es holt auf (läuft schneller, positive Wert im _pfd) oder wartet ein wenig (läuft langsamer, negative Werte im _pfd). Am Ende sollte das eigentlich so gut wie Null sein. Dann ist der PLL eingerastet. (auf das regenierte _trigger Signal und damit auf den Takt im _in).

---

So, ich hab nun MinGW, MSYS neu installiert, mit den aktuellsten Stand ausm SVN geholt und gebaut.
Es wird der Algo 1 verwendet. Es funktioniert weder mit dem BOS-Tool noch dem POCSAG Encoder.
Erster Screenshot ist mit dem POCSAG Encoder, zweiter mit dem BOS-Tool der Output sieht so ziehmich gleich aus...

Während an Signal anliegt schwingt das _pfd. Liegt nichts an ist es NULL. Man sieht es angedeutet am rechten Rand.
Im Debug Output bekommt er wohl immer einen SYNC und das wars dann. Auf dem Socket kommt keine Meldung raus. Wo sollte denn die Meldung ankommen? Nicht dass ich hier schon an den falschen Stellen suche. ;-) Im Debug Output steht sie nur, wenn sie in die Datenbank geschrieben wird?!

Mich wundert am ehesten, daß der PLL nicht einrastet. Ich glaube, ich check nochmal den snvn aus, um zu sehen, ob da vllt. einfach irgendwo der Wurm drin ist.

Hast ein 32 oder 64 Bit Betriebssystem ? Weil mit 64 Bit gab es ja so kleinere Problemchen :)

Ist das 512 oder 1200 Baud ? Ich nutze von Haus aus 512 Baud zum testen. Und da kann ich wirklich nur sagen, daß ich nebenher auch noch mit POC32 dekodiere und es nicht wirklich oft passiert, daß a) eine Meldung ganz fehlt b) Die Text in der Qualität sehr unterschiedlich sind. Wobei poc32 meistens bei langen Texten besser am Takt bleibt.

Zitat:

---

Zitat von Buebchen

Hast ein 32 oder 64 Bit Betriebssystem ? Weil mit 64 Bit gab es ja so kleinere Problemchen :)

---

Das ist ein 32bit System (Win XP SP3)

Zitat:

---

Zitat von Buebchen

Ist das 512 oder 1200 Baud ?

---

Ich nutze 512 Baud. Wenn ich den Decoder von www.dsp4swls.de nebenbei laufen lasse, gehts auch. Der Decodiert alles. Wobei er beim BOS-Tool den Text wohl nicht bekommt... Mit POC32 kann ich das auch nochmal testen, aber ich nehme an, der bekommt das dann auch hin.

[edit]also mit POC32 bekomme ich auch gar nichts zum decodieren, mit beiden Encodern getestet. Ein Pegel wird angezeigt und sonst nichts. Mh... das verwundert mich nun...

[edit2]mit den POCSAG encoder 44100 Sample und 1200 Baud gehts mir POC32, mit allen anderem nicht...