Регистрация Войти
Вопрос

Аппаратное обеспечение сканера OBD II с открытым исходным кодом без ELM или STN

Мы создали диагностический сканер OBD-II на базе микроконтроллера STM32, и он работает с большинством автомобилей. Но иногда наше устройство не может определить протокол OBD, в то время как сканер OBD (ELM) его определяет. Мы следуем международной стандартной документации, предоставленной ISO, поэтому наша логика теоретически верна, и эта настройка работает с большинством автомобилей.



Существуют ли реализации OBD-сканера с открытым исходным кодом, в которых вместо микросхем/прошивки используется микроконтроллер, как в ELM327? По сути, мне нужно знать, как сканер OBD II отправляет свои фреймы в шину CAN/K-Line.
Авто и транспорт

Перевод вопроса с Mechanics Stack Exchange
Лицензия: CC BY-SA (2.5–4.0)
Оригинальный вопрос: https://mechanics.stackexchange.com/questions/45345/open-source-obd-ii-scanner-hardware-without-elm-or-stn
1
+ Читать

10 Комментариев

  1. Я не смог найти прошивку для сканера с открытым исходным кодом, но мы решили проблему с KWP, с которой столкнулись. Мы по-прежнему открыты для предложений по сканерам OBD II с открытым исходным кодом.



    Я использую один и тот же контакт GPIO и UART TX, как и положено. Но при переключении между этими двумя режимами контакт переходит в режим высокого сопротивления, из-за чего происходит падение напряжения, которое видит/считывает ЭБУ KWP. Таким образом, в шине возникает ошибочный бит, и, очевидно, «рукопожатие» не происходит. Мы исправили это с помощью подтягивающего резистора.
  1. @JimmyB, да, у меня возникла проблема только с KWP fast. Я решил проблему. Спасибо вам, ребята
  1. Значит, проблема только в KWP fast? — Возможно, вам стоит перенести вопрос на EE.SE.
  1. Анализатор CAN-шины может оказаться более полезным, чем осциллограф или LabJack. Кроме того, вы уверены, что в автомобилях, к которым вы не можете подключиться, есть CAN. В США CAN не был обязательным до 2008 года. Таким образом, существует 12-летний разрыв в использовании транспортных средств, которые могли бы использовать что-то другое, кроме CAN (например, класс 2 или LIN).
  1. @Terry Gould, я использую STM32F103, MSP2515 для CAN и SN65HVDA100 для KWP. Обнаружение CAN и запрос PID работают без сбоев в большинстве автомобилей (за исключением того, что у нас произошел сбой при передаче данных по CAN в Audi Q5), а также хорошо работают ISO9141 и ISO 14230-slow. За исключением ISO 14230-fast (KWP FAST). Он не работает в большинстве автомобилей с KWP FAST.
  1. @vini_i Спасибо, я сейчас этим занимаюсь. Это немного сложно, так как у меня нет телескопа, поэтому я использую LabJack U3.
  1. @Janka, да, я в курсе. Но если сканер может его обнаружить, то и моё оборудование должно его обнаружить. Если только сканер не меняет конфигурацию контактов. Насколько мне известно, разъём OBD является стандартным. Поэтому я не понимаю, почему моя установка не работает, хотя сканер её обнаруживает.
  1. Какие приемопередатчики и другое оборудование вы используете? Не удается обнаружить только определенные транспортные средства или проблема возникает периодически?
  1. Возможно, вам лучше всего будет провести реверс-инжиниринг того, что у вас есть. Прощупайте линии и запишите, что происходит в процессе обнаружения. Затем сравните это с записью того, как ваш сканер выполняет обнаружение.
  1. Вы знаете, что есть автомобили, в которых ЭБУ подключены либо к L-линии (яркий пример — Audi), либо к дополнительной шине CAN? Так что, возможно, дело просто в проводке.
Вы уже ответили на этот вопрос