Announcement: there is an English version of this forum on Kennt ihr eigentlich schon http://www.elv.de/controller.aspx?cid=726&detail=44159 und http://www.elv.de/controller.aspx?cid=726&detail=44846 ? Dort wird ein PIN eines mit 3,3V betriebenen STM8L151C8U6 pro IR-Sender und ein PIN pro IR-Empfänger verwendet. Die Sendeschaltung ist uc-Pin über 1K an die Basis eines BCW66H Transistors, Emitter an GND, Kollektor über Infraot-LED IR333-A und 33 Ohm Widerstand an +UB (vermutlich 5V). Die Empfangsschaltung ist uc-Pin über eine Fotodiode SFH203FA und parallel 270p/50V an GND und der Pin auch über 470K an +3,3V. Die 8 weißen LEDs werden über 8 Ausgänge des TLC5946 betrieben, die anderen 8 sind unbenutzt. Ich hoffe es ist okay, diese Information zu reproduzieren.
Tim R. schrieb: > hm der rest hier keine lust mehr oder schon mit einem bierchen in der > sonne ?? ;-P Für ein Projekt im Ausland, grad keinen Kopf für anderes. Nächste Woche wieder zurück.
Hallo, nun hatte ich mich ja schon lange nicht mehr gemeldet. @johnpatcher: Entschuldigung, ich wusste nicht, daß das mit dem IR-Touch unter satiniertem Glas schon so gut getestet ist. Die, weiter oben genannte, Idee, IR-Sender und IR-Empfänger in gegenüberliegende Ecken der Zelle zu setzen ist sicher gut, das mindert auch den Anteil des vom satinierten Glas gestreuten Lichts, im Empfänger. Vielleicht macht es auch Sinn Sender und Empfänger nahe an das Glas ranzubringen, dann muß man aber aufpassen wegen Schattenbildung. Weiter oben wurde vorgeschlagen zwei UART-Ringe über alle Pixelplatinen zu führen, das würde ich nicht machen, erzeugt nur ne Menge unnötige Rechnerei auf den Pixeln, und dmit eine Verschlechterung des Timings. Wenn schon zwei UART-Ringe am Hauptcontroller, aber je einen für die Hälfte der Pixelplatinen. Um ein stabiles Timing zu erreichen, könnte man ja 'nur' den UART-Rx Interupt laufen lassen, und dort auch das senden von Bytes anstoßen, so würde die Verzugszeit pro Pixel nur um ca. 4 Controller-Taktzyklen wariieren. Den Rest dann über Polling erledigen, aber der Controller der Pixel hat ja Zeit genug. Man könnte Übertragungsbandbreite sparen, wenn man nicht RGB-Daten, sondern Daten im HSV-Farbraum überträgt. Bei RGB sind 8 Bit/Farbe recht wenig, wird schnell stufig, wenn nicht die volle Helligkeit gewünscht wird. Bei HSV muß nur die Helligkeit feinstufig sein, Bei Farbe und Sättigung reichen je 8 Bit gut aus. Bei der Helligkeit könnte man, im Pixelcontroller, noch eine Dimmkurve hinterlegen, die das logarythmische Helligkeitsempfinden des Auges berücksichtigt, dann reichen auch für die Helligkeit 8 Bit. Mit freundlichem Gruß - Martin
Frank M. schrieb: > Sehe ich genauso. Wieviele 10.000 Stunden hält so eine IR-Diode? "Halten" ist relativ. Bis zum Totalausfall sind es sicherlich etliche Stunden, aber eine Alterung (LED wird bei gleich Strom schwächer) tritt ggf. deutlich früher auf. > Wieviele Stunden am Tag ist der Tisch eingeschaltet? Den ganzen Tag ;)? Bzw. den halben Tag, weil die LED jeweils nur die Hälfte der Zeit eingeschaltet ist. Klar kann man auch über Auto On/Off nachdenken (wie bei der Wordclock), aber prinzipiell sollte der Tisch auch ein dauerhaftes Einschalten überstehen. Frank M. schrieb: > Ich halte diese "Untersuchungen" für rein akademisch. So akademisch finde ich das gar nicht. Frank M. schrieb: > IR-Diode per > Widerstand an einen (PWM-)Portpin und fertig. Eine (ungeglättete) PWM bringt ja wie gesagt nichts. Und eine ordentliche Glättung gestaltet sich nicht so einfach wie gedacht. Außerdem sind die 40 mA, die geliefert werden können ggf. zu wenig. Die IR LED kann 50 mA dauerhaft abhaben, gepulst sogar bis zu 1A, wenn ich das jetzt richtig im Kopf habe. Tim R. schrieb: > hm der rest hier keine lust mehr oder schon mit einem bierchen in der > sonne ?? ;-P Eher Letzteres ;). Konrad S. schrieb: > Die Auswertung sollte im 2x2- oder 3x3-Raster erfolgen, damit die > benachbarten Zellen nicht stören. Was meinst du damit bzw. wie willst du die nötige Synchronisation erreichen? Christian H. schrieb: > Kennt ihr eigentlich schon > http://www.elv.de/controller.aspx?cid=726&detail=44159 > und > http://www.elv.de/controller.aspx?cid=726&detail=44846 > ? Nein, schaut aber auch ganz interessant aus. Im Grunde ja der selbe Ansatz mit ein bisschen anderen Komponenten. Schaue ich mir mal im Detail an (wird man wohl den Artikel kaufen müssen :(). Die verwendete Fotodiode ist aber deutlich teurer. Martin Schlüter schrieb: > Die, weiter oben genannte, > Idee, IR-Sender und IR-Empfänger in gegenüberliegende Ecken der Zelle zu > setzen ist sicher gut, das mindert auch den Anteil des vom satinierten > Glas gestreuten Lichts, im Empfänger. Das müsste man wohl einfach mal wieder ausprobieren. Ich persönlich halte das für unnötig, weil es anders auch schon funktioniert hat und man mit einem solchen Ansatz Gefahr läuft "tote Winkel" zu schaffen. Martin Schlüter schrieb: > Weiter oben wurde vorgeschlagen zwei UART-Ringe über alle Pixelplatinen > zu führen, das würde ich nicht machen, erzeugt nur ne Menge unnötige > Rechnerei auf den Pixeln, und dmit eine Verschlechterung des Timings. Ja, wobei man ja auch darüber nachdenken könnte, dass bestimmte Daten nicht mehr weitergereicht werden. Durch zwei Ringe verdoppelt sich halt der Durchsatz. Dieser Aspekt ist bisher aber noch von keinem erprobt worden. Martin Schlüter schrieb: > Den Rest dann über Polling erledigen, > aber der Controller der Pixel hat ja Zeit genug. Bin mir noch nicht ganz sicher was noch so alles ansteht (ADC, Timer), aber das alles per Polling zu erledigen gefällt mir nicht wirklich. Martin Schlüter schrieb: > Man könnte Übertragungsbandbreite sparen, wenn man nicht RGB-Daten, > sondern Daten im HSV-Farbraum überträgt. Bei RGB sind 8 Bit/Farbe recht > wenig, wird schnell stufig, wenn nicht die volle Helligkeit gewünscht > wird. Bin sicherlich kein Experte auf dem Gebiet der Farbenlehre bzw. Informationstheorie, aber wieso sollte HSV sparsamer als RGB sein? Das stufige Verhalten bei geringen Helligkeiten ist ja nicht dem RGB Farbraum selbst zuzusprechen, sondern ist der zu geringen PWM Auflösung geschuldet. Und selbst wenn wir die Farbwerte per HSV übertragen, dann müssen wir sie letztendlich in PWM Werte umrechnen und stehen (bei 8-Bit) vor dem selben Problem. Der ATtiny841 bietet aber genug 16 Bit Timer, insofern sollten wir hier keine Probleme bekommen. Notfalls kann man mit ein bisschen Rechenaufwand auch eine 8 Bit Hardware PWM per Software erweitern. Oder habe ich etwas an deinem Ansatz fundamental falsch verstanden? Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > "Halten" ist relativ. Bis zum Totalausfall sind es sicherlich etliche > Stunden, aber eine Alterung (LED wird bei gleich Strom schwächer) tritt > ggf. deutlich früher auf. ich finde den Ansatz trotzdem etwas quatsch. Was ist denn mit der Leuchtdiode die die Farbe hergibt? Die wäre mir viel wichtiger, weil dort das Auge drauf schaut. Wenn dann müssten schon beide im Altererungsprozess berücksichtigt werden.. und das ist einfach viel zu aufwändig bin ich der Meinung, um ein paar Stunden Leuchtkraft zu gewinnen. Notfalls kann man ja alle 5 Jahre oder neue LEDs einlöten, sollte ja auch nicht so das Problem sein oder ?! :-D >> Wieviele Stunden am Tag ist der Tisch eingeschaltet? > > Den ganzen Tag ;)? Bzw. den halben Tag, weil die LED jeweils nur die > Hälfte der Zeit eingeschaltet ist. Klar kann man auch über Auto On/Off > nachdenken (wie bei der Wordclock), aber prinzipiell sollte der Tisch > auch ein dauerhaftes Einschalten überstehen. Also mein Tisch wird nicht mal annähernd einen halben Tag (ausser zu Anlässen) an sein... > Tim R. schrieb: >> hm der rest hier keine lust mehr oder schon mit einem bierchen in der >> sonne ?? ;-P > > Eher Letzteres ;). Gefällt mir, wo ist meine Pooleinladung ;-) > > Konrad S. schrieb: >> Die Auswertung sollte im 2x2- oder 3x3-Raster erfolgen, damit die >> benachbarten Zellen nicht stören. > > Was meinst du damit bzw. wie willst du die nötige Synchronisation > erreichen? Verstehe den Ansatz auch nicht ganz.. ich denke mit unseren bisherigen Ansätzen fahren wir schon gut > Das müsste man wohl einfach mal wieder ausprobieren. Ich persönlich > halte das für unnötig, weil es anders auch schon funktioniert hat und > man mit einem solchen Ansatz Gefahr läuft "tote Winkel" zu schaffen. Das denke ich auch. Wozu jetzt das "geschaffene" wieder verändern... und dann müsste man denke ich auch alle vier Ecken jeweils ausstatten oder? > Ja, wobei man ja auch darüber nachdenken könnte, dass bestimmte Daten > nicht mehr weitergereicht werden. Durch zwei Ringe verdoppelt sich halt > der Durchsatz. Dieser Aspekt ist bisher aber noch von keinem erprobt > worden. Das erfordert leider ein paar Pixel/Slaves zum Testen. Aber der Ansatz mit 2xUART ist denke ich schon am günstigsten. Vorallem können auf diese kurzen Strecken auch locker 500kBaud oder mehr erreicht werden. Alle Attiny unterstützen die selben Geschwindigkeiten. Hab gerade nochmal nachgeschaut, Theoretisch wären 1Mbaud bei 16MHz möglich :-) das sollte wohl langen? > Bin mir noch nicht ganz sicher was noch so alles ansteht (ADC, Timer), > aber das alles per Polling zu erledigen gefällt mir nicht wirklich. Polling würde ich an der Stelle gar nicht betreiben. Ausser der Hauptschleife gibt es keine Schleifen. Wenn ein (UART)-IR kam mit neuen Farbwerten, werden die entweder im IR oder eben per Flag in der Hauptschleife übernommen und eine ADC-Messung gestartet. Der ADC-IR kann dann das Rücksenden in Gang bringen. Also Polling sehe ich an keiner Stelle(wozu auch?) > Bin sicherlich kein Experte auf dem Gebiet der Farbenlehre bzw. > Informationstheorie, aber wieso sollte HSV sparsamer als RGB sein? Das > stufige Verhalten bei geringen Helligkeiten ist ja nicht dem RGB > Farbraum selbst zuzusprechen, sondern ist der zu geringen PWM Auflösung > geschuldet. Und selbst wenn wir die Farbwerte per HSV übertragen, dann > müssen wir sie letztendlich in PWM Werte umrechnen und stehen (bei > 8-Bit) vor dem selben Problem. Der ATtiny841 bietet aber genug 16 Bit > Timer, insofern sollten wir hier keine Probleme bekommen. Notfalls kann > man mit ein bisschen Rechenaufwand auch eine 8 Bit Hardware PWM per > Software erweitern. Das war auch mein Gedanke. Wir sind eher an die 8bit PWM Hardwaretechnisch gebunden. Es sei denn, es wird eine 10bit oder mehr genutzt. Der Vorteil am HSV ist, dass die Farben eher dem AUge "freundlich" vorkommen oder so Ähnlich hatte ich es mal im Kopf (Achtung gefährliches Halbwissen). Sollte man mal Wiki und co studieren. Aber die Datenmenge unterscheidet sich nicht großartig. Deswegen würde ich mir erst Gedanken über den Bus machen, wie man am schnellsten viele Daten vom Master zu den Pixeln bekommt und zurück.
:
Bearbeitet durch User
Hallo, Ich verfolge diesen Beitrag schon einige Zeit und mich hat nun auch das Fieber gepackt solch einen Tisch zu bauen. Da ich auch gern experimentiere habe ich zu dem Projekt eine Frage. Wie weit wurde denn nun die Hardware der led Ansteuerung festgelegt, oder gibt es hierbei eine Festlegung? Welchen Controller verwenden wir? Welche IR Sender und Empfänger werden bevorzugt Wie sieht die Kommunikation aus I2C oder UART Soll ein mikrocontroller nur eine RGB led steuern oder soll zwei RGB LEDs an einen Controller angeschlossen werden, dies wurde ggf. Eine IR Einheit ersparen. Bei geeignetem Controller wäre auch eine dreier Kombination aus 3x RGB und einer IR Einheit erdenklich. Wie sollen die einzelnen Platinen aussehen, 4eckick, 6eckig, USW. Die Platinen sollten untereinander steckbar sein, oder per Leitung verbunden werden? Freue mich schon auf das Projekt Viele Grüße
M. G. schrieb: > Hallo, > Ich verfolge diesen Beitrag schon einige Zeit und mich hat nun auch das > Fieber gepackt solch einen Tisch zu bauen. > > Da ich auch gern experimentiere habe ich zu dem Projekt eine Frage. Schön einen weiteren Interessenten gefunden zu haben! > > Wie weit wurde denn nun die Hardware der led Ansteuerung festgelegt, > oder gibt es hierbei eine Festlegung? Festgelegt ist eigentlich noch gar nichts. Aber an den Kommentaren kristallisieren sich denke ich auch langsam die Hauptgewichte raus. Ich werde das am nächsten WE mal zusammenfassen und ggf. den eröffneten Artikel zum Projekt aktualisieren > > Welchen Controller verwenden wir? Hier wurde der Attiny841 ins Auge gefasst. > Welche IR Sender und Empfänger werden bevorzugt Karol Babioch hatte hierzu ein sehr schönes Video hochgeladen mit seinen getesteten Komponenten. Da diese sehr gut zusammen funktionierten und auch günstig zu erwerben sind, denke ich werden wir uns alle auf diese einigen. Hab grad keine Namen im Kopf (einfach mal nach oben scrollen dort sind irgendwo Links) > Wie sieht die Kommunikation aus I2C oder UART kein I2C. eher UART, aber noch nicht festgelegt... > > Soll ein mikrocontroller nur eine RGB led steuern oder soll zwei RGB > LEDs an einen Controller angeschlossen werden, dies wurde ggf. Eine IR > Einheit ersparen. Bei geeignetem Controller wäre auch eine dreier > Kombination aus 3x RGB und einer IR Einheit erdenklich. Ein Pixel bekommt einen Attiny. Dieser steuert die IR-LED und die RGB (oder ggf. mehrere) in seinem Pixel. Hier wird noch über die Bereitstellung des Stroms diskutiert, da die ja doch ein paar mA benötigen. > > Wie sollen die einzelnen Platinen aussehen, 4eckick, 6eckig, USW. ein Pixel -> viereckig > Die Platinen sollten untereinander steckbar sein, oder per Leitung > verbunden werden? wird ebenfalls diskutiert. Steckverbindungen könnten knapp werden, da zwischen den Pixeln Trennwände angedacht sind. > > Freue mich schon auf das Projekt > > Viele Grüße Beim nächsten mal bitte (auch wenn es viel ist) die Beiträge durchlesen. Denn wenn jeder nun ankommt und erneut diese Fragen stellt, nimmt das hier kein Ende. Ich habe das aber nun einmalig für dich zusammengefasst ;-)
Karol Babioch schrieb: > Konrad S. schrieb: >> Die Auswertung sollte im 2x2- oder 3x3-Raster erfolgen, damit die >> benachbarten Zellen nicht stören. > > Was meinst du damit bzw. wie willst du die nötige Synchronisation > erreichen? Es gab ja immer mal Forderungen, die Pixel zu synchronisieren, d.h. daß nicht jedes Pixel die Farbe wechselt, wann immer es neue Daten bekommt, sondern damit auf ein Synchronsignal wartet, das alle Pixel gleichzeitig erreicht (naja, gleichzeitiger als die Daten jedenfalls). Damit kann man dann auch die IR-Messung synchronisieren. Die Pixel werden in mehrere Gruppen eingeteilt, z.B. schachbrettartig, und eine Gruppe mißt in der einen Hälfte einer Framezeit, die andere in der anderen. Damit jedes Pixel weiß, zu welcher Gruppe es gehört (bzw. mit wieviel Verzögerung nach dem Framesync es IR-leuchten darf, ohne die Nachbarn zu stören), muß der Master einmal ein Config-Telegramm senden, das für jedes Pixel anstelle RGB-Daten die Gruppennummer enthält. > Martin Schlüter schrieb: >> Weiter oben wurde vorgeschlagen zwei UART-Ringe über alle Pixelplatinen >> zu führen, das würde ich nicht machen, erzeugt nur ne Menge unnötige >> Rechnerei auf den Pixeln, und dmit eine Verschlechterung des Timings. > > Ja, wobei man ja auch darüber nachdenken könnte, dass bestimmte Daten > nicht mehr weitergereicht werden. Durch zwei Ringe verdoppelt sich halt > der Durchsatz. Dieser Aspekt ist bisher aber noch von keinem erprobt > worden. Man kann ja zur Durchsatzsteigerung beliebig viele Ringe einrichten, so viele, wie der Master Ports hat. Aber jedes Pixel ist am besten nur an genau einem Ring beteiligt. > Martin Schlüter schrieb: >> Man könnte Übertragungsbandbreite sparen, wenn man nicht RGB-Daten, >> sondern Daten im HSV-Farbraum überträgt. Bei RGB sind 8 Bit/Farbe recht >> wenig, wird schnell stufig, wenn nicht die volle Helligkeit gewünscht >> wird. > > Bin sicherlich kein Experte auf dem Gebiet der Farbenlehre bzw. > Informationstheorie, aber wieso sollte HSV sparsamer als RGB sein? Das > stufige Verhalten bei geringen Helligkeiten ist ja nicht dem RGB > Farbraum selbst zuzusprechen, sondern ist der zu geringen PWM Auflösung > geschuldet. Und selbst wenn wir die Farbwerte per HSV übertragen, dann > müssen wir sie letztendlich in PWM Werte umrechnen und stehen (bei > 8-Bit) vor dem selben Problem. Der ATtiny841 bietet aber genug 16 Bit > Timer, insofern sollten wir hier keine Probleme bekommen. Notfalls kann > man mit ein bisschen Rechenaufwand auch eine 8 Bit Hardware PWM per > Software erweitern. RGB vs. HSV hängt davon ab, wer die Gammakurve rechnet. Wenn die Pixel einfach nur dumm die befohlenen RGB-Werte linear darstellen, sind 8 bit zu wenig. Und dann braucht man auf einmal für RGB 30 oder 48 bit, damit man 10- bzw. 16bit-PWM machen kann und die Helligkeitsstufen nicht mehr auffallen. In so einer Situation ist HSV ein Vorteil, weil man da die Gesamthelligkeit (also das, worauf das Auge so empfindlich reagiert) als separate Zahl mit höherer Genauigkeit übertragen kann als die Farbangaben. Aber dann müssen die Pixel HSV-->RGB rechnen; und wenn sie das können, können sie genausogut je eine Gammakurve für R, G und B rechnen, und gut is. War bisher ja auch implizit so vorgesehen. Wenn man extrapingelig ist, macht es natürlich einen Unterschied, ob man die Gammakurve für die Gesamthelligkeit rechnet oder für die Farben einzeln (was falsch wäre), aber das wird wohl in der Praxis kaum auffallen.
Das mit dem HSV Farbraum habt ihr nicht ganz verstanden, 8 Bit PWM für RGB Anwendungen ist, im unteren Bereich, zu grob, da sollte man höher gehen, mindestens 10 Bit, eventuell durch zeitliches 'dithern' der 8 Bit Hardware-PWM (PWM-Wert 8 -> Ausgabe 2, 2, 2, 2 ; PWM-Wert 9 -> Ausgabe 3, 2, 2, 2 ; PWM-Wert 10 -> Ausgabe 3, 2, 3, 2 ; ...). Wenn man nun mehr als 8 Bit PWM hat, muß man bei RGB auch mehr als 3 Byte (1 Byte pro Farbe) übertragen. Bei HSV braucht nur der Helligkeitswert die hohe Auflösung zu haben, und da kann man auch auf 8 Bit reduzieren, wenn man die Dimmkurve verwendet, man kann also mit 3 übertragenen Bytes den Effekt einer PWM mit 10 Bit oder mehr erreichen, die PWM-Ausgabe muß dann natürlich die höhere Bitbreite können. Wenn man sich auf 8 Bit PWM-Ausgabe beschränkt bringt das natürlich nichts. Das mit den UART-Ringen ist wohl auch nicht richtig angekommen. Ich halte es für sinnvoller z.B. vom Master aus 2 UART-Ringe, die je 100 Pixel versorgen zu verlegen, als die zwei UART-Ringe über alle 200 Pixel zu legen, wo sich dann jeder Pixel um 2x UART-Ring kümmern muss, der Gesamt-Datendurchsatz ist bei beiden Varianten der gleiche, die Rechenlast auf den Pixeln aber nicht. Wenn die Leistung der IR-LED direkt an einem Portpin zu niedrig ist, könnte man, anstelle einer Verstärker-/Treiber- Schaltung, auch darüber nachdenken, mehrere IR-LEDs in Reihe zu schalten, deren Flußspannung liegt nur bei ca. 1,2V, da gehen, bei 5V Versorgung, 3 Stück in Reihe -> 3x so viel IR. Die 1A, die bei IR-LEDs angegeben werden gelten aber nur für kurze Pulse, Tastgrad z.B 1:100, bei 50% An gehen so 30-35mA. Mit freundlichen Grüßen - Martin
aber wenn anschließend eh auf eine angenommene 8bit PWM umgerechnet werden muss, bringt das doch alles trotzdem nichts? Von daher würde ich eh eine 10bit PWM vorschlagen und gut :-) dort können wir auch gerne über den HSV Farbraum gehen
Hallo Tim,
vielen Dank für die Zusammenfassung,
Ja sehr viel Text, hatte ihn mir gestern durchgelesen, aber doch nicht
alles hängengeblieben, war wahrscheinlich doch zu spät :-)
Ich freue mich schon über deine Zusammenfassung.
eine Frage habe ich noch, auch auf die Gefahr, dass diese schon erstellt
und beantwortet wurde.
- Warum ist I2C ausgeschlossen? der Leitungsaufwand ist doch auch gering
und die Übertragungsgeschwindigkeit doch recht passable, des weiteren
muss ein Attiny die Informationen nicht erst weiterleiten.
(Ausfallsicherheit)
Des weiteren, noch eine Anmerkung zur Verkabelung.
Warum muss den die Trennwand zwischen die einzelnen Platinen und kann
nicht auf das gesamt Platinen-Netzwerk aufgesetzt werden.
So habe ich die Verkabelung gespart und auch die Kosten werden
reduziert, denn die Steckverbinder kann ich auf die Unterseite der
Platinen bringen und dann die Trennwende oberhalb aufsetzen
Trenn-
Wand
----
LED ^ ^ || ^ ^ LED
Platine 1 xxxxxxxxxxxx xxxxxxxxxxxx Platine 2
Buchse |||| ----| Stiftleiste
Viele Grüße
Tim R. schrieb: > Karol Babioch schrieb: >> "Halten" ist relativ. Bis zum Totalausfall sind es sicherlich etliche >> Stunden, aber eine Alterung (LED wird bei gleich Strom schwächer) tritt >> ggf. deutlich früher auf. > ich finde den Ansatz trotzdem etwas quatsch. Was ist denn mit der > Leuchtdiode die die Farbe hergibt? Die wäre mir viel wichtiger, weil > dort das Auge drauf schaut. Wenn dann müssten schon beide im > Altererungsprozess berücksichtigt werden.. und das ist einfach viel zu > aufwändig bin ich der Meinung, um ein paar Stunden Leuchtkraft zu > gewinnen. Notfalls kann man ja alle 5 Jahre oder neue LEDs einlöten, > sollte ja auch nicht so das Problem sein oder ?! :-D Für die sichtbaren LEDs ist das (theoretisch) einfach. Die werden mit hoher Auflösung PWM-gedimmt, und wenn da ein einzelnes Pixel aus der Reihe tanzt, dann kann man das kompensieren, indem entweder der Master entsprechend korrigierte RGB-Werte sendet oder die Pixel individuell angepasste Gammakurven (die nichtlineare Umrechnung 8bit --> PWM-Auflösung) konfiguriert bekommen. Das ist also ein Software-Problem und damit später per Update lösbar. Die IR-LED kann aber nicht so einfach PWM-gedimmt werden. Wenn es je nötig sein sollte, die Helligkeit der IR-LED zu steuern, dann muß das jetzt schon in die Hardware eingebaut werden; bei Hardware heißt das Update "Nachrüsten" und macht richtig viel Arbeit. ;)
Martin Schlüter schrieb: > Das mit den UART-Ringen ist wohl auch nicht richtig angekommen. Ich > halte es für sinnvoller z.B. vom Master aus 2 UART-Ringe, die je 100 > Pixel versorgen zu verlegen, als die zwei UART-Ringe über alle 200 Pixel > zu legen, wo sich dann jeder Pixel um 2x UART-Ring kümmern muss, der > Gesamt-Datendurchsatz ist bei beiden Varianten der gleiche, die > Rechenlast auf den Pixeln aber nicht. Müsste dann der Master nicht entsprechend 2x 2xUART beherschen? Für jeden Ring 2xUART
M. G. schrieb: > eine Frage habe ich noch, auch auf die Gefahr, dass diese schon erstellt > und beantwortet wurde. > - Warum ist I2C ausgeschlossen? der Leitungsaufwand ist doch auch gering > und die Übertragungsgeschwindigkeit doch recht passable, des weiteren > muss ein Attiny die Informationen nicht erst weiterleiten. > (Ausfallsicherheit) wenn ich das richtig im Kopf behalten habe, ist das Problem, die Länge des Busses. Entweder an alle Pixel oder eben mehrere Reihen (mehrere I2Cs). Dort wird jeder einzeln nacheinander adressiert bzw. mit Daten versehen. Beim Chain wird der Strom rausgehauen und jeder nimmt sich einfach sein Paket (Ring). Der I2C ist auf dieser Länge denke ich einfach zu lahm und zu dem muss die lange Leitung an jeden Pixel geführt werden, was aufwändig klingt. Oder?! Könnte durch die Temperaturen grad den mega mist hier erzählen hehe.. > > Trenn- > Wand > ---- > LED ^ ^ || ^ ^ LED > Platine 1 xxxxxxxxxxxx xxxxxxxxxxxx Platine 2 > Buchse |||| ----| Stiftleiste > Interessant. Jedoch dürften die Trennwände dann NUR am Rand aufliegen oder? Das würde Stabilitätsprobleme mit sich bringen. Ein Gewicht in die Mitte und alles biegt sich denke ich Nosnibor schrieb: > Für die sichtbaren LEDs ist das (theoretisch) einfach. Die werden mit > hoher Auflösung PWM-gedimmt, und wenn da ein einzelnes Pixel aus der > Reihe tanzt, dann kann man das kompensieren, indem entweder der Master > entsprechend korrigierte RGB-Werte sendet oder die Pixel individuell > angepasste Gammakurven (die nichtlineare Umrechnung 8bit --> > PWM-Auflösung) konfiguriert bekommen. Das ist also ein Software-Problem > und damit später per Update lösbar. wie willst du denn dann die Abschwächung der LED mitbekommen? Das muss ja dann schon irgendwie hardwaretechnisch festgestellt und dann über den Bus an den Master vermittelt werden. Das klingt für mich genau so unnütz und aufwändig, wie es bei der IR-LED der Fall ist. Aber wenn ihr einfache/schnelle Ansätze habt, ich lasse mich gerne überzeugen
Tim R. schrieb: > M. G. schrieb: >> eine Frage habe ich noch, auch auf die Gefahr, dass diese schon erstellt >> und beantwortet wurde. >> - Warum ist I2C ausgeschlossen? der Leitungsaufwand ist doch auch gering >> und die Übertragungsgeschwindigkeit doch recht passable, des weiteren >> muss ein Attiny die Informationen nicht erst weiterleiten. >> (Ausfallsicherheit) > wenn ich das richtig im Kopf behalten habe, ist das Problem, die Länge > des Busses. Entweder an alle Pixel oder eben mehrere Reihen (mehrere > I2Cs). Dort wird jeder einzeln nacheinander adressiert bzw. mit Daten > versehen. Beim Chain wird der Strom rausgehauen und jeder nimmt sich > einfach sein Paket (Ring). Der I2C ist auf dieser Länge denke ich > einfach zu lahm und zu dem muss die lange Leitung an jeden Pixel geführt > werden, was aufwändig klingt. Oder?! Könnte durch die Temperaturen grad > den mega mist hier erzählen hehe.. >> >> Trenn- >> Wand >> ---- >> LED ^ ^ || ^ ^ LED >> Platine 1 xxxxxxxxxxxx xxxxxxxxxxxx Platine 2 >> Buchse |||| ----| Stiftleiste >> > Interessant. Jedoch dürften die Trennwände dann NUR am Rand aufliegen > oder? Das würde Stabilitätsprobleme mit sich bringen. Ein Gewicht in die > Mitte und alles biegt sich denke ich > Ich habe mit diesem Prinzip eine WordClock gebaut. Zwar war dies eine durchgehende Platine, aber das Holzraster lag ober einfach drauf, ohne jegliche Befestigung. die Glasplatte war mit dem 4 schrauben befestigt, keine Probleme bisher. Mann sollte dies vielleicht nicht ganz aus den Augen lassen, denn ich finde Kabel ehrlich gesagt nicht schön und unpraktisch, Hängen nur runter,usw Durchbiegen könnte man mit einem geeigneten Untergestell realisieren. Dieses Untergestell ist ja auch notwendig, wenn man einzelne Platinen hat, welche mit einzeladern verbunden sind. Noch eine Anmerkung zum I2C, Die Länge dürfte kein Problem sein, denn es gab schon Projekte in der ein ganzer Hausbus mit I2C realisiert wurde. Was passiert denn, wenn wir den UART benutzen und ein Teilnehmer ausfällt? Ein Austausch ist ja nicht innerhalb von 2 Minuten gemacht, (fehlende Bauteile usw.) Jedoch ist der Fehler für alle nachfolgenden Teilnehmer sichtbar, da diese keine Signale mehr bekommen, Dies macht dann den ganzen Tisch unbrauchbar, wenn die ienzelnen Module sich nicht im Standalone Betrieb befinden. Animationen gehen dann nicht mehr
Tim R. schrieb: > Martin Schlüter schrieb: >> Das mit den UART-Ringen ist wohl auch nicht richtig angekommen. Ich >> halte es für sinnvoller z.B. vom Master aus 2 UART-Ringe, die je 100 >> Pixel versorgen zu verlegen, als die zwei UART-Ringe über alle 200 Pixel >> zu legen, wo sich dann jeder Pixel um 2x UART-Ring kümmern muss, der >> Gesamt-Datendurchsatz ist bei beiden Varianten der gleiche, die >> Rechenlast auf den Pixeln aber nicht. > Müsste dann der Master nicht entsprechend 2x 2xUART beherschen? Für > jeden Ring 2xUART Wenn dies der fall wäre, dürfte dies auch gehen. es gibt µC welche 4 UARTs haben. z.B. ATMega 2560
Das mit den UART-Ringen wurde immer noch nicht verstanden, aber Nosnibor hat das gleiche geschrieben, es gibt mehrere UART-Ringe, so viele, wie der Master UARTs hat, aber die Pixelplatinen sind immer nur Teilnehmer an einem UART-Ring, so multipliziert sich der Gesamt-Datendursatz mit der Zahl der UART-Ringe, aber jede einzelne Pixelplatine muß nur einen UART-Ring verarbeiten/verwalten. Noch eine Anmerkung, habe es schon mal geschrieben: Für UART ist ein Quarz/Keramikresonator zwingend erforderlich, der interne RC-Oszillator ist zu ungenau, UART hat da, da nur 1x Pro Byte synchronisiert wird, zu wenig Spielraum. Man könnte naturlich auch SPI-Schnittstellen zu einem Ring verknüpfen, braucht dann aber zwei SPI pro Pixel (Ich habe jetzt nicht nachgeschaut, ob das mit den Tinys geht, bei den ATmegas können die UARTs auch SPI-Master). Da wird der Takt ja mitübertragen, und wenn der nicht höher ist, als 1/4 Taktfrequenz des Empfängers geht das auch wenn der Takt des Empängers stark abweicht. Also stellt man beim Master nicht schneller als 1/8 Clk ein. Elektrisch spricht übrigens einiges für den Ring, gegenuber einem Bus: Die Leitungen bleiben kurz, und der Potentialunterschied muß nur zwischen den Nachbarn gering genug sein, und nicht über den ganzen Aufbau. Nicht umsonst verwendet man bei Bussen oft differenzielle Treiber und Empfänger, die mit Potentialunterschieden von mehreren Volt umgehen können. Mit freundlichen Grüßen - Martin
M. G. schrieb: > Ich habe mit diesem Prinzip eine WordClock gebaut. Zwar war dies eine > durchgehende Platine, aber das Holzraster lag ober einfach drauf, ohne > jegliche Befestigung. die Glasplatte war mit dem 4 schrauben befestigt, > keine Probleme bisher. > Mann sollte dies vielleicht nicht ganz aus den Augen lassen, denn ich > finde Kabel ehrlich gesagt nicht schön und unpraktisch, Hängen nur > runter,usw das projekt sagt mir nun leider nichts, aber hast du denn auch gewichte bei der platte? rein als deko geht das, sobald dort aber was aufliegen soll etc wird es kritisch denke ich... > > Durchbiegen könnte man mit einem geeigneten Untergestell realisieren. > Dieses Untergestell ist ja auch notwendig, wenn man einzelne Platinen > hat, welche mit einzeladern verbunden sind. ja gut dann hast du wieder einen sonderbau... deswegen war angedacht einfach alle pixel gleich und einfach zu halten > > Noch eine Anmerkung zum I2C, Die Länge dürfte kein Problem sein, denn es > gab schon Projekte in der ein ganzer Hausbus mit I2C realisiert wurde. dort hast du dann dementsprechend auch kleine Übertragungsraten ;) > > Was passiert denn, wenn wir den UART benutzen und ein Teilnehmer > ausfällt? > Ein Austausch ist ja nicht innerhalb von 2 Minuten gemacht, (fehlende > Bauteile usw.) Ja gut, aber wann sollte einer ausfallen? Und wenn einer ausfällt muss eh alles raus. Da nimmt man sich dann ein paar Minuten Zeit. > Jedoch ist der Fehler für alle nachfolgenden Teilnehmer sichtbar, da > diese keine Signale mehr bekommen, > Dies macht dann den ganzen Tisch unbrauchbar, wenn die ienzelnen Module > sich nicht im Standalone Betrieb befinden. Animationen gehen dann nicht > mehr Wenn ein Pixel nicht geht, will ich zumindest meinen Tisch eh nicht betreiben, du etwa?! Ist ja wie ein Fernseher mit Toten Pixel. Krieg ich einen Würgreiz :-D
Das mehrere RInge verwendet werden können, wurde auch noch gar nicht ausgeschlossen. Ich würde es wahrscheinlich sogar bevorzugen. Einfach den Tisch in vier gleich große Teile zu je 1x UART teilen und man hat die vierfache Rate Das dann ein Quartz benutzt werden musst ist klar denke ich, aber sollte doch kein Problem darstellen? Vergesst bitte nicht die Pixelplatine ist klein, sprich ein 20er Piner wird es maximal wenn es gerade noch richtig im Kopf habe... da sind die Attinys optimal!
Karol Babioch schrieb: > Konrad S. schrieb: >> Die Auswertung sollte im 2x2- oder 3x3-Raster erfolgen, damit die >> benachbarten Zellen nicht stören. > > Was meinst du damit bzw. wie willst du die nötige Synchronisation > erreichen? Nosnibor hat es im Wesentlichen schon gesagt. Das 3x3-Raster hatte ich hier Beitrag "Re: LED Tisch mit Berührungs-/Gegenstandserkennung" kurz beschrieben. Zum Thema Synchronisation: Ich bin UART-Bus-Fan, da gibt es die Synchronisation gratis. Tim R. schrieb: > Theoretisch wären 1Mbaud bei 16MHz möglich Woher sollen die 16MHz kommen? Quarz? -> Teuer! Externer Takt? -> Bei den Leitungslängen wird das nix! Temperaturkompensierter interner 8MHz-RC-Oszillator sollte ausreichend genau sein, das Datenblatt sagt ±1% ist machbar. Martin Schlüter schrieb: > Das mit dem HSV Farbraum Zur Einstellung einer RGB-LED sind 3 Bytes locker ausreichend. Das bedeutet aber nicht, dass mit einer 8-Bit-PWM gearbeitet werden muss. Der Weg führt über eine Lookup-Tabelle mit 256 16-Bit-Einträgen. Damit lassen sich sehr sanfte Übergänge realisieren. An dieser Stelle wieder mal die Lese-Empfehlung für http://www.zabex.de/frames/sofabeleuchtung.html Martin Schlüter schrieb: > Für UART ist ein > Quarz/Keramikresonator zwingend erforderlich, der interne RC-Oszillator > ist zu ungenau Nein. Man muss ja bei 8MHz Takt nicht unbedingt 123456 Baud fahren wollen, 125000 Baud tun's auch.
Konrad S. schrieb: > Nosnibor hat es im Wesentlichen schon gesagt. Das 3x3-Raster hatte ich > hier Beitrag "Re: LED Tisch mit Berührungs-/Gegenstandserkennung" kurz > beschrieben. Zum Thema Synchronisation: Ich bin UART-Bus-Fan, da gibt es > die Synchronisation gratis. Aber wozu das ganze? Ich versteh ehrlich gesagt den Sinn nicht ganz, mal davon abgesehen das das ganze eine feste Größe voraussetzt wenn ihr z.B. 3x3 wählt. Wo ist das Problem am einzelnen Pixel? > > Tim R. schrieb: >> Theoretisch wären 1Mbaud bei 16MHz möglich > > Woher sollen die 16MHz kommen? > Quarz? -> Teuer! Die gibt es doch schon einzeln für 20cent oder bin ich gerade falsch?! In Masse dann natürlich günstiger > Externer Takt? -> Bei den Leitungslängen wird das nix! Will glaube ich auch keiner > Zur Einstellung einer RGB-LED sind 3 Bytes locker ausreichend. Das > bedeutet aber nicht, dass mit einer 8-Bit-PWM gearbeitet werden muss. > Der Weg führt über eine Lookup-Tabelle mit 256 16-Bit-Einträgen. Damit > lassen sich sehr sanfte Übergänge realisieren. An dieser Stelle wieder > mal die Lese-Empfehlung für > http://www.zabex.de/frames/sofabeleuchtung.html Daran hatte ich auch schon gedacht, aber auch wenn es 16Bit PWM ist, es sind immernoch 255er Auflösungen oder nicht? Ob nun 16bit auflösung oder 8 macht dann auch keinen Unterschied da die ganzen Zwischenstufen nicht angesteuert werden, weil (wie du selbst schreibst) 256 Einträge
:
Bearbeitet durch User
Bei dem Quarz geht es nicht darum, eine spezielle 'krumme' Baudrate zu treffen, das ist für den Ring völlig unwichtig, die Baudraten müssen nur gleich sein, sondern es geht um die Ungenaugkeit des RC-Oszillators, da fehlt in dem letzten Post eine 0, im Datenblatt sehe ich da +- 10%, und das noch bei fester Spannung und fester Temperatur, wariieren diese Größen ist man da schnell bei +- 20%. Für UART sind so ca. +- 3% erträglich, sonst kann man sich auf der Empfangsseite über viel Datenmüll freuen. Eine Möglichkeit wäre natürlich, auf einer gesonderten Leitung einen niedrigen Referenztakt, z.B. 100 Hz zu übertragen, und damit den internen Oszillator laufend nachzukalibrieren. Dann ist der Quarz entbehrlich. Dieser Takt könnte auch zur Synchronisation der Pixel verwendet werden. Mit freundlichen Grüßen - Martin
Tim R. schrieb: > Daran hatte ich auch schon gedacht, aber auch wenn es 16Bit PWM ist, es > sind immernoch 255er Auflösungen oder nicht? Ob nun 16bit auflösung oder > 8 macht dann auch keinen Unterschied da die ganzen Zwischenstufen nicht > angesteuert werden, weil (wie du selbst schreibst) 256 Einträge Das hast du, glaube ich, noch nicht ganz verinnerlicht. Die 256 Einträge sind die nötigen 16-Bit-PWM-Werte in gleichmäßig verteilten - also linearen - Helligkeitsabstufungen unter Berücksichtigung des Gammawertes. Die Helligkeitsstufen sind linear, nicht die PWM-Werte.
Tim R. schrieb: > ich finde den Ansatz trotzdem etwas quatsch. Was ist denn mit der > Leuchtdiode die die Farbe hergibt? Ich halte das nach wie vor für (zwingend) notwendig bzw. sinnvoll, weil man flexibler in Bezug auf verschiedene Glasarten (Dicke und Glas vs. Plexi). Die Kompensation des Alters bekommt man dadurch auch "geschenkt". Die RGB LEDs hingegen werden ja per PWM angesteuert, insofern wäre (theoretisch) eine Kalibrierung denkbar. In der Praxis spielt das aber eine untergeordnete Rolle. Tim R. schrieb: > Notfalls kann man ja alle 5 Jahre oder neue LEDs einlöten, > sollte ja auch nicht so das Problem sein oder ?! :-D Viel Spaß bei 100/200 Pixeln. Einlöten ist eine Sache, aber davor müsste man die alten LEDs ja erst auslöten. Tim R. schrieb: > Wir sind eher an die 8bit PWM > Hardwaretechnisch gebunden. Nein. Der ATtiny841 hat zwei 16 Bit Counter mit dazugehörigen PWM Kanälen! Nosnibor schrieb: > Damit kann man > dann auch die IR-Messung synchronisieren. Die Pixel werden in mehrere > Gruppen eingeteilt, z.B. schachbrettartig, Halte ich für unnötig kompliziert, weil die Praxis bei meinem Versuchsaufbau gezeigt hat, dass es auch ohne gut funktioniert. Nosnibor schrieb: > und wenn sie das können, > können sie genausogut je eine Gammakurve für R, G und B rechnen, und gut > is. War bisher ja auch implizit so vorgesehen. Eben, das war auch mein Argument ;). Martin Schlüter schrieb: > Wenn man sich auf 8 Bit > PWM-Ausgabe beschränkt bringt das natürlich nichts. Geht mal von einer (bis zu) 16 Bit PWM aus ;). Damit ersparen wir uns nämlich eine Menge Probleme. Martin Schlüter schrieb: > Das mit den UART-Ringen ist wohl auch nicht richtig angekommen. Ich > halte es für sinnvoller z.B. vom Master aus 2 UART-Ringe, die je 100 > Pixel versorgen zu verlegen, als die zwei UART-Ringe über alle 200 Pixel > zu legen, Ja, die genaue Topologie kann man sicherlich optimieren. Hier kommt es aber auf die konkret verwendete Anzahl an Pixeln an. Es wäre wichtig, dass unsere Steckverbinderlösung flexibel genug ist, sodass man die Pixel "beliebig" zusammen stöpseln kann. Martin Schlüter schrieb: > Wenn die Leistung der IR-LED direkt an einem Portpin zu niedrig ist, > könnte man, anstelle einer Verstärker-/Treiber- Schaltung, auch darüber > nachdenken, mehrere IR-LEDs in Reihe zu schalten, Bringst nur nix, weil die Pixel ja unabhängig voneinander funktionieren sollen und nur eine IR LED pro Pixel vorgesehen sit. M. G. schrieb: > - Warum ist I2C ausgeschlossen? Ausgeschlossen ist noch gar nichts. Halte I2C aber für unbrauchbar, weil wir ggf. zuviele Teilnehmer für die typische 7 Bit Adressierung hätten, weil die gesamte Leitungskapazität ggf. zu hoch (für brauchbare Taktraten) ist, und weil die ATtiny's AFAIK nur für den Fast Mode (400 kHz) spezifiziert sind. Alles was darüber hinaus geht ist "mutig". M. G. schrieb: > Was passiert denn, wenn wir den UART benutzen und ein Teilnehmer > ausfällt? > Ein Austausch ist ja nicht innerhalb von 2 Minuten gemacht, (fehlende > Bauteile usw.) > Jedoch ist der Fehler für alle nachfolgenden Teilnehmer sichtbar, da > diese keine Signale mehr bekommen, Ich weiß nicht, ob wir das auch noch beachten sollen, weil das Ziel hier robuster zu sein sicherlich mit Kosten einhergehen wird. Ich persönlich könnte dann für ein paar Tage auch mit einem "kaputten" Tisch leben. Außerdem macht es ja durchaus Sinn ein paar Pixel mehr zu bestellen, um entsprechenden Ersatz zu haben. Martin Schlüter schrieb: > Noch eine Anmerkung, habe es schon mal geschrieben: Für UART ist ein > Quarz/Keramikresonator zwingend erforderlich, der interne RC-Oszillator > ist zu ungenau, Ich denke auch, dass einen Quarz einsetzen sollten. Der kostet zwar ein paar Cent, aber ohne macht UART keinen Spaß. Konrad S. schrieb: > Temperaturkompensierter interner 8MHz-RC-Oszillator sollte ausreichend > genau sein, das Datenblatt sagt ±1% ist machbar. Meiner Erfahrung nach ist das aber nicht so einfach und erfordert eine Kalibrierung wie AVR053 beschrieben. Macht bei den vielen Pixeln sicherlich auch nur bedingt Spaß. Tim R. schrieb: > Die gibt es doch schon einzeln für 20cent oder bin ich gerade falsch?! Ja, wobei 20 Cent sich beim aktuellen Design schon bemerkbar machen. Würde trotzdem ganz stark dafür plädieren. Beim Wordclock Projekt scheitert die Umsetzung einer Erweiterung nämlich gerade daran. Pins haben wir beim ATtiny841 ja genug ;). Martin Schlüter schrieb: > Eine Möglichkeit wäre natürlich, auf einer gesonderten > Leitung einen niedrigen Referenztakt, z.B. 100 Hz zu übertragen, und > damit den internen Oszillator laufend nachzukalibrieren. Erscheint mir unnötig kompliziert (Software- und Verkabelungstechnisch). Dann, wie oben schon vorgeschlagen, jedem Modul einen Quarz spendieren. Konrad S. schrieb: > Die 256 Einträge > sind die nötigen 16-Bit-PWM-Werte in gleichmäßig verteilten - also > linearen - Helligkeitsabstufungen unter Berücksichtigung des > Gammawertes. Ja, bei einer 16 Bit (Hardware) PWM sehe ich da absolut kein Problem. Damit würden wir uns im Prinzip auch die ganze Farbraum-Rechnerei ersparen. Insofern +1 von mir ;). Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Martin Schlüter schrieb: > fehlt in dem letzten Post eine 0, im Datenblatt sehe ich da +- 10%, ??? Wir sprechen schon noch vom ATtiny841, hoffe ich? Kapitel "25.1.4.1 Accuracy of Calibrated Internal Oscillator" sagt Factory Calibration ±2% User Calibration ±1% Martin Schlüter schrieb: > bei fester Spannung und fester Temperatur Die Spannung sollte konstant sein. Die Temperatur ist bekannt, da der ATTiny841 einen Temperatursensor hat und somit der Oszillator nachgeführt werden kann.
Konrad S. schrieb: > Die Temperatur ist bekannt, da der > ATTiny841 einen Temperatursensor hat und somit der Oszillator > nachgeführt werden kann. Wobei die Genauigkeit des Sensors auch nicht besonders berauschend ist und man dann noch wissen muss wie aktuelle Temperatur (bzw. eine Änderung) den Takt beeinflusst. Das lässt sich vermutlich alles aus den Diagrammen im Datenblatt extrahieren, macht das ganze Vorhaben aber nur unnötig kompliziert. Quarz und all das ist unnötig ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: >> Temperaturkompensierter interner 8MHz-RC-Oszillator sollte ausreichend >> genau sein, das Datenblatt sagt ±1% ist machbar. > > Meiner Erfahrung nach ist das aber nicht so einfach und erfordert eine > Kalibrierung wie AVR053 beschrieben. Macht bei den vielen Pixeln > sicherlich auch nur bedingt Spaß. Der UART-Bus liefert nebenbei ein "Zeitnormal". Es spielt keine Rolle, ob ein oder einhundert Pixel. Jeder Pixel-µC synchronisiert seinen Oszillator, dann langweilt er sich eben ein ganz kleines bisschen weniger.
Karol Babioch schrieb: > Wobei die Genauigkeit des Sensors auch nicht besonders berauschend ist Die Genauigkeit spielt dabei keine Rolle, nur die Reproduzierbarkeit.
Die Frage ob wir einen Quarz brauchen oder nicht sollte vielleicht auch einen Einfluss auf die Wahl des µC haben. Es gibt µC die auch ohne Softwarekalibrierung ausreichend genaue RC Oscillatoren für UART haben. Ich hab auf die schnelle z.B. diesen hier gefunden: LPC1111FDH20/002,5 zu 0.42$ @ 2000Stück und der hat "12 MHz 1 % accuracy is guaranteed for 2.7 V to 3.6 V and Tamb=40°C to +85°C" Der Controller wäre preislich jedenfalls attraktiv. Wenn beim Tiny noch Quarz dazu käme würde ich auf jeden Fall den LPC bevorzugen.
Karol Babioch schrieb: > Tim R. schrieb: >> ich finde den Ansatz trotzdem etwas quatsch. Was ist denn mit der >> Leuchtdiode die die Farbe hergibt? > > Ich halte das nach wie vor für (zwingend) notwendig bzw. sinnvoll, weil > man flexibler in Bezug auf verschiedene Glasarten (Dicke und Glas vs. > Plexi). Die Kompensation des Alters bekommt man dadurch auch > "geschenkt". Die RGB LEDs hingegen werden ja per PWM angesteuert, > insofern wäre (theoretisch) eine Kalibrierung denkbar. In der Praxis > spielt das aber eine untergeordnete Rolle. Dann lieferten einen brauchbaren Ansatz. Bisher war da nur mit einer Menge extra Komponenten etwas machbar :-)
Wegen der Helligkeitssteuerung der IR LED sollten wir vielleicht nochmal ganz grundsätzlich überlegen, ob das überhaupt nötig ist. Was kann denn schlimmstenfalls passieren, wenn die Helligkeit falsch ist? Da gibt es ja zwei Möglichkeiten für eine falsche Helligkeit: zu hell oder zu dunkel. - zu dunkel: das gibt dann zu wenig Kontrast im empfangenen Signal bei eingeschalteter LED. Das empfangene Licht setzt sich zusammen aus 1. Umgebungshelligkeit (ggf. etwas verringert durch Gegenstand/Hand auf dem Pixel) 2. reflektiertem Licht der LED (falls eingeschaltet) 3. noch mehr reflektiertem Licht der LED, falls eingeschaltet und Hand/Gegenstand vor dem Pixel 4. Rauschen Nr. 3 ist das Nutzsignal. Nr. 1 rechnen wir durch eine Vergleichsmessung bei ausgeschalteter LED raus (in jedem Meßzyklus einmal) Nr. 2 rechnen wir durch eine Vergleichsmessung bei leerem Tisch raus (einmal beim Einschalten oder noch seltener) Nr. 4 können wir nicht so einfach rausrechnen; das Nutzsignal muß also größer als das Rauschen sein. Wenn die LED zu dunkel ist, wird das Nutzsignal zu schwach, d.h. Berührung wird nicht mehr erkannt, oder eben nicht mehr bei so viel Abstand wie geplant, oder nur noch bei besonders hellem Material. Außerdem wird Komponente 2 beeinflußt; wenn die LED ihre Helligkeit ändert, muß man den Tisch abräumen und neu eichen. Zu dunkel darf also nicht passieren. - zu hell: prima, das Signal/Rauschverhältnis wird besser. Wenn einen die hohe Reichweite stört, kann man das Signal ja immernoch kleinrechnen. Das einzige Problem, das ich sehe, wäre Überlauf/Übersteuerung des ADC. Fazit: wenn wir die IR-LED so auslegen, daß bei maximalem Signal (helle Umgebung, weißes Papier liegt auf dem Tisch, stark reflektierendes Glas) der ADC seinen Maximalwert liefert, haben wir hoffentlich eine Weile Ruhe. Die LED wird im Laufe der Zeit schwächer werden. Die Frage ist, wieviel schwächer darf sie werden, ohne die Erkennung (bei gelegentlichem nach-Eichen) lahmzulegen? Wird diese Verschlechterung innerhalb der vorgesehenen Lebensdauer des Gesamtsystems eintreten? Wenn wir für die letzte Frage auf "Nein" kommen, könne wir uns das LED-Stromverstellen sparen. Dann reicht ein Transistor + Vorwiderstand. Naja, über Temperaturkompensation könnte man mal nachdenken. Und gegen Exemplarstreuungen hilft vielleicht ein stromstabilisierender Emitterwiderstand. Und vielleicht (wie von Martin Schlüter schon vorgeschlagen) zwei LEDs in Reihe; die geben das gleiche Licht bei halbem Strom, nutzen sich dann aber nicht so schnell ab. Unsoweiterundsofort, einfach nur 'ne LED leuchten zu lassen ist kompliziert genug, wenn man's genau nimmt. Die Sache mit den unterschiedlichen Glassorten gibt mir schon zu denken; möglicherweise ist da wirklich ein angepaßte IR-LED-Stärke nötig, weil die Dynamik des Analogeingangs nicht reicht. Das wäre etwas, was man spätestens in der Phase mit den zehn Probepixeln testen muß. Wenn es sich als nötig erweist und niemand Lust auf analoges Schaltungsdesign hat, kann man immernoch mehrere LEDs einsetzen, jede davon so primitiv wie möglich angesteuert an einem eigenen Portpin, aber mit unterschiedlicher Leuchtkraft. Die Software entscheidet dann, wieviele und welche sie einschaltet. Die Diskussion zum Protokoll sollten wir vielleicht in den anderen Thread (Beitrag "schwierigkeiten passenden Bus zu finden") verlagern. UART ohne Quarz ist eine interessante Herausforderung, sollte aber zu schaffen sein (notfalls hat man eben weniger nutzbare Bits pro Byte).
beaglebone black rev. C verfügbar, für alle die evtl. zuschlagen wollen :-) http://www.exp-tech.de/Mainboards/BeagleBone-Black.html
Hallo, nachdem ich hier das Thema verfolge, ist mir noch nicht ganz klar, auf was in der Planungsphase Wert gelegt wird. zum einen wird über den Bus ausführlich diskutiert, dann wieder über die IR Ansteuerung, dann RGB oder RGBW, und dann wieder ein anderes Thema. Kreuz und quer ! Ich denke es soll erst einmal ein Anforderungsprofil angelegt werden. Zum einen steht da die Hardware: - LED: RGB oder RGBW - µC: Anzahl PWM-Ausgänge (8bit, 16bit, 32bit)? - µC: Kommunikationsarten? Anzahl der Ports für Kommunikation - µC: Art der Programmierung (SPI, JTAG,...) - µC: Anzahl weitere benötigter Pins inkl. Funktionen - IR: IR Sender + Empfänger (Art, Ansteuerung, Typ) - weitere Eigenschaften der Platinen und weitere Funktionen (z.B. Taster für manuelles Testprogramm der einzelnen Farben usw. Dann steht die Software: die Umsetzung kann nur auf der verwendeten Hardware basieren. Hat die Hardware nur z.B. nur - 8bit Timer, brauche ich mir über eine höhere PWM keine Gedanken machen, - oder hat die Hardware kein ADC, kann ich keine analogen Messwerte einlesen, (=> nur als Beispiel gedacht) Vielleicht sollte man diese Anforderungen klarer definieren und irgendwo niederschreiben, damit man sich an diesen Orientieren kann. Kategorien sind IR, LED und µC
M. G. schrieb: > Zum einen steht da die Hardware: > - LED: RGB oder RGBW > - µC: Anzahl PWM-Ausgänge (8bit, 16bit, 32bit)? 3x PWM RGB (evtl. HSV Farbmodell), 1x PWM IR-LEG (wenn nicht anders angesteuert wird) > - µC: Kommunikationsarten? Anzahl der Ports für Kommunikation bei 2xUART 4 Pins, für Erweiterung evtl. 2 Pins für CLK? > - µC: Art der Programmierung (SPI, JTAG,...) ISP > - µC: Anzahl weitere benötigter Pins inkl. Funktionen > - IR: IR Sender + Empfänger (Art, Ansteuerung, Typ) steht oben > - weitere Eigenschaften der Platinen und weitere Funktionen (z.B. Taster > für manuelles Testprogramm der einzelnen Farben usw. wenn überhaupt, dann sollten eigtl nur bei den Prototypen welche vorhanden sein > > Dann steht die Software: > die Umsetzung kann nur auf der verwendeten Hardware basieren. > Hat die Hardware nur z.B. nur > - 8bit Timer, brauche ich mir über eine höhere PWM keine Gedanken > machen, Attiny841 -> 16bit Timer > - oder hat die Hardware kein ADC, kann ich keine analogen Messwerte > einlesen, (=> nur als Beispiel gedacht) bis zu 8 ADC Kanäle hat der Controller wenn ich mich nicht irre aber ich gebe dir Recht, das hatte ich auch schon mal angesprochen, leider fehlt mir etwas die Zeit momentan
:
Bearbeitet durch User
Angehängte Dateien:
-
Entwurf.PNG
42 KB
Hallo auch auf die Gefahr hin, jetzt etwas falsch zu machen, habe ich mal unserem Projekt ein erstes Gesicht gegeben. dies ist nur ein Prototyp ohne jegliche Funktion, Layout oder sonstiges. ganzes Hühnerfutter fehlt natürlich auch noch. Nur damit man ein Bild vor Augen hat, was wir hier machen wollen Die Platine hat die Abmaße 50x50mm, Auch wenn noch spezifiziert, habe ich Steckkontakte zur Verbindung der einzelnen Platinen eingefügt (Anzahl beliebig gewählt) Aus meiner Sicht kann dies auch etwas kleiner gestaltet werden. Vielleicht 40x40mm. Platz ist auf der Platine genug.
M. G. schrieb: > Hallo > > auch auf die Gefahr hin, jetzt etwas falsch zu machen, habe ich mal > unserem Projekt ein erstes Gesicht gegeben. > > dies ist nur ein Prototyp ohne jegliche Funktion, Layout oder sonstiges. > ganzes Hühnerfutter fehlt natürlich auch noch. > > Nur damit man ein Bild vor Augen hat, was wir hier machen wollen > > Die Platine hat die Abmaße 50x50mm, > Auch wenn noch spezifiziert, habe ich Steckkontakte zur Verbindung der > einzelnen Platinen eingefügt (Anzahl beliebig gewählt) > > Aus meiner Sicht kann dies auch etwas kleiner gestaltet werden. > Vielleicht 40x40mm. Platz ist auf der Platine genug. Schöner Ansatz! wir hatten uns schon auf Maße von 45x45 bis glaube 48x48 geeinigt. Denn Platz für die Trennwände sollte auch etwas bleiben und rein für Notfälle bleibt auch etwas Spielraum ;-) Die LEDs und Sensoren würde ich versuchen mittig anzuordnen. Rein aus der Optik und der Funktionalität des Infrarot. Den Attiny dann eben auf irgendeine Seite packen, das sollte eigtl egal sein Wenn Stiftleisten, dann würde ich diese oben/unten oder rechts/links insgesamt zwei Stück anbringen damit die Pixel zu Reihen verbunden werden können. Aber da einige gruppieren wollten, besteht hier scheinbar auch noch Klärungsbedarf :-)
Tim R. schrieb: > Schöner Ansatz! > wir hatten uns schon auf Maße von 45x45 bis glaube 48x48 geeinigt. Denn > Platz für die Trennwände sollte auch etwas bleiben und rein für Notfälle > bleibt auch etwas Spielraum ;-) Dies habe ich dann wohl wieder überlesen mit den Trennwänden zwischen die einzelnen Platinen, kann ich mich nicht anfreunden. Die Platinen liegen dann zwischen den Raster, wackeln rum, werden ggf. durch die Anbindung von Leitungen nach oben gedrückt. Daher würde ich diese Platinen /Pixel eher "zusammenstecken". Egal wo ich den nächsten Pixel anstecke, rechts,links,oben oder unten, jede Kombination hat die Möglichkeit den Bus weiterzuleiten (ggf. über Löt-Jumper) und die Spannungsversorgung sicherzustellen > Die LEDs und Sensoren würde ich versuchen mittig anzuordnen. Rein aus > der Optik und der Funktionalität des Infrarot. > Den Attiny dann eben auf irgendeine Seite packen, das sollte eigtl egal > sein Ja ist eine gute Idee, ist notiert :-) > Wenn Stiftleisten, dann würde ich diese oben/unten oder rechts/links > insgesamt zwei Stück anbringen damit die Pixel zu Reihen verbunden > werden können. Aber da einige gruppieren wollten, besteht hier scheinbar > auch noch Klärungsbedarf :-) Die Stiftleisten habe ich unten angesiedelt, da ich das Raster oben einfach aufsetzen kann. Es gibt natürlich auch andere Verbindungsmöglichkeiten, nur ein erster Vorschlag. Stiftleisten sind halt schön flach. Da wären wir auch schon beim nächsten Thema. Ich würde alles gern in SMD halten, Abstand zum von Platine zum Glas wäre dann sehr gering (Öffnungswinkel LED abhängig) Gibt es auch ein IR Sender und Empfänger in gut lötbaren Format (für alle Menschen machbar)
naja die Platinen werden geschraubt, darauf wurde sich fast festgelegt. Somit sind sie fest. Und zudem kann die Spannungsversorgung über die Schrauben laufen mit Hilfe von Metallstreifen oder Ähnliches auf dem Boden des Tisches. Das denke ich war schon ein sehr guter Ansatz. Rein aus Platzgründen werden wir auch wohl auch keinen DIP oder was auch immer verwenden, 45x45mm ist auch nicht gerade viel
Hallo Wenn du mir Deine Platine als 3D Datei schicken könntest, kann ich am Wochenende mal rumprobieren wie sich die Platinen am besten und einfachsten zwischen dem Raster verschrauben lassen. Ich bin auch der Meinung, dass wir die Platinen auf das Raster legen/schrauben sollten. Wenn jemand nicht aufpasst und die Platten für das Raster dicker macht, passen die Platinen möglicherweise nicht mehr in die Pixel Kästen. Aber immer noch oben drauf.
Und (SMD) Bauteile nach Möglichkeit nur auf eine Seite. Falls die Platine zum Bestücker gehen soll. Sonst wird es teurer...
Hallo, ich bin immernoch etwas skeptisch in Bezug auf das Anschrauben der Platinen auf ein Metallraster. Und das dazwischensetzen der einzelen Platinen. Wie oben schon richitg festgestellt, bekommt man die Platinen nicht mehr in das Pixelraster, wenn man die Holz/Plastik/.. stärke falsch/anderst gewählt hat. Und obendrauflegen kann man diese auch nicht, da ja auf das Raster die GlasPlatte kommt, des weiteren stimmen dann nicht mehr die Abstände und Abstrahlungswinkel. Das Bauen macht dann kein Spaß. Dies würde mit einem Steckbaren System, wie von mir oben beschrieben nicht bassieren, das die Stärke des Rasters auch doppelt so breit sein kann, die Platz zwischen den einzelnen Eletronisschen Bauteilen ist. Ich selbst könnt mir vorstellen, auch kein Raster zu bauen, um die Farbverläufe der einzelnen LEDs gut sichtbar zu bachen. Bei einem Raster sind sie abgehackt. Des wieteren trimmen wir hier alles auf Kosten, günstiger µC, nur RGB anstatt RGBW, günstige IR Sender / Empfänger. Dann wollt ihr aber die komplette Grundplatte mit Mettallstreifen auslegen, Schraubverbindungen anbringen und die Schrauben auch noch kaufen. Für mich sieht das dann von oben nicht professionell aus, wenn ich auf der Platinen noch mind. 6-7 Schrauben vorfinde (TX0,RX0,TX1,RX1,5V,GND) event. noch CLK usw. Nicht jeder will vllt milchglas benutzen! ich weis nicht was dann billiger ist, Metallstreifen, + Schrauben als im gegensatz Steckverbinder in großer Stückzahl. Des weiteren ist es möglich mit meiner Variante auch abstrakte Formen zu bauen (z.B. ein "L"-Form oder eine "8" Form) Wie sieht dies denn mit Metallstreifen aus? Hier gibt es die Gefahr von Überlappungen, Stückelung einzelner Streifen, zusammenlöten von mehreren cm Metallstreifen. (ps. Metall hat eine gute Wärmeabfuhr, da macht löten richtig spaß) Des weiteren kann ich den Tisch von jetzt auf gleich vergrößern, sondern muss mir die Metallkonstruktion anpassen. (Gehe davon aus, das auch im Experiementierstatus auch Tische von 20x20 entstehen könnten, und da jedesmal die Unterkonstruktion neu bauen, oder lieber steckbar auf den Fußboden legen?) Oder man will sich dies an die Wand hängen, und wenn man nachts aus dem Bad kommt, wird eine Reihe von LED-Platinen mit der Bewegung aufläuchten (Oh man, gerade tolle Idee im Kopf dies als Lichtleiste an die Treppe zu machen, wenn man hoch und runter geht :-) ) Und da an der Wand Matallstreifen zu verlegen??? Ich verweise auf den oben genannten Link, wo mein System auch Anwendung findet http://www.elv.de/controller.aspx?cid=726&detail=44159 Viele Grüße
Aber wenn jemand entschuldige zu doof ist die richtige Dicke der Trennwände zu bestimmen, dann ist das seine eigene Schuld. Man kann in keinem Projekt jegliche Fehlerquellen abfangen, sowas geht einfach nicht! Deswegen gehe ich davon aus, dass alle richtige Trennwände hinbekommen und die Abstände dementsprechend passen. Für Notfälle ist die Platine ja auch etwas kleiner dimensioniert. Und wie schon beschrieben, ich finde Steckverbindungen sehr gut, aber wie willst du denn Stabilität in die Sache bekommen? Was trägt den die Glasplatte? nur am Rand ein paar Millimeter lassen wo die Ränder der Glasplatte aufliegen? Zudem haben die Trennwände den scharm die PIXEL optisch zu trennen. Wenn du nun flüssige Überläufe ohne Trennwände willst, ist das auch meiner Meinung nach schon wieder ein ganz anderes Projekt bzw. ein anderer Ansatz... genau wie die Idee das alles an eine Treppe oder Wand oder ähnliches zu bringen ;-) Zumal wie sieht der Kostenfaktor beim Stecken aus? Im Endeffekt wäre fast der ganze Tisch eine reine Platine. Die Metallstreifen waren nur für die Spannungsversorgungen gedacht. Aber das Thema ist noch gar nicht durch, das waren nur mal Überlegungen. Die Datenverbindungen könnte man zb. auch über Jumperkabel lösen oder sowas... Dann würde ich lieber bevorzugen eine Kombination aus Trennwänden und durch kleine Schlitze oder Öffnungen die Datenleitungen ziehen... Das Problem ist, wie willst du die Spannungsversorgung auf alle Teilnehmer verteilen?
Anfänger schrieb: > Wenn du nun flüssige Überläufe ohne Trennwände > willst, ist das auch meiner Meinung nach schon wieder ein ganz anderes > Projekt bzw. ein anderer Ansatz... genau wie die Idee das alles an eine > Treppe oder Wand oder ähnliches zu bringen ;-) Soweit ich das verstanden hatte, sollten die Pixel schon einigermaßen flexibel einsetzbar sein, sonst bräuchte nicht jedes Pixel einen eigenen Prozessor. Der eine will vielleicht ein 5x5cm-Raster, der andere eher 10x10cm. Und der dritte hat etwas gegen rechte Winkel und nimmt ein Sechseck- oder Dreieckraster. Oder ersetzt mit den Pixeln die hinterleuchteten Drucktaster an einer Schalttafel. Das alles ist natürlich kein Hinderungsgrund, im Layout bequeme Steckverbinder vorzusehen, mit denen sich ein 5x5cm-Raster leicht zusammenstecken läßt. Wer etwas anderes will, muß dann eben Kabel löten, oder die (hoffentlich auch enthaltenen) Stromschienenschraubenlöcher nutzen.
Angehängte Dateien:
-
VCC.png
2,1 KB
Anfänger schrieb: > Und wie schon beschrieben, ich finde Steckverbindungen sehr gut, aber > wie willst du denn Stabilität in die Sache bekommen? Was trägt den die > Glasplatte? nur am Rand ein paar Millimeter lassen wo die Ränder der > Glasplatte aufliegen? Meine Glastisch wird nur von 4 Beinen gehalten, da ist genug stabilität drin, hab noch keine Glasplatte gesehen, welche ich biegen kann :-) Wenn man eine entsprechende Dicke hat, ist dies kein Problem (5-10mm sollten reichen, ggf. auch mehr) Wenn der Rand des Tisches ca. 2-3 cm breit ist, kann dort eine ordentliche absenkung für die Glasplatte eingearbeitet werden und sie sitzt ordentlich, wackelt nicht, und hat genug stabilität. > Zudem haben die Trennwände den scharm die PIXEL > optisch zu trennen. Wenn du nun flüssige Überläufe ohne Trennwände > willst, ist das auch meiner Meinung nach schon wieder ein ganz anderes > Projekt bzw. ein anderer Ansatz... genau wie die Idee das alles an eine > Treppe oder Wand oder ähnliches zu bringen ;-) Ja anderes Projekt vieleicht schon, aber dennoch selbe Platine. Warum nicht die Platine auch im Standalone Betrieb laufen lassen? Taster drücken, und sschon kann sie als Baumbelacuhtung, oder Schrankdeko dienen. dafür brauche ich kein Extra Projekt, ist nur Software, welche im spätere verlauf eh kommt, da wir jeden Pixel bestimmt eh in der ersten Stufe als Standalone laufen lasssen, bevor die Anforderung des Masters dran ist. > Zumal wie sieht der Kostenfaktor beim Stecken aus? Im Endeffekt wäre > fast der ganze Tisch eine reine Platine. Das ist richtig, jedoch brauche ich dann keine einzelnen µC sondern mache dies über einen größeren, welcher mehr PWM hat und mehrer IR auslesen kann. Wenn kleine Platinen, sollten diese auch flexibel einsetzbar sein. > Die Metallstreifen waren nur für die Spannungsversorgungen gedacht. Aber > das Thema ist noch gar nicht durch, das waren nur mal Überlegungen. Die > Datenverbindungen könnte man zb. auch über Jumperkabel lösen oder > sowas... > Dann würde ich lieber bevorzugen eine Kombination aus Trennwänden und > durch kleine Schlitze oder Öffnungen die Datenleitungen ziehen... Willst du das z.B. Flachbandkabel zuerst durch den Schlitz stecken und dann Klimpen, soll der Schlitz unten sein, und wie lang soll das Verbindungskabel sein, wenn ein Abstand der einzelnen Bixel vllt. 1 cm ist. Materialbedarf: Flachbandekabel (o.ä.) + zwei Stecker, auf der anderen Seite jeweils Stiftleisten > Das > Problem ist, wie willst du die Spannungsversorgung auf alle Teilnehmer > verteilen? Durch Stiftleisten, welche die Spannungsversorgung von der einen auf die andere Platine verteilen. Gibt ein reines Netzwerk aus +5V und GND. Die DATA Leitung wird ebenfalls über die Stiftleite geführt, und hat die möglichkeit über z.B. Lötjumper auf ander Klemmen umgeleitet zu werden. Das Prinzip ist kein Hexenwerk. Die Paltine besteht aus 4 Seiten. zwei aneinander liegende Seiten ahebn Buchseleisten und die anderen haben Stiftleiten Das Signal geht über Buchse auf den µC und über Stiftleiste wieder raus. Je nachdem wie ich den nächsten Kontroller anschließen will, wähle ich über einen Jumper ob dieser auf Stiftleiste ein gesendet werden oder auf striftleiste2. Das selbe auch auf der Buchsenleiste. Dort kann ich wählen, ob Buchse1 oder Buchse2 das Signal kommt. Dadurch, dass alle Platinen rechts und links mit der jeweilegen anchbarpatinen verbunden sind, gibt es eine Stabilität. Vorteil ist dann auch die gemeinsame Massefläse _ _ +5V _ _ +5V _ _ | | ------- | | ------- | | |> LED1 >| DATA |>LED2 >| DATA |>LEDn >| Reihe 1 |> >| ====== |> >| ====== |> >| |_ _ | ------- |_ _| ------- |_ _|| _| GND GND | | | | | D|| | Data durch Jumper +| G| +| | +| A|| |G Umgeleitet 5| N| 5| | 5| T|| |N V| D| V| | V| A|| |D | | | | | || | _ _ +5V _ _ +5V _ _ | | ------- | | ------- | || | | LED1 <| DATA |< LED2<| DATA |< LEDn | Reihe 2 | <| ====== |< <| ====== |< | |_ _ | ------- |_ _| ------- |_ _| GND GND PS: wie bekomme ich den diesen Pfeil hin ^ sodass er nach unten zeigt? Ich würde mich freien, wenn wir deine Möglichkeit mit Schrauben, sowie die meine Möglihckeit auf eine Platine bekommen würden. Bezüglich erweiterter Stabilität würde ich auch extra Bohrlöcher vorsehen, welche man die Platine auf die unterkonstruktion setzen kann. Hier eventuell als gemeinsamer GND nutzbar Um es noch etwas zu verdeutlichen habe ich die Spannungsversorgung mal skizziert. Hoffe man kann es erkennen, was damit gemeint ist Viele Grüße
Angehängte Dateien:
-
20140612_143141.jpg
550 KB
Zu den Platinen, hatten wir ja schon in einer Abstimmung festgelegt, dass wir 50x50 mm Platinen verwenden werden. Offen war nur ncoh die Verbindungen zwischen den Platinen. >Meine Glastisch wird nur von 4 Beinen gehalten, da ist genug stabilität >drin Ich hatte auch vorgesehen, dass das Raster tragend sein soll. Zwar nicht so viel wie ein Brett aber doch nennenswert. >hab noch keine Glasplatte gesehen, welche ich biegen kann :-) Bei schöner wohen oder wie das heißt hatten die mal ne biegbare Glasplatte für die Dusche xD. Standen mit drei Mann drauf und die Platte hat gut gefedert. Sonst kann man die Glasplatte ja auch auf dem äußeren Rahmen aufliegen lassen. Da gibt es etliche Möglichkeiten die Kräfte abzuführen. Das Thema sollten wir glaub ich erst mal nach hinten verschieben. Ich würde die Platinen auch mit einem "Netzwerk" für Vcc und GND versehen und die Busleitungen dann in Reihe laufen lassen. Sollte ja recht günstig sein und ist nicht sehr anspruchsvoll zusammenzustecken. Ich habe bei meiner Skizze mal Vcc, Bus und GND in einzelnen Steckern dargestellt. Man muss ja auch nicht alle Seiten mit Verbindern versehen, ees würden ja zwei reichen. Man könnte in die Schnittpunkte des Rasters auch Muttern einbringen und die Platinen dann zwischen U-Scheiben festschrauben. Damit würde das Raster auch noch stabiler werden. Und es ist günstige Massenware. Dann starte ich mal die nächte Abstimmung xD. Sollen wir die Platinen mit Stiftleisten und Buchsen verbinden, wie bei dem von ELV?
wenn die Spannungsversorgung durch alle Teilnehmer laufen soll, müssten aber auf jedem Pixel Regler genutzt werden oder? glaube nicht, dass der letzte Teilnehmer dann noch saubere 5V an seinen Eingängen anliegen hat
M. G. schrieb: > Ich selbst könnt mir vorstellen, auch kein Raster zu bauen, um die > Farbverläufe der einzelnen LEDs gut sichtbar zu bachen. Bei einem Raster > sind sie abgehackt. Dann hast du am Ende aber auch keine Pixel. Das war ja eigentlich der Grundgedanke des Tischs, und macht auch den (optischen) Charme aus, wie ich finde. M. G. schrieb: > Wie oben schon richitg festgestellt, bekommt man die Platinen nicht mehr > in das Pixelraster, wenn man die Holz/Plastik/.. stärke falsch/anderst > gewählt hat. Die Platine sollte deutlich kleiner sein als das Pixelraster. Dann gibt es in der Hinsicht keine Probleme. M. G. schrieb: > Für mich sieht das dann von oben nicht professionell aus, wenn ich auf > der Platinen noch mind. 6-7 Schrauben vorfinde (TX0,RX0,TX1,RX1,5V,GND) > event. noch CLK usw. > Nicht jeder will vllt milchglas benutzen! Ohne Milchglas kann man das sowiso vergessen. Statt schön gleichmäßig ausgeleuchteter Pixeln siehst du dann vermutlich garnix. Es sei denn du schaust im richtigen Winkel in die LEDs, dann hast du einen kleinen, grellen Punkt. Das ist doch Quark... M. G. schrieb: > Ich selbst könnt mir vorstellen, auch kein Raster zu bauen, um die > Farbverläufe der einzelnen LEDs gut sichtbar zu bachen. Bei einem Raster > sind sie abgehackt. Dann bekommst du vermutlich auch nicht so eine saubere IR-Touch-Erkennung. Und das abgehackte ist ja, wie oben geschrieben, der von den meisten Mitbastlern gewünschte Effekt.
und bei Steckverbindungen sehe ich nur das Problem, dass alle Verbindungen und Bohrungen passgenau sein müssen, sobald einer etwas schief kommt gerät die gesamte Reihe in Verzug
Anfänger schrieb: > und bei Steckverbindungen sehe ich nur das Problem, dass alle > Verbindungen und Bohrungen passgenau sein müssen, sobald einer etwas > schief kommt gerät die gesamte Reihe in Verzug Das kann doch genau geplant werden, gibt doch koordinatensystem bei jedem Layoutprogramm Boris P. schrieb: > Dann bekommst du vermutlich auch nicht so eine saubere > IR-Touch-Erkennung. Und das abgehackte ist ja, wie oben geschrieben, der > von den meisten Mitbastlern gewünschte Effekt. Boris P. schrieb: > Ohne Milchglas kann man das sowiso vergessen. Statt schön gleichmäßig > ausgeleuchteter Pixeln siehst du dann vermutlich garnix. Es sei denn du > schaust im richtigen Winkel in die LEDs, dann hast du einen kleinen, > grellen Punkt. Das ist doch Quark... http://www.youtube.com/watch?v=OLfF4b49MLs http://www.youtube.com/watch?v=vzWEgOt3xsM Geht doch wunderbar, ohne Milchglas Boris P. schrieb: > Die Platine sollte deutlich kleiner sein als das Pixelraster. Dann gibt > es in der Hinsicht keine Probleme. Maik Pfeiffer schrieb: > Zu den Platinen, hatten wir ja schon in einer Abstimmung festgelegt, > dass wir 50x50 mm Platinen verwenden werden. Offen war nur ncoh die > Verbindungen zwischen den Platinen. Na was den nun, kleiner gleich oder größer, wir sollten definitiv mal eine größe Festlegen!!! Anfänger schrieb: > wenn die Spannungsversorgung durch alle Teilnehmer laufen soll, müssten > aber auf jedem Pixel Regler genutzt werden oder? glaube nicht, dass der > letzte Teilnehmer dann noch saubere 5V an seinen Eingängen anliegen hat Spannungsverluste hast du auch mit Metallstreifen. Eventuell muss man einen Regler einsetzen. Wenn du meine Variante nimmst, ist der längste weg die diagonale vom Tisch.(Pixel zu Pixel = Kürzester Weg) Bei Metallstreifen ist der längste Weg Länge * Breite vom Tisch(oder legst du alles kreutz und Quer, oder willst du jeden Pixel zur Spannungsquelle einzeln verdrahten, oder gibt es eine Metalllatte für GND und eine Für +5V?) Also Mehr Spannungsabfall durch größer Leitung, ggf auch wegen schlechteren Leiter als Kupfer! Ggf auch auf 6V gehen, mit etsprechender Diode von 0,7V reduzieren oder Suppressordioden auf 5 V regeln lassen, ... oder andere Alternativen Boris P. schrieb: > Dann bekommst du vermutlich auch nicht so eine saubere > IR-Touch-Erkennung. Und das abgehackte ist ja, wie oben geschrieben, der > von den meisten Mitbastlern gewünschte Effekt. Ja, es gibt ja auch andere Möglichkeiten den Pixel einzusetzen, (siehe Bodenbeleuchtung/Treppenbeleuchtung Die umsetzung, ob Tisch, Treppe, Schrank ist egal, die Hardware sollte dies alles können. Es war ja auch nur eine Idee, welche mir in den Kopf gekommen ist, und sehr geil aussehen könnte. Aber ersteinmal die Hrdware, dann Software, dann Umsetzung in realität
M. G. schrieb: > Anfänger schrieb: >> und bei Steckverbindungen sehe ich nur das Problem, dass alle >> Verbindungen und Bohrungen passgenau sein müssen, sobald einer etwas >> schief kommt gerät die gesamte Reihe in Verzug > > Das kann doch genau geplant werden, gibt doch koordinatensystem bei > jedem Layoutprogramm und deine Hand ist beim Bohren/Sägen etc. so genau wie ein Layoutprogramm ? ;-)
M. G. schrieb: > Youtube-Video "Reactive LED Coffee Table - Arduino 2" > Youtube-Video "New Interactive Proximity Sensing PCB Table Modules" > > Geht doch wunderbar, ohne Milchglas sieht aber auch genau so aus, wie es hier die meisten nicht wollen. stichwort: punktbeleuchtung
>und deine Hand ist beim Bohren/Sägen etc. so genau wie ein >Layoutprogramm ? ;-) Also wenn du sie Platinen selber machen möchtest gerne. Ich werde die bei dieser Menge auf jeden fall fertigen lassen xD.
Die Rede war vom Tisch, nicht von der Platine. Für die Steckverbindung muss jede Bohrung (zur Befestigung der Platine) exakt sitzen, sonst gibt es bei den Verbindungen irgendwann Probleme denke ich. Bohrung etwas daneben -> Platine schief -> Steckverbindung miserabel
Bei den Verbindungen zwischen dem Gitter und den Platinen, hat man mit der Schrauben U-Scheiben Lösung min. 1mm Spiel. Wenn man Karosserie Scheiben nimmt sogar 2-3mm. Außerdem ist die Schraube noch im Spalt der Holzplatte verschiebbar. Und falls man sich da versägt hat, hilt die Feile und noch eine U-Scheibe gerne aus xD. Das Borraster wird ja in dem Fall von den Platinen vorgegeben. Wenn man sich nicht traut es selber genau genug hin zubekommen kann ma ja erst die Platinen auflegen und die Punkte anzeichnen, oder direkt fertigen lassen.
Maik Pfeiffer schrieb: > Bei den Verbindungen zwischen dem Gitter und den Platinen, hat man mit > der Schrauben U-Scheiben Lösung min. 1mm Spiel. Wenn man Karosserie > Scheiben nimmt sogar 2-3mm. Außerdem ist die Schraube noch im Spalt der > Holzplatte verschiebbar. Jetzt habe ich mir mal dein Bild genauer angeschaut, willst du ehrlich U-Scheiben zur Verbindung der Platinen nehmen? Soll hierüber auch die Spannungsversorgung realisiert werden? > Und falls man sich da versägt hat, hilt die > Feile und noch eine U-Scheibe gerne aus xD. Dein ernst? willst du 100 Pixel die U Scheiben feilen? "Wenn man sich nicht versägt hat" => wenn du das schon sagst, dann muss eine Lösung her die das nicht zulässt. > Das Borraster wird ja in dem Fall von den Platinen vorgegeben. Wenn man > sich nicht traut es selber genau genug hin zubekommen kann ma ja erst > die Platinen auflegen und die Punkte anzeichnen, oder direkt fertigen > lassen. Also die Platine hat ja durch das Layout-Programm entsprechend ein Koordinatensystem, an dem die Bohrlöcher ausgerichtet werden können. Diesen Plan kann man auch ausdrucken, auf den Tisch auflegen, und anschließend ankörnen/anreißen. zur not per Exel eine Tabelle anfertigen, welche die Rastermaße hat, und ausdrucken Mach doch bitte mal eine Zeichnung wie ihr euch die Stromversorgung über Metallstreifen vorstellt. Dann würde ich gern einmal die Platinenkonfiguration der Pixelplatinen vorranbringen. Denn dann sehen wir, ob genug Platz haben, Anzahl der Bohrlöcher bestimmen, ggf. Stiftleiste + Löcher für Metallstreifen usw.
Anfänger schrieb: > M. G. schrieb: >> Youtube-Video "Reactive LED Coffee Table - Arduino 2" >> Youtube-Video "New Interactive Proximity Sensing PCB Table Modules" >> >> Geht doch wunderbar, ohne Milchglas > sieht aber auch genau so aus, wie es hier die meisten nicht wollen. > stichwort: punktbeleuchtung Ja, wir machen ja auch den Tisch, aber ein zwei Pixel werde ich auch für andere Zwecke verwenden. Mit den Videos zeigte ich nur, das ein Milchglas keine Einflüsse auf IR hat. Wie gesagt, erst einmal die Platinen, dann der Tisch
Maik Pfeiffer schrieb: > Dann starte ich mal die nächte Abstimmung xD. > Sollen wir die Platinen mit Stiftleisten und Buchsen verbinden, wie bei > dem von ELV? Bin ich dafür, es sollte auf jedenfall vorgesehen werden,
Angehängte Dateien:
-
Entwurf_2.PNG
51 KB
anbei eine kleine Überarbeitete Version der Leiterplatte Diese hat nun das Format 48x48mm Es sind nun, neben den Steckkontakten auch zwei Header drauf, welche zur Verdrahtung untereinander mit z.B. Flachbandkabel dienen kann. des weiteren habe ich 4 Befestigungslöcher vorgesehen, welche zur Befestigung an der Grundplatte dienen können. Diese können dann auf GND gelegt werden, um die Massefläche über die Grundplatte zu realisieren des weiteren habe ich einen kleinen Spannungsregler vorgesehen. Dieser ist optional einfach ml draufgewandert, um zu sehen, wie viel Platz hier noch ist. um ggf. die Spannungsversorgung zu erhöhen, falls bedarf da ist. Wenn nicht benötigt, dann unbestückt lassen Theoretisch reicht der Platz aus. als nächstes kommen dann noch da ganze Hühnerfutter drauf. Hat jemand schon einen Schaltplan oder Skizze? Ist denn schon festgelegt ob nun über UART kommuniziert wird? mit CLK oder ohne?
Angehängte Dateien:
-
Schaltplan_1.PNG
17 KB
Ich habe schon einmal angefangen einen Schaltplan zu entwerfen. Kann mir mal jemand sagen ob dieser Ansatz schon korrekt ist? an welchen Pins würdet Ihr denn die LEDs anschließen, sowie IR Sender und Empfänger? PA0: PA1: PA2: PA3: PA4: SCK & RXD1 PA5: MISO & TXD1 PA6: MOSI PA7: RXD0 PB0: Quarz_0(optional) PB1: Quarz_1(optional) PB2: TXD0 PB3: RESET Bitte um Erweiterung und Korrektur Danke
Mein Vorschlag für den ATtiny841: Für ISP die Pins 1 - VCC, 4 - RESET, 7 - MOSI, 8 - MISO, 9 - SCK und 14 - GND auf (vergoldete?) Pads führen, 2x3-Anordnung im 2.54-mm-Raster wie beim 6-poligen ISP-Anschluss, Ober- und/oder Unterseite. Dazu drei (vier?) Bohrungen für Führungsstifte (2mm?) als Verpolungsschutz. Gedacht als Notfall-Programmiermöglichkeit mit Kontakten wie http://de.mouser.com/ProductDetail/Mill-Max/0906-1-15-20-75-14-11-0/?qs=%2fha2pyFaduhRqn077Jj6Gu1uYMOSpSD6sKrGRrX1TLk%3d diese hier. RGB-LED-Ansteuerung über Pins 10 - TOCC2, 11 - TOCC1 und 12 - TOCC0. Falls die IR-LED über Transistor/MOSFET angesteuert wird, dann über Pin 9 - PAP4/TOCC3 mit PWM-Möglichkeit. Somit bleibt ISP funktionsfähig. Den IR-Sensor an Pin 13 - ADC0. Kommunikation über USART0 in "alternate"-Konfiguration: Pin 5 - RXD0 und 6 - TXD0. Versorgung an Pin 1 - VCC und Pin 14 - GND. Pin 2 - XTAL1 und 3 - XTAL2 bleiben erstmal frei für evtl. Quarz. 1 - VCC ISP 2 - XTAL1 frei 3 - XTAL2 frei 4 - RESET ISP 5 - RXD0 Kommunikation 6 - TXD0 Kommunikation 7 - MOSI ISP 8 - MISO ISP 9 - SCK ISP PA4/TOCC3 IR-LED 10 - TOCC2 RGB-LED 11 - TOCC1 RGB-LED 12 - TOCC0 RGB-LED 13 - ADC0 IR-Sensor 14 - GND ISP
Konrad S. schrieb: > Mein Vorschlag für den ATtiny841: Hast du dies denn schon einmal aufgebaut und getestet? (Steckbrett?) Hast du einen ATTiny841 zu Hause? Wenn ja, wo hast du ihn gekauft? Ich werde dann mal den Schaltplan vervollständigen und übers Wochenende wieder reinstellen.
Habe einen Attiny841 hier auf dem Steckbrett. Mit ISP Header ohne externen Quarz. Benutze dieses Breakout hier: https://code.google.com/p/bot-thoughts-eezee/source/browse/#svn%2Ftrunk%2FeeZeeTiny841%2Felectronics Gibt es eine Beschreibung zu Karols Testaufbau (Bauteile)?
Hier noch die Übersichtsseite: https://code.google.com/p/bot-thoughts-eezee/wiki/eeZeeTiny841 Habe mir das Board beim Platinensammler bestellt...
Peter schrieb: > Habe mir das Board beim Platinensammler bestellt... Hast du einen Link zum Bestellen? Peter schrieb: > Gibt es eine Beschreibung zu Karols Testaufbau (Bauteile)? Nicht das ich wüsste.
Hat jemand eine Ahnung, wo man den ATTiny841 kaufen kann. so die Standard Hersteller haben den nicht im Sortiment, oder man muss Händler sein. Wenn dieser nicht leicht zu bekommen ist, sodass ein Nachbau für jeden möglich ist, sollten wir uns eine alternative überlegen
M. G. schrieb: > Hat jemand eine Ahnung, wo man den ATTiny841 kaufen kann. Digikey > > so die Standard Hersteller haben den nicht im Sortiment, oder man muss > Händler sein. Hersteller ist Atmel. Alles andere sind Händler/Distris. Und Digikey ist z.B. mein "Standard-Distri", somit ist die Aussage etwas subjektiv.
M. G. schrieb: > Peter schrieb: >> Habe mir das Board beim Platinensammler bestellt... > > Hast du einen Link zum Bestellen? Ich habe mir das Board selber im Platinensammlerthread bestellt. Dauert halt etwas. Die Attinys habe ich von Farnell. Sehr günstig, aber halt nur für Firmenkunden.
Hi
> Hat jemand eine Ahnung, wo man den ATTiny841 kaufen kann.
CSD
MfG Spess
Hallo, da die Preise recht hoch sind und um mal ein bisschen was ans Forum zurück zu geben, biete ich eine kleine Sammelbestellung an. Ich bestelle 100x oder 200x ATTINY841-SSU (SOIC14) bei Farnell für 0,75€/St inkl. MwSt. Um den Aufwand einzugrenzen biete ich maximal 20 Slots an und begrenze die Stückzahl pro Slot auf 5, 10 oder 20 Stück, sowie die Gesamtsumme auf 200 Stück. Versand wird wohl als Warensendung zu 0,90€ passen (50g). Mit kleiner Aufrundung für Verpackung & Aufwand würde ich folgende Preise festsetzen: 5 Attinys: glatte 5€ ( 5*0,75€ + 0,90€ = 4,65€) 0,35 10 Attinys: glatte 9€ (10*0,75€ + 0,90€ = 8,40€) 0,60 20 Attinys: glatte 17€ (20*0,75€ + 0,90€ = 15,90€) 1,10 falls Versand doch 1,90€ kostet Ich möchte noch darauf hinweisen, dass die Ware erst Montag bei mir sein kann und die nächste Woche kurz ist. Außerdem dauert eine Warensendung meist ein paar Tage. Die Teile werden also wohl nicht vor dem langen Wochenende bei euch sein. Bitte die Liste kopieren und sich eintragen. Zusätzlich eine PN mit Lieferadresse an mich schreiben. Zahlung per Überweisung. Wie mache ich das jetzt mit der Entscheidung, ob ich 100 oder 200 Stück anbiete? Ich warte mal die Reaktionen ab und bestelle bis 17 Uhr... momentan sind eh nur 285 Stück bei Farnell lagernd, mehr geht also nicht. Ich gehe einfach mal von großer Nachfrage aus und biete 200 Attinys verteilt auf maximal 20 Slots an. Ihr tragt euren Namen und gewünschte Menge (5, 10 oder 20) in einen Slot ein. Entweder ist kein Slot mehr frei oder die Gesamtmenge von 200 Stück ist erreicht. Also rechnet bitte, nachdem ihr euch eingetragen habt, die aktuelle Gesamtsumme aus. 1) 5, 10, 20 Stück, Name: 2) 5, 10, 20 Stück, Name: 3) 5, 10, 20 Stück, Name: 4) 5, 10, 20 Stück, Name: 5) 5, 10, 20 Stück, Name: 6) 5, 10, 20 Stück, Name: 7) 5, 10, 20 Stück, Name: 8) 5, 10, 20 Stück, Name: 9) 5, 10, 20 Stück, Name: 10) 5, 10, 20 Stück, Name: 11) 5, 10, 20 Stück, Name: 12) 5, 10, 20 Stück, Name: 13) 5, 10, 20 Stück, Name: 14) 5, 10, 20 Stück, Name: 15) 5, 10, 20 Stück, Name: 16) 5, 10, 20 Stück, Name: 17) 5, 10, 20 Stück, Name: 18) 5, 10, 20 Stück, Name: 19) 5, 10, 20 Stück, Name: 20) 5, 10, 20 Stück, Name: Gesamtsumme: x/200 Gruß Nils
Hallo, ich würde mich an diese Bestellung beteiligen wollen, Gebe aber zu bedenken, dass noch nicht alle Einzelheiten abgesprochen wurden. Wenn du eine Bestellung machst, dann würde sich anbieten, über das Wochenende zu warten, damit auch andere Personen sich entscheiden können. Bis 17 Uhr wirst du nicht viele Teilnehmer haben. PS Ebenfalls benötigt man auch entsprechnde Adapterplatinen, welche auch mitbestellt werden könnten. Oder IR LED Sende und Empfänger. Kannst du enbtsprechend eine Liste zusammestellen, in der IR, LED und µC enthalten sind. Dann wird auch die Versandtkosten künstiger. Des weiteren gebe ich nocheinmal zu bedenken, wenn dieser µC schwer zu bekommen ist (ohne Gewerbe zu haben) dann müsste man auf ein anderen µC wechseln, sonst macht das bauen dann kein Spaß mehr. Selbst bei Digikey kosten diese fast 1€ bei 100€ Und der Lagerbestand bei Farnell reicht auch nicht für alle aus! Gibt es denn eine Alternativen µC (SecondSource) Wir sollten nocheinmal die Anforderungen klären
Diese Sammelbestellung war eher dazu gedacht, die hier aktiven günstig mit Controllern für die ersten Muster oder zum Kennenlernen des Controllers zu versorgen. Für ganze Tische reicht der Lagerbestand eh nicht. Die Verfügbarkeit wird sich aber vermutlich später verbessern. Atmel hat erfahrungsgemäß immer etwas Anlaufschwierigkeiten. Ohne Gewerbe kommst du in so kleinen Mengen nicht günstiger dran. Ich wollte mich hier auf die reinen Controller beschränken. Da muss dann halt jeder selber etwas basteln, um die aufs Steckbrett zu bekommen. Ist ja auch nur ein Angebot. Edit: Bei späteren 1000+ Platinen sieht die Welt sowieso wieder ganz anders aus. Edit2: Die Adapter sind dort viel zu teuer. Lieber woanders gucken. Über IR- und RGB-LED kann man noch reden. Such was passendes raus...
:
Bearbeitet durch User
1) 10 Stück, Name: Marco G. 2) 5, 10, 20 Stück, Name: 3) 5, 10, 20 Stück, Name: 4) 5, 10, 20 Stück, Name: 5) 5, 10, 20 Stück, Name: 6) 5, 10, 20 Stück, Name: 7) 5, 10, 20 Stück, Name: 8) 5, 10, 20 Stück, Name: 9) 5, 10, 20 Stück, Name: 10) 5, 10, 20 Stück, Name: 11) 5, 10, 20 Stück, Name: 12) 5, 10, 20 Stück, Name: 13) 5, 10, 20 Stück, Name: 14) 5, 10, 20 Stück, Name: 15) 5, 10, 20 Stück, Name: 16) 5, 10, 20 Stück, Name: 17) 5, 10, 20 Stück, Name: 18) 5, 10, 20 Stück, Name: 19) 5, 10, 20 Stück, Name: 20) 5, 10, 20 Stück, Name:
Bin auch wieder mit im Boot... Irgendwie recht teuer was ihr vor habt... Nachdem ich ja ganz gute Erfahrungen mit DMS gesammelt habe: https://www.youtube.com/watch?v=9stMBGurpZ4 und das ganze bei einer sehr guten Auflösung nur ca. 40 € gekostet hat, werde ich an dieser Strategie festhalten. Ich werde meinen Tisch nun neu bauen (IKEA Tisch kostet ja nicht so viel) und China Matrizen verwenden, um schnell und günstig eine große Auflösung zu bekommen. Nachdem ich zwei Chinamatrizen nun mit einem 15 € Cortex-M4 Board auf WS2801 emuliert habe, habe ich jegliche Freiheiten um die Bilddaten zu generieren und per DMA über ein Adernpaar abzusetzen... Die 2048 Pixel Matrix für knapp 120 € ist hier zu sehen: https://www.youtube.com/watch?v=uE1VEO-WsN8 Einzigster Nachteil (der mir gerade einfällt)... es wird wohl kein Multitouch-Display durch die DMS Lösung... dafür kann ich nebenbei jeden Gegenstand auf dem Tisch wiegen :D Grüße Basti
Echt geiler Tisch, wie hast du die Erkennung hinbekommen?
Auch wenn es ein bisschen Offtopic wird, ich habe jetzt noch nichts bestellt, lass das Angebot aber erst einmal so stehen. Das oben genannte Breakoutboard habe ich jetzt auf 19x16 mm verkleinert. Es würde nun 1,65€ (plus Versand) beim Platinensammler kosten. Evtl. kann man direkt ein kleines Testboard mit den LEDs drauf machen...
Hab ich eben mal zufällig gefunden http://shop.led-studien.de/de/elektronik-bausatze/led-pixel/rgb-pixel-50x50mm-inkl.-wannen-kabel1
@Basti, schön das du wieder dabei bist, ich finde dein Projekt auch nach wie vor toll, jedoch wird dadurch das Touch entschieden vernachlässigt, wodurch dieses Projekt hier einen anderen Charm bekommt! Deshalb auch bitte jetzt nicht etwaige Lösungen vorschlagen und das Projekt in eine ganz andere Richtung leiten. Der Ausgangsthread beschreibt worum es gehen soll! Es sei denn du hast eine schicke Lösung parat dann bin ich ganz Ohr :-) und sorry, aber das läuft jetzt hier etwas aus dem Ruder! ;-) Der Fairness halber gegenüber den Leuten die hier schon eine Menge Hirnschmalz reingebracht haben, sollten wir an dieser Stelle stoppen... und strukturiert weiter vorgehen und nich alte Lösungen verwerfen... zudem wird hier kein Basar eröffnet für ein paar Teile damit ein Prototyp entstehen kann der noch gar nicht ansatzweise fertig durchdacht ist. Die Idee ist nett, aber dafür dann entweder an entsprechender Stelle oder aber in einen extra Thread. Der hier ist schon genug verwuselt und vermüllt, da müssen wir jetzt nicht noch eine Sammelbestellung für etwas nicht fertiges anfeuern :-) also: Was haben wir? -ISP?(Durchkontaktierungen auf die man stecken kann) -einen ADC Kanal (Touch Sens) -drei PWM Kanäle 10bit (RGB/HSV) -ein PWM? Kanal IR-LED -Hühnerfutter Solange hier keine Lösung zwecks Stromsteuerung für die IR-LED kommt, wird dieser Ideenansatz auch keine Bedeutung finden Was brauchen wir? erstmal eine fertige Pixelplatine! Deswegen bitte ich alle weiteren Diskussionen um Tisch etc. erstmal beizulegen... Die Pixelplatine steht im Vordergrund und solange die nicht steht, kommen wir eh nicht weiter. Deswegen finde ich es gut, dass sich Gedanken um das Layout gemacht wurde und was für Verbindungen genutzt werden sollen bzw. wie die Stromversorgung zu händeln ist. Und das ist meiner Meinung nach der richtige Ansatz. Erstmal Stromversorgung und Verbindung, sprich bleibt es beim 2xUART für DaisyChain? oder nehmen wir einen andern? Was kann als nächstes getan werden? -ganz klar der Aufbau eines bzw. mehrere Prototypen und testen des Touch+RGB+Bus etc. -anschließend evtl. Verbesserungen vornehmen -und erst dann können wir in Masse etwas für alle bestellen! Zwecks Attiny841: meine Recherchen hatten nun nicht so schlechte Lieferzahlen sprechen lassen, wenn jedoch ein sehr bekannter/lieferbarer Chip gefunden wird der alles kann was wir brauchen, können wir den ja gerne noch austauschen Und nun bitte ich alle etwas beim Thema zu bleiben so langsam hab ich die Vermutung das Leute abhanden kommen, weil jeder querbet etwas postet! :-)
Sorry Tim R. In deinem Ausgangspost steht alles recht allgemein! Glas erkennen, Hand erkennen... Milchglas... Wir alles von mir erfüllt... ich werde es wohl nicht mehr schaffen die anderen 300 Posts zu lesen... Wenn ihr gerade bei ner Sammelbestellung seid, dann möchte ich euch nicht raus bringen... Würde auch daisy chain machen... aber mit SPI, scheint mir einfacher... Evtl. gibts was aus der Logikfamilie... Parallel rein, latch und seriell raus... aber ihr habt sicher vor, dass IR noch zu modulieren.... wegen Fremdeinstrahlung... dann ist der Tiny sicher ganz brauchbar... Grüße Basti @M.G. Mit Dehnungsmessstreifen aus 4 Küchenwaagen...
Hallo, habe noch einen anderen Vorschlag zu machen, der aber etwas in eine andere Richtung geht, aber dennoch realisierbar ist. Wie in den beiden oben genannten Links, wird der WS2801. Meine Idee, wäre nun, auf eventuell einen billigeren µC umzusteigen (wenn dieser den Anforderungen entspricht, dann den WS28xx zu nehmen, im 1 bis 6 RGB LEDs anzusteuern. Der WS2801 kostet 0,35€, vllt aber auch etwas billiger. Kann mit etwas Hühnerfutter aber auch mehr LEDs treiben (siehe Link oben) Vielleicht sollte man dies noch einmal kurz prüfen. ebenso sieht man in dem Wieder eine Schöne Möglichkeit die Verbindung der einzelnen Platinen mittels Flachbandkabel UND Steckverbinder zu kombinieren. Alternativ könnten auch die Ansteuerung der Platinen mit WS2801 geschehen, und die IR geschichte mit einem kleinen µC mittels I2C oder ähnliches an den Haupt-µC geschickt werden, welcher dann die LED wieder steuert. Also zwei kreise, einmal senden an WS2801 und empfangen der IR Werte über "iC. Wie gesagt, nur eine weitere Möglichkeit vllt ist ja was dran PS finde die Idee 3 - 5 LEDs auf die Platine zu bringen ziemlich Cool, Sieht bestimmt ganz gut aus
@M.G. Ich glaube du weißt nicht wie hell das wird... aus Erfahrung kann ich sagen... 20 mA pro Farbe ist für eine "Tischuntermatrix" schon viel zu Hell... daher würde ich auch von WS2811 abraten und eher was mit WS2801 oder billigeren WS2803 empfehlen, wo der Strom noch einstellbar ist! Ein Pixel pro Platine halte ich für etwas verschwenderisch... Von der Zeit den der Aufbau dann braucht, ganz zu schweigen...
Basti schrieb: > Sorry Tim R. > > In deinem Ausgangspost steht alles recht allgemein! Glas erkennen, Hand > erkennen... Milchglas... > > Wir alles von mir erfüllt... ich werde es wohl nicht mehr schaffen die > anderen 300 Posts zu lesen... dann habe ich dich falsch verstanden... erläutere deine variante bitte nochmal genauer, auch wie du die sachen detektierst Basti schrieb: > Ein Pixel pro Platine halte ich für etwas verschwenderisch... Von der > Zeit den der Aufbau dann braucht, ganz zu schweigen... dadurch bleiben wir einfach dynamisch. jeder kann soviele pixel kombinieren wie er mag. ich nehme an du würdest mehrere pixel auf eine platine vereinen? ;-) zudem ist bei 5x5cm pixeln nicht mega viel platz, ich denke die kleine platine wird auch schon gut gefüllt werden
Also zum Objekt erkennen mit DMS... klingt komplizierter als es ist... Aufgebaut sind im Grunde 4 Küchenwaagen unter jeder Tischecke... die Tischplatte liegt nur auf den Waagen und muss am Rand "versteckt" Luft haben... Jetzt werden 80 mal die Sekunde alle 4 Waagen eingelesen... anschließend wird über die Kraftformel der teschnischen Mechanik (wie die genau heißt, weiß ich gerade nicht) die Position des neuen Objektes berechnet. Alle 4 Waagen addiert, ergibt das Gesamtgewicht! Wenn man alle Objekte nacheinander abstellt, ist es wahrscheinlich kein Problem in Software die zu Speichern, wo welches mit welchem Gewicht steht... schwierig wird es nur, wenn Objekte zeitgleich abgestellt werden... Jetzt wäre zu definieren was zeitgleich bedeutet... die 80 Hz sind da eher weniger das Problem... aber das Abstellen eines Glases ist wohl ein Vorgang der auf mehreren Sampels pro Sekunde zu Veränderungen führt -> Trägheit der menschlichen Hand... Kommt der Tisch durcheinander muss er wahrscheinlich geleert werden um wieder alle Objekte zu erkennen... Wenn mans richtig gut machen möchte ist es wohl anspruchsvolle Signalverarbeitung... so nen wandernder Mittelpunkt wie im Video, ist schnell programmiert... Hätte ich zwei gleiche Gläser auf den Tisch gestellt, wäre der Pixel in die Mitte der beiden Gläser gehoppst... da meine Programmierung noch nicht so weit ist ;) Grüße Basti P.S. 4 Waagen ist im Grunde schon eine zuviel... aber das führt zu einer höheren Messgenauigkeit und die Platte hat natürlich 4 Ecken und so ist der Aufbau symmetrischer...
Schaut euch doch noch einmal meinen Link zu der Platine an. dort sind 6 RGB LEDs drauf. 50x50mm Platinenmaß. Hier noch einmal der Link, http://shop.led-studien.de/de/elektronik-bausatze/led-pixel/rgb-pixel-50x50mm-6-led-inkl.-wannen-kabel und hier das passende Datenblatt http://www.led-studien.de/docs/RGB-Pixel_Datenblatt.pdf Also Platz ist genug, und wenn wir auf 3-5 LED reduzieren würden, passt locker noch eine ATTiny841 drauf. Das ist nur eine Frage des Layouts und der Layeranzahl Wenn ein anderer µC verwendet werden kann, weil wir eventuell die Kommunikation überarbeiten, kann auch auf einen µC mit weniger Pins umgestiegen werden. Man sollte einmal überlegen, ob dieses Konzept eventuell auch Verwendung finden kann. Das Konzept mit LED Matrix und WS28xx ist ja zu tausenden umgesetzt und funktioniert sehr gut. wir brauchen also "eigentlich" nur eine Möglichkeit der IR Messung und die Wertrückgabe an den Master-µC
Sorry fürs Starten der Sammelbestellung innerhalb dieses Threads. Bei Interesse geht es nun hier weiter: Beitrag "Sammelbestellung Attiny841 zum Ausprobieren für LED-Tisch" Es ging nur darum schnell ein paar Attinys zu bestellen, da ich den Eindruck hatte, einige würden den gerne ausprobieren, kommen aber nicht dran. Das hat nichts mit einer Entscheidung Zugunsten dieses Controllers zu tun und auch nichts mit einer Serienproduktion. Ich kann auch 10 oder 20 bestellen. Da ist der Preis nur geringfügig höher. Nur möchte ich keine 100 Briefe mit jeweils einem Controller verschicken, daher die Idee mit den Slots und der maximalen Anzahl.
Nils Nachname schrieb: > Nur möchte ich keine 100 Briefe mit jeweils einem Controller > verschicken, daher die Idee mit den Slots und der maximalen Anzahl. Lass uns doch noch einmal übers WE warten, vielleicht gibt es dann konkretere Definitionen.
M. G. schrieb: > Schaut euch doch noch einmal meinen Link zu der Platine an. > > dort sind 6 RGB LEDs drauf. 50x50mm Platinenmaß. > Wenn ein anderer µC verwendet werden kann, weil wir eventuell die > Kommunikation überarbeiten, kann auch auf einen µC mit weniger Pins > umgestiegen werden. > > Man sollte einmal überlegen, ob dieses Konzept eventuell auch Verwendung > finden kann. > > Das Konzept mit LED Matrix und WS28xx ist ja zu tausenden umgesetzt und > funktioniert sehr gut. wir brauchen also "eigentlich" nur eine > Möglichkeit der IR Messung und die Wertrückgabe an den Master-µC wir kennen die Variante, die wurde weiter oben glaube schon mal gepostet. Das Problem ist zum einen der Preis, knapp 4,- für diese Platine ist mir zuviel. Wenn du das Prinzip übernehmen möchtest, ist der Ansatz nicht verkehrt, das Problem ist nur wenn wir extra ein WSxxx nehmen wirds schwierig dann noch günstig und platzsparend per uC zu kommunizieren. Man kann auch nur per Master allen Teilnehmern die Farben übergeben, aber wie läuft dann der Touch -> das hast du schon gut erkannt... wenn es richtig im Kopf habe, hatten wir genau deshalb diesen Ansatz verworfen... auch wenn die WSxxx ein tolles Spielzeug sind :-)
Tim R. schrieb: > wir kennen die Variante, die wurde weiter oben glaube schon mal > gepostet. Ja habe ich schon gemacht, aber keine Rückmeldung bekommen :-) > Das Problem ist zum einen der Preis, knapp 4,- für diese > Platine ist mir zuviel. Ich will ja nicht die Platinen kaufen, sonder das Konzept hat mir gut gefallen, vor allem die Möglichkeiten die Platinen untereinander zu verbinden. > Wenn du das Prinzip übernehmen möchtest, ist der > Ansatz nicht verkehrt, das Problem ist nur wenn wir extra ein WSxxx > nehmen wirds schwierig dann noch günstig und platzsparend per uC zu > kommunizieren. Man kann auch nur per Master allen Teilnehmern die Farben > übergeben, aber wie läuft dann der Touch -> das hast du schon gut > erkannt... wenn es richtig im Kopf habe, hatten wir genau deshalb diesen > Ansatz verworfen... auch wenn die WSxxx ein tolles Spielzeug sind :-) Ok, war auch nochmal ein Einwurf, und wurde noch einmal verworfen. Hast du eine kleine Zeichnung, wie du die Platinen aufbauen möchtest? Habe oben ja mal eine 3D Zeichnung angefügt. Ist denn die Idee mit z.B. 3-6 LEDs auf der Platine verworfen? => Ansteuerung über PWM und Transistoren Eine kurze Anmerkung habe ich noch, bin gerade auf folgende µC gestoßen. Könnt Ihr euch diese einmal anschauen. LPC81X http://www.nxp.com/parametrics/71785/#/p=1,s=0,f=,c=,rpp=,fs=0,sc=,so=,es= Dieser hat auch 2 UARTS, 16/32 bit Timer, 4x PWM Vielleicht ist dieser auch geeignet
Konrad S. schrieb: > 1 - VCC ISP > 2 - XTAL1 frei > 3 - XTAL2 frei > 4 - RESET ISP > 5 - RXD0 Kommunikation > 6 - TXD0 Kommunikation > 7 - MOSI ISP > 8 - MISO ISP > 9 - SCK ISP PA4/TOCC3 IR-LED > 10 - TOCC2 RGB-LED > 11 - TOCC1 RGB-LED > 12 - TOCC0 RGB-LED > 13 - ADC0 IR-Sensor > 14 - GND ISP In diesem Beispiel haben wir nur ein UART verwendet, wollten wir nicht 2 UARTs haben? 1 - VCC ISP 2 - XTAL1 frei 3 - XTAL2 frei 4 - RESET ISP 5 - RXD0 Kommunikation 6 - TXD0 Kommunikation 7 - MOSI ISP PA4/TOCC3 IR-LED 8 - MISO ISP Kommunikation 9 - SCK ISP Kommunikation 10 - TOCC2 RGB-LED 11 - TOCC1 RGB-LED 12 - TOCC0 RGB-LED 13 - ADC0 IR-Sensor 14 - GND ISP Bitte einmal überprüfen, ob dies so möglich wäre
backEMF schrieb: > Den LPC81X hatte auch schon im Auge der hat aber leider keinen adc. OHHH, da war ja was, habe ich nicht gemerkt Hatten wir uns jetzt auf DaisyChain geeinigt, oder zwei mal UART? Was ist den der Vor bzw. Nachteil der beiden Systeme
M. G. schrieb: > Tim R. schrieb: >> wir kennen die Variante, die wurde weiter oben glaube schon mal >> gepostet. > Ja habe ich schon gemacht, aber keine Rückmeldung bekommen :-) Ja, aber die wurden noch eher gepostet... sogar von mir sehe ich gerade ^^ such mal im Browser dann zeigt er gleich den Post > Ok, war auch nochmal ein Einwurf, und wurde noch einmal verworfen. Ideen sind immer gut, nur sollten diese auch etwas durchdacht sein, denn ohne Infrarot ist das ja auch nur eine halbe Lösung ;-) > > Hast du eine kleine Zeichnung, wie du die Platinen aufbauen möchtest? > Habe oben ja mal eine 3D Zeichnung angefügt. Ich werde versuchen am Wochenende mal einen Schaltplan zu entwerfen wo man gleich ein Layout draus ziehen kann > > Ist denn die Idee mit z.B. 3-6 LEDs auf der Platine verworfen? > => Ansteuerung über PWM und Transistoren verworfen nicht, aber entweder 1 oder 4 sind denke ich sinnvoll. Und aus Kosten-/Energie-/Aufwandsgründen wird sich denke eine RGB durchsetzen. Wird denk ich auch reichen > > LPC81X Die meisten hier im Forum als Hobbybastler bevorzugen Atmel, wenn ich das hier so richtig überblicke, deswegen wurden die kleinen kostengünstigen Attinys ins Auge gefasst. Ich weiß nicht wie das Volk hier zu einem ganz anderen Chip stehen würde. Sind die denn auch günstig und gut lieferbar? Das muss man ja auch immer beachten
M. G. schrieb: > Wenn ein anderer µC verwendet werden kann, weil wir eventuell die > Kommunikation überarbeiten, kann auch auf einen µC mit weniger Pins > umgestiegen werden. 2 Pins Versorgung 3 Pins RGB 1 Pin IR-LED 1 Pin IR-Sensor 2 Pins Kommunikation -------------------- 9 Pins Also entweder bringst du einen Vorschlag für Kommunikation mit nur einem Pin oder du bringst einen Vorschlag für einen μC mit 9 bis 13 Pins. M. G. schrieb: > 8 - MISO ISP Kommunikation > 9 - SCK ISP Kommunikation Mach einen Vorschlag für die Kommunikation über die Pins 8 und 9, bei dem ISP möglich ist, ohne Verbindungen zu benachbarten Pixeln aufzutrennen.
Konrad S. schrieb: > Mach einen Vorschlag für die Kommunikation über die Pins 8 und 9, bei > dem ISP möglich ist, ohne Verbindungen zu benachbarten Pixeln > aufzutrennen. Ich hatte weiter oben die Frage gestellt, wie die Kommunikation ablaufen soll. Tim R. schrieb: > Aber der Ansatz > mit 2xUART ist denke ich schon am günstigsten. Wie willst du denn den zweiten UART benutzen, wenn du die ISP Schnittstelle dafür brauchst? (oder habe ich das falsch gelesen? Tim R. schrieb: > sprich bleibt > es beim 2xUART für DaisyChain? oder nehmen wir einen andern? wieder zwei UART Ports im Gespräch Konrad S. schrieb: > Also entweder bringst du einen Vorschlag für Kommunikation mit nur einem > Pin oder du bringst einen Vorschlag für einen μC mit 9 bis 13 Pins. Wie stellst du dir eine Kommunikation mit nur einem Pin vor??? gib doch bitte mal einen Vorschlag Es bleiben ja nicht viele Möglichkeiten, aber auf eine sollten wir uns endlich mal festlegen UART: dann benötigen wir zwei UART Ports. Einen für DataIN, und einen für DataOUT Oder willst du einen Nehmen? würde ja auch gehen. dann bräcuhten wir keinen µC mit zwei UARTs Oder? SPI(DaisyChain) Hier wird die SPI Schnittstelle benutzt, http://www.mikrocontroller.net/articles/SPI_Daisychain I2C: wurde ja schon abgelehnt (oder vllt. doch nicht????) Konrad S. schrieb: > Mach einen Vorschlag für die Kommunikation über die Pins 8 und 9, bei > dem ISP möglich ist, ohne Verbindungen zu benachbarten Pixeln > aufzutrennen. die Pins können ja im Betrieb andere Funktionen besitzen. Wenn aber eine UART Funktion auf der ISP Schnittstelle liegt, kann man nichts machen (oder habe ich den Schaltplan falsch verstanden) Wenn wir auf DaisyChain gehen, hast du das Problem auch. Wenn du die den µC Programmieren willst, bekommen die anderen µC dann halt nur wirre Daten. Werden aber nicht programmiert, weil du die Reset-Leitung der anderen µC ja nicht mit benutzt. Beim Programmstart sollte eh einmal alles mit "0" initialisiert werden, um einen definierten Anfangszustand zu haben. FAZIT: Welche Kommunikationsschnittstelle wollen wir nun benutzen? UART oder SPI?
USART braucht ihr wieder einen Quartz... Oder ihr nehmt gleich einen XMega aus der E Serie... Dann habt ihr für schmales Geld so einige Schnittstellen und stabileren Clock. Man könnte auch das WS2811 Protokoll umsetzen, da kann der Clock schon gut schwanken und es kommt noch sauber durch... Ich seh den Aufwand gar nicht so sehr im programmieren... das ihr da was zusammenhängen müsstet...
der Gedanke war jeden Pixel mit 2 UARTs auszustatten. Wie im Artikel beschrieben, schiebt der Master alle Daten zum ersten Slave. Dieser entnimmt seine Farbwerte für die RGB-LED und reicht die anderen Daten über die zweite UART weiter (Daisychain). Der nächste entnimmt seine Daten und so weiter. Es ist bei jedem Pixel quasi immer das erste Datenpaket. Ein Zug an Daten der durchgereicht wird. Die Touch-Werte also die ADC Werte (natürlich gefiltert etc.) werden entsprechend über den die UART zum vorliegenden Slave weitergereicht, dieser leitet die Daten zum wieder vorigen weiter. Somit kommen vom aller ersten Slave der die RGB Werte empfangen hat auch als erstes die Touch Daten am Master an. --- Wenn hoffentlich die Pixel relativ gleich schnell senden/verarbeiten) --- Für die UART KANN und ich denke SOLLTE auch ein Quartz verwendet werden. Einfach um eine stabile Kommunikation zu sichern. Sehe darin auch kein großes Problem, warum will jeder zweite auf einen Quartz verzichten? Kostengründen? Ich finde mit dem Quartz ist einfach gesichert das die Timings stimmen. Wenn die Kommunikation den Bach runter geht ist der ganze Tisch dahin ;-/ Für SPI würde wieder eine CLK Leitung benötigt werden und wie sieht es mit dem ChipSelect aus? 2xUART wären insgesamt 4 Leitungen. Es würde keine Aufbereitung benötigt werden weil die Leitungslänge sich zwischen den Pixel auf wenige mm oder cm bewegt :-) die ISP sollte doch standardgemäß benutzbar sein oder überseh ich gerade was?! Und I2C ist denke ich auf die Länge etwas langsam und zudem wird jeder Teilnehmer nacheinander aufgerufen was die Sache etwas in die Länge zieht denk ich
:
Bearbeitet durch User
Für Daisy-Chain mit UART reicht ein UART. Schließlich hat ein UART RXD und TXD. Und wer - bitteschön - verlangt, dass RXD und TXD von einem UART zum gleichen Partner gehen müssen? Nosnibor hat hier Beitrag "Re: schwierigkeiten passenden Bus zu finden" schon geschrieben, was nötig ist, um in einer Daisy-Chain ohne Quarz zu arbeiten: Die Quelle der Daisy-Chain - und nur diese - sendet mit zwei Stop-Bits. Die von mir vorgeschlagene Anschlussbelegung lässt die Verwendung eines ¨Angst¨-Quarz zu. ;-) Der geneigte Leser mag sich die Takt-Differenz ausrechnen, die nötig ist, damit in der vorgeschlagenen Daisy-Chain-Konfiguration bei zwei Stop-Bits in der Eispeisung Datenverlust auftritt. Dazu als Hinweise: - Es muss nur ein Byte betrachtet werden. - Was ist der Synchronisations-Trigger für das Start-Bit im Empfänger? - Wann ist der letzte relevante Bit-Slot zu Ende?
Konrad S. schrieb: > Für Daisy-Chain mit UART reicht ein UART. Schließlich hat ein UART > RXD und TXD. Und wer - bitteschön - verlangt, dass RXD und TXD von > einem UART zum gleichen Partner gehen müssen? dann rechne mal bitte vor wieviel Daten du damit umher jagen kannst und vergiss dabei bitte nicht sowohl RGB/HSV als auch Touch Daten ;-)
Ich denk jeder Pixel sollte ein Cortex A8 mit Linux und WIFI bekommen, dann ist die Kommunikation gesichert... Ne mal im Ernst: wo liegt denn euer Preislimit pro Pixel? Habt ihr euch da schon geeinigt? Irgendwie gibts hier tausend Vorschläge die schon aus dem Preisrahmen fallen... Letztendlich würde ich eine Platine mit 4 oder 6 Pixeln entwickeln, sonst explodieren euch die Kosten... Vorschlag: WS2803 sind wie WS2801 vom latchen her... der Vorteil für euch (aber meist ein Nachteil), die verhalten sich wie richtige Schieberegister und nehmen nicht gleich ihre Daten aus dem Datenstrom... Also eine Platine mit WS2803 (=6 Pixel) und beim SPI in Serie einen Microkontroller der 6 IRs modulieren und auswerten kann (2xSPI hat). Der Master macht nun folgendes: Er schiebt einmal so viel Daten rein, wie nötig sind und erhält hinten raus die IR Werte... fertig ist... ganz simple und sagen wir, wenigstens um den Faktor zwei weniger Preis intensiv.
Basti schrieb: > Ne mal im Ernst: wo liegt denn euer Preislimit pro Pixel? Glaube um irgendwas 3-4Euro für Materialkosten waren wir mal angelangt > Habt ihr euch > da schon geeinigt? Irgendwie gibts hier tausend Vorschläge die schon aus > dem Preisrahmen fallen... Letztendlich würde ich eine Platine mit 4 oder > 6 Pixeln entwickeln, sonst explodieren euch die Kosten... Da der Tisch auf einer Waben-/Tetrisstruktur basiert, ergab sich eigtl von allein daraus, dass einzelne Pixelplatinen benötigt werden... wie hast du vor die Platine dann unter den Tisch zu bekommen?! Zumal du durch die Pixellösung völlig flexibel in der Anzahl bist > Vorschlag: WS2803 sind wie WS2801 vom latchen her... der Vorteil für > euch (aber meist ein Nachteil), die verhalten sich wie richtige > Schieberegister und nehmen nicht gleich ihre Daten aus dem Datenstrom... > Also eine Platine mit WS2803 (=6 Pixel) und beim SPI in Serie einen > Microkontroller der 6 IRs modulieren und auswerten kann (2xSPI hat). Naja gut, dann bräuchte man einen fetten Controller der 6 PWM? Kanäle ansteuern kann + WSxxx. Das wird dann denke auch kein ganz günstiger Controller mehr oder? Sicher das die Lösung so günstig ist?
:
Bearbeitet durch User
@M. G. (hummer87) Ich wollte dir dezent zu verstehen geben, dass deine Idee (¨einen µC mit weniger Pins¨ zu nehmen) unüberlegt ist, da bei den AVRs der nächstkleinere μC 8 Pins hat und damit zu klein ist. Es liegt also bei dir zu zeigen, dass es mit einem ¨kleineren¨ μC geht. Zum Thema ISP versus UART auf Pin 8 und 9: Stell dir drei benachbarte Pixel vor und von denen willst du den mittleren per ISP flashen. Auf Pin 9 liegen einerseits SCK vom ISP und andererseits die vom Vorgänger kommenden zu empfangenden Daten. Entweder musst du die Verbindung zum Vorgänger trennen oder du musst verhindern, dass der Vorgänger seinen TXD1 treibt, z.B. indem du den Vorgänger im Reset hältst.
Konrad S. schrieb: > Zum Thema ISP versus UART auf Pin 8 und 9: > Stell dir drei benachbarte Pixel vor und von denen willst du den > mittleren per ISP flashen. Auf Pin 9 liegen einerseits SCK vom ISP und > andererseits die vom Vorgänger kommenden zu empfangenden Daten. Entweder > musst du die Verbindung zum Vorgänger trennen oder du musst verhindern, > dass der Vorgänger seinen TXD1 treibt, z.B. indem du den Vorgänger im > Reset hältst. die sollten einmal geflasht werden und dann war die Überlegung "per Bus" zu flashen falls das nochmals nötig sein sollte, denn wollt ihr 100 Slaves alle einzeln per Hand flashen ? ;-) Aber mal davon abgesehen, wenn der Master keine Daten sendet, senden auch die Slaves keine Daten und somit kann man die ISP Pins ganz inruhe benutzen -> nur Master ruhig stellen ist erforderlich
@Tim R. als wenn man keinen Rahmen bauen könnte, der über die Platinen drüber geht... und da ihr keine Quadratmeter abdeckt, sollte die PCB aus China noch günstig zu bekommen sein... Hier ein Beispielkontroller: http://de.mouser.com/ProductDetail/Atmel/ATXMEGA8E5-AU/?qs=sGAEpiMZZMsXXU7tc6nusW3l2k2yH0M1 nen Euro bei 25 Stück... 18 PWM Kanäle... 6 Analogkanäle... Zwei USART/SPI Master und einen SPI Slave, I2C... bei 32 MHz Clock, kann der SPI Slave auch bissel Geschwindigkeit erreichen... kein Quartz nötig, PDI Programmierung über zwei reservierte Pins + VCC und Ground... ganzen Daten bekommt man per DMA weggeschaufelt...
Tim R. schrieb: > Konrad S. schrieb: >> Für Daisy-Chain mit UART reicht ein UART. Schließlich hat ein UART >> RXD und TXD. Und wer - bitteschön - verlangt, dass RXD und TXD von >> einem UART zum gleichen Partner gehen müssen? > dann rechne mal bitte vor wieviel Daten du damit umher jagen kannst und > vergiss dabei bitte nicht sowohl RGB/HSV als auch Touch Daten ;-) Du kannst bei 8MHz Takt mit einem UART 500kBaud empfangen (mit der Double-Speed-Option sogar 1MBaud). Bei zwei Stop-Bits ergibt das gut 44kByte/s (88kByte/s). Du hast 176 Takte (88 Takte) Zeit, um die Daten zu verarbeiten - allerdings sind auch noch andere Dinge abzuarbeiten, z.B. IR-LED und ADC. Das ist mit Interrupts schon mal nicht ganz ohne. Wenn du zwei UARTS nutzt, dann halbieren sich die zur Verarbeitung zur Verfügung stehenden Takte. Durch einen 16-MHz-Quarz kommst du wieder auf die ursprünglich genannten Werte. Es sei noch angemerkt, dass in einer Daisy-Chain-Konfiguration keine Interrupts für die Sender-Seite nötig sind. Bei einem Daisy-Chain-Durchgang werden für alle Pixel nur gleichartige Daten übertragen. Das Kommando steht also nur einmal im Header (RGB, HSV, ...) und nur die Farbwerte sind einmal je Pixel enthalten, sagen wir drei Bytes je Pixel. Jedes Pixel tauscht beim Weiterreichen durch die Daisy-Chain seine empfangenen Daten durch seine Daten für den Rückkanal aus. Dafür muss das Pixel zwar wissen, an welcher Position es in der Daisy-Chain sitzt, aber mit einem ¨DURCHZÄHLEN¨-Kommando ist das kein wirkliches Problem. Also ich komme bei einem UART und 25 Updates pro Sekunde auf ca. 600 Pixel pro Daisy-Chain.
Basti schrieb: > @Tim R. als wenn man keinen Rahmen bauen könnte, der über die > Platinen ja okay stimmt auch wieder > Hier ein Beispielkontroller: > http://de.mouser.com/ProductDetail/Atmel/ATXMEGA8E... Ok vielleicht blödes Beispiel weil der momentan nicht lieferbar ist ;-P @Konrad S. Das mit dem Austauschen ist ein guter Gedanke... nur wenn ungefähr 3Byte RGB-Daten kommen, wozu dann 3 Byte für den Touch verbrauchen? 1 Byte reicht ja eigtl völlig, aber diese "Verschwendung" muss an der Stelle dann wohl hingenommen werden. Das mit dem durchzählen hatte mich auch schon mal beschäftigt. Will man zuvor jedem Pixel eine feste Position zuordnen?! Das ist vielleicht etwas blöd Würdest du nicht eine DaisyChain pro Pixelreihe quasi machen? Ich hab deine Rechnung einfach mal so hingenommen, aber 600 Pixel pro DaisyChain klingt ziemlich heftig :-) (positiv gemeint)
@Tim R. wenn du mehr als 3650 Stück brauchst, dann ist er bei Mouser für dich wohl nicht lieferbar
Basti schrieb: > @Tim R. wenn du mehr als 3650 Stück brauchst, dann ist er bei > Mouser für > dich wohl nicht lieferbar ops mega peinlich, bin in der Zeile verrutscht! :-) also der uC hat aufjedenfall eine Menge Preipherie. Die Idee Pixel zu vereinen besteht ja die ganze Zeit schon, wie ist denn die Resonanz der andern?
Konrad S. schrieb: > Also ich komme bei einem UART und 25 Updates pro Sekunde auf ca. 600 > Pixel pro Daisy-Chain. was mir gerade noch einfllt... wenn wirklich nur eine UART verwendet werden soll, dann können wir auch auf den tiny841 verzichten und einen 2313 beispielsweise nehmen oder evt. kleiner?
Bezüglich der Pixel Zusammenführung, ist es denn sinnvoll einen Pixel zu nehmen, oder 4 Pixel auf eine Platine zu bringen. Das Beispiel mit dem atmega würde eine menge Geld einsparen und dieser kann 4 RGB led ansprechen sowie noch 4 IR led. Pwm hat er ausreichend. Preisbeispiel: 4x 0,80€ für attiny841 ( Einzelpersonen ) bei 4 Pixeln Oder 1x 1,50€ für atmega bei 4 Pixeln Die Platinen werden bei den meisten Herstellern nach dm2 abgerechnet. Ob ich nun 4 mal eine Platine nehme oder 1 mal in der selben gesamtgröße spiel nicht so die rolle. Auch die MHz sind höher. Vielleicht ist dies auch eine Option um günstiger zu werden
@M.G. könnte von mir sein, die Idee :P Das sind dann übrigens 18 mal 16 Bit PWM !!! Kann man jedenfalls bei der A4 Serie auch auf 24x8 Bit PWM umschalten... aber pins für spi blockieren einige PWMs!
Tim R. schrieb: > die sollten einmal geflasht werden und dann war die Überlegung "per Bus" > zu flashen falls das nochmals nötig sein sollte, denn wollt ihr 100 > Slaves alle einzeln per Hand flashen ? ;-) Firmware-Updates kommen selbstverständlich nur über UART ... zumindest solange, bis sich mal jemand vertut und den Bootloader zerschießt, weil der ATtiny841 keine Fuses hat, die einen Bootloader vor Überschreiben schützen würden. > Aber mal davon abgesehen, wenn der Master keine Daten sendet, senden > auch die Slaves keine Daten und somit kann man die ISP Pins ganz inruhe > benutzen -> nur Master ruhig stellen ist erforderlich Nein. Solange der TXD1 des Vorgänger-Pixels enabled ist, produziert er einen High-Pegel an SCK.
Tim R. schrieb: > Das mit dem Austauschen ist ein guter Gedanke... nur wenn ungefähr 3Byte > RGB-Daten kommen, wozu dann 3 Byte für den Touch verbrauchen? 1 Byte > reicht ja eigtl völlig, aber diese "Verschwendung" muss an der Stelle Das erste Pixel muss diesen Durchsatz in jedem Fall bringen können. Alle anderen Pixel haben die gleiche Leistung. Also warum unnötige Komplexität aufbauen durch ¨ausdünnen¨ des Datenstroms? > dann wohl hingenommen werden. Das mit dem durchzählen hatte mich auch > schon mal beschäftigt. Will man zuvor jedem Pixel eine feste Position > zuordnen?! Das ist vielleicht etwas blöd Fest? Nein, einfach nur beim Booten die Chain(s) durchzählen lassen. Die Reihenfolge in der Chain hat dann eigentlich nur aus rein pragmatischen Erwägungen eine ¨feste Beziehung¨ zur physischen Anordnung der Pixel. > Würdest du nicht eine DaisyChain pro Pixelreihe quasi machen? Ich hab Ich würde die Anzahl der Pixel pro Chain deutlich höher machen, auch im Hinblick auf das, was ich mal zur Stromschiene mit Kupferfolie gesagt habe (eine Reihe Pixel ¨linksrum¨, nächste Reihe ¨rechtsrum¨). Ich würde einerseits nicht die höchstmögliche Baudrate nehmen und andererseits erstmal eine Abschätzung haben wollen, wieviele Takte die Kommunikation verbrauchen darf. Danach richtet sich auch der UART-Bedarf des Masters. > deine Rechnung einfach mal so hingenommen, aber 600 Pixel pro DaisyChain > klingt ziemlich heftig :-) (positiv gemeint) Ich hoffe, die Rechnung stimmt.
Zu ¨mehrere Pixel auf einer Platine¨: Weiter oben war mal die Rede von Platinen mit 20x20cm zu einem guten Preis. Vorteile gibt es einige: es kommen ganz andere Kontroller in Frage, der Befestigungsaufwand reduziert sich deutlich, Steckverbinder zwischen den Platinen werden finanziell und vom Bestückungsaufwand her interessanter, ... Nachteile gibt es auch: weniger flexibles System, die ¨anderen Kontroller¨ sind noch weniger Bastler-lötfreundlich als SOIC, ...
Tim R. schrieb: > was mir gerade noch einfllt... wenn wirklich nur eine UART verwendet > werden soll, dann können wir auch auf den tiny841 verzichten und einen > 2313 beispielsweise nehmen oder evt. kleiner? ATtiny2313: Bezüglich Pin-Anzahl ist er größer (und bringt somit mehr unnötige Pins mit). Er hat nur zwei 16-Bit-PWM. Sein interner RC-Oszillator ist schlechter. Er hat weniger Flash und RAM. Und: Er ist nicht wirklich billiger!
Ich fände es sinnvoll, mit 20cm x 20cm Platinen von Elecrow zu arbeiten und einfach das zu machen, was Julius unter http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html gemacht hat, nur ohne Lochraster und ohne Krimpen von Kabeln. Dank billigerer PCBs als Julius vermutlich zur Verfügung hatte (?) kann einfach die gesamte Fläche des Tischs unten PCB sein. Oder wieso hat er das so gemacht wie er es gemacht hat mit 1200 Adern? Wieso hat er für jeden Pixel eine kleine Lochrasterplatine benutzt, die dann lose oder geschraubt im Kästchen liegt? Vermutlich nur um PCB-Herstellungskosten zu sparen, außerhalb von China wäre das ja auch unbezahlbar. Oder hat einer eine andere Idee warum er das gemacht hat? Und wenn jetzt hier der Plan ist, dass ein Pixel 5cm x 5cm groß ist und gleichzeitig das PCB aber auch volle 5cm x 5cm groß ist, wird ja doch die volle Fläche zu bezahlen sein. Nur wenn ihr den Attiny, RGBs & co und Stecker auf ein kleineres PCB macht, lohnen sich meiner Meinung nach der Aufwand für Kabel oder Schrauben und die Pixel-Platinen würden in dem Kästchen liegen und viel Raum um sich haben, so wie bei Julius. Der teure IS471F liefert ein Digitalsignal und braucht kein ADC. Das Shift-Register dazu (74HC165) gibt es bei Reichelt und den PWM-Controller mit 12 Bit billig bei Aliexpress: http://www.aliexpress.com/item/100-Original-TLC5940NT-TLC5940-TI-LED-Driver-DIP-28/1468213464.html (ob es eine Fälschung ist weiß ich nicht). Kein SMD nötig! Dadurch ist eine robuste (wenn auch mit 2,50 EUR sehr teure) Bewegungserkennung gegeben und die Platinen sind kaskadierbar als Daisy Chain, weil eben sowohl der 74HC165 als auch der TLC5940 die Daten durchreichen können. Wichtig ist nur, es so zu layouten, dass die Chips nicht mit den Kästchenrahmen kollidieren und nicht hässlich durch das Plexiglas durchscheinen, oder die Chips auf die Unterseite des PCBs machen, dann muss aber das Plexiglas oder Glas alleine den Druck von oben halten. Elecrow würde aber vermutlich auch ohne Aufpreis Stege in die Platinen fräsen, die nicht komplett durchgehen, so dass der Holzrahmen teilweise durch das PCB durchgehen könnte um auf eine stabile Platte unterhalb des PCBs zu drücken. Wird halt dann nur noch komplizierter, die Kästchen-Kämme zu sägen... Natürlich ist diese Vorgehensweise vollkommen abweichend von den Dingen, die im Thread alle verfolgt werden (Protokoll, Intelligenz pro Pixel, volle Flexibilität für Anordnung und Abstand und Anzahl der Pixel...), aber man könnte zumindest die Kosten prüfen: Der ADC-Kanal ist der Preis, auf den teuren IS471F verzichten zu können und billige IR-Empfänger verwenden zu können!
Konrad S. schrieb: > Nein. Solange der TXD1 des Vorgänger-Pixels enabled ist, produziert er > einen High-Pegel an SCK. richtig, war ich zu voreilig, man könnte evtl noch ein Diagnose Commande verwenden womit alle Pixel ihr TX irgendwie abschalten und erst wenn sie etwas empfangen (vom vorigen) ihre UARTs wieder vollständig einschalten, aber das ist zu aufwendig denke ich... > Fest? Nein, einfach nur beim Booten die Chain(s) durchzählen lassen. Die > Reihenfolge in der Chain hat dann eigentlich nur aus rein pragmatischen > Erwägungen eine ¨feste Beziehung¨ zur physischen Anordnung der Pixel. Du meinst der Master schickt ein "Zähl-Kommando" und jeder hängt den laufenden Counter entsprechend höher und weiß vom Vorgänger an welcher Stelle er nun liegt? Wäre eine einfache gute Möglichkeit :-) Konrad S. schrieb: > Nachteile gibt es auch: weniger flexibles System, die ¨anderen > Kontroller¨ sind noch weniger Bastler-lötfreundlich als SOIC, ... Gerade die Flexibilität war ja das was hier etwas im Vordergrund steht. Weil der eine 20x10 der andere 5x3 Pixel oder wie auch immer haben will. Die Variante ist günstiger keine Frage, aber will das hier auch jeder? Konrad S. schrieb: > ATtiny2313: Bezüglich Pin-Anzahl ist er größer (und bringt somit mehr > unnötige Pins mit). Er hat nur zwei 16-Bit-PWM. Sein interner > RC-Oszillator ist schlechter. Er hat weniger Flash und RAM. Und: Er ist > nicht wirklich billiger! nächste mal sollt ich doch vorher recherchieren bevor mir was rausplatzt :-) Christian H. schrieb: > Oder wieso hat er das so gemacht wie er es gemacht hat mit 1200 Adern? > Wieso hat er für jeden Pixel eine kleine Lochrasterplatine benutzt, die > dann lose oder geschraubt im Kästchen liegt? Vermutlich nur um > PCB-Herstellungskosten zu sparen, außerhalb von China wäre das ja auch > unbezahlbar. Oder hat einer eine andere Idee warum er das gemacht hat? Irgendwo hat er geschrieben, dass dies während seiner anfangs Studienzeit entstanden ist. Deswegen tippe ich, dass das Wissen dafür evtl. noch nicht vorhanden war oder auch einfach sein Basteltrieb ihn auf Lochraster etc. gebracht hat. Deswegen wollen wir hier eine ausgeklügelte einfachere,schnellere und günstigere Alternative schaffen ! :-) > > Und wenn jetzt hier der Plan ist, dass ein Pixel 5cm x 5cm groß ist und > gleichzeitig das PCB aber auch volle 5cm x 5cm groß ist, wird ja doch > die volle Fläche zu bezahlen sein. Also ich habe gerade mal fix einen Schaltplan gemacht und kurzes Layout, ich denke mit 45x45mm kommen wir mehr als genug hin für einen Pixel. Könnten sicher noch kleiner werden. > Dadurch ist eine robuste (wenn auch mit 2,50 EUR sehr teure) > Bewegungserkennung gegeben und die Platinen sind kaskadierbar als Daisy > Chain, weil eben sowohl der 74HC165 als auch der TLC5940 die Daten > durchreichen können. Wie oben beschrieben habe ich den Sensor getestet. Ist wirklich ein einwandfreier Sensor mit integriertem Filtering etc. Nur für 2,50 bekommen wir fast eine komplette Pixelplatine hin von daher sprengt der Sensor enorm die Kosten. 100 x 2,50 = 250eus (ohne Rabatt) rein für den IR-Sensor. Ich bin begeistert von dem Teil aber das ist es mir nicht Wert ;-)
Tim R. schrieb: > nächste mal sollt ich doch vorher recherchieren bevor mir was rausplatzt > :-) Gerade die Recherche bei Preisen ist schwierig, finde ich. Oben schrieb z.B. einer vom LPC11?? für 0.??€, den habe ich aber nur zu einem deutlich höheren Preis gefunden. > Also ich habe gerade mal fix einen Schaltplan gemacht und kurzes Layout, > ich denke mit 45x45mm kommen wir mehr als genug hin für einen Pixel. > Könnten sicher noch kleiner werden. Man könnte die Platine, um Fläche zu sparen, auch als schmalen Streifen vorsehen, gerade lang genug um die Stromschienen zu erwischen und nur so breit wie nötig. 35x20mm oder sowas. Wie auch immer, das muss als System geplant werden. Egal wo man dreht, es hat oft an anderer Stelle Konsequenzen. Schnellschüsse bringen da nichts.
Zum ISP... man kann auch alle Resets verbinden... dann kann keine anderer Controller rein quatschen... darf nur nicht an jedem reset 100 nF hängen ;) Ich weiß nicht ob ihr alle unter einen Hut bekommt... das läuft ja schon recht lange hier... Ich kann nur davon abraten mit einem Mikrocontroller und Vorwiderständen die LEDs zu betreiben... Konstantstromquellen mit 2% von Kanal zu Kanal und 5% von Chip zu Chip haben bei mir schon leichte Unterschiede zeigen lassen... Ohne guten Konstantstrom wird man aber auf der Konstruktion den unterschiedlichen Spannungswerten nicht Herr...
Angehängte Dateien:
-
DSC_0130.jpg
1,5 MB -
IMG_20140127_182021.jpg
850 KB -
DSC_0184.jpg
1,4 MB -
Unbenannt2.png
43 KB
Ich bin seit längeren auch dabei ein LED tisch zu bauen und schreibe hir mal meine erfahrungen. Mein Tisch hat 12x8 Felder mit einer Feldgröße von 5cmx5cm. Für die Beleuchtung nehme ich pro feld 2 ws2811 LEDs. Für die Berührungserkennung kommt in jedes Feld eine IR-LED und ein IR-Fototransitor. Die IR-LED wird mit 200kHz moduliert um störendes Fremdlich zu filtern. Die geplante Filterschaltung befindet sich im Anhang (Verstärkung der OPs muss noch angepasst werden) und wird zum schluss 8x Aufgebaut (Multiplexen der Fototransistoren). Als Fototransistor nehme ich: http://de.mouser.com/ProductDetail/Everlight/EL-PT15-21B-TR8/?qs=sGAEpiMZZMs50KUSuyRkpgKT0SUtKLb%252bZwTGgpPx6fw%3d und als LED die: http://www.conrad.de/ce/de/product/181712/IR-Emitter-940-nm-60-3-mm-radial-bedrahtet-Harvatek-HE3-160AC?ref=list Mit den Aufbau konnte ich ein Strom am Fototransistor von Störende Schreibtischlampe: 0,729µA LED ohne Berührung: 216µA LED mit Berührung: 260µA Fernbedinung: 162µA messen.
Basti schrieb: > Ich kann nur davon abraten mit einem Mikrocontroller und Vorwiderständen > die LEDs zu betreiben... Konstantstromquellen mit 2% von Kanal zu Kanal > und 5% von Chip zu Chip haben bei mir schon leichte Unterschiede zeigen > lassen... Ohne guten Konstantstrom wird man aber auf der Konstruktion > den unterschiedlichen Spannungswerten nicht Herr... wie würdest du denn allgemein überhaupt die Spannungsversorgung realisieren?!
Basti schrieb: > Ich kann nur davon abraten mit einem Mikrocontroller und Vorwiderständen > die LEDs zu betreiben... Konstantstromquellen mit 2% von Kanal zu Kanal > und 5% von Chip zu Chip haben bei mir schon leichte Unterschiede zeigen > lassen... Ohne guten Konstantstrom wird man aber auf der Konstruktion > den unterschiedlichen Spannungswerten nicht Herr... Solange dabei nur Exemplarstreuungen entstehen, kann man das Problem auf die Software abwälzen, indem jedes Pixel in seinem EEPROM entsprechende Korrekturwerte speichert. Die Spannungsversorgung ist natürlich ein anderes Problem: wenn nicht jedes Pixel einen eigenen Spannungsregler bekommt, wird die tatsächlich anliegende Spannung immer von der Last abhängen, und zwar nicht nur von der Last, die das Pixel selbst darstellt, sondern auch von der Belastung durch alle Pixel auf dem Weg bis zur Spannungsquelle. Theoretisch sollte der Master das berechnen und kompensieren können, aber der Abgleich (für jedes Pixel messen, wie es jedes andere beeinflußt) wäre wohl zu aufwendig.
Tim R. schrieb: > man könnte evtl noch ein Diagnose Commande > verwenden womit alle Pixel ihr TX irgendwie abschalten Ich gehe mal davon aus, dass bei notwendiger ISP-Programmierung die Kommandos über die Chain nicht mehr funktionieren. Würden sie noch funktionieren, dann bräuchte man den ISP nicht. ;-) (Man kann natürlich ganz schlicht beim Vorgänger-Pixel Reset provisorisch mit GND verbinden. Aber bei 100 oder mehr Pixel? Würg!) Unterm Strich: Ohne Not lieber die Finger vom USART1 lassen. Basti schrieb: > Zum ISP... man kann auch alle Resets verbinden... dann kann keine > anderer Controller rein quatschen Hm, ob das jeder Programmer mitmacht, wenn er 100 Eingänge treiben soll? Außerdem wäre das eine zusätzliche Verbindung, die von Pixel zu Pixel geführt werden müsste. Basti schrieb: > Ohne guten Konstantstrom wird man aber auf der Konstruktion > den unterschiedlichen Spannungswerten nicht Herr Bei dem Ansatz mit 0.1mm-Kupferfolie als Stromschiene kann jede Stromschiene einen Querschnitt von 4mm² haben, d.h. die Folie ist 40mm breit. Davon müssten dann zwei Pixelreihen versorgt werden, bei einem 10x10-Tisch also 20 Pixel. 0.1mm-Kupferfolie kostet hier http://de.opitec.com/opitec-web/c/zz/cID/c3I6ODA1OTk4MQ==/searchResult.jsf 28.86€/m².
Nosnibor schrieb: > Solange dabei nur Exemplarstreuungen entstehen, kann man das Problem auf > die Software abwälzen, indem jedes Pixel in seinem EEPROM entsprechende > Korrekturwerte speichert. Mit einem KPS-5130PD7C Farbsensor http://www.conrad.de/ce/de/product/180381 alle Pixel (im eingebauten Zustand) abgleichen. Der Master fährt ein Abgleichprogramm, bei dem der User den Farbsensor nach Blinkzeichen weiterbewegt. Wenn der Master alle Messwerte beisammen hat, errechnet er neue PWM-Lookup-Tabellen und macht das Update für alle Pixel.
Ich bin mal über diesen IC gestolpert: http://www.tme.eu/de/details/sct2210cstg/led-treiber/starchips-technology/# 16x Konstantstromquelle Schieberegister Ohne PWM, dafür ein echt günstiger Preis (~10cent / RGB-Led). Und man spart sich einen Haufen Widerstände zum löten. PWM für die einzelnen Kanäle wird aber nur noch mit hohem Softwareaufwand möglich sein. BAM (Bit-angle-Modulation) ist dagegen recht einfach und ohne Probleme bis ~12bit implementierbar.
Konrad S. schrieb: > Bei dem Ansatz mit 0.1mm-Kupferfolie als Stromschiene kann jede > Stromschiene einen Querschnitt von 4mm² haben, d.h. die Folie ist 40mm > breit. Davon müssten dann zwei Pixelreihen versorgt werden, bei einem > 10x10-Tisch also 20 Pixel. > 0.1mm-Kupferfolie kostet hier > http://de.opitec.com/opitec-web/c/zz/cID/c3I6ODA1O... > 28.86€/m². was vertragen diese Folien denn? eignen die sich als "Träger" für die Spannungsversorgung? habe leider noch nie mit solchen Folien gearbeitet
@Nosnibor kann man schon, will man das? Bei 16 Bit PWM kann man auch die eingehenden VCC messen und danach die LED PWM anpassen... die Kurve ist aber alles andere als linear... was das an programmier und vor allem testaufwand bedeutet... ui ui ui... das ist IMO nichts, was man sofort in eine Sammelbestell-Platine verpacken kann... weil das erst erprobt werden sollte... @Tim hm, bei meiner Matrix habe ich sehr große Masse und VCC Flächen hinbekommen und diese auch in 4 Richtungen ordentlich verteilen können: http://www.ledstyles.de/index.php/Thread/20531-Matrixsystem-Vorstellrunde/ Letztendlich hat ein Einspeisepunkt bei 20 A Maximalstrom ausgereicht (dank Konnstantstrom ;) ) Wird aber bei euerm Aufbau nicht so leicht, da viel mehr drauf muss... Würde hier im einfachsten Fall blanken 0,75 mm² Draht links und rechts der Platinen führen und den auf irgend ne passend dafür eingelötete "klemm Gabel" drücken... Was man dafür "missbrauchen" könnte, wäre noch herauszufinden...
asterix schrieb: > was vertragen diese Folien denn? eignen die sich als "Träger" für die > Spannungsversorgung? habe leider noch nie mit solchen Folien gearbeitet Welcher Art sind deine Bedenken? Kupfer als Leiter? Stört dich, dass die Folie dicker ist als die Kupferauflage einer Leiterplatte? Eher interessant ist die Frage, ob man bei einer Unterkonstruktion aus Holz zwischen Holz und Kupferfolie eine isolierende Kuststofffolie einlegen sollte. Oder ob man auch z.B. selbstklebendes Dachschutz-Kupferband nehmen könnte.
Hallo, ich habe mal eine Frage, habt Ihr einmal ausgerechnet, was ihr für Sträme erwartet? Ich habe mir mal kurz eine Matrix aus Pixeln von 8x8 RBS hergenommen. Wenn alle LEDs mit einmal Leuchten ergibt sich folgende Rechnung (Ich hoffe ich bekomm es richtig zusammen) !!! Wenn alle LEDs leuchten !!! Matrix(RGB) 8x8x3 = 192LED LED Strom : 0,02A 192 * 0,02A = 3,84A ====== Nun könnten wir ja auch mehrere Pixel auf eine Platine bringen und dies als Matrix aufbauen. Da hier maximal nur eine Spalte an ist ergibt sich folgende Rechnung: Spalte(RGB) = 8*3 = 24LEDs LED Pulsstrom = 0,1A 24*0,1 = 2,4A ===== Wir würden hierbei schon wieder Stromsparen Eine weitere möglichkeit wäre auch Charliplexing, hier weiß ich aber nicht, ab das realisierbar ist, da dieses System eigentlich für etwas anderes ausgelegt ist. Habe ich ein Berechnungsfehler? Eine Matrix zwar ist zwar etwas aufwändiger zu realisieren (Treiber usw.) aber auf die Dauer Kostengünstiger) oder?
Basti schrieb: > Wird aber bei euerm Aufbau nicht so leicht, da viel mehr drauf muss... > Würde hier im einfachsten Fall blanken 0,75 mm² Draht links und rechts > der Platinen führen und den auf irgend ne passend dafür eingelötete > "klemm Gabel" drücken... Was man dafür "missbrauchen" könnte, wäre noch > herauszufinden... an so etwas ähnliches hatte ich auch schon gedacht... einen Kupferdraht an alle Pixel führen und festgehalten wird das ganze durch eine Schelle oder Klemme oder irgendwas... Konrad S. schrieb: > asterix schrieb: >> was vertragen diese Folien denn? eignen die sich als "Träger" für die >> Spannungsversorgung? habe leider noch nie mit solchen Folien gearbeitet > > Welcher Art sind deine Bedenken? Kupfer als Leiter? Stört dich, dass die > Folie dicker ist als die Kupferauflage einer Leiterplatte? keine Sorgen, nur ich weiß nicht wie diese Kupferfolien sich im Gegensatz zu "normalen" Drahtleitern verhalten, gibts doch vllt. andere Eigenschaften. Aber wenn ihr meint damit lässt sich das lösen, wäre es ja eine schöne alternative
schönes Tischdesign übrigens! Den Post hatte ich noch gar nicht gesehen
@hummer87: Wenn die Spalten gemultiplext werden, wird es wohl Strom sparen. Aber ist das ein Argument dafür es so zu bauen? Solange nur 10, 12 oder 16 Bit PWM verfügbar ist, kann der gleiche Stromspareffekt ja einfach per Firmware erzielt werden: Einfach keine höheren Helligkeiten erlauben als ein bestimmer wert. Dann bleibt auch die maximale Stromaufnahme und Dicke der Leitungen doch im Rahmen, oder? Insbesondere wenn die PWM-Controller phasenversetzt arbeiten.
Christian H. schrieb: > Insbesondere wenn die > PWM-Controller phasenversetzt arbeiten. An Phasenversetzte PWM habe ich noch garn nicht gedacht. schönes Thema. Habe ich mich noch nicht damit beschäftigt. Dann würde ich ja bei einer RGB LED nur maximal 20mA Strom ziehen, obwohl alle 3 LEDs an sind? Klingt wunderbar, wenn es Umsetzbar ist.
Christian H. schrieb: > @hummer87: > Wenn die Spalten gemultiplext werden, wird es wohl Strom sparen. Aber > ist das ein Argument dafür es so zu bauen? Solange nur 10, 12 oder 16 > Bit PWM verfügbar ist, kann der gleiche Stromspareffekt ja einfach per > Firmware erzielt werden: Einfach keine höheren Helligkeiten erlauben als > ein bestimmer wert. Dann bleibt auch die maximale Stromaufnahme und > Dicke der Leitungen doch im Rahmen, oder? Oder! PWM schaltet unterschiedlich lange ein/aus. Auf die Stromstärke bei einer einzelnen LED hat es keinen Einfluss. Legst du die Leitungen nur auf die mittlere Stromstäke aus, dann bekommst du deutlichere Spannungseinbrüche. > Insbesondere wenn die > PWM-Controller phasenversetzt arbeiten. Im Prinzip ja. Aber sobald du Überlappungen hast, musst du doch wieder den vollen Strom bereitstellen. Und du musst dich bei der maximal erreichbaren Helligkeit einschränken. Ebenso bei der nutzbaren PWM-Auflösung.
Ohne Strom oder An-Zeit der PWM keine Helligkeit... Ich hab ein 2,5 cm Raster und mir hätten 3x7 mA gereicht... bei 5 cm Raster sollte wohl 3x20 mA reichen... Aber von den Rastermaßen bin ich weg... ich möchte nicht nur ein paar "Klötzer" aufleuchten lassen... ich stell mir ein paar richtig schicke Animationen vor... Hat schon mal jemand mit großen resistiven Touchfolien expermentiert? Bisher hab ich die nur ab 70 € gesehen... :-/ Multitouch wäre natürlich auch schick... gibts da schon was günstiges von den Chinesen?
Basti schrieb: > Aber von den Rastermaßen bin ich weg... ich möchte nicht nur ein paar > "Klötzer" aufleuchten lassen... ich stell mir ein paar richtig schicke > Animationen vor... Dann kauf doch einfach einen 60"-Fernseher und lasse ihn in einen Tisch ein. Dann noch eine Touch-Folie drauf und fertig. Dürfte sogar fast schon billiger sein, als unser Pixel-Projekt ;-)
Basti schrieb: > Wird aber bei euerm Aufbau nicht so leicht, da viel mehr drauf muss... > Würde hier im einfachsten Fall blanken 0,75 mm² Draht links und rechts > der Platinen führen und den auf irgend ne passend dafür eingelötete > "klemm Gabel" drücken... Was man dafür "missbrauchen" könnte, wäre noch > herauszufinden... in etwa sowas? http://www.pollin.de/shop/dt/NTkyODQ1OTk-/Bauelemente_Bauteile/Mechanische_Bauelemente/Steckverbinder_Klemmen/SMD_Leiterplattenklemme_WAGO_2060_0402_2_polig.html
Hö? Ne... wer soll das bezahlen, wenn ihr so viele Platinen machen wollt... dachte an was einfacheres für nen cent... sonst bist du allein mit dem WAGO Ding bei 50 €... Im Notfall so was... und dann doch fest löten... wenns was schönes gibt, was alleine Klemmt, wäre noch besser... http://static1.tme.eu/katalog_pics/3/c/9/3c9e7912d075ae736086152ffdf1dee9/1001.28.jpg
mit dem Preis ist klar... aber vielleicht gibt es ja in der Richtung irgendwelche billigen Klemmen die man verwenden kann
http://www.reichelt.de/Kabelschuhe/QS-1-5-4/3/index.html?&ACTION=3&LA=2&ARTICLE=24827&GROUPID=3250&artnr=QS+1%2C5-4 oder http://www.reichelt.de/Flachstecker/RK-R-4/3/index.html?&ACTION=3&LA=2&ARTICLE=15260&GROUPID=3249&artnr=RK-R-4 knapp 3euro für 100stück :-) die Versorgung von Teilnehmer zu Teilnehmer "schleifen" sollte damit einfach und schnell machbar sein oder nicht?
Schnell? Naja... alles relativ Ich hätte es so gemacht: diesen oben gezeigten Lötstift in die Platine einlöten... Ein 0,75er Draht (massiv) Abisolieren und auf erste Lötstift einer Reihe anlöten, dann einfach zur nächsten Platine ziehen, anlöten, weiter anlöten bis zum Ende... Draht zur nächsten Reihe weiter biegen und weiter gehts... Könnte mir vorstellen, dass man damit in 30 Minuten bei 100 Platinen durch ist... Noch besser wäre, wie schon erwähnt, ein Stift der das blanke Kabel nur klemmt ohne es trennen zu müssen.... ähnlich wie bei Netzwerkkabel Da ist man bei den Kabelschuhen noch dabei, 200 Kabelstücke jeweils zwei mal abzuisolieren... :P Wenns richtig teuer sein darf, schnell Aufgebaut und flexible, wäre der ASI Bus genau das richtige... Einfach das selbstheilende ASI Kabel in die Klemme drücken und mit zwei Leitungen Spannung und Datenbus bereit gestellt ... naja, man wird ja noch träumen dürfen :D Grüße Basti
Geil wäre wenn man einfach die nackte Ader wo rein "klippt" und gut... wäre für alle Pixel eine Arbeit von 30sek :D
Tim R. schrieb: > Geil wäre wenn man einfach die nackte Ader wo rein "klippt" und gut... Sowas wie "Abzweigverbinder", z.B. in der KFZ-Elektrik? Lästig bleibt dabei in jedem Fall die Kabelführung. Irgendwie muss das Kabel durch die Pixelwand. Und beim Aufsetzen der Pixelwände hat man nicht für jedes Pixel eine Hand, die das/die Kabel in die richtige Position drückt.
Wenn du keine durchgängige Platine hast, wird das eh immer auf einen zu kommen... seh hier aber keine größeren Probleme... Die KFZ Teile schneiden die Litzen recht stark... Verwende die nicht so gern...
Basti schrieb: > Wenn du keine durchgängige Platine hast, wird das eh immer auf > einen zu > kommen... seh hier aber keine größeren Probleme... das denke ich auch... zumal du ja die trennwände einzeln hantieren kannst... > > Die KFZ Teile schneiden die Litzen recht stark... Verwende die nicht so > gern... ich weiß nicht ob es sowas gibt, ich habe eine klettverbindung gefunden für normale NYM kabel http://www.voelkner.de/products/162431/400-xl.jpg statt dem klett eben metall (mit verbindung zur platine), wo das kabel reingelegt wird und man nur "umklappen" oder schrauben brauch zum befestigen... das wäre dann sowas von einfach :-) aber die oben geposteten flachstecker oder kabelschuhe find ich auch vällig okay, dann muss nur vcc/vss durch die platinen geführt werden, weiß nicht ob das so gut ist
Vielleicht lässt sich die IR Objekt Erkennung recht einfach mit den xmega e realisieren. Die empfangsschwelle lässt sich über den analog Komparator und dem DAC steuern. Die (de)modulation kann er möglicherweise in Hardware. Ich habe damit aber selbst noch nichts gemacht. Die demodulation sollte aber auch in Software kein Problem sein. Bei dieser Lösung bräuchte man für led und Fotodiode nur je einen widerstand.
hmm der Rest hier ist wohl leider wieder etwas verhindert ;-/
Hat wohl was mit der Fußball-WM zu tun. Seitdem ist's hier ruhig geworden. ;-)
Konrad S. schrieb: > Hat wohl was mit der Fußball-WM zu tun. Seitdem ist's hier ruhig > geworden. ;-) die schau ich doch ebenfalls, sollte doch aber kein Hindernis oder ;-)
Tim R. schrieb: > sollte doch aber kein Hindernis oder ;-) Hängt davon ab, wie lange der Einzelne braucht, um mit den Folgen der jeweiligen Freuden- oder Trauerfeier fertig zu werden. ;-)
na Tim, dann bau doch schon mal los?! Nen XMega und nen paar Fotodioden ne SPI Verbindung und du weißt schon mal, ob das so funktioniert (auch durchs Plexi) wie du es dir vorstellst... Einer muss doch den Anfang machen... sonst passiert hier sicher nicht mehr viel... Meinst du evtl. solche Verbinder? -> http://www.emico.de/shop_emico/images/artikel/list/180_189.jpg
Hallo, wollte mal Fragen, ob es denn schon einem Schaltplan gibt. Eventuell vllt. auch eine Bestellliste der einzelnen Bauteile, damit auch alle mit den gleichen Teilen Testen können. Ich würde mich über eine kleine Zusammenfassung freuen, wie weit vllt schon der ein oder andere gekommen ist.
Basti schrieb: > na Tim, dann bau doch schon mal los?! Nen XMega und nen paar > Fotodioden > ne SPI Verbindung und du weißt schon mal, ob das so funktioniert (auch > durchs Plexi) wie du es dir vorstellst... Einer muss doch den Anfang > machen... sonst passiert hier sicher nicht mehr viel... Werde ich machen sobald die Zeit da ist. Nur neuer Job und ein anstehender Umzug spielen mir nicht gerade in die Karten, deswegen erstmal noch theoretisches "Geplänkel" :-/ > > Meinst du evtl. solche Verbinder? -> > http://www.emico.de/shop_emico/images/artikel/list... Ja, für die blanke Ader der Versorgungsspannung wäre das doch einfach und kostengünstig oder nicht ? M. G. schrieb: > wollte mal Fragen, ob es denn schon einem Schaltplan gibt. > Eventuell vllt. auch eine Bestellliste der einzelnen Bauteile, damit > auch alle mit den gleichen Teilen Testen können. Ich hatte Schaltplan und Layout letzte Woche sporadisch mal angefangen. War nur halb fertig bzw. müsste da mal jemand drüber schauen, bin sicherlich kein Elektronik spezi... ich werde es heut Abend einfach mal hochladen
ps: ich nehme an der Attiny841 ist dann fest wenn keine weiteren Einwände kommen? @Basti, mit den Fotodioden wurde bereits getestet und ein schönes Video (siehe oben) dazu auf Youtube geladen. Deswegen denke ich sind die Komponenten für das Touch schon mal ermittelt. Mache mir eher um das Bussystem und die Versorgung noch Sorgen
nicht Gast schrieb: > Vielleicht lässt sich die IR Objekt Erkennung recht einfach mit den > xmega e realisieren Tim R. schrieb: > ps: ich nehme an der Attiny841 ist dann fest wenn keine weiteren > Einwände kommen? "Da waren Sie wieder, unsere drei Probleme!" Wenn wir mit einer einzelnen LED auf der Platine arbeitem, macht sicherlich der Attiny841 sinn. Sollte dennoch der Gedanke im Raum stehen, mehrere LEDs auf eine Platine zu bringen, würd der XMega eventuell mehr sinn machen. (Auch weitere Faktoren spielen eine Rolle: z.B. die Frequenz der Datenübertragung kann beim XMega viel höher gewählt werden.) Ein Anforderungsprofil, an welchen nicht mehr gerüttelt wird, wäre sehr sinnvoll. Dann was irgendwo mal einer geschrieben hat, findet man nicht mehr so leicht wieder. Es gibt doch eine Projektseite, in der Festlegungen, welche hier diskutiert wurden, reingeschrieben werden können. Desweiteren können auch Schaltpläne schon angefertigt werden, um zu sehen, ob noch weitere Bauteile benötigt werden, wo der Preis liegt, eventuell weitere Zusatzbauteile (wie Spannungsregler usw.) mit vorgesehen werden sollen. Tim R. schrieb: > Ich hatte Schaltplan und Layout letzte Woche sporadisch mal angefangen. Bitte poste ihn doch mal, dann können mehrere Leute weiterarbeiten, Verbesserungen geben, und den Fortschritt mit begleiten. Wenn alle Bauteile spezifiziert sind (Gehäuseform) dann kann auch ein anderes Mitglied das Layout machen. Es muss ja nicht einer alles machen. Bin sehr gespannt, wann der erste Prototyp das erste Lebenszeichen von sich gibt :-)
M. G. schrieb: > Wenn wir mit einer einzelnen LED auf der Platine arbeitem, macht > sicherlich der Attiny841 sinn. Natürlich hat man mit diesem Ansatz ein sehr modulares Design, mit all seinen Vorteilen. Aber es treibt auch den Preis massiv in die Höhe. Ich habe mich mal umgeschaut was einzelne Leds kosten würden. Inzwischen sind diese so günstig geworden, dass man alleine für den µC 20 Leds bekommt. http://de.aliexpress.com/item/1000PCS-LOT-5050-highlighted-red-green-and-blue-LED-light-emitting-diode-RGB-LED/1759436080.html http://de.aliexpress.com/item/free-shipping-10000pcs-lot-5mm-LED-IR-water-clear-led-diode-850nm-940nm-LED-Light-Emitting/1665949654.html http://de.aliexpress.com/item/2-X-1000-pcs-Lot-3MM-940NM-Photodiode-Infrared-Emission-Controls-FZ0444-Free-Shipping/1508783472.html Macht ~7ct inkl. MwSt. pro Pixel ohne Ansteuerung. Der Gesamtpreis sinkt enorm je mehr Pixel von einem µC angesteuert werden können. Es wäre es eine Überlegung wert (ich glaube der Vorschlag wurde schon genannt), 15x1cm² oder 20x1cm² Platinenstreifen zu benutzen und damit jeweils 4 Pixel zu realisieren. Man muss auch nicht einen µC wählen der alle Peripherie enthält, die gebraucht wird. Wenn man schon 1000 µCs bestellt kann man auch mit Softpwm und ähnlichen Tricks arbeiten (der Attiny24 günstiger als sein Nachfolger).
Sam .. schrieb: > Es wäre es eine Überlegung wert (ich glaube der Vorschlag wurde schon > genannt), 15x1cm² oder 20x1cm² Platinenstreifen zu benutzen und damit > jeweils 4 Pixel zu realisieren. Ja, ich hatte glaube auch einen Vorschlag gemacht, mit 15x15 oder 20x20cm Platinenen, das ist dann nicht mehr modular, bricht aber die Kosten enorm runter, was die µC angeht. Ebenfalls benötigt man von vielen sachen nur ein geringe Menge. z.b. fürden eventuelle Spannungswandler enorm reduziert, Steckverbinder, uvm. Auch der Verkabelungsaufwand wird geringer. Ebenso war im Gespräch die Platinen auch bestücken zu lassen. wenn ich mich nicht täusche wird die Bestückung nach Bauteilen und Platinen berechnet. die bauteile würden sich ebenfalls reduzieren, und die zu bestückenden Platinen auch. Also wieder Kosten eingespart. Ok, die Platinen werden dann pro Stück teuerer. aber bei entsprechender Menge, nimmt sich das nicht viel. Wenn es doch eh ein Tisch/Wand/etc. werden soll, dann kann man auch vorgeben, das mindestens eine Platine aus z.B. 5x5 Pixeln besteht. damit bekommt man auch sehr gut eine Vielzahl von Vorman hin. z.B. 100x100 pixel, 200x50 pixel. Auch mit 10x10 Pixeln lassen sich dies alles realisieren. Ehrlichgesagt ist dies immernoch meine erste Wahl, und ich sehe nur vorteile. Habt ihr eine andere Meinung
M. G. schrieb: > Wenn es doch eh ein Tisch/Wand/etc. werden soll, dann kann man auch > vorgeben, das mindestens eine Platine aus z.B. 5x5 Pixeln besteht. damit > bekommt man auch sehr gut eine Vielzahl von Vorman hin. z.B. 100x100 > pixel, 200x50 pixel. Ich finde diesen Weg eigentlich auch super. Es wird nur schwierig, sich mit "alle Mann" auf eine Rstergröße zu einigen, oder? Mein favorit wäre auch 20cm x 20cm Platinen, mit 4x4 oder 5x5 Pixeln. PS: Mal eine dumme Anfängerfrage: sehe ich das richtig, das Stromverbrauch von dem Ding gigantisch wird? Kleine Worst-Case-Rechnung: Für einen 1,6m x 1m Tisch, mit 8x5 20cm Platinen mit jeweils 5x5 Pixeln komme ich auf genau 1000 Pixel. Jeder Pixel hat 4 LEDs (RBG + IR), mit 20mA. Insgesamt also 80 Ampere?
:
Bearbeitet durch User
Boris P. schrieb: > Stromverbrauch von dem Ding gigantisch wird? Abgesehen davon, dass die Pixel mit 5cm etwas größer sein soll(t)en und die IR-LEDs nur einen Bruchteil der Zeit eingeschaltet sind, ist deine Rechnung richtig.
Boris P. schrieb: > PS: Mal eine dumme Anfängerfrage: sehe ich das richtig, das > Stromverbrauch von dem Ding gigantisch wird? > Kleine Worst-Case-Rechnung: Für einen 1,6m x 1m Tisch, mit 8x5 20cm > Platinen mit jeweils 5x5 Pixeln komme ich auf genau 1000 Pixel. Jeder > Pixel hat 4 LEDs (RBG + IR), mit 20mA. Insgesamt also 80 Ampere? also auf einer Fläche von 1x1m kriegt man bei 5x5cm Pixeln (Trennwände weggelassen) knapp 400 Pixel rein?! 400 mal 20mA für eine LED + 20mA für eine IR LED = 400 x 40mA = 16A (ganz grober Richtwert) daraus ergibt sich die oben genannte Problematik der Spannungs-/Stromversorgung
Konrad S. schrieb: > Boris P. schrieb: >> Stromverbrauch von dem Ding gigantisch wird? > > Abgesehen davon, dass die Pixel mit 5cm etwas größer sein soll(t)en und > die IR-LEDs nur einen Bruchteil der Zeit eingeschaltet sind, ist deine > Rechnung richtig. korrekt.. und die LEDs werden über asynchroner PWMs geschaltet
Anfänger schrieb: > die LEDs werden über asynchroner PWMs geschaltet ... was bei 100% aber nicht weiterhilft. Die Stromversorgung muss auf das Maximum ausgelegt werden. Man könnt' natürlich auf Software-Seite eine Begrenzung vorsehen.
Konrad S. schrieb: > Mach mal einen Vorschlag, wie damit die Kommunikation aussieht. I2C über USI http://www.atmel.com/Images/doc2560.pdf Noch günstiger geht es mit einer anderen Familie. Die STM8S werden in größeren Stückzahlen sehr günstig. Ich bin übrigens für ein 4x4 Raster, da es kaum Treiber mit krummen 5 oder 10 Kanälen gibt. Von den SCT2xxx Schieberegistern gibt es eine ganze Menge, sie sind auch alle günstig. Verfügbar sind sie leider nur bei Alibaba und tme. http://www.tme.eu/de/katalog/#id_category=112848&s_field=wysoki_prog&s_order=ASC&visible_params=2%2C367%2C35%2C10%2C2613%2C365%2C98%2C383%2C32%2C364%2C120%2C55%2C375%2C2234%2C63%2C31%2C804&used_params=383%3A24821%2C24608%2C24792%3B http://www.alibaba.com/product-detail/Linear-Mixed-Signal-Integrated-Circuits_100392069.html (SCT2016) Aber im Vergleich zu den bisherigen Lösungen, sind sie unschlagbar günstig und brauchen keine Widerstände. Bei einer 4x4 Matrix würde ein SCT reichen um die Leds inklusive IR-Led im 4-fach-Multiplex-Betrieb anzusteuern.
Genau und in so einen Tisch mit 250 W LED Leistung guckt man noch gern rein... Wie schon erwähnt, würde empfehlen nur mit 7 mA pro Farbe zu arbeiten...
ich finds ja schön wenn sich immer neue Leute einbringen, aber warum denn immer wieder das aktuelle Konstrukt über den Haufen werfen wollen um auf Schieberegister, Multiplexer oder I2C oder so zu setzen. Wenn ständig die Diskussionen neu aufgerollt werden kommt das Thema nie voran :-( Konrad S. schrieb: > Anfänger schrieb: >> die LEDs werden über asynchroner PWMs geschaltet > > ... was bei 100% aber nicht weiterhilft. > Die Stromversorgung muss auf das Maximum ausgelegt werden. Man könnt' > natürlich auf Software-Seite eine Begrenzung vorsehen. sollte denke ich als anmerkung dienen, dass an der Stelle keine 100% gefahren werden... natürlich sollte die Stromversorgung überdimensioniert sein Basti schrieb: > Genau und in so einen Tisch mit 250 W LED Leistung guckt man noch > gern > rein... > > Wie schon erwähnt, würde empfehlen nur mit 7 mA pro Farbe zu arbeiten... halte ich für sinnvoll, müsste man mal testen wie die leuchtkraft unter glas denn wirkt
Tim R. schrieb: > ich finds ja schön wenn sich immer neue Leute einbringen, aber warum > denn immer wieder das aktuelle Konstrukt über den Haufen werfen wollen > um auf Schieberegister, Multiplexer oder I2C oder so zu setzen. Wenn > ständig die Diskussionen neu aufgerollt werden kommt das Thema nie voran > :-( Ich weiß nicht was du am Ende pro Pixel zahlen möchtest. Aber mit 4x4 Panels und lokalem Multiplexing kommt man auf < 30ct / Pixel! Außerdem sinkt der Preis mit steigenden Stückzahlen und mit sinkendem Preis steigt die Beteiligung. Uart geht auch über USI, wenn 200kbps reichen. Ob man jetzt mit 7mA oder 20mA ansteuert macht übrigens kaum einen Unterschied. Außer dass man fehlende Helligkeit bei 7mA nicht mehr kompensieren kann - Dimmen kann man dagegen immer.
Tim R. schrieb: > ich finds ja schön wenn sich immer neue Leute einbringen, aber warum > denn immer wieder das aktuelle Konstrukt über den Haufen werfen wollen > um auf Schieberegister, Multiplexer oder I2C oder so zu setzen. Wenn > ständig die Diskussionen neu aufgerollt werden kommt das Thema nie voran > :-( Ich bin der Meinung, dass hier noch nicht festgelegt wurde. Mit Multiplex kann man mit geringem aufwand mehr LEDs ansteuern. Ohne das die µC mit mehr PWMs ausgestattet werden müssen. Auch ist SoftPWM nicht gerade Prozessorfreundlich. Um das ganze Chaos noch perfekter zu machen, noch ein weiterer Vorschlag Wir könnten ja auch einen TLC5940 verwenden. Dieser ist kaskadierbar, um alle LEDs anzusteuern. der µC benötigt nur ein PWM port. auch die IR Diode kann über hierüber angesteuuert werden, da dieser, wenn ich mich nicht irre 12bit PWM hat. Ebenfalls die DOT correction. macht alles sehr konfortabel. Im handel gibt es diese schon für 2€ das Stück. Bei entsprechender Menge natürlich günstiger. Bei Ebay habe ich schon 12 Stück für 10€ gekauft. Diese Dinger sind sehr leicht anzusteuern. Da hier alles über eine Stromsenke geregtl wird, kommen wir hier mit nur einen Widerstand aus. Toleranzen der einzelnen Widerstände (z.B. 5% bei einem, ergegeben 10% zwischen 2 Widerstand) entfallen hier. Das einzigste was man braucht sind analoge eingänge. Ein weiterer Vorteil an großen Platinen stelle ich mir gerade die Spannungsversorgung vor. Durch eventuelle Schaltreler kann die effizienz erhöht werden, Größere Spannungen realisiert werden (z.B. 12 -15V) ohne große Verlustleistung, und dadurch wieder geringeren Querschnitt der Zuleitung. Es gibt viele Wege, die alle ein Pro und kontra bedürfen. Jedoch gebe ich zu bedenken, das ein µc für eine LED sich langweilen wird und der Kosten Nutzen sehr klein ausfällt. in vielen beispielen im internet steuuert ein mC einen ganzen Tisch mit 100 x 100 Leds und IR. oder es werden Paltinen mit 8 LED und ein µC als einheit zusammengefasst. Das Anforderungsprofil steht ja schon, RGB LED(s) IR Sender + Emitter Kommunikation über 2-Wire / 3 Wire (welche Variante es wird ist nebensächlich, da dies "alle" µc Unterstützen. Das Realisierungskonzept gibt Fragen auf hier gibt es verschiedene Möglichkeiten A) - 1 RGB LED - 1 IR Sender - 1 IR Empfänger - 1 µC B) - 4x4 RGB LED Raster - 4 IR Sender - 4 IR Empfänger - 1 µC Vergleich Variante A <=> B Um mit Variante A die gleiche Pixelanzahl zu erreichen, benötigt man 16µC Ich würde mich freuen, wenn wir uns auf eine Variante festlegen
Ich denke man sollte mal einen Preis definieren... ich halte einen Euro pro Pixel für machbar.. ohne Netzteil... aber komplette Verkabelung + PCB + LEDs Also evtl 130 Euro für 100 Pixel, ohne mechanischen Aufbau... Wenn ihr weniger Preis-Leistung wollt, könntet ihr ja auch realisierte Lösungen nachbauen... es soll ja schon was "umwerfendes" werden, oder nicht?! Mit dem Ziel könnt ihr den Tiny pro Pixel gleich wieder einpacken... Was mir persönlich gefallen würde... @Sam natürlich macht der Strom einen Unterschied... nimmt man einfach WS2811 hat man nur 8 Bit und 20 mA... da fällt bis 7 mA wieder ein Bit weg... dann von 8 auf 7 Bit + gamma... da bleiben immer weniger Farbabstufungen übrig... @M.G. die TLC5940 sind auch schick, nur unter Umständen recht teuer... die Günstigere Alternative wäre wohl der von mir schon vorgeschlagene WS2803 IC... den bekommt man schon für 50 cent und der hat 18 Kanäle... also genau 6 RGB... die TLC haben glaube alle 16 Kanäle?! Da muss man wieder Multiplexen... aber dann passt der Preis vielleicht auch wieder... Als Ziel würde mir Pixelhardware gefallen die günstig und total doof ist... also nur Farbdaten per UART/SPI rein und hinten IR-Werte raus... TLC und WS2803 könnte man in Reihe zu einem µC ins SPI hängen... PCBs gibts ja hier fast geschenkt (Link zeigt eine Preisübersicht, ist nicht der Anbieter selbst): http://dangerousprototypes.com/2012/12/03/cost-breakdown-of-seeeds-pcb-service/
ok, dann lass ich euch mal diskutieren und warte einfach ab was rauskommt ;-)
Basti schrieb: > @Sam natürlich macht der Strom einen Unterschied... nimmt man einfach > WS2811 hat man nur 8 Bit und 20 mA... da fällt bis 7 mA wieder ein Bit > weg... dann von 8 auf 7 Bit + gamma... da bleiben immer weniger > Farbabstufungen übrig... Das ist natürlich klar. Aber ich würde auch auf mindestens 10-12bit gehen, da ist es nicht mehr tragisch. Ich bin immer noch dafür einen niedrigeren Preis anzupeilen. Dann kann man auch größere Matrizen mit dem gleichen Geld aufbauen (~200x200 für deinen angestrebten Preis). Mein Vorschlag: PCB: 15x15cm² oder 20x20cm² 2,50€ / 4€ µC : STM8S 0,40€ Treiber: SCT2xxx 0,25€ Leds: 16*0,02€ 0,32€ IR-Leds: 16*0,03€ 0,48€ Fotodioden: 16*0,02€ 0,32€ Hühnerfutter: 0,10€ 4,37€ // 26cent / Pixel. Der µC muss dafür natürlich 16*Softpwm über das Schieberegister bei entsprechender Auflösung schaffen. Ich denke das ist durchaus möglich wenn man phasenversetzte PWM-Signale nutzt. Der µC muss die Signale so verschieben dass er immer genug Zeit hat das Schieberegister nachzuladen. Das interne Latch des Schieberegisters kann über ein PWM-Signal vom µC jitterfrei gesteuert werden. Ich werde das mal mit normalen Schieberegistern testen. Alternativ gibt es Bit-Angle-Modulation. Damit ist sind 12bit einfach machbar. Dabei ist es ziemlich egal wie lange es dauert das Schieberegister zu befüllen. Die Länge der einzelnen Phasen steuert man über CS.
Sam .. schrieb: > Uart geht auch über USI Aber nicht vollduplex! Damit einen funktionierenden Ring aufbauen? Viel Vergnügen!
M. G. schrieb: > B) > - 4x4 RGB LED Raster > - 4 IR Sender > - 4 IR Empfänger > - 1 µC Zu wenig IR-Sender und IR-Empfänger. Treiber für LED-Kanäle?
ich lese die ganze zeit nur "billig billig billig".. ist ja schon wie in der industrie ;-) 200x200 pixeln á 5cm = 1000x1000cm? ist das jetzt ernst gemeint oder troll? Konrad S. schrieb: > Sam .. schrieb: >> Uart geht auch über USI > > Aber nicht vollduplex! > Damit einen funktionierenden Ring aufbauen? Viel Vergnügen! du scheinst etwas abgeneigt von den überlgeungen ? :-)
Angehängte Dateien:
-
Unbenannt.png
1,1 KB
Konrad S. schrieb: > M. G. schrieb: >> B) >> - 4x4 RGB LED Raster >> - 4 IR Sender >> - 4 IR Empfänger >> - 1 µC > > Zu wenig IR-Sender und IR-Empfänger. Treiber für LED-Kanäle? Die IR Sender habe in etwa so geplant (siehe Bild) Sollte doch reichen, oder? habt Ihr mehr geplant? ICh habe mir vorgestellt, dass eine IR LED 4 RGB LEDs ansteuert. Je nachdem ob die benachbarte IR auch angesteuert wurde, ändert sich der Farbverlauf. also jede IR agiert mit seinem Nachbarn Ja, die Treiber habe ich vergessen, Sorry. Je nachdem. wenn man Geld sparen will, kommt man nur mit Charlieplexing aus, um solch eine Matrix zu realisieren.
Tim R. schrieb: > 200x200 pixeln á 5cm = 1000x1000cm? ist das jetzt ernst gemeint oder > troll? Ich meinte 20x20. Und ich denke dass man mit einem guten und nicht überstürzten Konzept nichts falsch macht. Und wenn eine (3x) günstigere Lösung keine nennenswerten Nachteile hat, was spricht dann dagegen? Ich habe für die Preiskalkulation mit 100 Panels á 16 Pixel gerechnet. > Konrad S. schrieb: >> Sam .. schrieb: >>> Uart geht auch über USI >> >> Aber nicht vollduplex! >> Damit einen funktionierenden Ring aufbauen? Viel Vergnügen! > > du scheinst etwas abgeneigt von den überlgeungen ? :-) Wo ist denn das Problem? Der Master muss nur nach x Byte eine Pause einlegen. Abgesehen davon ist der STM8S geeigneter. M. G. schrieb: > Die IR Sender habe in etwa so geplant (siehe Bild) Das Problem dabei ist, dass die Panels sich gegenseitig stören könnten wenn keine Trennwände dazwischen sind. Und wenn man überall Trennwände platziert funktioniert dieses System nicht mehr.
:
Bearbeitet durch User
Tim R. schrieb: > du scheinst etwas abgeneigt von den überlgeungen ? :-) Nein, nicht abgeneigt, das trifft es nicht. Aber manches bisher vorgeschlagene ist, wirft man einen Blick auf die technischen Daten, schlichtweg Unfug, zumindest im Kontext dieses Threads. Da kann man nur den Ball immer wieder zurückspielen bis die Erkenntnis kommt, dass es so nicht funktionieren kann. Ach ja: evtl. wären für die Hardware zwei Threads sinnvoll, einer für Ein-Pixel-Platinen, einer für Mehr-Pixel-Platinen.
Sam .. schrieb: > Das Problem dabei ist, dass die Panels sich gegenseitig stören könnten http://www.youtube.com/watch?v=K4HRXa-GxIk Hier stört sich doch auch nichts > wenn keine Trennwände dazwischen sind. Und wenn man überall Trennwände > platziert funktioniert dieses System nicht mehr. ja, das stimmt, dann würdest du für jede LED eine eigene IR verwenden? Dann müsste man ja schon diesen hier nehmen. http://www.st.com/web/catalog/mmc/FM141/SC1244/SS1010/LN1571/PF246071 der hat 16x ADC. aber auch LQFP80
M. G. schrieb: > Die IR Sender habe in etwa so geplant Den Versuchen Karol Babiochs zufolge würde das wohl eher nicht funktionieren. Das solltest du mal testen und dann vorstellen.
Sam .. schrieb: > Wo ist denn das Problem? Der Master muss nur nach x Byte eine Pause > einlegen. Wie lang muss denn die Pause sein, damit es beim hundertsten Pixel noch zuverlässig mit dem Timing klappt. Willst du die Bytes einzeln weitergeben oder als Block pro Pixel? > Abgesehen davon ist der STM8S geeigneter. Klar, der muss es auch nicht mit so einem USI-Gewürge machen. Fast jeder µC ist geeigneter als ein ATtiny24.
Konrad S. schrieb: > > Ach ja: evtl. wären für die Hardware zwei Threads sinnvoll, einer für > Ein-Pixel-Platinen, einer für Mehr-Pixel-Platinen. sehr gute idee! Konrad S. schrieb: > M. G. schrieb: >> Die IR Sender habe in etwa so geplant > > Den Versuchen Karol Babiochs zufolge würde das wohl eher nicht > funktionieren. Das solltest du mal testen und dann vorstellen. wo ist karol babioch eigtl abgeblieben
M. G. schrieb: > ja, das stimmt, dann würdest du für jede LED eine eigene IR verwenden? > > Dann müsste man ja schon diesen hier nehmen. > http://www.st.com/web/catalog/mmc/FM141/SC1244/SS1010/LN1571/PF246071 > der hat 16x ADC. aber auch LQFP80 Die Fotodioden würde ich ebenfalls mindestens 4x4 multiplexen. Als µC würde der STM8S003F3 reichen: http://www.st.com/web/catalog/mmc/FM141/SC1244/SS1010/LN2/PF251792 Konrad S. schrieb: > Welche LEDs hast du im Sinn? Evtl. mit Link? Beitrag "Re: LED Tisch mit Berührungs-/Gegenstandserkennung"
:
Bearbeitet durch User
Sam .. schrieb: > Konrad S. schrieb: >> Welche LEDs hast du im Sinn? Evtl. mit Link? > > Beitrag "Re: LED Tisch mit Berührungs-/Gegenstandserkennung" Ah ja, danke. Ich habe im Artikel mal einen Abschnitt "Bauteil-Kandidaten" eingefügt: RGB Touch Matrix: Bauteil-Kandidaten So gehen uns solche Informationen nicht verloren.
> Ein Problem mit unregelmässiger Refreshrate gibt es hier nicht, da alle > Slaves beim letzten RGB-Wert bleiben und weiterleuchten, nur die > Aktualisierung "stockt" für eine 35stel Sekunde, das ist nicht > wahrnehmbar. Bei flüssigen Animationen ist das leider doch wahrnehmbar. Gerade bei solchen großen Pixeln. Ich habe das leider schon feststellen müssen. Das ruckeln kann das Auge feststellen. Ich würde eher die Datenrate erhöhen.
Ich habe die phasenversetzte Soft-PWM theoretisch getestet. Es ist möglich mit Schieberegister PWM-Signale mit voller Auflösung zu erzeugen. Alleine die PWM-Frequenz darf nicht zu hoch werden, wobei 1kHz kein Problem sind. Die Berechnung der Werte dauert zwischen ~50k Zyklen (beim Avr), aber da ist sicher noch Optimierungspotential. Der Ramverbrauch ist leider recht hoch: 10 Byte / PWM-Signal (4x4 Matrix -> 480B, 5x5 -> 750B - für den STM8S würde es noch reichen). Bit-Angle-Modulation ist sicher das einfachere Verfahren und wenn nichts dagegen spricht würde ich es auch das bevorzugen. Es wird auch reaktionsschneller sein. Mit beiden Verfahren sind 15bit bei 400Hz @ 16Mhz Takt möglich.
:
Bearbeitet durch User
Guter Witz... die kleinste Blank Zeit ist dann 1,2 Clock... In der Zeit bekommt man wohl keinen PIN an und aus... jedenfalls nicht mit Software Bleiben wir mal realistisch... 12 Bit sollten auch reichen... Eingangs werden wohl 8 Bit pro Farbe eintreffen...
Kein Witz. Beide verfahren haben einen gewissen overhead. Ein pwm Zyklus dauert da ein bisschen länger als 2^auflösung. Und das latch des Schieberegister lässt sich über einen pwm pin Zyklengenau steuern.
:
Bearbeitet durch User
Tim R. schrieb: > wo ist karol babioch eigtl abgeblieben Vielleicht hat er einfach die Nase voll. Könnte ich jedenfalls absolut nachvollziehen. Fast jeden Tag sind es neue Leute, die sich einschalten, OHNE vorher den Thread gelesen zu haben. Auch scheinen die Leute hier geteilter Meinung zu sein, was der LED-Tisch eigentlich werden soll. Die ursprüngliche Idee war eine Matrix mit Trennwänden aus 10x20 Rechtecken mit einer (Plexi-)Glasplatte darüber. Jetzt tauchen plötzlich Vidoes/Vorschläge auf mit (einfarbigen!) LEDs, die wild auf einer Platte verteilt sind und man da mit der flachen Hand drüber fahren kann und dabei leuchten. Das sind leider zwei vollkommen verschiedene Projekte. Auch die Wahl der µCs wird plötzlich wieder neu aufgerollt... usw. usw. Leute, lest den Thread von Anfang an! Wenn jemand was anderes bauen will, sollte er besser einen neuen Thread aufmachen. Auch braucht dieser Thread eine verantwortliche Person, welche den dazugehörenden Artikel ständig pflegt und auf dem aktuellen Stand hält. Dabei sollte er hier auch regelmäßig den Link auf den Artikel posten, damit Neueinsteiger direkt erkennen, um was es denn hier überhaupt geht.... Gruß, Frank, der sich hier auch nicht mehr beteiligen möchte, weil alle durcheinander plappern.
Frank M. schrieb: > Vielleicht hat er einfach die Nase voll. Könnte ich jedenfalls absolut > nachvollziehen. Fast jeden Tag sind es neue Leute, die sich einschalten, > OHNE vorher den Thread gelesen zu haben. ist ja das was ich hier angeschrieben hatte > > Auch scheinen die Leute hier geteilter Meinung zu sein, was der > LED-Tisch eigentlich werden soll. Die ursprüngliche Idee war eine Matrix > mit Trennwänden aus 10x20 Rechtecken mit einer (Plexi-)Glasplatte > darüber. Jetzt tauchen plötzlich Vidoes/Vorschläge auf mit > (einfarbigen!) LEDs, die wild auf einer Platte verteilt sind und man da > mit der flachen Hand drüber fahren kann und dabei leuchten. Das sind > leider zwei vollkommen verschiedene Projekte. > > Auch die Wahl der µCs wird plötzlich wieder neu aufgerollt... usw. usw. ! > > Leute, lest den Thread von Anfang an! Wenn jemand was anderes bauen > will, sollte er besser einen neuen Thread aufmachen. ! > > Auch braucht dieser Thread eine verantwortliche Person, welche den > dazugehörenden Artikel ständig pflegt und auf dem aktuellen Stand hält. > Dabei sollte er hier auch regelmäßig den Link auf den Artikel posten, > damit Neueinsteiger direkt erkennen, um was es denn hier überhaupt > geht.... > ich werde versuchen sobald ich zeit habe das aufzurollen damit wir hier schritt für schritt nachvollziehbar weiter machen können ! :-) ein neuer thread wird wohl die einfachste lösung
für alle die weiterhin Interesse an einer Pixellösung haben, ich habe hierzu einen neuen Thread gestartet und hoffe, dass es dort etwas besser läuft ! ;-) Beitrag "Projektidee RGB Pixel mit Touch"
Hey dein Beitrag ist zwar etwas älter. Wenn du jedoch nochmal eine Antwort zu deiner Frage brauchst, dann guck doch mal hier auf der Seite nach da findest du Video anleitungen dazu. Habe mich daran auch orientiert. http://ledtisch-test.de/ Mit freundlichen Grüßen Alex
Hi Wenn schon, dann bitte den Link auf die 'Selber bauen'-Seite. Die Start-Seite liest sich mehr nach 'kanne kaufä' http://ledtisch-test.de/led-tisch-selber-bauen Naja, keine 3 Jahre, noch nicht mal richtig trocken, der Kleine ;)
Thread beobachten
Seitenaufteilung abschalten
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.