mikrocontroller.net

Forum: Projekte & Code Digitaler Bilderrahmen, ePaper, Batteriebetrieb, portabel


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.
Autor: Horst M. (horst)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier haben wir einen elektronischen Bilderrahmen, der bei einem 
Update-Intervall von 2 Minuten im realen Einsatz gut 3 Monate mit einer 
AA-Zelle durchhalten sollte.
Als Display kommt ein 4.2"-ePaper-Modul von Waveshare zum Einsatz.
Es ist mir gelungen, eine Darstellung mit 16 Graustufen zu realisieren.
Das ist jenseits der von Waveshare spezifizierten Anwendung (Standard 
ist ein Betrieb mit 1 Bit/Pixel). Da Waveshare die ePaper-Displays wohl 
zukauft, ist nicht sicher, ob mglw. Displays mit anderer Technologie 
angeboten werden könnten, die mit dem implementierten 
Ansteuerungskonzept nicht harmonieren.
Tatsächlich ist das schon passiert:
Ich hatte zunächst ein Dreifarben-Display (weiß/gelb/schwarz) 
ausgewählt, weil ich auch getestet habe, ob sich mit der gelben Farbe 
evtl. ebenfalls etwas anfangen läßt. Dies macht allerdings m.E. für eine 
universelle Bilddarstellung keinen Sinn (die Anzeige wird einfach nur 
extrem gelbstichig), außerdem ist die Intensität der gelben Farbe nicht 
vernünftig bzw. unabhängig von der Schwarz/Weiß-Darstellung steuerbar. 
Da der Weißwert/Kontrast der dreifarbigen Displays selbst bei einfacher 
S/W-Ansteuerung aber vergleichsweise nicht ganz so gut ist, habe ich's 
auch mal mit der monochrome Display-Variante probiert.
Damit ist das Weiß zwar weißer, die Graustufen werden allerdings 
überraschenderweise ziemlich grobkörnig dargestellt, wie mit einem sehr 
grobkörnigen S/W-Filmmaterial. Das Dreifarb-Display zeigt keine solchen 
Effekte, deshalb bin ich dabei geblieben.

Die ePaper-Displays haben konstruktionsbedingt eine gewisse 
Temperaturabhängigkeit (immerhin verwenden sie ein mechanisches 
Funktionsprinzip, die Farbkügelchen müssen ja in einer Flüssigkeit 
bewegt werden). Das von Waveshare original bereitgestellte Setup 
berücksichtigt die Displaytemperatur in 9 Stufen und paßt die 
Display-Update-Parameter entsprechend an (im Wesentlichen verlängert 
sich die benötigte Updatedauer, je niedriger die Temperatur ist). Ich 
habe keine Klimakammer, mit der ich das entsprechend reproduzierbar 
nachbauen könnte, deshalb gibt es nur einen Parametersatz für die 
übliche Zimmertemperatur.
Eine konstante Spannungsversorgung ist ebenfalls ratsam, das Display 
arbeitet zwar auch noch mit einer geringeren Versorgungsspannung, 
Änderungen der Grauwerte sind bei schwankender Spannung aber 
unvermeidbar. Ein Spannungsstabilisator ist deshalb erforderlich, direkt 
aus einer 3V-LiMno2-Zelle macht's keinen Sinn, mit 3,6V-Lithium-Thionyl 
(evtl. auch Akku) + LDO wird's wohl gehen, ich habe mich für Alkaline-AA 
und Step-Up-Wandler entschieden.

Nach dem PowerOn-Reset wird das Display einmal mit den Factory-Settings 
gelöscht, das dauert gute 10 Sekunden. Für den normalen Betrieb habe ich 
die LookUp-Tables zeitlich optimiert, bin aber beim prinzipiellen 
Verfahren geblieben - in der Hoffnung, damit die Lebensdauer des 
Displays nicht zu reduzieren (ob's klappt, wird sich vmtl. erst nach 
etlichen Monaten Dauerbetrieb zeigen). Mit irgendwelchen wilden 
Parameterwerten (etwa höhere Boosterspannung und längeren Einzelphasen) 
ließe sich die benötigte Dauer mglw. noch verringern, aber was nützt 
das, wenn dann nach einiger Zeit die Farbkügelchen anders polarisiert 
werden oder vielleicht irgendwo Elektrolyse der Elektroden einsetzt...

