monitor 1.9.0 - aber richtig :)

[jhr-online]

Schade, dass du nicht selber Hand anlegen willst, aber ich akzeptiere das natürlich (widerwillig)... ;)

Du könntest uns einen Gefallen tun und deine Anregungen ins BugTrackingSystem [1] einfügen*. Wenn ich das richtig sehe, ist Punkt 1 eine Wunschfunktion und die Punkte 2 und 3 sind Bugs. Trag das ruhig so ein - ist nicht schwer zu bedienen und man muss sich zum Eintragen nicht mal registrieren.

Deine gewünschte Trennung von Backend und Frontend wäre ein sehr großer Eingriff. Derzeit ist die Überlegung, dass Version 1.9.x aus dem jetzigen Code besteht und Bugfixes, sowie kleine neue Features enthalten soll. Für große Änderungen ist ein ordentliches Umstrukturieren des Codes angemessen, was auf eine Version 2 hinauslaufen würde. In der Theorie ist die auch geplant, aber es liegt natürlich ganz am Engagement der Entwickler, ob es soweit kommt. Das wäre nämlich richtig viel Arbeit.

jhr

[1] http://bts.jhr-online.de/?do=newtask&project=2

* Das ist deswegen von Vorteil, weil da Kontaktmöglichkeiten zu den Entwicklern gespeichert sind/sein sollen und wir die einzelnen Aufgaben (Bugs/Wunschfunktionen) da zuweisen können. Das gibt dem ganzen etwas Struktur und man kann sich absprechen, wer was übernimmt.

[nepomuck]

Deine gewünschte Trennung von Backend und Frontend wäre ein sehr großer Eingriff. Derzeit ist die Überlegung, dass Version 1.9.x aus dem jetzigen Code besteht und Bugfixes, sowie kleine neue Features enthalten soll.

Ich halte es für den falschen Ansatz, noch mehr Features in da monolithische Programm einzubauen. Die aktuelle Version lässt sich doch jetzt schon kaum auf zeitgemäßen Plattformen compilieren, ohne nicht mindestens ein dutzen "dev" Libraries zu installieren.

Von der Zuverlässigkeit her ist das existierende Backend klasse. Die Dekodierung läuft fehlerfrei, besser als bei kommerziellen Produkten. Was hier im Forum immer wieder bemängelt wird, ist die Auswertung.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Der Output läuft in ein gewöhnliches Char-Device und jeder X-beliebige User-Mode-Prozess kann lesend darauf zugreifen. Die Entwickler der Forntends müssen sich dann gar nicht mehr mit dem alten Code herumschlagen.

Im Backend muss man sich lediglich auf ein Protokoll einigen, welches die Dekodierung auf das Char-Device schreibt wie: "Channel 0:ZVEI:12345:M" oder "Channel 1:FMS:kennung:Status 0". Die eigentliche Auswertung kann dann sogar ein simples Shell- oder Perl-Skript übernehmen.

Andreas

[SirFS]

Ich halte es für den falschen Ansatz, noch mehr Features in da monolithische Programm einzubauen. Die aktuelle Version lässt sich doch jetzt schon kaum auf zeitgemäßen Plattformen compilieren, ohne nicht mindestens ein dutzen "dev" Libraries zu installieren.

Von der Zuverlässigkeit her ist das existierende Backend klasse. Die Dekodierung läuft fehlerfrei, besser als bei kommerziellen Produkten. Was hier im Forum immer wieder bemängelt wird, ist die Auswertung.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Der Output läuft in ein gewöhnliches Char-Device und jeder X-beliebige User-Mode-Prozess kann lesend darauf zugreifen. Die Entwickler der Forntends müssen sich dann gar nicht mehr mit dem alten Code herumschlagen.

Im Backend muss man sich lediglich auf ein Protokoll einigen, welches die Dekodierung auf das Char-Device schreibt wie: "Channel 0:ZVEI:12345:M" oder "Channel 1:FMS:kennung:Status 0". Die eigentliche Auswertung kann dann sogar ein simples Shell- oder Perl-Skript übernehmen.

Andreas

Also ich muss sagen, dem stimme ich zu 100% zu.
Wenn ich mehr Zeit hätte, würde ich mich da ja mal mit beschäftigen...

[ManuelW]

Ich finde auch das klingt sehr vernünftig.
Vor allem die Konfiguration sollte einfacher werden, ich habe damals ewig
gebraucht und gebastelt bis es dann endlich mal so lief wie es sollte...

[DocSteel]

Hallo

Es wäre schön wenn mal einer der Entwickler im ersten Beitrag dieses Themas einen aktuellen Link zu einem funktionierenden svn posten könnte (bzw. den vorhandenen anpassen)

Bei jhr-online.de/monitor und bei monitord.de kommen beim Versuch dort svn's auszuchecken Fehlermeldungen bzw. es gibt die Domain im ersten Fall gar nicht mehr.

Das macht es Interssierten schwer an die Quellen zu kommen. Trotzdem ein tolles Projekt.

Gruß

Doc - Der sich über einen Link zu den aktuellen Dev-Quellen freuen würde (gerne auch Vers. 1.9, muss ja nicht 2.0 Beta sein, hauptsache es läuft)

[Buebchen]

Aktuelles SVN:

http://svn.monitord.de

