« 2018年9月 | トップページ | 2018年11月 »

VNC非対応のマシンを遠隔制御する

Remote8
 
「どうやって遠隔地のモニター画面を見るか」シリーズ
、大して人気がない中、黙々と続け、ついに完成しました。

 液晶モニターの画面は設定した時間が経てばオフになるようJavaScriptを組んだまではよかったけど、USBエミュレーターを操作する画面と、モニター画面を同居させるのに難航。
 お互いのjavaScriptとstyleSheetのいいとこ取りして一つのhtmlファイルにしたものの、jqueryの配列エラーがどうしても解決できず、まぁいいや一般ユーザーが使うページじゃないし、と言い訳してかつて使い慣れたフレームを使うことに。

 ところがframeってhtml5で廃止されたんだとかで、iframeなるものを利用。 centerタグも非推奨だとか、ほんに昭和は遠くなるばかり。
 それでもなんとか上のキャプチャーのようなものができあがり、恐る恐る外向けの回線に乗せ、インターネット経由で使ってみたら、確かにローカルよりは遅くなるものの、想像したよりはましだったのに一安心です。
 この回線、以前に報告したLTE利用の非常に遅いものですから、一般的な光回線ならローカルテストとほぼ同じレスポンスが得られるような気がします。

 いやぁ、しかしもう慣れたとは言え、「こうしたい」と考えても、必ずどこかで躓くのはなんなんでしょうね。 そして何だかんだ悩みながらもいつも必ずそれは乗り越え、「やれやれ、次はこれだ」というところでまた躓く。 もう定番ロールプレイングゲームみたいなもんです。

 一ヶ月前にラズパイを買って以降、パソコンハードとLinux、I/Oポート制御、電子工作、プログラミング、コーディング、ネットワーク等々、よくもまぁこれだけこなせたもんだ、というか、器用貧乏のシンボルみたいな仕事となりました。 はい。

| | コメント (0)

残念ながらあなたのアカウントAmazon.co.jpはブロックされます

 ってメールが二度ほど来て、最初はフィッシングだろうと即刻無視したものの、二回目はちょっと気になって調べてみました。
 よく読むと「ご不明な点がございましたら、お気軽にお問い合わせください。」と言いながらfromがnoreplyになっているあたりがダメなんだけど、それでも納得するために一応。
 
 Macのデフォルトメーラーである「メール」で貼られているurlを調べると、おお、ログイン画面の出来が良い。 日本語もちゃんとしている。 これを見て一瞬信じかけた。
 でも、そもそもhttpsじゃない。 
 このログイン画面、パスワードと共にアカウント名まで訊いてくる。 これ、フィッシングなら一発で漏れ漏れですよね。 ところが、本家の方も、ログインをしようとすると(当たり前だけど)確かにアカウント名を訊いて来ます。 常時ログインを常用していない人はむしろごの画面に慣れ切っていて、つい入力してしまうかもしれない。 う〜ん、紛らわしい。
Amazonfish

 では、と今度はメーラーで詳細を表示すると、Received:⁨from bhalu2eshop by dwcl.digiworldcomと出た。 なんじゃこりゃ、と試しにindexらしきurlを叩いてみるとこんなんしか出て来ず、意味不明。
 ちなみに、まともなAmazonからの到着予定メールでは、Received:⁨from a25-8.smtp-out.us-west-2.amazonses.comとなっています。
 
 正直、今まで多数のフィッシングや詐欺メールを受信しつつ、全てレイアウトが崩れていたり、日本語が変だったりと、こんなん騙されるほうがアホやでと思ってましたし、自分ならもっと巧妙にやるんだけどなぁ、なんて自惚れたことも考えていましたが、今回のはちょっと危なかったです。
 ちなみに下のは純正ログイン画面。
Amazonright

| | コメント (0)

