monitor 1.9.0 - aber richtig :)

[funkwart]

Der Kommentar

//war demod_se ...

legt die Vermutung nahe, dass es sich hierbei um den originalen Algo handelt. Außerdem habe ich bisher nichts in der monitord.xml stehen gehabt. Somit sollte der Default-Algo verwendet werden. Es wird aber bei 1k2 nichts dekodiert, somit vermute ich, dass default = demod_mg = neuer Algo ist.
Ich verstehe schon mg=Martin Grohmann und se=Stephan Effertz, aber dann würde das bedeuten, dass bei mir der Default-Algo, also der alte Algo von M. Grohmann unter monitord nicht tut, während er es unter monitor-1.8.1 nahezu perfekt tut...

VERWIRRUNG!!!

Gruß,
Funkwart

[mdi]

Hallo,

ich habe eben nochmal in die Sourcen auch des 1.8.1-er geschaut. Die "_mg" ist die Methode von Markus Grohmann, beim schnellen Überfliegen augenscheinlich nur angepasst an die C++-Struktur des monitord 2.0. Die _se ist die neue von Stefan. Warum die alte natürlich dann gar nicht tut, ist eine gute Frage... :(.

Ich selber habe leider keine POCSAG-Geschichten genutzt bisher, bei einem Test mit dem Algorithmus 1 tats aber (BOS-Tool -> Aufnahme Stereomix) gerade. Vielleich reicht der Pegel da bei Dir für die Auswertung mit dem monitord nicht (oder ist zuviel)?

Martin

[funkwart]

Den neuen Algo habe ich noch gar nicht ausprobiert. Ich wusste ja nicht, dass es zwei verschiedene Algos gibt und habe den Standardmäßigen (also den mg-Algo) genutzt. Ich denke mal, in 512 wird der auch genutzt, oder? Dort funktioniert er nämlich einwandfrei. Nur bei 1k2 nicht. Vielleicht ist ja ein Bug drin?!?
Ich werde heute Abend mal den 1er (also den von Stefan) probieren.
Ich berichte...

Danke und Gruß,
Funkwart

[mdi]

Moinmoin,

nach weiteren Blicken in den Code... ;):

pocsag-modul: default = 0 (mg)
poc512: default = 1 (se)
poc1200: default = 0 (mg)

Im 512er wird also idR das neue, im 1200er das alte Auswerte-Codestück genutzt. Der "globale" default-Wert in der POCSAG-Basisklasse wenn man sie so nennen will, ist 0 (mg), der wird aber durch die Klassenhierarchie dann überladen. Sollte er jedenfalls ;). Ist der algorithm-Wert in der monitord.xml explizit gesetzt, hat der eh gewonnen.

Für FMS gilt übrigens: 0 (mg) ist der Standard, hier heißt das Feld in der Konfigurationsdatei allerdings "algorithmus" (bei POCSAG "algorithm")! Bei Algorithmus 1 gibts wieder eine Neuentwicklung "_se", die scheinbar besser tut, wenn man dem Grundrauschen hier im Forum Glauben schenken kann ;).

Viele Grüße
Martin

[funkwart]

Moin Martin,

danke für Deine Mühen mit dem Code.
So detailliert hatte ich das nicht herausgelesen. Leider haben meine Tests nicht so ein wirklich gutes Ergebnis gebracht.
Ich habe beim Blick in den Code auch festgestellt, dass der Grohmann-Algorithmus wirklich fast 1:1 übernommen wurde. Was ich jetzt nicht begreife, ist, dass er mit monitor-1.8.1 hervorragend bei poc1k2 tut, mit monitord überhaupt nicht. Gleiches Gerät, gleiche Soundkarteneinstellungen etc. Zusätzlich blöde: Auch der SE-Algorithmus funktioniert keinen Deut besser. Mir kam es schon so vor, als ob das Auswählen des Algos überhaupt keinen Effekt hat... Vielleicht ist es ja so?! Ich habe in der monitord.xml folgende Eintragung stehen:

        
		 1 
		 0 
		 1 
	

Sowohl mit "0", als auch mit "1", als auch ohne die Zeile für den Algo kommt immer das Gleiche dabei heraus: Die Feldstärke-RIC wird als RIC korrekt erkannt, liefert aber keinen Text mit, obwohl monitor-1.8.1 immer [i][/] bzw. [i][/] dekodiert.
Wenn eine "normale" Nachricht kommt, wird eine völlig andere RIC dekodiert, aber ebenfalls kein Text. Dieses Verhalten ist mit beiden Varianten in der monitord.xml identisch. Sehr merkwürdig!

HILFE!!!

Danke und Gruß,
Funkwart

[mdi]

Hallo Funkwart,

schreib bitte probehalber den " 3 " dazu. Nur um auszuschließen, dass er gleich alles unterdrückt sobald er einen Fehler bei der Decodierung findet...

Hast Du mal versucht, z.B. mittels BOSTool etwas "zu senden" und das zu decodieren? Wenn das gehen sollte, könnte es an Eingangspegeln oder soetwas liegen; irgendwelche Pegel-Minima könnten da "reinhauen".

