www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welcher MC für Audioübertragung über LED?


Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frohe Ostern zusammen!

Ich hab ein etwas vages Anliegen, wobei mir hier vielleicht jemand 
helfen kann. Es geht um folgendes:

Im Rahmen eines Projektes soll ein Audiosignal von einem PC zu einem 
anderen übertragen werden. Die Übertragung soll mittels einer weißen 
Power-LED erfolgen, die für das Auge unsichtbar in ihrer 
Strahlungsleistung variiert (Stichwort Visible Light Communication). 
Zunächst wird nur der Sender betrachtet. Quelle des Audiosignals ist wie 
gesagt ein PC, die LED ist samt Treiberschaltung vorhanden. Was jetzt 
fehlt ist ein Mikrocontroller, der das digitale Audiosignal (z.B. MP3) 
für den Anfang mittels einer PWM umwandelt und an die LED schickt. 
Grundsätzlich ist das Fernziel ein Full-Duplex WLAN üder LEDs zu 
entwickeln - aber das ist noch in weiter Ferne. Soweit in der Theorie.

Meine Frage ist jetzt, welchen Mikrocontroller man dafür idealerweise 
nimmt. Leider mangelt es unserem Team an MC-Kenntnissen. Die sollen 
erarbeitet werden, aber zunächst stellt sich eben die Frage welchen man 
nimmt. Rein spekulativ hab ich mal den AT91SAM7A3 vorgeschlagen, da der 
schon einen 20-bit PWM Controller dabei hat. Aber es gibt sicher noch 
andere Aspekte zu berücksichtigen.

Darum meine Frage, welcher MC sich für den zugegeben noch etwas vagen 
Sachverhalt am ehesten eignen könnte.

Danke schon mal für eure Hilfe.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am liebsten garkeinen Mikrocontroller. Schafft deine Superhelle LED 
überhaupt so schnelle Schaltzeiten?

Ansonsten bist du nicht der erste, der sowas erfindet, gibts schon fast 
ewig:
http://en.wikipedia.org/wiki/RONJA

Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gar kein Mikrocontroller steht leider nicht zur Option. Da es sich dabei 
um ein Hochschulprojekt handelt, kann ich mir die Rahmenbedingungen 
nicht aussuchen.

Die LED schafft mit ein paar Tricks die Schaltzeiten schon. Darüber habe 
ich ausreichend Material.

Stimmt, RONJA gibts schon eine ganze Zeit. Die machen aber nicht das, 
was ich brauche. RONJA benutzt Linsen, um eine gezielte 
Übetragungsstrecke ziwschen 2 Punkten herzustellen. Bei meinem Projekt 
geht es um die ungerichtete Datenübertragung mittels LEDs, die für die 
Raumbeleuchtung geeignet sind. Ziel ist eine Vereinigung von Beleuchtung 
und Datenübertragung.
Auch das ist nicht neu, aber noch in den Kinderschuhen. Nur im 
asiatischen Raum ist man da schon etwas weiter.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben Z. wrote:
> Im Rahmen eines Projektes soll ein Audiosignal von einem PC zu einem
> anderen übertragen werden. Die Übertragung soll mittels einer weißen
> Power-LED erfolgen, die für das Auge unsichtbar in ihrer
> Strahlungsleistung variiert

Das ist ein Widerspruch.
Schwankt die Leistung, dann siehst Du auch ein Flackern.

Du brauchst ne Modulation, die die Leistung konstant hält, z.B. 
Frequenzmodulation, Phasenmodulation. Damit kannst Du dann auch den 
Einfluß von Fremdlicht unterdrücken.


Peter

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

... das hat mich sehr nachdenklich gemacht! Ich habe momentan so ein
Problem mit "Gleichlicht".  Mal sehn was draus wird. Z8

Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Du brauchst ne Modulation, die die Leistung konstant hält, z.B.
> Frequenzmodulation, Phasenmodulation. Damit kannst Du dann auch den
> Einfluß von Fremdlicht unterdrücken.