Ich denke, die hier gezeigte S/W- bzw. Graustufen-Implementation ist 
aktuell Stand der Technik,vollfarbfähige ePapers gibt es nach wie vor 
nur als Ankündigung oder Messemuster, Module für den Hobbyisten schon 
gar nicht.

Youtube-Video "Electronic Picture Frame with ePaper Display"

Als Controller habe ich einen Pro-Micro-Clone (Atmega 32u4, 3,3 V, 8 
MHz, 32 k Flash, 2.5 k RAM) eingesetzt, im Prinzip ginge es mit jedem 
Atmega ab 32 k Flash und 2 k RAM, wenn die Sektor-Puffergröße für das 
Lesen von der SD-Card reduziert wird. Der Programmcode an sich ist gar 
nicht so umfangreich - ca. 8 kBytes - aber es sind noch zwei Bilder für 
Statusanzeigen mit dabei, die tragen ziemlich auf...
Die LEDs und der Onboard-Spannungsregler auf dem Pro-Micro-Breakout sind 
rausgeknackt, um unnötigen Stromverbrauch zu vermeiden.
Die Bilder werden auf einer (Micro-)SD-Card als monochrome JPEGs 
abgelegt, die SD-Card wird via 8-Bit-Bustreiber (74HC245) angesteuert 
sowie mit Strom versorgt und kann damit komplett abgeschaltet werden.
Die dekodierten Bilddaten werden in einem SPI-RAM (64 kByte, 23LC512) 
zwischengespeichert, es ist nicht möglich, sie gleich im Framebuffer des 
ePaper-Moduls abzulegen.
Mittels Fotodiode BPW34 wird die Umgebungshelligkeit geprüft und das 
Display-Update gestoppt, sobald es zu dunkel geworden ist, das kommt der 
Batterielaufzeit zugute.
Als Step-Up-Wandler auf 3,3 V kommt der Sparkfun-Breakout PRT-10967 mit 
NCP 1402 zum Einsatz. Der Leerlaufstrom ist damit deutlich geringer als 
mit entsprechenden Pololu-Teilen, das ganze Gerät zieht zwischen den 
Display-Updates ca. 80 uA aus einer vollen AA-Zelle. Der Batteriehalter 
ist von Bulgin.
Beim Prototypen ist das SPI-RAM und der Spannungswandler-BreakOut unter 
dem ProMicro montiert, kleiner bekommt man die Steuerung mit Komponenten 
im 2.54 mm-Raster nicht mehr.
Das Schaltungskonzept sollte auch mit einem 7.5"-ePaper-Modul (640x375 
Pixel) verwendbar sein, in diesem Fall wird aber ein 128 kByte-SPI-RAM 
benötigt (23LC1024), mit dem größeren Display wäre sicher auch Platz für 
zwei AA-Zellen.

Die Firmware ist in Assembler kodiert (AVR Studio 4.19-Projekt).
Der JPEG-Dekoder ist eine angepaßte Version aus dieser Veröffentlichung 
Beitrag "Fast JPEG decoder on AT(x)mega" und braucht inkl. 
Datei- und SPI-RAM-Zugriff ca. 1 Sekunde für die Dekodierung eines 
Bildes (400x300 Pixel) bei 8 MHz Controllertakt. Der Atmega geht auch 
während der Display-Update-Phasen immer wieder in den Powersave-Modus 
und wird über die BUSY-Leitung vom Display geweckt, wenn der jeweilige 
Vorgang abgeschlossen wurde.
Der SD-Card/Filesystem-Treiber ist eine Mischung aus Petite FS und FAT 
FS (ElmChan), ich habe auf vFAT erstmal verzichtet, Datei- und Pfadnamen 
sind also im 8.3-Format (Großschreibung) anzugeben. In den Beispielen 
wird eine 4 GByte-Micro-SD-Card mit FAT32 verwendet.
Die Pfadnamen der anzuzeigenden Bilder werden aus der Datei PICTURES.TXT 
im Root-Verzeichnis gelesen.
Die Bilddarstellung kann mit der Datei CONTROL.TXT (ebenfalls im 
Root-Verzeichnis) kontrolliert werden.
Es gibt zwei Optionen:
timer=<Verzögerung bis zur Anzeige des nächsten Bildes in Sekunden, 
Default sind 120 Sekunden, Maximum 2040 Sekunden=34 Minuten>
mode=<random|>

