Datenübertragung Smartphone->Mikrocontroller per Display;Helligkeit möglichst einfach/billig messen?

[Joachim S. (oyo)]

Mir kam die Tage die Idee, geringe Datenmengen per Smartphone-Display 
von einem Smartphone zu einem Mikrocontroller übertragen. Konkret: 
WLAN-Zugangsdaten von einem Smartphone an einen ESP-Mikrocontroller zu 
übertragen, indem man den Smartphone-Bildschirm direkt vor einen mit dem 
µc verbundenen Helligkeitssensor hält, das Smartphone-Display zur 
Datenübertragung schnell blinkt, und der Mikrocontroller aus den 
gemessenen Helligkeitswerten die zu übertragenden Daten dekodiert.

Hier mal meine Wünsche:
1. Damit die prinzipbedingt eher langsame Datenübertragung nicht unnötig 
lange dauert, wäre es schön, mindestens 30 Bilder/Helligkeitswerte pro 
Sekunde auswerten zu können.
2. Pro Bild möchte ich ausserdem mindestens 4 Helligkeitsstufen bzw. 2 
Bit unterscheiden können (in der Hoffnung, das eine Bit dann als 
Clock-Signal verwenden zu können)
2. Da das Übertragen der WLAN-Zugangsdaten ja normalerweise ein 
einmaliger Vorgang ist, und das Ganze jetzt eher ein witziges kleines 
Zusatzfeature sein soll, hoffe ich dass es da eine möglichst günstige 
und einfache (im Sinne von: möglichst wenig günstige Bauteile und 
benötigte IO/ADC-Pins etc.) Lösung gibt.
3. Ich würde bevorzugen, wenn der Helligkeitssensor in SMD-Bauform wäre.

Diesen Artikel hier:
https://www.mikrocontroller.net/articles/Lichtsensor_/_Helligkeitssensor
habe ich bereits gefunden - bin aber unsicher, was da jetzt die beste 
Möglichkeit wäre.
Photowiderstände bekommt man schon extrem günstig, für unter 3 Cent das 
Stück. Allerdings sind die fast immer bedrahtet, ausserdem ja offenbar 
viel zu lahm etc.

