Archive for the ‘Android’ Category

前回、「(センサの値を)自動測定したくなった」と書いたが、半分くらいできるようになった。とりあえず、定期的にスマフォ(Nexus 4)で においセンサ(JSM-131SC)の画面を自動撮影し、その画像をPCに転送するようにした。通常は1時間に1-2回の測定なので、一日分でも画像は24-48枚にしかならず、自分で画面を読んで、手で測定値をスプレッドシートに入力するのでも苦にならない。

スマフォからセンサを常に同じ画角で撮影できるようにするため、それらを載せるスタンド(段ボール製)と自動撮影・画像転送プログラム(Automagic利用)を作った。

試行錯誤はしたが、丁度良さそうな箱があったので、それをベースにすることにした。ただ、スマフォのカメラは隅にあるため、普通にセンサの正面に載せたのでは画面が撮影できず、横にずらさないといけないのが落とし穴だった。使った箱が細かったので、スマフォを横置きにしてちゃんと写るようにすると、スマフォの重心が箱の外になって落ちてしまう。それで、最初は、スマフォをセンサに対して斜めに置いた画面は傾くが実用にはなるからいいと思ったが、やっぱり気に入らなかった。

次に、センサも斜めに置いてスマフォとセンサが平行になるようにしてみた。それなりに画面はちゃんとするが、斜めだと位置決めが難しく、完全には調整できず、やっぱり満足できなかった。

こういう本末転倒エキセントリックなこと、家電なら昔のS社、車だとH社がよくやって自爆するのかな?w 僕は好きだけどね。

結局、両方とも(普通に)箱に対して直角に置くことにし、そのためにスマフォが落ちないように横に台を追加して、ようやく満足できる画像が撮影できるようになった。ちょっとした欠点は、段ボールが結構弱く、何度もスマフォを抜き差しすると、微妙に撮影角度が変わってしまうことだが、まあ、それほど大きな問題ではない。それから、見栄えが悪いが、いつものことだw

定期撮影するプログラムは、もちろんそういうアプリは いくつかあったのだが、機能や使い勝手が今一つだったり制限があって不便だったので、Automagic(Android用グラフィカル言語)で即席に作った。指定の間隔でカメラで撮影して、90°回転して保存するという、猫でも作れそうなwとても簡単なものだ。

PCへの画像の自動転送は、以前作ってAQUOSで使っているもの(これもAutomagicで作った)がほとんどそのまま使えた。ただ、撮影したら(何分も待たずに)すぐに転送したかったので、指定のディレクトリにファイルが増えたら(= センサを撮影したら)転送するように、開始条件を追加した。

今はACアダプタで電源を供給しているので、どちらのプログラムも特に省電力の考慮は不要なので、作るのは楽だった(とはいえ、調整には結構手間が掛かった)。

自画自賛だけど、使ってみるとなかなか便利だ。何も考えなくても勝手に撮影されるので、写す手間がないし、うっかりしたり寝ている間のデータが抜けなくていい。欲を言えば、今は手で記録している、測定時の室温、湿度、外気温や天候なども同時に記録(撮影)したいが、まあ、すべての要望は満たせない(それに、今は、それらの情報は臭いには関係ないことが分かった)。あと、これだと、読む位置を決め打ち(固定)にすればOCRで測定値の抽出もできそうだが、まあ、測定が目的でないので多分しないだろう。

あと、このセットを自分に対して斜めに置いておけば、臭いなどが気になった時に測定値が(スマフォに隠れずに)見られるのもいい。

それから、作る前は気付かなかったのだが、これだとセンサとスマフォの距離が近いために画面が大きく写るので、サムネイルでも測定値が読めるから、スプレッドシートへの転記が楽でいい。あと、同じく距離が近いから画像の画素数を減らせるので、ファイルサイズが小さくて済む(1280x960画素、約500KB: 以前は約2500x3300画素で2MB前後になっていた)のもいい。

 

なお、臭いに関しては別途書きたいが、エアコンダクトを開けると駄目なようなので閉じ、換気扇を常に回して換気扇からの逆流を防ぐことを考えた。それで今は机の脇の本棚で定点観測している。ただ、エアコンに溜まった臭いを防ぐのが難しい(臭いを出さないようにすると、寒くなる)・・・

 

PS. 定期撮影機能は鳩の監視にも使えるかも知れない。鳩は短時間しか居ないから撮影間隔を短くするので、画像データが大きくなりそうだが、撮影期間を朝だけとかに限定すれば大丈夫か。まあ、鳩の場合は動体検知して動画を撮影した方が良さそうだ(できるか不明だし、既存のアプリがあればそっちが良さそうだ)。それでも、いわゆるタイムラプス動画はできるし、いろいろ使えそうな気がして来た。いずれにしても、設置・調整が一番面倒だ。 (6/21 8:00)

 

(6/22 16:36 Automagicで定期撮影するプログラムの画像を追加)

  •   0
  •   0

随分長引いていた、スマフォ(AQUOS sense lite)のCPU使用率がアイドル時でも100%のままになり、消費電力率が増える※問題が解決した。

※増えるといっても、良く書かれている「電池が激減」のようなものではなく、「なんか(前より)多いなあ」程度で、アイドル時は2%/h未満だったと思う。

この前も書いたように、最後まで分からなかった問題は、消費電力測定アプリのGsam Battery Monitor(以下、Gsam)だった。これを実行していると(= 一度でも画面を開くと)、CPU使用率が100%になったままで消費電力が増えるのだ。ただ、最初はGsamは使っていなかったので、切っ掛け(最初の問題)は、(良く書かれているように、)Google Play開発者サービスだったと推測する。去年の夏だったか、Android 9に更新した直後に消費電力率が増えた。

それで、どうしてか気になって調べているうちに、その時使っていた消費電力測定アプリ(シンプル バッテリー グラフだったと思う)が電池を食っていることが分かったのでGsamに換えたのだが*、それ以降、いろいろ原因を推測しては試し続けていたが全然直らなかった。なお、Google Play開発者サービスはいつの間にか直ったようだ(以前使っていた機種でもそういうことはあった)※。

*もう一個、My Battery Monitorも使っているが、こちらは問題ない。ただ、グラフが描けないので少し不便だ。

※キャッシュのクリアなどが効いたのかも知れない。ただ、その後でGsamを起動したので、効果が分からなかったのではないか。

今は元の消費電力率に戻って、一安心だ。例えば、昨夜から今朝に掛けてのアイドル時は0.32%/hで、「これだよこれ!」って感じだ。

 

(5/20 0:51 わずかに加筆)

  •   1
  •   0

GMBのトラックIDが変わる問題に対処しオーディオの配置が一段落し、また、先週 鳩よけを改良したら効果があったようで※、TODO・懸案が減って来たと安心していたら、またもや謎・懸案が増えた。

  • オーディオ: イコライザ設定を少し変えただけで耳閉感が再発・・・
  • ブログサーバーが突然落ちた・・・
  • スマフォの電池消費率が増えて全然直らなかった原因は、電池消費率測定アプリだった??

イコライザは、設置や設定を確定しようと特性を再度測定して確認していたら、それまで見落としていた左の156Hzの山に気付い(てしまっ)た。(参考: グラフの水色線) それで、その山を下げるためにフィルタ1個の設定を本当にほんの少し変えた(中心周波数を5Hz下げ、幅を0.02広げ、減衰量を1dB増やした)だけで、途端に耳閉感が起こるようになってしまった。時間をおいて何度か試したが、その設定にすると30分くらいで起こる。

特性は良くなったのに駄目な理由が全く分からない。変更したことで歪や位相ずれが増えたのかと思って調べてみたが、顕著な違いは見られなかった。もちろん、超低域や高域にも変化はない*。以前から気付いていた、イコライザの種類や設定に関係するものなのだろうが、今回はその経験則から外れていないし、こんなに微妙だとは思わなかった。全くお手上げなので、直す前の設定にしている。

*今、イコライザ変更後の特性(下に載せる)を確認したら、左だけ超低域(33Hz辺り)が7dBくらい増えていた。その時は、近所の工事やエアコンの騒音がたまたま入ったのだと思って居たが、これが原因なのかも知れない。全く関係ないフィルタの変更の影響が出たのだろうか? パワーがある時に確かめたい。もしかしたら、イコライザの経験則は こういうことに関連しているのだろうか。

イコライザ変更前後の特性: L: 水色(前), 紫(後); R: ピンク(前), オレンジ(後); LR: 黄緑(前), ベージュ(後)

ブログサーバーは、今朝、PCからカレンダーの予定を変更した時に落ちた感じだ。カーネルがパニック(例えでなく、こういう用語がある。要するに、「想定外の問題が起こったので落ちまーす」みたいなもの)になったようだが、パニックのためログには何も記録されておらず、仮想コンソールに出ていた断末魔の叫び(パニックのメッセージ)しかないので、全く原因不明だ。

先日のメンテ(物理サーバの移動)で仮想HWが変わったことが関係している気はするが、変わったといってもx86(64bit)機に変わりはなく、特にハードに依存させていないので、まともに動かないのがおかしい。カーネルが随分古いので、更新すれば直るかかも知れない。ただ、それなら、もう少しあとを予定していたが、OSのバージョンを上げたい。が、それはそれでかなり神経を遣うので、頻発するなら、とりあえずはカーネルかな。

スマフォの電池消費率は、去年の夏頃に気付いてずっーと試行錯誤して来たものの、どうにもならなかったのだが、先日、再起動後に現象が起こらないのに気付き、もしかして、電池消費率を測るために入れていたアプリ(GSam Battery Monitor, 以下GSam)を起動しなければ(正確には、開かなければ)、問題(電池消費率が増え、CPU使用率が100%のままになる)が起こらないのかと思って、数日間GSamを開かずに試しているが、今のところは再現していない。アイドル時の電池消費率は、以前のように0.5%/h以下(例: 昨夜から今朝の値: 0.35%/h)になっていて、満足だ。