無法者M.マルケスには師匠がいた

 一気に書こうとしたけど、やっぱ分けたほうがいいのかな、と昨日のM.マルケスmotoGPチャンピオン獲得の続き。

 彼の肉弾ライディングには実は模範がいるというか、いつだったか、ペドロサやドヴィなど数人がまとまってコースアウトするアクシデントがあったとき、ペドロサは「僕たちはこういうことをやってはいけないんだ」とコメントしていました。
 私は「僕たち」という表現が気になって、じゃ誰が「僕たち」の対岸にいるのか? 多分それは複数形でM.マルケス以外に誰を指すのか? ロッシでしょう。
 遡ること7年前のストーナーとの事件、その後もチームメイトだったロレンソとのもてぎでのラフプレー等々、今マルケス「だって前を走るやつが遅いんだもん」と見本にしていると言われても仕方ないのがかつてのロッシでした。
 
 ストーナーが引退時、「チャンピオンに対して敬意を表さない世界が嫌になった」と言ってましたが、今思えば、それはマナーもスポーツマンシップもない(と映った)ロッシを指していたと私は思います。 
 M.マルケスにしても、最高峰に上がって彼なりのラフライディングが批判されだした時、「ロッシなら良くて僕ならダメなのか?」みたいなコメント報道が記憶に残っています。

 それがコークスクリューでマルケスが前年の恨みを晴らしたあたりから流れが変わりだし、今ではロッシがM.マルケスのプレーに苦虫を噛み潰す表情を浮かべるようになったのも時代の流れを感じます。 この推移をロレンソやらストーナー、遡ればビアッジなんかがどう感じているのか非常に興味があります。
 
 でもね。
 ここに挙げた元祖肉弾ライディングと後継の二人、世界的にmotoGPファンを二分するといってもいいくらいの人気を誇っているのは事実です。
 つまりは危険な勇者が愛される、と。

 わからないでもありません。 
 私がF1に完全に興味をなくしたのはブロックの連続で、追い越す時は必ずクラッシュ絡み的な展開にうんざりしたからですからね。
 ペドロサやロレンソ(これもmoto2時代は荒っぽかったけど)のような古武士的スタイルが受ける日本が世界的には少数派で、それを考えると、モータースポーツはやはり狩猟民族的格闘技なのかな、と思ったりもする秋の夜長でした。

 そして来季はこの古武士と無法者がレプソルホンダでチームメイトになるという...

| | コメント (0)

motoGP、祝福できないチャンピオン

 これを書き出した時点でまだもてぎの録画を見てないんだけど、夕方にホンダから来たマルケスが今年のチャンピオンを獲ったというメールを見て、そうなるとはわかっていたとはいえ、正直うんざりして録画を見る気がなくなりました。
 ※その後、早回しで再生、ラストでドヴィが自滅したのを見て停止、消去。 ゴール後のマルケス&陣営の馬鹿騒ぎも見たくない。 二度見する気なし。 ただしおめでとう>クラッチロウ

 世界中で93を応援するファンの多さが46に次いで多いのは知っているけど、彼のあの傍若無人な、暴力的、時に文字通り殺人的なライティングスタイルが好きになれません。 てなことは4月にも書いてるんだけど、相変わらずの殺人ライディングが続いているのでまた書きます。
 
 順位を上げるためなら他を走るライダーにコース上でぶち当たって押し出し、時には転倒させることさえ厭わないスタイル、あれです。
 グリッド上でエンストしてもオフィシャルの指示を無視する非常識さと、それを許す関係者さの甘さ。 他のライダーにすれば「あれをやってもいいなら俺もチャンピオン取れるよな」というのが本音でしょう。

 今年限りで引退するペドロサにしても数年前、アラゴンでM.マルケスにぶち当てられてリアアクスルの配線をぶち切られなければ一度くらいは年間チャンピオンを取れていたかもしれません。
 
 レース前半は他人を蹴落しながらポイントを稼ぎまくり、ある程度チャンピオン獲得の見通しが立ったら突然おとなしい走りに切り替えて確実にポイントを守るスタイルも気持ち悪い。
 肉弾戦が好きならプロレスとかアメフトとかに行けばいいのに。 こけない曲芸が好きならサーカスに行けばいい。
 
 今頃はマルケスファンが二日酔いで喜びの余韻にまだ浸っているんだろうけど、全てのmotoGPファンが喜んでいるわけじゃない、ということで。

| | コメント (0)

どうやって遠隔地のモニター画面を見るか(4)

 最後に残った作業のうちの一つ、液晶モニターの無駄な点灯を防ぐ対策。
 文字通り、モニターの常時点灯を避けることで液晶の焼き付き、バックライトの劣化を防ぐことが目的ですが、同時にカメラの焼きつきを防ぐことも含んでいます。 カメラとモニターのセッティングが終わったプラスチックの箱を黒いカバーで囲ったのもその対策の一つ(撮像管への刺激を最小限に留める)。
 
 最初はモニターについている電源スイッチをいじろうとしたものの、あまりに小さくて入り組んでいるので、単純に電源を供給しているUSBケーブルを加工することに決定。
 USBですから、また5V、リレー制御です。 最初に制作した基盤にノコギリで軽く切れ目を入れ、あとは手で折って元気な個体を流用。
