Реверс-инжиниринг протокола парктроника. Танец маленьких бит

  • Tutorial
Привет, хабр!

В попытках свести все жизненные рабочие показатели своего автомобиля на один экран головного устройства дошла очередь и до подключения парктроника. Многие возразят — ведь даже у дешевых парктроников есть свой экранчик, зачем выводить данные куда-то ещё? Да просто лишний экранчик в салоне ставить не хочется, и покопаться в железе повод есть…

В статье постараюсь описать приёмы и инструменты для реверс-инжиниринга недокументированного протокола обмена двух железок между собой.

Из содержания некоторых публикаций, создаётся впечатление, что, во-первых, стоит выбирать парктроник с радиоканалом между основным блоком и экраном, и во-вторых, ничего сложного в протоколах обмена не ожидается. Хм… ну да. Правдой это оказалось наполовину.

Наличие радиоканала между основным блоком и «блоком индикации» позволяет предположить, что протокол обмена между ними будет простым и последовательным с передачей измеренных расстояний в явном виде. Если бы экран цеплялся напрямую, то, скорее всего, вся логика была бы реализована в одном чипе и на экран шли бы уже команды типа «зажги вот этот пиксель/сегмент и погаси вон тот», без возможности получить непосредственно измеренные расстояния. Окей. Воодушевлённые, идём в «крупнейший кибермаркет» и покупаем там самый дешевый комплект парктроника с самолётами в логотипе. Купили, и тут началось…

Шаг первый. Вскрытие и считывание посылаемых данных


Для начала определимся со способом передачи данных по радиоканалу. Вскрыв основной блок, находим там кругленький чип R433A с совершенно стандартной обвязкой. Приёмника в основном блоке нет, следовательно, канал передачи данных односторонний, с единственно возможной для R433 OOK-модуляцией. Т.е. при наличии высокого уровня цифрового сигнала (логической «единицы») передатчик передаёт в эфир несущую на частоте 433,92 МГц. При отсутствии высокого уровня — передатчик молчит. Со стороны приёмника в блоке индикации аналогичным образом происходит декодирование: если приёмник видит несущую, выдаёт высокий уровень, если не видит — выдаёт низкий. Да, все помехи от парктроника соседа приёмник так же прекрасно ловит, поэтому его чувствительность сильно занижается. И к передаваемым данным, как правило, добавляется контрольная сумма (этот факт нам ещё пригодится ниже).

Нам понадобится цифровой осциллограф-самописец (удобны простые USB-осциллографы, типа DiSco). Находим дорожку, которая идёт от главного микроконтроллера «мозгов» к передатчику в основном блоке или от приёмника к микроконтроллеру в блоке индикации, находим любую «минусовую» дорожку, подпаиваем к ним проводочки, подключаем осциллограф, смотрим:



Вот такую повторяющуюся посылку шлёт основной блок сразу при подаче питания. При внимательном её рассмотрении можно сделать крайне неочевидный вывод о том, что посылка состоит из трёх частей:

  • Первая часть — очевидно, некая синхронизация, чтобы «разбудить» приёмник и чип в блоке индикации. Состоит из пяти импульсов по 0.4 мс с паузами по 0.4 мс и следом одного импульса длительностью 1 мс с паузой 2 мс. Запомним информацию о длительности, она пригодится для реализации собственного декодера.
  • Вторая и третьи части — это непосредственно данные, закодированные в 16 импульсах разной ширины в каждой части (плюс ещё один 0.4 мс импульс в самом конце).

Выясним, каким образом во второй и третьей части закодированы биты. Чередование широких и узких импульсов похоже на Манчестерский код, который применяется, в частности, в сетях Ethernet. Но у манчестера два широких импульса не могут разделяться узким. Поэтому, заметив, что после широкого импульса всегда следует узкая «пауза» и наоборот (при общей длительности импульс+пауза = 1 мс), предположим более простое — ширина импульса непосредственно кодирует логическую единицу (узкий импульс) или ноль (широкий импульс).

