ミニーのBatteryGraph日記

Treo680のバッテリ問題を解明する為、日記形式で測定データを公開します
この日記は「問題の回避策が見つかる」のか「もう駄目だと諦める」のか、
何等かの結果が出るまで続けてみようと思っております。

■Treo680のバッテリ問題とは
一言でバッテリの持ちと言いましても、これは
・稼動時（本体オン時のバッテリ消耗度合）
・待機時（本体オフ時のバッテリ消耗度合）
 の二つに分けられると思います。

一般的に言って「稼動時」にバッテリを消耗するのは当たり前の事で、
Treo680の稼動時におけるバッテリ消耗度合については、現状では特に問題無いと思っております。

ボクが問題と考えるのは「待機時」におけるバッテリ消耗度合が予想以上に大きいという事で、
これが世間で「バッテリ問題」と呼ばれているものだと思います。

■BatteryGraphとは
BatteryGraphとは、バッテリの残量を記録してくれるフリーソフトで、以下のURLからダウンロード可能です。
http://palm.jeroenwitteman.com/BatteryGraph/

本ソフトを使いますと、例えば以下のようなグラフが得られます。赤線がバッテリ電圧、青線がバッテリ残量％です。
X軸のスパンについては色々指定可能です、例えば以下のグラフは72h（3日）となっております。

ただし、一番役に立ちそうなX軸スパン=24h（1日）については、直近の24時間分しかグラフに出来ません
以下、本日記で取り上げるグラフは、すべてX軸スパン=24h（1日）とします。

■その他用語の説明
素の状態　･･･　待機時におけるバッテリ消耗が、3〜4時間で-1%の状態を指します（これがTreo680本来の姿？）
DP1号、2号など　･･･　ボクが試作中のパッチのようなものとお考えください
※試作中のものは、ハッキリした効果が確認出来るまで、公開しませんのでご了承ください
※パッチの類など使わなくても、運用だけで逃げれる可能性も探ります

↓↓↓↓↓　ここから日記の始まり　↓↓↓↓↓

★★★　測定データ　2007.01.20　★★★


昨日、Palm本家からリリースされた カメラパッチの検証を行いました。

カメラパッチを適用したのは、昨日の17時ごろです
適用後カメラを起動、写真を数枚撮影して電源を切りました。
検証はBluetoothオフの状態で開始、グラフの最初は「素の状態」を維持しております。

本日の夜中2時ごろBluetoothをオンにしました、予想通り消耗度合いが悪化しています
この部分、グラフから読み取りますと、1時間につき-0.6％程度の消耗になってしまいました

※どうやらカメラパッチを適用しても、バッテリの消耗度合いは
※以前の「カメラを使用しない」状況と同等で、これ以上は良くならないみたいですね

[測定条件]
充放電サイクル　15回目
Bluetooth　オフ、途中からオン
赤外線　オフ
その他　カメラパッチの効果確認

[カメラパッチの解析]
今回修正されたライブラリCameraLib-camL.prcについて中身の解析を行いました。
新旧ライブラリの差分比較をすることで、追加された処理部分を抽出してみました。

■追加部分1
起動コード sysLaunchCmdInitialize (0x7ffe)のイベントプロシジャ冒頭部分
自分自身をプロテクトしてますね(ROM焼きではなくRAM上のパッチだから？)
この追加部分はバッテリの消耗とは無関係です。
00001908 e28f0030 	add	r0, pc, #48     // const Char *nameP "CameraLib-camL" (pc相対)
0000190c eb002348 	bl	$0000a634       // DmFindDatabase
00001910 e3a01001 	mov	r1, #1		 
00001914 eb002344 	bl	$0000a62c       // DmDatabaseProtect

■追加部分2
詳細不明です(カメラモジュールへの制御コマンド発行部分？)
手がかりは引数(r0,r1)とファンクション$0000855cと$000084fcの役割ですね
00006110 e3a01004 	mov	r1, #4
00006114 e3a00001 	mov	r0, #1
00006118 eb00090f 	bl	$0000855c
0000611c e28d1004 	add	r1, sp, #4
00006120 e3a00027 	mov	r0, #39
00006124 eb0008f4 	bl	$000084fc
00006128 e1dd00b4 	ldrh	r0, [sp, #4]
0000612c e3c00004 	bic	r0, r0, #4
00006130 e1cd00b4 	strh	r0, [sp, #4]
00006134 e1dd10b4 	ldrh	r1, [sp, #4]
00006138 e3a00027 	mov	r0, #39
0000613c eb000906 	bl	$0000855c

■追加部分3
ここも詳細不明です(カメラモジュールへの制御コマンド発行部分？)
引数(r0,r1)とファンクション$0000855cと$000084fcを呼び出す順番が追加部分2とは異なってますね
※追加部分2と3ですが、どちらかが open で、どちらかが close のような気がします
00006390 e1a0100d 	mov	r1, sp
00006394 e3a00027 	mov	r0, #39
00006398 eb000857 	bl	$000084fc
0000639c e1dd00b0 	ldrh	r0, [sp]
000063a0 e3800004 	orr	r0, r0, #4
000063a4 e1cd00b0 	strh	r0, [sp]
000063a8 e1dd10b0 	ldrh	r1, [sp]
000063ac e3a00027 	mov	r0, #39
000063b0 eb000869 	bl	$0000855c
000063b4 e3a01004 	mov	r1, #4
000063b8 e3a00001 	mov	r0, #1
000063bc eb000866 	bl	$0000855c

ホントにこれだけの修正で大丈夫なんでしょうか？(←まだ心配らしい）

★★★　測定データ　2007.01.03　★★★


念の為に本日も昨日と同じ検証を行いました
ご覧のように「バッテリ問題の根本原因はカメラに有る」という情報は、間違い無いです。

検証内容の説明です
昨日は約7時間分のデータしか取れませんでしたので、もう少し長時間にしました。

まず「バッテリの完全放電」を行ったあと一気に満充電しました。
その後、わざと74％程度まで「強制放電」させたところからスタート、時刻は夜中の3時頃です。
グラフの最初は「素の状態」を維持しております。
朝の8時頃にカメラを起動し、写真を10枚程撮影して電源を切りました。

その後はご覧の通り、昨日同様、待機時のバッテリ消耗が急に悪化しました。
この部分、グラフから読み取りますと、1時間につき-1.2％程度の消耗になってしまいました
「素の状態」が-0.2％ですので、約6倍になったようです。

[測定条件]
充放電サイクル　9回目
Bluetooth　オフ
赤外線　オフ
その他　カメラの使用前後の状況確認

[ここまでのまとめ]
この日記の目的であった「問題の回避策を見つける」という件と「残る疑問点」についてまとめます

■問題の回避方法
バッテリの完全放電を行ったあとは、カメラを使わない
※ApplicationsPanel というアプリを使わせて頂き、カメラアプリのアイコンを非表示にしましょう

参考リンク：右脳先生の荒業

■残る疑問点
（１）これで突発的な消耗事故（12/30の日記参照）は防げるのか？
※これについては、ホントに稀な現象でしょうから、暫く運用してみないと何とも言えないですね

（２）バッテリ問題の原因はカメラ以外にも有るのでは？
※今回、カメラ使用後は「1時間につき-1.2％の消耗」という具体的な数値は取れましたが、
※実際にはもっと悪い状況も有ります。これを、どう説明しましょうか？
※（ボク自身も購入当初は、-2％近く消耗していました･･･）


【お知らせ】
という訳で、本日で一旦、この日記をクローズしますね。
ボクとしては、ここ半月以上「高価なバッテリ検証器」になっているTreo680を
そろそろPDAとして、必要なアプリを全部入れて、実運用してみようと考えております。
※と言いながら本心は、早く中身を解析して遊びたいです。（＾＾）おバカさん
運用して行く上で、バッテリに関する新たな「問題点」や「回避策」が見つかりましたら、
その時は、またここでお知らせしたいと思います。


★★★　測定データ　2007.01.02　★★★


皆様、新年明けましておめでとうございます。
本年も宜しくお願い申し上げます。

「1/4から日記を更新します」と予告しておりましたが、
今朝 1SRC を覗いてみると、とても気になる書き込みを発見しました。
その書き込みの趣旨は「バッテリ問題の根本原因はカメラに有る」という内容で
これを読んだ瞬間、ボクにも心当たりが有りピンと来ました。

そのような訳で、急遽予定を繰り上げ、本日から日記の更新を始めたいと思います。
※お正月早々、ボクも相当なおバカさんですね（笑）

この情報の信憑性を確かめるため、早速検証してみました。
結果はご覧の通り、見事にこの情報通りの結果を得る事が出来ました。

グラフは本日の朝8時頃から始まっております、最初は「素の状態」を維持しております。
次に、お昼の12時過ぎにカメラを起動し、写真を10枚程撮影して電源を切りました。
その後はご覧の通り、待機時のバッテリ消耗が急に悪化しました。

※急な事でしたので、グラフのデータは約7時間分しか有りません

半月以上悩み続けた「バッテリ問題」の正体は、どうやらコレだったみたいです。
明日も更に同様なテストを行い、確かな「裏付け」を取りたいと思います。

[測定条件]
充放電サイクル　8回目
Bluetooth　オフ
赤外線　オフ
その他　カメラの使用前後の状況確認


★★★　測定データ　2006.12.30　★★★


う〜ん、予想外の結果が出てしまいました。( ´・ω・`)
事前調査では、Bluetoothをオフにしても「素の状態」に戻せなくなる現象は
Bluetoothで通信を行った後に起こる、と予想していたのですが･･･

気を取り直して、本日の検証内容の説明です。

まず今朝、Bluetoothをオンにして、Blazerを起動し約10分間ブラウジングを行いました、
その後、ネットワーク接続だけ切断し、Bluetoothはオンのままで本体の電源を切りました。

そのまま放置して、お昼頃にBluetoothをオフにしました。
注目するのは、この後の部分です。。。「素の状態」に戻っちゃいましたね

※本当は「素の状態」に戻らないと予想しておりました。
※「残酷なまでにグラフは正直」であります。

これはまずボクの頭の中を「素の状態」に戻す必要が有るみたいです

[測定条件]
充放電サイクル　7回目
Bluetooth　オフ→オン→オフ
赤外線　オフ
その他　特に無し

[ここまでの感想など]
大変厳しい表現で恐縮なのですが、
ボクは、今の状態でTreo680をメインマシンとして運用する事を
「欠陥車を運転するようなもの」というイメージで考えております。
欠陥が原因で、いつ事故が発生するかも知れません。

・欠陥＝もちろん「バッテリ問題」です
・事故＝1時間に-15％も-30％もバッテリを消耗する突発現象です （本日の右脳先生の記事参照）

ただ自動車と違い、人命に関わるような大事故にはならないでしょうから
騙し騙しの方法でも構わないので、なるべく安全に運用出来る術を
もうしばらくの間、この日記で探って行こうと考えております。

さて、年内の更新は本日をもって終了です。
次回の更新は、年明け1/4からを予定しております。

本年も「ミニーの資料室」をご覧頂き、誠にありがとうございました。
皆様、どうぞ良いお年をお迎えください。

来年につづく


★★★　測定データ　2006.12.29　★★★


今日から本業の休みが始まりました、まずは【お知らせ】です。
12/31〜1/3迄「ミニーのBatteryGraph日記」の更新はお休みします
※お正月ぐらい、ゆっくり休みましょうね

それでは本題です。
昨日「素の状態」からBluetoothをオンにてみると、グラフに一時、妙な変化がありましたが
本日の朝はご覧の通り、傾きが一定となり安定しておりました。

どうやらBluetoothをオンにした事で「素の状態」が終わってしまったようですね
この部分、グラフから読み取りますと、1時間につき-0.6％程度の消耗になってしまいました
「素の状態」が-0.2％ですので、約3倍になったようです。

※-0.6％がBluetoothオン時の「素の状態」じゃないのか？という疑問も残りますが
※これについては、後日検証する事にしましょう。

じゃあここで、もう一度Bluetoothをオフに戻せば「素の状態」に戻せるのでしょうか？

早速やってみましたところ、
ご覧の通り、Bluetoothをオフに戻せば見事に「素の状態」に戻す事が出来ました。

※実は「素の状態」とBluetoothオン/オフの関係は、この日記を始める事前調査の段階で
※何となくぼんやりとですが、把握をしておりました。
※本日は、予想通りのグラフが得られて、内心ホッとしました。（＾＾；）

それでは皆さんにお尋ねします。
どんな場合でもBluetoothをオフにすれば「素の状態」に戻せるのでしょうか？

色々試してみました結果、必ずしもそうだとは言い切れないのです。
明日は、この件に関して検証してみます。

[測定条件]
充放電サイクル　7回目
Bluetooth　オン途中からオフに
赤外線　オフ
その他　特に無し


★★★　測定データ　2006.12.28　★★★


昨晩あれから、Palm Insider Pro の機能を使って、本体自動オフタイマを無効にし
バックライト輝度最大の状態で、そのまま2時間少々放置。。。
バッテリ残量が57％になったのを確認して元に戻し、本体の電源を切って寝ました。

それで結果はご覧の通り、残量50％付近においても、昨日と同様な「素の状態」を再現出来ました。
つまり、「素の状態」は満充電付近にだけ起こる現象では無いという事が、これで証明されたと思います。
※グラフ上で「素の状態」の部分は約15時間です
※15時間を通しての消耗は-3％でした（5時間につき-1％) ← 昨日と同じ結果ですね
※Treo680の「残量％表示値」は、結構リニアに変化しており、信頼出来そうですね

これ以上放置しても、ず〜っと「素の状態」が続くであろうと判断し、
次にBluetoothをオンにしてみました。（Bluetoothは12/25以降ずっとオフでした）
するとグラフの様に、ちょっとおかしな変化を示しました。

Bluetoothをオンにした瞬間から、グラフの傾きが少しだけ急になったなと思っていたら
時が経つにつれて、だんだん緩やかになって来ているようで･･･
まるで「素の状態」に自己復帰するために頑張っている様にも見受けられます
面白いので、このまま翌朝まで放置して、どうなるのか確認したいと思います。

[測定条件]
充放電サイクル　7回目
Bluetooth　オフ途中からオンに
赤外線　オフ
その他　特に無し


★★★　測定データ　2006.12.27　★★★


素の状態　キタ━━━━(ﾟ∀ﾟ)━━━━ッ!!!!

日記を始めて4日目、ボクが申し上げておりました「素の状態」を本日確認出来ました。
まず、昨晩行った事を書きます
・バッテリの完全放電を行なってから一気に満充電しました
・その後、RescoBackupで保存した12/24の環境に戻しました
・本体電源を切って寝ました
やった事は、ただこれだけです。

本日は年末の雑用でバタバタして、ほとんど本体に触れる時間が有りませんでした
それが幸いしてか、ほぼ理想的な「素の状態」のグラフになっております。
※昨晩寝たのが遅かったため、約20時間分のデータです
※20時間を通しての消耗は-4％でした（5時間につき-1％)

それからDP2号の効果のテストも行いました
どうも効果が無いみたいですね、あと1回テストして駄目なら保留にしましょう。

これから、無理矢理にバッテリを消耗させてみます
残量50％付近においても、本日と同様な「素の状態」を再現出来るか、明日テストします
これはTreo680の残量％表示のリニアリティ（直線性）の検証も兼ねております。

[測定条件]
充放電サイクル　7回目
Bluetooth　オフ
赤外線　オフ
その他　DP2号有り途中から無しに


★★★　測定データ　2006.12.26　★★★


昨日の日記に書くべきでしたが、12/24と12/25の間に3つのアプリを追加しており
その内、2つが常駐アプリでした
KeyQuickについては昨日調べた通りの結果でした、本日はもうひとつの常駐アプリ
dmitrygr君のUDMHについて調べてみました
ただし、UDMHのオン/オフ切り替え機能には怪しい部分が有り
オフにする機能は使わず、ラウンチャでバッサリUDMHを削除後リセットしました
※おそらくオフ時に、ジャンプテーブルの書き戻し忘れてるのかな？

結果はご覧の通り、UDMHもバッテリ消耗には無関係だと思われます。
※dmitrygr君、疑ってごめんなさいね（って日本語で書いても読めないね）

次に、DP2号の効果を確かめる為、無効にしてみました
う〜ん、これは効果無しという事でしょうか･･･
本日は全く良いポイントが有りませんでした
とりあえず、明日はRescoBackupで保存した12/24の環境に戻してみますか。

[測定条件]
充放電サイクル　6回目
Bluetooth　オフ
赤外線　オフ
その他　UDMHオン→途中から削除、DP2号有り途中から無しに


★★★　測定データ　2006.12.25　★★★


DP1号にプログラミング上の不具合が見つかった為→DP2号に
DP2号は終日有り、常駐アプリの影響も否めない為、KeyQuickのオン/オフでの変化を調べました
結果、KeyQuickは無関係だと思われます。
それからBluetoothをオフした直後の1ヵ所だけ気になるポイントが有るが、
全体的にイマイチの結果でした。
昨日より、待機時消耗度合いが悪化しているのが気になります。

[測定条件]
充放電サイクル　6回目
Bluetooth　オン→途中からオフに
赤外線　オフ
その他　DP2号有り、KeyQuickオン→途中からオフに


★★★　測定データ　2006.12.24　★★★


赤矢印の区間、素の状態に近い？
DP1号の効果が有る様にも見えるが、これは偶然の結果かもしれない

[測定条件]
充放電サイクル　5回目
Bluetooth　オン
赤外線　オフ
その他　DP1号有り→途中から無しに


Copyright 2006. Mini's materials room. OSAKA JAPAN

[戻る]