monitor 1.9.0 - aber richtig :)

[MacLeod]

so hab noch mal n bissel getestet
fms wird opti erkannt. auch in zimmerlautstärke :-)
zvei muß ich derart aufregeln, das mir bald die ohren abfallen, und es kommt auch schon ein wenig zu verzerrungen. ev liegts ja daran das dann der signal/Rauschabstand groß genug ist, nur dann ists schon leicht verzerrt.
könnte ev der sig/rauschabstand eingestellt werden, bzw in der xml eingestellt werden?
wäre doch n versuch, nur leider weiß ich nicht ob das so einfach zu lösen ist ?

cu

edit:
...Ich habe einen Default-Wert von "#define SQUELCH_LEVEL 2000" eingestellt (hardcoded in MonitorModuleZVEI.cpp)...

da habe ich jetzt ein wenig mit gespielt :-)
im moment steht er bei mir auf 20 ! ... nicht hauen... :-)

zvei wird nun erheblich besser erkannt! muß nun mal einen längeren test fahren. alle 5-ton folgen die ich ihm nun vorgesetzt habe seien sie noch so verraucht oder verzerrt, wurden nahezu alle erkannt.und das in zimmerlautstärke :-)
mal sehen was kommt, wenn mein scanner mal was rausjagt.

[mdi]

Moinmoin,

könnte ev der sig/rauschabstand eingestellt werden, bzw in der xml eingestellt werden?
wäre doch n versuch, nur leider weiß ich nicht ob das so einfach zu lösen ist ?

doch, das war schon noch für "die Zukunft" geplant, ich habe mich nur noch nicht ausreichend mit dem XML-Parsing und dem Aufbau des Monitors befasst, sprich: Es wäre ja praktisch, wenn die XML-Config-Datei nur einmal ausgelesen werden müsste und den ZVEI-Modulen dann gesagt wird, wie groß die Parameter sein sollen. Das _geht_ bestimmt... :D.

...Ich habe einen Default-Wert von "#define SQUELCH_LEVEL 2000" eingestellt (hardcoded in MonitorModuleZVEI.cpp)...

da habe ich jetzt ein wenig mit gespielt :-)
im moment steht er bei mir auf 20 ! ... nicht hauen... :-)

Nein, warum hauen? Du hast mich auf einen wesentlichen Denkfehler hingewiesen! Die Geschichte war angepasst auf die bei mir auftretenden Wertebereiche. Das war Unsinn (eigentlich logisch ;D).
Ich habe den Filter jetzt angepasst durch Angabe einer Größe relativ zur Gesamtenergie des betrachteten Spektrums zur gegebenen Zeit (also ist nicht mehr die absolute 2000 oder 20 der Strich im Diagramm sondern ein 0.4 * gemessene_Gesamtenergie). Der Faktor 0.4 ist anpassbar, zur Zeit noch per define. Auch habe ich eine Debug-Möglichkeit eingefügt (default: false), ebenfalls per define anknipsbar. Die generiert dann ein Logfile der Energien der betrachteten Frequenzen. Klingt wüst, ist auch wüst und nicht zu empfehlen, es mit Logging länger als sagen wir ein, zwei Minuten laufen zu lassen.

Die Version steht im SVN.

Martin

[Buebchen]

Habe ein neue Version im SVN bereitgestellt. Im wesentlichen Designänderungen. Die SocketThreads, also die Komponentem, die mit dem verbunden Client spricht ist jetzt pro möglichem Client eine eigene Klasse. Damit ist es leichter spezifische Anpassungen durchzuführen, ohne die anderen Module berücksichtigen zu müssen.

Gerade für die angedachten Versionierungen beim monitord erscheint mir das sinnvoll. Ausserdem sind damit die crusader und FMS32 Module vom kommenden Ballast der Aufnahmesteuerung befreit :-)

Die neuen Klassen sind:

* SocketThreadMonitord
* SocketThreadCrusader
* SocketThreadFMS32

[MacLeod]

make geht nicht mehr... ???

