2014/06/24

マウスデバッガ

センサデバッガという記事は書きましたね。当たり前ですがセンサをデバッグしても特に意味はありません。そもそもセンサはデバッグするまでもなく、データシートがあります。
加えて、マウスというシステム自体の特性は、センサよりはMCUに依るところが大きいのです。

そんなわけで、最近コソコソと光学ナビゲーションシステム用リバースエンジニアリングツールを作ろうと画策しているのです。

Q. どんなツール?
マウスの基板上のSPIバスにコイツをぶら下げることでMCUとセンサの全通信を記録するツールです。

Q. どうやって?
センサから物理的に配線を引き出します。引き出すのはMISO、MOSI、NCS、SCLK。
MISOとMOSIをPSoC内の仮想ORゲートでOR演算して、SPI Slave ComponentのMOSIに突っ込みます。NCSとSCLKはそのままSPI Slave Componentに接続。
UART通信で通信内容をPCへ送信。

完成したら意味もなくプロジェクトファイルを上げて誰得感を楽しみたいのですが、非常に忙しいのでリリース時期は不明。

本題 :

なんとなんと面白いデータが出てきました。(データ内のCommentは後付です。)
あまりに面白いので思わずブログを更新するほどに。

 ・試験環境
環境 : PSoC Creator 3.0 SP7
検体 : Anker Laser Precision Gaming Mouse
MCU : PSoC 4 Pioneer Kit

データ内のCommentは後付です。
----------------------------------------------
3a 5a //RESET
24 00 //ゴミデータ?
24 3f //ゴミデータ?
7f 20 //ゴミデータ? FF 20かも。
03 00 //ここからはデータシート通りのスタートアップシーケンス
04 00
05 00
06 00
39 02 //SROMは3Kモードですね
13 1d //SROMのアップロードシーケンス
13 18 //同上

//これ以降の2900バイトは読みだして捨てている(SROMなので)。

//2900バイト捨てたあと↓
86 10 ab c3 75 e9 1f 86 53 4b               
8a 1f 01 f6 f0 3c 7a a8 cd 12 98 c5 9a 1c a8
68 4e 11 b0 08 12 6a 2d df 37 ff 52 b7 d2 e1
7a c5 00 fd 42 b4 30 e7 92 38 f8 e5 3e ff b6
5a 6f 33 7a 7a 0e 74 75 36 ef 82 9e 35 53 5e
2c f1 f6 54 35 e2 d6 c1 07 c2 f0 e0 99 b5 1b
fd a1 2f 43 5d b9 03 db 25 e2 c0 d8 b2 98 e7
91 4f 82 58 35 92 e1 55 86 8e 01 8d 10 29 dd
34 62 4e 16 22 4a 9a be f7 e1 c9 1c 32 6a db
3f f5 e1 4c 92 ae d7 a0 cf 90 ae d7 a1 48 1d
b5 60 cb 99 38 7a 7e 76 e3 4c 15 a4 c7 81 0b
9c b7 60 cb 1c 31 ed d1 2f d5 27 c7 63 60 83
2a a0 20 01 ff ff ff 33 ff ff ff ff ff ff ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 40 61 ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 3c 5b ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 38 96 ae

40 50 20 7f 00 00 00 00 00 df 7f 7f 31 bd ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 2e a2 ae
36 50 20 7f 00 00 00 00 00 df 7f 7f 28 fd ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 26 6e ae
2e 50 20 7f 00 00 00 00 00 df 7f 7f 24 08 ae
2c 50 20 7f 00 00 00 00 00 df 7f 7f 1f ac ae
27 50 20 7f 00 00 00 00 00 df 7f 7f 1d b2 ae
25 50 20 7f 00 00 00 00 00 df 7f 7f 1a 1a ae
22 50 20 7f 00 00 00 00 00 df 7f 7f 18 79 ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 16 f2 ae
1e 50 20 7f 00 00 00 00 00 df 7f 7f 14 2b ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 12 e9 ff
ff ff 20 7f 00 00 00 00 00 df 7f 7f 10 a0 ae
18 50 20 7f 00 00 00 00 00 df 7f 7f 0e 9d ff

.......... //以下ずっと同じようなデータ
----------------------------------------------

MotionBurstを使っているとは・・・意外性を出していきますね・・・
確かにそっちのほうが速いかもしれないが・・・?
しかし、MCUからセンサに何か言うことは無いんですかね。

それと、レジスタアクセスが意味不明過ぎます。というかデータの精度がかなり悪い。ちゃんとSROMアップロード出来てるのかすら分かりません。
マウスの問題なのか、こっちの問題なのか判断するのにオシロスコープが必要ですね。
細かい解析はいずれ。他のメーカのマウスを試そうにも検体と時間がありません。

おまけ

もう一度取ったデータをば。
----------------------------------------------
3a 5a
24 00
24 3f
7f 20
03 00
04 00
05 00
06 00
39 02
13 1d
13 18
6a c3 8c 14 3e b9 7c 30 85 5e
1b af 48 fc 32 9a 5c 50 f8 0f b7 81 e3 d5 46
68 94 c6 2c d0 e5 43 42 70 8d 80 40 93 51 6e
f9 bf fa 95 be 97 0b d6 28 07 ea 15 a1 87 3c
91 c7 c7 29 f7 fd b2 d3 79 9b d3 d0 73 a3 a9
b7 7c 14 f1 aa 9a f1 67 8f b2 a1 af 16 b6 08
3e 17 87 04 cd a8 df ed 09 7a 1a ed c8 1e d9
2f 16 06 c5 94 c7 3c 8a 7c 12 c1 ac 97 0a ac
34 70 0c 68 81 4e e9 a3 12 70 b1 12 54 d5 f7
bf 0e 48 e1 93 56 d9 ff af 0a 64 95 76 bd 06
7c 85 76 bd 0a 40 ed ab 06 5c c9 c3 d3 f3 b7
1a 60 ad 26 3c 08 5c e5 bb 06 58 e1 8f 6e 89
7e a9 3e 3b 1b 04 19 2a a0 20 01 ff ff ff 33
ff ff ff ff 67 ff ff ff ff 20 7f 00 00 00 00
05 db 7f 00 44 ab ff ff ff 20 7f 00 00 00 00
00 df 7f 7f 3c 5b ff ff ff 20 7f 00 00 00 00

----------------------------------------------

2014/06/19

更新減速

プライオリティの高い物を後回しにしてきたツケが回ってきそうなので更新頻度低下すると思います。

再開期間は未定、というか4~6月はたまたま運が良くて暇だったので、月6、7本のペースで書けたのですが。

もちろんゲームもデバイスも止める予定はないですが、相対的に取れる時間が減りそうなので優先度の低いアウトプットは減りそうです。


結局4月の段階で19本あったブログ記事の下書き、現状で2本しか減っていないんですがそれは大丈夫なんですかね。

2014/06/11

G300におけるレポートレートとレジスタアクセスの考察

個人的に推しているG300ですが、X、Y変位がオーバーフローするのを見てみたいので、ちょっとした実験をしました。

実験方法

1.マウスをぶんぶん振り回してログを取る。レポートレートは125Hzと1000Hzで行う。
2.最大値を最小値を抜き出し、考察する。

結果

・125Hz : -2032 ~ 2048
・1000Hz : -254 ~ 256

なるほどなるほど。色々と判明しました。

考察 

・センサの向き
最小値と最大値がそもそもおかしいです。ADNS系センサは、右方向を正の数として-128~127の値を取るはずなので最小値の絶対値は最大値の絶対値より大きいはずなのです。これから考えられるのはセンサが逆向きに付いているということ。

→ 確認した所、実装方向が逆向きでした。リファレンスデザインでは奥にあるはずのロゴが手前に来ています。このままだと出力がおかしいのでMCU的に正負を逆転しているのでしょう。こういった実装の意図は不明。
ユーザ的には、上下逆だろうが1カウントしか違わないのでほとんど関係ないです。


・レジスタへのアクセス間隔
あり得ないですが、「カウントをソフトウェア補間で倍にしている」という最悪のケースを考慮しなければ、1000Hzにおいては1レポート当たり2回、125Hzにおいては1レポート当たり16回でしょう。要するに毎秒2000回。

こうすることである程度のオーバーフローは防げますね。


・レポートレートの実装
アクセス間隔から考えるに、2000回のアクセスは全てのレポートレートで固定です。
センサから値を取得する度にMCU内の変数に加算しておき、レポート時は変数値を転送するような感じでしょうか。


・オーバーフロー対策
ローセンシプレイヤーは2500DPI等の高DPIでは使わない。1000DPI程度にすれば並の人間が振れる速度でオーバーフローはしないので問題ありません。
ハイセンシプレイヤーは、2500DPIでオーバーフローするような速度で振ったらキャラクタが何周もするはず。なので、その速度域は使用しないはずなので問題ない。

最も問題なのがマウスが高DPIでゲーム内のセンシティビティが低いようなプレイヤー。
この場合はバランスを見ながらDPIを落とし、ゲーム内センシティビティを上げる。

2014/06/10

レビュー : G-Pad 小間久商店

小間久商店のG-Pad Ultra wide small side edge ( スベリ7 グリップ1 ) 買いました。
若干マイナーなジャンルの製品なので、レビューがあまり無いのでメモ程度に書き散らしておきます。 日本製のガラス製マウスパッドでゲーミング用途って、現行品だとこれくらいしか無いんじゃないでしょうか。

写真では下の机の木目が写っていますが、マウスパッド自体は無地です。

Overview

Name : G-Pad Ultra wide small side edge スベリ7 グリップ1
Price :  8424 JPY
Made in Japan

Specification

JP : http://sheetglass.net/08g-pad/ultra/index.htm

Edge

Small edgeタイプ。面取りは、おおまかに角度15[deg]で幅4[mm]です。触っても痛くありません。

Nonslip sole

滑り止めの"マウスパッド用"ソール。12個付属してきて、自分で貼り付けます。グリップ自体はかなり良いですが接地面積が小さい為、効果は並程度。しかし本体重量的にずれることはほとんどありません。

Tracking

左右にブンブン振り回した時のX軸のカウント数です。rafaさんのブログのと見比べても普通ですが、こちらのほうが速度自体はMaxで100IPS程度と低いです。Y軸はカウント数ですので、IPSに直したい場合は0.5掛けて下さい。
 

Surface

拡大写真を載せておきます。
手触りはかなりザラザラしています。通常のすりガラスの"目"を細かにした感じです。
クリックで拡大
・・・写真じゃ分かりませんよね。
「このままでは"Logical"Gamingの名折れっ」ということでそれっぽいデータを出しましょう。

・試験環境
環境 : PSoC Creator 3.0 SP7
センサ : ADNS-5090
MCU : PSoC 4 Pioneer Kit

Register :
RUN_DOWNSHIFT = 0xFF
REST1_DOWNSHIFT = 0xFF
REST2_DOWNSHIFT = 0xFF
AUTO_LED_CTRL = 0b00001110
MOUSE_CTRL = 0b00100100
MOUSE_CTRL_EN = 0x10

・ピクセルアレイの様子
クリックで拡大
コントラスト比はかなり高そうです。
関係無いですが、そろそろピクセルアレイの値を画像化させるソフトを書かないといけないような気がしてきました。

・SQUAL
左右にゆっくり動かした時の値の変化です。
SQUALは一般的な尺度だと良好ですね。マウスパッドとしては普通です。90~105程度をキープ。
ちなみに白い紙だと30~40程度です( ADNS-5090のデータシートより )。値がバタつくのはセンサの仕様です。

個人的な感想

(今まで使用してきたのはAirpad Pro IIIです。)
非常に良いです。適当に買ったのですが大当たりを引きました。
デコピンでマウスパッドの端から端まで滑走するマウスパッドって中々無いんですよね。

そして、Airpad Proで悩みだった動摩擦係数と静止摩擦係数の差が大きく縮まりました。
ここ数ヶ月の間、

マウスパッドの性能とは滑走面の静止摩擦係数と動摩擦係数の差の小ささである

という理論を唱えていたのですが、今回、偶然にも条件に合うマウスパッドに出会えました。
数ピクセル単位のAimingが非常にやりやすいです。持ち運び用にstandardを買おうかな、と考えるくらいです。具体的に言うと、今週は忙しいのにレビューを書く時間を無理やり捻出させるくらいに良いマウスパッドです。
摩耗が少ない ( と思われる ) のもGood。トップクラスに高価なマウスパッドですが、運用可能期間を考えるとかなりお得だと思われます。

気になった点

・音
動かすだけで「ジャー」という音が出ます。ボイスチャットソフトでも拾うくらいの音ですね。
恐らくソールの減りも速いでしょう。

・超高速域におけるトラッキングエラー
咄嗟に後ろを向いた時などに、極稀にトラッキングエラーが発生して下を向く事態に陥ります。通常の速度域では問題なし。ソールの高さがシビアなようです。
ガラス系マウスパッドなので、ほとんどトラッキング出来ないマウスがあるようです。購入の際は慎重に調査することをお勧めします。

・モバイル性
持ち運びがかなり難しいです。400x300[mm]のワレモノなので、手持ちくらいしか方法がありません。しかし手持ちだと落とした場合に破損の可能性があります。頻繁にLANパーティ等に行かれる方は鞄に入る小さい物を買ったほうが良いかもしれません。

・在庫の少なさ
この記事の執筆時点でスベリ7 グリップ1は在庫がないようです。私がラス1を引いたようですね。
サイズと表面のラインナップから考えるに、数十種類の組み合わせがありそうですが、現状では数種類しか通販していないようです。
後、Yahooショッピングで購入したのですが、送料がちょっと高いかもしれません。

2014/06/06

レーザーセンサと光学センサ

レーザーと光学の定義 :
レーザーセンサと光学センサという分類法、違和感がありますよね ( 個人の感想です )。
レーザーとLED、発光方式に違いがありますし、コヒーレンシーの有無での違いもあるのですが、「光」であるのに変わりはないので、「双方ともに光を利用しているので、光学式なのでは・・・?」と毎回考えてしまいます。

この不可解なネーミングの経緯としては、もともとLEDを光源とした光学センサの後にレーザーセンサが出てきたのですが、

・( 従来型のLED光源の ) 光学式センサ
・( 新型の ) レーザーセンサ

この時のデバイス・センサメーカが、「レーザー」という文言を強く押し出した広告戦略が非常に影響していると考えられます。
英語でもOpticalとLaserという括りですが、Opticalという単語に「コヒーレンシーを含まないものを指す」とか定義されているのでしょうか。多分無いですね。

現状の呼称、結構モヤモヤするのでLEDセンサ ( LED Sensor ) と レーザーセンサ ( Laser Sensor ) に変えて欲しいのですが、誰かが変えようとする見込みも無いですし、変わらないでしょうね。
LEDという単語自体、最近は文章的にも工業的にも使用頻度が極端に上昇していてサイバーで未来チックなテイストの単語では無くなってきていますので広報的な意味でのチャンスはほぼ無くなったと言って良いでしょう。

レーザーとLED、どちらがシステムとして優れているのか、というのが疑問なのですが、メーカも双方の方式をラインアップしているあたり、甲乙付けがたいというのが結論なのでしょうか。
厳密にトラッキング面と速度域、解像度を指定できれば確実にどちらかの方式に絞れると思うのですが、コンシューマ向け製品という性質上、それは不可能です。

また、工学的での優劣以外の部分、つまりユーザーの心象や出荷台数、コスト等を考慮すると光学式に軍配が上がります。

日本でほぼ唯一のゲーミングマウスメーカであった(去年解散)DHARMAPOINT的には、大きな差はないものの、レーザーの方がスペック的には優れているという主張でした。その上で、企業としては光学センサのモデルもリリースするというスタンスですね
そう言い切れるに至ったプロセスと詳細が非常に気になりますが、今はもう聞けない悲しみ。
( ダーマ、なんで終わったんでしょうね。やはり遅延騒動が間接的な要因なのでしょうか。 )


以下余談 :
あえて光学式と対比されるのは機械式でしょうか。代表的なものは以下。
・ボールの回転を2軸のエンコーダで変位としてセンシングするボールマウスやトラックボールマウス
・ひずみゲージの電気抵抗値を変位に変換するポインティング・スティック ( 赤いIBM社のトラックポイントが有名 )

後は、タッチパッドやペンタブレット等の、ある任意の領域の静電容量の変化をセンシングしてポインティングを行う静電容量式ですね。


 ゲーミングマウスを日常的に使っているので、光学式が最も優れているとは思うのですが、個人的に、状況次第で優位性があると考えているのは、

・文章打ち込み時などに手をホームポジションから動かす必要のないポインティングスティック
・極めて高速かつ正確な絶対座標でのポインティングが行えるペンタブレット
・腕を動かす必要がなく、接地面に関しても制約が少ないトラックボールマウス

これらの3種です。

個人的に、メカニカルスイッチ+ポインティングスティックを搭載したキーボードはメーカが考え ( リリースされる製品の少なさ的な意味で ) ている以上に需要があるのではないかと思っているのですがどうなんでしょう。安価なら買ってしまうかも。
事務作業において、一般的なユーザは操作に熟練していくとキーボードのみの操作が増えていき、補助的な動作にのみマウスを使用するようになる傾向にあるので、できるだけ腕の移動を省くという思想は必要ではないのかと考えています。
まあ、恐らくそれらを勘定に入れ、コストや諸々のパラメタを考慮した上での判断なのでしょうけど。

2014/06/04

PSoC 5LPと有機ELディスプレイで動画を描画させてみる

先日購入した有機ELディスプレイ(記事)、買った時から動画を表示させたいと思っていたので作りました。
むしろ、表示させるために買ったという表現のほうが正しいかもしれません。有機EL特有の応答速度とコントラスト比は動画で一層優位性が示されると思います。


前回(センサーデバッガ)は詰まる所もなくすんなり完成しましたが今回はそうは行かなかったです。
あの時は秋にやると書きましたが、目の前の諸問題が大きすぎる時、短期で終わるプロジェクトは非常に魅力的なものです。
鉄は熱いうちに打て」と言いますしね :D

 開発後記的な物 ->

目標フレームレート

目標とするフレームレートは30fpsです。
動画の再生は、
データの読み込み → デコード → 転送
によって行われますので、1000ms / 30fps = 33.3ms の間に1フレームの全処理を行う必要があります。

ディスプレイへの転送時間

転送時間は事前の調査(記事)でおおよその見当はついています。
実際に計測した所、最適化の前後の差は、
  最適化前 : 105ms
  最適化後 : 25ms
でした。これは、1024byteのバイナリデータをI2Cの400kbpsで転送した場合です。
"理論値では3.22倍程度の最適化"と書きましたが、アプリケーションでは4倍程度の差がでます。MCUのI2CComponentの処理の減少分でしょうか。
 ちなみに1000kbpsへオーバークロックすることで、転送時間は、14ms程度まで減少します。

動画の変換の必要性

1ピクセル1バイト(0〜255)の輝度情報持ったバイナリデータをmicroSDから読み出すのは約26ms程度必要でした。それをマイコンのCPUでディスプレイに転送可能な二値画像に変換するのにさらに15ms程度必要です。
ディスプレイの転送を最適化したのみで実装した所、14fps程度しか出ません。

1フレームあたり1024byteしか必要ないので、わざわざ8192byteも読み込む必要はありません。事前にエンコードしてmicroSDカードに保存しておけば、デコード時間もなくせますし、転送時間も減らす事ができます。そんなわけでエンコーダーを作ります。

1bpp用エンコーダーの作成

使うのは私だけなので、機能を絞ります。
・1bppでSSDシリーズに直に転送出来るようなバイナリデータを吐き出すだけのソフト
・リサイズ機能なし(事前にMediaCoderでリサイズしておく)
・読めるのはRawVideoだけでいい(MediaCoderで事前に無圧縮フォーマット”.yuv”に変換しておく)
・極力ファイル容量を抑える

バイナリエディタを見ながら実装。BZのビットマップ表示機能がとても便利。


また、閾値の調整にMPCのシェーダー機能を利用していた(気がついたらHSLSがちょっとだけ書けるように・・・)のですが、もともと二値な動画以外は極端に見栄えが悪いことに気が付きました。というか何が映ってるのかよく分かりません。
輪郭抽出して描画させれば良いかな・・・? ということで輪郭抽出はまずHLSLで調整して、Cで実装します。

余談 :
二値の動画がどんな感じか見てみたい人は、下記コードをメモ帳に貼り付けて、1bpp.hlslというファイル名で"C:\ #MPCのインストールフォルダ# \MPC-HC\Shaders"に保存。オプション→再生→シェーダの画面でリサイズ後のシェーダに1bppを追加すると雰囲気が味わえます。
/*1bpp.hlsl*/
sampler s0 : register(s0);
float4 main(float2 tex : TEXCOORD0) : COLOR
{
 float4 c0 = tex2D(s0, tex);

 if (c0.r+c0.g+c0.b < 1.5) {
  c0 = float4(0, 0, 0, 0);
 } else {
  c0 = float4(1, 1, 1, 0);
 }
 return c0;
}


輪郭抽出

フィルタは一次微分(Roberts)を利用。
アルゴリズムとそれに与えるフィルタ(行列)が複数あり、二値化時の閾値も適切に決める必要がありますが、チューンは未定。
極端に低解像度の状況でのアルゴリズムは何が良いのでしょうか。

輪郭の細線化

抽出した輪郭をそのまま二値化すると線が太いことがあります。ですので、細線化(Thinning)を施します。アルゴリズムは、Hilditchですが、これももう少し詰める余地がありますね。

5LPへの移植

今までPSoC 4で開発していたのですが、SD_Card ComponentのUnsupportedな感じがプンプンします。サンプルはあるのですが、Creatorのdefaultに入ってませんし。
不穏だったので5LPへ移行。移植自体はスムーズに進みました。メモリもフラッシュも多く、配線の自由度も高いので非常に楽でした。


・・・弊ブログ、電子工作ブログになりつつあるので、そろそろGamingしていきましょうか。