Logitech G400 のデータパスを解析してみる

--------------------------------------------
2015/05/31 初出
2015/06/04 rafa様の関連記事を追記
--------------------------------------------
rafa様の記事(-rafalog: 鼠とオシロ)に便乗する形でLogitechの名機であるG400のデータパスをマイコンを使って覗いてみました．

ハードウェア (Hardware)

ハードはこんな感じに，ポリウレタン線でMISO，MOSI，SCLK，SSをセンサのピンから引き出します．

基盤が載っている筺体が違うことに気がついた方は相当の鼠ソムリエですが，コイツです．筺体のデザインに関しては，今まで触った100種以上(店頭で触ったものも含む)のマウスの中で最も良いです．
「ワクワクしながら家に持ち帰ったら，センサー性能と実装に絶望した」という悲しい過去があります．事務用マウスも一応ウォッチしていると良いことがあったりなかったりですね．

極めて良い筺体形状なので，一年ほど前にG400の基盤を無理やり載せました．その作業内容や顛末とかも記事にすると面白そうですが，「ひたすら筺体と基盤を弄って物理的・電気的整合性をとるだけ」という単純作業なので割愛します．基盤にメモが書いてあるのはその時の名残です．

マイコンはいつもの CY8CKIT-042 PSoC® 4 Pioneer Kitを使用します．このキットは色々な所で売っています．(秋月)

ソフトウェアの実装(Software implementation)

IDEは，PSoC Creator  3.0 SP2 (3.0.0.3140)を使用します．コードは全世界に公開できるクオリティに達していないので，「見たい」という奇特な方はご連絡を・・・ということで．
データのキャプチャにはSPI Slave コンポーネントを使用します．このコンポーネントはMaster(MCU)にぶら下がってSlaveとして振る舞います．MCUと本当のSlaveであるセンサ間でのみ通信が行われるので，全バイトデータをキャプチャすればMCUとセンサのやりとりを(理論上は)キャプチャできます．

図のように，2入力(マウス側のMOSI，MISO)をORゲートのコンポーネントで論理和にし，SPI SlaveのMOSIに入力します．SCLKとSSはマウスから引っ張ってきたものをそのまま使用します．このコンポーネントからマウスへのデータ転送は行わない(というよりMasterはG400の基板上のMCUなのでデータを送ると何が起きるか分からない)ので，NC(No Connect)とします．

SPI Slaveの設定はこんな感じにします．

ADNSシリーズはCPHA=1，CPCL=1なのでそのように設定します．ビットレートは1.5Mbpsとします．
もし違うマウスで調べる場合は，対象マウスのMCUからでているSCLKのビットレート調べて，それと同じ値にする必要があります．他の項目はDefaultで問題ありません．

プログラム

プログラムは，MCUかセンサからデータが来たら保存するという事を2000byte分行うだけです．

データレートも見たいので，2000byte分の取得の開始時間と終了時間もTimerを使用してマイクロ秒単位で記録しておきます．
2000/取得にかかった時間 でデータレートを算出できます．

データ (Data Result)

データは本来は2000バイト取得していますが似たようなデータは割愛しています．
もし，特定の条件でのデータが見たいという奇特な方がいらっしゃればコメントして下さい．

データレート(Data Rate)

以下がデータレートの測定結果です．

Stream Read Info ->
Size    :       2000
Start   :       5814 us
End     :       17684 us
Time    :       11870 us ( 12 ms )

Data Rate : 168 Byte/ms

このように，約12msの間に2000Byteをやりとりしていることが分かります．つまり，1msあたり168Byte程度になります．MotionBurstはMCUがセンサに1Byte分の命令を送り，7Byte分のデータを受け取るので，1通信に8Byteのやりとりが発生します．(詳しくはデータシートのMotion Readの項を参照)
これらを勘案すると，MCUはセンサーへ1msの間に複数回アクセスしている可能性が高いと言えます．168/8=21なので，大体20回変位データを取得してるんじゃないの？と考えられます．とりあえず生データを見てみましょう．

2015/06/04追記
rafa様がオシロスコープでRazer Abyssusの解析をしてくださいました．
-rafalog: 初代AbyssusのSPI通信解析
これを見ると，AbyssusはMotion→Delta_X→Delta_Yレジスタの転送をしたところで，NCS(SS)をプルアップして強制的に転送を止めています．確かに，これだと変位のスループットが稼げます．記事によると，Abyssusは1msで6回程度アクセスしているようです．
データシートには「転送後にNCSをHIGHにする必要がある」，とは書いてありましたが「転送中にNCSをHIGHにすれば転送を中断できる」ことには気づきませんでした．ゲーミングデバイスは奥が深いですね．

