[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jamsat-bb:5148] Re^:QT98 Y2K (2000.2.29)
藤田さん、芝山さん、みなさん
QT98_V4.0JのY2K問題についてのレポート、どうも有り難うございました。
結論から述べますと、アップデート・データの更新方法に係わって生じる不具合
であることが判明しました。
>軌道要素元期の整数部分"2000年"を、"1999年" の通日加算と見なす書き換えの
>方法で、ORB00063.Nは QT98 V4.0Jでも OKでした。
私も、同様の方法により試してみたところ、各衛星とも正常にアップデートされ
ていることが確認できました。なお、加算日数は通常の365日加算でOKでした。
>私は初歩的な考察しかできませんが、また既に確認すみとは思いますが、文面か
>ら、大谷さんのＰＣの内部時計が、３月以降１日だけ進んでいるようなことはな
>いでしょうか。
２台のパソコンで、同一方法（QT98のEDITモードで、EPOCHのみ修正・再入力）に
よる比較を行ってみた結果、やはり同様の不具合の発生を確認しました。
どうやら、このアップデート方法は、閏日の影響を受けてしまうようです。（今回
は通日処理によらず、EPOCH 再修正によるアップデート方式をとっていました。）
>本来、暦の計算をするユリウス暦だったか何たら暦だつたかの計算方法を組み替えれ
>ばよいのでないですか。
このプログラムは、もともとユリウス暦を使用したものですが、軌道要素を実際の
暦に当てはめる段階で不具合が発生し、この結果として１日ずれた計算結果を出力
しているものと思われます。
>細かいご説明は不要ですが、何が問題なのかについてコメントいただけませんでしょ
>うか。
以下のとおり、同じ周回のパスを表示して比較してみると、明らかに不具合が発生
していることが分かります。つまり、目的とするパス（上段）が１日遅れ（＋１日）
て出力される（下段）ことになり、特にリアルタイム・トラッキングでは既に１日
遅れの同時刻のパスが画面に表示され、全く意味のないデータとなってしまいます。
SCHEDULE FOR SATELLITE SO-35 at JH4DHX/3
DATE AOS MAX LOS EPOCH DX Range AZ EL ORBIT
10MAR100 234747 235458 000209 11MAR10 1157 259 38 5494
11MAR100 102056 102542 103028 11MAR10 2234 89 8 5501
11MAR100 115831 120511 121150 11MAR10 699 278 69 5502
11MAR100 234748 235455 000201 12MAR10 1230 260 35 5494
12MAR100 102043 102538 103032 12MAR10 2146 88 9 5501
12MAR100 115829 120508 121148 12MAR10 736 278 62 5502
SCHEDULE FOR SATELLITE AO-27 at JH4DHX/3
DATE AOS MAX LOS EPOCH DX Range AZ EL ORBIT
10MAR100 231619 232203 232748 10MAR10 2288 90 11 33645
11MAR100 005435 010207 010939 11MAR10 845 295 70 33646
11MAR100 023601 024049 024538 11MAR10 2630 301 7 33647
11MAR100 231607 232204 232802 11MAR10 2199 91 12 33645
12MAR100 005432 010204 010936 12MAR10 878 291 64 33646
12MAR100 023606 024042 024517 12MAR10 2707 302 6 33647
SCHEDULE FOR SATELLITE UO-14 at JH4DHX/3
DATE AOS MAX LOS EPOCH DX Range AZ EL ORBIT
11MAR100 135121 135744 140407 11MAR10 1981 268 16 52891
12MAR100 002658 003351 004043 12MAR10 1554 95 25 52898
12MAR100 020620 021321 022022 12MAR10 1302 291 33 52899
12MAR100 135129 135743 140358 12MAR10 2068 268 14 52891
13MAR100 002651 003348 004045 13MAR10 1473 95 27 52898
13MAR100 020619 021316 022013 13MAR10 1374 291 30 52899
>ただ、１９００年と２０００年については、「００」と表示する以上、何らかのプロ
>グラム上の「だまし(しかけ)」が必要な気がしますが・・・
はい。そのために色々と工夫しながら、QT98に軌道要素を読み込ませているわけです。
>※なお、この対応は1999年の通日処理でも可能だと思われますが、確認はして
> いません。その際に注意すべきことは、この場合も通常の365日加算を364日
> の加算として、-1日のオフセットをとることが必要となることです。
通日処理では不具合の出ないことが明らかになりましたので、当面は、この方法に
よるデータと比較しながらアップデート作業を行いたいと思います。
また、何等かの事情により通日処理ができない場合、或いは同種類の不具合が発生
した場合には、3月9日付書き込み [jamsat-bb:5141] QT98 Y2K (2000.2.29)による
方法をお試し下さい。また、既に述べましたが、加算日数のオフセットは必要なく
365日とし、364日にすると逆に１日ずれることも、この比較結果から分かりました。
皆さんからの御指摘、どうも有り難うございました。
ＪＨ４ＤＨＸ／３ 大谷 Mar.11 2000