ahoy
ahoy copied to clipboard
lumapu
[Bug] ePaper FullRefresh Routine vermutlich fehlerhaft
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 😱
das muss an der eingesetzten library liegen, in Ahoy hat sich hier nichts geändert.
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.
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 😪
dann schauen wir doch mal die Änderungen durch, evtl. ist @dAjaY85 auch schon informiert?
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.
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();
}
}
Ich dachte Du hast das komplett umgekrempelt als das CMT rein kam und die Bildchen ? 🤔
Hast doch was von der Waveshare-Lib gesagt 🤪
hatte kein Bock das ganze Layout neu zu machen, war mir nach paar Tagen zu viel Arbeit :-)
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 🤔
liegt vermutlich an der Bearbeitungszeit, deswegen ist der Prozess in OpenDTU in einem eigenen Task.
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...
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
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.
Naja Knickohr hat auch seine 12 WR dran. Nicht das es ein Timing Problem ist.
es geht ja eher zu schnell, nach deiner Theorie würde aber alles langsamer sein oder?
ja, ich habe eine einfache konfiguration mit nur einem WR an einem ESP32. das könnte natürlich der unterschied sein.
Die Display Prozedur blockiert der main Task, das hatten wir Anfang dieses Jahres festgestellt, deswegen auch der eigene Task fürs Display.
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 ? 🤔
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 😕
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 😉
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 😉
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.
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.