ATUにバグ有り（プリセットデータを時々間違う）
＜マルチバンドアンテナシステム２＞ATU 自作 ループアンテナ
160mバンドで200W運用が可能になって、2023年の9月に入り、DXシーズンを楽しむぞ！と期待していたら、ATUのプリセットデータを呼び出してもSWRが10を超える事が時々起こります。 特にバンド毎に傾向があり、7MHz以上ではあまり発生しませんが、3.5MHzや1.8MHzで頻度が高くなります。
ATUを降ろし、机上でダミー負荷をつないで試験しても同様に起こります。 どうもプログラムのバグ臭いです。 小手先の対策を行いましたが、異常の頻度は減少するものの、完全には無くなりません。 かくして、今一度原点に戻り、ソースファイルをじっくり見直す事にしました。
見直した結果、以下のバグが発見され、対策しました。
・リレーの駆動は、最初、これからセットしようとするリレー以外をリセットし、次に必要なリレーのみセットする方式になっていましたが、最初、全リレーをリセットし、次に必要なリレーをセットするように変更しました。 また、このリレーの仕様書を入手できたので、リレー駆動時間を仕様書通りの4.5msecに修正しました。 基本的には何も変わらないはずですが、変更後のリレー動作音に大きな差が生じましたので、以前の状態になにかバグが有った可能性があります。
・SWRのディップポイントを探す前に、LとCのリレー番号をゼロから粗いピッチで増加させ、おおまかな整合ポイントを探しにいきますが、このときSWRのリミット値以下を見つけても、粗いサーチ時の限度値（SWR20)以下が見つかったと言うリターン信号しか返していなく、次のルーチンでまた最初からディップポイントを探しており、外付けのSWR計がSWR1.5以下を示すのにサーチが停止しない原因となっていました。
・SWRのディップポイントを探す時、限度値を変更出来るようにしていましたが、一部のルーチンへこの変更された限度値が渡されていなく、常に一番厳しい限度値で判定し、なかなか整合OKになりません。 外付けのSWR計の値が一瞬SWR1.5以下になるのに、整合OKにならない原因のひとつになっていました。
・コントローラー側で6mのラストデータを誤って記憶し、リセットをかけると、データNGで1.8MHzの初期値に戻っていました。
・周波数からEEPROMのアドレスを検索する時利用する周波数スパンリストと周波数センターリストの一部が間違っていました。 一度整合OKで記憶したデータの読出しを周波数を切り替えた時、間違い、電源OFF/ONでラスト周波数を呼び出した時はOKになる原因がこれでした。
これらの対策済みATUをやっと正規の高さまで上げ、チューニングテストをすると、従来よりかなり早くSWR1.5以下に収束するようになりました。 まだ、バグがあるかも知れませんが、当分はこの状態で運用します。 ATUメインユニットの配線図にも誤りがありました。
10月に入ってもATUの調子が思うようにいかず、オリジナルのKT-100の基板をチェックする必要が生じ、なかを見えるように開けてみると、写真のごとくフェライトコアに巻き付けた電線ごと、黒焦げのコアが見つかりました。 多分200Wのリニアアンプにより損傷を受けたとおもわれますが、200W対策をした前の結果なのか、後の結果なのか判りません。 見ての通りコアも銅線も黒焦げですが、ちゃんと正常に動作しています。 ATUの調子が悪いのは、オリジナルのマイコンソケットに差し込んだコネクターの接触不良でした。 接点復活剤とグラグラのコネクター固定ネジをちゃんと閉めたら解決しました。
2023年11月
ATUとアンテナの調子を見る為に、JIDX Phoneに参加してみました。 BAND切り替えを行った時、どのBANDでもATUが最適整合状態にならず、一度電源OFF/ONのリセットでOKになる事が頻発しました。 また、プリセットコール要求OFFの状態で、たまたま、SWR1.05になっている時、TUNEを開始すると、即SWR90となり延々とATUが整合ポイントを探し出すという現象が数回発生しました。 結局、従来からのバグはまだ完全に収束していなく、この対応に悩む事になります。 次の CQ WW CWまでに解決出来るだろうか？
CQ WW CWの二日前の祭日になんとか対策出来ました。 時々SWRが大きくずれる原因はPICの端子からリレー駆動FETへの配線の半田付け不良でした。また、SWRが即90になるのは、マイコンのADC入力端子に接続したLPFのコンデンサでした。 このコンデンサが悪さしていた問題は、こちらで説明しています。
また、ATUのSWR限度値をTUNNING開始する度にランクを下げるようにソフトを組んでいましたが、一番厳しいSWR1.2以下が何度やっても適用されないバグもありました。 さらにCM結合器のバランスの問題で、1.8Mhzや3.5MHzが50Ωのダミー抵抗でもVrefがゼロにならない現象が有りましたので、これはソフトで補正しました。
この日はアンテナを2回も上げ下げし、ATUのソフトを7回も書き換えました。
ATUのデバッグをしながら24MHzで東チモールとソロモン島からのDXペディションをゲット。
CQ WW CWコンテストの当日、1.8MHzから28MHzまでオールバンドで運用しましたが、全部で141局。 その間、バンド切り替えの最初のメモリーデータが間違うという問題は解決していませんでした。
2023年12月
12月に入っても、周波数変更後に呼び出されたプリセットデータが間違っており、ATUの電源をOFF/ONすると正常になるという問題がでていました。 この問題はバンドや周波数に関係なく出ますが、 ATUとコントローラーの通信の時、ATUが決定したEEPROMのアドレスをコントローラー側で確認できるようにしてみましたが、アドレスに間違いがありません。 プログラムを何度もチェックし、間違いは無いのですが。
もう、疑うところは、プリセットデータをEEPROMに記録する関数と、指定のEEPROMアドレスからデータを読み出す関数が正常に動作していないとしか思えません。
いままでのトラブルの中で、関数が受け取った仮引数に関数内での演算の結果を代入すると、動作がおかしくなる場合と異常が発生しない場合とがあり、私の作る関数では、このような演算結果を仮引数の変数に代入しないようにしていましたが、今回の関数では、この仮引数と整数を加算した結果をそのまま次の関数への実引数として与えていました。
例えば次のような記述です。
CTUN = eepdata_read(ead3 + 1);
次の関数呼び出しの実引数である（ead3 + 1）のead3は、この関数が受け取る仮引数そのものです。 このような記述はPIC16FやPIC24F用のプログラムでは多用していましたが、今回のPIC18Fではダメなのかも知れません。 そこで、この引数を一度ead30という変数に代入し、ead31=ead30+1;でead31という変数を作り
CTUN = eepdata_read(ead31);
とりあえず、2日間のデバッグで一度も間違いが起こらなかったので、安心していたのですが、年末年始の休みに入ってしばらくすると、また、同じ現象が起こり始めました。 そこで、あぶなそうなソフトの手直しとXC8とPacksのバージョンアップを行い、様子見です。
XC8 V2.45 Packs PIC18F-K_DFP1.13.292
しかし、変更した2日目にまた同じ現象が発生しました。 ただし、発生頻度はかなり減少していました。 そして、原因がハードかも知れないと思っても、その対策が面倒なので、ここ数か月間はソフトで改善できないかとやってきた事を諦め、ハードのどの部分で発生しているのか、ATUを降ろし、机上で再現テストをすると、ATU本体のリレーの接触不良が原因であるとの証拠をつかみました。 ただ、16個あるリレーのどれがNGなのかは判りません。 どのリレーがNGかは判らないものの、2回連続してリレーをセットすると、99%くらいの確率でOKになります。 今まで、電源OFF/ONでOKになっていたのは、ATU本体の電源立ち上がり時にラストデータを使い、一度リレーをセットした後、約350m秒後に、コントローラーから同じくラストデータが送信され、再度リレーをセットしていましたので、この連続2度セットが接触不良を解消していたことも判りました。 そこで、ATUのリレーをプリセットデータから再セットする時だけ、回数と再セットの時間間隔をコントローラーから指定できるようにプログラムを変更しました。
とりあえずは、リレーは３回連続してセットし、その間隔は200m秒として様子を見る事にします。
2024年1月
対策できたと思ったのは3日間だけ、電源OFF/ONの時とほぼ同じタイミングとなる、間隔360msecでリレーを2回駆動してみましたが、やはり駄目。 接触不良が起こったら、電源をOFF/ONして手動で回復するので、あきらめムードになり、すでに3週間過ぎましたが、最近あまり発生しなくなりました。
以下のファイルは最終状態です。
ATU本体回路図 NB-ATU_main9.pdfをダウンロード
ATU本体 NB-ATU-main_10.cをダウンロード
ATUコントローラー NB-ATU-controller_9.cをダウンロード
本体ヘッダーファイル FREQ_Span8.hをダウンロード
コントローラーヘッダーファイル FREQ_Center8.hをダウンロード
その後の運用実績はこちら。