Quizfragen an alle Spaghetticode-Liebhaber

Moin Forum,

ich habe mal zwei Fragen an die "Spaghetti-Kenner" unter Euch:
Wo wird im Quellcode die Log-Datei geschrieben?
Hintergrund der Frage ist, dass ich gerne sowohl in der Bildschirmausgabe als auch im Log-File gerne nach jeder Meldung eine Linie aus Minuszeichen oder Unterstrichen hätte, um die Auflistung übersichtlicher zu haben. Es würde auch reichen, wenn diese Linien nur die Alarmierungen von den Statusmeldungen abgrenzen.
Wo füge ich das im Code ein? Oder kann man es evtl. sogar in der .monrc einstellen, wo die Formatierungen für Ausgaben festgelegt werden?

Ich hoffe, jemand von Euch kann mir hier helfen und bedanke mich schonmal im voraus für die Unterstützung.
Grüße,
Funkwart

Guck Dir mal den Minimal Perl Client unter: http://funkmeldesystem.de/foren/show...oni#post281400 an und den Beitrag da drunter. Der Client tut eigentlich genau das auf der Konsole was Du willst. Ich würde die Sachen eh nicht so wie Sie aus dem Monitord fallen in eine Log Datei schreiben sondern in eine SQL-Datenbank und diese dann via Frontend (Console oder PHP Web basiert) abfragen. Das macht das ganze deutlich übersichtlicher.

Hey, danke für den Tipp!

Ich hatte allerdings vergessen, zu schreiben, dass ich nicht den neuen Monitor, sondern den "alten" verwende.
Ich habe mir den Thread jetzt aus Zeitgründen nicht komplett durchgelesen, wohl aber gesehen, dass es nach den ersten Posts wohl Schwierigkeiten mit POC1200 gegeben hat. Bestehen diese noch, oder funktioniert das mittlerweile?

Gruß,
Funkwart

Lese ich hier, daß wir da noch einen Tester für POCSAG mit 1200 Baud hätten ? :-)

Muss mal den PLL tauschen. Habe mich jetzt entschlossen einen Software DPLL zu versuchen. Müßte bei POCSAG gut passen. FMS lasse ich nich aussen vor. Hier versuche ich vielleicht eher einen LPLL.

Für den DPLL muss ich aber noch die nötigen Parameter errechnen *grübel-rechne*grübel*

Generell: Einige haben Ärger mit POCSAG. Bei anderen rennt das wie verrückt. Einfach mal probieren. Ich könne mir vorstellen, daß es auch daran liegt ob das Netz von Swissphone oder Motorola stammt.

=================================================
!!! AB HIER WIDMET SICH DIESER THREAD WIEDER DEM THEMA !!!
=================================================

@ buebchen:
Von diesen abgefahrenen Dingen wie LPLL und DPLL habe ich leider nicht so viel Ahnung wie hier nötig ist. Aber als Tester stehe ich natürlich gerne zur Verfügung. Die örtlichen Ggegebenheiten habe ich Dir ja schon geschildert. Ein Testsystem habe ich auch am Laufen.
Du kannst Dich auch gerne per PM melden.

Gruß,
Funkwart

Oh je. Dann muss ich wohl am Wochenende mal die Filter für den PLL berechnen :-)

Reine Software PLLs habe ich nur im Studium gemacht. Bin gespannt ob ich das noch hinbekommen. Lang, lang ist's her ...

Zitat:

---

Zitat von dieKampfwurst

LOL

Wow, kaum kriecht einer euch in den popo, schon wird gerannt..

---

Die Meinung teile ich nicht.

Zitat:

---

Zitat von dieKampfwurst

Nunja, zur info bei mir macht das Swissfone Netz Probleme.
Ich weiss nur nicht, ob in dem Netz noch andere Pager genutzt werden.

Nocheinmal, wenn ich irgendwie helfen kann, helfe ich gerne.
Würde es etwas bringen, wenn ich euch ein Paar Meldungen zukommen lassen würde?

kW

---

Die Empfängertypen sind dafür nicht relevant. Motorola sendet z.T. einfach " anders ".

Wie schon geschrieben: Ich werde versuchen am WE mal erste Schritte in Richtung Austausch des PLLs zu machen. Im Bereich der eigentlichen digitalen Auswertung ist m.E. nicht viel zu ändern. Die sieht für mich auch ok sein.

Wenn es soweit ist würde ich mich über eine kurze Audio-Datei freuen. Dazu muss ich aber erstmal den PLL fertig haben. Nur erwarte bitte nicht, daß es am Montag definitiv als erste Version bereit steht. Ich habe in meiner Freizeit - wie Du auch - noch andere Hobbys und auch Verpflichtungen. Ich mache das nebenher gerne weiter. Über positive Kritik ist auch niemand böse. Aber ein einfaches " geht nicht " lasse ich nicht gelten. Ich erwarte dann auch ein wenig Eigeninitiave, wo das Problem liegen könnte.

Servus!

Mitteilung meinerseits: Die OT-Beiträge wurden entfernt, falls es weiter persönlich wird gibt's Konsequenzen!

Gruß
Alex

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

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

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

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.

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

Zitat:

---

Zitat von 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.

---

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.

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.

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

Hallo,

wollt mal nachfragen, obs schon etwas neues gibt..

Wenn es Neuigkeiten gibt, werden diese hier bekanntgegeben. Da hier nichts Neues steht, liegt der Schluss nahe, dass es noch keine neuen Mitteilungen gibt...

Gruß,
Funkwart

Vielen Dank für die Info :D

Wie funkwart schon schrieb: Ich gebe natürlich einen Laut von mir, wenn es etwas neues gibt ( sprich eine neue Version zum installieren und testen ).

Wie schon angedeutet ist meine Zeit etwas knapp. Aber die Mutation zum neuen Algorithmus ist im Gange :-)

Moin,

Zitat:

---

Zitat von Buebchen

Wie schon angedeutet ist meine Zeit etwas knapp. Aber die Mutation zum neuen Algorithmus ist im Gange :-)

---

*Schulter klopf* - gute Entscheidung und danke fürs Engagement :)!

Viele Grüße
Martin