erste Version am 28.01.2017
letzte Änderung am 31.01.2017

ESP8266-12 - Seite 3

ein paar Messungen zum Stromverbrauch

Um die Stromaufnahme von dem ESP-12E messen zu können, muss ich das Multimeter natürlich irgendwie zwischen den Ausgang des 3,3V-Reglers und den Chip bekommen. Grrrr..... Also nochmal löten....
Erst wird die Plus-Leitung hinter dem Regler aufgetrennt und mit zwei Lötnägeln auf die Leiterplatten-Oberseite gebracht. Nun noch ein kurzes Stück Litze mit je einer Lötöse an beiden Enden versehen und damit die passende Überbrückung anfertigen. Statt der Überbrückung kann jetzt ebenso ein Amperemeter zwischengeschaltet werden.

Das Multimeter zeigt 70mA beim Blink-Sketch an. Und zwar ohne die LED.
Eigentlich hatte ich ja eher 15mA erwartet. Irgendwo glaube ich nämlich gelesen zu haben, dass der "modem-sleep" automatisch eingestellt wird, wenn keine WLAN-Kommunikation erfolgt.... war wohl falsch.

Also wird nochmal das (bereits auf der ersten Seite verlinkte) Power-Saving-Video aufgerufen.
Wie im Video gesagt, bringt ein WiFi.mode(WIFI_OFF) in setup() auch bei mir noch keine sonderliche Verbesserung, erst mit WiFi.forceSleepBegin() geht der Stromverbrauch auf 13,7mA runter.
Beim Hochladen eines Sketches zieht der ESP-12E übrigens 58mA. Oder 15mA, wenn er vorher mit forceSleepBegin gelaufen ist.

Nun deepSleep. Dazu ist GPIO16 mit RST zu verbinden.
Der Aufruf erfolgt mittels ESP.deepSleep(1000*1000*10, WAKE_RF_DISABLED) für 10 Sekunden Tiefschlaf.
Während des Tiefschlafs zieht die Schaltung -wie erwartet- 16µA.
Allerdings habe ich noch keine Idee, wie ich mit meinem Equipment jetzt die Aufwach-Dauer messen könnte. Mit einem Zwei-Kanal-Speicher-Ozzi könnte man vielleicht die Zeit zwischen steigendem Stromverbrauch und Pegelwechsel an einem Pin messen. Aber den Stromverbrauch mit einem Ozzi zu messen, ist auch nicht ganz ohne.
Mit einem extrem kurzen Tiefschlaf könnte ich es vielleicht messen.
Also etwa eine Endlosschleife über: Pin5=HIGH, 1µs Tiefschlaf, Pin5=LOW, 1µs Tiefschlaf.
Und mit einem Ozzi dann an Pin5 ran.
Wobei das nix werden wird. Schließlich ist das Aufwachen aus dem Tiefschlaf praktisch ein Reset.
Also eher: setup(){Pin5=OUTPUT; Pin5=HIGH; 1µs Tiefschlaf}
Wenn ich das laufen lasse, blinkt die LED ziemlich flott. Dreimal pro Sekunde könnte hinkommen.
Um es genau zu wissen, müsste ich mein "gar-nicht-sooo-billig-USB-Ozzi" vorholen, die gammlige Windows-VM mit der Ansteuerungs-Software starten, wahrscheinlich (wie bisher immer) zig Einstellungen probieren, bis das Ding endlich mal tut, was ich will.....
Aber muss ich das eigentlich wirklich selbst messen...!?
Da sich meine bisher gemessenen Daten vollständig mit denen decken, die andere Leute gemessen haben, glaube ich einfach mal, dass dies bei den 300ms Aufwach-Zeit ebenfalls zutreffen würde.

Und damit kann ich deepSleep nicht gebrauchen - zumindest nicht für den Zweck, den ESP-12E als alternative Plattform für meinen Helligkeits und Temperatur-Logger einzusetzen.

Also "light sleep". Hier steht recht viel zu dem Thema.
Mit diesem Sketch konnte ich dann auch was sehen:

#include <ESP8266WiFi.h>
extern "C" {
#include "user_interface.h"
}

#define LED 5

void setup() {
Serial.begin(115200);
pinMode(LED, OUTPUT);
WiFi.begin("FreifunkWees01.2 (http://ffw)", "");

while (WiFi.status() != WL_CONNECTED) {
    delay(100);
    Serial.print(".");
}
}

