はい、高齢化の影響はあきれるくらい正直で、記憶力の減退はもう笑ってしまうくらい。特にひどいのが人の名前です。しかし記憶というのは
不思議なもので、思い出せなくても時間を暫く置くと、何の問題なく出てくるのが不思議と言えば、不思議。まあ、高齢化をこんな形で楽しむほか
ありません。

というのも、病気らしい病気はしたことがない、俺は強運の持ち主だと少し思い上がった年賀状をだしていた「ばち」があたって昨年の秋、
肺がんが見つかり、２回の入院を含む抗がん剤治療を受ける羽目になりました。驚いたのは、同年代の友人に打ち明けたら、なんと５～６人
のうち半数以上が抗がん剤治療を受けており誰も驚いてくれなかったことです。

幸い、治療の効果があって、今は１ヵ月に一回の点滴にまで回復が進んでいます。いつまでこんなことが続けられるのかわかりませんが、とりあえずの結論としては、延命をはかって様子を見るという姑息な形となりました。

私にとってトランプ大統領に唯一期待するのは、ケネディ事件の捜査記録の解禁を、2039年よりもっと早くしようと
していることで、私の生きている間に、世界の謎のひとつが明らかになると嬉しいです。

それではまた。

残念ながら、せっかくの機材を十分に活用できる活動が見つからないまま、時代はどんどん私を追い越して行き、おそらく
もうこれまでの電子工作を再開するのは不可能だとは思われますが、まあ、人生何が起きるか全く予測がつきません。

日本人に民主主義を教えてくれたはずのアメリカという国が、国会議事堂に暴徒の乱入をそそのかした男を大統領に
選ぶくらいだから世の中もう何が起きても驚きません。このブログも何かのために役立つかと思い、せこく生存を図る
ことに致しました。

最近、嬉しかったことをひとつご紹介してこの記事を締めたいと思います。昨秋、９３才という長寿で兄が
亡くなったのですが、式に参集した何人かの甥たちが私の生家に残した、無線操縦のエンジン模型飛行機や、
1メートルを超える模型ヨットのことを覚えてくれていて感動したことです。

その模型は、家を取り壊すときにすべて一緒にスクラップになりましたが、このブログもたまに問い合わせを
受けたりすることもありますので、そんな形でも残っていけばささやかな喜びです。

それでは、みなさままた一年後にでも。

例によって、1年に一回記事を書いて、このブログの延命を図っております。

だいぶん書きたいことも溜まっているのですが、こういうときに限って、時間に

迫られており（Zoomの待ち合わせ時間）、ちょっとこれで失礼いたします。

いずれ近いうちに記事を追加いたします。

まとまらないので、今回はこのブログ存続の証明をするだけとします。

　最近はチャットGPTなどソフトウエアでのブレークスルーが話題になることが多く、電子工作などハードウエアでの目立った動きが少ないようですが、何か「制作ごころ」が刺激されるものがあらわれて、こうしたブログを書くようなことが現れることを祈って、もう少し粘ってみたいと思います。

　使ったDASDはPCのディスクをSSD（半導体DASD）にしたときに余ったもので、アマゾンで買ったUSBアダプターにつないで、当初は動いていた。しかしそのうちエラーが頻発し始め、何度もDASDの初期化をやらされた。DASDそのものは壊れていない。

　DASDの電源は、TVが稼働中の時だけ入るように、以前使っていたパソコン連動テーブルタップを使っており、これの誤動作の可能性が高かったのだが、TVでの録画にそれほど大きなニーズがなかったため、そのままになっている。せっかくなので、この原因究明をやることにした。

いじり防止のナットで締めてあって分解できない(1/30/2021)
　TV棚の裏から、件のパソコン連動テーブルタップを取り出した。このタップはPCへの差し込みプラグが甘くて、足で触ると瞬断が発生し、PCがおかしくなったために取り替えたものである。触らなければ症状が出なかったので、TVに持ち込んでいた。

　しかし動かしてみると、全く動かない。完全に壊れてしまっているようだ。修理するか、連動部分を自作するか、とりあえず分解してみようとタップを裏返した。おやあ、締めてあるビスが通常のビスではない。座金が6角形の、いじり、いたずら対策のための特殊ネジになっている。

　こういうのを見ると目的はともかく、猛然と分解したくなるのが、物心ついて以来の所長の気質である。この種のネジ（トルクスネジ）については昔、Appleのコンピューターを分解するときに使った経験があり、いくつかドライバーも備えてある。工具箱を探る。おお、あった、あった。

　早速、このサンワサプライのテーブルタップのネジに当ててみた。残念、この手持ちのドライバーでは開かない全く別のものであることがわかった。6角形の溝の空き方が完全に逆だ。わからないときのGoogle頼みである。早速調べてみる。

　いやいや、昔に比べれば特殊ネジには沢山の種類があることがわかった。一番ポピュラーなのは、所長も一式持っているトルクスドライバーである。連動タップの特殊ネジは良くみるとオスメスが逆転している。Eタイプと呼ばれているようだ。

　ネットのおかげで、こういう買い物には全く苦労しなくなった。定番のアマゾンで簡単に品物が見つかり発注する。念のため3本買ったが、全部で￥3000程度。工具として残るので高い買い物とは感じない。

　しかし何となく納得がいかない。まだ何か少し違うような気がする。さらに検索を続ける。すると、このサイトに詳しい「ラインヘッドネジLH」タイプのような気がしてきた。電子部品やファミコンなどに良く使われているという。

　そうだ、これに違いない。アマゾンに発注していたトルクスドライバーEタイプの注文を慌てて取り消し、こちらにする。あとは工具の到着を待つのみである。

無事空いた。思ったより丁寧なつくり(2/2/21)
　工具が届いた。いそいそと梱包をあけ、早速、テーブルタップのネジ穴ににドライバーを当てる。おお、ぴったりかみあう。簡単に4つの止めねじが開いた。このドライバーは恐らくもうこれ以上は殆ど使わないだろうし、これだけに￥1000以上かけたのも馬鹿々々しい限りだが、なぜか素直に嬉しい。　パソコンで電源を連動させる基板は、タップの右端に、幅5センチ長さ4センチばかりの小さな基板である。特に一部が焼けたところもなく正常なように見える。基板の裏にはリレーも見える。この基板を使う気は今のところないので詳細に調べなかったが次のようなことがわかった。

• 制御機器の電源：    100VACを何らかの抵抗かコンデンサーで降圧している。トランスやスイッチング素子はない。いわゆるトランスレス電源だ。素人がいじるのは結構難しい。
• AC電源のon/off：　 基板についた超小型の24V DCリレーで15Aを制御している。
• 動作の検知：　       シャント抵抗(R020 FS62と刻印、２つ直列)間の電位差をオペアンプ(LM358)で増幅してマイコンのコンパレーターか何かで比較しているようだ。
• 制御IC:　           　8ビットマイコンだと思うが、刻印(C101)からは検索できず。このほか、HT241というレギュレーターっぽいICや、ブリッジダイオードらしいICが実装されているが詳細は不明。

思ったより、まじめに作ってあって感心する。

　さて、修復である。100VACとの直接接続はやはり避けたい。となると電源はUSB用の絶縁5VACアダプターなどの流用が必要だ。電流のセンスはC/Tセンサーが魅力的だが、２つともこのスペースには入らないだろう。このタップのスペースに作りこむことは諦める。

本来の目的に戻って簡便なUSB利用のタップにする(2/5/21)
　考えてみたら、もともとはTVに外付けするDASDの電源制御だ。必ずしも電流のセンスは必要ではない。都合の良いことに最近のTVは必ずUSBポートがついていて、電源を切ればマスタースイッチが入っていても切れてくれる（検証済み）。

　以前に作ったUSBによる電源制御アダプターをもう一度作ることにした。SSRや、ACインレット、基板用のUSBコネクターDIP化キットなど手持ちは十分にある。ケースは昔、可愛いので用もないのに買ってあったタカチの小さめの金属ケース（MB-1）がお手ごろだ。

　何年ぶりかのケース加工である。ミニサーキュラソー（丸鋸）を取り出して汎用基板をケースに入れる作業を始める。何事もなく縦横数ミリづつの基板カットに成功した。次はコッピングソー（糸鋸盤）を使ってアルミケースに電源インレットなどの大きな穴を開ける工程である。

　コッピングソーの出番は、4～5年前のRaspberryPiのライブカメラ制作以来で、何かわくわくする。しかし、機械を作業棚の奥からとりだして埃を払い設置して見て、すぐ使えないことがわかった。

　コッピングソーは作業面が平面でないとできないのだ。成形されているケースの一部に糸鋸を使うことは不可能である。据え付けるまでわからなかったとは、いかに作業から遠のいていたかを物語る。

　しかたがないので、今度はドリルスタンドを持ち出し、昔ながらの方法、3ミリ程度の穴を連続して空ける方法に切り替える。ははは、こっちの方がもっと簡単だった。この方法は、中学生時代の真空管ラジオのアルミシャーシー加工以来の手法で、ノウハウが蓄積されている。

判断ミスが多い。3回も部品をとりはずすも完成(2/10/21)
　ハンダ付けが楽しい。しかし、ちょっとケースが小さすぎて実装に苦労する。ほぼ1年半ぶりのハンダ付けだが、裸視ではもう汎用基板でも難しい。Aitendoで買った高画質映像の拡大鏡が頼りだ。ただ、この拡大鏡のレンズは焦点深度が浅く全体的に視るのは、ホーザンの立体顕微鏡の方が優るようだ。（面倒なので出していない）

　それより、参ったのが、部品の取り付け時のつけ間違いである。事前にサインペンで印をつけて間違いようがないはずなのだが、実際につけてみると、何故かひとつずれている。今回の基板は小さいので1つピッチがずれただけで他の部品が入らなくなる。

　汎用基板からの部品とりはずしは、表面実装に比べるとはるかに難しい。両面基板で裏側にハンダが回るとハンダ線でハンダをいくら吸い取ってもなかなかはずせない。位置決めのつもりでハンダの量を出来るだけ少なくしてあってもとれない。部品が半導体のときは特に神経を遣う。

　虎の子のSSRの位置決めを2回も失敗し、泣く泣く例の低温ハンダを使って部品をはずす。結局、それ以外の部品で1回、通算3回も取り付け位置を修正して、やっとのことで小さいケースにつめこんだ。

　それでも、久しぶりの工作である。何となくうきうきする。AC部もターミナルブロックや、ファストン端子などの在庫を活用して、整備性の高いレイアウトを工夫する。うむ、うまく配線できた。暫く出来栄えを鑑賞する。

　配線は秋月電子のキットカタログやデータシートを参照してトランジスターをひとつ使って、念のためUSBインターフェースとSSR一次側を分離した。ここで気になったのがSSRのデータシートに入っているSSR一次側のスイッチングダイオードD1である。

　ここはリレーのような誘導負荷ではなく、フォトカプラーの入力側なのでこうした逆電圧抑止のダイオードは不要のはずだが、秋月のSSRキットにも部品としてスイッチングダイオード(DAN202U)が実装されている。データシートにあるからには、何か目的があるのだろうが、どうも解せない。色々ウェブで探し回ったが答えは得られなかった。

　まあ、ダイオードひとつの話なので、とりあえず組み込んでおいた。テストに入る。うむ、全く問題なくTVの始動とともにDASDの電源が入り、切れると間違いなくDASDの電源も切れた。出来上がったら棚の裏に隠れて見えなくなるのがさびしいが、とりあえずは実用的な工作がひとつ完成した。

　これまでの草稿ファイルを読み直してみて驚いた。最後の記事のあと結構沢山の作業をしていてその記録も残っていたのだ。でも、このあたりは、2019年で何と、おととしの出来事になる。ラグビーのワールドカップの興奮を書き留めた記事もある。しかし、こんなものを今さらここに出しても何の意味もないだろう。

