MOTO+4 Applocations のブログ

HowTo 備忘 アイデア 活動などを書いてます

2000年以前用FIATダイアグツールを日本語化+αを試す2

投稿日:

前回は同ダイアグツールの基本接続と実車疎通接続を行いました。しかし連続モニタリングと再接続性に課題があり、調査します。

通信仕様書

まず通信仕様を理解する必要があります。通常はサプライヤ以外には非公開ですが検索するとpdfが見つかります。No.07223 と No. 3.00608 のFIAT公式資料がでてきます。No. 3.00608 の方が具体的内容のようです。No.07223は2000年以降の仕様のようであまり参考にならないです。公式か不明の”IAW 16F Technical Information”という資料に100%の内容が記載されているようです。

  • ECU接続時にSeedkey等はない。
  • 実際の通信ではチェックサムは無い。
  • ダイアグツール 接続時 1200bps、データ通信時7,812bps (コード内はクロック分周の都合か7,680bps)となっており一般と異なる。
  • 接続後は、ECUへのリクエストは1Byte。
  • 初期接続時に、110msec±10% という順守するにはPCだけでは厳しい条件あり。
  • 切断コマンドは見当たらず。

通信自体は、ダイアグツールは大体あっている感じです。

通信ケーブルの配線

車両側ダイアグコネクタには、L_LINE が来ていたので配線を確認しました。K-LINEと合成されているだけようです。

ダイアグツールアプリの構造

組込み機器と通信するWindowsアプリを作る場合、以下の課題があります。

  • msec単位の処理に対して、正確にリクエスト/応答できない。0.1秒が限度。
  • 画面操作なと介入により通信は遅延する。
  • .NETは、C++&Win32APIより数倍遅い。

当アプリは配慮はされていますが万全とは言えないようです。ここは様子見ですね。

  • ECU通信部は別スレッド化されている。(これはOK)
  • 通信リトライが無い。(UARTではハード層はリトライしないので実施が常識)
  • 不正確な Thread.Sleep を多用している。
  • 通信は1byte単位で実施している。(length指定より遅れが出やすい、.NETならなおさら)
  • エコーバックの一致チェックはしていない。(一線式のKLINEおよびLINではエコーバックが不一致だとBUS競合したと判断できる)
  • 必須かは不明だが、使用者に切断操作時に、ECUへ切断コマンドは送信していない。

解析機能の追加

まずECUとの通信内容をリアルタイム表示する機能が必要です。専用のアナライザ装置がベストですが、通信コンソール画面を追加します。これは別スレッドでメイン画面スレッドとPostMessageさせる取りするので処理遅延は最小です。以下アプリが受信待機していて、IG-ONしたとき、ECUから型番等が送られるのがわかります。

以下は、ダイアグツール側がECU型番を覚えているときのシーケンスで、失敗したときです。

見解としては、ECUとツールのどちらかが遅れているか、タイムアウト時間が適正でないといえそうです。ECUへのリクエストのタイミングか、ツール側の取りこぼしが疑わしいそうです。微妙なBaudrateも確かWindowsでは作りだせなかった記憶があります。FTDIでは作り出せるかもしれません。もろもろクロック周期の影響を受け7,812bpsジャストにはできないはずです。

その他変更

モニタログのパスは変更できるようにしました。

その他、昔の勢いで使いにくい部分はどんどん直してしまいました。

  • 接続時の通信リクエストにリトライ3回を追加。
  • ウインドウサイズやグラフ幅を覚えうるように処理を追加。
  • try – catch もれも一か所あり、そこに行着くと落ちるので修正。
  • メッセージ表示中にメイン画面の操作無効されているが、× ボタンも押せないのでそこは操作できるように修正。
  • USBケーブル抜き取り時に、DISCONNECTを実行。
  • USBケーブル挿入時にCOMを自動オープンする。
  • tooptipが表示されなくなる事象を修正。
  • グラフ画面で、項目名とグラフの比率をスライダで変更できるようにした。

