Forum: Mikrocontroller und Digitale Elektronik LED Tisch mit Berührungs-/Gegenstandserkennung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tim R. (herrvorragend)


Lesenswert?

Hallo allerseits,

ich bin momentan ein wenig am überlegen, ob ich eine Blitzidee von mir 
einfach mal umsetze.
Vorweg: Ich habe Erfahrung mit Mikrocontrollern, Programmierung etc.... 
zwar etwas eingerostet, aber das sollte reaktivierbar sein :)

Ich möchte gerne einen Tisch (ca. 1m x 2m) mit einer (Milch)Glasplatte 
mit LEDs bzw. RGBs versehen um einen schönen Leuchteffekt zu erhalten. 
Das ist soweit relativ einfach. Zusätzlich möchte ich aber eine 
Erkennung/Sensorik, ob beispielsweise eine Hand oder ein Glas auf dem 
Tisch steht, um diese Stelle andersfarbig leuchten zu lassen.

Mich würde interessieren, ob jemand Ideen hat, wie man relativ 
zuverlässig solch eine Erkennung durchführen kann bzw was gibt es für 
relevante Sensoriken?! Ich habe an Fotowiderstände oder 
Berührungssensoren gedacht. Bei denen bräuchte man nur eine ganze Menge 
oder?

Im Internet habe ich nur vereinzelte Themen gesehen wie diesen: 
http://www.mikrocontroller.net/topic/326455 der leider wohl gelöscht 
wurde :( Thema: "Gegenstands-Erkennung für RGB-LED-Table - 
Mikrocontroller.net"

Danke schon mal für alle konstruktiven Antworten

von Markus M. (adrock)


Lesenswert?

...warum wurde denn der andere Thread gelöscht?

Verstehe ich nicht...

Grüße
Markus

von stef (Gast)


Lesenswert?

die käuflichen Versionen machen das mit infrarot Reflex 
Lichtschranken... (ist kein michlglas)

suche mal nach: interaktiver led tisch

Ich denke das müsste über ein Kapazitiven Sensor gehen.

von Markus M. (adrock)


Lesenswert?

...wurde ja in dem anderen Thread schon alles besprochen:

- Fertigen Infrarot Proximity Sensor nehmen (Nachteil: ca. 2,50 EUR pro 
Sensor)

- Selbst mit IR-LED und Photodiode/Transistor etwas ähnliches bauen

- Kapazitiv (Nachteil: Drähte o.ä. notwendig

von Tim R. (herrvorragend)


Lesenswert?

Markus M. schrieb:
> ...wurde ja in dem anderen Thread schon alles besprochen:
>
> - Fertigen Infrarot Proximity Sensor nehmen (Nachteil: ca. 2,50 EUR pro
> Sensor)
>
> - Selbst mit IR-LED und Photodiode/Transistor etwas ähnliches bauen
>
> - Kapazitiv (Nachteil: Drähte o.ä. notwendig

wie beschrieben, konnte ich den anderen Thread leider nicht ansehen, 
aber danke schonmal für die Infos!

von Markus M. (adrock)


Lesenswert?

Also der Threadersteller des gelöschten Threads hatte noch viele IR-LEDs 
und Photodioden zu liegen und wollte sie verwenden.

Der Gedanke war:

- die IR-LEDs zu modulieren (um das Umgebungslicht zu unterdrücken)
- die Änderungen der Spannung an der Photodiode zu Verstärken und über 
einen Analogmultiplexer auf den A/D-Wandler eines µC zu geben
- aus Änderungen in der Amplitude des Signals müsste sich dann erkennen 
lassen, ob sich etwas an der Reflexion für dieses Quadrat geändert hat 
(Gegenstand auf dem Tisch)

So die Theorie.

Mit fertigen Näherungssensoren ist es noch einfacher, diese beinhalten 
schon eine gewisse Intelligenz, lassen sich teileise sogar noch über I²C 
programmieren (Empfindlichkeit etc.), kosten aber eben mehr, im Bereich 
2-3 EUR / Stück.

Man müsste das ganze mal in einem Testaufbau verifizieren inwieweit die 
einzelnen Möglichkeiten überhaupt funktionieren für den gegebenen Aufbau 
der Oberfläche (Glas, milchig), da habe ich keine Ahnung.

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

Markus M. schrieb:
> Also der Threadersteller des gelöschten Threads hatte noch viele IR-LEDs
> und Photodioden zu liegen und wollte sie verwenden.
>
> Der Gedanke war:
>
> - die IR-LEDs zu modulieren (um das Umgebungslicht zu unterdrücken)
> - die Änderungen der Spannung an der Photodiode zu Verstärken und über
> einen Analogmultiplexer auf den A/D-Wandler eines µC zu geben
> - aus Änderungen in der Amplitude des Signals müsste sich dann erkennen
> lassen, ob sich etwas an der Reflexion für dieses Quadrat geändert hat
> (Gegenstand auf dem Tisch)
>
> So die Theorie.

theorie ist immer gut hehe... wie gut die dioden im endeffekt waren weiß 
niemand ? :)

>
> Mit fertigen Näherungssensoren ist es noch einfacher, diese beinhalten
> schon eine gewisse Intelligenz, lassen sich teileise sogar noch über I²C
> programmieren (Empfindlichkeit etc.), kosten aber eben mehr, im Bereich
> 2-3 EUR / Stück.

in einer fixen suche bin ich nur auf sau teure sensoren gestoßen, hat 
jemand mal einen link? ich glaub ich habe an der falschen stelle gesucht

>
> Man müsste das ganze mal in einem Testaufbau verifizieren inwieweit die
> einzelnen Möglichkeiten überhaupt funktionieren für den gegebenen Aufbau
> der Oberfläche (Glas, milchig), da habe ich keine Ahnung.

ja das wäre sehr interessant zu wissen

von Markus M. (adrock)


Lesenswert?

Habe mal bei Digikey geschaut, interessant waren die Sensoren von:

TAOS (TSLxxxx), z.B. TSL26711FN:

- Infrarot
- Programmierbar über I²C
- inkl. Konstantstromquelle für die IR-LED
- Anzahl Pulse einstellbar etc.
- "Interrupt" Ausgang signalisiert Annäherung
- Preis: DK 0,50€ für 3000 Stk :-), Mouser ca. 0,80€, keine 
Mindestbestellmenge.

- Gibt noch andere Serien, z.B. TSL2771, noch empfindlicher, 1,10€ ab 
100 Stk.

Weitere ähnliche Sensoren:

- Avago APDS-9120, Sender und Empfänger integriert, Preis/Stk: 1,69€ 
(RS, ab 10)
- IS31SE5001 (schlecht verfügbar)
- Si1102, Preis/Stk: 2,34€ (RS)
- IS471F, Preis/Stk: 2,64€ (RS, ab 100), einziger bedrahteter Sensor

Wenn man den ganzen Aufwand nimmt, dürfte ab einer bestimmten Stückzahl 
ein fertiger Sensor günstiger sein... man bedenke auch, dass man 
hunderte davon einlöten/bestücken muss...

: Bearbeitet durch User
von Borislav B. (boris_b)


Lesenswert?

Ich muss mich hier auch mal als RGB-Table-Fan outen ;-)

Bei meiner Planung bin ich auf folgende Kombination gestoßen:

IR-LED "SFH 409", 0,15€
IR-Empfänger "TSOP31238", 0,66€

Kommt also zusammen auf 0,81€ pro Pixel. Der Empfänger arbeitet auf 
38khz, wenn man die LED also entsprechend moduliert, sollte das ganze 
sich nicht durch Umgebungslicht stören lassen.
(Die Wellenlängen habe ich bei der Auswahl der Komponenten nicht 
berücksichtigt, da müsste man also nochmal schauen, dass die LED auch 
wirklich zum Empfänger passt)

Was meint ihr? Könnte das hinhauen?
Wäre auf jeden Fall eine schön günstige Lösung.

von Tim R. (herrvorragend)


Lesenswert?

Markus M. schrieb:
>
> Wenn man den ganzen Aufwand nimmt, dürfte ab einer bestimmten Stückzahl
> ein fertiger Sensor günstiger sein... man bedenke auch, dass man
> hunderte davon einlöten/bestücken muss...


danke für deine Mühe... ich stehe jetzt nur gerade etwas auf dem 
Schlauch, was du mit fertig Sensor genau meinst? aber ich muss gestehen 
bin grad frisch von Arbeit gekommen, muss am we erstmal die ganzen 
Daten/Bauteile auswerten die hier zusammengetragen wurden


Boris P. schrieb:
> Ich muss mich hier auch mal als RGB-Table-Fan outen ;-)
>
> Bei meiner Planung bin ich auf folgende Kombination gestoßen:
>
> IR-LED "SFH 409", 0,15€
> IR-Empfänger "TSOP31238", 0,66€
>
> Kommt also zusammen auf 0,81€ pro Pixel. Der Empfänger arbeitet auf
> 38khz, wenn man die LED also entsprechend moduliert, sollte das ganze
> sich nicht durch Umgebungslicht stören lassen.
> (Die Wellenlängen habe ich bei der Auswahl der Komponenten nicht
> berücksichtigt, da müsste man also nochmal schauen, dass die LED auch
> wirklich zum Empfänger passt)
>
> Was meint ihr? Könnte das hinhauen?
> Wäre auf jeden Fall eine schön günstige Lösung.


schön einen weiteren Fan gefunden zu haben hehe
die Kombination ist wirklich günstig! hierzu sollte aber erst ein kurzer 
Test durchgeführt werden, ob das ganze auch dementsprecht zusammen 
funktioniert. Meine größte Sorge ist immernoch, wie sich das ganze 
Verhalten mit (Plexi-)Glas auswirkt. Glaube hier müsste ich selber mal 
eine kleine Testreihe starten oder gibt es hierzu schon Videos oder 
ähnliches die sehr aussagend sind ? :-)

für alle die es nicht kennen: ich habe gestern einen interessanten Link 
gefunden
http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html

von Chefkoch (Gast)


Lesenswert?

Qtouch?

von Basti (Gast)


Lesenswert?

Hatte unter meinem RGB Tisch mal 4 DMS getestet...


Ging ganz gut, hab es aber nicht weiter verfolgt...
Das Problem ist, kein Multitouch und herausfiltern von Querverspannungen 
bzw. eine gute mechanische Umsetzung ;)

Dafür kannst du natürlich reale Gewichte auflösen und sagen: oh, großer 
Schluck... du bist aber durstig ;)

Hab auch nen kleines YouTube Video das den Touch kurz demonstriert: 
SFCounterfeiter dort mein Name... Link mit Handy suchen, is immer so 
unpraktisch ;)

Grüße

Basti

von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> schön einen weiteren Fan gefunden zu haben hehe

Ich hoffe am Ende dieses Threads hat jeder von uns so einen RGB-Tisch 
zuhause stehen ;-)

Tim R. schrieb:
> die Kombination ist wirklich günstig! hierzu sollte aber erst ein kurzer
> Test durchgeführt werden, ob das ganze auch dementsprecht zusammen
> funktioniert. Meine größte Sorge ist immernoch, wie sich das ganze
> Verhalten mit (Plexi-)Glas auswirkt.

Laut Datenblatt passen die beiden zusammen (950nm Wellenlänge). Wäre 
noch zu testen, wie sich das in der Praxis verhält (Reflektionen am 
Plexiglas?).
Aber bei dem Herrn aus deinem Link hat es ja genau so funktioniert...

Tim R. schrieb:
> Glaube hier müsste ich selber mal eine kleine Testreihe starten

Ist halt nur immer blöd so ein paar einzelne Teile zu bestellen. Oder 
hast du einen Conrad um die Ecke?

Wie sieht es eigentlich mit den anderen Komponenten aus? Werden die hier 
auch disktutiert?
(Logik der Knoten, Bus, Controller & Ansteuerung, Stromversorgung usw.)
Ggf. könnte man ja eine Projektseite im Wiki starten? Oder den Thread zu 
den Projekten verschieben?

von Tim R. (herrvorragend)


Lesenswert?

Basti schrieb:
> Hatte unter meinem RGB Tisch mal 4 DMS getestet...
>
>
> Ging ganz gut, hab es aber nicht weiter verfolgt...
> Das Problem ist, kein Multitouch und herausfiltern von Querverspannungen
> bzw. eine gute mechanische Umsetzung ;)
>
> Dafür kannst du natürlich reale Gewichte auflösen und sagen: oh, großer
> Schluck... du bist aber durstig ;)
>
> Hab auch nen kleines YouTube Video das den Touch kurz demonstriert:
> SFCounterfeiter dort mein Name... Link mit Handy suchen, is immer so
> unpraktisch ;)
>
> Grüße
>
> Basti

netter tisch, finde das design auch relativ modern gehalten, aber 
schicht und gut :) die größe geht in ordnung, viel größer würde ich auch 
nicht gehen wollen. verrätst du deine technik dahinter?

also das projekt nimmt natürlich viel zeit und kosten in anspruch, 
sodass erst in ein paar wochen/monaten ergebnisse sichtbar werden. Das 
ganze neben der arbeit machen, macht es nicht unbedingt leichter gg 
also das direkt zu den projekten schieben würde ich nicht

aber an sich generell die ansteuerung, versorgung etc. kann hier gerne 
besprochen werden

von Markus M. (adrock)


Lesenswert?

Naja, zu der Auswertung der Sensoren hatten wir uns auch schon Gedanken 
gemacht.

Für die Beleuchtungs-LEDs könnte man der Einfachheit halber einfach die 
WS2812B nehmen.

Um die Werte der Sensoren abzufragen, könnte man entweder mehrere 
ATtinys per SPI koppeln, oder die Werte per Multiplexer abfragen.

Mit 8x 8-Bit Muitiplexern könnte man schon 256 Eingänge abfragen (8 oder 
16 I/O-Pins am Controller vorausgesetzt).

Analogmultiplexer sind auch nicht viel teurer, falls man mit Analogen 
Werten und A/D-Wandler arbeiten muss.

Eine andere Überlegung war auch für jeden Pixel einen kleinen ATtiny zu 
nehmen, der die IR-LED steuert und die Photodiode auswertet und man die 
Ergebnisse irgendwie per SPI Daisy-Chain dann abfragt... wobei 
wahrscheinlich die Implementierung dieses Pixelsensors dann schon ein 
eigenes Projekt wird...

von Tim R. (herrvorragend)


Lesenswert?

Markus M. schrieb:
> Naja, zu der Auswertung der Sensoren hatten wir uns auch schon Gedanken
> gemacht.
>
> Für die Beleuchtungs-LEDs könnte man der Einfachheit halber einfach die
> WS2812B nehmen.
>
> Um die Werte der Sensoren abzufragen, könnte man entweder mehrere
> ATtinys per SPI koppeln, oder die Werte per Multiplexer abfragen.
>
> Mit 8x 8-Bit Muitiplexern könnte man schon 256 Eingänge abfragen (8 oder
> 16 I/O-Pins am Controller vorausgesetzt).
>
> Analogmultiplexer sind auch nicht viel teurer, falls man mit Analogen
> Werten und A/D-Wandler arbeiten muss.
>
> Eine andere Überlegung war auch für jeden Pixel einen kleinen ATtiny zu
> nehmen, der die IR-LED steuert und die Photodiode auswertet und man die
> Ergebnisse irgendwie per SPI Daisy-Chain dann abfragt... wobei
> wahrscheinlich die Implementierung dieses Pixelsensors dann schon ein
> eigenes Projekt wird...

die WS2812B sind ja interessant, kenn ich auch noch nicht. wenn ich das 
richtig gesehen habe brauchen die eine versorgungsspannung und eine 
datenleitung, wo der spezifikation entsprechend die daten in den 
korrekten zeiten gesendet werden um eine farbe zu erhalten, ist das 
richtig?!

an multiplexen hatte ich zu aller erst gedacht. einzige problem wäre 
glaube ich nur ein mehraufwand der verkabelung

du meinst also kleine platinen für jeden pixel entwerfen? ich glaube der 
bastler in dem link den ich gepostet habe, hatte es genau so gemacht... 
man hätte dann zig kleine platinen mit jeweils sensor und led drauf... 
puh das würde eine ganz schöne arbeit mit sich ziehen

von Tim R. (herrvorragend)


Lesenswert?

Boris P. schrieb:

>
> Ist halt nur immer blöd so ein paar einzelne Teile zu bestellen. Oder
> hast du einen Conrad um die Ecke?
>


und ja... ich habe in berlin gleich drei conrad läden, wenn ich es 
richtig in erinnerung habe ;)

von Markus M. (adrock)


Lesenswert?

...ja, die WS2812(B) sind schon sehr cool, nur die Ansteuerung ist nicht 
trivial, aber es gibt inzwischen viele Libraries dafür.

Man kann sie praktisch als Kette direkt zusammenhängen und jede LED 
reicht dann die Daten an die nächste weiter, nachdem sie "ihre" Daten 
empfangen hat.

Ich habe mir jetzt mal bei RS diesen Avago Näherungssensor APDS-9120 
bestellt zum probieren.

Der hat sowohl die IR-LED als auch den Empfänger gleich eingebaut. D.h. 
man benötigt keine weiteren externen Komponenten für die 
Näherungserkennung.

Mal sehen ob er tut...

Grüße
Markus

von Tim R. (herrvorragend)


Lesenswert?

Markus M. schrieb:
> ...ja, die WS2812(B) sind schon sehr cool, nur die Ansteuerung ist nicht
> trivial, aber es gibt inzwischen viele Libraries dafür.
>
> Man kann sie praktisch als Kette direkt zusammenhängen und jede LED
> reicht dann die Daten an die nächste weiter, nachdem sie "ihre" Daten
> empfangen hat.
>
> Ich habe mir jetzt mal bei RS diesen Avago Näherungssensor APDS-9120
> bestellt zum probieren.
>
> Der hat sowohl die IR-LED als auch den Empfänger gleich eingebaut. D.h.
> man benötigt keine weiteren externen Komponenten für die
> Näherungserkennung.
>
> Mal sehen ob er tut...
>
> Grüße
> Markus

klasse deine schnellen antworten!
versteh ich das richtig, dass du solch ein projekt ebenfalls umsetzen 
magst?! das kam hier bisher gar nicht zum ausdruck

aber super, dann warte ich einfach mal deine ergebnisse ab. besteht die 
möglichkeit zum testen mit glas/plexiglas?

grüße
tim

von Borislav B. (boris_b)


Lesenswert?

Hui, die sind aber saftig teuer. Für das Geld lässt sich ja schon die 
komplette Pixel-Platine inkl. µC, RGB-LED, Sensoren und Perepherie 
umsetzen.

Ich finde auch die Lösung mit intelligenten Pixeln am sinnvollsten. Dann 
reicht eine einzige Datenleitung als Bus, um die Farbinformationen und 
die Sensordaten bidirektional zu übertragen. Der Verkabelungsaufand ist 
zudem minimal.

von Markus M. (adrock)


Lesenswert?

Also für einen konkretes Tischprojekt fehlt mir ehrlich gesagt momentan 
die Zeit und das Kleingeld.

Aber ich finde die Sensoren interessant, deswegen mache ich jetzt mal 
einen Konzepttest ob das überhaupt so funktionieren kann.

Allerdings habe ich keine genaue Ahnung wie sich Milch(Plexi)glas 
auswirkt, also ob es damit überhaupt noch funktioniert.

Mit klarem Glas bzw. ohne jegliche Mattierung wolltest Du das doch nicht 
machen nehme ich ma an?

von Basti (Gast)


Lesenswert?

Hallo,

danke für die Blumen... die Frge ist ja weniger, wie habe ichs gebaut... 
sondern, wie würde ich es heute bauen ;)

Also WS2812 ist schnell und sinnvoll. Leider sind die sehr hell für 
einen Tisch und beim Dimmen fehlt die Dynamik! Würde hier 16 Bit PWM 
Treiber der Chinesen verbauen -> MySemi!

Ansonsten habe ich 4 DMS aus jeweils einer Ebay ramsch Küchenwaage 
geholt ud fix und fertig DMS ICs mit 24 Bit Auflösung von TI 
gesampelt... brauchbar waren davon immerhin 17 Bit und das hat für 0,25 
Gramm gereicht ;)

Die Mechanik muss so gestaltet sein, dass es absolut Spannungsfrei 
arbeitet -> sehr schwieirg...

Elektrisch gesehen, ist es eher kein Kunstwerk... je nach Erfahrung... 
also Waagen und DMS Platinen plus Bauteile: 40€...
Auflösung definitiv viel höher als es deine Matrix sein wird ;)

Viel Erfolg!

Und macht euch mit IR nicht arm :D

Grüße

Basti

von Sabine (Gast)


Lesenswert?

Und das ganze irgendwie mit Ultraschall maschen? An mehreren Stellen 
Ultraschall ins Glas schicken bzw. detektieren und über die geänderte 
Dämpfung oder über Reflektionen auf die berührte Stelle schleissen. Es 
gibt ja auch robuste Touchdisplay, die mit sowas arbeiten.

Sabine

von Basti (Gast)


Lesenswert?

Klingt auch interessant, nur ist das für den Hobbisten sicher nicht so 
einfach umsetzbar... Mechanisch gesehen... Signalaufbereitung sicher 
auch nicht ohne

von Borislav B. (boris_b)


Lesenswert?

Basti schrieb:
> Klingt auch interessant, nur ist das für den Hobbisten sicher nicht so
> einfach umsetzbar... Mechanisch gesehen... Signalaufbereitung sicher
> auch nicht ohne

Und spätestens bei Multitouch wirds dann ganz schön haarig. Und gerade 
das würde bei so einem Tisch ja richtig gut kommen.

von Tim R. (herrvorragend)


Lesenswert?

http://shop.led-studien.de/de/elektronik-bausatze/led-pixel/rgb-pixel-50x50mm-inkl.-wannen-kabel

rein für die beleuchtung könnte man alternativ auch fertige pixel 
platinchen verwenden. der nachteil wäre nur, dass die sensorik für die 
touch funktionalität noch irgendwie extra behandelt werden müsste


hehe und beim suchen bin ich auf ein forenbeitrag gestoßen, wo jemand 
gerade frisch anfängt einen tisch zu bauen !

http://www.ledhilfe.de/viewtopic.php?f=35&t=18413

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

Boris P. schrieb:
> Hui, die sind aber saftig teuer. Für das Geld lässt sich ja schon die
> komplette Pixel-Platine inkl. µC, RGB-LED, Sensoren und Perepherie
> umsetzen.
>
> Ich finde auch die Lösung mit intelligenten Pixeln am sinnvollsten. Dann
> reicht eine einzige Datenleitung als Bus, um die Farbinformationen und
> die Sensordaten bidirektional zu übertragen. Der Verkabelungsaufand ist
> zudem minimal.

ich stimme dir zu. pixelplatinen bringe vorteile, wie schnelle 
austauschbarkeit und erweiterbarkeit mit sich

willst du auf diese platinen jeweils einen controller verbauen?! oder 
einen zentralen uC ?
ich frage mich nur gerade, wie du über eine leitung die farbinformation 
vom uC zur rgb und die sensor information zum uC tragen willst. quasi im 
polling den portpin von umschalten?

von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> willst du auf diese platinen jeweils einen controller verbauen?! oder
> einen zentralen uC ?
> ich frage mich nur gerade, wie du über eine leitung die farbinformation
> vom uC zur rgb und die sensor information zum uC tragen willst. quasi im
> polling den portpin von umschalten?

Ich habe vor auf jeden Pixel einen Controller zu setzen. Ein ATTinyXX 
eignet sich vermutlich am besten. Diese gibts bei geschickter auswahl 
schon ab 0,40€ das Stück.

Als "Master" schwebt mir ein Beaglebone Black vor. Der ist über 
LAN/WLAN/Bluetooth super von außen zu erreichen und kann auch komplexe 
Programme laufen lassen (animierte Fraktale auf den Tisch rendern usw.). 
Zusätzlich ist er klein, lüfterlos, verbraucht wenig Strom und kostet 
nicht viel.

Für den Bus würde ich eine Art I2C nehmen. Also nur zwei dünne 
Leitungen. Bidirektionale Kommunikation sollte damit recht leicht gehen:

Richtung 1: Master sendet Adress-Byte gefolgt von 3 Datenbytes (RGB). 
Der Slave mit der passenden Adresse übernimmt die Daten und lässt seine 
LED entsprechend leuchten.

Richtung 2: Master sendet nur die Adresse. Danach wartet er ein Bit 
lang, und lauscht auf dem Bus. Der Slave mit der entsprechenden Adresse 
nutzt diese Pause, um eine 1 oder 0 auf den Bus zu legen (Touch oder 
kein Touch). Der Master liest das Bit, und fragt dann den nächsten 
Slave.

Der Beaglebone Black hat übrigens noch zwei Realtime-Co-Prozessoren, 
über die sich so eine Kommunikation mühelos erledigen lässt (5ns 
Zykluszeit). Damit sollten gute 50Hz (RGB Daten + Touch Daten 
Übertragung) machbar sein.

PS: Je nach Anzahl der Pixel sollte man den Tisch vielleicht aufteilen, 
so dass der Master nur jede Zeile anspricht. In jeder Zeile spricht dann 
wiederrum der erste Controller mit allen anderen Controllern in der 
Zeile. So lassen sich probleme mit Spannungsverlusten bei langer 
Leitungslänge vermeiden und die Datenrate erhöhen.

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

Boris P. schrieb:
> Tim R. schrieb:
>> willst du auf diese platinen jeweils einen controller verbauen?! oder
>> einen zentralen uC ?
>> ich frage mich nur gerade, wie du über eine leitung die farbinformation
>> vom uC zur rgb und die sensor information zum uC tragen willst. quasi im
>> polling den portpin von umschalten?
>
> Ich habe vor auf jeden Pixel einen Controller zu setzen. Ein ATTinyXX
> eignet sich vermutlich am besten. Diese gibts bei geschickter auswahl
> schon ab 0,40€ das Stück.
>
> Als "Master" schwebt mir ein Beaglebone Black vor. Der ist über
> LAN/WLAN/Bluetooth super von außen zu erreichen und kann auch komplexe
> Programme laufen lassen (animierte Fraktale auf den Tisch rendern usw.).
> Zusätzlich ist er klein, lüfterlos, verbraucht wenig Strom und kostet
> nicht viel.

von den beagleboards habe ich schon gehört/gelesen, scheint ja aller 
hand positive aspekte mit sich zu bringen solch ein board. mein problem 
ist der dortige arm prozessor. ich bin atmel und microchip gewöhnter. 
ich habe quasi null ahnung von arm und würde mir an dieser stelle 
unnötige probleme vermeiden wollen. aber ansonsten eine nette auswahl!

>
> Für den Bus würde ich eine Art I2C nehmen. Also nur zwei dünne
> Leitungen. Bidirektionale Kommunikation sollte damit recht leicht gehen:
>
> Richtung 1: Master sendet Adress-Byte gefolgt von 3 Datenbytes (RGB).
> Der Slave mit der passenden Adresse übernimmt die Daten und lässt seine
> LED entsprechend leuchten.
>
> Richtung 2: Master sendet nur die Adresse. Danach wartet er ein Bit
> lang, und lauscht auf dem Bus. Der Slave mit der entsprechenden Adresse
> nutzt diese Pause, um eine 1 oder 0 auf den Bus zu legen (Touch oder
> kein Touch). Der Master liest das Bit, und fragt dann den nächsten
> Slave.

ok solch eine kommunikation habe ich noch nicht in betracht gezogen, 
sollte aber machbar sein (solange keine störungen auftreten). an dieser 
stelle kam mir auch der gedanke, wie schnell das polling aller 
teilnehmer durchgeführt werden kann. also ob locker "50fps" oder mehr 
erreicht werden, müsste man evtl mal ausrechnen
>
> Der Beaglebone Black hat übrigens noch zwei Realtime-Co-Prozessoren,
> über die sich so eine Kommunikation mühelos erledigen lässt (5ns
> Zykluszeit). Damit sollten gute 50Hz (RGB Daten + Touch Daten
> Übertragung) machbar sein.
>
> PS: Je nach Anzahl der Pixel sollte man den Tisch vielleicht aufteilen,
> so dass der Master nur jede Zeile anspricht. In jeder Zeile spricht dann
> wiederrum der erste Controller mit allen anderen Controllern in der
> Zeile. So lassen sich probleme mit Spannungsverlusten bei langer
> Leitungslänge vermeiden und die Datenrate erhöhen.

du meinst einen master und für jede zeile oder spalte einen co-master? 
dieser soll dann seine ganz zeile "abchecken" und zurück zum master 
übersenden, sodass der master effektiv mit 5-10 seiner co-master 
kommuniziert und der arbeitsaufwand gering gehalten wird?

von Tim R. (herrvorragend)


Lesenswert?

an sich gefällt mir der gedanke zum übertragen, es werden eigtl keine 
mux mehr benötigt und mit einem draht hat man sehr wenig 
verkabelungsaufwand... vllt könnte man beim "protokoll" noch ein bit 
spendieren um anzugeben ob read oder write vorgang vom master ausgelöst 
wird, rein zur absicherung

ansonsten ist das hier ja schon mal eine gute entwicklung, danke :)

von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> mein problem
> ist der dortige arm prozessor. ich bin atmel und microchip gewöhnter.
> ich habe quasi null ahnung von arm und würde mir an dieser stelle
> unnötige probleme vermeiden wollen. aber ansonsten eine nette auswahl!

Das Gute ist, dass du den dann in jeder Sprache programmieren kannst, 
auch high level. Also Python, Java (script), C#, C++, C, Assembler. Da 
sollte für jeden was dabei sein ;-)

Tim R. schrieb:
> also ob locker "50fps" oder mehr
> erreicht werden, müsste man evtl mal ausrechnen

Hab ich schon ausgerechnet ;-)
50 Hz sind auf jeden Fall drin.

Tim R. schrieb:
> du meinst einen master und für jede zeile oder spalte einen co-master?
> dieser soll dann seine ganz zeile "abchecken" und zurück zum master
> übersenden, sodass der master effektiv mit 5-10 seiner co-master
> kommuniziert und der arbeitsaufwand gering gehalten wird?

Ja genau, so meinte ich das. Der Co-Master müsste dann ein etwas 
größerer µC sein, so dass er mit master und seinen Slaves kommunizieren 
kann (braucht ein paar Pins mehr).

von Tim R. (herrvorragend)


Lesenswert?

also ich würde C/C++ bevorzugen :) :D

könntest du kurz aufzeigen, was du genau gerechnet hast? vorallem für 
wieviele teilnehmer

ja ich verstehe... kann mir jetzt grad nur schwer ausmalen wieviel mehr 
diese "co-master" uC dann bringen würden. oder ob man darauf verzichtet 
und einen großen nimmt der gleich alle reihen ansteuert




wie weit ist dein projekt denn eigtl schon voran geschritten??

: Bearbeitet durch User
von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> ja ich verstehe... kann mir jetzt grad nur schwer ausmalen wieviel mehr
> diese "co-master" uC dann bringen würden. oder ob man darauf verzichtet
> und einen großen nimmt der gleich alle reihen ansteuert

Dann bekommst du wohlmöglich ein Problem mit der Leitungslänge. Bei 
meinem Tisch (10x13 Pixel sind geplant) wäre diese wtwa 10m. Laut einem 
Online-Rechner, bricht die Spannung von 5V am Ende der leitung auf etwa 
die Hälfte zusammen. Und auch die Übertragung dürfte dann schwieriger 
werden (Laufzeiten, Kapizäten usw).
Durch die Gruppierung in Zeilen entspannt sich die Sache ungemein.

