Suchergebnisse

Hallo Leute, ich bin neu hier und habe auch gleich ein Problem..... Ich empfange über den Line-In ein Soundsignal welches binäre Daten enthält. Diese Daten werden mittels FSK übertragen. Ich habe jetzt schon einiges über dieses Thema gelesen bin aber immernochnicht schlauer geworden. Ich möchte gerne das Soundsignal in die Binärdaten umwandeln. Die Frequenz für logisch 1 ist 1200 Hz und für logisch 0 1800 Hz. Die Baudrate beträgt 1200 bit/s. Aktuell nutze ich die Bass.dll um die Daten auszuwerte…

Das hab ich ja. Es geht nicht um die Amplituden sondern um die Umwandlung des Signals in Binärdaten. Wie bereits erwähnt werden die Daten per FSK übertragen.

Wie im Eröffnungsthread geschrieben möchte ich das Soundsignal in die Binärdaten umwandeln. Was FSK ist weiß ich. Ich scheitere lediglich daran die FMS-Telegramme aus den Soundsignalen zu deodieren Edit: die Auswertung soll in Echtzeit erfolgen. Das speichern in eine wav-Datei ist überflüssig und nicht gewollt

Wie mache ich das ohne die BASS-Dll? Mit Soundprogrammierung beschäftige ich mich jetzt zum ersten Mal. Eines meiner Probleme ist auch die Messung in den entsprechenden Zeitabschnitten. Mit einem normalen Timer kommt man bei einer Baudrate von 1200 nicht weit. Ein Zeitabschnitt ist 833 ms lang. Edit: aktuell versuche ich das Zeitproblem mti dem QueryPerformanceTimer zu lösen

Danke für deine ausführliche Antwort. Hab grad bemerkt, dass ich einen Tippfehler hatte.... nicht 833 ms sondern 833 µs. Also 0,83333333 ms (1000ms / (1200kbit/s)) Bei A verstehe ich nicht wieso ich die Zeit nicht brauchen sollte.... Ich muss doch jeweils die Amplitude pro Symbol (also alle 833 µs) und pro Frequenz erkennen und daraus dann auf binär 1 oder 0 schließen oder verstehe ich das falsch?

Es geht um solche Telegramme: muenster.de/~mbarenh/old/retttxt/fms.htm Im Moment arbeite ich noch mit der BASS-DLL. Aber mittlerweile glaube ich, dass mir diese nicht schnell genug die FFT-Daten bringt (also dass nicht schnell genug das Array mit Daten gefütter wird und dementsprechend immer falsche Ergebnisse raus kommen). Ich will mir jetzt mal DirectX anschauen. Evtl kann ich da die Daten in Echtzeit und vollständig puffern. Was ich bei der BASS-DLL noch zur Verfügung habe ist ein Record-Proc…

Eine Queue in diesem Sinne habe ich mir schon gebaut. Das Problem ist aber dieses "abgeschnittene Segmente finden". Mein Ansatz ist aktuell so: ich lese die Amplituden von 1200 Hz und 1800 Hz. Wenn die Werte passen, dann wird an einen String entweder 1 oder 0 angehangen und das erste Zeichen abgeschnitten sodass der String immer eine Länge von 68 hat. Danach überprüfe ich die ersten 20 Zeichen auf Telegrammvorlauf und Blocksynchronisation. Wenn diese 20 Zeichen quasi gleich "11111111111100011010…

