２００６年１１月

改訂：2006/11/28

2006/11　WinDRM-Voice テスト(受信)

　WinDRM による Voice 交信のテスト で、WinDRM-Voice の受信体制は整っていたのですが、実際の交信テストをやられると言う情報があったので、送信はできませんが、受信だけ参加しました。

　実際の交信は、144MHzにおいて16QAMで行われました。　WinDRM-Voiceで送られるデジタル化された音声をデコードしたものは、独特の音声をしています。　下に、WinSpectra　で、40回サンプリングの平均値表示にした、通常のJ3Eによる交信音声の周波数特性（左下）と、WinDRM-VoiceによるG1Eによる交信音声の周波数特性（右下）を示します。　なお、音声データは同じ局のものです。

　左下の通常のJ3Eによる交信音声の周波数特性は送信側のフィルタ特性＋受信側のフィルタ特性が効いて、300Hzぐらいから下、および、2700Hzぐらいから上はカットされています。フィルタ帯域内は送信側の音声・マイク・イコライザの特性が効いているものと思われます。

　右下のWinDRM-VoiceによるG1Eによる交信音声の周波数特性はこれらフィルタ特性の影響はほとんど受けていないようです。　下限・上限の周波数は送信側のエンコード方式による影響が一番大きいと思われます。全体のエネルギーは左の特性に比べて、ずいぶん低域に移動しているように思います。通常の交信を、このような,100-300Hzの多い特性で行うと、モガモガした音声に聞こえるのですが、実際の交信を聞いてみると、むしろ、通常の音声に近い感じがして、モガモガ感はありません。　レベルは落ちてはいるものの、結構、高域まで伸びて出ているのが影響しているのでしょうか？

　64QAMでやったらどうなるか興味がわいてきます。　帯域が広くなる（はず）のでもう少し高域が延びるかも？

2006/11　オンエア各局のIQパターン

　WinDRM による Voice 交信のテスト で、WinDRMに IQ パターンの表示機能があることがわかったので、お空に出ている各局の IQ パターンと EasyPal の Quality 表示の関係をとってみました。　いずれの信号も 16QAM で 4x4 のパターンです。

　下の写真は、7MHz にオンエアしている各局の IQ パターンです。
　左はかなり弱い信号で、Quality がこのレベルでは、MSC まで点かないことが多く、復号できない場合が多いです。
　真ん中は、Quality が 16-18% で、このレベルになるとエラー無く復号することができるようです。
　右は、かなり Quality が高い信号で、これなら完璧です。

　こんどは、144MHz にオンエアしている各局の IQ パターンです。
　左はかなり弱い信号で、Quality がこのレベルでは、7MHz と同じように、MSC まで点かないことが多く、復号できない場合が多いです。
　真ん中は、Quality が 15-18% で、7MHz の場合よりもパターンがかなり乱れていますが、エラー無く復号することができていました。
　右は、144MHz としては、かなり Quality が高い信号で、これぐらいなら問題なく復号できます。

　総じて、7MHz よりも 144MHz のほうがパターンの純度が悪いように感じます。　やはり周波数が高いほうが、位相成分に対する精度保持が難しいのでしょうか？

2006/11　WinDRM による Voice 交信のテスト

　EasyPal や WSJT6 の交信 に続き、デジタルモードでの音声伝送のテストを行いました。　まさか、デジタルで音声伝送をしようとは思っていませんでしたので、デジタル音声方式の免許指定事項変更まではしていませんので、とりあえずは、送信パワーを最小のLにセットして、ダミーロードを使って、室内での対向試験です。

　下のブロック図は、この対向試験の構成図です。　EasyPal や WSJT6 の試験とほぼ同じですが、違うところは、アプリソフトとして WinDRM を二つ立ち上げていること、オーディオインタフェースとして、従来の TX用、RX用の二つに加えて Voice用にもう一つの合計三つを使っていることです。　Voice用のオーディオインタフェースからはマイクとヘッドフォーンの付いたパソコン用のヘッドセットに接続しています。
　なお、この構成は、通常の交信でも二つのサウンドデバイスを使います。　サウンドデバイスを一つでやる場合は、サウンドアウトの後にTXへ行く信号と、ヘッドフォーンへ行く信号を切り替える回路、および、サウンドインの前にRXからの信号と、マイクからの信号を切り替える回路、の二つの切替回路が必要になると思います。　最近は、サウンドデバイスも安いので、PTT信号で切換回路を作るよりも、サウンドデバイスを二つ用意したほうが手軽かもしれません。

