Archive for the ‘PC・技術’ Category

先日作った、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

スカスカな本棚は他の物で代用できそうなので、以前から撤去しようかと思っていたのだが、やり過ぎとか意味なさそうな気がして(本棚を捨てる訳にも行かないので、どこかに保管場所は要るから)保留していたのだが、先日、ある方(か*さん)のツイートに触発されてやってみた。

本棚の代わりだが、以前使わないから撤去したカラーボックスを使うことにした(妹にあげようとしたが断られたので、ベッドの下に隠していた)。他の案としては古い机もあったが、それは今は電子レンジを載せているので良くない。電子レンジは冷蔵庫の上に載るが、そうすると流しが暗くなって嫌なのだ。

やってみたら、結構うまく片付いた。本棚にあったもので、良く使うものだけをカラーボックスに入れ、残りの引き出しや書類ファイルなどはクローゼットに収納(隠)した。以前から、クローゼットの中にはスキャナ(ScanSnap)も入れている。なお、音質の補正に都合がいいので、クローゼットのドアは開放して(なぜかその方が特性がいい)、カーテンにしている。カレンダーは本来は机上に置くものだが、小さいので、クリップを変形させて金具を作って壁に掛けた。また、バックアップ用HDDやルータなどはカラーボックスの後ろに隠した。

カラーボックスの天面には財布や手袋を置いている。ちょっと狭いが無理ではない。あと、カラーボックスの棚板が少なかったので、得意の段ボールで増やして※眼鏡や鍵などの小物を置いている。

※当然ながら棚板を載せる棒もなかったので、そこら辺にあった木ネジにテープを適当に巻いて作った。耐久性が心配ではある。

何でも隠せば済むというものではないがw、とりあえず、いつも目にするところに物が少ない(空間が多い)のはいい感じだ。

 

(13:49, 15:32 若干修正)

  •   0
  •   1

文化庁とかいうところは、JASRAC並みに文化から最も遠い連中の集まりだ。

違法なコンテンツと知っていてダウンロードするのは、何でも違法

にしたいらしいが、「知っていて」って何だい?

この言い回しは昔の動画のダウンロードの違法化時にもされていて、前にも書いた気がするのだが、知っていなければセーフなのか。では、その「知っている(た)」はどうやって確かめられるのだろう。これがかなり難しいことに気付かずに安易に法に盛り込もうとしている時点で、文化のかけらもない連中としか言いようがない。

文字どおりに受け取って、「違法かどうか分からないよなぁ」とうそぶいて何でもダウンロードして、捕まった時に問われたら「全然知らなかった」と言えば済むのだろうか。多分済まないだろう。が、他人がその人が何かを「知っている(た)」かどうかなんて、どうやって判断するのだろう? 精神鑑定でできる?? 「常習的に」と言ったって、違法と気付かなければ、普通は何度でもダウンロードするだろう。知っていてもダウンロードするだろうけど、その違いはどこで分かるのだろうか? 捕まった時にどうやって証明すればいいのだろうか? 法だけは作って、証明する方法や例を示さず、「普通の人は大丈夫です」みたいな、いかにも日本的なあうんの呼吸みたいにされたら、全く安心できない。

それから、「明らかに(違法と)」とかいう文言も出そうだ。

市販の漫画は違法であることが「明らか」なんだろう。が、ものすごい山奥とかに住んでいて、TVも新聞も雑誌も何もなく、都会や社会の常識や流行を全然知らない人は、どうやってそれが違法であることを知るのだろうか。

逆に、あるサイトのトップや各ページに、

ここには違法なコンテンツしか置いていませんので、ダウンロード・キャプチャ・コピーなどはすべて違法です。

と分かりやすく書いてあったら、実際には合法なコンテンツしかなくても、ダウンロードした人が違法になる可能性があるだろうか。そして、そのサイト自体は違法ではないので、おとがめなしか。まあ、ダウンロードした人は違法にはならないだろうが、その記述は新たなコピープロテクトになるかも知れないと、冗談半分に思った今日この頃。

そして、執行するのは、ブラクラのリンクですら捕まえるくらいリテラシーの低い警察なので、いくら今は「明らかに」とか「繰り返し」とか「悪質な」などの制限をうたっていても、そのうちに別件逮捕の口実にうまく使われる可能性は大ありだ。そうなったら、PCなどは押収されて留置場送りと、大変嫌なことになる。結局、それが嫌だから、多くの人は萎縮してしまう。

脳味噌のない連中が偉くなって、「僕ちゃんたちがみんなで『正しい』って言えば、絶対正しいんだもんね!」の乗りで非常識なことばかりする、困った国になってしまったものだ。

その後、どういう訳か、問題の項目が削除される方向のようだ。例の人の鶴の一声らしく、狐につままれたようだ。でも、きっと、何か企みがあるのだろう。例えば、これで、善人とか他のアホよりはマトモな人の顔ができるから、支持率もあがるとか。いずれにしても、最悪の事態は回避できそうだ。感謝すべきは、「MANGA議連」会長の古屋という人だろう。

この調子で某押し売り放送のやりたい放題も止めて欲しい。 (3/8 12:58)

  •   0
  •   0

以前から恐れていたことだが、「公共」を名乗る押し売り放送が根回しをし尽くしたらしく、とうとうネットに同時配信できるようにしてしまった。それを回避する方法がなさそうなので、昨日は嫌な気分で途方に暮れていた。でも、今日、ある掲示板のまとめを読んだら、いいことが書いてあった。

22:名無しさん@1周年 2019/03/06(水) 11:01:03.45 ID:wIOb36XL0.net
NHKを見ない自由は無いのかよ!ルーティング禁止すりゃいいだけの簡単なお仕事じゃん。w

それだよ! NHKにルーティング(接続する設定)しなければ観られないから、スマフォだってPCだって「受信設備」にならないのではないか。もちろん、(プロバイダの)ルーティングは個人では設定・変更できず、プロバイダにしてもらうしかないが、逆に、そうしてもらえれば、第三者的に観られないことが証明されるから、連中にいちゃもんを付けられる心配はなさそうだ。

