Announcement: there is an English version of this forum on Karol Babioch schrieb: > Nochmal: Es geht nicht um die Interaktion von verschiedenen Pixeln > miteinander, sondern darum, dass ein Pixel auch Gegenstände über anderen > Pixeln erfassen kann, wenn es sich in einer bestimmten Höhe über der > Glasplatte befindet. So, jetzt hat es auch bei mir Klick gemacht. Und jetzt verstehe ich auch den ursprünglichen Post von Conny G. zu diesem Thema. Sorry, falls ich da Verwirrung gestiftet habe.
cyblord ---- schrieb: > avr-gcc unterstüzt den 841 in der aktuellen > Version. Wo finde ich Referenzen darauf? Auf der Homepage von avr-libc [1] ist davon noch keine Rede. Mein Eclipse mit aktueller Toolchain avr-gcc 4.9.0 und avr-libc 1.8.0 listet diesen auch noch nicht auf. cyblord ---- schrieb: > Für avrdude muss man den 841 noch in der conf datei eintragen. Das habe ich gesehen, ist aber die Definition von "geht nicht von Haus aus" ;). cyblord ---- schrieb: > Digikey liefert den 841 ab 1 Stück nach D auch für privat. Ok, bei Farnell ist die Lieferzeit nämlich unbekannt, der Preis dafür bei 70 Cent ;). cyblord ---- schrieb: > Obwohl ich nichtmal > das Studio verwende, sondern Eclipse mit AVR-Plugin, und ich das Plugin > auch noch an den 841 anpassen musste. Details? Ist das irgendwo dokumentiert? cyblord ---- schrieb: > So ist das halt > bei neuen Bausteinen. Ja, wobei man sich auch mehr Mühe geben könnte. Nach einem halben Jahr sollte das alles doch schon mal integriert sein ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://www.nongnu.org/avr-libc/user-manual/using_tools.html
Konrad S. schrieb: > So, jetzt hat es auch bei mir Klick gemacht. Und jetzt verstehe ich auch > den ursprünglichen Post von Conny G. zu diesem Thema. Sorry, falls ich > da Verwirrung gestiftet habe. Kein Problem, hatte das ja ursprünglich auch so gedeutet wie du ;). Beides sind Reflexionen und beides muss man im Design berücksichtigen. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > cyblord ---- schrieb: >> avr-gcc unterstüzt den 841 in der aktuellen >> Version. > > Wo finde ich Referenzen darauf? Auf der Homepage von avr-libc [1] ist > davon noch keine Rede. Mein Eclipse mit aktueller Toolchain avr-gcc > 4.9.0 und avr-libc 1.8.0 listet diesen auch noch nicht auf. Das ist ja auch veraltet. Die Toolchain wird ja inzwischen von Atmel gepflegt und dort findet man auch den aktuellen avr-gcc. Version kann ich dir grad nicht sagen. Müsste schon eine 5 davor sein. > Details? Ist das irgendwo dokumentiert? Nein, du kannst im Forum mal nach Tiny841 suchen, da findest du 1-2 Threads zu dem Thema inkl. 2 Dateien für das Plugin, welche den Tiny841 hinzufügen. Das wird aber sowieso nur für z.B. den "Fuse-Dialog" benötigt. Die Device-Liste holt sich das Plugin ja über avrdude. Und btw. von Haus aus, geht es eben mit dem Atmel Studio. Da brauchsts dann auch keinen avrdude. Für 3rd Party Tools kann man das nicht einfach mal so erwarten. Da muss man momentan halt noch selber was machen. gruß cyblord
:
Bearbeitet durch User
cyblord ---- schrieb: > Das ist ja auch veraltet. Die Toolchain wird ja inzwischen von Atmel > gepflegt und dort findet man auch den aktuellen avr-gcc. Link? cyblord ---- schrieb: > Müsste schon eine 5 davor sein. Da erzählst du mir aber was neues. avr-gcc wird parallel mit dem eigentlichen gcc entwickelt und da ist 4.9 Stand der Dinge (~ 1 Monat alt). cyblord ---- schrieb: > Die Device-Liste holt sich das Plugin ja über avrdude. Ja, und avrdude braucht derzeit noch zusätzliche Einträge in der Konfiguration. Das Problem mit dem Eclipse Plugin ist, dass es wohl ziemlich tot drum geworden ist, keine Ahnung, ob sich darum noch jemand kümmert und es bei Gelegenheit updated? Mit freundlichen Grüßen, Karol Babioch
Das aktuelle Atmel Studio 6.2 unterstützt den ATtiny841. Ich verwende allerdings die von Atmel bereitgestellte Toolchain für Linux. Quelle: http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx?tab=overview Bei avrdude.conf (Version 6.1) habe ich den Eintrag für den ATtiny841 hinzugefügt. Quelle: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1120422
Karol Babioch schrieb: > Frank M. schrieb: >> Diesen >> ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum >> Beispiel die Farben zu wechseln o.ä. > > Ich würde bei diesem Projekt gerne auf IR-Fernbedienungen verzichten. > Halte ich nach wie vor für unzeitgemäß. Smartphones sei dank. Die Steuerung des Tisches sollte am Besten so aussehen: :-) http://youtu.be/DTb0k_P1wlY > Conny G. schrieb: >> Dann wäre wichtig, dass man mit der gefundenen Lösung beides kann. Ich >> möchte Annäherung mit analogem Wert der Messung können (ermöglicht auch >> eine globale Kalibrierurung beim Master) und auch bei 10cm was messen. > > Wobei das die Ansprüche an den Bus wieder erhöht, weil nicht nur ein/aus > übertragen werden muss, sondern ein 8/9/10 Bit ADC Wert. Ja, aber - s.u. - bei 2 Bus-Ringen überträgt man eh in einer Richtung 3x PWM-Wert, das ist genügend Zeit um 8+ Bits Touch-Value zurückzuschicken. > Frank M. schrieb: >> Die Notwendigkeit für 2 >> UARTs sehe ich zwar noch nicht, aber schaden kanns nicht. > > Hier mein Vorschlag: Zwei gegenläufige UART-Ringe. Halbiert die > Verzögerung bis der letzte was mitbekommen hat, und verdoppelt den > Durchsatz. Die Hardware stände uns bei diesem Mikrocontroller ja zur > Verfügung ;). Jetzt sind wir nicht mehr weit von meinem Vorschlag in: http://www.mikrocontroller.net/articles/RGB_Touch_Matrix entfernt. Der Unterschied ist jetzt noch, dass ich dort ein implizites CLK wie beim WS2812(b) angenommen habe. Beim UART-Ansatz würde man das UART-Prinzip zugrundelegen. Aber kann man die 2 USI nicht genau wie das WS2812-Protokoll einsetzen? Dann ist die Zeit pro Pixel und pro Frame festgelegt und alles synchron und fein :-)
Frank M. schrieb: >> Im Prinzip gibt es zwei Richtungen. Aus Sicht des "Masters" sieht es so >> aus: >> >> - Ausgabe: RGB-Daten für jeden einzelnen Pixel, also mindestens 24 Bit >> - Eingabe: Status des Touch-Sensoren. Wenn wir es einfach halten wollen, >> dann 1 Bit (an/aus), oben wurde aber auch vorgeschlagen eine analoge >> Auswertung im Master zu ermöglichen, um dann Kontrastanalysen und >> ähnliches zu machen. Dann braucht es je nach ADC-Modus und Genauigkeit >> schon 8/9/10 Bit. > > Warum muss der Master den Status jeden einzelnen Touch-Sensors wissen? > Das kann doch jeder ATTiny-Slave selbst entscheiden, was er dann > macht.... zum Beispiel seine LED hochfaden. Der Master entscheidet, was die Pixel machen und versorgt sie mit Daten. Jeden einzeln, wie bei der Bildwiederholrate eines Screens: die Pixel wissen gar nix, nur ihren letzten RGB-Wert, den sie halten und den Touchstatus, den sie ständig mitteilen. Der Master fährt ein Spiel, oder eine Animation, was auch immer. http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html http://youtu.be/DTb0k_P1wlY > Ich sehe eher die Aufgabe eines Masters darin, den anderen ab und zu mal > mitzuteilen, was die Slaves machen sollen, wenn der Touch-Sensor mal > ansprechen sollte - also eine Art "Verhaltensprogramm". > > Was ich mir auch vorstellen kann: Eine "Vernetzung" der Slaves > untereinander mit jeweils dessen Nachbarn, also 4 Drähte zu jeweils dem > Slave links, rechts, oben, unten. So können sie dann dem Nachbarn durch > Ziehen der Strippe (standrdmäßig HIGH über Pullup) auf GND mitteilen, > wenn ihr Touch-Sensor angesprochen hat. Dadurch können die Nachbarn ihre > LEDs auch mal kurz ansprechen.... Wenn sie dies auch wieder den Nachbarn > mitteilen, könnte man so ganze "Wellen" durch den Tisch laufen lassen, > wenn jemand ein Glas abstellt. Zu limitiert, damit lassen sich Features wie oben verlinkt nicht lösen. > Meiner Meinung reicht Ein-/Aus auch als Touch-Sensor aus. M.e. muss der Touch kalibriert werden, das macht am Besten der Master im Gesamten. Wenn sich jeder Pixel einzeln kalibriert, kann es zu komischen Effekten kommen. Und wenn schon der Master den Touchwert bekommt (was bei 2 Busringen kein Aufwand ist), dann kann man auch mit Annäherung spielen, wenn man möchte. Wer das nicht möchte, arbeitet mit On/Off. Halte es aber für falsch die Architektur von Anfang für On/Off zu limitieren.
Conny G. schrieb: > Die Steuerung des Tisches sollte am Besten so aussehen: :-) > http://youtu.be/DTb0k_P1wlY Okay, das Video hat mich überzeugt, sowas kann man nur mit einem dicken Master machen. Hinweise zur im Video verwendeten Hardware gibt's hier: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html#Platine Während die 100 Lochrasterplatinen noch ziemlich "thin" aussehen (IR-Diode, Poti, (teurer!) IR-Sensor, RGB-LED und ein wenig Hühnerfutter), ist die Hauptplatine schon ziemlich fett - meines Erachtens. Halten wir also mal fest: Anzeige: Der Master überträgt RGB-Werte an M x N µCs (z.B. 10x10). Dies sollten Zielwerte sein, die in X Hunderstel-Sekunden per Fading erreicht werden sollen. Die Zeitspanne X wird natürlich auch vom Master vorgegeben. Ist sie 0, wird der RGB-Wert instantan angezeigt. So braucht der Master keine Zwischenwerte zu schicken und die Clients können selbst vom aktuellen RGB-Wert zum Ziel-RGB-Wert faden. So habe ich das bei meinem Equinox-Projekt mit den 60 ATTinys gemacht. Das spart eine Menge an Kommunikation. Ausserdem sind mit ein paar Bytes auf ganz einfache Weise auch Broadcasts möglich. Einen UART-Ring halte ich bei bei der Anzeige für unzweckmäßig, da jeder Slave das empfangene Byte erst weitersenden kann, wenn es vollständig empfangen wurde. Dadurch ergeben sich im Ring je nach Anzahl der Slaves erhebliche Verzögerungszeiten. Ich würde da eher einen UART-Bus nehmen: Alle Slaves haben eine ausgezeichnete Adresse und horchen mit RX an derselben Strippe. So habe ich es mit dem Equinox-Projekt gemacht. Nur ist es da kein UART, sondern ein synchroner serieller Bus. Aber der Unterschied ist da nur marginal. Bei dieser Vorgehensweise kann man ganze Blöcke von Daten verschicken, ohne die Slaves einzeln adressieren zu müssen. Man sendet Startadresse, Länge X des Blocks und anschließend X RGB-Werte. Dann picken sich X Slaves die für sie relevanten Daten aus dem Block heraus. Sensoren: Der Master muss jederzeit über die Sensoren informiert sein. Dies könnte man vielleicht tatsächlich über einen UART-Ring machen, da dies nicht so zeitkritisch ist. Der Master schiebt ein Kommando-Byte in den Ring und anschließend fallen M x N Touch-Sensor-Bits aus dem Ring am Ende wieder raus. Ich würde als Master einen Raspberry-PI oder ein Carambola nehmen. Dann haben wir genügend Power und die nötigen Schnittstellen.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Die Zeitspanne X wird natürlich auch vom Master vorgegeben. Ist > sie 0, wird der RGB-Wert instantan angezeigt. So braucht der Master > keine Zwischenwerte zu schicken und die Clients können selbst vom > aktuellen RGB-Wert zum Ziel-RGB-Wert faden. Halte ich nach wie vor zu "komplex". Ich würde die Clients wirklich "dumm" halten. Zwischenwerte & Co. sollen alle vom Master kommen. Der hat genug Power und kann sich Gedanken machen was Sinn macht. Ich würde das mit einem Touch-Monitor vergleichen. Hier kümmert sich der Monitor auch nur im die Eingabe (Touch) bzw. Ausgabe (Pixel). Die Auswertung der Eingabe(n) bzw. die Ausgabe(n) kommen vom Host. Frank M. schrieb: > Ich würde da eher einen UART-Bus nehmen: > Alle Slaves haben eine ausgezeichnete Adresse und horchen mit RX an > derselben Strippe. Nur haben wir dann das Problem, dass die Leitung extrem (!) lang bzw. kapazitiv ist. Keine Ahnung, ob das so ohne Weiteres in den Griff zu bekommen ist. Eine individuelle Adressierung würde mir auch besser gefallen, aber man kann nicht alles haben ;). Frank M. schrieb: > Ich würde als Master einen Raspberry-PI oder ein Carambola nehmen. Dann > haben wir genügend Power und die nötigen Schnittstellen. Wir hatten uns weiter oben schon auf ein Beaglebone geeinigt. Ist auch ein Linuxboard, bietet aber den Vorteil, dass es gleich MCUs mitliefert, die die Kommunikation übernehmen können. Der RasPi ist z.B. ziemlich lahm, wenn es um das gezielte Ansteuern von einzelnen Pins geht. Im Prinzip ist es aber auch egal, geht nur darum, dass man "schöne" Treiber schreibt, sodass man Anwendungen in High-Level Frameworks programmieren kann ohne sich um die darunterliegenden Details kümmern zu müssen. WiFi bzw. Ethernet inkl. Web-Interface wären auch nett. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Halte ich nach wie vor zu "komplex". Ich würde die Clients wirklich > "dumm" halten. Ist überhaupt nicht komplex. Wenn Du als Zeitspanne 0 schickst, hast Du genau Deinen "dummen" Fall. Mit Zeitspanne != 0 spart es aber jede Menge an Kommunikation. Hast Du Dir mal das im Equinox-Thread verlinkte Video heruntergeladen und angeschaut? > Zwischenwerte & Co. sollen alle vom Master kommen. Der > hat genug Power und kann sich Gedanken machen was Sinn macht. Hier geht es nicht um Power, sondern um die Menge an Daten. Du hast zum Beispiel ein Bild (MxN = 100 RGB-Werte) und Du willst, dass eine halbe Sekunde ein anderes Bild gezeigt wird. Wenn Du nun das Ziel-Bild schickst (weitere 100 RGB-Werte), dann faden die Pixel wie von Geisterhand gleitend auf das Zielbild. Das gibt für jedes Pixel einen gleitenden Übergang, wobei die Geschwindigkeit intern bis zu 25 Updates pro Sekunde sein können. Stell Dir nun vor, Du müsstest die alle übertragen... > Ich würde > das mit einem Touch-Monitor vergleichen. Hier kümmert sich der Monitor > auch nur im die Eingabe (Touch) bzw. Ausgabe (Pixel). Die Auswertung der > Eingabe(n) bzw. die Ausgabe(n) kommen vom Host. Das ist doch okay so. Nur die Zwischenwerte können für die Übergänge intern berechnet werden, sonst langweilen sich die Slaves doch nur. > Frank M. schrieb: >> Ich würde da eher einen UART-Bus nehmen: >> Alle Slaves haben eine ausgezeichnete Adresse und horchen mit RX an >> derselben Strippe. > > Nur haben wir dann das Problem, dass die Leitung extrem (!) lang bzw. > kapazitiv ist. Nö. Du legst TX des Masters auf 10 Transistoren/MOSFets und die schickst Du durch die Zeilen. Dann ist jede der Strippen nur maximal so lang wie eine Zeile und nicht M x N Zeilen. > Keine Ahnung, ob das so ohne Weiteres in den Griff zu > bekommen ist. Eine individuelle Adressierung würde mir auch besser > gefallen, aber man kann nicht alles haben ;). Doch kann man. Schau Dir mal das Video an. Die C-Funktionen sind im Master sehr klein, die Effekte sind aber riesig. Und wie gesagt: Mit Zeitspanne = 0 hast Du Deinen "Dummy-Mode" :-) Die Funktionen zum Faden innerhalb der ATTinys kann ich gern beisteuern, das ist kein Problem. > Frank M. schrieb: >> Ich würde als Master einen Raspberry-PI oder ein Carambola nehmen. Dann >> haben wir genügend Power und die nötigen Schnittstellen. > > Wir hatten uns weiter oben schon auf ein Beaglebone geeinigt. Ist auch > ein Linuxboard, bietet aber den Vorteil, dass es gleich MCUs mitliefert, > die die Kommunikation übernehmen können. Der RasPi ist z.B. ziemlich > lahm, wenn es um das gezielte Ansteuern von einzelnen Pins geht. Meinetwegen auch Beaglebone, da hab ich noch 4 Stück von in der Bastelkiste, kein Problem ;-) > Im Prinzip ist es aber auch egal, geht nur darum, dass man "schöne" > Treiber schreibt, sodass man Anwendungen in High-Level Frameworks > programmieren kann ohne sich um die darunterliegenden Details kümmern zu > müssen. WiFi bzw. Ethernet inkl. Web-Interface wären auch nett. Eben. Ist alles machbar. Gruß, Frank
Frank M. schrieb: > Hast Du Dir mal das im Equinox-Thread verlinkte Video > heruntergeladen und angeschaut? Ja, und in deinem Fall macht das wahrscheinlich auch am meisten Sinn. Hier sehe ich die Notwendigkeit dafür aber nicht, weil es das Entwickeln von Anwendungen schwieriger bzw. unintuitiver macht. Würde das ganze lieber als eine Art Framebuffer behandeln, anstatt mir über verschiedene Timing-Aspekte Gedanken machen zu müssen. Frank M. schrieb: > Stell Dir nun vor, Du müsstest die alle > übertragen... Der Bus muss das sowieso hergeben, sofern wir irgendetwas realisieren wollen was mit der Intelligenz der einzelnen Clients nicht mehr möglich ist. Frank M. schrieb: > Nö. Du legst TX des Masters auf 10 Transistoren/MOSFets und die schickst > Du durch die Zeilen. Dann ist jede der Strippen nur maximal so lang wie > eine Zeile und nicht M x N Zeilen. Wobei selbst das noch 1-2 Meter lang werden kann, je nachdem was die Leute denn effektiv vor haben. Bei den erforderlichen Taktraten stelle ich mir das schwierig vor. Bin aber kein ausgebildeter Elektrotechniker, ist nur mein Bauchgefühl. Lasse mich da gerne vom Gegenteil überzeugen ;). Frank M. schrieb: > Doch kann man. Schau Dir mal das Video an. Die C-Funktionen sind im > Master sehr klein, die Effekte sind aber riesig. Und wie gesagt: Mit > Zeitspanne = 0 hast Du Deinen "Dummy-Mode" :-) Das Video habe ich gesehen. Finde ich auch klasse. Aber das ist trotzdem nicht so besonders gut auf diesen Fall übertragbar. Wir wollen mit dem ganzen Tisch kontextabhängig interagieren. Intelligenz in den Clients halte ich eher für störend bzw. komplett unnötig. Da würde ich lieber den Bus so dimensionieren, dass die konstante Ausgabe von Daten mit 30 Hz kein Problem darstellt. Im Worst-Case muss das ja auch bei "schlauen" Clients funktionieren, ansonsten wäre man auf das beschränkt was die Clients können. Und die sind nun einmal bei weitem nicht so rechenstark wie der dazugehörige Host. Wie sehen das denn die anderen? Vielleicht bin ich auch der Einzige, der das so sieht, aber irgendwie gefällt mir die Idee von "schlauen" Clients nicht so besonders. Wie gesagt, ich würde das Ding eher mit einem Touch-Monitor vergleichen. Und bei einem solchen Monitor kommen sämtliche Auswertungen, Effekte und Anwendungen auch vom Host. Mit freundlichen Grüßen, Karol Babioch
Ich greife mal Franks Fading auf und spinne was dran. Unter Verzicht auf einen Quarz ergibt die 16-Bit-PWM eine Rate von 122 Updates pro Sekunde, ein recht brauchbarer Wert. Mit einem Byte für die Fading-Dauer kann das Fading mehr als zwei Sekunden dauern. Bei angenommenen fünf Bytes pro Feld, 30 Frames pro Sekunde und geschätzten 20 kByte pro Sekunde Nettoduchsatz könnten pro Master-TX durchaus 128 Felder mit Daten versorgt werden. Der "Trick" mit mit der gemeinsamen Ansteuerung der Felder-RX geht ähnlich auch für den Rückkanal: Solange für der Felder-TX das TXENn-Bit nicht gesetzt ist, gilt die normale Funktion des Port-Pins, kann also hochohmiger Input sein. Felder-TX-Pins lassen sich zusammenschalten, wenn die Software sicherstellt, dass nur immer ein Feld sendet. Hier ist viel Zeit für Sensordaten der Felder, weil keine Daten vom Master transportiert werden müssen.
Hi, die Nodes/Pixel sollten so minimal wie möglich sein, sowohl was die Bauteile als auch Intelligenz betrifft. Bauteile: - Controller (ATtiny841 ?) - RGB-LED - IR-LED - IR-Photodiode - ein paar Widerstände und Kondensatoren - ggf. Quarz notwendig - ggf. LED-Treiber Intelligenz des Pixelcontrollers: - Bootloader zum nachträglichen Neuprogrammieren (wichtig!) - Implementierung einer Daisy Chain, Taktgenerierung/Weitergabe noch offen - Annahme der RGB-Daten - Software oder Hardware PWM - Ansteuerung der IR-LED (pulsen) - Rückgabe des Analogwertes der gemessenen Spannung (ggf. gemittelt und/oder Differenz aus IR-LED an/aus) an der IR-Photodiode Sämtliche Steuerung der Pixel soll vom Master erfolgen. Ciao... Markus
Karol Babioch schrieb: > Frank M. schrieb: >> Hast Du Dir mal das im Equinox-Thread verlinkte Video >> heruntergeladen und angeschaut? > > Ja, und in deinem Fall macht das wahrscheinlich auch am meisten Sinn. > Hier sehe ich die Notwendigkeit dafür aber nicht, weil es das Entwickeln > von Anwendungen schwieriger bzw. unintuitiver macht. Würde das ganze > lieber als eine Art Framebuffer behandeln, anstatt mir über verschiedene > Timing-Aspekte Gedanken machen zu müssen. > > Frank M. schrieb: >> Stell Dir nun vor, Du müsstest die alle >> übertragen... > > Der Bus muss das sowieso hergeben, sofern wir irgendetwas realisieren > wollen was mit der Intelligenz der einzelnen Clients nicht mehr möglich > ist. > > Frank M. schrieb: >> Nö. Du legst TX des Masters auf 10 Transistoren/MOSFets und die schickst >> Du durch die Zeilen. Dann ist jede der Strippen nur maximal so lang wie >> eine Zeile und nicht M x N Zeilen. > > Wobei selbst das noch 1-2 Meter lang werden kann, je nachdem was die > Leute denn effektiv vor haben. Bei den erforderlichen Taktraten stelle > ich mir das schwierig vor. Bin aber kein ausgebildeter Elektrotechniker, > ist nur mein Bauchgefühl. Lasse mich da gerne vom Gegenteil überzeugen > ;). > > Frank M. schrieb: >> Doch kann man. Schau Dir mal das Video an. Die C-Funktionen sind im >> Master sehr klein, die Effekte sind aber riesig. Und wie gesagt: Mit >> Zeitspanne = 0 hast Du Deinen "Dummy-Mode" :-) > > Das Video habe ich gesehen. Finde ich auch klasse. Aber das ist trotzdem > nicht so besonders gut auf diesen Fall übertragbar. Wir wollen mit dem > ganzen Tisch kontextabhängig interagieren. Intelligenz in den Clients > halte ich eher für störend bzw. komplett unnötig. Da würde ich lieber > den Bus so dimensionieren, dass die konstante Ausgabe von Daten mit 30 > Hz kein Problem darstellt. Im Worst-Case muss das ja auch bei "schlauen" > Clients funktionieren, ansonsten wäre man auf das beschränkt was die > Clients können. Und die sind nun einmal bei weitem nicht so rechenstark > wie der dazugehörige Host. > > Wie sehen das denn die anderen? Vielleicht bin ich auch der Einzige, der > das so sieht, aber irgendwie gefällt mir die Idee von "schlauen" Clients > nicht so besonders. Wie gesagt, ich würde das Ding eher mit einem > Touch-Monitor vergleichen. Und bei einem solchen Monitor kommen > sämtliche Auswertungen, Effekte und Anwendungen auch vom Host. > > Mit freundlichen Grüßen, > Karol Babioch Ich stimme Karol voll zu: Hardware und Protokoll strukturell so simpel wie möglich, Slave = Dummer Pixel, der Host/Master hält den Framebuffer und überträgt das komplette Bild mit 25fps. Oder anders ausgedrückt: es ist sowohl bei Software als auch bei Hardware der beste Weg mit dem wichtigen Base Case zu beginnen und die Lösung so simpel wie möglich, so komplex wie nötig aufzusetzen. Speed-Optimierungen o.ä. macht man später, wenn man in konkrete Probleme läuft. Also spare ich mir adressierbare Notes und ein komplexeres Bildmanagement solange ich kann und mache einen dummen Daisy Chain Bus und einen Framebuffer. Es gibt keinen harten Grund eine Deltaanzeige zu machen sofern der Bus 25fps bei 200 oder 400 Pixeln hergibt. Wenn dann doch mal jemand eine Tanzfläche mit 10.000 Zellen bauen will, dann muss er sich was überlegen :-)
Also 25 ist aber wirklich Untergrenze oder nicht? 35-40Hz sind doch schon schöner :-) ich würde die "dumme" Salve Taktik auch bevorzugen. Ich glaub ein intelligenter Slave/Pixel zieht auch viel Aufmerksamkeit und Sorgen mit sich. Lieber einen strapazierbaren/schnellen Bus und alle Entwicklungen können auf dem Master laufen. Die Pixelplatinen nehmen nur noch RGB-Daten an, zeigen an und schicken Touch-Sensor-Wert zurück. Hast du die alten oder neuen Beagle Bones? Also einen Black? Momentan sind die Dinger ja recht Rar, wie ich das mitbekommen habe :-( P.S.: Kommt es mir nur so vor oder wird es hier langsam ein wenig kuddel muddel von den Themen... wie wäre es mit einem kurzen Schlachtplan für die weiteren Besprechungen ? ;-) freut mich aufjedenfall, dass sich nun viele hier beteiligen !
Tim R. schrieb: > Also 25 ist aber wirklich Untergrenze oder nicht? 35-40Hz sind doch > schon schöner :-) Kannst du denn wirklich mehr als 25 Bilder pro Sekunde wahrnehmen? Ich behaupte mal: Nein. Aber klar, der Bus sollte nicht an der absoluten Leistungsgrenze betrieben werden. Tim R. schrieb: > P.S.: Kommt es mir nur so vor oder wird es hier langsam ein wenig > kuddel muddel von den Themen... wie wäre es mit einem kurzen > Schlachtplan für die weiteren Besprechungen ? ;-) Mach einen Vorschlag ;). Bis zum ersten Prototyp ist das wohl alles - mehr oder weniger - eine Sammlung von Ideen und Anforderungen. Mit freundlichen Grüßen, Karol Babioch
Ich finde, Karol macht einen kleinen Denkfehler beim UART-Ring. Selbst bei einer Übertragungsrate von 115200 Baud sind es bei 8 Bit / no parity insgesamt 10 Bits (inkl. Start-/Stop-Bit) pro Byte. Damit beträgt die Übertragungsrate 11520 Byte/sec. Nehmen wir nun 100 Slaves an und 3 Bytes für jeden RGB-Wert. Dann sind das 3000 zu übertragene Bytes. Die Übertragung vom Master aus dauert dafür minimal 3000/11520 = 0,26 Sekunden. Damit kommt man auf ca. 4 Frames pro Sekunde. Hinzu kommen noch Verzögerungen bis zum letzten Slave, weil die Bytes immer erst weitergereicht werden können, wenn sie auch komplett empfangen wurden. Der letzte Slave erhält seine Daten also um einiges später, nämlich mindestens um 100/11520 Sekunden - auch wenn die Daten des letzten Slaves als erstes geschickt werden würden. Mit meinem intelligenten Protokoll (zusammen mit dem UART-Bus statt Ring), wo nur die Unterschiede gesendet werden brauchen, reduziert sich die zu übertragene Datenmenge erheblich. Genauso arbeiten Video-Komprimierungen, welche die Datenmenge auf durchschnittlich ein Zehntel herunterdrücken. Es ist auch kein Problem, für den Master eine Funktion zu schreiben, die einen Soll-Framebuffer übergeben bekommt und dann anhand des Ist-Framebuffer-Inhalts nur die Unterschiede (in Blöcken zusammengefasst) überträgt. Was ist daran kompliziert? Der Anwenderprogrammierer füllt einen Framebuffer, ruft die Send-Funktion auf, diese ermittelt die Diffs zum Ist-Zustand und überträgt dann nur die Unterschiede. Da braucht der Programmierer einer Anwendung für den Tisch sich überhaupt keinen Kopf drum zu machen. Das ist easy. Zusammen mit der Fade-Intelligenz in den Slaves kann das alles noch geglättet werden. Da ruckelt dann nix mehr. Die Slave-Funktionen dafür habe ich fix und fertig. Da muss nichts mehr neu erfunden werden noch bereitet es irgendeinem Kopfzerbrechen. Wenn der Anwender-Programmierer das Slave-Fading nicht nutzen will, benutzt er einfach als Fading-Zeitdauer die Null und schon erscheint das neue Bild instantan. Wenn ich Lust und Zeit hätte, würde ich jetzt einfach mal 10 Equinox-LED-Streifen zusammenlöten (10x15 = 150 ATtinys) und zeigen, dass man damit sogar einfache Filme in Farbe zeigen kann, wobei Farbwechsel von bestimmten Pixeln sacht ablaufen und die ATtinys damit sogar Zwischenbilder "berechnen" und damit Bewegungen viel flüssiger ablaufen. Mit einer Komplettübertragung eines Frames über UART bekommt man das nicht hin, siehe oben. Aber wie immer bei solchen Projekten: Dutzende reden, bis irgendwann einer anfängt und macht....
Karol Babioch schrieb: > Tim R. schrieb: >> Also 25 ist aber wirklich Untergrenze oder nicht? 35-40Hz sind doch >> schon schöner :-) > > Kannst du denn wirklich mehr als 25 Bilder pro Sekunde wahrnehmen? Ich > behaupte mal: Nein. Aber klar, der Bus sollte nicht an der absoluten > Leistungsgrenze betrieben werden. Es ist hier auch anders als zB beim Multiplexing: dort ist ein Pixel ein n-Tel der Zeit an und (n-1)/n aus - hier brauche ich wie bei PWM eine hohe Refresh Rate um kein Flimmern zu sehen. Aber unsere Pixel halten einfach den letzten Stand solange bis neue Daten kommen. Also geht es nicht um flimmern, sondern um die flüssige Wahrnehmung von Bewegung. Und da wir sowieso nur eine Auflösung von 10x10 oder 20x20 haben kann man von flüssiger Bewegung sowieso nicht sprechen, da ein Block immer um 6cm weiterspringt oder wenn es überblendet wird über zwei Blöcke schmiert. Ob das mit 25 oder 35fps passiert, das ist sowas von Wurst. Da ist es wesentlich wichtiger ein PWM Auflösung der Pixel von 10 Bit zu haben, damit Farbverläufe sanft sind. > Tim R. schrieb: >> P.S.: Kommt es mir nur so vor oder wird es hier langsam ein wenig >> kuddel muddel von den Themen... wie wäre es mit einem kurzen >> Schlachtplan für die weiteren Besprechungen ? ;-) Es müsste mal jemand durchgehen und die wesentlichsten Fakten, Entscheidungen, Kontroversen rausschreiben. > Mach einen Vorschlag ;). Bis zum ersten Prototyp ist das wohl alles - > mehr oder weniger - eine Sammlung von Ideen und Anforderungen. Ja, es bräuchte jetzt eine konkrete Implementation von mindestens 3x3....
Frank M. schrieb: > Nehmen wir nun 100 Slaves an und 3 Bytes für jeden RGB-Wert. Dann sind > das 3000 zu übertragene Bytes. Sorry, ich habe falsch gerechnet. Es sind natürlich nur 300 Bytes und damit ist die Übertragungsdauer 0,026 Sekunden + 100/11520 = 0,026 + 0,008 = 0,034 Sekunden. Also sind doch ca. 30 Frames pro Sekunde drin. Ich nehme daher alles zurück - auch wenn es bei 200 Slaves dann "nur" noch 15 Frames pro Sekunde sind.
Frank M. schrieb: > Ich finde, Karol macht einen kleinen Denkfehler beim UART-Ring. Selbst > bei einer Übertragungsrate von 115200 Baud sind es bei 8 Bit / no parity > insgesamt 10 Bits (inkl. Start-/Stop-Bit) pro Byte. > > Damit beträgt die Übertragungsrate 11520 Byte/sec. > > Nehmen wir nun 100 Slaves an und 3 Bytes für jeden RGB-Wert. Dann sind > das 3000 zu übertragene Bytes. Die Übertragung vom Master aus dauert > dafür minimal 3000/11520 = 0,26 Sekunden. Damit kommt man auf ca. 4 > Frames pro Sekunde. Hinzu kommen noch Verzögerungen bis zum letzten > Slave, weil die Bytes immer erst weitergereicht werden können, wenn sie > auch komplett empfangen wurden. Der letzte Slave erhält seine Daten also > um einiges später, nämlich mindestens um 100/11520 Sekunden - auch wenn > die Daten des letzten Slaves als erstes geschickt werden würden. > > Mit meinem intelligenten Protokoll (zusammen mit dem UART-Bus statt > Ring), wo nur die Unterschiede gesendet werden brauchen, reduziert sich > die zu übertragene Datenmenge erheblich. Genauso arbeiten > Video-Komprimierungen, welche die Datenmenge auf durchschnittlich ein > Zehntel herunterdrücken. > > Es ist auch kein Problem, für den Master eine Funktion zu schreiben, die > einen Soll-Framebuffer übergeben bekommt und dann anhand des > Ist-Framebuffer-Inhalts nur die Unterschiede (in Blöcken > zusammengefasst) überträgt. Was ist daran kompliziert? Der > Anwenderprogrammierer füllt einen Framebuffer, ruft die Send-Funktion > auf, diese ermittelt die Diffs zum Ist-Zustand und überträgt dann nur > die Unterschiede. Da braucht der Programmierer einer Anwendung für den > Tisch sich überhaupt keinen Kopf drum zu machen. Das ist easy. Zusammen > mit der Fade-Intelligenz in den Slaves kann das alles noch geglättet > werden. Da ruckelt dann nix mehr. Die Slave-Funktionen dafür habe ich > fix und fertig. Da muss nichts mehr neu erfunden werden noch bereitet es > irgendeinem Kopfzerbrechen. Wenn der Anwender-Programmierer das > Slave-Fading nicht nutzen will, benutzt er einfach als Fading-Zeitdauer > die Null und schon erscheint das neue Bild instantan. > > Wenn ich Lust und Zeit hätte, würde ich jetzt einfach mal 10 > Equinox-LED-Streifen zusammenlöten (10x15 = 150 ATtinys) und zeigen, > dass man damit sogar einfache Filme in Farbe zeigen kann, wobei > Farbwechsel von bestimmten Pixeln sacht ablaufen und die ATtinys damit > sogar Zwischenbilder "berechnen" und damit Bewegungen viel flüssiger > ablaufen. > > Mit einer Komplettübertragung eines Frames über UART bekommt man das > nicht hin, siehe oben. > > Aber wie immer bei solchen Projekten: Dutzende reden, bis irgendwann > einer anfängt und macht.... Hi Frank, Uart ist auch nur die Schnittstelle, genau genommen USI. Und damit kann man auch ein Protokoll wie SPI fahren. Oder so eins wie bei den WS2812 Streifen, da bin ich auch großer Fan von, das ist genial mit implizitem CLK und Latch durch Pause. Kennst die WS2812? Ein supereinfaches und echt mächtiges Prinzip, weil jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu kämpfen, jede LED schickt ein neues Signal. Schau Dir mal meine Protokollvorschlag hier an: http://www.mikrocontroller.net/articles/RGB_Touch_Matrix Das ist der Ws2812 Dausy Chain nachempfunden und es gibt auch mit 100 Slaves überhaupt kein Problem, Zitat: "Idealerweise hängen alle Slaves einfach an einem Strang als einfachstmögliche Konstellation - einfache Verkabelung, keine mehrfach-Einspeisung in der Software. Für einen 10x10 RGB-Touch-Tisch sind das 100 Slaves. Jeder hat 24 Bits zu bekommen, ergibt 2400 Bits. Mal Framerate von 25 ergibt 25 x 2.400 Bits = 60.000 Bits pro Sekunde. Vorsichtshalber betreiben wir den Bus mit 100 kBit, dann sind wir nicht in einem technisch kritischen Bereich und brauchen nur einen Strang. (Die WS2811 machen 800 kBit, also das 8-fache). 250 kbit sollten noch ebenso einfach machbar sein, dann kann auch ein 10x20 Tisch in einem Strang betrieben werden"
Frank M. schrieb: > Ich finde, Karol macht einen kleinen Denkfehler beim UART-Ring. Selbst > bei einer Übertragungsrate von 115200 Baud sind es bei 8 Bit / no parity > insgesamt 10 Bits (inkl. Start-/Stop-Bit) pro Byte. Wieso rechnest du mit 115200 Baud ;)? Laut Datenblatt des ATtiny841 sind auch deutlich mehr drin. Bei 20 MHz Oszillatorfrequenz sogar bis zu 2.5 Mbit/s (bei 0% relativem Fehler!). Insofern sollte das rein von der Datentransferrate weniger das Problem werden. Latenz und gleichzeitige Anzeige der übergebenen Daten ist ein anderes Problem, das hängt aber davon ab wie genau man das aufbaut. Conny G. schrieb: > Ein supereinfaches und echt mächtiges Prinzip, weil > jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu > kämpfen, jede LED schickt ein neues Signal. Wobei das bei uns ja in Software (und wahrscheinlich Interrupt basiert?) geschehen würde. Dadurch kann es zu Schwankungen im Timing kommen, die umso größer werden, umso länger die Kette ist. Oder sehe ich das falsch? Conny G. schrieb: > dann kann auch ein 10x20 Tisch in einem > Strang betrieben werden" Ich ziele irgendwie trotzdem immer noch 20x20 an. Das entspricht bei 5x5 cm großen Pixeln gerade mal 1x1 m. Und deine Rechnung sieht auch noch nicht die Touchwerte vor, oder? Sind ja auch nochmal (mindestens) ein Byte pro Pixel? Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Conny G. schrieb: >> Ein supereinfaches und echt mächtiges Prinzip, weil >> jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu >> kämpfen, jede LED schickt ein neues Signal. > > Wobei das bei uns ja in Software (und wahrscheinlich Interrupt basiert?) > geschehen würde. Dadurch kann es zu Schwankungen im Timing kommen, die > umso größer werden, umso länger die Kette ist. Oder sehe ich das falsch? Kommt darauf an wieviel die Verzögerung ist und ob das wirklich stört. Sagen wir mal ein Slave braucht bei 20 MHz 200 Takte zur Verarbeitung und zum Weitersenden. Halte das aber für zuviel. Denn wenn ich weiß ich hab meine Daten und muss nur auf den Ausgang schalten, was ich bekomme dann sind keine 2 Dutzend Takte. Bei 200 Takten hätten wir 10us Verzögerung bei jedem Slave, bei 100 Slaves 1ms. Das Latch bei den Ws2812 ist eine Pause von mind. 50us. Jetzt wäre die Frage, ob diese Verzögerung ein Problem für die Latchpause ist. Eigentlich dürfte das nicht so sein, es kommt die Pause zwar 1ms später hinten an, aber der Abstand der Bits muss sowieso gleich bleiben, sonst klappt das Protokoll im Ansatz nicht. Bei 20 Takten Verzögerung pro Slave sind wir bei 100us Verzögerung beim 100sten Slave. Beides sieht man nicht. Wenn also die Abstände der Bits bei jedem Slave gleich bleiben, dann ist auf jeden Fall alles gut. > Conny G. schrieb: >> dann kann auch ein 10x20 Tisch in einem >> Strang betrieben werden" > > Ich ziele irgendwie trotzdem immer noch 20x20 an. Das entspricht bei 5x5 > cm großen Pixeln gerade mal 1x1 m. Und deine Rechnung sieht auch noch > nicht die Touchwerte vor, oder? Sind ja auch nochmal (mindestens) ein > Byte pro Pixel? Wir haben doch eine Tx Chain und eine Rx Chain, die gleichzeitig laufen, also braucht der Rückkanal gar keine extra Zeit.
:
Bearbeitet durch User
Karol Babioch schrieb: > Laut Datenblatt des ATtiny841 sind > auch deutlich mehr drin. Bei 20 MHz Oszillatorfrequenz Der ATtiny841 ist nur bis 16MHz spezifiziert. Und das erfordert einen externen Takt bzw. Quarz.
Conny G. schrieb: > Wir haben doch eine Tx Chain und eine Rx Chain, die gleichzeitig laufen, > also braucht der Rückkanal gar keine extra Zeit. Richtig, ich vergaß. Macht die Aufteilung in zwei Ringe deiner Meinung nach dann noch Sinn? Die ATtiny841 jedenfalls haben jeweils zwei Hardware Module ;). Konrad S. schrieb: > Der ATtiny841 ist nur bis 16MHz spezifiziert. Und das erfordert einen > externen Takt bzw. Quarz. Dann sollte man Atmel mal darauf hinweisen, dass die entsprechenden UBRR Tabellen darüber hinaus gehen ;). Habe gar nicht überprüft, ob die vorgeschlagenen Werte überhaupt möglich bzw. spezifiziert sind. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Dann sollte man Atmel mal darauf hinweisen Hm, ja, das Datenblatt da noch ein paar Inkonsistenzen. Das Maximum ist wohl 16MHz mit Quarz.
Karol Babioch schrieb: > Conny G. schrieb: >> Wir haben doch eine Tx Chain und eine Rx Chain, die gleichzeitig laufen, >> also braucht der Rückkanal gar keine extra Zeit. > > Richtig, ich vergaß. Macht die Aufteilung in zwei Ringe deiner Meinung > nach dann noch Sinn? Die ATtiny841 jedenfalls haben jeweils zwei > Hardware Module ;). Wie meinst Du das? > Konrad S. schrieb: >> Der ATtiny841 ist nur bis 16MHz spezifiziert. Und das erfordert einen >> externen Takt bzw. Quarz. > > Dann sollte man Atmel mal darauf hinweisen, dass die entsprechenden UBRR > Tabellen darüber hinaus gehen ;). Habe gar nicht überprüft, ob die > vorgeschlagenen Werte überhaupt möglich bzw. spezifiziert sind. > > Mit freundlichen Grüßen, > Karol Babioch
Conny G. schrieb: > Wie meinst Du das? Willst du die Daten nur von einer Seite einspeisen, oder würde es Sinn machen dies von zwei Seiten zu tun, die Bandbreite zu verdoppeln und die Latenz zu halbieren. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> Wie meinst Du das? > > Willst du die Daten nur von einer Seite einspeisen, oder würde es Sinn > machen dies von zwei Seiten zu tun, die Bandbreite zu verdoppeln und die > Latenz zu halbieren. Gleiches wie vorher: so einfach wie geht. Also nur einmal einspeisen, solange sich nicht der Bedarf für mehr auftut.
Hi Conny, Conny G. schrieb: > Hi Frank, > > Uart ist auch nur die Schnittstelle, genau genommen USI. > Und damit kann man auch ein Protokoll wie SPI fahren. Weiß ich :-) > Oder so eins wie bei den WS2812 Streifen, da bin ich auch großer Fan > von, das ist genial mit implizitem CLK und Latch durch Pause. > Kennst die WS2812? Ein supereinfaches und echt mächtiges Prinzip, weil > jede LED das Signal aktiv weitergibt, also hat man nicht mit Buslänge zu > kämpfen, jede LED schickt ein neues Signal. Ja, das Prinzip gefällt mir auch. Soviel ich aber weiß, können die Dinger nur 8Bit-PWM pro Farbe. Das ist der einzige Grund, warum ich sie bisher nicht mag. Als ich damals die Equinox-Streifen entwarf, waren die WS-Dinger auch noch ein Vielfaches teurer als heute. Zum zweiten ist das Timing bei den WS2812-LEDs recht eng gehalten. > Schau Dir mal meine Protokollvorschlag hier an: > http://www.mikrocontroller.net/articles/RGB_Touch_Matrix Mach ich. > Das ist der Ws2812 Dausy Chain nachempfunden und es gibt auch mit 100 > Slaves überhaupt kein Problem, Zitat: Ja, ich hatte mich gestern abend um einen Faktor 10 verrechnet. Man schafft bei 115200 Baud und 100 Slaves tatsächlich 30 fps. Sorry. Das (minimale) Latenzproblem, dass der letzte Slave seine Daten zeitversetzt erhält, könnte man übrigens lösen, indem man die Framebuffer-Daten "rückwärts" schickt, d.h. die Daten für den letzten Slave werden als erstes losgeschickt. Damit minimiert man die Zeitdifferenzen. Aber wahrscheinlich sind diese sowieso nicht sichtbar - jedenfalls nicht bei 100 Slaves. Ausserdem müssten die Slaves dann wissen, wie lange die Daisy-Chain ist. Macht alles nur komplizierter. Gruß, Frank
:
Bearbeitet durch Moderator
Ich habe mich mal schlau gemacht, was es für verschiedene Touchsensor-Techniken gibt. Dabei ist mir die FTIR-Technik über den Weg gelaufen: http://www.cs.nyu.edu/~jhan/ftirsense/ Das Prinzip beruht darauf, dass eine Berührung an einer bestimmten Stelle auf einer Acryl-Glasscheibe eine Totalreflektion verhindert und so ein Austritt des seitlich eingespeisten Lichts ermöglicht. Man muss also nur seitlich an der Scheibe ein paar IR-LEDs anbringen, welche erstmal wegen der Totalreflektion ein IR-Licht erzeugen, welches normalerweise "innerhalb" der Scheibe verbleibt. Drückt man nun mit dem Finger auf eine Zelle, wird an dieser Stelle das IR-Licht auf den IR-Sensor fallen. Wahrscheinlich geht das sogar besser als mit den Sensoren, die in dem oben genannten Tisch-Video eingesetzt wurden. Dort muss eine Zelle fast komplett mit der Hand abgedeckt werden, damit der Sensor anspricht. Bei FTIR könnte eventuell schon ein Finger ausreichen. Es ist also gar nicht notwendig, dass jeder Slave einen eigenen IR-Sender hat, er braucht nur einen Empfänger. Ist das seitlich eingespeiste IR-Licht moduliert, könnte es mit TSOPs als Empfänger sehr gut klappen. Fragt sich nur, ob das auch mit Milchglas oder nur mit Acrylglas geht. Probieren geht da über studieren ;-)
Klasse Idee, ich hatte mal an so etwas ähnliches mit Lichtschranken gedacht aber mit IR ist natürlich auch super! Ich sehe dabei nur das Problem, was passiert wenn die Scheibe sich irgendwann "durchbiegt"... hier reichen ja Millimeter bereits aus um dem IR einen falschen Weg zu weisen oder nicht?! Hab jetzt keine Angaben dazu gefunden, aber kann man dazu wirklich "stink normale" IR LEDs nutzen? reichen die dafür aus? Müsste man mal erforschen... aber an sich gefällt mir diese Technik mega gut ! sehr schöner Beitrag ! :-)
Hi Frank, das ist allerdings ziemlich cool, günstig und effizient! Für Anwendung bei den Tisch fallen mir dazu zwei Dinge ein: Ich wünsche mir ja auch die Erkennung von Annäherung, das ginge damit nicht. Das funktioniert wohl über den Fettfilm des Fingers bzw die spezifischen Eigenschaften der Haut - den Glibberfaktor (wie nennt man das wissenschaftlich :-) ) - d.h. die Haut verbindet sich ein wenig mit der Oberfläche und bricht so die Reflexion. Das würde dann wahrscheinlich mit Tassen, Gläsern etc nicht funktionieren und das ist einer Dinge, die man mit dem Tisch machen kann: die Farbe wechseln wo etwas abgestellt wird.
asterix schrieb: > Ich sehe dabei nur das Problem, was passiert wenn die Scheibe sich > irgendwann "durchbiegt"... hier reichen ja Millimeter bereits aus um dem > IR einen falschen Weg zu weisen oder nicht?! Die Platte wird ja wohl auf einem zellenförmigen Gebilde liegen und nicht frei in der Luft hängen. Von daher wird auch nichts durchbiegen. > Hab jetzt keine Angaben dazu gefunden, aber kann man dazu wirklich > "stink normale" IR LEDs nutzen? reichen die dafür aus? Ich sehe bei FTIR-Beschreibungen immer nur stinknormale LEDs. Aber ich nehme mal an, dass dasselbe Prinzip auch für IR-Licht funktioniert. Hätte den Vorteil, dass man TSOPs benutzen kann und sich damit unabhängig vom Umgebungslicht macht. Ich werde das die Tage testen.
Conny G. schrieb: > Das funktioniert wohl über den Fettfilm des Fingers bzw die spezifischen > Eigenschaften der Haut - den Glibberfaktor (wie nennt man das > wissenschaftlich :-) ) - d.h. die Haut verbindet sich ein wenig mit der > Oberfläche und bricht so die Reflexion. > Das würde dann wahrscheinlich mit Tassen, Gläsern etc nicht > funktionieren und das ist einer Dinge, die man mit dem Tisch machen > kann: die Farbe wechseln wo etwas abgestellt wird. Das müsste man untersuchen. Der Thread hier heißt ja auch ursprünglich Gegenstandserkennung. Ohne eine Tasse oder Ähnliches erkennen zu können wäre doch etwas schade... für den Touch mit Händen wäre es sehr genial
Hi Conny, Conny G. schrieb: > Ich wünsche mir ja auch die Erkennung von Annäherung, das ginge damit > nicht. Nein, es muss ein direkter Kontakt mit der Platte hergestellt werden. > Das würde dann wahrscheinlich mit Tassen, Gläsern etc nicht > funktionieren und das ist einer Dinge, die man mit dem Tisch machen > kann: die Farbe wechseln wo etwas abgestellt wird. Das müsste man erstmal ausprobieren. Ich glaube nicht, dass es das Fett auf den Fingern ist. Dort, wo ein Gegenstand die Platte berührt, ändert sich der Brechungsindex des Materials. Das Licht wird dann nicht mehr an der Oberfläche totalreflektiert, sondern vom Gegenstand darüber in einem anderen Winkel, so dass das Licht dann nach unten austreten kann. Es sollte daher auch mit normalen Gegenständen wie Kaffeetassen gehen. Wie gesagt: Ich teste das. Ich habe zuhause wg. IRMP genügend IR-Dioden, TSOPs und auch noch irgendwo eine Acryglasscheibe rumfliegen. Wenn Du wirklich Annäherungen erkennen willst, dann wirds echt aufwändig. Wie wärs mit 2 Webcams an der Decke oberhalb des Tisches? ;-)
:
Bearbeitet durch Moderator
Wie deine Acrylglasscheibe beschaffen ist wäre dann auch interessant zu wissen Das Problem ist, dass die Vorstellungen nun etwas auseinander gehen. So wie ich die Resonanz hier festgestellt habe ist ein "richtiges Touch" erwünscht und keine >3cm Objekterkennung. Man müsste dann nach dem Test von Frank M. genau abgrenzen in welche Richtung das ganze laufen soll :-)
Angehängte Dateien:
Frank M. schrieb: > Dabei ist mir die FTIR-Technik über den Weg gelaufen: Interessant. Das Konzept klingt logisch und gefällt mir gut. Andererseits beeinflusst das auch die Tischkonstruktion, weil die Seiten nicht mehr den Abschluss bilden können. Frank M. schrieb: > Man muss also nur seitlich an der Scheibe ein paar IR-LEDs anbringen, > welche erstmal wegen der Totalreflektion ein IR-Licht erzeugen, welches > normalerweise "innerhalb" der Scheibe verbleibt. Zum Anbringen von LEDs an der Seite würden sich ggf. die Halterungen anbieten, welche man normalerweise bei Glasbodenbeleuchtungen erhält: Hab da mal was angehängt. Quelle: [1] Müsste man halt sehen, ob man IR-LEDs in dem benötigten Formfaktor kaufen kann und wie viele man braucht (je nach Abstrahlwinkel?). Frank M. schrieb: > Wenn Du wirklich Annäherungen erkennen willst, dann wirds echt > aufwändig. Wie wärs mit 2 Webcams an der Decke oberhalb des Tisches? ;-) Dann lieber Xbox Kinect ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://www.lidl.de/media/product/0/0/6/1/1/8/5/livarno-lux-led-glasbodenbeleuchtung-regular--1.jpg
Wieviele IR-LEDs pro Pixelreihe würde man ungefähr benötigen?
asterix schrieb: > Wieviele IR-LEDs pro Pixelreihe würde man ungefähr benötigen? Das kommt ganz auf die Glasplatte an und den Abstrahlwinkel der IR-LEDs an, hält sich aber stark in Grenzen (~3 pro Seite?).
asterix schrieb: > Wieviele IR-LEDs pro Pixelreihe würde man ungefähr benötigen? Das würde ich nicht "pro Pixelreihe", sondern eher "pro Tisch" bestimmen. Die LEDs senden sowieso alle dasselbe, müssen also nicht einzeln angesteuert werden. Ich habe mal ein paar Links zu Selbstbau-Touch-Scheiben auf FTIR-Basis zusammengetragen: http://www.larrystendebach.com/windows-7-multi-touch-table-ftir-diy/ http://sethsandler.com/multitouch/ http://www.maximumpc.com/article/features/build_your_own_multitouch_surface_computer Meist werden ca. 24 IR-LEDs an beiden kurzen Seiten verwendet - meist einfach in Reihe geschaltet. Als IR-Sensor wird eine Webcam verwendet, welche mit einem Tageslichtfilter versehen wird, damit nur das IR-Licht an der Webcam ankommt. Die Demos sind echt beeindruckend. Da muss ich mir echt überlegen, ob ich einen LED-Tisch mit 20x10 oder doch direkt einen Tisch in HD-Auflösung baue. Tetris kann man jedenfalls mit beiden Lösungen spielen ;-)
:
Bearbeitet durch Moderator
Frank M. schrieb: > Meist werden ca. 24 IR-LEDs an beiden kurzen Seiten verwendet - meist > einfach in Reihe geschaltet. Puh doch so viel ;). Bei deiner Idee mit TSOPs müssten die ja alle synchron laufen, um vom TSOP detektiert werden zu können? Klar, man kann, wie gesagt, alle in Reihe schalten :). Und wie sieht es mit Gegenstandserkennung aus? Bist du da zufällig schon über Bilder/Videos gestoßen? Ich seh immer nur Finger und Hände ;). Mit freundlichen Grüßen, Karol Babioch
was mir noch gerade eingefallen ist... Multitouch? Wenn am Anfang der Reihe der Strahl reflektiert wird, können die dahinter folgendenden nicht per Touch angesteuert werden, das heißt man stellt sie mehr oder weniger stumm... oder wie sieht dafür die Lösung aus? Ich werde mir mal geich die Links zu gemüte führen
asterix schrieb: > Ich werde mir mal geich die Links zu gemüte führen Schau dir die Links doch einmal an ;). Man kann jeden einzelnen Finger einer Hand detektieren. Hängt wohl auch damit zusammen, dass man viele LEDs hat ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Frank M. schrieb: >> Meist werden ca. 24 IR-LEDs an beiden kurzen Seiten verwendet - meist >> einfach in Reihe geschaltet. > > Puh doch so viel ;). Bei deiner Idee mit TSOPs müssten die ja alle > synchron laufen, um vom TSOP detektiert werden zu können? Klar, man > kann, wie gesagt, alle in Reihe schalten :). Eben, alle in Reihe oder mehrere Reihen als Gruppen an einem MosFet. Die IR-LEDs kosten nur ein paar Cent. Selbst bei 48 Stück sind es nur um die 15 EUR. > Und wie sieht es mit Gegenstandserkennung aus? Bist du da zufällig schon > über Bilder/Videos gestoßen? Ich seh immer nur Finger und Hände ;). Leider nein. Ich sehe auch immer nur Finger. Im ersten Video sieht man aber kurz ein Handy auf dem Tisch liegen, was eine Wellenbewegung des Bildes auslöst. Ob das echt ist? Muss man wohl ausprobieren.
Ich habe mittlerweile auch mindestens ein Video gesehen, wo Gegenstände erkannt werden. Zum Beispiel kleine 5x5cm große klare Plexischeiben, die man auf den Tisch legt. Sofort wird auf diesen Scheiben ein kleines Video abgespielt. Verschiebt man die Scheiben auf dem Tisch, wandert das Video immer mit, d.h. es sieht so aus, als wäre die kleine Plexischeibe ein eigenes Display. Andere Gegenstände, die ich gesehen habe: Handys und Kreditkarten, die auf dem Tisch abgelegt bzw. verschoben und erkannt werden. Will ich auch haben! Dagegen wirkt ein 20x10 LED-Tisch wie ein Oldtimer aus dem letzten Jahrhundert.... wenn man's doch "Old-Style" haben möchte, kann man ja einen 20x10 LED-Tisch per Software projezieren ;-)))
das ganze per Beamer etc. löst sich dann aber vom eigtl. Thema etwas ab und stellt ein eigenes Projekt da ;-)
Frank M. schrieb: > Will ich auch haben! Dagegen wirkt ein 20x10 LED-Tisch wie ein Oldtimer > aus dem letzten Jahrhundert.... wenn man's doch "Old-Style" haben > möchte, kann man ja einen 20x10 LED-Tisch per Software projezieren ;-))) Entführt da jemand den Thread? :-)
Conny G. schrieb: > Entführt da jemand den Thread? :-) Keine Angst, ich hatte nur gerade einen kleinen Begeisterungsanfall :-) Also wie gesagt, ich werde das mal mit ein paar IR-Dioden und einem TSOP und einer Scheibe testen. Sollte mich tatsächlich das Fieber gepackt haben, einen Full-HD-Tisch zu bauen, werde ich dafür einen eigenen Thread aufmachen.
Frank M. schrieb: > Keine Angst, ich hatte nur gerade einen kleinen Begeisterungsanfall :-) Den hast du uns denk ich gerade allen verpasst, ich finde die Technik sehr gut :-)) > Also wie gesagt, ich werde das mal mit ein paar IR-Dioden und einem TSOP > und einer Scheibe testen. Kannst du das evtl. zeitlich eingrenzen, wann man dort mit Ergebnissen rechnen kann?!
http://www.lowres.ch/ftir/ hier sieht man, dass relativ viele LEDs zum Einsatz kommen... also mit mindestens 3 pro Reihe (10x10) müsste man denke ich schon rechnen
Tim R. schrieb: >> Also wie gesagt, ich werde das mal mit ein paar IR-Dioden und einem TSOP >> und einer Scheibe testen. > Kannst du das evtl. zeitlich eingrenzen, wann man dort mit Ergebnissen > rechnen kann?! Ich habe dafür frühestens am nächsten Wochenende Zeit. Mittlerweile ist aber nach ausführlicher Lektüre diverser Dokumentationen/Anleitungen mein Enthusiasmus etwas gedämpft: Der FTIR-Effekt ist nur einigermaßen vernünftig messbar, wenn man auf die Acryl-Scheibe noch ein paar Schichten einer Silikon-Mischung aufträgt. Dies verstärkt den FTIR-Effekt. Ich weiß nicht, ob dieser Aufwand für einen LED-Tisch nicht zu hoch ist: Die Anzahl der nötigen LEDs wächst zwar nur linear mit den Ausmaßen des Tisches (während die Anzahl der LEDs bei einer pro Zelle quadratisch wächst), aber bei 10x10 oder auch 10x20 spart man da gar nicht soviel ein - falls überhaupt. Es gäbe auch noch die Möglichkeit, die IR-LEDs ein paar Millimeter über dem Tisch anzubringen, also Lichtschranken (horizontal und vertikal) zu spannen. Dann könnte man die Position von Fingern und Gegenständen schon schwebend über dem Tisch ermitteln. Das macht aber dann eine aufwändige Rahmenkontruktion notwendig und sieht bestimmt nicht so schön aus wie ein planer Glastisch. Also die Sensor-Geschichte ist noch nicht ausgestanden. Wahrscheinlich ist es doch am einfachsten, in jede Zelle unterhalb des Tisches eine IR-LED zu stopfen und dann eine Reflektion zu messen, wenn jemand etwas drauflegt. Aber hier mal Frage an Conny und Karol: Euch ist schon bewusst, dass ein LED-Tisch mit 10x20 sehr grobkörnig ist und eine abgestellte Kaffeetasse im Normalfall nicht genau über einer LED abgestellt wird und damit evtl. Nachbar-LEDs oder gar keine anspringen, um die Kaffeetasse von unten zu beleuchten? Ich halte den Sinn eines solchen Tisches mittlerweile für ziemlich fragwürdig. Es ist eine nette Spielerei, keine Frage.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Aber hier mal Frage an Conny und Karol: Euch ist schon bewusst, dass ein > LED-Tisch mit 10x20 sehr grobkörnig ist und eine abgestellte Kaffeetasse > im Normalfall nicht genau über einer LED abgestellt wird und damit evtl. > Nachbar-LEDs oder gar keine anspringen, um die Kaffeetasse von unten zu > beleuchten? Ich halte den Sinn eines solchen Tisches mittlerweile für > ziemlich fragwürdig. Es ist eine nette Spielerei, keine Frage. Ja, der Tisch ist völlig sinnfrei - das war die Ausgangslage :-) Ist wirklich nur eine coole Spielerei und die groben Zellen sind eigentlich ein schöner Charakterzug so eines Tisches. Man darf es nicht aus der Ecke: Multitouch-Tisch mit Projektor darunter betrachten, der ja schon als Arbeitsgerät durchgeht. Sondern eher als gepimptes, interaktives RGB-beleuchtetes Kunstobjekt mit Wow-Effekt - wenn man die Spiele und Animationen damit machen kann. Genau aus dem Grund ist es interessant durch clevere Lösungen die Konstruktion in Kosten und Bauzeit einigermassen effizient zu machen - denn was der hier http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html an Aufwand abgefackelt hat (man sehe sich die Verkabelung und die Hauptplatine an - enorm aufwändig), das ist nicht für jedermann :-) Ich find so einen Tisch echt witzig und cool - aber nicht für 1.000 Euro und Monate Bauzeit. Muss jetzt auch kein Schnäppchen werden, aber für 300-400 Euro und ein paar Wochenenden Bauzeit ist es schon ok. Da steckt dann noch genug Arbeit in der Software um die Coolness wirklich freizusetzen. Sowas wie das hier: http://www.solderlab.de/index.php/led-projects/true-color-matrix (Mosaik-Variante unten) ist auch funktionell völlig sinnfrei - aber man darf es nicht als missglückten "Screen" sehen, sondern als RGB Kunstwerk. (Sowas bau ich mir auch irgendwann noch... :-) )
:
Bearbeitet durch User
Conny G. schrieb: > Man darf es nicht aus der Ecke: Multitouch-Tisch mit Projektor darunter > betrachten, der ja schon als Arbeitsgerät durchgeht. > Sondern eher als gepimptes, interaktives RGB-beleuchtetes Kunstobjekt > mit Wow-Effekt - wenn man die Spiele und Animationen damit machen kann. Jupp, sehe ich genau so. Klar wäre ein HD-Touch was schönes, aber dieses interaktive RGB Touch find ich hat seinen Scharm > Da steckt dann noch genug Arbeit in der Software um die Coolness > wirklich freizusetzen. Satz des Tages! :-D Ich würde sagen, dass nach den ersten Tests mit dieser Technik (ohne gesonderdes Acryl) man entcheiden kann, wie es weiter geht.
Conny G. schrieb: > Ja, der Tisch ist völlig sinnfrei - das war die Ausgangslage :-) Gut, dann sind wir uns ja einig :-) > Ist wirklich nur eine coole Spielerei und die groben Zellen sind > eigentlich ein schöner Charakterzug so eines Tisches. Stimmt schon. Ich muss nur das HD-Dingens da aus meinen Gedanken verbannen ;-) > Sowas wie das hier: > http://www.solderlab.de/index.php/led-projects/true-color-matrix > (Mosaik-Variante unten) ist auch funktionell völlig sinnfrei - aber man > darf es nicht als missglückten "Screen" sehen, sondern als RGB > Kunstwerk. > (Sowas bau ich mir auch irgendwann noch... :-) ) Sowas ist mit den Equinox-Streifen kein Problem, mit 32 Stück hast Du zwar nur 32x15 statt 32x16, aber was da im Video abgeht, mache ich mit nur einem ATmega168 als Master.
Den RGB-Touch Tisch kann man auch als normalen Tisch verwenden. Ist der Beamer-Tisch dazu geeignet?!
asterix schrieb: > Den RGB-Touch Tisch kann man auch als normalen Tisch verwenden. Ist der > Beamer-Tisch dazu geeignet?! Das ist die Frage. Wegen der Rückprojektionsfolie und der Silikonschicht zwischen der Acryglasplatte und der Folie wahrscheinlich nicht. Und deswegen scheidet für mich FTIR als Sensor-Möglichkeit für den LED-Tisch mittlerweile auch ziemlich aus. Überlege mir, ob ich den FTIR-Test überhaupt noch machen sollte und nicht besser testen soll, ob eine Hand über einer kratzfesten Milchglasplatte genügend IR-Licht (das von unten kommt) reflektiert, dass ein TSOP anspricht, also: Hand/Finger ----------------------- Glasplatte ^ ^ IR-LED TSOP Und dann noch die Frage: Was passiert ohne Hand? Wenn man Pech hat, reflektiert die Glasplatte dann immer noch. In dem Fall müsste man die Modulationsfrequenz soweit in/aus den Grenzbereich des TSOPs fahren, dass dieser gerade eben nicht anspricht. Das wäre quasi eine Kalibrierung, die der Slave nach dem Booten als erstes machen könnte.
Frank M. schrieb: > > Das ist die Frage. Wegen der Rückprojektionsfolie und der Silikonschicht > zwischen der Acryglasplatte und der Folie wahrscheinlich nicht. Und > deswegen scheidet für mich FTIR als Sensor-Möglichkeit für den LED-Tisch > mittlerweile auch ziemlich aus. Überlege mir, ob ich den FTIR-Test > überhaupt noch machen sollte Warum nicht, vllt funktioniert es ja auch ohne extra besondere Folie und Silikonschicht. > und nicht besser testen soll, ob eine Hand > über einer kratzfesten Milchglasplatte genügend IR-Licht (das von unten > kommt) reflektiert, dass ein TSOP anspricht, also: > > Hand/Finger > ----------------------- Glasplatte > ^ ^ > IR-LED TSOP > > Und dann noch die Frage: Was passiert ohne Hand? Wenn man Pech hat, > reflektiert die Glasplatte dann immer noch. In dem Fall müsste man die > Modulationsfrequenz soweit in/aus den Grenzbereich des TSOPs fahren, > dass dieser gerade eben nicht anspricht. Das wäre quasi eine > Kalibrierung, die der Slave nach dem Booten als erstes machen könnte. Was ist der Ziel des Tests? Ob die Milchglasplatte das hergibt, was gehofft wird?! Ist durchaus sinnvoll, wenn die meisten auf Plexiglas verzichten wollen. Hast du denn eine zumindest von den Eckdaten geeignete Platte?
Hallo Frank, mal ganz dumm gefragt, warum nutzt Du nicht die Wärmestrahlung des Menschens ( Infrarot im Bereich 7-14µm ) zur Erkennung der Annäherung der Hand. Gruss Roman
RomanK schrieb: > die Wärmestrahlung des Menschens Zu viele Einflussfaktoren: z.B. Sonnenschein, heiße Tee-Tasse auf dem Tisch, kalte Hände (gerade bei Frauen), urste Hitze im Sommer etc.
Frank M. schrieb: > Und dann noch die Frage: Was passiert ohne Hand? Wenn man Pech hat, > reflektiert die Glasplatte dann immer noch. Das war bei mir der Fall, ja. > In dem Fall müsste man die > Modulationsfrequenz soweit in/aus den Grenzbereich des TSOPs fahren, > dass dieser gerade eben nicht anspricht. Das habe ich nicht probiert, bin aber gespannt, ob das zuverlässig hinzubekommen ist. Unabhängig davon kommt meine oben vorgeschlagene Lösung mit nur einer IR-Photodiode aus und kostet 1/4 eines TSOPs. Allerdings stellt es sich als echtes Problem heraus entsprechende Glasmuster zu organisieren. Bei vielen Angeboten zahlt man für das bisschen benötigte Glas (15x15cm) 30 Euro aufwärts. Habe mittlerweile günstige Muster erhalten, die sind dafür dann aber nur 10x10cm und 4mm stark. Mit freundlichen Grüßen, Karol Babioch
RomanK schrieb: > mal ganz dumm gefragt, warum nutzt Du nicht die Wärmestrahlung des > Menschens ( Infrarot im Bereich 7-14µm ) zur Erkennung der Annäherung > der Hand. Weil der Tisch dann auch nur auf Mensch, Hund, Katze, Kaffee, Tee und heißen Amaretto reagiert und nicht auf: Wein, Bier, Schlüssel, Telefon etc. :-)
Karol Babioch schrieb: > Das habe ich nicht probiert, bin aber gespannt, ob das zuverlässig > hinzubekommen ist. Unabhängig davon kommt meine oben vorgeschlagene > Lösung mit nur einer IR-Photodiode aus und kostet 1/4 eines TSOPs. Wird aber aufwändiger von der Software. Du brauchst dann einerseits einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), andererseits brauchst Du einen verlässlichen Tageslichtfilter - geschrieben in Software. Wenn Du da was Gutes hast, dann lassen wir das mit dem TSOP.
Frank M. schrieb: > > Wird aber aufwändiger von der Software. Du brauchst dann einerseits > einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), Nana, kaum einer? Der Tiny25/45/85, 24/44/84 hat welche. Und sogar der 13er sollte ADC haben.
Frank M. schrieb: > Du brauchst dann einerseits > einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), Der ATtiny25/45/85 auch, sogar mit jeweils 4 Kanälen ;). Frank M. schrieb: > andererseits brauchst Du einen verlässlichen Tageslichtfilter - > geschrieben in Software. Das besteht derzeit aus der Differenz von zwei Messungen: Einmal mit und einmal ohne eingeschalteter IR-LED. Soweit auch schön und gut. Bin für neue Ideen/Konzepte offen, kann im Bereich Signalaufbereitung und -filterung sicher noch eine Menge lernen. Man müsste halt in erster Linie mal sehen, wie sich das in einem echten Prototypen verhält. Bisher stand mir nur durchsichtiges Floatglas zur Verfügung. Außerdem habe ich festgestellt, dass die verwendeten Photodioden (ELPD204-6B) ziemlich unterschiedliche Charakteristiken aufweisen. Um eine Kalibrierung wird man also nicht herum kommen. Ideen hierfür? Beim Einschalten unter der Annahmen, dass der Tisch "leer" ist, sollte das ja klappen, oder? Frank M. schrieb: > Wenn Du da was Gutes hast, dann lassen wir das mit dem TSOP. Will dich nicht vom experimentieren abhalten. Interessieren würde es mich auch. TSOPs und IR-LEDs müsste ich auch noch über haben. Wie genau hast du dir das Softwaretechnisch vorgestellt? Nach dem Einschalten solange die Frequenz erhöhen, bis der TSOP low zurückliefert? In welchen Schritten? Gehst du davon aus, dass eine einmalige Kalibrierung dieser Art reicht, oder muss man das (während der Laufzeit?) ggf. öfters tun, wenn sich das Umgebungslicht und ähnliche Faktoren ändern? Habe den TSOP nie in so einer kreativen Art und Weise eingesetzt. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Frank M. schrieb: > Karol Babioch schrieb: >> Das habe ich nicht probiert, bin aber gespannt, ob das zuverlässig >> hinzubekommen ist. Unabhängig davon kommt meine oben vorgeschlagene >> Lösung mit nur einer IR-Photodiode aus und kostet 1/4 eines TSOPs. > > Wird aber aufwändiger von der Software. Du brauchst dann einerseits > einen ADC (hat kaum ein ATTiny (okay der 841 hat einen ;-) )), > andererseits brauchst Du einen verlässlichen Tageslichtfilter - > geschrieben in Software. > > Wenn Du da was Gutes hast, dann lassen wir das mit dem TSOP. Da hätte ich ein Modell dafür im Kopf: IR-LED pulst mit 10, 20 oder 30 kHz. ADC misst die Photodiode mit der doppelten Frequenz, also 20, 40 oder 60 kHz und zwar genau in der Mitte von "IR-LED an" und in der MItte von "IR-LED aus". Damit gibt es eine Differenz zwischen der Messung "IR-LED an" und der Messung "IR-LED aus" (Tageslicht). Das ist die Basis-Kalibrierung, die jeder einzelne Pixel dynamisch als Referenz mitführt als Durchschnitt über x Messungen. Hält nun jemand die Hand darüber, steigt die IR-Lichtstärke bei der "IR-LED An"-Messung und wir sehen ein Annäherungsevent, ab einer gewissen Schwelle. D.h. der analoge Touch-Wert, den jeder Pixel an den Master senden wäre die Änderung dieser Differenz. Also bei gleichbleibenden Verhältnissen, ohne Berührung oder Annäherung, senden wir "0". Bei Annäherung denjenigen Betrag, den wir bei "IR An" hinzugewinnen.
:
Bearbeitet durch User
bin mir nicht sicher, aber die Rechnung beinhaltet glaube ich nicht, dass wenn die Hand drüber gehalten wird, auch die Umgebungshelligkeit sinkt sprich die Differenz wird ein schwieriger Wert an dieser Stelle, weil beide Faktoren sich stetig ändern... oder denk ich gerade falsch?
oder doch... da durch wird die differenz größer und es sollte sogar leichter messbar sein, nicht?
Hallo Karol, was meinst Du genau, wenn Du schreibst, dass die Everlight Photodiode unterschiedlichen Charakteristiken hat? Die im Datenblatt enthaltene spektrale Empfindlichkeit ist auf jeden Fall physikalisch nicht realisierbar. Silizium "sieht" bis etwa 1120nm, dann ist Schluß. Im Datenblatt geht es bei Raumtemperatur bis 1300nm. Das ist Unfug. Gruß kokisan
Karol Babioch schrieb: > Der ATtiny25/45/85 auch, sogar mit jeweils 4 Kanälen ;). Sorry, ja, hatte das velwechsert mit den UARTs, die gerade bei den ATTinys so rar sind. Kommt daher, dass ich ADCs so gut wie gar nicht verwende. (Mein Leben verläuft also fast ausschließlich "digital" ;-) ) > Das besteht derzeit aus der Differenz von zwei Messungen: Einmal mit und > einmal ohne eingeschalteter IR-LED. Ob das reicht? Was passiert, wenn ich irgendeine FB drücke, um meinen Fernseher anzuwerfen? Was passiert, wenn ich das Licht im Raum anknipse, gerade dann, wenn irgendein ATTiny meint, er müsse gerade mal "mit"/"ohne" IR-LED die Hintergrundstrahlung messen? Was bedeutet das dann für Deine Sensor-Software? Was ist dann "ohne", was "mit"? Genau aus diesem Grund werden bei Lichtschranken und bei Fernbedienungen immer modulierte Signale genommen, um sich vom Umgebungslicht unabhängig zu machen. Schau Dir mal die Innenbeschaltung eines TSOPs an, dann weißt Du, was die da für einen Aufwand an Filterung treiben. Genau das müsste man in Software nachbilden. Mit je einer Messung "mit" und "ohne" ist es nicht getan. > Außerdem habe ich festgestellt, dass die verwendeten Photodioden > (ELPD204-6B) ziemlich unterschiedliche Charakteristiken aufweisen. Um > eine Kalibrierung wird man also nicht herum kommen. Ideen hierfür? Beim > Einschalten unter der Annahmen, dass der Tisch "leer" ist, sollte das ja > klappen, oder? Ja, beim Einschalten sollte der Tisch leer sein. > Will dich nicht vom experimentieren abhalten. Interessieren würde es > mich auch. TSOPs und IR-LEDs müsste ich auch noch über haben. Wie genau > hast du dir das Softwaretechnisch vorgestellt? Nach dem Einschalten > solange die Frequenz erhöhen, bis der TSOP low zurückliefert? Ja, genau so. Oder systematisch runter mit der Frequenz. > In welchen Schritten? In 4 kHz-Schritten, also z.B. 38, 42, 46, 50, usw. EDIT: Intervallschachtelung wäre hier sinnvoll: Also erst in großen Schritten. Wenn man dann eine Grenze gefunden hat, in kleineren Schritten nochmal nachmessen, bis man einen realen Wert gefunden hat und dann noch einen Sicherheitszuschlag drauf, also zum Beispiel: 32 -> 64 -> 50 -> 42 -> 46 -> 44 -> 45, dann plus 5. Resultat: 50. > Gehst du davon aus, dass eine einmalige Kalibrierung dieser > Art reicht, oder muss man das (während der Laufzeit?) ggf. öfters tun, > wenn sich das Umgebungslicht und ähnliche Faktoren ändern? Habe den TSOP > nie in so einer kreativen Art und Weise eingesetzt. Einmaliges Messen und Speichern des Wertes im EEPROM könnte reichen. Ändert man natürlich was an der Tischplatte (Höhe, Dicke, wasweissich), dann müsste man noch neu kalibrieren können. Ich nehme aber an, dass es nicht viel Zeit kostet, sicherheitshalber bei jedem Boot neu durchzumessen. Jede Messung dauert weniger als 1/10 Sekunde, nach spätestens einer Sekunde sollte die Angelegenheit erledigt sein. EDIT: Während des Betriebs muss wohl eher nicht neu kalibriert werden. Es ändert sich ja da nichts. TSOPs sind unabhängig von der Umgebungshelligkeit. Viele Grüße, Frank
:
Bearbeitet durch Moderator
Didi S. schrieb: > was meinst Du genau, wenn Du schreibst, dass die Everlight Photodiode > unterschiedlichen Charakteristiken hat? Der Spannungsverlauf schaut auf dem Oszilloskop für jede Diode anders aus, obwohl alle aus einer Charge sind. Didi S. schrieb: > Silizium "sieht" bis etwa 1120nm, > dann ist Schluß. Im Datenblatt geht es bei Raumtemperatur bis 1300nm. > Das ist Unfug. Das kann ich nicht bewerten. Frank M. schrieb: > Genau aus diesem Grund werden bei Lichtschranken und bei Fernbedienungen > immer modulierte Signale genommen, um sich vom Umgebungslicht unabhängig > zu machen. Gut, modularisieren wollte ich auch noch. Der Vorschlag von Conny gefällt mir gut, die IR-LED mit doppelter Frequenz zu betreiben. Dann kann man problemlos einmal "mit" und einmal "ohne" messen. Frank M. schrieb: > In 4 kHz-Schritten, also z.B. 38, 42, 46, 50, usw. Die Frage ist, ob das wiederum nicht zu grob ist. Kenne den TSOP und seine Empfangscharakteristiken nicht. Wie gesagt: Probier deine Idee ruhig mal aus, kann nicht schaden ;). Mit freundlichen Grüßen, Karol Babioch
Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger eignet. Es ist jetzt eine Weile her, daß ich ein entsprechendes Datenblatt gelesen habe, aber so ein moderner TSOP ist schon sehr gut auf seinen Einsatzzweck optimiert, nämlich das Datensignal des Senders zu detektieren, unabhängig von der Intensität mit der es ankommt, und so ein Verhalten können wir hier nicht ganz gebrauchen. Soweit ich mich erinnere, enthält der TSOP zwei AGC-Stufen: eine vor dem 40kHz-Filter und eine dahinter. Die erste verhindert, daß er von konstantem Umgebungslicht geblendet wird; die zweite verhindert, daß er von konstantem 40kHz-Störlicht (z.B. Energiesparlampe) geblendet wird. Und die zweite AGC-Stufe stört in dieser Anwendung, denn wir wollen ja unterscheiden können, wie stark das modulierte Signal des Senders beim TSOP ankommt, und genau das regelt die zweite AGC-Stufe weg. Da halte ich es für aussichtsreicher, das Filtern per Software zu machen, also den Unterschied zwischen dem Fotodiodensignal mit und ohne eingeschalteter IR-LED auszuwerten, um das Umgebungslicht rauszurechnen. Ich muß aber zugeben, daß ich keine praktischen Erfahrungen mit dem "Missbrauch" von TSOPs z.B. für Lichtschranken habe. Vielleicht gibt es ja noch welche ohne zweite AGC-Stufe; früher war es ja definitv so, daß Energiesparlampen so manche Fernbedienung lahmgelegt haben.
Nosnibor schrieb: > Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger > eignet. Ja, die Zweifel teile ich, lasse mich aber gerne vom Gegenteil überzeugen. In der Zwischenzeit arbeite ich weiter an meiner Photodioden Lösung. Die Detektierung ist robust, sogar mit einem 400-Watt Halogenstrahler im Raum ;) (Gibt es alternative Vorschläge für künstliche IR-Quellen?). Mein Pixel ist nach wie vor 5x5x3cm groß und das Ganze ist absolut unempfindlich gegenüber seitlichen Annäherungen. Das geht sogar soweit, dass einzelne Finger am Rand der Pixel nicht zuverlässig erkannt werden. Zwei Finger bzw. ein Finger in der Mitte hingegen funktionieren problemlos. Keine Ahnung, ob das so gewünscht ist, ändern kann man daran vermutlich nicht besonders viel. Annäherungen über dem Pixel sind ab etwa 5 cm über der Platte detektierbar. Einziger Wermutstropfen: Ich teste nach wie vor mit 2mm starken Floatglass. Das satinierte ist zwar auf dem Weg, braucht aber wohl noch ein bisschen. Insofern sind die vielversprechenden Ergebnisse mit Vorsicht zu genießen. Werde aber Photos bzw. ein Video erstellen, sobald ich einen "echten" Prototypen habe. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Nosnibor schrieb: >> Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger >> eignet. > > Ja, die Zweifel teile ich, lasse mich aber gerne vom Gegenteil > überzeugen. > > In der Zwischenzeit arbeite ich weiter an meiner Photodioden Lösung. Die > Detektierung ist robust, sogar mit einem 400-Watt Halogenstrahler im > Raum ;) (Gibt es alternative Vorschläge für künstliche IR-Quellen?). Fernbedienung? :-) > Mein Pixel ist nach wie vor 5x5x3cm groß und das Ganze ist absolut > unempfindlich gegenüber seitlichen Annäherungen. hast du denn neben dem Pixel auch eine IR-LED platziert, damit deine Hand diese Strahlen dann zum Sensor reflektieren kann? Oder hast du nur in dem einzelnen Pixel die IR-LED? Oder hast du allgemein mehrere Pixel? Wie sieht denn der Versuch in der Richtung aus > Das geht sogar soweit, > dass einzelne Finger am Rand der Pixel nicht zuverlässig erkannt werden. > Zwei Finger bzw. ein Finger in der Mitte hingegen funktionieren > problemlos. Das ist der oben erwähnte punktuelle Effekt. Die Sensorik+LED müsste wahrscheinlich wie Conny G. meinte noch weiter herunter gesetzt werden, um den Lichtkegel auf die Platte zu kriegen und nicht nur einen Bruchteil davon. Dann würde man evtl auch am Rand detektieren können
Karol Babioch schrieb: > Nosnibor schrieb: >> Ich habe Zweifel, ob sich ein TSOP in dieser Anwendung als Empfänger >> eignet. > > Ja, die Zweifel teile ich, lasse mich aber gerne vom Gegenteil > überzeugen. Mir ist der TSOP wg. zuviel Eigenlogik auch eher unsympatisch. Lieber die Filterung selber kontrollieren. > In der Zwischenzeit arbeite ich weiter an meiner Photodioden Lösung. Die > Detektierung ist robust, sogar mit einem 400-Watt Halogenstrahler im > Raum ;) (Gibt es alternative Vorschläge für künstliche IR-Quellen?). > Mein Pixel ist nach wie vor 5x5x3cm groß und das Ganze ist absolut > unempfindlich gegenüber seitlichen Annäherungen. Das geht sogar soweit, > dass einzelne Finger am Rand der Pixel nicht zuverlässig erkannt werden. > Zwei Finger bzw. ein Finger in der Mitte hingegen funktionieren > problemlos. Keine Ahnung, ob das so gewünscht ist, ändern kann man daran > vermutlich nicht besonders viel. Annäherungen über dem Pixel sind ab > etwa 5 cm über der Platte detektierbar. Das liegt am Abstrahlwinkel der IR-Diode an sich, dass mit 3cm Tiefe nun die Seite nicht abgedeckt wird. Das Problem würde sich auch mit tieferen Zellen lösen. Das würde also einerseits bei breit strahlenden IR-Dioden die Breite begrenzen und bei eng strahlenden hilft der Abstand, dass der Kegel oben breit genug ist. Am Ende müssen die Tiefe, die Größe der Zelle und der Abstrahlwinkel der Diode zusammenpassen. Denn hätte man eine mit 120 Grad, aber sie ist 10cm tief, dann wird zwar der Winkel durch die Tiefe gefiltert, aber ich verliere 50% (oder mehr) der Lichtleistung für den Detektor.
Conny G. schrieb: > Mir ist der TSOP wg. zuviel Eigenlogik auch eher unsympatisch. > Lieber die Filterung selber kontrollieren. Jut, dann spare ich mir den TSOP-Test. Sicherlich lässt sich ein gescheites Filtern von Umgebungseinflüssen auch in Software bewerkstelligen. Gruß, Frank
wenn wir das das das und das nun sein lassen wollen, was bleibt denn noch alternativ... ich verliere ehrlich gesagt gerade etwas den überblick :-)
Angehängte Dateien:
-
LedTisch.jpg
210 KB
Hallo, auch ich wollt mir einen Tisch bauen. Nur leider ist das Projekt durch einen Kumpel gestorben, der mir das Programm schreiben sollte. Was ich schon hatte war das vorläufige Konzept des Tisches. Die "Messinffläche" soll das LED Feld mit 12x16 Pixeln (3:4) a 50x50mm darstellen. Die gelben Punke sollten Touch Sensoren unter der Glasfläche sein um auch mögliche Anwendungen ohne Smartphone oder Rechenr zu bedienen. Ansonsten hatte ich eine 10mm einseitig mattierte Glasplallte vorgesehen, die um das LED Feld schwarz lakiert/beschichtet/beklebt werden sollte. Der Rest ist billiger Baustahl xD. Angeschlage hatte ich ca 1000€ auch wenn das schon knapp werden wird. Eine Version 2.0 hatte ich nicht vor zu fertigen xD. Ich bin gespannt was hier auf der Elektrischen Seite entsteht und würde mich auch gerne beteiligen solange ich noch was verstehe als Metaller^^.
So, habe - mehr oder weniger aus Spaß - mal ein Video meines aktuellen Setups gemacht, siehe [1]. Baut derzeit auf einem ATmega88 auf, weil damit die UART Handhabung einfacher ist. Im Prinzip mache ich aber nichts, was nicht auch ein ATtiny85 bzw. ATtiny841 macht. Überhaupt ist die Software sehr simpel. In einer Timer-ISR schalte ich die IR-LED ein bzw. aus und starte eine ADC Konvertierung. Die Ergebnisse ziehe ich jeweils voneinander ab. Überschreitet die Differenz eine Schwelle (per Trial & Error festgestellt), schalte ich die blaue LED ein. Dafür, dass das Ganze so simpel und günstig ist, funktioniert es erstaunlich gut. Konnte es weder mit einer Fernbedienung noch mit einem Halogenstrahler aushebeln. Einziges Problem bei diesem Ansatz ist aber die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? Habe testweise auch IR-LEDs links und rechts betrieben, hat dem Ganzen nichts ausgemacht. Habe im Video auch versucht zu zeigen, dass der Sensor nicht auslöst, wenn man sich neben dem eigentlichen Sensor bewegt. Dafür sind die Reflexionen zu schwach. Wie gesagt: Ist alles noch mit Float-Glas. Das satinierte trifft wohl erst im Laufe der nächsten Woche ein. Ich persönlich bin von diesem Ansatz voll und ganz überzeugt. Unabhängig davon ist es auch im Preis nicht zu schlagen: 20 Cent für die IR-LED und 20 Cent für die Photodiode. Bei größeren Mengen ggf. sogar billiger. Bei einem ATtiny841 hätten wir ja auch mehr als genug Platz für eine "schlaue" Auswertung in Software. Da fehlt es bei mir aber im Wesentlichen an Ansätzen, für Vorschläge bin ich aber gerne offen. Mit freundlichen Grüßen, Karol Babioch [1]: http://youtu.be/e9vYGd5S3GQ
Seanten schrieb: > Die gelben Punke sollten Touch Sensoren unter der Glasfläche sein um > auch mögliche Anwendungen ohne Smartphone oder Rechenr zu bedienen. Gefällt mir gut die Idee bzw. dein ganzes Konzept. Wolltest du die gelben Touchflächen sichtbar gestalten, oder "versteckt" halten? Hier würde sich ja ggf. eine kapazitive Lösung anbieten, zumindest wenn man an dieser Stelle auf das Metall verzichtet ;). Für Metallarbeiten fehlt mir sowohl das Know-How als auch die Werkzeuge. Hätte mich auf Holz beschränkt. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > So, habe - mehr oder weniger aus Spaß - mal ein Video meines aktuellen > Setups gemacht, siehe [1]. Baut derzeit auf einem ATmega88 auf, weil > damit die UART Handhabung einfacher ist. Im Prinzip mache ich aber > nichts, was nicht auch ein ATtiny85 bzw. ATtiny841 macht. Überhaupt ist > die Software sehr simpel. In einer Timer-ISR schalte ich die IR-LED ein > bzw. aus und starte eine ADC Konvertierung. > > Die Ergebnisse ziehe ich jeweils voneinander ab. Überschreitet die > Differenz eine Schwelle (per Trial & Error festgestellt), schalte ich > die blaue LED ein. > > Dafür, dass das Ganze so simpel und günstig ist, funktioniert es > erstaunlich gut. Konnte es weder mit einer Fernbedienung noch mit einem > Halogenstrahler aushebeln. Einziges Problem bei diesem Ansatz ist aber > die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne > oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa > 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? > > Habe testweise auch IR-LEDs links und rechts betrieben, hat dem Ganzen > nichts ausgemacht. Habe im Video auch versucht zu zeigen, dass der > Sensor nicht auslöst, wenn man sich neben dem eigentlichen Sensor > bewegt. Dafür sind die Reflexionen zu schwach. > > Wie gesagt: Ist alles noch mit Float-Glas. Das satinierte trifft wohl > erst im Laufe der nächsten Woche ein. > > Ich persönlich bin von diesem Ansatz voll und ganz überzeugt. Unabhängig > davon ist es auch im Preis nicht zu schlagen: 20 Cent für die IR-LED und > 20 Cent für die Photodiode. Bei größeren Mengen ggf. sogar billiger. > > Bei einem ATtiny841 hätten wir ja auch mehr als genug Platz für eine > "schlaue" Auswertung in Software. Da fehlt es bei mir aber im > Wesentlichen an Ansätzen, für Vorschläge bin ich aber gerne offen. > > Mit freundlichen Grüßen, > Karol Babioch > > [1]: http://youtu.be/e9vYGd5S3GQ Sehr cool, das sieht wirklich überzeugend aus. Jetzt muss man nur noch den Öffnungswinkel optimieren für den Rand. Ich meine immer noch, dass die Zelle tiefer sein sollte. Bzgl gut und schlecht reflektierender Objekte hätte man nur eine Chance, wenn man den den Abstand misst, aber nicht über die Reflexionsstärke. Nur Anhand einer Menge von reflektiertem Licht kann man das nicht unterscheiden. Das einzige was mir zum Abstand einfällt wäre Lichtlaufzeit, die ist aber zu Kurz. Ansonsten irgendwas mit Interferenz, hab ich irgendwo mal was dazu gelesen. Mmmh. Aus dem Bauch würde ich sagen, dass wir da ein neues Niveau von Schwierigkeitsgrad betreten und sollten das erstmal akzeptieren, dass wir das nicht differenzieren können. Schadet natürlich nicht die Abstandsmessung für einen Tag zu recherchieren, vielleicht geht ja was :-)
http://www.google.com/patents/EP2290393A2?cl=de Konzept zur optischen Abstandsmessung [0017]: "wird hier jedoch eine kontinuierlich modulierte, sinusförmige Lichtquelle verwendet. Die Distanzinformation lässt sich dabei anhand der Phasenverschiebung des zurückreflektierten Lichts rekonstruieren. " Also prinzipiell würden sich die ToF (Time of flight) Verfahren eignen, die für die Pixel von 3D Kameras verwendet werden. http://de.wikipedia.org/wiki/Abstandsmessung_(optisch)#Messung_.C3.BCber_die_Phasenlage Ob das statt mit einem Laser auch mit einer IR Diode funktioniert? Müsste schon, wenn man nicht die IR Wellenlänge als Modulation nimmt. Das ist allerdings bestimmt ein mehrwöchiges bis mehrmonatiges Forschungsprojekt für sich, wenn das noch niemand gemacht und veröffentlicht hat.
:
Bearbeitet durch User
Das Prinzip Phasendifferenz mit moduliertem Lichtstrahl sähe rein von der Theorie am vielversprechensten aus, Seite 20f: http://tams-www.informatik.uni-hamburg.de/lehre/2003ws/vorlesung/angewandte_sensorik/vorlesung_06.pdf Wenn gemäß dem Beispiel eine Frequenz von 10 MHz eine Wellenlänge von 30m ergibt - und das der Messbereich 1x Lambda ist - und unser Messbereich kleiner als 30cm sein soll (eher sogar 10), dann müsste man also mit der 100-fachen Frequenz arbeiten, 1 GHz. Für 10cm sogar 3 GHz. Erscheint mir eher schwierig.
Conny G. schrieb: > Erscheint mir eher schwierig. Ja, das ist ohne Zusatzbeschaltung nicht zu schaffen und insofern unattraktiv. Werden wir uns wohl damit abfinden müssen, dass metallische Gegenstände "besser" erkannt werden. Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > Das Prinzip Phasendifferenz mit moduliertem Lichtstrahl sähe rein von > der Theorie am vielversprechensten aus, Seite 20f: > http://tams-www.informatik.uni-hamburg.de/lehre/2003ws/vorlesung/angewandte_sensorik/vorlesung_06.pdf Diese Präsentation sagt auch, dass Ir Reflexion zur Abstandsmessung ungeeignet ist (Seite 23)
1 | Infrarotsensoren (2) |
2 | ● In realistischen Umgebungen haben die Oberfl ̈achen unterschiedliche Farben. |
3 | ● Farbige Oberfl ̈achen reflektieren unterschiedlich viel Licht. |
4 | ● Schwarze Oberfl ̈achen sind praktisch unsichtbar. |
5 | ● IR-Sensoren ko ̈nnen eigentlich nur zu Objekterkennung nicht aber zur Entfernungsmessung eingesetzt werden. |
6 | ● Wenn ein IR-Signal vom Sensor empfangen wird kann man mit Sicherheit annehmen, dass sich ein Objekt vor dem Sensor befindet. |
7 | ● Phantomsignale sind sehr selten. |
8 | ● Fehlt ein IR-Signal heißt das allerdings nicht, dass kein Objekt vor dem |
9 | Sensor ist. |
10 | ● IR-Sensoren werden fu ̈r kurze Reichweiten eingesetzt (50 bis 100 cm). |
Conny G. schrieb: > ● IR-Sensoren werden fu ̈r kurze Reichweiten eingesetzt (50 bis 100 cm). Wobei das ja für uns relevant wäre. Wir wollen ja nicht die Entfernung des Mondes bestimmen ;). Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Was der wohl kostet? http://www.directindustry.com/prod/stmicroelectronics/proximity-sensors-33699-1448175.html http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/data_brief/DM00078006.pdf
:
Bearbeitet durch User
Conny G. schrieb: > Was der wohl kostet? > http://www.directindustry.com/prod/stmicroelectron... Die Frage ist auch, ob sich das Ganze nicht durch Reflektionen am Glas durcheinander bringen lässt. Selbes Problem gilt natürlich auch für alle o.g. Verfahren. Sehe hier keinen realistischen Ansatz ... Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> Was der wohl kostet? >> http://www.directindustry.com/prod/stmicroelectron... > > Die Frage ist auch, ob sich das Ganze nicht durch Reflektionen am Glas > durcheinander bringen lässt. Selbes Problem gilt natürlich auch für alle > o.g. Verfahren. Sehe hier keinen realistischen Ansatz ... > > Mit freundlichen Grüßen, > Karol Babioch Den gibt's noch nicht zu kaufen http://www.st.com/web/catalog/mmc/FM132/SC626/PF260441?s_searchtype=partnumber# Die Reflexionen verfälschen die Messung minimal um den Anteil des reflektierten Lichts, würde ich behaupten. Es dürfte dann die gemessene Entfernung anteilig um die Reflexionsrate kürzen. Wenn also die Reflexion der Oberfläche des Glases bei ein paar Prozent liegt sollte das eigentlich kein Problem sein, wenn diese Hypothese so stimmt. Dann wäre die gemessene Entfernung einfach um diese paar Prozent kürzer. Jedenfalls habe ich gerade ähnliches bei den TOF Kameras gelesen. Alternativ sinkt die Emofindlichkeit/Reichweite, weil der reflektierte Anteil in die Störunterdrückung läuft... Könnte mir vorstellen, dass eine Matte Oberfläche auf der Unterseite besser ist, da der Strahl nicht direkt zurück reflektiert wird, sondern die Reflexion wird diffus gestreut und weniger erreicht die IR Diode. Mmmh, dafür reflektiert Matt aber mehr als glattes Glas. Man bräuchte eine richtige Entspiegelung... Müsste man einfach mal messen, ob die IR Diode bei glattem Glas oder bei matter Oberfläche mehr reflektiertes IR sieht.
:
Bearbeitet durch User
Den Proximity Sensor von STM gibt es noch nicht, wohl aber andere. Ich arbeite sehr viel mit dem VCNL4010 oder dem VCNL4020. Diese Sensoren sind genau für solche Anwendungen wie dem Tisch entwickelt worden, aber eben leider etwas teuer. Inwieweit die deutlich günstigere Lösung mit IRED und Photodiode funktionieren wird, kann ich nicht sagen, aber das Tüfteln ist doch gerade der Reiz am Basteln. Hier noch ein paar Gedanken zu den (digitalen) VCNL Sensoren... Das nutzbare Signal zur Erkennung eines Objektes ergibt sich aus dem reklektierten Signal abzüglich dem Offsetsignal und dem Signalrauschen, also verwertbares Signal = reflektiertes Signal - Offset - Rauschen reflektiertes Signal: je größer das Objekt und je näher der Abstand zur Quelle, desto mehr Signal gibt es; Infrarotes Licht verhält sich ähnlich dem visuellen Licht; schwarze Flächen reflektieren erstaunlich gut, also schwarz anmalen oder besprühen der "Innenseiten der Tischwürfel" bringt nicht viel bei Infrarot; wenn seitliche Reflexe vermieden werden sollen/müssen lieber Textil oder extrem matte Farben verwenden Offset: wird erzeugt durch all das reflektierte Licht von der Glasscheibe und den Innenseiten des Würfels; die Größe des Offsets hängt ab von der Distanz zum Abdeckglas, sowie nahen Objekten und Grenzflächen im "Tischwürfel", weiterhin von Toleranzen des Sensors (Photodiode), dem IRED Strom, der Umgebungstemperatur, dem Typ des abdeckenden Glasscheibe und einfallendem Umgebungslicht Rauschen: sowohl beim digitalen, als auch beim analogen Sensor vorhanden. Die VCNL haben ein digitales Rauschen von etwa 9-11 counts. Entscheidenden Einfluß hat das Coverglas. Je transparenter es ist, um so mehr Signal steht zur Reflexion am zu detektiernden Objekt zur Verfügung. Nach meiner Erfahrung verhalten sich oberflächenmattierte oder angeraute (angeätzte) Glasoberflächen schlechte als Gläser, die im gesamten Volumen milchig oder diffus sind. Wenn hinter dem milchigen Abdeckglas ein Objekt nicht mehr erkant wird, bringt die Erhöhung des Sendestromes oft nicht den gewünschten Effekt, weil proportional auch der Offset mit ansteigt. Eine Verbesserung bringt aber die Verringerung der Distanz zwischen IRED und Coverglas oder die Einengung des Öffnungswinkels der IRED auf den für die Applikation notwendigen Winkel. Noch zwei Gedanken zur Software. Meine Realisierungen mit Proximity Sensoren haben gezeigt, dass man mehrere Szenarien von Filtern und Kalibrierungen benötigt oder zumindest darüber nachdenken sollte: 1) Alle Komponenten inklusive des Coverglases altern. Es muß also eine Möglichkeit geben, das System im Ruhezustand zu kalibrieren, soll heißen den Systemoffset zu bestimmen und zu berücksichtigen. Eventuell jedesmal, wenn der Tisch "gebootet" wird. 2) Der Tod infraroter Applikationen sind Leuchten, die hohe Anteile an "schmutziger" Infrarotstrahlung abgeben, also bitte unbedingt mit Energiesparlampen und Leuchtstoffröhren testen (je chinesischer die Leuchte, desto ...), wenn soetwas in der Nähe vorhanden sein sollte. Erst wenn die Softwarefilter diesen "Stress" rausfiltern ist das System vor Überraschungen sicher. Also weiterhin viel Spass beim Tüfteln am ProxiTable ;-)
:
Bearbeitet durch User
Hallo Frank M., Dein Ansatz ein TSOP zu benutzen und seine Empfindlichkeitsschwelle durch bewusstes Verschieben der Burstfrequenz zu realisieren, ist extrem spannend, da die Problematik und das Tuning in die Software verlagert wird. Ich habe bei den Entwicklern der TSOP Baureihe mal nachgefragt ob mit diesem Trick ein "Nahfeld"-Proximity mit Coverglas realisierbar ist. Die Antwort war nicht eindeutig. Auf jeden Fall solltest Du Bauteile mit fix Gain in Betracht ziehen, da Bauteile mit nachregelnder AGC Dir das Leben in diesem Fall vermutlich nur erschweren. Weiterhin muß Deine Frequenz vermutlcih besser 100Hz abgestimmbar sein. Wenn Du Dich trotzdem noch entschliessen solltest, hier mal weiterzutesten, kannst Du mir eine PN schicken. Ein paar fix gain TSOP hast Du vermutlich nicht in Deiner Schublade rumliegen, oder doch ;-) Wenn nicht, lässt sich da bestimmt was machen. Gruß Didi
Karol Babioch schrieb: > Die Ergebnisse ziehe ich jeweils voneinander ab. Überschreitet die > Differenz eine Schwelle (per Trial & Error festgestellt), schalte ich > die blaue LED ein. Du hast die Schwelle auf umgerechnet ca. 5cm über der Glasplatte kalibriert, habe ich das richtig gesehen? Wie sieht das Verhalten aus, wenn du nur knapp über dem Glas detektieren möchtest?? Ansonsten sieht das wirklich schon sehr gut aus! schön aufgeräumter Platz übrigens :-D > Dafür, dass das Ganze so simpel und günstig ist, funktioniert es > erstaunlich gut. Das Argument finde ich sehr gut. Im Gegensatz zu meinem IS471 Sensor den ich getetset hatte, sind das Welten vom Preis her. > Konnte es weder mit einer Fernbedienung noch mit einem > Halogenstrahler aushebeln. Einziges Problem bei diesem Ansatz ist aber > die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne > oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa > 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? Ich glaub wenn wir das noch unterscheiden möchten, kommen wir in Welten bei denen mehrere Bachelor-/Masterarbeiten draus entstehen könnten. Ich finde die Ansätze die gepostet wurden sehr interessant. Jedoch eine kostengünstige Variante die auch in absehbarer Zeit realisierbar ist, sehe ich noch nicht. Lasse mich aber gerne vom Gegenteil überzeugen. > Habe testweise auch IR-LEDs links und rechts betrieben, hat dem Ganzen > nichts ausgemacht. Habe im Video auch versucht zu zeigen, dass der > Sensor nicht auslöst, wenn man sich neben dem eigentlichen Sensor > bewegt. Dafür sind die Reflexionen zu schwach. Ab ca. 25sek im Video? Ich sehe dort leider keine IR-LED?! Zumindest vorne den Teil der Einsichtig ist, sehe auf dem Steckbrett keine Bauteile?! > Wie gesagt: Ist alles noch mit Float-Glas. Das satinierte trifft wohl > erst im Laufe der nächsten Woche ein. satiniert Plexi? > Ich persönlich bin von diesem Ansatz voll und ganz überzeugt. Unabhängig > davon ist es auch im Preis nicht zu schlagen: 20 Cent für die IR-LED und > 20 Cent für die Photodiode. Bei größeren Mengen ggf. sogar billiger. Wie ich oben gepostet habe, gebe ich dir vollkommen Recht > [1]: Youtube-Video "LED Tisch: Touch Pixel - Test" sehr schön ! :-)
Didi S. schrieb: > Ich > arbeite sehr viel mit dem VCNL4010 oder dem VCNL4020. Kannte ich noch gar nicht. Gut, die sind natürlich wesentlich teurer, aber sofern die auch durch Glas hindurch zuverlässig funktionieren, dann wäre es durchaus eine Überlegung wert. Zumal dadurch die Software "einfacher" wird, weil die Dinger per I2C angesteuert werden. Im Datenblatt des VCNL4010 heißt es z.B., dass dieser bis 200 mm spezifiziert ist. Wie verhält sich das mit einer Glasscheibe dazwischen? Prinzipiell hört sich die Größenordnung ja für unseren Anwendungsfall richtig an? 16-Bit sind auch eine Menge, bin gerade darüber erstaunt, dass sich das überhaupt so genau auswerten lässt ... Didi S. schrieb: > Eventuell > jedesmal, wenn der Tisch "gebootet" wird. Ja, das hatten wir sowieso vor. Didi S. schrieb: > Erst wenn die Softwarefilter diesen "Stress" rausfiltern ist das System > vor Überraschungen sicher. Da muss man sich wohl vernünftige Testszenarien einfallen lassen und auch mit mehreren Pixeln gleichzeitig experimentieren. Didi S. schrieb: > Dein Ansatz ein TSOP zu benutzen und seine Empfindlichkeitsschwelle > durch bewusstes Verschieben der Burstfrequenz zu realisieren, ist extrem > spannend, da die Problematik und das Tuning in die Software verlagert > wird. Halte den Ansatz auch für spannend, und wäre an Resultaten (sowohl negativ als auch positiver Natur) interessiert ;). Tim R. schrieb: > Du hast die Schwelle auf umgerechnet ca. 5cm über der Glasplatte > kalibriert, habe ich das richtig gesehen? Ja, so in etwa. Bezieht sich natürlich auf Haut bzw. Hände. Tim R. schrieb: > Wie sieht das Verhalten aus, > wenn du nur knapp über dem Glas detektieren möchtest? Auch möglich. Um so näher man ans Glas heran kommt, umso größer ist die gemessene Spannungsdifferenz. Tim R. schrieb: > Das Argument finde ich sehr gut. Im Gegensatz zu meinem IS471 Sensor den > ich getetset hatte, sind das Welten vom Preis her. Ja, eben. Tim R. schrieb: > Ich > finde die Ansätze die gepostet wurden sehr interessant. Jedoch eine > kostengünstige Variante die auch in absehbarer Zeit realisierbar ist, > sehe ich noch nicht. Lasse mich aber gerne vom Gegenteil überzeugen. Geht mir genauso. Tim R. schrieb: > Ab ca. 25sek im Video? Ja. Tim R. schrieb: > Ich sehe dort leider keine IR-LED?! Ne, das war eine andere Versuchsreihe. In dem Video gibt es tatsächlich nur eine IR-LED. Tim R. schrieb: > satiniert Plexi? Nein, satiniertes Glas. Bin nach einigen Anfragen zu akzeptablen Preisen an entsprechende Muster gekommen. Im Übrigen wird das Glas im Verhältnis deutlich günstiger, wenn man "große" Flächen bestellt. Mit freundlichen Grüßen, Karol Babioch
Also du hast auch wirklich IR-LEDs quasi in nebenan liegenden "Pixeln" strahlen lassen und konntest in deinem Testfeld keine Relefktionen erkennen ja ? erstaunlich finde ich... Um was für Preise handelt es sich denn bei dem Glas?
Hi Karol, kannst Du mal Deine Schaltung kurz beschreiben die Du für Deinen Versuch verwendet hast? Also welche IR-LED und IR-Phototransistor (oder Diode) und mit welchen Widerständen? Danke & Gruß Markus
Tim R. schrieb: > Also du hast auch wirklich IR-LEDs quasi in nebenan liegenden "Pixeln" > strahlen lassen und konntest in deinem Testfeld keine Relefktionen > erkennen ja ? Ja. Tim R. schrieb: > Um was für Preise handelt es sich denn bei dem Glas? Hab jetzt für verschiedene Muster zwischen 4 und 15 EUR gezahlt. Ansonsten kostet ein qm wohl so um die 100 EUR. Markus M. schrieb: > kannst Du mal Deine Schaltung kurz beschreiben die Du für Deinen Versuch > verwendet hast? Die IR-LED wird direkt vom AVR betrieben. Vorwiderstand 100 Ohm. 125 Hz PWM mit 50 % Duty Cycle. Der resultierende Strom sind damit etwa 40 mA. Die Photodiode ist so wie hier [1] beschrieben, an einen ADC Eingang angeschlossen. Widerstand ist direkt übernommen, 1 Megaohm, da die Kanten am Oszilloskop scharf genug sind. Markus M. schrieb: > Also welche IR-LED und IR-Phototransistor (oder Diode) IR-LED ist eine ELIR204-6B von Everlight. Photodiode: ELPD204-6B, auch von Everlight. Ein Phototransistor eignet sich hier übrigens nicht besonders, weil der zu langsam schaltet, insbesondere wenn man die Frequenz erhöht. Habe zwischenzeitlich nämlich auch mit dem ELPT204-6B herumgespielt, aber das haut nicht wirklich hin. Mit freundlichen Grüßen, Karol Babioch [1]: https://www.mikrocontroller.net/articles/Datei:Photo_diode.png
Karol Babioch schrieb: > Hab jetzt für verschiedene Muster zwischen 4 und 15 EUR gezahlt. > Ansonsten kostet ein qm wohl so um die 100 EUR. hmm okay... Plexi gibts glaub für rund die Hälfte > > IR-LED ist eine ELIR204-6B von Everlight. Photodiode: ELPD204-6B, auch > von Everlight Habe grad mal gegoogelt und die Angebote waren nicht so breit wie bei anderen Bauteilen. Vielleicht sollte dann eine Alterantiv Diode gesucht werden ? .-)
Tim R. schrieb: > hmm okay... Plexi gibts glaub für rund die Hälfte Dafür überlebt Plexiglas als Tischoberfläche nicht einmal halb so lang. Da gab es bei früheren Diskussionen eine eindeutige Mehrheit zu Gunsten der Echtglas-Lösung, weil Plexiglas zu schnell zerkratzt, etc. Tim R. schrieb: > Habe grad mal gegoogelt und die Angebote waren nicht so breit wie bei > anderen Bauteilen. Vielleicht sollte dann eine Alterantiv Diode gesucht > werden ? .-) Bin ich prinzipiell offen für - sofern die herausgesuchte Lösung zu ähnlichen Konditionen zu erhalten ist und genausogut funktioniert. Ich hatte damals schon eine Weile gesucht, um ein Paar von IR-LED und Photodiode heraus zu suchen, dass Datenblatt technisch zusammen passt, günstig und für jeweils 20 Cent erhältlich ist. Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Dafür, dass das Ganze so simpel und günstig ist, funktioniert es > erstaunlich gut. Konnte es weder mit einer Fernbedienung noch mit einem > Halogenstrahler aushebeln. Sehr schöner Test! Einfach und effektiv. Gefällt mir! > Einziges Problem bei diesem Ansatz ist aber > die Unterscheidung zwischen gut reflektierenden Objekten in der Ferne > oder schlechten Reflektoren (z.B. Hand) im Nahen. Ist im Video ab etwa > 40 Sekunden zu sehen. Ideen, wie man das in den Griff bekommen könnte? Nein. Mit IR wohl gar nicht. Aber normalerweise wird man da wohl selten mit unterschiedlichen Materialien "spielen".
Hat denn jemand zfällig noch paar "handelsübliche" Photodioden rumliegen und kann damit testen? Ich möchte jetzt keine Bestellung für paar Photodioden auslösen, zumal meine Zeit momentan etwas knapp ist. Was mir noch eingefallen ist. Der LED-Treiber wäre doch gar nicht mal so schlecht. Zum einen 3xPWM für die RGB und zusätzlich noch 1x PWM für die IR-LED (welche ich die ganze Zeit gar nicht bedacht habe). Das Problem ist nur denk ich einen passenden Treiber mit am besten 4 PWM Ausgängen zu finden. Meine erste Suche bei Farnell ergab einen Baustein ab 2 Euro mit 5-6 Ausgängen. http://de.farnell.com/texas-instruments/tca6507pw/led-treiber-7ch-i2c-smb-tssop14/dp/1647813 Hat da jemand vielleicht eine bessere Alternative ? :-) edith: am besten sollten sie natürlich 10bit Auflösung haben
:
Bearbeitet durch User
Tim R. schrieb: > Der LED-Treiber wäre doch gar nicht mal so schlecht. Das kommt in erster Linie wohl darauf an für welchen Mikrocontroller wir uns entscheiden. Der ATtiny85 ist aufgrund der fehlenden UART Hardware kaum geeignet, der "nächstgrößere" ATtiny841 bietet wiederum mehr als genug. Aber klar, prinzipiell wären mir echte Treiber auch lieber. Hatte weiter oben ja beispielhaft welche für 50 Cent erwähnt, aber selbst das macht sich bei den vielen Pixeln bemerkbar. Bei 10x20 sind das 100 Euro, keine Ahnung, ob es das Wert ist. Tim R. schrieb: > Zum einen 3xPWM für die RGB und zusätzlich noch 1x PWM für die > IR-LED (welche ich die ganze Zeit gar nicht bedacht habe). 3 Kanäle reichen absolut. Die IR-LED indirekt über einen Treiber zu versorgen macht keinen Sinn. Wir müssen ja wissen wann die LED an bzw. aus ist und unsere ADC Messungen entsprechend synchronisieren. In meinem Versuchsaufbau hab ich das folgendermaßen gelöst: Eine Timer-ISR läuft mit einigen Hundert Hertz (in meinem Fall ~ 500). Diese wird in 4 gleich lange "Phasen" geteilt. In Phase 1 und 3 wird die LED getogglet (ein bzw. ausgeschaltet), in den Phasen 2 und 4 wird eine ADC Konvertierung durchgeführt. Dieser Ansatz garantiert nämlich, dass die ADC Konvertierung erst dann gestartet wird, wenn das Signal "stabil" ist. Die Photodioden-Konstruktion hat nämlich in der aktuellen Form in etwa 100 Mikrosekunden Rise- bzw. Falltime. Dieser Ansatz erfordert nur ganz wenig Overhead und macht keine expliziten Annahmen über das Timing. Der Artikel über Photodioden erwähnt nämlich explizit, dass man mit dem gewählten Aufbau eine Grenzfrequenz von nur einigen Kilohertz hat. Dafür kommt man ganz ohne "teure" zusätzliche Bauteile (z.B. OpAmps) aus. Einen Timer Interrupt mit dieser Frequenz wird man sowieso haben, ansonsten lässt sich eine schnellere ISR ja auch in Software herunter teilen. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Tim R. schrieb: > Hatte > weiter oben ja beispielhaft welche für 50 Cent erwähnt, aber selbst das > macht sich bei den vielen Pixeln bemerkbar. Bei 10x20 sind das 100 Euro, > keine Ahnung, ob es das Wert ist. Ja, das Problem ist verschiedene PWM-Kanäle haben zu wollen. Die kosten meist etwas mehr. Aber wenn jemand einen passenden Baustein für wenig Geld hat, immer her damit ? :-) > > Tim R. schrieb: >> Zum einen 3xPWM für die RGB und zusätzlich noch 1x PWM für die >> IR-LED (welche ich die ganze Zeit gar nicht bedacht habe). > > 3 Kanäle reichen absolut. Die IR-LED indirekt über einen Treiber zu > versorgen macht keinen Sinn. Wir müssen ja wissen wann die LED an bzw. > aus ist und unsere ADC Messungen entsprechend synchronisieren. Das ist schon richtig... oder habe ich gerade einen Denkfehler? Ob ich nun die IR-LED direkt abschalte oder per i2c dem Treiber sage er soll die IR-LED abschalten macht einen minimales delta T denk ich... aber direkt schalten ist schneller und man kann sicher sein das auch wirklich an/aus ist, das stimmt schon
Tim R. schrieb: > Das ist schon richtig... oder habe ich gerade einen Denkfehler? Gut, die Frage kann man erst klären, wenn man ein konkreten Baustein hat. Es ist halt wichtig, dass ein eventueller Treiber wirklich dann anschaltet, wenn wir es ihm sagen, und nicht anfängt selbst herum zu modulieren. Und unabhängig davon ist das Sprechen mit dem Treiber "komplizierter" als das Togglen eines Pins. Bei neueren AVRs lässt sich das ja durchs Schreiben ins PINx Register erledigen. Im Endeffekt sind das aber Detailfragen, die es zu klären gibt, wenn wir uns auf einen konkreten Mikrocontroller festgelegt haben. Funktionieren wird letztendlich beides ;). Mit freundlichen Grüßen, Karol Babioch
Der Attiny841 hat auch genügend Pins die vom Timer angesprochen werden können. Damit könnte man sich auch gleich den kompletten Treiber sparen. Bräuchte nur entsprechende Beschaltung
Bei nur 3 (4) Kanälen komme ich doch noch mit Software-PWM hin, auch mit 10 Bit Auflösung, wieso brauche ich dann einen PWM-Baustein? So reichen mit 3 Transistoren oder Mini-Mosfets um die RGB-LED mit richtig Strom zu versorgen, die kosten 30 Cent. Ach ja, wir haben die 2 Datenprotokolle auch noch, dann muss man auf die Timings ein bisschen aufpassen.
:
Bearbeitet durch User
Die TOCC Pins am Attiny841 sind doch quasi frei wählbar für die PWM-outputs oder nicht? Hab die leider noch nie benutzt, aber das Datenblatt so verstanden. Und somit können doch 2x RX/TX und 4PWM Kanäle genutzt werden bei 8 TOCC Kanälen.
Tim R. schrieb: > Die TOCC Pins am Attiny841 sind doch quasi frei wählbar für die > PWM-outputs oder nicht? Naja, ein paar Restriktionen gibt es schon, siehe Seite 115f. im Datenblatt, aber so eine Flexibilität kenne ich von AVRs noch gar nicht. Habe vorhin mal 10 Stück bestellt, mal sehen, was ich damit anfange ;). Habe mir übrigens auch jeweils ein Exemplar des VCNL4010 und VCNL4020 zugelegt. Auch hier - mehr oder weniger - nur aus Interesse, weil ich gerne wüsste, ob bzw. wie gut das Ganze auch durch Glas hindurch funktioniert. Funktionsreich sind diese Bausteine ja schon (, dafür auch entsprechend teuer. Da müssten wir schon sehr viele sein, damit sich das lohnt. Ab 8000 Stück kosten die dann auch nur noch rund einen Euro ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Da müssten wir schon sehr viele sein, damit sich das Das sind weniger als 8 Tische für 800 Stück.
Conny G. schrieb: > Das sind weniger als 8 Tische für 800 Stück. Die Rede war auch von 8000 ;). Das sind bei 10x20 40 Tische ;). Und selbst dann ist ein Euro noch eine Stange Geld (~ 200 Euro pro Tisch) und würde wohl das teuerste Bauteil darstellen. Der Mikrocontroller z.B. würde bei dieser Größenordnung nur noch 60 Cent kosten. LEDs, Platinen und Hühnerfutter werden zusammen sicherlich auch nochmal ein Euro ausmachen. Damit wären wir halt wieder bei etwa 3 Euro pro Pixel. Und das ist sogar noch optimistisch gerechnet. Wie gesagt, will das erst einmal nur ausprobieren (aus Interesse). Sofern das wirklich zuverlässig funktioniert, hätten wir halt eine Off-the-Shelf Komponente, die gleichzeitig auch eine Entfernungsmessung zulässt und uns neben dem Umgebungslicht auch noch eine extrem hohe Entfernungsauflösung bietet. Bin mir aber nicht sicher, ob das mit 8-10mm diffusen Glas überhaupt klappen kann. Idealerweise gäbe es ja nur einen konstanten Offset, den man in der Software leicht herausrechnen kann. Es kann aber genauso gut sein, dass die interne Elektronik damit nicht zurecht kommt und sich durch die vielen Reflexionen durcheinander bringen lässt. Probieren geht über Studieren ;). Erfahrungen habe ich mit diesen Sensoren noch keine. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Conny G. schrieb: >> Das sind weniger als 8 Tische für 800 Stück. > > Die Rede war auch von 8000 ;). Das sind bei 10x20 40 Tische ;). Und Ui. Zuviel Wein, zuviel geschielt.
Karol Babioch schrieb: > Habe mir übrigens auch jeweils ein Exemplar des VCNL4010 und VCNL4020 > zugelegt. Auch hier - mehr oder weniger - nur aus Interesse, weil ich > gerne wüsste, ob bzw. wie gut das Ganze auch durch Glas hindurch > funktioniert. Toll dieser Tatendrang ! > Funktionsreich sind diese Bausteine ja schon (, dafür auch > entsprechend teuer. Da müssten wir schon sehr viele sein, damit sich das > lohnt. Ab 8000 Stück kosten die dann auch nur noch rund einen Euro ;). Das ist eine ganze Menge. Ich glaube es sollte doch auf günstigere Alternativen zurück gegriffen werden, weil die Stückzahl mit einem Mal nicht erreicht wird
ps: wenn die LED-Treiber zu overpowered/teuer sind, dann seid ihr vom Prinzip wieder beim oben geposteten Schaltplan mit Transistoren oder Ähnlichem. War also gar nicht mal so abwägig würde ich meinen
" .... Bin mir aber nicht sicher, ob das mit 8-10mm diffusen Glas überhaupt klappen kann. Idealerweise gäbe es ja nur einen konstanten Offset, den man in der Software leicht herausrechnen kann. Es kann aber genauso gut sein, dass die interne Elektronik damit nicht zurecht kommt und sich durch die vielen Reflexionen durcheinander bringen lässt. ...." Das eingebaute IC arbeitet linear, soll heissen, dass die Reflexionen ein Offset bilden und das Nutzsignal oben drauf gesetzt wird. Bei 16 Bit Auflösung hat man genug Reserve. Ich habe in einer Anwendungen direkt hinter satiniertem Kunststoff ein Offset von etwa 55000 counts. Der Detektor rauscht digital mit etwa 9-11 counts. Meine Entscheidungsschwelle für ein Objekt oberhalb des Kunststoffes habe ich auf 30 counts gelegt. Das funktioniert einwandfrei.
:
Bearbeitet durch User
So, habe mittlerweile mit einem satiniertes Glasmuster experimentiert. Es ist 10 mm stark und die Lichtdurchlässigkeit beträgt ca. 80 %. Ich habe drei Pixel nebeneinander auf einem Steckbrett aufgebaut und mittels Kartonwänden voneinander getrennt. Für die Steuerung und Auswertung ist jeweils ein ATtiny85 zuständig. Der Code ist im Wesentlichen der selbe wie auch schon bei früheren Experimenten. Aus ästhetischen Gründen lasse ich die LEDs aber in etwa 100 ms "nachglühen". Die Schwellwerte habe ich etwas anpassen müssen (dV beträgt nur noch etwa 250 mV). Ich habe das Ganze wieder in einem kurzen Video festgehalten [1]. Die Lichtverhältnisse bzw. Spiegelungen bitte ich zu entschuldigen. Aufgrund der Urzeit bzw. dem fehlenden Tageslicht war ich gezwungen einen Halogenstrahler im Hintergrund an zu lassen. Ist aber ein Beweis für die Robustheit des Ansatzes :). Nachdem ich nun einige Stunden damit herum gespielt habe, muss ich zu meinem Erstaunen feststellen, dass die Wahl des Glases viel unkritischer ist als zunächst angenommen. Wie man im Video schön sieht, funktioniert es sowohl mit als auch ganz ohne Glas. Habe es auch noch mit einem 4mm starken und satiniertem Glas probiert, auch hier funktioniert es problemlos. Man sieht auch schön wie unempfindlich die einzelnen Pixel gegenüber dem Infrarot-Licht der jeweils anliegenden sind. Insgesamt bin ich mehr als zufrieden und denke, dass das genau der Ansatz ist, den wir verfolgen bzw. umsetzen sollten. Allein schon aus Kostengründen ;). Im Übrigen habe ich mittlerweile auch echte Entfernungssensoren vor mir liegen (VCNL4010 bzw. VCNL4020). Sind allerdings kleiner als zunächst angenommen, mal sehen wie ich da zu einem Versuchsaufbau komme ;). Die sind vermutlich für dieses Projekt, wie schon oben angemerkt, zu teuer - zu mal die Lösung mit IR Photodiode und IR LED gut und robust funktioniert. Da ich aber zum Teil die Intensität der IR LED anpassen musste, um einen vernünftigen Wert zu finden (zu Stark = Reflexionen, zu Schwach = zu unempfindlich), könnte es Sinn machen das aus der Software heraus steuerbar zu machen. Eine PWM halte ich hierfür allerdings nur für bedingt geeignet, weil wir das ja auch vermessen müssen. Was gäbe es hierfür denn für günstige Möglichkeiten? Überhaupt wüsste ich nicht wie man das dann automatisch kalibrieren könnte, wenn man zwei "Stellschrauben" hat, nämlich die von den Photodioden gemessene Differenz sowie die Intensität der IR-LED. Vorschläge? Einziges Manko sind jetzt noch die eigentlichen RGB LEDs. Bei meinen 3 cm und blauen diffusen 5mm LEDs, lässt sich schon noch deutlich erkennen wo sich die LED hinter dem Glas befindet. Idealerweise sollte die so diffus sein, dass die ganze Fläche gleichmäßig ausgeleuchtet ist. Werde wohl noch SMD RGB LEDs probieren, da die einen größeren Abstrahlwinkel haben und ich noch welche vorrätig habe. Übrigens: Für Interessierte finden sich unter [2] Bilder des Aufbaus bzw. eine kleine Fotodokumentation des Projekts ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://youtu.be/HgVx61N-96c [2]: https://plus.google.com/photos/+KarolBabioch/albums/6018967731865862353
:
Bearbeitet durch User
Karol Babioch schrieb: > So, habe mittlerweile mit einem satiniertes Glasmuster experimentiert. Sehr schöner Versuchsaufbau. Ich glaube auch, dass die von Dir getestete Konfiguration der richtige Weg ist. Allerdings halte ich das satinierte Glas immer noch für viel zu klar. SMD-RGB-LEDs mit ihrem großen Abstrahlwinkel halte ich auch für zwingend notwendig. Aber selbst dann werden Einzelheiten (wie Wände aber auch das Innenleben einer jeden Zelle) noch viel zu detailliert abgebildet. Das Glas muss wesentlich diffuser sein. Eventuell wäre eine weiße Farbschicht (wie beim WordClock-Projekt) oder Milchglas eine wesentliche Verbesserung. Dann würde auch jede Zelle viel heller wirken. Fragt sich dann nur, ob die Sensor-Empfindlichkeit dann noch ausreicht...
Karol Babioch schrieb: > So, habe mittlerweile mit einem satiniertes Glasmuster experimentiert. Sehr gute Arbeit, cool! Wenn ich das recht sehe reduziert das Glas die Reichweite von 5-7cm auf 2-3cm? Könnte man da durch die Kalibrierung noch mehr rausholen? Stimme Frank zu, dass Milchglas noch besser wäre. Was fiele uns denn an Entspiegelungsmöglichkeiten für die Unterseite ein? Das könnte Reflexionen und damit den Offset stark verringern.
Karol Babioch schrieb: > Ich habe das Ganze wieder in einem kurzen Video festgehalten [1]. Die > Lichtverhältnisse bzw. Spiegelungen bitte ich zu entschuldigen. sehr schöner Versuch! > Nachdem ich nun einige Stunden damit herum gespielt habe, muss ich zu > meinem Erstaunen feststellen, dass die Wahl des Glases viel unkritischer > ist als zunächst angenommen. Wie man im Video schön sieht, funktioniert > es sowohl mit als auch ganz ohne Glas. Habe es auch noch mit einem 4mm > starken und satiniertem Glas probiert, auch hier funktioniert es > problemlos. Muss mich leider anschließen, dass mir das Glas noch zu "durchsichtig" ist. Gibt es denn eine kostengünstige alterantive wie Milchglas mit guter Lichtdurchlässigkeit?! > Einziges Manko sind jetzt noch die eigentlichen RGB LEDs. Wir hatten anfangs über SuperFlux RGBs nachgedacht. Aber du hast auch gerade mal knapp 2cm tiefe in den Pixeln oder? Wie sieht es aus, wenn dieser Abstand vergrößert wird? Sollte der Abstrahlwinkel automatisch das komplette Glas beleuchten und nicht punktuell.
Frank M. schrieb: > Allerdings halte ich das satinierte Glas immer noch für viel zu klar. Ja, die Frage ist halt immer was es für Alternativen gibt, und wie man da (günstig) heran kommt. Die Lichtdurchlässigkeit der satinierten Gläser scheint immer in etwa 80 Prozent zu betragen, jedenfalls habe ich noch nichts anderes gesehen. Milchglas konnte ich noch keines organisieren, da rührt die Diffusität ja wirklich aus dem Glasinneren her, und nicht nur von der Oberfläche. Frank M. schrieb: > Eventuell wäre eine weiße > Farbschicht (wie beim WordClock-Projekt) Da bringst du mich auf eine Idee. Habe noch eine Diffusorfolie aus dem Wordclock-Projekt (für die Metallfront). Die könnte man unterlegen und dann sogar auf klares Glas setzen. Das Licht wird dabei in jedem Fall genug gestreut, vor allem bei SMD LEDs. Frank M. schrieb: > Fragt sich dann nur, ob die Sensor-Empfindlichkeit dann noch > ausreicht... Probieren geht über studieren: Funktionieren tut das Ganze auch wunderbar, siehe mein neustes Video [1]. Bin mir nur nicht sicher, ob das optisch akzeptabel bzw. ansprechend ist. Alternativ könnten man auch 5x5 cm große Quadrate ausschneiden und in den Pixeln anbringen. Die Glasplatte würde dann auf einer Holzkonstruktion aufliegen. Könnte mir vorstellen, dass das "schön" aussieht. Dazu ist es auch noch die kostengünstigste Alternative. Conny G. schrieb: > Wenn ich das recht sehe reduziert das Glas die Reichweite von 5-7cm auf > 2-3cm? Ja, etwas geringer ist das geworden. Lässt sich ggf. aber durch eine Erhöhung der Intensität der IR LEDs ausgleichen. Muss dafür aber meinen Versuchsaufbau ändern, weil ich beides gerne über die Software und ein entsprechendes Protokoll steuern würde, sodass ich nicht ständig neu flashen und den Aufbau ändern muss. Tim R. schrieb: > Aber du hast auch gerade mal knapp 2cm tiefe in den Pixeln oder? Die Kästchen sind derzeit 3 cm tief. Mit der Diffusorfolie reicht das aber. Bei der Wordclock z.B. ist der Abstand noch geringer und man kann die einzelnen LEDs nicht mehr erkennen. Mit freundlichen Grüßen, Karol Babioch [1]: http://youtu.be/SClKqD01_uU
:
Bearbeitet durch User
Übrigens: Als Vorschlag zu meinem Video wurde mir Folgendes [1] angeboten. Schaut auch sehr vielversprechend aus und basiert scheinbar auf Entfernungssensoren. Das entsprechende Produkt kann man hier [2] kaufen. Dort steht etwas von 300 Dollar, wobei man sich für den Preis nochmal bei denen melden soll? Gibt nicht viele technische Details, aber sofern das wirklich nur 300 Dollar kosten würde, lohnt sich im Prinzip der Selbstbau nicht ;). Mit freundlichen Grüßen, Karol Babioch [1]: https://www.youtube.com/watch?v=R10_4ciWxgI [2]: http://www.farralane.com/store/p-9505-acclaim-lighting-catwalk-panel.aspx
:
Bearbeitet durch User
Karol Babioch schrieb: > Übrigens: Als Vorschlag zu meinem Video wurde mir Folgendes [1] > angeboten. Schaut auch sehr vielversprechend aus und basiert scheinbar > auf Entfernungssensoren. Das entsprechende Produkt kann man hier [2] > kaufen. Dort steht etwas von 300 Dollar, wobei man sich für den Preis > nochmal bei denen melden soll? Gibt nicht viele technische Details, aber > sofern das wirklich nur 300 Dollar kosten würde, lohnt sich im Prinzip > der Selbstbau nicht ;). > > Mit freundlichen Grüßen, > Karol Babioch > > [1]: https://www.youtube.com/watch?v=R10_4ciWxgI > [2]: > http://www.farralane.com/store/p-9505-acclaim-lighting-catwalk-panel.aspx Das ist wirklich sehr gut gemacht! Ich frage mich allerdings, ob man es frei programmieren kann (Spiele, eigene Animationen etc.). Allerdings kostet das 20x20 Panel 300 Dollar. Also selbst wenn man 50% Rabatt bekäme, kommt man für einen 60x60 Tisch bei 3x3 = 9 Panels x 150 Dollar = 1.350 Dollar raus. Für den Preis bekommen wir es auch hin :-) Wir müssten doch folgendes schaffen können: - Holz, Lack, Schrauben, div. Kabel etc. 100-150 Euro - Glas 100 Euro - Pixel, 100 Pixel x 3 Euro = 300 Euro - Steuerung 30 Euro Also um die 500-600 Euro, das ist die Hälfte.
:
Bearbeitet durch User
Conny G. schrieb: > Das ist wirklich sehr gut gemacht! > Ich frage mich allerdings, ob man es frei programmieren kann (Spiele, > eigene Animationen etc.). Da steht etwas von DMX, also eventuell. Ansonsten könnte man das sicherlich modifizieren und nur den physikalischen Aufbau benutzen ;). Also rein theoretisch ... Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > - Pixel, 100 Pixel x 3 Euro = 300 Euro Dann hast du aber "nur" 100 Pixel, also z.B. 10x10. War nicht mal 10x20 bzw. sogar 20x20 der Plan? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> - Pixel, 100 Pixel x 3 Euro = 300 Euro > > Dann hast du aber "nur" 100 Pixel, also z.B. 10x10. War nicht mal 10x20 > bzw. sogar 20x20 der Plan? Ja, ich plante soweit einen kleinen Couchtisch von ungefähr 60x60cm. Vielleicht ein bisschen mehr.
Karol Babioch schrieb: > Probieren geht über studieren: Funktionieren tut das Ganze auch > wunderbar, siehe mein neustes Video [1]. Na also! So muss es sein: Die Fläche muss leuchten und nicht die LED dahinter. Wenn Du jetzt noch SMD-RGB-LEDs benutzt, wird auch noch der runde Kranz verschwinden und alles ist perfekt :-)
Frank M. schrieb: > Wenn Du jetzt noch SMD-RGB-LEDs benutzt, wird auch noch der > runde Kranz verschwinden und alles ist perfekt :-) Ja, aber ist das der Weg, den wir einschlagen wollen? Effektiv ist ja trotz der vielen Beiträge noch nicht wirklich etwas beschlossen worden und irgendwann müssen wir uns mal auf irgendetwas festlegen, um weiter voran zu kommen. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Wenn jeder nur wartet, wird das nie was. Irgendwann muss man auch "machen". Das heisst im konkreten Fall: das bisherige Ergebnis als Teillösung des Projekts ansehen. Damit ist es dann "beschlossen". Anders kommt man nicht weiter. Es wird immer welche geben, die mit einer Teillösung so nicht einverstanden sind oder lieber eine andere Lösung gesehen hätten. Aber ohne Kompromisse kommt man halt nicht weiter... ;-)
Angehängte Dateien:
Karol Babioch schrieb: > Frank M. schrieb: >> Wenn Du jetzt noch SMD-RGB-LEDs benutzt, wird auch noch der >> runde Kranz verschwinden und alles ist perfekt :-) > > Ja, aber ist das der Weg, den wir einschlagen wollen? Effektiv ist ja > trotz der vielen Beiträge noch nicht wirklich etwas beschlossen worden > und irgendwann müssen wir uns mal auf irgendetwas festlegen, um weiter > voran zu kommen. Um meinen Senf dazuzugeben: Ich würde es mir so vorstellen, dass die Zellen komplett ausgeleuchtet sind und man so wenig "LED-Punkt" wie möglich sieht. Ein kleiner dunkler Schatten (paar Millimeter) ist ok, man sollte aber nicht die Unterkonstruktion durch die Glasscheibe sehen können. Also sollte sie stark "milchig" sein, womit satiniert nicht ausreichen würde. Vom optischen Eindruck gefällt es mir wie hier gut: http://youtu.be/MoCnA9lN_54 (Ab 0:50). Nur grössere Felder. Oder wie der Touch Table: https://www.youtube.com/watch?v=DTb0k_P1wlY (bzw. angehängter Screenshot) wobei mir gerade auffällt, dass das Glas gerne noch etwas milchiger sein dürfte als hier. Genau deshalb wäre es mir auch lieber, wenn die Tiefe der Zellen mehr wäre als 3cm, weil sich dann einfacher eine schöne Ausleuchtung ergibt. Also weniger durch die Diffusion des Materials, mehr durch gute Ausleuchtung.
Frank M. schrieb: > Wenn jeder nur wartet, wird das nie was. Irgendwann muss man auch > "machen". > > Das heisst im konkreten Fall: das bisherige Ergebnis als Teillösung des > Projekts ansehen. Damit ist es dann "beschlossen". > > Anders kommt man nicht weiter. Es wird immer welche geben, die mit einer > Teillösung so nicht einverstanden sind oder lieber eine andere Lösung > gesehen hätten. > > Aber ohne Kompromisse kommt man halt nicht weiter... ;-) da gebe ich dir Recht :-) ... und da ich den Thread hier gestartet hatte, nehm ich mir einfach mal die Freiheit und würde beschließen, dass wir den gezeigten Testaufbau als Referenz nehmen. Ich werde z.B. meine IS471 Sensoridee aufgrund des Preises dann auch verwerfen. Die Frage um das richtige Glas muss eben probiert werden. Ich persönlich habe nichts gegen mein Plexiglas wo ich mir ein Muster bestellt hatte, aber wenn die Masse richtiges Glas bevorzugt, dann gehen wir diesen Weg. Nur fehlen mir bis dato Quellen, wo es gutes und günstiges Glas gibt, welches für unseren Gebrauch nutzbar bist :-( ps: warum smd-LEDs? streuen diese besser oder wie muss ich das verstehen. Bin jetzt gerade etwas verwirrt
:
Bearbeitet durch User
Tim R. schrieb: > ps: warum smd-LEDs? streuen diese besser oder wie muss ich das > verstehen. Bin jetzt gerade etwas verwirrt Ja. Diejenigen von der Wordclock haben z.B. einen Abstrahlwinkel von 140°. Da sieht man dann keinerlei Punkte. In Kombination mit Widerständen in der Bauform 0805 lassen sich auch gut per Hand löten und sparen Platz. Selbiges gilt für den ATtiny841, der sich als SOIC auch noch gut per Hand verarbeiten lassen würde. Bei den Photodioden bzw. IR-LEDs scheint es aber nur THT zu geben, insofern lässt sich ein bisschen Handarbeit eh nicht vermeiden. Was das "Beschließen" von Dingen für das Projekt angeht, so sind in meinen Augen zumindest noch folgende Baustellen offen: - Protokoll: Ist denn jeder mit der vorgeschlagenen Daisy Chain zufrieden? Gibt es berechtigte Einwände bzw. Verbesserungsvorschläge? Hat das überhaupt schon jemand probiert (mit ein paar (> 10) Slaves) ;)? Implizites Timing gefällt mir an sich ganz gut, nur ob das hinhaut bei so vielen Teilnehmern? Immerhin kann (in ungünstigen Fällen) auch einiges an Verzögerung entstehen durch die involvierten ISRs. Die UART ISRs z.B. sind auch relativ niedrig priorisiert. Man muss das Zeitfenster zum Übernehmen der Werte also groß genug wählen? Mag sich da jemand mal Gedanken zum Worst Case machen und irgendwelche Formeln bzw. konkrete Werte liefern ;)? - Überhaupt gibt es wenig konkrete Details zur verwendeten Schnittstelle bzw. im Wiki-Artikel ist von MOSI, MISO, usw. die Rede. SPI so wie es im Lehrbuch steht wird aber nicht funktionieren, weil wir mit einer synchronen CLK Leitung nicht hinkommen werden. Alternativ gibt es den o.g. UART Ring - entweder in einfacher oder zweifacher Ausführung. Letzteres fände ich "cooler", weil noch nirgends gesehen und potentiell doppelt so schnell. Andererseits macht es die Timings (zwei gegeneinander agierende ISRs) ggf. noch mehr "kaputt". - Die Frage zur Steuerung der Intensität der IR-LED ist auch noch nicht geklärt: Ich würde das schon für sinnvoll halten, allein schon weil IR LEDs wohl altern und mit der Zeit schwächer werden. Ggf. müsste man hier also nachjustieren. Das ist derzeit mein größtes Problem, weil der typische PWM Ansatz halt nicht funktionieren wird. Eine digitales Potentiometer bzw. eine programmierbare Konstantstromquelle kostet (merklich) Geld. - Maße: Ich halte eine Pixelgröße von 5x5 cm für einen guten Kompromiss. Würde die Platinen allerdings etwas kleiner machen, z.B. 48mm x 48mm, um genug Platz für eine Rahmenkonstruktion zu haben. - Spannungsversorgung: Sollen die Pixel jeweils selbst einen Spannungsregler an Board haben? Wenn wir einmal von 20 mA pro Farbe sowie 40 mA für die IR LED ausgehen, dann kommt da schon ordentlich was zusammen (> 100 mA pro Pixel). - Verkabelung: Weiter oben wurde z.B. der Vorschlag gemacht zumindest die Stromversorgung mittels "Schienen" zu gewährleisten. Die einzelnen Pixel-Platinen werden dann nur noch "aufgesteckt". Hat jemand Erfahrungen mit solchen Systemen? Stichwörter zum Suchen? Preise? Infos zur Zuverlässigkeit? Softwaretechnisch fehlt auch noch einiges: - Protokoll: Eine genaue Spezifikation + Implementierung - Bootloader: Ich würde gerne Pixel einzeln bzw. per Broadcast flashen können, um Updates bequem einzuspielen. Der ATtiny841 hat leider keinen dedizierten Bootloader-Support, d.h. wir müssen das per Software erledigen und es dahingehend absichern, dass man den Bootloader nicht kaputt machen kann (Stromausfall & Co.). 100+ Module per Hand neu zu flashen macht sicherlich keinen Spaß. Eine mögliche Inspirationsquelle: [1]. Was für Möglichkeiten der Verifizierung gibt es? Wenn wir das alles per Daisy-Chain hin und her schicken, dann könnte es langsam werden. "Interessant" wäre es, wenn sich die Pixel untereinander Updates zuspielen und überprüfen könnten. Ist aber vermutlich zu kompliziert, oder? Es gibt also eine Menge zu tun: Und selbst wenn all das steht, dann haben wir erst einmal nur "blöde" Pixel. Eine Steuerung will auch noch entworfen und programmiert werden ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://jtxp.org/tech/tinysafeboot_en.htm
:
Bearbeitet durch User
Karol Babioch schrieb: > Ja. Diejenigen von der Wordclock haben z.B. einen Abstrahlwinkel von > 140°. Ah super, ich hatte SMD-LEDs bisher nie als so wichtiges Leuchtmittel genutzt, eher für Hinweisleuchten oder was auch immer :-) > Was das "Beschließen" von Dingen für das Projekt angeht, so sind in > meinen Augen zumindest noch folgende Baustellen offen: Das ist klar... aber irgendwann müssen wir ja ausm Pott kommen denke ich :-) > - Protokoll: Ist denn jeder mit der vorgeschlagenen Daisy Chain > zufrieden? Gibt es berechtigte Einwände bzw. Verbesserungsvorschläge? > Hat das überhaupt schon jemand probiert (mit ein paar (> 10) Slaves) ;)? Bisher erschien mir die Variante als schnellste,komfortabelste Lösung vor. Nein es ist bisher bei reiner Theorie geblieben, soweit ich weiß. Das es getestet werden muss ist klar, aber ich denke der Ansatz ist leicht zu verstehen und sollte funktionieren. Wie schnell das ganze nun letztendlich wirklich ist, ist die intressanteste Frage denk ich. > Implizites Timing gefällt mir an sich ganz gut, nur ob das hinhaut bei > so vielen Teilnehmern? Immerhin kann (in ungünstigen Fällen) auch > einiges an Verzögerung entstehen durch die involvierten ISRs. Naja, die UART haben doch als einzige Komponente neben dem ADC einen Interrupt nötig oder?! > Die UART > ISRs z.B. sind auch relativ niedrig priorisiert. Man muss das > Zeitfenster zum Übernehmen der Werte also groß genug wählen? Mag sich da > jemand mal Gedanken zum Worst Case machen und irgendwelche Formeln bzw. > konkrete Werte liefern ;)? Weiter oben sind dazu schon ein paar Berechnungen gelaufen. Ich muss jetzt leider passen wie weit das genau ausgeführt wurde und der Thread hier wird ja langsam auch immer größer :-) > - Überhaupt gibt es wenig konkrete Details zur verwendeten Schnittstelle > bzw. im Wiki-Artikel ist von MOSI, MISO, usw. die Rede. Der Wiki Artikel ist noch ganz am Anfang. Conny war so nett ein paar Sachen dort aufzuschreiben. > SPI so wie es im > Lehrbuch steht wird aber nicht funktionieren, weil wir mit einer > synchronen CLK Leitung nicht hinkommen werden. Alternativ gibt es den > o.g. UART Ring - entweder in einfacher oder zweifacher Ausführung. Die Überlegungen gingen in Richtung 2x UART für jede Richtung (zwischen den Pixeln). Hier kann man mit der Topologie etwas spielen. Lässt man alle kaskadieren? Denke ich ist zu Zeitraubend. Lässt man die einzelnen Reihen/Spalten jeweils vom Master bedienen? Oder Platziert man den Master in der Mitte und lässt quasi 4 große Abschnitte des Tisches bedienen?! Ich denke mittig oder gleiche die einzelnen Reihen jeweils ansprechen wäre am günstigsten. Ich habe wegen dem Master gerade noch überlegt, ob wir eine Alternative finden könnten. Der Beagle Bone Black hat power und viele I/Os das ist fakt. Jedoch ist momentan (und ich denke auch in der Zukunft) das Teil schwer zu bekommen. Das heißt gibt es etwas ähnliches was leicht lieferbar ist? > - Die Frage zur Steuerung der Intensität der IR-LED ist auch noch nicht > geklärt: Ich würde das schon für sinnvoll halten, allein schon weil IR > LEDs wohl altern und mit der Zeit schwächer werden. Ggf. müsste man hier > also nachjustieren. Das ist derzeit mein größtes Problem, weil der > typische PWM Ansatz halt nicht funktionieren wird. Eine digitales > Potentiometer bzw. eine programmierbare Konstantstromquelle kostet > (merklich) Geld. Der Gedankenansatz ist schon sehr gut, nur denke ich sprengt das irgendwann auch etwas den Rahmen. Und die Alterung der LED ist denke ich vernässligbar, habe aber dazu ehrlich gesagt nicht das Wissen! Wir sollten aufpassen nicht zu doll "auszuholen" damit dieses Projekt auch noch realisierbar bleibt. Oder nicht?! > - Maße: Ich halte eine Pixelgröße von 5x5 cm für einen guten Kompromiss. > Würde die Platinen allerdings etwas kleiner machen, z.B. 48mm x 48mm, um > genug Platz für eine Rahmenkonstruktion zu haben. ich denke mit 5x5cm kann jeder gut leben. Zur Not kann man jeder seine eigene Größe realisieren. Die Platinen würde ich sogar noch etwas kleiner dimensionieren weil 4mm Wandstärke etwas knapp werden könnte. Die Pixelwände sollen schießlich auch die Glasplatte halten und was darauf steht. Ich posaune einfach mal 45x45mm raus :-) > - Spannungsversorgung: Sollen die Pixel jeweils selbst einen > Spannungsregler an Board haben? Wenn wir einmal von 20 mA pro Farbe > sowie 40 mA für die IR LED ausgehen, dann kommt da schon ordentlich was > zusammen (> 100 mA pro Pixel). > - Verkabelung: Weiter oben wurde z.B. der Vorschlag gemacht zumindest > die Stromversorgung mittels "Schienen" zu gewährleisten. Die einzelnen > Pixel-Platinen werden dann nur noch "aufgesteckt". Hat jemand > Erfahrungen mit solchen Systemen? Stichwörter zum Suchen? Preise? Infos > zur Zuverlässigkeit? Also stecken ist denke ich nicht so die gute Idee. Ich würde Schrauben verwenden damit die Pixel wirklich fest sind und nix verrutscht. Das würde evtl. auch eine neue Kalibrierung mit sich ziehen etc. Aber ich denke die Idee mit den Schienen war schon sehr gut, hab da leider nur auch keine Erfahrung mit. > Softwaretechnisch fehlt auch noch einiges: > > - Protokoll: Eine genaue Spezifikation + Implementierung > > - Bootloader: Ich würde gerne Pixel einzeln bzw. per Broadcast flashen > können, um Updates bequem einzuspielen. Der ATtiny841 hat leider keinen > dedizierten Bootloader-Support, d.h. wir müssen das per Software > erledigen und es dahingehend absichern, dass man den Bootloader nicht > kaputt machen kann (Stromausfall & Co.). 100+ Module per Hand neu zu > flashen macht sicherlich keinen Spaß. Eine mögliche Inspirationsquelle: > [1]. Was für Möglichkeiten der Verifizierung gibt es? Wenn wir das alles > per Daisy-Chain hin und her schicken, dann könnte es langsam werden. > "Interessant" wäre es, wenn sich die Pixel untereinander Updates > zuspielen und überprüfen könnten. Ist aber vermutlich zu kompliziert, > oder? > > Es gibt also eine Menge zu tun: Und selbst wenn all das steht, dann > haben wir erst einmal nur "blöde" Pixel. Eine Steuerung will auch noch > entworfen und programmiert werden ;). Um die Software auf dem Master mache ich mir eigtl. am wenigsten Sorgen. Jeder kann dann etwas zum Häppchen dazu steuern :-)
...vielleicht kannst Du da was mit anfangen: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html
Michael D. schrieb: > ...vielleicht kannst Du da was mit anfangen: > http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html Daran orientieren wir uns schon. Nur wollen wir das Ganze modularer und "besser" (TM) hinbekommen ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > - Überhaupt gibt es wenig konkrete Details zur verwendeten Schnittstelle > bzw. im Wiki-Artikel ist von MOSI, MISO, usw. die Rede. SPI so wie es im > Lehrbuch steht wird aber nicht funktionieren, weil wir mit einer > synchronen CLK Leitung nicht hinkommen werden. Ich habe einfach mal einen Wiki-Artikel angelegt und die ersten Gedanken reingeworfen, d.h. ausgereift ist das noch gar nicht. Muss man noch sehen, ob man das mit USI oder Bitbanging oder USART ... am besten macht. > - Maße: Ich halte eine Pixelgröße von 5x5 cm für einen guten Kompromiss. > Würde die Platinen allerdings etwas kleiner machen, z.B. 48mm x 48mm, um > genug Platz für eine Rahmenkonstruktion zu haben. Mir wäre eigentlich 6x6 lieber (60cm-Tisch = 10 Pixel), aber ich könnte mit 5cm auch arbeiten, sind halt dann 12 Pixel für 60cm. Bisschen kleiner finde ich gut, stimme Tim zu, dass man das ruhig grosszügig machen könnte, also 45mm. Auch wenn ich meine, dass 4mm Trennwand voll ausreichen - man hat ja ein ganzes "Wabenkonstrukt" um die Glasplatte zu halten. > - Verkabelung: Weiter oben wurde z.B. der Vorschlag gemacht zumindest > die Stromversorgung mittels "Schienen" zu gewährleisten. Die einzelnen > Pixel-Platinen werden dann nur noch "aufgesteckt". Hat jemand > Erfahrungen mit solchen Systemen? Stichwörter zum Suchen? Preise? Infos > zur Zuverlässigkeit? Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze Breite und darauf per Einstechen oder Aufdrücken die Pixel zu kontaktieren. Elegantere Lösungen willkommen. Die Grundidee war sich das Anlöten von Kabel an den Pixeln (hunderte Lötstellen) - oder noch aufwändiger: Stecker & Buchse für jeden Pixel und das vielleicht noch 2x -zu ersparen. > - Bootloader: Ich würde gerne Pixel einzeln bzw. per Broadcast flashen > können, um Updates bequem einzuspielen. Der ATtiny841 hat leider keinen > dedizierten Bootloader-Support, d.h. wir müssen das per Software > erledigen und es dahingehend absichern, dass man den Bootloader nicht > kaputt machen kann (Stromausfall & Co.). 100+ Module per Hand neu zu > flashen macht sicherlich keinen Spaß. Eine mögliche Inspirationsquelle: > [1]. Was für Möglichkeiten der Verifizierung gibt es? Wenn wir das alles > per Daisy-Chain hin und her schicken, dann könnte es langsam werden. > "Interessant" wäre es, wenn sich die Pixel untereinander Updates > zuspielen und überprüfen könnten. Ist aber vermutlich zu kompliziert, > oder? Bootloader fände ich auch wichtig, anfangs muss man eine Menge an der Software arbeiten, dann wird man einfach nur wahnsinnig immer 100x zu flashen. (30 Sekunden x 100 = 3000 Sekunden = 1 Stunde).
Karol Babioch schrieb: > Michael D. schrieb: >> ...vielleicht kannst Du da was mit anfangen: >> http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html > > Daran orientieren wir uns schon. Nur wollen wir das Ganze modularer und > "besser" (TM) hinbekommen ;). > > Mit freundlichen Grüßen, > Karol Babioch Ja, weil das: http://www.it-gecko.de/wp-content/uploads/2012/04/CIMG0533.jpg http://www.it-gecko.de/wp-content/uploads/2012/04/CIMG0590.jpg total irre ist :-) Größten Respekt vor der geduldigen Leistung & dem Aufwand, aber ich hab da keine Lust drauf :-)
:
Bearbeitet durch User
Conny G. schrieb: > Größten Respekt vor der geduldigen Leistung & dem Aufwand, aber ich hab > da keine Lust drauf :-) ich schließe mich an. wo die riesen platine das erstmal gesehen hatte, dachte ich wort wörtlich what the f*ck :-D
Tim R. schrieb: > Wie schnell das ganze nun > letztendlich wirklich ist, ist die intressanteste Frage denk ich. Ja ;). Tim R. schrieb: > Der Beagle Bone Black > hat power und viele I/Os das ist fakt. Jedoch ist momentan (und ich > denke auch in der Zukunft) das Teil schwer zu bekommen. Das heißt gibt > es etwas ähnliches was leicht lieferbar ist? Bei uns dauert das sicherlich noch. Vielleicht ist es bis dahin wieder etwas besser lieferbar. Ansonsten müssten wir uns in der Tat nach Alternativen umsehen. Tim R. schrieb: > Der Gedankenansatz ist schon sehr gut, nur denke ich sprengt das > irgendwann auch etwas den Rahmen. Und die Alterung der LED ist denke ich > vernässligbar, habe aber dazu ehrlich gesagt nicht das Wissen! Wir > sollten aufpassen nicht zu doll "auszuholen" damit dieses Projekt auch > noch realisierbar bleibt. Oder nicht?! Prinzipiell hast du natürlich recht. Diesen Aspekt würde ich allerdings nicht unterschätzen. Zum Einen habe ich schon von mehreren Seiten gehört, dass der Effekt tatsächlich auftritt und zum Anderen wären wir damit so flexibel wie es nur geht in Bezug auf das verwendete Glas bzw. Plastik. Die Module sollten dann mit allem zurecht kommen, dass Infrarotlicht passieren lässt. Habe mittlerweile auch schon Treiber für 20 Cent gesehen, wobei die nicht genug Strom geliefert haben. Ich suche weiter ... ;). Tim R. schrieb: > Aber ich denke die Idee mit den Schienen war schon sehr gut, hab da > leider nur auch keine Erfahrung mit. Prinzipiell gefällt mir die Idee natürlich auch. Aber keine Ahnung inwiefern das in Sachen Platinendesign zu berücksichtigen ist. Tim R. schrieb: > Um die Software auf dem Master mache ich mir eigtl. am wenigsten Sorgen. > Jeder kann dann etwas zum Häppchen dazu steuern :-) Klar, ist das "kleinste" Problem, aber so "klein" ist es dann auch wieder nicht ;). Vor allem wenn man es modular und erweiterbar gestalten will. Tim R. schrieb: > Naja, die UART haben doch als einzige Komponente neben dem ADC einen > Interrupt nötig oder?! Sowie die Timer ISR, welche die ADC Konvertierungen startet. Alternativ könnte man die ADC Konvertierungen auch in einem Free-Running-Modus laufen lassen und dort den Pin togglen. Viel Overhead ist das Alles natürlich nicht, aber es addiert sich im Worst-Case halt zusammen. Und wenn der Vorletzte Pixel dann erst einmal nichts mehr hört, weil die Pixel davor andere Dinge zu tun hatten, dann wird er bei einem impliziten Timing davon ausgehen, dass alles übertragen worden ist und die Werte übernehmen. Der letzte Pixel bliebe dann leer aus. Man muss das Übernahme-Fenster also groß genug wählen, um auch im Worst-Case auf der sicheren Seite zu sein. Und das hat indirekt wieder Einfluss auf die maximale Refresh-Rate. Mit freundlichen Grüßen, Karol Babioch
Conny G. schrieb: > Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas > wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze > Breite und darauf per Einstechen oder Aufdrücken die Pixel zu > kontaktieren. Die Idee finde ich natürlich gut, nur ob das zuverlässig funktioniert? Will bei einer so teuren Konstruktion nur ungern mit Wackelkontakten im Produktivbetrieb zu tun haben. Und das Verkabelungsproblem löst es ja auch noch nicht ganz, weil wir zumindest die Datenleitungen wirklich als Kabel ausführen müssen ;). Hast du so etwas denn schon einmal ausprobiert? Die Pixel kann man ja als doppelseite Platinen auslegen, vielleicht reichen großzügige Kontaktflächen ja bereits? Ansonsten: Womit willst du "Einstechen"? Gibt es hierfür fertige Bauteile? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Conny G. schrieb: >> Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas >> wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze >> Breite und darauf per Einstechen oder Aufdrücken die Pixel zu >> kontaktieren. > > Die Idee finde ich natürlich gut, nur ob das zuverlässig funktioniert? > Will bei einer so teuren Konstruktion nur ungern mit Wackelkontakten im > Produktivbetrieb zu tun haben. Und das Verkabelungsproblem löst es ja > auch noch nicht ganz, weil wir zumindest die Datenleitungen wirklich als > Kabel ausführen müssen ;). Nein, Wackelkontakt will ich auch nicht. Ich spinne mal rum...: Masse, VCC und Daten als Schraubenloch auf die Platine, wo das Kupfer bis ran geht. Dann Schraube mit Beilagscheibe durch, sodass genügend Kontakt ist. Die Schraube geht durch die Bodenplatte. Auf der anderen Seite, also Unterseite der Bodenplatte haben wir dann einen Kupferstreifen, eine Aluschiene, was weiss ich, was gut leitet. Da werden dann an entsprechender Stelle Löcher gebohrt, die Schraube von oben durchgesteckt, Mutter drauf. Wobei dann VCC/Masse immer komplette Breite durchgingen, das Datensignal immer nur von Platine zu Platine, man könnte auch einfach solche Minikabelchen für die Daten machen: http://img.directindustry.de/images_di/photo-g/kabelschuhe-rechteckigen-zungen-isoliert-19655-3183179.jpg Und die an die entsprechenden Schrauben per Mutter befestigen. Diese Kabelschuhkabelchen zu krimpen wären einfache Handgriffe, Mutter drauf ist auch nicht aufwändig. Und damit wäre auch jede Platine schön überdimensioniert mit 4 Schrauben angeschraubt :-) (VCC, GND, Data In, Data Out)
Conny G. schrieb: > Ich spinne mal rum...: Bin da für alles offen, würde es nur gerne ausprobiert haben. Nicht, dass wir dann hunderte Platinen haben, und es nicht klappt wie geplant ;). Was die Datensignale angeht z.B. kann ich mir nicht vorstellen, dass das so hinhaut. Signalintegritätstechnisch sind breite Kupferstreifen sicherlich nicht perfekt. Für VCC/GND hingegen könnte ich mir das gut vorstellen. Mit freundlichen Grüßen, Karol Babioch
für die datenleitung würde ich einfache jumperkabel vorschlagen.. kriegt man überall günstig und man brauch nur jeweils die stiftleisten bedienen. ist dann aber leider nicht so fest wie eine verschraubung, aber brauch man das wirklich? solange die platine fest sitzt sollte das denk ich machbar sein
Angehängte Dateien:
-
Baugruppe1.jpg
230 KB -
Baugruppe2.jpg
360 KB
Ich habe mal ein paar Maße zusammengefasst die ich hier so gelesen habe. Displaymaße: 600x600mm Pixelgröße: 50x50mm Innere Displayhöhe: wurde mehr als 30mm gewünscht, habe 55mm festgelegt Glasplatte: 5mm Dick Rahem: Komplette aus Holz und einfach zuzuschneiden Ist alles so ausgelegt, dass fast alles im Baumarkt zugeschnitten werden kann. Nur die Einkerbungen der inneren Platten müssen mit einer Stichsäge eingeschnitten werden, Sägeblattbreite = Plattendicke. Der Rahmen kann je nach Geschmack geschraubt oder gedübelt werden. Die Galsplatte kann man einfach von oben einlegen und später mit einem Pümpel wieder rausholen xD. Die Platinengröße sollte dann 48x48mm nicht überschreiten, wie schon erwähnt. Karol Babioch schrieb: > Conny G. schrieb: >> Ich meinte eigentlich nicht Schienen, sondern ganz simpel & billig sowas >> wie ein Kupferstreifen von 1-2cm Breite der Länge nach über die ganze >> Breite und darauf per Einstechen oder Aufdrücken die Pixel zu >> kontaktieren. > > Die Idee finde ich natürlich gut, nur ob das zuverlässig funktioniert? > Will bei einer so teuren Konstruktion nur ungern mit Wackelkontakten im > Produktivbetrieb zu tun haben. Und das Verkabelungsproblem löst es ja > auch noch nicht ganz, weil wir zumindest die Datenleitungen wirklich als > Kabel ausführen müssen ;). Die Idee finde ich garnicht so schlecht, jedenfalls für die Stromversorgung. Man könnte die Schienen einkleben (zur Isolation lakieren oder ähnliches) und die Platinen direkt auf die Schienen schrauben. Wegen den Kontakten kann man ja einfach Kontaktpaste draufschmieren. http://www.conrad.de/ce/de/product/814411/?insert_kz=VQ&hk=SEM&WT.srch=1&WT.mc_id=google_pla&gclid=CJ_n2JHF1L4CFQQOwwodRLoAOA Ich glaube allerdings, dass es an dem Kostenfaktor scheitern wird. Man würde für den Tisch oben ca. 14,4m Kupfer benötigen. Werden so 37,30€ nach Ebay für ein 2x300x200mm Blech, daraus dann 4mm breite Streifen schalgen und alles mit Gewinden versehen. Dazu noch die Paste, Schrauben und die Kabel um die Enden zu verbinden und schon hat sich das leider erledigt, wenn ich mich nicht verrechnet habe xD.
Tim R. schrieb: > für die datenleitung würde ich einfache jumperkabel vorschlagen.. kriegt > man überall günstig und man brauch nur jeweils die stiftleisten > bedienen. ist dann aber leider nicht so fest wie eine verschraubung, > aber brauch man das wirklich? solange die platine fest sitzt sollte das > denk ich machbar sein Auch eine gute Idee! Einfach ein 5mm Loch (oder ein bisschen mehr) in der Grundplatte, 1 Pin Male Header nach unten, dann kann man kurze Kabelchen dieser Sorte http://www.ebay.de/itm/like/281336255345?lpid=106&_configDebug=ViewItemDictionary.ENABLE_PAYMENTS_IN_HLP:true&hlpht=true&ops=true&viphx=1 von unten anstecken.
Maik Pfeiffer schrieb: > Ich habe mal ein paar Maße zusammengefasst die ich hier so gelesen habe. Das Modell schaut super aus. Darf man denn fragen in welcher Software du das designed bzw. gerendert hast? Ansonsten hast du ja so gut wie alles bedacht und übernommen. Deine Sorgen bezüglich der Kupferstreifen teile ich. Kabel werden wohl doch günstiger sein. Mit Stiftleisten und Jumperkabeln sollte das schon auch hinhauen. Bei den Trennwänden dachte ich ggf. an Lasercutten. Das ist durch die vielen 3D-Drucker auch in eine bezahlbare Region gerutscht und bietet den Vorteil, dass es wirklich passgenau ist. Was die Holz-Konstruktion angeht: Soll es eigentlich einen doppelten "Boden" geben? Das würde sich ja anbieten, um die vielen Kabel und die Steuerung zu verstecken, oder? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > bedacht und übernommen. Deine Sorgen bezüglich der Kupferstreifen teile > ich. Kabel werden wohl doch günstiger sein. Mit Stiftleisten und > Jumperkabeln sollte das schon auch hinhauen. Würde man es mit Kabeln verbinden, wäre die Frage, ob man von Platine zu Platine geht oder vom Rand an jede Platine der Reihe oder so ähnlich. Und dann ein dickes Kabel einmal am Rand lang. Eleganter wäre wenn dann von Platine zu Platine, dann hätte man immer so ein 3er Jumper Pack. Dann ist die Frage, wieviel Strom durch das erste Kabelchen gehen muss, wenn die ganze Reihe dranhängt. Wir hatten vorher 100mA pro Platine - 40mA IR, 3x20mA RGB und uC plus evtl. Spannungsregler, dann könnten wir bei 120mA rauskommen. 60er Tisch, 12 Platinen in einer Reihe, 12x 120mA = knapp 1,5A für das erste Kabel. Leider steht für die kleinen Jumperkabelchen oben kein Querschnitt. Die werden aber sicher ziemlich dünn sein, also AWG28 oder so. Dann sind 1,5A schon ein bisschen viel, könnte aber gerade noch so gehen. Bin aber kein Fan von "gerade noch"... Auf jeden Fall geht nur maximal eine 10er / 12er Reihe in Serie, die Reihen müsste man mit etwas dickerem verbinden. Da könnte man vielleicht für die erste Reihe sowas mit Schiene, Gewindeschrauben und Kabelschuhen machen. Damit liesse sich großer Kabelsalat von Netzteil zu jeder Reihe vermeiden. Damit haben wir übrigens auch zum ersten Mal den gesamten Strombedarf des Tisches: für 12x12 sind es dann 17 Ampere. Ordentlich! :-)
Conny G. schrieb: > Auch eine gute Idee! > Einfach ein 5mm Loch (oder ein bisschen mehr) in der Grundplatte, 1 Pin > Male Header nach unten, dann kann man kurze Kabelchen dieser Sorte > > Ebay-Artikel Nr. 281336255345 > > von unten anstecken. da ist amazon komischerweise ja um welten günstiger ;-P http://www.amazon.de/hochqualitative-Jumperkabel-weiblich-m%C3%A4nnlich-female/dp/B00K9QY13M/ref=sr_1_1?ie=UTF8&qid=1401486876&sr=8-1&keywords=jumperkabel+10cm
Conny G. schrieb: > Wir hatten vorher 100mA pro Platine - 40mA IR, 3x20mA RGB und uC plus > evtl. Spannungsregler, dann könnten wir bei 120mA rauskommen. > 60er Tisch, 12 Platinen in einer Reihe, 12x 120mA = knapp 1,5A für das > erste Kabel. > Leider steht für die kleinen Jumperkabelchen oben kein Querschnitt. > Die werden aber sicher ziemlich dünn sein, also AWG28 oder so. > Dann sind 1,5A schon ein bisschen viel, könnte aber gerade noch so > gehen. > Bin aber kein Fan von "gerade noch"... Hier muss ich mal kurz einlenken. Die Idee mit den Jumperkabeln war auf die Daten bezogen! Sprich die 2xUARTs von jedem Pixel zum nachfolgenden. Für die Spannungsversorgung würde ich auch solche Schienen bevorzugen. Die Spannungsversorgung über die Jumper laufen lassen, das wird nicht gut gehen denke ich... da wird ja doch schon ein wenig mehr fließen als 50mA > Damit haben wir übrigens auch zum ersten Mal den gesamten Strombedarf > des Tisches: für 12x12 sind es dann 17 Ampere. Ordentlich! :-) Ist das nicht etwas hoch?? Für einen LED-Tisch?? Ich meine da reicht nicht mal mehr eine standard 16A Haussicherung?? :-/ Ich sehe gerade ein k.o. Kriterium im Landeanflug...
:
Bearbeitet durch User
Karol Babioch schrieb: >Das Modell schaut super aus. Darf man denn fragen in welcher Software du >das designed bzw. gerendert hast? Ich benutze Autodesk Inventor. Hatte mal die Möglichkeit die Software günstig als Schullizens zu kaufen. Die Bilder konnte ich direkt aus der Ansicht exportieren. Karol Babioch schrieb: >Bei den Trennwänden dachte ich ggf. an Lasercutten. Das ist durch die >vielen 3D-Drucker auch in eine bezahlbare Region gerutscht und bietet >den Vorteil, dass es wirklich passgenau ist. Daran hatte ich jetzt garnicht gedacht. Habe die Platten extra so ausgewählt, dass ein Schnitt mit der Stichsäge ausreicht. Nach den Motto "make it as easy as possible". Und ich glaube wer so ein Tisch bauen möchte sollte wenigstens eine Stichsäge haben xD Karol Babioch schrieb: >Was die Holz-Konstruktion angeht: Soll es eigentlich einen doppelten >"Boden" geben? Das würde sich ja anbieten, um die vielen Kabel und die >Steuerung zu verstecken, oder? Den brauchen wir glaub ich garnicht. Wenn es eine Masterplatine in einem Pixel gibt die alle anderen per Bus ansteuert, können wir einfach die Kabel zwischen unterer Platte und den Trennwänden durchmogeln. Damit würde nur noch die Stromzuführ über ein externes Netzteil an einem Bein entlang laufen. Habe davon nicht so die Ahnung xD
Tim R. schrieb: > Conny G. schrieb: >> Wir hatten vorher 100mA pro Platine - 40mA IR, 3x20mA RGB und uC plus >> evtl. Spannungsregler, dann könnten wir bei 120mA rauskommen. >> 60er Tisch, 12 Platinen in einer Reihe, 12x 120mA = knapp 1,5A für das >> erste Kabel. >> Leider steht für die kleinen Jumperkabelchen oben kein Querschnitt. >> Die werden aber sicher ziemlich dünn sein, also AWG28 oder so. >> Dann sind 1,5A schon ein bisschen viel, könnte aber gerade noch so >> gehen. >> Bin aber kein Fan von "gerade noch"... > > Hier muss ich mal kurz einlenken. Die Idee mit den Jumperkabeln war auf > die Daten bezogen! Sprich die 2xUARTs von jedem Pixel zum nachfolgenden. > Für die Spannungsversorgung würde ich auch solche Schienen bevorzugen. > Die Spannungsversorgung über die Jumper laufen lassen, das wird nicht > gut gehen denke ich... da wird ja doch schon ein wenig mehr fließen als > 50mA Über ein Jumperkabelchen ein paar Hundert mA ist ok, aber bei 1-1,5A Dauerstrom fühle ich mich eigentlich nicht mehr so wohl. Am Ende geht's um den Widerstand des Kabels (= Leistungsverlust, Spannungsabfall) und Erwärmung. Das scheint wohl theoretisch nach kurzem Googeln schon noch ok, aber ist schon die Grenze. Ich würde auch eine Schienen oder Kupferstreifen-Lösung bevorzugen: - superordentlich, keine Kabel - keine Einzelkabelchen konfektionieren, löten, stecken, crimpen - bei einer cleveren Lösung geht es zusammen mit der Montage der Platinen (mit 2 Schrauben festschrauben) - kein Problem mit dem Querschnitt bzgl. Strom Ich fände ein 3er Jumperkabel von Platine zu Platine schon auch noch ok und einigermassen elegant. Aber der Querschnitt ist schon ziemlich windig. >> Damit haben wir übrigens auch zum ersten Mal den gesamten Strombedarf >> des Tisches: für 12x12 sind es dann 17 Ampere. Ordentlich! :-) > > Ist das nicht etwas hoch?? Für einen LED-Tisch?? Ich meine da reicht > nicht mal mehr eine standard 16A Haussicherung?? :-/ Ich sehe gerade ein > k.o. Kriterium im Landeanflug... Auf der 230V-Seite sind das aber nur 0,4A plus Trafo-/Netzteilverluste. :-) Wir haben ja z.B. 5V in der Schaltung, also 5V x 17A = 85W. Also soviel in etwa ein Laptop an Netzteil braucht.
Mir geht da grad was durch den Kopf.
Wenn man für die Verbindung der Pixel auch eine Platine nähme.
Oder einen 10-20mm breiten Platinenstreifen.
Auf denen sitzen dann 3er Female Headers im Abstand von 50mm =
Pixelbreite.
Dann könnte man alle 5cm durch die Grundplatte ein passendes Loch bohren
in das genau der Female Header reinpasst und von oben die Pixel
aufstecken.
Also so:
Pixelplatine 3er Male-Header
=====================+++====
------------------+ ||| +--------------
Grundplatte | HHH |
------------------+ HHH +--------------
====+++=====
Kontaktstreifenplatine mit 3er Female-Header
lach... ich bin zu müde und sollte ins bett habe ich gerade gemerkt! :-D also halte ich die bevorzugten lösungen fest: -spannungsversorgung über 2 schienen (5V,GND) -datenleitungen jeweils 3 jumperkabel TX,GND,RX
Für die Stromversorgung reichen auch Streifen aus 0.1mm dicker Kupferfolie. In einer Richtung kommt unter jede Trennwand ein 25 oder 30mm breiter Streifen. Geradzahlige Streifen werden an GND angeschlossen, ungeradzahlige Streifen an VCC. Die Module werden abwechselnd reihenweise ¨linksrum¨ bzw. ¨rechtsrum¨ eingebaut. Der Kontakt zwischen Platine und Kupferstreifen wird durch kurze Kupferröhrchen hergestellt, evtl. gibt es z.B. Kupferhohlnieten mit geeignetem Innendurchmesser für die Verschraubung der Platine and die Grundplatte.
Teils von Conny G.: xD
| | Trennwand
| |
| |
| |
| |
Pixelplatine | | P.p.
==================++= +--+ =++================
=++==========++= <- Verbinder-Platine
-----------------|__|--------|__|---------------
Grundplatte
------------------------------------------------
Wir brauchen ja nicht mal durch die Grundplatte. Die Verbinder-Platine
schrauben wir direkt auf die Grundplatte und Bohren unter den Lötstellen
ein paar mm weg. Natürlich müsste die Platine lakiert sein. Somit haben
wir auch gleich einen gleichmäßigen Abstand zwischen Grundplatte und
Pixelplatine in jedem Pixel.
In etwa könnte die dann so aussehen:
+------------------------------+
| o Schraubenlöcher o |
| + -------- Positiv ------ + |
| - -------- Negativ ------ - |
| x -------- Bus ------ x |
| o Schraubenlöcher o |
+------------------------------+
Konrad S. schrieb: > Für die Stromversorgung reichen auch Streifen aus 0.1mm dicker > Kupferfolie. In einer Richtung kommt unter jede Trennwand ein 25 oder > 30mm breiter Streifen. Geradzahlige Streifen werden an GND > angeschlossen, ungeradzahlige Streifen an VCC. Die Module werden > abwechselnd reihenweise ¨linksrum¨ bzw. ¨rechtsrum¨ eingebaut. Der > Kontakt zwischen Platine und Kupferstreifen wird durch kurze > Kupferröhrchen hergestellt, evtl. gibt es z.B. Kupferhohlnieten mit > geeignetem Innendurchmesser für die Verschraubung der Platine and die > Grundplatte. Das ist eine echt gute Idee! Genau so hatte ich mir das erhofft. Man muss die Platinen sowieso nur an 2 Ecken diagonal anschrauben, also bräuchte man 2 Abstandhalter von 3mm, diese Kupferröhrchen oder was auch immer. Die Verschraubungen sind dann gleichzeitig VCC und Gnd.
Maik Pfeiffer schrieb: > Teils von Conny G.: xD > > | | Trennwand > | | > | | > | | > | | > Pixelplatine | | P.p. > ==================++= +--+ =++================ > =++==========++= <- Verbinder-Platine > -----------------|__|--------|__|--------------- > Grundplatte > ------------------------------------------------ > > Wir brauchen ja nicht mal durch die Grundplatte. Die Verbinder-Platine > schrauben wir direkt auf die Grundplatte und Bohren unter den Lötstellen > ein paar mm weg. Natürlich müsste die Platine lakiert sein. Somit haben > wir auch gleich einen gleichmäßigen Abstand zwischen Grundplatte und > Pixelplatine in jedem Pixel. > > In etwa könnte die dann so aussehen: > > +------------------------------+ > | o Schraubenlöcher o | > | + -------- Positiv ------ + | > | - -------- Negativ ------ - | > | x -------- Bus ------ x | > | o Schraubenlöcher o | > +------------------------------+ Und eine Verbinderplatine würde mehrere Pixel überspannen, wäre so 20-30cm lang, so lange wie das Format nicht die Produktionskosten hochtreibt. Was mir an so einer Lösung echt gut gefallen würde: keine Kabel und Strom und Signale in einem System. Und ob wir dann einen oder 2 Busse haben ist egal. Pixel nur aufstecken und fertig. Superelegant. Nur die Kosten machen mir sorgen. Ich habe keine Ahnung, ob man die Verbinderplatine 20mm x 200mm zu einem Preis von zB 3-5 Euro bekommen könnte. Die Kostenrechnung sähe dann so aus: Pixel 3 Euro, 144 Pixel 430 Euro. Verbinderplatine 5 Euro, 30 Verbinder 150 Euro. Verbinderplatine 3 Euro, 30 Verbinder 90 Euro. Also lieber 3 Euro. Dafür bekäme man dann: Null Verkabelung, supersauber, supereinfach, supergeil.
Oder noch eine andere Variante: Flexplatinenanschlüsse wie bei den LCD Displays. Die passen sogar einfach so unter den Trennwänden durch. Sind nur fummelig zum Einstecken.
Conny G. schrieb: >Und eine Verbinderplatine würde mehrere Pixel überspannen, wäre so >20-30cm lang, so lange wie das Format nicht die Produktionskosten >hochtreibt. Nicht ganz Conny, hatte es so gedacht das nur zwei Pixelplatinen miteinander verbunden werden, ähnlich den Infineon Modulen auf der Mainpage des Forums. Wenn jede Pixelplatine an jeder Seite die Gleichen (verpolungssicheren) Stiftleisten hat, kann man Diese einfach einstecken, wenn die Verbindungs-Platinen auf der Grundplatte aufgeschraubt sind. Somit kann man durch die Verbinder auch die "Form" der Busleitung festlegen. Ob Stern, Reihe nach Reihe oder Schnecken Form xD.
Conny G. schrieb: > Man muss die Platinen sowieso nur an 2 Ecken diagonal anschrauben, Wobei ich die Platinen nur minimal groß machen würde, also lang genug, um die ¨Stromschienen¨ zu erwischen und nur so breit wie unbedingt nötig.
Conny G. schrieb: >Oder noch eine andere Variante: Flexplatinenanschlüsse wie bei den LCD >Displays. Als Flex Platinen könnte man SLI Kabel von Grafikkarten nehemn, würden aber den Kostenrahmen sprengen. Statt 0,1mm Stronschienen würde ich doch eher Quetschverbinder und Kabel bevorzugen. Einfach einen endlos Stang quetschen und auf jeder Platine einstecken. http://www.reichelt.de/Flachstecker/FS-P-4-75/3/index.html?&ACTION=3&LA=2&ARTICLE=24863&GROUPID=3249&artnr=FS-P+4%2C75 Kostengünstig und schell zu quetschen mit einer ordentlichen Zange. U U U U U U U U | | | | | | | | + ===+=|========+=|========+=|========+ | | | | | - =====+==========+==========+==========+
Also die Flexidee ist gut, aber die kann glaub ich gleich verworfen werden. Das sprengt die Kosten. Flex ist ja allgemein um einiges teurer als normale "Platinchen". Die Schraubidee für die Spannungsversorgung würde ich auch versuchen. Ich würde einfach noch eine günstige alternative in den Raum werfen: Streifenraster ? :-)
Wie wäre es mit was ich in Beitrag "Re: schwierigkeiten passenden Bus zu finden" vorgeschlagen habe: Warum nicht bei elecrow.com 20cmx20cm PCBs bestellen und damit den Tisch komplett auslegen? Dann kann man billige Shift-register und die DIP-TLCs von Aliexpress verwenden, kann dicke Bahnen für die Versorgung machen und braucht kein Protokoll mehr und muss nur an den Rändern der PCBs ein paar Verbindungen machen für Strom und Kaskadierung? (z.B. mit Stiftleisten und Jumpern) Statt Kabel zu krimpen, Schienen zu entwickeln o.ä. könnte man damit alle Verbindungen ätzen lassen. Danach nur noch löten. 50 20cmx20cm würden 190 EUR kosten (ohne Versand und Zoll), 10 20cmx20cm würden 94 EUR kosten (ohne Versand und Zoll). Wenn ich mich nicht irre würde man mit http://www.aliexpress.com/item/100-Original-TLC5940NT-TLC5940-TI-LED-Driver-DIP-28/1468213464.html auch die Attinys sparen, zumindest für die LEDs. Also wäre am Ende alles wie bei ITGecko, nur ohne crimpen und die Modularität wäre grober. Ein Shift-Register für die Eingänge zu verwenden basiert halt auf "Entfernungssensor IS471+IR-LED LD274" (Roboterteile.de: 2,63EUR). Das ist teuer, aber was ich hier an Alternativen gelesen habe basiert bis jetzt immer auf dem Attiny, oder?
Christian H. schrieb: > Wie wäre es mit was ich in > Beitrag "Re: schwierigkeiten passenden Bus zu finden" > vorgeschlagen habe: > Warum nicht bei elecrow.com 20cmx20cm PCBs bestellen und damit den Tisch > komplett auslegen? Dann kann man billige Shift-register und die DIP-TLCs > von Aliexpress verwenden, kann dicke Bahnen für die Versorgung machen > und braucht kein Protokoll mehr und muss nur an den Rändern der PCBs ein > paar Verbindungen machen für Strom und Kaskadierung? (z.B. mit > Stiftleisten und Jumpern) > > Statt Kabel zu krimpen, Schienen zu entwickeln o.ä. könnte man damit > alle Verbindungen ätzen lassen. Danach nur noch löten. > > 50 20cmx20cm würden 190 EUR kosten (ohne Versand und Zoll), > 10 20cmx20cm würden 94 EUR kosten (ohne Versand und Zoll). > > Wenn ich mich nicht irre würde man mit > http://www.aliexpress.com/item/100-Original-TLC5940NT-TLC5940-TI-LED-Driver-DIP-28/1468213464.html > auch die Attinys sparen, zumindest für die LEDs. > > Also wäre am Ende alles wie bei ITGecko, nur ohne crimpen und die > Modularität wäre grober. > > Ein Shift-Register für die Eingänge zu verwenden basiert halt auf > "Entfernungssensor IS471+IR-LED LD274" (Roboterteile.de: 2,63EUR). Das > ist teuer, aber was ich hier an Alternativen gelesen habe basiert bis > jetzt immer auf dem Attiny, oder? Ich glaube den Attiny können wir nicht sparen. Die Ir Dioden Remote abfragen durch einen Master ist zu aufwendig. ADC auf Ferne ist keine gute Idee und dezentrale ADC bringen uns nicht weiter, dann kann man gleich Attinys nehmen. Würde also die Struktur der Lösung schon so lassen wie bisher eingekreist. Aber trotzdem könnte man das mit den 20x20 Pcbs überlegen, das erspart tatsächlich die Verkabelung komplett, es bräuchte nur Steckkontakte oder Brücken an den Rändern.
Conny G. schrieb: > Aber trotzdem könnte man das mit den 20x20 Pcbs überlegen, das erspart > tatsächlich die Verkabelung komplett, es bräuchte nur Steckkontakte oder > Brücken an den Rändern. Also nur für die Verbindungen extra Platinen?! Finde ich ehrlich gesagt ziemlich umständlich. Zumal das für mich nach Widerspruch klingt, wenn du sagst "erspart Verkabelung" und im nächsten Teilsatz "bräuchte nur Steckkontakte oder Brücken"... also wirklich sparen tu ich an diesem Ansatz doch gar nichts oder? Ich glaub ich versteh den Ansatz gerade etwas falsch... Und das würde preislich reinschlagen denke ich
Die Idee wäre, alle Bauteile auf 20cmx20cm PCBs zu löten und darüber dann die Holzkästen zu stellen. Jeder IR-Senser/LED und auch die RGB-LEDs und was auch immer an Shiftregistern, Tinys oder TLCs gebraucht wird, würde in den 20cmx20cm geroutet und gelötet. Es wäre kein Problem, von einem Atmega z.B. 14 Pins zu LEDs zu routen oder alles von einem TLC. Keine Kabel, kein Krimpen! Es wäre weniger modular, für 60cmx60cm reichen 9 Module, für 50cmx50cm muss man absägen und das Layout passend machen oder weitere Platinen für 10cmx10cm und 10cmx20cm machen. Und die Rasterweite ist fest. Aber ich glaube, es wäre die wenigste Arbeit und mit Elecrow.com sogar bezahlbar. Übrigens habe ich noch eine andere Idee: Mit Panelizing liese sich die Elektronik nicht auf die Bodenplatte packen, sondern auf die "Holzkästen": Elecrow würde einem in das PCB sicher auch die Kammstruktur fräsen und dann könnte man die Kastenstruktur aus PCB-Material machen (20cm x 5 cm PCBs, 50-100 Stück) und die Bodenplatte aus einer großen Holzplatte. Die Bauteile würden dann ihre Bedrahtung nicht von unten, sondern von der Seite haben. Einziger Vorteil: Man muss kein Holz sägen.
Tim R. schrieb: > Conny G. schrieb: >> Aber trotzdem könnte man das mit den 20x20 Pcbs überlegen, das erspart >> tatsächlich die Verkabelung komplett, es bräuchte nur Steckkontakte oder >> Brücken an den Rändern. > > Also nur für die Verbindungen extra Platinen?! Finde ich ehrlich gesagt > ziemlich umständlich. Zumal das für mich nach Widerspruch klingt, wenn > du sagst "erspart Verkabelung" und im nächsten Teilsatz "bräuchte nur > Steckkontakte oder Brücken"... also wirklich sparen tu ich an diesem > Ansatz doch gar nichts oder? Ich glaub ich versteh den Ansatz gerade > etwas falsch... Und das würde preislich reinschlagen denke ich Neil, nicht extra Platinen, sondern statt 5x5 dann 20x20 oder sogar größer (je nach Preis).
Conny G. schrieb: > Neil, nicht extra Platinen, sondern statt 5x5 dann 20x20 oder sogar > größer (je nach Preis). Auch wenn das die Verkabelung vereinfachen mag, kommen wir halt nicht weiter, wenn wir Kernaspekte, die eigentlich schon "beschlossen" waren doch wieder umkrempeln. Ich seh schon, hier wird irgendjemand einfach mal das Zepter in die Hand nehmen und machen müssen ;). Die Möglichkeiten wurden ja mittlerweile alle (mehr oder weniger) durch diskutiert. Mit freundlichen Grüßen, Karol Babioch
:
Bearbeitet durch User
Karol Babioch schrieb: > Conny G. schrieb: >> Neil, nicht extra Platinen, sondern statt 5x5 dann 20x20 oder sogar >> größer (je nach Preis). > > Auch wenn das die Verkabelung vereinfachen mag, kommen wir halt nicht > weiter, wenn wir Kernaspekte, die eigentlich schon "beschlossen" waren > doch wieder umkrempeln. Ich seh schon, hier wird irgendjemand einfach > mal das Zepter in die Hand nehmen und machen müssen ;). Die > Möglichkeiten wurden ja mittlerweile alle (mehr oder weniger) durch > diskutiert. > > Mit freundlichen Grüßen, > Karol Babioch Dem stimme ich zu. Zumal wir durch die Pixellösung wirklich komplett flexibel sind. Wenn mehrere zusammengefasst werden sollen hat man schon mal eine Winschränkung... und ist das auch wirklich günstiger? Würde lieber zur bestehenden Lösung tendieren, damit wir nicht wieder erneut verschiedene Themen durchkauen brauchen :-)
Wenn die Pixel fertig entwickelt sind (inclusive Protokoll), hindert einen ja niemand, 4x4 (oder mehr) davon auf eine große Platine zu kopieren, mit ein paar Leiterbahnen dazwischen, die das Verdrahten ersparen.
Nosnibor schrieb: > Wenn die Pixel fertig entwickelt sind (inclusive Protokoll), > hindert > einen ja niemand, 4x4 (oder mehr) davon auf eine große Platine zu > kopieren, mit ein paar Leiterbahnen dazwischen, die das Verdrahten > ersparen. Genau so sehe ich das auch... Was sagt denn der Rest, der hier gerne mal mit postet ? :-) Um das Thema Master nochmal anzustupsen: Ich hatte ja schon mal gepostet, dass das BBB relativ schwer zu bekommen ist, soweit ich weiß werden die in der Industrie auch haufenweise weggekauft. Wie wäre es mit alternativen wie dem Cubie Board z.B. ? Ich kenne mich nur mit diesen ganzen neuen "Mini-PCs" á la Rpi gar nicht aus
Ich wäre auch dafür die Platinen vorerst auf 50x50 -0,1/-0.5 mm festzulegen. Größenänderungen kann man später immer noch vornehem. Auch würde ich vorschlagen, dass das Layout sich auf die Mitte der Pixelplatine konzentriert. Gibt auch ein Angebot für 200 mal 50x50mm Platinen für ~82€. Dann starte ich jetzt mal die Abstimmung xd. Nur "JA" oder "NEIN" für die 50x50 Pixelplatine, bitte!!!
Tim R. schrieb: > Ich kenne mich nur mit diesen > ganzen neuen "Mini-PCs" á la Rpi gar nicht aus Selbiges gilt für mich. Der Markt ist mittlerweile auch gar nicht mehr so einfach zu überschauen. Persönlich gearbeitet habe ich nur mit dem Raspberry Pi, das Beaglebone Black gefällt mir gerade in diesem Anwendungsfall aber deutlich besser. Wie gesagt, da mache ich mir derzeit noch keine Gedanken, weil der Master erst den übernächsten Schritt darstellt. Bis dahin kann sich die Verkaufssituation ja schon wieder geändert haben. Wenn nicht gucken wir uns nach Alternativen um. Das sollte ja hoffentlich keinen Einfluss auf jetzige Designkriterien haben, oder? Seanten schrieb: > Nur "JA" oder "NEIN" für die 50x50 Pixelplatine, bitte!!! Ja ;) Wenn wir schon beim Thema Umfragen bzw. Anfragen sind: Mich würde (zunächst rein aus Neugier) interessieren wie viele an einer solchen Sammelbestellung teilnehmen würden. Also soll jetzt noch keine verbindliche Bestellabgabe sein, aber es wäre sicherlich nicht schlecht zu wissen von wie vielen Platinen wir hier reden und ob eine Bestückung sinnvoll ist bzw. sich lohnen würde. Ich vermute nämlich, dass es hier durchaus einige "stille" Mitleser gibt. Das zumindest legen die Statistiken meiner oben geposteten Videos nahe ;). Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Tim R. schrieb: >> Ich kenne mich nur mit diesen >> ganzen neuen "Mini-PCs" á la Rpi gar nicht aus > > Selbiges gilt für mich. Der Markt ist mittlerweile auch gar nicht mehr > so einfach zu überschauen. Persönlich gearbeitet habe ich nur mit dem > Raspberry Pi, das Beaglebone Black gefällt mir gerade in diesem > Anwendungsfall aber deutlich besser. Wie gesagt, da mache ich mir > derzeit noch keine Gedanken, weil der Master erst den übernächsten > Schritt darstellt. Bis dahin kann sich die Verkaufssituation ja schon > wieder geändert haben. Wenn nicht gucken wir uns nach Alternativen um. > Das sollte ja hoffentlich keinen Einfluss auf jetzige Designkriterien > haben, oder? Nein, das ist m.E. auch unabhängig vom Design des Pixel. Wir sollten am Ende mit jedem Timing-Akkuraten Master (also nicht RPi direkt z.B.) das Protokoll betreiben können. Das könnte auch sein Raspberry Pi > uC-Schaltung -> Pixelbus. Oder jede andere Kombi eines "größeren" Masters, der evtl. über einen uC auf den Bus geht. > Seanten schrieb: >> Nur "JA" oder "NEIN" für die 50x50 Pixelplatine, bitte!!! > > Ja ;) Ja. Ich wollte ja auch nicht die bisher diskutierte Lösung infrage stellen nur ein bisschen herum-brainstormen, welche Möglichkeiten es für die Verbindung noch gibt. Mir gefallen Verbinderplatinchen immer noch am besten, das ist dann, wenn wir bei 45x45-Platinchen bleiben ja ein separates Thema, ob Kabel, Schienen oder Verbinderplatinen. > Wenn wir schon beim Thema Umfragen bzw. Anfragen sind: Mich würde > (zunächst rein aus Neugier) interessieren wie viele an einer solchen > Sammelbestellung teilnehmen würden. Also soll jetzt noch keine > verbindliche Bestellabgabe sein, aber es wäre sicherlich nicht schlecht > zu wissen von wie vielen Platinen wir hier reden und ob eine Bestückung > sinnvoll ist bzw. sich lohnen würde. Ich vermute nämlich, dass es hier > durchaus einige "stille" Mitleser gibt. Das zumindest legen die > Statistiken meiner oben geposteten Videos nahe ;). Interessiert, 144 Stück.
Ich bräuchte dann 192 pixel. Werde mir wohl doch noch einen Job suchen müssen ^^. Worüber wir auch nachdenken sollten ist unter welcher Lizens das Projekt stehen soll, wenn sich damit Keiner auskennt würde ich mich da mal reinarbeiten. Kann ja nicht wirklich bei der Elektronik helfen und cad Zeichnungen sind in ein paar Stunden erledigt xd.
"Stiller Mitleser", sehr interessiert, ca. 1mx2m Tischgröße. Holger
seanten schrieb: > Worüber wir auch nachdenken sollten ist unter welcher Lizens das Projekt > stehen soll Ist ja bisher noch nichts veröffentlicht worden ;). Ich persönlich bin großer Befürworter der GPL (zumindest für die Software). Beim Thema Schaltpläne bzw. Designs und Layouts kenne ich mich weniger aus. Was macht denn hier aus deiner/eurer Sicht heraus Sinn? Creative Commons? Mit freundlichen Grüßen, Karol Babioch
seanten schrieb: > Worüber wir auch nachdenken sollten ist unter welcher Lizens das Projekt > stehen soll http://de.wikipedia.org/wiki/WTFPL ?
Ich bin nach wie vor am Tisch interessiert. Und würde Pixelplatinen von 45x45 bis 50x50mm bevorzugen :-) Schöner Einwand! Die "stillen Mitleser" habe ich noch gar nicht bedacht. Hätte auch ehrlich gesagt gar nicht angenommen, dass es welche gibt. Der Master kann natürlich am Ende besprochen werden, ich hatte nur gerade noch mal zwecks BBB geschaut. Ich würde vorschlagen, dass sich erstmal abschließend auf eine IR-LED + Fotodiode geeinigt werden sollte, welche günstig ist, lieferbar und natürlich entsprechende Eigenschaften aufweisen. Die im Video verwendeten Sensoriken waren nicht mehr die best zu beschaffensten oder?!
Conny G. schrieb: > http://de.wikipedia.org/wiki/WTFPL Ich persönlich bin schon ein Freund von Copyleft (und damit z.B. der GPL). Ich bin mir aber natürlich darüber bewusst, dass das ein ziemlich subjektives Thema ist und ich denke wir würden uns da schon irgendwie einig werden. Im Notfall könnte man das ja sogar zweigleisig lizensieren usw. usf. ;). Überhaupt ist ja bisher bis auf ein paar Zeilen Testcode noch nichts programmiert bzw. veröffentlicht worden. Insofern hat auch diese Frage noch Zeit ;). Tim R. schrieb: > Schöner Einwand! Die "stillen Mitleser" habe ich noch gar nicht bedacht. Doch, doch, sei dir mal sicher, dass es davon auch ein paar gibt ;). Tim R. schrieb: > Der Master kann natürlich am Ende besprochen werden, ich hatte nur > gerade noch mal zwecks BBB geschaut. Ja, zur Zeit ist das katastrophal, hoffentlich wird es wieder mal besser ;). Der BBB würde mir persönlich gut zusagen. Tim R. schrieb: > Die im Video > verwendeten Sensoriken waren nicht mehr die best zu beschaffensten > oder?! Wie eingangs erwähnt, hatte ich mich letztes Jahr schon einige Zeit damit beschäftigt gehabt und bin zu dieser Auswahl gekommen, weil die zusammen passen, gut und günstig sind. Bei Digikey [1] [2] würden wir bei einer Stückzahl von 1000 in etwa 8 Cent pro Stück zahlen (16 Cent pro Pixel). Bei 2500 wird es sogar nochmal einen Cent billger ;). Ich glaube kaum, dass wir es günstiger schaffen, lasse mich aber gerne vom Gegenteil überzeugen. Der ATtiny841 [3] ist für um die 70-80 Cent zu beschaffen, d.h. wir liegen mit den drei "Hauptkomponenten" bei unter einem Euro. Ich persönlich bin immer noch der Meinung wir sollten den Strom durch die IR LED regelbar machen, um Alterungseffekten vorzubeugen und größtmögliche Flexibilität in Bezug auf die verwendeten Materialien zu haben. Klassische LED Treiber konnte ich bisher allerdings keine brauchbaren und zugleich günstigen finden. Derzeit arbeite ich an einer PWM Glättung mittels Tiefpass und einem folgenden Impedanzwandler. Problem ist aber, dass einfache OpAmps wie der LM358 nicht von Rail-to-Rail operieren, und damit weitere Spannungen nötig wären -> Wenig attraktiv ... Habe für Tipps ein offenes Ohr ;). Bei dieser Gelegenheit: Wie wollen wir das jetzt mit der Spannungsversorgung machen? Jedem Pixel einen Spannungswandler spendieren? Bei welcher Eingangsspannung? Bei 100+ Pixeln kommen ja mit klassischen Linearreglern auch ganz schöne Verluste zusammen. Bei 12 Volt Eingangsspannung, 5 Volt Ausgangsspannung und einem Stromfluss von 100 mA, wären das 0,7 W pro Pixel, zumindest bei voller Helligkeit. Auch nicht wirklich akzeptabel, oder? Dann lieber für eine ausreichend stabile 5 Volt Spannungsversorgung sorgen und alles "direkt" (mit Pufferkondensatoren auf den Pixelplatinen) dranhängen? Echt erstaunlich wie viel es zu beachten gibt, selbst bei so etwas "einfachem" wie einem LED Tisch. Und ob das alles nachher auf Anhieb klappt ist die nächste Frage ;). Im Zweifel hockt dann jeder auf 100+ Platinen und muss doch noch massive Handarbeit leisten - in der Hoffnung noch etwas retten zu können, dass wir in der Planungsphase übersehen haben -> GAU. Mit freundlichen Grüßen, Karol Babioch [1]: http://www.digikey.com/product-detail/en/PD204-6B/1080-1139-ND/2675630 [2]: http://www.digikey.com/product-detail/en/IR204/1080-1072-ND/2675563 [3]: http://www.digikey.com/product-search/en?k=attiny841&mnonly=0&newproducts=0&ColumnSort=1000011&page=1&stock=0&pbfree=0&rohs=0&quantity=&ptm=0&fid=0&pageSize=25
:
Bearbeitet durch User
Ich habe das mit der Lizens deshalb angesprochen, da ich mit meiner cad Software nichts erstellen darf was hinterher kommerziell genutzt wird. Ist leider eine Einschränkung die ich im Hinterkopf behalten muss. Ich würde auch für später vorschlagen alle Holzteile der Tische zusammen herzustellen um einfach Großhandelsware zu bekommen. Habe leztens erst wieder feststellen müssen das sich die Verleihmung von Bauhausbrettern schon durch lakieren anlößt und Fugen sichtbar werden. Gerade bei 2m wird es sehr stark auffallen.
Karol Babioch schrieb: > [1]: > http://www.digikey.com/product-detail/en/PD204-6B/... > [2]: http://www.digikey.com/product-detail/en/IR204/108... > [3]: > http://www.digikey.com/product-search/en?k=attiny8... Dann nehme ich alles zurück. Von mir aus können diese Komponenten gerne als "fest" betrachtet werden seanten schrieb: > Ich habe das mit der Lizens deshalb angesprochen, da ich mit > meiner cad > Software nichts erstellen darf was hinterher kommerziell genutzt wird. > Ist leider eine Einschränkung die ich im Hinterkopf behalten muss. Das ganze sollte ohne kommerzielle oder gewinnbringende Hintergründe laufen. Rein priv. Gebrauch :-)
Zum IR-Stromregel-Problem: Als Impedanzwandler (von der RC-Tiefpasskette am PWM-Ausgang auf die IR-LED) sollte es eigentlich auch ein Transistor tun. Ein bipolarer Transistor mit Emitterwiderstand stellt ja praktisch eine (basis-)spannungsgesteuerte Stromquelle dar. Zwei Probleme sehe ich dabei, die man durchrechnen/simulieren müßte: - der nötige Basisstrom errechnet sich aus LED-Strom und Stromverstärkungsfaktor des Transistors. Dieser Basisstrom belastet den Tiefpass, so daß man den nicht beliebig hochohmig bauen kann. - Timing: die Controller-Hardware gibt eine maximale PWM-Frequenz vor; damit ist eine minimale Zeitkonstante für den Tiefpass gegeben (abhängig von der genauen Schaltung und der gewünschten maximalen Restwelligkeit). Wenn sich herausstellt, daß das für die gewünschte Touch-Abfragefrequenz zu lahm ist, brauchen wir einen zweiten Controller-Pin, um die IR-LED schnell Ein- und Ausschalten zu können. Und wahrscheinlich einen zweiten Transistor. Das artet langsam in richtiges analoges Transistorschaltungsdesign aus… mit quadratzentimeterweise Hühnerfutter auf der Platine. Eigentlich sollte der geschickte µC-Einsatz genau das vermeiden, dachte ich immer...
Stiller Mitleser hier :-) Ich wäre an ca. 100 Modulen interessiert. Und um auch etwas der Diskussion beizutragen: Ich halte es auch für sinnvoll eine Möglichkeit vorzusehen den IR-Dioden Strom zu steuern. Und mit steuern meine ich nicht Regeln. Das wäre in der Tat übers Ziel hinausgeschossen für unsere Anwendung. Ich denke der Vorschlage von Nosnibor den Strom mit Hilfe eines Bipolartranistors und dessen Stromverstärung zu steuern für eine gute Idee. Das wird man aber tatsächlich testen müssen. Die komplexität dieser Schaltung halte ich aber für überschaubar..
Nosnibor schrieb: > Ein bipolarer > Transistor mit Emitterwiderstand stellt ja praktisch eine > (basis-)spannungsgesteuerte Stromquelle dar. Habe ich noch gar nicht dran gedacht, werde ich mal probieren. Mal sehen wie "stabil" das Ganze ist. Nosnibor schrieb: > Wenn sich herausstellt, daß das für die gewünschte Touch-Abfragefrequenz > zu lahm ist, brauchen wir einen zweiten Controller-Pin, um die IR-LED > schnell Ein- und Ausschalten zu können. Und wahrscheinlich einen zweiten > Transistor. Zur Zeit arbeite ich mit 125 Hz, das sollte also mehr als nur machbar sein. Ansonsten hätte der ATtiny841 wohl noch genug freie Pins ;). Nosnibor schrieb: > Eigentlich > sollte der geschickte µC-Einsatz genau das vermeiden, dachte ich > immer... Du darfst gerne weitere Vorschläge machen ;). Der typische PWM-Ansatz zur Intensitätssteuerung fällt hier halt weg, und damit kommt man wohl um eine externe Beschaltung nicht ganz herum. backemf schrieb: > Und mit steuern meine ich nicht Regeln. Zumindest ich habe die Worte in meinen obigen Beiträgen ziemlich synonym verwendet, was natürlich nicht ganz korrekt ist. Ja, eine Steuerung ist hier gut genug ;). backemf schrieb: > Die komplexität > dieser Schaltung halte ich aber für überschaubar.. Die Komplexität ist sicherlich noch überschaubar, allerdings machen solche "Konstrukte" es immer unattraktiver die Module per Hand zu bestücken - gerade, wenn wir auf SMD setzen. Insofern hoffe ich einfach mal, dass sich noch ein paar mehr Leute melden, sodass die Herstellung und Bestückung der Platinen günstiger wird ;). Wenn ich das jetzt richtig zusammen getragen habe, dann schaut die Situation bisher so aus (hatte mich selbst übrigens vergessen bisher): Conny G. 144 seanten 192 Holger W. 100+? Tim R. 100+? backemf 100 Karol Babioch 256 (16x16) Das wären bisher also so um die 800+ Module. Insofern sollte sich doch eine Möglichkeit finden die gut und günstig herzustellen, vor allem werden es ja potentiell immer noch mehr werden ;). Mit freundlichen Grüßen, Karol Babioch
Noch eine Variante zur Steuerung des IR-LED-Stroms: PWM-Ausgang --> RC-Glied --> Transistor mit Emitterwiderstand. PWM relativ langsam und mit niedrigem Tastgrad, d.h. man kann das PWM-Signal als einzelne kurze Pulse ansehen. Während des Pulses wird die Basisspannung am Transistor ungefähr linear steigen, in der Pause klingt sie dann mehr oder weniger exponentiell ab. Wenn der A/D-Wandler (und die Photodiode) deutlich schneller ist als diese Vorgänge, kann man einfach eine Messung kurz vor Anfang des Pulses machen (dann ist die LED aus) und die zweite gegen Ende des Pulses (dann hat die LED ihre maximale Helligkeit). Mit der Pulsdauer stellt man ein, bei welchem LED-Strom gemessen wird. Da die Schaltung normalerweise mit geringem Tastgrad betrieben wird (der LED-Strom muß ja in den Pausen auf 0 abklingen), wird sie bei dauer-H am PWM-Ausgang die IR-LED durchbrennen; das ist in der Entwicklungsphase zu beachten! Vorteil gegenüber dem vorigen Ansatz (D/A-Wandler per PWM) ist der geringere Schaltungsaufwand, weil nicht mehr so stark geglättet werden muß.
Nosnibor schrieb: > Noch eine Variante zur Steuerung des IR-LED-Stroms: Ok, danke für den Input! Du scheinst ja recht fit in Bezug auf diese Thematik zu sein. Hättest du zufällig konkrete Werte für die Widerstände bzw. Kondensatoren? Oder Lust das mal eben durchzurechnen? Bei der verwendeten Frequenz können wir wirklich von "langsam" ausgehen (< 1 kHz und weniger) - denk ich mal. Mit freundlichen Grüßen, Karol Babioch
Angehängte Dateien:
-
VOLTCRAFT10_1.gif
17 KB
Ich habe hier einen kleinen Versuchsaufbau zusammengestöpselt: ein Arduino, der eigentlich etwas ganz anderes machen soll, erzeugt alle 20ms einen H-Impuls von abwechselnd 2ms und 3ms Dauer. Dann kommen 10kΩ und 1µF, dann ein BC547C mit 33Ω am Emitter und einer roten LED nach +5V am Kollektor. Das Oszi zeigt den Eingangsimpuls und den Spannungsabfall am Emitterwiderstand. Man sieht den erwarteten fast linearen Anstieg und den exponentiellen Abfall. Der Anstieg setzt verzögert ein, weil unterhalb einer minimalen Basisspannung (ca. 0,6V) praktisch kein Strom fließt, und diese Spannung muß erstmal erreicht werden, das dauert (ca. 1ms). Aus dem gleichen Grund geht der Strom auch in der Pause auf 0 zurück, was bei einem echten exponentiellen Abfall ja ewig dauern würde. Außerdem sieht man sehr schön, daß unterschiedlich lange Pulse in unterschiedlich hohe verwandelt werden. Aber die Flanken sehen unangenehm steil aus: ob man da jetzt ein stabiles ADC-Signal erwarten kann, ist fraglich. Der Strom ist mit 15mA Spitzenwert zu klein; da könnte man den Kondensator verkleinern, damit höhere Basisspannungen schneller erreicht werden. Oder den Emitterwiderstand verkleinern.
Angehängte Dateien:
-
4bit_current_source.png
2,4 KB -
4bit_current_source_sch.png
34 KB
Die Lösung mit Tiefpass gefolgt von bipolar Transistor ist entgegen meiner Annahme wohl doch etwas heikler. Um einen Kollegktor strom von 100mA zu ermöglichen ist ein Basisstrom in der Gegend von 0.2-1mA nötig. Das macht es notwendig den R des RC niedrig zu wählen was wiederrum bedeutet das die Frequenz der PWM sehr hoch sein muss um bei Sinnvollen Kapazitäten die notwendige Filterwirkung zu erreichen. Ich hab jetzt mal eine Anderen Ansatz verfolgt der allerding 3-4 Pins des µc beanspruchen würde. Haben wir die? Damit ließe sich mit 3-4 digitalen Ausgängen der Strom in 8 bwz. 16 Stufen einstellen.
Die Pins haben wir wahrscheinlich, aber die Anzahl der Bauteile soll möglichst klein bleiben. In diesem Sinne: weg mit den Dioden, und die Portpins dann statt Ausgang-LOW auf Eingang schalten.
Nosnibor schrieb: > Die Pins haben wir wahrscheinlich, aber die Anzahl der Bauteile > soll > möglichst klein bleiben. In diesem Sinne: weg mit den Dioden, und die > Portpins dann statt Ausgang-LOW auf Eingang schalten. das Selbe kam mir auch gleich in den Sinn. Um die Pins mache ich mir weniger Sorgen, sondern eher um den Platzbedarf der Kleinbauteile
Nosnibor schrieb: > In diesem Sinne: weg mit den Dioden, und die > Portpins dann statt Ausgang-LOW auf Eingang schalten. Die Dioden sind nur da um einen high-imp state der µC IOs zu simulieren. Die wären natürlich nicht notwendig. Notwendig wären nur 2 Transistoren und 6 Widerstände.
backEMF schrieb: > Die Dioden sind nur da um einen high-imp state der µC IOs zu simulieren. > Die wären natürlich nicht notwendig. > Notwendig wären nur 2 Transistoren und 6 Widerstände. OK, das leuchtet ein, deshalb auch "ideale" Dioden. Interessant wäre jetzt, wenn man mit aktivem LOW-Pegel auch noch etwas sinnvolles anfangen könnte, so daß man mit vier Ausgängen auf 81 verschiedene LED-Ströme käme.
Schön, dass sich da sogar mehrere Leute Gedanken drüber machen. Ich persönlich bin mittlerweile kurz davor doch noch zum CAT4003B zu greifen. Der bietet 3 Kanäle mit jeweils 25 mA und bietet 32 programmierbare Stufen. Wenn wir die drei Kanäle parallel schalten und die IR-LED damit bedienen, dann haben wir 32 Stufen und können den Stromfluss zwischen 0 und 75 mA steuern. Externe Beschaltung ist auch so gut wie keine nötig. Kostenpunkt: ~ 35 Cent. Ich lasse mich von euren kreativen Vorschlägen aber gerne überzeugen, sofern ihr der Meinung seid, dass es gut genug für unseren Anwendungsfall ist ;). Mit freundlichen Grüßen, Karol Babioch
35 Cent sind echt günstig für den Treiber. Mit der Transistorlösung sind war auch schon bei 20cent.16 stufen halte ich für ausreichend. Ich werde das ganze mal ausprobieren und berichten.
backEMF schrieb: > 35 Cent sind echt günstig für den Treiber. Ja, sehe ich auch so. Andererseits macht sich in diesem Fall halt wirklich jeder Cent bemerkbar -- bei potentiell tausenden von Modulen. Der Treiber würde uns halt viele externe Bauteile ersparen. Das einzige Problem: Im Datenblatt wird immer davon ausgegangen, dass man 3 einzelne LEDs betreibt. Wie sich der Baustein bei ein und der selben LED verhält, kann ich nicht sagen. Überhaupt wird (zumindest meiner Meinung nach) nicht klar wie der Treiber intern arbeitet. Von PWM ist nämlich keine Rede (also Linearregler?), während es bei anderen Treibern in dieser Preisklasse immer erwähnt wird. Vielleicht kann sich ja jemand mit mehr Erfahrung das Datenblatt ansehen und beurteilen, ob das so klappen könnte wie ich es mir vorstelle [1]. Für etwa 5 Cent mehr gäbe es auch den CAT4004B, d.h. 4 Kanäle, also bis zu 100 mA. Sinnvoll? An sich würde ich die IR LED einfach parallel an alle 3 bzw. 4 Kanäle hängen und hätte damit in 32 Stufen. Die Ansteuerung kann mittels jedem beliebigen Pin erfolgen, da die Timings aus Sicht eines Mikrocontrollers ziemlich einfach einzuhalten wären. Man kann halt nur in eine Richtung schalten, d.h. ggf. muss man mittels einem Wrap-Around zum gewünschten Level, wobei 32 Toggles selbst ohne Interrupt basiertem Ansatz kein Problem darstellen sollten. backEMF schrieb: > Ich werde das ganze mal ausprobieren und berichten. Super, bin gespannt ;). Mit freundlichen Grüßen, Karol Babioch [1]: http://www.onsemi.com/pub/Collateral/CAT4003B-D.PDF
:
Bearbeitet durch User
welche Vorteile bringt denn die Steuerung des Stroms für die IR-LED? bringt das nicht eher Nachteile mit sich weil die Diode entsprechend mal "mehr" und mal "weniger" erkennt und dadurch die Werte sehr variieren können? Kann mich auch gerade komplett täuschen
blobba schrieb: > welche Vorteile bringt denn die Steuerung des Stroms für die IR-LED? Ein Vorteil ist das sich mögliche alterunseffekte der IR-LED ausgleichen ließen. Wobei ich die Alterung eher unkritisch sehe. Die meiste Zeit könnte die LED ja aus sein. Und möglicherweise ist es notwendig die Leistung an verschiedene Tische anpassen zu können.(Glas, Abstand, Reflektionen etc.) In wie weit das Sinn macht weiß ich nicht. Möglicherweise lässt sich ja auch mehr Information genwinnen indem man immer bei mehreren IR intensisäten mißt? Ich denke wir sollten bevor wir dne Strom veränderlich machen erst abklären ob es überhaupt einen klaren benefit gibt.
backEMF schrieb: > Ich denke wir sollten bevor wir dne Strom veränderlich machen erst > abklären ob es überhaupt einen klaren benefit gibt. Sehe ich genauso. Wieviele 10.000 Stunden hält so eine IR-Diode? Wieviele Stunden am Tag ist der Tisch eingeschaltet? Ich halte diese "Untersuchungen" für rein akademisch. IR-Diode per Widerstand an einen (PWM-)Portpin und fertig.
Frank M. schrieb: > Sehe ich genauso. Wieviele 10.000 Stunden hält so eine IR-Diode? > Wieviele Stunden am Tag ist der Tisch eingeschaltet? > > Ich halte diese "Untersuchungen" für rein akademisch. IR-Diode per > Widerstand an einen (PWM-)Portpin und fertig. war auch mein Gedanke. lässt das Vorhaben hier in eine etwas andere Richtung laufen denke ich...
Frank M. schrieb: > Ich halte diese "Untersuchungen" für rein akademisch. IR-Diode per > Widerstand an einen (PWM-)Portpin und fertig. Einen kleinen Transistor wird schon notwendig sei. Die 20mA vom Portpin werden nicht reichen.
hm der rest hier keine lust mehr oder schon mit einem bierchen in der sonne ?? ;-P
Das Thema ist zwar schon abgehakt, trotzdem dieser Nachtrag: Um dem Effekt "Unerwünschte Erkennung von Gegenständen über benachbarten Zellen" entgegenzuwirken, könnte man die IR-LED in eine Ecke der Zelle und die IR-Photodiode in die diagonal gegenüberliegende Ecke setzen. Der von der Zelle IR-beleuchtete und gleichzeitig gesehene Bereich beschränkt sich dabei im Wesentlichen auf den Raum direkt über der Zelle. Die Auswertung sollte im 2x2- oder 3x3-Raster erfolgen, damit die benachbarten Zellen nicht stören.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.