　月日のたつのは早い、というより去年の春から始まったコロナ騒ぎがいかに世界にとっても自分にとっても大きなショックを与えた出来事であったかということを物語る。何しろ昨年は泊りがけの旅行を一度もしていない。毎月行ってきた囲碁の例会や、IT研修の講師仲間の勉強会も殆ど中止、運動不足解消のためのジム通いも休みがちで、この1月の2回目の非常事態宣言前後も欠席が続いている。

　このあいだ後期高齢者の免許更新の認知機能テストで94点だと威張っていたら、今年の年賀状で北海道の知人が「満点」と自慢しているのを見て大笑する。免許をとって60年だと息巻いてもそれこそそれが老化の証拠と言われれば返す言葉もない。ちょうどコロナの謹慎と、ブログ休止の時期が重なったため、どんどん悲観的な考えが中心になって先が暗くなるばかりである。

　とはいえ年が改まって2021年である。恒例により居間に武者凧を飾る。年賀状の数は幸い少し増えた。みなさん引きこもりでやることがなくなったのか。ここのブログのURLを自分の賀状に載せていることもあって、ブログの休止を気遣って下さる人もいる。そろそろ何とかしなければと思っていたところへ、ちょうど自宅のIT環境が変わる出来事があった。ブログを再開する意欲がこれでやっと閾値を超えたようなので、こうしてまとめている。

いや作りも作ったり17年
　再開するにあたって、これまでの記事を少し振り返ってみた。我ながら驚く記事の量である。ちょっと全体を俯瞰してみよう。退職後の暇つぶしの電子工作にはまって実に13年、記事数は285本にのぼる。これらはすべて、このブログ内のサイドページ「記事一覧」で直読可能である。

　作った製品で現役で動いているのは、小さなLEDペンライトから、人感センサーの階段照明、リモートプリンター電源制御、ガイガーカウンターや、リニアPCMオーディオプレイヤーなど10種近くで、いつも電源が入っているか、現用している。

　一方、滅多に動かさないが、動く状況（部品取りされず原型を保っている）なのは、カメラを上下左右に動かせるウェブカメラや、FPGAから組んだフォトフレーム、音量リモコン、Xbeeを使ったリモート電力ロガーなど数十点にのぼる。

　工作が止まったのは、意欲が失せたというより技術の限界で止まっていると考えて良い。ガイガーカウンターは、測定値の校正が簡単に出来ない。ウエブカメラは屋外防水仕様の実現が難しい。リニアPCMプレーヤーは早送り、早戻し機能の実現で挫折した。意気込んでいた心電計プロジェクトは、ロボット制御のための筋電電流検知が目標だったが、資料が少なすぎてあきらめた。

　13年間で大抵のところはやりつくしている。こういう状況ではなかなか再開は難しい。でも、おもわぬところで喜ばれたものもある。市販の有線ロボットアームを改造して無線にした機械は、孫が「ボロット、ボロット」と言って喜んでくれた。

我が家のWiFi環境を新しくする(1/10/21)
　このあいだ友人と話をしていて、「WiFi6（シックス）にした」という話がでて、最初、IPV6のことと聞き違え、恥をかいた。我が家のネット環境は、10年近く前に1GbitのAUひかりにして以来進展はない。

　現用のWiFiルーターは、アクセスポイントとして使っており、　WiFi何とかというなら、WiFi5(802.11acをサポートする)なのだが、何故かiPhoneなどでは、WiFi4である802.11a/gあたりとしかつながらなかった。

　そもそも、WiFiは家族用で、ネットは主にPCの有線LAN経由なのでそのままになっていた。少々大きなファイルのダウンロードも、昔に比べれば信じられないほど速くなっているし、動画再生も特にストレスなく見られ、不自由を感じることはなかった。ところが、このところ支障がでてきた。家族がiPADでオンラインゲームをやっていると回線が切れるというのだ。

　これには心当たりがある。去年の暮、1ヵ月無料でAUひかりTVが見られるという勧誘の電話にのってレンタルのセットトップボックスを導入し、例の大ブームとなった「鬼滅の刃」や、「進撃の巨人」あたりの動画を見始めた。このとき家族のゲーム回線が時々タイムアウトになるようだ。
　
　回線速度を測ってみた。有線で100Mbps近く、WiFiでも数十メガビットはある。高画質TVの画像の伝送速度はせいぜい15Mbps程度なので、まだ余裕があると思うのだが、イーサネットのようなパケット回線は実質的な速度が半分も行かないことが多い。結果しては動画を2本同時に見るのは無理なようだ。

　それにしても、１Gbit対応のハブ(HUB)やケーブルを使っている割には最大速度が100Mを超えないのは不審だ。ケーブルを改めて詳しく調べてみた。すると無線LANのアダプターに行くLANケーブルが1Gbit対応でないHUBにつながっていることを発見した（10年前は、Gbit用のポート数の多いHUBは結構高かった）。そうか、原因がわかったぞ。これを１Gbit対応のHUBにつなぎ換える。

　いや、これでも改善されない。だいたいGbitイーサなのに、どこも100Mbpsを超えていない。まるまる1000Mbpsを期待しないでも、最低でも20％、普通なら半分近くあって欲しい。それなのに有線でも100メガいかないのはどう見てもおかしい。

現用のWiFiルーターWHR1166DHPの有線ポートは100Mbpsまでだった(1/11/2021)
　我が家のネット環境を簡単に説明しておこう。地下階の配電盤近くに光ONUとAU光電話のルーター（電話2回線なので２つ）があり、ルーターとONUの間はGbitのHUBでつながっている。ここまではKDDIからのレンタルで、調べるべきはルーターから下流の部分である（この思い込みがあとでたたる）。

　WiFi無線ルーター（アクセスポイント）は、一階の居間に置いてあり、有線でルーターにつながっている。TVのセットトップボックスは、無線ルーターの横にあり、無線ルーターのLANポートと有線でつながる。居間のノートPCは、WiFi経由のことが多い。

一方、家族のiPADは2階の寝室で無線でつながる。従って錯綜するのは、地下のルーターから居間に通ずる有線LANの速度が大きなカギを握っていることになる。

　そこで、かねて用意の30メーターのCAT5eケーブルで直接つないでみた。しかし、無線LANの速度は全く変わらず（WiFi接続のノートPCで測定）、iPADの回線切れも改善されない。　

　そのうち重大な事実を知った。無線ルーター（WHR1166DHP）の入口(WANポート)は１Gbps対応なのだが、分配するインターネットポートは100Mbpsだという。あれこれ、色々ネットを探しているうちに、WiFiルーターを新しくしたくなってきた。

このときは現用ルーターが802.11acをサポートしていることに気付いていなかったので、余計欲しくなり、WiFi5のルーターの中でも廉価なこれ(WSR1166DHP2)を注文した。

有線LANが1Gbitにならない原因がわかった(1/14/2021)
　新しいルーターが来るまで時間があるので、基本的な問題、有線でも100Mbpsを超えない問題解明を再開した。光ONUのイーサケーブル出口から、既存のケーブルを片っ端から1Gbps対応のケーブル（Cat5e）で繋ぎ変えて様子を見る。

ONUから電話回線のルーターまでは装置そのものはKDDIのレンタルだが、ケーブルはこちらで用意した覚えがある。実はこの中で前々から気になっていたことがある。2台のルーターを分岐させるHUBのパイロットランプ(LED)の色がバラバラなのだ。ここはすべてGbitなので、LEDは全部緑のはずなのだが、緑（Gbit）と100Mbps以下（橙）が混在しているのである。

有線の速度は、HUBやルーターについている回線速度を表すLEDで判断していた。我が家のメインPCはGbitのNICカードを入れて、ルーターまでの回線が1Gbitでつながっているのは確認されている。それなのに上部の接続でGbitになっていないなら話にならない。

　上部のHUBで緑になっている1メーターばかりのケーブルを取り出してみて驚いた。このケーブルは4芯しか接続されていない100Mbpsまでのケーブルではないか。ありゃりゃあ、これはどういうことだ。最初に工事したときのことを必死になって思い出そうとしたが、全く思い出せない。

　念のため、1Gbpsを通すケーブルを、緑のLEDの点くポートに差してみる。何と、緑でなく橙色になる。うはあ、わかったぞ、このHUBのパイロットランプは1Gbpsが橙で、100Mbps以下が緑なのだ。間違いない。

これをすべて橙に統一して速度を測る。いや、おめでとうございます。有線LANでは、上り下りとも300Mbps近い速度が実現した。スマホも今までの数十Mbpsから100メガ近くまで上がる。iPADの回線も、ひかりTVによって切れることもなくなった。

何とも人騒がせなHUBだった。沢山のHUBを見てきたけれど、遅い回線の方が緑で、早い方のGbitが橙色のパイロットランプというHUBは聞いたことがない。このあと同系のHUBの仕様書をネットで探したが、LEDの色の説明はどこにもなく確認は出来なかった。
　
WiFi5の無線LANルーターをアクセスポイントにする(1/16/2021)
　注文していた新しいWiFiルーター(WSR1166DHP2)が到着した。時間があったのでネットで調べたら、この機種のマニュアルにはAP(アクセスポイント)モードでの設定の説明が一切ないので要注意ということだった。しかし、事前のこの情報のおかげでまごつかずにすんだ。

　要するに、ルーターモードとAPモードを物理スイッチで切り分けているので、ルーターの初期IPアドレスを変えるときに、PCとネットの知識がないと簡単にできないためである。前にも話したと思うが、技術が巨大化、階層化されていくと益々素人がいじるのが難しくなる。

知らない人でも出来るように色々なお助けの仕掛けが出来ているが、最後までうまく行く保証はなく、一旦途中で止まれば全く手も足もでなくなるだろう。Amazonあたりのこの製品の評価サイトには沢山の怨嗟のコメントを見ることができる。

　ともあれ、このルーターはインターネット端子もGbitイーサなので、有線でつないだ1階のノートPCの回線速度も倍増した。ただ体感的にはそれほど早くなった感じはしない。WiFiは予想通り200Mbpsを越え、画面の遷移は確かに早くなった。

　これで我が家のWiFi環境は、名実ともWiFi5と言える環境になった。先に書いたように、前の無線ルーターでも、802.11acをサポートしていたのだが、元の速さが100Mbpsを越えていなかったため、この規格に上がらなかったのではないか。いわゆる大山鳴動して鼠一匹に近い騒ぎだったが、結果としては高速になったので一応は良しとしよう。

とても参考になるサイト(1/20/2021)
https://www.silex.jp/blog/wireless/2015/01/post-15.html　
この小論（２）（３）がすごい。これまでの通信の世界が一望できる
https://ascii.jp/elem/000/000/561/561734/　
イーサケーブルのカテゴリーについての実験が参考になる

電子工作を全くやっていなかったわけではないのですが、まあ、殆ど工作らしいことはしていませんでした。新型コロナウイルス騒ぎで、ジム通いや、テニスサークルの参加など、殆どの外出が出来なくなり、3キロ太りました。いわゆる「コロナ太り」です。

今回の書き込みは、このサイト（ココログ）の無料版が9月の1日から、一年以上更新していないブログを閉鎖するという通知が来たので、とりあえず生存証明を出しておくことにしました。いきなり削除するという荒行はしないようですが、期限をすぎると記事の編集が出来なくなり、編集・追加するときは有料版に加入させるようです。

このブログを今後どうするかについては決めておりません。まあ、このまま立ち消えになっても大騒ぎする話でもないのですが、人の足元を見るような措置には、抵抗をしたくなる気質ですので、こういうことになりました。

復活する可能性はゼロではないので、お楽しみにお待ちください。

PS: 何か工作の時にとった写真や、お出かけのときのスナップを掲載しようと探したのですが、やっぱり1枚もありませんでした。悪しからずご了承ください。

