Pull to refresh

Comments 224

Клево!
Только одно уточнение, основная прелесть ваговской реализации (в частности VCDS) не только в том, чтобы получать данные, но и вносить изменения в настройки, вплоть до очень тонких. То есть, не только настроить «сколько сигналов поворотника дать при легком нажатии переключателя», но и внести различные коррективы в режимы работы устройств подключенных к этой шине. Например догреватель вебасто, положение кузова/пневмоподвески, калибровка фар и тп и тд
PS: Еще вспомнил пару интересных вещей. Если модель ВАГ-а оборудована датчиком дождя, электростеклоподьемниками и/или люком, то в некоторых моделях через VCDS (или «Васю») можно активировать функцию автозакрытия стекол, при срабатывании этого датчика.
Активировал много фич через VCDS которые не положены моей комплектации. Хотел активировать автоматическое опускание правого зеркала при заднем ходе, но оказалось, что для этого нужен другой механизм зеркала. А в целом VAG нравится, с детства люблю конструкторы.
С зеркалами да, есть такие нюансы. Автоскладывание при постановке на охрану, мне так и не удалось сделать.
насколько я знаю, эта опция связана не с механизмом зеркала (штатный электромеханизм запросто его опустит), а с наличием памяти сиденья. эти опции связаны в по.
Скорее, это связано с датчиком положения зеркала. Т.е. для обычной регулировки нужен только моторчик, за положением следит сам водитель (максимум — концевики надо поставить, чтобы в конце хода ничего не сломать и не сжечь), а чтобы автоматически опустить зеркало и потом поднять его обратно ровно в то же положение, надо измерять, насколько именно оно опустилось и поднялось. В комплектациях «с памятью» эти датчики, очевидно, тоже нужны (но уже везде, не только в зеркалах).
Ничего подобного, у меня на Йети этой функции штатно нет так как нужно сиденье водителя с электроприводом и памятью. Однако мы с товарищем с помощью Васи активировали эту функцию. Теперь при включении задней передачи, зеркало (правое пассажирское) опускается, а при движении вперед возвращается на место. Только надо рычажок управления зеркалами поставить на правое зеркало, в других положениях функция не включается
Кстати, я рычажок не пробовал ставить на правое зеркало, может тоже заработает. Через Васю активировал функцию, но результат не было.
Я на драйве читал, что нужно ставить мезанизм с памятью положения, чтобы это заработало. А так регулировка все равно осуществляется по Кан шине.
Через драйв и нашел эту инфу. Работает только когда рычажок на правом зеркале. Это ВАГ ставит эту опцию в комплекте с электро механизмом и памятью кресел. Но повторюсь на моем авто работает
у меня нет памяти кресел но зеркало опускается когда рычажок на правом положении

Вам повезло — попался подходящий для этого блок зеркала. Мне не повезло )
Из полезного, на йети сделал подсветку в поворотах (работает за счёт противотуманок, фича от Тигуана).
Хочу ещё поменять кондиционер на климат. Блок управления стоит относительно дёшево (в пределах 10 тыс на разборах), правда попадаются в основном от фольцев, поэтому придется подсветку на зелёный перепаивать.

Ну на машинах 12-го года выпуска это делается. А подсветка это стандартная фишка всего VAGа (и на Сеате, и на Шкоде), на всех машинах концерна можно сделать. Кондер я тоже думал поменять, но не только блок надо заменить, там гораздо больше переделывать надо и влетает в копеечку
C подсветкой, только если электрика позволяет. На фабии, например, не позволяла, хотя можно было кинуть отдельный провод от одной из туманок.
По поводу климата на йети (2012г), насколько узнавал, только блок управления и пару датчиков воткнуть. Все остальное уже и так управляется электроникой, все заслонки сервофицированны, только команды отдает не контроллер а человек.
Ну и в бортовой компьютер прописать что теперь есть климат.
Подсветка это не электрика, а блок управления.
Надо посмотреть по ETKA, есть ли различия. Вечером гляну, вы меня заинтриговали
Именно электрика. Если две ПТФ по электрике идут на одном проводе, в блок управления смысла нет лезть, они же должны включаться независимо друг от друга. На фабии в комплектации с датчиком света, вроде как идут отдельно, если без, то включаются только вместе.
На йети вроде как всегда отдельно. Если есть датчик поворота руля, можно включить от положения руля, если нет, то только от поворотников. Иногда полезная штука, правда только вправо нормально светит )
Датчика света нет. Алгоритм работы следующий. Включается при скорости ниже 40 км/ч, если включен поворотник, то сразу включается, если поворачивается руль, то плавно загорается и также плавно тухнет. Но только при скорости ниже 40 км/ч
За опускание зеркала при движении задним ходом отвечает 52-й блок «Блок управления пассажирской двери». У SanchoPanso998 есть подробный отчет по доработке зеркала Опускание правого зеркала при включении задней скорости
Просто меняешь мотор в правом зеркале (на Али оригинал для рынка Китая за $40) и дотягиваешь вместе с ним 4 провода — на управление по вертикали и горизонтали. Далее VCDS — кодировка в блоке комфорта/BCM в зависимости от модели.
На данный момент обкатываю решение и потихоньку пишу мобильное приложение для iOS, чтобы любой мог попробовать цифровую панель приборов.

А как данные будут поступать на мобильное ПО? придется какую-то железяжку подключать?
UFO just landed and posted this here
Я знаю torque. Я хочу сделать панель приборов, которая смогла бы заменить штатную. Дизайн очень важен. Считывание и стирание ошибок пока не планирую, хотя это возможно.
UFO just landed and posted this here
Спасибо. Да, к сожалению в Octavia единственное нормальное место для установки монитора это место штатной магнитолы, все остальное колхоз.
Да везде так.
Ни в одной машине «нет штатного пустого дополнительного места для 7'' дисплея».