　下の写真は、実際に Voice を WinDRM の 16QAM で送信して、もう一つの WinDRM で受信している時の画面の様子です。　左上が送信側の WinDRM、右上がマイクのレベルコントロール、左下が受信用の WinDRM、右下がヘッドフォーンのレベルコントロール画面です。
　送信側の WinDRM の TX Voice ボタンをクリックすると、受信側の WinDRM の左側にある ID、Freq、Time、Frame、FAC、MSC が順番に点灯して、画面には 16QAM の IQ パターンがきれいに表示されます。これだけきれいに分離されていると、復号は問題ないでしょう。
　この写真は、マイクに向かって「あ〜」と言う声を入れた時ですが、受信側のヘッドフォーンからは、約4秒後に「あ〜」と聞こえてきます。　音質は「まあまあ」でしょうか？　携帯電話並みの音質とでも言いましょうか。

　WinDRM による Voice 伝送は 4QAM は使えないようで、16QAM と 64QAM だけのようです。リアルタイムで送るには伝送量が足りないのでしょうか？
　下の写真は、64QAM のときの写真です。　IQ パターンは本来なら 8x8 になるはずですが、結構ぼやけていて、ちょっと目を離してみたら、8x8 に見えなくも無いかなぁと言った感じです。　しかし、これだけぼやけていても、十分な精度で復号してくれているようです。　16QAM の時と同じように、約4秒後に「あ〜」と言う声が聞こえてきます。
　とりあえず、これで、室内実験は問題ないようですので、後は、お空に出るためには、変更申請を急ぐ必要があります。

【補足】

　64QAM の時 IQ パターンがぼやけていたのは、信号レベルが低過ぎたからの様でした。　信号レベルを少し上げると、以下のようにきれいな 8x8 の IQ パターンになりました。
　また、変調レベルによって、IQパターンの純度（ぼやけ具合）はあまり変わらないようです。　極端に変調レベルを下げたり、極端に変調レベルを上げた時にぼやけるようです。
　EasyPal の Quality はこの純度を表しているのかと想像していたのですが、関係は良くわかりません。　心なしか EasyPal よりも変調レベルに対する許容度が大きいように感じます。　復号方式が違うのかもしれません。

2006/11　EasyPal-64QAM

　EasyPal の特性測定・その2 で、変調方式によるファイルサイズの違いをグラフで示しましたが、通常の交信では16QAMが良く使われているようです。　64QAMは通信時間の面では断然有利ですが、おそらく、ノイズやQSBには弱いだろうと想像できます。　でも、最近交信している144MHzでは、ノイズはそれほどありませんし、地上波の範囲ではQSBもほとんどありませんので、64QAMをテストしてみました。
　下の写真は、実際に交信した時の写真で、30kmほど離れた局との交信です。　伝送時間が47秒と出ています。　16QAMでは68秒かかりますので、70%弱の時間で送ることが出来ます。　エラー無く送ることが出来れば、同じファイルサイズ(15kB)ですので、当然ながら、受信側では、どの変調方式でも、同じ画質を得ることが出来ます。　同じ画像を送った時の受信側のQuality表示は、相手局のレポートによると、4QAMの時で44%、16QAMの時で41%、64QAMの時で46%と遜色なく送れる様です。　但し、エラーになって、再送をすることになれば、せっかく短縮しようと思った伝送時間が余計に掛かってしまいますので、何をやっているかわからないことになってしまいます。
　この変調方式は、受信側は自動的に対応しますので、送信側の意思でその時の電波状況に応じて、4QAMか16QAMか64QAMの最適なものを選択して送れば良いと思います。
　同じようにバンド幅も、2.3kHzか2.5kHzの選択ができますが、こちらは、ほとんどの相手局は2.5kHz帯域が受信できると思いますので、よほど狭帯域で受信している相手局の場合を除き、わざわざ、時間のかかる2.3kHzを使うことはないと思います。