Шаг второй. Декодирование ручками


Итак, у нас есть 32 бита данных и 4 датчика. Логично предположить, что на каждый датчик отводится «чуть менее» 8 бит, плюс, вероятно, контрольная сумма (мы ещё помним про контрольную сумму!). И нам нужно понять, каким образом в этих битах кодируются расстояния до препятствий и всё такое. Для начала отключим все датчики и вручную с показаний осциллографа запишем полученную последовательность бит:

10011100 10011100 10011101 01000100

хм… понятно, что ничего не понятно. В отсутствие датчиков логично бы получать все единицы или все нули. Здесь ничего похожего. Подключим датчик A, направив его в пустоту (показания — «бесконечность»):

10011100 10011100 10010011 01001100

изменились последние два байта. В 4-м байте поменялся 1 бит. Видимо, именно он показывает «наличие датчика A»? А в 3-м байте поменялось 3 бита. Причём, если рассматривать их как отдельное 3-битное число, записанное от младшего к старшему биту, можно заметить, что оно увеличилось на единицу: 011+1=100. А единица эта — добавилась к 4-му байту. Отсюда два предварительных вывода:

  • в 3-м байте есть биты, относящиеся к контрольной сумме,
  • контрольная сумма — это простая арифметическая сумма чего-то с чем-то, никаких там CRC и прочих сложностей,
  • данные в целом кодируются не байтами, а 4-битными «нибблами».

Попробуем отключить датчик A и подключить датчик B:

10011100 10011110 01011101 01000100

изменились 2-й и 3-й байты. Шестой бит второго байта (считая от нуля), похоже, «наличие датчика B». Младшие 4 бита третьего байта — тоже контрольная сумма, тоже увеличилась на единицу, появившуюся во втором байте. Но появилась она там не в нулевом и не в четвёртом, а в шестом бите! Уже становится интересно. Пробуем одновременно датчики A и B в «бесконечность»:

10011100 10011110 01010011 01001100

да, кое-что прояснилось. Имеем второй байт, как в посылке «только датчик B» и четвёртый байт из посылки «только датчик A». А вот в третьем байте две 4-битных части из двух предыдущих посылок. Предположение про 4-битные контрольные суммы начинает подтверждаться? Непривычно только то, что контрольная сумма засунута в середину посылки.

Попробуем теперь выставить перед датчиком A (отключив B) препятствие на расстоянии, скажем, 90 см:

10011100 10011100 10011111 01000110

о как, бит «наличие датчика A» больше не показывает нам наличие датчика A. Но в последних 4 битах появился бит в другом месте. И разительно поменялась контрольная сумма. Хотя если сравнить с исходной посылкой без датчиков: 1111-1011 = 100, а последние 4 бита: 0110-0010 = 100. Ура! Совпало!

Тем не менее, дальше становится понятно, что вручную с показаний осциллографа срисовывать эти биты тяжело и велика вероятность ошибиться. Поэтому…

Шаг третий. Декодирование ножками в микроконтроллере


У нас есть микроконтроллер. Ардуино или просто AVR на макетке, неважно. Он у нас есть, кому как не ему собирать все данные для головного устройства. Поэтому самое время написать программку для декодирования посылки от парктроника и передачи этой посылки через терминалку в компьютер для упрощения дальнейшего процесса реверсинга.

Поскольку уровень сигналов от парктроника составляет стандартные 5 вольт, то подключение к AVRке для отладки очень простое — проводом на любую неспециализированную ножку (хмм… может я зря зачеркнул в заголовке?).

Исходник программы доступен на гитхабе. Декодированием занимается функция-обработчик прерывания PCINT3_vect в строке 119 и далее. Остальная часть программы делает много других интересных штук, может быть когда-нибудь я и про это напишу статью. А пока опишу вкратце алгоритм декодирования посылки от парктроника.