void loop() {
wifi_set_sleep_type(LIGHT_SLEEP_T); // light sleep
delay(10000);                        // für 10 Sekunden
digitalWrite(LED, HIGH);             // LED an
delay(1000);
digitalWrite(LED, LOW);              // LED aus
delay(1000);
}

Was ich sehe, ist, dass der Strom tatsächlich gelegentlich bis auf 1,2mA runter geht. Aber nur kurz. Gelegentlich geht er dafür auch bis zu 67mA hoch. Und zwar deutlich häufiger, als im 10-Sekunden-Takt.
Das temporäre Anklemmen von einem SuperCap mit 0,1F (zwischen GND und Vcc vom Chip) hat sonderbarerweise keinerlei Auswirkungen gehabt.

das RTC+EEPROM-Modul abfragen

Weil ich mit dem Stromverbrauch von dem Ding erstmal nicht weiterkomme, will ich mal schauen, wie es denn bzgl. der Kommunikation mit externen Komponenten aussieht. Da bietet sich das RTC-Modul an. Also I2C. Der nötige Code ist schnell zusammen-kopiert aus Logger:

#include <Wire.h>

#define DS3231_ADR 0x68 // I2C-Adresse der RTC
#define AT24C32_ADR 0x57 // I2C-Adresse des EEPROM (bei A0-A2 offen == Default)

struct RTCdata {
unsigned long year   : 6; // funktioniert bis 2063, danach ;-) statt 2000 einfach 2064 addieren
unsigned long month : 4;
unsigned long day    : 5;
unsigned long hour   : 5;
unsigned long minute : 6;
unsigned long second : 6;
};

RTCdata getRTC(void) {
RTCdata t;

Wire.beginTransmission(DS3231_ADR);
Wire.write(0);                      // Register(0) (Seconds)
Wire.endTransmission();
Wire.requestFrom(DS3231_ADR, 7);    // 7 Byte holen
t.second=bcd2dec(Wire.read())&0x3F; // Seconds
t.minute=bcd2dec(Wire.read())&0x3F; // Minutes
t.hour =bcd2dec(Wire.read())&0x1F; // Hours
Wire.read();                        // Day weglesen
t.day   =bcd2dec(Wire.read())&0x1F; // Date
t.month =bcd2dec(Wire.read())&0x0F; // Month
t.year =bcd2dec(Wire.read())&0x3F; // Year
return(t);
}

void printRTC(RTCdata t) {
Serial.print(2000+t.year); Serial.print("."); Serial.print(t.month);   Serial.print("."); Serial.print(t.day); Serial.print(" ");
Serial.print(t.hour, DEC); Serial.print(":"); Serial.print(t.minute, DEC); Serial.print(":"); Serial.print(t.second, DEC);
}

void setup() {
Serial.begin(115200);
Wire.begin(0, 2); // SDA, SCL
}

void loop() {
RTCdata t;
t=getRTC();
printRTC(t);
Serial.println();
delay(1000);
}

byte dec2bcd(byte val) { return((val/10*16)+(val%10)); }
byte bcd2dec(byte val) { return((val/16*10)+(val%16)); }

Die einzige Erweiterung sind praktisch die Parameter bei Wire.begin(). Beim Arduino bzw. ATmega328 waren hier nur die Analog-Pins 4 und 5 möglich, beim ESP-12E sollen es laut ESP8266 Technical Reference Kapitel 9.1 alle GPIO-Pins sein. Zumindest verstehe ich den Satz "All GPIO pins can be configured with open-drain mode, thus easily enabling GPIO interface for I2C data or clock functionalities." so.

Wolln mal testen.
Mit Wire.begin(14, 16) gehts schon mal nicht. Wire.begin(16, 14) auch nicht.
Bei Wire.begin(12, 13) kommt das aktuelle Datum+Zeit.
Wire.begin(12, 14) klappt ebenfalls.
Wire.begin(12, 16) nicht. Also scheint GPIO16 schon mal Probleme mit I2C zu haben.
Wire.begin(4, 5) geht wieder.
Wire.begin(0, 2) auch und Wire.begin(2, 0) ebenfalls.
Und zu guter Letzt noch Wire.begin(2, 15): klappt mit Einschränkung... GPIO15 darf erst nach Upload gesteckt werden, sonst gibt es Mecker in der IDE:

warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed

Fazit: alle Pins außer GPIO16 lassen sich für I2C verwenden.
Durchsucht man die Technical Reference speziell nach GPIO16, findet man sofort die Aussage: "Different from other IO interfaces, GPIO16(XPD_DCDC) belongs to the RTC module instead of the general GPIO module. It can be used to wake up the chip during deep-sleep; it can be configured to input or output mode; but it cannot trigger the IO interrupt."
Na denn.... muss man halt wissen.... blöde Sache, wenn man das nicht weiß. Hoffentlich lauern nicht noch [viel] mehr von solchen Fallen in den Abgründen des Chips. Ich werde die 117 Seiten deswegen jetzt trotzdem garantiert nicht auswendig lernen.

Nutzung vorhandener DC-Stromquellen

Gestern Abend hatte ich die glorreiche Idee, dass es ja nicht die 15mA Stromverbrauch bei 3,3V sind, die mich an dem Ding stören. Es ist vielmehr das Steckernetzteil, das mich stören würde - und das ich deswegen bräuchte, weil sich die Schaltung nicht hinreichend lange über Akku betreiben läßt.
Hätte ich allerdings eine DC-Stromquelle, die ohnehin da ist, sähe die Sache schon ganz anders aus.
Und......
Im Büro habe ich meinen 11W-PC, der 24*7 läuft. Und der hat noch freie USB-Ports.
Im Schlafzimmer ist der Fernseher dauerhaft mindestens auf Standby (mit 0.2W), der hat ebenfalls zwei ungenutzte USB-Ports.
Nur in der Küche gibts [bisher] kein Device mit "eh da 5V". Würde ich die Position des WLAN-Routers um einen halben Meter verändern, stünde der nicht mehr im Wohnzimmer, sondern in der Küche. Andererseits wäre dann eine Wand mehr zwischen WLAN-Router und Garten.... mal schauen.

DS18B20 und LDR abfragen

Dann will ich mal testen, wie ich meine zwei Sensoren per ESP-12E abfrage.
Ich fange mit dem LDR am ADC-Pin an.
Erstmal muss man rausfinden, dass der ADC-Pin nur Spannungen bis 1V messen kann.
In den ganzen PDF's von Espressif habe ich nix dazu gefunden. Hier stand dann was ... und mit dem Wissen versteht man dann endlich auch die ADC-Beschaltung des WeMos D1 mini. Somit ergibt sich folgendes Schaltbild:

Dann muss man noch rausfinden, wie der ADC-Pin im Programm abgefragt wird. Zum Glück hatte ich ja schon ein bischen bei der Zuordnung der Pins zu symbolischen Namen gestöbert. Also A0 oder 17 ist der gesuchte Pin.
Das Test-Sketch ist trivial:

void setup() {
Serial.begin(115200);
}

void loop() {
Serial.println(analogRead(A0));
delay(1000);
}

Allerdings bekomme ich den Messwert nicht unter 11. Selbst dann nicht, wenn ich die Verbindung zu Vcc trenne.
Lege ich den ADC-Pin mit einer 16cm langen Strippe direkt an Masse, bekomme ich Werte zwischen 8 bis 15.
Theoretisch könnte das auch an meiner Schaltung liegen. Also etwa Blips auf Vcc. Ein Elko mit 2200µF zwischen Vcc und GND ändert jedoch nix.
Ein genauer passendes Verhältnis der Widerstände des Spannungsteilers (korrekt wären 230KΩ und 100KΩ) wird auch nix daran ändern, dass 0V nicht 0 ergibt. Ähnliches zeigt sich beim WeMos D1 mini. Dessen Werte pendeln zwischen 2 und 3, wenn AB an GND liegt und zwischen 980 und 984, wenn AB an +3,3V liegt. Letzteres wird nun allerdings schon hauptsächlich am falschen Widerstandsverhältnis liegen - also das nicht 1023 gemeldet wird.
Wieder an meiner Schaltung: ADC-Pin direkt an +3,3V bzw. Vcc liefert 1024.
Dolle Sache....also dafür, dass das ein 10-Bit-ADC sein soll... Ob das ein Bug in der Core-Lib sein sollte!?
Eher nicht. In core_esp8266_wiring_analog.c wird lediglich das Ergebnis von system_adc_read() zurückgeliefert.
Das wird -wenig erhellend- in core_esp8266_phy.c in Kommentaren referenziert und im SDK in user_interface.h als
uint16 system_adc_read(void);
deklariert. Wie auch immer diese Funktion gebaut sein mag....ihr Rückgabewert geht über 10 Bit hinaus.
Na denn....geht schlecht, aber geht.

