[Bug] ePaper FullRefresh Routine vermutlich fehlerhaft

[knickohr]

Platform

ESP32

Assembly

I did the assebly by myself

nRF24L01+ Module

nRF24L01+ plus

Antenna

circuit board

Power Stabilization

Elko (~100uF)

Connection picture

• I will attach/upload an Image of my wiring

Version

0.7.38 und davor

Github Hash

Blahblah

Build & Flash Method

ESP Tools (flash)

Setup

ePaper

Debug Serial Log output

No response

Error description

Wurde an der FullRefresh Routine des ePapers was verändert, ergänzt, optimiert ?

Mir ist aufgefallen das der FullRefresh beim Booten der DTU wesentlich schneller stattfindet. Das wäre eigentlich kein Problem, sogar wünschenswert, aber es entstehen dann häßliche „Ghostings“ auf dem Display. Der Hintergrund ist nicht mehr weiß, sondern grau, einige Pixel bleiben hängen und vor allem entsteht eine Art Wasserzeichen im Hintergrund. Das Ahoy-Logo erscheint eingebrannt 😲

Das Verhalten ist sein 2 oder 3 DEVs vorhanden. Kann leider den genauen Beginn nicht mehr sagen. Früher gestaltete sich der Refresh vom ePaper so das er im Sekundentakt mal schwarz, dann weiß, immer mit negativen Logo war. Ab diesem Zeitpunkt ist es eher ein wildes Flackern und das Logo bleibt im Hintergrund irgendwie hängen ☹️

Nach einigen manuellen Reboot scheint es vorübergehen gelöst zusein, bis zum nächsten Reboot 😱

[lumapu]

das muss an der eingesetzten library liegen, in Ahoy hat sich hier nichts geändert.

[HorstyS]

also, ich hab das bei mit nicht. sowohl nicht mit 0.7.26 oder .36

[knickohr]

Wir sind mittlerweile bei 38 !

[HorstyS]

korrekt, aber es wurde

Version
0.7.38 und davor

angegeben

[knickohr]

Ja, ich weiß nicht wann es angefangen hat. Es ist sogar schon eine 39 da 🤪

Ich teste die jetzt mal und wenn die bei mir auch buggy ist, gehe ich mal auf die 36 zurück.

[HorstyS]

und ich versuche mal die .39 ;)

[knickohr]

Ich bin jetzt zurück bis zur 0.6.9 😲 Und immer das gleiche Verhalten. So lange kann das noch nicht geändert worden sein 🤔

Hab die 39 jetzt drauf und soweit OK, muß halt aufpassen beim Booten. Seltsam finde ich das Verhalten schon, zumal es ja kein Einzelfall ist. Alle meine 3 DTUs haben das „Flattern“ am Anfang 😵

Mein.Film.mov

Früher war dieses Flattern eher ein gemütliches Pumpen im Sekundentakt.

Ich schätze mal @lumapu hat Recht, da wurde wahrscheinlich was an der Lib verändert 😪

[lumapu]

dann schauen wir doch mal die Änderungen durch, evtl. ist @dAjaY85 auch schon informiert?

[knickohr]

Er macht an der alten Lib nichts mehr. Hat doch irgendwo einen PR mit der neuen Original Waveshare Lib. Dazu muß aber Ahoy irgendwie umgekrempelt werden 😱 OpenDTU hat das schon drin.

[dAjaY85]

in OpenDTU ist immer noch die GxEPD2 integriert. Es wurde halt für die Displays ein eigener Task erstellt, damit dieser den gesamten SPI Bus nicht blockiert.

Zusätzlich ist in OpenDTU das ePaper Display nun als SW-SPI integriert.

Folgendermaßen:

In main hinter den includes:

void displayTask(void*);
TaskHandle_t displayTaskHandle;

in der setup-Schleife:
xTaskCreateUniversal(displayTask, "displayTask", 8192, NULL, 1, &displayTaskHandle, ARDUINO_RUNNING_CORE);

am ende der main:

void displayTask(void* pvParameters)
{
    CONFIG_T& config = Configuration.get();
    const PinMapping_t& pin = PinMapping.get();

    // Initialize Display
    MessageOutput.print("Initialize Display... ");
    Display.init(
        static_cast<DisplayType_t>(pin.display_type),
        pin.display_data,
        pin.display_clk,
        pin.display_cs,
        pin.display_reset,
        pin.display_busy,
        pin.display_dc);
    Display.setOrientation(config.Display_Rotation);
    Display.setEnablePowerSafe(config.Display_PowerSafe);
    Display.setEnableScreensaver(config.Display_ScreenSaver);
    Display.setContrast(config.Display_Contrast);
    Display.setLanguage(config.Display_Language);
    Display.setUpdatePeriod(config.Display_UpdatePeriod);
    MessageOutput.println("done");

    while (true) {
        Display.loop();
        yield();
    }
}