Ansonsten fürchte ich, müsste man genauer schauen, was der Auswerter wann wo findet und verarbeitet... da fehlt mir aber momentan der Durchblick; wie gesagt habe ich bisher nur im ZVEI-Code rumgefingert, auch in Sachen Debugging.

Viele Grüße
Martin

[funkwart]

Hallo Martin,

die Sache scheint doch etwas tiefer zu gehen.
bringt beim Algo 0 (default) nur mehr Falschauswertungen, trotzdem keine übermittelten Nachrichten. Bei Algo 1 bringt es gar nix. Keine Auswertungen.
Ich habe mal auf einem Windows-Rechner den minitord installiert, bos-tool dazu und getestet. Auch dort wird 512Baud perfekt, 1200 Baud gar nicht dekodiert. Sogar noch grottiger als auf Linux.
Ich vermute das Problem irgendwo in einem Bug in der 1k2-Dekodierroutine.
Ich habe nur wirklich absolut nicht genug Ahnung, um dazu etwas zu finden. Könnte höchstens mal einen zeilenweisen Vergleich zwischen 1k2 und 512 anstellen, aber ob das was bringt.

Gruß,
Funkwart

---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---EDIT---

Ich habe tatsächlich mal die MonitorModulePocsag512.cpp und die MonitorModulePocsag1200.cpp miteinander verglichen und festgestellt, dass es einige Unterschiede gibt. Zwar kann man für die 512er Variante auch in der xml den Tag formulieren, daraus folgt aber keine Entscheidung für einen Algorithmus - obwohl beide im Code vorhanden sind.
Weiterhin gibts in der 512er Variante noch einen großen Abschnitt, in dem ein IIR Filter programmiert wurde. Den gibts in der 1k2er Variante nicht.
Das erst einmal als grober Vergleich der beiden Versionen.

[rhein-erft]

Moin Martin,

Die Feldstärke-RIC wird als RIC korrekt erkannt, liefert aber keinen Text mit, obwohl monitor-1.8.1 immer [i][/] bzw. [i][/] dekodiert.
Wenn eine "normale" Nachricht kommt, wird eine völlig andere RIC dekodiert, aber ebenfalls kein Text. Dieses Verhalten ist mit beiden Varianten in der monitord.xml identisch. Sehr merkwürdig!

HILFE!!!

Danke und Gruß,
Funkwart

Hallo zusammen,
habe ähnliche Probleme mit dem lieben poc1200. Wenn ich mit BOS-Tool per Klinke vom Notebook in den Server sende ist die Auswertequote bei so ca. 66%, RIC wird erkannt und Text auch vollständig. Wenn ich dann per Empfangsgerät und riesen Antenne dekodiere, z.b. von unserem Testsender aus dekodiert die Sau die Rics in fast 75% richtig, jedoch ohne Text. Das ist schwer nervig...
Nächstes Ding: wenn man auf DEBUG loggt bekomme ich immer von der MonitorModulePocsag.cpp ein "Sync gefunden (line 165)"
Dies passiert wenn ich mit dem Sender sende oder "normal" empfange, allerdings auch wenn weder ne RIC noch irgendwas anderes erkannt wird.

Ich hoffe es wird langsam besser, weil so, alles in allem ist der monitord schon schwer cool geworden...
Gruß rhein-erft

[Buebchen]

Nach einer recht langen Pause tut sich ja doch wieder was zum monitord. Bisher habe ich aus purem Eigennutz primär den 512 Baud Algoritmus optimiert. Gerade was den IIR angeht weiß ich nicht so recht, ob der bei 1200 Baud auch noch so gut funktioniert. Werde ich wohl mal testen müssen.

Werd mal nen Checkout machen und sehen, was ich mit BOSTool so aus 1200 Baud rausholen kann. Der 1.8.1 Algo ist ziemlich verstrickt gewesen. Da waren mitten drin dann auch mal Textausgaben und sowas eingeflochten. Das hatte ich soweit entheddert, daß der Auswerter von der Ausgabe selbst getrennt ist.

Was ich mal im laufe der nächsten Tage testen werden: IIR auf 1200 Baud ausprobieren. Und mal sehen, wo sich ggf. das Original und die 2.0-Version von (MG) unterscheiden.

Edit:
Das "Sync gefunden" hatte ich eingebunden um zu sehen, ob es Probleme gibt beim Einschwingen auf den Bit-Takt. Das ist doch recht empfindlich. Manchmal waren die Geschwindigkeitskorrekturen so groß, daß der PLL sinngemäß direkt wieder ausgerastet war. Dann wurde natürlich nix mehr erkannt.

Ein SYNC leitet immer eine Aussendung ein. Danach käm dann ein Adresswort und ggf. Datenwörter für den Inhalt.

[MiThoTyN]

Tach zusammen!

Folgendes mal als Hinweis:

Ich lese hier arbeiten doch einige mit dem POCSAG-Teil des BOS-Tools zum Testen der Auswerter.