s/monitord_monitord-MonitorModuleZVEI.Tpo -c -o monitord/monitord_monitord-Monit                   orModuleZVEI.o `test -f 'monitord/MonitorModuleZVEI.cpp' || echo './'`monitord/M                   onitorModuleZVEI.cpp
monitord/MonitorModuleZVEI.cpp:37: error: expected unqualified-id before â<<â to                   ken
make[1]: *** [monitord/monitord_monitord-MonitorModuleZVEI.o] Error 1
make[1]: Leaving directory `/home/tom/monitord/trunk'
make: *** [all] Error 2
tom@TomServer:~/monitord/trunk$

[mdi]

Hallo,

ich habe die aktuelle Revision 220 eben neu ausgecheckt und kein Problem finden können. Dein Fehler-Log besagt, dass in der Zeile 37 ein "<<"-Operator stehen soll. Das ist definitiv nicht korrekt; kann es sein, dass der Checkout irgendwie korrumpierte? Besteht die Möglichkeit, den /trunk bei Dir lokal zu löschen und neu auszuchecken?

Ich habe mittlerweile auch eine Ubuntu-Box (in einer virtualbox) laufen, allerdings tut der Mikro-Eingang nicht (Mist!). Auch dort konnte ich sauber auschecken und ./configure, make laufen lassen, was ein funktionsfähiges Binary ergab.

Martin
PS: Wow. Ich bin absolut fasziniert, wie schnell es hier mit allem möglichen weitergeht und wie kurz die Antwortzeiten bei Problemen sind :)!

[Buebchen]

Ich kann auch unter Ubuntu 6.06 keinen Fehler feststellen und würde auch einen neuen checkout vorschlagen.

[MacLeod]

jo!
trunk-ordner gelöscht und neu ausgechecked.
nu lüppt dat. komisch wer weiß was da broken war ....*grübel*

zvei funzt nun um welten besser! selbst die sirenenauslösung wird erkannt :-)))

alarme über den angeschlossenen scanner sind natürlich selten. habe auch nicht immer meinen "arbeitsrechner" am laufen.
gibts denn schon ne entwicklung in sachen "gespeicherter protokolle" zwecks langzeittest meine ich...

für den crusader oder fms32, wäre es doch toll wenn die protokolle irgendwie zwischengespeichert werden, muß ja nicht in ner datenbank sein, und beim aufruf des programms werden diese protokolle an das frontend übergeben.
ich weiß, ich wiederhole mich...
ich kann leider wie schon gesagt nicht programieren, sonst hätte ich mich da sicher ran gemacht.
ich weiß auch nicht in wie weit das überhaupt machbar ist. kann nur hoffen das es irgendwann klappt.

was habt ihr denn als frontend angeschlossen?

Gruß
Thomas

[einhirn]

monitord/MonitorModuleZVEI.cpp:37: error: expected unqualified-id before "<<" token

Das überzählige "<<" ist in diesem Fall wohl eine gewünschte Eigenschaft von Subversion.
Was passiert ist:

Subversion konnte einen Unterschied zwischen der aktuellen Revision und deiner Arbeitskopie nicht "mergen", es ist ein Konflikt aufgetreten - das sieht man beim Checkout an dem Buchstaben "C" vor dem Dateinamen.

Bei einem Konflikt legt Subversion 3 temporäre Dateien an, das sieht dann hinterher z.B. so aus:

MonitorModuleZVEI.cpp.r1
MonitorModuleZVEI.cpp.mine
MonitorModuleZVEI.cpp.r5
MonitorModuleZVEI.cpp

Die ".r1"-Datei (Revision 1, Beispiel) ist die Revision, die Du ursprünglich ausgecheckt hattest. Da Du die Datei geändert hast, wird die geänderte Kopie als .mine-Datei gesichert. Die ".r5"-Datei (Revision 5, Beispiel) ist die aktuelle Revision vom SVN-Server. Zu guter letzt gibt es noch die Datei ohne zusätzliche Endung: In dieser Datei sind die entscheidenden Zeilen von sowohl Deiner Änderung, als auch der Änderung die durch den SVN-Checkout in die Datei kommen sollen. Getrennt wird dabei mit Zeilen wie "<<<<<<< .mine" "=======" ">>>>>>> .r5".

Um diesen nicht automatisch behebbaren Konflikt zu beseitigen, machst du entweder ein

svn revert 

um die Originalversion wiederherzustellen oder du editierst die Datei ohne zusätzliche Endung derart, dass die SVN-Konfliktmarker raus sind und der "Konflikt" behoben ist. Das musst du SVN dann noch sagen und zwar mit

svn resolved 

Mehr (Ausführlicheres) zu dem Thema gibts (scheinbar nur in Englisch) im SVNBook unter:
http://svnbook.red-bean.com/ (Einstiegsseite)
http://svnbook.red-bean.com/en/1.4/s....cycle.resolve (Direktlink zur Konfliktlösung)

bye
Einhirn