　まあそれは表向きで、低調な理由は、やはり所長の高年齢化、いわゆる加齢（今年から後期高齢者）によるということは残念ながら否定できない。年は取りたくないがこればっかりは皆に平等に訪れるので文句を言ってみても始まらない。

　実はそれだけではない。2月に記事をアップしたあと、いくつか事件があってブログへの意欲がさらに落ちた。それは、恒例のスキー合宿のことである。年と共に年間の滑降日数が減っているが、昨シーズンはたまたま一回も行けず、今年3月始めの八方尾根のスキーは2年ぶりだった。

　これが、もうシーズンの終わりに近く、しかもウイークデイだったため、コースの整地が行き届いておらず、こぶだらけのバーンの急坂（八方リーゼンスラロームコースの薄葉のカベ）で、疲労で足が言うことを聞かなくなってしまったのである。

　いつもシーズン最初の滑りでは足の疲労で激しい痛みに見舞われることがあったのだが、今回は2シーズンぶりで、しかも、このコースは途中から緩斜面の初心者コースに逃げることができない。コース上で立ち往生し、生まれて初めてスノーボートのお世話になった。これまでちょっとした足自慢だったのだが、すっかり自信を失った。

　悪いことは重なるもので、次の日、大雨でスキーをやめスキー場近くの秘境集落（青鬼集落）に遊びに行く途中の山道で、ころがってきたコブシ大の石を跳ね上げ、ミッションオイルのタンクからの油漏れで車が運転不能になった。結局、一行はバスで帰る羽目に陥った。

　直接、電子工作とは関係ないが、度重なる不運である。幸い、修理代やレッカー代、帰りの交通費などは保険が効いたので、経済的な損失はだいぶ免れたが、立て続けの災難に、気持ちの上ですっかり落ちこんでしまい、まとまったことをする気がなくなってしまった。

旧友からブログ再開の催促(2019/6/20)
　それがどうして再開する気になったか、スキーのあと、電子工作を全くやらなかったわけではない。何度か記事を書くために作業メモをワープロに残してはいたが、たいした成果も生まれず記事にまとめるところまで行かなかった。

　こういうものは、一旦、流れの方向を失うと立ち直りが難しくなる。時間が経てば経つほどそうだ。このブログも、もうこれでおしまいかと考えていた矢先、旧友からメールが入った。楽しみにしているのに音沙汰がないが、どうかしたのかという問い合わせである。読者から、しかも知人からの意外な消息の問い合わせは嬉しいものだ。

　これでやっとブログを再開する意欲がわいた。ちょうど、ジャイロセンサーを応用した倒立振り子のウェブの試作記事が面白くて、自分も作りたくなり、少しづつ倒立振り子を作り始めた。完成したらブログを書こうと思っていたのだが、これがまた難儀したのである。

　ただ、うまく行かないとなると、猛烈に何とかしてやろうという気分に陥るいつもの性格が幸いした。結局のところ自作の倒立振り子は、今日現在、まだ立たせることに成功していないのだが、ブログ再開には十分な作業記録もまとまった。記事にするまで、さらにまた2ヵ月ほどかかったことになるが、その間の試行錯誤の記録を公開する(9/15/2019)。
　
名古屋での大学同期の同窓会(3/25/2019)
　電子工作の話の前に、それ以外のことを、書き留めてきたメモを元に少しご紹介。このブログは日記の代わりを兼ねているので、記録の糸を切らさないために暫くご辛抱いただきたい。まずは、3月に名古屋で行われた大学の同期会の話である。

　名古屋は、家族の関係で、このところ行く機会が増えており、また名古屋かと少し迷ったが、名古屋は京浜地区と阪神地区の中間にあたり、関西の連中が久しぶりにたくさん来るというので出席する気になった。

　大学の同期会というのは、若いうちは苦手だった。大学の同窓生は、高校と違い同業者が多いので、現役の頃は、何かと緊張して遠慮することが多い。自分がどうということではない。まわりに気を遣うのである。

 


　大きな会社だと同期が何人も就職している。何十年か経つとおのずと身分に大きな差が生じる。当人たちはさほど気にしているようには見えないが、同級生同士で余りに違いすぎると、かえってまわりが緊張する。

　かたや重役クラスと、研究所の主任研究員あたりとは、話す内容も全く違ってくるし、学生の頃はどちらかというと主任研究員の方が羽振りが良かっただけに、余計に気を遣ってしまう。

　しかし、最近は、卒業してもう50年近くが経ち、殆どの者は、すっかり引退しているので気が楽である。ホテルでの飲み会では、それぞれ近況報告があった。数十年ぶりの再会もあり、話がはずむ。仕事の話はもう殆どなく趣味などの個人的な話が多い。結構面白くて時間を忘れる。

　次の日は、名古屋観光である。熱田神宮と、名古屋城、トヨタ博物館などをみんなで貸し切りバスを利用して訪問した。幸い、始めて行くところが多く、飽きなかった。昼食は名物の「ひつまぶし」。昔から同じというが20年前に食べたものとは少し違うような。

　印象に残ったのは、名古屋城のボランティアのガイドさんたちだった。バスガイドのOGや、会社を息子に譲って引退した旅行代理店の白髪の元社長が、嬉々として案内してくれる。同年代の頑張りについ感動してしまった。やはり人のお役に立つのがいちばん嬉しい。

タッチボタン式ベッドスタンドの改修(5/2/2019)
　工作の話である。家族が使っていた、筐体を触るだけで点灯するスタンドが時々誤動作するようになった。暗闇でも点けられ便利なのだが、勝手に電源が入ってしまうのは危険である。捨てるというので引き取った。

　台座の部分を分解して中身を取り出した。円盤型の台座の中にはタッチ機能一式の入った小さなプラスティックケースが固定もされずに入っているだけの極く簡単な構造である。タッチ機能は、台座、フレキシケーブル、笠などの金属部分を触るたびに、クリプトン球の照明が、小、中、大、オフに切り替わるという仕掛けだ。

　簡単なロジックなので、作り直すなら静電センサーと、SSR（ソリッドステートリレー）にTiny13あたりの極く小さな8ビットマイコンの組み合わせで作れる。しかし、何となく気が進まない。これが電子工作低調の原因なのだが、今までに同じようなことを沢山やってきたので、いわゆる「わくわく」感がないのだ。

　もともとタッチ機能は便利なようで、ちょっと触っただけで、切れたり点いたりするのは自分ではあまり便利だとは思っていなかった。たまに、家人から借りて使って、触れるたびに明るさが変わるので煩わしかった記憶がある。

　どうしたものかと思案していると、塗装された台座の表部分に、タッチを確実にするための金属面のメクラ蓋がつけられているのに気が付いた。タッチセンサーはここをセンサー部の入力としている。この穴に単なるオルタネートのプッシュスイッチをつけて電源スイッチにすればどうだろうか。もっとも簡単な修理法だ。

　久しぶりに秋葉原にでかけ、スイッチの種類の多い千石通商で、良さそうなタクトスイッチ（径6.5ミリ）を見つけてきた。工作は、造作もない。めくら蓋の穴をリーマーで少し広げ、スイッチを取り付けて数か所のハンダ付けをするだけである。

　組み上げてみる。見映えも悪くない。スイッチの押し心地は、台座に重量があるので安定感があり安物のタクトスイッチでも感触は悪くない。現用のベッドスタンドにすることにした。

　リハビリの電子工作としては、全く物足らない作業量だったが、それでも何かを自分の手で解決したという満足感は十分味わえた。

囲碁ソフトに翻弄される。何とか2段(6/15/2019)
　久しぶりに「天頂の囲碁7」という囲碁ソフトを買った。所長は10年近く前に、北朝鮮製の「銀星5」というソフトを試したことがある。これはアマ2段という触れ込みだったが、精々が2級程度で、所長は最後は3目置かせて良い勝負だった。

　今度のソフトはそれとは比べ物にならないほど強そうだ。このソフトを買うきっかけとなった碁仲間によると、全く歯が立たないという。彼はアマ6段の高段者でプライドがあるので最強のままでランクを落としていないそうだが、それにしても市販クラスの囲碁ソフトがそんなに強くなったとは信じがたい。

　注文してほどなくアマゾンから品物が届いた。19路盤は時間がかかるので、13路盤でやってみる。これが強いのである。コンピューターのレベルを初段にしたのだが、何度やっても勝てない。こちらにもプライドがあるので、暫く挑戦したが諦めた。ランクを段々下げていくと2級程度で何とか互角になった。

　そのうち、この囲碁ソフトには検討モードといって、お勧めの次の手を教えてくれる機能があることを知った。これを使うと、これが実に簡単に勝てるのだ。自分がいかにまずい手を打っていたかということをいやというほど味合わされる。

　これを暫く繰り返すうち、次第にこの検討モードを使わなくても勝てるようになった。2級クラスでは、打ってくる手は素人で、切れるところはすべて切ってきて、大抵の試合はねじり合いの混戦になり、読みあいに負けてしまう。2級と言えど、手数の計算はコンピューターにかなわない。

　なるべく挑発に乗らずに、じっくり模様を作っていき、ここぞというところで勝負すると相手が投げてくれるようになった。このソフトは先行き15目以上の負けになりそうなときは投了するようだ（投了を拒否して続けて行くと無茶苦茶な手を打ってきて負ける時があるので注意）。

　次第に勝率が上がり、最近は相手が2段でも、ちょうど良い相手になった。所長は自称、初段と言っているので順当な所か。そんなこんなで電子工作の方はさっぱり進まなかった。

ジャイロセンサーの応用、倒立振り子をつくることにする(7/19/2019)
　電子工作再開のきっかけとなったのは倒立振り子を制作する以下のブログサイトである。

　　半日で作る倒立振り子

　実験の経過の逐一を、ステップバイステップで丁寧に解説されており、とても面白い（最後はProcessingによるPCでの画像シミュレートまである）。読んでいるうち、段々自分もやりたくなってきた。

　ただ、この記事のジャイロセンサーはアナログのもので、所長はこれを持っておらず、CPUもAVRを使った正規のArduinoで、こちらは、例のESP8266である。この記事をそのまま作っていくことは出来ない。移植が必要である。

　しかし、ウェブで「倒立振り子　MPU6050 ESP8266」のキーワードで探すと、これらを使った倒立振り子の記事が山ほど見つかった。　今度は多すぎて、何を選んでよいか迷ってしまうほどだ。

　MPU6050は、6軸の加速度、ジャイロセンサーで、I2Cがインターフェースになっている。3年程前、Processingを使った飛行モデルの実験に使った。記事が残っている。

　このときは実際のハードの姿勢制御ではなく、PC画面上の飛行機モデルを動かすのが目的だった。ソースコードは、そっくりひとさまの物を拝借し、PC画面に飛行機をだそうとしたがうまく行かない。

　つながらないのは、現用のビデオカードが、Proscessingのビデオエンジンをサポートしていないことが原因とわかり、新しいビデオカードを購入したりして大騒ぎして、やっとのことで動かした。結局、ジャイロセンサーの動きを確認するだけに精力を使い果たし、実際の応用まで行かなかった。

　実物の姿勢制御にジャイロセンサーを使うのは、今回が初めてである。モーターなどのメカ部分と、センサーからのデータで如何にモーターを制御するか、ソフトのロジックだけでなく、メカトロニクスとしてはかなり高度な技術が要求される。

　先ほどのサイトの写真を見ていると、モータードライバーは以前、Xbeeを使ったラジコンカーと同じTA7291を使っており、とりあえず、これは、そのまま流用して先に進むことにした。

TA7291Pはやはり4.5V以上が必要か(7/29/2019)
　件のラジコンカーを制作品を積み上げた資料棚から取り出した。このラジコンカーは。タミヤのツインモーターキットを使って、前進と後進だけでなく左右の回転も出来るようになっている。