Remote6

 USBケーブルの一番外側の被覆を慎重に割くと、中には赤、黒、青、白とカラフルな線が四本。 そっか、実際には電源だけしか流れてないけど、配線はフルに来てるのか。
 でもどれを切るの? 常識的に+は赤だよな、ネットで見てもどうやら赤で間違いなさそう、とニッパーでプツン。 気分はジャガーノート。 
 これらを慎重に半田付けし、コイル側をGPIOに接続してテストすると、あっさり成功。 MJPG-Streamerとwebiopiの組み合わせでも確実にモニターをオンオフできるのを確認。

 ただし、一個増えたリレーのおかげで100均ケースの中が狭くなり、ショートに気を使わなくてはならなくなりました。 次回同じものを作ることがあれば、リレーが7個ずらりと並ぶ基盤を用意したほうがいいのかもしれません。
 消費電流については、実際に同時にリレーが働くのは最大で2個という設計ですから、ラズパイの電力不足はまず問題ないと踏んでいます。
Remote7

 ただこれ、消し忘れると意味がないので、時間経過により自動オフにする仕組みが必要になります。 最も簡単なのは既製品を利用することですが、ラズパイがあるのになんかそれも間抜けな気がして、さてwebiopiでやるのかpythonか、ほんとはphpでやりたいんだけどなぁ、とか思案中。

 さぁ、あと一息です。

| | コメント (0)

シチューオンライスというのを見つけた

 行きつけのイオンは毎週火曜がセール日で、定番として玉ねぎ、じゃがいも、人参などの、大凡カレーに最適な野菜が安くなります。 品質も人参がすぐしょぼしょぼになること以外はそこそこで、この日にカレーなどの例えばシチュー、ハヤシライス、肉じゃが、ポトフやポテサラの野菜を仕入れます。

 とはいえ、これもパターンになってしまうとなんとなく飽きてくるというもので、なんかないかなぁ、と悩みつつ売り場を歩いていたら、ありました!ハウス製「シチューオンライス」なるものが。
Stewonrice

 要は、シチューなんだけど、カレー的にご飯にかけることを前提に作ってあるということで、ちょうどご飯を多めに炊いていたところなので、思わず飛びつきました。
 これは豚肉に最適化されたカレー風味なんだそうで、他に牛肉最適化、鶏肉最適化のパッケージも並んでいました。 いや、昨今牛は高いので、今日は豚用で。

 作り方はどちらかというとハッシュドビーフに似ていて、最後に牛乳を300cc加えますから見た目はクリームシチュー的です。 が、味は確かにカレー風味、ご飯に合う。
 豚肉ということでニンニクを加えましたから、ビタミンB1の摂取も万全。
 翌朝には全量完食、昼には残りませんでした。

 うん、次は牛版、鶏版もぜひ試してみよう。

| | コメント (0)

どうやって遠隔地のモニター画面を見るか(3)

 とりあえずラズパイ直結カメラで3.5インチモニターを写すことは成功したけど、ケースへの固定をしなくてはなりません。
 カメラの方は両面テープ、それもカメラ裏に飛び出した1mmほどのビスの頭を避けるために、少し厚みのある両面テープを使用。 でもこれって熱とかでポロっと外れそうなので、細いタッピングネジ二本で補強。

 モニターは本来ラズパイの上面に直挿しするような設計で、周辺に取り付け用ステーなどはありません。 よってドアの隙間を防ぐためのスポンジテープで少し柔らかめに固定することに。 左右からと、上部から支えます。
Remote3

 カメラとモニターの距離は、最初の実験ではとりあえず映ったのの、遠くて正直判読しづらく、現実的な操作は難しいと感じました。
 対策として、まずラズパイ側のMJPG-Streamerが用意する視聴ページのスタイルシートをいじり、本来撮影している640×480をドットバイドットで表示されるように変更。
 これを試しに800×600とか1280×960にもしてみましたが、ローカル環境でも明らかに遅延が大きくなり、グローバル環境ではまず役に立たないと諦めました。

 さらに実際に設定で見たい部分は画面の3/4位であることに気づき、ならば、とモニターとカメラの距離を徐々に近づけ、設定画面がぎりぎり映るように変更。 同時にカメラのピントも手動で調整。
 モニターとカメラの位置が決まれば、あとはできるだけ外部の光に影響されないように黒いカバーをかけ(実は毛筆習字用の下敷き)、下記のように、web上の640×480動画でメニューの文字がなんとか操作可能までに読めるようになりました。
