みちびきの災害・危機管理通報サービス受信実験
スイッチサイエンスさんで「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テストは問題なし（後で判ったが確認したのは送信だけだったのが失敗）
SAM-M8Qのシリアル出力
こちらも問題なしと思っていて実際は出力ピンを観間違えていた
問題点
実は問題が２点あり解決まで時間が掛かることになる
①SAM-M8Qのシリアル出力のピンが反対
シールドにTx，Rxと記載されているが動作は反対になっていてRxが出力（どうやら相手側を記載しているようだ）
②ESP32C3 SuperMiniのSerial1のピンの割り当てに制限があり，受信に割り当てピンは20でないと安定しない
これはSAM-M8Qの出力が問題なかったので，ESP32C3のSerial1（SAM-M8Q受信）をSerialで出力したところ何も出力されなかったので，ネットで調べたらSuperMiniでは基板がコンパクトな影響もあって受信が安定していないことが判明
修正点
Rx，Tx指定ピンの変更（上記のスケッチでは修正されている），配線は結果的に修正なしでOKとなる
まずは受信はできるようになったので基本構成は良しで，災害・危機管理通報試験日に情報取得テストを実施する予定