Quizfragen an alle Spaghetticode-Liebhaber

[dieKampfwurst]

Kein Thema..
ich habe zu hause ein Tool, welches unter Windows läuft, und die aufgenommenen Dateien ohne Probleme decodiert.
Leider habe ich keinen Source dazu gefunden.

Was ich gerne Probieren würde ist die Aufnahme über den mointord, was bei mir leider nicht funktioniert. (Plugin wird nicht geladen).

Buebchen kann ich dir per PM einen Link schieken zu dem Testfile ?

kW

[dieKampfwurst]

Hal eine blöde Frage,
wieso PLL und co?
Ich kenn PLL nur in bezug auf Frequenzen, welche durch einen Quarz nicht erreicht werden können, und verfielfältigt werden.

Wenn ich eine Decodierung in einem Controller machen würde würde ich versuchen saubere "1"en und "0"en zu bekommen.

Leider weis ich nicht, wie die Daten aussehen, die der Treiber ausspuckt, ich schätze mal er gibt analoge werte aus.

Kann man nicht mit einer Sample Frequenz von ca. 5*512 / 5*1200 / 5*2400 das Signal simpel zerlegen und über die Zeit bis ein bestimter Wert über / unterschritten wird messen? Dann hätte man die Daten.
Ich weis gerade nicht, ob eine 1 nur oberhalb der Nulllinie kommt, oder ob auf dem Signal ein grosser Offset liegt.

kW

[Buebchen]

Es gibt da so eine Regel in der digitalen Nachrichtentechnik: Der Takt kann nur aus dem Signal gewonnen werden. Um dazu bietet sich eine PLL ( oder ähnliches an ).

Bisher geht der alte Code hin und achtet primar auf Nulldurchgänge ( Flanken ). Diese markieren den Anfang eines Bits. Soweit erscheint es einfach: Nulldurchgang = Bit startet, Hälfte der Dauer eines Bits warten, dann Wert auslesen. Man müßte ja in der Mitte vom Bit stehen. Und ist schon fertig.

Da so schöne Signal nicht auftreten ist es dann doch schwieriger. Die Flanken könnte man per Schmitt-Trigger verbessern. Verrauschte Signal haben vielleicht mal zwischendurch einen Nulldurchgang. Und weiss der Geier, was noch auftreten kann.

Der alte Algo ist nicht sehr komplex, wenn man ihn aus dem bestehenden Source erstmal rausgearbeitet hat. Da er aber Probleme hat einer langen Übertragung zu folgen vermute ich, liegt es daran, daß Auswerter und Signal irgendwann auseinanderdriften.

Generell zum PLL: Du hast da einen Anwendung genannt ( Frequenzerzeugung ). Eine andere ist eben die Sync auf ein empfangenes Signal ( wo ich ja erstmal nicht weiss wann die Übetragung startet - Mir also die Phasenlage nicht bekannt ist - ebenso muss ich meinen Empfänger natürlich im Sync halten ).

Bei einer Samplerate von 22,050 kHz ist ein Bit bei 512 Baud übrigens 43,0664 Samples lang. Wenn man also alle 43 Samples einen Wert aufnimmt driftet man schon aus dem Takt ...

Ergänzung: POCSAG ist ein NRZ Signal. Technisch wird die Trägerfrequenz selbst verändert. Nicht das aufmodulierte Signal. Was im Empfänger aber egal ist. Der sieht im besten Fall tolle Rechtecke :-)

[dieKampfwurst]

Ebend..

ich hatte damals ein Ähnliches Signal (DCF) wo ich zwar nur eins und null empfangen hatte, da bin ich dann nur nach der Zeit gegangen.
Grob kennt man ja die Zeiten, sprich wenn länger, als xx Sampel = 1 wenn kürzer = 0. Dies würde auch keine genaue Zeitbasis benötigen, da man nach jedem Pegel die Zeit Resettet.

[DocSteel]

Auch ich würde als Tester für eine neue POC1200 Version zur Verfügung stehen.

[Buebchen]

Ebend..

ich hatte damals ein Ähnliches Signal (DCF) wo ich zwar nur eins und null empfangen hatte, da bin ich dann nur nach der Zeit gegangen.
Grob kennt man ja die Zeiten, sprich wenn länger, als xx Sampel = 1 wenn kürzer = 0. Dies würde auch keine genaue Zeitbasis benötigen, da man nach jedem Pegel die Zeit Resettet.

Am Algorithmus selbst habe ich noch nicht viel gemacht. Die wirklich einfachen Ideen hatten aber keine Verbesserung gebracht. Jetzt gehe ich mal den akademischen Weg. Mal sehen, ob das dann besser wird. Ich selbst habe die Probleme nicht. Bei meinem Empfang sehe ich immer das [EOT] am Ende. Habe also vollständigen Text.

[dieKampfwurst]

Unter dem 32Bit Linux lief es bei mir ohne Probleme, unter dem 64Bit nur in einer 32Bit Chroot (der alte monitor) Meldungen hatte ich meist 2 bis 3 mal bekommen samt [EOT].

Ob die decodierung nach dem Theoretischem Weg besser klappt keine ahnung.
Evtl. können wir am WE über irc diskutieren, ich fände es nicht schlecht, wenn dort ein Chan aufgebaut wird, wo man zu gleich mit mehreren Diskutieren kann.

[jhr-online]

Es gibt bereits einen Channel!
#fms-monitor auf freenode.

Genauso, wie es ein BugTrackingSystem gibt: bts.monitord.de und sogar Mailinglisten stehen zur Verfügung, wenn das mal gewünscht wird. Alles kein Problem; man muss nur fragen...

jhr