Druckbare Version
So also zum Thema Vista:
Ich habe leider derzeit kein Vista-System auf dem ich testen könnte. Eine Installation in VirtualBox funktioniert leider nicht.
Ansonsten: Ich sehe doch, dass es schon 20 Leute runtergeladen haben. Wo bleibt denn das Feedback? Funktioniert es überhaupt?
Oder habe ich die sache mit der Config-Datei nicht richtig erklärt?
Oder, oder, oder?
Moin.
Ich habs mal nach den bekannten Startschwierigkeiten laufen lassen, er hat auch was dekodiert,
aber leider iss hier Amateurfunk ein wenig ..naja, weisse Fläche auf der Relaiskarte. BOS hat hier
auch kein Pocsag.. mir selbst Meldungen zuzusenden ist nicht so lustig ^^
Intensiver habe ich es dann auch nicht getestet, da ich anstelle des PC halt nur nen Steckernetzteil
brauche, was den Stromverbrauch angeht, wenn ich wirklich mal Pocsag dekodieren will ;) Aber
da muss ich ja vorsichtig sein hier, sonst werd ich direkt wieder niedergemacht, warum ich nen
Hardwaredekoder in diesem Thread erwähne.
Was ich sagen kann, ist, das die Hardware zwar weniger Fehler im Parallelbetrieb macht, das aber
sicherlich nicht an deiner Software liegt, sondern an der üblichen Latenz zwischen Soundkarte und
Treiber bei Linux-Systemen. Für Realtime bräuchtest du ne root-Umgebung, wenn ich mich nicht
irre?
gruss,
Tim
Zunächst gibt es auf allen anderen Multitasking-System auch entsprechende Latenz. Nicht nur unter Linux. Aber Latenz verursacht keine Fehler, es ist ja nur eine Verzögerung... Daten gehen dadurch nicht verloren. Allenfalls dauert es einen Wimpernschlag länger, bis die Daten angezeigt werden. Aber das sollte man als Mensch nicht wahrnehmen können.
Mit root oder nicht-root hat das auch nicht viel zu tun. Für eine geringe Latenz wären ein spezieller Treiber und ggf ein RealTime-Kernel vonnöten.
ERm... mag ja sein, das ich mich falsch ausgedrückt habe.
Ich meine das Phänomen, das der Soundbuffer gefüllt wird, aber der Kernel
just in dem Moment einfach mal dem parallel laufenden GCC mehr Zeit zugesteht
und beim "digitalisieren" der Sounddaten nun eine Unterbrechung vorliegt - bei Datensignalen
nunmal tödlich..
Dem Prozess bzw. dem soundtreiber wie bei "jackd" realtime-priorität zu geben, bringt vielleicht
besserungen, aber du hast recht, ein Multitaskingsystem ist nunmal streng genommen nicht
wirklich geeignet für Datendekodierung - zumindest unter Lastbedingungen. Wenn das System
gemächlich vor sich hin-idlet, gibt's sicherlich kaum Probleme (dafür ist das Datenformat
nicht komplex genug, würd ich sagen ^^) ..
Da ich aber irgendwie immer am Rechner arbeite, was compiliere oder zumindest im Hintergrund
Daten schaufele, kann ich dir nur sagen, das im Parallelbetrieb an der Software mal nichts ankommt,
wenn über die serielle Schnittstelle der Hardware was angeliefert wird.
So - nun die anderen 19 Downloader :-P
Ich bleib aber mal daran, ob ich reproduzierbare Ergebnisse liefern kann..
Gruss,
Tim
Ah... dieses Phänomen nennt sich Bufferoverrun. Latenz ist, wie ich schon sagte, nur die Verzögerung vom anliegen der Daten am Eingang bis sie im Programm ankommen.
Die Digitalisierung und Speicherung in einem kleine Puffer auf der Soundkarte ist vollständig in Hardware implementiert, ist also unabhängig vom Prozessor.
Wenn dieser Puffer auf der Soundkarte voll ist, dann löst die Hardware einen Interrupt aus und die Interruptroutine im Kernel (bzw. Treiber) überträgt dann mittels DMA den Puffer der Soundkarte in den RAM.
Auch diese Vorgänge sind unabhängig von der CPU-Last. Hier geht i.d.R. nichts verloren. Das digitalisieren hat also kein Aussetzer durch hohe CPU-Last.
Der einzige Fall, in dem ein Bufferoverrun auftreten kann ist, wenn das Programm nicht genug CPU-Zeit hat um die Daten vom Treiber entgegen zu nehmen und zu verarbeiten bis der nächste "Satz" Daten vorliegt.
Aber das lässt sich durch einfach Maßnahmen weitergehen ausschließen:
-entsprechende Puffergröße wählen
-wählen der Prozess- bzw. Threadpriorität
usw.
(darum habe ich mich in der alpha-Version übrigens nicht nicht gekümmert)
>[...] aber du hast recht, ein Multitaskingsystem ist nunmal streng genommen nicht
>wirklich geeignet für Datendekodierung - zumindest unter Lastbedingungen.
Das habe ich nicht gesagt und ich behaupte sogar das Gegenteil!
Man denke nur an so komplizierte Formate wie:
-Ethernet
-WiFi
-DVB
-Videostream
...
...aber wir wollen hier mal nicht zuweit abschweifen. Ich habe mich ein wenig hinreißen lassen ;-)
Hi ..
Japp, ich beziehe mich in der Tat auf das von dir beschriebene Problem.
OT:
Erm.. Ethernet und die ganzen Dinger werden aber nicht über ne Soundkarte verarbeitet,
eben weil sie so komplex sind. Dafür ist andere L0/L1 zuständig.. es ging mir ausschliesslich
um eine Dekodierung von Datensignalen durch digitalisierung einer analogen Frequenz.
Alles andere sind andere Vorraussetzungen. (Ich kann mit demselben Mikrocontroller einen
Chip ansprechen, der dann Ethernet auf der Ausgabeseite hat, oder nen Chip, der mir nen FFSK
Signal erzeugt, aber nicht zwingend beides mit dem Mikrocontroller selbst erzeugen, weil eins
zu komplex ist für die Geschwindigkeit der MCU. Vergleich hier wäre als "Soundkarte", "virtuelle
Soundkarte", "Netzwerkkarte" und "virtuelle Netzwerkkarte")
Topic:
Es könnte übrigens noch ein ganz anderes Problem sein, es wäre mal zu fragen, ob ein User
sowohl die Windows als auch Linux Version auf derselben Hardware laufen hat - vielleicht liegt
es an den Filtern meiner Soundkarte ^^
Gruss,
Tim
Also wie ich beschrieben habe ist ein Datenverlust bei der AD-Wandlung ausgeschlossen. Genauso ist es bei einer Decoder-Hardware.
Allerdings bleibt die Frage wie die Decoder-Hardware digitalisiert. Falls mittels SchmittTrigger, dann liegt hier schon ein Vorteil auf der Seite der Software. Diese verwendet aufwändigere Mechanismen, die auch stets angepasst werden können. Bspw. möchte ich noch ein LowPass-FIR zur Rauschunterdrückung hinzufügen.
Die Eigentliche Dekodieraufgabe ist ausgesprochen simpel. Diese Aufgabe muss entsprechend bei einem Hardware-Decoder eine MCU übernehmen. Es existiert keine MCU die leistungsmäßig mit einem handelsüblichen PC mithalten kann.
Als Vergleich: Man kann ja auch mit einem PC in echtzeit Audio als MP3 aufnehmen. Und das erfordert immerhin diskrete Kosinustransformation in Echtzeit.
Ansonsten gibt das Programm derzeit eine DEBUG-Meldung aus, falls tatsächlich ein Overrun auftritt. Bisher habe ich das noch nicht geschafft.
Zusammenfassend:
Als Argument für einen Hardware-Decoder lasse ich nicht gelten, dass dieser leistungsfähiger ist.
Von welchen Filtern sprichst du?
Gerade getestet:
Code:Michael@athlon64:~/pocsag> ./openpoc
LOG_FILE: ./log.txt
./openpoc: relocation error: ./openpoc: symbol snd_device_name_hint, version ALSA_0.9 not defined in file libasound.so.2 with link time reference
Michael@athlon64:~/pocsag>
auf ner Athlon 64bit maschine.Code:Michael@athlon64:~/pocsag> ./openpoc
LOG_FILE: ./log.txt
./openpoc: relocation error: ./openpoc: symbol snd_device_name_hint, version ALSA_0.9 not defined in file libasound.so.2 with link time reference
Michael@athlon64:~/pocsag>
Hallo EIB!
Welche ALSA-Version hast du? Hast du auch die entsprechenden 32-Bit Libs installiert?
http://funkmeldesystem.de/foren/show...4&postcount=69
Dann fehlt mir wohl was ..........
ok, dann nächste Frage:
Welche distribution?
Habe gerade mal nachgeschaut, alsa-libs in der gleichen Versionsnummer für 32bit sind installiert.
Ich verwende aktuell OpenSuse 10.2.
Wenn ich Zeit habe, ist ein Online-Update auf 11.0 geplant (bis dahin sollte die Stable laufen :-) ).
Also...
bei mir funktioniert es zwar und stürzt auch nicht ab (Vista 64), aber es dekodiert auch nicht...
Debug-Ausgabe ist nur...:
DATA: us_bit: 1952
no syncword
canceled in Decode-Engine
PUSH: 1
Gleichzeitig zeigt ein anderer Dekoder aber Meldungen an. Ich benutze den Line-In mit einem Diskriminator.
hmm... dass bedeudet, dass die Präambel erkannt wird (512 Baud), das SyncWord aber nicht. Verwendet dein Netz ein anderes SynWord? Kann ich mir nicht vorstellen....Zitat:
Zitat von PelBB
Versuche doch mal die Lautstärke zu variieren.
Sooo...
Habe mal mit dem Lautstärkeregler Line-In gespielt, das bringt leider garnichts.
Wenn ich den Mikrofon-Eingang benutze, dekodiert das Programm, wenn ich den Eingang weit aufziehe.
Leider stürzt es dann aber nach kürzester Zeit ab... und zwar sofort oder kurz nach der ersten Dekodierung.