正確には、いろいろなこと(例: プロキシ、VPN)をすれば観られる気はするが、それは、アンテナがない・撤去した人に、「ポータブルアンテナを付ければ観られるでしょ」と因縁を付けるようなものだ(彼らはそれすらしそうだから嫌なのだが)。

あとは、プロバイダがそういうプランなりオプション(「Nフリー」プラン/オプション!)を提供してくれるのに期待するしかない。が、きっと、どこか(政府から遠いところ。GoogleやAmazonはどうだ?)が始めて、それが好評になってみんなが乗り換えて、他のプロバイダも追従するような気がする。そうなって欲しい! そのための費用はもちろん払う。押し売り放送の料金と同じかそれ以上だって構わない。

これは正義や信義の問題だ!

クソや泥棒に払うお金は1円だってない!

 

PS. 4Kだの8Kだのを放送し始めたけど、これだったら、最初からネット放送(?)だけにすればずっと早く楽にできたのに(もちろん僕は嫌だが)。とんでもない無駄な開発だったと思う。というか、そうなったら「放送」である必要なんてない。不便過ぎる。

PS2. 技術的な話になるが、動画(今後は4Kとかになるのか?)をバンバン流されるとかなりの帯域を食うだろうから、NW構成にもよるが、Nフリーにすることでプロバイダの負荷が軽減できる可能性がある。そういう言い訳(「うちは帯域が貧弱なので・・・」)をすれば、プロバイダも国に睨まれずにできるかも知れない。とにかく何とかして欲しい。

それから、僕のスマフォは500MB/月でとてもじゃないがTVなんて観られないのだが、それは考慮してくれないのだろうか?w 実際問題、500MBは特殊だとしたって、普通の契約(3GBくらい?)の人がスマフォでTVを観るのは現実的なのだろうか?? 例の「3日で1GB」などの連続使用制限も大丈夫なのか? あと、従量契約の人はまず観ないだろうね。はい論破!? (とは言え、彼らの論法は、現実性が皆無でも可能性が0でなければ(一瞬でも映ればいい)金を毟り取る根拠になるので、どうしようもない)

  •   1
  •   2

