Edisonの移動カメラ化はさっぱりすすまず

初めての五竜遠見スキー場。季節外れの豪雪(3/13/2015)
　今年2回目のスキー行が近づいた1週間ほど前、仕事から帰ってきて急に気分が悪くなり食べたものを戻した。微熱がある。夜遅くからは激しい下痢に見舞われる。どうもノロウイルスにやられたらしい。医者は3～4日で良くなると言ったが、出発まであと4日、スキーを中止するかは微妙なところだ。

　2日間は食事らしいものは何もとれず。スキーに行く前日にやっと下痢が納まり、おかゆが食べられるようになった。自分の車で仲間を乗せてスキーに行く約束をしているので中止は避けたい。連れに事情を話し、恐る恐る予定通りスキーに出かけた。

　関東平野は快晴だったが、スキー場に近くなると雪が激しくなった。春も半ばというのに猛吹雪である。宿のペンション前の坂が上りきれない。先に着いたもう一台の仲間の車は180度回転したそうだ。別の道から迂回して何とか宿の駐車場にたどりついた。

　今回のスキー場は、いつも出かける八方尾根の宿が競技会の本部になってしまったので、その隣の五竜遠見スキー場である。何十年もこのあたりに来ているが初めてのスキー場だ。楽しみにしていたのだが、体力が心配だ。

　でも泊まったペンションは当たりだった。ゲレンデにも近く、食事も上品で、ロビーに恐ろしく贅沢なオーディオ装置があるのに驚いた。バブルの儲かったときに先代が揃えたのだという。JBL4344などのスタジオモニター2組と、タンノイのArden（アーデン）が聞き比べられるようになっている。アンプはマッキントッシュ（管ではなく石）。クラシックはやはりタンノイが良い。

　体の方は、順調に回復した。当初食べられる量はみんなの1/4だったが、帰るころには普通に戻り、スキーをやるのには十分だった。ただ季節外れの大雪でゲレンデには、1m近い新雪が積もった。 　腕試しに、圧雪していないバーンに飛び込んでみたら、雪が重く、スキーを浮かすことも出来ず、斜滑降のまま前のめりに転倒した。これが簡単に起き上がれない。深雪スキーなどと洒落れているような状態ではない。ほうほうのていで退散した。

　今回はノロウイルスのせいに出来るが、基礎体力は間違いなく低下している。残念だけれど仕方がない。体力相応（年相応）のスキーをやるしかない。まあ、スキーそのものは誰もけがもなく無事に東京に戻ってきた。

いんちきなSDカードリーダーで写真データを失う(3/17/2015)
　しかし、帰ってからも不運は続いた。スキーの写真をPCに移すため、カメラから取り出したマイクロSDカードをUSBアダプターに付けているうち読めなくなったのである。1回目は読めたのだが、2回目から全体が読めなくなる。ディスク自体がないというとんでもないエラーメッセージだ。

　USBプラグにSDカードのソケットがついている簡便なタイプのSDカードアダプターである。このアダプターは前にもこんな事故が有ったような気がする。確かこれで2回目である。SDカードを調べてみるとマスターディレクトリがこわれているようだ。家族が使っていたカメラなのでバックアップは殆どない。

　データそのものは壊れてなさそうなので、データを回収できるユーティリティをウェブで探した。有償、無償を問わず、無数のリカバリーソフトが見つかった。定番のものはなさそうだ。このあたりは商売になるようで、見つけるときは無料でも、取り出そうとすると有料になるソフトがあったりするので気を付けないといけない。

このリカバリーソフトで幸い99％の画像データは回収できた（家族の申告による）。面白いことにこのソフトは、Windows版はデータ回復が連続してできないなどの制約があるが、Linux版は全くフリーで使える。

　家族がカメラに入れたままにしていた写真データなので(大事なものはバックアップがあった)、幸い大事にならずに済んだが、一度事故があったにもかかわらず、このアダプターをそのまま部品箱に入れたままにしていた自分の不明を恥じる。このアダプターをどこで買ったのか今になれば全く思い出せない。とりあえずはゴミ箱に直行させた。

2つ目の抵抗を焼いて、遂にDCDCコンバーターの自作を断念(3/23/2015)
　こんなこともあって、電子工作の意欲は下がるところまで下がってしまった。Edison基板の電池電源の調査は、NiMH(ニッケル水素)電池4ヶを、DC-DCコンバーターNJM2360で昇圧して(7.5～9V)動かして以来、先に進んでいない。

　スキーに行く前に、インダクターを大型のものに取り換えたり、抵抗の定数値を変えてみたり、配線を短くして見たり、すこしづつ様々な方法を試していたが、いずれも目立った効果はなかった。

　性能に関わるファクターが沢山ありすぎる。まず、単体のNJM2360か、外付けにパワーTRを付けるか、さらにFETをつけるかの選択肢がある。それに、インダクターの種類でも結構性能が変わる（URL参照）。

