2021年1月4日月曜日

星像が流れるのは赤道儀が水平でなかったためか?

Borg71FL+レデューサーで、これまでに星像が丸くなったのが、1117日の1回だけでした。その時点では、フランジバックと、ヘリコイドの前後の鏡筒の傾斜を調整したので、うまくいったと思っていました。

光軸の傾斜は関係ない?

しかし、その後128日から22日の間に、何度も試したのですが、いずれも左上(縦構図ですので、北西側)の星像が放射状に流れていました。

数日の間、ヘリコイドの前の鏡筒を上下左右に移動させてみましたが、基本的に上のように左上の星像が最も悪くなっていました。いずれも偏芯率が0.6を超えていますので、かなり目立ちます。

赤道儀の水平を調整にすると少しまともに

一度だけうまくいき、その後再現しないような要因が何かを考えてみました。三脚を三脚スプレッダーに乗せるとき、はっきりとはまらずに縁に乗っていたことがあることを思い出しました。これが、南西側の足でしたので、もしかしたらと思い、南西側を上げるように調整しました。泡水準器では、調整前後で大きな差があるようには見えませんでしたが・・・

上が、1225日に試しに撮影した画像のeccentricity図です。以前ほど偏芯率が良くないのは、ガイドエラーのせいだと思います。RA側のエラーが大きいので、どうしても縦長の星像になります。しかし、最大の偏芯率は0.6より小さくなっていますし、周辺部との差が大きくないので、画像処理である程度修正できます。私としては満足できるものです。

星像の流れの原因?

もし赤道儀が水平でないことが、星像の流れの原因であれば、赤道儀が上下したがって南北に(画像は縦構図を横にしているので左右に)回転しており、その中心が中央より下したがって南に(画像では中央より右に)あるために、北側の(画像では左側の)星像が大きく流れるのではないでしょうか。

これから

1225日以降はチャンスがなかったので、今日から何度か撮影して確認してみます。

2020年12月23日水曜日

ナローバンドの組込み・星像の歪み

光害地ではL画像を撮影するのは無理だろう、LRGBから取り出した抽出Lと、Ha・OIIIを合成して作ろうと思いました。HaOIIIは、それぞれRとG・BNBRGBCombinationで組込んで、RGBを補強します。まだ始めたばかりですが、この方法は大変効果があることが分かりました。なお、フィルターホイールは5枚しか入らないものにしましたので(軽量化のため)、SIIは省略です。

燃える木と馬頭星雲

まずは、燃える木と馬頭星雲です。71FL+レデューサー、ZWO ASI 183MMで、HaOIIIがそれぞれ約100分、RGBがそれぞれ約70分、合計でおよそ410分です。赤を強調してみました。

ただし、OIIIGBに組み込むと、馬頭星雲の背景が赤になりませんでしたので、HaRに入れただけです(OIIIL画像の一部として使っただけ)。パラメーターを変えて、これからいろいろ試してみようと思います。また、アルニタクの周りにハローが出ています。これはG・B・OIIIから来ているのですが、自然なものなのでしょうか?それともフィルターが良くないのでしょうか?

かもめ星雲

かもめ星雲も、撮影時間はほぼ同じです。ただし、OIIIGBに組み込んでも不自然にはなりませんでした。逆にHaだけでOIIIを入れないと、赤がきつくなりすぎました。これまでOSCカメラ(294MC)で何度も撮ったものですがうまくいかず、今回始めてうまく捉えられました。モノクロカメラによるナローバンドとRGBの組み合わせは、光害地で大変有効だと思います。

しかし、目立たないようにクロップしていますが、左上(北西側)の星像が流れています。

星像の流れ

前回モンキー星雲を撮影したときは、周囲まで星像が丸くなり、これで万全と思ったものです。PixInsighteccentricity図も、私としては満足できるものでした(これは、HaとOIIIのHOO合成です)。



しかし、「燃える木と馬頭星雲」「かもめ星雲」ともに左上の星が、-60度位に傾斜しており、eccentricity0.6を越えてしまいます。 


これは、71FL対物レンズとレデューサーの間にある、ヘリコイドが原因となって光軸が曲がっているのだろうと考えました。そのため、鏡筒バンドをヘリコイドをまたぐように取り付け、鏡筒バンドの締め付けネジで調整しようとしました。

確かにこのネジで、対物レンズが上下します。いろいろな場所にネジを入れて試したのですが、基本的に左側の歪みが大きいままです。次は、下に詰め物を入れて、対物レンズを上に少し上げた状態です。何もしていない状態と変化がありません。

他の方向へ詰め物を入れても、ネジで締めてもあまり変わりません。すると、これは光軸の歪みが原因ではないのかもしれません。

これから

一度はうまくいっているわけですから、必ず改善できるはずです。極軸が合わないことによるわずかな回転が原因かもしれません。もう一度フランジバックも調整してみます。

また、色収差が目立つことも分かりました。青が左、赤が右にはみ出ています。71FLの問題だと思いますが、なんとか画像処理で修正できないか試してみます。なお、PixInsightで、Distortion CorrectionをオンにしてStar AlignmentでRGBを位置合わせし直しましたが、だめでした。これは当然のことのようですので、別の方法を探します。

2020年12月4日金曜日

フラット補正の失敗と原因

フラット補正がうまくいかず、チリ跡がドーナツ状に残ってしまいました。今回は、空が格別に明るかったこと、フラット撮影のライト撮影の間が空いていたこと、フラットダークを事前に撮りためた、従ってフラットの撮影時間と完全に一致しないもとを使うなど、これまでと状況が違っていました。


症状

121日は月齢15.9でしたが、ナローバンドならいけるだろうと、月のそばの燃える木と馬頭星雲をHaで撮影しました。71FL+フラットナー+ASI 183MMHa3X23枚です。

一見すると問題なさそうですが、強くストレッチを掛けると次のようにドーナツがいくつも現れます。特に右上が目立ちますが、中央から左の下には、いくつものドーナツのかけらがあります。中央部と右にも薄く見えています。

これは当然ながら、フラット画像に対応しています。次も強くストレッチしたフラットです。周辺減光とチリの内部は補正されているのですが、チリの周辺部のみがドーナツ状に残っています。


フィルターホイールの回転方向か

以前にもたまにこのような現象がありましたが、毎回ではないので、あきらめていました。今回しっかりと原因を探ってみました。撮影スケジュールは次の通りです。空が明るいので、撮影時間は3分と短くしました。

18:55      プレアデス星団 Ha 312枚(ベランダのひさしに掛かる)
20:01      Haフラット 3.05秒 35
20:04      OIIIフラット 4.31秒 35
21:15      燃える木と馬頭星雲 Ha 324
22:30      燃える木と馬頭星雲 OIII 312枚(雲が出てくる)

これまでは、毎回ライトを撮影後にフラットを撮っていましたが、最後まで撮影に付き合わなければならず、面倒でした。その後、フィルターを変えてもフォーカスが変わらないことに気づき(全てZWO製のためか)、最初にまとめて撮影し、後はNINAのシーケンスに導入、プレートソルブ、ガイド開始を任せ、朝まで寝てしまおうというのが当初のプランでした。

そのため、フラットとライトの撮影の間に、フィルターの移動が入ります。そうするとこの失敗は、フィルターホイールの回転を双方向にしているためではないかと思い至りました。フィルターの位置が回転方向によって微妙にずれ、フィルター上のチリの位置もずれることになり、フラット補正が失敗します。以前にCloudy Nightsの中で、フラット補正の失敗が、これで解決したという記事を見つけたためです。調べてみると案の定unidirectionalにチェックが入っていませんでした。


フィルターのチリではない

しかし、OIIIのフラットとHaのフラットのチリ跡が、ほとんど同じであることに気づきました。次はOIIIのフラット画像を強調したものです。

右上・中央・左下のチリがHaと同じです。あまり目立たないのですが、次の、燃える木と馬頭星雲のOIII画像にもドーナツがあります。

ということは、これらのチリはセンサー側にあるということになります。センサー前の保護ガラスを清掃して、フラットを撮影すると確かにこれらのチリ跡は消えています。

つまり、フィルターの位置がずれていたから、ドーナツが残ったわけではないことになります。


原因は構図を変えたため

最初に撮った次のプレアデス星団には、ドーナツがありません。したがって、フラット画像には全く問題がないことになります。空が明るかったことや、フラットダークとフラットの時間が完全に一致していないことは、原因にはなりえません。その結果、燃える木のライトの撮影に、なんらかの問題があることがわかりました。

Cloudy Nightsでドーナツになるフラット補正の失敗例を探しました。そうすると、それまでうまくいっていたフラット補正が、ある日突然うまく行かなくなった、20173月のフォーラムが見つかりました。次の投稿画像のドーナツは、現象としては全く同じものだと思います。

https://www.cloudynights.com/topic/569243-flat-issues-out-of-nowhere/

いくつものアドバイスがありましたが、その中で決定的だったのは、オートフォーカサーのネジが緩んでいて、フォーカサーが少しずれことが原因だったとの回答です。投稿者の場合は、Alnitakのフラットボックスが、フラット撮影時つまり天頂を向いているときに、位置が下がっていたことが原因であることが分かったとのことです(詳しいことはよく分かりませんが)。なおこの種の問題では、迷光が原因ではとする主張がいつも出てきますが、これはどうも関係なさそうです。

つまり、ほんの僅かな光軸のずれがドーナツを作るようです。これがヒントになり、フラット撮影から燃える木と馬頭星雲撮影の間に、カメラを90度回転したことに気づきました。回転自体はフラット補正に影響を与えるものではないはずですが、回転装置のネジの締め方を、完全に前と同じでできるはずはありません。これによってフラット補正が失敗したのであろうことは、間違いないと思います。

 

これから

次回の撮影時に今回の考察結果を確認しますが、フラットとライトの撮影の間は、鏡筒を手で操作しないようにしたいと思います。学ばなければいけないことがたくさんあります。


2020年11月26日木曜日

PrecisePartsのアダプター

注文していたPrecisePartsのアダプターが本日届きましたので、取り急ぎご報告します。先月注文した時点で、今月19日に出荷することが決まっており、そのとおりに発送されました。アメリカとの航空便が制限されているこの時期にも関わらず、早く届きました。

もし合わなければ無料で交換する旨の手紙が入っています。実際、交換してもらった人がいるようです。


このアダプターは、次の機材を置き換えるものですので、光路長が28.3mm、対物側がM49.80.75メス、接眼側がTマウントのオスになります。
Borgカメラマウント キヤノンEOS用【5005】光路長10.8mm
ZWO EOS-EFマウントアダプターIIEFW用 光路長 17.5mm

上のEOSマウントアダプターのセットが104gなのに対し、47gですので、およそ50g軽くなりました。がたつきがなくなるだけでなく、軽量化できるのは大きなメリットです。


鏡筒に取り付けた状態です。左側がBorgフラットナー+マウントホルダー、右側がZWO電動フィルターホイールminiになります。


これから使ってみますが、問題はないように思われます。

2020年11月23日月曜日

星像のまとめ・NINAの極軸合わせ

ようやく星像が丸くなりました。私なりに分かったことをまとめておきます。次はHaOIIIだけですが、初めて撮影したモンキーヘッド星雲です。


また、東京在住のCuiv, The Lazy Geekさんのビデオを見て、N.I.N.A.の極軸合わせ機能が使えるようになりました。PHD2のドリフトアラインメントより早く終わります。

星像を丸くするために(まとめ)

① 最も大きな悪影響は、ZWO EOS-EFマウントアダプターIIによるものでした。全く問題がない場合もありましたので、気がつくのが遅くなりました。かみ合わせが良くないと、星像が一様に流れます。現在は、強化加工をしてもらったBorg Tマウントのイモネジを調整し、傾きが出ないようにしています。もう少ししたらPrecisePartsの特注アダプターが届きますので、それを使うようにします。

2つ目の大きな問題は、Borgのフランジバックでした。Borgはフラットナーとレデューサーで異なるマウントホルダーを使うように推奨しています。

 フラットナー:M57→M49.8ADSS 7923】(光路長0)
 レデューサー:カメラマウントホルダーM 7000】(光路長5mm

この後にカメラマウントキヤノンEOS用【5005】(光路長10.8mm)を付けます。ここからのフランジバックが44mmであると書かれていますので、上のホルダーからのフランジバックは、54.8mmであるはずだと思い込んでいました。

しかし、レデューサーとフラットナーでは、フランジバックが違っており、フラットナーでは、1mm程度長くしないといけないことが分かりました。スペーサーで毎回調整するのは面倒ですので、結局次のようにしました。

 ・フラットナーの目盛りを71FL400mmではなく、460mm程度にする
        
※これにより4mm程度光路長を短くする(何度か試行錯誤する)
 ・カメラマウントホルダーM 7000】(光路長5mm)を使う
        
※これで全体として光路長を1mm程度長くする

PPECRAのガイドエラーを少なくする

④ 東側のウェイトを重くして、RAのガイドを安定させる

上の③と④は前回書いた通りです。二つを合わせると0.6RMS程度の改善が見られました。なお、AZ-EQ5 GTPPECを動作させるにはEQMODではなくGreen Swamp Serverを使わなければならないこと(恐らく)については、前回を参照してください。

それ以外では、ベルトのテンションをあまり緩めると、明らかにガイドエラーが大きくなることが分かりました。ただ、出荷時のままでも問題はなかったようです。また、RADEC軸にあった遊びについては、しっかりギアを合わせて完全になくしても、良い効果は得られませんでした。締め過ぎて異音がするようになったこともありました。

 N.I.N.A.の極軸合わせ

PHD2のドリフトアラインメントは、どうにも時間がかかり、不満でした。NINAの極軸合わせはプレートソルブを使って誤差をデジタル表しますので飛び付いたのですが、前に試したときは東の緯度0(水平)を向いてしまって、うまくいきませんでした。ビデオ(https://www.youtube.com/watch?v=Le5BJcBADA8)を見てようやく、緯度を指定できることが分かりました(歳を取ると理解が遅くなります)。

プレートソルブは、Rフィルターで4秒撮影するように指定し、高度測定の東の緯度は20度にしています。恐らく2秒程度でも大丈夫だと思います。

緯度をずらして(恐らく)2回撮影し、極軸のずれを表示してくれます。1回の測定にかかるのは25秒程度です。この後は何回か試行錯誤して測定を繰り返します。次は、高度が2.5分角程度のずれに収まったことを示しています。

方位角は、天の子午線と黄道の交点で測定します。上の図では、35分角のずれがあることを示しています。

PHD2では、ガイドが安定するまでに最低でも2~3分かかりますので、2回の修正で済んだとしても、高度と方位角で15~20分はかかります。それがNINAですと両方でも10分位しかかかりません。なによりデジタルですので、信頼性があります(そのような気がします)。北が見える場合のSharpCapにはかないませんが、これは便利だと思います。

これから

持ち出し用赤道儀のAZ-GTiでも、GS Serverが問題なく動作することが分かりました。ボーレートをAZ-EQ5115200ではなく、9600にする必要がありますが、それ以外の設定を変更する必要はありません。PPECは自動的に無効になります。さすがにSkyWatcher専用ソフトです。

また、AZ-GTi用にノートパソコンの代わりに、Windowsタブレットを中古で購入しました。8GB, SSD256GB16,000円と、感激するような安さです。マウスもキーボードも使わなければ、パソコン用テーブルを持ち出す必要もありません。さらに、電力消費も少ないので、バッテリーも持ちそうです。苦労しましたが、画面タッチだけで何でもできることは確認しました。歳を取ると外で出るのは億劫になりますが、準備だけは整えておこうと思っています。

2020年11月6日金曜日

AZ-EQ5のPPECとGreen Swamp Server

ようやくAZ-EQ5PPECが動いたように思います。前回はEQMOD_2でうまくいったような気がしましたが、その後何度か試してみると、効果がないどころか、どうも悪くなっていること分かりました。結局Green Swamp Server(GS Server)で、なんとか動かせたようです。AZ-EQ5では、EQMODPPECが動作しないというのは本当なのかもしれません。

 PPECのトレーニング

GS Serverのマニュアルをざっと読んで、PPECのトレーニングの仕方が悪かったことが分かりました。これまでは、Cloudy Nightの投稿から、PHD2のガイド出力をオフにしてトレーニングすると思っていましたが、ガイドしたままにしなければならないようです。

トレーニングには20分以上かかりました。上の画像は終了後にPPECをオンにした状態です。次は、トレーニング中のPHD2のグラフです。

全体のエラーRMS1.5秒角ですので、前回のEQMOD_2でのPPEC動作とほとんど変わりません。次がGS ServerでのPPEC動作中のグラフです。

全体に乱れてはいますが、RAの値は1.26秒角から0.97秒角へ、0.3秒角ほど良くなっています。ネットで調べるとPPECの効果はこのくらいのようです。

マニュアルによると、次の設定画面左のAlternate PPECオプションが、ポイントのようです。PPECが動作していると、PHD2からのガイドパルスがランダムに削られてしまう(truncateされる)不具合を修正するものだそうです。ST4では、信号を出す前にPPECをオフにし、信号を出した後にオンにするのでこの問題は起きないため、Alternate PPECはこの動作をエミュレートしているとのことです。

前回のCloudy Nightsの投稿者もこれを検証しており、AZ-EQ5では、ガイドパルスが極めて小さくなっていました。AZ-EQ5固有の問題のようで、SkyWatcherの他の赤道儀(EQ6など)では起きないようです。

なお、上の画面でAlternate PPECの下にあるGoTo Dec Pulseオプションは、DECに対してガイドパルスではなく、GOTO信号を送るものだそうです。その方が精密な指定ができるとのことですが、昨日のチェックでは効果は確認できませんでした。

 これから

GS Serverの使い方がだんだんと分かってきましたので、これをメインで使っていこうと思います。EQMODと比べて設定が楽ですし、インターフェースが分かりやすくなっています(ただし、PECを作るAutoPecのような機能はありません)。

RAは多少良くなったのですが、逆にDECが悪くなってしまいました。以前は0.5秒角程度だったのです。これは、DECのギアの締め過ぎ、もしくはベルトのテンションを強くし過ぎたのかもしれません。次回に調整してみます。


※追記(2020/11/07)

昨日の晴れ間に、GS ServerとPPECを再確認しました。次のグラフの最初の3分半程度がPPECがオフ、以降がオンです。
オフの状態ではピリオディックエラーがはっきりと分かりますが、オンにすると目立なくなり、効果が確認できます。

オンの状態で撮影したくじら座A(M77)のFITS画像です。昨日は71FLとレデューサーを試しましたで、ピクセル画角は1.72秒角です。フラットナーと比べると、ガイドエラーの許容度は高く、星像はほぼ丸くなっているように思います。この程度なら満足できます。
バックフォーカスも合ってきたので、周辺部の乱れはなくなってきました。後は、フラットナーの1.1秒角で、どの程度丸くなるかです。なお、DECのギアを多少緩めたのですが、目立った効果はないようです。

※追記(2020/11/11)
AZ-EQ5GT(とAZ-GTi)では、EQASCOMのギアの設定をCustomにしなければならなかったことが、遅まきながら分かりました。もしかしたら、これをしていなかったからPPECが動かなかったのかもしれません。時間があれば検証してみます。

2020年11月3日火曜日

星を丸くする その2

カメラ183MMに変更した後の、卵型の星像を解決するのに、①~④について解決策を考えてみました。引き続き⑤~⑦について検討します。

① カメラのピクセル角度が小さくなってガイドエラーが目立つようになった
② バックフォーカスが合っていない
③ カメラと鏡筒の接続面が傾いている
④ カメラとウェイトのバランスが合っていない
 PHD2の極軸合わせがうまくいっていない
         
かなり適当にドリフトアライメントをやっている

 AZ-EQ5のバックラッシュが大きい
         
ウェイトの先端やアリミゾの部分が確かにガタガタする

 AZ-EQ5のピリオディックエラーが大きい
         PEC
機能を使っていない

⑤ 極軸合わせを確認する

ドリフトアラインメント後に、PHD2のガイド・アシスタントを実行するようにしました。ここで「極軸設定エラー」がおおむね3分角以内になるようにします。また、推奨される設定を採用するようにしました。

AZ-EQ5 GTのバックラッシュを小さくする

RA側は、ウェイト軸の先端が数ミリ動きますし、DEC側はマウント部がやはりカタカタと動きます。なんとか調整してみることにしました。やはりCloudy Nightsで半日ほど検索し、次のサイトで明快に説明されていることが分かりました。


https://www.cloudynights.com/topic/476391-the-new-sky-watcher-az-eq5-mount-debut/page-8#entry6637832

この説明画像をクリックすると、ファンさんのスペイン語のサイトに行きます。Googleで日本語翻訳するとなんとか分かります。なお、ファンさんはC4つのネジを緩めなくても調整できたと書いていますが、私の場合は4つとも緩めなければなりませんでした。これで、RADECもガタツキが完全になくなりました。なお、その後で、同じように分かりやすい動画も見つけました。

https://www.youtube.com/watch?v=pR0eKzJ2Cqc

この動画のCuivさんによると、上の4つのCネジは「完全に緩めてはならない」とのことでした。もしかしたら、私の調整はまずかったのかもしれません。なお、これでベルトのテンションも簡単に調整できます。できるだけきつくする方が良いという投稿もありましたので、いずれ調整し直そうと思います。

ただし、これによってガイドエラーが改善したという実感は得られませんでした。バックラッシュが影響するDEC側は、もともとガイドエラーが小さかったからかもしれません。次は8月のログですが、RAのエラーがDEC2倍になっています。

RAのピリオディックエラーを補正する

上のログから分かるように、RA側のエラーが大きいことから、星像が横長になることが説明できます。 しかし、これまでのいろいろな対策から、トータルのRMS1.3秒角程度には小さくできるようになりました。8月に比べると、DECの乱れが多少改善されています。しかし、ピリオディックエラーの影響がまだはっきりと見えます。なんとか、1秒角以内になるようにしたいと思っています。

ピリオディックエラーを補正するPECを使ってみることにしました。AZ-EQ5にはPPECもありますので、それも使ってみます。

EQMODAutopecと、PHD2のログを使ってPEカーブを作るPECPrepの両方を試してみました。いずれもEQMODPECと、AZ-EQ5PPECの二つを動作させてみました。しかし、改善されるどころか、かえって悪くなってしまいました。

これは妙です。PHD2のガイドをなしにしてPECPPECだけを動かすと、ある程度の補正効果はありますので、PECが動いていることは間違いありません。やはり星像は横長になります。

Cloudy Nightsで、AZ-EQ5ではPPECの信号のタイミングがEQMODと合わないために、うまく補正ができないというSoyuzさんの投稿がありました。

https://www.cloudynights.com/topic/664717-mount-encoder-performance-testing-and-related-discussion/page-4#entry9431417

私には、技術的な説明は理解できないのですが、ST4を使うか、Green Swamp ServerGSS)を、EQMODに代えて使わなければならないとのことです。ST4では、空の位置が変わるたびにキャリブレーションをやり直さなければならないようですので、これは却下することにしました。なお、PECについてはうまくいくように書いてありますが、私の場合はだめでした。

GSSは、SkyWatcherOrion赤道儀に特化した、EQMODに代わるドライバーのようで、インターフェースは使いやすくできています。接続すると次のような画面になります。 

PHD2NINA、ステラリウムからも赤道儀としてうまく認識されます。しかし、これでもPPECPHD2はうまく動きませんでした。EQMODと同じように、PPECを使わない場合よりガイドエラーが大きくなります。さらに、動作が不安定なようで、ストールすることがありました。またParkHomeを異なる場所に設定できますが、両者を同じように設定しても、違うところに行ってしまいます。というわけで、GSSは当面使わないことになりました。

ここで行き詰まったわけですが、赤道儀にEQMODに加えてEQMOD_2があることに気づきました。これはいくらネットで調べてもわからないために、使ってみることにしました。


まだ一日使っただけですが、全く同じように動作しますし、PECを作り直してPPECにしてみましたが、なんとか動いているように見えます。


この日(1031日)はほぼ満月ですし、シーイングも良くありませんでした。DEC側がずいぶん乱れているのはそのせいでしょうか(そうであれば良いのですが)。おかげでRADECのエラーの差が少なくなり、星像は比較的丸く見えるようになりました。


これから

EQMOD_2をしばらく検証してみようと思います。これでもだめならガイドをST4にしてみるしかありません。他にどんな方法が考えられるのでしょう?


※追記(2020/11/04)
GSServerのビデオを見て、Parkの設定方法が分かりました。また、鏡筒への接続はNINAなどから直接行わないで、GSServerを介して行うことも分かりました。単なるドライバーではなく、サーバーと呼ばれる所以ですね。もう少し試行してみます。AG-EQ5のエンコーダーは精密なものではないので、オフにしておくのが良いという情報もありました。