Tim R. schrieb:
> könntest du kurz aufzeigen, was du genau gerechnet hast? vorallem für
> wieviele teilnehmer

Für 130 Teilnehmer komme ich auf 20ms pro Übertragung. Also 50Hz.
Die komplette Rechnung habe ich leider grad nicht hier, kann ich aber 
nachreichen).

von Tim R. (herrvorragend)


Lesenswert?

boris warum eigtl kein raspberry pi?

von Conny G. (conny_g)


Lesenswert?

Braucht es für Touch überhaupt 50 Samples pro Sekunde, da reichen doch 
10?

von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> boris warum eigtl kein raspberry pi?

Den könnte man auch nehmen und zB per SPI einen 
Kommunikations-Coprozessor dranhängen, der sich um Realtime Aufgaben wie 
den Touch-Bus kümmert.
Ein RPi als Linuxsystem ist nicht gut in Realtime oder recht 
zeitkritischen Aufgaben.
Der BeagleBone hat den Vorteil, dass der einen uC schon Onboard hat.

von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> boris warum eigtl kein raspberry pi?

Für Steuerungsaufgaben ist der BBB deutlich besser geeignet:
 - Mehr Schnittstellen
 - Schneller Prozessor
 - Echtzeit-Co-Prozessoren schon an Board

Hier gibt's mehr zu dem Thema:
http://makezine.com/magazine/how-to-choose-the-right-platform-raspberry-pi-or-beaglebone-black/

Conny G. schrieb:
> Braucht es für Touch überhaupt 50 Samples pro Sekunde, da reichen
> doch 10?

Ich habe versucht das Protokoll möglichst einfach zu halten (Farben und 
Touch-Events immer abwechselnd)). Klar würde auch weniger reichen. Aber 
wenn alles im 50Hz Takt läuft, ist das doch super.

von Conny G. (conny_g)


Lesenswert?

Boris P. schrieb:

> Conny G. schrieb:
>> Braucht es für Touch überhaupt 50 Samples pro Sekunde, da reichen
>> doch 10?
>
> Ich habe versucht das Protokoll möglichst einfach zu halten (Farben und
> Touch-Events immer abwechselnd)). Klar würde auch weniger reichen. Aber
> wenn alles im 50Hz Takt läuft, ist das doch super.

Schraubt aber die Anforderungen unnötig nach oben.
Ich würde auch für die Farben keine 50fps nehmen, wenn ws2811 LEDs zum 
Einsatz kommen, denn im Unterschied zum Multiplexing leuchten diese LEDs 
ja in der zuletzt eingestellten Farbe weiter.
Also muss ich nicht mit hoher Frequenz Flimmern verhindern, sondern nur 
dafür sorgen, dass Animationen flüssig sind.
Also reichen auch hier 20-25fps locker aus.
Dann habe ich bei 25fps für RGB und Touch (bei einer analogen Auflösung 
von 1 Byte / 255 Werten pro Pixel) und 25fps für RGB dann 25 x 200 
(Tisch von 10x20) x ( 8 + 24 ) = 160 kBit/s.
Bei dieser Geschwindigkeit sollte man Busprobleme auch mit wenig Aufwand 
in den Griff bekommen.

Mit 255 Bit Auflösung kann man die Kalibrierung zentral im Master 
machen. Und sogar auf die Stärke des Touch reagieren, also die 
Entfernung der Annäherung.

Wenn man es nun noch schaffen würde das Protokoll der WS2811 in 
Leserichtung zu implementieren, dann hat man eine Kette von Attinys, die 
jeder wieder Bustreiber sind und kein Buslängenproblem.
Der Master redet mit dem ersten Touch-Attiny und der gleichzeitig mit 
dem nächsten usw. Auf diese Weise saugt man sich die Bytekette aus der 
Daisychain. Da man weiß wieviele Pixel man hat, braucht man kein 
Ende-Zeichen.
So könnte man sich den sternförmigen Aufbau und die Zeilencontroller 
sparen und hat von Grund auf keine langen Bus.

von Borislav B. (boris_b)


Lesenswert?

Wozu brauchst du denn die WS2811? Wenn du eh einen ATTiny pro Pixel 
verwendest kannst du dir den doch sparen, oder?

Conny G. schrieb:
> Dann habe ich bei 25fps für RGB und Touch (bei einer analogen Auflösung
> von 1 Byte / 255 Werten pro Pixel) und 25fps für RGB dann 25 x 200
> (Tisch von 10x20) x ( 8 + 24 ) = 160 kBit/s.
> Bei dieser Geschwindigkeit sollte man Busprobleme auch mit wenig Aufwand
> in den Griff bekommen.

was genau hast du da jetzt eingerechnet? Auch ein Start/Sync-Signal, die 
Adressierung und den Rückkanal?
Ich komme bei meiner Rechnung auf 220 kbit/s bei 50Hz Updaterate von 
Farben und Touch-Status (für 130 LEDs). Das scheint mir ein guter Wert 
zu sein.

Conny G. schrieb:
> dann hat man eine Kette von Attinys, die
> jeder wieder Bustreiber sind und kein Buslängenproblem.

Ich bin noch nicht so sicher, ob das funktioniert. Sinn und Zweck eines 
Busses ist es ja, dass alle Teilnehmer gleichzeitig lesen und schreiben 
können. Wenn du nun das Signal durch jeden Teilnehmer "durchrouten" 
musst, geht ja viel Zeit verloren. Ob das dann noch hinhaut?

Ein weiteres Problem ist zudem die Spannungsversorgung: Auf einer 10m 
leitung (1,5mm^2) kommen von den 5V am Anfang nur noch ca. die Hälfte am 
Ende an. Damit läuft natürlich kein Controller mehr. Deswegen wollte ich 
hier auf eine andere Topologie setzen.

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Boris P. schrieb:
> Wozu brauchst du denn die WS2811? Wenn du eh einen ATTiny pro Pixel
> verwendest kannst du dir den doch sparen, oder?

Könnte man auch. Mit den WS2811 müsste man sich um das RGB-PWM nicht 
mehr weiter kümmern.

> Conny G. schrieb:
>> Dann habe ich bei 25fps für RGB und Touch (bei einer analogen Auflösung
>> von 1 Byte / 255 Werten pro Pixel) und 25fps für RGB dann 25 x 200
>> (Tisch von 10x20) x ( 8 + 24 ) = 160 kBit/s.
>> Bei dieser Geschwindigkeit sollte man Busprobleme auch mit wenig Aufwand
>> in den Griff bekommen.
>
> was genau hast du da jetzt eingerechnet? Auch ein Start/Sync-Signal, die
> Adressierung und den Rückkanal?
> Ich komme bei meiner Rechnung auf 220 kbit/s bei 50Hz Updaterate von
> Farben und Touch-Status (für 130 LEDs). Das scheint mir ein guter Wert
> zu sein.

Ja, 220kBit geht auch noch. Allerdings würde ich nicht nur Touch-Status 
machen, sondern einen "analogen" Wert für Annäherung und Kalibrierung.

> Conny G. schrieb:
>> dann hat man eine Kette von Attinys, die
>> jeder wieder Bustreiber sind und kein Buslängenproblem.
>
> Ich bin noch nicht so sicher, ob das funktioniert. Sinn und Zweck eines
> Busses ist es ja, dass alle Teilnehmer gleichzeitig lesen und schreiben
> können. Wenn du nun das Signal durch jeden Teilnehmer "durchrouten"
> musst, geht ja viel Zeit verloren. Ob das dann noch hinhaut?

Das geht bei den WS2812 doch auch prima. Genau so müsste man es machen. 
Im Prinzip müssen die Attinys direkt jedes Bit weiterleiten ohne gross 
zwischenzuspeichern.
Es könnte auch Kommunikation à la I2C sein: ich schiebe einmal RGB-Bytes 
raus und erhalte direkt T 0 0 (Touch-Wert 8 Bit, Null, Null) zurück.
D.h. die Tinys würden den Bitstrom eimal direkt weiterleiten und im 
Rückkanal einen zurückschieben.
Und ein Pause wäre "Latch", den RGB-Wert übernehmen bzw. den 
Touch-Messwert für die nächste Runde speichern.

Man bräuchte also 2, evtl. 3 Leitungen von Tiny zu Tiny: Tx, Rx, Clk.

> Ein weiteres Problem ist zudem die Spannungsversorgung: Auf einer 10m
> leitung (1,5mm^2) kommen von den 5V am Anfang nur noch ca. die Hälfte am
> Ende an. Damit läuft natürlich kein Controller mehr. Deswegen wollte ich
> hier auf eine andere Topologie setzen.

Das ist das kleinste Problem einmal die Versorgung an den Spalten 
vorbeizuführen und an jeder Spalte einzuspeichen. Oder Zeile, ist völlig 
wurst.

von Borislav B. (boris_b)


Lesenswert?

Conny G. schrieb:
> Mit den WS2811 müsste man sich um das RGB-PWM nicht
> mehr weiter kümmern.

Auf den ersten Blick scheint der ca. 0,50€ zu kosten. Bei einem 
200-Pixel-Tisch wären das also schon mal 100€ nur für diesen Chip. Da 
würde ich doch lieber schnell eine Soft-PWM auf dem ATTiny 
implementieren. Ist ja kein Hexenwerk ;-)

von Conny G. (conny_g)


Lesenswert?

Boris P. schrieb:
> Conny G. schrieb:
>> Mit den WS2811 müsste man sich um das RGB-PWM nicht
>> mehr weiter kümmern.
>
> Auf den ersten Blick scheint der ca. 0,50€ zu kosten. Bei einem
> 200-Pixel-Tisch wären das also schon mal 100€ nur für diesen Chip. Da
> würde ich doch lieber schnell eine Soft-PWM auf dem ATTiny
> implementieren. Ist ja kein Hexenwerk ;-)

Und das I2C zwischen den Tinys macht auch nur Sinn, wenn der Tiny das 
PWM macht.

von Conny G. (conny_g)


Lesenswert?

Man sollte man so ein I2C-Daisy-Chain-Member mit Attiny, RGB LED als 
Prototyp bauen, bzw. 10 davon und testen. Ich glaube ist supercool so.
Oder wie man seit neuestem sagt: supersimpel, superclever ... supergeil!

von Borislav B. (boris_b)


Angehängte Dateien:

Lesenswert?

Also ich glaube man kann doch auf eine Unterteilung in Zeilen 
verzichten. Wenn man nicht alles als Kette, sondern sternförmig anordnet 
(siehe Bild), beträgt die maximale Leitungslänge ca. 70cm. Das sollte 
sowohl für die Stromversorgung als auch den Bus problemfrei sein.

Dann braucht man also nur noch einen Typ von Pixel, und die 
Buskommunikation ist auch deutlich einfacher.

Das könnte so aussehen:

Master sendet Start/Sync-Signal
-> Alle Slaves beginnen nun zu lauschen

Master sendet Addresse (8 Bit)
-> Nun weiß der entsprechende Slave dass er gemeint ist

Master sendet 24 Bit Farbinformationen
-> Slave übernimmt die Daten in seine RGB-LED-PWM

Master wartet 1 Bit lang
-> Slave setzt sein Touch-Status auf den Bus, Master liest diesen

=> Wiederhlung des Vorgehens mit nächster Adresse


Dann ist zwar keine Kalibrierung durch den Master möglich (wie oben 
vorgeschlagen), aber ich denke die ist auch verzichtbar, oder? Auch die 
Entfernung der Hand zum IR-Sensor brauche ich nicht wirklich. Daher 
sollte ein Bit als Rückkanal reichen.

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

So geht's auch, ja. Dann müsste man nicht das Chaining machen.

Wenn man es wie I2C implementiert und damit hin (RGB) und rück (Touch) 
gleichzeitig, dann bekommt man 24 Bit Rückkanal sowieso geschenkt, d.h. 
es kann dann problemlos 1 Byte Touch-Wert zurückbekommen, weil mit dem 
Taktsignal sowieso 24 Bits laufen und gar keine Extra Zeit für den 
Touch-Status gebraucht wird.

: Bearbeitet durch User
von Borislav B. (boris_b)


Lesenswert?

Conny G. schrieb:
> Wenn man es wie I2C implementiert und damit hin (RGB) und rück (Touch)
> gleichzeitig, dann bekommt man 24 Bit Rückkanal sowieso geschenkt, d.h.
> es kann dann problemlos 1 Byte Touch-Wert zurückbekommen, weil mit dem
> Taktsignal sowieso 24 Bits laufen und gar keine Extra Zeit für den
> Touch-Status gebraucht wird.

Ich kann dir nicht folgen. Du hast doch nur eine Leitung. Je mehr Daten 
du also zurücksenden möchtest, desto länger dauert das, desto kleiner 
ist die Update-Rate.
Wo bekommst du da was geschenkt?

von Conny G. (conny_g)


Lesenswert?

Boris P. schrieb:
> Conny G. schrieb:
>> Wenn man es wie I2C implementiert und damit hin (RGB) und rück (Touch)
>> gleichzeitig, dann bekommt man 24 Bit Rückkanal sowieso geschenkt, d.h.
>> es kann dann problemlos 1 Byte Touch-Wert zurückbekommen, weil mit dem
>> Taktsignal sowieso 24 Bits laufen und gar keine Extra Zeit für den
>> Touch-Status gebraucht wird.
>
> Ich kann dir nicht folgen. Du hast doch nur eine Leitung. Je mehr Daten
> du also zurücksenden möchtest, desto länger dauert das, desto kleiner
> ist die Update-Rate.
> Wo bekommst du da was geschenkt?

Sorry, ich hab's mit SPI verwechselt. Aber ich meinte SPI, da hast 
gleichzeitig TX und RX geschenkt. Mit 2 Leitungen plus Clock, das ist 
nicht so aufwändig in der Verkabelung.

Habe heute auch schonmal kurz drüber nachgedacht, ob man sich "Rails" 
aus Kupfer auf die Grundplatte machen könnte auf die man die Module dann 
aufschraubt und damit sich jede Verkabelung erspart.
Allerdings riecht mir das stark nach Busproblemen mit Kapazität, 
Induktivität und Störungen...
Lieber nimmt man gleich kurze Standardkabel wie SATA-Kabel oder so. 10cm 
für 1,70 Euro auf Ebay. Geht auch bestimmt noch billiger. Kurze 10cm 
Standard-Flachbandkabel mit 6 Polen.
Denn die Konfektionierung von 100 Kabeln (bei 10x10) ist einer der 
riesigen Arbeitszeitfresser.

von Borislav B. (boris_b)


Lesenswert?

Conny G. schrieb:
> Sorry, ich hab's mit SPI verwechselt. Aber ich meinte SPI, da hast
> gleichzeitig TX und RX geschenkt. Mit 2 Leitungen plus Clock, das ist
> nicht so aufwändig in der Verkabelung.

Klar, man könnte statt einer Datenleitung gleich zwei nehmen, dann hat 
man RX und TX gleichzeitig. Aber da es eigentlich kein Zeitproblem geben 
sollte, kann man sich die zusätzliche Leitung doch sparen, und alles auf 
einer machen.

Ist weniger Verkabelungsaufwand, billiger und hat keinerlei Nachteile.

von Conny G. (conny_g)


Lesenswert?

Dann könnte das mit den Rails evtl. doch gehen... man macht 1cm breite 
Kupferstreifen nebeneinander, die sind schon mal die Stromversorgung der 
einzelnen Pixel.
Dann braucht man die Pixel eigentlich nur mit einem dicken Lötauge 
draufschrauben und sie haben Strom, v.a. mit einer sehr dicken 
Zuleitung, also wenig Verlust.

Oder statt draufschrauben am Rand anlöten, wie die SMD-Funkmodule :-)
Aber das wäre unpraktisch, weil schlecht wartbar, da ist Schrauben 
besser.

Und das I2C entweder über ein 3. Rail, wobei das enorm Störanfällig ist.
oder mit Lötnägeln o.ä. nach unten durch das Basisbrett durch und dort 
mit 7cm geschirmtem Kabel von Nagel zu Nagel hüpfen.

Oder das Datenrail zwischen 2 Schirmschichten nehmen, also Kupfer (GND) 
+ Folie + Kupfer (DATA) + Folie + Kupfer (GND) und das immer für 1cm 
unterbrechen.
Dann könnte man hier sogar GND + Data abnehmen.

Das würde jede Verkabelung komplett ersparen.

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Oder gleich 25x25 (oder welches Maß auch immer ein Vielfaches der Pixel 
ist) Platinen als Basis nehmen.

von Tim R. (herrvorragend)


Lesenswert?

uiuiui das ist ja fortgeschritten hier heute :-)

mich würde interessieren, wie wird denn der realtime prozessor auf dem 
beagle angesprochen?!

mit dem "protokoll" zur eindrahtleitung für rgb und touch stimm ich 
überein, ich glaube das ist die einfachste und zugleich 
verdrahtungsärmste methode

ich hatte die ganze zeit eh im kopf, den master direkt vor die "reihen" 
zu setzen und somit 10 (oder mehr) reihen anzusprechen, die jeweils 1-2m 
leitungslänge haben. ich verstehe nicht ganz wie du auf 10m 
leitungslänge kommst -> zwecks spannungsabfall ?
aber in der mitte als physische sterntopologie sollte das ganze auch 
machbar sein :)

boris bei deinem protokollablauf, sollte der master nicht erst das touch 
abfragen und anschließend einen rgb wert senden? also rein aus der logik 
kann der master ja keinen rgb wert setzen, wenn der touch nicht vorher 
abgefragt wurde... es sei denn man verwendet den vorigen zyklus

die entfernung der hand wäre ein sehr nettes gimmik. daran hatte ich 
nocht gar nicht gedacht. aber das zieht einige erweiterungen mit sich 
oder?

an kupferplatten für die versorgung hatte ich auch schon gedacht, ich 
hab mit diesen nur noch nie gearbeitet und weiß nicht ob das so 
funktionieren würde, aber sehe dort eigtl keine probleme. weiß nur nicht 
ob ich mir so eine "offene leitung" in meinen tisch bauen will ;-)

für die datenleitung würde ich fertig gecrimpte kabel kaufen oder sata 
kabel wie Conny es geschrieben hatte. ich habe definitiv keine lust 
gefühlt 1000000 kabel erst ordentlich zu verarbeiten bevor ich sie 
richtig verwenden kann

... und ja das ist mir bekannt: supersimpel, superclever ... supergeil! 
;-P

von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> ich verstehe nicht ganz wie du auf 10m
> leitungslänge kommst -> zwecks spannungsabfall ?

Die kommen zustande, wenn du eine Kette über alle Pixel bildest (das war 
mal meine aller erste Idee). Bei einer Sternstruktur, ist das Problem 
natürlich weg.

Tim R. schrieb:
> boris bei deinem protokollablauf, sollte der master nicht erst das touch
> abfragen und anschließend einen rgb wert senden? also rein aus der logik
> kann der master ja keinen rgb wert setzen, wenn der touch nicht vorher
> abgefragt wurde... es sei denn man verwendet den vorigen zyklus

Meinst du Inputs lesen -> neue Ausgabe berechnen -> Outputs setzen?
Das wird so nicht klappen, da du in der kurzen Zeit das nächste Bild 
nicht berechnet bekommst. Die Übertragung auf dem Bus geht ja so 
schnell, dass da nur sehr wenig Zeit zwischen liegt. Man muss sowieso 
Anwendung (Spiel, Animation etc.) komplett vom Displaytreiber 
entkoppeln, da diese ja asynchron auf verschiedenen Prozessoren laufen.

D.h. die Anwendung berechnet so schnell die Bilder wie sie kann und 
kopiert die Daten in einen Puffer (Hauptprozessor). Der Display-Treiber 
(Realtime-Prozessor) greift sich unabhängig davon in einer festen 
Frequenz die Daten aus dem Buffer und schiebt sie an die Pixel.

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> die entfernung der hand wäre ein sehr nettes gimmik. daran hatte ich
> nocht gar nicht gedacht. aber das zieht einige erweiterungen mit sich
> oder?

Eigentlich nicht so dramatisch. Die einzelnen Pixel übermitteln nur 
einen Wert in einem Range statt 0 oder 1 für den Touch. Und der Master 
kann entweder für alle die gleich Schwelle nehmen oder nach irgendeiner 
Logik die Schwellwerte differenziert setzen.
Und bei der Auswertung des Touch kann man Annäherung einfliessen lassen, 
wenn man möchte oder auch nur per Schwelle an/aus interpretieren.
Ich fände das cool, wenn man man einen "analogen" Wert hätte - gerade 
weil es nur mässig mehr Aufwand macht (entweder höhere Datenrate bei 
I2C-ähnlichem Protokoll oder 3 Leitungen für SPI). Nur Touch j/n ist 
eine recht harte Designentscheidung, die diese Möglichkeiten eliminiert.

> an kupferplatten für die versorgung hatte ich auch schon gedacht, ich
> hab mit diesen nur noch nie gearbeitet und weiß nicht ob das so
> funktionieren würde, aber sehe dort eigtl keine probleme. weiß nur nicht
> ob ich mir so eine "offene leitung" in meinen tisch bauen will ;-)

Es wären eher Kupferfolie oder Kupferstreifen oder so. Idealerweise noch 
verzinnen im chem. Verzinnungsbad, dann oxidieren sie nicht.
Der Tisch ist ja zu. Und es sind maximal 12V würde ich annehmen, eher 
nur 5V, das ist völlig unproblematisch. Und man könnte auch noch mit 
einer ordentlichen Schicht Klarlack o.ä. eine Isolierung schaffen.

> für die datenleitung würde ich fertig gecrimpte kabel kaufen oder sata
> kabel wie Conny es geschrieben hatte. ich habe definitiv keine lust
> gefühlt 1000000 kabel erst ordentlich zu verarbeiten bevor ich sie
> richtig verwenden kann
>
> ... und ja das ist mir bekannt: supersimpel, superclever ... supergeil!
> ;-P

von Tim R. (herrvorragend)


Lesenswert?

Boris P. schrieb:
> Tim R. schrieb:
>> ich verstehe nicht ganz wie du auf 10m
>> leitungslänge kommst -> zwecks spannungsabfall ?
>
> Die kommen zustande, wenn du eine Kette über alle Pixel bildest (das war
> mal meine aller erste Idee). Bei einer Sternstruktur, ist das Problem
> natürlich weg.

ach du wolltest eine lange kette mit allen pixeln bilden?? ich hatte die 
ganze zeit für jede reihe die länge versorgung und datenleitung geplant, 
das wäre eben nur die tischlänge

>
> Tim R. schrieb:
>> boris bei deinem protokollablauf, sollte der master nicht erst das touch
>> abfragen und anschließend einen rgb wert senden? also rein aus der logik
>> kann der master ja keinen rgb wert setzen, wenn der touch nicht vorher
>> abgefragt wurde... es sei denn man verwendet den vorigen zyklus
>
> Meinst du Inputs lesen -> neue Ausgabe berechnen -> Outputs setzen?
> Das wird so nicht klappen, da du in der kurzen Zeit das nächste Bild
> nicht berechnet bekommst. Die Übertragung auf dem Bus geht ja so
> schnell, dass da nur sehr wenig Zeit zwischen liegt. Man muss sowieso
> Anwendung (Spiel, Animation etc.) komplett vom Displaytreiber
> entkoppeln, da diese ja asynchron auf verschiedenen Prozessoren laufen.

also der user aus dem link den ich zuvor gepostet habe, hatte glaube nur 
einen atmega verwendet. das sollte doch eigtl relativ gut gehen oder 
nicht? pixel abfragen, pixel setzen... und das bei 100 pixeln am besten 
rund 25mal die sekunde

>
> D.h. die Anwendung berechnet so schnell die Bilder wie sie kann und
> kopiert die Daten in einen Puffer (Hauptprozessor). Der Display-Treiber
> (Realtime-Prozessor) greift sich unabhängig davon in einer festen
> Frequenz die Daten aus dem Buffer und schiebt sie an die Pixel.

die idee der kopplung ist aber auch gut. nur mit einem mehraufwand 
verbunden, aber nun versteh ich deine entscheidung für das beagleboard 
:)



ps: kupferstreifen war auch das wort was ich gesucht habe, ich kam nicht 
drauf *g

: Bearbeitet durch User
von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> also der user aus dem link den ich zuvor gepostet habe, hatte glaube nur
> einen atmega verwendet. das sollte doch eigtl relativ gut gehen oder
> nicht? pixel abfragen, pixel setzen... und das bei 100 pixeln am besten
> rund 25mal die sekunde

Nenene, mit nem ATMega macht das glaubich keinen Spaß ;-)
Du willst ja auch WLAN und oder Bluetooth Anbindung haben, vielleicht 
einen Webserver. Und die Programmierung sollte in verschiedenen 
Hochsprachen möglich sein, so dass man vielleicht sogar Programme mit 
anderen "Nachbauern" austauschen kann. Das alles bekommst du beim BBB 
geschenkt.

von Tim R. (herrvorragend)


Lesenswert?

Boris P. schrieb:
> Tim R. schrieb:
>> also der user aus dem link den ich zuvor gepostet habe, hatte glaube nur
>> einen atmega verwendet. das sollte doch eigtl relativ gut gehen oder
>> nicht? pixel abfragen, pixel setzen... und das bei 100 pixeln am besten
>> rund 25mal die sekunde
>
> Nenene, mit nem ATMega macht das glaubich keinen Spaß ;-)
> Du willst ja auch WLAN und oder Bluetooth Anbindung haben, vielleicht
> einen Webserver. Und die Programmierung sollte in verschiedenen
> Hochsprachen möglich sein, so dass man vielleicht sogar Programme mit
> anderen "Nachbauern" austauschen kann. Das alles bekommst du beim BBB
> geschenkt.

das würde aber nach sich ziehen das wir den selben aufbau realisieren 
bzw. das du alle schaltpläne codes etc frei gibst ?! :)
erst dann können auch andere dazu ihren teil beisteuern ;)

von Borislav B. (boris_b)


Lesenswert?

Tim R. schrieb:
> das würde aber nach sich ziehen das wir den selben aufbau realisieren
> bzw. das du alle schaltpläne codes etc frei gibst ?! :)
> erst dann können auch andere dazu ihren teil beisteuern ;)

Dass der Code und die Schaltpläne frei zugänglich sind, ist für mich 
selbstverständlich. Ich würde das ganze dann eh auf einer Open-Source 
Plattform hosten. So kann sich an der Entwicklung beteiligen wer mag.

Den "Grafiktreiber" würde ich dann so implementieren, dass die Anzahl 
der Pixel, die gewünschte Datenrate usw. einstellbar sind. So kann diese 
für jedes Tisch-Format benutzt werden. Das ganze wird eine C/ASM 
Library, die dann von jeder Sprache einbindbar ist.

Dann kann jeder (ob nun Java-Scripter oder Hardcore-Assemblierer) für so 
einen Tisch eine Anwendung schreiben. Die könnte man dann auch schön auf 
dieser Plattform hosten (mit SCreenshots/Video, Beschreibung und 
Download), und sich so austauschen.

Keine Ahnung wie viele Nachbauer sich dann für sowas finden. Aber 
Versuch macht kluch ;-)

von Tim R. (herrvorragend)


Lesenswert?

Na das hättest du mal anfangs erwähnen sollen, dass du es gerne so 
machen magst ;-)

Ich weiß nicht ob sich nachbauer finden, aber sobald Entwickler eigene 
Software dafür schreiben haben wir ebenso was davon hehe

Die geschwindigkeit ist ein gutes Thema, denn je mehr Teilnehmer desto 
schneller muss der Echtzeitptozessor die Daten scheffel

Also zu aller erst sollten die kleine Struktur und das Protokoll in eine 
Datei ausgelagert werden. Und dann kann es eigtl losgehen mit dem 
schaltplan für die pixelplatine etc oder wie sieht's aus? :) sollten uns 
dann eben nur auf die Komponenten einigen

von Conny G. (conny_g)


Lesenswert?

Bin grundsätzlich auch am Bau so ein coolen Tisches interessiert. Wird 
allerdings eine Weile dauern, bis ich wirklich dazukomme, habe noch 
Projekte vorher abzuschließen.
Fände es gut, wenn wir cleveres Konzept für die Pixel finden, wie wir 
uns die ganze Wahnsinnsverkabelung ersparen / erleichtern könnten.
Also Bus oder Daisy Chain.

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> Bin grundsätzlich auch am Bau so ein coolen Tisches interessiert. Wird
> allerdings eine Weile dauern, bis ich wirklich dazukomme, habe noch
> Projekte vorher abzuschließen.
> Fände es gut, wenn wir cleveres Konzept für die Pixel finden, wie wir
> uns die ganze Wahnsinnsverkabelung ersparen / erleichtern könnten.
> Also Bus oder Daisy Chain.

ich habe das problem der zeit und des platzes, ich weiß noch gar nicht 
wohin mit dem ding gg

also die variante des eigenen einfachen protokolls, welches auf einer 
kaskadierung basiert, gefällt mir am besten. lasse mir gerne aber 
alternativen zeigen. somit brauch jede pixel-platine 2 leitung 
versorgung und eine bidirektionale datenleitung. macht 3 leitungen pro 
pixel :) wovon die zwei zur versorgung evtl durch die kupferstreifen 
oder ähnliches gelöst werden könnten... ich würde für die versorgung auf 
der pixelplatine zum einen steckverbindung und zum anderen evtl eine 
borung zum schrauben oder so vorschlagen

von Tim R. (herrvorragend)


Lesenswert?

http://www.schramm-software.de/bausatz/distanzsensor/

gerade durch zufall gefunden... ist ja süß :D

von Tim R. (herrvorragend)


Lesenswert?

hey kollegen eingeschlafen ?

push the thread :p

von Borislav B. (boris_b)


Lesenswert?

Hi Tim,
im Moment sieht es ja eher düster aus:
Conny ist momentan anderweitig beschäftigt:

Conny G. schrieb:
> Wird allerdings eine Weile dauern, bis ich wirklich dazukomme, habe noch
> Projekte vorher abzuschließen.

Bei Dir sieht es auch nicht besser aus:

Tim R. schrieb:
> ich habe das problem der zeit und des platzes, ich weiß noch gar nicht
> wohin mit dem ding gg

Und auch bei mir sind zurzeit noch zwei andere Projekte in Arbeit.

Zudem scheinen sich hier nicht besonders viele Interessenten zu finden. 
Außer uns Dreien meldet sich hier ja keiner. Zudem mangelt es uns (so 
wie ich das einschätze) hier und da an Expertise - z.B. ist die 
Realtime-Unit des BBB nicht so einfach zu programmieren. Daher betrachte 
ich das Projekt vorerst als "auf Eis gelegt"...

von Conny G. (conny_g)


Lesenswert?

Was ich bei derlei "Randprioritäten" gerne praktiziere ist eine Taktik 
der kleinen Schritte: definieren wo ich hin will (cooler 
RGB-Touch-Tisch) und das dann in Unterprojekte zerlegen, die für einen 
Abend taugen. Dann kann man immer dann, wenn man gerade Zeit und auf nix 
anderes Lust hat so einen Teil rausziehen und durchführen und hat nach 
ein paar Wochen dann doch schon einiges erledigt.
Und man kann schon immer mal Bauteile mitbestellen und ansammeln.
Und wir hier können uns solche Aufgaben aufteilen.

Die aufwändugste Basis des Tisches sind ja die RGB-Touch-Pixel.
Also sollte man ein erstes realistisch erscheinendes Konzept dafür 
festlegen, Bauteile bestellen, aufbauen und testen.