Remote5

 例のリモートUSBエミュレーターも、ポインター移動速度の調整をやり直し、カメラ画像を見ながら監視カメラユニットを操作できることを確認。
 
 残る仕事は一つのページに画面と操作ボタンを収納するコーディングと、無駄なモニター点灯を防ぐタイマー的ハードの考案の二つとなりました。
 もっとも、インターネット経由で使ったらレスポンスとか問題出るのでしょうが...
Remote4


| | コメント (0)

どうやって遠隔地のモニター画面を見るか(2)

 ラズパイには、MIPI CSI-2と言う基盤直結のカメラ端子が用意されていて、これがどの記事を見てもUSBカメラより画像も速度も優れている、と高評価です。 理想はこの端子に接続できるビデオコンバーターがあれば良いのですが、マイナーマシンですから、そこに不満を言っても仕方ありません。

 ならば、と考えたのが一旦超小型モニターに画面を映し、それをラズパイ直結カメラで撮影&モニターする、というアイデア。
 幸い、ラズパイの大きさに合わせ、3.5インチモニターというのが複数用意されていて、その中にはHDMI接続モニター機能を持ったものもあり、これを監視カメラユニットに接続することに決定。
 一方のラズパイ側のカメラは、一般的な固定焦点では近い側のピントが辛かろう、と探して見ると、マクロ撮影も可能な可変焦点タイプを発見。 それもそれほど高くないのがありがたい。

 これらをお互い稼働させ、モニターが目一杯映るところを探すとお互いの距離は約20cm。 実際の設置を考えると、この二者をきっちりと固定し、守るケースが必要となりますので、これは100均で確保。 見た目は写真の通り。
Remoto1

 
 とりあえずこの状態でテストすると、ビデオコンバートよりずっと綺麗に映るのに一安心。 さらにそれを見ながら、ラズパイのGPIO設定画面からマウスエミュレーションをテストすると、とりあえず上下左右、左右クリック共にカーソルが動くのを視認。
 このスクリーンショットは同ネット上の別Macからhttp経由で見たもので、モニターにはまた保護フィルムが貼られたままの状態ですから、今はもう少し鮮明になっています。
 
 いろいろハードの調整も必要ですし、本来は操作ボタンと画面を一つのwebページに表示させなくてはならないのでまだ時間がかかります。
Remoto2

| | コメント (0)

どうやって遠隔地のモニター画面を見るか(1)

 紆余曲折はあったものの、ラズパイからネット越しにUSBマウスをエミュレーションすることには成功しました。
 すると次は向こう側の画面をどうやって見るかに作業が移ります。

 もしかすると「それってラズパイじゃなく、Windowsならもっと簡単にできるんじゃない?」と思っている方もいるかもしれませんので、一応説明しておきます。
 
 理屈的にはその指摘は正しくて、ホストマシンをスティックPCとすることを前提に、Windows専用のドライバーを用いることで、二台のマシン間を自由に行き来できるUSBケーブルという素晴らしいパーツが用意されており、実験してみたところ、完璧に作動しました。
 まどろっこしいリモコンではなく、普通のマウス操作が可能ですから、操作感も最高で、また親側さえWindowsであれば、リモート側のOSはなんでも良い(今回は監視カメラユニット。OSは組み込みLinux)という度量の広さを提供してくれます。
 うん、これは良い。

 次は画面モニター。 これはビデオコンバーターを想定。 とはいえ、数万円もする本格的なものは予算的に無理ですから、2〜3千円程度のUSBスティックタイプから選択。
 監視カメラユニットからはHDMIとVGAの二系統出力がありますが、VGAから最終的にUSBに映像信号を持ってくるものは上記予算では見当たらず(USB→VGAならいくらでもあります)、HDMIから直接USBに変換するものと、HDMIから一旦NTSCにする箱と、それをUSB映像にキャプチャーするパーツの組み合わせをテスト。
 結果は、前者は付属のドライバーをインストールしても全く役に立たず、発熱だけが恐ろしいほど凄くて、即ジャンク箱落ち。

 後者は国産メーカーらしく、ちゃんとキャプチャーできるものの、NTSCゆえに画像はかなり甘い。 これでメニューの操作ができるだろうか?と不安を抱きつつ、とりあえず他マシンからVNC経由で接続すると、表示ウィンドウに「何も接続されていません」とのブルー画面。 え?そんなあほな、と本体を確認するとちゃんと映っています。
 どうやらWindowsの画面描画システムとキャプチャーソフト、VNCの相性が良くないみたいです。

 どちらにせよ、所詮はビデオキャプチャー、期待通りリモートで見れたとしても画像クオリティは低く、細かいメニュー操作の確認は難しそうなので、このアイデアをこれ以上追いかけるのはやめ、ゆえにラズパイ直結のカメラでなんとかしよう、と考えたわけです。
 
