Подключение парктроников к can шине

Добавил пользователь Валентин П.
Обновлено: 19.09.2024

Всем привет, друзья. Нашёл описание по интеграции нештатных парктроников с CAN-шиной для автоматического включения/выключения, в зависимости от скорости.

Как считаете, осуществимо на наших авто?

Тут украинцы интегрировали со штатным park assistant

Upd — парктроники пришли, были покрашены и установлены.

Исправно включаются при скорости менее 15 км/ч. (издают только звуки при нахождении препятствия).

P.S. бампер резать стало жалко, врезались в переднюю губу обвеса от ОД.

P.S.S. как Украинцы (cсылка на YouTube

Toyota Land Cruiser Prado 2020, двигатель бензиновый 2.7 л., 166 л. с., передний привод, автоматическая коробка передач — электроника

Машины в продаже

Комментарии 15

Я из Алматы, подскажите где ставили передние парктроники и по какой цене?

Из МСК заказал, а ставил у электриков на Старлайн.

Я из Алматы, подскажите где ставили передние парктроники и по какой цене?

Тысяч 65 на наши вроде, там ещё бывают изнутри клеятся, как заводские, но не было в наличии нигде.

Оно та да, но хотелось, чтоб всё было по фен шую!)))

Я из-за этого ролика также взял себе парктроники gazer, только для их подключения к голове нужна ещё какая то приблуда! Якобы они сами её изготавливают и купить отдельно её невозможно! Я думаю просто не рассказывают, чтоб у них устанавливали!

Ну да ладно, звукового хватает сигнала.

Как можно подключить парктроники gazer к штатной голове?

Добрый день. Тут не знаю. Ребята с Украины делали.

Если узнаёте, просьба также поделиться.

Ссылки кажется не работают.
На экран выходит изображение?

Доброго дня.
На экран не выводит (

На Хайлендере стояли передние парктроники — практически постоянно держал их выключенными так как в пробке на Аль-Фараби 😉, если стоять близко к впереди стоящей машине, они замучают своими сигналами. А если подъехал к стене то постоять с заведённым двигателем (а летом по другому никак) тоже не получится — постоянно будут пищать. Короче по мне, с учетом высокого клиренса Прадо, передние парктроники это бесполезная функция. Конечно если она есть с завода то пусть будет а специально их ставить я бы не стал.

"интеграция" — такие красивые выражения, и всё ради одного сигнала скорости. Проще непосредственно к датчику подключиться.
Кстати, есть ещё один нюанс, связанный с удобными/красивыми терминами, — если их откинуть, как бы сбросить шелуху, и сказать как есть, то это будет звучать так — подключение постороннего устройства к штатной шине данных авто. Звучит уже не так круто, но зато правда.
Я вот себе задумал пару сканеров отпечатка внедрить (электроника готова, осталось установить), вот это действительно пример нехилой "интеграции", причем такой, что для любого установщика из любого именитого центра по установке сиг это стало бы непосильной задачей ещё на этапе осмысления.

Какие нежные вокруг люди в интернете )) коробит что-то — будте добры — проходите мимо )) Вова.

Я не понял, вы уже поставили их? А где интересно в Ате? Камеру не собираетесь ставить?

Приветствую! Да, поставил. В starline у знакомых ребят. Парктроники заказывал из МСК.
Камеру ставил — снял, не понравился вид.

Всем привет! Я обзавелся комплектом передних и задних парктроников и решил взглянуть в интернете как их подключить так как проводов там много. Пришлось немножко попотеть но нашел схемки и несколько фото-отчетов.
Пока что только теория, установка будет ниже

И ВОТ СОБРАННАЯ МНОЮ ИНФОРМАЦИЯ

1. СХЕМА Одолжил на Yetti клубе, цвета в основном должны совпадать но могут быть некоторые несовпадение. Разъёмы блока парктроника обозначены T12j, T12h и T16к. Разъём Т81 используется для подключения передних парктроников в подкапотном пространстве. (ВАЖНО! если неправильно подключить хоть один из датчиков, или одного датчика будет не хватать, или не подключен динамик то система работать не будет. Раздастся просто разовое срабатывание динамика)