Der zweite Teil ist der Bus.
Dazu könnte man erstmal die One Wire Idee komplett ausformulieren.
Dann implementieren und auf zwei beliebigen uCs testen, danach mal mit 
2.
Und wenn einstweilen die Touchpixel getestet sind, macht man mal 10-20 
davon und testet nochmal. Evtl mit extra großen Abständen der Leitungen. 
Vielleicht auch mal mit 3 Kupferstreifen auf der Bodenplatte - 
vielleicht geht's ja und man spart sich die Verkabelung komplett.

Und nach diesen beiden Elementen - die eigentlich die schwierigsten sind 
- geht's um Gehäuse und die Steuerung, auch zwei getrennte Projekte.
Ebenso zerlegen, aufteilen und Schritt für Schritt abfackeln.

Also als erstes: Pixel definieren
- welche LEDs und wieviele (braucht das schon mal einen Prototyp?
- welcher Mikrocontroller?
- Bauelemente Touch?
Ziele:
- RGB: Hell genug auch bei moderatem Tageslicht
- Touchmessung moduliert für mehr Robustheit
- So wenige Bauelemente wie möglich für effizienten Aufbau
- Kostengrenze pro Pixel 3 Euro?
- ...
Fragen:
- Zusätzlich weiße LED für echtes weiß und Pastell?
- Anforderungen an den uC
  - günstig, weil 100 Stück
  - Idealerweise schon 5 PWMs für RGBW und Touch
- ...

Das müssen wir noch weiter aufrollen.

von Markus M. (adrock)


Angehängte Dateien:

Lesenswert?

Hi,

ich hatte mir ja mal den IR Näherungssensor APDS-9120 von Avago 
angeschaut (siehe auch oben).

Das Dingens ist für einen Tisch nicht brauchbar, es ist ultraklein (ca. 
4x4 mm) und ziemlich fies zu löten.

Es funktioniert grundsätzlich zwar, aber der Erfassungswinkel und 
-Abstand (im besten Fall 4cm, aber nur bei weißem Material) passen 
nicht. Auch die eingebaute IR-LED ist dafür einfach zu winzig.

Man wird also um eine Lösung mit einer externen möglichst "dicken" 
IR-Led mit breitem Abstrahlwinkel nicht umhinkommen.

Der Si1102 sieht auch noch ganz interessant aus, mit seinem 
Erfassungsbereich von max. 50cm. Allerdings mit 3x3 mm und 8 Pins auch 
ein Winzling.

Oder eben doch mit einem Controller pro Pixel aufbauen, so hätte man 
auch bei der Wahl der RGB-LEDs mehr Freiheit.

Grüße
Markus

von Tim R. (herrvorragend)


Lesenswert?

ah super, auf deine antworte habe ich gewartet! danke dir für das testen

das ist schon mal ein guter ansatz. das bauteil ist wirklich winzig. ich 
habe mir aber überlegt, wenn es wirklich mehrere pixelplatinen werden 
sollen, diese bestücken zu lassen sonst werd ich irre bei soviel löterei 
:D aber das ziel, für jeden pixel eine platine zu fertigen ist glaube 
ich schon ziemlich festgesteckt, sonst wird es unnötig aufwendig

ich werde mir gleich mal den Si1102 anschauen...

zur zeit warte ich gerade auf meine bestellung vom is471 und einer 
kleinen plexiglas platte (lichtdurchlässig)... danach werde ich mal 
einen kleinen aufbau aufm steckbrett probieren. hab noch ein kleines 
demo board von microchip rumliegen vllt werde ich auch gleich eine 
kleine auswertung auf dem uC vornehmen

von Markus M. (adrock)


Lesenswert?

Das hier ist ja im Prinzip ein wenig Grundlagenforschung, zumindest 
bzgl. des Tisches.

Wie sieht denn der geplante Aufbau des Tisches aus? Wenn man schon 
soviel Geld reinsteckt, wird man doch sicher keine Plexiglasplatte am 
Ende nehmen? Glas sollte doch schöner aussehen, oder?

Wie groß sollen denn die einzelnen "Pixel" werden? 5x5 cm? Daraus ergibt 
sich dann ja auch, wie weit die LEDs (IR + RGB) und somit auch der 
Sensor von der Scheibe entfernt sein muss, um eine gleichmäßige 
Ausleuchtung zu bekommen. Ist evtl. auch experimentell zu ermitteln.

Der Erbauer des anderen Touch-Tisches hat Milch(plexi?)glas mit 40% 
Lichtdurchlässigkeit genommen.

Grüße
Markus

von Conny G. (conny_g)


Lesenswert?

Bzgl. der Entfernung von der Glas-/Plexischeibe:

die Ausleuchtung ist gar nicht mal so die Frage. Vielmehr ist 
interessant, dass der Winkel der Touch-Erkennung möglichst schmal ist.
D.h. die IR-Diode und der IR-Receiver sollten so weit unten sitzen, dass 
der Öffnungswinkel der Messung nach oben nur noch 10-20 Grad ist.

Beim Beleuchten wäre es egal, wenn die LED 120 Grad Abstrahlwinkel hätte 
und nur so weit von der Platte entfernt ist, dass man keine Punktförmige 
Lichtquelle mehr sieht - das sind nur 5-7cm.

Diese 5-7cm reichen aber bei einer "Pixelgröße" von 60/10 = 6cm für 
10-20 Grad IR-Erkennung noch nicht aus, es ergäbe eher einen Winkel von 
45 Grad.
Müsste also doppelt so weit runter, also 10+ cm.

von Tim R. (herrvorragend)


Lesenswert?

Markus M. schrieb:
> Das hier ist ja im Prinzip ein wenig Grundlagenforschung, zumindest
> bzgl. des Tisches.
>
> Wie sieht denn der geplante Aufbau des Tisches aus? Wenn man schon
> soviel Geld reinsteckt, wird man doch sicher keine Plexiglasplatte am
> Ende nehmen? Glas sollte doch schöner aussehen, oder?
>
> Wie groß sollen denn die einzelnen "Pixel" werden? 5x5 cm? Daraus ergibt
> sich dann ja auch, wie weit die LEDs (IR + RGB) und somit auch der
> Sensor von der Scheibe entfernt sein muss, um eine gleichmäßige
> Ausleuchtung zu bekommen. Ist evtl. auch experimentell zu ermitteln.
>
> Der Erbauer des anderen Touch-Tisches hat Milch(plexi?)glas mit 40%
> Lichtdurchlässigkeit genommen.
>
> Grüße
> Markus

ich habe jetzt einen kleinen testaufbau auf einem steckbrett mit dem 
is471 realisiert (inkl. Plexiglasscheibe).

die schaltung habe ich von 
http://www.kreatives-chaos.com/artikel/abstandssensor-mit-is471 fast 
identisch übernommen (danke an den autor). als ausgabe diente erstmal 
eine einfache kleine LED. plexiglas habe ich eine 10x10cm große plexi- 
milchglas mit 79% lichtdurchlässigkeit bei ebay genutzt (versand war 
teurer als das glas selbst :-D)

ich habe etwa 2cm abstand zwischen led und plexiglas. die erkennung lief 
soweit schon mal ganz gut. man muss aufpassen das die LED nicht den 
sensor beeinflusst. ich werde meinen prototypen nur noch etwas umbauen, 
um die led und den sensor richtig ausrichten zu können und anschließend 
gleich an einen uC zu gehen für eine eventuelle filterung. zudem muss 
ich mal eine RGB unter das glas klemmen um zu sehen wie die led als 
lichtquelle wirkt. denn ich persönlich mag keine punktausleuchtung 
sondern das gestreute licht quasi.

somit habe ich die grundlagenforschung nun am schopf gepackt.

rein aus kostengründen würde mich interessieren, wie andere sensoren 
arbeiten wie zum beispiel der TSOP oder andere sensoren die hier genannt 
wurden... wenn man 100xIS471 nimmt, kommt schon ein sümmchen zusammen... 
eine kostengünstigere alternative wäre praktisch

: Bearbeitet durch User
von Joe (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

bin mit dabei..... ;-)

Hatte dieses Video gefunden.......
https://www.youtube.com/watch?v=6WkqYltIJJU

Aber eben teuer und nur einfarbig.

Aber der erste Gedanke von mir war ganz einfach erst mal ein 
Fototransistor plus Leistungstransistor wie im Anhang.

So spät genug, muss jetzt erst mal in die Heia. ;-)

von Conny G. (conny_g)


Lesenswert?

Mir schwirrt folgendes Modell im Kopf herum:

Ein Attiny oder ähnlicher kleinstmöglicher Prozessor
lässt einen Timer mit 100 kHz laufen
pulst mit diesem Timer ein IR-LED mit 50 Khz
es wird je On-Periode der IR-LED und je Off-Periode einmal die Spannung 
an einer IR-Diode gemessen
Zwischen diesen beiden Werten wird jede Messperiode (oder auch über 100 
Messperioden zur Störungsfilterung) die Differenz gebildet
dadurch ist eine Kalibrierung auf die Umgebungshelligkeit gegeben: 
Off-Wert ist die Grundhelligkeit, On-Helligkeit ist die Abstandsmessung, 
die Differenz aus beiden ist der Sensorwert, der proportional zum 
Abstand eines Sensors ist
Je höher die Grundhelligkeit, desto geringer die Auflösung der Erkennung 
(die Differenz der beiden Wert wird geringer)

Idealerweise würde man den Messbereich noch mit einem Opamp auf die 
Referenzspannung der AD-Wandlung skalieren, das maximiert die 
Grundauflösung der Messung.

Nun kann der Attiny auch den 1-Wire-Bus bedienen und entweder ein 
digitales Signal geben - für diejenigen, die das bevorzugen - oder ein 
analoges für die Entfernung eines Gegenstands.

von Tim R. (herrvorragend)


Lesenswert?

Joe schrieb:
> Hallo zusammen,
>
> bin mit dabei..... ;-)
>
> Hatte dieses Video gefunden.......
> https://www.youtube.com/watch?v=6WkqYltIJJU
>
> Aber eben teuer und nur einfarbig.
>
> Aber der erste Gedanke von mir war ganz einfach erst mal ein
> Fototransistor plus Leistungstransistor wie im Anhang.
>
> So spät genug, muss jetzt erst mal in die Heia. ;-)

wenn ich das richtig sehe is das nen fototransi oder ? heißt der 
reagiert nur auf licht bzw. schatten. das wäre in so einem tisch meiner 
meinung nach ganz schön ungeeignet alleine wegen umgebungslicht und 
eigenen licht im pixelkästchen... oder irre ich mich?!


@Conny du willst also die LED auch gleichzeitig als sensor nutzen? ist 
dieses modell denn schon mal getestet worden oder ist das eine reine 
idee?
zumindest von den bauteilen wäre das glaub günstiger weil der is471 zum 
beispiel wegfällt... würde eben nur anfangs eine größere testreihe mit 
sich bringen...

von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> @Conny du willst also die LED auch gleichzeitig als sensor nutzen? ist
> dieses modell denn schon mal getestet worden oder ist das eine reine
> idee?
> zumindest von den bauteilen wäre das glaub günstiger weil der is471 zum
> beispiel wegfällt... würde eben nur anfangs eine größere testreihe mit
> sich bringen...

Nein, ganz normal IR-LED zum senden des Messsignals und IR-Diode als 
Sensor. Das Ganze gepulst für Toleranz gg. Fremdlicht.

IR-Diode meint hier nicht IR-LED sondern IR-Foto-Diode, das sind zwei 
verschiedene Dinge.
Aber ich würde IR-Fotodiode statt Fototransistor vorschlagen, da 
IR-Fotodioden soviel ich gelesen habe schneller reagieren.

: Bearbeitet durch User
von Markus M. (adrock)


Lesenswert?

...das Problem mit den Photodioden ist aber, dass sie nur sehr kleine 
Ströme liefern. Somit kommt man um einen OP nicht herum.

Damit hat man schon wieder mehr Bauteile auf der Platine. OP und 
Hühnerfutter...

von Conny G. (conny_g)


Lesenswert?

Markus M. schrieb:
> ...das Problem mit den Photodioden ist aber, dass sie nur sehr kleine
> Ströme liefern. Somit kommt man um einen OP nicht herum.
>
> Damit hat man schon wieder mehr Bauteile auf der Platine. OP und
> Hühnerfutter...

Ui, ja, ok. Muss zugeben, dass ich noch nicht mit Photodioden gearbeitet 
habe.

Ich habe dazu gerade folgendes gefunden:

Beitrag "Re: Photodiode messen"

"An die Fotodiode wird eine Spannung in Sperrichtung angeschlossen,
die zu einer Verstärkung des Fotostromes führen kann (auf die
Beschaltung beziehen sich offensichtlich die Angaben im Datenblatt, V_R
wird in Sperrichtung angelegt und über einen Widerstand im Kreis kann
wieder eine stromproportionale Spannung abgegriffen werden). Nachteil:
U.a. geringere Linearität (sollte in diesem Fall lt. Datenblatt aber
unproblematisch sein)."

Habe gerade mal in Datenblättern nachgelesen, was der 
Schaltzeitunterschied zwischen Fototransistor und Fotodiode eigentlich 
ist.
Transistor: 5µs
http://www.vishay.com/docs/81504/bpv11.pdf
Diode: 2,5ns
http://www.vishay.com/docs/81502/bpv10.pdf

Ist also schon Faktor 1.000, bei 100 kHz Messfrequenz haben wir nur 10µs 
für die Messung.
Mit der Frequenz kann man schon noch ein bisschen runtergehen, so bis 
40-50 kHz, aber dann sinds auch nur 20µs und damit noch im 
Schaltzeitbereich des Transistors.

Ich würde also sagen: um es so zu machen wie ich skizziert habe muss es 
eine Fotodiode sein.

: Bearbeitet durch User
von Armin K. (-donald-) Benutzerseite


Lesenswert?

Hallo,
wozu IR, Sensor, Lichtschranke und weiteres?
Ihr habt doch den besten Sensor schon vorhanden! Die LED selbst.
Siehe http://cs.nyu.edu/~jhan/ledtouch/index.html

von Conny G. (conny_g)


Lesenswert?

Armin K. schrieb:
> Hallo,
> wozu IR, Sensor, Lichtschranke und weiteres?
> Ihr habt doch den besten Sensor schon vorhanden! Die LED selbst.
> Siehe http://cs.nyu.edu/~jhan/ledtouch/index.html

Wäre durchaus eine Idee.

Da würden mich zwei Fragen beschäftigen:
- ist die Empfindlichkeit genug um durch mattiertes (Plexi)Glas zu 
kommen?
- würde Infrarot nicht deutlich bessere Abgrenzung von Fremdlicht 
bieten?

Ich denke, dass die Empfindlichkeit generell und Störunempfindlichkeit 
speziell bei normalen LEDs eher kritisch stehen.
Kann aber die Dimension der Fotodiodenwirkung einer normalen LED 
überhaupt nicht einschätzen, also wie stark der Kompromiss ggü Fotodiode 
ausfällt.

Weiss das jemand, wie es um die Licht-Empfindlichkeit einer normalen 
Diode steht?

von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> Armin K. schrieb:
>> Hallo,
>> wozu IR, Sensor, Lichtschranke und weiteres?
>> Ihr habt doch den besten Sensor schon vorhanden! Die LED selbst.
>> Siehe http://cs.nyu.edu/~jhan/ledtouch/index.html
>
> Wäre durchaus eine Idee.
>
> Da würden mich zwei Fragen beschäftigen:
> - ist die Empfindlichkeit genug um durch mattiertes (Plexi)Glas zu
> kommen?
> - würde Infrarot nicht deutlich bessere Abgrenzung von Fremdlicht
> bieten?
>
> Ich denke, dass die Empfindlichkeit generell und Störunempfindlichkeit
> speziell bei normalen LEDs eher kritisch stehen.
> Kann aber die Dimension der Fotodiodenwirkung einer normalen LED
> überhaupt nicht einschätzen, also wie stark der Kompromiss ggü Fotodiode
> ausfällt.
>
> Weiss das jemand, wie es um die Licht-Empfindlichkeit einer normalen
> Diode steht?

das selbe dachte ich mir bei der seite auch. ich sehe nur einen dunklen 
raum mit LEDs. aber was ist, wenn das umgebungslicht eben tageslist oder 
was auch immer entspricht, dann sieht die empfindlichkeit zur messung 
mit der led selbst schon ganz anders aus und ich glaube um einiges 
schlechter als IR

den ansatz mit IR-fotodiode/transistor werde ich mal nachschauen. ich 
kenne nur fototransi-/dioden aber nicht mit IR. guter ansatz, so lässt 
sich tortzdem evtl. viel einsparen :)

von Markus M. (adrock)


Lesenswert?

Hi,

habe jetzt mal den Si1102 getestet...

Erstmal ist das Ding so winzig, dass es mich an meine Grenzen gebracht 
hat, was das Anlöten des Lackdrahtes an die 7 winzigen Pads (0,3mm x 
0,3mm) angeht.

Habe es dann zusammen mit einer SFH4056 IR-Diode ausprobiert. Es wäre 
wohl besser, eine Diode mit einem "narrow beam" zu nehmen, in der 
application note haben sie eine SFH4650 verwendet.

Das Ding ist so empfindlich, dass ich erst an einen Fehler in der 
Schaltung gedacht habe, weil es kontinuierlich etwas detektiert hat :-) 
Musste dann die Empfindlichkeit herabsetzen und IR-Diode und den 
Empfänger wirklich optisch etwas isolieren. Danach hat es immer noch 
meine Hand in ca. 10cm locker erkannt.

Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich 
befürchte ja, dass das Milchglas an sich schon reflektiert und somit 
schon zu einer (Falsch-)Erkennung führt.

Grüße
Markus

von Conny G. (conny_g)


Angehängte Dateien:

Lesenswert?

Markus M. schrieb:
> Hi,
>
> habe jetzt mal den Si1102 getestet...
>
> Erstmal ist das Ding so winzig, dass es mich an meine Grenzen gebracht
> hat, was das Anlöten des Lackdrahtes an die 7 winzigen Pads (0,3mm x
> 0,3mm) angeht.
>
> Habe es dann zusammen mit einer SFH4056 IR-Diode ausprobiert. Es wäre
> wohl besser, eine Diode mit einem "narrow beam" zu nehmen, in der
> application note haben sie eine SFH4650 verwendet.
>
> Das Ding ist so empfindlich, dass ich erst an einen Fehler in der
> Schaltung gedacht habe, weil es kontinuierlich etwas detektiert hat :-)
> Musste dann die Empfindlichkeit herabsetzen und IR-Diode und den
> Empfänger wirklich optisch etwas isolieren. Danach hat es immer noch
> meine Hand in ca. 10cm locker erkannt.
>
> Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich
> befürchte ja, dass das Milchglas an sich schon reflektiert und somit
> schon zu einer (Falsch-)Erkennung führt.
>
> Grüße
> Markus

Qualitativ hört sich das gut an, ich denke aus dieser Perspektive könnte 
man die Erkennung kaum besser lösen.
Das mit dem Milchglas oder Plexi müsste man einfach ausprobieren. Ich 
vermute, dass es deutlichen Einfluss auf die Erkennungsschwelle hat, 
weil man die Reflexion unter die Empfindlichkeitsschwelle nehmen müsste.
Heisst die Reichweite sinkt. Müsste aber ok sein, das haben ja andere 
mit so einem Tisch auch schon gelöst.
Und das wird bei jeder Lösung so sein.

Die Frage ist aber, ob so ein Bauteil nötig ist. Kostet zusätzliches 
Geld (2,80 Euro hab ich gerade gefunden), ist fummelig zu löten.
Und ein uC ist für Bus und PWM sowieso schon da, m.E. kann der die 
IR-Touch-Erkennung gleich mitmachen.
Ein IR-Emitter, eine IR-Diode und ein Opamp sind günstiger als der 
Si1102 alleine.

Man müsste mal einen Prototypen machen, der tut wie ich es oben 
vorgeschlagen habe und herausfinden ob das funktioniert und wie gut.
Evtl. findet sich noch eine Lösung den Opamp rauszulassen, dann wär's 
optimal.

Bzgl. der Reflexion:
Vielleicht könnte man die Unterseite sogar mit einer 
reflexionsreduzierenden Schicht bekleben, es macht sicher einen 
drastischen Unterschied ob man eine spiegelnde Plexi/Glas-Fläche hat, 
die den IR-Strahl direkt und konzentriert auf den Empfänger zurückwirft 
oder ob man eine matte Folie davor hat, die das IR in alle Richtungen 
verteilt.
Die Verteilung/Diffusion sollte das auf den Sensor reflektierende IR auf 
einen Bruchteil (Fünftel, Zehntel?) reduzieren und die Empfindlichkeit 
der Touch-Erkennung wieder entsprechen anheben.

Das hat mich jetzt mal genauer interessiert. Siehe angehängte Grafik:
Bei direkter Reflexion trifft ca. 10% der Lichtenergie des IR-Emitters 
wieder den Empfänger.
Wenn es durch eine Matte Folie "in alle Richtungen" verteilt wird, ist 
es sicher kaum mehr 1%, also ein Zehntel oder weniger.
(Der IR-Empfänger ist hier in ein kleines schwarzes Röhrchen gepackt, 
das sicherstellt, dass er nur Licht von oben bekommt).

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Es gibt jetzt einen Artikel, wo wir Erkenntnisse dokumentieren können:
http://www.mikrocontroller.net/articles/RGB_Touch_Matrix

Ich würde vorschlage nur einigermassen fertig ausdiskutierte oder 
getestete Lösungen dort zu hinterlassen. Also Diskussion, 
Lösungserarbeitung hier, Ergebnis im Artikel.

von Tim R. (herrvorragend)


Lesenswert?

Markus M. schrieb:
> Hi,
>
> habe jetzt mal den Si1102 getestet...
>
>
> Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich
> befürchte ja, dass das Milchglas an sich schon reflektiert und somit
> schon zu einer (Falsch-)Erkennung führt.
>
> Grüße
> Markus

also ich habe wie gesagt mit dem is471 getestet (mit milch 
lichtdurchlässigen acryl/plexiglas). es ging wunderbar. ich musste nur 
die ausrichtung von sensor und ir-led etwas verändern und gegenseitig 
abschirmen, aber mein prototyp steht hier und funktioniert soweit 
einwandfrei. einzige problem besteht dabei, wenn die plexiglas nur ein 
wenig neigung hat, dann detektiert der sensor auch das glas (aufgrund 
des winkels). habe ca. 4-5cm abstand zwischen glas und led/sensor. und 
meine hand wird bis knapp 1-2cm über dem glas erkannt

mich würde nur noch interessieren, ob eine lösung mittels 
ir-fototransistor + verstärkerschaltung besser bzw. günstiger ist als 
die is471, weil die preislich doch etwas reinhauen bei mehreren pixeln

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> Markus M. schrieb:
>> Hi,
>>
>> habe jetzt mal den Si1102 getestet...
>>
>>
>> Die Frage ist nur, wie es auf ein Material wie Milchglas reagiert. Ich
>> befürchte ja, dass das Milchglas an sich schon reflektiert und somit
>> schon zu einer (Falsch-)Erkennung führt.
>>
>> Grüße
>> Markus
>
> also ich habe wie gesagt mit dem is471 getestet (mit milch
> lichtdurchlässigen acryl/plexiglas). es ging wunderbar. ich musste nur
> die ausrichtung von sensor und ir-led etwas verändern und gegenseitig
> abschirmen, aber mein prototyp steht hier und funktioniert soweit
> einwandfrei. einzige problem besteht dabei, wenn die plexiglas nur ein
> wenig neigung hat, dann detektiert der sensor auch das glas (aufgrund
> des winkels). habe ca. 4-5cm abstand zwischen glas und led/sensor. und
> meine hand wird bis knapp 1-2cm über dem glas erkannt

1-2cm ist fast ein bisschen wenig. Denke es sollte mehrere cm über dem 
Tisch beginnen, damit es nicht unangenehm zu bedienen ist?

> mich würde nur noch interessieren, ob eine lösung mittels
> ir-fototransistor + verstärkerschaltung besser bzw. günstiger ist als
> die is471, weil die preislich doch etwas reinhauen bei mehreren pixeln

Fototransistor m.E. ist zu langsam, wenn man mit einer Trägerfrequenz 
arbeitet, siehe oben. Bei 50-100 kHz ist das genau die Größenordnung, 
die der Fototransistor zu reagieren braucht.

von Tim R. (herrvorragend)


Lesenswert?

@Markus

falls du dir zum testen eine kleine plexiglasscheibe holen magst:

Ebay-Artikel Nr. 111002520558

habe mir dort eine 10x10x4mm besorgt (schnelle lieferung), um so den 
touch zu testen... denn ohne plexiglas sind alle testreihen die wir hier 
aufstellen eigentlich wertlos ;-)

von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> Tim R. schrieb:
>
> 1-2cm ist fast ein bisschen wenig. Denke es sollte mehrere cm über dem
> Tisch beginnen, damit es nicht unangenehm zu bedienen ist?
>

das ist jedem sein empfinden würde ich fast behaupten. aber zur not 
klemmt ein poti am is471, womit ich die reichweite etwas hochschrauben 
kann. ich persönlich möchte eigentlich nicht meine hand weit über den 
tisch halten, sondern wie beim smartphone oder ähnlichen richtiges 
"touch" verwenden, deshalb habe ich die reichweite eingegrenzt

>> mich würde nur noch interessieren, ob eine lösung mittels
>> ir-fototransistor + verstärkerschaltung besser bzw. günstiger ist als
>> die is471, weil die preislich doch etwas reinhauen bei mehreren pixeln
>
> Fototransistor m.E. ist zu langsam, wenn man mit einer Trägerfrequenz
> arbeitet, siehe oben. Bei 50-100 kHz ist das genau die Größenordnung,
> die der Fototransistor zu reagieren braucht.

vorallem haben die keine filter für das umgebungslicht oder ? hab 
zumindest nur normale transis gesehen die auch IR erkennen, aber nicht 
dafür "optimiert" waren...

um es mal zusammen zufassen:
wahlweise würden is471 oder der Si1102 unsere ansprüche umsetzen, 
richtig? :-)
wie sieht es eigtl. mit den TSOP aus, hat da jemand zufällig einen 
rumliegen?

grüße

von Markus M. (adrock)


Lesenswert?

...naja, der Si1102 hat auch mit einer roten LED funktioniert. Er 
funktioniert wohl zwischen 600nm und 950nm.

Ist somit nicht wirklich optimal, da ja dann auch die LEDs selbst alles 
beeinflussen würden.

Für die Lösung mit einem µC je Pixel:

Es gibt durchaus Phototransistoren, die relativ selektiv sind was die 
Wellenlänge angeht. Z.B. Osram SFH 310 FA oder 309 FA (andere 
Wellenlänge) oder auch Vishay TEFT4300 (sind jetzt alles TH Bauteile).

Idealerweise sollte man ein Modell finden, welches direkt ohne OP an den 
A/D-Wandler angeschlossen werden kann. Man müsste dann natürlich ein 
bisschen Hirnschmalz in das Programm auf dem Controller stecken, um eine 
gute Detektion zu erreichen. Aber da der Controller ja weiß, wann die 
IR-LED an/aus ist, muss er ja "nur" die Differenz des Signals vom 
Phototransistor nehmen, diese integrieren (aufsummieren über die Zeit) 
und hätte einen ersten Anhaltspunkt. Man könnte die weiteren Parameter 
für die Erkennung dann per Software gut anpassen.

Wenn man zusätzlich die RGB-LED ansteuern will und noch den BUS 
realisieren muss, kommt man allerdings mit dem kleinsten AVR nicht mehr 
hin.

Grüße
Markus

von Conny G. (conny_g)


Lesenswert?

Markus M. schrieb:
> ...naja, der Si1102 hat auch mit einer roten LED funktioniert. Er
> funktioniert wohl zwischen 600nm und 950nm.
>
> Ist somit nicht wirklich optimal, da ja dann auch die LEDs selbst alles
> beeinflussen würden.

Stimmt, der ist zu breit für eine gefilterte Wahrnehmung. Ist nicht 
einmal ein Wellenlängendiagramm drin, was dafür spricht, dass die 
Empfindlichkeit recht breit aufgestellt ist.

> Für die Lösung mit einem µC je Pixel:
>
> Es gibt durchaus Phototransistoren, die relativ selektiv sind was die
> Wellenlänge angeht. Z.B. Osram SFH 310 FA oder 309 FA (andere
> Wellenlänge) oder auch Vishay TEFT4300 (sind jetzt alles TH Bauteile).

Ich hatte darüber nachgedacht die Frequenz von IR-Fernbedienungen zu 
verwenden, also um die 40 Khz.
Hierfür würde ein Fototransistor nicht funktionieren, weil der schon 
2,5us zum schalten benötigt. 40 kHz ist 25us für eine Periode.
Das ist eher kritisch, wenn die Schaltfrequenz so nah an der 
Messfrequenz ist.
Also müsste man mit der Messfrequenz nach unten gehen, was aber 
eigentlich kein Problem wäre, wenn man nach dem Schema vorgeht:

1. IR-LED an
2. IR-Lichtstärke messen (generiertes IR-Licht)
3. IR-LED aus
4. IR-Lichtstärke messen (Fremdlicht)
5. Differenz berechnen
-> weiter bei 1
Und das für 10-20 Zyklen und den Mittelwert als Messwert verwenden

Dann muss man eigentlich nicht wie die TSOP etc. das tun mit einer 
Trägerfrequenz und Frequenzfilter arbeiten, weshalb die wohl eine recht 
hohe Frequenz verwenden.

Nach oben geschriebenem Algorithmus ist die Messfrequenz eigentlich fast 
egal, sie sollte nur hoch genug sein, dass man genügend Messwerte für 
einen Durchschnittswert in kurzer Zeit herausbekommt.
Sagen wir mal wir wollen 10-20 Touch-Werte pro Sekunde und 100 Samples 
für einen Messwert.
Dann müsste 1.000 Mal pro Sekunde gemessen werden, das schafft auch noch 
ein Fototransistor.
Man könnte dann auch noch auf 10 Khz gehen und das wäre für einen 
Fototransistor noch schaffbar (1 Periode = 40 x Schaltzeit 
Fototransistor).

> Idealerweise sollte man ein Modell finden, welches direkt ohne OP an den
> A/D-Wandler angeschlossen werden kann. Man müsste dann natürlich ein
> bisschen Hirnschmalz in das Programm auf dem Controller stecken, um eine
> gute Detektion zu erreichen. Aber da der Controller ja weiß, wann die
> IR-LED an/aus ist, muss er ja "nur" die Differenz des Signals vom
> Phototransistor nehmen, diese integrieren (aufsummieren über die Zeit)
> und hätte einen ersten Anhaltspunkt. Man könnte die weiteren Parameter
> für die Erkennung dann per Software gut anpassen.
>
> Wenn man zusätzlich die RGB-LED ansteuern will und noch den BUS
> realisieren muss, kommt man allerdings mit dem kleinsten AVR nicht mehr
> hin.

Was brauchen wir denn... genügend Taktzyklen und genügend Pins.
Taktzyklen halte ich aus dem Bauch nicht für das Problem.

Pins:
- 3 Pins für RGB, Software-PWM 8 Bit mit 1 8 Bit Timer
- 1-2 Pins für den Bus, 1 16 Bit Timer
- 1 Pin A/D Wandler für IR-Messung
= 6 Pins gesamt

Damit geht's nicht mehr mit einem 6-Beiner, mindestens 8 braucht es, 
wenn man das RESET Pin als normales Pin schaltet.

Als kleinster also Attiny13.

Der hat aber nur einen 8 Bit Timer, damit bliebe der Bus ohne Timer.
Evtl. könnte man aber auch Bus und PWM mit einem 8 Bit-Timer schaffen.