(つづく)

| | コメント (0)

フォトトライアック、ギブアップ

 ラズパイのGPIOからUSBマウスのエミュレーションをする話、フォトトライアックを非ゼロクロスタイプに変更して完成のはずでした。

 が、私の人生、そんなにうまく行くはずがない。
 20×80の基盤に部品を組み込むのもだんだん慣れてきて、白だったTOSHIBAのトライアックから黒いSHARP製を並べて配線。 で、テスト。 理論的には絶対に間違いないはず。
 
 あれ?あれあれあれ?
 ゼロクロス時代と変わりありません。
 しばらく考え込むも、原因不明。 ふとブレッドボードに手を伸ばし、予備のフォトトライアックで3.3VのLEDをテスト。 ちゃんとGPIOからON/OFFできています。 ふむ。
 次、5Vでやってみると... LEDがかなり明るくなると同時に、今度はOFFができなくなりました。 あ、USBエミュレーターの引きずりの症状と同じです。
 つまり、原因は不明ながら、新たに用意したフォトトライアックは、3.3Vはコントロールできるのに、5Vでは電流切断不可だという結論に達しました。

 う〜、なんとか制御される側の電圧を3.3Vに降圧できんもんだろうか、とあれこれ調べ、手持ちのパーツで実験できる方法として、同じ値の抵抗を三つ使って落とす方法を試してみました。
 すると、LEDではちゃんと切れるようになったものの、本来の回路ではUSBエミュレーターが動きません。 こっちはこっちで3.3Vでは不満なようで。

 あ゛い゛う゛え゛お゛〜〜〜〜
 万策尽きました。
 
 が、諦めるわけにはゆきません。
 結局、一個一個元気に動くリレーを確認し、当初のメカニカルリレー案に戻ることに。 なんのこっちゃら。

 最初に組んだ基盤のうち、元気のなかったリレーは二個、ところが彼らは端子が六本で、半田吸い取り糸で吸い取ったくらいでは基盤から離れてくれません。 結局新たにチェック済みのリレー六個を並べて新たな基盤を作り直すことに。
 はんだごてを握りながら、この数日の工作はなんだったんだろうと思いつつ、全く新しい分野のこと、良い勉強になったと、割と素直に意外なほどイライラすることもなく最後の基盤が完成。
 
 試運転すると、おっと、今度はちゃんと期待通り動いてくれました。 ラズパイで全く別のシステムを操作できます。 やれやれ...
 まぁいい、結果良ければ全て良し。 もたもたせずに次のステップに進まなくては。
 
 ちなみに下の写真、右から順にリレー初号機、リレー完成機、ゼロクロスフォトトライアック壱号機、非ゼロクロス弐号機。
Relaies

| | コメント (0)

ゼロクロスの罠

Phototri

 なんかアニメのタイトルみたいですが。
 機械式リレーだとラズパイのGPIOポートから制御するのが不安定、の解決策。 正直なところ、まぁこれで一件落着だろうと慢心しておりました。
 
 その解決策というのは、フォトトライアックという、一言で言うと、光で電流の流れをON/OFFする、一種の無接点リレーです。 正直言って、私の古い電子(いや、電気かな?)の知識では未知の部品です。(上の写真では左側の基盤に並んでいる方)

 きっかけは、リモートチャイムを作った時に使用した、秋月電子オリジナルの無接点リレーでした。 このキット、放熱に配慮すればAC100Vの25A、つまり2500Wまで切断できる優れもので、私のような単なるチャイムのスイッチオンオフには完全なオーバークオリティ。
 ま、それはともかく、この説明書をよく読むと、最終段のトライアックをコントロールするのにフォトトライアックというさらにもう一個のトライアックが組み合わされているのに気がつきました。 ?と思って、この品番を秋月のページで検索し、さらにそこから製造元である東芝が発行するPDFの資料を辿ると、なるほど、フォトトライアックというのはそれだけでも電流の断続ができるものの、電流的には十数mAが限界で、普通はそれを大容量トライアックのスイッチとして二段階制御する、ということです。
 ん?十数mA? いや、それでもリモートUSBユニットへの信号線としては十分な容量じゃない? というのが前回でのひらめき。

 価格も一個70円ほどで、早速深夜バイト明けに眠気も忘れて組み上げ。 部品的には抵抗がそれぞれのトライアック分必要となるので、6個増えたものの、こちらも徐々に半田付けというか、基盤配線に慣れて来たので、想像するほど面倒ではありませんでした。
 おっと、今回はこれにあわせてブレッドボードも購入し、基盤に組み付ける前にラズパイとフォトトライアックを組み合わせ、試験的にLEDを繋いで動作テスト。 →問題なし。 う〜む、昨年末までLEDの工作方法さえ知らなかったのを思えば、なんて進歩。 ふっ、俺も強くなったものよ...
 