最初に問題に気付いた時はGSamは入れていなかったので、これだけが原因ではなく、きっと、(当時の)Google Play開発者サービスが悪かったのだと思うが、実はGSamも極悪だったようだ。もしそうなら、こいつのために、ずっと試行錯誤させられて来たので損害賠償請求したいくらいだw まあ、これで直れば、懸案も謎も減るからいい。それにしても、GSamに限らず、電池消費率測定アプリは電池を食うことが多く、ミイラ取りがミイラになるようなもので、しっかりしろと言いたい。今使っているMy Battery Monitorは大丈夫そうだ。ただ、グラフが出ないのでちょっと不便ではある。

 

※鳩よけについては書こうと思っていたが、別件があって面倒だった。簡単に書くと、その前に改良した時に室外機の上用のワイヤーに隙間ができていて(下から見ても分からない)、先月の終わり頃から鳩が入り込むようになった。それで、ワイヤーを均等にし(デジカメで撮影して確認した)、余っていたステンレスワイヤーをそれらのワイヤーに緩く巻いて隙間を塞いだら、今のところは大丈夫だ。ただ、どうも、鳩はこっちが何かしてから少し経ってから来るようなので、油断はできない。

  •   0
  •   0

9:30頃出た。行きはのどかで、のんびり気持ち良く走れた。車内などは暑くて春の感じだった。そういえば、帰宅してから目が痒いので、花粉が飛び始めたのかも知れない。

道の駅きたかわべ には2時間くらいで着いた。Google地図の予想はいつも速目で、カーナビの予想時間はもっと長いので、経路を設定したあとで慌てた(実際、待ち合わせに遅れた)。久し振りに生姜焼き定食を食べた(学生時代を思い出す)。おいしかったけど、ちょっとぬるかったのが残念だった。他にも、カツカレーとか蕎麦とかいろいろ食べたいものがあったので、次に行ったら試したい。

いつものように、なおきさんと話が弾んだ。それにしても、「会食」というと堅苦しいし、「談笑」と書くと政治家みたいだし、「遊んだ」というのもおかしいので、なかなかいい表現が浮かばない。もしかして「男子会」??www

帰路はなぜか遅い車が多かった。行きと違ってちょっとイライラしたので横に逸れたら、別の車も遅く、それが居なくなったあとでスピードを出したせいで本来とは逆に曲がってしまったりして、却って遠回りになってしまったw (地図の下の方の凹部)

実は、おそらくそういう車のスピードは行きと同じくらいだったのだろうが、疲れがイライラを増したのだろう。他には、走りのペースやタイミングが微妙に僕(あるいは「普通」の車)とずれていたのかも知れない。とんでもなく遅い訳ではなかったから悪くはないけど、意図せず煽られたり事故の原因になったりするかも知れないので、周囲を良く見て運転した方がいいように思う。とはいえ、自分の安全な範囲を超えたスピードを出せというのも無茶な話だ・・・

反時計周り、139km、約8時間。

以下、今日の細かい話題いろいろ。

iVideoのモバイルルーターiV501の電池残量の謎

先日7.5時間くらい外に持ち出して帰宅したらスマフォのWi-Fiが切れていたので、電池が切れたのかと思った。ただ、iV501の電池残量は、本体の電池ランプはどういう表示になるか不明だし、webも4種類程度のアイコンだけで%では出ないので、確かめようがない。それで、今日、定期的にランプとwebのアイコンの変化を見ていたのだが、約6.5時間経過してもランプに変化はなく(電源ボタンを押すと点いて、しばらく点灯したまま)、アイコンも段階3(残量75%前後と推定)から変化がなかった。帰宅後(約8時間経過)にweb APIで残量を見たが、アイコンと同じ3だった。

実際、充電も速く、2時間以内に満充電になったので、それほど電池は減っていなかったと思われる(まあ、すべての情報がおかしい可能性もなきにしもあらずではあるが・・・)。

なので、通信状態にもよるのだろうが、8時間くらいは余裕で持つのだろう。先日Wi-Fiが切れたのは、頻繁に通信して電池がなくなったか、何かのトラブルでたまたまWi-Fiが切れたと推測する。

以上は全部推測ではあるが、昨日までは、次のレンタルでは正確な残量が分かる501HWに換えてみようかと思っていたが、そっちは2倍くらいの重さだし、結局、どちらの連続使用可能時間も8時間程度なので、長時間外に居たら外部電池が要ることに代わりはないし、iV501の電池の持ちは意外にいいので、このまま使い続けるのも悪くないと思っている。

それから、偶然の一致だとは思うが、満充電になったあとしばらく電波強度が-100dBmくらいに下がるという謎もある。いろいろバグのようなものがあるのかも知れない。

なかなか優秀なGPSロガーアプリ: Geo-Log - GPS Logger & Notebook

スマフォ(AQUOS sense lite)の電池消費率が大きくなる問題はまだ原因が分からないのだが、もしかしたら、GPSロガーアプリ(GPS Logger)が古い(新しいAndroidの前に出た版を最後に、Google Playからなくなっている)ためかと思い、近頃は別のアプリ(Geo-Log)を試している※。それがなかなか優秀で、3分間隔で記録するようにしたところ、今日8時間使っても電池は12%(他のアプリも込み)しか減っておらず、電池消費率は約1.5%/hと随分少なかった。もちろん、記録結果は上の図のように全く問題ない(記録間隔が比較的長いので、徒歩の場合には経路がショートカットになることはあるが、僕には問題ない。もちろん間隔を短くすることもできるし、移動距離での記録も設定可能だ)。

※Geo-Logは有料なのだが、なぜか、Googleからアプリ購入などに使えるクーポン(500円だったか)が来ていたので、それで安く買えた。なお、無料版(LD-Log FREE)もある。

  • 今日ガソリンを入れたら、燃費は13.4km/lだった。前回は14km/lだったので、少し落ちた。引越し関係や通院などで近場が多かったせいか。
  • 先日オイルとフィルタを交換した。オイル会員なのと他の店を探すのが面倒だったので、先日切る決心をしたいつものディーラーを許してしまったw そこは事務を除いては問題ないから、まあ妥当だろう。なぜか、担当のおじさんが居なくてちょっと寂しかったw
  • ついでに先日の不調を調べてもらったが、問題は記録されていないとのことだった。バッテリーは、寿命まであと少しあるようで(「駄目」まで1目盛り残っていた)、「この冬を越せば、もう少し使えるでしょう」とのことだった。いつもそうだが、なんとも商売気のない店で好感が持てる。
  • 累計走行距離は約56000kmになった。去年の今頃から3000kmも増えていない。

引越しとスーパー

引越したというのに、旧居の時に良く行っていたスーパーに良く行っている。そこは僕にはいろいろ(例: 価格、品揃え、味、雰囲気)「丁度いい」(= 最高ではない)のを再発見したのである。僕だけでなく、他の人もそういう良さを評価して行くために、決して安くはないその店が潰れないのかも知れない。今度は徒歩では辛いので、車で行っている。まあ、重いもの(例: ホッピーの瓶)が持てるので、それも悪くない。今日もドライブ帰りに寄った。

ひらがなの氾濫を憂う。

いつからか、(今日の目的地のような)固有名詞のひらがな書きが偏重されるようになったが、文章に書いた時に読みにくい。僕としては、本当にひらがなの効果を狙う場合やネタ以外では、ひらがなだけで表記するのは止めた方がいいと思う。例えば、題の「道の駅きたかわべ へ−」だって、普通に空白を入れずに「道の駅きたかわべへ−」ではどこで切るのか即座に分からず、見た目も何かおかしいではないか。

(稿を別にするのが面倒で、少しずついろいろな話題を盛り込んだので、カテゴリが多くなった。)

  •   0
  •   0

注意 3か月くらいiVideoを使って何度かトラブルがあったが、SIM・ルーターの管理や障害対応が全く適切でないと感じた。更に、通信障害が起こっても、通信に関してはキャリア任せなのでトラブルシューティングができず、機材(SIM・ルーター)の交換しかできず、それも「様子見しろ」と言って渋るし、交換されるにしても届くのが数日後で、その間は障害はそのままなので、iVideoをメインに使うのはリスクが高過ぎることが分かった。その経験から、iVideoを重要な用途(例: 光回線の代わり)に使うことは全く推奨しない。

具体例については、「[悲報] 完全無線は時期尚早でござった。」を参照のこと。(2020/3/25 6:34)


信じられないことに、1/10に届いてから今のところ何も問題ない。正確には問題はあるが、iVideoでなく こっちの問題だw

今までの通信データ量は測定する箇所やソフトによって異なるが、概ね5-8GBである。これなら、SIMの上限の900GB/月にはまず達しないだろう。良くある通信量による速度制限は3日で10GBなので(そういう制限があるとは書いてなかった)、それには掛かっていないから、隠れた制限の有無はまだ分からないが、少なくとも、説明にあった、他の人に迷惑を掛けるほどは使っていないようだ。参考までに、PCでの通信データ量と通信速度のグラフを載せる。

Spotifyを聴いている時は ほぼ一定の傾きでデータ量が増加している感じだ。たまにデータ量が急増する(速度のグラフが尖っている時)のはオンラインストレージに自動バックアップしているか、サーバをローカルにバックアップしている時である。なお、時々データ量が減るのは測定プログラムのバグである(テザリングのoff/onがうまく処理できていない)。

たまに通信速度を測ってみるが、安定の10Mbps程度だw 今日一回だけ、PCからのアクセスがすごく遅かったことがあったが、間違ってテザリングを断続させたせいかも知れない。また、動画はほとんど観ないが、特に問題なさそうだ。それから、突然通信が途切れることもない(ちょっと前に、PCのネットワークインタフェースが一瞬落ちて、すぐに繋がるということがあったが、頻発はしていないし、自動的に回復するから大きな問題はなさそうだ)。

そういう訳で、今までのところ、iVideoのSIMは、僕の日常的な使用に関しては何も問題がない。まあ、無線通信自体は大手キャリアのものだから当たり前なのかも知れないが、ここまで問題がないのには感心する。あと、ルータ代わりに使っている古いスマフォ(Nexus 4)も、過酷な使用に良く耐えているものだw