リポジトリ本流に戻しにくくなってしまいました。

2000年以前用FIATダイアグツールを日本語化+αを試す1

投稿日:

GWお休みいただいていますが個人的には自動車整備を遂行しないといけません。弊方の’93型FIATがシリンダーヘッドをOHした後、アイドリング途中でエンジンが停止する事象が発生し続けています。

’80年以降のFI車なら通常ISC:Idle Speed Contorl によりアイドリング回転数はECUにより制御されています。ソレノイド(デューティ信号制御)とステッパーモータ制御(モータ専用信号制御)の2種類があり、後者の方が応答性が早いが制御が複雑になりハード面もコストUPになります。当FIATは後者です。

ここはダイアグ (故障診断もしくはスキャン)ツールで状態を確認したいところです。しかし他メーカにも同じく、FIATの2000年以前は通信プロトコルが車両メーカ固有で市販品は使えません。メーカ専用はディーラ以外では持っていないし、購入ルートがありません。

C#でのこの種のアプリ学習もかねて、オープンソースWindowsアプリのIAW_SCAN2:ダイアグ ツールを準備しました。機能を理解するため、当Project貢献のため日本語化をしました。これまでの記事は以下です。

その後、2024.1月の実車で試し、再開できていませんでした。まずその時の結果を整理します。

通信ケーブルの用意

PC側は市販のFT232R搭載のUSB→K-LINEケーブル を使います。UART( 全二重2線式5V非同期クロックシリアル通信 )をK-LINE( 半二重1線式ISO9141/BATT電圧の非同期クロックシリアル通信 )に変換するものです。K-LINE は変換には専用ICを使いますが電気的に電圧レベルを変換してUART送受信ラインを接続しているだけでロジックは載ってません。 K-LINE はBUS型でL-LINEという信号ラインもありますが平たいところ無視してもよいです。

USB→K-LINEケーブルの仮想COMは、デフォルトで1回の送信で16msecディレイがあるので最小にしておきます。これはPC側は細かい通信インターバルを刻めないため、ここで調整できるようにしてあるのだと思います。

ODBII→FIAT用コネクタ は何故かアマゾンで売っていました。そのままでは使えませんでした。2点加工が必要です。

  • PINの幅が実写より幅太でした。削って細くする。
  • OBDII側コネクタが、KLINE変換側よりRが大きいので、削って小さくする。

実車との接続

エンジンルーム内の以下のダイアグコネクタと接続します。

一般的にダイアグコネクタよりBATTが来ているですが当FIATは来ないようです。ODBII→FIAT用コネクタ のワニ口をバッテリとボディアースに接続します。

初回接続

割とすんなりECUと接続でき、ECU機種を認識しました。ECU機種は自動判別です。

ケーブル接触が微妙なのか通信が断線時は以下のようになります。

ケーブル接触不良を物理的に見るため、ケーブル内に接続中LEDを追加します。出力はFT232Rのオプションポートを使います。

LEDを観察しつつ電気的に接続している最中でもよく接続が切れます。一度切れると次に接続しにくくなり、下図のように約20secでタイムアウトします。ECU機種は自動判別をしない方が調子いいようです。

アイドルスロットル開度の確認

アイドル維持できない場合、アイドル時のスロットル開度が怪しいです。基本ECUが学習するのですが規定値を外れすぎていると学習しません。アイドル時スロットル開度の規定値が何Voltかは、メーカ整備書にも、ヘインズのマニュアルにも未記載で、ダイアグツールを使うようにとしが記載がないです。

スロットル開度は確認できました。このままではまずそうです。しかし一瞬モニタはできるのですがすぐ切れ、その後再接続できません。モニタしながな調整ができないですね。一晩待つと接続できる傾向がみられます。アプリの問題か、ECUが接続解除命令を受けとれておらず、新しい接続を拒否しているのかも、、、