Bboard

 さて自信満々、基盤上の配線チェックも終わり、またまた例の中華カメラシステムでテスト。 ラズパイ上のpythonで、上下左右+左右クリックを順に動かすスクリプトを動かすと。
 「上」うんうん、順調。
 「下」うんうん、これも順調。 当ったり前だぁ、完璧だぁ。
 「左」... あれ?変。 以後、全滅。
 なんか、一旦入ったスイッチが切れずにずっと後を引いてるみたい。 ロックリレー組んだ覚えないんだけど?
 
 実はここから丸一日原因追求に費やしましたが、それは省略。 いえ、今回も結構徹底的にやりました。
 で、結論として、組み込んだフォトトライアックが「ゼロクロス制御」だったことが原因と判明。 いえ、それって説明書にもPDFにもしつこく出ていたんですけどね。 うごごご、無知って恥ずかしい。
 
 交流はご存知のように常に電圧が変動していますから、これを断続する時にたまたま最高電圧だと、無接点であっても大きな電気的ノイズが発生するそうです。 それを防ぐため、電圧ゼロ時にのみ断続するのがゼロクロス制御だそうで、これが一個70円そこらのチップに入っているんだからすごい。
 
 が、今私が求めているのは直流の制御。 つまり、切断するべき回路の電圧がゼロになることはなく、だから一度入った制御がずっと切れずに尾を引いたわけです。
 ほんにド素人の極みながら、わかってしまえばこちらのもの。 「非ゼロクロス制御タイプ」というフォトトライアックもあるのも確認したので、またまた秋月に注文。
 いや、電子部品は個々の価格が安いので(非ゼロクロス制御フォトトライアックはなんと、4個で100円! 330Ωの抵抗なんて100個で100円!)、こういう試作時に助かります。 車の12V DCの場合は何かと高くついたっけ。
 
 で、多分、次回はこの制御の項目、終ります。 の筈...

| | コメント (3)

魚の煮汁に酸味を加える

Nizakana

 ラズパイネタは部品待ちのため置いといて、突然の料理ネタ。
 半月ほど前、サンマの煮物レシピで煮汁に酢を加える、とありました。
 煮魚の煮汁といえば、砂糖、酒、みりん、醤油、そして生姜を加えるというのが定番で、そこに酢?とは思いつつ、その通りにして見たら、なるほど味の輪郭が立つというか、キリッとした味になりました。 でも量を間違えると怖いなぁ、とも。

 そして先日、綺麗なからすがれいがあったので、久々に煮るべ、と購入。 そこでふと思い出したのが、サンマ煮に加えた酢のこと。
 同時に、焼きサンマには大きすぎるだろうこれ、という貰い物のスダチが冷蔵庫にあるのを思い出し、これを酢の代わりの酸味にして見たらどうだろう、と考えついたので、スクイーザーでぎゅうぎゅう絞って鍋の中に。 サイズがサイズなのでそこそこの量になって、う〜ん、酸味が勝ってしまったらどうしよう、と思いつつ適当に煮詰めて出来上がり。

 恐る恐る端の方を摘んで食べて見たら、おお、なんともいえない高級めいたお味。
 普段の煮汁がどちらかというと甘みが強い、どろっとした捉えどころのない味なのに対して、前回のサンマと同じく、味がキリッと立っています。
 とはいえ、例によって食事中に会話のない家ですので、特に賛美の声もあがらず。 でも非難の声もなし。 いや、悪くないと思うよ、この酸味。
 
 でもやっぱり量が怖いと感じるのは相変わらずで、スダチもこれ以上入れてたら「なにこれ?」って感じになっていたと思います。
 まぁ、また機会があったら挑戦してみるとします。

| | コメント (0)

GPIOポートの難しさ