Der Atmega geht nach der Dekodierung/Anzeige eines Bildes in den 
Powersave-Modus und läßt sich vom Watchdog-Interrupt alle 8 Sekunden 
aufwecken. Die Granularität des timer-Parameters ist dementsprechend 8 
Sekunden.
Mit mode=random wird ein zufälliges Bild zur Anzeige ausgewählt, mit 
jedem anderen Parameterwert oder wenn mode gar nicht angegeben wird, 
erfolgt die Anzeige sequentiell so wie in PICTURES.TXT aufgeführt.
Im Random-Mode wird im Übrigen geprüft, ob das aktuell gewählte Bild 
bereits unter den fünf zuvor angezeigten Bildern gewesen ist. In diesem 
Fall wird ein anderes Bild gewählt.

Die Firmware erwartet die Bilder im korrekten Format, es wird nichts 
skaliert, gedithert o. dgl. (die Schaltung hat kein Gramm Fett zuviel, 
für größere Bilder ist kein Platz; außerdem müßte die Skalierung usw. 
jedesmal auf's Neue durchgeführt werden, das kostet wieder Energie; ein 
SPI-RAM wäre datenzugriffstechnisch für solche Bildmanipulationen auch 
nicht direkt optimal).
"Korrekt" ist eine Auflösung von 400x300 Pixeln, monochrom mit 16 
Graustufen im JPEG-Format.
Der grundlegende Workflow mit GIMP sieht bspw. so aus:
Bild-->Modus-->Graustufen
Bild-->Bild skalieren 400x300
Bild-->Modus-->Indiziert-->
    Optimale Palette erzeugen, max. Anzahl der Farben: 16
    + Rasterung: Floyd Steinberg (normal)
Bild-->Modus-->Graustufen
Exportieren als JPEG, "Progressiv" darf nicht verwendet werden

Bei den meisten Bildern ist es empfehlenswert, zusätzlich noch unscharf 
zu maskieren und einen Weißabgleich durchzuführen (alles noch als 
Farbbild), um den Kontrast des S/W-Bildes zu steigern. Abhängig vom 
Bildinhalt kann es sich lohnen, weitere Effekte zu probieren 
(Kontrastspreizung u.ä.).
Das alles läßt sich mit GIMP auch verscripten, etwa mit Batch Image 
Manipulation oder mit Script-Fu.

Mit der Mechanik hatte ich's noch nie so... Das Gehäuse ist aus 
lasergeschnittenen Acrylglasteilen zusammengeklebt (die Klebflächen 
sind, äh, optimierbar...) das ginge mit Sicherheit eleganter. Richtig 
edel wäre ein Acryl-Spritzgußgehäuse mit polierter Frontpartie, 
integriertem Batteriefach (ggf. sogar 4xAA für LDO und > 1 Jahr 
Laufzeit) und ordentlichem Schlitz für die SD-Card, aber das ist als 
Einzelstück illusorisch. Ich würde noch nichtmal die Konstruktion 
hinkriegen (hab für die Acrylplatten mit ein paar CAD-Programmen 
gespielt und die Flinte nach kürzester Zeit ins Korn geworfen und 
Millimeterpapier genommen :-/).

Die Dokumentationslage zum Displaycontroller ist ziemlich dürftig, von 
Waveshare gibt's offiziell nur das Allernötigste, um das Display im 
Standardmodus  steuern zu können (insbesondere die Informationen zur 
Struktur der LookUp-Tables werden explizit zurückgehalten und wurden aus 
dem aktuellen Datenblatt entfernt).
Der serielle Daten-"Eingang" P_MOSI ist effektiv bidirektional, der 
Controller liefert bei einigen Kommandos Informationen zurück.
In der fertigen Bilderrahmen-Firmware werden keine Lesezugriffe 
verwendet (man könnte aber z.B. den eingebauten Temperatursensor 
auslesen und die Controller-Settings anpassen), während der Entwicklung 
war diese Möglichkeit jedoch sehr hilfreich.
Ich habe das so realisiert, daß das SPI-Interface am Atmega nach dem 
Senden des Kommandos und eventueller Parameter deaktiviert und der 
MOSI-Pin auf Input konfiguriert wurde. Das Einlesen der Daten erfolgte 
dann mit einem Soft-SPI, man könnte für solche Zwecke natürlich auch 
gleich alles per Soft-SPI machen.
Mit dieser Methode habe ich das OTP-ROM ausgelesen. Die enthaltenen 
Informationen können als Aufsetzpunkt für eigene Definitionen (LUT etc.) 
verwendet werden, man muß das Rad nicht neu erfinden.