[knickohr]

Ich dachte Du hast das komplett umgekrempelt als das CMT rein kam und die Bildchen ? 🤔

Hast doch was von der Waveshare-Lib gesagt 🤪

[dAjaY85]

hatte kein Bock das ganze Layout neu zu machen, war mir nach paar Tagen zu viel Arbeit :-)

[knickohr]

Wurde an der GxEPD2 was verändert ? Update ? Ich kann mir dieses ehemals pumpen, jetzt flackern mit Wasserzeichen nicht erklären 😪

Hmmm, laut Git ist es immer noch die 1.5.2 von April 🤔

[dAjaY85]

liegt vermutlich an der Bearbeitungszeit, deswegen ist der Prozess in OpenDTU in einem eigenen Task.

[HorstyS]

also....ich habe jetzt die .39 seit gestern nachmittag. ich habe kein ghosting oder ähnliches auf meinem ePaper display. der refresh ist auch genauso wie mit den älteren versionen. auch mehrere reboots gestern produzieren das nicht.
just to mention...

[dAjaY85]

Hängt von vielen Faktoren ab, Anzahl WR etc. jede zusätzliche Komponente bremst die DTU ab.
Wie gesagt, wir hatten festgestellt, dass das Display den DTU Task um paar s bremst, weil während der Bearbeitung des Displays die NRF usw. nicht angesprochen werden.
Es wäre schon Sinnvoll die von @LennartF22 vorgeschlagene Implementierung auch in Ahoy umzusetzen.

Anbei der damalige PR: https://github.com/dAjaY85/OpenDTU/pull/1

[knickohr]

Kurios !!!

Mit der 0.7.40 ist es jetzt wieder besser 😱

[lumapu]

Habe gestern mein epaper auch wieder in Betrieb genommen (an Fusion Board). Ich habe auch kein ghosting gesehen, war allerdings auch die 0.7.40.

Ich habe bzgl. des Displays nichts geändert. @knickohr evtl. liegt es tatsächlich an der Tageszeit zu der du Ahoy neu startest.

[dAjaY85]

Naja Knickohr hat auch seine 12 WR dran.
Nicht das es ein Timing Problem ist.

[lumapu]

es geht ja eher zu schnell, nach deiner Theorie würde aber alles langsamer sein oder?

[HorstyS]

ja, ich habe eine einfache konfiguration mit nur einem WR an einem ESP32. das könnte natürlich der unterschied sein.

[dAjaY85]

Die Display Prozedur blockiert der main Task, das hatten wir Anfang dieses Jahres festgestellt, deswegen auch der eigene Task fürs Display.

[knickohr]

Habe gestern mein epaper auch wieder in Betrieb genommen (an Fusion Board). Ich habe auch kein ghosting gesehen, war allerdings auch die 0.7.40.

Moment !

Heißt das das das Fusion mit ePaper, nRF und Ahoy 0.7.40 wieder läuft ? Ab der 0.7.x hat es das nämlich nicht mehr gemacht 😲

(Er hat das nRF dann nicht mehr gefunden)

Edit :
Nein, geht nicht 😢 Entweder geht das nRF oder das Display. Beides gleichzeitig nicht. @lumapu wie hast Du das hinbekommen ? 🤔

[lumapu]

nein nicht mit ePaper aber das kommt hoffentlich bald

[knickohr]

Fixed ! 😎

Die Lösung findet ihr hier im Bild :

[knickohr]

Ich mache das wieder auf weil es sich immer mehr verhärtet das die Full-Refresh Routine doch fehlerhaft oder unvollständig zu sein scheint.

Wie ich darauf komme ?
Die DTU hat jetzt eine Uptime von mehreren Tagen und der Hintergrund des ePapers wird immer dunkler. Mit jedem Full-Refresh scheint etwas mehr grau im Hintergrund hängen zu bleiben. Kurioserweise ist an den Stellen sn denen ein Partial-Refresh stattfinden der Hintergrund schön weiß.

Meiner Meinung ist da was im argen 😕

[MetaChuh]