Кстати, а какая модель дисплея используется? Я тут купил очень похожий на ваш, под такую же задачу… А он, собака, не хочет заводится на RPI.
У меня оригинальный дисплей, но он не очень мне нравится, черный не черный, круглое выглядит как эллипс.
www.raspberrypi.org/products/raspberry-pi-touch-display

А вот как я бы хотел чтобы выглядело в машине. Это системе Carsara.


Дисплей крутой, но диагональ поменьше и дороже он. В остальном то, что нужно.
Для АМОЛЕД дисплея нужен ещё алгоритм предотвращения выгорания, для статичных картинок и долгой работы он не очень подходит. И если для основных шкал это ещё терпимо(они-то не меняются, хоть и выгорают) то для цифровых областей где цифры мало меняются(область индикатора топливного бака) это будет проблемой.
Сделать дисплей быстросъёмнвм и раз в два года — менять его.
кто меняет машины раз в два года — таким не озадачивается.
Кому раз в два года поменять мелкий амолед дорого — пусть собирает на неонках дисплей.
Может и не дорого, но в итоге просто накладно по времени. Когда таких мелочей набирается под сотню, там дисплей поменять, там батарейку… и всё это выливается в то что надо будет ЧТО-ТО менять каждые 2-3 дня. Удовольствие очень сомнительное.
Ну ведь есть штатная цифровая приборка.
Я хочу сделать панель приборов, которая смогла бы заменить штатную
А у экрана какие хар-ки по части рабочих температур?
Сейчас как раз и делаю мобильное приложение, которое теже данные будет получать по wi-fi от elm327.
Ну тут не wifi а bluetooth. Но пойдет, в общем? Кстати, а ведь распберри умеет блютуз, стоило ли провода тащить к разъёму тогда?

Через elm327 не получится обновлять обороты каждые 5 мс. Как минимум 50 мс, а в реале все 100 мс.
Хочется максимальноц скорости

Круто! Приятно видеть завершённый проект.
Я пытался сделать нечто подобное для своей шеви-нивы, но столкнулся с особенностями подключения по OBD II к ECU Bosh, и так и не смог заставить гонять даже простую диагностику через Torque из-за хитрой инициализации. Так и не вышло подобрать нужную AT-последовательность. В итоге забил и довольствовался штатным БК, который умел только показывать коды ошибок. До сниффа протокола руки не дошли.
Я провел очень много времени в машине, чтобы добиться того что хотел.
В итоге сейчас добавить функцию это делов на несколько десятков минут.
Мне понравился дизайн, автор молодец.

А это железо и софт сможет потянуть несложную 3Д графику?
— Поликаунт примерно 400 000 треугольников или меньше
— Текстурирование, в идеале две текстуры в два независимых UV канала (освещение и цвет поверхности, как в играх времен half life 1).
— Шейдеры и всякие модные PBR не обязательно



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

На RPi3 Quake 3 работает. В качестве Ui фреймворка у меня Kivy, он умеет с 3d графикой работать, но я не пробовал.

На википедии пишут, что Raspberri Pi поддерживает OpenGL ES 2.0 — т.е., есть и текстуры и пискльные/вершинные шейдеры. Про производительность можно почитать здесь: https://www.raspberrypi.org/forums/viewtopic.php?t=88058, якобы без текстур и освещения можно рисовать 19миллионов треугольников в секунду.

И вот он я не знаю как подключить ШГУ чтобы работала подсветка и bluetooth.
Знаете чего не хватает у вас (как и в интерфейсах пожалуй всех авто). Количества топлива в баке тупо в литрах. Сигналка моего прошлого авто умела эту информацию на брелок выводить, скажу вам, это очень удобно.
Это не сложно, я же получаю числовое значение в литрах, можно и вывести.
Я отлавливаю нажатия кнопок подрулевого переключателя, могу с его помощью менять отображения, со шкалы на числовое.
Знаете почему ни одна приборка не выводит информацию «тупо в литрах»?
Потому что не знает её.
Датчик топлива показывает плюс минус тонну. Поэтому и показывают стрелку или шкалу с примерным количеством. Показать напрямую значение с датчика — ввести пользователя в заблуждение и словить минус в карму от разгневанных владельцев.
Не поверите, но знаю. Тем не менее я почти 3 года этой информацией руководствовался на заправке и ни разу не прогадал. Точность +- литр. Пожалуй, соглашусь, что в движении это не очень полезная информация, вот на заправке или в начале пути, вполне себе.
Вам повезло с калибровкой.
Обеспечить достаточную точность в каждом автомобиле нельзя/дорого. Поэтому шкала.
Хотя тут конечно кастомная приборка, можно и вывести. Тут согласен.
Я сам сварщик не настоящий, но подозреваю, что не так неплохо у машин с этой калибровкой, просто инерция разработчиков. Потом, всегда ведь можно откалибровать, естественно заложив запас литров в 5, или сколько там обычно на авто делают.
Как?
Датчик что-то адекватно покажет только на ровной поверхности без движения.
Если увеличивать точность — надо дополнитиельные датчики и алгоритмы подключать. Что приведет к удорожанию, и не особо нужно.
По мне, описываем в инструкции все перечисленные проблемы. Показываем цифры только когда машина стоит на месте (либо в режиме парковки). Можно ещё и предупреждение показывать (моя новая Kia, каждый раз напоминает об аккуратности за рулём, могла бы и уровень топлива показывать, с пометкой, что может ошибаться).
ну и можно сделать инструкцию по калибровке датчика уровня топлива.
Замер на горизонтальной поверхности? Или тогда плюс 3-4 датчика со средним значением.

Да просто на относительно горизонтальной поверхности.