Geradezu genial und ideal erschien mir die in oben genanntem Artikel 
erwähnte Möglichkeit, gewöhnliche LEDs als Helligkeitssensor zu 
missbrauchen 
(https://www.mikrocontroller.net/articles/Lichtsensor_/_Helligkeitssensor#LED). 
Die gibt es als SMD schliesslich extrem billig, und zusätzlich bräuchte 
man offenbar nur einen Widerstand. Aber ist das für mein Vorhaben eine 
wirklich geeignete Option, oder spricht da irgendetwas dagegen? Und wenn 
geeignet - worauf sollte ich sinnvollerweise bei der Auswahl der LED 
achten? (z.B. Farbe oder Ähnliches)
Wenn nicht geeignet - was wäre die bessere Lösung? Phototransistor? 
Photodiode?

Bei einer kurzen Google-Suche konnte ich auf Anhieb nur zwei Webseiten 
finden, wo diese Idee bereits aufgegriffen wurde:
https://hackaday.com/2013/02/25/using-a-flashing-lcd-monitor-to-transfer-data/
http://eclsh.blogspot.com/2013/02/gray-scale-lcd-data-transfer.html
Allzu viel scheint daraus aber nicht geworden zu sein. :-(

[Stefan F. (Gast)]

Fotowiderstände sind zu träge, Fotodioden brauchen einen Verstärker. Ich 
würde Fototransistoren verwenden, die kannst du direkt mit einem 
digitalen (oder vielleicht besser: analogen) Eingang verbinden.

[Frank K. (fchk)]

Joachim S. schrieb:

> Hier mal meine Wünsche:
> 1. Damit die prinzipbedingt eher langsame Datenübertragung nicht unnötig
> lange dauert, wäre es schön, mindestens 30 Bilder/Helligkeitswerte pro
> Sekunde auswerten zu können.

Dein Bildschirmupdate wird nicht synchron zum LCD-Update sein, und Du 
kannst Dir nicht undebingt sicher sein, dass Phones immer mit 60 Hz 
updaten. Viele MIPI DSI-Displays haben lokalen Speicher, so dass sie 
nicht regelmäßig Bilddaten brauchen - infach aus Stromspargründen.

30 Frames sind realistisch gesehen die Obergrenze.

> 2. Pro Bild möchte ich ausserdem mindestens 4 Helligkeitsstufen bzw. 2
> Bit unterscheiden können (in der Hoffnung, das eine Bit dann als
> Clock-Signal verwenden zu können)

Vergiss es. Graustufen verteuern die Auswerteelektronik deutlich, und Du 
brauchst irgendeine Kalibrierung. Mehre Sensoren sind einfacher.

> 2. Da das Übertragen der WLAN-Zugangsdaten ja normalerweise ein
> einmaliger Vorgang ist, und das Ganze jetzt eher ein witziges kleines
> Zusatzfeature sein soll, hoffe ich dass es da eine möglichst günstige
> und einfache (im Sinne von: möglichst wenig günstige Bauteile und
> benötigte IO/ADC-Pins etc.) Lösung gibt.
> 3. Ich würde bevorzugen, wenn der Helligkeitssensor in SMD-Bauform wäre.

Mein Vorschlag: Probiere erstmal etwas, was in der Praxis schon 
funktioniert: den Flickercode von TAN-Generatoren.

Siehe:
https://6xq.net/flickercodes/

Da steht drin, wie das ganze Zeug funktioniert. Die nehmen Takt und 4 
Datenbits. Das kannst Du natürlich bis auf 1 Datenbit reduzieren, aber 
vielleicht implementierst Du erstmal das Original, denn das läuft auf 
den verschiedensten Bildschirmtypen.

fchk

[Joachim S. (oyo)]

Stefanus F. schrieb:
> Fotowiderstände sind zu träge, Fotodioden brauchen einen Verstärker. Ich
> würde Fototransistoren verwenden, die kannst du direkt mit einem
> digitalen (oder vielleicht besser: analogen) Eingang verbinden.

Danke schon mal für die Antwort, Stefan. Einen zusätzlich nötigen 
Verstärker würde ich in der Tat als K.O.-Kriterium betrachten.

Wobei mich die Antwort ehrlich gesagt gerade etwas verwirrt, denn ich 
hatte diesen Abschnitt hier:
https://www.mikrocontroller.net/articles/Lichtsensor_/_Helligkeitssensor#Konstantstromquelle_mit_Arbeitswiderstand
so verstanden, dass bei der Option "Photodiode" ein einziger 
zusätzlicher Widerstand ausreichen würde, indem man Photodiode und 
Widerstand als Spannungsteiler verwendet. Da die Option 
"Phototransistor" auf den ersten Blick völlig identisch aussieht:
https://www.mikrocontroller.net/articles/Lichtsensor_/_Helligkeitssensor#Phototransistor
habe ich mich eh bereits gefragt, wie sich diese beiden Optionen jetzt 
genau unterscheiden bzw. welche Vor-/Nachteile beide Optionen in meinem 
geplanten Anwendungsfall hätten.

Ich halte also mal fest: Wenn es auf Photodiode vs. Phototransistor 
herausläuft, dann wohl eher Phototransistor.

[Stefan F. (Gast)]

Joachim S. schrieb:
> dass bei der Option "Photodiode" ein einziger
> zusätzlicher Widerstand ausreichen würde, indem man Photodiode und
> Widerstand als Spannungsteiler verwendet.

Ja, ein Widerstand mit 1MΩ mag gehen, aber zeige mir mal einen ADC, der 
mit so großen Eingangswiderständen noch halbwegs brauchbar funktioniert. 
Bei den mir bekannten Mikrocontrollern musst auf Werte unter 20kΩ 
kommen.

[Peter Z. (Gast)]

Ich habe das mit einer Photodiode und einem OP schon mal realisiert um 
mit einem blinkenden Handy Bildschirm ein Relais ein bzw. auszuschalten. 
1 Databyte und 1 Byte Crc8 wurde dazu übertragen.
Die Handy Beleuchtung ist übrigens PWM gepulst.
Viel Spaß beim Umsetzen deiner Vorstellung ;)

[Joachim S. (oyo)]

Frank K. schrieb:
> Joachim S. schrieb:
>
>> Hier mal meine Wünsche:
>> 1. Damit die prinzipbedingt eher langsame Datenübertragung nicht unnötig
>> lange dauert, wäre es schön, mindestens 30 Bilder/Helligkeitswerte pro
>> Sekunde auswerten zu können.
>
> Dein Bildschirmupdate wird nicht synchron zum LCD-Update sein, und Du
> kannst Dir nicht undebingt sicher sein, dass Phones immer mit 60 Hz
> updaten. Viele MIPI DSI-Displays haben lokalen Speicher, so dass sie
> nicht regelmäßig Bilddaten brauchen - infach aus Stromspargründen.
>
> 30 Frames sind realistisch gesehen die Obergrenze.

Gut, dann ist das halt so. 30fps fände ich auch völlig ok, mir ging es 
dabei auch vor Allem darum, dass der Helligkeitssensor technisch dazu in 
der Lage sein sollte, 30 bzw. deutlich über 30 brauchbare Messwerte pro 
Sekunde zu liefern (womit ein LDR ja offenbar flachfällt).

>> 2. Pro Bild möchte ich ausserdem mindestens 4 Helligkeitsstufen bzw. 2
>> Bit unterscheiden können (in der Hoffnung, das eine Bit dann als
>> Clock-Signal verwenden zu können)
>
> Vergiss es. Graustufen verteuern die Auswerteelektronik deutlich, und Du
> brauchst irgendeine Kalibrierung. Mehre Sensoren sind einfacher.

Mehrere Sensoren möchte ich ehrlich gesagt vermeiden, wenn es nur 
iiirgendwie möglich ist. Selbst mit einer drastischen Reduzierung der eh 
schon sehr geringen Übertragungsrate könnte ich mich momentan eher 
anfreunden.

Als Kalibrierung hatte ich vorgesehen, dass vor der eigentlichen 
Datenübertragung einfach eine gewisse Hell-/Dunkel-Sequenz gesendet 
wird, durch die sich der Empfänger auf die maximale/minimale Helligkeit 
einstellt.

Was genau verteuert Deiner Einschätzung nach denn die Auswerteelektronik 
so deutlich, wenn man vier Graustufen unterscheiden will?

> Mein Vorschlag: Probiere erstmal etwas, was in der Praxis schon
> funktioniert: den Flickercode von TAN-Generatoren.
>
> Siehe:
> https://6xq.net/flickercodes/
>
> Da steht drin, wie das ganze Zeug funktioniert. Die nehmen Takt und 4
> Datenbits. Das kannst Du natürlich bis auf 1 Datenbit reduzieren, aber
> vielleicht implementierst Du erstmal das Original, denn das läuft auf
> den verschiedensten Bildschirmtypen.

Diese TAN-Generatoren kenne ich, an die habe ich auch bereits gedacht, 
nachdem mir die Idee kam. Aber wenn irgendwie möglich, möchte ich 
dennoch lieber einen anderen Ansatz wählen, der mit einem einzigen 
Helligkeitssensor auskommt. Leicht nachteilig finde ich bei dem 
TAN-Generator-Ansatz nämlich nicht nur, dass man mehrere Sensoren 
benötigt (also auch mehr Bauteile, Kosten und benötigte IO-Pins), 
sondern auch, dass diese TAN-Generatoren erst einmal auf die konkrete 
Bildschirmgrösse konfiguriert werden müssen, und dass der TAN-Generator 
dann ganz exakt an der richtigen Stelle positioniert werden muss.

Die Art der Datenübertragung, die mir momentan vorschwebt, wäre für 
einen solchen TAN-Generator nicht geeignet, das ist mir klar. Man will 
schliesslich nicht für jede TAN minutenlang warten.
Aber für das von mir vorgesehene Anwendungsszenario erscheint mir mein 
minimalistischer und vglw. langsamer Ansatz akzeptabel, denn es geht 
hier wie gesagt um einen Vorgang, den man pro Gerät/Mikrocontroller 
üblicherweise ja nur ein einziges Mal durchführt...

[Joachim S. (oyo)]

Peter Z. schrieb:
> Ich habe das mit einer Photodiode und einem OP schon mal realisiert um
> mit einem blinkenden Handy Bildschirm ein Relais ein bzw. auszuschalten.
> 1 Databyte und 1 Byte Crc8 wurde dazu übertragen.

Das werte ich jetzt einfach mal als ermunternde Bestätigung, dass die 
Idee grundsätzlich durchaus funktionieren sollte. :-)