　入力電源を何にするかでも最大出力電圧（電力）は大きく変わる。リチウムバッテリー(3.7～4.2V)の電池の大小でも変わるし、数Aの容量を持つACアダプターであっても、それに見合う電力が出るわけではない。定格容量内であっても電流を流していくと出力電圧が落ちて電力が下がる。

　今のところエネループ、NiMH電池が一番高出力なようだが、これも満充電のとき(1.4V)は良くても、最後の方(1.1V以下)では、リチウムにも及ばない(4ヶで4.4Vなのだが)。

　色々いじったが、結局、入力をNiMH(4ヶ)に仮に固定し、設定電圧を7.5Vとして、単体では6.3V 294mA (1.85W)の出力が最大だった。外付けパワートランジスター（2SC3694）を入れても、6.7V 358mA(2.4W)までしか出力は出なかった。設定電圧は下手に上げたり（9V）すると、かえって出力は下がってしまう（電圧も電流も）。

　そもそもが、すべてブレッドボード上での実験である。汎用基板で組んでもうまくいかないことがあるという微妙な回路で、ブレッドボードのままで、性能が悪いと断定するわけにはいかない。それにしても心残りなのは外付けの効果があまり感じられないことだ。この回路図（FETひとつにTRを2つ）で組んだ外付けFET(IRLB8721)では、パワーTRより成績が悪かった。　

　実験をまだしていなかった最後の回路、FETとPNPトランジスターひとつ（2SA1015）を外付けしたものも試したみた。これも似たような性能で成果は上がらない。そのうち、誤接触で過大電流制限用の0.5Ω抵抗から一瞬小さな煙が出て、抵抗を焼いてしまった。

　ブレッドボードの配線をいじっているうちにVccをどこかでショートさせてしまったらしい。この抵抗を焼いたのは、これで2回目である。ひとつ5円もしないパーツだが、焼けて使えなくなってしまう（ひとつは断線、ひとつはキロオーム台に）こと自体が気分的に滅入る。これですっかり意欲を失ってしまった（へたれである）。

　UVCカメラ付きのEdisonを機嫌よく動かすには、7.5V入力なら、400mA以上を安定的に供給できないといけない（前記事の計測データから）。あともう少しなのだが、アナログは基礎がないので、何をするにもすべて手さぐりで方向を定められない。

　それにNJM2360は相当設計の古いICで、どこかのサイトでは化石とまで言われている。インダクターや、パワーTR、FETなど沢山部品を揃えてしまったが、ここからの撤退はそろそろ潮時のようだ。

ストロベリーのテスト前に、Intelブレークアウト基板の電源を調べる(3/25/2015)
　実は、スキーに行く前、前記事でとりあげたストロベリーリナックスのDC-DCコンバーター基板を注文してあった（これを2つ、これを１つ）。これらの基板は超小型で、いずれも3～5V入力から、20V近くまで昇圧し、電流も800mA以上出せるという触れ込みで、値段もそう高くない。

　スキーに行く直前に届き、簡単なテストをしたところ、NiMH電池入力でEdisonが短時間ながらストリーミングまで正常に動作してしまったのである。今までのNJM2360での最高はカメラを付けるまでで、ストリーミングはできなかった。

　この成功が、NJM2360のさらなる実験に力が入らなくなった原因のひとつなのだが、これが長時間カメラを動かし続けることできるかはまだわからない。このコンバーターの長時間テストの前に、Intel純正のこのブレークアウト基板の電源系統をもういちど調べ直すことにした。

　というのは、前の記事のコメントで、この基板には、5VのVccに直接接続する電源供給の方法があることを教えてもらった。そんなこともあるので、安易にストロベリー基板に頼る前に、何が最善策なのか基本的なところを押さえておきたいと思ったからである。

　頂いたコメントにもあるように、この基板の詳しい回路図は秋月電子のホームページにPDFとして出ている。それによると、基板には、以下の3つの電源関係のICが載っている。型番から調べるとそれぞれ次の機能を持っているようだ。

MIC2039　　　電流制限IC
BQ24079　　　リチウム電池充電IC
TPS62133　　　降圧DC-DCコンバーター

完全な理解ではないが、これまでに調べたところでは、外部の7.5～15V入力は、TPS62133の降圧コンバーター入力で、一旦5Vに落とし(5V_SYSとVBUS)、5V_SYSは、MIC2039の電流制限ICと、BQ24079のリチウム電池充電ICを経由して、V_SYSとなり、これがEdisonのVccに入る。従ってVccは5Vではなく、リチウムバッテリーの3.15～4.4Vの範囲である。

　このDC降圧コンバーターの効率がどれくらいか、コンバーターを通さないで、直接5VをDC-DCコンバーターで作って供給するのが良いのかどちらが良いかは難しいところである。効率からみれば直接の方が良いに決まっているが、負荷の変動にどちらが強いかはわからない。