mein waveshare rev2.1 hat bis jetzt keine issues, auch ohne diode.

lustiges was mir aufgefallen ist (absolut irrelevant aber irgendwie faszinieeerend):

wenn die rotation 0° ist, und man den strom trennt, bleibt das e-paper bild 1:1 eingefroren wie es ist ... so wie erwartet ...
aaaaber: wenn die rotation auf 90° gestellt ist, und man dann den strom trennt, minimiert sich der kontrast des eingefrorenen bildes auf 50%, also verwaschen grauer.

ist voll wurst, aber faszinierend ...
hirnwichsen: im 90° mode erkennt man durch den hellen grauton statt schwarz, dass die spannung weg ist und alles inaktiv ist.
wenn dies auch bei 0° wäre, hätte ich gedacht es ist per design.
jetzt denke ich, per accidental "design" ist auch gut zum wissen und nutzen 😃

[knickohr]

Wo nimmst Du den Strom weg ? Am Display oder am USB. Den Effekt habe ich hin und wieder auch wenn ich das von USB nehme. Habe aber noch nicht darauf aufgepaßt ob es von der Rotation abhängt. Ich drehe 180 Grad.

[knickohr]

Ich mache hier mal wieder auf 😢

Es wird wieder schlimmer, trotz eingebauter Diode. Das „Eingrauen“ und Ghosting kommt ausschließlich nach einem Softboot. Boote ich kalt und warte vorher ein paar Minuten ist es wieder OK.

Deshalb @lumapu , bitte schnellstmöglich den FullRefresh beim Softboot unterdrücken (siehe Wunschliste, obsolet). Zumal mittlerweile 2 weitere User im Discord aufgetaucht sind, die ebenfalls von Ghosting-Problemen beim ePaper berichten 😱

[MetaChuh]

Wo nimmst Du den Strom weg ? Am Display oder am USB. Den Effekt habe ich hin und wieder auch wenn ich das von USB nehme. Habe aber noch nicht darauf aufgepaßt ob es von der Rotation abhängt. Ich drehe 180 Grad.

hi @knickohr
prosit neujahr und sorry für die späte antwort
(ist im trubel untergegangen bis zum re-opening)

ich hab's e-paper noch immer nur fliegend angestöpselt an einen esp32 d1 mini (die mag ich gerne, weil passt "pin kompatibel" rein, wo eigentlich ein esp 8266 d1 mini rein soll)

strom ist direkt auf der 3.3v leitung vom d1 board, sogar ohne extra cap.
nrf und e-paper werden beide vom onboard 3.3v wandler befeuert.
strom kommt von einem front usb port einer synology, oder einem normalen iphone ladeadapter (je nach dem was grad frei ist)

displaymäßig hab' ich keine troubles bis jetzt, aber das ist auch nur eine test dtu mit 0.6.9, die nicht stakkato über api abgefragt wird.

zum display greyout und stabilität kann ich nichts sagen, das teil rennt mit uralt firmware und dient nur dem zweck, dass ich schnell was am epaper testen konnte, also ahoy dtu damals drauf, und danach nie wirklich verwendet.

glg,
metachuh

[knickohr]

Ich glaube Dir das. Wenn Du das Display nur hin und wieder mal verwendest, dann funktioniert es.

[Tanakkara]

mit der 0.8.64

[knickohr]

Nein, das war schon weit vorher da, es tritt irgendwann mal auf, und dann geht es nicht mehr weg. Die Geister die ich rief …

[ich008]

v0.8.36

ist in den letzten 2 Wochen aufgetreten. Softwareupdate von v0.8.36 zu v0.8.114 über v0.8.83 brachte keine Abhilfe. Versuche mich nächste Woche mal am troubleshooting.

v0.8.114

[Loetnase]

Hallo Freunde der geisternden ePaper,

hier mal wieder ein Update von meinen Geistern. Ich habe einmal 3 ePaper zusammen gekauft,
eines kam gleich in Einsatz -> Aufkleber A (Auffällig) 79, das mit der längsten Betriebszeit, das steht in der Mitte.
das zweite etwas später in den Einsatz -> Aufkleber 78, steht rechts.
und das dritte mit blauem Rand erst zur Geistersuche vor kurzem im Einsatz.
Je nach verwendeter Softwareversion Ahoy zeigt das A 79 sehr schnell Geister, das 78 später und das ohne mit blauem Rand erst spät.
Das sagt mir, mit steigender Betriebszeit steigt die Geisteranfälligkeit, neue ePapers werden wohl zuerst keine Geister zeigen. @MetaChuh
Mit höheren Softwareversionen kommen die Geister auch schneller. Das ist auf den Bildern gut zu sehen, z.B. bei der 0.8.126 ist nach 13,5 Stunden alles begeistert.