Die Queue ist kein Problem. Das Problem ist die Ermittlung ob eine 1 oder eine 0 geschrieben werden soll. Ich möchte FMS-Telegramme dekodieren. Die Übertragung wird mittels "kohärenter Unterträger-FSK" gemacht. Wenn ich alles richtig verstanden habe bedeutet das, dass wenn die Amplitude von 1200 Hz größer als die von 1800 Hz ist und gleichzeitig ein Signal auf 1200 Hz anliegt eine 1 geschrieben wird und Bei 1800 Hz eine 0. Edit: @-blaze- Du hast mir weiter oben die Formel s(t) = sin(t*2pi*f(t) +…

Hab jetzt mal mit verschiedenen Möglichkeiten "gecaptured" und habe Zeitmessungen durchgeführt. Alle Methoden bringen ein Update nach 15 bis 30 ms. Das ist definitiv zu langsam wenn alle 0,833 ms ausgewertet werden muss. Es muss doch eine Möglichkeit geben direkt über die System-DLL's von Windows einen Stream in Echtzeit zu lesen. Diese 15 bis 30 ms sind für mich persönlich ein Anzeichen dafür, dass in den jeweiligen Funktionen der Buffer per Windows-Timer gefüllt wird. Und dieser Timer kann nic…

Danke für deine Antwort. Ich möchte aber eigentlich in meinem Programm keine "Fremdsoftware" einsetzen. Ziel ist es ein Programm zu schaffen, welches am Besten mit Windows-Boardmitteln klar kommt. Vielleicht geht was per DirectX in Echtzeit? Vielleich weißt du auch wie multimon die Signale verarbeitet?

Zitat: „Gibt es gute Gründe dafür, das Rad neuzuerfinden? “ Ja die gibt es.... 1. Fehlverarbeitungen selbst zu optimieren und um Fehlerquellen zu finden 2. Um unabhängig von aderen zu bleiben. Letztendlich ist das einzigste Problem die Geschwindigkeit in der der Buffer gefüllt wird. Der Buffer müsste alle 800 µs mit Daten gefüllt werden um selbst zu verarbeiten. Zitat: „Multimon-NG ist Open Source, du kannst dir also den ganzen Sourcecode zu Gemüte führen “ Ich wollte mir jetzt eigentlich nicht …

Zur Demodulation kommt es ja aber noch gar nicht, da nicht genügend Daten da sind. Aktuell bekomme ich ca. alle 20 ms neue Daten vom Line-In. Um FSK bzw FMS zu demodulieren braucht man aber mindestens alle 833 µs neue Daten.....

Soweit sind wir ja nun schon die ganze Zeit. Aber über welche Möglichkeit kommen die Daten schnell genug? Der Thread, in dem die Daten ankommen, aktualisiert nur ca. alle 20 ms

CSCore ist genauso langsam..... Hab ich schon probiert.....

Ich habe die Zeit gemessen und im Schnitt liegt die Zeit bei rund 20.000 µs

Du hast dich glaub ich verlesen. Aktuell kommen alle 20 ms (MILLIsekunden) Daten an. Bei FSK mit einer Baudrate von 1200 brauche ich aber alle 833 µs (MIKROsekunden) Daten. Baudrate 1200 Bit/s = 0,833333 s/Bit Somit hilft es mir nichts wenn ich nur jede Sekunde sample....

Ich habe jetzt nochmal mit CSCore experimentiert. Hier wird der Buffer alle 9 ms geupdatet. VB.NET-Quellcode (55 Zeilen)

Es sind wirklich 833 µs. Um die Daten richtig auswerten zu können brauch ich doch aber auch alle Daten oder nicht? Wenn der Buffer nur alle 10 ms geupdatet wird, dann fehlen mir doch ettliche Bits oder täusche ich mich da?

Das verstehe ich jetzt nich wirklich.... Wenn bei einer Baudrate von 1200 Bit/s alle 833µs ein Bit ankommt, dann muss doch der Buffer auch mindestens so schnell gefüllt werden oder nicht? Dekodierung und die Queue haben wir ja nun schon durchgekaut - aber das eigentliche Problem mit der Geschwindigkeit sehe ich noch nicht als gelöst. Eine Frage noch: bei der Dekodierung - reicht es da, wenn ich bei 1200 > 1800 = 1 und 1800 > 1200 =0 setze? Oder bedarf es dennoch einer Formel? Ich gehe davon aus,…

Ich meine den Puffer, der in der Sub datas() übergeben wird (e.data). Darauf mache ich FFT aber das Ergebnis passt nicht. Die Daten scheinen zu langsam zu kommen.....

Mal andersrum. Wie ist dieser Puffer aufgebaut? Welche Daten sind da enthalten? Nur ein Sample oder mehrere? Edit: die Samplerate von 44100 Hz wird von CSCore angegeben bei cs.WaveFormat.SampleRate

OK. Das habe ich verstanden. Daraus ergibt sich aber gleich die nächste Frage: woher weiß ich welchen Index welche Frequenz in dem Puffer (Byte-Array) hat? Wenn der Puffer kontinuierlich ist, dann ergibt sich ständig ein anderer Index für die Frequenz 1200 und 1800 Hz. Woher weiß ich nun welchen Bereich ich in den FFT schicken muss? Anmerkung: bei der aktuellen Methode kann ich die Puffergröße nicht ändern. Diese ist vorgegeben.

Also ein Telegramm besteht aus 68 Bit (entspricht 256 ms bei einer Baudrate von 1200 Bit/s (inkl. Sendevorlauf von 200 ms mit keinen Bits - quasi Stille auf dem Line-In)). Eine langsamere Verarbeitung sollte sich eigentlich nicht auf den Puffer auswirken, da dieser in eine Queue gepeichert wird und von einem separaten Thread (somit asynchron) verarbeitet wird. Also müsste ich quasi meine Daten aus dem Puffer so verarbeiten? VB.NET-Quellcode (38 Zeilen)

Danke für deine Antwort. Dein Ansatz ist ein bisschen anders als meiner aber eigentlich besser (aus meiner Sicht). Aber so leid es mir auch tut: es hilft mir im Moment nicht weiter. Ich hänge ja nach wie vor bei der Analyse des Audio-Streams. 1200 * item.Length / cs.WaveFormat.SampleRate habe ich beim googlen gefunden. Das soll mir den Index für das FFT bringen (zumindest laut dem Autor in einem Forum). Der Hinweis mit 1 Bit ist ungleich 1 Byte war gut. Das hatte ich ganz verdrängt. Aber das mac…

Ein FMS-Telegramm beginnt mit "11111111111100011010" und danach kommt das eigentliche Telegramm. Somit muss ich grundsätzlich die ersten 20 Bits eines 68-Bit-Streams analysieren um zu entscheiden ob ein Telegramm vorliegt oder nicht. Das kann ich aber nur "richtig" wenn ich beim Auslesen der Frequenzamplituden richtig vorgehe. Der Puffer (e.Data.Length) hat eine Länge von 7872 Bytes (bzw. 7871 da Nullbasierend). Nun muss ich ja aus dem Puffer die Amplituden für 1200 Hz und 1800 Hz ziehen. 1200 H…

Im Anhang ein Screenshot wie ein ankommendes FMS-Telegramm (übertragen mittels kohärenter FSK) aussehen könnte.

Also muss ich wohl doch komplexere Berechnungen anstellen bzw. eine generierte Frequenz mit der empfangenen vergleichen.... Zur Erinnerung hier noch mal der Link für die Beschreibung von FMS-Telegrammen: muenster.de/~mbarenh/old/retttxt/fms.htm @-blaze- erstmal vielen Dank für deine riesige Unterstützung. Ich scheitere wirklich nur an der Analyse der Audio-Daten. Ich hoffe du hast mein Problem verstanden. Es interessieren nur 2 Frequenzen (1200 Hz und 1800 Hz). Der Rest der Spektrums ist völlig …

Ich wünsche dir auch eine gute Nacht. Wenn ich es richtig verstanden habe, dann wird lediglich für binär 1 ein Ton mit 1200 Hz gesendet und für binär 0 ein Ton mit 1800 Hz

Ich habe jetzt noch ein wenig mit CSCore "gespielt" und bin auf eine Property namens WaveFormat gestoßen. Diese enthält folgende Werte: VB.NET-Quellcode (7 Zeilen) Der Puffer hat eine Länge von 7872 Mit diesen Werten müsste man doch eigentlich ausrechnen können, wieviele Daten im Puffer stecken und welchen Ausschnitt man aus dem Puffer für die FFT braucht oder nicht?

Mono würde grundsätzlich reichen aber das kann man bei CSCore nicht einstellen genauso wie die Samplerate. Ich gehe davon aus, dass das die Werte sind, welche in den Windows-Eigenschaften des Geräts festgelegt sind. In meinem Fall 44100, 16 Bit, Stereo