スイッチの押し心地は、台座に重量があるので安定感があり安物のタクトスイッチでも感触は悪くない。現用のベッドスタンドにすることにした。リハビリの電子工作としては、全く物足らない作業量だったが、それでも何かを自分の手で解決したという満足感は十分味わえた。囲碁ソフトに翻弄される。何とか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である。この記事をそのまま作っていくことは出来ない。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基板の空き地に単にピンヘッダーを立てるだけでつけてしまった。ジャイロなので本当はもっとしっかりつける必要があると思うが、まずはこれでいこう。次はいよいよソフトだ。これが実はくだらないところで大はまりした。長期間、開発から離れているとどうもカンが働かないからだろうか。横道に何度もはまり込んで、ウンウンうなっていた。これが面白いということもあるが、全部を書き出しているときりがないので、はまった落とし穴の主なものだけ、以下にまとめておく。MPU6050の出力データをテストのためUARTに連続して数値を出力していた時である。ジャイロの角度の数値がマイナスに振れないのである。MPU6050の各データは、符号付き16ビットで、8ビットづつのレジスターから値をシフトしてintで定義した変数に収容している。これが、マイナスになっていない。8ビットデータ(上位データ)は、符号なし(uint8_t)でとっても、intに入れると符号付でマイナスになるはずなのだが、そうなっていない。ひとつひとつ、データをSerial.print()でしらみつぶしに出力させて確かめた。その結果、intタイプの変数に入れたとき、MSBビットをマイナスにみなしていないということがはっきりした。)のはずなのにおかしい。int16_tにしてみたら、何とちゃんとマイナスが出た。えー、そんなー、信じられない。Arduinoでは、intは符号なし(unsigned)なのか。何かの具合で、データタイプがおかしくなっている。この真相究明に数日を無駄にした。何か間違っているのだろうか(どこかで#defineされている?)。WDTエラーで先に行かないソースコードは、ここを参考にさせてもらった。ここは、MPU6050とTA7291を使っており、姿勢制御の部分がそのまま使えそうだったからである。CPUはPICなので、ESP8266のArduinoに書き換える必要がある。このあたりの移植は所長にとっては難しい仕事ではない(何十年もやってきた)。タイマーの部分や、割り込みの処理をかえる必要があるが、これらは、すべて調査済みである。//ESP8266内部クロック換算。100msごとなどを使う。)意気揚々と、ESP8266用のコードに書き換え、コンパイルした。順当にコンパイルは通った。モータードライバーはつけずに、出力をデバッグUARTに出させて、まずはテストである。ところが、これが全く動かないのである。ウェブで原因を探すが、ハードがおかしいとか、ユーザーループが長すぎるとか、不安定な電源だとか、どうもピントがずれている。PICからの移植だが、機種依存になるようなものは何もやっていない。floatなどの4バイトデータが非常に多いので、SRAMあたりのヒープデータを食ってしまっている感じだ。ユーザープログラムがスタートする前に、メモリ破壊が起きている感じである。IDEそのものを新しい版に換えてみることにした。今使っているIDEは、数年前におとした1.6.12で、最近は1.8.21まで上がっている。ところが悪いことは重なるもので、こいつは、ファームを書き込むesptoolがUARTを認識せず、プログラムそのものを焼くことすらできない。なにか散々な目にあっている。やれやれ、このあたりで原因を究明する気力を失った。仕方がないので、IDEは1.6.12まで戻り、別のソースコードで作り直すことにした。ここは、MPU6050からのデータを取り出して、相補フィルターで出てきたデータの補正をしているところまであったのでこれを参考にすることにした。不思議なことに、最初のソースコードに、このコードを組み込んでみると、WDTのエラーは解消したのである。モーターにはつないでいないが、MPU6050の測定値がシリアルコンソールに派手に出始めたのである。いやいや、理屈はわからないが、プロジェクトは一歩前進した。このあと実際にESP8266の出力ピンからモーターをドライブする段階に入れる。動く所まで漕ぎつけたが、暴れるだけ(9/19/2019)倒立振り子が出来たら、ブログを半年ぶりに更新しようと目論んでいたが、いつまでたっても倒立がうまくいかないのであせっている。タイヤをかえたり、PID制御のパラメーターを変えても、細かいモーターの動きが実現せず、暴れるだけである。モーターが「ミー」と弱い音を立てるだけで動かないので、PWM値を上げて、モーターの出力を増やすと、今度は、回りすぎて車体が激しく振動し、倒立するどころではない。そのうち、頼まれた研修講師の期日がせまり、その準備でそれどころではなくなった。工作室に降りない日が続く。それでも日を置くと、物事を外から見ることになり、トラブルがわかってくることがある。それなりの解決法は何となく見えてきたが、ブログの記事もかなり多くなったのでこのあたりで一区切りつけることにする。(火)ESP8266のJJY電波時計のスケッチ公開これまで作っていたESP8266を使ったJJY電波リピーターと電波時計受信機のうち、受信機の方が何とか安定して時刻を知らせるようになった。こちらを先に、ソースコードと回路図を公開することにする。電波時計は長時間動かすものだから、本来はESP8266のような大喰いのWiFiモジュールで作るのは筋違いだが、WiFi環境が必要な電波リピーターにESP8266を使ったので、開発環境を共通にしたかったのと、気楽に始めたのにうまく動かず、止めるに止められなくなったせいでもある。前にも書いたが、JJYの受信パルスは1秒に一回の超低速通信(1bps)である。クロック80MHzのESP8266なら沢山のロジックを組み込んで、相当インテリジェントなエラー修正が出来ると意気込んで始めたのだが、これがとんでもなく難関で、ほんの少しでもノイズが出るような受信環境では全く正しくデコードができない。リピーターのコイルから数十センチも離すと、受信モジュールが正規の福島(おおたかどやま)からの電波も受け始めて干渉を起こすらしく、年月日などに目茶目茶な数字を出し始めて全く話にならない。出来ないとなると、むらむらと反抗心が出てきて何とかしてやろうと、いつもの悪い癖が出る。この3週間、半分泣きべそをかきながら、意地になってデバッグに熱中していた。その結果、何とか市販の電波時計程度の信頼性のある時計になったので、Arduinoのスケッチソースリストと、回路図を公開することにする。詳しくはこれ以降の作業記録で。日本の女子は強い(9/9/2018)その前に、ちょっと電子工作とは違う話題を少し。プロテニスの話である。手が届きそうで届かなかったテニス4大大会(グランドスラム)の日本人の優勝は、天真爛漫なあの「大坂なおみ」があっさり全米で達成してしまった。4年前の錦織の全米準優勝も驚いたが、今度はもっとすごい。すべてに優勝)をやってのけるかもしれない。錦織のときにも同じことを書いたが、野球はアメリカと日本でしか騒がないのに対し、テニスは全世界が対象である。サッカーは庶民が中心だが、テニスはセレブのスポーツファンを巻き込む。ウィンブルドンの観客の平均年収は2000万円という話を聞いたこともある。世界に与える影響は、野球の比ではない。気になるのが、彼女の出自の問題だ。今、世界は、水面下では色々あっても建前上は人種の区別をしないことに極度に神経質になっている。それなのに日本のマスコミが彼女の帰国会見で、実に無神経な質問をしたのには驚いた(あなたは何人?)。いう話は、すぐに世界中にひろまる(マスコミの浅はかさは世界共通)。世界から日本が馬鹿にされるのは身から出た錆でしようがないけれど、大坂選手が日本に愛想をつかしてアメリカ国籍に換わってしまわないことを祈るばかりである。I2C液晶を2台とも4本の結線だけで動かす(9/10/2018)電子工作の話に戻ろう。Aitendoで入手した2台のI2C液晶の始末である。このうち一台は電源を逆接してしまい、破損が心配されたが、幸運にも壊れていなかった。バックライト付きだから今のところACアダプターのついた電波時計に使う予定である。インターフェースはI2Cだが、液晶の本体は12本のピンが出ており、内部で使うコンデンサーや、I2C/SPIの識別をする制御線などの追加の配線が必要である。工作のついでに、2つの液晶がいつでも使えるようチップコンデンサーなどを使って整備しておくことにした。このままでは、ブレッドボードに配線を加える必要があり、特にひとつは動作テストを急いだため、ジャンパーコードやコンデンサーを空中でハンダ付けする完全なバラック状態になっている。このコンデンサーは省略することが出来ない。はずすと簡単に動かなくなる。久しぶりに秋月にでかけ(このところはAitendoが多かった)、1μFのチップセラコンを入手した。相変わらず、ここはいつも賑わっている。帰って早速チップセラコン(2012)の空中配線を楽しむ。本ですむのだが、4本だとやや強度に不安が出る。液晶とバックライトの発光面との接着である。両面テープで貼るのは手軽で良いが、蛍光面にテープが見えて見栄えが悪い。それと時計の表示装置にするのならバックライトなしの液晶の方が消費電力が少なくて済む。JJY電波リピーターのバグを解消した(9/14/2018)電波時計の前にやることが残っている。JJY電波リピーターの不具合である。リピーターはNTPから時刻を貰っているので正確無比のはずなのだが、長時間動かすと、何故か分単位で遅れることがある。NTPや、WiFiが原因であることは考えにくいので、すべてこちらが悪いのだが、原因が思い当たらない。秒間の最後がポジションマーカーパルスで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秒)を定義する。分かれ、時分については第4フレームにパリティビットがついて誤り検知が出来るようになっている。この連続マーカーパルスさえ正しく検知できれば、データが途中乱れても相当なエラー回復が可能である。いわゆるフレーム同期というやつで、月日、西暦などのデータは数多く重複するので、フレーム単位にデータを貯めておけば、大きな狂いを防ぐことも出来る。したことを頭に入れて、オシロでJJY受信モジュールの出力波形をつぶさに観察すると、ノイズはパルスの立ち上がりや立下りでチャタリング風に出る短いパルスが多く、パルスの真ん中を分断することは少ない。チャタリング抑止のロジックを入れればだいぶエラーを減らせそうだ。パルス巾の認定にも工夫をした。参考にさせて貰ったソースリストでは、パルス巾の有効範囲がひどく狭く、それ以外をエラーにしている。このため、ちょっとノイズが出始めると、エラービットばかりになって話にならない。考えてみれば、パルス巾は、0.2、0.5、0.8秒以外はないので(15分、45分に出るモールス信号列を除けば)、中間値をすべてエラーにするのはおかしい。少々強引だが、ここではエラーの範囲をなくし、適当な区切りですべてを何らかの有効データとみなして後で調整することにした。思いつくエラー修正を片っ端から盛り込むも迷走(9/23/2018)さらに、次のようなフレーム単位の修正ロジックを入れて、実験を開始した。測定では正式のJJY標準電波は、PCルームではノイズだらけで全くデコード不能になるので、主にNTPを使った電波リピーターの出力をソースにする。それでも正規のJJY電波と干渉するせいか少し離すとノイズが出る。●正時(0秒)と正時の間のフレーム数が、6つ以外はエラーとしこの間のデータは捨てる●マーカーとマーカーの間のパルス数が規定以外(9ビット)ではエラーとし、このフレームのデータを無効とする。この程度では少し波形がノイズっぽくなってくると、データが全く有効ではなくなり、表示は目茶目茶になる。致命的なのが、正時を判断する連続ポジションマーカーの取りこぼしで、たとえそのあとのフレームを正しく受信していても、西暦などもとんでもない数字に変わってしまう。のみ始めて、そのときの時分、年月日を表示する。有効/無効フラグを設定し、年月日のデータは使いまわしをする。データ保全を狙った改善を行った。精度が高くなった半面、正しい時刻に戻るのに時間がかかるうえ、時々、月日や西暦が出鱈目になる不具合は改善されない。エラーの程度を定量的に把握することが難しく何が効果があるのかわからないので泥沼状態である。試しに正式な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の回路図ファイルを置きます。今年の8月は例年にない猛暑だった。観測史上初めてという猛暑日(35度以上)数の記録が各地で相次いだ。ここ東京も例外ではなく、月後半には猛烈な雷の夕立が連続したりして、何か日本が亜熱帯気候地帯に変わってしまったかのような不気味さを覚える。電子工作は相変わらずである。暑さでアスレチックジムのヨガを欠席することが増えて工作の時間はむしろ増えているのだが(何しろ老人は不要不急の外出はするなと脅されている)、集中が効かなくなっている。昔に比べれば間違いなく進行の速度が落ちている。ESP8266を使いまわして、AitendoのJJY標準電波受信モジュールを使った自作電波時計や、オシレーターチップ(LTC1799)を使ってJJY電波にNTP時刻を載せるリピーターを大分前から作っているのだが、どうも埒(らち)が明かない。記事の更新間隔もまた一か月を越えてしまった。それでも、あれこれいじくりまわして、やっとそれらしい動きを双方がするようになってきたので、ここらでご報告することにする。このままずるずるブログの更新が出来ないでいると、電子工作に対する意欲そのものを失う心配があるからだ。前回記事のコメント通り、自前の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年のロジックを入れたのに逆さまでは何にもならない。これでは一日遅れるのは当然だ。)のロジックを修正する。簡単に解決した(添付画面は修正済み)。考えてみたら、UNIXの経過秒は、1970/1/1からの計算だから、時差とは関係ない。プログラムミスの疑いを持つべきだった。いうことにあとから気づくのだから、どうしようもない。パラレルキャラクタLCDもお粗末なトラブル(8/15/2018)気になっていたパラレルのキャラクターLCDが動くようになった。Arduinoの標準ライブラリ(LiguidCrystal.h)では動かず、ESP8266ではだめなのかも、と放置してあったのだが、その後ウェブ上で新しいライブラリーが見つかったのでこれを試すことにした。LCDのテストに使っていたNTP時刻をUARTに出力するプログラムに、前のライブラリを退避させて新しく組み込む。こいつも最初は動かなかった。このパラレルLCDは当初3.3V仕様であることを忘れ、不要なバックライトの負電圧回路を組み込んだり、バックライト配線が別にあることに気づくのが遅れたり散々苦労しているのだが、今度も駄目かとがっくり落ち込む。いうときは腰を据えて、落ち着くことだ。基本に立ち返ってハードウエアの配線からチェックしなおした。おやあ、コントラストを決める端子が未配線だけれど、これに電圧をかけなくても良いの?いや、そりゃ駄目でしょう。こいつが原因に違いない。あわててブレークアウト基板に、半固定抵抗器を実装し、ピンに接続する。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は構造化ブロックの識別がインデント(字下げ)だけなので、間違いやすいだろう。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秒というのが多い。相手が人間である限り、こだわってみても余り意味はないのだが気にはなる。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先生である。ウェブを漁ると出てきた出てきた。いつものエラーメッセージぶっこみ方式である。file」で一発で、このGitHubがヒットした。ST7032.cppを探し出し、この通りにしたらコンパイルが通った。意気揚々と、配線をしてテストを開始する。店が紹介するデータシートは中国語だが、不思議に殆どが理解可能だ。それと、I2C/SPIの識別する制御ピンなどを適当につないで実験を開始した。この液晶もコントラスト不足で最後までてこずる(9/5/2018)これがまた全く動かない。ライブラリーを使うのは楽で良いけれど、ソフトが悪いのかハードが悪いのか、このままでは全く見当がつかない。いうときは処置なしである。そのうち、不具合箇所の切り分けに良い方法を見つけた。I2C液晶は、ストロベリーリナックスの昔のPCMプレーヤーに使った現物がブレッドボード上に残っている。これを流用して動かしてみればどちらが悪いかすぐわかる。え、いやこれも動かない。何だと―、ソフトが悪いのか。ウェブ上で紹介されているソースリストをもう一度良く見る(これしか頼りにならない)。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の方である。ピッチ変換ピンヘッダーをもう一度付け直すのは大変なのでジャンパーコードを無理やりハンダ付けし、付属のパスコンなどは空中配線でつけてテストした。良かった、壊れていなかった。やれやれこれでブログに書くことができる。(スケッチのコードはまだ未完成なので、次回以降に公開したいと思います。記事の間隔が今回も一か月を越えた。このあいだ電子工作をやっていなかったわけではない。毎日、PCルームにこもって、ごそごそやっているのだが、何しろやることが発散し、次々に興味が他に移るので記事にまとめるところまでいかない。赤外線リモコンウェブサーバーのプロジェクトはソースコードの公開で一段落し、そのあと、表面実装基板にするため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というチップが目に入った。Protocol)から得た正確な時刻を元に自前のJJYの標準電波(40kHz)を出して、電波時計を動かそうというものである。ウェブを検索してみて驚いた。NTPを使った電波時計リピーターは、最近は事務所などで沢山の掛け時計の時刻合わせに使われるらしく、市販品が多数出ており、しかも結構な価格で売り出されている。安いものでも2万円はする。電波時計のJJY信号は、もう6年も前、Aitendoで実際に受信モジュールを買ってきてテストしたことがある。値段を聞いて俄然、制作意欲が盛り上がった。赤外線サーバーそっちのけで、受信モジュールの実験の準備を始める。リピーターの実験には、こういう受信モジュールが必須だからだ。電波時計リピーターの方は、参考にさせて貰ったサイトではRaspberryPiでPythonを使ったソースコードが公開されている。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デコードのソースコードはウェブにいくつかころがっていた。IDEを使ったそのうちの一つが簡単そうなので、これを利用させてもらうことにする。参考にさせて貰ったソースのブログは以下の通り。https://ameblo.jp/amano-jacky-nochio/entry-11824498383.htmlソースが見つかったので安心して、その前に、まだやっていない40kHzの発振機能を確かめておくことにした。電波送信は昔の真空管のC級増幅を真似る(7/14/2018)ブレッドボードにLTC1799モジュールを差し込み、ウェブで紹介された通りの回路を組み立てる。このサイトの記事は外見だけでアンテナの諸元の詳しい説明がない。これは電波法のからみで具体的な情報を避けておられると勝手に判断し、自分なりのアンテナを用意して長波の電波発振のテストを始めることにした。動作そのものは、モジュールなので電源を入れると簡単に動いた。オシロで波形を確かめる。矩形波の綺麗なパルスが出ているのを確認した。組み上げたJJY受信モジュールを近づけてみる。アンテナは適当なリード線(電話ケーブル4~5m)である。JJYのデコードは出来ていないが、受信だけならLEDの点滅でわかる。ブレッドボードの近くに受信モジュールを近づけると、LEDが点いたままになり、受信していることは明らかだ。