У нынешних AVRок почти на каждую ногу можно повесить прерывание, которое будет срабатывать каждый раз при изменении уровня на входе. Т.е. каждый раз при переходе от 0 до 5 вольт и каждый раз при переходе обратно от 5 до 0. Таким образом, достаточно при помощи таймера засекать время между срабатываниями прерывания и фиксировать внутреннее состояние. Состояний может быть несколько: ожидание первых 5 импульсов, ожидание широкого импульса, ожидание паузы, ожидание первых 16 бит (с последующим декодированием в зависимости от длительности импульса), ожидание паузы, ожидание вторых 16 бит, ожидание финального импульса, переход в начальное состояние. Причём всё это реализовано в обработчике прерывания, отнимает каждый раз буквально считанные такты и совсем не занимает главный цикл (правда, занимает отдельный таймер, но это исправимо).

Получившееся устройство по UART выдаёт в терминалку компьютера декодированные значения непосредственно в виде 4х байт. Для упрощения последующего анализа открываем Excel и пишем макрос:

Хабр умеет подсвечивать бейсик?
  Dim lst As Worksheet
  Dim s As String
  Dim v, i, j As Long
  
  Set lst = ActiveWorkbook.ActiveSheet

  For k = 2 To 365
  For i = 1 To 8
    If i Mod 2 = 0 Then ii = i - 1 Else ii = i + 1
    s = "&H0" + Mid(lst.Cells(k, 2).Value, ii, 1)
    v = CDec(s)
    For j = 0 To 3
      If (v And (2 ^ j)) > 0 Then
        lst.Cells(k, 3 + (i - 1) * 4 + j) = "1"
      Else
        lst.Cells(k, 3 + (i - 1) * 4 + j) = "0"
      End If
    Next j
  Next i
  Next k


генерирующий из 4 шестнадцатеричных байт вот такое (разноцветие и подписи, конечно, я уже добавил сам):



очень наглядно стало видно, что биты «наличие датчика» действительно имеются по всем 4-м датчикам и влияют на контрольные суммы соответственно. А пропадание бита датчика A при некоторых показаниях обусловлено чем-то ещё.

Обладая всем вышеописанным инструментарием, опытным путём получаем таблицу по датчику A:



ну всё очень неплохо вырисовывается:
  • Последние 4 бита — десятки сантиметров датчика A. Причём если промоделировать расстояния вплоть до нуля, получится, что нулю десятков сантиметров соответствует 1111 и далее по убывающей, 10+ см = 1110, 20+ см = 1101, 30+ см = 1100 и т.д. вплоть до 0011, соответствующего 130+ см.
  • Отмеченные бледно-розовым два столбца по 2 бита соответствуют единицам сантиметров (заметьте, что для 105, 95 и 85 см биты одинаковы). Причём в первом столбце более старшие биты 4-битного значения. Принцип кодирования тот же: 0 см = 1111, 1 см = 1110 и т.д. вплоть до 9 см = 0110
  • Первая контрольная сумма остаётся неизменной, а вот вторая меняется хитро. Столбец десятков сантиметров влияет на сумму непосредственно, а вот оба столбца единиц сантиметров — влияют только на старшие два бита контрольной суммы.

Соберем аналогичную таблицу по датчику B:



здесь интереснее получается:
  • Два столбца по два бита, кодирующие единицы сантиметров, остаются на своих местах (отмечены светлозеленым). Получается, что, скорее всего, единицы сантиметров выводятся каждый раз для ближайшего к препятствию датчика, а десятки сантиметров — отдельно по каждому датчику. Таким образом, на штатном экранчике выводится расстояние до ближайшего к препятствию датчика с точностью до сантиметра и, грубо, расстояние до остальных датчиков в виде полосочек перед бампером.
  • Десятки сантиметров для датчика B получаются также разбитыми на два столбца по два бита (отмечены «среднезеленым»).
  • Обратившись к инструкции к парктронику, выясняем, что заявленное максимальное фиксируемое расстояние до препятствия — 2.5 метра. А в 4 битах можно закодировать только 1.6 метра. Значит где-то есть пятый бит? И действительно, промоделировав расстояния 1.7 метра и дальше, выясняем, что это второй бит первого байта (отмечен тёмнозеленым). Таким образом, десятки сантиметров датчика B кодируются битами в следующем порядке (от старшего к младшему): 2,1,0,16,15.
  • Меняются значения обоих 4-битных контрольных сумм. Следовательно, биты, связанные с показаниями датчика B, влияют на обе суммы.
  • Первая контрольная сумма чётко изменяется на единицу вместе с изменениями на единицу значения десятков сантиметров. Видимо остальные столбцы, которые тоже включены в эту сумму — среди неизменяющихся по датчику B.


Очередь датчика C:



я уже начинаю мыслить, как китаец:
  • гоньфень джи рёнран суньза ой, то есть единицы сантиметров по-прежнему на своих местах.
  • Десятки сантиметров для датчика C закодированы в пяти битах, которые на этот раз вместе, хоть и принадлежат разным байтам (сиреневый и тёмносиреневый). Принцип кодирования аналогичен предыдущим датчикам.
  • Первая контрольная сумма (первые 4 бита) чётко изменяется на единицу вместе с изменениями на единицу значения десятков сантиметров. Аналогично датчику B. Следовательно, предварительный вывод: в первую контрольную сумму входят значение десятков сантиметров датчика B и датчика C (вероятно, без пятого бита) и что-то ещё. Интуиция подсказывает, что это младшие 4 бита последнего байта. Проверим ниже.


По датчику D собирать подробную таблицу стало лениво, поэтому так:



что ж, все гипотезы подтвердились. Первые 4 бита последнего байта кодируют десятки сантиметров датчика D.

Для проверки промоделируем несколько сочетаний датчиков A и B:



да, всё совпадает.

На данном этапе мы можем полностью декодировать расстояния по каждому датчику, включая единицы сантиметров. И наличие/отсутствие датчиков. Может быть, этого достаточно? Хм. Кажется что-то ещё недораскопано…

Шаг четвёртый. Расчёт CRC (Chinese Redundancy Check)


Итак, что мы уже знаем про местные контрольные суммы:
  • Их две, по 4 бита, находятся почему-то не в последнем, а в третьем байте.
  • Каждая из них является простой арифметической суммой данных из других столбцов.
  • Предположительно известна принадлежность некоторых бит к конкретным контрольным суммам.


Отметим известную на данный момент принадлежность на выборке каких-нибудь произвольных показаний:



попробуем просуммировать по первой строке, возьмём столбцы десятков сантиметров датчиков B, C и D:

1110 + 0111 + 0011 = 11000

хм, а контрольная сумма в третьем байте 0111. А что если минус один?

1110 + 0111 + 0011 — 1 = 10111

совпадает, если отбросить лишний бит. Проверим по другим строкам:

1110 + 0111 + 0011 — 1 = 10111 (ой, тут всё повторилось)
0101 + 0111 + 0011 — 1 = 0111 (тут без отбрасывания)
1111 + 1100 + 1100 — 1 = 100110 (тут аж два бита переполнилось)
0001 + 0101 + 0011 — 1 = 1000 (без отбрасывания)

ура, всё совпало!
У нас остались не отмеченные столбцы. Вероятно, они относятся ко второй контрольной сумме, поэтому попробуем просуммировать:

1010 + 1011 + 0011 = 11000
1110 + 0111 + 0101 = 11010
1110 + 0011 + 1000 = 11001
1111 + 1111 + 0111 = 100101
1111 + 1011 + 0111 = 100001

мда, маловато общего с второй контрольной суммой. Посмотрим, сколько нужно вычесть, чтобы совпало:

1010 + 1011 + 0011 — 10 = 10110
1110 + 0111 + 0101 — 10 = 11000
1110 + 0011 + 1000 — 11 = 10110
1111 + 1111 + 0111 — 01 = 100100
1111 + 1011 + 0111 — 11 = 11110

где-то я это уже видел… а, ну да, у первой контрольной суммы! Зависимость простая — от второй КС нужно отнять то, что мы отбросили как переполнение при расчёте первой КС, только xor'енное с 11. Т.е. отбрасывая 00 (ничего) от первой КС, от второй отнимаем 11 и т.д.

Уфф, вроде всё. Осталось два незадействованных бита, но они, похоже, всегда единицы.

Шаг пятый. Чистка радиоэфира


А вообще я не сторонник применения радиоканалов где попало. Эфир и так прилично загажен, так что работать это всё будет местами (географическими) довольно нестабильно. Поэтому займёмся тем, что выкинем из парктроника приёмник и передатчик, соединив базовый блок, блок индикации и наш микроконтроллер по проводам. Почему я упоминаю блок индикации, хотя не собирался его ставить? А из-за пищалки. Всё-таки передача от базового блока парктроника в наш микроконтроллер, там декодирование, затем пересылка в головное устройство, там снова декодирование и отрисовка внесёт некритичный, но заметный лаг в отображение расстояний. Поэтому блок индикации останется в недрах приборки и будет пищать заведомо быстрее (хотя в будущем, может быть, заставлю пищать свой микроконтроллер).

Можно было бы не париться и соединить все блоки проводочками прямо как в отладочном режиме, напрямую. Однако прокидывать через всю машину жалкие 5 вольт TTL, поверьте мне, не лучшая идея. Поэтому впаяем во все три устройства микросхемы MAX485, реализующие передачу по куда более надёжному интерфейсу RS-485. В общем как-то так (простите за неотмытый флюс). Базовый блок:



на месте белого кружка в правом верхнему углу платы стоял чип R433A, из его обвязки также удалён транзистор Q11 и резистор, вместо которого припаян проводок. А в свободном месте удалось расположить микросхемку так, что ножки попали на минусовой контакт и несколько других подходящих контактов. Поскольку базовый блок всегда является передатчиком, ножки DE и RE можно постоянно замкнуть на +5 вольт. Линии A и B интерфейса RS485 выведены на дополнительную клемму.

Блок индикации:



ну здесь вообще красота, MAX485 впаялась практически как родная вместо стоявшей микросхемы приёмника RF83C. Совпали ножки выхода данных DO и минусовая GND, ножки DE и RE, поскольку эта часть всегда приёмник, посажены на землю. Остальное потребовало всего одной перемычки.

Работает, как и прежде:



фотку собственного микроконтроллера, пожалуй, опубликую в статье про остальную часть функционала KMENevoBT с гитхаба.

Напоследок, код полного декодирования посылки от парктроника из отладочной программки на Delphi:

Ну не бейте, это всего-лишь отладочный код на коленке
procedure TfrmKMEmul.UpdatePT(a, b, c, d: Byte);
var
  cm, la, lb, lc, ld, crc1, crc2: integer;
begin
  cm := $F - ( (a shr 2) and $C + (b shr 4) and $3 );
  la :=  (d shr 4) and $F;
  lb := ((a and 7) shl 2) + ((b shr 6) and $3);
  lc := ((a shr 6) and $3) + ((b and $7) shl 2);
  ld := (d) and $F;
  crc1 := ((lc and $F + lb and $F + ld) - 1);
  crc2 := ((a shr 2) and $F) + ((b shr 2) and $F) + ((d shr 4) and $F);
  crc2 := crc2 - ((crc1 shr 4) xor $3);

  la := $F - la;
  lb := $1F - lb;
  lc := $1F - lc;
  ld := $F - ld;

  lbCM.Caption := IntToStr(cm);
  lbA.Caption := Format('%.1f', [la/10]);
  lbB.Caption := Format('%.1f', [lb/10]);
  lbC.Caption := Format('%.1f', [lc/10]);
  lbD.Caption := Format('%.1f', [ld/10]);

  if la = $F - $2 then lbA.Font.Color := clRed else lbA.Font.Color := clGreen;
  if lb = $1F - $4 then lbB.Font.Color := clRed else lbB.Font.Color := clGreen;
  if lc = $1F - $4 then lbC.Font.Color := clRed else lbC.Font.Color := clGreen;
  if ld = $F - $2 then lbD.Font.Color := clRed else lbD.Font.Color := clGreen;

  if crc1 and $F = c and $F then lbCRC.Caption := 'OK' else lbCRC.Caption := 'BAD';
  if (crc2 and $F = (c shr 4) and $F) then lbCRC2.Caption := 'OK' else lbCRC2.Caption := 'BAD';
