Hallo, es gibt ja vor allem im Smartphonebereich einige Projekte, die den Headsetanschluss (Audio In/Out) für die Datenübertragung verwenden. Dies finde ich grundsätzlich auch sehr interessant, und würde mich gerne näher mit dem Thema beschäftigen - und als Gegenstück falls möglich einen AVR verwenden. Zum Senden der Daten benötige ich also, von der Modulationslogik einmal abgesehen, soweit ich es verstehe die Möglichkeit verschiedene Schwingungen zu erzeugen - oder eben auf eine Sinusschwingung aufzumodulieren. Die Schwingungen im konkreten Fall sind Spannungskurven, richtig? Also müsste ich die theoretisch per PWM erzeugen können. Wenn ich mich nicht irre, muss ich aber auch negative Spannungen erzeugen können, da die Schwingungen um 0V verlaufen, richtig? Wie kann ich dies realisieren? Gibt es eine einfache Möglichkeit die Daten beim Einlesen wieder zu dekodieren? Mein Vorgehen wäre ein ADC und FFT, um einzelne Frequenzen zu isolieren. Gibt es bessere Ansätze? Zum Schluss bleibt noch die Frage, wie solch eine Modulation konkret aussehen könnte. Gibt es da fertige Ansätze? Könnt ihr mir etwas empfehlen? Danke im Voraus!
Eine FFT ist evtl. mit Kanonen auf Fliegen geschossen. Es gibt für sowas bessere Verfahren. Wieviel Aufwand zu betreiben ist hängt stark von den gewünschen Eigenschaften wie z.B. Übertragungsrate und zu erwartendem Signal-/Rauschabstand ab. Im einfachsten Fall langt ein Umtasten zwischen zwei Frequenzen beim Senden (suche mal nach FFSK oder AFSK) und einer Periodendauermessung beim Auswerten. Am anderen Ende stehen dann Verfahren bei den mehrere Bits auf einmal übertragen werden und sowohl in der Phasenlage, als auch in der Frequenz und der Amplitude unterschiedliche Informationen (Bits des gerade übertragenen Bytes) stecken und Signal-/Rauschabstände bei nahezu 0dB vorliegen.
>es gibt ja vor allem im Smartphonebereich einige Projekte, die den >Headsetanschluss (Audio In/Out) für die Datenübertragung verwenden. Ach ja, welche denn? Du meintest Du schon, ueber einen GSM Kanal uebertragen oder das Smartphone als Endpunkt der "Audiodaten"? Das Problem bei der GSM Uebertragung ist, dass die Voicecoder-Parameter basierend auf einem Vocaltraktmodell berechnet werden und sich daher nicht fuer adhoc fuer off-the-shelf Datenuebertrgaung eignen. Bei einer 50 Baud(!) Versuchstrecke mit CCITT V.21 300 Baud Frequenzen bei GSM-auf-Analog ging es manchmal, bei 20 Baud dann recht stabil.
Das richtig Fachwort dazu heisst Modem. Suche doch einfach mal nach Dokumentationen, wie die 300 Baud Modems funktionierten. Die waren noch recht überschaubar. Zum Ende der Modem Ära statteten die meisten Laptop Hersteller ihre Geräte mit Soft-Modems aus, die aus einer Kombination von Software und Soundkarte bestanden. Die funktionierten allerdings eher schlecht als Recht. jetzt, wo es Mutli-Core Prozessoren gibt, würde dieses Konstrukt wieder eher Sinn machen. Aber jetzt hat der Massenmarkt kein Interesse mehr an Modems.
>es gibt ja vor allem im Smartphonebereich einige Projekte, die den >Headsetanschluss (Audio In/Out) für die Datenübertragung verwenden. Könntest Du ein paar Links auf Beispielprojekte posten?
Janis E. schrieb: > Zum Senden der Daten benötige ich also die Möglichkeit verschiedene > Schwingungen zu erzeugen Als einfaches Verfahren zur Übertragung von Befehlen eignet sich DTMF. Dafür gibts fertige ICs zur Kodierung und Dekodierung. Für echte Übertragung von ASCII-Zeichen nimmt man Modems. In den alten Siemens-Handys war z.B. ein Modem gleich eingebaut. Gruss Harald
Packet-Radio macht genau das, mit 1200Baud. Am Handfunkgerät trotz Filterung des Sende- und Empfangssignals, was die Datensignale stark verzerrt. Für 9600 Baud müsste man schon in das Gerät eingreifen. Zum Ausprobieren gibts die Softwarelösung mit Soundkarte, "Paxon" und "Soundmodem", für Windows und Linux. http://www.dj4uf.de/funktechnik/soundmodem/soundmodem.htm
:
Bearbeitet durch User
Christoph Kessler (db1uq) schrieb: > Packet-Radio macht genau das, mit 1200Baud. Am Handfunkgerät trotz > Filterung des Sende- und Empfangssignals, was die Datensignale stark > verzerrt. Für 9600 Baud müsste man schon in das Gerät eingreifen. > > Zum Ausprobieren gibts die Softwarelösung mit Soundkarte, "Paxon" und > "Soundmodem", für Windows und Linux. > http://www.dj4uf.de/funktechnik/soundmodem/soundmodem.htm Für transparente Audio-Kanäle eines Amateufunk-Gerätes ist das schön. Aber für den TE lohnt es nicht einmal den Versuch, denn: Tiramisu schrieb: > Das Problem bei der GSM Uebertragung ist, dass die > Voicecoder-Parameter basierend auf einem Vocaltraktmodell berechnet > werden > und sich daher nicht fuer adhoc fuer off-the-shelf Datenuebertrgaung > eignen. > > Bei einer 50 Baud(!) Versuchstrecke mit CCITT V.21 300 Baud Frequenzen > bei GSM-auf-Analog ging es manchmal, bei 20 Baud dann recht stabil. Es grüßt RainerK, dd1dl
Ja, stimmt, das kenne ich von "ordentlichen" Funkgeräten nicht, da muss man nicht ganz so ökonomisch mit der Bandbreite umgehen. Dann werden auch die guten alten 56k-Telefonmodems nicht funktionieren.
Tiramisu schrieb: > Ach ja, welche denn? Du meintest Du schon, ueber einen GSM Kanal > uebertragen oder das Smartphone als Endpunkt der "Audiodaten"? Es geht um letzteres, also die Ansteuerung von Peripherie o.ä. über den Audiokanal. Das machen auch manche kommerzielle Produkte: http://www.engadget.com/2010/03/02/redeye-mini-converts-iphone-ipad-or-ipod-touch-into-ir-beaming/ Und hier ein Selbstbauprojekt für die Gegenrichtung: http://www.creativedistraction.com/demos/sensor-data-to-iphone-through-the-headphone-jack-using-arduino/
Rufus Τ. Firefly schrieb: > Es geht um letzteres, also die Ansteuerung von Peripherie o.ä. über den > Audiokanal. Das machen auch manche kommerzielle Produkte ja, ganz genau Rufus Τ. Firefly schrieb: > Und hier ein Selbstbauprojekt für die Gegenrichtung: > > http://www.creativedistraction.com/demos/sensor-data-to-iphone-through-the-headphone-jack-using-arduino/ prima, danke für den Link! C. W. schrieb: > (suche mal nach FFSK oder AFSK) danke für den Hinweis, das hilft mir weiter!
Harald Wilhelms schrieb: > Als einfaches Verfahren zur Übertragung von Befehlen eignet sich > DTMF. Dafür gibts fertige ICs zur Kodierung und Dekodierung. Die sind aber alle mindestens abgekündigt, größtenteils aber schon seit Jahren überhaupt nicht mehr verfügbar. Und das ist kein Wunder, schafft es doch schon ein µC wie ein ATtiny recht problemlos, DTMF zu decodieren (Encoding war sowieso nie ein Problem). > Für echte Übertragung von ASCII-Zeichen nimmt man Modems. Oder baut solche in Software. De facto waren schon in den 90er Jahren des vergangenen Jahrhunderts alle Consumer-Modems reine Software-Werke. Ja OK, DSP-Software, aber eben doch "nur" Software.
Rufus Τ. Firefly schrieb: > Es geht um letzteres, also die Ansteuerung von Peripherie o.ä. über den > Audiokanal. Was Du suchst ist ein Modulationsverfahren. Eine ganze Fachrichtung (Nachrichtentechnik) beschäftigt sich damit, möglichst effiziente Modultationsverfahren zu finden. Insbesondere wird das dann interessant, wenn man möglichst viele Daten in kurzer Zeit (mit wenig Fehlern) übertragen möchte. Begrenzt ist die Menge der zu übertragenden Daten durch die benutzbare Bandbreite (-> Shannon), bei Audio vielleicht maximal 20kHz. Je geringer die Datenrate sein soll, desto simpler kann die verwendete Modulation sein. Für ein einfaches "Ein/Aus" geht z.B. "Ton / kein Ton". Oder, wie schon vorgeschlagen, DTMF, das sind zwei simultane Töne mit denen üblicherweise 12 Symbole codiert werden. Gibt es fertige Chips für. Hast Du schon eine Vorstellung, wie gross Deine Datenrate sein soll ?
:
Bearbeitet durch User
Kai S. schrieb: > Hast Du schon eine Vorstellung, wie gross Deine Datenrate sein soll ? Ja, da u.A. auch ein kleines Display angesteuert werden soll, und im Zweifelsfall der Aufbau eines kompletten Frames nicht zu lange dauern soll, hätte ich gerne (soweit möglich) mindestens 2048 Bytes pro Sekunde, optimalerweise das Doppelte.
:
Bearbeitet durch User
Janis E. schrieb: > Ja, da u.A. auch ein kleines Display angesteuert werden soll, und im > Zweifelsfall der Aufbau eines kompletten Frames nicht zu lange dauern > soll, hätte ich gerne (soweit möglich) mindestens 2048 Bytes pro > Sekunde, optimalerweise das Doppelte. Also mit 16..32 kBps definitiv im Bereich der etwas diffizileren und rechenleistungshungrigen Modulationsverfahren von Modems. Also nimmst du entweder ein Modem oder programmierst deren bekannten und wohldokumentierten Verfahren nach (wenn die Rechenleistung deiner Geräte dafür zusätzlich reicht, denn ihren normalen Job sollen sie ja nebenbei auch noch erledigen, oder?)
Kai S. schrieb: > Begrenzt ist die Menge der zu übertragenden Daten durch die benutzbare > Bandbreite (-> Shannon), bei Audio vielleicht maximal 20kHz. Das ist nur die halbe Wahrheit. Eine weitere Begrenzung stellt der Störabstand auf dem Übertragungskanal dar.
Bei dem einen Link http://www.engadget.com/2010/03/02/redeye-mini-converts-iphone-ipad-or-ipod-touch-into-ir-beaming/ wurde das Audiosignal in ein IR-Signal umgesetzt. Das ist pragmatisch, aber zusaetzliche HW und gefuehlt unsportlich. Ein Smartphone hat ja einen Lautsprecher und ein Mikro, das sollte fuer eine bidirektionale Datenuebertragung alleine ausreichen. Anfang der 80er Jahre gab' es mal ein Wettrennen in der c't, wer die effizienteste Aufzeichnungsmethode fuer Kassetten ( http://de.wikipedia.org/wiki/Compact_Cassette ) hatte. Meiner Erinnerung nach waren das (damals) etwa 7kbit/s. Dieses Verfahren wurde dann fuer die damals erhaeltlichen Rechner als platformunabhaeniger Standard implementiert und sukzessive platformweise veroeffentlicht. Das war aber leider nicht wireless! Mit heutigen DSP-Verfahren sollte man in den Bereich der letzten Generation von Analogmodems kommen (33 kBaud / 56 kBaud)!!?
56kBaud lief anders. Hierbei wurden die AD / DA-Wandler der digitalisierten Vermittlungsstelle vermessen und direkt mit analog gewandelten Daten beschickt. Die 56kBaud sind das Ergebnis der 8kHz Samplingrate und 7 Bit Wortbreite. (Amerikanisches ISDN und damit auch deren analoge Vermittlungen hatten nur 7 Bit) Dieser Modus funktionierte nur mit entsprechenden Gegenstellen (z.B. INet-Provider). Zwei dieser Modems mit 56kBd miteinander zu verbinden funktionierte nicht, es wurde dann ein langsamerer Modus verhandelt. Zusätzlich hatte man zur Geschwindigkeitserhöhung in die Modems eine Datenkompression eingebaut, welche reine Texte um bis zu 4x schneller übertrug. Bereits komprimiertes Material lief langsam. Das kam aber nicht so häufig vor - es wurde vor allem Text übertragen. Gruß Jobst
Es ist schon erstaunlich wie viele Autisten hier unterwegs sind und bei GSM immer noch Modems für transparente Audio-Kanäle empfehlen. Bereits im dritten Beitrag und auch als Zitat: Tiramisu schrieb: > Das Problem bei der GSM Uebertragung ist, dass die > Voicecoder-Parameter basierend auf einem Vocaltraktmodell berechnet > werden > und sich daher nicht fuer adhoc fuer off-the-shelf Datenuebertrgaung > eignen. Es grüßt RainerK
Hallo, das ist weder neu noch "innovativ" (trotz der Erwähnung von Smartphones) es nennt sich: MODEM. Das ist immer das "lustige" bei den Smartphones: Die neuen "Erfindungen" - die man aus den frühen 80ern von den Heimcomputern kennt (wie die tollen "neuen" Spiele). Google mal nach AC97 Modem (das ist allerdings für Softmodems). Jeder PC hat / hatte(?) das implementiert. wenn man eine ausreichend niedrige Baudrate (300 Bd) oder so wählt und die Lautpsrecher laut macht und ein vernünftiges Mikrofon nimmt, sollte es auch über ein paar m gehen. Ging ja früher auch über Akustikkoppler. Zumindes wäre das ein Startpunkt für eine Recherche.
RainerK schrieb: > Es ist schon erstaunlich wie viele Autisten hier unterwegs sind > und bei GSM immer noch Modems für transparente Audio-Kanäle empfehlen. Vielleicht solltest du dich mal an die eigene Nase fassen. Dann bekommst du evtl. auch irgendwann mit, daß es überhaupt nicht um GSM geht.
Ohje schrieb: > Google mal nach AC97 Modem (das ist allerdings für Softmodems). Jeder PC > hat / hatte(?) das implementiert. ja, das hilft weiter, danke! Was allerdings (solange ich es nicht übersehen habe) noch nicht geklärt ist, ist die Frage mit dem negativen Spannungspegel. Sowohl für den Ein- als auch den Ausgang muss ich ja (wenn ich es richtig verstehe) Sinusschwingungen um 0V handeln, also sowohl Positive als auch Negative. 1) Wie erzeuge ich mittels PWM negative Spannungen? 2) Wie kann ich mit einem AVR die Frequenzen bestimmen, wenn die Spannungen negativ werden? Das dürfte mit einem simplen ADC nicht möglich sein, oder?
Janis E. schrieb: > Was allerdings (solange ich es nicht übersehen habe) noch nicht geklärt > ist, ist die Frage mit dem negativen Spannungspegel. Hier nicht relevant. Erzeuge das Signal mit einem Gleichspannungsoffset von halbem Maximalpegel, dann hast Du nur positive Spannungen. Den Gleichspannungsoffset wiederum wirst Du durch einen in Reihe geschalteten Kondensator wieder los.
> Hier nicht relevant. Erzeuge das Signal mit einem Gleichspannungsoffset > von halbem Maximalpegel, dann hast Du nur positive Spannungen. > > Den Gleichspannungsoffset wiederum wirst Du durch einen in Reihe > geschalteten Kondensator wieder los. Ok, das ergibt Sinn, danke. Aber was ist mit dem Eingang? Wie verhält sich der ADC bei negativen Spannungen?
Auf der Seite muss Du dafür sorgen, daß ein Gleichspannungsoffset zum Signal hinzugefügt wird, denn der ADC mag natürlich keine negative Eingangsspannung.
Rufus Τ. Firefly schrieb: > Auf der Seite muss Du dafür sorgen, daß ein Gleichspannungsoffset zum > Signal hinzugefügt wird, denn der ADC mag natürlich keine negative > Eingangsspannung. Und wie stelle ich das am sinnvollsten an?
Janis E. schrieb: > 1) Wie erzeuge ich mittels PWM negative Spannungen? Hm, ich glaube Du bist hier auf dem Holzweg: Wenn Du Ausgabe über die Kopfhörerbuchse erfolgen soll (zumindest habe ich das bisher so verstanden) brauchst Du keine PWM, denn der Kopfhörerausgang ist ja bereits ein D/A Wandler (sogar 2, da Stereo). Diese füttert man üblicherweise mit vorzeichenbehafteteten (signed) Samplewerten a 16 Bit. Das entpricht also ziemlich direkt dem was an der Buchse herauskommt. ZigZeg
Kai S. schrieb: > Janis E. schrieb: >> 1) Wie erzeuge ich mittels PWM negative Spannungen? > > Hm, ich glaube Du bist hier auf dem Holzweg: Wenn Du Ausgabe über die > Kopfhörerbuchse erfolgen soll (zumindest habe ich das bisher so > verstanden) brauchst Du keine PWM, denn der Kopfhörerausgang ist ja > bereits ein D/A Wandler (sogar 2, da Stereo). Diese füttert man > üblicherweise mit vorzeichenbehafteteten (signed) Samplewerten a 16 Bit. > Das entpricht also ziemlich direkt dem was an der Buchse herauskommt. Wie genau meinst Du das? Konkretes Beispiel. Ich verwende FSK (danke an die Modem-Tipps) und möchte zwei verschiedene Frequenzen generieren (uC -> Computer) und differenzieren (Computer -> uC). Für die Ausgabe der Frequenz würde ich nun, wie Rufus es empfohlen hat, PWM vom uC nutzen, und einen Kondensator in Reihe schalten. Die Frage ist also, wie ich mit dem Input verfahre. Ich habe die Ausgabe von Computer/Smartphone/whatever, und wie genau sehen diese Signale aus? Meine Vorstellung war, dass ich dort im Normalfall Schwingungen um 0V mit einer Amplitude von ca. 3V habe, also am ADC Werte zwischen -3V und +3V ankommen würden. Die Frage ist, wie ich mit diesen Werten umgehe (oder habe ich noch irgendwo einen Denkfehler?).
Janis E. schrieb: > Zum Schluss bleibt noch die Frage, wie solch eine Modulation konkret > aussehen könnte. Gibt es da fertige Ansätze? Könnt ihr mir etwas > empfehlen? Mit solchen Verfahren wurde in der Anfangszeit der Heimcomputer (1985) Programme und Daten auf Kassettenrecodern aufgezeichnet.
RainerK schrieb: > GSM immer noch Modems für transparente Audio-Kanäle empfehlen. >> Voicecoder-Parameter basierend auf einem Vocaltraktmodell Meinst Du, das auch eine DTMF-Übertragung bei dieser Art der Codierung nicht mehr möglich ist? Gruss Harald
Janis E. schrieb: > Meine Vorstellung war, dass ich dort im Normalfall Schwingungen um 0V > mit einer Amplitude von ca. 3V habe, also am ADC Werte zwischen -3V und > +3V ankommen würden. Die Frage ist, wie ich mit diesen Werten umgehe einfach noch Mal die Beiträge lesen. Ein Tipp von mir: ich habe den Eindruck du bist damit noch überfordert, bastel erst Mal was einfaches, da wirst Du oft genug hängenbleiben ...
Janis E. schrieb: > es gibt ja vor allem im Smartphonebereich einige Projekte, die den > Headsetanschluss (Audio In/Out) für die Datenübertragung verwenden. Dies > finde ich grundsätzlich auch sehr interessant, und würde mich gerne > näher mit dem Thema beschäftigen - und als Gegenstück falls möglich > einen AVR verwenden. Janis E. schrieb: > Konkretes Beispiel. Ich verwende FSK (danke an die Modem-Tipps) und > möchte zwei verschiedene Frequenzen generieren (uC -> Computer) und > differenzieren (Computer -> uC). Nun bin ich verwirrt. Du wolltest doch einen AVR an Dein Smartphone anschliessen ? Zumindest hast Du das im ersten Betrag behauptet ?!? Und nun ein Computer ? Und in welche Richtung soll die Datenübertragung gehen ??? Für die Ausgabe vom AVR könntest Du tatsächlich eine PWM benutzen. Ich bezweifele übrigens, dass ein AVR genügend Rechenleistung hat, um ein einigermassen komplexes Modulationsschema zu modulieren/demodulieren. Nicht umsonst werden DSPs für diesen Zweck benutzt. Heute reicht für möglicherweise auch ein ARM aus, wenn man geschickt programmiert (und nicht eine Datenrate nach dem derzeitigen Stand der Technik erwartet).
Kai S. schrieb: > Du wolltest doch einen AVR an Dein Smartphone > anschliessen Die Smartphones waren ein Beispiel. Ich möchte mehrere Devicetypen (nicht gleichzeitig ;)) mit dem uC verbinden, und ich fand die Idee mit dem Audiosingal spannend, da es von so ziemlich jeder Platform unterstützt wird.
:
Bearbeitet durch User
Harald Wilhelms schrieb: > Meinst Du, das auch eine DTMF-Übertragung bei dieser Art der > Codierung nicht mehr möglich ist? zumindest nicht zuverlässig. Hier haben schon einige was dazu geschrieben: Beitrag "DTMF Funktioniert das heute noch?"
Janis E. schrieb: > Konkretes Beispiel. Ich verwende FSK (danke an die Modem-Tipps) Hast du auch begriffen, daß du damit weit davon entfernt bist, die von dir anvisierten Ziele bezüglich der Datenrate zu erreichen, daß du dich damit vielmehr auf dem Niveau der Kassetteninterfaces der 70er und 80er Jahre des letzen Jahrhunderts bewegst? Also nix mit >16kBps, sondern bestenfalls irgendwas bei knapp der Hälfte dieser Größe. > Für die Ausgabe der Frequenz würde ich nun, wie Rufus es empfohlen hat, > PWM vom uC nutzen, und einen Kondensator in Reihe schalten. Nun, die Erzeugung des Signals ist bei den einfacheren Modulationsverfahren meist überaus trivial. Und zwar auch für bezüglich des Kanals völlig unrealistisch hohe Datenraten... > Die Frage ist also, wie ich mit dem Input verfahre. Ich habe die Ausgabe > von Computer/Smartphone/whatever, und wie genau sehen diese Signale aus? Genau das ist das Problem. Sie sind dann durch die Mangel der Kanalbandbreite gelaufen. Wenn der Sender sich bezüglich der Bandbreite hinreichend beschränkt hatte und es keine nennenswerten Störungen im Kanal gab, kriegst du immerhin ein Signal, mit dem man was anfangen kann. > Meine Vorstellung war, dass ich dort im Normalfall Schwingungen um 0V > mit einer Amplitude von ca. 3V habe, also am ADC Werte zwischen -3V und > +3V ankommen würden. Die absoluten Momentanwerte des Signals sind völlig irrelevant. Bezüglich der Pegel spielt nur eins eine Rolle: Der Signalpegel muß soviel höher sein als der Pegel des Rauschens, daß der vom Sender abgesonderte Verlauf des Signals hinreichend gut rekonstruiert werden kann. Und natürlich muß die Sampling-Rate mehr als das Doppelte der höchsten verwendeten Signalfrequenz betragen. Bei einfachen Modulationsverfahren ist das einfach zu erreichen, wenn man die Bandbreitengrenze des Kanals respektiert. Eben deswegen sind diese Verfahren "einfach". Es sind nur zwei Pegel im Signal zu unterscheiden. Komplexere Modulationsverfahren können die Bandbreitengrenze des Kanals auch nicht umgehen, denn die ist Naturgesetz. Deswegen beruhen sie darauf, innerhalb dieser Bandbreite nicht nur zwei verschiedene Pegel, sondern mehr als zwei zu übertragen. Umso schwieriger wird es aber für den Empfänger, sauber zwischen diesen Pegeln zu unterscheiden, denn je mehr verschiedene Pegel es gibt, desto kleiner ist der Unterschied zwischen ihnen und desto leichter ist es für das allgegenwärtige Rauschen, aus einem gewollten Pegel einen benachbarten falschen zu machen.
Mal 'ne ganz bescheuerte Frage: Wozu sollen digitale Daten für die Übertragung in ein Analogsignal umgewandelt werden, um sie anschließend wieder für eine digitale Übertragungsstrecke zu digitalisieren und zu komprimieren. Und dann stellt sich auch noch raus, das die Kompressionsalgorithmen für die menschliche Sprache optimiert sind und sich für Modemsignale denkbar schlecht eignen. Das ist wie Liniengraphiken durch einen JPEG-Kompressor zu schicken.
> Es ist schon erstaunlich wie viele Autisten hier unterwegs sind > und bei GSM immer noch Modems für transparente Audio-Kanäle empfehlen. Der erste Teil des Satzes trifft sicher auf mich zu ;-), bzgl. des zweiten Teils des Satzes plaediere ich auf eine kognitive Fehlleistung. In dem angesprochenen Experiment wurden uebrigens keine Modems, sondern ein V.21 FSK-Modulator und auf der Gegenseite ein V.21-Akustikkoppler verwendet. >Meinst Du, das auch eine DTMF-Übertragung bei dieser Art der >Codierung nicht mehr möglich ist? Das hatte ich mich auch gefragt und wuerde vermuten, dass das nicht stabil geht. Im GSM wird der Tastendruck auf dem Handy out-of-band uebertragen (im Signalisierungskanal). Ein DMTF Handsender geht halt erst ueber das Mikrofon an den fuer die menschliche Sprache optimierten Sprachcodec. Zur Validierung der Hypothese habe ich bereits ein analoges Delegatic Telefon besorgt (in-band DTMF Datenuebertragung auf das LCD Display waehrend eines Telefongespraechs), ich muss noch einen DTMF Handsender buchten und wenn ich mal wieder eine autistische Phase habe, dieses spannende Experiment via GSM durchfuehren :-) Leider geht das ganze am eigentlichen Anliegen des TOs etwas vorbei, aber gerade wegen der 16kBit/s Herausforderung koennte es wichtig sein, bestehende Loesungen, Erfahrungen und Grenzen in verwandten Bereichen zusammenzutragen.
0815 schrieb: > Und dann > stellt sich auch noch raus, das die Kompressionsalgorithmen für die > menschliche Sprache optimiert sind und sich für Modemsignale denkbar > schlecht eignen. Auch andere haben schon herausgefunden, daß es hier nicht um die Nutzung von GSM-Telephonen zur Datenübertragung geht. Nein, hier geht es darum, daß ein Mobiltelephon Daten mit über die Audioschnittstelle angeschlossener Peripherie austauscht, weil a) nicht jedes Mobiltelephon andere geeignete(re) Schnittstellen aufweist und b) diese Schnittstellen nicht bei jedem Mobiltelephonbetriebssystem ohne weiteres per Software ansteuerbar sind.
0815 schrieb: > Mal 'ne ganz bescheuerte Frage: > Wozu sollen digitale Daten für die Übertragung in ein Analogsignal > umgewandelt werden, um sie anschließend wieder für eine digitale > Übertragungsstrecke zu digitalisieren Nun, das ist genau dann sinnvoll, wenn als Übertragungsstrecke nur ein Audiokanal zur Verfügung steht. OMG, war das schwer. Da bist du nicht allein drauf gekommen?
Bell 202, 1200 baud Demodulator in an ATTiny10: https://sites.google.com/site/wayneholder/attiny-4-5-9-10-assembly-ide-and-programmer/bell-202-1200-baud-demodulator-in-an-attiny10 ... halt nicht ueber eine Audio-Luftschnittstelle.
Tiramisu schrieb: > In dem angesprochenen Experiment wurden uebrigens > keine Modems, sondern ein V.21 FSK-Modulator > und auf der Gegenseite ein V.21-Akustikkoppler verwendet. Vielleicht erklärst du mal den Unterschied.
> Vielleicht erklärst du mal den Unterschied.
V.21 FSK-Modulator: Sender
V.21-Akustikkoppler: Sender & Empfaenger
Tiramisu schrieb: > Bell 202, 1200 baud Demodulator in an ATTiny10: > > https://sites.google.com/site/wayneholder/attiny-4-5-9-10-assembly-ide-and-programmer/bell-202-1200-baud-demodulator-in-an-attiny10 > > ... halt nicht ueber eine Audio-Luftschnittstelle. Tolles Beispiel, danke! 0815 schrieb: > Mal 'ne ganz bescheuerte Frage: > Wozu sollen digitale Daten für die Übertragung in ein Analogsignal > umgewandelt werden, um sie anschließend wieder für eine digitale > Übertragungsstrecke zu digitalisieren und zu komprimieren Ein konkretes Beispiel: Ich möchte aus einer uC Schaltung Messdaten über mein iPhone auslesen und Konfigurationseinstellungen verändern. Da sich das Zielsystem Außen befindet, ist ein Netzwerk nicht sinnvoll und möglich, außerdem soll es aufs Energiesparen ausgelegt sein. Da es im Hobbybereich nicht möglich ist, die Lightning Schnittstelle vom iPhone zu verwenden, und damit es bspw. auch jemand mit einem Android Phone oder einem Notebook verwenden kann, bietet sich die Übertragung über Audio an..
>> bietet sich die Übertragung über Audio an..
Nachdem es jemand nur abstrakt als Stoerabstand erwaehnt hat:
Die Umgebungsgeraeusche und bei hoeheren Datenrate werden
Reflexionen des Schalls ein ziemliches Problem werden.
Bereits bei 1000Baud sind Deine Uebertragungseinheiten
in der Luft "nur 33cm lang", bei den Bell und CCITT
Frequenzen ist das etwa eine/zwei Kompression-en/Dekompression-en
der Luft.
Auch ein Demodulator muss sich "einschwingen"...
Die oben beschriebenen GSM Experimente habe hatte ich
sukzessive aufgebaut und auch ohne GSM Kanal
(also Modulator/Luft/CCITT-V.21-Akustikkoppler Dataphon) durchgefuehrt.
Bei einem ruhigen Laborumfeld geht das bis 1,0m bei 50 Baud tadellos,
bereits ein PC-Luefter in 0,5m stoert erheblich.
Nun ist ja ein Akustikkoppler nicht fuer diese grossen
Entfernungen designed, da geht bestimmt noch was, aber letztlich
wird die Physik des Schalls limitieren.
300Baud sind stabil, wenn sich der Modulationslautsprecher <10cm
in der direkten Verlaengerung der Hoermuschel des Akkustikkopplers
befindet (und es ruhig ist).
(Meine Definition von stabil war: Modulator gibt staendig
abcdefghijklmnopqrstuvwxyz<CR><LF> aus, im Terminalprogram,
das am Akustikkoppler hing, sehe ich maximal 1 Fehler pro Zeile)
0815 schrieb: > Wozu sollen digitale Daten für die Übertragung in ein Analogsignal > umgewandelt werden, um sie anschließend wieder für eine digitale > Übertragungsstrecke zu digitalisieren und zu komprimieren. Weil man so mehr Daten pro Zeiteinheit übertragen kann. Praktisch alle Modems funktionieren so.
Diejenigen, die sich gegenseitig beschimpfen wollen, können das gerne tun, aber nicht hier. Tauscht Eure Email-Adressen aus.
Hi Janis, Tipp: es gibt im Forum Threads, die sich mit Datenuebertragung mittels Ultraschall mit aehnlich gelagerten Problemen beschaeftigen/beschaeftigten.
Koennte auch ein Patentminenfeld sein (u.a. EU/EP Patente dabei): siehe z.B. http://www.intrasonics.com/patents.html
Tiramisu schrieb: > Koennte auch ein Patentminenfeld sein (u.a. EU/EP Patente dabei) Danke für den Hinweis, aber da ich mit meinen Kenntnissen weit davon entfernt bin etwas kommerziell zu veröffentlichen, dürfte das für mich keine Rolle spielen ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.