GPS 受信機による不完全な PC 時刻同期値の補正・修正
宮下和久*
2022 年 2 月 10 日 17:43(UTC)頃に起きた(245)Vera(13.4 等級)による TYC 285-00908-1（10.9等級）の掩蔽の観測で、加瀬部久司氏の GPS 受信機が動作トラブルに陥った。そのおりに、加瀬部氏が行った対処と確認、記録、そして報告から、それらのトラブルの原因と時刻の補正量を得ることができたので報告する。これは、機材のトラブルがあっても、適切な対策を講じることにより問題を解決して正しい時刻値を得ることができる典型的な事例であり、またそれは、基本的な観測手順を確実に行うことの大切さを示している。加瀬部氏から許可をいただいたので、以下に紹介する。筆者は、皆様の観測時の参考になさっていただくことを願うものである。

１．GPS 受信機に関して、観測時に起こったこと
加瀬部氏は、観測報告で次のように記述している（表 1）。
表１ 加瀬部氏による観測報告（一部抜粋）
５.減光がおきた場合の時刻(UT)：

Limovie ver. 0.9.99.5A(Aqua)5i7 による解析

減光時刻：17h43m33.011s +/- 0.003s
復光時刻：17h43m38.393s +/- 0.003s
減光時間：5.382s
PC 内部時計と GPS の同期は「GPS_Clock」で行い「誤差”0”」と表示されていたが、SharpCap のタイムスタンプ表示は、時刻確認のための GHS 時計・Timeis（スマホ）・電波時計とは目測で約１秒進んでいた。
７.時刻保持方法
PC 内部時刻はＵＳＢ型ＧＰＳモジュールＧＴ－７３０ＦＬ－Ｓで同期。GHS 時計＋Timeis＋電波時計で確認。
GHS 時計の LED 1pps 発光を観測の前後に約 60 秒撮影。
但し今回は上記５項の問題があり、１時間くらい設定や再接続を何度も試みたが一致できなかった。
この観測は、加瀬部氏がこの受信機を使い始めた時期に行われた。加瀬部氏は、受信機のボーレートと同期ソフトの設定が異なるものであることに気づかずにいて、正常な時刻が得られないことから受信機の電源を何度も入れなおしていた（後日の JOIN にて加瀬部氏の投稿内容からまとめて示した）。
加瀬部氏が使用していた GT730-FL は、うるう秒などの情報の記憶期間の短い機種である。そのため、この観測時には UTC に対して進んだ時刻を示していた。それがスマートフォン上のTimeis や LED 照射用として用いていた GHS-OSD の示す UTC 時刻との時刻値の差となって現れていた。また、同期ソフトウエア GPS-Clock は、GT730-FL の出力する時刻値を、センテンス出力時のタイミングで PC の時刻をセットしていた。一方、GHS-OSD は、GPS システムの与える UTC の正秒のタイミングで確実に LED の点灯を行っており、それがビデオに記録された。
* 本稿に述べている解析は IOTA/EA 惑星および小惑星による掩蔽部局
観測・解析支援担当- 1 して行いました。ただし、本稿は、筆者個人としての立場で書いています。の業務と以上が、加瀬部氏の「報告」から読み取ることのできる、観測時の状況である。これを元に、それぞれのことがらを検証しながら、うるう秒の扱いの不具合によって多分正しく求められていないであろう現象時刻の「復元」を進めていこう。

２．ビデオの解析結果(1) ライトカーブと回折フィッティング
Limovie による解析手順としては、次項の SharpCap Timing Analysis の方が先に行う必要があるが、私たち観測者が現象後にすぐにライトカーブを求めたり、仮に時刻をフィットで調べたりするのと同じように、まずは光量解析をしてみよう。

← 対象星

図１ 観測ビデオと測光から得られたライトカーブ
左上： 観測ビデオ

左下： 測光領域と星像（PSF 測光） 右： 得られたライトカーブ

