Декодирование предполагаемых временных меток
Я пишу инструмент для декодирования данных, которые я получаю через кабель mini-USB от весов Beurer BF-105.
Часть, с которой я действительно борюсь, — это 4 байта, которые, по моему мнению, должны кодировать временную метку измерений.
Я собрал следующие примеры данных за последние 3 дня:
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
Единственное, что я там вижу, это то, что по крайней мере несколько младших битов второго байта кодируют день, поскольку он увеличивается на единицу при каждом изменении дня. Но я не понимаю, как он это кодирует.
Кто-нибудь видит здесь какие-то закономерности, которые мне не хватает? Что эти кусочки могли мне сказать?
Я начал модифицировать инструмент, который я создал для BF-100, для другой кодировки BF-105 здесь: https://gitlab.com/thomas351/beurer_bf100_parser/-/blob/bf105/src/main.rs
В отличие от хранилища дней рождения в пользовательском разделе и времени получения в конце файла, это явно не просто кодирование трех обычных частей нашего календаря (год, месяц и день) отдельно без какого-либо смещения. Интерпретация всех первых 2 байтов как одного целого числа u16 дает значения 11657, 11658 и 11659 за последние 3 дня. Подобная интерпретация соответствовала бы данным, которые я собрал на данный момент, но примите нулевой день 17 апреля 1992 года, что не кажется разумным смещением для использования.
ОБНОВЛЯТЬ:
как отметил @htmlcoderexe, переключение между днем происходит не в полночь, а иногда между ~ 11:00 и 18:08. Или, согласно двум моим недавно полученным образцам, где-то между ~11:00 и 17:50:
00101101 10001100 10001100 11100011 = 2024-03-19 17:50:09
00101101 10001100 10001101 00000001 = 2024-03-19 17:51:30
ох, ты прав, я этого раньше не видел, спасибо за подсказку. Ну, я не уверен, какую информацию содержат эти 4 байта, предыдущая модель кодировала только дату, а не время. Также в не совсем простой кодировке я смог скопировать отсюда: github.com/Urban82/BeurerScaleManager/wiki/Anaанализ
откуда у вас временные метки? например, откуда вы знаете, что эти двоичные значения соответствуют этим конкретным меткам времени, и почему иногда они точны до секунды, а иногда даже не до минуты (например, «~ 11:00»)
эти временные метки — это только то, что я собрал вручную, поэтому субминутная часть, скорее всего, либо вообще не будет закодирована в двоичных данных, либо, по крайней мере, не будет соответствовать тому, что я записал.
Ответы 1
Наконец понял это. Это u32, который представляет секунды, прошедшие с 01.01.2000 00:00:00.
не уверен, что это так просто. Смена дня, похоже, не происходит в 00:00 - данные говорят, что наилучшее предположение - около 18:00 (см. штампы от 18 марта 2024 г., младшие биты второго байта отличаются на 1 до и после, и после 18). :00 они такие же, как и 19 марта 2024 г., но до 18:00) Однако другие числа, кажется, странно переворачиваются, поскольку всего через 8 и 10 минут после 18:00 уже отображаются высокие значения в 3-м байте. Может быть, некоторые из них являются флагами? Я подозреваю, что на самом деле это может быть подсчет некоторых «тиков», которые не совсем соответствуют удобочитаемым единицам времени.