基板には、今になっては思い出せないトランジスターが6ケも実装されていた。情けないことに、これが何のためにつけられたのか思い出せない。解析の結果、モーター電圧（4.5V）とXbeeのVcc、3.3Vの間のバッファーと断定した（自分で作ったものなのに確信がない。まあ、8年も前のことだけど）。

ところがテストしてみると、TA7291は、リチウム電池の4.1V近辺では動かないのである。データシートを見るとロジック電圧は4.5V以上とある。しかし、ネットのなかでは、Arduinoの3.3Vでも動かしている例がある。どうもおかしい。もう一度やってみたら、今度はちゃんと動いた。

ちょっとパワーが足らないような気がするが、まずは動けば良い（このトラブルは、その後、PWM制御入力ピンのハンダ付け不良が発見されて無事解決した。つまりゲイン最小になっていた）。もし、これで動かなければ、こちらにはDRV8835という強力なモータードライバーがある。

あらためて新しいハードを作るのでなく、このラジコンカーを立てて使い、上にジャイロセンサーや、ESP8266をつけるサブシャーシーをつけることにした。あれこれ実装の方法を考える。

18650電池フォルダーをホットボンドでつけて倒立振り子のハード完成(7/30/2019)
　結局、既存のリモコンカーのシャーシー（といっても秋月C基板）に、フロッピーケースのコーナーを切り取ったL字アングルをつける。このフロッピーケースを応用する方法は、これまでいろいろな所で使っているので手慣れたものである。

　電池は容量の大きい、リチウム充電池18650を使い、Aitendoで手に入れた18650用の電池ケースをホットボンドでメインシャーシーにつける。重心が問題だ。倒立振り子の安定は、重心が上にあればあるほど安定するはずだが、そのことはどの記事にも明記されていない（昔、雨傘を立てて遊んだ記憶にもとづく）。よくわからないが、とりあえず、電池はサブシャーシーとモーターの中間に
つけた。
　
　やっつけだが、一応、定番の倒立振り子風の形が完成した。タイヤが他のウェブサイトの作品のように大型のものにするか迷っている。 テストのため、簡単なスケッチを書いて、TA7291Pモーター基板とESP8266でモーターをリモコンで回すところまで確認した。

ESP8266基板にMPU6050を実装した。出てくる数値がおかしい(8/3/2019)
　駆動部のハードの目途が立ったので、MPU6050の実装に取り掛かる。これは結局ESP8266基板の空き地に単にピンヘッダーを立てるだけでつけてしまった。ジャイロなので本当はもっとしっかりつける必要があると思うが、まずはこれでいこう。

　次はいよいよソフトだ。これが実はくだらないところで大はまりした。　長期間、開発から離れているとどうもカンが働かないからだろうか。横道に何度もはまり込んで、ウンウンうなっていた。まあ、これが面白いということもあるが、全部を書き出しているときりがないので、はまった落とし穴の主なものだけ、以下にまとめておく。

　まず(1)、Arduinoのintって、unsigned　なの？　
　MPU6050の出力データをテストのためUARTに連続して数値を出力していた時である。ジャイロの角度の数値がマイナスに振れないのである。MPU6050の各データは、符号付き16ビットで、8ビットづつのレジスターから値をシフトしてintで定義した変数に収容している。

　これが、マイナスになっていない。8ビットデータ（上位データ）は、符号なし（uint8_t）でとっても、intに入れると符号付でマイナスになるはずなのだが、そうなっていない。ひとつひとつ、データをSerial.print()でしらみつぶしに出力させて確かめた。

　その結果、intタイプの変数に入れたとき、MSBビットをマイナスにみなしていないということがはっきりした。そんな馬鹿な。　Arduinoでもデータタイプのintは、符号付(signed )のはずなのにおかしい。

　半信半疑で、データタイプのintを int16_tにしてみたら、何とちゃんとマイナスが出た。えー、そんなー、信じられない。Arduinoでは、intは符号なし(unsigned)なのか。何かの具合で、データタイプがおかしくなっている。この真相究明に数日を無駄にした。何か間違っているのだろうか（どこかで#defineされている？）。

　次は(2)、ビルドしたプログラムがsoft WDTエラーで先に行かない
　ソースコードは、ここを参考にさせてもらった。ここは、MPU6050とTA7291を使っており、姿勢制御の部分がそのまま使えそうだったからである。ただし、CPUはPICなので、ESP8266のArduinoに書き換える必要がある。

　このあたりの移植は所長にとっては難しい仕事ではない（何十年もやってきた）。タイマーの部分や、割り込みの処理をかえる必要があるが、これらは、すべて調査済みである。（ESP8266のタイマー割り込みは、通常のArduinoの
MsTimer2::set(mill-sec, TimeProc);
MsTimer2::start();

ではなく、
#define MSEC2CLOCK(ms) (ms * 80000L) //ESP8266内部クロック換算。
timer0_isr_init(); // 割り込みルーチンの初期化
timer0_attachInterrupt(timer0_ISR); //割り込みベクトルに登録
timer0_write(ESP.getCycleCount() + MSEC2CLOCK( 100 )); // 100msごと
などを使う。）

　意気揚々と、ESP8266用のコードに書き換え、コンパイルした。順当にコンパイルは通った。モータードライバーはつけずに、出力をデバッグUARTに出させて、まずはテストである。

　ところが、これが全く動かないのである。ウェブで原因を探すが、ハードがおかしいとか、ユーザーループが長すぎるとか、不安定な電源だとか、どうもピントがずれている。PICからの移植だが、機種依存になるようなものは何もやっていない。

　ただ、floatなどの4バイトデータが非常に多いので、SRAMあたりのヒープデータを食ってしまっている感じだ。ユーザープログラムがスタートする前に、メモリ破壊が起きている感じである。

　さらに(3)実行時エラーで、新版のArduinoIDEを試すも、今度はファームが書き込めない
　というので、Arduino　IDEそのものを新しい版に換えてみることにした。今使っているIDEは、数年前におとした1.6.12で、最近は1.8.21まで上がっている。

　ところが悪いことは重なるもので、こいつは、ファームを書き込むesptoolがUARTを認識せず、プログラムそのものを焼くことすらできない。なにか散々な目にあっている。やれやれ、このあたりで原因を究明する気力を失った。

　仕方がないので、IDEは1.6.12まで戻り、別のソースコードで作り直すことにした。

　ここは、MPU6050からのデータを取り出して、相補フィルターで出てきたデータの補正をしているところまであったのでこれを参考にすることにした。

　不思議なことに、最初のソースコードに、このコードを組み込んでみると、WDTのエラーは解消したのである。モーターにはつないでいないが、MPU6050の測定値がシリアルコンソールに派手に出始めたのである。いやいや、理屈はわからないが、プロジェクトは一歩前進した。このあと実際にESP8266の出力ピンからモーターをドライブする段階に入れる。

やっと動く所まで漕ぎつけたが、暴れるだけ(9/19/2019)
　倒立振り子が出来たら、ブログを半年ぶりに更新しようと目論んでいたが、いつまでたっても倒立がうまくいかないのであせっている。タイヤをかえたり、PID制御のパラメーターを変えても、細かいモーターの動きが実現せず、暴れるだけである。

　モーターが「ミー」と弱い音を立てるだけで動かないので、PWM値を上げて、モーターの出力を増やすと、今度は、回りすぎて車体が激しく振動し、倒立するどころではない。

　そのうち、頼まれた研修講師の期日がせまり、その準備でそれどころではなくなった。暫く、工作室に降りない日が続く。それでも日を置くと、物事を外から見ることになり、トラブルがわかってくることがある。それなりの解決法は何となく見えてきたが、ブログの記事もかなり多くなったのでこのあたりで一区切りつけることにする。

　あんなに熱中したCNCマシンも全く遊んでいる。レーザーカッターなど梱包も開けていない。要するに、工作のときの「わくわく」感が得られなくなったのだ。そう、数年前アメリカの雑誌「TIME」に世界で影響力のある100人に選ばれた片付けの名人、近藤麻理恵氏のいう「ときめき」がなくなったのである。

　電子工作は仕事ではない。気分が盛り上がらなければ何もしないで一向にかまわないのだが、貧乏性に生まれたと見えて何か落ち着かない。試験が近づいているのに勉強に手が付かないときと同じような妙な焦燥感に襲われる。それに、このブログは備忘録を兼ねているので、何か書いておかないとまずい。

　現在のところ、これしか生存証明がない。日記はメモ程度でも残すようにしているが（激しい物忘れ対策）、詳しい状況はこのブログが頼りである。というので量は少ないが、この2か月の行動記録（作業ではなく）で、記憶の糸をつないでいくことにした。

自作のループアンテナを曲げわっぱの工法でつくる(1/12/2019)

　でも何か工作をしようと思って、曲げやすいという杉の薄板をホームセンターで年末に買ってあった。中波用のループアンテナを自作するつもりである。厚さ2ミリ、幅5センチの1メートルばかりの薄板が2枚である。

　しかし、薄板を円弧に曲げる方法に迷ってそのままになっている。水に濡らせば良いのだが適当な方法が思いつかない。当初は、風呂場に持ち込むつもりだったが、熱湯の方が効率が良さそうだ。といって板を漬け込む熱湯容器を自宅で用意することは不可能である。

　そのうち、自宅にある竹製の蒸し器の外周がアンテナに近い大きさであることに気づいた。この蒸し器は我が家の最大の鍋に載せるもので、鍋に湯を沸かし、薄板を少しづつ浸して、これにあてていけば、全部を漬けなくても曲げられる気がしてきた。

　意を決して、家人が寝静まったある日の深夜、作業にとりかかる。ガスレンジに鍋をかけ板を焦がさないように斜めにしながら少しづつ沸騰する湯に一分ほど浸したあと、蒸し器の外周にあてて曲げて行く。温度が高いと思いのほか簡単に曲がることがわかった。何のことはない「案ずるより、産むがやすし」の諺通りである。直径およそ30センチの円形のフレームが簡単に作れた。

　円の固定は。凝らなければもっと楽にすんだ。単なる瞬間接着剤だけで完全に止まった。最近の接着剤は強力で、曲げわっぱのような織り込み加工は全く不要である。固定台は、自作の温調付きのアクリル曲げ器で、CDケースを簡単に曲げて作る。テスト用なので見映えはしないが実用的には十分だ。

　次は線材である。この前のデコパネのループアンテナは、被覆線を使ったが、どうも少しかさばる。今度はUEW線にしようと思ったが、手持ちがないので先に進めない。これは買ってこなければならない。

久しぶりの秋葉原。松屋で天ぷらそば。買い物はUEW線(1/14/2019)
　ちょうどそのころ、古い職場の友人から新年会を兼ねて久しぶりに会わないかというお誘いがきた。秋葉原に買い物に来るのでそのついでということである。渡りに船とはこのことであった。定番の須田町のソバ屋、「松屋」で待ち合わせることにする。

　昼時をはずして午後2時に集まったのだが、松屋はこの時間でも行列が出来ていて、大盛況であった。ビールと天ぷらそばを注文する。混んでいるので気が引けたが、一杯くらいなら良いだろう。ここはつきだしに「そばみそ」が出る。これが美味なのだ。

　すっかり満足して買い物にでかけた。電線と言えば、やはりオヤイデ電気である。太さ0.5ミリのUEW線を50mほど調達する。メーター￥15程度で、1000円でおつりが来た。このあとは、2人でなつかしの店の消息を渡り歩く。

　ラジオデパートは定休日ということもあって閑散としていて空きスペースが目立った。昔、結構はまっていた大通りの小さな中華そばや「松楽（しょうらく）」は、代が変わったそうで、店構えには全く昔の面影はないが、立派に営業していた。味は同じらしい。

　これも良く行っていたガード下のラジオセンター横の喫茶店「古炉奈（ころな）」はコスメ喫茶に様変わりしていた。中を覗く気分にはなれない。いわゆるDOS/V通りと言われた末広町にかけての通りに足を延ばすと、立ち並んでいたPCパーツショップの殆どが姿を消していて、2人で嘆く。