> Die Handy Beleuchtung ist übrigens PWM gepulst.

Ah. Sehr guter Hinweis - da habe ich nicht dran gedacht, das 
verkompliziert das Ganze in der Tat zumindest ein wenig... :-/

[Jens M. (schuchkleisser)]

Stefanus F. schrieb:
> Fotowiderstände sind zu träge,

Wie träge ist "zu"?
Ich habe einen Drehzahlmesser für Modellflieger, der einen LDR hat, und 
der kann weit schneller als 50Hz messen: Das sind bei "2-flügelig" 
gerade 3000 1/min, und das Ding kann 99999 1/min messen, sowie bis 
"9-flügelig", wobei ich nicht weiß oder 99999 und 9 zusammen gehen.
Aber 50Hz sollte ja für die Blinkerei reichen.

Ansonsten gibt es ja Systeme wie die FotoTAN-Geräte, die machen genau 
das was OP will.
Idee klauen, fertig.
Man muss nur aufpassen, das die Framerate der Handyglotze passt.
So manche Strobo-App kommt mit ganz schrägen Interferenzeffekten, wenn 
man das testet.

[Stefan F. (Gast)]

Jens M. schrieb:
> Wie träge ist "zu"?

Wenn du einen gewöhnlichen Fotowiderstand zuerst in die Sonne legst und 
dann in eine schwarze Dose, dauert es einige Sekunden, bis er sich einem 
stabilen Wert (>1MΩ) annähert.