Ещеодна схема. Тут видно распиновку кнопки. Пригодится если кнопка не работает.

2. ОБЩИЙ ВИД ПАРКОВОЧНОЙ СИСТЕМЫ Тут я выложил всю проводку.

3. ПРОВОДКА 16-ПИНОВОГО РАЗЪЕМА Т16к Именно тут есть провода CAN которые вызывают наибольшее количество вопросов. Как можно видеть провода CAN и питание кнопки имеют нехитрую схемку со штекером для параллельного подключения. О подключении мы и будем говорить

4. РАЗЪЁМЫ БЛОКА ПАРКТРОНИКА Тут наглядно все подписано

5. БЛОК GATEWAY CAN шина это приспособление для цифрового управления системами автомобиля с помощью всего одной пары проводов для каждой системы вместо километров проводки как это было раньше. Все CAN провода заходят в Gateway через красный разъём который нам и нужен, точнее 6 и 16 пины.

6. ПОДКЛЮЧЕНИЕ К CAN Тут используем вспомогательный чёрный 3-пиновый разъём которым параллелим провода 6 и 16 pin. Для этого провода которые вынули из красного разъёма gateway вставляем в чёрный 3-пиновый разъём а на их место втыкаем провода CAN от парктроника. Затем черный 3-пиновый разём собираем обратно.

Подключение осциллографа полностью подтвердило эту гипотезу:

Канал A — CS, B — CLK, D — DATA.

Пару выходных дней, несколько вечеров и у меня был уже готовый прототип на макетке (с ардуино-nano), который уверенно получал данные от основного блока парктроника и производил их декодирование. Выбор парктроника оправдался — даже уровни согласовывать не пришлось.

После этого парктроник был установлен в автомобиль и основное место разработки переместилось туда.

Часть вторая: Слушаем

Схема устройства совершенно не блещет какой-то оригинальностью: используются типовые схемы включения всех составляющих (из их даташитов). На всякий случай вывел почти все свободные порты ввода-вывода на дополнительный разъем (вдруг что-то еще придет в голову в процессе реализации?). Естественно, для программатора развел ICSP.

На первом этапе решил (для простоты) подключиться к диагностическому разъему, благо в нем MS-шина присутствует. Где именно в разъеме следует искать, подсмотрел тут.

Часть третья: Говорим

Собрал дома небольшой тестовый стенд, состоящий из моего устройства и этого дисплея. Отработка на стенде — значительно комфортнее, чем в машине, зимой на улице.

Параллельно нашел замечательный комментарий:

You can send the 3 frames with the following IDs:
0x28F: LCD settings and probably some other settings (you just send the same data you receive in a normal 0x28f frame).
0×290: 0xC0 (first byte) followed by first 5 alfanum signs
0×291: 0×85 (first byte) followed by the next 7 alfanum signs

all of them, just after you receive the 0×291 frame id sent by the HU. This will make your text being visible with almost no flicker at all.
The reason for sending the 0x28F is that it is required for displaying the 0×290 and 0×291 text, otherwise the LCD seems to simply ignore the 0×290 and 0×291.
Another method would be to set a timer with a 150ms interrupt and send the 3 frames described above.

0x28F frame content that I have used:
hex: D1 00 00 00 80 00 00 01

Таким образом, для того, чтобы дисплей отобразил передаваемый текст нужно передавать три посылки (при первых тестах я передавал только две и из-за этого дисплей отказывался отображать мой текст).

Часть четвертая: Логика

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

В домашних условиях написал основную часть кода, на тестовом дисплее все выглядело более-менее прилично. Но после визита в машину, вылезли серьезные…

В общем, работает, но совсем не так, как хотелось бы.

Получилось вот такое устройство:

Часть шестая: Тесты

На видео видно, что вывод практически идентичен, и в некоторых случаях на дисплее Mazda информация появляется на доли секунды раньше (что совсем неплохо).

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

И тут обнаружилась следующая проблема:

Пропала информация блока климат-контроля (правая часть дисплея). Как оказалось, это не единственная пропажа — маршрутный компьютер тоже отказался показывать свою информацию.