Нет, там проблема датчика в другом — у него имеется дискретность. Т.к. он представляет собой полавок подключенный к проволочному переменному резистору. Во многих машинах два поплавка или конструкция поплавка такая что его положение слабо зависит от качки. Проблема именно в дискретности. И соответственно датчик показывает в у.е. в литры переводить надо знать объём бака. А поскольку сами у.е. дискретны, потом ещё умножаем на емкость бака, которая тоже варьируется… получается +- лапоть, значения не кратные литрам и откалибровать очень муторно. По литру топливо заливать и записывать значения. Ну да, конечно же у датчика есть нижняя граница, например меньше 5л в баке он уже не покажет и это тоже зависит от того как этот датчик на заводе поставили и как он на кочках погнулся в процессе эксплуатации.
А еще эта резистивная оплетка имеет свойство менять свою равномерность, ведь по ней постоянно вверх-вних ползает ползунок, который может смещать витки, в итоге пропадает линейная зависимость, и простой формулой для калибровки не обойтись. У меня так на сивике было, замечал что в середине шкалы расход замирал, а потом ускорялся. Разобрал датчик топлива — там неравномерно витки лежали. Да и степень окисления разная. Так что это дело работает «на глазок».
Т.к. он представляет собой полавок подключенный к проволочному переменному резистору.

Не обязательно к проволочному, бывают и плёночные.

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

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

Можно под бак встроить весы.

И датчики взять от танка
Ровная поверхность — ставим датчик наклона. Неподвижность — датчик ускорения. Калибруем всё на 1 машине, «наклон 5 градусов, бензин 20л, предполагается получение информации с датчиков… реальные показания..» и потом на каждой условно калибруемся по пустому баку, 20л, 20л при наклоне 10 градусов, полный бак, полный бак при наклоне -15 градусов. Ускорение — только расчётные данные.
Датчики потянут на пару долларов + сертификация.
Опять же, софтовые изменения — делаются для всех машин сразу, сильно цену не изменят. Другое дело что это сильно не нужно, но я почти уверен что это всё уже в каких-нибудь машинах есть, просто показывают как привычнее пользователю, а привыкли к шкалам. Может через obd можно получить абсолютные значения у каких-то машин.
Есть масса более простых и предсказуемых датчиков для измерения ровня топлива. При программной коррекции появляется масса мест возникновения погрешности, ньюансов работы которые так просто и не выявишь на этапе проектирования и иные сложности которые в итоге имеют конкретный экономический вес не в пользу грубых но простых датчиков. Знать точный объём топлива в баке? Это фетишь… на самом деле водителю нужно знать перед поездкой на 500км хватит ли топлива чтобы доехать без дозаправки, и если по грубым подсчетам в притык, то это лишь повод заехать на ближайшую заправку. И так если посмотреть, то этим обычно страдают водители которые ВЕЧНО ездят на остатках бензина в баке, дескать бензин дорогой, ага. Буд-то это как-то способно сэкономить денег. Нормальное состояние бака перед любой боле-менее длительной поездкой — это полный бак. Если топлива половина бака — это повод при удобной возможности заехать на заправку.
Калибруем всё на 1 машине
и потом на каждой условно калибруемся
Но ведь у каждой модели своя геометрия бака. Это ж не параллелепипед.
У каждой машины своя уникальная форма бака? Не модели, а именно экземпляра. А что форма сложная — калибровка на 1 машине и нужна полная.

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

UFO just landed and posted this here
В данной ситуации — калибровка, это не только настройка датчика. С этим то проблем нет по большей части.
Много факторов надо учитывать при движении. Сложный алгоритм.
И опять же — зачем?
Зачем знать осталость 5 литров, или 10? В любом случае пора заправляться. Потому что на прямой можно ехать при 5, а на склоне можно и заглохнуть. Словить клин насоса из-за осушения бака. ЗАсрать фильтр осадком с бака.
Бензин — не таштука. которую нужно восполнять на нуле. А если у нас нет требования к знанию точного нуля — то и геморрой с точными показаниями датчика не нужны.

При это я понимаю желание иметь точное значение на приборке. Это фетиш. Я сам на приборку кучу херни сейчас вывожу, потому что это же круто знать всё о машине! Еще и теллеметрию пишу… Но это именно потому что хочется, а не потому что объективно надо.
Бывает, технологически ставят разные баки. Пошла другая партия, бак чуть шире или выше и вмещает +1 литр от предыдущего. Бывает, одна и та же модель но датчик ставят уже другой, с другой нелинейностью и своими особенностями… Пара часов калибровки на заводе на каждый автомобиль выливается в лишние потраченные тысячи человеко-часов на производство автомобиля, а значит упущенная прибыль…
Я обнаружил 3 разных показания о остатке топлива в баке.
1) Датчик в баке показывает 18л когда стою на месте. При движении показания сильно меняются, от 10 до 30л.
2) Рассчитанный примерный остаток, показывает 16.5л
3) Положение стрелки топлива в баке в градусах

Я ориентируюсь на второй вариант
У меня в BMW E39 большая проблема с жизнеспособностью этих датчиков, спасибо нашему милому бензину: то воды нальют то еще какой фигни (супруга пролила немного при заправке с канистры, в итоге оттереть не могу вообще ничем теперь).

ЗЫ смотрю на вашу штуку, хочу) но с железом возиться просто не умею

Я пишу приложение Панель приборов для iPad/iPhone, дизайн будет такой же как в текущем проекте, сначала только для VAG, если будет интерес, то для BMW и других марок возможно будет сделать.

кого убить? правда вот с айпадами не дружу, хотя где то первый валяется)

Убивать никого не нужно )
Нужно только время на разработку. Там гляди и на Android тоже выпущу

Не знаю у меня показывает остаток топлива в баке в литрах. Точность шага 5 литров. Шкода Йети, концерн ВАГ
Почему не знают?
Древние Супры, Марки, и прочие Ниссан Либерти…
Точность, правда, ± верста, но её вполне хватает.

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

Основываясь на каком расходе показывается прогноз пробега в конкретном авто нужно ещё выяснять. Знаю как минимум два варианта:
1. По среднему расходу с момента последнего сброса счётчика в маршрутном компьютере.
2. По среднему расходу за последний период(обычно порядка 10км, возможно у кого-то и по времени период).
При этом диапазон расхода на своём авто обычно представляешь довольно точно — пределы, в зависимости от обстановки. Бортовой комп окружающей обстановкой не владеет. Допустим попал в пробку(например на бетонке), примерно представляешь сколько ты в ней простоишь. Есть две заправки — одна вскоре, прямо на бетонке(но вопрос контроля качества на загородных АЗС очень непредсказуем), другая, проверенная, километров через 70. 70 км это примерно 6 литров(с учётом текущей пробки). У меня бак 54л, и 8 секций на указателе уровня топлива(есть подозрение что две нижние секции по диапазону как одна верхняя — последняя уже минималка, с лампочкой минимального остатка). Получается дискретность показаний уровня топлива примерно 6.75л. И вот смотрю я на уровень — три клетки. А это сколько? 20.25л? Тогда не парюсь, и заправляюсь на проверенной. Или же это уже 13.6л(чуть больше чем при двух секциях уровня)? Тогда лучше рискнуть непроверенной заправкой, и долить в бак чтобы точно хватило до проверенной(не люблю езду с двумя клетками).

Если же ездить только в местности где полно надёжных заправок, тогда да — в большинстве ситуаций хватит даже того недоразумения что у меня штатно на торпеде стоит.

Себе поставил мультитроникс — лежит в бардачке, данные выводит по BT на телефон(у них своё приложение). При тарировке бака по двум точкам дал мне точность остатка примерно ± 1 литр в крайних зонах(легко проверяется заправкой до полного бака, с поправкой на борзость АЗС, и объём приёмной трубы). В середине бака может подвирать больше, но не критично — точность указателя на торпеде гораздо хуже во всём диапазоне. Мне хватает :). Кому мало — есть режим калибровки по 7 точкам, вооружаемся мерной ёмкостью и калибруем бак(но мне кажется это для ситуаций с сильно кривым баком, или сильно нелинейным ДУТ).

По поводу колебания уровня в баке при движении — как минимум мультитрониксовский усредняет показания, и если вы 5 минут(грубо говоря, не мерял) подряд не стоите в горку, то показания не исказятся. Да и стрелочный в зубиле тоже не мгновенно дёргался вслед за поплавком(кстати, потенциометр там был не проволочный).
Хм… Не знаю как, но в моей 2114 аж 2006 г. штатный «компьютер» таки выводил количество топлива в баке с точностью ± литра два в зависимости от того, насколько косо поставил на не особо ровной стоянке. К сожалению, не посмотрел, есть ли это в CAN.
Так что, подозреваю, что тут дело в чём-то другом.
Прочитайте комменты вокруг. Уже все объяснили несколько раз.
Показания колеблются от множества факторов, плюс даже в идеальныхз условиях погрешность плюс минус десяток литров.
Так что то что компьютер что-то там выводи, не значит что он это знает. Это сильно ориентировочное значение.
Судя по изменениям после слива/заправки в состоянии со снятым аккумулятором — пересчитывается из показаний поплавкового датчика, так что компьютер — таки знает.

Оно, конечно, ориентировочное, но совпадает с реальностью достаточно неплохо, порядка ± 5% в относительно ровном Екатеринбурге и ± 10% в э… холмистой местности. Для большинства применений такой точности более, чем достаточно.
Совершенно верно. Для большинства применений(собственно применение одно — оценка оставшегося пробега) этого и достаточно. Поэтому и показывают оставшийся пробег, а не количество литров.
Неоднократно видел обсуждение датчиков топлива на радиотехнических форумах, там пытались сделать точный индикатор количества топлива. Так вот это в принципе невозможно со штатными датчиками — это связано с их конструкцией. Датчики эти проволочные ибо дешёвые и меньше стираются со временем и там как раз получается что одному витку такого датчика соответствует шаг уровня топлива в баке порядка 2л. А для грузовых авто с большим баком и того больше.
Есть, конечно, другие датчики измерения объёма топлива в баке но кроме гораздо большей стоимости у них есть и свои недостатки. Например, зависимость от примесей в топливе, смачиваемость датчика топливом(емкостные датчики), низкая надёжность в целом из-за сложности и т.д.
У VAG бывает такая опция, можно вывести на дисплей. Причем показывает даже не остаток, а сколько еще войдет литров. С запасом, чтобы не получилось, что вдруг не вошло.
Сколько читал отзывов — говорят, довольно точно, не обманывает.
Брешет литров на пять в меньшую сторону. То есть если пишет «Войдет 15 литров», то можно спокойно заливать 20 :)
Ну почем сразу брешет-то? 15 же вошло )
Я VCDSом включил её себе.
Перестраховывается он, зараза. До 5 литров как минимум. Люблю заправляться до полного, но чтобы не бегать туда-сюда до кассы. Говорит 30 литров можно заправить, заправляешь 30, а показометр даже не на максимум встаёт.
А почему просто полный бак нельзя заливать автоматом?
Заправок, где сначала заправляешься потом платишь у нас раз-два и обчёлся. А на обычных надо ходить на кассу лишний раз за возвратом, если не влезло оплаченное. Лишние хопы :)
С «не вошло» не испытываю никаких проблем. Возвращаюсь на кассу и всё. У Башнефти при оплате через терминал ВБРР(у них два, один для клиентов Сбера, второй для всех) — можно даже не заходить: пистолет повесил и всё. «Император» за кассой как нажмёт окончание заправки — так деньги на карту и вернутся. А если Сбер, то идёшь, отменяют первую транзкцию, и проводят вторую на фактическую сумму.
Заправляюсь всегда до полного, чтобы реже заезжать на АЗС.
Виталь, интерфейс просто огонь!
Пришлось освоить Inkscape и Illustrator, это стоило недели бессонных ночей.
Использовать диагностические запросы (я правильно понял?) для получения данных не очень удобно, кмк. Не знаю как у вагов, но у японцев все эти данные можно получить не отправляя никаких запросов, в салонной шине все свободно гуляет.
Еще заметил, что у вас не значащие байты в кадрах ISO-TP забиты 0x55 или 0xAA, как положено, а вот все у тех же японцев там мусор, оставшийся от предыдущих сообщений в буфере. VAG — Mitsubishi — 1:0
У меня есть версия приборки, которая подключается непосредственно к CAN шине, в этом случае не нужно вести опрос. Но вычислять сниффером что означает каждый пакет очень трудоемко, потому что информация с некоторых датчиков не часто обновляется. Вывел только часть приборов и забил.
В япошках и корейцах через OBD2 можно спокойно слушать CAN шину, там проще.

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

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