von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> 1. IR-LED an
> 2. IR-Lichtstärke messen (generiertes IR-Licht)
> 3. IR-LED aus
> 4. IR-Lichtstärke messen (Fremdlicht)
> 5. Differenz berechnen
> -> weiter bei 1
> Und das für 10-20 Zyklen und den Mittelwert als Messwert verwenden

wie dolle streut denn solch ein bauteil? wenn ich 20 mal messe und alle 
werte relativ große schwankungen aufweisen, ist das auch nur halb 
gewonnen. könnte man zwar mitteln, aber die streuung bleibt trotzdem 
relativ hoch. aber der ansatz wäre eine günstige alternative

> Pins:
> - 3 Pins für RGB, Software-PWM 8 Bit mit 1 8 Bit Timer
> - 1-2 Pins für den Bus, 1 16 Bit Timer
> - 1 Pin A/D Wandler für IR-Messung
> = 6 Pins gesamt


also ein einziger Pixel-/Controller benötigt nach dem bisherigen Schema 
was wir überlegt hatten:
-3 Pins RGB, PWM mit 8 Bit Timer
-4 Pins Bus (1x RGB in, 1x RGB out, 1x Sensorwert in, 1x Sensorwert out)
-Clock?
-ADC je nach dem welche Variante verwendet wird
=7-9 Pins gesamt... nach meiner Rechnung?

von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> Conny G. schrieb:
>> 1. IR-LED an
>> 2. IR-Lichtstärke messen (generiertes IR-Licht)
>> 3. IR-LED aus
>> 4. IR-Lichtstärke messen (Fremdlicht)
>> 5. Differenz berechnen
>> -> weiter bei 1
>> Und das für 10-20 Zyklen und den Mittelwert als Messwert verwenden
>
> wie dolle streut denn solch ein bauteil? wenn ich 20 mal messe und alle
> werte relativ große schwankungen aufweisen, ist das auch nur halb
> gewonnen. könnte man zwar mitteln, aber die streuung bleibt trotzdem
> relativ hoch. aber der ansatz wäre eine günstige alternative

Was meinst Du mit streuen?

>> Pins:
>> - 3 Pins für RGB, Software-PWM 8 Bit mit 1 8 Bit Timer
>> - 1-2 Pins für den Bus, 1 16 Bit Timer
>> - 1 Pin A/D Wandler für IR-Messung
>> = 6 Pins gesamt
>
>
> also ein einziger Pixel-/Controller benötigt nach dem bisherigen Schema
> was wir überlegt hatten:
> -3 Pins RGB, PWM mit 8 Bit Timer
> -4 Pins Bus (1x RGB in, 1x RGB out, 1x Sensorwert in, 1x Sensorwert out)
> -Clock?
> -ADC je nach dem welche Variante verwendet wird
> =7-9 Pins gesamt... nach meiner Rechnung?

Du hast recht, ich hab die Daisy Chain vergessen, sorry :-)
Also 6 oder 8 Pins, je nachdem ob Sensorbus separat oder nicht:
3 Pwm, 2 Bus, 1 ADC = 6
Optional plus 2 Sensorbus.

von Tim R. (herrvorragend)


Lesenswert?

wenn mehrere messungen alleine für das umgebungslicht angenommene Werte 
annehmen wie: 26 48 65 33 18 45... dann kann man das zwar mitteln, aber 
ob man dann den tatsächlich schwellwert für "touch aktiv" oder "touch 
nicht aktiv" erreicht ist relativ fraglich weil die streuung der werte 
so groß ist dass der fehler dementsprecht ansteigt. große streuung (also 
schwankung) der werte zieht einen großen fehler mit sich. oder seh ich 
das falsch?! ich kann leider nicht beurteilen wie gut diese sensoren mit 
infrarot sind und dann zusätzlich noch einer rgb im nacken...

bei der variante mit dem is471 fällt der adc pin weg ;-P
gibts denn überhaupt einen attiny mit 3 PWM kanälen? hatte gerade ein 
datenblatt offen wo leider 2 drin stand


ps: conny hast du meine nachricht bekommen?

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> wenn mehrere messungen alleine für das umgebungslicht angenommene Werte
> annehmen wie: 26 48 65 33 18 45... dann kann man das zwar mitteln, aber
> ob man dann den tatsächlich schwellwert für "touch aktiv" oder "touch
> nicht aktiv" erreicht ist relativ fraglich weil die streuung der werte
> so groß ist dass der fehler dementsprecht ansteigt. große streuung (also
> schwankung) der werte zieht einen großen fehler mit sich. oder seh ich
> das falsch?! ich kann leider nicht beurteilen wie gut diese sensoren mit
> infrarot sind und dann zusätzlich noch einer rgb im nacken...

Das mag sein, dass die Messwerte streuen, aber es sind halt Messwerte. 
Die sind ja dann für sich nicht falsch und ein fertiger Sensor hat doch 
genau dasselbe und muss damit arbeiten. Deshalb verstehe ich die Sorge 
nicht, denn wenn so ein fertiger Sensor das schafft dann wir auch.
Ein Fototransistor den wir verwenden ist ja auch nicht um eine 
Zehnerpotenz ungenauer als die Fotozelle eine fertigen Sensors?

> bei der variante mit dem is471 fällt der adc pin weg ;-P
> gibts denn überhaupt einen attiny mit 3 PWM kanälen? hatte gerade ein
> datenblatt offen wo leider 2 drin stand

Ich schrieb schon Soft PWM, brauchen für 3 windige 8 Bit Kanäle keine 
Hardware PWM.

> ps: conny hast du meine nachricht bekommen?

Ja, und geantwortet, aber Deine Emailadresse Bounces, "Mailbox Not 
available". Hab die Antwort per PN hier geschickt.

von Markus M. (adrock)


Lesenswert?

Hi,

also der "Algorithmus" macht in etwa das was die Näherungssensoren auch 
tun:

- IR LED aus
- A = Spannung am Phototransistor
- IR LED an
- B = Spannung am Phototransistor
- Summe += (A-B)

Die Summe über die Zeit X ergibt dann die Menge des reflektierten 
Lichtes. Wenn man dann noch einen Schwellwert einbaut hat man eigentlich 
schon ein einfaches Verfahren.

Nehmen wir mal an eine Messung dauert 50 µs (wie schnell ist der 
A/D-Wandler des ATtiny?), dann haben wir 20k Messungen pro Sekunde. /2 
wg. der IR-LED aus Phase und dann sagen wir mal 10 Messungen zum 
Aufsummieren... ergibt 1 ms für die Messung. Man könnte dann während der 
Messung sogar die RGB-PWM ruhen lassen um Seiteneffekte zu vermeiden.

An Pins benötigt man m.E. mindestens:

- IR LED Ausgang, könnte aber sein dass man da noch einen 
Treibertransistor benötigt, um der IR LED einen etwas höheren Strom zu 
geben (lt. Datenblatt max. 40mA für einen ATtiny 44/84). oder man 
schaltet zwei Ausgänge parallel...

- R/G/B LED Ausgang

- A/D-Wandler Eingang

- Bus (In/Out)

- Reset/debugWire

Komme da also leider auf 8 I/O-Pins.

Grüße
Markus

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Markus,

Du hast recht, IR Out habe ich auch noch vergessen!
Ja, dann sind wir incl Reset bei 8 und man könnte sich mal die 
zweitkleinsten Tinys ansehen.

von Tim R. (herrvorragend)


Lesenswert?

um mal vom theoretischen teil in die praxis zu kommen... hat denn jemand 
mal entsprechend bauteile für nen kurzen mess- bzw. testaufbau, ob das 
auch alles so funktioniert, wie gedacht? ;-P

von Conny G. (conny_g)


Lesenswert?

Ich hätte ein paar Atmega8 und Attiny da (für einen ersten Bustest oder 
den IR-Detektor Test müssten es noch nicht die finalen uCs sein), aber 
leider gar keine Zeit, weil ich noch 2 andere Projekte fertigzustellen 
habe.

von Düsendieb (Gast)


Lesenswert?


von Conny G. (conny_g)


Lesenswert?


von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> Ja, und geantwortet, aber Deine Emailadresse Bounces, "Mailbox Not
> available". Hab die Antwort per PN hier geschickt.

ja stimmt mein acc hier läuft auf eine uralt trach mail :-/

aber wo seh ich hier denn meine PNs? ich stell mich gerade richtig glatt 
an und finde kein postfach oder so *peinlich

von Conny G. (conny_g)


Lesenswert?

Die PNs werden per Email weitergeleitet. Vermutlich an genau dieses 
Emailpostfach :-)

von Tim R. (herrvorragend)


Lesenswert?

bin dabei die email zu tauschen, warte auf den admin..

ähm... weiter im thread?... oder erstmal den anderen thread weiterfüllen 
? :-)

von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
>
> Du hast recht, ich hab die Daisy Chain vergessen, sorry :-)
> Also 6 oder 8 Pins, je nachdem ob Sensorbus separat oder nicht:
> 3 Pwm, 2 Bus, 1 ADC = 6
> Optional plus 2 Sensorbus.

da fällt mir ein... wenn ich von einer 6pin ISP zum programmieren 
ausgehe, sind 4 Pins extra nötig... es sei denn man nimmt ein 
schaltungsdesign vor womit die pins zum proggen und ein/ausgabe 
verwendet werden können... ich weiß nur nicht wie dabei eine logik 
aussehen müsste, habe bisher isp immer extra beschalten

von Conny G. (conny_g)


Lesenswert?

Die ISP Pins kann man problemlos mit anderer Funktion belegen solange 
die andere Funktion nicht die Programmierung stört.
Oft braucht man keine extra Beschaltung dafür, manchmal tun es 
Widerstände zu den anderen Bauteilen, manchmal muss man einen digitalen 
Switch vorsehen, der durch RESET umgeschaltet wird.

von Conny G. (conny_g)


Lesenswert?

Hier auf Seite 7 steht was dazu:
http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf

Shared use of SPI programming lines
If additional devices are connected to the ISP lines, the programmer 
must be protected from any device, other than the AVR, that may try to 
drive the lines. This is especially important with the SPI bus, as it is 
similar to the ISP interface. Applying series resistors on the SPI 
lines, as depicted in Figure 3-2, is the easiest way to achieve this.
Note that the AVR will never drive the SPI lines in a programming 
situation, since the AVR is held in RESET to enter programming mode – 
and RESET’ing the AVR tri-states all pins.

D.h. wenn die Daisy Chain sicher nicht angesteuert wird während 
programmiert wird muss man nicht einmal den Widerstand einfügen.

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

http://www.mikrocontroller.net/articles/AVR_In_System_Programmer

ganz unten steht etwas zur benutzung der pins :-)
problematisch wird es beim eingang, sofern dieser nicht durchgeschaltet 
ist. im Text steht:
"Als Eingänge sollte man die Pins allerdings nicht verwenden, da ein 
angeschlossener Taster zum Beispiel die Programmierimpulse kurzschließen 
würde, wenn er gedrückt ist. "

da an jeder seite ein weiter pixel oder ein master klemmt, könnte das 
sogar problematisch werden oder nicht? zum programmieren müsste die 
komplette kommunikation still gelegt sein
alternativ könnt man einfach einen großen jumper zum programmiermodus 
abkommandieren, ist nur etwas nervig das ständige umschalten *g
switch der an reset geschaltet ist, wird denke ich die sicherste methode 
sein, welchezugleich nicht kompliziert ist

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Sollte es möglich sein, dass andere in der Chain senden, dann könnte man 
die in der Appnote genannten Schutzwiderstände verwenden.
Es macht aber eigentlich keinen Sinn, dass man die Pixel-Slaves mitten 
in der laufenden Schaltung programmiert.
Und wenn der Master (die Tisch-Steuerung) aus ist, dann tun auch die 
Pixel Slaves nichts.

Ansonsten kann man dem auch ganz aus dem Weg gehen und die ISP-Pins für 
PWM verwenden.

Vielleicht sollte man aber sowieso über einen Bootloader nachdenken, der 
die Firmware automatisch von Pixel zu Pixel weitergibt :-)

von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> Sollte es möglich sein, dass andere in der Chain senden, dann könnte man
> die in der Appnote genannten Schutzwiderstände verwenden.
> Es macht aber eigentlich keinen Sinn, dass man die Pixel-Slaves mitten
> in der laufenden Schaltung programmiert.
> Und wenn der Master (die Tisch-Steuerung) aus ist, dann tun auch die
> Pixel Slaves nichts.

ja stimmt, an den schlafenden master hatte ich nun gar nicht gedacht... 
guten morgen g

>
> Ansonsten kann man dem auch ganz aus dem Weg gehen und die ISP-Pins für
> PWM verwenden.
>
> Vielleicht sollte man aber sowieso über einen Bootloader nachdenken, der
> die Firmware automatisch von Pixel zu Pixel weitergibt :-)

daran hatte ich auch schon gedacht, nur fand ich einen bootloader etwas 
"überzogen", bin zufrieden wenn das ganze auch so erstmal steht hehe... 
aber um nicht 100pixel nach einander programmieren zu müssen wäre eine 
lösung "über-bus-programmierung" schon sehr hilfreich

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Könnte eigentlich genauso funktionieren wie die Daisy Chain à la 
ws2811... die Firmware wird direkt weitergeschickt.
Es müsste nur ein Trigger-Event geben, wann und warum die Slaves alle im 
Bootloader bleiben.

Dazu hatte ich schon mal drangedacht, dass man 4 Bytes statt 3 
übertragen könnte.
Einerseits könnte man dann 10 Bit PWM machen, also 3x10= 30 bit und hat 
dann noch 2 Bits für Protokoll-Befehle.
Und da könnte ein Befehl sein: RGB-Daten. Ein weiterer 
Sensor-Daten-Rückwärtsgang. Und ein dritter: Bootloader-Modus.
Die Slaves blieben dann nach dem Start für xxx Millisekunden im 
Bootloader, ob das Kommando kommt und wenn nicht -> normales Programm.
Wenn Bootloader, dann wird jedes Byte gespeichert und gleich 
weitergereicht.
Und das funktioniert dann genauso wie die RGB-Übermittlung.
Und wenn es beim Flashen einen CRC-Fehler gibt, dann schaltet der Slave 
die LED auf rot, die anderen auf grün.

von Conny G. (conny_g)


Lesenswert?

Oder... jeder Slave flasht (per Bootloader) seinen Nachbarn sobald er 
selbst fertig ist.
Damit könnte eine Wiederholung automatisch durchgeführt werden, wenn mal 
der CRC-Check daneben geht.

von Tim R. (herrvorragend)


Lesenswert?

das wäre ein guter ansatz. ich muss gestehen ich habe bisher bootloader 
nur verwendet aber selbst noch nie implementiert. kann man die einfach 
(in C) programmieren?! muss man irgendwas wichtig beachten?! ich müsste 
mir an der stelle erstmal ein wenig lektüre besorgen

bei 10bit ist der nette nebeneffekt, dass 1024 statt 256 farben 
theoretisch angesteuert werden könnten :-)

ein CRC wäre an der stelle ein muss. ich sehe schon ich produziere dann 
nur rote lichter


ich habe grad mal nach jahre das gute alte eagle vorgeholt. der tiny13 
reicht, wie besprochen, nicht aus... bin gerade am tiny23 dran nen 
pinkompatiblen chip in eagle zu finden... aber an sich sollte der genug 
IOs haben. kann die tage ja mal den kleinen schaltplan hochladen und 
dann kann das entwerfen der pixelplatine schon mal los gehen

von Conny G. (conny_g)


Lesenswert?

Bootloader ist nicht so schwierig, habe ich mich schon einmal einen 
kurzen Abend damit beschäftigt und ein Progrämmchen gemacht, das auf dem 
Uart sich dann als Bootloader meldet. Ist ziemlich leicht ein C-Programm 
als Bootloader zu deklarieren, im Prinzip muss es nur in die 
Bootloader-Section geschrieben werden beim Flashen und die 
Bootloader-Fuses gesetzt werden (BL an und Startadresse). War noch nicht 
da dann auch das Flash zu schreiben, aber da gibt's viele 
Bootloaderprojekte oder Tutorials für, vermute das wäre ein weiterer 
Abend oder zwei/drei bis das tut.

Hier:
http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung
Bis 6. hab ich's getestet.

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

für mich klingt das gerade nach jemandem, der sich freiwillig meldet ? 
;-)

von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> für mich klingt das gerade nach jemandem, der sich freiwillig meldet ?
> ;-)

Prinzipiell sehr gerne. Ich habe aber noch ein Projekt fertigzustellen, 
das noch um die 8 Wochen dauern wird, bis dahin nur Zeit zum Senf 
dazugeben.

von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> Tim R. schrieb:
>> für mich klingt das gerade nach jemandem, der sich freiwillig meldet ?
>> ;-)
>
> Prinzipiell sehr gerne. Ich habe aber noch ein Projekt fertigzustellen,
> das noch um die 8 Wochen dauern wird, bis dahin nur Zeit zum Senf
> dazugeben.

per spi einfach den bootloader reinladen wird wohl nicht funktionieren 
oder? es ist also ein isp-programmer dafür nötig...?! ansonsten kann man 
wirklich die komplette programmer schnittstelle "weglassen"

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> Conny G. schrieb:
>> Tim R. schrieb:
>>> für mich klingt das gerade nach jemandem, der sich freiwillig meldet ?
>>> ;-)
>>
>> Prinzipiell sehr gerne. Ich habe aber noch ein Projekt fertigzustellen,
>> das noch um die 8 Wochen dauern wird, bis dahin nur Zeit zum Senf
>> dazugeben.
>
> per spi einfach den bootloader reinladen wird wohl nicht funktionieren
> oder? es ist also ein isp-programmer dafür nötig...?! ansonsten kann man
> wirklich die komplette programmer schnittstelle "weglassen"

Nein, man muss den Bootloader schon vorher per ISP laden, dann kann man 
die Firmware mit dem Bootloader "wie auch immer" laden.
(Den Bootloader kann man sicher auch aus der Software schreiben, aber 
irgendwas muss auf dem uC laufen um ins Flash zu schreiben).

Man könnte aber für den Fall, dass man den Bootloader ersetzen muss 
einen Tag-Connect-Port vorsehen
http://www.tag-connect.com/catalog/6
Der Witz daran ist, dass man keine Headerleiste oder Stecker braucht, 
sondern nur Pads und Löcher auf der Platine hat auf die man das Kabel 
aufsteckt.
In 2-3 Wochen kann ich wohl was dazu dagen, ob es gut funktioniert. Das 
Kabel habe ich mir gerade gekauft und den Tag-Connect in eine Schaltung 
eingebaut, die ich gerade mache.

von Christian H. (c_h)


Lesenswert?

Es wäre schon möglich, dass ein Modul das nächste programmiert ohne dass 
zuvor ein Bootloader installiert wurde.

Fast jeder Atmega-Chip kann ein ISP-Programmer sein!

Dazu müssen nur die 3 SPI-Pins und der Reset-Pin des in der Kette 
nächsten, zu programmierenden Moduls mit 4 beliebigen Pins des 
vorherigen Moduls verbunden werden. Das sind leider dann 4 Leitungen von 
jedem Modul zu seinem Nachfolger, wodurch das Ziel Kabel zu sparen 
natürlich angegriffen wird. Im Gegenzug muss man die Module dann aber 
nur löten und verkabeln und nicht auch noch mit einem Bootloader 
programmieren!

Passender Source-Code würde sich bei Guloshop.de finden. Dort gibt es 
einen Programmer auf attiny85-Basis und auch den freien Source-Code. 
Dieser Programmer macht das zum Programmieren nötige SPI-Protokoll 
direkt per Port-Programmierung. Mit diesem Code könnte man bei einem 
attiny84 oder 2313 wohl 4 beliebige freie Pins mit den zum programmieren 
benötigten Pins des Nachfolgemoduls verbinden.

Der bei der Arduino-Software beiliegende Arduino-ISP Sketch ist auch 
interessant, aber weniger gut geeignet, weil er die Daten auf die 
ISP-Schnittstelle wirklich per HW-ISP des Atmega328p rausschreibt. D.h. 
SPI des Programmierers mit mit SPI des programmierten verbunden sein.

von Tim R. (herrvorragend)


Lesenswert?

also die funktion der pixel sollte anhand von einem prototypen aufbau 
mit 2-3 pixeln denke ich erstmal gemacht werden und anschließend sollte 
die software stehen... also nur im notfall wird dann nochmal die 
software für jeden pixel geändert werden... und dafür nen extra 
bootloader? zumal die pixel eh eine ISP brauchen, würde ich den 
bootloader erstmal als gimmick/feature betrachten oder nicht?

die geräte habe ich schon mal gesehen, fand ich ziemlich interessant... 
kannst ja mal berichten

tiny als DIP?

von Conny G. (conny_g)


Lesenswert?

Christian H. schrieb:
> Es wäre schon möglich, dass ein Modul das nächste programmiert ohne dass
> zuvor ein Bootloader installiert wurde.
>
> Fast jeder Atmega-Chip kann ein ISP-Programmer sein!

Das habe ich schon bedacht, aber wg. der Zielsetzung einen schlanken Bus 
zu haben, gleich ausgenommen.
Ich würde nicht mit 4 Leitungen von Pixel zu Pixel gehen wollen, nur um 
die programmieren zu können.

von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> also die funktion der pixel sollte anhand von einem prototypen aufbau
> mit 2-3 pixeln denke ich erstmal gemacht werden und anschließend sollte
> die software stehen... also nur im notfall wird dann nochmal die
> software für jeden pixel geändert werden... und dafür nen extra
> bootloader? zumal die pixel eh eine ISP brauchen, würde ich den
> bootloader erstmal als gimmick/feature betrachten oder nicht?

ISP muss nicht. Man könnte die ICs auch alle vor dem Einlöten 
programmieren. Nur für eine einmalige Nutzung wäre wirklich auch ein ISP 
unnötig.

Der Bootloader ist wirklich nicht unbedingt erforderlich. Auf der 
anderen Seite ist es einfacher ein bisschen Software auf allen Pixel zu 
haben um die in einer Chain alle zu aktualisieren als einen ISP Header 
auf jedem.

So ein Tag Connect wäre allerdings wieder nicht so schlecht, denn es 
kostet nur einen Quadratzentimeter Platinenplatz und sonst keine 
Bauteilkosten oder Löterei. Dann kann man jederzeit programmieren, wenn 
man will, braucht aber nicht 100 Header einlöten.

Zusammengefasst:
- die Software der Pixel ist (und muss) simpel sein
- ann muss der Pixel nur 1x programmiert werden
- ISP-Header für 1x ist quatsch
- Bootloader wäre "nett", muss aber nicht
- also OOSP (Out of system programming :-) oder Tag Connect
- falls die Pixel in china hergestellt werden (empfehlenswert), dann Tag 
Connect

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

ich würde dann einfach zum DIP greifen... sockel auf platine löten und 
die chips alle extern bespielen und anschließend raufklemmen... FALLS 
wirklich mal eine änderung nötig ist, kann man die chips immernoch 
rausholen und muss nicht entlöten

bootloader sehe ich auch als feature

der tag connect ist nett aufjedenfall... aber ob man das extra geld 
dafür aufbringen mag... ich weiß nich so recht der tisch verschlingt an 
sich genügend geld :-)

von Conny G. (conny_g)


Lesenswert?

Wenn die Platinen in China bestückt werden... ist es günstiger DIP oder 
SMD zu bestücken oder egal?
Ggf. wäre das ein Grund lieber einen Programmierheader oder Tag-Connect 
zu nehmen als DIP und Sockel.

Man müsste frühzeitig hier Angebote einholen und entscheiden ob selbst 
oder Ausland, da die Auftragsbestückung erheblichen Einfluss auf das 
Platinendesign nimmt.
Wenn man selbst 100 Stück bestückt und nur die Platinen bestellt, dann 
nimmt man lieber DIP als dass man 20x seinen Pizzaofen laufen lässt.
Wenn man Auftragsbestückung macht und es zeigt sich, das SMD günstiger, 
einfacher oder was weiss ich ist, dann ist SMD angesagt.

von Tim R. (herrvorragend)


Lesenswert?

kenne mich mit fertigung aus asien nich sonderlich aus, vllt kann ja mal 
jemand ein link einwerfen oder selbst erfahrungswerte beisteuern ? :-)

ich wäre für platinenfertigung und die controller selbst aufbringen, hat 
den vorteil, dass notfalls die wirklich nochmal runterkönnen (anders als 
beim smd löten)... ist zwar ein tag arbeit ungefähr 100 stück zu machen, 
aber gut, dafür sparen wir an anderen stellen haufen arbeit

so hab mal den tiny2313 im dip im schaltplan drin mit dem is471... 
teurer sensor aber ich habe bisher keine wirkliche alternative deswegen 
lass ich den sensor erstmal soweit drin, kann ja ggf noch geändert 
werden...

hatten wir eigtl schon über die leds gesprochen?!

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

hab mal eben rumgeschaut nach "starken" rgb-leds...

http://www.leds24.com/SuperFlux-RGB-LED-3-Chip-diffus-50-rot-gruen-blau-steuerbar
7,62mm, 20mA pro Chip
Lichtintensität Chip: rot=2500mcd - grün=4000mcd - blau=2000mcd

oder
http://www.led1.de/shop/led-rainbow-rgb-ultrahell/48mm-rgb/strawhat-led-48mm-rgb-4-pin-wedrgb03-cm.html?xploidID=78cvmdt90dggek448avtu1l4q1
4,8mm, 20mA
Max. Lichtstärke: 500mcd (rot) 1.800mcd (grün) 400mcd (blau)

aber vllt gibts ja bei ebay auch gute pakete mit 100 stück oder so?


die Frage ist auch, eine oder mehrere RGB pro Pixel? bei it-gecko.com 
wurde eine led pro pixel genommen und sah eigtl auch ausreichend aus 
denke ich. von daher würde ich zu einer led tendieren nur weiß ich nicht 
so recht was für welche, weil des doch schon recht krasse unterschiede 
gibt

: Bearbeitet durch User
von Markus M. (adrock)


Lesenswert?

Über einen Bootloader habe ich auch nachgedacht zum programmieren der 
Pixels.

Habe auch nach RGB-LEDs geschaut. Ich verstehe nicht, wieso bei den 
günstigen z.B. Blau die geringste Lichtstärke hat, eigentlich wird es 
doch vom Auge am "schlechtesten" wahrgenommen?!

Relativ ausgeglichene LEDs werden dann wohl schon wieder teurer... aber 
auch da müsste man wohl verschiedene ausprobieren und schauen ob sie den 
Ansprüchen genügen... Die Strawhead LEDs sehen aber ganz gut aus.

Habe mal die Kosten pro Pixel überschlagen und komme leider auf so ca. 4 
EUR pro Pixel... (ATtiny44A, IR-LED, IR-Phototransistor, Hühnerfutter, 
RGB-LED) zzgl. Platinchen...

von Conny G. (conny_g)


Lesenswert?

Sollte man auf ausgewogene Lichtstärke von RGB schauen?
Die zweiteren haben ja R G B ein Verhältnis von 1 : 3,5 : 0,8, das ist 
schon extrem Richtung grün.
Man sollte eine Kalibrierung vornehmen um bei 100% alle auf gleicher 
Helligkeit zu haben (R G B nebeneinander auf 100% sollten gleich hell 
aussehen), damit würde man das schon kompensieren, aber verschwendet 
damit 70% der Leistung der grünen.

Bzgl. Lichtstärke müsste man es einfach mal testen und ein paar kleine 
Boxen aus Pappe bauen im Format einer Zelle, also 6x6x6 cm, in einer 
Höhe von ca. 10cm und unten dann diverse Test LEDs in verschiedenen 
Stückzahlen einsetzen und die Farben durchtesten.

Vielleicht erstmal 1 Stück und die Farben von verschiedenen Modell 
anschauen und danach die Helligkeit zwischen 1 und 3 Stück.
Idealerweise würde man von den Farben bei moderatem Tageslicht auch noch 
was sehen.

Für den Helligkeitstest könnte an auch erstmal mit Abschnitten eines 
WS2812(B) testen und davon 1, 2, 3 in die Box legen.
Dann kennt man den Wert an Lumen (Leistung ohne Winkelabhängigkeit) bzw. 
Candela (mit Winkelabhängigkeit), den man braucht.
Ich glaube das ist ein einfacher Ansatz, mit den WS2812 zu testen. 
Sofern dort im Datenblatt die Lichtstärken angegeben sind.

Bzgl. des Winkels sehe ich 120 Grad eigentlich als Verschwendung von 
Lichtleistung, besser hätten sie 30-60 Grad.
Denn wg. möglichst engem Winkel des IR-Sensings (jede Zelle sollte 
eigentlich nur vertikal nach oben und wenig zur Seite messen) sollte die 
Platine etwas weiter unten sitzen (mind. 10 cm) und dann habe ich nach 
oben einen Winkel von < 45 Grad.
Und alles was die RGB-LEDs breiter strahlen geht einfach nur an die 
Seitenwand und wird nur teilweise reflektiert, selbst wenn die 
Seitenwand weiss ist.

Bauform ist eigentlich egal, höchstens noch von der Bestückung (selbst 
oder China) abhängig.
Können auch relativ gross sein, haben 6x6cm Platz.

Habe mir kürzlich 8mm WS2811 RGBs bestellt, die sind ziemlich hell. Habe 
die auch noch ohne WS2811, müsste mal testen, ob die genauso hell sind.
Datenblatt habe ich leider keins dazu, die mcd/lm Werte nachzusehen...

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Markus M. schrieb:
> Habe mal die Kosten pro Pixel überschlagen und komme leider auf so ca. 4
> EUR pro Pixel... (ATtiny44A, IR-LED, IR-Phototransistor, Hühnerfutter,
> RGB-LED) zzgl. Platinchen...

Und dann sind sie noch nicht bestückt, oder?

von Conny G. (conny_g)


Lesenswert?

Hier mal die nächstbesten 8mm RGB, die Google ausgespuckt hat:

http://www.powerledworld.com/de/20pcs-x-8mm-4pin-rgb-common-anode-led-light-redgreenblue-water-clear.html?language=de&currency=EUR

Sehen gar nicht mal so schlecht aus.
Abstrahlwinkel 35% finde ich bestens.
7 Euro / 20 = 35 Cent ist zu teuer, das geht m.E. für die Hälfte.

Die sind richtig hell, Winkel 20 Grad (fast ein bisschen wenig):
http://www.leds24.com/10mm-3-Chip-Rainbow-RGB-4-Pin-LED-20-RGB-LEDs-steuerbar?gclid=CO7uyKSMz70CFQIcwwod5F0AKw

Die Superflux, die Du schon gefunden hattest:
http://www.leds24.com/SuperFlux-RGB-LED-3-Chip-diffus-50-rot-gruen-blau-steuerbar
sind etwa gleich hell, haben aber doppelten Winkel.
Der Winkel von 50% passt aber ganz gut.

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Also beim 
WS2812Bhttp://www.mikrocontroller.net/attachment/180459/WS2812B_preliminary.pdf

haben wir:

RGB IC characteristic parameter

Emitting color  Model    Wavelength(nm)  Luminous intensity(mcd)
Red             13CBAUP  620-625         390-420
Green           13CGAUP  522-525         660-720
Blue            10R1MUX  465-467         180-200

also R = 400mcd, G = 700mcd, B = 200mcd,
wobei der Abstrahlwinkel hier auch mind. 120 Grad ist.

Gegenüber den Superflux RGB:
7,62mm, 20mA pro Chip
Lichtintensität Chip: rot=2500mcd - grün=4000mcd - blau=2000mcd

ist das etwa ein Fünftel.