今までに見付かった問題を以下に挙げる。いずれも、iVideoには関係ないことである。

  • LTE通信用スマフォ(Nexus)の電池が切れる可能性
    • USBテザリングしているデスクトップPCをスリープさせると、USBに電源電圧は掛かっていてテザリングは切れないものの、なぜかNexusが充電しなくなってしまう。
    • Wi-Fiテザリングをしているせいか減る速度は速く(約12%/hだった)、約8時間で切れる計算だ。 → (1/13 3:14) その後、アプリを減らしてみたら約8%/hになって、約12時間まで伸びた。これくらいなら、切れる心配は少なそうだ。
    • いろいろ試したが対処できなかったので、何らかの理由でLTEルータを買わない時に改めて考えることにした。
    • 仮に電池が切れても、スリープ中なのでデスクトップPCは使っていないので、Wi-Fiテザリングをしているスマフォ(AQUOS sense lite)がモバイル通信になる程度で大きな問題はない。
  • スマフォ(AQUOS)からPCへのLAN経由の画像転送ができない。
    • (前回書いたもの) 対処は可能だが面倒なので、これも何らかの理由でLTEルータを買わない時に考えることにした。
  • 耳閉感や耳鳴りが再発
    • (これも前回書いたもの) どうも、中継用に使っていたPC(Vision-HT)のファンではなく、疲れや寝不足によるようだ。なかなか厄介だ。
  • 突然、PC(Linux)から通信ができなくなった。 (1/16 5:11追記)
    • Googleなどへのpingも通らない。一旦、LANを切断しても変わらなかった。
    • 「いよいよ速度制限が掛かってしまったか・・・」と思ったが、スマフォ(AQUOS)からは問題なかった。
      • → LTE接続用スマフォ(Nexus)のUSBテザリングをoff/onしたら直った。
      • やっぱり、スマフォをモバイルルータにするのは無理があるようで、ちゃんと使うならルータが必要だ。ちなみに、現時点でNexusでのモバイルの通信データ量は約20GBになっていた。

ルータの候補を探したが、余り高いものは買いたくないので、以下の2つしかない。

  • au Speed Wi-Fi HOME WHITE L01s HWS32SWA: 約8千円-1.2万円
  • NEC Aterm PA-HT100LN: 約1.2万円

通信速度と消費電力と小ささでNECが良さそうだ。速度はHWS32SWAのカタログ値は大きいが、WiMAXも合わせてCA(carrier aggregation)した場合なので、実際にはそれほど出ないと思う。そもそも、このSIMにすごい速さを期待するのは、八百屋で魚を求めるようなものだw あと、本当にあるとは思えないのだが、HWS32SWAのメーカーH社はスパイウェアが気になる。

モバイルルータも考えたが、Ethernetがないので不便だ。まあ、PCにWi-Fiの子機を付ければいいのだが、Linuxでちゃんと動く子機がなかなか少ないようで、失敗するのが嫌なのだ。それに、モバイルルータは内蔵電池の消耗が気になるので避けたい。

ルータを検討していて気付いてしまったのだが、固定ルータにすると、前回書いたようには外出時に簡単に持っていけない問題が発覚した。スマフォをルータにするのは安定性や耐久性(特に電池)や管理・保守の点で難点があるので、通常は固定ルータを使い、外に持ち出す時にはSIMを抜いてスマフォ(Nexus)に挿すのが良さそうだ。が、SIMのサイズが違うこともあるので、面倒でやらなそうだな・・・ 早くも夢は破れたw

てな訳で、来週末辺りまで問題がなければ、OCNを解約してそのまま光回線は終了にして、LTEルータを注文したい。今度は、届いてから「あっ!」ってことがないようにしたいwww

  •   0
  •   1

実家で聴いたスマフォ(AQUOS sense lite)の音が大変悪くて、以前設定したイコライザを使ったり、再度耳で調整したのだが、どうも今ひとつだった。それで、もちろんスマフォに多くは求めないながらも、興味が湧いたので、どういう周波数特性なのか測り、その結果でイコライザを調整してみようと思った。

実は、そもそもは年末に修理から返って来たオーディオインタフェース(Focusrite Scarlett Solo)の動作確認に、PC(オーディオ)のスピーカーの特性を測定しようと思っていたのだが、スマフォの特性が気になったので、そっちをすることにした。なお、スピーカーの特性も測定したが、問題なかった。

手で持って聴く場合を想定して、(いつものように段ボールで)簡単なホルダーを作って測定してみた。すると、耳は全然あてにならないことが改めて分かって、毎度のことながら愕然としたw

なお、スマフォの特性を測定するには、PCの出すテスト信号をスマフォから出す必要があるが、PCのスピーカーと違って普通には出力できない。僕のスマフォでは(ネットのテザリングとは違って)AndroidがUSBのサウンドデバイスになることはなさそうなので、マイク端子に音を入れてスピーカーから出すアプリを使おうかと思って探したのだが、どうも直接的でなくて気に入らなかったので更に検索したら、すごく丁度いい方法があって助かった(→ 参照)。

それは、LinuxのPulseAudio(サウンド系)が出す音をネットでスマフォに送ってスピーカーから出すという、最も直接的な方法である。PulseAudioはなかなか高機能で、音をネットに出すこともできるようだ(JACK Audioでもできるようだが、やったことがないし、やるのは怖いし面倒だw)。スマフォ側は、それを受けるアプリ(Simple Protocol Player)をインストールして動かしたら、無事に音が出た。

ただし、使うイコライザ(例: Equalizer Pie(後述))によってはSimple Protocol Playerの音に効かないので、その時にはSoundWire (free)というのを使った。どうしてか、PulseAudioと違ってかなり(数秒)遅延があるのだが、特性を測定するソフト(REW)でトリガー音で測定開始するようにしたら、うまく測定できた。

SoundWireと同様の方法にVLCを使うのもあったが、やっぱり遅延が大きく、トリガー音で測定開始できることに気付く前だったので諦めた(トリガー音を使うなら、SoundWireよりも手軽でいいと思う)。エンコード用バッファの関係で遅延するのだろうか?

(1/4 4:50) スマフォの通信データ量をチェックして驚いたのだが、PulseAudioの転送はデータ量がとんでもない(測定のために1-数時間使っていただけで、1GB近くに達していた)ので、間違ってモバイル回線を使わないように注意が必要だ。圧縮していないせいはあるにしても、随分多い。また、SoundWireもPulseAudioの1/3程度と多かった。

耳で調整した時には、2kHzや4kHz辺りに山があるように感じた(その辺りを下げたら、感じが良くなった気がしたため)のだが、実際には山は7.5kHz付近にあった。。。

特性を見たら、2kHzや4kHz辺りなんて平らもいいところで、僕の耳は節穴かと言いたいが、聴覚特性に関係しているのかも知れない。等ラウドネス曲線では500Hz-4kHz辺り(特に4kHz)の感度がいいから大きく聞こえることや、錯覚のようなものがあるのかも知れない。

あと、うすうす感じては居たが、このスマフォは中低音が全く出ず、700Hz以下は期待できない。ここまではっきり出ないと、その割り切りに却って感心するw (某●ニー社とかだと、「何とかベース」とか言って、重低音を無理やりして出して宣伝しそうじゃないですか) 逆に、超高域(15kHz辺りまでは余裕だし、20kHz辺りまでも何とか)が出ているのが意外だし不思議だ。

それで、中低域は諦めるとして、イコライザアプリ(Equalizer Pro)で補正してみた。まあまあ山が下がったのだが、Equalizer Proは7.5kHz付近の調整ができないので、今ひとつ納得できなかった。それで他のイコライザを探したら、7.5kHzの近くの6.3kHzや10kHzが調整できる、Equalizer Pieというのが見付かって試してみたら、かなりいい感じに補正できた

ただ、どういう訳か、Equalizer Pieはイコライジングできるアプリが少ないようで、Spotifyには使えるのだが、YouTubeアプリやOperaには使えない。まあ、Spotifyに使えれば問題ないのだが、なんか気に入らないので、Equalizer Proを再調整してみたら、許せるくらいになった

最後に、実際にYouTubeにアップロードされていた曲(Sugar 「ウエディング・ベル」(1981))の冒頭に対して適用した例を示す(あらかじめ済みません(どうでもいいけど"Apology in advance."ってあるのだろうか?)。フリー音源を見付けるのが面倒だったので、好きな曲を使いました。権利者の方からクレームを頂いたら取り下げて入れ替えます)。

補正によって、高域のギラギラした感じ・うるささが大分改善された(でも、音量の違いやオーディオのスピーカーで聴くせいか、今聴くと余りうるさくない?)。ただ、オーディオのスピーカーでは中低域がちゃんと出ているので、そっちを聴くと「ああ、やっぱりこれだよなー」ってなってしまう。

てな訳で、このくらいの測定・調整なら、手軽にできて楽しいものだw

書いたあとで思ったが、楽器の音(調律ではない)は耳で作るのだと思うが(これはこれで、すごくおもしろそうだ!)、オーディオ機器・装置は耳では無理だろう。もちろん、後者は、あくまでも無色透明な音、平坦な特性を目指す僕の指向での話である。

 

PS. 測定中にスマフォがホルダから落ちてしまって、コネクタから着地して割れちゃったかなとか慌てたが、運良く無傷だった。

  •   0
  •   0

「一体何なんだ」と言いたいが、前回の投稿の後、昨日から今日に掛けて更にトラブルが重なって起こった。

  • スマフォ(AQUOS sense lite)のアイドル時の消費電力率が増える現象が再発した。: 原因不明
  • 自宅とサーバのオンラインバックアップのエラー: 原因不明(「たまに起こる」としか言えない)・・・
  • サーバからの上記のエラーやその他の通知が、Gmailの迷惑メール判定で何通か届いていなかった。: 近頃、誤判定が増えた感じ。

スマフォの消費電力率の問題は今までにも起こっていて、何度も試行錯誤して直ったと思ったのに解決していなくてがっかりした。増えるといっても、長時間アイドル時に平均0.6%/h以下のものが1%/h近くになる程度なのだが、アプリ(My battery monitorなど)で見ると、アイドル状態なのにアクティブ率が100%のままで(= スリープしていない)下がらず、どうも気分が悪い。どうしても直らないようなら、定期的に再起動させようかと思う。が、再起動も電力を食うのでどっちが得だろうか?

オンラインバックアップの問題も今までにも何度か起こっていて、主な直接的な原因は、たまにバックアップソフト(duplicacy)の内部状態とストレージ(Backblaze B2)の状態が合わなくなることのようだ。起こる都度、暫定対処や様子見(再実行で直ることがある)をして来た。それで大きな問題はなさそうなのだが、本当に問題ないかが分からないのが怖い。