[Jens M. (schuchkleisser)]

Tja, das mag sein.
Tritzdem kann mein RPM-Meter bei Zimmerbeleuchtung vorbeifliegende 1cm 
Breite Flügel erfassen, mit locker mehreren zig Hertz.
Und LED- oder Leuchtstofflampen machen ihn verrückt.
Draußen geht's, oder wenn man noch ne Heatball hat.

Du musst deinen Versuch mal nicht von 100000 auf 0 Lux machen, sondern 
vielleicht nur mit 100000 zu 99000, oder 0 bis 100, oder 10000-11000.
Dann klappt das.

[Christopher J. (christopher_j23)]

Joachim S. schrieb:
> Smartphone-Bildschirm direkt vor einen mit dem µc verbundenen
> Helligkeitssensor hält

> Wenn nicht geeignet - was wäre die bessere Lösung? Phototransistor?
> Photodiode?


> Pro Bild möchte ich ausserdem mindestens 4 Helligkeitsstufen bzw. 2 Bit
> unterscheiden können

Das Problem sehe ich weniger im Empfänger als viel mehr im Sender. 
Aktuelle Helligkeitssensoren die so typischerweise in Smartphones 
verbaut werden haben durchaus eine respektable Auflösung (natürlich in 
Abhängigkeit der Abtastrate bzw. der Integrationszeit aber das ist ein 
anderer Punkt) aber wie willst du deinem Handy beibringen, dass es ein 
Bild mit xyz Lux ausgeben soll? Da kommt dir ironischerweise der 
Helligkeitssensor des Gerätes selbst in die Quere, der beim Auflegen auf 
den Sensor des ESP auf einmal meint dein Display runterdimmen zu müssen, 
weil es eben gerade ein bisschen dunkler geworden ist. Eventuell hast du 
aber auch Reflexionen und der Helligkeitssensor (in deinem Handy) meint 
es wäre jetzt doch eigentlich wieder heller draußen und schraubt die 
Displayhelligkeit hoch.