Hier ist mal die Beschreibung der Werte im OTP-ROM aus dem von mir 
eingesetzten Display:
Offset  Wert    Beschreibung
000     A5      Check code, enable key
001     CB      LUT Revision
002     05      Displaytemperatur <=5 Grad für LUT-Definition 0
003     0A      Displaytemperatur <=10 Grad für LUT-Definition 1
...
009     28      Displaytemperatur <=40 Grad für LUT-Definition 7
00A     7F      Ende, LUT-Defintion 8 (oberhalb 40 Grad)

010     0190    X-Auflösung (400)
012     012C    Y-Auflösung (300)
014     53      "S"
015     30      "0"
016     31      "1"
017     30      "0"
018     02      ???

020     A5      Check code, enable key
021     0F      Parameter für PANEL_SETTING
022     00      Parameter für POWER_OFF_SEQUENCE_SETTING
023     D7      1. Parameter für BOOSTER_SOFT_START
024     D7      2. Parameter für BOOSTER_SOFT_START
025     1E      3. Parameter für BOOSTER_SOFT_START
026     00      Parameter für TEMPERATURE_SENSOR_SELECTION
027     77      Parameter für VCOM_AND_DATA_INTERVAL_SETTING
028     22      Parameter für TCON_SETTING
029     0190    1. Parameter für RESOLUTION_SETTING (HRES)
02B     012C    2. Parameter für RESOLUTION_SETTING (VRES)
02D     0000    1. Parameter für GSST_SETTING (HST)
02F     0000    2. Parameter für GSST_SETTING (VST)
031     00      Parameter für CASCADE_SETTING
032     00      Parameter für POWER_SAVING
033     00      Parameter für FORCE_TEMPERATURE

0F0     A5      Check code, enable key
0F1     FC      ??
0F2     E1
0F3     F0 
0F4     F8
0F5     F8
0F6     F8 
0F7     F0
0F8     F0
0F9     F0
0FA     F0
0FB     F0
0FC     F0
0FD     F0
0FE     F2
0FF     FC

                LUT-Definition 0
100     3C      Parameter für PLL_CONTROL
                der 1. Parameter ist immer 3
101     00      2. Parameter für POWER_SETTING
102     2B      3. Parameter für POWER_SETTING
103     2B      4. Parameter für POWER_SETTING
104     12      5. Parameter für POWER_SETTING
105     16      Parameter für VCM_DC_SETTING
106             LUT_FOR_VCOM
        00 B1 B1 00 0C 01 
        00 0D 01 20 02 06 
        00 0A 0A 05 05 19 
        00 05 05 03 03 1E 
        00 0D 0A 20 12 06 
        00 06 1E 1E 01 0E 
        00 09 09 00 00 01
        00 00 
132             LUT_WHITE_TO_WHITE
        90 B1 B1 00 0C 01 
        40 0D 01 20 02 06 
        66 0A 0A 05 05 19 
        99 05 05 03 03 1E 
        80 0D 0A 20 12 06
        00 06 1E 1E 01 0E 
        00 09 09 00 00 01 
15C             LUT_BLACK_TO_WHITE
        A0 B1 B1 00 0C 01 
        48 0D 01 20 02 06 
        66 0A 0A 05 05 19 
        99 05 05 03 03 1E 
        06 0D 0A 20 12 06 
        BC 06 1E 1E 01 0E
        F0 09 09 00 00 01 
186             LUT_WHITE_TO_BLACK
        90 B1 B1 00 0C 01 
        40 0D 01 20 02 06 
        66 0A 0A 05 05 19 
        99 05 05 03 03 1E 
        80 0D 0A 20 12 06 
        00 06 1E 1E 01 0E 
        00 09 09 00 00 01
1B0             LUT_BLACK_TO_BLACK
        62 B1 B1 00 0C 01 
        09 0D 01 20 02 06 
        66 0A 0A 05 05 19 
        99 05 05 03 03 1E 
        11 0D 16 1C 0A 06 
        00 06 1E 1E 01 0E 
        00 09 09 00 00 01 
200             LUT-Definition 1
...
900             LUT-Definition 8

Mit der LUT wird der Spannungsverlauf an den Elektroden (die sog. 
Waveform) definiert.