Leider hat das BOS-Tool in der letzten Version ein Timing-Problem. Das Ausgleichen der Rundungsfehler funktioniert nicht richtig, das komplette POCSAG-Signal ist etliche Millisekunden kürzer als es sein müsste.

Im Detail:

Bei einer Samplefrequenz der Soundkarte von 44100 Hz und einer Baudrate von 1200 Bps hat ein Bit die Länge von 36,75 Samples. Das runde ich auf 36 und summiere den Rest von 0,75 auf. Jedes Mal, wenn dieser Rest > 1 wird, füge ich ein Füllsample ein. Das klappt beim BOS-Tool nicht. Dort ist jedes Bit nur exakt 36 Samples lang.

Die Abweichung in Samples ist also:

AbweichungSamples = (nBits * 0,75)

Dann kann man auf die Millisekunden umrechnen.

Ich stell euch demnächst mal einen korrigierten POCSAG-Geber zur Verfügung.

Gruß Joachim

[dekarl]

Bei einer Samplefrequenz der Soundkarte von 44100 Hz und einer Baudrate von 1200 Bps hat ein Bit die Länge von 36,75 Samples. Das runde ich auf 36 und summiere den Rest von 0,75 auf. Jedes Mal, wenn dieser Rest > 1 wird, füge ich ein Füllsample ein. Das klappt beim BOS-Tool nicht. Dort ist jedes Bit nur exakt 36 Samples lang.

Moin,

das heißt mit 48.000 Hz müsste es gehen weil das genau 40*1200 ist?

[MiThoTyN]

Das würde auch gehen.

Aber nichts desto trotz müsste ich das in der Programmierung des BOS-Tools ändern. Bei 48 Khz bin ich mir aber nicht sicher, ob es nicht noch Hardware gibt, die das nicht unterstützt. Ich tendiere da eher wie besprochen dazu, die fehlenden Samples auszugleichen. Das würde auch bei Sampleraten von 11025 und 22050 noch funktionieren.

Wie auch immer, ihr bekommt demnächst eine Version, mit der die Timings richtig sind.

Gruß Joachim

[funkwart]

Es gibt ja auch noch folgendes Programm zum En- und Decodieren:
http://www.dsp4swls.de/sorfmon/sorfmon.html

Weiß hier zufällig jemand, wie die Decodierung in PDW, zu finden unter http://www.gsm-antennes.nl/PDW/ funktioniert?

Ich habe das mal testweise installiert und bekomme exorbitante Auswertungsergebnisse. Leider aber eben ein Windoof-Programm und nicht monitord ;-)

Das Ganze kann auch noch FLEX und ACARS. Wenn man das bei monitord mit drin hätte, hätte man sicherlich auch eine gute Unterstützung von Programmierern aus den Niederlanden...

Nur so als Anregung.

Gruß,
Funkwart

[RICkey]

Hallo zusammen,

ich hoffe, ich bin hier nicht ganz off-topic, da ich den monitord 2.0 nutze. Leider haben wir hier massive Probleme bei der Pocsag 512 Auswertung auf einem Debian System.

Derzeit hängen zwei Scanner (2m/4m) an dem Line-In der Soundkarte (wobei am Mic das gleiche Verhalten auftritt) und bei der digitalen Alarmierung brechen die Meldungen immer nach ca. 24-30 Zeichen ab. Es kommt also keine Nachricht vollständig an.
Inzwischen bin ich hier so einige Vorschläge durchgegangen: Pegeleinstellungen kontrollieren (über alsamixer, div. Pegel durchprobiert), maxerrors auf 5 bzw. 6 erhöht, crc und ecc Einstellungen verändert, etc. Leider brachte bisher alles nichts.
Wenn ich auf einem anderen System eine Nachricht generiere und direkt über Kabel auf dem Server in die Soundkarte einspeise wird die Nachricht vollständig und korrekt dekodiert und in die DB geschrieben.

Hänge ich die Scanner an einen anderen Rechner (Win XP, monitord 2.0) werden alle Nachrichten vollständig und korrekt dekodiert. Das bedeutet, dass das Signal der Scanner eigentlich "gut" sein sollte. Warum hakt es dann auf dem Debian-System?

Hat jemand evtl. noch einen heißen Tipp? Ich bin über jeden Vorschlag dankbar, da ich im Moment keine Ideen mehr habe. Vielen Dank für die Mühen im voraus.

Gruß, Bastian.

[funkwart]

Nur mal als kleine Anregung: Probiere doch bitte einfach mal den monitor-1.8.1 aus. Lässt sich ohne Weiteres parallel installieren (nur nicht gleichzeitig nutzen). Versuche dort mal die Dekodierung. Wäre interessant zu wissen, wie es da aussieht und ob sich daraus Rückschlüsse ziehen lassen. Bei mir z.B. funktioniert POC1200 auf monitor-1.8.1 ohne Probleme und astrein, mit monitord geht nix!

Gruß,
Funkwart