Backyさん御製作のツールJDEM_AUTOで作る５ｍメッシュシーナリー。
昨日はバイキュービック３倍補間で猿山灯台付近を作ってみたが、今日はさらにFractionBitsを３に設定して作ってみた。
昨日のはFractionBits=0で、高さ方向は１mの分解能だったが、今日はFractionBits=3に設定したので、高さ方向は 0,125mの分解能である。
Bicubic=3で作った昨日は、一部地形に新たな盛り上がりがあったので、FractionBits=3でも、細かな標高変化を期待したが、残念ながらこの場所では変化を発見することは出来なかった。
灯台の近傍で、僅かな標高の変化は確認できたが、灯台が置いてなかったら認識できないくらいの変化だった。
しかし飛行してみての全体的な印象では、何となくだが地形に粒々した感じがでたような印象を受けた。起伏感の無いデフォルトの地表であるが、起伏が結構見えてきていた。
５ｍメッシュ単体でも十分なのだが、それに補間を掛け、さらに高さ方向に分解能を上げたのだから、精神的にはもうこれ以上ない十分さである。
ただし、FractionBits=3でファイルサイズは２倍以上大きくなる。Bicubic補間で３倍近くなっている上での増加なので、そうむやみに多用は出来ないだろう。
やはり思い入れのある土地にのみ最高の補間をかけておくことにしよう。
さて、明日からは灯台のテクスチャ貼り付けをやることにしよう。
Backyさん御製作のツールJDEM_AUTOを使わせていただいて５ｍメッシュシーナリーについてちょっと試しているが、Backyさんがアプリをグレードアップされたおかげで、線形補完やバイキュービック補間でメッシュポイントを増加させられるようになった。
それでさっそく現在制作中の能登半島は猿山灯台付近の５ｍメッシュを作り直し、通常の５ｍメッシュとの違いを較べてみた。
設定は、Bicubic補間、倍率は３倍、である。
Backyさんからのお知らせでは４倍にするとメモリぎりぎりになってしまうとかで、私のショボイPCの処理能力も考え、３倍にしたわけである。
で、結果はどうだったかというと、通常の５ｍメッシュでも既に相当細かなメッシュであるので、大きな山容や断崖の形に劇的変化が起きるという訳ではなかったが、それでも微妙に違うところも確認できた。
補完の原理(数式？)がほとんど分かっていないので、なぜそういう違いになって現れるのか自分で理解できていないのだが、海に突き出した鼻状態の部分で、補完メッシュの地形に軍配が上がった。
４倍補間にするともっと違いが出るのだろうか、また、線形補間にするとどうなるのだろうか。
３倍補間の地形を見た感じでは、大きく(長く)なだらかに流れる地形の所で、ピクッと肩が立つようになるところが出るようである。
ファイルサイズは３倍補間なので、まさに標準のほぼ３倍弱。それなりのサイズにはなる。
この５ｍメッシュポイント補間版も超高解像度フォトシーナリーと同様に、思い入れのある土地で、じっくりと低空遊覧飛行をする所に適用すると、FSがより充実することは間違いない。
次々と素晴らしいアプリを開発しアップデートしてくださるBackyさんに、本当に感謝申し上げます。有り難うございます。
能登半島の猿山灯台を作り始めた。Kanoさんの故郷に近いとのことであるし、Kanoさん製作中の0,5m/pix能登半島フォトシーナリーに併用していただこうという訳で、10日ほど前から作り始め、何とかテクスチャ貼りの手前まで来た。
考えてみると一昨年も伊勢の大王崎、安乗崎の灯台を作ったし、冬になると何故か灯台作りになっている。
冬と灯台。なんだか似合っている気もする。
伊勢の時は神宮参拝を兼ねて大王崎と安乗崎に一泊旅行を敢行した。で、今回もどうも現地を訪ねたい気分がフツフツと沸き上がってきている。
そしてどうせ行くなら、猿山灯台に加えて能登半島突端の禄剛崎灯台も見てみたい。見たら作る、という事になるのだろうが、風光明媚な能登のフォトシーナリーに灯台の２つくらいはあっても悪くないだろう。
そう言えば能登は長いこと訪ねていない。仕事で富来に行ったのも5年ほど前になるし、観光で輪島まで行ったのは15年以上前になる。
確か能登島のほうには、作るべき美しい橋もあったような．．．
しかしそれにしても、５ｍメッシュへの設置テストで見る限り、この灯台は相当猛烈な場所にあるようで、FSX内で見る限り、なんだか山登りの装備で訪ねた方がいいような所だ。
残るは、テクスチャ貼り。
５ｍメッシュシーナリーのお勉強の総復習のつもりで、地元の他に、大津--京都--北摂のフォトシーナリーに合わせて、一部の５ｍメッシュを作って飛行してみた。
平地での効果はあまりないが、それでも河川では堤防が盛り上がって描画される所も多く、これなら橋を普通に（FSデフォ特有のせり上がった積み木みたいな橋ではなく）架ける事ができる。
山地や峡谷になると、その効果は絶大で、深く窪んだ川や、山肌に這うドライブウエイの段状の地形など、かなり本物に近い感じを受ける。
また、山際の高速道路なども削ったり盛り上がったりした感じがよく分かるなど、低空での遊覧飛行には５ｍメッシュは効果が大きいことが実感できた。
結局、５ｍメッシュはFS飛行をどう楽しむか、によってその価値が大きく変わるようだ。
計器飛行メインのラインパイロット訓練的飛行には、山地の空港周辺以外は全く不必要だろうし、2000ｆｔぐらいで雄大な景色を楽しむ遊覧飛行にも、あまり要らないだろう。私のPCの場合、スペックのせいでもあるのか、５ｍメッシュはある程度近づかないと効いてこないのである。
ヘリでゆっくりと地表を眺めながら遊覧飛行するとなると、やはり５ｍメッシュである。
私の場合は、地元と、馴染みの深い北信越、京阪神、中京あたりの５ｍメッシュをそろえれば、FS飛行が充実しそうである。
５ｍメッシュシーナリーの標高０ｍ問題。あれこれ考えている内に、シーナリー作成ツールJDEM_AUTO作者のBackyさんからアドバイスをいただき、実にスマートに見事に解決することができた。
勘所は、JDEM_AUTOで５ｍメッシュデータを処理するときに、データファイルの-9999値は「データ無し」である事を設定しておく、という事である。
さらに、１０ｍメッシュを作る時のようにはしない、つまり「-9999」を「0」に置換しない、これが大事なことだった訳だ。
５ｍメッシュデータはデータ無し(-9999)の部分が多いこと、また北陸の河川部分はほぼすべてデータ無しになっていること。この２つの事がグランドキャニオン状の崖下に広がる０ｍ平原と、奈落の底に落ち込む標高０ｍの河川を作ってしまっていた訳だ。
で、結局、コンパイルの際にデータ無し(-9999)のメッシュポイントにはDEMデータを作らないでおけば、そのポイントには一つ下のレイヤ順位の標高データ（私の場合は１０ｍメッシュデータ）が生きてくるという訳だったのだ。
考えてみれば簡単な事だったが、Ｂａｃｋｙさんからのアドバイスがないと、これには思い至らなかっただろう。やはり一人では何もできないものだ。できても小さなことになってしまうだろう。
さっそく５ｍメッシュのコンパイルし直しにとりかかり、石川県の我谷ダムのところでチェックしてみた。
ここは５ｍメッシュにしてから、ダムも流域の川も全て標高０ｍの奈落の底になってしまっていた場所だ。
新しい設定でやった結果、見事に５ｍメッシュデータと水面(１０ｍメッシュデータ)が融合していて違和感は無い。
下の2月1日記事にある標高０ｍの方形盆地もきれいに無くなり、１０ｍメッシュが活きて５ｍメッシュと融合して表示されていた。
そもそも、よほどよく知っている土地でないと５ｍメッシュ描画なのか１０ｍメッシュ描画なのかは判別しにくく、高高度をＦＳ巡行する時には５ｍも１０ｍもさして変わりはないが、それでもやはり、ヘリやセスナで低空を遊覧飛行する際の近景は、何と言っても５ｍメッシュの臨場感は高い。知っている土地の地形だと、見事に本物そっくりに感じられる。これに超高解像度のフォトシーナリーが重なればリアル感はなおさらである。
ＦＳもすごい時代に突入した。
Kanoさん作成の５ｍメッシュをいただきモニターさせていただいている。 北信越全域のメッシュデータである。すごい！
FSのオフ会以来、超高解像度のフォトシーナリーがマイブームとなっているが、Kanoさんのご説明、「超高解像度フォトには高密度メッシュがよく似合う。」との事で、さっそく体験してみる機会を頂いたわけだ。
フォトシーナリーや作成ツールやメッシュ等、このところ何人もの方々の素晴らしいアプリやソフト作品を使用させていただいており、誠に有り難く、感謝、感謝！！！。
で、５ｍメッシュであるが、Kanoさんは山地でのフライトを勧めてくださっていたのだが、とりあえずは福井空港北方にある丘陵地帯で確認飛行をしてみた。
なだらかな畑地なので、細い農道や切り通しの道などはなかなか１０ｍメッシュ（これでも高密度DEMだが...）では表現されないのだが、５ｍメッシュでは見事に表現された。
もちろん近景での場合であるが、農道がストンと落ち込んで表現されているし、丘陵が出っ張った鼻もきれいに表現されている。また、斜面の際にある平らな畑も盛り上がることなく平にきちんと斜面の横にある。
遠景については、３８ｍメッシュを１０ｍメッシュに変えたときのような劇的変化は感じられなかったが、やはり思った通り、５ｍメッシュによる、これだけの正確な地形に0.5m/pixを上回る超高解像度のフォトを組み合わせたら、FSでの遊覧飛行は別世界に突入するに違いない。
すごい時代になった。また、有り難いことに５ｍメッシュにしてもフレームレートはほとんど落ちない。
ただひとつ、５ｍメッシュシーナリー自体の問題ではないのだが、現行の５ｍメッシュデータは、データの欠落があちこちにあるようで、その部分は標高０ｍの方形盆地になってしまい、グランドキャニオンの崖下平原のような地形が出現してしまうことである。
また、ｋａｎｏさん情報によれば、河川部分も標高０ｍになってしまい、山地の河川は奈落の底状態との事である。
この問題点は元データの追補を待つのが一番だとは思うが、待てない．．．．。
河川の０ｍについては、元データのＸＭＬファイルの０ｍ値を、そのポイントの前後の有効値と同じにするか２ｍほど低くして書き直してからシーナリーコンパイルすればよいと思うが、１ファイルに３万個以上もあるデータをじ〜っと見つめながら手動で手直しするのは、おそらく不可能である。しかもファイル数は数知れぬほどあるのである。
また、データ欠落による０ｍ盆地問題については、１０ｍメッシュデータを参照しながら、５ｍメッシュのデータ欠落部分には１０ｍメッシュの値を代入していく方法が考えられる。
しかし、これは０ｍ河川対策以上に手作業では不可能なことである。
自動化するアプリが欲しいが、そのアプリに盛り込みたい追加機能もいくつかあって、今思案中である。
が、最大の問題は自分の作成能力。MS-DOS時代には仕事用のアプリをBASICとCで作った経験はあるが、いま、参考書を読み直しても、「．．．．(-_-)」という状態である。
自分なりの仕様が固まったら、中部圏FSの新星（実は大御所）Backyさんにお願いするしかない(^_^;)
（追記）2月5日
データ欠落による標高０ｍ問題は、Backyさんの作成アプリJDEM_AUTOの設定をいじれば、実に見事に解消できることが判明した。 上の2月5日記事を参照。
新年おめでとうございます。今年もご愛読のほどお願いいたします。
12月のFSのオフ会でFSearthTilesを使用した高解像度(0.5m/pix以上か)のフォトシーナリーを体験して、大変に驚いた。そして、さっそく自分でもやってみることにした。
ソース画像を自動的に読み込んで５季節と夜のシーナリーまで自動的に作ってくれる。水面処理こそは自動で出来ないが、全く今までのやり方の数十倍のスピードで作業がはかどる。
今までやってきた手作業の良さも勿論あるが、自動処理のすごさにはまいった。そして楽になった分を、水面処理や高解像度化に回せるのである。
ところで、FSearthTilesが自動作製したHardWinterの画像の出来にもまた驚いている。
山地と平地を見事に識別して、特に住宅地の冬景色テクスチャは、もうそのまま使えるぐらいの完成度である。
田畑はちょっと修正の必要があるが、低山は通常の「冬景色」としては、色だけ白黒２値化すればまあこのまま使ってもよいレベルである。
さすがに数百ｍ以上の山になると、北陸の冬景色としては使えないのであるが、自作とFSEartTiles自動生成とを組み合わせれば、冬のテクスチャ作りも比較的短時間で出来そうである。
今まで地元の冬景色を、それこそポチポチと作っていたが、新しい作成エリアについては、このツールがあれば一気に冬景色を仕上げることも出来そうである。
FSEartTilesはフォトシーナリーの自動化と高解像度化を推し進めるツールだと思うが、さらに季節の変化のあるフォトシーナリーという、一歩進んだFS世界を広げてくれるツールであるとも思う。
本当に、FSを始めた頃には実現できるとは到底思えなかった世界が広がりつつあるのだ。
FSのオフミーティングが12月17日から18日にかけて、名古屋で行われた。今回は幹事をさせていただいたが、参加者９人への連絡が主な仕事で、オフ会当日は私自身が楽しんでしまって、細かなお仕事は参加の皆さんにあれこれとお気遣いいただく事になってしまった。
しかし中部近畿圏のFS大好き人間が数名以上参集するオフ会は、多分３年ぶりか４年ぶりだと思うが、皆さんお変わりなくそれぞれディープにFSを楽しんでいらっしゃる事がわかり、また、新しい情報や機器、とっておきのお宝公開など、本当に楽しい一晩だった。
参加の９名、北から石川、福井、長野、岐阜、三重、兵庫と色々だったが、初対面の方とも会って１０分後までには旧知の仲という風になって、結局は朝の３時過ぎまで、情報交換や、Kanoさんご用意の巨大スクリーンに映し出されたFSX映像とで、もう少年のように楽しんでしまっていた。
往復とも金沢のKanoさんの車に同乗させていただいたので、道中もFS談義に花が咲いたわけで、年に一度あるか無いかの素晴らしい休日を過ごすことが出来た。
オフ会の中で、今まで存在は知っていたが手を染めてこなかったところのFS Earth Tile による大阪・奈良フォトシーナリーを拝見したが、0.5m/pix以上の解像度で作製されていたため、その詳細さには度肝を抜かれた感じだった。離陸直後から周囲のフォトがクリアーに見えるのである。また、駐車場の自動車もフロントガラスが識別できるのである。もうこれには、まいった。
で、さっそくFS Earth Tileを入手して、あれこれ試してみた。
FS Earth Tileを使用すれば、水面処理こそ手作業であるが、その処理さえ諦めれば極めて迅速にフォトシーナリーが作れ、その分だけ画像の高解像度化に力を注げる訳だ。今のところFS
Earth Tileが読み込む画像は衛星画像であるため、航空写真に比べればどうしてもクリアーさに欠けるが、場所によっては航空写真以上の良い画像が得られる所もある。
どうも、このオフ会で、都市部においては2m/pixより悪い解像度では満足が出来なくなってしまった気がする。
その他、オフ会では、自作シーナリーのお裾分けをいただいたり、自作CDUのデモを拝見したり、貴重な戦闘機機体パネルに寄せ書きしたり、各人のディープなFS経験に感嘆したりと、一週間経った今でもまだ余韻にひたれるほどなのである。
で、今は、神戸空港周辺で1m/pixを上回る高解像度フォトシーナリー作製の習熟中なのである。ソフトはFS Earth TileとPhotoSceneryMakerとを併用している。いずれも一長一短あり。
とにかく、もうフォトシーナリーはギガバイトの世界に突入。人間の感覚が要求するものには際限がない．．．．なぁ。
FSX用大阪平野北部フォトシーナリーの西宮・芦屋方面を拡張した。甲子園球場もカバー範囲に入った。
しかし、いつもながら海岸線のアルファ画像処理には時間がかかった。神戸周辺は比較的直線が多い海岸線だとたかをくくっていたら、さすがは高級リゾート海岸？、マリーナがあって係留された小型船周辺の水面処理にはえらく手間取った。
しかしこれでShigeさんの大阪フォトの西側とつながったので、あとは生駒・信貴・東大阪あたりを作れば、大津から大阪湾までの完全VFRも実現の運びとなる。年内に何とかできないかなぁ、といつもの妄想が。
ところで、今回このあたりは東西２．５m/pix、南北２．９m/pixの解像度である。
今回から地表画像作製作業に、以前のように「カシミール」を利用することになった。位置の割り出しは国土地理院のサイトの方が楽なのだが、その他いろいろの利点があるので、再びカシミールを利用することになった訳である。
カシミールはFS以外にも、登山の俯瞰図準備やGPSデータ処理にと、大変お世話になっているフリーソフトで、作者の杉本さんには深く感謝。
シーナリーの解像度としては１．４m/pixでやるべきだったかもしれないが、１５００ｆｔも上昇すると、２．９m/pixもさほど変わらないので、ちょっと今回は市街地の割には手抜きをしてしまった。
生駒・信貴・東大阪あたりは１．４m/pixでやっておかないと、八尾に着陸する際にちょっと地表のボケが気になるかもしれない。
Saitek の Flight Instrument Panel 。新たに追加になった６個の計器は、セスナのバーチャルコッックピットと共に使ってなかなか使い勝手がよい。しかし、本体左の６個のボタンの割り当てが、私の使い方には合わない。しかもデフォルトの６個の計器は全て同じボタン割り当て。 まったくもったいない。
また、本体下の２個のロータリーエンコーダーのダイヤルも、デフォルト６計器では高度計に「気圧バグ」、定針儀に「OBS1、針路バグ」のみの割り当てであって、他には割り当てがなく何の役にも立っていない。これでは折角のダイヤルがもっいなさすぎる。
追加６個の計器にはADF周波数変更やら何やらそれなりに割り当ててあるので、何か割り当て方法があるはずだと思い、設定が書かれているｘｍｌファイルを見てみると、比較的簡単に割り当て変更が出来そうな事がわかった。
で、さっそく試してみた結果、予想通りｘｍｌの書き換えだけでFSXイベントに割り当てられている機能がボタンやダイヤルに割り当て可能なことが確かめられた。
今現在のところ、次のように割り当て変更してみた。
定針儀ボタン ：１＝AP-マッハ保持 ２＝AP-NAV1保持 ３＝通信機(デフォルトのまま) ４＝GPS（デフォルトのまま） ５＝ストロボライト ６＝パネルライト
定針儀のダイヤルはデフォルトのまま（左＝OBS1、右＝針路バグ）
スピード計ボタン ：１＝AP-スピード保持 ２＝AP-マッハ保持 ３、４はデフォルトのまま ５＝スモーク ６＝SLEW（高速移動）
スピード計のダイヤル ：左＝COM周波数MHｚ 右＝COM周波数KHｚ
その他、計器の表示順番も変更したのに合わせて、追加の６計器のボタン割当てを少し入れ替え。
計器板の画像もいじれる様子なので、ダイヤルのノブの画像（機能ラベル付き）を追加してみたい。
先日来考えていたGoFlightのGF-RP48 のキーやダイヤルの割り付けだが、新たに購入したSaitek のFlight Instrument
Panel（FIP）にOBSやADF指針回転機能ダイヤルがあるので、計器関係一切はFIPに任せることにした。
それで結局、GoFlightのRP48には通信機器とオートパイロットの中で、よく使う機能を選んで割り当てることに決定した。
機能設定ソフトは、GFConfigを使わず、敢えて前バージョン的なGFKeysを使用する。GFConfigは割り当てられる機能が限定されており、単体では周波数上下には使えない。
また、FSX標準では周波数変更のイベントEntryは設定されていないので、SDKを参考にして、XMLファイルにイベント名とキーシーケンスを追加記述してやる必要がある。そのキーシーケンスをGFKeysでRP48に指定する。
ダイヤルは、NAV1（MHｚ）、NAV1（KHｚ）、ADF周波数、AP高度設定。
ボタンは、NAV1スタンバイ周波数切り替え、NAV1信号音、アプローチのマーカー信号音、ADF信号音、空き、空き、AP高度保持、APマスタースイッチ。
COMやNAVの周波数をダイヤル１個だけで上下させる設定に出来ないこともない。そうすればダイヤルが１個空いてCOM周波数を割り当てる余裕が出るが、やってみるとエアバンド一杯に上下させるのに相当数回さないといけなくて、実用的ではないことがわかった。
また、私のFSX使用法の場合、COM周波数はATC機能の中で自動的に切り替わる。結局ダイヤルではNAV1周波数をMHｚとKHｚ別々に上下させ、ADFはダイヤル１個で上下させることにした。ADFは１個で十分にバンド幅を上下させられる。NAV周波数もダイヤル２個で快適に変更できている。
これで少し、FS計器飛行の練習を「その気になって」やれそうである。
GoFlight の GF-RP48 の設定が今ひとつしっくりこないので色々やってみている時に、かねてより気になっていた Saitek の
Flight Instrument Panel のドライバーが有志の手によってアップデートされていることを、omegabooさんの掲示板で知った。
なんと新たに６個の計器が追加になって、HSI、VOR１、VOR2、ADF、FMD、エンジン計器パネルが使えるようになっているので、これは「買い」と判断し、さっそく注文した。歴史的円高でもあるのでAmazon経由で個人輸入し、トータル18900円だった。
使用感その他を、omegabooさんのサイト載せたが、心覚えに再掲載。
・購入したままのデフォルトでは6個の計器のみ使用可能。これらの基本的計器はバーチャルコックピットのもので間に合うものばかりで、ほとんど使い出が無い。ただ、ジャイロコンパス（定針儀）はＯＢＳ１指針も併設されていて、読み取りやすくて有用（後述参照）。
化粧箱には12個の計器が印刷してあるのに、付属CDに入っているのは６個用のドライバー。で、Saitekサイトから追加ドライバーをダウンロードする必要あり。また、この追加ファイルはrar形式圧縮なので、rarに対応したLhaplusなどの解凍ソフトが必要。
新しいドライバーには計器12個分のdllと新xmlファイルが入っているので、それらを全て上書き。サイトに書いてある方法はなぜかトンチンカンな間違った説明である。
・使用してもフレームレートはほとんど変わらない。ホッとする。
・LAN経由で別PCに信号を送って、その別PCでこのInstrument Panel を使う機能が付属している。使わないが．．．
・ミニLCDの色と解像度は良好。細かな数字もくっきりと表示される。
・左側の６個のボタンは、２Dパネル、GPS計器、通信機器等を表示させるボタン。FSXゲーム画面に通常に表示させるボタン。
さらに追加６個の計器に切り替えると、ＡＤＦとＮＡＶ１のアイデンティファイ信号on/offや、ＡＴＣの０〜９の選択ボタン、プッシュバック、パーキングブレーキなども新たに割り当てられている。
２個付属しているロータリーエンコーダー（ダイヤル）を回して、高度計の微調整や、針路バグの回転、ＯＢＳ１、OBS２のカード回転が出来る。特にジャイロコンパスとセットになったＯＢＳ１指針調整機能は便利。
割り当てを定義しているXMLファイルは、FSXイベントで記述してあるので、これを書き換えれば、ボタンやダイヤルの機能割り当てを簡単に追加変更できる
（はず。） ボタンは、６個×１２＝７２個 の追加ボタンを得たことになる。ただ、切り替えが必要なので、７２個分そのまま全てに別機能を割り当てたら、使いにくいことになる。デフォの６計器は全て同じ機能を割り当ててある。
・ＵＳＢハブ経由でも使えた。ただし外部電源供給型のハブ。
・薄くて軽いので、付属のアタッチメント器具でどこかに固定しないと使いにくい。
やはりこの新追加の６個の計器こそが値打ちもの。ただ、今のところ設置場所に困っている。
で、GoFlightのRP48は、通信機器の周波数制御とオートパイロットに使うことにした。ソフトはＧＦ Ｋｅｙｓ．
娘の里帰り出産準備、９月の初孫誕生といろいろあって、あっという間に１０月になってしまった。その間FSXは深夜にクロスカントリーをちょっとだけ。 しかし前々から、そしてクロカン飛行中も感じていたことだが、せっかく購入したGoFlightのGF-RP48の操作は、デフォルトでは少々使いにくい、あるいは物足りないのである。
GF-RP４８は４個のロータリーダイヤルと８個のボタンにFSの様々な機能を割り当てる事ができ、見た目もまあまあ良くて期待して購入したものだが、実際に使ってみると、８個のボタンへの割り当ては十分な機能があるが、４個のロータリーダイヤルへの割り当ては（デフォルト使用のままでは）相当に期待はずれなのである。つまり、一番期待していた、COMやNAVの周波数をダイヤル回転で操作できないのである。というか、周波数変更面に関して言えば、このGF-RP４８単体（のデフォルト使用）では「GF-166Aなどの周波数変更用ユニットを操作する機能」しか持っていないのである。
そもそもこういったプログラマブルな機器では設定ファイルをいじれば相当な自由度があるはずなので、どれどれ、と調べてみたが、標準で使用する「GF
Config」という設定ソフトとその設定ファイルでは、ユーザーによる自由な設定はできない事がわかった。ロータリダイアルに関しては、初心者でも簡単に設定できるようにとメーカーがプリセットしておいた機能しか選べないのである。
しかし何とか、方法はあるはずだという訳でもう少しGoFlightのホームページをチェックしてみると、GF SDKなる操作ソフト開発キットも公開されていたが、さすがに敷居が高すぎるわけで、出来上がりのソフトはないかと見てみると、「GF Keys」というソフトが見つかった。
この「GF Keys」は「GF Config」の前バージョン的なソフトのようで、ロータリーダイアルもキーシーケンスを使って設定し、設定ファイルも直接編集可能になっている。この「古さ」がユーザーにとっては有り難い訳で、さっそくこの「GF
Keys」で機能設定をやり直すことにした。
出来るだけFSXが使用しないキーシーケンスを使いたいので、今日はFSX標準のキーシーケンスを調べていたが、これに３時間ほどかかってしまって、今日はもう打ち止めにした。しかも（予想通り）COMやNAVの周波数を変えるキーシーケンスは標準ではFSXのcfgXMLに設定されていなかった。
しかし、FSXのSDKには周波数変更のXMLファイル用Entryが書いてあったはずなので、明日はそれをちょっと調べてみて、空いているキーに割り当ててみようと思っている。
うまくいけば、GF-RP48単体のダイアルで周波数変更ができるようになるはずである。
------------------------------------------------------------------------
（10月23日追記） 少しばかりやってみた結果。
確かに、GF Keysを使えば、GF-RP48のロータリーダイアルにキーストロークを割り付けられることを確認。それで、実際にNAV１の周波数変更をやってみたが、周波数変更用のFSX用Entryは、例えばNAVならば、MHｚとKHzは別々に割り当てられている。ADFなどは１００KHｚ、１０KHz,１KHｚが別々のEntryになっていて、結局のところロータリーダイアル回転のみで（キーやボタンを一回も押さずに）周波数を上下するには、NAVで2個、ADFで3個のダイアルが必要になってくる。NAV２、COM１、トランスポンダも入れたら全くすごい数のダイヤルになってしまう。
そもそもGF-RP48には4個しかダイヤルはないのだから、要するに、ダイアル回転で周波数を上げ下げする前に、ボタン操作で無線機の切り替えをやる必要が出てくるわけで、そうすると、ダイヤルは実は周波数上下用に１個あればよいのである。そしてこんな風にGF-Keysを使うと、残り３個のダイアルに割り当てる機能が思い浮かばなくなってくるのでもある。
結局、敢えてGF Keysという前バージョン的なソフトを使うメリットは、周波数変更に関してはほとんど無いことになってしまった。
(11月４日追記) NAV、COM、ADFそれぞれに、１個のダイヤルで周波数を上下できるEntryイベントを発見。これでやってみた結果を、上記１１月５日記事に記載。
作り上げたランディングギアのユニットを、スロットルレバーユニットの筐体に組み込んだ。
もともとばかでかく作ってあった筐体なので、スイッチの下の空きスペースに難なく納まった。と思ったが、やはり、思わぬアクシデント。
筐体内の仕切板を支えてあったL型アングルと、ランディングギアユニットの取付用L型アングルとが重なり合ってしまって、少しだけギアユニットが上向き加減の取り付けになるのを我慢せざるを得なかった。
また、L型アングルを元の長さのまま使用した結果、ランディングギアユニットを少し後ろに下げて取り付けたので、筐体側面上でのレバー上下動の幅が、思っていたより大きくなってしまった。
以上の結果、筐体に大きな縦溝が、しかもスイッチ板にかかるまで開いてしまって、ただでさえ見た目の良くない筐体が一層目も当てられない状態となってしまった。
溝の周囲に、ギアダウンのリミット速度などを記したシールなどを上手く貼り付けて、少しなりとも見た目をよくしてやらないといけない。
また、ちくわ状の穴あき丸棒（外径20mm、内径10mm）で作ったレバーつまみも、パテ埋めなどを施してやる必要もある。塗装は諦める。
しっかしこれ、他人の作ったものなら絶対に欲しくない見栄えであるのに、自分で作ったものだとどうしてこう、改造を加えてでも使い続けるものなのか．．．．。不出来の子供ほど可愛いと世間では言うが．．．．。 正直な所、作り直す手間も今更という感じでもある。
ランディングギアのユニット作製 Aug. 24 , 2011
先日Kanoさんから大量の電子工作用パーツを頂いた。今となっては田舎では入手が難し目の部品もあって、その中に「瞬間スイッチ」があった。しかも松下製。
このスイッチは以前から何かの都合があれば入手しようと思っていた部品であり、見たとたんに、「あ、これでランディングギアのユニットを作ろう」と決めた次第である。
今のところはランディングギアはELECOMのアーケード型スティックに割り振って使用しているが、４方向のスティックではやはりインベーダーゲームを連想してしまうのである。私の世代は。
やっぱり上下動のみのレバーが欲しいというわけで、(株)ミストラルの製作ページにあった記事を参考に、同じように木工製作でやってみることにした。
木の板を少々、5mmのアルミ丸棒、タッピングビス、Lアングル、そして頂き物の瞬間スイッチ。
部品らしい部品と言えば、瞬間スイッチぐらいしかない。ほとんどあり合わせのもので揃えられた。
勘所は、瞬間スイッチを押すための木板製カム（アルミ棒を取り付けたもの）の形と大きさと取り付け位置ぐらいだ。
何度がスイッチとの距離と位置関係を調整し、さらにカムの形を少し尖った形状に削り直して、３日ほどの夜なべ工作でユニットは完成。時間的には12時間もかかったかかからないかぐらいである。
見た目は悪いが動作はOK。狙った通りに作動している。できればアルミアーム上下の手応えが、もう少し金属っぽい作動感があって欲しいが、ま、贅沢は言わない。
あとは、このランディングギアユニットを、スロットルレバーユニットの筐体に仕込むだけである。
上手く仕上がることを願いながら、今日の所は終了。