Man könnte es also ungefähr vergleichen, wie die Helligkeit der 
Superflux herauskommt, wenn man 4-5 der WS2812b in so eine 6x6cm Testbox 
packt und weisses/diffuses Plexiglas drüberlegt.

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

heißt das die superflux sind dementsprechend 4 mal so hell oder wie kann 
man diese werte interpretieren?

dein letzter satz hat es eigentlich erst interessant gemacht... wie 
sieht das ganze unter plexiglas aus ;-)
wir können mutmaßen über abstände und lichtstärken, aber wie es im 
endeffekt ausschaut weiß man nicht, oder?
ich würde mich entschließen eine superflux oder andere led zu besorgen 
und mal unter meine lichtdurchlässige plexiglas vom touch-testaufbau zu 
packen...

habe ich das richtig verstanden, dass der abstand zwischen plexi und 
platine ~10cm bei dir in anspruch nehmen soll? ich bin momentan bei der 
hälfte...

Markus M. schrieb:
> Habe mal die Kosten pro Pixel überschlagen und komme leider auf so ca. 4
> EUR pro Pixel... (ATtiny44A, IR-LED, IR-Phototransistor, Hühnerfutter,
> RGB-LED) zzgl. Platinchen...

solange aber kein testaufbau mit einem ir-transi mal aufgebaut wurde, 
würde ich dort keine 100 stück bestellen ? .-) klang bisher simpel aber 
sollte zumindest mit einem prototypen belegbar sein...



ich wundere mich gerade wie bei gleicher stromaufnahme und anliegenden 
spannungen solch enorme lichtstärkenunterschiede zustande kommen... hat 
da jemand evtl. eine erläuterung?

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
> heißt das die superflux sind dementsprechend 4 mal so hell oder wie kann
> man diese werte interpretieren?

Man muss bei den Lichtstärkeangaben immer aufpassen, ob es 
winkelabhängig (mcd = Candela) oder unabhängig (Lumen) ist.

Lumen heisst: Lichtleistung insgesamt, die abgestrahlt wird, in alle 
Richtungen. Wird deshalb auch für die Angabe Lumen/Watt verwendet -> 
wieviel der Stromleistung wird in Lichtleistung umgewandelt.
Das macht nur Sinn ohne Abstrahlwinkel.

Cancela ist eine relative Einheit:
http://de.wikipedia.org/wiki/Candela
Die Candela [kanˈdeːla] [1] (lateinisch für Kerze) ist die 
SI-Basiseinheit der Lichtstärke, das heißt des von einem Objekt in eine 
gegebene Richtung ausgesandten Lichtstroms pro Raumwinkeleinheit 
(Steradiant, sr), gemessen in großer Entfernung von der Lichtquelle.

D.h. wieviel wird pro "sr" ausgesandt.

> ich wundere mich gerade wie bei gleicher stromaufnahme und anliegenden
> spannungen solch enorme lichtstärkenunterschiede zustande kommen... hat
> da jemand evtl. eine erläuterung?

Und deshalb sind die "mcd" bei der einen LED mit dem kleineren 
Abstrahlwinkel viel größer, weil dieselbe Lichtenergie auf einen 
kleineren Winkel abgestrahlt wird.

Entscheidend ist jetzt: Wir sehen nur das Licht, das oben auf die 6x6cm 
Plexiglasplatte trifft, d.h. am besten passt der Abstrahlwinkel 
möglichst gut zur Entfernung der LED von der Plexiglasplatte und dem 
dadurch aufgespannten Winkel, dann ist sie maximal hell im vgl. zur 
Lichtleistung, die sie insgesamt hat.
Denn alles, was an die Seitenwand geht ist "verloren". (Naja, es wird 
reflektiert, aber dabei verlieren wir einen großen Anteil davon, denn es 
ist bestenfalls weiss und kein Reflektor, der es nach oben strahlt).


> dein letzter satz hat es eigentlich erst interessant gemacht... wie
> sieht das ganze unter plexiglas aus ;-)
> wir können mutmaßen über abstände und lichtstärken, aber wie es im
> endeffekt ausschaut weiß man nicht, oder?

Ja, das lässt sich nicht über die reinen Lichtstärkewerte abschätzen.
ABER: Man kann von z.B. den WS2812B ungefähr auf andere LEDs schliessen, 
wenn man mal ermittelt hat, wieviel man davon haben will.
Oder jede andere LED zum Test, wo man die Lichtstärke kennt.

> ich würde mich entschließen eine superflux oder andere led zu besorgen
> und mal unter meine lichtdurchlässige plexiglas vom touch-testaufbau zu
> packen...
>
> habe ich das richtig verstanden, dass der abstand zwischen plexi und
> platine ~10cm bei dir in anspruch nehmen soll? ich bin momentan bei der
> hälfte...

Die 10cm verfolgen folgenden Gedanken:
Für die Abstrahlung der RGB LED ist es wurst, solange der Abstrahlwinkel 
der LED zusammen mit der Entfernung das Plexi genau ausleuchten.

Aber für das Touch-Sensing ist es m.E. sehr wichtig, dass der Winkel des 
Infrarotstrahls sehr eng ist, also am besten nur 10 Grad, höchstens 20 
Grad.
Denn jede Zelle des Tischs soll die Bewegungen ja auch nur darüber 
messen und nicht noch die Nachbarzelle.

Extremes Beispiel: bei 5cm Abstand und >70-80 Grad Abstrahlwinkel der 
IR-LED könnte der IR-Sensor nicht mehr unterscheiden, ob die Bewegung 
nun über seinem Feld oder über dem Nachbarfeld stattgefunden hat, denn 
wenn Du 5cm über das Plexi gehst, geht der Strahl bereits bis zur Mitte 
des Nachbarfeld.

Deshalb sollte die Platine möglichst weit nach unten, damit es nach oben 
wie ein "Rohr" wird.
Man könnte IR-LED und Sensor auch mit einem Röhrchen abschirmen, aber 
dann ergibt sich das gegenteilige Problem, dass direkt über dem Plexi 
der "Kreis" zu klein wird und der Rand nicht erfasst wird.

Hatte dazu weiter oben schon mal eine Skizze eingestellt, oder?
Ach, die war zum Vorschlag, dass man die Unterseite des Plexi oder 
Glases mit einer Entspiegelfolie bekleben sollte um das von dem Plexi 
direkt reflektierte IR-Licht möglichst viel zu streuen.

: Bearbeitet durch User
von Tim R. (herrvorragend)


Lesenswert?

das mit dem licht ergibt sinn, ich hätte wohl doch mal fix dr. goggle 
öffnen sollen :-)

Conny G. schrieb:
> Die 10cm verfolgen folgenden Gedanken:
> Für die Abstrahlung der RGB LED ist es wurst, solange der Abstrahlwinkel
> der LED zusammen mit der Entfernung das Plexi genau ausleuchten.
>
> Aber für das Touch-Sensing ist es m.E. sehr wichtig, dass der Winkel des
> Infrarotstrahls sehr eng ist, also am besten nur 10 Grad, höchstens 20
> Grad.
> Denn jede Zelle des Tischs soll die Bewegungen ja auch nur darüber
> messen und nicht noch die Nachbarzelle.
>
> Extremes Beispiel: bei 5cm Abstand und >70-80 Grad Abstrahlwinkel der
> IR-LED könnte der IR-Sensor nicht mehr unterscheiden, ob die Bewegung
> nun über seinem Feld oder über dem Nachbarfeld stattgefunden hat, denn
> wenn Du 5cm über das Plexi gehst, geht der Strahl bereits bis zur Mitte
> des Nachbarfeld.
>
> Deshalb sollte die Platine möglichst weit nach unten, damit es nach oben
> wie ein "Rohr" wird.
> Man könnte IR-LED und Sensor auch mit einem Röhrchen abschirmen, aber
> dann ergibt sich das gegenteilige Problem, dass direkt über dem Plexi
> der "Kreis" zu klein wird und der Rand nicht erfasst wird.


also das problem hatte ich bei meinen 5cm nicht. eher genau andersrum. 
meine bewegungen wurden erst zur "mitte" am genausten erkannt... also 
ein finger war sehr kritisch, bei zwei fingern wurde es dann sehr 
zuverlässig... und sobald beide finger nah der mitte waren wurde 
erkannt... wenn sie ansatzweise einen anderen pixel berührt hätten, 
hätte das diesen pixel nicht interessiert... vllt stell ich die tage mal 
nen vid online... ich verstehe deinen gedankengang, aber müsste mal 
schauen wie der is471 bei 10cm abstand überhaupt wirkt

von Rabenvogel (Gast)


Lesenswert?

Schaut mal hier, das sieht doch schnieke aus:
http://finnrudolph.de/Blog/Mongoose_-_RGBY_Desk

von Tim R. (herrvorragend)


Lesenswert?

hätte ja nicht gedacht das man so etwas mit fototransistoren 
hinbekommt... schönes teil aufjedenfall, danke für den link!

mit fototransistoren... aber wie funktioniert das genau, dass die farbe 
festgestellt wird, müssen ja gute filter sein :)

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?


von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> In etwa so:
> http://www.instructables.com/id/Introduction-29/?lang=de

ja hatte eben ähnliche seiten gefunden... etwas aufwendig aber machbar

von Michael H. (mha1)


Lesenswert?

Wirklich interessant der Tisch mit der Farberkennung

Anstelle von Fototransistoren mit Filtern könnte man für die 
Farberkennung auch fertige Sensoren nutzen. Damit sollte sich eine 
Farberkennung relativ einfach gestalten.

Bei meinen Recherchen vor einiger Zeit habe ich die unten stehenden 
Produkte gefunden. Leider waren von kaum einem Hersteller Muster zu 
bekommen und auch bei Mouser / Digekey sind diese Bausteine oft nicht 
auf Lager (Mindestbestellmenge dann teilweise 2000 Stück).

MAXIM
MAX44005, MAX44006, MAX44008

TAOS / AMS
TCS3103, TCS3104, TCS3404, TCS3414
TCS3471x, TCS3472x, TCS3772x (x=1,3,5,7)

Intersil
ISL29120, ISL29125

Kingbright
KPS-5130PD7C

Ich habe aktuell ein paar TCS34725 zum Test für ein anderes Projekt auf 
dem Schreibtisch liegen. Leider fehlt mir die Zeit mich mit einem 
weiteren Projekt aktiv zu beschäfigen.

Die TCS34725 sind in einem DFN-6 SMD Gehäuse und damit nicht ganz 
einfach ohne Reflow-Ofen zu bestücken. Bei einem Preis von knapp EUR 2,- 
pro Stück aber für die Farberkennung recht praktisch.

von Christian H. (c_h)


Lesenswert?

Könnte man nicht für sehr kurze Zeit Rot, dann Grün, dann Blau mit der 
sowieso vorhandenen PWM-gesteuerten LED anzeigen um die aufliegenden 
Gegenstände zu bestrahlen und jeweils den einen Phototransistor pro 
Modul abfragen um so die reflektierte Menge Licht für R, G und B zu 
erhalten? Danach kann die LED wieder PWM machen, bis zur nächsten 
Messung.

von Conny G. (conny_g)


Lesenswert?

Bleiben wir doch lieber erstmal beim Touch Sensing.

von Tim R. (herrvorragend)


Lesenswert?

Christian H. schrieb:
> Könnte man nicht für sehr kurze Zeit Rot, dann Grün, dann Blau mit der
> sowieso vorhandenen PWM-gesteuerten LED anzeigen um die aufliegenden
> Gegenstände zu bestrahlen und jeweils den einen Phototransistor pro
> Modul abfragen um so die reflektierte Menge Licht für R, G und B zu
> erhalten? Danach kann die LED wieder PWM machen, bis zur nächsten
> Messung.

finde den einwand gar nich so schlecht :-) man müsste nur einen 
geeigneten fotowiderstand oder ähnliches finden... würde damit der 
"touch" nicht auch funktionieren?

einzige problem seh ich, wenn sich zwischenzeitig das umgebungslicht 
ändert

: Bearbeitet durch User
von tester (Gast)


Lesenswert?


von Tim R. (herrvorragend)


Lesenswert?

tester schrieb:
> 
http://www.reichelt.de/Optokoppler/ELI-TR9904/3/index.html?&ACTION=3&LA=2&ARTICLE=114342&GROUPID=3046&artnr=ELI+TR9904

der zufall wollte es so, mein kollege hat mir aus seinem 
bauteilreservoir so eine lichtschranke vorzaubern können... im 
datenblatt konnt ich nichts zur reichweite finden, ausser dass es für 
"scanner" und ähnliches geeignet ist... deshalb habe ich die IR-led von 
diesem bauteil an den ausgang von meinem is471 gehängt, damit ich nicht 
selbst fix ein programm schreiben muss für das signal... ich muss aber 
sagen, die erkennungsreichweite liegt bei irgendwie zwischen 0-2cm... 
also quasi gar nichts. mein poti der den transistor basis für die ir-led 
regelt konnte dabei auch nicht wirklich viel ändern. denke das mein 
aufbau soweit richtig ist, aber lasse mich gerne eines besseren 
belehren, wenn jemand erfahrung mit dem oben genannten bauteil hat ? :-)
ansonsten schade, bleibe ich bis dato bei dem is471...

ps.: leben die anderen teilnehmer hier noch ? :-P

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Lebe noch. Aber habe kein Interesse an der RGB Farbmessung. Lieber ein 
guter IR Touch Sensor.
Und da kann ich vor Testaufbau nichts dazu sagen. Und für den habe ich 
gerade keine Zeit.
Muss erst dieses Teil hier finalisieren, produzieren, programmieren, 
testen.
Beitrag "Re: Review von Schaltung und Routing"
Und danach eine Steuerung entwickeln die das DMX dafür sendet, sowie 
zwei weitere Lichtobjekte via Lichtschalter und Lan steuerbar macht.

von Tim R. (herrvorragend)


Lesenswert?

Conny G. schrieb:
> Lebe noch. Aber habe kein Interesse an der RGB Farbmessung.

die war auch eher geflaxt... glaub das nimmt noch mehr zeit in anspruch 
die ich zumindest nicht habe..

> Lieber ein
> guter IR Touch Sensor.

deswegen habe ich noch eine alternativen fototransistor getestet, aber 
mit mäßgem erfolg...

na dann viel erfolg!

von tester (Gast)


Lesenswert?

um die diskussion mal wieder ein wenig voran zu treiben:

mir kam ein gedanke beim foren-stöbern... wie wäre es mit einer 
mechanischen auswertung? zum beispiel mit waagen an jeder ecke oder 
kante... kann mir nur nicht genau vorstellen, wie genau dann die pixel 
ausgewertet werden können

nachteil: man muss berühren und ggf etwas fester drücken... ein drüber 
wischen oder im millimeterabstand drüber halten ist dann nicht mehr 
viel..

vorteil: kostengünstiger als fertig IR, wie es mit selbst erbrachter IR 
erkennung aussieht, schwer zu sagen... bisher kam leider keine zumindest 
brauchbare/getestete lösung

von Karol B. (johnpatcher)


Lesenswert?

Hi,

tester schrieb:
> mir kam ein gedanke beim foren-stöbern... wie wäre es mit einer
> mechanischen auswertung? zum beispiel mit waagen an jeder ecke oder
> kante... kann mir nur nicht genau vorstellen, wie genau dann die pixel
> ausgewertet werden können

Vorschlag wurde weiter oben sogar schon einmal gemacht. Mit persönlich 
gefällt das nicht, und ich bin auch skeptisch was die Auswertung angeht, 
gerade in Bezug auf "Multitouch". Mit IR hingegen ist das alles möglich 
-- zumindest theoretisch.

Ich hatte letztes Jahr etwas ähnliches vor (nachdem ich o.g. YouTube 
Video gesehen habe) und bin interessanterweise in vielerlei Hinsicht zu 
den selben Schlüssen gekommen, d.h. modular und Auswertung per IR.

Bin dabei auf die Kombination ELPD204-6B und ELIR604-6B gestoßen, da 
diese günstig sind und Datenblatt technisch gut zusammen passen. Ich 
hatte mir allerdings überlegt ggf. jeweils 2 oder 4 Dioden pro Modul zu 
verwenden, um auch am Rand eine vernünftige Empfindlichkeit 
gewährleisten zu können. Allerdings spielt hierbei die geometrische 
Anordnung eine Rolle, sodass Reflexionen nicht von den Nachbarn 
ausgewertet werden. Eventuell würde sich das aber auch mit ein bisschen 
Logik in der Software verhindern lassen, immerhin weiß ja die Software 
wann mit Reflexionen zu rechnen ist (also wann die IR-LEDs an sind).

Habe das Ganze auch vor mir liegen, bin allerdings noch nicht dazu 
gekommen einen vernünftigen Versuchsaufbau anzufertigen. Wurde sich denn 
mittlerweile schon auf die Größe eines Pixels geeinigt? Rein vom Bus her 
sind wir wohl auf (höchstens) 200 Module beschränkt. Alles darüber wird 
schon eine Herausforderung. Insofern würde ich 10x10cm vorschlagen, 
womit sich z.B 1x2m Fläche füllen lassen würden. Ggf. müsste man die 
Module selbst aber kleiner gestalten, sodass die einzelnen Zellen 10x10 
cm groß sind. Das hängt dann aber von der verwendeten Technik ein. Ich 
dachte hier an Holz, welcher per Laser geschnitten wird. Das hat sich im 
3D-Druck bewährt und ist verhältnismäßig stabil und günstig.

Was den Mikrocontroller angeht: Man kann auch ein paar Pins sparen, 
indem man auf echte LED-Treiber setzt. Würde das Ganze gerne hell haben, 
und da stoßen meiner Erfahrung nach die Mikrocontroller an ihre Grenzen, 
zumindest, wenn man die Datenblattkonform betreiben möchte. IR-LEDs 
vertragen i.d.R. mehr Strom und es macht wahrscheinlich Sinn das 
auszunutzen, um das SNR aufzubessern.

Ein entsprechenden LED-Treiber vorausgesetzt könnte man sich auch die 
Software-PWM sparen. Andererseits treibt das natürlich wieder die kosten 
in die Höhe.

Wir sollten uns im Übrigen auch auf das Material der Oberfläche einigen. 
Plexiglas halte ich persönlich für nicht so schön, weil ich Glas für 
beständiger und kratzfester halte, wenn man den Tisch wirklich als Tisch 
benutzten sollte.

Wie seht ihr das Alles? Besteht überhaupt noch Interesse an einem 
"gemeinsame" Projekt? Scheint ja trotz der anfänglichen Euphorie ein 
bisschen eingeschlafen zu sein das Ganze ...

Mit freundlichen Grüßen,
Karol Babioch

von Markus M. (adrock)


Lesenswert?

Hi,

so ganz grundsätzlich verfolge ich das schon noch. Allerdings habe ich 
momentan weder Zeit noch Geld einen "richtigen" Tisch zu bauen.

Deine Meinung zu der Oberfläche (echtes Glas) teile ich. Die Oberfläche 
wird direkt Auswirkungen auf die Auswertung/Aufbau der 
Berührungserkennung haben.

Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert 
werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten 
ist o.ä.
Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst 
großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl. 
der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht) 
und entsprechende IR LEDs (passende Wellenlänge zu dem IR 
Phototransistor).

Wenn die Auswertung/IR-Abtastung der Berührung/Näherung "Pixelweise" 
nacheinander erfolgt, sollten sich doch die Reflexionen von 
Nachbarpixeln in Grenzen halten.

Aber man müsste das wirklich alles mal an einem "Messaufbau" z.B. 3x3 
Pixel) testen.

Ob man die IR-LEDs wirklich mit höherem Impulsstrom betreiben muss wird 
sich zeigen.

Wir haben letztendlich mehrere Baustellen:

- Mechanischer Aufbau (Material, Dicke, Abstände etc.)
- IR Sender / Empfänger Auswertungsmimik
- "Beleuchtung" (RGB LED, ggf. Treiber oder WS2812B?)
- Kommunikation zwischen den Pixeln bzw. Anbindung über einen Bus (inkl. 
Möglichkeit einer automatischen Neuprogrammierung der Pixelcontroller)

Ciao...
Markus

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Markus M. schrieb:
> Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert
> werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten
> ist o.ä.
> Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst
> großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl.
> der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht)
> und entsprechende IR LEDs (passende Wellenlänge zu dem IR
> Phototransistor).

Das mit dem breiten Erfassungswinkel ist der falsche Ansatz. Sonst kann 
man zwei Zellen nebeneinander nicht unterscheiden, wenn es keine scharfe 
Zellenabgrenzung gibt.
Der Strahl muss aus jeder Zelle relativ steil herauskommen, dazu braucht 
es ein Stück Abstand von der Oberfläche.
Kann man selber ausrechnen: bei ca. 7x7cm Zellengröße (60x60 Tisch als 
eine Größenoption mit 10x10 Zellen) und nur 90 Grad Abstrahlwinkel wird 
eine Hand bei einem Abstand von 5cm noch in der Mitte der Nachbarzelle 
erfasst - das nimmt dem Konzept jede "Schärfe" in der Erkennung.
Wenn man steileren Winkel will, kommt man um eine gewisse Aufbauhöhe, 
wie 10cm, nicht herum (wenn man mit 1 IR-LED arbeiten will. Mir mehreren 
kann man auch welche mit schmalem Winkel nehmen oder sie in ein Röhrchen 
stecken. Aber mehrere ist m.E. bei 100 Zellen keine Optione).

von Conny G. (conny_g)


Lesenswert?

Karol Babioch schrieb:
> Wie seht ihr das Alles? Besteht überhaupt noch Interesse an einem
> "gemeinsame" Projekt? Scheint ja trotz der anfänglichen Euphorie ein
> bisschen eingeschlafen zu sein das Ganze ...

Schon interessiert an dem Tisch, aber wie erwähnt hab ich kaum / keine 
Zeit. Wird bei mir eher noch (2-3?) Monate dauern, bis aktuelle 
Elektronikprojekte abgefrühstückt sind.

von Ast E. (vis)


Angehängte Dateien:

Lesenswert?

schön zu lesen, dass es doch noch interessierte gibt

ich bin momentan auf wohnungssuche und würde nach erfolgreichem umzug 
mich wieder intensiv dem thema widmen.

Markus M. schrieb:
> Deine Meinung zu der Oberfläche (echtes Glas) teile ich. Die Oberfläche
> wird direkt Auswirkungen auf die Auswertung/Aufbau der
> Berührungserkennung haben.

Wollt ihr ein durchsichtiges Glas benutzen? Dann sieht man die ganze 
Elektronik, was denk ich keiner will. Also wird es ein mattes Glas 
werden. Das Problem dabei ist, es muss relativ gut Lichtdurchlässig 
sein. Gibt es geeignete Gläser dafür die auch bezahlbar sind? Ich hab 
mich aus Kostengründen und weil mein Test erfolgreich mit Plexiglas war, 
eben für lichtdurchlässige Acryl-Milchgläser entschieden

> Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert
> werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten
> ist o.ä.

das denke ich auch

> Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst
> großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl.
> der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht)
> und entsprechende IR LEDs (passende Wellenlänge zu dem IR
> Phototransistor).
>
> Wenn die Auswertung/IR-Abtastung der Berührung/Näherung "Pixelweise"
> nacheinander erfolgt, sollten sich doch die Reflexionen von
> Nachbarpixeln in Grenzen halten.
>
> Aber man müsste das wirklich alles mal an einem "Messaufbau" z.B. 3x3
> Pixel) testen.

Mein nächster Test sollte eine Kaskadierung von 3-4 Pixeln sein, zum 
Testen der Kommunikation und zum feststellen, wie sehr sich die IR 
Sensoriken beißen

>
> Ob man die IR-LEDs wirklich mit höherem Impulsstrom betreiben muss wird
> sich zeigen.
>
> Wir haben letztendlich mehrere Baustellen:
>
> - Mechanischer Aufbau (Material, Dicke, Abstände etc.)

ich würde ein 5x5cm Feld als Größe vorschlagen. 10x10cm ist ziemlich 
groß meines erachtens

> - IR Sender / Empfänger Auswertungsmimik
> - "Beleuchtung" (RGB LED, ggf. Treiber oder WS2812B?)

da jeder Pixel eine einzelne RGB benötigt (oder auch mehrere), würde ich 
zu relativ starken LEDs tendieren ohne extra Treiber. Die PWM kann auch 
leicht ein ATTiny liefern

> - Kommunikation zwischen den Pixeln bzw. Anbindung über einen Bus (inkl.
> Möglichkeit einer automatischen Neuprogrammierung der Pixelcontroller)

Diese Thematik war meines erachtens relativ weit voran geschritten. Im 
DaisyCHain (Kaskadierung) der Pixel kann einfach und komfortabel eine 
Kommunikation geschaffen werden. Jeder Pixel hat 2 In- und 2 Outputs. 
RGB_IN, RGB_OUT, TOUCH_IN, TOUCH_OUT... Der Mastercontroller sendet in 
jeweils 3Byte (RGB) für jeden Teilnehmer dessen Farbwerte. Der Master 
schiebt also den Datenzug von 3Byte mal x Pixel an. Der erste Teilnehmer 
entnimmt seine 3Byte Daten (RGB_IN) und schiebt die restlichen Daten 
weiter (RGB_OUT). Die Pixel senden nach erfolgreichem Empfangen ihren 
Touch-Status an den Master (ggf. über mehrere Pixel) über TOUCH_OUT. Die 
Pixel die dazwischen liegen nehmen am TOUCH_IN den Touch Status vom 
nachliegenden Pixel auf und senden diesen in der Reihe weiter.
Ich glaub ich habe das ganze gerade etwas umständlich erklärt, aber zur 
Not stehen ja oben nochmal mehrere Erläuterungen ;-)

Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig 
Software... und das ganze kann auf alle Pixel geflasht werden.

>
> Ciao...
> Markus

Im Anhang befindet sich mal ein fixer Schaltplan von mir, so wie ich es 
mal mit der IS471 angedacht hatte. Ich werde mir gleich mal die eben 
geposteten Sensoren anschauen, evtl sind die besser. Ihr könnt ja 
einfach mal Kritik/Vorschläge/Ideen hageln lassen. :-)

Grüße
Tim


ps:
http://www.mikrocontroller.net/articles/RGB_Touch_Matrix

: Bearbeitet durch User
von Karol B. (johnpatcher)


Lesenswert?

Tim R. schrieb:
> Im Anhang befindet sich mal ein fixer Schaltplan von mir, so wie ich es
> mal mit der IS471 angedacht hatte. Ich werde mir gleich mal die eben
> geposteten Sensoren anschauen, evtl sind die besser. Ihr könnt ja
> einfach mal Kritik/Vorschläge/Ideen hageln lassen. :-)

Das Problem des IS471 ist halt der Preis. Meine Lösung auf Basis von 
ELPT204-6B und ELIR204-6B kostet pro Pixel nur 40 Cent.

Habe das Ganze mittlerweile auch getestet und halte das Ergebnis für 
gut. Mein Pixel ist 10x10 Pixel groß und 8 cm hoch. Das ist ziemlich 
groß, werde es nachher nochmal kleiner basteln. Der Unterschied zwischen 
"nichts aufgelegt" und "Hand aufgelegt" liegt derzeit bei 980 mV, und 
ist gut detektierbar. Interessanter wird es bei "Finger am Rand" 
aufgelegt, da wird der Unterschied entsprechend kleiner und eine echte 
Herausforderung. Mit kleineren Pixeln sollte das aber hoffentlich besser 
werden. Andererseits heißt kleinere Pixel = mehr Pixel = höhere 
Anforderung an den Bus. 10x10 sollen es bei mir schon werden, mehr ist 
besser, irgendwann dann allerdings natürlich auch eine Frage des Geldes 
;).

Was haltet ihr denn von dem Vorschlag mehrere IR-Dioden (zumindest 
Photodioden für den "Empfang") zu verwenden. Damit dürften sich nämlich 
Reflexionen aus anderen Zellen erkennen lassen, weil nicht alle 
"Empfänger" (gleich stark) angestrahlt werden. Die Frage ist nur wie 
viele vertretbar sind, wie viele Pins wir übrig haben und welche 
geometrische Anordnung sich hierfür anbietet?


Tim R. schrieb:
> da jeder Pixel eine einzelne RGB benötigt (oder auch mehrere), würde ich
> zu relativ starken LEDs tendieren ohne extra Treiber. Die PWM kann auch
> leicht ein ATTiny liefern

Starke LEDs + kein Treiber ist ein wenig ein Widerspruch. AVRs sind 
i.d.R. für irgendwas zwischen 20 mA und 40 mA spezifiziert. Meistens 
schaffen sie nicht mal das, wenn mehrere Pins gleichzeitig beansprucht 
werden. In Software kann (je nach Taktfrequenz und je nachdem wie genau 
wir den Bus implementieren) eine 8-Bit PWM  schon eine Herausforderung 
werden. Dot-Correction haben wir da dann auch noch nicht. RGB kostet 
mindestens auch 3 Pins. LED Treiber kümmern sich um all das, machen den 
Hardware Aufbau einfacher (keine Widerstände notwendig) und brauchen zum 
Teil nur ein einzigen Pin. Insofern tendiere ich ganz stark für den 
Einsatz eines solchen Treibers.

Tim R. schrieb:
> Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig
> Software... und das ganze kann auf alle Pixel geflasht werden

Apropos flashen: Was ist aus der Bootloader Idee geworden? Wenn wir uns 
nämlich wirklich für mehrere IR-Photodioden + Logik in Software zur 
Detektion entscheiden sollten, wäre es immer denkbar, dass man 
"Verbesserungen"/Kalibrierungen einspielen möchte. Manuell 100+ Pixel zu 
flashen, macht dann wohl keinen Spaß mehr ;).

Mit freundlichen Grüßen,
Karol Babioch

von Ast E. (vis)


Lesenswert?

ja ich weiß die sind leider teuer... aber bieten auch etwas dafür, finde 
ich

mehrere sensoren wäre auch eine idee... ich kann nur nicht abschätzen 
wie die software dazu aussehen müsste bzw. ob dazu ein cleverer algo 
nötig ist, um fremdeinwirkendes IR ausschließen zu können

Ok etwas unglücklich ausgedrückt. natürlich wird eine extra beschaltung 
für die leds nötig. wie im schaltplan zu sehen hatte ich erstmal an 
transistoren zum schalten gedacht und dann sollte das ja kein problem 
darstellen, oder?

led-treiber per i2c oder was schwebt dir vor? der benötigt eben auch nur 
wieder extra platz und erzeugt kosten. aber an sich vereinfacht das 
natürlich eine menge

im datenblatt findet man leider keine distanzen zu dem sensor... aber 
wenn du meinst e funktioniert gut, kannst du gerne mal ein video oder 
ähnliches hochladen, wo die masse den effekt auch beobachten kann :-)

grüße

: Bearbeitet durch User
von Karol B. (johnpatcher)


Lesenswert?

Tim R. schrieb:
> ja ich weiß die sind leider teuer... aber bieten auch etwas dafür, finde
> ich

Nichts was man nicht für 1/5 des Preises selbst bauen könnte, zumindest 
für unsere Ansprüche ...

Tim R. schrieb:
> mehrere sensoren wäre auch eine idee... ich kann nur nicht abschätzen
> wie die software dazu aussehen müsste bzw. ob dazu ein cleverer algo
> nötig ist, um fremdeinwirkendes IR ausschließen zu können