Ich probiere gerade mal diverse Versionen rückwärts durch um vieleicht einen Startzeitpunkt zu finden.

Die uralte 0.6.0 hat nach über 6 Tagen Uptime zwar leichte aber akzeptable Geister. Ich habe da mal die Gehäuse gewechselt aber A ist immer A


Ich denke die ePapers werden da irgendwie langsamer und könnten längere Refreshzeiten gebrauchen.
Es macht auch einen Unterschied beim "cleanen" des ePapers ob man einen System -> Reboot macht oder oder Settings -> Save,
Settings save ist da besser, das ePaper ist da sauberer.
Es macht auch einen großen Unterschied die Versorgungsspannung für ca. eine halbe Stunde weg zu nehmen und dann zu starten wie @knickohr auch schon schrieb. Das lässt die Geister später kommen.
Ist da im Code irgendwo etwas einstellbar/veränderbar? Ich habe da leider keine brauchbare Ahnung von Software und kann da wohl nicht viel helfen.
Das ist die aktuell verwendete Treiberversion vom ePaper https://github.com/zinggjm/GxEPD2#1.5.3
Wenn aber jemand mit Ahnung da etwas machen kann aber kein geisterndes ePaper hat, einfach bitte melden.
Er oder sie kann gerne eine oder zwei komplette DTUs von mir bekommen, ich helfe da gerne.
Ich danke euch für eure Mithilfe und geleistete Arbeit.
mkG eure Lötnase

[semicuda]

Hi zusammen,

ich hatte auch das Problem mit Geisterbildern und immer weiter sinkendem Kontrast bei jedem Update - testweise habe ich nun mal (sehr amateurhaft) die Partial-Refreshs entfernt und damit das Problem ersteinmal gefixt. Läuft seither problemlos:

semicuda@cf715da

Cheers

[knickohr]

Etwas Erklärung bitte !
Wenn Du die Partial Refresh entfernt hast, dann schreibt es doch immer über die gleiche Stelle. Würde bedeuten das ein schwarzer Punkt nicht mehr gelöscht wird und im Laufe der Zeit das ganze Feld schwarz wird.

[semicuda]

Verstehe was du meinst - aber in dem Kontext bedeutet Partial Refresh, dass nur ein bestimmter Teil des Framebuffers (also des Bildschirminhalts im RAM) auf das Display geschrieben wird; der Rest bleibt stehen. Bei einem Full Refresh werden alle Pixel neu ins Display geschrieben, egal ob sie verändert werden oder nicht. Pixelzustände vom vorherigen Inhalt bleiben da definitiv nicht stehen.

Edit: eventuell dauern mit meiner Variante (ausschließlich Full Refreshs bei jedem Update) die Displayupdates einen Augeblick länger, und möglicherweise verschleißt das Display geringfügig schneller.

[knickohr]

Ja korrekt.

Man soll aber Full Refresh nicht so oft machen da anscheinend dort das Display scheller „ausgebrannt“ wird. Das es länger dauert ist klar. Was Du ja geschrieben hast. Doch mit Geistern ist das Display einfach unansehnlich 😢

[semicuda]

Eben - und das mit dem Ausbrennen ist mir jetzt ersteinmal egal, funktioniert und sieht gut aus.

[Loetnase]

Hallo Freunde der geisternden ePaper,

Ich möchte jetzt mal meine neueren Erkentnisse zu den ePapern weitergeben.
Ich bin ziemlich weit zurück gegangen und dann wieder schrittweise nach vorne, habe dann vor meinem Urlaub noch die 0.8.10-0.8.12 aufgespielt und nach etwas über 16 Tagen sahen die noch richtig gut aus.
Dann kam der nächste Dreierblock dran und ab 0.8.13 kommen die Geister wieder, ich habe dann mehrmals die Software auf den 3 Geräten gewechselt um die Hardware auszuschliesen.
Ich würde sagen bis 0.8.12 ist die Software i.O. und ab 0.8.13 starten die Geister.
Im Change Log der 0.8.113 ist da für mich nichts zum ePaper erkennbar.
Kann nur @lumapu die Unterschiede im Quelltext zwischen 0.8.12 und 0.8.13 bezüglich ePaper herausfinden oder ist da auch jemand anderes noch dazu fähig?
Vieleicht kann dann jemand damit eine Version mit einem Lösungsansatz erstellen, welchen ich dann sehr gerne wieder testen werde. Meine Softwarekentnisse sind da leider zu dürftig.

