Проект: считывание/стирание ошибок ECU + часы + немного охраны = вместо штатных часов Опции

[SSh]

Код ошибки имеет опред. структуру, которая определяется по позициям след. образом:

Первая позиция:
P - код работы двигателя и/или АКПП
B - код работы электростеклоподъёмников, подушек безопасности, центрального замка и т.д., того что находится в кузове
C - код работы ходовой части (шасси)
U - код взаимодействия между электронными блоками

ЭБУ по контакту 7 выдает нам только коды, начинающиеся с "Р"

Вторая позиция:
0 - общий для OBD-II код
1 и 2 - код производителя
3 - резерв

Третья позиция - типы неисправностей:
1 и 2 - топливная система или подача воздуха
3 - система зажигания
4 - вспомогательный контроль
5 - холостой ход - вот тут немного не понятно ....
6 - ECU или его цепи
7 и 8 - трансмиссия

Четвертая и пятая позиции - порядковый номер ошибки

Например, Р0110:
Р - Ошибка двигателя или АКПП
0 - OBD-II код
1 - топливная система или подача воздуха
10 - номер ошибки

Или Р0720
7 - трансмиссия

Т.е. насколько я понял остается расшифровка только последних 3-х цифр, Р0 - общие для всех ошибок...

[AZM.SU]

SSh, спасибо конечно, но это общие сведения и касаются они кодов ошибок в общем, вопрос же стоит так:

Как из двух байт (хай и лоу) возвращаемых ECU в ответ на запрос ошибок получить вид
P0110
т.е. как, например, число 0110 упаковано в указанные 2 байта?

Возможных вариантов множество, примеры:
1) BCD - аккурат 4 цифры;
2) unsigned int 2 byte as dec string - от 1 до 5 цифр;
3) (string) unsigned char hi byte as dec string + unsigned char lo byte as dec string - от 2 до 6 цифр;
... и ещё минимум 2 варианта, которые только я вижу...

Гадать и тыкать ненавижу, может быть есть у кого ни будь точные сведения?

[SSh]

AZM.SU, я нигде не смог найти конкретного алгоритма преобразования полученных байтов в код ошибки. Думаю, если все-таки ничего откопать не удасться, то придется искуственно вызвать ошибку (отключив например какой-нибуть датчик) считать код с ЭБУ и сопоставив с тем-же кодом из таблицы DTC понять что и как там происходит. Примерно таким способом я воспользовался когда надо было выяснить формат записи пробега в EEPROM.

[AZM.SU]

SSh, этот вариант я оставляю всё же на крайний случай.
И так, хожу к машине по 15 раз в день, да ещё и верчуть как уж подлазая к разъёму, что бы подоткнуть контакты в дырочки =)

---

Кстати, а как EvoScan и подобный софт работающий через опенпорт показывают ошибки - в каком виде, сколько позиций (я так понял, сохраняются 3 ошибки и 1 "текущая")?

[SSh]

Честно говоря - не знаю, в то время когда игрался с EvoScan-ом хотел тоже вызвать ошибку чтоб посмотреть, но так и не сделал этого. А сейчас абсолютно нет времени на подобные эксперименты (IMG:style_emoticons/default/smile.gif)

[SSh]

Вот еще что нашел относительно декодирования отклика ЭБУ
http://en.wikipedia.org/wiki/OBD-II_PIDs

Начиная с MODE3

A request for this mode returns information about the DTCs that have been set. The response will be an integer number of packets each containing 6 data bytes. Each trouble code requires 2 bytes to describe, so the number of packets returned will be the number of codes divided by three, rounded up. A trouble code can be decoded from each pair of data bytes.

ну и т.д...

Что я понял при беглом просмотре:
Код ошибки состоит из двух байтов, назовем их А и В.
Байт А раскладываем побитно и имеем:

А7 и А6 - первый символ кода ошибки,

Код

A7 A6    First DTC character
-- --    -------------------
0  0    P - Powertrain
0  1    C - Chassis
1  0    B - Body
1  1    U - Network

А5 и А4 - второй символ,

Код

A5 A4    Second DTC character
-- --    --------------------
0  0    0
0  1    1
1  0    2
1  1    3

А3, А2, А1 и А0 - третий символ,

Код

A3 A2 A1 A0    Third DTC character
-- -- -- --    -------------------
0  0  0  0    0
0  0  0  1    1    
0  0  1  0    2
0  0  1  1    3
0  1  0  0    4
0  1  0  1    5
0  1  1  0    6
0  1  1  1    7
1  0  0  0    8
1  0  0  1    9

Раскладываем байт В, старшие биты - В7...В4 - четвертый символ, младшие В3...Б0 - пятый
Все 5 символов вместе дают нам код ошибки в таком виде, в каком он представлен в описаниях (например, P0105 Неисправность датчика давления воздуха)

[AZM.SU]

