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

Считывание OBD2 слишком быстро

Я пишу программу для создания телеметрического приложения, которое будет считывать параметры с моего VW Golf mk4 2001 года выпуска через OBD2 с помощью кабеля, совместимого с ELM327.



Пока что у меня всё получается. Проблема в том, что программа работает слишком медленно (3–4 значения в секунду). Некоторые проблемы могут быть связаны с моим программным обеспечением, некоторые — с ограничениями протокола OBD2 в моём автомобиле, но давайте предположим, что всё дело в моём программном обеспечении, и я собираюсь улучшить его, чтобы оно работало как можно быстрее.



Я прочитал в документации к кабелю, что автомобилю, использующему стандарты OBD2 до 2002 года, запрещено считывать значения быстрее, чем за 100 миллисекунд до установки. В нем говорится, что проблемы могут возникнуть, но они не вдаются в подробности.



У меня такой вопрос: знает ли кто-нибудь, какие проблемы могут возникнуть при чтении информации с OBD2, и можно ли устранить эти проблемы, если они возникнут, просто отсоединив и снова подсоединив клеммы аккумулятора к автомобилю?
Авто и транспорт

Перевод вопроса с Mechanics Stack Exchange
Лицензия: CC BY-SA (2.5–4.0)
Оригинальный вопрос: https://mechanics.stackexchange.com/questions/6463/reading-obd2-too-fast
1
+ Читать

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

  1. Вы заметите, что большинство программных инструментов OBD редко отображают более 4–5 параметров за один просмотр. Я также сталкивался с проблемами при попытке считать слишком много значений одновременно.



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




    1. Скорость транспортного средства каждые 2 секунды.

    2. Частота вращения каждые 1 секунду.

    3. Уровень топлива проверяется каждые 30 секунд.

    4. Напряжение аккумулятора измеряется каждые 5 секунд.

    5. Давление во впускном коллекторе, или давление наддува, измеряется каждую секунду.

    6. Температура охлаждающей жидкости каждые 10 секунд.

    7. Загрузка двигателя каждые 1–2 секунды.



    Хитрость заключается в том, чтобы чаще опрашивать тех, кто меняется чаще.



    В следующий раз, когда вы будете в машине с бортовым компьютером, переключитесь на отображение мгновенного расхода топлива и посмотрите, как часто меняется значение. В моей машине оно меняется каждую секунду. Я бы сказал, что одна секунда — это отличный базовый показатель, потому что он позволяет без проблем считывать 9 параметров PID с интервалом в 100 мс каждую секунду.
  1. Опыт — лучший учитель ;)
  1. «Хитрость в том, чтобы опрашивать тех, кто чаще всего меняется, ещё чаще». Это снова что-то до неприличия очевидное, о чём я не подумал. Спасибо за информацию, она очень ценна!
  1. @NicolaeSurdu, справедливости ради стоит отметить, что для автомобилей, выпущенных до апреля 2002 года, поведение не определено. Неясно, сможет ли третья сторона предоставить вам полезную информацию обо всех транспортных средствах, поскольку у неё её нет. Тем не менее вы всё равно можете создавать полезные системы мониторинга на основе ограниченных данных: например, использовать фильтр Калмана для адаптивной интерполяции/экстраполяции: cs.unc.edu/~welch/kalman
  1. «Но не приводите никаких подробностей». Это меня взбесило, а ведь именно этого я и жду: подробностей :(
  1. Я узнал из документации то же, что и вы, но я удивлён, что в автомобильных стандартах есть такие недоработки, как переполнение буфера. Обычно у них очень строгие режимы тестирования. В любом случае, я протестировал это на своей машине, и, судя по всему, она не позволяет мне опрашивать данные быстрее, даже если я этого хочу. Большое вам спасибо за ваш вклад!

  1. Документация ELM указывает на то, что проблема заключается не только в запросах. На странице 31 этого документа указано, что проблема заключается в скорости, с которой запросы J1850 поступают в систему бортовой диагностики (это следствие обновления стандарта J1979 в апреле 2002 года). В частности, они предостерегают от запросов со скоростью выше 100 миллисекунд (также известной как 10 запросов в секунду), но не приводят никаких подробностей.



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



    Это я так нервничаю: конечно же, это ваша машина.



    Итак, подытожим: похоже, что инструменты для мониторинга OBD доступны в Ubuntu бесплатно. На странице руководства по obdgpslogger представлены два интересных варианта:



       -a|--samplerate <samples-per-second>
    
          Sample at most this many times a second. The software will sleep
    
          temporarily at the end of each loop if appropriate. Keep in mind
    
          there is an upper limit to samplerate, typically capped  by  I/O
    
          on  your  serial  port.  Set  this  to zero to sample as fast as
    
          possible.  BE WARNED. Values greater than ten here are forbidden
    
          for  cars  predating April 2002. If you think your car postdates
    
          early 2002, and you'd like to sample as fast as possible, the -o
    
          option may help
    

    
   -o|--enable-optimisations
    
          Enable  certain  elm327  optimisations. This will [usually] make
    
          sampling faster [not a noticeable amount if you're only sampling
    
          once a second], but makes it much easier to accidentally disobey
    
          the standard if you're sampling as fast as possible.


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



    obdgpslogger --samplerate 10 --enable-optimisations

Вы уже ответили на этот вопрос