本当の原因はネットワークかバックアップソフト(自作+duplicacy)かストレージのどれかなのだろうが、どれかは不明だ。おそらくduplicacy(通信エラーに対するロバスト性が足りない)だとは思うが、サポート依頼を出すにも説明が困難ではある(でも、出せばスパっと分かってくれることもある)。エラーはサーバのバックアップで起こることが多いので、とりあえず、ネットワークへの送信速度を下げてみた。

Gmailの問題は初めて気付いた。今までにも迷惑判定で落とされたものがあるかも知れないが、仕方ない(「なんかおかしい」ということはあった)。たちが悪いのは、Gmailの迷惑メールはThunderbirdの迷惑メールフォルダには出ないことが多くて(出ることもある)気付かないことだ。Googleの商売のせいか、G Suite(有料版)でないと迷惑メール判定の強度調整(そういうのがあればの話)ができないようなので、落とすと困る差出人からのは迷惑メールにしないフィルタを登録してその場しのぎをし、更に、サーバからの通知メールはGmailに送らないようにした。

根本的な対処には、可能な限りGmailを使わない方がいいのだろうが、(アカウントの生成や破棄が)手軽で容量はふんだんだし、Androidには必須なので、根絶はなかなか難しい。。。 とりあえずは、重要な用途には使わない方が良さそうだw

あんなの飾りです。普通の人にはそれが分からんのですよ??

 

題は見直し中にSpotifyで掛かったより。(9:52)

PS. 更に、ついさっきはUbuntuの更新リポジトリの国内サーバにも接続できなかった。一時的なものだろうが、随分重なるものだ。 (8:42)

  •   0
  •   0

毎月の血圧での通院時に、医師が過去の血圧を見る可能性があるが、毎回は見ないようで、(使われない可能性が高いのに)渡された紙のノートに転記するのは面倒だから、スプレッドシートをスマフォにコピーしておいて、言われたら見せようと思った。そして、LibreOfficeのファイルをスマフォにコピーしてクリックすれば楽勝で開けると思っていたのだが、全然そんなことはなかった。

信じられないことに、Androidにまともなオフィスビューアがない。入っていた(昔自分で入れたのかも)のは すぐに有料版に誘導する鬱陶しいもので、全然使いものにならなかった。他のも同様だったし、多くはシートが重くて開けなかった(1年分とかで数値が多いうえに平均処理とかいろいろやっているせいだろう。スプレッドシートはセルごとに式が入れられるので、最適化しないと重くなりそうだ)。グラフだってまともに出るものはなかった。

OpenOfficeのAndroid版はさすがに他よりはマシだったが、ほとんど単に移植しただけのもので、やっぱり実用にはならなかった。例えば、なぜか書式がおかしくなって、肝心の血圧が"###"と出たりした(3桁はちゃんと出るのに、2桁の時だけおかしいから謎だ。LibreOfficeとOpenOfficeの違い?)。

結局、グラフは画像(PNG)で保存、数値はPDFでエクスポート(どっかの省も数千ページとかやってたなw)という、もし誰かに見られたら情弱の烙印wを押されてしまいかねない、大変原始的な方法で切り抜けることになった。

Googleは、Androidでも何でも、「(僕らの誇る)Google docsを使え!」というスタンスなのだろうか。ただ、そこにインポートしたってまともに表示できなかった気がする(確か、グラフが駄目だった)が、最初からデータを入れて使えってことなのか・・・

まあ、ずっと行くだろうから、しばらく試行錯誤してみよう。

(10/21 11:45) 結局、今日は血圧を聞かれもしなかったw 休み明け(かつ、知らなかったが明日は祝日、)で混んでいたせいか、問題があれば言えってスタンスか。まあ、僕は自分で管理するつもりだし、何かあれば言うからいいけど。が、何か損した気がするので、とりあえず、次回は月曜などは避けようと思う。ただ、別件だが、今日はインフルエンザの予防接種もしたのだが、まさに一瞬のうちに終わった(「は?」と思ったw)。だから、腕はいいのだろう。

  •   0
  •   0

(技術的な詳細を書くのは大変だし、セキュリティ面の心配もあるので簡略化した)

僕はPC(Linux)とスマフォ(Android)でカレンダーを共有している(Googleなどは使わず、自分のサーバで実現している)のだが、ずっと、些細だけどムカつく「アラーム重複問題」に悩まされて来た。その現象を以下に書く。

  1. カレンダーの予定の通知時刻になると、LinuxのLightningとAndroidのカレンダーアプリ(DigiCal)から、同時または順次アラームが出る(省電力機能のためか、Androidは少し遅れることが多い)。
  2. 部屋に居る場合、Lightningのアラームを先に停め、遅れて出たAndroidのを停める。
  3. これで終わりならいいのだが、1分くらいすると、Androidのアラームが再び出る。 → イラっとする。

まったく鬱陶しいこの問題を、なかなか解決出来ずに居た。

まあ、部屋に居なければ問題は起こらないし、Androidのアラームを無視して停めなければいいのだが、今は勤めていないので部屋に居ることが多いし、性格上、アラームを停めないとLEDが点滅し続ける※のを見過ごす訳にはいかないw

※カレンダーアプリによっては、通知時刻からある程度時間が経つとアラームやLEDが自動で(勝手に)消えるものもあるが、それだと予定に気付かずに過ごしてしまう可能性があるので、消えないものを選んで使っている。

今まで何度も試したり調べたりしたのだが、その原因が昨日ようやく分かった。一言で書けば、LightningとAndroidのカレンダーアプリ・同期プログラムの相性だ。そして、どのプログラムも他に換えることができない。Lightningは僕にしてみれば最低レベルで使えるLinuxのカレンダーアプリで、それよりまともなものを探したがない。一方、Androidのアプリも同期プログラムも他にいいものがない。それでもいろいろ試したのだが、使い勝手、機能、性能、消費電力や通信データ量などが「許せる」もので問題が解決するものはなかった。

そういう訳で、昨日は随分試行錯誤したものの、結局、「解決不能」という結論になってしまった。

以下に、昨日の調査の結果推定した問題の起こる流れと、(その流れを前提として)問題を解決するために試したことを書く。

問題の起こる流れ

  1. 予定の通知の時刻になる。
  2. Lightningがアラームを出す。
  3. 僕がアラームを停める。
  4. Lightningは、なぜか、その予定をサーバに更新する(書き込む)。: おそらく、「アラームを停めた」という状態を保存するためだろう。
  5. DigiCalがアラームを出す。
  6. 僕がアラームを停める。
  7. DigiCalとカレンダー同期プログラムは、なぜか、サーバに更新を問い合わせる。: おそらく、省電力機能のために同期間隔が設定より長くなっていて、「起きたついでに」するのだろう。
  8. カレンダー同期プログラムは、サーバにLightningが更新した予定(アラームを停めたもの)があるので、それを取得する。
  9. 更新された予定がDigiCalに伝わり、予定の通知の時刻を少し過ぎているだけなので、DigiCalは(再度)アラームを出す。: 通知の時刻を大幅に過ぎている場合は出ないはず。

試したこと

  • Lightningが更新する処理に割り込んで、更新したように見せかけて、実は(サーバ内の情報を)更新しないようにした。 → Lightningは、更新後、御丁寧にも再度その予定を取得して確認し、更新されていないことに気付くのか(パニックになるのか)、アラームを停めてもダイアログが消えない。: 失敗
  • 同じく、Lightningが更新する処理に割り込んで、サーバ内の情報を更新する時に、Lightningが使いそうな部分だけ変更する(残りは元のままにする)ようにしてみた。 → Androidのカレンダー同期プログラムは、更新内容に関わらず書き込まれただけで変更されたとみなすようで、やっぱり、DigiCalはアラームを出す。: 失敗
  • 同じく、中身を何も変更せずに更新しても、上記の理由で駄目だった。: 失敗

LightningもDigiCalとカレンダー同期プログラムも、押し付けがましい余計なお世話をしてくれるので手こずっている(しかも、そういうのを解除できる設定などない)。もっとテキトーでいいのだがw

他には、Lightningがサーバへの書き込み後に行なう、本当に書き込まれたかの確認の処理に割り込んで、アラーム停止後はLightningが期待するように見せ掛けるようにし※、実際にはサーバには書き込まないようにすることが考えられるが、結局、カレンダーサーバの処理の一部を作るようなもので、大変だし、いつまで動くか分からない(いずれかの要素の動作が変わったら、駄目になる可能性が高い)など馬鹿らしいので、止めた。あとは、サーバのプログラムを改造することも考えられるが、上と同様の理由で止めた。

※今朝はこの処理の準備として、Lightningとサーバ間の通信パケットを見て、Lightningはアラーム停止後にどんな処理をしている(どんな情報を取得している)のか詳しく調べようかとも思ったのだが、勝算はないし面倒なので止めた。

まあ、気にしないのが一番なんだろうな。それができれば苦労しないんだがw

 

(10/7 13:20 わずかに修正)

  •   2
  •   1

辞めた会社の面接の時、仕事でSkypeを使うとの話だったので、てっきり、ビデオ通話でスマフォのフロントカメラを使うのだろうと思ってカバーを注文した(最初はPCのwebカメラも要るかと思ったが、とりあえずスマフォで済ませようとした。実はそれが大正解だったw)。それまでは、セキュリティ向上(例: 盗撮アプリ対策)のためにカメラの前に紙のシールを貼って、たまに撮影する時だけ剥がしていたのだが、仕事で使うようになって頻繁に剥がしていたら駄目になってしまうと思ったからだ。

カバーを選ぶ時、なるべく小さく(特に高さ)薄い物を探した。というのは、僕のスマフォは、シャープの機能(Clip Now)により、画面上縁を水平になぞると画面キャプチャできるのだが、カバーが大きいと(指が離れたとみなされて)できなくなってしまうからだ。最初は手軽に100円ショップを探したのだが、なぜかなかった。余りリスクが知られていないために、そういう需要はないのか。それで、Amazonで「FIRST2SAVVV 3 X ウェブカメラカバー」という3枚組のにした。高さは1cm弱、厚さは0.7mm程度だ(今気付いたが、高さを7mmと勘違いして、それなら他より小さいからキャプチャに干渉しないかもと思って注文したのかも知れない。ボケてるなあ・・・)。250円くらいだった。中国からなので、届くのは遅かった。