Um das Problem der dynamischen Displayhelligkeit zu umgehen könnte man 
diese natürlich am Handy deaktivieren. Verbleibt jedoch noch das 
Problem, dass ein Handy vielleicht etwas heller eingestellt ist als ein 
anderes. Hierfür könntest du natürlich eine Art Start-Bit wie bei einem 
UART einfügen. Macht die ganze Sache jedoch noch komplizierter.

Ich würde den Vorschlag von Frank verfolgen, d.h. das Verfahren von den 
Tangeneratoren und nicht nach Graustufen unterscheiden. Wenn es nur um 
einen WLAN-Schlüssel geht, dann ist die Datenrate ja auch nicht so 
kritisch und selbst wenn die Übertragung fünf oder zehn Sekunden dauern 
sollte, dann geht davon die Welt nicht unter, schließlich wechselt man 
nicht jeden Tag den WLAN-Schlüssel. Ansonsten würde sich beim ESP32 
eventuell auch Schall für die Datenübertragung anbieten, schließlich hat 
der ESP I2S und es ist viel einfacher einem Handy zu sagen "gib mal für 
200 Millisekunden einen Ton mit 800 Hz aus". Auch die erreichbare 
Übertragungsgeschwindigkeit dürfte deutlich höher sein. Ich schätze mal 
1200 Baud sind locker drin. Also gewissermaßen ein ESP als Datenklo ;)

[Frank K. (fchk)]

Joachim S. schrieb:

>>> 2. Pro Bild möchte ich ausserdem mindestens 4 Helligkeitsstufen bzw. 2
>>> Bit unterscheiden können (in der Hoffnung, das eine Bit dann als
>>> Clock-Signal verwenden zu können)
>>
>> Vergiss es. Graustufen verteuern die Auswerteelektronik deutlich, und Du
>> brauchst irgendeine Kalibrierung. Mehre Sensoren sind einfacher.
>
> Mehrere Sensoren möchte ich ehrlich gesagt vermeiden, wenn es nur
> iiirgendwie möglich ist. Selbst mit einer drastischen Reduzierung der eh
> schon sehr geringen Übertragungsrate könnte ich mich momentan eher
> anfreunden.

Naja, dann wirst Du warscheinlich eine OpAmp-Schaltung brauchen anstelle 
eines einfachen Schmitt-Trigger-Eingangs.

Ausweg: Manchester-Kodierung. Damit hast Du nur ein Signal, das Takt und 
Daten enthält. Die Anforderungen ans Timing auf der Sendeseite sind 
natürlich höher.

Schau Dir an, wie Microchip das macht:

http://ww1.microchip.com/downloads/en/DeviceDoc/22067J.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/22076D.pdf

Damit wird die Hardware einfach, die Software aber komplex. Gut für die 
Stückkosten.

fchk

[Stefan F. (Gast)]

Frank K. schrieb:
> Naja, dann wirst Du warscheinlich eine OpAmp-Schaltung brauchen anstelle
> eines einfachen Schmitt-Trigger-Eingangs.

Den würde ich in Software implementieren, incl. automatischer Anpassung 
an die Display-Helligkeit. Wozu hat man sonst quasi kostenlos ADC 
Eingänge zur Verfügung?

[chris (Gast)]

Geht mit dual color Led, welche zwei Anschlüsse haben.
Übertragen mit Display, emfpangen mit Kamera.

[chris (Gast)]

Am Einfachsten ist es Morsecode zu verwenden.
Übertragung mittels Display (langsam) oder flash (schnell).
Für Android oder IOS gibt es die Apps zum Senden und empfang der Daten.

[M.K. B. (mkbit)]

Joachim S. schrieb:
> Vergiss es. Graustufen verteuern die Auswerteelektronik deutlich, und Du
> brauchst irgendeine Kalibrierung. Mehre Sensoren sind einfacher.

Man sollte auch bedenken, dass die Helligkeit im Handy wahrscheinlich in 
RGB angegeben wird. Diese sieht für das menschliche Auge linear aus. Für 
deine Auswerteeinheit ist es aber exponentiell.

Du kannst ja auch zwei Sensoren einbauen. Die Trennung ist dann in der 
Bildschirmmitte. Auf dem ESP ist dann ein Strich, der da ausgerichtet 
werden muss. Damit entfällt die Skalierung.