Die LUTs sind prinzipiell vergleichbar strukturiert,  LUT_FOR_VCOM nimmt 
jedoch eine Sonderstellung ein und ist 44 Bytes lang.

           Bit
Offset  76543210        Beschreibung
00      AABBCCDD        jeweils 2 Bit Level-Select
                        00: VCM_DC
                        01: VDH+VCM_DC (VCOMH)
                        10: VDL+VCM_DC (VCOML)
                        11: Floating
01      AAAAAAAA        Anzahl der Frames für Level A
02      BBBBBBBB        Anzahl der Frames für Level B
03      CCCCCCCC        Anzahl der Frames für Level C
04      DDDDDDDD        Anzahl der Frames für Level D
05      XXXXXXXX        Wiederholungszähler (0...255)
06...11                 gleiche Struktur wie 00...05
12...17                 gleiche Struktur wie 00...05
18...23                 gleiche Struktur wie 00...05
24...29                 gleiche Struktur wie 00...05
30...35                 gleiche Struktur wie 00...05
36...41                 gleiche Struktur wie 00...05
42      -YYYYYYY        Bit 0...6 für die sieben Phasen  
                        der Waveform
                        0: not all Gate ON
                        1: all Gate ON
43      -ZZZZZZZ        Bit 0...6 für die sieben Phasen 
                        der Waveform
                        0: no VCOM High Voltage
                        1: VCOM High Voltage

Die übrigen (Source-)LUTs sind jeweils 42 Bytes lang und werden wie 
folgt kodiert:
       Bit
Offset  76543210        Beschreibung
00      AABBCCDD        jeweils 2 Bit Level-Select
                        00: GND
                        01: VDH
                        10: VDL
                        11: VDHR
01      AAAAAAAA        Anzahl der Frames für Level A
02      BBBBBBBB        Anzahl der Frames für Level B
03      CCCCCCCC        Anzahl der Frames für Level C
04      DDDDDDDD        Anzahl der Frames für Level D
05      XXXXXXXX        Wiederholungszähler (0...255)
06...11                 gleiche Struktur wie 00...05
12...17                 gleiche Struktur wie 00...05
18...23                 gleiche Struktur wie 00...05
24...29                 gleiche Struktur wie 00...05
30...35                 gleiche Struktur wie 00...05
36...41                 gleiche Struktur wie 00...05

Die Anzahl der Frames und die Wiederholungszähler sollten normalerweise 
in allen fünf LUTs identisch kodiert werden, die LUTs unterscheiden sich 
dann nur bei den Level-Selects.

Die vier "Source"-LUTs werden bei einem S/W-Display standardmäßig so 
verwendet, daß sowohl der alte als auch der neue Bildinhalt im 
Display-RAM stehen Der Displaycontroller braucht dann nur die geänderten 
Pixel anzusteuern (schwarz-->weiß und umgekehrt), ein vorheriges Löschen 
des Displayinhalts ist nicht erforderlich.
Schon bei der normalen Ansteuerung des Dreifarb-Displays funktioniert 
das nicht mehr so. Dabei wird von einem vollständig gleichfarbigen 
Displayinhalt ausgegangen (üblicherweise Weiß) und die Bildanteile für 
die Vordergrund-Farben (Schwarz und Gelb bzw. Rot) werden ins 
Display-RAM geladen.
Pro Pixel gibt es damit zwei Bits, Bit 0 bspw. für Schwarz und Bit 1 für 
Gelb. Mit der Bitkombination wird eine der vier LUTs addressiert, die 
dann die Farbe des Pixels setzt.
Das Verfahren ist ziemlich flexibel (nur deshalb konnte ich die 
Graustufendarstellung realisieren).

Beispiel:
00:  Weiß
01:  Schwarz
10:  Gelb
11:  Gelb (genausogut könnte aber auch Schwarz die höhere Priorität 
haben, es hängt nur von der Definition der Waveform in der LUT ab)

Interessant ist übrigens die Methode, mit der die verschiedenen Farben 
kontrolliert werden.
Eine begründete Vermutung lautet:
Die schwarzen und weißen Farbpartikel sind verhältnismäßig klein (können 
sich also schnell bewegen), benötigen aber eine vergleichsweise hohe 
Spannungsdifferenz zwischen VCOM und Source.
Die roten/gelben Farbpartikel sind größer und träger, bewegen sich aber 
schon bei einer kleineren Spannungsdifferenz. Das ist wohl der Grund, 
warum die Dreifarbdisplays eine erheblich längere Zeit für das Update 
brauchen.

