Datenübertragen per Audiobuchse?

Vielen Dank für die bisherigen Replies.
Also es ist ja von der Anwendung her nicht als wirkliche Informationsübertragung gedacht, sondern nur zum reinen Schalten. Ich stell mir das so vor(auch wenn es bisher nur eine Fantasie),
dass man am PC eine Koreographie komponiert, ähnlich wie mit einem Notenprogramm, und diese Koreographie in Bewegungsbefehle konvertiert, und diese dann als Audiodatei abspeichert.
Die Koreographie lässt sich dann vom tragbaren Mp3 Player oder änhliches ausführen.

Zitat:

---

dann könnte man anstatt Schieberegister einfache Zähler benutzen und per nur eine Leitung entsprechende Anzahl Impulsen schicken um gewünschten Zustand der Ausgänge zu haben.

---

Ist auf diese Weise simultanität möglich?

Um wie von euch vorgeschlagen 100 getrennte Schaltkanäle zu umgehen, reichen dann genaugenommen sogar 6 Kanäle, um 6bit zu erzeugen, denn 64 Schaltwege reichen auch aus für mein Vorhaben:-({|=.
Richtig? Falsch. Denn 6 bit sind zu wenig, wenn wir Simultanität wollen. Also die 64 Schaltwege müssen uabhängig beschritten werden können = 64 bit, auch wenn manche Bit-Stellungen nur sehr selten oder garnicht auftreten.
Aber man könnte zumindest das Stereo verwenden, um die Filterbank selbst in 2 Teile zu trennen. Dann hat man 2x32bit. Auf diese Weise ließen sich die Frequenzabstände wenigstens verdoppeln. Oder das schafft zumindest Freiraum für eine geschickte Wahl der Frequenzen.

Zum Thema Schaltzeit: Wenn sich das Einschwingen eines Filters von einem anderen unterscheidet, dann schlägt sich das doch nur in verschiedenen Schaltverzögerungen nieder. Das wird dann dazu führen, dass manche Bits früher als andere gesetzt werden, und dadurch es zwischenzeitlich zu einem falschen Bewegungsbefehl kommt.
In diesem Fall sollte es doch kein Problem sein, softwareseitig einfach den Schaltbefehl früher oder später zu geben, damit alle synchron sind. Da wären halt einpaar kleine Messungen erforderlich... oder einfach nur rumprobieren.

Um die generelle Schaltverzögerung komplett auszulöschen, könnte man doch zusätzlich alle Schaltimpulse softwareseitig früher geben. D.h bei der Konvertierung der Komposition des Notenprogramms in die Koreographie bzw. dem Bewegungsplan wird einfach generell jede Änderung eines Bitmusters einpaar Millisekunden früher ausgeführt.

Hallo,

Zitat:

---

Zitat von amrosik

Um die generelle Schaltverzögerung komplett auszulöschen, könnte man doch zusätzlich alle Schaltimpulse softwareseitig früher geben. D.h bei der Konvertierung der Komposition des Notenprogramms in die Koreographie bzw. dem Bewegungsplan wird einfach generell jede Änderung eines Bitmusters einpaar Millisekunden früher ausgeführt.

---

So ganz funktioniert das dann nicht, du hast da immer eine gewissen Jitter.

Als Beispielrechnung:
Das Filter schaltet irgendwann zwischen 4 und 8 Perioden des angelegten Signals mal durch. Das ist rein Zufällig.

Bei 1 kHz liegt die Zeit also zwischen 4 und 8 ms.
Bei 10kHz zwischen 0.4 und 0.8 ms.
und bei 100Hz zwischen 40 und 80 ms.

(Dies ist ein weiter Grund, wieso man so etwas heute lieber mit einem DSP macht.)

MfG Peter(TOO)

OK, ja das war fast vorhersehbar.

Es ist nun so, dass ich für meine Anwendung eine (Nutz-)Datenrate von mindestens 32kbit/s benötige, um eine zeitliche Auflösung von 1ms zu erreichen. Grund (korrigiert mich wenn ich falsch liege):

32-bit kommen deshalb zustande, da ich durch unsere vorherige Diskussion versucht habe, die Datenredundanz zu reduzieren. Es wären erst 64-bit nötig, um 64 Schalter unabhängig zu schalten. Dies ist aber nicht unbedingt notwendig.
Meine Anwendung besteht aus 4 Reihen mit jeweils durchschnittlich 16 Schaltern. Innerhalb jeder Reihe müssen 2 Schalter unabhängig voneinander geschaltet werden können (wir haben sozusagen 2 Cursor pro Reihe).
Um sich ein Bild zu machen, stellt euch einfach eine Instrumentsaite vor. Für diese braucht man einen Finger der den Ton hält, und einen der den nächsten präpariert.
Bei 16 möglichen Schaltern pro Reihe (Saite) macht das (etwa) 4 bit pro Cursor. D.h. 8 bit pro Reihe, also 4*8 = 32 bit Information.
Desweiteren sollte ein 32-Bit-Muster innerhalb von 1 ms refresht werden. Somit benötigt man eine Nutzdatenrate von 32kbit/s.
Da müssten dann noch Prüfbits und weiß-nicht-was dazu...

...Und wenn ich mich nicht irre, krieg ich mit dem PC höchstens eine Samplerate von 44kHz hin.
Angenommen wir vergessen die Multiplex-Methode, und machen das seriell per Audiobuchse, dann benötigen wir (wie von euch vorgeschlagen wurde) im einen Kanal eine Rechteckfunktion von sagen wir mal 40kHz, die Nutzdaten und Header-Zeugs enthält. Ich kann mir nicht vorstellen dass diese Rechteckfunktion bei 44kHz Samplerate noch schön aussieht oder überhaupt produziert werden kann. Mit Audacity sind z.b. nur etwa 20kHz möglich.

Wenn die Datenrate für serielle Übertragung auf diese Weise durch die Samplerate begrenzt ist, dann fällt seriell (per Audio) raus.
Und jetzt eine Frage:
Falls die Datenrate für serielle Übertragung von Informationen durch die Samplerate begrenzt ist, lässt sich diese Aussage auch auf die Multiplexmethode verallgemeinern? , sodass man sagen kann: Bei diese Samplerate ist keine höhere Informationsübertragung als X kbit/s möglich, auf welche Weise sie auch immer stattfindet (seriell, parallel, schwarze Magie...)?
Weil dann wäre die Analoge-Filtermethode sowieso raus, zumindest wenn es um 40kbit/s geht.


In diesem Fall gilt Plan B:

Sich mit 4ms zeitlicher Auflösung zufrieden geben. Also 8kbit/s. Wieviel Header benötigt man, um 8kbit/s Nutzdaten sicher zu übertragen? Bleibt man da unter 20kbit/s? Und ist es überhaupt möglich mit Audiobuchse seriell 20kbit/s zu übertragen?
Ist in diesem Fall seriell trotzdem besser als parallel, auch wenn man digitale Filter benutzt? Wo liegt deren Latenzzeit?