　一方、末広町から少し離れたAitendoの直営店には、友人が妙に感動したのが印象的だった。どういう基準で集められたのか判然としないのだが、なにしろ部品の種類が多いという。そして旧交通博物館の中央線の線路の見える喫茶店で一休みした。ここは、前から行きたかったところで、やっとのことでそれが実現できた。ご満悦である。

　自宅に帰って早速、UEW線をループアンテナのフレームに巻く。20回あたりで前の方形ループアンテナと同じインダクタンスが得られるはずだ。テストの結果は、方形のループとほぼ同じ290μHが得られた。しかし感度はわずかながら低い。これは断面積がこちらの方が少ないので順当な結果であろう。

恐るべし中華ラジオの実力(1/16/2019)
　このあいだの1000円台のラジオは家族に持って行かれたので、今度はDSPチューナーのオールバンドラジオを物色する（この前のはアナログ選局）。このあたりになると価格も￥5000台となり、日本製もちらほら良いものがあるが、やっぱり価格/機能比では中国には勝てない。 　TECSUNという中華大手のこれ（PL310ET）を選ぶ。中華の通販は￥1000以下の小さな部品は郵便物で来るのでアマゾン経由でもやたらと時間がかかるが、この程度になるとさすがに宅配便ルートなので到着は早い。数日で届いた。

　早速梱包を解いて中身を取り出す。前のラジオと同じくらいの大きさだ。電池は単3三つでニッケル水素充電池が使え、入れたままで充電できる。少し充電して試聴する。おおお、こいつは室内でもロッドアンテナだけで、在京FMが10何局、簡単に入感する。自作の意欲を奪ってしまう高感度だ。

　ただし選局方法は無茶苦茶難しい。FMや中波帯を自動スキャンする程度ならともかく、短波帯を探訪するには、説明書を熟読してもまだわからない。アンテナがないこともあるが、めぼしい局を殆ど受信することができない。これはまともなアンテナで心を入れ換えて（馬鹿にせず）、練習しないととても使いこなせそうにない。　

　もののはずみで中波用の既製品のループアンテナ(TECSUN AN-200)もついでにポチってしまってあった。テストのため地下に持ち込み、USBドングルのRFコンバーターの前段につないだ。しかし、感度は自作のものと大差がないというより、むしろ低い。ダイヤルを回しても感度に変わりがない。

　小さいので仕方がないと言えばその通りだが、ちょっとがっかりである。RF（無線）は基本、アナログなので、びっくりするような成果は出てこない。まあ、期待する方が間違っていた。

とうとうAitendoのCCDカメラ顕微鏡を代引きで買った(1/18/2019)
　前からAitendoの直営店に行くたびに、気になっていたCCDカメラを付けた顕微鏡をとうとう買ってしまった。この顕微鏡、CCDカメラの画像を大型ディスプレイに映し出すもので、店の一角でデモをやっており、実際にプリント基板などを拡大して見ることができる。

　当研究所では数年前ホーザンの実体双眼顕微鏡を導入し、とりあえず不自由なく0.5ミリピッチまでのハンダ付けは可能になっているが、難点は視野が狭いために肉眼で相当周りを確認しながら使う必要があった。

　このCCDカメラの顕微鏡は、高解像度で大画面に映せるので飛躍的に視認範囲が広がる。しかも対物レンズと対象物の間のクリアランスは30センチ近くあるので、ハンダ付けなどの作業ははるかに楽になりそうである。　しかし、大型ディスプレイに手持ちがなかったのと、場所がかさばりそうなのでためらっていた（価格はスタンドなどをすべて合わせても3万前後でたいしたことはない）。それが正月に、娘に貸してあった液晶ディスプレイが戻ってきたのと、最近の電子工作へのやる気の回復のため、さらにこのあいだの直営店でのデモの印象が強かったため、思い切って買うことにした。

　ちょうど思い立った日が直営店の定休日なのでウェブサイトを見ていたら、なんとレンズキットが売り切れになっている。ところが暫くしたら1ケだけ在庫が戻っているではないか。これはもう買うしかない。あわてて通販で申し込む。

　ところが、Aitendoの通販は銀行振り込みが出来ない。カード支払いは、使える会社が限定されており、残る支払い方法は代引きしかない。手数料をとられるが、まあ、これが一番安全だろう。ぐずぐずしているうちにまた売り切れるかもしれないので、あせって画面に入力する。めでたくレンズキットはカートに入った（このあとだいぶん長い間、レンズキットは在庫切れになっていた）。

リモコン不調なれど、この解像度は凄い(1/20/2019)
　数日後、無事、レンズキット、CCDカメラ、スタンド一式が宅配便で届いた。早速組み立てる。最初、カメラの対物レンズに保護シートが貼ってあり、ぼけぼけ画像に頭を抱えていたが、それを外すと見事な映像が出てきた。

　当研究所の手持ちのディスプレイのHDMI出力はやや不安定で、ひんぴんとリセットを繰り返し心配したが、DVI経由にすると安定した。DVIとHDMIはコネクターが違うだけで両方サポートしているようだ。

　試しに、ハンダ付けをやってみた。実体顕微鏡に比べると、圧倒的な視野の広さは比較にならないほど楽である。焦点深度が浅いのが少し不満だが、もっと困ったのが、ついてきたリモコンの一部の操作が動かないことだった。 　早速、店にクレームのメールを出したところ、すぐに返答があり、返送用の切手つき封筒と代品を送ってきた。しかし、このリモコンも同じ症状だ。電源の入り切りが、OFFは動くがONのとき動作しない。どうもこのCCDカメラの正規のリモコンではないようだ。リモコンはどうしても必要なものではないので、とりあえず2品とも店に送り返し、正しく動くリモコンを再送してくれるよう頼んだ。

閑話休題。下呂温泉と各務原の航空宇宙博物館(1/27/2019)
　工作以外の話題をひとつ。旅行の話である。家族が名古屋に転勤していて今年中に東京に戻りそうなので、今のうちに名古屋近辺に遊びに来ないかと誘いを受けた。ということで、下呂温泉と、近くの刃物で有名な関市に家族で行くことになった。

　この界隈には、平成が終わるというので人気になっている平成の「道の駅」がある。ここは元々の地名が平成（へなり）という町で、話のタネに立ち寄った。何の変哲もない道の駅だが、これが結構な人出で驚いた。よほど行くところにみんな困っているらしい（我々もその一員だったが）。

　下呂温泉は、日本三大名湯（江戸時代の制定で草津と有馬と下呂）のひとつということだが、特に驚くようなところではなく、極く普通の山里に広がる中程度の温泉である。とても寒い日だったので、結局、温泉街へは出向かず、旅館の中でたっぷり温泉を楽しんだ。泉質はアルカリ性で肌にやさしい。　

　関市では、60年ぶりに切り出し小刀を買い替えた。左利き用もあったが（自分は左利き）、右利きの刃の使い方に長年慣れてしまっているので結局、右利き用を買った。学習用は￥1000前後だが、少し贅沢して￥3000クラスのものをもとめる。

　関市に隣接した「かがみはら航空宇宙博物館」にも立ち寄った。各務原は、旧日本軍の航空機開発のメッカであり、戦後も沢山の国産の飛行機がこの近辺で開発されたそ>うだ。ずらりと実機が並んだ博物館はなかなか見ごたえがあった。

　前回記事のとおり、PCでJJY標準電波を見るために、USBアダプターに接続したソフトウエアラジオドングルで画面上に受信した電波のスペクトルを出そうとしている。何十年ぶりかのRF(電波、高周波)の世界に完全に飲み込まれてしまったようだ。

　そもそものきっかけは、このサイトの記事のような気もするが、もっと前からJJYの電波強度を調べていた気もする。いずれにしても、この記事は、6年以上も前の記事で、今や、このほかにも長波のJJYを受信した話は沢山でてくる。ここにはドングルではなく、一般の普通の受信装置で聞いておられる例もある。

　アマチュア無線家の中には、このドングルを受信機（高級型がある）として実用に使っておられる例も数多くあるようで、技術の進歩の激しさに今更ながら驚くばかりである

　JJYの電波そのものは、当研究所ではAitendoの受信モジュールを使った電波時計の自作や、標準電波のリピーター制作などで既にお馴染みである。PCで受信することは目新しい話なので飛びついた。しかし、これが電波を見るとなると、そう簡単にはいかなかった。 　我ながら馬鹿なことにこだわっていると思う。そう、当研究所のモットー、「実用」ということでは、全く実用のあてのない（アマチュア無線をやらないなら）工作である。それでも、後述するように、ドングルとHFコンバーター、それに外付けRFアンプと手製のループアンテナで、40Khz近辺でそれらしい電波を捉えることに成功した。

　しかし、受信機のデコード機能の関係か、正確なパルスコードを見ることは出来ず、本当にこれがそうなのかの確証はない。とはいえ、近辺でそれらしい電波はこれしかなく、3Khzほどオフセットしているが、これはコンバーターのクリスタルの誤差の範囲(数十PPM)だと思われる。受信できたことにしておこう。ともあれ、以下は、この一か月の悪戦苦闘の記録である。

HFコンバーターの組み立て(11/2/2018)
　前回のブログ記事をUPしたあと、予定通りHFコンバーターの組み立てに入った。製作者のサイトには数多くの制作記が載っているが、みなさん例外なく部品の小ささに驚かれているようだ。しかし、こちらには例の実体顕微鏡という強い味方がいる。

　1608チップの実装も怖くない。それでもLEDひとつを飛ばして行方不明にしてしまった。このクラスのパーツは床に飛ばしてしまうと、まず発見は不可能である。しばらく床の絨毯をペンライト片手に文字通り手探りで探したが、早々に諦めた。

　というのは、この大きさのLEDなら手持ちがあるからだ。昔々、ネットの記事（チップ部品の手ハンダ実装競争）に刺激されて手に入れてある。これを取り出して難なくハンダ付けし、とりあえず配線終了である。失くしたLEDは青色だったようで、取り替えたLEDは緑。こちらの方が所長の好みなので怪我の功名であった。

　プリント基板なので、誤配線の心配はない。オプションパーツのリレー（VHF帯へのバイパス）の実装を残し、テストを開始する。アンテナの準備が出来ていないので、まず、自作SG(シグナルジェネレーター)から40khzを出し、ドングルを100Mhz起点にして受信できるかどうかを試す（コンバーターは100Mhzへアップコンバートする。つまり40Khzなら100,040khzを受信）。

　PCのラジオソフトはこの前から使っているSDR#（SDRシャープ）である。よーし、受信しているようだ。それでは、これまでのLTC1799を使ったJJYリピーターではどうか。ふーむ、これは無理なようだ。直付けしていないこともあって受信できない。

　カップリングコンデンサーで直付けすれば、前のドングル直結のダイレクトサンプリングのときのように見えるのだろうが、先を急ぐのでアンテナを使った中波の受信テストに進む。

中波のAM放送が聞こえない。アンテナの原理を学ぶ（11/5/2018）
　中波の受信はJJY受信と直接関係がないが、どの程度の受信能力があるかは試しておきたい。最近のアマチュア無線は、このソフトウエアラジオによるバンドウォッチ（入感の監視）が当たり前になっているようなので、今後この世界に復帰するときのためにも調べておきたい（おいおい）。

　アンテナが問題だ。はじめループアンテナを作ろうと、ウェブサイトを漁ったが、作りたくなるようなものが見つからなかった。調べて行くうちにどんどん基本に戻り、アンテナとは何ぞやというところまで調べる羽目になった。

　ウェブで基本的なことを学ぼうとするが、なかなか良い資料にめぐまれない。どの世界でもそうだが、最初の初歩の部分の解説は山ほどあるが、ちょっと進んで、長波帯での有効なアンテナの考え方を分かりやすく書いたサイトは全く見当たらない。