　コメントにある5V供給というのがどこから供給することを指すのかわからない。5V_SYSは、このPDFの回路図によれば、端子として出ておらず、簡単に5Vを供給するポイントはない。VBUSはEdisonのOTGのUSB機器に供給する5V出力で、ここから供給するのは何かおかしい（一応SBDを介して5V-SYSに入るようになっているが）。

　何度も回路図を調べたが、適当な5V供給ポイントが見当たらないのと、この基板で完結している系を乱したくなかったので当初の予定通り、7～15Vの外部入力ラインに9V程度の電圧をかける方針で行くことにする。

ストロベリーリナックスのDC-DCコンバーターでカメラが長時間動いた(3/26/2015)
　このストロベリーリナックスのDC-DCコンバーターは、短時間ながらスキーに行く前、Edisonにつないでカメラのストリーミングが動いた。ただし数分しか動かしていないので、安定して動くかどうかはわからない。長時間テストに入る。

　最初、スルーホールに接続できるジャンパーと電流値を測るためのシャント抵抗を入れたミニブレッドボード上の配線で試してみたが、どこかで接触不良が起きるらしく、立ち上がるもののカメラをつないだり、基板を動かしたりするとリセットした。

　そこで、コンバーター基板にピンをハンダ付けし、ミニブレッドボードにしっかり差して動かすと安定した。一時間経っても、全く問題なくウェブカメラは動作した。よーし、電源のハードはこれで決まりだ。NJM2360は残念なことをしたが、さすがは既製品のDC-DCコンバーターである。この程度の負荷では殆ど熱を持たない（Edisonは触れないほどではないがカメラを動かすと結構熱くなる）。

　Edisonのウェブカメラの負荷はどれくらいだろう。topコマンドで測ってみる。それによるとCPU使用率は50%で、これはmjpg-streamerのモーションJPEGでも、node.jsのffmpegのMPEG1ストリームでも変わらなかった。

　PC側のリソースメーターで見ると、転送量はモーションJPEGでは2Mbpsを超えている。一方、node.jsはMPEG1なので1Mbps以下である。apacheなどのHTTPサーバーを入れるとCPU使用率は50%ではすまなくなり、もしかするとこのストロベリーのDC-DCコンバーター基板では動かなくなる危険もあるが、現在のままでは、とりあえず問題はない。

　やれやれ、やっとのことでハードの問題はクリアしたようだ。次はこれをどういうパッケージに実装するかであるが大きな峠は越した。次の課題は、ストリーミングソフトの決定である。

node.jsではどうしてもWindowsで画面が出ない(3/28/2015)
　NiMH電池による電池駆動は順調である。電池の充電も2回目に入った。途中で止まることもない。単3のエネループ(1900mAh)4ケで、少なくとも3時間以上は動いているので実用には十分だろう。

　問題は動画ソフトである。ストリーミング画像はmjpg-streamerも、node.js(ffmepegのMPEG1)のどちらでも安定して出ている。node.jsの方が軽くて良いのだが、実はこいつはWindowsでは画像が出ない。一方、mjpg-streamerはWindowsでも画像が出るのだが、自分用の画面を切り出すことが難しい。前のRaspberryPiのときは難儀した。

　このmjpg-streamerのHTTPサーバーは簡易版で、CGIをサポートしていないだけでなく、スタイルシートがとても複雑で改造を諦めた。モーションJPEGなので反応が遅く、全体に重い。自分用にカストマイズしたいのならApacheなどの別のサーバーを必要とする。

　そこでnode.jsの方をサーバーとすることにし、画像をWindowsで出せるよういろいろ調べてみた。いじったところは、主にffmpegのパラメーターである。しかし、色々、パラメーターをいじるが（ffmpegの）、何を入れてもダメである。Webを探し回るが適切な情報はない。どうも原因はffmpegではなく、node.js側にあるような気がしてきた。

　しばらくはnode.jsのお勉強をする。node.jsはPERLやRUBYのようなスクリプト言語(JavaScript)のインタープリターと考えれば納得がいく。インタープリターなのでソースコードが直に見える。調べたところでは、jsmpegというコマンド（？）がストリームをデコードしているようだ。

　しかし、ウェブを幾ら漁っても、これがWindowsでは動かないという文言が見当たらないのである。うーむ、ウェブの断片的な情報では、全体をつかむのが難しい。ちょうど良い機会なので仕事の帰り、久しぶりに秋葉原の書泉に寄って、こんな本を買ってみた。

　書泉はさすがに専門書が揃っている。node.jsの本だけでも10冊近くあった。ただ、何が適当な参考書なのかはわからない。迷った末、定番のオライリー本にする。脱線につぐ脱線だがまあ許してもらおう。このあたりでブログに報告することにする。もう20日も経ってしまっている。