2006/11　WSJT6 の初交信

　一方、WSJT6 の特性測定・運用 で、調整は済んでいたのですが、交信はまだ出来ていませんでした。　ある日、IC-706MKIIGのパワーを最小のLに設定して試験していたところ、突然、ピロピロと応答があり、30秒後には、メイン画面に相手のコールサインが見事に復号されて表示されました。「おっとっと」と言うことで、慌てて、相手のコールサインを入力し、テストした時の手順 で順番に応答していきました。30秒毎のリターンで、こちらが送信し始めてから、前回の受信内容が復号されるので、ちょっとまどろっこしいですが、あっけなくWSJT6の初交信が出来ちゃいました。　下の写真はその時のWSJT6のメインウィンドウの記録です。　独特の交信方法で、いまいち、内容のわからないところもありますが、画面がかっこいいし、久しぶりの新しい方式の交信で興奮しました。

2006/11　WSJT6 の特性測定・運用

　EasyPal の特性測定・運用　および　EasyPal の特性測定・その2　で、手を付けるのが遅れましたが、　EasyPal の特性測定・運用　と、ほぼ同じ構成で、WSJT6 を2つ立ち上げて、一方を送信用に、もう一方を受信用に使い、主として、送信の変調レベル、受信のレベル調整の特性測定、および、運用のシュミレーションをしてみました。

　最初は、FSK441モードで試してみました。　4つの画面が出るので、ディスプレイ一杯に表示しても、重なってしまいます。　下の画面は、全画面をキャプチャしたところで、右側が送信側のWSJT6で、左側が受信側のWSJT6です。
　送信レベルはそれほどクリティカルではなく、マニュアルでも、多少ALCが振れる状態でも良いと記述されています。　私は、EasyPalと同じレベルで試してみました。　3-Toneの基準信号でS7のレベルです。　それでも送信中は、Ｓの目盛で20〜30dBの位置までメーターが振ります。
　一方、受信側は、結構クリティカルで、IC-756PROのATT=18dBにして一番絞った状態でさらに、WSJT6のレベルを調整して、信号表示がわずかに出るぐらいの状態で、綺麗に受信できました。

　次はJT6Mモードです、送信レベル、受信レベルほぼ同じ位置で受信できます。

　こちらはJT65Aモードです、こちらも、送信レベル、受信レベルほぼ同じ位置で受信できます。
　なお、マニュアルによれば、無信号状態で、RX_Noiseレベルを、0dBに合わせると書いてありますが、実験の接続では、ノイズレベルが低いので、その通りには行きませんでした。　手探りで、レベル調整して、良さそうなところに設定しています。

2006/11　EasyPal の特性測定・その2

　EasyPal の特性測定・運用をお空で話していたところ、「周波数の変動に対してはどうなのか？」と言う話題になりました。　その他、EasyPal/HamPal には、詳しいマニュアルが無いので、疑問になる点が多く、追加の特性測定をしてみることにしました。　測定時の構成も前回に比べて、受信側を変えてみました。　前回は、送信をEasyPalで、受信をHamPalでやっていましたが、今回は、EasyPalを2つ立ち上げて、一方を送信用に、もう一方を受信用に使い、受信側は、EasyPalとHamPalの２本立てで実験することにしました。　下は、その構成図です。

