В моем скетче если что регулируйте задержки строка 62 и 66 . Одна из низ это между отправкой байт на эбу. У меня там стоит 1мс , в ваших скетчах 5мс. Но может и 1 будет работать.
Плюсы моего скетча это: отсутствие delay. Переподключение при обрыве связи, проверка КС , а значит если будет мусор , то на индикацию не пройдут некорректные данные. Также легко добавлять новые пиды.
в вашем скетче delay-и присутсвтуют и нет проверки корректности полученных от PCM данных, поэтому на экране возможно будут проскакивать нереальные значения и подтормаживания, а также плохое реагирования на кнопку. Так для прикола проверьте мой мой скетч.
Если говорить про Delay(1000), которая в в основном цикле, то она там совсем не нужна. Её нужно закомментировать. Я её использовал для отладки. А в остальных случаях я так думаю без задержек не получится. Да и максимум там задержка на 50-100мс.
100 это уже очень прилично я вам скажу. Нормальные программы так не пишут. Например , обороты двс скачками будут отображаться. Мой скетч тоже далеко не идеал. Но delay больших нет. Максимум 5 вроде гдето было. Подобные пару скетчей у меня отлично работают. Посмотрите принцип получения байт от PCM.
Добрый день MaksVV. Спасибо за скетч. У меня работает свой сейчас. Читаю параметры температуры, скорости и обороты двигателя. Но с напряжением по адресу 0x42h почему-то не получается. Возвращает 0x83 0xF1 0x10 0x7F 0x01 0x12 0x16.
MaksVV пишет:
вот исправленный скетч, в том есть косяки . Видимо такой PID 01 42 ЭБУ не поддерживает.
С программами не работал, опыта нет (если подскажете куда копать в этом плане, то тоже буду признателен). Сразу пишу скетч для Ардуино. Если к OBD2 разъёму подключить ELM 327, то данные можно считывать через тот же Car Scanner, например. Но я хочу вывести на панель значение температуры, от этого и пришлось этим заняться.
Могу выложить свои творения которые делал в 2019 году. НО по мимо программы, нужно еще чтоб аппаратная часть была рабочей.
Выложи, пожалуйста, буду очень признателен. По поводу аппаратной части - вот как раз я тоже выше вопрос про это задал. Хотел бы узнать, кто какие ещё варианты использует?
Видел такой вот ещё вариант и на lm393 , вот не понятно, какой в итоге использовать и может ли поменяться результат, если буду использовать эти схемы (пока не собирал, но детали все есть под рукой для сборки).
Mersovod оптимально через Advanced Serial Port Monitor заснифить обмен этой программы через ELM и потом уже нужный обмен повторить через ардуино.
Правильно ли я понимаю, что если не использовать сторонний софт, то надо будет параллельно к сканеру подключиться к K-линии моей же собранной аппаратной схемой, и через SoftwareSerial поставить порт на чтение и вывести все шестнадцатиричные значения через монитор Serial порта?
А если через Advanced Serial Port Monitor, то какая аппаратная часть нужна для этого? Что-то типа "BM9213M Универсальный автомобильный адаптер K-L-линии USB" ? И также надо будет параллельно сканеру подключаться?
* сканером я называю ELM или официальное диагностическое оборудование Mercedes (которое тоже у меня присутствует)
Advanced Serial Port Monitor перехватывает обмен на COM порту компьютера и по этому ничего дополнительно цеплять на K-line не надо !
Просто цепляем elm, запускаем Advanced Serial Port Monitor, запускаем ПО от elm и общаемся с ЭБУ. Потом смотрим в логе Advanced Serial Port Monitor - что посылалось-принималось через COM порт и уже пробуем посылать/принимать эти данные через ваш девайс.
мозги ==> аппаратная часть собранная мной (подсоединённая к K-линии) ==> арудина ==> USB (COM порт)
Ты говоришь что при использовании Advanced Serial Port Monitor ничего цеплять не нужно. Ок, я втыкаю ELM в мозги. ELM работает по блютузу, запускаю на андройде приложение для коннекта к ELM. А COM порт-то на компе как будет слушаться программой Advanced Serial Port Monitor? Если он никуда не подключён. Туплю пока )
Komandir, эти скетчи, по сути, вроде то же самое, что в начале темы были, но попробую.
Вопрос сейчас в другом - я попробовал использовать Advanced Serial Port Monitor, но если я запускаю одновременно мерсовский софт сканирования ЭБУ и открываю в Advanced Serial Port Monitor, то я тем самым занимаю порт и мерсовский софт не работает, т.к. порт занят. Может быть какие-то конкретные настройки нужно сделать в Advanced Serial Port Monitor?
Я точно не помню - может порядок запуска важен. Вообще Advanced Serial Port Monitor не должен занимать порт. Он как бы встраивается между ... Может софт видит что Advanced Serial Port Monitor "подгляывает" и не хочет раскрывать секреты ...
У меня сканер подключается с физическому COM порту №2, через переходник RS232 TO RS485 (RS485 выходом в COM порт). Должен ли я эту галочку "Режим интерфейса RS485" поставить?
А что означают вот эти две красные полоски? Просто они кликабельные и надпись при наведении ни о чем мне не говорит ) Не понятно, должны ли они быть нажаты во время мониторинга или нет.
В общем попробовал я промониторить, выдаёт очень много данных, там порт постоянно общается со сканером, даже до инициализации, поэтому очень сложно было разобраться. Пошёл по другому пути - попробовал разобраться в скетче, описанном в посте #55 от Aku, в итоге вроде как общение с ЭБУ началось, по крайне мере ошибок, которые там заложены в коде не вылезло и я дошёл за запросов температуры. Мозги стандарта ISO 9141, соответственно для запроса температуры ОЖ используется пакет
{0x68, 0x6A, 0xF1, 0x01, 0x05, 0xC9}
в ответ ЭБУ мне присылает такое:
48 6B 1 41 5 0 FA 0 0 0 0
По коду используется 5 байт, тут он = 0, но если смотреть через сканер то должно быть 27 градусов (ЭБУ такое значение отдаёт).
В ответе контрольная сумма верная. Как вариант это ответ от другого узла ЭБУ.
Вы бы все-таки выложили перехваченный массив данных в HEX формате. Можно нажать Clear и сразу после нажатия подключить разъем OBD к авто. Посмотрим что там видно ... Если монитор отображает температуру, то должно быть видно посылки-ответы типа 0x68, 0x6A, 0xF1, 0x01, 0x05, 0xC9
Выкладываю ссылку на лог обмена сканера с ЭБУ на том моменте, где я смотрел температуру ОЖ (но там на экране ещё было два или три других параметра, которые не убрать). На момент сканирования температура была 26 градусов. В логе сразу всё скопом - отправка и приём данных. Что-то мне подсказывает, что он ничем не поможет.
В итоге решил подключить собранную сборку и написанный, загруженный скетч в ардуинку к самой машине (до этого тестировал на купленнм с разборки ЭБУ дома без подсоединения датчиков) и ВОУЛЯ! Всё заработало на реальной машине!
А откуда узнать подобные запросы на параметры, которые описаны тут?
Например я хочу получить уровень топлива, вернуть мозги должны PID = 2F, но какой запрос я должен сделать и как самому мне понимать какие делать для соответствующих PID'ов?
Каждый бит указывает на поддержку определенного PID'а диапазона. Единица в самом правом бите указывает на наличие поддерживаемых PID'ов в следующем диапазоне. Standard PID's
Скажу честно, не пробовал. Авто на улице в снегу)). Бегаю с ноутом для отладки. Не очень удобно. Может быть в выходной попробую.
Заметил, что протокол очень чувствителен к временным интервалам.
В моем скетче если что регулируйте задержки строка 62 и 66 . Одна из низ это между отправкой байт на эбу. У меня там стоит 1мс , в ваших скетчах 5мс. Но может и 1 будет работать.
Плюсы моего скетча это: отсутствие delay. Переподключение при обрыве связи, проверка КС , а значит если будет мусор , то на индикацию не пройдут некорректные данные. Также легко добавлять новые пиды.
Предлагаю свой вариант бортового МК. Добавил немного функционал.
1. Выбор параметра кнопкой.
2. Если температура двигателя меньше 40 градусов, 3 параметра перебираются автоматически.
3. При срабатывании какого-нибудь порога, моргает индикатор и пикает зуммер.
а все таки #45 пробовали?
MaksVV,Спасибо за помощь. Нет. Не дошло до этого. Когда у меня заработало, смысл пропал. Но если очень нужно, то попробую.
в вашем скетче delay-и присутсвтуют и нет проверки корректности полученных от PCM данных, поэтому на экране возможно будут проскакивать нереальные значения и подтормаживания, а также плохое реагирования на кнопку. Так для прикола проверьте мой мой скетч.
Если говорить про Delay(1000), которая в в основном цикле, то она там совсем не нужна. Её нужно закомментировать. Я её использовал для отладки. А в остальных случаях я так думаю без задержек не получится. Да и максимум там задержка на 50-100мс.
100 это уже очень прилично я вам скажу. Нормальные программы так не пишут. Например , обороты двс скачками будут отображаться. Мой скетч тоже далеко не идеал. Но delay больших нет. Максимум 5 вроде гдето было. Подобные пару скетчей у меня отлично работают. Посмотрите принцип получения байт от PCM.
Привет, MaksVV. А почему в скетче №45 Вы считываете напряжение из одного байта SysVolt = buf[n+2]/10.0 ?
В документации на Pid-ы другая формула
(hex)
(Dec)
Добрый день MaksVV. Спасибо за скетч. У меня работает свой сейчас. Читаю параметры температуры, скорости и обороты двигателя. Но с напряжением по адресу 0x42h почему-то не получается. Возвращает 0x83 0xF1 0x10 0x7F 0x01 0x12 0x16.
вот исправленный скетч, в том есть косяки . Видимо такой PID 01 42 ЭБУ не поддерживает.
Добрый день! Пытаюсь повторить Ваше творение ! не могу найти библиотеку данную ! Если не сложно поделитесь . Спасибо! #include "din_ind.h"
Добрый! Библиотека моя личная. Могу скинуть. Моя почта "elektronshik.kudzinсобакаgmail.com"
Ребят, только учусь. Мне нужно тоже получить из машинки температуру. Машина Mercedes W168.
Перебрал почти все скетчи тут, в итоге, для наглядности, по скетчу в сообщении #36 (от MaksVV) выдаёт следующее:
Какие-нибудь программы видят авто через шнурок ?
С программами не работал, опыта нет (если подскажете куда копать в этом плане, то тоже буду признателен). Сразу пишу скетч для Ардуино. Если к OBD2 разъёму подключить ELM 327, то данные можно считывать через тот же Car Scanner, например. Но я хочу вывести на панель значение температуры, от этого и пришлось этим заняться.
Могу выложить свои творения которые делал в 2019 году. НО по мимо программы, нужно еще чтоб аппаратная часть была рабочей.
Mersovod оптимально через Advanced Serial Port Monitor заснифить обмен этой программы через ELM и потом уже нужный обмен повторить через ардуино.
Могу выложить свои творения которые делал в 2019 году. НО по мимо программы, нужно еще чтоб аппаратная часть была рабочей.
Выложи, пожалуйста, буду очень признателен. По поводу аппаратной части - вот как раз я тоже выше вопрос про это задал. Хотел бы узнать, кто какие ещё варианты использует?
Видел такой вот ещё вариант и на lm393 , вот не понятно, какой в итоге использовать и может ли поменяться результат, если буду использовать эти схемы (пока не собирал, но детали все есть под рукой для сборки).
Mersovod оптимально через Advanced Serial Port Monitor заснифить обмен этой программы через ELM и потом уже нужный обмен повторить через ардуино.
Правильно ли я понимаю, что если не использовать сторонний софт, то надо будет параллельно к сканеру подключиться к K-линии моей же собранной аппаратной схемой, и через SoftwareSerial поставить порт на чтение и вывести все шестнадцатиричные значения через монитор Serial порта?
А если через Advanced Serial Port Monitor, то какая аппаратная часть нужна для этого? Что-то типа "BM9213M Универсальный автомобильный адаптер K-L-линии USB" ? И также надо будет параллельно сканеру подключаться?
* сканером я называю ELM или официальное диагностическое оборудование Mercedes (которое тоже у меня присутствует)
Advanced Serial Port Monitor перехватывает обмен на COM порту компьютера и по этому ничего дополнительно цеплять на K-line не надо !
Просто цепляем elm, запускаем Advanced Serial Port Monitor, запускаем ПО от elm и общаемся с ЭБУ. Потом смотрим в логе Advanced Serial Port Monitor - что посылалось-принималось через COM порт и уже пробуем посылать/принимать эти данные через ваш девайс.
Не до конца понял.
Как сейчас у меня:
мозги ==> аппаратная часть собранная мной (подсоединённая к K-линии) ==> арудина ==> USB (COM порт)
Ты говоришь что при использовании Advanced Serial Port Monitor ничего цеплять не нужно. Ок, я втыкаю ELM в мозги. ELM работает по блютузу, запускаю на андройде приложение для коннекта к ELM. А COM порт-то на компе как будет слушаться программой Advanced Serial Port Monitor? Если он никуда не подключён. Туплю пока )
Я про elm в виде шнурка в USB/COM компьютера. А мерседесовская приблуда куда включается ?
Я про elm в виде шнурка в USB/COM компьютера. А мерседесовская приблуда куда включается ?
А, понял, хорошо, попробую через мерседесовский сканер, он с проводом. Спасибо!
Так ещё можно попробовать ...
Komandir, эти скетчи, по сути, вроде то же самое, что в начале темы были, но попробую.
Вопрос сейчас в другом - я попробовал использовать Advanced Serial Port Monitor, но если я запускаю одновременно мерсовский софт сканирования ЭБУ и открываю в Advanced Serial Port Monitor, то я тем самым занимаю порт и мерсовский софт не работает, т.к. порт занят. Может быть какие-то конкретные настройки нужно сделать в Advanced Serial Port Monitor?
Я точно не помню - может порядок запуска важен. Вообще Advanced Serial Port Monitor не должен занимать порт. Он как бы встраивается между ... Может софт видит что Advanced Serial Port Monitor "подгляывает" и не хочет раскрывать секреты ...
Что вот эти настройки обозначают?
У меня сканер подключается с физическому COM порту №2, через переходник RS232 TO RS485 (RS485 выходом в COM порт). Должен ли я эту галочку "Режим интерфейса RS485" поставить?
С такими переходниками не сталкивался.
Может не тот снифер ... я брал тут - https://advanced-serial-port-monitor.soft112.com/
У меня он сейчас не работает - бесплатно работает ограниченное время. Запускать надо в режиме Наблюдатель.
Вашу тему не знаю, но у себя применяю VSPE сплиттер, программа для 32 битной версии бесплатна
А что означают вот эти две красные полоски? Просто они кликабельные и надпись при наведении ни о чем мне не говорит ) Не понятно, должны ли они быть нажаты во время мониторинга или нет.
Я вроде не нажимал там ничего. Просто в HEX обмен смотрел и все.
Выложу тут ссылку на инициализацию - https://russianblogs.com/article/33311624928/
В общем попробовал я промониторить, выдаёт очень много данных, там порт постоянно общается со сканером, даже до инициализации, поэтому очень сложно было разобраться. Пошёл по другому пути - попробовал разобраться в скетче, описанном в посте #55 от Aku, в итоге вроде как общение с ЭБУ началось, по крайне мере ошибок, которые там заложены в коде не вылезло и я дошёл за запросов температуры. Мозги стандарта ISO 9141, соответственно для запроса температуры ОЖ используется пакет
{0x68, 0x6A, 0xF1, 0x01, 0x05, 0xC9}
в ответ ЭБУ мне присылает такое:
48 6B 1 41 5 0 FA 0 0 0 0
По коду используется 5 байт, тут он = 0, но если смотреть через сканер то должно быть 27 градусов (ЭБУ такое значение отдаёт).
В итоге я чёт не пойму, где тут температура?
В ответе контрольная сумма верная. Как вариант это ответ от другого узла ЭБУ.
Вы бы все-таки выложили перехваченный массив данных в HEX формате. Можно нажать Clear и сразу после нажатия подключить разъем OBD к авто. Посмотрим что там видно ... Если монитор отображает температуру, то должно быть видно посылки-ответы типа 0x68, 0x6A, 0xF1, 0x01, 0x05, 0xC9
Выкладываю ссылку на лог обмена сканера с ЭБУ на том моменте, где я смотрел температуру ОЖ (но там на экране ещё было два или три других параметра, которые не убрать). На момент сканирования температура была 26 градусов. В логе сразу всё скопом - отправка и приём данных. Что-то мне подсказывает, что он ничем не поможет.
Там есть кнопочка ASCII/HEX - можно в HEX ???
Вот в HEX
Насколько я вижу тут нет протокола OBD ... Это какой то свой протокол MB.
Получается, нужен всё-таки шнур с Элемкой? Там точно OBD будет ....
Скорее всего. MB не делится своими протоколами.
> в ответ ЭБУ мне присылает такое:
> 48 6B 1 41 5 0 FA 0 0 0 0
В итоге решил подключить собранную сборку и написанный, загруженный скетч в ардуинку к самой машине (до этого тестировал на купленнм с разборки ЭБУ дома без подсоединения датчиков) и ВОУЛЯ! Всё заработало на реальной машине!
Это дома:
А это в машине:
Ok
Кидаю. Это пример, на его основе соберете свой.
А откуда узнать подобные запросы на параметры, которые описаны тут?
Например я хочу получить уровень топлива, вернуть мозги должны PID = 2F, но какой запрос я должен сделать и как самому мне понимать какие делать для соответствующих PID'ов?
Нужно отправить PID 01 00. Будет ответ всех поддерживаемых.
А как узнать какой за что отвечает?
Запрос 0100 только для диапазона 0x01-0x20.
Ответ содержит 4 байта. Для запроса 0100, к примеру, приходит ответ:10111110 00011111 10101000 00010011
Каждый бит указывает на поддержку определенного PID'а диапазона. Единица в самом правом бите указывает на наличие поддерживаемых PID'ов в следующем диапазоне. Standard PID's
Это я вроде понял, не пойму откуда берётся последнее значение?
{0xC2, 0x33, 0xF1, 0x01, 0x05, 0xEC};
Т.е. 0хЕС
Это контрольная сумма - в данном протоколе младший байт суммы всех остальных !
0xC2+0x33+0xF1+0x01+0x05=0x01EC
В ответе от ЭБУ последний байт считается по той же схеме и если он не совпадает - произошла ошибка передачи !!!