Ich denke die Abarbeitung dieses Geisterproblems sollte hier im Git erfolgen, wobei ich ab und zu ein paar Infos dazu auch im Discord bekannt geben würde.

[ich008]

Sehen kann die commits jeder. Das einzige zwischen 0.8.12 und 0.8.13 das mir jetzt bezüglich refresh ins Auge springt ist d3c0232
Der Rest ist eher Bildschirmschoner, neue Hardware und Zeichensatz kann natürlich auch noch irgendwas in einer Lib sein die jetzt nicht direkt hier im src geändert wurde.

[You69Man]

Hi all,
ich habe ja damals die Änderungen für die OLED Displays (screensaver, symbols...) gemacht, wollte aber eigentlich das ePaper gar nicht angreifen, da ich selbst keines zum Testen habe. Wie ich nun sehe, gab es aber offenbar einen kleinen Nebeneffekt auf das ePaper, indem der FullRefresh nun alle 480 x 5 Sekunden, anstatt wie vorher alle 480 x 10 Sekunden durchgeführt wird.

Ich kann mir das Fehlverhalten des ePaper Refresh rein vom Lesen des Sourcecodes zwar nicht wirklich erklären, zumal nämlich auch vorher schon bei neuen Inverter-Daten (mNewPayload) zusätzliche, azyklische ePaper refreshs durchgeführt wurden. Außerdem hatte Knickohr ja die Ghostings schon mit "0.7.38 und davor" gemeldet, also lange vor meinen OLED-Änderungen. Andererseits sind aber die sehr guten Tests von Lötnase nicht von der Hand zu weisen, das sieht eindeutig nach etwas Systematischem aus.

Ich hätte hier daher einmal einen Vorschlag für einen Fix (#1706), um die Wartung der im Timing doch recht unterschiedlichen OLED und ePaper Displays besser zu trennen, und wieder die ursprüngliche 10s Taktung des ePapers herzustellen. Ob die ePaper Phänomene damit komplett verschwinden würde ich bezweifeln, aber vielleicht treten sie damit wieder seltener auf.

Ein kleiner zusätzlicher Bugfix ist auch mit dabei (mEpaper.tickerSecond() und mEpaper.fullRefresh() wurden immer aufgerufen, auch wenn kein ePaper konfiguriert und initialisiert war, welche Auswirkungen immer das auch hatte...)

Bitte um Review (@lumapu) und Tests durch die ePaper Besitzer (kann es selbst leider wie gesagt nicht testen)!

[knickohr]

Ich glaube auch nicht das es daran liegt. Denn es gibt Versionen da funktioniert das ePaper besser und dann gibt es wieder Versionen wo es richtig übel ist.

Ich glaube eher da spukt was in den Takt des ePaper rein. Aber man weiß ja nie 😉

[Loetnase]

Ich denke es liegt auch etwas an der Betriebsdauer der ePaper, ich habe ja alle drei zusammen gekauft und hatte zuerst das mit dem Aufkleber (A) im normalen Betrieb, das zweite zum Ausprobieren, das dritte lag noch so in der Schublade.
Zuerst hat nur das A gegeistert, dann beim Spielen kam langsam das zweite dazu, zum Verifizieren kam dann des dritte auch noch in den Einsatz und das fing auch langsam an zu geistern. Jetzt geistern alle 3 zuverlässig bei den hohen Versionen.
Da spielen Alterung und Software zusammen.

Sobald jemand eine testbare Version gebacken hat, dürft ihr mir sagen wo ich die finde, die teste ich euch gerne.
Ich bin leider kein Held der Software um das selbst zu backen aber lasst es uns probieren.

[You69Man]

Ich habe hier (#1706) mal zwei Testversionen verlinkt (wroom32 und fusion)

[knickohr]

Die Hoffnung stirbt zuletzt 😁

Mit der 132 scheint das Problem endgültig behoben zu sein. Ich beobachte noch ein paar Tage 😉

[Loetnase]

Ich lass die 132 auch noch ein paar Tage laufen 🏃🏃🏃‍♀️
Dann hoffen wir mal, dass das keine Eintagsfliege war 😇