　まず、送信側の周波数を固定し、受信側の周波数を可変して、Qualityがどのように変化するかを実験してみました。
　テスト用の画像・送信モードは、前回と同じで、テストパターンを 10kB・50秒で取り込み、
B-Mode, 16-QAM, Bandwidth=2.5kHz, Error Protect=Normal, Interleave=Long, Tx Instance=1、
でテストしました。
　左下のグラフはその結果で、以外と単純なデジタル的な結果になりました
�@　同期は中心周波数からほぼプラマイ100Hzで引き込むようです。
�A　一度同期に引き込むと、プラマイ350Hz程度までは、同期がはずれないようです。
�B　あまり急激に周波数を変えると、上記の350Hz以内でも、同期がはずれるようです。
�C　周波数をゆっくり上昇（青矢印）、下降（赤矢印）させると、ヒステリシスを描きます。
�D　一度、同期に入れば、Qualityは測定誤差範囲内で安定しています。
�E　HamPalの時はQualityが20だけ大きな値を示す以外は、EasyPalとほぼ同じ動作をします。
　なお、上記の実験では、受信用のIC-756PROはFilterを3.0kHz（USBでは最大設定）に設定していますが、予想以上に同期に引き込まれる範囲が広かったので、端の方ではFilterの影響が出ているかもしれません。
　実際のチューニングでは、Tuneの3-Tone信号を三つの緑色のマーカーに合わせ込むのですが、WaterFall画面の一番左の緑色のマーカーと、更にその左の小さな黄色のマーカーとの間が220Hz程あるようですので、このマーカー間の半分より少し狭いぐらいまでの確度で合わせ込んでいれば、チューニングは大丈夫と言うことになります。

　次に、画像の種類によるQualityや送信時間の変化を実験してみました。
　画像は、右下にある4種類を使ってみました。　�@上の実験で使ったテストパターン、�A青系の強い雪景色の山小屋、�B女性のポートレイト、�C赤系の強い苺の写真、の4種類です。　画像の取り込み・送信モードは上と同じで、テスト画像を 10kB・50秒で取り込み、
B-Mode, 16-QAM, Bandwidth=2.5kHz, Error Protect=Normal, Interleave=Long, Tx Instance=1、
でテストしました。
　こちらの結果も何とも単純な結果になりました。
�@　画像種類に関係なく、10kB、50秒になるので、画像の種類によって圧縮率（＝画像品質）を変えている様です。
�A　Qualityは画像の種類に関係なく、60〜62程度で、測定誤差範囲内で安定しています。
�B　画像の四隅にコールサイン等の文字を入れても、Qualityは、60〜62程度で、変わりません。
　後から考えたら、当たり前のことで、骨折り損でした。

　前回の測定で、実際にお空に出ている局のQualityは、まだ7局と測定データが少ないのですが、10〜36 に分布していました。　また、上記と同じ状態で、かなり低い変調レベルに調整してある私の信号を、S7ぐらいの信号強度で受信した場合、Qualityが 42〜43 というレポートもあります。　今回の測定での Qualityは 60〜62 と結構高い数値です。　従って、Quality 20% 程度は空中の伝送路上で悪化しているものと思われます。　16QAM ですので、直交性を保ったまま、振幅成分4値を維持して送るのは大変だと思います。

　なお、測定中に気づいたのですが、IC706MKIIGは、連続で送信動作をさせると、温度上昇と共に、結構QRHと出力の変化があるようです。
　温度上昇に付いては、以前に動作時温度変化(706)で測定していますが、今回、かなりの、連続送信でケース上側の温度が45℃ぐらいまで上がっていました。　中はもっと熱くなっていると思います。　平均電力はそれほど出ていないので、45℃でまで上昇すると、そこで安定してそれ以上は上がりません。　送信を止めると7℃ほど下がって、38℃で安定しています。
　QRHについては、温度が上がると、だらだらと約100Hzほど下側にずれて、温度が戻ると、また上昇して、元に戻る様です。　IC706MKIIGの周波数安定度の仕様が、0〜50℃で5ppmですので、144MHzだと720Hzまでは仕様範囲内の様です。
　パワーの方は、目盛りでS7で調整していた物が、目盛りのS6ぐらいまで下がる様です。　これも、温度が下がれば、元に戻るようです。

【補足（送信時間vsファイルサイズ、送信時間vs各種パラメータ）】

　ついでに、送信時間vsファイルサイズの特性、および、送信時間VS各種パラメータの特性をグラフにして見ました。　各種パラメータのグラフは、あまりに膨大なデータになるので、ファイルサイズが15kBの時のみにしてあります。　各パラメータについて、ファイルサイズに対する傾向は、左のグラフと同じ傾向を示します。

