NEOの(152637) 1997 NC1が明日2026年6月27日に地球に最接近します。CAFS FOR (152637) 1997 NC1
5月半ばからライトカーブを取得すべく、晴れた日は光度観測を行ってきましたが、なかなか自転周期が求まりません。地球との位置関係の変化が大きい為かもしれませんが、悩ましいです。明日、台風一過で晴れたら、掩蔽観測と最後の光度測定したいと思います。
下記は、6月23日の晴れ間に撮った(152537) 1997 NC1のGifアニメです。

NEOの(152637) 1997 NC1が明日2026年6月27日に地球に最接近します。CAFS FOR (152637) 1997 NC1
5月半ばからライトカーブを取得すべく、晴れた日は光度観測を行ってきましたが、なかなか自転周期が求まりません。地球との位置関係の変化が大きい為かもしれませんが、悩ましいです。明日、台風一過で晴れたら、掩蔽観測と最後の光度測定したいと思います。
下記は、6月23日の晴れ間に撮った(152537) 1997 NC1のGifアニメです。

ブログの更新が4年も滞っていましたが、レンタルサーバーも更新されましたので、再開したいと思います。まずは今帰還中のArtemis-IIの画像です。場所の情報は、NASAのJPL HorizonsのサイトHorizons SystemからArtemis-IIの情報と観測場所、観測期間、書式を設定してDLしました。
撮影は4月6日AM2:50~2:55と3:20~3:30、4月8日AM1:00~2:40(ファイル大きすぎて載せられず)、4月9日AM2:55~3:35です。いずれも見た目の移動速度が10″/min以下と遅かったので、露出時間を16秒、32秒とかけられました。






撮影機材:
鏡筒:Celestron C14 +Starizona Hyperstar f/1.9,
カメラ:ZWO ASI294MM Pro(冷却設定0℃)Gain:120 Exp.16sec(4月6日),32sec(4月9日)
Gifアニメ:50msec/frame
架台:タカハシNJP Temma II
撮影ソフト:Sharp Cap Pro 4.1 解析ソフト:Tycho v13.3
久々の投稿になります。以前からISSを手動の経緯台とテルラドファインダーを使って高射砲の様にバシャバシャと1眼カメラ使って撮ってました。でも、なかなか思うように撮れず、カメラ画像認識の自動追尾でやる方法が無いのかなあと検索していましたら、昨年の今頃にAstronomy Live (https://www.youtube.com/c/messierhunter/featured) というYoutubeサイトでメンバーになればSatTrakerという光学追尾ソフトを使えると分かったので、早速環境を整え、とりあえず出来るようになりました。(https://youtu.be/w2Ot7q6K_iM)
ただ、このソフトでは追尾カメラがDirectShowドライバでないといけないなど、いろいろ使いづらいのと、動作が不安定なところがあっても、作者が忙しい様で、改良があまり進まなく、不満がありました。
今年の2月ごろ、CloudyNightsで、閉ループ制御で人工衛星を追尾するソフト開発を改良しているので、興味ある人を募集しているという話を見つけ、コンタクトしてみました。すると同じiOptron AZ Mount Proを使って追尾するとのことで、テスターとして仲間に入れてもらいました。
このソフト pypogs(the PYthon Protable Optical Ground Station)は元々、人工衛星とのレーザー通信の為にESAで2019年に開発されGithub上で公開(https://pypogs.readthedocs.io/en/latest/)されているもので、その名のとおりPythonで記述されています。主メンバーはJPL(ジェット推進研究所)のエンジニアで趣味で天文をしているR氏と このソフトのオリジナル作成者で元ESAで現在MITのG氏というすごい人達です。
彼らとはDiscordというLINEに似たテキストや音声でコミュニケーションできるツールで、やり取りしています。もちろん英語なのですが、DeepL翻訳のプラグインを使うことで あまり苦も無く出来ています。便利な世の中になってきましたね。
最初はPCのPython環境確認、Githubからのpypogsのインストール、架台とカメラの設定など、手取り足取り教えてもらいながら実施してきて、実際にISS追尾でき始めたのは、3月12日でした。(https://youtu.be/QXI7orzas8M)右画面にクリオネの様なISSがフラフラと踊ってます。^^;
これをPIPPというソフトで動きを止めて拡大するとこうなります。(https://youtu.be/u-ioTUw78ow)
4月に入ってからは、夕方観測が多くなったので、画像が良くない状態が続きました。また、MITのG氏もR氏とは別にオリジナルを改良したものをリリースしてきたので、それも確認するようになってきました。その場合架台はセレストロンのNexstarSEです。この辺の話は、また明日以降記載しようかと思います。
昨日の記事でPPSプロジェクションユニットに、投影用のレンズが必要な話を書きましたが、今日になって、他のレンズの模索中に、LEDをある位置に置くと、きれいな縦線が画面の横に出来たのです。
その場所は、OAGの光を入れる穴のそばから4㎜位ずれた位置です。早速発泡ポリエチレン板を加工し、LEDを保持する円盤を作成し、取り付けてみたら良好な結果となりました。
これまで、遠回りしていたみたいで、半分がっくり来たのですが、これで、ZWO社のOAGを入手するだけで、他の部品も不要で、簡単な工作で良いので、このPPS発光プロジェクションユニット(PPS Flash Projection Unit)の作成ハードルが大きく下がったと思います。


年末にCMOSカメラを使った場合の掩蔽観測に有用なユニットを試作しました。
なぜ、このようなものを作ったかといいますと、これまでのアナログCCDカメラに代わり、最近高感度高速特性を持つ惑星撮影用のCMOSカメラを使った掩蔽観測を行うようになってきたのですが、これにはSharpCapというソフト使い、時刻はこのソフトのTimeStampで記録していました。
ところが、このTimeStampの時刻は、PCの時刻を元にしているため正確ではありません。それゆえ、GPSモジュールを使い、PCの時刻補正を行った上、GPSモジュールのPPS信号をLEDで発光したものを、観測の前後の時間に、望遠鏡の先端にかざして撮影することで、正確な時刻補正をしていました。
ただ、常々、この作業が面倒なことと、実際の観測時とは異なる時刻に、違うフレームサイズ・レートで行うこと(1msecの時間分解能を求めるのにフレームサイズを小さくして1000fpsとか)が、実際の撮影フレームサイズ・レートに対し、正しく補正出来ているのか疑問に思っていました。
理想は、掩蔽撮影と同時に画面の横の端で上から下まで縦長にPPS発光画像が、観測画面に被らず共存することです。 (望遠鏡の先端にかざす方法は、画面いっぱいに光が広がるので、共存できない)
縦長が良い理由は、CMOSカメラ画像は 横方向スキャンにはほとんど時間差が無い が縦方向にスキャンに時間差があり対象星と同じ縦位置でPPS発光を読み取らないと、実際のタイミングにならないからです。
これを実現する方法を探してみたのですが、望遠鏡の斜め前からコリメータを使ってカメラに投影する方法
http://www.occultations.org/meetings/NA/2017Meeting/Olsen_TalkSlidesShort.ppt
や、 小型化だが複雑な構造のもの
http://www005.upp.so-net.ne.jp/k_miyash/occ02/timer.html
がありましたが、手軽ではありません。
1番目の資料中に、天体撮影に使われるオフアキシスガイダーの写真があり、これを通常とは逆向きにして、ガイダーカメラを入れる方から画面の端に画像を投影しては?とありました。ただ、どうやって画像を投影するかが問題で、これは2番目の資料のアイデア(ハイゲンス接眼レンズをばらして1個のレンズを投影に使った)で行けないかなあとも思いました。
自分の持っているオフアキシスガイダーは9mm厚の薄型で良さげでしたが、プリズムを逆差し出来ない構造になっており、全体を逆向きにするには接続リングを工夫しないと難しそうでした。そこで、ZWO社のサイトで OAGの写真をみて見ると、プリズム逆差し出来そうな感じに見えました。価格も年末価格で$115だったので、思い切って発注。
投影用に使うハイゲンス接眼レンズは昔の24.5mm径(ツアイスサイズ?)のものしか無いようでしたので、いつも通っている天文台で古い望遠鏡をたくさん持っている 台長さん に、いらないハイゲンス接眼レンズもらえないかと尋ねたら、8mm,9mm,20mmの3つを分けていただきました。この中で簡単にバラせたのは20mmのものだけで、8mm,9mmは出来ず。
この20mmをバラしたレンズのどちらをどの様に投影したら良いかがわからなかったのですが、CMOSカメラの前に レンズをかざして、PCの画像が見える距離を探ったりして、接眼側のレンズが投影できそうなことがわかりました。これをきちんと保持する方法として、24.5-31.7mm変換アダプタをヤフオクで入手しました。
そうこうするうちに、ZWO社からOAGが到着し、確認すると案の定、プリズムをカメラ側に逆差し出来ることがわかり嬉しくなりました。早速、ASI290MMのT2ねじに接続、プリズムの長さをCMOSセンサの近くまで引き出し、ハイゲンス接眼レンズの片側を24.5-31.7mm変換アダプタにさかさまに入れ、OAGに差し込んでみました。
ASI290MMをPCにつないで、画像を見ると、右端から明るく光が被っていますが、なぜか差し込む光の加減で縦に直線状になるところがあります。これは!と思って、LEDを手で開口部付近をかざしながら探って観てみると、なんと光軸の中心から少し外れたところに、画面端が縦にきれいな直線状に光る場所があったのです。これはLEDの光がレンズで集光後、 ボケた 円形に形になりそれが、光軸の中心からずれたことにより、プリズムのエッジで半分に切られた状態になったと推測されます。
この位置を忘れないよう、テープなどで仮固定、穴あけして型紙とし、加工しやすい2.4mm厚発泡塩ビを25mm径にサークルカッターで何枚か切り出したものを両面テープで重ね貼り、型紙位置に穴あけを行って、PPS発光LEDを差し込めば完成です。
なお、撮影露光時間により、LEDの光量を変化させないといけないので、LEDには可変抵抗を接続したほうが良いです。
以上の様にして制作したのは下記写真になります。



現在、上記写真にある解析ソフトLimovieの作者の方が、このユニットを使用して時刻を正確に合わせる機能を作成いただいており、間もなく完成予定です。
ただし、 1msecレベルの時刻合わせが可能となるには、どんな露光露光時間でも良いのでなく、今のところ3ms~333msの間の12種類の条件で撮影時間は1分から1.5分必要ですが、掩蔽観測ではそれくらい行うことが普通なので、問題無いと思います。
このPPSプロジェクションユニットは、本体の入手性は良く、専門的な加工が無くて良いのですが、レンズの入手性だけがネックです。百均の双眼鏡の接眼レンズが候補ですが、固定方法が定まらず、まだ再現できていません。何か良い方法が見つかれば、紹介したいと思います。

最近自分の中で熱が入っているのは電視観望で。上記写真は最近のスタイルです。
構成は架台がSkyWatcherのAZ-GTi、鏡筒はタカハシのFS-60CB、カメラはZWOのASI385MCにx0.5のレジューサー付与(実質0.72倍)、PCはNECのwinTABでSharpCaptureで見せています。
この架台のAZ-GTiですが、購入したのが4月3日ですぐに観望始められたのですが、アライメントをしても、対象星が数度ずれる位とても自動導入精度が悪かったので、がっくりしました。このときは本体の作成精度の悪さかと思い、代理店に電話しようと思ったくらいです。CloudyNightのサイトを見たら なんとコントロールソフトのSynScanPro ver1.15はバグにより導入精度が悪くなっているとのこと。改善されたver1.16のAndroidやWindowsにはリリース早かったのですが、iOSは3日遅れでやっと出ました。
ただ、このSynScanProは対象星をリストから選ぶタイプで、今までSkySafariのような星図から導入する形に慣れている私にとって使いにくいものでした。そこでiPhoneとiPadを連携させてSkySafariコントロールをトライしてみましたが、上手く行きませんでした。仕方なく、古いAndroidタブレットでSynScanProを動かし、iPadのSkySafariとリンクさせることに成功しました。
でも、なんだか大げさになってしまった感があります。。
昨年から検討していたイタリアのDynamic Optics社製のAOですが、やっと国内代理店から概算価格が提示されました。
ただ、その概算価格が想定をはるかに超える金額(安いドイツ車が買える)で、これまで聞いた性能に対してあまりにもコストパフォーマンスが悪く感じましたので、断念することにしました。
残りのStellar Products社製にかけることにします。
2019年1月4日の晩、しぶんぎ座流星群の極大があるとのことで、カメラを自宅から北東の方角にセッティングし、撮影しました。
同時に撮影したUFOcaptureによる記録と照合すると、4枚流星が写っていました。
今回はそれらを含め、いつものタイムラプスにしたものです。
今夜靄っていましたが、明日雨が降りそうなので、気になっていた46P/Wirtanen彗星を撮ってみました。尾があまり見えない彗星ですねえ。
EOS-6D SEO-SP4 ISO1600 20秒x18枚 135mmF2.8アポゾナー、 CD-1赤道儀 ステライメージ8、PhotoShopCCで処理