Hm, ja stimmt. D.h. die integrierte PWM bringt mir nicht viel. Was mich 
dann wieder zu meiner Ursprungsfrage bringt: Welcher Mikrocontroller ist 
dafür wohl am günstigsten?

Autor: Ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde sagen, das der konkrete Microcontroller erstmal nebensächlich 
ist.

Hauptsache, das das Übertragungsverfahren überhaupt mal funktioniert.
Nimm zum probieren einfach mal einen auf dem Du das Konzept, das Du 
probieren willst auch implementieren kannst.

Danach erst optimieren.

Also, erstmal Übertragungsverfahren aussuchen und probieren.

Autor: Matrix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wandle das Audiosignal in SPDIF um (oder nimm gleich das als Quelle) und 
geb dieses Signal auf die LED drauf. Dürfte für das Auge keine 
sichtbaren Änderungen geben.

Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ahem wrote:
> Hauptsache, das das Übertragungsverfahren überhaupt mal funktioniert.
> Nimm zum probieren einfach mal einen auf dem Du das Konzept, das Du
> probieren willst auch implementieren kannst.

Naja, ich will hier ja nicht das Rad neu erfinden. Ich weiß, dass diese 
Übertragungsart mit einer PAM oder auch einer QAM funktioniert. Siehe 
z.B. 
http://www.lnt.ei.tum.de/mitarbeiter/gaete/publica... 
Also werden wir da ansetzen. Da ich aber wie gesagt keine Ahnung von den 
verschiedenen Mikrocontrollern habe, weiß ich nicht auf welchem sich 
denn nun z.B. eine PAM gut implementieren läßt.

Gast wrote:
> Wandle das Audiosignal in SPDIF um (oder nimm gleich das als Quelle) und
> geb dieses Signal auf die LED drauf. Dürfte für das Auge keine
> sichtbaren Änderungen geben.

Das ist nicht so gut. Eine Audioübetragung soll schließlich nur der 
erste Schritt sein. Ziel ist es beliebige Daten zu übertragen und da ist 
SPDIF nicht so sinnvoll.

