開発者向け

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 — routing activation の前に ISO13400_SOURCE_ADDR を設定してください。設定しないとゲートウェイが拒否します。ECU アドレスは各メッセージで渡されます（[TA][SA][UDS]）。ISO13400_TARGET_ADDR は Set/GetConfig では設定しません。送信は P2 で直列化されます：未完了の UDS 要求は同時に 1 つ、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); /* ECU の IP は自動的に記憶される */
  PassThruIoctl(ch, ISO13400_CONNECT_TCP, NULL, NULL);
  PassThruIoctl(ch, ISO13400_ACTIVATE_ROUTING, NULL, &code); /* 0x10 = 成功 */
  /* 以降は PassThruWriteMsgs / PassThruReadMsgs — 通常の UDS */

• バス障害診断 — bus-off（配線断/短絡、ACK なし）と CAN ボーレート誤りは、汎用の失敗コードではなく baud rate を含む詳細なエラーテキストを返すようになりました。
• J2534 と ELM327 で単一の TCP ポート — ELM327 専用ポート 35000 は廃止され、両プロトコルはコマンドポート 53983 で提供されます。プロトコルは接続の最初の 1 バイトで判定されます：0x55（J2534 フレームマーカー）— J2534、それ以外（テキスト AT コマンド）— ELM327。
• BLE — ローテーションする MAC アドレス（RPA）：スキャナーにはランダムアドレスが見え、ペアリング済みデバイスは IRK で解決します。Secure Connections の接続のみ受け付けます。

修正

• データバイトによる CAN フィルター — PassThruStartMsgFilter は CAN ID の 4 バイトのみを比較し、指定されたフィルター長を無視していました。標準の要求どおり全長で比較するようになり、フレーム内容による 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;   /* CAN ID 4 バイト + データ 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 — アクティブな CAN チャネルでの AT SH コマンドが Flow Control を壊し（FC がパディングなし DLC=3 で送信され、ゲートウェイが Consecutive Frames を送らない）、受信フィルターを自身の TX ID で上書きしていました（AT CRA なしの受信が壊れる）。データシートどおり AT SH は送信ヘッダーのみを設定し、受信フィルターは AT CRA/CF/CM のみで制御されます。
• Android 14+（Pixel）との BLE ペアリング — システムの Fast Pair / Find My Device がデバイスと並行してペアリングを開始すると失敗していました。
• K-Line/KWP — 密な通信で応答の最後の 1 バイトが失われる。ACK ブロックが約 70 ミリ秒遅れて送信され識別が中断する。接続失敗後にチャネルが固まる。
• PassThruStopPeriodicMsg が停止後に余分なフレームを 1 つ送ることがありました。
• 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 ミリ秒に延長 — 低速または混雑したネットワークでデバイスへの制御コマンドがタイムアウトしていました。

---