図２ 回折曲線のフィットにより、現象時刻を求める
ただし、この時点では LED を用いた時刻補正および GPS の秒値の補正はなされていない。

ライトカーブを図１に示す。中間の値は、フレーム露光期間中に減光や増光が始まったものと考えられる。また、図２に回折シミュレーションとのフィットの結果を示す。
全体的に、ノイズの少ないライトカーブであり、S/N=10 ほどと良好な観測がなされたことを示している。また、減光直後および増光開始直前にわずかに高い光量となっているが、これは光の回折のシミュレーション曲線とは離れており、重星の可能性もあるかもしれないが、現象時刻の測定への影響は微小であるので、この議論には含めない。

- 2 -３．LED による時刻補正の様子

図 3 LED 光の発光タイミング
画面全体が LED 光で明るくなっており（精度を考えるともう少し明るさが欲しいが…）、LED 信号の点灯を示す S1 ランプ（画面左下）が赤く点灯している。その左側にある Threshold 値を適切に設定することで、LED 点灯をこのような形で示すことができるが、解析作業においてこれは必須ではない。

図３は、SharpCap Timing Analysis 後における、LED 発光時のフレーム時刻を示したものである。右下の水色の地で示されているものが補正後の時刻である。Field1[17h44m41.9956s]がフレーム露光の中央時刻、Field2[17h44m42.0207s]がフレーム露光終了時刻である。一方、キャプチ
ャソフトはこのフレームの終了時刻として[17h44m41.527s]を与えている。これは、Limovie のSharpCap Timing Analysis 機能が、SharpCap の与えたフレーム終了時刻の秒値を活かす形で、LED の点灯時に正秒となるように時刻補正を行ったためである。この作業の時点では、あくまで見かけ上であるが、SharpCap は UTC に対して 0.493 秒遅れていた、と見ることができる。しかし、前出の加瀬部氏の報告からわかるように、SharpCap の与えた秒値が適正でない可能性が高いので、ここではあくまでも仮の「遅れ」である。

4．GPS 受信機はうるう秒情報の受信前には何秒進んでいたか
GPS 受信機は、うるう秒の情報が衛星から取得できるまでは、一定の秒数進んだ値を出力する。
進みの量は、機種によって異なる。その詳細については、本稿末の付録 2 を参照いただきたい。
それではこの観測で使用された GT730-FL の進みの量はどのくらいだろうか。それを調べるた
めに、図４に示すような実験を行った。
まず、観測時と同じように、3 日間放置して記憶用電池を放電させた状態の GT730―FL を用意した。次いで、PC を GT-902PMGG（DSR 信号線経由での 1PPS 信号を PC から利用可能）とHACSTIP-GPS Ver. 2 を利用して、PC のシステムタイムを+/-0.20msec 以下の誤差で UTC と同期させた。そこに GT730-FL をつなぎ、もう一つの HACSTIP-GPS Ver. 2 を起動させて、GT730FL が電波受信を開始してからの GGA センテンスの出力時刻値とそのタイミングについて測定と記録を行った。その結果を図 5 に示す。

- 3 -

GT-902PMGG

GT-730-FL
GGA

RMC

1PPS

HACSTIP-GPS (1)HACSTIP-GPS (2)getsetPC system time
図４ うるう秒情報受信前の GPS 受信機が出力する秒値の UTC に対する進みの測定

Delay of GPS receiver’s timefrom UTC (msec)
Time (sec)
図 5 うるう秒情報取得前後における GT730-FL の出力秒値の UTC に対する進み遅れの変化
縦軸は UTC に対する受信機出力の「遅れ」を表す。最初は 1700msec ほどの「進み」であるが、195 秒目に 300msec ほどの「遅れ」となった。
図５から、この受信機は UTC に対して 2 秒進んだ秒値を出力していることが読み取れる。最初 1700msec の進みで、うるう秒情報受信後は 300msec の遅れであるが、これは、GGA センテンスが UTC の正秒よりも 300msec 遅れて出力されるためである。付録１の表から、この受信機のファームウエアは 2012 年 7 月１日から 2015 年 7 月 1 日の間のどこかの時点で書かれたものであろうと推測される。

