DOGXL240-7 Kontrastspannung

Hat niemand eine Idee? Hier im Anhang noch ein Oszillogramm von der 
Kontrastspannung. Es ist zu sehen wie sie ansteigt und dann 
zusammenbricht.

Hallo,
Ich habe das gleiche Problem an meinem DOGM240-6. Wie hast Du das 
Problem gelöst? Ich versuche schon seit ewigkeiten, die Kontrastspannung 
zum laufen zu kriegen.

Plötzlich hat die Kontrastspannung einfach funktioniert. Ich habe keine 
Ahnung warum. Die einzige Vermutung ist dass es bei geringer 
Lufttemperatur nicht funktioniert...

Ich hatte danach aber noch eine Menge weitere Probleme, da der I²C Bus 
scheinbar extrem störanfällig ist. Das LCD-Modul selbst stört den Bus so 
stark dass ständig Fehlübertragungen auftreten, die vom LCD-Controller 
dann als falsche Kommandos interpretiert werden, sodass der ständig 
irgendeinen Unsinn macht. Als "Lösung" verwende ich den Reset-Pin, um 
den Controller regelmäßíg zu resetten (wobei das Panel auch schön 
flackert), um ihn aus irgendwelchen ungültigen Zuständen herauszuholen. 
Außerdem habe ich an allen I²C Transfers Timeouts implementiert, und 
initialisiere das LCD bei Überschreitung komplett neu. Insgesamt sehr 
aufwändig dieses LCD mit I²C halbwegs "stabil" ans Laufen zu bekommen.

Hallo,
Ich habe mal die Vlcd gemessen. Die Springt von 0 auf 14,2V innerhalb 
von ein paar ms. Dann liegt die Spannung linear ca 3 Sekunden lang an 
und springt innerhalb von ein paar ms wieder auf 0V.
Wenn man die DIV/s auf 500ms stellt, sieht es wie ein sauberer 
Rechteckimpuls aus.

Nach diesen 3 Sekunden verschwindet auch mein Text.

Deine Spannung steigt ja sehr Trapezförmig an. Dies ist bei mir nicht 
so.

Die Temperatur ist mMn nebensächlich, da ich es auch an heissen Tagen in 
der Sonne ausprobiert habe.

Mein Text erscheint zuverlässig (wenn die Kontrastspannung passt) obwohl 
das Signal aif dem Oszi ziemlich grauenhaft aussieht. Mit 
Fehlübertragungen hatte ich noch kein Problem.

Hallo,

zum Display kann ich nichts sagen, aber:

I2C ist eigentlich sehr stabil, wird schließlich in fast allen 
Fernsehern, Radios usw. genutzt.

keine zu langen leitungen, passende PullUp-Widerstände (2,2k bei 5V 
sollte immer passen), evtl. in SDA und SCL einen 100 Ohm Widerstand beim 
Slave in die Leitungen gegen Reflektionen.

Gruß aus Berlin
Michael

Da ich den oberen Beitrag nicht Editieren kann, kommt jetzt das Bild vom 
Oszi über Pin 29 (Vlcd)

Ich habe mal meine Schaltung gefönt und die Anzeigetzeit ging von 
2-3Sekunden auf ca 0,5 Sekunden runter.
In Kühlschrank zeigt es ca 7 Sekunden etwas an und in der Gefriertruhe 
sind es ca 20 Sekunden.

Niklas G. schrieb:
> Die einzige Vermutung ist dass es bei geringer
> Lufttemperatur nicht funktioniert...

genau umgekehrtes Verhalten?!?

Ich hab das DOGXL240 am laufen, jedoch via SPI. Pullups mit 2.2k halte 
ich bei einem im Datenblatt des LCDs angegebenen Innenwiderstand der 
I2C-Schnittstelle von 600-1000 Ohm für ein Gerücht. Ich habe schon beim 
diesbezüglich gleichen DOGXL160 I2C gleich an den Nagel gehängt, da die 
erreichbare Geschwindigkeit unter aller S.. war. Beim 240er benötigt ein 
kompletter Display-Refresh via SPI ca. 18ms.

Sorry mit dem Tablet kann ich nicht editieren .... geschweige denn 
copy/paste.
Init erfolgt nach Datenblatt:

1

    WriteLCD($F1,false);                          // Set COM to 127

2

    WriteLCD($7F,false);

3

    WriteLCD($F2,false);                          // Set display start line to 0

4

    WriteLCD($00,false);

5

    WriteLCD($F3,false);                          // Set display end line to 127

6

    WriteLCD($7F,false);

7

    WriteLCD($81,false);                          // Set contrast

8

    WriteLCD($8F,false);

9

    WriteLCD($C0,false);                          // Set bottom view

10

    WriteLCD($02,false);

11

    WriteLCD($A3,false);                          // 9.4 kilo-lines/second

12

    WriteLCD($25,false);                          // Set temp.compensation -0.10%/°C

