Seltsamer TimeStamp

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Seltsamer TimeStamp

      Hallo,
      kennt jemand eine 7-Byte Zeiterfassung ca 1,5 Mega Ticks pro Sekunde. Beginn ca Jahr 700. Um von E5 5B 79 78 39 A5 BF auf den 01.10.2019 19:06:00 zu kommen rechnet man sich nen Wolf . Gibts da fertige Routinen? Unix wäre ja zu einfach gewesen a_45_132ca9f5
      Das ganze kommt von DS100 Datenlogger für drei Byte Daten plus Zeit verschwenden die 36Byte.
    • Pluto25 schrieb:

      Um von E5 5B 79 78 39 A5 BF auf den 01.10.2019 19:06:00 zu kommen
      Die einzige Erklärung die ich im Moment habe ist, dass alles BCD-Kodiert sein könnte.
      Dann würde Datum (dd.mm.yyyy) und Uhrzeit (hh:mm:ss) mit Sekunden 7 Byte Speicherbedarf benötigen.

      Das passt aber nicht zu den Zahlen. Vielleicht muss man die Bits erst noch invertieren / rotieren.

      Vielleicht kannst du mal einen kompletten Datensatz aufzeigen und angeben, was bereits bekannt ist.
      Also Datensatz-Format-Aufbau erklären.
    • Leider ließ es sich nicht als Text kopieren :
      Zwischenablage.jpg
      0+1 sind die Temperatur Kommastelle (66E6=,9 / CC=,8)
      2 ist die Temperatur + 32K (22°C)
      3,14 und 20 vermutlich Feldtrenner
      4 die Feuchtigkeit (69%)
      5 evt der Meßtakt?
      D-13 der Zeitstempel (01.10.2019 19:14:00)
      19-1F auch einer aber vermutlich die Übertragungszeit nicht der Meßzeitpunkt
      Sie entstanden im Minutentakt.
      11 incrementiert sich im ca 45 Minuten Takt

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Pluto25 ()

    • ,8 Vielleicht ja auch 52428/65536 bei einer Auflösung von 16 Bit hinter dem Komma. Aber es gibt nur Zehn Kombinationen also kein CD CC. Vermutlich wird es "rückwärtz" generiert. (65536*0,9= Hex E6 66 Neiderwertiges zuerst wären 66 E6. Das ließe sich gut in den Griff bekommen. (Das gewünschte Format brauchts nur Grad genau) Das mit der Zeit macht mir mehr Kopfzerbrechen.
      Ich vermute das der ganze Satz kein einziges gewolltes Ascii Zeichen enthält
    • Ich glaube mit dem Dekodieren der Daten bist du teilweise auf dem Holzweg.

      Mir scheint es, dass Spalte 0 bis 3 die Temperatur sein könnte als Single gespeichert (4 Byte)
      An Spalte 4 Feuchte kann sein, aber deine Umrechnung scheint dann von Hex in Dezimal nicht zu passen.

      Geh doch mal hin und lösche den Speicher in dem Logger.
      Stelle den so ein, dass der alle 5 Sekunden die Werte Loggt.

      Dann notiere Uhrzeit und Datum, an dem du den Logger startest.
      Nach 3-5 Logst stoppst du den Logger.

      Dann zeigst du was der Logger geloggt hat, also 1x Rohdaten und dann was die Windows-Software an Temperatur- und Feuchtewerte anzeigt.

      Um das zu dekodieren braucht es eine eindeutige Zuordnung. Von Werten und Daten.

      Kannst du das mal machen und hier rein stellen?

      Ich gehe davon aus, dass dein Logger nur einen Kanal für Temp und einen für Feuchte hat.

      Ich würde Temp als Single (4 Byte) oder Temp*10 als Integer (2 Byte) speichern. 1 Byte Feuchte.
      Dazu Datum und Uhrzeit (max 7 Byte, geht aber auch deutlich kürzer), dann noch eine laufende Nr für den Datensatz (2Byte oder 4 Byte). Ich komme da auf insgesamt ca. 16 Byte großzügig gerechnet).

      Im Datensatz ist mir auch aufgefallen dass da Bereiche Doppelt sind.
      Spalte $D bis $13 deckt sich mit Spalte $19 bis $1F.

      Vielleicht interpretierst du die Datensatzlänge auch falsch.

      Mach doch mal den oben beschriebenen Logversuch mit 5s Interval über 3 - 5 Messungen.
    • Mitch64 schrieb:

      dass da Bereiche Doppelt sind
      Das erste die Meßzeit das zweite die Übertragungszeit. Nur nahe gleichzu solange er am PC hängt.
      Eigendlich ist mir eine Minute zu lang mit 5 wird ne halbe Stunde :( Zwischenablage.jpg
      Zwischenablage2.jpg
      Sollte ich die Kommastelle brauchen, müsste nur Byte 2 durch Hex16 (22) geteilt zu werden.
      Eine einfache Shift operation anstelle der psydosingle Krampf.
      Mit der Zeit ist das nicht so einfach.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Pluto25 ()

    • Na das ist ja mal ein merkwürdiges Dateiformat.
      Offensichtlich hat jemand Interesse daran, dass man das Format nicht entschlüsseln kann.
      Bisher kann ich das von dir bestätigen:
      Dateiformat.png
      Die Nachkommastelle der Temperatur (Offset 0 = LowByte, Offset 1 = HighByte) muss man durch $FFFF (65535 dez.) teilen, damit man den Wert hat, den man zur Temperatur (Wert von Offset 2 - 32) aufaddieren muss.

      Komisch dabei: Der Wert 0 würde dann -32°C bedeuten. Aber das Gerät soll ein Messbereich von -40°C bis +60°C haben. Was steht also an Offset 2 bei Temperaturen unter 32°C?
      Kannst du das schnell mal testen? :D

      Wer kommt auf so ein unsinniges Dateiformat?
      Die Werte, die du für das Datum hältst scheinen sich zu bestätigen. Bin aber nicht dahinter gekommen, wie das gespeichert sein könnte. BCD-Kodierung kann ich ausschließen.

      Ich bekomme langsam den Eindruck, dass es sich bei dem Datum samt Zeit um eine Zahl handeln könnte, die die vergangene Zeit in Minuten seit einem Ursprung darstellt. Also Anzahl Minuten seit einem Ur-Datum.

      Man bräuchte jetzt mehr Daten mit einem anderen Datum, damit man sieht, was sich bei anderen Jahreszahlen ändert oder bei anderen Tagen usw.

      Das ist echt ne harte Nuss, dieses Format! a_27_b277ca12
    • Mitch64 schrieb:

      Also Anzahl Minuten seit einem Ur-Datum
      Ja in ca 660 nano Sekunden Schritten seit ca Jahr 700 anno domini. Vermutlich ist es viel simpler , wir kommen nur nicht drauf weil unsere Hirne schleckt binär denken. Die gesamte Zahl dividiert durch Hex
      18 45 C8 ergibt Sekunden seit Jahr 700 - Schaltjahre? Anfangszeit? Eine dirty Lösung wäre einfach "jetzT" abziehen und von dann die Sekunden berechnen. Aber selbst dann müssen die Monate /Tage noch konstruiert werden :(
    • Aber das ist doch irgendwie krank den Wert durch Hex 1845C8 teilen.
      Das ist ja schon bei der Temperatur Nachkommastelle äußerst merkwürdig.

      Ich denke auch, dass es simpler sein muss. Wenn man jetzt mal eine Messung hat vom 1.1.2000 und eine vom 1.1.2001 und vielleicht zur Überprüfung noch eine vom 1.1.2002, und alles um 0:00 gemessen (jedenfalls zur gleichen Zeit), dann könnte man durch Differenzbildung der Wert für ein Jahr ermitteln.

      So käme man Stück um Stück näher ans Ergebnis.
      Aber das Datum in ns abspeichern? Den Chinesen traue ich ja so manches zu, aber so krank sind die dann doch nicht, oder?
    • @Pluto25 mach's doch mal andersrum und bastel dir einen Datensatz und lass den durch die sw anzeigen (umrechnen). Mit den jetzt gewonnenen Erkenntnissen kannst du 0,0° und 99% Feuchtigkeit einstellen und für die Zeit einfach Nuller angeben. Was sagt die sw dazu?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • tschoeatsch schrieb:

      Was sagt die sw dazu
      Feuchte 0 :) Temperatur +2°C :?: Datum 01.01.1900 0.00Uhr ?(

      Danke, Guter Ansatz

      die ersten drei Byte beeinflussen die Zeit nicht. Prüfsummen?
      das vierte beschreibt 45/256 min die oberen drei Bit des 5ten beschreiben Tage die anderen die 32 dreiviertel Stunden eines Tages

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Pluto25 ()

    • Algorithmus um Schaltjahre zu berechnen?
      Ja gibt es. Jahreszahl Modulo 4, denn jedes 4. Jahr ist ein Schaltjahr. 2020 ist ein Schaltjahr.

      Ich habe mal ausgerechnet, wie viel Sekunden ein Jahr hat (kein Schaltjahr). Und habe dann die ersten 4 Byte von dem Datum genommen und durch die Sekunden geteilt. Kam dann (nicht ganz sicher) auf ca. 115 Jahre?
      Jedenfalls haben 5 Jahre gefehlt. Grob gerechnet müsste die "Epoche" (Start-Datum) dann ca. 1895 gelegen haben. Gab's da eine Datums-Festlegung so wie 1.1.1900 oder 1.1.1970?

      Ich habe übrigens mit dem Windows-Rechner gerechnet. Der packt diese Zahlen noch.
    • Mitch64 schrieb:

      Datums-Festlegung so wie 1.1.1900
      Ein früherer Termin ist nicht zu erreichen. Aber die Logik bleibt mir verschloßen: ;(

      Quellcode

      1. 01.01.1900 16:04:00 05 5b be 6f
      2. 01.01.1900 12:00:00 04 00 00 00
      3. 01.01.1900 15:00:00 05 00 00 00
      4. 03.01.1900 00:00:00 10 00 00 00
      5. 01.07.1900 04:18:00 20 5b be 8f
      6. 01.07.1900 00:00:00 20 00 00 00
      7. 05.07.1900 00:00:00 60 00 00 00
      8. 26.05.1901 00:00:00 80 00 00 00
      9. 02.06.1901 00:00:00 81 00 00 00
      10. 06.06.1901 11:13:00 80 5b be 6f
      11. 02.11.1901 00:00:00 85 00 00 00
      12. 05.09.1903 00:00:00 95 00 00 00
      13. 11.05.1907 00:00:00 a5 00 00 00
      14. 19.09.1914 00:00:00 b5 00 00 00
      15. 05.12.1922 11:42:00 c0 5b be 6f
      16. 30.04.1924 11:42:00 c1 5b be 6f
      17. 08.12.1929 11:43:00 c5 5b be 6f
      18. 16.11.1959 23:27:00 d5 5b be 6f
      19. 20.09.1991 22:49:00 e0 5b be 6f
      20. 23.02.2014 22:55:00 e4 5b be 8f
      21. 30.09.2017 00:00:00 e5 00 00 00
      22. 05.10.2017 22:49:00 e5 00 be 6f
      23. 03.10.2019 22:49:00 e5 5b be 6f
      Alles anzeigen

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Pluto25 ()