Druckbare Version
Wie siehts mit POC1200 aus? Da geht bei mir gar nichts.Zitat:
Zitat von Buebchen
Dennoch wäre es schön, wenn du den Code dafür zur Verfügung stellen könntest. Mach das Frontend nur POC oder auch ZVEI und FMS?Zitat:
Frontend ist selbstgehäkelt und extrem minimalisitisch ( aber immerhin web-basiert :-)
Auch da wäre es nett, wenn du den Code irgendwo publizieren würdest.Zitat:
Zitat von DocSteel
viele Grüße,
Andreas
Zu POCSAG mit 1200 Baud kann ich nix sagen, da wir auf 512 Baud laufen.
Den PHP Code suche ich mal raus. Ist natürlich alles hard-wired :-)
Soweit ich mich erinnere, stammt der Code von dir. Hast du das noch nie mit poc1200 probiert?Zitat:
Zitat von Buebchen
Macht nix. Ein paar erklärende Kommentarzeilen im Code wirken Wunder.Zitat:
Den PHP Code suche ich mal raus. Ist natürlich alles hard-wired :-)
viele Grüße,
Andreas
Ich hab lediglich das PHP Frontend aus dem Thread hier genommen (Danke an den Urheber) und es um ein paar Kleinigkeiten verfeinert insbesondere:
- Automatische Aktualisierung (alle xx Sekunden) via PHP Header
- Eine Anzeige wann das Frontend zum letzten mal aktualisiert wurde
- Anpassen der HiOrg Liste auf die Bedürfnisse des Kreises
- RIC Filter (Rics die nicht in die DB geschrieben werden sollen) siehe dazu auch meine Lösung hier: http://funkmeldesystem.de/foren/show...78&postcount=3
Ansonsten funktioniert wie schon geschrieben die 1200 Baud Pocsag Auswertung mit einigen kleine Problemchen. FMS und ZVEI wird hier mangels Eingangssignal momentan nicht betrieben.
Das Frontend stelle ich zum Download bereit sobald ich dazu komme da ein Paket draus zu packen.
Nein - der Code ist nicht von mir. Der Code selbst stammt aus dem monitor Projekt (bzw. multimon). Ich habe zwar einige Teile bearbeitet, aber die Kernkomponenten sind erhalten geblieben. Ich hätte auch zu wenig Erfahrung in Software PLLs um eine anständige und gleichzeitig CPU schonende Sync "mal eben" zu schreiben :-) Da bleibe ich bei dem, was ja schon lange läuft. Ich habe den C Spaghetti-Code nur einmal kräftig entwirrt, damit das Ding überhaupt vernünftig bearbeitet werden kann.Zitat:
Zitat von nepomuck
Ich würde mir das Ganze gerne auch mal unter Windows ansehen. Was brauche ich an Software, um monitord unter Windows 2003 zu bauen?Zitat:
Zitat von Buebchen
Danke,
Andreas
Du kannst zum einen die Installer-Version für Windows nehmen oder aber wenn Du selbst bauen müßtest findest Du hier eine tolle Anleitung von mdi:
http://www.funkmeldesystem.de/foren/...ad.php?t=35783
hallo kannst du mir die Frequenzen Dithmarschen sagen vom digitalen funkmeldernZitat:
Zitat von funkwart
Wenn ich es könnte, dürfte ich es nicht.
Aber mach Dich doch mal im Internet schlau, z.B. hier:
http://www.funkfrequenzen01.de/bos3sh.htm
Gruß,
Funkwart
Hi,
könnt ihr mal aus dem aktuellsten Trunk einen neuen Windows Installer kompilieren und veröffentlichen?
Die Version auf der HP ist ja inzwischen ein halbes Jahr alt. Selber kompilieren geht leider nicht da ich nur 64 bit Systeme habe und ich die Anwendung auf ein 32bit Windows portieren muss auf dem ich nicht kompilieren kann.
Und im Anhang noch ein Bild auf ein Frontend für den monitord an dem ich die letzten Tage etwas rumgeschrieben hab. Wenn interresse besteht kann ich davon mal eine Version veröffentlichen.
http://www.projekt-webspace.de/pic/s...i4monitord.jpg
Gruß
HP
Moin,
ist oben. http://www.monitord.de/?article=5Zitat:
Zitat von HeckenPenner
Gern! In welcher Sprache hast Du das geschrieben?Zitat:
Zitat von HeckenPenner
Viele Grüße
Martin
PS: Ich habe ein Tag im SVN eingerichtet: Aktueller Stand heute, oben genanntes Binary, Name: 2.0-060808-RC1.
Ah, verdammt, jetzt muss ich euch hier doch belästigen.
Seit vielen vielen Stunden versucher ich monitord ans Laufen zu bekommen. Das tuts auch so weit, aber offenbar funktioniert etwas mit den Servern nicht. Es werden keine Ports geöffnet, nmap sagt mir alles ist dicht (sowohl 127.0.0.1 als auch "reale" ip) und telnet kommt auch nicht durch. Woran kanns liegen?
Mein tcpsocket sieht soweit richtig aus, habe mal zwischen bind sowohl das interface als auch die ip gesetzt
(bind) eth0 (/bind)
(bind) 192.168.178.23 (/bind)
so etwa.
Würde mich über Hilfe freuen,
Gruß,
Bene
P.S. Das system ist logischerweise Linux, also ein Sidux 2008-02.
Vielen Dank an die und Hut ab vor den Leuten die ihre Freizeit opfern um der Welt so geniale Programme zur Verfügung zu Stellen =)
EDIT: Verdammt, da war ja was mit den Spitzklammern... Runde Klammern sind in meiner monitord.xml spitz ;)
Moinmoin,
na also sowas aber auch ;)!Zitat:
Zitat von ToffiFee
Ich habe den Code nicht geschrieben, daher ganz direkt drei Fragen:Zitat:
Zitat von ToffiFee
a) sind Mehrfachangaben zum jetzigen Zeitpunkt erlaubt? (-> Buebchen?)
b) welche Eingaben können hier getätigt werden (eth0 eher nicht, wenn ich den Code richtig interpretiert habe)?
c) hast Du, ToffiFee, es mal beim * belassen und tut der monitord dann etwas?
Viele Grüße und gute Nacht
Martin
habs auch mal mit dem vorkonfigurierten "*" belassen, der monitord tut aber dasselbe wie mit allen anderen einstellungen:
<code>
toffifee@siduxbox:~$ monitord
02:36:54.255 INFO: monitord/SocketServer.cpp(660) SocketManager erstellt
02:36:54.256 DEBUG: monitord/MonitorSignals.cpp(21) Signal erstellt...
02:36:54.256 INFO: monitord/MonitorModulesResults.cpp(51) Dispatcher startet
02:36:54.259 DEBUG: monitord/MonitorModulesResults.cpp(88) Dispatcher waiting
02:36:54.260 DEBUG: monitord/MonitorSignals.cpp(60) Waiting for signal
02:36:54.273 DEBUG: monitord/MonitorSignals.cpp(21) Signal erstellt...
Loglevel: INFO
</code>
sieht fuer mich danach aus als waere alles in ordnung, nur wie gesagt, nmap und co. sagen mir saemtliche ports sind zu. Die firewall ists nicht, die ist hardwaremaessig erst ab gateway, software habe ich keine (meiner Meinung nach obsolet).
<code>
Starting Nmap 4.62 ( http://nmap.org ) at 2008-08-07 02:37 CEST
Interesting ports on localhost (127.0.0.1):
Not shown: 1707 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
631/tcp open ipp
3000/tcp open ppp
3306/tcp open mysql
</code>
Gruß,
Bene
Super! Danke!Zitat:
Ich habs in Python und wxWidgets geschrieben weil ich die UI Gerne auf allen Platformen nutzen würde. Aber ohne Anpassungen gehts leider nicht.Zitat:
Gern! In welcher Sprache hast Du das geschrieben?
Gruß
HP
Und gleich nochmal was...
Der Server sendet jetzt zur Begrüßung ein "100" ['100', 'monitord 2.0svn READY']
Früher hat er ein "110" gesendet!
Ist das gewollt?
Gruß
HP
Aaaalso:
Der Server läuft jetz... Mit derselben Konfiguration wie vorher, nur habe ich den Port jetzt einfach mal auf 111 gestellt. Telnet sagt mir:
110:monitord 2.0svn READY
Also bei mir nix 100. Weiß jemand woran das liegt das es auf den Standardports nicht läuft?
Gruß,
Bene
Moin,
fuck, hatte ich hier zu schreiben vergessen und auch nicht im SVN eingecheckt sondern nur lokal bei mir geändert und aus den Sourcen den Installer gedreht.Zitat:
Zitat von HeckenPenner
Ja, das ist so gewollt, jedenfalls von mir und ich sollte das mal ins SVN einchecken. 110 ist laut Protokoll-Defnition "Inquiry" und nicht "OK". Daher muss hier eine 100 hin.
Martin
PS (edit): Noch was zum Inquiry, ist es überhaupt sinnvoll, dass der Server ein inquiry macht? Normalerweise muss der Client ja den Server connecten und fragen, was er kann und schauen, ob das zu seinem Befehlssatz matcht. Wenn nicht... pech ;).
Moin,
die 100/110 habe ich ein Posting eher erklärt ;). Ich checks ein gleich...Zitat:
Zitat von ToffiFee
Dass er nicht auf "seinem" Port läuft, ist komisch. Hast Du dahin auch mal per telnet connected?
Martin
Klaro. Aber wie gesagt, alles dicht. Wenn ich per telnet auf 111 connecte kommt das protokoll richtig an, er decodiert richtig, die Befehle laufen usw. Habs grad mal mit Port 5000 probier (einfach mal irgendeinen zum Testen genommen, völlig random), da funktionierts auch. Keine Ahnung woran das liegen könnte, wie gesagt, firewall und son Schmarrn hab ich nicht ;)Zitat:
Zitat von mdi
Übrigens, kann mir jemand ein fähiges Webinterface empfehlen?
Gruß,
Bene
EDIT:
Es geht! Man weiss nicht warum, aber nachdem ich den Port nochmal auf 9333 gesetzt habe laeuft es. Verdammt, ich versteh das nicht, aber mir egal, er läuft =)
Danke Danke Danke für alle vergeblichen versuche mir unter die Arme zu Greifen, manchmal bedarf es eben einer höheren Macht ;)
Aber son Webinterface interessiert mich dennoch ;)
Ok, danke!Zitat:
Zitat von mdi
Find ich jetzt zwar schade, denn das bringt mir den gesamten Login Vorgang durcheinander, macht aber auch mehr Sinn.
Inquiry ist Sinnvoll in so fern, dass der Server abwärtskompatibel ist und auch mit älteren evtl. nicht mehr gepflegten Programmen zusammenarbeiten kann. Dazu müssen sich die beiden halt auf eine Protokoll Version einigen und das geht dann nur per Inquiry.
Gruß
HP
Moinmoin,
wem sagst du das... ;D!Zitat:
Zitat von ToffiFee
Dazu gab es hier im monitor-Forum auch schon einige Diskussionen; wie weit die aktuellen Vorhaben derzeit sind, kann ich Dir nicht genau sagen - im SVN gibts aber auch ein Web-Frontend zu finden (PHP).Zitat:
Zitat von ToffiFee
Ja, das glaube ich Dir aufs Wort :7. Tut mir leid.Zitat:
Zitat von HeckenPenner
Ja sicher, nur ist die Frage: Warum sollte der Server den Client fragen, was der kann? Dass der Client den Server fragt und dann sagt, er möchte mit Version xy sprechen, ok. Aber dass der Server den Client fragen kann und/oder sollte, hat mich grad verwirrt ;).Zitat:
Zitat von HeckenPenner
Viele Grüße
Martin
Strenggenommen sollte das eigentlich aussehen:Zitat:
Zitat von mdi
Wenn die Verbindung steht, sendet der Server ein nacktes 100 als OK, ohne Versionsnummer oder Sonstwas, denn der Befehl 100 hat keine Parameter.
Der Client soll dann einen 210 (inquiry vom Client) an den Server schicken, welcher als Antwort mehrere 111er liefert und dem Client so mitteilt, was der Server alles kann.
Der Server könnte im Gegenzug vom Client ein Inquiry 110 einfordern, auf das der Client mit 211ern antwortet. Diese Funktion ist dafür gedacht, falls jemand auf dem Server eine Liste aktuell angemeldeter Clients verwalten will. Soweit ich weiss, ist das Feature aber im server noch nicht implementiert.
Danach soll von Seiten des Clients der Login "220" erfolgen, der als Paramter den Usernamen, das Passwort und die gewünschte Protokollversion enthält.
Aktuell arbeiten die Test-Setups ohne Logins und daher antwortet der Server momentan direkt mit 100 und Version -- das ist strenggenommen so nicht zulässig.
Die Protokolldefiniton 0.3 berücksichtigt den Sonderfall "Autologin" nicht -- hier sollten wir uns überlegen, wie wir das künftig korrekt handhaben.
viele Grüße,
Andreas
Warum ist ein 100 ...ready unzulässig ? Im Grunde genommen wird der TCP Connect damit bestätigt. Aber wir können da auch gerne einen anderen Code nehmen - Sozusagen für die welcome message ( Vgl. SMTP: "220 Server ready" - nach dem connect ).
Was genau beim bind geht muss ich nachsehen. Ich meine im Moment gehen ausschließlich IP Adressen. Ggf. noch hostnamen. Interfacenamen aber bestimmt nicht. Wäre auch nicht unter windows und Unix kompatibel in dem Fall.
Wir hatten und bei der Protokolldefinition auf etliche Standards geeinigt:Zitat:
Zitat von Buebchen
- Alle Kommandos und Quittungen sind rein nummerisch, Parameter sind durch ":" getrennt und, falls alphanummerisch, in Ascii codiert.
- Das Kommando "100" ist nicht mehr als eine positive Quittung auf ein vom Client abgesetztes Kommando. Laut unserem Standard gibt es bei "100" einfach keine Folgeparamter.
Folglich ist "100 Version xyz Ready" eine unzulässige Antwort.
Für die Beta-Versionen ist sowas ganz nett, da man viel mit einem Telnet-Client arbeitet und sehen will, was los ist. Aber wenn die ersten, richtig funktionellen Forntends da sind, müssen sich die Backend- und Frondend-Entwickler exakt an die Protokolldefinition halten -- sonst wird das ganze nicht funktionieren.
Das Thema hatten wir schon einmal und haben uns damals gegen eine "lesbare" Welcome-Message entschieden, da ein trockenes "100" als positive Verbindungsbestätigung völlig ausreicht. Und für den Austausch der exakten Versionsinformationen haben wir deshalb das Inquiry-Kommando (210 vom Client an den Server oder 110 vom Server an den Client) mit einer mehrzeiligen Antwort festgelegt. Wobei die Klartextmeldungen Ascii codiert werden müssen.Zitat:
Zitat von Buebchen
Ich zitiere das Protokollmanual:
Alle Programmierer müssen sich an die Protokollstandards halten. Wenn jeder eigene Protokollvarienten implementiert, wird die Kommunikation zwischen Client und Server einfach nicht funktionieren.Code:Beispiel (in allen Beispielen wird der Text zwecks der Lesbarkeit in „“ angegeben, statt in ASCII
kodiert):
210 (=Inquiry-Anforderung vom Client)
111:1:“monitord“ (sieht in wirklichkeit so aus: 111:1:6D6F6E69746F7264)
111:2:“LINUX“ (111:1 = Name des Servers, 111:2=OS des Servers 111:3 = Version )
111:3:0021
111:4:0010
111:4:0020 (111:4 = unterstützte Protokollversionen)
111:4:0021
111:5:"REC" (111:5 = unterstützte Module dieses Servers)
111:5:"MYSQL"
111:0
viele Grüße,
Andreas
Wenn ich das mal so sagen darf:
1. Ich sehe zum einen kein Frontend, daß in absehbarer Zeit zur Verfügung steht
2. Das aktuelle Frontend muss zwangsläufig mit diesem Protokollbruch schon umgehen können, um zu funktionieren. Demzufolge ist es mehr Aufwand die Programme an das Protokoll anzupassen als andersherum.
Wozu haben wir uns dann überhaupt auf einenen Protokollstandard geeinigt, wenn sich keiner dran hält?Zitat:
Zitat von Buebchen
Client/Server-Applikationen können nunmal nur dann richtig funktionieren, wenn das Protokoll eindeutig vorgegeben ist und sich alle daran halten.
Natürlich können wir jederzeit eine neue Protokollversion 0.4 deklarieren, welche diese Änderungen berücksichtigt.
Ich sehe darin aber keinen Sinn. Warumm sollte der Server klar lesbare Meldungen von sich geben? Das Ziel dieser ganzen Entwicklung ist es doch, dass Client-Tasks mit dem monitord kommunizieren und nicht die Anwender per Telnet die Kommandoausgabe verfolgen, oder?
Dein Änderungswunsch hebelt gleich mehrere Syntaxregeln aus, auf die wir an dieser Stelle vor etlichen Monaten gemeinsam geeinigt hatten:
Dazu gehört, dass Paramter mit ":" getrennt sind und dass wir keinen Klartext übermitteln. Zudem haben alle Kommandos klar deklarierte Paramter. Woran soll der Client erkennen, wann ein OK mit oder ohne Paramter daher kommt und was soll er überhaupt damit anfangen?
Willst du du diese durchaus durchdachten Syntaxregeln auf den Kopf stellen, nur damit der Server freundlich "Hallo" sagen darf?
Ich persönlich halte das für einen absolut kontraproduktiven Vorschlag, weil es die Programmierung von Frondends verkompliziert und das Fehlerrisiko bei der Kommunikation zwischen Client und Server erhöht.
Ich möchte einen Gegenvorschlag machen:
So lange das hier alles im Beta-Stadium ist, fügen wir dem Protokoll zu Debug-Zwecken eine Art Kommentarfeld hinzu:
Am Ende eines Kommandos kann ein ";" als Trennzeichen kommen und dahinter steht, was immer du auch möchtest. Die Client-Entwickler können sich darauf einstellen und einfach alles, was nach dem ";" kommt ignorieren.
Beispiel:
Dann haben wir den freundlichen "Hallo" ohne das Protokoll zu vermurksen. Bei Erreichen einer Final-Release können wir das Kommentarfeld einfach sausen lassen, ohne dass die Clients umprogrammiert werden müssen.Code:S->C nach Verbindungsaufbau
100;Hallo von CVS 0.5.6a-xy auf Debian
C->S
220;sag mir, wer du bist
111:1:6D6F6E69746F7264;CVS 0.5.6a-xy auf Debian
....
Ist das ein akzeptabler Vorschlag?
viele Grüße,
Andreas
Hmm. Ich sollte so spät keine Postings schreiben ... Irgendwie klingt das etwas sehr "unfreundlich". Sorry dafür.
Zum Thema:
Generell halte ich ";" für sehr sinnvoll und würde es auch im Final drin lassen. Der Grund ist einfach. Wenn man mal debuggen will kann der arme Programmierer schneller erfassen, was da geschieht. Das ist ja auch der Grund warum eben bei einem täglich millionenfach genutzten Protokoll wie SMTP solche Ausgaben immer noch vorhanden sind.
Selbst SSH beginnt übrigens mit einer Klartextmeldung. Das soll nur verdeutlichen, daß ich nicht der einzige verirrte Geist bin der glaubt, daß menschenlesbare Meldung einen Nährwert haben können :-)
Also dann lass uns das so machen, daß Meldungen mit einem ";" noch einen lesbaren Kommentar bekommen können. Ich finde das eine sehr gute Lösung. Prima !
Moin,
hm... grundsätzlich fällt mir spontan kein echtes Gegenargument ein (außer dass das halt die sonstige Trennung am Doppelpunkt ein wenig verwurstet). Ein optionales Protokoll-Feld mit Doppelpunkt-Trennung ist aber nicht so günstig falls mal Felder hinzukommen, von daher trennt das ; einen Kommentar eindeutig.Zitat:
Zitat von Buebchen
Also: [x] - nicht dagegen.
Ich möchte kurz noch einen Verweis hier einbringen: Ich habe einen neuen Thread hier im Forum erstellt mit der Bitte um Kommentare -> http://www.funkmeldesystem.de/foren/...ad.php?t=39572 (Thema: Aktueller Stand der Dinge?). Würd mich über hilfreiche Antworten freuen :)!
Viele Grüße
Martin
Nix passiert.Zitat:
Zitat von Buebchen
OK. Ich füge das so in die Protokolldeklaration (ab sofort 0.3a) ein.Zitat:
Zitat von Buebchen
Kommentar:
Ein ";" am Ende eines Kommandos signalisiert einen Kommentar. Dieser folgt im Klartext, darf aber keine Sonderzeichen (0x00 - 0x19) enthalten.
Bis zum ";" haben wir den "maschinenlesbaren" Teil, wie bereits in Protokollversion 0.3 festgelegt, danach folgt der "menschenlesbare" Kommentar. Das ";" steht auf jeden Fall am Ende eines Komandos nach allen Parametern.
Ein ";" kann jedem Befehl anhängen, muss das aber nicht.
Ich crossposte die Protokolländerung dort. Dann sieht's hoffentlich jeder.Zitat:
Zitat von mdi
viele Grüße,
Andreas
Murks! Eine Versionsnummer 0.3a läßt sich natürlich nicht wie vorgesehen mit dem Inquiry-Kommando übermitteln!.Zitat:
Zitat von nepomuck
Also: Aktuelle Protokollversion = 0.4, was beim Inquiry dann so aussieht: "111:4:004"
viele Grüße,
Andreas
Version 4 ist jetzt implementiert ( sprich Klartext beim welcome durch Semikolon getrennt ).
Moin!Zitat:
Zitat von Max K. - auf Seite28
Könnten wir das hier mal pushen? ich hab das gleiche Problem... Hab auch schon etwas gegoogelt, andere Soundkarte probiert und das System (hier ein Suse10.3) neu installiert, leider ohne Erfolg.
Wäre gut wenn hier jemand noch die eine oder andere Idee hätte
Danke!
Hast du in deinem System überhaupt ein Gerät "/dev/dsp". Je nach Distribution könnte das auch "/dev/dsp0" heißen und müsste entsprechend in der Konfiguration angegeben werden.Zitat:
Zitat von Bubu80
Wenn ein "/dev/dsp" vorliegt, wie lauten dann die Rechte? Darf der User in dessen Dunstkreis monitord arbeitet auf "/dev/dsp" lesend zugreifen?
Wenn nicht, dann probier mal dem Device andere Rechte zu geben. Führe als Root aus:
und probiere es dann nochmal.Code:chmod a+rw /dev/dsp
viele Grüße,
Andreas
Hallo Nepomuck,
danke das du dich meldest.
Ich hab ein file "-dsp" in meinem /dev, ebefalls liegt dort ein Verzeichnis "/snd". da ich erstmal die Fehler finden wollte, arbeite ich als root in meinem SuSE 10.3...
In dem /snd Verzechniss finden sich weitere Anschlüsse: pcmC0D0c, pcmC0D0p, pcmC0D1p, seq, timer, midiC0D0 und control0
Habe jede Datei schon mal in der Konfig angezeigt, immer ohne erfolg...
Gruß
Bubu
also bei mir das gleiche...Zitat:
Zitat von Bubu80Moin!Zitat:
Zitat von Max K.
Könnten wir das hier mal pushen? ich hab das gleiche Problem... Hab auch schon etwas gegoogelt, andere Soundkarte probiert und das System (hier ein Suse10.3) neu installiert, leider ohne Erfolg.
Wäre gut wenn hier jemand noch die eine oder andere Idee hätte
Danke!
Für diejenigen, die den Fehler bekommen, daß /dev/dsp kein gültiges Device ist:
Da scheint was nicht zu klappen mit der Erkennung, ob ALSA ( Kernel 2.6 ) oder OSS genutzt werden muss. Das Device /dev/dsp gehört zu OSS.
Erster Versuch wäre es jetzt bei dem SuSE 10.3 mal zu gucken, ob man die OSS Emulation von ALSA irgendwo noch dazupacken kann ( vermutlich ist das einfach ein Modul um Yast ). Die Emulation ist schon im ALSA von Hause aus vorgesehen.
Also das alsa-oss packet ist bereits installiert...Zitat:
Zitat von Buebchen
-----------------
16:37:44.168 INFO: monitord/Monitor.cpp(67) logging started
16:37:44.180 INFO: monitord/Monitor.cpp(108) monitord 2.0svn READY^M
16:37:44.181 INFO: monitord/Monitor.cpp(205) starting soundcard #0
16:37:44.181 INFO: monitord/SndPipe.cpp(152) creating decoders for soundcard #0
16:37:44.181 DEBUG: monitord/SndPipe.cpp(201) creating decoder for soundcard #0L:POC512
16:37:44.181 DEBUG: monitord/SndPipe.cpp(212) creating decoder for soundcard #0R:POC512
16:37:44.181 INFO: monitord/SndPipe.cpp(259) loading audioplugins for left channel
16:37:44.181 INFO: monitord/SndPipe.cpp(261) loading audioplugins for right channel
16:37:44.185 INFO: monitord/Monitor.cpp(213) soundcard #0started
16:37:44.185 INFO: monitord/posix/MonitorAudioOSS.cpp(89) AudioThread /dev/dsp is running
-----------------
also soweit läuft alles, nur dekodiert er nichts. wie kann ich denn einfach meine soundmixer etc Einstellungen teste, dass ich sichergehen kann, dass etwas (Sound) beim Montor ankommt?
Hab auch schon versucht zu debuggen, ich bekomme z.B. nie ein Sync.... Und wie korrekte Audiodaten im Buffer auzusehen haben, weiß ich auch net.. :-(
Also im Yast ist bei mir auch das "alsa-oss" Paket installiert. Wo soll ich nun weiter gucken? Kann man denn eines von beiden System abstellen? Sollte man das?
..
Danke!
Bubu
Bei mir auch mit der aktuellen Version immernoch das gleiche Problem :-(
Ich kompiliere den monitor übrigens gerade auf einer NSLU2 mit Debian 4.0 drauf, wenn das problemlos durchläuft, spiel ich mit dem Gedanken, mir da ne USB-Soundkarte für zu holen.. Allerdings wärs doof, wenn ich auch dort das gleiche Problem mit dem monitor habe.. Hat da evtl. jemand einen Lösungsvorschlag für?
Moin Forum,
ist eigentlich noch jemand aktiv an der Entwicklung von monitord? Nachdem nun schon so viel Energie in dieses Projekt geflossen ist, wäre es doch schade, wenn es sich nun im Sande verlaufen würde.
Bitte gebt mal Rückmeldung, ob es noch irgendwelche Aktivitäten gibt.
Danke und Gruß,
Funkwart
Moinmoin,
ich lese hier weiterhin mit, bin aber in Sachen Entwicklung derzeit nicht aktiv. Support für das ZVEI-Modul ist aber drin, sofern es damit ein Problem gibt.
Momentan bin ich dabei, eine Abwicklungs-Software für die Einsätze des Vereines zu schreiben, für den ich auch den monitord respektive seine ZVEI-5Ton-Auswertung brauchte. Der Fokus liegt hierbei auf der Abwicklung eines großen Einsatzes, nicht bei der Disponierung vieler Einsätze.
Das ganze braucht recht viel Zeit, von der ich generell nicht sooo ausufernd viel für derartige Projekte verfügbar habe im Moment.
Viele Grüße
Martin
Ja und nein.Zitat:
Zitat von funkwart
Ich habe begonnen, ein Java-Frontend zu bauen. Das soll zunächst nur rudimentär die Funktionen der alten Monitor-Version umsetzen (gefilterte Logs schreiben, Aktionen ausführen, Aufnahmen starten)
Allerdings bin ich ein schlechter Programmierer, weswegen sich das Ganze in die Länge zieht. Zudem habe ich bei einem Plattencrash, leider sehr viel Code verloren und muss einiges neu schreiben -- und Zeit habe ich dafür im Moment eigentlich gar keine.
Mit Netbeans als IDE bin ich auch nicht zufrieden.
Es sieht also nicht gut für meinen Client aus.
Unterstützung von einem erfahrenen Java-Programmierer wäre sehr hilfreich.
Was das Protokoll angeht, tut sich momentan nix. Es liegen derzeit keine wesentlichen Feature-Requests vor.
Andreas
Bei mir ist es ähnlich wie MDI. Ich lese hin- und wieder mit. Habe aber im Moment noch nichtmal ein Testsystem mit dem ich Änderungen ausprobieren könnte.
Immerhin hat Eclipse schonmal wieder den Weg auf meinen neuen PC gefunden :)
Ja und Nein...Zitat:
Zitat von funkwart
Ich lese auch noch mit, und bastel etwas am Code, aber so wirklich Zeit ...
Was ist überhaupt Zeit? *g*
Ich hab letztens ein Buch zum Thema PLL Design in die Finger bekommen. Da konnte ich dann doch nicht widerstehen und hab da ein wenig drin gestöbert.
Für POCSAG habe ich mal ein wenig rumgespielt. Unter Windows sind die Ergebnisse mit dem BOSTool ganz gut. Ich habe aber noch keine LiveTests gemacht. Wer mutig ist kann ja mal aus dem SVN auschecken und prüfen, wie das Ergebnis bei Ihnen ist.
Es gibt noch ein paar Parameter die ich fest vorgegeben habe. Könnte also gut sein, daß es bei einigen überhaupt nicht klappen will. Sicher also die alte monitord.exe (bzw. monitord executeable)
:)
Also ich hab mal ausgecheckt und hier kommt bei Poc1200 bei beinah jeder 2. Ric kein sauberes Ergebniss zustande im Gegensatz zu vorher.
Vielen Dank für die Rückmeldung. Ich muss mal mein Scanner-Netzteil suchen :)
Witzigerweise hatte der alte Algorithmus beim klaren Signal vom BOSTool nur selten komplett ausgewertet. Ich hatte mal ein weisses Rauschen zugemischt. Aber vermutlich muss ich mal ne reale Aufnahme ausprobieren.
Hallo Foren-Admins,
Gibt es eine Möglichkeit, diesen kompletten Thread in eine Textdatei zu packen und irgendwo zum Download zu stellen?
Ich müsste mir mal aus den vielen Posts die ganzen Änderungen zur Protokollversion 0.4 raussuchen und die Protokolldokumentation auf den neusten Stand bringen.
Danke,
Andreas
Ich habe zwar nix gefunden, um den Thread kpl. zu exportieren - aber die Druckvorschau ist ganz hilfreich. Dann auf 50 Beiträge pro Seiten einstellen. Dann sind es vllt. 3-4 "Seiten" ab dem Release von Version 3 des Protokolls.