Skip to content

Progress Log: ビルドフラグ整理と実機検証計画

Task Description

v1.8.2リリース（WiFi APIリファクタリング完了）後、プロジェクト全体のコンパイル時フラグの状態を整理し、WiFi機能導入に伴う実機検証要件を検討。

目的：

  • 現在のビルドフラグ一覧化（ENABLE_WIFI、STREAM_FORMAT、ENABLE_BME280等）
  • フラグ間の相互作用を把握
  • WiFi有効時の実機検証が必要な項目を特定
  • 本番デプロイ前に実施すべきハードウェアテスト計画を策定

現状のビルドフラグ環境

実装済みフラグ一覧

WiFi関連：

  • ENABLE_WIFI=0|1 - WiFi APモード＋埋め込みWeb UI（v1.8.0追加、約150-200KB追加）

データストリーム形式（相互排他）：

  • STREAM_FORMAT=0 - SSV（スペース区切り）- デフォルト、本番用
  • STREAM_FORMAT=1 - TSV（タブ区切り）
  • STREAM_FORMAT=2 - CSV（カンマ区切り＋ヘッダ）
  • STREAM_FORMAT=3 - JSONL（JSON Lines形式）

センサデータ選択：

  • ENABLE_BME280=0|1 - 環境センサ（温度・気圧・湿度）の含有
  • ENABLE_TIMESTAMP=0|1 - uptime_ms、duration_usフィールド含有
  • ENABLE_GPIO_ABSTRACTION=0|1 - GPIO HAL API（v1.6.8+）vs直接レジスタアクセス

通信プロトコル選択：

  • ENABLE_TEXT_PROTOCOL=0|1 - テキストコマンド vs バイナリプロトコル（相互排他）

検出・デバッグ：

  • DEBUG_DETECTION_MODE=0|1 - 定期モード（ベンチ用）vs 通常検出

その他メモリ関連：

  • DETECT_POLL_COUNT - 検出周期あたりのGPIOポーリング数（デフォルト100）

v1.8.2での4つのビルドプロファイル

esp32dev-release:

  • リリースタイプ：本番用（-O2最適化）
  • WiFi：無効
  • テキストコマンド：無効
  • 検出モード：通常
  • フラッシュ使用率：22.6%（925KB/4MB）
  • 用途：フィールド展開

esp32dev-debug:

  • リリースタイプ：デバッグ用（-Ogシンボル付き）
  • WiFi：無効
  • テキストコマンド：無効
  • 検出モード：通常
  • フラッシュ使用率：22.9%
  • 用途：本番トラブルシューティング

esp32dev-dev:

  • リリースタイプ：開発用（-O2最適化）
  • WiFi：有効
  • テキストコマンド：有効
  • 検出モード：定期モード
  • フラッシュ使用率：25%
  • 用途：通常開発

esp32dev-wifi:

  • リリースタイプ：開発用（-O2最適化）
  • WiFi：有効
  • テキストコマンド：有効
  • 検出モード：定期モード
  • フラッシュ使用率：26.8%（1093KB/4MB）
  • 用途：WiFi機能フォーカス開発

メモリ使用率

  • ベースライン（esp32dev-release）：925KB（22.6%）
  • WiFi追加分：約168KB（4.2%）
  • 合計（esp32dev-wifi）：約1093KB（26.8%）
  • 残り容量：73.2% ✓ 十分な余裕あり

フラグ組み合わせと検証状態

v1.8.2で検証済みの組み合わせ

✅ 確認済みビルド構成：

  • esp32dev-release - STREAM_FORMAT=0、ENABLE_BME280=1、ENABLE_TIMESTAMP=0、ENABLE_WIFI=0
  • esp32dev-debug - releaseと同じ、デバッグシンボル付き
  • esp32dev-dev - ENABLE_TEXT_PROTOCOL=1、DEBUG_DETECTION_MODE=1、ENABLE_TIMESTAMP=1
  • esp32dev-wifi - ENABLE_WIFI=1、ENABLE_TEXT_PROTOCOL=1、STREAM_FORMAT=3（JSONL）

