なんかもう狂ったようにMMANA-GALをいじりまくってるという。
それで、前回までのあらすじは、磁気ループアンテナのシミュレーションをMMANA-GALでやるとどうも今一なので、とりあえず普通のアンテナをシミュレーションしてみようと思ったら、マッチング回路に嵌ってさあ大変。
なので個人用覚書を書いて少々調べたところまで。
その後、マッチング回路の具体例を見るためにMMANA-GALを立ち上げた。ANTフォルダーのなかにいろいろあるけど、Shortっていうのがあるけど何だこれ?開いてみると、変な文字化けしたファイルの他に
Magnetic loopsというフォルダーがあるではないの!
そこを覗いてみると・・・あ~あったよ。MLAが沢山。
なので急遽予定を変更して、マッチング回路は後回しにして磁気ループアンテナのこのファイルを開いて計算しまくってみる。
「ちゃんとSWRさがってるじゃん」 という。
確かに、マッチング回路がこちらでは試してないすばらしい?方式になってるのもあったけれど、でも一部には、こちらで試した形状とほぼ同じなのにまともに動いているのもある。ということは・・・
1. 当然ながら、MMANA-GALでMLAの計算はできる。
2. 一見SWRが下がらないように見えても、調整が非常にシビアなためにディップポイントがわからないだけかも?
ということになった。ここから今回の話が始まる。
--------------
まずこれは、こちらで試した形状とほぼ同じ感じの、MMANA-GALに付属している磁気ループアンテナのファイルを開いたところだ。
寸法の差はあるけれど、形状としてはこのときやったものとそっくりだ。
ならばまず、計算してみようじゃないの。ということでやってみたら、
SWR 1.08 と。
これはすばらしすぎる!
この数字を見てしまったのが運のツキ。必然的にMMANA-GALをいじりまくることに・・・
これがそのときのGeometry.
これの負荷のところにあるCの、
ものすごく微妙な値に注目。
53.672pF を見てしまったら、さっきのような感想が自然に出てくる。
ということは、単に手作業でパラメータを適当に動かしてアタリをつけるなんていう方法ではまぐれ当たりを狙うようなもので、まともな設計は不可能なのは明白。そう思っていじっていると・・・
「最適化」という機能があるみたいな?
でもごらんのとおり、こちらの環境では日本語にすると文字化けして使えない。ググッてみても全くそんな症状は無し。またまたまたまた、
世界で一人だけNG現象が発動だ! これは得意技だからね。あらゆる分野で日常的に経験するよ。詳しくは変人狂人廃人ブログ参照。w
・・・は置いておいて、最適化機能ってわからないので検索した。こちらのサイト様がすばらしい。読んでみて少し理解する。
-------あと、勝手に想像するに、このサイト様の記事が書かれた時代、要するにMMANAが話題になった時代には、作者のJE3HHTさんが一人でやっておられたけど、MMANAのページの最終更新はもう2003年だ。
その後はもう、MMANA-GALになってロシア人?の人とかが主導権をとって開発しているっぽい?ので、日本語なんてまともに見てないんじゃないのか?まあいいや。どうせ世界に一人だし~~~(^o^)/
とはいうもののくやしいので、
MMANAGAL1_2.iniファイルがあったので覗いてみる。
この赤い矢印のところ2箇所に、
Microsoft San Serifというのが見えたので、こういう怪しい臭いがするところは、2箇所ともMS UI Gothicに手で直してsaveしてから再度
MMANA-GALを立ち上げなおすと・・・
この絵のように、上のほうだけ勝手にMicrosoft San Serifに書き直されてしまった。
余計なこと しやがって~(^o^)/.... というわけで、
当然ながらMMANA-GALの文字化けの症状は全く直っていない。
で、MMANA-GALフォルダにある
english.mmnとjapanese.mmnを並べて比べてみたのがこの絵だ。
つまりこういう手間をかけてやれば、全ての英語表記の日本語訳はわかるわけだ。でもこういう手間ってあまりにも馬鹿馬鹿しすぎ。さらには、EmEditorの機能では、違うファイルを並べて表示することはできず、このようにタブ機能をオフにして手で並べないとダメという面倒くささ。
・・・・・・というか、MMANA-GAL / EmEditor両方ともフリーソフトで超高性能ですばらしいんですよね!!!
なので、文句は言わずありがたく使わせていただくわけで、こういうところには深入りしないで次に行く。「日本語がダメなら使わない」という、PCの世界では常識~~~なことをここでも適用するというだけ。
-----
参考サイト様を読んで、少し使い方がわかったので、Optimization機能をいじってみる。
こういうふうに、LoadにCを設定して、50-55pFまで0.002pF刻みでパラメータを動かしてやって、様子を見るというのをやってみようという。
つまり、「最適化」はしないでパラメータスイープをやりたいので、左上にあるNo goal set(simple sweep)にチェックを入れる。
そして「Start」を押してみたのが次の絵だ。
まず、左側の緑色の線のところに、計算結果が流れてくる。今回は2500ポイントもやったので、かなり時間がかかる。
でもどうやら70秒かかって2500点終了したと出たので、赤い矢印の
「Plots」を押してみたのが右のところのグラフだ。
結論から言うと、このプロット機能は、横軸は周波数に固定されている。まあ、「最適化」機能の成果を見るためにある補助機能としてのグラフプロットだから、設計思想的には理解できる。でもこれだと、こちらで意図していた、パラメータによる変化の様子を見ることはできないわけだ。
あとさらに、なんかこう2500点も計算した割には、ずいぶんプロットされている点が少ないんですけど・・・
なので、計算結果をsaveした、.maoファイルを開けてみるか、またはこのように計算直後にそのlogを見てみると・・・
No.の最大値は128.
どうやら、
MMANA-GALの最適化機能のパラメータを動かせる最大個数は128
みたいだ。
なので前に戻って、個数を100個にしてやり直す。
53-54pFの範囲で0.01pF刻みで計算なら大丈夫だろう。
そしてこれが計算結果。さっきと同じ画面だ。
で、違うのはこの後。
MMANA-GALのプロット機能には頼らず、この絵のように赤で示した部分のデータをドラッグしてこの結果全部をコピーペーストして外部のテキストファイルに保存する。
しかしそれを見ると・・・
なんか53.6720から始まってるんですけど・・・
そして上がっていって54まで行った後で、53.6720の1つ下に戻って・・・
そこから今度は下がって、最後の53まで行く。
なんかこう、これがMMANA-GALの仕様みたいな。でもちゃんと100個のデータ自体は正常なので、そういう風に納得して次にいく。
次は、このテキストデータをExcelに入れて、この順番の狂いを直してから自分用にいろいろ整形して、最終的にはグラフにしてみる。
ここまで来るともう、MMANA-GALの機能からは離れて、どういう結果が見たいかという主観の問題だ。
これが最終結果その1.
横軸は負荷のところにあるコンデンサの容量。縦軸は他の全部の量の変化だ。(周波数は前にあったように14.05MHz)つまり、実際にIC-7000MとMFJ-1788を接続して、14.05MHZでMFJ-1788のFINE TUNEボタンを押しているときの状態そのものを表現したグラフになったわけだ。
これが最終結果その2.単なる拡大図だ。
見てのとおり、点々の1つ1つは、バリコン容量を0.01pF単位で変化させたところに対応している。いかに調整がシビアかがグラフ上にデータとして示されたことになる。
というわけで今回はこれにて終了。
それで、前回までのあらすじは、磁気ループアンテナのシミュレーションをMMANA-GALでやるとどうも今一なので、とりあえず普通のアンテナをシミュレーションしてみようと思ったら、マッチング回路に嵌ってさあ大変。
なので個人用覚書を書いて少々調べたところまで。
その後、マッチング回路の具体例を見るためにMMANA-GALを立ち上げた。ANTフォルダーのなかにいろいろあるけど、Shortっていうのがあるけど何だこれ?開いてみると、変な文字化けしたファイルの他に
Magnetic loopsというフォルダーがあるではないの!
そこを覗いてみると・・・あ~あったよ。MLAが沢山。
なので急遽予定を変更して、マッチング回路は後回しにして磁気ループアンテナのこのファイルを開いて計算しまくってみる。
「ちゃんとSWRさがってるじゃん」 という。
確かに、マッチング回路がこちらでは試してないすばらしい?方式になってるのもあったけれど、でも一部には、こちらで試した形状とほぼ同じなのにまともに動いているのもある。ということは・・・
1. 当然ながら、MMANA-GALでMLAの計算はできる。
2. 一見SWRが下がらないように見えても、調整が非常にシビアなためにディップポイントがわからないだけかも?
ということになった。ここから今回の話が始まる。
--------------
まずこれは、こちらで試した形状とほぼ同じ感じの、MMANA-GALに付属している磁気ループアンテナのファイルを開いたところだ。
寸法の差はあるけれど、形状としてはこのときやったものとそっくりだ。
ならばまず、計算してみようじゃないの。ということでやってみたら、
SWR 1.08 と。
これはすばらしすぎる!
この数字を見てしまったのが運のツキ。必然的にMMANA-GALをいじりまくることに・・・
これがそのときのGeometry.
これの負荷のところにあるCの、
ものすごく微妙な値に注目。
53.672pF を見てしまったら、さっきのような感想が自然に出てくる。
ということは、単に手作業でパラメータを適当に動かしてアタリをつけるなんていう方法ではまぐれ当たりを狙うようなもので、まともな設計は不可能なのは明白。そう思っていじっていると・・・
「最適化」という機能があるみたいな?
でもごらんのとおり、こちらの環境では日本語にすると文字化けして使えない。ググッてみても全くそんな症状は無し。またまたまたまた、
世界で一人だけNG現象が発動だ! これは得意技だからね。あらゆる分野で日常的に経験するよ。詳しくは変人狂人廃人ブログ参照。w
・・・は置いておいて、最適化機能ってわからないので検索した。こちらのサイト様がすばらしい。読んでみて少し理解する。
-------あと、勝手に想像するに、このサイト様の記事が書かれた時代、要するにMMANAが話題になった時代には、作者のJE3HHTさんが一人でやっておられたけど、MMANAのページの最終更新はもう2003年だ。
その後はもう、MMANA-GALになってロシア人?の人とかが主導権をとって開発しているっぽい?ので、日本語なんてまともに見てないんじゃないのか?まあいいや。どうせ世界に一人だし~~~(^o^)/
とはいうもののくやしいので、
MMANAGAL1_2.iniファイルがあったので覗いてみる。
この赤い矢印のところ2箇所に、
Microsoft San Serifというのが見えたので、こういう怪しい臭いがするところは、2箇所ともMS UI Gothicに手で直してsaveしてから再度
MMANA-GALを立ち上げなおすと・・・
この絵のように、上のほうだけ勝手にMicrosoft San Serifに書き直されてしまった。
余計なこと しやがって~(^o^)/.... というわけで、
当然ながらMMANA-GALの文字化けの症状は全く直っていない。
で、MMANA-GALフォルダにある
english.mmnとjapanese.mmnを並べて比べてみたのがこの絵だ。
つまりこういう手間をかけてやれば、全ての英語表記の日本語訳はわかるわけだ。でもこういう手間ってあまりにも馬鹿馬鹿しすぎ。さらには、EmEditorの機能では、違うファイルを並べて表示することはできず、このようにタブ機能をオフにして手で並べないとダメという面倒くささ。
・・・・・・というか、MMANA-GAL / EmEditor両方ともフリーソフトで超高性能ですばらしいんですよね!!!
なので、文句は言わずありがたく使わせていただくわけで、こういうところには深入りしないで次に行く。「日本語がダメなら使わない」という、PCの世界では常識~~~なことをここでも適用するというだけ。
-----
参考サイト様を読んで、少し使い方がわかったので、Optimization機能をいじってみる。
こういうふうに、LoadにCを設定して、50-55pFまで0.002pF刻みでパラメータを動かしてやって、様子を見るというのをやってみようという。
つまり、「最適化」はしないでパラメータスイープをやりたいので、左上にあるNo goal set(simple sweep)にチェックを入れる。
そして「Start」を押してみたのが次の絵だ。
まず、左側の緑色の線のところに、計算結果が流れてくる。今回は2500ポイントもやったので、かなり時間がかかる。
でもどうやら70秒かかって2500点終了したと出たので、赤い矢印の
「Plots」を押してみたのが右のところのグラフだ。
結論から言うと、このプロット機能は、横軸は周波数に固定されている。まあ、「最適化」機能の成果を見るためにある補助機能としてのグラフプロットだから、設計思想的には理解できる。でもこれだと、こちらで意図していた、パラメータによる変化の様子を見ることはできないわけだ。
あとさらに、なんかこう2500点も計算した割には、ずいぶんプロットされている点が少ないんですけど・・・
なので、計算結果をsaveした、.maoファイルを開けてみるか、またはこのように計算直後にそのlogを見てみると・・・
No.の最大値は128.
どうやら、
MMANA-GALの最適化機能のパラメータを動かせる最大個数は128
みたいだ。
なので前に戻って、個数を100個にしてやり直す。
53-54pFの範囲で0.01pF刻みで計算なら大丈夫だろう。
そしてこれが計算結果。さっきと同じ画面だ。
で、違うのはこの後。
MMANA-GALのプロット機能には頼らず、この絵のように赤で示した部分のデータをドラッグしてこの結果全部をコピーペーストして外部のテキストファイルに保存する。
しかしそれを見ると・・・
なんか53.6720から始まってるんですけど・・・
そして上がっていって54まで行った後で、53.6720の1つ下に戻って・・・
そこから今度は下がって、最後の53まで行く。
なんかこう、これがMMANA-GALの仕様みたいな。でもちゃんと100個のデータ自体は正常なので、そういう風に納得して次にいく。
次は、このテキストデータをExcelに入れて、この順番の狂いを直してから自分用にいろいろ整形して、最終的にはグラフにしてみる。
ここまで来るともう、MMANA-GALの機能からは離れて、どういう結果が見たいかという主観の問題だ。
これが最終結果その1.
横軸は負荷のところにあるコンデンサの容量。縦軸は他の全部の量の変化だ。(周波数は前にあったように14.05MHz)つまり、実際にIC-7000MとMFJ-1788を接続して、14.05MHZでMFJ-1788のFINE TUNEボタンを押しているときの状態そのものを表現したグラフになったわけだ。
これが最終結果その2.単なる拡大図だ。
見てのとおり、点々の1つ1つは、バリコン容量を0.01pF単位で変化させたところに対応している。いかに調整がシビアかがグラフ上にデータとして示されたことになる。
というわけで今回はこれにて終了。