Кто ни будь, растолкуйте, вот здесь http://evoecu.logic.net/wiki/MUT_Requests есть запросы на получение температуры:
07 | CoolantTemp | Coolant Temp | F | x*1.8+32
10 | CoolantTempScaled | Coolant Temp Scaled | F | 1.8*x-40
какая температура всё же правильная?
По идее формула "x*1.8+32" говорит нам что ECU в ответ на этот запрос выдаёт температуру в градусах цельсия/2, ибо 2*1.8+32 аккурат 35,6F, что и равно 2 градуса цельсия.
Удивляет, что по этой формуле отрицательных величин быть не может, или возвращаемый байт надо интерпретировать как байт со знаком?

Ещё момент - по формуле:
235*[InjPulseWidthW]/1000000*[RPM]*2
где 235 это пропускная способность форсунок у движка 4G13,
получается, что в моей машине движок жрёт бензина 1,07 литра в час, однако много!
Никто не знает где можно уточнить, сколько родные форсунки льют, что бы верное число ввести?

Ну и наконец последний момент - растолкуйте мне, человеку далёкому от ДВС, по русски, что означают параметры из таблички http://evoecu.logic.net/wiki/MUT_Requests хотя бы самые важные, что бы понять за какими следить желательно, например:
27 | OctaneFlag | Octane Level -- что это?
2C | AirVol | Air Volume -- а это для чего?
ну и так далее, исключая очевидные вроде "Injector Pulse Width" (длительность открытия форсунок), "Battery Level" (напряжение на аккумуляторе) и "Engine RPM" (обороты двигателя).

По намёку Главного, создал отдельную тему, где надеюсь, соберётся со временем полнейшая информация о каждом параметре:
MUT протокол: запросы и ответы - что есть что и о чём говорит?

[zhuns]

Никто не знает где можно уточнить, сколько родные форсунки льют, что бы верное число ввести?

Может уже не актуально - сколько времени прошло. А вдруг, пригодится
Я параметры форсунки нашел так. Вначале узнал ее номер, как запчасти
(На машине форсунка Bosh № 0 280 155 723). Зная его находим параметры форсунки здесь или лучше здесь
Узнал, что производительность форсунки равна 227 cc /min

[BpyH]

Всем доброго времени суток.
Наткнулся на интересную тему ТЫК вроде как есть исходник, но я не вникал туда так как язык понимаю только на бейсике.

[Gummi_bear]

Если у кого есть шнурок и ноутбук, буду признателен за то, что напишите на васике или ещё чем ни будь процедуру инита и покажете что отвечает ваше ECU в ответ на 01h на скорости 5 бод, или если кто дамп обмена данными с порта снимет начиная с процедуры инита и до первого запроса, в том же EvoScan или подобном софте (уж это сделать думаю не так сложно, вроде софта навалом, например: http://www.aggsoft.ru/serial-port-monitor/...ort-sniffer.htm или http://archive.rin.ru/more/15983.html/ или гугл находит).

Если есть кто на лансере с движками отличными от 4g13 из Новосибирска, будут признателен если отпишитесь и найдёте время подъехать вечерком для просмотра что ответит их ECU на инит. Обещаю, всю машину до тла не сожгу, максимум несколько метров проводки =)

Мдас ... тема давняя, но чем черт не шутит :-)

У меня на столе лежит мозг от 4G18 и ардуина мега 2560 + L9637, инит на ней написать пока не получается :-(
Пробовал как вы в своем посте описывали по русски, а фиг! мож ардуина не умеет с нестандартными скоростями UART работать?
Тогда надо самому программно писать SoftwareSerial, т.к. из доступных библиотек пробывал, не работают, или под мегу328 затечены х.з. :-(

мож кто подскажет? стенд для экспериментов есть :-)

[Gummi_bear]

С утра пораньше сходил к машине с девайсом.
Согласно протокола ISO 9141-2 инит вообще не прошел, то есть на посылку байта 33h ECU не удосужилось ничего ответить на скорости 10400.
Согласно MUT-II ответ на инит по прежнему 55 70 85.
Исходя из здравого смысла, начинаю приходить к мнению, что важно лишь 55 и 85, где 55 - синхро байт, 85 - байт конца посылки ответа.
Вероятно надо после 85 просто вернуть ему в ответ FE (инверсия байте 01, т.е. адреса) и далее попробовать работать по схеме:
1. передаём запрос
2. получаем ответ
3. передаём инверсно последний байт ответа (подтверждаем приём).

Согласно пдфке в 11 посте, у меня прошло все как там описано, за исключением того, что ECU не присылает мне последний ответ 0xCC
Моск на PIDы что-то отвечает, я правда пока не знаю что :-)

На запрос PID 0x14 отвечает 55537 (DEC)
Мож я что-то не до конца вкурил в коде :-)

Вот код, с которым получилось установить соединение.

 My_OBD.txt ( 6,29 килобайт ) Кол-во скачиваний: 1404


Код не мой, меня не пинать, я только подправил для своего железа: Arduino Mega 2560 + L9637D
Код стырил здесь: http://compcar.ru/forum/showthread.php?t=4992
На авторство не претендую, но т.к. с афтырем сего опуса связаться тот форум мне не дает (не заслужил еще), выкладываю тут.

Камменты в коде не мои, я только номера UART поправил.

Собственно как и ТС уперся в правильные PIDы, и работу с ними :-(