HB-Dis-EP-42BW - 4.2" ePaper Display

[jp112sdl]

Glaub schon. Sollte gehen

[TomMajor]

Es erfolgt jedes Mal ein Burst.

EDIT:
Habs mal mit nem Batterieaktor getestet und diesen mit einer Reihe von Schaltbefehlen belästigt... So lange der wach ist (savePower<Idle>), scheint es tatsächlich kein erneutes Burst zu geben

Belasse ich den Batterieaktor im savePower<Sleep> scheint dieser jedoch unmittelbar nach Empfang einer Nachricht wieder schlafen zu gehen, so dass jeder Schaltbefehl mit einem Burst gesendet wird.

Müsste man sich vielleicht doch mal mit nem DVB-T Stick anschauen.
Oder Debug einbauen, wo WOR detektiert wird.
Ich traue den Logausgaben vom RFD nicht ganz.

Danke für die Infos.
Mit SDR anschauen wäre eine Idee.
Ist es korrekt das ePaper in den sleep geht wenn es auf die restlichen Telegramme bzw. DISPLAY_REFRESH_WAIT_TIME wartet?

Code: Alles auswählen

        uint16_t rtime = this->getList0().displayRefreshWaitTime() * 100;
        ePaper.setRefreshAlarm(rtime);

Falls ja und man das in Idle ändern könnte würde das ziemlich Duty Cycle beim ePaper sparen, oder?

BTW, wieder mal ein cooles Teil, der AskSinAnalyzer Respekt vor deiner Produktivität.

[papa]

Die Messageverarbeitung in MultiChannelDevice führt nach jeder erfolgreichen Kommunkation ein stayAwake mit 500ms aus (Zeile 466). Du kannst ja mal den Wert auf 1s erhöhen und schauen, ob das denn weniger Bursts ergibt.

[TomMajor]

Die Messageverarbeitung in MultiChannelDevice führt nach jeder erfolgreichen Kommunkation ein stayAwake mit 500ms aus (Zeile 466). Du kannst ja mal den Wert auf 1s erhöhen und schauen, ob das denn weniger Bursts ergibt.

Schau ich mir mal am WE an wenn ich das SDR aufgesetzt und bedienen kann, habe ich bis jetzt noch nicht gemacht. Wenn das geht sehe ich mir mal die Bursts an.

[jp112sdl]

Also es wird tatsächlich nur 1x Burst ausgesendet.
So lange das Display wach ist, empfängt es auch mehrere Telegramme

[TomMajor]

Das sieht gut aus, vielen Dank für die Info!
Also haben wir keinen Handlungsbedarf bezüglich Burst Optimierung beim ePaper.

Habe mir SDRSharp geladen aber den Stick noch nicht installiert, hatte ich noch vor. Frage mich ob ich die Bursts damit überhaupt auflösen/sehen kann, werde berichten falls ja.

[jp112sdl]

In CubicSDR kann man Bursts schön sehen, da sie mit ~300ms doch sehr lang sind ggü. normalen Telegrammen mit ~30ms

[TomMajor]

ok, habe SDRSharp am Laufen (CubicSDR ging leider unter Windows gar nicht, hängt sich reproduzierbar bei der Device Auswahl auf, eventuell teste ich es noch mal demnächst auf dem Mac).

Die Bilder zeigen das Displayupdate des ePaper, das erste als 2 Lines upgedatet wurden, das zweite mit 6 Lines.

Beim ersten Bild ist die Scrollspeed des Waterfall Diagramms auf Maximum (und damit die zeitliche Auflösung), beim zweiten nicht, deswegen sind die Balken beim ersten höher.
Irgendwie beschleicht mich das Gefühl dass die dicken Balken die Bursts sind und dass doch mehr geburstet wird als die vorigen Antworten hier im Thread vermuten lassen

Refresh Wartezeit des ePaper liegt bei 5sec.
.

[jp112sdl]

Hab grad mal mit Cubic reingehört.
Hatte 2 Bursts bei komplettem Screen-Refresh (wobei das ja bei mir nicht viel ist, bis auf Temperaturwert und Datum nur Fixtexte).

[TomMajor]

Hab grad mal mit Cubic reingehört.
Hatte 2 Bursts bei komplettem Screen-Refresh (wobei das ja bei mir nicht viel ist, bis auf Temperaturwert und Datum nur Fixtexte).

Könntest du bitte mal bei Gelegenheit zum Vergleich einen screenshot posten wie das ePaper Screen-Refresh bei Cubic aussieht?
Um mal zu sehen ob es da mehr Infos gibt.
Hast du auch ca. 4 Telegramme zwischen den Bursts?