end;



Шаг шестой. Выводы


Возможно, в какой-то момент стоило отказаться от дальнейших раскопок и заказать с Ebay тот же парктроник, который расковырял итальянец с форума по первой ссылке, но мне понравился сам парктроник. Он весьма быстро и точно работает. Пришлось добить, уже из принципа.
Что курили китайцы, разрабатывая такой вот протокол, непонятно.

Лирическое отступление
Довелось мне несколько лет назад раскопать протокол диагностики автомобилей Форд с мозгами EEC-IV. Это такие мозги на основе интеловского набора 8096, кажется. В общем, древность на уровне чуть-ли не 8086. Ставилось это на форды с середины 80х и по начало 2000х, где-то с начала 90х там был реализован протокол диагностики Data Communication Link (DCL). Так вот, скорее всего из-за ограничений производительности невозможно было сделать протокол обмена с асинхронным обменом данными, как COM-порт компьютера. Поэтому протокол был синхронный. Это означало, что при активации диагностики мозги начинали слать по линии данных «фреймы», состоящие из строго синхронизированных по времени байтслов. Для общения с мозгами необходимо было с точностью в десятки микросекунд засылать свои слова в указанные промежутки между принимаемыми словами. Никакой компьютер с COM-портом не обеспечивал требуемой точности отправки байт. Пришлось делать на микроконтроллере…
Хм, так о чём я… А, вот. В том случае такой интересный протокол обмена был оправдан ограничениями чипа. В случае с этим парктроником я не вижу никакой логики именно такого «танца» бит. Что мешало расположить, к примеру, 4х4 бит десятков сантиметров, затем 4 бита единиц сантиметров, ещё 4 бита на расширение до 5 бит датчиков B и C и всякие служебные и в конце контрольная сумма всех бит (просто сумма, без извращений, в крайнем случае стандартная CRC8).


Кстати, зная протокол обмена, можно применить этот парктроник не только на автомобиле, а, к примеру, на самодельном роботе. Да, для роботов есть отдельные ультразвуковые датчики, но тут их сразу четыре и читаются они одной ножкой ардуины, хоть и с задержкой в несколько миллисекунд.

Всем дочитавшим всего наилучшего!

