Комментарии 224
Только одно уточнение, основная прелесть ваговской реализации (в частности VCDS) не только в том, чтобы получать данные, но и вносить изменения в настройки, вплоть до очень тонких. То есть, не только настроить «сколько сигналов поворотника дать при легком нажатии переключателя», но и внести различные коррективы в режимы работы устройств подключенных к этой шине. Например догреватель вебасто, положение кузова/пневмоподвески, калибровка фар и тп и тд
Я на драйве читал, что нужно ставить мезанизм с памятью положения, чтобы это заработало. А так регулировка все равно осуществляется по Кан шине.
Вам повезло — попался подходящий для этого блок зеркала. Мне не повезло )
Из полезного, на йети сделал подсветку в поворотах (работает за счёт противотуманок, фича от Тигуана).
Хочу ещё поменять кондиционер на климат. Блок управления стоит относительно дёшево (в пределах 10 тыс на разборах), правда попадаются в основном от фольцев, поэтому придется подсветку на зелёный перепаивать.
По поводу климата на йети (2012г), насколько узнавал, только блок управления и пару датчиков воткнуть. Все остальное уже и так управляется электроникой, все заслонки сервофицированны, только команды отдает не контроллер а человек.
Ну и в бортовой компьютер прописать что теперь есть климат.
Надо посмотреть по ETKA, есть ли различия. Вечером гляну, вы меня заинтриговали
На йети вроде как всегда отдельно. Если есть датчик поворота руля, можно включить от положения руля, если нет, то только от поворотников. Иногда полезная штука, правда только вправо нормально светит )
На данный момент обкатываю решение и потихоньку пишу мобильное приложение для iOS, чтобы любой мог попробовать цифровую панель приборов.
А как данные будут поступать на мобильное ПО? придется какую-то железяжку подключать?
Ни в одной машине «нет штатного пустого дополнительного места для 7'' дисплея».
Кстати, а какая модель дисплея используется? Я тут купил очень похожий на ваш, под такую же задачу… А он, собака, не хочет заводится на RPI.
www.raspberrypi.org/products/raspberry-pi-touch-display
А вот как я бы хотел чтобы выглядело в машине. Это системе Carsara.
![](https://habrastorage.org/webt/of/gs/hl/ofgshln_4zpzwmt-couggywlylo.jpeg)
ru.aliexpress.com/item/5-5-AMOLED-AMOLED/32974946179.html
взял отсюда mysku.ru/blog/aliexpress/72287.html
Кому раз в два года поменять мелкий амолед дорого — пусть собирает на неонках дисплей.
Я хочу сделать панель приборов, которая смогла бы заменить штатнуюА у экрана какие хар-ки по части рабочих температур?
ru.aliexpress.com/item/Elm327-V1-5-Bluetooth-OBD2-elm327-1-5/32961354257.html?spm=a2g0v.search0604.3.72.680e2b59HVlX97&ws_ab_test=searchweb0_0%2Csearchweb201602_8_10065_10068_319_317_10696_453_10084_454_10083_10618_10307_10301_537_536_10059_10884_10889_10887_321_322_10915_10103_10914_10911_10910%2Csearchweb201603_16%2CppcSwitch_0&algo_pvid=0ba785d4-c416-459e-a6a6-b17644826b5c&algo_expid=0ba785d4-c416-459e-a6a6-b17644826b5c-10
Я пытался сделать нечто подобное для своей шеви-нивы, но столкнулся с особенностями подключения по OBD II к ECU Bosh, и так и не смог заставить гонять даже простую диагностику через Torque из-за хитрой инициализации. Так и не вышло подобрать нужную AT-последовательность. В итоге забил и довольствовался штатным БК, который умел только показывать коды ошибок. До сниффа протокола руки не дошли.
А это железо и софт сможет потянуть несложную 3Д графику?
— Поликаунт примерно 400 000 треугольников или меньше
— Текстурирование, в идеале две текстуры в два независимых UV канала (освещение и цвет поверхности, как в играх времен half life 1).
— Шейдеры и всякие модные PBR не обязательно
![](https://habrastorage.org/webt/qk/pt/ud/qkptudqh6vjhj822zgpz7poesb0.jpeg)
Например, типа как на картинке. Идея в том, чтобы создавать интерфейс интерактивных схем, планов объектов, навигаторов по помещениям и т.п.
На википедии пишут, что Raspberri Pi поддерживает OpenGL ES 2.0 — т.е., есть и текстуры и пискльные/вершинные шейдеры. Про производительность можно почитать здесь: https://www.raspberrypi.org/forums/viewtopic.php?t=88058, якобы без текстур и освещения можно рисовать 19миллионов треугольников в секунду.
Я отлавливаю нажатия кнопок подрулевого переключателя, могу с его помощью менять отображения, со шкалы на числовое.
Потому что не знает её.
Датчик топлива показывает плюс минус тонну. Поэтому и показывают стрелку или шкалу с примерным количеством. Показать напрямую значение с датчика — ввести пользователя в заблуждение и словить минус в карму от разгневанных владельцев.
Обеспечить достаточную точность в каждом автомобиле нельзя/дорого. Поэтому шкала.
Хотя тут конечно кастомная приборка, можно и вывести. Тут согласен.
Датчик что-то адекватно покажет только на ровной поверхности без движения.
Если увеличивать точность — надо дополнитиельные датчики и алгоритмы подключать. Что приведет к удорожанию, и не особо нужно.
Т.к. он представляет собой полавок подключенный к проволочному переменному резистору.
Не обязательно к проволочному, бывают и плёночные.
Пленочный в этом узле будет обладать низкой надежностью, поскольку в процессе движения поплавок постоянно елозит туда-сюда, резистивный слой затрется довольно быстро.
Датчики потянут на пару долларов + сертификация.
Опять же, софтовые изменения — делаются для всех машин сразу, сильно цену не изменят. Другое дело что это сильно не нужно, но я почти уверен что это всё уже в каких-нибудь машинах есть, просто показывают как привычнее пользователю, а привыкли к шкалам. Может через obd можно получить абсолютные значения у каких-то машин.
Калибруем всё на 1 машине
и потом на каждой условно калибруемсяНо ведь у каждой модели своя геометрия бака. Это ж не параллелепипед.
Достаточно добавить дребезг датчика и можно забыть про проблемы движения и тряски автомобиля. А угол наклона на нормальных машинах вообще не влияет, т.к. датчик уровня устанавливают максимально близко к вертикальной оси бака.
Много факторов надо учитывать при движении. Сложный алгоритм.
И опять же — зачем?
Зачем знать осталость 5 литров, или 10? В любом случае пора заправляться. Потому что на прямой можно ехать при 5, а на склоне можно и заглохнуть. Словить клин насоса из-за осушения бака. ЗАсрать фильтр осадком с бака.
Бензин — не таштука. которую нужно восполнять на нуле. А если у нас нет требования к знанию точного нуля — то и геморрой с точными показаниями датчика не нужны.
При это я понимаю желание иметь точное значение на приборке. Это фетиш. Я сам на приборку кучу херни сейчас вывожу, потому что это же круто знать всё о машине! Еще и теллеметрию пишу… Но это именно потому что хочется, а не потому что объективно надо.
1) Датчик в баке показывает 18л когда стою на месте. При движении показания сильно меняются, от 10 до 30л.
2) Рассчитанный примерный остаток, показывает 16.5л
3) Положение стрелки топлива в баке в градусах
Я ориентируюсь на второй вариант
ЗЫ смотрю на вашу штуку, хочу) но с железом возиться просто не умею
Древние Супры, Марки, и прочие Ниссан Либерти…
Точность, правда, ± верста, но её вполне хватает.
Однако же машины показывают остаток по пробегу достаточно дочно. Плюс показывают остаток свободного места в баке в литрах. И если последнее полезно (сколько можно заправить безнина), то остаток бензина именно в литрах, а не по пробегу, даже не знаю чем может быть полезен, в отличии от остатка пробега.
1. По среднему расходу с момента последнего сброса счётчика в маршрутном компьютере.
2. По среднему расходу за последний период(обычно порядка 10км, возможно у кого-то и по времени период).
При этом диапазон расхода на своём авто обычно представляешь довольно точно — пределы, в зависимости от обстановки. Бортовой комп окружающей обстановкой не владеет. Допустим попал в пробку(например на бетонке), примерно представляешь сколько ты в ней простоишь. Есть две заправки — одна вскоре, прямо на бетонке(но вопрос контроля качества на загородных АЗС очень непредсказуем), другая, проверенная, километров через 70. 70 км это примерно 6 литров(с учётом текущей пробки). У меня бак 54л, и 8 секций на указателе уровня топлива(есть подозрение что две нижние секции по диапазону как одна верхняя — последняя уже минималка, с лампочкой минимального остатка). Получается дискретность показаний уровня топлива примерно 6.75л. И вот смотрю я на уровень — три клетки. А это сколько? 20.25л? Тогда не парюсь, и заправляюсь на проверенной. Или же это уже 13.6л(чуть больше чем при двух секциях уровня)? Тогда лучше рискнуть непроверенной заправкой, и долить в бак чтобы точно хватило до проверенной(не люблю езду с двумя клетками).
Если же ездить только в местности где полно надёжных заправок, тогда да — в большинстве ситуаций хватит даже того недоразумения что у меня штатно на торпеде стоит.
Себе поставил мультитроникс — лежит в бардачке, данные выводит по BT на телефон(у них своё приложение). При тарировке бака по двум точкам дал мне точность остатка примерно ± 1 литр в крайних зонах(легко проверяется заправкой до полного бака, с поправкой на борзость АЗС, и объём приёмной трубы). В середине бака может подвирать больше, но не критично — точность указателя на торпеде гораздо хуже во всём диапазоне. Мне хватает :). Кому мало — есть режим калибровки по 7 точкам, вооружаемся мерной ёмкостью и калибруем бак(но мне кажется это для ситуаций с сильно кривым баком, или сильно нелинейным ДУТ).
По поводу колебания уровня в баке при движении — как минимум мультитрониксовский усредняет показания, и если вы 5 минут(грубо говоря, не мерял) подряд не стоите в горку, то показания не исказятся. Да и стрелочный в зубиле тоже не мгновенно дёргался вслед за поплавком(кстати, потенциометр там был не проволочный).
Так что, подозреваю, что тут дело в чём-то другом.
Показания колеблются от множества факторов, плюс даже в идеальныхз условиях погрешность плюс минус десяток литров.
Так что то что компьютер что-то там выводи, не значит что он это знает. Это сильно ориентировочное значение.
Оно, конечно, ориентировочное, но совпадает с реальностью достаточно неплохо, порядка ± 5% в относительно ровном Екатеринбурге и ± 10% в э… холмистой местности. Для большинства применений такой точности более, чем достаточно.
Есть, конечно, другие датчики измерения объёма топлива в баке но кроме гораздо большей стоимости у них есть и свои недостатки. Например, зависимость от примесей в топливе, смачиваемость датчика топливом(емкостные датчики), низкая надёжность в целом из-за сложности и т.д.
Сколько читал отзывов — говорят, довольно точно, не обманывает.
Перестраховывается он, зараза. До 5 литров как минимум. Люблю заправляться до полного, но чтобы не бегать туда-сюда до кассы. Говорит 30 литров можно заправить, заправляешь 30, а показометр даже не на максимум встаёт.
Заправляюсь всегда до полного, чтобы реже заезжать на АЗС.
Еще заметил, что у вас не значащие байты в кадрах ISO-TP забиты 0x55 или 0xAA, как положено, а вот все у тех же японцев там мусор, оставшийся от предыдущих сообщений в буфере. VAG — Mitsubishi — 1:0
В япошках и корейцах через OBD2 можно спокойно слушать CAN шину, там проще.
Не боитесь забить шину диагностическими запросами? Я так понял, довольно часто посылаются сообщения, а ведь если какой-то модуль уже пишет в шину, то остальные модули ждут своей очереди (по приоритетам). Не проверяли, как влияет ваш на пропускную способность?
Попробуйте, расскажите!
Скорее всего большинство кодов должны подходить, потому что многие блоки между разными VAG машинами взаимозаменяемы.
Простым elm327 адаптером я смогу получить те же данные?
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
Посмотрите в статье, я много кодов написал
www.drive2.ru/b/472129194529128744/?m=526712250266812507&page=0#a526712250266812507
Самодельный дисплей в панель приборов! (черный который снизу, там с завода заглушка была)
Связка: Arduino + ELM327 + 2.2 ili9341.
Теоретически должен подойти для любой машины где есть OBD-II.
На фото для тестов выводит скорость, обороты двигателя
и температуру охлаждайки. Сейчас вместе с цифрами показывает простой индикатор-полоску. В планах сканирование и вывод наименований ошибок, а так-же их сброс.
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
www.drive2.ru/b/489658158654947380
Посмотрите исходник, он в спойлере. Просто виджетам указывал координаты.
Не стал заморачиваться с автолайаутом.
http://raspicarprojekt.de/index.php
Немцы в этом плане красавчики, неоднократно общался на их форумах по поводу VAG Can шины. У них много собрано информации. С помощью ардуино настраивают автоматизацию в машине.
Закину на этот форум инфу о проекте.
Поздравляю с прекрасной реализацией!
Я сам озадачен похожим проектом, в качестве основного устройства, правда, Google Nexus 7, Arduino и CAN-шилд уже приобрел, буду постепенно это все соединять. Правда, авто у меня GMC, для подобных мало информации, снифферить придется и самому все детально анализировать.
Пишите еще)
1) Место расположения датчиков. Взгляд вниз вверх быстрее чем вбок вниз вбок вверх.
2) Материал дисплея. Автомобильные стекла делаются с зажитой от осколков. Что в вашем варианте? Вариант для фильмов ужасов? Когда кусок стекла при аварии разрезает горло водителю? Брррр…
Ну да, не заводское решение. Я же изначально хотел стрелочки приборов заменить на дисплей. Но пока до этого не дошло
Краш тест для шкафа купе? Не, не слышал. ;)
Думаю что обычное стекло опаснее. Вы видели как бьются авто стекла? Стекла на планшетах бьются по иному. Как бьются стекла в шкафах купе не знаю. Не видел.
Но что-то мне подсказывает, что там обычные стекла, совсем не те что применяются в авто промышленности.
Так что еще один, хорошо закрепленный и расположенный в стороне врядли что-то сильно изменит.
Если сможешь помочь реализовать вывод пропусков зажигания по каждому цилиндру и температуру со всех лямбд на приборную панель, то цены вообще не будет твоей идее!
Странно, что нет упоминания pccar в комментариях или статье.
За климат и отображение его отвечает низкоскоростная шина комфорта, которая живёт отдельно, но, как и высокоскоростная основная, тоже заведена в на шлюз.
Лучше работать с данными напрямую, не нужно будет дёргать шлюз, выдерживать таймеры, а просто читать прилетевшие данные и отображать. Это будет более оперативно (высокоприоритетные данные могут прилетать каждые 10мс). А чтобы лишнее не прилетало, то задать фильтры. Правда у MCP2515 их всего 6, но что-то в даташите как-то непонятно про них. Тут бы я воспользовался каким-нибудь STM32 (F105 например) с CAN на борту. Там их 28 полноценных штук. Хватит за глаза.
Если нужно будет как-то стирать ошибки, то можно подсмотреть в шине, что посылает шлюз в шину, когда стирает ошибки из разных блоков.
Я хотел сделать с прямым подключением к сан шине, но провозившись 2 дня, плюнул.
Может быть и вернусь к этому когда-то.
Я, для одного проекта, как раз записывал в лог данные шины во время поездки, а после сидел и пялился на цифры, припоминая маршрут и что было на пути. А чтобы было проще, то записанный лог проигрывался в программе.
В итоге нашёл всё необходимое и больше.
Правда у MCP2515 их всего 6, но что-то в даташите как-то непонятно про них
Есть маска: принимать все сообщения (фильтры не работают), только стандартные с учётом фильтров, только расширенные с учётом фильтров или и стандартные, и расширенные с учётом фильтров,
и 6 фильтров, биты которых сравнивают с битами сообщенияё, исходя из чего сообщение помещается в приёмный буфер или игнорируется.
У сотой серии STM одномоментно работает или CAN, или USB. В своё время был этим неприятно удивлён
У него 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.
А что изменится, если не будет адресного запроса 7E2, а только широковещательный? Все равно ведь придут те же 7EA и 7EC, не так ли?
По-хорошему, при отправке ШВ запроса, следует или обрабатывать все пришедшие, или отфильтровывать какой-то конкретный ответ по ID (в принципе, тогда лучше бы делать адресный запрос, но я могу предположить случай, когда это невозможно — в J1939 такое вполне бывает)
Полагаться на «первое пришедшее» не стоит — потому что не факт, что первым придёт ответ с максимальным приоритетом из диапазона. Первым будет «с максимальным приоритетом из имеющихся» — а это может быть не весь диапазон. Так, в вашем примере, если на шине присутствуют все узлы диапазона, первым должен прийти 7E8 (от устройства 0), но видимо, на шине есть только устройства 2 и 4. И даже если мы знаем список устройств и закладываемся на подмножество вместо полного диапазона — может случиться, что устройство отвалится от шины или вообще выйдет из строя, и не пошлет ожидаемого сообщения, и тогда если вместо фильтра по ID мы таки ждем «первое пришедшее», то опять же примем не то что ожидали.
То есть, подразумевается, что на широковещательный запрос 7DF ответы приходят те же самые, 7E8+X, что и на адресные запросы?Да, это так, но это в случае стандартизированной диагностики. Некоторые модули могут слушать сообщения вообще с другими идентификаторами и работать по протоколу UDS.
А что изменится, если не будет адресного запроса 7E2, а только широковещательный? Все равно ведь придут те же 7EA и 7EC, не так ли?Нет, только от того, кто этот запрос может обработать.
может случиться, что устройство отвалится от шины или вообще выйдет из строя, и не пошлет ожидаемого сообщения, и тогда если вместо фильтра по ID мы таки ждем «первое пришедшее», то опять же примем не то что ожидали.Там даётся время, в течении которого должен прийти ответ. Время на память не помню, но отрезок маленький.
Освежил сведения, да, время, в пределах которого ожидается ответ, минимально и равно 50мс. И да, в ответе содержится информация, что за ответ прилетел.
Но даже если представить, что ответ у нас содержит информацию, что запросили, как будет разруливаться ситуация, когда два устройства посылают 7DF? Тут никакой арбитраж не поможет. Вылезет ошибка.
Нет, только от того, кто этот запрос может обработать.Стоп. Если широковещательный запрос подразумевает получение ответов в диапазоне 7E8+X, то его и должны обрабатывать все, кто посылает такие ответы.
Но какое это отношение имеет к рассматриваемому примеру? И что вообще должен был проиллюстрировать пример? Мне показалось, что неявно подразумевалось утверждение «устройство, посылающее 7E2, будет мешать устройству, пославшему 7DF».Я плохой пример привёл, а после освежения знаний понял, что он не правильный. Проблема действительно возникнет только когда 2 устройства пошлют сообщения с одним идентификатором.
Стоп. Если широковещательный запрос подразумевает получение ответов в диапазоне 7E8+X, то его и должны обрабатывать все, кто посылает такие ответы.В принципе да.
Я ранее не правильный пример привёл, проблемы начинаются, когда 2 устройства начинают посылать диагностические запросы с помощью широковещательного сообщения.
Конкретные модели не назову, просто коллеги выработали эмпирическое правило — при подключении сканера ни в коем случае ему не мешать.
два устройства, посылающих полностью одинаковый ID — это в принципе, недопустимая ситуация для CAN
«если очень хочется, то можно» :-)
Да, есть вероятность (при одновременном старте передачи), что одно из устройств отвалится с ошибкой. Но практика показывает, что счётчик ошибок достаточно большой, и это устройство успеет передать, что ему надо, в следующий свободный момент.
Т.е. да, при проектировании шины два устройства с одинаковым ID — однозначно плохо и неправильно. Но если надо чужую шину слегка модифицировать — ну, приходится и так, с подделкой чужих пакетов…
А, сообразил — проигрыш арбитража ошибкой не считается, а вот несоответствие бита в остальной части кадра — как раз ошибка, увеличивающая счетчик. И да, вы правы — пока счетчик не заполнится это тоже приводит лишь к откладыванию передачи, как и при проигрыше арбитража.
а послать эту комманду самому можно?
хочу кнопку +10 круиз контроль
Только скорее всего если продублировать команды полученные из, они не отработают. Нужно получить прямые команды из кан шины
Вы не думали расширять функционал в сторону параметров ЭБУ двигателя? Для VAG группы очень не хватает удобного инструмента, которые бы мог на лету выводить параметры топливной системы, наддува, зажигания.
Т.к. VAGовские моторы очень легко поддаются форсировке, вывод этих параметров очень был бы интересен! На данный момент на рынке есть только polar fis, который ставится в разрыв проводки приборки, позволяющий выводить нужные параметры. Вечно кататься с VCDS — вообще не вариант, он часто избыточен, а простые ELM адаптеры часто не имеют доступа к нужным параметрам.
![image](https://habrastorage.org/getpro/habr/comment_images/282/94d/576/28294d576337b23a8ec81de358a2d11f.png)
А если я подключаю второй адаптер, то проц начинает перегреваться и тротлить.
Более полной базы по CAN-шинам в открытом доступе, пожалуй, и нет…
Может, пригодится. :)
![](https://habrastorage.org/webt/f-/qs/35/f-qs359t8byvca-fh_hfzfkvnri.jpeg)
![](https://habrastorage.org/webt/nd/jt/yw/ndjtyw0daunstnwaakv5k1b0cu8.jpeg)
![](https://habrastorage.org/webt/am/jp/vl/amjpvlvwpquls1sbvk0ixggc-cc.jpeg)
Хакаем CAN шину авто. Виртуальная панель приборов