検証が必要な未テスト組み合わせ

🔄 実機検証が必要な組み合わせ：

WiFi＋通常検出：

  • ENABLE_WIFI=1 + 通常検出モード - WiFiが宇宙線検出を邪魔しないか
  • ENABLE_WIFI=1 + ENABLE_GPIO_ABSTRACTION=1 - 抽象化層の重複による影響

データフォーマット組み合わせ：

  • STREAM_FORMAT=1,2,3 + ENABLE_TIMESTAMP=1 - TSV/CSV/JSONLにタイムスタンプ付き
  • STREAM_FORMAT=3（JSONL）全フィールド - ArduinoJsonのメモリ使用量

環境センサ＋WiFi：

  • ENABLE_WIFI=1 + ENABLE_BME280=0 - WiFiのみ（サイズ最適化）
  • ENABLE_WIFI=1 + ENABLE_BME280=1 - フルセンサスイート（現在のesp32dev-wifi）

実装必要なハードウェア検証項目

2025-11-22-wifi-evaluation.mdの分析に基づく

WiFiハードウェア導入時の3つの主要リスク：

1. 宇宙線検出への電磁干渉（EMI/RF） ⚠️ 最優先

リスク内容：

  • WiFi電波（2.4GHz）が以下に誘導ノイズを引き起こす可能性
  • ADC読み値（GPIO32）への影響
  • GPIO検出入力（GPIO12、GPIO19、GPIO27）への影響
  • 電源カップリング経由の影響

必要なテスト内容：

  • 基準値測定（WiFi OFF時）
  • 各検出ピンで100個の連続サンプル取得
  • ノイズフロアと標準偏差を計算

  • 1分間のADC読み値記録

  • WiFi有効時の測定

  • WiFi AP常時ブロードキャスト中に同じ測定実施
  • ベースライン比較でSNR悪化度を評価

  • 受入基準：ΔSNR < 5% またはノイズ増加 < 2σ

  • WiFi通信中の測定

  • ブラウザから継続的なAPI呼び出し（1回/秒）
  • スレッショルド値を繰り返し測定
  • データ破損や誤検出の有無確認

2. 電源供給の安定性 ⚠️ 最優先

リスク内容：

  • WiFiスイッチング電流（50-150mAのピーク）による
  • VCC低下（sag）がADC精度に影響
  • グラウンドバウンスがGPIOロジックレベルに影響

必要なテスト内容：

  • 電源レール測定（WiFi ON vs OFF）
  • オシロスコープでVCC波紋を測定
  • 波紋の大きさが±100mV以内か確認

  • ESP32データシート推奨値との比較

  • WiFi負荷下でのADC安定性

  • GPIO32（ADC）の読み値をWiFi活動前後で記録
  • WiFi送信とADCノイズの相関確認
  • 目標：ADC読み値の分散 < 50 LSB

3. ファームウェアサイズとメモリ制約 ⚠️ 中優先

リスク内容：

  • 未テストのフラグ組み合わせがメモリ上限を超える可能性

必要なテスト内容：

  • 全フラグ組み合わせのビルドサイズ監査
  • 各フラグ有効時のバイナリサイズ測定

  • 受入基準：全フラッシュ < 80%（3.2MB）

  • 実行時メモリプロファイリング

  • WiFi操作中のピークヒープ使用量
  • 長時間運用時のメモリリーク確認
  • 目標：RAM < 70%（224KB以下）

テスト計画と実機検証フロー

フェーズ1：オフラインビルド検証（2025-11-23～24）

目標：すべてのフラグ組み合わせが正常にコンパイルできることを確認