5．観測時に、キャプチャ中の画面のタイムスタンプが「約 1 秒」進んで見えたのはなぜか？
なぜ 2 秒ではないのか？
加瀬部氏は観測報告の中で「GHS-OSD の表示時刻やスマートフォンの Timeis の時刻よりも約 1 秒進んで見えた」と記している。前項の測定だとうるう秒情報の受信までは 2 秒進んでいるはずである。これはなぜだろうか？ たしかに 300msec 遅れた時刻補正がなされている可能性が高いのだが、それだと「1 秒」よりも長く、2 秒近くに感じるはずである。

- 4 -この謎を解くカギは、GT730-FL のセンテンス出力順序（表２）にある。
表 2 受信機のセンテンス出力順序
Type of prior(or pivot)
sentence
Products

RMC leads other sentences

GGA leads other sentences

VK172, Doctradio

GT730-FL

Garmin18xlvc, Garmin15

AE-GNSS-EXTSNT+ANT SET

GT902PMGG
Sentence

1. RMC (Date, Time, Site etc.)

order

2. GGA(Time, Site etc)

1. GGA(Time, Site etc)
…………

…………

n+1 GSV(Information of satellites)

n+1 GSV(Information of satellites)
n+2 GSV(Information of satellites)

n+2 GSV(Information of satellites)
…………

…………

n+m GSV(Information of satellites)

n+m GSV(Information of satellites)

n+m+1 RMC (Date, Time, Site etc.)

多くの受信機は、最初に RMC センテンスを出力する。PC 同期ソフトウエアにとってこれは好都合である。なぜなら、PC の「時計」の役目をするシステムタイムは、1601 年 1 月 1 日 0:00:00
を起点とする、10 ナノ秒を単位とした整数で時刻を扱っているからである。そこに時刻値をセットすることで時刻同期を行うのであるから、セットする値には年月日の情報が必須である。GGA行はこの年月日の情報を持たないので、時刻同期に用いるには不都合である。他の何らかの手段で年月日の情報を得なければならないからである。
時刻同期ソフトウエアは、センテンス文の扱いとして、現時点で 3 種類が存在する。
（表 3）
表 3 ソフトウエアによるセンテンス文の扱いの違い
1. RMC 行のみを扱うことのできるソフトウエア （GPS-Clock）
2. RMC 行と GGA 行を設定で切り替えることにより扱うソフトウエア （Satk）
3. RMC 先行タイプと GGA 先行タイプを自動的に判別するソフトウエア (HACSTIP-GPS)
この観測時に加瀬部氏が使用していたソフトウエアは GPS-Clock である。このソフトウエア
は RMC 行のみを扱うため、PC への時刻のセットは RMC 文出力を受け取った時点で行われる。
すでに前項で述べたように、GT730-FL では GGA 文の出力は UTC 後 300msec ほど経ってから行われることが実験で確かめられているが、RMC 文の出力は表 2 から推測できるように、更に遅いタイミングとなるはずである。そこで、GT730-FL について GPS-Clock を用いて時刻同期を行ったとき、PC のシステムタイムがどのように「同期＆補正」されていくかを実験で確かめた。
実験方法は、基本的には 4 項に示すものと同様である（図 6）。
ここではうるう秒受信後についての状況が得られればよいから、GT730-FL は起動後充分に時間をおいてから使用した。まず、準備として、GT902PMGG と HACSTIP-GPS の組み合わせにより、UTC と PC システムタイム双方の時刻を精密に取得＆記録ができるようにしておく。