UFO just landed and posted this here
Как я понял некоторые данные генерирует сама приборка, например градус стрелки количества литров в баке и этой информации нет в низкоскоростной CAN шине. Эту информацию можно запросить только через диагностический разъем.
В моем япе сигнал из бака идет прямо в приборку, а она в двух разных пакетах уже выдает обработанные сглаженные данные.
Смотрел распиновку приборки и в моей машине датчик в баке напрямую связан с приборкой, а приборка уже в кан шину выплевывает показания.
То то я смотрю они очень похожи. Сеть построена аналогично, очень похожие диагностические запросы.
Диагностика везде внешне похожа, это вариации на основе ISO 14229.
Вот со второго взгляда начинаются отличия — другие ID пакетов, нестандартные PID'ы и т.д…
Интерфейс жестко прописан или можно кастомизировать положение и внешний вид датчиков?
Кастомизация возможно на 100%. Можно в отдельном файле сделать класс Dashboard с полностью другим дизайном и заменить текущий.
Так-то понятно, что код исправил, вот тебе и кастомизация. :)
Имел ввиду, без правки кода как раз. Через конфиг, или «режим редактирования».
В текущем проекте жестко привязан интерфейс, но все подготовлено для того, чтобы можно было делать скины.
UFO just landed and posted this here
На магнитиле есть кан шина, на нее же выводятся показания температуры, парктроника и др. Я подключался к кан шине в районе приборке, там же и охранная система подключена.
Отличная работа! Тоже думал запилить свою приборку, правда на механических стрелках. Подскажи, там вообще можно читать все в реальном времени? Видел много китайских приблуд, так они работают с задержкой до двух секунд. А для тахометра это большая печаль, там надо шустро реагировать.
Везде по-разному. В моей машине данные тахометра и спидометра идут в приборку каждые 50 мс.
Я тахометр считывал со скорость 0.005 сек. Быстрее не пробовал
UFO just landed and posted this here
Отличная статья! Ваш пост сэкономит кучу времени всем желающим поковырять ваговскую шину.
Надеюсь кому то будет полезно, я несколько месяцев украдкой делал проект.
У меня вопрос: а коды доступа к информации привязаны конкретно к авто или они универсальны в рамках всего ВАГ семейства? Просто имею рапид и хотелось бы попробовать сделать что-то подобное.

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

Насколько я знаю, в Рапиде с 17 модельного года уже стоит бортовая сеть от MQB-A, что очень похожа на последнюю Октавию А7?
Простым elm327 адаптером я смогу получить те же данные?
Вот так нужно настроить ELM327, чтобы отправлять CAN команды:
atz
at sh 714 // запрос на адрес 714
at cra 77e // ждем ответ от 77e
at fc sh 714 // запрос на адрес 714
at fc sd 30 00 00
at fc sm 1
at al
at sp 6
at ca f0
03 22 22 0d 55 55 55 55 // запрос

05 62 22 0D 55 65 AA AA //ответ
А что это за запрос был? Просто интересно? Я сам с АТ команды дела не имел, поэтому и интересуюсь.
// Двери
714 03 22 22 0D 55 55 55 55

Посмотрите в статье, я много кодов написал
А что за последовательность команд между «запросом на адрес» и самим запросом? Меня это интересует)
Скажите, пожалуйста, на какой модели Octavia это реализовано? Давно есть желание что-нибудь подобное замутить, но не решаюсь
Проделывал года два назад такое на своей
Самодельный дисплей в панель приборов! (черный который снизу, там с завода заглушка была)
Связка: Arduino + ELM327 + 2.2 ili9341.
Теоретически должен подойти для любой машины где есть OBD-II.
На фото для тестов выводит скорость, обороты двигателя
и температуру охлаждайки. Сейчас вместе с цифрами показывает простой индикатор-полоску. В планах сканирование и вывод наименований ошибок, а так-же их сброс.
UFO just landed and posted this here
Судя по связке там все в wired)
Да напрямую! И использовал библиотеку ELM для ардуино (еле влезло все в arduino pro mini вместе со шрифтами). На разъеме OBD2 есть контакты на которых появляется +12 когда ключ зажигания включен. Я переделал питание ELM на этот пин чтобы не садился аккумулятор машины. Весь индикатор запитал тоже от встроенного в ELM LDO 3v3. Всё уместилось внутри приборной панели кроме ELM а провод идущий от него на панель (+3v3, rx, tx, GND) используется и для данных и для прошивки (не надо каждый раз панель снимать)
Отличная работа. Я делал нечто подобное под американские форды, только использовал штатный экран
github.com/p1ne/fdim-controller
www.drive2.ru/r/mercury/mariner/886255
и рассказывал www.youtube.com/watch?v=yOIXnQCXnhg

После пересаживания на ВАГ сделал так же, как автор — подключил кан-сниффер в параллель к VCDS. Хотя интереснее напрямую в гейтвей :) Пока вяло ковыряю кнопки MMI.

Есть кстати интересный товарищ на драйве — делает дисплейчик под Ауди www.drive2.ru/users/kvaziigor
UFO just landed and posted this here
Вторая версия интерфейса приборки получилась хорошей, 3 перегружена. Каким образом собирали дизайн интерфейса? Какие возможности есть?

Посмотрите исходник, он в спойлере. Просто виджетам указывал координаты.
Не стал заморачиваться с автолайаутом.