【補足（連続送信時の温度上昇）】

　別の日に、温度上昇の様子を測定してみました。
　この日は、先日の測定の日よりも、かなり気温が低くて、2〜3℃低く出ています。　温度測定はIC-70MKIIGの上蓋の上にセンサーを置いて測定しています。　電源を入れて、受信状態においていますと、1時間半ほどで温度が36℃ぐらいで安定するようです。　その後、変調レベルが42の位置でEasyPalの連続送信をすると42℃ぐらいまで上がった後は、連続送信し続けてもそれ以上の温度上昇はないようです。

　連続送信をやめると、温度が下がりまた安定します。　次に、変調レベル84の位置でMMSSTVの連続送信をすると46℃ぐらいまで上がった後安定し、更に連続送信してもそれ以上の温度上昇はないようです。　やはり、MMSSTVのほうが平均電力が大きいのか、温度上昇も大きいようです。　逆に言うと、EasyPalはかなり平均電力の小さいレベルで、軽く使っているようです。

2006/11　EasyPal の特性測定・運用

　一時は SSTV に、はまっていましたが、このところ、デジタルモードの画像通信に、はまっています。　EasyPal と言うのがリリースされてこれが結構、面白いです。　このソフトウエアは、欧米人が作った割には、マニュアルが整備されていません。　結構、膨大な機能が盛り込まれている様なのですが、とりあえず、簡単なテキストファイルの説明が有るだけで、皆さん、手探りで調整・運用されているようです。　せっかくの貴重な機能がもったいない気がします。　まあ、フリーで使わせていただいているわけですから、文句は言えないですし、作者の好みも有るのでしょう。　こういったフリーソフトの場合、ユーザーの立場からマニュアル・ノウハウなどサポートしてあげるのが、フリーソフトユーザーの責任でしょうか？

　ところで、実は、以前に PC-TRX-IF（汎用の PC-トランシーバ・インタフェース） を作った時に、免許の指定事項・無線設備は変更していたので、電波を出すのには問題無いのですが、7033Hz のデジタルモードには、ちょっと出る勇気が無かったので、長い間、モニターだけしていたのです。　最近、144MHz をワッチしていると、結構、アクティブに出ておられる方がいる様なので、144MHz で交信にトライしてみました。　一応、事前に、入念に調整していたので、問題無いレベルの画像の送受が出来ました。

　さて、その調整なのですが、私は、トランシーバを２台使って、１台は送信に、１台は受信・モニターに使って、ＰＣも、２つのサウンドカードを使って、送信レベルの調整を行い、ついでに、EasyPal の動作特性を取ってみました。

�@パソコンは一台のパソコンに送信用として EasyPal を、受信用として HamPal を同時に起動して使ってみました。　EasyPal を多重起動して動作させることも出来るようですが、I/O ポートや、データファイルがゴチャゴチャになりそうな気がしたので、別のアプリにしてみました。
�Aサウンドインタフェースは、送信用には PC-TRX-IF に内蔵させている C-Media USB Audio Interface を、受信用には Sound Station USB Audio Interface を使っています。
�B送信機には通常の 144MHz の交信に使う IC-706MKIIG を使い、ダミーロードをつないでいます。
�C受信機には IC-756PRO + FTV-107 の構成に同軸スイッチをオフ状態で接続しています
　また、調整用のトーンなどが準備されていないので、WaveGen と言うアプリで、調整用の Wav ファイルも作ってみました。

EasyPal 調整用 Wav ファイル（LZH圧縮、6,071kB）

　このアーカイブには二つのファイルが入っています
�@ Wave_3-Tone_Sweep_-10.wav
　これは、変調レベルのレファレンス用に使います。　EasyPal に付いている Tune と同じ 3-Tone を5秒、300Hz-2500Hz のスイープを5秒、2500Hz-300Hz のスイープを5秒、最後にまた 3-Tone を5秒の構成になっています。　レベルは、WaveGen で 3-Tone でも歪まない最大レベルで -10dB（WaveGen 基準）にして居ます。
�A Wave_3-Tone_Sweep_-24.wav
　�@と同じ構成ですが、通常の交信でも使えるように、レベルを -24dB にして、EasyPal に付いている Tune とほぼ同じレベルにしています。