-> wichtig ist das http Protokoll (für WebDAV)

[DocSteel]

Ah danke! :)

[pocfreak]

bekommt jemand dieses

http://www.kb9ukd.com/digital/pocsag12.wav

signal dekodiert?

wenn ja, mit welchem eingangspegel??

das signal lässt sich bei mir unter windows und linux (wine) mit PDW dekodieren.

aber nicht mit monitor.

ich wäre für hilfe echt dankbar!!

[funkwart]

Hallo Forum,
hallo Entwickler,

gibt es eigentlich irgendwelche Entwicklungen bezüglich der Dekodierung von POCSAG 1200 Baud? Das letzte Posting, das ich dazu gefunden habe, hatte im Prinzip zum Inhalt: Dekodierroutine geändert, monitord dekodiert 1k2 deutlich schlechter als vorher.
Es ist doch schade, dass ein so universell und fortschrittlich aufgebautes Programm nicht genutzt werden kann, weil eine Komponente nicht tut, was sie soll.
Ich habe leider weder von C++ noch von POCSAG-Dekodierung genug Ahnung, um mich selbst an den Code zu setzen.
Könnte nicht einer der Programmierer die Dekodierroutine vom alten 1.8.1 einbauen und wie bei fms per Tag in der XML-Datei zur Auswahl stellen? Bitte, habt doch ein Herz für die User, die so fürchterlich auf dem Schlauch stehen aktuell!

Vielen Dank und bested Grüße,
Funkwart

[mdi]

Hallo zusammen,

ich habe eben einmal nachgesehen, was da in den Sourcen drin steht:

	bool crccheck=getNodeBool(*pConfig,"crc-check",true) ;
	bool errorcorrection=getNodeBool(*pConfig,"ecc",false) ;
	int minpreambel=getNodeInt(*pConfig,"minpreambel",0) ;
	int maxerrors=getNodeInt(*pConfig,"maxerrors",0) ;
	int algorithmus=getNodeInt(*pConfig,"algorithm",0) ;

Das heißt, man kann im POC1200-Bereich der Konfigurationsdatei einstellen:
- crc-check (0/1) (geschrieben: 1 ), default true
- ecc (0/1) (Fehlerkorrektur) , default false
- minpreambel (Länge der Präambel), default 0
- maxerrors (maximale Anzahl an Fehlern vor Verwurf des Telegramms), default 0
- algorithm (0/1), default 0/"der alte"

Probier doch mal, den Auswerte-Algorithmus zu ändern (0/1). Es sind derzeit zwei implementiert, 0 ist wohl der alte (aus dem 1.8.1er, so weit ich das sehe), 1 der neue (von Buebchen hier im Forum, wenn ich das richtig zuordne). Ansonsten kann es auch schon deutlich helfen, die "maxerrors" hoch zu setzen (wenigstens auf eins oder zwei); wie sieht denn da Deine Konfiguration aus derzeit?

Viele Grüße
Martin

[jhr-online]

Bin ich ebenfalls dabei.

Dann packen wir doch den ganzen Dekodiercode in einen Monitor-Daemon mit minimalen Konfigurationsoptionen. Das muss nichts neu geschrieben, sondern nur Bestehendes neu verpackt werden.

Für dich gilt, wie für alle anderen, die mitmachen wollen:

• Schick mir eine PN mit einem Wunschpasswort, damit ich Schreibzugriff auf das Repo einrichten kann.
• Registrier dich im BugTrackingSystem und nenn mir in der PN deinen Namen, damit ich dich da zum Developer machen kann (das erlaubt auch da Änderungen und so)
• Registrier dich in der Mailingliste
• Komm ab und zu mal im Channel #fms-monitor auf irc.freenode.net vorbei

Wenn alle einverstanden sind, machen wir mal einen Termin ab, an dem wir uns alle im IRC treffen (für ne halbe Stunde oder so) und mal überlegen, wie wir es am Besten angehen. Vorschlag: (Oster-) Montag, 20 Uhr.

jhr

PS: Danke! :)

[ManuelW]

Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...

Ob Montag um die Zeit klappt weiss ich noch nicht, da wollt ich an nem
Bau-Seminar in SecondLife teil nehmen :P

[jhr-online]

Wozu denn noch ne Mailingliste wenn wir das Forum haben ?
Ist doch doppelt gemoppelt...

Es ist nur ein Angebot. Wenn wir die nicht brauchen, mache ich sie wieder aus. Ist ja kein Problem. Ich hab mich nur sehr an den Luxus gewöhnt :)

Was den Termin betrifft: Das war auch nur ein Vorschlag. Scheint wohl nix zu werden, wenn sich zwei melden, weil sie nicht da sind. Andere Vorschläge?

jhr

[Buebchen]

Also, ich war im Osterstreß (der jetzt erstmal fließend in dn Kommunions-Streß übergeht). Würde aber versuchen, dabei zu sein. Am liebsten frühestens um 20:00 Uhr. Besser sogar 21:00 Uhr :-)

Mailingliste würde ich mal abwarten. Ggf. für die Entwickler unter sich. Ansonsten finde ich ist das Forum einfacher und erreicht mehr Leser.

[jhr-online]

Bin ich dabei!

An alle: Termin für ein IRC-Treffen lieber in der Woche oder am Wochenende?

jhr