Немцы в этом плане красавчики, неоднократно общался на их форумах по поводу VAG Can шины. У них много собрано информации. С помощью ардуино настраивают автоматизацию в машине.
Закину на этот форум инфу о проекте.

Отличная работа. С удовольствием читал обе статьи. Спасибо.

Поздравляю с прекрасной реализацией!
Я сам озадачен похожим проектом, в качестве основного устройства, правда, Google Nexus 7, Arduino и CAN-шилд уже приобрел, буду постепенно это все соединять. Правда, авто у меня GMC, для подобных мало информации, снифферить придется и самому все детально анализировать.

Я все же хотел бы переделать на андроид планшет, это дешевле, смотрится лучше и можно лаунчер свой сделать.

Я на Авито купил Nexus 7 32Gb Wi-Fi за 3к. Вариант с дисплеем и Raspberry отбросил как раз по причине дороговизны.
Лаунчер да, но надо научиться писать под Android:)

Приятно почитать про ковыряние в потрохах авто, тем более VAG, который довольно легко в свои потроха пускает всех желающих.
Пишите еще)
В вашем решении для меня две очевидные проблемы безопасности.
1) Место расположения датчиков. Взгляд вниз вверх быстрее чем вбок вниз вбок вверх.
2) Материал дисплея. Автомобильные стекла делаются с зажитой от осколков. Что в вашем варианте? Вариант для фильмов ужасов? Когда кусок стекла при аварии разрезает горло водителю? Брррр…

Ну да, не заводское решение. Я же изначально хотел стрелочки приборов заменить на дисплей. Но пока до этого не дошло

UFO just landed and posted this here
Вы правы, не поверю. :) Машины худо бедно проверяют на краш тестах.
Краш тест для шкафа купе? Не, не слышал. ;)
UFO just landed and posted this here
Эээ… Не понял вашу мысль. Вы считаете что стекло в планшете, не предназначенное для атво промышленности, такое же безопасное как специальные авто стекла?

Думаю что обычное стекло опаснее. Вы видели как бьются авто стекла? Стекла на планшетах бьются по иному. Как бьются стекла в шкафах купе не знаю. Не видел.
Но что-то мне подсказывает, что там обычные стекла, совсем не те что применяются в авто промышленности.
UFO just landed and posted this here
До осколков может дело не дойти, при лобовом ударе, например, сила будет такой что оторвет планшет и стекло вместе с ним целиком, и оно отработает своими кромками как ножом ещё до того как разобъётся. И плёнка тут не поможет никак. разве что если плёнка будет обволакивать весь планшет целиком и будет очень прочной, как кевлар например.
UFO just landed and posted this here
Какой клей удержит стекло дисплея в корпусе при перегрузке в 100G например? Планшет оторвёт, несомненно. А дальше его разные компоненты будут испытывать разные нагрузки, неизвестно как поведёт себя стекло которое держится только на клею а клей уже 1) высох за 5 лет эксплуатации, 2) размягчился под действием солнца. Планшет ударит, но стекло может пролететь несколько дальше планшета сыграв роль ножа.
Полагаю, что в машине достаточно плохо закрепленных предметов, которые предоставляют опасность. Например — регистратор на присоске.
Так что еще один, хорошо закрепленный и расположенный в стороне врядли что-то сильно изменит.
Вот поэтому там не должно быть ни одного нештатного предмета. Даже обычные лежащие очки могут нанести серьёзные дополнительные травмы. То что это «в стороне» очень относительно, зависит от того с какой стороны придётся удар, не все аварии чистые лоб-в-лоб, пытаясь избежать аварии можешь столкнуться таким образом что планшет полетит аккурат в тебя.
Отличная работа! Не задумывались о проекционном выводе на лобовое стекло?
Такие проекторы уже есть, обычно кроме скорости, больше ничего и не нужно выводить
Автор — разработчик в широком смысле слова… Крутой проект, требующий знаний во многих областях… Я в восхищении ))
aivs, я подумывал делать, что-то вроде www.figma.com/blog/what-teslas-model-three-ui-reveals-about-its-vision-for-the-future для ipad + wifi elm327, остановился на проблеме управления климат-контролем. Блок старый 8e0820043H. В «Васе» не удалось найти какое-либо управление температурой, чтоб сохранить сам блок, но управлять им из приложения. Делать какую-либо плату управления климат-контролем через Arduino не хочется.
Я тоже не нашел управление климатом в своей машине. Но на штатной магнитоле отображается температура обдува. Может управления по can и нет, а только отображение.
Отличная реализация!
Если сможешь помочь реализовать вывод пропусков зажигания по каждому цилиндру и температуру со всех лямбд на приборную панель, то цены вообще не будет твоей идее!
Пропуски зажигания можно вывести по цилиндрам, температуру с лямбд не смотрел, но скорее всего тоже можно
Колоссальная работа. Со своим пассатом тормознулся как раз на органичном внедрении дисплея. На место штатной магнитолы — низко, вместо центральных дефлекторов — лучше, но пока не осилил сделать красиво.
Странно, что нет упоминания pccar в комментариях или статье.
У меня пока что вместо pccar — телефон
А почему решили работать через диагностику, а не с сырыми данными? Просто, если решите параллельно подцепить ELM327 или что-то иное, то железо начнёт конфликтовать.

За климат и отображение его отвечает низкоскоростная шина комфорта, которая живёт отдельно, но, как и высокоскоростная основная, тоже заведена в на шлюз.