　さて、特性の測定ですが、以下の方法で測定しています。
�@上記の�@の -10dB 信号の 3-Tone 部分を使い、IC-706MKIIG のレベルメーターのパワー表示値を読みとって、変調レベルのレファレンスとしています。　レベルメーターは、Ｓの表示を読みとって、Ｓが一つあたり 6dB で換算しています。　この変調レベルが、左下のグラフの横軸になっています。
�Aテスト用の画像を送信し、HamPal で受信して最高の Quality % を表示した時の値を、Quality %（緑）で表示しています。 大体の場合は全データを受信し終える直前が最高の Quality % になります。　なお、グラフで表示している Quality % は、下で述べる、HamPal/EasyPal Quality 換算により、EasyPal Quality % として表示しています。
�Bテスト用画像を送信しているときの、IC-706MKIIG のパワーレベル値を、送信時 Po 表示（青）で表示しています。
�Cテスト用画像を送信しているときの、IC-756PRO のＳメーター値を、受信時Ｓ表示（赤）で表示しています。なお、この値もＳが一つあたり 6dB で換算しています。　なお、この時、IC-756PRO の ATT は -12dB にセットしています。

　以上で、測定した特性が左下のグラフです。　通常の SSTV の場合は変調レベルは横軸で 84 の位置です。　この位置で、SSTV の 1750Hz シングルトーンで、コンプレッサ OFF で、ALC が振れる直前のレベルです。　これから見ると、EasyPal の場合はかなりレベルを下げた位置に Quality 最高の位置が有ります。　パワーレベルはほとんど振れない位置です。　あまりレベルを下げすぎると、今度は受信側の問題により、Quality が下がってくるようです。Quality も、信号強度もそこそこのレベルは横軸で42あたり、レファレンス調整レベルでＳ７あたり、通常の送信では表示がＳ２（LED表示3個分）ぐらいの様です。SSTV の信号レベルに比べたら 1/10 以下です。

　右下のグラフは、受信信号レベルに対する、Quality の変化の様子です。　変調レベルは、左下のグラフで 42 の位置にセットして、IC-756PRO の ATT を調整してＳの変化と Quality の変化を測定した物です。　横軸が -12 の位置で、Ｓの表示が９です。　これより信号が落ちると、Quality の方も悪化するようです。

　以上、かなりラフな測定データで、絶対値での判定は出来ませんが、送信変調レベルと Quality、および、受信信号レベルと Quality の関係が、傾向だけは分かったような気がします。

【補足】

　WinDRM の資料 The adjustment of transmitter power for HamDRM.pdf によれば、DRM 信号のピークパワーと実効値パワーは 8:1、9dB になるそうです。　したがって、通常のトランシーバについているパワー計が実効値を示しているとすれば、シングルトーンで 100W で ALC が効き始めるように調整されている場合には、DRM のときは 12.5W 以上のパワーを出すとピークでは歪んでいることになるようです。

　また、簡単な調整法は、tune 信号でウオーターフォールに 725、1475、1850Hz の 3Tone 以外に相互変調歪みの成分 325、1100、2225、2600Hz が現れないように、パワーを絞って行くことだそうです。　送信部のリニアリティが悪い場合は、相互変調歪み成分を消しきれないこともあるようです。

　テスト用の画像は、測定時間を短縮するために、左下の画像（実サイズは 640x480、お空で流れていた画像を、コールサイン・名前を変えて使わせてもらいました。）を EasyPal で 10kB・50秒で取り込み、EasyPal の送信モードは、
B-Mode, 16-QAM, Bandwidth=2.5kHz, Error Protect=Normal, Interleave=Long, Tx Instance=1、
で実行しています。
　右下は、EasyPal と HamPal で同時に同じ局の信号を受信したときの、Quality % の相関（散布図）です。 HamPal の Quality % と EasyPal の Quality % の換算は以下の一次式で表されるようです。
[EasyPal Quality %] = [HamPal Quality %] - 20
　なぜ、EasyPal と HamPal で Quality % の表示が違うのかは不明です。
　実際にお空に出ている7局分の Quality % はこのグラフのように、EasyPal で10〜36、HamPal で30〜56に分布していました。

