monitor 1.9.0 - aber richtig :)

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

[nepomuck]

Moin,

Mal 'ne grundsätzliche Frage:

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

Braucht es diese ganzen Parameter beim Build wirklich? Geht das nicht einfacher, so dass der Anwender nur über die monitor.xml entscheidet, welche Module er starten will. Ein einfaches ./configure und make baut dann einfach alles.

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

Braucht es diese Libs zum Build oder erst zur Laufzeit? Es sollte doch genügen, wenn in der monitor.xml der Pfad zu den Libs angegeben wird, falls der Anwender diese Module nützen möchte.
Das würde es erheblich vereinfachen, den monitord als Binärdatei auf einer Distribution zu installieren (per RPM oder DEB).

Liesse sich überdies eine Option einbauen, die nach einer Ausnahme die Audiodatei an ein externes Skript übergibt? Dann könnte man die Aufzeichnung beispielsweise durch einen Filter jagen, der Ruhepasen entfernt.

viele Grüße,
Andreas

[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

[mdi]

Hallo nochmal,

dem Switch()-Statement und den Namen der Methoden nach müsste 0 und default der alte Algorithmus (mg) sein. 1 als einziger Fall ist der neue (se).

Mit der "Unterschied"-Überlegung solltest Du recht haben: Wenn der Algorithmus 1:1 übernommen wurde, dann müsste bei Parameter "Algorithmus 0" die Auswertung identisch sein.

Genaueres kann Dir da Buebchen sagen, ich habe meine Finger bisher nur im ZVEI-Auswerter gehabt... ;). Aber ich bin gespannt was bei Deinen Versuchen heraus kommt :)!

Viele Grüße
Martin