Wir müssten uns einfach auf die Größe eines Pixels festlegen. Habe jetzt 
zuletzt mit 5x5x3 cm gearbeitet, finde das fast ein wenig klein, bzw. 
bin mir nicht sicher, ob wir die Elektronik + Steckverbindungen nachher 
wirklich auf dieser Fläche unterbringen. Mehrere Sensoren machen bei 
dieser Größe vermutlich auch gar keinen Sinn. Bei 10x10 hingegen sieht 
das schon wieder anders aus.

Tim R. schrieb:
> Ok etwas unglücklich ausgedrückt. natürlich wird eine extra beschaltung
> für die leds nötig. wie im schaltplan zu sehen hatte ich erstmal an
> transistoren zum schalten gedacht und dann sollte das ja kein problem
> darstellen, oder?

Prinzipiell natürlich möglich. Erfordert aber alles extra Beschaltung. 
Ich persönlich mag bipolare Transitoren ala BC337 nicht besonders für 
diesen Zweck. FETs sind mir da lieber. Außerdem hast du noch die 
Basistransistoren vergessen ;).

Tim R. schrieb:
> led-treiber per i2c oder was schwebt dir vor? der benötigt eben auch nur
> wieder extra platz und erzeugt kosten. aber an sich vereinfacht das
> natürlich eine menge

Die gibt es in verschiedenen Ausführungen. Gibt auch echte 
Einpin-Lösungen, die implizit über das Timing gesteuert werden. Klar, 
ein bisschen teurer wird es (im Vergleich zu Widerständen + BC337). 
Platztechnisch könnte das aber sogar günstiger sein. Da wir mit der 
Diodenlösungen aber 2 Euro sparen (im Vergleich zu IS471), haben wir in 
dieser Beziehung etwas mehr Spielraum. Habe mir noch nicht alle Optionen 
angesehen, aber die gehen so in etwa bei 50 Cent los, und sollten 
hoffentlich für unter 1 Euro zu bekommen sein.

Tendenziell haben wir auch den Vorteil, dass wir eine entsprechende 
Sammelbestellung organisieren könnten. Da wohl jeder mindestens 100+ 
Module braucht, kommen wir da schnell in einen "günstigeren" Bereich.

Tim R. schrieb:
> im datenblatt findet man leider keine distanzen zu dem sensor... aber
> wenn du meinst e funktioniert gut, kannst du gerne mal ein video oder
> ähnliches hochladen, wo die masse den effekt auch beobachten kann :-)

Sind ja auch keine Distanzsensoren, sondern IR-Photodioden. Diese als 
Touch-"Sensor" zu verwenden ist im Prinzip nur eine "kreative" 
Anwendung. Die mögliche Entfernung hängt von vielen Faktoren ab - unter 
anderem wie stark die IR-LED ist und wie stark das Glas reflektiert.

Bin mit dem Ergebnis bei einem einzigen Pixel zufrieden. Werde sehen, 
dass ich das bis zum nächsten Wochenende zu einer 3x3 Konstruktion 
ausbaue und auch vernünftig per Mikrocontroller auswerte. Derzeit fehlen 
z.B. noch die RGB-LEDs, aber die sollten laut Datenblatt der 
IR-Photodiode kein allzugroßen Effekt haben. Komme dann hoffentlich auch 
dazu ein Demo-Video anzufertigen.

Unabhängig davon sollten wir uns aber trotzdem auf einige Dinge 
festlegen, bevor wir wirklich weiter machen können:

- Größe (Länge, Breite, Höhe) eines Pixels -> Mein Vorschlag: 5x5x3 cm
- Maximale Anzahl von Pixeln -> Mein Vorschlag: 20x20 wären schön, je 
nach Bus wird das aber "schwierig"
- Typ und Stärke der Oberfläche: Das hat vermutlich den größten 
Einfluss. Werde zusehen, dass ich ein paar Muster bestelle, um das dann 
auch testen zu können.

Mit freundlichen Grüßen,
Karol Babioch

von Ast E. (vis)


Lesenswert?

Karol Babioch schrieb:
> Nichts was man nicht für 1/5 des Preises selbst bauen könnte, zumindest
> für unsere Ansprüche ...

das ist richtig. wie reagiert dein sensor bei verschiedenen 
umgebungshelligkeiten? der is471 nutzt ja extra filter, was ich sehr gut 
fand

> Wir müssten uns einfach auf die Größe eines Pixels festlegen. Habe jetzt
> zuletzt mit 5x5x3 cm gearbeitet, finde das fast ein wenig klein, bzw.
> bin mir nicht sicher, ob wir die Elektronik + Steckverbindungen nachher
> wirklich auf dieser Fläche unterbringen. Mehrere Sensoren machen bei
> dieser Größe vermutlich auch gar keinen Sinn. Bei 10x10 hingegen sieht
> das schon wieder anders aus.

stimmt das könnte ein problem werden, bei einem 5x5 feld. evtl. doch ein 
10x10cm feld?! so lässt sich mit einer 10er reihe auch ein tisch von 
einem meter länge gut erreichen :-) bei 5x5cm feldern müssten schon 
knapp 20 pixel in eine reihe (+overhead vom gerüst)


> Prinzipiell natürlich möglich. Erfordert aber alles extra Beschaltung.
> Ich persönlich mag bipolare Transitoren ala BC337 nicht besonders für
> diesen Zweck. FETs sind mir da lieber. Außerdem hast du noch die
> Basistransistoren vergessen ;).

könntest du mir näher erläutern was du mit basistransistor meinst?


> Tendenziell haben wir auch den Vorteil, dass wir eine entsprechende
> Sammelbestellung organisieren könnten. Da wohl jeder mindestens 100+
> Module braucht, kommen wir da schnell in einen "günstigeren" Bereich.

grundsätzlich ja! müssten sich nur zum gegebenen zeitpunkt genügend 
einfinden und genau da sehe ich das problem ;-) bisher ist die resonanz 
zum wirklichen umsetzen/basteln gering..

> Sind ja auch keine Distanzsensoren, sondern IR-Photodioden. Diese als
> Touch-"Sensor" zu verwenden ist im Prinzip nur eine "kreative"
> Anwendung. Die mögliche Entfernung hängt von vielen Faktoren ab - unter
> anderem wie stark die IR-LED ist und wie stark das Glas reflektiert.
>
> Bin mit dem Ergebnis bei einem einzigen Pixel zufrieden. Werde sehen,
> dass ich das bis zum nächsten Wochenende zu einer 3x3 Konstruktion
> ausbaue und auch vernünftig per Mikrocontroller auswerte. Derzeit fehlen
> z.B. noch die RGB-LEDs, aber die sollten laut Datenblatt der
> IR-Photodiode kein allzugroßen Effekt haben. Komme dann hoffentlich auch
> dazu ein Demo-Video anzufertigen.

welche RGBs willst du benutzen?!

von Karol B. (johnpatcher)


Lesenswert?

Tim R. schrieb:
> das ist richtig. wie reagiert dein sensor bei verschiedenen
> umgebungshelligkeiten?

Umgebungslicht hat natürlich einen Einfluss, sofern man sich das am 
Oszilloskop ansieht. Hält sich aber in Grenzen und lässt sich Software 
eliminieren.

Tim R. schrieb:
> der is471 nutzt ja extra filter, was ich sehr gut
> fand

Der IS471 ist ja auch eine All-in-One Lösung, die vieles übernimmt, was 
bei uns der Mikrocontroller übernimmt.

Tim R. schrieb:
> könntest du mir näher erläutern was du mit basistransistor meinst?

Sorry, meinte natürlich Basis-Widerstand.

Tim R. schrieb:
> grundsätzlich ja! müssten sich nur zum gegebenen zeitpunkt genügend
> einfinden und genau da sehe ich das problem ;-) bisher ist die resonanz
> zum wirklichen umsetzen/basteln gering..

Mal sehen, sofern wir soweit kommen, finden sich bestimmt ein paar. Habe 
im Bekanntenkreis schon einige Interessanten. Also auf 1000+ sollten wir 
leicht und locker kommen, und da lässt sich in Bezug auf Preise und 
Assemblierung eventuell schon etwas machen.

Tim R. schrieb:
> welche RGBs willst du benutzen?!

Da habe ich mir noch nicht so besonders viele Gedanken gemacht. Für den 
Testaufbau ist das ja ziemlich egal. Nachher muss man sich das mal 
genauer ansehen. Die Frage ist, ob wir auf SMD LEDs setzen, oder auf 
klassische Steckbauteile. Die IR LED und Photodiode sind gibt es meines 
Wissens nach z.B. nur in einer 3mm Steckvariante, insofern kommen wir um 
ein wenig Handarbeit nicht herum.

Im Prinzip ist mir das aber egal. Ich hätte nur gern eine vernünftige 
Helligkeit, d.h. das es auch bei Tageslicht "sichtbar" ist (deswegen 
auch LED Treiber, weil die das einfacher machen). Auf Multiplexing & Co. 
würde ich daher gerne verzichten (wobei das mit unserer Modullösung 
nicht notwendig ist). Bei 5x5x3 sollte auch eine einzige LED ausreichen, 
bei größeren Pixeln könnten ggf. mehrere notwendig werden.

Mit freundlichen Grüßen,
Karol Babioch

von Conny G. (conny_g)


Lesenswert?

Conny G. schrieb:
> Markus M. schrieb:
>> Auch finde ich, sollte der ganze Aufbau möglichst flach realisiert
>> werden. Wer will schon einen Tisch, wo unter der Platte ein 20cm Kasten
>> ist o.ä.
>> Daraus folgt m.E. wir benötigen einen IR Phototransistor mit möglichst
>> großem Erfassungswinkel und möglichst selektivem Erfassungsbereich bzgl.
>> der Wellenlänge (ansonsten Beeinflussung durch die LEDs bzw. Fremdlicht)
>> und entsprechende IR LEDs (passende Wellenlänge zu dem IR
>> Phototransistor).
>
> Das mit dem breiten Erfassungswinkel ist der falsche Ansatz. Sonst kann
> man zwei Zellen nebeneinander nicht unterscheiden, wenn es keine scharfe
> Zellenabgrenzung gibt.
> Der Strahl muss aus jeder Zelle relativ steil herauskommen, dazu braucht
> es ein Stück Abstand von der Oberfläche.
> Kann man selber ausrechnen: bei ca. 7x7cm Zellengröße (60x60 Tisch als
> eine Größenoption mit 10x10 Zellen) und nur 90 Grad Abstrahlwinkel wird
> eine Hand bei einem Abstand von 5cm noch in der Mitte der Nachbarzelle
> erfasst - das nimmt dem Konzept jede "Schärfe" in der Erkennung.
> Wenn man steileren Winkel will, kommt man um eine gewisse Aufbauhöhe,
> wie 10cm, nicht herum (wenn man mit 1 IR-LED arbeiten will. Mir mehreren
> kann man auch welche mit schmalem Winkel nehmen oder sie in ein Röhrchen
> stecken. Aber mehrere ist m.E. bei 100 Zellen keine Optione).

Interessiert keinen? :-)

Das dürfte sich bemerkbar machen sobald man eine 3x3 Matrix versucht, 
dann wird es sich zeigen, dass der mittlere Pixel sehr schwierig alleine 
zu touchen ist, wenn der Abstrahl-/Erfassungwinkel zu breit ist.
Es dürfte dann so sein, dass bei Faust von oben, 5cm über der Fläche 
alle 9 Pixel ansprechen und das finde ich nicht so optimal.

von Conny G. (conny_g)


Lesenswert?

Karol Babioch schrieb:
> Tim R. schrieb:
>> das ist richtig. wie reagiert dein sensor bei verschiedenen
>> umgebungshelligkeiten?
>
> Umgebungslicht hat natürlich einen Einfluss, sofern man sich das am
> Oszilloskop ansieht. Hält sich aber in Grenzen und lässt sich Software
> eliminieren.

Misst Du schon gepulst, also wie die TSOP-IR-Empfänger?
Trägerfrequenz von 20/30 kHz abstrahlen und nur auf die reagieren?
Oder IR-Puls mit 10 kHz, Abtastung mit 20 kHz und je eine Messung mit 
"IR On" und eine Messung mit IR Off und dann Differenz als Maß?

von Conny G. (conny_g)


Lesenswert?

Tim R. schrieb:
>> Wir müssten uns einfach auf die Größe eines Pixels festlegen. Habe jetzt
>> zuletzt mit 5x5x3 cm gearbeitet, finde das fast ein wenig klein, bzw.
>> bin mir nicht sicher, ob wir die Elektronik + Steckverbindungen nachher
>> wirklich auf dieser Fläche unterbringen. Mehrere Sensoren machen bei
>> dieser Größe vermutlich auch gar keinen Sinn. Bei 10x10 hingegen sieht
>> das schon wieder anders aus.
>
> stimmt das könnte ein problem werden, bei einem 5x5 feld. evtl. doch ein
> 10x10cm feld?! so lässt sich mit einer 10er reihe auch ein tisch von
> einem meter länge gut erreichen :-) bei 5x5cm feldern müssten schon
> knapp 20 pixel in eine reihe (+overhead vom gerüst)
>

Ich fände einen 60x60 Couchtisch mit 10x10 Pixeln eine pragmatische 
Basis.
Dann ist jeder Pixel 6x6cm gross und man kann auch andere Tischgrößen 
fabrizieren, 120x60, 72x72, was auch immer.

Die Tiefe der Pixel würde ich 10cm machen um einen möglichst engen 
Messbereich eines Pixels zu haben.
Für eine schöne Ausleuchtung des 6x6 Vierecks braucht es auch mehr als 
3cm, würde sagen, dass dafür 5-6cm reichen könnten.
Aber der dominante Faktor für die Tiefe ist m.E. die Touch-Detektion.

von Conny G. (conny_g)



Lesenswert?

Conny G. schrieb:
> Die Tiefe der Pixel würde ich 10cm machen um einen möglichst engen
> Messbereich eines Pixels zu haben.
> Für eine schöne Ausleuchtung des 6x6 Vierecks braucht es auch mehr als
> 3cm, würde sagen, dass dafür 5-6cm reichen könnten.
> Aber der dominante Faktor für die Tiefe ist m.E. die Touch-Detektion.

Hier mal als quick & dirty Skizze, einmal 3cm Tiefe, einmal 10cm.

Man sieht, dass bei den 3cm Tiefe der Zellen ein Gegenstand von 4cm 
Durchmesser in einer Höhe von 5/6cm über dem Tisch von 3 Zellen 
nebeneinander voll erfasst wird.
Natürlich wird wg. des etwas längeren Weges von der Seite das Signal 
"links" und "recht" etwas schwächer sein - aber ich glaube nicht, dass 
man das unterscheiden kann, es wird stark genug sein.

Bei einer Tiefe von 10cm ergibt sich das Problem nicht, da der 
Messwinkel grundsätzlich viel schmaler ist.
Derselbe Gegenstand an derselben Position wird garantiert nicht erkannt.
So finde ich das optimal.

Nebenbei ist bei dieser 100mm-Tiefe-Konstellation die Fläche oben auch 
sicher optimal von der RGB-LED ausgeleuchtet.
Das wird bei den 30mm nicht so sein.
Und das ist nicht "gemeint" oder "geraten", sondern ich weiss es von 
LED-hinterleuchteten Panelen von 40x40cm, die ich vor ein paar Jahren 
mal gemacht habe.
Der Abstand der LEDs dahinter war ein paar cm, es brauchte einen Abstand 
von mindestens 6/7 cm um vorne beim gefärbten Plexi (pink) keine 
einzelnen LEDs mehr erkennen zu können.

Zur Illustration ein Foto der Panele: der Abstand zwischen vertikalen, 
nebeneinander angebrachten LED_Streifen zum Plexiglas ist 7cm, man sieht 
immer noch ein klein wenig die Kontouren der LED-Streifen dahinter.
Klar, dass das mit weniger Abstand weniger gut ausgeleuchtet wäre.

: Bearbeitet durch User
von Karol B. (johnpatcher)


Lesenswert?

Conny G. schrieb:
> Interessiert keinen? :-)
>
> Das dürfte sich bemerkbar machen sobald man eine 3x3 Matrix versucht,
> dann wird es sich zeigen, dass der mittlere Pixel sehr schwierig alleine
> zu touchen ist, wenn der Abstrahl-/Erfassungwinkel zu breit ist.

Mir ist natürlich vollkommen klar, was du meinst, bzw. das es rein 
geometrisch bedingt besser wäre die Konstruktion "tiefer" zu machen. 
Andererseits schaut halt "tiefer" unschöner aus ;).

Ich bin nach wie vor der Meinung, dass man diese Probleme aber mittels 
Software in den Griff bekommen kann. Die einzelnen Pixel sind ja nicht 
synchronisiert, d.h. der Puls kommt und die damit einhergehende Messung 
findet zu verschiedenen Zeit statt. Darüber hinaus könnte man z.B. auch 
über verschiedene Pulsfrequenzen für benachbarte Zellen nachdenken. 
Letztendlich könnte man die Geometrie sogar zu seinem Vorteil ausnutzen 
und die Empfindlichkeit erhöhen, indem man die Signale der benachbarten 
Zellen mit interpretiert. Das würde natürlich eine Kommunikation der 
einzelnen Pixel miteinander erfordern und dürfte auch algorithmisch 
nicht ganz einfach sein, ist aber auch nicht ausgeschlossen.

Letztendlich hilft hier nur ein Versuchsaufbau. Den werde ich in 
nächster Zeit anfertigen.

Conny G. schrieb:
> Nebenbei ist bei dieser 100mm-Tiefe-Konstellation die Fläche oben auch
> sicher optimal von der RGB-LED ausgeleuchtet.
> Das wird bei den 30mm nicht so sein.
> Und das ist nicht "gemeint" oder "geraten", sondern ich weiss es von
> LED-hinterleuchteten Panelen von 40x40cm, die ich vor ein paar Jahren
> mal gemacht habe.

Dem halte ich z.B. die gesammelten Erfahrungen mit der "Wordclock" 
entgegen. Hier beträgt der Abstand zwischen LED und "Anzeigefläche" etwa 
2 - 2,5 cm und die LEDs lassen sich nicht erkennen. Ist alles eine Frage 
des verwendeten Diffusors (bzw. in unserem Fall des verwendeten Glases). 
Auch hier geht versuchen über studieren. Bin derzeit auf der Suche nach 
günstigen Anbietern von satiniertem Glas, welches ich nachher auch in 
größerem Umfang erwerben kann. Bringt ja nichts, wenn ich das Ganze mit 
irgendwelchen Restbeständen zum Laufen bekomme, nachher aber vor dem 
Problem stehe, dass das entsprechende Glas nicht mehr aufzutreiben ist. 
Überhaupt ist das bisschen Glas für erste Tests teurer, als erwartet.

Hat hier irgendjemand Erfahrungen/Tipps? Wie stark soll das Glas sein? 
4mm scheint mir ein guter Kompromiss aus Stärke, Gewicht und Preis. Gibt 
es irgendwelche Einwände? Habe was Glas angeht sicherlich nicht die 
meiste Erfahrung, und einen Tisch habe ich auch noch nie gebaut ;). 
Letztendlich sollten wir ja alle den gleichen physikalischen Aufbau 
verwenden.

Mit freundlichen Grüßen,
Karol Babioch

von Karol B. (johnpatcher)


Lesenswert?

> Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig
> Software...

Noch etwas zum Protokoll: Zwei UARTs bieten AVRs i.d.R. nicht, d.h. 
Bit-Banging. Bin mir um ehrlich zu sein nicht sicher, ob das mit 
Soft-PWM + Protokoll + IR-Modulierung und Auswertung alles unter einen 
Hut zu bekommen ist.

Habe mir den Wiki-Artikel jetzt mal genauer angesehen bzw. mir Gedanken 
dazu gemacht, bin mir aber in Sachen "Rückrichtung" nicht sicher wie das 
zu verstehen ist. Was genau veranlasst die Slaves dazu ihre Sensordaten 
zurückzuschicken? Und macht es wirklich Sinn die RGB Daten auslesbar zu 
machen? Normalerweise sollten die ja im Puffer des "Masters" stehen und 
bei 25 Hz Refresh-Rate ist es doch eh recht uninteressant die Daten 
auszulesen, oder?

Ansonsten frage ich mich, ob es nicht "schöner" wäre das ganze doch als 
echten Bus auszulegen und die einzelnen Pixel adressierbar zu machen. 
Damit wäre (zumindest theoretisch) auch eine Kommunikation untereinander 
möglich. Klar, es würde Overhead bedeuten, andererseits müsste man nicht 
immer alle Daten ausgeben, sondern könnte einzelne Pixel gezielt setzen 
und auslesen. Ideal wäre natürlich Unterstützung in Hardware, aber bei 
I2C kommen wir von der Geschwindigkeit und der maximalen Anzahl von 
Teilnehmern in Bedrängnis. CAN ist wahrscheinlich zu teuer, und SPI 
skaliert bei der Anzahl an Teilnehmern nicht wirklich.

Im Endeffekt denke ich hier nur laut, und es ist auch schon spät, aber 
wäre es nicht möglich das Ganze in einem "Ring" aufzubauen? Die 
einzelnen Nodes sind per UART miteinander verbunden, der Master ist 
jeweils am "Schluss", in etwa so:

Master (TX) -> Node1(RX) -> Node1(TX) -> Node2(RX) -> Node2(TX) -> ... 
-> Master (RX)

Eine echte Kommunikation untereinander ist damit nicht effizient 
möglich, aber alles andere sollte sich vereinfachen:

- Eine UART Schnittstelle pro Teilnehmer, d.h. in Hardware
- Sowohl "empfangen" als auch "senden" sind aus Sicht des Masters 
möglich
- Logik eines Teilnehmers ist einfach: Alles empfangene "untersuchen" 
und weitergeben

Wie seht ihr das? Habe ich etwas übersehen? Wird das in dieser Form 
schon irgendwo verwendet, sodass man sich auf Erfahrungen anderer 
stützen könnte?

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Karol Babioch schrieb:
> Conny G. schrieb:
>> Interessiert keinen? :-)
>>
>> Das dürfte sich bemerkbar machen sobald man eine 3x3 Matrix versucht,
>> dann wird es sich zeigen, dass der mittlere Pixel sehr schwierig alleine
>> zu touchen ist, wenn der Abstrahl-/Erfassungwinkel zu breit ist.
>
> Mir ist natürlich vollkommen klar, was du meinst, bzw. das es rein
> geometrisch bedingt besser wäre die Konstruktion "tiefer" zu machen.
> Andererseits schaut halt "tiefer" unschöner aus ;).

Ich finde, das lässt sich im Design elegant machen.

> Ich bin nach wie vor der Meinung, dass man diese Probleme aber mittels
> Software in den Griff bekommen kann.

Das glaube ich nicht, wie soll das gehen?
In einer Zelle weiß ich ja nicht, ob die Reflexion vom Rand oder der 
Mitte kommt.
Ich könnte höchstens bei einem Signal, das ich in zwei Zellen (oder 
mehreren) empfange über die Intensität ermitteln welcher ich es zuordnen 
will. Das könnte ich aber nicht in den Zellen tun, sondern müsste es im 
Mastercontroller wie eine Kontrastverstarkung bei Pixeln rechnen.

> Die einzelnen Pixel sind ja nicht
> synchronisiert, d.h. der Puls kommt und die damit einhergehende Messung
> findet zu verschiedenen Zeit statt. Darüber hinaus könnte man z.B. auch
> über verschiedene Pulsfrequenzen für benachbarte Zellen nachdenken.

Das eliminiert aber nicht die Unschärfe durch zu großen 
Erfassungsbereich pro Zelle.

> Letztendlich könnte man die Geometrie sogar zu seinem Vorteil ausnutzen
> und die Empfindlichkeit erhöhen, indem man die Signale der benachbarten
> Zellen mit interpretiert. Das würde natürlich eine Kommunikation der
> einzelnen Pixel miteinander erfordern und dürfte auch algorithmisch
> nicht ganz einfach sein, ist aber auch nicht ausgeschlossen.

S.o., wenn man es im Master als Kontrastverstärkung macht gar nicht so 
kompliziert.

> Letztendlich hilft hier nur ein Versuchsaufbau. Den werde ich in
> nächster Zeit anfertigen.

Der beantwortet bestimmt diese Fragen am Besten.

> Conny G. schrieb:
>> Nebenbei ist bei dieser 100mm-Tiefe-Konstellation die Fläche oben auch
>> sicher optimal von der RGB-LED ausgeleuchtet.
>> Das wird bei den 30mm nicht so sein.
>> Und das ist nicht "gemeint" oder "geraten", sondern ich weiss es von
>> LED-hinterleuchteten Panelen von 40x40cm, die ich vor ein paar Jahren
>> mal gemacht habe.
>
> Dem halte ich z.B. die gesammelten Erfahrungen mit der "Wordclock"
> entgegen. Hier beträgt der Abstand zwischen LED und "Anzeigefläche" etwa
> 2 - 2,5 cm und die LEDs lassen sich nicht erkennen.

Kann ich nicht beurteilen.

> Ist alles eine Frage
> des verwendeten Diffusors (bzw. in unserem Fall des verwendeten Glases).

Es gibt 2 Faktoren, die die Optik bestimmen:
A) wie groß ist der Lichtkegel, der auf den Diffusor auftrifft.
B) wieviel verteilt der Diffusor das Licht in seinem Körper

Hier ist ein sehr wesentlicher Unterschied zwischen Plexiglas und 
Satiniertem Glas:
Plexiglas ist durch und durch milchig und verteilt deshalb das Licht 
sehr stark im Körper.
Bei Glas ist das nicht unbedingt so, wenn es nur auf der Oberfläche 
aufgeraut ist, dann sehe ich den Lichtkegel 1:1 so, wie er auftrifft.
Nur wenn es wirklich komplett durchgefärbt ist, verteilt es auch 
innerhalb des Glases.

Will sagen: der Abstand kann bei weißem Plexiglas etwas knapper sein als
oberflächlich Satiniertem Glas, weil es "aktiv" verteilt.
Bei Glas ist demnach wichtig, dass der Lichtkegel der LED das Glas 
vollflächig beleuchtet.

> Auch hier geht versuchen über studieren. Bin derzeit auf der Suche nach
> günstigen Anbietern von satiniertem Glas, welches ich nachher auch in
> größerem Umfang erwerben kann. Bringt ja nichts, wenn ich das Ganze mit
> irgendwelchen Restbeständen zum Laufen bekomme, nachher aber vor dem
> Problem stehe, dass das entsprechende Glas nicht mehr aufzutreiben ist.
> Überhaupt ist das bisschen Glas für erste Tests teurer, als erwartet.
>
> Hat hier irgendjemand Erfahrungen/Tipps? Wie stark soll das Glas sein?
> 4mm scheint mir ein guter Kompromiss aus Stärke, Gewicht und Preis. Gibt
> es irgendwelche Einwände? Habe was Glas angeht sicherlich nicht die
> meiste Erfahrung, und einen Tisch habe ich auch noch nie gebaut ;).
> Letztendlich sollten wir ja alle den gleichen physikalischen Aufbau
> verwenden.

Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch 
wichtig, denn die Platte muss alles aushalten, was da so drauf passiert. 
Etwas kräftiger abgestellte Maßkrüge, was weiß ich. (Bin in Bayern 
beheimated :-) ) Vielleicht geht ein bisschen weniger, wenn es ein 
kleiner Tisch (60x60) ist, aber weniger würde ich nicht machen wollen.
4mm ist eher Fensterglas und hält das m.E. nicht her.

>
> Mit freundlichen Grüßen,
> Karol Babioch

Lg,
Conny

: Bearbeitet durch User
von Conny G. (conny_g)


Lesenswert?

Karol Babioch schrieb:
>> Ich würde dabei bleiben. Es werden nur zwei UARTs benötigt, ein wenig
>> Software...
>
> Noch etwas zum Protokoll: Zwei UARTs bieten AVRs i.d.R. nicht, d.h.
> Bit-Banging. Bin mir um ehrlich zu sein nicht sicher, ob das mit
> Soft-PWM + Protokoll + IR-Modulierung und Auswertung alles unter einen
> Hut zu bekommen ist.
>
> Habe mir den Wiki-Artikel jetzt mal genauer angesehen bzw. mir Gedanken
> dazu gemacht, bin mir aber in Sachen "Rückrichtung" nicht sicher wie das
> zu verstehen ist. Was genau veranlasst die Slaves dazu ihre Sensordaten
> zurückzuschicken?

Das zurückschicken wird nicht veranlasst, sie werden wie bei SPI beim 
Senden gleichzeitig zurückgeschickt.

> Und macht es wirklich Sinn die RGB Daten auslesbar zu
> machen?

Die RGB-Daten werden nicht zurückgeschickt, nur die Touchdaten. Aber 
weil natürlich ebensoviele Bits zurück müssen als hin sind es je 24 Bit 
pro Node, auch wenn 8 Bit reichen würden.

>Normalerweise sollten die ja im Puffer des "Masters" stehen und
> bei 25 Hz Refresh-Rate ist es doch eh recht uninteressant die Daten
> auszulesen, oder?
>
> Ansonsten frage ich mich, ob es nicht "schöner" wäre das ganze doch als
> echten Bus auszulegen und die einzelnen Pixel adressierbar zu machen.

Schöner ja, aber deutlich aufwändiger. Und m.e. braucht man die 
individuelle Adressierung nicht, also dann lieber nur einen 3-Draht-Bus, 
dann ist die Verkabelung von 100 Nodes so einfach wie möglich.

> Damit wäre (zumindest theoretisch) auch eine Kommunikation untereinander
> möglich. Klar, es würde Overhead bedeuten, andererseits müsste man nicht
> immer alle Daten ausgeben, sondern könnte einzelne Pixel gezielt setzen
> und auslesen. Ideal wäre natürlich Unterstützung in Hardware, aber bei
> I2C kommen wir von der Geschwindigkeit und der maximalen Anzahl von
> Teilnehmern in Bedrängnis. CAN ist wahrscheinlich zu teuer, und SPI
> skaliert bei der Anzahl an Teilnehmern nicht wirklich.
>
> Im Endeffekt denke ich hier nur laut, und es ist auch schon spät, aber
> wäre es nicht möglich das Ganze in einem "Ring" aufzubauen? Die
> einzelnen Nodes sind per UART miteinander verbunden, der Master ist
> jeweils am "Schluss", in etwa so:
>
> Master (TX) -> Node1(RX) -> Node1(TX) -> Node2(RX) -> Node2(TX) -> ...
> -> Master (RX)

Wenn das wirklich klappt, könnte ich mir das auch vorstellen. Es hätte 
den Vorteil, dass es keine Leitung für einen Rückkanal braucht.
Ich hab allerdings mal versucht den Ring zu durchdenken und es sah so 
aus als hakt das. Jetzt gerade denke ich aber, es könnte gehen, saß da 
evtl dem falschen Modell auf. Gerade aber keinen frischen Kopf mehr das 
durchzudeklinieren.

> Eine echte Kommunikation untereinander ist damit nicht effizient
> möglich,

Untereinander halte ich für zu kompliziert und unnötig. Übergeordnete 
Entscheidungen, die über einen Node hinausgehen sollte der Master 
treffen.

> aber alles andere sollte sich vereinfachen:
>
> - Eine UART Schnittstelle pro Teilnehmer, d.h. in Hardware
> - Sowohl "empfangen" als auch "senden" sind aus Sicht des Masters
> möglich
> - Logik eines Teilnehmers ist einfach: Alles empfangene "untersuchen"
> und weitergeben
>
> Wie seht ihr das? Habe ich etwas übersehen? Wird das in dieser Form
> schon irgendwo verwendet, sodass man sich auf Erfahrungen anderer
> stützen könnte?
>
> Mit freundlichen Grüßen,
> Karol Babioch

von Karol B. (johnpatcher)


Lesenswert?

