Announcement: there is an English version of this forum on 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