Jetzt also der DS18B20. Die Beschaltung des Chips ist hier dabei.
Pin1 geht an GND, Pin3 an Vcc, Pin2 braucht einen 4,7KΩ-Pullup, ansonsten ist keine weitere Hardware nötig.
Die Software wird wieder einfach von Logger zusammenkopiert:

#include <OneWire.h>

#define MAX_SENSOR_COUNT 2   // maximale Anzahl der Sensor-Paare
#define DS18B20_DATA_PIN 13 // OneWire-Data-Pin

byte ROMcode_g[MAX_SENSOR_COUNT][8];           // ROM-Codes der DS18B20
byte sensor_count_g;                           // die Anzahl der Sensor-Paare

OneWire ds18b20(DS18B20_DATA_PIN);

char discoverOneWireDevices(void) {
sensor_count_g=0;
while(ds18b20.search(ROMcode_g[sensor_count_g])) {
    if(OneWire::crc8(ROMcode_g[sensor_count_g], 7)!=ROMcode_g[sensor_count_g][7]) {
      return(0);
    }
    sensor_count_g++;
    if(sensor_count_g>=MAX_SENSOR_COUNT) { // mehr als zwei Sensor-Paare sind nicht vorgesehen
      break;
    }
}
ds18b20.reset_search();
return(1);
}

int readDS18B20_CRC(byte ROMcodeIdx) {
static byte scratchpad[9];

for(int i=0; i<3; i++) { // maximal 3 Versuche, einen Wert mit korrekter CRC zu lesen
    ds18b20.reset();
    ds18b20.select(ROMcode_g[ROMcodeIdx]);
    ds18b20.write(0x44); // This command initiates a single temperature conversion
    //delay(750);
    ds18b20.reset();
    ds18b20.select(ROMcode_g[ROMcodeIdx]);
    ds18b20.write(0xBE); // Read Scratchpad
    for(int j=0; j<9; j++) {
      scratchpad[j]=ds18b20.read();
    }
    if(scratchpad[5]==0xFF && scratchpad[7]==0x10 && OneWire::crc8(scratchpad, 8)==scratchpad[8]) {
      // Was für ein beschissener CRC. Wenn man die Verbindung zur DQ-Leitung zieht, kommt 9x 0x00 zurück.
      // Und 9x 0x00 führt zu OneWire::crc8()==0 - passt also zu scratchpad[8] und ist damit
      // in diesem Fall vollkommen wertlos.
      // Daher werden zusätzlich die Byte 5 und 7 geprüft, die laut Doku "Reserved" und ab Werk
      // mit den Werten 0xFF bzw. 0x10 vorbelegt sind.

      // Für Byte 0 und 1 gilt:
      // BIT    15 14 1 1 11 10 09 08 07 06 05 04   03   02   01   00
      //        S S S S S 2^6 2^5 2^4 2^3 2^2 2^1 2^0 2^-1 2^-2 2^-3 2^-4
      return((scratchpad[1]<<8)|scratchpad[0]);
    }
}
return(0x8FFF); // Fehlerkennung (0x8FFF kann nicht als Temperatur-Wert vorkommen)
}

void setup() {
Serial.begin(115200);
discoverOneWireDevices();

}

void loop() {
Serial.println(readDS18B20_CRC(0)/16.0);
delay(1000);
}

Das hat direkt nach dem ersten Upload funktioniert.
Es wird eine Temperatur von 18.62 °C gemeldet. Das könnte hinkommen und deckt sich zusätzlich mit der Außentemperatur-Anzeige meiner Lüftersteuerung im Rechner.
Kurz den Chip angefasst und direkt gehen die Werte hoch. Also....passt.

Tests zur Genauigkeit der Uhr im ESP-12E

Wenn ich nicht ganz so sehr auf minimalen Stromverbrauch achten muss bzw. die "System clock" konstant laufen lasse, kann ich vielleicht das RTC+EEPROM-Modul einsparen.
Auf das EEPROM als Massenspeicher kann ich beim ESP-12E getrost verzichten - der hat genug RAM.
Und wenn die eingebaute Uhr immerhin so präzise liefe, dass sie pro Tag höchstens ein paar Sekunden falsch ginge, bräuchte ich auch den DS3231-RTC-Chip (der ja immerhin Temperatur-Schwankungs-kompensiert ist) nicht.
Laut ESP8266 Low Power Solutions Table 1-1 bleibt beim Sleep-Mode "modem-sleep" alles außer WiFi eingeschaltet. Somit auch die "System clock". Einmal täglich würde ich die sowieso gemäß NTP stellen.