Ras5

 と、ここまで来て進展が止まっています。
 ラズパイから最初に繋がっている毛むくじゃらボードは、先日に完成していたリレーボード 。 裏に3Vリレーが6個並んでいます。
 その先に接続されているのが、ビットトレードワンというところから出ているREVIVE USBというユニットで、これを使ってUSBマウスをエミュレートします。
 
 試しに例の中華監視カメラの本体につないでみましたが、左/右クリック、上下は問題ないものの、なぜか左右に動きません。
 二日ほどかけてあれこれし、それこそ徹底的に調べたんだけど、どうやらリレーの個体差が原因だとわかって来ました。
 決して不良品というわけではなく、同じGPIOの3.3V端子から直結すると元気に動きます。 が、ソフトウエア制御の端子からだとうまくオンにならない、というかなんか小さい音がしている時もあるので、コイルの力が弱いとか、メカ部分の抵抗が大きいとかの微妙な個体差だという結論です。
 
 テスターで測るとちゃんと3.3V来ているのに、と悩みつつ、ラズパイでLEDを光らせるという記事の中で、「1つのGPIOにつき電流量が16mAまで」という項目を見かけ、あわてて秋月電子が提供している技術情報を確認。
 すると、使用している3Vリレーのコイルは50mAも消費していることが判明。 つまりこれだけで16mAという限界を大幅に超えている、つまりコイルへの供給電流が不足し、それでも個体の中で頑張る子だけが健気に接点の切断を実現していたという事実が判明しました。
 
 かといって、負荷の低いリードリレーの3Vコンシューマー版は例がなく、先日のリモートチャイムの時に使った無接点リレーを六つ並べると、コスト増加に加えて基盤面積が大きくなるという閉塞状態。
 とはいえ開発をやめるわけにもいかず、とりあえずは多めにリレーを購入し、その中から元気な子を探し出すしかないなぁ、という結論に達しました。
 が、これを推し進めることは、一時的とはいえラズパイに大きな電気ダメージを強いることでは?と不安になって来ます。
 
 しかし、さらにうじうじとあれこれ粘って調べていたら、その無接点リレー(ソリッドステートリレー)の資料におや?と。 うん、これはコスト的にも場所的にも一挙解決の福音かもしれないヒントを見つけました。 ただ、私の知識と経験が圧倒的に不足しているので実験するしかありません。
 と、現在またまた秋月電子に注文中... 結果が出るのは来週かと。

| | コメント (0)

ラズパイのWebIOPiメニューにアクセスできない時

Ras4 先の発言で触れた 、私が見つけた良き参考書というのは、「ラズベリーパイで遊ぼう! 改訂第2版 林 和孝 (著) 」です。
 愛するジュンク堂に何冊か並んでいるうちから選んだのですが、今回、自分が何をしたいかがはっきりしていたので、比較的楽に選別できました。 オススメです。
 
 ただし、WebIOPiに関する記述、7-1「WebIOPiを活用してみよう」を進めてゆくうち、P233の「ブラウザでWebIOPiにアクセスしてみよう」で躓きました。
 外部からアクセスすると、ユーザーネームとパスワードは聞いてくるのでWebIOPiのサーバー機能はちゃんと働いているにもかかわらず、ログイン直後に(例えばSafariなら)「切断されました」とメッセージが出てメイン画面にたどり着けません。 Chromeでも一緒。
 これは必要なパッチが変更されたことが原因で、同じくP233に記載されている出版社情報ページで著者自らが新しいパッチ情報をあげておられます。

 ただし、一旦失敗してしまった後にこの新パッチを当ててもダメで、WebIOPiを新たにインストールし直してから新パッチを当てないと解決しませんでした。 また、考えすぎてパッケージのアンインストールとかするのではなく、単に上書きインストールで大丈夫なようです。

| | コメント (0)

ラズパイのGPIOにリレーを繋ぐ

Ras3

 そんなわけで、ラズパイのGPIOポートから外部のUSBマウスエミュレータ基盤を動かすためのリレーをかました図がこれ。
 細長い基盤の裏には3Vリレーが6個並んでいます。 なぜ6個かというと、左クリック、右クリック、ポインタの上下左右をコントロールするため。
 これはとりあえず動作試験の状態で、このあと省略できるマイナス線(GND)をとっぱらたりして、今はもう少しすっきりしています。
 
 制御は、webIOPiというフレームワークを組み込み、そのライブラリをjavaScriptを使ってwebページから行う、という、このあたりの流れがわかっている人には割と簡単な仕組みが用意されています。 つまりhtmlやらcss、jsの知識も必要でもある、ということ。

 写真の状態ではすでにそのチェックが終わっており、http経由でMacのwebブラウザから特定のリレーをON/OFFし、カチカチというリレーの動作音がすることを確認しています。 いや〜、なんだか訳もなく楽しい。
 ここまで来たらエミュレーターとの回路図を考え、配線を済ませば試作機の完成となりますが、さてどうなりますやら。
 
 幸いにして、ラズパイの基本から今回自分がやりたいことまでの基本が全て掲載されている参考書に出会えたのでここまで比較的短時間で来れましたが、この本については次の発言で。

