Anyone recognise this date byte format ?

[crankshaft]

Does anyone recognise this data byte format for date ??

This was done at 8:15:

Epoch timestamp: 1643156100
Timestamp in milliseconds: 1643156100000
Date and time (GMT): Wednesday, 26 January 2022 00:15:00
Date and time (your time zone): Wednesday, 26 January 2022 08:15:00 GMT+08:00

This is the data I received for 8:15

Code Select Expand

['0xa0', '0x11', '0x4', '0xf4', '0x40', '0x83', '0x29']

The first 2 bytes are the device id and address: '0xa0', '0x11'

The other bytes somehow make up the date.

at 8:16 the data changed to:

Code Select Expand

['0xa0', '0x11', '0x4', '0x30', '0x41', '0x83', '0x29']

with bytes 3 & 4 incrementing by 60 seconds.

And today byte 5 (0x83) rolled over to 0x84, so I know at least bits 3,4 & 5 are the date / time and probably byte 6.

I suspect byte 2 is some other register.

But does anyone recognise this format as I cant seem to translate it into an epoch ??




 

[crankshaft]

Using python, to me this does not look like a 4byte epoch ??

Code Select Expand

import struct
data = [0xf4, 0x40, 0x83, 0x29]
struct.unpack("<I", bytearray(data))[0]
>> 696467700

data = [0x29,0x83,0x40,0xf4]
struct.unpack("<I", bytearray(data))[0]
>> 4097868585


[trastikata]

Can you write small routine to gather more data with the corresponding time and date?

[crankshaft]

Thanks, bytes 3 & 4 increment by 60 seconds each minute:

Code Select Expand

8:17 ['0xa0', '0x11', '0x4', '0x6c', '0x41', '0x83', '0x29']
8:57 ['0xa0', '0x11', '0x4', '0xcc', '0x4a', '0x83', '0x29']
9:00 ['0xa0', '0x11', '0x4', '0x44', '0x4b', '0x83', '0x29']

etc etc etc

I presume that bits 5 & 6 will also increment when the proceeding byte overflows.

I am using buspirate to sniff the I2C bus and have written a python script that uses buspirate and formats and filters the output.
There's nothing else really to gather, once a minute this data is transmitted and the bytes increment by 60 seconds.

[m.kaviani]

the bytes inside the calendar chip like DS1307 are stored and changed in BCD format.
did you consider that?

Code Select Expand

CLOCK_READ:

    ADDR = 0 : GoSub READ_TIME : SECOND = STORE
    ADDR = 1 : GoSub READ_TIME : MINUTE = STORE
    ADDR = 2 : GoSub READ_TIME : HOUR   = STORE
    ADDR = 3 : GoSub READ_TIME : DAY    = STORE
    ADDR = 4 : GoSub READ_TIME : DATE   = STORE
    ADDR = 5 : GoSub READ_TIME : MONTH  = STORE
    ADDR = 6 : GoSub READ_TIME : YEAR   = STORE
    Return

READ_TIME:

    BStart
    BusIn CLOCKIN,ADDR,[STORE]
    BStop
    GoSub BCD_TO_BIN
    Return

BCD_TO_BIN:

    Select STORE
    Case 16 To 25
    STORE=STORE-6
    Case 32 To 41
    STORE=STORE-12
    Case 48 To 57
    STORE=STORE-18
    Case 64 To 73
    STORE=STORE-24
    Case 80 To 89
    STORE=STORE-30
    Case 96 To 105
    STORE=STORE-36
    Case 112 To 121
    STORE=STORE-42
    Case 128 To 137
    STORE=STORE-48
    Case 144 To 153
    STORE=STORE-54
    EndSelect
    Return


[crankshaft]

Thanks, no it's not that.

In my data Byte 0 is the device ID, Byte 1 is the device address and byte 3 increments every second, rolling over to byte 4 and byte 5.

But thanks anyway.

[trastikata]

If you arrange the data from byte 6 to byte 3 with byte 6 being MSB and byte 3 LSB, it's a timestamp in seconds. But what is the basis?

Hour --> HEX Timestamp --> DEC Timestamp --> Difference DEC Timestamp --> Actual time difference in minutes
8:15  --> 0x298340F4    --> 696467700        --> 60                                         --> 1
8:16  --> 0x29834130    --> 696467760        --> 60                                         --> 1
8:17  --> 0x2983416C    --> 696467820        --> 2400                                    --> 40
8:57  --> 0x29834ACC    --> 696470220       --> 120                                      --> 2
9:00  --> 0x29834B44    --> 696470340

696467700 represents 8:15 -->
696467700 / 60 seconds = 11607795 minutes -->
11607795 - 15 (minutes from 8:15) = 11607780 minutes to 8:00 -->
11607780 / 60 minutes = 193463 hours from base
Today - 193463 hours = 3 Jan 2000

If I may assume the data was recorded 3 days ago, the base for the timestamp is 01-01-2000

[keytapper]

Using python, to me this does not look like a 4byte epoch ??

The epoch is Jan 1st 1970. So they considered to count every second since then. That will result 1.5 century before the 32bit unsigned variable will roll over.
In python we may use time and datetime libraries to manipulate that value aka unixtime

Code Select Expand

>>> import datetime
>>> datetime.datetime.fromtimestamp(1643156100)
>>> datetime.datetime(2022, 1, 26, 8, 15)
It looks like you're parsing a time from a GPS module. My studies are gathering such information from Ublox M6 module, so the packet payload should be about 16 or 20 bytes long, refering to NAV-TIMEUTC and NAV-TIMEGPS.
NOTE
The Ublox format is little ENDIAN

[m.kaviani]

Thanks, no it's not that.

In my data Byte 0 is the device ID, Byte 1 is the device address and byte 3 increments every second, rolling over to byte 4 and byte 5.

But thanks anyway.

so, what is your calendar device?

[crankshaft]

Thanks all @trastikata was actually on the nail, it is elapsed seconds since 2000/1/1.

I was thinking that it was somehow based on epoch (1970) but the count matches 2000/1/1 as a baseline perfectly

Thanks so much for the help