その後、仕事の最初の日に分かったのだが、Skypeは主に音声だけ※でするそうで、届く前にカバーはほぼ不要なことが分かってしまった・・・

※要は、電話代わりなのだろう。あと、電話と違って数人で会議ができるのもいいのだろう。前の前の会社で(会社の電話が支給されていなかったので、)みんなが電話代わりに使っていた、iPhoneのFaceTimeオーディオと同様だ。当時は、Skypeはビデオだけで(SkypeOutでない)音声通話ができるなんて知らなかったので、自分のスマフォをAndroidに換えた時に、FaceTimeの代わりにGoogle Duoが使えることを調べて連絡したのだが、田舎だけあってか、誰も試しすらせず普通の電話をして来たw その時にSkypeを知っていれば、もう少し手軽に(特定ベンダーに依存しないという意味)使えたかも知れないが、SkypeはMSのアカウントが要る(しかも、気軽に退会できない)ので、やっぱりDuoと同じ(いや、それ以下)だっただろう。

更にタイミングのいいことに、退職の連絡をした日に届いたw もう必要ではないけど一応試してみたのだが、やっぱり画面キャプチャはできなかった(しかも、指をスライドするとカバーが動いてしまう)ので、諦めて仕舞った。ただ、紙のシールを貼り直したら、見た目が悪いし駄目になった時に作り直すのが面倒なので、プラスティック製の不透明なシール(紙製のものが良くある丸い物)にしようと思ったが、近くのスーパーなどにはなく、あとで100円ショップを探そうと思っていた。

ところが! 昨夜、何の気なしにスマフォの「システムアップデート」(「OS更新」とは一言も書いてなかった)をしたら、期待も覚悟もwしていなかったのにAndorid 9に更新され、それとともにClip Nowが改良されて、左右縁の縦スライドでもキャプチャできるようになった。それで、諦めていたカバーを再度試すことにした。

画面キャプチャは依然として横スライドでは駄目だが、縦ならちゃんとできた。当然ながら、カバーを閉じればカメラには何も写らず開ければカメラには干渉せず、撮影には問題ない。難点は、安いだけあって脆弱なことだ。カバーにはノッチのような固定機能がないので不意に動きそうだし、粘着力も弱そうなのですぐに剥がれそうだ。あと、取り付ける時に可動部が外れたので、そういうこともあるかも知れない。

まあ、それでも、諦めていたものが僥倖で使えるようになりw、見た目も悪くないので、しばらく試してみたい。

別件の確認のために1時間程度散歩したが、その程度ならカバーは動かないことが分かった。 (10:42)

 

PS. ところで、この製品の呼び方は、(「スマフォ」=「スマホ」として)「スマフォカメラカバー」なのか、「スマフォカメラ用カバー」なのか、「スマフォ用カメラカバー」なのか、「スマフォ用カメラ用カバー」なのか、考えると夜も眠れない。どうも、名前からして数奇な運命のようだw (15:22)

PS2. 上の問題を少し真面目に考えてみると、名前を構成する可能性のあるいずれかの単語が広く知られていれば、それを区切らずに使うのが良さそうだ。そこで、「スマフォカメラ」や「カメラカバー」(本当は「レンズカバー」が良さそうではある)は広く知られているだろうかを考える。後者は良さそうだが、前者は今ひとつ不自然な感じで、「スマフォのカメラ」と呼ばれていそうだから、「カメラカバー」を単語として使うのが良さそうだ。とすると、「スマフォ用カメラカバー」が適切な気がする。実際、パッケージには"Webcam cover"とあって、「カメラカバー」に相当する。

よって、この人の名前は、「スマフォ用カメラカバー」と思われる。

あ、題が駄目になっちゃった・・・w (15:28)

  •   0
  •   1

前回追記したように、新たな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

確かシンプル バッテリー グラフが突然駄目になった時だったと思うが、スマフォの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

ケーブル追放計画の一つ、スマフォの充電を無線にしようと、AmzonでQiという規格の製品を探した。散々探して候補を決めたのだが、やっぱり止めた。以下のような問題があることに気付いたからだ。

  • (気軽に)充電しながら使えない。
  • パッドも持って行かないと、出先で(気軽に)充電できない。

というのは、僕のスマフォ(AQUOS sense lite)は無線充電に対応してないので、本体に、レシーバーという電気を受けるアンテナに相当する部品を貼ってUSB端子に接続するのだが、スマフォケースを使っている場合、そのUSBコネクタを簡単には外せない(スマフォをケースから取り出す必要がある)ので、気軽には通常の充電には切り替えられないのだ。

充電しながら使うのは、プログラムの作成やデバッグ時、あるいは、連続して音楽を聴く時に必要だし、出先でも充電したい。パッドという送信機に相当するものも持参すれば充電はできるが、さすがに大掛かりだし、散歩とかちょっとした外出の時は無理だ。

更に、レシーバーには碌な安心できる製品がない。部品的な扱いのせいか、パッドと違い、名前の知られたメーカーのものは皆無で、どれを見ても、「使えない」・「すぐ壊れた」・「すごく熱くなる」・「厚い」とかいうクレームが多い。電力を扱うものだから、安心できるものが欲しい。

という訳で、充電ケーブルが1本残ることになった。次のスマフォの時には、是非、無線充電対応のものを考えよう。

PS. USB type-Cコネクタを極小なスペースで分岐できような部品、あるいは、そういうレシーバがあればいいのだが、さすがに探してもなかったし、実現するにはかなりの無理があるだろう。

  •   0
  •   0

大分春らしくなったので、またドライブに行きたくなった。例によって行き先は迷ったが、県内のみかも山公園か、群馬の多々良沼公園が残った。他には、大田原城跡や八溝県民休養公園や道の駅 きたかわべや道の駅 めぬまなども候補だった。みかも山公園も良さそうだったが、有名なカタクリには少し早いので、今まで余り行ったことのない所ということで多々良沼公園にした。

10:30頃出発し、12時頃着いた(実は、そこは本物の多々良沼公園ではなく、ガバ沼の近くだったようだ)。道は混んでいたし、疲れと空腹で今ひとつの気分だった。

途中、コンビニから出る時になぜかクラクションを鳴らされて、意味が分からなかった。片側2車線で、左車線の車が遠かったので、右車線から来た車に注意してゆっくり出たら、誰かに鳴らされた。音の感じ(純正じゃなかった)から、右車線の後ろから来たワンボックスが鳴らしたようだが、なぜだろう? その前の車が妙に遅かったから? − と思っていたのだが、さっき理由が分かった気がする。鳴らしたらしいワンボックスは最初に遠く左車線に居た車(その時は軽とか普通車に見えた)で、僕がのこのこ左に出て行ったので右車線に移ったものの、前の車(高齢者らしかった)が遅くて追い越せずにイライラして鳴らしたのだろう。そうだったら申し訳なかったが、そのワンボックスは遠かったし遅そうに見えたのだ。まあ、お互いに運が悪かったんだろう。。。

冷たい物が飲みたかったのだが、その公園にあった自販機の飲み物はホットコーヒー以外は全部売り切れという寂しいありさまだったので、とりあえず、自販機を探して出た。少し走って7-11にたどり着いた。この辺りは道が複雑な感じだ。あと、群馬も栃木同様、運転は荒い感じだ。

昼食に7-11のコールスローサラダと冷しラーメン(牛骨醤油)を車内で食べた。ラーメンは麺は今ひとつだが、冷えたスープが意外においしかった。珍しいことに、7-11の冷たい麺はそれしか残ってなかった。自販機といい、暑かったせいだろうか?

造園業者の若い人(十代の顔だった)が、トラックの助手席で大きなカップ焼きそばを食べていた。今は僕も昼は外に出るのが億劫なことがあって、そういう時はカップ麺などで済ませているので、気持ちが分かる。

この頃から急に曇って来て、雨も降り出した。ただ、食べたら気分が盛り返して来たので、とりあえず本物の公園に行ってから帰ることにした。少し走ったらその公園らしきものがあったのだが、うっかり通過してしまった。引き返そうと思っていたら、うまい具合に別の駐車場があった。そこは、漁協がやっているらしい休憩所釣り場があるところだった。

桟橋がぐるっと伸びていておもしろいのだが、釣り客以外は立ち入り禁止だった。まあ、僕はこういうのが怖い(いかにも板が腐っていて、抜けそうではないか・・・)ので、禁止でなくても入らなかったとは思うが。風のせいか外はすごく寒かったので、休憩所で飲んだホットコーヒーがおいしかった。置いてあった案内の紙を見たら、公園の方に白鳥が居るらしかった(思い違いで、実際には公園の反対側(ガバ沼)だったようだ。しかも、時間・時期的に見るのが難しそうだった)ので、ちょっと歩いてみることにした。

公園は広々としており、なかなか気持ち良かった。ウッドチップの散歩道がいい感じだった(ただ、全部がそうではなかった)。この頃にはまた日が出て来て暖かく(暑く)なった。少しだが、大きな野鳥も居た。池で獲物を捕るところも見られた。白鳥かも知れない白い鳥も遠くに居た。

いろいろ見られて満足したし、充分歩いたので、帰ることにした。この頃、なぜか、ショパンのポロネーズが頭に浮かんだ(彼の曲は、ピアノ協奏曲以外はほとんど聴かないのに)。後で調べたら、「英雄ポロネーズ」(ポロネーズ 第6番)だった。これの出だしは派手で、そのせいか、いつもは聴くことがないのに、なぜか浮かんだ(なお、浮かんだのは出だしでなく、その後のメインの部分だった)。

帰宅後、手持ちやSpotifyで聴き比べたら、ルービンシュタインの(ライブ、初出年は未確認)が一番好みに合っていて、彼以外(例: アシュケナージ、ポリーニ、アルゲリッチ)は、なぜか余りピンと来なかった。ただ、Rafał Blechaczの(2010)の音は実にクリアで良かった(やっぱり、ルービンシュタインの迫力には及ばなかったが)。