故障表示

一瞬見えた故障表示ですが、FAILが立っていました。

一応、FAILをクリアしました。

メンテナンス機能

実施しなければならない機能項目がないかみてみました。本ツールは、アクティブテストと市場調整機能までサポートしているようです。なかなかです。なおこれらの項目は車両毎に変わってきます。

以上、割と使えそうですが、連続モニタリングと再接続性に課題があります。次記事では、それを解析していきます。しかしこの種のアプリを開発していた時期もあり懐かしいです。

Microsoft Office 2024 のinstall覚書

投稿日:

近年用MS-Officeは、弊方の規模ではボリュームライセンス適用できないので一般向けを使用しています。入れ替えの機会があり、割と困惑したのでその覚書です。

購入

Microsoft Office 2024 Homeを価格はどこでも変わらないので、MS Store より購入しました。Amazonの販売元Amazonのコードのみのアイテムは3,000くらい安かったですがちょっと怖いのでやめときました。(前職場にてExecl単品をAmazon公式から数回購入して問題はなかったですが…)

MS Storeでも、法人カード決済で即購入できます。

ダウンロード

ダウンロードに行着くまでかなりかかります。ダマされたのかと疑心してしまいます。

インストール

手順は以下のとおりです。「Office365」と表記が出るので間違って購入したかと焦ります。

初回起動

アンインストールした Office2021 が一瞬見え、インストール出来ていないと疑いますが、起動しきるとOffice2024になります。

ところで2024で何か良くなったか?

Execl だけ見てみましたが特に変わってない印象です。弊方としては、操作性に関してはOffice2003から退化しっぱなしです。

Windows11 24H2にUPDATEできなくなった件2

投稿日:

前記事ではFUJITSU Q556/R でWindows11にて新エディションにupdateができなくなり、その原因を報告しました。 Win11対応のCPUが搭載できるQ558とのそれができないQ556を購入間違えていたのが根本原因でした。

Q558の入手

運よくQ558/VのCPU/ストレージ無しのドンガラを安価に入手できました。再セットアップ工数と購入費のトレードオフ面では疑問ですが、業務上の買い物失敗は取返したいところです。双方の基板を比較してみます。

Q558ではRS232Cがオプションになったみたいです。今回は残念ながらRS232C無でした。

確認用部品の入手

Q558/Vドンガラは動作不明のため、まず確認用に比較的安価なCPU: core i3 8100T を入手します。

Q558/Vドンガラには、PC4-2666 4GB が差さっててました。本機は core i5 8700Tモデルだった模様です。CPUと通信速度が合うQ556/Rで使っていたPC4-2400 に差替えます。

OSアップデート

Q556/Rで使っていたストレージを差し電源ON。OSライセンス的にはQ556/Rに元々もあるので問題ないハズです。CPUと基板が変わったので少し時間がかかりますが起動しました。

そこからWindows Updateでは24H2のアップデート項目は表示されなかったため、USBメディアでインストールを開始。当然ですがCPUチェックは通過します。

下記のとおりWindows11 24H2 にアップデートできました。

アプリ動作確認

一応マシンとしては別になったので、アプリの動作確認をします。

MS Office 2003はライセンス承認も求めてきます。承認は通過(未だできますね) こちらはパッケージライセンスなので問題無しです。

Q556/Rに入っていたMS Office 2021はプレインストールライセンスの模様で更新はできず。再購入が必要です。 MS-Office 2024パッケージ版を新規購入です。

永続ライセンスで購入できるPDFエディタ:wondershare PDFelement は再ログインでOK。ライセンス変換的な行為は不要でした。これが使えなかったら納入や見積書作成ができずタイヘンでした。

以上、これで正しく Windows11 24H2 にアップデートでき、多分この先も心配しなくていいでしょう。

Bluetooth5の2Mbps通信を明示的に指定する

投稿日:

nRF Sniffer for Bluetooth LE のセットアップにて、Android端末とnRF52840との間で、Bluetooth5の2Mbpsのフレームが見受けられませんでした。一つの原因は端末仕様でした(詳細はこちら)

上位プロトコルへの自動切換えは何となく怪しい、1Mbps か 2Mbps どちらの状態か把握管理したい。そこで2Mbps( BT用語ではPHY_2Mというようです) 弊方では以下のようにしました。

スレーブAndroid側

STATE_CONNECTEDイベント検出後、setPreferredPhy() をcallし、nRF52840 へ 2Mbps を明示的に要請します。

  private final BluetoothGattCallback mGattcallback = new BluetoothGattCallback() {
        // 接続状態変更
        @Override
        public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
           switch  (newState ) {
             case BluetoothProfile.STATE_CONNECTED :    // 接続完了
                if ( /* 端末で2Mbpsがサポート済みか?*/ ) {
                     /* 2MBpsを設定 */
                     gatt.setPreferredPhy(
                         BluetoothDevice.PHY_LE_2M_MASK,
                         BluetoothDevice.PHY_LE_2M_MASK,
                         0
                     );
                 }
              }
                ・・・後 略・・・

これで nRF52840 側の BLE_GAP_EVT_PHY_UPDATE_REQUEST イベントを用意してあれば、速度設定が反映されます。なお大前提として端末が 2Mbps サポートしているかの事前CHECKが必要です。

マスタnRF52840Android側

試したところAndroid側の接続完了が先に到達するようですが、到達順は処理負荷等でずれることも考えられます。nRF52840 側にも仕込んでおきます。こちらは2Mbps サポート有なので無条件に設定します。

static void ble_evt_handler(
	ble_evt_t const * p_ble_evt,	// [in] Bluetooth stack event.
	void 			* p_context		// [in] ハンドラ引数(任意)
) {
    uint32_t err_code;

    switch( p_ble_evt->header.evt_id )
    {
	  // 通常接続。	Connected to peer.
      case BLE_GAP_EVT_CONNECTED:
        /* 2MBpsを設定 */
        ble_gap_phys_t const phys =  {
     	     .rx_phys = BLE_GAP_PHY_2MBPS,
     	     .tx_phys = BLE_GAP_PHY_2MBPS,
   	    };
       	err_code = sd_ble_gap_phy_update(/*in*/ p_ble_evt->evt.gap_evt.conn_handle,
	 								 /*in*/ &phys );
       	APP_ERROR_CHECK( err_code,902 );

        break;

念のためアドバタイズ用の初期値も変更しておきました。

    ・・・前 略・・・
    init.config.ble_adv_secondary_phy = BLE_GAP_PHY_2MBPS | BLE_GAP_PHY_1MBPS ;
    // 1Mと2Mを orするようにとどっかに書いてあった。2MBPSだけだと論理エラーが発生。
    init.config.ble_adv_primary_phy   = BLE_GAP_PHY_2MBPS | BLE_GAP_PHY_1MBPS ;
    init.evt_handler = on_adv_evt;	// EVENTハンドラ関数

 	  // -BLEアドバタイズ初期化 -
    err_code = ble_advertising_init( /*out*/&m_advertising, /*in*/&init );
    APP_ERROR_CHECK( err_code,1501 );

Android側も BluetoothGattCallback の onPhyUpdate をオーバライドして、Logcatを仕込んで動きを確認できるようにするとベターです。

実行結果

更新要求のアナライズ結果です。

更新応答のアナライズ結果です。

肝心の転送レートは、あまり変わりません。

PACKET送信部のアナライズ結果は以下の通りでした。まだ課題がありますね。

しかしながらデットタイムの見られないパターンも一部みられました。L2CAP(分割送信)が効き、251byte が 220byte と 41byte に分割されたときでした。デットタイムはいずれにしても課題ですが、もしかしてNordic UART上ではpacket分割しないのが正しいのかもしれません。