2018年10月31日 (水)

JJY電波を見るため、RF(高周波)の世界に踏み込む

 当研究所で最後まで残った未踏のフロンティアはRF(高周波)である。実はRFには思い入れがあって、何となくこれまで避けていたのだが、ひょんなきっかけでどっぷり踏み込むことになった。

 前にも少し触れたと思うが、所長は60年以上昔の中学生の頃、アマチュア無線に熱中していた。電話級が出来る前の2アマの国家試験は一次が合格し、二次は修学旅行と重なったため(試験は受け直せても修学旅行は一度きり)受けずにそのままになっている(当時は一次試験合格有効期間が10年あった)。

 修学旅行で秋葉原に行き、ガード下の真空管屋さんで、807と5U4G(パワー出力管と整流管)を買い込み、後生大事に持ち帰った記憶がよみがえる。結局、電源トランスが高くて買えなくて、送信機を自作するところまで行かなかった。

 その代わり、6ZP1(いや懐かしい)という一般ラジオ用の出力管で、近くの悪友と勝手に電波を飛ばし遊んでいた(豆電球にループ線をつけ、出力コイルにかざすとマイクの音に合わせて明滅し楽しかった)。そんな今になっては時効になった様々な思い出がある。

 そのうち受験勉強が忙しくなって、結局、無線免許はとりそびれた。そんなトラウマがあるのか、電子工作を始めてもこの世界はあえて封印していたのだが、JJYの電波時計リピーターを開発しているうち、遂に、RFの世界に再び入り込む誘惑に耐え切れなくなってしまった。どんな状況になったか。詳しくは以下の作業記録で。Dsc01506

スペアナが欲しいが高い(10/1/2018)
  そもそもは、JJYの標準電波がどの程度、この研究所に来ているかを調べたかったのがきっかけである。軽い気持ちで作ったJJYリピーターは十分な出力があるはずなのに少し離れるとノイズっぽくなって受信が出来なくなる。このままではリピーターをかなり時計に近づける必要があり実用性が低い。

 受信出来なくなるのは、本家のJJY電波(40khz)と干渉しているからだと思われるが、本当に干渉しているかは単なる推測で確かめたわけではない。リピーターを60khzにすれば解決するのかも知れないが、そうなると受信側も対応が必要で面倒だ。

 こういうことを検証するには、何と言ってもスペクトルアナライザーが一番である。来ている電波を適当なアンテナなどで受けてスペアナで調べれば一発で解決する。しかし、スペアナは、オシロに比べると中華の安値革命がまだ起きていないと見えて、どれも高価である。いくら安くても10万円近くはする。

 参考書などを手に入れて、少しまともに調べ始めたのだが、長波帯までカバーするスペアナはやはり本格的なものでなくては無理で、そういうスペアナは50万円以上する。PCにUSB接続するハンディなものでも100万近くするのはざらで、とても手が出せるものではない。

 どうしたものかと考えていたら、そのうちウェブ上で恰好のものが見つかった。サウンドカードのアナログ入力を利用したPCで動くソフトウエアのスペアナである。実際に動かして、JJYの電波をとらえている記事も複数見つかった。

 Spectrum Labというのが定番のようだ。主な測定対象はオーディオ帯域のようだが、最近のサウンドカードはスーパーオーディオCD(SACD)の普及で、長波帯(40Khz)くらいは軽くカバーしているようだ。当研究所のメインPCのサウンドカードも48khzサンプリングで、何とか聞こえるのではないか。

Spectrorum LabでPCサウンドカードのスペアナを狙うも失敗(10/2/2018)
 早速、このPCのフリーのスペアナソフトSpectrum Labを使わせてもらうことにする。ドイツのアマ無線家(DL4YHF)の開発で、凝りに凝った機能がてんこもりである。いかにもドイツ人らしい緻密な構成だ。アマ無線家御用達のようで、多種多様な使い方の紹介があり、何から始めて良いのか全く見当がつかない。ただ、わずかだが日本語の解説ページがある。

 しかし、日本語でも専門用語が多く理解するのにひと苦労だ。幸い、このソフトでJJYを受信しているサイトがあったので、それを頼りに導入を進めた。ダウンロードは順調に終わり、動作させると画面上に一定の範囲の周波数帯域の受信スペクトルが出始めた。

 全体の電波の受信スペクトルが時系列で画面上を滝のように流れて行く(WaterFallと呼ばれる)。素晴らしい。しかし設定が難しくて、JJY電波の40khzあたりの受信帯域になかなかならず、エラーになることが多い。

 しかも、やっとのことで帯域の設定が出来ても、肝腎の電波が出てこない。念のため、埃を払って自作のSG(シグナルジェネレーター)を持ち出して、その出力をアナログ入力につなぐと20khz以上では出力が消える。Ws000010

 そのうち大変なことに気が付いた。現在のメインPCのサウンドカードは、古い、ゲームポートがまだついている48khzのCreativeのサウンドカードである。48khzサンプリングで見える周波数はその半分の24Khzであることに今更のように気が付いた(シャノンの定理)。

 道理でSpcetrum Labの画面では、24khz以上のホワイトノイズが綺麗に下がっているわけだ。やれやれ、ハードウエアがサポートしていないので、40khzの受信は、この手持ちのサウンドカードでは無理なのである。暫し呆然とする。

サウンドカードを新調するもこれも受信せず(10/7/2018)
 こういうところで簡単にやめてしまわないところが所長の取柄である。漱石の「坊ちゃん」ではないが、若いころから、これで苦労している。負けず嫌いとも言うが、この年になってこの性格が自分にとって良かったかどうか長期的に判断すれば、どうみても赤字決算だ。

 決して褒められる性格ではない。しかし精神衛生上は、間違いなくこちらの方がストレスは少ない。自分の気持ちに正直にこだわっている方が、色々なことを我慢して別の道にいやいや進むより、気分的にははるかに楽だからだ。

 ということで、懲りずにネットで最近のサウンドカードの動向を恐る恐るリサーチする。折角、ソフトを入れたのだから、サウンドカードそのものを取り替えてやろうという算段である。すると、96Khzや192Khzサンプリングのスーパーオーディオのサウンドカードが次々に見つかった。Ws000012

 価格も3000円程度であることがわかった。10万以上するスペアナのことを考えればただのような安さだ。喜び勇んでサウンドカードをウェブでポチッた。アマゾンで注文して3日で届いた。いそいそと、これまでのカードをはずして装填する。

 ところがどっこい、こいつがうまく行かない。帯域の設定は明らかに前のカードに比べれば楽になり、簡単に96Khzあたりに設定がエラーなしに出来るようになったが、受信しないのである。自作SGの出力をパスコン(0.1μF)経由で直接アナログ入力に接続しテストを進める。

 すると前のカード同様、24Khz以下では活発に波が出るのに、それ以上になると全くピークがでてこないことがわかった。その代わり、24khzより低い周波数を発生させていると、高調波の形で、派手に40Khz以上の波形が出始める。

 何ということだ。こいつもアナログ系はどうも24Khzを境にLPFをかけたように感度が極端に下がる。もしかすると本当に音声帯域のためのLPFが付いているのかもしれない。

ちゃんとLPFのカットオフ周波数は100Khzになっていた(10/10/2018)
 こうなると、もう止まらない。高額でないにしろ新しいカードを準備したのだ。このまま黙って引き下がるわけにはいかない。 

 サウンドカードをもういちどPCスロットからはずして、オーディオジャック近辺のプリント配線を、実体顕微鏡を使って調査する。もしかしたら、このアナログ部分にCRフィルターがかかっているのかもしれない。それなら、このLPFをバイパスしてやれば良い。

 プリント基板をいじろうという大それた目論見だが、乗り掛かった舟である。このあたりの表面実装部品は、1608程度の大きさなので、何とか手ハンダで修正が可能だと思う。

 20倍の実体顕微鏡で調べたところでは、確かに、オーディオジャックから音声チップに入る前に、それらしいアナログ回路がついている(写真の赤丸で囲ったところ)。Line もMicの入力もどれも、一段のRCフィルターがついているようだ。

 配線の済んだCRの定数は正しく測定することは出来ないはずだが、秋月の精密級LCRメーター(LE5000)は、2点間の合成LCRを出してくれるという触れ込みなので測ってみる。何かもっともらしいCR値が現れた。得た値をウェブの早見表ソフトに入れカットオフ周波数を調べる。Dsc01541

 測定できた定数は、LineもMicも違った値だったが、奇しくも2つともカットオフ周波数は100Khz近辺で、96khzサンプリングというスペックと符合する。ちゃんと通しているように見える。

 さてどうしよう。このCR部分が本当にLPFになっているかどうかの確証が得られないまま、このカードの配線をいじる勇気は生まれてこない。この方法は少し棚上げにするしかないか。

高周波増幅回路の横道に入る(10/12/2018)  
 ウェブには、電波時計の受信モジュールを使うのでなく、スクラッチからJJYの受信機を自作して受信に成功しておられる方の記事もいくつかある。その中には、FETを使った高周波リニアアンプの回路図も載っている。

 そうか、アナログ入力の前にアンプで増幅しておけば電波が見つかるかもしれない。アンプの回路はとても簡単である。しかも使用する高周波用のFETは、2SK241といって秋月でももう売っていない絶滅危惧種なのだそうだ。これは横道に入るのに十分な魅力的な話である。

 本来の目的に向かっているかどうかわからないが、急にアンプが作りたくなった。ウェブを探し回って、本来の定番2SK241(東芝製)の完全互換品、2SK439(日立製)が、あのAitendoで売っていることを発見し(¥120)、これだけのために、Aitendoに足を運んだ。

 高周波なので本当はハンダ付けで作るべきだろうが、とりあえずブレッドボードに配線を短くして組んでみる。回路はここを参考にさせていただいた。簡単な回路なのですぐ完成した。電源は、リチウム電池である。Dsc01508

 アンプそのものの増幅率は、SGで波を出し、オシロで入出力をモニターすれば実測可能だ。おお、これは簡単に測定できた。発振もしない。ただ中波帯(1Mhz以下)では増幅率は30倍近くあるが、1Mhzを超すと、どんどん増幅が頭打ちになる。

 まあ、中長波帯では数十倍あるので、早速、回路をサウンドカードの前段に接続しテストしてみる。残念。やはりこの程度の増幅では、リピーターの40khzも本来のJJYも受信不能であった。

さらに中華SDRドングルを買ってしまう(10/16/2018)
 八方塞がりである。何をやってもうまく動かない。しかし、ここまで無線に目覚めてしまったので、このまま引き下がるわけにはいかなくなった。あきらめきれず色々調べているうち、さらにJJYを受ける方法があることがわかった。ワンセグチューナーのドングルである。

 夢中になってウェブを探索する。これまで避けて通ってきた道なので、RFの世界は知らないことが多くて興味が尽きない。スペクトルアナライザーに関連したところでは、ワンセグのテレビを視聴できるUSBドングルが流行っているようだ。Dsc01507

 たったの20ドル近くで高性能のデジタルレシーバー(Software Digital Radio)が手に入る。本来は欧州仕様のTVワンセグチューナーのドングルだが、これも欧州のアマチュア無線家が開発したソフトを使うと、FM受信機や、航空無線の傍受用に早変わりし、VHFのスペアナにもなる。

 調べているうち、VHF帯だけでなく、長中波やHF(短波)も聞けるオールバンドラジオになることを知った。ふーむ、これならJJYもこれで聞けるかもしれない。

 このあいだのCNCマシン同様、同じような形をしたドングルが市場に出回っていて、やたらと種類が多い。代表的な、というよりオリジナルはRTL-SDRと呼ばれるドングルのようだ。色々調べた結果、ドングルではなくHF帯も受信できるソフトウエアラジオのセットを注文した。これもアマゾンで発注して3日で届いた。Ws000011

 アンテナを普段使っているTV/FM用の同軸ケーブルにつなぐと、FM放送などは簡単に受信が出来た。長波帯の受信を試みる。しかし、残念なことに、こいつも1000Khz以下は極端に感度が下がる。VHFは快調に受信するが、HF帯はまともなアンテナをつけなければ無理なようだ。

 スペック上は100khz以上ということで、受信方式はダイレクトサンプリングなので、少し感度が低いということをあとで知った。 

はてはHFコンバーターも発注(10/20/2018)
 もう際限がなくなってきた。前から秋月で気になっていた高周波用の同軸コネクター関連のパーツを手当たり次第にウェブでポチっている。まず、SMAコネクターまわりが気になって、ケーブルやコネクターを買い込む。Dsc01509

 安いので、知らずにリバースSMAのケーブルを買って、刺さらなくてあせって、あわてて変換プラグを注文したり、FケーブルからSMAの変換プラグ(厳密にはインピーダンスが合わないので国産にはない)を発注したり、はては、同軸ケーブルの圧着工具(安い中国製)まで注文したりして、もう錯乱状態である。

 そのうち、ダイレクトサンプリングではなく、スーパーヘテロダイン方式(だと思う)のHFコンバーターがアマゾンに出ているのを発見した。これなら長波帯までカバーしているので受信ができるかもしれない。

 完成品は少し高いが(¥6800)、キットでも頒布されていることがわかった(半額)。少し迷ったが、高周波基板の勉強のつもりでキットで手に入れることにした。日本の個人の方が開発されているというのも心強い。

 メールで申し込んだら、すぐ返事があり、お金を振り込むと3日も経たないうちに家に届いた。アマゾンに頼んだ諸々の部品や工具はまだ届いていないというのに、驚くべき速さだ。

 封筒を開けてみて、予想通りの細かい部品に、いささかたじろぎ、これまでのようにすぐ制作にとりかかる余裕が生まれてこない。そこで、このブログの記事を出した後、一度気分を落ち着かせてから着手することにする。

| | コメント (0) | トラックバック (0)

2018年10月 2日 (火)

ESP8266のJJY電波時計のスケッチ公開

 これまで作っていたESP8266を使ったJJY電波リピーターと電波時計受信機のうち、受信機の方が何とか安定して時刻を知らせるようになった。とりあえずこちらを先に、ソースコードと回路図を公開することにする。

 電波時計は長時間動かすものだから、本来はESP8266のような大喰いのWiFiモジュールで作るのは筋違いだが、WiFi環境が必要な電波リピーターにESP8266を使ったので、開発環境を共通にしたかったのと、気楽に始めたのにうまく動かず、止めるに止められなくなったせいでもある。

 前にも書いたが、JJYの受信パルスは1秒に一回の超低速通信(1bps)である。クロック80MHzのESP8266なら沢山のロジックを組み込んで、相当インテリジェントなエラー修正が出来ると意気込んで始めたのだが、これがとんでもなく難関で、ほんの少しでもノイズが出るような受信環境では全く正しくデコードができない。Dsc01493

 リピーターのコイルから数十センチも離すと、受信モジュールが正規の福島(おおたかどやま)からの電波も受け始めて干渉を起こすらしく、年月日などに目茶目茶な数字を出し始めて全く話にならない。出来ないとなると、むらむらと反抗心が出てきて何とかしてやろうと、いつもの悪い癖が出る。

 この3週間、半分泣きべそをかきながら、意地になってデバッグに熱中していた。その結果、何とか市販の電波時計程度の信頼性のある時計になったので、Arduinoのスケッチソースリストと、回路図を公開することにする。どれだけ迷走したか。詳しくはこれ以降の作業記録で。

やっぱり日本の女子は強い(9/9/2018)

 その前に、ちょっと電子工作とは違う話題を少し。プロテニスの話である。手が届きそうで届かなかったテニス4大大会(グランドスラム)の日本人の優勝は、天真爛漫なあの「大坂なおみ」があっさり全米で達成してしまった。

 4年前の錦織の全米準優勝も驚いたが、今度はもっとすごい。勝ち方が豪快である。彼女のことだったら、本当のグランドスラム(1年間に、全米、全豪、全仏、全英すべてに優勝)をやってのけるかもしれない。

 錦織のときにも同じことを書いたが、野球はアメリカと日本でしか騒がないのに対し、テニスは全世界が対象である。しかも、サッカーは庶民が中心だが、テニスはセレブのスポーツファンを巻き込む。ウィンブルドンの観客の平均年収は2000万円という話を聞いたこともある。世界に与える影響は、野球の比ではない。

 ちょっと気になるのが、彼女の出自の問題だ。今、世界は、水面下では色々あっても建前上は人種の区別をしないことに極度に神経質になっている。それなのに日本のマスコミが彼女の帰国会見で、実に無神経な質問をしたのには驚いた(あなたは何人?)。

 こういう話は、すぐに世界中にひろまる(マスコミの浅はかさは世界共通)。世界から日本が馬鹿にされるのは身から出た錆でしようがないけれど、大坂選手が日本に愛想をつかしてアメリカ国籍に換わってしまわないことを祈るばかりである。Dsc01485

I2C液晶を2台とも4本の結線だけで動かす(9/10/2018)
 電子工作の話に戻ろう。Aitendoで入手した2台のI2C液晶の始末である。このうち一台は電源を逆接してしまい、破損が心配されたが、幸運にも壊れていなかった。バックライト付きだから今のところACアダプターのついた電波時計に使う予定である。

 インターフェースはI2Cだが、液晶の本体は12本のピンが出ており、内部で使うコンデンサーや、I2C/SPIの識別をする制御線などの追加の配線が必要である。工作のついでに、2つの液晶がいつでも使えるようチップコンデンサーなどを使って整備しておくことにした。

 このままでは、ブレッドボードに配線を加える必要があり、特にひとつは動作テストを急いだため、ジャンパーコードやコンデンサーを空中でハンダ付けする完全なバラック状態になっている。なお、このコンデンサーは省略することが出来ない。はずすと簡単に動かなくなる。Dsc01494

 久しぶりに秋月にでかけ(このところはAitendoが多かった)、1μFのチップセラコンを入手した。相変わらず、ここはいつも賑わっている。帰って早速チップセラコン(2012)の空中配線を楽しむ。I2Cだけだとピンヘッダーは4 本ですむのだが、4本だとやや強度に不安が出る。

 課題が残った。液晶とバックライトの発光面との接着である。両面テープで貼るのは手軽で良いが、蛍光面にテープが見えて見栄えが悪い。それと時計の表示装置にするのならバックライトなしの液晶の方が消費電力が少なくて済む。また買いに行かなければ。

JJY電波リピーターのバグを解消した(9/14/2018)

 電波時計の前にやることが残っている。JJY電波リピーターの不具合である。リピーターはNTPから時刻を貰っているので正確無比のはずなのだが、長時間動かすと、何故か分単位で遅れることがある。

 NTPや、WiFiが原因であることは考えにくいので、すべてこちらが悪いのだが、原因が思い当たらない。NTPの正時(0秒)を待ってパルスシーケンスを始めるのだが、パルスシーケンスは59 秒間の最後がポジションマーカーパルスで0.2秒、この残りの0.8秒で次のNTP時刻が変わるのを待って同期させるロジックである。

 たとえ遅れたとしても、秒単位の遅れのはずなのにパルスシーケンスは、1分以上の時刻遅れを表示する。しかも、エラーは長時間のときにたまに発生するだけで、普通は全く問題ない。

 長時間(2時間以上)コンソールにメッセージを記録し続けてやっと原因がわかった。何と本来は59.2秒で終わるはずなのに、59秒より早く送り終えるところが見つかった。ロジックは59とか0などの絶対値ではなく、NTPで得た秒データの変化をトリガーにしている。

 このままだと59秒の時に、そのときの「分」データを得てそれを新しい時刻の「分」にするので結果として1分遅れることになる。なぜ早くなるのかの原因は全く見当がつかない。どうしようか。

 迷ったけれど、対症療法で、NTPの秒データが00になるまでべたに待つことにした。CPUは回りっぱなしで精神衛生上あまり愉快ではないが背に腹は代えられない。幸いなことにこの修正後は全く問題なく動いている。

焦電型人感センサーを更新(9/15/2018)
  さらに道草を食っている。階段の照明の入り切りに使っていた焦電型人感センサーが何となく感度が悪くなり、階段の前でパントマイムをやらされることが増えてきた(動きがあると反応する)。

 人感センサーについては、実は、一年前、秋月で偶然これを見つけて買ってある。以前、千石で買おうと思った赤外線センサーNapionの改良形のようだ、値段は半分以下の¥480だった。テストしただけで、部品箱に眠っている。Dsc01496

 階段の上での身振り手振りが、段々煩わしくなったきたので、これに更新することにした。久しぶりの汎用基板でのハンダ付けが楽しい。UEW線を持ち出さずに、すべてのパーツのリード線を活用し配線する。

 作り替えたのはセンサー部だけで、電源の入り切りなどの制御ユニットはこれまでのものを流用する。何事もなく完成した。ちょっと物足らなかったが、出来上がりには満足である。今度のセンサーはやたら高感度で、階段に近づくだけで反応する。

 考えてみたら、最初のセンサーを作ったのは、もう6年も前のことだった。まあ、6年も使ったのだがら減価償却はできているだろう。Dsc01495

エラー回復ロジックをつけた電波時計ロジックの工夫(9/20/2018)
 電波時計の開発にぐずぐずしているのは理由がある。今回のプロジェクトの本筋は、JJY電波リピーターで、電波時計は単なるテスト環境のつもりだった。我が家にある市販の電波時計は、腕時計、目覚まし、掛け時計とあらゆる種類が整い、今さら電波時計を自作する必要性はない。

 それなのに電波時計の方に夢中になっているのは一種の逃避である。電波リピーターはハードの要素が大きい。しかもハードと言っても電波という高周波の世界である。所長の高周波の知識は、60年近く昔の少年時代から一歩も進んでいない。大学時代の知識は超絶的な理論ベースで、実践には見事なほど役に立たない(自分であきれるばかり)。

 何となくハードを避け、自分の得意なソフトにこだわりたくなる潜在意識があるようだ。電波時計のハードは、いじるところがないが(受信モジュールには手が出せない)、ソフトには改良の大きな余地があるような期待がある。

 JJYの標準電波のロジックは簡単な構造である。一秒に一回の立ち上がりパルスのタイミングが、その時の正確な秒を示し、そのあとのパルス幅でコードが決定する(0.5秒が1、0.8秒が0)。10秒に一回、マーカーパルス(0.2秒)が出て、次のフレームへ進む。

 さらに1分に一回、このマーカーパルスが冒頭に出て正時(0秒)を定義する。6つのフレームは、時分、月日、西暦、曜日などに分かれ、時分については第4フレームにパリティビットがついて誤り検知が出来るようになっている。Dsc01488

 この連続マーカーパルスさえ正しく検知できれば、データが途中乱れても相当なエラー回復が可能である。いわゆるフレーム同期というやつで、月日、西暦などのデータは数多く重複するので、フレーム単位にデータを貯めておけば、大きな狂いを防ぐことも出来る。

 こうしたことを頭に入れて、オシロでJJY受信モジュールの出力波形をつぶさに観察すると、ノイズはパルスの立ち上がりや立下りでチャタリング風に出る短いパルスが多く、パルスの真ん中を分断することは少ない。チャタリング抑止のロジックを入れればだいぶエラーを減らせそうだ。

 さらに、パルス巾の認定にも工夫をした。参考にさせて貰ったソースリストでは、パルス巾の有効範囲がひどく狭く、それ以外をエラーにしている。このため、ちょっとノイズが出始めると、エラービットばかりになって話にならない。

 考えてみれば、パルス巾は、0.2、0.5、0.8秒以外はないので(15分、45分に出るモールス信号列を除けば)、中間値をすべてエラーにするのはおかしい。少々強引だが、ここではエラーの範囲をなくし、適当な区切りですべてを何らかの有効データとみなして後で調整することにした。

思いつくエラー修正を片っ端から盛り込むも迷走(9/23/2018)
 さらに、次のようなフレーム単位の修正ロジックを入れて、実験を開始した。測定では正式のJJY標準電波は、PCルームではノイズだらけで全くデコード不能になるので、主にNTPを使った電波リピーターの出力をソースにする。それでも正規のJJY電波と干渉するせいか少し離すとノイズが出る。

●正時(0秒)と正時の間のフレーム数が、6つ以外はエラーとしこの間のデータは捨てる
●マーカーとマーカーの間のパルス数が規定以外(9ビット)ではエラーとし、このフレームのデータを無効とする。

 しかし、この程度では少し波形がノイズっぽくなってくると、データが全く有効ではなくなり、表示は目茶目茶になる。特に致命的なのが、正時を判断する連続ポジションマーカーの取りこぼしで、たとえそのあとのフレームを正しく受信していても、西暦などもとんでもない数字に変わってしまう。

そこでさらに、
●キャッシュにデータを蓄えておいて、1分間正しくデータ(6フレーム、9ビット)を拾ったとき  にのみ始めて、そのときの時分、年月日を表示する。
●10秒ごとのフレーム単位に 有効/無効フラグを設定し、年月日のデータは使いまわしをする。

 などのデータ保全を狙った改善を行った。だいぶん精度が高くなった半面、正しい時刻に戻るのに時間がかかるうえ、時々、月日や西暦が出鱈目になる不具合は改善されない。エラーの程度を定量的に把握することが難しく何が効果があるのかわからないので泥沼状態である。

 試しに正式なJJYの受信できる場所で動かしてみる。電波が安定しているときは良いが、やっぱり、少しノイズが出始めてエラーになったら全くダメダメで、なかなか回復しない。既に正しく受信できているはずの西暦や、月日も目茶目茶になってしまう。

別の不具合が落着。やっと日にち違いの原因が究明された(9/25/2018)
 それでも受信エラーが僅かなうちは修正が効き、リピーターに近づけている限り、正しい時刻を表示するようになってきた。JJY標準電波の方も場所を選べば安定して受信できる。しかし、受信機にはまだもうひとつ大きな問題が残っている。 Dsc01482

 実際のJJY標準電波を受信すると受信機の日付が一日先になるのだ。リピーターから受信していれば合っているのに、標準で一日ずれるのは、要するにリピーターが出すパルスシーケンスがずれていることを示すが、リピーターが表示している日付とパルスシーケンスは全く同じリソースからとっており、ここで誤りが起きるのは不可思議としか言いようがない。

 例の辻褄合わせで直した「とがめ」が出ている感じがする。今度も閏年を疑って再度テストステートメントを挿入して確かめるが、問題はない。そこで少しづつ、printfを入れ込んで犯人を追跡していった。その結果、電波時計の方が帳尻合わせをしているようで、犯人はリピーター臭い。

 ビットの送り込みや、UNIX経過秒なども調べるが問題なし。さんざん調べまわった結果、やっと原因がわかった。NTPの通算日データが0オリジンだったというオチである(JJYは1オリジン)。NTPでは通算日と月日の両方のデータが独立して取れるようになっており、これが発見を遅らせた。

 奥歯に物がはさまったように気になっていたJJYリピーターと電波時計の一日の狂いが遂に究明された。最近は物忘れが激しく、つい10年も経たない職場の同僚の名前を思い出せなくて数日悩むことがあるが、それに匹敵する「もやもや感」が解消され、気分が良い。

もう一歩踏み込んでエラー補正。何とか及第か(9/27/2018)
 市販の電波時計が受信できるところでは、殆どエラーなしに受信ができるようになってきた。ただ、一分ごととフレーム毎のエラーチェックを厳密にしているはずなのに、まだ年月日が、ときどきインチキになるときがある。

 これがなぜ起きるのか、調べているうちに、この現象は偶にではなくしょっちゅう起こりうる現象であることがわかった。つまり誤ったポジションマーカーを途中で拾うと本来入るべきフレームではないところに別のデータが送り込まれる。

 当然、そのフレームはエラーになるが、次のフレームは0から始まるのでビット数が合ってそのフレームが有効になってしまうのだ。このフレームは所定の場所ではないので、データはでたらめになるというわけである。これを避けるには、正時から積算しているシステム内の秒数とフレーム数の照合をする必要がある。

 生の秒数と、フレーム番号を比較するのは少し抵抗があったのだが、この秒数は、連続したポジションマーカーの時、0に戻しているので信頼性は高い。やってみると、この効果は絶大で、年月日はまずどんなことがあっても変化しなくなった。やっと電波時計らしくなった。

 さらに、一度、正確に手に入れたデータはUNIX経過秒の形で残し、1分後のデータに不安がある時は、これを更新せず、前の経過秒に秒数を足す形で表示を守る。この秒数は、ArduinoIDEのタイムスタンプmillis()まで動員した。ちょっと禁じ手に近い技だが、理論上は、とりあえずは電波が受信できない状態でも時間は守れる。

JJY電波時計のESP8266用スケッチソースコードの公開(9/30/2018)
 居間に持ち込んでフィールドテストを続ける。本来のJJY電波の到達するところは殆どエラーなしで順調である。たまに数分遅れる時があるが、すぐに復帰する。これを避けるのは、電波時計の中にRTC(リアルタイマークロック)を入れれば完全に解決するが、元はと言えば、電波リピーターのテスト環境のつもりで開発してきたので、そこまでやる気はない。

 消費電流の多いESP8266とバックライト付きの液晶を使った電波時計だが、何かの参考になるかと思い。ここに回路図と一緒にスケッチソースコードを公開することにする。参考にさせていただいたソースコードはここである。復号のところは大いに参考にさせてもらった。あらためて御礼申し上げたい。Jjyclock

 回路について少し説明をしておくと、JJY受信モジュールはAitendoの古い40/60Khz受信モジュールで、もう販売しておらず、今は新しい受信モジュールになっているが、所定のところにつなげば(GPIOへは新しいモジュールのTNというネガティブ信号入力)、問題なく動くと思われる。

 受信モジュールとESP8266のGPIOとの間にトランジスター(2SA1015)が入っているが、これは、受信モジュールが負論理(0がデータ受信)の逆転をするためと、受信モジュールと直接ESP8266とつないだときの高周波ノイズを避けるためである(以前オシロにプローブをあてると誤動作した)。

 液晶の表示は、上段が年月日と時分、下段は、秒数とフレームの処理推移のプログレッシブバーもどき、さらに頭に正式なJJYからではなく推定の時には「X」マークが出る。

以下に、zipファイルでかためたスケッチソースファイルのフォルダーと、BSCH3Vの回路図ファイルを置きます。

「JJYradioClock.zip」をダウンロード


| | コメント (0) | トラックバック (0)

2018年9月 9日 (日)

ESP8266による電波時計リピーターの完成

 今年の8月は例年にない猛暑だった。観測史上初めてという猛暑日(35度以上)数の記録が各地で相次いだ。ここ東京も例外ではなく、月後半には猛烈な雷の夕立が連続したりして、何か日本が亜熱帯気候地帯に変わってしまったかのような不気味さを覚える。

 電子工作は相変わらずである。暑さでアスレチックジムのヨガを欠席することが増えて工作の時間はむしろ増えているのだが(何しろ老人は不要不急の外出はするなと脅されている)、集中が効かなくなっている。昔に比べれば間違いなく進行の速度が落ちている。

 ESP8266を使いまわして、AitendoのJJY標準電波受信モジュールを使った自作電波時計や、オシレーターチップ(LTC1799)を使ってJJY電波にNTP時刻を載せるリピーターを大分前から作っているのだが、どうも埒(らち)が明かない。記事の更新間隔もまた一か月を越えてしまった。

 まあそれでも、あれこれいじくりまわして、やっとそれらしい動きを双方がするようになってきたので、ここらでご報告することにする。このままずるずるブログの更新が出来ないでいると、電子工作に対する意欲そのものを失う心配があるからだ。

自前で作ったUNIX経過秒のお粗末(8/9/2018) 

 前回記事のコメント通り、自前のUNIX経過秒とNTP時刻との1日のずれは、Shuji009さんの指摘であっさり解決した。何と閏年の計算違い(バグとも言う)というお粗末である。Ws000008

 以前、JSTの指定をしたのにNTPからの時刻に9時間の差が出てしまい、面倒なので9時間足して辻褄あわせをしたことがあるが、今度も自前で計算した日時(1970年1月1日からの経過秒)とNTPの経過秒が合わない。時差のずれではないので少し気になったが、これも無精して1日足して帳尻を合わせた。

 それが記事をアップしたあと、Shuji009さんからコメントが入った。2000年は400で割り切れる年で閏年ですけど大丈夫ですかというご指摘である。閏年のロジックは、「4で割り切れる年は閏年。ただし、100で割り切れる時は平年。さらに400で割り切れると再び閏年」という結構ややこしいロジックである。

 はいはい、ちゃんと400で割り切れるロジックも入っていますよと、最初は自信満々だったが、何か胸騒ぎがした。待てよ、400で割り切れるときに、平年に戻していないかい。言葉にすると400で割り切れる時は、100でも割り切れるので、そんなことは考えられないが...

 あわててソースリストを出して見る。「がーん」、400で割り切れるときは平年にしている!こいつだ。せっかく400年のロジックを入れたのに逆さまでは何にもならない。これでは一日遅れるのは当然だ。 

 自作の閏年を決める関数、leapyear( )のロジックを修正する。勿論、簡単に解決した(添付画面は修正済み)。考えてみたら、UNIXの経過秒は、1970/1/1からの計算だから、時差とは関係ない。プログラムミスの疑いを持つべきだった。こういうことにあとから気づくのだから、どうしようもない。

パラレルキャラクタLCDもお粗末なトラブル(8/15/2018)
 気になっていたパラレルのキャラクターLCDが動くようになった。Arduinoの標準ライブラリ(LiguidCrystal.h)では動かず、ESP8266ではだめなのかも、と放置してあったのだが、その後ウェブ上で新しいライブラリーが見つかったのでこれを試すことにした。

 LCDのテストに使っていたNTP時刻をUARTに出力するプログラムに、前のライブラリを退避させて新しく組み込む。しかし、こいつも最初は動かなかった。このパラレルLCDは当初3.3V仕様であることを忘れ、不要なバックライトの負電圧回路を組み込んだり、バックライト配線が別にあることに気づくのが遅れたり散々苦労しているのだが、今度も駄目かとがっくり落ち込む。

 こういうときは腰を据えて、落ち着くことだ。基本に立ち返ってハードウエアの配線からチェックしなおした。おやあ、コントラストを決める端子が未配線だけれど、これに電圧をかけなくても良いの?いや、そりゃ駄目でしょう。

 そうか、こいつが原因に違いない。あわててブレークアウト基板に、半固定抵抗器を実装し、ピンに接続する。電源を入れ起動しなおすと見事LCD画面に「Hello ARDUINO」の初期表示がでた。やれやれ長かったな。コントラストの配線をしていないのでコントラスト最小のまま表示が見えていなかっただけというお粗末である。

Dsc01476

 もしかすると、元の(ArduinoIDEに最初から組み込まれている)LiguidCrystal.hでも動いていたのかも知れない。しかし、他にやらねばならないことが多いので、そこまでさかのぼって確認する気力がもう生まれてこない。さきに進もう。

 NTPの時刻を表示して暫く遊ぶ。書式付きの関数printfがlcdでも動くことを発見した(lcd.printf)。数字の表示位置が固定されるので「:」や「/」がずれず、格段に見やすくなる。ただし、ESP8266では多数の変数を表示しようとすると暴走する(3つまでOKであることは確認)。

較正の仕方がわかってエンコーダーの開発は順調に進む(8/22/2018)

 猛暑が続く。しかし地下室は温度が安定して涼しく、極楽だ。それなのに電子工作の進捗ははかばかしくない。今度のプロジェクトの最終目標は、ESP8266でNTP時刻を使いJJY電波をエンコードするリピーターである。Dsc01478 そのモニター用のこれもESP8266で作ったJJY電波時計の調整に手間取っている。このプログラムはUARTに盛大なテストメッセージが出るので、テストをやりやすくするため、時刻表示をLCDに出そうとしたのだが、LCDそのものの表示がなかなかうまくいかない。

 一方、オシレーターチップLTC1799を使ったリピーターの電波の強度は、もう十分だ。受信機と発信機双方をデスク上に置いた(1m以内)状態で、電波をON/OFFすると電波時計のモニターLEDがはっきり同期して点滅するのを確認している。ただ、送信を止めて暫くすると、受信機は本来のJJY電波を受信するのか乱れたパルスが出始める。

 受信モジュールにはAGC(自動感度制御)がついているようだ。ある程度以上の強度の電波をうけていれば微弱なJJY電波の方はマスクされるが、それが止まると弱い電波でも受信し始める感じだ。実用性を高めるためには、このあたりをもう少し調べておきたい。

 しかし、現在の電波時計プログラムの出力は、PCのコンソールしかなく移動できる場所が限られる。PCからは結構ノイズが出るのでここからも少し離したい。キャラクタLCDに手を付けたのも移動性を高めるためだった。

 とはいえ、こればっかりやっていても先に進まない。そこで、これまで放置していたリピーターのJJY電波エンコーダーの開発に注力することにした。干渉の方はこれが出来てからでも良い。リピーターの実装は、前回記事で紹介した通り、Pythonで書いたソースコードが手本にある。

 あらためてこれを読み込む。おお、これはとても自然なコーディングで好感が持てる。難しいことは全くやっていない、仕様通り、ポジションマーカーパルスで隔てられた10秒単位のデータを送り込んでいる。NTPとの較正のやり方がよくわからなかったのだが、ここでは平明な方法で実装している。

 あらかじめ、NTPで時刻を得たところをマイクロセカンドオーダーのタイムスタンプで記録し、次の正時(0秒)に見合う待ち時間を計算し、その待ち時間を使ってJJYのエンコードシーケンスの関数をスタートさせるというものだ。これで正確な同期が実現する。これはわかりやすい。

それらしい電波時計のシーケンスが出た(8/24/2018)

 同期ロジックがわかったので、急に先が拓けた気分になった。俄然コーディングする意欲が起きて移植に力が入る。Pythonから、Arduinoの言語(C++が基本)に戻すのは、そう難しくない。

 ただ、Pythonは構造化ブロックの識別がインデント(字下げ)だけなので、間違いやすいだろう。書くのは楽だがデバッグに苦労しそうだ(何を隠そう所長はbegin endで構造に厳密なpascal派だ)。

 しばらくコーディングに専念した。なにしろパルス一回当たりで数百msは待つロジックなので、少々のデバッグステートメントは入れ放題である。ArduinoのUART(Serial.printなど)はバッファリングしているらしく、一行出力では数十μsしか遅れないし、lcdでも2行出力が3msしかかからない。

 デバッグのためテンコ盛りにテストメッセージを入れたスケッチが完成した。まだLTC1799オシレーターの出力制御まで配線が済んでいないが、LEDをつけて動きを確かめる。電波時計のLEDブリンクは、このところいやというほどテストしているので、大体の動きは見ているだけでわかる。Dsc01481

 よーし、それらしい点滅が始まった。念のためオシロにもいれて動きを確認する。良いようだ。ブレッドボード上のLTC1799発生回路のロジックICに結線して実際の電波を発射する。ここまで来ると先を急ぎたくなる。ミニブレッドボード2つに組んだJJY電波時計を近くに寄せ、受信テストを開始する。

 良いぞ。電波時計のLEDがLTC1799オシレーターのLEDに合わせて点滅を始めた。問題ない。本来のJJY側の干渉もなく、順調に受信しているようだ。UARTコンソールをもう一台増設し、電波時計側のモニターも開始する。

 いやあ、長いことかかったが、電波時計側も、ノーエラーで時刻を表示し始めた。しかし、少し電波が弱い。1mも離すと、エラーが出始め、大元のJJY電波と干渉が始まってエラーの嵐になる。まだ安定したとは言えない。

 そうは言っても、とにかく目的は果たした。嬉しい。しばらく表示させて様子を見る。うーむ、まだ時間は正確ではないようだ。まず、分の更新が遅れている。それと1分遅い(これは想定済み)。それと、NTPとの同期ではどうも一秒程度遅いようだ。

秒の精度にこだわってみる(8/26/2018)

 ArduinoのNTPはSNTPがベースで、一時間に1回くらいの較正が入っているようである。クライアントのレベル(つまりWiFiの先のESP8266)でも、公式サイトによると0.5ms程度の誤差に止まるという話だが、どうもそれほど正確ではない(このほかここも参照)。

 自宅にある既存の電波時計を持ち込んだり、有線電話の117で調べるが、1秒近くずれている。もっとも市販の2万円以上するNTPリピーターでも誤差は1秒というのが多い。相手が人間である限り、こだわってみても余り意味はないのだが気にはなる。

 同期の方法を、待ち時間方式ではなく、一分単位に最終59秒まで来たら、NTPの時刻取得コマンド now = time(NULL); を10ms間隔で発行し、秒が59から00になるタイミングを待って同期させる方法に換えてみた。これでかなり正確になるはずだが、余り前と変わらない。それでも、分の更新の遅れの修正や(これは単なるコーディングミス)、コンソール出力メッセージの調整(多すぎるデバッグ用メッセージ削除)を進め、段々電波時計らしくなってきた。Dsc01482

 開発が一段落してきたので、昨日、これも久しぶりに御徒町のAitendoを訪れ、ESP8266の予備とアダプター基板、ついでにI2C液晶を数点買い込んだ。土曜ということもあって、いつもながら混雑している。ここのLCDのラインナップはすさまじく多い。I2C液晶のコントローラーチップは殆どが例のST7032のようで、制御ソフトについて神経を遣わないで済むのは嬉しい(Arduinoのライブラリで動く)。

AitendoのI2C液晶ディスプレイで遊ぶ、いや遊ばれている(8/28/2018)

 リピーターや受信機は、ブレッドボードでは動いたが、実装をどうするかで迷っている。すぐにはうまい方法が見当たらないので、とりあえずは、Aitendoで買い込んだI2C液晶のLCDの動作試験をすることにした。ところが、これがまた曲者だったのである。

 沢山のAitendoの液晶群の中から、あらかじめウェブで一番スマートそうな奴を選んで買ったのが、このLCDである。しかし買って帰って良く見ると、ピン幅が、1.8ミリという変態的な間隔で、しかもバックライトの端子が横に不作法に突き出ている。Ws000009

 例のピッチ変換テクニックの荒業を駆使してブレッドボードに装着する。空中配線は予想通りうまく行った。10ピンのハンダ付けはとても頑丈で、ハンダは僅かづつしか付いていないが12本もつけば少々力を入れてもビクともしない。ブレッドボードの抜き差しも全く心配ない。

 このLCDはI2CとSPI両方のインターフェースをサポートしているので、ジャンパー配線や、パスコンを2つも接続しなければならないが、とりあえずはピンだけにしてブレッドボードでこのあたりは配線する。Dsc01483  最終的には、受信機も、リピーターもLCD表示でスタンドアローン化したい。ただ。時計なので電池駆動は無理でACアダプターということになりそうだ。

ST7032のライブラリーが入らない(9/4/2018)
 I2C液晶に対するArduinoの対応は、多種多様な方法があるようで、ウェブ上には、沢山の方法、ライブラリーの紹介があり、何を選んでよいか迷ってしまう。このあたりは、ここのサイトが詳しく紹介されているのでお勧めである。

 今度の液晶のコントローラチップST7032のライブラリーだけでもいくつかあるが、当研究所では、一番簡単そうな、このサイトのライブラリーを選ばせてもらった。

 おや、こちらは標準のライブラリではなく、新たなライブラリST7032.hが必要なようだ。言われるままにリソースをダウンロードし、所定のディレクトリに収容してビルドに入った。しかし「ST7032.hなんて知らないよ」という素っ気ないエラーが返ってきた。

 ふーむ、ウェブの指定では、とってきたリソース(フォルダー)のリネームをすることになっている。そういえば、ArduinoIDEは立ち上げ直していない。一旦、終了して立ち上げ直す。よーし、ビルドのメッセージが先に進んだ。コンパイルしているようだ。

 いやだめだ。ソースリストの中でコンパイルエラーが出ている。ST7032.cppの中でavr/pgmspace.hがないと怒られる。なにー、avrじゃないとだめなのか。手近なところにavrのライブラリーはない。それにここはESP8266だ。暗雲が垂れ込める。

 困ったときのGoogle先生である。ウェブを漁ると出てきた出てきた。いつものエラーメッセージぶっこみ方式である。「ST7032.h avr/pgmspace.h no such file」で一発で、このGitHubがヒットした。ST7032.cppを探し出し、この通りにしたらコンパイルが通った。

 ソフトはOKである。意気揚々と、配線をしてテストを開始する。店が紹介するデータシートは中国語だが、不思議に殆どが理解可能だ。I2Cなので、ピン12本のうち必要なのは4本だけで(Vcc GND SCL SDA)配線が楽だ。それと、I2C/SPIの識別する制御ピンなどを適当につないで実験を開始した。

この液晶もコントラスト不足で最後までてこずる(9/5/2018)
 これがまた全く動かない。ライブラリーを使うのは楽で良いけれど、ソフトが悪いのかハードが悪いのか、このままでは全く見当がつかない。こういうときは処置なしである。そのうち、不具合箇所の切り分けに良い方法を見つけた。

 I2C液晶は、ストロベリーリナックスの昔のPCMプレーヤーに使った現物がブレッドボード上に残っている。これを流用して動かしてみればどちらが悪いかすぐわかる。早速試す。え、いやこれも動かない。何だと―、ソフトが悪いのか。

 ウェブ上で紹介されているソースリストをもう一度良く見る(これしか頼りにならない)。コンストラクターでlcdオブジェクトを作って(ST7032 lcd;など)、次のステップがいきなりlcd.clear()などのステートメントだ。これ何か足らないような。例えば、lcd.begin(16,2)なんて初期化はしないで良いのかい。半信半疑だったが、だめもとである。付け加えてみる。

 おーし、ストロベリーリナックスの超小型LCDにメッセージが出た。初期化ステートメントが抜けていただけだ。ソフトは問題ない。しかし新しいLCDでは動かない。何回目かのピン配置の確認をしているとき、とんでもないことを見つけて顔が青ざめた。

 何とピン番号のスタートが逆順だ。ICなどのストレートのピン番号は原則は反時計回りで下の段なら左側からだが、このLCDのピン番号は右から始まっている!データシートには明記されているので間違えたこちらが悪いが、それにしても。

 さらにVccとグランドの端子位置を確かめて愕然とする。電源2本は中間地点で対称についている。つまり逆にすると電源は逆差しになってしまう。いやあ、壊したか。折角、ピンヘッダーを芸術的に接続したというのに。逆接の時間は通算でも1分ないと思うが壊れた可能性は高い。

 泣く泣く、もう一台のLCDの実装にとりかかる。最初のLCDのピッチ変換のピンヘッダーをとりはずし、2台めにハンダ付けする。さあどうだ。あれー、まだ表示されない。しかし、表面がうっすら変わった感じがする。前の経験が生きている。

 今度もコントラストか。 I2C液晶のコントラストはソフトである。コードには中間の30にしてある。ストロベリーリナックスのLCDはこれで良かった。もしかしたら、こいつを変えると良いのかもしれない。コントラストを50にして再ビルドする。やったー、文字が出た。

Dsc01485  悔しいので、速攻でコンソールからのキー入力でコントラストを上下するロジックを組み込む。このLCDは0~63までのうち、50以上でないと鮮明に出ないことが分かった。

 壊れたと思った最初のLCDの方である。ピッチ変換ピンヘッダーをもう一度付け直すのは大変なのでジャンパーコードを無理やりハンダ付けし、付属のパスコンなどは空中配線でつけてテストした。良かった、壊れていなかった。正常に表示が出た。やれやれこれでブログに書くことができる。
(スケッチのコードはまだ未完成なので、次回以降に公開したいと思います。)

| | コメント (0) | トラックバック (0)

2018年8月 3日 (金)

また脱線。今度は電波時計リピーターでさらに迷走

 記事の間隔が今回も一か月を越えた。このあいだ電子工作をやっていなかったわけではない。毎日、PCルームにこもって、ごそごそやっているのだが、何しろやることが発散し、次々に興味が他に移るので記事にまとめるところまでいかない。

 赤外線リモコンウェブサーバーのプロジェクトはソースコードの公開で一段落し、そのあと、表面実装基板にするためkiCADの基板設計に取り組んでいた。しかしこれが、ひょんなことで別のテーマに興味が移った。電波時計のリピーターである。

 さらに、そのリピーターも部品の動作テストをやっただけで、関心は電波時計の制作の方に移り、それも、さらに別の枝葉の分野に手を伸ばして収拾がつかなくなってしまった。このあたりで戦線をまとめ直さないと、いつまでたっても記事が書けなくなる。

久しぶりのkiCADは進みが遅い(6/25/2018)
  ミニブレッドボードに作ったリチウム電池駆動の携帯型赤外線リモコンウェブサーバーは、とりあえず目的の機能を満足し(2階のエアコン、温風ヒーターの制御)、実用化の目途が立った。ただハードはまだ実験用のブレッドボード上だし、ソフト面でも残された課題が多い。

Dsc01462  まずは、覚えたリモコン命令を記録していくEEPROMエリアの拡張である。まともにやるなら、例のSPIFFSのファイルシステムにすれば良いのだけれど、そこまで大がかりにする気にはなれない。そう、ニーズがはっきりしていないので運用シナリオが描けないである。

 具体的な仕様が決まらない。今のところ考えているのが寝室の冷暖房の精密温度制御だが、どうしてもやりたいわけでもない(時限タイマーを使えばそれなりに間に合う)。もうひとつが洗面所の温風ヒーターだが、これは防水仕様(湯舟から動かしたい)をまとめる方が先で、ソフト面でこれ以上つけたすところはない。

 あらゆる機器開発でうまくいかない原因の最大級は、この「仕様が明確でない」ということである。実際の使い方が決まらなければ、結局、どれくらいの大きさのEEPROMが必要なのかも定まらない。困ったものだ。

 というので、赤外線サーバーのソフト開発はこのあたりにし、ハードの実装基板を作ることにした。もともとの制作動機は、この基板を表面実装で自前のCNCマシンで作ることだったのだ。何のことはない、本道に戻ったことになる。

 久しぶりにkiCADを立ち上げて表面実装基板の設計に入る。回路図エディターで、ミニブレッドボードに作ったESP8266のウェブサーバーの回路図を改めて書き下ろす。情けないことにkiCADの使い方をあらかたみな忘れている。 

 ESP8266のフットプリントデータをネットで探す。これが意外と見つからない。みんなブレークアウト基板で済ませているようだ。あちこち探し回ってやっと見つかった。しかし、これが回路図エディターに取り出すことができない。 Irserver

 原因はフットプリントデータと、ESP8266の回路図データは別物であることに暫く気が付かずに迷走していただけだった。やれやれ、年は取りたくないものである。見つけたフットプリントは、新しいバージョンのkiCADが必要だというので、kiCADのインストールをしなおす。殆ど泥縄状態である。

 ところが新バージョン(4.0.7)のkiCADは、変な所でループが始まって先に進まない。部品の諸元を変更するたびに、フリーズする。全く止まるわけではなく暫くすると復帰するが、ちょっとした定数の変更のたびに長時間待たされるのはたまらない。

 バージョンを元にもどそうかと考え始めたころ、解決法が見つかった。アノテーションと言ってパーツの番号付けをするルーチンがおかしくなっているようだ。強制的なアノテーションを部品の諸元を替えるたびに行うと、短時間で処理が終わることが分かった。なんやかんやで、回路図をつくるところでなかなか先に進まない。

電波時計リピーターは市販化されていて結構良い値段がする(7/8/2018)
 そんなころ、ESP8266の予備品を見つけるため部品箱を整理していたら、LCT1799というチップが目に入った。これは、去年の4月に面白がって買ったオシレーターチップで、これでNTP(Network Time Protocol)から得た正確な時刻を元に自前のJJYの標準電波(40kHz)を出して、電波時計を動かそうというものである。

 ウェブを検索してみて驚いた。NTPを使った電波時計リピーターは、最近は事務所などで沢山の掛け時計の時刻合わせに使われるらしく、市販品が多数出ており、しかも結構な価格で売り出されている。安いものでも2万円はする。

 電波時計のJJY信号は、もう6年も前、Aitendoで実際に受信モジュールを買ってきてテストしたことがある。値段を聞いて俄然、制作意欲が盛り上がった。赤外線サーバーそっちのけで、受信モジュールの実験の準備を始める。リピーターの実験には、こういう受信モジュールが必須だからだ。

 電波時計リピーターの方は、参考にさせて貰ったサイトではRaspberryPiでPythonを使ったソースコードが公開されている。電波時計は処理単位が一秒ごと、つまり1 bpsなので、NTPさえ動けば何もRaspiまで担ぎ出すことはない。ESP8266で十分動くはずだ。 

 NTPではなく、既存のJJYからのリピーターなら、当研究所の名前になっている8ビットのAVRでも十分可能だ。電子工作では著名なChaNさんは、10年以上も前にTiny2313クラスで電波時計を作られている。

 少し迷ったが、現在一番環境が揃っていて開発に慣れているESP8266で作ることにした。まずは正しい電波をデコードできる時計を完成させ、次に電波発生装置に行くことにする。アンテナが課題だ。

6年ぶりの電波時計モジュールは動いた(7/11/2018)
 部品箱から取り出したAitendoの受信モジュールは、ミニブレッドボードに刺さったままで、モニターのときPCなどからのノイズを避けるフォトカップラーもついていた。早速、通電して動作を確認する。電源を入れてすぐは動かないが、暫く(十数秒)すると、福島からの電波を受信し、LEDが点滅し始めた。

Dsc01475  うむ、動いているようだ。新しいオシロをつないでパルスを見る。前のオシロはじかに接続すると、ノイズが出て受信不能になったのだが、どうだろう。まずは直接つないでみる。おお、今度のオシロは直結でも全く問題なくJJYのパルスが表示された。

 ちゃんとした高周波ノイズ漏れ対策が出来ているのだろう。たいしたものだ。ただ、地下室の奥にあるPCのそばではやはりノイズが多い。オシロと受信モジュールをひとまとめにして、PCのそばから、地下室のオープンスペース(保安上の吹き抜け)へ持ち込むとJJY時報パルスは完全になる。

 蛍光灯の近くは全然だめだが、PC電源の影響は殆どないようだ。受信機はオシロがなくても、電波を受けるとLEDが点くようになっているので、部屋のあちこちに移動して受信状況を調べる。以前はPCの横でも正常に受信できたのだが、長波は季節的なものがあるのかもしれない。Dsc01468

 とはいえ、オシロで見ているとパルスが全くでたらめになることは少なく、パルスの立ち上がりと立下りでチャタリングが起きている程度である。頑張れば、ここでもデコードすることが出来るかもしれない。このあたりの受信強度でも時刻を得られることを今回の開発目標とする。

 ESP8266でのJJYデコードのソースコードはウェブにいくつかころがっていた。Arduino IDEを使ったそのうちの一つが簡単そうなので、これを利用させてもらうことにする。参考にさせて貰ったソースのブログは以下の通り。    
https://ameblo.jp/amano-jacky-nochio/entry-11824498383.html

 ソースが見つかったので安心して、その前に、まだやっていない40kHzの発振機能を確かめておくことにした。

電波送信は昔の真空管のC級増幅を真似る(7/14/2018)
 ブレッドボードにLTC1799モジュールを差し込み、ウェブで紹介された通りの回路を組み立てる。このサイトの記事は外見だけでアンテナの諸元の詳しい説明がない。これは電波法のからみで具体的な情報を避けておられると勝手に判断し、自分なりのアンテナを用意して長波の電波発振のテストを始めることにした。

 動作そのものは、モジュールなので電源を入れると簡単に動いた。オシロで波形を確かめる。矩形波の綺麗なパルスが出ているのを確認した。既に組み上げたJJY受信モジュールを近づけてみる。アンテナは適当なリード線(電話ケーブル4~5m)である。Dsc01473

 JJYのデコードは出来ていないが、受信だけならLEDの点滅でわかる。ブレッドボードの近くに受信モジュールを近づけると、LEDが点いたままになり、受信していることは明らかだ。少し離すと切れる。1m程度が限界だ。リード線はつないでも離しても変わらない。ほっておくとJJYからの電波を受信し始める。

 サイトの記事の外見はフェライトコアにUEW線を巻き付けたいわゆるバーアンテナである。長波なんて波長は何キロメートルもあるので、どんなアンテナで送信するのが良いか全くわからない。

 それでも、ふと思い出して部品箱を漁る。みつけたみつけた。以前Aitendoで買ったシングルバンド用の受信モジュールのアンテナ部分が見つかった。買ったころ断線していて苦労したやつである。

Dsc01466  これは受信用だが、送信アンテナの代わりになるはずだ。単にオシレーターの出力につなぐのではなく、サイトの記事通り、FET(2SJ377)をつけ、20Ω程度の抵抗負荷をつけてみた。

 少し電波は強くなったようだが、事務所内の電波掛け時計を一斉に同期させるほどの強さではない。よく考えてみたら、電源電圧が変わっていないのだから、FETで増幅してみても同じ負荷なら出力は増えない理屈だ。

 念のため、オシロで波形を見てみる。おやあ、鋭い下向けのパルス(数十V以上)が出ている。ふーむ。これはDC-DCコンバーターのスイッチング回路そのままだ。これをならせば正弦波になるのか。

 ここで閃いた。昔というより大昔、アマチュア無線の真似事でやった共振回路である。適当なコンデンサーをインダクタンス(バーアンテナ)に並列にして同調回路にする。真空管時代のC級増幅のタンク回路である。

 おお、正弦波まではいかないがそれらしい矩形波がでた。喜び勇んでJJY受信機の感度を確かめる。うん少しは良くなったようだ。LTC1799そのものよりは少し距離が伸びた。しかし、3mから4m少々までが受信限度である。

 バーアンテナの威力がわかったものの、すこし離れるとJJY電波の方が強くなる。福島からの電波に負けるのだから、LTC1799から発射されている電波強度は、いわゆる電波法に云う免許なしに出して良い微弱電波であることは間違いない。

 大きな部屋の多くの電波掛け時計を制御することは出来ないので実用品にはならないが、アマチュアで近くの電波時計を動かすには十分だろう。免許の必要もない(大体、許可されるはずもないが)

ESP8266によるNTPの受信は簡単に動いた(7/16/2018)
 JJY受信の目途はたったし(ソースを入手しただけだが)、電波の送信もOKになった。残りは、NTPの受信である。以前、RaspberryPiでNTPを受信したことがあるが、ESP8266では初めてである。またネットのお世話になる。

 調べると、簡単に、サンプルソースが見つかった。早速新規プロジェクトを立ち上げ、コピペ一発でソースをぶちこむ。幸いビルドはNO ERRORである。動かしてみるとシリアルコンソール上に、正確な年月日時分秒が出た。

Jjydecoder  同期をどうするかという問題は残るが、これで必要なリソースはすべて揃ったことになる。ただし正確さについては、NTPを使っている以上、余り厳密な追及は出来ない。

JJY受信機の表示に3.3V用のキャラクターLCDを使おうとして失敗(7/18/2018)
 JJYの受信デコードのプログラムのソフト開発に戻る。ネットから頂いたJJYデコードプログラムは、ESP8266ではなく、普通のAVRを使ったArduinoがベースで、表示装置はキャラクターLCDである。

 こちらのLCDの手持ちは、大分前に買ってあった定番中の定番、秋月の反転色の2行16文字のキャラクターLCD(SC1602BBWB-XA-LB-G)である。普通、こういうLCDは3.3Vでは動かない。ウェブを見ていても、ESP8266のLCDは最近はやりのI2Cインターフェースの3.3V版が殆どで、こうしたパラレルLCDの使用例は極めて少ない。 

 そのうち、5VのLCDを、LCDクロックのパルスを利用した負電圧発生回路を付加して使っているページを見つけて制作心が刺激され、これを入れてみることにした。久しぶりのハンダ付けを楽しむ。ところが、これが全く動かない。バックライトすらつかない。

 キャラクターLCDを使うのは、考えてみると久しぶりで、下手をするとガイガーカウンター以来で7年は経っている。色々調べるうち、お粗末な間違いというか勘違いをいくつも発見した。まず、このパラレルLCDはもともとが3.3V用で、負電圧回路は全く必要がなかった。お馬鹿な話である。

 さらに、バックライトの電源は別から供給しなければならないということにだいぶあとで気が付いた。いやいや、情けないの一言である。

Dsc01467  バックライトに電源を入れて、LCDはそれらしい表示が出てきたが、表示ドットはいわゆる豆腐状態で全く反応が見られない。オシロで制御信号を見ると、細かいパルスが出ているが、LCDのパルスにしては、細すぎる(数μs)。どうも、このソースはArduino用で、ESP8266では動かないようだ。

 ライブラリーのLiquidCrystal.hのソースを見た限りでは、クロック依存のところはなさそうなのだが、ここにあまりかかずらっているのも意味がなさそうな感じがしてきた。時計を作ることが最終目的ではない。潔くLCDをあきらめてシリアルコンソールにすることにする。

LCDを諦めて、シリアルコンソールに出力を換える(7/20/2018)
 猛暑である。週2回行っているヨガとプールのアスレチックジムもお休みである。LCDは開発の必須条件ではない。本筋でないところであちこち道草を食ってきたので、何が何だかわからなくなってきた。とりあえずはソースコードのLCD表示部分をシリアルコンソールに切り替える作業に没頭する。

 これは手数がかかっただけで、何も問題はなかった。シリアルコンソールに、それらしいメッセージが次々に表示された。しかし、エラーが多い。いつまでたっても正しいJJY時刻を手に入れることは出来なさそうである。

 このソースは、チャタリングなどの抑止機能は全くついていない。パルスを単純に受け入れて、パルス幅、0.2sec(マーカーパルス)、0.5sec(論理1)、0.8sec(論理0)をスペックどおり(±5ms)調べて、範囲を超えるところはすべてエラーにしている。

 これでは、オシロでみたような立ち上がりや立下りでチャタリングを起こせば、全くデコードできなくなる。そこで、スイッチ制御でおなじみのチャタリング防止ロジックを入れる。立ち上がりと立下りの双方に数十msの待ち時間を入れ、安定したパルスになるようにする。

 しかし、PC横の受信モジュールではどうやっても安定した時刻を得ることができない。前と違って、まれに(10回に一回くらいか)、時刻が出る時もあるが、これでは実用性にかける。

Dsc01471  こうなると意地である。受信機を地上近くのオープンスペースの階段に置いて、PCのところまで電話ケーブル(10m)で送電線のように引き回してテストを続ける。フォトカプラーを経由しているせいか、少々引き回しても結果が乱れることは全くなかった。

 地上近くでは、殆どエラーは起きない。この状態でやっとJJY電波のデコードに成功した。大体、JJY時計の開発が目的ではなく、リピーターが目的なのに全く無駄なことをやっていると思うが、やりだしてことを途中で止めることが出来ない性格である。自分でもあきれてしまう。

一分の遅れをどうするかでまた脱線(7/28/2018)
 実は、これも、NTPを使ったリピーターには関係のない話なのだが、ここでまた3日近く浪費した。それは、JJY標準電波の表示時間が、最初に正時パルスが来て、そのあとおよそ1分かけてその時刻(時分年月日)を伝えるパルスが送られてくるというロジックの問題である。

 つまり、パルスを受け取って、その時刻が何時何分の正時だったかがわかるのは、およそ1分後になるということだ。リピーターなら、NTPと同期させて正時パルスを伝え、その時刻データを送って行けばよい。しかし、時計の場合は、1分先の時刻を用意しないと、正確な時刻にならなくなる。

 これも、お馬鹿な話だが、リピーターでも、この1分先の時刻を用意しなければならないと思い、一生懸命ロジックを考えてテストしていた。たかが一分と侮ってはいけない。単に分を足すだけでは問題は解決しない。下手をすれば年をまたがるときは、すべての表示を変える必要がある。

 色々考えたが、UNIX経過時間を使うのが一番合理的だと判断した。UNIXは1970年1月1日午前0時から始めた秒数をタイマーとして持っている。これに関しては沢山の標準関数が用意されているのでこれを応用する。

 やりかたはこうだ。JJYから得られた時分年月日を一旦、この経過秒に変換し、これに60を足して、また時分年月日に戻せば良い理屈である。

 早速、先ほどのNTPプログラムにこのロジックを組み込んでテストする。ところがこれが一筋縄では行かなかったのである。

 悪戦苦闘、3日間。やっと解決した。しかし、この経過時間があちこちで違うので参った。つまり、JST(日本標準時)の扱い方が、サイトやNTPのオプションで違うのか、どうしても数が合わない。最終的な解決は、この前もやったと思うが、現場合わせである。つまり、NTPをJSTオプションで使ったタイマー値は、地道に計算した1970/1/1の経過秒より一日増やせば一致することがわかった。

 いかにも釈然としない解決だが、とりあえずは、一分遅らせることに成功である。やれやれ。このあたりでブログの原稿をまとめよう。

| | コメント (4) | トラックバック (0)

2018年6月23日 (土)

ESP8266の赤外線リモコンウェブサーバー実装にはまる

 2年越しの課題、古いエアコンの赤外線リモコンの制御に成功して意気が上がったのも束の間、またブログの更新間隔が1ヵ月を越えてしまった。久しぶりのソフト開発に思いのほか手間がかかった。ソースの公開のためのスクラッチビルドが遅々として進まず、開発が難航していたのだ。

 最近、ソースコードを公開していないので、そろそろソフトを公開しようとしていた。人様のソースの流用なので、許諾を得るために何度か先方に問い合わせをしてきた。しかし、今になっても返事がない。仕方がないので、ソースコードをこちらで書き直すことにした。

 本来は、クリーンルームなどにこもって、既存のコードとは完全に切り離した形で開発しないといけないのだが、まあ、アマチュアなのでそこは大目に見ていただき、ソースコードをモジュール単位に分解して作り直す。しかし、どうしても似たようなコードになってしまうのは仕方がない。

 それでも、独自のロジックを組み込んだりして、何とか目鼻がついてきたので、このへんでそろそろ公開することにする。

ウェブサーバーからリモコン操作ができるようにする(5/12/2018)
 参考にさせてもらったサイトはここである。ESP8266でコード式の赤外線リモコンの送受信までの機能がある。記事の続編には、ウェブサーバー版もあるようなので、これも少し参考にさせてもらった。

 ただ、ここでは、赤外線リモコンのコードは手入力でソースコードのHTMLデータにセットしている。せっかく赤外線コードが得られているのに、これを手書きで入れ直すのはあまり嬉しくない。 そこで、これをもっと使いやすく、受信したコードをコンパイルなしにウェブを通して送信する機能を追加することにした。

 この世界は所長の慣れないウェブプログラミングである。それでもAVRなどと違ってESP8266はかなりのフラッシュを持っているので、相当なことが出来そうだ。ここで勉強して経験を積み、このあたりの開発力をもう少し高めておきたいという下心もある。

Dsc01464 このため、最近何冊か参考書を買って勉強しているが、今一つ成果は上がっていない。意気込んでプログラミングにとりかかったもののなかなか先に進まない。ウェブを漁ったり、過去の参考書を引っ張り出したり、悪戦苦闘の連続で、まともに動き始めるのに、結局ほぼ2週間かかった。

 Arduinoのライブラリーを活用しようとしているので、回り道が多い。調べているうちESP8266のウェブサーバー関係のプログラム例は沢山、ウェブ上に見かけるが、まとめると大きく2つの流れがあることがわかった。

ESP8266のウェブサーバーライブラリには2種類あり微妙に違う(5/14/2018)
 まず、ひとつは、この参照サイトにも使われているESP8266webserver.hというライブラリ(クラス)を使ったコードで、もうひとつはArduino本来のWiFiシールド時代からとみられるWiFiserver.hである。 

 最初のライブラリは、クライアントからリクエストが上がると、server.on()というイベントドリブン的な関数が呼ばれて、ここでそれぞれイベントに応じた処理が行える。メインのloop()の中は、HandleClient()しかなく、ここでこまごまとした処理を一手に引き受けているようだ。

 もう一方は、clientというクラスを定義して、クライアントからのレスポンスをloop()の中で常時待ち、リクエストそのものを実際に受け取りながら処理を制御する。こちらの方はやや原始的だが多彩な操作が出来そうである。

 ウェブサーバーのGET/POSTといったデータのやり取りは今一つ理解できていないので、後者の系統が分かりやすくて良いのだが、クライアントからのデータの取り出しが難しい。見様見真似でコードを書いていくのだが、今一(いまいち)しっくり来ない。

 前者はそのへんを組み込み関数一発で解決できる。しかしウェブサーバーの処理以外の並行処理をしようとすると(たとえばタクトスイッチ制御など)、どうもうまく動いてくれない。loop()のなかの、handleclient()がブラックボックスになっていて難しい。あれこれ悩む。

50年ぶりの葵祭は小ぎれいになっていた(5/15/2018)
 開発の話が続いたので、たまには、電子工作以外の話題をご紹介。所長の例の京都の小学校の同窓会の話である。これまでは京都近郊の少し離れた会場(石山寺、宇治など)に惹かれて、東京から足を運んでいたが、こんどは別のおさそいである。幹事もなかなかやるものだ。

Dsc01451 前は場所につられたが、今度は京都三大祭りのひとつである葵(あおい)祭の当日がクラス会という趣向である。われわれのクラスの卒業時の総数は51名、そのうち物故者4名、所在が分かっている人32名で、今回は15名の参加であった。半分に近い結構な出席率だ。しかも関東からの出席者が半数近くもいる。やはり祭りの威力はたいしたものである。

Dsc01459  子供の頃見物した葵祭は、平安時代の装束をつけた行列が鴨川の土手を練り歩く頃は、祭りが終盤に近いので、学生アルバイトが汗みずくで疲れ果てて歩いており、近くで見ると見映えの決して良いものではなかった。しかし50年ぶりに見た祭りの行列は、なかなか小ぎれいになっていた。

Dsc01455

 みな溌剌としており、藤の花で飾られた牛車(ぎっしゃ)がとても優雅だ。馬に乗った人の列も昔より沢山いる。しかも馬はみなサラブレッドで昔はこんな立派な馬ではなかった。話に聞くと、関東方面の牧場から乗馬用の馬を大量に借りて来るそうで、人ごみに慣れておらず、時々、暴れるそうだ。

 そういえば、所長の学友には祭りの主催者、上賀茂神社の関係者がおり、直垂(ひたたれ)姿で乗馬していて、御所内で落馬しかけている報道写真を数年前新聞で見たことがある。

やっと目鼻がついたか。ウェブプログラミングが通る(5/25/2018)
 開発の話に戻ろう。2年越しでエアコンの作動に成功したといっても、これはモニターにしているシリアルコンソールからの発信で、ブラウザー画面からではない。ハードはこの前に使ったミニブレッドボードの携帯型の学習リモコンで、ここにウェブサーバーのソフトを流し込んでいく。

Dsc01465  ウェブサーバー用のソースコードは既にサイトに紹介されているのだが、スクラッチから開発したいため、別のライブラリーWiFiserver.hで動くようにコードを書き換えて行く。前にも述べたように、このライブラリーは、loop()の中でGET/POSTという、クライアントとサーバーのやりとりが目に見える形で操作できるのでプログラミングがしやすい。

 しかし、すぐに暗礁に乗り上げた。帰ってくるデータが制御文字を避けるためのエンコードが残ったままで(スペースが%20など)、これをデコードしなければならない。%20をスペースに戻すくらいなら簡単だが、サーバーには日本語が使いたいので漢字となるとお手上げである。

 ウェブ上で解決法を探したが手ごろな仕掛けは見つからない。色々迷ったが、結局、オリジナルのESP8266webserver.hに戻し、なるべく元のソースコードを見ないようにして開発していくことにした。

 こちらのライブラリでは、GET/POSTで入ってくるコードは、argsという組み込み関数にパラメーターを与えれば、コマンドのStringデータを次々に一発で得ることが出来る。しかもデータはエンコードされておらず(というより、関数内でデコード済み)、大幅に開発量を減らせる。

 お手本があるので進捗が早い。オリジナルのWiFiがAPモードで使いにくかったので、STAモードに換え、一般のブラウザーでも画面が出るようにする。これで使いにくいスマホをクライアントにしないで、一般のPCから操作が出来るようになった。

 HTML文書は、以前、ESP32で画像付きサーバーを作ったときのソースを流用して、とりあえず画面を立ち上げる。styleシートの扱いが難しく、素人まるだしの無粋な画面だが、動かしてみると、これが意外にも簡単に動いた。Ws000004 とりあえず、電子音量リモコンの上下ボタンと、エアコンのスタート/ストップだけの操作だが、PCの画面から、ボタンをクリックすると、音量リモコンが動き、エアコンが、厳かに音を立てて始動するのを確認した。いやいや、まだオリジナルのソースのかなりの部分が残っているが、とりあえずは完成である。感慨にふける。

コンパイルなしに新しい赤外線コマンドを画面から追加する(5/27/2018)
 次の課題は、ウェブサーバー上でのコマンドの追加である。受信部はまだこのサーバープログラムには実装していないので、まずはFORMタグによるクライアント画面上からのコマンド名と、その赤外線データの文字入力でコマンドを新設する機能を開発する。

 ブラウザーの画面で、データのやりとりをするのは簡単ではない。シリアルコンソールなどの送受信は、双方が同等の機能を持ち、独立して動くので、やりとりを設計するのに苦労しないが、HTMLを介したサーバーとクライアントのやりとりは、サーバーからクライアントにトリガーをかけることは基本的には出来ないので、一筋縄ではいかない。

 いわゆるプッシュ通信という、あたかも、サーバーからデータが来るように見える機能があるが、これは、あらかじめクライアント側のアプリに仕掛けがしてあるからで、基本的にサーバーは、あくまでもクライアントからのリクエストを待つしかない。

 つまり継続して通信を続けるには、必ず、クライアント側にお膳立てが必要で、HTML文書やCGIなどでサーバーが事前に準備しておく必要があるのだ。これが面倒である。

 悪戦苦闘の結果、画面上の形や位置は、とてもスマートと言えない状態だが、コマンド名とそのコード化された赤外線コマンド($から始まる16進コード、オリジナルがまだ残っている)を画面上に表示し、FORMタグで取りこむことに成功した。下の行に、クリッカブルになったコマンドが表示され、これをクリックすると、めでたくリモコンとして動作した。やれやれ、これでまた一歩前進である。

 こうなると、受信部の実装が急がれる。赤外線受信のハードの部分は携帯型学習リモコンに実装済みで、オリジナルのソースコードでは動作を確認している。これを独自ソースに書き換えなければならない。

 受信部分で最も大変なのが、得られたRAWデータ(パルス幅μs)をコード化する部分である。オリジナルは、AEHA(家電協)方式と、NEC方式しかサポートしておらず、あとからSONY方式を追加したのだが、今度は、いちから作り直しである。

 特に苦労したところは、NEC方式とSONY方式の区別だ。基本のパルス長が562μsと600μsと非常に近接しており、この差だけで区別することは難しい(テストのときは何とか特定データで誤魔化した)。これを全く違う方法で区別するように頭を捻った。

 その方法は、ソースを見て頂ければわかるが、NECとSONYの基本長がほぼ同じで、論理ビットがちょうど反転しているのを利用している(NECはONパルスの長さが一定で、OFFの長さで0.1を判断し、SONYはその逆)。得られたON/OFFのビット長の平均を比較すれば、ほぼ間違いなく両者を区別できるしくみだ。

EEPROMが曲者だった。いくつかの落とし穴にはまる(6/5/2018)

 受信部のスクラッチ開発は手間がかかるので、その作業のかたわら、EEPROMでデータを保存する機能をつけてみた。ESP8266でのEEPROMの実装は始めてであるが、見たところ簡単そうなので気楽にコードを加えて行ったところ、最初は大はまりにはまった。

 プログラムがひんぴんと落ちるのである。データを書き込むと、一瞬でメモリ破壊でシステムがリセットする。ためしにネットにある例題をコーディングすると問題ない。つまりハードではない。頭を抱えた。

 オチは簡単だった。要するに、データをStringで定義すると、EEPROMの中のデータ長が不定になるため(恐らく0バイト指定)、メモリ破壊になるのだ。Stringで定義してはいけない。探した限りでは、これまでの情報にこの落とし穴の指摘はなかった。

 文字配列にして長さを指定しても、実はまだメモリ破壊が止まらなかった。これは今度はこちらのミスだった。要するに、文字列の最後の'\0'キャラクターを長さに入れていなかったためで、少し多めにデータ長を指定してOKとなる。やれやれ。

Ws000006  このあと、待ち時間を入れないとおかしくなる(5ms以上必要)と聞いて、慌てて待ち時間を追加する。これでやっとのことで、画面で定義した新しいコマンドが電源を入り切りしても現れるようになる。このあたりも作りこめば、いろいろ工夫できるが、とりあえず、最後の受信部の書き直しに移る。

ウェブサーバーに受信部を追加する。大幅書き直しでこいつも難航(6/12/2018)
  Arduinoのプログラムステップ数も500を越えて、そろそろ開発の限界に近付いてきた(ひとつのモジュールの開発規模が500ステップを越えると制御不能になりやすい)。そういうことでもないが、気楽に、今までの受信部をとりあえず、全部取りこみ、タクトスイッチで受信を開始するロジックを加えたのだが、全体が全く動かなくなった。

 わかってみれば、単なる変数の初期化忘れが原因だったのだが、最初はなぜ動かなくなったのか全く見当がつかない。疑似コード作成をさぼって、適当にコードを追加した咎めである。こうなると、もう修復は難しい。

 一旦、入れたコードを#if 0と#endifで全部元へ戻し、少しづつコードを足して、その度に動くことを確認しながら入れるコードを増やして行った。結局、バグは先に述べた通り、単なるレコード数変数の初期化忘れという初歩的ミスだった。

 何とか動くようになり、このソフトは、以下の手順で学習した赤外線データを送ることが出来る。まず、タクトスイッチの押下で(準備OKのLEDが点灯)、赤外線リモコンの照射を待ち、正しく信号が入ると、LEDが点滅して無事受信されたことを知らせる。

 ここで、画面上の、「画面更新」というボタンを押すと、得られた赤外線コードが表示されるので、クリックすると、学習した赤外線コマンドが送信される。電源を切ってもデータを残すためには、この赤外線コードを、ブラウザーのコピー/ペーストで、コマンド新設の欄に入れて登録すれば電源を切っても残る。

Ws000007  学習したコマンドを直接EEPROMに保存する機能はまだ未開発だが、これ以上、公開を遅らせたくないので、見切り発車で公開の準備に入った。ソースコードの独自開発をせっせと進める。

ソースコードの公開(6/22/2018)

 そのうち、4年に一度のサッカーのワールドカップが始まった。PCに向かうより、TVの前で深夜過ごすことが多くなり、開発の速度はいやでも落ちる。しかも、全く勝てる見込みのなかったコロンビアに日本が見事な勝ち越しゴールで勝ったものだから、もう大変である。

 ということで遅れに遅れていたが、やっとのことでソースコードを公開できるまでになった。まだ未完成な所も多く、オリジナルのコードをすべて取り替えるところまで行っていない。プロの世界では、まずクロだが、まあ、お金をとるわけでもないので、とりあえず公開して様子をみることにする。
以下に、赤外線リモコンサーバーのスケッチを公開いたします。フォルダーがzipファイルになっていますので解凍のあと、適当なArduinoの開発環境に入れてビルドしてください。WiFiのIDとパスコードを加えるだけで、上記の画面が、192.168.0.33/で見えるはずです。

「sketch_IRserver.zip」をダウンロード

意:6/26以前にダウンロードした方は、もういちどダウンロードしなおし、前のものは廃棄してください。一部にバグがありました。

| | コメント (2) | トラックバック (0)

2018年5月14日 (月)

CNCマシンは少しお休み。赤外線学習リモコンに熱中

 CNCマシンで DC-DCコンバーター基板を切削して動作するところまで作りこみ、CNCマシンへの情熱は少しおさまった。

 電子工作を始めてから早いものでもう10年が経つ。正確には2007年10月、ブログの公開が2008年8月だが、前にも書いたようにCNC制御は究極の夢で、とても自分では実現できるとは思っていなかった。それだけに感動の思いはひとしおである。

 勢いに乗って、次々に基板切削にとりかかりたいところだが、なぜか手が止まった。当研究所のモットーは「実用」である。「何かに役に立つものをつくる」ということから言えば、今作りたい表面実装基板はない。

 実用にこだわると意外にテーマがないものだ。CNCマシンの他の応用、彫刻などの木工も、題材を探してはいるが、これはという決め手がない。レーザーカッターまで買ってあるのだが、テーマは見つからない。そう、何となく、みんな「ときめかない」のだ。

一度挫折した赤外線学習リモコン基板はどうだろう(4/15/2018)
 そこで、これまでのブログの記事を読み返しながらテーマを探していると、以前AVRで作って、うまく動かず途中で諦めた赤外線学習リモコンの記事が目に止まった。
(もともとの電子音量リモコン制作記事はこちら

 2年ほど前に、AVRのTiny861を使って、得られた受信信号をそのまま(RAWデータ方式)送り返す方式で、手始めに自作の赤外線による電子音量リモコンを動かそうとしたのだが、一番簡単なSONY方式にもかかわらず、全く動かなくて途中で投げ出した。エアコンのようなデータ量の多いリモコンを学習することはとてもじゃないけれど出来そうもなかった。

Pc043427  このあたりは最近どうなっているのだろう。ネットで「学習リモコン」をキーに検索する。すると最近のIOT時代を反映してか、予想以上にたくさんヒットした。2年前より明らかに多い。電子工作というよりこれは実用品のようで、商品の宣伝がやたら目につく。自作の制作記事も前より増えている。

 自作のターゲットマシンはWiFiモジュールのESP8266が多い。廉価だし、WiFi付きなので遠隔地からも簡単に制御が出来る。しかもプログラム開発にArduinoが使える。この前は意地を張って、ESP8266でなくわざとTinyを使って失敗したが、今度は素直にESP8266を使ってみようか。

 ソースコードも、あまりやせ我慢をしないで先人のものを使わせてもらおう。うまく動けば、この学習リモコンユニット基板をCNCマシンで作ればよい。これまでのリベンジと、CNCマシンの第二作、一石二鳥である。

 ESP8266はこの前使ったAVRに比べると格段に高性能である。クロックは80Mhzと、下手なARMより早いし、フラッシュやSRAMもメガバイトクラスなので気楽にプログラミングが出来る。AVRのときのようにメモリに気を遣う必要は殆どない。

 ただ、赤外線学習リモコンと言っても、色々な方式がある。一旦意味のあるデータにデコードしてから、それを再生するコード方式が一番確実だが、赤外線リモコンには多種類のコードフォーマットがあり、これをすべて網羅することは難しい。といって、記録したデータそのものを忠実に再現する方法(RAWデータ方式)は、以前、失敗していてトラウマがある(ロジアナで同じような波形だったのに全く動かなかった)。

 いずれにしても、ESP8266を変換基板なしに直付けして作る表面実装のリモコン基板なんかはちょっと格好が良いのではないか。どの方式にするかはあとからでも決められる。とにかく学習リモコンを作ることを次のテーマにすることにした。

受信部分はあっさり動いたが、送信部分は追加開発が必要(4/23/2018)
 RAWデータ方式でもコード方式でも、受信部分は同じなので、まずはESP8266を使った受信部分の開発を始める。ハードの準備はミニブレッドボードで簡単に組みあがる。
ソースコードは、ここ(東京お気楽カメラ)を使わせてもらうことにする。記事はここ

 ここは詳細な分析があり、送信部分は、RAWデータではなく一旦すべてのデータをデコードするコード方式だが、このコードを使ってサーバーからの送信もできるらしい。とても高機能だ。

 赤外線受信モジュールを用意し、ソースコードをネットからコピペし、新規スケッチに放り込んでコンパイルする。幸いコンパイルエラーもなく順調にビルドが出来た(当たり前か)。モニターのPCコンソールをつないで早速動作テストに入る。

Ws000003  おお、素晴らしい。赤外線パルスのマイクロセカンドのオーダーの数値がコンソールに並んだ。いや、さすがはESP8266だ。4バイト(long)や2バイトのバイナリデータを多数(5ケ)かかえた構造体の配列を400以上とってもびくともしない。AVRとは大違いである。

 次は送信部分である。このサイトは赤外線LEDへ流す電流を詳細に検討されていてとても参考になる。こちらもサイトにならって2本の赤外線LEDを直列に並べる。大電流の必要な赤外線LEDのドライブは、トランジスターでなく、前に使ったFET(2SJ377)を使う。

 すぐにでも送信のテストをしたいところだが、このサイトの送信は、AEHA(家電協)とNEC方式の2つのコード方式で、皮肉にもこちらの手元にある赤外線ボリュームコントロールのSONY方式はなく、新たな開発が必要である。

 いずれはSONY方式のコード化はしなければならないが(ネットを経由するとき)、結果を早く知りたいのでRAWデータ方式の送信部を追加開発することにした。あわよくば、全部をRAWデータ方式にしても良い。これでうまく行けば無敵になるからだ。

RAWデータ方式で電子音量リモコンが動いた!(4/25/2018)
 送信部分が完成した。テストに入る。受信部分で対象のリモコンからデータを受け取ったあと、何らかのトリガーで、マイクロセカンドオーダーで蓄積された時間間隔に従って忠実に赤外線をON/OFFし発信する(RAWデータ方式)。

Dsc01431  このユニットは電池駆動にする予定である。リモコンの対象が家の各部に散らばっていて、テストのためにはPCから離れなければならないからだが、トリガーのタクトスイッチなどの実装が手間なので、とりあえずはPCのシリアルコンソールからのキーボード入力で制御する。

 テストの対象は、まずは目の前にある以下の3つである。このあいだの自作の電子音量リモコン、それにPCルームにある10年以上前の古い三菱エアコンと、RaspberryPi用の10インチモニターのリモコンである。他の部屋のエアコン、TVやDVD、洗面所の温風ヒーターなどは現地に赴かなければならない。

 手始めは、因縁の電子音量リモコンである。送信する。全く動かない。ふーむ、やれやれ。今度も駄目か。赤外線LEDに並列に可視光線のLEDをつけているので、発信していることは間違いがない。オシロにもそれらしい信号(サブキャリヤー)が観測できる(ただし、端子の所で)。

 受信の時のデータはコンソールで確認できているので、あとは、赤外線LEDあたりを疑うしかない。参考サイト以外の赤外線リモコン関連の記事を見ていると、赤外線LEDを4つも並列に並べているところや、複数あるとかえって個体差でエラーが多いという指摘のあるサイトがあったりして、混乱する。

 2つあったLEDを1つに減らしたり、制限抵抗を10Ωに下げたり、LEDの照準を合わせたり試行錯誤するうち、おお、気が付くといつのまにか電子音量リモコンが反応し、ボリューム値が変わっていた。

少しづつ成功率が上がっていく。PWM方式も有効(4/28/2018)
 いや、嬉しい。今まで全く反応がなかったSONYフォーマットの赤外線音量リモコンが動く。百発百中というわけにはいかないが、今まで全く無反応だっただけに嬉しい。

 でも、ときどきESP8266そのものが暴走するし、成功率は余り高くない。オシロの波形をさらに良く調べたところ、意外にも、パルスの立下りがなまったサブキャリヤーの波形があらわれた。なにー、FETはトランジスタより高速だというのに、この波形はおかしいではないか。

Dsc01435  このFETは、前に動かなかったとき使っていたのと同じP-MOSのFET(2SJ377)だ。サブキャリヤーがちゃんとした矩形パルスになっていない。そうか、以前動かなかったのは、この原因もあるのだろうか。

 赤外線LEDのドライバーをFETからトランジスター(2SC1815)に切り替えた。オシロの波形はまだ少しなまってはいるが、FETよりは格段にましな矩形波パルスになった。成功率は残念ながら100%とは言えないが、それでも反応する率は確実に高くなってきた。 FETのスイッチング特性については、ここ(SUDOTEK)が詳しくて参考になる。

 それにしても、久しぶりのコーディングは、落とし穴に落ちてばかりで、結構な手間がかかった。たとえばwhileループの継続条件を決める変数を、最初のカッコのなかで、++や--で、うっかり変えてしまうと、そのあとの処理は、変わった後の変数が使われる。

 コーディングしているものにとっては、forループと同じように、i++や、i--は、繰り返し処理が済んでから、やってくれるものと期待しているけれど、そう甘くはない。プログラムは書いたようにしか動かないのである。このデバッグに数時間かかった。やれやれ。

 リモコンの成功率を高めるために、サブキャリアーをdelayループでなくanalogWrite()を使ってPWMでサブキャリアーを出すこともやってみた。これはうまく行った。オシロにもきれいな矩形波が並び、周波数も想定通りだ。暫くこれを使おう。

Dsc01434  成功率は徐々に上がってきた。好調なときは、ヒット率は90%まで達するときがある。しかし、100ビット以上あるエアコンはまだピクリとも動かない。うーむ、これはコード方式でないと無理か。

 それはともかく、ネットを探し回っているうち、以下のすごいサイトを発見した。ArduinoでなくAVRのTiny85で学習リモコンを作った方のURL。いやこれはすごい。詳細な解析結果と、データ圧縮まで考えた力作である。

ミニブレッドボードに携帯版の学習リモコンを作る(5/1/2018)
 SONY方式の電子音量リモコンに続き、NEC方式のRaspiのモニターのリモコンも問題なく動いた。エアコンはまだ動かないが、我が家には、まだ数種類のエアコンや、TV、DVDなどがあり、どこまでRAWデータ方式が有効か確かめておきたい。このため携帯版の学習リモコンの開発に移った。

 このあいだ買ったESP8266用の幅の広いミニブレッドボードに、もう一台のESP8266を載せ、送信LEDと受信モジュールを接続する。さらに、タクトスイッチと状態表示のLEDを追加した。シリアルコンソールがなくても制御出来るようにするためである。電源はリチウム電池で、このあいだのLDO(NJM2845)で3.3Vにする。

Dsc01430  赤外線の送信トリガーはタクトスイッチで、発信の確認は赤外線LEDに並列に接続した普通のLEDである。受信の方は、データを読み終わると別の状態表示用のLEDを点滅させ、その後、点灯したままにしてデータが蓄えられていることを示す。

 これで自宅のあちこちにでかけ実際のリモコンの動作を確認していった。その結果、TVのリモコンや、洗面所の温風ヒーター、さらに2Fの寝室のこの間、買い替えたばかりの三菱エアコンは、このRAWデータ方式でも見事に動くことが確認された。

 結局、我が家でこのRAWデータ方式の学習リモコンで動かないのは、10年以上前のエアコンだけとなった。このエアコンは1Fの居間のエアコンと全く同じであり、皮肉なことに最もこの機械を使う可能性の高い機器が残ったことになる。何となく気持ちが収まらない。成功した気分になれない。

 それに、小規模なリモコンでもコマンドシーケンスを持っているのがあるので苦労する。最近導入した台湾製のロボット掃除機などは、コマンドの種類は少ないのに、ボタンの2度押しなどでコードを変えているようで、単純に2回同じボタン信号を送っても正しく作動しない。 

ESP8266のWatch Dog Timerの作動から逃げる(5/2/2018)
 実験機が持っていた持病、時々暴走してしまう症状の原因がやっとわかった。プログラムを動かしている間に、いつのまにか、CPUが例外条件を感知してリセットしてしまう。いわゆる暴走だ。

 最初は測定中に配列に大きな値がはいってメモリでも壊しているのだろうと思っていたが、メッセージを良く見ると、そうではない。ループ中にWatch Dog timerが動いたというメッセージである。わけがわからない。

 こういうときはGoogle先生に聞くに限る。いつものエラーメッセージをキーワードにする検索で、すぐ原因がわかった。ESP8266のArduinoは、ユーザープログラムの裏でWiFiなどのシステムが動いている。従って、ユーザーが一定以上CPUを独占すると、エラーとしてシステムをとめてしまうらしい。

 つまり、While(1)などでCPUをループさせ、ディジタルピンの変化を監視するプログラムは、途中で、delay(0)とか、yield()などの関数をはさまないと、このトラップにかかる。

 理屈がわかれば対処は上の通り簡単だ。参考にさせてもらったサイトのソースに、delayループが各所に挟まれていた理由が始めてわかった。何故こんなところでms単位の待ちをいれるのだろうと最初は訝っていた。これを省いていったため暴走が始まったらしい。

赤外線センサーが時々ノイズを出す(5/3/2018)
 さらに、携帯版の学習リモコンで、折角、覚えさせたデータが失われる不具合(点いていたLEDが消える)が、頻発し始めた。赤外線センサーの誤動作で受信ユニットが動き、貯めてあったデータが失われるようだ。

 こういうときのためのオシロである。 赤外線センサーの出力にSingleトリガーをかけて、早速、調査を開始する。接続して1分も経たないうちに原因が判明した。赤外線センサーから、20μs程度の短いパルスが発生している。手持ちの2つあるセンサーの内の一つがノイズっぽく、もうひとつは比較的安定している。

 電源ノイズで、こういう現象が起きるようだ。Vccにコンデンサーと抵抗のデカップリングをすればなくせるらしいが、そもそもは、こういう短いパルスだけで、これまでのデータを消してしまう方も悪い。一旦、まともに得たデータ(カウント20以上)は、受信エリアとは別に残しておくソフト的な方法で解決した。シングルパルスのノイズは無視しておればよい。

 あれやこれやで、携帯型の学習リモコンも安定してきたが、どうもプロジェクトの終着点が見えない。この学習リモコンで何を制御するのかという明確な目的がないので際限がないのだ。何と言っても、我が家の主力エアコン2機が、この方式で動かないというのが致命的である。やっぱり、コード方式をやってみるか。

やっと主力エアコンが動いた。やっぱりコード方式でないとだめだった(5/8/2018)
 長い間の懸案、学習リモコンで難攻不落だった三菱の古いエアコンを動かすことに遂に成功した。コード化して送り直す必要があった。いやあ、長かった。上記サイトのソースコードのおかげである。感謝、感謝。

 秋月で入手した赤外線センサー(OSRB38C9AA) は、このサイトにあるように、どうもON期間が短く、OFF期間が長くなる傾向があって(およそ30μs)、それでも新しいエアコンや、ビット数の少ないTVなどの制御はRAWデータ方式でうまく動くのだが、我が家にある、10年以上前の古い三菱エアコンだけはこの方式ではガンとして動かなかった。 

 最初、センサーの立ち上がりと立下りの遅れの時間の差と考えていたが、オシロで調べたところ、明確な差は出なかった。パルス列の中で、差のあるところと全くない所が混在している。RAWデータ方式の明確な問題点は突き止められない。

 結局、これまで参考にさせていただいたソースコードを元に戻し、コード方式の実験に移る。さらにSONY方式を加えて、プログラムの確認が容易に出来るようにした。エアコンを激しくon/offすると機械に良くないということを聞いたからである。

 SONY方式は、ビット数が少ないのだが、データビットの論理が反転しており、ビット'0'と'1'の区別はON部分の長さである。従って、リーダーの直後のOFF区間からデータに入る。

 つまり、コード化にあたっては受信のところからデータ収集のやり方を変える必要がある。しかも、基準時間がNEC方式との差が10%以下(560と600μs)なのでどちらかを決めるのが難しい。エアコンのデコードとは本来関係がないのだが、ついSONY方式の実現の方に夢中になる。

 送信の方は少し楽だ。ソースコードの中で、送信するビットの部分を2つ作り、最初から独立させてしまう。独立させるのは、送出時間の誤差を少しでも減らすためでもある。ESP82366である。フラッシュは潤沢にある。

 できた。コード方式をSONY方式の電子音量リモコンで確かめる。よーし、動いた。しかし成功率は、RAWデータ方式よりちょっと良いくらいで、目を見張る程のことはない。さて、いよいよ、問題のエアコンのテストである。

 まず、リモコンをエアコンに読み取られないよう(エアコンが動くとステイタスが変わる)、陰で実験機に覚え込ませ、シリアルコンソールでデータが入ったことを確認して、祈る気持ちで、送信ボタンをON。

 ピーっと、言う音と共に、エアコンにスイッチが入った。やった、やった。2年越しの懸案が解決した。勝利の快感に酔いしれる。これだから電子工作はやめられない。このあと、ウェブサーバーへの移転にも成功したのだが、紙数が増えてきたのでこのへんで一段落としよう。

| | コメント (2) | トラックバック (0)

2018年4月14日 (土)

CNCマシン(3)遅れていたが、遂にプリント基板初切削に成功

 このところ順調に20日程度の間隔でアップしてきた記事が今回は遅れている。道草を卒業してCNCマシンの工作にやっと戻れたのに、ちょっとしたことでまた止まってしまったからだ。それでもその後やっとプリント基板の初切削に成功した。基板も動いて長年の念願がかなった。

前回のBluetoothによるUSBシリアルのワイヤレス化について(3/12/2018)
 本題に移る前に、先の道草の報告をしておこう。USBシリアルデータをBluetoothで送り、CNCマシンをワイヤレスで動かす話である。

 いくつかの障害を越えて、前回までにRaspberryPi Zero W(以降raspi0W)のUSBシリアルポートは、Bluetoothを通して、別のPCの仮想シリアルになった。接続の開始に少しコツがいるが、送受信とも安定して動いた。ただ、少し画面の展開が遅いのが気になる。Grbl_ble

 残るは、実機のテストである。raspi0Wの基板をCNCマシンの横に持ち込んで、USBケーブルをRaspiのホストUSBソケットに接続する。少し離れたPCではBluetoothの仮想シリアルポートをCNC制御ソフトCandle(Grblcontroller)のシリアルポートに指定する。このPCでCandleが動けばワイヤレス化は成功である。

念のため、PCのTeratermでCOMポート(com10となった)を立ち上げる。すると例の、
Grbl 0.9j['$' for help]
>

という、ArduinoのGRBLのWelcomeメッセージが出た。$などのコマンドのレスポンスも正常だ。良いぞ。次はいよいよCandleの始動である。立ち上げたあと、設定で、bluetoothのCOMポートを指定する。

 うーむ、つながったような、つながっていないような。画面では、ジョグダイヤルの画面部分が黒くなり接続しているようだが、反応はない。そのうちエラーメッセージが出て、画面の制御部分がグレーになる。たまにスピンドルが回り出すが、止めることは出来ない。

 こういう制御系でこの安定性ではとても危なっかしくて使えないのだが、根がしつこい性分である。あきらめきれずロジアナを持ち出して、シリアルデータをCNC2418のコントロールボードから採って調べてみた(ストロベリーリナックスがおまけにつけてくれた極小プローブが役に立った) Dsc01408

 その結果、シリアルデータは正しくPCからここまで送られているが、Candleがレスポンスを返していない。懸念したとおり送受信の反応が遅すぎ、タイムアウトとなっている公算が強いことが分かった。

 データの中継をしているRaspiでのPythonプログラムの問題である。プログラム上は単純に来たデータを送っているだけで余分なことは何一つしていない。従って、これをさらに高速化するには全く別のことを考えないといけない。残念ながらこれ以上は無理だ。ここは潔く諦めるべき時だろう。 Grblstart

 ということで、このUSBワイヤレスプロジェクトは、これで一区切りとする。PythonとBluetooth、それにRaspiでのリダイレクトの勉強が出来ただけでも収穫だと考えよう。

PCB(プリント基板)制作の進行に戻る(3/15/2018)
 MDF板の彫刻以来、止まっていたCNCマシンの工作を再開する。Easelで作ったMDF板の切削はとても順調に出来たが、こちらが主力でやろうとしている基板切削は、基板データの制作途中で止まったままだった。

 基板の回路は、これまで幾多の挑戦をしてきたDC-DCコンバーター基板である。KiCADで設計データは大体できていたが、サイズが問題だった。今まで汎用の表面実装基板で作ったものより小さくすることが難しくて、そのままになっている。 Ws000001

  久しぶりにKiCADを立ち上げ、コンバーター基板の小型化を再開する。DC-DCコンバーターは、これまで3個以上の基板制作をやってる。少なくともこれより大きくしたくない。入出力間のピン間隔が20.32ミリ(mil規格で8ピン)、全体のサイズで25X15ミリ以下が目標である。

 一時的に嫌気がさして先に進まなかったのだが、時間を空けたのが良かったのだろう、何故か順調に手が動く。ほどなく目標のサイズにすることが出来た。このソフトに慣れてきたのかもしれない。配線チェック(DRC)も問題ない。最後のステップ、べたアースにして状態を見る。

 あれえ、出力側のピンの周囲のべたアースがおかしい。ここはかなり部品を寄せたところだが、べたアースのパターンは前のピン位置のところを基準に描かれ、このままではショートしてしまっている。

 うーむ、前の部品データが残っていて悪さをしているようだ。そう言えばピンを移動した時、パーツエディターではピンのフットプリントと形状枠がずれておかしなことになっていた。この部品(2ピンヘッダー)を一旦削除し、新しいデータを持ってきたが、事態は改善されない。

 KiCADの不具合に間違いないが、今これにかかわっている時間はない。プリント基板エディターのデータをすべて消去し、回路図エディターからネットリストや部品抽出を再度やりなおし、そっくり基板エディターのデータを作り直した。

 何回目かの手順なので作業が早い。すぐ基板が完成した。べたアースはどうだ。大丈夫だ。余計なものはついていない。前のデータのミスも見つけられたし(片側のピンヘッダーがmil規格でなかった)、KiCADの習得にもなった。言うことはない。そう、所長は究極のプラス思考人間である。

Gcodeを出す工程に移る。聞きしに勝る複雑な工程に四苦八苦(3/19/2018)
 次はいよいよ難関のCAMデータ変換である。いやいや、これがこんなに大変とは思っていなかった。KiCADのガーバーデータ(基板情報を網羅したもの)からCNCマシンの制御コマンドGcodeに移すのは、膨大な手順が必要である。 Ws000002

 ひとつひとつが複雑な手順で出来ているので、沢山の設定が必要なのはわかる。しかし、途中の工程が多すぎる。でも、悪戦苦闘したおかげで今までちんぷんかんぷんだった事情がだいぶ理解できるようになった。ガーバーデータなどというCAM技術用語をそれなりに駆使できるほどになったのは大したものだと自画自賛する。

 面倒な理由は他にもある。KiCADからGcodeを出すには定番のルートというものがなく、多くのやり方があって何を選べば良いのかわからないことだ。素人にとっては複数の手段があることはかえって難しくする要素である。

 しかし、泣き言を言ってもいられない。せっせとウェブサイトを逍遥し、一番楽そうな方法を探求する。検討の結果、FlatCAMが一番主流なようなので、これで先に進むことにする。こういうのは善悪を抜きにしてやっている人の多い道を選ぶというのが一番という「ずるい」考え方でもある。

 FlatCAMの解説は色々あるが、ここあたりが一番詳しくておすすめである。こちらも詳しいが、ちょっとわかりにくい。

べたアースのGcodeが難しい(3/22/2018)

 べたアースの切削がやはり最大の難関だった。境界部分の切削パスは、カッターの切削幅だけを注意していれば良いのだが、べたアースを指定すると、どこにも接続されない島が残る。この残った部分を削除する、いわゆる、べた抜き銅箔部の削除(noncopper削除)手順が思ったように働かない。

 ゾーンを指定すると、その部分の島の部分を削除するパスを作ってくれるはずなのだが、ゾーンの範囲がうまく決まらず、ソフトがハング状態(ゾーンを調べまわっているのか)になったり、とんでもなく広い部分がごっそり指定されたりする。

 結局、KiCADから FlatCAM、さらに CandleのGcodeまで行き来してやっと切削できそうなGcodeデータが揃った。 べた抜き銅箔は、ゾーンではなく切削パスを追加する手順がFlatCAMにあるので、これをせっせと島になった部分に書き込んで、切削データを揃える。

 いやいや、一癖も二癖もあるフリーソフトである。何とか出来上がった。実際のデータをCandleに持ち込んで、エンドミルをつけない運転(カメラリハーサルか)を開始した。ふーむ、予想通り動いているようだ。 Ws000000

 それにしてもこの熱中ぶりは自分でも驚くばかりである。難しいから面白いのか、夢中でデータをいじる。うっかりすると、エンドミルを基板深さまで打ち込んで、いきなり走り出すGcodeを吐いたりするので、油断はならない(あっという間に刃を折っておしまいになる)。

基板(PCB)の初切削は思ったより順調。しかし穴あけができない(3/25/2018)
  リハーサルがうまく行ったので、本番の切削に進む。最後の工程である。基板切削なのでZ軸の補正をするheightmap機能が活躍する。切削の範囲は小さいのでheightmapのデータ収集は簡単に済んだ。 Dsc01411

 いよいよ、Vカッターを付けてPCB(プリント基板)の切削である。最初はカッターの位置をきっちり基板にあてなかったこともあり、遠慮めの切削となって銅箔を削るところまでカッターが行かなかった。

 切削の深さを少し増やし、Z軸の原点をさらに近づけた2回目は、うまく行ったのだが、掲載写真の通りY軸のステッピングモーターが最後の最後で空回りし、外周の切削が基板を横切ってしまって失敗した。3回の試行でほぼ考えているような基板が削れた。スピンドルは全速ではなく60%で音は殆ど気にならない。 Dsc01413

 切り離しまで行って重大な誤りに気付く。ドリルビットに換えようと手持ちのプロクソンのミニリューターのビットをとりだしたら、何とここのシャンクサイズは3.0ミリだった。CNCマシンは3.175ミリである。3ミリのコレットチャックの持ち合わせはない。

 やれやれ、このドリルビットは使えないのか。これは大誤算である。ドリルビットはこれを流用することにしていたので何の用意もしていない。あわててアマゾンで適当なドリルビットのセットを発注する。アマゾンだからすぐ着くと思っていたが送られてきた書類の到着予定日を見て目を疑った。

 何と、10日以上もかかるという。アマゾンだけど販売している会社は中国だった。うーむ、注文の時に良く調べるべきだったが、もう遅い。まあ、余り慌てても仕方がないので、到着までやり残していた工作で時間をつぶすことにする。

中国からドリルビットが届くまで、他の工作で気を紛らわす(3/27/2018)

 やり残している工作はいくらでもある。まず、このあいだESP8266でワイヤレス化したロボットアームの暴走抑止である。制御系の電池がへたるとアームが暴走するのを止めたい。このあいだ全てのモーターが動き出して、大騒ぎになった。

 この原因はわかっている。これまで参考にさせていただいたプログラムがもともと負論理だったが、これをそのままにしたので、3V以下でも動くモータードライバーに0のデータが送られて、すべてのモーターが全開になるというオチである。

 これを逆にするソフトの改修である。サーバー側の改修だけで済むはずだ。でも気持ちが悪いので、クライアント側のリモコンからもすべて負論理から正論理に換えることにする。作業は面倒なだけで単純な作業だ。

 ところが動かしてみたら全く不審な動きをする。動かそうとする部分が動かなくて他のアームが動く。えー、そんな器用なことを誰がする。あらためて慎重に工程を確認した。サーバー側のESP8266のコンパイルがテスト用にだけ済んで、本番のロボットアーム基板に換装するのを忘れていたことがわかる。 Dsc01415

 やれやれ年は取るものではない。コンパイルのときは、必ず最初のメッセージなどにコンパイルの記録を残しておくという鉄則を怠った咎めが早速結果に表れた。自戒、自戒である。

 次は、ブレッドボードに組んであったクライアント(リモコン側)をまともなケースに組み込む工作である。久しぶりにサーキュラーソーを持ち出して、基板の端を切り、ケースの上蓋にタクトスイッチの穴を開ける。これはこれで面白い。 Dsc01416_2

 電源スイッチは、最初手持ちのスライドスイッチですますつもりだったが、ウェブで小さなロッカースイッチを見つけて、急に気が変わり、Aitendoで沢山のロッカースイッチが売られているのを発見し、急遽、足を延ばして買いに行ったりした。

 こういうものは実際に手に取って調べるのが一番確実だからだ。Aitendoはウィークデイだったが、前にも増して客が多い。品数も増えたようである。付近には、全く別の電子部品の小売店ができたりして町が何となく以前と雰囲気が変わってきた印象だ。 Dsc01418

 やることがなくなって、レーザーカッターの準備まで始める。お馬鹿なことに買ってあったレーザーは0.5Wの一番小さいレーザーユニットだった。慌てて5.5Wの別のユニットを注文した。$100以上する。道理で最初に払った金額が小さかったわけだ。

届いたドリルビットは初回でポッキリ。スピンドルが回っていなかった(4/8/2018)
 ビットが届いた。基板に両面テープを貼り(基板カットまでしてしまったので)、マシンにセットして、以前の合わせ位置を頼りに位置決めをする。ジョグを動かして合わせるが、目視ではなかなか合わない。

 リハーサルを何度も繰り返し、何とか許容範囲に納まったので、意気込んで切削開始ボタンを押す。あれ、スピンドルが回らない。えー、という間もなくドリルビットは目的地まで動いて、静かに下がって行き、リセットスイッチを押す暇もなく、たわんだところでソフトはエラーで緊急停止した。 Dsc01414

 ステッピングモーターが高負荷で止まったらしい。リセットなど押す余裕など全くなかった。真っ赤なエラーマークを解除し、祈る気持ちでZ軸を上げたが、残念ながらドリルビットは数ミリのところで折れていた。

 スピンドルが回らなかった原因は、Gcodeではない。リハーサルのときに用心してモーターの回転を止めるため接続コードをはずしてあり、それを開始前に確認するのを怠った、誠に単純なチェックミスである。 Dsc01419

 まだ、ひとつも穴を開けないうちにドリルビットを失う。情けなさに何故か思わず笑いがこみあげてくる。やれやれ、あれだけ用心していたのにこのざまだ。たかだか一本¥100のビットだが、このあいだ1 万円以上入った財布を落とした時よりはるかにショックが大きかった。

 それでも気を取り直し、ビットを取り替えて(0.6 -> 0.5mm)工作をすぐ再開する(俺も懲りない男である)。今度は全速でスピンドルモーターを回しながら再開。無事、穴あけに成功した。それはそうだ、穴開けといっても今度の基板はわずか6か所である。 Dsc01421

 ただ慎重になりすぎ、穴あけの深さが足らなくて全部貫通していない。基板は作業盤からはずしてしまったので、リューターで、0.5mmの貫通と、ピン穴用の1mm穴あけをやる。これで、すべての工程は終了した。当研究所の初の基板切削は、ほろ苦い出発となったが、とりあえず一段落である。

一気に実装。よーし、一番性能が良いぞ(4/9/2018)

 基板切削終了のところでブログの記事にしようと思っていたのだが、部品のハンダ付けを試しに始めたところ、止まらなくなった。プリント基板は迷うことがないので次から次に進む。既に部品はビニール袋にすべて用意してあったのでなおさら止まらない。12個の部品実装はあっというまに終わった。 Dsc01422

 ここまできたら動くのを確認したい。これも我慢できない。ブレッドボードに基板を差し(これが使えるようにmilピッチにこだわった)、早速、これまでの基板とダミーロードのセメント抵抗も持ち出して実験を開始する。

 あれ、電圧が一定しない。一旦上がった出力電圧は、そのまま下がってしまって電源電圧と同じになる。早速、実体顕微鏡で仔細にハンダ付けをチェックする。すぐ不良個所が見つかった。電圧調整用の半固定抵抗のピンのひとつがどうもくさい。試しにピンセットで強く押すとピンが外れた。ここをしっかり固定しなおす。 Dsc01423

 よーし、所定の電圧が出た。さあ、これからが本番だ。ダミー抵抗で負荷をかけてテスト開始。これまでの自作基板では、250mAくらいまでは良いのだが、400mAを越えると出力が9Vを維持できなくなる。(7V程度に落ちる)

 さあ、こんどのやつはどうだ。うむ、250mAではこれまでのものと同様全く問題ない。400mAはどうか。やった。良いぞ。9Vに近い8.8Vで頑張っている。

 市販の大容量をうたったDC-DCコンバーターでも400mAを越えると、この程度の電圧降下はあるし、自作にしては上出来である。胸を張ってブログに報告できる。 Dsc01424

| | コメント (0) | トラックバック (0)

2018年3月12日 (月)

脱線が止まらない。RaspiでPythonに熱中

 CNCマシンのプリント基板切削まであと少しというところで、Raspberrypi Zero W(以降Raspi0W)に寄り道し、今度は、USBとBluetoothシリアルのブリッジプログラムを書こうとして、Python(パイソン)にはまってしまった。完全な横道である。

 PythonはRasPiのPiはPythonからと言われるようにRaspiの公式言語らしいが、これまで何となく縁がなかった。今や自慢にもならないが、所長は学生時代のFORTRANから50年間、ありとあらゆる計算機言語(今数えたら全部で25以上、アセンブラーだけでも8機種)をかじってきた(ひととおり動かした)。しかしPythonだけはまだ書いたことがない。

 人が騒ぐとかえって冷めるという「へそ曲がり」が主な理由だが、「蛇」嫌い(Pythonはニシキヘビのこと)ということもあるかもしれない。本屋でO'ReillyのPython本の表紙を見て何度かのけぞった記憶がある。

Normaladpter_1  冗談はともかく、ArduinoのUSBシリアルから、BlootoothのシリアルをつなぐRaspiでの仕掛けは、最初、スクリプトのリダイレクトで出来ると考えていたのだが、どうもリソースの競合で送受信は同時にできないような気がしてきた。実験レベルだが2つ定義するとはねられる。

 で、丁度良い機会なのでPythonを知っておこうと気楽にプログラミングを書き始めた。ところがこれが面白いというか、うまく動かなくてすっかり深入りしてしまったのである(CかPerlで書いておけば良かったと思っても後の祭り)。

RaspberryPi Zero Wでは何故か不調。stretchバージョンが原因か(2/21/2018)
 前記事の通りRaspi3では苦労の末、Bluetoothシリアルそのものは快調に動いた。しかしRaspi0Wではご機嫌が悪い。コマンドレベルでは特に問題なく動くのだが、Bluetoothのシリアル起動スクリプトをデーモンに入れて自動化しようとしたあたりから、つながらなくなった。

 最初は良いのだが、一旦接続を切ると2回目からは、Can't bind rfcomm socket address already in useというエラーを吐いて何をやっても進まない(再立ち上げ必要)。だいたい、socketなどコマンドでいじれるレベルではないのでバグ臭い。

 このメッセージをキーに検索すると、山ほど質問サイトがヒットする。海外が殆どである。決め手になるような対策は見つかっていない。特効薬はないようだ。wheesyあたりで良かったのが、Jessieで駄目になったというレポートがあるが、こんどのやつは、JessieからStretchでおかしくなっている。

 そのうち遂にPCのWin10側までおかしくなった。ペアリングのときにシリアルディバイスではなくてオーディオ機器だとプロファイルを勘違いしはじめる。何度か繰り返すとうまくいくときがあるというのが悩ましい。どうも、道具として使えるほど安定していない感じである。Stretch500x457  bluetoothの情報が、古いのと新しいのが混在し、どれを信じれば良いのかわからない。定番となるものがない。特定のハードウエアに特化し、CUIで動かす汎用的なhciconfigなどのコマンドはサポートが途切れているようだ。Raspi3では機嫌よく動いていたものが、Raspi0ではどうも不調である。

Jessie最終バージョンでRaspi0WのBluetooth完動(2/24/2018)
 Raspi3とRaspi0Wが使うOSは共通である。ハードもこのあたりは変わっていない(と思う)。違うのはOSのバージョンだけである。Raspi0WはJessieではなく最新のStretchを入れている。これがうまくいかない原因である可能性が高くなってきた。

 そこで、バージョンを落としてみることにした。 また、あの長時間のダウンロードかと覚悟していたが、偶然、Raspiの日本のミラーサイトがあることを発見した。いや助かった。早速、ここを試す。20分程度で1.5Gを落とすことができた。ひとつ前のJessieの最終版2017/7/10版でやってみる(ミラーサイトの一覧はこちら

 やっぱり、最新バージョンがおかしかったようだ。このOSでRaspi0のBluetoothは全く問題なくサイトの情報どおりにしっかり動いた。ただ、これはコマンド投入によるもので自動化はまだやっていない。しかし、これもうまく行く予感はする。

 とはいえ、デーモン化はRaspi3でもうまく行っていない。Bluetoothのペアリングと接続はもう問題なくなったが、実際のCOMポートがつながらない時がある。Raspi0のブリッジの部品化はなかなか難しい。そろそろCNCに戻らねば、色んなことを忘れてしまいそうだ(いや、冗談でなくて)。

いやあ気難しい。ディバイスファイルがなくなってもプロセスが残ってしまう(2/25/2018)   といいながら、諦めきれず、Bluetoothシリアルのトラブルシューティングを続けていた。段々、Linuxのことを思い出し、システムっぽいコマンドを打てるようになってきて、事情が明らかになってきた。

 Linuxは基本的にはマルチタスクなので、コマンドを終了したつもりでもプロセスが残っているときがある。プロセスを表示するのはps -auxというコマンドである。しかし、このコマンドはメッセージ量が多く、問題点をみつけることが難しい。

 しかし、Linux(UNIX)に慣れてきたので、ps -auxの出力をgrepでフィルターをかける
ps -aux | grep -i rfcomm などという芸当が出来るようになった(-iは大文字小文字を区別しない)。しかも一旦入れたらhistory機能(上向き矢印キー)で何度でも繰り返せる。

 やっぱりそうだった。ディバイスファイル(/dev/rfcomm0)が残っていなくても、プロセス(rfcommというコマンド)が残っているではないか。これがこれまでの不調の原因だろう。ほっておくとこいつはいくらでも増えていく。もしかすると前のトラブルもOSのせいではなかったかもしれない。

 通信の応答を待ち続けるrfcommのプロセスの残骸をps auxとkillでこまめに消して、Raspi0でも安定してシリアルが動くようになった。Raspiの接続要求コマンド(rfcomm listen ….)は、PCの端末から最初に接続を切れば、プロセスも消えることが分かった。

 手順を守れば(起動は、必ずRaspi側からリダイレクトコマンドを入れ、切断するときは必ずPC側から切る)、ほぼBluetoothシリアルは安定してつながるようになったが、何かの拍子で動かなければ、WiFiのSSHをPCで開いて手当が必要である。まだ自動化や部品化までは道が遠そうである。

 それにしても端末関係のLinux(UNIX)の処理は難しい。昔、LinuxのシリアルHOWTOを翻訳していてモデムと格闘していたことを思い出す。うまく動くと会社のLinuxマシンを電話で呼び出して自宅でデバッグすることが出来た。

閑話休題。電子工作以外の話(2/26/2018)

 システムのややこしい話が続いたので、たまには息抜きに電子工作以外の話題。この時期に避けて通れない確定申告の話である。意外に思われるが、所長の確定申告はだいぶ前から手書きである。会社の申告ならともかく、個人の申告などの作業量はたかが知れている。最初パソコンでやってみたがすぐやめた。

 一年に一回しかやらないパソコン操作である。覚えているわけがない。いちいちサイトなどで調べる時間は完全な無駄で、手で書いている方がよほど効率が良い。さらに重要なことがある。空欄に数字をいれるだけで確定申告が完成してしまうとそれに慣れてしまい、税制のしくみ(恐ろしさ)を知らずに過ごしてしまいそうだからである。

 税制そのものの構造は、そんなに難しいものではない。収入額から、その収入を得るのに必要な経費と、社会的な生活経費(扶養や保険控除)を引いた所得額に、その額に合わせた税率をかけて税額を出し、そこから給料などで既に収めた源泉徴収額を引いた残りが確定申告額である。

 しかし、この税額を決める過程が実に悩ましい。税額を出すだけなら単純な計算、所得額の大小に応じた税率をかけて、その金額から一定額を引くことで求められるが、ではこの所得額ではどれくらいの税率になるかを調べようとすると途端に難しくなる。

 税率と所得の関係は、税率 = 最初の税率 -( 一定額 / 所得額 ) という式で、これはグラフにすると1/Xなどで代表される双曲線で表される関数である。つまり税率は、所得額が195万以下は一定だが、195万以上は段階的な曲線を描いて最高税率の45%まで上がっていく。

 株の配当などは税率が一律なので、総合課税でも分離課税でも変わらないが、雑収入(講演料や執筆料)などは最初にとられている源泉徴収分が払いすぎなので申告したら戻ってくるのか、無申告のままの方が良いのかは、そう簡単には答えが出ない。総所得によって税率が変わるからである(本当は不労所得である株の配当こそ、収入に応じた高い税率とするべきなのだが)。

 給与所得者は大元で完璧に把握されており、必要経費も厳重な制限があるので税金を節約することは絶望的である(個人事業者申請をして抵抗することもできるが)。確定申告のささやかな楽しみの一つがどれだけ税金を安くできるか(脱税ではなく節税)なのだが、パソコン操作ではこの楽しみの仕組みを知ることなく終わってしまう。

 パソコンで言われるままに金額を入れていけば、すぐ税額が出るのは確かに便利だ。しかし、なるだけしくみを見せないで、向こうの都合の良い税額を決めようという魂胆が透けて見えて所長はいつも不愉快になる。

 それはともかく、確定申告の作業と合わせて、この時期忙しかったのが、冬季オリンピックの観戦だった。今年のオリンピックは何かと話題が多かった。メダルの数も最大のようでご同慶の至りである。女子スケートの団体金メダルなど、いかにも日本人らしい緻密な協同作業の成果である。

 瞬間芸の多い冬季五輪競技でカーリングだけは実にのどかな雰囲気で、大人気になったのも、うなずける。それにしても、メダリストと4位以下の選手の扱いがこんなに違うのは、はたから見ているとお気の毒としか言いようがない。なぜこんなに違ってしまうのか、人間の心理を分析する必要がありそうだ。

 それはそうと、CNCマシンがそろそろ埃をかぶっている。早く工作に戻ろう。

Pythonのプログラミングを始める(3/2/2018)

  Raspi0wのbluetoothシリアルはまずまず安定してつながるようになった。一方向だけなら、リダイレクトだけで、USBにつないだESP8266の時報(DS3231を使ったやつ)がbluetoothを通してPCの端末(TeratermのCOM10)に表示されるようになった。Dsc01401

 しかし、Raspi3でも経験した通り、もう一方のPCからESP8266へ返すコマンド類は出すことが出来ない。/dev/XXXを2回リダイレクトに使わなければならないからである。一方向をリダイレクトして、もう一方を指定すると「そのファイルは使用中」というメッセージではねられる。

cat /dev/AAA > /dev/BBB
cat /dev/BBB > /dev/AAA  ====>ここでエラー

まあ、考えてみれば当たり前の話で、何かうまい回避策があるのかもしれないが、ウェブにはそれらしい情報は見当たらなかった。これはやっぱりプログラムを書かねばならないか。まあ、たいしたプログラムではないから、Cで書いてもそう手間はかからないだろう。

 ここで前から気になっていたPythonが頭に浮かんだ。こいつはマルチスレッドも出来るようだし、マスターする絶好の機会に恵まれた感じがする。もともとRaspiを始めたのは、ArduinoのUSBをワイヤレスでつなぎCNCマシンを離れたところから動かそうという寄り道で、Pythonはさらに別の横道になるが、もう止められない。Pythonを学ぶ機は熟したようである。

情けない。PythonのLチカでお粗末ミス(3/8/2018)
 PythonはRaspiでは標準装備だし、PCにもいつのまにかPythonが導入されていた(何かのパッケージをダウンロードした時、勝手に入ったものらしい)。勉強するのに情報は事欠かない。ネット上にはPython情報が溢れかえっている。 Pythonraspi0

 利用させてもらっているのに文句を言うのは失礼だが、残念ながら殆どが初心者か初級者向けの入門コースの情報で、すこし難しいことをやろうとすると、途端に少なくなり、海外まで足を延ばさないと必要な情報が得られない。

 まあ、これはどの分野でも同じで覚悟はしていたが、pythonはコンピューター言語の入門コースという触れ込みらしく特に多い。Pythonが入門用の言語というのは、実は大いに異論があるのだが、ここでこれにこだわると話が完全に発散してしまうのでこれ以上はやめておく。

 ひとわたりPythonを調べてシリアルブリッジくらいなら簡単に書けそうなことはわかった。でも教えて頂いたサイトの先人の方々を無視するのは失礼になる。敬意を表して定石通りLチカから始めることにした。

 ところが、これが難航したのである。デバッグに半日かかった。原因は、全く単純なコーディングミスである。情けないというか、ヤキがまわったというか。年はとるものではない。ここに書くのもお恥ずかしいミスをまあ聞いて下さい。

 LチカなのでI/Oピンを直に触る必要がある。RaspiのPythonでは、GPIOの制御はRPiというライブラリがあって(他にも色々ある)、これをimportすることになっている。

import RPi.GPIO as GPIO 

とやってモジュールを組み込み、数行ばかりの簡単なLEDの点滅のプログラムを動かそうとした。すると、

Traceback (most recent call last):
  File "led-flash.py", line 4, in <module>
    GPIO.setmode(RPi.GPIO.BCM)
NameError: name 'RPi' is not defined

というエラーで止まった。何い、GPIOを操作するRPiライブラリーが入っていない?というのでいくつかのRPiライブラリーを入れる手順を実行し、すべてエラーもなくインストールされた。しかし、ことごとく同じ上記のエラーではねられる。最後はpythonパッケージの入れ替えまでやった。勿論それでも動かない。

Dsc01407_2 このエラーステートメントを注意深く読めば、こんなに大騒ぎしなくても良いのだが、pythonの事情に明るくないので、うっかり見過ごしていた。最後の一行だけしか目に入っていない。

その前の行に問題の一行がある。GPIO.setmode(RPi.GPIO.BCM)でRPiが定義されていないと言っている。

そう、ここのRPiは不要というより間違いである。前に、import RPi.GPIO as GPIOとしているのだから、モジュールは、RPi.RPi.GPIOを探すことになる。

 このRPiを削除してRaspi0Wは何事もなくLEDの点滅を始めたことは言うまでもない。情けなくて暫く立ち上がることもできなかった。このショックから立ち直るため、最初からpythonの勉強をすることを決意し、参考書まで買ってしまった。 Dsc01405

 「エキスパートPythonプログラミング」である。しかし、これはまた完全に失敗した。全く高度すぎて歯が立たない。絶版になっているらしく、古本でも新品より高い。いつものことながら、参考書の選定がすべて間違っている。負け惜しみをいうようだが、中級向けの参考書って本当に少ないと思う。

Pythonはマルチスレッドにして送受信とりあえず開通(3/10/2018)
 pythonは対話形式のインタープリターがご先祖のようで、キーボードなどの入力ディバイスの操作は意外にも機能が揃っていない。画面の自由な表示や、ゲーム機のようなキーボードの押下のような動作は標準機能にはなく、すべて拡張機能である。

 例えば、シリアルの送信側のキー操作は、キーが押されたタイミングを検知してプログラムを動かさないとキー入力を待っていたらプログラムは先に進まないことになる。ところが探し回ったが、Windowsにはあるキーが押されたことを知らせる機能がLinux/Macにないのだ。 

これや、これのような拡張機能はあるが、一定のキーの押下は検知できてもすべての印字可能なキーの動きをセンスしてくれる一般的な関数が見当たらない。

 こうなったら、無理にシングルスレッドにこだわることもないだろう。Pythonは一つのプログラムで複数のスレッドを動かせるらしい。 調べてみたら、それほど難しくなさそうだ。

 実際に入れてみたらPythonのマルチスレッドは思ったより簡単で、すぐ動いた。さすがPythonである。スレッドを2つにしたおかげでループの中の処理も非常に簡単になった。シングルスレッドでは、中のループを途中で止めないような細心の注意が必要だが、別々なら何の配慮も必要ない。ただ、相手の送信を待ち、データが入ってくれば送るだけで済む。

 テストしてみる。順調に双方のシリアルポートが開き、USBにつないだESP8266の時報プログラムがBluetooth経由でPCのターミナル(Teraterm)に出てきた。次はPC側からESP8266の時刻の較正入力である。

 出た。しかし、行送りがうまく行かないせいか文字の出方がおかしい。送受信とは全く別ルーチンで動いているはずなのに、送り側の文字を入れないと案内のメッセージが出てこない。ひとつづつ遅れるので較正のプロセスはうまく動いていない。 Dsc01404

 しばらく、これで悩んだ。サイトを巡り歩いているうちに、原因らしいものをみつけた。pythonのコンソールによる出力はバッファリングされているというのだ。つまり、ブランクや改行を伴わない裸のデータを出力するときは、

sys.stdout.write()

というステートメントを使うのだが、これだけではまだのバッファリングされて本当の画面には出てこない。以下のコマンドが必要だという。

sys.stdout.flash()

要するにキューに溜まったデータを常に吐き出しておかないとおかしくなる。

 この一行を加えて、Raspi0Wのシリアルブリッジは無事、完成した。暫く、USB側に色々な機械をつないで遊ぶ。至福の時間である。まだ、実際のCNCマシンとCandle(GBRL)でのテストが待っているが、とりあえず一段落である。いやいや今回も波瀾万丈だった。

以下は、当研究所初めてのPythonプログラムです(USBとBluetoothのシリアルをブリッジする)
Raspiのコマンドないしはスクリプトとしてお使いください。Bluetoothのシリアル化と、ポートの監視(listen)コマンドについては、こちらや、こちらのサイトが詳しくて親切なのでそちらをどうぞ。

#!/usr/bin/env python
#coding: utf-8
#
#  LABO Gataro   3/11/2018
#  Serial bridge between 
#  USB and Bluetooth
#
import serial
import time
import thread
import sys
TIMEOUT = 0.0
def comOpen(tport):
    try:
      comtmp = serial.Serial( port=tport,
      baudrate = 115200, bytesize=8,
      parity = 'N', stopbits = 1,
      timeout = TIMEOUT, writeTimeout = TIMEOUT )
      return comtmp     except:       print "Failed Open /dev->" + comtmp.portstr def sendtxt() :
     ble.reset_input_buffer()
     while True:
       kb = ble.read(1)
       com.write(kb)
       com.flush()
       if kb == '~' :
         print "..TX Stopped.."          sys.exit() #------------------------------------------------------
def main() :
   com.reset_input_buffer()    ble.reset_input_buffer()    thread.start_new_thread( sendtxt, ())    print "Threading start(sendtxt)... "    line = ""    try:      while True:        if com.in_waiting > 0 :            line = com.read(1) #           sys.stdout.write(line)  # test print on Raspi #           sys.stdout.flush()            ble.write(line)    except:       print "All thread stopped..." #======================================================= if __name__ == '__main__' :
  com = comOpen('/dev/ttyUSB0')   print "USB Comport Opened... " + com.portstr   com.reset_input_buffer()   ble = comOpen('/dev/rfcomm0')   print  "BlueTooth Com opened..." + ble.portstr   main()

| | コメント (6) | トラックバック (0)

2018年2月21日 (水)

CNCマシン(2) 切削を始めるも、Raspi Zero Wへ思わぬ脱線

 中華CNCマシンCNC2418のプロジェクトは順調に進んで、遂に初切削(ただしMDF板の彫刻)に成功したのだが、プロジェクトは突然違う方向にそれてしまった。本人も驚く脱線ぶりである。どうしてこんなことになったのか。詳しいいきさつは本文で。

Normaladpter_9 エンドミルの種類が多すぎて迷う(2/2/2018)
 CNCマシン導入の元々の目的はプリント基板の切削なのだが、初切削にふさわしい基板データがまだ用意できていない。こういうこともあろうかと練習用にMDF板を買ってあった。これで切削の練習をして経験を積みながら基板データの完成を待って、本番切削に進もうという計画である。

 ところが、CNCキットの付属エンドミルは基板切削用のVカットのカッターで、サービスについてきたエンドミル10本も、これと全く同じものだった。練習はMDF板の彫刻である。Vカッターは彫刻には使えない、別のエンドミルが必要だという(これは見映えがしないだけということがあとでわかったが)。

 というので、ウェブで初心者にも使えそうなエンドミルを物色する。ところが、エンドミルと一言で言っても、膨大な種類があり何を選んで良いのか全く見当がつかない。価格もてんでんばらばらである。10本¥1000台から、一本が¥3000以上(勿論、趣味向けでも)のものまであり途方に暮れてしまった。

 何を彫るのかが決まっていないのだから当然と言えば当然なのだが、それにしても値段の幅が大きすぎる。Aliexpressなどの中華サイトだけかと思ったら、国内のアマゾンや、楽天、ものたろーなどの国内サイトも似たようなもので、安いものも沢山ある。

 少なくとも中華サイトは何が送られてくるか予想がつかないので注文する気にならない。基板切削用のエンドミルといえば、オリジナルマインドという日本のホビー用CNCフライス盤を作っている会社の「土佐冒典(とさまさのり)」というエンドミルがピカ一のようだ。しかし、高価で¥3000近くする。ただし今探しているのは彫刻用のエンドミルなのでこれはまだ相当先の話だ。

CAMソフトEASELでMDF板の彫刻に挑む(2/5/2018)
 迷った挙句、アマゾンでとりあえず1ミリから2ミリの安いエンドミルセット(タングステン 10本¥1650)を適当に注文し(どうせすぐ何本も折るだろう)、それが来るまでMDF板の彫刻の準備をすることにした。Dsc01399

 作業盤にMDF板を両面テープとクランプで固定しで、もういちどレベル出し(heightmapによる)をする。今度はケント紙(0.5ミリくらい)を低いサイドの側に挟んでMDF板をクランプで固定し、heightmapを出してみる。おお、誤差は0.3ミリ以内におさまった。これで彫刻の準備は整った。

 何を初切削するかが問題である。このCNCキットには、中国簡体字の彫刻サンプルがついていて、皆さんはこれを試験切削に使われている。所長にはちょっと変なこだわりがあって、これを初切削のデータにしたくないと思っていた。中華製品にすべてが飲み込まれていくような感じに反発があったからだ。

 とはいえ、自前の彫刻用CAMデータの用意があるわけではない。今までKiCADで基板用データの開発ばかりやっていて、そこまで手が回っていない。慌ててみなさんのサイトを再び訪れて、適当なCAMソフトを探す。しかし、これも沢山種類があって何が良いのかすぐには決められない。

 泥縄的に調べた結果、どうもEASELが一番楽にCAMデータが作れそうな感じだったのでこれを選んだ。このソフトは、ダウンロードするのではなく、ウェブ上のアプリケーションになっていて、Fusion360のような壮大な3Dモデリングソフトではなく、2D(というか2.5D)ソフトであり、出来ることは限られている。

 しかし、出来上がった図形の切削の部材とエンドミルの種類を画面上で選んで、出来上がりを確認できるところが素晴らしい。ここでVカットのカッターと普通のエンドミルの基本的違いを知ることができた。要するにVカッターは深く掘れば彫るほど切削幅が広がるというだけの違いである。1stvcut0206

 元々このソフトは、自社のデスクトップCNCマシン(Shapeokoというらしい)の付属ソフトだったようで、文字は英字だけで日本語対応はしていない(と思う)。まあ、テスト用なので深入りせず、EASELのシンボルマーク(と思う)のテレビとYGataroという文字を選んだ。

EASELのデータでCNC初切削に成功(2/6/2018)
 いよいよ切削だ。スピンドルにコレットチャックでビットを挟めるER11を装填する。やけに固いと思ったら、ウェブ上ではこのチャックは熱嵌合と言って、チャックを高熱にして、はめ込むのだそうだ。今さらそれを知ってもそんな大掛かりなことはすぐにはできない。Normaladpter_8_3

 それでも、少し力を入れるとシャフトに少しづつ入っていくようなので、10ミリ近く入ったところで試しにスピンドルを回してみた。いやだめだ。80%の回転数から機械全体が振動するくらいの回転むらが起きる。ER11とスピンドルの回転の中心が合っていないからだろう。

 騒音というより機械に影響が出るくらいの振動なので折角買ったER-11だが、あわてて元のカプラーに戻した。その後もう一度トライして、今度は軸が合ったようで、最大回転でも全く問題なく回転するようになった。かなり奥まで入れたからかもしれない。Normaladpter_7

 注文したエンドミルはまだ届いていない。キット付属のVカッターを装填する。Vカッターの切りしろはEASELの出来上がり画面で確認しているが、本当に画面のような彫刻ができるかどうかはわからない。ドキドキする時間である。

 ソフト(Candle)を起動し、EASELで作ったCAMデータを読み込む。このCAMデータは、一度テキストエディターで、スピンドルの回転数を全速のS1000から、S600に落としたデータだ。騒音を気にして細工をした。

 スタートボタンを押す。スピンドルが回り始めた。回転は60%なので音は全く静かである。何度かシミュレーションした通り、Vカッターが進んでいく。5分足らずで削れた。トラブルなし、木屑というより、木の粉がこんもり、切削あとに残った。Normaladpter_4

 もっと木粉が飛ぶと思ったが、MDF板の木粉は周囲に止まっている。掃除機で吸い取ると、出ました、出ました。EASELの出来上がり予想画面と全く同じような彫刻部分が鮮やかに浮き出た。いやあ、感激の瞬間である。早速記念撮影する。遂にがた老AVR研究所はCNCによる切削という新しいページを加えた。

KiCADの開発に戻るが満足できるデータが出来ない(2/8/2018)
 アマゾンからエンドミルが到着した。しかし彫刻の第二作のデザインがなかなか見つからない。凸版的なロゴを作って自宅の門の照明部分に飾ると面白いと思っていたのだが、これは結構難しい。一方、KiCADのプリント配線基板の切削データは、まだまだ満足すべきレベルに達しない。

 前回も書いたがKiCADの操作が、あのEAGLEに勝るとも劣らず難しいのだ。題材は、このあいだのトランジスタの回路基板ではなく、以前苦戦した表面実装基板、DC-DCコンバーター回路にして実用化を狙ったのだが、次に紹介するような落とし穴に次々とはまり、先になかなか進めない。

●配線幅を変えられないのは定義していないだけ
 配線の線幅を決めるサイドメニューで、ネットクラスで規定するもの以外の幅に指定できない。何故だ何故だと騒いでいたら、デザインルール定義の中の「グローバルデザインルールのカスタム配線幅」に欲しい線幅を入力するとサイドメニューにそれが反映されることがわかった。こんなの教えて貰わない限り絶対に不可能な作業手順である。

●カーソルが外へ出て行かない
 KiCADのプリント基板エディターは、ほとんどのコマンドが右クリックでサイドメニューを出し、さらに下位のメニューに行く構造になっているが、そのメニューを全部閉じてからカーソルを画面外に出そうとすると、その前のオペレーションを引きずり外へ出て行かないときが度々ある。

必ずではなくて、時々なるので、これはどうもバグくさい。試行錯誤の末、画面上の何もない所でダブルクリックを無駄打ちすると解消することを発見した。スタックされていた複数の操作が溜まっていて解消されていない感じだ。

●配線がうまく行かないときのエラーメッセージが出ないことが多い
 大抵はネットリストに反する配線をしようとしたときか、またはDRC(デザインルールチェック)に反する配線をしたときに起きる。エラーメッセージが画面下部に出る時もあるが、殆どは単に配線が完成しないだけで何の反応もない。慣れないうちは何が原因かわからず頭を抱えていた。

●ライブラリの読み込みや検索を不用意にかけるとメッセージなしで応答が返ってこない
 CPUに負担のかかる処理は普通、砂時計などの処理中サインが出てユーザーにその状況を教えるものだが、KiCADでは何のメッセージもなく、まるでフリーズしたかのように動きを止めてしまう。何も動かないのであせって他の処理を次々にやってさらに混迷を深める事態になる。

●部品ライブラリの構造が今一つ理解しにくい
 これは慣れていないだけとも言えるが、ライブラリの構造がパブリックなものと自分用のもの、そのプロジェクト個別のものとに分かれており混乱する。新しい部品を作るのに四苦八苦した。Ws000008_2

 以上は、主だった暗礁だけで、まだわからないことは沢山ある。それでも悪戦苦闘の結果、何とか、それらしい基板設計図ができた。しかし寸法を測ってみると既存の手配線の表面実装基板に比べてあまり小さくなっていない。あれだけ苦労して作ったのにちょっとがっかりである。

 小さくする手段が見えない。べたアースは簡単に出来るし、出来栄えは悪くないと思うのだが、どうも切削に向かう気力が生まれてこない。

突然、RaspberryPi Zero Wを発注してしまう(2/9/2018)
 そんなとき、とあるサイトでArduinoのUSBケーブル部分をBluetooth化したArduino基板が紹介されているのを見つけた。ご存知のように中華CNCマシンの制御基板はArduinoである。(本家はここ

 現在CNCマシンのArduinoのUSBケーブルは、すぐ脇にあるノートPCにつながれ、ここでCNC制御ソフトCandle(GRBL)が動いている。一方、EASELやKiCADなどの制作ソフトは、4~5m離れたメインPCにあり、試し切削のときは、USBメモリでデータを持ち運んだ。

 ネットワークドライブでつなげば、少なくともUSBメモリのような原始的なことはしないで済むのだが、USBケーブルをBluetoothで無線化すれば、メインPCにCNC制御ソフトを入れて動かすこともできる。

 CNC切削の手元に制御できる画面がないのは緊急時に困るが、それはそれとして、USB接続の機器を無線化できるというしくみに何故か心が強く惹かれてしまった。

 そういえば、最近売り出されたRaspberryPi(以降 Raspi)の新しいシリーズに、WiFiとBluetoothがついているRaspi Zero Wというのがあってこれは10ドルという破格の価格だ。日本でも少し高いが通販で手に入る。

 無線機能のついているRaspi 3でUSBとBluetoothをつなぐシリアルのブリッジを作るのはどうみても無駄な気がするが、このRaspi Zero Wなら千円ちょっとである。それに対して、bluetooth化したArduinoは¥5000近く。しかも、今手持ちのCNCマシンのArduinoはモータードライバーと一緒の基板に組み込まれているので、これを活用することは出来ない。

 CNCの基板切削への意欲より、このUSBをBluetoothでワイヤレスにしたいという意欲の方が優り、気が付くとスイッチサイエンスの販売予約のボタンをポチっとしてしまっていた。Raspi Zero Wは、国内ではまだ高いが(ケースなどを抱き合わせで買わされて¥3000以上)、スイッチサイエンスだけは10ドルに近い、¥1300台で一人一台の予約販売をやっている。

RaspberryPi 3でbluetoothシリアルの実験(2/10/2018)
 予約販売というのだから少し日がかかるだろう。待ちきれずに、同じ機能を持つRaspi3で、USBの無線化を実験し始めた。USBと言ってもArduinoのUSBはシリアル変換ICが入っておりUSBの中身は、単なるシリアル通信である。

 やり方をすべて解説してくれるサイトは見つからなかったが、Bluetoothのシリアル化(SPPプロファイル定義)は沢山のサイトに解説があったので、情報には不足しなかった。しかし、これが結構難儀したのである。

 要は、RaspiのホストUSBで、USBのシリアルデータを受け取り、BluetoothのシリアルディバイスにリダイレクトするスクリプトをRaspiで動かせばそれでOKなはずなのだが、まず、BluetoothのシリアルポートがWindows10でうまく動かない。Ws000006_2

 Win10のBluetoothドライバーは、昔買ったドングルについていたBlue Soleilというサードパーティのもので、シリアルポートを開くことは簡単に出来、PC上にはcom10という仮想ポートができた。しかし、Raspiとつながらない。

 ペアリングまでは順調に進むのだが、肝心のシリアルの接続がOKにならない。Rasp側のBluetooth仮想シリアルデイバイスrfcomm0がactiveになったり途中で切れたりする。切れたあともrfcomm0が居座り、なかなか消去できず、ペアリングそのものもおかしくなる。

 何度か繰り返すうち、Windows側はcom10だけでなく、時々、com4とかcom5というポートが現れて、どうもbluetoothの下位部分はつながっても上位のシリアルポートの部分がうまく動いていない感じがする。

 Bluetoothのトラブルシューティング情報の中に「Win10は標準でBluetoothのドライバーを持っている」という文言があり、ここで閃いた。もしかするとBlue Soleilのドライバーがぶつかっているのかもしれない。Ws000009_2

 このドライバーをアンインストールして再度試してみたら、ピンポーン!これがあたりだった。ぴったりCOM4とCOM5がディバイスマネージャーに「Bluetooth標準シリアル」として登場した。不思議なことに、これで、Raspi側のシリアルディバイスのrfcomm0も安定して途中で切れたりすることもなくなった。

 Linux(UNIX)のすごいところは、こういうディバイスファイル(/dev/XXX)が出来れば、コーディングなしに、パイプやリダイレクトという考え方でデータのやりとりができるところである。このあいだのウェブカメラ /dev/videoなどと全く同じである。

Usb

echo "Hello World" > /dev/rfcomm0 

とやれば、Windows側のCOM4にHello Worldが送られる。TeratarmなどでCOM4を開いておけば、このメッセージが出る。

Tertermで、キーボードを打つと、PCからデータが送られてディバイスファイルに貯められ、

cat /dev/rfcomm0

で、Raspiの標準出力(ここではコンソール)に出力される。

と、簡単そうに書いたが、Linuxに凝っていたのはもう20年近くも前のこと。こういう単純な操作すらすっかり忘れていた。暫くはGoogle先生に頼りきりで、夢中になって勉強する。

Ws000007_2  それでも、RaspiにこのあいだのESP8266のリアルタイマークロック(DS3231)のUSBシリアル出力をRaspiにつなぎ、リダイレクトでBluetoothのシリアルを経由してPCのTeratermに時刻が表示されたときは感激した。これで残すはRaspi内のスクリプトの作成である。

RaspberryPi Zero Wのインストール(2/13/2018)
 スイッチサイエンスのRaspi Zero Wは、会員のみの予約販売で一人一個までという厳しい条件である。会員になるのは無料なので会員になって注文した。届くまで暫く待たなければならないだろうと覚悟していたのだが、申し込んだら2日もしないうちに発送の連絡が入った。なーんだ。

 ほどなく郵便でRaspi Zero Wが届いた。早速インストールにとりかかる。RaspiのOSは最近、jessieからstretchというコードネームのバージョンに上がったようだ。今回は今のところ単なるブリッジが用途なので、8GBのSDカードに指定通りカーネルイメージを入れることにする。

 このカーネルイメージのダウンロードは時間がかかった。混んでいるのだろう。200KB/秒程度の速度しか上がらず、1.4Gを落とすのに2時間余りかかった。最初、ウェブ記事を参考にキーボードやディスプレイなしでインストールしようとしたが、どうもうまく動かない。

 Raspi Zero WのHDMIコネクターはミニということもあってディスプレイにつながらない(マイクロは持っているが)。仕方がないので量販店に駆けつけて調達し、画面を見てみたら、画面上のダイアログでキーボードの入力を待っていた。

 こうなれば以前のRaspi3からキーボードを持ってきて先に進むしかない。結局、キーボードなしのインストールは実績を積むことが出来ず、普通のインストールとなってしまった。Normaladpter

 やっと、Raspi Zero Wが立ち上がった。Raspi3に比べれば画面は相当遅く、全体にのったりとした動きだ。CPUの数も少ないし、クロックも低いので当たり前と言えば当たり前だ。まあこれは、こういったガジェット(小物)用だから問題ない。

 このあとはRaspi Zero Wのスクリプトの制作の話になるのだが、紙数も増えてきたのでこのあたりで一区切りとしよう。

| | コメント (4) | トラックバック (0)

2018年2月 2日 (金)

CNCマシン(1) 初切削の目前で電源故障。代品はすぐ届く

 予想通り、がた老AVR研究所のブログはCNCマシン導入一色の制作記となった。久しぶりの大型プロジェクトである。今まで夢でしかなかった表面実装チップを変換基板なしに直に実装する基板が自前で出来るのである。

 自分は化学系ではないので基本的に薬品(特に液体)を使うのは苦手で、どうしてもプリント基板が必要な時は、海外発注で何とかすませてきた。それが、自宅で自由に銅箔面を削って基板を作れるのである。

 しかも、今度のCNCマシンはかなり強力な(5.5W)レーザーカッターまでつけた。安いので、はずみでポチったのだが、これを使えばこのあいだのロボットアームもフレームから自作できるかもしれない。夢は限りなくふくらむ。ただ、実際に動かすまでやらねばならないことは数限りなくある。

 以下は、この2週間の活動記録である。残念ながらまだ切削はできていない。

ダイヤルゲージでフレーム面の水平を調べる(1/16/2018)
 ダイヤルゲージをスピンドル軸に固定し、水平レベル(Z軸)を測定する。何のために買ったのか思いだせないダイヤルゲージだが、取り出してみたら、ウェブに出ているみら太氏のような高級品ではなく最小読み取り目盛りが0.01mmの普及品だった。

Dsc01313  スピンドルへの固定は、手持ちのあり合わせですませる。当て板に使っていた蒲鉾板の端切れに6ミリの穴を開け、そこにダイヤルゲージを固定し、木材接着用のクランプで板をスピンドルモーターの空洞を使って固定する。簡単に固定できた。

 ジョグで工作面上を動かし測定する。工作面(作業盤)はV-slotなので溝がある。Y軸の移動のときはダイヤルゲージがそこで引っかかり、送りねじが空周りを始めたりして慌てる。モーター保護のためカップラーの締め付けを強くしていないためである。リミットスイッチを早くつけなければ。

 測定の結果、X軸方向が結構歪んでいて1ミリ以上の誤差があることがわかった。単調変化なので、これはXZ軸のフレームの左右が傾いているからに違いない。一方、Y軸の誤差は微妙だ。全体では0.3ミリ以下なのだが、最初の1/4部分で0から0.3に上がり、その後、変化しない。

 この理由はわからない。組み上げる時、動きをスムーズにするために作業盤の裏の軸受けひとつに、薄いスチロール板(0.2mm)を挟んで締め付けているが、これが原因とはどうみても考えられない。工作面のV-slot盤そのものが曲がっているのかもしれない。

 まともな水平出しをしていないので、測定はこれ以上綿密にやらなかった。ただ、問題が残っている。歪みがわかったあとの対策である。X軸は、もういちどフレームのブラケットを緩めて調整する余地が残っているが、Y軸は原因がわからないので直しようがない。シャフトが歪んでいる?(まさか)。

製図板でレベル出し。けっこう歪んでいた(1/17/2018)

 プロが使う水平出しの工具、定盤(じょうばん)はとてもじゃないけど手が出ない。でも何とかしようと安物のべニアの製図板(それでも¥5000した)をウェブで注文していた。これが来るまで少し日数がかかり、今日届いた。

 早速、出来上がったマシンのフレームを緩めてスピンドルモーターのついたXZ軸一式をはずし、床に置いた製図板に水平面のフレームを置く。Y軸のステッピングモーターの軸もはずし、フレームだけにして4隅を押しながら、がた付きを見る。

 結構がたついていた。コーナーブラケットを一旦全部緩め、どの隅を押しても他が浮かないことを確認しながら、少しづつ締めて行く。フレームのがた付きがなくなったら、Y軸の軸受けもすべて少しゆるめ、滑りを確認しながら、軸受けそのものを慎重に締めて行く。

 滑りは以前に比べて大幅に改善されていた。しかし、軸受けの固定を強めて行くと、必ず滑りが悪くなる。軸受けそのものの精度が余りない上に、固定はV-slotの溝で自由度があるからだ。これからの調整は完全に「かん」の世界である。

 幸い、たまたま3つまで締めて全く問題なく最後の4つ目でおかしくなったので、この軸受けを紙やスチロール(クリアファイル)板をさらに足して少しづつ締めて行くと、殆ど変わらない滑りが得られた。もしかすると、このひとつを遊ばしておいても精度に問題がなかったのかもしれない。

 そろそろ素材を用意する段階だ。仕事の帰り、久しぶりに秋葉原に寄り、買い物をした。これまで手をくわえて見ていた生基板を千石電商で両面と片面基板を1枚づつ入手する。秋月は10枚単位でしか売っていない。色々試したいので少量づつ買うことにした。ついでにリミットスイッチ用に超小型のマイクロスイッチ(¥100)を買い増した。

 最近、千石は店舗を大幅に統合し本社の売り場階が増えたが、どうも慣れなくていけない。スイッチとコネクターなどは同じ階ではなく、地下と2階に分かれてしまって混乱する。所長にとっては全く縁がないエレキギターの部品が結構大きな面積を占めているのも気に入らないところだ。

Ws000006 heightmapという機能があった。早速、工具を作る(1/19/2018)
 当研究所のCNC導入の大きな目的は、薬剤を使わないプリント基板の切削にある。ほとんどの工作は基板制作になるはずなので、工作面の平面出しは薄い銅箔を削るので非常に重要だ。ただ、買ってきた生基板を見ていると、この板だけでも結構歪んでいるではないか。

 これを平面にするのは大変だなと感じていたのだが、ウェブの中でみなが話題にしているのに、最初その意味がわからなかったheightmap機能というのが、これを解決するカギであることを知った。

 Z軸は、切削の前に、このあらかじめ採っておいたheightmap情報を元に補正し、常に一定距離で削れるようにする仕掛けである。これなら少々元が歪んでいても削り出す深さは一定に保てる。とても合理的な方法だ。

 基本的な平面出しが一段落したので、早速、ウェブサイトを参考に見よう見まねでA5ピンを使ったheightmap機能の実験に取り掛かる。Z軸プローブは、商用AC用の1.6mm単線の切れ端を使う。被覆を入れるとちょうど3ミリ、エンドミルの口径にピッタリである。

Dsc01316  やすりで切断面を磨くとちょうど良い感じである。最初、プローブケーブルをひとつ隣のピンに刺して、Zプローブを実行させ、生基板にゴリゴリ言いながらプローブが刺さったときも銅なので大きな被害はまぬがれた。

 間隔や、広さを指定し、スタートボタンを押すと、生基板の上をスピンドルの先端につけたプローブが少しづつ動いて距離を測っていく。順調に進んでいるようだ。見ているだけで楽しい。画面に少しづつ結果がカラーで表示されていく。よーし無事終わった。

 測定結果は、フレームの水平出しをやったおかげでダイヤルゲージの時より大分良くなった。それでも0.3ミリ程度の誤差があるようだ。この程度なら補正出来るだろう。ついでに、マーティ氏が経験したA5端子のESD対策のダイオードを基板にハンダ付けする。

Normaladpter  確かにグランドから浮いたICの端子を長く引き回すのは静電気を引き込みやすくICそのものを壊す危険がある。残るはレーザーカッターの時の12V電源のグランド対策だが、レーザーはまだ動かさないのでこれは後回しにする。いやいや先達がすべて問題を先に見つけて指摘してくださるのでとても安心だ。

 レーザーカッターも、厳密には光の焦点の関係でZ軸にうるさいはずだ。しかしheightmapがこれを解決してくれる。出来上がったheightmapは色とりどりで美しい(変化があるということで本当は良くない)。誤差は0.3mm以下になったが、素材の固定は結構難しい。相当、余白が必要だし、余り強く締めると反って歪みが出てくる。

 このところホームセンターに行っては、集塵装置や、防音ボックスを物色している。しかし、これという気にいったものは見つからない。まあ、地下のオープンスペースが作業場所になると思うので、そう神経質になることはない。ここでは、これまでに派手に音や粉塵を出している。

いよいよ初切削かと意気込んでいるときに思わぬ障害(1/21/2018)

  生基板も買ってきたし、そろそろ試しの切削を決行しようかと思ったとたん、電源が突然おかしくなった。電圧が全くでてこない。少々ケーブルをいじるが全く反応なし。みら太氏のところにも不良品が最初行っているので余り驚かないが、とにかくステッピングモーターが回らない。電圧は0V。

 そういえば、テストの時、スピンドルモーターが連続ではなく間歇的にしか回らないので最初はそういうものだ思っていたが、やっぱり問題があったのだ。ACアダプターの故障に間違いない。24V、5.62Aという妙な定格である。

 先方にクレームの電子メールをとりあえず打ったが、返事はすぐには来ない。とにかく先に進みたいのでウェブで代替品を探す。ところが、頼りにしている秋月には、24Vで4A以上は、アダプター形式のものはなく本格的な電源装置ユニットになる。しかも¥5000近くする。

 とにかく電源が来なければ先に進めない。もっと安い所はないかさらにネットで調べる。すると車のバッテリーの充電用(トラックは24Vらしい)のAC電源ユニットが異様に安いのを発見した。安いのは¥2000台からある。一応みな安定化電源をうたっている。

Normaladpter_1_2  恐らくこれも中華製品で、CNCマシン同様、どこかのオリジナルの製品がコピーされ市場に出回っているようで、みな恐ろしく似た形をしている。あまり安いのは危ない(代替品がまた壊れたのではしゃれにならない)ので、少し値段の高い¥3600のものにする。

 CNCキットの販売元から、早速レスポンスがあった。実際に電圧が出てこないという証拠の写真が欲しいという。こんなもの必要ないと思うが(いくらでも演出できる)、まあ求めに応じる。LINE風のやりとりが面白い。

Dsc01317  しかし、このクレームシステムは合理的だ。通常のメール以外に、発注番号をキーにしたLINE風のやりとりがウェブサイトの掲示板として出来ており、写真も送れるし、なにより窓口が一本になっているので混乱することがない。

KiCADに挑戦。こいつがまた難物。何とか1枚できたけれど(1/25/2018)
 車用品のAC電源ユニットを発注はしたもののこれもすぐ来るわけではない。はやる心を抑えきれず、近くのホームセンターで60X30(cm)のMDF板(5ミリ)を3枚に切ってもらって練習に備えたり、プリント配線のデータの準備をしたりして電源が来るのを待った。

 プリント基板の切削も良いが、普通の加工しやすい素材で本来のフライス盤の機能も確かめておきたい。どうせならソフトについているサンプルの簡体字の漢字パターンでなく、自前のデータを作りたいと、適当なソフトを探したが、これはとてもじゃないが簡単には準備できないことがわかる。

 Fusion360というのが定番のようで、マーティ氏やみら太氏のブログには詳しく出ているが、恐ろしく機能が豊富でちょっとのことで使いこなせそうにない。それにしてもソフトの世界はこのところ様変わりだ。非営利ならこのソフトが一年単位で無料で使える(更新可能)。昔なら数十、いや数百万円はしたであろう3Dモデリングソフトが自由に使える。良い時代になったものだ。

 基板CADの定番EAGLEは直接Gcodeを吐き出せるというのだが、今さらEAGLEを勉強しなおすというのもちょっと気が重い。もう少し簡便なCADプログラムはないか。調べるうちにKiCADというのがフリーソフトでは最近非常にもてはやされていると聞いたのでインストールしてみた。

 ところがこいつが意外に難物だった。ユーザーインターフェースがちょっと変わっているのか、どうも操作が慣れない。操作勝手はむしろEAGLEより使いにくい。まあ、フリーソフトだからということもあるが、なにかハングするようにソフトが止まるので面食らう。

Ws000008  やっとのことで、トランジスター1石でLEDをドライブする回路を作り、何とかべたアースで基板を作ることまで成功した。いや、これはちょっと大変だ。

非金属用のZ軸プローブを作ってheightmap(1/27/2018)
 車用品の店からAC電源ユニットが届いて、水平出しのテストを継続する。ただ何度もやってさすがに飽きてきた。懸念した通り生基板をクランプで強く締めても、やはり基板はかなり歪んでいる。当て板をしいて測りなおすが、あまり効果はない。

 それはそうと、制作の参考にさせてもらっているマーティ氏のCNCにかける熱意は素晴らしい。みら太氏は他に大型の二酸化炭素レーザーカッターを自作されているベテランで、このところ中華CNCの記事は少ないが、マーティ氏はたくさんの製品をこの中華CNCで制作されておりとても参考になる。

Normaladpter_5  このなかでスピンドルモーターの回転数測定で古いPS2マウスから部品を集めたという記事に触発されて、こちらもジャンク箱からいくつもあるマウスを取り出して分解したら、使い易そうなマイクロスイッチが3つも入っているのを見つけた。

 ちょうどMDF板を買ってきて、非金属用のheightmapを出したいと思っていたところだ。これでZ軸プローブを作ることを思い立った。アクリルの端材にマイクロスイッチの2ミリの穴をあけ、スピンドル軸は3ミリの長めのビスで代用できる。

Normaladpter_4  実は写真では良くわからないが、アクリル板の接着で大失敗している。瞬間接着剤の乾きが早く、天板のアクリル小片が正確に固定されていない。2回やったが2回とも不満な結果。もっとも、接着の効果を試すのには役に立った(べらぼうに接着力は強い)。

 テストする。うまく動いた。ただ、マーティ氏が指摘した通り、スイッチのヒステリシスは結構ある。でも、heightmap測定では一方向でしか測っていないので問題ないはずだ。これでハード関係の整備は殆ど終わった。あとは、切削データの準備である。

AliExpressから代品到着(2/1/2018)
 皮肉なことに、車用品のACアダプターが届いて数日もしないうちに、AliExpressから新しいACアダプターが届いた。早速、梱包を解く。出てきた製品は前の製品と全く違うタイプだった。容量も6Aに増強されていた。勿論問題なく動いた(写真右が代品)。

Normaladpter_2  いやみっぽく「故障品は返送しようか。送料着払いで」とメールしたら「not much reseach value」なので要らないと返事が来た。まあ、中国では良くあることなのでいちいち原因解析などしておられないのだろう。それにしても、クレームのメールを出したのが20日で、届いたのは30日、まるで日本の通販並みの速さだ。

 しかも、とても誠実だ。中国だといって馬鹿にしてはいけない。向こうの英語は正直言ってかなり怪しい感じだし(まあ、自分も余り褒められたものではないが)、発送前にテストしておけばわかった不具合だと思うけれど、少なくても担当の女性(名前がElizabethなので)のトラブル収束に向ける誠意を感じた。やはり中国恐るべしである。

| | コメント (2) | トラックバック (0)

2018年1月15日 (月)

遂にCNCマシンキットを発注。細かい工作をしながら待つ

みなさま遅まきながらあけましておめでとうございます。
 おかげさまでこのブログは発足以来10年にもなりました。最近は記事の更新間隔が広がり、アクセス数も漸減しておりますが、自分として電子工作は定年後のライフワークとして欠かせない活動のひとつとなっています。

 このブログも少しは人の役に立っていることを感じる時がたまにはあり、自分の好きなことで人に喜ばれることは無上の喜びでもありますので、止める気は今のところ全くありません。この自己満足を満たしつつ、細く長く続ける所存でありますので今後ともよろしくご支援のほどを願っております(コメントがとても励みになります)。

 さて、今年は表題にありますように、とうとう念願のCNC(コンピューター制御)工作機の開発に挑むことにしました。当研究所の究極の目標のひとつでもあります。年末からこれまでの活動経過を以下にご報告します。

年末に意を決してCNC工作マシンに取り組むことを決定(12/27/2017)
 遂に中華CNCフライス盤キットを発注した。これまで欲しい欲しいと思っていたコンピューター制御の工作機械である。

Dsc01311_2  フライス盤とは高速で回転する刃物(ビット)で素材を切削し部品を作る機械のことで、プロの世界では、古くからコンピューター制御で自動的に作ることが当たり前になっている。最近はアマチュアの世界でも普及が広がってきた。

 しかし、ちょっと前までアマチュアが手の出せるCNCフライスは、どんなに安くてもキットで10数万円した。自作するのはもっと大変だった。市販のミニフライス盤を改造するにしても、相当な工作の熟練度と経験を持たないと近寄れない世界であった。

 それが中国製のCNCフライス盤キットならフレームからモーター、制御基板など全部合わせて、なんと数万円で手に入るのだ。ネットには続々と制作記が掲載され、評判も悪くない。

 情報が豊富になったので、中華キットでも不安がなくなってきた。これはもう作るしかないだろう。この制御コンピューターがArduinoというのも時代を感じさせる。やってみたいのは、プリント基板制作である。いわゆる乾式プリント基板である。

 発注先は、この前のオシロと同じAliexpressに決めた。沢山のショップが同じようなものを売り出している。良く見ると少しづつ微妙に違っていて同じではない。これを比較するサイトもあったりして選ぶのに参考になる。先月あたりから、色々物色して、多数の人が選んだCNC2418で、買うところは、一番安心できそうな、ここに決めた。

 発注の時、ついでに5.5Wのレーザーユニットもつける。フライス盤がCNCレーザーカッターに早変わりだ。3ミリくらいまでのアクリル板の切り抜きが出来るという。これまで実用品にこだわってきた電子工作だが、こんどのプロジェクトは究極の実用化である。 Ws000003

 ロボットアームなど、いくらこだわっても所詮は玩具である。一方、CNCマシンはこれをもとに、プリント基板や、ケースを自作できる。実用という意味では、「しかけ」を再生産する「しかけ」ほど実用的なものはない。

 価格は何とレーザーユニットも含めて$148、送料$50、あわせて$200たらず。関税がかかるにしても、日本円で2万5000円以下である。本当にこんなに安くて良いのか、画面の前で一抹の不安がよぎる。

 しかし、ここまで来て引き返すわけにもいかない。自分ひとりで興奮しながら、深夜、購入のボタンを押した。手元に届くには暫く日がかかりそうだが、楽しみに待つことにしよう。

参考にさせてもらったサイト。
CNC制御の自作レーザーマシンや、ルーター(フライスまで行かないか)マシンの全体俯瞰には、次のサイトがおすすめ。
自作CNCマシン・レーザーカッターについて

中華CNCマシンの制作や調整は以下の2つのサイトが細かくて懇切丁寧。必見である。
みら太な日々

マーティーの工房日誌

中華CNCマシンの比較は以下が詳しい。結局ここと同じものを選択。
念願のCNCフライスをついに注文……ただし、激安の中華CNCだがな

(無断引用ご容赦)

秋月電子で安いLDOを見つけた。秋月のLDOが勢ぞろい(12/29/2017)
 キットが来るまでには日数がかかる。調べたいことは調べつくした。何か手を動かしていないと落ち着かない性格になっている。ということで、これまでやりのこした細々とした工作で、気を紛らすことにした。

 ロボットアームのリモコンは、まだブレッドボードの上の仮ごしらえである。いずれケースに入れるつもりだが、せめて電源だけでもバッテリーにしようと、部品箱にころがっているリチウム電池を取り出した。

 リチウム電池は、満杯のときが4.1Vで、公称が3.7Vだ(危険水位は3.6Vでこのあと急激に下がる)。3.3Vディバイスのためには、いわゆるLDO(low drop out)3端子レギュレーターの出番である。

 当研究所には、既に沢山の3.3V用のLDOレギュレーターが揃っている。レギュレーターによっては、発振したり、なかなか定電圧にならなかったり微妙にやっかいな部品である。しかも、過去にはレギュレーターを2つも焼損させて「復讐」を受けたりしている。

 最近のディバイスの電源電圧は3.3Vが多い。RaspberryPiやESPシリーズなど、これらは消費電流が多くて、電源の容量不足で問題が続出し、ネットが一時この話題で大いに賑わったことがある。

 このとき、ねむいさん達が推奨していた3.3V用の強力なレギュレーター、ADP3338が、秋月でも売り出されているのを発見した。しかし高い。ひとつ¥300もする(DigiKeyではもっと高かった)。

 どうしようかなと、さらに秋月サイトを眺めていると、LDOのジャンルで、日本無線のNJM2845というチップが目に止まった。こいつは最大出力が0.8Aと少し低いものの(ADP3338は1A)、最小ドロップ電圧が0.18Vという優れものである(ADP3338は0.19V)。価格はなんと1/6の¥50。これは買うべきだろう。

Dsc01310  それに、LT1963というLDOも売り出されていた。これは小さいけれど1.5Aも出せる強力なLDOで、ねむいさんがかなり前に推奨していたことがある。しかし、これも少し高くひとつ¥200もする。でも何となく気になったので、暮れの秋葉原に出て、これら話題のLDOをまとめて買ってきた。

 買ってきてとりあえずNJM2845のブレッドボード用のミニ基板を作る。こういう工作は楽しい。簡単にできた。早速、ロボットアームのリモコンボードに使ってみる。うむ、これまで、LD3985や、AMS1117では、電池電圧が3.9Vを下回るとリセットを繰り返して動かなくなったリモコンが、快調に動く。

Dsc01308  まあ、AMS1117は最小ドロップ電圧が1.0V、LD3985は、最大出力電流が0.15Aといずれもスペック外になるのだが、同じLDOと銘打っても、こんなに差があることに驚いた。ADP3338ならもっと安定するのだろうが、これは先のお楽しみということで先に進む。

ESP8266の省電力化はうまくいかない(12/31/2017)
 ロボットアームのESP8266は送受信とも電池駆動である。ネット機器は一般に大飯喰らいで、Xbeeなどは数十mA、WiFiのXbeeなどは百mAを越す。ESP8266でもWiFi接続時は同じくらい消費する。そのため、当然、電池駆動などの時のため節電モードが用意されている。

 ESPシリーズ(ESP8266やESP32)はこれまで動かすことに専念してきたので、省電力化の機能は横目で見るだけだった。手が空いたので、少しは省電力化しようと調べてみた。このサイトの情報が良くまとまっている。

 それによると、3つのモードのうち、使えそうなのはlight sleepである。ただ、今度のロボットアームは、送受信とも常にネットで相手の状況を調べている。こういう常時ネットと交信するシステムでは余り効果がないように思われるが、こればかりはやってみないとわからない。

 省電力の設定そのものは、リセットを伴うdeep sleep以外はソースコードに手を入れる必要は殆どない。単に設定のAPI関数、 wifi_set_sleep_type(LIGHT_SLEEP_T) を入れるだけである(モデムスリープはMODEM_SLEEP_T)。

 deep sleepはプログラムがリセットされるから、プログラムの構造を変える必要があり、立ち上がりのトリガーをコーディングしなければならない。今度のプログラムではこれを使うことが出来ない。

 送受信とも、このlight sleepでテストしてみた。結果は全く影響がなかった。sleepを入れる前、受信側(サーバー)は交信前で、93~98mA、送信側(リモコン側)は、108mA程度で、交信が始まると、受信側が120mAに跳ね上がり、送信側も、134mAに上がる。

 sleepを入れると、受信側は、交信中で136mAとかえって悪化してしまう(送信側は変化なし)。休止するための何らかのオーバーヘッドがあるのだろう。プログラムの構造を考えずに、こういうステートメントを入れても効果がないことが良くわかった。

 測定は、電源に0.5Ωの抵抗を挿入し、両側の電圧をオシロで100mV/divで測った。今度のオシロは測定機能も充実していて、平均電流や、RMS(二乗平均)値も出してくれる(上記数値はすべてRMS値)。

 さらに、測定量が多いので、時間軸を拡大してもちゃんとデータを持っている。前のオシロでは、持っているデータが少ないので、少し詳細を見ようと、時間を広げると、すぐ波形が凸凹になって絵にならなかった。

 落ち着いた大晦日。電流の計測で、日がな、ゆったり時を過ごす。東京では雪が降ったそうである。こちらは雨だったと家人が言う。都心の方が雪というのも面白い。

めげない性格。何とかクライアント側を半分にする(1/4/2017)
 何事もなく新年を迎えた。近くの神社に初詣に行き、箱根駅伝を見てしまうとやることがない。CNCキットは正月中なので来る気配はない。で、年末挫折したESP8266の省電力化をあきらめないでしつこく続けることにした。

Dsc01305  要するに、断続的な観測以外の用途では、deep sleepは使えないし、無理に入れてもリセットなどで結果としてトータルとしては電力増の可能性がある。light sleepもネットが動いているときは殆ど無力だ。

 従って、UDPパケットがくるのをひたすら待つサーバー側は、省電力にすることは難しい。調べる間隔を延ばせば、反応が遅くなるだけだ。残るはクライアント側のリモコンスイッチのところである。

 少なくても、スイッチを押すまでは送信を休止していれば、少しは減るのではないか。再び、オシロに火を入れて測定開始である。まず、何もしない時の電流量は、先に紹介した通り100mAを越えている。一定の間隔(17ms)で常時パケットを送る仕様なのでこんなものだろう。

 そこで、スイッチを押したときのみUDP送信をするようにソフトの修正を行った。これがはまったのである。うまく動かない。電池が不足してコアダンプを始めたり、memcpyの標準関数がおかしくなったり、さんざんな目にあう。

 久しぶりの疑似コーディングで考え直す。スイッチを押した後の処理が難しい。うまく止まってくれない。フラグやスイッチはなるべく使いたくない。苦労の結果、前の状況を残しておくロジックで省電力化に成功した。電流量は60mAと半分近くになった。

 オシロで調べたところでは、最初、フルにネット接続をしているようだが、暫くすると休止モードに移行し(ベースの電流ががくっと下がる)、消費電流が低くなる。しかし、WiFiネットの継続のための内部のヘルスチェックの交信が入るようで、たとえアプリで送信を止めていてもこれ以上、下げるのは無理なようだ。

遂にCNCマシンキットきたー(1/9/2018)
 そうこうするうちに、思ったより早く暮れに発注した中華CNCマシンキットが到着した。AliExpressは注文確定から入金報告、出荷の有無などを逐一メールで報告してくれる。運送会社はEMSでこれも荷物の状況をかなり詳しくサイトで確認できる。

 ついでに発注したレーザー光線防眩ゴーグルは、本体より早く日本に到着していたようだが、受け取ったのは同時だった。外出中に家人が受け取ったのだが、関税は全く請求されなかった。送り状には、¥744と明記があるのだが、配達員は何も請求しなかったという。忘れたのかもしれない。Dsc01306

 荷物を記念撮影する。写真で見ていたのだが、思ったより小さい。しかしかなり重い。梱包も中国からにしては、歪みも殆どなくきれいな荷姿だ。さて、これから苦難の道が始まる。しかし、これは楽しみでもある。

 しばらく当研究所のブログはこの話題が続き、電子工作どころではなくなるが、まあ、AVRと銘打って今は殆どAVRをいじっていない。気儘にやることを勘弁して頂きたい。さきほどの先人たちの克明な制作記があるので何の不安もなく作業を開始できる。みら太さんの制作記事が一番詳しくてわかりやすい。

 梱包を解く。ありゃ、レーザー光線防眩ゴーグルが添付されていた。機材そのものは彼のキットとは微妙に違うところがあるが、大筋では同じ。X軸の動きが、彼のは渋かったようだが、こちらは、全く問題なくスムーズだ。反対にY軸がいまいち動きが悪い。レベル出しが必要なのかも知れない。

何とか動いたが、これからが大変(1/14/2018)
 残念なことに、我が家には水平を出せる定盤のような設備はない。床のフローリングも水平なようで、細かく歪んでおり、スマホの水平レベルアプリで調べても、これを頼りに水平を出すのは意味がなさそうである。

Dsc01307  実は当研究所では、ずいぶん昔、みら太さんが使っているダイヤルゲージを購入している。何のために買ったのか今になると思い出せないのだが、これを使えば相当精密な水平レベルを実現できそうだ。しかし、問題はフレームのレベル出しだ。色々考えた末、べニアの安い製図版を買って、ここで水平にすることにした。ネットで発注したが、到着まで10日近くかかるとメールが入った。

 待っていられないので暫定的な水平出しで我慢して、組み立てを急ぐ。4日ほどかけて無事完成した。組み立て過程は、これまでの複数のサイトの説明で十分なのでここでは省略する。最初は、このマシンの主要枠材、v-slotの取り扱いに難渋したが(後入れナットがうまく入らない)、これも慣れてくるとだいぶ楽になった。

 フレームが組みあがった。ステッピングモーターと、送りねじの接続で一苦労する。送りねじの長さが、X軸とY軸で微妙に違い、最初、逆につけてつながらない、つながらないと焦っていたり、基板の取り付けでフレームがずれているのに気が付かなくて(ここのずれは他と関係しない)、もうちょっとで取り付け穴を広げそうになったり、ドタバタはあったが特に大きな問題はなく組みあがる。

 電子回路の配線は、単にモーターのケーブルを基板につなぐだけである。あっけなく、終わった。さあ、今度はソフトの準備だ。実は、ソフトのインストールが一番てまどった。付属のDVDからPCに持ち込もうとするとエラーが出る。しかも英文用のGRBLはDVDで立ち上げようとするとアプリケーションエラーで止まる。

Dsc01312  あちこちいじったが、中文用のGRBLがDVDから動くことがわかった。紹介ネットサイトでおなじみのgrblControlの画面が出た。とりあえずこれでモーターの試運転まで行くことにする。USBをつないでUARTを接続、画面が変わった。

 動いたー。jogという手動のボタンで上下左右に動かす。いやあ感激、感激である。GRBLインストールのトラブルは、原因究明より大もとのサイトから正式のソフトをダウンロードしてめでたくHDDから起動できることを確認した。なんと全てオープンソースなのだ。これが中華製品躍進の理由かもしれない。

 とりあえず動いたというだけだが、ブログはこのへんで一段落しよう。残るは、防音ボックスと集塵装置の整備である。Fusion360のための64ビットOSの準備も待っている。ひょっとすると、このあたりの整備の方が本体より高くつくかもしれない。

| | コメント (4) | トラックバック (0)

2017年12月27日 (水)

ロボットアームのESP8266ワイヤレスリモコン化(続き)

ボタンの操作性を向上(12/8/2017)
 ロボットアームのリモコン(ESP8266のUDPクライアント)操縦用のボタン(スイッチ)は、5つのモーターの作動を指示するスイッチと、その正逆転の共通スイッチのひとつ、合わせて6つである。動かしてみるとやっぱり、アームの上下や左右の回転の操作は、それぞれが独立したタクトスイッチで動かす方がはるかに操作しやすい。

 しかし、ESP8266の使えるIOピンは6本が最大で、増やすわけにはいかない。というのでこのあいだ、I2Cで16チャネルまで増やせるI/OエキスパンダーIC(MCP23017)というのを秋月で買ってきてあるのだが、まあ、ここまでこだわることもあるまい。

 つらつら考えているうちにアイデアが浮かんだ。タクトスイッチは5X2の10個を並べ、対のボタンには、正転逆転のモードが同時に通電されるようなハード的なやり方を加えれば実現できるのではないか。例えばダイオードみたいなもので。

Tactsw_with_diode

 その昔、少年時代の頃、階段の明かりを単極双投のスイッチ2つでどちらから点けても、その先で消せるという回路を知って、ひどく感動した記憶がある。今度はそれほどでもないが、思いついたときは近来になく興奮した。

 でも、本当に動くのだろうか。これは試してみるしかない。小信号用の順電圧降下の少ないショットキーバリアダイオードの買い置きがある。早速、これを持ち出して同時に押す側のタクトスイッチから、正逆転のモードのピンと、本来の制御ピンに対して順方向に2つのダイオードをつなぎ、LEDをつけてみた。

 見事に、2つのLEDが考えたように点灯した。いやあ嬉しい。ウェブで調べると、キーマトリックスではダイオードが盛大に使われていることを知った。まあ車輪の再発明みたいなものだけれど、自力で思いついたところが偉いと自分で自分を褒める。

組み立てたけど動きが遅くなった。電池切れでもない(12/9/2017)
 遊んでいるうちに、アームの動きが急に鈍くなってきた。単一電池なのでまだまだ大丈夫なはずだが、グリッパーでものをつかんで運ぶのに結構長時間夢中になって動かしている。気がつかないうちに、電池がへたったのかもしれない。 Dsc01269

 オリジナルの電源は、単一電池4本を直列に接続し、その真ん中を共通グランドにして、これだけで正逆転の運転を巧妙に実現しているのだが、リモコンにするときは、この配列をモーター電源と制御電源(ESP8266とモータードライバー)に独立させて供給するように変更した。

 制御電源は、多くても数十mAしか流れない(但し、連続して流れる)。一方、モーターの方は数百mAではるかに消費が激しい。そこで、これを制御側と交換してみた。これで元気が戻るはずである。しかし、同じように勢いがない。ふーむ、これはおかしい。電池切れとは考えにくい。電圧を測るとモーター側もまだ一本1.5V近くある。

 マルチメーターで各部の電圧を測る。確かにモータードライバーのモーター出力は正規の1/3に近い1Vしか出ていない。念のため制御側のGPIO電圧も測る。おかしい。ここも1.8Vくらいしかない。ESP8266のGPIOピンのプルアップ不足かと思い、4.7KΩの少し強めのプルアップ抵抗をつけるが全く効果はない。

 モータードライバーDRV8835が早くも駄目になったのだろうか。ウェブで調べる。モータードライバーの損傷の原因は、過電圧、過電流、逆接続、モーターなどの逆起電力とある。電池なので過電圧はあり得ない。過電流に対してはモーター回路には用心して0.9A(遮断1.8A)のポリスイッチを入れてある。 逆向きに通電した覚えもない。

 ただ、モーターの逆起電力を抑えるダイオードは入れていない。考えられる原因は、やはり、逆起電力なのだろうか。しかし、リレーなどと違って正逆転するHブリッジのモーターの逆起電力を逃すダイオードの付け方がわからない。

 DRV8835がモータードライバーと銘打つからには、こうした備えは当然あると思うし、データシートには何の注意書きもない。しかし、現実には、モータードライバーがへたったとしか考えられない症状だ。仕事の帰り、秋葉原の秋月によって腹立ちまぎれにDRV8835を5つも買ってきた。

 交換する前に、念のため各部の電圧を測ってみた。すると奇妙な結果が出たのである。モーターの起動/停止ピンの電圧は低いが、左/右を決めるピンは、ばっちりVccと同じ電圧が出ている。

 おかしい。これは何か発振している。マルチメーターなので平均電圧しかわからないが、その可能性はある。 こうなると、オシロの出番だ。必要なピンにハンダ付けで臨時のプローブを出し、それをブレッドボードに差して動かないようにして慎重にIOピンの電圧波形を測定することにした。

オシロがお手柄。あけてみたら原因はハードではなくソフト(12/14/2017)
 実はオシロ測定に入る前に基本的なミスで大はまりした。こんどのESP8266受信サーバーは、モーターと制御系の電池を別にしているため、共通のグランドつまりローサイドで電源を切っている。これが原因で小一時間、頭を抱え込んでいた。

 念を入れてマルチメーターで電圧を測っていたときである。電源スイッチを入れてもいないのに電圧がでている。おかしい、どうしてだ。始めはスイッチがこわれているのではないかと疑った。しかしスライドスイッチがそうそう壊れるわけはない。

 ローサイドで電源を切っているときは、グランド側のプローブは、電池側でなく、スイッチの手前(回路側)にプローブをあてないといけないというのに気が付くまで暫く時間がかかった。図に書いたら一発でわかるミスだが、ブレッドボード上では中々わからない。実に情けない話である。

Dsc01265  この騒ぎが一段落して、やっと、オシロでGPIOピンの波形を出すところまで行った。そして、出てきた波形を見てさらにびっくりする。全く予想もしていない波形だった。最初、発振を疑っていたのでアナログっぽいランダムな波形を予想していた。

 それが、何とピンの電圧が、きれいなパルス状に出ているではないか。発振ではない人工的なパルス波形である。あっと思い当たった。これはソフトで作った波形だ。間違いない。

 動き始めた当初、暴走を止めるために受信メッセージが切れたときサーバー側で、とりあえず全ての制御を止めるロジックを入れた。こいつが原因に違いない。データが来るより、処理の方が速いため、次の受信データが来る前に制御は全部止まり、次のデータで再びONされる。

 マルチメーターでは平均電圧しかでないのでこの状況はわからない。ちょうどPWMのような動きをして回転が下がっているだけだ。モータードライバーはおかしくない。正しく動いている。全部自分が悪いのだ。モータードライバーさん疑ってごめんなさい。

 いやあ、世の中というのは恐ろしい。最初考えていた原因とは全く違っていて、犯人は暴走防止に気楽に入れたコードだった。ハードを疑った因果応報で、所長の本業のソフトの世界に弾が戻ってくるとは良く出来た話である。

無事、ロボットアームは元気を取り戻したが(12/16/2017)
 待ち時間を調整して、送る間隔と、受け取る間隔を同じにし、受信側も、受信データが来ない時は一定時間待ち、さらにデータの有無を聞いて、ないとき始めて制御を止めるロジックに変える。

Dsc01266  これで無事に普通のパルスが出た。ただ、どれだけ短くスイッチを押しても、100msちかいONになってしまうのが少し気になるが、とりあえずはもう大丈夫なはずだ。 もういちどロボットアームを組み立てなおす。試運転である。

 よーし、これまでへたったと思っていた単一電池でも元気よくアームが動いた。いやいや、お疲れさまでした。10個のボタンの制御はとても快適だ。まわりの消しゴムや、電池(単一でも持ち上る)を掴み、所定の位置に運んだりして遊ぶ。

 ロボットアームはワイヤレスで順調に動いた。動かすことが目的なのでこれでプロジェクトは大団円である。しかし、奥歯にものがはさまったように気になるところがまだひとつある。ワイヤレスのタクトスイッチをどれだけ短く打っても、モーターが100から120ms、動きを止めないことである。

 これはオシロで測ったときにわかったことなのだが、人間のタクトスイッチの押下の間隔は最小で50msくらいまで短く出来るはずなのにおかしい。実際の動作には殆ど影響がないのだが、何となく気になっている。

ロジアナでUDPを解析することを決断する(12/25/2017)
 現在クライアントとサーバーの間のUDP通信は17msという中途半端な時間間隔(オリジナルのまま)で送受信を繰り返しているが、この間隔で最小の動作時間が100ms以上というのは解せない。

 こうなってくると、オシロではわからない。もしかすると何かとんでもない動きをしているのかもしれない。データが溢れているのだろうか。UDPのパケットが未読のままだと、どういう状態でデータが残っていくのか、ウェブで調べてもはっきりとしたことはわからない。

 気になるといつまでも尾を引く、いやな性格である。オシロではなくロジアナで各部の動きを調べれば相当なところまでわかると思うが、ロジアナは準備が大変なのでなかなか決心がつかなかった。

 しかし、UDPの動きを知る良い機会でもある。ちょうど年賀状も出し終わって手が空いたところなので,結局、机の奥にしまってあったロジアナ一式を持ち出すことになった。

ロジアナで原因は一発で解明(12/27/2017)
 久しぶりのロジアナである。クライアントとサーバーの双方からプローブを引き出す。スケッチにはGPIO一本をつぶして動作点を記録するコードを追加して再ビルド。幸い双方にはUARTがついているのでこれも利用し、全体の動きを調べることにした。

Udpread  その結果、ロジアナはとても正直に実情を伝えてくれた。グラフを見れば一目瞭然である。受信側のデータの有無を調べる関数UDP.parsePacket()が正しく動いていない。暴走を避けるため、この関数を20msほど休んで再発行しているが、そのあとloop()の先頭に戻るので結果としてこの関数を連続して呼んでいることになる。

 UDP.parsePacket()は、連続して呼ぶと正しいデータを返さないようだ。いくつか空振りしたあとデータが入って処理が再開される。そのあいだの5回くらいの空振りが100msの原因だった。

Udp_read  要するに、Arduinoのloop()の中で、待ち時間を入れずにこのコマンドを実行させるとおかしくなる。まあ、通信関係では良くある、不具合とも言えないトラブルである。それにしても、ロジアナはいとも簡単に原因を解明してくれた。

 いやあ、さすがはロジアナだ。原因がわかれば解決は簡単である。loop()のUDP.parsePacket()が連続しないよう10ms程度の待ち時間を設ける。これでボタンの最小時間は50ms程度まで下げることが出来た。

 ま、しかし、それで動作が目に見えて早くなったわけでもない。完全な自己満足の世界だ。それでも何となくキビキビと動くように感じで(気のせいに違いないが)、気分が良い。

Dsc01276  こんどのスケッチのソースは、殆どが人さまからの借りものなので、ここで公開するのはためらっている。UDPのメッセージを漏らさずGPIOピンに反映させるのに少々手を入れたので、みなさんに使ってもらいたい気もするが、機種依存だろうから余り役に立たないかもしれない。

 もしどうしてもということなら、コメントかメールを頂ければ、ご送付申し上げる。

| | コメント (2) | トラックバック (0)

2017年12月 8日 (金)

ロボットアームを2台のESP8266でリモコン操縦する

ブレッドボードのテストは順調だがスマホのHTMLタグが難しい(11/13/2017)
 モータードライバーで、ロボットアームをタクトスイッチで動かすことは出来た。これをESP8266のGPIOで制御してやれば、ワイヤレスリモコンが完成する。

 ソフトは、以前クローラーをスマホで動かしたときのESP8266のスケッチが残っている。これを流用すれば良いはずだ。ESP8266のWiFiをAP(アクセスポイント)モードにして、スマホとpeer to peerでつなぎ、スマホの画面から制御する方式である。

 このスケッチの中の制御ピンを増やしてやれば良い。ESP8266のハード周りをもう一度復習する。ESP8266は18本ピンが出ているが、このうちGPIOとして使えるピンは9本だけである。しかも、いくつかはモード切替などのため使えないピンがあり、結局、自由に動かせるピンは、6本しかない(制限付きのものが3本)。ぎりぎりだった。

Dsc01236 以前のスケッチに、動かすGPIOピンを少しづつ増やし、モーターを動かす代わりにLEDをブレッドボード上につけて動かしてみる。LEDは順調に点いたり、消えたりした。

 しかし、問題なのはスマホの方だ。画面上のボタンを増やしていくと、すぐ画面が一杯になり、スクロールしないと、ボタンが押せなくなる。画面のタップで操作性が悪くなっているところへ、画面の移動までして操縦することは、ほぼ不可能だ。

 小さなスマホの画面に、数多くのボタン類をどうレイアウトするかも問題である。はじめ、ボタンをトグルスイッチのようにして、モーターの細かい制御が出来るように考えたが、スマホのタッピング操作は連続させると全く違うactionにとられることがわかってこれは断念する。

Dsc01237 不便だが、それぞれのモーターのボタンはすべて動きの開始だけで、停止は共通のボタン一つにすることにした。それにしても、このボタンに使うHTMLのformタグのレイアウトはとても難しい。行と行の間隔が空きすぎて、ボタンの多い今度のリモコン画面は一面に納まらない。

 formタグを一行に複数置く方法は、幸いウェブにやりかたが載っていた。フォントをさらに小さくするなどして、一画面に納まるようにレイアウトする。もっと良い方法があると思うが、情けないことに新しい方法が思い当たらない。これまでの方法を力づくで片付けていくしかない。

スマホでテスト用のLEDは動いたが、運転するのは無理か(11/14/2017)
 画面が出来た。LEDをタップで光らして見る。点灯は僅か遅れるし、画面だけ見ているならともかく、アームの動きを見ながら、のっぺらな画面をタップする事は目茶目茶難しい。スマホのタップで細かい動きを制御するのはどうも無理な感じがする。

 何か良い方法はないだろうか。色々探してみる。すると、ESP8266同士をサーバー・クライアントでつないでいる記事が見つかった。そうか、スマホでなく、もう一台のESP8266をクライアントにし、これをUARTか、タクトスイッチで動かせば、スマホのタップを使わなくてすむ。

 しかし、これまでWiFiで2台のESP8266を連携させた経験がない。通信のイメージが良くつかめない。STAモードなのか、APモードなのか、TCPかUDPか色々方式がありそうだ。ちゃんと動くのかどうかの確信がない。それに対して今のスマホ方式はとにかく動いている。

 乗り掛かった舟ということもある。今、これをやめるとこれまでの苦労が無駄になる。迷った挙句、とりあえずモーターを動かすところまでやってみて、だめなら2台方式に乗り換えることにする。

オシロの計測では、0.5~0.6秒遅れ。やっぱり諦めるべきか(11/22/2017)
 その前に、スマホ方式の時間遅れをオシロで調べてみることにした。スマホは画面のタップ操作以外に、スマホが反応してから実際にESP8266のGPIOが動くまで、瞬時というわけではなく一息遅れてしまう。これがどれくらいの遅れか実測し、スマホ方式を諦める駄目押しにしたい。Dsc01238_2

 実測と言ってもスマホをタップしたタイミングは、残念ながら電気的に知ることは出来ない。これは別のタクトスイッチとスマホを同時に押して近似することにした。以前、スイッチの同時押しを実装するとき、人間の同時押しというのがどれくらいの誤差があるか測ったことがある。

 それによると、人間は、ずれを5ms以下にすることは殆どできないが、50ms程度の違いなら同時に押せる。今測りたい時間差は数百msの世界なので、この程度なら複数回測って平均をとればよい。

 久しぶりの新型オシロに電源を入れる。ブレッドボードにタクトスイッチを付け、それで手でタクトスイッチとタップを同時に操作し、それをトリガーにESP8266側でONされる時間を画面に出す。

 測定の結果、少々の誤差はあるが、平均では、0.5~0.6秒程度遅れていることが分かった。この前、クローラーをスマホで動かしたときと大体同じ感触だ。クローラーのような大雑把な運転ならともかく、ロボットアームでものをつかむというような、細かい操縦は出来ないだろう。 

スマホの操縦でロボットアームが壊れそう。モーターを分解修理(11/24/2017)
 とにかく、スマホによるロボットアームの動作試験は、やって見ることにした。まだ実装がすんでいないのでブレッドボードを経由して、ロボットアームとESP8266を接続する。Dsc01254

 スマホのWiFiサイトを、画面に出てくるESP8266のアクセスポイントに設定し、適当なブラウザーでアドレスを指定する。よーし、制御画面が出てきた。適当なモーターをONする。良いぞ。モーターが動き始める。記念すべきスマホによるロボットアームの最初の稼働だ。

 しかし、予想した通り、やはり、遅れ時間が大きいうえ、少し焦って画面を見ずにタップすると思った通りの操作にならない。そのうちアームは限界点に達して悲鳴をあげる(このキットのギアは空回り機構がついている)。

 さらに都合の悪いことに、タップを正確にボタン上で行わないと画面が移動して目的のボタンがなくなってしまう。そのうち、モーターのひとつのギヤがかんで空転し始め、慌ててロボットアームの電源を切り離した。やれやれ、落ち着いているときは良いが、すこし焦るとタップ操作は、昨今の高齢者のブレーキとアクセルの踏み間違いと同じになる。Dsc01252

 モーターの空転は、減速ギアボックスの中で、歯車がはずれたようだ。ギアボックスの分解を余儀なくされた。予想通り、画面のタップで、こういう細かい動作を制御することは無理だということが良く分かった。

 タップというのは画面を見ながらでないと正確にできないし、それではロボットアームの動きがわからなくなる。これでスマホで操縦することは完全に諦めがついた。

 やっぱり、もう一台ESP8266を入れて、タクトスイッチを動かすクライアント方式にしよう。ロボットアームの実装は途中でお休みし、ESP8266の2台方式にとりかかった。

2台めのESP8266ブレークアウト基板の制作(11/25/2017)
 ということで、ストックしてあった予備のESP8266のブレークアウト基板の組み立てにとりかかる。これはクライアント用である。久しぶりなのでESP8266の開発環境を復習する。

 結構沢山のピンを事前にセットアップする必要ある。これまでの基板は、便利と思って、I/Oピンソケットをすべて片側に一列に並べたが、ピンの位置の確認に余計な手間がかかり反って非能率だった。その反省を生かして、今度はESP8266のピン両側に分けてピンソケットを並べる。

 書き込みモードとフラッシュブートの切り替えは、スライドスイッチからタクトスイッチに変更する。切り替えは、電源立ち上がりかリセット直後のGPIO0のhigh/lowだけで判断しているようなので、タクトスイッチだけで良い。 Dsc01264

 さらにGPIO15は立ち上がりの時は、必ず、LOWでないと動かないが(これが結構はまる)、立ち上がった後は、制御可能なので、プルダウンはピンヘッダーで変更可能にする。

 大した作業量ではないので、この基板はすぐ出来た。あとは、ロボットアームに実装する作業手順である。ロボットアームの基板は小さく、リセットスイッチなどは載せられないから、どこかでスケッチを焼いてから、持ち込む必要がある。

Aitendoピッチ変換基板で実装するESP8266を用意する(11/27/2017)

 作業手順を検討した結果、ESP8266の稼働用の基板がもうひとついることが分かった。リセットや書き込み用のボタンは必要ないが、立ち上がりに必要ないくつかの設定がある。立ち上がりモードの設定(GPIO0)、GPIO2のプルアップと、GPIO15のプルダウンである。

 ロボットアームの基板の平面上は確保したが、ESP8266のピッチ変換基板のピンヘッダーの高さが意外に大きく、普通にシングルラインのICソケットにつけていたのでは、カバーが入らないか、下のフレームにぶつかってしまう。

 実は、前からこのことに気づき、色々調べていたのだが、ふとしたことで良さそうな案を思いついた。秋月が売っている汎用基板に厚さが0.8ミリの薄い基板があることを知って閃いた。これにICソケットをハンダ付けし、この基板をESP8266の裏側に入れてESP8266をはさむ。Dsc01258

 こうすると、ICソケットの高さ分が低くなり、カバーの中におさまる。ESP8266の立ち上がりに必要な部品は、この薄い基板に配線できる。なかなか良いアイデアだと自己満足する。

 そのうち、Aitendoのピッチ変換基板の裏には、初期設定用のプリント配線が用意されており、あらためて配線しなくても実装できることを発見した。

 このプリント配線だが、リセットやENABLEのプルアップ抵抗のランドは、2010くらいあるのに、GPIO0や、GPIO15などのランドは非常に狭い。1005よりもっと狭い。これはあとになってわかったのだが、このランドはハンダブリッジの間隔で、チップ抵抗を置くランドではなかった。直接VccやGNDに落としてもOKだということなのかもしれないが、何となく不安だ。

 で、これまでのストックから、1005クラスのチップ抵抗を探し、ランドを削って正式なプルアップ/プルダウン配線にすることにした。しかし、こんな小さな抵抗の手持ちはない。

そこで、物入れから、ジャンク基板(結構たまった)や、歴代の不良HDDなどを掘り出して、1005に近いプルダウンになる10KΩ程度のチップ抵抗を探した。

 思ったより簡単に見つかった。ハンダごてだけで採集する。例の低温ハンダを使うまでもない。少し周りを長い間あてていれば、チップ抵抗くらいだと自然に動き出すので、取りだすのは簡単だ。

 何とか必要な数のチップ抵抗を確保し、やっとのことでつけたのだが、案の定、一か所テンプラハンダをやってしまった。ランドが小さすぎて片側が接触不良になっていたのである。Dsc01251

 写真ではよくわからないが、左側がつながっていない。これで数時間を無駄にした。チップ部品は、片側が固定されてしまうと、残りの部分の接触不良は目検や、物理的な検証(部品を触る)では簡単には見つからないことを学ぶ。

 それにしても、残してあったHDDは不良品もふくめて5個以上ある。Appleマッキントッシュ時代の160MB(GBではありません)、SCSII(スカジー、これは死語か)DISKを見つけて感慨無量である。あのころは100MBを越す容量は大容量だったのだ。このあたりのチップ部品は、2010ではなくもっと大きいので、最近の基板には大きすぎて使えないのが残念である。

UDPでLEDを制御するスケッチを見つけた(12/1/2017)
 2台のESP8266の接続を紹介するサイトは、探してみたら結構沢山見つかった。参考になりそうなスケッチ(ソースコード)もあちこちにある。いくつか見て手続きの簡単なUDPで行うことにする。ここのソースコードを拝借することにした。4つのLEDの点滅を別のESP8266で実現している。こちらと全く同じだ。動画も公開されており、見たところレスポンスも速い。

 Arduinoには沢山のライブラリーがあるのでUDPを動かすのは、とても簡単なようだ。UDPを知らなくても、単にソケットをオープンしてそこへデータを流し込むだけである。クライアント側は、ソケットにデータが来るのをループで待って、それを読むだけである。

 こちらも2台のESP8266とLEDで実験してみた。最初は全く動かなかった。動かなかった理由は、お恥ずかしいながら全く基本的なところである。拝借したソースコードのSSIDとパスコードを自分のところに変えていなかっただけのことである。Dsc01256

 UDPが今一つ理解できていない証拠である。ソースコードの中の、WiFiのSSIDとパスコードが'*'になっているのを見て、UDPではそうするのかと、そのままにしてあったというオチである。良く考えれば、WiFiのこことUDPとは何の関係もないのだが、思い込みというのは恐ろしい。これに気付くまでまた数時間を浪費した。

 2台のESP8266のWiFiを正しく設定して、UDPを使ったリモコンLEDは全く問題なく動作した。動きも速い。案ずるより産むがやすしである。もっと早くこの方式にすれば良かった。

 ついでにオシロで遅れ時間を測定した。今度は両方とも電気的に問題なく採集できる。良いぞ。最小5ms、最大でも20ms以内にレスポンスが返ってきた。スマホ経由のTCP/IPのサーバー経由なら数百msオーダーだったやつだ。

やった、タクトスイッチのUDP接続でロボットアーム快調に動く(12/6/2017)
 ここまで来たら、もうあと一歩である。ブレッドボードを何枚か連ねてバラックでモータードライバーの制御線をESP8266のGPIOにつなぎ、もうひとつのブレッドボードにタクトスイッチを並べてクライアントを組み上げる。

 あれえ。クライアントのGPIO16だけが一旦、0(active)になると1(stop)に戻らない。試行錯誤の結果GPIO16はプルアップが必要とわかった。10KΩの抵抗を入れてしのぐ。Dsc01263

 早く結果が見たいので、一部のモーターだけの結線にして、UDP接続を確かめる。UARTを動かして接続をモニターしながら、テスト開始。

 やった。とても機敏にモーターが動いたり止まったりする。スマホとは比較にならないレスポンスだ。全く問題ない。ところがしばらく動かしている間に、突然モーターが止まらなくなった。あわててロボットアームの主電源を切り離す。暴走だ。こういう機械で最も避けねばならない現象である。不安がよぎる。

 冷静になって、慎重にソースコードを見直した。ははーん、原因がわかったぞ。サーバーは常にクライアントからのUDPメッセージを待ち続け、切れても再接続の初期手続きをやりなおしてループしている。

 GPIOの状態はどうだ。あらあら、通信が途絶えても、前の状態を続けたままだ。これではクライアントの接続が切れると同時に、前の状況のまま暴走する。

 良かった。これが原因に違いない。LEDなら付きっぱなしでも実害はないが、モーターの場合は致命的だ。サーバー側に、通信が途切れれば、必ずすべてのモーターの駆動を止めるステップを加えた。その結果、動きは安定し、今までのところこのトラブルは再現していない。Dsc01260

 ESP8266基板に正式にモータードライバーの制御線を接続し、所定の基板スペースにセットして一段落である。記念撮影する。テストをやりすぎたので電池がへたり、モーターの動きが鈍くなってしまったが、すべてのモーターがリモコンで動くというのは気持ちが良い。

やれやれこれでロボットアームのリモコン化は一段落である。

| | コメント (2) | トラックバック (0)

2017年11月 9日 (木)

ロボットアームをESP8266でリモコン化する

 また、ブログ書き込みの間隔が空いた。懸案のWiFIモジュールESP32を画像付きサーバーにするプロジェクトが一段落して、すっかり肩の力が抜けてしまい、そろそろ一か月を越える。

 とはいえ、このブログは備忘録を兼ねているので休むわけにはいかない。これまでの細々とした出来事を時系列でご報告し、そのあと、突然、その気になった表題のロボットアームの話をご紹介することにする。Dsc01232

 ロボットアームは、将来もっと本格的なものに乗り換えたいのだが(CNCフライス盤キットとどちらにするか迷っている)、とりあえずは、トイ(玩具)レベルのロボットアームキットで勉強することにする。動いたらこれをESP8266か何かでリモコン化しようと思う。詳しくは後半で。

CディスクがS.M.A.R.Tチェックで、BADになりディスクをSSDにした(10/1/2017)
 ESP32の画像サーバー開発に取り組んでいたころから、メインのPCがまたおかしくなった。BIOSの段階でハードディスクのエラー警告で止まる。エラーは、1TBのCディスクのハードチェックS.M.A.R.Tである。不良セクターの数が限界に近付いているようだ。

 今のところファンクションキーを押せば何事もなく立ち上がるが、この状況は爆弾を抱えているようなもので、このままにはしておけない。ウェブなどで探索するが、エラーの数が限界を越えたものをもどす方法はない。ハードを取り替えるしかないようだ。

 ハードディスクの購入や交換は造作のない話だが、中味をそっくり別の物理媒体に移すのは結構面倒である。ネットで簡単な方法を探しているうち、何も今さらHDDではなくSSD(Solid State Disk)に取り替えてしまえば良いことに気づいた。前からSSDにしたかったので一石二鳥である。

 どんなSSDが良いか調査を開始する。なんと240GBのサイズが一万円を切っている。現在のCディスクの使用量は100GBもないので、これだけあれば十分である。製品も新興メーカーも含め、多種多様のSSDが出回っている。Dsc01235 まあ、メインのCディスクにいくら安くても無名の会社のものを使うのは怖いので、SAMSUNG(ここが信頼できるかは別として)の240GBを選ぶ、それでも1万円少々で手に入る。面倒なので、通販で注文する。ほどなく郵便で届いた。便利な世の中になったものだ。

 早速、一緒に買った5インチベイのアダプターをつけてミニタワーのメインPCの筐体に装填する。ウェブサイトの記事にならい、無料のクローンユーティリティを使って、Cディスクの丸ごとコピーを始めた。このあたりのソフトは昔は有料で、しかも結構良い値段だったけれど今やこれも無料である。

 小一時間で終了した。早速、立ち上げる。おおー、これは超早い。Win10の立ち上げ14秒(BIOS入れて29秒)、シャットダウン10秒。これまでどれだけ早くても、それぞれ45秒、20秒かかっていた。それにしても世の中の進歩はすさまじい。半導体ディスク240GBが1万円しないのだ。

NTPでJST時間を作るには(10/3/2017)
 ESP32の画像サーバーの後始末で、ちまちました作業をやっている。今度入れたESP-IDFのSPIFFSは、生意気にもWifiでNTPにつなぎ、ファイルに時刻を記録している。時刻を見るとどうもGMTである。で、これをJSTに換えようと気楽に調べ始めたのだが、簡単に変更出来ない。ここはUNIXの世界なのである。奥が深い。

 少し調べたところでは、ロケールは日本になっているので、何もしないでTimeコマンドに反映されているはずだが、そうなっていない。それとも、NTPの数値はあくまでもGMTなのか。Timeコマンドの基本的な構造を理解していないので、手さぐりのトラブルシューティングになっている。

 たいしたことでもないことに時間をとられている感じがして、今一つ身が入らない。それでもソースコードを見ているうちにふと閃いた。Timeはある時刻からの積算秒を返す。それなら、GMTと日本時間の差9時間分の秒数を常に足してやればよいのではないのか。

 で、9X60X60=32400 を出てきた時間(秒)に足してみた。やった。ちゃんと時刻は日本時間になった。何というか、子供の時に「ずる」をしておやつを余分に貰った気分である。何となく後ろめたいが、まあ、次に行こう。

ESP-IDFの環境で日本語が通らない(10/4/2017)
 さらに気になっているのが、ESP32の画像サーバーのindex.htmlで日本語が化けることである。ソースのエディターのTeraPadでは正常に日本語が表示されるのに、ESP-IDFの開発環境mingwで見てみると、完全に字化けしている。mingwそのものは日本語メッセージが出ているのにソースの中の日本語が化ける。

 当然、ホームページの日本語は化ける。はて面妖な。どうでもよい話だが何か気に喰わない。当面やることがないので、少し本腰を入れる。ソースファイルのTeraPadのエンコードはUTF8になっている。それなのに、ESP-IDFのコンソールで字化けしている。

 ESP-IDFのコンソールが完全に日本語化(UTF8)されていることは確認した。そうなるとエディターTerapadの問題だ。バイナリーエディターを使って作られたテキストファイルを検証した。その結果、驚くべきことがわかった。

 Terapadは一旦シフトJISで作ったテキストファイルを編集画面上のオプションでいくらUTF8にしても、途中からUTF8に換わらない。エンコードをUTF8と指定した空のテキストファイルを起こし、そこで日本語を入れればUTF8になるが、一旦シフトJIS(それ以外は検証していないが)で作ったテキストファイルに後からエンコードをUTF8に直しても、UTF8にならないのである。

 要するに、TeraPadの不具合だ。いやもしかするとどこかにオプションがあったり、こういう仕様なのかもしれないが、フリーソフトなので余り追及する気にはならない。いずれにしても、空のファイルから日本語を入れ無事ホームページは日本語になった。このファイルにあとからシフトJISの日本語データを他からコピペして持ってきてもUTF8になる。

ESP8266はやっぱり遅い(10/8/2017)
 雑用が多くて、このところ電子工作に向かう機会が少ない。PCのエクセルで3日近く数字と格闘していたので、気分なおしに工作がしたくなり、久しぶりにESP8266を動かしてみた。

 ESP8266に、このあいだESP32で使ったjpgファイルを持ち込んで、どの程度の速さかを確認してみようという実験だ。これまでの画像ファイルは12KB足らずの小さな画像なので、ESP32で使った同じ40KBのjpgファイルを表示させてみれば直接比較ができる。

 前のブログ記事を見ながら、SPIFFSのアップロードを始めた。おやあ、エラーが出て途中で止まる。これまでと変えたところと言えば、ArduinoIDEでフラッシュサイズを最大の4MBに広げた。(前は1MBにしてあった)。

 ESP8266のフラッシュメモリのサイズは公称4MBだが、ウェブには、2MBしかないとか色々議論があるようで、これの検証も兼ねて4MBにしてみたのだが、いずれにしても動かないなら仕方がない。これを1MBに戻して再度挑戦。おお、ファイルのアップロードが順調に始まった。

 問題なくアップロードが終了し、ファイル名を前のファイル名と同じに換えて動かしてみる。これなら再ビルドも不要だ。うむ、動いた。いやあ遅いな。ESP32では一瞬だったが、やはりのったりと画像が出る。

 価格的には、ESP8266とESP32は余り違いはないので、これからはESP32を使う方が良さそうだ。I/Oピンもはるかに多いし。

DS3231の恐るべき精度(10/9/2017)

 ESP8266のボードの近くにTODクロックのDS3231がころがっていた。これをいじってから、もう一年は経っている。久しぶりに動かしてみる。ESP8266で動かしたことのあるI2C接続である。スケッチを取り出しI2Cをつなぐ。順調に時計が動き始めた。

 出てきた時刻を見て目を疑う。何と、数秒も狂っていない。ブログを慌てて読み返す。それによると最後の校正時間が2016年の4月1日とある。1年と6か月。そのあいだの誤差が1秒足らず。

 何かGPSかNTPで較正したとしか考えられない正確な表示で、狐につままれた感じだ。これは恐るべき精度としか言いようがない。それとも、ちょうど一年の寒暖の差で補正されたのかもしれない。

ESP32で固定IPアドレスの設定に成功したがNTPが通らない(10/17/2017)
 ESP32の次のテーマが見つからない。画像を出すようなウェブサーバーのアプリケーションがないのだ。これまでのDoit(懸案)メモを見なおしていると、ESP32のIPアドレスの固定化が懸案で残っていた。

 当初、固定アドレス化はすぐ着手したのだが、ArduinoIDEと違ってESP-IDFには、固定アドレスを設定するAPIが見当たらない。ESP-IDFでは出来ないと言っているサイトもある。それでそのままになっていた。

 それが、久しぶりに、ESP32 static IP addressなどでウェブを探したらやり方を紹介する海外のサイトが見つかったのである。それも一年も前のフォーラムでの議論だ。あとをたどって、ここをみつけた。

 入れてみた。最初、構造体をグローバルにするとコンパイルエラーになったので、ダメ元でローカル(Wifiの初期化ルーチン)に入れてみたらすんなり通った。早速実験する。おおお、うまく行った。あれだけ探していたのになぜ今まで見つからなかったのだろう。不思議なほど簡単に見つかった。

 得意になっていたのも束の間、こんどは、NTPのアクセスがうまくいかなくなった。うーむ、次から次にトラブルが起きるなあ。元へ戻すと大丈夫。staticアドレスにしたことでNTPが見つかっていない。

 DHCPがやってくれていた、NTPのURLの名前解決が出来ていないようだ。で、生のIPアドレスをnslookupで調べてそれをコードに埋め込んでみた。よーし、これならstaticでもNTPが動いた。

 原因を究明する。そもそも、固定(static)アドレスを指定するAPIの構造体には、IPアドレスとゲートウエイアドレス、それにnetmaskのメンバーはあるが、ネームサーバーのメンバーがない。バグではなくて仕様なのかもしれない。

 解決法は見つけられない。ESP-IDFには、mDNSという名前解決をローカルでやるネームサーバーのスタックがあるので、これを使えということかもしれない。いずれにしても、ここもUNIXの世界で、そう簡単に答が出る話ではない。まあ、これはこのあたりで深入りは止める。

ArduinoIDEでもESP32のSPIFFSサポートが始まった(10/19/2017)
 そうこうするうちに、ESP32のArduinoIDEでも、フラッシュファイルシステムをサポートするようになったことが判明した。うーん、こちらの方が楽か。ESP-IDFはやっぱり、日本で使っている人が少なく情報がとりにくい。

ロボットアームに興味が移って、キットを衝動買い(10/22/2017)
 秋雨前線が居座ったり、台風が来たりして連日雨にたたられ、自宅で引きこもることが多くなった。電子工作もテーマが品切れでやることがない。それでも、見るともなくウェブをさ迷っていたら、ちょうど良い遊び相手が見つかった。

 それは、ロボットアームである。昔(と言っても7~8年前)、エレキットのロボットアームに興味が湧き、一時は購入まで検討したことがあるが、その後、熱が醒めてそのままになっている。確か、商品を画像認識で、色別に仕分けしていたサイトで使われていた。

 久しぶりに、「robot arm」をキーワードにウェブで調べてみると、そのころに比べると海外も含めて多数のキットが売り出されていることがわかった。すべてアマチュア向けであるが、多種多様のロボットアームのキットが売られている。

 玩具レベルのものから、海外製品では、3DプリンターやCNC加工にでも使える数十万円のものまでたくさんある。玩具レベルのものは普通のDCモーターだが、少し高級になるとサーボモーターが多い。ステッピングモーターを使ったものはアマチュア向けにはないようだ。これは位置決めの仕掛けが難しいからだろう。Dsc01226

 所長が選んだキットは、¥5,000余りの日本製の「グリッパーアームロボット40320C」である。有線リモコンの5軸のDCモーター駆動で、先端に名前の通りはさみ(グリッパー)がついている。ツートーンカラーで、デザインが洒落ているのが気に入った。

 DCモーターなので、自動制御のようなことは出来ないが、有線をESP8266のようなものでワイヤレスにすることはできそうだ。画面を見ているうち急に欲しくなり、思わずアマゾンで注文のボタンを押してしまった。

電池が原因で片側が動かず、あせる(10/25/2017)
 キットは、4~5日で届いた。早速、記念撮影し、中を開ける。丁寧な組み立て説明書がついているので制作に不安はない。リモコンのコントローラーまで組み立て式で、スイッチは大きな金属片でプリント基板と接触させる。バラストを兼ねた単一電池4本を2本づつ正転と逆転用にわけ通電する方式で電子的な部品は一切使っていない。Dsc01227

 プラモデルのような部品を組み合わせ、モーターユニットを作っていく。3時間程度の作業を2回かけて2日で完成した。勇躍テストに入る。ところが逆転ができない。ひとつひとつのモーターユニットはテストが済んでいるので、問題はコントローラー周りだが、おかしなところは何もない。

 大体、部品など何もついていない回路で疑うところは電池のホルダーのところだけだが、しっかりハンダ付けで固定されている。しかも片側だけ動かないというのが気に入らない。テスターまで持ち出してやっと原因がわかった。Dsc01228

 何と片側の電池1つが、へたっていた。無負荷で測ると、1.5Vを指すが、電流を流したとたん0V近くまで下がる。使ったあとの電池が紛れていたようだ。単一電池は、他の小さな電池に比べると、へたると格段に高い内部抵抗を持つことが分かった。

 やれやれ、この電池のおかげで2回、配線ボックスを分解させられた。電池を取り替えてめでたくロボットアームは上下左右、自由に動くようになった。暫く夢中になって遊ぶ。ただリモコンのスイッチが固く、小さい子供さんが動かすのには苦労するだろう。Dsc01234

 次の目論見は、これにモータードライバーを入れてタクトスイッチだけで動くようにすることだ。最終的には、ESP8266を使ってワイヤレス化する。

#22AWGの基板配線はとても難しい(10/28/2017)
 モータードライバーで動かす基板制作を始める。キットの元の基板のマウントを利用し、秋月のC基板を少し削るとピッタリ入った。ESP8266あたりを付ける広さも確保された。Dsc01230

 例のモータードライバーDRV8835を3つ、コネクターの周りにレイアウトし、5つのモーターの制御を行う。6つ制御できるがひとつは未使用のままにしておく。念のためアートワークも描いた。配線はモーターなので細いUEW(ウレタン)線ではなく、#22の耐熱撚線(UL3265)を使う。こういうときのために買い置いてある、少々のハンダ付けの熱でも全く溶けたりしない丈夫な被覆を持っている撚線だ。

 配線を始めてちょっと後悔した。#22は少し太すぎて、DIPピッチではピンとピンの間を通すことが出来ない。まあ、被覆があるので接触することに神経質になることはないが、もう少し番手の大きい#24あたりが良かったかもしれない。しかし乗り掛かった舟である。そのまま配線を進める。Dsc01231

 ちなみに、22番の撚線の断面積は、0.633平方mmで、厚さ35μmのプリント基板配線だと9ミリぐらいの幅に相当する。#24くらいの撚線で配線すれば問題ないかも知れない。これで5ミリ幅程度、1Aクラスのモーターまで大丈夫なはずだ。

 久しぶりの基板の配線に夢中になる。苦労すればするほど出来上がったときの喜びは大きい。ただ最近は集中できる時間が短くなって2時間が限度だ。制御線はUEW線で済ませ、一日2時間程度の作業で5日で仕上がった。

DRV8835モータードライバーの在庫切れ(11/4/2017)
 しかし、問題が残っている。DRV8835そのものの手持ちが2つしかない。ひとつ足りない。未実装のDRV8835はアダプターの配線だけで先に進んだ。4つのモーターの動作確認は済んだが、まだ全体には組み込めない。Dsc01233

 秋葉原に車で出かけて秋月電子に向かった。なんと!DRV8835が売り切れている。11月上旬入荷予定とある。そのあとネットで入荷を確認して店にいったがまだ届いておらず、結局3回も秋月に通って11月4日遂に3個めを手に入れた。 

 帰ってすぐブレークアウト基板をハンダ付けする。とりあえず制御線だけ引き出し、ミニブレッドボードにタクトスイッチを並べてテストする。

 タクトスイッチはモーター5つに6ケ。モーター一つにスイッチを2つ設けて、正転、逆転それぞれ受け持たせるのが一番自然だが、これだと、制御線が10本になってしまい、将来のリモコンには多すぎる。esp8266は9本しかGPIOピンが使えない。

 このために、DRV8835のモードは、始動/停止と、正転/逆転にわかれたモード1を選ぶ。正転/逆転のピンは全部共通にしてピンの節約をはかった。

 とにかく、タクトスイッチによるリモコンは完成した。思っている以上に紙数が増えたので今回はこのあたりで。

| | コメント (3) | トラックバック (0)

2017年9月28日 (木)

WiFiモジュールESP32で画像付きサーバーの開発に成功

 前回までのブログは、失敗続きで暗かった。この年(もう70才を数年越えた)で、無謀にもみんながやっていないI2Cのクロックストレッチをソフトで実現しようとして、ハードウエアの基礎知識不足を見事にさらけだし、あえなく撤退した。

 しかし、今度の記事は胸を張って明るく報告できる。今流行りのWiFiモジュールESP8266の兄貴分ESP-WROOM-32(以下ESP32)で、画像付きのウェブサーバーの開発に挑み、このほど動かすことが出来たのだ。 Dsc01199

 ESP8266ではフラッシュの部分をファイルシステムにするSPIFFSがArduinoIDEで用意されていたので、これを利用して画像データファイルをホームページに表示することが出来た。ただ、ESP8266では性能的に一杯一杯で、わずか12KB程度のjpegファイルの表示に、ひといき(0.5秒くらいか)時間がかかり実用的とは言えない。

 ESP32は、ESP8266に比べると、CPU数が1から2、クロックも1.5倍(160->240Mhz)と性能が一段と強化されている(他にもBlueToothなど機能も豊富になった)。こいつなら少しは実用的な画像を背景にしたホーム画面や、イラストで作ったボタンが使えるかもしれない。
ここが詳しい

 ところが、ESP32のArduinoIDEの環境では、今のところSPIFFSが動いていないようなのだ。(このブログ参照)しかし、ウエブ情報を集めていくと、製造元(espressif社)の提供する開発環境、ESP-IDFや、他のプロジェクト(Rua-RTOS)で、フラッシュファイルシステムを作ったという話が出てくる。

 うまく動いているらしいが、リンク先が海外で、いまひとつ確実なことがわからない。でもここまできたらESP-IDFを導入して画像が出るところまで動かし、ESP8266との差を確かめたくなった。

 以下は、ESP-IDFの環境整備から、画像表示に成功するまでのESP32開発記録である。実は終盤になって画像を表示させるのにSPIFFSより遥かに簡単な方法が見つかるという、どんでん返しがあったのだが、詳しくは本文で。

ESP-IDF開発環境の導入から始める(9/2/2017)
 ESP-IDFとはArduinoIDEとは別の開発環境である。製造元の正式環境だが、make主体のCUIの世界で、WindowsにLinuxの環境を作るなど、準備に手間がかかり、今まで敬遠してきた。しかし目標である画像の出るサーバー画面の実現のためには避けて通れなくなった。

 気分を新たにして、開発環境を準備する。ハードウエアはArduinoの時と同じ秋月で売られている純正ブレークアウト基板DevkitCを使う。こいつは横幅が広いので普通のブレッドボードに差すとジャンパーが出せなくなるが、ここはミニブレッドボード2枚を並べてしのぐ。

 ESP-IDFのインストールは紹介するサイトが今や山ほどある(以前は少なかったが)。戸惑うことはない。むしろ沢山ありすぎて何を選べば良いのか迷うほどだ。まあ、余りこだわることはない。こことかこのあたりを参考にインストールを始めた。

 最初のmingw(Win上のLinux環境)のインストールファイルが500MB近くもあり、サーバーの線が細くてダウンロードに1時間近くかかったのが問題だったくらいで、インストールそのものは、意外にも順調だった。ここでも「ねむいさん」のブログにお世話になる。彼(彼女?)は何と去年のうちに環境をインストールしテストまでされていた。

 mingw上に自分のホームディレクトリを作り、開発環境は出来上がったが、沢山のサイトを拾い読みしていたために、ホームディレクトリの位置がさまざまで、esp-idf(開発環境本体)のディレクトリパスが中々通らない。何とか、ごまかし、ごまかし(mingwなので、サブディレクトリ区切りがバックスラッシュ\と、/が混在してややこしい)、makeが通るようにする。

 やっと動き出して、中味のファイルや、サンプルコードを覗く。ここはC++でもなく、純然たるCの世界だった。STM32で少しかじったFreeRTOSがメインのOSのようで、何か久しぶりに旧友に会ったような気分でなつかしい。

 ただ、MakeFileのあたりの情報隠蔽がかなり深い。実際のMakefileの中身が全く表に出て来ないので何をやっているのかわからない。ソースがメインプログラムしかないのも不思議である。わからないことだらけだが、とりあえず先に進む。

LチカとHelloWorldは簡単に動いた(9/3/2017)
 以前の記事のとおり、ESP32はArduinoの環境で既に動かし、LEDをウェブから制御できるサーバーまで作った。それでもESP-IDFの環境に慣れるため、サンプルソースにLチカ(blink)と、hello worldのソースがあったので、これらを使って練習することにした。

 ホームディレクトリに、サンプルソースの一式(AVRで言うプロジェクトのようなものか)をコピーし、make menuconfigで、シリアルラインの定義をしたあと、makeに入る。延々とビルドが始まった。

 ふーむ、Lチカくらいで、何か、すべてのリソース(IPV6からBluetooth、SSLまで)をビルドしているようだけど、どう言うことなんだろう。まあ、何十分もかかるわけでもないので待つしかないが、何か無駄のような。

Esp32_spiffs  Lチカは、指示通り、make menuconfigでIOピンの位置を修正する。前に使ったLEDをGPIOに設置し、makeに入る。幸いNO Errorのようだ。続いて、make flashでファームに焼く。これもエラーは出ない。すると、めでたくLEDが1秒近い間隔で点滅し始めた。よーし、動いた。

 次は、Hello worldである。もうひとつ手順が増える。make flashのあと、make monitorでコンソールにUSBコンソールのCOM3仮想ターミナルを立ち上げる。やたらとメッセージが多いが、無事、コンソールにHello World!の文字が10行づつ繰り返された。これも問題ない。

SPIFFSのgithubを見つける(9/6/2017)
 次は、HTTPサーバーだが、その前にこれまで見つけてあるSPIFFSプロジェクトを入れることにした。目星をつけたいくつかのサイトを調べているうち、英文だが、外国人(イタリア?)の英語なので、とても理解しやすいサイトを見つけてある。

 以前に見つけたところとは別のサイトだが、esp-idfの環境で、SPIFFSが出来たという報告である。沢山の感謝とお礼のレスポンス付きだ。これは間違いなく動いているようだ。喜び勇んでダウンロードする。

 順調に進むかと思われたが、そう簡単に問屋は許さなかった。今度も、ディレクトリパスが難しい。make menuconfigそのものが通らない。いくつかの関門を潜り抜け、menuconfigまで行ったが、今度は本番のmakeでビルドエラーが出る。残念!

 何かおかしい。インストールした場所が悪いのか。githubなので、clone先が所定のところにないと、正しく動かないようだ。余り深入りは避け、次の日、出勤した事務所のPCで最初からインストールしてみた。これが不思議、makeが通ったのである。

SPIFFS動作成功(9/8/2017)
 帰宅して、もう一度やり直す。やった。makeが通る。make flashで実際にファーム焼き込み。これもうまく行った。原因はやっぱりgitを展開するディレクトリの位置だったようだ。いやあ気難しい。

 まあ、あまりこれにこだわっていても仕方がない。先に進もう。それにしても単なるフラッシュだけの操作なのだけど、LチカとHelloWorldと同じように、延々とすべてのライブラリのコンパイルが続く。

Ws000032  testSPIFFS.cのソースコードをあらためて精読する。mainで各種の関数をテストし、それをコンソールに出力している。そんなに複雑ではない。これだけで動くようだ。何はともあれmake monitorでコンソールを動かしてみた。

 やった、それらしい出力が次から次に出力される。ディレクトリを増やしたり(mkdir)、ファイル一覧(ls)なども出来る。うむ、うまく動いているようだ。フラッシュファイルにアップロードする方法がまだわからないが、テスト環境には、フラッシュに入れたファイルイメージが残されており、何らかの方法でアップロードは出来るようだ。

 ここまで進むと先は見えてきた。ESP-IDFのサンプルソースにはHTTPサーバーのソースがあるので、このSPIFFSを、サーバーに合体させれば動く見通しがついた。どちらを母体にするか迷ったが、構造の複雑なサーバーのソースコードにSPIFFSの要素を組み込んでいく。その前に、HTTPサーバーを動かしておかないといけない。しかし、これが意外と難渋したのである。

やっとホームページが出せた。サンプルソースでは動かない(9/18/2017)
 サンプルがあるので、簡単にHTTPサーバーは動くかと思ったが、これがなかなかいうことを聞かない。いくつかあるHTTPサーバーのソースの一つをビルドしたが、ホームページ(index.html)を出すようなところが見当たらない(http_request_server)。

 やっていることは、どこからかのソケットを受けてそれをSTDOUT(コンソール)に表示するだけである。これはサーバーではないよね。クライアントがやることだ。少なくともesp-idfのサンプルソースesp-idf/examples/protocols/http_requestと、https_requestにあるソースには、リクエストしかなく、これでは動かない。

 困ったときはgoogle先生である。esp-idf http_server などのキーワードで検索を続けると、別のそれらしいソースコードが見つかった。ドイツの電子工作ショップのサイトで、ソースだけで説明記事に戻れないが、コードを読む限りでは、クライアントのリクエストに対してindex.htmlを返す部分がある。もうひとつタスクが必要のようだ(netconn_server)。

 半信半疑ながら、このソースに取り替えて、再度ビルドしてみる。よーし、OK! 簡単なindex.htmlが表示された。良かった。でも、なぜ本家のサンプルには、本来のHTTPサーバーの雛形がないのだろう。謎である。次はいよいよhtmlファイルのフラッシュファイル化に進む。

HTTPサーバーの解析に夢中になる(9/16/2017)
 フラッシュファイルを入れるため、サーバーのソースを読みふける。おおー、段々全体が見えてきた。嬉しい。いや勉強になる。これまで近づこうとしてなかなか機会のなかったソケットプログラムだ。lwipとか、nghttpとか、新しいプロトコルを知る。

 電子工作ではなくて、ウェブプログラミングで遊んでいる。この世界も複雑で奥が深い。HTTPサーバーの教科書が少ない。事務所の帰りにいつもの秋葉原書泉で参考書を探すが、自分が知りたい基礎の部分を解説したものはなかなか見つけられない。

 このesp-idfの開発環境にも大分慣れてきたが、それににしても、このフルビルドは何とかならないか。延々と必要もないモジュール群をコンパイルしていく。一旦コンポーネント(ライブラリ)が出来ると、あとは少し早くなるが、それまでは大変だ(まあ、モジュールを選択するのも大変なので、こういうやり方もあるか)。

 文字列の連結、文字列のサーチなどArduinoIDFにはあった機能をせっせと開発する。コーディングとしては楽しかったが、これらはすべてCの標準関数(string.h)にあることがわかって、お蔵入りした。完全な無駄足である。

SPIFFSでテキストファイルの送出は成功した(9/22/2017)
 画像表示は、読み込みのとき大きなバッファースペースが必要なので、まずは文字ベースでindex.htmlに埋め込む方法をテストする。これが結構難しい。どうも思ったようにhtmlに展開してくれない。

 それより問題なのは、nett_conn_serverというFreeRTOSのタスク上でSPIFFSを動かすとstack overflowでプログラムが落ちるのである。menuconfigなどでスタックサイズを広げるが改善されない。これもウェブで調べて解決方法が見つかった。タスクを起こす関数に、スタックサイズを指定するパラメーターがあったのだ。

  これを通常の3倍(6144バイト)まで広げてやっとstack overflowは止まった。しかし、それでもindex.htmlに思ったような文字列が出てこない。何回か試行錯誤するうち、重大な誤りをみつけた。

 文字列の長さを得るのに、sizeofを使っていたのだが、ポインターを使った文字列では、これがアドレスを収容するエリア(ここでは4バイト)になってしまうことに、だいぶ後になってから気づくというお粗末である。Esp32spiffs1

 しかも、関数の引数にすると呼ばれた先では、strlenでも文字数が正しく得られない。それやこれやで苦闘の結果、何とか出せたのだが、<object src=XXXXX />のタグでは、スクロールバーのようなものが出てしまう。目的は画像ファイルなので、道草を食いたくないのだが、テキストファイルの表示だけで四苦八苦である。

何と、もっと良い方法を見つけた。バイナリの埋め込み(9/24/2017)
 色々とウェブをさ迷ううち、SPIFFSではない、もっと楽な画像ファイルの表示方法があることを偶然つきとめた。いや情報は浴びるように摂っていれば良いことがあるという言葉どおりの快挙である。

 esp-idf esp32 webserverなどのキーワードで、調べているうち、スマホのきれいな画像のボタンでLEDをウェブから制御しているページを見つけた。

 ボタンがきれいなイラスト画像(pngファイル)である。へえー、サーバーでどこかのクラウドサーバーにリンクして画像を持ってきているのだろうかと、思っていたら、どうもそうではない。Ws000001 mainと同列にある、component.mkファイルにCOMPONET_EMBED_FILES:=でファイル名を定義すると、これをbinary dataとしてフラッシュに埋め込んでくれるというのだ。

 これはすごい。以前、AVRでやったことのある、フラッシュにバイナリーデータを埋め込むobjcopyと同じ手法である。埋め込んだ後、エントリーポイントを取得すれば、プログラムのなかでこのバイナリーデータを使うことが出来る。

 まだSPIFFSではjpegファイルまで進んでいないが、ファイルを読み込まなくても、外部参照だけでデータをとりこめる。しかもバッファーの長さを気にする必要もない(コンスタントデータなのでバッファーの長さは気にしないで良い)。

 これは試してみるしかない。早速、サイトの情報を頼りに、見よう見まねで、適当なjpegファイルをとりだし(SPIFFSスタックの中にあった画像)、component.mkファイルに設定し、ビルドしてみた。おーし、何のエラーも出ずビルドは終わった。

Esp32spiffs2  次はmake flashである。いつもより少し時間がかかるが無事終了した。jpegファイル40KB分だけ遅くなっているか。さあ、make monitorでサーバーを立ち上げる。

 おおー、やった。画像がホームページに出た。しかも早い!一瞬だ。嬉しくて何度もディスプレイの前でガッツポーズをする。ホームページそのものは、画像とテストメッセージ一行の何も意味もないページだが、このあとには無限の可能性が待っている。

SPIFFSでも画像ファイルの送出に成功。そう遅くにもならない(9/25/2017)
 勢いに乗って、SPIFFSでも画像が送れるかやってみる。このnetconn_serverというしかけが良く見えないので、バッファーサイズをどれくらいまで広げられるかわからない。これが、画像ファイルの読み込みを遅らせていた理由だが、もうそんなことは言っていられない。適当なサイズ(4KB)でneconn_write()を繰り返し発行することにする。

 恐らく、バイナリ埋め込みに比べれば遅くで使い物にならないかもしれないが、まずはやってみる。動かしてみた。おやあ、またstack overflowで止まる。祈る気持ちでスタックサイズを2048の3倍からさらに4倍の、8192まで上げて再度動かしてみる。

Esp32_spiffs3  よーし、動いた。そんなに遅くならない。esp-idfについているデバッグ用のメッセージにms単位のタイムスタンプがあるので、これで測ってみると、同じ画像で、埋め込みで平均62msが、SPIFFSだと108msだ。ブロックサイズを広げればもう少し早くなるかもしれない。

 とにかく、ESP32の画像付きサーバーの開発はこれで一段落した。胸を張ってブログに報告できる。

以下に、サーバーのソース一式をONE DRIVEで公開します。ディレクトリごとzipファイルにしたので、これをesp-idfのホームディレクトリに展開し、mainの直上のディレクトリでビルドすれば、バイナリデータを埋め込んでくれます。ソースには2種類のやりかたがコメントとして残っているので、適当に選んでください。WiFiの設定はmake menuconfigで行います。

ここをクリックしてONEDRIVEに行く

| | コメント (2) | トラックバック (0)

2017年9月 2日 (土)

ソフトI2Cはクロックストレッチまで手を出してあえなく沈没

 I2Cのスレーブライブラリの改訂が泥沼に入り込んだまま動けない。アナログの超音波距離計測センサーHC-SR04(以下SR04)を、電源3.3V、I2C化したブレークアウト基板を作ったところまでは良かったが、そのあと、計測を高速で動かそうとして、ソフトI2Cスレーブのプログラミングに大苦労し、気が付いたら一か月が経っていた。

 そもそも、このTiny85を使ったソフトI2Cのライブラリーは、もう2年も前に開発したもので、ソースコードまで公開している。今度の開発でいくつかの不具合が見つかったので、改訂版を出せばそれですむ話なのだが、せっかく再公開するのだから、もう少し機能を増やしておこうと欲を出したのが間違いの始まりだった。Dsc01170

 ソースコードをレビューしているうち、最初の版は、I2Cのマスター読み込みのストップコンディション検知が未実装だったことがわかった。ブログ記事では作ったことになっているが、ソースコードを読んでみると実装されていない。

 スレーブからマスターへの送信(マスター読み込み)の終了は、最後のデータバイトにマスターがNACK応答を返せば止まるので、ストップコンディションは不要と言えば不要である。しかし出来ていると書いてしまった手前、放置するわけにもいかなくなった。それにマスター書き込みの方は、リピートスタートまで(もちろんストップも)実装したのに、何となく落ち着きが悪い。

 そこで、これを追加しようと気楽にコードを加えたのだが、これがうまくいかない。出来上がったプログラムはどうやってもストップコンディションを受け付けないのである。マスターはストップコンディションを出しているはずなのにロジアナで見ると波形が出ていない。謎である。

 脱線につぐ脱線というのが、がた老AVR研究所の通例ではあるが、今回はどうもいけない。迷路に入りすぎだ。I2Cのスレーブ側のプログラムは、すべて割り込み駆動で、SR04を制御するバックグラウンドルーチンとは非同期で同時に動く。デバッグは一筋縄では行かない。

 こういう細かいことに興味のない読者の方々には申し訳ないが、実は所長は、こうした箱庭のような8ビットマイコンのマルチタスク的プログラミングが好きで、つい深入りしてしまう。ロジックアナライザーで全体の様子が手に取るように把握できるようになったので余計やめられなくなっている。

 以下は、この泥沼のようなプログラム開発の一か月の顛末である。しかも今回は撤退に次ぐ撤退の苦しい開発となった。まあ、こういうときもあると自分を慰めている。

懸案のI2C通信と計測の同時処理はあきらめる(8/6/2017)
 前回記事で、SR04のエコーと、I2C通信の共通変数(タイマーキャリーカウンター)を分離して、正しいデータが出たと喜んだのもつかの間、少し待ち時間を短くしていくとまたデータが不正確になってきた。どうも距離の計測値が低すぎるし、安定した値がでてこない。

 ソースコードをもう一度入念に調べる。すると、共用していないはずのタイマールーチンに続々とおかしな使い方が見えてきた。要するに被っていたのはキャリー変数だけではなかったのである。

 まず、肝心のタイマーのおおもとのレジスターTCNT0をI2Cが始まるたびに0に戻していた。最大でも0.26ms(8ビットのオーバーフロー)、音速にして5センチ余りの誤差は、今度の用途(人感センサー)を考えると、そう大きな問題ではないが正確でなくなることには間違いない。Ws000029 さらに、I2Cの通信が終わるたびに、タイマーのオーバーフロー割り込みを止めてしまっていることが判明した。タイマーそのものは動いていても、8ビットタイマーのキャリーが増えていかないのは致命的だ。これが、ときどき距離が不正確になる犯人であった。

 この一週間、デバッグに奔走していた。調べれば調べるほど、エコー時間計測とI2C通信の非同期処理は不可能であることがわかってきた。要するにタイマーが一つしかないところで、タイムアウトと計測を一緒にやろうというのが無理筋だったのである。

 とにかく、こんなにリソースを共用していたらマルチタスクもあったものではない。計測期間中にI2C通信を行うソフトの開発は中止することにした。今回の無駄足は疲労感が強い。もっと早く気が付くべき基本のところを忘れて、深入りしてしまったからだ。 

 当初の方式、センサーのエコーを少し長めに待ち(SR04の最大エコー30ms程度)、データを読み込む方式に戻した。これでも100ms以内で連続して計測が出来る。まあ、人感センサーならこの程度で十分だろう。

マスター読み込みのストップコンディション検知にチャレンジ(8/16/2017)
 エコー期間中にI2Cを動かして計測間隔を短縮しようという目論見は完全にはずれた。意気込んでプログラミングをしようと振り上げた拳(こぶし)の行き先がない。この高ぶった気分を鎮めるために、何か手を動かさないと納まりがつかなくなってしまった。

 そこで、未実装の「マスター読み込み」シーケンスのストップコンディションの検知機能を開発することにした。しかし、これも難儀したのである。しかけは、「マスター書き込み」と同じように最初のデータビットのクロック(SCL)立ち上がり区間で、データライン(SDA)を監視して、ストップコンディションを判定する。

 「マスター書き込み」では、スタートコンディション(これはリピートスタート)もストップコンディションも順調に検知し、動作も確認している。簡単に動くだろうと気楽にコーディングしたのだが、全く動かない。かえって、全体の動作が不安定になってしまった。Dsc01195

 いつものロジックアナライザーにプローブ点を増やして解析する。波形を見ると、マスターがストップコンディションを実行しているのにSDAが上がっていない。つまりストップコンディションが発生していない状態であることが分かった。謎である。

 メモに何枚もタイミングチャートを描いて調べていく。ひとつづつの動きを詳細に確認していくと、驚くべき事実が浮かび上がってきた。「マスター書き込み」なら容易に出来る処理は、「マスター読み込み」では不可能ではないかということである。

ソフトでストップコンディションは作れない(8/20/2017)
 誤解を招かないように補足すれば、ソフトウエアでは実現できないということである。ハードウエアならSCLがHIGHのときのSDAの動きを監視する機構を加えれば良いので問題はない。しかし、ソフトでは同時処理が出来ないので、「マスター読み込み」ではSCLクロックが来る前に、スレーブは次に送るべきビット値を用意してSDAに乗せておかなければならない。

 もし、その値がLOW(0)のときは、ストップコンディションを阻止してしまい、スレーブ側ではそれを検知できないということになる。そもそも、「マスター読み込み」はスレーブ側がSDAラインを上下させてデータをマスターに送る。スレーブがSDAを下げてしまうと、マスターはこれをHIGHにすることが出来ない。

 元から不可能な機能を作ろうと、もがいていたことになる。ack/nackビットを受け取って次のデータの第一ビットの間中SDAラインをスレーブは占有してしまうので、スタート/ストップコンディションをマスターが出せないのである。「マスター書き込み」では、SDAラインはマスターが制御するので問題ない。

 とにかく、「マスター読み込み」のとき、ソフトでスレーブ側のストップコンディション検知は実装できないことが明らかになった。この2週間余りの作業は全く無意味なものになった。お馬鹿としか言いようがない。エコー期間のI2C騒動と、このストップコンディション開発を撤退するにあたり、反省をこめて何が悪かったのかまとめてみる。

教訓:

  •  一度に複数の機能をデバッグしてはいけない。どれが原因か特定するのが難しい(欲張るな)。プログラムをなめてかかって、いくつかの機能をまとめてコーディングしていた。原因が見つけにくいうえに、単独でバグをつぶしていくより、結果として余計な時間がかかっている。
  • 基本的な機能から確認していかないと何をやっているのかわからなくなる(急がば回れ)原理を理解せずに、小手先のコーディングが多すぎた。タイミングチャートをいくら詳しく描いて、コードを工夫しても、I2Cの基本を忘れていたら何にもならない。
  • 思い込みは可能な限り見直す(これは定数だから変わらないと思い込むな)わかっているはずなのに、この思い込みというやつは魔物である。すべてを疑うという視点をなくさないようにと気を配っていても、つい先のことに気を取られて基本部分を忘れがちになる。

 やれやれ、現役時代、さんざん後輩に言い聞かせてきた原則ばかりである。このブログにも偉そうに何度も同じようなことを書いてきた。それがこのざまである。お恥ずかしい。まさしくプログラムは考えたようには動かない、書いたようにしか動かない、である。

 この記事はあとから書いているので、まだ冷静な話になっているが、デバッグの最中は暗中模索、ロジアナの前で悪戦苦闘であった。もうやめようかと何度も思った。Tiny85のファーム書き換えはSR04を外す必要があり、ビルドを繰り返しているうち、ブレッドボードの接触不良で動作が不安定になったりする。散々である。

 ただ、ロジアナの威力は今さらながらすごいと感動した。プローブの数を増やしていけば、色々な所の可視化が可能になる。今回も、マスター側からもプローブを出せることに気づいたのは大きかった。これによって、マスター側が正常に動いていることを確認でき、自分の愚かな思い込みに気づくことが出来たからだ。

超音波センサーユニットの配線図とライブラリソースコードの再公開(8/19/2017)
 とにかく開発は一段落した。ライブラリーも安定して、これまでのように時々、0値が連続したり、異常値が出たりすることはなくなった。思い当たる不具合は、これまでのところ全部つぶした。

 最後までわからなかった偶に起きるデータ異常値は、ロジアナの波形を精密に調べなおして、SCL割り込みがタイマー割り込み(オーバーフロー)によって遅れ、その結果、SCLクロックが外れているのを発見した。I2cslaveoverhead

 タイミングによっては、これがスタート/ストップコンディションとみなされ、そのあとのデータが欠落する。Tiny85のCPUクロックは8MHzで、内蔵CRクロックなのでこれ以上は上げられない。SCL割り込みのオーバーヘッドは8μs内外で、クロックが40Khz(半サイクル12.5μs)のI2Cでは、ギリギリである。

 I2Cはこれ以上遅くしたくないので、タイムアウト用のタイマーの割り込みを起こさないようにするしかない。プリスケールを8から64に上げ、メッセージが16文字以内なら割り込みが起きないようにした。テストの結果、20文字以上送っても、数値の乱れはなくなった(必ず起きるわけではない)。

 お約束のソースコードと配線図を掲載する。I2Cライブラリーそのものは上記のようにすべて改善に失敗したが、マスター側とSR04制御部には若干の機能を追加してある。
 以下に例によってZIPで固めたソースライブラリ、readme.txt、配線図ファイル(.bs3)を置きます。 
   「I2CslaveSet_2.zip」をダウンロード

 コマンドの解説など詳しくはreadme.txtに説明した。以前の公開したライブラリーはうまく動かないところもあるので、この版のライブラリを使われることをお勧めする(当該ブログ記事にも注記)。

I2CスレーブライブラリーとSR04測定ルーチンの改善点(8/21/2017)
 テスト用の親機のTiny861とのペアで追加した機能と、修正した不具合の部分を以下にまとめておく。

I2cslave_85_2

追加した機能:
(1)    連続距離測定
SR04の距離測定が0.2秒間隔で開始され、UARTコンソールに測定値が1行づつ表示される。人感センサーなどで機器を動かしながら最適位置を見つけるのに便利。リターンキーを押すことで測定は中止される。

(2)    スレーブ側からの独自データ送出
サンプルとして、スレーブ側のソフトのバージョン番号をフラッシュに定義し、それを表示させる。I2C化するディバイスのレジスター値などを表示するのに使える。

(3)    バッファーデータの16進データ表示
スレーブの持つ送受信バッファー(36バイト)を全部表示する。本来はデバッグ用。

修正した不具合
(1)    マスター読み込みでのスレーブ側の不正データ送信のバグ修正
タイマー割り込みのオーバーヘッドで、送ったデータが欠落したり、文字化けが起きていたのを修正。

(2)    スレーブ側の連続データ送出でのバグ修正
マスターから送ったデータの戻しでバッファーサイズ分を全部表示できなかったのを修正。

 いやいや、長い間かかったけれど、何とか納まった。ウェブで見る限り、AVRマイコンでソフトI2Cスレーブの開発例は殆どない。あっても、すべてUSIというAVR独自のハードインターフェースを使ったもので、この開発のようにGPIOだけで作った例はひとつもない(自分で探した限り)。

 ちょっと鼻が高いのだが、これは完全な自己満足の世界である。ということで、さらに挑戦しようと、欲を出して恥の上塗りをすることになった。それが、次に紹介するクロックストレッチの実装である。まあ、笑わずに聞いてください。

クロックストレッチ実装の野望、もろくも砕ける(8/23/2017)
 I2Cは、原則、すべての通信の主導権をマスターが握っており、マスターの出すクロック(SCL)に従って複数のスレーブが動作する。これに対し、クロックストレッチとは、I2C通信でスレーブが、マスターを待たせる唯一の手段である。

 スレーブの処理速度が遅く、マスターの要求に応えられないときなどに使う。SCLラインをいずれかのスレーブがLOW(0)に落とすことによって、マスターはSCLの発行を止め、スレーブが解放(HIGH)にすることで再開する。
実装は簡単に見える。マスター側で、クロックライン(SCL)を監視していて、誰か(スレーブの誰か)がSCLをLOW(0)に落とせば(いわゆるワイアードNOR)、それがHIGHになるまで通信を止める(クロックパルスを延期する)。

 スレーブ側はもっと簡単である。必要な時にSCLをLOWにしてしまえば、すべての交信はストップする。また、HIGHに戻せば、マスター側が待っているから再開する(はず)。鼻歌交じりで、双方をコーディングし、勇んでテストに入った。これが地獄の始まりとは露知らず。

 テストの前は、クロックストレッチが実際に行われているかの実測のため、タイマーを再整備したりして余裕だったのだが、実際には全く動かなかった。スレーブでクロックストレッチをかけた途端、すべての反応は止まる。ハングアップである。

 ロジアナで様子を見る。通信シーケンスは、スレーブがクロックストレッチをかけたとみられるところから、見事にSCLがLOWになったまま、最後まで動かない。あれ、おかしい。マスターが待つのはともかく、スレーブがどうして引きすられる?

 スレーブには1秒タイムアウトが設けてあって、I2Cの通信が1秒以内に終わらないと通信を終了させて初期状態にもどるようになっているはずだ。

 あっあっあー、だめだ。スレーブ側の割り込みプログラムのなかで、SCLがHIGHになるのを待っている。これではバックグラウンドのコマンドでいくらSCLを元に戻そうにも、永遠にバックグラウンド側に戻ってこない。いわゆるデッドロックである。

 悪あがきで、多重割り込みでスレーブ側に短いタイムアウトを設け、別のところで待つようなしかけも考えた。avr-libcには多重割り込みを認めるマクロはあるが(リニアPCMプレーヤーで使用)、今度の場合は、バックグラウンドに戻っても、スレーブの割り込みプログラムに帰れないので意味がない。

 クロックストレッチをスレーブ側が要求するとき、あらかじめ割り込みルーチンの進入を止めておくという姑息な方法もあるが、マスター側の通信要求がいつ発生するか分からないときに、スレーブを止めるのは著しく可用性を失う。

 要するに、ハードでのみ実現できる機能で、そもそもソフトでやろうというのが無謀だったのだ。クロックストレッチという誰も実現していない機能を実現してやろうという野望は、もろくも消えた。

 やれやれ、三度にわたる敗退である。暫くは立ち上がれそうにない。ただ、この電子工作は、定年後の重要なライフワークのひとつになっており、もう今さら止めるわけにはいかない。

 今、考えている次のテーマは、ESP32で、課題になっていたSPIFFS(フラッシュメモリを使ったディスクシステム)だ。フォーラムなどを見ていると、ESP-IDFという、Arduinoとは違うプラットホームで動き始めたようだ。これを試すのも悪くないかと思っている。

| | コメント (2) | トラックバック (0)

2017年7月26日 (水)

オシロのテストどころかソフト開発で大はまり

 新しいオシロで色々テストするつもりが、久しぶりにソフトのデバッグにはまってそれどころではなかった。超音波距離センサーSR04のI2C化の最中に、avr-libcのバグらしいもの(と最初は確信)に遭遇して意気込んでいたのだが、何のことはない、わかってみたら全てこちらのミスと判明した。いやあ情けない。まあ、それまでのいきさつを最後まで聞いてください。

新しいオシロは機能がありすぎて持て余し気味(6/30/2017)

 ほぼ10年ぶりにオシロ(帯域200MhzのSiglent SDS1202X-E)を新調して、埃をかぶっていた自作のファンクションジェネレーター(以降FG)を棚から持ち出し、FFTとか、シーケンスモードとかの新機能を試そうと、張り切ってオシロに向かった。

Dsc01176 ただし、まだ操作に慣れていないので簡単な測定でも四苦八苦である。トリガーのかけ方がいまいち理解できない。スロープとエッジの違いも良くわからない。FGで矩形波を出し、FFT(高速フーリエ解析)の波形を見るが、思っているような形にはならない。だいたいアナログ機器の調整ならともかく、単にFFTでスペクトル波形を出しても、「で、それがどうした」と言われたら黙るしかない。

  というので仕事の帰り、秋葉原の書泉ブックセンターに寄ってオシロの参考書を探した。入門書はいくつかあるが、中上級のものはほとんどない。技術の進歩が激しいので単行本になりにくいのだろう。雑誌の特集を集めたムック本が2種見つかったが、ひとつはすでに初代のオシロの時に買ったものだった。しかたがないので残りの一冊も買う。Dsc01175

 参考書の中のオシロはメーカーが違うので、パネル面や用語が手持ちのものとかなり異なる。まあ基本のところは大体似たような機能なので迷わないが、ちょっと細かくなってくるとわからなくなる。本来はこの会社(Siglent)のマニュアルを探すべきなのだろうが、日本語のものはないし、とっつきにくい。

 ウェブには何故かこういう紹介サイトもある。しかし、情けないことに半分も理解できない。うーむ、難しいな。知らなければならないことが山ほどある。ここは基本的なやり方を参考書の最初から読みこんで少しづつ理解していくしか方法はないようだ。

 前記事にあるように測定の時間的な範囲が広がったのはとても収穫だが、アナログ波形を見なければ進まない工作は現在していない。そう、宝の持ち腐れと言っても良い。使い道が見いだせないというのはつらいものだ。

センサーのブレークアウト基板を作る。久しぶりハンダ付けが楽しい(7/4/2017)
 いうことで、これまでの工作の続きをすることにした。ブレッドボードに組んでいた超音波距離センサーHC-SR04のブレークアウト基板の制作である。入力を電源3.3VとI2Cだけの結線にしぼり、RaspiやESP8266などの最近のCPUと簡単に接続できるようにする。

 手持ちのケース(タカチのSW70 75X50X35)に全体が入ることを考慮して、秋月のC基板を少し小さくする(72X40)。ここにSR04とTiny85、それに例のストロベリーリナックスのDC-DCコンバーター、秋月で入手したI2C用のレベルシフター(FXMA2102 ¥200)をレイアウトする。Dsc01164

 過去のブログ記事を見てみたら、本格的なアートワークをやる汎用基板でのハンダ付けは数年ぶりのことだ。久しぶりのアートワークそのものが楽しい。ここでの醍醐味は、複雑だった引き回しが部品の位置を少し変えるだけで簡単になることだ。

 パズルを解くのと同じである。何度もアートワークをメモに描きなおし頭を捻る。配線を交叉させないというルールは守れないかなと諦めたころ、ピンヘッダーの方向を逆にするときれいに解決したりする。鬼の子をとったような気分である。実際の工作前にもこれだけ楽しめる。

 アートワークも完成したので、部品を揃えてハンダ付けの工程に入る。ハンダ付けは一気にやらない。楽しみながら少しづつやる。実体顕微鏡を買っておいてよかった。最近TVのCMでメガネにかける拡大鏡を見かけるが、これは精々1.6倍程度で、倍率20倍のこの顕微鏡にはかなわない。ただ、顕微鏡は慣れないと対象物に絞り込むのが一苦労だ。Dsc01171

 配線作業は進む。サインペンでアートワークにハンダ付けした部分を塗りながら、出来上がっていく基板を矯めつ眇めつ(ためつすがめつ)眺めて感慨にふける。考えてみたら、この方式を始めて、そろそろ10年。このパズルのような、UEW線を交差させないアートワークと、この細かいはんだ付けの絶妙な組み合わせが、心をひきつけてやまない。

 自分がこの小宇宙の創造神である。満足感、達成感は、悪いけれどArduinoやRaspiなどでの工作とは比較にならない、至福の時間である。この基板にI2Cスレーブライブラリーを使ったSR04のインターフェースソフトを合わせて記事にしたら喜んでもらえるかもしれない。期待が膨らむ。

使えないHC-SR04があった。ブレークアウト基板はミスなし(7/6/2017)
 サインペンで線を塗るところがなくなった。完成である。ニチアツのコネクターを奢って、圧接ペンチでソケットに入れるピンを用意する(久しぶりなので1ピン失敗した)。SR04は背の高さを低くするため、センサーのピンソケットを平型に換えてある(オリジナルはL型)。テストに入る。Dsc01172

 最初、動かなくてあせったが、沢山あるセンサーユニットSR04のうち、選りによってトラブルのある方を使っていたことがわかり、あわてて正常な方にピンを付け直す。さあこれでどうだ、電源ON。良かった。ブレッドボード上の親機(Tiny861)のUARTコンソールに、距離が表示された。

 やった、やった。基板のハンダ付けは完全試合だった。腕はまだ落ちていないぞ。SR04距離センサーは、このあいだ秋月で同種のセンサー(US-015)を買ってある。ついでにこれも平型ピンに取り替えてテストする。これも問題なく動いた。 

 これで当研究所には、なんと合わせて5つもの距離センサーが揃ったことになった。アマゾンでは2つも買ってあった。このうち正常に動くのは3つ。具合が悪いのは、アマゾンの一つと秋月で最初に買ったもの合わせて2つである。Dsc01166

 ハードは一応、これで一段落である。用途は現在、階段の照明切り替えに使っている赤外線人感センサーの代替を考えているが、人間の近接を距離によってどうやって検知するかロジックが決まっていない。これからテストをして決めていくことになる。

親機のコマンド新設。距離が安定しない。DC-DCコンバーターが怪しいか(7/8/2017)
 SR04ブレークアウト基板のソフトの整備に入る。これまでにI2Cスレーブそのもののソフトは、Tiny85に組み込み、かなり作りこんだライブラリーが完成してコードも公開済みである。

 マスター書き込みでデータを送った後、ストップコンディションを送らずに、続けてスタートコンディションが来ても、これに対応する機能(リピートスタート)や、書き込み/読み込み双方のストップコンディションの対応、タイムアウトなど、I2Cスレーブとしてはほぼ満足できる機能がライブラリーとして実現している。

 ここはもう余り手を加える必要はない。残るは、このブレークアウト基板が部品として使えるように、親機のTiny861に必要なUARTコマンドを追加して、汎用的なソフト環境を整備することである。Dsc01169

 まずは、連続して測定した距離を表示するコマンドを新設する。これは先のロジックを作るのにも必要な機能で、人が近づいたときどう距離が変化していくか連続的に調べるためである。作るのは簡単で、SR04の測定を開始するコマンドと、SR04のエコーを調べるコマンドを連続的に実行すれば良い。停止は、コンソールからのリターンキーである。

 簡単に出来たので、三脚にブレークアウト基板を固定して測定を開始する。順調にデータが出始めた。ところが、出力データが安定しないのである。階段の下から上部に向けて超音波を発射し、最上部に人が立てば、距離が変化して照明などの回路をONする理屈なのだが、無人なのに距離が安定しない。

 壁に囲まれた閉空間なので反射が多いからか、また、空気中の微粒子からの反射か、突然距離が短くなる。安定した距離が続かない。困った。このままでは、実用的な目的を果たせない。

DC-DCコンバーターを調べているうちにレベルシフターを壊したか(7/12/2017)
 三脚に固定しているのに、距離センサーが不安定な原因は、どうもDC-DCコンバーターのせいではないかという疑いがでてきた。埃が原因というのも考えにくい。DC-DCコンバーターはSR04にごく近い所に固定されている。疑うところはこれくらいしかない。

 というので、5Vの昇圧コンバーターの動作を停止し、別のスイッチング電源からコードを引き込んでテストした。最初、これで安定したので、DC-DCコンバーターの影響に間違いないと思っていたのだが、少し長い間測っていると、やっぱり別電源でも測定値の揺らぎは発生した。がっかりである。

 障害物がまわりにあるときは、測定値が不安定になってしまうようである。気流の動きで反射した音波が遅れて到着し距離が不当に伸びるのかもしれない(ロジックは良くわからない)。そうこうするうちに、突然センサーが動かなくなった。I2Cの通信自体がNO Responseである。

 何度も確認したが、接触不良ではない。トラブルシューティングの原則通り、マルチメーターで各部の電圧をひとつひとつ調べていく。電圧も問題なかった。DC-DCコンバーターも5Vを作っている。

 次はI2Cだ。まだ使い慣れていないがオシロでI2Cの波形をチェックする。まず親機。大丈夫だ。次はスレーブI2CのTiny85、おやあ、クロックがおかしい。パルスは受けているようだが、0になっていない(負論理なのでactiveにならない)。

 I2Cのスレーブはクロックは受信するだけである。異電圧間をつなぐレベルシフター(FXMA2102)が正しく伝えていないのではないか。

新しいオシロがお手柄。すぐにレベルシフター不調を表示(7/13/2017)
 オシロの波形によれば、I2C信号がレベルシフターを介するところでクロックのパルスが痕跡だけになる。Tiny85のUARTは動くし、親機も正常にI2C信号を出している。配線でおかしなところもない。これはレベルシフターICが壊れたとみるのが順当なところだろう。

 この実験中、DC-DCコンバーターをはずして、5Vを別の電源アダプターなどで供給した。何度かやっているうちに逆差したのかもしれない。Tiny85などのDIP製品は逆差しに案外耐えるが、こういうSMD(表面実装)部品は一瞬でも壊れる可能性がある。

 幸い、レベルシフター(FXMA2102)は予備が買ってあった(こういうときのため)。後ろ向きの仕事で気が進まないけれど、交換してみるしかない。低温ハンダで基板とピンヘッダーをはずし(ピンヘッダーはハンダ付けしてしまった)、チップだけ載せ換えた。

 電源を入れ直す。SR04基板は問題なく動き始めた。I2Cの信号もちゃんと見える。やっぱりレベルシフターが死んでいたのだ。いや、レベルシフターを失ったのは残念だけれど、新しいオシロが手柄を立ててくれた。自らを慰める。

 距離が時々違う値を示す現象は、照射する方向を選ぶと殆どなくなることがわかった。反射面の形によって値が不安定になるようである。人感センサーとしては、垂直方向(音波の方向)で使うのは無理な気がする。水平方向(音波を横切る)なら100%検知できるのだが。

一進一退のデバッグ。同時処理でこける。avr-libcがおかしい?(7/16/2017)
  SR04を動かす分のソフト開発は大体終わった。SR04では使わない連続データの入出力機能などは開発済みだ。考えられる機能はほぼ実現したが、ただひとつ気になっているところがある。

 連続測定のとき、SR04のエコーが返ってくるまで余裕を見て50msの待ち時間を設けていることだ。用途から言って、そう短い測定間隔が必要なわけではない。実用上は全く問題ないのだが、距離が短くても、待ち時間は変わらない。そのあいだ何もしないというのも芸のない話だ。 Dsc01173_2

 この間隔を短くするのは、超音波のエコーが返ってくるまでに、親機の方から、エコーが返ってきたがどうかを調べるコマンドを送れば良い。親機はそのフラグを見て、バッファーに収容されたデータを読む。簡単なロジックだ。

 トリガーをSR04にかけるまえに、フラグを0にし、帰ってきたらこれを1にする。親機は適宜マスター読み込み宣言でこのフラグを読み取って1になるのを待つ。造作のない話なのだが、これがつまづきの始まりだった。どうにもうまく動かないのである。

 何故かフラグが1になったあとの計測データがでたらめになる。計測が割り込みを受けている間にデータが不正になるのである。慌ててAVRの参考文献を調べるが、AVRと、avr-libcは基本的にはリエントラント(複数のタスクを受け入れる)で、同じプログラムに複数のスレッドが通ることを許している。Ws000027

 これまでにこうしたプログラムはいくつか作り、何の問題なく動いている。リニアPCMプレーヤーなどは、DACの音声発生、SDカードの読み込み、LCDの進捗表示と3段のマルチタスクで動いている。

 勿論、リエントラントといっても共通のグローバル変数や、printfなどの標準関数はリエントラントには動かない。しかし、I2CとSR04の計測ルーチンは全く無関係だ(とこのときは確信していた)。だから問題なく動くはずなのだが、現実にはデータが汚されている。ハングするならともかくまともに戻って動くのが気に入らない。

 満を持してロジアナを出動させる(オシロでは無理)。I2Cとエコー、実際にデータをセットするプロセスにプローブを入れ、状況を見る。確かに、エコー期間の時にI2Cが動くとデータが不正になる。共通リソースもないのにどうしてこんなことが起きるのだろう。

情けない。とんでもない思い込みだった。立派に共通変数が被っていた(7/23/2017)
 このブログは原因がわかってから書いている。原因が解明される前のメモを今読み返しているが、いつものデバッグのときと同じで、なぜこれに気が付かなかったのだろうと感心するほど、思い込みというのは恐ろしい。 Ws000028

 I2Cの割り込みと、計測ルーチンとは全く独立していると完全に思い込んでいるから、最初は、もしかしたらavr-libcの不具合とか、もっと別なことが原因ではないかと思っていた。そのあいだに以下のような副次的なバグまで発見された。

(1)    親機から子機(スレーブ)のデータを読み込むのに、いちいちコマンドを送っていたが、そんなことをせずにマスター読み込み宣言で自由にデータが読めることがわかった。SR04のトリガーをかけてからの動作をひとつ省略した。出来る限り競合を避けるため。
 ->全く効果なし 

(2)    データをマスターに送る時、スレーブのバッファーに各ビットにひとつだけ1 の立ったマスクビットをANDしてバッファーを壊していた。データを送り終えると、元のバッファーデータはALLゼロになる。つまり、一旦送ったデータの再送が出来ていなかった。 
->これも特段の変化なし。データの再利用はしていなかった。

 完全な迷路にはまっていた。I2Cとエコーロジックは無関係だと思っているから、割り込みのときにレジスターなどが破壊されて値が不正になるのではとも考え、測定部分が関数になっていたので直接にコーディングしなおしたりした。もちろん変わりはなかった。ほぼこれで一週間悩んでいた。

 それが見るともなくソースコードを見ているとき、ふと気になるところが見つかった。スレーブのソフトI2Cは先方からの想定したビット列が来ない時は、ハングアップを避けるため1秒程度のタイムアウトを設けて、通信自体をリセットするようになっている。

 このタイムアウトのメッセージに、"No_Echo or Timeout..."というところがある。ちょっと待て、このNo Echoというのはどういうことだ。あっあっあー、何ということだ。このタイマーのキャリーを記録する変数をSR04のエコー期間を測定するときにも使っているではないか。

 たとえプログラムがリエントラントでも、変数を共通にしていては駄目になるのは当たり前だ。I2Cは通信開始時に必ずこの変数を0に戻す。これで、これまでに測っていたエコーのキャリー変数は0に戻り値はでたらめになる。あーあ、何というお馬鹿なプログラム。

 この修正は極めて簡単である。キャリー変数を、I2Cのタイムアウト用と、エコー測定用のものを分けて定義するだけだ。これで、どれだけエコー期間にI2Cが被っても正常な値を表示するようになったのは当然のことである。

 やれやれ、長い間かかった。思い込みというのは恐ろしい。「すべてのものを疑え」というデバッグの格言をかみしめる。 配線図や、コードの公開は、今ちょっとショックが大きすぎて作業する気力が生まれない。公開は次回以降としたい。

| | コメント (4) | トラックバック (0)

2017年6月29日 (木)

超音波方式の人感センサーI2C化と新しいオシロ

 PCの横で超音波距離センサーHC-SR04がブレッドボード上に残されたままになっている。他の電子部品に比べると特徴的な形をしているので何かと目立つ。ブログを調べてみたら、このセンサーにはまっていたのはもう2年も前のことで(2015/7/28)、そのあいだ放置したままということになる。Dsc01163

 ブログによると、このあとこの距離計測センサーをI2Cでつなごうとして、AVRの8ピンプロセッサーTiny85を使ってソフトのI2Cスレーブライブラリーを苦労して開発した。ソースコードをブログに上げたのは良かったのだが、そのあとは力が抜けてそのままになっている。

 このセンサーはアナログで動作電圧は5V、距離をパルス時間幅で返してくる。Edisonやesp8266などの3.3Vベースの32ビットプロセッサーとは電圧が違うし、それよりもプロセッサーにOSが入っていたりWiFiなどの割り込みが起きると、こうしたアナログのパルス幅の正確な時間は測れない。 

 そういうことでI2C化を始めたのだが、工作は全然別の方向に迷走したままになっている。そういえば、秋月で異電圧間のI2CをつなぐICも買ってあったのに部品箱の不良在庫になっている。Raspi3の電源問題も一段落したので、このあたりを次のテーマにすることにした。

 HC-SR04のブレークアウト基板(Vccは3V)をつくる。I2CスレーブのTiny85と3.3->5Vコンバーターをつけ、外部へは3.3V入力とGND、それにI2CのSDA、SCLの4本のケーブルをつけて、32ビット機器に簡単に接続できるようにする。

 親機はEdisonはもはや重いので、esp8266あたりを想定する。アプリケーションは、人が近づいたら反応する人感センサーにしようと思う。現在の階段のセンサーは焦電型で結構、反応が微妙で調整が難しい。距離測定の超音波なら、扉を開けるだけで反応するはずだ。

これまでの工作の再現だけで2日を要した(6/19/2017)
 裸になっていたSR04とTiny85を取り出して、ミニブレッドボードに移し替え、ブレークアウト基板のテストベンチをつくる。これまでのブログ記事を参考に(もうこれなしでは生きていけない)、もういちど配線をし直す。Tiny861の親機の方はまだブレッドボード上に生き残っていた。Dsc01157

 UARTを2つつないで意気揚々とテストに入った。しかし動かない。親機は動いたようだが、子機のTiny85は UARTにWelcomeメッセージは出るが、反応が全くない。親機からコマンドを送っても「そんな機械はない」と門前払いだ。

 接続を確かめる。プルアップ抵抗が隣のピンに入っているのを見つけた。最近は目が悪くなって良く間違える。さあ、どうだ。駄目だ。依然として動かない。しようがない。オシロを取り出す。なにー、ちゃんとI2Cの波形が見えるではないか。それでも動かないとはどういうことだ。

 暫く大騒ぎしていたが、落ち着いて配線を見直し、間違いを見つけた。要するにジャンパーコードの接続ミスだった。SDAとSCLが逆さまになっている。Tiny85と親機のTiny861の間のピンが揃っているかだけに気をとられ、ピンそのものが逆だったというお粗末である。情けない。Ws000022

 つまらない配線ミスで時間をとられたが、完動した。次はこのSR04のブレークアウト基板のソフト仕様である。どの程度の独立性を持たせるかで、基板ハードの仕様に影響が出る。何から何まで、例えば、音速の補正をコマンドで修正できるようにしておけば、ファーム書き換えのISPピンソケットはいらないかもしれない。しかしそれも面倒だ。

 実装するDC-DCコンバーターを何にするかも迷うところだ。部品箱を久しぶりに整理すると、5コ以上のDC-DCコンバーター基板が出てきた。1V以下でLEDをつけるやつ(これは今回は使えない)やら、表面実装にこだわったFP6291のもの(2つもある)、昔のHT7750など、自作品だけで沢山ある。

急にオシロが欲しくなって衝動的に発注(6/21/2017)
  そのうち、オシロで半分つぶれかかったI2Cの波形(これで良くデータが通ると感心)を見ていて、突然、これまで我慢していたオシロに対する物欲が沸き起こった。 波形がお粗末なのはオシロのせいではないが、この物欲というやつは、「ときめき」と同じでどうも理由が明確ではない。Dsc01155

 数年前こちらに良くコメントを寄せてくれる、ばんとさんにオシロを勧めたとき、自分も新しいオシロが欲しくなったことがある。このときは、使う機会が少なかったので、やっとのことで我慢した。

 当研究所がオシロを買ったのは、もう9年も前の話である。帯域60MhzのOWON製(PDS6062T)で、当時は10万円近くした(¥79,800)。買ったときは、清水の舞台から飛び降りる気分だとブログにはある。

 オシロの効果は抜群で、PCMプレーヤーのバッファーアンダーランを一発で発見したり大活躍をしたこともあるが、単純なトリガーしか選べないことや、蓄積データ量が少ないので大したことは調べられず次第に使われることが少なくなった。

 まあアナログ工作は殆どやらないので、それほど大きな不満はない。ちょっと複雑になればロジアナを引っ張り出せば良い。 オシロは今度の工作のように、動きを確認するだけに使われていた。必要性を強く感じることはなかったのである。

 このあと、低価格帯のオシロは、さらに安くなって中華のオシロは帯域100Mhzが3万円台になった(ばんとさんに勧めたころ)。中華製も評判は悪くなさそうだったが、強いニーズがなかったことがあって、オシロ熱はそれほど高くならず、その後は余り調査していない。

 あらためて調べてみると驚いた。さらに低価格化が進んでいる。少し前までは高級オシロにしかなかったフォスファー機能(アナログオシロのように繰り返し波形を色分けしてくれる)のついたものが、10万以下で手に入る。

 調べている間に、狙いをつけたのが、SiglentというシンセンのメーカーのSDS1202X-Eというオシロである。帯域が200MHz、メモリが14 Megaポイント。フォスファー付きで、この-EというサフィックスはUART、I2C、SPIなどのレコードの解析もできるシリアルデコーダーが付いている最新バージョンである。Ws000023

 ひところなら確実に100万以上はした商品ランクである。価格が悩ましい。日本で買えば(アマゾンとか楽天)10万近くするのだが、Alibabaなどの中華サイトでは、$380、何と4万円そこそこで売っている。にわかには信じられない安さだ。

 今これがないと進めないようなプロジェクトはないが、欲しいという欲望に勝てなくなった。しかも5万円以下で、これまで想像もしていなかった高性能のオシロが手に入るのだ。ここ数年は、余り電子工作に金をかけていない。少しくらいは良いだろう。

 中華サイトの買い物はリスクが大きいが、日本のサイトの半額以下というのは強烈な魅力だ。何しろ所長は「破格の安値」というのに弱いのである。ウェブサイトの珍妙な日本語の広告画面を何度も見ては迷っていたが、抵抗できず、ついポチってしまった。相手は、AliExpressである。

DCDCコンバーターの電源でSR04が動かない(6/24/2017)
 注文はしたけれど、到着まで10日はかかりそうなので、SR04のブレークアウト基板制作を続けた。次の課題はDC-DCコンバーターのテストである。

 久しぶりに秋葉原で買い物をした。自作のDC-DCコンバーターは、殆どが9 V以上の昇圧コンバーターで、5Vに上げるコンバーターにするため、秋月電子で面実装の半固定抵抗を入手するためである。

 面実装の基板の修正はとても難しい。例の低温ハンダで部品をはずすのは簡単だが、この自作のDC-DCコンバーター基板(FP6291)は、最初のバージョンではんだ付けに大苦労した版だ(ブログ参照)。半固定の抵抗器を取り替えるだけに数時間かかった。

 何とかして取り換えた。電源を入れる。おやあ、無負荷では5Vになるが、LEDだけつけても3V近くまで下がる。オシロで見るとパルスだらけの出力で明らかにおかしい。実体顕微鏡で配線を子細にチェックする。Dsc01162

 すると、分圧抵抗のグランド側のハンダブリッジでつないだところが見事に切れているのを発見した。やれやれ、以前もこの現象に悩まされたことを思い出す。他のところで熱を加えているときにブリッジが解消されてしまうのである。

 これを直して無事、負荷をかけてもちゃんと5Vが出るようになった。300mA以上流してもOK。勇躍、SR04の電源に組み込む。SR04は無事動いた。

不愉快にも市販のDCDCコンバーターは完動(6/25/2017)
 ところが、何故か、センサーの計測距離が不正確になってしまった。どれだけ遠くを指しても、出てくる距離が30cm以上にならないのである。電圧は5Vのままで、オシロで見る限り波形も正常だ。理由はわからない。DC-DCコンバーターのパルス周波数と、超音波センサーのパルス(40khz)とが近いからだろうか。

 スペックによるとFP6291のPWMパルス周波数は、1Mhzと高いのでその影響はないはずだが、おかしなことには間違いない。修正の手間を考えると、もうひとつの自作のDCDCコンバーター(同一のFP6291)をさらに試す気力はもう残っていない。

 昔作ったHT7750もだめだった。距離はもう少しFP6291のより伸びるが、1m以上にはいかない。だいたいこいつはオシロで見ても、脈流でこういう電源には向いていない。本来の工作と違う脇道でこういうトラブルは、気分が滅入る。折角I2Cのレベルシフターまで入れて不良在庫を少し消化したというのに。

 しかし、少々のことではへこたれない当研究所の所長である。手持ちの市販(ストロベリーリナックス)のDC-DCコンバーター基板(LM2735)の予備があるのを思い出し、これを部品箱から探し出して実験してみた。

 何と悔しいことに、このコンバーターでは全く問題なく超音波センサーが動くのである。えー、なぜだろう。何故、自作のコンバーターでは動かないのだろう。不愉快なことだがこれが現実だ。Lm2735

 そもそもDCDCコンバーターをつくるのが目的ではなかった。へそ曲がりでは負けない所長だが、さすがに今度は、これ以上、これにかかわるのはやめることにした。全くの時間の無駄だ。

 だいたいこのストロベリーのコンバーター基板も予備品でこれまで部品箱の肥やしになっていたパーツである。ここで役に立っただけでも良しとせねばなるまい。ブレークアウト基板を早く作って人感センサーを作ろう。

新しいオシロ来たー(6/27/2017)
 オシロを注文したあと、注文先からは「入金は確認しました」や、「商品を配送しました」という意外にこまめなメールが届いていたが、思ったより早く、注文していたオシロが届いた(Siglent SDS1202X-E)。Dsc01158

 カード入金して2日で出荷の知らせがあり、到着は5日後である。たいしたものだ。初めての中華サイトでの買い物でどきどきしていたのだが、とりあえず一安心である。メールが届いていたので大丈夫とは思っていたが、やはり数万円台の買い物では緊張する。

 噂では、大陸からの荷物はべこべこになっている(荷扱いが極端に悪い)はずなのだが、結構、荷姿は崩れていない。ただし、段ボールを開けると、正式の梱包の段ボール箱が現れた。やはり二重になっていた。しっかりした間仕切りの発泡スチロールで機械は中央に浮いている。Dsc01159

 取り出す。現状の8インチに比べれば今度のオシロは7インチでやはり心持ち小さい。心がはやるので前と同じように居間で梱包を解き、プローブの校正をする。画面はかなり高解像度だ。

 我慢が出来ず、早速地下の工作ルームに持ち込んで現在のI2Cなどの波形を観測する。沢山機能はあるが、まだ使いこなせないので、これまで計測したものだけの再現である。

 おおー、測定範囲が広い。これまでのオシロは少しでも長い間観測しようと思っても、すぐに切れてしまい、全体をつかめない(こういうときはすぐロジアナに切り替え)のだが、今度は違う。何しろ記録量がこれまでの2倍以上あるのだ。(6M->14Mpt/s)。Dsc01161

 距離センサーのテスト機で、I2cをスタートさせ実際のアナログの応答トリガーがかえってくるところまでが一目で見られる。これはありがたい。画面が小さくなったことを感じさせない性能向上である。以前より価格は半分で性能はざっと3倍(帯域60Mhz ->200Mhz)。時代の進歩を実感する。

 フォスファー機能とか、シリアルのデコーダーとか盛りだくさんの機能があるのだが、とりあえずは満足である。追い追い調べていくことにしよう。久しぶりに自作のシグナルジェネレーターなどを埃をはらって登場させ色々テストする予定だ。Dsc01160

| | コメント (7) | トラックバック (0)

2017年6月12日 (月)

RaspberryPi3の電源問題はOSの不具合だった

 しつこいことでは誰にも負けない当研究所の所長が、やっとのことでRaspberryPi3(以降Raspi3)が立ち上がらない問題を解決することができた。

 研究所の工作テーマはESP32に移っていたが、定点カメラを目指したRaspi3の初期ブートが失敗するトラブルは解決されていない。パワーオンリセットが効かないのである。USB機器をはずして立ち上げると大体うまく行くが、USBをつないだまま(もちろんセルフパワーHUBで電源供給済み)だと、ほぼ立ち上がらない。Dsc01131_1 質(たち)の悪いことに、一旦、ブートに成功すると暫くは問題なく動く。しかし半日おいておくと、立ち上がらなくなる。一番先に疑われたのは電源である。いくつかのアダプターを買ってきたり、ケーブルを吟味したり、HUBを換えたりしたが、はっきりとした改善は見られない。

 オシロを使って立ち上がりの電圧の波形を何とかとることができた。立ち上がらない時と、正常に動いた時の双方の波形がとれた。しかしどちらも似たような波形だ。確かに0.5msくらいのところで大電流が流れたらしいディップがあるが、正常に立ち上がる時も同じようなものだ。電源が原因ではないような気がする。Dsc01133_1

もう一台RaspberryPi3を買う(5/24/2017)
 次に疑うべきは、Raspiのハードそのものである。以前、Edisonで本体がおかしくなって熱暴走したこともある。もしかしたらハードがやられているのかもしれない。今、Raspi3は一台しかないので確認はできない。これはもう一台買うしかないか。

 予備ということにして(使うあてがないのがつらい)Raspi3をアマゾンで発注する。ケースとヒートシンク付きで¥5980と安かったのでつい手が出た。数日で届く。便利な時代になったものだ。

 まずは、この新しいRaspiの動作確認である。システムディスクの16GBのSDカードを用意し、NOOBS一式をダウンロードする。OSのバージョンは2.1.0から2.4.0に上がっていた。 

 ふーむ、zipファイルが200MB以上増えている。どんどん進化しているようだ。インストールは順調に進みトラブルなくOSは展開された。電源を入れる。全く問題ない。順調に立ち上がる。少なくとも電源ではない。電源不足を示す画面の稲妻マークも全く表示されない。快調だ。

Dsc01137 やっぱり最初のRaspi3が原因だったのか。いや、まだ、カメラをつないでいない。しかもOSが違う。今のOS(2.4.0)はまだ裸の状態で、これからSAMBAや、動体検知motion、日本語入力、固定IPアドレス化などを加えていかないとトラブルの起きた状況にならない。

 加えた変更のうち、初期化のトラブルに関係しそうな要素は、何といってもカメラモジュールの接続だ。ハードの初期化でループしてしまえばブートは先に行かない。まずトラブルの起きた元のRaspi3にこの2.4.0の新しいシステムディスクを差し替えて動かしてみる。

結局、OSを最新版にして落着(5/28/2017)
 やっぱり何の問題もなく立ち上がった。いやいや、まだカメラモジュールをenableにしていない。raspi-configでカメラモジュールをenableにして立ち上げ直す。よーし、素直にブートが始まった。Raspi本体が悪くないことは確実だ。

 最後の確認である。カメラの動作確認だ。motionはまだ入れていないので、raspistillなどの専用コマンドをあせる手でコンソールに入力する。おめでとうございます。ランプがついて写真がとれた。間違いなくOSの問題である。

 これでトラブルの原因がはっきりした。2.1.0でのカメラモジュールの接続はブートの時にハングすることがあるのだ。このあと、元の2.1.0のOSに戻し、再現を確認した後、raspi-configでカメラをdisableにすると、カメラをつけていてもトラブルが解消することを確かめた。

 このハングが何の原因で起きるのかはわからない。少なくともインストール直後は起きていなかったから、カメラモジュールだけの問題ではなさそうである。このあと入れたアプリと何らかの競合が起きた可能性が高い。

 何が原因にせよ、少なくとも2.4.0で電源トラブルは解消した。というので、2.4.0にこれまでのアプリをインストールし直せば問題は解決する。せっせとNOOBS2.4.0の新しいバージョンにこれまでのアプリをインストールし始めた。

 SAMBAサーバーや、Motion動体検知パッケージ、日本語入力など、入れるたびに初期化の状況を確かめる。2.4.0では最終的にmotionを動かしても全く問題は起きなかった。

 やれやれ、長い道のりだったが、ここ暫く当研究所を悩ませたブートの不調は、OSの更新で解決することになった。もっと早く、カメラをdisableにしてテストしておけば、もう一台Raspi3を買わずにすんだのだが、まあ、これは結果論だろう。

今度はSAMBAドライブが不調(5/29/2017)
 そうこうするうちにまたトラブル発生である。SAMBAのディスクにしていた昔のLet'sNoteの2.5インチIDEドライブがおかしなことになった。立ち上がり時に、$LogFile is not clean. mount in Windows....のエラーが出て、書き込みが出来なくなった。Windowsでマウントし直しエラーをリセットせよとのことである。

 ファイルの中身は普通に見ることができる。SAMBAを通すとWindowsからも正常に見えるが、書き込みはこちらからもできない。それではというので、Win10の方にUSB経由で直接持ち込んで、エクスプローラーで見たら、何とドライブは認識したが「この場所にファイルはありません」という完全拒否である。

 Windowsに昔からあるディスク管理ユーティリティで調べる。コントロールパネルの奥にあるこのユーティリティ(このネストの深さは何だ。このソフトはサードパーティ製で、MSとしては何としてもいじらせたくないらしい)でドライブを見ると、ちゃんと正常にディスクは見える。  
 しかし、ディスクの形式がRAW(生とでも訳すか)となっているのが気になる。このRAWをキーワードにウェブを検索すると、おお、良かった。沢山解決法があるようだ。要するに、何らかのタイミングでドライブのブートレコードのディスクの種類を規定するコードが誤って変更されるとこういう状態になるらしい。

Windowsのフリーソフトで解決(6/1/2017)
解決法の中から、まず、TestDiskを選ぶ。このユーティリティは、LinuxやWindowsでも動くフリーソフトで一番評判が良さそうなソフトだ。早速ダウンロードした。ガイドするサイトも沢山ある。簡単に治りそうに見えたが、これが結構難しい。

 やれることが沢山ありすぎて迷うのだ。日本語化されていないのはともかく、何がおかしくなっているのかわからないので下手にいじることができない。このあたりは、一瞬の動作で、すべてのファイルを失う危険がある。良く納得してからでないと作業は出来ない。

 要するに、「今、自分が何をやっているかを理解していないときは手を出してはいけない」というやつである。この「RAW」という文言が何を意味するのか具体的にわからないからである。迷った挙句、他にも方法がありそうなのでこのユーティリティの作業を諦めた。ウェブで検索を続ける。

 その結果、昔、所長も使ったことのある商用ソフトAcronisの無償試用ソフト(Acronis Disk Director)が良さそうなので、これで修復することにした。サイトに行き、慎重に無償版をダウンロードする。こういうソフトのページには、宣伝用の全く違うソフトのダウンロードボタンが隠れていることが多いので気を付けないといけない。Ws000008

 何とか目的のソフトをダウンロードして、早速試してみた。このサイトが親切だ。
画面がわかりやすい。ガイドに従って、未初期化をRAWと読み替え作業を進める。順調に処理が進んで、そう時間もかからず完了した。RAWはNTFSに変わる。

 念のため、Windowsを再起動する。よーし、正常なドライブに戻った。書き込めるか。中に入っているテキストファイルを呼び出し文字を書き込んで保存する。良いぞ、問題なく変更された。このディスクの中に入っているファイルで失って困るものはないが、正常に戻ったことが嬉しい。

 SAMBAにつなぎなおし、read/write可能なことを確かめる。昔、知人にPCで何をするでもないのに環境整備だけに異常に熱心な人がいた。自分も今度の入れ込みぶりはこの系統かなと苦笑いする。今のところSAMBAで使っているのはmotionの記録ファイルだけである。

ACアダプターの負荷特性を調べると驚くべきことが(6/2/2017)
 Raspiの電源問題の後日談である。Raspi3の立ち上がりの不安定さを解消するため、めたらやたらDC5Vの安定化電源ACアダプターを買い込んだことは前回までにご紹介してある。それが、落ち着いて数えたら、容量が2A以上のものだけで6個もあった(購入4ケ、故障した無線ルーターなどからの流用品2ケ)。 

 容量とは言うが、本当にこれだけの電流を取り出せるのか確かめたことはない。前にも書いたように、必ずしも容量の大きいアダプターが安定してRaspiを動かせていたわけではない。彼らの実力がどの程度なのか、ちょっと本格的に調べてみたくなってきた。

 良く言う電源のレギュレーションとは過渡特性のことを指すが、それ以前の静的な負荷特性は余り問題にしない。しかし過渡特性は、この静的な負荷特性が基本になるもので、これが低いようでは問題にならないはずなのだが、余り話題にならないのはなぜだろう。調べてみよう。

Dsc01135 こういうときのために、セメント抵抗を何種類かそろえてある。スライダックのような本格的なものはないが、物理の実験よろしく直列並列を駆使すれば、5Vなら0.1Aきざみで数Aくらいまで測れるくらいの種類は持っている(50、20、10、2Ω)。

 ブレッドボードにこのあいだ買ったUSBコネクター電流計や、ACアダプタージャックを取り付け、少しづつ測り始めた。データが揃ってくると驚くべき事実が明らかになってきた。おおげさな話かもしれないが、こうしたACアダプターは全然定電圧電源ではないのである。

結構、ケーブルの損失があるのだ(6/5/2017)
 どのACアダプターでも、1A少々の電流でもかなりの電圧降下がある。負荷によって出力電圧が変わらないのが定電圧だと思うのだが、サイトのいう定電圧回路の一般的なロードレギュレーションの上限±0.2%どころではない。平気で数%も落ちてしまう。

 4A容量のアダプターといえども1A流して(正確には0.9A)、0.3Vも下がり4.7Vになってしまうのはどうみてもおかしい。これで定電圧アダプターと称するのはいかがなものか。

 確かに、5Vフルスケールでグラフを描いてみれば、0.3Vの低下というのははごくわずかだが、0.5Vフルスケールにしてみると直線的に電圧が低下していく。

 汎用的なアダプターと違い、無線ルーター、USBハブなどの付属のアダプターは無負荷のときはあきらかに5V以上で、使われる範囲で5Vを維持するようになっている。これなんか一種の詐欺だ。

Dsc01138  グラフを描きながら、悪態をついていたが、少し冷静になって考えてみると、わけがわかってきた。流れる電流が1A近くなるとケーブルの長さが効いてきて負荷端では電圧降下が避けられないのだ。 

サイトで調べてみると、銅線の直流抵抗は意外に大きい。#24(アダプターで使われる一般的な太さ)の撚り銅線(錫メッキ)で1mあたり、0.09Ω(1kmで89Ω)。ということは、1A流せば、たった1mのケーブルで、0.1V近く下がってしまうのだ(往復換算)。

 大抵のアダプターのDC側のケーブルは2m近い。一生懸命、アダプターを取り替え、セメント抵抗をつけたりはずしたりしてグラフを作ったが、あまり意味がないことがわかった。手持ちの沢山のACアダプターの記録を詳しく公開するつもりだったが、誤解を招きそうなのでやめておく。

 この測定結果は、これまでのRaspiでのテストの状況と良く符合する。アダプターではなく、DC側のケーブルの長さや太さが大きく影響している。一番成績の良かったのは、例の秋月での長さ10cmの電源ケーブルが一番トラブルが少なかった。

 負荷端での電圧降下を少なくするのは、太いケーブルにするか短くするかが一番で、ケーブルの長さにかかわらず一定にするには、負荷端から電圧測定線(リモートセンシング)を引き出すような大掛かりな装置が必要だということも分かった。今回は良い勉強をさせてもらった。

| | コメント (4) | トラックバック (0)

2017年5月19日 (金)

RaspberryPi 3の電源事情好転せず。ESP32に手を出す

 RaspberryPi 3(以下Raspi3)による監視カメラはほぼ完成したが、恐れていた通り実際の観測には重い腰が上がらなくなった。現役時代の習い性だろう(若い時はそうではなかったので、一種の職業後遺症)。こういうプロジェクトを計画なしに始めることに強い抵抗があるのだ。

 どんな仕事でも一旦始めると、それを中止する大義名分が見つからない限り止められなくなる習慣が出来ている。途中でやめることに強い罪悪感を覚える。作業を始める前に具体的な目的と目標を決めておくのが決まりになっている。

 これまでに何度か気楽に始めてそれが止められず、といって順調に事は進まず、その葛藤で、へとへとになってしまったことがある。とまあ、出来ない屁理屈をこねているが、実はそれよりもっと深刻なことがある。Raspi3そのものの動作がまだ安定しない。

 USBセルフパワーHUBと電源のACアダプターを共通にすると大量にHUBの方から電力を供給してしまう問題は、特定のHUBの逆流と結論付けたのだが、念のため単独でテストしたところマスター側には電圧がかかってこないし(LEDが点かない)、このHUBを分解して中身を確認しても、しっかりVBUS側にはSBD(ショットキーバリヤーダイオード)が入っていたりする。

 別のHUBに交換し、ケーブルを吟味した結果、定常的な電源容量不足は一時的に稲妻の警告がでるものの、相当な負荷をかけても(カメラと自前ブラウザーなど)、ほとんど落ちることはなくなった。しかし、今度は、本体そのものが電源を入れてもブートしなくなるというトラブルが発生し始めた。Dsc01110

 必ず起きるということではなく、何度か電源を入れ直したり、HDDにつながるセルフパワーHUBの電源を別にしたり、あとからUSBを接続したりすると正常にシステムが立ち上がるので、それほど神経質になることはないのだが、安心して運用テストに入れるレベルにない。

UARTの字化けはあっさり解決。ボーレートがおかしかっただけ(4/17/2017)
 
Tiny13を使ったRaspi電源制御装置も、最初、電圧低下でRaspi3では不安定だったのだが、ケーブルやHUBを交換しているうちに安定して作動するようになっている。この制御装置は、電流量のモニターが出来るので、このまま使いたい、しかし肝心のUARTシリアル出力が盛大な字化けをしているのが気になる。Dsc01111

 で、これを先に直すことにした。久しぶりにオシロを動かして、ボーレートを調べる。明らかに9600bpsのボーレートより遅い(1ビット10.4μsのはずが12μs近く)。ネット情報によれば、Teratermはボーレートが設定画面で自由に変更できるというのでオシロのタイミングに合わせてボーレートを下げてみたが(9600 -> 9000近辺)、不思議なことに全く改善されなかった。

 どうも他の原因が考えられる。自作のソフトUARTのソースコードをじっくり見直した。すると送信期間はボーレートを守るため割り込み禁止(cli();)にしているところを、ストップビットを出した直後、解除(sei())してしまっているのを発見した。 

 ふーむこれか。もしここで割り込みが入ってしまうと、規定よりストップビットが長くなって字化けする。ただ、シリアル出力は、500msに一回の電流測定のときだけで、かかる時間は、9600bpsで30 字だしてもせいぜい3ms(1文字10ビットで1ms)だ。他と被ることはないはずだ。

 しかし、さらにコードを調べていくと、待ち時間をループでなく8ビットタイマーで作っていることがわかった。それもその割り込みは1ms単位だ。もしかしたら、ペンディングになっていたタイマー割り込みがここで入ってUARTと被るのかもしれない。

 ロジアナでも持ち出して測れば一発で原因がわかると思うが、何しろTiny13は8ピンでプローブに使えるピンが一本も残っていない。面倒なので、ボーレートの調整と、この修正(割り込み解除をひとつずらしただけ)を一緒に直してテストしてみた。Ws000019

 ピンポーン!見事に字化けはひとつもなくなった。やっぱり被っていたのか。念のため、割り込み解除のステートメントを元に戻してみた。何と、何と。それでも字化けは解消している。被ってはいなかったのだ。

 単なるボーレートの修正だけで直ってしまった。通信ソフトのTeratermのボーレート変更では治らなかったのに何故だ?心残りではあるが、余りこればっかりやっているわけにもいかない。先に進もう。

10インチのHDMIモニターを入れてRaspi環境が改善(4/18/2017)

 現在のRaspi3のOSはJessieで、HDMIコンソールからブートするようになっている。今まではPCのHDMIモニターを共用にしてディスプレイのSWで切り替えていたのだが、電源のトラブルシューティングで頻繁に再起動をする状況ではどうも具合が悪い。 

 例の7インチIGZOパネルをこのときとばかりに使いたいのだが、1920x1080の解像度では、動画を見るのならともかく、コンソールは猛烈に字が小さくなりデバッグなどはとても出来ない。フォントを拡大するコマンドは入れたが、実用性に欠ける。迷った挙句、適当なHDMIディスプレイを別個に買うことにした。Dsc01115

 ウェブで調べてみる。沢山ある。10インチ近辺のモニターは、車載用のTVモニターの需要があるらしい。爆安店で探せば数千円で買えるかもしれないが、買いに行く時間が惜しい。通販でも1万円近くだせばスピーカーまでついた本格的なHDMIモニターが買える。アマゾンで注文する。良い時代になったものだ。

 ほどなく品物が届いた。タッチパネル式のスイッチ、リモコンまでついて立派なものである(1024X600)。動かしてみる。おおお、少し小さいがコンソールを見るには十分だ。これで格段にRaspiの開発環境は整備された。いちいちPCのディスプレイをスイッチで切り替えなくて済む。Dsc01116

 専用のディスプレイが出来たので、Raspi3そのものの整備が楽しくなった。Raspi3はBluetoothもあるし、NOOBSのデスクトップには、既にいくつものブラウザーが動くようになっている。電源問題が先に進まないので、つい色々なことに目移りしてしまう。

 前にも書いたが、Raspi3の性能は大したもので、ウェブサーフィンも殆どストレスを感じない。居間で使っているASUSの古いネットブック(CPUはAtom)より早いかもしれない。感心なことにデスクトップにはBluetoothのドライバーまでインストール済みだ。

秋葉原で久しぶりの買い物。秋月の最大ACアダプターなど(4/21/2017)
 暫くご無沙汰だった秋葉原に仕事の帰り立ち寄り、秋月電子でいくつか部品を買ってきた。これからの電子工作プロジェクトの候補である。現状が迷走しているので、何らかの起爆剤になることを期待している。

・LTC1799
オシレーターチップ。電波時計の電波(JJY 40/60khz)をこれで発生させ、ESP8266などで、ネットのNTP(Network Time Protocol)で得た時刻を標準電波形式にスイッチングする。要するに電波時計リピーター(別経路のリピーターだが)を作ろうというものである。

ウェブサーフィンをしているときに、これを使い、ESP8266のArduinoIDEで作っている記事を見つけた。電波の届かないところでも電波時計が使える。面白そうなのでとりあえずICだけを調達する。Dsc01129

・ソリッドステートリレー (シャープ 8A 250V)
AC機器をリモートで入り切りするために在庫がなくなったので補充した。これまでのESP8266が遊んでいるので、これにウェブサーバーを立てて、ブラウザーからの指示でAC機器を制御する。典型的なIOTの第一歩である。WiFiモジュールは、新しいESP32も買ってあるが、この程度の制御にはもったいないので別の用途を考えることにする。

・4Aの定電圧5V ACアダプター
 Raspi電源制御の切り札、秋月電子内の最大容量の5Vアダプターである。自前で強力な5V安定電源を作る前に、本当に電源容量だけの問題かこれで確かめようというもの。

・ブレッドボード用DIP基板のついたUSBコネクター    
 Raspi電源問題解明で何らかの回路をUSBバスに付加してテストするため。ブレッドボードでハンドリングできるDIPピンのついたUSB Aタイプコネクター。ブレッドボードそのものは接触不良のかたまりみたいなものだが、何とか藁をも掴む思いである。          

4AアダプターでもRaspi電源事情は改善せず。好い加減あきてきた(4/22/2017)
 当研究所には、5V定電圧ACアダプターなら山ほど揃っている。秋月で買った3Aと2.5Aのものを始め、例のUSBセルフパワーHUBの2.6Aや、2.1Aなど、数えてみたら5つもあった。

 今さら、さらに買い足す必要もないのだが、何となく意地になって4AのACアダプターを思い切って買ってみた(といっても¥900)。帰宅して、とるものもとりあえずまずこのアダプターの実験をする。しかし、残念ながらRaspiの電力環境は好転しなかった。これまでのACアダプターと殆ど変わりはない。

 相変わらず稲妻マークは出るし、時々最初のブートが効かない問題は依然としてなくならない。USBプラグを抜き差しすると変化があるので、アダプターの容量の問題ではなくこのあたりの接触不良の疑いも出てきた。

 ウェブで「電源 ロードレギュレーション向上」などのキーワードで、関連情報を探すが、出てくるのはプロ向けのおおがかりな回路設計の話ばかりで、アマチュアが手軽に試せるようなことは何も見つからない。

 本当は、自前で高性能の3端子レギュレーターなどでACから5Vにする定電圧装置を作るべきなのだろうが、このあたりは、素人なのでとっかかりがなく、もどかしい。

 解決の方向が見えない。ブートを失敗するのは、電源投入時の瞬間的な電圧降下であろうとあたりはつけているが、確認するにも現象が固定化されない(どのACアダプターでも起きる。長時間OFF後はほぼ必ず発生。一旦成功すると、そおあとは失敗しない)。具体的な手段が見つからない。段々飽きてきた。

Raspi3のオーディオ環境整備にはまっている(4/30/2017) 
 そういうこともあるが、このところはRaspi3の環境整備にはまっている。専用のディスプレイでデスクトップ環境が格段に使いやすくなったこともある。

 Raspiのオーディオは無印のころから、これまで全く手を出していない。Raspiのオーディオも結構人気のようである。まずはオーディオ関係を整備することにする。

 Raspi3にはアナログ(単なるステレオジャック)と、HDMI出力、それに情報によれば、入出力ピンにI2Sが出ているということだ。この10インチディスプレイはスピーカーがついているのでHDMIからの音が出るはずだ。Dsc01128

 とりあえずRaspi3のデスクトップのメニューバーにオーディオ選択のダイアログがあったので、これをHDMIにしてみる。ブラウザーで適当な音源を選び音を出す。簡単に音が出た。小さなスピーカーなので音質はお世辞にも良いとは言えない。「音も出ます」程度の音である。

 次は、アナログである。内蔵DACは11ビットというのでこれも音質は期待できない。ヘッドフォンを取り出しジャックにつなぐ。おやあ、シーッと量子化ノイズが耳ざわりだ。11ビットならもうちょっと良いはずだが。

 音を出してみる。小さいスピーカーに比べれば、音はましだが、やはりノイズが気になる。ウェブで評判を調べる。うーむ、このアナログの評価は散々だ。

RaspiAudioの音質不良はrpi-updateで少し改善。Bluetoothも(4/28/2017)
 ウェブをさまよい歩くうち、Raspiのアナログ音の出力は、ここのサイトによるとファームウエアがバグっていてサンプリングビットが1ビット少なく10ビットになっているという情報を得た。(オリジナルはここ

 ここには、バグの修正版のダウンロードサイトも紹介されている。2012年の古いパッチのようだが、正規のupdateにはなっていない。現在の最新バージョンには反映されていないようだ。ふーむ、恐らく何か別の不具合があってのことかもしれない。

 まあ、ものは試しである。一式をダウンロードして、インストールしたあと、ファームウエアの書き直し、rpi-updateをかける。エラーもなく順調にrpi-updateは終わった。

 音を出してみる。うーん、少しは良くなったか。確かに少しノイズが少なくなったが、音は驚くほど良くなったとは言えない。まあ11ビットDACは、二昔前のPCのサウンドカード程度なのでこれ以上の向上は無理のようだ。

 Raspiオーディオで検索をかけると沢山ヒットする。いわゆるハイレゾオーディオの中継基地として安上がりなのが人気なのだろう(この手のオーディオ機器は信じられないほど高価)が、当研究所は今のところハイレゾ再生には行かないことにしている。

 というので、次はBlueToothでの音の再生にチャレンジした。キーボードは動いたが手持ちのBluetoothヘッドフォン(サンワのMM-BTSH30)は、認識はするものの、音がすぐ切れる。ブラウザーや、デスクトップのScratchという教育ソフトの猫の音もでないので、BlueToothの問題だと放置していたのだが、あるとき、コンソールから、

aplay /usr/share/sounds/alsa/Front_Center.wav

というコマンドを入れたら、何と、Bluetoothでの音の再生に成功した。だとすると、ウェブに沢山情報のあるとおり、bluetoothのオーディオパッケージBluezと、これまでのLinuxのオーディオALSAとの衝突がどこかで起きている可能性が高い。

 Raspi内のどれかのオーディオパッケージをインストールし直せば、うまく行くのかも知れないが、問題は深そうで簡単に行く話ではない。ウェブでは調べた限りでは、こういう話題がヒットしない。解決策が見つかる可能性は低い。これも少々あきてきた。

ESP32-WROOM-32のテストに着手する(5/4/2017)
 というので、このあいだ買ったままになっていたESP-WROOM-32(以降ESP32)を試してみることにした。このESP32はWiFiモジュールESP-WROOM-2(以降ESP8266)のグレードアップ版である。Dsc01127

 中華製のWiFiモジュールには信じられないほど安価なのが多いが、日本の電波機器の技術適合証明、いわゆる技適をとっていないのが殆どである。しかし、ESP32はいち早く技適をとり、秋月からはPCへのUSB-UARTまで装備したブレークアウトボード(¥1480)も売り出された。単体の値段もESP8266と殆ど変わらない(¥550 と¥700)。

 これまでのESP8266の弱点、CPUが遅い、I/Oピンが少ない、SRAMの量が今一つという不満を一気に解消しており、これはお買い得と、少し前、予定もないのに単体と、ブレークアウトボードをひとつづつ買ってしまってある。

 以前ESP8266で画像付きのサーバーを作ったことがあるが、画像を出すだけ一息の時間が必要で、簡単なGPIOの操作ならまだしも、ちょっと手の込んだ遠隔制御には使えそうになかった。それがこのESP32ではだいぶ使えそうである。

 その割には日本ではまだブレークしていないようだ。技適はついているし、秋月などでもオリジナル(Espressif)社のブレークアウト基板を廉価で出しているに不思議だ。調べてみて何となく理由がわかった。

 どうもESP8266ほど周辺のソフト開発環境が進んでいないようだ。ESP32の開発元、Espressif社が、Arduinoではない独自の開発環境 ESP-IDEというのを作ったようだが、そのあたりの情報が不足している。一本道ではなく、いくつもの開発環境があるというのは、初心者にとってはかえって弊害になる。

 検索をかければ、ウェブには山ほど紹介記事が出てくるのだが、どれも今までのものと何か違和感がある。一例をあげれば、ここなどは、懇切丁寧な記事の大部分は、トリッキーな空中配線や、ブレッドボード上の配線法なので、読み流しているうち、急に複雑なウェブサーバーの紹介になってびっくりする。 

 ここのサイトは、詳細なESP32の情報が掲載されている。でも、ここの情報だけで、初心者がESP32を動かすことは難しいだろう。膨大な情報があるが、多すぎて、恐らくどこかで折れたら(書かれている通りに動かないなど)最後、手も足も出なくなるだろう。

 この違和感は、これらサイトの筆者の責任ではない。明らかに電子工作のやりかたがArduinoなどをきっかけに大きく変わってきたからではないだろうか。要するにハードやソフトウエアの複雑さが比較にならないほど大きくなって、全貌を簡単に把握できなくなっているのだ。

 結論から言えば、素人が手を出しにくい。WiFiによるスマホとの連携ひとつをとっても、その実現は膨大な技術の蓄積で可能になっている。本当の初心者なら電子工作はもっと少ない要素でできている8ビットのPICやAVRで経験を積む方が結局早道なのではないか。

 悪態をついてばかりいても先には進めない。とりあえずは開発環境から整備を始めることにする。何しろ沢山サイトはあるが、ちょっと目を通しただけではなかなかわからない。当研究所には、ESP8266を開発したArduinoIDEがある。当然この環境と一緒にしたいのだが、このあたりの解説が少ないのである。

ESP32のWiFiサーバーまであっさり動く(5/10/2017)
 このサイトを参考に、既存のArduinoIDEに、ESP32関係のパッケージをインストールする。ここを見つけるまでは、殆どのサイトが新規にArduinoIDEをインストールするところから始まっているので苦労した。要するに既にArduinoIDEがあるのなら、所定のディレクトリーにダウンロードしたパッケージを解凍して入れるだけで良い。IDEを再始動すれば、すんなりESP32関係がロードされる。

 ハードの方はいたって簡単だ。ブレークアウトボードなら、追加する配線は殆どない。LEDと制限抵抗を適当なGPIOピンにつなぐだけである。電源はとりあえずUSBから貰う。ここも電源問題が大変なようだが、まあ、実験レベルなのでこのまま行く。

 ArduinoのLチカのコードをコピペし、ビルドする。何事もなく、終了した。次は、ファームへの書き込みである。おお、無事に書き込みが始まったようだ。心なしかESP8266より速いような気がするが、これは、ファーム焼きこみのシリアルの速度が921600bpsとべらぼうに早いためで、本体が早いわけではないようだ。

 ファームの書き込み終了のメッセージと同時に、LEDが点滅し始めた。あっけなくLチカ成功である。ブレークアウトボードのおかげで、前の手製のESP8266開発キットに比べると、動作モードをタクトスイッチで切り替える必要がない(勝手にボードでGPIOピンを切り替えてくれる)。

 勢いに乗って、WiFiサーバーまで動かしてみることにする。ESP32のライブラリーにある、SinpleWebServerのソースを読み込み、このサイトを参考に、Lチカで使ったLEDをブラウザーからスイッチするコードに組み替える。

 これもビルド、ファーム書き込みともNO ERRORで終わった。立ち上げる(といっても何もしないで良い)。恐る恐る、PCに戻り、ESP32のIPアドレスを調べ(まだ固定化していない)、該当のIPアドレスでアクセスする。Ws000020

 やった。小さなメッセージだが、サーバーからの画面が出た。必要な所はクリック可能な色に変わっている。ONのところをクリックする。おめでとうございます。LEDが点いた。とりあえずESP32はウェブサーバーまであっけなく動くことが確認された。

 これから、ESP8266とどの程度高性能なのか調べていくことになるが、紙数も増えてきたので、このあたりで記事を区切ることにする。

| | コメント (4) | トラックバック (0)

2017年4月16日 (日)

motionの動体検知はRaspi3の電源が安定しない

フィールドテストの開始(3/25/2017)
 適当なパラメーター(前記事参照)を設定して、いよいよmotionによる自宅前の道路の動体検知の監視を始めた。道に面したサンルームのブラインドにカメラのレンズが通るだけのの隙間をわずかに開けて、そこに三脚に固定したカメラを設置する。外から見ると、ブラインドに隙間が空いて何か不自然だけれど、実験なのでとりあえずはこのままに。

Dsc01104 RaspiはWiFiにしたので引き回すケーブルは電源ケーブルだけで良い。設置は楽になった。HDDは三脚の下に置いた菓子折りの空き箱にHUBと一緒に載せる。電源スイッチを入れてその場を離れる。地下の工作室に戻ってPCからSSHを開き、motionを起動する。

 よーし、これでmotionは、ストリーム画像を送りながら、動きがあった時だけ、動画(aviファイル)と静止画(jpegファイル)をSAMBAサーバーの所定のフォルダーに画像を残していくはずである。念のため、PCのブラウザーでストリーミングを確認する。うむ画像が出た。102017032517352505 小一時間、カメラをサンルームに置き、データを収集した。ファイル数200ばかり。容量にして80MBくらいが溜まった。これくらいなら一日放置しても大した量にはならないか。

 データの中身をチェックする。自動車は監視対象ではないが、動体検知するのは車のときが殆どである。カメラの位置は進行に対して90°なので自転車の追尾は結構難しい。この場所からでは流れ映像しか撮れない。

 歩行者は問題なさそうだ。動体検知画素数1000程度で十分捕捉している。それでもタバコを人家の庭にポイ捨てする不届き者の人相を完全に把握するのは難しそうだ。 Ws000017

 ファイルは動体検知をしたセッション単位にひとつづつ数が増えていく。現在は、イベント番号(検知セッションの中での連番)というのがファイル名の先頭に来るので、ソートがうまくいかない。ファイル名を工夫しないといけない。

監視カメラの仕様がなかなか決まらない(3/28/2017)
 フィールドテストは始まったが、本格的な運用に入るまでに解決しなければならないことがブラインドの不自然な隙間だけでなく、まだ沢山ある。

 現在、撮影は室内から窓ガラス越しにやっているが、本当は外に置きたいところだ。しかし、外に置くとなると、カメラの防水、防風、防塵などの対策がただちに大ごとになる。レンズを近づけてガラスの影響を少なくする場所があれば良いのだが、今のところ都合の良さそうな所は見つからない。

 また、三脚にカメラを固定し、付属物を横に置いているが、これももう少し工夫したい。掃除はしにくいし、機動的な移動はできない。それに、まだ猫に気づかれていないが、HDDは僅かだが音を出す。長時間放置した場合の音に敏感な猫の対策も考えておかないといけない。

 さらにカメラの運転仕様が悩ましい。吸い殻を捨てる不届き者の特定を当面の目標にしているから、長時間の監視が求められる。人通りの少ない早朝か深夜が考えられるので、もしかしたら赤外線カメラにする必要があるかもしれない。自動的な時間制御もあった方が良い。

 出来上がった映像のチェックがこれまた大変である。motionを使っているので、歩行者、自転車が通過するときだけの映像になっているはずだが、映像をチェックするPC側のビュワーの機能だけでなく、現在のファイル名を今よりもうすこし合理的なものにしたい。

 先述したように、現在のmotionの録画したファイル名の先頭は、ひとつの動き検知のなかの複数の動きの番号(イベントNo)で、ソートするときとても不便である(ここの1や2は余り意味をなさない)。これはmotion.confのファイル名設定で換えられそうだが。Dsc01110_

 世の中の監視カメラの整理はどうやっているのだろうか。やっぱりしらみつぶしに映像を見ていくしか能がないのか。悩ましい所である。

電源制御装置を入れるだけで電圧降下の警報マークが出る(3/29/2017)
 フィールドテストをしながら、Raspiを安定して動かす電源の検討をしている。Raspbianのデスクトップには、電力不足になると画面右上に警報の稲妻型のロゴが出る(4.65V以下)ことを知り、これで、たくさんあるこれまでのACアダプターの性能比較が楽になった。

 ブート時はCPUにロードがかかり手持ちのすべてのアダプターで一部に稲妻が出る。結構敏感である。しかも必ずしも容量の大きい(流せる最大電流)アダプターの方が安定しているとは言えない。秋月の5V 3Aより、セルフパワーHUBについていた容量表示が2.6Aの方が何故か稲妻の出方が少なかったりする。ただ、少々稲妻が出てもすぐRaspiがダウンするわけではない。

 電源ケーブルとして使っているUSBケーブルでも大きな違いがある。太いケーブルの方が相対的には良いが、これとて余り長いと細い短いケーブルに負ける。秋月電子のRaspi専門の商品棚にあった長さわずか10センチくらいのUSBケーブル(タイプA->マイクロB)がやはり最強だ。

 先だって作った自慢のRaspiの自動電源制御装置(スイッチ押下で電源が入り、シャットダウンで小電流になると電源OFF)は、レギュレーションを間違いなく悪化させる。これを経由させると稲妻が出る頻度が高くなり、システムが不安定になってしまうことがある。

 この電源制御装置は0.22Ωのシャント抵抗で電流を計測している。500mA流れても、0.1Vの低下にしかならないので影響は少ないはずだが、どうしてなのだろう。

 以前買った、USBソケット内にLCD電流計を入れたやつはもっと良くない。入れただけで電圧が下がり、正常に立ち上がらない。表示は4.7V以上だが、恐らく瞬間的な大電流のとき表示以上の電圧降下があるのだと思われる。Dsc01113

 オシロでこの瞬間的な電圧降下を測定したいと思うが、トリガーをどうかけて良いのかわからない。入力をACにして、高感度にし、トリガーをnormalやsingleにしてみるが、全く引っかからない。

 こうした瞬間的な降下を回避したいのだが、どうもうまく行かない。下手なインダクターは無用の直流の電圧降下があるし、コンデンサーも大容量のものが既に付いている。これ以上の追加は突入電流が心配だ。

 どうも、Raspiの電源コネクターになっているマイクロUSBのソケットを疑いたくなってきた。2A以上の電流が流れるというのに、あの接点の小ささは気になる。あまり結果は期待できないが、これも例のやり方に替えて試してみることにする。

電源をGPIOピン経由にしても改善せず(4/1/2017)

 それは、以前の無印Raspiで愛用していた、GPIOピン配列に一緒に設定されているVccピンに直接5Vを供給する方法である。無印RaspiはUSBからのパワー供給は、ポリスイッチが間に挟まっており、こいつが悪さをして電源が安定しなかった。

 このポリスイッチを無効にすることで安定化したのだが、最も簡便なのはそのあとにピンに出ているVccピンに電源を供給してしまうことである。ポリスイッチが有効に動くのは、raspi基板内でショートなどで電流が流れることで、それは通常考えられない。これがなくても余り問題にならないという判断である。

 今度のRaspi3は、電源供給用に特化したUSBマイクロソケットがついており、その先の配線はRaspi2までと変わることはない。しかし、マイクロUSBのような小さな接点で、2Aを越す電流を安定的に送れるとは思えない。不安定さの要因のひとつになっているのではないか。

 そこで、前の無印Raspi同様、GPIOピンのVccに電源を供給し、いくつかの同じテスト(ブラウザー2本立ち上げ、motion動作、自分でストリーム受信など)をやってみた。残念ながら、マイクロUSBからの給電に比べ大きく改善されることはなかった。

電源制御装置で奇妙なトラブルにはまる (4/3/2017)
 問題なさそうなケーブルやACアダプターを選んで、何とか自作の電源制御装置を入れても安定して電源が供給されるようになった。

 ただ、SAMBAサーバーに使っている2.5インチHDDの電源供給(USBから給電)は、ただでさえ逼迫しているRaspi3の電源事情を考えて、当初から、セルフパワーのHUBを追加している。しかし、これでは、監視カメラを動かすのに2台のACアダプターが必要になり、取り回しが悪い。

 そこでせめて、ひとつだけのACアダプターでRaspi本体と、HDDをドライブするセルフパワーのHUBの電源にしようとした。ただ、セルフパワーHUBのACアダプターの受け口は、当研究所標準の2.1ミリジャック(秋月電子の標準と同じ)と違うので少々の加工が必要である。

 ところがこのテストをしているうち、妙な挙動に悩まされることになった。電源制御装置にACアダプター端子を追加し(単に入力をパラにしただけ)テストした時のことである。ブートしてRaspiのデスクトップ画面が順調に立ち上がった途端、電源制御のリレーが動いて切れてしまった。

 はじめは過電流が流れてRaspiがリセットしたのかと思ったのだが、勿論そんな状況ではなく、正確にリレーが働いて電源を切っており、症状は再現する。つまり、これはRaspiの消費電流量がシャットダウン時とみなされるまで低下していることを意味する。これはおかしい。Raspiは電源が切れるまで、ブートメッセージを始め、正常な動きをしている。Dsc01109

なんとUSBセルフパワーHUBが犯人(4/5/2017)
 こういう状況を放置しておけないのが所長の習性である。何が原因なのだろう。突き止めるまでは先に進めなくなった。幸いこのTiny13の電源制御装置は、裏蓋を開けるだけでデバッグ用のUARTにアクセスできる。字化けが何故か多いが(未解明)、そのときの消費電流と測定カウント、インターバルなどを表示する。

 このUARTをつないでスタート時からの電流量をモニターして驚くべきことが分かった。何と、このHUBのときは、Raspiには通常の1/3の電流しか流れていない。Raspiは普通、立ち上がりの時はかなり電流が流れるが、デスクトップが出てしまえばRaspiは200mA前後に落ち着く。これが通常の1/3だとシャットダウン時に想定している最高電流80mAを下回る。で、制御装置はシャットダウンと判定したのだ。 Dsc01111

 しかし、電流量が減ったのが全く理解できない。ブートは通常通り行われており、問題はない。するとHUBの電源を共通のACアダプターからとっていることが、これまで違ったところなので、これが原因であることは明らかである。しかし、理屈が合わない。USBコネクターから電源が供給される?そんな馬鹿な。

 試しにHUBを取り替えて別のHUBにしてみた。ははは、この問題は全く解消した。本当だ。セルフパワーのUSB-HUBの中には、スレーブからでもマスターのUSBパワーの電源を戻してやることがあるのだ。

体制は整ったが、突然、工作意欲がなくなる(4/14/2017)
 妙な現象は、手持ちのセルフパワーHUBの特性であることがわかった。症状の出ない別のHUBに切り替え、Raspiの監視カメラの電源整備はとりあえず一段落である。

 三脚の上にカメラ付きのRaspi3を置き、そこから電源用と、HDD接続用のUSBケーブルを2本出す。三脚の下にHDDとセルフパワーHUBを配置し、そこからACアダプターへの電源ケーブルを引くというレイアウトである。Dsc01108

 これをサンルームに持ち込み、テスト開始と意気込んだところに、珍しく風邪を引いた。これがかなり酷く、熱は微熱なのだが咳が止まらないうえ、声がしゃがれて出なくなった。こんなに喉をやられたことは記憶にない。無精して医者に行くタイミングを逃し、家人からあきれられた。

 そんなことで、突然工作意欲が湧かなくなった。電源制御装置のモニターのUARTの字化けを直そうと、久しぶりにAtmelStudioを立ち上げたりしているのだが、次の一歩が出ない。実はこのあいだネットで評判になっているESP8266の発展版、ESP32も買ってきてあるのだが、これも手が付かない。

 これまでにやった工作らしい工作は、傘の骨の修理(東急ハンズで修理用パーツをゲット)。DVDレコーダーリモコンの修理(これはカラ割には成功したが赤外線LED点灯せず。アマゾンで買い直し)。このあいだてこずったRaspiのBlueToothのテスト(キーボードは簡単につながったが、タイムアウトがあって使いにくい)、と脈絡のないことばかりである。

 まあ、これは意欲が戻るのを待つしかない。ブログもこのままではまずいので、とりあえず、中身はないが、これまでの報告ということで。

| | コメント (2) | トラックバック (0)

2017年3月25日 (土)

RaspberryPiのmotion動体検知の実用化に向けて

 このところRaspberryPi(以下Raspi)にはまっている。これを電子工作というのにはちょっと抵抗があるが、システム開発と言うのも何か大げさだ。まあ、Raspiは簡単にI/Oピンをいじれるマシンなので電子工作と言っても間違いではないだろう。

 巷(ちまた)には、Raspiに関する情報は溢れかえっている。しかし実用的な工作まで解説しているサイトは意外に少ない。あっても、詳しいのは導入までの工程で、そのあとの作業について解説しているところが少ないのだ。

 監視カメラに使うといっても、電源や、設置場所、耐天候対策、映像データの蓄積・管理など、検討すべき項目は数多い。この分野も既に専門家による大きな市場ができているので、素人が立ち入る場所がなくなっている。アマチュアがちょっと手軽にやってみるときの情報が少ないのは仕方がないのかもしれない。

 それに、アマチュアは作って動くところまでが楽しみで、動いてしまうと急激に興味が薄れるものだ(かく言う所長もその傾向を否定できない)。しかも、応用の方向は個人によって千差万別なので、参考にならないことが多い。このあたりは自分なりに開拓していくしかないのだろう。Dsc01068

 それはともかく、やっとmotionで想定した通りの動体検知システムが動き始めた。この監視カメラの運用までは、まだやることが沢山あるが、とりあえず一段落したのでブログに報告する。例によって時系列でまとめてあるので、話題が飛び飛びになることはご勘弁願いたい。

サブネット越しの名前解決(3/8/2017)
 直前の記事は、Raspi3をWiFiでつなぎ、SAMBAサーバーを動かすところまでだった。WiFiそのものは何事もなく動き、映像ストリーミングも快調に流れるのだが、SAMBAがなぜか通らない。撮りためるmotionの映像データは、何もしないとすべてRaspi3のSDカードに収容されるので、SDカードの耐久性が心配で、別のメディアを用意しておきたい。

 SAMBAにしておけば、リモートから監視映像を確認することもできるので一石二鳥だ。というので、SAMBAにこだわっているのだが、有線なら通るSAMBAが無線のWiFiではつながらないのである。

 WiFiルーターはブリッジで使っている(はずな)ので、同一のサブネットだと思うのだが、どうもSAMBAサーバーでは別のネットになるらしく、WindowsがRaspiを見つけられない。

 調べてみると、ウェブでは既知の問題点らしく、色々なところで解決法が紹介されている。要約すると以下のようになる。

(1)直接、PCでSAMBAサーバーのIPアドレスを指定してリモートドライブを定義する。WiFi越しでも通る(はずだ)。

(2)PC側のhostsファイルにサーバー名とIPアドレスを登録する。Windowsにもhostsファイルがあるとは知らなかった。しかし、これがとんでもないところにある。C:\Windows\system32\drivers\etcという深いパスの下にある。

(3)PC側のlmhostsファイルにサーバー名を登録する。これが正道なのだろう。lmhostとは、NetBIOSというWindowsのネットワークサービスの名前解決法である。このファイルも、hostsファイルと同じディレクトリにある。

 それぞれ試してみた。(1)は問題なく動いた。但し、固定アドレスをいちいち打ち込むのは運用上うまくない。他をあたってみた。(2)は、最初このファイルを変更することが出来なかった。さらに調べて、管理者権限が必要とわかり、エディター(Terapad)を管理者権限で実行させて変更に成功した。これも問題なくPCはサーバーを見つけてくれた。

 (3)も(2)と同じやりかたで、ホスト名とIPアドレスのセットを登録すると、WiFiでもSAMBAが動くようになった。一番、もっともらしい(3)にする。

Raspi3不調。OS入れ直し(3/9/2017)
 Raspi3の新機能のうち、まだ試していない機能がある。Bluetoothである。ただ、現在は、Bluetoothは、シリアルコンソールのUARTとぶつかるということで、停止している。実際に、ウェブにあるBluetooth関連のコマンドはエラーで戻って先に進まない。

 しかし、情報によれば、シリアルコンソールは、RaspiのBIOSにあたるconfig.txtに、クロックを固定する core_freq=250という設定だけで正常に戻るというのである。しかもBluetoothも動くという。

 今、Bluetoothを使う必要はないのだが、この方法が果たして有効なのかを確認するためBluetoothを動かしてみた。確かに、Bluetoothのセットアップコマンドは有効になり、Bluetoothが動き始めたような感じになった。

 ところが、Bluetoothのディバイスを持ち出して動作を試そうとしている間に、何故かRaspiそのものが正常にブートしなくなったのである。延々とエラーメッセージを吐き出すだけでブートが終わらない。ログインプロンプトまで行かないので何もできない。

 これまで加えたUART関連の変更(config.txtはPCから操作できる)を少しづつ元に戻してみるが、現象は変わらない。一番最初まで戻ったが、同じ状態である。恐らく何らかのBluetoothの設定ファイルが作られてしまい元に戻らないのだろう。設定ファイルをいじろうにもシステムが立ち上がらないので手の施しようがない。暫し途方に暮れる。

 余計なことをして、全く先に進めなくなってしまった。こういうときの一番の解決法は、OSを作り直すことだ。あれこれ悩んでいるくらいなら最初からシステムSDカードを作り直す方が手っ取り早い。Noobs

 手元に16GBのSDカードが見つかった(安売りショップで余りの安さに衝動買い)ので、今度はここに本格的なRaspbianをインストールしなおすことにする。ウェブを改めて調べる。どうも以前と様子が違ってOSのインストール方法が変わったようだ。

NOOBSって何だ?(3/10/2017)
 RasPiも例によって横道からつまみ食いをして動かしてきたので、最近の動向が良く見えていない。このNOOBSというやつが良くわからない。ウェブをさらにさまよい、これが複数のOSを選択インストールできる最新の方法であることがわかった。

 以前やっていたOSのカーネルをイメージファイルで、そっくりコピーする方式はどこへ行ったのだろう。ちょっと探したところでは見つけることが出来なかった。で、このNOOBS方式(ノービス、初心者向けということか)を試してみることにする。

 どうもこいつは、HDMIケーブルを使った画像デスクトップを要求するようだ。Raspiのデスクトップは、この前のSharpの7インチIGZOパネルを用意していたが、これが新しいOSで動くためには、またあのconfig.txtに修正を加える必要がある。面倒なので、PCのディスプレイと共用にする。

 太いPC用のHDMIケーブルを接続し、SDカードに展開したファイル群に起動をかける。よーし、画面にそれらしい起動画面があらわれた。ここではおなじみのRaspbianを選ぶ。他の選択肢にも興味をそそられたが他のは情報が圧倒的に少ないので選択の余地はない。

 Windowsと同じようなビルド画面が延々と続き、数十分でセットアップは終了した。そうか段々こいつもWindowsに似てきたな。キーボードとマウスをUSBハブにつけ準備を整える。順調にデスクトップが立ち上がる。ウェブブラウザーは既に日本語化されていた。20170324234018_1920x1080_scrot

 それにしてもあらためてRaspi3の速さを実感する。1920x1080の画面がスムーズに動く。ネットサーフィンも全くストレスなしに楽しめる。Linuxで動かす分にはもう十分な実用性があるように思えた。

新しいOSはデスクトップからでしか動かない?(3/13/2017)  
 デスクトップからの立ち上げには成功した。ところがシリアルから立ち上がるコンソールが動かないのである。SSHは動くが、シリアルは無反応である。シリアルはハードに直結しているので、ネットがおかしくなったり、デスクトップがおかしくなった時の緊急時のために動かしておきたい。

 ウェブを探していたら、何と、Raspi3からはシリアルはオプションで通常はdisableだという。(ここがとても参考になった。)

 あわてて、デスクトップの仮想ターミナルで、raspi-configを入力し、シリアルをenableにしようとした。なんと、そこにはシリアルを有効にする項目がないのである。ありゃー、これはどういうことなのだ?

 気を落ち着けて、ウェブの説明を最初から読み直す。なになに、デスクトップの「設定」メニューにはシリアルのenable/disableボタンがあるではないか。画面から「設定」を選び、最初のconfig.txtの部分を開く。ほんとだ。ちゃんとある。

 これをenableにして、rebootをかける。おおー、コンソールにブートメッセージが戻ってきた。やれやれ、これで一安心である。それにしても、以前のイメージファイルからのOSは何だったのか。

Raspi3は少しづつ元に戻る。マウントの制作(3/15/2017)
 OSを入れ直して、さらにWiFi化や、SAMBAサーバー、motionのインストールなど原状復帰の作業を進める。そのかたわら、定点監視カメラの本格的な実装に向けた工作も始めた。

 まず、ヨドバシでカメラ用の安い三脚(¥4000)を手に入れ、マウント台をアクリル板から自作する。マウントへのRaspiの固定は当初は輪ゴムで良いだろう。本格的にはいずれ別の方法を考える。Dsc01067

 久しぶりのアクリル工作である。楽しい。アクリル板からRaspiを載せる10X8(cm)の台座と、固定用の1/4インチボルト(これは万国共通のようである)を埋め込む2枚のホルダーを切り出す。以前、USBカメラを固定するのに使った方式と全く同じやり方である。

 これを2液混合のエポキシ系接着剤で接合した。乾燥のため一日放置し、これで丈夫になっただろうと実際に三脚に付けてみた。これが何と、少し力をかけただけでポロッと簡単にはがれてしまった。

 えー、エポキシ系ってアクリルにはつかないのか。前のUSBカメラのときは問題なかったのに。あわててGoogle先生にお伺いを立てる。接着面があまり滑らかだと接着力が落ちるらしい。そういえば前のUSBカメラの表面は梨地だった。

 そこでアクリル板の接合面を紙やすり(#200以下)で表面が曇るまでこすり、念のため別の新しい2液混合の接着剤にしてやり直してみた。今度も一日乾燥させる。試してみた。うむ、今度は大丈夫なようだ。 Dsc01071

 ついでに、近くのDIY店で、滑り止めのゴムシート(厚さ1ミリ、商品名エラストマーシート)を買ってきて、台座に合わせて貼り付ける。これは強力だった。輪ゴム程度の固定でしっかりカメラは固定された。よし、これで定点カメラの固定は万全になった(屋内専用)。

カメラモジュールのパイロットLEDの明度を下げる(3/17/2017)
 定点カメラにするためには直しておきたいところがある。カメラモジュール正面のLEDだ。動き出すと赤く光るのでわかりやすいが、カメラの正面に煌々と赤い光が点くのはまるで威嚇しているようにみえてまずい。

 このLEDをソフト的に消すことはできる。設定ファイルのconfig.txtで、disable_camera_led=1とすれば消えるが、カメラが動いているかどうかの確認が出来なくなるのも困る。

 そこで、LEDの位置を変えようとカメラモジュール基板を色々調べる。カメラチップのピンがビアを通して正面に出ている。これを利用して裏に移すことを考えたが、裏面にはスペースが余りない。しかもこれはかなりな手間だ。 Raspiled

 で、結論はLEDの制限抵抗を増やして暗くすることにした。基板についている抵抗は220オームである。どれくらいの抵抗が良いのか、適当な赤LEDをブレッドボードに差して(同色なら似たような特性と仮定)試してみる。

 10Kオームくらいでも結構明るく輝く。100Kではさすがに暗すぎる。久しぶりに例の低温ハンダを持ち出す。LEDのところに広がらないよう細心の注意を払ってハンダをつける。よーし、簡単に抵抗ははずれた。低温ハンダをハンダ吸い取り線で入念に除去する。

 部品箱の中から昆虫採集のように残してあったチップ抵抗のコレクションから10KΩを探し出し、交換する。パターンは1005だったが、手持ちの1608でも実装可能だった。交換作業は30分もかからなかった。

 試してみる。うん、10Kでも明るすぎるくらいだが、これくらいなら目立たないで良い。いや、くだらない作業だったが、何かとても充実した気持ちになった。

本格的なmotionの設定。画像はとれたが管理が大変(3/22/2017)
 準備が進んできたので、いよいよ、motionの監視用のソフト仕様の検討に入る。motion.confの膨大な設定パラメーターを、我慢して最初から読みはじめる。

 バージョンに新旧があるようで少し混乱するが、読み込んでみるとそう難しい構造ではなかった。大きく分けると静止画(動きを確認したところでのスナップショット)と、その前後の動画の2種類をアクションごとに保存していくようだ。Motion1 Motion2

 沢山のパラメーターがある(動きを検知する前の画像の処理とか、動かなくなってからの動画の記録をどこで止めるとか)。

 管理的には、スナップショットの静止画と、動画は別々のフォルダーに残しておきたいが、これはどうも無理なようだ。

 記録を始める動きの範囲の大小は、実際に動かして見て決めるしかないだろう。ファイルの置き場所は、SAMBAのHDDに指定する。とりあえず、以下のようなパラメーターで監視を始めることにする(変更したところのみ)。

width 640     (320)      Raspi3ならこれくらい画像を大きくしても十分見られる
height 480    (240)
framerate 12  (2)          あまり大きくすると時間遅れが大きくなるようだ
netcam_keepalive on (off)       HTTP/1.1を使ってストリーミングの性能向上
threshold 3000 (1500)             これはとりあえず。これでも結構敏感に反応する
pre_capture  1    (0)                      検知する前の画像も記録する。
event_gap    5    (60)                     検知したあと、不感となる時間(秒数)
max_movie_time 10  (0)                 動画記録の最大時間(秒数) 0は制限なし
output_captures best (on)        検知した一連の画像のうち最大変化量の静止画を残す
output_debug_pictures on (off)   静止画を検知するときの2値化した画像で残す ffmpeg_output_movies  on (off)    検知した時の動画を記録する
locate_motion_mode    on (off)     検知した画像の部分を4角で囲む
target_dir /SAMBAファイルのパス (/var/lib/motion)記録データの保存場所
stream_motion   on  (off)            ストリーム配信をする
stream_maxrate  20  (1)          ストリーム映像のフレームレート
stream_localhost off     (on)        ストリーム配信を自分以外にもする
webcontrol_localhost off   (on)  各種パラメーターの設定を自分以外でも変更可能

 以上の設定で、工作ルームでのテストでは、手を振ったり、動いたりすれば確実に画像が記録されるのを確認した。これが実際の道路を移して所定の画像がとれるのかはわからない。

Dsc01070  このあとは三脚をサンルームの道路に面した場所に置き、観測を開始することにする。さて、どんな映像がとれるか、久しぶりにわくわくする気分である。このあたりで今回の記事は一区切り。次回をお楽しみに。

| | コメント (0) | トラックバック (0)

2017年3月 6日 (月)

やっぱりRaspberryPi3は早い

 RaspberryPi(以下Raspi)の定点カメラのハードとOS周りの整備は完成した。次はアプリである。定点カメラの細かい仕様は、まだ決まっていない。とりあえずは、通行中の人や車をチェックする(家の前で何が起きているか監視する)ぐらいのことを考えておく。厳密なものではない。

無印Raspiは遅い。motionはすんなり動いたがカクカク(2/3/2017)

 満を持して無印Raspi(初代のRaspberryPi B)に、motionパッケージをインストールする。Raspi3は電力消費が大きいので、無印の方で動くなら動かしたい。無印RaspiのOSはこのあいだ更新した。アプリを入れる前にapt-get updateと、upgradeをかける。

 うーむ、何かエラーが起きているようだ。updateが進まない。エラーメッセージは「サイトが見つからない」と怒っている。えー何故だ。apt-getを中止して、pingをかける。何だ何だ、ネットワークが外へ出ていっていない。

 そう言えば、RaspiのIPアドレスを固定にするため。staticアドレスに変えた。設定ファイルを確かめる。DNSはちゃんと定義してある。何で行かない? 面倒なので、DHCPに戻す。問題なく外部へpingが通り、apt-get updateは無事終わった。upgradeに入る。これがまたえらく時間がかかる。小一時間かかった。件のmotionの方は何のことはない数分でインストールされた。

 このあと、IPアドレス設定ファイル(/etc/dhcpcd.conf)の中を見るともなく見ていて、とんでもないミスを発見した。DNSを定義する設定行domain-name-servers=XXX.... が、server=になっていた。Linuxは無口で、こういう誤りは教えてくれない。

 motionの設定でもまた少しまごついた。最初の設定値(デフォルト)ではサーバー外へのストリーミングを許さないのだ。ウェブ上の情報と、実際のパラメーターの名前が微妙に違うので結構混乱する。それにしてもこの設定量の多さには辟易する。ここの記事が親切だ。

 エディター(nanoこいつは便利だ)の検索機能(ctl+W)を使って目的のパラメーターを探し出した。stream_localhost off (ウェブ上ではwebcam_localhostになっている) これを直せば、すぐに画像が表示された。

 しかし、遅い! 前はもう少し早かったような気がするが、640ドットはお話にならないくらい遅い。320x240の画面でもカクカクして見にくい。景色を見るだけならともかく監視には使えない。シリアルコンソールには、motionが残しているファイル名が延々と出ているので、無駄な設定をしている可能性はある。うーむ、無印Raspiでこのまま行くか、Raspi3に上げるか迷うところだ。

mjpg-streamerは早かった(2/6/2017)
 motionは動体検知の機能がついているので動きが重い。320x240の画像のストリーミングでも2~4fps(フレーム/秒)がせいぜいだ。動きを検知するたびにデータフォルダーにaviファイルを大量に残しているようなので余計遅くなっているようだ。

Mjpgstreamer  これを止めようと、あれこれ設定をいじったが、うまくいかない。これからの目的(路上の不審者の究明)には、このソフトがうってつけなのだが、なかなか手ごわい。motionの仕組みそのものを理解していないので、どう止めるのか行き当たりばったりである。一番無駄な方法だ。

 motionばかりにこだわっていても先に進まない。で、以前使ったもう一つのストリーミングソフトmjpg-streamer(これにapache2とでライブカメラにした)を導入することにした。動体検知はできないがライブカメラとして使える。motionより早いはずだ。

 このアプリは、ソースコードからである。この前は、ダウンロードに手間がかかり、コンパイルエラーが出たりして大騒ぎだったが、今回はスムーズにインストールされた。バージョンが上がったのかも知れない。

 早速試してみる。おおお、こいつは早い。無印Raspiでも640x480の画像が滑らかにでる。Raspi3ならもっと早いだろう。motionのように動体検知は出来ないが、ストリーミングだけならこれで十分だ。

Raspi3に切り替える。シリアルコンソールが字化け(2/14/2017)

 Raspiのカメラモジュールは当初の目的(定点カメラ)をほぼ実現した。ただ、2つの無印Raspiには既にお役目がある。ひとつはSAMBAサーバー、もうひとつはパンチルトが出来る外部ライブカメラのメインマシンである(いずれも最近は使っていないけれど)。

 Raspi3は現在具体的な用途が決まっていない。こちらに移した方が合理的である。それに無印では遅かったmotionも早くなって、最終目的の動体検知が実用になるかもしれない。 折角、無印Raspiで動いているのを改めてRaspi3に移すのも二重手間だが、どれくらい早くなるのかも試してみたかったので移し替えることにした。

Dsc00976 まずは、Raspi3のケースに、カメラを固定する工作を加えなければいけない。Raspi3のケースを手に取っているうち閃いた。カメラの固定は、無印の時はケースについている段差(というより縁)を利用している。これをRaspi3の時も使えば良い。そう、縁のかわりをアクリルの細い棒で再現するのだ。

 早速、アクリル棒を切り出し、瞬間接着剤で固定する。差してみる。おお、うまくはまった。ちょっとテーバーが付いているので(勝手にできたのだが)、ピッタリだ。よーし、良いぞ。こんなささいなことでも、何かとても幸せな気分になれる。次はソフトだ。

 当研究所のRaspi3は、去年の6月に買ったので、OSはJessieで、例のカメラモジュールのディバイスファイル化は済んでいる。7インチのIGZO液晶パネルを動かすため、日本語化までやったがアプリは全く入れていない。久しぶりに火を入れることにする。シリアルコンソールをつなぎ電源をON。

Dsc00977

 おやあ、シリアルが字化けだ。前はどうした。あ、前は、HDMIケーブルでデスクトップ画面を出していたのでこれを使っていない。あわててシリアルの接続ピンを確認する。間違っていない。そりゃそうだ、化けた文字がでているのだからハードがおかしいのではない。

 こういうときは、Google先生に聞くのが一番だ。調べてみるとすぐに原因が明らかになった。Raspi3では、そのままだとシリアルコンソールがまともに動かないとある。入出力ピンが新しく入ったBluetoothのUARTと共用になったためらしい。

 これはあとの話だが、SAMBAのインストールをしたらまたおかしくなった。この解決は、ここ(http://akkagi.info/20161004_web/)に詳しい。要はmdline.txtの中を変えれば良い(と言ってもconsoleの順番を変えただけ)。これでやっとシリアルコンソールは安定した。

Raspi3にもSAMBAサーバー(2/19/2017)

 ついでに、このRaspi3にもSAMBAを入れる。SAMBAはすんなりインストールされたのだが、WindowsからSAMBAディスクが見えない。Raspi側の状況は問題ないのに。なぜだ。

 居間で使っているWinXPのネットブックではいつもどおりディスクが見えるので、これはこのWindows10の問題である。これもWebに情報を求める。うーむ、SAMBAの認証がえらく面倒くさくなったようだ。

 まず、Raspi側でSAMBAサーバーにsmbpasswdにユーザーIDとパスワードを定義し、Windows側ではネットワーク資格情報なる登録がいるようだ。この前までは、何もしなくてもすんなり読み書きができたのになぜだろう。

 SAMBAの設定パラメーターも、motionに負けず劣らず膨大な量なので、ことは簡単ではない。いくつかのウェブ情報を頼りに、せっせと設定を入れ込む。うまく行くときと行かないときがあって混乱する。

 リモートディスクの設定方法が複数あるのが混乱のもとだ。このユーザーIDというのはWindowsのなのかLinuxなのか、SAMBA固有なのか良くわからない。うまく行くとユーザーIDの入力は求められないが、求められたときは、正しい(と思われる)IDを入れてもはじかれる。

 何度もやっているうち、何とか安定してディスクがつながるようになった。Windowsは「ネットワークドライブの割り当て」から始めるのが確実なようだ。しかし、この「割り当て」のアイコンを出すのが結構難しい。Windowsのエクスプローラー(ファイラー)も機能が肥大してしまっている。

Raspi3のmotionは早かった(2/21/2017)

 まあ寄り道ばかりしていても仕方がない。本来の目的に移ろう。motionのインストールだ。これは問題なくインストールされ、定義ファイルの修正も何度目かなので順調に終わった。カメラモジュールが動くことは、raspistillなどの専用のコマンドで確認してある。

 Raspi3のOSは、Jessieなのでカメラモジュールは既にディバイスファイル(/dev/video0)になっている。motionは何もしないで動くはずだ。動作させる。赤いLEDが点灯し動き始めた。しかし、ストリーミングは始まらない。

 コンソールには何か延々とバックアップの画像ファイルを残していくメッセージが出るだけだ。えーなんで。何も変えていないよ。設定ファイルがおかしいのか、もういちど確認する。いや無印のときと変わっていない。

 OSもアプリも全く同じだ。それなのになぜRaspi3では動かない。設定ファイルを何度も確認するが、変わったところはない。暫く途方に暮れる。仕方がない、派手に出ているmotionの起動直後のメッセージを地道にひとつひとつ調べていくことにした。

 すると、コマンドを入れた直後のメッセージで、motionの設定ファイル/etc/motion/motion.confがないというメッセージが見つかった。ええー、そんな馬鹿な。さっきエディターで編集したばかりだ。何故だ? ああー、もしかすると motionに設定ファイルを読む権限がない? つまりmotionをsudoをつけずに動かしているからか。

 そのとおりだった。sudoを付けて動かすと問題なくストリーミングが始まった。しかしそれにしても、今までsudoをつけていたっけ?motionの設定ファイルmotion.confの属性がおかしい。オーナーがrootになっているのはともかく、他ユーザーに読めないようになっている(パーミッション600)。

 これではsudoがないと動かないはずだ。以前は一般ユーザーでも動いていたように思う。まあ、それはともかく、chmodで属性を644に替え、一般ユーザーで見えるようにする。動かしてみる。うむ、正常に立ち上がった。

 ストリーミングはどうだ。焦る手でPCのブラウザーを開く。出た。おおお、こいつは早い。無印に比べたら雲泥の差だ。640x480でも軽く20FPSくらいはいっていそうな滑らかさだ。さすがRaspi3だ。遅延は少し(0.5秒程度か)あるが、監視には全く問題がない。

 これはRaspi3で決まりだな。電源は元から電池にするつもりはないのであまり障害ではない。ACアダプターに大きいのが必要なだけだ。

自宅前の定点カメラのテスト順調。夕方でも鮮明(2/25/2017)
 いよいよフィールドテストに入る。自宅前の道路に面したサンルームの一角に3脚を据え付けカメラ付きのRaspi3を固定する。電源を入れ、LANケーブルを延長して(早くWiFiにしよう)接続する。動作中を示すカメラの前の赤LEDが眩しく、道行く人は不審に思うかもしれないが、これはいずれ消せる。

Raspi3_motion  ネットブックを持ち出し、ストリーミング映像を確認する。うん、良く映っている。窓ガラス越しだが、視認性は高い。解像度も問題ない。車の通行も飛ばないで映っている。いやあ、これは簡単だ。定点カメラとしての実用性は十分だ。

 日が暮れてきた。人間の目ではかなり暗いが、映像ではまだ十分な明るさだ。これでmotionの動体検知の機能を稼働させ、画像ファイルをSAMBAに入れて、遠隔地からその画像を確認するという手順が可能になった。

 カメラの固定がまだ仮りの状態なのと、引き回すのに有線LANではなく、WiFiにすることが課題に残っているが、今回のプロジェクトは何とか想定通りに進みそうである。

無線LANでもmotionは快調に動いたが。SAMBAが不調(2/28/2017)
 最後の仕掛けに挑戦する。Raspi3から実装されたWiFiである。定点カメラの移動の際、有線LANではなく無線(Wifi)にできればとても楽だ。セキュリティの問題はあるが、どうせ家の中から撮った外の景色が外に漏れたとしても大した問題ではない。

 Raspi3の無線LANの設定は多数のウェブサイトに紹介記事があり、インストールに不安はない。適当なサイトを選んで設定を進める。ただ最近の改定で、設定方法がかわり(dhcpの指定ファイルが一元化された)、設定方法が複数あるようで少し混乱する。

 LANケーブルがなければカメラの移動は大変楽になる。電源ケーブルさえ気にしていればいいからだ。motionの結果は、ストリーミングを利用して他のサーバーに送ったり、SAMBAディスクに記録して離れたところから眺めたりできる。

 WiFiの設定は、簡単にできた。ifconfigでIPアドレスを確認する。ここも、固定アドレスにする。メインPCからSSHでRaspi3にログオンする。よーし、入った。次はいよいよ動画ストリーミングだ。

 おお、何の問題なく画像が出た。動きは有線のときと全く遜色ない円滑さである。いやいや、これは楽だ。今後、Raspi3を移動体に載せて動画中継をすることも可能になる(電源が大変だけど)。

 勢いに乗って、SAMBAサーバーが動くか確認する。しかし、Wifi経由では、SAMBAがつながらなかった。確かに、有線LANと無線LAN2つに経路が出来たとき、経路を選ぶ設定パラメーターはSAMBAにはない。何か別の理由があるようだ。

 調べ始めると、意外に根の深い問題であることがわかった。そのうち確定申告の期限が迫ってきて、電子工作に時間がかけられなくなった。このあたりで記事をまとめて、話の続きは次回に報告するとしよう。

| | コメント (0) | トラックバック (0)

2017年2月 1日 (水)

RaspberryPiのカメラモジュールで定点カメラの野望

 今年もみなさまに新年のご挨拶をする前に、1月も終わりになってしまいました。昨年同様、正月早々、家族が酷い風邪にやられました。だいたい年末のお節料理の準備で精魂つきはてるようです。

 そんなことで初詣にも行けない散々な状況でしたが、本人だけは5日に学生時代の仲間と珍しく正月七福神詣でをすませ、とりあえず年神さまには義理をはたしました。

Dsc00830 その話はあとでするとして、電子工作の方は相変わらず低調です。というのも昨年来のPCのビデオボードのトラブルが解決せず、これにこだわって万事が進みません。MPU6050の次のテーマとして、滞留在庫の整理を兼ね、RaspberryPiの組み込みカメラモジュールの動作テストをするつもりでしたが、具体的な目的が決まるまで迷走が続きました。

 昨年予定していた忘年会が色々な都合で持ち越しになり、このところ連続して新年会があったことも進まない原因のひとつです。それでも何とか、試行錯誤でアクリル板のカメラマウントをでっちあげ、想定した定点カメラが形になってきたのでブログに上げることにします。以下の報告は備忘録を兼ねているので時系列でわかりにくくすみません(2/1/2017記)。

ビデオカードの不具合に悩まされる(12/29/2016)
 暮れも押し迫ってきたが、電子工作は思わぬ展開で先に進まない。ジャイロセンサーMPU6050の3Dライブラリーのために替えたビデオボードのせいで、メインのPCが頻々とフリーズを繰り返し、安心してPC作業が出来なくなってしまったのだ。

 症状は、ワープロぐらいでは起きないが、動画を見たり、ゲームをしたりすると、画像が途切れエラーメッセージが出る。そのあと復帰することが多いが、時にはフリーズしたり、システムがリセットしたりする。このPCは電子工作専用ではなく、汎用的に使っているので何とかしなければならない。

 出てくるエラーメッセージは「ビデオドライバーの応答がないので、システムをリセットする」というもので、例によってこのキーワードでネットを検索すると、膨大な量の記事がヒットする。Win7時代からの古い問題のようである。何らかの原因で、GPU(ビデオボードのCPU)の応答が遅いと、OSがそのアプリの実行を止めてしまうというものだ。

 少なくとも、元々の内蔵ビデオインターフェース(Intel)では起きていない。ウエブにある症例では、NVIDIA系のボードが圧倒的に多いが、AMDのRADEON系で全く起きないわけでもないという。ワープロや簡単なウェブサーフィンくらいでは起きないが、グラフィック画面で(ゲームのトランプのカードの移動だけでも)大体おかしくなる。

 年賀状も書き終えて、少し暇になったので、色々な対策を片っ端から試してみた。まず、デフォルトで2秒というレジストリーのパラメーターのタイムアウトの時間を、レジストリエディターで5秒に延長する。これでエラーの様子が少し変わったが、頻度はかえって多くなったような気がする。

 次が、ビデオドライバーの更新である。ビデオカードに付属していたドライバーはネットで調べると少し古いので最新のものにとりかえる。全く変化なし。古いドライバーが残っているとおかしくなるというので、ユーティリティを使って古いドライバーの削除とクリーンインストール。これも駄目。

 サイトによっては、NVIDIAのコントロールパネルでのオプションの設定変更だけで綺麗に治ったというのがあったが、全く効果なし。こんな簡単なことで治るわけがないと思う。

 さまざまなことを試してみた。結局のところ最初に比べれば発生頻度は少なくなったような気もするが、完治はしない。頻度が少なくなったとはいえ、ゲームで遊んでいて大事なところでフリーズに見舞われると気晴らしにもならない。フリーズは1分ほど待つと前の状況に復帰することが多いのだが、タイミングが悪いとそのアプリが落ちたり、システムが完全に止まったりする。

 マザーが古すぎて新しいビデオカードと合っていないというのが、どうも最大の原因のような気がする。しかしマザーを変えるとなると、CPUとメモリーまで入れれば、やはり数万円はかかるだろう。そんな馬鹿なことはしたくない。3Dを見るだけのためにとんだ疫病神を引き込んでしまった。

ビデオカードの不具合に決着つかず。別のボードを発注(1/2/2017)

 いずれにしても、こんなに長い間(少なくともWin7時代から)ユーザーを悩ましている問題が全く解決されていないというのも、このPC業界の不思議なところだ。最近のビデオボードのオプションは3D関係(恐らくDirectXというパッケージ)だけで軽く10個以上あり、何か技術の末端肥大を感じさせる。モンスター化して制御不能になってしまっているのではないか。

 年が明けても、あきらめきれず色々しつこく試していた。最も基本的なハードの部分、カードスロットの接触不良を疑い、ビデオボード基板の接点の掃除と差しなおしを何回かやったが、事態は進展しなかった(これで劇的に治ったという報告もある)。

 メモリーとの不適合を指摘するサイトがあり、そこではメインメモリーを交換したら解決したとあったが、この少し古いPCのメインメモリーを買いなおすのはやりたくない。(このサイトは系統的に良くまとめられている。高知の自作パソコンショップが2009年に詳細な調査を行っている。結論はメモリの相性問題ということだ。)

 メモリ交換でなく、PCのBIOSのアップデートでも解決したというサイトもあった。これなら費用もかからない。早速試してみた。久しぶりのBIOSのアップデートである。マザーボードのASUSのサイトを探すと幸い現在のバージョンより先のBIOSが見つかったので(もう2年も前のやつだったが)、入れ替えてみた。

 動かしてみる。ふむ、起きない。これが原因だったのか。暫く使う。駄目だ。1時間ばかり経って、やはり再現した。頻度は明らかに前より少なくなったようだが、全く0にはならない。

 マイクロソフトの基本ドライバーでは全く起きないので最悪の場合はこれに戻せば良い。ただ、このドライバーは3Dをサポートしていないので、Processingの飛行機は動かない。元の内蔵ボードに戻しても動かないことは同じだ。PCを取り替えるという手段も本末転倒である。だとすると、どういうことになる? そう、トラブルの報告の少ないRADEONのビデオボードをウェブで発注してしまったのだ。

谷中七福神詣でをしてきた(1/5/2017)
 しかしお正月なので、品物はすぐには来ない。というので新年での行事をご紹介しておこう。このあいだの筑波山歩きの山(街)歩き仲間が誘ってくれた七福神めぐりである。例年この仲間は、新年に都内の七福神詣でをしているそうだ。今年は、江戸最古という触れ込みの谷中(やなか)の七福神である。

Dsc00839 Dsc00845

 出発点は田端駅近くの福禄寿を祭った東覚寺で、ゴールは上野不忍池の弁天堂である。距離にしておよそ12キロ。街歩きとしては丁度頃合いの長さだ。昔の人は良く考えている。我々一行は正月5日、田端駅に集合した。

 歩き始めてまず驚いたのは、お正月ということもあるが、参詣者の多さである。それも高齢者の小団体が多いのでうっかりしていると他のパーティに紛れて迷子になる。我々も参加者が10人を越えていたので、グループを2つにわけて行動した。 Dsc00857 最近は御朱印帳で参詣の印を押してもらうのがはやっているが(スタンプラリーと同じ趣向)、ここには七福神をイラストした色紙(¥1000)が売られている。ここに各寺、神社の朱印を押してもらう(各¥200)。帰って壁に貼ると結構な正月飾りになる。

 田端駅近くの最初のお寺が少し離れているだけで、ほかは、いわゆる谷中墓地に点在するお寺の敷地内に七福神の祠がある。人通りが多いのはみんな七福神詣の人たちである。お寺によっては長い行列ができている。Dsc00849

 幸い、風もなく絶好の散歩日和で、不忍池の弁天堂で満願成就である。ちょうど日も落ちて来て、お酒を飲んでも後ろめたくない時間になってきた。解散する前に近くのビヤホールで新年を祝って乾杯である。いや生きてきてよかった。

ビデオカードはカードの交換でけり(1/9/2017)
 発注していたビデオカードが届いた。正月休みだったのでネット販売にしては少し時間がかかっている。今度はNVIDIAでなくてRADEON(ATI)である。

 こちらは3Dゲームなどには関心がない。安物で十分だ(玄人志向のHD6450 ¥4000少々)。実は年の暮れ、また秋葉原を覗いたのだが安いものは店頭には殆ど売っていなかった。店頭販売では単価の低い商品は効率が悪いからだろう(数万円が売れ筋のよう)。通販のポイントが溜まっていたので、出費は¥2000程度ですんだ。 Dsc00865 早速、とりかえる。PCI Expressの仕様がやっとわかってきた。前のビデオカードGT710は、PCI Express X8で、今度のHD6450は、X16(スロットのバス巾)ということが始めてわかった。最初のボードのスロットにすき間があったのはそういうことだったのだ。

 結果は予想した通り、トラブルは完全にきれいさっぱり解消した。何時間動かしても、全くフリーズは起こらない。古いマザーとの相性問題というが、これはやっぱり、NVIDIAの不具合としか言いようがない。性能的には、GT710より、3D性能が少し低いが、2DはむしろRADEONの方が高く、何といっても安定しているのが一番である。

 やれやれ、3週間近く悪戦苦闘したあの時間は何だったのか。この執筆時点(1/31)でも起きていない。PC関係で、このあいだのマザーボードといい、このNVIDIAのビデオカードといい、不要不急の部品がまた増えてしまった。ともあれ、これでやっと、本題の電子工作に戻れる。

RaspberryPiのカメラモジュールはあっけなく動いた(1/12/2017)

 電子工作の話に戻る。テーマは、このあいだRaspiのディスプレイを買ったときについでに買ってあったカメラ(Raspi カメラモジュールV1.3 ¥3000少々)はまだ一度も動作させていない。部品棚に眠ったままである(このモジュールは既にV2になって画素数も800万と高性能になっている。価格は高くなってしまった) Dsc00855

 実用ということでは、はっきりした目的はない。自宅の前の道から吸い殻を車寄せに捨てる不届き者がいて家族が怒っている。これを動かして、定点カメラか、ドライブレコーダー的な使い方をしてみれば面白いかもしれない。

 現在、当研究所には、3台のRaspiがある。無印のRaspiが2台(SAMBAサーバー、パンチルトの出来るライブカメラでいずれも最近は電源が入っていない)と、Raspi3が一台である。Raspi3は用途が決まっていないが、電力喰らいなので、無印のSAMBAサーバーにカメラをつなぐ。

 カメラは、最初、逆刺し(絶縁面に接点側が入るので副作用は心配なし)して動かなかったが、このサイトの案内で、専用のコマンド(raspistill や、raspividなど)を使い、簡単に静止画や動画を撮ることができた。

 検証は、SAMBAなのでWindowsディスクにコピーして、PC側で見る。RaspiでXwindowを動かすほどのことでもない。SAMBAサーバーにカメラをつけたのはこれが理由である。

 500万画素もあるので鮮明な画像だ。ビデオも問題なく撮れた。ビデオの再生は、WinPCでは動かなかったので、例の7インチのIGZOパネルを使った。

 config.txtの設定データをこのSAMBAサーバーに移してデスクトップを表示させた。これも順調に液晶パネルが動作し、例の超微細なデスクトップが現れる。シリアルターミナルから、ウェブサイトで教えられた動画プレーヤーomxplayerを実行させる。

 画面はデスクトップ画面である。何かもうひとひねりしないと画像が出ないと思っていたが、一息待ち時間があったあと、突然、画面全体に、工作室を逆さ(カメラモジュールが逆さまになっていた)に映した動画が見事再生された。5秒で10MBばかりのハイビジョンクラスの画像である。とても滑らかな再生で驚く。

久しぶりのアクリル工作は大変だった(1/17/2017)
 さて、カメラは動いたが、課題が2つ残っている。カメラのマウントと、カメラを汎用的なビデオディバイスにすることである。現在は専用のコマンドからで、motionや、mjpg-streamerのようなライブカメラのシステムを動かすには、/dev/videoなどのディバイスファイルにしないといけない。

Dsc00854  それはさておき、まずはカメラマウントの制作である。カメラモジュールは2センチ四方の小さな基板だけであり何らかのマウントが必要だ。それに、FFC(フレキケーブル)が短く、堅いのでカメラの固定が難しい。定点カメラにするならRaspiごと固定する手段が必要だ。

 手持ちのアクリル板を、いつものアクリル曲げ器を使って、カメラマウントに加工することにした。モデルは以前作った赤外線センサーのマウント台である。アクリル板を曲げて2つのコの字フレームを作り、ヒンジで接合する。

 部品庫に眠っていたA4ほどのアクリル板(厚さ2ミリ)をサーキュラーソーで、切り出す。小さなサーキュラーソーなので、20センチ近い長い板の切断は苦手だ。切断面がどうしても歪んできて回転部分の摩擦が大きくなり、下手をすると大事故の心配がある(材料の破損とか飛散)。 Dsc00862

 何とかだましだまし切り出した後、アクリル曲げ器でコの字型のフレームに曲げる。温度が少し低すぎるのか、どうもうまく曲がらない。久しぶりなのでノウハウを忘れてしまっている。温度を上げて何度か曲げを調整しているとき、少し力を入れて整形していたら、ポリっと割れてしまった。

 アクリル板は何度も同じところに熱をかけて曲げていると強度が極端に落ちることを忘れていた。焦げない程度に一気に強い熱を加え一回で曲げ切らないと材料が劣化することを、終わってから思い出す。やれやれ年はとるものではない。 Dsc00863

 結局、外側のフレーム(マウントを固定する方)は2回作り直した。2回目はサーキュラーソーが心配でコッピングソー(糸鋸盤)を使った。外側を半円形に切ると、少しそれらしくなった。

 このあと苦労したのが、チルトさせるためのヒンジの穴あけである。平面時に穴あけして正確な位置合わせをすることは殆ど不可能なので、曲げたあとから穴をあけるしかない。正確な位置決めのため小さいドリル穴から全部リーマーで直径15ミリまで円形を広げたのだが、これが大変で、指に豆を作ってしまった。

 苦労の結果、何とかそれらしいマウントが出来た。ただ、リボンケーブルが固くてマウントそのものを固定しないとカメラを安定した位置に止めることができない。実用的には、Raspiのケースそのものに固定する必要がでてきた。

試行錯誤の結果、まずまずのマウント(1/30/2017)
新年会が続いて工作の時間がとれなかったが、少し落ち着いたので、久しぶりにAitendoに行き、FFCケーブルと無印Raspiのケースが安売りされていたので購入した。

 FFCケーブルは、カメラのケーブルを下から出したくて順目のケーブルを買ってきたのだが、つけてみて大失敗に気づく。このまえのESP8266変換基板のときと全く同じである。FFCケーブルの接続面を替えたら接続は全く逆になる! これをつけてからそれに気が付く馬鹿さ加減にまた暫し呆然となる。

 これは買いなおすとして、はずみで買ったRaspiのケースはあたりだった。うまいぐあいにケース上段に段差が出ていたのでそれにあわせてマウントに溝を作り、きっちりその段差に固定する。おお、ぴったりカメラは固定された。こいつはうまくいった。嬉しくて記念撮影。

Dsc00864  さて次はソフトである。motionなどのライブカメラで動かすには、汎用的なディバイスファイルにするしかけが必要である。もとのSAMBAサーバーのOSはV3のWheezyで汎用的なビデオパッケージVideo4Linuxをサポートするカーネルモジュールが入っていない。最初、このサイトの情報でインストールを試みたがうまくいかなかった。

 そこで、OSの取り換えを試みる。最新バージョンのJessieが無印のRaspiで動く保証が得られなかったがだめもとで入れてみた。幸い、何事もなく順調にインストールに成功。めでたく/dev/video0というディバイスファイルが出た。

 これであとはmotionや、jpeg-streamerなどのインストールをすれば定点カメラが完成する。ブログの紙数も増えてきたので、このあたりで報告を一段落しよう。

| | コメント (0) | トラックバック (0)

2016年12月22日 (木)

ジャイロセンサーMPU6050とProcessingで飛行機の3D姿勢表示

 前から少しづつ進めていたプロジェクト、6軸の加速度・ジャイロセンサーMPU6050をESP8266のArduinoで動かして、PCの画面に3Dの画像(飛行機)を表示する開発がやっと一段落した。MPU6050の基板を手で動かすと、PCの飛行機がそれに合わせて動く。Dsc00804

 当研究所の大きな縛り「実用品を開発する」ことなら、MPU6050は本来ならドローンや2足歩行のロボット(まあ、これも実用品ではないが)に使って始めて開発と言えるのだが、そこまでの足慣らしということで始めた。ところがこれが思ったより難航したのである。Ws000011

Processingの3Dライブラリーが動かない(12/3/2016)
 Processingそのものは、すでに前回、単独で動くことを確認している。これからやりたいことは、MPU6050で検索すると必ず出てくる3Dの飛行機やティーポットをPCのProcessingの画面上で動かすことである。

 ところが3Dに必要なProcessingのリソースをダウンロードしようとすると、殆どの日本語サイトが紹介しているダウンロード先のAndrocityというサイトが変わってしまっていて、先に進めない。

 片っ端からウェブサイトを探し回って何とかファイルを見つけ、インストールには成功した。toxiclibというライブラリーも見つかった。しかし、動かしてみるとProcessingの3D出力のドライバーOpenGLでエラーが出る。平面図形は至極順調に動くのだが、OpenGLが以下のメッセージを出してエラーとなる。

Framebuffer error (framebuffer unsupported), rendering will probably not work as expected

 調べてみると、PCのグラフィックドライバーが古いと動かないようだ。このライブラリ(OpenGL)だけでなく他の3Dライブラリでもトラブっているようで、エラーメッセージをキーにすると海外のサイトが多数ヒットする。

Ws000009

 回避する方法は、残念ながら紹介されていない。基本的には新しいビデオカードに替えるか、メーカーがビデオドライバーを更新してくれるのを待つしかないようだ。しかし後者はこちらの場合望み薄である。

 現用のPCのビデオインターフェースが古すぎる。マザーに内蔵のビデオインターフェースはIntelのG33で、恐らく7年は経っている。最新のIntel汎用ドライバーに更新しようとしても、メッセージは「これが最新です」と出て、状況は変わらない。

 うーむ、買ってくるしかないか。前のPCで使っていた古いRADEONのボードは部品庫に残っているが、これとてかなり古く、動く保証はない。変なところで頓挫してしまった。余り意地になるのはやめようと思うが、どうも気になって他のことに移る気分にならない。

 本来の工作の方向ではない(単なるMPU6050の動作テスト)ので、潔く他のことをすれば良いと思うのだが、へそ曲がりなもので、出来ないとなると余計悔しくて気持ちが納まらない。因果な性分である。

ビデオボードを買ってきて解決(12/6/2016)
 色々迷ったが、次にやることが見つからないので、くだらない話だけれどビデオカードを更新することに決めた。ということで、買うことは決めたのだが、いざ具体的には何を買えばよいのか見当がつかない。PC自作から遠ざかって15年は経っている。

 ネットで久しぶりに「ビデオカード」をキーワードに検索をかけてみた。おお、出てくるわ出てくるわ。この世界はまだまだ活況のようだ。そのうち全体を俯瞰できる親切なサイトを見つけた。なにー、10万円を超すビデオカードが沢山市販されている。中には30万を越すボードもある。これ業務用ではないよね。ハイエンドPCゲーマー御用達のボードのようだ。

 こんな高いボードにはもとより縁はない。お値段は¥5000以下(さっきのサイトのランクでは5段階の下から2番目)、冷却ファンのない静かなボードが条件である。仕事の帰り、秋葉原に寄り、この前PC電源を買い替えたお馴染みのTwoTopで、適当なボードを物色する。ASUSのGeforce GT710を選んだ。¥4200余り。

 家に帰って久しぶりのPC拡張ボードの工作である。ビデオインターフェースのコネクター規格PCI Expressがえらく複雑になっていて悩ましい。バージョンが1から3まである上、2には枝番としてx1だのx16だのに分かれている。買ったきたビデオカード(2.0 x8)が現用のマザーに入るか心配だ。

 スロットに差してみると、何か接続されないピンの空きが多い。不安がよぎったが、とりあえずはきっちり入ったので試しに動かしてみた。BIOSは今のところ何もいじらない。新しいカードの方にビデオケーブルのコネクターをつけて電源を入れてみる。

 良かった。BIOS画面が映った。ビデオカードを自動認識してこちらを使うようだ。ドライバーを入れていないので、MicroSoftの汎用ドライバーで画像は荒いが、Win10までちゃんと動く。付属のDVDからビデオドライバーをインストールすると、正規の1920ドットの画面になった。やれやれ。

 さあ、目的のOpenGLのProcessingはどうだ。おおう、あっさり飛行機が出た。Arduinoとつないでいないので、飛行機はまだ正面を向いたまま動かないが、3Dの部分は問題なく動いているようだ。

 ビデオカードの効果は他にもあった。これまでMicroSoftの無料ゲームの中に、画像の乱れがあったり、やけに動きが遅かったりしたゲームがあったのだが、これらの不具合がすべて解消された。まあ、お金をかけたことは無駄ではなかった。

Processingで画像がグリグリ動く(12/7/2016)
 3Dが出たので、また暫くProcessingで遊ぶ。それこそティーポットやヨット、シリンダーなどの3D図形がマウスの操作で自由に動く。素晴らしい。

 すごく親切なProcessingのガイドがウェブで見つかった。それを夢中になって試す。いやいや、昔に比べると、良くインタプリターだけでこれだけ滑らかな動きが出来るものだと感心する。

 このサイトにも例の3D飛行機(MPUTeapot)の丁寧なインストール方法の紹介がある。この通り忠実に手順を踏めば簡単に動きそうだが、どうもこの前のスマホの無線操縦のように動いた後、何も出来なくなるような気がしてきた。

 もう少し基本からProcessingとArduinoを勉強した方が、のちのち良いような気がする。少し回り道でも、ひとつづつ段階を経て動作を確認していくことにした。ArduinoでMPU6050をドライブし、そのシリアル出力をPCのProcessingで受けて、画像ルーチンの入力にする過程を確認していこう。

 だいたい、MPU6050の6軸のセンサー値の意味も完全に理解しているわけではない。加速度センサーだけで測れるのは、飛行機で言えば、縦揺れ(ピッチング)と横揺れ(ローリング)だけで、縦軸(Z軸)の回転(ヨーイング)は、角速度センサー(ジャイロセンサー)で値を積分しないと測れないはずなのだが確証はない。ちょっとソースを覗いてみたけれど、全く手も足もでなかった。

 独自開発しようと意気込んでいたが簡単に白旗をあげた。このJeff Rowberg氏の開発したMPU6050関係のライブラリーは膨大で、MPU6050.cppなどは3000ステップを超える。I2Cのドライバーだけでも1000ステップ以上で、これを無償で公開されているのには頭が下がる。

ProcessingとArduinoの連携に目鼻がついた(12/10/2016)
 それでも、単にソースをコピーしてきて動かすことだけは避けたい。理由は、コピペだけでは身につかないProcessingとArduinoの技術を少しでも習得しておきたいからである。センサー、MPU6050のI2Cはライブラリを拝借するが、3Dの画像を出す部分は、せめて少しでも理屈を知っておきたい。

 作業を以下のように細かく分割して、ひとつづつ確認していくことにした。

(1)    Processingの学習  例のこのサイトがとても親切に教えてくれる。
(2)    Arduino スケッチとライブラリ構築の復習 これは上記のサイトのここが詳しい。 
(3)    Processingシリアル入出力のテスト
(4)    ProcessingとArduinoのシリアル連携 ここを参考にさせてもらった     
(5)    ArduinoとMPU6050の接続テスト
(6)    ProcessingとArduinoのハンドシェイクプロトコルの決定
(7)    ProcessingとArduinoの接続テスト
(8)    Processingの画像出力のスケッチ作成
(9)    MPU6050とProcessingのテスト

 現在は、(4)まで済んでいる。(5)が課題だ。ArduinoのシリアルコンソールにMPU6050の数値を出すスケッチはたくさんのサイトで紹介されている。これを試すことにする。

ステップ(5)MPU6050の接続テストまですんだ(12/12/2016)
 簡単に通過するはずだったのだが、意外に手間取った。原因はESP8266のI2Cの接続ピンの勘違いである。以前使ったピンアサインのメモに基づいて配線したのだが、MPU6050を認めないメッセージが出る。 

コピペさせてもらったソースに間違いはない(はずだ)。動かないとなると、途端に何も出来なくなるのがArduinoである。ピンの接触不良や、AD0ピンのプルダウンなどを疑うが問題はない。オシロなどを出して波形を見るまでもなく、何か基本的な間違いだと思うが、最初は以前自分で書いたメモを信じていたので途方に暮れた。

 気を取り直してESP8266の正式なピンアサインをネットで確かめる。あっあっあー、SDAピンが違うぞ。なぜだ。どうして間違ったところにメモしたのだ。正しい方にピンを差しなおしテストする。よーし、いいぞ。それらしい値が出てきた。

ステップ(6)(7)は既製のスケッチを流用(12/14/2016)
 次はArduinoのMPU6050のメッセージがProcessingのテキスト画面に出ることを確認する。これは問題なく動いた。ただし、Processingのテキスト画面はスクロールしないので単に、忙しく数字が変化するだけで、見映えはしない。

Procesingserial  Processingのテキスト画面をスクロールするように直したい気持ちが激しく盛り上がったのだが、やっとのことで自制する。ここで脱線するとまた戻れなくなる。我慢、我慢である。

 とりあえず、これでESP8266につないだMPU6050のデータは正しく、Processingに到着した。残るは最後の関門、画像表示である。既成のスケッチのソースを見て調べるが、そう難しいハンドシェイクはしていない。単にメッセージの頭に特定のキャラクター($)を入れて、それをトリガーに後続データを配分しているだけのようだ。

 難しいのはやはりセンサー値の加工である。色々ネットで調べる。クオータニオン(四元数、しげんすうと読む)という3Dでは常識らしい用語を発見して珍しく興奮し、暫く勉強する。いやあ、奥が深い。 

 これからMPU6050から出てきた数値を気安く加工しようと思っていたが、一筋縄で触れるものではなさそうだ。ここは素直に、既成のスケッチを使わせて貰うことにしよう。まずは動かすことが先決だ。

ステップ(8)(9)はMPUTeapot2のプロジェクトをそのまま使う(12/15/2016)
 人さまの動いたソースを借用するのだから、すんなり動くのかと思っていたが、そうは問屋が卸さなかった。参考にしたサイトは、すでに紹介したここである。

 このサイトは、以前、懸命に探し回ったリソースがちゃんとダウンロードできるようになっており、ここだけですべてが動く(実は大きな落とし穴があったのだが)。順調にMPUTeapot2のライブラリを入れてArduinoとProcessingを動かした。しかし、エラーメッセージが出るだけで機体は動かない。

 例のArduinoの弊害である。 スケッチソースは長大で、ちょっと目検したくらいでは何がおかしいのか見当はつかない。手も足も出ない状態だ。まあ、救いは、散々連携テストをしてきたので、ハードなどの問題はなく、動かない原因は現在入れたアプリケーションソフト(のはずだ)だ。

 ただ、エラーメッセージが奇妙である。つながったことを示すステートメントは出るが、何か(割り込み)を待つというステートメントのあと、タイムアウトが起きてリセットされ、これが延々と続く。

Initializing I2C devices...
Testing device connections...
MPU6050 connection successful

 

Send any character to begin DMP programming and demo:
Initializing DMP...
Enabling DMP...
Enabling interrupt detection (Arduino external interrupt 0)...
DMP ready! Waiting for first interrupt...

 

Soft WDT reset  (以下繰り返し)

 何らかの外部割込みをArduinoが待っているような感じだ。しかし、参考にしたサイトの結線図にはMPU6050の割り込みピンの接続はない。他のサイトを見るとMPU6050のINTピンが結線されている配線図や、動画が見受けられる。

 うーむ、どっちなんだろう。Arduino UNOでは割り込みピン#0に繋ぐという説明があるが、ESP8266には外部割込みピン#0はない(GPIO#0はあるが、これは制御用に使っている)。つまり繋ぐところが見当たらない。 Dsc00802

 こうなったら本当にMPU6050が割り込み付きで動いているのか(ソフトで設定できるようだ)、確かめるのが先決だ。もし、割り込みモードで動いているのなら、先の配線図が誤りということになる。

 オシロを持ち出して、MPU6050のINTピンを観測した。ピンポーン!当たりだった。I2Cのメッセージが出される前後に派手に割り込み信号が上がっているのを確認した。そうか、やはり必要なのだ。しかし、割り込み入力はESP8266のどこに入れたら良いのだ?

 恐る恐るArduinoのスケッチソースを調べ始める。良かった。見つかった。setup()ルーチンの中に、割り込みピンの定義をしているらしい以下のステートメントを発見した。

attachInterrupt(0, dmpDataReady, RISING);
mpuIntStatus = mpu.getIntStatus();

ふーむ、ここが0になっている。ESP8266のピン0は、ファーム書き込みの制御ピンのためプルアップされたままで入力には使えない。

やっとのことで飛行機が動いた(12/16/2016)

 ここを適当なピンに定義し直せば良いのはないか。希望の光が見えてきた。こいつをESP8266の適当なピンにアサインする。とりあえず2にしてみる。あせる手でジャンパーをMPU6050のINTピンの間に飛ばし、再ビルドする。

Ws000010_2  動く予感がする。まず、Processingを動かす。Arduinoはまだ電源を入れない。続いてArduino(ESP8266)の電源を入れる。これまではタイムアウトのメッセージが出るだけだったがどうだ。おおー、コンソールに字化けしたメッセージが出始めた。しかし依然として飛行機は動かない。

 割り込みジャンパーコードを抜き差ししているうち、突然メッセージが規則的なデータ列になった。同時に飛行機がズルッと動いた。何かのタイミングでMPU6050が暴走するようだ。ESP8266を立ち上げてから割り込みを有効にすると暴走しないことが多い。

Dsc00807  やった、やった。MPU6050を載せたミニブレッドボードを動かすと飛行機が姿勢を変える。反応はとても早い。やれやれビデオボードまで新調してやっとのことで、画像を動かすことに成功した。何度も電源を入れ直し動作を確認する。ささやかな達成感で胸が膨らむ。

 最後が少し手間取ったが(サイトの記述を信用しすぎた)、動いてしまえば何の問題もない。冷静になって考えれば、実にくだらない作業なのだが、仮説をたてて、ひとつづつ問題を解消し、それが思い通りになったときは、どんな小さなことでも嬉しい。これが電子工作の醍醐味である。

| | コメント (2) | トラックバック (0)

2016年11月28日 (月)

行き当たりばったりの電子工作(2)

 WiFiモジュールESP8266とスマホを組み合わせた玩具のクローラーの無線操縦は、ウェブのソースをそっくり頂戴して、すんなり動いた。しかし、Arduinoによる開発なので経験値はさっぱり上がらない。達成感にも欠けるし、先に進もうという意欲がどうも盛り上がらない。

 そうこうするうちに、前回のブログからもう一か月が経ってしまった。これまでの経験で、記事の間隔をこれ以上開けると内容をまとめるのに苦労する。で、まとまりに欠けるが、これまで書き貯めたメモを元にこれまでの活動をご報告する。相変わらずの行き当たりばったりでごめんなさい。

AtmelStudio7がすんなり入った(10/21/2016)
 ESP8266周りの制作が一段落したので、このあいだうまく行かなかったWin10でのAtmelStudio7のインストールを再度試みてみた。AtmelStudioの中核アプリVisualStudioは好きではないが、一旦動けばデバッグ機能が豊富なので動くことに越したことはない(まあ、AVRあたりのソース量ぐらいではあまりメリットはないが)。

 新しくインストーラーをダウンロードし直し、インストールをやってみた。これが何ということか、全く問題なくインストールが終了したのである。時間もそう長くかからなかった。理由はよくわからない。狐につままれた心境である。Ws000000 確かにWin10は1週間ほど前、更新が入った(不本意ながら)。AtmelStudioのインストーラーのバージョンも以前の、7.0-1006から7.0-1188に上がっている。しかし、どうも、これだけの理由だけとも思えない。動いたのは良いけれどあまり気分は良くない。

 実際にプロジェクトを入れて試してみた。正常に動いた。ただ、以前のAVRStudioのプロジェクトは認めてくれない。古いバージョンのImport/exportができるというのでやってみた。Importそのものは正常に終わったが、ビルドしてみるとmakefileでエラーになる。

 以前のAtmelStudio6のときも、こんなことがあったような記憶がある。ライブラリーのディレクトリ位置が、makefileの中身とずれているようだ。こういう統合環境のデバッグは意外に厄介である。ウェブ上で解決策を探るが、有力な情報は得られなかった。

 当面、includeするソースをカレントルート(main.cがあるところ)に置いておけば、正常にコンパイルできるはずなので、とりあえずそのままにしておくことにする。現在、AVRでの開発プロジェクトはない。

あっけなくDRV8835は稼働。こんな簡単で良いのか(10/29/2016)
 最近、秋月電子では、DRV8835というモータードライバーICが売られている。こいつはひとつだけで、2つのモーターの正逆転を個別に制御でき、容量も一回路あたり1.4Aまで流せる。以前試したBD6211あたりより容量が大きい。しかも今、作っているMP4212などよりはるかに安い(MP4212はひとつだけで¥380、DRV8835は2つ動かせて¥300)。

Dsc00767 モード0、1(2つのピンの1が正転、逆転になるか、一つのピンがON/OFF、もうひとつのピンが正転と逆転)の動作テストもする。これも全く問題なく動いた。

 このあいだ、秋月でMP4212のドライバーのフォトカプラーを買うときに、矛盾するけれどこいつも買ってしまったことは、前の記事ですでに紹介した。ただ、買っただけでテストはしていない。このままにしておくと部品箱の肥やしになってしまいそうなので、動かしておくことにした。

 動かすと言っても、ブレッドボードに刺して、ジャンパーコードで電池とモーターを接続するだけである。部品はいらない。とりあえずシングルモーターでテストする。何の問題もなくモーターは正転逆転した。少々回しっぱなしにしても、クローラーに使ったFA130くらいのモーターなら、チップはちょっと暖かくなる程度で楽勝である。

 MP4212で苦労した配線や、ダンパー抵抗も必要ない。あまりにも簡単に動きすぎて、気が抜ける。基板面積は恐らく1/10くらいだろう。Hブリッジを知らなくても、これくらいのモーターなら何も考える必要がない時代になったのだ。

 今まで秋月C基板の1/4近くを占めて作ったMP4212のモーター基板はいったい何だったのか。まあこれはもっと大きなモーター(数A)に使えるから良いものの、何かやるせなさを感じる。Arduinoと同じ展開だ。モーターの経験値は上がらないし、一旦動かなくなれば対処不能だ。

ジャイロセンサーMPU6050をどう料理するか(11/6/2016)
 スマホなどの普及で、安価なペリフェラルディバイスが大量に市場に出回っている。以前なら考えられない高性能なセンサーが破格の値段で買える時代になった。

 このMPU6050もそのひとつだ。4、5年前なら3軸の加速度センサーだけで数千円していたのが、こいつは、加速度、ジャイロあわせて6軸のセンサーなのに¥1000以下で手に入る。これもアマゾンで、ウェブの話題につられて、使うあてもないのにポチッとして買ってしまった。

 次のプロジェクトは、この部品箱の肥やしになっているジャイロセンサーMPU6050をESP8266に絡ませることにしよう。ウェブサイトには沢山の応用例を見ることが出来る。これはArduinoのおかげである。

 どうもI2Cで簡単に動くようだ。ただ、動かすだけでは面白くない。これまでに何度も懲りている。「入れました。動きました」で終わりたくない。もう少し、手の込んだことをやっておきたい。

 とはいえ、倒立一輪車や、ドローンなどの姿勢制御まで一気に進むのは簡単ではない。最近のスマホなどの動画をブレなく撮影できる手持ちジンバルなども食指をそそられるが、これもすぐに思いついて作れるレベルでもない。

 色々迷ったが、とにかくMPU6050を動かすことを当面の目的とし、結果を少し凝ることにした。単にコンソールに数字を出すだけでなく、PC上でポットや飛行機などの姿勢が変わるシステムを作りたい。Arduinoと連携して、PC上に動画を出すProcessingというアプリがあるらしい。

Processingのインストールなどで参考にしたサイトは、
   http://kimizuka.hatenablog.com/entry/2015/05/01/000000
である。Processingそのものの解説は以下が詳しい。
    http://robo.mydns.jp/Lecture/index.php?Processing

 しかし、構想ばかりが膨らんで、なかなか具体的な計画にならない。メモに構想(妄想)を書き散らすだけの日々が過ぎていく。

本日ESP8266で全くの徒労。最近こういうのが多いな(11/10/2016)

 このところ雑用で忙しかったが、久しぶりにまとまった時間が出来たので、そろそろ次のプロジェクトのハードのため、一つ残っていた予備のESP8266をピッチ変換基板に実装する工作をやった。

 これまでの2つのESP8266には何らかのファームが入っており、これをつぶすのに抵抗があったのと、何か手を動かしていないと落ち着かない性分になってしまったこともある。しかし、これが2日間の泥沼の作業になるとは予想してもいなかった。

 ピッチ変換基板は、Aitendo製で、milピッチのレイアウトがこれまでの一列づつの両側ではなく下に2段にまとまった基板だ。以前、この2種類を2つづつ4枚買ってあった。リセットSWやレギュレーターを配線したブレークアウト基板を共通にしたいため、ブレークアウト基板の方に2段目のソケットを追加して動くようにした。 Dsc00769

 よく考えれば、こんなことはあり得ない(ピンアサインが両側一列と下側2段と同じ)のだが、何を勘違いしたか、両側1列の片側をそっくり寄せてレイアウトして実装してしまったのである。これがまた情けないことに、すべての半田付けを終わって動作テストしたときに始めて気が付いた。

 テスターで調べたら、全くピンアサインが違っている。極く当たり前の話なのだが、これを今頃になって気が付くおのれの愚かさに暫し呆然となる。9本の配線のハンダ付け18か所が全く無駄になった。お馬鹿にもほどがある。

 まあ、ここで自暴自棄にならないところが、自分で自分を褒めてやりたいところだ(と必死に自分をかばう)。叫びたい自分を押し殺し、低温ハンダを持ち出して、ブレークアウト基板に増設したピンソケットをとりはずした。さらに普通のハンダを盛って、ハンダ吸い取り線で丁寧に掃除する。

Dsc00766 ここでさらに失敗をしたら破滅的なことになるので、慎重に作業を進める。やっと前の状態に戻った。このままでは腹の虫が収まらない。愚かな自分を慰めるために汎用基板の切片を取り出してピッチ変換基板のさらに変換基板を作り始めた。

 下段2段のピンアサインは、調べたら両側一列とは全く異なり、通常のピン順序を無視した無茶苦茶な配列で、どうもアートワークを簡単にするためらしい。ということで変換基板の配線はむしろ簡単に済んだ。ちょっと背が高くなったが、問題になるレベルではない。

Dsc00763 ほぼ2日かけて、新しいピッチ変換基板の変換基板が完成した。恐る恐るテストする。最初の誤接続でのESP8266の破損を心配したが問題なく動いた。一安心である。実にくだらない作業だったけれど、何とか事態を収拾した。不思議なことに、こんな後ろ向きの仕事なのに満足感がある。

Processing単体では問題なく動く(11/14/2016)
 MPU6050をテストするのにビジュアルなベンチを用意したいということで始まったProcessingだったが、インストールのあと、本題を忘れて、もっぱらProcessingの画像表示を楽しんでいる。

 当初、PCで動くProcessingは、外見がArduino IDEに似ているので、何かと思ったが、動かしてみれば単なるJAVAのインタープリターで、画像などを簡単に出せるものだということがわかった。Arduinoそのものとは直接の関係はない。

 「Processing 入門」などのキーワードで調べると、沢山のウェブサイトが見つかる。適当なものを選んで演習する。これは楽だ。実にあっけなくPC上で図形を加工しながら動画にできる。また年寄りの繰り言になるが、あのC言語でグラフィックLCDに円を描く関数を開発していたのは何だったのかという気分になる。

 Arduinoとの連携は、単に、Arduinoのデバッグ用のシリアルインターフェースを利用しているだけで、大層なしかけがあるわけではない(と思う)。 要するに、どちらかのトリガーで、あらかじめ決めたデータをArduinoが送り、それによってProcessingの画像が動くと考えれば良い。

 理屈がわかってしまうと、途端に先に進む意欲が低下する悪い癖が出て、開発のテンポが落ちる。適当な応用例がサイトで見つからないのだ。みんな沢山のライブラリーが必要なようで、やってみる気がなかなか起こらない(気位ばかりは高いが実はへたれである)。

筑波山に登ってきた(11/17/2016)
 そこで、電子工作以外の話題をひとつ。所長は関西の出身で、東京に出てきた京都の高校の同級生がここ15年近く健脚自慢のメンバーで定期的に山や街歩きをしている。今回は、筑波山に登るというので仲間に加えてもらった。Dsc00690

 ちょうど紅葉のシーズンなのでそれも楽しみだが、筑波山あたりは関西から東京に出てきた者にとっては全く盲点と言っていいくらい知らないところで、殆ど行く機会がない。しかもつくばエキスプレスという新しい鉄道に乗るのもはじめての経験で、何かわくわくする(所長は元鉄道おたくである)。Dsc00706 Dsc00732

 筑波山に登るといっても、ロープウエイとケーブルカーが整備されており、ほとんど登る行程なしに、男体山、女体山という2つの峰に行くことが出来る。それでも一週間も前に古い軽登山靴を物置から出して磨く。家族から、「まるで小学生の遠足ね」と冷やかされる。

Dsc00735 Dsc00746  朝8時に秋葉原に出る。ウイークデイなので長いエスカレーターは上りの通勤客の大群にはばまれ、地下の深いホームにたどりつくだけで一苦労である。終点のつくば駅からのバスは平日にもかかわらず乗客で満員だった。驚いたことに外国人のパーティが1/3近くおりバスの車内は外国語で溢れていた(彼らは大声ではしゃぐ)。 

Dsc00750  寒いとおどかされていたが、好天に恵まれて絶好の山日和である。男体山は、女体山より標高は7mも低いのに、山道は岩だらけの急坂で、かなり息が上がったが、女体山の方はアプローチが長いので簡単に頂上に出た。

 女体山からは霞ケ浦が一望できる。ただ、もやで残念ながら富士山は見ることはできなかった。それでも、帰りのロープウェイからの極彩色の紅葉は素晴らしかった。

PC連動ACコンセント自作に脱線する(11/21/2016)
 さらに、くだらない寄り道をしている。当研究所のメインPCには、PC電源連動タップが装備されており、メインの電源の入り切りで、周辺の機器(ディスプレイ、スキャナー、オーディオなど)も連動して作動するようになっているのだが、このタップの具合が最近おかしくなってきた。

 足元に置いてあるタップが足で動かされると、偶(たま)にだが、PC本体の電源が瞬断し、PCがリセットしてしまう。作動中のPCの突然の電源断は、Win10では少し丈夫になったようだが(セーフティスタートを強制されない)、この前の電源故障のときに懲りている。何とかしないといけない。

 この連動タップは10年以上経っているので買い替えても良いのだが、電子工作の経験を積んで来ると工作心が刺激されて、ただ買い替えるだけでは芸のない話である。で、脱線して、この連動コンセントを作り始めた。昔のPCならいざ知らず、今はUSB端子があるのでわざわざPC電源から5Vを引き出す必要もない。USBから5Vを出しリレーひとつで出来上がるはずだ。

Dsc00755

 ACインレット、アウトレットなどの工作だけである。プリンター電源のLAN制御のとき使った15Aを入り切りできるメカニカルリレーの予備があるが、せっかくだからもうひとつのAC制御、SSR(Solid State Relay シャープS108T02)を使ってみることにした。

Dsc00761  何の電子工作らしいところはない。単にケースの工作だけのようなものだけど久しぶりのコッピングソーやボール盤(んな大げさのものでなく単なるドリルスタンド)を持ち出しての工作は楽しかった。配線は、単に入力にLEDの制限抵抗を入れ、インレットとアウトレットのACの太い配線をはんだ付けしただけである。

 それでも慎重を期して、10項目に上る作業項目をメモに書き、赤ペンで消していく。SSRを普通のリレーと勘違いして、直接5Vを端子にかけ、ひとつ¥280もするSSRをお釈迦にしたことは秘密である。Dsc00759

 出来合いのヒートシンクをつけ、接合部分には本式に伝熱グリスを塗り、USBソケットを補強し(ソケット部は特に必要)、あれこれ3つ以上買ったケースの中から作りやすいケースを選び、半日かけてSSRによるPC連動スイッチが完成した。

 勇躍テストに入る。ACを扱うのでバラックで事前に動作テストは済んでいるが、PCで動かすのは初めてである。動いた! 念のためオシロでUSBが立ち上がる波形を見る。PCのUSB電源の立ち上がりは、起動スイッチと同時にUSB側も立ち上がるようで、パルス状ではなく徐々に(立ち上がり6ms程度)で5Vになるようだ(電源断も同じカーブ)。

 PCも無事立ち上がり、shutdownで電源も切れる...ん、切れない。えー、どうして?調べた結果、このPCのマザーは、待機時にWake Up LANなどのためにUSBがOFFにならないUSBコネクター部があるようで、USBプラグを待機時にOFFになるところを選んでOKとなった(マザーボード上のピンでOFFにすることもできるようだ)。

 とりあえず、工作の目的は果たした。少々足で電源をいじっても瞬断の心配はなくなった。きりの良い所なので、報告をここらで一段落する。

| | コメント (2) | トラックバック (0)

2016年10月20日 (木)

ESP8266とスマホでクローラーの無線操縦をためす

 メインPCの電源故障でWindows10をこわしてしまい、再構築したのだが有力なアプリが全滅してしまった。電子工作どころではない。ブログを書き込むだけの最小限のソフトを再インストールして、前回の記事は何とかアップしたが、その後も悪戦苦闘が続いた。

ロジックアナライザーのドライバーが入らない(9/15/2016)
 この間やっとWindows7からWindows10に切り替えた直後にこの事件である。ワードやエクセルは幸いインストールCDが手元にあったので簡単に戻り、ブログの記事のアップや会社の決算などは無事終わったが、電子工作の開発環境のアプリなどは、ショートカットが残っているだけで本体は殆ど影も形もない無残なありさまだ。

 アプリを使う機会のたび、少しづつ修復作業を続けた。大方のソフトは生き返ってきたが、この前も、てこずったZEROPLUSのロジアナLAP-C16128がうまく入らない。みんなWin10で苦労しているようだ。

 それでも最近は販売元が、win10をサポートする最新版を出しているので大丈夫だという情報を見つけた。しかし何度やっても、その公式インストーラーは変なエラーメッセージではねられる。例のエラーメッセージを直接Googleに喰わせる方式で探索すると、ウェブからは解決法が沢山でてきた。しかしどれを試してもうまくいかない。 Ws000008 何か汎用的な相性問題のようで、特定(ZEROPLUS)のアプリのウェブの記事は少ない。いくつかあるZEROPLUSの記事はみんなWin8時代のものばかりである。最初にWin10に入れる時も苦労している。このときは、何回か失敗したあと、いつのまにか動いた。どうも悪い予感がする。

悪戦苦闘。遂にLAP-C16128のドライバーインストール成功(9/20/2016)
 この1週間、喉に小骨が刺さったように気になっていた、ドライバーのインストールが、どういうはずみかうまく入った。何が原因だったのかはわからない。色々な方法を試すうち、偶然のようにうまく動いた。どうにも気分が悪い。

 製造元のWin10で動くというインストーラーでエラーが出る。このインストーラーはドライバーとアプリケーションを別々にインストールするようになっている。まずドライバーをインストールすると、途中で以下のメッセージが出てインストールが中断される。Win10のディバイスマネージャーのZEROPLUSのアイコンの下のLAP-Cドライバーには故障のマーク(!)がついたままだ。

 アプリケーションは最初の1回はなぜか問題なく入ったが、環境を元にもどすため、一度アンインストールして再度入れようとしたらその後は全く入らなくなった。エラーメッセージは、ドライバーもアプリも同じで以下のようなものである。
  1608: Unable to create InstallDriver instance.
  Return code -2147221021

このエラーメッセージを直接、Googleに放り込んで見ると、海外を含めてさまざまな解決法が出てくる。インストール時の共通のエラーのようで、沢山のソフトでの発生事例が報告されているようだ。どうしてこういうこと起きるのかという説明が不足しているので手探りである。

原因が何かがわからない。何かの拍子にwindowsのインストーラー関係のリンクがおかしくなるのだそうだ。こちらはWindows10を再インストールしているので、このあたりは大いに可能性がある。

 いくつかのサイトをまわるうち、以下の方法(Idriver.exeを独自に実行してから、インストーラーを動かす)をやると、少なくとも上記エラーは出ないで先に進むことがわかった。しかし、ドライバーは正常にインストールされない。

c:\Program Files\Common Files\InstallShield\Driver\1150\Intel 32>idriver

 レジストリーを綺麗にするユーティリティ(CCleaner)を見つけたので、これで不審なレジストリーを消去するが変わらない。仕事場のノートPCで試しにインストールしたら、何の問題もなくドライバーが入った。やはり、この自宅のPCの固有の問題であることは明らかだ。

 自宅にもどり再度挑戦する。こういうのは気になったら止められない性分である。CCleanerのメニューの中に、レジストリーだけでなく不要なプログラムを消す機能がある。これを見ていると、消したはずのLAP-Cのドライバーが存在していた。これは怪しい。とりあえず、それを消した。

 これが良かったのかもしれない。インストーラー始動前に、必ずこれ(Idriver.exeの実行)をやるようにし、さらに管理者権限で必ず、setup.exeを始動するようにした。何度目かのトライで何と、インストーラーが順調に動き、ディバイスマネージャーのアイコンから!マークが消えた!

 LAP-Cが問題なく動いた。ふー、やれやれ。決め手がなんであったのか確証がないのが心残りだが、とにかくこれで他のことに移れる。それにしてもOSの変更は大型機の時代からユーザーにとっては実に厄介なイベントである。

 昔は、性能が良くて安価な新しいハード機器を動かすために、渋々替えてきた(これはメーカーの戦略)。バージョンアップはそれなりにユーザーに利益をもたらしたのだが、今や、バージョンアップは、ユーザーにとって何の役にも立たない作業になり果てている。ベンダー、メーカーの都合に付き合わされるのは、もうそろそろ止めて貰いたい。

今度はAtmelStudioが入らない。これは少し静観(9/24/2016)

 次のAVRの開発環境、AtmelStudioは、結局、諦めた。これがなければAVRを動かせないわけではない。あの愚鈍な象のように重いVisual Studioは正直言って、あまり愉快な環境ではない。

 当研究所は、AtmelStudioで使っているのはエディターとビルドだけで、書き込みは、ChaNさん謹製の超軽いAVRSPである。コマンドプロンプトに一旦入れておけば、コマンドのリピートキー一発で何度でもビルドを繰り返せる。

 それでも一応は入れておこうと、最新版のAtmelStudioをダウンロードし、インストールを始めた。延々とVisualStudioをインストールし始める。そのうちインストーラーがハングアップしたようで、一時間近くほっておいても終わらなくなった。リソースマネージャーで見ると、どこかでループしていることは明らかだ。

 サイトの情報にも、いくつかハングアップの事例が報告されている。抜本的な解決策は見つかっていないようだ。まあ、AtmelStudioは必須の環境ではない。なければAVRtool Chainをインストールして裸でmakeしてもかまわない。これは少し静観することにする。

 そのうちWindows10に入っている無料のゲームソフトが思いのほか面白く、PCを立ち上げても、それに時間をとられて、まともなことをやる気力が盛り上がらなくなった。ゲームにはまって気が付いたら深夜という繰り返しの毎日で、電子工作そのものの動きが停滞してしまった。

久しぶりに秋葉原に行きモータードライバーなどを調達(9/30/2016)
 それでも、Win10のインストール騒ぎの最中、実は少しづつ続けていたハード工作がある。8月に面白がって買ったアームクローラーの工作である。モータードライバーをMP4212で作っていた。ブレッドボードでのテストでは問題なく動いた。

 クローラーにESP8266基板と、MP4212を2つ載せたモータドライバー基板を2階建てで取り付けるつもりで準備を進める。ブレッドボードから汎用基板に部品を移して配線する。久しぶりのはんだ付けを楽しむ。

Pa207520 クローラーについているモーター程度(マブチのFA-130)でMP4212を使うのは少し勿体ないが、以前、1Aまで流せるというBD6211というモータードライバーをこのモーターに使っておかしくしてしまったことがある。モーターが止まるほどの過負荷をかけると、こんな小さいモーターでも1A以上が流れこわれてしまったらしい。用心に越したことはない。

 このサイトの情報を参考に、最終的には、ESP8266とスマホでラジコン化するのが当面の目的だ。片側のMP4212の実装が済んだので、実際にモーターの電源を利用してHブリッジの動作を確認する。電源は、ニッケル水素電池2つか、800mAhのリチウム電池である。

 ところがMP4212のモータードライバーの動きがどうもおかしい。4Vのリチウム電池では何か瞬間的に貫通電流が流れるらしく、瞬断してうまく回らない(動くときもある)。回路的に悪いのか。あのフォトカプラーを直接論理回路化した回路が悪いのか。

 FETの動作原理を復習する。どうも、直接、ロジックだけであのHブリッジを動かすのは無理な感じがしてきた。あのままでは、FETのゲートに電荷が溜り誤動作するような。要するに単なるスイッチではドライブが出来ない感じがする。

 念のため、オリジナルが正しく動くどうか、フォトカプラー(TLP250)を試してみたくなった。久しぶりに秋葉原の秋月にでかける。行ったついでに、1.4Aまで動くというデュアルモータードライバーモジュールDRV8835(¥300)を買った。これはひとつで2つのモーターを動かせる。さっきのフォトカプラーの回路ならフォトカプラーだけで4つ(¥150X4=¥600)もいるところでこちらは断然お得だ。

 しかし、MP4212のモータードライバーの片側も実装し、電源の接続ピンを新しくしたら、Hブリッジは全くトラブルなく快調に動いた。MP4212モータードライバーの不可思議な動きは、どうもピンヘッダーの接触不良の疑いが濃厚だ。今、別個にテストしているが何の問題もない。

ESP8266の復習を始める。フラッシュファイルシステムも戻った(10/4/2016)    
 ESP8266をおさらいする。まずは、棚からとりだしたESP8266モジュールの埃をはらい、動作の確認をする。これまでやった実験(フラッシュファイルシステム、RTC、ATコマンドファームの書き戻しなど)を次々に追試した。

 フラッシュファイルシステムが動かなかったが、これはATコマンドモードに戻したとき、ファイル本体とディレクトリのリンクが切れてしまうらしく、フラッシュファイルをもう一度書き込んだらOKになった。こうしたリハビリでESP8266周りの視界が広がり、最終目的(スマホでラジコン)開発の体制が整ってきた。Dsc00584 最終目的は、ESP8266はソフトAPモードにして、peer to peerでスマホとつなぎ、ラジコン化することだ。このウェブ記事のソースをそのまま借用することにしている。このスケッチのスマホのボタンで、クローラーの前後進、左右移動が、ボタンのタップで出来るはずだ。

 まずは、ATコマンドでソフトAPモードにする。これは問題ない。簡単にスマホにサイト名が出た。勢いに乗って参考サイトのコマンドを入れて、スマホと接続。ESP8266のコンソールから接続を知らせるメッセージが出た。しかし、このあとのHTMLシーケンスはないので何もできない。これはここまで。

ESP8266とスマホでクローラーの無線操縦ができた(10/13/2016)
 人様のソフトをそっくりいただいて、ESP8266をAPモードにし、スマホとpeer to peerで結んだリモコンで、めでたく、このあいだ作ったアームクローラーが動いた。スマホのタップによる動作指示は、やはり少し遅れるので本格的な操縦というより「動きます」というのを確認できる程度と考えて良い。スマホのタッチスクリーンの操作をこれからマスターしていかないと実用にはならない。Dsc00588

 電源は、モーターをニッケル水素の乾電池2つ(2.8V)、ESP8266の方はリチウム電池(3.7V)に独立させた。ESP8266基板に、低ドロップレギュレーター(AMS1117)を実装して3.3Vにしている。

 このニッケル水素乾電池のフォルダーをシャーシーに固定するのにえらい時間がかかった。始めはフォルダーをかっこ良くはめ込み止めにしようと、アクリル曲げ機まで動員して、アクリル加工をしようと試みたのだが、意外に難しく(薄いアクリル板は曲げるとそこが極度に弱くなる)、バッテリーフォルダーの素材が瞬間接着剤を受け付けないタイプ(ポリスチロールか)で接着はあきらめた。Dsc00590

 かわりにリアフェンダー(アームクローラーは角度をつけて動くので)に、アクリル小片でバッテリーフォルダーをはさみ、ねじ止めした方法が、簡略だがとても具合よくバッテリーを固定することが出来た。始めから奇をてらわずこうしておけば良かったのだ。

 今回もソフトウエアはAruduinoのスケッチをそっくり拝借したので、全く経験値は上がらなかった。まあ、一旦決めたこと「ESP8266とスマホでラジコン」という命題を何とか挫折なく最後までやりとげたことが救いといえば救いだ。

 次のテーマが問題だ。折角買ったDRV8835はまだ動かせていない。いまだに、あの「ときめき」が電子工作では復活していない。当研究所の活動にはまだまだ暗雲が垂れ込めている。

また新東名を走ってきた(10/16/2016)
 ここで電子工作以外の話題をひとつご報告。車で関西に法事と墓参りのため、帰省した。3年近く前、亡くなった長姉の見舞いに来て以来の長距離ドライブである。例の新東名(第二東名から名を替えたらしい)は以前に比べると車の量が増えたが相変わらず快適だ。Dsc00632

 しかし、トンネルなどの一部は十分な3車線の広さがあるのに、速度超過を心配したのか、路側帯を広くしてわざと2車線にしている。確かに次元を超えたスピードが出るので何とか速度を落とさせようという魂胆なのだろうが、せっかくの機能を台無しにする、いかにも日本の行政らしい「余計なお世話」である。

Dsc00648 お墓は大阪(豊中)にあるが、法事は京都で行われた。いつも、京都では錦市場でおみやげを買って帰るだけだが、今回は珍しく市内の行事を調べて銀閣寺で特別公開があるというので、何十年ぶりかに東山の銀閣(慈照寺)に足を延ばした。

 特別公開は、足利義政の持仏堂で書院造りの原点といわれる東求堂(とうぐどう)の内部と与謝蕪村などの襖絵である。「写真はとるな。角のある持ち物をふりまわすな。壁にもたれるな」とやけにうるさい。まあ、国宝なのだから仕方あるまい。

Dsc00643

 ちょうど雨上がりで、庭園の緑がとても美しかった。義政は西の苔寺(西芳寺)を愛していたらしく、豊富に苔が各所に使われて庭を引き立てている。有名な砂の山や、砂の海原は江戸時代の考案らしく、義政本人の趣向には見えない。

 錦市場で、いつもの、三木鶏卵の卵焼き、打田の漬物、丹波の栗などをしこたま買い込んで、機嫌よく、秋の京都をあとにした。それにしても外国人の数はすさまじい。初日のホテル(ノク京都)は外資系もあるが、90%は外国人で、日本人の数に入れていた隣の夫婦連れは、近くを通ったら日本語を喋っていなかった。

Dsc00641 前回と違い、帰りの東名は幸い大きな渋滞にもあわず(海老名で30分くらいの事故渋滞だけ)、5時間余りで東京に戻ってきた。昔、正月一日に、がらがらの東名をしゃかりきに飛ばした私のコースレコード5時間ちょうどに迫る記録だ(もっともそのときの距離は506キロ、今は480キロ)。

| | コメント (2) | トラックバック (0)

2016年9月11日 (日)

電子工作は復活できるか。行き当たりばったりの工作

 また更新が遅れている。とうとう8月は記事を一本も出せなかった。このブログの大きなテーマである電子工作をろくにやっていないので書くことがない。当然と言えば当然なのだが、電子工作を始めてもう10年近く、ブログも8年を経過し、このブログは自分の備忘録として欠かせない存在になっている(物忘れがひどいのでこれが頼り)。

 大げさに言えばこれが人生の一部になってしまったような感じで、何か書いていかないと、自らの存在を否定してしまうような恐怖感を覚えるほどだ。ということで、読者の方には甚だ申し訳ないが、今回も脈絡のない行き当たりばったりの電子工作の記事を読んでいただくことになる。申し訳ない。

赤外線学習リモコンはとりあえず撤退。復旧作業に入る(8/1/2016)
 Windows10のインストールにかまっていたら、あっというまに8月になっていた。前回はやっとのことでブログ記事を上げたが、電子工作の部分は極くわずかで、大部分は、同窓会と病気とPCの話ばかりである。工作机のブレッドボード上の学習赤外線リモコンの配線は、ロジアナのプローブで山盛りのように盛り上がったままである。

 とにかく、先に進む意欲が生まれない。迷路に入ってしまったこともある。テスト対象にしている赤外線リモコンボリューム(自作)の方が頻々と暴走を繰り返すので、本題の学習リモコンのトラブル解明が進まないのだ。

 ロジアナで見る限り、ちょっと見たところでは、正しいビット配列を指定の時間間隔で出しているように見える(リーダービットなど)。しかし受け側の赤外線リモコンボリュームは全く反応しない。手持ちの市販リモコン送信機では苦も無く反応するのに、どうにも気分が悪い。

Ws000006 このリモコンボリュームは、Tiny2313を使っているので、SRAMが128バイトしかない。必要なデータを表示しようと思うと、すぐスタックがオーバフローし、リセットされてしまう。こいつのデバッグをしていると何かとても無駄なことをやっているような気がして気分が盛り上がらない。

 別のテストベンチを作るか、記録するデータを長さのデータではなく、一度デコードする方式に換えれば、先に進むのだろうが、これらを変えるのは、すべてかなりの手間(恐らく今のTiny861では無理)になるので、さらにやる気が起こらない。

 暫く放(ほう)ってあったが、このまま立ち枯れ状態になっているのも始末が悪い。とにかく、このテーマからは撤退することにした。ロジアナのプローブを片付けて机を整理する。テストのため、いじっておかしくなった(時々止まる)リモコン電子ボリュームの復帰から始める。

Dsc00525

 現在この電子ボリュームは使っていないとはいえ、元通りにはしておきたい。ソースに入れたテストステートメントをすべて抜き出して再コンパイルする。暴走はしなくなった。しかしこのボリュームの売りである電源を切る前のボリュームの位置を再現しなくなった。

 このしかけは、リセットICを使って、電源が切れる寸前に制御信号を入れ、EEPROMにその時の音量レベルを記録することで実現している。ソースコードを調べているうちに、リセットICの制御ピンとUART受信ピンが被っていることを発見した。テストのためのUART受信を生かしたままになっていた。

 やれやれ年は取るものではない。これまでのソースやブログの記事に明記していなかったので、このことをすっかり忘れていた。UART受信を無効にし、これで電子ボリュームは完全復活した。組み立てなおして所定のオーディオラックの位置に戻す。

アームクローラーの玩具を買ってみる(8/10/2016)
 simさんのブログに載っていた、キャタピラーが2重になった不整地走行可能なアームクローラーの玩具が急に欲しくなり、いつのまにかアマゾンの購入サイトでボタンを押してしまっていた。

 何かの当てがあるわけでもない。どれくらいの不整地まで踏破できるのか試してみたくなったような気がするが、これは衝動買いを正当化する言い訳で、要するに気分が乗っただけである。電子工作も本来はこういう「ときめき」から始めるべきで、無理にやるのは無駄が多い。自戒である。

 キットは、単に直進するだけの機能で価格は¥2000しない。しかし¥2000以下だと送料がかかる。良くしたもので、2モーターのリモコン対応の部品をつけると送料無料の金額になるセット販売の案内がある。躊躇なくこちらを選ぶ。昔はこういうのに抵抗があったが、今は全くない。

Dsc00569 到着したタミヤのプラモデル風のクローラーの組み立てに熱中する。作りながら、これをこれまでのリモコン用の機器をどう組み合わせるかあれこれ考える。もうXbeeは良いだろう。ESP8266かIntel Edisonか、それともRaspberry Pi(以下、Raspi)か。

 いずれにしても手を動かしていると、スランプを忘れる。2モーターのモーターアセンブリーも一緒に組み立てる。組み立てたあと、シャフトが違うことに気が付き、もういちどギヤボックスの組み立てをやりなおし。説明書が微妙に不親切だ。

 モーターの配線に2か月振りにハンダごてに火を入れ、雑音抑止のコンデンサーとリードをハンダ付けする。モーターを回してみる。問題なく両方動いた。とりあえずこれでメカの部分は完成である。

IGZOの液晶パネルを買ってしまう(8/18/2016)
  そのうち、オリンピックが始まった。予想外の選手がメダルを獲ったりして、日本が盛り上がっている。いつものようにメディアが金属回収業者のように「メダル、メダル」と叫び、例年このプレッシャーに負ける選手が続出するのだが、今年は続々と表彰台にあがる日本人選手の笑顔が何度も画面に映る。

 吉田沙保里の4連覇は実現しなかった。五輪主将はメダルをとれないというジンクスがあるらしい。しかし銀メダルなら大威張りではないか。若手が台頭してきたのだから先輩は喜ぶべきで、表彰式まで泣きじゃくるのは少々大人げない感じがした(主将なんだから)。

 クローラーの組み立ては終わったが、これをリモコンにするための実装の良いアイデアが浮かばずそのままになっている。そのうち、ウェブをみているうち別のものに関心が移ってしまった。

Dsc00553_2 これもどなたかのブログで、Raspiの液晶パネルの話が出て、以前から気になっていたのだが、急に再燃して欲しくなってしまった。夏休みで10日近く休んでいた事務所に出た帰り、久しぶり(2か月以上)に、秋葉原を訪れる。秋月電子はいつものようにごったがえしていた。

 この盛況を見る限り、電子工作が下火になった感じはしない。Raspi用の液晶パネルは前と同じ、店の前の平積みのカウンターに無造作に積み上げられていた。ついでに500万画素もある専用カメラなども購入。珍しく2万円近い出費である。

IGZOパネルは最初は気難しかった(8/20/2016)
 秋月には、2種類のRaspi用のパネルが売り出されている。ひとつは、純正のタッチパネルがつき、専用のインターフェースにつける、800x480のもの、もうひとつは、SHARP製の、何と1920x1200のパネル。どちらも7インチだが、SHARPのIGZOパネルは、HDMIインターフェースである。Dsc00551

 値段はどちらも1万円を超すが、どちらにするか迷うところだ。結局、汎用性、性能対価格比の優るIGZOを買うことにした。7インチで1920ドットである。フレキケーブルが微妙だというので、専用のスタンドも一緒に購入した(¥2000)。

 帰宅して、液晶パネルを取り出す。まず驚くのがその薄さである。スタンドのアクリル板の保護シートを、傷をつけないよう慎重にはがし、パネルを挟み込む。2枚ある基板を付属の取り付けポストを使って背面のアクリル板に固定する。

Dsc00552_2  ここまでは、それほど難しい作業ではないが、一番難儀したのが、薄紙のように薄いFP(フレキ)ケーブルの接続である。不安定な状態でパネルを持ち、基板側のソケットにケーブルを接続しなければならない。

 特に電源側は、4ピンしかなく、髪のように細い。ブログにも、この4ピンFPケーブルがコネクターに刺さらず泣いたという話が紹介されている(ハッチの上がる方向が逆)。こちらも何回か予行演習をしたあと何とかつながった。

P9057517 しかし、基板とFPケーブルの周りは裸で、このままでは何かの拍子に、ものが当たって、ケーブルが切れる心配が十分ある。色々考えた挙句、コネクター周りにプラスチックのガードを2面つけた。それにしてもこの細かさは尋常ではない。

config.txtはRaspiのBIOSだった(8/21/2016)
 久しぶりにRaspi3に火を入れる。順調にシステムは立ち上がったが、液晶は真っ暗のままだ。電源はシステムが立ち上がる前に入れておかないといけないとか、画面が出ているときに不意に電源を切ると液晶ピクセルが壊れるとか脅されている。えらく気難しい。

 何度か説明書を読み込み、指定通りのconfig.txtをtelnetを使って作ったが、画面は出てこない。config.txtを戻して、これまでのPCのHDMIケーブルを差し替えると、問題なくRaspiのデスクトップが出るので、犯人はこのconfig.txtの設定か、液晶パネルそのものである。

 心配なので、FPケーブルのコネクターの差し込みをやりなおす。念のため、実体顕微鏡を持ち出して、コネクター周りを視認する。大丈夫なようだ。とするとconfig.txtの設定誤りということになる。

 調べてみると、config.txtとは、RaspiのBIOSにあたる部分で、ハードに密着しており、少しでも違うとおかしくなることは十分考えられる。試しに、このパネル用のconfig.txtで立ち上げると既存のPCディスプレイでも真っ暗になる。

 もういちど説明書の、config.txtの記述と、実際のコーディングとの違いを調べ始めた。その結果、2か所も間違っていた。最初の、hdmi_pixel_freq_limit=200000000の0がひとつ多すぎるところと、frame_buffer_height=1200をmaxと同じ1920にしてしまっていた。Dsc00558

 これらを直して、祈る気持ちで再度、raspiの電源を入れる。おーし、液晶パネルのバックライトが明るく点灯し、画面右上隅にアイコンが現れた。とみるまに立ち上げのメッセージが矢のように流れ始める。間もなく、順調にデスクトップが現れた。いやあ小さい、しかし実に鮮明な画像だ。

いやあそれにしても小さい。すごい(8/23/2016)

 IGZOの7インチデイスプレイがやっとのことで動いた。嬉しくて記念撮影をする。HDMIケーブルが大きすぎてパネルが動く。もっと細いケーブルを買ってこなくては。マウスポインターは糸くずのように微小で、文字は殆ど読むことが出来ない。残念ながら画像や動画ビュワー以外の実用性には欠けるようだ。Dsc00555

 アマゾンでHDMIのスリムケーブルを入手した。届いたケーブルを見て吃驚(びっくり)する。こんな細いので大丈夫? 無事つながることを確認した。面白いので以前使っていたケーブルと比較写真。これまでのケーブルではケーブルを動かすと本体が動いた。

 デスクトップ画面の実用化のため、画面拡大の方法を模索する。調べた結果、Ubuntuにkmagという画面拡大のアプリがあり、これが一番使いやすそうである。しかし、raspiのOSは同じdebian系統だが、ubuntuではない。ウェブを調べたが、確証はとれない。

Dsc00566  だめもとで、試しにraspiで apt-get install kmagをやってみたら、感心にもインストールを始めた。無事、エラーもなくインストールされたので、勢いでkmagをターミナル端末から直接入力した。なんと、無事にubuntuのkmagがraspberryPiでも動いた。

 今のところ、kmagを立ち上げるところだけが細かいが、そのあとはそう苦労せずにターミナルからのコマンド投入が行えるようになった。少しは実用に近づいたかもしれない。

MP4212の回路に大きな誤解があった。モータードライバーを作る(8/15/2016)
 ウェブで刺激されて買った、キャタピラーが2重になって荒れ地を走行できるクローラーの玩具の話に戻る。モーターが動くところまでで止まってて、次はこれを何でドライブするかである。モータードライバーは、MP4212にしようと思っている。

 世間には数限りないモータードライバーが売られているが、へそ曲がりの所長としては、出来合いのモータードライバーを使うのには抵抗がある。どうせなら、裸に近い形から作りたい。といっても「へたれ」なので、単体のFETやパワーTRから組みこむのは疲れる。

 そこで、MP4212だ。このFETモジュールICはとうに生産停止になっているが、まだ在庫があるようで、入手性はそう悪くない(千石やサトー電気で買える¥300程度)。モーターの正逆転回路、HブリッジをひとつのICで実現できるようコンプリメンタリーなFET(N-MOSとP-MOS)が2つづつ入っている。

 このFETモジュールは、以前、自作サーボモーターの時使って、回路図まで公開している。しかし、今度のクローラーで調べているうち、もっと安全で簡便な回路があることがわかった。前の回路は、間違っているわけではないが、使い方によっては、ICを燃やす危険がある。

 前の回路は、正転と逆転のそれぞれの制御信号があるが、これを両方Highにすれば、貫通電流が流れる危険があるのだ。ソフトでそうならない保証はない。今度見つけた回路は、正転、逆転の2つの制御信号が同時にHighになっても、モーター部が短絡するだけで(ブレーキがかかる)、電源側は短絡しない。しかも前は必要だったドライバーのトランジスターが不要である。

 この回路図をみつけたので、急に自分も作りたくなった。オリジナルは、ドライバーにフォトカプラーを使っているが、同じVccを使うならこれもいらない。ブレッドボードで手早く作り、動くことを確認した。

リアルタイマークロック(DS3231)の月差は1秒以下(8/27/2016)
 クローラー工作の続きで、ESP8266のPWDでモーターを動かそうと、棚に放置していたESP8266を引っ張り出した。このブレッドボードには、I2C機器のテストに使ったRTC(DS3231)が付けたままになっている。Dsc003860002 ヘルスチェックのつもりで通電し、今年の4月1日に接続したままの時計の計測をしてみた。このRTCは以前のブログ記事に、月差が2秒以内と紹介した記憶がある。

 今測れば、4か月、149日間の誤差を測ることになる。シリアルポートを生かし、時計の表示を見る。いやあ、これは驚いた、遅れが3秒以内だ。30.4日を1ヵ月として、3X30.4/149 は、月差で0.61秒である。置いてあったところが地下室で温度の変化が少ない所とはいえ、信じられない精度だ。

いやあひどい目にあった。PC突然死亡。結局、電源不良だった(9/8/2016)
 メインのPCが急に動かなくなって、この4日間、これにかかりきりだった。おかげで遅れたブログのアップがさらに遅れて気の抜けたビールのようになってしまった。

 事件は、突然に起きた。いつものようにPCの起動ボタンを押したが、反応がない。電源コンセントがはずれているのかと確かめたが、何も変わっていない。起動ボタンを押して電源ランプが一瞬点くが、すぐに消えてしまうことがわかった。CPUのファンさえ回らない。

 思い当たることは何もない。突然、メインのPCが動かなくなってしばし呆然となる。あちこちいじっているうち、BIOSの画面までは出るようになった。どうもACプラグの差し込みがゆるかったかのような感じである。しかし、Windowsの立ち上げが始まると必ず途中で電源が切れる。

一旦切れたあとは、リセットボタンも、起動ボタンの押下の反応もなくなるので、最初はてっきりマザーボードが、ご臨終になったものだと考えた(これが重大な誤りだったことはあとでわかったのだが、この時点ではマザーだとばかり思っていた)。

 マザーのトラブルは交換するしかない。あわてて、サブのノートPCを使ってウェブで、ASUSの同じ機種のマザーを探す。5年以上も前のマシンなので、もうCPUのチップセットLG755の新品は売っていない。中古のこのマザーの後継機種らしいものを見つけて注文した。

 3日で届いた。いや助かった。すぐ組み立てにとりかかる。久しぶりの自作パソコンの工作である。いくつか切り傷を作りながら(安物のケースは特に危険)、これまでのマザーを取り外し、届いたマザーに組み替える。最初、メモリーだけ積み替えて苦笑い。CPUを忘れていた。

 さあ、組みあがった。電源を入れる。何と、何と、前と同じ症状で、電源が途中で切れた。うはあ、これは大変だ。これはマザーではなく、電源不良の可能性が高い。リセットボタンが効かなかったのでマザーとばかり思っていたが、ウェブによるとこれは電源不良の特徴なのだそうだ。

 時間が惜しいので、直接、秋葉に買いに行くことにした。車を飛ばし、近くのコインパークに車を止め、パソコンショップをはしごする。いわゆるDOS/V通りは、以前と様変わりしてパソコンショップはもう数えるほどしかなかった。

 昔懐かしいTwoTopがまだやっていたので、ここで適当なATX電源(玄人志向の500W)を買い込んで自宅へトンボ帰りする。電源の交換は、マザーほど大変ではない。組み替えて、本当に祈る気持ちで起動ボタンを押す。おお、動いた。OSの立ち上げまで行った。

 しかし、立ち上げの途中で突然電源が切れることを何度も繰り返したため、Windows10は、再起不能の状態で、システムの再構成を要求してきた。仕方がない。それに従うことにする。1時間近くかかって再構成は終了した。電源が切れることはなくなったが、システムの中身は散々な状態になっていた。

 ほとんどのアプリケーションが削除されてしまっている。このあと何とかWordなどを再インストールして、このブログを書ける状態までになった。それでも数多くのアプリが死んだままだ。とりあえず今の状況を報告して、今回の記事を終わることとする。

| | コメント (2) | トラックバック (0)

2016年7月21日 (木)

赤外線学習リモコンはデータ再現で挫折したまま進まず

 キャプチャーした赤外線のデータ列をロジアナで確認し、学習リモコンの工作は峠を越したと考えたのは甘かった。あれ以来すっかり電子工作への意欲が湧かなくなって、気が付けばもう2か月近くが経とうとしている。

 深刻なスランプである。何とか先に進めようと、作業の前にこれからの作業項目をメモに列挙し、気力を奮い立たせてPCに向かう。開発環境を立ち上げ、メモの手順に従って開発する。

Dsc00524

 これまでなら、一旦作業が流れに乗ると自然に手が先に進んでいくものなのだが、最近は少し結果が出ると、何故かそれ以上のやる気を失い、ほかのことに気をとられてしまう。これが愚にもつかないゲームや、ウェブサーフィンだったりする。困ったものだ。

 責任を転嫁する気持ちは毛頭ないが、どうも最近は電子工作そのものも前に比べると盛り上がりに欠けているように感じる。所長が始めた8年前は、活発な活動をしている掲示板やブログサイトが沢山あって、大いに参考にさせてもらったものだ。

 ところが、現在はみな低調で閑古鳥が鳴いている掲示板が多い。電子工作関連の雑誌も、以前はFPGAや32ビットCPUの基板が盛んに付録につけられて、みんなでわくわくしながら動かしていたものだが、最近はこういう話も聞かない。

 実は、所長の電子工作が低調なのは理由があって、5月の末、体調を崩し病院通いをしていたせいもある。工作をする気持ちのゆとりがなく、一時は、狭心症の疑いまでかけられたのだが、幸い誤診だったようで、今は全く症状はない。

 この話はあとですることにして、趣味の電子工作全体が低調な原因には思い当たる節がある。個人的で一方的な仮説にすぎないが、この低調さは最近のArduinoの普及と大きな関わりがあるように思える。

Arduinoの功罪
 商売の邪魔をする気は全然ないのだが、Arduinoで電子工作の世界は大きく変わった。しかし反面、つまらなくなった。まずメリットの方はご存知のように次のようなものだ。

ハードウエアのI/Oインターフェースが統一されているので、初心者は、面倒なI/Oピンの初期化に気を遣わないですむ。誤配線や誤設定をする恐れが少ない。最近は機種を超えて共通なのでハードウエア設定はさらに楽になり失敗はほとんどなくなった。

各種のペリフェラル(UARTやI2C、SPI)の設定も、スケッチライブラリーが全部用意されているので、プログラムを書くのが大変楽になった。ほぼデータの中身だけを心配すればよい。

各種のシールド(増設するディバイス)とそのライブラリーが用意されているので、簡単に高度な機能を実現できる。

 経費的には、はるかに高額になったとはいえ、便利になったことは間違いない。所長もESP8266では大いに恩恵を受けた。その反面、この道はあらゆるテクノロジーの世界がこれまでに経験したことと全く同じ道である。

Ws000003

 便利になればなるほど、細部を知らないでも先に進めるので、技術を身につける機会を奪ってしまう。つまり情報が隠蔽化され、ブラックボックスになっていけば、必然として次の弊害が起きる。

組み立てて、それで動けば問題ないが、一旦、動かないとなると、どこから手を付けて良いのか全く見当がつかなくなる。故障や、ちょっとした不具合にも対応することが出来ない。

作った製品の改善や、改良は殆ど出来ない。製品の応用もできなくなる。いわゆる技術力は身につかない。

それでもこうした複雑になったしかけを短時間に理解し、その応用ができる技術者は一部に存在する。しかし以前にも増してその数は限られる。これにより技術者間の格差はさらに広がる。大多数の一般の人は作って動かしただけで終わってしまう。

 最近の電化製品は、一旦故障が起きると一般の電気店では殆ど修理不能で、自動車もそうだ。ボンネットの中は完全なブラックボックスで点火プラグひとつ素人が交換できない。その製品を使うことが目的ならそれでも良いが、電子工作というのは作る過程を楽しむ趣味でもある。

 従って、電子工作にすぐ飽きる人が増える。ちょっと見は楽そうなので一時的に参入者は増えるかもしれない。しかし長い目で見ていると、参加人口はどんどん減っていくという寸法である。これまで繰り返されてきた、知らずに自分で自分の首を絞めているという業界の悲劇がここでも起きているように思う。

サードオピニオンまで聞いて何とか安心(6/23/2016)
 それはさておき所長の病気の話である。ある朝、コーヒーを淹れようとミネラルウオーターの2リッターペットボトルを持って機嫌よく階段を上がっているとき、突然、息切れがして胸が苦しくなりその場に座り込んだ。息切れは間もなく解消したが動悸がおさまらず、その後はちょっとした運動をするだけで、すぐ息切れがする。

 近くの医院で心電図や血液検査をしてもらうが、特に異常はない。最初は熱中症だと言われた。しかし気温が30 度以下の室内では考えにくい。頻脈は心理的なことでも起きるというので最初にもらった薬は何と精神安定剤だった。

 数日経って息切れはだいぶ良くなったとはいえ、洗車をしただけで息が上がる。近所の医院の医者は大病院で精密検査をすることを勧めてくれた。最初に行った大病院では、心臓エコーなどの検査を受けた。しかし、ここでも特に異常なしと言われる。症状は殆ど改善していたが、原因がわからないのは不安だ。

 さらにまた別の大病院に行く。ここの医者は症状を聞いて、「これは狭心症しか考えられない」と宣言する。なんだ、やっぱり狭心症なのか、そういえば血液が高脂質だと注意されている。ニトロ舌下錠までもらって覚悟を決める。ただ念のため、造影剤を使った心臓CTスキャンを撮ることになった。

 近くの医者に報告する。「すっかり病人にされちゃったのね」と笑う。このとき、こちらは狭心症を見抜けなかったこれまで2人の医者は藪(やぶ)だと思っていたので内心は穏やかではない。

 心臓CTスキャンの結果が出た。見せられた自分の心臓の血管はプラモデルでつくったようにつるつるで動脈硬化のかけらもなかった。医者はあっさり狭心症の見立てを取り下げた。で、同じときに撮ったCTスキャンの肺臓にいくつか血栓のあとがみられるので、肺塞栓症、そう、いま流行のエコノミークラス症候群だろうということに落ち着いた。

 そうか、前の2人の医者は藪ではなかったのだ。医者の見立てというのは恐ろしい。CTスキャンがなければ、ずっと狭心症の薬を飲まされているところだった。1週間飲んでいた薬が、動脈から静脈に急に変わって、薬局の薬剤師が笑っていた。

 とはいえ狭心症より、肺塞栓症の方が始末が悪い。血栓が出来る要因がはっきりしないからだ(2月に海外旅行にでかけているが3か月も前の話)。ただ一過性なので今は全く問題ないというのが有り難い。それに心臓が思ったよりきれいだったので安心している。

2年ぶりの小学校の同窓会。今度は世界遺産の宇治上神社と平等院(5/20/2016)
 さらに、電子工作とは関係ない話題をもうひとつ。実は前記事をアップする直前、例の、京都の小学校の同窓会が2年ぶりに宇治で行われたので行ってきた。そのときの写真を少しご紹介しておこう。

Dsc004520001

 宇治は硬貨の裏にも彫刻され、世界遺産にもなっている平等院の鳳凰堂が有名だが、実は、それ以外にも世界遺産に指定されているところがある。それが、平等院の川向うの北東に位置する、宇治上(うじがみ)神社である(京都のお寺や神社がすべて世界遺産ということではなく、全部で17か所)。

 所長も行ったことがない。同窓会をその近くで行うというので、また日帰りで京都へ行ってきた。同窓会の前に、その神社に行ったのだが、何の変哲もない神社で完全に足をすくわれた(これは予想した通りでもあったが)。

Dsc004530002

 世界遺産に指定された理由は、国宝となっている日本で一番古い神社の本殿が残っていることらしい。しかし別に驚くような建物でもない。これだけで他には何にもない。実にあっけない世界遺産だった。まあ観光客が殆ど来ていなくて、のんびりと散策できたことは収穫だった。

 今度の同窓会は、この世界遺産と、遠方から珍しい同級生(何十年ぶり)が来るというのに釣られて来たのだが、まさに60年ぶりに会った同級生は、頭が薄くなっていたが、話をしているうちに完全に小学校時代の面影が再現し、とても感動した(相手があまり自分のことを覚えていなくて少し残念だったが)。

Dsc004570006

正しいサブキャリア―周波数を作る(6/2/2016)
 電子工作の話に戻ろう。工作そのものは、前回記事のあと少しやっただけで、その後は殆ど進展していない。もともとは、無線WiFiモジュールのESP8266で学習する赤外線リモコン遠隔制御装置を、それこそArduinoで作るつもりだった。

 ウェブにはいくつかのソースコード(スケッチ)が公開されている。ここここのソースを拝借すれば恐らく問題なく動くのだろうが、それだけでは何となく面白くない。赤外線リモコンは応用範囲が広いので、ハードなどの技術をマスターしておきたい。そこであえてマイコンのAVRで基本的なところから作りこんだ。それが、深みにはまっている。

 赤外線の学習リモコンというのは、既存の赤外線リモコンの送信データを、受信してそっくり記録し、あらためて必要に応じて、その赤外線データを送信するもので、前回のブログ記事の通り、データ受信と記録の機能は、Tiny861を使って(最初Tiny441で失敗)、開発に成功している。

 次は送信部である。赤外線のデータ規格はさまざまな種類があるので、汎用的にするため、ここでデコードすることはやめ、忠実にその長さに基づいて赤外線を発信する方法をとることにする。エラー率は高くなるが、とりあえずはこれに挑戦する。

 送信用の赤外線LEDはこれまで使ったことがない。まずはミニブレッドボードに、送信用赤外線LEDとFET(2SJ377)をつけて、赤外線LEDがon/offできるか確かめる。確認のため普通の発光LEDを並列につける。問題なく動いた。制限抵抗が300Ω程度でも1m位は受信するようだ。

Dsc00527

 次はソフトウエアである。これまでの受信部とこの送信部を少し大きめのブレッドボードに統合したあと、送信側のロジックを開発する。キャリアーパルスはPWMでなく、通常のGPIOをタイマーで駆動して、duty比1/3のサブキャリアーを作った。

 割り込みルーチンにこれを組み込み、ON/OFFはメインループのフラグで行う。タイマー割り込みはサブキャリアーの2倍(on/off)のタイミング13μsで発生させる。メインループのON/OFFは、最少でも500~600μs単位なのでこれで十分動くはずだ。

 動かしてみる。オシロでサブキャリアーの周波数を測定する。うーむ、30Khzを下回っている(およそ28Khz)ので受信モジュールが正しく動かない可能性がある(仕様上は30~38Khz)。

 遅れる原因をチャートを書いて調べる。キャリアーパルスの遅れは、タイマー割り込みが起きて割り込みルーチンに来るときの時間(オーバーヘッド)だけが問題で、割り込みルーチンの中の処理は関係しない。実測してみるとこのオーバーヘッドは、8Mhzのクロックで4μs内外のようだ。

 それを加味して、タイマーの時間を調整する。しかし、どうも計算通りにならない。思い切って値を減らす。対症療法だが、これでやっとサブキャリア―が30Khzを超えた。まずはこんなもので良いだろう。

送受信の分離にてまどる(6/8/2016)
 受信で得たパルスデータの配列(立ち上がりと立下りの間の時間1バイト)から赤外線パルスを作るのは簡単だ。送信の指示があれば配列をループに入れ、先頭から配列データに入っている待ち時間を計算してウエイトし、データの最後まで送信LEDのスイッチをon/off(exclusive OR)させるだけである。

 しかし、最初はうまくいかなかった。同じCPUに送受信ルーチンを入れ込んであるため、送信赤外線が出始めると、受信側が割り込みを開始して動いてしまう。送信パルスは間隔を単なるループ回数で決めているので、正確な間隔にならなくなる。

 受信側の割り込みを動かないようにすれば良いのだが、これが意外に面倒だった。どうしても、最初のパルス受信を止めることが出来ない。送信パルスの発生は、タイマーの割り込みルーチンで動いているので始終動いており、受信モジュールの割り込みを止めるステートメントの場所が難しいのだ。

Led1

 停止をするステートメントの前後を割り込み禁止にし、ペンディングの割り込みを事前にクリアするステップを追加してやっとのことで、受信を黙らせることに成功した。その後はロジアナで波形を見ながら少しづつ送信波形を記録したデータに近くなるよう調整していく。

 ロジアナがまたも大活躍である。これがなかったら全く手も足もでなかっただろう。ロジアナさまさまである。Tiny861の20ピンが大いに役立った。いくらでもプローブ点を作れる。5本で解析すれば、だいたいのことはわかる。

Dsc00526

 現在の我が家にあるリモコンは5種類以上ある。学習リモコンの最終ターゲットはエアコンだが、このデータ列は長大なので、とりあえずは電子ボリュームに使ったSONY仕様のリモコンを当面のターゲットにして調整する。簡単といっても、こいつもリピートとして同じ信号が必ず5本近く出るので、正確な信号を再現することは結構難しい。

やっとのことで3機種の再生に成功したが、本体が受け取らない(6/22/2016)
 徐々にではあるが、学習赤外線リモコン送信部がそれらしい赤外線データを再生し始めた。SONY仕様の12ビットの信号も、ロジアナで見る限り、10%内外の誤差でデータをだしているようだ。

 リピートの処理はリピートとリピートの間の40msの間隔でタイムアウトをとり、2番目以降のデータを無視することで正しいデータが得られるようになった。エアコンのリモコンに対象を移す。データは多いが、何とか512バイト内(Tiny861のSRAMサイズ)に納まっている。

 いよいよ、当面のターゲット、寝室の最近新しくしたリモコンデータである。おやあ、Tiny861がリセットする。ええー、こいつは512バイト以上なの? 測ってみた(数だけ勘定する)。何と何と、こいつは292イベント(146ビット)もあり、しかも念の入ったことに、10ms程度の休みのあと同じデータが繰り返されていて軽く配列データが512バイトを超えてしまう。

Led2

 仕方がない。リピートのタイムアウトを10msに縮めて最初のデータだけを記録することにする。さらにテストを続ける。今度はデータ列の最後のイベントの割り込みがペンディングになり、これが次のデータ列とみなされて本来のデータが消えてしまうトラブルに悩まされる。これは、割り込みリクエストのクリアをいたるところに入れて回避する。

 悪戦苦闘の結果、3つのリモコンそれぞれで、ほぼ原形通りの波形を出力するようになった(まだ実地テストはやっていない)。こんなに長い間かかるとは当初考えても見なかった。原因は、それぞれのリモコンが持っている、リピート信号を除去するのに手間取ったことが一番大きかった。もうちょっと、プログラムの構造を考え直す必要があるかも知れない。

再生したデータで本体動かず。意欲がわかない。完全なスランプ(7/4/2016)
 体調はすっかり戻った。週2回のジムでも、プールで300mが楽に泳げるようになった。ただ、電子工作への集中力が途切れている。送信部のデータがほぼ想定通り出たので、実機でのテストに入る。対象は、まずは電子ボリュームにしているSONY仕様の一番簡単なリモコンのテストだ。

 オーディオコーナーに設置してある電子ボリュームを工作机に移し、ケースを外してデバッグ用のUARTを取り出す。うまく動けば良いが、動かないときの用心である。苦労して設定し、いよいよテストに入る。

Dsc00525

 だめだ。全く動かない。UARTにすらメッセージが出ない。送信データのデコードがうまく出来ない。一番簡単なSONYフォーマットのデータを受け付けない。たかだか12ビットのデコードが出来ないのだから、100ビット以上あるエアコンのデコードなど思いもよらない。

 何が原因か。赤外線の出力をちゃんと受け取っていることは確認した。出力波形は、入力とほぼ同じになっている。少しづつ違うようだが、誤差は20%もないだろう(600usが500us程度)。ただ、このあたりは10 %以下でないと駄目なのかもしれない。

 こうなると意地になるのが常である。電子ボリュームのソフトをいじって中身のデータを出せるような体制に入る。しかし、この機器のCPUはTiny2313で、SRAMが128バイトしかない。ちょっと詳しいデータを出そうとすると、スタックのオーバーフローで簡単に暴走してしまう。

 このあたりで集中力が切れた。このままでは泥沼である。体制をもういちど見直して最初から仕切り直しをしたほうが結局効率が高そうだ。しかし、電子工作への意欲が落ちているのでなかなか次の一歩が進めず、いたずらに時間が経つばかりである。

Windows10インストールで最初の犠牲者(7/12/2016)

 そんなことで別のことに興味が移ってしまった。Windows10である。今さらの感もあるが、今月末に無償アップグレード期限が切れるというので、渋々入れることにした。Windows7で何とか動いていたMSのFlight Simulator(FS 2004)が心配だが、まあそれはあとで考えることにして、これまでさんざん無視していたWindows10移行のボタンを押す。2時間近くかかった。

 ソフトは大体無事だったが、いくつかのハードがらみのアプリに問題が出た。Epsonのスキャナーは何とか、このサイトの情報で助かる。LAP-Cのロジアナはバージョンアップの情報があったのでうまくいくと思ったが、以前のファイルが残っていて正常に動かすのにてこずった。

 AtmelStudioや、Win95時代の定番のエディターや、ターミナルは無事だった。もちろんChaNさんのAVRSPも問題なし。開発環境はほぼ整った。やれやれ。

 FS2004は遂に動かなくなった。そもそもCD-ROMを入れないと動かないソフトは全滅のようだ(セキュリティの関係らしい)。OSそのものは確かに軽くなった。もっともこれは、Win10とともにメモリを増強したことが原因かも知れない(AtmelStudioがメモリ喰らいで、メモリを2Gから4Gにした)。

 大所が動いて、細かいところのテストに入る。意外なところがダメだった。サンワのUSB BlueToothドングルは、現在ほとんど使っていないが、こいつが動かなくなった。サイトを見るとなんと「Win10はサポートしていない」というではないか。最初の犠牲者だ。

 こいつは、仕事の帰り、ヨドバシに寄ってWin10対応のものを買いなおした。なんと、¥1000少々。気が抜ける価格だ。ウェブ上では、BlueToothの世界も沢山のバージョンがあり、色々な話が渦巻いているようだ。まあ、最近のボードは、このあたりはすべて内蔵だから、ドングルに関心が薄れたのかもしれない。

Dsc00530

 ヨドバシ秋葉原店は、膨大な売り場面積だが、BlueToothのドングルは5種類くらいしか売っていなかった。動かないという苦情が多いせいなのかもしれない。

 ともあれ、Windows10は今のところ順調に稼働している。ブログの紙数も増えてきたようなのでとりあえず活動報告をここで一区切りすることにする。

| | コメント (6) | トラックバック (0)

2016年6月 1日 (水)

落穂ひろいの電子工作(続き)赤外線学習リモコンで遊ぶ

遂にパワーダウンスリープの不具合が解消された(5/8/2016)
 機械式自動巻時計のゼンマイを巻く自動巻機(ややこしい)の不具合の話を前の記事に書いた。結局、原因解明ができず途中であきらめたのだが、記事の最後に「閃いた」というコメントを残しておいた。

 「閃いた」のは以前、似たような状況でAVRのマイコンに、ある機能を組み込んだことを思い出したことである。それは電子ボリュームの赤外線リモコンを作ったとき、パワーダウン時のEEPROM書き込みの誤動作をさけるフューズビットの設定、BOD(Brown Out Detect)機能である。09p6017508 BODとはVccが低電圧になったとき、CPUが誤動作しないよう内部でリセットする機能で、デフォルトでは設定されていない。ウェブ上でこんな記事を見つけたことも、BODが気になるきっかけになった。

 この記事は、スリープから目覚めるときにはBODを設定しておいた方が良いという内容で、直接現在の不具合とは関係ない。ただ今度の不具合は、CPU内部の不可思議な動き(電源断のときの電圧降下の遅さ/速さで症状が違う)に関連がありそうで、何となく臭う。

 こじつければ、電源が切れた後、パワーダウンスリープからVccが徐々に下がっていくとき、何らかの予期しない動きがあって今の状態になると考えれば、Vccが下がると同時にリセットがかかる方が望ましいことには違いない。

 ということで半信半疑だったが、藁をもつかむ思いで、件(くだん)のTiny2313にBODを設定してみることにした。フューズビットを見てみると、現在の状況では未設定である。何の確証もないが、物は試しである。4.3Vでリセットがかかるようにする。

 おおお、何ということだ。これでパワーダウンスリープで電源を抜いても、問題なく初期状態でCPUは動き始めたのである。いつも必ずトラブルが起きていた、ACアダプターのACコード側の抜き差しでも、全く症状は起きない。

 実際に運用してみた。見事、1週間問題なく動いた。やれやれ、何だったのだろう。全く根拠はないが、BOD設定をフューズビットに設定するだけで直ってしまった(その後も、順調に稼働中5/31記)。

すごい、DS3231の月差は1.2秒(5/10/1216)
 久しぶりにWiFiモジュールのESP8266を動かす。最後に触ったのは、I2CリアルタイマークロックRTC(DS3231)の動作テストである。このRTCはバッテリーバックアップがついているので、精度を調べるために大分前に正確な時刻を設定して放置してあった(4/1設定)。

 UARTをつないで、ESP8266に電源を入れる。現状のプログラムはUART上に5秒ごとに時刻を表示するようになっている。スマホや手持ちの電波時計の正確な時刻と見比べる。ふむふむ、なんと、殆ど誤差がない。こいつはすごい。

 このあいだ調べたデータシートのスペックによれば、月差で4秒近辺ということだが、今の時刻は2秒もずれていない。これまでに40数日間動いているのだ。多めだが2秒としてこれを365日12ヶ月で月差を換算すると1.2秒である。大したものである。08p6017503 まあ、最近はGPSが正確な時間をくれるようだが、こんなスタンドアロンのしかも廉価なチップがこの精度なのは偉い。この製品も、以前の超音波距離センサーと同様、オリジナルをコピーした中華製のようだが、こうした電子部品が普及することはアマチュアにとっては有り難いことである。

 長い目で見れば、先行開発にチャレンジする人(や会社)を減らすことになって産業全体では悪い影響を及ぼすのかもしれないが、ジェネリック薬品と同じような位置づけと考えれば、そう心配することもないのではないか(トップメーカーの囲い込みを防げる)と勝手な理屈をこねる。

AitendoでUSBプラグを買い、Tiny24で遊ぶ(5/11/2016)

 AVRのTiny13は安いし小さいので重宝している。しかし使えるI/Oピンとフラッシュサイズが少ないのが難点である。これまでのソフト資産を生かしたまま、ちょっと機能を拡張したくても次の適当な製品がない。

 Tiny85は、USIがつき、フラッシュも大きくなるが、なにせ8ピンなのでI/Oピンの制約は変わらない。といって、Tiny2313や、Tiny861は20ピンで急に大きくなりすぎる。データシートなどを調べると、このあいだには、14ピンの24/44シリーズがあるらしいが、日本の市場には出ていないと思っていた。

 それがAitendoのサイトを見ていたら、SOPのTiny24とTiny44が売られているのを発見した(Tiny24/44にはDIP版がない)。たまたまUSBのAタイプオスコネクター(ジャック)を探していて、いきつけの秋月や千石に気に入ったものがなくて、Aitendoで良さそうなものを見つけたところである。04p5127492

 ちょうど良い機会なので、久しぶりに直営ショップへでかけることにした。ここは秋葉原というより上野に近い。地下鉄日比谷線の仲御徒町の駅から歩いて5分かからない。おやあ、1階に店が見える。始め、全部がここへ移ったのか勘違いしたが、どうも狭すぎる。店員に聞いたら3Fにもあるという(ちょっと日本語が覚束ない女性店員が答えて)、そちらに回る。

 3Fのメインの売り場は前と同じ場所にあった。1Fの店はキット製品だけの売り場らしい。相変わらず結構な客の入りだ。膨大な品数だが、女性店員は的確に陳列場所に案内してくれる。Tiny24/44はすぐ見つかった。2つづつ買う。値段もリーズナブルだ(¥120と¥200)05p5217494

 帰ってきて、早速ブレッドボード上で使えるように、手持ちのSOPの変換基板を取り出したのだが、こいつが、やたらとごつく大きすぎる。長さが700mil(7ピン)なのは仕方がないが、幅は明らかに広すぎる(600mil)。20ピンの2313や、x61より大きく見えるのでは洒落にならない。

 というので、今までのテーマ(学習赤外線ユニット)そっちのけで、自分で変換基板を作り始めた。動きだした手が止まらない。切り出した汎用基板に耐熱絶縁シートを張って、その上に接着剤で表面実装チップを固定し、0.2ミリのUEW線で配線する。

07p5217501  前から憧れていたChaNさんの得意技である。作ってみると意外にしっかりしていて美しい。幅は、100milしか狭くならなかったが、完全な自己満足の世界である。興に乗って2つ(Tiny24と44)も作ってしまった。

赤外線LEDの制御にTiny24とFETを持ち出す(5/15/2016)
 前から考えているテーマはESP8266とスマホを使った赤外線リモコンの遠隔操作である。既成のリモコン信号を学習して、スマホから操作できる。いくつかの作例があり、ソースコードも公開されている。簡単にできそうだ。ESP8266の適当なアプリとして、部品も大分前に揃えてあった。

 しかし、部品を目の前にして、急に気分が変わった。このままブレッドボードに部品を差し、ソースをArduino IDEにコピペして動かすだけでは何か物足りない気がする。赤外線リモコンは、前に受信側は自作したが、送信側はまだ作ったことはない。

 ウェブの情報によれば、何やら送信用の赤外線LEDは、離れたところから動作させるには、1A近い電流量が必要になるらしい。マイコンのI/Oピンの最大電流は数十mAなので、当然なんらかのドライバーが必要になる。

 そういうことも含めて、すべてお仕着せのスペックで作るのが惜しくなった。ちょうどSOPのTiny24がブレッドボードで使えるように変換基板を作ったところだ。赤外線リモコンをこれで作りたくなった。

 赤外線LEDの送信側のハード制作は初めてで、それに慣れておこうという魂胆もある。トランジスターで動かしている例が多いが、ここは久しぶりにFETで制御してみることにした。改めてネットでFETのおさらいをする。1A程度のスイッチングなら手持ちの小さなFET (2SJ327)で十分だ。

 まずFETの点灯テストから始める。念のため、可視光線のLEDを並列につなぐ。受信側はセンサーの出力をオシロで確認する。点灯する。あれえ、反応がない。オシロを良く見ると、小さなパルスは入っている。

 念のため、エアコンや、電子ボリューム用の汎用リモコン(ソニー仕様)などを当ててみる。問題なく連続パルスが出ている。それなのに何故出ない? 暫くして、その理由がわかった。はっはっは、情けない話だが、サブキャリア―(35Khz前後)が必要なことをここで始めて理解した。

 だから「赤外線受信素子」ではなく、「赤外線受信モジュール」なのだ。サブキャリアーを発生させるしかけが必要である。まだ先の話だと思っていたが、あわててTiny24の変換基板をブレッドボードに載せ、35Khzのサブキャリアー発生装置を作り始めた(照れ隠しもある)。

 Tiny24/44のデータシートを改めて子細に眺める。タイマーや、ADコンバーターなどのペリフェラルは、殆どx61に近い装備で2313のようなUARTはついておらず、例のUSIが代わりにある。タイマー割り込みを使って、35Khz 1/3デューティのパルスを作る。

 特に迷うことなく、赤外線のサブキャリアー発生装置が完成した。早速、テストに入る。想定した周波数より少し低いが(30khz)パルスが出た。受信モジュールに向けてみる。問題なくタクトスイッチで入り切りする出力が、受信モジュールの変化と同期した。

 このあたりの赤外線リモコンのフォーマットについては、何といってもChaNさんのサイトが一番わかりやすくておすすめである。ただ、今度の学習リモコンは、各種のリモコンを汎用的に使いたいので、ここでの中身のフォーマットは関係ない。出来るだけ、原波形を忠実に再現することが重要だ。

SRAMが256バイトでは記録できない。いっそのことMega88にするか(5/23/2016)

 次は、赤外線データ列の記録である。赤外線パルス列の受信は、以前電子ボリュームの時に実装しているので、ソースコードをそっくり持ち込み、テストする。あっさり動いた。しかし、エアコンのデータ受信で頓挫した。

 エアコン(三菱)の送信データ列が多すぎて、Tiny24/44では入りきらないのである。配列が溢れて暴走する。データ蓄積を止めて回数だけで調べる。274イベントもあった。Tiny44のSRAMは256バイトでスタックを考えれば到底入らない。

 困った。何とかならないか。EEPROMにしまいながらとか、色々頭を捻ったが、最少で500μs単位で発生する赤外線データの蓄積を、ミリセカンドオーダーの記録装置でやろうということに、そもそも無理がある。

 最終ゴールはESP8266なので、テストベンチに凝るのも本末転倒である。潔く、換装を決意する。SRAMの大きさは、折角換装するなら1Kバイトくらいは欲しい。すると、Mega88あたりか。Tiny861では不足だろう。始め、Megaにするつもりでデータシートを見ていたが、861でもSRAMが512バイトあることを発見した。

 少し、迷ったが、Tinyシリーズの中の移植の方が、Megaシリーズへの移植より楽な気がして、SRAMの量に不安は残ったが、Tiny861に移すことにした(これが、えらいトラブルの元になるとはこの時点では露知らず)。

Tiny861の罠(わな) コンペアマッチとキャプチャー機能が排他的とは(5/25/2016)
 Tiny24/44とTinyx61のタイマーの構成はちょうど逆で、受信の時に使うインプットキャプチャー(邦版データシートでは、捕獲入力)機能は、Tiny24/44のタイマー1から、Tiny861のタイマー0に変わっている。

 それ以外は大きな違いはなく、順調に移植が終わった。コンパイルする。おやあ、インプットキャプチャーしたときの値を収容するICR0(Tiny24/44ではICR1)レジスターがヘッダーファイルにないので未定義エラーになる。

 何かおかしい。それと、通信のタイムアウト用に設定したタイマー0のコンペアマッチの割り込みルーチンが動いていないようだ。UARTで設定したOCR0Aレジスターの値を表示させてみると、0になっている(未定義エラーはとりあえずコメント化して回避)。

 暫く頭を抱えていた。データシートがどうも不審なのである。日本語版では、ICR0レジスターが存在するかのような説明(本項では捕獲入力レジスタはICR0と呼ばれますが、これは比較レジスタへの参照です)があるが、これでは何のことかわからない。

 念のため原文を引くと、Even though the Input Capture register is called ICR0 in this section, it is refering to the Output Compare Register(s).
で、どうもコンペアマッチレジスターが実体で、捕獲入力のレジスターは仮想的な感じだ。

 さらに、データシートを調べていって、決定的な表を見つけた。

表11-2. 動作種別(ページ48)

番号 ICEN0 TCW0 CTC0     動作種別 TOP値 OCR0x更新時 TOV0設定時
--------------------------------------------------------------
0    0   0    0  標準8ビット動作             $FF    即時  MAX($FF)
1      0       0        1    8ビット比較一致
                             タイマ/カウンタ解除(CTC)動作  OCR0A  即時   MAX($FF)
2       0      1        x    16ビット動作                    $FFFF    即時   MAX($FFFF)
3       1      0        x     8ビット捕獲入力動作        $FF       即時   MAX($FF)
4       1      1        x    16ビット捕獲入力動作        $FFFF   即時   MAX($FFFF)

 なんのことはない。これではっきりした。動作種別があって、もともとTinyx61のタイマー0は、インプットキャプチャーか、コンペアマッチにしかならないのだ。Tinyx61はTiny24/44に較べると古い設計のようで、インプットキャプチャー機能が独立していない。

 まあ、データシートを読み込まなかった自分が悪いのだけれど、何とも後味の悪い解決だ。データシートにちゃんと書いていない。OCR0Aレジスターは、インプットキャプチャーをenableにすると、コンペアマッチレジスターにならないのだ。

 いかにも両方出来るように書いてある。しかも、インプットキャプチャーのレジスター定義(ICR0)がデータシートにあるのに、ヘッダーファイルにない。混乱する。捕獲入力の値はOCR0AとOCR0Bレジスターに16ビット分が、TCNT0LとTCNT0Hから移されるというのオチである。

 インプットキャプチャーとコンペアマッチ機能は排他的だと、ひとこと書いてくれれば、何もここまで迷うことはなかったのにと八つ当たりである。いずれにしても、データシートのとおり、OCR0Aなどを使って、初期の目的は、Tiny861でもやっと実現した。274イベントのエアコン波形もめでたく記録された。

ロジアナの波形を頼りにプログラムの改修。至福の時(5/28/2016)
 めでたく全部のデータが記録されたので、中身の検証に入る。ここからは、オシロやUARTでは無理で、ロジアナの登板である。赤外線受信モジュールのふるまいは、正確にロジアナで捉えられている。

 それに加えて、マイコン内の割り込みルーチンや、データの処理部分にプローブ(GPIOピン)を設定し、調べ始める。20ピンのTiny861なので気楽に設定できる。

 うーむ、採集された値は、だいぶ原データと違う値だ。受信モジュールの割り込みから、本来のデータ収集をする時点がばらばらなので。誤差が大きい。これは、割り込み時点ではフラグをだすだけで処理をメインに持ってきているので、そのあいだに別の割り込みが入ったりして違ってくるのだろう。この方式では駄目だ。Ws000007

 これはやっぱり、割り込みルーチンの中で処理を全部済ませる必要がある。どうせなのでソースコードをつらつら眺め、コードの短縮化を図る。元のプログラムは律儀にピン(キャプチャーピン)の状態を忠実に調べてから、割り込みの区別(立下りか、立ち上がり)を換えているが、考えてみれば、これは必要ない(単にスイッチするだけで良い)。

 さらに、赤外線データのひとかたまりのデータの最初とそれ以降を区別するフラグを設けていたが、これも考えてみればいらない。最初につかんだデータは使わなければ良いだけだ。ただ、これによりタイムアウトだけが最後まで解決できなかった。データを受信したという印がなければタイムアウトを起こせない。 結局、このデータが来始めたことを知らせるフラグを復活させ、「データが来始めてタイムアウトするときだけ」真のタイムアウトとし、他のタイムアウトは無視するという逆転の発想で解決した。Ws000006

 こうして、割り込みプログラムの誤差はどんどん小さくなり、最終的には、当初200μs以上誤差のあったキャプチャーは、すべての遅れを5μsまで下げることが出来た。これは痛快だった。Arduinoを使っている限りでは、味わえない醍醐味である(シールドの設計者が独占している)。

 ロジアナの画面に、綺麗に揃ったパルス列を並べて至福の時を過ごす。UARTのデータもきっちり5%以下のAnalyz_remocon誤差で記録されている(0.33~0.31の範囲なので、2/32 = 6.25%)。あとは、この値に基づいて赤外線LEDを制御するだけである。紙数が増えてきたので、このあたりで報告しておこう。

Ws000004_2

 

| | コメント (0) | トラックバック (0)

«落穂ひろいの電子工作とRaspiの自動電源制御装置の改良