　恐らく、書籍でもそうだろう。改めて探す気にならない。これまでに何度も失敗をしている。あきらめきれずネットサーフィンを続けるうち、不要電波の輻射をおさえるサイトの解説でふと面白いことを思いついた。要するにこの反対をやれば良いのだ。

　輻射を抑えるには、シールド線のように、行きと帰りのワイヤーを近づけて相殺させる。ぐるぐる巻きをさけて磁界と電界を交錯させないようにとある。そうだ、この逆をやれば、電波が出て行く勘定だ。

　つまり、ワイヤーのさしわたす範囲の面積を出来るだけ広げたり（一本線のアンテナでは地上接地面が対極）、繰り返しの流路をまとめて磁束と電界を交叉させたりすれば（コイル）、電波が輻射していくのだ。一波長が数キロメートルという長波電波でも、ループアンテナのようなものが有効だということが少しは理解できた。

続々とウエブで高周波部品を注文。圧着工具を2度買い（11/10/2018）
　無線、高周波（RF）の世界は、これまでの、マイコンなどの電子工作とは少し毛色の違う部品を使う。同軸コネクターだけでも多種多様な規格があることを学ぶ。秋月電子の店頭で横目でみていたSMAコネクターが小さくて、とても工作心（ごころ）を刺激されていたのだが、これが大威張りで使える。　

　当面、当研究所の高周波コネクターは、SMAに統一することにしてSMA関係のコネクターやケーブルを次々に物色して、ネットで注文している。まるで新しい玩具に夢中になっている子供のようだ。　同軸などの通信ケーブルの配線では、コネクターかしめ用の圧着工具（ペンチ）が重要なキーディバイスである。圧着ペンチは昔から何故か気になる工具で、当研究所では、みな安物ばかりだがイーサネットや電話のRJ11,RJ45用から、ピンヘッダー用のオープンバレル型（これだけはまともなEngineer製）、AC配線の絶縁端子型用まで5つ近くが揃っている。

　圧着ペンチの価格はピンキリで業務用のものは軽く一万円近くするが、ここも最近は中華ものが幅を利かせているようで2千円しないで各種の工具が手に入る。同軸コネクターの圧着工具も中華製が安いので、気楽に他のSMAプラグなどと合わせて注文していたら、コネクターの規格とダイスのサイズの違うものが届いてしまった。

　どうもRG58や、RG174などのこれから使おうと思っているケーブルのサイズと微妙に違っている。いざとなればプラス側の細いピンの固定はハンダ付けで何とかなるが、千円ちょっとの工具なので、ウェブでもう一度、太さを確認し（インチとミリでややこしい）、2本目を発注した。　ところが、こういうときに限って、注文したものと全く違う型番のものが届いた。アマゾンは返品が簡単に出来るので、宅配業者に送料受取人払いで送り返し、同じものを注文しなおす。それにしても、肩の力が抜ける話だ。

　コネクターだけでなく、同軸ケーブルも種類が多すぎて何を選べば良いのかわからない。RG系列（米軍仕様）と、5C2V,3D2VなどのJIS系列は互換性があるところとないところがあり、コネクターそのものも、ケーブルによって種類が違い（太さが違うので）、もう何が何だかわからない状態である。

　既製品のアンテナも色々見つかった。マグネティックシールドループアンテナが良さそうだが、1万円以上してちょっと手が出せない。ケーブルを何メートル用意するのかも問題だ。最終的には、室内ではなく、せめて2階のベランダあたりまで伸ばすことを考えれば20メートル以上は買っておきたい。しかし、余り長いのを買ってしまうと損失がばかにならない。悩ましいところである。

　またケーブルの値段が店によって極端に違うのも気になる。秋葉原の有名なケーブルの専門店オヤイデ電気は結構高い。ネットの方が圧倒的に安いのだが、これもまちまちで迷ってしまう。ケーブルは規格品なのにどうしてこんなに値段が違うのか。中華パチものがあるのだろうか。

子供のラジカセからループアンテナをはずし実験。受信成功(11/13/2018)
　ちょうどそのころ、我が家の物置の奥に娘が捨てていったラジカセが見つかった。MDカセットという今では絶滅した電池式だ。手提げハンドルの脇にちょうど欲しかった巾10センチばかりの中波用のループアンテナがついていた。本体からはずれるようになっていて方向を選べる。

　早速これを利用することにする。たいしたループをしているわけではないが（7ターン）、テストしてみる価値はある。早速、SMAプラグにターミナルブロックをつけるブレーク基板を用意して、接続し、地下のPC横でテストしてみた。

　おお、HFコンバーターで始めて中波AM放送を聞くことができた。地下では、せいぜいが、NHK第一とFEN、それに東京放送(TBS)くらいだが、同軸ケーブルで地上近くに持って行くと、5局以上が受信できた。

　ためしに、電話線でワイヤーを垂らして持ち出すと、家庭電力からの強烈な雑音で全く聞こえなくなった。同軸ケーブルはやっぱりノイズ抑制には欠かせないものであることを納得する。

アンテナを外に出しても感度改善せず(11/15/2018)
　圧着ペンチが届かないので、SMAプラグを、買い置きのRG174ケーブルに、だましだまし固定し、中継プラグで継ぎ足して（例のリバースSMAコードに変換プラグをかませたもの）、ラジカセアンテナを屋外に出した。

　我が家は家族の要望で防犯・防災用に網ガラスが入っている。電波事情としては良い環境とは言えない。これを避けるためである。屋外に固定するために作ったのが、写真のデコパネでつくった棚である。玄関の外壁に両面テープで固定した。 　デコパネ（ポリスチレン樹脂）は、近くのホームセンターでたまたま見つけた極めて軽くてしかも意外に丈夫な板素材である。ポリスチレンも接着できるという接着剤が、最近売り出されているのでそのテストの意味もあって買ってきた。

　デコパネをハサミや、カッターで簡単に切り離し、接着剤で固定する。考えていた構造をあっという間に作ることが出来た。重いものは載せられないが、ループアンテナくらいなら問題ない。ガムテ―プでアンテナを仮止めする。

　ケーブルは、ルーバー型の換気窓の下を通す。見映えはいまひとつだが、無事、地下の工作室から、玄関先の換気窓のところまでケーブルがつながった。勇躍、受信テストに入る。しかし、アンテナを外に出しても感度は殆ど改善されなかった。期待していただけにがっかりである。

4アマくらいならちょっと勉強したら合格できるかも？(11/17/2018)
　RFの世界を調べ始めて、どんどん深入りが止まらなくなっている。今まで避けて通っていたアマチュア無線の世界でもある。見ること聞くことが、とても新鮮で物珍しい。危険だ。ここもオーディオ同様、やりだすと止まらない趣味である。

　それでも誘惑に耐えられず、ウェブで昨今のアマチュア無線界を覗いてしまった。色々面白い。無線の資格が昔に比べると全く変わっている。4級というクラスまである。これが昔の電話級という初心者向けのライセンスのようだ。

　試験問題までウェブで見ることができる。試しに電波工学のところを全く復習せずにやってみた。10問くらいですべて選択問題である。解答を調べる。おお、70%くらいの正解率だ。これはやれるじゃないか。ちょっと楽しみになってきた。

　とはいえ、アマチュア無線を活発にやろうという気は何故か盛り上がってこない。電波の送信だけがやってみたいだけなので、これ以上の具体的なステップには進まなかった。

驚くべき中華ラジオの世界。オールバンドラジオがたったの1500円!(11/19/2018)
　我が家にはだいぶ前から携帯ラジオがない。リファレンス機器として一台買うことにした。災害への備えにもなる。

　適当なものを探すためウェブで調べ始めて驚いた。何とたったの￥1500台でオールバンドラジオが売り出されている。もちろん中華製だが、どうも日本のELPAのコピー品のようだ。だめもとで注文してみる。 　ほどなく到着し、早速試聴した。これがなんと、これまでのHFコンバーター付きのRTL-SDRドングルより感度が高い。地下のPC横の外部アンテナなしでNHK第一が楽々入感する。ニッポン放送などドングルでは入りにくいものまで聞こえる（ノイズが多いが）。すっかり肩の力が抜ける。

　あわててドングルの前段につけるHFアンプを発注する。ドングルといえども、もう少し感度を上げておきたい。HFアンプは、これまた多種多様のアンプが販売されて適当なものを見つけるのが大変だった。少しづつスペックが違う。　RFアンプはともかく、この￥1500台のラジオは家族に強奪された。手芸の時にラジオが一番落ち着くのだそうだ。

2万円以上するSDRドングルがあるそうな(11/28/2018)
　話は発散するばかりで止め処がない。ソフトウエアラジオ（SDR）には、別のオールバンドSDRがあるということを知る。RTL-SDRドングルは8ビットADCだが、これは12ビットサンプリングである。さらにLNA（ローノイズアンプ）が付いている。

　紛らわしいがSDRplay RSP2という名前で、イギリスの製品である。アマチュア無線家が本国から輸入して実際の局の運用に使っているレベルのようだ。ただし価格は 2万円以上する。いずれ中華パチものが出てくると思うが、今のところその情報はない。だいぶん迷ったが、結局、買うことは見合わせる。

デコパネのループアンテナが案外感度が良い。3D-2V同軸ケーブルと接続(12/2/2018)
　格安のモノタロウから50mで￥4000（メートルあたり￥80！オヤイデだと￥200以上）の3D-2Vケーブルが届いた。とりあえず30mで切って両端にSMAプラグを付ける。将来2階のベランダにアンテナを上げても届く長さにした。 　再発注して届いた圧着ペンチで本格的な、コネクターのかしめの仕事をする。この圧着ペンチはアマゾンで売られている格安のペンチ(￥1500 足らず)で、型番はTU-301Gである。秋月で買った、かしめ用のSMAプラグの各部のサイズとどうも0.1ミリほどの誤差があるのが気になったが問題なく圧着に成功した。

　アンテナは、棚で味を占めたデコパネで作る。30cm四方のループアンテナを作った。デコパネなのでフニャフニャだが、沢山巻かなければ大丈夫だ。Aitendoで手に入れたポリバリコンをミニブレッドボードに実装し、中波帯は同調アンテナにする。　秋月で買った精密級（？）のLCRメーター（LE5000）が大活躍である。14ターンで190μHで、4連のポリバリコンをすべて並列にして400pF足らず。これで中波帯が入るはずだ。念のためフランクリン発振回路に入れてみた。見事に、500KHzあたりの発振を確かめた。

遂にJJYを捉えたか(12/7/2018)
　このあいだのテストで外に出しても余り感度が変わらないことがわかったので、アンテナを１Fのサンルームの三脚（ライブカメラ用）に固定して、アンテナのテストに入る。ポリバリコンはつけたままで同調形の中波用になっている。

　アンテナ出力は、ピックアップコイル（3ターン）を同時巻きし、同軸ケーブルで受信機までつなぐ。結果は上々で沢山の放送局が聞こえる。ポリバリコンで感度の高い周波数帯域が移動することを確かめる。AGCをかけないと、大電力のNHK第一や、FENは出力が大きすぎ歪んでしまうほどだ。

　いよいよ、40Khz帯の探索だ。ポリバリコンにさらに並列に0.03μFのセラコンを加え、ドングルの前にHFアンプを加えて、ソフトウエアラジオのSDR#を100Mhz帯にセットする。

　左側に、局発の100Mhzの大きなピークが映り、右横の周波数帯をrangeバーで広げて、出現するピークを慎重に調べて行く。ヘテロダイン方式の受信機は、とにかく混変調を起こしやすく（自分で別の電波を作っているので）、至る所にあらわれるイメージ波に用心しないといけない。

　すると、40Khzより少し低いが、数Khz手前の38.5Khz近辺に出力が間歇的に上下する電波を発見した。ラジオをCWモードにするが、JJY時報のようなパルスは捉えられない。暫く、周辺を探索する。HFコンバーターは中波でも数Khzの誤差が出ているので、これがどうもJJY臭い。

