[an error occurred while processing this directive]

[an error occurred while processing this directive]


カレンダー

2009年10月
       
10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

2009/10/7(水)

GPS熱が暴走。そしてGoogleバーコードで予想外の苦戦。

●「Fen」(LR700/8E)延命計画考察

昨日からやってたmemtest86+はエラーなし。本運用再開。
eBoostrシステムメモリキャッシュを384→768MiBに拡大。

メモリは無事限界突破して2GiBになったが、残る弱点であるHDDの遅さはちょっと改善が難しい状況だ。
eBoostrなどで見かけ上高速化することはできるが、根本的な解決には換装しかない。
だが、2.5インチPATA HDD自体が少なくなっているし、容量には不満がないので高速化に絞って考えると回転数の多いものが欲しいが、7200rpmはすでに入手困難。
5400rpmでも少しは速くなりそうだが(単純計算で約28.6%高速化)…。
クラッシュ防止のために予防的換装を行うという手もあるが、延命にあまりコストをかけたくない。
やはりあと1年ぐらいが限度かもしれないな。とりあえずこれから出る新製品には目を光らせておこう。
…まあ、ソフトウェア面での役割移行がうまく進めば、「Fen」にそれほどスペックを必要としなくなるのであと2年は使えそうだが。

●Googleロゴが読めない問題

朝。
Googleのロゴがバーコードになってるのを発見。
手持ちのバーコードリーダーでも読めないし、携帯電話(W62CA)の読み取り機能も認識せず。

---

帰宅後。
大学で印刷してきたGoogleのバーコード、読んでみたけどアウト。
念のため自宅でも印刷しなおしたがやはりアウト。
でも読めるらしい↓
Googleのバーコードを読み込んでみた
…比率が悪いんだろうか。コントラスト?
タグに「CODE128」とあり、手持ちのバーコードリーダーはCODE128読めるはずなのだが。
もしや大きさが悪いのか?と思って、70%、80%、90%、110%、125%のコードも読ませてみたがアウト。
CODE128自体が読めることを確認するため、WikipediaのCODE128記事にあるバーコードを読んでみるとおk。しかもディスプレイ上で。
一体何故読めないのか?実は意外なところに原因はあった。

朝最初に見たときから、どうもバーコードが変だと思っていた。
普通、バーコードは白と黒なのに、なぜか灰色などの中間色が混じっている。印刷したものもバーが不鮮明だ。
ここで、先ほど見た動画ではバーコードが中央部に表示されていたことを思い出す。
中央…ヴぁーーーーーーーーーーー!iGoogleじゃない!!
そう、私は普段Willcom情報を執拗に追跡するため、Willcom関係のサイトRSSを6個も登録したiGoogleをGoogleの標準ページにしている(※)。
もちろん最初にバーコードを発見したのもそのページ。
当然ながら印刷したのもそのページ。言うまでもなく拡大縮小したのもそのページ。
そして、普通のGoogleトップ(Google ホーム)を表示させて読んでみると一発おk。しかも「Naoko」(NB100/H)の液晶上で(上記動画では液晶上では読めていない)。
より詳細にみると、Google ホームのバーコードURLはhttp://www.google.co.jp/logos/barcode09.gif、iGoogleのバーコードはhttp://img0.gmodules.com/logos/barcode09_res.gif。全くの別物である。
まさか、Googleの機能をより深く使っているがゆえにこんな目にあわされるとは思っていなかったよ。

※:その前は約定期日記、約定期blog、アキバblogと、最初から用意されていたニュースRSS3つを登録したiGoogleを標準ページにしていた。結局iGoogleに変わりはない。

●ニコニコ動画

【寝下呂企画】magnetを普通に歌ってみたはずだった【ねる×Gero】
毎回このカオスっぷりが面白い。次もあるかな〜?

帰りにニコstack消化。
以前にキャッシュしてあった分があるのでEMチャージは使わずAIR-EDGEで。
九度山あたりでキャッシュが切れたのでEMチャージ使って続きを視聴しようかと思ったが、微妙に時間が足りなさそうだったのでやめておいた。

ニコ割ゲーム。カート。20460点。センター維持で連打し、障害物来たら回避する作戦でやってみた。
それでも結構ぶつかってしまったが…。
そういえばいつの間にか結果発表が30分後になってる。前は10分だったんだが。
結果…849/61985、1位27980、100位23650。久しぶりの3桁。ノーミスだったら100位以内に入ったかもorz。

●モバイル

なんとなくD11LC接続してAT+CSQで電波強度調べたら奇妙なことが。
圏外なのでてっきり99,99になるのかと思ったら、何故か18,1とか18,3とか返ってくる。
RSSIは18固定?で、BERが1〜4ぐらいの範囲のようだ。
もちろんLEDは赤点滅、ユーティリティも圏外表示(実際には「検索中...」がほとんどだが)。
もしかしてD11LCはAT+CSQで受信状態を計測することは不可能なのか?

Willcom、-42200(PHSのみ)か。CORE 3Gも鈍ってるな。
emobileは+88200で、チャージは2300。そのうちの1は私だな。
それにしてもEMチャージ少ないなぁ。やはりわずか数百円をケチるために面倒なチャージ管理をしたくないってことか。

docomoの速度低下がひどくなってる?乗り換えはLTE待ちかな。でも和歌山に来るのはかなり先だろうな。

●GPS(位置情報)

電車でGPSテスト。
直付けや3Dコネクタじゃ受信状態が悪く「やはり雨じゃ無理か?」と思ったが、延長ケーブルで窓と日よけの間に挟んだら8〜9衛星捕捉してHDOP1.0(9衛星時)。
その後の調査で、条件が最良でも11衛星ぐらいが限界っぽいことが判明。時間によっては6衛星程度ということも。つまり9はかなり好条件。
また、7衛星でも配置によってはHDOP1.0になるし、HDOPは1以下にもなる。

GPSについて調査していて、LORANという位置情報システムがあることを知る。
原理的にはGPSと同じように、基地局からの電波を受信して受信遅延から基地局との距離を計算し、現在位置を求めるというもの。
…これPHS基地局で似たような事できないか?
まあ、陸地では地形の影響で無理だろうなぁ。LORANも基本的に船舶・航空機(海上)用らしいし。
それ以前に基地局に原子時計とか搭載するとコスト上がりすぎるか。
電波強度使う方法(※)なら追加コスト0だが、精度がタコなんだよな。。
※:ATコマンドでCSIDと電波強度取得→あらかじめ用意したCSIDと基地局位置のDBから現在位置を推定。

auのW04KにはGPSが搭載されてるらしい。他にもWWAN搭載PCにはGPSも搭載されていることがある。
これから外付けデータカード出すんだったらGPSも搭載してくれるといいな。でもあまりコストアップするのは困るが。

GPSの民間用コードはそれほど精度がないのに、何故数mm単位の地殻変動が分かるのかということだが、あれはレシーバの位置情報自体を用いるわけじゃないらしい。
詳細は「GPS 測量」とかでぐぐれ(ぉ)。

UMGPSで研究室の位置情報を計測。
lat N 34°16'04.009
lon E135°09'04.957
alt 104.96m
2drms 19.58m(H),26.19m(V)
count 5211(H)/5200(V)
time 3:30:45

●大学

13:05頃研究室。

来週月曜日に点検のため大学全体が停電するらしい。

GPSなどの調査やメールチェックしてたらもう16:42orz
途中、友人が来たので雑談など。

研究対象などをまとめるが、実際のプログラム作成や実験には至らず。やヴぇぇ時間がない。
しかも後日、研究テーマ自体に致命的な問題があることが判明。もうだめぽorz。

●今日の出来事

1:3x頃寝る→6:45頃起きる。

朝飯は総菜パン。

昼飯はケンタッキーでチキンフィレサンドセット。今回は少し寒いと思ったのでホットミルクティにした。

帰りに番組視聴してたら、「Naoko」(NB100/H)のバッテリが異常に減ってるのでGPSレシーバが原因かと思ったが、なんとAMOS側のケーブルが抜けてた(ぉ)。
下古沢駅付近のトンネルですごい風。

晩飯はラーメン。

台風による停電に備えて「Fen」にバッテリ装着。
ニュースで台風情報確認。
「Naoko」にMP630のドライバ入れる。

[[an error occurred while processing this directive]][[an error occurred while processing this directive]]