Hallo allerseits, ich bin momentan ein wenig am überlegen, ob ich eine Blitzidee von mir einfach mal umsetze. Vorweg: Ich habe Erfahrung mit Mikrocontrollern, Programmierung etc.... zwar etwas eingerostet, aber das sollte reaktivierbar sein :) Ich möchte gerne einen Tisch (ca. 1m x 2m) mit einer (Milch)Glasplatte mit LEDs bzw. RGBs versehen um einen schönen Leuchteffekt zu erhalten. Das ist soweit relativ einfach. Zusätzlich möchte ich aber eine Erkennung/Sensorik, ob beispielsweise eine Hand oder ein Glas auf dem Tisch steht, um diese Stelle andersfarbig leuchten zu lassen. Mich würde interessieren, ob jemand Ideen hat, wie man relativ zuverlässig solch eine Erkennung durchführen kann bzw was gibt es für relevante Sensoriken?! Ich habe an Fotowiderstände oder Berührungssensoren gedacht. Bei denen bräuchte man nur eine ganze Menge oder? Im Internet habe ich nur vereinzelte Themen gesehen wie diesen: http://www.mikrocontroller.net/topic/326455 der leider wohl gelöscht wurde :( Thema: "Gegenstands-Erkennung für RGB-LED-Table - Mikrocontroller.net" Danke schon mal für alle konstruktiven Antworten
...warum wurde denn der andere Thread gelöscht? Verstehe ich nicht... Grüße Markus
die käuflichen Versionen machen das mit infrarot Reflex Lichtschranken... (ist kein michlglas) suche mal nach: interaktiver led tisch Ich denke das müsste über ein Kapazitiven Sensor gehen.
...wurde ja in dem anderen Thread schon alles besprochen: - Fertigen Infrarot Proximity Sensor nehmen (Nachteil: ca. 2,50 EUR pro Sensor) - Selbst mit IR-LED und Photodiode/Transistor etwas ähnliches bauen - Kapazitiv (Nachteil: Drähte o.ä. notwendig
Markus M. schrieb: > ...wurde ja in dem anderen Thread schon alles besprochen: > > - Fertigen Infrarot Proximity Sensor nehmen (Nachteil: ca. 2,50 EUR pro > Sensor) > > - Selbst mit IR-LED und Photodiode/Transistor etwas ähnliches bauen > > - Kapazitiv (Nachteil: Drähte o.ä. notwendig wie beschrieben, konnte ich den anderen Thread leider nicht ansehen, aber danke schonmal für die Infos!
Also der Threadersteller des gelöschten Threads hatte noch viele IR-LEDs und Photodioden zu liegen und wollte sie verwenden. Der Gedanke war: - die IR-LEDs zu modulieren (um das Umgebungslicht zu unterdrücken) - die Änderungen der Spannung an der Photodiode zu Verstärken und über einen Analogmultiplexer auf den A/D-Wandler eines µC zu geben - aus Änderungen in der Amplitude des Signals müsste sich dann erkennen lassen, ob sich etwas an der Reflexion für dieses Quadrat geändert hat (Gegenstand auf dem Tisch) So die Theorie. Mit fertigen Näherungssensoren ist es noch einfacher, diese beinhalten schon eine gewisse Intelligenz, lassen sich teileise sogar noch über I²C programmieren (Empfindlichkeit etc.), kosten aber eben mehr, im Bereich 2-3 EUR / Stück. Man müsste das ganze mal in einem Testaufbau verifizieren inwieweit die einzelnen Möglichkeiten überhaupt funktionieren für den gegebenen Aufbau der Oberfläche (Glas, milchig), da habe ich keine Ahnung.
:
Bearbeitet durch User
Markus M. schrieb: > Also der Threadersteller des gelöschten Threads hatte noch viele IR-LEDs > und Photodioden zu liegen und wollte sie verwenden. > > Der Gedanke war: > > - die IR-LEDs zu modulieren (um das Umgebungslicht zu unterdrücken) > - die Änderungen der Spannung an der Photodiode zu Verstärken und über > einen Analogmultiplexer auf den A/D-Wandler eines µC zu geben > - aus Änderungen in der Amplitude des Signals müsste sich dann erkennen > lassen, ob sich etwas an der Reflexion für dieses Quadrat geändert hat > (Gegenstand auf dem Tisch) > > So die Theorie. theorie ist immer gut hehe... wie gut die dioden im endeffekt waren weiß niemand ? :) > > Mit fertigen Näherungssensoren ist es noch einfacher, diese beinhalten > schon eine gewisse Intelligenz, lassen sich teileise sogar noch über I²C > programmieren (Empfindlichkeit etc.), kosten aber eben mehr, im Bereich > 2-3 EUR / Stück. in einer fixen suche bin ich nur auf sau teure sensoren gestoßen, hat jemand mal einen link? ich glaub ich habe an der falschen stelle gesucht > > Man müsste das ganze mal in einem Testaufbau verifizieren inwieweit die > einzelnen Möglichkeiten überhaupt funktionieren für den gegebenen Aufbau > der Oberfläche (Glas, milchig), da habe ich keine Ahnung. ja das wäre sehr interessant zu wissen
Habe mal bei Digikey geschaut, interessant waren die Sensoren von: TAOS (TSLxxxx), z.B. TSL26711FN: - Infrarot - Programmierbar über I²C - inkl. Konstantstromquelle für die IR-LED - Anzahl Pulse einstellbar etc. - "Interrupt" Ausgang signalisiert Annäherung - Preis: DK 0,50€ für 3000 Stk :-), Mouser ca. 0,80€, keine Mindestbestellmenge. - Gibt noch andere Serien, z.B. TSL2771, noch empfindlicher, 1,10€ ab 100 Stk. Weitere ähnliche Sensoren: - Avago APDS-9120, Sender und Empfänger integriert, Preis/Stk: 1,69€ (RS, ab 10) - IS31SE5001 (schlecht verfügbar) - Si1102, Preis/Stk: 2,34€ (RS) - IS471F, Preis/Stk: 2,64€ (RS, ab 100), einziger bedrahteter Sensor Wenn man den ganzen Aufwand nimmt, dürfte ab einer bestimmten Stückzahl ein fertiger Sensor günstiger sein... man bedenke auch, dass man hunderte davon einlöten/bestücken muss...
:
Bearbeitet durch User
Ich muss mich hier auch mal als RGB-Table-Fan outen ;-) Bei meiner Planung bin ich auf folgende Kombination gestoßen: IR-LED "SFH 409", 0,15€ IR-Empfänger "TSOP31238", 0,66€ Kommt also zusammen auf 0,81€ pro Pixel. Der Empfänger arbeitet auf 38khz, wenn man die LED also entsprechend moduliert, sollte das ganze sich nicht durch Umgebungslicht stören lassen. (Die Wellenlängen habe ich bei der Auswahl der Komponenten nicht berücksichtigt, da müsste man also nochmal schauen, dass die LED auch wirklich zum Empfänger passt) Was meint ihr? Könnte das hinhauen? Wäre auf jeden Fall eine schön günstige Lösung.
Markus M. schrieb: > > Wenn man den ganzen Aufwand nimmt, dürfte ab einer bestimmten Stückzahl > ein fertiger Sensor günstiger sein... man bedenke auch, dass man > hunderte davon einlöten/bestücken muss... danke für deine Mühe... ich stehe jetzt nur gerade etwas auf dem Schlauch, was du mit fertig Sensor genau meinst? aber ich muss gestehen bin grad frisch von Arbeit gekommen, muss am we erstmal die ganzen Daten/Bauteile auswerten die hier zusammengetragen wurden Boris P. schrieb: > Ich muss mich hier auch mal als RGB-Table-Fan outen ;-) > > Bei meiner Planung bin ich auf folgende Kombination gestoßen: > > IR-LED "SFH 409", 0,15€ > IR-Empfänger "TSOP31238", 0,66€ > > Kommt also zusammen auf 0,81€ pro Pixel. Der Empfänger arbeitet auf > 38khz, wenn man die LED also entsprechend moduliert, sollte das ganze > sich nicht durch Umgebungslicht stören lassen. > (Die Wellenlängen habe ich bei der Auswahl der Komponenten nicht > berücksichtigt, da müsste man also nochmal schauen, dass die LED auch > wirklich zum Empfänger passt) > > Was meint ihr? Könnte das hinhauen? > Wäre auf jeden Fall eine schön günstige Lösung. schön einen weiteren Fan gefunden zu haben hehe die Kombination ist wirklich günstig! hierzu sollte aber erst ein kurzer Test durchgeführt werden, ob das ganze auch dementsprecht zusammen funktioniert. Meine größte Sorge ist immernoch, wie sich das ganze Verhalten mit (Plexi-)Glas auswirkt. Glaube hier müsste ich selber mal eine kleine Testreihe starten oder gibt es hierzu schon Videos oder ähnliches die sehr aussagend sind ? :-) für alle die es nicht kennen: ich habe gestern einen interessanten Link gefunden http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html
Hatte unter meinem RGB Tisch mal 4 DMS getestet... Ging ganz gut, hab es aber nicht weiter verfolgt... Das Problem ist, kein Multitouch und herausfiltern von Querverspannungen bzw. eine gute mechanische Umsetzung ;) Dafür kannst du natürlich reale Gewichte auflösen und sagen: oh, großer Schluck... du bist aber durstig ;) Hab auch nen kleines YouTube Video das den Touch kurz demonstriert: SFCounterfeiter dort mein Name... Link mit Handy suchen, is immer so unpraktisch ;) Grüße Basti
Tim R. schrieb: > schön einen weiteren Fan gefunden zu haben hehe Ich hoffe am Ende dieses Threads hat jeder von uns so einen RGB-Tisch zuhause stehen ;-) Tim R. schrieb: > die Kombination ist wirklich günstig! hierzu sollte aber erst ein kurzer > Test durchgeführt werden, ob das ganze auch dementsprecht zusammen > funktioniert. Meine größte Sorge ist immernoch, wie sich das ganze > Verhalten mit (Plexi-)Glas auswirkt. Laut Datenblatt passen die beiden zusammen (950nm Wellenlänge). Wäre noch zu testen, wie sich das in der Praxis verhält (Reflektionen am Plexiglas?). Aber bei dem Herrn aus deinem Link hat es ja genau so funktioniert... Tim R. schrieb: > Glaube hier müsste ich selber mal eine kleine Testreihe starten Ist halt nur immer blöd so ein paar einzelne Teile zu bestellen. Oder hast du einen Conrad um die Ecke? Wie sieht es eigentlich mit den anderen Komponenten aus? Werden die hier auch disktutiert? (Logik der Knoten, Bus, Controller & Ansteuerung, Stromversorgung usw.) Ggf. könnte man ja eine Projektseite im Wiki starten? Oder den Thread zu den Projekten verschieben?
Basti schrieb: > Hatte unter meinem RGB Tisch mal 4 DMS getestet... > > > Ging ganz gut, hab es aber nicht weiter verfolgt... > Das Problem ist, kein Multitouch und herausfiltern von Querverspannungen > bzw. eine gute mechanische Umsetzung ;) > > Dafür kannst du natürlich reale Gewichte auflösen und sagen: oh, großer > Schluck... du bist aber durstig ;) > > Hab auch nen kleines YouTube Video das den Touch kurz demonstriert: > SFCounterfeiter dort mein Name... Link mit Handy suchen, is immer so > unpraktisch ;) > > Grüße > > Basti netter tisch, finde das design auch relativ modern gehalten, aber schicht und gut :) die größe geht in ordnung, viel größer würde ich auch nicht gehen wollen. verrätst du deine technik dahinter? also das projekt nimmt natürlich viel zeit und kosten in anspruch, sodass erst in ein paar wochen/monaten ergebnisse sichtbar werden. Das ganze neben der arbeit machen, macht es nicht unbedingt leichter gg also das direkt zu den projekten schieben würde ich nicht aber an sich generell die ansteuerung, versorgung etc. kann hier gerne besprochen werden
Naja, zu der Auswertung der Sensoren hatten wir uns auch schon Gedanken gemacht. Für die Beleuchtungs-LEDs könnte man der Einfachheit halber einfach die WS2812B nehmen. Um die Werte der Sensoren abzufragen, könnte man entweder mehrere ATtinys per SPI koppeln, oder die Werte per Multiplexer abfragen. Mit 8x 8-Bit Muitiplexern könnte man schon 256 Eingänge abfragen (8 oder 16 I/O-Pins am Controller vorausgesetzt). Analogmultiplexer sind auch nicht viel teurer, falls man mit Analogen Werten und A/D-Wandler arbeiten muss. Eine andere Überlegung war auch für jeden Pixel einen kleinen ATtiny zu nehmen, der die IR-LED steuert und die Photodiode auswertet und man die Ergebnisse irgendwie per SPI Daisy-Chain dann abfragt... wobei wahrscheinlich die Implementierung dieses Pixelsensors dann schon ein eigenes Projekt wird...
Markus M. schrieb: > Naja, zu der Auswertung der Sensoren hatten wir uns auch schon Gedanken > gemacht. > > Für die Beleuchtungs-LEDs könnte man der Einfachheit halber einfach die > WS2812B nehmen. > > Um die Werte der Sensoren abzufragen, könnte man entweder mehrere > ATtinys per SPI koppeln, oder die Werte per Multiplexer abfragen. > > Mit 8x 8-Bit Muitiplexern könnte man schon 256 Eingänge abfragen (8 oder > 16 I/O-Pins am Controller vorausgesetzt). > > Analogmultiplexer sind auch nicht viel teurer, falls man mit Analogen > Werten und A/D-Wandler arbeiten muss. > > Eine andere Überlegung war auch für jeden Pixel einen kleinen ATtiny zu > nehmen, der die IR-LED steuert und die Photodiode auswertet und man die > Ergebnisse irgendwie per SPI Daisy-Chain dann abfragt... wobei > wahrscheinlich die Implementierung dieses Pixelsensors dann schon ein > eigenes Projekt wird... die WS2812B sind ja interessant, kenn ich auch noch nicht. wenn ich das richtig gesehen habe brauchen die eine versorgungsspannung und eine datenleitung, wo der spezifikation entsprechend die daten in den korrekten zeiten gesendet werden um eine farbe zu erhalten, ist das richtig?! an multiplexen hatte ich zu aller erst gedacht. einzige problem wäre glaube ich nur ein mehraufwand der verkabelung du meinst also kleine platinen für jeden pixel entwerfen? ich glaube der bastler in dem link den ich gepostet habe, hatte es genau so gemacht... man hätte dann zig kleine platinen mit jeweils sensor und led drauf... puh das würde eine ganz schöne arbeit mit sich ziehen
Boris P. schrieb: > > Ist halt nur immer blöd so ein paar einzelne Teile zu bestellen. Oder > hast du einen Conrad um die Ecke? > und ja... ich habe in berlin gleich drei conrad läden, wenn ich es richtig in erinnerung habe ;)
...ja, die WS2812(B) sind schon sehr cool, nur die Ansteuerung ist nicht trivial, aber es gibt inzwischen viele Libraries dafür. Man kann sie praktisch als Kette direkt zusammenhängen und jede LED reicht dann die Daten an die nächste weiter, nachdem sie "ihre" Daten empfangen hat. Ich habe mir jetzt mal bei RS diesen Avago Näherungssensor APDS-9120 bestellt zum probieren. Der hat sowohl die IR-LED als auch den Empfänger gleich eingebaut. D.h. man benötigt keine weiteren externen Komponenten für die Näherungserkennung. Mal sehen ob er tut... Grüße Markus
Markus M. schrieb: > ...ja, die WS2812(B) sind schon sehr cool, nur die Ansteuerung ist nicht > trivial, aber es gibt inzwischen viele Libraries dafür. > > Man kann sie praktisch als Kette direkt zusammenhängen und jede LED > reicht dann die Daten an die nächste weiter, nachdem sie "ihre" Daten > empfangen hat. > > Ich habe mir jetzt mal bei RS diesen Avago Näherungssensor APDS-9120 > bestellt zum probieren. > > Der hat sowohl die IR-LED als auch den Empfänger gleich eingebaut. D.h. > man benötigt keine weiteren externen Komponenten für die > Näherungserkennung. > > Mal sehen ob er tut... > > Grüße > Markus klasse deine schnellen antworten! versteh ich das richtig, dass du solch ein projekt ebenfalls umsetzen magst?! das kam hier bisher gar nicht zum ausdruck aber super, dann warte ich einfach mal deine ergebnisse ab. besteht die möglichkeit zum testen mit glas/plexiglas? grüße tim
Hui, die sind aber saftig teuer. Für das Geld lässt sich ja schon die komplette Pixel-Platine inkl. µC, RGB-LED, Sensoren und Perepherie umsetzen. Ich finde auch die Lösung mit intelligenten Pixeln am sinnvollsten. Dann reicht eine einzige Datenleitung als Bus, um die Farbinformationen und die Sensordaten bidirektional zu übertragen. Der Verkabelungsaufand ist zudem minimal.
Also für einen konkretes Tischprojekt fehlt mir ehrlich gesagt momentan die Zeit und das Kleingeld. Aber ich finde die Sensoren interessant, deswegen mache ich jetzt mal einen Konzepttest ob das überhaupt so funktionieren kann. Allerdings habe ich keine genaue Ahnung wie sich Milch(Plexi)glas auswirkt, also ob es damit überhaupt noch funktioniert. Mit klarem Glas bzw. ohne jegliche Mattierung wolltest Du das doch nicht machen nehme ich ma an?
Hallo, danke für die Blumen... die Frge ist ja weniger, wie habe ichs gebaut... sondern, wie würde ich es heute bauen ;) Also WS2812 ist schnell und sinnvoll. Leider sind die sehr hell für einen Tisch und beim Dimmen fehlt die Dynamik! Würde hier 16 Bit PWM Treiber der Chinesen verbauen -> MySemi! Ansonsten habe ich 4 DMS aus jeweils einer Ebay ramsch Küchenwaage geholt ud fix und fertig DMS ICs mit 24 Bit Auflösung von TI gesampelt... brauchbar waren davon immerhin 17 Bit und das hat für 0,25 Gramm gereicht ;) Die Mechanik muss so gestaltet sein, dass es absolut Spannungsfrei arbeitet -> sehr schwieirg... Elektrisch gesehen, ist es eher kein Kunstwerk... je nach Erfahrung... also Waagen und DMS Platinen plus Bauteile: 40€... Auflösung definitiv viel höher als es deine Matrix sein wird ;) Viel Erfolg! Und macht euch mit IR nicht arm :D Grüße Basti
Und das ganze irgendwie mit Ultraschall maschen? An mehreren Stellen Ultraschall ins Glas schicken bzw. detektieren und über die geänderte Dämpfung oder über Reflektionen auf die berührte Stelle schleissen. Es gibt ja auch robuste Touchdisplay, die mit sowas arbeiten. Sabine
Klingt auch interessant, nur ist das für den Hobbisten sicher nicht so einfach umsetzbar... Mechanisch gesehen... Signalaufbereitung sicher auch nicht ohne
Basti schrieb: > Klingt auch interessant, nur ist das für den Hobbisten sicher nicht so > einfach umsetzbar... Mechanisch gesehen... Signalaufbereitung sicher > auch nicht ohne Und spätestens bei Multitouch wirds dann ganz schön haarig. Und gerade das würde bei so einem Tisch ja richtig gut kommen.
http://shop.led-studien.de/de/elektronik-bausatze/led-pixel/rgb-pixel-50x50mm-inkl.-wannen-kabel rein für die beleuchtung könnte man alternativ auch fertige pixel platinchen verwenden. der nachteil wäre nur, dass die sensorik für die touch funktionalität noch irgendwie extra behandelt werden müsste hehe und beim suchen bin ich auf ein forenbeitrag gestoßen, wo jemand gerade frisch anfängt einen tisch zu bauen ! http://www.ledhilfe.de/viewtopic.php?f=35&t=18413
:
Bearbeitet durch User
Boris P. schrieb: > Hui, die sind aber saftig teuer. Für das Geld lässt sich ja schon die > komplette Pixel-Platine inkl. µC, RGB-LED, Sensoren und Perepherie > umsetzen. > > Ich finde auch die Lösung mit intelligenten Pixeln am sinnvollsten. Dann > reicht eine einzige Datenleitung als Bus, um die Farbinformationen und > die Sensordaten bidirektional zu übertragen. Der Verkabelungsaufand ist > zudem minimal. ich stimme dir zu. pixelplatinen bringe vorteile, wie schnelle austauschbarkeit und erweiterbarkeit mit sich willst du auf diese platinen jeweils einen controller verbauen?! oder einen zentralen uC ? ich frage mich nur gerade, wie du über eine leitung die farbinformation vom uC zur rgb und die sensor information zum uC tragen willst. quasi im polling den portpin von umschalten?
Tim R. schrieb: > willst du auf diese platinen jeweils einen controller verbauen?! oder > einen zentralen uC ? > ich frage mich nur gerade, wie du über eine leitung die farbinformation > vom uC zur rgb und die sensor information zum uC tragen willst. quasi im > polling den portpin von umschalten? Ich habe vor auf jeden Pixel einen Controller zu setzen. Ein ATTinyXX eignet sich vermutlich am besten. Diese gibts bei geschickter auswahl schon ab 0,40€ das Stück. Als "Master" schwebt mir ein Beaglebone Black vor. Der ist über LAN/WLAN/Bluetooth super von außen zu erreichen und kann auch komplexe Programme laufen lassen (animierte Fraktale auf den Tisch rendern usw.). Zusätzlich ist er klein, lüfterlos, verbraucht wenig Strom und kostet nicht viel. Für den Bus würde ich eine Art I2C nehmen. Also nur zwei dünne Leitungen. Bidirektionale Kommunikation sollte damit recht leicht gehen: Richtung 1: Master sendet Adress-Byte gefolgt von 3 Datenbytes (RGB). Der Slave mit der passenden Adresse übernimmt die Daten und lässt seine LED entsprechend leuchten. Richtung 2: Master sendet nur die Adresse. Danach wartet er ein Bit lang, und lauscht auf dem Bus. Der Slave mit der entsprechenden Adresse nutzt diese Pause, um eine 1 oder 0 auf den Bus zu legen (Touch oder kein Touch). Der Master liest das Bit, und fragt dann den nächsten Slave. Der Beaglebone Black hat übrigens noch zwei Realtime-Co-Prozessoren, über die sich so eine Kommunikation mühelos erledigen lässt (5ns Zykluszeit). Damit sollten gute 50Hz (RGB Daten + Touch Daten Übertragung) machbar sein. PS: Je nach Anzahl der Pixel sollte man den Tisch vielleicht aufteilen, so dass der Master nur jede Zeile anspricht. In jeder Zeile spricht dann wiederrum der erste Controller mit allen anderen Controllern in der Zeile. So lassen sich probleme mit Spannungsverlusten bei langer Leitungslänge vermeiden und die Datenrate erhöhen.
:
Bearbeitet durch User
Boris P. schrieb: > Tim R. schrieb: >> willst du auf diese platinen jeweils einen controller verbauen?! oder >> einen zentralen uC ? >> ich frage mich nur gerade, wie du über eine leitung die farbinformation >> vom uC zur rgb und die sensor information zum uC tragen willst. quasi im >> polling den portpin von umschalten? > > Ich habe vor auf jeden Pixel einen Controller zu setzen. Ein ATTinyXX > eignet sich vermutlich am besten. Diese gibts bei geschickter auswahl > schon ab 0,40€ das Stück. > > Als "Master" schwebt mir ein Beaglebone Black vor. Der ist über > LAN/WLAN/Bluetooth super von außen zu erreichen und kann auch komplexe > Programme laufen lassen (animierte Fraktale auf den Tisch rendern usw.). > Zusätzlich ist er klein, lüfterlos, verbraucht wenig Strom und kostet > nicht viel. von den beagleboards habe ich schon gehört/gelesen, scheint ja aller hand positive aspekte mit sich zu bringen solch ein board. mein problem ist der dortige arm prozessor. ich bin atmel und microchip gewöhnter. ich habe quasi null ahnung von arm und würde mir an dieser stelle unnötige probleme vermeiden wollen. aber ansonsten eine nette auswahl! > > Für den Bus würde ich eine Art I2C nehmen. Also nur zwei dünne > Leitungen. Bidirektionale Kommunikation sollte damit recht leicht gehen: > > Richtung 1: Master sendet Adress-Byte gefolgt von 3 Datenbytes (RGB). > Der Slave mit der passenden Adresse übernimmt die Daten und lässt seine > LED entsprechend leuchten. > > Richtung 2: Master sendet nur die Adresse. Danach wartet er ein Bit > lang, und lauscht auf dem Bus. Der Slave mit der entsprechenden Adresse > nutzt diese Pause, um eine 1 oder 0 auf den Bus zu legen (Touch oder > kein Touch). Der Master liest das Bit, und fragt dann den nächsten > Slave. ok solch eine kommunikation habe ich noch nicht in betracht gezogen, sollte aber machbar sein (solange keine störungen auftreten). an dieser stelle kam mir auch der gedanke, wie schnell das polling aller teilnehmer durchgeführt werden kann. also ob locker "50fps" oder mehr erreicht werden, müsste man evtl mal ausrechnen > > Der Beaglebone Black hat übrigens noch zwei Realtime-Co-Prozessoren, > über die sich so eine Kommunikation mühelos erledigen lässt (5ns > Zykluszeit). Damit sollten gute 50Hz (RGB Daten + Touch Daten > Übertragung) machbar sein. > > PS: Je nach Anzahl der Pixel sollte man den Tisch vielleicht aufteilen, > so dass der Master nur jede Zeile anspricht. In jeder Zeile spricht dann > wiederrum der erste Controller mit allen anderen Controllern in der > Zeile. So lassen sich probleme mit Spannungsverlusten bei langer > Leitungslänge vermeiden und die Datenrate erhöhen. du meinst einen master und für jede zeile oder spalte einen co-master? dieser soll dann seine ganz zeile "abchecken" und zurück zum master übersenden, sodass der master effektiv mit 5-10 seiner co-master kommuniziert und der arbeitsaufwand gering gehalten wird?
an sich gefällt mir der gedanke zum übertragen, es werden eigtl keine mux mehr benötigt und mit einem draht hat man sehr wenig verkabelungsaufwand... vllt könnte man beim "protokoll" noch ein bit spendieren um anzugeben ob read oder write vorgang vom master ausgelöst wird, rein zur absicherung ansonsten ist das hier ja schon mal eine gute entwicklung, danke :)
Tim R. schrieb: > mein problem > ist der dortige arm prozessor. ich bin atmel und microchip gewöhnter. > ich habe quasi null ahnung von arm und würde mir an dieser stelle > unnötige probleme vermeiden wollen. aber ansonsten eine nette auswahl! Das Gute ist, dass du den dann in jeder Sprache programmieren kannst, auch high level. Also Python, Java (script), C#, C++, C, Assembler. Da sollte für jeden was dabei sein ;-) Tim R. schrieb: > also ob locker "50fps" oder mehr > erreicht werden, müsste man evtl mal ausrechnen Hab ich schon ausgerechnet ;-) 50 Hz sind auf jeden Fall drin. Tim R. schrieb: > du meinst einen master und für jede zeile oder spalte einen co-master? > dieser soll dann seine ganz zeile "abchecken" und zurück zum master > übersenden, sodass der master effektiv mit 5-10 seiner co-master > kommuniziert und der arbeitsaufwand gering gehalten wird? Ja genau, so meinte ich das. Der Co-Master müsste dann ein etwas größerer µC sein, so dass er mit master und seinen Slaves kommunizieren kann (braucht ein paar Pins mehr).
also ich würde C/C++ bevorzugen :) :D könntest du kurz aufzeigen, was du genau gerechnet hast? vorallem für wieviele teilnehmer ja ich verstehe... kann mir jetzt grad nur schwer ausmalen wieviel mehr diese "co-master" uC dann bringen würden. oder ob man darauf verzichtet und einen großen nimmt der gleich alle reihen ansteuert wie weit ist dein projekt denn eigtl schon voran geschritten??
:
Bearbeitet durch User
Tim R. schrieb: > ja ich verstehe... kann mir jetzt grad nur schwer ausmalen wieviel mehr > diese "co-master" uC dann bringen würden. oder ob man darauf verzichtet > und einen großen nimmt der gleich alle reihen ansteuert Dann bekommst du wohlmöglich ein Problem mit der Leitungslänge. Bei meinem Tisch (10x13 Pixel sind geplant) wäre diese wtwa 10m. Laut einem Online-Rechner, bricht die Spannung von 5V am Ende der leitung auf etwa die Hälfte zusammen. Und auch die Übertragung dürfte dann schwieriger werden (Laufzeiten, Kapizäten usw). Durch die Gruppierung in Zeilen entspannt sich die Sache ungemein. Tim R. schrieb: > könntest du kurz aufzeigen, was du genau gerechnet hast? vorallem für > wieviele teilnehmer Für 130 Teilnehmer komme ich auf 20ms pro Übertragung. Also 50Hz. Die komplette Rechnung habe ich leider grad nicht hier, kann ich aber nachreichen).
Braucht es für Touch überhaupt 50 Samples pro Sekunde, da reichen doch 10?
Tim R. schrieb: > boris warum eigtl kein raspberry pi? Den könnte man auch nehmen und zB per SPI einen Kommunikations-Coprozessor dranhängen, der sich um Realtime Aufgaben wie den Touch-Bus kümmert. Ein RPi als Linuxsystem ist nicht gut in Realtime oder recht zeitkritischen Aufgaben. Der BeagleBone hat den Vorteil, dass der einen uC schon Onboard hat.
Tim R. schrieb: > boris warum eigtl kein raspberry pi? Für Steuerungsaufgaben ist der BBB deutlich besser geeignet: - Mehr Schnittstellen - Schneller Prozessor - Echtzeit-Co-Prozessoren schon an Board Hier gibt's mehr zu dem Thema: http://makezine.com/magazine/how-to-choose-the-right-platform-raspberry-pi-or-beaglebone-black/ Conny G. schrieb: > Braucht es für Touch überhaupt 50 Samples pro Sekunde, da reichen > doch 10? Ich habe versucht das Protokoll möglichst einfach zu halten (Farben und Touch-Events immer abwechselnd)). Klar würde auch weniger reichen. Aber wenn alles im 50Hz Takt läuft, ist das doch super.
Boris P. schrieb: > Conny G. schrieb: >> Braucht es für Touch überhaupt 50 Samples pro Sekunde, da reichen >> doch 10? > > Ich habe versucht das Protokoll möglichst einfach zu halten (Farben und > Touch-Events immer abwechselnd)). Klar würde auch weniger reichen. Aber > wenn alles im 50Hz Takt läuft, ist das doch super. Schraubt aber die Anforderungen unnötig nach oben. Ich würde auch für die Farben keine 50fps nehmen, wenn ws2811 LEDs zum Einsatz kommen, denn im Unterschied zum Multiplexing leuchten diese LEDs ja in der zuletzt eingestellten Farbe weiter. Also muss ich nicht mit hoher Frequenz Flimmern verhindern, sondern nur dafür sorgen, dass Animationen flüssig sind. Also reichen auch hier 20-25fps locker aus. Dann habe ich bei 25fps für RGB und Touch (bei einer analogen Auflösung von 1 Byte / 255 Werten pro Pixel) und 25fps für RGB dann 25 x 200 (Tisch von 10x20) x ( 8 + 24 ) = 160 kBit/s. Bei dieser Geschwindigkeit sollte man Busprobleme auch mit wenig Aufwand in den Griff bekommen. Mit 255 Bit Auflösung kann man die Kalibrierung zentral im Master machen. Und sogar auf die Stärke des Touch reagieren, also die Entfernung der Annäherung. Wenn man es nun noch schaffen würde das Protokoll der WS2811 in Leserichtung zu implementieren, dann hat man eine Kette von Attinys, die jeder wieder Bustreiber sind und kein Buslängenproblem. Der Master redet mit dem ersten Touch-Attiny und der gleichzeitig mit dem nächsten usw. Auf diese Weise saugt man sich die Bytekette aus der Daisychain. Da man weiß wieviele Pixel man hat, braucht man kein Ende-Zeichen. So könnte man sich den sternförmigen Aufbau und die Zeilencontroller sparen und hat von Grund auf keine langen Bus.
Wozu brauchst du denn die WS2811? Wenn du eh einen ATTiny pro Pixel verwendest kannst du dir den doch sparen, oder? Conny G. schrieb: > Dann habe ich bei 25fps für RGB und Touch (bei einer analogen Auflösung > von 1 Byte / 255 Werten pro Pixel) und 25fps für RGB dann 25 x 200 > (Tisch von 10x20) x ( 8 + 24 ) = 160 kBit/s. > Bei dieser Geschwindigkeit sollte man Busprobleme auch mit wenig Aufwand > in den Griff bekommen. was genau hast du da jetzt eingerechnet? Auch ein Start/Sync-Signal, die Adressierung und den Rückkanal? Ich komme bei meiner Rechnung auf 220 kbit/s bei 50Hz Updaterate von Farben und Touch-Status (für 130 LEDs). Das scheint mir ein guter Wert zu sein. Conny G. schrieb: > dann hat man eine Kette von Attinys, die > jeder wieder Bustreiber sind und kein Buslängenproblem. Ich bin noch nicht so sicher, ob das funktioniert. Sinn und Zweck eines Busses ist es ja, dass alle Teilnehmer gleichzeitig lesen und schreiben können. Wenn du nun das Signal durch jeden Teilnehmer "durchrouten" musst, geht ja viel Zeit verloren. Ob das dann noch hinhaut? Ein weiteres Problem ist zudem die Spannungsversorgung: Auf einer 10m leitung (1,5mm^2) kommen von den 5V am Anfang nur noch ca. die Hälfte am Ende an. Damit läuft natürlich kein Controller mehr. Deswegen wollte ich hier auf eine andere Topologie setzen.
:
Bearbeitet durch User
Boris P. schrieb: > Wozu brauchst du denn die WS2811? Wenn du eh einen ATTiny pro Pixel > verwendest kannst du dir den doch sparen, oder? Könnte man auch. Mit den WS2811 müsste man sich um das RGB-PWM nicht mehr weiter kümmern. > Conny G. schrieb: >> Dann habe ich bei 25fps für RGB und Touch (bei einer analogen Auflösung >> von 1 Byte / 255 Werten pro Pixel) und 25fps für RGB dann 25 x 200 >> (Tisch von 10x20) x ( 8 + 24 ) = 160 kBit/s. >> Bei dieser Geschwindigkeit sollte man Busprobleme auch mit wenig Aufwand >> in den Griff bekommen. > > was genau hast du da jetzt eingerechnet? Auch ein Start/Sync-Signal, die > Adressierung und den Rückkanal? > Ich komme bei meiner Rechnung auf 220 kbit/s bei 50Hz Updaterate von > Farben und Touch-Status (für 130 LEDs). Das scheint mir ein guter Wert > zu sein. Ja, 220kBit geht auch noch. Allerdings würde ich nicht nur Touch-Status machen, sondern einen "analogen" Wert für Annäherung und Kalibrierung. > Conny G. schrieb: >> dann hat man eine Kette von Attinys, die >> jeder wieder Bustreiber sind und kein Buslängenproblem. > > Ich bin noch nicht so sicher, ob das funktioniert. Sinn und Zweck eines > Busses ist es ja, dass alle Teilnehmer gleichzeitig lesen und schreiben > können. Wenn du nun das Signal durch jeden Teilnehmer "durchrouten" > musst, geht ja viel Zeit verloren. Ob das dann noch hinhaut? Das geht bei den WS2812 doch auch prima. Genau so müsste man es machen. Im Prinzip müssen die Attinys direkt jedes Bit weiterleiten ohne gross zwischenzuspeichern. Es könnte auch Kommunikation à la I2C sein: ich schiebe einmal RGB-Bytes raus und erhalte direkt T 0 0 (Touch-Wert 8 Bit, Null, Null) zurück. D.h. die Tinys würden den Bitstrom eimal direkt weiterleiten und im Rückkanal einen zurückschieben. Und ein Pause wäre "Latch", den RGB-Wert übernehmen bzw. den Touch-Messwert für die nächste Runde speichern. Man bräuchte also 2, evtl. 3 Leitungen von Tiny zu Tiny: Tx, Rx, Clk. > Ein weiteres Problem ist zudem die Spannungsversorgung: Auf einer 10m > leitung (1,5mm^2) kommen von den 5V am Anfang nur noch ca. die Hälfte am > Ende an. Damit läuft natürlich kein Controller mehr. Deswegen wollte ich > hier auf eine andere Topologie setzen. Das ist das kleinste Problem einmal die Versorgung an den Spalten vorbeizuführen und an jeder Spalte einzuspeichen. Oder Zeile, ist völlig wurst.
Conny G. schrieb: > Mit den WS2811 müsste man sich um das RGB-PWM nicht > mehr weiter kümmern. Auf den ersten Blick scheint der ca. 0,50€ zu kosten. Bei einem 200-Pixel-Tisch wären das also schon mal 100€ nur für diesen Chip. Da würde ich doch lieber schnell eine Soft-PWM auf dem ATTiny implementieren. Ist ja kein Hexenwerk ;-)
Boris P. schrieb: > Conny G. schrieb: >> Mit den WS2811 müsste man sich um das RGB-PWM nicht >> mehr weiter kümmern. > > Auf den ersten Blick scheint der ca. 0,50€ zu kosten. Bei einem > 200-Pixel-Tisch wären das also schon mal 100€ nur für diesen Chip. Da > würde ich doch lieber schnell eine Soft-PWM auf dem ATTiny > implementieren. Ist ja kein Hexenwerk ;-) Und das I2C zwischen den Tinys macht auch nur Sinn, wenn der Tiny das PWM macht.
Man sollte man so ein I2C-Daisy-Chain-Member mit Attiny, RGB LED als Prototyp bauen, bzw. 10 davon und testen. Ich glaube ist supercool so. Oder wie man seit neuestem sagt: supersimpel, superclever ... supergeil!
Angehängte Dateien:
-
Pixel.png
18 KB -
Matrix.png
8 KB
Also ich glaube man kann doch auf eine Unterteilung in Zeilen verzichten. Wenn man nicht alles als Kette, sondern sternförmig anordnet (siehe Bild), beträgt die maximale Leitungslänge ca. 70cm. Das sollte sowohl für die Stromversorgung als auch den Bus problemfrei sein. Dann braucht man also nur noch einen Typ von Pixel, und die Buskommunikation ist auch deutlich einfacher. Das könnte so aussehen: Master sendet Start/Sync-Signal -> Alle Slaves beginnen nun zu lauschen Master sendet Addresse (8 Bit) -> Nun weiß der entsprechende Slave dass er gemeint ist Master sendet 24 Bit Farbinformationen -> Slave übernimmt die Daten in seine RGB-LED-PWM Master wartet 1 Bit lang -> Slave setzt sein Touch-Status auf den Bus, Master liest diesen => Wiederhlung des Vorgehens mit nächster Adresse Dann ist zwar keine Kalibrierung durch den Master möglich (wie oben vorgeschlagen), aber ich denke die ist auch verzichtbar, oder? Auch die Entfernung der Hand zum IR-Sensor brauche ich nicht wirklich. Daher sollte ein Bit als Rückkanal reichen.
:
Bearbeitet durch User
So geht's auch, ja. Dann müsste man nicht das Chaining machen. Wenn man es wie I2C implementiert und damit hin (RGB) und rück (Touch) gleichzeitig, dann bekommt man 24 Bit Rückkanal sowieso geschenkt, d.h. es kann dann problemlos 1 Byte Touch-Wert zurückbekommen, weil mit dem Taktsignal sowieso 24 Bits laufen und gar keine Extra Zeit für den Touch-Status gebraucht wird.
:
Bearbeitet durch User
Conny G. schrieb: > Wenn man es wie I2C implementiert und damit hin (RGB) und rück (Touch) > gleichzeitig, dann bekommt man 24 Bit Rückkanal sowieso geschenkt, d.h. > es kann dann problemlos 1 Byte Touch-Wert zurückbekommen, weil mit dem > Taktsignal sowieso 24 Bits laufen und gar keine Extra Zeit für den > Touch-Status gebraucht wird. Ich kann dir nicht folgen. Du hast doch nur eine Leitung. Je mehr Daten du also zurücksenden möchtest, desto länger dauert das, desto kleiner ist die Update-Rate. Wo bekommst du da was geschenkt?
Boris P. schrieb: > Conny G. schrieb: >> Wenn man es wie I2C implementiert und damit hin (RGB) und rück (Touch) >> gleichzeitig, dann bekommt man 24 Bit Rückkanal sowieso geschenkt, d.h. >> es kann dann problemlos 1 Byte Touch-Wert zurückbekommen, weil mit dem >> Taktsignal sowieso 24 Bits laufen und gar keine Extra Zeit für den >> Touch-Status gebraucht wird. > > Ich kann dir nicht folgen. Du hast doch nur eine Leitung. Je mehr Daten > du also zurücksenden möchtest, desto länger dauert das, desto kleiner > ist die Update-Rate. > Wo bekommst du da was geschenkt? Sorry, ich hab's mit SPI verwechselt. Aber ich meinte SPI, da hast gleichzeitig TX und RX geschenkt. Mit 2 Leitungen plus Clock, das ist nicht so aufwändig in der Verkabelung. Habe heute auch schonmal kurz drüber nachgedacht, ob man sich "Rails" aus Kupfer auf die Grundplatte machen könnte auf die man die Module dann aufschraubt und damit sich jede Verkabelung erspart. Allerdings riecht mir das stark nach Busproblemen mit Kapazität, Induktivität und Störungen... Lieber nimmt man gleich kurze Standardkabel wie SATA-Kabel oder so. 10cm für 1,70 Euro auf Ebay. Geht auch bestimmt noch billiger. Kurze 10cm Standard-Flachbandkabel mit 6 Polen. Denn die Konfektionierung von 100 Kabeln (bei 10x10) ist einer der riesigen Arbeitszeitfresser.
Conny G. schrieb: > Sorry, ich hab's mit SPI verwechselt. Aber ich meinte SPI, da hast > gleichzeitig TX und RX geschenkt. Mit 2 Leitungen plus Clock, das ist > nicht so aufwändig in der Verkabelung. Klar, man könnte statt einer Datenleitung gleich zwei nehmen, dann hat man RX und TX gleichzeitig. Aber da es eigentlich kein Zeitproblem geben sollte, kann man sich die zusätzliche Leitung doch sparen, und alles auf einer machen. Ist weniger Verkabelungsaufwand, billiger und hat keinerlei Nachteile.
Dann könnte das mit den Rails evtl. doch gehen... man macht 1cm breite Kupferstreifen nebeneinander, die sind schon mal die Stromversorgung der einzelnen Pixel. Dann braucht man die Pixel eigentlich nur mit einem dicken Lötauge draufschrauben und sie haben Strom, v.a. mit einer sehr dicken Zuleitung, also wenig Verlust. Oder statt draufschrauben am Rand anlöten, wie die SMD-Funkmodule :-) Aber das wäre unpraktisch, weil schlecht wartbar, da ist Schrauben besser. Und das I2C entweder über ein 3. Rail, wobei das enorm Störanfällig ist. oder mit Lötnägeln o.ä. nach unten durch das Basisbrett durch und dort mit 7cm geschirmtem Kabel von Nagel zu Nagel hüpfen. Oder das Datenrail zwischen 2 Schirmschichten nehmen, also Kupfer (GND) + Folie + Kupfer (DATA) + Folie + Kupfer (GND) und das immer für 1cm unterbrechen. Dann könnte man hier sogar GND + Data abnehmen. Das würde jede Verkabelung komplett ersparen.
:
Bearbeitet durch User
Oder gleich 25x25 (oder welches Maß auch immer ein Vielfaches der Pixel ist) Platinen als Basis nehmen.
uiuiui das ist ja fortgeschritten hier heute :-) mich würde interessieren, wie wird denn der realtime prozessor auf dem beagle angesprochen?! mit dem "protokoll" zur eindrahtleitung für rgb und touch stimm ich überein, ich glaube das ist die einfachste und zugleich verdrahtungsärmste methode ich hatte die ganze zeit eh im kopf, den master direkt vor die "reihen" zu setzen und somit 10 (oder mehr) reihen anzusprechen, die jeweils 1-2m leitungslänge haben. ich verstehe nicht ganz wie du auf 10m leitungslänge kommst -> zwecks spannungsabfall ? aber in der mitte als physische sterntopologie sollte das ganze auch machbar sein :) boris bei deinem protokollablauf, sollte der master nicht erst das touch abfragen und anschließend einen rgb wert senden? also rein aus der logik kann der master ja keinen rgb wert setzen, wenn der touch nicht vorher abgefragt wurde... es sei denn man verwendet den vorigen zyklus die entfernung der hand wäre ein sehr nettes gimmik. daran hatte ich nocht gar nicht gedacht. aber das zieht einige erweiterungen mit sich oder? an kupferplatten für die versorgung hatte ich auch schon gedacht, ich hab mit diesen nur noch nie gearbeitet und weiß nicht ob das so funktionieren würde, aber sehe dort eigtl keine probleme. weiß nur nicht ob ich mir so eine "offene leitung" in meinen tisch bauen will ;-) für die datenleitung würde ich fertig gecrimpte kabel kaufen oder sata kabel wie Conny es geschrieben hatte. ich habe definitiv keine lust gefühlt 1000000 kabel erst ordentlich zu verarbeiten bevor ich sie richtig verwenden kann ... und ja das ist mir bekannt: supersimpel, superclever ... supergeil! ;-P
Tim R. schrieb: > ich verstehe nicht ganz wie du auf 10m > leitungslänge kommst -> zwecks spannungsabfall ? Die kommen zustande, wenn du eine Kette über alle Pixel bildest (das war mal meine aller erste Idee). Bei einer Sternstruktur, ist das Problem natürlich weg. Tim R. schrieb: > boris bei deinem protokollablauf, sollte der master nicht erst das touch > abfragen und anschließend einen rgb wert senden? also rein aus der logik > kann der master ja keinen rgb wert setzen, wenn der touch nicht vorher > abgefragt wurde... es sei denn man verwendet den vorigen zyklus Meinst du Inputs lesen -> neue Ausgabe berechnen -> Outputs setzen? Das wird so nicht klappen, da du in der kurzen Zeit das nächste Bild nicht berechnet bekommst. Die Übertragung auf dem Bus geht ja so schnell, dass da nur sehr wenig Zeit zwischen liegt. Man muss sowieso Anwendung (Spiel, Animation etc.) komplett vom Displaytreiber entkoppeln, da diese ja asynchron auf verschiedenen Prozessoren laufen. D.h. die Anwendung berechnet so schnell die Bilder wie sie kann und kopiert die Daten in einen Puffer (Hauptprozessor). Der Display-Treiber (Realtime-Prozessor) greift sich unabhängig davon in einer festen Frequenz die Daten aus dem Buffer und schiebt sie an die Pixel.
:
Bearbeitet durch User
Tim R. schrieb: > die entfernung der hand wäre ein sehr nettes gimmik. daran hatte ich > nocht gar nicht gedacht. aber das zieht einige erweiterungen mit sich > oder? Eigentlich nicht so dramatisch. Die einzelnen Pixel übermitteln nur einen Wert in einem Range statt 0 oder 1 für den Touch. Und der Master kann entweder für alle die gleich Schwelle nehmen oder nach irgendeiner Logik die Schwellwerte differenziert setzen. Und bei der Auswertung des Touch kann man Annäherung einfliessen lassen, wenn man möchte oder auch nur per Schwelle an/aus interpretieren. Ich fände das cool, wenn man man einen "analogen" Wert hätte - gerade weil es nur mässig mehr Aufwand macht (entweder höhere Datenrate bei I2C-ähnlichem Protokoll oder 3 Leitungen für SPI). Nur Touch j/n ist eine recht harte Designentscheidung, die diese Möglichkeiten eliminiert. > an kupferplatten für die versorgung hatte ich auch schon gedacht, ich > hab mit diesen nur noch nie gearbeitet und weiß nicht ob das so > funktionieren würde, aber sehe dort eigtl keine probleme. weiß nur nicht > ob ich mir so eine "offene leitung" in meinen tisch bauen will ;-) Es wären eher Kupferfolie oder Kupferstreifen oder so. Idealerweise noch verzinnen im chem. Verzinnungsbad, dann oxidieren sie nicht. Der Tisch ist ja zu. Und es sind maximal 12V würde ich annehmen, eher nur 5V, das ist völlig unproblematisch. Und man könnte auch noch mit einer ordentlichen Schicht Klarlack o.ä. eine Isolierung schaffen. > für die datenleitung würde ich fertig gecrimpte kabel kaufen oder sata > kabel wie Conny es geschrieben hatte. ich habe definitiv keine lust > gefühlt 1000000 kabel erst ordentlich zu verarbeiten bevor ich sie > richtig verwenden kann > > ... und ja das ist mir bekannt: supersimpel, superclever ... supergeil! > ;-P
Boris P. schrieb: > Tim R. schrieb: >> ich verstehe nicht ganz wie du auf 10m >> leitungslänge kommst -> zwecks spannungsabfall ? > > Die kommen zustande, wenn du eine Kette über alle Pixel bildest (das war > mal meine aller erste Idee). Bei einer Sternstruktur, ist das Problem > natürlich weg. ach du wolltest eine lange kette mit allen pixeln bilden?? ich hatte die ganze zeit für jede reihe die länge versorgung und datenleitung geplant, das wäre eben nur die tischlänge > > Tim R. schrieb: >> boris bei deinem protokollablauf, sollte der master nicht erst das touch >> abfragen und anschließend einen rgb wert senden? also rein aus der logik >> kann der master ja keinen rgb wert setzen, wenn der touch nicht vorher >> abgefragt wurde... es sei denn man verwendet den vorigen zyklus > > Meinst du Inputs lesen -> neue Ausgabe berechnen -> Outputs setzen? > Das wird so nicht klappen, da du in der kurzen Zeit das nächste Bild > nicht berechnet bekommst. Die Übertragung auf dem Bus geht ja so > schnell, dass da nur sehr wenig Zeit zwischen liegt. Man muss sowieso > Anwendung (Spiel, Animation etc.) komplett vom Displaytreiber > entkoppeln, da diese ja asynchron auf verschiedenen Prozessoren laufen. also der user aus dem link den ich zuvor gepostet habe, hatte glaube nur einen atmega verwendet. das sollte doch eigtl relativ gut gehen oder nicht? pixel abfragen, pixel setzen... und das bei 100 pixeln am besten rund 25mal die sekunde > > D.h. die Anwendung berechnet so schnell die Bilder wie sie kann und > kopiert die Daten in einen Puffer (Hauptprozessor). Der Display-Treiber > (Realtime-Prozessor) greift sich unabhängig davon in einer festen > Frequenz die Daten aus dem Buffer und schiebt sie an die Pixel. die idee der kopplung ist aber auch gut. nur mit einem mehraufwand verbunden, aber nun versteh ich deine entscheidung für das beagleboard :) ps: kupferstreifen war auch das wort was ich gesucht habe, ich kam nicht drauf *g
:
Bearbeitet durch User
Tim R. schrieb: > also der user aus dem link den ich zuvor gepostet habe, hatte glaube nur > einen atmega verwendet. das sollte doch eigtl relativ gut gehen oder > nicht? pixel abfragen, pixel setzen... und das bei 100 pixeln am besten > rund 25mal die sekunde Nenene, mit nem ATMega macht das glaubich keinen Spaß ;-) Du willst ja auch WLAN und oder Bluetooth Anbindung haben, vielleicht einen Webserver. Und die Programmierung sollte in verschiedenen Hochsprachen möglich sein, so dass man vielleicht sogar Programme mit anderen "Nachbauern" austauschen kann. Das alles bekommst du beim BBB geschenkt.
Boris P. schrieb: > Tim R. schrieb: >> also der user aus dem link den ich zuvor gepostet habe, hatte glaube nur >> einen atmega verwendet. das sollte doch eigtl relativ gut gehen oder >> nicht? pixel abfragen, pixel setzen... und das bei 100 pixeln am besten >> rund 25mal die sekunde > > Nenene, mit nem ATMega macht das glaubich keinen Spaß ;-) > Du willst ja auch WLAN und oder Bluetooth Anbindung haben, vielleicht > einen Webserver. Und die Programmierung sollte in verschiedenen > Hochsprachen möglich sein, so dass man vielleicht sogar Programme mit > anderen "Nachbauern" austauschen kann. Das alles bekommst du beim BBB > geschenkt. das würde aber nach sich ziehen das wir den selben aufbau realisieren bzw. das du alle schaltpläne codes etc frei gibst ?! :) erst dann können auch andere dazu ihren teil beisteuern ;)
Tim R. schrieb: > das würde aber nach sich ziehen das wir den selben aufbau realisieren > bzw. das du alle schaltpläne codes etc frei gibst ?! :) > erst dann können auch andere dazu ihren teil beisteuern ;) Dass der Code und die Schaltpläne frei zugänglich sind, ist für mich selbstverständlich. Ich würde das ganze dann eh auf einer Open-Source Plattform hosten. So kann sich an der Entwicklung beteiligen wer mag. Den "Grafiktreiber" würde ich dann so implementieren, dass die Anzahl der Pixel, die gewünschte Datenrate usw. einstellbar sind. So kann diese für jedes Tisch-Format benutzt werden. Das ganze wird eine C/ASM Library, die dann von jeder Sprache einbindbar ist. Dann kann jeder (ob nun Java-Scripter oder Hardcore-Assemblierer) für so einen Tisch eine Anwendung schreiben. Die könnte man dann auch schön auf dieser Plattform hosten (mit SCreenshots/Video, Beschreibung und Download), und sich so austauschen. Keine Ahnung wie viele Nachbauer sich dann für sowas finden. Aber Versuch macht kluch ;-)
Na das hättest du mal anfangs erwähnen sollen, dass du es gerne so machen magst ;-) Ich weiß nicht ob sich nachbauer finden, aber sobald Entwickler eigene Software dafür schreiben haben wir ebenso was davon hehe Die geschwindigkeit ist ein gutes Thema, denn je mehr Teilnehmer desto schneller muss der Echtzeitptozessor die Daten scheffel Also zu aller erst sollten die kleine Struktur und das Protokoll in eine Datei ausgelagert werden. Und dann kann es eigtl losgehen mit dem schaltplan für die pixelplatine etc oder wie sieht's aus? :) sollten uns dann eben nur auf die Komponenten einigen
Bin grundsätzlich auch am Bau so ein coolen Tisches interessiert. Wird allerdings eine Weile dauern, bis ich wirklich dazukomme, habe noch Projekte vorher abzuschließen. Fände es gut, wenn wir cleveres Konzept für die Pixel finden, wie wir uns die ganze Wahnsinnsverkabelung ersparen / erleichtern könnten. Also Bus oder Daisy Chain.
:
Bearbeitet durch User
Conny G. schrieb: > Bin grundsätzlich auch am Bau so ein coolen Tisches interessiert. Wird > allerdings eine Weile dauern, bis ich wirklich dazukomme, habe noch > Projekte vorher abzuschließen. > Fände es gut, wenn wir cleveres Konzept für die Pixel finden, wie wir > uns die ganze Wahnsinnsverkabelung ersparen / erleichtern könnten. > Also Bus oder Daisy Chain. ich habe das problem der zeit und des platzes, ich weiß noch gar nicht wohin mit dem ding gg also die variante des eigenen einfachen protokolls, welches auf einer kaskadierung basiert, gefällt mir am besten. lasse mir gerne aber alternativen zeigen. somit brauch jede pixel-platine 2 leitung versorgung und eine bidirektionale datenleitung. macht 3 leitungen pro pixel :) wovon die zwei zur versorgung evtl durch die kupferstreifen oder ähnliches gelöst werden könnten... ich würde für die versorgung auf der pixelplatine zum einen steckverbindung und zum anderen evtl eine borung zum schrauben oder so vorschlagen
Hi Tim, im Moment sieht es ja eher düster aus: Conny ist momentan anderweitig beschäftigt: Conny G. schrieb: > Wird allerdings eine Weile dauern, bis ich wirklich dazukomme, habe noch > Projekte vorher abzuschließen. Bei Dir sieht es auch nicht besser aus: Tim R. schrieb: > ich habe das problem der zeit und des platzes, ich weiß noch gar nicht > wohin mit dem ding gg Und auch bei mir sind zurzeit noch zwei andere Projekte in Arbeit. Zudem scheinen sich hier nicht besonders viele Interessenten zu finden. Außer uns Dreien meldet sich hier ja keiner. Zudem mangelt es uns (so wie ich das einschätze) hier und da an Expertise - z.B. ist die Realtime-Unit des BBB nicht so einfach zu programmieren. Daher betrachte ich das Projekt vorerst als "auf Eis gelegt"...
Was ich bei derlei "Randprioritäten" gerne praktiziere ist eine Taktik der kleinen Schritte: definieren wo ich hin will (cooler RGB-Touch-Tisch) und das dann in Unterprojekte zerlegen, die für einen Abend taugen. Dann kann man immer dann, wenn man gerade Zeit und auf nix anderes Lust hat so einen Teil rausziehen und durchführen und hat nach ein paar Wochen dann doch schon einiges erledigt. Und man kann schon immer mal Bauteile mitbestellen und ansammeln. Und wir hier können uns solche Aufgaben aufteilen. Die aufwändugste Basis des Tisches sind ja die RGB-Touch-Pixel. Also sollte man ein erstes realistisch erscheinendes Konzept dafür festlegen, Bauteile bestellen, aufbauen und testen. Der zweite Teil ist der Bus. Dazu könnte man erstmal die One Wire Idee komplett ausformulieren. Dann implementieren und auf zwei beliebigen uCs testen, danach mal mit 2. Und wenn einstweilen die Touchpixel getestet sind, macht man mal 10-20 davon und testet nochmal. Evtl mit extra großen Abständen der Leitungen. Vielleicht auch mal mit 3 Kupferstreifen auf der Bodenplatte - vielleicht geht's ja und man spart sich die Verkabelung komplett. Und nach diesen beiden Elementen - die eigentlich die schwierigsten sind - geht's um Gehäuse und die Steuerung, auch zwei getrennte Projekte. Ebenso zerlegen, aufteilen und Schritt für Schritt abfackeln. Also als erstes: Pixel definieren - welche LEDs und wieviele (braucht das schon mal einen Prototyp? - welcher Mikrocontroller? - Bauelemente Touch? Ziele: - RGB: Hell genug auch bei moderatem Tageslicht - Touchmessung moduliert für mehr Robustheit - So wenige Bauelemente wie möglich für effizienten Aufbau - Kostengrenze pro Pixel 3 Euro? - ... Fragen: - Zusätzlich weiße LED für echtes weiß und Pastell? - Anforderungen an den uC - günstig, weil 100 Stück - Idealerweise schon 5 PWMs für RGBW und Touch - ... Das müssen wir noch weiter aufrollen.
Angehängte Dateien:
-
IMG_0253.JPG
44 KB
Hi, ich hatte mir ja mal den IR Näherungssensor APDS-9120 von Avago angeschaut (siehe auch oben). Das Dingens ist für einen Tisch nicht brauchbar, es ist ultraklein (ca. 4x4 mm) und ziemlich fies zu löten. Es funktioniert grundsätzlich zwar, aber der Erfassungswinkel und -Abstand (im besten Fall 4cm, aber nur bei weißem Material) passen nicht. Auch die eingebaute IR-LED ist dafür einfach zu winzig. Man wird also um eine Lösung mit einer externen möglichst "dicken" IR-Led mit breitem Abstrahlwinkel nicht umhinkommen. Der Si1102 sieht auch noch ganz interessant aus, mit seinem Erfassungsbereich von max. 50cm. Allerdings mit 3x3 mm und 8 Pins auch ein Winzling. Oder eben doch mit einem Controller pro Pixel aufbauen, so hätte man auch bei der Wahl der RGB-LEDs mehr Freiheit. Grüße Markus
ah super, auf deine antworte habe ich gewartet! danke dir für das testen das ist schon mal ein guter ansatz. das bauteil ist wirklich winzig. ich habe mir aber überlegt, wenn es wirklich mehrere pixelplatinen werden sollen, diese bestücken zu lassen sonst werd ich irre bei soviel löterei :D aber das ziel, für jeden pixel eine platine zu fertigen ist glaube ich schon ziemlich festgesteckt, sonst wird es unnötig aufwendig ich werde mir gleich mal den Si1102 anschauen... zur zeit warte ich gerade auf meine bestellung vom is471 und einer kleinen plexiglas platte (lichtdurchlässig)... danach werde ich mal einen kleinen aufbau aufm steckbrett probieren. hab noch ein kleines demo board von microchip rumliegen vllt werde ich auch gleich eine kleine auswertung auf dem uC vornehmen
Das hier ist ja im Prinzip ein wenig Grundlagenforschung, zumindest bzgl. des Tisches. Wie sieht denn der geplante Aufbau des Tisches aus? Wenn man schon soviel Geld reinsteckt, wird man doch sicher keine Plexiglasplatte am Ende nehmen? Glas sollte doch schöner aussehen, oder? Wie groß sollen denn die einzelnen "Pixel" werden? 5x5 cm? Daraus ergibt sich dann ja auch, wie weit die LEDs (IR + RGB) und somit auch der Sensor von der Scheibe entfernt sein muss, um eine gleichmäßige Ausleuchtung zu bekommen. Ist evtl. auch experimentell zu ermitteln. Der Erbauer des anderen Touch-Tisches hat Milch(plexi?)glas mit 40% Lichtdurchlässigkeit genommen. Grüße Markus
Bzgl. der Entfernung von der Glas-/Plexischeibe: die Ausleuchtung ist gar nicht mal so die Frage. Vielmehr ist interessant, dass der Winkel der Touch-Erkennung möglichst schmal ist. D.h. die IR-Diode und der IR-Receiver sollten so weit unten sitzen, dass der Öffnungswinkel der Messung nach oben nur noch 10-20 Grad ist. Beim Beleuchten wäre es egal, wenn die LED 120 Grad Abstrahlwinkel hätte und nur so weit von der Platte entfernt ist, dass man keine Punktförmige Lichtquelle mehr sieht - das sind nur 5-7cm. Diese 5-7cm reichen aber bei einer "Pixelgröße" von 60/10 = 6cm für 10-20 Grad IR-Erkennung noch nicht aus, es ergäbe eher einen Winkel von 45 Grad. Müsste also doppelt so weit runter, also 10+ cm.
Markus M. schrieb: > Das hier ist ja im Prinzip ein wenig Grundlagenforschung, zumindest > bzgl. des Tisches. > > Wie sieht denn der geplante Aufbau des Tisches aus? Wenn man schon > soviel Geld reinsteckt, wird man doch sicher keine Plexiglasplatte am > Ende nehmen? Glas sollte doch schöner aussehen, oder? > > Wie groß sollen denn die einzelnen "Pixel" werden? 5x5 cm? Daraus ergibt > sich dann ja auch, wie weit die LEDs (IR + RGB) und somit auch der > Sensor von der Scheibe entfernt sein muss, um eine gleichmäßige > Ausleuchtung zu bekommen. Ist evtl. auch experimentell zu ermitteln. > > Der Erbauer des anderen Touch-Tisches hat Milch(plexi?)glas mit 40% > Lichtdurchlässigkeit genommen. > > Grüße > Markus ich habe jetzt einen kleinen testaufbau auf einem steckbrett mit dem is471 realisiert (inkl. Plexiglasscheibe). die schaltung habe ich von http://www.kreatives-chaos.com/artikel/abstandssensor-mit-is471 fast identisch übernommen (danke an den autor). als ausgabe diente erstmal eine einfache kleine LED. plexiglas habe ich eine 10x10cm große plexi- milchglas mit 79% lichtdurchlässigkeit bei ebay genutzt (versand war teurer als das glas selbst :-D) ich habe etwa 2cm abstand zwischen led und plexiglas. die erkennung lief soweit schon mal ganz gut. man muss aufpassen das die LED nicht den sensor beeinflusst. ich werde meinen prototypen nur noch etwas umbauen, um die led und den sensor richtig ausrichten zu können und anschließend gleich an einen uC zu gehen für eine eventuelle filterung. zudem muss ich mal eine RGB unter das glas klemmen um zu sehen wie die led als lichtquelle wirkt. denn ich persönlich mag keine punktausleuchtung sondern das gestreute licht quasi. somit habe ich die grundlagenforschung nun am schopf gepackt. rein aus kostengründen würde mich interessieren, wie andere sensoren arbeiten wie zum beispiel der TSOP oder andere sensoren die hier genannt wurden... wenn man 100xIS471 nimmt, kommt schon ein sümmchen zusammen... eine kostengünstigere alternative wäre praktisch
:
Bearbeitet durch User
Angehängte Dateien:
-
Bewegungsmelder.jpg
37 KB
Hallo zusammen, bin mit dabei..... ;-) Hatte dieses Video gefunden....... https://www.youtube.com/watch?v=6WkqYltIJJU Aber eben teuer und nur einfarbig. Aber der erste Gedanke von mir war ganz einfach erst mal ein Fototransistor plus Leistungstransistor wie im Anhang. So spät genug, muss jetzt erst mal in die Heia. ;-)
Mir schwirrt folgendes Modell im Kopf herum: Ein Attiny oder ähnlicher kleinstmöglicher Prozessor lässt einen Timer mit 100 kHz laufen pulst mit diesem Timer ein IR-LED mit 50 Khz es wird je On-Periode der IR-LED und je Off-Periode einmal die Spannung an einer IR-Diode gemessen Zwischen diesen beiden Werten wird jede Messperiode (oder auch über 100 Messperioden zur Störungsfilterung) die Differenz gebildet dadurch ist eine Kalibrierung auf die Umgebungshelligkeit gegeben: Off-Wert ist die Grundhelligkeit, On-Helligkeit ist die Abstandsmessung, die Differenz aus beiden ist der Sensorwert, der proportional zum Abstand eines Sensors ist Je höher die Grundhelligkeit, desto geringer die Auflösung der Erkennung (die Differenz der beiden Wert wird geringer) Idealerweise würde man den Messbereich noch mit einem Opamp auf die Referenzspannung der AD-Wandlung skalieren, das maximiert die Grundauflösung der Messung. Nun kann der Attiny auch den 1-Wire-Bus bedienen und entweder ein digitales Signal geben - für diejenigen, die das bevorzugen - oder ein analoges für die Entfernung eines Gegenstands.
Joe schrieb: > Hallo zusammen, > > bin mit dabei..... ;-) > > Hatte dieses Video gefunden....... > https://www.youtube.com/watch?v=6WkqYltIJJU > > Aber eben teuer und nur einfarbig. > > Aber der erste Gedanke von mir war ganz einfach erst mal ein > Fototransistor plus Leistungstransistor wie im Anhang. > > So spät genug, muss jetzt erst mal in die Heia. ;-) wenn ich das richtig sehe is das nen fototransi oder ? heißt der reagiert nur auf licht bzw. schatten. das wäre in so einem tisch meiner meinung nach ganz schön ungeeignet alleine wegen umgebungslicht und eigenen licht im pixelkästchen... oder irre ich mich?! @Conny du willst also die LED auch gleichzeitig als sensor nutzen? ist dieses modell denn schon mal getestet worden oder ist das eine reine idee? zumindest von den bauteilen wäre das glaub günstiger weil der is471 zum beispiel wegfällt... würde eben nur anfangs eine größere testreihe mit sich bringen...
Tim R. schrieb: > @Conny du willst also die LED auch gleichzeitig als sensor nutzen? ist > dieses modell denn schon mal getestet worden oder ist das eine reine > idee? > zumindest von den bauteilen wäre das glaub günstiger weil der is471 zum > beispiel wegfällt... würde eben nur anfangs eine größere testreihe mit > sich bringen... Nein, ganz normal IR-LED zum senden des Messsignals und IR-Diode als Sensor. Das Ganze gepulst für Toleranz gg. Fremdlicht. IR-Diode meint hier nicht IR-LED sondern IR-Foto-Diode, das sind zwei verschiedene Dinge. Aber ich würde IR-Fotodiode statt Fototransistor vorschlagen, da IR-Fotodioden soviel ich gelesen habe schneller reagieren.
:
Bearbeitet durch User
...das Problem mit den Photodioden ist aber, dass sie nur sehr kleine Ströme liefern. Somit kommt man um einen OP nicht herum. Damit hat man schon wieder mehr Bauteile auf der Platine. OP und Hühnerfutter...
Markus M. schrieb: > ...das Problem mit den Photodioden ist aber, dass sie nur sehr kleine > Ströme liefern. Somit kommt man um einen OP nicht herum. > > Damit hat man schon wieder mehr Bauteile auf der Platine. OP und > Hühnerfutter... Ui, ja, ok. Muss zugeben, dass ich noch nicht mit Photodioden gearbeitet habe. Ich habe dazu gerade folgendes gefunden: Beitrag "Re: Photodiode messen" "An die Fotodiode wird eine Spannung in Sperrichtung angeschlossen, die zu einer Verstärkung des Fotostromes führen kann (auf die Beschaltung beziehen sich offensichtlich die Angaben im Datenblatt, V_R wird in Sperrichtung angelegt und über einen Widerstand im Kreis kann wieder eine stromproportionale Spannung abgegriffen werden). Nachteil: U.a. geringere Linearität (sollte in diesem Fall lt. Datenblatt aber unproblematisch sein)." Habe gerade mal in Datenblättern nachgelesen, was der Schaltzeitunterschied zwischen Fototransistor und Fotodiode eigentlich ist. Transistor: 5µs http://www.vishay.com/docs/81504/bpv11.pdf Diode: 2,5ns http://www.vishay.com/docs/81502/bpv10.pdf Ist also schon Faktor 1.000, bei 100 kHz Messfrequenz haben wir nur 10µs für die Messung. Mit der Frequenz kann man schon noch ein bisschen runtergehen, so bis 40-50 kHz, aber dann sinds auch nur 20µs und damit noch im Schaltzeitbereich des Transistors. Ich würde also sagen: um es so zu machen wie ich skizziert habe muss es eine Fotodiode sein.
:
Bearbeitet durch User
Hallo, wozu IR, Sensor, Lichtschranke und weiteres? Ihr habt doch den besten Sensor schon vorhanden! Die LED selbst. Siehe http://cs.nyu.edu/~jhan/ledtouch/index.html
Armin K. schrieb: > Hallo, > wozu IR, Sensor, Lichtschranke und weiteres? > Ihr habt doch den besten Sensor schon vorhanden! Die LED selbst. > Siehe http://cs.nyu.edu/~jhan/ledtouch/index.html Wäre durchaus eine Idee. Da würden mich zwei Fragen beschäftigen: - ist die Empfindlichkeit genug um durch mattiertes (Plexi)Glas zu kommen? - würde Infrarot nicht deutlich bessere Abgrenzung von Fremdlicht bieten? Ich denke, dass die Empfindlichkeit generell und Störunempfindlichkeit speziell bei normalen LEDs eher kritisch stehen. Kann aber die Dimension der Fotodiodenwirkung einer normalen LED überhaupt nicht einschätzen, also wie stark der Kompromiss ggü Fotodiode ausfällt. Weiss das jemand, wie es um die Licht-Empfindlichkeit einer normalen Diode steht?
Conny G. schrieb: > Armin K. schrieb: >> Hallo, >> wozu IR, Sensor, Lichtschranke und weiteres? >> Ihr habt doch den besten Sensor schon vorhanden! Die LED selbst. >> Siehe http://cs.nyu.edu/~jhan/ledtouch/index.html > > Wäre durchaus eine Idee. > > Da würden mich zwei Fragen beschäftigen: > - ist die Empfindlichkeit genug um durch mattiertes (Plexi)Glas zu > kommen? > - würde Infrarot nicht deutlich bessere Abgrenzung von Fremdlicht > bieten? > > Ich denke, dass die Empfindlichkeit generell und Störunempfindlichkeit > speziell bei normalen LEDs eher kritisch stehen. > Kann aber die Dimension der Fotodiodenwirkung einer normalen LED > überhaupt nicht einschätzen, also wie stark der Kompromiss ggü Fotodiode > ausfällt. > > Weiss das jemand, wie es um die Licht-Empfindlichkeit einer normalen > Diode steht? das selbe dachte ich mir bei der seite auch. ich sehe nur einen dunklen raum mit LEDs. aber was ist, wenn das umgebungslicht eben tageslist oder was auch immer entspricht, dann sieht die empfindlichkeit zur messung mit der led selbst schon ganz anders aus und ich glaube um einiges schlechter als IR den ansatz mit IR-fotodiode/transistor werde ich mal nachschauen. ich kenne nur fototransi-/dioden aber nicht mit IR. guter ansatz, so lässt sich tortzdem evtl. viel einsparen :)
Hi, habe jetzt mal den Si1102 getestet... Erstmal ist das Ding so winzig, dass es mich an meine Grenzen gebracht hat, was das Anlöten des Lackdrahtes an die 7 winzigen Pads (0,3mm x 0,3mm) angeht. Habe es dann zusammen mit einer SFH4056 IR-Diode ausprobiert. Es wäre wohl besser, eine Diode mit einem "narrow beam" zu nehmen, in der application note haben sie eine SFH4650 verwendet. Das Ding ist so empfindlich, dass ich erst an einen Fehler in der Schaltung gedacht habe, weil es kontinuierlich etwas detektiert hat :-) Musste dann die Empfindlichkeit herabsetzen und IR-Diode und den Empfänger wirklich optisch etwas isolieren. Danach hat es immer noch meine Hand in ca. 10cm locker erkannt. Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich befürchte ja, dass das Milchglas an sich schon reflektiert und somit schon zu einer (Falsch-)Erkennung führt. Grüße Markus
Angehängte Dateien:
-
IR-Reflexion.png
25 KB
Markus M. schrieb: > Hi, > > habe jetzt mal den Si1102 getestet... > > Erstmal ist das Ding so winzig, dass es mich an meine Grenzen gebracht > hat, was das Anlöten des Lackdrahtes an die 7 winzigen Pads (0,3mm x > 0,3mm) angeht. > > Habe es dann zusammen mit einer SFH4056 IR-Diode ausprobiert. Es wäre > wohl besser, eine Diode mit einem "narrow beam" zu nehmen, in der > application note haben sie eine SFH4650 verwendet. > > Das Ding ist so empfindlich, dass ich erst an einen Fehler in der > Schaltung gedacht habe, weil es kontinuierlich etwas detektiert hat :-) > Musste dann die Empfindlichkeit herabsetzen und IR-Diode und den > Empfänger wirklich optisch etwas isolieren. Danach hat es immer noch > meine Hand in ca. 10cm locker erkannt. > > Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich > befürchte ja, dass das Milchglas an sich schon reflektiert und somit > schon zu einer (Falsch-)Erkennung führt. > > Grüße > Markus Qualitativ hört sich das gut an, ich denke aus dieser Perspektive könnte man die Erkennung kaum besser lösen. Das mit dem Milchglas oder Plexi müsste man einfach ausprobieren. Ich vermute, dass es deutlichen Einfluss auf die Erkennungsschwelle hat, weil man die Reflexion unter die Empfindlichkeitsschwelle nehmen müsste. Heisst die Reichweite sinkt. Müsste aber ok sein, das haben ja andere mit so einem Tisch auch schon gelöst. Und das wird bei jeder Lösung so sein. Die Frage ist aber, ob so ein Bauteil nötig ist. Kostet zusätzliches Geld (2,80 Euro hab ich gerade gefunden), ist fummelig zu löten. Und ein uC ist für Bus und PWM sowieso schon da, m.E. kann der die IR-Touch-Erkennung gleich mitmachen. Ein IR-Emitter, eine IR-Diode und ein Opamp sind günstiger als der Si1102 alleine. Man müsste mal einen Prototypen machen, der tut wie ich es oben vorgeschlagen habe und herausfinden ob das funktioniert und wie gut. Evtl. findet sich noch eine Lösung den Opamp rauszulassen, dann wär's optimal. Bzgl. der Reflexion: Vielleicht könnte man die Unterseite sogar mit einer reflexionsreduzierenden Schicht bekleben, es macht sicher einen drastischen Unterschied ob man eine spiegelnde Plexi/Glas-Fläche hat, die den IR-Strahl direkt und konzentriert auf den Empfänger zurückwirft oder ob man eine matte Folie davor hat, die das IR in alle Richtungen verteilt. Die Verteilung/Diffusion sollte das auf den Sensor reflektierende IR auf einen Bruchteil (Fünftel, Zehntel?) reduzieren und die Empfindlichkeit der Touch-Erkennung wieder entsprechen anheben. Das hat mich jetzt mal genauer interessiert. Siehe angehängte Grafik: Bei direkter Reflexion trifft ca. 10% der Lichtenergie des IR-Emitters wieder den Empfänger. Wenn es durch eine Matte Folie "in alle Richtungen" verteilt wird, ist es sicher kaum mehr 1%, also ein Zehntel oder weniger. (Der IR-Empfänger ist hier in ein kleines schwarzes Röhrchen gepackt, das sicherstellt, dass er nur Licht von oben bekommt).
:
Bearbeitet durch User
Es gibt jetzt einen Artikel, wo wir Erkenntnisse dokumentieren können: http://www.mikrocontroller.net/articles/RGB_Touch_Matrix Ich würde vorschlage nur einigermassen fertig ausdiskutierte oder getestete Lösungen dort zu hinterlassen. Also Diskussion, Lösungserarbeitung hier, Ergebnis im Artikel.
Markus M. schrieb: > Hi, > > habe jetzt mal den Si1102 getestet... > > > Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich > befürchte ja, dass das Milchglas an sich schon reflektiert und somit > schon zu einer (Falsch-)Erkennung führt. > > Grüße > Markus also ich habe wie gesagt mit dem is471 getestet (mit milch lichtdurchlässigen acryl/plexiglas). es ging wunderbar. ich musste nur die ausrichtung von sensor und ir-led etwas verändern und gegenseitig abschirmen, aber mein prototyp steht hier und funktioniert soweit einwandfrei. einzige problem besteht dabei, wenn die plexiglas nur ein wenig neigung hat, dann detektiert der sensor auch das glas (aufgrund des winkels). habe ca. 4-5cm abstand zwischen glas und led/sensor. und meine hand wird bis knapp 1-2cm über dem glas erkannt mich würde nur noch interessieren, ob eine lösung mittels ir-fototransistor + verstärkerschaltung besser bzw. günstiger ist als die is471, weil die preislich doch etwas reinhauen bei mehreren pixeln
:
Bearbeitet durch User
Tim R. schrieb: > Markus M. schrieb: >> Hi, >> >> habe jetzt mal den Si1102 getestet... >> >> >> Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich >> befürchte ja, dass das Milchglas an sich schon reflektiert und somit >> schon zu einer (Falsch-)Erkennung führt. >> >> Grüße >> Markus > > also ich habe wie gesagt mit dem is471 getestet (mit milch > lichtdurchlässigen acryl/plexiglas). es ging wunderbar. ich musste nur > die ausrichtung von sensor und ir-led etwas verändern und gegenseitig > abschirmen, aber mein prototyp steht hier und funktioniert soweit > einwandfrei. einzige problem besteht dabei, wenn die plexiglas nur ein > wenig neigung hat, dann detektiert der sensor auch das glas (aufgrund > des winkels). habe ca. 4-5cm abstand zwischen glas und led/sensor. und > meine hand wird bis knapp 1-2cm über dem glas erkannt 1-2cm ist fast ein bisschen wenig. Denke es sollte mehrere cm über dem Tisch beginnen, damit es nicht unangenehm zu bedienen ist? > mich würde nur noch interessieren, ob eine lösung mittels > ir-fototransistor + verstärkerschaltung besser bzw. günstiger ist als > die is471, weil die preislich doch etwas reinhauen bei mehreren pixeln Fototransistor m.E. ist zu langsam, wenn man mit einer Trägerfrequenz arbeitet, siehe oben. Bei 50-100 kHz ist das genau die Größenordnung, die der Fototransistor zu reagieren braucht.
@Markus falls du dir zum testen eine kleine plexiglasscheibe holen magst: http://www.ebay.de/itm/PLEXIGLAS-Acrylglas-milchglas-79-Lichdurchlaessigkeit-4mm-kostenloser-Zuschnitt-/111002520558 habe mir dort eine 10x10x4mm besorgt (schnelle lieferung), um so den touch zu testen... denn ohne plexiglas sind alle testreihen die wir hier aufstellen eigentlich wertlos ;-)
Conny G. schrieb: > Tim R. schrieb: > > 1-2cm ist fast ein bisschen wenig. Denke es sollte mehrere cm über dem > Tisch beginnen, damit es nicht unangenehm zu bedienen ist? > das ist jedem sein empfinden würde ich fast behaupten. aber zur not klemmt ein poti am is471, womit ich die reichweite etwas hochschrauben kann. ich persönlich möchte eigentlich nicht meine hand weit über den tisch halten, sondern wie beim smartphone oder ähnlichen richtiges "touch" verwenden, deshalb habe ich die reichweite eingegrenzt >> mich würde nur noch interessieren, ob eine lösung mittels >> ir-fototransistor + verstärkerschaltung besser bzw. günstiger ist als >> die is471, weil die preislich doch etwas reinhauen bei mehreren pixeln > > Fototransistor m.E. ist zu langsam, wenn man mit einer Trägerfrequenz > arbeitet, siehe oben. Bei 50-100 kHz ist das genau die Größenordnung, > die der Fototransistor zu reagieren braucht. vorallem haben die keine filter für das umgebungslicht oder ? hab zumindest nur normale transis gesehen die auch IR erkennen, aber nicht dafür "optimiert" waren... um es mal zusammen zufassen: wahlweise würden is471 oder der Si1102 unsere ansprüche umsetzen, richtig? :-) wie sieht es eigtl. mit den TSOP aus, hat da jemand zufällig einen rumliegen? grüße
...naja, der Si1102 hat auch mit einer roten LED funktioniert. Er funktioniert wohl zwischen 600nm und 950nm. Ist somit nicht wirklich optimal, da ja dann auch die LEDs selbst alles beeinflussen würden. Für die Lösung mit einem µC je Pixel: Es gibt durchaus Phototransistoren, die relativ selektiv sind was die Wellenlänge angeht. Z.B. Osram SFH 310 FA oder 309 FA (andere Wellenlänge) oder auch Vishay TEFT4300 (sind jetzt alles TH Bauteile). Idealerweise sollte man ein Modell finden, welches direkt ohne OP an den A/D-Wandler angeschlossen werden kann. Man müsste dann natürlich ein bisschen Hirnschmalz in das Programm auf dem Controller stecken, um eine gute Detektion zu erreichen. Aber da der Controller ja weiß, wann die IR-LED an/aus ist, muss er ja "nur" die Differenz des Signals vom Phototransistor nehmen, diese integrieren (aufsummieren über die Zeit) und hätte einen ersten Anhaltspunkt. Man könnte die weiteren Parameter für die Erkennung dann per Software gut anpassen. Wenn man zusätzlich die RGB-LED ansteuern will und noch den BUS realisieren muss, kommt man allerdings mit dem kleinsten AVR nicht mehr hin. Grüße Markus
Markus M. schrieb: > ...naja, der Si1102 hat auch mit einer roten LED funktioniert. Er > funktioniert wohl zwischen 600nm und 950nm. > > Ist somit nicht wirklich optimal, da ja dann auch die LEDs selbst alles > beeinflussen würden. Stimmt, der ist zu breit für eine gefilterte Wahrnehmung. Ist nicht einmal ein Wellenlängendiagramm drin, was dafür spricht, dass die Empfindlichkeit recht breit aufgestellt ist. > Für die Lösung mit einem µC je Pixel: > > Es gibt durchaus Phototransistoren, die relativ selektiv sind was die > Wellenlänge angeht. Z.B. Osram SFH 310 FA oder 309 FA (andere > Wellenlänge) oder auch Vishay TEFT4300 (sind jetzt alles TH Bauteile). Ich hatte darüber nachgedacht die Frequenz von IR-Fernbedienungen zu verwenden, also um die 40 Khz. Hierfür würde ein Fototransistor nicht funktionieren, weil der schon 2,5us zum schalten benötigt. 40 kHz ist 25us für eine Periode. Das ist eher kritisch, wenn die Schaltfrequenz so nah an der Messfrequenz ist. Also müsste man mit der Messfrequenz nach unten gehen, was aber eigentlich kein Problem wäre, wenn man nach dem Schema vorgeht: 1. IR-LED an 2. IR-Lichtstärke messen (generiertes IR-Licht) 3. IR-LED aus 4. IR-Lichtstärke messen (Fremdlicht) 5. Differenz berechnen -> weiter bei 1 Und das für 10-20 Zyklen und den Mittelwert als Messwert verwenden Dann muss man eigentlich nicht wie die TSOP etc. das tun mit einer Trägerfrequenz und Frequenzfilter arbeiten, weshalb die wohl eine recht hohe Frequenz verwenden. Nach oben geschriebenem Algorithmus ist die Messfrequenz eigentlich fast egal, sie sollte nur hoch genug sein, dass man genügend Messwerte für einen Durchschnittswert in kurzer Zeit herausbekommt. Sagen wir mal wir wollen 10-20 Touch-Werte pro Sekunde und 100 Samples für einen Messwert. Dann müsste 1.000 Mal pro Sekunde gemessen werden, das schafft auch noch ein Fototransistor. Man könnte dann auch noch auf 10 Khz gehen und das wäre für einen Fototransistor noch schaffbar (1 Periode = 40 x Schaltzeit Fototransistor). > Idealerweise sollte man ein Modell finden, welches direkt ohne OP an den > A/D-Wandler angeschlossen werden kann. Man müsste dann natürlich ein > bisschen Hirnschmalz in das Programm auf dem Controller stecken, um eine > gute Detektion zu erreichen. Aber da der Controller ja weiß, wann die > IR-LED an/aus ist, muss er ja "nur" die Differenz des Signals vom > Phototransistor nehmen, diese integrieren (aufsummieren über die Zeit) > und hätte einen ersten Anhaltspunkt. Man könnte die weiteren Parameter > für die Erkennung dann per Software gut anpassen. > > Wenn man zusätzlich die RGB-LED ansteuern will und noch den BUS > realisieren muss, kommt man allerdings mit dem kleinsten AVR nicht mehr > hin. Was brauchen wir denn... genügend Taktzyklen und genügend Pins. Taktzyklen halte ich aus dem Bauch nicht für das Problem. Pins: - 3 Pins für RGB, Software-PWM 8 Bit mit 1 8 Bit Timer - 1-2 Pins für den Bus, 1 16 Bit Timer - 1 Pin A/D Wandler für IR-Messung = 6 Pins gesamt Damit geht's nicht mehr mit einem 6-Beiner, mindestens 8 braucht es, wenn man das RESET Pin als normales Pin schaltet. Als kleinster also Attiny13. Der hat aber nur einen 8 Bit Timer, damit bliebe der Bus ohne Timer. Evtl. könnte man aber auch Bus und PWM mit einem 8 Bit-Timer schaffen.
Conny G. schrieb: > 1. IR-LED an > 2. IR-Lichtstärke messen (generiertes IR-Licht) > 3. IR-LED aus > 4. IR-Lichtstärke messen (Fremdlicht) > 5. Differenz berechnen > -> weiter bei 1 > Und das für 10-20 Zyklen und den Mittelwert als Messwert verwenden wie dolle streut denn solch ein bauteil? wenn ich 20 mal messe und alle werte relativ große schwankungen aufweisen, ist das auch nur halb gewonnen. könnte man zwar mitteln, aber die streuung bleibt trotzdem relativ hoch. aber der ansatz wäre eine günstige alternative > Pins: > - 3 Pins für RGB, Software-PWM 8 Bit mit 1 8 Bit Timer > - 1-2 Pins für den Bus, 1 16 Bit Timer > - 1 Pin A/D Wandler für IR-Messung > = 6 Pins gesamt also ein einziger Pixel-/Controller benötigt nach dem bisherigen Schema was wir überlegt hatten: -3 Pins RGB, PWM mit 8 Bit Timer -4 Pins Bus (1x RGB in, 1x RGB out, 1x Sensorwert in, 1x Sensorwert out) -Clock? -ADC je nach dem welche Variante verwendet wird =7-9 Pins gesamt... nach meiner Rechnung?
Tim R. schrieb: > Conny G. schrieb: >> 1. IR-LED an >> 2. IR-Lichtstärke messen (generiertes IR-Licht) >> 3. IR-LED aus >> 4. IR-Lichtstärke messen (Fremdlicht) >> 5. Differenz berechnen >> -> weiter bei 1 >> Und das für 10-20 Zyklen und den Mittelwert als Messwert verwenden > > wie dolle streut denn solch ein bauteil? wenn ich 20 mal messe und alle > werte relativ große schwankungen aufweisen, ist das auch nur halb > gewonnen. könnte man zwar mitteln, aber die streuung bleibt trotzdem > relativ hoch. aber der ansatz wäre eine günstige alternative Was meinst Du mit streuen? >> Pins: >> - 3 Pins für RGB, Software-PWM 8 Bit mit 1 8 Bit Timer >> - 1-2 Pins für den Bus, 1 16 Bit Timer >> - 1 Pin A/D Wandler für IR-Messung >> = 6 Pins gesamt > > > also ein einziger Pixel-/Controller benötigt nach dem bisherigen Schema > was wir überlegt hatten: > -3 Pins RGB, PWM mit 8 Bit Timer > -4 Pins Bus (1x RGB in, 1x RGB out, 1x Sensorwert in, 1x Sensorwert out) > -Clock? > -ADC je nach dem welche Variante verwendet wird > =7-9 Pins gesamt... nach meiner Rechnung? Du hast recht, ich hab die Daisy Chain vergessen, sorry :-) Also 6 oder 8 Pins, je nachdem ob Sensorbus separat oder nicht: 3 Pwm, 2 Bus, 1 ADC = 6 Optional plus 2 Sensorbus.
wenn mehrere messungen alleine für das umgebungslicht angenommene Werte annehmen wie: 26 48 65 33 18 45... dann kann man das zwar mitteln, aber ob man dann den tatsächlich schwellwert für "touch aktiv" oder "touch nicht aktiv" erreicht ist relativ fraglich weil die streuung der werte so groß ist dass der fehler dementsprecht ansteigt. große streuung (also schwankung) der werte zieht einen großen fehler mit sich. oder seh ich das falsch?! ich kann leider nicht beurteilen wie gut diese sensoren mit infrarot sind und dann zusätzlich noch einer rgb im nacken... bei der variante mit dem is471 fällt der adc pin weg ;-P gibts denn überhaupt einen attiny mit 3 PWM kanälen? hatte gerade ein datenblatt offen wo leider 2 drin stand ps: conny hast du meine nachricht bekommen?
:
Bearbeitet durch User
Tim R. schrieb: > wenn mehrere messungen alleine für das umgebungslicht angenommene Werte > annehmen wie: 26 48 65 33 18 45... dann kann man das zwar mitteln, aber > ob man dann den tatsächlich schwellwert für "touch aktiv" oder "touch > nicht aktiv" erreicht ist relativ fraglich weil die streuung der werte > so groß ist dass der fehler dementsprecht ansteigt. große streuung (also > schwankung) der werte zieht einen großen fehler mit sich. oder seh ich > das falsch?! ich kann leider nicht beurteilen wie gut diese sensoren mit > infrarot sind und dann zusätzlich noch einer rgb im nacken... Das mag sein, dass die Messwerte streuen, aber es sind halt Messwerte. Die sind ja dann für sich nicht falsch und ein fertiger Sensor hat doch genau dasselbe und muss damit arbeiten. Deshalb verstehe ich die Sorge nicht, denn wenn so ein fertiger Sensor das schafft dann wir auch. Ein Fototransistor den wir verwenden ist ja auch nicht um eine Zehnerpotenz ungenauer als die Fotozelle eine fertigen Sensors? > bei der variante mit dem is471 fällt der adc pin weg ;-P > gibts denn überhaupt einen attiny mit 3 PWM kanälen? hatte gerade ein > datenblatt offen wo leider 2 drin stand Ich schrieb schon Soft PWM, brauchen für 3 windige 8 Bit Kanäle keine Hardware PWM. > ps: conny hast du meine nachricht bekommen? Ja, und geantwortet, aber Deine Emailadresse Bounces, "Mailbox Not available". Hab die Antwort per PN hier geschickt.
Hi, also der "Algorithmus" macht in etwa das was die Näherungssensoren auch tun: - IR LED aus - A = Spannung am Phototransistor - IR LED an - B = Spannung am Phototransistor - Summe += (A-B) Die Summe über die Zeit X ergibt dann die Menge des reflektierten Lichtes. Wenn man dann noch einen Schwellwert einbaut hat man eigentlich schon ein einfaches Verfahren. Nehmen wir mal an eine Messung dauert 50 µs (wie schnell ist der A/D-Wandler des ATtiny?), dann haben wir 20k Messungen pro Sekunde. /2 wg. der IR-LED aus Phase und dann sagen wir mal 10 Messungen zum Aufsummieren... ergibt 1 ms für die Messung. Man könnte dann während der Messung sogar die RGB-PWM ruhen lassen um Seiteneffekte zu vermeiden. An Pins benötigt man m.E. mindestens: - IR LED Ausgang, könnte aber sein dass man da noch einen Treibertransistor benötigt, um der IR LED einen etwas höheren Strom zu geben (lt. Datenblatt max. 40mA für einen ATtiny 44/84). oder man schaltet zwei Ausgänge parallel... - R/G/B LED Ausgang - A/D-Wandler Eingang - Bus (In/Out) - Reset/debugWire Komme da also leider auf 8 I/O-Pins. Grüße Markus
:
Bearbeitet durch User
Markus, Du hast recht, IR Out habe ich auch noch vergessen! Ja, dann sind wir incl Reset bei 8 und man könnte sich mal die zweitkleinsten Tinys ansehen.
um mal vom theoretischen teil in die praxis zu kommen... hat denn jemand mal entsprechend bauteile für nen kurzen mess- bzw. testaufbau, ob das auch alles so funktioniert, wie gedacht? ;-P
Ich hätte ein paar Atmega8 und Attiny da (für einen ersten Bustest oder den IR-Detektor Test müssten es noch nicht die finalen uCs sein), aber leider gar keine Zeit, weil ich noch 2 andere Projekte fertigzustellen habe.
Düsendieb schrieb: > https://www.youtube.com/watch?v=Z3dSurrH-Gc > > ist es das? Ne, cooler: https://www.youtube.com/watch?v=DTb0k_P1wlY
Conny G. schrieb: > Ja, und geantwortet, aber Deine Emailadresse Bounces, "Mailbox Not > available". Hab die Antwort per PN hier geschickt. ja stimmt mein acc hier läuft auf eine uralt trach mail :-/ aber wo seh ich hier denn meine PNs? ich stell mich gerade richtig glatt an und finde kein postfach oder so *peinlich
Die PNs werden per Email weitergeleitet. Vermutlich an genau dieses Emailpostfach :-)
bin dabei die email zu tauschen, warte auf den admin.. ähm... weiter im thread?... oder erstmal den anderen thread weiterfüllen ? :-)
Conny G. schrieb: > > Du hast recht, ich hab die Daisy Chain vergessen, sorry :-) > Also 6 oder 8 Pins, je nachdem ob Sensorbus separat oder nicht: > 3 Pwm, 2 Bus, 1 ADC = 6 > Optional plus 2 Sensorbus. da fällt mir ein... wenn ich von einer 6pin ISP zum programmieren ausgehe, sind 4 Pins extra nötig... es sei denn man nimmt ein schaltungsdesign vor womit die pins zum proggen und ein/ausgabe verwendet werden können... ich weiß nur nicht wie dabei eine logik aussehen müsste, habe bisher isp immer extra beschalten
Die ISP Pins kann man problemlos mit anderer Funktion belegen solange die andere Funktion nicht die Programmierung stört. Oft braucht man keine extra Beschaltung dafür, manchmal tun es Widerstände zu den anderen Bauteilen, manchmal muss man einen digitalen Switch vorsehen, der durch RESET umgeschaltet wird.
Hier auf Seite 7 steht was dazu: http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf Shared use of SPI programming lines If additional devices are connected to the ISP lines, the programmer must be protected from any device, other than the AVR, that may try to drive the lines. This is especially important with the SPI bus, as it is similar to the ISP interface. Applying series resistors on the SPI lines, as depicted in Figure 3-2, is the easiest way to achieve this. Note that the AVR will never drive the SPI lines in a programming situation, since the AVR is held in RESET to enter programming mode – and RESET’ing the AVR tri-states all pins. D.h. wenn die Daisy Chain sicher nicht angesteuert wird während programmiert wird muss man nicht einmal den Widerstand einfügen.
:
Bearbeitet durch User
http://www.mikrocontroller.net/articles/AVR_In_System_Programmer ganz unten steht etwas zur benutzung der pins :-) problematisch wird es beim eingang, sofern dieser nicht durchgeschaltet ist. im Text steht: "Als Eingänge sollte man die Pins allerdings nicht verwenden, da ein angeschlossener Taster zum Beispiel die Programmierimpulse kurzschließen würde, wenn er gedrückt ist. " da an jeder seite ein weiter pixel oder ein master klemmt, könnte das sogar problematisch werden oder nicht? zum programmieren müsste die komplette kommunikation still gelegt sein alternativ könnt man einfach einen großen jumper zum programmiermodus abkommandieren, ist nur etwas nervig das ständige umschalten *g switch der an reset geschaltet ist, wird denke ich die sicherste methode sein, welchezugleich nicht kompliziert ist
:
Bearbeitet durch User
Sollte es möglich sein, dass andere in der Chain senden, dann könnte man die in der Appnote genannten Schutzwiderstände verwenden. Es macht aber eigentlich keinen Sinn, dass man die Pixel-Slaves mitten in der laufenden Schaltung programmiert. Und wenn der Master (die Tisch-Steuerung) aus ist, dann tun auch die Pixel Slaves nichts. Ansonsten kann man dem auch ganz aus dem Weg gehen und die ISP-Pins für PWM verwenden. Vielleicht sollte man aber sowieso über einen Bootloader nachdenken, der die Firmware automatisch von Pixel zu Pixel weitergibt :-)
Conny G. schrieb: > Sollte es möglich sein, dass andere in der Chain senden, dann könnte man > die in der Appnote genannten Schutzwiderstände verwenden. > Es macht aber eigentlich keinen Sinn, dass man die Pixel-Slaves mitten > in der laufenden Schaltung programmiert. > Und wenn der Master (die Tisch-Steuerung) aus ist, dann tun auch die > Pixel Slaves nichts. ja stimmt, an den schlafenden master hatte ich nun gar nicht gedacht... guten morgen g > > Ansonsten kann man dem auch ganz aus dem Weg gehen und die ISP-Pins für > PWM verwenden. > > Vielleicht sollte man aber sowieso über einen Bootloader nachdenken, der > die Firmware automatisch von Pixel zu Pixel weitergibt :-) daran hatte ich auch schon gedacht, nur fand ich einen bootloader etwas "überzogen", bin zufrieden wenn das ganze auch so erstmal steht hehe... aber um nicht 100pixel nach einander programmieren zu müssen wäre eine lösung "über-bus-programmierung" schon sehr hilfreich
:
Bearbeitet durch User
Könnte eigentlich genauso funktionieren wie die Daisy Chain à la ws2811... die Firmware wird direkt weitergeschickt. Es müsste nur ein Trigger-Event geben, wann und warum die Slaves alle im Bootloader bleiben. Dazu hatte ich schon mal drangedacht, dass man 4 Bytes statt 3 übertragen könnte. Einerseits könnte man dann 10 Bit PWM machen, also 3x10= 30 bit und hat dann noch 2 Bits für Protokoll-Befehle. Und da könnte ein Befehl sein: RGB-Daten. Ein weiterer Sensor-Daten-Rückwärtsgang. Und ein dritter: Bootloader-Modus. Die Slaves blieben dann nach dem Start für xxx Millisekunden im Bootloader, ob das Kommando kommt und wenn nicht -> normales Programm. Wenn Bootloader, dann wird jedes Byte gespeichert und gleich weitergereicht. Und das funktioniert dann genauso wie die RGB-Übermittlung. Und wenn es beim Flashen einen CRC-Fehler gibt, dann schaltet der Slave die LED auf rot, die anderen auf grün.
Oder... jeder Slave flasht (per Bootloader) seinen Nachbarn sobald er selbst fertig ist. Damit könnte eine Wiederholung automatisch durchgeführt werden, wenn mal der CRC-Check daneben geht.
das wäre ein guter ansatz. ich muss gestehen ich habe bisher bootloader nur verwendet aber selbst noch nie implementiert. kann man die einfach (in C) programmieren?! muss man irgendwas wichtig beachten?! ich müsste mir an der stelle erstmal ein wenig lektüre besorgen bei 10bit ist der nette nebeneffekt, dass 1024 statt 256 farben theoretisch angesteuert werden könnten :-) ein CRC wäre an der stelle ein muss. ich sehe schon ich produziere dann nur rote lichter ich habe grad mal nach jahre das gute alte eagle vorgeholt. der tiny13 reicht, wie besprochen, nicht aus... bin gerade am tiny23 dran nen pinkompatiblen chip in eagle zu finden... aber an sich sollte der genug IOs haben. kann die tage ja mal den kleinen schaltplan hochladen und dann kann das entwerfen der pixelplatine schon mal los gehen
Bootloader ist nicht so schwierig, habe ich mich schon einmal einen kurzen Abend damit beschäftigt und ein Progrämmchen gemacht, das auf dem Uart sich dann als Bootloader meldet. Ist ziemlich leicht ein C-Programm als Bootloader zu deklarieren, im Prinzip muss es nur in die Bootloader-Section geschrieben werden beim Flashen und die Bootloader-Fuses gesetzt werden (BL an und Startadresse). War noch nicht da dann auch das Flash zu schreiben, aber da gibt's viele Bootloaderprojekte oder Tutorials für, vermute das wäre ein weiterer Abend oder zwei/drei bis das tut. Hier: http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung Bis 6. hab ich's getestet.
:
Bearbeitet durch User
für mich klingt das gerade nach jemandem, der sich freiwillig meldet ? ;-)
Tim R. schrieb: > für mich klingt das gerade nach jemandem, der sich freiwillig meldet ? > ;-) Prinzipiell sehr gerne. Ich habe aber noch ein Projekt fertigzustellen, das noch um die 8 Wochen dauern wird, bis dahin nur Zeit zum Senf dazugeben.
Conny G. schrieb: > Tim R. schrieb: >> für mich klingt das gerade nach jemandem, der sich freiwillig meldet ? >> ;-) > > Prinzipiell sehr gerne. Ich habe aber noch ein Projekt fertigzustellen, > das noch um die 8 Wochen dauern wird, bis dahin nur Zeit zum Senf > dazugeben. per spi einfach den bootloader reinladen wird wohl nicht funktionieren oder? es ist also ein isp-programmer dafür nötig...?! ansonsten kann man wirklich die komplette programmer schnittstelle "weglassen"
:
Bearbeitet durch User
Tim R. schrieb: > Conny G. schrieb: >> Tim R. schrieb: >>> für mich klingt das gerade nach jemandem, der sich freiwillig meldet ? >>> ;-) >> >> Prinzipiell sehr gerne. Ich habe aber noch ein Projekt fertigzustellen, >> das noch um die 8 Wochen dauern wird, bis dahin nur Zeit zum Senf >> dazugeben. > > per spi einfach den bootloader reinladen wird wohl nicht funktionieren > oder? es ist also ein isp-programmer dafür nötig...?! ansonsten kann man > wirklich die komplette programmer schnittstelle "weglassen" Nein, man muss den Bootloader schon vorher per ISP laden, dann kann man die Firmware mit dem Bootloader "wie auch immer" laden. (Den Bootloader kann man sicher auch aus der Software schreiben, aber irgendwas muss auf dem uC laufen um ins Flash zu schreiben). Man könnte aber für den Fall, dass man den Bootloader ersetzen muss einen Tag-Connect-Port vorsehen http://www.tag-connect.com/catalog/6 Der Witz daran ist, dass man keine Headerleiste oder Stecker braucht, sondern nur Pads und Löcher auf der Platine hat auf die man das Kabel aufsteckt. In 2-3 Wochen kann ich wohl was dazu dagen, ob es gut funktioniert. Das Kabel habe ich mir gerade gekauft und den Tag-Connect in eine Schaltung eingebaut, die ich gerade mache.
Es wäre schon möglich, dass ein Modul das nächste programmiert ohne dass zuvor ein Bootloader installiert wurde. Fast jeder Atmega-Chip kann ein ISP-Programmer sein! Dazu müssen nur die 3 SPI-Pins und der Reset-Pin des in der Kette nächsten, zu programmierenden Moduls mit 4 beliebigen Pins des vorherigen Moduls verbunden werden. Das sind leider dann 4 Leitungen von jedem Modul zu seinem Nachfolger, wodurch das Ziel Kabel zu sparen natürlich angegriffen wird. Im Gegenzug muss man die Module dann aber nur löten und verkabeln und nicht auch noch mit einem Bootloader programmieren! Passender Source-Code würde sich bei Guloshop.de finden. Dort gibt es einen Programmer auf attiny85-Basis und auch den freien Source-Code. Dieser Programmer macht das zum Programmieren nötige SPI-Protokoll direkt per Port-Programmierung. Mit diesem Code könnte man bei einem attiny84 oder 2313 wohl 4 beliebige freie Pins mit den zum programmieren benötigten Pins des Nachfolgemoduls verbinden. Der bei der Arduino-Software beiliegende Arduino-ISP Sketch ist auch interessant, aber weniger gut geeignet, weil er die Daten auf die ISP-Schnittstelle wirklich per HW-ISP des Atmega328p rausschreibt. D.h. SPI des Programmierers mit mit SPI des programmierten verbunden sein.
also die funktion der pixel sollte anhand von einem prototypen aufbau mit 2-3 pixeln denke ich erstmal gemacht werden und anschließend sollte die software stehen... also nur im notfall wird dann nochmal die software für jeden pixel geändert werden... und dafür nen extra bootloader? zumal die pixel eh eine ISP brauchen, würde ich den bootloader erstmal als gimmick/feature betrachten oder nicht? die geräte habe ich schon mal gesehen, fand ich ziemlich interessant... kannst ja mal berichten tiny als DIP?
Christian H. schrieb: > Es wäre schon möglich, dass ein Modul das nächste programmiert ohne dass > zuvor ein Bootloader installiert wurde. > > Fast jeder Atmega-Chip kann ein ISP-Programmer sein! Das habe ich schon bedacht, aber wg. der Zielsetzung einen schlanken Bus zu haben, gleich ausgenommen. Ich würde nicht mit 4 Leitungen von Pixel zu Pixel gehen wollen, nur um die programmieren zu können.
Tim R. schrieb: > also die funktion der pixel sollte anhand von einem prototypen aufbau > mit 2-3 pixeln denke ich erstmal gemacht werden und anschließend sollte > die software stehen... also nur im notfall wird dann nochmal die > software für jeden pixel geändert werden... und dafür nen extra > bootloader? zumal die pixel eh eine ISP brauchen, würde ich den > bootloader erstmal als gimmick/feature betrachten oder nicht? ISP muss nicht. Man könnte die ICs auch alle vor dem Einlöten programmieren. Nur für eine einmalige Nutzung wäre wirklich auch ein ISP unnötig. Der Bootloader ist wirklich nicht unbedingt erforderlich. Auf der anderen Seite ist es einfacher ein bisschen Software auf allen Pixel zu haben um die in einer Chain alle zu aktualisieren als einen ISP Header auf jedem. So ein Tag Connect wäre allerdings wieder nicht so schlecht, denn es kostet nur einen Quadratzentimeter Platinenplatz und sonst keine Bauteilkosten oder Löterei. Dann kann man jederzeit programmieren, wenn man will, braucht aber nicht 100 Header einlöten. Zusammengefasst: - die Software der Pixel ist (und muss) simpel sein - ann muss der Pixel nur 1x programmiert werden - ISP-Header für 1x ist quatsch - Bootloader wäre "nett", muss aber nicht - also OOSP (Out of system programming :-) oder Tag Connect - falls die Pixel in china hergestellt werden (empfehlenswert), dann Tag Connect
:
Bearbeitet durch User
ich würde dann einfach zum DIP greifen... sockel auf platine löten und die chips alle extern bespielen und anschließend raufklemmen... FALLS wirklich mal eine änderung nötig ist, kann man die chips immernoch rausholen und muss nicht entlöten bootloader sehe ich auch als feature der tag connect ist nett aufjedenfall... aber ob man das extra geld dafür aufbringen mag... ich weiß nich so recht der tisch verschlingt an sich genügend geld :-)
Wenn die Platinen in China bestückt werden... ist es günstiger DIP oder SMD zu bestücken oder egal? Ggf. wäre das ein Grund lieber einen Programmierheader oder Tag-Connect zu nehmen als DIP und Sockel. Man müsste frühzeitig hier Angebote einholen und entscheiden ob selbst oder Ausland, da die Auftragsbestückung erheblichen Einfluss auf das Platinendesign nimmt. Wenn man selbst 100 Stück bestückt und nur die Platinen bestellt, dann nimmt man lieber DIP als dass man 20x seinen Pizzaofen laufen lässt. Wenn man Auftragsbestückung macht und es zeigt sich, das SMD günstiger, einfacher oder was weiss ich ist, dann ist SMD angesagt.
kenne mich mit fertigung aus asien nich sonderlich aus, vllt kann ja mal jemand ein link einwerfen oder selbst erfahrungswerte beisteuern ? :-) ich wäre für platinenfertigung und die controller selbst aufbringen, hat den vorteil, dass notfalls die wirklich nochmal runterkönnen (anders als beim smd löten)... ist zwar ein tag arbeit ungefähr 100 stück zu machen, aber gut, dafür sparen wir an anderen stellen haufen arbeit so hab mal den tiny2313 im dip im schaltplan drin mit dem is471... teurer sensor aber ich habe bisher keine wirkliche alternative deswegen lass ich den sensor erstmal soweit drin, kann ja ggf noch geändert werden... hatten wir eigtl schon über die leds gesprochen?!
:
Bearbeitet durch User
hab mal eben rumgeschaut nach "starken" rgb-leds... http://www.leds24.com/SuperFlux-RGB-LED-3-Chip-diffus-50-rot-gruen-blau-steuerbar 7,62mm, 20mA pro Chip Lichtintensität Chip: rot=2500mcd - grün=4000mcd - blau=2000mcd oder http://www.led1.de/shop/led-rainbow-rgb-ultrahell/48mm-rgb/strawhat-led-48mm-rgb-4-pin-wedrgb03-cm.html?xploidID=78cvmdt90dggek448avtu1l4q1 4,8mm, 20mA Max. Lichtstärke: 500mcd (rot) 1.800mcd (grün) 400mcd (blau) aber vllt gibts ja bei ebay auch gute pakete mit 100 stück oder so? die Frage ist auch, eine oder mehrere RGB pro Pixel? bei it-gecko.com wurde eine led pro pixel genommen und sah eigtl auch ausreichend aus denke ich. von daher würde ich zu einer led tendieren nur weiß ich nicht so recht was für welche, weil des doch schon recht krasse unterschiede gibt
:
Bearbeitet durch User
Über einen Bootloader habe ich auch nachgedacht zum programmieren der Pixels. Habe auch nach RGB-LEDs geschaut. Ich verstehe nicht, wieso bei den günstigen z.B. Blau die geringste Lichtstärke hat, eigentlich wird es doch vom Auge am "schlechtesten" wahrgenommen?! Relativ ausgeglichene LEDs werden dann wohl schon wieder teurer... aber auch da müsste man wohl verschiedene ausprobieren und schauen ob sie den Ansprüchen genügen... Die Strawhead LEDs sehen aber ganz gut aus. Habe mal die Kosten pro Pixel überschlagen und komme leider auf so ca. 4 EUR pro Pixel... (ATtiny44A, IR-LED, IR-Phototransistor, Hühnerfutter, RGB-LED) zzgl. Platinchen...
Sollte man auf ausgewogene Lichtstärke von RGB schauen? Die zweiteren haben ja R G B ein Verhältnis von 1 : 3,5 : 0,8, das ist schon extrem Richtung grün. Man sollte eine Kalibrierung vornehmen um bei 100% alle auf gleicher Helligkeit zu haben (R G B nebeneinander auf 100% sollten gleich hell aussehen), damit würde man das schon kompensieren, aber verschwendet damit 70% der Leistung der grünen. Bzgl. Lichtstärke müsste man es einfach mal testen und ein paar kleine Boxen aus Pappe bauen im Format einer Zelle, also 6x6x6 cm, in einer Höhe von ca. 10cm und unten dann diverse Test LEDs in verschiedenen Stückzahlen einsetzen und die Farben durchtesten. Vielleicht erstmal 1 Stück und die Farben von verschiedenen Modell anschauen und danach die Helligkeit zwischen 1 und 3 Stück. Idealerweise würde man von den Farben bei moderatem Tageslicht auch noch was sehen. Für den Helligkeitstest könnte an auch erstmal mit Abschnitten eines WS2812(B) testen und davon 1, 2, 3 in die Box legen. Dann kennt man den Wert an Lumen (Leistung ohne Winkelabhängigkeit) bzw. Candela (mit Winkelabhängigkeit), den man braucht. Ich glaube das ist ein einfacher Ansatz, mit den WS2812 zu testen. Sofern dort im Datenblatt die Lichtstärken angegeben sind. Bzgl. des Winkels sehe ich 120 Grad eigentlich als Verschwendung von Lichtleistung, besser hätten sie 30-60 Grad. Denn wg. möglichst engem Winkel des IR-Sensings (jede Zelle sollte eigentlich nur vertikal nach oben und wenig zur Seite messen) sollte die Platine etwas weiter unten sitzen (mind. 10 cm) und dann habe ich nach oben einen Winkel von < 45 Grad. Und alles was die RGB-LEDs breiter strahlen geht einfach nur an die Seitenwand und wird nur teilweise reflektiert, selbst wenn die Seitenwand weiss ist. Bauform ist eigentlich egal, höchstens noch von der Bestückung (selbst oder China) abhängig. Können auch relativ gross sein, haben 6x6cm Platz. Habe mir kürzlich 8mm WS2811 RGBs bestellt, die sind ziemlich hell. Habe die auch noch ohne WS2811, müsste mal testen, ob die genauso hell sind. Datenblatt habe ich leider keins dazu, die mcd/lm Werte nachzusehen...
:
Bearbeitet durch User
Markus M. schrieb: > Habe mal die Kosten pro Pixel überschlagen und komme leider auf so ca. 4 > EUR pro Pixel... (ATtiny44A, IR-LED, IR-Phototransistor, Hühnerfutter, > RGB-LED) zzgl. Platinchen... Und dann sind sie noch nicht bestückt, oder?
Hier mal die nächstbesten 8mm RGB, die Google ausgespuckt hat: http://www.powerledworld.com/de/20pcs-x-8mm-4pin-rgb-common-anode-led-light-redgreenblue-water-clear.html?language=de¤cy=EUR Sehen gar nicht mal so schlecht aus. Abstrahlwinkel 35% finde ich bestens. 7 Euro / 20 = 35 Cent ist zu teuer, das geht m.E. für die Hälfte. Die sind richtig hell, Winkel 20 Grad (fast ein bisschen wenig): http://www.leds24.com/10mm-3-Chip-Rainbow-RGB-4-Pin-LED-20-RGB-LEDs-steuerbar?gclid=CO7uyKSMz70CFQIcwwod5F0AKw Die Superflux, die Du schon gefunden hattest: http://www.leds24.com/SuperFlux-RGB-LED-3-Chip-diffus-50-rot-gruen-blau-steuerbar sind etwa gleich hell, haben aber doppelten Winkel. Der Winkel von 50% passt aber ganz gut.
:
Bearbeitet durch User
Also beim WS2812Bhttp://www.mikrocontroller.net/attachment/180459/WS2812B_preliminary.pdf haben wir: RGB IC characteristic parameter Emitting color Model Wavelength(nm) Luminous intensity(mcd) Red 13CBAUP 620-625 390-420 Green 13CGAUP 522-525 660-720 Blue 10R1MUX 465-467 180-200 also R = 400mcd, G = 700mcd, B = 200mcd, wobei der Abstrahlwinkel hier auch mind. 120 Grad ist. Gegenüber den Superflux RGB: 7,62mm, 20mA pro Chip Lichtintensität Chip: rot=2500mcd - grün=4000mcd - blau=2000mcd ist das etwa ein Fünftel. Man könnte es also ungefähr vergleichen, wie die Helligkeit der Superflux herauskommt, wenn man 4-5 der WS2812b in so eine 6x6cm Testbox packt und weisses/diffuses Plexiglas drüberlegt.
:
Bearbeitet durch User
heißt das die superflux sind dementsprechend 4 mal so hell oder wie kann man diese werte interpretieren? dein letzter satz hat es eigentlich erst interessant gemacht... wie sieht das ganze unter plexiglas aus ;-) wir können mutmaßen über abstände und lichtstärken, aber wie es im endeffekt ausschaut weiß man nicht, oder? ich würde mich entschließen eine superflux oder andere led zu besorgen und mal unter meine lichtdurchlässige plexiglas vom touch-testaufbau zu packen... habe ich das richtig verstanden, dass der abstand zwischen plexi und platine ~10cm bei dir in anspruch nehmen soll? ich bin momentan bei der hälfte... Markus M. schrieb: > Habe mal die Kosten pro Pixel überschlagen und komme leider auf so ca. 4 > EUR pro Pixel... (ATtiny44A, IR-LED, IR-Phototransistor, Hühnerfutter, > RGB-LED) zzgl. Platinchen... solange aber kein testaufbau mit einem ir-transi mal aufgebaut wurde, würde ich dort keine 100 stück bestellen ? .-) klang bisher simpel aber sollte zumindest mit einem prototypen belegbar sein... ich wundere mich gerade wie bei gleicher stromaufnahme und anliegenden spannungen solch enorme lichtstärkenunterschiede zustande kommen... hat da jemand evtl. eine erläuterung?
:
Bearbeitet durch User
Tim R. schrieb: > heißt das die superflux sind dementsprechend 4 mal so hell oder wie kann > man diese werte interpretieren? Man muss bei den Lichtstärkeangaben immer aufpassen, ob es winkelabhängig (mcd = Candela) oder unabhängig (Lumen) ist. Lumen heisst: Lichtleistung insgesamt, die abgestrahlt wird, in alle Richtungen. Wird deshalb auch für die Angabe Lumen/Watt verwendet -> wieviel der Stromleistung wird in Lichtleistung umgewandelt. Das macht nur Sinn ohne Abstrahlwinkel. Cancela ist eine relative Einheit: http://de.wikipedia.org/wiki/Candela Die Candela [kanˈdeːla] [1] (lateinisch für Kerze) ist die SI-Basiseinheit der Lichtstärke, das heißt des von einem Objekt in eine gegebene Richtung ausgesandten Lichtstroms pro Raumwinkeleinheit (Steradiant, sr), gemessen in großer Entfernung von der Lichtquelle. D.h. wieviel wird pro "sr" ausgesandt. > ich wundere mich gerade wie bei gleicher stromaufnahme und anliegenden > spannungen solch enorme lichtstärkenunterschiede zustande kommen... hat > da jemand evtl. eine erläuterung? Und deshalb sind die "mcd" bei der einen LED mit dem kleineren Abstrahlwinkel viel größer, weil dieselbe Lichtenergie auf einen kleineren Winkel abgestrahlt wird. Entscheidend ist jetzt: Wir sehen nur das Licht, das oben auf die 6x6cm Plexiglasplatte trifft, d.h. am besten passt der Abstrahlwinkel möglichst gut zur Entfernung der LED von der Plexiglasplatte und dem dadurch aufgespannten Winkel, dann ist sie maximal hell im vgl. zur Lichtleistung, die sie insgesamt hat. Denn alles, was an die Seitenwand geht ist "verloren". (Naja, es wird reflektiert, aber dabei verlieren wir einen großen Anteil davon, denn es ist bestenfalls weiss und kein Reflektor, der es nach oben strahlt). > dein letzter satz hat es eigentlich erst interessant gemacht... wie > sieht das ganze unter plexiglas aus ;-) > wir können mutmaßen über abstände und lichtstärken, aber wie es im > endeffekt ausschaut weiß man nicht, oder? Ja, das lässt sich nicht über die reinen Lichtstärkewerte abschätzen. ABER: Man kann von z.B. den WS2812B ungefähr auf andere LEDs schliessen, wenn man mal ermittelt hat, wieviel man davon haben will. Oder jede andere LED zum Test, wo man die Lichtstärke kennt. > ich würde mich entschließen eine superflux oder andere led zu besorgen > und mal unter meine lichtdurchlässige plexiglas vom touch-testaufbau zu > packen... > > habe ich das richtig verstanden, dass der abstand zwischen plexi und > platine ~10cm bei dir in anspruch nehmen soll? ich bin momentan bei der > hälfte... Die 10cm verfolgen folgenden Gedanken: Für die Abstrahlung der RGB LED ist es wurst, solange der Abstrahlwinkel der LED zusammen mit der Entfernung das Plexi genau ausleuchten. Aber für das Touch-Sensing ist es m.E. sehr wichtig, dass der Winkel des Infrarotstrahls sehr eng ist, also am besten nur 10 Grad, höchstens 20 Grad. Denn jede Zelle des Tischs soll die Bewegungen ja auch nur darüber messen und nicht noch die Nachbarzelle. Extremes Beispiel: bei 5cm Abstand und >70-80 Grad Abstrahlwinkel der IR-LED könnte der IR-Sensor nicht mehr unterscheiden, ob die Bewegung nun über seinem Feld oder über dem Nachbarfeld stattgefunden hat, denn wenn Du 5cm über das Plexi gehst, geht der Strahl bereits bis zur Mitte des Nachbarfeld. Deshalb sollte die Platine möglichst weit nach unten, damit es nach oben wie ein "Rohr" wird. Man könnte IR-LED und Sensor auch mit einem Röhrchen abschirmen, aber dann ergibt sich das gegenteilige Problem, dass direkt über dem Plexi der "Kreis" zu klein wird und der Rand nicht erfasst wird. Hatte dazu weiter oben schon mal eine Skizze eingestellt, oder? Ach, die war zum Vorschlag, dass man die Unterseite des Plexi oder Glases mit einer Entspiegelfolie bekleben sollte um das von dem Plexi direkt reflektierte IR-Licht möglichst viel zu streuen.
:
Bearbeitet durch User
das mit dem licht ergibt sinn, ich hätte wohl doch mal fix dr. goggle öffnen sollen :-) Conny G. schrieb: > Die 10cm verfolgen folgenden Gedanken: > Für die Abstrahlung der RGB LED ist es wurst, solange der Abstrahlwinkel > der LED zusammen mit der Entfernung das Plexi genau ausleuchten. > > Aber für das Touch-Sensing ist es m.E. sehr wichtig, dass der Winkel des > Infrarotstrahls sehr eng ist, also am besten nur 10 Grad, höchstens 20 > Grad. > Denn jede Zelle des Tischs soll die Bewegungen ja auch nur darüber > messen und nicht noch die Nachbarzelle. > > Extremes Beispiel: bei 5cm Abstand und >70-80 Grad Abstrahlwinkel der > IR-LED könnte der IR-Sensor nicht mehr unterscheiden, ob die Bewegung > nun über seinem Feld oder über dem Nachbarfeld stattgefunden hat, denn > wenn Du 5cm über das Plexi gehst, geht der Strahl bereits bis zur Mitte > des Nachbarfeld. > > Deshalb sollte die Platine möglichst weit nach unten, damit es nach oben > wie ein "Rohr" wird. > Man könnte IR-LED und Sensor auch mit einem Röhrchen abschirmen, aber > dann ergibt sich das gegenteilige Problem, dass direkt über dem Plexi > der "Kreis" zu klein wird und der Rand nicht erfasst wird. also das problem hatte ich bei meinen 5cm nicht. eher genau andersrum. meine bewegungen wurden erst zur "mitte" am genausten erkannt... also ein finger war sehr kritisch, bei zwei fingern wurde es dann sehr zuverlässig... und sobald beide finger nah der mitte waren wurde erkannt... wenn sie ansatzweise einen anderen pixel berührt hätten, hätte das diesen pixel nicht interessiert... vllt stell ich die tage mal nen vid online... ich verstehe deinen gedankengang, aber müsste mal schauen wie der is471 bei 10cm abstand überhaupt wirkt
hätte ja nicht gedacht das man so etwas mit fototransistoren hinbekommt... schönes teil aufjedenfall, danke für den link! mit fototransistoren... aber wie funktioniert das genau, dass die farbe festgestellt wird, müssen ja gute filter sein :)
:
Bearbeitet durch User
Conny G. schrieb: > In etwa so: > http://www.instructables.com/id/Introduction-29/?lang=de ja hatte eben ähnliche seiten gefunden... etwas aufwendig aber machbar
Wirklich interessant der Tisch mit der Farberkennung Anstelle von Fototransistoren mit Filtern könnte man für die Farberkennung auch fertige Sensoren nutzen. Damit sollte sich eine Farberkennung relativ einfach gestalten. Bei meinen Recherchen vor einiger Zeit habe ich die unten stehenden Produkte gefunden. Leider waren von kaum einem Hersteller Muster zu bekommen und auch bei Mouser / Digekey sind diese Bausteine oft nicht auf Lager (Mindestbestellmenge dann teilweise 2000 Stück). MAXIM MAX44005, MAX44006, MAX44008 TAOS / AMS TCS3103, TCS3104, TCS3404, TCS3414 TCS3471x, TCS3472x, TCS3772x (x=1,3,5,7) Intersil ISL29120, ISL29125 Kingbright KPS-5130PD7C Ich habe aktuell ein paar TCS34725 zum Test für ein anderes Projekt auf dem Schreibtisch liegen. Leider fehlt mir die Zeit mich mit einem weiteren Projekt aktiv zu beschäfigen. Die TCS34725 sind in einem DFN-6 SMD Gehäuse und damit nicht ganz einfach ohne Reflow-Ofen zu bestücken. Bei einem Preis von knapp EUR 2,- pro Stück aber für die Farberkennung recht praktisch.
Könnte man nicht für sehr kurze Zeit Rot, dann Grün, dann Blau mit der sowieso vorhandenen PWM-gesteuerten LED anzeigen um die aufliegenden Gegenstände zu bestrahlen und jeweils den einen Phototransistor pro Modul abfragen um so die reflektierte Menge Licht für R, G und B zu erhalten? Danach kann die LED wieder PWM machen, bis zur nächsten Messung.
Bleiben wir doch lieber erstmal beim Touch Sensing.
Christian H. schrieb: > Könnte man nicht für sehr kurze Zeit Rot, dann Grün, dann Blau mit der > sowieso vorhandenen PWM-gesteuerten LED anzeigen um die aufliegenden > Gegenstände zu bestrahlen und jeweils den einen Phototransistor pro > Modul abfragen um so die reflektierte Menge Licht für R, G und B zu > erhalten? Danach kann die LED wieder PWM machen, bis zur nächsten > Messung. finde den einwand gar nich so schlecht :-) man müsste nur einen geeigneten fotowiderstand oder ähnliches finden... würde damit der "touch" nicht auch funktionieren? einzige problem seh ich, wenn sich zwischenzeitig das umgebungslicht ändert
:
Bearbeitet durch User
tester schrieb: > http://www.reichelt.de/Optokoppler/ELI-TR9904/3/index.html?&ACTION=3&LA=2&ARTICLE=114342&GROUPID=3046&artnr=ELI+TR9904 der zufall wollte es so, mein kollege hat mir aus seinem bauteilreservoir so eine lichtschranke vorzaubern können... im datenblatt konnt ich nichts zur reichweite finden, ausser dass es für "scanner" und ähnliches geeignet ist... deshalb habe ich die IR-led von diesem bauteil an den ausgang von meinem is471 gehängt, damit ich nicht selbst fix ein programm schreiben muss für das signal... ich muss aber sagen, die erkennungsreichweite liegt bei irgendwie zwischen 0-2cm... also quasi gar nichts. mein poti der den transistor basis für die ir-led regelt konnte dabei auch nicht wirklich viel ändern. denke das mein aufbau soweit richtig ist, aber lasse mich gerne eines besseren belehren, wenn jemand erfahrung mit dem oben genannten bauteil hat ? :-) ansonsten schade, bleibe ich bis dato bei dem is471... ps.: leben die anderen teilnehmer hier noch ? :-P
:
Bearbeitet durch User
Lebe noch. Aber habe kein Interesse an der RGB Farbmessung. Lieber ein guter IR Touch Sensor. Und da kann ich vor Testaufbau nichts dazu sagen. Und für den habe ich gerade keine Zeit. Muss erst dieses Teil hier finalisieren, produzieren, programmieren, testen. Beitrag "Re: Review von Schaltung und Routing" Und danach eine Steuerung entwickeln die das DMX dafür sendet, sowie zwei weitere Lichtobjekte via Lichtschalter und Lan steuerbar macht.
Conny G. schrieb: > Lebe noch. Aber habe kein Interesse an der RGB Farbmessung. die war auch eher geflaxt... glaub das nimmt noch mehr zeit in anspruch die ich zumindest nicht habe.. > Lieber ein > guter IR Touch Sensor. deswegen habe ich noch eine alternativen fototransistor getestet, aber mit mäßgem erfolg... na dann viel erfolg!
um die diskussion mal wieder ein wenig voran zu treiben: mir kam ein gedanke beim foren-stöbern... wie wäre es mit einer mechanischen auswertung? zum beispiel mit waagen an jeder ecke oder kante... kann mir nur nicht genau vorstellen, wie genau dann die pixel ausgewertet werden können nachteil: man muss berühren und ggf etwas fester drücken... ein drüber wischen oder im millimeterabstand drüber halten ist dann nicht mehr viel.. vorteil: kostengünstiger als fertig IR, wie es mit selbst erbrachter IR erkennung aussieht, schwer zu sagen... bisher kam leider keine zumindest brauchbare/getestete lösung
Hi, tester schrieb: > mir kam ein gedanke beim foren-stöbern... wie wäre es mit einer > mechanischen auswertung? zum beispiel mit waagen an jeder ecke oder > kante... kann mir nur nicht genau vorstellen, wie genau dann die pixel > ausgewertet werden können Vorschlag wurde weiter oben sogar schon einmal gemacht. Mit persönlich gefällt das nicht, und ich bin auch skeptisch was die Auswertung angeht, gerade in Bezug auf "Multitouch". Mit IR hingegen ist das alles möglich -- zumindest theoretisch. Ich hatte letztes Jahr etwas ähnliches vor (nachdem ich o.g. YouTube Video gesehen habe) und bin interessanterweise in vielerlei Hinsicht zu den selben Schlüssen gekommen, d.h. modular und Auswertung per IR. Bin dabei auf die Kombination ELPD204-6B und ELIR604-6B gestoßen, da diese günstig sind und Datenblatt technisch gut zusammen passen. Ich hatte mir allerdings überlegt ggf. jeweils 2 oder 4 Dioden pro Modul zu verwenden, um auch am Rand eine vernünftige Empfindlichkeit gewährleisten zu können. Allerdings spielt hierbei die geometrische Anordnung eine Rolle, sodass Reflexionen nicht von den Nachbarn ausgewertet werden. Eventuell würde sich das aber auch mit ein bisschen Logik in der Software verhindern lassen, immerhin weiß ja die Software wann mit Reflexionen zu rechnen ist (also wann die IR-LEDs an sind). Habe das Ganze auch vor mir liegen, bin allerdings noch nicht dazu gekommen einen vernünftigen Versuchsaufbau anzufertigen. Wurde sich denn mittlerweile schon auf die Größe eines Pixels geeinigt? Rein vom Bus her sind wir wohl auf (höchstens) 200 Module beschränkt. Alles darüber wird schon eine Herausforderung. Insofern würde ich 10x10cm vorschlagen, womit sich z.B 1x2m Fläche füllen lassen würden. Ggf. müsste man die Module selbst aber kleiner gestalten, sodass die einzelnen Zellen 10x10 cm groß sind. Das hängt dann aber von der verwendeten Technik ein. Ich dachte hier an Holz, welcher per Laser geschnitten wird. Das hat sich im 3D-Druck bewährt und ist verhältnismäßig stabil und günstig. Was den Mikrocontroller angeht: Man kann auch ein paar Pins sparen, indem man auf echte LED-Treiber setzt. Würde das Ganze gerne hell haben, und da stoßen meiner Erfahrung nach die Mikrocontroller an ihre Grenzen, zumindest, wenn man die Datenblattkonform betreiben möchte. IR-LEDs vertragen i.d.R. mehr Strom und es macht wahrscheinlich Sinn das auszunutzen, um das SNR aufzubessern. Ein entsprechenden LED-Treiber vorausgesetzt könnte man sich auch die Software-PWM sparen. Andererseits treibt das natürlich wieder die kosten in die Höhe. Wir sollten uns im Übrigen auch auf das Material der Oberfläche einigen. Plexiglas halte ich persönlich für nicht so schön, weil ich Glas für beständiger und kratzfester halte, wenn man den Tisch wirklich als Tisch benutzten sollte. Wie seht ihr das Alles? Besteht überhaupt noch Interesse an einem "gemeinsame" Projekt? Scheint ja trotz der anfänglichen Euphorie ein bisschen eingeschlafen zu sein das Ganze ... Mit freundlichen Grüßen, Karol Babioch
Hi, so ganz grundsätzlich verfolge ich das schon noch. Allerdings habe ich momentan weder Zeit noch Geld einen "richtigen" Tisch zu bauen. Deine Meinung zu der Oberfläche (echtes Glas) teile ich. Die Oberfläche wird direkt Auswirkungen auf die Auswertung/Aufbau der Berührungserkennung haben. Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten ist o.ä. Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl. der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht) und entsprechende IR LEDs (passende Wellenlänge zu dem IR Phototransistor). Wenn die Auswertung/IR-Abtastung der Berührung/Näherung "Pixelweise" nacheinander erfolgt, sollten sich doch die Reflexionen von Nachbarpixeln in Grenzen halten. Aber man müsste das wirklich alles mal an einem "Messaufbau" z.B. 3x3 Pixel) testen. Ob man die IR-LEDs wirklich mit höherem Impulsstrom betreiben muss wird sich zeigen. Wir haben letztendlich mehrere Baustellen: - Mechanischer Aufbau (Material, Dicke, Abstände etc.) - IR Sender / Empfänger Auswertungsmimik - "Beleuchtung" (RGB LED, ggf. Treiber oder WS2812B?) - Kommunikation zwischen den Pixeln bzw. Anbindung über einen Bus (inkl. Möglichkeit einer automatischen Neuprogrammierung der Pixelcontroller) Ciao... Markus
:
Bearbeitet durch User
Markus M. schrieb: > Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert > werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten > ist o.ä. > Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst > großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl. > der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht) > und entsprechende IR LEDs (passende Wellenlänge zu dem IR > Phototransistor). Das mit dem breiten Erfassungswinkel ist der falsche Ansatz. Sonst kann man zwei Zellen nebeneinander nicht unterscheiden, wenn es keine scharfe Zellenabgrenzung gibt. Der Strahl muss aus jeder Zelle relativ steil herauskommen, dazu braucht es ein Stück Abstand von der Oberfläche. Kann man selber ausrechnen: bei ca. 7x7cm Zellengröße (60x60 Tisch als eine Größenoption mit 10x10 Zellen) und nur 90 Grad Abstrahlwinkel wird eine Hand bei einem Abstand von 5cm noch in der Mitte der Nachbarzelle erfasst - das nimmt dem Konzept jede "Schärfe" in der Erkennung. Wenn man steileren Winkel will, kommt man um eine gewisse Aufbauhöhe, wie 10cm, nicht herum (wenn man mit 1 IR-LED arbeiten will. Mir mehreren kann man auch welche mit schmalem Winkel nehmen oder sie in ein Röhrchen stecken. Aber mehrere ist m.E. bei 100 Zellen keine Optione).
Karol Babioch schrieb: > Wie seht ihr das Alles? Besteht überhaupt noch Interesse an einem > "gemeinsame" Projekt? Scheint ja trotz der anfänglichen Euphorie ein > bisschen eingeschlafen zu sein das Ganze ... Schon interessiert an dem Tisch, aber wie erwähnt hab ich kaum / keine Zeit. Wird bei mir eher noch (2-3?) Monate dauern, bis aktuelle Elektronikprojekte abgefrühstückt sind.
Angehängte Dateien:
-
Table_V01.png
30 KB
schön zu lesen, dass es doch noch interessierte gibt ich bin momentan auf wohnungssuche und würde nach erfolgreichem umzug mich wieder intensiv dem thema widmen. Markus M. schrieb: > Deine Meinung zu der Oberfläche (echtes Glas) teile ich. Die Oberfläche > wird direkt Auswirkungen auf die Auswertung/Aufbau der > Berührungserkennung haben. Wollt ihr ein durchsichtiges Glas benutzen? Dann sieht man die ganze Elektronik, was denk ich keiner will. Also wird es ein mattes Glas werden. Das Problem dabei ist, es muss relativ gut Lichtdurchlässig sein. Gibt es geeignete Gläser dafür die auch bezahlbar sind? Ich hab mich aus Kostengründen und weil mein Test erfolgreich mit Plexiglas war, eben für lichtdurchlässige Acryl-Milchgläser entschieden > Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert > werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten > ist o.ä. das denke ich auch > Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst > großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl. > der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht) > und entsprechende IR LEDs (passende Wellenlänge zu dem IR > Phototransistor). > > Wenn die Auswertung/IR-Abtastung der Berührung/Näherung "Pixelweise" > nacheinander erfolgt, sollten sich doch die Reflexionen von > Nachbarpixeln in Grenzen halten. > > Aber man müsste das wirklich alles mal an einem "Messaufbau" z.B. 3x3 > Pixel) testen. Mein nächster Test sollte eine Kaskadierung von 3-4 Pixeln sein, zum Testen der Kommunikation und zum feststellen, wie sehr sich die IR Sensoriken beißen > > Ob man die IR-LEDs wirklich mit höherem Impulsstrom betreiben muss wird > sich zeigen. > > Wir haben letztendlich mehrere Baustellen: > > - Mechanischer Aufbau (Material, Dicke, Abstände etc.) ich würde ein 5x5cm Feld als Größe vorschlagen. 10x10cm ist ziemlich groß meines erachtens > - IR Sender / Empfänger Auswertungsmimik > - "Beleuchtung" (RGB LED, ggf. Treiber oder WS2812B?) da jeder Pixel eine einzelne RGB benötigt (oder auch mehrere), würde ich zu relativ starken LEDs tendieren ohne extra Treiber. Die PWM kann auch leicht ein ATTiny liefern > - Kommunikation zwischen den Pixeln bzw. Anbindung über einen Bus (inkl. > Möglichkeit einer automatischen Neuprogrammierung der Pixelcontroller) Diese Thematik war meines erachtens relativ weit voran geschritten. Im DaisyCHain (Kaskadierung) der Pixel kann einfach und komfortabel eine Kommunikation geschaffen werden. Jeder Pixel hat 2 In- und 2 Outputs. RGB_IN, RGB_OUT, TOUCH_IN, TOUCH_OUT... Der Mastercontroller sendet in jeweils 3Byte (RGB) für jeden Teilnehmer dessen Farbwerte. Der Master schiebt also den Datenzug von 3Byte mal x Pixel an. Der erste Teilnehmer entnimmt seine 3Byte Daten (RGB_IN) und schiebt die restlichen Daten weiter (RGB_OUT). Die Pixel senden nach erfolgreichem Empfangen ihren Touch-Status an den Master (ggf. über mehrere Pixel) über TOUCH_OUT. Die Pixel die dazwischen liegen nehmen am TOUCH_IN den Touch Status vom nachliegenden Pixel auf und senden diesen in der Reihe weiter. Ich glaub ich habe das ganze gerade etwas umständlich erklärt, aber zur Not stehen ja oben nochmal mehrere Erläuterungen ;-) Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig Software... und das ganze kann auf alle Pixel geflasht werden. > > Ciao... > Markus Im Anhang befindet sich mal ein fixer Schaltplan von mir, so wie ich es mal mit der IS471 angedacht hatte. Ich werde mir gleich mal die eben geposteten Sensoren anschauen, evtl sind die besser. Ihr könnt ja einfach mal Kritik/Vorschläge/Ideen hageln lassen. :-) Grüße Tim ps: http://www.mikrocontroller.net/articles/RGB_Touch_Matrix
:
Bearbeitet durch User
Tim R. schrieb: > Im Anhang befindet sich mal ein fixer Schaltplan von mir, so wie ich es > mal mit der IS471 angedacht hatte. Ich werde mir gleich mal die eben > geposteten Sensoren anschauen, evtl sind die besser. Ihr könnt ja > einfach mal Kritik/Vorschläge/Ideen hageln lassen. :-) Das Problem des IS471 ist halt der Preis. Meine Lösung auf Basis von ELPT204-6B und ELIR204-6B kostet pro Pixel nur 40 Cent. Habe das Ganze mittlerweile auch getestet und halte das Ergebnis für gut. Mein Pixel ist 10x10 Pixel groß und 8 cm hoch. Das ist ziemlich groß, werde es nachher nochmal kleiner basteln. Der Unterschied zwischen "nichts aufgelegt" und "Hand aufgelegt" liegt derzeit bei 980 mV, und ist gut detektierbar. Interessanter wird es bei "Finger am Rand" aufgelegt, da wird der Unterschied entsprechend kleiner und eine echte Herausforderung. Mit kleineren Pixeln sollte das aber hoffentlich besser werden. Andererseits heißt kleinere Pixel = mehr Pixel = höhere Anforderung an den Bus. 10x10 sollen es bei mir schon werden, mehr ist besser, irgendwann dann allerdings natürlich auch eine Frage des Geldes ;). Was haltet ihr denn von dem Vorschlag mehrere IR-Dioden (zumindest Photodioden für den "Empfang") zu verwenden. Damit dürften sich nämlich Reflexionen aus anderen Zellen erkennen lassen, weil nicht alle "Empfänger" (gleich stark) angestrahlt werden. Die Frage ist nur wie viele vertretbar sind, wie viele Pins wir übrig haben und welche geometrische Anordnung sich hierfür anbietet? Tim R. schrieb: > da jeder Pixel eine einzelne RGB benötigt (oder auch mehrere), würde ich > zu relativ starken LEDs tendieren ohne extra Treiber. Die PWM kann auch > leicht ein ATTiny liefern Starke LEDs + kein Treiber ist ein wenig ein Widerspruch. AVRs sind i.d.R. für irgendwas zwischen 20 mA und 40 mA spezifiziert. Meistens schaffen sie nicht mal das, wenn mehrere Pins gleichzeitig beansprucht werden. In Software kann (je nach Taktfrequenz und je nachdem wie genau wir den Bus implementieren) eine 8-Bit PWM schon eine Herausforderung werden. Dot-Correction haben wir da dann auch noch nicht. RGB kostet mindestens auch 3 Pins. LED Treiber kümmern sich um all das, machen den Hardware Aufbau einfacher (keine Widerstände notwendig) und brauchen zum Teil nur ein einzigen Pin. Insofern tendiere ich ganz stark für den Einsatz eines solchen Treibers. Tim R. schrieb: > Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig > Software... und das ganze kann auf alle Pixel geflasht werden Apropos flashen: Was ist aus der Bootloader Idee geworden? Wenn wir uns nämlich wirklich für mehrere IR-Photodioden + Logik in Software zur Detektion entscheiden sollten, wäre es immer denkbar, dass man "Verbesserungen"/Kalibrierungen einspielen möchte. Manuell 100+ Pixel zu flashen, macht dann wohl keinen Spaß mehr ;). Mit freundlichen Grüßen, Karol Babioch
ja ich weiß die sind leider teuer... aber bieten auch etwas dafür, finde ich mehrere sensoren wäre auch eine idee... ich kann nur nicht abschätzen wie die software dazu aussehen müsste bzw. ob dazu ein cleverer algo nötig ist, um fremdeinwirkendes IR ausschließen zu können Ok etwas unglücklich ausgedrückt. natürlich wird eine extra beschaltung für die leds nötig. wie im schaltplan zu sehen hatte ich erstmal an transistoren zum schalten gedacht und dann sollte das ja kein problem darstellen, oder? led-treiber per i2c oder was schwebt dir vor? der benötigt eben auch nur wieder extra platz und erzeugt kosten. aber an sich vereinfacht das natürlich eine menge im datenblatt findet man leider keine distanzen zu dem sensor... aber wenn du meinst e funktioniert gut, kannst du gerne mal ein video oder ähnliches hochladen, wo die masse den effekt auch beobachten kann :-) grüße
:
Bearbeitet durch User
Tim R. schrieb: > ja ich weiß die sind leider teuer... aber bieten auch etwas dafür, finde > ich Nichts was man nicht für 1/5 des Preises selbst bauen könnte, zumindest für unsere Ansprüche ... Tim R. schrieb: > mehrere sensoren wäre auch eine idee... ich kann nur nicht abschätzen > wie die software dazu aussehen müsste bzw. ob dazu ein cleverer algo > nötig ist, um fremdeinwirkendes IR ausschließen zu können Wir müssten uns einfach auf die Größe eines Pixels festlegen. Habe jetzt zuletzt mit 5x5x3 cm gearbeitet, finde das fast ein wenig klein, bzw. bin mir nicht sicher, ob wir die Elektronik + Steckverbindungen nachher wirklich auf dieser Fläche unterbringen. Mehrere Sensoren machen bei dieser Größe vermutlich auch gar keinen Sinn. Bei 10x10 hingegen sieht das schon wieder anders aus. Tim R. schrieb: > Ok etwas unglücklich ausgedrückt. natürlich wird eine extra beschaltung > für die leds nötig. wie im schaltplan zu sehen hatte ich erstmal an > transistoren zum schalten gedacht und dann sollte das ja kein problem > darstellen, oder? Prinzipiell natürlich möglich. Erfordert aber alles extra Beschaltung. Ich persönlich mag bipolare Transitoren ala BC337 nicht besonders für diesen Zweck. FETs sind mir da lieber. Außerdem hast du noch die Basistransistoren vergessen ;). Tim R. schrieb: > led-treiber per i2c oder was schwebt dir vor? der benötigt eben auch nur > wieder extra platz und erzeugt kosten. aber an sich vereinfacht das > natürlich eine menge Die gibt es in verschiedenen Ausführungen. Gibt auch echte Einpin-Lösungen, die implizit über das Timing gesteuert werden. Klar, ein bisschen teurer wird es (im Vergleich zu Widerständen + BC337). Platztechnisch könnte das aber sogar günstiger sein. Da wir mit der Diodenlösungen aber 2 Euro sparen (im Vergleich zu IS471), haben wir in dieser Beziehung etwas mehr Spielraum. Habe mir noch nicht alle Optionen angesehen, aber die gehen so in etwa bei 50 Cent los, und sollten hoffentlich für unter 1 Euro zu bekommen sein. Tendenziell haben wir auch den Vorteil, dass wir eine entsprechende Sammelbestellung organisieren könnten. Da wohl jeder mindestens 100+ Module braucht, kommen wir da schnell in einen "günstigeren" Bereich. Tim R. schrieb: > im datenblatt findet man leider keine distanzen zu dem sensor... aber > wenn du meinst e funktioniert gut, kannst du gerne mal ein video oder > ähnliches hochladen, wo die masse den effekt auch beobachten kann :-) Sind ja auch keine Distanzsensoren, sondern IR-Photodioden. Diese als Touch-"Sensor" zu verwenden ist im Prinzip nur eine "kreative" Anwendung. Die mögliche Entfernung hängt von vielen Faktoren ab - unter anderem wie stark die IR-LED ist und wie stark das Glas reflektiert. Bin mit dem Ergebnis bei einem einzigen Pixel zufrieden. Werde sehen, dass ich das bis zum nächsten Wochenende zu einer 3x3 Konstruktion ausbaue und auch vernünftig per Mikrocontroller auswerte. Derzeit fehlen z.B. noch die RGB-LEDs, aber die sollten laut Datenblatt der IR-Photodiode kein allzugroßen Effekt haben. Komme dann hoffentlich auch dazu ein Demo-Video anzufertigen. Unabhängig davon sollten wir uns aber trotzdem auf einige Dinge festlegen, bevor wir wirklich weiter machen können: - Größe (Länge, Breite, Höhe) eines Pixels -> Mein Vorschlag: 5x5x3 cm - Maximale Anzahl von Pixeln -> Mein Vorschlag: 20x20 wären schön, je nach Bus wird das aber "schwierig" - Typ und Stärke der Oberfläche: Das hat vermutlich den größten Einfluss. Werde zusehen, dass ich ein paar Muster bestelle, um das dann auch testen zu können. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Nichts was man nicht für 1/5 des Preises selbst bauen könnte, zumindest > für unsere Ansprüche ... das ist richtig. wie reagiert dein sensor bei verschiedenen umgebungshelligkeiten? der is471 nutzt ja extra filter, was ich sehr gut fand > Wir müssten uns einfach auf die Größe eines Pixels festlegen. Habe jetzt > zuletzt mit 5x5x3 cm gearbeitet, finde das fast ein wenig klein, bzw. > bin mir nicht sicher, ob wir die Elektronik + Steckverbindungen nachher > wirklich auf dieser Fläche unterbringen. Mehrere Sensoren machen bei > dieser Größe vermutlich auch gar keinen Sinn. Bei 10x10 hingegen sieht > das schon wieder anders aus. stimmt das könnte ein problem werden, bei einem 5x5 feld. evtl. doch ein 10x10cm feld?! so lässt sich mit einer 10er reihe auch ein tisch von einem meter länge gut erreichen :-) bei 5x5cm feldern müssten schon knapp 20 pixel in eine reihe (+overhead vom gerüst) > Prinzipiell natürlich möglich. Erfordert aber alles extra Beschaltung. > Ich persönlich mag bipolare Transitoren ala BC337 nicht besonders für > diesen Zweck. FETs sind mir da lieber. Außerdem hast du noch die > Basistransistoren vergessen ;). könntest du mir näher erläutern was du mit basistransistor meinst? > Tendenziell haben wir auch den Vorteil, dass wir eine entsprechende > Sammelbestellung organisieren könnten. Da wohl jeder mindestens 100+ > Module braucht, kommen wir da schnell in einen "günstigeren" Bereich. grundsätzlich ja! müssten sich nur zum gegebenen zeitpunkt genügend einfinden und genau da sehe ich das problem ;-) bisher ist die resonanz zum wirklichen umsetzen/basteln gering.. > Sind ja auch keine Distanzsensoren, sondern IR-Photodioden. Diese als > Touch-"Sensor" zu verwenden ist im Prinzip nur eine "kreative" > Anwendung. Die mögliche Entfernung hängt von vielen Faktoren ab - unter > anderem wie stark die IR-LED ist und wie stark das Glas reflektiert. > > Bin mit dem Ergebnis bei einem einzigen Pixel zufrieden. Werde sehen, > dass ich das bis zum nächsten Wochenende zu einer 3x3 Konstruktion > ausbaue und auch vernünftig per Mikrocontroller auswerte. Derzeit fehlen > z.B. noch die RGB-LEDs, aber die sollten laut Datenblatt der > IR-Photodiode kein allzugroßen Effekt haben. Komme dann hoffentlich auch > dazu ein Demo-Video anzufertigen. welche RGBs willst du benutzen?!
Tim R. schrieb: > das ist richtig. wie reagiert dein sensor bei verschiedenen > umgebungshelligkeiten? Umgebungslicht hat natürlich einen Einfluss, sofern man sich das am Oszilloskop ansieht. Hält sich aber in Grenzen und lässt sich Software eliminieren. Tim R. schrieb: > der is471 nutzt ja extra filter, was ich sehr gut > fand Der IS471 ist ja auch eine All-in-One Lösung, die vieles übernimmt, was bei uns der Mikrocontroller übernimmt. Tim R. schrieb: > könntest du mir näher erläutern was du mit basistransistor meinst? Sorry, meinte natürlich Basis-Widerstand. Tim R. schrieb: > grundsätzlich ja! müssten sich nur zum gegebenen zeitpunkt genügend > einfinden und genau da sehe ich das problem ;-) bisher ist die resonanz > zum wirklichen umsetzen/basteln gering.. Mal sehen, sofern wir soweit kommen, finden sich bestimmt ein paar. Habe im Bekanntenkreis schon einige Interessanten. Also auf 1000+ sollten wir leicht und locker kommen, und da lässt sich in Bezug auf Preise und Assemblierung eventuell schon etwas machen. Tim R. schrieb: > welche RGBs willst du benutzen?! Da habe ich mir noch nicht so besonders viele Gedanken gemacht. Für den Testaufbau ist das ja ziemlich egal. Nachher muss man sich das mal genauer ansehen. Die Frage ist, ob wir auf SMD LEDs setzen, oder auf klassische Steckbauteile. Die IR LED und Photodiode sind gibt es meines Wissens nach z.B. nur in einer 3mm Steckvariante, insofern kommen wir um ein wenig Handarbeit nicht herum. Im Prinzip ist mir das aber egal. Ich hätte nur gern eine vernünftige Helligkeit, d.h. das es auch bei Tageslicht "sichtbar" ist (deswegen auch LED Treiber, weil die das einfacher machen). Auf Multiplexing & Co. würde ich daher gerne verzichten (wobei das mit unserer Modullösung nicht notwendig ist). Bei 5x5x3 sollte auch eine einzige LED ausreichen, bei größeren Pixeln könnten ggf. mehrere notwendig werden. Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > Markus M. schrieb: >> Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert >> werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten >> ist o.ä. >> Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst >> großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl. >> der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht) >> und entsprechende IR LEDs (passende Wellenlänge zu dem IR >> Phototransistor). > > Das mit dem breiten Erfassungswinkel ist der falsche Ansatz. Sonst kann > man zwei Zellen nebeneinander nicht unterscheiden, wenn es keine scharfe > Zellenabgrenzung gibt. > Der Strahl muss aus jeder Zelle relativ steil herauskommen, dazu braucht > es ein Stück Abstand von der Oberfläche. > Kann man selber ausrechnen: bei ca. 7x7cm Zellengröße (60x60 Tisch als > eine Größenoption mit 10x10 Zellen) und nur 90 Grad Abstrahlwinkel wird > eine Hand bei einem Abstand von 5cm noch in der Mitte der Nachbarzelle > erfasst - das nimmt dem Konzept jede "Schärfe" in der Erkennung. > Wenn man steileren Winkel will, kommt man um eine gewisse Aufbauhöhe, > wie 10cm, nicht herum (wenn man mit 1 IR-LED arbeiten will. Mir mehreren > kann man auch welche mit schmalem Winkel nehmen oder sie in ein Röhrchen > stecken. Aber mehrere ist m.E. bei 100 Zellen keine Optione). Interessiert keinen? :-) Das dürfte sich bemerkbar machen sobald man eine 3x3 Matrix versucht, dann wird es sich zeigen, dass der mittlere Pixel sehr schwierig alleine zu touchen ist, wenn der Abstrahl-/Erfassungwinkel zu breit ist. Es dürfte dann so sein, dass bei Faust von oben, 5cm über der Fläche alle 9 Pixel ansprechen und das finde ich nicht so optimal.
Karol Babioch schrieb: > Tim R. schrieb: >> das ist richtig. wie reagiert dein sensor bei verschiedenen >> umgebungshelligkeiten? > > Umgebungslicht hat natürlich einen Einfluss, sofern man sich das am > Oszilloskop ansieht. Hält sich aber in Grenzen und lässt sich Software > eliminieren. Misst Du schon gepulst, also wie die TSOP-IR-Empfänger? Trägerfrequenz von 20/30 kHz abstrahlen und nur auf die reagieren? Oder IR-Puls mit 10 kHz, Abtastung mit 20 kHz und je eine Messung mit "IR On" und eine Messung mit IR Off und dann Differenz als Maß?
Tim R. schrieb: >> Wir müssten uns einfach auf die Größe eines Pixels festlegen. Habe jetzt >> zuletzt mit 5x5x3 cm gearbeitet, finde das fast ein wenig klein, bzw. >> bin mir nicht sicher, ob wir die Elektronik + Steckverbindungen nachher >> wirklich auf dieser Fläche unterbringen. Mehrere Sensoren machen bei >> dieser Größe vermutlich auch gar keinen Sinn. Bei 10x10 hingegen sieht >> das schon wieder anders aus. > > stimmt das könnte ein problem werden, bei einem 5x5 feld. evtl. doch ein > 10x10cm feld?! so lässt sich mit einer 10er reihe auch ein tisch von > einem meter länge gut erreichen :-) bei 5x5cm feldern müssten schon > knapp 20 pixel in eine reihe (+overhead vom gerüst) > Ich fände einen 60x60 Couchtisch mit 10x10 Pixeln eine pragmatische Basis. Dann ist jeder Pixel 6x6cm gross und man kann auch andere Tischgrößen fabrizieren, 120x60, 72x72, was auch immer. Die Tiefe der Pixel würde ich 10cm machen um einen möglichst engen Messbereich eines Pixels zu haben. Für eine schöne Ausleuchtung des 6x6 Vierecks braucht es auch mehr als 3cm, würde sagen, dass dafür 5-6cm reichen könnten. Aber der dominante Faktor für die Tiefe ist m.E. die Touch-Detektion.
Angehängte Dateien:
-
Zelle_60x60mm_30mm_tief.png
51 KB -
Zelle_60x60mm_100mm_tief.png
63 KB -
hinterleuchtete_Panele.jpg
170 KB
Conny G. schrieb: > Die Tiefe der Pixel würde ich 10cm machen um einen möglichst engen > Messbereich eines Pixels zu haben. > Für eine schöne Ausleuchtung des 6x6 Vierecks braucht es auch mehr als > 3cm, würde sagen, dass dafür 5-6cm reichen könnten. > Aber der dominante Faktor für die Tiefe ist m.E. die Touch-Detektion. Hier mal als quick & dirty Skizze, einmal 3cm Tiefe, einmal 10cm. Man sieht, dass bei den 3cm Tiefe der Zellen ein Gegenstand von 4cm Durchmesser in einer Höhe von 5/6cm über dem Tisch von 3 Zellen nebeneinander voll erfasst wird. Natürlich wird wg. des etwas längeren Weges von der Seite das Signal "links" und "recht" etwas schwächer sein - aber ich glaube nicht, dass man das unterscheiden kann, es wird stark genug sein. Bei einer Tiefe von 10cm ergibt sich das Problem nicht, da der Messwinkel grundsätzlich viel schmaler ist. Derselbe Gegenstand an derselben Position wird garantiert nicht erkannt. So finde ich das optimal. Nebenbei ist bei dieser 100mm-Tiefe-Konstellation die Fläche oben auch sicher optimal von der RGB-LED ausgeleuchtet. Das wird bei den 30mm nicht so sein. Und das ist nicht "gemeint" oder "geraten", sondern ich weiss es von LED-hinterleuchteten Panelen von 40x40cm, die ich vor ein paar Jahren mal gemacht habe. Der Abstand der LEDs dahinter war ein paar cm, es brauchte einen Abstand von mindestens 6/7 cm um vorne beim gefärbten Plexi (pink) keine einzelnen LEDs mehr erkennen zu können. Zur Illustration ein Foto der Panele: der Abstand zwischen vertikalen, nebeneinander angebrachten LED_Streifen zum Plexiglas ist 7cm, man sieht immer noch ein klein wenig die Kontouren der LED-Streifen dahinter. Klar, dass das mit weniger Abstand weniger gut ausgeleuchtet wäre.
:
Bearbeitet durch User
Conny G. schrieb: > Interessiert keinen? :-) > > Das dürfte sich bemerkbar machen sobald man eine 3x3 Matrix versucht, > dann wird es sich zeigen, dass der mittlere Pixel sehr schwierig alleine > zu touchen ist, wenn der Abstrahl-/Erfassungwinkel zu breit ist. Mir ist natürlich vollkommen klar, was du meinst, bzw. das es rein geometrisch bedingt besser wäre die Konstruktion "tiefer" zu machen. Andererseits schaut halt "tiefer" unschöner aus ;). Ich bin nach wie vor der Meinung, dass man diese Probleme aber mittels Software in den Griff bekommen kann. Die einzelnen Pixel sind ja nicht synchronisiert, d.h. der Puls kommt und die damit einhergehende Messung findet zu verschiedenen Zeit statt. Darüber hinaus könnte man z.B. auch über verschiedene Pulsfrequenzen für benachbarte Zellen nachdenken. Letztendlich könnte man die Geometrie sogar zu seinem Vorteil ausnutzen und die Empfindlichkeit erhöhen, indem man die Signale der benachbarten Zellen mit interpretiert. Das würde natürlich eine Kommunikation der einzelnen Pixel miteinander erfordern und dürfte auch algorithmisch nicht ganz einfach sein, ist aber auch nicht ausgeschlossen. Letztendlich hilft hier nur ein Versuchsaufbau. Den werde ich in nächster Zeit anfertigen. Conny G. schrieb: > Nebenbei ist bei dieser 100mm-Tiefe-Konstellation die Fläche oben auch > sicher optimal von der RGB-LED ausgeleuchtet. > Das wird bei den 30mm nicht so sein. > Und das ist nicht "gemeint" oder "geraten", sondern ich weiss es von > LED-hinterleuchteten Panelen von 40x40cm, die ich vor ein paar Jahren > mal gemacht habe. Dem halte ich z.B. die gesammelten Erfahrungen mit der "Wordclock" entgegen. Hier beträgt der Abstand zwischen LED und "Anzeigefläche" etwa 2 - 2,5 cm und die LEDs lassen sich nicht erkennen. Ist alles eine Frage des verwendeten Diffusors (bzw. in unserem Fall des verwendeten Glases). Auch hier geht versuchen über studieren. Bin derzeit auf der Suche nach günstigen Anbietern von satiniertem Glas, welches ich nachher auch in größerem Umfang erwerben kann. Bringt ja nichts, wenn ich das Ganze mit irgendwelchen Restbeständen zum Laufen bekomme, nachher aber vor dem Problem stehe, dass das entsprechende Glas nicht mehr aufzutreiben ist. Überhaupt ist das bisschen Glas für erste Tests teurer, als erwartet. Hat hier irgendjemand Erfahrungen/Tipps? Wie stark soll das Glas sein? 4mm scheint mir ein guter Kompromiss aus Stärke, Gewicht und Preis. Gibt es irgendwelche Einwände? Habe was Glas angeht sicherlich nicht die meiste Erfahrung, und einen Tisch habe ich auch noch nie gebaut ;). Letztendlich sollten wir ja alle den gleichen physikalischen Aufbau verwenden. Mit freundlichen Grüßen, Karol Babioch
> Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig > Software... Noch etwas zum Protokoll: Zwei UARTs bieten AVRs i.d.R. nicht, d.h. Bit-Banging. Bin mir um ehrlich zu sein nicht sicher, ob das mit Soft-PWM + Protokoll + IR-Modulierung und Auswertung alles unter einen Hut zu bekommen ist. Habe mir den Wiki-Artikel jetzt mal genauer angesehen bzw. mir Gedanken dazu gemacht, bin mir aber in Sachen "Rückrichtung" nicht sicher wie das zu verstehen ist. Was genau veranlasst die Slaves dazu ihre Sensordaten zurückzuschicken? Und macht es wirklich Sinn die RGB Daten auslesbar zu machen? Normalerweise sollten die ja im Puffer des "Masters" stehen und bei 25 Hz Refresh-Rate ist es doch eh recht uninteressant die Daten auszulesen, oder? Ansonsten frage ich mich, ob es nicht "schöner" wäre das ganze doch als echten Bus auszulegen und die einzelnen Pixel adressierbar zu machen. Damit wäre (zumindest theoretisch) auch eine Kommunikation untereinander möglich. Klar, es würde Overhead bedeuten, andererseits müsste man nicht immer alle Daten ausgeben, sondern könnte einzelne Pixel gezielt setzen und auslesen. Ideal wäre natürlich Unterstützung in Hardware, aber bei I2C kommen wir von der Geschwindigkeit und der maximalen Anzahl von Teilnehmern in Bedrängnis. CAN ist wahrscheinlich zu teuer, und SPI skaliert bei der Anzahl an Teilnehmern nicht wirklich. Im Endeffekt denke ich hier nur laut, und es ist auch schon spät, aber wäre es nicht möglich das Ganze in einem "Ring" aufzubauen? Die einzelnen Nodes sind per UART miteinander verbunden, der Master ist jeweils am "Schluss", in etwa so: Master (TX) -> Node1(RX) -> Node1(TX) -> Node2(RX) -> Node2(TX) -> ... -> Master (RX) Eine echte Kommunikation untereinander ist damit nicht effizient möglich, aber alles andere sollte sich vereinfachen: - Eine UART Schnittstelle pro Teilnehmer, d.h. in Hardware - Sowohl "empfangen" als auch "senden" sind aus Sicht des Masters möglich - Logik eines Teilnehmers ist einfach: Alles empfangene "untersuchen" und weitergeben Wie seht ihr das? Habe ich etwas übersehen? Wird das in dieser Form schon irgendwo verwendet, sodass man sich auf Erfahrungen anderer stützen könnte? Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Conny G. schrieb: >> Interessiert keinen? :-) >> >> Das dürfte sich bemerkbar machen sobald man eine 3x3 Matrix versucht, >> dann wird es sich zeigen, dass der mittlere Pixel sehr schwierig alleine >> zu touchen ist, wenn der Abstrahl-/Erfassungwinkel zu breit ist. > > Mir ist natürlich vollkommen klar, was du meinst, bzw. das es rein > geometrisch bedingt besser wäre die Konstruktion "tiefer" zu machen. > Andererseits schaut halt "tiefer" unschöner aus ;). Ich finde, das lässt sich im Design elegant machen. > Ich bin nach wie vor der Meinung, dass man diese Probleme aber mittels > Software in den Griff bekommen kann. Das glaube ich nicht, wie soll das gehen? In einer Zelle weiß ich ja nicht, ob die Reflexion vom Rand oder der Mitte kommt. Ich könnte höchstens bei einem Signal, das ich in zwei Zellen (oder mehreren) empfange über die Intensität ermitteln welcher ich es zuordnen will. Das könnte ich aber nicht in den Zellen tun, sondern müsste es im Mastercontroller wie eine Kontrastverstarkung bei Pixeln rechnen. > Die einzelnen Pixel sind ja nicht > synchronisiert, d.h. der Puls kommt und die damit einhergehende Messung > findet zu verschiedenen Zeit statt. Darüber hinaus könnte man z.B. auch > über verschiedene Pulsfrequenzen für benachbarte Zellen nachdenken. Das eliminiert aber nicht die Unschärfe durch zu großen Erfassungsbereich pro Zelle. > Letztendlich könnte man die Geometrie sogar zu seinem Vorteil ausnutzen > und die Empfindlichkeit erhöhen, indem man die Signale der benachbarten > Zellen mit interpretiert. Das würde natürlich eine Kommunikation der > einzelnen Pixel miteinander erfordern und dürfte auch algorithmisch > nicht ganz einfach sein, ist aber auch nicht ausgeschlossen. S.o., wenn man es im Master als Kontrastverstärkung macht gar nicht so kompliziert. > Letztendlich hilft hier nur ein Versuchsaufbau. Den werde ich in > nächster Zeit anfertigen. Der beantwortet bestimmt diese Fragen am Besten. > Conny G. schrieb: >> Nebenbei ist bei dieser 100mm-Tiefe-Konstellation die Fläche oben auch >> sicher optimal von der RGB-LED ausgeleuchtet. >> Das wird bei den 30mm nicht so sein. >> Und das ist nicht "gemeint" oder "geraten", sondern ich weiss es von >> LED-hinterleuchteten Panelen von 40x40cm, die ich vor ein paar Jahren >> mal gemacht habe. > > Dem halte ich z.B. die gesammelten Erfahrungen mit der "Wordclock" > entgegen. Hier beträgt der Abstand zwischen LED und "Anzeigefläche" etwa > 2 - 2,5 cm und die LEDs lassen sich nicht erkennen. Kann ich nicht beurteilen. > Ist alles eine Frage > des verwendeten Diffusors (bzw. in unserem Fall des verwendeten Glases). Es gibt 2 Faktoren, die die Optik bestimmen: A) wie groß ist der Lichtkegel, der auf den Diffusor auftrifft. B) wieviel verteilt der Diffusor das Licht in seinem Körper Hier ist ein sehr wesentlicher Unterschied zwischen Plexiglas und Satiniertem Glas: Plexiglas ist durch und durch milchig und verteilt deshalb das Licht sehr stark im Körper. Bei Glas ist das nicht unbedingt so, wenn es nur auf der Oberfläche aufgeraut ist, dann sehe ich den Lichtkegel 1:1 so, wie er auftrifft. Nur wenn es wirklich komplett durchgefärbt ist, verteilt es auch innerhalb des Glases. Will sagen: der Abstand kann bei weißem Plexiglas etwas knapper sein als oberflächlich Satiniertem Glas, weil es "aktiv" verteilt. Bei Glas ist demnach wichtig, dass der Lichtkegel der LED das Glas vollflächig beleuchtet. > Auch hier geht versuchen über studieren. Bin derzeit auf der Suche nach > günstigen Anbietern von satiniertem Glas, welches ich nachher auch in > größerem Umfang erwerben kann. Bringt ja nichts, wenn ich das Ganze mit > irgendwelchen Restbeständen zum Laufen bekomme, nachher aber vor dem > Problem stehe, dass das entsprechende Glas nicht mehr aufzutreiben ist. > Überhaupt ist das bisschen Glas für erste Tests teurer, als erwartet. > > Hat hier irgendjemand Erfahrungen/Tipps? Wie stark soll das Glas sein? > 4mm scheint mir ein guter Kompromiss aus Stärke, Gewicht und Preis. Gibt > es irgendwelche Einwände? Habe was Glas angeht sicherlich nicht die > meiste Erfahrung, und einen Tisch habe ich auch noch nie gebaut ;). > Letztendlich sollten wir ja alle den gleichen physikalischen Aufbau > verwenden. Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch wichtig, denn die Platte muss alles aushalten, was da so drauf passiert. Etwas kräftiger abgestellte Maßkrüge, was weiß ich. (Bin in Bayern beheimated :-) ) Vielleicht geht ein bisschen weniger, wenn es ein kleiner Tisch (60x60) ist, aber weniger würde ich nicht machen wollen. 4mm ist eher Fensterglas und hält das m.E. nicht her. > > Mit freundlichen Grüßen, > Karol Babioch Lg, Conny
:
Bearbeitet durch User
Karol Babioch schrieb: >> Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig >> Software... > > Noch etwas zum Protokoll: Zwei UARTs bieten AVRs i.d.R. nicht, d.h. > Bit-Banging. Bin mir um ehrlich zu sein nicht sicher, ob das mit > Soft-PWM + Protokoll + IR-Modulierung und Auswertung alles unter einen > Hut zu bekommen ist. > > Habe mir den Wiki-Artikel jetzt mal genauer angesehen bzw. mir Gedanken > dazu gemacht, bin mir aber in Sachen "Rückrichtung" nicht sicher wie das > zu verstehen ist. Was genau veranlasst die Slaves dazu ihre Sensordaten > zurückzuschicken? Das zurückschicken wird nicht veranlasst, sie werden wie bei SPI beim Senden gleichzeitig zurückgeschickt. > Und macht es wirklich Sinn die RGB Daten auslesbar zu > machen? Die RGB-Daten werden nicht zurückgeschickt, nur die Touchdaten. Aber weil natürlich ebensoviele Bits zurück müssen als hin sind es je 24 Bit pro Node, auch wenn 8 Bit reichen würden. >Normalerweise sollten die ja im Puffer des "Masters" stehen und > bei 25 Hz Refresh-Rate ist es doch eh recht uninteressant die Daten > auszulesen, oder? > > Ansonsten frage ich mich, ob es nicht "schöner" wäre das ganze doch als > echten Bus auszulegen und die einzelnen Pixel adressierbar zu machen. Schöner ja, aber deutlich aufwändiger. Und m.e. braucht man die individuelle Adressierung nicht, also dann lieber nur einen 3-Draht-Bus, dann ist die Verkabelung von 100 Nodes so einfach wie möglich. > Damit wäre (zumindest theoretisch) auch eine Kommunikation untereinander > möglich. Klar, es würde Overhead bedeuten, andererseits müsste man nicht > immer alle Daten ausgeben, sondern könnte einzelne Pixel gezielt setzen > und auslesen. Ideal wäre natürlich Unterstützung in Hardware, aber bei > I2C kommen wir von der Geschwindigkeit und der maximalen Anzahl von > Teilnehmern in Bedrängnis. CAN ist wahrscheinlich zu teuer, und SPI > skaliert bei der Anzahl an Teilnehmern nicht wirklich. > > Im Endeffekt denke ich hier nur laut, und es ist auch schon spät, aber > wäre es nicht möglich das Ganze in einem "Ring" aufzubauen? Die > einzelnen Nodes sind per UART miteinander verbunden, der Master ist > jeweils am "Schluss", in etwa so: > > Master (TX) -> Node1(RX) -> Node1(TX) -> Node2(RX) -> Node2(TX) -> ... > -> Master (RX) Wenn das wirklich klappt, könnte ich mir das auch vorstellen. Es hätte den Vorteil, dass es keine Leitung für einen Rückkanal braucht. Ich hab allerdings mal versucht den Ring zu durchdenken und es sah so aus als hakt das. Jetzt gerade denke ich aber, es könnte gehen, saß da evtl dem falschen Modell auf. Gerade aber keinen frischen Kopf mehr das durchzudeklinieren. > Eine echte Kommunikation untereinander ist damit nicht effizient > möglich, Untereinander halte ich für zu kompliziert und unnötig. Übergeordnete Entscheidungen, die über einen Node hinausgehen sollte der Master treffen. > aber alles andere sollte sich vereinfachen: > > - Eine UART Schnittstelle pro Teilnehmer, d.h. in Hardware > - Sowohl "empfangen" als auch "senden" sind aus Sicht des Masters > möglich > - Logik eines Teilnehmers ist einfach: Alles empfangene "untersuchen" > und weitergeben > > Wie seht ihr das? Habe ich etwas übersehen? Wird das in dieser Form > schon irgendwo verwendet, sodass man sich auf Erfahrungen anderer > stützen könnte? > > Mit freundlichen Grüßen, > Karol Babioch
Conny G. schrieb: > Ich finde, das lässt sich im Design elegant machen. Das liegt dann wohl im Auge des Betrachters. Dünn ist aber deswegen besser, weil man damit auch "dicke" Tische bauen kann ;). Andersherum wird es schwieriger. Conny G. schrieb: >> Ich bin nach wie vor der Meinung, dass man diese Probleme aber mittels >> Software in den Griff bekommen kann. > > Das glaube ich nicht, wie soll das gehen? Ich dachte in erster Linie daran, dass die einzelnen Zellen zu verschiedenen Zeitpunkten ihre Messungen durchführen. Die Nachbarzelle kann ja nur erfasst werden, wenn sie auch aktiv ist. Die Idee ist die eigene IR-LED nur kurz zu aktivieren und dann die Messung vornehmen. Die einzelnen Zellen laufen ja nicht synchron. Hab das Timingtechnisch aber noch nicht durchgerechnet geschweige denn ausprobiert. Conny G. schrieb: > Will sagen: der Abstand kann bei weißem Plexiglas etwas knapper sein als > oberflächlich Satiniertem Glas, weil es "aktiv" verteilt. Ja, mit Glas hab ich in diesem Bereich keine Erfahrungen, bekomme ich ja dann bald zu sehen. Conny G. schrieb: > Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch > wichtig, denn die Platte muss alles aushalten, was da so drauf passiert. Sehe ich auch so, daher fragte ich ja. Wobei dicker natürlich in unserem Fall ungünstiger ist, weil mehr Reflexionen und weniger Durchlass ... Was in unserem Fall ggf. dünneres Glas ermöglichen könnte ist die Unterteilung der Pixel. Wenn man das als tragende Konstruktion auslegt, dann muss die Glasplatte selbst nicht mehr soviel aushalten. Bin aber kein Ingenieur, diese Erkenntnis beruht also nur auf meinem laienhaften Physikverständnis. Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch > wichtig, denn die Platte muss alles aushalten, was da so drauf passiert. > Etwas kräftiger abgestellte Maßkrüge, was weiß ich. (Bin in Bayern > beheimated :-) ) Vielleicht geht ein bisschen weniger, hier wollte ich eigentlich noch schreiben: "vielleicht 8mm" > wenn es ein > kleiner Tisch (60x60) ist, aber weniger würde ich nicht machen wollen. > 4mm ist eher Fensterglas und hält das m.E. nicht her.
Karol Babioch schrieb: > Ich dachte in erster Linie daran, dass die einzelnen Zellen zu > verschiedenen Zeitpunkten ihre Messungen durchführen. Die Nachbarzelle > kann ja nur erfasst werden, wenn sie auch aktiv ist. Die Idee ist die > eigene IR-LED nur kurz zu aktivieren und dann die Messung vornehmen. Die > einzelnen Zellen laufen ja nicht synchron. Hab das Timingtechnisch aber > noch nicht durchgerechnet geschweige denn ausprobiert. Jetzt weiß ich wo wir uns missverstehen. Ich meine nicht die Detektion des IR von Zelle links durch Zelle Mitte. Sondern, dass jedes "Auge", jede Zelle einen weiten Erfassungbereich hat und deshalb ein Gegenstand von mehr als einer Zelle gesehen wird, und zwar mit dem "eigenen" IR. In dem von mir beschriebenen Szenario (Skizze Abstand 3cm) wird der Gegenstand über Zelle Mitte gleich von 9 Zellen gesehen und zwar mit dem eigenen IR. Und keine der Zellen kann unterscheiden, ob es Randbereich oder Mitte ist. Also ist schlicht die Erkennung "unscharf", aus einem "Pixel" werden 9. Das Problem lässt sich also nicht durch andere Abtastfrequenz oder asynchrone Abtastung lösen, denn trotzdem würden Zelle links und rechts auch den Gegenstand sehen. Lg, Conny
:
Bearbeitet durch User
Conny G. schrieb: > Wenn das wirklich klappt, könnte ich mir das auch vorstellen. Es hätte > den Vorteil, dass es keine Leitung für einen Rückkanal braucht. > Ich hab allerdings mal versucht den Ring zu durchdenken und es sah so > aus als hakt das. Jetzt gerade denke ich aber, es könnte gehen, saß da > evtl dem falschen Modell auf. Gerade aber keinen frischen Kopf mehr das > durchzudeklinieren. Mir scheint, dass auch fast zu einfach zu sein, aber ich habe bisher noch keinen Grund gefunden, warum das nicht funktionieren sollte. Würde vorschlagen, wir machen uns da beide nochmal Gedanken die nächsten Tage über ... Interessant wäre allerdings was sich aus einem UART (ohne Quarz?) so herausholen lässt. Ich habe bei AVRs bisher nur mit maximal 9600 Baud gearbeitet, und selbst hier wird oft ein Quarz empfohlen. Der würde aber wiederum zwei Pins kosten :(. Gibt es hierzu bereits Erfahrungswerte? Interessanterweise sagt das Datenblatt nämlich (ATmega168), dass bei 8 MHz Oszillatorfrequenz und einem Wert von 1 im Baud Rate Register und U2X = 1 eine Übertragungsrate von 1 Mbps möglich ist (bei 0% relativem Fehler). Das sollte in unserem Fall ja ausreichend sein ;). Conny G. schrieb: > Untereinander halte ich für zu kompliziert und unnötig. Übergeordnete > Entscheidungen, die über einen Node hinausgehen sollte der Master > treffen. Ok, das Modell können wir natürlich auch verfolgen. Macht wahrscheinlich sogar mehr Sinn, weil dadurch die Nodes einfacher/billiger sind und der Master sowieso genug Power hat. Habe hier wohl einen etwas zu komplexen Ansatz verfolgt. Ein Grund mehr für den oben vorgeschlagenen Ring ;). Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > Jetzt weiß ich wo wir uns missverstehen. Ja, in der Tat. Deine Sorge der Erkennung über anderen Zellen hängt in erster Linie aber wiederum von der Höhe des Gegenstandes über der Glasplatte ab. Ich hätte schon gedacht, dass man die Glasplatte (nahezu) berühren soll, insofern sind die o.g. 60mm fast ein bisschen hoch (je nachdem wie dick die Hände natürlich sind ;)). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch >> wichtig, denn die Platte muss alles aushalten, was da so drauf passiert. > > Sehe ich auch so, daher fragte ich ja. Wobei dicker natürlich in unserem > Fall ungünstiger ist, weil mehr Reflexionen und weniger Durchlass ... Reflexion findet nur an den beiden Grenzflächen des Glases statt, also hat die Dicke darauf keinen Einfluss. Beim Durchlass hängt es davon ab, ob es massiv durchgefärbtes Milchglas ist oder oberflächlich satiniertes Glas. Das spielt dann auch mit der nachfolgende Sache zusammen: > Was in unserem Fall ggf. dünneres Glas ermöglichen könnte ist die > Unterteilung der Pixel. Wenn man das als tragende Konstruktion auslegt, > dann muss die Glasplatte selbst nicht mehr soviel aushalten. Bin aber > kein Ingenieur, diese Erkenntnis beruht also nur auf meinem laienhaften > Physikverständnis. Das stimmt, dass die Unterkonstruktion es möglich machen könnte, das Glas etwas dünner zu wählen. Im Prinzip ist die Dicke des Glases nur dann entscheidend für den Gesamtaufbau, wenn es entscheidend für die Diffusion der RGB-LED ist. Ich würde aber sowieso einen größeren Abstand (10cm) für wichtig ansehen. In diesem Fall ist die Dicke des Glas irrelevant und man könnte zum Vorteil des Durchlasses ein einseitig unten oberflächlich satiniertes Glas verwenden. Das hätte unten auch wenig Spiegelung, maximalen Durchlass, weil sonst reines Glas. Ansonsten ist noch der Haptik-Faktor für manchen ein Kriterium - ich finde den Klang eines 10mm-Glastisches beim Abstellen eines Glases wesentlich angenehmer (dumpfes "Tong") als bei 4mm (helles "Pling") - schon deshalb wäre ich für ein 8-10mm Glas.
Karol Babioch schrieb: > Zwei UARTs bieten AVRs i.d.R. nicht Gibt es durchaus. Bei den kleinen ist der ATtiny841 mit zwei UARTs interessant. Conny G. schrieb: > Ich meine nicht die Detektion des IR von Zelle links durch Zelle Mitte. > Sondern, dass jedes "Auge", jede Zelle einen weiten Erfassungbereich hat > und deshalb ein Gegenstand von mehr als einer Zelle gesehen wird, und > zwar mit dem "eigenen" IR. Legt man ein 3x3-Raster über den Tisch und prüft man in neun Zyklen in jedem Raster je ein Feld, dann hat man immer zwei inaktive Felder zwischen zwei aktiven Feldern. Da kann garnichts schiefgehen.
Karol Babioch schrieb: > Interessant wäre allerdings was sich aus einem UART (ohne Quarz?) so > herausholen lässt. Ich habe bei AVRs bisher nur mit maximal 9600 Baud > gearbeitet, und selbst hier wird oft ein Quarz empfohlen. Der würde aber > wiederum zwei Pins kosten :(. Gibt es hierzu bereits Erfahrungswerte? Übrigens: Die kleinen 8 Pin AVRs (bis einschließlich ATtiny85 bieten gar kein echtes UART Modul, sondern nur USI. Damit lassen sich laut App Note "AVR307: Half Duplex UART Using the USI Module" selbst bei 14.75MHz nur 230.4 kbps erreichen. Der nächstgrößere wäre dann der ATtiny841, der schon zwei UART Module bietet, dafür aber 14 Pins hat .... Hat sich in dieser Beziehung schon jemand Gedanken gemacht? Das o.g. Beaglebone als Master halte ich z.B. für eine gute Lösung, aber bei den Nodes bin ich persönlich noch auf der Suche ... Mit freundlichen Grüßen, Karol Babioch
Konrad S. schrieb: > Legt man ein 3x3-Raster über den Tisch und prüft man in neun Zyklen in > jedem Raster je ein Feld, dann hat man immer zwei inaktive Felder > zwischen zwei aktiven Feldern. Da kann garnichts schiefgehen. Doch, Conny G. hat schon recht. Rein geometrisch bedingt, kann auch etwas "neben" der eigentlichen Pixelfläche detektiert werden. Das wird umso besser, je höher der Unterbau ist. Andererseits kann es auch bei einem höheren Unterbau und ungünstigen Reflexionen an der Seitenwand zu einem solchen Effekt kommen. Ideal wäre natürlich eine Laufzeiterkennung. Das wird aber bei Lichtgeschwindigkeit und unserem Ziel, die Module möglichst billig zu halten, schwierig ;). Hier hilft nur eines: Ausprobieren und sehen wie empfindlich das Ganze letztendlich reagiert. Ich habe bei ersten Tests z.B. festgestellt, dass Haut gar nicht so gut reflektiert, insofern dürfte eine "seitlich" angestrahlte Hand weit weniger problematisch sein, als ein idealisierter Totalreflektor. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Doch, Conny G. hat schon recht. Nein. Beispiel: | A | B | C | D | E | F | G | H | I | J | --+---+---+---+---+---+---+---+---+---+---+-- 0 | a | b | c | a | b | c | a | b | c | a | 0 --+---+---+---+---+---+---+---+---+---+---+-- 1 | d | e | f | d | e | f | d | e | f | d | 1 --+---+---+---+---+---+---+---+---+---+---+-- 2 | g | h | i | g | h | i | g | h | i | g | 2 --+---+---+---+---+---+---+---+---+---+---+-- 3 | a | b | c | a | b | c | a | b | c | a | 3 --+---+---+---+---+---+---+---+---+---+---+-- 4 | d | e | f | d | e | f | d | e | f | d | 4 --+---+---+---+---+---+---+---+---+---+---+-- 5 | g | h | i | g | h | i | g | h | i | g | 5 --+---+---+---+---+---+---+---+---+---+---+-- 6 | a | b | c | a | b | c | a | b | c | a | 6 --+---+---+---+---+---+---+---+---+---+---+-- 7 | d | e | f | d | e | f | d | e | f | d | 7 --+---+---+---+---+---+---+---+---+---+---+-- 8 | g | h | i | g | h | i | g | h | i | g | 8 --+---+---+---+---+---+---+---+---+---+---+-- 9 | a | b | c | a | b | c | a | b | c | a | 9 --+---+---+---+---+---+---+---+---+---+---+-- | A | B | C | D | E | F | G | H | I | J | Im Zyklus a sind die mit a markierten Felder aktiv. Ihre IR-LEDs senden und ihre IR-Sensoren messen. Die Felder b bis i sind inaktiv. Ihre IR-LEDs senden nicht und ihre IR-Sensoren messen nicht. Danach folgt Zyklus b mit aktiven b-Feldern und inaktiven Feldern a und c bis i. Entsprechend folgen die Zyklen c bis i. Was soll da schiefgehen?
Hui, über Nacht ist hier ja einiges geschehen ! :-) zum Glas: Ich habe (wie oben gepostet) ein 4mm dickes Milch-Plexiglas mit 79% LD im 10x10cm Format günstig erworben. Link steht oben. Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen, sondern genau auf dem Tisch oder knapp darüber (maximal 2cm). Denn das ist für mich Touch. Oder nicht?! Somit denke ich wären auch keine "großen" Tiefen nötig für den Unterbau. Und wenn der Tisch stabilen Unterbau bekommt, kann das Glas auch etwas dünner werden :-) Ich werde die Tage mal meinen Aufbau noch einmal rauskramen und das Touch-Verhalten genau untersuchen UND den Abstand für eine LED mir anschauen. Ich denke Conrad hat nicht ganz unrecht, dass die LEDs punktuell zu sehen sind, wenn man zu nah am Glas ist. Diese Daten können dann zumindest als Referenz für ein 4mm Plexiglas dienen :-) Es kann ja gern mal jemand ein 8mm Glas testen @Karol Deine Idee zum 1x UART "Bus" finde ich gar nicht schlecht. Nur die Idee (wenn ich mich Recht entsinne) war die Überlegung zur Steigerung des Durchsatzes -> deswegen 2xUART. Müsste man mal durchrechnen, was bei der Ring Topologie an Daten durchrauschen könnte und ob das einer schönen Framerate (mindestens 30Hz) genügt. @Konrad.S Wie sollen die Zyklen denn bestimmt werden. Wann weiß ein Pixel, dass sein Messzyklus nun ansteht? Ich verstehe nicht ganz, wie das Timing an dieser Stelle zusammen kommen soll. Jedoch die Idee dahinter gefällt mir! grüße
Hi Karol, Karol Babioch schrieb: > Was haltet ihr denn von dem Vorschlag mehrere IR-Dioden (zumindest > Photodioden für den "Empfang") zu verwenden. Damit dürften sich nämlich > Reflexionen aus anderen Zellen erkennen lassen, weil nicht alle > "Empfänger" (gleich stark) angestrahlt werden. Die Frage ist nur wie > viele vertretbar sind, wie viele Pins wir übrig haben und welche > geometrische Anordnung sich hierfür anbietet? Man könnte auch einen TSOPxxxx nehmen. Der hat zwar nur ein digitales Verhalten, aber man könnte trotzdem beim Boot eine Art "Kalibrierung" machen, indem man die Modulationsfrequenz der Sendediode derart in den Grenzbereich des TSOP fährt, dass er bei Milchglas ohne Gegenstand darüber gerade eben nichts mehr empfängt. > Starke LEDs + kein Treiber ist ein wenig ein Widerspruch. AVRs sind > i.d.R. für irgendwas zwischen 20 mA und 40 mA spezifiziert. Es ist kein Problem, bei einem AVR (egal ob Tiny oder Mega), eine RGB-LED direkt über Vorwiderstände anzuschließen, siehe auch: Beitrag "Equinox-Uhr mit 60 ATtinys" > Meistens > schaffen sie nicht mal das, wenn mehrere Pins gleichzeitig beansprucht > werden. In Software kann (je nach Taktfrequenz und je nachdem wie genau > wir den Bus implementieren) eine 8-Bit PWM schon eine Herausforderung > werden. Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von 8Bit auf 16Bit aufbohre. Dadurch bekommt man wesentlich weichere Übergänge hin. Bei 8 Bit sind das eher Farbsprünge - gerade im unteren Bereich. > Apropos flashen: Was ist aus der Bootloader Idee geworden? Die obige Lösung benutzt einen 2-Draht-Bus, der mit SPI vergleichbar ist - implementiert in Software. Dieser ist skalierbar (d.h. nicht fix von der Anzahl der angeschlossenen AVRs) und ich kann sämtliche angeschlossenen µCs in einem Rutsch per Bootloader flashen. Bei einer max. Übertragungsrate von bis zu 100.000 Bits/sec ist das zu flashende Programm ruckzuck auf alle AVRs übertragen. Diesen Bus könnte man zur Befehlsübertragung nutzen. Ein ATmega als Steuereinheit könnte dann Farbprofile oder auch Animationen in den Client-AVRs aktivieren. Diesen ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum Beispiel die Farben zu wechseln o.ä. Leider sind beim ATTiny85 bei Verwendung des Busses keine Pins mehr für IR-Sender/Empfänger mehr frei... denn eigentlich ist dieser µC sehr billig (bekommt man schon für 60-70ct) und hat auch jede Menge Speicher. Okay, man könnte statt des 2-Draht-Busses auch nur einen Draht (und damit SW-Uart) verwenden - bei geringerer Übertragungsrate. Dann wäre ein weiterer Pin frei für den Sender. Wenn man dann noch den RESET-Pin als Datenpin verwendet, könnte man auch noch IR empfangen. Alternative zum ATtiny85 wäre ein ATtiny4313.... den ATtiny2313 mit seinen 2KB Flash finde ich zu winzig. Gruß, Frank
asterix schrieb: > Ich habe (wie oben gepostet) ein 4mm dickes Milch-Plexiglas mit 79% LD > im 10x10cm Format günstig erworben. Link steht oben. Ja, wobei der Trend hier eher zum echten Glas mit 8-10mm geht. Das fänd' ich auch schicker. Wenn man schon einen 3-stelligen EUR-Betrag für die Elektronik ausgibt, soll das Ding ja auch vernünftig aussehen am Ende. > Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich > zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen, Ja, das sehe ich auch so. Also mir würde eine Erkennung von Gegenständen direkt AUF der Platte (oder 5mm drüber von mir aus :-) völlig ausreichen. > dienen :-) Es kann ja gern mal jemand ein 8mm Glas testen Ja, wobei jetzt die Frage wäre mit wieviel Lichtdurchlässigkeit. > @Konrad.S > Wie sollen die Zyklen denn bestimmt werden. Wann weiß ein Pixel, dass > sein Messzyklus nun ansteht? Ich verstehe nicht ganz, wie das Timing an > dieser Stelle zusammen kommen soll. Jedoch die Idee dahinter gefällt > mir! Ja, ich fände eine einfache Daisy Chain mit evtl. synchronem Takt auch optimal. Wenn man gleichzeitig die Sensordaten zurückgibt wäre das perfekt. Habe da momentan noch einen kleinen Knoten im Hirn, aber ich denke es könnte funktionieren. Wichtig erscheint mir vorzusehen, dass alle Pixel/Nodes die erhaltenenen RGB-Daten zu einem gemeinsamen Zeitpunkt gleichzeitig übernehmen. Wenn man einen globalen Takt hat, könnte man dieses durch eine längere low oder high Phase signalisieren (so machen es die WS2811/WS2812). Man müsste mal schauen, was die serielle Schnittstelle vom ATtiny hergibt. Bitbanging sollten wir vermeiden. Grüße Markus
Die 4mm Plexiglas waren mein erster spontaner Testkauf. Ich kenn mich mit normalen Glas nicht aus. Gibts denn milchiges Glas, welches sich für unsere Zwecke eignet (bezahlbar)?! Ich dachte in der Richtung wird immer auf Plexi zurückgegriffen :-) Hat jemand mal einen Link? ps: @ Frank M. schönes Projekt!
:
Bearbeitet durch User
Tim R. schrieb: > Die 4mm Plexiglas waren mein erster spontaner Testkauf. Ich kenn mich > mit normalen Glas nicht aus. Gibts denn milchiges Glas, welches sich für > unsere Zwecke eignet (bezahlbar)?! Ich dachte in der Richtung wird immer > auf Plexi zurückgegriffen :-) Hat jemand mal einen Link? Plexi verkratzt leicht. Ich will ja auch was draufstellen ;-) Ich habe schon gedacht, diesen Tisch hier für so ein Projekt zu verwenden, den habe ich nämlich bereits: http://www.ikea.com/de/de/catalog/products/30157103/ Muss ich mal schauen, wie LEDs darunter aussehen... > ps: > @ Frank M. > schönes Projekt! Danke! :-)
Markus M. schrieb: ausgibt, soll das Ding ja auch vernünftig aussehen am Ende. > >> Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich >> zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen, > > Ja, das sehe ich auch so. Also mir würde eine Erkennung von Gegenständen > direkt AUF der Platte (oder 5mm drüber von mir aus :-) völlig > ausreichen. Dann wäre wichtig, dass man mit der gefundenen Lösung beides kann. Ich möchte Annäherung mit analogem Wert der Messung können (ermöglicht auch eine globale Kalibrierurung beim Master) und auch bei 10cm was messen. Und ich will Messschärfe / Bildschärfe per Geometrie (10cm Tiefe). Rein geometrisch kann ein Pixelmodul ja beides, wenn der Abstrahlwinkel der IR LED breit genug jst. Und der muss für wenig Höhe ja sowieso eher breit sein. Das nutzt nur für mehr Höhe die IR Abstrahlleistung nicht optimal, weil 50% der Leistung an die (schwarze) Seitenwand gehen. Evtl kann man 2 Varianten von LEDs im Abstrahlwinkel finden das zu optimieren. Ansonsten geht es nur um Kalibrierung, ob ich bei 10cm schon was Messe und analog Messe oder ob ich nur 5-10mm will und digital reagiere.
Frank M. schrieb: > Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von > 8Bit auf 16Bit aufbohre. > Leider sind beim ATTiny85 bei Verwendung des Busses keine Pins mehr für > IR-Sender/Empfänger mehr frei... denn eigentlich ist dieser µC sehr > billig (bekommt man schon für 60-70ct) und hat auch jede Menge Speicher. Ich kann den ATtiny841 nur nochmal wärmstens empfehlen: vier 16-Bit-Hardware-PWM und es ist immer noch ein 8-Bit-Timer übrig, zwei U(S)ARTs, 512 Bytes RAM. Netto-Preis bei DigiKey: 0.9748€ bei Hundert Stück, 0.86644€ bei Tausend Stück. http://www.atmel.com/Images/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet.pdf asterix schrieb: > Wie sollen die Zyklen denn bestimmt werden. Wann weiß ein Pixel, dass > sein Messzyklus nun ansteht? Ich verstehe nicht ganz, wie das Timing an > dieser Stelle zusammen kommen soll. Hängt davon ab, wie die Kommunikation aussieht. Wenn genügend Pins da sind, dann könnte man ein diffenzielles Signal zur Synchronisation an alle µCs führen und mit dem Analog-Komparator auswerten. Finde ich aber verschwenderisch, zumal immer noch Leitungen für die Kommunikation notwendig sind. Bei einem Bus kann darüber auch synchronisiert werden. Ich könnte mir RS-485 vorstellen, allerdings mit CAN-Treibern, z.B. MCP2562 oder TJA1051.
Hallo allerseits, auch wenn ich es nicht vorhabe einen solchen Tisch zu bauen, interessiert mich alles was mit LEDs zu tun hat sehr, und so lese ich hier mit. Deshalb möchte ich auch meine Gedanken zu dem Thema kundtun: Bei den ganzen Überlegungen zum IR-Touch habt ihr eine wichtige Problematik bisher übersehen, ihr braucht für die Lichtverteilung satiniertes Glas, oder gar Milchglas, das streut auch das IR-Licht! Wer hat, nimmt mal eine Milschglasscheibe, schaut von der Seite drauf, von der die Beleuchtung kommt, und hält auf der anderen Seite die Hand davor, ist die Hand zu sehen? Bei satiniertem Glas vermutlich ja, wenn sie nahe gunug ist, bei Milchglas wohl eher nicht, vielleicht wenn die Hand direkt aufliegt. Mehr 'sieht' eine Photodiode auch nicht. Sprich, wenn es überhaupt geht, ist das Signal recht schwach. Habt ihr schon mal über kapazitiven Touch nachgedacht, dünnes, grobmaschiges Drahtnetz knapp unter der Glasfläche, so daß es keine störenden Schatten wirft. Auswertung lässt sich direkt mit Mikrocontroller-Pins und ein paar Widerständen machen (mal Googeln), dann stört auch die Nachbarzelle nicht mehr. Die Idee mit dem UART-Ring ist sehr gut, und passt auch gut zu dieser Anwendung. Master schickt die RGB-Daten als Paket auf die Leitung, der Pixelcontroller nimmt sich den ersten RGB Wert weg, schickt den Rest weiter, und hängt hinten seine Sensordaten dran, danach dann eine Pause zur Synchronisation, so braucht es auch keine Adressierung der Pixel, und auch keinen 2. (Software-)UART. Wenn ihr UART verwenden wollt, solltet ihr unbedingt eien Quarz vorsehen, daß der interne Oszillator dafür zu ungenau ist, ist kein Gerücht. Da beim UART nur ein mal, an der vorderen Flanke des Startbits, synchronisiert wird, wirken sich Unterschiede im Takt vom Sender und Empfänger stark aus, auch wenn sich die gewünschte Baudrate, durch passende Teilereinstellung, genau treffen lässt. Was die Bedenken wegen der Software-PWM anbelangt, da halte ich diese Anwendung eher für unproblematisch. Allerdings sind 8 Bit PWM zu wenig, im unteren Bereich ist das sehr stufig, und wenn dann noch eine allgemeine Dimmung für den Abend dazukommt wird es mit den Mischfarben schon schwierig. Und dann will man ja vielleicht noch Farbstiche der RGB-LEDs korrigieren. Da sollten es schon 10-12 Bit PWM-Auflösung sein, sollte hier aber gehen. Ich bin gerade an einem Hobby-Projekt, da steuert ein ATmega328 (Der große Bruder des ATmega168, vom Speicher her) 18 RGB-LEDs, als 3x6 Matrix, also 1/6 Multiplex, 9 Software-PWM-Kanäle. Da erreiche ich 300 Hz 'Bildwiederholfrequenz' bei 10 Bit PWM-Auflösung. Und das bei Betrieb mit dem internen 8 MHz Oszillator. Da ich dort den UART nutze, gleiche ich den Oszillator über das OSCCAL-Register ab, habe am Timer 2 einen Uhrenquarz, und nutzte das als Zeitnormal, der Abgleich läuft immer mit, so daß auch Spannungs- und Temperaturänderungen erfasst werden. Wenn ihr RGB-LEDs über Vorwiderstände und PWM betreibt denkt daran, daß sich die Farbe, bei Mischfarben, oder auch Weiß, abhängig von der Versorgungsspannung deutlich ändert. Bei meinem Aufbau, bei dem die Versorgungsspannung prinzipbedingt nicht konstant ist, habe ich diesen Effekt dadurch stark gemildert, daß ich zu den Rot-Chips eine normale SI-Diose (1N4148) in Reihe schalte, und dann den gleichen Vorwiderstand verwende wie für Grün und Blau. Da ändert sich die Farbe zwischen 4V und 5V Versorgungsspannung nur noch minimal. Ihr habt ja prinzipbedingt lange Leitungen, und somit auch Spannungsabfall. Vielleicht sollte man auf jede Pixelplatine einen Spannungsregler setzten, reicht ja ein kleiner 'L' Typ. Wenn ihr die LEDs, so wie oben schon mal vorgeschlagen, über (MOS-)Transistoren ansteuert könnte man auch über eine höhere Versorgungsspannung für die LEDs nachdenken, und dann mehrere 6-Pin RGBs in Reihe schalten -> Viel mehr Licht, ohne hohe Stromstärken zu brauchen (Bei 100 - 200 Pixeln summieren sich auch mA zu beachtlichen Werten) Wenn ihr den IR-Touch verwenden wollt, sollten die möglichst nicht gleichzeitig messen, wurde ja auch schon angesprochen, bei dem schwachen Signal ist die Verfälschung schnell ein Problem. Da könnte das weiterreichen der Daten, auf dem UART-Ring, gleich als Trigger herhalten: Gerade Daten bekommen -> Messung starten. So würden sie alle schön nacheinender messen. Beim Ring könnte der Zeitversatz zwischen erstem und letztem Pixel vielleicht auffallen, wenn sich die RGB-Werte plötzlich stark ändern, vielleicht sollte ein Pixel doch 'wissen' wo im Ring er sich befindet, und mit einer passenden Verzögerung bei der Ausgabe des RGB-Wertes kompensieren. Wenn sich jede Pixelplatine ihre RGB-Daten wegnimmt, ist die Position im Ring durch auszählen der verbleibenden Daten ermittelbar. Mit freundlichem Gruß - Martin
Konrad S. schrieb: > Ich kann den ATtiny841 nur nochmal wärmstens empfehlen: vier > 16-Bit-Hardware-PWM und es ist immer noch ein 8-Bit-Timer übrig, zwei > U(S)ARTs, 512 Bytes RAM. Ist wirklich ein geiles Teil. Besonders gefällt mir daran, dass man die Timer-Outputs auf fast beliebige Pins mappen kann. Zwei 16-Bit-Timer mit je zwei PWM-Kanälen sind natürlich auch klasse. Die Notwendigkeit für 2 UARTs sehe ich zwar noch nicht, aber schaden kanns nicht.
:
Bearbeitet durch Moderator
japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter leicht zu machen ! :-)
Tim R. schrieb: > japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter > leicht zu machen ! :-) Wäre mir auch lieber, leider gibt es den 841er nicht im DIP/DIL.
Tim R. schrieb: > japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter > leicht zu machen ! :-) Also SOIC Löten sollte ja wohl jeder hinbekommen. Habt ihr wirklich vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen? Die macht man schon klein und kompakt in SMD und lässt sich die Platinen günstig aus Fernost zu 50 oder 100 Stück raus.
cyblord ---- schrieb: > Tim R. schrieb: >> japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter >> leicht zu machen ! :-) > > Also SOIC Löten sollte ja wohl jeder hinbekommen. Habt ihr wirklich > vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen? Die > macht man schon klein und kompakt in SMD und lässt sich die Platinen > günstig aus Fernost zu 50 oder 100 Stück raus. So hätte ich mir das auch vorgestellt.
cyblord ---- schrieb: > Also SOIC Löten sollte ja wohl jeder hinbekommen. Habt ihr wirklich > vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen? Die vielen natürlich nicht, aber das erste ;-)
cyblord ---- schrieb: > Tim R. schrieb: >> japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter >> leicht zu machen ! :-) > > Also SOIC Löten sollte ja wohl jeder hinbekommen. Habt ihr wirklich > vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen? Die > macht man schon klein und kompakt in SMD und lässt sich die Platinen > günstig aus Fernost zu 50 oder 100 Stück raus. Also die ersten Testaufbauten wären mir als DIP lieber. Die Endprodukte könnte man auch kleiner ausfallen lassen. Ich kenne mich in den asiatischen Kreisen nicht aus ;-) Wie viel kostet denn so eine Chinaproduktion ca. 100 Leiterplatten? Un-/Bestückt?
Ich hatte welche bei Farnell bestellt. Günstiger als bei Digikey. Leider als SOIC gerade nicht lieferbar... VPE: 1 Stück 1+ 0,785 € 10+ 0,739 € 25+ 0,694 € 50+ 0,653 €
Tim R. schrieb: > die ersten Testaufbauten wären mir als DIP lieber Was spricht gegen einen Adapter von SOIC-14/16 nach DIP-14/16? So teuer sind die auch wieder nicht.
makrolöter schrieb: > Was spricht gegen einen Adapter von SOIC-14/16 nach DIP-14/16? Eben. Gar nichts. Im Gegenteil. Man muss keine 2 Gehäusetypen vorhalten, sondern kauft immer nur SOIC. > So teuer sind die auch wieder nicht. http://www.ebay.de/itm/4Pcs-0-65-1-27mm-to-2-54-SO-SOP-SOIC-SSOP-TSSOP-MSOP-14-to-DIP-Adapter-convert-/281161108586?pt=Vintage_Electronics_R2&hash=item4176820c6a Eher nicht so teuer ;-) Leiterkarten kosten z.B. bei ITEAD (max. 5x5cm), 100 Stück = 75$. Bestückt müsste man natürlich anfragen. Könnte sich bei 100+ Platinen aber schon lohnen. Selbst mit Stencil + Lötpaste + Reflowofen könnte das von Hand fertigen schon in Arbeit ausarten.
:
Bearbeitet durch User
Hi, Konrad S. schrieb: > Was soll da schiefgehen? Nochmal: Es geht nicht um die Interaktion von verschiedenen Pixeln miteinander, sondern darum, dass ein Pixel auch Gegenstände über anderen Pixeln erfassen kann, wenn es sich in einer bestimmten Höhe über der Glasplatte befindet. Inwiefern das in der Praxis von Bedeutung ist, wird sich zeigen müssen. Immerhin ist eine Hand z.B. kein perfekter Retroreflektor. asterix schrieb: > Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich > zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen, > sondern genau auf dem Tisch oder knapp darüber (maximal 2cm). Denn das > ist für mich Touch. Oder nicht?! Das sehe ich auch so, beim Thema Material der Oberfläche bin ich aber definitiv für Glas. Klar kann man mit Plexiglas herum experimentieren, die Frage ist nur, inwiefern die Ergebnisse dann übertragbar sind. Die Dicke des Glases ist mir im Prinzip egal, stabil soll es halt sein ;). asterix schrieb: > @Karol > Deine Idee zum 1x UART "Bus" finde ich gar nicht schlecht. Nur die Idee > (wenn ich mich Recht entsinne) war die Überlegung zur Steigerung des > Durchsatzes -> deswegen 2xUART. Müsste man mal durchrechnen, was bei der > Ring Topologie an Daten durchrauschen könnte und ob das einer schönen > Framerate (mindestens 30Hz) genügt. Rein Datenratentechnisch haut das schon hin: 20 x 20 x 30 x 24 ~ 300 kBit/s. Ein ATmega168 schafft bei 8 MHz laut Datenblatt bis zu 500 kBit/s. Außerdem habe ich weiter unten noch eine neue Idee ;). Frank M. schrieb: > Man könnte auch einen TSOPxxxx nehmen. Der hat zwar nur ein digitales > Verhalten, aber man könnte trotzdem beim Boot eine Art "Kalibrierung" > machen, indem man die Modulationsfrequenz der Sendediode derart in den > Grenzbereich des TSOP fährt, dass er bei Milchglas ohne Gegenstand > darüber gerade eben nichts mehr empfängt. Mit einem TSOP hatte ich anfangs auch experimentiert, allerdings aufgrund seiner AGC schnell wieder verworfen. Das hat bei mir dermaßen schlecht funktioniert, dass ich SEHR skeptisch bin, ob das zu schaffen ist. Glaube ich erst, wenn ich es sehe ;). Frank M. schrieb: > Es ist kein Problem, bei einem AVR (egal ob Tiny oder Mega), eine > RGB-LED direkt über Vorwiderstände anzuschließen, siehe auch: > > Beitrag "Equinox-Uhr mit 60 ATtinys" Interessantes Projekt. Würdest du die Helligkeit auch bei Tageslicht als akzeptabel beschreiben? Frank M. schrieb: > Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von > 8Bit auf 16Bit aufbohre. Dadurch bekommt man wesentlich weichere > Übergänge hin. Bei 8 Bit sind das eher Farbsprünge - gerade im unteren > Bereich. Details zu der "Aufbohrung" würden mich interessieren. Mit welchen Interrupts arbeitest du? Frank M. schrieb: > Dieser ist skalierbar (d.h. nicht fix von > der Anzahl der angeschlossenen AVRs) und ich kann sämtliche > angeschlossenen µCs in einem Rutsch per Bootloader flashen. Wobei du in der Projektbeschreibung von maximal 239 Teilnehmern sprichst. In unserem Fall ist das zu wenig. Ich persönlich strebe jetzt einfach mal 20x20 = 400 an. Auch bin ich mir ziemlich sicher, dass wir bei einer "Daisy-Chain" mit der erforderten Taktrate in Probleme hinein laufen werden, wenn die Clockleitung 10+ Meter lang ist ;). Frank M. schrieb: > Bei einer > max. Übertragungsrate von bis zu 100.000 Bits/sec ist das zu flashende > Programm ruckzuck auf alle AVRs übertragen. Auch 100 kBit/s ist in unserem Fall leider zu wenig :(. Siehst du denn eine Möglichkeit, dass zu "verbessern"? Frank M. schrieb: > Diesen > ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum > Beispiel die Farben zu wechseln o.ä. Ich würde bei diesem Projekt gerne auf IR-Fernbedienungen verzichten. Halte ich nach wie vor für unzeitgemäß. Smartphones sei dank. Tim R. schrieb: > Ich dachte in der Richtung wird immer > auf Plexi zurückgegriffen :-) Ne, also ich kenne, um ehrlich zu sein kein einzigen Plexi-Glas Tisch. Ist, wie schon gesagt, zu kratzanfällig. Conny G. schrieb: > Dann wäre wichtig, dass man mit der gefundenen Lösung beides kann. Ich > möchte Annäherung mit analogem Wert der Messung können (ermöglicht auch > eine globale Kalibrierurung beim Master) und auch bei 10cm was messen. Wobei das die Ansprüche an den Bus wieder erhöht, weil nicht nur ein/aus übertragen werden muss, sondern ein 8/9/10 Bit ADC Wert. Konrad S. schrieb: > Ich kann den ATtiny841 nur nochmal wärmstens empfehlen: Bietet in der Tat ziemlich viel für ziemlich wenig Geld. Andererseits ist die Frage, ob wir wirklich 14 Pins brauchen ;). Konrad S. schrieb: > Bei einem Bus kann darüber auch synchronisiert werden. Ich könnte mir > RS-485 vorstellen, allerdings mit CAN-Treibern, z.B. MCP2562 oder > TJA1051. Braucht alles Platz und kostet Geld. Macht sich bei der Anzahl an Teilnehmern dann doch bemerkbar. Martin Schlüter schrieb: > Sprich, > wenn es überhaupt geht, ist das Signal recht schwach. Dass es überhaupt geht haben ja andere schon bewiesen. Martin Schlüter schrieb: > Habt ihr schon mal > über kapazitiven Touch nachgedacht, dünnes, grobmaschiges Drahtnetz > knapp unter der Glasfläche, so daß es keine störenden Schatten wirft. Wurde in anderen Threads auch schon durchgesprochen. Netze werfen Schatten. Alternativ wurde auch schon diskutiert etwas Metallisches aufzudampfen. Die Frage ist halt, inwiefern man da als Hobbybastler zu bezahlbaren Preisen herankommt. Außerdem werden die Touchflächen dann sicherlich auch nicht mehr so scharf sein. Martin Schlüter schrieb: > Wenn ihr RGB-LEDs über Vorwiderstände und PWM betreibt denkt daran, daß > sich die Farbe, bei Mischfarben, oder auch Weiß, abhängig von der > Versorgungsspannung deutlich ändert. Auch deswegen bin ich für LED-Treiber. Martin Schlüter schrieb: > Wenn ihr UART verwenden wollt, > solltet ihr unbedingt eien Quarz vorsehen, daß der interne Oszillator > dafür zu ungenau ist, ist kein Gerücht. Kostet halt wieder Platz, Geld und zwei Pins. Frank M. schrieb: > Die Notwendigkeit für 2 > UARTs sehe ich zwar noch nicht, aber schaden kanns nicht. Hier mein Vorschlag: Zwei gegenläufige UART-Ringe. Halbiert die Verzögerung bis der letzte was mitbekommen hat, und verdoppelt den Durchsatz. Die Hardware stände uns bei diesem Mikrocontroller ja zur Verfügung ;). Frank M. schrieb: > Wäre mir auch lieber, leider gibt es den 841er nicht im DIP/DIL. Sehe ich nicht als Problem. Zum Einen lässt sich das nach wie vor per Hand löten (wenn man nicht gerade zwei linke Hände hat, oder eingeschränkt sieht), und zum andern wäre eine Assemblierung auch denkbar. Mit freundlichen Grüßen, Karol Babioch
Einziges Problem was ich noch sehe ist in der Tat die Signalisierung, wann die Daten übernommen bzw. angezeigt werden sollen. Der Bus arbeitet ja zeitlich indeterministisch, weil jeder Teilnehmer empfangen und senden muss und das je nach aktuellem Zustand kürzer oder länger dauern kann. Eine dedizierte Leitung hingegen ist auch nicht so besonders attraktiv und wird bei der Leitungslänge eventuell auch eine Herausforderung? Verzichtet man darauf, dann kann es zu Tearing-Effekten kommen, das ist auch unschön. Vorschläge ;)? Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Um einen Quartz (falls UART benutzt werden soll), kommen wir denke ich gar nicht herum. Denn die Kommunikation ist eines der Herzstücke am Tisch, die muss reibungslos laufen. Dann verzichte ich aus kostengründen lieber auf einen LED-Treiber und nutze die 3 PWM Kanäle vom Tiny :-) Karol Babioch schrieb: > Das sehe ich auch so, beim Thema Material der Oberfläche bin ich aber > definitiv für Glas. Klar kann man mit Plexiglas herum experimentieren, > die Frage ist nur, inwiefern die Ergebnisse dann übertragbar sind. Die > Dicke des Glases ist mir im Prinzip egal, stabil soll es halt sein ;). Wie gesagt, hat denn jemand mal einen Link? Ich habe bisher nur Gläser gefunden die maximal 30% Lichtdurchlässigkeit bieten. Um aber die LEDs auch schön zu sehen bräuchten wir etwas mehr oder ?!
Tim R. schrieb: > Wie gesagt, hat denn jemand mal einen Link? Ich habe bisher nur Gläser > gefunden die maximal 30% Lichtdurchlässigkeit bieten. Um aber die LEDs > auch schön zu sehen bräuchten wir etwas mehr oder ?! Für Muster habe ich mich bisher größtenteils auf eBay umgeschaut. Da gibt es auch 80% Lichtdurchlässigkeit, siehe z.B. [1]. Ist halt alles nicht ganz billig und ich würde gerne die Gewissheit haben, dass ich nachher auch im großen Stile an die selbe Ware komme. Sonst sind jetzt getroffene Designentscheidungen nachher für die Tonne. Mit freundlichen Grüßen, Karol Babioch [1]: http://stores.ebay.de/glasereikern/Satiniertes-Glas-/_i.html?_fsub=2425365017&_sid=1041773537&_trksid=p4634.c0.m322
Karol Babioch schrieb: > Mit einem TSOP hatte ich anfangs auch experimentiert, allerdings > aufgrund seiner AGC schnell wieder verworfen. Das hat bei mir dermaßen > schlecht funktioniert, dass ich SEHR skeptisch bin, ob das zu schaffen > ist. Glaube ich erst, wenn ich es sehe ;). Vielleicht komme ich am nächsten Wochenende mal dazu, es auszuprobieren. > Interessantes Projekt. Würdest du die Helligkeit auch bei Tageslicht als > akzeptabel beschreiben? Du kennst die LEDs (RGB, PLCC6) doch schon vom WordClock-Projekt. Mir würde die Helligkeit reichen. > Frank M. schrieb: >> Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von >> 8Bit auf 16Bit aufbohre. Dadurch bekommt man wesentlich weichere >> Übergänge hin. Bei 8 Bit sind das eher Farbsprünge - gerade im unteren >> Bereich. > > Details zu der "Aufbohrung" würden mich interessieren. Mit welchen > Interrupts arbeitest du? Ich hatte es falsch in Erinnerung, ich bohre die 8-Bit-HW-PWM mittels TIMER1_OVF_vect lediglich auf 12 Bit auf. Damit hat man dann aber auch schon 4096 Stufen statt nur 256. Auch bei kleineren Helligkeiten kann man dann keine Stufen mehr erkennen. Wenn wir uns für den ATtiny841 entscheiden, spielt das aber keine Rolle mehr. Dann haben wir bereits hardwaremäßig 4 16-Bit-PWMs. Das reicht für RGB allemal. > Frank M. schrieb: >> Dieser ist skalierbar (d.h. nicht fix von >> der Anzahl der angeschlossenen AVRs) und ich kann sämtliche >> angeschlossenen µCs in einem Rutsch per Bootloader flashen. > > Wobei du in der Projektbeschreibung von maximal 239 Teilnehmern > sprichst. In unserem Fall ist das zu wenig. Ich persönlich strebe jetzt > einfach mal 20x20 = 400 an. Auch bin ich mir ziemlich sicher, dass wir > bei einer "Daisy-Chain" mit der erforderten Taktrate in Probleme hinein > laufen werden, wenn die Clockleitung 10+ Meter lang ist ;). Die 239 sind dem Protokoll geschuldet, weil die Block-Start-Adresse ein Byte lang ist. Nimmt man 2 Bytes für Start- und Länge (falls man die überhaupt braucht, wenn man alle erreichen will), kommt man auf bis zu 60.000 Busteilnehmer. Dann reichen aber sowieso keine 2 Drähte mehr ;-) > Frank M. schrieb: >> Bei einer >> max. Übertragungsrate von bis zu 100.000 Bits/sec ist das zu flashende >> Programm ruckzuck auf alle AVRs übertragen. > > Auch 100 kBit/s ist in unserem Fall leider zu wenig :(. Siehst du denn > eine Möglichkeit, dass zu "verbessern"? Nein, mehr ist nicht drin per Bitbanging. Dann doch lieber den einen/zwei HW-UART(s) eines ATtiny841. Ich muss da irgendwo was überlesen haben... kannst Du mir mit einem Link oder einer kurzen Beschreibung mal auf die Sprünge helfen? Was für Daten sollen da denn überhaupt zwischen den ATtinys übertragen werden? > Frank M. schrieb: >> Diesen >> ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum >> Beispiel die Farben zu wechseln o.ä. > > Ich würde bei diesem Projekt gerne auf IR-Fernbedienungen verzichten. > Halte ich nach wie vor für unzeitgemäß. Smartphones sei dank. Gerne! Warum nicht? Ich habe mir letztens ein sehr interessantes WLAN-Modul bei Watterott geholt... klingt sehr vielversprechend (und wartet auf den ersten Test mit IRMP ;-) ).
:
Bearbeitet durch Moderator
Frank M. schrieb: > Vielleicht komme ich am nächsten Wochenende mal dazu, es auszuprobieren. Lass mich gerne überraschen ;). Unabhängig davon ist ein TSOP aber trotzdem fast 4x teurer als eine einzelne IR-Photodiode. Frank M. schrieb: > Du kennst die LEDs (RGB, PLCC6) doch schon vom WordClock-Projekt. Mir > würde die Helligkeit reichen. Die LEDs sind auch nicht unbedingt das Problem, sondern wie viel Strom man da durch jagt ;). Keine Ahnung, ob der Mikrocontroller selbst stark genug ist (scheinbar aber schon). Außerdem braucht es selbst bei einer Hardware PWM 3 Pins + 2 Timer. Ein dedizierter LED Treiber (habe z.B. gerade das Datenblatt des CAT4003B offen) kommt mit einer Leitung aus und benötigt keine externen Widerstände. Bessere Treiber können auch eine Dot-Korrektur vornehmen, um Unterschiede in den LEDs auszugleichen. Klar, bei einer 16 Bit PWM kann man das auch in Software machen, aber so erspart man sich eine Menge Arbeit. Frank M. schrieb: > Ich hatte es falsch in Erinnerung, ich bohre die 8-Bit-HW-PWM mittels > TIMER1_OVF_vect lediglich auf 12 Bit auf. Damit hat man dann aber auch > schon 4096 Stufen statt nur 256. Auch bei kleineren Helligkeiten kann > man dann keine Stufen mehr erkennen. Wenn wir uns für den ATtiny841 > entscheiden, spielt das aber keine Rolle mehr. Dann haben wir bereits > hardwaremäßig 4 16-Bit-PWMs. Das reicht für RGB allemal. Ja, 12-Bit sollten auch reichen. Sofern wir uns für den ATtiny841 entscheiden, ist das aber alles kein Problem mehr. Andererseits kann der Ansatz Widerstände zur Strombegrenzung zu verwenden schon zum Problem werden, weil ggf. kleine Spannungsschwankungen große Farbveränderungen bedeuten können, siehe oben. Frank M. schrieb: > Ich muss da irgendwo was überlesen haben... kannst Du mir mit einem Link > oder einer kurzen Beschreibung mal auf die Sprünge helfen? Was für Daten > sollen da denn überhaupt zwischen den ATtinys übertragen werden? Im Prinzip gibt es zwei Richtungen. Aus Sicht des "Masters" sieht es so aus: - Ausgabe: RGB-Daten für jeden einzelnen Pixel, also mindestens 24 Bit, maximale Anzahl der Pixel ist noch nicht wirklich festgelegt, ich persönlich hätte gerne 20x20 - Eingabe: Status des Touch-Sensoren. Wenn wir es einfach halten wollen, dann 1 Bit (an/aus), oben wurde aber auch vorgeschlagen eine analoge Auswertung im Master zu ermöglichen, um dann Kontrastanalysen und ähnliches zu machen. Dann braucht es je nach ADC-Modus und Genauigkeit schon 8/9/10 Bit. Das Ganze natürlich für jeden Pixel und mit einer Refresh-Rate von 25 - 30 Hz. Optional wäre es schön, wenn das Protokoll noch Möglichkeiten zum Flashen einzelner Teilnehmer vorsehen würde. Kalibrierungen wären, je nachdem welchen Weg wir wählen, auch denkbar/sinnvoll, wobei das alles natürlich nicht regelmäßig stattfinden muss. Mit dem ATtiny841 hab ich mich mittlerweile angefreundet, weil der eben zwei UART Module anbietet, wodurch wir zwei gegenläufige UART Ringe aufspannen könnten. Wenn wir jedem Datensatz noch eine "Framenummer" voranstellen, dann kann auch jeder Teilnehmer feststellen, ob er das Paket schon gesehen hat, und es in diesem Fall nicht mehr weiterleiten. Das entlastet den "Bus". Wie siehst du das? Möglich? Sinnvoll? Oder hab ich etwas übersehen? Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > [1]: > http://stores.ebay.de/glasereikern/Satiniertes-Glas-/_i.html?_fsub=2425365017&_sid=1041773537&_trksid=p4634.c0.m322 puh, zumindest bei diesem Anbieter sind 0,6m² (maximal) bei 8mm Dicke schon knapp 70 Teuros. Und 20x30cm oder 10x60cm ist etwas knapp für die meisten oder ? ;-)
Karol Babioch schrieb: > Die LEDs sind auch nicht unbedingt das Problem, sondern wie viel Strom > man da durch jagt ;). Keine Ahnung, ob der Mikrocontroller selbst stark > genug ist (scheinbar aber schon). Ja, der Strom (max. 20mA pro Pin) ist kein Problem. > Andererseits kann der > Ansatz Widerstände zur Strombegrenzung zu verwenden schon zum Problem > werden, weil ggf. kleine Spannungsschwankungen große Farbveränderungen > bedeuten können, siehe oben. Wo sollen diese "Spannungsschwankungen" herkommen? Bei 60 ATtinys hintereinander konnte ich diese nicht beobachten, schon gar nicht als Farbveränderungen. > Im Prinzip gibt es zwei Richtungen. Aus Sicht des "Masters" sieht es so > aus: > > - Ausgabe: RGB-Daten für jeden einzelnen Pixel, also mindestens 24 Bit > - Eingabe: Status des Touch-Sensoren. Wenn wir es einfach halten wollen, > dann 1 Bit (an/aus), oben wurde aber auch vorgeschlagen eine analoge > Auswertung im Master zu ermöglichen, um dann Kontrastanalysen und > ähnliches zu machen. Dann braucht es je nach ADC-Modus und Genauigkeit > schon 8/9/10 Bit. Warum muss der Master den Status jeden einzelnen Touch-Sensors wissen? Das kann doch jeder ATTiny-Slave selbst entscheiden, was er dann macht.... zum Beispiel seine LED hochfaden. Ich sehe eher die Aufgabe eines Masters darin, den anderen ab und zu mal mitzuteilen, was die Slaves machen sollen, wenn der Touch-Sensor mal ansprechen sollte - also eine Art "Verhaltensprogramm". Was ich mir auch vorstellen kann: Eine "Vernetzung" der Slaves untereinander mit jeweils dessen Nachbarn, also 4 Drähte zu jeweils dem Slave links, rechts, oben, unten. So können sie dann dem Nachbarn durch Ziehen der Strippe (standrdmäßig HIGH über Pullup) auf GND mitteilen, wenn ihr Touch-Sensor angesprochen hat. Dadurch können die Nachbarn ihre LEDs auch mal kurz ansprechen.... Wenn sie dies auch wieder den Nachbarn mitteilen, könnte man so ganze "Wellen" durch den Tisch laufen lassen, wenn jemand ein Glas abstellt. Meiner Meinung reicht Ein-/Aus auch als Touch-Sensor aus.
:
Bearbeitet durch Moderator
Tim R. schrieb: > puh, zumindest bei diesem Anbieter sind 0,6m² (maximal) bei 8mm Dicke > schon knapp 70 Teuros. Und 20x30cm oder 10x60cm ist etwas knapp für die > meisten oder ? ;-) Ja, das geht ins Geld. Werde am Wochenende vielleicht doch nochmal lokale Glasereien abklappern, und nach Mustern/Abfällen fragen. Wobei sich auch hier das Problem der Wiederbeschaffung stellt ... Karol Babioch schrieb: > Mit dem ATtiny841 hab ich mich mittlerweile angefreundet, Übrigens ist das doch nicht so einfach wie gedacht. Der ATtiny841 wird derzeit nicht wirklich gut unterstützt. Weder avr-gcc noch avrdude unterstützen ihn von Haus aus. Auch beim offiziellen Atmel Studio braucht es wohl irgendwelche Zusatz-Pakete. In Deutschland ist es auch gar nicht so einfach da heranzukommen. Das macht das Ganze wieder unattraktiv(er) :(. Frank M. schrieb: > Wo sollen diese "Spannungsschwankungen" herkommen? Bei 60 ATtinys > hintereinander konnte ich diese nicht beobachten, schon gar nicht als > Farbveränderungen. Die Leitungen werden je nach Ausführung halt schon ziemlich lang. Und das Netzteil hat auch ordentlich zu tun mit dem Regulieren, wenn da 400 RGB LEDs (= 1200 LEDs) munter an- und ausgeschaltet werden ... Frank M. schrieb: > Warum muss der Master den Status jeden einzelnen Touch-Sensors wissen? Die Idee war halt, dass man im Master sich dann die Kontraste genauer ansehen kann, um so auch Gegenstände über der Glasplatte zu erkennen. > Das kann doch jeder ATTiny-Slave selbst entscheiden, was er dann > macht.... zum Beispiel seine LED hochfaden. Ne, wirklich entscheiden sollen die Slaves nichts selber. Der Master soll denen schon vorschreiben was zu tun ist, wie willst du sonst "Spiele" und andere Formen der Interaktionen implementieren? Es kann z.B. durchaus sinnvoll sein gewisse Felder zu deaktivieren, egal, ob sich darauf nun eine Hand befindet, oder nicht. Schau dir vielleicht einfach mal die o.g. Videos an. Frank M. schrieb: > Eine "Vernetzung" der Slaves > untereinander mit jeweils dessen Nachbarn, also 4 Drähte zu jeweils dem > Slave links, rechts, oben, unten. Etwas ähnliches hatte ich oben vorgeschlagen. Bei meinem aktuellen Vorschlag zwei UART Ringe zu verwenden wäre das auch halbwegs effizient möglich ohne extra Strippen. Andererseits macht eine Auswertung im Master schon Sinn. Der hat mehr Power und weiß, ob eine solche Auswertung im aktuellen Kontext überhaupt Sinn macht. Frank M. schrieb: > Meiner Meinung reicht Ein-/Aus auch als Touch-Sensor aus. Allein schon zur Kalibrierungszwecken könnte es Sinn machen die gemessenen Analogwerte bekannt zu machen. Ich habe z.B. bei den IR-Photodioden gemerkt, dass die sich zum Teil schon ein wenig anders verhalten. Rein von der benötigten Datenübertragungsrate macht das den Braten auch nicht mehr fett, und sollte bei zwei Ringen mit jeweils 500 kBit/s kein Problem sein. Was der Master dann damit anfängt bleibt ihm überlassen ;). Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Übrigens ist das doch nicht so einfach wie gedacht. Der ATtiny841 wird > derzeit nicht wirklich gut unterstützt. Weder avr-gcc noch avrdude > unterstützen ihn von Haus aus. Auch beim offiziellen Atmel Studio > braucht es wohl irgendwelche Pakete. In Deutschland ist es auch gar > nicht so einfach da heranzukommen. Das macht das Ganze wieder > unattraktiv(er) :(. Das stimmt so nicht. avr-gcc unterstüzt den 841 in der aktuellen Version. Atmel Studio benötigt ein Update-Paket, aber danach gibts keine Probleme. Für avrdude muss man den 841 noch in der conf datei eintragen. Haben hier schon einige gemacht. Ich selbst auch. Die conf gibts hier auch irgendwo in einem thread. Das ist kein Problem. Digikey liefert den 841 ab 1 Stück nach D auch für privat. Habe jetzt schon einige Projekte damit realisiert. Obwohl ich nichtmal das Studio verwende, sondern Eclipse mit AVR-Plugin, und ich das Plugin auch noch an den 841 anpassen musste. Geht absolut problemlos und in den nächsten Versionen wird das wohl alles schon drin sein. So ist das halt bei neuen Bausteinen. gruß cyblord
Karol Babioch schrieb: > Nochmal: Es geht nicht um die Interaktion von verschiedenen Pixeln > miteinander, sondern darum, dass ein Pixel auch Gegenstände über anderen > Pixeln erfassen kann, wenn es sich in einer bestimmten Höhe über der > Glasplatte befindet. So, jetzt hat es auch bei mir Klick gemacht. Und jetzt verstehe ich auch den ursprünglichen Post von Conny G. zu diesem Thema. Sorry, falls ich da Verwirrung gestiftet habe.
cyblord ---- schrieb: > avr-gcc unterstüzt den 841 in der aktuellen > Version. Wo finde ich Referenzen darauf? Auf der Homepage von avr-libc [1] ist davon noch keine Rede. Mein Eclipse mit aktueller Toolchain avr-gcc 4.9.0 und avr-libc 1.8.0 listet diesen auch noch nicht auf. cyblord ---- schrieb: > Für avrdude muss man den 841 noch in der conf datei eintragen. Das habe ich gesehen, ist aber die Definition von "geht nicht von Haus aus" ;). cyblord ---- schrieb: > Digikey liefert den 841 ab 1 Stück nach D auch für privat. Ok, bei Farnell ist die Lieferzeit nämlich unbekannt, der Preis dafür bei 70 Cent ;). cyblord ---- schrieb: > Obwohl ich nichtmal > das Studio verwende, sondern Eclipse mit AVR-Plugin, und ich das Plugin > auch noch an den 841 anpassen musste. Details? Ist das irgendwo dokumentiert? cyblord ---- schrieb: > So ist das halt > bei neuen Bausteinen. Ja, wobei man sich auch mehr Mühe geben könnte. Nach einem halben Jahr sollte das alles doch schon mal integriert sein ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://www.nongnu.org/avr-libc/user-manual/using_tools.html
Konrad S. schrieb: > So, jetzt hat es auch bei mir Klick gemacht. Und jetzt verstehe ich auch > den ursprünglichen Post von Conny G. zu diesem Thema. Sorry, falls ich > da Verwirrung gestiftet habe. Kein Problem, hatte das ja ursprünglich auch so gedeutet wie du ;). Beides sind Reflexionen und beides muss man im Design berücksichtigen. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > cyblord ---- schrieb: >> avr-gcc unterstüzt den 841 in der aktuellen >> Version. > > Wo finde ich Referenzen darauf? Auf der Homepage von avr-libc [1] ist > davon noch keine Rede. Mein Eclipse mit aktueller Toolchain avr-gcc > 4.9.0 und avr-libc 1.8.0 listet diesen auch noch nicht auf. Das ist ja auch veraltet. Die Toolchain wird ja inzwischen von Atmel gepflegt und dort findet man auch den aktuellen avr-gcc. Version kann ich dir grad nicht sagen. Müsste schon eine 5 davor sein. > Details? Ist das irgendwo dokumentiert? Nein, du kannst im Forum mal nach Tiny841 suchen, da findest du 1-2 Threads zu dem Thema inkl. 2 Dateien für das Plugin, welche den Tiny841 hinzufügen. Das wird aber sowieso nur für z.B. den "Fuse-Dialog" benötigt. Die Device-Liste holt sich das Plugin ja über avrdude. Und btw. von Haus aus, geht es eben mit dem Atmel Studio. Da brauchsts dann auch keinen avrdude. Für 3rd Party Tools kann man das nicht einfach mal so erwarten. Da muss man momentan halt noch selber was machen. gruß cyblord
:
Bearbeitet durch User
cyblord ---- schrieb: > Das ist ja auch veraltet. Die Toolchain wird ja inzwischen von Atmel > gepflegt und dort findet man auch den aktuellen avr-gcc. Link? cyblord ---- schrieb: > Müsste schon eine 5 davor sein. Da erzählst du mir aber was neues. avr-gcc wird parallel mit dem eigentlichen gcc entwickelt und da ist 4.9 Stand der Dinge (~ 1 Monat alt). cyblord ---- schrieb: > Die Device-Liste holt sich das Plugin ja über avrdude. Ja, und avrdude braucht derzeit noch zusätzliche Einträge in der Konfiguration. Das Problem mit dem Eclipse Plugin ist, dass es wohl ziemlich tot drum geworden ist, keine Ahnung, ob sich darum noch jemand kümmert und es bei Gelegenheit updated? Mit freundlichen Grüßen, Karol Babioch
Das aktuelle Atmel Studio 6.2 unterstützt den ATtiny841. Ich verwende allerdings die von Atmel bereitgestellte Toolchain für Linux. Quelle: http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx?tab=overview Bei avrdude.conf (Version 6.1) habe ich den Eintrag für den ATtiny841 hinzugefügt. Quelle: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1120422
Karol Babioch schrieb: > Frank M. schrieb: >> Diesen >> ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum >> Beispiel die Farben zu wechseln o.ä. > > Ich würde bei diesem Projekt gerne auf IR-Fernbedienungen verzichten. > Halte ich nach wie vor für unzeitgemäß. Smartphones sei dank. Die Steuerung des Tisches sollte am Besten so aussehen: :-) http://youtu.be/DTb0k_P1wlY > Conny G. schrieb: >> Dann wäre wichtig, dass man mit der gefundenen Lösung beides kann. Ich >> möchte Annäherung mit analogem Wert der Messung können (ermöglicht auch >> eine globale Kalibrierurung beim Master) und auch bei 10cm was messen. > > Wobei das die Ansprüche an den Bus wieder erhöht, weil nicht nur ein/aus > übertragen werden muss, sondern ein 8/9/10 Bit ADC Wert. Ja, aber - s.u. - bei 2 Bus-Ringen überträgt man eh in einer Richtung 3x PWM-Wert, das ist genügend Zeit um 8+ Bits Touch-Value zurückzuschicken. > Frank M. schrieb: >> Die Notwendigkeit für 2 >> UARTs sehe ich zwar noch nicht, aber schaden kanns nicht. > > Hier mein Vorschlag: Zwei gegenläufige UART-Ringe. Halbiert die > Verzögerung bis der letzte was mitbekommen hat, und verdoppelt den > Durchsatz. Die Hardware stände uns bei diesem Mikrocontroller ja zur > Verfügung ;). Jetzt sind wir nicht mehr weit von meinem Vorschlag in: http://www.mikrocontroller.net/articles/RGB_Touch_Matrix entfernt. Der Unterschied ist jetzt noch, dass ich dort ein implizites CLK wie beim WS2812(b) angenommen habe. Beim UART-Ansatz würde man das UART-Prinzip zugrundelegen. Aber kann man die 2 USI nicht genau wie das WS2812-Protokoll einsetzen? Dann ist die Zeit pro Pixel und pro Frame festgelegt und alles synchron und fein :-)
Frank M. schrieb: >> Im Prinzip gibt es zwei Richtungen. Aus Sicht des "Masters" sieht es so >> aus: >> >> - Ausgabe: RGB-Daten für jeden einzelnen Pixel, also mindestens 24 Bit >> - Eingabe: Status des Touch-Sensoren. Wenn wir es einfach halten wollen, >> dann 1 Bit (an/aus), oben wurde aber auch vorgeschlagen eine analoge >> Auswertung im Master zu ermöglichen, um dann Kontrastanalysen und >> ähnliches zu machen. Dann braucht es je nach ADC-Modus und Genauigkeit >> schon 8/9/10 Bit. > > Warum muss der Master den Status jeden einzelnen Touch-Sensors wissen? > Das kann doch jeder ATTiny-Slave selbst entscheiden, was er dann > macht.... zum Beispiel seine LED hochfaden. Der Master entscheidet, was die Pixel machen und versorgt sie mit Daten. Jeden einzeln, wie bei der Bildwiederholrate eines Screens: die Pixel wissen gar nix, nur ihren letzten RGB-Wert, den sie halten und den Touchstatus, den sie ständig mitteilen. Der Master fährt ein Spiel, oder eine Animation, was auch immer. http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html http://youtu.be/DTb0k_P1wlY > Ich sehe eher die Aufgabe eines Masters darin, den anderen ab und zu mal > mitzuteilen, was die Slaves machen sollen, wenn der Touch-Sensor mal > ansprechen sollte - also eine Art "Verhaltensprogramm". > > Was ich mir auch vorstellen kann: Eine "Vernetzung" der Slaves > untereinander mit jeweils dessen Nachbarn, also 4 Drähte zu jeweils dem > Slave links, rechts, oben, unten. So können sie dann dem Nachbarn durch > Ziehen der Strippe (standrdmäßig HIGH über Pullup) auf GND mitteilen, > wenn ihr Touch-Sensor angesprochen hat. Dadurch können die Nachbarn ihre > LEDs auch mal kurz ansprechen.... Wenn sie dies auch wieder den Nachbarn > mitteilen, könnte man so ganze "Wellen" durch den Tisch laufen lassen, > wenn jemand ein Glas abstellt. Zu limitiert, damit lassen sich Features wie oben verlinkt nicht lösen. > Meiner Meinung reicht Ein-/Aus auch als Touch-Sensor aus. M.e. muss der Touch kalibriert werden, das macht am Besten der Master im Gesamten. Wenn sich jeder Pixel einzeln kalibriert, kann es zu komischen Effekten kommen. Und wenn schon der Master den Touchwert bekommt (was bei 2 Busringen kein Aufwand ist), dann kann man auch mit Annäherung spielen, wenn man möchte. Wer das nicht möchte, arbeitet mit On/Off. Halte es aber für falsch die Architektur von Anfang für On/Off zu limitieren.
Conny G. schrieb: > Die Steuerung des Tisches sollte am Besten so aussehen: :-) > http://youtu.be/DTb0k_P1wlY Okay, das Video hat mich überzeugt, sowas kann man nur mit einem dicken Master machen. Hinweise zur im Video verwendeten Hardware gibt's hier: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html#Platine Während die 100 Lochrasterplatinen noch ziemlich "thin" aussehen (IR-Diode, Poti, (teurer!) IR-Sensor, RGB-LED und ein wenig Hühnerfutter), ist die Hauptplatine schon ziemlich fett - meines Erachtens. Halten wir also mal fest: Anzeige: Der Master überträgt RGB-Werte an M x N µCs (z.B. 10x10). Dies sollten Zielwerte sein, die in X Hunderstel-Sekunden per Fading erreicht werden sollen. Die Zeitspanne X wird natürlich auch vom Master vorgegeben. Ist sie 0, wird der RGB-Wert instantan angezeigt. So braucht der Master keine Zwischenwerte zu schicken und die Clients können selbst vom aktuellen RGB-Wert zum Ziel-RGB-Wert faden. So habe ich das bei meinem Equinox-Projekt mit den 60 ATTinys gemacht. Das spart eine Menge an Kommunikation. Ausserdem sind mit ein paar Bytes auf ganz einfache Weise auch Broadcasts möglich. Einen UART-Ring halte ich bei bei der Anzeige für unzweckmäßig, da jeder Slave das empfangene Byte erst weitersenden kann, wenn es vollständig empfangen wurde. Dadurch ergeben sich im Ring je nach Anzahl der Slaves erhebliche Verzögerungszeiten. Ich würde da eher einen UART-Bus nehmen: Alle Slaves haben eine ausgezeichnete Adresse und horchen mit RX an derselben Strippe. So habe ich es mit dem Equinox-Projekt gemacht. Nur ist es da kein UART, sondern ein synchroner serieller Bus. Aber der Unterschied ist da nur marginal. Bei dieser Vorgehensweise kann man ganze Blöcke von Daten verschicken, ohne die Slaves einzeln adressieren zu müssen. Man sendet Startadresse, Länge X des Blocks und anschließend X RGB-Werte. Dann picken sich X Slaves die für sie relevanten Daten aus dem Block heraus. Sensoren: Der Master muss jederzeit über die Sensoren informiert sein. Dies könnte man vielleicht tatsächlich über einen UART-Ring machen, da dies nicht so zeitkritisch ist. Der Master schiebt ein Kommando-Byte in den Ring und anschließend fallen M x N Touch-Sensor-Bits aus dem Ring am Ende wieder raus. Ich würde als Master einen Raspberry-PI oder ein Carambola nehmen. Dann haben wir genügend Power und die nötigen Schnittstellen.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Die Zeitspanne X wird natürlich auch vom Master vorgegeben. Ist > sie 0, wird der RGB-Wert instantan angezeigt. So braucht der Master > keine Zwischenwerte zu schicken und die Clients können selbst vom > aktuellen RGB-Wert zum Ziel-RGB-Wert faden. Halte ich nach wie vor zu "komplex". Ich würde die Clients wirklich "dumm" halten. Zwischenwerte & Co. sollen alle vom Master kommen. Der hat genug Power und kann sich Gedanken machen was Sinn macht. Ich würde das mit einem Touch-Monitor vergleichen. Hier kümmert sich der Monitor auch nur im die Eingabe (Touch) bzw. Ausgabe (Pixel). Die Auswertung der Eingabe(n) bzw. die Ausgabe(n) kommen vom Host. Frank M. schrieb: > Ich würde da eher einen UART-Bus nehmen: > Alle Slaves haben eine ausgezeichnete Adresse und horchen mit RX an > derselben Strippe. Nur haben wir dann das Problem, dass die Leitung extrem (!) lang bzw. kapazitiv ist. Keine Ahnung, ob das so ohne Weiteres in den Griff zu bekommen ist. Eine individuelle Adressierung würde mir auch besser gefallen, aber man kann nicht alles haben ;). Frank M. schrieb: > Ich würde als Master einen Raspberry-PI oder ein Carambola nehmen. Dann > haben wir genügend Power und die nötigen Schnittstellen. Wir hatten uns weiter oben schon auf ein Beaglebone geeinigt. Ist auch ein Linuxboard, bietet aber den Vorteil, dass es gleich MCUs mitliefert, die die Kommunikation übernehmen können. Der RasPi ist z.B. ziemlich lahm, wenn es um das gezielte Ansteuern von einzelnen Pins geht. Im Prinzip ist es aber auch egal, geht nur darum, dass man "schöne" Treiber schreibt, sodass man Anwendungen in High-Level Frameworks programmieren kann ohne sich um die darunterliegenden Details kümmern zu müssen. WiFi bzw. Ethernet inkl. Web-Interface wären auch nett. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Halte ich nach wie vor zu "komplex". Ich würde die Clients wirklich > "dumm" halten. Ist überhaupt nicht komplex. Wenn Du als Zeitspanne 0 schickst, hast Du genau Deinen "dummen" Fall. Mit Zeitspanne != 0 spart es aber jede Menge an Kommunikation. Hast Du Dir mal das im Equinox-Thread verlinkte Video heruntergeladen und angeschaut? > Zwischenwerte & Co. sollen alle vom Master kommen. Der > hat genug Power und kann sich Gedanken machen was Sinn macht. Hier geht es nicht um Power, sondern um die Menge an Daten. Du hast zum Beispiel ein Bild (MxN = 100 RGB-Werte) und Du willst, dass eine halbe Sekunde ein anderes Bild gezeigt wird. Wenn Du nun das Ziel-Bild schickst (weitere 100 RGB-Werte), dann faden die Pixel wie von Geisterhand gleitend auf das Zielbild. Das gibt für jedes Pixel einen gleitenden Übergang, wobei die Geschwindigkeit intern bis zu 25 Updates pro Sekunde sein können. Stell Dir nun vor, Du müsstest die alle übertragen... > Ich würde > das mit einem Touch-Monitor vergleichen. Hier kümmert sich der Monitor > auch nur im die Eingabe (Touch) bzw. Ausgabe (Pixel). Die Auswertung der > Eingabe(n) bzw. die Ausgabe(n) kommen vom Host. Das ist doch okay so. Nur die Zwischenwerte können für die Übergänge intern berechnet werden, sonst langweilen sich die Slaves doch nur. > Frank M. schrieb: >> Ich würde da eher einen UART-Bus nehmen: >> Alle Slaves haben eine ausgezeichnete Adresse und horchen mit RX an >> derselben Strippe. > > Nur haben wir dann das Problem, dass die Leitung extrem (!) lang bzw. > kapazitiv ist. Nö. Du legst TX des Masters auf 10 Transistoren/MOSFets und die schickst Du durch die Zeilen. Dann ist jede der Strippen nur maximal so lang wie eine Zeile und nicht M x N Zeilen. > Keine Ahnung, ob das so ohne Weiteres in den Griff zu > bekommen ist. Eine individuelle Adressierung würde mir auch besser > gefallen, aber man kann nicht alles haben ;). Doch kann man. Schau Dir mal das Video an. Die C-Funktionen sind im Master sehr klein, die Effekte sind aber riesig. Und wie gesagt: Mit Zeitspanne = 0 hast Du Deinen "Dummy-Mode" :-) Die Funktionen zum Faden innerhalb der ATTinys kann ich gern beisteuern, das ist kein Problem. > Frank M. schrieb: >> Ich würde als Master einen Raspberry-PI oder ein Carambola nehmen. Dann >> haben wir genügend Power und die nötigen Schnittstellen. > > Wir hatten uns weiter oben schon auf ein Beaglebone geeinigt. Ist auch > ein Linuxboard, bietet aber den Vorteil, dass es gleich MCUs mitliefert, > die die Kommunikation übernehmen können. Der RasPi ist z.B. ziemlich > lahm, wenn es um das gezielte Ansteuern von einzelnen Pins geht. Meinetwegen auch Beaglebone, da hab ich noch 4 Stück von in der Bastelkiste, kein Problem ;-) > Im Prinzip ist es aber auch egal, geht nur darum, dass man "schöne" > Treiber schreibt, sodass man Anwendungen in High-Level Frameworks > programmieren kann ohne sich um die darunterliegenden Details kümmern zu > müssen. WiFi bzw. Ethernet inkl. Web-Interface wären auch nett. Eben. Ist alles machbar. Gruß, Frank
Frank M. schrieb: > Hast Du Dir mal das im Equinox-Thread verlinkte Video > heruntergeladen und angeschaut? Ja, und in deinem Fall macht das wahrscheinlich auch am meisten Sinn. Hier sehe ich die Notwendigkeit dafür aber nicht, weil es das Entwickeln von Anwendungen schwieriger bzw. unintuitiver macht. Würde das ganze lieber als eine Art Framebuffer behandeln, anstatt mir über verschiedene Timing-Aspekte Gedanken machen zu müssen. Frank M. schrieb: > Stell Dir nun vor, Du müsstest die alle > übertragen... Der Bus muss das sowieso hergeben, sofern wir irgendetwas realisieren wollen was mit der Intelligenz der einzelnen Clients nicht mehr möglich ist. Frank M. schrieb: > Nö. Du legst TX des Masters auf 10 Transistoren/MOSFets und die schickst > Du durch die Zeilen. Dann ist jede der Strippen nur maximal so lang wie > eine Zeile und nicht M x N Zeilen. Wobei selbst das noch 1-2 Meter lang werden kann, je nachdem was die Leute denn effektiv vor haben. Bei den erforderlichen Taktraten stelle ich mir das schwierig vor. Bin aber kein ausgebildeter Elektrotechniker, ist nur mein Bauchgefühl. Lasse mich da gerne vom Gegenteil überzeugen ;). Frank M. schrieb: > Doch kann man. Schau Dir mal das Video an. Die C-Funktionen sind im > Master sehr klein, die Effekte sind aber riesig. Und wie gesagt: Mit > Zeitspanne = 0 hast Du Deinen "Dummy-Mode" :-) Das Video habe ich gesehen. Finde ich auch klasse. Aber das ist trotzdem nicht so besonders gut auf diesen Fall übertragbar. Wir wollen mit dem ganzen Tisch kontextabhängig interagieren. Intelligenz in den Clients halte ich eher für störend bzw. komplett unnötig. Da würde ich lieber den Bus so dimensionieren, dass die konstante Ausgabe von Daten mit 30 Hz kein Problem darstellt. Im Worst-Case muss das ja auch bei "schlauen" Clients funktionieren, ansonsten wäre man auf das beschränkt was die Clients können. Und die sind nun einmal bei weitem nicht so rechenstark wie der dazugehörige Host. Wie sehen das denn die anderen? Vielleicht bin ich auch der Einzige, der das so sieht, aber irgendwie gefällt mir die Idee von "schlauen" Clients nicht so besonders. Wie gesagt, ich würde das Ding eher mit einem Touch-Monitor vergleichen. Und bei einem solchen Monitor kommen sämtliche Auswertungen, Effekte und Anwendungen auch vom Host. Mit freundlichen Grüßen, Karol Babioch
Ich greife mal Franks Fading auf und spinne was dran. Unter Verzicht auf einen Quarz ergibt die 16-Bit-PWM eine Rate von 122 Updates pro Sekunde, ein recht brauchbarer Wert. Mit einem Byte für die Fading-Dauer kann das Fading mehr als zwei Sekunden dauern. Bei angenommenen fünf Bytes pro Feld, 30 Frames pro Sekunde und geschätzten 20 kByte pro Sekunde Nettoduchsatz könnten pro Master-TX durchaus 128 Felder mit Daten versorgt werden. Der "Trick" mit mit der gemeinsamen Ansteuerung der Felder-RX geht ähnlich auch für den Rückkanal: Solange für der Felder-TX das TXENn-Bit nicht gesetzt ist, gilt die normale Funktion des Port-Pins, kann also hochohmiger Input sein. Felder-TX-Pins lassen sich zusammenschalten, wenn die Software sicherstellt, dass nur immer ein Feld sendet. Hier ist viel Zeit für Sensordaten der Felder, weil keine Daten vom Master transportiert werden müssen.
Hi, die Nodes/Pixel sollten so minimal wie möglich sein, sowohl was die Bauteile als auch Intelligenz betrifft. Bauteile: - Controller (ATtiny841 ?) - RGB-LED - IR-LED - IR-Photodiode - ein paar Widerstände und Kondensatoren - ggf. Quarz notwendig - ggf. LED-Treiber Intelligenz des Pixelcontrollers: - Bootloader zum nachträglichen Neuprogrammieren (wichtig!) - Implementierung einer Daisy Chain, Taktgenerierung/Weitergabe noch offen - Annahme der RGB-Daten - Software oder Hardware PWM - Ansteuerung der IR-LED (pulsen) - Rückgabe des Analogwertes der gemessenen Spannung (ggf. gemittelt und/oder Differenz aus IR-LED an/aus) an der IR-Photodiode Sämtliche Steuerung der Pixel soll vom Master erfolgen. Ciao... Markus
Karol Babioch schrieb: > Frank M. schrieb: >> Hast Du Dir mal das im Equinox-Thread verlinkte Video >> heruntergeladen und angeschaut? > > Ja, und in deinem Fall macht das wahrscheinlich auch am meisten Sinn. > Hier sehe ich die Notwendigkeit dafür aber nicht, weil es das Entwickeln > von Anwendungen schwieriger bzw. unintuitiver macht. Würde das ganze > lieber als eine Art Framebuffer behandeln, anstatt mir über verschiedene > Timing-Aspekte Gedanken machen zu müssen. > > Frank M. schrieb: >> Stell Dir nun vor, Du müsstest die alle >> übertragen... > > Der Bus muss das sowieso hergeben, sofern wir irgendetwas realisieren > wollen was mit der Intelligenz der einzelnen Clients nicht mehr möglich > ist. > > Frank M. schrieb: >> Nö. Du legst TX des Masters auf 10 Transistoren/MOSFets und die schickst >> Du durch die Zeilen. Dann ist jede der Strippen nur maximal so lang wie >> eine Zeile und nicht M x N Zeilen. > > Wobei selbst das noch 1-2 Meter lang werden kann, je nachdem was die > Leute denn effektiv vor haben. Bei den erforderlichen Taktraten stelle > ich mir das schwierig vor. Bin aber kein ausgebildeter Elektrotechniker, > ist nur mein Bauchgefühl. Lasse mich da gerne vom Gegenteil überzeugen > ;). > > Frank M. schrieb: >> Doch kann man. Schau Dir mal das Video an. Die C-Funktionen sind im >> Master sehr klein, die Effekte sind aber riesig. Und wie gesagt: Mit >> Zeitspanne = 0 hast Du Deinen "Dummy-Mode" :-) > > Das Video habe ich gesehen. Finde ich auch klasse. Aber das ist trotzdem > nicht so besonders gut auf diesen Fall übertragbar. Wir wollen mit dem > ganzen Tisch kontextabhängig interagieren. Intelligenz in den Clients > halte ich eher für störend bzw. komplett unnötig. Da würde ich lieber > den Bus so dimensionieren, dass die konstante Ausgabe von Daten mit 30 > Hz kein Problem darstellt. Im Worst-Case muss das ja auch bei "schlauen" > Clients funktionieren, ansonsten wäre man auf das beschränkt was die > Clients können. Und die sind nun einmal bei weitem nicht so rechenstark > wie der dazugehörige Host. > > Wie sehen das denn die anderen? Vielleicht bin ich auch der Einzige, der > das so sieht, aber irgendwie gefällt mir die Idee von "schlauen" Clients > nicht so besonders. Wie gesagt, ich würde das Ding eher mit einem > Touch-Monitor vergleichen. Und bei einem solchen Monitor kommen > sämtliche Auswertungen, Effekte und Anwendungen auch vom Host. > > Mit freundlichen Grüßen, > Karol Babioch Ich stimme Karol voll zu: Hardware und Protokoll strukturell so simpel wie möglich, Slave = Dummer Pixel, der Host/Master hält den Framebuffer und überträgt das komplette Bild mit 25fps. Oder anders ausgedrückt: es ist sowohl bei Software als auch bei Hardware der beste Weg mit dem wichtigen Base Case zu beginnen und die Lösung so simpel wie möglich, so komplex wie nötig aufzusetzen. Speed-Optimierungen o.ä. macht man später, wenn man in konkrete Probleme läuft. Also spare ich mir adressierbare Notes und ein komplexeres Bildmanagement solange ich kann und mache einen dummen Daisy Chain Bus und einen Framebuffer. Es gibt keinen harten Grund eine Deltaanzeige zu machen sofern der Bus 25fps bei 200 oder 400 Pixeln hergibt. Wenn dann doch mal jemand eine Tanzfläche mit 10.000 Zellen bauen will, dann muss er sich was überlegen :-)
Also 25 ist aber wirklich Untergrenze oder nicht? 35-40Hz sind doch schon schöner :-) ich würde die "dumme" Salve Taktik auch bevorzugen. Ich glaub ein intelligenter Slave/Pixel zieht auch viel Aufmerksamkeit und Sorgen mit sich. Lieber einen strapazierbaren/schnellen Bus und alle Entwicklungen können auf dem Master laufen. Die Pixelplatinen nehmen nur noch RGB-Daten an, zeigen an und schicken Touch-Sensor-Wert zurück. Hast du die alten oder neuen Beagle Bones? Also einen Black? Momentan sind die Dinger ja recht Rar, wie ich das mitbekommen habe :-( P.S.: Kommt es mir nur so vor oder wird es hier langsam ein wenig kuddel muddel von den Themen... wie wäre es mit einem kurzen Schlachtplan für die weiteren Besprechungen ? ;-) freut mich aufjedenfall, dass sich nun viele hier beteiligen !
Tim R. schrieb: > Also 25 ist aber wirklich Untergrenze oder nicht? 35-40Hz sind doch > schon schöner :-) Kannst du denn wirklich mehr als 25 Bilder pro Sekunde wahrnehmen? Ich behaupte mal: Nein. Aber klar, der Bus sollte nicht an der absoluten Leistungsgrenze betrieben werden. Tim R. schrieb: > P.S.: Kommt es mir nur so vor oder wird es hier langsam ein wenig > kuddel muddel von den Themen... wie wäre es mit einem kurzen > Schlachtplan für die weiteren Besprechungen ? ;-) Mach einen Vorschlag ;). Bis zum ersten Prototyp ist das wohl alles - mehr oder weniger - eine Sammlung von Ideen und Anforderungen. Mit freundlichen Grüßen, Karol Babioch
Ich finde, Karol macht einen kleinen Denkfehler beim UART-Ring. Selbst bei einer Übertragungsrate von 115200 Baud sind es bei 8 Bit / no parity insgesamt 10 Bits (inkl. Start-/Stop-Bit) pro Byte. Damit beträgt die Übertragungsrate 11520 Byte/sec. Nehmen wir nun 100 Slaves an und 3 Bytes für jeden RGB-Wert. Dann sind das 3000 zu übertragene Bytes. Die Übertragung vom Master aus dauert dafür minimal 3000/11520 = 0,26 Sekunden. Damit kommt man auf ca. 4 Frames pro Sekunde. Hinzu kommen noch Verzögerungen bis zum letzten Slave, weil die Bytes immer erst weitergereicht werden können, wenn sie auch komplett empfangen wurden. Der letzte Slave erhält seine Daten also um einiges später, nämlich mindestens um 100/11520 Sekunden - auch wenn die Daten des letzten Slaves als erstes geschickt werden würden. Mit meinem intelligenten Protokoll (zusammen mit dem UART-Bus statt Ring), wo nur die Unterschiede gesendet werden brauchen, reduziert sich die zu übertragene Datenmenge erheblich. Genauso arbeiten Video-Komprimierungen, welche die Datenmenge auf durchschnittlich ein Zehntel herunterdrücken. Es ist auch kein Problem, für den Master eine Funktion zu schreiben, die einen Soll-Framebuffer übergeben bekommt und dann anhand des Ist-Framebuffer-Inhalts nur die Unterschiede (in Blöcken zusammengefasst) überträgt. Was ist daran kompliziert? Der Anwenderprogrammierer füllt einen Framebuffer, ruft die Send-Funktion auf, diese ermittelt die Diffs zum Ist-Zustand und überträgt dann nur die Unterschiede. Da braucht der Programmierer einer Anwendung für den Tisch sich überhaupt keinen Kopf drum zu machen. Das ist easy. Zusammen mit der Fade-Intelligenz in den Slaves kann das alles noch geglättet werden. Da ruckelt dann nix mehr. Die Slave-Funktionen dafür habe ich fix und fertig. Da muss nichts mehr neu erfunden werden noch bereitet es irgendeinem Kopfzerbrechen. Wenn der Anwender-Programmierer das Slave-Fading nicht nutzen will, benutzt er einfach als Fading-Zeitdauer die Null und schon erscheint das neue Bild instantan. Wenn ich Lust und Zeit hätte, würde ich jetzt einfach mal 10 Equinox-LED-Streifen zusammenlöten (10x15 = 150 ATtinys) und zeigen, dass man damit sogar einfache Filme in Farbe zeigen kann, wobei Farbwechsel von bestimmten Pixeln sacht ablaufen und die ATtinys damit sogar Zwischenbilder "berechnen" und damit Bewegungen viel flüssiger ablaufen. Mit einer Komplettübertragung eines Frames über UART bekommt man das nicht hin, siehe oben. Aber wie immer bei solchen Projekten: Dutzende reden, bis irgendwann einer anfängt und macht....
Karol Babioch schrieb: > Tim R. schrieb: >> Also 25 ist aber wirklich Untergrenze oder nicht? 35-40Hz sind doch >> schon schöner :-) > > Kannst du denn wirklich mehr als 25 Bilder pro Sekunde wahrnehmen? Ich > behaupte mal: Nein. Aber klar, der Bus sollte nicht an der absoluten > Leistungsgrenze betrieben werden. Es ist hier auch anders als zB beim Multiplexing: dort ist ein Pixel ein n-Tel der Zeit an und (n-1)/n aus - hier brauche ich wie bei PWM eine hohe Refresh Rate um kein Flimmern zu sehen. Aber unsere Pixel halten einfach den letzten Stand solange bis neue Daten kommen. Also geht es nicht um flimmern, sondern um die flüssige Wahrnehmung von Bewegung. Und da wir sowieso nur eine Auflösung von 10x10 oder 20x20 haben kann man von flüssiger Bewegung sowieso nicht sprechen, da ein Block immer um 6cm weiterspringt oder wenn es überblendet wird über zwei Blöcke schmiert. Ob das mit 25 oder 35fps passiert, das ist sowas von Wurst. Da ist es wesentlich wichtiger ein PWM Auflösung der Pixel von 10 Bit zu haben, damit Farbverläufe sanft sind. > Tim R. schrieb: >> P.S.: Kommt es mir nur so vor oder wird es hier langsam ein wenig >> kuddel muddel von den Themen... wie wäre es mit einem kurzen >> Schlachtplan für die weiteren Besprechungen ? ;-) Es müsste mal jemand durchgehen und die wesentlichsten Fakten, Entscheidungen, Kontroversen rausschreiben. > Mach einen Vorschlag ;). Bis zum ersten Prototyp ist das wohl alles - > mehr oder weniger - eine Sammlung von Ideen und Anforderungen. Ja, es bräuchte jetzt eine konkrete Implementation von mindestens 3x3....
Frank M. schrieb: > Nehmen wir nun 100 Slaves an und 3 Bytes für jeden RGB-Wert. Dann sind > das 3000 zu übertragene Bytes. Sorry, ich habe falsch gerechnet. Es sind natürlich nur 300 Bytes und damit ist die Übertragungsdauer 0,026 Sekunden + 100/11520 = 0,026 + 0,008 = 0,034 Sekunden. Also sind doch ca. 30 Frames pro Sekunde drin. Ich nehme daher alles zurück - auch wenn es bei 200 Slaves dann "nur" noch 15 Frames pro Sekunde sind.
Frank M. schrieb: > Ich finde, Karol macht einen kleinen Denkfehler beim UART-Ring. Selbst > bei einer Übertragungsrate von 115200 Baud sind es bei 8 Bit / no parity > insgesamt 10 Bits (inkl. Start-/Stop-Bit) pro Byte. > > Damit beträgt die Übertragungsrate 11520 Byte/sec. > > Nehmen wir nun 100 Slaves an und 3 Bytes für jeden RGB-Wert. Dann sind > das 3000 zu übertragene Bytes. Die Übertragung vom Master aus dauert > dafür minimal 3000/11520 = 0,26 Sekunden. Damit kommt man auf ca. 4 > Frames pro Sekunde. Hinzu kommen noch Verzögerungen bis zum letzten > Slave, weil die Bytes immer erst weitergereicht werden können, wenn sie > auch komplett empfangen wurden. Der letzte Slave erhält seine Daten also > um einiges später, nämlich mindestens um 100/11520 Sekunden - auch wenn > die Daten des letzten Slaves als erstes geschickt werden würden. > > Mit meinem intelligenten Protokoll (zusammen mit dem UART-Bus statt > Ring), wo nur die Unterschiede gesendet werden brauchen, reduziert sich > die zu übertragene Datenmenge erheblich. Genauso arbeiten > Video-Komprimierungen, welche die Datenmenge auf durchschnittlich ein > Zehntel herunterdrücken. > > Es ist auch kein Problem, für den Master eine Funktion zu schreiben, die > einen Soll-Framebuffer übergeben bekommt und dann anhand des > Ist-Framebuffer-Inhalts nur die Unterschiede (in Blöcken > zusammengefasst) überträgt. Was ist daran kompliziert? Der > Anwenderprogrammierer füllt einen Framebuffer, ruft die Send-Funktion > auf, diese ermittelt die Diffs zum Ist-Zustand und überträgt dann nur > die Unterschiede. Da braucht der Programmierer einer Anwendung für den > Tisch sich überhaupt keinen Kopf drum zu machen. Das ist easy. Zusammen > mit der Fade-Intelligenz in den Slaves kann das alles noch geglättet > werden. Da ruckelt dann nix mehr. Die Slave-Funktionen dafür habe ich > fix und fertig. Da muss nichts mehr neu erfunden werden noch bereitet es > irgendeinem Kopfzerbrechen. Wenn der Anwender-Programmierer das > Slave-Fading nicht nutzen will, benutzt er einfach als Fading-Zeitdauer > die Null und schon erscheint das neue Bild instantan. > > Wenn ich Lust und Zeit hätte, würde ich jetzt einfach mal 10 > Equinox-LED-Streifen zusammenlöten (10x15 = 150 ATtinys) und zeigen, > dass man damit sogar einfache Filme in Farbe zeigen kann, wobei > Farbwechsel von bestimmten Pixeln sacht ablaufen und die ATtinys damit > sogar Zwischenbilder "berechnen" und damit Bewegungen viel flüssiger > ablaufen. > > Mit einer Komplettübertragung eines Frames über UART bekommt man das > nicht hin, siehe oben. > > Aber wie immer bei solchen Projekten: Dutzende reden, bis irgendwann > einer anfängt und macht.... Hi Frank, Uart ist auch nur die Schnittstelle, genau genommen USI. Und damit kann man auch ein Protokoll wie SPI fahren. Oder so eins wie bei den WS2812 Streifen, da bin ich auch großer Fan von, das ist genial mit implizitem CLK und Latch durch Pause. Kennst die WS2812? Ein supereinfaches und echt mächtiges Prinzip, weil jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu kämpfen, jede LED schickt ein neues Signal. Schau Dir mal meine Protokollvorschlag hier an: http://www.mikrocontroller.net/articles/RGB_Touch_Matrix Das ist der Ws2812 Dausy Chain nachempfunden und es gibt auch mit 100 Slaves überhaupt kein Problem, Zitat: "Idealerweise hängen alle Slaves einfach an einem Strang als einfachstmögliche Konstellation - einfache Verkabelung, keine mehrfach-Einspeisung in der Software. Für einen 10x10 RGB-Touch-Tisch sind das 100 Slaves. Jeder hat 24 Bits zu bekommen, ergibt 2400 Bits. Mal Framerate von 25 ergibt 25 x 2.400 Bits = 60.000 Bits pro Sekunde. Vorsichtshalber betreiben wir den Bus mit 100 kBit, dann sind wir nicht in einem technisch kritischen Bereich und brauchen nur einen Strang. (Die WS2811 machen 800 kBit, also das 8-fache). 250 kbit sollten noch ebenso einfach machbar sein, dann kann auch ein 10x20 Tisch in einem Strang betrieben werden"
Frank M. schrieb: > Ich finde, Karol macht einen kleinen Denkfehler beim UART-Ring. Selbst > bei einer Übertragungsrate von 115200 Baud sind es bei 8 Bit / no parity > insgesamt 10 Bits (inkl. Start-/Stop-Bit) pro Byte. Wieso rechnest du mit 115200 Baud ;)? Laut Datenblatt des ATtiny841 sind auch deutlich mehr drin. Bei 20 MHz Oszillatorfrequenz sogar bis zu 2.5 Mbit/s (bei 0% relativem Fehler!). Insofern sollte das rein von der Datentransferrate weniger das Problem werden. Latenz und gleichzeitige Anzeige der übergebenen Daten ist ein anderes Problem, das hängt aber davon ab wie genau man das aufbaut. Conny G. schrieb: > Ein supereinfaches und echt mächtiges Prinzip, weil > jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu > kämpfen, jede LED schickt ein neues Signal. Wobei das bei uns ja in Software (und wahrscheinlich Interrupt basiert?) geschehen würde. Dadurch kann es zu Schwankungen im Timing kommen, die umso größer werden, umso länger die Kette ist. Oder sehe ich das falsch? Conny G. schrieb: > dann kann auch ein 10x20 Tisch in einem > Strang betrieben werden" Ich ziele irgendwie trotzdem immer noch 20x20 an. Das entspricht bei 5x5 cm großen Pixeln gerade mal 1x1 m. Und deine Rechnung sieht auch noch nicht die Touchwerte vor, oder? Sind ja auch nochmal (mindestens) ein Byte pro Pixel? Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Conny G. schrieb: >> Ein supereinfaches und echt mächtiges Prinzip, weil >> jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu >> kämpfen, jede LED schickt ein neues Signal. > > Wobei das bei uns ja in Software (und wahrscheinlich Interrupt basiert?) > geschehen würde. Dadurch kann es zu Schwankungen im Timing kommen, die > umso größer werden, umso länger die Kette ist. Oder sehe ich das falsch? Kommt darauf an wieviel die Verzögerung ist und ob das wirklich stört. Sagen wir mal ein Slave braucht bei 20 MHz 200 Takte zur Verarbeitung und zum Weitersenden. Halte das aber für zuviel. Denn wenn ich weiß ich hab meine Daten und muss nur auf den Ausgang schalten, was ich bekomme dann sind keine 2 Dutzend Takte. Bei 200 Takten hätten wir 10us Verzögerung bei jedem Slave, bei 100 Slaves 1ms. Das Latch bei den Ws2812 ist eine Pause von mind. 50us. Jetzt wäre die Frage, ob diese Verzögerung ein Problem für die Latchpause ist. Eigentlich dürfte das nicht so sein, es kommt die Pause zwar 1ms später hinten an, aber der Abstand der Bits muss sowieso gleich bleiben, sonst klappt das Protokoll im Ansatz nicht. Bei 20 Takten Verzögerung pro Slave sind wir bei 100us Verzögerung beim 100sten Slave. Beides sieht man nicht. Wenn also die Abstände der Bits bei jedem Slave gleich bleiben, dann ist auf jeden Fall alles gut. > Conny G. schrieb: >> dann kann auch ein 10x20 Tisch in einem >> Strang betrieben werden" > > Ich ziele irgendwie trotzdem immer noch 20x20 an. Das entspricht bei 5x5 > cm großen Pixeln gerade mal 1x1 m. Und deine Rechnung sieht auch noch > nicht die Touchwerte vor, oder? Sind ja auch nochmal (mindestens) ein > Byte pro Pixel? Wir haben doch eine Tx Chain und eine Rx Chain, die gleichzeitig laufen, also braucht der Rückkanal gar keine extra Zeit.
:
Bearbeitet durch User
Karol Babioch schrieb: > Laut Datenblatt des ATtiny841 sind > auch deutlich mehr drin. Bei 20 MHz Oszillatorfrequenz Der ATtiny841 ist nur bis 16MHz spezifiziert. Und das erfordert einen externen Takt bzw. Quarz.
Conny G. schrieb: > Wir haben doch eine Tx Chain und eine Rx Chain, die gleichzeitig laufen, > also braucht der Rückkanal gar keine extra Zeit. Richtig, ich vergaß. Macht die Aufteilung in zwei Ringe deiner Meinung nach dann noch Sinn? Die ATtiny841 jedenfalls haben jeweils zwei Hardware Module ;). Konrad S. schrieb: > Der ATtiny841 ist nur bis 16MHz spezifiziert. Und das erfordert einen > externen Takt bzw. Quarz. Dann sollte man Atmel mal darauf hinweisen, dass die entsprechenden UBRR Tabellen darüber hinaus gehen ;). Habe gar nicht überprüft, ob die vorgeschlagenen Werte überhaupt möglich bzw. spezifiziert sind. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Dann sollte man Atmel mal darauf hinweisen Hm, ja, das Datenblatt da noch ein paar Inkonsistenzen. Das Maximum ist wohl 16MHz mit Quarz.
Karol Babioch schrieb: > Conny G. schrieb: >> Wir haben doch eine Tx Chain und eine Rx Chain, die gleichzeitig laufen, >> also braucht der Rückkanal gar keine extra Zeit. > > Richtig, ich vergaß. Macht die Aufteilung in zwei Ringe deiner Meinung > nach dann noch Sinn? Die ATtiny841 jedenfalls haben jeweils zwei > Hardware Module ;). Wie meinst Du das? > Konrad S. schrieb: >> Der ATtiny841 ist nur bis 16MHz spezifiziert. Und das erfordert einen >> externen Takt bzw. Quarz. > > Dann sollte man Atmel mal darauf hinweisen, dass die entsprechenden UBRR > Tabellen darüber hinaus gehen ;). Habe gar nicht überprüft, ob die > vorgeschlagenen Werte überhaupt möglich bzw. spezifiziert sind. > > Mit freundlichen Grüßen, > Karol Babioch
Conny G. schrieb: > Wie meinst Du das? Willst du die Daten nur von einer Seite einspeisen, oder würde es Sinn machen dies von zwei Seiten zu tun, die Bandbreite zu verdoppeln und die Latenz zu halbieren. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> Wie meinst Du das? > > Willst du die Daten nur von einer Seite einspeisen, oder würde es Sinn > machen dies von zwei Seiten zu tun, die Bandbreite zu verdoppeln und die > Latenz zu halbieren. Gleiches wie vorher: so einfach wie geht. Also nur einmal einspeisen, solange sich nicht der Bedarf für mehr auftut.
Hi Conny, Conny G. schrieb: > Hi Frank, > > Uart ist auch nur die Schnittstelle, genau genommen USI. > Und damit kann man auch ein Protokoll wie SPI fahren. Weiß ich :-) > Oder so eins wie bei den WS2812 Streifen, da bin ich auch großer Fan > von, das ist genial mit implizitem CLK und Latch durch Pause. > Kennst die WS2812? Ein supereinfaches und echt mächtiges Prinzip, weil > jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu > kämpfen, jede LED schickt ein neues Signal. Ja, das Prinzip gefällt mir auch. Soviel ich aber weiß, können die Dinger nur 8Bit-PWM pro Farbe. Das ist der einzige Grund, warum ich sie bisher nicht mag. Als ich damals die Equinox-Streifen entwarf, waren die WS-Dinger auch noch ein Vielfaches teurer als heute. Zum zweiten ist das Timing bei den WS2812-LEDs recht eng gehalten. > Schau Dir mal meine Protokollvorschlag hier an: > http://www.mikrocontroller.net/articles/RGB_Touch_Matrix Mach ich. > Das ist der Ws2812 Dausy Chain nachempfunden und es gibt auch mit 100 > Slaves überhaupt kein Problem, Zitat: Ja, ich hatte mich gestern abend um einen Faktor 10 verrechnet. Man schafft bei 115200 Baud und 100 Slaves tatsächlich 30 fps. Sorry. Das (minimale) Latenzproblem, dass der letzte Slave seine Daten zeitversetzt erhält, könnte man übrigens lösen, indem man die Framebuffer-Daten "rückwärts" schickt, d.h. die Daten für den letzten Slave werden als erstes losgeschickt. Damit minimiert man die Zeitdifferenzen. Aber wahrscheinlich sind diese sowieso nicht sichtbar - jedenfalls nicht bei 100 Slaves. Ausserdem müssten die Slaves dann wissen, wie lange die Daisy-Chain ist. Macht alles nur komplizierter. Gruß, Frank
:
Bearbeitet durch Moderator
Ich habe mich mal schlau gemacht, was es für verschiedene Touchsensor-Techniken gibt. Dabei ist mir die FTIR-Technik über den Weg gelaufen: http://www.cs.nyu.edu/~jhan/ftirsense/ Das Prinzip beruht darauf, dass eine Berührung an einer bestimmten Stelle auf einer Acryl-Glasscheibe eine Totalreflektion verhindert und so ein Austritt des seitlich eingespeisten Lichts ermöglicht. Man muss also nur seitlich an der Scheibe ein paar IR-LEDs anbringen, welche erstmal wegen der Totalreflektion ein IR-Licht erzeugen, welches normalerweise "innerhalb" der Scheibe verbleibt. Drückt man nun mit dem Finger auf eine Zelle, wird an dieser Stelle das IR-Licht auf den IR-Sensor fallen. Wahrscheinlich geht das sogar besser als mit den Sensoren, die in dem oben genannten Tisch-Video eingesetzt wurden. Dort muss eine Zelle fast komplett mit der Hand abgedeckt werden, damit der Sensor anspricht. Bei FTIR könnte eventuell schon ein Finger ausreichen. Es ist also gar nicht notwendig, dass jeder Slave einen eigenen IR-Sender hat, er braucht nur einen Empfänger. Ist das seitlich eingespeiste IR-Licht moduliert, könnte es mit TSOPs als Empfänger sehr gut klappen. Fragt sich nur, ob das auch mit Milchglas oder nur mit Acrylglas geht. Probieren geht da über studieren ;-)
Klasse Idee, ich hatte mal an so etwas ähnliches mit Lichtschranken gedacht aber mit IR ist natürlich auch super! Ich sehe dabei nur das Problem, was passiert wenn die Scheibe sich irgendwann "durchbiegt"... hier reichen ja Millimeter bereits aus um dem IR einen falschen Weg zu weisen oder nicht?! Hab jetzt keine Angaben dazu gefunden, aber kann man dazu wirklich "stink normale" IR LEDs nutzen? reichen die dafür aus? Müsste man mal erforschen... aber an sich gefällt mir diese Technik mega gut ! sehr schöner Beitrag ! :-)
Hi Frank, das ist allerdings ziemlich cool, günstig und effizient! Für Anwendung bei den Tisch fallen mir dazu zwei Dinge ein: Ich wünsche mir ja auch die Erkennung von Annäherung, das ginge damit nicht. Das funktioniert wohl über den Fettfilm des Fingers bzw die spezifischen Eigenschaften der Haut - den Glibberfaktor (wie nennt man das wissenschaftlich :-) ) - d.h. die Haut verbindet sich ein wenig mit der Oberfläche und bricht so die Reflexion. Das würde dann wahrscheinlich mit Tassen, Gläsern etc nicht funktionieren und das ist einer Dinge, die man mit dem Tisch machen kann: die Farbe wechseln wo etwas abgestellt wird.
asterix schrieb: > Ich sehe dabei nur das Problem, was passiert wenn die Scheibe sich > irgendwann "durchbiegt"... hier reichen ja Millimeter bereits aus um dem > IR einen falschen Weg zu weisen oder nicht?! Die Platte wird ja wohl auf einem zellenförmigen Gebilde liegen und nicht frei in der Luft hängen. Von daher wird auch nichts durchbiegen. > Hab jetzt keine Angaben dazu gefunden, aber kann man dazu wirklich > "stink normale" IR LEDs nutzen? reichen die dafür aus? Ich sehe bei FTIR-Beschreibungen immer nur stinknormale LEDs. Aber ich nehme mal an, dass dasselbe Prinzip auch für IR-Licht funktioniert. Hätte den Vorteil, dass man TSOPs benutzen kann und sich damit unabhängig vom Umgebungslicht macht. Ich werde das die Tage testen.
Conny G. schrieb: > Das funktioniert wohl über den Fettfilm des Fingers bzw die spezifischen > Eigenschaften der Haut - den Glibberfaktor (wie nennt man das > wissenschaftlich :-) ) - d.h. die Haut verbindet sich ein wenig mit der > Oberfläche und bricht so die Reflexion. > Das würde dann wahrscheinlich mit Tassen, Gläsern etc nicht > funktionieren und das ist einer Dinge, die man mit dem Tisch machen > kann: die Farbe wechseln wo etwas abgestellt wird. Das müsste man untersuchen. Der Thread hier heißt ja auch ursprünglich Gegenstandserkennung. Ohne eine Tasse oder Ähnliches erkennen zu können wäre doch etwas schade... für den Touch mit Händen wäre es sehr genial
Hi Conny, Conny G. schrieb: > Ich wünsche mir ja auch die Erkennung von Annäherung, das ginge damit > nicht. Nein, es muss ein direkter Kontakt mit der Platte hergestellt werden. > Das würde dann wahrscheinlich mit Tassen, Gläsern etc nicht > funktionieren und das ist einer Dinge, die man mit dem Tisch machen > kann: die Farbe wechseln wo etwas abgestellt wird. Das müsste man erstmal ausprobieren. Ich glaube nicht, dass es das Fett auf den Fingern ist. Dort, wo ein Gegenstand die Platte berührt, ändert sich der Brechungsindex des Materials. Das Licht wird dann nicht mehr an der Oberfläche totalreflektiert, sondern vom Gegenstand darüber in einem anderen Winkel, so dass das Licht dann nach unten austreten kann. Es sollte daher auch mit normalen Gegenständen wie Kaffeetassen gehen. Wie gesagt: Ich teste das. Ich habe zuhause wg. IRMP genügend IR-Dioden, TSOPs und auch noch irgendwo eine Acryglasscheibe rumfliegen. Wenn Du wirklich Annäherungen erkennen willst, dann wirds echt aufwändig. Wie wärs mit 2 Webcams an der Decke oberhalb des Tisches? ;-)
:
Bearbeitet durch Moderator
Wie deine Acrylglasscheibe beschaffen ist wäre dann auch interessant zu wissen Das Problem ist, dass die Vorstellungen nun etwas auseinander gehen. So wie ich die Resonanz hier festgestellt habe ist ein "richtiges Touch" erwünscht und keine >3cm Objekterkennung. Man müsste dann nach dem Test von Frank M. genau abgrenzen in welche Richtung das ganze laufen soll :-)
Angehängte Dateien:
Frank M. schrieb: > Dabei ist mir die FTIR-Technik über den Weg gelaufen: Interessant. Das Konzept klingt logisch und gefällt mir gut. Andererseits beeinflusst das auch die Tischkonstruktion, weil die Seiten nicht mehr den Abschluss bilden können. Frank M. schrieb: > Man muss also nur seitlich an der Scheibe ein paar IR-LEDs anbringen, > welche erstmal wegen der Totalreflektion ein IR-Licht erzeugen, welches > normalerweise "innerhalb" der Scheibe verbleibt. Zum Anbringen von LEDs an der Seite würden sich ggf. die Halterungen anbieten, welche man normalerweise bei Glasbodenbeleuchtungen erhält: Hab da mal was angehängt. Quelle: [1] Müsste man halt sehen, ob man IR-LEDs in dem benötigten Formfaktor kaufen kann und wie viele man braucht (je nach Abstrahlwinkel?). Frank M. schrieb: > Wenn Du wirklich Annäherungen erkennen willst, dann wirds echt > aufwändig. Wie wärs mit 2 Webcams an der Decke oberhalb des Tisches? ;-) Dann lieber Xbox Kinect ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://www.lidl.de/media/product/0/0/6/1/1/8/5/livarno-lux-led-glasbodenbeleuchtung-regular--1.jpg
Wieviele IR-LEDs pro Pixelreihe würde man ungefähr benötigen?
asterix schrieb: > Wieviele IR-LEDs pro Pixelreihe würde man ungefähr benötigen? Das kommt ganz auf die Glasplatte an und den Abstrahlwinkel der IR-LEDs an, hält sich aber stark in Grenzen (~3 pro Seite?).
asterix schrieb: > Wieviele IR-LEDs pro Pixelreihe würde man ungefähr benötigen? Das würde ich nicht "pro Pixelreihe", sondern eher "pro Tisch" bestimmen. Die LEDs senden sowieso alle dasselbe, müssen also nicht einzeln angesteuert werden. Ich habe mal ein paar Links zu Selbstbau-Touch-Scheiben auf FTIR-Basis zusammengetragen: http://www.larrystendebach.com/windows-7-multi-touch-table-ftir-diy/ http://sethsandler.com/multitouch/ http://www.maximumpc.com/article/features/build_your_own_multitouch_surface_computer Meist werden ca. 24 IR-LEDs an beiden kurzen Seiten verwendet - meist einfach in Reihe geschaltet. Als IR-Sensor wird eine Webcam verwendet, welche mit einem Tageslichtfilter versehen wird, damit nur das IR-Licht an der Webcam ankommt. Die Demos sind echt beeindruckend. Da muss ich mir echt überlegen, ob ich einen LED-Tisch mit 20x10 oder doch direkt einen Tisch in HD-Auflösung baue. Tetris kann man jedenfalls mit beiden Lösungen spielen ;-)
:
Bearbeitet durch Moderator
Frank M. schrieb: > Meist werden ca. 24 IR-LEDs an beiden kurzen Seiten verwendet - meist > einfach in Reihe geschaltet. Puh doch so viel ;). Bei deiner Idee mit TSOPs müssten die ja alle synchron laufen, um vom TSOP detektiert werden zu können? Klar, man kann, wie gesagt, alle in Reihe schalten :). Und wie sieht es mit Gegenstandserkennung aus? Bist du da zufällig schon über Bilder/Videos gestoßen? Ich seh immer nur Finger und Hände ;). Mit freundlichen Grüßen, Karol Babioch
was mir noch gerade eingefallen ist... Multitouch? Wenn am Anfang der Reihe der Strahl reflektiert wird, können die dahinter folgendenden nicht per Touch angesteuert werden, das heißt man stellt sie mehr oder weniger stumm... oder wie sieht dafür die Lösung aus? Ich werde mir mal geich die Links zu gemüte führen
asterix schrieb: > Ich werde mir mal geich die Links zu gemüte führen Schau dir die Links doch einmal an ;). Man kann jeden einzelnen Finger einer Hand detektieren. Hängt wohl auch damit zusammen, dass man viele LEDs hat ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Frank M. schrieb: >> Meist werden ca. 24 IR-LEDs an beiden kurzen Seiten verwendet - meist >> einfach in Reihe geschaltet. > > Puh doch so viel ;). Bei deiner Idee mit TSOPs müssten die ja alle > synchron laufen, um vom TSOP detektiert werden zu können? Klar, man > kann, wie gesagt, alle in Reihe schalten :). Eben, alle in Reihe oder mehrere Reihen als Gruppen an einem MosFet. Die IR-LEDs kosten nur ein paar Cent. Selbst bei 48 Stück sind es nur um die 15 EUR. > Und wie sieht es mit Gegenstandserkennung aus? Bist du da zufällig schon > über Bilder/Videos gestoßen? Ich seh immer nur Finger und Hände ;). Leider nein. Ich sehe auch immer nur Finger. Im ersten Video sieht man aber kurz ein Handy auf dem Tisch liegen, was eine Wellenbewegung des Bildes auslöst. Ob das echt ist? Muss man wohl ausprobieren.
Ich habe mittlerweile auch mindestens ein Video gesehen, wo Gegenstände erkannt werden. Zum Beispiel kleine 5x5cm große klare Plexischeiben, die man auf den Tisch legt. Sofort wird auf diesen Scheiben ein kleines Video abgespielt. Verschiebt man die Scheiben auf dem Tisch, wandert das Video immer mit, d.h. es sieht so aus, als wäre die kleine Plexischeibe ein eigenes Display. Andere Gegenstände, die ich gesehen habe: Handys und Kreditkarten, die auf dem Tisch abgelegt bzw. verschoben und erkannt werden. Will ich auch haben! Dagegen wirkt ein 20x10 LED-Tisch wie ein Oldtimer aus dem letzten Jahrhundert.... wenn man's doch "Old-Style" haben möchte, kann man ja einen 20x10 LED-Tisch per Software projezieren ;-)))
das ganze per Beamer etc. löst sich dann aber vom eigtl. Thema etwas ab und stellt ein eigenes Projekt da ;-)
Frank M. schrieb: > Will ich auch haben! Dagegen wirkt ein 20x10 LED-Tisch wie ein Oldtimer > aus dem letzten Jahrhundert.... wenn man's doch "Old-Style" haben > möchte, kann man ja einen 20x10 LED-Tisch per Software projezieren ;-))) Entführt da jemand den Thread? :-)
Conny G. schrieb: > Entführt da jemand den Thread? :-) Keine Angst, ich hatte nur gerade einen kleinen Begeisterungsanfall :-) Also wie gesagt, ich werde das mal mit ein paar IR-Dioden und einem TSOP und einer Scheibe testen. Sollte mich tatsächlich das Fieber gepackt haben, einen Full-HD-Tisch zu bauen, werde ich dafür einen eigenen Thread aufmachen.
Frank M. schrieb: > Keine Angst, ich hatte nur gerade einen kleinen Begeisterungsanfall :-) Den hast du uns denk ich gerade allen verpasst, ich finde die Technik sehr gut :-)) > Also wie gesagt, ich werde das mal mit ein paar IR-Dioden und einem TSOP > und einer Scheibe testen. Kannst du das evtl. zeitlich eingrenzen, wann man dort mit Ergebnissen rechnen kann?!
http://www.lowres.ch/ftir/ hier sieht man, dass relativ viele LEDs zum Einsatz kommen... also mit mindestens 3 pro Reihe (10x10) müsste man denke ich schon rechnen
Tim R. schrieb: >> Also wie gesagt, ich werde das mal mit ein paar IR-Dioden und einem TSOP >> und einer Scheibe testen. > Kannst du das evtl. zeitlich eingrenzen, wann man dort mit Ergebnissen > rechnen kann?! Ich habe dafür frühestens am nächsten Wochenende Zeit. Mittlerweile ist aber nach ausführlicher Lektüre diverser Dokumentationen/Anleitungen mein Enthusiasmus etwas gedämpft: Der FTIR-Effekt ist nur einigermaßen vernünftig messbar, wenn man auf die Acryl-Scheibe noch ein paar Schichten einer Silikon-Mischung aufträgt. Dies verstärkt den FTIR-Effekt. Ich weiß nicht, ob dieser Aufwand für einen LED-Tisch nicht zu hoch ist: Die Anzahl der nötigen LEDs wächst zwar nur linear mit den Ausmaßen des Tisches (während die Anzahl der LEDs bei einer pro Zelle quadratisch wächst), aber bei 10x10 oder auch 10x20 spart man da gar nicht soviel ein - falls überhaupt. Es gäbe auch noch die Möglichkeit, die IR-LEDs ein paar Millimeter über dem Tisch anzubringen, also Lichtschranken (horizontal und vertikal) zu spannen. Dann könnte man die Position von Fingern und Gegenständen schon schwebend über dem Tisch ermitteln. Das macht aber dann eine aufwändige Rahmenkontruktion notwendig und sieht bestimmt nicht so schön aus wie ein planer Glastisch. Also die Sensor-Geschichte ist noch nicht ausgestanden. Wahrscheinlich ist es doch am einfachsten, in jede Zelle unterhalb des Tisches eine IR-LED zu stopfen und dann eine Reflektion zu messen, wenn jemand etwas drauflegt. Aber hier mal Frage an Conny und Karol: Euch ist schon bewusst, dass ein LED-Tisch mit 10x20 sehr grobkörnig ist und eine abgestellte Kaffeetasse im Normalfall nicht genau über einer LED abgestellt wird und damit evtl. Nachbar-LEDs oder gar keine anspringen, um die Kaffeetasse von unten zu beleuchten? Ich halte den Sinn eines solchen Tisches mittlerweile für ziemlich fragwürdig. Es ist eine nette Spielerei, keine Frage.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Aber hier mal Frage an Conny und Karol: Euch ist schon bewusst, dass ein > LED-Tisch mit 10x20 sehr grobkörnig ist und eine abgestellte Kaffeetasse > im Normalfall nicht genau über einer LED abgestellt wird und damit evtl. > Nachbar-LEDs oder gar keine anspringen, um die Kaffeetasse von unten zu > beleuchten? Ich halte den Sinn eines solchen Tisches mittlerweile für > ziemlich fragwürdig. Es ist eine nette Spielerei, keine Frage. Ja, der Tisch ist völlig sinnfrei - das war die Ausgangslage :-) Ist wirklich nur eine coole Spielerei und die groben Zellen sind eigentlich ein schöner Charakterzug so eines Tisches. Man darf es nicht aus der Ecke: Multitouch-Tisch mit Projektor darunter betrachten, der ja schon als Arbeitsgerät durchgeht. Sondern eher als gepimptes, interaktives RGB-beleuchtetes Kunstobjekt mit Wow-Effekt - wenn man die Spiele und Animationen damit machen kann. Genau aus dem Grund ist es interessant durch clevere Lösungen die Konstruktion in Kosten und Bauzeit einigermassen effizient zu machen - denn was der hier http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html an Aufwand abgefackelt hat (man sehe sich die Verkabelung und die Hauptplatine an - enorm aufwändig), das ist nicht für jedermann :-) Ich find so einen Tisch echt witzig und cool - aber nicht für 1.000 Euro und Monate Bauzeit. Muss jetzt auch kein Schnäppchen werden, aber für 300-400 Euro und ein paar Wochenenden Bauzeit ist es schon ok. Da steckt dann noch genug Arbeit in der Software um die Coolness wirklich freizusetzen. Sowas wie das hier: http://www.solderlab.de/index.php/led-projects/true-color-matrix (Mosaik-Variante unten) ist auch funktionell völlig sinnfrei - aber man darf es nicht als missglückten "Screen" sehen, sondern als RGB Kunstwerk. (Sowas bau ich mir auch irgendwann noch... :-) )
:
Bearbeitet durch User
Conny G. schrieb: > Man darf es nicht aus der Ecke: Multitouch-Tisch mit Projektor darunter > betrachten, der ja schon als Arbeitsgerät durchgeht. > Sondern eher als gepimptes, interaktives RGB-beleuchtetes Kunstobjekt > mit Wow-Effekt - wenn man die Spiele und Animationen damit machen kann. Jupp, sehe ich genau so. Klar wäre ein HD-Touch was schönes, aber dieses interaktive RGB Touch find ich hat seinen Scharm > Da steckt dann noch genug Arbeit in der Software um die Coolness > wirklich freizusetzen. Satz des Tages! :-D Ich würde sagen, dass nach den ersten Tests mit dieser Technik (ohne gesonderdes Acryl) man entcheiden kann, wie es weiter geht.
Conny G. schrieb: > Ja, der Tisch ist völlig sinnfrei - das war die Ausgangslage :-) Gut, dann sind wir uns ja einig :-) > Ist wirklich nur eine coole Spielerei und die groben Zellen sind > eigentlich ein schöner Charakterzug so eines Tisches. Stimmt schon. Ich muss nur das HD-Dingens da aus meinen Gedanken verbannen ;-) > Sowas wie das hier: > http://www.solderlab.de/index.php/led-projects/true-color-matrix > (Mosaik-Variante unten) ist auch funktionell völlig sinnfrei - aber man > darf es nicht als missglückten "Screen" sehen, sondern als RGB > Kunstwerk. > (Sowas bau ich mir auch irgendwann noch... :-) ) Sowas ist mit den Equinox-Streifen kein Problem, mit 32 Stück hast Du zwar nur 32x15 statt 32x16, aber was da im Video abgeht, mache ich mit nur einem ATmega168 als Master.
Den RGB-Touch Tisch kann man auch als normalen Tisch verwenden. Ist der Beamer-Tisch dazu geeignet?!
asterix schrieb: > Den RGB-Touch Tisch kann man auch als normalen Tisch verwenden. Ist der > Beamer-Tisch dazu geeignet?! Das ist die Frage. Wegen der Rückprojektionsfolie und der Silikonschicht zwischen der Acryglasplatte und der Folie wahrscheinlich nicht. Und deswegen scheidet für mich FTIR als Sensor-Möglichkeit für den LED-Tisch mittlerweile auch ziemlich aus. Überlege mir, ob ich den FTIR-Test überhaupt noch machen sollte und nicht besser testen soll, ob eine Hand über einer kratzfesten Milchglasplatte genügend IR-Licht (das von unten kommt) reflektiert, dass ein TSOP anspricht, also: Hand/Finger ----------------------- Glasplatte ^ ^ IR-LED TSOP Und dann noch die Frage: Was passiert ohne Hand? Wenn man Pech hat, reflektiert die Glasplatte dann immer noch. In dem Fall müsste man die Modulationsfrequenz soweit in/aus den Grenzbereich des TSOPs fahren, dass dieser gerade eben nicht anspricht. Das wäre quasi eine Kalibrierung, die der Slave nach dem Booten als erstes machen könnte.
Frank M. schrieb: > > Das ist die Frage. Wegen der Rückprojektionsfolie und der Silikonschicht > zwischen der Acryglasplatte und der Folie wahrscheinlich nicht. Und > deswegen scheidet für mich FTIR als Sensor-Möglichkeit für den LED-Tisch > mittlerweile auch ziemlich aus. Überlege mir, ob ich den FTIR-Test > überhaupt noch machen sollte Warum nicht, vllt funktioniert es ja auch ohne extra besondere Folie und Silikonschicht. > und nicht besser testen soll, ob eine Hand > über einer kratzfesten Milchglasplatte genügend IR-Licht (das von unten > kommt) reflektiert, dass ein TSOP anspricht, also: > > Hand/Finger > ----------------------- Glasplatte > ^ ^ > IR-LED TSOP > > Und dann noch die Frage: Was passiert ohne Hand? Wenn man Pech hat, > reflektiert die Glasplatte dann immer noch. In dem Fall müsste man die > Modulationsfrequenz soweit in/aus den Grenzbereich des TSOPs fahren, > dass dieser gerade eben nicht anspricht. Das wäre quasi eine > Kalibrierung, die der Slave nach dem Booten als erstes machen könnte. Was ist der Ziel des Tests? Ob die Milchglasplatte das hergibt, was gehofft wird?! Ist durchaus sinnvoll, wenn die meisten auf Plexiglas verzichten wollen. Hast du denn eine zumindest von den Eckdaten geeignete Platte?
Hallo Frank, mal ganz dumm gefragt, warum nutzt Du nicht die Wärmestrahlung des Menschens ( Infrarot im Bereich 7-14µm ) zur Erkennung der Annäherung der Hand. Gruss Roman
RomanK schrieb: > die Wärmestrahlung des Menschens Zu viele Einflussfaktoren: z.B. Sonnenschein, heiße Tee-Tasse auf dem Tisch, kalte Hände (gerade bei Frauen), urste Hitze im Sommer etc.
Frank M. schrieb: > Und dann noch die Frage: Was passiert ohne Hand? Wenn man Pech hat, > reflektiert die Glasplatte dann immer noch. Das war bei mir der Fall, ja. > In dem Fall müsste man die > Modulationsfrequenz soweit in/aus den Grenzbereich des TSOPs fahren, > dass dieser gerade eben nicht anspricht. Das habe ich nicht probiert, bin aber gespannt, ob das zuverlässig hinzubekommen ist. Unabhängig davon kommt meine oben vorgeschlagene Lösung mit nur einer IR-Photodiode aus und kostet 1/4 eines TSOPs. Allerdings stellt es sich als echtes Problem heraus entsprechende Glasmuster zu organisieren. Bei vielen Angeboten zahlt man für das bisschen benötigte Glas (15x15cm) 30 Euro aufwärts. Habe mittlerweile günstige Muster erhalten, die sind dafür dann aber nur 10x10cm und 4mm stark. Mit freundlichen Grüßen, Karol Babioch
RomanK schrieb: > mal ganz dumm gefragt, warum nutzt Du nicht die Wärmestrahlung des > Menschens ( Infrarot im Bereich 7-14µm ) zur Erkennung der Annäherung > der Hand. Weil der Tisch dann auch nur auf Mensch, Hund, Katze, Kaffee, Tee und heißen Amaretto reagiert und nicht auf: Wein, Bier, Schlüssel, Telefon etc. :-)
Karol Babioch schrieb: > Das habe ich nicht probiert, bin aber gespannt, ob das zuverlässig > hinzubekommen ist. Unabhängig davon kommt meine oben vorgeschlagene > Lösung mit nur einer IR-Photodiode aus und kostet 1/4 eines TSOPs. Wird aber aufwändiger von der Software. Du brauchst dann einerseits einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), andererseits brauchst Du einen verlässlichen Tageslichtfilter - geschrieben in Software. Wenn Du da was Gutes hast, dann lassen wir das mit dem TSOP.
Frank M. schrieb: > > Wird aber aufwändiger von der Software. Du brauchst dann einerseits > einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), Nana, kaum einer? Der Tiny25/45/85, 24/44/84 hat welche. Und sogar der 13er sollte ADC haben.
Frank M. schrieb: > Du brauchst dann einerseits > einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), Der ATtiny25/45/85 auch, sogar mit jeweils 4 Kanälen ;). Frank M. schrieb: > andererseits brauchst Du einen verlässlichen Tageslichtfilter - > geschrieben in Software. Das besteht derzeit aus der Differenz von zwei Messungen: Einmal mit und einmal ohne eingeschalteter IR-LED. Soweit auch schön und gut. Bin für neue Ideen/Konzepte offen, kann im Bereich Signalaufbereitung und -filterung sicher noch eine Menge lernen. Man müsste halt in erster Linie mal sehen, wie sich das in einem echten Prototypen verhält. Bisher stand mir nur durchsichtiges Floatglas zur Verfügung. Außerdem habe ich festgestellt, dass die verwendeten Photodioden (ELPD204-6B) ziemlich unterschiedliche Charakteristiken aufweisen. Um eine Kalibrierung wird man also nicht herum kommen. Ideen hierfür? Beim Einschalten unter der Annahmen, dass der Tisch "leer" ist, sollte das ja klappen, oder? Frank M. schrieb: > Wenn Du da was Gutes hast, dann lassen wir das mit dem TSOP. Will dich nicht vom experimentieren abhalten. Interessieren würde es mich auch. TSOPs und IR-LEDs müsste ich auch noch über haben. Wie genau hast du dir das Softwaretechnisch vorgestellt? Nach dem Einschalten solange die Frequenz erhöhen, bis der TSOP low zurückliefert? In welchen Schritten? Gehst du davon aus, dass eine einmalige Kalibrierung dieser Art reicht, oder muss man das (während der Laufzeit?) ggf. öfters tun, wenn sich das Umgebungslicht und ähnliche Faktoren ändern? Habe den TSOP nie in so einer kreativen Art und Weise eingesetzt. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Frank M. schrieb: > Karol Babioch schrieb: >> Das habe ich nicht probiert, bin aber gespannt, ob das zuverlässig >> hinzubekommen ist. Unabhängig davon kommt meine oben vorgeschlagene >> Lösung mit nur einer IR-Photodiode aus und kostet 1/4 eines TSOPs. > > Wird aber aufwändiger von der Software. Du brauchst dann einerseits > einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), > andererseits brauchst Du einen verlässlichen Tageslichtfilter - > geschrieben in Software. > > Wenn Du da was Gutes hast, dann lassen wir das mit dem TSOP. Da hätte ich ein Modell dafür im Kopf: IR-LED pulst mit 10, 20 oder 30 kHz. ADC misst die Photodiode mit der doppelten Frequenz, also 20, 40 oder 60 kHz und zwar genau in der Mitte von "IR-LED an" und in der MItte von "IR-LED aus". Damit gibt es eine Differenz zwischen der Messung "IR-LED an" und der Messung "IR-LED aus" (Tageslicht). Das ist die Basis-Kalibrierung, die jeder einzelne Pixel dynamisch als Referenz mitführt als Durchschnitt über x Messungen. Hält nun jemand die Hand darüber, steigt die IR-Lichtstärke bei der "IR-LED An"-Messung und wir sehen ein Annäherungsevent, ab einer gewissen Schwelle. D.h. der analoge Touch-Wert, den jeder Pixel an den Master senden wäre die Änderung dieser Differenz. Also bei gleichbleibenden Verhältnissen, ohne Berührung oder Annäherung, senden wir "0". Bei Annäherung denjenigen Betrag, den wir bei "IR An" hinzugewinnen.
:
Bearbeitet durch User
bin mir nicht sicher, aber die Rechnung beinhaltet glaube ich nicht, dass wenn die Hand drüber gehalten wird, auch die Umgebungshelligkeit sinkt sprich die Differenz wird ein schwieriger Wert an dieser Stelle, weil beide Faktoren sich stetig ändern... oder denk ich gerade falsch?
oder doch... da durch wird die differenz größer und es sollte sogar leichter messbar sein, nicht?
Hallo Karol, was meinst Du genau, wenn Du schreibst, dass die Everlight Photodiode unterschiedlichen Charakteristiken hat? Die im Datenblatt enthaltene spektrale Empfindlichkeit ist auf jeden Fall physikalisch nicht realisierbar. Silizium "sieht" bis etwa 1120nm, dann ist Schluß. Im Datenblatt geht es bei Raumtemperatur bis 1300nm. Das ist Unfug. Gruß kokisan
Karol Babioch schrieb: > Der ATtiny25/45/85 auch, sogar mit jeweils 4 Kanälen ;). Sorry, ja, hatte das velwechsert mit den UARTs, die gerade bei den ATTinys so rar sind. Kommt daher, dass ich ADCs so gut wie gar nicht verwende. (Mein Leben verläuft also fast ausschließlich "digital" ;-) ) > Das besteht derzeit aus der Differenz von zwei Messungen: Einmal mit und > einmal ohne eingeschalteter IR-LED. Ob das reicht? Was passiert, wenn ich irgendeine FB drücke, um meinen Fernseher anzuwerfen? Was passiert, wenn ich das Licht im Raum anknipse, gerade dann, wenn irgendein ATTiny meint, er müsse gerade mal "mit"/"ohne" IR-LED die Hintergrundstrahlung messen? Was bedeutet das dann für Deine Sensor-Software? Was ist dann "ohne", was "mit"? Genau aus diesem Grund werden bei Lichtschranken und bei Fernbedienungen immer modulierte Signale genommen, um sich vom Umgebungslicht unabhängig zu machen. Schau Dir mal die Innenbeschaltung eines TSOPs an, dann weißt Du, was die da für einen Aufwand an Filterung treiben. Genau das müsste man in Software nachbilden. Mit je einer Messung "mit" und "ohne" ist es nicht getan. > Außerdem habe ich festgestellt, dass die verwendeten Photodioden > (ELPD204-6B) ziemlich unterschiedliche Charakteristiken aufweisen. Um > eine Kalibrierung wird man also nicht herum kommen. Ideen hierfür? Beim > Einschalten unter der Annahmen, dass der Tisch "leer" ist, sollte das ja > klappen, oder? Ja, beim Einschalten sollte der Tisch leer sein. > Will dich nicht vom experimentieren abhalten. Interessieren würde es > mich auch. TSOPs und IR-LEDs müsste ich auch noch über haben. Wie genau > hast du dir das Softwaretechnisch vorgestellt? Nach dem Einschalten > solange die Frequenz erhöhen, bis der TSOP low zurückliefert? Ja, genau so. Oder systematisch runter mit der Frequenz. > In welchen Schritten? In 4 kHz-Schritten, also z.B. 38, 42, 46, 50, usw. EDIT: Intervallschachtelung wäre hier sinnvoll: Also erst in großen Schritten. Wenn man dann eine Grenze gefunden hat, in kleineren Schritten nochmal nachmessen, bis man einen realen Wert gefunden hat und dann noch einen Sicherheitszuschlag drauf, also zum Beispiel: 32 -> 64 -> 50 -> 42 -> 46 -> 44 -> 45, dann plus 5. Resultat: 50. > Gehst du davon aus, dass eine einmalige Kalibrierung dieser > Art reicht, oder muss man das (während der Laufzeit?) ggf. öfters tun, > wenn sich das Umgebungslicht und ähnliche Faktoren ändern? Habe den TSOP > nie in so einer kreativen Art und Weise eingesetzt. Einmaliges Messen und Speichern des Wertes im EEPROM könnte reichen. Ändert man natürlich was an der Tischplatte (Höhe, Dicke, wasweissich), dann müsste man noch neu kalibrieren können. Ich nehme aber an, dass es nicht viel Zeit kostet, sicherheitshalber bei jedem Boot neu durchzumessen. Jede Messung dauert weniger als 1/10 Sekunde, nach spätestens einer Sekunde sollte die Angelegenheit erledigt sein. EDIT: Während des Betriebs muss wohl eher nicht neu kalibriert werden. Es ändert sich ja da nichts. TSOPs sind unabhängig von der Umgebungshelligkeit. Viele Grüße, Frank
:
Bearbeitet durch Moderator
Didi S. schrieb: > was meinst Du genau, wenn Du schreibst, dass die Everlight Photodiode > unterschiedlichen Charakteristiken hat? Der Spannungsverlauf schaut auf dem Oszilloskop für jede Diode anders aus, obwohl alle aus einer Charge sind. Didi S. schrieb: > Silizium "sieht" bis etwa 1120nm, > dann ist Schluß. Im Datenblatt geht es bei Raumtemperatur bis 1300nm. > Das ist Unfug. Das kann ich nicht bewerten. Frank M. schrieb: > Genau aus diesem Grund werden bei Lichtschranken und bei Fernbedienungen > immer modulierte Signale genommen, um sich vom Umgebungslicht unabhängig > zu machen. Gut, modularisieren wollte ich auch noch. Der Vorschlag von Conny gefällt mir gut, die IR-LED mit doppelter Frequenz zu betreiben. Dann kann man problemlos einmal "mit" und einmal "ohne" messen. Frank M. schrieb: > In 4 kHz-Schritten, also z.B. 38, 42, 46, 50, usw. Die Frage ist, ob das wiederum nicht zu grob ist. Kenne den TSOP und seine Empfangscharakteristiken nicht. Wie gesagt: Probier deine Idee ruhig mal aus, kann nicht schaden ;). Mit freundlichen Grüßen, Karol Babioch
Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger eignet. Es ist jetzt eine Weile her, daß ich ein entsprechendes Datenblatt gelesen habe, aber so ein moderner TSOP ist schon sehr gut auf seinen Einsatzzweck optimiert, nämlich das Datensignal des Senders zu detektieren, unabhängig von der Intensität mit der es ankommt, und so ein Verhalten können wir hier nicht ganz gebrauchen. Soweit ich mich erinnere, enthält der TSOP zwei AGC-Stufen: eine vor dem 40kHz-Filter und eine dahinter. Die erste verhindert, daß er von konstantem Umgebungslicht geblendet wird; die zweite verhindert, daß er von konstantem 40kHz-Störlicht (z.B. Energiesparlampe) geblendet wird. Und die zweite AGC-Stufe stört in dieser Anwendung, denn wir wollen ja unterscheiden können, wie stark das modulierte Signal des Senders beim TSOP ankommt, und genau das regelt die zweite AGC-Stufe weg. Da halte ich es für aussichtsreicher, das Filtern per Software zu machen, also den Unterschied zwischen dem Fotodiodensignal mit und ohne eingeschalteter IR-LED auszuwerten, um das Umgebungslicht rauszurechnen. Ich muß aber zugeben, daß ich keine praktischen Erfahrungen mit dem "Missbrauch" von TSOPs z.B. für Lichtschranken habe. Vielleicht gibt es ja noch welche ohne zweite AGC-Stufe; früher war es ja definitv so, daß Energiesparlampen so manche Fernbedienung lahmgelegt haben.
Nosnibor schrieb: > Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger > eignet. Ja, die Zweifel teile ich, lasse mich aber gerne vom Gegenteil überzeugen. In der Zwischenzeit arbeite ich weiter an meiner Photodioden Lösung. Die Detektierung ist robust, sogar mit einem 400-Watt Halogenstrahler im Raum ;) (Gibt es alternative Vorschläge für künstliche IR-Quellen?). Mein Pixel ist nach wie vor 5x5x3cm groß und das Ganze ist absolut unempfindlich gegenüber seitlichen Annäherungen. Das geht sogar soweit, dass einzelne Finger am Rand der Pixel nicht zuverlässig erkannt werden. Zwei Finger bzw. ein Finger in der Mitte hingegen funktionieren problemlos. Keine Ahnung, ob das so gewünscht ist, ändern kann man daran vermutlich nicht besonders viel. Annäherungen über dem Pixel sind ab etwa 5 cm über der Platte detektierbar. Einziger Wermutstropfen: Ich teste nach wie vor mit 2mm starken Floatglass. Das satinierte ist zwar auf dem Weg, braucht aber wohl noch ein bisschen. Insofern sind die vielversprechenden Ergebnisse mit Vorsicht zu genießen. Werde aber Photos bzw. ein Video erstellen, sobald ich einen "echten" Prototypen habe. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Nosnibor schrieb: >> Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger >> eignet. > > Ja, die Zweifel teile ich, lasse mich aber gerne vom Gegenteil > überzeugen. > > In der Zwischenzeit arbeite ich weiter an meiner Photodioden Lösung. Die > Detektierung ist robust, sogar mit einem 400-Watt Halogenstrahler im > Raum ;) (Gibt es alternative Vorschläge für künstliche IR-Quellen?). Fernbedienung? :-) > Mein Pixel ist nach wie vor 5x5x3cm groß und das Ganze ist absolut > unempfindlich gegenüber seitlichen Annäherungen. hast du denn neben dem Pixel auch eine IR-LED platziert, damit deine Hand diese Strahlen dann zum Sensor reflektieren kann? Oder hast du nur in dem einzelnen Pixel die IR-LED? Oder hast du allgemein mehrere Pixel? Wie sieht denn der Versuch in der Richtung aus > Das geht sogar soweit, > dass einzelne Finger am Rand der Pixel nicht zuverlässig erkannt werden. > Zwei Finger bzw. ein Finger in der Mitte hingegen funktionieren > problemlos. Das ist der oben erwähnte punktuelle Effekt. Die Sensorik+LED müsste wahrscheinlich wie Conny G. meinte noch weiter herunter gesetzt werden, um den Lichtkegel auf die Platte zu kriegen und nicht nur einen Bruchteil davon. Dann würde man evtl auch am Rand detektieren können
Karol Babioch schrieb: > Nosnibor schrieb: >> Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger >> eignet. > > Ja, die Zweifel teile ich, lasse mich aber gerne vom Gegenteil > überzeugen. Mir ist der TSOP wg. zuviel Eigenlogik auch eher unsympatisch. Lieber die Filterung selber kontrollieren. > In der Zwischenzeit arbeite ich weiter an meiner Photodioden Lösung. Die > Detektierung ist robust, sogar mit einem 400-Watt Halogenstrahler im > Raum ;) (Gibt es alternative Vorschläge für künstliche IR-Quellen?). > Mein Pixel ist nach wie vor 5x5x3cm groß und das Ganze ist absolut > unempfindlich gegenüber seitlichen Annäherungen. Das geht sogar soweit, > dass einzelne Finger am Rand der Pixel nicht zuverlässig erkannt werden. > Zwei Finger bzw. ein Finger in der Mitte hingegen funktionieren > problemlos. Keine Ahnung, ob das so gewünscht ist, ändern kann man daran > vermutlich nicht besonders viel. Annäherungen über dem Pixel sind ab > etwa 5 cm über der Platte detektierbar. Das liegt am Abstrahlwinkel der IR-Diode an sich, dass mit 3cm Tiefe nun die Seite nicht abgedeckt wird. Das Problem würde sich auch mit tieferen Zellen lösen. Das würde also einerseits bei breit strahlenden IR-Dioden die Breite begrenzen und bei eng strahlenden hilft der Abstand, dass der Kegel oben breit genug ist. Am Ende müssen die Tiefe, die Größe der Zelle und der Abstrahlwinkel der Diode zusammenpassen. Denn hätte man eine mit 120 Grad, aber sie ist 10cm tief, dann wird zwar der Winkel durch die Tiefe gefiltert, aber ich verliere 50% (oder mehr) der Lichtleistung für den Detektor.
Conny G. schrieb: > Mir ist der TSOP wg. zuviel Eigenlogik auch eher unsympatisch. > Lieber die Filterung selber kontrollieren. Jut, dann spare ich mir den TSOP-Test. Sicherlich lässt sich ein gescheites Filtern von Umgebungseinflüssen auch in Software bewerkstelligen. Gruß, Frank
wenn wir das das das und das nun sein lassen wollen, was bleibt denn noch alternativ... ich verliere ehrlich gesagt gerade etwas den überblick :-)
Angehängte Dateien:
-
LedTisch.jpg
210 KB
Hallo, auch ich wollt mir einen Tisch bauen. Nur leider ist das Projekt durch einen Kumpel gestorben, der mir das Programm schreiben sollte. Was ich schon hatte war das vorläufige Konzept des Tisches. Die "Messinffläche" soll das LED Feld mit 12x16 Pixeln (3:4) a 50x50mm darstellen. Die gelben Punke sollten Touch Sensoren unter der Glasfläche sein um auch mögliche Anwendungen ohne Smartphone oder Rechenr zu bedienen. Ansonsten hatte ich eine 10mm einseitig mattierte Glasplallte vorgesehen, die um das LED Feld schwarz lakiert/beschichtet/beklebt werden sollte. Der Rest ist billiger Baustahl xD. Angeschlage hatte ich ca 1000€ auch wenn das schon knapp werden wird. Eine Version 2.0 hatte ich nicht vor zu fertigen xD. Ich bin gespannt was hier auf der Elektrischen Seite entsteht und würde mich auch gerne beteiligen solange ich noch was verstehe als Metaller^^.
So, habe - mehr oder weniger aus Spaß - mal ein Video meines aktuellen Setups gemacht, siehe [1]. Baut derzeit auf einem ATmega88 auf, weil damit die UART Handhabung einfacher ist. Im Prinzip mache ich aber nichts, was nicht auch ein ATtiny85 bzw. ATtiny841 macht. Überhaupt ist die Software sehr simpel. In einer Timer-ISR schalte ich die IR-LED ein bzw. aus und starte eine ADC Konvertierung. Die Ergebnisse ziehe ich jeweils voneinander ab. Überschreitet die Differenz eine Schwelle (per Trial & Error festgestellt), schalte ich die blaue LED ein. Dafür, dass das Ganze so simpel und günstig ist, funktioniert es erstaunlich gut. Konnte es weder mit einer Fernbedienung noch mit einem Halogenstrahler aushebeln. Einziges Problem bei diesem Ansatz ist aber die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? Habe testweise auch IR-LEDs links und rechts betrieben, hat dem Ganzen nichts ausgemacht. Habe im Video auch versucht zu zeigen, dass der Sensor nicht auslöst, wenn man sich neben dem eigentlichen Sensor bewegt. Dafür sind die Reflexionen zu schwach. Wie gesagt: Ist alles noch mit Float-Glas. Das satinierte trifft wohl erst im Laufe der nächsten Woche ein. Ich persönlich bin von diesem Ansatz voll und ganz überzeugt. Unabhängig davon ist es auch im Preis nicht zu schlagen: 20 Cent für die IR-LED und 20 Cent für die Photodiode. Bei größeren Mengen ggf. sogar billiger. Bei einem ATtiny841 hätten wir ja auch mehr als genug Platz für eine "schlaue" Auswertung in Software. Da fehlt es bei mir aber im Wesentlichen an Ansätzen, für Vorschläge bin ich aber gerne offen. Mit freundlichen Grüßen, Karol Babioch [1]: http://youtu.be/e9vYGd5S3GQ
Seanten schrieb: > Die gelben Punke sollten Touch Sensoren unter der Glasfläche sein um > auch mögliche Anwendungen ohne Smartphone oder Rechenr zu bedienen. Gefällt mir gut die Idee bzw. dein ganzes Konzept. Wolltest du die gelben Touchflächen sichtbar gestalten, oder "versteckt" halten? Hier würde sich ja ggf. eine kapazitive Lösung anbieten, zumindest wenn man an dieser Stelle auf das Metall verzichtet ;). Für Metallarbeiten fehlt mir sowohl das Know-How als auch die Werkzeuge. Hätte mich auf Holz beschränkt. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > So, habe - mehr oder weniger aus Spaß - mal ein Video meines aktuellen > Setups gemacht, siehe [1]. Baut derzeit auf einem ATmega88 auf, weil > damit die UART Handhabung einfacher ist. Im Prinzip mache ich aber > nichts, was nicht auch ein ATtiny85 bzw. ATtiny841 macht. Überhaupt ist > die Software sehr simpel. In einer Timer-ISR schalte ich die IR-LED ein > bzw. aus und starte eine ADC Konvertierung. > > Die Ergebnisse ziehe ich jeweils voneinander ab. Überschreitet die > Differenz eine Schwelle (per Trial & Error festgestellt), schalte ich > die blaue LED ein. > > Dafür, dass das Ganze so simpel und günstig ist, funktioniert es > erstaunlich gut. Konnte es weder mit einer Fernbedienung noch mit einem > Halogenstrahler aushebeln. Einziges Problem bei diesem Ansatz ist aber > die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne > oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa > 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? > > Habe testweise auch IR-LEDs links und rechts betrieben, hat dem Ganzen > nichts ausgemacht. Habe im Video auch versucht zu zeigen, dass der > Sensor nicht auslöst, wenn man sich neben dem eigentlichen Sensor > bewegt. Dafür sind die Reflexionen zu schwach. > > Wie gesagt: Ist alles noch mit Float-Glas. Das satinierte trifft wohl > erst im Laufe der nächsten Woche ein. > > Ich persönlich bin von diesem Ansatz voll und ganz überzeugt. Unabhängig > davon ist es auch im Preis nicht zu schlagen: 20 Cent für die IR-LED und > 20 Cent für die Photodiode. Bei größeren Mengen ggf. sogar billiger. > > Bei einem ATtiny841 hätten wir ja auch mehr als genug Platz für eine > "schlaue" Auswertung in Software. Da fehlt es bei mir aber im > Wesentlichen an Ansätzen, für Vorschläge bin ich aber gerne offen. > > Mit freundlichen Grüßen, > Karol Babioch > > [1]: http://youtu.be/e9vYGd5S3GQ Sehr cool, das sieht wirklich überzeugend aus. Jetzt muss man nur noch den Öffnungswinkel optimieren für den Rand. Ich meine immer noch, dass die Zelle tiefer sein sollte. Bzgl gut und schlecht reflektierender Objekte hätte man nur eine Chance, wenn man den den Abstand misst, aber nicht über die Reflexionsstärke. Nur Anhand einer Menge von reflektiertem Licht kann man das nicht unterscheiden. Das einzige was mir zum Abstand einfällt wäre Lichtlaufzeit, die ist aber zu Kurz. Ansonsten irgendwas mit Interferenz, hab ich irgendwo mal was dazu gelesen. Mmmh. Aus dem Bauch würde ich sagen, dass wir da ein neues Niveau von Schwierigkeitsgrad betreten und sollten das erstmal akzeptieren, dass wir das nicht differenzieren können. Schadet natürlich nicht die Abstandsmessung für einen Tag zu recherchieren, vielleicht geht ja was :-)
http://www.google.com/patents/EP2290393A2?cl=de Konzept zur optischen Abstandsmessung [0017]: "wird hier jedoch eine kontinuierlich modulierte, sinusförmige Lichtquelle verwendet. Die Distanzinformation lässt sich dabei anhand der Phasenverschiebung des zurückreflektierten Lichts rekonstruieren. " Also prinzipiell würden sich die ToF (Time of flight) Verfahren eignen, die für die Pixel von 3D Kameras verwendet werden. http://de.wikipedia.org/wiki/Abstandsmessung_(optisch)#Messung_.C3.BCber_die_Phasenlage Ob das statt mit einem Laser auch mit einer IR Diode funktioniert? Müsste schon, wenn man nicht die IR Wellenlänge als Modulation nimmt. Das ist allerdings bestimmt ein mehrwöchiges bis mehrmonatiges Forschungsprojekt für sich, wenn das noch niemand gemacht und veröffentlicht hat.
:
Bearbeitet durch User
Das Prinzip Phasendifferenz mit moduliertem Lichtstrahl sähe rein von der Theorie am vielversprechensten aus, Seite 20f: http://tams-www.informatik.uni-hamburg.de/lehre/2003ws/vorlesung/angewandte_sensorik/vorlesung_06.pdf Wenn gemäß dem Beispiel eine Frequenz von 10 MHz eine Wellenlänge von 30m ergibt - und das der Messbereich 1x Lambda ist - und unser Messbereich kleiner als 30cm sein soll (eher sogar 10), dann müsste man also mit der 100-fachen Frequenz arbeiten, 1 GHz. Für 10cm sogar 3 GHz. Erscheint mir eher schwierig.
Conny G. schrieb: > Erscheint mir eher schwierig. Ja, das ist ohne Zusatzbeschaltung nicht zu schaffen und insofern unattraktiv. Werden wir uns wohl damit abfinden müssen, dass metallische Gegenstände "besser" erkannt werden. Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > Das Prinzip Phasendifferenz mit moduliertem Lichtstrahl sähe rein von > der Theorie am vielversprechensten aus, Seite 20f: > http://tams-www.informatik.uni-hamburg.de/lehre/2003ws/vorlesung/angewandte_sensorik/vorlesung_06.pdf Diese Präsentation sagt auch, dass Ir Reflexion zur Abstandsmessung ungeeignet ist (Seite 23)
1 | Infrarotsensoren (2) |
2 | ● In realistischen Umgebungen haben die Oberfl ̈achen unterschiedliche Farben. |
3 | ● Farbige Oberfl ̈achen reflektieren unterschiedlich viel Licht. |
4 | ● Schwarze Oberfl ̈achen sind praktisch unsichtbar. |
5 | ● IR-Sensoren ko ̈nnen eigentlich nur zu Objekterkennung nicht aber zur Entfernungsmessung eingesetzt werden. |
6 | ● Wenn ein IR-Signal vom Sensor empfangen wird kann man mit Sicherheit annehmen, dass sich ein Objekt vor dem Sensor befindet. |
7 | ● Phantomsignale sind sehr selten. |
8 | ● Fehlt ein IR-Signal heißt das allerdings nicht, dass kein Objekt vor dem |
9 | Sensor ist. |
10 | ● IR-Sensoren werden fu ̈r kurze Reichweiten eingesetzt (50 bis 100 cm). |
Conny G. schrieb: > ● IR-Sensoren werden fu ̈r kurze Reichweiten eingesetzt (50 bis 100 cm). Wobei das ja für uns relevant wäre. Wir wollen ja nicht die Entfernung des Mondes bestimmen ;). Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Was der wohl kostet? http://www.directindustry.com/prod/stmicroelectronics/proximity-sensors-33699-1448175.html http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/data_brief/DM00078006.pdf
:
Bearbeitet durch User
Conny G. schrieb: > Was der wohl kostet? > http://www.directindustry.com/prod/stmicroelectron... Die Frage ist auch, ob sich das Ganze nicht durch Reflektionen am Glas durcheinander bringen lässt. Selbes Problem gilt natürlich auch für alle o.g. Verfahren. Sehe hier keinen realistischen Ansatz ... Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> Was der wohl kostet? >> http://www.directindustry.com/prod/stmicroelectron... > > Die Frage ist auch, ob sich das Ganze nicht durch Reflektionen am Glas > durcheinander bringen lässt. Selbes Problem gilt natürlich auch für alle > o.g. Verfahren. Sehe hier keinen realistischen Ansatz ... > > Mit freundlichen Grüßen, > Karol Babioch Den gibt's noch nicht zu kaufen http://www.st.com/web/catalog/mmc/FM132/SC626/PF260441?s_searchtype=partnumber# Die Reflexionen verfälschen die Messung minimal um den Anteil des reflektierten Lichts, würde ich behaupten. Es dürfte dann die gemessene Entfernung anteilig um die Reflexionsrate kürzen. Wenn also die Reflexion der Oberfläche des Glases bei ein paar Prozent liegt sollte das eigentlich kein Problem sein, wenn diese Hypothese so stimmt. Dann wäre die gemessene Entfernung einfach um diese paar Prozent kürzer. Jedenfalls habe ich gerade ähnliches bei den TOF Kameras gelesen. Alternativ sinkt die Emofindlichkeit/Reichweite, weil der reflektierte Anteil in die Störunterdrückung läuft... Könnte mir vorstellen, dass eine Matte Oberfläche auf der Unterseite besser ist, da der Strahl nicht direkt zurück reflektiert wird, sondern die Reflexion wird diffus gestreut und weniger erreicht die IR Diode. Mmmh, dafür reflektiert Matt aber mehr als glattes Glas. Man bräuchte eine richtige Entspiegelung... Müsste man einfach mal messen, ob die IR Diode bei glattem Glas oder bei matter Oberfläche mehr reflektiertes IR sieht.
:
Bearbeitet durch User
Den Proximity Sensor von STM gibt es noch nicht, wohl aber andere. Ich arbeite sehr viel mit dem VCNL4010 oder dem VCNL4020. Diese Sensoren sind genau für solche Anwendungen wie dem Tisch entwickelt worden, aber eben leider etwas teuer. Inwieweit die deutlich günstigere Lösung mit IRED und Photodiode funktionieren wird, kann ich nicht sagen, aber das Tüfteln ist doch gerade der Reiz am Basteln. Hier noch ein paar Gedanken zu den (digitalen) VCNL Sensoren... Das nutzbare Signal zur Erkennung eines Objektes ergibt sich aus dem reklektierten Signal abzüglich dem Offsetsignal und dem Signalrauschen, also verwertbares Signal = reflektiertes Signal - Offset - Rauschen reflektiertes Signal: je größer das Objekt und je näher der Abstand zur Quelle, desto mehr Signal gibt es; Infrarotes Licht verhält sich ähnlich dem visuellen Licht; schwarze Flächen reflektieren erstaunlich gut, also schwarz anmalen oder besprühen der "Innenseiten der Tischwürfel" bringt nicht viel bei Infrarot; wenn seitliche Reflexe vermieden werden sollen/müssen lieber Textil oder extrem matte Farben verwenden Offset: wird erzeugt durch all das reflektierte Licht von der Glasscheibe und den Innenseiten des Würfels; die Größe des Offsets hängt ab von der Distanz zum Abdeckglas, sowie nahen Objekten und Grenzflächen im "Tischwürfel", weiterhin von Toleranzen des Sensors (Photodiode), dem IRED Strom, der Umgebungstemperatur, dem Typ des abdeckenden Glasscheibe und einfallendem Umgebungslicht Rauschen: sowohl beim digitalen, als auch beim analogen Sensor vorhanden. Die VCNL haben ein digitales Rauschen von etwa 9-11 counts. Entscheidenden Einfluß hat das Coverglas. Je transparenter es ist, um so mehr Signal steht zur Reflexion am zu detektiernden Objekt zur Verfügung. Nach meiner Erfahrung verhalten sich oberflächenmattierte oder angeraute (angeätzte) Glasoberflächen schlechte als Gläser, die im gesamten Volumen milchig oder diffus sind. Wenn hinter dem milchigen Abdeckglas ein Objekt nicht mehr erkant wird, bringt die Erhöhung des Sendestromes oft nicht den gewünschten Effekt, weil proportional auch der Offset mit ansteigt. Eine Verbesserung bringt aber die Verringerung der Distanz zwischen IRED und Coverglas oder die Einengung des Öffnungswinkels der IRED auf den für die Applikation notwendigen Winkel. Noch zwei Gedanken zur Software. Meine Realisierungen mit Proximity Sensoren haben gezeigt, dass man mehrere Szenarien von Filtern und Kalibrierungen benötigt oder zumindest darüber nachdenken sollte: 1) Alle Komponenten inklusive des Coverglases altern. Es muß also eine Möglichkeit geben, das System im Ruhezustand zu kalibrieren, soll heißen den Systemoffset zu bestimmen und zu berücksichtigen. Eventuell jedesmal, wenn der Tisch "gebootet" wird. 2) Der Tod infraroter Applikationen sind Leuchten, die hohe Anteile an "schmutziger" Infrarotstrahlung abgeben, also bitte unbedingt mit Energiesparlampen und Leuchtstoffröhren testen (je chinesischer die Leuchte, desto ...), wenn soetwas in der Nähe vorhanden sein sollte. Erst wenn die Softwarefilter diesen "Stress" rausfiltern ist das System vor Überraschungen sicher. Also weiterhin viel Spass beim Tüfteln am ProxiTable ;-)
:
Bearbeitet durch User
Hallo Frank M., Dein Ansatz ein TSOP zu benutzen und seine Empfindlichkeitsschwelle durch bewusstes Verschieben der Burstfrequenz zu realisieren, ist extrem spannend, da die Problematik und das Tuning in die Software verlagert wird. Ich habe bei den Entwicklern der TSOP Baureihe mal nachgefragt ob mit diesem Trick ein "Nahfeld"-Proximity mit Coverglas realisierbar ist. Die Antwort war nicht eindeutig. Auf jeden Fall solltest Du Bauteile mit fix Gain in Betracht ziehen, da Bauteile mit nachregelnder AGC Dir das Leben in diesem Fall vermutlich nur erschweren. Weiterhin muß Deine Frequenz vermutlcih besser 100Hz abgestimmbar sein. Wenn Du Dich trotzdem noch entschliessen solltest, hier mal weiterzutesten, kannst Du mir eine PN schicken. Ein paar fix gain TSOP hast Du vermutlich nicht in Deiner Schublade rumliegen, oder doch ;-) Wenn nicht, lässt sich da bestimmt was machen. Gruß Didi
Karol Babioch schrieb: > Die Ergebnisse ziehe ich jeweils voneinander ab. Überschreitet die > Differenz eine Schwelle (per Trial & Error festgestellt), schalte ich > die blaue LED ein. Du hast die Schwelle auf umgerechnet ca. 5cm über der Glasplatte kalibriert, habe ich das richtig gesehen? Wie sieht das Verhalten aus, wenn du nur knapp über dem Glas detektieren möchtest?? Ansonsten sieht das wirklich schon sehr gut aus! schön aufgeräumter Platz übrigens :-D > Dafür, dass das Ganze so simpel und günstig ist, funktioniert es > erstaunlich gut. Das Argument finde ich sehr gut. Im Gegensatz zu meinem IS471 Sensor den ich getetset hatte, sind das Welten vom Preis her. > Konnte es weder mit einer Fernbedienung noch mit einem > Halogenstrahler aushebeln. Einziges Problem bei diesem Ansatz ist aber > die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne > oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa > 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? Ich glaub wenn wir das noch unterscheiden möchten, kommen wir in Welten bei denen mehrere Bachelor-/Masterarbeiten draus entstehen könnten. Ich finde die Ansätze die gepostet wurden sehr interessant. Jedoch eine kostengünstige Variante die auch in absehbarer Zeit realisierbar ist, sehe ich noch nicht. Lasse mich aber gerne vom Gegenteil überzeugen. > Habe testweise auch IR-LEDs links und rechts betrieben, hat dem Ganzen > nichts ausgemacht. Habe im Video auch versucht zu zeigen, dass der > Sensor nicht auslöst, wenn man sich neben dem eigentlichen Sensor > bewegt. Dafür sind die Reflexionen zu schwach. Ab ca. 25sek im Video? Ich sehe dort leider keine IR-LED?! Zumindest vorne den Teil der Einsichtig ist, sehe auf dem Steckbrett keine Bauteile?! > Wie gesagt: Ist alles noch mit Float-Glas. Das satinierte trifft wohl > erst im Laufe der nächsten Woche ein. satiniert Plexi? > Ich persönlich bin von diesem Ansatz voll und ganz überzeugt. Unabhängig > davon ist es auch im Preis nicht zu schlagen: 20 Cent für die IR-LED und > 20 Cent für die Photodiode. Bei größeren Mengen ggf. sogar billiger. Wie ich oben gepostet habe, gebe ich dir vollkommen Recht > [1]: Youtube-Video "LED Tisch: Touch Pixel - Test" sehr schön ! :-)
Didi S. schrieb: > Ich > arbeite sehr viel mit dem VCNL4010 oder dem VCNL4020. Kannte ich noch gar nicht. Gut, die sind natürlich wesentlich teurer, aber sofern die auch durch Glas hindurch zuverlässig funktionieren, dann wäre es durchaus eine Überlegung wert. Zumal dadurch die Software "einfacher" wird, weil die Dinger per I2C angesteuert werden. Im Datenblatt des VCNL4010 heißt es z.B., dass dieser bis 200 mm spezifiziert ist. Wie verhält sich das mit einer Glasscheibe dazwischen? Prinzipiell hört sich die Größenordnung ja für unseren Anwendungsfall richtig an? 16-Bit sind auch eine Menge, bin gerade darüber erstaunt, dass sich das überhaupt so genau auswerten lässt ... Didi S. schrieb: > Eventuell > jedesmal, wenn der Tisch "gebootet" wird. Ja, das hatten wir sowieso vor. Didi S. schrieb: > Erst wenn die Softwarefilter diesen "Stress" rausfiltern ist das System > vor Überraschungen sicher. Da muss man sich wohl vernünftige Testszenarien einfallen lassen und auch mit mehreren Pixeln gleichzeitig experimentieren. Didi S. schrieb: > Dein Ansatz ein TSOP zu benutzen und seine Empfindlichkeitsschwelle > durch bewusstes Verschieben der Burstfrequenz zu realisieren, ist extrem > spannend, da die Problematik und das Tuning in die Software verlagert > wird. Halte den Ansatz auch für spannend, und wäre an Resultaten (sowohl negativ als auch positiver Natur) interessiert ;). Tim R. schrieb: > Du hast die Schwelle auf umgerechnet ca. 5cm über der Glasplatte > kalibriert, habe ich das richtig gesehen? Ja, so in etwa. Bezieht sich natürlich auf Haut bzw. Hände. Tim R. schrieb: > Wie sieht das Verhalten aus, > wenn du nur knapp über dem Glas detektieren möchtest? Auch möglich. Um so näher man ans Glas heran kommt, umso größer ist die gemessene Spannungsdifferenz. Tim R. schrieb: > Das Argument finde ich sehr gut. Im Gegensatz zu meinem IS471 Sensor den > ich getetset hatte, sind das Welten vom Preis her. Ja, eben. Tim R. schrieb: > Ich > finde die Ansätze die gepostet wurden sehr interessant. Jedoch eine > kostengünstige Variante die auch in absehbarer Zeit realisierbar ist, > sehe ich noch nicht. Lasse mich aber gerne vom Gegenteil überzeugen. Geht mir genauso. Tim R. schrieb: > Ab ca. 25sek im Video? Ja. Tim R. schrieb: > Ich sehe dort leider keine IR-LED?! Ne, das war eine andere Versuchsreihe. In dem Video gibt es tatsächlich nur eine IR-LED. Tim R. schrieb: > satiniert Plexi? Nein, satiniertes Glas. Bin nach einigen Anfragen zu akzeptablen Preisen an entsprechende Muster gekommen. Im Übrigen wird das Glas im Verhältnis deutlich günstiger, wenn man "große" Flächen bestellt. Mit freundlichen Grüßen, Karol Babioch
Also du hast auch wirklich IR-LEDs quasi in nebenan liegenden "Pixeln" strahlen lassen und konntest in deinem Testfeld keine Relefktionen erkennen ja ? erstaunlich finde ich... Um was für Preise handelt es sich denn bei dem Glas?
Hi Karol, kannst Du mal Deine Schaltung kurz beschreiben die Du für Deinen Versuch verwendet hast? Also welche IR-LED und IR-Phototransistor (oder Diode) und mit welchen Widerständen? Danke & Gruß Markus
Tim R. schrieb: > Also du hast auch wirklich IR-LEDs quasi in nebenan liegenden "Pixeln" > strahlen lassen und konntest in deinem Testfeld keine Relefktionen > erkennen ja ? Ja. Tim R. schrieb: > Um was für Preise handelt es sich denn bei dem Glas? Hab jetzt für verschiedene Muster zwischen 4 und 15 EUR gezahlt. Ansonsten kostet ein qm wohl so um die 100 EUR. Markus M. schrieb: > kannst Du mal Deine Schaltung kurz beschreiben die Du für Deinen Versuch > verwendet hast? Die IR-LED wird direkt vom AVR betrieben. Vorwiderstand 100 Ohm. 125 Hz PWM mit 50 % Duty Cycle. Der resultierende Strom sind damit etwa 40 mA. Die Photodiode ist so wie hier [1] beschrieben, an einen ADC Eingang angeschlossen. Widerstand ist direkt übernommen, 1 Megaohm, da die Kanten am Oszilloskop scharf genug sind. Markus M. schrieb: > Also welche IR-LED und IR-Phototransistor (oder Diode) IR-LED ist eine ELIR204-6B von Everlight. Photodiode: ELPD204-6B, auch von Everlight. Ein Phototransistor eignet sich hier übrigens nicht besonders, weil der zu langsam schaltet, insbesondere wenn man die Frequenz erhöht. Habe zwischenzeitlich nämlich auch mit dem ELPT204-6B herumgespielt, aber das haut nicht wirklich hin. Mit freundlichen Grüßen, Karol Babioch [1]: https://www.mikrocontroller.net/articles/Datei:Photo_diode.png
Karol Babioch schrieb: > Hab jetzt für verschiedene Muster zwischen 4 und 15 EUR gezahlt. > Ansonsten kostet ein qm wohl so um die 100 EUR. hmm okay... Plexi gibts glaub für rund die Hälfte > > IR-LED ist eine ELIR204-6B von Everlight. Photodiode: ELPD204-6B, auch > von Everlight Habe grad mal gegoogelt und die Angebote waren nicht so breit wie bei anderen Bauteilen. Vielleicht sollte dann eine Alterantiv Diode gesucht werden ? .-)
Tim R. schrieb: > hmm okay... Plexi gibts glaub für rund die Hälfte Dafür überlebt Plexiglas als Tischoberfläche nicht einmal halb so lang. Da gab es bei früheren Diskussionen eine eindeutige Mehrheit zu Gunsten der Echtglas-Lösung, weil Plexiglas zu schnell zerkratzt, etc. Tim R. schrieb: > Habe grad mal gegoogelt und die Angebote waren nicht so breit wie bei > anderen Bauteilen. Vielleicht sollte dann eine Alterantiv Diode gesucht > werden ? .-) Bin ich prinzipiell offen für - sofern die herausgesuchte Lösung zu ähnlichen Konditionen zu erhalten ist und genausogut funktioniert. Ich hatte damals schon eine Weile gesucht, um ein Paar von IR-LED und Photodiode heraus zu suchen, dass Datenblatt technisch zusammen passt, günstig und für jeweils 20 Cent erhältlich ist. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Dafür, dass das Ganze so simpel und günstig ist, funktioniert es > erstaunlich gut. Konnte es weder mit einer Fernbedienung noch mit einem > Halogenstrahler aushebeln. Sehr schöner Test! Einfach und effektiv. Gefällt mir! > Einziges Problem bei diesem Ansatz ist aber > die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne > oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa > 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? Nein. Mit IR wohl gar nicht. Aber normalerweise wird man da wohl selten mit unterschiedlichen Materialien "spielen".
Hat denn jemand zfällig noch paar "handelsübliche" Photodioden rumliegen und kann damit testen? Ich möchte jetzt keine Bestellung für paar Photodioden auslösen, zumal meine Zeit momentan etwas knapp ist. Was mir noch eingefallen ist. Der LED-Treiber wäre doch gar nicht mal so schlecht. Zum einen 3xPWM für die RGB und zusätzlich noch 1x PWM für die IR-LED (welche ich die ganze Zeit gar nicht bedacht habe). Das Problem ist nur denk ich einen passenden Treiber mit am besten 4 PWM Ausgängen zu finden. Meine erste Suche bei Farnell ergab einen Baustein ab 2 Euro mit 5-6 Ausgängen. http://de.farnell.com/texas-instruments/tca6507pw/led-treiber-7ch-i2c-smb-tssop14/dp/1647813 Hat da jemand vielleicht eine bessere Alternative ? :-) edith: am besten sollten sie natürlich 10bit Auflösung haben
:
Bearbeitet durch User
Tim R. schrieb: > Der LED-Treiber wäre doch gar nicht mal so schlecht. Das kommt in erster Linie wohl darauf an für welchen Mikrocontroller wir uns entscheiden. Der ATtiny85 ist aufgrund der fehlenden UART Hardware kaum geeignet, der "nächstgrößere" ATtiny841 bietet wiederum mehr als genug. Aber klar, prinzipiell wären mir echte Treiber auch lieber. Hatte weiter oben ja beispielhaft welche für 50 Cent erwähnt, aber selbst das macht sich bei den vielen Pixeln bemerkbar. Bei 10x20 sind das 100 Euro, keine Ahnung, ob es das Wert ist. Tim R. schrieb: > Zum einen 3xPWM für die RGB und zusätzlich noch 1x PWM für die > IR-LED (welche ich die ganze Zeit gar nicht bedacht habe). 3 Kanäle reichen absolut. Die IR-LED indirekt über einen Treiber zu versorgen macht keinen Sinn. Wir müssen ja wissen wann die LED an bzw. aus ist und unsere ADC Messungen entsprechend synchronisieren. In meinem Versuchsaufbau hab ich das folgendermaßen gelöst: Eine Timer-ISR läuft mit einigen Hundert Hertz (in meinem Fall ~ 500). Diese wird in 4 gleich lange "Phasen" geteilt. In Phase 1 und 3 wird die LED getogglet (ein bzw. ausgeschaltet), in den Phasen 2 und 4 wird eine ADC Konvertierung durchgeführt. Dieser Ansatz garantiert nämlich, dass die ADC Konvertierung erst dann gestartet wird, wenn das Signal "stabil" ist. Die Photodioden-Konstruktion hat nämlich in der aktuellen Form in etwa 100 Mikrosekunden Rise- bzw. Falltime. Dieser Ansatz erfordert nur ganz wenig Overhead und macht keine expliziten Annahmen über das Timing. Der Artikel über Photodioden erwähnt nämlich explizit, dass man mit dem gewählten Aufbau eine Grenzfrequenz von nur einigen Kilohertz hat. Dafür kommt man ganz ohne "teure" zusätzliche Bauteile (z.B. OpAmps) aus. Einen Timer Interrupt mit dieser Frequenz wird man sowieso haben, ansonsten lässt sich eine schnellere ISR ja auch in Software herunter teilen. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Tim R. schrieb: > Hatte > weiter oben ja beispielhaft welche für 50 Cent erwähnt, aber selbst das > macht sich bei den vielen Pixeln bemerkbar. Bei 10x20 sind das 100 Euro, > keine Ahnung, ob es das Wert ist. Ja, das Problem ist verschiedene PWM-Kanäle haben zu wollen. Die kosten meist etwas mehr. Aber wenn jemand einen passenden Baustein für wenig Geld hat, immer her damit ? :-) > > Tim R. schrieb: >> Zum einen 3xPWM für die RGB und zusätzlich noch 1x PWM für die >> IR-LED (welche ich die ganze Zeit gar nicht bedacht habe). > > 3 Kanäle reichen absolut. Die IR-LED indirekt über einen Treiber zu > versorgen macht keinen Sinn. Wir müssen ja wissen wann die LED an bzw. > aus ist und unsere ADC Messungen entsprechend synchronisieren. Das ist schon richtig... oder habe ich gerade einen Denkfehler? Ob ich nun die IR-LED direkt abschalte oder per i2c dem Treiber sage er soll die IR-LED abschalten macht einen minimales delta T denk ich... aber direkt schalten ist schneller und man kann sicher sein das auch wirklich an/aus ist, das stimmt schon
Tim R. schrieb: > Das ist schon richtig... oder habe ich gerade einen Denkfehler? Gut, die Frage kann man erst klären, wenn man ein konkreten Baustein hat. Es ist halt wichtig, dass ein eventueller Treiber wirklich dann anschaltet, wenn wir es ihm sagen, und nicht anfängt selbst herum zu modulieren. Und unabhängig davon ist das Sprechen mit dem Treiber "komplizierter" als das Togglen eines Pins. Bei neueren AVRs lässt sich das ja durchs Schreiben ins PINx Register erledigen. Im Endeffekt sind das aber Detailfragen, die es zu klären gibt, wenn wir uns auf einen konkreten Mikrocontroller festgelegt haben. Funktionieren wird letztendlich beides ;). Mit freundlichen Grüßen, Karol Babioch
Der Attiny841 hat auch genügend Pins die vom Timer angesprochen werden können. Damit könnte man sich auch gleich den kompletten Treiber sparen. Bräuchte nur entsprechende Beschaltung
Bei nur 3 (4) Kanälen komme ich doch noch mit Software-PWM hin, auch mit 10 Bit Auflösung, wieso brauche ich dann einen PWM-Baustein? So reichen mit 3 Transistoren oder Mini-Mosfets um die RGB-LED mit richtig Strom zu versorgen, die kosten 30 Cent. Ach ja, wir haben die 2 Datenprotokolle auch noch, dann muss man auf die Timings ein bisschen aufpassen.
:
Bearbeitet durch User
Die TOCC Pins am Attiny841 sind doch quasi frei wählbar für die PWM-outputs oder nicht? Hab die leider noch nie benutzt, aber das Datenblatt so verstanden. Und somit können doch 2x RX/TX und 4PWM Kanäle genutzt werden bei 8 TOCC Kanälen.
Tim R. schrieb: > Die TOCC Pins am Attiny841 sind doch quasi frei wählbar für die > PWM-outputs oder nicht? Naja, ein paar Restriktionen gibt es schon, siehe Seite 115f. im Datenblatt, aber so eine Flexibilität kenne ich von AVRs noch gar nicht. Habe vorhin mal 10 Stück bestellt, mal sehen, was ich damit anfange ;). Habe mir übrigens auch jeweils ein Exemplar des VCNL4010 und VCNL4020 zugelegt. Auch hier - mehr oder weniger - nur aus Interesse, weil ich gerne wüsste, ob bzw. wie gut das Ganze auch durch Glas hindurch funktioniert. Funktionsreich sind diese Bausteine ja schon (, dafür auch entsprechend teuer. Da müssten wir schon sehr viele sein, damit sich das lohnt. Ab 8000 Stück kosten die dann auch nur noch rund einen Euro ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Da müssten wir schon sehr viele sein, damit sich das Das sind weniger als 8 Tische für 800 Stück.
Conny G. schrieb: > Das sind weniger als 8 Tische für 800 Stück. Die Rede war auch von 8000 ;). Das sind bei 10x20 40 Tische ;). Und selbst dann ist ein Euro noch eine Stange Geld (~ 200 Euro pro Tisch) und würde wohl das teuerste Bauteil darstellen. Der Mikrocontroller z.B. würde bei dieser Größenordnung nur noch 60 Cent kosten. LEDs, Platinen und Hühnerfutter werden zusammen sicherlich auch nochmal ein Euro ausmachen. Damit wären wir halt wieder bei etwa 3 Euro pro Pixel. Und das ist sogar noch optimistisch gerechnet. Wie gesagt, will das erst einmal nur ausprobieren (aus Interesse). Sofern das wirklich zuverlässig funktioniert, hätten wir halt eine Off-the-Shelf Komponente, die gleichzeitig auch eine Entfernungsmessung zulässt und uns neben dem Umgebungslicht auch noch eine extrem hohe Entfernungsauflösung bietet. Bin mir aber nicht sicher, ob das mit 8-10mm diffusen Glas überhaupt klappen kann. Idealerweise gäbe es ja nur einen konstanten Offset, den man in der Software leicht herausrechnen kann. Es kann aber genauso gut sein, dass die interne Elektronik damit nicht zurecht kommt und sich durch die vielen Reflexionen durcheinander bringen lässt. Probieren geht über Studieren ;). Erfahrungen habe ich mit diesen Sensoren noch keine. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Conny G. schrieb: >> Das sind weniger als 8 Tische für 800 Stück. > > Die Rede war auch von 8000 ;). Das sind bei 10x20 40 Tische ;). Und Ui. Zuviel Wein, zuviel geschielt.
Karol Babioch schrieb: > Habe mir übrigens auch jeweils ein Exemplar des VCNL4010 und VCNL4020 > zugelegt. Auch hier - mehr oder weniger - nur aus Interesse, weil ich > gerne wüsste, ob bzw. wie gut das Ganze auch durch Glas hindurch > funktioniert. Toll dieser Tatendrang ! > Funktionsreich sind diese Bausteine ja schon (, dafür auch > entsprechend teuer. Da müssten wir schon sehr viele sein, damit sich das > lohnt. Ab 8000 Stück kosten die dann auch nur noch rund einen Euro ;). Das ist eine ganze Menge. Ich glaube es sollte doch auf günstigere Alternativen zurück gegriffen werden, weil die Stückzahl mit einem Mal nicht erreicht wird
ps: wenn die LED-Treiber zu overpowered/teuer sind, dann seid ihr vom Prinzip wieder beim oben geposteten Schaltplan mit Transistoren oder Ähnlichem. War also gar nicht mal so abwägig würde ich meinen
" .... Bin mir aber nicht sicher, ob das mit 8-10mm diffusen Glas überhaupt klappen kann. Idealerweise gäbe es ja nur einen konstanten Offset, den man in der Software leicht herausrechnen kann. Es kann aber genauso gut sein, dass die interne Elektronik damit nicht zurecht kommt und sich durch die vielen Reflexionen durcheinander bringen lässt. ...." Das eingebaute IC arbeitet linear, soll heissen, dass die Reflexionen ein Offset bilden und das Nutzsignal oben drauf gesetzt wird. Bei 16 Bit Auflösung hat man genug Reserve. Ich habe in einer Anwendungen direkt hinter satiniertem Kunststoff ein Offset von etwa 55000 counts. Der Detektor rauscht digital mit etwa 9-11 counts. Meine Entscheidungsschwelle für ein Objekt oberhalb des Kunststoffes habe ich auf 30 counts gelegt. Das funktioniert einwandfrei.
:
Bearbeitet durch User
So, habe mittlerweile mit einem satiniertes Glasmuster experimentiert. Es ist 10 mm stark und die Lichtdurchlässigkeit beträgt ca. 80 %. Ich habe drei Pixel nebeneinander auf einem Steckbrett aufgebaut und mittels Kartonwänden voneinander getrennt. Für die Steuerung und Auswertung ist jeweils ein ATtiny85 zuständig. Der Code ist im Wesentlichen der selbe wie auch schon bei früheren Experimenten. Aus ästhetischen Gründen lasse ich die LEDs aber in etwa 100 ms "nachglühen". Die Schwellwerte habe ich etwas anpassen müssen (dV beträgt nur noch etwa 250 mV). Ich habe das Ganze wieder in einem kurzen Video festgehalten [1]. Die Lichtverhältnisse bzw. Spiegelungen bitte ich zu entschuldigen. Aufgrund der Urzeit bzw. dem fehlenden Tageslicht war ich gezwungen einen Halogenstrahler im Hintergrund an zu lassen. Ist aber ein Beweis für die Robustheit des Ansatzes :). Nachdem ich nun einige Stunden damit herum gespielt habe, muss ich zu meinem Erstaunen feststellen, dass die Wahl des Glases viel unkritischer ist als zunächst angenommen. Wie man im Video schön sieht, funktioniert es sowohl mit als auch ganz ohne Glas. Habe es auch noch mit einem 4mm starken und satiniertem Glas probiert, auch hier funktioniert es problemlos. Man sieht auch schön wie unempfindlich die einzelnen Pixel gegenüber dem Infrarot-Licht der jeweils anliegenden sind. Insgesamt bin ich mehr als zufrieden und denke, dass das genau der Ansatz ist, den wir verfolgen bzw. umsetzen sollten. Allein schon aus Kostengründen ;). Im Übrigen habe ich mittlerweile auch echte Entfernungssensoren vor mir liegen (VCNL4010 bzw. VCNL4020). Sind allerdings kleiner als zunächst angenommen, mal sehen wie ich da zu einem Versuchsaufbau komme ;). Die sind vermutlich für dieses Projekt, wie schon oben angemerkt, zu teuer - zu mal die Lösung mit IR Photodiode und IR LED gut und robust funktioniert. Da ich aber zum Teil die Intensität der IR LED anpassen musste, um einen vernünftigen Wert zu finden (zu Stark = Reflexionen, zu Schwach = zu unempfindlich), könnte es Sinn machen das aus der Software heraus steuerbar zu machen. Eine PWM halte ich hierfür allerdings nur für bedingt geeignet, weil wir das ja auch vermessen müssen. Was gäbe es hierfür denn für günstige Möglichkeiten? Überhaupt wüsste ich nicht wie man das dann automatisch kalibrieren könnte, wenn man zwei "Stellschrauben" hat, nämlich die von den Photodioden gemessene Differenz sowie die Intensität der IR-LED. Vorschläge? Einziges Manko sind jetzt noch die eigentlichen RGB LEDs. Bei meinen 3 cm und blauen diffusen 5mm LEDs, lässt sich schon noch deutlich erkennen wo sich die LED hinter dem Glas befindet. Idealerweise sollte die so diffus sein, dass die ganze Fläche gleichmäßig ausgeleuchtet ist. Werde wohl noch SMD RGB LEDs probieren, da die einen größeren Abstrahlwinkel haben und ich noch welche vorrätig habe. Übrigens: Für Interessierte finden sich unter [2] Bilder des Aufbaus bzw. eine kleine Fotodokumentation des Projekts ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://youtu.be/HgVx61N-96c [2]: https://plus.google.com/photos/+KarolBabioch/albums/6018967731865862353
:
Bearbeitet durch User
Karol Babioch schrieb: > So, habe mittlerweile mit einem satiniertes Glasmuster experimentiert. Sehr schöner Versuchsaufbau. Ich glaube auch, dass die von Dir getestete Konfiguration der richtige Weg ist. Allerdings halte ich das satinierte Glas immer noch für viel zu klar. SMD-RGB-LEDs mit ihrem großen Abstrahlwinkel halte ich auch für zwingend notwendig. Aber selbst dann werden Einzelheiten (wie Wände aber auch das Innenleben einer jeden Zelle) noch viel zu detailliert abgebildet. Das Glas muss wesentlich diffuser sein. Eventuell wäre eine weiße Farbschicht (wie beim WordClock-Projekt) oder Milchglas eine wesentliche Verbesserung. Dann würde auch jede Zelle viel heller wirken. Fragt sich dann nur, ob die Sensor-Empfindlichkeit dann noch ausreicht...
Karol Babioch schrieb: > So, habe mittlerweile mit einem satiniertes Glasmuster experimentiert. Sehr gute Arbeit, cool! Wenn ich das recht sehe reduziert das Glas die Reichweite von 5-7cm auf 2-3cm? Könnte man da durch die Kalibrierung noch mehr rausholen? Stimme Frank zu, dass Milchglas noch besser wäre. Was fiele uns denn an Entspiegelungsmöglichkeiten für die Unterseite ein? Das könnte Reflexionen und damit den Offset stark verringern.
Karol Babioch schrieb: > Ich habe das Ganze wieder in einem kurzen Video festgehalten [1]. Die > Lichtverhältnisse bzw. Spiegelungen bitte ich zu entschuldigen. sehr schöner Versuch! > Nachdem ich nun einige Stunden damit herum gespielt habe, muss ich zu > meinem Erstaunen feststellen, dass die Wahl des Glases viel unkritischer > ist als zunächst angenommen. Wie man im Video schön sieht, funktioniert > es sowohl mit als auch ganz ohne Glas. Habe es auch noch mit einem 4mm > starken und satiniertem Glas probiert, auch hier funktioniert es > problemlos. Muss mich leider anschließen, dass mir das Glas noch zu "durchsichtig" ist. Gibt es denn eine kostengünstige alterantive wie Milchglas mit guter Lichtdurchlässigkeit?! > Einziges Manko sind jetzt noch die eigentlichen RGB LEDs. Wir hatten anfangs über SuperFlux RGBs nachgedacht. Aber du hast auch gerade mal knapp 2cm tiefe in den Pixeln oder? Wie sieht es aus, wenn dieser Abstand vergrößert wird? Sollte der Abstrahlwinkel automatisch das komplette Glas beleuchten und nicht punktuell.
Frank M. schrieb: > Allerdings halte ich das satinierte Glas immer noch für viel zu klar. Ja, die Frage ist halt immer was es für Alternativen gibt, und wie man da (günstig) heran kommt. Die Lichtdurchlässigkeit der satinierten Gläser scheint immer in etwa 80 Prozent zu betragen, jedenfalls habe ich noch nichts anderes gesehen. Milchglas konnte ich noch keines organisieren, da rührt die Diffusität ja wirklich aus dem Glasinneren her, und nicht nur von der Oberfläche. Frank M. schrieb: > Eventuell wäre eine weiße > Farbschicht (wie beim WordClock-Projekt) Da bringst du mich auf eine Idee. Habe noch eine Diffusorfolie aus dem Wordclock-Projekt (für die Metallfront). Die könnte man unterlegen und dann sogar auf klares Glas setzen. Das Licht wird dabei in jedem Fall genug gestreut, vor allem bei SMD LEDs. Frank M. schrieb: > Fragt sich dann nur, ob die Sensor-Empfindlichkeit dann noch > ausreicht... Probieren geht über studieren: Funktionieren tut das Ganze auch wunderbar, siehe mein neustes Video [1]. Bin mir nur nicht sicher, ob das optisch akzeptabel bzw. ansprechend ist. Alternativ könnten man auch 5x5 cm große Quadrate ausschneiden und in den Pixeln anbringen. Die Glasplatte würde dann auf einer Holzkonstruktion aufliegen. Könnte mir vorstellen, dass das "schön" aussieht. Dazu ist es auch noch die kostengünstigste Alternative. Conny G. schrieb: > Wenn ich das recht sehe reduziert das Glas die Reichweite von 5-7cm auf > 2-3cm? Ja, etwas geringer ist das geworden. Lässt sich ggf. aber durch eine Erhöhung der Intensität der IR LEDs ausgleichen. Muss dafür aber meinen Versuchsaufbau ändern, weil ich beides gerne über die Software und ein entsprechendes Protokoll steuern würde, sodass ich nicht ständig neu flashen und den Aufbau ändern muss. Tim R. schrieb: > Aber du hast auch gerade mal knapp 2cm tiefe in den Pixeln oder? Die Kästchen sind derzeit 3 cm tief. Mit der Diffusorfolie reicht das aber. Bei der Wordclock z.B. ist der Abstand noch geringer und man kann die einzelnen LEDs nicht mehr erkennen. Mit freundlichen Grüßen, Karol Babioch [1]: http://youtu.be/SClKqD01_uU
:
Bearbeitet durch User
Übrigens: Als Vorschlag zu meinem Video wurde mir Folgendes [1] angeboten. Schaut auch sehr vielversprechend aus und basiert scheinbar auf Entfernungssensoren. Das entsprechende Produkt kann man hier [2] kaufen. Dort steht etwas von 300 Dollar, wobei man sich für den Preis nochmal bei denen melden soll? Gibt nicht viele technische Details, aber sofern das wirklich nur 300 Dollar kosten würde, lohnt sich im Prinzip der Selbstbau nicht ;). Mit freundlichen Grüßen, Karol Babioch [1]: https://www.youtube.com/watch?v=R10_4ciWxgI [2]: http://www.farralane.com/store/p-9505-acclaim-lighting-catwalk-panel.aspx
:
Bearbeitet durch User
Karol Babioch schrieb: > Übrigens: Als Vorschlag zu meinem Video wurde mir Folgendes [1] > angeboten. Schaut auch sehr vielversprechend aus und basiert scheinbar > auf Entfernungssensoren. Das entsprechende Produkt kann man hier [2] > kaufen. Dort steht etwas von 300 Dollar, wobei man sich für den Preis > nochmal bei denen melden soll? Gibt nicht viele technische Details, aber > sofern das wirklich nur 300 Dollar kosten würde, lohnt sich im Prinzip > der Selbstbau nicht ;). > > Mit freundlichen Grüßen, > Karol Babioch > > [1]: https://www.youtube.com/watch?v=R10_4ciWxgI > [2]: > http://www.farralane.com/store/p-9505-acclaim-lighting-catwalk-panel.aspx Das ist wirklich sehr gut gemacht! Ich frage mich allerdings, ob man es frei programmieren kann (Spiele, eigene Animationen etc.). Allerdings kostet das 20x20 Panel 300 Dollar. Also selbst wenn man 50% Rabatt bekäme, kommt man für einen 60x60 Tisch bei 3x3 = 9 Panels x 150 Dollar = 1.350 Dollar raus. Für den Preis bekommen wir es auch hin :-) Wir müssten doch folgendes schaffen können: - Holz, Lack, Schrauben, div. Kabel etc. 100-150 Euro - Glas 100 Euro - Pixel, 100 Pixel x 3 Euro = 300 Euro - Steuerung 30 Euro Also um die 500-600 Euro, das ist die Hälfte.
:
Bearbeitet durch User
Conny G. schrieb: > Das ist wirklich sehr gut gemacht! > Ich frage mich allerdings, ob man es frei programmieren kann (Spiele, > eigene Animationen etc.). Da steht etwas von DMX, also eventuell. Ansonsten könnte man das sicherlich modifizieren und nur den physikalischen Aufbau benutzen ;). Also rein theoretisch ... Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > - Pixel, 100 Pixel x 3 Euro = 300 Euro Dann hast du aber "nur" 100 Pixel, also z.B. 10x10. War nicht mal 10x20 bzw. sogar 20x20 der Plan? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> - Pixel, 100 Pixel x 3 Euro = 300 Euro > > Dann hast du aber "nur" 100 Pixel, also z.B. 10x10. War nicht mal 10x20 > bzw. sogar 20x20 der Plan? Ja, ich plante soweit einen kleinen Couchtisch von ungefähr 60x60cm. Vielleicht ein bisschen mehr.
Karol Babioch schrieb: > Probieren geht über studieren: Funktionieren tut das Ganze auch > wunderbar, siehe mein neustes Video [1]. Na also! So muss es sein: Die Fläche muss leuchten und nicht die LED dahinter. Wenn Du jetzt noch SMD-RGB-LEDs benutzt, wird auch noch der runde Kranz verschwinden und alles ist perfekt :-)
Frank M. schrieb: > Wenn Du jetzt noch SMD-RGB-LEDs benutzt, wird auch noch der > runde Kranz verschwinden und alles ist perfekt :-) Ja, aber ist das der Weg, den wir einschlagen wollen? Effektiv ist ja trotz der vielen Beiträge noch nicht wirklich etwas beschlossen worden und irgendwann müssen wir uns mal auf irgendetwas festlegen, um weiter voran zu kommen. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Wenn jeder nur wartet, wird das nie was. Irgendwann muss man auch "machen". Das heisst im konkreten Fall: das bisherige Ergebnis als Teillösung des Projekts ansehen. Damit ist es dann "beschlossen". Anders kommt man nicht weiter. Es wird immer welche geben, die mit einer Teillösung so nicht einverstanden sind oder lieber eine andere Lösung gesehen hätten. Aber ohne Kompromisse kommt man halt nicht weiter... ;-)
Angehängte Dateien:
Karol Babioch schrieb: > Frank M. schrieb: >> Wenn Du jetzt noch SMD-RGB-LEDs benutzt, wird auch noch der >> runde Kranz verschwinden und alles ist perfekt :-) > > Ja, aber ist das der Weg, den wir einschlagen wollen? Effektiv ist ja > trotz der vielen Beiträge noch nicht wirklich etwas beschlossen worden > und irgendwann müssen wir uns mal auf irgendetwas festlegen, um weiter > voran zu kommen. Um meinen Senf dazuzugeben: Ich würde es mir so vorstellen, dass die Zellen komplett ausgeleuchtet sind und man so wenig "LED-Punkt" wie möglich sieht. Ein kleiner dunkler Schatten (paar Millimeter) ist ok, man sollte aber nicht die Unterkonstruktion durch die Glasscheibe sehen können. Also sollte sie stark "milchig" sein, womit satiniert nicht ausreichen würde. Vom optischen Eindruck gefällt es mir wie hier gut: http://youtu.be/MoCnA9lN_54 (Ab 0:50). Nur grössere Felder. Oder wie der Touch Table: https://www.youtube.com/watch?v=DTb0k_P1wlY (bzw. angehängter Screenshot) wobei mir gerade auffällt, dass das Glas gerne noch etwas milchiger sein dürfte als hier. Genau deshalb wäre es mir auch lieber, wenn die Tiefe der Zellen mehr wäre als 3cm, weil sich dann einfacher eine schöne Ausleuchtung ergibt. Also weniger durch die Diffusion des Materials, mehr durch gute Ausleuchtung.
Frank M. schrieb: > Wenn jeder nur wartet, wird das nie was. Irgendwann muss man auch > "machen". > > Das heisst im konkreten Fall: das bisherige Ergebnis als Teillösung des > Projekts ansehen. Damit ist es dann "beschlossen". > > Anders kommt man nicht weiter. Es wird immer welche geben, die mit einer > Teillösung so nicht einverstanden sind oder lieber eine andere Lösung > gesehen hätten. > > Aber ohne Kompromisse kommt man halt nicht weiter... ;-) da gebe ich dir Recht :-) ... und da ich den Thread hier gestartet hatte, nehm ich mir einfach mal die Freiheit und würde beschließen, dass wir den gezeigten Testaufbau als Referenz nehmen. Ich werde z.B. meine IS471 Sensoridee aufgrund des Preises dann auch verwerfen. Die Frage um das richtige Glas muss eben probiert werden. Ich persönlich habe nichts gegen mein Plexiglas wo ich mir ein Muster bestellt hatte, aber wenn die Masse richtiges Glas bevorzugt, dann gehen wir diesen Weg. Nur fehlen mir bis dato Quellen, wo es gutes und günstiges Glas gibt, welches für unseren Gebrauch nutzbar bist :-( ps: warum smd-LEDs? streuen diese besser oder wie muss ich das verstehen. Bin jetzt gerade etwas verwirrt
:
Bearbeitet durch User
Tim R. schrieb: > ps: warum smd-LEDs? streuen diese besser oder wie muss ich das > verstehen. Bin jetzt gerade etwas verwirrt Ja. Diejenigen von der Wordclock haben z.B. einen Abstrahlwinkel von 140°. Da sieht man dann keinerlei Punkte. In Kombination mit Widerständen in der Bauform 0805 lassen sich auch gut per Hand löten und sparen Platz. Selbiges gilt für den ATtiny841, der sich als SOIC auch noch gut per Hand verarbeiten lassen würde. Bei den Photodioden bzw. IR-LEDs scheint es aber nur THT zu geben, insofern lässt sich ein bisschen Handarbeit eh nicht vermeiden. Was das "Beschließen" von Dingen für das Projekt angeht, so sind in meinen Augen zumindest noch folgende Baustellen offen: - Protokoll: Ist denn jeder mit der vorgeschlagenen Daisy Chain zufrieden? Gibt es berechtigte Einwände bzw. Verbesserungsvorschläge? Hat das überhaupt schon jemand probiert (mit ein paar (> 10) Slaves) ;)? Implizites Timing gefällt mir an sich ganz gut, nur ob das hinhaut bei so vielen Teilnehmern? Immerhin kann (in ungünstigen Fällen) auch einiges an Verzögerung entstehen durch die involvierten ISRs. Die UART ISRs z.B. sind auch relativ niedrig priorisiert. Man muss das Zeitfenster zum Übernehmen der Werte also groß genug wählen? Mag sich da jemand mal Gedanken zum Worst Case machen und irgendwelche Formeln bzw. konkrete Werte liefern ;)? - Überhaupt gibt es wenig konkrete Details zur verwendeten Schnittstelle bzw. im Wiki-Artikel ist von MOSI, MISO, usw. die Rede. SPI so wie es im Lehrbuch steht wird aber nicht funktionieren, weil wir mit einer synchronen CLK Leitung nicht hinkommen werden. Alternativ gibt es den o.g. UART Ring - entweder in einfacher oder zweifacher Ausführung. Letzteres fände ich "cooler", weil noch nirgends gesehen und potentiell doppelt so schnell. Andererseits macht es die Timings (zwei gegeneinander agierende ISRs) ggf. noch mehr "kaputt". - Die Frage zur Steuerung der Intensität der IR-LED ist auch noch nicht geklärt: Ich würde das schon für sinnvoll halten, allein schon weil IR LEDs wohl altern und mit der Zeit schwächer werden. Ggf. müsste man hier also nachjustieren. Das ist derzeit mein größtes Problem, weil der typische PWM Ansatz halt nicht funktionieren wird. Eine digitales Potentiometer bzw. eine programmierbare Konstantstromquelle kostet (merklich) Geld. - Maße: Ich halte eine Pixelgröße von 5x5 cm für einen guten Kompromiss. Würde die Platinen allerdings etwas kleiner machen, z.B. 48mm x 48mm, um genug Platz für eine Rahmenkonstruktion zu haben. - Spannungsversorgung: Sollen die Pixel jeweils selbst einen Spannungsregler an Board haben? Wenn wir einmal von 20 mA pro Farbe sowie 40 mA für die IR LED ausgehen, dann kommt da schon ordentlich was zusammen (> 100 mA pro Pixel). - Verkabelung: Weiter oben wurde z.B. der Vorschlag gemacht zumindest die Stromversorgung mittels "Schienen" zu gewährleisten. Die einzelnen Pixel-Platinen werden dann nur noch "aufgesteckt". Hat jemand Erfahrungen mit solchen Systemen? Stichwörter zum Suchen? Preise? Infos zur Zuverlässigkeit? Softwaretechnisch fehlt auch noch einiges: - Protokoll: Eine genaue Spezifikation + Implementierung - Bootloader: Ich würde gerne Pixel einzeln bzw. per Broadcast flashen können, um Updates bequem einzuspielen. Der ATtiny841 hat leider keinen dedizierten Bootloader-Support, d.h. wir müssen das per Software erledigen und es dahingehend absichern, dass man den Bootloader nicht kaputt machen kann (Stromausfall & Co.). 100+ Module per Hand neu zu flashen macht sicherlich keinen Spaß. Eine mögliche Inspirationsquelle: [1]. Was für Möglichkeiten der Verifizierung gibt es? Wenn wir das alles per Daisy-Chain hin und her schicken, dann könnte es langsam werden. "Interessant" wäre es, wenn sich die Pixel untereinander Updates zuspielen und überprüfen könnten. Ist aber vermutlich zu kompliziert, oder? Es gibt also eine Menge zu tun: Und selbst wenn all das steht, dann haben wir erst einmal nur "blöde" Pixel. Eine Steuerung will auch noch entworfen und programmiert werden ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://jtxp.org/tech/tinysafeboot_en.htm
:
Bearbeitet durch User
Karol Babioch schrieb: > Ja. Diejenigen von der Wordclock haben z.B. einen Abstrahlwinkel von > 140°. Ah super, ich hatte SMD-LEDs bisher nie als so wichtiges Leuchtmittel genutzt, eher für Hinweisleuchten oder was auch immer :-) > Was das "Beschließen" von Dingen für das Projekt angeht, so sind in > meinen Augen zumindest noch folgende Baustellen offen: Das ist klar... aber irgendwann müssen wir ja ausm Pott kommen denke ich :-) > - Protokoll: Ist denn jeder mit der vorgeschlagenen Daisy Chain > zufrieden? Gibt es berechtigte Einwände bzw. Verbesserungsvorschläge? > Hat das überhaupt schon jemand probiert (mit ein paar (> 10) Slaves) ;)? Bisher erschien mir die Variante als schnellste,komfortabelste Lösung vor. Nein es ist bisher bei reiner Theorie geblieben, soweit ich weiß. Das es getestet werden muss ist klar, aber ich denke der Ansatz ist leicht zu verstehen und sollte funktionieren. Wie schnell das ganze nun letztendlich wirklich ist, ist die intressanteste Frage denk ich. > Implizites Timing gefällt mir an sich ganz gut, nur ob das hinhaut bei > so vielen Teilnehmern? Immerhin kann (in ungünstigen Fällen) auch > einiges an Verzögerung entstehen durch die involvierten ISRs. Naja, die UART haben doch als einzige Komponente neben dem ADC einen Interrupt nötig oder?! > Die UART > ISRs z.B. sind auch relativ niedrig priorisiert. Man muss das > Zeitfenster zum Übernehmen der Werte also groß genug wählen? Mag sich da > jemand mal Gedanken zum Worst Case machen und irgendwelche Formeln bzw. > konkrete Werte liefern ;)? Weiter oben sind dazu schon ein paar Berechnungen gelaufen. Ich muss jetzt leider passen wie weit das genau ausgeführt wurde und der Thread hier wird ja langsam auch immer größer :-) > - Überhaupt gibt es wenig konkrete Details zur verwendeten Schnittstelle > bzw. im Wiki-Artikel ist von MOSI, MISO, usw. die Rede. Der Wiki Artikel ist noch ganz am Anfang. Conny war so nett ein paar Sachen dort aufzuschreiben. > SPI so wie es im > Lehrbuch steht wird aber nicht funktionieren, weil wir mit einer > synchronen CLK Leitung nicht hinkommen werden. Alternativ gibt es den > o.g. UART Ring - entweder in einfacher oder zweifacher Ausführung. Die Überlegungen gingen in Richtung 2x UART für jede Richtung (zwischen den Pixeln). Hier kann man mit der Topologie etwas spielen. Lässt man alle kaskadieren? Denke ich ist zu Zeitraubend. Lässt man die einzelnen Reihen/Spalten jeweils vom Master bedienen? Oder Platziert man den Master in der Mitte und lässt quasi 4 große Abschnitte des Tisches bedienen?! Ich denke mittig oder gleiche die einzelnen Reihen jeweils ansprechen wäre am günstigsten. Ich habe wegen dem Master gerade noch überlegt, ob wir eine Alternative finden könnten. Der Beagle Bone Black hat power und viele I/Os das ist fakt. Jedoch ist momentan (und ich denke auch in der Zukunft) das Teil schwer zu bekommen. Das heißt gibt es etwas ähnliches was leicht lieferbar ist? > - Die Frage zur Steuerung der Intensität der IR-LED ist auch noch nicht > geklärt: Ich würde das schon für sinnvoll halten, allein schon weil IR > LEDs wohl altern und mit der Zeit schwächer werden. Ggf. müsste man hier > also nachjustieren. Das ist derzeit mein größtes Problem, weil der > typische PWM Ansatz halt nicht funktionieren wird. Eine digitales > Potentiometer bzw. eine programmierbare Konstantstromquelle kostet > (merklich) Geld. Der Gedankenansatz ist schon sehr gut, nur denke ich sprengt das irgendwann auch etwas den Rahmen. Und die Alterung der LED ist denke ich vernässligbar, habe aber dazu ehrlich gesagt nicht das Wissen! Wir sollten aufpassen nicht zu doll "auszuholen" damit dieses Projekt auch noch realisierbar bleibt. Oder nicht?! > - Maße: Ich halte eine Pixelgröße von 5x5 cm für einen guten Kompromiss. > Würde die Platinen allerdings etwas kleiner machen, z.B. 48mm x 48mm, um > genug Platz für eine Rahmenkonstruktion zu haben. ich denke mit 5x5cm kann jeder gut leben. Zur Not kann man jeder seine eigene Größe realisieren. Die Platinen würde ich sogar noch etwas kleiner dimensionieren weil 4mm Wandstärke etwas knapp werden könnte. Die Pixelwände sollen schießlich auch die Glasplatte halten und was darauf steht. Ich posaune einfach mal 45x45mm raus :-) > - Spannungsversorgung: Sollen die Pixel jeweils selbst einen > Spannungsregler an Board haben? Wenn wir einmal von 20 mA pro Farbe > sowie 40 mA für die IR LED ausgehen, dann kommt da schon ordentlich was > zusammen (> 100 mA pro Pixel). > - Verkabelung: Weiter oben wurde z.B. der Vorschlag gemacht zumindest > die Stromversorgung mittels "Schienen" zu gewährleisten. Die einzelnen > Pixel-Platinen werden dann nur noch "aufgesteckt". Hat jemand > Erfahrungen mit solchen Systemen? Stichwörter zum Suchen? Preise? Infos > zur Zuverlässigkeit? Also stecken ist denke ich nicht so die gute Idee. Ich würde Schrauben verwenden damit die Pixel wirklich fest sind und nix verrutscht. Das würde evtl. auch eine neue Kalibrierung mit sich ziehen etc. Aber ich denke die Idee mit den Schienen war schon sehr gut, hab da leider nur auch keine Erfahrung mit. > Softwaretechnisch fehlt auch noch einiges: > > - Protokoll: Eine genaue Spezifikation + Implementierung > > - Bootloader: Ich würde gerne Pixel einzeln bzw. per Broadcast flashen > können, um Updates bequem einzuspielen. Der ATtiny841 hat leider keinen > dedizierten Bootloader-Support, d.h. wir müssen das per Software > erledigen und es dahingehend absichern, dass man den Bootloader nicht > kaputt machen kann (Stromausfall & Co.). 100+ Module per Hand neu zu > flashen macht sicherlich keinen Spaß. Eine mögliche Inspirationsquelle: > [1]. Was für Möglichkeiten der Verifizierung gibt es? Wenn wir das alles > per Daisy-Chain hin und her schicken, dann könnte es langsam werden. > "Interessant" wäre es, wenn sich die Pixel untereinander Updates > zuspielen und überprüfen könnten. Ist aber vermutlich zu kompliziert, > oder? > > Es gibt also eine Menge zu tun: Und selbst wenn all das steht, dann > haben wir erst einmal nur "blöde" Pixel. Eine Steuerung will auch noch > entworfen und programmiert werden ;). Um die Software auf dem Master mache ich mir eigtl. am wenigsten Sorgen. Jeder kann dann etwas zum Häppchen dazu steuern :-)
...vielleicht kannst Du da was mit anfangen: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html
Michael D. schrieb: > ...vielleicht kannst Du da was mit anfangen: > http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html Daran orientieren wir uns schon. Nur wollen wir das Ganze modularer und "besser" (TM) hinbekommen ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > - Überhaupt gibt es wenig konkrete Details zur verwendeten Schnittstelle > bzw. im Wiki-Artikel ist von MOSI, MISO, usw. die Rede. SPI so wie es im > Lehrbuch steht wird aber nicht funktionieren, weil wir mit einer > synchronen CLK Leitung nicht hinkommen werden. Ich habe einfach mal einen Wiki-Artikel angelegt und die ersten Gedanken reingeworfen, d.h. ausgereift ist das noch gar nicht. Muss man noch sehen, ob man das mit USI oder Bitbanging oder USART ... am besten macht. > - Maße: Ich halte eine Pixelgröße von 5x5 cm für einen guten Kompromiss. > Würde die Platinen allerdings etwas kleiner machen, z.B. 48mm x 48mm, um > genug Platz für eine Rahmenkonstruktion zu haben. Mir wäre eigentlich 6x6 lieber (60cm-Tisch = 10 Pixel), aber ich könnte mit 5cm auch arbeiten, sind halt dann 12 Pixel für 60cm. Bisschen kleiner finde ich gut, stimme Tim zu, dass man das ruhig grosszügig machen könnte, also 45mm. Auch wenn ich meine, dass 4mm Trennwand voll ausreichen - man hat ja ein ganzes "Wabenkonstrukt" um die Glasplatte zu halten. > - Verkabelung: Weiter oben wurde z.B. der Vorschlag gemacht zumindest > die Stromversorgung mittels "Schienen" zu gewährleisten. Die einzelnen > Pixel-Platinen werden dann nur noch "aufgesteckt". Hat jemand > Erfahrungen mit solchen Systemen? Stichwörter zum Suchen? Preise? Infos > zur Zuverlässigkeit? Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze Breite und darauf per Einstechen oder Aufdrücken die Pixel zu kontaktieren. Elegantere Lösungen willkommen. Die Grundidee war sich das Anlöten von Kabel an den Pixeln (hunderte Lötstellen) - oder noch aufwändiger: Stecker & Buchse für jeden Pixel und das vielleicht noch 2x -zu ersparen. > - Bootloader: Ich würde gerne Pixel einzeln bzw. per Broadcast flashen > können, um Updates bequem einzuspielen. Der ATtiny841 hat leider keinen > dedizierten Bootloader-Support, d.h. wir müssen das per Software > erledigen und es dahingehend absichern, dass man den Bootloader nicht > kaputt machen kann (Stromausfall & Co.). 100+ Module per Hand neu zu > flashen macht sicherlich keinen Spaß. Eine mögliche Inspirationsquelle: > [1]. Was für Möglichkeiten der Verifizierung gibt es? Wenn wir das alles > per Daisy-Chain hin und her schicken, dann könnte es langsam werden. > "Interessant" wäre es, wenn sich die Pixel untereinander Updates > zuspielen und überprüfen könnten. Ist aber vermutlich zu kompliziert, > oder? Bootloader fände ich auch wichtig, anfangs muss man eine Menge an der Software arbeiten, dann wird man einfach nur wahnsinnig immer 100x zu flashen. (30 Sekunden x 100 = 3000 Sekunden = 1 Stunde).
Karol Babioch schrieb: > Michael D. schrieb: >> ...vielleicht kannst Du da was mit anfangen: >> http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html > > Daran orientieren wir uns schon. Nur wollen wir das Ganze modularer und > "besser" (TM) hinbekommen ;). > > Mit freundlichen Grüßen, > Karol Babioch Ja, weil das: http://www.it-gecko.de/wp-content/uploads/2012/04/CIMG0533.jpg http://www.it-gecko.de/wp-content/uploads/2012/04/CIMG0590.jpg total irre ist :-) Größten Respekt vor der geduldigen Leistung & dem Aufwand, aber ich hab da keine Lust drauf :-)
:
Bearbeitet durch User
Conny G. schrieb: > Größten Respekt vor der geduldigen Leistung & dem Aufwand, aber ich hab > da keine Lust drauf :-) ich schließe mich an. wo die riesen platine das erstmal gesehen hatte, dachte ich wort wörtlich what the f*ck :-D
Tim R. schrieb: > Wie schnell das ganze nun > letztendlich wirklich ist, ist die intressanteste Frage denk ich. Ja ;). Tim R. schrieb: > Der Beagle Bone Black > hat power und viele I/Os das ist fakt. Jedoch ist momentan (und ich > denke auch in der Zukunft) das Teil schwer zu bekommen. Das heißt gibt > es etwas ähnliches was leicht lieferbar ist? Bei uns dauert das sicherlich noch. Vielleicht ist es bis dahin wieder etwas besser lieferbar. Ansonsten müssten wir uns in der Tat nach Alternativen umsehen. Tim R. schrieb: > Der Gedankenansatz ist schon sehr gut, nur denke ich sprengt das > irgendwann auch etwas den Rahmen. Und die Alterung der LED ist denke ich > vernässligbar, habe aber dazu ehrlich gesagt nicht das Wissen! Wir > sollten aufpassen nicht zu doll "auszuholen" damit dieses Projekt auch > noch realisierbar bleibt. Oder nicht?! Prinzipiell hast du natürlich recht. Diesen Aspekt würde ich allerdings nicht unterschätzen. Zum Einen habe ich schon von mehreren Seiten gehört, dass der Effekt tatsächlich auftritt und zum Anderen wären wir damit so flexibel wie es nur geht in Bezug auf das verwendete Glas bzw. Plastik. Die Module sollten dann mit allem zurecht kommen, dass Infrarotlicht passieren lässt. Habe mittlerweile auch schon Treiber für 20 Cent gesehen, wobei die nicht genug Strom geliefert haben. Ich suche weiter ... ;). Tim R. schrieb: > Aber ich denke die Idee mit den Schienen war schon sehr gut, hab da > leider nur auch keine Erfahrung mit. Prinzipiell gefällt mir die Idee natürlich auch. Aber keine Ahnung inwiefern das in Sachen Platinendesign zu berücksichtigen ist. Tim R. schrieb: > Um die Software auf dem Master mache ich mir eigtl. am wenigsten Sorgen. > Jeder kann dann etwas zum Häppchen dazu steuern :-) Klar, ist das "kleinste" Problem, aber so "klein" ist es dann auch wieder nicht ;). Vor allem wenn man es modular und erweiterbar gestalten will. Tim R. schrieb: > Naja, die UART haben doch als einzige Komponente neben dem ADC einen > Interrupt nötig oder?! Sowie die Timer ISR, welche die ADC Konvertierungen startet. Alternativ könnte man die ADC Konvertierungen auch in einem Free-Running-Modus laufen lassen und dort den Pin togglen. Viel Overhead ist das Alles natürlich nicht, aber es addiert sich im Worst-Case halt zusammen. Und wenn der Vorletzte Pixel dann erst einmal nichts mehr hört, weil die Pixel davor andere Dinge zu tun hatten, dann wird er bei einem impliziten Timing davon ausgehen, dass alles übertragen worden ist und die Werte übernehmen. Der letzte Pixel bliebe dann leer aus. Man muss das Übernahme-Fenster also groß genug wählen, um auch im Worst-Case auf der sicheren Seite zu sein. Und das hat indirekt wieder Einfluss auf die maximale Refresh-Rate. Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas > wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze > Breite und darauf per Einstechen oder Aufdrücken die Pixel zu > kontaktieren. Die Idee finde ich natürlich gut, nur ob das zuverlässig funktioniert? Will bei einer so teuren Konstruktion nur ungern mit Wackelkontakten im Produktivbetrieb zu tun haben. Und das Verkabelungsproblem löst es ja auch noch nicht ganz, weil wir zumindest die Datenleitungen wirklich als Kabel ausführen müssen ;). Hast du so etwas denn schon einmal ausprobiert? Die Pixel kann man ja als doppelseite Platinen auslegen, vielleicht reichen großzügige Kontaktflächen ja bereits? Ansonsten: Womit willst du "Einstechen"? Gibt es hierfür fertige Bauteile? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas >> wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze >> Breite und darauf per Einstechen oder Aufdrücken die Pixel zu >> kontaktieren. > > Die Idee finde ich natürlich gut, nur ob das zuverlässig funktioniert? > Will bei einer so teuren Konstruktion nur ungern mit Wackelkontakten im > Produktivbetrieb zu tun haben. Und das Verkabelungsproblem löst es ja > auch noch nicht ganz, weil wir zumindest die Datenleitungen wirklich als > Kabel ausführen müssen ;). Nein, Wackelkontakt will ich auch nicht. Ich spinne mal rum...: Masse, VCC und Daten als Schraubenloch auf die Platine, wo das Kupfer bis ran geht. Dann Schraube mit Beilagscheibe durch, sodass genügend Kontakt ist. Die Schraube geht durch die Bodenplatte. Auf der anderen Seite, also Unterseite der Bodenplatte haben wir dann einen Kupferstreifen, eine Aluschiene, was weiss ich, was gut leitet. Da werden dann an entsprechender Stelle Löcher gebohrt, die Schraube von oben durchgesteckt, Mutter drauf. Wobei dann VCC/Masse immer komplette Breite durchgingen, das Datensignal immer nur von Platine zu Platine, man könnte auch einfach solche Minikabelchen für die Daten machen: http://img.directindustry.de/images_di/photo-g/kabelschuhe-rechteckigen-zungen-isoliert-19655-3183179.jpg Und die an die entsprechenden Schrauben per Mutter befestigen. Diese Kabelschuhkabelchen zu krimpen wären einfache Handgriffe, Mutter drauf ist auch nicht aufwändig. Und damit wäre auch jede Platine schön überdimensioniert mit 4 Schrauben angeschraubt :-) (VCC, GND, Data In, Data Out)
Conny G. schrieb: > Ich spinne mal rum...: Bin da für alles offen, würde es nur gerne ausprobiert haben. Nicht, dass wir dann hunderte Platinen haben, und es nicht klappt wie geplant ;). Was die Datensignale angeht z.B. kann ich mir nicht vorstellen, dass das so hinhaut. Signalintegritätstechnisch sind breite Kupferstreifen sicherlich nicht perfekt. Für VCC/GND hingegen könnte ich mir das gut vorstellen. Mit freundlichen Grüßen, Karol Babioch
für die datenleitung würde ich einfache jumperkabel vorschlagen.. kriegt man überall günstig und man brauch nur jeweils die stiftleisten bedienen. ist dann aber leider nicht so fest wie eine verschraubung, aber brauch man das wirklich? solange die platine fest sitzt sollte das denk ich machbar sein
Angehängte Dateien:
-
Baugruppe1.jpg
230 KB -
Baugruppe2.jpg
360 KB
Ich habe mal ein paar Maße zusammengefasst die ich hier so gelesen habe. Displaymaße: 600x600mm Pixelgröße: 50x50mm Innere Displayhöhe: wurde mehr als 30mm gewünscht, habe 55mm festgelegt Glasplatte: 5mm Dick Rahem: Komplette aus Holz und einfach zuzuschneiden Ist alles so ausgelegt, dass fast alles im Baumarkt zugeschnitten werden kann. Nur die Einkerbungen der inneren Platten müssen mit einer Stichsäge eingeschnitten werden, Sägeblattbreite = Plattendicke. Der Rahmen kann je nach Geschmack geschraubt oder gedübelt werden. Die Galsplatte kann man einfach von oben einlegen und später mit einem Pümpel wieder rausholen xD. Die Platinengröße sollte dann 48x48mm nicht überschreiten, wie schon erwähnt. Karol Babioch schrieb: > Conny G. schrieb: >> Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas >> wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze >> Breite und darauf per Einstechen oder Aufdrücken die Pixel zu >> kontaktieren. > > Die Idee finde ich natürlich gut, nur ob das zuverlässig funktioniert? > Will bei einer so teuren Konstruktion nur ungern mit Wackelkontakten im > Produktivbetrieb zu tun haben. Und das Verkabelungsproblem löst es ja > auch noch nicht ganz, weil wir zumindest die Datenleitungen wirklich als > Kabel ausführen müssen ;). Die Idee finde ich garnicht so schlecht, jedenfalls für die Stromversorgung. Man könnte die Schienen einkleben (zur Isolation lakieren oder ähnliches) und die Platinen direkt auf die Schienen schrauben. Wegen den Kontakten kann man ja einfach Kontaktpaste draufschmieren. http://www.conrad.de/ce/de/product/814411/?insert_kz=VQ&hk=SEM&WT.srch=1&WT.mc_id=google_pla&gclid=CJ_n2JHF1L4CFQQOwwodRLoAOA Ich glaube allerdings, dass es an dem Kostenfaktor scheitern wird. Man würde für den Tisch oben ca. 14,4m Kupfer benötigen. Werden so 37,30€ nach Ebay für ein 2x300x200mm Blech, daraus dann 4mm breite Streifen schalgen und alles mit Gewinden versehen. Dazu noch die Paste, Schrauben und die Kabel um die Enden zu verbinden und schon hat sich das leider erledigt, wenn ich mich nicht verrechnet habe xD.
Tim R. schrieb: > für die datenleitung würde ich einfache jumperkabel vorschlagen.. kriegt > man überall günstig und man brauch nur jeweils die stiftleisten > bedienen. ist dann aber leider nicht so fest wie eine verschraubung, > aber brauch man das wirklich? solange die platine fest sitzt sollte das > denk ich machbar sein Auch eine gute Idee! Einfach ein 5mm Loch (oder ein bisschen mehr) in der Grundplatte, 1 Pin Male Header nach unten, dann kann man kurze Kabelchen dieser Sorte http://www.ebay.de/itm/like/281336255345?lpid=106&_configDebug=ViewItemDictionary.ENABLE_PAYMENTS_IN_HLP:true&hlpht=true&ops=true&viphx=1 von unten anstecken.
Maik Pfeiffer schrieb: > Ich habe mal ein paar Maße zusammengefasst die ich hier so gelesen habe. Das Modell schaut super aus. Darf man denn fragen in welcher Software du das designed bzw. gerendert hast? Ansonsten hast du ja so gut wie alles bedacht und übernommen. Deine Sorgen bezüglich der Kupferstreifen teile ich. Kabel werden wohl doch günstiger sein. Mit Stiftleisten und Jumperkabeln sollte das schon auch hinhauen. Bei den Trennwänden dachte ich ggf. an Lasercutten. Das ist durch die vielen 3D-Drucker auch in eine bezahlbare Region gerutscht und bietet den Vorteil, dass es wirklich passgenau ist. Was die Holz-Konstruktion angeht: Soll es eigentlich einen doppelten "Boden" geben? Das würde sich ja anbieten, um die vielen Kabel und die Steuerung zu verstecken, oder? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > bedacht und übernommen. Deine Sorgen bezüglich der Kupferstreifen teile > ich. Kabel werden wohl doch günstiger sein. Mit Stiftleisten und > Jumperkabeln sollte das schon auch hinhauen. Würde man es mit Kabeln verbinden, wäre die Frage, ob man von Platine zu Platine geht oder vom Rand an jede Platine der Reihe oder so ähnlich. Und dann ein dickes Kabel einmal am Rand lang. Eleganter wäre wenn dann von Platine zu Platine, dann hätte man immer so ein 3er Jumper Pack. Dann ist die Frage, wieviel Strom durch das erste Kabelchen gehen muss, wenn die ganze Reihe dranhängt. Wir hatten vorher 100mA pro Platine - 40mA IR, 3x20mA RGB und uC plus evtl. Spannungsregler, dann könnten wir bei 120mA rauskommen. 60er Tisch, 12 Platinen in einer Reihe, 12x 120mA = knapp 1,5A für das erste Kabel. Leider steht für die kleinen Jumperkabelchen oben kein Querschnitt. Die werden aber sicher ziemlich dünn sein, also AWG28 oder so. Dann sind 1,5A schon ein bisschen viel, könnte aber gerade noch so gehen. Bin aber kein Fan von "gerade noch"... Auf jeden Fall geht nur maximal eine 10er / 12er Reihe in Serie, die Reihen müsste man mit etwas dickerem verbinden. Da könnte man vielleicht für die erste Reihe sowas mit Schiene, Gewindeschrauben und Kabelschuhen machen. Damit liesse sich großer Kabelsalat von Netzteil zu jeder Reihe vermeiden. Damit haben wir übrigens auch zum ersten Mal den gesamten Strombedarf des Tisches: für 12x12 sind es dann 17 Ampere. Ordentlich! :-)
Conny G. schrieb: > Auch eine gute Idee! > Einfach ein 5mm Loch (oder ein bisschen mehr) in der Grundplatte, 1 Pin > Male Header nach unten, dann kann man kurze Kabelchen dieser Sorte > > Ebay-Artikel Nr. 281336255345 > > von unten anstecken. da ist amazon komischerweise ja um welten günstiger ;-P http://www.amazon.de/hochqualitative-Jumperkabel-weiblich-m%C3%A4nnlich-female/dp/B00K9QY13M/ref=sr_1_1?ie=UTF8&qid=1401486876&sr=8-1&keywords=jumperkabel+10cm
Conny G. schrieb: > Wir hatten vorher 100mA pro Platine - 40mA IR, 3x20mA RGB und uC plus > evtl. Spannungsregler, dann könnten wir bei 120mA rauskommen. > 60er Tisch, 12 Platinen in einer Reihe, 12x 120mA = knapp 1,5A für das > erste Kabel. > Leider steht für die kleinen Jumperkabelchen oben kein Querschnitt. > Die werden aber sicher ziemlich dünn sein, also AWG28 oder so. > Dann sind 1,5A schon ein bisschen viel, könnte aber gerade noch so > gehen. > Bin aber kein Fan von "gerade noch"... Hier muss ich mal kurz einlenken. Die Idee mit den Jumperkabeln war auf die Daten bezogen! Sprich die 2xUARTs von jedem Pixel zum nachfolgenden. Für die Spannungsversorgung würde ich auch solche Schienen bevorzugen. Die Spannungsversorgung über die Jumper laufen lassen, das wird nicht gut gehen denke ich... da wird ja doch schon ein wenig mehr fließen als 50mA > Damit haben wir übrigens auch zum ersten Mal den gesamten Strombedarf > des Tisches: für 12x12 sind es dann 17 Ampere. Ordentlich! :-) Ist das nicht etwas hoch?? Für einen LED-Tisch?? Ich meine da reicht nicht mal mehr eine standard 16A Haussicherung?? :-/ Ich sehe gerade ein k.o. Kriterium im Landeanflug...
:
Bearbeitet durch User
Karol Babioch schrieb: >Das Modell schaut super aus. Darf man denn fragen in welcher Software du >das designed bzw. gerendert hast? Ich benutze Autodesk Inventor. Hatte mal die Möglichkeit die Software günstig als Schullizens zu kaufen. Die Bilder konnte ich direkt aus der Ansicht exportieren. Karol Babioch schrieb: >Bei den Trennwänden dachte ich ggf. an Lasercutten. Das ist durch die >vielen 3D-Drucker auch in eine bezahlbare Region gerutscht und bietet >den Vorteil, dass es wirklich passgenau ist. Daran hatte ich jetzt garnicht gedacht. Habe die Platten extra so ausgewählt, dass ein Schnitt mit der Stichsäge ausreicht. Nach den Motto "make it as easy as possible". Und ich glaube wer so ein Tisch bauen möchte sollte wenigstens eine Stichsäge haben xD Karol Babioch schrieb: >Was die Holz-Konstruktion angeht: Soll es eigentlich einen doppelten >"Boden" geben? Das würde sich ja anbieten, um die vielen Kabel und die >Steuerung zu verstecken, oder? Den brauchen wir glaub ich garnicht. Wenn es eine Masterplatine in einem Pixel gibt die alle anderen per Bus ansteuert, können wir einfach die Kabel zwischen unterer Platte und den Trennwänden durchmogeln. Damit würde nur noch die Stromzuführ über ein externes Netzteil an einem Bein entlang laufen. Habe davon nicht so die Ahnung xD
Tim R. schrieb: > Conny G. schrieb: >> Wir hatten vorher 100mA pro Platine - 40mA IR, 3x20mA RGB und uC plus >> evtl. Spannungsregler, dann könnten wir bei 120mA rauskommen. >> 60er Tisch, 12 Platinen in einer Reihe, 12x 120mA = knapp 1,5A für das >> erste Kabel. >> Leider steht für die kleinen Jumperkabelchen oben kein Querschnitt. >> Die werden aber sicher ziemlich dünn sein, also AWG28 oder so. >> Dann sind 1,5A schon ein bisschen viel, könnte aber gerade noch so >> gehen. >> Bin aber kein Fan von "gerade noch"... > > Hier muss ich mal kurz einlenken. Die Idee mit den Jumperkabeln war auf > die Daten bezogen! Sprich die 2xUARTs von jedem Pixel zum nachfolgenden. > Für die Spannungsversorgung würde ich auch solche Schienen bevorzugen. > Die Spannungsversorgung über die Jumper laufen lassen, das wird nicht > gut gehen denke ich... da wird ja doch schon ein wenig mehr fließen als > 50mA Über ein Jumperkabelchen ein paar Hundert mA ist ok, aber bei 1-1,5A Dauerstrom fühle ich mich eigentlich nicht mehr so wohl. Am Ende geht's um den Widerstand des Kabels (= Leistungsverlust, Spannungsabfall) und Erwärmung. Das scheint wohl theoretisch nach kurzem Googeln schon noch ok, aber ist schon die Grenze. Ich würde auch eine Schienen oder Kupferstreifen-Lösung bevorzugen: - superordentlich, keine Kabel - keine Einzelkabelchen konfektionieren, löten, stecken, crimpen - bei einer cleveren Lösung geht es zusammen mit der Montage der Platinen (mit 2 Schrauben festschrauben) - kein Problem mit dem Querschnitt bzgl. Strom Ich fände ein 3er Jumperkabel von Platine zu Platine schon auch noch ok und einigermassen elegant. Aber der Querschnitt ist schon ziemlich windig. >> Damit haben wir übrigens auch zum ersten Mal den gesamten Strombedarf >> des Tisches: für 12x12 sind es dann 17 Ampere. Ordentlich! :-) > > Ist das nicht etwas hoch?? Für einen LED-Tisch?? Ich meine da reicht > nicht mal mehr eine standard 16A Haussicherung?? :-/ Ich sehe gerade ein > k.o. Kriterium im Landeanflug... Auf der 230V-Seite sind das aber nur 0,4A plus Trafo-/Netzteilverluste. :-) Wir haben ja z.B. 5V in der Schaltung, also 5V x 17A = 85W. Also soviel in etwa ein Laptop an Netzteil braucht.
Mir geht da grad was durch den Kopf.
Wenn man für die Verbindung der Pixel auch eine Platine nähme.
Oder einen 10-20mm breiten Platinenstreifen.
Auf denen sitzen dann 3er Female Headers im Abstand von 50mm =
Pixelbreite.
Dann könnte man alle 5cm durch die Grundplatte ein passendes Loch bohren
in das genau der Female Header reinpasst und von oben die Pixel
aufstecken.
Also so:
Pixelplatine 3er Male-Header
=====================+++====
------------------+ ||| +--------------
Grundplatte | HHH |
------------------+ HHH +--------------
====+++=====
Kontaktstreifenplatine mit 3er Female-Header
lach... ich bin zu müde und sollte ins bett habe ich gerade gemerkt! :-D also halte ich die bevorzugten lösungen fest: -spannungsversorgung über 2 schienen (5V,GND) -datenleitungen jeweils 3 jumperkabel TX,GND,RX
Für die Stromversorgung reichen auch Streifen aus 0.1mm dicker Kupferfolie. In einer Richtung kommt unter jede Trennwand ein 25 oder 30mm breiter Streifen. Geradzahlige Streifen werden an GND angeschlossen, ungeradzahlige Streifen an VCC. Die Module werden abwechselnd reihenweise ¨linksrum¨ bzw. ¨rechtsrum¨ eingebaut. Der Kontakt zwischen Platine und Kupferstreifen wird durch kurze Kupferröhrchen hergestellt, evtl. gibt es z.B. Kupferhohlnieten mit geeignetem Innendurchmesser für die Verschraubung der Platine and die Grundplatte.
Teils von Conny G.: xD
| | Trennwand
| |
| |
| |
| |
Pixelplatine | | P.p.
==================++= +--+ =++================
=++==========++= <- Verbinder-Platine
-----------------|__|--------|__|---------------
Grundplatte
------------------------------------------------
Wir brauchen ja nicht mal durch die Grundplatte. Die Verbinder-Platine
schrauben wir direkt auf die Grundplatte und Bohren unter den Lötstellen
ein paar mm weg. Natürlich müsste die Platine lakiert sein. Somit haben
wir auch gleich einen gleichmäßigen Abstand zwischen Grundplatte und
Pixelplatine in jedem Pixel.
In etwa könnte die dann so aussehen:
+------------------------------+
| o Schraubenlöcher o |
| + -------- Positiv ------ + |
| - -------- Negativ ------ - |
| x -------- Bus ------ x |
| o Schraubenlöcher o |
+------------------------------+
Konrad S. schrieb: > Für die Stromversorgung reichen auch Streifen aus 0.1mm dicker > Kupferfolie. In einer Richtung kommt unter jede Trennwand ein 25 oder > 30mm breiter Streifen. Geradzahlige Streifen werden an GND > angeschlossen, ungeradzahlige Streifen an VCC. Die Module werden > abwechselnd reihenweise ¨linksrum¨ bzw. ¨rechtsrum¨ eingebaut. Der > Kontakt zwischen Platine und Kupferstreifen wird durch kurze > Kupferröhrchen hergestellt, evtl. gibt es z.B. Kupferhohlnieten mit > geeignetem Innendurchmesser für die Verschraubung der Platine and die > Grundplatte. Das ist eine echt gute Idee! Genau so hatte ich mir das erhofft. Man muss die Platinen sowieso nur an 2 Ecken diagonal anschrauben, also bräuchte man 2 Abstandhalter von 3mm, diese Kupferröhrchen oder was auch immer. Die Verschraubungen sind dann gleichzeitig VCC und Gnd.
Maik Pfeiffer schrieb: > Teils von Conny G.: xD > > | | Trennwand > | | > | | > | | > | | > Pixelplatine | | P.p. > ==================++= +--+ =++================ > =++==========++= <- Verbinder-Platine > -----------------|__|--------|__|--------------- > Grundplatte > ------------------------------------------------ > > Wir brauchen ja nicht mal durch die Grundplatte. Die Verbinder-Platine > schrauben wir direkt auf die Grundplatte und Bohren unter den Lötstellen > ein paar mm weg. Natürlich müsste die Platine lakiert sein. Somit haben > wir auch gleich einen gleichmäßigen Abstand zwischen Grundplatte und > Pixelplatine in jedem Pixel. > > In etwa könnte die dann so aussehen: > > +------------------------------+ > | o Schraubenlöcher o | > | + -------- Positiv ------ + | > | - -------- Negativ ------ - | > | x -------- Bus ------ x | > | o Schraubenlöcher o | > +------------------------------+ Und eine Verbinderplatine würde mehrere Pixel überspannen, wäre so 20-30cm lang, so lange wie das Format nicht die Produktionskosten hochtreibt. Was mir an so einer Lösung echt gut gefallen würde: keine Kabel und Strom und Signale in einem System. Und ob wir dann einen oder 2 Busse haben ist egal. Pixel nur aufstecken und fertig. Superelegant. Nur die Kosten machen mir sorgen. Ich habe keine Ahnung, ob man die Verbinderplatine 20mm x 200mm zu einem Preis von zB 3-5 Euro bekommen könnte. Die Kostenrechnung sähe dann so aus: Pixel 3 Euro, 144 Pixel 430 Euro. Verbinderplatine 5 Euro, 30 Verbinder 150 Euro. Verbinderplatine 3 Euro, 30 Verbinder 90 Euro. Also lieber 3 Euro. Dafür bekäme man dann: Null Verkabelung, supersauber, supereinfach, supergeil.
Oder noch eine andere Variante: Flexplatinenanschlüsse wie bei den LCD Displays. Die passen sogar einfach so unter den Trennwänden durch. Sind nur fummelig zum Einstecken.
Conny G. schrieb: >Und eine Verbinderplatine würde mehrere Pixel überspannen, wäre so >20-30cm lang, so lange wie das Format nicht die Produktionskosten >hochtreibt. Nicht ganz Conny, hatte es so gedacht das nur zwei Pixelplatinen miteinander verbunden werden, ähnlich den Infineon Modulen auf der Mainpage des Forums. Wenn jede Pixelplatine an jeder Seite die Gleichen (verpolungssicheren) Stiftleisten hat, kann man Diese einfach einstecken, wenn die Verbindungs-Platinen auf der Grundplatte aufgeschraubt sind. Somit kann man durch die Verbinder auch die "Form" der Busleitung festlegen. Ob Stern, Reihe nach Reihe oder Schnecken Form xD.
Conny G. schrieb: > Man muss die Platinen sowieso nur an 2 Ecken diagonal anschrauben, Wobei ich die Platinen nur minimal groß machen würde, also lang genug, um die ¨Stromschienen¨ zu erwischen und nur so breit wie unbedingt nötig.
Conny G. schrieb: >Oder noch eine andere Variante: Flexplatinenanschlüsse wie bei den LCD >Displays. Als Flex Platinen könnte man SLI Kabel von Grafikkarten nehemn, würden aber den Kostenrahmen sprengen. Statt 0,1mm Stronschienen würde ich doch eher Quetschverbinder und Kabel bevorzugen. Einfach einen endlos Stang quetschen und auf jeder Platine einstecken. http://www.reichelt.de/Flachstecker/FS-P-4-75/3/index.html?&ACTION=3&LA=2&ARTICLE=24863&GROUPID=3249&artnr=FS-P+4%2C75 Kostengünstig und schell zu quetschen mit einer ordentlichen Zange. U U U U U U U U | | | | | | | | + ===+=|========+=|========+=|========+ | | | | | - =====+==========+==========+==========+
Also die Flexidee ist gut, aber die kann glaub ich gleich verworfen werden. Das sprengt die Kosten. Flex ist ja allgemein um einiges teurer als normale "Platinchen". Die Schraubidee für die Spannungsversorgung würde ich auch versuchen. Ich würde einfach noch eine günstige alternative in den Raum werfen: Streifenraster ? :-)
Wie wäre es mit was ich in Beitrag "Re: schwierigkeiten passenden Bus zu finden" vorgeschlagen habe: Warum nicht bei elecrow.com 20cmx20cm PCBs bestellen und damit den Tisch komplett auslegen? Dann kann man billige Shift-register und die DIP-TLCs von Aliexpress verwenden, kann dicke Bahnen für die Versorgung machen und braucht kein Protokoll mehr und muss nur an den Rändern der PCBs ein paar Verbindungen machen für Strom und Kaskadierung? (z.B. mit Stiftleisten und Jumpern) Statt Kabel zu krimpen, Schienen zu entwickeln o.ä. könnte man damit alle Verbindungen ätzen lassen. Danach nur noch löten. 50 20cmx20cm würden 190 EUR kosten (ohne Versand und Zoll), 10 20cmx20cm würden 94 EUR kosten (ohne Versand und Zoll). Wenn ich mich nicht irre würde man mit http://www.aliexpress.com/item/100-Original-TLC5940NT-TLC5940-TI-LED-Driver-DIP-28/1468213464.html auch die Attinys sparen, zumindest für die LEDs. Also wäre am Ende alles wie bei ITGecko, nur ohne crimpen und die Modularität wäre grober. Ein Shift-Register für die Eingänge zu verwenden basiert halt auf "Entfernungssensor IS471+IR-LED LD274" (Roboterteile.de: 2,63EUR). Das ist teuer, aber was ich hier an Alternativen gelesen habe basiert bis jetzt immer auf dem Attiny, oder?
Christian H. schrieb: > Wie wäre es mit was ich in > Beitrag "Re: schwierigkeiten passenden Bus zu finden" > vorgeschlagen habe: > Warum nicht bei elecrow.com 20cmx20cm PCBs bestellen und damit den Tisch > komplett auslegen? Dann kann man billige Shift-register und die DIP-TLCs > von Aliexpress verwenden, kann dicke Bahnen für die Versorgung machen > und braucht kein Protokoll mehr und muss nur an den Rändern der PCBs ein > paar Verbindungen machen für Strom und Kaskadierung? (z.B. mit > Stiftleisten und Jumpern) > > Statt Kabel zu krimpen, Schienen zu entwickeln o.ä. könnte man damit > alle Verbindungen ätzen lassen. Danach nur noch löten. > > 50 20cmx20cm würden 190 EUR kosten (ohne Versand und Zoll), > 10 20cmx20cm würden 94 EUR kosten (ohne Versand und Zoll). > > Wenn ich mich nicht irre würde man mit > http://www.aliexpress.com/item/100-Original-TLC5940NT-TLC5940-TI-LED-Driver-DIP-28/1468213464.html > auch die Attinys sparen, zumindest für die LEDs. > > Also wäre am Ende alles wie bei ITGecko, nur ohne crimpen und die > Modularität wäre grober. > > Ein Shift-Register für die Eingänge zu verwenden basiert halt auf > "Entfernungssensor IS471+IR-LED LD274" (Roboterteile.de: 2,63EUR). Das > ist teuer, aber was ich hier an Alternativen gelesen habe basiert bis > jetzt immer auf dem Attiny, oder? Ich glaube den Attiny können wir nicht sparen. Die Ir Dioden Remote abfragen durch einen Master ist zu aufwendig. ADC auf Ferne ist keine gute Idee und dezentrale ADC bringen uns nicht weiter, dann kann man gleich Attinys nehmen. Würde also die Struktur der Lösung schon so lassen wie bisher eingekreist. Aber trotzdem könnte man das mit den 20x20 Pcbs überlegen, das erspart tatsächlich die Verkabelung komplett, es bräuchte nur Steckkontakte oder Brücken an den Rändern.
Conny G. schrieb: > Aber trotzdem könnte man das mit den 20x20 Pcbs überlegen, das erspart > tatsächlich die Verkabelung komplett, es bräuchte nur Steckkontakte oder > Brücken an den Rändern. Also nur für die Verbindungen extra Platinen?! Finde ich ehrlich gesagt ziemlich umständlich. Zumal das für mich nach Widerspruch klingt, wenn du sagst "erspart Verkabelung" und im nächsten Teilsatz "bräuchte nur Steckkontakte oder Brücken"... also wirklich sparen tu ich an diesem Ansatz doch gar nichts oder? Ich glaub ich versteh den Ansatz gerade etwas falsch... Und das würde preislich reinschlagen denke ich
Die Idee wäre, alle Bauteile auf 20cmx20cm PCBs zu löten und darüber dann die Holzkästen zu stellen. Jeder IR-Senser/LED und auch die RGB-LEDs und was auch immer an Shiftregistern, Tinys oder TLCs gebraucht wird, würde in den 20cmx20cm geroutet und gelötet. Es wäre kein Problem, von einem Atmega z.B. 14 Pins zu LEDs zu routen oder alles von einem TLC. Keine Kabel, kein Krimpen! Es wäre weniger modular, für 60cmx60cm reichen 9 Module, für 50cmx50cm muss man absägen und das Layout passend machen oder weitere Platinen für 10cmx10cm und 10cmx20cm machen. Und die Rasterweite ist fest. Aber ich glaube, es wäre die wenigste Arbeit und mit Elecrow.com sogar bezahlbar. Übrigens habe ich noch eine andere Idee: Mit Panelizing liese sich die Elektronik nicht auf die Bodenplatte packen, sondern auf die "Holzkästen": Elecrow würde einem in das PCB sicher auch die Kammstruktur fräsen und dann könnte man die Kastenstruktur aus PCB-Material machen (20cm x 5 cm PCBs, 50-100 Stück) und die Bodenplatte aus einer großen Holzplatte. Die Bauteile würden dann ihre Bedrahtung nicht von unten, sondern von der Seite haben. Einziger Vorteil: Man muss kein Holz sägen.
Tim R. schrieb: > Conny G. schrieb: >> Aber trotzdem könnte man das mit den 20x20 Pcbs überlegen, das erspart >> tatsächlich die Verkabelung komplett, es bräuchte nur Steckkontakte oder >> Brücken an den Rändern. > > Also nur für die Verbindungen extra Platinen?! Finde ich ehrlich gesagt > ziemlich umständlich. Zumal das für mich nach Widerspruch klingt, wenn > du sagst "erspart Verkabelung" und im nächsten Teilsatz "bräuchte nur > Steckkontakte oder Brücken"... also wirklich sparen tu ich an diesem > Ansatz doch gar nichts oder? Ich glaub ich versteh den Ansatz gerade > etwas falsch... Und das würde preislich reinschlagen denke ich Neil, nicht extra Platinen, sondern statt 5x5 dann 20x20 oder sogar größer (je nach Preis).
Conny G. schrieb: > Neil, nicht extra Platinen, sondern statt 5x5 dann 20x20 oder sogar > größer (je nach Preis). Auch wenn das die Verkabelung vereinfachen mag, kommen wir halt nicht weiter, wenn wir Kernaspekte, die eigentlich schon "beschlossen" waren doch wieder umkrempeln. Ich seh schon, hier wird irgendjemand einfach mal das Zepter in die Hand nehmen und machen müssen ;). Die Möglichkeiten wurden ja mittlerweile alle (mehr oder weniger) durch diskutiert. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Conny G. schrieb: >> Neil, nicht extra Platinen, sondern statt 5x5 dann 20x20 oder sogar >> größer (je nach Preis). > > Auch wenn das die Verkabelung vereinfachen mag, kommen wir halt nicht > weiter, wenn wir Kernaspekte, die eigentlich schon "beschlossen" waren > doch wieder umkrempeln. Ich seh schon, hier wird irgendjemand einfach > mal das Zepter in die Hand nehmen und machen müssen ;). Die > Möglichkeiten wurden ja mittlerweile alle (mehr oder weniger) durch > diskutiert. > > Mit freundlichen Grüßen, > Karol Babioch Dem stimme ich zu. Zumal wir durch die Pixellösung wirklich komplett flexibel sind. Wenn mehrere zusammengefasst werden sollen hat man schon mal eine Winschränkung... und ist das auch wirklich günstiger? Würde lieber zur bestehenden Lösung tendieren, damit wir nicht wieder erneut verschiedene Themen durchkauen brauchen :-)
Wenn die Pixel fertig entwickelt sind (inclusive Protokoll), hindert einen ja niemand, 4x4 (oder mehr) davon auf eine große Platine zu kopieren, mit ein paar Leiterbahnen dazwischen, die das Verdrahten ersparen.
Nosnibor schrieb: > Wenn die Pixel fertig entwickelt sind (inclusive Protokoll), > hindert > einen ja niemand, 4x4 (oder mehr) davon auf eine große Platine zu > kopieren, mit ein paar Leiterbahnen dazwischen, die das Verdrahten > ersparen. Genau so sehe ich das auch... Was sagt denn der Rest, der hier gerne mal mit postet ? :-) Um das Thema Master nochmal anzustupsen: Ich hatte ja schon mal gepostet, dass das BBB relativ schwer zu bekommen ist, soweit ich weiß werden die in der Industrie auch haufenweise weggekauft. Wie wäre es mit alternativen wie dem Cubie Board z.B. ? Ich kenne mich nur mit diesen ganzen neuen "Mini-PCs" á la Rpi gar nicht aus
Ich wäre auch dafür die Platinen vorerst auf 50x50 -0,1/-0.5 mm festzulegen. Größenänderungen kann man später immer noch vornehem. Auch würde ich vorschlagen, dass das Layout sich auf die Mitte der Pixelplatine konzentriert. Gibt auch ein Angebot für 200 mal 50x50mm Platinen für ~82€. Dann starte ich jetzt mal die Abstimmung xd. Nur "JA" oder "NEIN" für die 50x50 Pixelplatine, bitte!!!
Tim R. schrieb: > Ich kenne mich nur mit diesen > ganzen neuen "Mini-PCs" á la Rpi gar nicht aus Selbiges gilt für mich. Der Markt ist mittlerweile auch gar nicht mehr so einfach zu überschauen. Persönlich gearbeitet habe ich nur mit dem Raspberry Pi, das Beaglebone Black gefällt mir gerade in diesem Anwendungsfall aber deutlich besser. Wie gesagt, da mache ich mir derzeit noch keine Gedanken, weil der Master erst den übernächsten Schritt darstellt. Bis dahin kann sich die Verkaufssituation ja schon wieder geändert haben. Wenn nicht gucken wir uns nach Alternativen um. Das sollte ja hoffentlich keinen Einfluss auf jetzige Designkriterien haben, oder? Seanten schrieb: > Nur "JA" oder "NEIN" für die 50x50 Pixelplatine, bitte!!! Ja ;) Wenn wir schon beim Thema Umfragen bzw. Anfragen sind: Mich würde (zunächst rein aus Neugier) interessieren wie viele an einer solchen Sammelbestellung teilnehmen würden. Also soll jetzt noch keine verbindliche Bestellabgabe sein, aber es wäre sicherlich nicht schlecht zu wissen von wie vielen Platinen wir hier reden und ob eine Bestückung sinnvoll ist bzw. sich lohnen würde. Ich vermute nämlich, dass es hier durchaus einige "stille" Mitleser gibt. Das zumindest legen die Statistiken meiner oben geposteten Videos nahe ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Tim R. schrieb: >> Ich kenne mich nur mit diesen >> ganzen neuen "Mini-PCs" á la Rpi gar nicht aus > > Selbiges gilt für mich. Der Markt ist mittlerweile auch gar nicht mehr > so einfach zu überschauen. Persönlich gearbeitet habe ich nur mit dem > Raspberry Pi, das Beaglebone Black gefällt mir gerade in diesem > Anwendungsfall aber deutlich besser. Wie gesagt, da mache ich mir > derzeit noch keine Gedanken, weil der Master erst den übernächsten > Schritt darstellt. Bis dahin kann sich die Verkaufssituation ja schon > wieder geändert haben. Wenn nicht gucken wir uns nach Alternativen um. > Das sollte ja hoffentlich keinen Einfluss auf jetzige Designkriterien > haben, oder? Nein, das ist m.E. auch unabhängig vom Design des Pixel. Wir sollten am Ende mit jedem Timing-Akkuraten Master (also nicht RPi direkt z.B.) das Protokoll betreiben können. Das könnte auch sein Raspberry Pi > uC-Schaltung -> Pixelbus. Oder jede andere Kombi eines "größeren" Masters, der evtl. über einen uC auf den Bus geht. > Seanten schrieb: >> Nur "JA" oder "NEIN" für die 50x50 Pixelplatine, bitte!!! > > Ja ;) Ja. Ich wollte ja auch nicht die bisher diskutierte Lösung infrage stellen nur ein bisschen herum-brainstormen, welche Möglichkeiten es für die Verbindung noch gibt. Mir gefallen Verbinderplatinchen immer noch am besten, das ist dann, wenn wir bei 45x45-Platinchen bleiben ja ein separates Thema, ob Kabel, Schienen oder Verbinderplatinen. > Wenn wir schon beim Thema Umfragen bzw. Anfragen sind: Mich würde > (zunächst rein aus Neugier) interessieren wie viele an einer solchen > Sammelbestellung teilnehmen würden. Also soll jetzt noch keine > verbindliche Bestellabgabe sein, aber es wäre sicherlich nicht schlecht > zu wissen von wie vielen Platinen wir hier reden und ob eine Bestückung > sinnvoll ist bzw. sich lohnen würde. Ich vermute nämlich, dass es hier > durchaus einige "stille" Mitleser gibt. Das zumindest legen die > Statistiken meiner oben geposteten Videos nahe ;). Interessiert, 144 Stück.
Ich bräuchte dann 192 pixel. Werde mir wohl doch noch einen Job suchen müssen ^^. Worüber wir auch nachdenken sollten ist unter welcher Lizens das Projekt stehen soll, wenn sich damit Keiner auskennt würde ich mich da mal reinarbeiten. Kann ja nicht wirklich bei der Elektronik helfen und cad Zeichnungen sind in ein paar Stunden erledigt xd.
"Stiller Mitleser", sehr interessiert, ca. 1mx2m Tischgröße. Holger
seanten schrieb: > Worüber wir auch nachdenken sollten ist unter welcher Lizens das Projekt > stehen soll Ist ja bisher noch nichts veröffentlicht worden ;). Ich persönlich bin großer Befürworter der GPL (zumindest für die Software). Beim Thema Schaltpläne bzw. Designs und Layouts kenne ich mich weniger aus. Was macht denn hier aus deiner/eurer Sicht heraus Sinn? Creative Commons? Mit freundlichen Grüßen, Karol Babioch
seanten schrieb: > Worüber wir auch nachdenken sollten ist unter welcher Lizens das Projekt > stehen soll http://de.wikipedia.org/wiki/WTFPL ?
Ich bin nach wie vor am Tisch interessiert. Und würde Pixelplatinen von 45x45 bis 50x50mm bevorzugen :-) Schöner Einwand! Die "stillen Mitleser" habe ich noch gar nicht bedacht. Hätte auch ehrlich gesagt gar nicht angenommen, dass es welche gibt. Der Master kann natürlich am Ende besprochen werden, ich hatte nur gerade noch mal zwecks BBB geschaut. Ich würde vorschlagen, dass sich erstmal abschließend auf eine IR-LED + Fotodiode geeinigt werden sollte, welche günstig ist, lieferbar und natürlich entsprechende Eigenschaften aufweisen. Die im Video verwendeten Sensoriken waren nicht mehr die best zu beschaffensten oder?!
Conny G. schrieb: > http://de.wikipedia.org/wiki/WTFPL Ich persönlich bin schon ein Freund von Copyleft (und damit z.B. der GPL). Ich bin mir aber natürlich darüber bewusst, dass das ein ziemlich subjektives Thema ist und ich denke wir würden uns da schon irgendwie einig werden. Im Notfall könnte man das ja sogar zweigleisig lizensieren usw. usf. ;). Überhaupt ist ja bisher bis auf ein paar Zeilen Testcode noch nichts programmiert bzw. veröffentlicht worden. Insofern hat auch diese Frage noch Zeit ;). Tim R. schrieb: > Schöner Einwand! Die "stillen Mitleser" habe ich noch gar nicht bedacht. Doch, doch, sei dir mal sicher, dass es davon auch ein paar gibt ;). Tim R. schrieb: > Der Master kann natürlich am Ende besprochen werden, ich hatte nur > gerade noch mal zwecks BBB geschaut. Ja, zur Zeit ist das katastrophal, hoffentlich wird es wieder mal besser ;). Der BBB würde mir persönlich gut zusagen. Tim R. schrieb: > Die im Video > verwendeten Sensoriken waren nicht mehr die best zu beschaffensten > oder?! Wie eingangs erwähnt, hatte ich mich letztes Jahr schon einige Zeit damit beschäftigt gehabt und bin zu dieser Auswahl gekommen, weil die zusammen passen, gut und günstig sind. Bei Digikey [1] [2] würden wir bei einer Stückzahl von 1000 in etwa 8 Cent pro Stück zahlen (16 Cent pro Pixel). Bei 2500 wird es sogar nochmal einen Cent billger ;). Ich glaube kaum, dass wir es günstiger schaffen, lasse mich aber gerne vom Gegenteil überzeugen. Der ATtiny841 [3] ist für um die 70-80 Cent zu beschaffen, d.h. wir liegen mit den drei "Hauptkomponenten" bei unter einem Euro. Ich persönlich bin immer noch der Meinung wir sollten den Strom durch die IR LED regelbar machen, um Alterungseffekten vorzubeugen und größtmögliche Flexibilität in Bezug auf die verwendeten Materialien zu haben. Klassische LED Treiber konnte ich bisher allerdings keine brauchbaren und zugleich günstigen finden. Derzeit arbeite ich an einer PWM Glättung mittels Tiefpass und einem folgenden Impedanzwandler. Problem ist aber, dass einfache OpAmps wie der LM358 nicht von Rail-to-Rail operieren, und damit weitere Spannungen nötig wären -> Wenig attraktiv ... Habe für Tipps ein offenes Ohr ;). Bei dieser Gelegenheit: Wie wollen wir das jetzt mit der Spannungsversorgung machen? Jedem Pixel einen Spannungswandler spendieren? Bei welcher Eingangsspannung? Bei 100+ Pixeln kommen ja mit klassischen Linearreglern auch ganz schöne Verluste zusammen. Bei 12 Volt Eingangsspannung, 5 Volt Ausgangsspannung und einem Stromfluss von 100 mA, wären das 0,7 W pro Pixel, zumindest bei voller Helligkeit. Auch nicht wirklich akzeptabel, oder? Dann lieber für eine ausreichend stabile 5 Volt Spannungsversorgung sorgen und alles "direkt" (mit Pufferkondensatoren auf den Pixelplatinen) dranhängen? Echt erstaunlich wie viel es zu beachten gibt, selbst bei so etwas "einfachem" wie einem LED Tisch. Und ob das alles nachher auf Anhieb klappt ist die nächste Frage ;). Im Zweifel hockt dann jeder auf 100+ Platinen und muss doch noch massive Handarbeit leisten - in der Hoffnung noch etwas retten zu können, dass wir in der Planungsphase übersehen haben -> GAU. Mit freundlichen Grüßen, Karol Babioch [1]: http://www.digikey.com/product-detail/en/PD204-6B/1080-1139-ND/2675630 [2]: http://www.digikey.com/product-detail/en/IR204/1080-1072-ND/2675563 [3]: http://www.digikey.com/product-search/en?k=attiny841&mnonly=0&newproducts=0&ColumnSort=1000011&page=1&stock=0&pbfree=0&rohs=0&quantity=&ptm=0&fid=0&pageSize=25
:
Bearbeitet durch User
Ich habe das mit der Lizens deshalb angesprochen, da ich mit meiner cad Software nichts erstellen darf was hinterher kommerziell genutzt wird. Ist leider eine Einschränkung die ich im Hinterkopf behalten muss. Ich würde auch für später vorschlagen alle Holzteile der Tische zusammen herzustellen um einfach Großhandelsware zu bekommen. Habe leztens erst wieder feststellen müssen das sich die Verleihmung von Bauhausbrettern schon durch lakieren anlößt und Fugen sichtbar werden. Gerade bei 2m wird es sehr stark auffallen.
Karol Babioch schrieb: > [1]: > http://www.digikey.com/product-detail/en/PD204-6B/... > [2]: http://www.digikey.com/product-detail/en/IR204/108... > [3]: > http://www.digikey.com/product-search/en?k=attiny8... Dann nehme ich alles zurück. Von mir aus können diese Komponenten gerne als "fest" betrachtet werden seanten schrieb: > Ich habe das mit der Lizens deshalb angesprochen, da ich mit > meiner cad > Software nichts erstellen darf was hinterher kommerziell genutzt wird. > Ist leider eine Einschränkung die ich im Hinterkopf behalten muss. Das ganze sollte ohne kommerzielle oder gewinnbringende Hintergründe laufen. Rein priv. Gebrauch :-)
Zum IR-Stromregel-Problem: Als Impedanzwandler (von der RC-Tiefpasskette am PWM-Ausgang auf die IR-LED) sollte es eigentlich auch ein Transistor tun. Ein bipolarer Transistor mit Emitterwiderstand stellt ja praktisch eine (basis-)spannungsgesteuerte Stromquelle dar. Zwei Probleme sehe ich dabei, die man durchrechnen/simulieren müßte: - der nötige Basisstrom errechnet sich aus LED-Strom und Stromverstärkungsfaktor des Transistors. Dieser Basisstrom belastet den Tiefpass, so daß man den nicht beliebig hochohmig bauen kann. - Timing: die Controller-Hardware gibt eine maximale PWM-Frequenz vor; damit ist eine minimale Zeitkonstante für den Tiefpass gegeben (abhängig von der genauen Schaltung und der gewünschten maximalen Restwelligkeit). Wenn sich herausstellt, daß das für die gewünschte Touch-Abfragefrequenz zu lahm ist, brauchen wir einen zweiten Controller-Pin, um die IR-LED schnell Ein- und Ausschalten zu können. Und wahrscheinlich einen zweiten Transistor. Das artet langsam in richtiges analoges Transistorschaltungsdesign aus… mit quadratzentimeterweise Hühnerfutter auf der Platine. Eigentlich sollte der geschickte µC-Einsatz genau das vermeiden, dachte ich immer...
Stiller Mitleser hier :-) Ich wäre an ca. 100 Modulen interessiert. Und um auch etwas der Diskussion beizutragen: Ich halte es auch für sinnvoll eine Möglichkeit vorzusehen den IR-Dioden Strom zu steuern. Und mit steuern meine ich nicht Regeln. Das wäre in der Tat übers Ziel hinausgeschossen für unsere Anwendung. Ich denke der Vorschlage von Nosnibor den Strom mit Hilfe eines Bipolartranistors und dessen Stromverstärung zu steuern für eine gute Idee. Das wird man aber tatsächlich testen müssen. Die komplexität dieser Schaltung halte ich aber für überschaubar..
Nosnibor schrieb: > Ein bipolarer > Transistor mit Emitterwiderstand stellt ja praktisch eine > (basis-)spannungsgesteuerte Stromquelle dar. Habe ich noch gar nicht dran gedacht, werde ich mal probieren. Mal sehen wie "stabil" das Ganze ist. Nosnibor schrieb: > Wenn sich herausstellt, daß das für die gewünschte Touch-Abfragefrequenz > zu lahm ist, brauchen wir einen zweiten Controller-Pin, um die IR-LED > schnell Ein- und Ausschalten zu können. Und wahrscheinlich einen zweiten > Transistor. Zur Zeit arbeite ich mit 125 Hz, das sollte also mehr als nur machbar sein. Ansonsten hätte der ATtiny841 wohl noch genug freie Pins ;). Nosnibor schrieb: > Eigentlich > sollte der geschickte µC-Einsatz genau das vermeiden, dachte ich > immer... Du darfst gerne weitere Vorschläge machen ;). Der typische PWM-Ansatz zur Intensitätssteuerung fällt hier halt weg, und damit kommt man wohl um eine externe Beschaltung nicht ganz herum. backemf schrieb: > Und mit steuern meine ich nicht Regeln. Zumindest ich habe die Worte in meinen obigen Beiträgen ziemlich synonym verwendet, was natürlich nicht ganz korrekt ist. Ja, eine Steuerung ist hier gut genug ;). backemf schrieb: > Die komplexität > dieser Schaltung halte ich aber für überschaubar.. Die Komplexität ist sicherlich noch überschaubar, allerdings machen solche "Konstrukte" es immer unattraktiver die Module per Hand zu bestücken - gerade, wenn wir auf SMD setzen. Insofern hoffe ich einfach mal, dass sich noch ein paar mehr Leute melden, sodass die Herstellung und Bestückung der Platinen günstiger wird ;). Wenn ich das jetzt richtig zusammen getragen habe, dann schaut die Situation bisher so aus (hatte mich selbst übrigens vergessen bisher): Conny G. 144 seanten 192 Holger W. 100+? Tim R. 100+? backemf 100 Karol Babioch 256 (16x16) Das wären bisher also so um die 800+ Module. Insofern sollte sich doch eine Möglichkeit finden die gut und günstig herzustellen, vor allem werden es ja potentiell immer noch mehr werden ;). Mit freundlichen Grüßen, Karol Babioch
Noch eine Variante zur Steuerung des IR-LED-Stroms: PWM-Ausgang --> RC-Glied --> Transistor mit Emitterwiderstand. PWM relativ langsam und mit niedrigem Tastgrad, d.h. man kann das PWM-Signal als einzelne kurze Pulse ansehen. Während des Pulses wird die Basisspannung am Transistor ungefähr linear steigen, in der Pause klingt sie dann mehr oder weniger exponentiell ab. Wenn der A/D-Wandler (und die Photodiode) deutlich schneller ist als diese Vorgänge, kann man einfach eine Messung kurz vor Anfang des Pulses machen (dann ist die LED aus) und die zweite gegen Ende des Pulses (dann hat die LED ihre maximale Helligkeit). Mit der Pulsdauer stellt man ein, bei welchem LED-Strom gemessen wird. Da die Schaltung normalerweise mit geringem Tastgrad betrieben wird (der LED-Strom muß ja in den Pausen auf 0 abklingen), wird sie bei dauer-H am PWM-Ausgang die IR-LED durchbrennen; das ist in der Entwicklungsphase zu beachten! Vorteil gegenüber dem vorigen Ansatz (D/A-Wandler per PWM) ist der geringere Schaltungsaufwand, weil nicht mehr so stark geglättet werden muß.
Nosnibor schrieb: > Noch eine Variante zur Steuerung des IR-LED-Stroms: Ok, danke für den Input! Du scheinst ja recht fit in Bezug auf diese Thematik zu sein. Hättest du zufällig konkrete Werte für die Widerstände bzw. Kondensatoren? Oder Lust das mal eben durchzurechnen? Bei der verwendeten Frequenz können wir wirklich von "langsam" ausgehen (< 1 kHz und weniger) - denk ich mal. Mit freundlichen Grüßen, Karol Babioch
Angehängte Dateien:
-
VOLTCRAFT10_1.gif
17 KB
Ich habe hier einen kleinen Versuchsaufbau zusammengestöpselt: ein Arduino, der eigentlich etwas ganz anderes machen soll, erzeugt alle 20ms einen H-Impuls von abwechselnd 2ms und 3ms Dauer. Dann kommen 10kΩ und 1µF, dann ein BC547C mit 33Ω am Emitter und einer roten LED nach +5V am Kollektor. Das Oszi zeigt den Eingangsimpuls und den Spannungsabfall am Emitterwiderstand. Man sieht den erwarteten fast linearen Anstieg und den exponentiellen Abfall. Der Anstieg setzt verzögert ein, weil unterhalb einer minimalen Basisspannung (ca. 0,6V) praktisch kein Strom fließt, und diese Spannung muß erstmal erreicht werden, das dauert (ca. 1ms). Aus dem gleichen Grund geht der Strom auch in der Pause auf 0 zurück, was bei einem echten exponentiellen Abfall ja ewig dauern würde. Außerdem sieht man sehr schön, daß unterschiedlich lange Pulse in unterschiedlich hohe verwandelt werden. Aber die Flanken sehen unangenehm steil aus: ob man da jetzt ein stabiles ADC-Signal erwarten kann, ist fraglich. Der Strom ist mit 15mA Spitzenwert zu klein; da könnte man den Kondensator verkleinern, damit höhere Basisspannungen schneller erreicht werden. Oder den Emitterwiderstand verkleinern.
Angehängte Dateien:
-
4bit_current_source.png
2,4 KB -
4bit_current_source_sch.png
34 KB
Die Lösung mit Tiefpass gefolgt von bipolar Transistor ist entgegen meiner Annahme wohl doch etwas heikler. Um einen Kollegktor strom von 100mA zu ermöglichen ist ein Basisstrom in der Gegend von 0.2-1mA nötig. Das macht es notwendig den R des RC niedrig zu wählen was wiederrum bedeutet das die Frequenz der PWM sehr hoch sein muss um bei Sinnvollen Kapazitäten die notwendige Filterwirkung zu erreichen. Ich hab jetzt mal eine Anderen Ansatz verfolgt der allerding 3-4 Pins des µc beanspruchen würde. Haben wir die? Damit ließe sich mit 3-4 digitalen Ausgängen der Strom in 8 bwz. 16 Stufen einstellen.
Die Pins haben wir wahrscheinlich, aber die Anzahl der Bauteile soll möglichst klein bleiben. In diesem Sinne: weg mit den Dioden, und die Portpins dann statt Ausgang-LOW auf Eingang schalten.
Nosnibor schrieb: > Die Pins haben wir wahrscheinlich, aber die Anzahl der Bauteile > soll > möglichst klein bleiben. In diesem Sinne: weg mit den Dioden, und die > Portpins dann statt Ausgang-LOW auf Eingang schalten. das Selbe kam mir auch gleich in den Sinn. Um die Pins mache ich mir weniger Sorgen, sondern eher um den Platzbedarf der Kleinbauteile
Nosnibor schrieb: > In diesem Sinne: weg mit den Dioden, und die > Portpins dann statt Ausgang-LOW auf Eingang schalten. Die Dioden sind nur da um einen high-imp state der µC IOs zu simulieren. Die wären natürlich nicht notwendig. Notwendig wären nur 2 Transistoren und 6 Widerstände.
backEMF schrieb: > Die Dioden sind nur da um einen high-imp state der µC IOs zu simulieren. > Die wären natürlich nicht notwendig. > Notwendig wären nur 2 Transistoren und 6 Widerstände. OK, das leuchtet ein, deshalb auch "ideale" Dioden. Interessant wäre jetzt, wenn man mit aktivem LOW-Pegel auch noch etwas sinnvolles anfangen könnte, so daß man mit vier Ausgängen auf 81 verschiedene LED-Ströme käme.
Schön, dass sich da sogar mehrere Leute Gedanken drüber machen. Ich persönlich bin mittlerweile kurz davor doch noch zum CAT4003B zu greifen. Der bietet 3 Kanäle mit jeweils 25 mA und bietet 32 programmierbare Stufen. Wenn wir die drei Kanäle parallel schalten und die IR-LED damit bedienen, dann haben wir 32 Stufen und können den Stromfluss zwischen 0 und 75 mA steuern. Externe Beschaltung ist auch so gut wie keine nötig. Kostenpunkt: ~ 35 Cent. Ich lasse mich von euren kreativen Vorschlägen aber gerne überzeugen, sofern ihr der Meinung seid, dass es gut genug für unseren Anwendungsfall ist ;). Mit freundlichen Grüßen, Karol Babioch
35 Cent sind echt günstig für den Treiber. Mit der Transistorlösung sind war auch schon bei 20cent.16 stufen halte ich für ausreichend. Ich werde das ganze mal ausprobieren und berichten.
backEMF schrieb: > 35 Cent sind echt günstig für den Treiber. Ja, sehe ich auch so. Andererseits macht sich in diesem Fall halt wirklich jeder Cent bemerkbar -- bei potentiell tausenden von Modulen. Der Treiber würde uns halt viele externe Bauteile ersparen. Das einzige Problem: Im Datenblatt wird immer davon ausgegangen, dass man 3 einzelne LEDs betreibt. Wie sich der Baustein bei ein und der selben LED verhält, kann ich nicht sagen. Überhaupt wird (zumindest meiner Meinung nach) nicht klar wie der Treiber intern arbeitet. Von PWM ist nämlich keine Rede (also Linearregler?), während es bei anderen Treibern in dieser Preisklasse immer erwähnt wird. Vielleicht kann sich ja jemand mit mehr Erfahrung das Datenblatt ansehen und beurteilen, ob das so klappen könnte wie ich es mir vorstelle [1]. Für etwa 5 Cent mehr gäbe es auch den CAT4004B, d.h. 4 Kanäle, also bis zu 100 mA. Sinnvoll? An sich würde ich die IR LED einfach parallel an alle 3 bzw. 4 Kanäle hängen und hätte damit in 32 Stufen. Die Ansteuerung kann mittels jedem beliebigen Pin erfolgen, da die Timings aus Sicht eines Mikrocontrollers ziemlich einfach einzuhalten wären. Man kann halt nur in eine Richtung schalten, d.h. ggf. muss man mittels einem Wrap-Around zum gewünschten Level, wobei 32 Toggles selbst ohne Interrupt basiertem Ansatz kein Problem darstellen sollten. backEMF schrieb: > Ich werde das ganze mal ausprobieren und berichten. Super, bin gespannt ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://www.onsemi.com/pub/Collateral/CAT4003B-D.PDF
:
Bearbeitet durch User
welche Vorteile bringt denn die Steuerung des Stroms für die IR-LED? bringt das nicht eher Nachteile mit sich weil die Diode entsprechend mal "mehr" und mal "weniger" erkennt und dadurch die Werte sehr variieren können? Kann mich auch gerade komplett täuschen
blobba schrieb: > welche Vorteile bringt denn die Steuerung des Stroms für die IR-LED? Ein Vorteil ist das sich mögliche alterunseffekte der IR-LED ausgleichen ließen. Wobei ich die Alterung eher unkritisch sehe. Die meiste Zeit könnte die LED ja aus sein. Und möglicherweise ist es notwendig die Leistung an verschiedene Tische anpassen zu können.(Glas, Abstand, Reflektionen etc.) In wie weit das Sinn macht weiß ich nicht. Möglicherweise lässt sich ja auch mehr Information genwinnen indem man immer bei mehreren IR intensisäten mißt? Ich denke wir sollten bevor wir dne Strom veränderlich machen erst abklären ob es überhaupt einen klaren benefit gibt.
backEMF schrieb: > Ich denke wir sollten bevor wir dne Strom veränderlich machen erst > abklären ob es überhaupt einen klaren benefit gibt. Sehe ich genauso. Wieviele 10.000 Stunden hält so eine IR-Diode? Wieviele Stunden am Tag ist der Tisch eingeschaltet? Ich halte diese "Untersuchungen" für rein akademisch. IR-Diode per Widerstand an einen (PWM-)Portpin und fertig.
Frank M. schrieb: > Sehe ich genauso. Wieviele 10.000 Stunden hält so eine IR-Diode? > Wieviele Stunden am Tag ist der Tisch eingeschaltet? > > Ich halte diese "Untersuchungen" für rein akademisch. IR-Diode per > Widerstand an einen (PWM-)Portpin und fertig. war auch mein Gedanke. lässt das Vorhaben hier in eine etwas andere Richtung laufen denke ich...
Frank M. schrieb: > Ich halte diese "Untersuchungen" für rein akademisch. IR-Diode per > Widerstand an einen (PWM-)Portpin und fertig. Einen kleinen Transistor wird schon notwendig sei. Die 20mA vom Portpin werden nicht reichen.
hm der rest hier keine lust mehr oder schon mit einem bierchen in der sonne ?? ;-P
Das Thema ist zwar schon abgehakt, trotzdem dieser Nachtrag: Um dem Effekt "Unerwünschte Erkennung von Gegenständen über benachbarten Zellen" entgegenzuwirken, könnte man die IR-LED in eine Ecke der Zelle und die IR-Photodiode in die diagonal gegenüberliegende Ecke setzen. Der von der Zelle IR-beleuchtete und gleichzeitig gesehene Bereich beschränkt sich dabei im Wesentlichen auf den Raum direkt über der Zelle. Die Auswertung sollte im 2x2- oder 3x3-Raster erfolgen, damit die benachbarten Zellen nicht stören.
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.