P.S. Хотел опрос добавить насчёт писать ли про раскопки протокола мозгов для газового впрыска KME Nevo Pro. Там несколько другие приёмы использовались… Но думаю, скорее надо спрашивать насчёт «а нужны ли на хабре такие околоавтомобильные изыскания?».
Поделиться публикацией
Комментарии 29
    +16
    1. Обязательно пишите. 2 Да.

    С форком ресурса в сторону школьного кружка и курилки для балаболов читать профильные хабы стало интересно (т.к. пишут те, кому действительно интересно «угореть по хардкору»). Ну а автомобильная электроника на уровне железок и софта — это не хардкор, а “ultra violence“. Просто в силу того, что одновременно в ней живут вещи из разных технологических эпох.
      +1
      Не хуже Пляшущих человечков. Настоящая черепаха. Распознавание битов с осциллографа через видеокамеру смартфона не пробовали? Шучу…
        +1
        Со смартфоном было бы уже излишество (хотя я делал кое-что на OpenCV недавно :)
        Если бы не необходимость подключения «ардуинки», я бы воспользовался встроенным лог.анализатором осциллографа. Там 16 каналов и настраиваемый декодер байт.
      • НЛО прилетело и опубликовало эту надпись здесь
          +9
          Chinese Redundancy Check — сделало мой день :)
            0
            У вас осцилограмма смещена вниз или же это в устройстве ассиметричные уровни (-0,7 — 0.2)?
              0
              Осциллограф двухканальный. Слева шкала от отключенного «красного» канала. От «синего» — справа, на которой 0-5 Вольт, как и полагается.
              +1
              creat0r, Вам большой жирный плюс (не хватает кармы проголосовать за статью). Уже года полтора под столом валяется парктроник без экрана и все это время я ждал именно этой статьи, что бы прикрутить туда экран на своем контроллере. Спасибо, пошел цеплять осцилограф к своему парктронику.
                +10
                За зачистку радиоэфира респект.
                  +6
                  Спасибо, сэнсэй :)
                  Всё началось с изиэлектроникса, в своё время.
                  0
                  Хм. Возможно, это сделано чтобы затруднить реверс и оставить простоту протокола(без шифрования), а может всё куда обоснованней — чтобы в случае помех были повреждены разные части передаваемых данных и повысилась вероятность обнаружения ошибки.

                  Кстати, не увидел индивидуального кода, это же получается что… если вдруг две машины будут парковаться одновременно рядом с одинаковым парктроником то у них ничего не получится. будут попеременно воспринимать то свои данные то соседа то вообще ничего.
                    0
                    Во время получения посылки по радиоканалу вероятнее всего словить одиночную мощную помеху, которая задавит напрочь несколько бит подряд. Такое повреждение способна отловить любая контрольная сумма, не важно, считается ли она целиком от всех данных, или чередуясь через два бита. Насчёт затруднения реверса — тоже вряд ли. Уж для затруднения столько напридумывать можно. К примеру, перестановку битов по маске или XOR их между собой. Да даже простое шифрование сделать, зашив ключи в оба блока.

                    Индивидуального кода нет, вся надежда на специально загрубленную чувствительность приёмника при относительно мощном передатчике и экранирование канала передачи данных внутри цельнометаллического кузова авто. Но вообще да, применение радиоканала в данном случае — оправдано только ленью и способностью китайцев сначала сделать, а потом подумать «а может не стоило?». Протащить провод через салон можно практически в любом авто.
                      0
                      Ключи в обоих блоках это усложнение процесса сборки(надо индивидуально прошивать блоки ключами, причем еще парно) и увеличение времени сборки — это лишние сложности которые ведут к удорожанию.
                      С защитой от реверса — та же фигня, время на разработку сильно ограничено и порой что-либо выдумывать просто нет времени. Вот взяли и реализовали простую перестановку бит. Кстати, это может и являться индивидуальным кодом — в другом комплекте биты могут быть переставлены уже совсем по другому.
                        +1
                        Ну, ключи либо необязательно индивидуальны для каждого комплекта, либо могут зависеть от какого-то общего параметра схем обоих блоков на момент производства.

                        Если кто купит другой комплект и попробует получить данные, пусть напишет, как там переставлены биты. Интересно же.
                    0
                    Хотелось бы попросить у автора (надеюсь правилами хабра это не возбраняется) ссылку на статью, где можно почитать, как AVR-ку или Arduino использовать для считывания всяких автомобильных показаний (наподобие открытия двери, капота, может каких-то датчиков (масла, температуры и т. д.))
                    Спасибо.
                      0
                      Это слишком обширная тема. У каждого автомобиля будет свой подход к считыванию показаний.
                      Для примера, концевики открытия дверей и капота зачастую вообще отсутствуют и ставятся вместе с сигнализацией уже сторонними фирмами, не на заводе. Тогда всё зависит от типа сигналки.
                      Но, при этом, у некоторых современных автомобилей высокого класса мало того, что эти концевики есть с завода, они ещё и висят на бортовой CAN-шине и считываются только модулем CAN, подключенным на эту шину.

                      То же самое с датчиками двигателя (масла, антифриза, ...). Либо некоторых из них нет вообще (температуры масла, скажем), тогда их надо ставить дополнительно и подключать к ардуине напрямую, либо снимать сигнал параллельно подключению его к штатным блокам управления автомобиля, либо считывать эти показания из блока управления двигателем по протоколам OBD-2.

                      В упомянутом в статье проекте KMENevoBT сделано чуть иначе. Газовые мозги KME Nevo Pro имеют встроенный модуль OBD-2 для подключения к заводским бензиновым мозгам. Таким образом по протоколу KME из газового мозга читаются и все показатели по газу и, заодно, все показатели по бензину (с небольшим лагом, правда).
                        0
                        Там электрически все просто, сложности начинаются в таблице используемых кодов, они не очень-то распространяются производителями и могут сильно отличаться для разных производителей.
                          0
                          Возьмите для начала книжку Practical Arduino (на Амазоне или, если денег жалко, на торрентах) и возьмите оттуда главу про OBD.

                          Сайт книги — www.practicalarduino.com/projects/vehicle-telemetry-platform
                          0
                          А какая минимальная дистанция обнаружения у этого парктроника? Если 30 см как у всех дешевых, то по-моему не стоило так из-за него заморачиваться.
                            +1
                            30 см, да. Не вижу смысла парковаться ближе. В крайнем случае после фиксации 30 см всегда можно сдвинуться ещё на 10-15 см «на глаз».
                            Вот для переднего парктроника не подходит, для манёвров в стеснённом пространстве по краям переднего бампера желательно было бы и поближе расстояния фиксировать.
                            0
                            Отмеченные бледно-розовым два столбца по 2 бита соответствуют единицам сантиметров (заметьте, что для 105, 95 и 85 см биты одинаковы). Причём в первом столбце более старшие биты 4-битного значения. Принцип кодирования тот же: 0 см = 1111, 1 см = 1110 и т.д. вплоть до 9 см = 0110


                            Проинвертировать не пробовали?
                              0
                              Да, можно было бы вообще всю посылку проинвертировать. Но тогда биты наличия датчиков были бы «0». Нелогично.
                              В данном случае, операция (16 — X) побыстрее, чем (!X & 0xF), наверное :)
                                0
                                Т.е. 15 — X, конечно.
                                Я к тому, что интерпретация короткого импульса как 1 и длинного как 0 вроде бы более правильная. В обратном случае контрольная сумма так просто не рассчитывается.
                                  0
                                  Это не биты наличия датчиков, это биты ошибки датчика. Самодиагностика выдала ошибку датчика — единица. Нет ошибки — ноль. Основная ошибка датчика — это его отсутствие, понятно =)
                                    0
                                    Осталось с такой же уверенностью попробовать рассчитать контрольные суммы из инвертированных бит :)
                                      0
                                      Не надо инвертировать биты. Надо просто инвертировать ваше понимание их значения.
                                +2
                                Может быть у них такой протокол из-за набора экзотического кодирования не менее экзотической разрядности.
                                Что-то вроде — слова (байты) у них BIG ENDIAN, а биты — LITTLE ENDIAN. Встречается такая экзотика в микроконтроллерах. По крайней мере глядя на таблицу что-то такое может подойти. Если при этом ещё и длинна слова 12 бит, то какая раз такая странная картина и получится — на самом деле в ОЗУ эта CRC лежит после данных.
                                  +1
                                  С интересом прочитал! Пишите еще, буду ждать
                                    0
                                    Радиоканал не знаю, а вот у проводных парктроников иногда используют протокол LIN: amber.ssau.ru/download/lin.pdf

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое