Для разработчиков

Спецификация и описание функций J2534 ›
Спецификация и описание команд ELM327 ›

Интерфейс ELM327 доступен в адаптере Nano ET. Остальные адаптеры ScanDoc используют протокол J2534 PassThru.

Новости для разработчиков

Изменения в J2534 DLL, ELM327 и прошивках адаптеров ScanDoc, которые касаются интеграции: новые функции, протоколы и параметры — с примерами использования.

---

DLL 2.0.0.200, прошивка Nano ET сборка 83 04.08.2026

Скачать библиотеки J2534 2.0.0.200 — Windows x86/x64/ARM64 (отдельные сборки для Windows 7), macOS (universal), Linux (x64, x86, ARM, ARM64), Android (arm64-v8a, armeabi-v7a, x86, x86_64), iOS.

Прошивка Nano ET — сборка 83

Новое

• DoIP (ISO 13400) и BMW HSFZ — новые протоколы ISO13400_PS (0x8FFD) и HSFZ_PS (0x8FFC). В стандарт SAE J2534 они не входят — это собственное расширение ScanDoc: диагностика по Ethernet — обнаружение автомобилей в сети (VIN, логический адрес), TCP-подключение, routing activation, обмен UDS. Тестерный адрес по умолчанию 0 — задайте ISO13400_SOURCE_ADDR до активации маршрутизации, иначе шлюз ответит отказом; адрес ЭБУ передаётся в каждом сообщении ([TA][SA][UDS]), ISO13400_TARGET_ADDR через Set/GetConfig не задаётся. Отправка сериализуется по P2: один незакрытый UDS-запрос за раз, NRC 7F xx 78 продлевает ожидание до P2*max (6 с). Новый параметр канала ISO13400_P3_DOIP (0x8108) — пауза между сообщениями.
  Пример

  uint32_t ch, code = 0;
  pt_config_t sa  = { ISO13400_SOURCE_ADDR, 0x0E80 };
  pt_config_list_t cfg = { 1, &sa };
  
  PassThruConnect(dev, ISO13400_PS, 0, 0, &ch);
  PassThruIoctl(ch, SET_CONFIG, &cfg, NULL);                 /* SA — до routing activation */
  PassThruIoctl(ch, ISO13400_DISCOVER_VEHICLES, NULL, NULL); /* IP ЭБУ запомнится сам */
  PassThruIoctl(ch, ISO13400_CONNECT_TCP, NULL, NULL);
  PassThruIoctl(ch, ISO13400_ACTIVATE_ROUTING, NULL, &code); /* 0x10 = success */
  /* дальше PassThruWriteMsgs / PassThruReadMsgs — обычный UDS */

• Диагностика шины — bus-off (обрыв/КЗ проводки, нет ACK) и неверная скорость CAN возвращают информативный текст ошибки с указанием baud rate вместо общего кода отказа.
• Один TCP-порт для J2534 и ELM327 — отдельный порт 35000 для ELM327 удалён, оба протокола обслуживаются на командном порту 53983. Протокол определяется по первому байту соединения: 0x55 (маркер кадра J2534) — J2534, любой другой (текстовая AT-команда) — ELM327.
• BLE — ротируемый MAC-адрес (RPA): сканеры видят случайный адрес, спаренные устройства резолвят его по IRK; принимаются только соединения Secure Connections.

Исправлено

• CAN-фильтры по байтам данных — PassThruStartMsgFilter сравнивал только 4 байта CAN ID, игнорируя заданную длину фильтра. Теперь кадр сравнивается на всю длину, как требует стандарт: PASS/BLOCK по содержимому кадра работают.
  Пример

  /* Подавить ответы TesterPresent (07E8 02 7E ...) в приёмной очереди */
  pt_msg_t mask = {0}, pattern = {0};
  mask.protocol_id = pattern.protocol_id = CAN;
  mask.data_size   = pattern.data_size   = 6;   /* 4 байта CAN ID + 2 байта данных */
  memcpy(mask.data,    "\xFF\xFF\xFF\xFF\xFF\xFF", 6);
  memcpy(pattern.data, "\x00\x00\x07\xE8\x02\x7E", 6);
  uint32_t fid;
  PassThruStartMsgFilter(ch, BLOCK_FILTER, &mask, &pattern, NULL, &fid);

• J2534 — каждый принятый кадр получает индивидуальную метку времени в момент приёма, как требует спецификация (раньше — общую на пачку); эхо переданного CAN-кадра выдаётся только при успешной отправке — эхо при ошибке TX вводило хост в заблуждение о состоянии шины.
• ELM327 — команда AT SH при активном CAN-канале ломала Flow Control (FC уходил без паддинга, DLC=3 — шлюз не слал Consecutive Frames) и затирала приёмный фильтр своим TX ID (приём ответов без AT CRA ломался). По даташиту AT SH задаёт только заголовок передачи — приёмный фильтр теперь управляют только AT CRA/CF/CM.
• BLE-спаривание с Android 14+ (Pixel) — срывалось, когда системный Fast Pair / Find My Device запускал спаривание параллельно с прибором.
• K-Line/KWP — терялся последний байт ответа при плотном обмене; ACK-блок уходил на ~70 мс позже и рвал идентификацию; канал залипал после неудачного подключения.
• PassThruStopPeriodicMsg мог отправить лишний кадр после остановки.
• TP2.0/TP1.6 _PS — выбор пинов через SET_CONFIG(J1962_PINS) не применялся, кадры не уходили на шину.
• Устойчивость к некорректным данным — валидация малформед-кадров (ISO15765 First/Single Frame, длина DoIP-пакета, сборка TP2.0/TP1.6) и параметров хоста (ReadMsgs, IOCTL): вместо зависания или порчи памяти прибор возвращает штатные коды ошибок J2534.

Библиотеки J2534 — 2.0.0.200

Исправлено

• Таймаут контрольных команд по WLAN/LAN поднят до 1000 мс — на медленных или загруженных сетях управляющие команды прибору отваливались по таймауту.

---