　JJYは毎時15分と45分にJJYのコールサインをモールスコードで発信している。何回かこのタイミングで耳をそばだてたが、聞き取ることは出来なかった。

　確かな証拠は見つけられなかったが、これがJJYの40Khzである可能性は高い。RFの世界の探索は今後も続けるとして、JJYを見るというテーマはこのへんで一段落して肩の荷を下ろすことにする。

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

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

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

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

スペアナが欲しいが高い(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以上では出力が消える。

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

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

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

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

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

　価格も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値が現れた。得た値をウェブの早見表ソフトに入れカットオフ周波数を調べる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　久しぶりに秋月にでかけ（このところは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だった。テストしただけで、部品箱に眠っている。

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

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

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

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

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

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

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

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

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

　こうしたことを頭に入れて、オシロで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標準電波の方も場所を選べば安定して受信できる。しかし、受信機にはまだもうひとつ大きな問題が残っている。

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

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

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

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

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

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

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

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

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

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

　以前、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」の初期表示がでた。やれやれ長かったな。コントラストの配線をしていないのでコントラスト最小のまま表示が見えていなかっただけというお粗末である。

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

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

較正の仕方がわかってエンコーダーの開発は順調に進む（8/22/2018）
　猛暑が続く。しかし地下室は温度が安定して涼しく、極楽だ。それなのに電子工作の進捗ははかばかしくない。今度のプロジェクトの最終目標は、ESP8266でNTP時刻を使いJJY電波をエンコードするリピーターである。　そのモニター用のこれも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ブリンクは、このところいやというほどテストしているので、大体の動きは見ているだけでわかる。

　よーし、それらしい点滅が始まった。念のためオシロにもいれて動きを確認する。良いようだ。ブレッドボード上の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になるタイミングを待って同期させる方法に換えてみた。これでかなり正確になるはずだが、余り前と変わらない。それでも、分の更新の遅れの修正や（これは単なるコーディングミス）、コンソール出力メッセージの調整（多すぎるデバッグ用メッセージ削除）を進め、段々電波時計らしくなってきた。

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

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

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

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

　このLCDはI2CとSPI両方のインターフェースをサポートしているので、ジャンパー配線や、パスコンを2つも接続しなければならないが、とりあえずはピンだけにしてブレッドボードでこのあたりは配線する。 　最終的には、受信機も、リピーターも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にして再ビルドする。やったー、文字が出た。

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

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

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

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

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

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

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

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

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

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

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

　原因はフットプリントデータと、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が点滅し始めた。

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

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

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

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

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

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

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

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

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

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

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

　これは受信用だが、送信アンテナの代わりになるはずだ。単にオシレーターの出力につなぐのではなく、サイトの記事通り、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である。動かしてみるとシリアルコンソール上に、正確な年月日時分秒が出た。

　同期をどうするかという問題は残るが、これで必要なリソースはすべて揃ったことになる。ただし正確さについては、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用で、負電圧回路は全く必要がなかった。お馬鹿な話である。

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

　バックライトに電源を入れて、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回に一回くらいか）、時刻が出る時もあるが、これでは実用性にかける。

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

　地上近くでは、殆どエラーは起きない。この状態でやっと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の経過秒より一日増やせば一致することがわかった。

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

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

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

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

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

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

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

　このため、最近何冊か参考書を買って勉強しているが、今一つ成果は上がっていない。意気込んでプログラミングにとりかかったもののなかなか先に進まない。ウェブを漁ったり、過去の参考書を引っ張り出したり、悪戦苦闘の連続で、まともに動き始めるのに、結局ほぼ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)
　開発の話が続いたので、たまには、電子工作以外の話題をご紹介。所長の例の京都の小学校の同窓会の話である。これまでは京都近郊の少し離れた会場（石山寺、宇治など）に惹かれて、東京から足を運んでいたが、こんどは別のおさそいである。幹事もなかなかやるものだ。

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

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

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

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

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

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

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

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

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

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

　HTML文書は、以前、ESP32で画像付きサーバーを作ったときのソースを流用して、とりあえず画面を立ち上げる。styleシートの扱いが難しく、素人まるだしの無粋な画面だが、動かしてみると、これが意外にも簡単に動いた。　とりあえず、電子音量リモコンの上下ボタンと、エアコンのスタート/ストップだけの操作だが、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となる。やれやれ。

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

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

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

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

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

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

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

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

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

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

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

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

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

　このあたりは最近どうなっているのだろう。ネットで「学習リモコン」をキーに検索する。すると最近の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コンソールをつないで早速動作テストに入る。

　おお、素晴らしい。赤外線パルスのマイクロセカンドのオーダーの数値がコンソールに並んだ。いや、さすがは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データ方式）。

　このユニットは電池駆動にする予定である。リモコンの対象が家の各部に散らばっていて、テストのためには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はトランジスタより高速だというのに、この波形はおかしいではないか。

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

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

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

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

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

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

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

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

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

　赤外線の送信トリガーはタクトスイッチで、発信の確認は赤外線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年越しの懸案が解決した。勝利の快感に酔いしれる。これだから電子工作はやめられない。このあと、ウェブサーバーへの移転にも成功したのだが、紙数が増えてきたのでこのへんで一段落としよう。

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

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

　残るは、実機のテストである。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のコントロールボードから採って調べてみた（ストロベリーリナックスがおまけにつけてくれた極小プローブが役に立った）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

中国からドリルビットが届くまで、他の工作で気を紛らわす(3/27/2018)
　やり残している工作はいくらでもある。まず、このあいだESP8266でワイヤレス化したロボットアームの暴走抑止である。制御系の電池がへたるとアームが暴走するのを止めたい。このあいだ全てのモーターが動き出して、大騒ぎになった。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　冗談はともかく、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側までおかしくなった。ペアリングのときにシリアルディバイスではなくてオーディオ機器だとプロファイルを勘違いしはじめる。何度か繰り返すとうまくいくときがあるというのが悩ましい。どうも、道具として使えるほど安定していない感じである。 　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）に表示されるようになった。

　しかし、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情報が溢れかえっている。

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

　まあ、これはどの分野でも同じで覚悟はしていたが、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パッケージの入れ替えまでやった。勿論それでも動かない。

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

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

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

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

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

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

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

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

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

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

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

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

　しばらく、これで悩んだ。サイトを巡り歩いているうちに、原因らしいものをみつけた。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()