Autor: Roland Praml (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
erst mal sollte man das Übertragungsverfahren festlegen, indem man sich 
überlegt:
- ist der Code gleichspannungsfrei, sprich keine Helligkeitsänderung
- wie aufwändig ist die Codierung
- wie aufwändig die Dekodierung

-> wird wohl auf PSK bzw. FSK raus laufen.

Dann die vorerst nötige Bandbreite. Hier sollte man sich nicht 
überschätzen, 54 MBit sind wohl vorerst NICHT nötig. Eher was im Bereich 
115,2KBit

Hat man dies alles, sieht man sich mal seine Lieblingscontroller an. Ein 
AVR mit UART und LED am PWM, sollte (bei 4-8 MHz) noch genug 
Rechenleistung haben, um PSK/FSK durchzuführen.

Wenn du dann mal in den MBit-Bereich kommst, dann wirst wohl eine 
Zusatzhardware (CPLD o. ein TTL Grab) für die PWM-Erzeugung brauchen, da 
ein µC das meist nicht mehr schafft.

Wobei du da dann noch das Problem hast, dass du die LED's auch schnell 
genug ansteuern können musst.

Gruß
Roland

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland Praml wrote:
> erst mal sollte man das Übertragungsverfahren festlegen, indem man sich
> überlegt:
> - ist der Code gleichspannungsfrei, sprich keine Helligkeitsänderung
> - wie aufwändig ist die Codierung
> - wie aufwändig die Dekodierung
>
> -> wird wohl auf PSK bzw. FSK raus laufen.

Ja, ich halte eine PSK oder FSK für den Anfang auch für recht 
wahrscheinlich.

> Hat man dies alles, sieht man sich mal seine Lieblingscontroller an. Ein
> AVR mit UART und LED am PWM, sollte (bei 4-8 MHz) noch genug
> Rechenleistung haben, um PSK/FSK durchzuführen.

Da ich bislang nur am Rande mit Controllern zu tun hatte, habe ich da 
keinen Liebling. Welchen würdest du spontan empfehlen? Letzlich brauche 
ich nur irgendeinen mit dem wir beginnen können. Falls sich dann im 
Laufe des Projekts herausstellt, dass wir einen anderen brauchen weil 
vielleicht bestimmte Anforderungen auftreten, die ich jetzt noch nicht 
kenne, ist das auch kein Problem. Dann fordern wir einen neuen an. 
Hauptsache ich habe irgendwo einen Startpunkt.

> Wenn du dann mal in den MBit-Bereich kommst, dann wirst wohl eine
> Zusatzhardware (CPLD o. ein TTL Grab) für die PWM-Erzeugung brauchen, da
> ein µC das meist nicht mehr schafft.

Das ist interessant. Da muss ich mich dann bei Gelegenheit mal genauer 
mit beschäftigen.

> Wobei du da dann noch das Problem hast, dass du die LED's auch schnell
> genug ansteuern können musst.

Auch das wird noch hinreichend betrachtet werden müssen, da gebe ich dir 
recht.
Grundsätzlich erstmal danke für diesen konstruktiven Beitrag zu meiner 
Frage.


Gast wrote:
>http://www.heise.de/newsticker/Drahtloses-Netzwerk...

Willst du mir mit diesem begrenzt informativen Heiseartikel etwas 
bestimmtes sagen?

Autor: Niels Keller (niels-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da ich bislang nur am Rande mit Controllern zu tun hatte, habe ich da
> keinen Liebling. Welchen würdest du spontan empfehlen? Letzlich brauche
> ich nur irgendeinen mit dem wir beginnen können.

Hallo, schalte mich da gerade mal ein...
Interessantes Vorhaben. Ich selbst weiß wie unflexibel solche Vorgaben 
sein können (muss mit uP gemacht werden). Also einfach zu programmieren 
und billig und mit PWM-Ausgängen sind Atmegas. Ist die 
Programmiersprache vorgegeben? Wenn nein, dann empfiehlt sich Bascom zu 
nehmen. Das Programm ist zur Entwicklung eines Algorithmuses gut zu 
gebrauchen. Später kann man dann immer noch einen C-Code schreiben. Als 
Anfang empfehle ich das Pollin Evaluationsboard. Dazu kauft man dann 
noch einige Atmegas und Tinys und lässt den Atmega mit 16 Mhz bzw. den 
Tiny mit 20 Mhz laufen. Wenn es dann nach eingiger Zeit läuft wird es 
Zeit auf einen C-Code umzusteigen ...

Autor: Roland Praml (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Niels, würde ich dir erstmal einen AVR empfehlen, z.B. einen 
ATMEGA32.

Dieser hat genug Portpins um ohne großen Aufwand noch ein LCD für 
Debug-Meldungen o.Ä. anschließen zu können. Der Tipp mit dem 
Evaluationsboard ist sicher nicht verkehrt, wenns auch später eine 
eigene Platine werden wird, allein schon wegen der FET-Ansteuerung.
Wenn du ein Evalboard bestellst, kannst du ja ggf. gleich noch das 
CPLD-Evalboard mitbestellen, dass es momentan bei Pollin gibt.

Gruß
Roland

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss also zur Beleuchtung dienlich sein. Wie wäre es mit RGB-LED`s statt 
weissen LED`s?
Dann könnte man die Information auf die Lichtfarbe statt auf die 
Helligkeit aufmodulieren, Helligkeitsunterschiede fallen Stärker auf als 
Farbunterschiede.

Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niels Keller wrote:
> Hallo, schalte mich da gerade mal ein...
> Interessantes Vorhaben. Ich selbst weiß wie unflexibel solche Vorgaben
> sein können (muss mit uP gemacht werden). Also einfach zu programmieren
> und billig und mit PWM-Ausgängen sind Atmegas. Ist die
> Programmiersprache vorgegeben? Wenn nein, dann empfiehlt sich Bascom zu
> nehmen. Das Programm ist zur Entwicklung eines Algorithmuses gut zu
> gebrauchen. Später kann man dann immer noch einen C-Code schreiben. Als
> Anfang empfehle ich das Pollin Evaluationsboard. Dazu kauft man dann
> noch einige Atmegas und Tinys und lässt den Atmega mit 16 Mhz bzw. den
> Tiny mit 20 Mhz laufen. Wenn es dann nach eingiger Zeit läuft wird es
> Zeit auf einen C-Code umzusteigen ...

Danke, das ist ja schon mal ein super Ansatz. Die Atmegas und das EB 
kosten ja auch nicht die Welt, damit kann man dann schon gefahrlos 
rumprobieren.
Zur Programmiersprache: Bascom kenne ich nicht, aber in C bin ich 
eigentlich ganz fit. Da müsste ich mich aber eh erst mit den restlichen 
Teammitgliedern absprechen.

Roland Praml wrote:
> Wenn du ein Evalboard bestellst, kannst du ja ggf. gleich noch das
> CPLD-Evalboard mitbestellen, dass es momentan bei Pollin gibt.

Gute Idee. Dann hat man das schon mal da. Es geht ja letztendlich auch 
erstmal darum anzufangen und sich mit der Materie vertraut zu machen. 
Dafür scheint mir das schon mal eine gute Möglichkeit zu sein. Danke 
nochmal.

Andreas Klepmeir wrote:
> Muss also zur Beleuchtung dienlich sein. Wie wäre es mit RGB-LED`s statt
> weissen LED`s?
> Dann könnte man die Information auf die Lichtfarbe statt auf die
> Helligkeit aufmodulieren, Helligkeitsunterschiede fallen Stärker auf als
> Farbunterschiede.

Die weißen LED sind für eine Arbeitsplatzbleuchtung besser geeignet, 
weil sie vor allen Dingen viel heller sind (insb. in der 
Power-LED-Variante).

Autor: Niels Keller (niels-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Zur Programmiersprache: Bascom kenne ich nicht, aber in C bin ich
> eigentlich ganz fit. Da müsste ich mich aber eh erst mit den restlichen
> Teammitgliedern absprechen.


Bascom ist wie Basic, hat aber auch OO-Elemente. Bei Programmierung in C 
empfiehlt sich AVR Studio zu nehmen.

Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niels Keller wrote:
> Bascom ist wie Basic, hat aber auch OO-Elemente. Bei Programmierung in C
> empfiehlt sich AVR Studio zu nehmen.

Okay, dann bleibe ich wohl besser bei C. In Basic hab ich praktisch gar 
keine Erfahrung. ;-) Danke für die Infos.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also einen Atmega würde ich dafür nicht nehmen.
Warum?
Du musst dein Audiosignal ja auch irgendwie in den Controller bringen. 
Eventuell sogar analog. Da machen 12 bit AD-Wandlerauflösung noch nicht 
wirklich Spaß. Mal angenommen, du willst Stereo in CD-Qualität 
übertragen (damit hätte ich jetzt mal angefangen, muss ja nicht gleich 
HD sein), sind das etwa 1,5 Megabit/Sekunde. Das ganze auf einem Atmega 
in eine FSK zu codieren, halte ich nicht unbedingt für eine einfache 
Aufgabe, denn dafür braucht man Rechenleistung. Eine Menge 
Rechenleistung. Und FSK allein genügt ja nicht. Man muss ja noch 
Hilfsdaten mit integrieren (Rechts-Links-Codierung, 
Samplestartmarken...). FSK ist eine Modulationsart mit analogem 
Ausgangssignal, das erstmal erzeugt werden muss. Aber nicht mit einem 
Atmega, der hat nämlich keine DA-Wandler. Üblicherweise wird die FSK 
auch erst im Basisband analog erzeugt und dann erst auf die HF 
aufgemischt. Aber auch dazu sind sehr schnelle Wandler nötig, deren 
Anbindung an einen Atmega einfach nur ohne Ende kompliziert sein werden.

Ich würde dir zu einem Prozessor raten, der für Audioanwendungen gedacht 
ist. Da hast du schon die richtigen Schnittstellen für 
Audioanalogwandler (I2S Format) und vor allem viel mehr Rechenleistung 
und Arbeitsspeicher. Für den Anfang wäre da z.B. ein Arm7 nicht 
schlecht. Ich hab mit denen von Atmel (AT91SAM7X... oder AT91SAM7SE... 
für externes RAM) gute Erfahrungen gesammelt. Als Compiler verwende ich 
den (kostenlosen) WINARM (gcc). Programmiert werden die direkt über ihre 
eigene USB-Schnittstelle, du brauchst also keine teure Hardware zum 
Programmieren.

Bezahlbar sind sie auch, schau beim Reichelt, da sind sie meines Wissens 
nach am günstigsten.

Wenn du für dein Projekt gute finanzielle Mittel hast, würde ich 
durchaus auch zu einem DSP greifen. Ein Texas Instruments TMS320C6000 
ist dafür optimal. Schau mal bei Spectral Digital, da gibt es ein 
TMS320C6713 DSK, da ist alles dabei (uneingeschränkter Compiler - der 
nur mit diesen Boards funktioniert, Matlab Testversion, Netzteil, AD und 
DA Wandler für Audio, onboard USB Debugger und vor allem eine Menge 
Arbeitsspeicher und Rechenleistung ohne Ende).

So ein Board bekommt man bei ebay manchmal schon für unter 300 Euro.


Allgemein würde ich dir empfehlen, dass du dir mal ein gutes 
Grundlagenwissen aneignest, bezüglich dem was es am Markt an Controllern 
gibt. Schau dir dazu einach mal die Webseite von Atmel, Texas 
Instruments und Philips an.

Beliebte Hochleistungsprozessoren sind der Arm7 (auch Arm9) die von 
vielen Herstellern implementiert werden, der TMS320 von Texas 
Instruments, die DSPs von Analog Devices und eventuell auch der dsPIC 
von Microchip (von dem ich dir als Anfänger aber eher abraten würde - er 
ist nicht schlecht, aber er braucht einfach viel Erfahrung).

Bedenke auch, dass dir bei manchen Prozessoren hier Leute helfen können, 
bei anderen wieder nicht.
Im DSP-Forum ist der TMS320 und der Blackfin (Analog Devices) gut 
bekannt, dsPIC und der AT32 von Atmel eher nicht.

Im englischsprachigen Arm Forum sind die Arm 7 (LPC... von Philips) 
sowie die Arm 7 (AT91SAM... von Atmel) gut bekannt, Intel (PXA...) eher 
nicht.


Nur noch so als Anregung: Wie wäre es mit einer Datenübertragung mit dem 
IRDA Protokoll? Das wäre für Audio schnell genug und ist für 
raumlichtgestörte Übertragungen gedacht. Eben nur für Infrarot, aber das 
macht ja nichts. Viele Prozessoren können mit ihrem UART-Modul direkt 
IRDA-Codierung erzeugen. Ließ einfach mal ein paar Datenblätter der 
gängigen Prozessoren. Auf den ersten Seiten steht immer eine 
Zusammenfassung, was sie können.

Grüße,

Peter

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben Z. wrote:

> Zur Programmiersprache: Bascom kenne ich nicht, aber in C bin ich
> eigentlich ganz fit.

Dann vergiß BASCOM.

Autor: Ben Z. (yossarian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

Danke für die sehr ausführlichen Hinweise. Damit kann ich schon mal sehr 
viel anfangen. Jetzt steht und fällt es damit, auf was man sich an der 
Hochschule einläßt.

Ich melde mich, sobald ich definitiv weiß, womit wir arbeiten werden.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum gleich so kompliziert? Der Controller kann doch eine 
Manchester-Codierung machen und damit direkt an den LED-Treiber gehen, 
der Empfänger muss dann nur mit einem Bandpass den Träger rausfiltern 
und den Manchestercode decodieren. Wenn die LEDs hell und der Treiber 
schnell genug ist sollte das schon reichen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.