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

[papa]

So wie ich das sehe, ist der Timeout, der zum Refresh des Displays gesetzt wird zu niedrig. Dadurch geht die CPU kurz vor dem Empfang der nächsten Nachricht in den Sleep.

Code: Alles auswählen

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

Einfach mal den DisplayRefreshWaitTime ordentlich erhöhen.
In Zeile 586 und Zeile 601 wird der Refresh übrigens fest auf 20ms gesetzt.

Hi papa,

der DisplayRefreshWaitTime ist auf 5sec eingestellt, daran kann es m.E. nicht liegen.
Schau dir noch mal das Bild
viewtopic.php?f=76&t=48153&start=450#p514407
an.
Die Burstserie kommt da relativ schnell, Zeitraum viel kleiner als 5sec, d.h. das Display antwortet lange Zeit nicht mehr, und nur weil im loop() code die Unterscheidung in Sleep/Idle drin ist.

Die Zeilen mit den 20ms sind m.E. in diesem Fall nicht relevant (Config Änderung und irgendein init glaub ich).

Das mag ja alles sein - aber irgendwas schaltet das Waiting vor eintreffen der nächsten Nachricht aus. Gib doch mal den Wert mit welchem der Alarm gesetzt wird aus.

[TomMajor]

Das mag ja alles sein - aber irgendwas schaltet das Waiting vor eintreffen der nächsten Nachricht aus. Gib doch mal den Wert mit welchem der Alarm gesetzt wird aus.

Ich habe den Alarmwert ausgegeben:

Code: Alles auswählen

  
    void setRefreshAlarm (uint32_t t) {
    DPRINT("a"); DDECLN(t);
    isWaiting(true);
    sysclock.cancel(*this);
    Alarm::set(millis2ticks(t));
    sysclock.add(*this);
  }

5000 wie erwartet denke ich.
Bilder zeigen die Debugausgaben und die Bursts/Telegramme dazu.

Meine Interpretation: Nachdem die erste Message kam und der Alarm auf 5000 gesetzt wird reagiert das ePaper auf keinerlei Messages von der Zentrale mehr, deswegen die vielen Bursts.
Erst nachdem die 5sec vorbei sind und isWaiting wieder auf false ist (Ausgabe "s0") kommt wieder genau eine Message durch, Alarm geht auf 5000 und das Spiel beginnt von vorn.
Aber warum, die loop Schleife sollte doch das device während der Zeit nur in den Idle senden und nicht alles blockieren.

Hier noch mal als Referenz der aktuelle sketch zu den Bildern:
https://www.dropbox.com/s/g27y8xqo1ugh0 ... 1.ino?dl=0
.

ScreenShot 96 COM6.png (6.03 KiB) 1314 mal betrachtet

[papa]

Ich komme leider an Deinen Sketch nicht ran, da Dropbox einen Login haben will.
Aber zurück zum Problem. Am besten nochmal ganz systematisch von vorne. Könntest Du bitte ein zweites unabhängiges Gerät die Nachrichten aufzeichnen lassen. Bitte ohne Idle - dann haben wir auch ordentliche Zeitstempel.
Außerdem bitte noch in Radio.h die Zeilen 620 & 621 rein nehmen. Dann sehen wir jedes empfangene Paket. In Device::pollRadio auch. Vielleicht geht es ja irgendwo verloren
Die Ausgabe in Activity.h Zeile 26 könnte auch hilfreich sein.

[TomMajor]

Ich komme leider an Deinen Sketch nicht ran, da Dropbox einen Login haben will.
Aber zurück zum Problem. Am besten nochmal ganz systematisch von vorne. Könntest Du bitte ein zweites unabhängiges Gerät die Nachrichten aufzeichnen lassen. Bitte ohne Idle - dann haben wir auch ordentliche Zeitstempel.
Außerdem bitte noch in Radio.h die Zeilen 620 & 621 rein nehmen. Dann sehen wir jedes empfangene Paket. In Device::pollRadio auch. Vielleicht geht es ja irgendwo verloren
Die Ausgabe in Activity.h Zeile 26 könnte auch hilfreich sein.

Hi papa,