テスト対象：

  • ✓ esp32dev-release（ベースライン、既に確認済み）
  • ✓ esp32dev-dev（既に確認済み）
  • ✓ esp32dev-debug（既に確認済み）
  • ✓ esp32dev-wifi（既に確認済み）

フラグオーバーライドテスト：

  • STREAM_FORMAT=1（TSV）+ ENABLE_TIMESTAMP=1
  • STREAM_FORMAT=2（CSV）+ ENABLE_TIMESTAMP=1
  • STREAM_FORMAT=3（JSONL）+ ENABLE_TIMESTAMP=1
  • ENABLE_WIFI=1 + ENABLE_GPIO_ABSTRACTION=1
  • ENABLE_WIFI=1 + ENABLE_BME280=0（最小WiFi構成）

成功基準：

  • すべてのビルドがエラーなくコンパイル
  • 全組み合わせでフラッシュ使用率 < 80%
  • バイナリサイズが想定範囲内

フェーズ2：実機検証 - 検出性能（2025-11-25～27）

必要な実験機器：

  • OSECHIプロトタイプ（完全なセンサスイート搭載ESP32開発ボード）
  • オシロスコープまたはUSBロジックアナライザ
  • 宇宙線検出セットアップ（ミューオン源またはバックグラウンド）
  • 電源供給（USB or ラボ用電源、電流測定可能なもの）

テストシーケンス：

  1. ベースライン測定（WiFi OFF）
  2. esp32dev-releaseをアップロード
  3. GPIO12、19、27から100サンプル採取（入力信号なし）
  4. GPIO32（ADC）を1分間継続測定
  5. ノイズ統計計算（平均値、σ、最小値、最大値）

  6. 結果記録：baseline_wifi_off.log

  7. WiFi有効・待機状態

  8. esp32dev-wifiをアップロード
  9. WiFi APはブロードキャストするがクライアント接続なし
  10. GPIO/ADC測定を繰り返し
  11. ベースラインとの比較 → SNR悪化度を計算

  12. 結果記録：baseline_wifi_idle.log

  13. WiFiアクティブ通信中

  14. ブラウザクライアントをWiFi APに接続
  15. 継続的なAPI呼び出し（1回/秒、5分間）
  16. WiFi通信中のGPIO/ADC測定
  17. 誤検出や見落とし検出の有無確認

  18. 結果記録：baseline_wifi_traffic.log

  19. 宇宙線検出テスト（ミューオン源がある場合）

  20. 検出ピンに信号注入
  21. WiFi ON vs OFF での検出信頼性を測定
  22. 誤検出数、見落とし数をカウント
  23. 受入基準：エラー率 < 1%の差

フェーズ3：電源・EMI検証（2025-11-27～28）

必要な実験機器：

  • 電流計（ラボ用電源内蔵or インライン分流抵抗）
  • オシロスコープ（最低100MHz帯域幅）
  • 50Ω終端ネットワーク（RF結合分析用）

測定項目：

  1. 消費電力プロファイリング
  2. WiFi OFF：アイドル時と検出サイクル時の電流
  3. WiFi ON（待機）：WiFi待機状態での電流
  4. WiFi ON（送信）：HTTP応答時のピーク電流

  5. タイムドメイン電流波形ログ（1ms分解能）

  6. 電源レールノイズ解析

  7. VCC波紋をPCB上3箇所で測定（多層ボード想定）
  8. 10kHz～10MHz範囲での共振確認

  9. ESP32データシートのEMC仕様との比較

  10. RF結合性検証

  11. 検出入力ノード周辺のRF場強度測定
  12. スペクトラムアナライザ利用（有れば）
  13. WiFi TX時の2.4GHzピーク場強度記録

フェーズ4：長期安定性テスト（2025-11-28～）

期間：24時間連続運用

テスト構成：

  • esp32dev-wifiファームウェア、WiFi有効状態
  • 定期的なブラウザAPI呼び出し（10秒毎）
  • 宇宙線検出動作（バックグラウンドカウント）
  • メモリリーク、クラッシュ、接続断の監視

成功基準：

  • WiFi切断がない（AP初期ブロードキャスト後）
  • メモリリークなし（暖機後のヒープが安定）
  • 検出動作の安定性維持
  • すべてのAPI応答が一貫

実機検証の成果物

必要なドキュメント：

  • test-results/2025-11-23-build-flags.log - 全フラグ組み合わせのビルドサイズ
  • test-results/2025-11-25-detection-baseline.csv - GPIO/ADC測定（WiFi OFF）
  • test-results/2025-11-25-detection-wifi-idle.csv - GPIO/ADC測定（WiFi待機）
  • test-results/2025-11-25-detection-wifi-traffic.csv - GPIO/ADC測定（API通信中）
  • test-results/2025-11-27-power-profile.csv - 時間軸電流測定
  • test-results/2025-11-27-power-noise.log - VCC波紋解析
  • test-results/2025-11-28-stability-24h.log - 24時間運用ログ

分析レポート：WiFi ON vs OFF性能比較サマリー

Learnings

ビルドフラグアーキテクチャから学んだこと

現在の強み：

  • モジュール型フラグシステムで機能組み合わせが容易
  • platformio.ini環境ベースの設定が整理されている
  • 条件付きコンパイル（#if ENABLE_X）でバイナリ肥大化を防止

識別されたギャップ：

  • フラグのコンパイル影響についてコード内ドキュメント不足
  • フラグ相互作用が形式的に定義されていない（例：STREAM_FORMAT + ENABLE_TIMESTAMP組み合わせ）
  • ランタイム検証機構がない（例：ENABLE_BME280=0時のBME280呼び出し防止）

WiFi評価分析から得た洞察

重要な知見：

  1. EMI/RFリスクは現実的で定量化可能（2.4GHzは<100MHz検出回路に結合可能）
  2. 電源アーキテクチャが重要 - WiFi用と検出用で別レギュレータ推奨
  3. 完全埋め込みHTML（gzip圧縮）戦略は実行可能（26.8%フラッシュで十分余裕）
  4. ハードウェア検証は本番デプロイ前に必須 - シミュレーション代替不可

クリティカルパス項目：

  • WiFiと検出サブシステム間の電源遮断
  • グラウンドプレーン設計（多層PCB＋スター接地）
  • ESP32 WiFiラジオ周辺のRFシールド

Next Steps

直近（2025-11-23～24）

  1. ビルドフラグ監査
  2. CLAUDE.mdにビルドフラグ包括的ドキュメント追加
  3. 全フラグ組み合わせをビルドしてフラッシュ/RAM影響測定

  4. プロジェクトドキュメントにビルドマトリクス表作成

  5. ハードウェアテスト計画最終化

  6. プロジェクトオーナーと利用可能な機器を確認
  7. テストスクリプト準備（GPIO サンプリング、API呼び出し）
  8. 各フェーズの成功/失敗判定基準を定義

短期（2025-11-25～28）

  1. フェーズ1～3ハードウェア検証実施
  2. ベースライン測定（WiFi OFF）収集
  3. WiFi干渉テスト実行

  4. 電源供給安定性測定

  5. ドキュメント・分析

  6. テストデータ解析と比較チャート生成
  7. 発見された問題と対策方法を文書化
  8. ハードウェア検証レポート作成

中期（v1.8.3以降の計画）

  1. 問題発見時の設計改善
  2. ノイズフロア追跡アルゴリズム実装（SNR悪化検出時）
  3. EMIレベルに基づく動的フィルタチューニング

  4. 必要に応じたWiFiラジオのパワーゲーティング

  5. 本番リリース判定基準

  6. 全フラグ組み合わせの検証と文書化完了
  7. ハードウェア検証完了＆許容結果確認
  8. EMI/電源課題が対策or文書化済み
  9. 本番ビルド署名・リリース準備完了