2006/11　HamSを Ver 3.20a にアップ

　HamS が Ver3.20a にバージョンアップ公開されました。　ほとんどはバグフィックスのバージョンアップです。　バージョンアップ手法に付いては作者のＨＰに詳しく記述されていますので、その通りに実行すれば問題なく新しいバージョンに更新されます。
　バグフィックス以外に、マイナーですが、いくつかの機能アップも図られています。　その中では、連続検索の複数行貼付が便利で、出色の出来です。　今までとは、効率が全然違います。　また、検索後の待ち時間も従来より短縮されていますので、ちょうど次の操作をしている間に待ち時間が終わってしまうぐらいの感覚です。
　Ver 3.20の時の三つの不具合も解決されているようです。
　第一の「総務省ＨＰデータ読み込みがうまくいかない。」は、前のバージョンがネット関係で「ギクシャク」と立ち上がったのに比べ、非常にスムーズに立ち上がります。今のところ、立ち上がりで一度も失敗したことはありません。
　第二の「起動時に機能設定がクリアされてしまう。」も今のところ大丈夫のようです。
　第三の「EXPポイントのP10が頻繁に変化し不安定な事。」は、前と違って、今のところ、一度も変化していません。　また、他のポイントも含め、立ち上がった後も、リアルタイムにポイントの変化が、基本情報４に反映されて表示されるので、何となく安心感が有ります。

　我が家のネットワーク環境は必ずしも良くはなく、ADSLであるのに、かなり遅いのですが、総じて、前のバージョンとは別物のソフトの様に安定して動作しています。



　ところで、色々操作していくうちに、「復元」に関して、動作の不具合な時があるのに気が付きました。　Ver3.20以前から内在していたのかもしれませんが、このところ、データの修復でよく使うので気づきました。
　不具合の内容は、復元動作をさせると、２〜３回に１回はハングアップ（したような）状態になります。

　左下は、正常終了のダイアログを表示したまま、マウスクリックを受け付けない状況です。　復元自体は、終了しているようです。立ち上げ直すと、データは復元しているように見えます。

　右下は、データ復元中のダイアログを表示したまま、マウスクリックを受け付けない状況です。　復元自体は、終了しているようです。立ち上げ直すと、データは復元しているように見えます。

　左下は、上記の二つの場合に、タスクマネージャで、強制的にタスクを終了を選択したときのメッセージ画面です。　なお、JAVAは バージョン 1.5.0 (ビルド 1.5.0_09-b03) になっています。

　右下は、別の症状ですが、正常に終了したときでも、このようにツールバーのアイコンがアクティブになっていない時が有ります。　この時、環境設定を選択して、環境設定のダイアログが表示された瞬間に、ツールバーのアイコンがアクティブになります。

　ところで、現状では退避は常に「BACKUP.DAT」に退避されて、古い退避データは、上書きされているようです。　最新バージョンは安定しているので、あまり失敗は有りませんが、退避するときに、異常状態になっているのを気づかずに退避すると、蓄積されていたデータが台無しになってしまいます。　特に、機能チェックがクリアされているときに、間違って、退避をクリックしてしまい、データが台無しになった痛い経験が有ります。

　そこで、私は、退避する度に「BACKUP.DAT」をコピーして「0611041209_BACKUP.DAT」の様な名前を付けて、日時付き退避データが残るようにしています。　復元の時は、希望の日時のデータを、「BACKUP.DAT」にリネームして使用しています。　但し、Ver3.12--->Ver3.20の時は、バージョン間のデータに互換性が無く、バージョンアップにも失敗して痛い目に遭いました。　バージョン間の互換性が無くなるときは、変換ツールを提供していただくと助かるのですが、今後に期待しましょう。

　なお、上記の障害と、バックアップの日付管理は、作者に報告＆提案済みです。

現在位置：　トップ > アマチュア無線 > ２００６年１１月