| | コメント (0)

HighSierraの復元もクソな件

 RS232C端子を失ったPCですら面倒になったとは書きましたが、それでもIC書き換えるだの、セットアップされたボードの設定値を変えるだのになるとやっぱりMacではなくPCなわけです。
 でも時代はありがたいもので、Macを持っていれば慌てず騒がずBOOTCAMPでWindowsも動きます。 まぁ、そういう基盤系メーカーから言わすと、BOOTCAMP上での動作は保証しておりません、となるわけだけど、そんな微妙なコントロールをしているのは大概他で何かのトラブルを起こしがちなので、むしろその炙り出しに好都合という意見もあります。
 
 さて、我が環境ではすでにもともとMicrosoftのフライトシミュレーター用だったiMacと、今こうして文章を書いているMacBook Proとの両方にWindows7が入っていました。 ところがApple純正のXcodeという開発ツールがバージョンアップのたびに我が物顔にサイズを肥大させ、(今見るとアプリだけで11GB。他にもライブラリ多数)おかげでSSDの容量確保のためにMacBook Pro.からWindows7は削除されてしまいました。
 ゆえに、再度MacBook ProにWindowsを入れる為には、内蔵SSDの換装が必須。
 
 Macの世界ではずっと昔からこの内臓記憶丸ごとコピーというのが楽で、ディスクユーティリティという純正ツールを用います。 ただし書き出し先は非常用ということでFirewire800(IEEE1394)接続の2.5inHDDですから、180GBほどの書き出しに三時間半ほどかかりました。
 すると最後の最後にエラー表示が。 いや、「失敗しましたてんてんてん」じゃないだろう。
 
Restore

 六年前にも一見同様のエラーに見舞われたことがありますが、どうも今度は様子が違う。 もしかして単純なメディアのエラーかもしれないと再度三時間半ほどかけてやってみてもまた同じ。
 そしてエラーメッセージの"APSF inverter failed to invert the volume - Invalid argument"を検索してみると、どうやらこの半ば騙されたようにアップデートされたようなクソHigh Sierra で新たに採用されたAPFSディスクフォーマットが絡んでいることが判明。 いや、これ純正ユーティリティなんだけど?>Apple
 
 とまぁ、文句を言っても直してくれるわけもなし、あるいは「Mojaveなら治ってます」とか言い出しそうなので当てにはできない。 しかたないのでさらに探すと、C.C.C.? なんか懐かしい名前が出てきた。
 それはCarbon Copy Clonerというコピーツール 。 かなり以前から存在するものの、純正ディスクユーティリティがあったり、Time Machineという定期バックアップツールが加わったりして、存在感がどんどん薄れて言った記憶のある有料ユーティリティです。
 4,700円かぁ、とため息を付いていたら、おや、30日間は無償お試し期間があるという。
 あぁ、いいなぁ、こういうの。 とりあえず切羽詰まった状況では非常に助かるし、もしうまく行ったら、次回同様のトラブル時には買ってしまうかもしれない。
 
 ということで、早速ダウンロードしてコピー開始。 速度はなぜか一時間ほど速く、二時間強。
 うん、とりあえずバックアップ完了。 次はMacBook Proを裏返し→開腹→内蔵SSD交換、終わったら今度は書き戻し。
 また二時間強かかったけど、あら、問題なく終了。 素晴らしいじゃないか>C.C.C.
 
 あ、APFSの名誉のために付け加えますと、このフォーマットに問題があるわけではありません。 むしろSSDに最適化された新しい考え方です。 問題はそれを純正アプリケーションに実装できないAppleのプログラマー。
 何もしてないのに定期的に「問題が起きたので新規バックアップを取ってください」と直ぐに音をあげるTime Machineも今ひとつ信用できないし、このCarbon Copy Clonerというのにもっと頼ってもいいかもしれない。

Ccc

| | コメント (0)

« 2018年9月 | トップページ | 2018年11月 »