Лучше работать с данными напрямую, не нужно будет дёргать шлюз, выдерживать таймеры, а просто читать прилетевшие данные и отображать. Это будет более оперативно (высокоприоритетные данные могут прилетать каждые 10мс). А чтобы лишнее не прилетало, то задать фильтры. Правда у MCP2515 их всего 6, но что-то в даташите как-то непонятно про них. Тут бы я воспользовался каким-нибудь STM32 (F105 например) с CAN на борту. Там их 28 полноценных штук. Хватит за глаза.
Если нужно будет как-то стирать ошибки, то можно подсмотреть в шине, что посылает шлюз в шину, когда стирает ошибки из разных блоков.
Искать команды в шине без запросов более трудоемко, чем засниффать известную команду.
Я хотел сделать с прямым подключением к сан шине, но провозившись 2 дня, плюнул.
Может быть и вернусь к этому когда-то.
С этим согласен. И когда сканируешь CAN, то лучше это делать на ходу и не одному.
Я, для одного проекта, как раз записывал в лог данные шины во время поездки, а после сидел и пялился на цифры, припоминая маршрут и что было на пути. А чтобы было проще, то записанный лог проигрывался в программе.
В итоге нашёл всё необходимое и больше.
Правда у MCP2515 их всего 6, но что-то в даташите как-то непонятно про них

Есть маска: принимать все сообщения (фильтры не работают), только стандартные с учётом фильтров, только расширенные с учётом фильтров или и стандартные, и расширенные с учётом фильтров,
и 6 фильтров, биты которых сравнивают с битами сообщенияё, исходя из чего сообщение помещается в приёмный буфер или игнорируется.

У сотой серии STM одномоментно работает или CAN, или USB. В своё время был этим неприятно удивлён
У сотой серии STM одномоментно работает или CAN, или USB

В 105/107 поправили.
Спасибо за информацию. Надо будет потестить
А для тех, кто не дружит с STM, зато хорошо знаком с AVR — AT90CAN128 (есть еще 64, 32, но 128 более доступен у поставщиков).
У него 15 «мейлбоксов».
Просто, если решите параллельно подцепить ELM327 или что-то иное, то железо начнёт конфликтовать.

Разве два устройства на шине CAN не могут слать запросы и получать ответы? Там же вроде есть какой-то арбитраж.
Арбитраж есть, но он по сути также отвечает за приоритет отправки сообщений.
Стандартная диагностика живёт на запросах широковещательных 7DF или адресных 7E0+X и ответах 7E8+X, где X от 0 до 7. При отправке широковещательного запроса на 7DF, ответ прилетит от 7E8+X.
А теперь представьте картину, ваши устройства отправили запросы с идентификаторами 7DF и 7E2, а ответы прилетят 7EA и 7EC. Как мы видим, устройство, оправившее адресный запрос 7E2, ожидает ответ от 7EA и корректно отработает, а вот устройство, отправившее 7DF, обработает первый ответ из интервала 7E8+X.

А так, шина предполагает, что в ней не будет работать 2 устройства, которые посылают сообщения с одним идентификатором.
Хм… Но если устройство, например, запрашивало скорость, то оно ведь и будет ждать в ответ пакет с идентификатором скорости? И если в ответ прилетает что-то другое — ну значит нужно ждать дальше, пока не прилетит запрошенный пакет. Он ведь все равно прилетит.
То есть, подразумевается, что на широковещательный запрос 7DF ответы приходят те же самые, 7E8+X, что и на адресные запросы? (я не в курсе протоколов для легковушек, я по грузовикам и автобусам специализировался — SAE J1939).

устройство, отправившее 7DF, обработает первый ответ из интервала 7E8+X.

А что изменится, если не будет адресного запроса 7E2, а только широковещательный? Все равно ведь придут те же 7EA и 7EC, не так ли?

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

Полагаться на «первое пришедшее» не стоит — потому что не факт, что первым придёт ответ с максимальным приоритетом из диапазона. Первым будет «с максимальным приоритетом из имеющихся» — а это может быть не весь диапазон. Так, в вашем примере, если на шине присутствуют все узлы диапазона, первым должен прийти 7E8 (от устройства 0), но видимо, на шине есть только устройства 2 и 4. И даже если мы знаем список устройств и закладываемся на подмножество вместо полного диапазона — может случиться, что устройство отвалится от шины или вообще выйдет из строя, и не пошлет ожидаемого сообщения, и тогда если вместо фильтра по ID мы таки ждем «первое пришедшее», то опять же примем не то что ожидали.
То есть, подразумевается, что на широковещательный запрос 7DF ответы приходят те же самые, 7E8+X, что и на адресные запросы?
Да, это так, но это в случае стандартизированной диагностики. Некоторые модули могут слушать сообщения вообще с другими идентификаторами и работать по протоколу UDS.

А что изменится, если не будет адресного запроса 7E2, а только широковещательный? Все равно ведь придут те же 7EA и 7EC, не так ли?
Нет, только от того, кто этот запрос может обработать.

может случиться, что устройство отвалится от шины или вообще выйдет из строя, и не пошлет ожидаемого сообщения, и тогда если вместо фильтра по ID мы таки ждем «первое пришедшее», то опять же примем не то что ожидали.
Там даётся время, в течении которого должен прийти ответ. Время на память не помню, но отрезок маленький.

Освежил сведения, да, время, в пределах которого ожидается ответ, минимально и равно 50мс. И да, в ответе содержится информация, что за ответ прилетел.

Но даже если представить, что ответ у нас содержит информацию, что запросили, как будет разруливаться ситуация, когда два устройства посылают 7DF? Тут никакой арбитраж не поможет. Вылезет ошибка.
Ну, два устройства, посылающих полностью одинаковый ID — это в принципе, недопустимая ситуация для CAN. Но какое это отношение имеет к рассматриваемому примеру? И что вообще должен был проиллюстрировать пример? Мне показалось, что неявно подразумевалось утверждение «устройство, посылающее 7E2, будет мешать устройству, пославшему 7DF».

Нет, только от того, кто этот запрос может обработать.
Стоп. Если широковещательный запрос подразумевает получение ответов в диапазоне 7E8+X, то его и должны обрабатывать все, кто посылает такие ответы.
Но какое это отношение имеет к рассматриваемому примеру? И что вообще должен был проиллюстрировать пример? Мне показалось, что неявно подразумевалось утверждение «устройство, посылающее 7E2, будет мешать устройству, пославшему 7DF».
Я плохой пример привёл, а после освежения знаний понял, что он не правильный. Проблема действительно возникнет только когда 2 устройства пошлют сообщения с одним идентификатором.