以前から、ルービンシュタインのショパンがSpotifyのDaily mixで掛かるたびに「いいなあ」とひかれていたので、彼のショパンには何か特別なものがあるのかも知れない。

帰路は行きよりずっと混んでいた。特に、小山市の前後がキツかった。そっちに向かったのは失敗だった。ただ、行きと同じ道はおもしろくなかったし、293号で葛生を通るとセメントの埃まみれになって嫌だから、なかなか道がない。素直にナビの言う通りに50号と4号バイパスを通る(50号を通らず、バイパスでない4号を通って失敗した)か、行きの道を戻れば良かったのかも知れない。

宇都宮市に入った頃、タイヤをハの字(「鬼キャン」)にしている馬鹿の実物をおそらく初めて見た。タイヤを傾け過ぎているせいか、タイヤの底面がバイクのように丸くなっていて、それでもいいと思っているところがアホ丸出しだと思った。趣味だから別にいいけど(危険ではあるが)、本当の鬼キャンは四角いタイヤの角を使うものではないのか? 見せるだけでなく、走りこむと丸くなってしまうのか?

今回も、何年も住んでいるというのに、宇都宮市内の道は家の近くの散歩している辺りに行くまで、どこをどう通っているのか全然分からなかった。そのせいで、途中でちょっと早く右折して変な道に入ってしまった。

家の近くは危険なのでゆっくり走っていたら、軽が後ろにぴったり着けて来て鬱陶しかった。小物ほど煽ったり無茶するから嫌だ。とはいえ、途中で中型トラックや営業のワンボックスもぴったり着けて来たし、逆に、行きに黒のレクサスやレジェンド(アコード?)が予想外に丁寧に走っていて感心したから、車でなく運転者が小物ということなのだろう。それなら当然だ。

小物といえば、行きに最小・最安のアウディが煽って来たり・左右にうろちょろして意気がっていたのが笑えたw

帰りは県内でも雨が降ったり止んだりしていた。春のせいか?

18時頃、何とか無事に帰宅した。いつも同様、予想以上に長く乗って、とても疲れた。8時間近くも出ていたというのに距離は200kmにもならなかったので、ガソリンは余り減らなかった。散歩を90分近くしていたのは大きいのだろう。

今回は休日かつ出るのが遅かったため、道が混んでいたうえに変な車が結構居て、それほど気持ち良くは走れなかった。ただ、平日の朝は通勤の渋滞に巻き込まれる可能性があるし、そもそも、行く気になる日と調子がいい日、更に、天気のいい日がなかなか合わないので、気分良くドライブをするのは意外に難しい。

約146km、7.5時間。
IXY Digital 3000ISで撮影。

 

PS. 先日、Operaから切り替えたFirefoxが実は駄目だった。埋め込み動画を切ったはずなのに、なぜかダウンロードしたようで、起動し(て自動的に前回のページ(このブログ)が表示され)ただけでモバイルデータを3MBも消費した。しかも、そのせいか、表示がすごく遅かった。がっかりして、ドライブの気分をスポイルさせられたので、その場でOperaに戻し、帰宅したら速攻でFirefoxを削除した。

  •   0
  •   0

Firefoxのアドオン(ContentBlockHelperとHTML Content Blocker)で切れるか試した。

テスト用動画 (テスト時は埋め込みプレーヤーにしていた)

↓ HTML Content BlockerでObjectをブロックしたら、表示されなくなった。

設定はPCの画面だが、スマフォでも同様の設定でブロックできる。設定の方法が分かりにくいが、種類のアイコンを押すとon/offし、下線がある状態でブロックされる。念のため、Mediaもブロックすることにした。

これで一安心か?

(3/16 21:06) 結局、どうしてか、実際にはうまく動かなかった(データ量が多かった)ので、今はFirefoxを使うこと自体を止めた。

 

※ページサイズを軽量化するため、動作確認後、動画の内容と個数を変えた。 → 動画の表示形態を変えた。 (3/16 21:06)

  •   0
  •   0

さっき、Wi-Fiでの画像取り込み機能の確認のついでに、何の気なしにスマフォのモバイルデータ量を見て驚いた。いつもは大体1日3MB以下なのに、どういう訳か、30MBくらいに激増していたのである。原因のアプリを調べたらOperaで、昼食の時に外でwebを見たら25MBくらい使っていた。それで、てっきりOperaが変なことをやるようになったのかと思って、(Wi-Fiで)Firefoxを試したが同様だった。Chromeでも同じだった。

良く考えてみたら、その時はこことリンクしている方のブログだけしか見なかったので、ページに問題がありそうだ。フォントをダウンロードしたのかと思ったが、このブログのスマフォドラレコの投稿に動画のリンクを貼っていた(動画の挿入するのにURLのペーストや「URLから挿入」を使うと、埋め込みプレイヤーになって便利なのでそうしていた)のを思い出した。調べたら、確かにその3つの動画は合計で21MBくらいだった。

それで、とりあえず、動画のリンクの出し方を普通のリンクにしてみた。それからキャッシュを削除してリロードしたところ、データ量は2MBくらいだったので、直ったはずだ。

極限までデータ量を削減していたつもりなのに、とんでもなく間抜けなことをしていた。。。 まったく油断も隙もない。

そして、今までモバイルで見られた方は(スピードもデータ量も)すごく重かったと思いますが、大変失礼しました。

 

PS. ブラウザにこういう大きいのを読まない設定があるといいのだが、なさそうだった。WordPressの出し方にも問題がありそうだ。テーマをいじって、モバイルの時はそういうのを出さないようにするのがいいのだろうが、面倒だ・・・

それに、自分のサイトは制限できるとしても、他人のサイトでも同様なことは起こるから、ブラウザなどでの対策が要りそうだ。と言っても、僕が余りにもケチっているだけで、実は、普通の人はだーれも気にしていないのかも知れないw

Firefoxのアドオンで埋め込み動画を切れることが分かったので、それを使うことにした。スマフォ版Firefoxは遅いが、データ量の削減の方が重要だ。

それから、PCでもスマフォでもOSを問わず同じアドオンが動くのは、Firefoxの大きなメリットだ。Chromeもスマフォでだってできると思うのだが、Googleの方針で無効にしているのか、できない構造なのか。 (3/11 6:03)

(3/16 21:01) ところが、今日外で使ったら、自分のブログを開くだけでもものすごく遅かったうえにモバイルデータを3MBも使った。前に家で見た、動画の入ったページを再度読もうとしたのだろうか。ただ、アドオンが効くはずなのにそれも駄目だったようだ。結局、Firefoxは使い物にならないことが分かったのでアンインストールし、Operaに戻した。

  •   1
  •   0

先日作った、Androidスマフォの画像をLinuxPCにWi-Fiで取り込むプログラム(システム)だが、その後、使ったり試行錯誤したり考えたりしているうちにいろいろアイデアが浮かんで、(まだ細かい確認・調整点はあるものの)最初の要望どおり、以下のようにできた。

スマフォをPCに繋がなくても、操作なしで自動的にPCに画像が取り込まれる

それまで難しいと思っていたのは、元々の要望の重要な点とか使い方とか全体としての流れを整理し切れていなかったからだと思う。

僕の使い方と期待する動作を整理すると、以下のようになる。

  1. 外でスマフォで撮影したり画面をキャプチャして帰宅したら、それほど待たずに(家のWi-Fiに繋がった頃に)PCに画像が取り込まれている。
  2. 家でスマフォで撮影や画面をキャプチャしたあと、そのまま置いておけば(それほど待たずに)PCに画像が取り込まれている。

1は既に前回できた(Wi-Fiの再接続を契機に転送を開始する)。2は、前回はいつ転送(するかどうかのチェック)を始めればいいかの判断をすればいいのか分からなかった。そこで、更に具体的に使い方の流れを考えると、以下になる。

  1. スマフォで撮影やキャプチャする。
  2. 画面をoffにする。

そして、画面がoffになった(→ スマフォがアイドル(使っていない)状態になった)のを契機に処理を開始すれば良いことに気付き、実装した。かなり手こずったが、概ねうまく動くようになった。処理の流れの概要は以下である。

  • スマフォ
    1. スマフォがアイドル状態になったことを検知する。
      1. 画面がoffになるのを待つ。
      2. 数分後(例: 5分)にタイマーがイベントを出すように設定する。
    2. タイマーイベントを待つ。
    3. 前回の転送終了時刻より新しいファイルを探す。
    4. 新しいファイルがあれば、PCに転送開始要求を出す。
  • PC: スマフォから新しいファイルを取得する。

以下に難しかったことを書く。

アイドル(スマフォを使っていない)状態の検出

画面がoffになってすぐ転送を行うと、例えば、画面のタイムアウトで暗くなったなどで、また画面をonにして使い出して画像を追加する可能性があるから無駄である(無意味ではないが、まだ作業が終わっていないものを転送する可能性があるし、新規ファイルのチェックや転送(通信)の回数はなるべく減らす方が良い)。そこで、スマフォがアイドル状態であることを検知して転送を行うことにした。

アイドル状態は、一定時間(例: 5分間)画面がoffになっていることで判定するようにした。また、その時間より早く画面がonになったら、アイドル状態でないとして処理を打ち切る(「なかったこと」にする)。具体的には、画面がoffになった時にタイマーを設定し、タイマーの期限が来たらアイドルとし、それより前に画面がonになったら、(アイドルでないとして)タイマーを解除する。

なお、スリープ中はSSHDroidがうまく動かない(スマフォが完全にスリープしている訳ではないが、SSHDroidがスリープしているようだ)ので、スリープを解除するために画面をonにするのだが、その後の画面offもアイドルの開始と判定してしまう問題があるので、自分で画面をonにした場合には少しの間(例: 30秒間)画面offを無視するようにした。なお、なぜか、自分(このプログラム)で画面をonにした場合には、画面onのイベントは起こらないようだ(将来問題になりそうなので、再確認が要りそうだ)。

「前回の転送終了時刻」の取得

スマフォはPCに(「新しいファイルがあるよ」と)転送開始要求を出すだけで、実際の転送はPCが行うため、PCが本当にファイルを取得したか・できたかは基本的には分からない。しかし、転送に使っているrsyncコマンドはリモート(この場合、スマフォ)に転送のログを書くことができるので、その機能を使うことにした(これは邪道なやり方なのだが、一応、rsyncの機能しか使っていないので、許すことにした)。転送が成功しているとすれば、ログの更新時刻=転送終了時刻なので、新規ファイルの検索に手軽に使える(転送中に画像を作成するなどして食い違いが生じる可能性もあるが、その前にアイドル(放置)状態であることを確認しているので、余りなさそうだ)。

なお、ログから転送が成功したかどうかの判定をして、失敗していたら適切に処理すべきだが、今はいつも成功したとみなしている。そのため、何らかの原因でエラーが起こった場合、転送アイコンを押して(手動で)取得する必要がある。 → ログ中のエラーから失敗を判定する処理を追加した。失敗した場合、下記のログファイルの削除を行わないようにすることで、次回も今回と同じファイルから転送する。ただ、それでうまくいくかは疑問で、通知などが要る気がする。 (3/10 7:20)

また、rsyncのログファイルは毎回追記されるので、サイズが増大するのを防ぐため、転送開始要求を出す前に削除(実際にはrename)している。

 

以上により、基本的には、定期的な新規ファイルのチェックが不要になった(一応、保険として1時間に1回するようにはしている。ただ、アイコンを押せば手動でできるので、そこまでする必要はないのだが・・・ ← 忘れていたが、自動転送要求する時にPCが起動していなかった場合のリトライ用に有用だった(3/10 14:46))。それに加え、前回追加した、PCから最新のファイル名を取得する処理(通信)も不要になり(= 再び転送開始要求だけになった)、電池消費量が(更に?)減ったはずで※、なかなか気分がいい。

※ 8時間のアイドル時の消費電力量は0.4%/hだった。これは先日できたWi-Fiの再接続処理の低い時と同じ値なので、このプログラムの待ち受け時の消費電力は無視できる程度と考えられる。 (3/10 7:29)

そして、結果的にスマフォの転送開始アイコンもPCの状態表示ウインドウも不要になってしまった(後者は、使用中に勝手に出ると邪魔なので、エラー発生時以外は出さないようにしているため)。

 

作った画像転送システムを実際に使っていると、今までは余り興味がなくて魅力を感じていなかった無線や非接触通信がかなり便利に感じる。ケーブルをつながなくていいから手間が省けるし、机の周りがごちゃごちゃしなくて済む(でも、イヤフォンは御免だw)。それで、デジカメの画像もWi-Fiで取り込みたい気分が起こって来た。ちょっと調べたら、FlashAirがなかなかおもしろそうだ。ただ、電池消費量が増えるという情報があるし、そもそもそこまでする必要があるのか(スマフォはあるものでできたから手軽に始められたけど、デジカメだと追加の物が要るのでお金が掛かる)甚だ疑問なので、良く考えたい。

あと、スマフォの充電も非接触にして可能な限りケーブルを排除したいのだが、本体が対応していないので無理そうだ(これもいろいろあるんだろうけど・・・)。

 

PS. 少し話が飛ぶが、日本のメーカーは、ユーザーの要望の真意とか実際に使う手順とかをちゃんと見極めずに、「できるから」、「高機能なら売れる」と思い込んで作り込んでしまったために、機能はてんこ盛りだけど使えない家電とかばかりになってしまったのではないだろうか。挙句の果てに、高いうえに使いにくいから売れずに海外のライバルに負けてしまったという、踏んだり蹴ったり状態だ・・・

PS2. (節操なく宗旨替えするようだがw、)この無線・非接触の時代に、USBは4なんてやり出して、全く理解できない。まあ、あってもいいけど、そこまで高速なのが要るのだろうか。それより、昔諦めたWireless USBを復活させればいいと思うのに。ただ、あれ自体はUWBを使うなんて先進的過ぎて失敗したので、もっと「普通に」やればいいと思うが、そうできないからああなったのだろうか? だったらWi-Fiとかを使えばいいってことだろうか?

(3/10 7:58 加筆・修正)

  •   0
  •   0

ずっとやりたかったけど、面倒で見送っていたことができた。スマフォなどのケーブルが何本も(充電用とPC接続用、他にデジカメ用も)あって見苦しいし、注意しないと間違えるのが嫌になったのだ。しかも、スマフォをPCに繋いでも、いちいち画面で画像転送(PTP)を選ぶ必要がある※のも、イライラを増していた。

※検索すると、この選択は開発者ツールを使えば固定できるようなのだが、なぜか、再起動か何かのたびにリセットされて、いつも選ぶ羽目になっていた。AQUOSの仕様なのだろうか?

やりたかったのは以下のようなことだ。

  • スマフォをPCに繋がなくても、操作なしで自動的にPCに画像が取り込まれる。
  • USBで繋いだ時と全く同じように取り込まれる。
    • 新規画像(例: 前回の取り込み以降に撮影されたもの)画像だけが取り込まれる。
    • 画像は年月日ごとのディレクトリ(例: 2019/2019_01-03/2019_03_04)に仕訳けされる。
    • 画像のファイル名にはカメラ(スマフォ)・トップディレクトリ(例: DCIM/102SHARP)固有のIDが追加される(例: DSC_0301_2345987612.JPG)。
      • カメラ間・カメラ内のファイル名の競合を防ぐため。
    • ファイルの更新時刻が撮影時刻になる。
      • PNGなど、タグのないファイルでも並び順を揃えたいので。
    • 新しい画像であることを示すタグ(例: Subject="New")が付く。
      • ファイルを自動で仕訳けするために画像の場所が分散するので、あちこち探さなくても一目で新規画像を分かるようにするため。

そして、なぜか数日前(調べたら、3/2からだった。簡単にできそうなアイデア(後述の、マウントしてtarコマンドでコピー)が浮かんだので始めたのだった。本当に、「寝食を忘れて」熱中・集中していたので、結構疲れた)からやる気が出て実装し、以下のような感じで動くようになった。

  • スマフォをPCに繋がなくても、スマフォのアイコン(実体はウィジェット)を押すとPCに画像が取り込まれる。
  • USBで繋いだ時と全く同じように取り込まれる。

上に書いたように、操作なしにしたかったのだが、いくつかの問題があるので、今は保留している。 (→ その後改良して、概ね操作なしでできるようになった。: 3/9 12:09)

  • 使っているサーバソフト(SSHDroid)の仕様なのか、画面offの状態では、そのサーバが停止(スリープ?)するために、PCから接続できない。接続していても、画面offになってしばらくすると切れる。
    • → サーバを起動するために画面をonにするのなら、ロック解除してアイコンを押すのはそれほど手間ではない。
  • 仮に常時接続できるようにしても、定期的にPCから新規画像のチェックをするのは効率が悪い(画像が増えることはそれほど頻繁でないので)。頻繁にチェックすると電池を食うし、チェック間隔を長くすると不便だ。
    • → 画像が増えたら、スマフォがPCに通知するようにすれば良さそう。[今後の課題]

なお、PCからも取り込みを開始することができるのだが(最初はそうした)、上記のように、取り込み前に自分でスマフォの画面をonにする必要があるから余り便利でないことに気付き、スマフォから開始できるようにした。

スマフォとPCの画面が写った動画でないと全くおもしろくない(さすがに撮影する気は起こらないw)のだが、以下のように、スマフォのエクスポート(あるいはアップロード・同期)アイコンを押すと、PCで取り込みプログラムが起動し、取り込みウインドウに取り込みの経過が表示され、新規画像が取り込まれる。自画自賛だが、なかなか便利だ。例えば、スマフォで撮影したらアイコンを押すだけでPCに入れられるのはすごくいい(今までだったら、ケーブルを繋ぐかDropboxに入れるなど、結構面倒だった)。今気付いたが、家の中ならどこにいても転送できるはずだ(それに価値があるかは別としてw)。

こういうアプリなり仕組みは既にあるが、いろいろ探してもどうも僕の要望には今ひとつ合わないので(同様な理由でUSBでの取り込みプログラムも自分で作ったので、まず合いようがない)、自分で作った。あと、今はスマフォからクラウドに直接自動的にアップロードするのが主流だが、やっぱり使いにくいし、モバイルデータ量も増大するかも知れないし、そもそも、提供者の都合で仕様が変わったり有料になったり終了になる可能性があるので、なるべく使わないことにしている。

と、さらっと書いたが、中ではなかなかいろいろなことをやっているので、以下に細かい話を書く。

スマフォからの画像取り込み

基本的には、今までのUSB(PTP)での画像取り込みプログラム(の枠とでもいうもの)を使っている。ただ、今回のネットワーク対応ためにかなり追加・変更した箇所がある。

転送の仕組みは、最初は、sshfsなどでPCからスマフォのファイルシステムをマウントし、ファイル一覧を取得し、新規ファイルを抽出してtarコマンドでコピーすることを考えたが、rsyncコマンドの方が便利そうだったので、それを使うことにした。特に、rsyncはマウント不要(自動でスマフォ側のプログラムを起動する)なのが良かった。

スマフォのファイルシステムは大きく、毎回スキャンするのは得策でないから、PCでは新規ファイルの抽出はせず、取り込み済みファイル一覧から除外ファイル一覧を作ってrsyncに指定することにした。実際には、スマフォ内でrsyncによるスキャンは行われるが、PCからNW経由でやるよりは良さそうだ。除外ファイルサイズが大きくなって重くなるのが気になるが、今のところ、デジカメも含む全ファイル一覧(画像数: 8千以上)でさえ300KB未満なので、大きな問題はなさそうだ。

画像取り込みの開始

前述のとおり、最初はPCのプログラムで取り込みを開始するようにしたが、その前にスマフォの画面をonにする必要があって不便なので、スマフォのアイコンで開始できるようにした。

そうするにはいろいろな方法が考えられるが、手軽に作るためにAutomagicを使うことにした。Automagicで可能なのは、Wake on LANパケットの送信、HTTPアクセス、FTPアクセスなどだった。Wake on LANは手軽でいいのだが、ユーザのデータが送れないので、HTTPにしてみた。

なお、AutomagicからOSのコマンドを実行することもでき、ncコマンドもあるのだが、UDPの送信ができない(セキュリティの制限か、エラーになる)ので、諦めた。あと、そもそも、Automagicから実行できるコマンドのパスがシェルとは違っているために実行できない問題もあった。

