monitord auf Linux / Auswertung verbessern?

[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.