Стоп. Если широковещательный запрос подразумевает получение ответов в диапазоне 7E8+X, то его и должны обрабатывать все, кто посылает такие ответы.
В принципе да.

Я ранее не правильный пример привёл, проблемы начинаются, когда 2 устройства начинают посылать диагностические запросы с помощью широковещательного сообщения.
Слышал, что многим диагностическим сканерам сносит крышу, если параллельно ещё кто-то общается на этом же протоколе. Т.е. при получении данных, у которых Service и PID «некорректные», сканер не пропускает их, а перезапускает опрос. И отваливается по количеству запросов.
Конкретные модели не назову, просто коллеги выработали эмпирическое правило — при подключении сканера ни в коем случае ему не мешать.
два устройства, посылающих полностью одинаковый ID — это в принципе, недопустимая ситуация для CAN

«если очень хочется, то можно» :-)
Да, есть вероятность (при одновременном старте передачи), что одно из устройств отвалится с ошибкой. Но практика показывает, что счётчик ошибок достаточно большой, и это устройство успеет передать, что ему надо, в следующий свободный момент.
Т.е. да, при проектировании шины два устройства с одинаковым ID — однозначно плохо и неправильно. Но если надо чужую шину слегка модифицировать — ну, приходится и так, с подделкой чужих пакетов…
Я вот не помню, продолжает ли устройство во время передачи данных слушать линию и сверять с передаваемыми битами. Спецификация CAN 2.0 гласит, что арбитраж раcпространяется на ID и бит Remote Frame.

А, сообразил — проигрыш арбитража ошибкой не считается, а вот несоответствие бита в остальной части кадра — как раз ошибка, увеличивающая счетчик. И да, вы правы — пока счетчик не заполнится это тоже приводит лишь к откладыванию передачи, как и при проигрыше арбитража.
делал подобное для своего ландровера, т.к. у меня по комплектации не положен экран с информацией о 4х4 системах — с помощью drive2 и лр-клаба написал софтину для андроида, получать эти данные через bluetooth elm приблуду
скриншот
Это действительно очень важная информация!
Приложение в маркете?
пока ещё нет — ещё не закончил разработку. Пользоваться криво-косо можно, но пока рано говорить о готовности. Потихоньку пилю в свободное время
А какая elm приблуда позволят читать кан шину своей программой?
ээ, никакая? elm327 даёт доступ к obd2 интерфейсу через bluetooth или ещё что
Elm это и есть приблуда, а программа для чтения кан шины — это терминал, нужно только знать, что в него писать.
Настоящий елм 1.5 позволяет читать и писать в шину что угодно.
UFO just landed and posted this here

Я старался, мне это интересно

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

хочу кнопку +10 круиз контроль
Кнопки круиза не смотрел, гляну. Но это точно будет команда кнопка нажата вверх/вниз. Т.е. чтобы сделать +10 нужно будет 10 раз подряд послать команду.
Только скорее всего если продублировать команды полученные из, они не отработают. Нужно получить прямые команды из кан шины
я понимаю, что надо отловить комманду +1 и потом ее же 10 раз послать
Я думаю там аналоговый сигнал на делителях и идет напрямую в голову. У меня так.
Здравствуйте, а не могли бы вы выложить исходники графики?
Здравствуйте, исходники не могу выложить. Они будут использоваться в коммерческом проекте.
Какой экран используете?
По-моему альтернатив нет. Я искал с большим разрешением, но нет
Ну если тока искать от мерседеса на разборках, но там непонятно что с подключением и цена я думаю будет невероятной.

Ну и вот bit.ly/2VQJYxm
Я тут заметил баг, если обороты равны нулю, то стрелка начинает смотреть строго вверх. Не пытались понять почему так происходит?
Нужно потестить
self._needle.rotation = 112-(0.028*self.value) # 1 rpm = 0.028 gr
Очень здорово! Отличный подход к риверсированию протокола.

Вы не думали расширять функционал в сторону параметров ЭБУ двигателя? Для VAG группы очень не хватает удобного инструмента, которые бы мог на лету выводить параметры топливной системы, наддува, зажигания.

Т.к. VAGовские моторы очень легко поддаются форсировке, вывод этих параметров очень был бы интересен! На данный момент на рынке есть только polar fis, который ставится в разрыв проводки приборки, позволяющий выводить нужные параметры. Вечно кататься с VCDS — вообще не вариант, он часто избыточен, а простые ELM адаптеры часто не имеют доступа к нужным параметрам.
Это все можно, какие-то диагностические параметры добавлю в мобильное приложение.
Вчера вылезла ошибка по лямбде, код ошибки говорит об обрыве в цепи (гонял ня Селигер, возможно цепанул). Было бы круто отображать ошибки на 3д модели, как у Tesla. Читать ошибки не сложно, сложно и долго полную модель машины сделать.
Отличная статья, мне даже в голову не приходило, что, можно написать свою приборку. Автору огромный респект и уважение.
А такой подход можно применить и на тойоту 2005 года? или без разницы какая машина?
Если для тойоты есть подобное диагностическое оборудование, которое можно просканировать, то такой подход можно применить. Иначе придется слушать шину и самому понимать, что это за данные — это сложно.
Я вот заметил такую беду: сам can-адаптер потребляет уйму процессора, это даже при том, что к шине он не подключен:
image

А если я подключаю второй адаптер, то проц начинает перегреваться и тротлить.
Кстати, совсем забыл напомнить о существовании очень любопытного проекта: github.com/commaai/opendbc

Более полной базы по CAN-шинам в открытом доступе, пожалуй, и нет…
Да, интересно. Спасибо!
Sign up to leave a comment.

Articles

Change theme settings