Версия для печати темы
Нажмите сюда для просмотра этой темы в обычном формате
Форум Технических Маньяков _ Умелые руки _ Проект: считывание/стирание ошибок ECU + часы + немного охраны = вместо штатных часов
 |
+7-978-708-85-73 Дроссель Amadeus Productions. Быстрый заказ по телефону. (Viber, WhatsApp, Telegram) |
Автор: AZM.SU 15.6.2011, 15:46
Так как я крайне не люблю часы с 12-ти часовым форматом времени, то решил заменить в машине штатные часы на собственной разработки, а раз уж всё одно делать на микроконроллере, то счёл правильным дополнить функционал возможностью считывать/сбрасывать ошибки ECU и сделать возможность выдавать некий сигнал на какое либо исполнительное устройство, если обороты двигателя привысят некое число XX но до этого не проведена какая либо специальная процедура (пусть даже элементарная, например не поднесён магнит с крытому геркону).
Итого, хочется получить:
+ Часы с 24х часовым ворматом отображения времени;
+ Считывание/сброс ошибок ECU;
+ Дополнительную охранную систему, которая беспрепятственно позволяет заводить двигатель дистанционно, на прогрев, но блокировать его работу если не сняли с охраны но попытались двигаться (подняли обороты выше XX).
Пока это проект, так как устройство собрано, но работает лишь как часы, все попытки научить его соединяться с ECU были тщетны.
Девайс сейчас выглядит так:
Схема (уж простите что не причёсана, ведь пока проект):
Процедура иницимализации соединения с ECU которую пробовал:
Pause 300ms
'Send 0x01 (00000001) at rate of 5 baud (LSB) with a Start Bit and a Stop bit
'Send Startbit
Set K line low (0)
Pause 200ms
'Now to send out 0x01
'Send out bit0
Set K line high (1)
pause 200ms
'Send out bit1
Set K line low (0)
pause 200ms
'Send out bit2
Set K line low (0)
pause 200ms
'Send out bit3
Set K line low (0)
pause 200ms
'Send out bit4
Set K line low (0)
pause 200ms
'Send out bit5
Set K line low (0)
pause 200ms
'Send out bit6
Set K line low (0)
pause 200ms
'Send out bit7
Set K line low (0)
pause 200ms
'Send Stopbit
Set K line high (1)
Pause 200ms
Switch to 15625 baud
Receive C0 55 EF 85
send FE
Receive E4 ' First Byte of ECU ID
Send FF
Receive B3 ' Second byte of ECU ID
Send FE
Receive E4 ' First Byte of ECU ID
Send FF
Receive B3 ' Second Byte of ECU ID
Send FD
Receive 20
Send FD
Receive 20
Send FD
Receive 20
Соответственно в си это выглядит у меня так:
WHdisplayPrint("CONNECT TO ECU..");
#asm("cli")
UBRR0H=0;
UBRR0L=0;
UCSR0B=0;
UCSR0A=0;
UCSR0C=0;
#asm("sei")
PORTD.1=0; // В обычном состоянии, когда зажигание выключено USART отключен а линию держим в состоянии "High", что бы через нагрузочный резистор на 510 ом не кушать аккумулятор и резистор не греть
delay_ms(3000); // Сделаем задержку на 3 сек, что бы этот переход с лог 1 на лог 0 не воспринимался как что то нужное
// Slow Init
PORTD.1=1;
delay_ms(300);
// Send 0x01 (00000001) at rate of 5 baud (LSB) with a Start Bit and a Stop bit
PORTD.1=0; // стартовый бит
delay_ms(200);
PORTD.1=1; // первый бит байта x01
delay_ms(200);
PORTD.1=0;
delay_ms(1400); // 7 бит =0
PORTD.1=1; // стоповый бит
delay_ms(200);
PORTD.1=0; // опустили стоповый бит
// Переключаемся на 15625 бит/сек
// USART initialization
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART Receiver: On
// USART Transmitter: On
// USART0 Mode: Asynchronous
// USART Baud Rate: 15625
#asm("cli")
UCSR0A=0x00;
UCSR0B=0x98;
UCSR0C=0x06;
UBRR0H=0x00;
UBRR0L=0x0F;
#asm("sei")
Buffer_clear();
// начало для теста (в течение 5 сек попробуем принять что нам ответит ECU и покажем это на дисплей)
for(TmpIndexInRecivSnd=0; TmpIndexInRecivSnd<8; TmpIndexInRecivSnd++){MassivECUid[TmpIndexInRecivSnd]=0;}
TmpTimer0=0;
TmpIndexInRecivSnd=0;
TmpFlagConnectOk=0;
while (TmpTimer0<5 && TmpFlagConnectOk ==0){
if (TmpIndexInRecivSnd < 7){
TmpRecivChar=Buffer_getchar();
if (rx_buffer_empty0 ==0){
MassivECUid[TmpIndexInRecivSnd]=TmpRecivChar; TmpIndexInRecivSnd++;
}
}else{TmpFlagConnectOk=1;}
} // while (TmpTimer0<5 && TmpFlagConnectOk ==0)
if (TmpFlagConnectOk ==0){ErrorECUconnect(2,99); return;}
WHdisplayClear();
WHdisplayPrint("ECU CONNECT OK");
sprintf(OULCD_bufferStr0, "%02X%02X%02X%02X%02X%02X%02X%02X", MassivECUid[0], MassivECUid[1], MassivECUid[2], MassivECUid[3], MassivECUid[4], MassivECUid[5], MassivECUid[6], MassivECUid[7]);
WHdisplaySetKursor(0, 1);
WHdisplayPrint(OULCD_bufferStr0);
delay_ms(5000);
WHdisplayClear();
return;
// конец для теста
В общем столкнулся с проблемой: ничего ECU в ответ на такой инит не шлёт.
Изначальна информация по иниту связи взята по адресу:
http://www.myrollingroad.com/showthread.php?t=60
но там встречается и упоминание что надо слать на 5 бод не байт 01 а байт 33, в общем всё мутно.
Соответственно прошу помощи - может быть кто то может помочь осциллограммами связи с ECU, скажем снять осциллограмму с K-line при соединении какой ни будь софтины через шнурок на FT232 или так располагает ясными и чёткими сведениями о том, что за сигналы нужно передать/принять?
P.S. Если у кого какие идеи есть что ещё желательно прикрутить в готовый девайс, то озвучивайте, постараюсь уложить, по окончании работ над девайсом выложу схему причёсанную, прошивку и платку.
Автор: Titus 15.6.2011, 16:44
Хм, идея просто обалденная 
по инфе - кто-то из ребят может подтянется.. или попробовать Ежика спросить в личку 
Автор: AZM.SU 15.6.2011, 16:55
Соединение с ECU проходило, просто у меня в сишнем коде был небольшой недочёт, а именно - код ждал прихода 7 байт от ECU, поправил, по факту приходит только 3 байта (в шестнадцатеричке):
55 70 85
вместо
C0 55 EF 85
причём стабильно 55 70 85, думал может что сбоит, мало ли, 10 раз выслал запрос к ECU ответ одиновков.
Кстати на том же форуме myrollingroad.com попадались и сообщения где указывают что надо переключаться на скорость не 15625 а на 10400.
Посмотрел на эти байты в бинарке и с стартовыми стоповыми битами и без таковых и проинвертировав биты соответствующие байтам 55 70 85 - всё мимо.
Никак C0 55 EF 85 не получается. Либо где-то пропуски бит, но это значит скорость не 15625 либо эти 3 байта всё же нормально.
В общем если кто сможет пояснить что считать нормальным, а что нет, буду признателен.
Titus, пока это ещё это лишь гадкий утёнок, а в конечном итоге да, это можно превратить в нечто хорошее.
Да и по цене на компоненты не так дорого получается, самое дорогое дисплей (почти 300 руб, но его заменить можно легко на менее дорогие), остальное всё укладывается менее чем в 200 рублей, в общем выходит неплохая замена даже если это будут только часы и измеритель напряжения бортсети.
Автор: DmitryVS 15.6.2011, 21:49
Предложение по функционалу: не по оборотам блокировать, а по показания датчика скорости (либо от ЭБУ, либо с импульсного входа спидометра).
Автор: Titus 15.6.2011, 22:11
AZM.SU, давай доделывай, можно будет запустить вообще в коммерческий юз - ибо девайс супер
по фичам и тп - если не против - можем подумать все вместе, чего ему еще не хватает и тп - основная задумка у тебя очень классная
Автор: AZM.SU 15.6.2011, 23:08
Это поистине отличная идея!
Спидометр я конечно трогать не буду равно как и лишние провода тянуть не предполагаю, есть же запрос который выдаёт "Vehicle speed".
Как то я сглупил что сразу о скорости не подумал.
по фичам и тп - если не против - можем подумать все вместе, чего ему еще не хватает и тп - основная задумка у тебя очень классная :)
Коммерческий юз можно, если ни чьи из заседателей этого форума права/доходы это не ущемит.
А так - есть схема, есть печатка, код как доведу, если никто не против, в открытый доступ выложу на форум.
Что касается фич - что угодно.
Если нужно, то ещё полно ног на контроллере, можно хоть флешку зацепить и логировать всё на неё, хоть I2C память, хоть таблеткой-ключиком домофона "открывать" перед движением, хоть приятным голосом семпла с флешки говорить "вы превысили установленный предел оборотов двигателя".
Правда, лучше выбирать что надо, а не пытаться засунуть всё и сразу, а то припаивать разное и писать обвязку этого устать могу, всё же в контроллере не так много оперативной и памяти программ, придётся очень постараться что бы навешать и голос и логирование и GPS координаты с отдельного модуля и вывод всех значений да ещё и по голубому зубу на мобильный телефон =)
Доделать, я обязательно доделаю, даже если для этого придётся 1000 и 1 раз сходить от ЭВМ до автомобиля или вырвать из него ECU и разобрать вскрыв консервным ножиком =)
Другой вопрос - если найдутся те, кто помогут разобраться с протоколом, хотя бы до уровня "инициализировать соединение, отправить простенький запрос и получить на него ответ", то времени на разработку уйдёт на пару-тройку порядков меньше, чем при беготне и выяснению всего методом тыка.
Пока я не очень понял где тот самый Ёжик, которому надо писать в личку, надеюсь он сам заглянет и может что подскажет, а может даже и осциллограмму процесса инита обмена, запроса и ответа даст или просто пнёт меня в нужную почку, что бы я побрёл в правильном направлении.
----------
Развёрнуто о том, что видел читал, что понял, что нет.
Имеется информация:
1) http://en.wikipedia.org/wiki/OBD-II_PIDs // прочитано
2) http://www.myrollingroad.com/showpost.php?p=111&postcount=3 // накидал даже на досуге на сях генератор этой самой CRC
3) http://www.chiptuner.ru/content/obdcod // расшифровка прям в девайсе не запланирована (считав код и дома в интернете найти можно что за ошибка), по этому прочитал бегло
4) XML файл программы EvoScan // не всё пока ясно
5) http://www.myrollingroad.com/showthread.php?t=60 и http://www.myrollingroad.com/showthread.php?t=65 // попробовал соединиться как указано, ECU отвечает 55 70 85 вместо C0 55 EF 85, во втором источнике указано что ответ должен быть 55 EF 85, близко но не оно - приплыли.
6) http://www.myrollingroad.com/showthread.php?t=32 // прочитано, конфликтует с п.5 по иниту (33 вместо 01 надо слать) и дальнейшему обмену 10400 вместо 15625 бод
Мутные моменты (требуется уточнение):
A) Информация из п. 5 либо кривая, либо не для того ECU что у меня, либо у меня ошибки в коде.
B) Есть у кого ни будь понимание почему именно C0 или 55 в том или ином месте ответа ECU и почему слать в ответ такой последовательности надо именно FE а не какое другое значение?
Ведь нутром чую, что этим самым ECU что-то пытается сказать, например 55h вероятно байт для проверки синхронизации и скорости порта, уж слишком специфичен он в виде бит.
C) в п. 5 говорится:
For example if you wanted to know the RPM of the engine. Send 21 and it will reply with a answer ...
хотя в п. 1,2 нет никакого "отправьте просто 21 и получите RPM", там целый пакет надо формировать а не 1 байтик слать.
D) Не понятно как лучше работать по ISO 9141-2 или по MUT-II протоколу, что бы уметь читать/сбрасывать ошибки и другие параметры, например ту же скорость и желательно не только ошибки ECU двигателя но и ECU ABS.
E) ECU двигателя и ECU ABS сидят на одной шине но у них просто адреса разные или как то ещё хитрее? То есть как сказать им - сейчас я обращаюсь к двигателю, а вот этот запрос к АБС?
Автор: Titus 15.6.2011, 23:30
Дык со мной и обсудим, я даже думаю создать скоро раздел внутренних разработок нашего форума - если интересно поучаствовать будет в долях - велкам
Автор: Titus 15.6.2011, 23:31
Ёжик вот:
http://forum.amadeus-project.com/index.php?showuser=9
Отпиши ему в личку, с приветом от меня (сам он редко бывает на форуме, вряд ли зайдёт сюда) - может быть, поможет
Автор: alkrymov 16.6.2011, 6:46
Обалдеть идея. Жду продолжения с нетерпением =)
Автор: SSh 16.6.2011, 8:12
Если поможет разобраться с обменом - проект MUTLogger. В архиве схемы и исходники.
MUTLogger.rar ( 169,07 килобайт )
: 795
Автор: AZM.SU 16.6.2011, 16:38
SSh, мне попадались куски этого проекта но весь целиком я его не видел. Спасибо за архивчик!
Ах да, это не всё спасибо, есть и второе - за размеры платки (из Вашей темы "http://forum.amadeus-project.com/index.php?showtopic=600").
---
Накопал файлик с спецификацией протокола ISO 9141-2, выкладываю здесь, вдруг кто захочет повторять "подвиги":
ISO_9141_2_1994.pdf ( 2,35 мегабайт )
: 4375
Никому слйчайно не попадалось ли подобных файликов с описанием протокола MUT-II?
А то чужой код это хорошо, но ещё лучше знать почему именно то и именно тогда в нём делается, а то начинает мне сдаваться что на моём 4G13 не совсем такие ответы ECU как на 4G18.
Может кто с форума в Новосибирске есть, у кого 4G18 движок или иной из списка поддерживаемых EvoScan, попробовать зацепиться к его шине, глянуть что выдаст в ответ на инит соединения.
Автор: SSh 16.6.2011, 17:17
AZM.SU, спрашиваю просто ради интереса... Я тоже пару лет назад загорелся подобной идеей, даже писал об этом на форуме, но пока то да се, прикинул что это (считывание ошибок) совершенно ненужная мне функция... На этом и забросил все дела по теме. Как-раз все файлы и ссылки что я выкладывал - нарытая в то время инфа.
Интересная идея - блокировка по достижению опред. оборотов или скорости, но в принципе импульсный сигнал с датчика скорости выведен отдельным контактом на диагностическом разъеме - N14 если не ошибаюсь, надо будет в сервис мануал заглянуть... А еще легче подцепиться непосредственно к контактам 11 (тахометр) или 12 (спидометр) белого разъема приборки.
Автор: AZM.SU 16.6.2011, 17:38
Импульсный сигнал то легко снять и обработать даже на самом чахлом микроконтроллере вроде ATtint13, час программирования и даже кроме всего "отпираться" будет ключиком от домофона.
Потом, как с этим проектом закончу наверно накидаю простенький проект только под этот функционал.
А так задуряться (считывание ошибок и иже с ним) я начал потому что первичная цель: сделать хорошие часы.
Далее мысль шла так: но не на К176ИЕ3 же их делать, а значит микроконтроллер, а значит индикатор символьный, а раз так, то почему бы не ошибки читать да сбрасывать, а если уж читать, то почему бы по тому же протоколу не читать обороты или скорость, а если уж читать обороты, или скорость, то почему бы не завязать это к охране.
Как с чтением разбирусь, так видимо далее мысль пойдёт: раз уж всё читать можно, то почему бы не вычислять расход топлива или другие вещи (хотя лично мне на расход по-барабану).
Ещё мне нравиться осваивать новые горизонты, как хобби. GPS, GSM модули, всякие однопроводные цифровые ключики - пройденные этап, а тут такая игрушка ECU целого автомобиля, да ещё и с автомобилем! Грех не разобраться.
Да и всю найденную инфу сюда выкладываю, вдруг кто захочет что-то иное сделать или просто разобраться, заглянет на форум и ругаться матом не будет, потому что вся информация в одной теме, сообщение к сообщению, не надо половину интернета обходить и на 7 языках читать учиться.
Автор: Mihail V 16.6.2011, 17:42
Интересно было бы построить подобный прибор, типа контрол-юнит датчиков с мультидисплеем, показания параметров например:
1. Температура выхлопа
2. Давление масла
3. Давление наддува
4. Температура масла
и т.д.
Такое возможно? В принципе с Сергеем уже говорили на эту тему, данные показания остро необходимы на турбо машине, но засирать панель датчиками очень не хочется!
Автор: AZM.SU 16.6.2011, 19:10
Mihail V, если ECU знает эти параметры и может их выдать, то дело за малым.
Все кроме пункта 3 вроде фигурируют в OBD-II PIDs.
Если ECU не знает какого из параметров и датчиков нет нужных в машине, то тут только запиливать датчики, но это уже совсем для другого проекта или spin-off от этого проекта.
---
Ладно, подожду до завтра, может кто здесь отпишется из людей знающих низкий уровень протоколов связи, если нет, то попробую отбросить мысли о MUT и проинитить соединение согласно спецификации ISO 9141-2, посмотрю как на это выругается, а если не выругается то какие PID умеет обрабатывать.
Ох как же я ненавижу метод тыка...
Автор: SSh 16.6.2011, 19:37
Я, кстати, в бытность еще стуентом на ВАЗ 2103 сделал вместо штатных часов электронные, на К176ИЕ12, ИЕ13.
Самым трудным было выточить обойму... Ну и SMD элементов в то время не было, вся конструкция поместилась на 2-х платах между которыми были установлены АЛС333.
Автор: AZM.SU 17.6.2011, 5:49
С утра пораньше сходил к машине с девайсом.
Согласно протокола ISO 9141-2 инит вообще не прошел, то есть на посылку байта 33h ECU не удосужилось ничего ответить на скорости 10400.
Согласно MUT-II ответ на инит по прежнему 55 70 85.
Исходя из здравого смысла, начинаю приходить к мнению, что важно лишь 55 и 85, где 55 - синхро байт, 85 - байт конца посылки ответа.
Вероятно надо после 85 просто вернуть ему в ответ FE (инверсия байте 01, т.е. адреса) и далее попробовать работать по схеме:
1. передаём запрос
2. получаем ответ
3. передаём инверсно последний байт ответа (подтверждаем приём).
Если у кого какие мысли есть относительно моих предположений - высказывайте.
Если у кого есть шнурок и ноутбук, буду признателен за то, что напишите на васике или ещё чем ни будь процедуру инита и покажете что отвечает ваше ECU в ответ на 01h на скорости 5 бод, или если кто дамп обмена данными с порта снимет начиная с процедуры инита и до первого запроса, в том же EvoScan или подобном софте (уж это сделать думаю не так сложно, вроде софта навалом, например: http://www.aggsoft.ru/serial-port-monitor/serial-port-sniffer.htm или http://archive.rin.ru/more/15983.html/ или http://www.google.ru/search?q=%22com+port%22+%D0%BE%D1%82%D0%BB%D0%B0%D0%B4%D0%BA%D0%B0+freeware).
Если есть кто на лансере с движками отличными от 4g13 из Новосибирска, будут признателен если отпишитесь и найдёте время подъехать вечерком для просмотра что ответит их ECU на инит. Обещаю, всю машину до тла не сожгу, максимум несколько метров проводки =)
P.S. Проект "MUTLogger" господина Joerg Balitzki from Germany оказался бесполезен, более того у этого господина в коде полный бардак, одни только задержки чего стоят, не говоря уже о том, что о протоколе связи он знал лишь понаслышке, в некоторых местах мы тупо ожидаем 7 байт, а если они не приходят то просто игнорируем этот факт, впрочем и если приходят то тоже не обращаем на них внимание.
Автор: ByKA 17.6.2011, 9:27
В прошлом году пытался подружить атмегу с лансом. Но инициализации так и не прошла.
Вот еще одна ссылочка с фрагментом кода: http://www.pajero4x4.ru/bbs/phpBB2/viewtopic.php?f=30&t=37792. Может поможет.
Если на выходных получится попробую получить дамп инита с evoscan... Хотя, мне кажется, эти снифферы только со стандартными скоростями работать будут...
И вот еще кусок кода инициализации по ISO9141 для arduino:
// The init process is done in timed sections now so that during the reinit process
// the user can use the buttons, and the screen can be updated.
// Note: Due to the timed nature of this init process, if the display screen takes up too much CPU time, this will not succeed
void iso_init()
{
long currentTime = millis();
static long initTime;
static int initFirstDelay = 300;
#ifdef ISO_9141
// CodeOptimization (128bytes)
// Changed ISO init 2-7 steps to take values from array (could be moved to PROGMEM)
// ISO_14230_slow could be changed too (same way)
byte ISOSteps[8] = {
0, //0 not used
30, //1 HIGH
20, //2 LOW
40, //3 HIGH
40, //4 LOW
40, //5 HIGH
40, //6 LOW
26 //7 HIGH
};
if (ISO_InitStep == 0)
{
// setup
ECUconnection = false;
serial_tx_off(); //disable UART so we can "bit-Bang" the slow init.
serial_rx_off();
initTime = currentTime + initFirstDelay;
initFirstDelay = (initFirstDelay % 4500) * 2; //if 4800 then down to 300ms AND sequence: 300, 600, 1200, 2400, 4800
ISO_InitStep++;
}
else if (currentTime >= initTime)
{
if (ISO_InitStep > 0 && ISO_InitStep < 8)
{
digitalWrite(K_OUT, ISO_InitStep % 2);
#ifdef useL_Line
digitalWrite(L_OUT, ISO_InitStep % 2);
#endif
initTime = currentTime + ISOSteps[ISO_InitStep] * 10;
ISO_InitStep++;
}
else if (ISO_InitStep == 8)
{
#ifdef useL_Line
digitalWrite(L_OUT, LOW);
#endif
// bit banging done, now verify connection at 10400 baud
byte b = 0;
// switch now to 10400 bauds
Serial.begin(10400);
// wait for 0x55 from the ECU (up to 300ms)
//since our time out for reading is 125ms, we will try it up to three times
for (byte i=0; i<3; i++)
if (iso_read_byte(&b))
break;
if(b == 0x55)
{
ISO_InitStep++;
}
else
{
// oops unexpected data, try again
ISO_InitStep = 0;
}
}
else // ISO_InitStep == 9
{
byte b;
bool bread;
bread = iso_read_byte(&b); // read kw1
#ifdef DEBUGOutput
LastReceived1 = b;
LastReceived1OK = bread ? 1 : 0;
#endif
bread = iso_read_byte(&b); // read kw2
#ifdef DEBUGOutput
LastReceived2 = b;
LastReceived2OK = bread ? 1 : 0;
#endif
// 25ms delay needed before reply (url with spec is on forum page 56)
// it does not work without it on VW MK4
delay(25);
// send ~kw2 (invert of last keyword)
iso_write_byte(~b);
#ifdef DEBUGOutput
LastSend1 = ~b;
#endif
// ECU answer by 0xCC (~0x33)
// read several times, ECU not always responds in time
for (byte i=0; i<3; i++)
{
bread = iso_read_byte(&b);
if (bread)
break;
}
#ifdef DEBUGOutput
LastReceived3 = b;
LastReceived3OK = bread ? 1 : 0;
#endif
if (b == 0xCC)
{
ECUconnection = true;
// update for correct delta time in trip calculations.
old_time = millis();
}
ISO_InitStep = 0;
}
}
Сам проект лежит тут: http://opengauge.googlecode.com/svn/trunk/obduino32K/obduino32K.pde
Автор: AZM.SU 17.6.2011, 10:16
ByKA, за ссылку "Тыц" спасибо, особенно интересно что там пишут, что, при ините, что бы сцепиться с двигателем надо слать адрес 00h а на адрес 01h отвечает что-то другое (вот бы ешё правда знать что).
ISO9141 как я погляжу стандартная прям как по протоколу в PDF-ке которую я накопал и в посте #11 выложил, вот только у меня ECU эту процедуру полностью проигнорировал =(
А проснифферить трафик с COM порта обязано получиться, этот же софт я так понимаю встаёт прокладкой между виндовым API, функцией OpenFile(), значит скорость не важна, по идее, если оно так, то перехватит и первые 8 бит передаваемые на 5 бод.
Так или иначе попробовать стоит, снять в дамп процесс соединения и запрос/ответ любого параметра, например, того же напряжения батареи, которое вроде как запрос 14h.
---
Пока оставлю здесь ссылки на то, что ещё дали интернеты относительно MUT:
http://evoecu.logic.net/wiki/MUT_Requests
http://evoecu.logic.net/wiki/MUT_Commands
не знаю насколько актуальны эти запросы и команды, но наличие команд радует, особенно то что на форумах упоминают, что команда C0 глушит двигатель, а это самое оно для противоугонных функций =)
Команды DA ... DD тоже весёлые для противоугона =)
Автор: AZM.SU 18.6.2011, 4:14
CONNECT TO ECU
OK
Vbat: 12.02612
Другими словами соединение с ECU побеждено.
Для истории или для других желающих реализовать подобные проекты немного информации.
MUT-II INIT (соединение по MUT-II):
delay_ms(2000); // ждём отстоя пены
K line = 1 // старт инита
delay_ms(300);
K line = 0
delay_ms(200); // передаём "стартовый бит"
K line = 0
delay_ms(200*8); // якобы передаём байт 0x00 - это адрес ECU двигателя (не сочтите за быдлокодинг, это для примера, естественно можно эти 2 строки не писать, просто в предыдущей задержке вписать 200*9), для системы ABS адрес будет 0x04 и передавать надо его.
K line = 1
delay_ms(200); // передаём "стоповый бит"
// Переключаемся на 15625 бод, 8 Data, 1 Stop, No Parity
ждём прихода синхробайта, должен быть равен 0x55
если синхробайт не пришёл, то говорим "Ошибка, где ECU?" и далее не продолжаем
ждём прихода 0xEF
если не пришло, говорим "Ошибка, вы подсовываете нам не то ECU!" и далее не продолжаем
ждём прихода концовки ответа которая при любом ECU равна 0x85, будь то ABS или иное ECU.
Здесь и далее можем начинать слать запросы и получать ответы
При посылке запросов, не забываем, что байт, который мы передаём нам и возвращается, то есть пока мы его передаём мы его и принимаем, он как эхо.
Проверить, что присоединились верно можно отправив запрос 0x14 (показать напряжение аккумулятора) и если получим значение менее 0x33, то выдать "Ошибка ECU не отвечает на наши запросы".
MUT-II WORK (работа по протоколу MUT-II):
Дожидаемся конца отправки (или принятия байта)
Принимаем байт
Если принятый байт не равен байту, который отправляли, то сообщим "Ошибка, на K-линии неполадки!" и далее не продолжаем
Дожидаемся принятия байта
Принимаем байт (это ответ ECU на наш запрос)
Специально написал процедуры на русском, а не в кодах, что бы не путать людей, вдруг кто асм, си или васик не знает, что бы не мучались.
Едем далее.
Пару "ласковых":
Забудте как страшный сон сайт www.myrollingroad.com
Или специально врут или просто их EVO и Lancer IX совсем разные машины, что у EVO адрес ECU 0x01, но у Lancer IX он точно на адресе 0x00!
---
Так как соединение побеждено, перехожу к этапу #2 - считывание ошибок.
С сбросом ошибок понятно, есть команда 0xFC, с чтением пока не понял, кто может растолкуйте - есть команды, например:
0x40 - Stored Faults Lo
0x41 - Stored Faults Hi
Внимание вопрос!
хорошо, считали 2 байта, теперь как эти 2 байта превратить в ошибку вида:
P0110 (Датчик температуры воздуха на впуске)
или
P0720 (Электрическая цепь датчика частоты вращения выходного вала)
Ведь буквы бывают не только P но и B и C, да и 2 байта это 65536 комбинаций (кодов) а в виде "P0110", даже учитывая буквы, гораздо меньше.
Автор: SSh 18.6.2011, 6:29
Код ошибки имеет опред. структуру, которая определяется по позициям след. образом:
Первая позиция:
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 18.6.2011, 8:13
SSh, спасибо конечно, но это общие сведения и касаются они кодов ошибок в общем, вопрос же стоит так:
Как из двух байт (хай и лоу) возвращаемых ECU в ответ на запрос ошибок получить вид
P0110
т.е. как, например, число 0110 упаковано в указанные 2 байта?
Возможных вариантов множество, примеры:
1) http://ru.wikipedia.org/wiki/%C4%E2%EE%E8%F7%ED%EE-%E4%E5%F1%FF%F2%E8%F7%ED%FB%E9_%EA%EE%E4 - аккурат 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 18.6.2011, 10:33
AZM.SU, я нигде не смог найти конкретного алгоритма преобразования полученных байтов в код ошибки. Думаю, если все-таки ничего откопать не удасться, то придется искуственно вызвать ошибку (отключив например какой-нибуть датчик) считать код с ЭБУ и сопоставив с тем-же кодом из таблицы DTC понять что и как там происходит. Примерно таким способом я воспользовался когда надо было выяснить формат записи пробега в EEPROM.
Автор: AZM.SU 18.6.2011, 10:53
SSh, этот вариант я оставляю всё же на крайний случай.
И так, хожу к машине по 15 раз в день, да ещё и верчуть как уж подлазая к разъёму, что бы подоткнуть контакты в дырочки =)
---
Кстати, а как EvoScan и подобный софт работающий через опенпорт показывают ошибки - в каком виде, сколько позиций (я так понял, сохраняются 3 ошибки и 1 "текущая")?
Автор: SSh 18.6.2011, 11:04
Честно говоря - не знаю, в то время когда игрался с EvoScan-ом хотел тоже вызвать ошибку чтоб посмотреть, но так и не сделал этого. А сейчас абсолютно нет времени на подобные эксперименты
Автор: SSh 18.6.2011, 15:41
Вот еще что нашел относительно декодирования отклика ЭБУ
http://en.wikipedia.org/wiki/OBD-II_PIDs
Начиная с MODE3
ну и т.д...
Что я понял при беглом просмотре:
Код ошибки состоит из двух байтов, назовем их А и В.
Байт А раскладываем побитно и имеем:
А7 и А6 - первый символ кода ошибки,
-- -- -------------------
0 0 P - Powertrain
0 1 C - Chassis
1 0 B - Body
1 1 U - Network
А5 и А4 - второй символ,
-- -- --------------------
0 0 0
0 1 1
1 0 2
1 1 3
А3, А2, А1 и А0 - третий символ,
-- -- -- -- -------------------
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 21.6.2011, 6:01
Кто ни будь, растолкуйте, вот здесь 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" (обороты двигателя).
По намёку Главного, создал отдельную тему, где надеюсь, соберётся со временем полнейшая информация о каждом параметре:
http://forum.amadeus-project.com/index.php?showtopic=3958
Автор: zhuns 19.1.2012, 15:45
Может уже не актуально - сколько времени прошло. А вдруг, пригодится
Я параметры форсунки нашел так. Вначале узнал ее номер, как http://www.mitsubishi.constantaservice.net/index.php?id=12899&TYP_ID=17751&MOD_ID=5076&MOD_CDS=110005076
(На машине форсунка Bosh № 0 280 155 723). Зная его находим параметры форсунки http://boards.bmworg.ru/viewtopic.php?t=2108или лучше http://users.erols.com/srweiss/tableifc.htm
Узнал, что производительность форсунки равна 227 cc /min
Автор: BpyH 17.2.2012, 12:00
Всем доброго времени суток.
Наткнулся на интересную тему http://www.mikrocontroller.net/topic/176478 вроде как есть исходник, но я не вникал туда так как язык понимаю только на бейсике.
Автор: Gummi_bear 10.1.2015, 10:12
Если есть кто на лансере с движками отличными от 4g13 из Новосибирска, будут признателен если отпишитесь и найдёте время подъехать вечерком для просмотра что ответит их ECU на инит. Обещаю, всю машину до тла не сожгу, максимум несколько метров проводки =)
Мдас ... тема давняя, но чем черт не шутит :-)
У меня на столе лежит мозг от 4G18 и ардуина мега 2560 + L9637, инит на ней написать пока не получается :-(
Пробовал как вы в своем посте описывали по русски, а фиг! мож ардуина не умеет с нестандартными скоростями UART работать?
Тогда надо самому программно писать SoftwareSerial, т.к. из доступных библиотек пробывал, не работают, или под мегу328 затечены х.з. :-(
мож кто подскажет? стенд для экспериментов есть :-)
Автор: Gummi_bear 12.1.2015, 7:31
Согласно протокола 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 килобайт )
: 1408Код не мой, меня не пинать, я только подправил для своего железа: Arduino Mega 2560 + L9637D
Код стырил здесь: http://compcar.ru/forum/showthread.php?t=4992
На авторство не претендую, но т.к. с афтырем сего опуса связаться тот форум мне не дает (не заслужил еще), выкладываю тут.
Камменты в коде не мои, я только номера UART поправил.
Собственно как и ТС уперся в правильные PIDы, и работу с ними :-(
|
+7-978-708-85-73 Дроссель Amadeus Productions. Быстрый заказ по телефону. (Viber, WhatsApp, Telegram) |