monitord auf Linux / Auswertung verbessern?

[Pilzi]

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.

[Buebchen]

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.

[Pilzi]

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

[Buebchen]

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 :(

[Buebchen]

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/

[nepomuck]

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