13

    WriteLCD($A9,false);                          // Enable display in black/white mode

14

    WriteLCD($D1,false);                          //

Ich nutztze die Library von U8glib. Ich habe jetzt auf SPI 4 Draht 
umgebaut. Der Fehler ist exakt gleich geblieben.

War Deine Kontrastspannung auf einen Hardware- oder Softwarefehler 
zurückzuführen?

Hat jemand von euch mal U8glib ausprobiert?

J. D. schrieb:
> War Deine Kontrastspannung auf einen Hardware- oder Softwarefehler
> zurückzuführen?
Ich weiß es nicht, es hat am zweiten Tag plötzlich funktioniert :/ 
Einzige Vermutung wie gesagt Temperaturabhängigkeit, beim ersten Versuch 
wars draußen in einer kalten Garage, beim zweiten im gemütlich warmen 
Labor...

Hast du die Pins für die Ladungspumpe mal ans Oszilloskop gehalten? 
Vielleicht sieht man da was. Was passiert, wenn du nach Einstellen der 
Konstrastspannung gar nichts mehr sendest? Bricht sie dann auch ein?

Michael U. schrieb:
> I2C ist eigentlich sehr stabil, wird schließlich in fast allen
> Fernsehern, Radios usw. genutzt.
Bei diesem LCD koppeln die Impulse der Ladungspumpe stark auf die 
I²C-Leitungen ein (kann man auf dem Oszilloskop sehen), und das LCD hat 
100Ω Serienwiderstände in den Datenleitungen. Somit gibt es keinen 
richtigen Low-Pegel wenn das LCD "0" sendet, sondern nur eine Spannung 
die sich durch den Spannungsteiler von 100Ω und den Pullups ergibt. 
Außerdem sind auf dem PCB (nicht von mir gemacht...) SDA und SCL ca. 7cm 
lang und direkt nebeineinander und übersprechen gegenseitig. Da I²C 
keinerlei Fehlererkennung/Korrektur hat, ist das dann alles andere als 
stabil :-/ Man kann auf dem Oszilloskop sehen, wie das LCD oft 7 
reinkommende Bits als 8 Bits erkennt und dann beim 8. Bit schon "ACK" 
sendet, was dem I²C-Master vom Mikrocontroller gar nicht gefällt. 
Umgekehrt werden manchmal auch 9 Bits als 8 gezählt.
Ist mir ein Rätsel wie Leute sowas als Hausbus oder gar Fahrzeugbus ans 
Laufen kriegen.

J. D. schrieb:
> Hat jemand von euch mal U8glib ausprobiert?
Nö

Ich verwende momentan folgende Sequenz per I²C zum Initialisieren. Diese 
wird bei jedem Timeout/I²C-Busfehler/alle 200 Frames neu durchlaufen, 
denn das LCD erkennt regelmäßig fälschlicherweise Datenbytes als 
Befehle, die irgendwelche Parameter umstellen. Daher setze ich alle 
Parameter auf "richtig", auch wenn einige Werte die Standardwerte sind:

1

static uint8_t initSeq [] = {

2

  0xF1, 0x7F,  // Last COM Electrode

3

  0xF2, 0,  // Display Start Line

4

  0xF3, 0x7F,  // Display End Line

5

6

  0x81, 0x8F,  // Contrast

7

  0xC0, 0x02,  // View

8

9

  0xA3,    // Line Rate

10

  0x25,    // Temp Comp

11

  0xA9,    // Enable Display

12

  0xD1,    // Black & White Mode

13

14

  0x2B,    // Panel Loading

15

  0x2F,    // Internal Charge Pump active

16

17

  0x40,    // Scrolling

18

  0x50,    // Scrolling

19

  0x82, 0x13, 1, // Isolation Clock Front

20

  0x82, 0x14, 0, // Isolation Clock Back

21

  0x84,    // Partial Display Disable

22

  0x89,    // RAM Address Control

23

  0x90,    // Fixed lines

24

  0xA4,    // All Pixels Off

25

  0xA6,    // Don't invert image

26

27

  0xC8, 0,  // N-Line Inversion

28

  0xEA,    // Bias Ratio

29

30

  0xF4, 0,  // WPC0

31

  0xF5, 0,  // WPP0

32

  0xF6, 239,   // WPC1

33

  0xF7, 15,   // WPP1

34

35

  0xF8,    // Window Mode

36

};

Dieser Datenblock kann in einem Rutsch an die I²C Adresse für Befehle 
(je nach Adresspin-Belegung) gesendet werden (mach ich per DMA).
Keine Ahnung ob die alle so optimal sind, aber es funktioniert 
halbwegs...

Ja ich habe mal die einzelnen Kondensatoren gemessen:

Ich habe mein Programm so abgespeckt, dass nur noch der Constructor und 
die Einbindung der Library dort steht.

Jetzt wollte ich die Zip Datei vom Constructor hochladen. Scheint aber 
nicht zu gehen.