ずっとやりたかったけど、面倒で見送っていたことができた。スマフォなどのケーブルが何本も(充電用と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

先日からの、Wi-Fiに接続できる環境でもモバイルデータが使われる問題への対処の続きのまとめを書いていたら、新しいアイデアが浮かんで、それがうまく行ったので書く。前半はそのアイデアが浮かぶ前に書いていたものを加筆・修正したもので、後半がそのアイデアと結果である(前半を飛ばしたい場合はここ)。

ディープスリープ回避による同期間隔の改善

当初は、Automagicで定期的にカレンダーなどの特定アプリの同期を行うようにし、その時にWi-Fiが切れていたら再接続するようにしていた。ただ、システムがディープスリープする(Dozeモードになる)のか、アイドル時間が長くなると、Automagicでの同期間隔が(設定は30分なのに)3時間前後に伸びる傾向にあった。それは消費電力の削減には効くので諦めようとした。とは言え、やっぱり、できれば同期間隔が伸び過ぎないようにしたくなった。ただ、前回も書いたように、消費電力削減と定期的な同期間隔とモバイルデータ量の削減は相反するので、うまく共存させる必要がある。

それまでに分かった問題点は、

  1. ディープスリープ(Dozeモード)のために同期間隔が伸びる。
  2. 要求した同期の実行が遅れることがある。(同期の実行遅れ)

なので、それらを解消(軽減)できればいいと考えた。

それで、同期間隔が長くなり過ぎることを改善するためのポイントは、スマフォを「寝させ過ぎない」(ディープスリープさせ過ぎない)ことだろうと考えた。ディープスリープし過ぎると同期間隔が伸び、更に、Wi-Fiが切れる(offになる)可能性も高くなって、モバイルデータ量も増えてしまう。一方で、全然ディープスリープしなかったら消費電力が増えてしまう。だから、Androidを「適度に突っついて」、目を覚まさせればうまく行きそうな気がした。

いろいろ試したのだが、前回気付いた「ディープスリープを回避する方法」をヒントにしたら、結構うまく行った感じだ。そのアイデアは以下である。

Periodic Timer(オプション= "Like alarm clock")をセットすると、ディープスリープにならなくなるが、セットしたままだと消費電力が増えてしまう。そこで、短時間だけPeriodic Timerをセットして解除すれば、消費電力はそれほど増えないのではないか。

これにより、上記の2つの問題が改善できることを期待した。1番は、定期的にディープスリープにならない状態を作ることで、ほとんどの同期間隔を支配しているPeriodic Timer Inexactの精度が向上することを(この間にPeriodic Timer Inexactが「動き出す」ことを期待する)、2番は、ディープスリープにならない状態を作ることでAndroid内部に溜まっている同期要求が実行(flush)されることを、それぞれ期待した。それで、以下のようなPeriodic Timerの設定で試してみた。

  • Periodic Timerの周期(= ディープスリープにしない時間): 2分
  • Periodic Timerを解除するまでの待ち時間: 30秒

理論的には、Periodic Timerのイベントが起こったらすぐに解除してもいいはずだが、解除する前に何かの処理を入れたほうがいいかと考えて、少し待ち時間を入れた(後で分かったが、待ち時間は要るようだ)。

すると、1番(同期間隔)については効果があったが、意外なことに、2番(同期の実行遅れ)にはほとんど効果がなかった。ディープスリープにしない時間が短かかったのかも知れないし、他の要因があるのかも知れないと思っていたのだが、その後、要求を溜めているのは、OSでなく同期アプリ自体なのかも知れない(同期アプリがスリープしていたら、要求を受けても実行できないのだろう)と考え、同期アプリがスリープしないように、「電池の最適化」をoffにして試したら、同期の実行遅れもなくなった。

基本的な処理の流れは以下である。

  1. 同期の契機となるイベント(例: Periodic Timer Inexact)を待つ。
  2. 同期する時期(例: 前回の同期から30分以上経過)だったら以下を行う。
    1. ディープスリープ回避処理を有効にする(= Periodic Timerを起動する)。 → ディープスリープの回避が始まり、Periodic Timerの周期の経過後に解除される。
    2. 同期処理を行う(基本的には前回書いたのと同じ内容)。

本当は本体のプログラム中でPeriodic Timerの作成や起動をしたかったのだが、Automagicに適当な機能はなかったので(アラームやタイマーなどは可能だが、本当にアラームが設定されて音が鳴ったりするので、実用には向かない)、別のプログラムにした。もしかしたら、ディープスリープ回避処理で行っているスリープ(オプション= "Keep device awake")をするだけでもいいのかも知れないが、確かではない(Periodic Timerには"Like alarm clock"オプションが必要なので、たぶん駄目だと思う)。

ディープスリープ回避処理は以下である。

  1. Periodic Timer(周期= 1分, オプション= "Like alarm clock")のイベントを待つ。
  2. 以下を並行して行う。
    1. 一定時間(30秒間)Sleepする(オプション= "Wake up from idle/doze": Doze(ディープスリープ)状態から復帰させる)。
    2. 一定時間(35秒間)Sleepする(オプション= "Keep device awake": この間はディープスリープさせない)。
  3. 自分を無効にする(= Periodic Timerを無効にする)。

2種類のSleepは、Sleepの2種類のオプションのうちどちらがディープスリープの回避に効果的なのか分からなかったので、念のため両方入れた(Periodic Timerによってディープスリープは既に回避されているのだから、おそらく後者だけで充分だと思うし、なくてもいいかも知れない)。

上記の仕組みを実装し、試してみたところ、管理しているアプリが同期する時にWi-Fiが切れていても確実に接続できるようになり、なかなか良い結果が得られた。要するに、僕の要求のほとんどを満たし、期待以上の効果が得られた。ただ、このプログラムとサーバのログやモバイルデータ通信の状態や使い勝手をチェックしていたら、以下の問題が見付かった。

Wi-Fiが切れている間にこの仕組みが管理していないアプリ(= 外部から同期開始できないもの。例: AquaMailやGoogle Play)やOSの通信が始まった場合は、モバイルが使われてしまう。

特に、AquaMail(メールアプリ)はデータ量が多いうえに外部から同期を開始させられないのでモバイルデータ量が増える要因なので、外部からの同期が可能なBlueMail(= TypeApp)に換えたのだが、使い勝手や好みではAquaMailの方が良い。

Wi-Fi接続のモニタリングと自動(強制)再接続

それで思い付いたのは、同期する仕組みの中の、「Wi-Fiが切れていたら再接続する」処理だけを定期的に実行することである。本来、Wi-Fiの再接続はOSが自動的に行うから自分でする必要はないのだが、ディープスリープ中はそれが結構長く遅れることがあり、その間に通信が発生するとモバイルが使われるので、それを回避するため、切断後なるべく速やかに再接続したい。AutomagicはWi-Fiの切断イベント(WiFi Disconnected)を受けられるので、それを契機にすれば切断後即座に接続できそうだ。また、何らかの理由(例: 帰宅時、ディープスリープ中)でWiFi Disconnectedがない・受け損ねた場合に備えて、定期的なチェックも行う。

基本的な処理の流れは以下である。

  1. 契機となるイベント(例: WiFi Disconnected, Periodic Timer Inexact)を待つ。
  2. 再接続処理を行う時期(例: 前回の処理から30分以上経過)だったら、以下を行う。
    • Wi-Fiを使用する設定になっていて、Wi-Fiが切れていて(WiFi Connectedが偽)、
      • 指定のAP(= 家のルータ)が利用可能(WiFi Available)なら、再接続(WiFi Reassociate)を行う。
      • イベントがWi-Fiの切断(WiFi Disconnected)で、指定のAPが利用可能でないなら、Wi-Fi APのスキャン(WiFi Scan)を行う。
      • イベントがWi-Fi APのスキャン結果(WiFi Scan Results Available)で、結果(AP一覧)が空の場合には、再接続(WiFi Reassociate)を行う※。
  3. ディープスリープ回避を行う時期(例: 前回の回避から30分以上経過)だったら、以下を行う。
    • ディープスリープ回避プログラムを起動する(実際にはプログラムを「有効」にすることでPeriodic Timerが起動され、ディープスリープの回避が始まる)。

※ 下にも書いたが、Wi-Fi APがあるにも関わらずWiFi Scanの結果が空の場合があり、その時に切断されたままの状態が長引いてしまうため、スキャン結果が空の場合にも再接続してみるようにした。ただ、画面を点灯すると自動的にスキャンが行われるようなので、外出時に無駄に再接続しようとして消費電力を増やす可能性はある。

実装後、さまざまな調整を行い、最終的には以下のような設定(動作条件)にした。

  • 処理の契機とするイベント
    • Periodic Timer Inexact, WiFi Disconnected, WiFi Scan Results Available, WiFi State Enabled, Automagic Startup
  • 再接続処理を行う最小間隔: 10分 (Periodic Timer InexactとAutomagic Startupのみ。それ以外は無条件に実行する)
  • Periodic Timer Inexactの周期: 15分
  • ディープスリープを回避する間隔: 30分
  • ディープスリープの回避
    • Periodic Timerの周期(= ディープスリープにしない時間): 1分
    • Periodic Timerを解除するまでの待ち時間(Sleep(Keep device awake)): 35秒

Periodic Timer Inexactの周期やディープスリープ回避の間隔を長くすると消費電力が減るが、切断時(Wi-Fiの鍵の期限切れなどで起こる)や帰宅時に再接続するまでの時間が長くなる可能性が高い。また、Periodic Timerを解除するまでの待ち時間は必要で、ないとディープスリープしてWi-Fiが切れてしまう。

当初は、基地局(セル)への接続イベント(Phone Cell GSM: Connected to CIDs)を使って帰宅の判定をしようとしたのだが、基地局の範囲は広いために家から離れたところ(Wi-Fiは繋がらない)で「帰宅」と判定してしまうのと、基地局の変化(増減)を常にフォローすることはできないから、いつまで今の判定条件が有効なのか分からないので止めた。

それから、画面を点灯させるとWi-Fiのスキャンが行われてWiFi Scan Results Availableイベントが発生するから、その時はPeriodic Timer Inexactの周期を待たずに素早く再接続できる(実際には、この場合はOSも再接続すると思われる)。

なお、同期間隔が伸びるのを防ぐために無効にしていた、カレンダー同期アプリの「電池の最適化」は有効に戻した。ディープスリープ回避の効果のようだ。

最終的な性能(特性)は以下のようになり、概ね要求を満たせたように思う。

Wi-Fiが利用可能な場所(家)で、約7時間(2/25 21:13 - 2/26 4:17)のアイドル時の性能:

  • 消費電力率: 0.6%/h (2/26 1:50までは0.4%/h)
  • モバイルデータの使用量(← Wi-Fiの再接続が遅れた期間): 約60KB (Wi-Fiの使用量: 約3MB)
  • Wi-Fiの再接続が遅れた回数: 3回 (再接続回数: 4回)
  • カレンダーの平均同期間隔: 約32分 (13回/7時間)

ディープスリープ回避処理により、Wi-Fiが長時間停まることはなくなったようだが、Wi-Fiの鍵の期限切れの時の再接続が数十秒遅れることがあるために※、モバイルデータが使われるのを完全には防げてはいない。ただ、OSを含むすべてのアプリからの通信をほぼWi-Fiにすることができたので、前回よりはモバイルデータ量が減ったはずだ。消費電力は以前より大きくなっているが*、低い期間もあるので他の要因が関係しているのではないかと思う。この点はもう少し様子を見たい。また、同期間隔は申し分ない。

※ Wi-Fiの再接続が遅れることがある問題の詳細な原因は不明なのだが、その時はWi-Fi APのスキャン(WiFi Scan)を行ってもAP一覧が空になっているので、スマフォ(AQUOS sense lite)の仕様(作り)に起因するものではないかと思っている。OSはWi-Fiデバイスは使える状態(「生きている」)だと思って使おうとするのだが、実際にはスマフォが停めていて、使われる時に陰で起動させるのだが、その立ち上がりに時間が掛かるために、最初のスキャンで結果が得られないのではないかと推測している。あるいは、Wi-Fiデバイスの立ち上がりが遅く、OSはそれを待ちきれなくて、モバイルが使われるのかも知れない。

* 消費電力増加の影響を考えてみる。: アイドル状態を継続(使わずに放置)できる時間を考えると、今回の消費電力率(0.6%/h)では前回(最小で0.3%/h)より約7日短くなる。が、実際にはそういう状況はなく、毎日使って充電しているので、その値は余り意味がない。それで、1日当たりの消費電力の差を求めると7.2%程度となる。そして、当然ながら、使っている時の消費電力はそれよりずっと大きい(数十%)ので、この処理による消費電力の増加はそれほど問題ではなさそうだ(と思ったが、通常は1日で20%くらいしか減らないから、7.2%の増加は大きいかも知れない)。

この作業はなかなか根気が要り、動作確認すると不具合が見付かって調整し、再度確認するという手順を何度も繰り返していた。動作確認は深夜などの長時間使わない時に放置することでしかできないので、なかなか時間が掛かり、3週間くらい掛かったが、ようやく終わったようだ(消費電力と再接続の遅れに我慢すればね・・・w)。

わずかなモバイルデータ使用量や電池使用量を減らすだけの、重箱の隅をつつくような改良ではあるのだが、Androidのいろいろなことが分かって(大体は想像)おもしろかった。それから、Automagicを使えば(いくつか不満はあるものの)ものすごくいろいろなことができるので、感心した。結構昔に買ったのだが、全く損はない。

(3/1 6:51) 月が変わったので、モバイルデータ使用量削減処理の効果を調べてみた。削減処理の作成を始めたのは大体2月からなので、1月と2月のモバイルデータ量を比較すれば分かりそうだ。

  • 1月: 134MB → 4.3MB/日
  • 2月: 81.8MB → 2.9MB/日

見かけ上は1日約1.4MBの節約となった。ただし、1月には設定誤りによるカレンダーの再取得や地図アプリ比較のための利用があったので、その分が多くなっているはずだから、過去のログからそれらのデータ量(カレンダー: 約16MB、地図: 11.8(1月分)-2.7(2月分)= 9.1MB)を引くと、以下のようになる。

  • 1月: 109MB → 3.5MB/日
  • 2月: 81.8MB → 2.9MB/日

1日600KB(27MB/月)の節約と、効果はかなり微妙(気分の問題??)だ。ただ、データ量削減処理は2月の半ば頃から動き出したし、処理の作成や修正による増分もありそうなので、今月の分を見てみないと本当の効果は分からない。ただ、劇的に減ることはなさそうだ。

それでも、現在のモバイルデータの残量は1GB(契約は500MB)になっているので、まあ、全体としては目論見どおりである(良く考えると、繰り越しできるのは前月分だけだと思っていたが、そうではない? それならなおありがたいが・・・)。

 

PS. この作業中に他の問題も見付かったので、書いておく。

○同期アプリごとの問題

  1. 同期が不安定なもの: Androidの再起動後にカレンダーの予定がほとんどなくなって、同期がうまく行かなくなった。
  2. 同期のデータ量が多いもの: 同期は調子いいのだが、常に数十KB(上の約10倍)のデータを取得する。取得するデータの選択がインテリジェントでない?

不安定なのは良くないのだが、最初だけ何とかすればあとはうまく動くから、データ量を減らしたいので、1番を使うことにした。

○Wi-Fi matic(位置に基づいて自動的にW-Fiを有効・無効にするアプリ)の問題

なぜか、Wi-Fiを有効にする場所なのに無効にされてしまうことがある。有効・無効はモバイルの基地局(セル)で判定しているのだが、家に居ても基地局がたまに変わる(3つくらいあった)のに、1つしか記憶しないために無効にしてしまうようだ。元々なのか、設定を変えてしまったせいだろうか? しかも、このアプリはGoogle Playからなくなってしまっているので、使い続けるのは好ましくない。Wi-Fi maticは家以外に居る時(外出時)の消費電力を減らすために使っているのだが、とりあえず、使うのを止めることにした。

それから、複数の基地局に対応したWi-Fi maticの代わりを作ろうとしたのだが、難しかったので止めて、常にWi-Fiを有効にしたままにすることにした。問題になるのは、外出時に無駄にWi-Fiが有効であるために消費電力が増えることだが、外出時は操作やモバイルデータの消費電力の方が大きいので、大きな問題ではなさそうだ。

PS2. この、Wi-Fiが途切れる(勝手にoffになる、再接続が遅れる)現象は僕のスマフォ・環境(ルータとの相性)だけで起こるのか、それともAndroidなら他でも起こるのか気になるところだ。何となく前者の気はするが、実は後者だけど、細かい話だから誰も気にしていないのかも知れない。

PS3. モバイルのデータ残量を見たら、月末だというのに690MB(→ 先月の繰り越し分が190MB余った)も余っている。繰り越しできるのは1か月だろうから、節約し過ぎても意味がないのかも知れない。であれば、多少の接続遅延を許して(= Wi-Fi時でも少しモバイルが使われる)省電力に振る方が得策なのか? 「そんなのどっちでもいい」というのが真実のような気はするがw、まあ、ちょっと考えてみよう。

という具合に、"Never ending story"になる。。。 (2/27 18:58)

  •   0
  •   0

懸案のドラレコだが、本物の設置方法を詳細に検討して何とか方針が決まって、「さあ、注文だ」と思っていたのだが、風邪気味でだるくて、「届いても取り付けられないな」とか思っているうちに、本質的なことに疑念が生じてしまった。以下のような考えだ。

  • 今までに、事故は10年に1回くらいしか起こってないのに、(期待値としての金額は前回書いた通りではあるが、)そのための準備が要るの? しかも、これからは今までよりずっと乗らないから、確率も期待値もかなり減りそうだ(また乗ることになったら、話は別)。
  • 「準備」と言ったって、家の耐震補強とか非常食とかABSやエアバッグと違って、ドラレコを付けても、安全性(事故の起こる確率)は全く変わらない。「ドラレコを付けたら事故が減る」とか、事故になった時の死亡率が減るなんてことは全くなく、あくまでも事故が起こった後に自分の立場を守るとか嫌な思いをしないためだけのものなのだ。
    • (2/26 7:50追記) つまり、ドラレコは「アクティブセーフティ」どころか「パッシブセーフティー」でもない何か(おそらく、「安全のための機器」ではない)なのだ。それから、「ドラレコを付けたら・付ければ、運転が記録されることで緊張感が生まれて、安全運転につながる」という意見・説もあるが、論外だ。記録の有無に関わらず、いつもちゃんと運転しなくてはならない(僕自身が実践できているかは別として)。そういう人は、そのうち、記録されていることなど忘れて、イザという時に困るのがオチだ。
  • 「立場」と言ったって、今は別に何も失うものはないし、任意保険の弁護士特約には入っているし、いくら準備したって、事故になったら嫌な思いをするのは確実なのは分かり切っている。
    • (2/26 7:53追記) 例えば、突然飛び出して来た人をひいて殺してしまったら、いくらドラレコの記録でこっちに何も非がなかったことが証明されたって、「何もなし」では全く済まないだろう。
  • せいぜい考えられる、回避・軽減可能な損失は、(こっちの過失割合が大きくなって)保険の等級が上がって(というか、少しでも保険を使えば過失の割合には関係ないだろう)保険料が上がるのと、免許の点数とか刑事罰の重さで、ドラレコがあればその度合いが小さくなる可能性がある程度だ。そんなことは、自分の怪我とか嫌な思いに比べたら屁でもない! (まあ、刑務所行きはちょっと嫌だが、さすがに、自分が悪くないのに、ドラレコがないためにそこまでひどいことになるとは思えない。そうなるのなら、自分もそうなる原因を作っているのだ・・・)
  • あと、駐車中の当て逃げなどはまず防げない(ぶつけた車は分かるかも知れないが、ぶつけられることは全く防げない)。これはどうしてか、いつまで経っても嫌な気分を思い出させるので、それに無力なのなら、余り価値がない。

と思ったら、

別に要らなくね?

と思ってしまった(若者言葉はノリで使ってますw)。

だから、ポチっとするのは止める感じだ。ただ、あって損ではないのは確かだから、もし次に車を買う時には迷わず付けると思う。

あと、遊びとしてのドラレコはおもしろいので、スマフォでドライブの光景を「テキトーに」録画するのはやってみたいと思った。それは、なぜか、自分の運転を自分で観てもおもしろかったくらいだからだ。

 

PS. 以前にもこういうことはあったが、その時も今も、全然、無駄とかつまらないことをしたは思っていない。逆に、「おもしろかったからいい」くらいだ。そういうところが技術馬鹿なんだと思うw でも、文系(経済?)の人とかスマートな(= 意識高い)理系は、検討したたけで(いや、それ以前に「そんなの当たり前・自明でしょ()」で)終わりそうだ。それじゃあ、全くつまらないと思う。

PS2. やっぱりコスパ最高なのは、「録画中」のステッカーかな。いやマジで。もちろん買わないし貼らないけどw

  •   1
  •   0

ドラレコの設置場所に迷った。フロントガラス上部よりダッシュボードの上の方が手軽そうでいいと思っているのだが、下部が良く映らないという情報があった。考えても分からないので、買って試そうと思っていたのだが、まず今(無料で)できることをやってみようと、段ボールで台を作り、ダッシュボードに古いスマフォ(Nexus 4)を仮置きして、どのくらいの視野で撮影できるか試してみた。もちろん、実際のドラレコとは視野角は違うだろうが、下部の切れ方は設置する高さや角度の影響の方が大きいと思うので、実際(予定)に近く設置すればスマフォでも確認はできると思った。

設置時に、作ったままでは高過ぎる気がしたので、下の箱を外した(実はこの箱は、「高さが足りないかも」と思って後から追加したものだ)。

意外にちゃんと撮影できていて、観てみたら予想以上に良く、視野はまず問題なさそうだった。写りも良くて、途中で観た時は「これでいいじゃん!」と思い掛けたのだが、帰ってから調べたらものすごく電池を食っていた(約35%/h)ので驚いた。これでは3時間も持たない。まあ、アプリ(今回はアウトガードというのを使った)や設定を選べば減るかも知れないし、SIMを入れていないために、例の「セルスタンバイ」も電池を食っていたから、ダミーのSIMを入れれば減るかも知れない。それに、常時USBから給電すれば、電源は問題はないだろう(が、電池はすぐに寿命になりそうだ)。

それでも、何となく無理があって実用には向かない気はする。あと、スマフォが大きくて若干目障りな問題もあった。その点では外部カメラが使えればいいが、USB 2.0でまともに動画が転送できるかとか、OSやアプリが対応しているかどうかが疑問だ・・・ それから、後方が撮影できないという欠点もある(スマフォを2台使えばできないことはない。確かに2台余ってはいるけど・・・)。

以下に、市街地での撮影例を示す。

※エンジンや排気の音が結構迫力あるのだが、元々そういう車(改造はしていない)なのと、構図やマイクなどのせいで更に迫力が出ているのだと思う。暴走している訳ではないので、誤解せぬよう・・・

サンプルは再エンコードしたためにぼやけているが、元の動画は以下のようにかなり鮮明で、(縮小しても)他車のナンバーがはっきり読める。

スマフォドラレコで撮影した動画のキャプチャ

それから、やる前は、カメラの固定をかなりちゃんとしないとブレて駄目だと思っていたのだが、こんないい加減な台(若干傾いてさえいる)でもそれなりに見えるし、そもそも、僕が使いたいのは事故などの問題のあった時だけなので、多少振動しても問題ないことに気付いた。ただ、衝撃でカメラが動いてしまったら、肝心の場面が映らない可能性もあるので、それなりにしっかり固定する必要はあるだろう。

あと、スマフォなら、部屋に持ち帰れば簡単にドライブ中の映像をPCに取り込めるのもいい。ドラレコだといちいちmicro SDを抜くのが面倒だから、問題のあった時だけ使うことを想定していたが、手軽にできるのなら欲も出て来る。なお、動画ファイルのサイズは意外に小さかった。5分で200MB以下だった(いや、これは実は1時間で2GBを超えるから、大きいのだw)。

という訳で、試してみたらいろいろなことが分かった。そして、スマフォドラレコの手軽さ・安さも捨てがたいので、もう少し考えてみたい。

以下のように進めようと思う。 (16:27)

  1. 夜の撮影具合を試す。
    • (2/25 5:36) アウトガードの消費電力が大きかったのでAutoBoy Dash Camを試してみた。
      • まれに焦点がボケた以外は、大きな問題はなかった
      • 電力消費率は約10%/hだった。
      • 今回はダミーSIMを入れていたので、再度、アウトガードの電力消費率を測りたい。
      • スマフォドラレコでの撮影例3 (夜間, アプリ: AutoBoy Dash Cam)
  2. 良さそうなら、ドラレコにも使えそうなスタンドを買い、スマフォを正式に設置して使ってみる。
    • 良さそうなら、外付けのカメラ(webカメラ?)を付けてみる。(ただし、いいものは結構高いので、要検討)
  3. 駄目そうなら、本物のドラレコを買って取り付ける。

(2/25 9:46) 今、別のアプリを試に行こうかと思っていたら、根本的なことに気付いた。スマフォドラレコは確かに手軽だが、本物同様の信頼性は望めないということに。例えば、以下のような問題で正常に動作しなくなる可能性は結構大きいから、「いざという時に記録されていなかった」ということはあり得る。ドライブの記録ならがっかりするだけだからいいが、事故などの証拠用としては論外である。

  • 夏の高温、冬の寒さ、結露
  • 連続書き込みでのストレージの劣化
  • 電池寿命
  • アプリやOSのハングなど

そのような問題を防ぐには、定期的に(毎回?)正常動作を確認するべきのだろうが、それは現実的でない。忘れなければやるかも知れないが、そもそも面倒だ。本物でも原則的には動作確認は要るが、スマフォはより信頼性は高そうだから、確認の必要性は低いことが期待できる。定期的なmicro SDの交換を忘れず、使用時は警告が出なければ正常動作が期待できる。

という訳で、やっぱり本物をポチっとするかな・・・

いろいろ試したのが無駄になった気はするが、そもそも、スマフォドラレコは「本物」の設置方法を検討するために始めたのだから、こういう結論になっても無駄ではなかったのだ。まあ、プロトタイプとか実証実験のようなものだったのだ。それで設置方法だけでなく、実際に使う時に外せない条件に気付けたのだから、本当に成功と言えよう(と、自画自賛してみるw)。

 

PS. テストで走っているだけでも気持ちが良くて、気付いたら1時間半、30kmくらい走っていた。

PS2. さすがにNexus 4は古いせいか(2013年に購入)、側面のゴムのような部分が劣化してベタベタになっていた。最初はケースが劣化したのかと思っていたのだが、本体まで劣化していた。ケースは貼り薬(例: トクホン)のような臭いまで出していた。。。 まあ、これなら心置きなく使い倒せるw

PS3. ダミーのSIMは、iPhone 6sを買った時に、本物のSIMが届くのが待ち切れなくて、すぐアクティベートしたくて買った未契約のものがあったのだが、サイズが違っていた(Nexusはmicro, iPhoneはnano)。ただ、セロハンテープでうまく誤魔化したらなんとか認識した。位置合わせと接触をちゃんとする以外に、挿入する前か後に一旦電源を切る必要があるようだ。これでセルスタンバイの消費電力は減るだろうか? (何となく、関係ない気がする・・・)

PS4. Nexusよりは新しいiPhone 6sも余っているから、ドラレコアプリを探したのだが、検索しても無料でまともなものがなさそうなうえに、App Storeは(昔からそうだが、)webでは全く使いものにならないので、呆れ果てて使う気が失せた。まったく、煮ても焼いても食えない腐った林檎だ。まだ人気はあるようなイメージだが、開発者は段々逃げつつあるのかも知れない。

(3/10 20:53 動画のサイズがかなり大きい(3個で25MB)ことに気付いたので、リンクに変更)

  •   0
  •   0

もはや当たり前(一種のブーム?)のようになっている、ドラレコ。僕も、今まで何度も付けようか迷っては、止めて来た。今も再び迷っているのだが、おそらく止める気がする(← 書いたあとで気が変わったw →)面倒ではあるが、付けてみようかと思う。迷う理由はいくつかある。

  1. 必要性に疑問がある(リスクとの兼ね合い)。
  2. いい製品がない。
  3. フロントガラスに赤外線カットフィルムを貼っているので、取り付けに不安がある(フィルムが剥がれないか)。
  4. これ以上、前面がごちゃつくのが嫌(今既に、GPS, VICS, ETCのアンテナが並んでいる)。

まず、1番(一番重要)は、今の僕の状況を考えると必要性が薄そうに思える。今は通勤に使っていないので、乗る機会は少ない。せいぜい月に2回だ。ドラレコが有用なのは、事故に遭った場合、かつ、相手が悪質な場合や、人や自転車が飛び出して来た場合だろう。他には、煽られたとか警察が言い掛かりを付けて来たとかだろうか。それらの起こる確率はどの程度だろうか? ドラレコがないことによる損害の期待値(平均損害額)はどのくらいだろうか? 少し考えてみる。

ドラレコがないことによる損失の期待値(平均損害額)の試算 (1回の運転当たり)

  • 車に乗った時に事故に遭う確率 R1= 3回/36年= 3/(2*(36*365)/3)= 0.000342 (今までの実績。今まで3日に1日(各日の往復を2回とする)乗っていたと推定した。バイクは含まず)
  • 事故に遭った時にドラレコがないことで嫌な目に遭う確率 R2= 1/2 (相手が悪質な場合などで、ドラレコが役に立つ場合。推定)
  • 事故に遭った時に嫌な目に遭うことでの損害額 L1= 10万円 (推定)
  • その他の嫌な目に遭う確率 R3= 1/100 (推定)
  • その他の嫌な目に遭った時の損害額 L2= 10万円 (推定)
  • 合計の損失の期待値 L= L1*R1*R2 + L2*R3= L1(=L2)*(R1*R2 + R3)= 1017 (円/回)
  • 参考
    • 月に2日(24日/年)乗った場合の年間の期待値: 約4.8万円 (各日の往復を2回とした)
    • 毎日通勤で乗る場合の年間の期待値: 約41万円 (年間200日乗るとし、各日の往復を2回とした)

確率は苦手なので、上の計算が合っているか不安だが、合っているとすれば、今の状態でも付ける価値はありそうだ。今までドラレコがなくても損害がなかったのは、確率の計算の常で、これからある可能性が高いと解釈すればいいのだろうか(本当はそうではないようだが、実に分からんw)。

なお、今まで事故のたびに嫌な目に遭ったが、ほとんどは精神的・時間的なものだった。一度当て逃げされたが、それは駐車中に側面を擦られたものなので、ドラレコがあっても役に立たなかっただろう。その他の事故では相手が過失を認めたので、金銭的な実害はなかった。

「その他の嫌な目」については、煽りとかはあるものの、特に損害は受けておらず(ドラレコがあっても煽りはあると思うし、通報しても実益があるだろうかとは思う。ステッカーだけで充分な気はする)、警察などからの言い掛かりもなかった(仮にドラレコがあっても、覆すのは難しいかも知れないし、言い掛かりよりも、本当にこっちが良くないことをしている方が多い)。

2番は以前からずっとそうだ。以下のような条件を全部満たすものはほとんどない。

  • 耐久性・信頼性がある。
  • 前後を撮影できる。
  • 取り付けが楽。
  • 値段が高過ぎない。
  • 小型・軽量

外国製の安い製品は耐久性や信頼性に欠けるイメージがある。例えば、去年は評判が良かったメーカーが今は全然人気がなかったり、メーカー自体がなくなっているのを見ると、「やっぱりな・・・」としか思えない。いい物を出しているなら、ずっと人気があるはずだし、会社も継続しているはずではないか。それから、外国製のルームミラー型はカメラの位置が左ハンドル用なので、今ひとつ撮影条件が良くないという話も読んだ。

国内メーカーにしたって、必ずしも良い訳ではでないようで、すぐ壊れた・壊れやすいとか、定期的にメディア(micro SD)をフォーマットしなければならないとか※、サポートがひどいとかいうのが多く、それらを除外するとほとんど残らない(僕の調べた限りでは、存続が危ないP社しかない。笑えることに、今回の最有力候補は去年のそれと同じだった)。もちろん、外国製より値段は高目だ。

※僕の意見では、メディアを定期的に(2週間に1回など!)フォーマットしなければならないのは、ドラレコ自体の作りが悪いせいだ。確かに、良く言われているようにフラグメントは起こるが、そもそも、フラッシュメモリではフラグメントの影響は少ない。実際、SSDにデフラグは不要ではないか(要る説もあるが)。動画記録が遅くなる可能性はあるが、エラーを出すものではない。

定期的にフォーマットしなければならないのは、ドラレコの電源断などの処理がイマイチなために、論理フォーマットが壊れる(壊す)可能性が高いからだろう。だから、平気な顔して「定期的なフォーマットが必要です」などとマニュアルに書くメーカーの技術力を疑う。

なお、メディアが寿命で壊れるために定期的に交換する必要があるのは仕方ない。ドラレコは大容量のデータを連続して書き込み続けるので、TLCなどの安いものだとすぐに寿命に達してしまうのだ。このことと定期フォーマットが混同されているフシもある。フォーマットすると一時的に使えるようになる場合が多いが、寿命なのですぐに駄目になってしまう。こういう用途にはSLCを使ったものがいい(実際にはSLCでも出来が悪くて駄目なものもある)のだが、そもそも売ってないうえに、すごく高い。

「煽り運転対策に有効」とか言いつつ、未だに前後を撮影できる製品が少ないのは、マスコミの欺瞞(ブームを作る時に良くあるパターン)やメーカーの怠慢が感じられる。

3番は詳しい説明は不要だろう。ルームミラー型にするか、取り付ける部分のフィルムを切って剥がすかになる。ミラー型は余りないし(実は、今回の検討のきっかけは、サンコーのミラー型の新製品だった)、フィルムを切るとそこから剥がれ出しそうなのでしたくない。他に、ダッシュボード上に付ける手もあるが、下の視野が狭くなってしまうようだ。

4番は、純正オプションなら綺麗にまとまるだろうが、後付けだと物やケーブルがごちゃつくだろう。リアカメラが付くものは、前だけの物よりも更にケーブルが増えるのも痛い。そして僕は不器用なので、綺麗にまとめられる可能性が低いw

なんだかんだ言っても1番が一番重要なのだが、上の検討より、あった方が良い感じだ。なるほど。もう少し積極的に考えたいが、計算する前は「余り乗らないから要らない」という結論だったので、どうも納得が行かない。自分で計算したのではあるが・・・

まあ、付けて悪いことはないのは確かなので、(既に候補は決まっているので、)もう少し具体的に考えてからポチっとしようと思う。

 

PS. いい製品がないので、基本的な処理としては動画を撮るだけだから、(スマフォなどを使って)自分で作りたくもなったのだが、実際には難し・面倒そうなので止めた。

  •   0
  •   0

技術バカ者たるもの、謎は解きたいので、先ほど不明だった、ダイソーのUSB LEDランプの消費電流を測ることにした。ただ、僕は直流電流がまともに測れるデジタルテスターなんて持ってないので、どうにかする必要がある。

最初は、AC電源の消費電力を測るエコチェッカー(= ワットチェッカーもどき: 本物を持っていたが、寿命のせいか壊れたので、同様のものを買った)でACアダプタの消費電力を測ってみたのだが、さすがに小さくて"0W"なので、有効な値を得るには数時間くらい点灯したままにしなければならず、まぶしいし面倒だし精度も悪そうなので止めた。

仕方なく、手持ちの物を駆使して測ることにした。理論的には、電源と小さい抵抗(例: 1Ω以下)と電圧計があれば、電流は電圧として測れる。以下に、その模式図を示す。

                      電圧計
                
電源 |+ ———> 小抵抗 ———> +| 測定対象
    |- <—————————————— -|

ところが、うちには小さい抵抗なんてない。しかも、実際に上図のように接続するには、USBを受けてバラ線にして抵抗を通して、またUSBに直せるようなものが要るが、そんな気の利いたものはない! でも、そんなことで諦める訳にはいかないのでw、手持ちの物で何とかすることを考えた。そして、もはや遺物とも言える、USB→PS/2変換コネクタ(以下、変換コネクタ)と余っているUSBケーブルを使うことを思い付いた。以下に、その構成を示す。

               電圧計 
      (USB-A)                     (USB-A) 
USB電源 |+ ——> 小抵抗 ——> | 変換コネクタ | ————> +| ランプ
        |- <———————————— |           | <———— -|
          USBケーブル (バラ - PS/2のピン)

変換コネクタの中は直結であることが分かっているので、それを分解するなどして、USBの線を出せるようにすればいい。最初はプラスティック部を切って開けようとしたのだが、大変だったので、PS/2コネクタの円筒形の金属部をラジオペンチで力任せにひねったら、うまく外れて、ピンに線を半田付けできそうな感じになった。

そして、USBケーブルのBコネクタを切断して線を出して、対応するPS/2コネクタのピンに半田付けした。一つだけ忘れてはいけないのは(実は危うく忘れた)、片方の電源の線だけは直結せずに、途中に抵抗を繋げられるように、2つのミノムシクリップに繋ぐことだ。予想以上にうまく行って、抵抗なしの(ミノムシクリップを直結した)状態で、ちゃんと点灯した

次に、電流を電圧に変換する抵抗を用意する。上に書いたように小さい抵抗なんてないが、10Ωは沢山あったので、それをとりあえず10本並列に繋げて1Ωにした(もし駄目だったら、さらに10本追加して0.5Ωにしようと思っていたが、大丈夫だった)。これもうまく行って(ただ、テスター自体か電池が劣化しているのか、実際の抵抗値は測れなかった)、ちゃんと電流(正確には1Ωの両端の電圧)が測定できた

そして、目的の電流測定結果は予想外というか予想通りというか、「さすが中国」であったw

1Ωの抵抗の両端の電圧は約0.27Vだったので、以下の計算より消費電流は約270mAとなり、記事での値(292mA)とほぼ合った。

オームの法則より、電圧E= 電流I×抵抗Rなので、I= E/Rとなる。
ここで、R= 1Ωなので、I= E/1= Eとなるから、
電流I= E= 約0.27A = 約270mAとなる。

なお、抵抗での電圧降下は約0.27Vで、これがランプの点灯回路の動作を変えて、消費電流(の測定値)に影響しないかという疑問はあるが、定格電圧(5V)の10%未満なので問題なさそうだ。実際、見た目の明るさは変わっていない。なお、もしランプの消費電流が仕様通り1Aだったら、電圧降下は1Vとなるので、良くないだろう。

それにしても、3倍以上(仕様では1-1.2A)にもサバを読むとは、さすが中国だ。もしかしたら、中には仕様どおりに大電流を食う、ものすごく明るいものがあるのかも知れない。それはきっと「当たり」なのだろうw もしかすると、ほとんどが暗い不良品で、ごくまれに良品があるのかも知れないな。それはそれでおもしろいが、僕はこっちでいい。

PS. 余談だが、更に正確に測定するなら、まずは抵抗値を正確に測る必要がある。例えば1本ずつなら測れるかも知れない(でも、アナログなので、誤差が結構ありそうだ)。次は、テスターの測定値(電圧)の較正だ。基準電圧としてボタン電池が使えるだろうか。あとは、なんとかして直流(抵抗両端の電圧)を周波数に変換できれば、それをPCの音声入力に入れて取り込んで解析すれば測れそうだ。いやいや、安いデジタルテスターを買うのが一番いいよw

(2/15 22:27 わずかに追加, 2/16 7:50 図を改良)

  •   0
  •   0