I'm writing a tool to decode data I retrieve via mini-USB cable from the Beurer BF-105 scale.
The part I'm really struggling with are the 4 bytes that I think should encode the timestamp of the measurements.
I gathered the following example data over the last 3 days:
00101101 10001001 10001111 11111100 = 2024-03-17 ~11:00
00101101 10001001 11001000 01110101 = 2024-03-17 15:28:24 (?)
00101101 10001010 10101000 01001100 = 2024-03-18 07:21
00101101 10001010 10110001 10011110 = 2024-03-18 07:23
00101101 10001011 00111111 10000110 = 2024-03-18 18:08:13
00101101 10001011 01000000 00110010 = 2024-03-18 18:10:39
00101101 10001011 11100110 00010000 = 2024-03-19 05:58:23
00101101 10001011 11111010 01001110 = 2024-03-19 07:24:46
00101101 10001001 10011011 11101000 = 2024-03-17 ~16:00
00101101 10001010 10011110 00000001 = 2024-03-18 ~07:00
00101101 10001011 11101101 10010100 = 2024-03-19 06:30:20
00101101 10001011 11101101 10101010 = 2024-03-19 06:30:54
The one thing I do see in there is that at least the lower few bits of the second byte encodes the day, since it increases by one on every day change. But I don't understand how it encodes it.
Does anybody see any patterns here that I'm missing? What could those bits want to tell me?
I've started modifying the tool I created for the BF-100 to the different encoding of the BF-105 here: https://gitlab.com/thomas351/beurer_bf100_parser/-/blob/bf105/src/main.rs
Unlike the birthday storage in the user section and the retrieval time at the end of the file, it's clearly not just encoding the 3 usual parts of our calendar (year, month & day) separately without any offset. Interpreting the whole first 2 bytes as a single u16 integer gives the values 11657, 11658 & 11659 for the last 3 days. Interpreting it like that would fit the data I have collected so far, but make day zero 1992-04-17 - which doesn't seem like a sensible offset to use.
as @htmlcoderexe pointed out, the switch between the day does not happen at midnight, but some-when between ~11:00 and 18:08. Or according to my two newly aquired samples some-when between ~11:00 and 17:50:
00101101 10001100 10001100 11100011 = 2024-03-19 17:50:09
00101101 10001100 10001101 00000001 = 2024-03-19 17:51:30
Finally figured it out. It's an u32 that represents the seconds passed since 2000-01-01 00:00:00.