浅草ギ研 感圧センサー 「AS-FS」レビュー

はじめに

感圧センサのAS-FSに関する情報がWEBにあまりないので簡単に紹介します．
ちなみにゲーミングデバイスは出てきませんのでその筋の方にはあまり意味のない情報です．
(低レイヤ系のゲーミングデバイス勢の皆さんは，おそらく私と同じことを考えると思うので必読です．)

力センサ事情

気圧センサなどは結構色々選べるのですが，機械的な圧力を測れるセンサは種類が少なく，個人で気軽の買える圧力センサはAS-FS以外だとInterlink ElectronicsのFSRシリーズくらいという感じで結構珍しいです．
力の計測の王道としてはロードセルを使えばよいのですが値段やサイズが・・・というのがあって個人で手を出すのは結構際どいラインだと思います．
ちなみに，まともな力センサを安く手に入れる方法として「電子秤を分解してセンサ部を使う」という手があります．

AS-FS概要

詳細 ： 浅草ギ研　感圧センサーAS-FSの紹介
センサを買うとデータシート的な1枚の紙が付いてきますが，内容は公式サイトの紹介ページとほぼ同じでした．
抵抗値が変化するFSR系と違い，電圧出力なので出力ピンをADCするだけで力が測れてお手軽です．それに小型，安価なので導入もしやすいと思います．

センサ構成

分解画像

大きく分けて基盤とゴム部の2つから構成されています．2つはネジとナットで組んでありました．
白いゴムの感触はモノ消しゴムのような感じ．

原理的は渦巻きのパターンの部分に黒い導電性のゴムが当たって，当たってる具合で抵抗値が変化するような感じでしょう．

評価

簡単に使ってみました．(かなり適当なので参考程度にお願いします)

評価環境

MCU ：CY8CKIT-050 PSoC® 5LP Development Kit

ADCにはΔΣ型ADCを使いました．センサの出力はADC_INピンに直入れします．

コンフィグ

評価

ノイズ的には，サーミスタと同じようなモノなので回路の頑張り次第です．ちなみに適当に繋いでも8bitで揺れがないくらいでした．
最小感度はゴムを固定しているネジの閉め具合で決まります．ゴムが基盤から浮くくらいネジを緩めると，かなり感度が上がりますが0N付近の出力の安定性が大きく下がります．まともに測れるレンジは100g以上だと思います．それ以下は検出自体は出来ますがかなり不安定な感じです．
最大感度はデータシート通りの2kgくらいでしょうか．思い切り握っても値は上下しているような気もするのでもう少し高いかもしれません．

ヒステリシス

これがかなりの曲者です．無負荷→押す→無負荷という手順を行うと，前後の無負荷の出力が異なります．例を挙げると，950→1200→980，みたいな出力になります．
センサの原理を考えれば当然ですが，絶対値の測定などは結構厳しいです．

また，ネジの閉め具合で無負荷時の値が大きく変化します．そういう意味でも再現性がかなり低いです．原理から言うと気温とか湿度とかそういう影響も受けそうですね．

瞬間的な圧力の相対値とか，圧力の増加/減少は測れるのでそういう所には使えると思います．
長期的に運用しながら絶対値を測るような使い方には向いていません．ゴムの固定方法を工夫した上でキャリブレーションを丁寧にすればなんとかなるかも？，みたいな感じだと思います．

まとめ

• 導入は簡単
• 出力ピンをADCするだけ
• ヒステリシスが大きい
• 0N→押す→0N のような操作をした時に前後の0Nで値が異なる
• 絶対値の測定には向かない
• ゴムの状態によって出力値が変わる+ヒステリシス

結論から言うと，私が使いたい用途には向きませんでした．
このセンサはあくまで感圧センサで，圧力センサではないです．
「インテリジェントな検出スイッチ」みたいな使い方が向いていると思います．

加速理論とその後の周辺

はじめに

私の現在のマウス加速の設定とその設定の考え方について紹介します．

関連記事

#LogicalGaming: 加速理論とその周辺
ゲーミングにおけるマウス加速は有効にするべきか，それとも無効にするべきかという是非について議論しました．

rafalog: マウスアクセル調整ツール Interaccel紹介
rafa様によるInteraccelの紹介記事です．

rafalog: Interaccelセッティングガイド
rafa様によるInteraccelの設定方法のガイドです．

パラメタの設定方法

私は無加速時のセンシティビティを基準に設定しました．

私はCSGOをsensitivity 1.0，加速オフでプレイしていました．DPIが750の時で180度振り向くのにおよそ35cmほどです．
400DPI換算だとsensitivity 1.875程度ですね．プロプレイヤーの平均的コンフィグと比べると少し低いですが，私は左利きなのに右手でマウスを扱っている上に，身体を操作する能力が高くないので「こんなもんかな」と考えています．

この35cm/180°というセンシティビティは，私がFBを回避できるくらいの速さで視点を回すことができ，かつ遠距離でもHSを狙っていけるギリギリのラインです．
欲を言えば，500DPIのほうが遠距離の精密射撃は安定するのですが，500DPIだとFBの回避やクロスレンジでの撃ち合いがかなり厳しいです．対して，1000DPIだとクリアリングやFBの回避はスムーズに出来ますが，不調時にAimingの精度が低下し安定感がありません．

したがって，500DPI～1000DPIの「いいとこ取り」をしようということで加速を設定しました．

数時間の調整でこのようになりました．まずマウスのDPIを1000DPIに上げました．
そして，低カウント時に500DPIとなるようにPost-ScaleX，Yを0.5に設定しました．
Acceleration値は低めの0.05にしました．色々試してみたのですが，無加速時の設定に慣れすぎたためか，数値を0.1や0.2にすると違和感が大きかったです．
以上で右のグラフのように，1Count/Pollingの時に500DPI，20Count/Pollingの時に1000DPIになるような設定になります．

また，現状では，Acceleration値が低いためSensitivity Capが入れていません．今後入れるかもしれませんが・・・．Acceleration値を高く設定する場合は必須だと思います．

経過観察

Aimは無加速時の水準に戻すまでに2，3日かかりました．Aim戻し方はブランクがあった時と同じですね．ACEやいい感じのフラグシーンもそこそこ出ているので，あとは今後の慣れ次第だと思います．
加速を入れるとAWPが当たらなくなるイメージがあったのですが，そうでもないようです．

余談ですが，無理にマウスを振らなくて良くなったのでSurfがかなりやりやすくなりました．

おまけ

2016年

はじめに

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

ブログを立ち上げてから2年が経ちました．2014年は44記事と，かなり見せつけていった感じもありますが，対する2015年は10記事でその中で内容があるものは7記事程度とあまり芳しくない結果になりました．

優先順位的には(1)リアルでのタスク，(2)シューターのプレイ，(3)ブログの更新という順序なので，1つ目が詰まってくるとプレイヤーとして活動するだけでいっぱいいっぱいになってしまいました．コンスタントに更新しているデバイス勢のみなさまをリスペクト不可避です．
しかし，徐々に時間の使い方上手くなっているような気もするので今年はもう少し更新できるような気がしています．

2015年を振り返って

記事にはしていませんが，ADNSセンサとSPI通信の実装について理解が深まったのが技術的な収穫でしょうか．

SPIの送信バッファのFIFOが空になった後にディレイ入れると，おそらくSSがHIGHになるのでセンサが通信終了だと勘違いして読めていないんでしょうね．5090だとt_SRADが4usなのでなんとかなっていたのですが，9x00系や3xxx系はt_SRADが大きいのでここで(文字数

— systema (@systema_) 2015, 10月 14

そろそろオシロスコープが欲しいです．

また，CS:GOのStatTrak™ について簡単な開発をしました．

現存する類似物の中では，最も再現性の高いディスプレイ表現が出来たと自負しています．

それでは去年の記事で印象深いものをいくつか紹介します．

加速理論とその周辺

これが一番反響が大きかったように思います．便利なツールも出てきましたので，マウス加速についてもう少しフォーカスされるようになると良いと思います．

また，この記事ではもう一つ言いたかったことがあります．それは，これまでのように風習や経験則，感覚を大切にすることも大事ですが，定量的なデータを使用したり工学的（科学的）な視点からの論理的な考察も加わることでゲーミングは更なる高みを目指せる，ということです．

ただ「理論だけをブチ上げて手を動かさない」という説得力のないパターンになりつつあるので，実際に動くものを作るということにも注力していきたいです．

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

VR界隈でも描画遅延と「酔い」の関係などがフォーカスされてきており，そういう意味でも描画遅延ネタは継続していきたいです．この記事で理想値は分かったので，今後は「そこにどうやって近づけるか」ということを議論していきたいです．特に，最近のWindowsはDWMが明示的にオフにできない事による影響や，ゲーム内のコンフィグに起因する遅延の増減などを調べられることを考えています．

#LogicalGamingGlobal

 低レイヤーの部分を扱うデバイス勢の方は少ないので，探索範囲を広げて交流していけばより多くの知見が得られると考えて始めました．今年はきっと更新します・・・．ゲーミングデバイスオタクにも英語力が求められる時代ということでしょう．
さしあたり，描画遅延について書き始めたのですが，知っていることを全て書こうとするとIEEE Transactionsのフォーマットで10pくらいになりそう，ということが分かってきて止まっています．ですので，適当で良いので英語の文章とデータを出したほうが良いのかなと思い始めています．

近況

デバイス

年末にDPのマウスパッドを7枚買いました．興味深い特性を持つものがいくつかあったので，じっくり考察していきたいと思います．表面画像も近いうちにアップロードします．

使用中のデバイスは，マウスはG100s（形状的にはG300がベスト），マウスパッドはコントロール系の布マウスパッドというのが2015年に出た結論です．しかし，マウス加速に関して考えると，マウスパッドに関してはまだまだ調べる余地がありそうです．
今はRazer Orochi 2015が気になっています．形状は異なりますがG300に近いコンセプトで，センサー性能が良さそうです．

ゲーム

CS:GOではランクをGEにすることが出来ました．ただ，私が強くなったというよりはシステムの仕様変更による影響が大きそうです．しかし，とりあえずの目標を達成することが出来たので嬉しいです．
12月中旬からはCS:GOを休止してTom Clancy's Rainbow Six® Siegeをプレイしています．ユーザが明示的にマップを改変して守ったり攻めたりするシューターは珍しいので，しばらくプレイして可能性を探りたいと思います．

加速理論とその周辺

FPSシーンのデバイスのセッティングでは
マウス加速はOFFにすべきである
ということが基本的事項として言われています．

私も現状の設定では加速なしでプレイしているので，加速なし派の支持者と言えるのですが，デバイスについての知識が増えるに従ってもう一度加速について考えるべきだと感じています．

機械的な視点で考えると，

• 異なる応答特性をもつ複数のアクチュエータ
• 肩，腕，指の筋肉
• 複数のジョイント
• 肩，肘，手首，指

を用いて作業点(マウス)を動作させているので，非常に複雑な構成のシステムです．

また，アクチュエータである筋肉の電流応答を見てみましょう．

[1]

肩，腕，手の筋肉が一概にこういう特性だ，ということを断言するわけではありません．しかし，少なくともマウスを動かすのに使う筋肉も「線形応答ではないはず」という予想はできます．

そして，制御系(脳)自体も，状況に応じて様々な神経からのフィードバックと神経の遅延を加味しながらアクチュエータを制御しています．こうしたシステムで，「最終的に系全体では線形になっている」もしくは「線形な特性をもつポインタを使用するべき」と主張するのは難しいと考えています．

また，私の考えていた加速なしにしていた一つの理由として，
脳は移動量を関節角のフィードバックを元にしているはずであるので，いかなる速度で動かしても一定の関節角の動きを取る加速なしが優れている
という考えがあります．しかし，前述のとおり関節の構成は複雑です．
また，関節の長さもポイントとなります．例えば肘から作動点まで40cmだとすると，1mm平行移動させる場合の肘関節の角度差は0.14°となります．私は，複数の関節からのフィードバックを0.1°単位で加味しながら制御しているとは考えられません．
そしてプレイ中に意識して考えると，どちらかというと視覚からのフィードバックを重視しており，そこから筋張力を制御しているように感じます．したがって，実は関節角によるフィードバックは重要度が高くないと考えるようになりました．

これらを勘案すると，「加速は入れるべき」なのではないかということが分かってきます．

加速なしv.s.加速あり

それぞれのメリット・デメリットはrafa様の記事の通りなので是非参照してください．
私の経験から要点をまとめると以下のようになります．

• 加速なし
• ハイセンシ
• 成績にムラが出やすい
• 近距離に強く，遠距離に弱い
• 多くのタイトルで初期状態ではハイセンシ状態である
• 初心者にハイセンシのプレイヤーが多い
• ローセンシ
• 成績が安定する
• 遠距離に強く，近距離に弱い
• ミドルセンシ
• ハイ・ローの中間的な特性だが，近距離ではハイセンシに負け，遠距離ではローセンシに負ける
• 加速あり
• 習熟に時間が掛かる
• 極めれば(恐らく)不得手なレンジは無くなる
• 「加速特性」という複雑なパラメタを自分に合わせてチューニングする必要がある

加速特性

ちなみに「どのようなパターンの加速特性とするべきか」という問題に関しては，非常に難しい問題なので今後のユーザの試行錯誤に期待していきたいです．
さしあたり，現状で分かっている点から加速特性について少しだけ考えてみましょう．

低速域の場合，例えばの話ですが，右に3カウント動かした後に左に4カウント動かす，というのを瞬時に間違いなくやってのける人はあまりいないでしょう．400dpiだとすると，1カウントで0.06mmとなりますが，誤差±0.03mm単位で物を正しい場所に動かすのは難しいです．そういう意味では低速域ではセンシティビティを下げるべきだと考えられます．

高速域では，低中速域でのセンシティビティに大きく依存すると考えています．低中速域でのセンシティビティが低い場合，高速域では大きな力が必要となります．全力で投げるよりも8割の力で投げた方がコントロールしやすいですよね．したがって，中高速域ではある程度の加速をかけて全力で動かさなくても高速に視点が動作するようにすると良いでしょう．

問題点

「加速なし」の圧倒的なメリットとして，「振り向きを一度測れば，すべてのタイトルでセンシティビティを統一できる」というものが挙げられます．基本的にはrawinputを有効にするか，OS側の加速を切ってゲーム内の加速を切ることで加速なしの環境は構築できるのです．そして，使い慣れた振り向きになるようにセンシティビティを調整すればOKです．
ついでに言えば，ゲームエンジン毎に振り向きを計りながらセンシティビティを調整するのは面倒なので複数のタイトルで設定値を統一して欲しいですが．

加速ありで問題となるのが複数タイトルでのセンシティビティを合わせにくいというものです．私も一時期マウス加速を試していた時期があったのですが，複数タイトルでのセンシティビティが合わせにくいという理由で止めています．
インゲームの加速機能を使用すると，エンジンによる加速のかかり具合によってセンシティビティが統一できないという問題があります．また，rawinputしか選べないタイトルも存在するかもしれないのでOS側で設定するというのも難しい話です．

こうした問題を解決するには，複数タイトルに対応した統一的な加速特性設定の規格が必要なのだと思います．

さしあたっての解決法は，QL Mouse Accel Driverなどでドライバレベルで加速をかけることです．しかし，導入が少々面倒という点があります．

または，マウスレベルでの制御を行うことです．加速を掛ける段階でカウントをうまく縮尺させれば，整数型でも加速をつけることができるのでFPUを搭載していないマイコンであっても，問題にならないレベルの演算時間だと見積もることができます．マウスレベルで加速をかけることで，ネットカフェやオフラインなどの環境でも自分の加速特性を利用することができます．
しかし，こちらはファームウェア毎に異なる方法で加速をかけることになるので，複数のマウスを頻繁に取り替える場合などを想定すると，これもまた統一した規格が必要になると考えられます．

[1] 板倉直明,久保公人,井口弥寿彦,南谷晴之: "電気刺激による筋張力制御系の安定性の評価" 電子情報通信学会論文誌. J72-DII. 1543-1549 (1989)

ブランク後のAimの戻し方

7月は「その日その日の締切のタスクを消化していたら，気がついたら終わっていた」という感じで，ほとんどシュータープレイできませんでした．

ここで問題となるのは，「ブランクの後にAimを元の水準に戻すにはどうするのか？」というところ．

前に書いた記事の通り，毎日継続してまとまった時間プレイすることが重要であるのは分かっているので，今回は意図的に長時間プレイすることにしました．
初日は，Aim調整のみ，ピストル20分，デスマッチ20分，2vs2を1.5時間くらいでしょうか．
ここで，画面が思ったより遠くにおいてあることに気が付いて画面を近づけたり，センシを調整したりしました．

翌日はピストルを20分，デスマッチ20分程度してからMMをプレイしました．
3試合連続でACE(1ラウンド中で5人全員を一人で倒すこと)を出したり，前の水準よりも良いんじゃないかというくらいになりました．Aimは思っていたよりも速く戻るものなのだなと思いました．

ここまで来ると完全なる日記ですが，色々ネタはあるので8月はボチボチブログの更新をしたいと思います．Globalの方も1本か2本あげたいところですね．

#LogicalGamingGlobal

グローバルへオフェンシブに行きましょう．

#LogicalGamingGlobal というブログを作りました．
弊ブログの英語版という位置づけになります．

このブログのアクセス解析をしていると，翻訳して見てくださっている方が結構いるようで，折角なら英語版を作れば良いのではないかと思いました．
ちょっとコアな内容の記事だと，国内だと「俺得」だと思ってくださる方が数える程しか居ないような気がしていて，もう少し裾野を広げれば面白いことになるのではないかと期待しています．

全記事を翻訳して出すわけではなく，去年の総集記事に書かれるくらいのクオリティをもつ記事だけ要約・翻訳して書いていこうと思います．"ゲーミングを定量化する"系のネタは，海外は海外で各々やっているので出す必要はあまりないと考えていて，デバイス系メインになる予定です．
要するに#LogicalGamingの要約版なので，日本人の方は特に見る必要はないものになるでしょう．


グローバルでフルスタックなπ型人材の需要が高いようなので，英作文の練習も兼ねていたりもします：D
圧倒的成長をしなければいけない時期になりましたので，とりあえず趣味と実益を兼ねる所から攻めてみようかと・・・なにかレアスキルとかあれば良かったのですが：(

私の英語力的にすごく恥ずかしかったりしますが，うまく内容が伝わるように頑張りたいです．

マウスパッドの相性問題をマウスソールの厚さを変えることで解決してみる

先日，Artisan 紫電改を購入したのですが私のG300rではうまくトラッキングが出来ないという問題がありました．症状としては，G300rの低速移動時にカーソルが意図していない方向に動きます．また，高速移動時も意図しない方向に飛ぶことが多々あり，事務作業にすら使用できないレベルでした．
結論から言うと厚めのソールを使っていたことが原因でしたが，そのデバッグの様子を書いてみます．


とりあえず，なぜトラッキング出来ないのか調べます．
まずは，この装置(マウスの光学センサが見ている世界を見てみる)を使って表面の様子を見ます．

当該記事で他のマウスパッドと見比べていただければ分かりますが，紫電改はコントラスト比が低く「のっぺり」とした表面でかなり「悪い」部類に入ります．
確かに，カタログスペックが低いADNS-3050系センサではトラッキングするのが厳しいのもうなずけます．

しかし，どうしても紫電改が使いたいので諦めずにトライしましょう．
特徴点を増やすように試行錯誤してみたところ，基板を強く押し付けた場合( -0.1～0.2mm )に良好な結果が得られることが分かりました．

たった0.1mmか0.2mm程度の差ですが，もはや別のマウスパッドに見えます．コントラスト比が上昇したのと，表面の若干低い位置にある小さな粒状の突起にハイライトが見えるようになりました．
この結果を元にG300rのソールを薄いものに変更したところ，低速時のトラッキングエラーはほぼ無くなりました．

この装置的には，上の図の状態でソールを外してある上に，マウスパッドに押し付けていますので，メーカ設計の値の-0.5mmくらいの位置です．かなりフォーカス位置が外れている印象ですね．

まとめ

• 0.1mm単位でソール厚を追い込むことで，トラッキング性能が向上
• 相性問題をFixできることも
• 付属ソールと同じ厚さにしておくのが無難
• 3D系の表面の場合はちょっと薄めにすると良くなるかも

マウスパッドの相性問題に悩まされる場合は，ソール厚を変更することで実用レベルまでに改善することがあるので是非お試し下さい．

※今回は「ソール薄くする」ことで解決しましたが，一概に薄くすれば良いというわけでもないと思いますので色々試行錯誤してみてください．

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程度の時間が必要になると分かります．この時間は，エンジン内の描画処理の順序の工夫等で縮められるのでしょうか．描画遅延の削減を売りにしたエンジンとか出れば面白そうですね．
ゲームエンジンは，フレームレートが特にフォーカスされることが多いですが，描画遅延に対してもより一層注目が集まると，この差は徐々に埋まっていくかも知れませんね．