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.
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
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.
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
Hi Peter, ... das hat mich sehr nachdenklich gemacht! Ich habe momentan so ein Problem mit "Gleichlicht". Mal sehn was draus wird. Z8
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?
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.
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.
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/publications/Grubor_Gaete_High-Speed_Wireless_Indoor_Communication_via_Visible_Light_ITG_Breitbandversorgung_2007.pdf 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.
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
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?
> 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 ...
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
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.
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).
> 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.
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.
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
Ben Z. wrote: > Zur Programmiersprache: Bascom kenne ich nicht, aber in C bin ich > eigentlich ganz fit. Dann vergiß BASCOM.
@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.
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.
Bitte 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.