Für einen ersten Test habe ich mal obiges DS3231-Sketch etwas modifiziert:

long millis_base;
long sec_base;

void setup() {
RTCdata t;
millis_base=millis();
Serial.begin(115200);
Wire.begin(2, 0); // SDA, SCL
t=getRTC();
sec_base=t.second+t.minute*60+t.hour*60*60;
}

void loop() {
static long sec, mil;
static RTCdata t;

t=getRTC();
printRTC(t);
Serial.print(" ");
sec=t.second+t.minute*60+t.hour*60*60;
Serial.print(sec-sec_base);
Serial.print(" ");
mil=millis()-millis_base;
Serial.print(mil/1000);
Serial.print(".");
Serial.print(mil%1000);
Serial.println();
delay(1000);
}

Das liefert im Terminal sowas hier:

2017.1.29 12:5:56   0   0.3
2017.1.29 12:5:57   1   1.4
2017.1.29 12:5:58   2   2.6
2017.1.29 12:5:59   3   3.7
2017.1.29 12:6:0   4   4.8
2017.1.29 12:6:1   5   5.9
2017.1.29 12:6:2   6   6.10
2017.1.29 12:6:3   7   7.11
2017.1.29 12:6:4   8   8.12
2017.1.29 12:6:5   9   9.14
2017.1.29 12:6:6   10   10.15
[......]
2017.1.29 12:16:56   660   660.909
2017.1.29 12:16:57   661   661.910
2017.1.29 12:16:59   663   662.911
2017.1.29 12:17:0   664   663.913
2017.1.29 12:17:1   665   664.914
2017.1.29 12:17:2   666   665.915
2017.1.29 12:17:3   667   666.917
2017.1.29 12:17:4   668   667.918
[......]
2017.1.29 12:18:1   725   724.998
2017.1.29 12:18:2   726   725.999
2017.1.29 12:18:3   727   727.0
2017.1.29 12:18:4   728   728.2
[......]
2017.1.29 13:5:56   3600   3599.960
2017.1.29 13:5:57   3601   3600.962
2017.1.29 13:5:58   3602   3601.963
2017.1.29 13:5:59   3603   3602.964
[......]
2017.1.29 13:16:10   4214   4214.809
2017.1.29 13:16:11   4215   4215.810
2017.1.29 13:16:12   4216   4216.812

Vorne die Zeit vom DS3231-Modul, danach die Sekunden seit Programmstart gemäß DS3231 und dahinter die Sekunden samt Divisionsrest seit Programmstart gemäß ESP-12E-Timer.

Nach 663 Sekunden bzw. etwa 11 Minuten gibt es bereits eine Abweichung.
Nunja, von der DS3231 bekomme ich nur Sekunden. Es ist unbekannt, ob die Sekunde gerade ein paar Millisekunden alt, oder die Sekunde in ein paar Millisekunden bereits abgelaufen ist.
Also ist eine Sekunde Abweichung noch kein Indiz für irgendwas.
Und wie zur Bestätigung laufen die Uhren nach 727 Sekunden wieder synchron.

Hier im Büro sind es gerade 21°C. Vielleicht werde ich den Test heute Abend im Wohnzimmer für ein paar Stunden wiederholen, nachdem ich den Ofen angemacht habe.

Weil mir das mit der eingebauten Ungenauigkeit von einer Sekunde nicht gefällt, nochmal mit leichter Änderung:

RTCdata getRTCprecise(void) {
static RTCdata t;
int sec;

t=getRTC();
sec=t.second;
while(t.second==sec) {
    delay(1);
    t=getRTC();
}
return(t);
}

long millis_base;
long sec_base;

void setup() {
RTCdata t;

Serial.begin(115200);
Wire.begin(2, 0); // SDA, SCL
t=getRTCprecise();
millis_base=millis();
sec_base=t.second+t.minute*60+t.hour*60*60;
}

void loop() {
static long sec, mil;
static RTCdata t;

t=getRTCprecise();
mil=millis()-millis_base;
printRTC(t);
Serial.print("   ");
sec=t.second+t.minute*60+t.hour*60*60;
Serial.print(sec-sec_base);
Serial.print("   ");
Serial.print(mil/1000);
Serial.print(".");
Serial.print(mil%1000);
Serial.println();
delay(900);
}