これだけのためにPCでHTTPサーバを動かすのはもったいないので、socatコマンドで擬似的なHTTPサーバを作って待ち受けることにした。「サーバ」といってもまったく大したことはなく、「のようなもの」だ。基本的なコマンドは以下のような感じで、たった1行(長いので折り返した)で済むものだ。

echo -e "HTTP/1.0 200 OK\r\n\r\nHello!" |
  socat -d TCP-LISTEN:2345,reuseaddr - | hexdump -C

AutomagicからPCのTCPポート2345にアクセスすると(URLの例: http://192.168.1.2:2345)、PCでその要求がダンプされる(→ 要求が来たことが分かる)。また、スマフォ(Automagic)には"Hello!"という文字列が返るので、PCからの応答も分かる。

あと、ものすごく簡単な不正アクセス対策として、Automagicから要求を出す時に、ヘッダに「何か」(普通はない情報、合言葉のようなもの)を追加すると、何もしないよりはよい。そもそも、外部からのアクセスはルータで遮断されるので、外部からPCへのHTTPアクセスは来ない前提だし、PCはデスクトップなので持ち歩かないから、今はこれでいいと思う。それから、Wake on LANは間違って宅内の他の機器から出る可能性があり、ブロードキャストなので宛先で受信制限ができず、上記のようにユーザのデータは送れなくて正当性のチェックができないという点でも、HTTPの方が少し良さそうだ。

スマフォの個体の識別

前述のように、画像のファイル名にはカメラ(スマフォ)・トップディレクトリ固有のIDを追加する。そのIDは、カメラ情報(メーカー、機種、SN)から生成するのだが、当然、NW経由ではそれらは取得できない(スマフォのコマンドを使うとできるかも知れないが、仕組みを特定のOS・機種に依存させたくないので、止めた)。

そこで、スマフォのMACアドレス(HWアドレス)を使うことにした。MACアドレスはその個体に固有で変わることがないので、IDとしては良い。ただ、USBで取り込んだ時とネットワーク経由の時でIDが異なると、別の接続では取り込み済みファイル一覧が異なるため、新規ファイルが異なって、重複して取り込まれてしまうので、画像取り込み開始プログラムで、MACアドレスからUSB(PTP)で取得・生成したIDを検索して(今はプログラム中に書いている)、それを取り込みプログラムに指定するようにした。そうすれば、同じ取り込み済みファイル一覧が参照される。

MACアドレスは、次のように取得する。スマフォからのHTTPアクセスの場合、アクセスを受けたsocatは環境変数SOCAT_PEERADDRにスマフォのIPアドレスを格納するので、要求が来たらコマンドを実行するようにし、その中でIPアドレスを取得し、その後、arpコマンドでIPアドレスに対応するMACアドレスを取得するようにした。次はそのコマンド例である(まだsocatには理解できていないことがあるため、綺麗ではない。なぜか、最後の";"は必要である)。

tmp_file=/tmp/iimg-rss.d
http_resp_line='HTTP/1.0 200 OK\r\n\r\nAccepted.'
socat -T 0.7 TCP-LISTEN:2345,reuseaddr 
  SYSTEM:"/bin/echo -n -e \"\\\"${http_resp_line}\\\"; 
  (date +\"Date:\ %Y/%m/%d\ %H:%M:%S\"; 
  echo \"PeerAddr: \${SOCAT_PEERADDR}\"; 
  echo; cat ) > $tmp_file; "

スマフォから要求が来た場合、一時ファイル/tmp/iimg-rss.d中に、要求が来た時刻(Date)、スマフォのIPアドレス(PeerAddr)、要求の内容が格納されるので、適宜処理すれば良い(上述の正当性チェック用トークンも要求の内容として格納されている)。なお、これを受信した場合、スマフォには"Accepted."という文字列が返る(今はそのチェックはしていない)。

見つかった問題

実装中や試している時に見付かった問題と対処を以下に書く。

  • rsyncの除外・含めるファイル指定の謎
    • 対象ファイルの指定はなかなかの謎で、うまく使えるようにするのがとても大変だった。指定順序がかなり重要らしい。(→ 参考ページ)
  • オーディオファイル(例: MP3)、動画にはタグが付けられない。
    • exiftoolがMP3などの書き込みには対応していないうえに、タグの仕組みが異なるので、画像と同じようには処理できない。
    • → 取り込み後に画像管理アプリXnViewMPに認識させるために、新規画像一覧を指定してXnViewMPを起動しているので、取り込み時にタグが付けられなかったファイルがある場合には、そのウインドウを閉じないようにして新規ファイルが分かるようにした。
  • 時々SSHDroidが停まる。
    • Wi-Fiの鍵更新時に一瞬Wi-Fiが切れるために、SSHDroidが終了するようだ。
    • → 先日できたWi-Fiの自動再接続プログラムで、画面がoffの場合には(onの時はすぐに繋がるから、問題ないはず)SSHDroidを再起動するようにして、解決するか試している。 → 今のところ大丈夫なようだ。
  • ディレクトリ名の問題
    • rsyncと従来の取り込みプログラム間の想定の違いやAndroidで画像のあるディレクトリはDCIMだけでないなどの細かい問題があったので、逐次対応した。
  • 変なファイル名
    • 一部のファイル名に、想定外の"["や"]"が入っているものがあって、「ゲー」っとなったが、PHPにescapeshellarg()というすごい関数があることを知って、何とかなった。
  • 余計なファイル(Android下のキャッシュなど)の除外
    • 上述のrsyncの除外パターンに指定して、なんとか除外できるようになった。
  • tarはエラーをうまく返さない?
    • 普通に使う分にはちゃんと返すのだろうが、パイプで繋げた場合にはエラー状態が消滅してしまって、失敗がちゃんと分からなくて不便だった。これは、rsyncに換えた最初の理由である。

その他

今、以下のようなことを思った・思っている。

  • 転送がすごく速い。
    • USB(PTP, gphoto2)での時よりずっとキビキビしていて、速くて気分がいい。今は転送ファイル数が少ないだけかも知れないが、rsyncの処理が高速な気もする。
  • 外からの帰宅時に自動取得できると便利かも。※
    • AutomagicでWi-Fiの接続イベントが取れるので、その時にエクスポート開始すればできそうだ。これを作れば、帰宅してすこし経てば自動的に取り込まれているので、ロック解除してアイコンを押す手間すら省けて、なかなか良さそうだ。が、帰宅時にPCが起動していない可能性もあるので、そううまくは行かないことに、今気付いた。 → 外部サーバを使うといいかも知れない(大げさになってしまうが)。
  • スマフォの物理ボタンを押したら転送開始できると便利。
    • が、使えるボタンが少な過ぎて無理(音量しか使えない)。
  • デジカメでもこうしたいが、無理かも。
    • 仮にWi-Fi付きモデルだとしても、rsyncが動くとは思えない(別のファイル共有が使えれば、それに対応させれば、可能性はある)。
  • Automagicはすごく便利! もっとしゃぶり尽くしたいw
  • そして、こんな芸当(というか、Linuxでは当たり前だが)はiPhoneではまず無理だっ! (ネイティブアプリを作ればできるかも知れないけど、そんな面倒なことはしたくない)

※ その後、帰宅後の転送を操作なしにできるように、Wi-Fi接続時に自動的に画像転送を開始するようにした。PCが起動していない可能性については、開始前にpingでPCが起動しているかを確認するようにした。また、Wi-Fiの接続が安定するのを待つため、少し(例: 3分間)待つようにした。

更に、スマフォが電源に接続された時も、同様に自動で転送開始するようにした。この場合は無駄な転送になる可能性があるが、電池は消費しないので、大きな問題ではない。

なお、自動的に転送を開始する場合は、エラーがあった時以外はPCの画面に画像取り込みウインドウを出さないようにした。なるべくPCの操作を邪魔されたくないからである。これは、上記トークンと同様に、スマフォからの転送開始要求のHTTPヘッダに取り込みの動作モードを指定することで実現した。 (3/5 8:58)

その後、アイドル中(画面消灯後、約3分経過以降)はSSHDroidが停まっている(アプリがdoze状態?)ためにPCからのrsyncでのアクセスが失敗することが分かった。いろいろ試したところ、直接的にアプリを起こすことはできなかったが、画面を点灯させるとSSHDroidも動き出すことが分かったので、自動転送開始の契機がWi-Fiの接続時の場合には(電源接続時はスマフォ全体のスリープが解除されてSSHDroidも動き出すので、必要はない)、短く(1秒程度)点灯させてから転送開始するようにした。消費電力の増加が気になるので、しばらく様子を見たい。 (3/6 9:43, 13:35)

Wi-Fi接続時に自動転送したいのは帰宅時なので、長時間(例: 10分以上)Wi-Fiが切断された後に接続した時だけ転送を開始するようにして、長時間アイドル中のWi-Fi鍵の更新時に無駄に画面点灯と空の転送が実行されて電池が減るのを防ぐようにしてみた。

ソフトというのは、最初は単純なものでも、こうしていろいろ工夫・調整すると複雑になってしまう。そういうのの成れの果てがWindowsのようなものだ。なかなか加減が難しい。。。 (3/6 14:14)

更に、自動転送の場合、スマフォ内に前回PCが取り込んだ(PCに転送した)ファイルより新しいものがある時だけ転送開始要求するようにした。これで、無駄に画面が点くことはまずなくなるだろう。ただ、新規ファイルの検索と画面点灯とどちらの電池消費量が多いかは不明だ(点灯させるとスマフォ全体が起動するから、そっちの方が多いとは思うが)。

PCへの要求を送るのにHTTPを使うようにしたおかげで、スマフォからPCへの命令(前回転送したなかで最新のファイル名を取得する)を追加できたのは良かった。

これで、この件に関しては概ね気が済んだ。ただ、想定が狂って、転送開始要求の前に、前回転送した最新のファイルを取得する必要があるために転送回数が増えてしまったのは、ちょっと気に入らない。本当に必要なのか、もう少し考えてみたい。

当然ながら、プログラムは更に複雑になってしまった。 (3/7 11:53)

 

(18:52 若干加筆; 19:49 題を変更; 20:28 若干加筆; 23:42 2番目のsocatの例が誤っていたので修正)

  •   0
  •   0