- 5 -次に、PC に GT730-FL をつなぎ、GPS-Clock を起動させて、GPS-Clock に時刻設定動作を任せる。これにより、加瀬部氏が観測に使ったのと同じ組み合わせで時刻補正が行われるようになる。
（ただし、異なるのはうるう秒時刻情報の受信後である点であるが。）
まとめると、GT730-FL と GPS-Clock の組み合わせがどの程度正しく時刻補正を行うことができるかを、GT902PMGG と HACSTIP-GPS の組み合わせで測定し検証しようとするものである。

GT-730-FL

GT-902PMGG
RMC

1PPS

RMC

GPS-Clock

HACSTIP-GPS
getsetPC system time

図 6 受信機 GT730-FL とソフトウエア GPS-Clock による時刻同期の正確性の検証法

図 7 GT730-FL と GPS-Clock の組み合わせによる時刻同期のようす
図 7 から、GT730-FL と GPS-Clock を組み合わせた場合には、RMC 行の出力タイミングにより 550msec から 380msec の遅延が発生していることが読み取れる。300msec と、ほぼ一定であった GGA 行による時刻補正の遅延に比べて、著しく幅の広い補正タイミングである。これは、ひとつには、GT730-FL が、GSV 行を出力するときとしないときがあるためであり、またもうひ
とつは、GPS-Clock は時刻補正を毎秒行っているわけではなく、UTC（センテンス受け取り時、という意味であるが）との差が一定量に達した時のみ時刻補正を行うためである。ここで注意しなければならないのは、図７は RMC 文の出力タイミングの全てを表しているわけではなく、GPSClock が必要と判断して時刻補正を行った結果である、ということである。

- 6 -ここで、第 3 項および図 3 に戻って考えてみよう。
正秒を示す LED が点灯したようすが図 3 に現れている。このとき、キャプチャソフトはフレーム露光終了時刻として[17h44m41.527s]を与えている。また、LED 補正後のフレーム露光終了時
刻は[17h44m42.0207s]である。この両者の差は約 493msec である。
この遅延量は、図 7 から、GT730 と GPS-Clock の組み合わせで時刻補正を行った場合での、UTC に対する遅延の値のうち、GPS-Clock 起動直後付近の補正遅延とほぼ一致する。加瀬部氏は何回も GT-730 を起動しなおした、と述べていることからも、受信機の再起動直後に GPS-Clockが時刻補正を行った結果が反映されたものと推測される。
以上から、ビデオのフレーム画面に書き込まれたタイムスタンプは、Limovie の SharpCap
Timing Analysis により補正された時刻より、493msec 遅れた値であることを示している。
一方、第 4 項および図 5 が示すように、GT730-FL がうるう秒受信前に出力する時刻値は 2.000秒だけ進んでいるので、タイムスタンプの時刻の進みは、 2.000 – 0.493 = 1.507(秒) であったことになる。なお、キャプチャ画面にも表示の遅延があるだろうことを考えるとこの進みの時間は更に小さなものになり、更には秒値の整数値のみを比べれば「1 秒の差」に見えるだろう。以上により、加瀬部氏の「約 1 秒進んでいるように見えた」との報告を矛盾なく説明することができる。