[avr (Gast)]

Wenn es einfach werden soll kann man schon Richtung Manchesterkodierung 
gehen, aber schnell wird es damit nicht.

Für ein schnelle Übertragung würde ich folgendes vorschlagen:
- Volle Helligkeit, um PWM-Störeinflüsse zu reduzieren
- Jedes Frame, bzw. jedes nte Frame (je nach dem wie schnell so Displays 
reagieren) wird für eine anderes Symbol (=Graustufe) genutzt.
- Synchronisationfolge am Anfang der Übertragung, damit der Empfänger 
Übertragungsfrequenz und Dynamikbereich kennt
- Anschließend werden die Daten mit einer guten Fehlerschutzkodierung 
(z.B. Reed-Solomon) übertragen
- Überabtastung am Empfänger mit Tiefpassfilterung

Damit sollte eine Übertragung in 1-2 Sekunden durchführbar sein. 
Allerdings ist die Software dazu alles andere als trivial.

[Joachim S. (oyo)]

Vielen Dank schon mal für die vielen Antworten, die in der Zwischenzeit 
eingegangen sind.

Da waren wirklich einige hilfreiche Hinweise dabei. z.B. der Hinweis, 
dass mir ausgerechnet der Helligkeitssensor im Smartphone da zusätzliche 
Probleme bereiten könnte, indem er dann die Bildschirmhelligkeit 
dynamisch hoch-/herunterregelt.

Oder, dass ich die Datenübertragung stattdessen Lautsprecher/Mikrofon 
bzw. Ton machen könnte. Das erscheint mir in der Tat als der viel 
bessere Ansatz zur Datenübertragung von Smartphone zu Mikrocontroller, 
denn damit würde man fast alle genannten Probleme vermeiden, und man 
könnte so vermutlich auch die Übertragungsgeschwindigkeit deutlich 
erhöhen.

Ich sehe ja auch ein, dass es grundsätzlich sinnvoller wäre, auf mehrere 
Sensoren statt auf Graustufen zu setzen. Aber, hach, vielleicht kann's 
ja mancher nachvollziehen: Noch bin ich nicht ganz bereit, mich von 
meinem ursprünglichen Gedanken mit möglichst geringem Materialeinsatz zu 
verabschieden, und hoffe immer noch, dass man die genannten Probleme 
irgendwie lösen kann. (Die Hoffnung stirbt halt zuletzt)

Momentan tendiere ich am ehesten dazu, die Übertragungsgeschwindigkeit 
zu reduzieren, und dadurch gewisse Probleme zu lösen. Die Daten in 1-2 
Sekunden übertragen zu können, wäre zwar toll - aber da habe ich eh mit 
deutlich mehr gerechnet. Weil es halt ein einmaliger Vorgang ist, würde 
ich derzeit sogar 60 Sekunden oder mehr als noch akzeptabel betrachten. 
Bei sagen wir mal 30 Byte Datenmenge wären das dann gerade mal ca. 4 Bit 
pro Sekunde.

Damit käme wohl auch ein LDR wieder in Frage. Da ich ein ESP8266-Board 
mit Photowiderstand hier eh herumliegen habe, werde ich wohl einfach mal 
einen kleinen Versuch starten, mit unterschiedlich vielen Graustufen und 
Geschwindigkeiten, und die gemessenen Werte einfach mal roh aufzeichnen 
und visualisieren.
Wenn sich die Idee mit den Graustufen dabei wirklich als ungeeignet 
herausstellt, werde ich als nächstes wohl wirklich in Richtung 
Manchester-Kodierung denken, wie das ja schon mehrere vorgeschlagen 
haben.

[Stefan F. (Gast)]

Falls ein LDR wirklich schnell genug ist, könnte er mit etwas Glück die 
PWM Dimmung der Display-Beleuchtung von ganz alleine heraus filtern.

Für kommerzielle Consumer Produkte sind LDR aber nicht mehr zugelassen, 
glaube ich.

[Joachim S. (oyo)]

