Druckbare Version
Wäre toll.Zitat:
Zitat von Buebchen
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 :)
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.Zitat:
Zitat von funkwart
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.
Nein, weil sich fast täglich der Build ändert. Mit der monitord-Bosix warte ich auf einen stabilen Build.Zitat:
Zitat von funkwart
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
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.Zitat:
Zitat von Buebchen
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.
So, ich hab nun MinGW, MSYS neu installiert, mit den aktuellsten Stand ausm SVN geholt und gebaut.Zitat:
Zitat von Buebchen
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.
Das ist ein 32bit System (Win XP SP3)Zitat:
Zitat von Buebchen
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.Zitat:
Zitat von Buebchen
[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...