[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 😵

https://github.com/lumapu/ahoy/assets/63048210/a4347595-4ee3-4afd-b30a-c3ee4939e3ab

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 😕

[knickohr]

Was gibt’s Neues ?

Nun ja, nach 2 Wochen Testbetrieb mit einer Diode in der Versorgungsspannung muß ich berichten das es jetzt zu funktionieren scheint. Ich habe eine alte Germaniumdiode (AA119) genommen weil die einen sehr geringen Spannungsabfall von nur ca. 0,15V hat. Ja, das Ding ist alt und kann nicht viel ab, aber offenbar reicht es aus.

Das würde auch meine Vermutung bekräftigen das es nicht das Display selbst und vermutlich auch die die Refresh-Routine ist, sondern das hier wohl was anderes im Argen ist. Den Verdacht habe ich schon länger das der Strom nicht vom Display benötigt wird, sondern in der restlichen Schaltung gebraucht wird. Nun stellt sich für mich die Frage was beim Refresh noch alles nebenher läuft, bzw. gerade zu diesem Zeitpunkt aktiv ist, das die Spannung runter zieht ?

Ich werde weiter beobachten 😉

[MetaChuh]

hab' mir grad das e-paper display zum testen bestellt, und bin jetzt schon dankbar für deine vorab infos 👍 wird etwas dauern, bis ich zum testen komme, weil ich wechsle gerade alle esp8266 gegen die form factor und pin kompatiblen esp32 d1 mini module von az.....y und in den ferien der kids bleibt nur noch die zeit, wenn alle schlafen und ich selbst noch nicht zu ko bin 😉

[knickohr]

Das Problem vom ePaper ist momentan nur ein Einzelfall. Bis jetzt hat noch niemand auch nur ähnliche Probleme gehabt. Es ist nicht hardwareabhängig da ich mit mehreren unterschiedlichen Konfigurationen getestet habe. Ich schätze mal, es ist Alterungs- oder Laufzeitproblem. Da ich das Display seit den allerersten Tests quasi rund um die Uhr am Laufen habe. Kurioserweise scheint das Verhalten nicht das Display selbst auszulösen, sondern etwas von der anderen Hardware. Vielleicht ist es ein ähnlicher Effekt wie beim NRF-Modul und dem Elko. Oder die Library hat doch einen Schuß ? 🤔

Es ist auch noch nicht sicher ob es nicht irgendwann wieder auftritt. Das wäre aber dann der Beweis das es mit der Alterung des Displays zu tun hat. Deshalb lasse ich auch vorerst mal hier auf.

[knickohr]

Nach weiteren 2 Wochen und etlichen Reboots mache ich jetzt zu. Das Problem ist seither nicht mehr aufgetreten.

Die Lösung war anscheinend die Diode. Ob der Kondensator zusätzlich notwendig ist, weiß ich nicht, aber schaden tut er auch nicht.

[MetaChuh]

@knickohr danke für die info 👍 ps: bei mir liegt das e-paper display seit 2 wochen auch aus zeitmangel noch originialverpackt da 🙈

plus ich finde meine alte germanium diode nicht, die ich 100pro noch irgend wo aus einem kosmos elektronikbaukasten der 80er habe.

also nicht wundern, wenn in den nächsten paar jahren in diesem issue aus heiterem himmel steht: ha ich hab die diode endlich gefunden 😂

glg und danke dir für die infos 👍

[knickohr]

Nachtrag hierzu :

Mir is5 vor ein paar Tagen die Germaniumdiode hops gegangen. Keine Ahnung warum. Vielleicht weil sie schon zu alt war oder aber das Display zieht doch hin und wieder mal mehr als 20mA Strom.

Egal, es ist jetzt eine BAT43 drin und die tut auch wunderbar, verträgt jetzt 200mA.

[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:

https://github.com/semicuda/ahoy/commit/cf715da282b72ee14e72d454aba34935ff291555

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.