Conny G. schrieb:
> Ich finde, das lässt sich im Design elegant machen.

Das liegt dann wohl im Auge des Betrachters. Dünn ist aber deswegen 
besser, weil man damit auch "dicke" Tische bauen kann ;). Andersherum 
wird es schwieriger.

Conny G. schrieb:
>> Ich bin nach wie vor der Meinung, dass man diese Probleme aber mittels
>> Software in den Griff bekommen kann.
>
> Das glaube ich nicht, wie soll das gehen?

Ich dachte in erster Linie daran, dass die einzelnen Zellen zu 
verschiedenen Zeitpunkten ihre Messungen durchführen. Die Nachbarzelle 
kann ja nur erfasst werden, wenn sie auch aktiv ist. Die Idee ist die 
eigene IR-LED nur kurz zu aktivieren und dann die Messung vornehmen. Die 
einzelnen Zellen laufen ja nicht synchron. Hab das Timingtechnisch aber 
noch nicht durchgerechnet geschweige denn ausprobiert.

Conny G. schrieb:
> Will sagen: der Abstand kann bei weißem Plexiglas etwas knapper sein als
> oberflächlich Satiniertem Glas, weil es "aktiv" verteilt.

Ja, mit Glas hab ich in diesem Bereich keine Erfahrungen, bekomme ich ja 
dann bald zu sehen.

Conny G. schrieb:
> Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch
> wichtig, denn die Platte muss alles aushalten, was da so drauf passiert.

Sehe ich auch so, daher fragte ich ja. Wobei dicker natürlich in unserem 
Fall ungünstiger ist, weil mehr Reflexionen und weniger Durchlass ...

Was in unserem Fall ggf. dünneres Glas ermöglichen könnte ist die 
Unterteilung der Pixel. Wenn man das als tragende Konstruktion auslegt, 
dann muss die Glasplatte selbst nicht mehr soviel aushalten. Bin aber 
kein Ingenieur, diese Erkenntnis beruht also nur auf meinem laienhaften 
Physikverständnis.

Mit freundlichen Grüßen,
Karol Babioch

von Conny G. (conny_g)


Lesenswert?

Conny G. schrieb:
> Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch
> wichtig, denn die Platte muss alles aushalten, was da so drauf passiert.
> Etwas kräftiger abgestellte Maßkrüge, was weiß ich. (Bin in Bayern
> beheimated :-) ) Vielleicht geht ein bisschen weniger,

hier wollte ich eigentlich noch schreiben: "vielleicht 8mm"

> wenn es ein
> kleiner Tisch (60x60) ist, aber weniger würde ich nicht machen wollen.
> 4mm ist eher Fensterglas und hält das m.E. nicht her.

von Conny G. (conny_g)


Lesenswert?

Karol Babioch schrieb:
> Ich dachte in erster Linie daran, dass die einzelnen Zellen zu
> verschiedenen Zeitpunkten ihre Messungen durchführen. Die Nachbarzelle
> kann ja nur erfasst werden, wenn sie auch aktiv ist. Die Idee ist die
> eigene IR-LED nur kurz zu aktivieren und dann die Messung vornehmen. Die
> einzelnen Zellen laufen ja nicht synchron. Hab das Timingtechnisch aber
> noch nicht durchgerechnet geschweige denn ausprobiert.

Jetzt weiß ich wo wir uns missverstehen.
Ich meine nicht die Detektion des IR von Zelle links durch Zelle Mitte. 
Sondern, dass jedes "Auge", jede Zelle einen weiten Erfassungbereich hat 
und deshalb ein Gegenstand von mehr als einer Zelle gesehen wird, und 
zwar mit dem "eigenen" IR.
In dem von mir beschriebenen Szenario (Skizze Abstand 3cm) wird der 
Gegenstand über Zelle Mitte gleich von 9 Zellen gesehen und zwar mit dem 
eigenen IR. Und keine der Zellen kann unterscheiden, ob es Randbereich 
oder Mitte ist. Also ist schlicht die Erkennung "unscharf", aus einem 
"Pixel" werden 9.
Das Problem lässt sich also nicht durch andere Abtastfrequenz oder 
asynchrone Abtastung lösen, denn trotzdem würden Zelle links und rechts 
auch den Gegenstand sehen.

Lg,
Conny

: Bearbeitet durch User
von Karol B. (johnpatcher)


Lesenswert?

Conny G. schrieb:
> Wenn das wirklich klappt, könnte ich mir das auch vorstellen. Es hätte
> den Vorteil, dass es keine Leitung für einen Rückkanal braucht.
> Ich hab allerdings mal versucht den Ring zu durchdenken und es sah so
> aus als hakt das. Jetzt gerade denke ich aber, es könnte gehen, saß da
> evtl dem falschen Modell auf. Gerade aber keinen frischen Kopf mehr das
> durchzudeklinieren.

Mir scheint, dass auch fast zu einfach zu sein, aber ich habe bisher 
noch keinen Grund gefunden, warum das nicht funktionieren sollte. Würde 
vorschlagen, wir machen uns da beide nochmal Gedanken die nächsten Tage 
über ...

Interessant wäre allerdings was sich aus einem UART (ohne Quarz?) so 
herausholen lässt. Ich habe bei AVRs bisher nur mit maximal 9600 Baud 
gearbeitet, und selbst hier wird oft ein Quarz empfohlen. Der würde aber 
wiederum zwei Pins kosten :(. Gibt es hierzu bereits Erfahrungswerte?

Interessanterweise sagt das Datenblatt nämlich (ATmega168), dass bei 8 
MHz Oszillatorfrequenz und einem Wert von 1 im Baud Rate Register und 
U2X = 1 eine Übertragungsrate von 1 Mbps möglich ist (bei 0% relativem 
Fehler). Das sollte in unserem Fall ja ausreichend sein ;).

Conny G. schrieb:
> Untereinander halte ich für zu kompliziert und unnötig. Übergeordnete
> Entscheidungen, die über einen Node hinausgehen sollte der Master
> treffen.

Ok, das Modell können wir natürlich auch verfolgen. Macht wahrscheinlich 
sogar mehr Sinn, weil dadurch die Nodes einfacher/billiger sind und der 
Master sowieso genug Power hat. Habe hier wohl einen etwas zu komplexen 
Ansatz verfolgt. Ein Grund mehr für den oben vorgeschlagenen Ring ;).

Mit freundlichen Grüßen,
Karol Babioch

von Karol B. (johnpatcher)


Lesenswert?

Conny G. schrieb:
> Jetzt weiß ich wo wir uns missverstehen.

Ja, in der Tat. Deine Sorge der Erkennung über anderen Zellen hängt in 
erster Linie aber wiederum von der Höhe des Gegenstandes über der 
Glasplatte ab. Ich hätte schon gedacht, dass man die Glasplatte (nahezu) 
berühren soll, insofern sind die o.g. 60mm fast ein bisschen hoch (je 
nachdem wie dick die Hände natürlich sind ;)).

Mit freundlichen Grüßen,
Karol Babioch

von Conny G. (conny_g)


Lesenswert?

Karol Babioch schrieb:
> Conny G. schrieb:
>> Messe gerade mal meinen Wohnzimmertisch. 10mm. Das fände ich auch
>> wichtig, denn die Platte muss alles aushalten, was da so drauf passiert.
>
> Sehe ich auch so, daher fragte ich ja. Wobei dicker natürlich in unserem
> Fall ungünstiger ist, weil mehr Reflexionen und weniger Durchlass ...

Reflexion findet nur an den beiden Grenzflächen des Glases statt, also 
hat die Dicke darauf keinen Einfluss.
Beim Durchlass hängt es davon ab, ob es massiv durchgefärbtes Milchglas 
ist oder oberflächlich satiniertes Glas.
Das spielt dann auch mit der nachfolgende Sache zusammen:

> Was in unserem Fall ggf. dünneres Glas ermöglichen könnte ist die
> Unterteilung der Pixel. Wenn man das als tragende Konstruktion auslegt,
> dann muss die Glasplatte selbst nicht mehr soviel aushalten. Bin aber
> kein Ingenieur, diese Erkenntnis beruht also nur auf meinem laienhaften
> Physikverständnis.

Das stimmt, dass die Unterkonstruktion es möglich machen könnte, das 
Glas etwas dünner zu wählen.
Im Prinzip ist die Dicke des Glases nur dann entscheidend für den 
Gesamtaufbau, wenn es entscheidend für die Diffusion der RGB-LED ist.

Ich würde aber sowieso einen größeren Abstand (10cm) für wichtig 
ansehen.
In diesem Fall ist die Dicke des Glas irrelevant und man könnte zum 
Vorteil des Durchlasses ein einseitig unten oberflächlich satiniertes 
Glas verwenden.
Das hätte unten auch wenig Spiegelung, maximalen Durchlass, weil sonst 
reines Glas.

Ansonsten ist noch der Haptik-Faktor für manchen ein Kriterium - ich 
finde den Klang eines 10mm-Glastisches beim Abstellen eines Glases 
wesentlich angenehmer (dumpfes "Tong") als bei 4mm (helles "Pling") - 
schon deshalb wäre ich für ein 8-10mm Glas.

von Konrad S. (maybee)


Lesenswert?

Karol Babioch schrieb:
> Zwei UARTs bieten AVRs i.d.R. nicht

Gibt es durchaus. Bei den kleinen ist der ATtiny841 mit zwei UARTs 
interessant.

Conny G. schrieb:
> Ich meine nicht die Detektion des IR von Zelle links durch Zelle Mitte.
> Sondern, dass jedes "Auge", jede Zelle einen weiten Erfassungbereich hat
> und deshalb ein Gegenstand von mehr als einer Zelle gesehen wird, und
> zwar mit dem "eigenen" IR.

Legt man ein 3x3-Raster über den Tisch und prüft man in neun Zyklen in 
jedem Raster je ein Feld, dann hat man immer zwei inaktive Felder 
zwischen zwei aktiven Feldern. Da kann garnichts schiefgehen.

von Karol B. (johnpatcher)


Lesenswert?

Karol Babioch schrieb:
> Interessant wäre allerdings was sich aus einem UART (ohne Quarz?) so
> herausholen lässt. Ich habe bei AVRs bisher nur mit maximal 9600 Baud
> gearbeitet, und selbst hier wird oft ein Quarz empfohlen. Der würde aber
> wiederum zwei Pins kosten :(. Gibt es hierzu bereits Erfahrungswerte?

Übrigens: Die kleinen 8 Pin AVRs (bis einschließlich ATtiny85 bieten gar 
kein echtes UART Modul, sondern nur USI. Damit lassen sich laut App Note 
"AVR307: Half Duplex UART Using the USI Module" selbst bei 14.75MHz nur 
230.4 kbps erreichen.

Der nächstgrößere wäre dann der ATtiny841, der schon zwei UART Module 
bietet, dafür aber 14 Pins hat ....

Hat sich in dieser Beziehung schon jemand Gedanken gemacht? Das o.g. 
Beaglebone als Master halte ich z.B. für eine gute Lösung, aber bei den 
Nodes bin ich persönlich noch auf der Suche ...

Mit freundlichen Grüßen,
Karol Babioch

von Karol B. (johnpatcher)


Lesenswert?

Konrad S. schrieb:
> Legt man ein 3x3-Raster über den Tisch und prüft man in neun Zyklen in
> jedem Raster je ein Feld, dann hat man immer zwei inaktive Felder
> zwischen zwei aktiven Feldern. Da kann garnichts schiefgehen.

Doch, Conny G. hat schon recht. Rein geometrisch bedingt, kann auch 
etwas "neben" der eigentlichen Pixelfläche detektiert werden. Das wird 
umso besser, je höher der Unterbau ist. Andererseits kann es auch bei 
einem höheren Unterbau und ungünstigen Reflexionen an der Seitenwand zu 
einem solchen Effekt kommen.

Ideal wäre natürlich eine Laufzeiterkennung. Das wird aber bei 
Lichtgeschwindigkeit und unserem Ziel, die Module möglichst billig zu 
halten, schwierig ;).

Hier hilft nur eines: Ausprobieren und sehen wie empfindlich das Ganze 
letztendlich reagiert. Ich habe bei ersten Tests z.B. festgestellt, dass 
Haut gar nicht so gut reflektiert, insofern dürfte eine "seitlich" 
angestrahlte Hand weit weniger problematisch sein, als ein idealisierter 
Totalreflektor.

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Konrad S. (maybee)


Lesenswert?

Karol Babioch schrieb:
> Doch, Conny G. hat schon recht.

Nein. Beispiel:

  | A | B | C | D | E | F | G | H | I | J |
--+---+---+---+---+---+---+---+---+---+---+--
0 | a | b | c | a | b | c | a | b | c | a | 0
--+---+---+---+---+---+---+---+---+---+---+--
1 | d | e | f | d | e | f | d | e | f | d | 1
--+---+---+---+---+---+---+---+---+---+---+--
2 | g | h | i | g | h | i | g | h | i | g | 2
--+---+---+---+---+---+---+---+---+---+---+--
3 | a | b | c | a | b | c | a | b | c | a | 3
--+---+---+---+---+---+---+---+---+---+---+--
4 | d | e | f | d | e | f | d | e | f | d | 4
--+---+---+---+---+---+---+---+---+---+---+--
5 | g | h | i | g | h | i | g | h | i | g | 5
--+---+---+---+---+---+---+---+---+---+---+--
6 | a | b | c | a | b | c | a | b | c | a | 6
--+---+---+---+---+---+---+---+---+---+---+--
7 | d | e | f | d | e | f | d | e | f | d | 7
--+---+---+---+---+---+---+---+---+---+---+--
8 | g | h | i | g | h | i | g | h | i | g | 8
--+---+---+---+---+---+---+---+---+---+---+--
9 | a | b | c | a | b | c | a | b | c | a | 9
--+---+---+---+---+---+---+---+---+---+---+--
  | A | B | C | D | E | F | G | H | I | J |

Im Zyklus a sind die mit a markierten Felder aktiv. Ihre IR-LEDs senden 
und ihre IR-Sensoren messen. Die Felder b bis i sind inaktiv. Ihre 
IR-LEDs senden nicht und ihre IR-Sensoren messen nicht.

Danach folgt Zyklus b mit aktiven b-Feldern und inaktiven Feldern a und 
c bis i.

Entsprechend folgen die Zyklen c bis i.

Was soll da schiefgehen?

von asterix (Gast)


Lesenswert?

Hui, über Nacht ist hier ja einiges geschehen ! :-)

zum Glas:
Ich habe (wie oben gepostet) ein 4mm dickes Milch-Plexiglas mit 79% LD 
im 10x10cm Format günstig erworben. Link steht oben.
Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich 
zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen, 
sondern genau auf dem Tisch oder knapp darüber (maximal 2cm). Denn das 
ist für mich Touch. Oder nicht?!
Somit denke ich wären auch keine "großen" Tiefen nötig für den Unterbau.
Und wenn der Tisch stabilen Unterbau bekommt, kann das Glas auch etwas 
dünner werden :-)

Ich werde die Tage mal meinen Aufbau noch einmal rauskramen und das 
Touch-Verhalten genau untersuchen UND den Abstand für eine LED mir 
anschauen. Ich denke Conrad hat nicht ganz unrecht, dass die LEDs 
punktuell zu sehen sind, wenn man zu nah am Glas ist.
Diese Daten können dann zumindest als Referenz für ein 4mm Plexiglas 
dienen :-) Es kann ja gern mal jemand ein 8mm Glas testen

@Karol
Deine Idee zum 1x UART "Bus" finde ich gar nicht schlecht. Nur die Idee 
(wenn ich mich Recht entsinne) war die Überlegung zur Steigerung des 
Durchsatzes -> deswegen 2xUART. Müsste man mal durchrechnen, was bei der 
Ring Topologie an Daten durchrauschen könnte und ob das einer schönen 
Framerate (mindestens 30Hz) genügt.

@Konrad.S
Wie sollen die Zyklen denn bestimmt werden. Wann weiß ein Pixel, dass 
sein Messzyklus nun ansteht? Ich verstehe nicht ganz, wie das Timing an 
dieser Stelle zusammen kommen soll. Jedoch die Idee dahinter gefällt 
mir!


grüße

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Karol,

Karol Babioch schrieb:
> Was haltet ihr denn von dem Vorschlag mehrere IR-Dioden (zumindest
> Photodioden für den "Empfang") zu verwenden. Damit dürften sich nämlich
> Reflexionen aus anderen Zellen erkennen lassen, weil nicht alle
> "Empfänger" (gleich stark) angestrahlt werden. Die Frage ist nur wie
> viele vertretbar sind, wie viele Pins wir übrig haben und welche
> geometrische Anordnung sich hierfür anbietet?

Man könnte auch einen TSOPxxxx nehmen. Der hat zwar nur ein digitales 
Verhalten, aber man könnte trotzdem beim Boot eine Art "Kalibrierung" 
machen, indem man die Modulationsfrequenz der Sendediode derart in den 
Grenzbereich des TSOP fährt, dass er bei Milchglas ohne Gegenstand 
darüber gerade eben nichts mehr empfängt.

> Starke LEDs + kein Treiber ist ein wenig ein Widerspruch. AVRs sind
> i.d.R. für irgendwas zwischen 20 mA und 40 mA spezifiziert.

Es ist kein Problem, bei einem AVR (egal ob Tiny oder Mega), eine 
RGB-LED direkt über Vorwiderstände anzuschließen, siehe auch:

  Beitrag "Equinox-Uhr mit 60 ATtinys"

> Meistens
> schaffen sie nicht mal das, wenn mehrere Pins gleichzeitig beansprucht
> werden. In Software kann (je nach Taktfrequenz und je nachdem wie genau
> wir den Bus implementieren) eine 8-Bit PWM  schon eine Herausforderung
> werden.

Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von 
8Bit auf 16Bit aufbohre. Dadurch bekommt man wesentlich weichere 
Übergänge hin. Bei 8 Bit sind das eher Farbsprünge - gerade im unteren 
Bereich.

> Apropos flashen: Was ist aus der Bootloader Idee geworden?

Die obige Lösung benutzt einen 2-Draht-Bus, der mit SPI vergleichbar ist 
- implementiert in Software. Dieser ist skalierbar (d.h. nicht fix von 
der Anzahl der angeschlossenen AVRs) und ich kann sämtliche 
angeschlossenen µCs in einem Rutsch per Bootloader flashen. Bei einer 
max. Übertragungsrate von bis zu 100.000 Bits/sec ist das zu flashende 
Programm ruckzuck auf alle AVRs übertragen. Diesen Bus könnte man zur 
Befehlsübertragung nutzen. Ein ATmega als Steuereinheit könnte dann 
Farbprofile oder auch Animationen in den Client-AVRs aktivieren. Diesen 
ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum 
Beispiel die Farben zu wechseln o.ä.

Leider sind beim ATTiny85 bei Verwendung des Busses keine Pins mehr für 
IR-Sender/Empfänger mehr frei... denn eigentlich ist dieser µC sehr 
billig (bekommt man schon für 60-70ct) und hat auch jede Menge Speicher.

Okay, man könnte statt des 2-Draht-Busses auch nur einen Draht (und 
damit SW-Uart) verwenden - bei geringerer Übertragungsrate. Dann wäre 
ein weiterer Pin frei für den Sender. Wenn man dann noch den RESET-Pin 
als Datenpin verwendet, könnte man auch noch IR empfangen. Alternative 
zum ATtiny85 wäre ein ATtiny4313.... den ATtiny2313 mit seinen 2KB Flash 
finde ich zu winzig.

Gruß,

Frank

von Markus M. (adrock)


Lesenswert?

asterix schrieb:

> Ich habe (wie oben gepostet) ein 4mm dickes Milch-Plexiglas mit 79% LD
> im 10x10cm Format günstig erworben. Link steht oben.

Ja, wobei der Trend hier eher zum echten Glas mit 8-10mm geht. Das fänd' 
ich auch schicker. Wenn man schon einen 3-stelligen EUR-Betrag für die 
Elektronik ausgibt, soll das Ding ja auch vernünftig aussehen am Ende.

> Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich
> zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen,

Ja, das sehe ich auch so. Also mir würde eine Erkennung von Gegenständen 
direkt AUF der Platte (oder 5mm drüber von mir aus :-) völlig 
ausreichen.

> dienen :-) Es kann ja gern mal jemand ein 8mm Glas testen

Ja, wobei jetzt die Frage wäre mit wieviel Lichtdurchlässigkeit.

> @Konrad.S
> Wie sollen die Zyklen denn bestimmt werden. Wann weiß ein Pixel, dass
> sein Messzyklus nun ansteht? Ich verstehe nicht ganz, wie das Timing an
> dieser Stelle zusammen kommen soll. Jedoch die Idee dahinter gefällt
> mir!

Ja, ich fände eine einfache Daisy Chain mit evtl. synchronem Takt auch 
optimal. Wenn man gleichzeitig die Sensordaten zurückgibt wäre das 
perfekt. Habe da momentan noch einen kleinen Knoten im Hirn, aber ich 
denke es könnte funktionieren. Wichtig erscheint mir vorzusehen, dass 
alle Pixel/Nodes die erhaltenenen RGB-Daten zu einem gemeinsamen 
Zeitpunkt gleichzeitig übernehmen. Wenn man einen globalen Takt hat, 
könnte man dieses durch eine längere low oder high Phase signalisieren 
(so machen es die WS2811/WS2812).

Man müsste mal schauen, was die serielle Schnittstelle vom ATtiny 
hergibt. Bitbanging sollten wir vermeiden.

Grüße
Markus

von Ast E. (vis)


Lesenswert?

Die 4mm Plexiglas waren mein erster spontaner Testkauf. Ich kenn mich 
mit normalen Glas nicht aus. Gibts denn milchiges Glas, welches sich für 
unsere Zwecke eignet (bezahlbar)?! Ich dachte in der Richtung wird immer 
auf Plexi zurückgegriffen :-) Hat jemand mal einen Link?

ps:
@ Frank M.
schönes Projekt!

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tim R. schrieb:
> Die 4mm Plexiglas waren mein erster spontaner Testkauf. Ich kenn mich
> mit normalen Glas nicht aus. Gibts denn milchiges Glas, welches sich für
> unsere Zwecke eignet (bezahlbar)?! Ich dachte in der Richtung wird immer
> auf Plexi zurückgegriffen :-) Hat jemand mal einen Link?

Plexi verkratzt leicht. Ich will ja auch was draufstellen ;-)

Ich habe schon gedacht, diesen Tisch hier für so ein Projekt zu 
verwenden, den habe ich nämlich bereits:

  http://www.ikea.com/de/de/catalog/products/30157103/

Muss ich mal schauen, wie LEDs darunter aussehen...

> ps:
> @ Frank M.
> schönes Projekt!

Danke! :-)

von Conny G. (conny_g)


Lesenswert?

Markus M. schrieb:
 ausgibt, soll das Ding ja auch vernünftig aussehen am Ende.
>
>> Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich
>> zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen,
>
> Ja, das sehe ich auch so. Also mir würde eine Erkennung von Gegenständen
> direkt AUF der Platte (oder 5mm drüber von mir aus :-) völlig
> ausreichen.

Dann wäre wichtig, dass man mit der gefundenen Lösung beides kann. Ich 
möchte Annäherung mit analogem Wert der Messung können (ermöglicht auch 
eine globale Kalibrierurung beim Master) und auch bei 10cm was messen.
Und ich will Messschärfe / Bildschärfe per Geometrie (10cm Tiefe).

Rein geometrisch kann ein Pixelmodul ja beides, wenn der Abstrahlwinkel 
der IR LED breit genug jst.
Und der muss für wenig Höhe ja sowieso eher breit sein.
Das nutzt nur für mehr Höhe die IR Abstrahlleistung nicht optimal, weil 
50% der Leistung an die (schwarze) Seitenwand gehen.
Evtl kann man 2 Varianten von LEDs im Abstrahlwinkel finden das zu 
optimieren.

Ansonsten geht es nur um Kalibrierung, ob ich bei 10cm schon was Messe 
und analog Messe oder ob ich nur 5-10mm will und digital reagiere.

von Konrad S. (maybee)


Lesenswert?

Frank M. schrieb:
> Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von
> 8Bit auf 16Bit aufbohre.

> Leider sind beim ATTiny85 bei Verwendung des Busses keine Pins mehr für
> IR-Sender/Empfänger mehr frei... denn eigentlich ist dieser µC sehr
> billig (bekommt man schon für 60-70ct) und hat auch jede Menge Speicher.

Ich kann den ATtiny841 nur nochmal wärmstens empfehlen: vier 
16-Bit-Hardware-PWM und es ist immer noch ein 8-Bit-Timer übrig, zwei 
U(S)ARTs, 512 Bytes RAM. Netto-Preis bei DigiKey: 0.9748€ bei Hundert 
Stück, 0.86644€ bei Tausend Stück.
http://www.atmel.com/Images/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet.pdf

asterix schrieb:
> Wie sollen die Zyklen denn bestimmt werden. Wann weiß ein Pixel, dass
> sein Messzyklus nun ansteht? Ich verstehe nicht ganz, wie das Timing an
> dieser Stelle zusammen kommen soll.

Hängt davon ab, wie die Kommunikation aussieht.

Wenn genügend Pins da sind, dann könnte man ein diffenzielles Signal zur 
Synchronisation an alle µCs führen und mit dem Analog-Komparator 
auswerten. Finde ich aber verschwenderisch, zumal immer noch Leitungen 
für die Kommunikation notwendig sind.

Bei einem Bus kann darüber auch synchronisiert werden. Ich könnte mir 
RS-485 vorstellen, allerdings mit CAN-Treibern, z.B. MCP2562 oder 
TJA1051.

von Martin S. (led_martin)


Lesenswert?

Hallo allerseits,

auch wenn ich es nicht vorhabe einen solchen Tisch zu bauen, 
interessiert mich alles was mit LEDs zu tun hat sehr, und so lese ich 
hier mit. Deshalb möchte ich auch meine Gedanken zu dem Thema kundtun:

Bei den ganzen Überlegungen zum IR-Touch habt ihr eine wichtige 
Problematik bisher übersehen, ihr braucht für die Lichtverteilung 
satiniertes Glas, oder gar Milchglas, das streut auch das IR-Licht! Wer 
hat, nimmt mal eine Milschglasscheibe, schaut von der Seite drauf, von 
der die Beleuchtung kommt, und hält auf der anderen Seite die Hand 
davor, ist die Hand zu sehen? Bei satiniertem Glas vermutlich ja, wenn 
sie nahe gunug ist, bei Milchglas wohl eher nicht, vielleicht wenn die 
Hand direkt aufliegt. Mehr 'sieht' eine Photodiode auch nicht. Sprich, 
wenn es überhaupt geht, ist das Signal recht schwach. Habt ihr schon mal 
über kapazitiven Touch nachgedacht, dünnes, grobmaschiges Drahtnetz 
knapp unter der Glasfläche, so daß es keine störenden Schatten wirft. 
Auswertung lässt sich direkt mit Mikrocontroller-Pins und ein paar 
Widerständen machen (mal Googeln), dann stört auch die Nachbarzelle 
nicht mehr.

Die Idee mit dem UART-Ring ist sehr gut, und passt auch gut zu dieser 
Anwendung. Master schickt die RGB-Daten als Paket auf die Leitung, der 
Pixelcontroller nimmt sich den ersten RGB Wert weg, schickt den Rest 
weiter, und hängt hinten seine Sensordaten dran, danach dann eine Pause 
zur Synchronisation, so braucht es auch keine Adressierung der Pixel, 
und auch keinen 2. (Software-)UART. Wenn ihr UART verwenden wollt, 
solltet ihr unbedingt eien Quarz vorsehen, daß der interne Oszillator 
dafür zu ungenau ist, ist kein Gerücht. Da beim UART nur ein mal, an der 
vorderen Flanke des Startbits, synchronisiert wird, wirken sich 
Unterschiede im Takt vom Sender und Empfänger stark aus, auch wenn sich 
die gewünschte Baudrate, durch passende Teilereinstellung, genau treffen 
lässt.

Was die Bedenken wegen der Software-PWM anbelangt, da halte ich diese 
Anwendung eher für unproblematisch. Allerdings sind 8 Bit PWM zu wenig, 
im unteren Bereich ist das sehr stufig, und wenn dann noch eine 
allgemeine Dimmung für den Abend dazukommt wird es mit den Mischfarben 
schon schwierig. Und dann will man ja vielleicht noch Farbstiche der 
RGB-LEDs korrigieren. Da sollten es schon 10-12 Bit PWM-Auflösung sein, 
sollte hier aber gehen. Ich bin gerade an einem Hobby-Projekt, da 
steuert ein ATmega328 (Der große Bruder des ATmega168, vom Speicher her) 
18 RGB-LEDs, als 3x6 Matrix, also 1/6 Multiplex, 9 Software-PWM-Kanäle. 
Da erreiche ich 300 Hz 'Bildwiederholfrequenz' bei 10 Bit PWM-Auflösung. 
Und das bei Betrieb mit dem internen 8 MHz Oszillator. Da ich dort den 
UART nutze, gleiche ich den Oszillator über das OSCCAL-Register ab, habe 
am Timer 2 einen Uhrenquarz, und nutzte das als Zeitnormal, der Abgleich 
läuft immer mit, so daß auch Spannungs- und Temperaturänderungen erfasst 
werden.

Wenn ihr RGB-LEDs über Vorwiderstände und PWM betreibt denkt daran, daß 
sich die Farbe, bei Mischfarben, oder auch Weiß, abhängig von der 
Versorgungsspannung deutlich ändert. Bei meinem Aufbau, bei dem die 
Versorgungsspannung prinzipbedingt nicht konstant ist, habe ich diesen 
Effekt dadurch stark gemildert, daß ich zu den Rot-Chips eine normale 
SI-Diose (1N4148) in Reihe schalte, und dann den gleichen Vorwiderstand 
verwende wie für Grün und Blau. Da ändert sich die Farbe zwischen 4V und 
5V Versorgungsspannung nur noch minimal. Ihr habt ja prinzipbedingt 
lange Leitungen, und somit auch Spannungsabfall. Vielleicht sollte man 
auf jede Pixelplatine einen Spannungsregler setzten, reicht ja ein 
kleiner 'L' Typ. Wenn ihr die LEDs, so wie oben schon mal vorgeschlagen, 
über (MOS-)Transistoren ansteuert könnte man auch über eine höhere 
Versorgungsspannung für die LEDs nachdenken, und dann mehrere 6-Pin RGBs 
in Reihe schalten -> Viel mehr Licht, ohne hohe Stromstärken zu brauchen 
(Bei 100 - 200 Pixeln summieren sich auch mA zu beachtlichen Werten)

Wenn ihr den IR-Touch verwenden wollt, sollten die möglichst nicht 
gleichzeitig messen, wurde ja auch schon angesprochen, bei dem schwachen 
Signal ist die Verfälschung schnell ein Problem. Da könnte das 
weiterreichen der Daten, auf dem UART-Ring, gleich als Trigger 
herhalten: Gerade Daten bekommen -> Messung starten. So würden sie alle 
schön nacheinender messen. Beim Ring könnte der Zeitversatz zwischen 
erstem und letztem Pixel vielleicht auffallen, wenn sich die RGB-Werte 
plötzlich stark ändern, vielleicht sollte ein Pixel doch 'wissen' wo im 
Ring er sich befindet, und mit einer passenden Verzögerung bei der 
Ausgabe des RGB-Wertes kompensieren. Wenn sich jede Pixelplatine ihre 
RGB-Daten wegnimmt, ist die Position im Ring durch auszählen der 
verbleibenden Daten ermittelbar.

