疑似電波時計の全体の構成を考える

疑似電波時計(勝手に命名していますが)を作ろうと思い、電子ペーパーに始まり、セグメント液晶をPICで動かすことをやってきました。
alasixosaka.hatenablog.com
alasixosaka.hatenablog.com

どうやらセグメント液晶とPICの液晶ドライバ機能を使うことで、目的の電池駆動は達成できそうなことが分かった。
alasixosaka.hatenablog.com

なので、疑似電波時計の全体構成を考えてみた。
時計機能自体は、PICの持っているRTCCとLCDドライバでセグメント液晶を駆動することで達成できるが、どうやって時刻を合わせるかが問題。

どうやって時刻を合わせるか

まず、下記の3つの案を考えた。

  1. ESP8266やESP32を使ってインターネット経由で時刻を取得しPICとシリアル通信して時刻を合わせる。
  2. GPSモジュールとTWE-LITEを組み合わせた時計サーバーを構築し、PICに子機のTWE-LITEを繋いで時刻を合わせる
  3. ESP8266やESP32とTWE-LITEを組み合わせた時計サーバーを構築し、PICの子機のTWE-LITEを繋いで時刻を合わせる

このうち、1の案が最もシンプルだし、安上がり。TWE-LITEは¥1800位するが、ESP8266なら¥1000以下で買える。しかし、消費電流が大きいのが問題。色々調べたが、電池で駆動するためにはそれなりに工夫が必要らしい。突入電流が1Aほどもあるという話で、電池で動かしている人は大容量のコンデンサを使ったりしている。ESPは不要なの時はスリープさせておけばよいのだが、WiFiに接続して時刻を取得するまでに数秒程度がかかるので、その間の消費電流が大きくて電池の持ちが心配なのと、電池が減った時に突入電流で動かなくなる心配があり却下。
2の案は、前に疑似電波時計を作ろうとしたときに考えた案で、時計サーバー自体は試作したものが既にある。しかし、今回改めて検証したところ、シリアルの通信速度が115200bpsくらいないとデータを取りこぼしてしまってうまく拾えないことが分かった。おまけに、送られてくるデータはNMEAという書式で大量の文字列の羅列でこの中から時刻データを拾い出す必要がある。一番痛いのは通信速度で115200bpsを出そうと思ったら、PICのクロック周波数が4MHz以上必要になり、PIC自体の消費電流も上がってしまう。
そこで、今回は最も手間がかかる方法になりそうだが、3の案で進めることにした。
全体の構成はこんなイメージ

疑似電波時計イメージ図

時計側はPICとTWELITEをシリアルで通信してサーバーからの時刻情報を受け取る。時計サーバーは、ESP8266(又はESP32)でインターネットから現在時刻を入手して、I2C通信でRTCモジュールに書き込む。TWELITEは、I2CでRTCモジュールと通信して現在時刻を入手して無線で送信する。RTCモジュール自体は極低消費電力なので、TWELITEとESP8266を適当にスリープさせれば電池で駆動できるかもしれない。ACアダプタ駆動にしても、消費電力を抑えるに越したことはない。RTCモジュール自体は精度がまずまずあるので、時計合わせは1回/日程度で問題ないと考えている。TWELITE側は、結構な頻度で送信する必要がありそう。というのも、受け側の時計側のTWELITEも常に稼働しておくと消費電力が大きすぎて電池が持たない。普段はスリープしておいて1回/日程度起きて時刻を取得するようにしたい。とすると、サーバー側は時計側のTWELITEがいつ起きてもいいように結構な頻度で送信をしておく必要がある。今のところ1回/秒くらいを考えているが、そのあたりはやりながら調整してく方針。
また、時計サーバー側のTWELITEはI2CでRTCモジュールから時刻を読み取ることができれば、ESP8266とのシリアル通信は不要になる。ただし、その場合は自分でプログラムを組まないと行けない。それができなければシリアル通信でESP8266と通信するしかない。そうするとESP8266もTWELITEと同じタイミングで起きてRTCモジュールのデータを読みに行く必要があるので消費電力的には苦しい。まあ、とりあえず、TWELITEのI2C通信にチャレンジしてみることにする。