So, ich habe zwischenzeitlich mal einen Test mit einem Photowiderstand 
gemacht, und die vom ADC gemessenen Werte (10 Bit, also 0-1023) 
aufgezeichnet und visualisiert. Gemessen wurde 100 mal pro Sekunde, also 
alle 10 Millisekunden. Ich habe immer 1000 Messwerte erfasst, also 10 
Sekunden.

Ich habe immer vier Graustufen genommen, die RGB-Farbcodes #000000, 
#555555, #aaaaaa und #ffffff.

Ich habe 5mal pro Sekunde gewechselt. Das Display habe ich mal auf 
maximale, mal auf 50% Helligkeit eingestellt.

Die eine Grafik zeigt die vollen 10 Sekunden bzw. 1000 Messwerte, die 
zweite Grafik (quasi als Vergrösserung) nur die ersten 200.

Was ich daraus schliesse:
1. PWM sorgt zumindest in der Kombination aus Photowiderstand + meinem 
Smartphone glücklicherweise nicht für Probleme. Durch die Trägheit des 
LDR wird der PWM-Effekt offenbar herausgefiltert, wie von Stefan 
vermutet.
2. Die gemessene Helligkeit verhält sich offenbar nicht linear; der 
Sprung von 0% bzw. #000000 auf 33% bzw. #555555 ist deutlich kleiner als 
die beiden Sprünge danach.
3. Der Photowiderstand verhält sich schon recht träge, aber 10 oder 
vielleicht sogar 20fps dürften schon drin sein.

Ich betrachte die Ergebnisse dieses Tests jetzt erst einmal als 
ermutigend. Grundsätzlich scheint die Idee schon machbar zu sein, auch 
wenn die Datenübertragung wohl ziemlich lahm sein wird.
Habe mir jetzt mal einen Fototransistor bestellt; sobald der da ist, 
werde ich den Test dann nochmal damit wiederholen.

[Stefan F. (Gast)]

Das sieht doch schon sehr brauchbar aus.

[Joachim S. (oyo)]

Stefanus F. schrieb:
> Das sieht doch schon sehr brauchbar aus.

Finde ich auch. Ich habe deutlich Schlimmeres befürchtet. Gerade weil 
der ADC des ESP meines Wissens nach ja eh etwas problematisch ist.

Was mich immer noch ein wenig verwundert ist, dass der Sprung von 0 auf 
33% Helligkeit bzw. von Farbe #000000 auf #555555 so deutlich geringer 
ist als die beiden Sprünge danach, von 33% auf 66% bzw. von 66% auf 
100%.

Weil ich mich gefragt habe, ob das vielleicht einfach mit diesem 
speziellen Smartphone bzw. dessen Display zusammenhängt, habe ich 
zwischenzeitlich nochmal ein anderes Smartphone hervorgekramt und den 
Test damit wiederholt. (Siehe Anhang, die grüne Linie). Auch da aber das 
gleiche Phänomen.

Hat da jemand eine Erklärung für? Ich frage mich halt, ob ich davon 
ausgehen kann, dass das bei fast allen Smartphones so wäre. In diesem 
Fall wäre es wahrscheinlich sinnvoller, statt 33% und 66% andere 
Graustufen-Werte zu wählen, bei denen die Abstände gleichmässiger sind.

[Stefan F. (Gast)]

Joachim S. schrieb:
> Was mich immer noch ein wenig verwundert ist, dass der Sprung von 0 auf
> 33% Helligkeit bzw. von Farbe #000000 auf #555555 so deutlich geringer
> ist als die beiden Sprünge danach, von 33% auf 66% bzw. von 66% auf
> 100%.

Weil das Auge auf Helligkeitsunterschiede anders reagiert, als der LDR.

Für das Auge gilt, dass du etwa vier-fache Energie brauchst, damit es 
doppelt so Hell aussieht (also logarithmisch). Beim LDR ist es ebenfalls 
nicht linear, aber nicht ganz so extrem wie beim Auge.

> Ich frage mich halt, ob ich davon ausgehen kann, dass
> das bei fast allen Smartphones so wäre.

Ich würde mich darauf vorbereiten, dass das bei jedem Smartphone anders 
ist und auch von der aktuellen Einstellung abhängt. Stichwort: 
Farb-profile