Mit freundlichem Gruß - Martin

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Konrad S. schrieb:
> Ich kann den ATtiny841 nur nochmal wärmstens empfehlen: vier
> 16-Bit-Hardware-PWM und es ist immer noch ein 8-Bit-Timer übrig, zwei
> U(S)ARTs, 512 Bytes RAM.

Ist wirklich ein geiles Teil. Besonders gefällt mir daran, dass man die 
Timer-Outputs auf fast beliebige Pins mappen kann. Zwei 16-Bit-Timer mit 
je zwei PWM-Kanälen sind natürlich auch klasse. Die Notwendigkeit für 2 
UARTs sehe ich zwar noch nicht, aber schaden kanns nicht.

: Bearbeitet durch Moderator
von Ast E. (vis)


Lesenswert?

japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter 
leicht zu machen ! :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Tim R. schrieb:
> japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter
> leicht zu machen ! :-)

Wäre mir auch lieber, leider gibt es den 841er nicht im DIP/DIL.

von Cyblord -. (cyblord)


Lesenswert?

Tim R. schrieb:
> japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter
> leicht zu machen ! :-)

Also SOIC Löten sollte ja wohl jeder hinbekommen.  Habt ihr wirklich 
vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen? Die 
macht man schon klein und kompakt in SMD und lässt sich die Platinen 
günstig aus Fernost zu 50 oder 100 Stück raus.

von Conny G. (conny_g)


Lesenswert?

cyblord ---- schrieb:
> Tim R. schrieb:
>> japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter
>> leicht zu machen ! :-)
>
> Also SOIC Löten sollte ja wohl jeder hinbekommen.  Habt ihr wirklich
> vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen? Die
> macht man schon klein und kompakt in SMD und lässt sich die Platinen
> günstig aus Fernost zu 50 oder 100 Stück raus.

So hätte ich mir das auch vorgestellt.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

cyblord ---- schrieb:
> Also SOIC Löten sollte ja wohl jeder hinbekommen.  Habt ihr wirklich
> vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen?

Die vielen natürlich nicht, aber das erste ;-)

von Ast E. (vis)


Lesenswert?

cyblord ---- schrieb:
> Tim R. schrieb:
>> japp sehr gut ausgestattet... ich dachte nur an DIP, um es jedem Löter
>> leicht zu machen ! :-)
>
> Also SOIC Löten sollte ja wohl jeder hinbekommen.  Habt ihr wirklich
> vor, diese vielen Module einzeln auf Lochraster mit Dips aufzubauen? Die
> macht man schon klein und kompakt in SMD und lässt sich die Platinen
> günstig aus Fernost zu 50 oder 100 Stück raus.

Also die ersten Testaufbauten wären mir als DIP lieber.
Die Endprodukte könnte man auch kleiner ausfallen lassen.

Ich kenne mich in den asiatischen Kreisen nicht aus ;-) Wie viel kostet 
denn so eine Chinaproduktion ca. 100 Leiterplatten? Un-/Bestückt?

von Horst (Gast)


Lesenswert?

Ich hatte welche bei Farnell bestellt. Günstiger als bei Digikey.
Leider als SOIC gerade nicht lieferbar...

VPE: 1 Stück
1+
0,785 €

10+
0,739 €

25+
0,694 €

50+
0,653 €

von makrolöter (Gast)


Lesenswert?

Tim R. schrieb:
> die ersten Testaufbauten wären mir als DIP lieber

Was spricht gegen einen Adapter von SOIC-14/16 nach DIP-14/16?
So teuer sind die auch wieder nicht.

von Cyblord -. (cyblord)


Lesenswert?

makrolöter schrieb:
> Was spricht gegen einen Adapter von SOIC-14/16 nach DIP-14/16?
Eben. Gar nichts. Im Gegenteil. Man muss keine 2 Gehäusetypen vorhalten, 
sondern kauft immer nur SOIC.

> So teuer sind die auch wieder nicht.

Ebay-Artikel Nr. 281161108586
Eher nicht so teuer ;-)


Leiterkarten kosten z.B. bei ITEAD (max. 5x5cm), 100 Stück = 75$.

Bestückt müsste man natürlich anfragen. Könnte sich bei 100+ Platinen 
aber schon lohnen. Selbst mit Stencil + Lötpaste + Reflowofen könnte das 
von Hand fertigen schon in Arbeit ausarten.

: Bearbeitet durch User
von ... (Gast)


Lesenswert?

beim ESC neulich war die komplette Bühne berührungsempfindlich und als 
LED Leinwand...

von Karol B. (johnpatcher)


Lesenswert?

Hi,

Konrad S. schrieb:
> Was soll da schiefgehen?

Nochmal: Es geht nicht um die Interaktion von verschiedenen Pixeln 
miteinander, sondern darum, dass ein Pixel auch Gegenstände über anderen 
Pixeln erfassen kann, wenn es sich in einer bestimmten Höhe über der 
Glasplatte befindet. Inwiefern das in der Praxis von Bedeutung ist, wird 
sich zeigen müssen. Immerhin ist eine Hand z.B. kein perfekter 
Retroreflektor.

asterix schrieb:
> Und ich bin der Meinung das 10cm tiefe zuviel sind. Zum einen möchte ich
> zum Beispiel auch keinen Gegenstand >5cm über dem Tisch erkennen,
> sondern genau auf dem Tisch oder knapp darüber (maximal 2cm). Denn das
> ist für mich Touch. Oder nicht?!

Das sehe ich auch so, beim Thema Material der Oberfläche bin ich aber 
definitiv für Glas. Klar kann man mit Plexiglas herum experimentieren, 
die Frage ist nur, inwiefern die Ergebnisse dann übertragbar sind. Die 
Dicke des Glases ist mir im Prinzip egal, stabil soll es halt sein ;).

asterix schrieb:
> @Karol
> Deine Idee zum 1x UART "Bus" finde ich gar nicht schlecht. Nur die Idee
> (wenn ich mich Recht entsinne) war die Überlegung zur Steigerung des
> Durchsatzes -> deswegen 2xUART. Müsste man mal durchrechnen, was bei der
> Ring Topologie an Daten durchrauschen könnte und ob das einer schönen
> Framerate (mindestens 30Hz) genügt.

Rein Datenratentechnisch haut das schon hin: 20 x 20 x 30 x 24 ~ 300 
kBit/s. Ein ATmega168 schafft bei 8 MHz laut Datenblatt bis zu 500 
kBit/s.
Außerdem habe ich weiter unten noch eine neue Idee ;).

Frank M. schrieb:
> Man könnte auch einen TSOPxxxx nehmen. Der hat zwar nur ein digitales
> Verhalten, aber man könnte trotzdem beim Boot eine Art "Kalibrierung"
> machen, indem man die Modulationsfrequenz der Sendediode derart in den
> Grenzbereich des TSOP fährt, dass er bei Milchglas ohne Gegenstand
> darüber gerade eben nichts mehr empfängt.

Mit einem TSOP hatte ich anfangs auch experimentiert, allerdings 
aufgrund seiner AGC schnell wieder verworfen. Das hat bei mir dermaßen 
schlecht funktioniert, dass ich SEHR skeptisch bin, ob das zu schaffen 
ist. Glaube ich erst, wenn ich es sehe ;).

Frank M. schrieb:
> Es ist kein Problem, bei einem AVR (egal ob Tiny oder Mega), eine
> RGB-LED direkt über Vorwiderstände anzuschließen, siehe auch:
>
>   Beitrag "Equinox-Uhr mit 60 ATtinys"

Interessantes Projekt. Würdest du die Helligkeit auch bei Tageslicht als 
akzeptabel beschreiben?

Frank M. schrieb:
> Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von
> 8Bit auf 16Bit aufbohre. Dadurch bekommt man wesentlich weichere
> Übergänge hin. Bei 8 Bit sind das eher Farbsprünge - gerade im unteren
> Bereich.

Details zu der "Aufbohrung" würden mich interessieren. Mit welchen 
Interrupts arbeitest du?

Frank M. schrieb:
> Dieser ist skalierbar (d.h. nicht fix von
> der Anzahl der angeschlossenen AVRs) und ich kann sämtliche
> angeschlossenen µCs in einem Rutsch per Bootloader flashen.

Wobei du in der Projektbeschreibung von maximal 239 Teilnehmern 
sprichst. In unserem Fall ist das zu wenig. Ich persönlich strebe jetzt 
einfach mal 20x20 = 400 an. Auch bin ich mir ziemlich sicher, dass wir 
bei einer "Daisy-Chain" mit der erforderten Taktrate in Probleme hinein 
laufen werden, wenn die Clockleitung 10+ Meter lang ist ;).

Frank M. schrieb:
> Bei einer
> max. Übertragungsrate von bis zu 100.000 Bits/sec ist das zu flashende
> Programm ruckzuck auf alle AVRs übertragen.

Auch 100 kBit/s ist in unserem Fall leider zu wenig :(. Siehst du denn 
eine Möglichkeit, dass zu "verbessern"?

Frank M. schrieb:
> Diesen
> ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum
> Beispiel die Farben zu wechseln o.ä.

Ich würde bei diesem Projekt gerne auf IR-Fernbedienungen verzichten. 
Halte ich nach wie vor für unzeitgemäß. Smartphones sei dank.

Tim R. schrieb:
> Ich dachte in der Richtung wird immer
> auf Plexi zurückgegriffen :-)

Ne, also ich kenne, um ehrlich zu sein kein einzigen Plexi-Glas Tisch. 
Ist, wie schon gesagt, zu kratzanfällig.

Conny G. schrieb:
> Dann wäre wichtig, dass man mit der gefundenen Lösung beides kann. Ich
> möchte Annäherung mit analogem Wert der Messung können (ermöglicht auch
> eine globale Kalibrierurung beim Master) und auch bei 10cm was messen.

Wobei das die Ansprüche an den Bus wieder erhöht, weil nicht nur ein/aus 
übertragen werden muss, sondern ein 8/9/10 Bit ADC Wert.

Konrad S. schrieb:
> Ich kann den ATtiny841 nur nochmal wärmstens empfehlen:

Bietet in der Tat ziemlich viel für ziemlich wenig Geld. Andererseits 
ist die Frage, ob wir wirklich 14 Pins brauchen ;).

Konrad S. schrieb:
> Bei einem Bus kann darüber auch synchronisiert werden. Ich könnte mir
> RS-485 vorstellen, allerdings mit CAN-Treibern, z.B. MCP2562 oder
> TJA1051.

Braucht alles Platz und kostet Geld. Macht sich bei der Anzahl an 
Teilnehmern dann doch bemerkbar.

Martin Schlüter schrieb:
> Sprich,
> wenn es überhaupt geht, ist das Signal recht schwach.

Dass es überhaupt geht haben ja andere schon bewiesen.

Martin Schlüter schrieb:
> Habt ihr schon mal
> über kapazitiven Touch nachgedacht, dünnes, grobmaschiges Drahtnetz
> knapp unter der Glasfläche, so daß es keine störenden Schatten wirft.

Wurde in anderen Threads auch schon durchgesprochen. Netze werfen 
Schatten. Alternativ wurde auch schon diskutiert etwas Metallisches 
aufzudampfen. Die Frage ist halt, inwiefern man da als Hobbybastler zu 
bezahlbaren Preisen herankommt. Außerdem werden die Touchflächen dann 
sicherlich auch nicht mehr so scharf sein.

Martin Schlüter schrieb:
> Wenn ihr RGB-LEDs über Vorwiderstände und PWM betreibt denkt daran, daß
> sich die Farbe, bei Mischfarben, oder auch Weiß, abhängig von der
> Versorgungsspannung deutlich ändert.

Auch deswegen bin ich für LED-Treiber.

Martin Schlüter schrieb:
> Wenn ihr UART verwenden wollt,
> solltet ihr unbedingt eien Quarz vorsehen, daß der interne Oszillator
> dafür zu ungenau ist, ist kein Gerücht.

Kostet halt wieder Platz, Geld und zwei Pins.

Frank M. schrieb:
> Die Notwendigkeit für 2
> UARTs sehe ich zwar noch nicht, aber schaden kanns nicht.

Hier mein Vorschlag: Zwei gegenläufige UART-Ringe. Halbiert die 
Verzögerung bis der letzte was mitbekommen hat, und verdoppelt den 
Durchsatz. Die Hardware stände uns bei diesem Mikrocontroller ja zur 
Verfügung ;).

Frank M. schrieb:
> Wäre mir auch lieber, leider gibt es den 841er nicht im DIP/DIL.

Sehe ich nicht als Problem. Zum Einen lässt sich das nach wie vor per 
Hand löten (wenn man nicht gerade zwei linke Hände hat, oder 
eingeschränkt sieht), und zum andern wäre eine Assemblierung auch 
denkbar.

Mit freundlichen Grüßen,
Karol Babioch

von Karol B. (johnpatcher)


Lesenswert?

Einziges Problem was ich noch sehe ist in der Tat die Signalisierung, 
wann die Daten übernommen bzw. angezeigt werden sollen. Der Bus arbeitet 
ja zeitlich indeterministisch, weil jeder Teilnehmer empfangen und 
senden muss und das je nach aktuellem Zustand kürzer oder länger dauern 
kann. Eine dedizierte Leitung hingegen ist auch nicht so besonders 
attraktiv und wird bei der Leitungslänge eventuell auch eine 
Herausforderung? Verzichtet man darauf, dann kann es zu Tearing-Effekten 
kommen, das ist auch unschön.

Vorschläge ;)?

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Ast E. (vis)


Lesenswert?

Um einen Quartz (falls UART benutzt werden soll), kommen wir denke ich 
gar nicht herum. Denn die Kommunikation ist eines der Herzstücke am 
Tisch, die muss reibungslos laufen. Dann verzichte ich aus kostengründen 
lieber auf einen LED-Treiber und nutze die 3 PWM Kanäle vom Tiny :-)


Karol Babioch schrieb:

> Das sehe ich auch so, beim Thema Material der Oberfläche bin ich aber
> definitiv für Glas. Klar kann man mit Plexiglas herum experimentieren,
> die Frage ist nur, inwiefern die Ergebnisse dann übertragbar sind. Die
> Dicke des Glases ist mir im Prinzip egal, stabil soll es halt sein ;).

Wie gesagt, hat denn jemand mal einen Link? Ich habe bisher nur Gläser 
gefunden die maximal 30% Lichtdurchlässigkeit bieten. Um aber die LEDs 
auch schön zu sehen bräuchten wir etwas mehr oder ?!

von Karol B. (johnpatcher)


Lesenswert?

Tim R. schrieb:
> Wie gesagt, hat denn jemand mal einen Link? Ich habe bisher nur Gläser
> gefunden die maximal 30% Lichtdurchlässigkeit bieten. Um aber die LEDs
> auch schön zu sehen bräuchten wir etwas mehr oder ?!

Für Muster habe ich mich bisher größtenteils auf eBay umgeschaut. Da 
gibt es auch 80% Lichtdurchlässigkeit, siehe z.B. [1]. Ist halt alles 
nicht ganz billig und ich würde gerne die Gewissheit haben, dass ich 
nachher auch im großen Stile an die selbe Ware komme. Sonst sind jetzt 
getroffene Designentscheidungen nachher für die Tonne.

Mit freundlichen Grüßen,
Karol Babioch

[1]: 
http://stores.ebay.de/glasereikern/Satiniertes-Glas-/_i.html?_fsub=2425365017&_sid=1041773537&_trksid=p4634.c0.m322

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Karol Babioch schrieb:
> Mit einem TSOP hatte ich anfangs auch experimentiert, allerdings
> aufgrund seiner AGC schnell wieder verworfen. Das hat bei mir dermaßen
> schlecht funktioniert, dass ich SEHR skeptisch bin, ob das zu schaffen
> ist. Glaube ich erst, wenn ich es sehe ;).

Vielleicht komme ich am nächsten Wochenende mal dazu, es auszuprobieren.

> Interessantes Projekt. Würdest du die Helligkeit auch bei Tageslicht als
> akzeptabel beschreiben?

Du kennst die LEDs (RGB, PLCC6) doch schon vom WordClock-Projekt. Mir 
würde die Helligkeit reichen.

> Frank M. schrieb:
>> Ich benutze im obigen Projekt 3 Hardware-PWMs, die ich softwaremäßig von
>> 8Bit auf 16Bit aufbohre. Dadurch bekommt man wesentlich weichere
>> Übergänge hin. Bei 8 Bit sind das eher Farbsprünge - gerade im unteren
>> Bereich.
>
> Details zu der "Aufbohrung" würden mich interessieren. Mit welchen
> Interrupts arbeitest du?

Ich hatte es falsch in Erinnerung, ich bohre die 8-Bit-HW-PWM mittels 
TIMER1_OVF_vect lediglich auf 12 Bit auf. Damit hat man dann aber auch 
schon 4096 Stufen statt nur 256. Auch bei kleineren Helligkeiten kann 
man dann keine Stufen mehr erkennen. Wenn wir uns für den ATtiny841 
entscheiden, spielt das aber keine Rolle mehr. Dann haben wir bereits 
hardwaremäßig 4 16-Bit-PWMs. Das reicht für RGB allemal.

> Frank M. schrieb:
>> Dieser ist skalierbar (d.h. nicht fix von
>> der Anzahl der angeschlossenen AVRs) und ich kann sämtliche
>> angeschlossenen µCs in einem Rutsch per Bootloader flashen.
>
> Wobei du in der Projektbeschreibung von maximal 239 Teilnehmern
> sprichst. In unserem Fall ist das zu wenig. Ich persönlich strebe jetzt
> einfach mal 20x20 = 400 an. Auch bin ich mir ziemlich sicher, dass wir
> bei einer "Daisy-Chain" mit der erforderten Taktrate in Probleme hinein
> laufen werden, wenn die Clockleitung 10+ Meter lang ist ;).

Die 239 sind dem Protokoll geschuldet, weil die Block-Start-Adresse ein 
Byte lang ist. Nimmt man 2 Bytes für Start- und Länge (falls man die 
überhaupt braucht, wenn man alle erreichen will), kommt man auf bis zu 
60.000 Busteilnehmer. Dann reichen aber sowieso keine 2 Drähte mehr ;-)

> Frank M. schrieb:
>> Bei einer
>> max. Übertragungsrate von bis zu 100.000 Bits/sec ist das zu flashende
>> Programm ruckzuck auf alle AVRs übertragen.
>
> Auch 100 kBit/s ist in unserem Fall leider zu wenig :(. Siehst du denn
> eine Möglichkeit, dass zu "verbessern"?

Nein, mehr ist nicht drin per Bitbanging. Dann doch lieber den 
einen/zwei HW-UART(s) eines ATtiny841.

Ich muss da irgendwo was überlesen haben... kannst Du mir mit einem Link 
oder einer kurzen Beschreibung mal auf die Sprünge helfen? Was für Daten 
sollen da denn überhaupt zwischen den ATtinys übertragen werden?

> Frank M. schrieb:
>> Diesen
>> ATmega könnte man dann auch per IR-Fernbedienung fernsteuern - um zum
>> Beispiel die Farben zu wechseln o.ä.
>
> Ich würde bei diesem Projekt gerne auf IR-Fernbedienungen verzichten.
> Halte ich nach wie vor für unzeitgemäß. Smartphones sei dank.

Gerne! Warum nicht? Ich habe mir letztens ein sehr interessantes 
WLAN-Modul bei Watterott geholt... klingt sehr vielversprechend (und 
wartet auf den ersten Test mit IRMP ;-) ).

: Bearbeitet durch Moderator
von Karol B. (johnpatcher)


Lesenswert?

Frank M. schrieb:
> Vielleicht komme ich am nächsten Wochenende mal dazu, es auszuprobieren.

Lass mich gerne überraschen ;). Unabhängig davon ist ein TSOP aber 
trotzdem fast 4x teurer als eine einzelne IR-Photodiode.

Frank M. schrieb:
> Du kennst die LEDs (RGB, PLCC6) doch schon vom WordClock-Projekt. Mir
> würde die Helligkeit reichen.

Die LEDs sind auch nicht unbedingt das Problem, sondern wie viel Strom 
man da durch jagt ;). Keine Ahnung, ob der Mikrocontroller selbst stark 
genug ist (scheinbar aber schon). Außerdem braucht es selbst bei einer 
Hardware PWM 3 Pins + 2 Timer. Ein dedizierter LED Treiber (habe z.B. 
gerade das Datenblatt des CAT4003B offen) kommt mit einer Leitung aus 
und benötigt keine externen Widerstände. Bessere Treiber können auch 
eine Dot-Korrektur vornehmen, um Unterschiede in den LEDs auszugleichen. 
Klar, bei einer 16 Bit PWM kann man das auch in Software machen, aber so 
erspart man sich eine Menge Arbeit.

Frank M. schrieb:
> Ich hatte es falsch in Erinnerung, ich bohre die 8-Bit-HW-PWM mittels
> TIMER1_OVF_vect lediglich auf 12 Bit auf. Damit hat man dann aber auch
> schon 4096 Stufen statt nur 256. Auch bei kleineren Helligkeiten kann
> man dann keine Stufen mehr erkennen. Wenn wir uns für den ATtiny841
> entscheiden, spielt das aber keine Rolle mehr. Dann haben wir bereits
> hardwaremäßig 4 16-Bit-PWMs. Das reicht für RGB allemal.

Ja, 12-Bit sollten auch reichen. Sofern wir uns für den ATtiny841 
entscheiden, ist das aber alles kein Problem mehr. Andererseits kann der 
Ansatz Widerstände zur Strombegrenzung zu verwenden schon zum Problem 
werden, weil ggf. kleine Spannungsschwankungen große Farbveränderungen 
bedeuten können, siehe oben.

Frank M. schrieb:
> Ich muss da irgendwo was überlesen haben... kannst Du mir mit einem Link
> oder einer kurzen Beschreibung mal auf die Sprünge helfen? Was für Daten
> sollen da denn überhaupt zwischen den ATtinys übertragen werden?

Im Prinzip gibt es zwei Richtungen. Aus Sicht des "Masters" sieht es so 
aus:

- Ausgabe: RGB-Daten für jeden einzelnen Pixel, also mindestens 24 Bit, 
maximale Anzahl der Pixel ist noch nicht wirklich festgelegt, ich 
persönlich hätte gerne 20x20
- Eingabe: Status des Touch-Sensoren. Wenn wir es einfach halten wollen, 
dann 1 Bit (an/aus), oben wurde aber auch vorgeschlagen eine analoge 
Auswertung im Master zu ermöglichen, um dann Kontrastanalysen und 
ähnliches zu machen. Dann braucht es je nach ADC-Modus und Genauigkeit 
schon 8/9/10 Bit.

Das Ganze natürlich für jeden Pixel und mit einer Refresh-Rate von 25 - 
30 Hz. Optional wäre es schön, wenn das Protokoll noch Möglichkeiten zum 
Flashen einzelner Teilnehmer vorsehen würde. Kalibrierungen wären, je 
nachdem welchen Weg wir wählen, auch denkbar/sinnvoll, wobei das alles 
natürlich nicht regelmäßig stattfinden muss.

Mit dem ATtiny841 hab ich mich mittlerweile angefreundet, weil der eben 
zwei UART Module anbietet, wodurch wir zwei gegenläufige UART Ringe 
aufspannen könnten. Wenn wir jedem Datensatz noch eine "Framenummer" 
voranstellen, dann kann auch jeder Teilnehmer feststellen, ob er das 
Paket schon gesehen hat, und es in diesem Fall nicht mehr weiterleiten. 
Das entlastet den "Bus". Wie siehst du das? Möglich? Sinnvoll? Oder hab 
ich etwas übersehen?

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Ast E. (vis)


Lesenswert?

Karol Babioch schrieb:
> [1]:
> 
http://stores.ebay.de/glasereikern/Satiniertes-Glas-/_i.html?_fsub=2425365017&_sid=1041773537&_trksid=p4634.c0.m322

puh, zumindest bei diesem Anbieter sind 0,6m² (maximal) bei 8mm Dicke 
schon knapp 70 Teuros. Und 20x30cm oder 10x60cm ist etwas knapp für die 
meisten oder ? ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Karol Babioch schrieb:

> Die LEDs sind auch nicht unbedingt das Problem, sondern wie viel Strom
> man da durch jagt ;). Keine Ahnung, ob der Mikrocontroller selbst stark
> genug ist (scheinbar aber schon).

Ja, der Strom (max. 20mA pro Pin) ist kein Problem.

> Andererseits kann der
> Ansatz Widerstände zur Strombegrenzung zu verwenden schon zum Problem
> werden, weil ggf. kleine Spannungsschwankungen große Farbveränderungen
> bedeuten können, siehe oben.

Wo sollen diese "Spannungsschwankungen" herkommen? Bei 60 ATtinys 
hintereinander konnte ich diese nicht beobachten, schon gar nicht als 
Farbveränderungen.

> Im Prinzip gibt es zwei Richtungen. Aus Sicht des "Masters" sieht es so
> aus:
>
> - Ausgabe: RGB-Daten für jeden einzelnen Pixel, also mindestens 24 Bit
> - Eingabe: Status des Touch-Sensoren. Wenn wir es einfach halten wollen,
> dann 1 Bit (an/aus), oben wurde aber auch vorgeschlagen eine analoge
> Auswertung im Master zu ermöglichen, um dann Kontrastanalysen und
> ähnliches zu machen. Dann braucht es je nach ADC-Modus und Genauigkeit
> schon 8/9/10 Bit.

Warum muss der Master den Status jeden einzelnen Touch-Sensors wissen? 
Das kann doch jeder ATTiny-Slave selbst entscheiden, was er dann 
macht.... zum Beispiel seine LED hochfaden.

Ich sehe eher die Aufgabe eines Masters darin, den anderen ab und zu mal 
mitzuteilen, was die Slaves machen sollen, wenn der Touch-Sensor mal 
ansprechen sollte - also eine Art "Verhaltensprogramm".

Was ich mir auch vorstellen kann: Eine "Vernetzung" der Slaves 
untereinander mit jeweils dessen Nachbarn, also 4 Drähte zu jeweils dem 
Slave links, rechts, oben, unten. So können sie dann dem Nachbarn durch 
Ziehen der Strippe (standrdmäßig HIGH über Pullup) auf GND mitteilen, 
wenn ihr Touch-Sensor angesprochen hat. Dadurch können die Nachbarn ihre 
LEDs auch mal kurz ansprechen.... Wenn sie dies auch wieder den Nachbarn 
mitteilen, könnte man so ganze "Wellen" durch den Tisch laufen lassen, 
wenn jemand ein Glas abstellt.

Meiner Meinung reicht Ein-/Aus auch als Touch-Sensor aus.

: Bearbeitet durch Moderator
von Karol B. (johnpatcher)


Lesenswert?

Tim R. schrieb:
> puh, zumindest bei diesem Anbieter sind 0,6m² (maximal) bei 8mm Dicke
> schon knapp 70 Teuros. Und 20x30cm oder 10x60cm ist etwas knapp für die
> meisten oder ? ;-)

Ja, das geht ins Geld. Werde am Wochenende vielleicht doch nochmal 
lokale Glasereien abklappern, und nach Mustern/Abfällen fragen. Wobei 
sich auch hier das Problem der Wiederbeschaffung stellt ...

Karol Babioch schrieb:
> Mit dem ATtiny841 hab ich mich mittlerweile angefreundet,

Übrigens ist das doch nicht so einfach wie gedacht. Der ATtiny841 wird 
derzeit nicht wirklich gut unterstützt. Weder avr-gcc noch avrdude 
unterstützen ihn von Haus aus. Auch beim offiziellen Atmel Studio 
braucht es wohl irgendwelche Zusatz-Pakete. In Deutschland ist es auch 
gar nicht so einfach da heranzukommen. Das macht das Ganze wieder 
unattraktiv(er) :(.

Frank M. schrieb:
> Wo sollen diese "Spannungsschwankungen" herkommen? Bei 60 ATtinys
> hintereinander konnte ich diese nicht beobachten, schon gar nicht als
> Farbveränderungen.

Die Leitungen werden je nach Ausführung halt schon ziemlich lang. Und 
das Netzteil hat auch ordentlich zu tun mit dem Regulieren, wenn da 400 
RGB LEDs (= 1200 LEDs) munter an- und ausgeschaltet werden ...

Frank M. schrieb:
> Warum muss der Master den Status jeden einzelnen Touch-Sensors wissen?

Die Idee war halt, dass man im Master sich dann die Kontraste genauer 
ansehen kann, um so auch Gegenstände über der Glasplatte zu erkennen.

> Das kann doch jeder ATTiny-Slave selbst entscheiden, was er dann
> macht.... zum Beispiel seine LED hochfaden.

Ne, wirklich entscheiden sollen die Slaves nichts selber. Der Master 
soll denen schon vorschreiben was zu tun ist, wie willst du sonst 
"Spiele" und andere Formen der Interaktionen implementieren? Es kann 
z.B. durchaus sinnvoll sein gewisse Felder zu deaktivieren, egal, ob 
sich darauf nun eine Hand befindet, oder nicht. Schau dir vielleicht 
einfach mal die o.g. Videos an.

Frank M. schrieb:
> Eine "Vernetzung" der Slaves
> untereinander mit jeweils dessen Nachbarn, also 4 Drähte zu jeweils dem
> Slave links, rechts, oben, unten.

Etwas ähnliches hatte ich oben vorgeschlagen. Bei meinem aktuellen 
Vorschlag zwei UART Ringe zu verwenden wäre das auch halbwegs effizient 
möglich ohne extra Strippen. Andererseits macht eine Auswertung im 
Master schon Sinn. Der hat mehr Power und weiß, ob eine solche 
Auswertung im aktuellen Kontext überhaupt Sinn macht.

Frank M. schrieb:
> Meiner Meinung reicht Ein-/Aus auch als Touch-Sensor aus.

Allein schon zur Kalibrierungszwecken könnte es Sinn machen die 
gemessenen Analogwerte bekannt zu machen. Ich habe z.B. bei den 
IR-Photodioden gemerkt, dass die sich zum Teil schon ein wenig anders 
verhalten. Rein von der benötigten Datenübertragungsrate macht das den 
Braten auch nicht mehr fett, und sollte bei zwei Ringen mit jeweils 500 
kBit/s kein Problem sein. Was der Master dann damit anfängt bleibt ihm 
überlassen ;).

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Karol Babioch schrieb:

> Übrigens ist das doch nicht so einfach wie gedacht. Der ATtiny841 wird
> derzeit nicht wirklich gut unterstützt. Weder avr-gcc noch avrdude
> unterstützen ihn von Haus aus. Auch beim offiziellen Atmel Studio
> braucht es wohl irgendwelche Pakete. In Deutschland ist es auch gar
> nicht so einfach da heranzukommen. Das macht das Ganze wieder
> unattraktiv(er) :(.

Das stimmt so nicht. avr-gcc unterstüzt den 841 in der aktuellen 
Version.
Atmel Studio benötigt ein Update-Paket, aber danach gibts keine 
Probleme.
Für avrdude muss man den 841 noch in der conf datei eintragen. Haben 
hier schon einige gemacht. Ich selbst auch. Die conf gibts hier auch 
irgendwo in einem thread. Das ist kein Problem.
Digikey liefert den 841 ab 1 Stück nach D auch für privat.

Habe jetzt schon einige Projekte damit realisiert. Obwohl ich nichtmal 
das Studio verwende, sondern Eclipse mit AVR-Plugin, und ich das Plugin 
auch noch an den 841 anpassen musste. Geht absolut problemlos und in den 
nächsten Versionen wird das wohl alles schon drin sein. So ist das halt 
bei neuen Bausteinen.

gruß cyblord

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.