生データ(Raw Data)

以下から生データになります．前半はマウスが静止している時のもので，後半はマウスを動かしている時のものです．静止時はMOSIのみとMISOのみのものも取りました．

移動中に0x80になっている部分は，Motionレジスタなので7bitが1になっているはずなので，本当は0xf0になります．つまり，データのキャプチャが1Clock分遅れており，データが微妙にずれているという結果になります．もう少しちゃんと書く必要がありますね．

MOSI&MISO (No Motion)

55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f
55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f
55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f
55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f

MOSI (No Motion)

55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00
55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00
55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00
55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00

MISO+Data Offset (No Motion)

※MOSIのデータで1列目のバイトを決めているので，MISOのみのデータは行がずれています．
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00

Low Speed (MOSI&MISO)

-----Stream-----
55 50 80 00 fa bd 00 50 80 ff fd 0a 01 1f 55 50 80 00 fd 50 80 00 fb 3d c3 0a 01 1f
55 50 80 00 fc bd 00 50 80 00 fb 0a 01 1f 55 50 80 ff fd 50 80 00 fa 3d cb 0a 01 1f
55 50 80 00 fe bd 00 50 80 00 fa 0a 01 1f 55 50 80 00 fb 50 80 00 fb 3d c3 0a 01 1f
55 50 80 00 fe bd 00 50 80 00 f9 0a 01 1f 55 50 80 00 fc 50 80 00 fb 3d c3 0a 01 1f
55 50 80 00 fd bd 00 50 80 00 fd 0a 01 1f 55 50 80 00 fb 50 80 02 fa 3d c3 0a 01 1f
55 50 80 01 fd bd 00 50 80 00 fc 0a 01 1f 55 50 80 01 fb 50 80 01 fc 3d c3 0a 01 1f
55 50 80 01 f9 bd 00 50 80 01 fc 0a 01 1f 55 50 80 00 fb 50 80 00 fc 3d cb 0a 01 1f
55 50 80 02 fa bd 00 50 80 00 fb 0a 01 1f 55 50 80 02 fc 50 80 01 fb 3d c7 0a 01 1f
55 50 80 02 fb bd 00 50 80 00 fb 0a 01 1f 55 50 80 02 fb 50 80 01 fb 3d c3 0a 01 1f
55 50 80 00 fb bd 00 50 80 03 fa 0a 01 1f 55 50 80 01 fc 50 80 01 fb 3d c3 0a 01 1f
55 50 80 03 fa bd 00 50 80 01 fc 0a 01 1f 55 50 80 01 fb 50 80 00 fc 3d c7 0a 01 1f
55 50 80 03 fa bd 00 50 80 01 fa 0a 01 1f 55 50 80 02 fa 50 80 02 fd 3d cb 0a 01 1f
55 50 80 01 fa bd 00 50 80 03 fb 0a 01 1f 55 50 80 01 fa 50 80 03 fa 3d c3 0a 01 1f
...
-----Stream END-----

Middle Speed (MOSI&MISO)

-----Stream-----
55 50 80 06 1c bd 00 50 80 06 1c 0a 01 1f 55 50 80 07 24 50 80 04 1e 3d c7 0a 01 1f
55 50 80 05 1b bd 00 50 80 04 1d 0a 01 1f 55 50 80 04 1d 50 80 05 26 3d cf 0a 01 1f
55 50 80 02 1e bd 00 50 80 00 1e 0a 01 1f 55 50 80 fe 1c 50 80 04 26 3d c7 0a 01 1f
55 50 80 02 1d bd 00 50 80 00 1f 0a 01 1f 55 50 80 00 1e 50 80 00 1d 3d c7 0a 01 1f
55 50 80 00 28 bd 00 50 80 00 1d 0a 01 1f 55 50 80 ff 1e 50 80 00 1d 3d c7 0a 01 1f
55 50 80 00 29 bd 00 50 80 01 1d 0a 01 1f 55 50 80 fe 1c 50 80 00 1e 3d c7 0a 01 1f
55 50 80 fc 28 bd 00 50 80 01 1f 0a 01 1f 55 50 80 ff 1c 50 80 ff 1c 3d cf 0a 01 1f
55 50 80 fc 1f bd 00 50 80 01 1d 0a 01 1f 55 50 80 fe 1c 50 80 fb 1e 3d c7 0a 01 1f
55 50 80 fc 1e bd 00 50 80 fc 1d 0a 01 1f 55 50 80 fa 27 50 80 fc 1e 3d c7 0a 01 1f
55 50 80 fb 1c bd 00 50 80 fb 1e 0a 01 1f 55 50 80 f8 26 50 80 fa 1d 3d c7 0a 01 1f
55 50 80 fa 1e bd 00 50 80 fa 1d 0a 01 1f 55 50 80 f9 1a 50 80 f7 27 3d c7 0a 01 1f
55 50 80 f9 1c bd 00 50 80 f7 1c 0a 01 1f 55 50 80 f9 1c 50 80 f8 1c 3d cf 0a 01 1f
55 50 80 f4 23 bd 00 50 80 f8 1c 0a 01 1f 55 50 80 f9 1a 50 80 f7 1b 3d c7 0a 01 1f
...
-----Stream END-----

まとめ 

ここからわかったことをまとめます．

• G400はMotionBurstを使用している
• 1msの間にセンサから複数回(おそらく10回以上)変位を読んでいる

複数回アクセスは予想通りですね．(G300でもやっていました)
AnkerのマウスもMotionBurstを使っていましたし，ゲーミングマウスでのデータ取得はMotionBurstが基本なのかもしれません．

キャプチャを正確にしてデータが取れたら，さらに分かることが多そうです．なにか分かったら，また記事にしたいと思います．

最近の私的デバイス事情とか進捗とか

リアルの方の進捗メイキングのほうが中々どうして・・・という感じで記事になりそうな進捗はないです．今回はゲーミングデバイスの雑談というか日記的なものになります．

進捗など

ゴールデンウィークと5月一杯を使ってAim調整ソフトウェアに仕立てることは出来たのですが，使用しているライブラリのLicenseなどの諸事情がありアプリケーション自体の公開はしない予定です．ちゃんと表に出してフィードバックをもらうのが重要だというのは理解しているのですが・・・ ：(
最近は毎日1時間ほど，このアプリケーションを遊んでいます．
2年位前から，「こんなアプリケーションが欲しいけど，誰も作らないだろうから自分で作るしかないなぁ」と考えていたものなので肩の荷が下りた気持ちです．

4月はコレの続きとして，ADNS-9500対応のものを作ろうとしていました．
しかし，問題が発生しました．

あーなるほど。 pic.twitter.com/IDGWY29JGn

— systema (@systema_) 2015, 5月 4

センサ側のMISO(SPI用のMaster入力Slave出力)のポートが死んだようです．図の上の部分がMISOの信号なのですが，最大でも0.5V程度しか出ていません．筺体に星の絵が書いてあるのが特徴のマウスだったのですが，センサーがお星様になりました．RIP Anker Laser Precision Gaming Mouse．
しかし#LogicalGamingの夏はまだ終わりません．Perixx MX-2000 IIの熱いカバーによって願望は成されるでしょう．

以上を踏まえて，日本周辺の優秀なゲーミングデバイス若人へ以下の言葉を送ります．
「ADNSセンサは出力ピンに電流をSinkさせると壊れることがあるので，通電前にMCU側のピン設定をよく確認しましょう．」

マウス

今使っているのはRazer Abyssus (2014)です．G300r best という結論が出たのですが，紫電改が原因でこうなりました．マウスパッドの項で詳しく書きます．

個人的な使いたいマウス候補を順で並べると，G300r，G100s，Razer Abyssus(2014)，その他，の順です．
G100sの形状が許容出来て，G300rのセンサー性能が問題となるのならG100sが一番オススメです．価格が安いのも良いポイントです．
ここ一年で，数十種類のマウスを店頭で触りましたが，サイズと重量の項目でほとんどが選外となりました．

他にはADNS-3090のドナーとしてELECOMのM-XG3Gを買いました．Amazonで購入できるADNS-3090センサ搭載マウスで一番安いと思います．このマウスは，カウントクリップが特徴のマウスですが，実際にプレイしてみると低IPS帯での使用ならクリティカルな問題はないのかなと感じました．
形状的は良いと思うのですが，少し大きすぎるのと，重量は完全にアウトの領域なので私のマウス候補からは除外となりました．そのうちセンサーからケーブルが生えることになるでしょう．コレのADNS-3090版を予定しています．最終的に基板から剥がす所まで行くかも知れません．

また，大手サプライから出ている極小の安マウスを捕獲して筺体の作りについて考えたりしていました．
今欲しいマウスははるか昔にディスコンしているWMOです．欲しいと言いつつ，WMOを使うのならG100sで良い気がします．
他には，DRTCM37/38関係のマウスがC国のメーカからチラホラ出ているようなのでこちらも気になります．

マウスパッド

後述の紫電改を買うまでの数ヶ月はCOUGAR CONTROL mouse padを使用していました．非常に良い布マウスパッドです．
個人的に使いたいマウスパッド候補を順で並べると，紫電改，COUGAR CONTROL，ROCCAT Tait，その他，の順になります．紫電改はかなり滑るマウスパッドなので，人を選ぶと思います．マウスパッドもまた，Arkなどの店頭で数十枚触りましたが，滑走性を考えると選外になりました．

最後に，最近Artisan 紫電改を購入しました．大変興味深いマウスパッドです．
摩擦係数はプラスチックマウスパッドとほぼ同等だと感じました．しかし，布，プラスチック製のマウスパッドと比較して，動摩擦係数と静止摩擦係数の比が1に近いです．もう少し全体の摩擦係数が高ければ完璧だったでしょう．
紫電改でG300(r)で使用すると低速時にセンサの誤動作が起きるので，Razer Abyssus(2014)を使うことにしました．紫電改を使い始めて2週間ほどですが，プラスチックマウスパッド並に滑る点を除けば非常によいと感じます．
Abyssusはブランド上の理由でL社のマウスが使えないといった軽量マウサーの方にオススメだと思います．(当然，中の錘は外してある前提ですが．)軽いのは確かですが，大きさ的には小型にはジャンルされないのかなという感じがします．

キーボード

RealforceのALL 30gモデルを買いました．しかし，テンキーが邪魔だったので一日でサブキーボードへ移動せさました．文章作成能力は非常に高いので，長文を書く時に出して使っています．これを買うために，実験装置のファームウェアの修正アップデート(という名のほぼフルスクラッチでファームウェアを書き直した)で稼いだ分がほとんど飛んだような・・・
スイッチの特性的にはゲーミング用途としても良いのかもしれませんが，極端な差は感じられません．赤軸とRealforceを比較して，戦績にどれくらい影響するかは未知の領域です．極端にこだわる人でなければCherry MXの赤軸か茶軸のメカニカルキーボードで十分だと思います．

ちなみに今，私が使用しているゲーム用のキーボードは赤軸のKEYCRAFTSのCR-210RD-BBLEです．このキーボードは製品HPの画像を見ると分かるように，全スイッチにLEDを搭載しているのに，キートップはクリアパーツではないので暗所では逆光でむしろキーの文字が見えないという大変に興味深い仕様なのですが，他に特徴はありません．テンキーレスなところは良いと思います．

描画遅延の基準点を調べてみる

半年ほど前にゲームのタイトル毎の描画遅延を測定する手法を紹介しました．

#LogicalGaming: ゲーム毎の描画遅延を測定してみる
今回はその測定手法を用いて，別のことを調べます．

今回は，「極限まで処理が簡略化されたゲームの描画遅延はどれくらいなのか？」という事を測ります．
これは，HIDデバイスの入力が，

PC内のUSBホスト → OS(CPU) → ゲーム → グラフィックカード → ディスプレイ

と処理されていく時の最短時間を知ることが出来ます．
この最短時間は，ゲームエンジンを描画遅延を意識して書いた時，そのゲームエンジンが到達できる最も低遅延な時間とも言えます．また，ゲームエンジンを最適化しても，これ以下の描画遅延を実現するのは難しいということになります．

プログラム

極限まで処理が簡略化されたゲームとして用意したプログラムは，今年始めに用意した自作プログラムです．SDL(Simple DirectMedia Layer)というマルチメディアライブラリを使用してOpenGL APIを制御します．

このプログラムは，マウスカーソルの移動のX軸が右方向なら赤，左なら緑を画面全体に描画します．他にはフレームレートの計測と，ESCキーが押されたら終了する処理のみです．

1フレーム(1ループ)が20行程度で書かれており，初期化が終了すればノートPCで走らせても1000fps以上出る非常に軽いプログラムです．
時代遅れになりつつある私のリグでも6200fps程度出ます(Intel Core i7 2600，NVIDIA GTX 670)．
フレームレートが約6200fpsとすると，プログラム自体が持ちうる遅延は0.16ms程度ですので，遅延は非常に小さいとして無視できます．
つまり，上述の最短時間からゲームの項を削除して考える事が出来ます．

PC内のUSBホスト → OS(CPU) → ゲーム → グラフィックカード → ディスプレイ

USBホスト，OS，グラフィックカードあたりは生半可な手法では遅延を削減出来そうな設定は難しいですので，あとは「ディスプレイを遅延の少ない機種に買い換える」程度しかユーザーサイドで工夫できる場所がないということになります．

結果

右端のBaselineのラベルが付いたものが，今回紹介したプログラムの描画遅延時間です．

私の作成したプログラムは8.4msとなりました．私の環境では，入力デバイスが画面に反映されるまでに最低でも8.4msの時間が必要になると分かりました．120Hz駆動の液晶で換算すると，ちょうど1フレーム程度になります．これは，どんなに良いエンジンでも，PC側の都合で最低でも1フレーム程度の遅延は起きうるということを意味します．

また，一般的なFPSタイトルは演算や描画処理などで，さらに4～10ms程度の時間が必要になると分かります．この時間は，エンジン内の描画処理の順序の工夫等で縮められるのでしょうか．描画遅延の削減を売りにしたエンジンとか出れば面白そうですね．
ゲームエンジンは，フレームレートが特にフォーカスされることが多いですが，描画遅延に対してもより一層注目が集まると，この差は徐々に埋まっていくかも知れませんね．

一段落

したはずなのですが．．．
色々後回しにしていた事を片付けるので3月中は終わりそうです．

2月と3月前半はブログ更新はおろか，シューターすらプレイできない日が大半でした：(
デバイス勢の方々のブログは欠かさず見ていましたが，私自身のアウトプットが少なかったです．
来年度は，「時間をうまく使う」ことを重要視していきましょう．

ゲーミング・ゲーミングデバイスへのモチベーション的には去年の今頃より高いですし，
ネタ自体はちょくちょく作っているのでボチボチ更新していきたいと思います．

マウスが見ている視界はどれくらいの大きさなのか？

以前マウスが見ている景色について調べたという記事を書きました．

マウスの光学センサが見ている世界を見てみる

マウスのセンサはマウスパッドをカメラのようなもので撮影して，そこから動かした距離を測定しています．

そのセンサの仕組みの中で，「マウスがどのような写真を撮影しているのか」という事を調べました．

今回はマウスのセンサがマウスパッドの表面でどれくらいの範囲を見ているのかを明らかにしていきます．

範囲が分かることにより，マウスが読み取れるような凹凸パターンのサイズに検討がつきます．

例えば，凹凸のサイズが非常に大きい面ですとマウスは小さい範囲しか見えないので変化がないように見えます．逆にマウスからは滑らかに見えるくらい小さい凹凸しかなければそれも変化を読み取ることが出来ません．どちらの場合も良好なトラッキング結果は得られないでしょう．

それではいくつか撮影してみましょう．撮影環境は前回と同じです．

まず最初はどこのご家庭にもあるノギスです．目盛の部分を撮影しました．

ノギスの目盛部分

目盛の黒い線がくっきり写っています．

"目盛の太さ"は目測ですが0.1～0.07mmくらいだと思います．

次はレシートに印刷してあったQRコードを撮影しました．

レシートのQRコード

こちらも綺麗に写っています．

このQRコードは12.2x12.2mmの範囲に33x33ピクセルで印刷されています．

この2つの画像から考えると，ADNS-5090が見ている範囲は0.8x0.8mm程度であることが分かります．ADNS-5090は19x19ピクセルの画素数ですので，1ピクセルが表す範囲は0.04mm程度であると分かります．

補足 ： レンズ倍率について

レンズの倍率を低くしてDPIを犠牲にしつつ最大トラッキングIPSを上げたりするようなこともあるらしいです．

参考 ： rafalog: 光学式センサー用レンズいろいろ

倍率を変更すると見える範囲も変化するので適切なパターンのサイズも変化します．

例えば低倍率にすると見える範囲が大きくなり最大トラッキング速度は上昇しますが，その分小さな凹凸は見えなくなります．その場合は表面の凹凸パターンが大きめのマウスパッドの方がより良いと考えられます．

生存報告も兼ねて．

2015年

あけましておめでとうございます．
今年も#LogicalGamingと@systema_，（CG/計算機な人は@aaax3001も）をよろしくお願いします．

・2014年を振り返って

ブログを立ち上げたのが2014/01/10なので，ちょうど一年程になります．
1-3月はあまり更新していませんでしたが，4月にrafa様のブログで取り上げて頂いてから本格的に活動を始めたような気もします．そういった中で様々な人から反応を頂きまして，更新のモチベーションになりました．
書きたいと思った記事はその時その時でタイトルだけ書いて全部下書きにしているのですが，下書きの個数は減るどころか増えています．ブログの更新するネタがないなんて言っている人が羨ましい・・・ ：D

3月の終わりにこんなツイートをしたのが懐かしいです．

本格的にLogical Gamingの活動開始します。主な活動内容はゲーミンググレードのデバイス開発を目標とした試験と解析です。
— aaax (@aaax3001) 2014, 3月 29

宣言通り「ゲーミンググレードのデバイス開発を目標とした試験と解析」はしていたのでよしとしましょう．センサ・スイッチの制御とUSB関係の基礎的な知識がついたのが良いですね．


ついでに去年の記事の中で印象深いものを幾つか紹介．

・USB HIDデバイスのクリックの最速応答を考える
USB HIDが制御出来たのが嬉しくて突発的に書いた記事です．
私でも比較的容易にクリックレスポンスの速い実装が出来ました．つまり，クリックの応答速度が速いメーカーが秘伝のタレを持っているのではなく，速度が遅いメーカーが何らかの理由で遅くしているという事でもあります．理由に関してはマーケティングやサポートであったり，優先度の低さなどもあると思います．
そういう意味でも良いゲーミングのためには，ユーザ自身が明確なデータを測定して公開するというのは大事なのだと思います．


・マウスの光学センサが見ている世界を見てみる 
ADNS系センサの制御は組み込み方面ではそこそこ見かけるのですが，PixelGrabberについてはちょこっと動画があっただけであまり使われていません．
そういった中で，ゲーミングマウスパッドがマウスの光学センサからはどのように見えているのかを示しました．解像度が低いのでもっと意味不明な感じだと想像していたのですが，思ったより顕微鏡画像っぽく見えたのがナイスですね．
今後の私のマウスパッドレビューではPixelGrabberで取得したマウスパッドの表面画像がつくようになるでしょう．泡沫ブログなのでレビューに個性が出すいいツールになるかもしれません．
光学・レーザーにおける差異を見てみたいのでレーザセンサもやるべきなのですが・・・今年の課題ということで．


どの記事も内容的に「訳わからん」と言われがちなのでもう少しわかりやすくしたいです．
このブログを訪れるユーザが「rafalogの過去の記事を全て読んでいる」という前提で話を進めているのが問題なので，もう少し導入部分に力を入れていきたいです．


次は"ゲーミングを定量化する"という，このブログ本来のテーマに基づいたものです．

・ゲーム毎の描画遅延を測定してみる
「ゲームのタイトルによって入力が画面に反映される時間に差異がある」という現象事態は多くのゲーマーが感覚的に認識しつつも公表はあまりされていません．「遅延というパラメータがゲーミングのパフォーマンスに影響する」という事自体が，ここ数年でやっとメジャーになってきたというのが私としての認識です．
その"遅延の差"の存在を証明し，ミリ秒単位で定量的に測定できる手法について示しました．
遅延の差の存在を証明することと，タイトル毎の優劣を明確に測定・公開することによって，ハードウェアの遅延だけではなくゲームエンジンや実装における遅延低減がフォーカスされると良いですね．


・Reaction Time (反射神経)とAimの関係
Reaction TimeがAimとどう関係するのか？Reaction Timeを縮める為に効果的な物はあるのか？
こういったことをゲーミングを指向して調査しました．結論として，人間も含めて全てを「システム」として捉えると，ハードウェアやOSに起因する遅延を出来るだけ低減するようにセッティングするべきだということと，人間のReaction Timeに関してはばらつきが大きく明確に改善する方法はないという事を示しました．
人間においては「集中力」というのがかなり重要な要素になっているのが分かったので，暗示（条件付け）についてもう少しフォーカス出来ると面白いと思います．


・FPSにおける武器の精度について考えてみる
この記事で最も言いたかったのは，精度が高い武器を使用すると許容される誤差が大きくなるという点です．あまり反響がなくて残念ですが ：（
私はシューターにおいて初弾の精度はかなり重要なパラメータだと考えているのですが，世間一般ではそうでもないのでしょうか．

・最近

年末年始は描画遅延の調査に必要になったためOpenGLを触っていました．
極端にシンプル（数ステップ）なルーチンを持つOpenGLアプリケーションを作成して，入力→ディスプレイへの描画における遅延時間の基準点を調べる予定です．
とりあえず実行ファイルは出来たので後は撮影とデータ整理ですね．ハイスピード撮影で動画は撮ったもののコマ数を数えるのが面倒でやっていない，という事態がここ2ヶ月程度続いているので・・・作って満足してしまうタイプなのかもしれません．

また，あのページ自体も「とりあえず測る環境は出来たので記事にする」という感じで公開した物なので，もうより体系的・定量的にまとめる必要があります．


あと，私はFPSでもスペースキーで射撃するという結構独特なスタイルだったのですが，レイテンシが気になってきたので構成を変えました．射撃はキーボードの下に置いたG302でやることにします．
こうすればクリック中に右手の筋肉の動きは制約を受けないし，レスポンスも最速クラスです．
マウスはアレ以来ずっとG100sを使っています．


もう一つ，COUGAR Gaming Mouse Pad - CONTROL series買いました．
このシリーズ，ControlタイプとSpeedタイプという2種類がラインナップされていて，Speedタイプは巨匠ことMysticSiva様がレビューされています．
Cougar SPEED gaming mouse pad | Chocolate Device

このマウスパッド，中々いい感じなのと，Controlタイプは3次元形状を持つ滑走面が売りらしいのでそのうちレビューしたいです．



と言いつつ・・・1，2月は相当忙しくなりそうであまり更新出来ない予定です．

G100sファーストインプレッション

「より軽量であること」がどれだけ有効なのかを確かめるために試用してみるテスト．

錘を外すために通電して全スイッチの動作を確認したら即分解．開封から5分程度でしょうか．

多分自己最速ですね ：D

ピストルサーバーをプレイしていて思ったのですが，このマウスは重量が軽いので慣性が小さく，ダイレクトに思考をマウスに伝えられる能力が高いと感じました．未だかつて無い一体感ですね．

G302の形状に慣れ，G100の形状にはすぐに適応出来たのでしばらくはG100sで行こうと思います．

初日でG100sに大きく傾いたので，AM010搭載の可能性が低いG300と，G100s選べと言われたらかなり微妙なライン・・・


ちょっと良いAIMだったので動画をアップロード ：D

ADNS-9500 Logitechカスタムを殻割りしてみる

巷でのブームに乗って撮ってみました．
Nikon 1 V1だと全然寄れないので苦し紛れでVICTORINOXについていたルーペで拡大してなんとか撮りました ：D

ADNS-'S'9500

手元に潰していいセンサは・・・と思ったらG700の基板がぶち転がしてあったので，センサを外して，殻割り．
「殻を割った」というよりはプラスチックのカバーを剥がしただけですね．センサの基板とカバーはゴム状の接着剤で貼り付けられていました．

このセンサは表面の印字では"S9500 B1212TD 103"となっており，通常のADNS-9500の"A9500 xxxx"という印字とは異なっています．S9500はロジクール向けのカスタムモデルのようです．
ピン数はAは8x2の16ピンですが，Sは7x2の14ピンになっています．何が省かれているのかは詳細に調べないと分かりませんが，Aのデータシートを見た感じレギュレータの出力ピンを省いたのかなーとか思ったり．

フォーカスが外れていますが，穴の位置的にセンサーダイから外れた右端の四角い物体がレーザ発光部だと思われます．チップLED的なものを想像していたのですが非常に小さいです．
ADNS-9500はダイ上に発光部があるので外部にレーザ用のドライバ（トランジスタ）をぶら下げなくてはいけないのですよね．


●PMW3310DHと似ている？
rafa様の記事を見ると，PMW3310DHとかなり似ている構成だと分かります．
参考 ： rafalog: Pixart PMW3310DH殻割り
周辺部を見れば判別は容易ですが，ダイのみで9500と3310差が見分けられる方は，極端にレベル高いソムリエですねこれ．是非お知り合いになりたいです．
また，センサの系統を考えるとADNS-9800もこれらとクリソツな可能性が高いと考えれます．

また，AM010ともおおまかなレイアウトは似ているのですよね．3050の世代からダイのアーキテクチャが変わったのかもしれません．


そろそろ，やり残した遅延ネタに移行していきたいのですが他にもやりたいことが幾つか・・・

ROCCAT KAVEのモード設定

KAVE自体はもうディスコンになっており新型のXTD 5.1chが出ていたりとちょっと時期遅れな感じですが気になったので実験．

重量・性能共に最高クラスと名高いのヘッドセットであるROCCAT KAVEですが，手元のコントローラには[Game]  [Movie]なるモード切り替えスイッチがついています．この設定，どちらがTop Choiceなのか調べてみます．

とりあえず公式マニュアルを見てみましょう．
http://www.roccat.org/Downloads/Manuals/ROCCAT-Kave/ROCCAT-Kave_Manual_EN.pdf
OPERATION，Game vs. Movieから引用：
Two options are available to you which control how the headset sound is mixed: ‘Game’ and ‘Movie’.
The ‘Game’ setting is equivalent to the original 5.1 sound setting and is best suited to games, particularly first-person shooters.
If you intend to watch films on the computer, ‘Movie’ is the best setting as it ensures that the voices sound clearer and more defined.

何をもって"best suited to games"と言えるのか明確なDefinitionが示されていないので詳細は良く分からないのですが，とりあえず「ゲームやるならGameモードが最適で，映画を見るならMovieモードにすると良いですよ．」という事らしいです．ほほう．

何が起きているのか確認してみましょう．
検証に使うのはCS:GOのカスタムマップ「Audio Test Chamber」です．
http://steamcommunity.com/sharedfiles/filedetails/?id=337790613

KaveのGameモードとMovieモードを切り替えながら足音を聞いてみます．
モードの切り替えの時にラグや音の途切れが全くないので，スイッチでコントローラ内の回路を直接切り替えているみたいです．

足音を鳴らしたままで自分の視点をグルグル回すとよく分かるのですが，Movieモードだと正面±30°くらいに音源がある時だけ音が大きくなります．他の状況だとGameモードとの差は知覚できません．

本来は自分が回っているのですが，音源のほうが回っているとするとイメージだと下図のような感じ．

「現実に近い」というか音の軌道として正しいように聞こえるのはGameモードです．
ゲーム用途なら間違いなくGameモードを使ったほうが良いと思います．

Movieの方は前方の音を強調した音響設定にしてあるみたいですが，それがなぜMovieに適するのかは不明です．何らかのサラウンドの規格に準拠していたりするのでしょうか．

KAVEの簡易レビュー ：

ついでにレビューをば．
結論から言うとこのヘッドセットが壊れたら2万円出して後継機のXTD 5.1chを買うレベルで気に入っています．
サラウンドに対応しているタイトルのみに限定されますが，2chヘッドフォンと比較すると「定位感」の次元が違います．BF3をメインでプレイしていた時に購入したのですが，立ち回りが変わりました．

わかりやすく言うと，目を閉じた状態で
・2chでプレイ・・・敵の居る方向が30度刻みで分かる
・5.1chでプレイ・・・敵の居る方向が15度刻みで分かる
という位の差です．
足音を聞いてPrefireする時の精度も上がりますし，後ろから足音がした時に厳密にどこに敵が居るのかかなり正確に分かります．


もちろんある程度のサウンドカードも必要ですが，定位感を重視するならサウンドカードよりもヘッドフォンがリアル5.1chな物を買うべきでしょう．
120HzのモニタとKaveのどちらかしか使えないのなら120Hzのモニタより60Hzモニタ+このヘッドフォンのほうが強いと思います．

私のデバイス優先度は，

マウス > マウスパッド > Kave > モニタ > キーボード > サウンドカード

という感じですね．あくまでサラウンド対応しているゲームに限定すればですが．


・音質
少し低音が強めでほかは普通という感じ．
他のチャンネルのドライバを入れなくてはいけないのでドライバ径も小さいですし，2chヘッドフォンだと考えると約1万円というのはかなりコストパフォーマンスの悪い製品だと思います．これに音質に期待して買う人も居ないでしょうけど．ただ，音質的には3000円くらいのヘッドフォンよりは良いと思います．


・装着感
耳全体を覆う感じのタイプで，重い以外は良いです．密閉型なので蒸れます．
私もゲーム中以外はスピーカーを使用しており，基本的Kaveは使いません．


Pros
・次元が違う定位感
・特に難点のない音質（特筆して良くないが悪くはない）
・耐久性が高い（3年間毎日数時間使用しても壊れない）
・装着感

Cons
・サラウンド対応タイトルでしか効果を発揮しない
・重い（人によっては装着できないと感じるほど）
・蒸れる（密閉型のため）
・音質の割には高額（2ch用途のみなら別なものを買うべき）

CS:GOのFoV（視野角）を擬似的に下げてみる

超小ネタ更新．

Counter Strike Global Offensive では視野角(FoV, Field of View)は固定となっています．
垂直方向の視野角は一定で，モニタのアスペクト比に応じて水平方向の視野角が変化します．
CS:GOの日本語Wikiに大変分かりやすい図が乗っているので参照下さい．

アスペクト比に関しては，4：3+黒枠（Black Bars）の方が良いとか，4：3を16：9に引き伸ばすと敵の横幅が大きくなるので当てやすいとか，横方向の視野角が大きい16：9ワイドが強い等々の説ありますがプロですらこのあたりの設定はマチマチであり，「自分がやりやすいと思うものが一番良い」というのが一般的な意見のように感じます．

今回はいつも少し毛色の違った話で，簡単にFoVを下げる方法を考えようというトライです．

体感的にはこんな感じ．

やることは簡単で，

1.ディスプレイを物理的に近づける
2.HUDサイズを小さくする

この2点です．
2をやらないとレーダーやキルログなどの重要な情報が見れなくなってしまうので結構重要だなと思います．
HUDサイズはビデオ設定のHUDサイズから設定できます．

あとは下図の暗部を見ないようにするだけ ：D

CS1.6で大変有名なSionさんもこういう意図で画面と近いようなプレイスタイルでプレイされていたのかもしれませんね．

【ニコニコ動画】Counter-Strike1.6 Sion -all view-