normalerweise kann man bei dropbox sagen, nein, kein Konto, direkter download, steht ganz unten im popup.
Aber egal, ich habe den sketch nochmal angehängt, k.A. warum ich das gestern nicht gleich gemacht habe.
Extension auf .h geändert wegen Forum Dateianhang Beschränkung.

Bin nicht sicher ob ich alles verstehe was ich machen soll. Ein weiteres, beliebiges AskSinPP Gerät um alle Messages zu sehen die so unterwegs sind, quasi ein Monitor?
Und du meinst für diesen Monitor ohne Idle weil sonst Messages verpasst werden bzw. die Timestamps nicht stimmen.

Und der Monitor soll die Modifikationen in Radio.h und Activity.h bekommen oder das ePaper?
Device::pollRadio komplett unklar was zu tun ist, da ist kein code den ich auskommentieren könnte.

Und dann den Test mit ePaper/isWaiting Version, die nicht funktioniert (im Anhang) und messages von ePaper und Monitor loggen, also mit zwei seriellen Monitoren parallel?

Danke,

[papa]

Bin nicht sicher ob ich alles verstehe was ich machen soll. Ein weiteres, beliebiges AskSinPP Gerät um alle Messages zu sehen die so unterwegs sind, quasi ein Monitor?

Genau. Ich würde gern mal alles sehen, was da hin und hergeschickt wird - inklusive der Zeitstempel. Das geht nur mit einem separaten Spion.

Und du meinst für diesen Monitor ohne Idle weil sonst Messages verpasst werden bzw. die Timestamps nicht stimmen.

Ja - Idle macht den Timer aus. Dann stimmen die Zeitstempel nicht mehr.

Und der Monitor soll die Modifikationen in Radio.h und Activity.h bekommen oder das ePaper?
Device::pollRadio komplett unklar was zu tun ist, da ist kein code den ich auskommentieren könnte.

Nein - die Modifikationen sollen in den ePaper.

Code: Alles auswählen

bool pollRadio () {
    uint8_t num = radio().read(msg);
    DPRINT("PollRadio: Msglen=");DDECLN(num);
    if( num >= 10 && isDeviceID(msg.from()) == false ) {

Und dann den Test mit ePaper/isWaiting Version, die nicht funktioniert (im Anhang) und messages von ePaper und Monitor loggen, also mit zwei seriellen Monitoren parallel?

Genau - die Logs von beiden. Dann sehen wir hoffentlich, wie das alles zusammen hängt.

[TomMajor]

Hallo papa,
alles klar, mache ich, kann 1-3 Tage dauern bis ich dazu komme, ist momentan zeitlich alles etwas eng.
Ich würde den aktuellen V4 Branch für die Tests nehmen denke ich.

[papa]

Passt

[TomMajor]

@papa
ich musste bei der PollRadio Debug msg mit if (num) kapseln da sonst der Log relativ schnell mit Messages wo num = 0 ist voll wurde.

Code: Alles auswählen

    if (num) {
      DPRINT("PollRadio: Msglen=");DDECLN(num);
    }

Die aktuellen Änderungen:

.
Sonst bin ich soweit durch, die Logs folgen gleich.

[TomMajor]

Ok, ich hoffe ich habe den Fehler gut loggen können. Verhalten wie gehabt, nach der ersten Msg scheint das ePaper in eine Art Blocking zu gehen und nimmt keine Messages an.
Ich vermute für den Zeitraum 5sec wo isWaiting auf true steht. Deswegen die vielen Burst Versuche der Zentrale.
Bin gespannt ob es damit etwas klarer wird
.

[papa]

Leider nicht wirklich. Mach mal das "Go Sleep" wieder weg. Das bringt nicht viel - sieht soweit logisch aus. Dafür mal würde ich gern wissen, wie der IdleState des Radio ist. Bitte mal folgende Ausgaben einbauen:

Code: Alles auswählen

    // VAR1
    DPRINT("Radio: ");DDECLN(hal.radio.isIdle());
    if (ePaper.isWaiting() == false) {
      hal.activity.savePower<Sleep<>>(hal);
 

Und die Ausgabe in Radio.h Zeile 739 mal aktivieren.