エンドミルの種類が多すぎて迷う(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板の彫刻の準備をすることにした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

突然、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でうまく動かない。

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

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

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

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

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

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

echo "Hello World" > /dev/rfcomm0　

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

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

cat /dev/rfcomm0

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

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

　それでも、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からキーボードを持ってきて先に進むしかない。結局、キーボードなしのインストールは実績を積むことが出来ず、普通のインストールとなってしまった。

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

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

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

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

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

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

　スピンドルへの固定は、手持ちのあり合わせですませる。当て板に使っていた蒲鉾板の端切れに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階に分かれてしまって混乱する。所長にとっては全く縁がないエレキギターの部品が結構大きな面積を占めているのも気に入らないところだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　ロボットアームなど、いくらこだわっても所詮は玩具である。一方、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レギュレーターが揃っている。レギュレーターによっては、発振したり、なかなか定電圧にならなかったり微妙にやっかいな部品である。しかも、過去にはレギュレーターを２つも焼損させて「復讐」を受けたりしている。

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

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

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

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

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

　まあ、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の省電力化をあきらめないでしつこく続けることにした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

無事、ロボットアームは元気を取り戻したが(12/16/2017)

　待ち時間を調整して、送る間隔と、受け取る間隔を同じにし、受信側も、受信データが来ない時は一定時間待ち、さらにデータの有無を聞いて、ないとき始めて制御を止めるロジックに変える。

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

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

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

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

ロジアナでUDPを解析することを決断する(12/25/2017)

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

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

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

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

ロジアナで原因は一発で解明(12/27/2017)

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

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

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

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

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

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

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

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

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

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

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

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

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

　不便だが、それぞれのモーターのボタンはすべて動きの開始だけで、停止は共通のボタン一つにすることにした。それにしても、このボタンに使う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が動くまで、瞬時というわけではなく一息遅れてしまう。これがどれくらいの遅れか実測し、スマホ方式を諦める駄目押しにしたい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　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Ωの抵抗を入れてしのぐ。

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

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

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

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

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

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

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

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

　ロボットアームは、将来もっと本格的なものに乗り換えたいのだが（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が出回っている。　まあ、メインの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しかないとか色々議論があるようで、これの検証も兼ねて４MBにしてみたのだが、いずれにしても動かないなら仕方がない。これを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モーターだが、少し高級になるとサーボモーターが多い。ステッピングモーターを使ったものはアマチュア向けにはないようだ。これは位置決めの仕掛けが難しいからだろう。

　所長が選んだキットは、￥5,000余りの日本製の「グリッパーアームロボット40320C」である。有線リモコンの5軸のDCモーター駆動で、先端に名前の通りはさみ（グリッパー）がついている。ツートーンカラーで、デザインが洒落ているのが気に入った。

　DCモーターなので、自動制御のようなことは出来ないが、有線をESP8266のようなものでワイヤレスにすることはできそうだ。画面を見ているうち急に欲しくなり、思わずアマゾンで注文のボタンを押してしまった。

電池が原因で片側が動かず、あせる(10/25/2017)
　キットは、4～5日で届いた。早速、記念撮影し、中を開ける。丁寧な組み立て説明書がついているので制作に不安はない。リモコンのコントローラーまで組み立て式で、スイッチは大きな金属片でプリント基板と接触させる。バラストを兼ねた単一電池4本を2本づつ正転と逆転用にわけ通電する方式で電子的な部品は一切使っていない。

　プラモデルのような部品を組み合わせ、モーターユニットを作っていく。3時間程度の作業を2回かけて2日で完成した。勇躍テストに入る。ところが逆転ができない。ひとつひとつのモーターユニットはテストが済んでいるので、問題はコントローラー周りだが、おかしなところは何もない。

　大体、部品など何もついていない回路で疑うところは電池のホルダーのところだけだが、しっかりハンダ付けで固定されている。しかも片側だけ動かないというのが気に入らない。テスターまで持ち出してやっと原因がわかった。

　何と片側の電池1つが、へたっていた。無負荷で測ると、1.5Vを指すが、電流を流したとたん0V近くまで下がる。使ったあとの電池が紛れていたようだ。単一電池は、他の小さな電池に比べると、へたると格段に高い内部抵抗を持つことが分かった。

　やれやれ、この電池のおかげで2回、配線ボックスを分解させられた。電池を取り替えてめでたくロボットアームは上下左右、自由に動くようになった。暫く夢中になって遊ぶ。ただリモコンのスイッチが固く、小さい子供さんが動かすのには苦労するだろう。

　次の目論見は、これにモータードライバーを入れてタクトスイッチだけで動くようにすることだ。最終的には、ESP8266を使ってワイヤレス化する。

＃22AWGの基板配線はとても難しい(10/28/2017)
　モータードライバーで動かす基板制作を始める。キットの元の基板のマウントを利用し、秋月のC基板を少し削るとピッタリ入った。ESP8266あたりを付ける広さも確保された。

　例のモータードライバーDRV8835を3つ、コネクターの周りにレイアウトし、5つのモーターの制御を行う。6つ制御できるがひとつは未使用のままにしておく。念のためアートワークも描いた。配線はモーターなので細いUEW(ウレタン)線ではなく、＃22の耐熱撚線（UL3265）を使う。こういうときのために買い置いてある、少々のハンダ付けの熱でも全く溶けたりしない丈夫な被覆を持っている撚線だ。

　配線を始めてちょっと後悔した。#22は少し太すぎて、DIPピッチではピンとピンの間を通すことが出来ない。まあ、被覆があるので接触することに神経質になることはないが、もう少し番手の大きい#24あたりが良かったかもしれない。しかし乗り掛かった舟である。そのまま配線を進める。

　ちなみに、22番の撚線の断面積は、0.633平方mmで、厚さ35μmのプリント基板配線だと9ミリぐらいの幅に相当する。#24くらいの撚線で配線すれば問題ないかも知れない。これで5ミリ幅程度、1Aクラスのモーターまで大丈夫なはずだ。

　久しぶりの基板の配線に夢中になる。苦労すればするほど出来上がったときの喜びは大きい。ただ最近は集中できる時間が短くなって2時間が限度だ。制御線はUEW線で済ませ、一日2時間程度の作業で5日で仕上がった。

DRV8835モータードライバーの在庫切れ(11/4/2017)
　しかし、問題が残っている。DRV8835そのものの手持ちが２つしかない。ひとつ足りない。未実装のDRV8835はアダプターの配線だけで先に進んだ。4つのモーターの動作確認は済んだが、まだ全体には組み込めない。

　秋葉原に車で出かけて秋月電子に向かった。なんと！DRV8835が売り切れている。11月上旬入荷予定とある。そのあとネットで入荷を確認して店にいったがまだ届いておらず、結局3回も秋月に通って11月4日遂に3個めを手に入れた。　

　帰ってすぐブレークアウト基板をハンダ付けする。とりあえず制御線だけ引き出し、ミニブレッドボードにタクトスイッチを並べてテストする。

　タクトスイッチはモーター5つに6ケ。モーター一つにスイッチを2つ設けて、正転、逆転それぞれ受け持たせるのが一番自然だが、これだと、制御線が10本になってしまい、将来のリモコンには多すぎる。esp8266は9本しかGPIOピンが使えない。

　このために、DRV8835のモードは、始動/停止と、正転/逆転にわかれたモード1を選ぶ。正転/逆転のピンは全部共通にしてピンの節約をはかった。

　とにかく、タクトスイッチによるリモコンは完成した。思っている以上に紙数が増えたので今回はこのあたりで。

　しかし、今度の記事は胸を張って明るく報告できる。今流行りのWiFiモジュールESP8266の兄貴分ESP-WROOM-32（以下ESP32）で、画像付きのウェブサーバーの開発に挑み、このほど動かすことが出来たのだ。

　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まで）をビルドしているようだけど、どう言うことなんだろう。まあ、何十分もかかるわけでもないので待つしかないが、何か無駄のような。

　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と同じように、延々とすべてのライブラリのコンパイルが続く。

　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バイト）になってしまうことに、だいぶ後になってから気づくというお粗末である。

　しかも、関数の引数にすると呼ばれた先では、strlenでも文字数が正しく得られない。それやこれやで苦闘の結果、何とか出せたのだが、<object src=XXXXX />のタグでは、スクロールバーのようなものが出てしまう。目的は画像ファイルなので、道草を食いたくないのだが、テキストファイルの表示だけで四苦八苦である。

何と、もっと良い方法を見つけた。バイナリの埋め込み(9/24/2017)
　色々とウェブをさ迷ううち、SPIFFSではない、もっと楽な画像ファイルの表示方法があることを偶然つきとめた。いや情報は浴びるように摂っていれば良いことがあるという言葉どおりの快挙である。

　esp-idf esp32 webserverなどのキーワードで、調べているうち、スマホのきれいな画像のボタンでLEDをウェブから制御しているページを見つけた。

　ボタンがきれいなイラスト画像(pngファイル)である。へえー、サーバーでどこかのクラウドサーバーにリンクして画像を持ってきているのだろうかと、思っていたら、どうもそうではない。　mainと同列にある、component.mkファイルにCOMPONET_EMBED_FILES:=でファイル名を定義すると、これをbinary dataとしてフラッシュに埋め込んでくれるというのだ。

　これはすごい。以前、AVRでやったことのある、フラッシュにバイナリーデータを埋め込むobjcopyと同じ手法である。埋め込んだ後、エントリーポイントを取得すれば、プログラムのなかでこのバイナリーデータを使うことが出来る。

　まだSPIFFSではjpegファイルまで進んでいないが、ファイルを読み込まなくても、外部参照だけでデータをとりこめる。しかもバッファーの長さを気にする必要もない（コンスタントデータなのでバッファーの長さは気にしないで良い）。

　これは試してみるしかない。早速、サイトの情報を頼りに、見よう見まねで、適当なjpegファイルをとりだし（SPIFFSスタックの中にあった画像）、component.mkファイルに設定し、ビルドしてみた。おーし、何のエラーも出ずビルドは終わった。

　次はmake flashである。いつもより少し時間がかかるが無事終了した。jpegファイル40KB分だけ遅くなっているか。さあ、make monitorでサーバーを立ち上げる。

　おおー、やった。画像がホームページに出た。しかも早い！一瞬だ。嬉しくて何度もディスプレイの前でガッツポーズをする。ホームページそのものは、画像とテストメッセージ一行の何も意味もないページだが、このあとには無限の可能性が待っている。

SPIFFSでも画像ファイルの送出に成功。そう遅くにもならない(9/25/2017)
　勢いに乗って、SPIFFSでも画像が送れるかやってみる。このnetconn_serverというしかけが良く見えないので、バッファーサイズをどれくらいまで広げられるかわからない。これが、画像ファイルの読み込みを遅らせていた理由だが、もうそんなことは言っていられない。適当なサイズ(4KB)でneconn_write()を繰り返し発行することにする。

　恐らく、バイナリ埋め込みに比べれば遅くで使い物にならないかもしれないが、まずはやってみる。動かしてみた。おやあ、またstack overflowで止まる。祈る気持ちでスタックサイズを2048の3倍からさらに4倍の、8192まで上げて再度動かしてみる。

　よーし、動いた。そんなに遅くならない。esp-idfについているデバッグ用のメッセージにms単位のタイムスタンプがあるので、これで測ってみると、同じ画像で、埋め込みで平均62msが、SPIFFSだと108msだ。ブロックサイズを広げればもう少し早くなるかもしれない。

　とにかく、ESP32の画像付きサーバーの開発はこれで一段落した。胸を張ってブログに報告できる。

以下に、サーバーのソース一式をONE DRIVEで公開します。ディレクトリごとzipファイルにしたので、これをesp-idfのホームディレクトリに展開し、mainの直上のディレクトリでビルドすれば、バイナリデータを埋め込んでくれます。ソースには2種類のやりかたがコメントとして残っているので、適当に選んでください。WiFiの設定はmake menuconfigで行います。

ここをクリックしてONEDRIVEに行く

　そもそも、このTiny85を使ったソフトI2Cのライブラリーは、もう2年も前に開発したもので、ソースコードまで公開している。今度の開発でいくつかの不具合が見つかったので、改訂版を出せばそれですむ話なのだが、せっかく再公開するのだから、もう少し機能を増やしておこうと欲を出したのが間違いの始まりだった。

　ソースコードをレビューしているうち、最初の版は、I2Cのマスター読み込みのストップコンディション検知が未実装だったことがわかった。ブログ記事では作ったことになっているが、ソースコードを読んでみると実装されていない。

　スレーブからマスターへの送信(マスター読み込み)の終了は、最後のデータバイトにマスターがNACK応答を返せば止まるので、ストップコンディションは不要と言えば不要である。しかし出来ていると書いてしまった手前、放置するわけにもいかなくなった。それにマスター書き込みの方は、リピートスタートまで（もちろんストップも）実装したのに、何となく落ち着きが悪い。

　そこで、これを追加しようと気楽にコードを加えたのだが、これがうまくいかない。出来上がったプログラムはどうやってもストップコンディションを受け付けないのである。マスターはストップコンディションを出しているはずなのにロジアナで見ると波形が出ていない。謎である。

　脱線につぐ脱線というのが、がた老AVR研究所の通例ではあるが、今回はどうもいけない。迷路に入りすぎだ。I2Cのスレーブ側のプログラムは、すべて割り込み駆動で、SR04を制御するバックグラウンドルーチンとは非同期で同時に動く。デバッグは一筋縄では行かない。

　こういう細かいことに興味のない読者の方々には申し訳ないが、実は所長は、こうした箱庭のような8ビットマイコンのマルチタスク的プログラミングが好きで、つい深入りしてしまう。ロジックアナライザーで全体の様子が手に取るように把握できるようになったので余計やめられなくなっている。

　以下は、この泥沼のようなプログラム開発の一か月の顛末である。しかも今回は撤退に次ぐ撤退の苦しい開発となった。まあ、こういうときもあると自分を慰めている。

懸案のI2C通信と計測の同時処理はあきらめる(8/6/2017)
　前回記事で、SR04のエコーと、I2C通信の共通変数（タイマーキャリーカウンター）を分離して、正しいデータが出たと喜んだのもつかの間、少し待ち時間を短くしていくとまたデータが不正確になってきた。どうも距離の計測値が低すぎるし、安定した値がでてこない。

　ソースコードをもう一度入念に調べる。すると、共用していないはずのタイマールーチンに続々とおかしな使い方が見えてきた。要するに被っていたのはキャリー変数だけではなかったのである。

　まず、肝心のタイマーのおおもとのレジスターTCNT0をI2Cが始まるたびに0に戻していた。最大でも0.26ms（8ビットのオーバーフロー）、音速にして5センチ余りの誤差は、今度の用途（人感センサー）を考えると、そう大きな問題ではないが正確でなくなることには間違いない。　さらに、I2Cの通信が終わるたびに、タイマーのオーバーフロー割り込みを止めてしまっていることが判明した。タイマーそのものは動いていても、8ビットタイマーのキャリーが増えていかないのは致命的だ。これが、ときどき距離が不正確になる犯人であった。

　この一週間、デバッグに奔走していた。調べれば調べるほど、エコー時間計測とI2C通信の非同期処理は不可能であることがわかってきた。要するにタイマーが一つしかないところで、タイムアウトと計測を一緒にやろうというのが無理筋だったのである。

　とにかく、こんなにリソースを共用していたらマルチタスクもあったものではない。計測期間中にI2C通信を行うソフトの開発は中止することにした。今回の無駄足は疲労感が強い。もっと早く気が付くべき基本のところを忘れて、深入りしてしまったからだ。　

　当初の方式、センサーのエコーを少し長めに待ち（SR04の最大エコー30ms程度）、データを読み込む方式に戻した。これでも100ms以内で連続して計測が出来る。まあ、人感センサーならこの程度で十分だろう。

マスター読み込みのストップコンディション検知にチャレンジ(8/16/2017)
　エコー期間中にI2Cを動かして計測間隔を短縮しようという目論見は完全にはずれた。意気込んでプログラミングをしようと振り上げた拳（こぶし）の行き先がない。この高ぶった気分を鎮めるために、何か手を動かさないと納まりがつかなくなってしまった。

　そこで、未実装の「マスター読み込み」シーケンスのストップコンディションの検知機能を開発することにした。しかし、これも難儀したのである。しかけは、「マスター書き込み」と同じように最初のデータビットのクロック（SCL）立ち上がり区間で、データライン(SDA)を監視して、ストップコンディションを判定する。

　「マスター書き込み」では、スタートコンディション（これはリピートスタート）もストップコンディションも順調に検知し、動作も確認している。簡単に動くだろうと気楽にコーディングしたのだが、全く動かない。かえって、全体の動作が不安定になってしまった。

　いつものロジックアナライザーにプローブ点を増やして解析する。波形を見ると、マスターがストップコンディションを実行しているのに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クロックが外れているのを発見した。

　タイミングによっては、これがスタート／ストップコンディションとみなされ、そのあとのデータが欠落する。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とのペアで追加した機能と、修正した不具合の部分を以下にまとめておく。

追加した機能：
(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とは違うプラットホームで動き始めたようだ。これを試すのも悪くないかと思っている。