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

[Buebchen]

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

[nepomuck]

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

[Buebchen]

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.

[Buebchen]

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

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.

[nepomuck]

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)

                     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)

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.

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

[nepomuck]

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

[Buebchen]

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

[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

[Buebchen]

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.