monitor 1.9.0 - aber richtig :)

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

[Buebchen]

Eine neue Version ist im SVN eingecheckt. Würde mich interessieren, ob die jeder compilieren kann. Einiges ist geändert. Die meisten Features sind als Kernelement (ohne grosse Tests) vorhanden.

Wichtig:
lame + mysql werden vom configure script getestet, wenn man es nutzen will. Dazu muss die libmp3lame.so und libmysqlclient.so im Linkerpfad liegen. Sonst meldet configure einen Fehler.

Ach ja. Die option --enable-lame habe ich in --with-lame umbenannt (da es auch with--mysql heisst).

Das vollständige Pluginpaket würde also mit --enable-plugins --with-mysql --with-lame erstellt werden.

Gibt es eigentlich jemanden, der rpm bauen kann ?

[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

[funkwart]

Hallo Martin,

danke für den Tipp.
Ich hatte auch schon versucht, mich durch den Code zu hangeln und war vor wenigen Minuten genau an der Stelle angekommen. Somit müsste also ein

 1 

im Abschnitt poc1200 der monitord.xml den 1.8.1-er Algorithmus wieder aktivieren?!
Standardmäßig (0) wird wohl der neue Algo aktiviert.
Denn:

void MonitorModulePocsag1200::demod(float *buffer, int length)
{
	switch (m_iAlgorithmus)
	{
	case 0:
		demod_mg(buffer, length) ; // war demod_se ...
		break ;
	case 1:
		demod_se(buffer, length) ; // war demod_se ...
		break ;
	default:
		demod_mg(buffer, length) ;
	} ;
}

Dann dürfte es ja theoretisch keinen Unterschied zur 1.8.1-Variante auf ein und derselben Hardware kommen, richtig?

Danke und Gruß,
Funkwart

[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.