Благодарю за ссылку. Ранее я пользовался поиском по гитхабу, но не нашёл дампов с устройств Dyson нужной структуры пакетов. Хотя по ссылке я и не нашел дамп для TP07, появились новые данные от схожих устройств.
В свете новой инфы нужно поправить таблицу распределения битов в пакете. Теперь на команду отводится 7 бит и 3 бита на контрольную сумму. Это чисто академическая информация, не влияющаяя на работоспособность устройства.
Да, пробовал и так, и сяк. Разворачивал тело пакета, разворачивал контрольную сумму, отдельно байты переменных тоже переставлял, ничего не подошло. Возможно, не удалось подобрать правильные настройки самой reveng. Если кому будет интересно попытаться самостоятельно, пользуясь reveng, взломать CRC32, дамп всех пакетов за 10 секунд работы выложен в репозитории проекта на гитхабе.
Есть вероятность, что для подсчёта CRC32 используется аппаратный модуль в контроллере STM32, поэтому reveng не срабатывает. Reveng считает побайтный crc, a в модуль подсчёта crc контроллера грузится по 4 байта за один раз. Для выравнивания последних байт пакета до кратных 4-м, что-то дописывается. Если это так, то, не зная этого, никогда не вскрыть crc.
Я иду сейчас другим путём. Ещё один доп провод в нужное место на плате, и будем имитировать управление с IR пульта. Нужные посылки уже расшифрованы, допишу программную часть и сделаю продолжение детектива.
В первую очередь необходимо выделить пакеты среди всего массива данных. Принимающая сторона должна быть способна отделить один пакет от другого. Есть несколько способов: добавить старт-стоп байт в пакет (как в этом случае) или сделать паузы между пакетами, тогда можно будет ловить пакеты на основании Idle Line прерывания.
Сразу удалось выявить старт/стоп байт 0x12 (18 в десятичной системе), пакеты мы нашли и отделили. Дальше записываем их рядом и сравниваем. Видим что они разной длины,которая указана во втором (и как оказалось в третьем) байте.
Для проверки корретности получения информации обычно используют некую контрольную сумму, которую добавляют в конец пакета (в основном). 4-х байтный CRC32 удалось выделить достаточно быстро. А дальше сложнее, если не используется какой-либо определенный стандарт формата пакета (modbus, например), приходится много сидеть и сравнивать отличия в разных пакетах, искать патерны и зависимости.
Данные по UART передаются в основном 8-ми битном формате, с определенной скоростью. Чтобы передать значение двух-восьми байтной переменной, нужно делить на байты. Очень полезно понимать, как записываются многобайтовые переменные в памяти (little-endian и big-endian), какой формат представления для вещественных чисел (float, double).
Можно экселем обойтись, но это долго при большом количестве данных. Я написал библиотечку парсера для удобства. Я сегодня выложу на гитхаб (сылка в конце статьи) excel файл с даными после работы парсера. Посморите визуально на разные пакеты, может станет понятнее.
Благодарю за ссылку. Ранее я пользовался поиском по гитхабу, но не нашёл дампов с устройств Dyson нужной структуры пакетов. Хотя по ссылке я и не нашел дамп для TP07, появились новые данные от схожих устройств.
В свете новой инфы нужно поправить таблицу распределения битов в пакете. Теперь на команду отводится 7 бит и 3 бита на контрольную сумму. Это чисто академическая информация, не влияющаяя на работоспособность устройства.
Да, пробовал и так, и сяк. Разворачивал тело пакета, разворачивал контрольную сумму, отдельно байты переменных тоже переставлял, ничего не подошло. Возможно, не удалось подобрать правильные настройки самой reveng. Если кому будет интересно попытаться самостоятельно, пользуясь reveng, взломать CRC32, дамп всех пакетов за 10 секунд работы выложен в репозитории проекта на гитхабе.
Есть вероятность, что для подсчёта CRC32 используется аппаратный модуль в контроллере STM32, поэтому reveng не срабатывает. Reveng считает побайтный crc, a в модуль подсчёта crc контроллера грузится по 4 байта за один раз. Для выравнивания последних байт пакета до кратных 4-м, что-то дописывается. Если это так, то, не зная этого, никогда не вскрыть crc.
Я иду сейчас другим путём. Ещё один доп провод в нужное место на плате, и будем имитировать управление с IR пульта. Нужные посылки уже расшифрованы, допишу программную часть и сделаю продолжение детектива.
В первую очередь необходимо выделить пакеты среди всего массива данных. Принимающая сторона должна быть способна отделить один пакет от другого. Есть несколько способов: добавить старт-стоп байт в пакет (как в этом случае) или сделать паузы между пакетами, тогда можно будет ловить пакеты на основании Idle Line прерывания.
Сразу удалось выявить старт/стоп байт 0x12 (18 в десятичной системе), пакеты мы нашли и отделили. Дальше записываем их рядом и сравниваем. Видим что они разной длины,которая указана во втором (и как оказалось в третьем) байте.
Для проверки корретности получения информации обычно используют некую контрольную сумму, которую добавляют в конец пакета (в основном). 4-х байтный CRC32 удалось выделить достаточно быстро. А дальше сложнее, если не используется какой-либо определенный стандарт формата пакета (modbus, например), приходится много сидеть и сравнивать отличия в разных пакетах, искать патерны и зависимости.
Данные по UART передаются в основном 8-ми битном формате, с определенной скоростью. Чтобы передать значение двух-восьми байтной переменной, нужно делить на байты. Очень полезно понимать, как записываются многобайтовые переменные в памяти (little-endian и big-endian), какой формат представления для вещественных чисел (float, double).
Можно экселем обойтись, но это долго при большом количестве данных. Я написал библиотечку парсера для удобства. Я сегодня выложу на гитхаб (сылка в конце статьи) excel файл с даными после работы парсера. Посморите визуально на разные пакеты, может станет понятнее.