0x38A обязательная отправка, без этого не работает маршрутник
0x400 данные маршрутника
0x3BA климат
0x201 текущие параметры (скорость, обороты)

После того, как в код прошивки добавлены правила для прямой трансляции собщений с этими идентификаторами на дисплей — все заработало так, как надо.

Часть седьмая: "… и поскакал!"

В процессе поиска различной информации зарегистрировался на форуме владельцев Mazda5 — поделился своими наработками, показал, как получается. Оказалось, что этот проект интересен не только мне. В конференции помогали искать необходимую информацию, подсказывали возможные функции.

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

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

Вообще о процессе поиска данных надо рассказать более подробно - это может показаться интересным (и полезным для подобного реверсинжиниринга).

Раз данные есть — нужно их как-то использовать.

Сразу же добавил своему модулю функцию оповещения о незакрытых дверях на скорости выше 10 км/ч.

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

Потом вспомнил, что на Peugeot была штатная функция автоматического запирания дверей на скорости. Очевидно, что тут тоже такую же функцию добавить… но уже не на прототипе (к сожалению, управление центральным замком в Mazda невозможно через CAN-шину, хотя в некоторых других машинах это вполне реально).

Естественно, пригодились все полученные знания в процессе создания и эксплуатации прототипа (тот же резистор на 120Ом в CAN-шине для работы дисплея).

При этом получилось, что все подключения к проводке машины можно было сделать непосредственно за дисплеем (там очень объемная пустая ниша и присутствуют все необходимые сигнальные провода).

Часть восьмая: Продакшн

Устройства произвели не слишком оперативно — на это ушло почти 3 недели. Но почта увеличила срок ожидания еще почти на месяц. Но не будем о грустном, поскольку получилось неплохо:

Часть девятая: Настройки

Вообще было достаточно сложно и интересно было придумывать реализацию такого меню, когда доступен дисплей в одну строку и всего в 12 символов.

Несколько дней тестировал изделие в своем авто — никаких нареканий, все работает отлично.

Часть десятая: Продолжение?

На текущий момент все платы отправлены их новым владельцам. Как только они будут установлены, надеюсь, получу дополнительные отзывы.
Перед отправкой успел одну из плат подключить к Mazda CX-7 — почти все заработало сразу (некоторые данные маршрутного компьютера закодированы чуть иначе), но в целом — подключение прошло успешно.
Сейчас устройство (с текущей прошивкой) проверено на Mazda3, 5, 6 (там где дисплеи похожи на те, что я использовал в процессе разработки).

После адаптации прошивки, думаю, устройство может оказаться полезным практически на любом современном авто, где вывод на дисплей (или приборную панель) осуществляется через MS-CAN.

Часть последняя: Arduino?

Ответ очень прост: все программирование я делал в среде Arduino.

В этой статье я расскажу как собрать свою уникальную виртуальную или цифровую панель приборов и получить данные с любых датчиков в автомобилях группы VAG (Volkswagen, Audi, Seat, Skoda).

Мною был собран новый CAN сниффер и CAN шилд для Raspberry Pi на базе модуля MCP2515 TJA1050 Niren, полученные с их помощью данные я применил в разработке цифровой панели приборов с использованием 7″ дисплея для Raspberry Pi. Помимо простого отображения информации цифровая панель реагирует на кнопки подрулевого переключателя и другие события в машине.

В качестве фреймворка для рисования приборов отлично подошел Kivy для Python. Работает без Иксов и для вывода графики использует GL.

CAN сниффер из Arduino Uno
Подслушиваем запросы с помощью диагностической системы VAG-COM (VCDS)
Разработка панели приборов на основе Raspberry Pi и 7″ дисплея
Софт панели приборов на Python и Kivy (UI framework)
Видео работы цифровой панели приборов на базе Raspberry Pi

CAN сниффер из Arduino Uno

Чтобы послушать, что отправляет VCDS в CAN шину я собрал сниффер на макетке из Arduino и модуля MCP2515 TJA1050 Niren.

Схема подключения следующая:

CanHackerV2 позволяет смотреть пролетающий трафик, записывать и проигрывать команды с заданным интервалом, что очень сильно помогает в анализе данных.