6．まとめ
加瀬部氏の観測は、GPS 受信機と時刻同期ソフトウエアがうるう秒情報の受信前に PC の同期を行ったことにより、1.000 秒を単位とする値の時刻ずれが発生していた。更にそこにセンテンス文の出力の UTC に対する遅延が加わり、少し複雑な「時刻ずれ」を示していた。本稿に述べた解析と実験の結果、GPS 受信機による時刻ずれは 2.000 秒の「進み」であることが明らかになったことから、報告時刻を次のように修正することにより正確な現象時刻を得ることができた（表 4）。
表 4 減光がおきた場合の時刻(UTC)--- 修正前（報告値） ---------------------------------------------------------------------------減光時刻：17h43m33.011s +/- 0.003s
復光時刻：17h43m38.393s +/- 0.003s
減光時間：5.382s-------------------------------------------------------------------------------------------------------- 修正後 ----------------------------------------------------------------------------------------減光時刻：17h43m31.011s +/- 0.003s
復光時刻：17h43m36.393s +/- 0.003s
減光時間：5.382s-----------------------------------------------------------------------------------------------------このような秒ずれの現象が起きたとき、正確な時刻が不明となってしまう場合も多い。加瀬部氏の観測から正確な時刻を「復元」できたのは、次のような点が有効にはたらいたからであると考えられる。
1. Timeis などの他の時刻ソースと、キャプチャフレーム画面の時刻値の比較を行った。
2. 目視での時刻ずれも含めて、観測手順について要点を不足なく詳しく報告した。
3. LED 発光に、信頼性の高い受信機を用いていた。

- 7 -特に、前 2 者は観測においてたいへん重要である。加瀬部氏の観測は、これらの要点を確実に押さえて観測と報告をおこなえば、仮に GPS 機器に不具合が生じても、それを補って正しい現象時刻を求めることができる好例である。あらためて氏の観測姿勢に対して敬意を表するとともに、読者の皆様にもひとつの事例として参考にしていただきたいと思う。
また、このような時刻ずれが補正されていない観測時刻は、整約図において、「特定の絶対的な誤差を持った」値として扱われるべきではない。たとえば、時刻ずれの発生している観測には必ず *.*（定数）秒の誤差を与えて計算する、などである。S/N から推定できる誤差値は、GPS により起こる時刻ずれの値よりも小さいことがふつうであるし、時刻ずれそのものも付録の表に示すように様々な値となることからもいかにそれが不適切な取り扱いであるかが理解できるだろう。
この点もここで、明確に述べておきたい。

謝辞

加瀬部久司氏には、本稿の原案にあたる解析結果をお読みいただき、また、公開する許可を与えていただきました。この事例が皆様の観測に役立てていただけることを願いながら、加瀬部様に心より感謝申し上げます。

参考文献
HACSTIP Ver. 2 の開発とそれを用いた時刻補正の精度の検証
http://astrolimovie.info/limovie/cmos/Verification_of_software_and_hardware_%20using_new_version_of_H
ACSTIP.pdf
掩蔽現象観測用 GPS 受信＋1PPS-LED ちょうちんコバンザメ(Lantern Sharksucker)の製作
http://astro-limovie.info/limovie/cmos/Lantern-Sharksucker.pdf
国立天文台 [暦 Wiki] 全地球測位システム (Global Positioning System; GPS)†https://eco.mtk.nao.ac.jp/koyomi/wiki/GPS.html
GPS による汎用時刻保持装置の開発, 早水 et. al., 2001, 国立天文台報https://www.nao.ac.jp/contents/about-naoj/reports/report-naoj/p73.pdf
GPS の NMEA フォーマット
https://www.hiramine.com/physicalcomputing/general/gps_nmeaformat.html
NMEA 0183 の情報 （Garmin 社）
https://www8.garmin.com/manuals/webhelp/gpsmap7400-7600/JA-JP/GUID-891D6EC7-169E4146-8279-8400626217D0.html- 8 -【付録１】 当該の現象【付録 2】GPS 受信機と時刻ずれについて

