Bastelt jeder jetzt im privaten weiter?
Druckbare Version
Bastelt jeder jetzt im privaten weiter?
Also ich schon :-)
Wobei eben wie bei allen anderen auch die Zeit nicht soo üppig da wäre, daß ich "mal so eben" 20 Stunden pro Woche da rein stecken könnte ...
Umso mehr ein Grund, dass alle (oder ein größerer Kreis) zusammenarbeiten. Es muss doch nicht das Rad x-mal parallel neu erfunden werden!?Zitat:
Zitat von Buebchen
Das Projekt lief doch so schön an und nun trennt sich alles wieder auf... schade!
Gruß,
Funkwart
So ist es nicht gemeint, oder gewollt. Aber es macht aus meiner Sicht keinen Sinn eine Working-Copy ins SVN zu stellen, die noch nicht fertig ist. Ich frage mich nur, wer denn eigentlich noch am Projekt mitwirkt. So wirklich viel "andere" Bewegung ist aus meiner Sicht nicht mehr festzustellen. Beschäftigt sich wirklich jemand anders noch mit dem Quelltext ?Zitat:
Zitat von funkwart
Hmm... SVN bietet doch prima Möglichkeiten, um neben funktionierenden Versionen ebenfalls noch "nicht funktionierende, weil gerade dran entwickelt wird"-Versionen einzustellen - Stichwort "Tags".Zitat:
Zitat von Buebchen
Und ich halte es für wichtig, das du deine Arbeit dort ablegst - erstens kann dir evtl. der eine oder andere dann noch zuarbeiten, zweitens sieht man vielleicht, dass es vorangeht, drittens ist deine Arbeit dann "gesichert" - sprich sollte Dir oder deinem Rechner samt Backups ($Gottheit/Höhere Gewalt behüte) etwas zustoßen, so gäbe es immerhin noch die Kopie im SVN, so dass Deine Arbeit weiterführt werden könnte.
bye
Einhirn
Das mit den Backups würde schon noch gehen :-) Da müßte noch so einiges mehr in Rauch aufgehen als mein PC. Das ist einer der Vorteile, wenn man beruflich mit IT zu tun hat...Zitat:
Zitat von einhirn
Ich hatte schonmal überlegt nen tag dafür zu machen. Wobei das natürlich immer noch die Frage offen läßt, ob sich da überhaupt noch andere mit befassen werden. Werde die Tage nen branch anlegen und hochladen. Ein tag ist nach meinem Verständnis eher ein als "release" eingefrorener Versionsstand (wobei das im Zeitalter des svn technisch betrachtet genau das gleiche wie ein branch ist).
Tja, bei uns in der IT-Abteilung wird immer vermieden, dass über ein Projekt nur genau einer Bescheid weiß, und Passwörter werden an einem sicheren aber für bestimmte Mitarbeiter der IT-Abteilung zugänglichen Ort hinterlegt. Den Aufwand treiben wir - neben normalen Datenbackups - um auch für den Fall "Mitarbeiter von Omnibus überrollt, liegt jetzt glücklicherweise nicht tot, aber dummerweise mit Gedächtnisverlust im Krankenhaus" einen Ausweg haben und z.B. wichtige Systeme weiterhin gewartet werden können.Zitat:
Zitat von Buebchen
Ich warte gespannt - schließlich bin ich sehr an einem ZVEI-Decoder für Windows interessiert, den ich kostenlos erhalten kann - dafür würde ich auch mal in den Code gucken ;)Zitat:
Zitat von Buebchen
bye
Einhirn
So, branch 2.1.1-merginWinLin erstellt und meine working copy importiert.
Zur Zeit arbeite ich mit MSYS und Eclipse/CDT unter Windows XP.
./configure --enable-plugins
baut bei mir ein geeignetes Makefile. Unter Linux hatte ich - wenn ich mich nicht irre - noch ein paar Änderungen gemacht. Ich weiss nicht, ob ich die schon in der Windows working copy drin habe...
über aktive Mitarbeit würde ich mich freuen, da das ja auch ein Ansporn ist, die Sache bis zum Ende zu entwickeln ...
Hallo,
auf der Suche nach einem "simplen" ZVEI-Auswerter für unseren Betriebsfunk bin ich auf Monitor und die aktuelle Entwicklung gestoßen. Die Sourcen des 2.1.1-mergeWinLin habe ich ausgecheckt und mit MSYS kompilieren können. Das Binary ist lauffähig, seine TCP-Ports per Telnet erreichbar. Eine ZVEI-Tonfolge über das Mikrofon am Rechner auszuwerten gab jedoch nichts aus (nach Korrektur der monitord.xml -> eigene IP-Adressen als "ohne Login" eingetragen).
Bevor ich mich jetzt durch alle Sourcen wühle um den bisherigen Funktionsumfang herauszufinden: Gibt es irgendwo eine Liste der bereits implementierten Funktionalitäten des monitord und wo die echen Knackpunkte/Probleme noch vorliegen? Ich habe versucht, mir diese Infos aus den bisherigen Beiträgen dieses Threads herauszudestillieren, aber ich bin irgendwann stumpf gescheitert, wichtige Feature-Wünsche, Bugs und Fernziele von den bestehenden Features zu trennen :/. Die Sourcen sind dann doch recht umfangreich, von daher wären mir kleine "Pointer" sehr wichtig.
Für eine kurze Info darüber hier im Forum wäre ich sehr dankbar, dann wüsste ich genauer, ob und wo ich vielleicht helfen kann (oder ob nicht =)).
Viele Grüße
Martin
Welcher ZVEI Standard wird genutzt ?
In der MonitorModuleZVEI.cpp ab Zeile 80+ werden die Frequenzen der einzelnen Töne definiert. Das ist für ZVEI 1 z.Zt. richtig. Andere Normen werden damit vermutlich nicht klappen. Da wir seit langem mit POCSAG arbeiten ist da mein Wissen ein wenig verblasst :-)
Zum Testen unter windows nehme ich das BOSTool (www.gibma.de). Das erzeugt sehr "klare Töne". Mit Audacity kann man dann ja immer noch ein Rauschen beimischen.
Hallo Buebchen,
das mit dem Standard ist so ein Problem... *g*.
Wir nutzen Fünftonfolgen des ZVEI-1 (wenn ich mich recht entsinne), allerdings haben wir unsere Geräte dahingehend modifiziert, dass die Tonfolge nicht doppelt (wie vorgesehen) gesendet wird: Bei uns geht als erstes die Nummer des Gerufenen raus und dann die des Rufenden (dann sieht der Gerufene gleich, wer denn rief). Entsprechend müsste ich auch schauen, ob die Rufe in moitor einzeln oder zusammen ausgewertet werden. Danach sendet der Gerufene einen Quittungsruf (seine Kennung), ebenfalls als einfachen Fünfton.
Was ich noch gern wüsste ist: Wie weit ist denn der Funktionsumfang unter Windows mittlerweile? Ich habe mal in den Code geschaut und meinte gesehen zu haben, dass da noch keine Weitergabe der Soundbuffer an die Auswerter geht, oder habe ich nicht genau genug hingeschaut? Was kann denn der Windows-Port schon und was noch nicht?
Vielen Dank für die Antwort aber schonmal :)!
Martin
Der Windows-Port kann alles das, was die linux Version auch kann. Wobei es nicht zu 100% der Leistungsumfang des alten monitor-1.8.1 ist, da erst mit der neuen Version ein einigermassen vernünftiges Klassenkonzept dazugekommen ist.
Die ZVEI Auswertung ist ein wenig wackelig. Da wird z.T. der allererste Ruf nach dem Programmstart meist falsch erkannt. Danach ist es dann ok (bis auf einige Aussetzer).
Am besten machst Du ein paar Debug-Ausgaben im ZVEI Modul. Ich würde da mit cout einfach mal alle erkannten Ziffern ausgeben. Das müßte ja zu deiner Einspielung passen. Das ZVEI Modul achtet auch auf die Pausen. Das müßtest Du dann ggf. dann auch noch anpassen.
Übergabe der Sounddaten erfolgt übrigens in SndPipe::DataFromSoundIn() :-)
Hallo Buebchen,
erstmal herzlichen Dank, das war genau das, was mir jetzt weiterhalf :).
Ich habe festgestellt, dass unsere "gemischten" Tonfolgen problemlos erkannt und decodiert werden können, jedenfalls meistens. Auch habe ich gesehen, dass der Monitord so weit gut läuft, allerdings beim Beenden einen Fehler schmeißt (ist nicht als Dienst installiert).
Erstmal möchte ich ein herzliches Dankeschön an alle am monitor für Windows mitarbeitenden Entwickler der Vergangenheit und Gegenwart loswerden :)!
Viele Grüße
Martin
Hallo nochmal von mir,
ich habe jetzt einige Zeit in Ruhe am Code gesessen - und vor allem die demod-Methode des ZVEI-Moduls neu geschrieben.
Es waren einige Merkwürdigkeiten im Verhalten zu beobachten (unter anderem auch bei der Ausgabe, bei der Fünfton-Folgen mit führender Null gar nicht erst angezeigt wurden, da alles unter 10000 mit einem "return" abgebrochen wurde). Ich habe eine neue Logik geschrieben, die bei meinen Tests recht robust war und auch eine längere Alarmierungsfolge problemlos geschluckt und wie gewünscht ausgegeben hat. Eine "Achttonfolge" habe ich mit dem alten Code reproduzieren können, der neue brachte sie bisher nicht an die Oberfläche.
Die Auswertung des Sirenentons beruht zur Zeit lediglich auf der Auswertung der 1240Hz (obere Hälfte des Doppeltons für den Feueralarm); da war vorher ein Spezialfall definiert, der jedoch auch merkwürdige Dreckeffekte bei der generellen Auswertung der Tonfolgen brachte.
Ich achte _grob_ auf Pausen. Perfekt ist das nicht, lässt sich aber vermutlich nachrüsten. Die Pause-Geschichten liefen im mir vorliegenden Code auch nur unrund, schien mir - jedenfalls gab es da unreachable code und ein "#define Pause" vor einem "return PAUSE", dahinter dann irgendwelche Berechnungen von Pausenzeiten in der Methode "get_pause" - die flog jetzt gnadenlos raus.
Die Ausgabe-Bedingungen sind die folgenden:
a) "unklare Ausloesung" (0) bei "eine Fünftonfolge gelesen, neue Ziffer erkannt" (entsprechend der nächsten, in geringem Abstand zur vorherigen geschickten Tonfolge).
b) "Melderausloesung" (1) bei erkannter Fünftonfolge und erkanntem Melderweckton.
c) "unklare Ausloesung" (0) bei zu langer Pause nach Abschluss der Fünftonfolge aber fehlenden Melder/Sirenentönen.
d) "Sirenenausloesung" (2) bei erkannter Fünftonfolge und anschließendem Sirenenton wie oben geschrieben (NUR die 1240 Hz).
Die Fälle 1 und 2 (Melder und Sirene) ignorieren Zeitbeziehungen, sprich sie schlagen an, sobald der Weck- oder Sirenenton innerhalb der Timeout-Zeit erkannt wird. Das sollte OK sein, da der Melderton (2600 Hz, wie der Ton für die Wiederholung) nicht als erstes Zeichen stehen kann und der Sirenenton 1240 zwar der 1270 (Ziffer 3) nahe liegt aber der Abstand ausreichend groß sein müsste. Ich messe keinerlei Längen der einzelnen Töne (70ms wäre Standard für eine Frequenz/eine Ziffer), das ist entsprechend im Code kommentiert - allerdings aufgrund der Geschichte mit dem Wiederholungston auch nicht so wichtig (da nicht zweimal der selbe Ton kommen darf, wäre eine Zeitbeziehung einzubauen im Ergebnis nur der Hinweis auf einen falsch arbeitenden Sender).
Was war noch *grübel* - ach ja: Ich verbrauche jetzt möglicherweise eine Kleinigkeit mehr Speicher, da ich die Fünftonfolge in "int zvei_folge[5]" ablege statt in einem Konstrukt, auf das mit Bits geschossen wurde. Sicherlich war das elegant, macht den Code aber schwerer verständlich. Auf der anderen Seite habe ich einige Variablen gespart - ich habs nicht nachgerechnet.
Ja... Patches sind erstellt, soll ich die jemandem mailen oder selber ins SVN einpflegen (Zugang vorausgesetzt)?
Viele Grüße
Martin
Das klingt ja richtig toll. Ich denke, ein eigener Commit wäre sinnvoll. SVN Zugangsdaten gibts bei jhr-online.
Bin sehr gespannt.