KLogProViewer4 / begrenzte Anzahl Datensätze im Diagramm ?

[Brösel]

Um die "zukünftigen" Daten raus zu bekommen, werde ich nicht um einen RESET herum kommen.

Gleichzeitig interessiert mich der Aufbau der 0_history. Wie ich gelesen habe, sind 84 Byte pro Datensatz abgelegt.

Ein Datensatz hat jeweils 84 Byte:
=============
8 Byte Datum (double)
4 Byte Temp int (float)
4 Byte Humidity int (float)

jetzt 8 x im Wechsel:

4 Byte Temp Chn 1 ... 8 (float)
4 Byte Humidity Chn 1 ... 8 (float)

zum Schluss jeden Datensatzes:
4 Byte 0x00 (anscheinend z.Zt. Schlusskennung)
=============
zusammen 84 Byte pro Datensatz.

Nur wie ist das Datum nun zusammengesetzt ? Reihenfolge der Bytes ?
Die 84 Byte befinden sich zwischen den roten Klammern. 4 Byte mit "00" bezeichnen den Beginn oder das Ende, wie oben schon beschrieben.

[gelöscht durch Administrator]

[gusa]

Hallo Brösel,

hatte mal einen ähnlichen Fehler. Schau Dir mal meine Grafik an, da sind auf einer Grafik die Fehler zu sehen, durch übergroßen Ausschlag der Werte. Jetzt habe ich mir die Werte der history_0 Datei angesehen und diesen Zeitfehler entdeckt.


Gruß

gustav



[gelöscht durch Administrator]

[TheWeather]

Hallo Brösel,

der Fehler steckt enweder im KLP selbst oder in dessen Auslesedienst.

Wir (WsWin oder KlogProViewer) lesen nur mit ...

Die Anleitung von Gustav für einen Main-Reset solltest Du auf jeden Fall auch ausprobieren!

So wie ich sehe, kannst Du auch Hex auslesen und bist daher auch mit Dateistrukturen eher "bewandert".

Beim Datumsformat, welches in der history_0.dat verwendet wird, handelt es sich (entgegen meiner ersten und wie von Dir unten dokumentierten Vermutung) nicht um einen 8-Byte-Double, sondern um zwar ebenfalls 8 Byte, aber einen 64-Bit Integerwert, welcher sich am julianischen Datum orientiert (siehe http://de.wikipedia.org/wiki/Julianisches_Datum ). Es ist also nicht ganz so trivial, aus dem 64-Bit-Wert ohne weitere Umrechnungen auf den "echten", zeitzonenbezogenen Datumswert/Uhrzeit (UTC) zu gelangen, dann noch Zeitzone und Sommerzeit/Winterzeit zu berücksichtigen, um als Ergenbis zum aktuellen, lokalen Datumsstempel zu gelangen. Um das "auseinander zu nehmen" und zu verstehen, musst Du Dich zunächst selbst durch einige Versuche durchquälen:
a) Julianisches Datum aus 64 Bit (meines Wissens nach dem 01.01.-4712, 12:00 vergangene Zeit, hier in µsec) nach UTC umrechnen
b) Zeitzone des Standorts durch Addition/Subtraktion berücksichtigen
c) Sommerzeit/Winterzeit nach Kenntnis der nationalen Regelungen als Offset addieren/subtrahieren (ist in der EU anders als z.B. in U.S.A. oder sonstwo auf der Welt.

Ich hab' mir das mal irgenwann als Tool fertig gemacht, welches auch funktioniert - über Feinheiten kann ich da momentan nichts mehr weiter beitragen.

Das Datum steckt also tatsächlich jeweils die ersten 8 Byte nach den "0000". Wenn Du selbst auch programmieren kannst, dann versuch doch mal, aus diesen 8 Bytes ein "aktuelles Datum" zu generieren. Ich selbst habe knapp zwei Tage gebraucht, bis ich zumindest den Algorithmus raus hatte - auf das Julianische Datum hat mich dann erst ein Kollege hier aus dem Forum gebracht - hierfür nochmals Danke, falls er mit liest.

Ich hoffe, das hilft ein wenig weiter. In einigen Worten "erklären" lässt sich's leider von mir nicht so einfach.

Gruß Hans

[Brösel]

Dann lass' ich das lieber mal, bevor ich hier massenhaft Stunden investiere.

Bin davon ausgegangen, dass Datum und Zeit irgendwie als Intel- oder Motorola-Format abgelegt sind.

Werde dann mal den Logger resetten und den DCF-Empfang abstellen.....