GPS 受信機を PC につないで時刻同期ソフトウエアを動作させたとき、時刻が「1.000 秒、2.000秒、3.000 秒…」などと、きりのよい秒数でずれて表示されることがある。ここではその現象について説明する。
GPS システムが扱っている時刻は、「1980 年 1 月 6 日 0 時 0 分 0 秒 UTC から数えて通算何秒目か」という「整数値」である。そのため、GPS システムは、UTC や JST に用いられていて日頃私たちが使うような年月日時分秒といった時刻の概念を基本的には持っていない。GPS 受信機
は、私たちに便利になるように、UTC（協定世界時）の値に変換してから PC に出力しているのである。
ところが、私たちが使っている UTC や JST には、地球の回転の変化に合わせるように、時折「うるう秒」が挿入される。これはうるう年のようにある決まりに従って挿入されるのではなく、地球の回転に合わせて行われるので不定期である。したがって、GPS 受信機は、うるう秒の実施年月日の情報がなければ、正しく UTC を計算できなくなる。例えば、もし 1 回分のうるう秒についての情報がなければ、GPS は UTC より 1 秒早い時刻値を出力してしまうことになる。
GPS は 1980 年を起点とした総計秒数で時刻を扱うが、その間、今日までにうるう秒が 18 回挿- 9 -入されている。もし GPS 受信機がそのすべてを知らずに動作しているとしたら、UTC との差は18 秒になる。しかし、実際には 18 秒も進んだ時刻を出力する受信機など身の回りに存在しない。
受信機はうるう秒について、次の 2 段構えで補正して、時刻値を出力するからである。
(1) 受信機のファームウエアに書き込まれているうるう秒の情報を使って補正すべての受信機には、その設計がなされた（ファームウエアが書かれた）時点までのうるう秒の回数についての情報が書き込まれている。したがって、発売直後に購入して使用すれば、そのときは過去の全てのうるう秒が補正されるから、正しい時刻値を出力していることになる。
ところが、設計されてからユーザーが使用するまでの間にうるう秒が挿入されると、受信機はそれを知らずに時刻値を出力する。うるう秒で 1 秒遅れさせられた UTC に対して、受信機はうるう秒を入れない、UTC より 1 秒進んだ時刻値を出力してしまう。うるう秒の挿入が設計後 2 回行われて入れば、2 秒進んだ時刻値を出力することになる。
表１に、ファームウエアの書かれた時期の異なる GPS 受信機がうるう秒情報を受信する前に出力する時刻の UTC に対する進みを示す。
表１ うるう秒挿入に対する製品設計のタイミングと、うるう秒情報受信前の時刻の進み
1980 年からの年月日

うるう秒情報受信前の UTC に対するうるう秒挿入回数
第 2７回

時刻値の「進み」(2022 年 1 月 1 日時点)
2017 年 1 月 1 日

A 製品のファームウエアが書かれる
第 26 回

進んでいる

C 製品は、UTC より 3 秒

進んでいる2009 年 1 月 1 日

D 製品のファームウエアが書かれる
第 23 回B 製品は、UTC より 2 秒

2012 年 7 月 1 日

C 製品のファームウエアが書かれる
第 24 回進んでいる

2015 年 7 月 1 日

B 製品のファームウエアが書かれる
第 25 回A 製品は、UTC より 1 秒

D 製品は、UTC より 4 秒 進んでいる

2006 年 1 月 1 日(2) 衛星から送られてくるうるう秒の情報を使って補正(1) のままだと、時刻値としては使えない。そこで受信機は、1 秒などのずれをもった時刻を出力しつつ、衛星からのうるう秒の情報を待つ。衛星のうるう秒についての情報は、12.5分に 1 回の割で出力される。これはちょうどエンドレスビデオのようなもので、どのタイミングから見始めたかによって、ほしい情報が得られるまでの時間は異なる。ただ、最大 12.5分待てば、途中で受信が途切れない限り、それまでの間に必ずうるう秒の情報を受信できる。
そして、この情報を受信した瞬間から、受信機は正しい UTC の値を出力するようになる。
(3) 受信機のメモリに記憶されたうるう秒情報を使って補正
GPS 受信機の中には、情報を記憶するメモリと、それが動作するための電池を搭載したものがある。このような受信機の場合には、起動後しばらくして衛星電波を受信した時点で、正しい UTC の値を出力する。ただし、内部電池が切れて情報が保持できなくなったときは、(2)の機種と同様の状況となる。

- 10 -