Comments 29
1. Обязательно пишите. 2 Да.
С форком ресурса в сторону школьного кружка и курилки для балаболов читать профильные хабы стало интересно (т.к. пишут те, кому действительно интересно «угореть по хардкору»). Ну а автомобильная электроника на уровне железок и софта — это не хардкор, а “ultra violence“. Просто в силу того, что одновременно в ней живут вещи из разных технологических эпох.
С форком ресурса в сторону школьного кружка и курилки для балаболов читать профильные хабы стало интересно (т.к. пишут те, кому действительно интересно «угореть по хардкору»). Ну а автомобильная электроника на уровне железок и софта — это не хардкор, а “ultra violence“. Просто в силу того, что одновременно в ней живут вещи из разных технологических эпох.
Не хуже Пляшущих человечков. Настоящая черепаха. Распознавание битов с осциллографа через видеокамеру смартфона не пробовали? Шучу…
UFO just landed and posted this here
Chinese Redundancy Check — сделало мой день :)
У вас осцилограмма смещена вниз или же это в устройстве ассиметричные уровни (-0,7 — 0.2)?
creat0r, Вам большой жирный плюс (не хватает кармы проголосовать за статью). Уже года полтора под столом валяется парктроник без экрана и все это время я ждал именно этой статьи, что бы прикрутить туда экран на своем контроллере. Спасибо, пошел цеплять осцилограф к своему парктронику.
За зачистку радиоэфира респект.
Хм. Возможно, это сделано чтобы затруднить реверс и оставить простоту протокола(без шифрования), а может всё куда обоснованней — чтобы в случае помех были повреждены разные части передаваемых данных и повысилась вероятность обнаружения ошибки.
Кстати, не увидел индивидуального кода, это же получается что… если вдруг две машины будут парковаться одновременно рядом с одинаковым парктроником то у них ничего не получится. будут попеременно воспринимать то свои данные то соседа то вообще ничего.
Кстати, не увидел индивидуального кода, это же получается что… если вдруг две машины будут парковаться одновременно рядом с одинаковым парктроником то у них ничего не получится. будут попеременно воспринимать то свои данные то соседа то вообще ничего.
Во время получения посылки по радиоканалу вероятнее всего словить одиночную мощную помеху, которая задавит напрочь несколько бит подряд. Такое повреждение способна отловить любая контрольная сумма, не важно, считается ли она целиком от всех данных, или чередуясь через два бита. Насчёт затруднения реверса — тоже вряд ли. Уж для затруднения столько напридумывать можно. К примеру, перестановку битов по маске или XOR их между собой. Да даже простое шифрование сделать, зашив ключи в оба блока.
Индивидуального кода нет, вся надежда на специально загрубленную чувствительность приёмника при относительно мощном передатчике и экранирование канала передачи данных внутри цельнометаллического кузова авто. Но вообще да, применение радиоканала в данном случае — оправдано только ленью и способностью китайцев сначала сделать, а потом подумать «а может не стоило?». Протащить провод через салон можно практически в любом авто.
Индивидуального кода нет, вся надежда на специально загрубленную чувствительность приёмника при относительно мощном передатчике и экранирование канала передачи данных внутри цельнометаллического кузова авто. Но вообще да, применение радиоканала в данном случае — оправдано только ленью и способностью китайцев сначала сделать, а потом подумать «а может не стоило?». Протащить провод через салон можно практически в любом авто.
Ключи в обоих блоках это усложнение процесса сборки(надо индивидуально прошивать блоки ключами, причем еще парно) и увеличение времени сборки — это лишние сложности которые ведут к удорожанию.
С защитой от реверса — та же фигня, время на разработку сильно ограничено и порой что-либо выдумывать просто нет времени. Вот взяли и реализовали простую перестановку бит. Кстати, это может и являться индивидуальным кодом — в другом комплекте биты могут быть переставлены уже совсем по другому.
С защитой от реверса — та же фигня, время на разработку сильно ограничено и порой что-либо выдумывать просто нет времени. Вот взяли и реализовали простую перестановку бит. Кстати, это может и являться индивидуальным кодом — в другом комплекте биты могут быть переставлены уже совсем по другому.
Хотелось бы попросить у автора (надеюсь правилами хабра это не возбраняется) ссылку на статью, где можно почитать, как AVR-ку или Arduino использовать для считывания всяких автомобильных показаний (наподобие открытия двери, капота, может каких-то датчиков (масла, температуры и т. д.))
Спасибо.
Спасибо.
Это слишком обширная тема. У каждого автомобиля будет свой подход к считыванию показаний.
Для примера, концевики открытия дверей и капота зачастую вообще отсутствуют и ставятся вместе с сигнализацией уже сторонними фирмами, не на заводе. Тогда всё зависит от типа сигналки.
Но, при этом, у некоторых современных автомобилей высокого класса мало того, что эти концевики есть с завода, они ещё и висят на бортовой CAN-шине и считываются только модулем CAN, подключенным на эту шину.
То же самое с датчиками двигателя (масла, антифриза, ...). Либо некоторых из них нет вообще (температуры масла, скажем), тогда их надо ставить дополнительно и подключать к ардуине напрямую, либо снимать сигнал параллельно подключению его к штатным блокам управления автомобиля, либо считывать эти показания из блока управления двигателем по протоколам OBD-2.
В упомянутом в статье проекте KMENevoBT сделано чуть иначе. Газовые мозги KME Nevo Pro имеют встроенный модуль OBD-2 для подключения к заводским бензиновым мозгам. Таким образом по протоколу KME из газового мозга читаются и все показатели по газу и, заодно, все показатели по бензину (с небольшим лагом, правда).
Для примера, концевики открытия дверей и капота зачастую вообще отсутствуют и ставятся вместе с сигнализацией уже сторонними фирмами, не на заводе. Тогда всё зависит от типа сигналки.
Но, при этом, у некоторых современных автомобилей высокого класса мало того, что эти концевики есть с завода, они ещё и висят на бортовой CAN-шине и считываются только модулем CAN, подключенным на эту шину.
То же самое с датчиками двигателя (масла, антифриза, ...). Либо некоторых из них нет вообще (температуры масла, скажем), тогда их надо ставить дополнительно и подключать к ардуине напрямую, либо снимать сигнал параллельно подключению его к штатным блокам управления автомобиля, либо считывать эти показания из блока управления двигателем по протоколам OBD-2.
В упомянутом в статье проекте KMENevoBT сделано чуть иначе. Газовые мозги KME Nevo Pro имеют встроенный модуль OBD-2 для подключения к заводским бензиновым мозгам. Таким образом по протоколу KME из газового мозга читаются и все показатели по газу и, заодно, все показатели по бензину (с небольшим лагом, правда).
Там электрически все просто, сложности начинаются в таблице используемых кодов, они не очень-то распространяются производителями и могут сильно отличаться для разных производителей.
Возьмите для начала книжку Practical Arduino (на Амазоне или, если денег жалко, на торрентах) и возьмите оттуда главу про OBD.
Сайт книги — www.practicalarduino.com/projects/vehicle-telemetry-platform
Сайт книги — www.practicalarduino.com/projects/vehicle-telemetry-platform
А какая минимальная дистанция обнаружения у этого парктроника? Если 30 см как у всех дешевых, то по-моему не стоило так из-за него заморачиваться.
Отмеченные бледно-розовым два столбца по 2 бита соответствуют единицам сантиметров (заметьте, что для 105, 95 и 85 см биты одинаковы). Причём в первом столбце более старшие биты 4-битного значения. Принцип кодирования тот же: 0 см = 1111, 1 см = 1110 и т.д. вплоть до 9 см = 0110
Проинвертировать не пробовали?
Да, можно было бы вообще всю посылку проинвертировать. Но тогда биты наличия датчиков были бы «0». Нелогично.
В данном случае, операция (16 — X) побыстрее, чем (!X & 0xF), наверное :)
В данном случае, операция (16 — X) побыстрее, чем (!X & 0xF), наверное :)
Т.е. 15 — X, конечно.
Я к тому, что интерпретация короткого импульса как 1 и длинного как 0 вроде бы более правильная. В обратном случае контрольная сумма так просто не рассчитывается.
Я к тому, что интерпретация короткого импульса как 1 и длинного как 0 вроде бы более правильная. В обратном случае контрольная сумма так просто не рассчитывается.
Это не биты наличия датчиков, это биты ошибки датчика. Самодиагностика выдала ошибку датчика — единица. Нет ошибки — ноль. Основная ошибка датчика — это его отсутствие, понятно =)
Может быть у них такой протокол из-за набора экзотического кодирования не менее экзотической разрядности.
Что-то вроде — слова (байты) у них BIG ENDIAN, а биты — LITTLE ENDIAN. Встречается такая экзотика в микроконтроллерах. По крайней мере глядя на таблицу что-то такое может подойти. Если при этом ещё и длинна слова 12 бит, то какая раз такая странная картина и получится — на самом деле в ОЗУ эта CRC лежит после данных.
Что-то вроде — слова (байты) у них BIG ENDIAN, а биты — LITTLE ENDIAN. Встречается такая экзотика в микроконтроллерах. По крайней мере глядя на таблицу что-то такое может подойти. Если при этом ещё и длинна слова 12 бит, то какая раз такая странная картина и получится — на самом деле в ОЗУ эта CRC лежит после данных.
С интересом прочитал! Пишите еще, буду ждать
Радиоканал не знаю, а вот у проводных парктроников иногда используют протокол LIN: amber.ssau.ru/download/lin.pdf
Sign up to leave a comment.
Реверс-инжиниринг протокола парктроника. Танец маленьких бит