Подслушиваем запросы с помощью диагностической системы VAG-COM (VCDS)

Программно-аппаратный сканер VCDS предназначен для диагностики электронных систем управления, устанавливаемых на автомобилях группы VAG. Доступ ко всем системам: двигатель, ACP, АБС, климат-контроль, кузовая электроника и т.п., считывание и стирание кодов неисправностей, вывод текущих параметров, активация, базовые установки, адаптация, кодирование и т.п.

Подключив сниффер к линиям CAN_L и CAN_H в диагностическом шнурке я смог увидеть какие запросы делает VCDS и что отвечает авто.

Особенность авто группы VAG в том, что OBD2 разъем подключен к CAN шине через шлюз и шлюз не пропускает весь гуляющий по сети трафик, т.е. подключившись в OBD2 разъем сниффером вы ничего не увидите. Чтобы получить данные в OBD2 разъёме нужно отправлять шлюзу специальные запросы. Эти запросы и ответы видно при прослушивании трафика от VCDS. Например вот так можно получить пробег.

В VCDS можно получить информацию почти с любого датчика в машине. Меня в первую очередь интересовала информация, которой вообще нет на моей приборке, это:

температура масла
какая именно дверь открыта

Разработка панели приборов на основе Raspberry Pi и 7″ дисплея

В качестве аппаратной части я выбрал Raspberry Pi. Была идея использовать Android планшет, но показалось, что на Raspberry Pi будет проще и быстрее. В итоге докупил официальный 7″ дисплей, и сделал CAN шилд из модуля TJA1050 Niren.

OBD2 штекер использовал от старого ELM327 адаптера.

Используются контакты: CAN_L, CAN_H, +12, GND.

Тесты в машине прошли успешно и теперь нужно было все собрать. Плату дисплея, Raspberry Pi и блок питания разместил на куске черного пластика, очень удачно подобрал пластмассовые втулки, с ними ничего не болтается и надежно закреплено.

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

Напильником довел лист черного пластика до размера крышки бардачка, к нему прикрепил бутерброд и дисплей. Для прототипа сойдет, а 3D модель с крышкой для дисплея и всеми нужными крепежами уже в разработке.

Софт панели приборов на Python и Kivy (UI framework)

Параллельно со сборкой самой панели приборов я вел разработку приложения для отображения информации с датчиков. В самом начале я не планировал какой либо дизайн.

Первая версия панели приборов

По мере разработки решил визуализировать данные более наглядно. Хотел гоночный дизайн, а получилось, что-то в стиле 80-х.

Вторая версия панели приборов

Продолжив поиски более современного дизайна я обратил внимание какие цифровые приборки делают автопроизводители и постарался сделать что-то похожее.

Третья версия панели приборов

Ранее, я никогда не разрабатывал графические приложения под Linux поэтому не знал с чего начать. Вариант на вебе простой в разработке, но слишком много лишних компонентов: иксы, браузер, nodejs, хотелось быстрой загрузки. Попробовав Qt PySide2 я понял, что это займет у меня много времени, т.к. мало опыта. Остановился на Kivy — графический фреймворк для Python, простой в понимании с полной библиотекой графических элементов и дающий возможность быстро создать мобильный интерфейс.

Kivy позволяет запускать приложение без Иксов, прямо из консоли, в качестве рендера используется OpenGL. Благодаря этому полная загрузка системы может происходить за 10 секунд.

Алгоритм работы следующий, используется 3 потока:

В главном потоке работаем с графическими элементы (спидометр, тахометр, часы, температуры и др) на экране
Во втором потоке каждые 5 мс делаем опрос следующего датчика
В третьем потоке слушаем CAN шину, получив ответ парсим его и обновляем соответствующий графический элемент

Проект цифровой панель приборов открытый. Рад буду предложениям и комментариям!

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

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

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

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

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

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

10011100 10011100 10011101 01000100

10011100 10011100 10010011 01001100

10011100 10011110 01011101 01000100

10011100 10011110 01010011 01001100

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

10011100 10011100 10011111 01000110

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

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

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

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

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

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

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

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

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

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

Очередь датчика 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:

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

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

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

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

Читайте также: