Archive for the ‘PC・技術’ Category

4/16の日記より(少し改変)

久しぶりに"Let it be"(2009リマスター)。当たり前だが、中学の頃聴いたレコードよりずっと音がいい。細かい音まではっきり聞こえて、いつも感動する(ありがたく思う)。ところが、今は、音が悪いうえに手間も掛かるレコードを好き好んで買う人が居るのが不思議だ。。。

レコードの音や雑音がいいのなら、レコードじゃなくたって、(あるかどうかは知らないが)レコードの音にするエフェクタ・シミュレータでいいではないか。レコードを掛けるために手間を掛けるのがいいのか。レコードはコーヒーじゃないので、手間暇掛けて掛けること自体に意味はない。たとえ高速回転の高音質盤を買い込み、クリーンルームで再生して、最高の結果が出せたとしても、マスターの音には全然敵わない。そもそも、今はカッティングに使っているマスターがデジタルなのに、それをまたアナログに変換して(、ピチパチ雑音と一緒に)聴きたいっていう気持ちが理解できない。段階が増えれば、それだけ音質は劣化する(レコードの場合、物理的に転写する工程があるから、かなり劣化すると思う。CDも転写するが、エラー訂正があるから、レコードの比ではない)のだが、それがいいのか?

仮に、「レコードは掛け方・機材で音が変わるのがいい」とか言うのなら、それは全くおかしい。そんなのだったら本当にエフェクタで充分だ。その方がずっと自分の出したい音が出せる。コーヒーの淹れ方で香りや味が変わるのは本質的だが、掛け方や機材でレコードの音を変えるのは全然違う。

あと、面を裏返すのや盤を入れ替えるのは鑑賞の妨げにはならないのだろうか。音楽を楽しむのなら、音質(仮にいいとして)だけじゃなくて、演奏に集中できることはかなり重要だ。例えば、本来は短時間で繋がるべき(あるいは曲間なしで連続する)楽章や曲の間が何分も中断してもいいのだろうか? 謎だ。余程の物好きだ。インスタ映えみたいに、レコードを掛ける自分の姿に酔いたいのだろうか。もしかして、「掛ける体験がいい」とか言うのかw そんなに体験がいいんだったら、楽器を買って自分で演奏しようとした方がずっといいよ。

せいぜい、大きなジャケットが欲しいからレコードを買うのはありだろうが、ジャケットだけでも手に入れられるだろうし(それ以前に、今はいくらでも画像が出回ってそうだ)、曲はCDや(ハイレゾ)配信で聴けばずっと楽ではないか。

いずれにしても、そういう人たちは音楽を楽しむことが主目的ではないようなので、僕は全然共感できない。そして、ブームに乗って安直に手を替え品を替え(45回転盤、重量盤、カラー盤、復刻日本盤・帯w, etc.)レコードを出すレーベルは全く情けない限りだ。

 

PS. レコードの音にするエフェクタ(またはシミュレータ)はあった(WebLP)。カセットのも見付かった(WebCassette)。どちらもブラウザ(Chrome)で動くし、カセットはVSTなどのプラグインになっているから、本当の再生にも使える。ただ、僕からすれば、レコードは音質が良過ぎる(雑音が少ない。ただ、歪は多過ぎる)し、カセットは悪過ぎる(いろいろなつまみを高品質側に回して、CHROMEかMETALポジションでないとちょっと・・・: デジタルに慣れ過ぎているせいかも知れない)感じでまだおもちゃ的で実用には物足りないが、もっといいものはできるだろう。

あと、WIN32用なら、Vinylizerというレコードシミュレータがあった。これはVSTプラグインなので、本格的に使えるだろう。

更に、Calf Studio Gearにもレコード(Vinyl)とカセット(Tape Simulator)のシミュレータがあった。だから、Linux(JACK)でもできる。こちらはいろいろ調整できるが、やっぱりどこか不自然で納得行かない。もっとちゃんとシミュレートしないと実用には耐えないと思う。JACKにはVyNil (Vinyl Effect)というのもあり、Calfよりはマシだがやっぱり物足りない(というか、僕はもう、そういう音を受け付けない身体なのかも知れない)。

そういう意味では、手軽に自然なレコードやテープの音を出すには(それに意味があるとして)、本物のレコードやテープを使う価値があるのだろうw

そして、(仮にまともなシミュレータがあったとしても、)もちろん僕は、「使ってみますか?」→「まさかー」だw

PS2. さっき噴飯物を見つけた。妙にレコードに力を入れている店、HMVの「ブラックヴァイナル・アナログレコード」って、普通のレコードじゃん!! なに気取ってんだよw しかも、見出しは字が抜けてるし。こういうのを中学生くらいの子が見ると、なんか特別な物のように思ってつい注文するのだが、届いた実物を見てがっかりするのだ(僕の経験よりw)。 (4/19 17:41)

「ブラックヴァイナル・アナログレコード」か・・・w

(「志向・趣味の違いか。 (その2)」(投稿予定)の前半にする予定だったが、繋がり・まとまりが悪いので単独で投稿)

  •   0
  •   0

前回追記したように、新たなWi-Fi節電アプリを2つ見付けて試した。一個(Wayfi - Automatic WiFi Toggle Service (2018))はGPSの位置情報でWi-Fiのon/offを判定するものだが、前回も書いたように、室内では位置が安定せず、たびたびon/offするので本質的に良くないと考えて却下し、もう一個(Wifi matic (2017))を試した。機能的にはその前に使おうと思っていたWifi Automatic (2018)と同様に、APがない時にWi-Fiを間欠的にon(通常はoff)するものである。

APがない状態で、Wi-Fiを連続onした場合とその2つのアプリ(Wifi maticとWifi Automatic)でWi-Fiを間欠onした場合、更に、APがある状態でWi-Fiを連続on(かつAPに接続)した場合の電力消費率を比較した。

はじめは、より実使用時に近い値を得ようと、外を歩いて往路と復路でWifi maticをon/offして効果を確認しようとしたのだが、どちらも消費電力が小さくて、片道40分程度(最初は30分程度を考えていたが、全く電池が減っていなかったので追加した)では確度の高い値が得られなかった。それ以上歩くのは大変だったので、室内で外出時を模擬した条件で長時間放置しての測定も行った。以下に結果を示す(過去のデータも利用している)。以下では、測定中はほぼ操作をしていない。

外を歩いて測定 (Wi-Fi APなし)

  • Wifi matic off (連続on): 1.5%/h (約40分間)
  • Wifi matic on (間欠on: 15分に1回on): 1.2%/h (約40分間)

→ WiFi matic on(間欠on)の場合、連続onよりも電力消費率が0.3%/h程度少なくなった。

室内での測定 (Wi-Fi APなし/あり)

  • Wi-Fi APなし
    • WiFi matic off (連続on): 0.67%/h (約3時間)
    • Wi-Fi 間欠on
      • WiFi matic on (15分に1回on, APなし): 0.43%/h (約2.3時間)
      • Wifi automatic on (15分に1回on, APなし): 0.57%/h (約3.5時間)
  • Wi-Fi APあり, 接続あり
    • WiFi matic on: 0.57%/h (約3.5時間)

Wi-Fi APがなくて接続できない場合、Wi-Fi間欠onでは連続onよりも電力消費率は0.24%/h程度減り※1、Wi-Fi接続時と同等か少し小さくなる※2。間欠onのアプリ(WiFi maticとWifi automatic)同士の差は0.14%/h程度と、わずかである。

※1 この結果は、前回の最初の見積もりの「Wi-Fiは平均0.21%/h (中略) 消費していると考えられる」と合う(ただし、減った量は見積もりより大きい)。

※2 Wi-Fi接続時の電力消費率がAPなし(Wi-Fi連続on)時より小さいのは、後者はすべての通信(同)をモバイルで行うために、使用していないWi-Fiの分と合わせて消費電力が大きくなる一方、前者はほとんどの通信(インターネット関連)をWi-Fiで行うために消費電力が小さくなるからではないかと推測する。ただ、モバイル通信もそれほど電気を食わないようで、差は0.1%/h程度でしかない(無操作だったため、通信量が少ないせいもあるだろう)。

結局、外でも室内でも、Wi-Fi間欠onで削減できる電力消費率は0.5%/h未満であることは確かだ。

仮に外出時の平均電力消費率を2.5%/hとして、Wi-Fi間欠onにして0.5%/h減るとすれば、電池を全部使った場合には約10時間長く使えることになるが、実際には0%までは使えないので、高々6-8時間程度の伸びであろう。更に、実際の平均電力消費率はもっと大きく(3.5%/h?)、Wi-Fi間欠onによる削減量はもっと少ない(0.25%/h?)から、実際の伸びは1.5時間くらいにしかならないのではないだろうか(それでも、いざという時には結構ありがたい?)。

また、後で消費電力測定アプリ(AccuBattery)の結果を見て分かったのだが、Wi-Fiよりも画面on時の消費電力がかなり大きく、画面on時はoff時の40倍近かった(例: 画面on時: 19%/h, off時: 0.5%/h)。バックライト自体の電力以外に、アプリが動くせいもあるかも知れない。いずれにしても、Wi-Fiで消費電力を減らそうとするのは効果的でなさそうだ。

以上より、Wi-Fiを間欠on(通常off)にするメリットは余りなさそう(つまり、気にする必要はない)である。ただ、自宅以外にWi-Fi APがある場合(お店など)、それらのAPを認識して無駄に接続しようとして電気を食う可能性があるのと、常時onの場合、画面をonするたびにWi-Fiが起動してAPをスキャンしたりして電気を食う可能性があるので、間欠onにした方が若干いいことが期待できる。が、残念ながら、上記の画面onでの消費電力の増大を見ると「気分の問題」という印象は強い※。

※結局、今は、「折角やったんだから」、「気分だけでも下げよう」という思いで、WiFi maticで間欠onにしている。

そして、なぜ、Wi-Fi間欠onにしても消費電力が減らないかを考えると、可能性としては、以下のことが考えられる(いずれも推測)。

  • 今のWi-Fiチップはそもそも消費電力が低い。
  • AndroidがWi-Fiチップをうまく制御して消費電力を下げている。
  • 僕のスマフォ(AQUOS sense lite)のWi-Fiチップはアイドル状態が長くなると勝手に停まるような、独自の省電力機能があるために、平均消費電力が低くなっている。

という訳で、がっかりな結果ではあったが、まあ、モバイルの基地局でWi-Fiをon/offするプログラムを作る意味がないことが分かったのは、徒労が省けたという点で収穫と言えそうだw

PS. 消費電力測定アプリについて: 3C Battery Monitorは全画面広告が突然出て(他のアプリを使っていても出る!)鬱陶しいので止めて、GSam Battery Monitor, My Battery Monitor, AccuBatteryを併用している。GSam Battery Monitorはグラフが出るので一覧性が良く、My Battery Monitorは電池残量などの履歴が数値で出るので、細かく調べるのに良い。AccuBatteryは全体的な状況を見るのに良い(が、それほど有用でないので削除した)。

PS2. 関連するアプリを(散々)検索して思ったが、節電をうたうのはまだしも、充電時間の短縮とか電池・スマフォの冷却とか、果ては劣化した電池の回復とか太陽光での充電なんてのをうたうトンデモアプリが多くて笑った。引っ掛かる人は多そうだが、入れるとどうなるのか、結構怖い。

直接は関係ないが、「しょうもないアプリ」の簡単な見分け方として、名前やアイコンに年号(今なら"2019"。古いままなのは論外w)や"HD"(なぜか、カメラだけじゃくて電池関係にもある)が入っているのは、大体イマイチ(害がないことが多いが、他のアプリの「異名同曲」)な気がする。

なお、本文中の()内の年号はアプリ名ではなく、僕が追加したものである。

  •   0
  •   0

積年のストレスが爆発寸前だったので、このブログのドメイン名(piulento.net)の登録業者(レジストラ)をお名前.comからGoogle Domainsにした。

移管先の検討

今までのお名前.comへの不満を以下に書く。

  • ウマシカ仕様で、すべてのことにイライラする。
  • 料金: 安くない(.netドメインの更新料: 1598円/年 (税込み、以下同))。
    • 最初(1年目)は少し安かったのでここにしたのだが、2年目(更新)以降は値上がりした(価格表には書いてあったが、その後値上がりした気がする)ので騙された気分になった。
  • 設定画面(web)が分かりにくいうえに遅い。
    • どこをどうすればいいか、とにかく分からず(直感的でない)、設定する時はいつも不安になるし、間違いやすい。何も考えないで作っていそうだ。逆に、人をイライラさせようとして作ったのなら、天才の作品だ。
    • 無駄な装飾(例: プログレスで丸いのが延々とぐるぐるする。ログインするだけでも、これで何秒も待たされる。一体何をしているのか知らないが、「そんなことする暇があったら1秒でも速く表示しろ!」って言いたい)が鬱陶しい。余程センスのない人が作っていそうだ。
      • ↑思い出した。OCNの管理画面(マイなんとか?)も同様に遅くてイライラするから、なるべく使いたくない。ガラパゴスの似たもの同士なのか。
    • ドメイン名の更新時期が近いせいか、ログインすると勝手に更新ページが開かれるのも鬱陶しい。全くセンスが悪い。
    • 有料サービスでも料金が書いてないことが多い(例: ボタンを押すと料金が発生する時に、料金が出ない)ので、うっかり課金されそうになる。
  • 連絡メールが紛らわしい。さらっと有料サービスに誘導する。
    • 「【重要】[2件]の管理状況について」という題のが来て、詐欺か、本物なら一体何があったかと思ったのだが、中身は単に「登録情報の確認しろ」だけ。最後にそれに絡めた有料サービスの広告(有料とは書いてない)がある。実際、「へえ、便利そうだからやるか」と思って設定し掛けたら、有料なことが分かって止めたことがある。
    • 「【要確認】ご登録情報を至急ご確認ください」という題だが、これも内容は上と同じ。最後にやっぱり有料サービスの広告。
    • 近頃こういうのが頻繁に来て、堪忍袋の緒が切れた。
  • ちょっとした追加機能が有料で高い。ドメインロック(不正操作の予防機能)すら有料※。(← ドメインロックについては、下記のように誤解だった)
    • ※お名前.comの設定画面を見直したら、ドメインロックの名前は「ドメインプロテクション」だと思っていたが、実は「ドメイン移管ロック」で、こちらは無料だった。説明はないし、ドメインプロテクションが先に出ていて(しかも、ドメインロックと場所が別)目立つし、メールの宣伝ではドメインプロテクションに飛ばされたので、とても誤解しやすい。 (4/16 5:43)
  • いまだに2要素(段階)認証でない。

ドメイン名登録業者を検索して、以下が候補になった。もちろん、お名前.com(GMO)系の業者は除外した。

  • さくらインターネット
    • 高い(1852円/年)。
    • いろいろなサービスを使っても、全然割引きがない。
    • 信頼感はある。
    • 設定画面(web)は「昔ながら」の様相で、使いやすくはない(お名前.comよりはずっといいが・・・)。
    • 2要素(段階)認証かどうか不明(サービスによって、そうだったりそうでなかったり・・・)。
  • スタードメイン
    • 安くはない(1490円/年)。
    • 事前にポイントを買って支払う(プリペイド)ので面倒。
    • プリペイドのため、自動更新でないのも面倒。
  • Xdomain
    • 安くはない(1490円/年)。
    • 良くも悪くもないが、リセラー(元はスタードメインらしい)なので継続性が不安。
  • Google Domains
    • 信頼感はあるが、突然終わる心配がある。
    • 設定画面が使いやすそう。
    • 安くはない(1512円/年)。
    • DNSサーバ(8.8.8.8)は高速。
  • FC2
    • 安い(1,180 円(税込みか抜きか明記なし))が信頼性はかなり疑問。
    • Webページに重要なことが書いてなかったりする(例: 料金が税込みかどうか不明: ただ、Googleも不明だった)。
    • アダルト系のイメージで印象悪い??
  • 海外の業者(namecheap, Uniregistry): 特に安くなく(1500円/年前後)、メリットが感じられなかった。

移管先を選ぶ際には、可能なら料金を安くしたかったが、そもそも年間2千円未満とすごく高いものではないので、それよりも、安定性(信頼性)や使いやすさを重視した。

最初は、今までの経験から、信頼性が高く既に使っているVPSなどのサービスと一本化できるのが便利そうなので、さくらにしようと思っていた。しかし、割引きがない(いつも、なんでやらないのかなと思う。「VPS使ってたらドメイン半額」とかいいと思うが。商売下手なのかな)し、設定画面もイマイチそうだし(実際、今使っている他のサービスのはイマイチ)、いくら信頼性があるといっても一社に依存し過ぎるのは良くないので、Googleにした。もちろん、全然好きじゃないのだがw

上にも書いたように、彼らの習性で突然終了になる心配があるが、レジストラのサービスはコストは安いし、彼ら自身も使っていそうだから、まず大丈夫だと期待した。それに、終わりになる時は早期に予告されるだろうから、また移管すればいいのだ。

それから、Googleはユーザーの個人情報を収集する悪癖があるが、ドメイン名の場合、登録者の情報を登録時にしか取得しないので、大きな問題はない。そもそも、僕はAndroidを使っている時点でいろいろな個人情報を渡しているから、現状以上の問題はない。あと、DNSサーバは使う人が選べるから、Googleが嫌な人は使わなければ良い。そして、デフォルトではプロバイダ・キャリアのサーバが使われるので、ほとんどの人は何もしなくてもGoogleのDNSサーバに関わることはない。

移管の準備

移管に際して、ひとつ大きなハードルがあった。移管前に、元の業者(お名前.com)でWHOIS情報(ドメイン所有者の名前、住所、電話番号、メールアドレスなど)を公開する必要があり、移管が終わるまでその状態が続くことだ。通常は、「WHOIS情報公開代行」という機能で、ドメイン所有者の情報の代わりに代理(例: レジストラ)の情報を公開しているのだが、移管中は自分の本当の情報を全世界に公開することになる。移管に掛かる時間は未定(通常は数時間だが、数日間掛かる場合もあると説明されている)なので、なかなか恐ろしいものがある。僕としては数時間でも嫌だ。

どうしても公開が必要そう(移管先からの連絡ができないためのようだ)なので諦め掛けたのだが、いろいろ調べるうちに、さくらに移管した方の情報が見付かった。そこには、以下のようなさくらの説明が引用されていた。

登録者名はプライバシーを重んじる方は、ハンドル名・ニックネームなどのプライバシーに影響のない名称をご検討下さい

プライバシーを重んじる私は、上の記述を柔軟に解釈して、公開されても不都合のない情報に変更した。一番重要なのは、メールが届くことだ。詳しくは、「分かってるな」 → 「私、すごく物分りいいんです」ってことでw

それ以外は特別大したことはなかった。念のため、現状のお名前.comのDNS設定などをメモした程度だ(実際には、自動でGoogleに移行された)。

移管作業

作業前に再度確認したところ、1点だけ準備に抜けがあった。WHOIS情報の管理担当者と経理担当者が変わっていなかったので、修正した。WHOIS情報には4つのカテゴリがあり、そのうちの3つを変更する必要があった※(WHOIS情報を検索すると全部は出ないようだが、念のため、全部変更したかった)のだが、最初の1つ(登録者)しか変更していなかったのだ。危ういところだった。お名前.comの設定画面が分かりにくく・使いにくく、必要最低限以上は1μ秒だって使いたいと思えないので、設定変更後の確認を充分にしなかったせいだ。

※今、仕事用ドメインを見たら、4つ目の技術担当者も変更する必要がある場合があるようだ。piulento.netでは技術担当者情報はGMOになっていたので不要だったが、仕事用ドメインでは自分になっていたから、全部確認・変更する必要がある。まったく良く分からないシステムだ。 (4/16 5:31)

それ以外には大きな問題はなく、つつがなく終わった(実際の作業内容・手順については、ここを読まれる方で実施する方が多いとは思えないので、割愛する。検索すればいくらでも出て来る。逆に、調べてできない方はしない方がいい)。一番心配だったのは、お名前.comからの移管承認と移管終了の通知メールが遅かったことだ。それぞれ約1時間くらい掛かった。その間、「もし、どこかに不備があって処理が停まってしまったら、お名前.comもGoogleもサポート依頼は面倒そうだな・・・」とか思っていた。

大体、2時間くらいで作業が終わった。

それから動作確認し、問題なかった。代理のWHOIS情報(→ 検索ページの例)はGoogleのものに代わり、IPアドレスはちゃんと検索でき、ブラウザでのアクセスも問題なかった。ただし、ドメイン情報の伝達には時間が掛かるので、すぐに試しても意味がない場合があるので、数時間後に再度確認してOKだった。

感想・その他

やっぱり、お名前.comは論外かつぼ●たくりだと思った。ほとんど何もしないのにお金を取り(これは他社も同様)、追加機能は、例え必要な機能だってほとんど有料だ(しかも、平気で千円/年とか取る)。昔からやっていたらしい功績は認めるが、余りにも阿漕ではないだろうか。これでは、ひどい目に遭った人が止める(辞める)一方ではないかと思う。実際、「ドメイン移管」で検索すると、「お名前.comから*に移管」というようなのが沢山出て来る。ただ、そこは数多くのレジストラ(例: ムームードメイン)を吸収しているから、それでも余裕があるのだろうか(検索すると、「お名前.comからムームーに移管」というのも多くて、(それにはちゃんとした訳があるのだが、)苦笑する)。

Googleでは、設定画面(web)は見慣れた単純明快なもので分かりやすく、使い勝手がいい。設定に当たっていくつか不明な点はあったが、不安は全くなかったし、すぐにしたいことができた。そのうえ、いくつかの付加機能(例: メール転送)が無料で使える。もちろん明朗会計で、勝手に有料サービスに誘導されるなんてことはないw

それから、移管する前に心配していたのだが、ドメイン名の有効期間は移管しても全く減らない。移管時に、新しいレジストラに1年分の料金を支払う必要があるが、それは今の期限に追加される。期限前に移管しても残りが消滅する訳ではなく、移管した日が期限の開始になる訳ではない(だから期限ギリギリまで移管を待つ必要はない)。これは良心的だ。というか、下に書いたように、レジストラはドメイン名を登録するだけなので、(今までの)レジストラの関与がなくなったからといってドメイン名の有効性が消滅する訳ではないのだろう。

なお、レジストラは常日頃ドメイン名の管理をしている訳ではなく、単に登録しているだけ(要は取り次ぎをするだけで、付加的にDNSサーバの提供などをしている)なので、基本的には登録や変更の時しか仕事をしていない。だから、DNSサーバを持っていれば自分だってできる(しかも無料で)はずだが、実際には登録先の団体(レジストリ)は契約(認証?)済みのレジストラからの要求しか受け付けないので、自分で登録するのは現実的でない。でも、そのうち、GoogleあたりがSSL証明書のLet's Encryptみたいに、もっと手軽にドメイン登録できるようにしそうな気がする(ただ、そうしても、Googleには今以上の利益はなさそうだ)。

僕のドメインは、もう一個、休眠状態の仕事用のがあるのだが、期限切れで失効させようと思っている。でも、もし幸運にも使う宛てができたら、Googleに移そう。どっちにしても、年内にはめでたくお名前.comからサヨナラできる。

  •   0
  •   0

確かシンプル バッテリー グラフが突然駄目になった時だったと思うが、スマフォのWi-Fiの消費電力を減らせば更に電池が持つようになるかと思って測ってみたら、意外に食うことが分かった。まず、GSam Battery Monitorで、家で長時間アイドル状態での全体に対するWi-Fiの電池使用率の割合を調べてみた。約9時間で調べたところ、主な要素の使用率は以下のようになった(→ )。

  • 電池使用量(減った率): 6%/8:51 (→ 平均電力消費率: 0.68%/h)
    • 画面: 0%
    • Wi-Fi: 31%
    • アプリ: 46%

これより、Wi-Fiは平均0.21%/h、アプリは平均0.31%/hを消費していると考えられる。だから、仮にWi-Fiを常にoffにしたら、平均電力消費率は(0.68-0.21=)0.47%/hに、onの時間を半分にできたら0.58%/hになるはずだ。

Wi-Fiを停める(停めたい)状況は、以下の2とおりある。

  • 外出時: モバイルしか使われないから全くの無駄なので、Wi-Fiを(自動で)offにしたい。
  • 在宅時: 常時onだと待機(アイドル)時は無駄なので、必要な時だけonにしたい。

外出時に関して、以前はWiFi Maticという、モバイルの基地局情報で位置を判定してWi-Fiをon/offするアプリを使って、外出時は自動でoffになるようにしていたのだが、どうしてか、少し前から誤動作するようになり、家でもoffになってしまったので止めた(既に公開されていない(同名のものはあるが、別物である)ことも、止めるきっかけになった)。確かに、止めた時には外出時の電力消費率が若干増えたのを覚えている。

それで、代わりのアプリを探したのだが、どうしても僕の要望に合うものはなかった。惜しいものはいくつかあったのだが、ネットワーク位置情報(Googleに自分の位置を送る)を使うものは却下した。候補の中で良さそうだったものを以下に列挙する。

  • Smart WiFi Toggler (2015): ネットワーク位置情報を使う。
  • Wifi Toggle (per Funkzelle) (2017): 新しい基地局を手で登録しなければならない(自動学習ではない)。
  • AutoWiFiOnOff (2018): いろいろイマイチ(惜しい)。
  • WiFi Auto (open source) (2018): ネットワーク位置情報を使う。
  • WiFi Automatic (2018): 位置はGPSを使う(しかも、位置での判定は動かない)。

一番良かったのは最後のWiFi Automaticだった※が、なぜか位置での判定はできなかった(テストで結構歩いたのに無駄だったw)。ただ、仮に(他のアプリを使って)位置(基地局)で判定できても、基地局が増減するたびに誤動作する可能性があるので、位置での判定は諦め、WiFi Automaticの機能の、APの有無での判定を使うことにした。具体的には以下のような設定にした。

  • 15分ごとにWi-Fiをonにする。
  • 2分間Wi-Fi APに接続できない時、Wi-Fiをoffにする。

※(4/13 14:20) その後更にアプリを探したところ、以下の2つも良かった。あとでそれぞれの評価結果を投稿する予定である。

    • Wifi matic (2017): 最初に使っていたものと同じような名前だが、別物。
      • 機能はWiFi Automaticのサブセット的で、僕が使ううえではほぼ同じことができる。位置でのon/offはできないが、WiFi Automaticの位置判定もうまく動かないので、こちらの方が軽量そうでいい。また、ルータの情報が見えたり、動作ログが見やすいなどの点も便利。
      • 簡単に動作したところ、問題なさそうだった。
      • 下のWayfiが駄目なら、WiFi Automaticでなくこちらを使う予定。
    • Wayfi - Automatic WiFi Toggle Service (2018): 名前はサービスっぽいが、独立したアプリのようだ。
      • GPSを使うが、ネットワーク位置情報は使わなくても良く、機能が僕の要望に合っているので、消費電力が大きくなければ使いたいと思った。
      • 基本動作は概ね問題ない。
      • 外ではWi-Fiが完全にoffになり、帰宅したら即座にWi-Fiに接続されるのが気持ちいい。
      • 「外出」を模擬(「家」の位置をずらし、ルータのWi-Fiをoff)した長時間静止・アイドル時の消費電力は全く問題なかった(0.6-0.7%/h程度)。
      • 実際の外出時の消費電力を確認中(少なくはないが、いつもと同様な感じ(3%/h前後)で、すごく多くはない)。
      • 少し使ってみたら、家に居るのに、時々Wi-Fiがoffになる(すぐにはonにならず、5分くらいしないと繋がらない)。「家」の範囲を200mと大きくしても直らなかった。そうでなくても、家の近くの外に居る時も、頻繁にon/offしていたので余り気分が良くない。確かに、GPSには誤差(揺らぎ)があるし、室内だと受信状況が悪いから、本質的に良くない気がした(基地局の方がまだましだ)。それで、Wayfiは止めてWifi maticを使ってみることにした。 (4/13 20:32)

外出時に上記の処理(「Wi-Fi間欠on」と呼ぶ)をする場合としない場合(「Wi-Fi連続on」)および在宅時(Wi-Fiは連続on=常時接続)を想定した条件(実際には、いずれも家の中で測定した。「外出時」の環境は、ルータのWi-Fiを停めて実現した)での電力消費率を測定した。

以下に、外出時のWi-Fi間欠on時()と連続on時()、在宅時の連続on時()のWi-Fiの動作状況や電池残量のグラフを示す。電池残量は水色の線で、Wi-Fiの電源on/off状況は"WiFi"の左のオレンジ色の点・線で示されている。基本的に想定どおり動いている(16時以降の部分)。ただし、Wi-Fi onの間隔が指定と異なっており(約11分になっている)、アプリの不具合なのか機能の制限なのか、私が仕様を誤解しているのかも知れない。

それぞれの電力消費率は以下のようになった。

  • 外出時 (モバイルデータ通信, Wi-Fiは常に非接続)
    • Wi-Fi間欠on(on時間率: 13%): 0.53%/h以下
    • Wi-Fi連続on: 1.5%/h
  • 在宅時 (Wi-Fiは常に接続): Wi-Fi連続on: 0.53%/h以下

上で、「以下」というのは、測定時間を充分長くできなかったため、電池残量がきりのいい値にならず(残量の最小単位は1%)、1%未満の残量が切り捨てられているために、多目の電力消費率になっていることを示す。

外ではモバイルデータ通信をするためか、ほぼWi-Fiだけで通信する在宅時よりも約1%電力消費率が大きい。そして、Wi-Fi間欠onにした場合には電力消費率を約1%/h減らせて、連続onの約1/3にすることができた。これは当初の期待以上である。測定誤差などはあるだろうが、外出時の消費電力を多少下げられることが分かった。

実際には、外出時には上のテストのように何もしないで居る訳ではなく、GPSロガーを動かしたり、写真を撮ったり、地図を見たり、音楽を聴いたりする。それらの消費電力はかなり大きい(そもそも、画面点灯の消費電力ですら大きい)ので、Wi-Fiでの削減が本当に体感できるかは疑問だ。ただ、消費電力を可能な限り減らすに越したことはないだろうし、それが目的だ。

もちろん、外では基本的にWi-Fiを使わないのだから完全にoffにしたいが、上述のとおりいいアプリがない。Automagicで自分で作ろうとも思ったが、基地局のIDを見てみると、数時間ごとに3-4個が切り替わっていて、これからも新しいものが出て来そうだ。そのため、基地局が増えたら自動的に登録するようにするとしても、かなり広いエリアが「家」と見なされることになり、家の付近ではWi-Fiがoffにならなそうだ。基地局での「家」の判定と上記の間欠onを組み合わせれば良さそうだが、なかなか複雑なので保留した。

余談: 基地局で位置を判定するタイプの自動Wi-Fi on/offアプリに対して「ちゃんと動かない」と言う方が結構居るが、上記のような基地局の変化のせいではないかと思う。基地局を自動学習できるアプリはほとんどなく、最初に設定した基地局だけがずっと来る訳ではないから、そのうち「家でない」と判断されてoffになってしまうのではないだろうか。まあ、こういうことは普通は分からないから仕方ないだろう。アプリの作者ですら想定してなさそうだ(大抵のアプリは、「家」には基地局を1個しか登録できない)。

次に、在宅時の消費電力削減も可能か試してみた。基本的には、普段はWi-Fiをoffにしておき、通信する時にWi-Fiをonにすればいい(Wi-Fi APがなければ諦める)。書くとシンプルで簡単そうだが、実際にはとても難しい。WiFi Maticの代わりを探していた時にそういうのがあったのだが、その時はそれが目的でなかったので閉じてしまったら、その後、いくら探しても全然出て来なくなってしまった。僕の見間違いだったのか幻だったのか、全く不思議だ。

それで、この方式(「Wi-Fi自動on」と呼ぶ)の実用性を検討するためにAutomagicとWiFi Automaticを使ってプロトタイプを作ってみた。基本的には以下のような処理である。

  1. Wi-Fiがoffになったイベントを待つ。
  2. モバイルデータ通信が始まるのを待つ(1000バイト以上送受信されるのを待つ)。
  3. Wi-Fiをonにする。
  4. Onにしてから一定時間(6分)後、または、一定時間(2分)以内にAPに接続できない場合はoffにする。

簡単に書いたが、実装には苦労した。しかも、動かしてみると効率が悪く、消費電力を削減するどころか増えてしまった。原因は、上記2番の実装が悪くて、条件が満たされるまで延々と繰り返し待っている(ポーリングしている)からである。本当は1番のようなイベントにしたかったのだが、Automagicではできないので、とりあえずこのようにしてみた。

以下に、Wi-Fi自動on時()と連続on時()のWi-Fiの動作状況や電池残量のグラフを示す。2つを比較すると分かるように、Wi-Fi自動on時はWi-Fiは断続的に(上の間欠onと異なり、モバイル通信を契機にonになるので一定間隔ではない)onになっており、想定どおり動いていることが分かる。

ただ、電池残量(水色線)の傾きを見ると分かるように、Wi-Fi自動onでの電力消費率(1.7%/h)は連続on(0.53%/h)の3倍以上にもなってしまった。上にも書いたように、モバイル通信の状態のポーリングで常にアプリが動いているのが悪いようだ。更に、そのためにDoze(ディープスリープ)状態にもなれないようで(本方式ではDozeの線が破線になっているが、連続onではほぼ繋がっている)、消費電力が大きくなったのだろう。

それ以外に想定外のことも分かって、この方式自体がイマイチな可能性があることが分かった。それは、当たり前のことだが、通信は時間的に分散している(まとまっていない)。それまでoffになっていたWi-Fiをonにしたからといって、途端にいろいろなアプリが通信をし出すことはないのだ。そのため、Wi-Fiのon/offが頻繁になって、まとまったoffの時間ができない(実際、グラフではほとんどのWiFiの点の隙間は広くない)。それでは消費電力が低いoffの時間が稼げないうえに、onにする時に消費電力が増えるため、消費電力を削減する効果が低い。これを何とかするにはOSの対応が要る(例: アイドル時は通信をまとめる、アイドル中は各種アプリを一括して動かす: どちらも難しそうだ)。

いつものように、「やる前に気付けよ!」って話ではあるが、やってみないと分からないことはあるものだ。それに、後述のように、Googleだってやっているのだから、それほど間違ってはいないはずだ。

それから、最初から分かってはいたが、モバイルデータ通信が始まった後でWi-Fiをonするので、契機となった通信のデータは全部モバイルになる(一つの通信の途中から切り替えることはできない)ため、モバイルデータ通信量が通常の約4倍に増えてしまった(最初の通信は量が小さいだろうと思い込んでいたが、実際にはそうでもなかった)。これを解消するにもOSの対応が要る(これは容易だ)。

これに関しては、以前も書いたように、トレードオフがある。もし、モバイルデータをふんだんに使えるなら、これは全く無視していい。ただ、僕のように500MB/月というケチケチプランだとそうも行かない。この件ではいつも悪あがきしている。今回だってその一環だw

結局、現段階では「いいことなし」なのかも知れない。ただ、アイデアとしては悪くないはずだ。実際、Android 9 (Pie)にはこの機能(Wi-Fi自動on)が入っているとのことなので、それに期待したい。ただ、上記のように通信が分散したままだと、いつもonになってしまって余り効果がなさそうだ(そのためにPixel以外の8(Oreo)には入っていないのかも知れない)。まあ、どうなるか楽しみではある。

それに、そもそも、在宅時はいくらでも充電できるのだから、すごく苦労してまで消費電力を下げる必要はないことにも後から気づいたw それでPieに更新されるのを待つことにした。

という訳で一勝一敗(一敗一分?)となったが、若干にせよ、消費電力削減できた(気がする: まだ実際に使って、「お、使用可能時間が*時間も伸びた!」などとは実感できていない)ので、気分(だけ?)はいいw

 

おまけ: 今日の午後に実際に外出した時のグラフを載せる。Wi-Fiは、外出中はちゃんと間欠onになっている(今回は、指定どおりの15分間隔になっているようだ)。GPSロガーを動かしていたのでGPSも動いているし(移動中は意外に頻繁だ)、画面も点灯している。電力消費率は1.7%/hだった。いつもは3%/h前後なので少なくなった気はするが、使い方にもよるので、まだ何とも言えない。

床屋に行った時の動作状況

(4/12 8:59 わずかに加筆; 4/13 14:20, 20:32 追加アプリについて追記)

  •   1
  •   0

なぜか、春になるといろいろなことが動き出す(まさに啓蟄?)ようで、気候が良くて気分がいいこともあるのだが、いろいろなことが勃発して疲れることも多い。以下に主なものを列挙する。あとで詳細を書くかも知れないし、そのままにするかも知れない。特に書きたいことは、ここで書いておく。

  • 病気再発? → とりあえず、様子見に。
  • スマフォ(AQUOS sense lite)の怪: 電池の激減、Wi-Fiルータへの接続を繰り返す、再起動したら予定を同期しなくなった。
    • なぜか、消費電力測定アプリ(シンプル バッテリー グラフ)が駄目になって、突然数十%も減るようになったので、別の(3C Battery Monitor)に入れ替えたj※。広告を停めるため、外部との通信を遮断していたのだが、突然、それが原因で電池を食うように(見えるだけ?)なった他に、システムの電池情報もおかしくするようになってしまったようだ。
      • ※その後、GSam Battery Monitorというアプリもいいことが分かった。こっちは電力消費率のグラフが出て便利だし、例のDoze(ディープスリープ)状態になっていた時間や、Wi-FiやGPSなどがonになっていた時間が分かるので便利だ。あと、広告も良心的でいい(3Cは突然全画面で出る)。でも、3Cにもいい点がある(アプリごとの電力消費量が分かる: GSamにもその画面はあるが、正しく動いていない)ので、ちょっと迷っている。 (4/7 19:42) → GSamは電力消費率のグラフの縦軸(消費率)を拡大できなくて実用的でないので、基本的には3C(同様のグラフがあり、ちょっと分かりにくいけど拡大できる)にすることにした。ただ、今は別件でWi-Fiのon/offの確認をしたいので、一時的にGSamも併用している。まあ、両方入れておいても問題なさそうではあるが。 (4/8 12:17)
    • Wi-Fiルータへの接続はAir Cardでいろいろやっていた関係かも知れない。ルータも再起動したら、直った。
    • 再起動で予定を同期しなくなったのは以前からなので、諦めて別のアプリにした。今までのは古い版のまま更新されていないので、仕方ない。
  • 鋭い歯科衛生士さん、歯科医院の世襲劇
    • 先日の定期検診で診てくれた歯科衛生士さんは、僕が何も言わなかったのに、今までの人が発見できなかった問題を2個も見付けてくれた。一個は虫歯で、もう一個は割れの可能性だった。虫歯は歯が金属に接する部分が欠けていたのだが、以前痛んですぐに収まったところかも知れない(すごく小さいので、自分で見ても全然分からないし、今は自覚症状もない)。痛んだ時は、(歯科)医師も衛生士も全然分からなかった。割れは、ずっと、歯ブラシで触ったりするとピリピリしていた歯だった。写真では縦に筋が入っていたが、医師は割れではない(知覚過敏)と診たようだ。それまでは指摘すらされなかったから、写真を見せられてすごく納得した。当然なんだろうが、こういうのはかなり人に依るものだな。
    • それまでは前回までの、清掃をとても丁寧にしてくれる、お姉さん的な人にやってもらいたくて楽しみにしていたのだがw、すっかりその鋭い人に参ってしまった。次回もその人だといいが、なかなかそうも行かない・・・
    • その日、なぜかそれまでの担当の歯科医師が居なくて、院長に代わった。掲示されている担当者一覧を見たら、歯科医師のところには院長と同じ名字の人が並んでいたので、子どもたちが一人前になったから今までの人は「用済み」になって放逐されてしまったのだろうと推測した。資格があっても気を抜けない、なかなか大変な世界だw
    • あと、いつものように、受付にはにこやかな菅野美穂さん(に似た人)が居て、和んだのは全くどうでもいいことだが、どうしても書きたいw
  • 軽いドライブ、小泉さんと国生さんw
    • 歯科のあとで、いつものデニーズに昼食を食べに行き、それから古峰ヶ原(古峯神社)にドライブに行った。古峰ヶ原はデニーズから30kmくらいあるので、疲れたら途中で帰ろうと思っていたが、すごく気持ち良く走れて全然遠く感じず、あっという間だった。
    • デニーズの辺りの道ばたの桜並木が満開で綺麗だった。今まで全然知らなかった。
    • デニーズには小泉さん(仮)が居た。相変わらずだったw クーポンを使おうとしたらログインが必要で、手間が掛かってすぐに見せられなかったのだが、見せなくても「確認したので大丈夫です」と言ってくれたのがうれしかった。でも、すぐに居なくなってしまった。
    • デニーズアプリは、ログインは面倒だし、データ量を馬鹿みたいに食う(20MB以上)のでちょっと止めたい。
    • ドライブの帰路に寄ったコンビニに、(昔の)国生さゆりそっくりな人(色白、ミディアム(かショート)ボブ、色っぽい顔と目と唇)が来て、驚いた。なぜ、あんな田舎にあんな綺麗な人が居たんだろう? 車内でバナナを食べていた僕は目を釘付けにされた。
  • 散歩中にピアノ: 先日散歩していたら、突然、ピアノの演奏が聞こえて来た。CDなどの録音ではなく、誰かが弾いていると感じた。録音(プロ)ほど完璧ではないが、(よく子どもがするような)弾き直しなどなくて下手ではなく、気合が入っていた。曲名は分からなかったが(多分、リストなど僕の不得意なロマン派)、なかなか鋭い演奏で、少し立ち止まって居た。なんとなく、大人の女性がグランドピアノを弾いている気がした(少なくとも、アップライトではないし、高校生以上のような気がする)。その辺りには蕎麦屋のおばさんの家があるのだが、まあ、あののどかな人があんな鋭い音を出していたのではないだろう※。今日、その蕎麦屋に行ってそのおばさんも居て、何か知っていることがあるかもとは思っては居たのだが、なかなか聞けなかったw
    • ※僕は、日頃から表現者の性格・行動・属性などと作品は関係ないと思っているが、上に書いたこととは矛盾しないと思う。つまり、のどかな人は、仮に演奏したとしてものどかな音を出すように思えるから、「のどか」に見えるのだ。別の言い方をすれば、世間に広く知られていると思われることは実際には虚像で、本人を正しく表していない可能性があるが、本人を知っていれば、その人のしそうな表現も推測できるということなのではないだろうか。(苦しいな・・・)
  • 母の病気: おそらく緊急性はないのだが、根治には手術が要る一方、高齢なので手術にはリスクがあるので、どう助言すればいいのか難しい。助言しても、なかなか本心を出さないから厄介だ。
  • 暑いうえに寒い → くしゃみ連発+鼻水。ティシューの減りが速いうえに鼻の周辺がひりひりする。
  • 床屋が面倒: 行きたくなってから2週間経過して、髪の伸び具合が高校・大学時代みたいな雰囲気になって来たw

こんな時はやっぱり、モーツァルトのピアノ協奏曲(第20番以降)を聴くに限るのだが、Spotifyで選ぶのすら疲れるので、手持ちのゼルキンの1980年代のを連続して掛けている。時には歯がゆい・枯れ過ぎな箇所もあるのだが、全体としては「鉄板」で、安心して聴ける。他の定番であろう、内田やピレシュ、ペライアなどとは安心度が全然違う。ただ、フレイの演奏がもっとあれば、新進気鋭(当時)さや若い熱気やパワーで元気が出る気がするのだが、余りないので仕方ない。

 

PS. コンピュータのプログラムやライブラリの説明で、「いろいろ混ぜて一緒にした」(= ごった煮)というような意味の単語があったのだが、調べても"misc."や"sundry"(今日まで正しい意味を知らなかった)くらいしかなく、「本物」が思い出せなくて歯がゆいw

(4/7 11:35 地名を修正)

  •   0
  •   0

先週、2017年に手術した辺りが腫れた。そして、前回と同様の経過を経て治まった。再発したのかと思って心配になったのだが、単なるできもので問題ないかも知れないとも思いつつも、やっぱり気になって病院に行った。

結果は予想どおり「様子見」になり、またこうなったら来るように言われた。まあ、今までの経験から予想していたとおり(医師は、だいたい、その時に症状が出ていなければ、「様子見」にする)なので、特にムカつきもせず、逆にまた入院・手術するのも面倒だし、あそこには余り入院したくないので、ほっとしたくらいだ。ただ、もし次回行くとすれば、無駄足を避けるために治る前に行きたいw

ただ、MRIくらい撮ってもいいとは思うのだが、まあいい。というのは、今は、仮に再発しても手術しないことも考えているからだ。前回は病気なのを知らずに二十年以上放置していたが、癌のようなすごくひどいことにはなっていなかったので、今後もそれで乗り切れるのではないかと期待するのだ。まあ、その時になったらどうするか分からんけど、次は手術するのとしないのと、更に、(僕の体質に起因するのであれば、)手術しても再発する可能性も考慮して、どちらがいいか考えたい。

転勤したのか、前回の主治医は居なくなっていた。そして、運の悪いことに、今日は当番の二人のうち片方が休みのようで、結構待つかと思ったが、一時間くらいで診てもらえた。途中から一人増員になったのが良かった。その増員の医師は、前回もちょっと診てくれた元気な人だった。もしかしたら、僕の手術をした人なのかも知れないと思うのだが、手術前の挨拶はなかったし、僕は眼鏡をしていなかったし、彼はマスクを着けていたから良く分からない。そういうことを教えてくれなかったのは、あの病院の良くない点だ。そういうことも、あそこを敬遠したい一因だ。

他に、日本の病院では良くあることだが、受付前の待合所で人前で病状を聞かれたのは、どうなんだろうと思った。僕はまあいいけど、話しにくい人は居るだろうし、今はプライバシーを大切にする世の中ではないのか。その病院はとても大きな組織が運営しているのに、田舎だからダウングレードしてしまっているのか。残念なことだ。でも、いつも思うのだが、看護師さんや受付の人が親切なのは良い。少なくともそれだけは、あそこのいい点だ。

待っている間、SpotifyでThe Carsの"Candy-O" (1979)を聴いた。ちゃんと聴くのは久し振りではないか。データ節約モードでも全く問題ない音質だった。ただ、スマフォのボリュームでは微妙な音量調整ができないので、ケーブルの途中に入れるボリュームが欲しくなった。そういうアプリがあればいいのだが、以前は見つからなかった(→ 「音量微調整」で検索したらいろいろあったので、試す)。次のアルバム(何だったかすっかり忘れたw)を聴き始めた頃に呼ばれた。

見ただけのせいか、診療費は200円くらいと安かった。ちょっと心配したのだが、再診扱いのようで、紹介状がなくても追加費用は取られなかった。

モバイルデータ量を調べたら、なぜかOperaが多かった。以前起こったのと同じ現象だ。自分や他の方のブログをちょっと見ただけなのに16MBも使った。40分くらい聴いたSpotifyと同じくらいだ。謎だし、どうも気に入らない。Firefoxでも起こったし、フォントか何かなのだろうか。

帰りにちょっとドライブして来た。景色は「いかにも春」で、ところどころに桜なども咲いていて、車が例によって調子良いのと相まって、気持ち良過ぎて眠りそうだったw 約30km、1時間くらい走った。途中に、たまに通るちょっとした山道(低いので、屈曲路という方が正しい)があって楽しかった(正確には、その道かもと思ってナビの目的地に設定した)。やっぱり道はちんぷんかんぷんで、帰路はナビより近道があったのに気付かなかった。

朝、バッテリーが少し危うい感じだったが、まだ持ちこたえている。走行距離はほとんど増えず、約54000km。夏には車検だ。

 

PS. スマフォの音楽再生音量の微調整の件。Androidではなんと15段階しかできないようだ。昔から問題になっているのだが、例によってGoogleは対応していない。Automagicでも15段階だった。微調整するアプリはいくつか見付かったが、Precise Volume (+ EQ/Booster)というのが一番僕には向いている感じだ。ただ、無料版ではアプリを開かないと微調整ができず、音量キーを押すと大きな幅で変わってしまうのが嫌だ。気に入ったら買おうか。 それにしても、ブースターは山ほどあるのだが、そんなに使うものだろうか。あと、単なる音量調整(設定と同じ機能)が山ほどあるのだが、そんな無意味なアプリを作るなんて、そんなに暇なのか?w 情弱から広告料を稼ぎたいのか。 (22:53)

(4/4 7:53) その後、AndroidのイコライザやDSPを改造して自作しようかと思ってGithubを探したのだが、さすがに面倒なので保留した(中心部分は乗算だけなのでものすごく簡単なのだが、UIだのAndroidアプリにするような、「回り」の作業が煩雑だ)。そもそも、イコライザアプリなんて、中身はAndroidのを使う、単なるガワばかりだった。ただ、一個だけ、JamesDSPManagerというのがまともで良さそうだった。これをベースにすれば、今使っているグライコアプリと音量微調整を統合できそうだ。

それから、(Google Playでなく)Googleで検索して、最初は使い方が分からなくてパスした、ExtraVolumeSimple(音量微調整)※の使い方が分かり、良さそうなので試そうと思っている(と言っても、スマフォでSpotifyを聴くことはそうそうないので、なかなか試せないがw)。

※ExtraVolumeConfigの方が新しいようだ。基本機能は同様だが、不具合修正や新しいOS対応があるようなので、こっちに変えた。

ただ、UIをもう少し分かりやすくすればいいと思う。あれでは、画面を一目見て使える人は皆無だろう。Google Playにも「どうすれば音量を微調整できる」ということは書いてなくて、他人の書いたページを読んで初めて分かった・・・ これを、例えば、「拡張音量設定」を「音量ステップの倍率」などと書き、そのスライダーの最小・最大値を"x1/10"と"x10"などと書き、現在の値を"x1/6"のように書けば、随分分かりやすくなるのではないだろうか(← 例はあくまでも僕の理解の範疇なので、実は間違っているのかも知れない)。

まあ、こっちは使うだけなので文句は言わないが(でも、上の改善例をコメントに書こうかな)、技術者としては「それじゃ駄目だよ」と言いたいw あと、こちらは、ちょっと設定しようとすると全画面広告を出すPrecise Volumeより邪悪でないのが、すごくいい。

  •   0
  •   0

もう誰も使っていないだろうし、こういう情報が要る方は皆無だとは思うが、折角いろいろやったので、今までに分かったことをまとめる。最新版のハード(PQI Air Card II)とファーム(V303)が対象である。

  • 使い方に関して
    • PC(Linux)からAir Cardのファイルにアクセスするなら、dropbearを入れてsshfsなどを使うよりcurlftpfsを使う方が手軽。
      • Air Cardの内蔵のftpサーバのままでマウントできる(設定・改造不要)。
      • curlftpfsでの転送速度が速いか遅いかは不明(筆者の環境では500KB/sくらい出ていた)。
    • autorun.shを作って子機モードで使う時にAPに繋がるまでに30秒くらい掛かるのは、通常のAPモード(w3コマンド)と子機モード(w2コマンド)の初期化に時間が掛かっているため。w3を起動させずに直接子機モードにすれば少し速くなるはず。
      • そうするにはinitramfsを作り直す必要がある。
      • /etc/init.d/S12_mod_wifi startでAPモードにしている。
      • ただし、APモードになれないと動作確認が困難になる欠点があるので切り替えられるようにした方がいい。
    • 子機モードの時は、kcard_appやkcard_cmdやkcard_startupは全く不要。kcard_appを停めても問題ない。
      • kcard_appでデジカメで画像を削除したらWi-Fiをonにするなどの処理を行っている。
    • ファーム更新に失敗した時などに設定が壊れてWi-FiのSSIDがおかしく(例: "h)")なったりして、ファームを書き直しても直らない場合は(まだ「回復不能になった」と諦める必要はないw)、/mnt/mtd/configがディレクトリでなく通常ファイルになっていることがあるので、ログインできるならそうしてコマンドを実行して直すか、autorun.shにコマンドを書いて作り直すといい。
    • Air Card内のLinuxと外部からのmicro SDへのアクセスが競合すると、micro SDが(論理的に)壊れる可能性がある。
      • Linuxからrefresh_sdコマンドを実行するとその時のmicro SDの状態がLinuxに反映でき、syncコマンドでその逆(Linuxでの変更がmicro SDに反映される)になるようだ。
      • それでも同時アクセス(例: Linuxで変更後、外部でmicro SDが変更され、その後Linuxでsyncした場合)で壊れる可能性はある。
      • だから、Linuxからmicro SDに書き込むのはなるべく控える方がいい。
  • 消費電力関係
    • 「スリープモード」は無効。kcard_cmd -s 0 (または1)は効かない。してもしなくても一緒で、スリープしない。
      • 昔は動いていたけどファーム更新でなくなったのか、子機モードで使っていたせいかも知れない(そうでなくても無効だった気がするが、定かでない)。
      • kcard_appに入っているが公開されていないioctl、KCARD_GO_SLEEPも効かない。
    • 消費電力を減らすには、wlコマンドでWi-Fiモジュールの省電力設定を変えるのがいい。
      • 例: wl PM 1 (または wl PM 2)
        • wl PM 0で解除される。
      • 消費電力が27%くらい減る(例: 800mW → 500mW)。
    • ifconfigコマンドでWi-Fiを停めてもWi-Fiが使えなくなるだけで、消費電力は減らない。
    • Wi-Fiの送信電力を下げても消費電力は減らない。通信速度が落ちるので無意味。
    • Wi-Fiモジュールの省電力機能以外で消費電力を減らすことはほぼ不可能。
      •  システムをスタンバイさせたり電源をoffにする機能はなさそう。
        • 第三者が公開しているbusyboxのpoweroffコマンドの動作はshutdownと同様。
      • スリープはビジーループなので、消費電力削減には全く効かない。
      • micro SDをアンマウントしても消費電力は減らない。
      • カーネルにはクロックを変更したりスリープモードになると思われる機能があるが、使えるのか(本当に機能するのか)は不明。
      • Linuxを起動させなくても消費電力は減らない(u-bootのスリープがビジーループになっているせいか)。
      • CPUにはスタンバイなどの機能はあるが、システム制御レジスタの仕様が分からなので使えない。
      • 仮に、電源スイッチを付けてAir Card全体の電源を切ったとしたら、外部からSDとしてアクセスできなくなってしまう。
        • micro SDの制御にはLinuxやCPUは関わっていないが、SOCが制御しているようなので。
    • microSDを挿さないとAir Card全体が起動しないようで、消費電力は低い。
  • 更に細かい話
    • Air Cardの元はKeyASICのMCARDのようだ。
      • TranscendのWi-Fi SD CardやFlucardも同様と思われる。
      • SOC: SPG101 (CPU: ARM926EJS)
      • Wi-Fi: Fortune AF-N-31GL (Atheros AR6005)
      • Linuxカーネル: 2.6
    • ファーム更新用プログラム: program.binについて
      • ファーム更新ファイルの内容(推定)
        • program.bin: ファームウェア更新プログラム
        • mtd_jffs2.bin: /mnt/mtdのファイルシステムの内容
        • Image3: Linuxカーネル (Imageの場合もある)
        • initramfs3.gz: Linuxのルートファイルシステム(/)の内容 (initramfs.gzの場合もある)
        • autoload.tbl: (ない場合もある)不明。読み込むファイル一覧?
      •  更新に必要なファイルが正しくないと通常の起動になる。
        • 先頭のデータで更新ファイルの正当性を確認しているようなので、最初だけコピーしておけば誤魔化せる。
      • program.binの中に書かれたu-bootのコマンド(スクリプト)で、micro SDの更新ファイルを読んで内部フラッシュに書き込んでいる。
      • program.binはu-bootのサブセット+改造と思われ、使える(動く)コマンド・機能は少ないし、動作がおかしいものがある。
        • if, &&などやclk setコマンドは使えない。
        • sleepコマンドの単位は秒でなく、かなり小さい(約1/416秒?)。
      • ファームの更新成功後、program.binはLinuxの起動時に削除される(他の更新ファイルはどこで削除されているのか不明)。
    • [既知の情報] ファーム内のinitramfs3.gzの先頭8バイトを除去しないと、gunzipできない。
      • 例: dd if=initramfs3.gz bs=8 skip=1 | gunzip > initramfs3
      • ファイルの展開にはcpioを使う。
        • 例: cpio -ivd < initramfs3
    • [既知の情報] busyboxをコンパイルするには、arm-none-linux-gnueabiのgccが要る(→ ダウンロードの例)。Linuxのクロスgcc(arm-none-eabiなど)では駄目。
      • u-bootやLinuxカーネル(GPLなので、昔ソースが公開されていたようだ)はそれでなくてもビルドできるが、ちゃんと動かすための設定が難しい(u-bootは起動はするものの、今ひとつうまく動かない。Linuxカーネルはビルドできたが、動かなかった)。
      • LinuxカーネルはmkimageコマンドでuImageにする。なぜか作られなかったので、u-bootのものを使った。
    • Air Cardのブートの流れは以下のように推測している。
      1. 電源on後、内部フラッシュのu-bootが読まれて起動される。
      2. u-bootはmicro SDにprogram.binがあれば読んで実行する。
      3. u-bootは内部フラッシュのLinuxを起動する。(内部フラッシュからRAMへの展開をどこでやっているのか不明: おそらくu-bootがやっている)

 

(4/3 8:09 refresh_sdに補足)

  •   1
  •   0

諦めた」と書いたPQI Air Card II(以下、Air Card)でのデジカメ画像の転送であるが、実は密かに日夜続けていたw(投稿の間が空いたのはそのせいだ) 買ったお金が無駄になるのが嫌なのでなく、「できそうでできない」というムカつかせる状態や僕の好奇心がそうさせていた。毎日、夜には諦めて片付けるものの、朝起きると新しいアイデアが浮かび、引っ張り出して試し、結局駄目でがっかりして、「もう諦めた!」と決意を堅くして仕舞うの繰り返しだった。

大きな問題は以下だった。

  • 電源をonにした時、通常はWi-Fi(Linuxも)を起動させないようにする。
  • デジカメから、Linuxを起動するかどうかの切り替えができるようにする。

切り替える手段がほとんどないので、Air CardやFlashAirのやり方をならって、特定の画像を削除することにした。ただ、前にも書いたように、切り替え機能を実現するベースに使おうとしているファームウェア更新プログラム(program.bin)ではifなどの条件判定ができないうえに、入手したu-bootをコンパイルしてもなぜかうまく動かない機能が多いので、どうしても、「あるファイルがあったら*する/しない」という判定ができずにいた。

それが、昨夜ふと思い付いたことで可能になった。

program.binは、SD内にファームウェアの更新に必要なファイルがあるかどうかを判定して(u-bootの)ファイル読み込みやフラッシュ書き込みコマンドを実行しているので、その判定処理を使うのだ。具体的には、例えば、SDにあるImage3というファイルをフラッシュに書き込むコマンドは、program.binの中に以下のような文字列で書かれている。

fatload mmc 1 208000 image3; sf erase 200000 300000; sf write 1ffc00 200000 300000

今までは、そこにファイル有無を判定するコマンドを入れて失敗していたのだが、そもそも、Image3がある時だけこれが実行されるのだから、これが呼ばれる前にImage3というファイルの有無の判定処理があるはずで、それが使えるのだ。それで、書き込みコマンドを以下のように書き換えれば、SDにImage3がある時には、(しばらくの間: 10万秒(= 約1日)を期待する)Linuxを起動させないようにすることができる(u-bootにはシステムを止めたり何もしないでいるコマンドがないので、sleepを使った)。

sleep 100000

そのように書き換えて(実際には、コマンドを書けるサイズが大きいのでpreprog_chk.binというファイル用の領域を使った)、SDに対象のファイルを作って起動したら、当たり前ながらLinuxは起動しなかった。

実際にデジカメから設定できるようにするには、設定に使う画像ファイルはDCIMディレクトリの下になければならないのだが、運良く乗り越えられた。program.binの中には、存在を確認するファイル名を格納している領域があるので、そこに判定に使いたいファイル名(例: DCIM/100_CTRL/nowf0001.jpg)を書き込めば良い。実際には、本来のファイル名より実際のファイル名が長いからオーバーしてしまうのだが、たまたま、その後にメッセージの文字列が入っていたので、そこまで使って格納できた。メッセージは見えないので、おかしくても全く問題ない。具体的には、

preprog_chk.bin\0pre-program check passed.

DCIM/100_CTRL/nowf0001.jpg\0 check passed.

に変えた(文字列中の"\0"は、文字列の終端を示す文字である。\0は記載したそれぞれの文字列の最後にもあるが、省略している)。これで、DCIM/100_CTRL/nowf0001.jpgがある時はWi-Fi(Linuxも)は起動せず、それをカメラで削除して電源を入れ直せばWi-Fi(Linuxも)が起動するようになる(Linuxが起動したら、削除した設定用ファイルなどを復活させるようにした)。なお、デジカメはディレクトリ名やファイル名や画像のサイズを細かくチェックしているので、それらを規格や仕様に合わせないと、デジカメにエラーが出たり画像が表示されなかったりするので、注意が必要だ。

画像の削除でWi-Fi(Linux)をonにできるようになった

ここで、動作確認していたら問題が見付かった。Linuxを起動させないようにするsleepの待ち時間が想定よりかなり短いことが分かった。調べたら、約1日は持つと思っていた"sleep 100000"が約4分で終わってしまった。どういう訳か、単位が秒でなく1/416秒程度だったようだ。仕方ないので、約1時間ごとに繰り返すように、以下のようにした(調べたところでは、アドレスe00000にジャンプするとプログラムが(再)起動するようなので、そうした)。

sleep 1440000; go e00000

ようやく、実使用時の操作方法でPCに画像を転送できるように(実際にはPCから画像が取り込めるように)なったと思いきや、更に大きな落とし穴があった。

デジカメの省電力(自動電源off)機能だ。

今の状態ではWi-Fiでの転送速度はUSBに比べれば遅いが、改良していくら高速化しても、大量の画像を転送しているうちにデジカメの電源が切れる可能性が0にならないのだ。マニュアルによれば、5分で切れる(時間は変更不可・・・)。今日測定したら、1枚の転送に約6秒掛かっていたので、50枚以上取り込もうとしたら切れる。いくら高速化したって(現実には10倍だって無理だろう)、いつかは切れる。一方、USB(PTP)の場合は、カメラが自分で転送中と分かっているから、おそらく絶対に切れない。自分で転送しているのに切るのなら、とんでもない間抜けだ。

カメラは、挿さっているSDが勝手にWi-Fiで転送しているなんてことは知る由がないし、SDからカメラに「ちょっと電源切らないで」なんて言えないので、それを防ぐにはデジカメの省電力機能をoffにするしかないが、使っているうちに自分で電源を切り忘れる可能性があるから嫌だし、転送のたびに設定を変えるのは面倒だ(それならケーブルを繋ぐ方がいい)。

「Wi-Fi内蔵SD」は本質的に駄目だったのだ。

確かに、ちょっと前に見たページにも省電力機能と競合するのでWi-Fi SDは下火になったようなことが書いてあった。。。 これって、最初っから太刀打ちできないとか腐っているもの(例: 竹槍)を気合や根性でなんとかしようとしたけど結局は無駄で、他所の賢い人が考えた素性のいいものに完敗するという、日本の伝統ではないか!w (多分、「本物」は、この期に及んでも分割転送とかいろいろやるんだろうな・・・ 僕はもうお腹いっぱいだが)

散々苦労したし、渾身のシステムができそうでわくわくしていたものの、結局はお蔵入りだ。がっかりしたが、まあ、随分遊べて(ちょっとしたハッカーの真似事?w)おもしろかったし、いろいろなことが分かったので良しとしたい。

が、すごく疲れたー。

これで安心して本当に仕舞えるかな(micro SDだけ残してさっさと捨てたいくらいだw)。

最後に一言:

駄目なものはいくら頑張ったって無駄。

 

PS. それにしても、Air Cardの中をかなりいろいろ見たが、これまでに書いた以外にも山ほどまともに動かない/作っていない・手抜きなところが多く、いかにも「中華クオリティ」(ただし、本当はどの国の人が作ったのかは知らない)だと思った。まあ、それでもそれなりに売れてそれなりに動いているのだから、逆に感心する。でも、それが結局は、あのとんでもない評価に繋がっているのだろう。やっぱり、手抜きはいけない。

(19:55 画像を追加)

  • wifi機能付のSDカード

    wifi機能付のSDカード

    wifi機能、つまり、無線LANを使った通信機能のあるSDカードがある程度広まった感があるのでここで…

  •   0
  •   0

先日から頑張っていたPQI Air Card II(以下、Air Card)は諦めた。いろいろ苦労して、さっきデジカメからPCに画像を取り込めるようにはなったのだが、その過程で、消費電力が大きいどころでない、致命的で解決できない問題に気付いたのだ。実使用時のように、Air Cardをデジカメに入れて、撮影・表示してPCから画像を取り込もうとして、気付いた。

Air Cardは中でLinuxが動いている。それが最大の(魅力であり、)欠陥だ。

Linuxは、Windowsと同様、起動が遅い。いくら頑張っても、一瞬では起動できない。スマフォのAndoridもLinuxベースだが、使っていない時にスリープしているだけで、基本的にはいつも動いているから、頻繁に画面をon/offしたって問題がない(そして、ご存知のように、本当に電源をon/offする時はすごく時間が掛かる)。

ところが、デジカメは全く違う。撮影時は、撮ったら電池を節約するために電源を小まめに切る。表示の時も同様だ。そのたびに、SDカードの中の可哀想なLinuxは(おそらく途中まで)起動しては、何の前触れもなくブチっと電源を切られる。Linuxは(Windows同様、)終了時にもちゃんとした手順を踏まないといけないから、そんなことを年中やっていたら、いつかはSDカードが壊れる(論理的、あるいは、物理的に)。だから、「すぐ壊れる」、「動かなくなった」というレビューが多いのかも知れない。

仮に、システムがうまくできていて、そんなことしても問題が生じないようになっていたって、僕は使う気になれない。撮影・表示のたびに中で「ブチブチ」しているのを想像するだけで、冷や汗が出そうだ。

これがもし、SDカードでなく、デジカメ本体の中で(Linuxである必要はないのだが)Linuxが動いていたら、まだマシだろう。スマフォのように、電源を切ったように見せかけてスリープとかスタンバイさせればいいのだ。あるいは、電源を切って一定のアイドル時間が経過したら本当に終了すようにし、その処理が完了するまでは電池で動かしておくなどだ。

デジカメにWi-Fiを後付けするという発想は良かったと思うが、(他のいろいろな失敗作と同様、)やり方が悪かった。安易なノリだけで進めてしまったとか、できたから売るという姿勢だったのかも知れない。元の開発キット(→ 片鱗が見える; 元にしていると思われる、KeyASICのWi-Fi SDカード Mcard)を見ると、まあ、普通に良くある物で、デジカメ用のWi-Fi SDのようなことはできるのだが、実際に製品化した時のことは余り考えていないことが想像できる。まあ、最初のコンセプトの時点ではそれでいいのだが、実際の使われ方をちゃんと考えて売り込まないと、絵に描いた餅にしかならないことの典型だ。何らかの製品はできるけど、(例によって、製品化を押し付けられた開発者が多大な苦労をしたって)使い物にならない物しかできないし、売れない。その結果がこのひどいレビューサマリーだ。

PQI Air Card IIのレビュー結果。。。

他にも以下のような問題があった。

  • 消費電力が大きい。
  • Air Card自体やPCにマウントするためのソフト(curlftpfs※)の動作の安定性が悪い。
    • Air Cardが起動しない(Wi-Fi接続しない)ことがある。
    • curlftpfsでマウント・アンマウントできないことがある。
    • curlftpfsを使うと、他のプロセスがハングすることがある。
  • Air Cardの起動が遅い(Wi-Fi接続できるまで30秒くらい掛かる)。

※curlftpfs(FTPサーバをPCにマウントするソフト)はAir Cardとは関係ないが、PCから画像を取り込むのに、Air Cardの改造を最小限にしようとしたために使用した。

消費電力には目をつぶっても※、2, 3番目のありさまでは、普通に気軽に使える状態(例: 先日構築したスマフォの画像の自動転送は、とてもいい感じに動くようになった。僕は、デジカメでもそれができるのを夢見ていた)には、まずならなそうだと思った。

別の投稿のPS3に書いたが、Linuxを動かしていなくても消費電力が大きいことが分かったので、これ以上減らせる可能性はほとんどない。(3/27 12:12追記)

という訳で、諦めた。

 

Air Card自体はおもしろい製品ではあるのだが、何か他に使えるかというと、残念ながらない。いわゆる"IoT"用途が思い付くが、センサなどの外部入力ができないし、基本機能も性能も悪く、拡張性もなく、小さ過ぎてハードの改造もできず、OSも凄まじく古いので、全くつぶしが効かない。これを普通に使えるようにするために苦労するんだったら、普通のラズベリーパイなどの方がずっといい。値段も安い。(いずれにしても、僕は趣味でそういうのをいじる気にはならないからパスだがw)

なお、FlashAirにも同様の問題はありそうだが、あちらはフラッシュメモリが内蔵で汎用SDカードでないから、ブチブチ対策ができそうだし、OSはLinuxではないかも知れないし、中にバックアップ電源が入っているかも知れないので、少しは安定しているのかも知れない。でも、僕はやっぱり使わないだろう。

という訳で、良くある、「コンセプトは良かったんだけどねぇ・・・」の典型だった。僕も、もう少しそもそものところから考えれば良かった。「あの小さい中でLinuxが動いている」ということだけで目がくらみ、「これはすごい!」と思考停止してしまった。まだまだ甘いね。

 

PS. 文句を言うばかりでなく、どうすればできるかを考えたら、ハードでWi-Fiやストレージ処理のほとんどを実現すればいいような気がする。今でも低レベルのWi-FiやSDカードの処理はハードでやっているが、Linuxじゃなくても(理想はOSなしで)簡単に使えるようなチップなら良さそうだ(ただ、低レベルの通信だけじゃなくて、各種プロトコルが要るから、結構難しい気はする。それでも、そういう製品はあるようだ)。

まあ、Air Card自体が(部品化されているという意味で)「ハード」と言えばそうなのだが、そう言うのであれば、「まったく出来が悪過ぎるハード」だとしか言いようがない。

それから、Wi-Fiのon/offスイッチは必須だ。スイッチがあれば、消費電力だけでなく、かなりの「ブチブチ対策」になる。それならLinuxでもまだ可能性がある。スイッチがある製品はez Shareだけだが、現実的な技術や費用でできることと実際の使い方を良く考えたのかも知れない。そこには感心する。

PS2. 「諦めた」とは書きつつも、例によってしつこくあがいてみたのだが、やっぱり、Air Cardはどうにもならない。一番の問題に対処すべく、電源on時にLinuxを起動しなくもできるようにしたいと思って四苦八苦したが、PCとAir CardのOSのバージョンが乖離し過ぎているためにいろいろな不整合が噴出して、前段階(基本的なプログラム(busybox)のコンパイル)すらままならなかった。

そもそも、ソフト的に選択できるようにしたとして、実際に(人が)Linuxを起動するかどうかを手軽に選択する手段がない。あの小ささでは電気的スイッチを付けるのは無理だ(ライトプロテクトスイッチは、実はどこにも繋がっていない)。せいぜい、「特定の画像を削除して」とかなら可能そうだが、それを実装するのも容易ではない(でも可能かもなぁ。でも疲れたなぁ・・・)。

※(3/27 12:14追記) 本文に追記したように、Linuxを動かしていなくても消費電力が大きいことが分かったので、この検討は意味がなかった。

(3/30 10:02追記) 興味があったのでその後も試してみた。まず、program.binは(更新専用のためか)u-bootのサブセットで、hushの機能(ifや&&など)が使えない。そのため、program.binの中のu-bootコマンド文字列をパッチして「特定の画像があったらLinuxを起動させない」ようにすることはできなかった。

次に、ある方が、GPLのために公開されていたAir CardまたはTranscend Wi-Fi SD Card(実体はKeyASICのKA2000)のソースプログラムなどを公開していたので、その中のu-bootを改造して使えるか試した。Ubuntu 12なら、Sourcery G++ Lite 2011-03-42 (ARM EABI)でコンパイルでき、u-boot.binを"program.bin"としてmicro SDに置くことで起動もできた。

ただし、公開されたソースと実機の構成が異なるのか、今ひとつうまく動作しなかった。例えば、u-bootのgoコマンドやSDや内蔵フラッシュからのファイル読み込み(fatload, sf loadコマンド)はうまく動作しないことが多かった。構成が違うためなのか私の使い方が悪いのかは不明である。外部に何も出力できないので状態の確認が難しいし、実機の詳細な情報がないので、調整のしようがない。

また、このプラットフォームのu-bootのsleepコマンドは単なるビジーループなので、消費電力を減らすためには使えない(前の投稿のPS3や上記の「Linuxを動かしていなくても消費電力が大き」かったのはそのせいだろう)。クロックの周波数を下げるとか各デバイスやCPUを停めるなどの処理が要るが、実機の情報がないので困難だ。

他に可能性があるのは、program.binをうまく改造することかLinuxの起動の初期に停止させる(デバイスの初期化プログラムがちゃんとあるので、期待する処理ができる可能性はある)ことだが、前者は至難の技だし後者は余り好ましくない(Linuxは内蔵フラッシュから起動するので、起動を中断させても大きな問題は起こらなそうではあるが)うえにLinuxをビルドするのは大掛かりだ。

という訳で、私の希望どおりにAir Cardを改良・改造するのは、ほとんど不可能だと思う。

PS3. スイッチでWi-Fiのon/off可能なeZ Shareについて調べたが、一番の問題は専用アプリまたはブラウザからのアクセスしかできないことだ。それではLinuxから画像を取り込むのがなかなか面倒だ(ページのスクレーピング?)。あと、例によって、サポートがかなり心許ない。質問しようとしたのだが、webに書かれたメールアドレスはエラーで戻って来た。それで、Amazonに出している店(メーカーかその関連企業)に出したら結構アバウトな回答だった。例えば、消費電力を聞いているのにスイッチの使い方を答えて来たり、起動時間は「速い」という回答だったり・・・ この調子では、質問の答えが良くても実際は違うことがありそうだから、買って試すしかない※。けれど、上記のとおり、通信がしょぼいので止めた。

※再度消費電力について質問したら、回答は"Thank you!"だった。脳味噌あるのかな? 論外以下で却下だ。 (3/27 16:53)

あと、内部画像(→ , )を見ただけでの推測だが、Wi-Fiのon/offは本当にWi-Fiチップだけon/offしている(チップの電源制御端子(CHIP_PWD_L)をon/offしていると想像する)ようだ。それでも消費電力が小さければいいが、試してみないとなんとも言えない。

画像を見て今気付いたのだが、これはmicro SDを使っているけど、抜けないように(そうとは分からないように?)封入しているのか。道理でカードが汚れている訳だ。なかなかすごい・・・

(2/26 7:06 わずかに修正, 8:08 Mcardへのリンクを追加; 3/27 9:21 PS2, PS3を追記, 12:14 Linuxを動かしていない時も消費電力が大きい件を追記, 12:56 ez Shareのスイッチの件を追記, 17:48 題に追加; 3/30 10:02 PS2に追記)

  •   0
  •   0

昨日絶賛したPQI Air Card II(以下、Air Card)。引き続き、デジカメ画像取り込みシステムの構築作業を続けていて、ふと思った。先日のLEDランプを測った時の治具で消費電力が測れるのではと。早速やってみたら、何とか測れた。

単体では無理なので、カードリーダー(I-O Data USB2-7inRW)に挿した状態で測定した。比較のため、カードなしの場合、Air Cardなしの場合(16GB micro SDをアダプタで使用)、Air CardのWi-Fi接続時と切断時(アイドル状態)を測定した。以下に結果を示す。なお、電流値は約1Ωの抵抗の両端の電圧をアナログテスターで測った。そのため、精度は低い。なお、カードのみやAir Card+SDカードの消費電力は、アダプタ込みの値からアダプタ単体の値を減算して求めた。また、電力は電圧を5Vとして計算した。

  • カードなし(アダプタ単体): 60mA (300mW)
  • SDカードのみ(Air Cardなし): 70mA (350mW) → SDカードのみ: 10mA (50mW)
  • Air Card
    • 起動直後: 120mA (600mW) → Air Card+SDカード: 60mA (300mW)
    • Wi-Fi on時(APに接続状態): 220mA (1.1W) → Air Card+SDカード: 160mA (800mW)
    • Wi-Fi off時: 160mA (800mW) → Air Card+SDカード: 100mA (500mW)

Air Cardの消費電力がかなり大きいことが分かり、愕然とした。Wi-Fiがonの時は仕方ないにしても、offにすれば減ると思い込んでいたので、offにしてもほとんど減らないのは想定外だった。そこで、何とか減らせないものかと試行錯誤した。

ほとんどは効果がなかったが、Wi-Fiの電力管理の設定で減らせた。具体的には、Air Cardにログインして以下のコマンドを実行する。

wl PM 2

"2"は"1"でも良い。2だと高速(状態変化に速く適応する)に電力を制御するようだ。この設定をしてもWi-Fi off時の消費電力は変わらないが、on時(APに接続)のアイドル時の電力が下がることが分かった。"2"の場合の測定結果を以下に示す。

  • Air Card (電力管理設定あり)
    • Wi-Fi on時(APに接続、アイドル状態)、Wi-Fi off時: 160mA (800mW) → Air Card+SDカード: 100mA (500mW)

つまり、Air Cardのアイドル時の消費電力は、Wi-Fiのon/offに関わらず約100mA (500mW)となる。どうにも信じ難いのだが、Wi-Fi部でなく基本部が電気を食っているようだ(あるいは、電力制御機能がなくて、Wi-Fiを"off"にしても電気は流れているのかも知れない)。そして、上記のとおり、SDカードのみだと10mA (50mW)なので、Air Cardを使うと消費電力が10倍になる計算で、更に愕然とした。ただ、調べたところでは、東芝のFlashAirはWi-Fiをoffにすると消費電力が小さくなるが、Air CardのWi-Fi off時の消費電力は大きいままだ。(3/25 4:44 訂正)

(3/25 4:44) SiSO-LABによれば、FlashAir単体の消費電力は以下のとおりだったので、Air CardのWi-Fi off時の消費電力はFlashAirの5倍程度と、特に大きい。

Wi-Fi on時: 622mW, Wi-Fi off時: 104mW

普通のLinuxだと、CPUやSDカードなどのクロック周波数を下げて消費電力を減らせる可能性があるのだが、Air Cardにはそのようなコマンドはない。また、poweroffのような、システムを停めるコマンドもない(別の製品(Flucard)のpoweroffコマンドを試したが、効果はなかった)。

ただ、カメラ本体の消費電力が大きい場合には、SDカード部の消費電力が増えてもそれほど影響がない可能性があるので、カメラ(IXY Digital 3000IS)の消費電力を調べてみた。CIPAの測定値と連続再生時間は以下のとおりである。

画面表示時: 280枚, 再生時間: 6時間
バッテリ: NB-5L: 3.7V, 1120(1050)mAh, 3.9Wh

それで、CIPAの測定方法から、撮影時のおおよその連続使用時間を求めて平均消費電力を推定しようとした。CIPAの測定方法の概略は、以下のとおりである。

  • 30s間隔で撮影
  • 2回に1回フラッシュ
  • 10枚ごとに電源off, on

そこで、平均撮影間隔を1.5枚/分とすると、280枚では3.1時間なので、平均消費電力は

3.9Wh/3.1h= 1.25W

となる。Air Cardのアイドル時の消費電力は上記のとおり0.5Wなので、約40%の増加(撮影可能枚数は40%減)となり、やっぱり大きい。なお、再生時の消費電力は3.9Wh/6h= 650mWなので、Air Cardによってほぼ倍増する(再生可能時間は1/2)計算になる。

これでは使う意味がない気がして来た。無理をしてでも消費電力を下げるには、例えば、micro SDをアダプタでカメラに入れて撮影し、家に戻ってPCに画像を転送する時だけAir Cardに挿し直すことだが、手間が増えて何がいいのか分からない。ケーブルがないことだけがメリットだが、カードを挿し替えるくらいならカードリーダーを使う方がいい。。。

作業を続けるべきか迷う(やる気は結構下がったw)が、とりあえず作って、ひととおり使って、電池がどのくらい持つのか確かめてみたい。

 

PS. 一つ、Air Cardが使える可能性があるのは、カードリーダーの動作時の消費電力が大きい場合だ。カードを挿していない時の消費電力は上記のように低いけれど、カードを挿して動かすと増える可能性がある。その時にはAir Card+SDカード(カードのみも)の消費電力が相対的に減るので、Air Cardによる消費電力の増加は少なくなる。これを調べるにはSDカードの端子を引き出さなければいけないので、無理だ。本当に使ってみるしかない。

いやいや、良く考えると、SDカードのみの場合の消費電力も小さいから、カードが挿さっていなくてもカードリーダーは動いているようだ。そして、仮にSDカードの消費電力が0Wだったとしても、カードリーダー単体の消費電力が50mW増えて、Air Cardがその分減って450mWになる程度だ。「詰んだ」ってやつかな。。。

PS2. もう一つの可能性は、Air CardのLinuxのカスタマイズ部分を解読して改造することだ。Linuxが起動するまでは消費電力が低いようなので、その逆に、Wi-Fiを使わなくなったらLinuxが起動する前の状態に戻せばいい。はずだが、かなり面倒なうえに、それで消費電力が減らせるかどうかは不明だ。そもそも、僕はAir Cardで遊びたい訳ではない(おもしろかったのは確かだが、機能が貧弱過ぎるので、余りおもしろくない)ので、FlashAirに乗り換えるほうがいい。 (3/25 9:31)

PS3. Linuxが起動しなければ(各種デバイスが動かないから)消費電力が低いのかどうか確かめてみた。別の投稿のPS2にも書いたように、Air Card用のプログラムをコンパイルすることすら困難だったので、ブートローダ(u-boot)ファームウェア更新プログラム(program.bin)を改造した。Air Cardの更新ファームウェアのZIPを展開したうち※のprogram.binというファイルがブートローダ更新プログラムである。その中に書かれたスクリプト(u-bootのサブセット?)でファームの更新とLinuxの起動を行っているようなので、u-bootの終了や長時間のスリープに置き換えて、Linuxを起動させないようにした。具体的には、以下のようにして改造した。

sed -e 's/bootcmd=run set_bootargs; run bootf/bootcmd=sleep 123456; sleep 234567/g' -e 's/fatload mmc/exit; /g' program.bin > /tmp/program.bin

※PQI Air Card IIのファームウェアファイルの内容(推測)は以下のとおり。

    • program.bin: ブートローダ(u-boot) ファームウェア更新プログラム
    • mtd_jffs2.bin: /mnt/mtdのファイルシステムの内容
    • Image3: Linuxカーネル
    • initramfs3.gz: Linuxのルートファイルシステム(/)の内容
    • autoload.tbl: (ない場合もある)不明。読み込むファイル一覧?

試すには、改造したprogram.binと残りのファームをmicro SDに書き込んで電源を入れてしばらく待てば良い(元に戻すには、本来のファームをmicro SDに書き込んで電源を入れてしばらく待てば良い)。

残念ながら、結果は駄目だった。Air CardのAPはできていないので、確実にLinuxは起動していないのだが、消費電力は減っておらず、上記のアイドル時の消費電力と同じ100mA (500mW)だった。

結局、そもそもAir Card自体が何もしなくても消費電力が大きいようだ。ここから減らそうとしたら、電源管理モジュールの機能を使ってシステム(ハード)の動作を停止させる必要がありそうだが、そういう機能があるのか不明だし、この状態ではWi-Fiモジュールは動作していないことが確実なので、それ以外の消費が大きいということなので、まず減らないだろう。

という訳で、Air Cardが日の目を見ることはなさそうだ。

(3/25 4:44 FlashAirの消費電力を訂正; 8:56 題に追加、加筆・修正; 3/27 12:07 PS3を追加; 3/29 13:36 program.binの内容を訂正)

  •   0
  •   0