Für die Graustufendarstellung werden die LUTs entsprechend so kodiert, 
daß die vier Bits pro Bildpunkt mit zwei Display-Updates - jeweils zwei 
Bits für die LUT-Adressierung wie oben gezeigt -  die Intensität der 
schwarzen "Farbe" für dieses Pixel setzen (ausgehend von einem komplett 
weißen Displayinhalt). Das ist der Trick, der Rest ist Handwerk...

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr schick!

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst M. schrieb:
> Als Step-Up-Wandler auf 3,3 V kommt der Sparkfun-Breakout PRT-10967 mit
> NCP 1402 zum Einsatz. Der Leerlaufstrom ist damit deutlich geringer als
> mit entsprechenden Pololu-Teilen, das ganze Gerät zieht zwischen den
> Display-Updates ca. 80 uA aus einer vollen AA-Zelle.

danke dafür!

tolles Projekt, ich wollte schon "meckern" aber es ist sehr durchdacht!

Mein erstes richtiges Projekt mit DC/DC Wandler war ein Reinfall, was 
nutzt es wenn der µC schläft und schön sparsam ist wenn der Wandler die 
Zellen leersaugt.

Autor: Horst M. (horst)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Horst M. schrieb:
> Hier haben wir einen elektronischen Bilderrahmen, der bei einem
> Update-Intervall von 2 Minuten im realen Einsatz gut
> 3 Monate mit einer AA-Zelle durchhalten sollte.

Ooops, das war sehr konservativ geschätzt.
Heute, nach über 9 Monaten mit einer AA-Zelle vom Discounter, habe ich 
den "Low Battery"-Screen gesehen. Das Gerät hat während der üblichen 
Bürozeiten gearbeitet - also werktäglich ca. 8 Stunden mit zwei Minuten 
Update-Intervall - und stand sonst im Dunkeln (=Stop des 
Display-Updates, siehe Beschreibung).
Sehr wahrscheinlich hat mein Schätzometer beim Messen des Leerlaufstroms 
im 200uA-Meßbereich bereits soviel Spannungsabfall eingebracht, daß der 
StepUp-Wandler deutlich mehr gezogen hat als bei direkter Verbindung zur 
Batterie.

Nach nun einigen zehntausend Display-Updates lassen sich keine negativen 
Effekte (WearOut, Shadowing etc.) erkennen, die optimierte Waveform und 
die anderen Settings scheinen also das Display nicht zu stressen.
Abstürze gab es auch keine, die Firmware ist wohl stabil genug.

9 Monate - da habe ich gar kein schlechtes Gewissen, eine Primärzelle 
einzusetzen...

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst M. schrieb:

> Heute, nach über 9 Monaten mit einer AA-Zelle vom Discounter, habe ich
> den "Low Battery"-Screen gesehen.

Naja, das ist schon sehr schön, aber da ginge sicher noch mehr. Deine 
Begründungen, warum du eine Konstantspannungsquelle unbedingt zu 
brauchen glaubst, sind nämlich sehr, sehr dünn.

Und du kannst davon ausgehen, dass der weit überwiegende Teil der 
verbrauchten Energie genau in diesem Ding verheizt wurde.

D.h.: da ist noch deutlich mehr drin. Im Prinzip läuft es schlicht 
darauf hinaus, Kennlinienfelder für das Display zu ermitteln, sowohl was 
die Abhängigkeit von der Temperatur als auch von der Spannung betrifft. 
Das kann man mit einer Webcam als billigem Sensor leicht automatisieren 
(wenn kein ausführliches DB des eigentlichen Displays zur Verfügung 
steht, denn das sollte diese Abhängigkeiten ohnehin umfassend 
dokumentieren).

Woher auch immer: Wenn man die Kennlinienfelder hat, kann man den 
Konstanter wegwerfen und die nötigen Anpassungen bei der Ansteuerung 
entsprechend der aktuellen Temperatur und Spannung in Software 
erledigen.

BTW: Man braucht nicht unbedingt eine Klimakammer für solche Sachen, 
auch wenn die natürlich ein deutlich komfortableres Arbeiten ermöglicht. 
Das geht zur Not auch mit einfachen haushaltsüblichen Gerätschaften wie 
Tiefkühlfach/-truhe und Backofen, jedenfalls für den Temperaturbereich, 
der hier in Mitteleuropa relevant ist.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.