スイッチサイエンスさんで「GPSシールドを使ってみちびき（QZSS）の災害・危機管理通報サービス（DC Report・DCX）を受信してみた。」という記事が公開されていて面白そうなんで試してみる
記事が出た時から気になっていて，地球上の通信はインターネットの普及で有線化されてしまったもんだから，通信（受信も）を楽しむなら地球外だなと思っていたところ，アマチュアレベルでみちびきの情報受信ができるというのは魅力があった訳である
実験といっても既に実装方法が公開されているので，そのまんま利用させてもらい，まずはベースとなる構成の確認となる
購入したのは動作確認が取れている以下の２つ
- ESPrR Developer C6（ESP32C6）
- ESPrR Developer用GPSシールド（SAM-M8Q）
ハードウェア
ESP32C6は予備として使用しないでESP32C3 SuperMiniを使う
SAM-M8Qとの接続はSerialだけで良いようなのでESP32C3のSerial1と繋ぐ
SAM-M8QのTXD，RXDはシールド上で切替可能となっており，初期はIO4，IO5に接続されていることに注意
ソフトウェア
必要ライブラリは以下の３つでIDEからインストール
- SparkFun_u-blox_GNSS_Arduino_Library：V2を使う（ライブラリ名通りで良い）
- QZQSM：修正する必要はない
- DCX
メインスケッチは「espr_dev_qzss_drc_drx_decode.ino」をgithubからDLして一部修正
#ifdef ARDUINO_ESP32C6_DEV
const int rxPin = 15;
const int txPin = 21;
#elif ARDUINO_ESP32C3_DEV //Super Mini
const int rxPin = 20;
const int txPin = 21;
#elif ARDUINO_ESP32S3_DEV
const int rxPin = 40;
const int txPin = 35;
#else // ESP32_DEV
const int rxPin = 19;
const int txPin = 21;
#endif
テスト
ビルドでESP32は対応してない旨のメッセージが表示されるが問題なし
ところが最初は動作しなかった（以下がデバッグメッセージ込みの出力）
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.
Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 1
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
begin: isConnected - second attempt
Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 1
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
begin: isConnected - third attempt
Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 1
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.
Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 1
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
begin: isConnected - second attempt
Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 1
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
begin: isConnected - third attempt
Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 1
sendCommand: Waiting for ACK response
waitForACKResponse: TIMEOUT after 1100 msec.
u-blox GNSS not detected. Please check wiring. Freezing.
これをSAM-M8Qとの通信であるSerial1の問題だと考え調査
ESP32C3のSerial1テスト（tx:20，rx:21）は問題なし（後で判ったが確認したのは送信だけだったのが失敗）
SAM-M8Qのシリアル出力
こちらも問題なしと思っていて実際は出力ピンを見間違えていた
問題点
実は問題が２点あり解決まで時間が掛かることになる
①SAM-M8Qのシリアル入出力のピンが反対
シールドにTx，Rxと記載されているが動作は反対になっていてRxが出力（どうやら相手側を記載しているようだ）
②ESP32C3 SuperMiniはSerial1のピンの割り当てに制限があり，受信の割り当てピンは20でないと動作しない
これはSAM-M8Qの出力をESP32C3のSerial1（SAM-M8Qから受信）で受信後，Serialで出力したところ何も出力されなかったので，ネットで調べたらSuperMiniでは基板がコンパクトな影響もあって受信が安定していないことが判明
SuperMiniのピンレイアウト図ではRxは21と記載されている（これも接続相手側を示しているならややこしいことだ）
修正点
Rx，Tx指定ピンの変更（上記のスケッチでは修正されている），配線は結果的に修正なしでOKとなる
まずは受信はできるようになったので基本構成は良しで，災害・危機管理通報試験日に情報取得テストを実施する予定
（追加）
情報取得確認
窓際で受信
30秒位してQZSSを受信
受信情報はタブレットのUSB接続にて「Serial USB Terminal」を使い表示（当然スマホでも可）
熊本地震では通信設備の破損などによりスマホが使用できなくなったようだが，みちびきからの受信は可能なので非常時において少ない情報ではあるが参考にはなるだろう
今後の展開
ポータブルならハードケースを作成してスマホのUSB接続で利用可能
固定運用ならDBサーバに送信してWebから参照するようにすれば良い（トップページに最新情報を表示するのも良さそう）
