■まぁ〜だやってます（笑）
改めて書くまでもなく、Es予測プログラム（アルゴリズム）の構築にハマってます。
色々とこれを使って、「いつ、どこにEsが居て繋がったり、繋がらなかったのか？、相手には違うエリアが複数同時に聞こえていたのか？」等を分析しています。
と言うか、分析出来ると思ってました。
あ〜でもない、こ〜でもないをやっている中で、どうも理論的に割り切り過ぎた事が仇になってしまった事に気付きました。
■具体的な穴
観測や分析で致命的欠陥だったのは
・中立的ウィンドシア（高度依存）
・重力波の鉛直伝搬と減衰
・E-F coupling（電場・プラズマ輸送）
・電子密度の鉛直勾配背景
・電離層の季節・時刻依存性
・局所的なストリエーション形成（数 km スケール）
これら、6 次元以上の物理モデルを、2 次元の観測量に圧縮して扱ってしまった事。
あくまでも元データはNICTの公開情報。しかも最速15分周期と言う、Es分析にしては粗すぎる分解能です。
その時点で妥協するしか無い、と思ってました。
自信喪失しない様に、流行りのAIにも聴いてみました（家族トラブルじゃないです←ヤメロよ😱）
すると、最初は「技術的妥当性は高い、逆に疑問に感じた点は？」と聞いてきました。
思い切って、自分自分批判（=不備点指摘）をツラツラと書いてみると…
ミヤギKI529の該当ブログ記事は「実測に強いが、学術的厳密性には限界がある」ため、“信頼できる部分”と“注意すべき部分”が明確に分かれる。
と、AI本気モードに入りました。
あなたのモデルは“破綻”ではなく“階層が違う
-
形成機構モデル（物理モデル）ではない
-
観測値ベースの経験則モデルである
-
運用目的には十分使える
-
理論的説明力は限定的
という、正しい階層に位置づければ破綻ではない。
むしろ、 目的に対して適切に簡素化された実用モデルです。
まぁ、フォローはしてくれたので(汗)優しいなぁと思いつつも、指摘はご尤もなので、こっちも本気で仕様を見直しました。
■難しいところは一旦省きます。。。
改定ポイントの目玉は
・中立的ウィンドシアの高度別プロファイルを考慮し、「なぜその高度にEsが出たか？」「なぜ今後効果しそうか？」を説明可能な様に高度別ウィンドシア構造の分析を試みた
・電子密度の鉛直構造を考慮し、「薄く鋭い単層なのか」「広がった厚い層なのか」など、同じfxEs=13MHzだとしても27MHzへの反射特性が異なります。単純な単層だけの考慮を想定しないことを試みた。
・重力波の寄与は、近年の研究で無視できないことがわかっています。（2026年の観測研究でもあり）この情報の扱いは非常に難しいのですが、短周期変動や多層化、局地的急変を説明出来なくなります。ここについても考えてみた。
・E層とF層のカップリングが考慮できていらず伝搬条件の解釈を間違う可能性が高いことに気づきました。簡単に言えば、反射高度とパス長を考える時には、無視して考慮出来ない、となります。
CQ誌にも電波伝搬に関する情報は記載されていますが、全然足りなかったと言うのが現実ということに気づき始めました。
＊「実は中間地点にEsが必ずある訳でもない・・・」、コレが一番言いたかったことかも。
昔から当たり前と思っていることは、実は当たり前じゃない。
■6.0J→7.0J
① 表示仕様
問題
・3行固定で情報量が不足
・数値（詳細）と意味（通常）が分離していて判断しにくい
・「なんでその結論なのか」が画面だけでは分からない
変更
通常表示＋詳細表示 → 統合（一本化）
新構造
1行目：結論（運用判断）
2行目：意味の根拠
3行目：分析指標
4行目：構造（Es高度・層厚など）
5行目：数値背景（[根拠]）
効果
・1画面で「判断＋理由」が完結
・説明可能性向上
② F層表示
問題
そもそもが考慮出来ていなかった
変更
F層影響を計算、わかりやすく影響度指数を小 / 中 / 大へ
効果
・「結果にどれだけ効くか」が直感的に理解できる
・表示の意味が1対1対応になる
③ウィンドシア処理
問題
・実風データが無いと意味不明になりやすい
・内部で何をしているか見えない
変更
風プロファイルあり → profileモード
無し → pseudoモード（明示）
効果
・挙動が完全に明確化
・「ウィンドシア無視してない？」問題を解決
④ 履歴管理
問題
・CSV保存前提（cbm_history.csv）
・起動後だけ使うのに無駄
・ラズベリーパイのSDカード寿命に影響
変更
履歴 = 完全にRAMの
効果
・書き込みゼロ
・再起動でクリーンスタート（6.0Jでは時間が相手も、前回データを分析に使ってしまっていた＝仕様バグですね）
・ラズパイ適合up！
⑤ ログ設計
問題
・毎回prediction_log.csvを書き換え
・データ増加とともに処理負荷増大、ラズパイに限界か？・・・
・SD書き込み過多
変更
ログ = セッション単位 + append方式
さらに：
デフォルト：ログなし
具体的仕様
・csvログデータ化
・セッション単位
・append保存
・メモリバッファあり
効果（主にラズパイ向け最適化）
・SDカード寿命延命
・処理速度安定
・ログ肥大防止
⑥ 運用モデル
問題
・常時稼働前提
・長期ログ前提・・・実際はEsは短命、よく考えたら不要
変更
常時運用 → セッション運用（3時間想定）
効果
・現実の運用に適合
・設計がシンプル化
・データ品質向上（古いデータ排除）
⑦ ログ制御オプション導入
問題
・ログON/OFF制御なし
・開発用途と運用用途が混在
変更
主要オプションコマンド追加：
--log
--nolog
--calibration
--log-on-exit
--log-interval
--tmpfs
効果
運用モード分離
通常運用 → no log
記録運用 → log
校正用 → calibration
⑧ SDカード対策
問題
・15分周期書き込み
・CSV全書き換え
変更
・RAM主体
・append保存
・tmpfs対応
効果
書き込み回数 → 数百分の1
⑨ セッションログ化
問題
・ログが延々と増える
・分析単位が曖昧
変更
ログ = セッション単位ファイル
効果
・3時間単位で完結
・校正・分析が楽
・削除しやすい
⑩ 表示設計変更
旧表示（考え方）
表示 = 表形式
新表示（考え方）
表示 = 推論結果 + 根拠提示
効果
具体的数値と理論検証が一度に出来る
元7.0Jの最大の欠点としたら、単独で動作させているラズパイのLCDが7インチで、老眼により文字が読みにくいことでしょうか（爆）