В последнее время поступает много негатива по китайским адаптерам с версией 2.1.
Работают только с OBD2 протоколом и не всегда стабильно, любые KWP2000 протоколы - поддерживают криво и плохо, в большинстве случаев связь с ЭБУ не устанавливается.
CAN протоколы тоже могут вызывать ошибки переполнения буфера и спонтанные отключения.
Причина - удешевление производства в Китае, которое повлияло на качество. Китайские производители стали использовать более дешевый чип PIC который не совместим с исходной прошивкой (китайской же).
Продавцы уже поняли что люди не хотят покупать v2.1 и поэтому перемаркировали их и теперь эти адаптеры отзываются как версия 1.5.
Они не понимают некоторых команд для соединения с ЭБУ, а некоторые неправильно воспринимает:
SendCommand:ATAL HandleReply: ? - должно быть ОК -> EXTRAINIT SendCommand:ATIB10 HandleReply: ELM327 v2.1 - должно быть ОК -> EXTRAINIT SendCommand:ATSH8111F1 HandleReply: OK -> EXTRAINIT SendCommand:ATST32 HandleReply: OK -> EXTRAINIT SendCommand:ATSW00 HandleReply: ? - должно быть ОК
Если для подключения к вашему ЭБУ необходимо прописывать строку инициализации elm (использовать шаблон строки инициализации elm), а на команды (ATIB10, ATAL, ATSW00 … ) которые неправильно отрабатывает ELM приходят ответы знак вопроса (на ATIB10 должен быть ответ ОК, а не версия elm адаптера), то такой адаптер нестандартные протоколы (KWP2000) не поддерживает (ЭБУ: Январь, Микас, Делфи…Авто: ВАЗы, Chery Tiggo, Nissan, Toyota JDM…).
Связь вы не установите! И дело здесь не в программе хобдрайв!
Проверка ELM327: Самостоятельно проверить elm можно с помощью Хобдрайва: ~ в системных настройках изменить уровень системных логов с error на trace ~ в параметрах авто выбрать шаблон строки инициализации elm: VAZ Yanvar ~ подсоединиться к елм, результат ответов посмотреть в log.txt (находится в папке с программой) или такую же проверку можно сделать с помощью терминале (программы для elm, можно скачать бесплатно на google play) необходимо послать следующие команды:
ATAL
ATIB10
ATSH8110F1
ATSW00 посмотреть какой ответ отдает адаптер. Если на команды запроса приходят ответы ОК, то этот адаптер будет работать с нестандартными протоколами.
Если на команды запроса (хотя бы на некоторые из них) приходят ответы знак вопроса (на ATIB10 должен быть ответ ОК, а не версия elm адаптера), то такой адаптер нестандатртные протоколы (KWP2000) не поддерживает.
Также можно выделить группу mac-адресов, которые принадлежат “кривым” elm адаптерам:
~ версия 2.1 на ATAL-?:
~ версия 1.5, на ATAL-OK, но другие команды не воспринимает или воспринимает неправильно:
00:1D:A5:00:0C:E6
00:1D:A5:00:0C:F9
~ версия 2.1, на ATAL-OK, но другие команды не воспринимает или воспринимает неправильно
00:1D:A5:68:98:8A
00:1D:A5:68:98:8B
00:1D:A5:68:98:8C
00:1D:A5:68:98:8D
~ версия 1.5, на ATAL, ATIB10, ATST32 - ?
12:34:56:88:89:7C
12:34:56:88:93:E3
На рынке появились елм, которые в elm327identifier пишет ответ ОК, а на самом деле там немного по-другому и связь с авто по KWP2000 установить не удается
Вот такой лог имеем с elm327identifier: Имя устройства=OBDII Mac адрес устройства=00:1D:A5:68:98:8A Версия устройства (Заявленная)=ELM327 v1.5 ATIB10 1.0 OK
с хобдрайва: SendCommand:ATIB10 HandleReply: KBusBaud=10400 OK
Не должно быть в ответе KBusBaud=10400
Новая партия урезанных адаптеров на поддельном чипе pic. Связь устанавливается, но не все параметры отображаются:
Ответ с нормального адаптера (авто Samand с ЭБУ Siemens): [TRACE] 09.06.2017 8:09:31.353[OBD2Engine] SendCommand:2101 [TRACE] 09.06.2017 8:09:31.353[OBD2Engine] -> SENSOR_ACK [TRACE] 09.06.2017 8:09:31.676[OBD2Engine] HandleReply: 6101783D45AE897E17000417D90000712E00007A0000005803FF0058000000B0B0B0B000000000000000000000000000000000001F00B5E900003B6F1E050EFC68000000009A09006801EB03002C3F16000000
Вот с кривого (авто Samand с ЭБУ Siemens): [TRACE] 28.07.2017 17:39:25.289[OBD2Engine] SendCommand:2101 [TRACE] 28.07.2017 17:39:25.293[OBD2Engine] -> SENSOR_ACK [TRACE] 28.07.2017 17:39:25.649[OBD2Engine] HandleReply: 5361017A3D42B16D8F16003216DA0000992E00007D
Ответ на запрос 2101 должен начинаться с 6101, а тут начинается с 53. 53 - это длина ответа в hex (обычно она не пишется, если не задан параметр ATH1 - отображать хедер ответа). В десятичной системе измерения получается 83, что совпадает с ответом с хорошего адаптера (61 - первый байт, 01-второй, … 00-восемдесят третий). В плохом адаптере отображается только двадцать байт из 83.
Дополнение.
На данный момент все больше плохих адаптеров отвечают в терминале ОК.
Пока плохие адаптеры не знают команды
ATPPS.
Для проверки в терминале пошлите
ATZ
ATPPS
Ответы от них в терминале имеют примерно такой вид:
Write: ATZ Read: ATZ
ELM327 v1.5
Write: ATPPS Read: ATPPS 00:FF F 01:FF F 02:FF F 03:32 F 04:01 F 05:FF F 06:F1 F 07:09 F 08:FF F 09:00 F 0A:0A F 0B:FF F 0C:68 F 0D:0D F 0E:9A F 0F:FF F 10:0D F 11:00 F 12:FF F 13:32 F 14:FF F 15:0A F 16:FF F 17:92 F 18:00 F 19:28 F 1A:FF F 1B:FF F 1C:FF F 1D:FF F 1E:FF F 1F:FF F 20:FF F 21:FF F 22:FF F 23:FF F 24:00 F 25:00 F 26:00 F 27:FF F 28:FF F 29:FF F 2A:38 F 2B:02 F 2C:E0 F 2D:04 F 2E:80 F 2F:0A F
Если на ATPPS будет ответ знак вопроса, то адаптер имеет урезанный функционал.