Durch das getRTCprecise() kann ich jetzt davon ausgehen, dass jede Sekunde vom DS3231 immer auf eine Millisekunde gleich alt ist. Da kommt im Terminal:

2017.1.29 13:19:18   1   1.0
2017.1.29 13:19:19   2   2.0
2017.1.29 13:19:20   3   3.0
2017.1.29 13:19:21   4   3.999
2017.1.29 13:19:22   5   5.0
[......]
2017.1.29 13:29:18   601   600.994           // nach 10 Minuten
2017.1.29 13:29:19   602   601.995
2017.1.29 13:29:20   603   602.994
[......]
2017.1.29 14:19:18   3601   3600.968         // nach 60 Minuten
2017.1.29 14:19:19   3602   3601.968
2017.1.29 14:19:20   3603   3602.968
2017.1.29 14:19:21   3604   3603.969
2017.1.29 14:19:22   3605   3604.967
[......]
2017.1.29 14:49:18   5401   5400.952          // nach 90 Minuten
2017.1.29 14:49:19   5402   5401.952
2017.1.29 14:49:20   5403   5402.952
2017.1.29 14:49:21   5404   5403.952
2017.1.29 14:49:22   5405   5404.951

Zwischendurch habe ich mal gelüftet und die Temperatur im Raum ging zeitweilig auf 19°C runter.

Somit nach 10 Minuten 6 Milisekunden Abweichung, nach 60 Minuten schon 32 Millisekunden.
6*6=36. Keine ganz lineare Abweichung. Ich lass das Ding noch weiter laufen.
Nach 90 Minuten sinds 48 Millisekunden. 6*9=54 aber 32/2*3=48. Also schon linear, wenn man 30 Minuten-Abweichung als Basis nimmt.
Aber sowieso egal: rechnet man 32 Millisekunden Abweichung pro Stunde auf einen Tag hoch, ergeben sich 32*24=768 Millisekunden Abweichung pro Tag. Das würde mir vollkommen reichen.

Jedoch steht ja noch der Test mit deutlich geänderter Umgebungstemperatur an. Also muss ich mal temporär auf den Laptop umziehen und eine mobile Stromversorgung suchen.

So, der Umzug ist vollzogen und der Ofen heizt bereits. Der ESP-12E liegt auf einem Notenständer, der jetzt direkt neben dem Ofen steht. Die Höhe ist etwa Ofen-Oberkante. Direkt auf die Schamottsteine des Ofens wollte ich die Schaltung doch lieber nicht legen....da wirds schon ziemlich warm....
Pünktlich um 18:00 ging die Messung bei 23°C los.
Es ist 18:38, ich habe mir gerade das zweite Bierchen aus dem Kühlschrank geholt und dabei Thermometer und Laptop überprüft.
Am Ofen bzw. ESP-12E sind es 32°C und 25 Millisekunden Abweichung.
Nächstes Bier: 19:16, 33°C und 53 Millisekunden Abweichung.
Mittlerweile sitze ich primär vor dem Fernseher. ZDF.info. Mein Lieblingssender. Wie gut, dass der Fernseher Time-Shift beherrscht und ich bei Bedarf einfach die Pause-Taste drücken kann.... :-) Das Programm ist heute durchaus spannend.
20:00, 38°C, 85 Millisekunden Abweichung.
20:30, 42°C, 111 Millisekunden Abweichung.
21.33, 43°C, 162 Millisekunden Abweichung.

So. Langt für heute. Sieht aber erstmal gut aus.

Der Vollständigkeit halber noch die Auswertung:
038 Minuten -> 025 Millisekunden Abweichung (m=0,658)
076 Minuten -> 053 Millisekunden Abweichung (m=0,697)
120 Minuten -> 085 Millisekunden Abweichung (m=0,708)
150 Minuten -> 111 Millisekunden Abweichung (m=0,740)
213 Minuten -> 162 Millisekunden Abweichung (m=0,761)
Wenn man das aufmalt, kommt deutlich keine Gerade heraus. Vielmehr steigt die Steigung bei jedem Wert.
Trotzdem liegt das noch im (für meine Zwecke) akzeptablen Bereich: 24*60/213*162=1095,2 Millisekunden Abweichung pro Tag.

Die Umsetzung der Erkenntnisse in einen LoggerV2 werde ich einen eigenen Abschnitt auf der Homepage auslagern.