News:

PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

Anyone recognise this date byte format ?

Started by crankshaft, Jan 27, 2022, 05:24 AM

Previous topic - Next topic

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

['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:

['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 ??

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

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

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?

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

#6
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

#7
Quote from: crankshaft on Jan 27, 2022, 08:44 AMUsing 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
>>> 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
Ignorance comes with a cost

m.kaviani

Quote from: crankshaft on Jan 27, 2022, 10:36 PMThanks, 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