06-06-98

Version 1 of this file is a duplicate of the ephemeris file for 6/5/98. We didn't notice this until several months after we had used it (in algorithm version 4 processing) when we had some other problems with ephem files in the Summer of 1998. We looked back in our inter-ephemeris QA file and it had caught the error when comparing the 6/5/98 and 6/6/98 files during their definitive arc overlap period (1998-06-06T00:00:00 to 1998-06-06T10:00:00). The two files were identical over that period. (At that time, there was no flag in the QA code to bring that to our attention. We have since added that flag to the code.) We asked FDF for a new file and received a second version on 10/21/99. We used version 1 of the file in algorithm version 5 processing since the version 2 file was delivered just as reprocessing was starting, the version 1 file's predictive arc into 6/7/98 was very good, and the differences between the version 1 and version 2 files were small. We intend to use the version 2 file in algorithm version 6 processing.

JAXA contacted TSDIS in April, 2000, noting a descrepancy between their 6/6/98 2A21 intermediate temporal write file and ours. They looked into the problem and discovered that they had used a version 2 file for 6/6/98 that had been delivered by automated means a day after the version 1 file had been delivered (6/8/98). TSDIS did not know about this second file and never picked it up.

So, the file that FDF delivered to TSDIS on 10/21/99 was really the version 3 file and the file that FDF delivered to JAXA on 6/8/98 was the version 2 file.

We ran our intra-ephemeris QA code on all three versions of the file and all passed with similar results although the code gave the following message when run on the version 1 file:

Our inter-ephemeris QA code gives the following message when run on the version 1 file:

We did comparisons of definitive arcs for all versions of the 6/6/98 ephemeris file to the files for 6/5/98 (which was the version 1 file) and 6/7/98. We also did definitive arc comparisons of each version to the other versions. Below is a table of the results. The results are the difference between the two files in kilometers.

Even though the compares of the version 3 file to the 6/5 and 6/7 files are better than the compares of the version 2 file to the 6/5 and 6/7 files, TSDIS decided to use the version 2 file for the next round of reprocessing (V6). This is because the version 3 file was created using a different method than is normally used. It was created from the definitive archive and contains nine days of merged definitive arc data as opposed a normal TRMM ephemeris file which contains 34 hours of definitive arc data followed by 7 days, 14 hours of predictive arc data. The file is very accurate but there are slight jumps where the definitive arcs were merged. These jumps can be seen in the compare of the version 2 file to the version 3 file. The compare of the 6/5 file to the version 3 file is an exact match at the beginning of the compare reflecting the use of the 6/5 definitive arc to create the version 3 file. The compare of the version 3 file to the 6/7 file is an exact match at the end of the compare reflecting the use of the 6/7 definitive arc to create the version 3 file.

For more information on the files or plots of the compares, please contact Michael Hensley at TSDIS.

Version 1 of this file is a duplicate of the ephemeris file for 7/28/98. We didn't notice this until several months after we had used it (in algorithm version 4 processing) when we had some other problems with ephem files in the Summer of 1998. We looked back in our inter-ephemeris QA file and it had caught the error when comparing the 7/28/98 and 7/29/98 files during their definitive arc overlap period (1998-07-29T00:00:00 to 1998-07-29T10:00:00). The two files were identical over that period. (At that time, there was no flag in the QA code to bring that to our attention. We have since added that flag to the code.) We asked FDF for a new file and received a second version on 10/1/98. We used version 1 of the file in algorithm version 5 processing since the version 2 file was delivered just as reprocessing was starting, the version 1 file's predictive arc into 7/30/98 was OK, and the differences between the version 1 and version 2 files were small. We intend to use the version 2 file in algorithm version 6 processing.

We ran our intra-ephemeris QA code on both versions of the file and both passed with similar results.

Our inter-ephemeris QA code gives the following message when run on the version 1 file:

We did comparisons of the definitive arc for version 2 of the 7/29/98 ephemeris file to the files for 7/28/98 (which was the version 1 file) and 7/30/98. Below is a table of the results. The results are the difference between the two files in kilometers.

From the results of the compares, TSDIS decided to use the version 2 file for the next round of reprocessing (V6).

For more information on the files or plots of the compares, please contact Michael Hensley at TSDIS.

This file was the first in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-08-27T17:08:00.0 and 1998-08-27T17:09:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, and Pz at both times 1998-08-27T17:08:00.0 and 1998-08-27T17:09:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the second in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-09-01T17:19:00.0 and 1998-09-01T17:20:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-09-01T17:19:00.0 and 1998-09-01T17:20:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the third in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-09-07T16:34:00.0 and 1998-09-07T16:35:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-09-07T16:34:00.0 and 1998-09-07T16:35:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the fourth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-09-12T17:22:00.0 and 1998-09-12T17:23:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-09-12T17:22:00.0 and 1998-09-12T17:23:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the fifth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-09-22T16:28:00.0 and 1998-09-22T16:29:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-09-22T16:28:00.0 and 1998-09-22T16:29:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the sixth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-09-26T16:19:00.0 and 1998-09-26T16:20:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, and Vz at both times 1998-09-26T16:19:00.0 and 1998-09-26T16:20:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the seventh in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-10-01T16:37:00.0 and 1998-10-01T16:38:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, and Vz at both times 1998-10-01T16:37:00.0 and 1998-10-01T16:38:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the eighth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-10-06T17:17:00.0 and 1998-10-06T17:18:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-10-06T17:17:00.0 and 1998-10-06T17:18:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the ninth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-10-10T17:13:00.0 and 1998-10-10T17:14:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, and Vy at both times 1998-10-10T17:13:00.0 and 1998-10-10T17:14:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the tenth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-10-15T17:42:00.0 and 1998-10-15T17:43:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at time 1998-10-15T17:42:00.0 and our maximum limit for Px, Py, Pz, Vy, and Vz at time 1998-10-15T17:43:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the eleventh in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-10-19T17:26:00.0 and 1998-10-19T17:27:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-10-19T17:26:00.0 and 1998-10-19T17:27:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the twelth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-10-24T16:25:00.0 and 1998-10-24T16:26:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-10-24T16:25:00.0 and 1998-10-24T16:26:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the thirteenth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-10-30T17:22:00.0 and 1998-10-30T17:23:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vy, and Vz at time 1998-10-30T17:22:00.0 and our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at time 1998-10-30T17:23:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the fourteenth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-11-04T17:44:00.0 and 1998-11-04T17:45:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Pz, and Vy at time 1998-11-04T17:44:00.0 and our maximum limit for Px, Py, Pz, Vy, and Vz at time 1998-11-04T17:45:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the fifteenth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-11-08T17:40:00.0 and 1998-11-08T17:41:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-11-08T17:40:00.0 and 1998-11-08T17:41:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the sixteenth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-11-11T18:41:00.0 and 1998-11-11T18:42:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-11-11T18:41:00.0 and 1998-11-11T18:42:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the seventeenth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-11-16T17:37:00.0 and 1998-11-16T17:38:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-11-16T17:37:00.0 and 1998-11-16T17:38:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

This file was the eighteenth in a series of 18 ephemeris files throughout the Summer and Fall of 1998 which had jumps in the definitive arc state vector. We didn't have intra-ephemeris QA software to detect these jumps at the time. The first time we noticed the jumps was during the 11/8/98 IP. The TSDIS GV/TRMM Satellite coincidence code errored out on that day after calculating duplicate coincident events for the same orbit and GV site, a physical impossibility. The jump in the definitive arc state vector had caused the code to think that the satellite had backed up for an instant and then continued on so in effect passing the same GV site twice in one orbit. Once we had QA software in place to detect intra-ephemeris jumps, we ran the software on all the ephemeris files for the life of the mission and discovered the other 17 flawed files.

We discovered that all these jumps occurred at the first delta-v burn time of the reboost burn pair for that day. At the time, the reboost burn pairs were scheduled about every 4 to 5 days. The error occurred because FDF was not creating a smooth merge of the pre- and post-maneuver ephemeris solutions. Once we alerted FDF to the problem, they found a solution and sent us replacement ephemeris files for the 18 days.

Version 1 of this file failed our intra-ephemeris QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file:

The two TAI times in the table above correspond to 1998-11-22T17:02:00.0 and 1998-11-22T17:03:00.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, Pz, Vx, Vy, and Vz at both times 1998-11-22T17:02:00.0 and 1998-11-22T17:03:00.0.

Version 2 of this file causes several warnings to be written to our intra-ephemeris QA file but all warnings are minor so a new file is not needed. See explanation of version 2 file on the main ephemeris status page under the table entitled "EPHEMERIS FILES WITH MINOR FLAWS".

For more information on the files or plots of our QA output, please contact Michael Hensley at TSDIS.

TSDIS first noticed a problem with version 1 of this file when the inter-ephemeris QA failed while processing the ephemeris file for 1/1/99. There was a 7 kilometer along track disagreement between the files for 12/31/98 and 1/1/99 as shown below:

Note the along track difference of -7.623 kilometers between the ephemeris files for 12/31/98 and 1/1/99.

The following is a table or our inter-ephemeris QA limits. Note that the version 1 file exceeded our maximum along track limit at time 1999-01-01T02:40:18.714 where the check was made.

A leap second occurred at 1998-12-31 23:59:60 so TSDIS suspected that the disagreement was the result of how the ephemeris files handled leap seconds along with the way TSDIS used them since the TRMM satellite travels about 7 kilometers in one second.

TSDIS uses FORTRAN routines provided by the Flight Dynamics Facility (FDF) to read the ephemeris files. One of the routines, EPHEMRD, assumes that all the state vectors are always exactly 60 seconds apart, but the ephemeris file that crosses the leap second stores a pair of vectors (at 98-12-31 23:59:00 and 99-01-01 00:00:00) that are 61 seconds apart because of the leap second at 98-12-31 23:59:60. Thus, the Hermite polynomial interpolation gets messy when spanning the leap second. More important, however, the vectors interpolated for any times well beyond (minutes past) the leap second are actually for positions one second, or about 7 kilometers, ahead of the actual position. The only input to EPHEMRD for specifying the time desired for the interpolated vector is seconds from epoch, and that seems to assume there are no leap seconds.

A new ephemeris file was obtained in which the the leap second was removed and TSDIS processing was continued using this file for orbits 6294 and 6295. The interpolation problems over the year boundary were eliminated, however it was recognized later that this file had a separate problem when used by our routines. The epoch time for this ephemeris was in the new year even though the file started on 12/31/98. (Normally, the epoch time in the header is at the start time of the file, but it doesn't have to be.) Since our ephemeris interface uses this epoch time to associate the ephemeris time to our atomic (TAI) time representation, our time included a leap second where the ephem didn't. Thus we interpreted the ephemeris vectors as one second behind the correct times. This was recognized in coastline offsets on VIRS images.

The version 2 file start time was 1 second later than the version 1 file start time.

A second new ephemeris was obtained, in which the epoch time was at the beginning of 12/31/98, and again the leap second was removed (to keep even 60 second intervals in the file). This ephemeris file worked properly with our software to give correct geolocation (as confirmed with checks of coastlines in VIRS images). However by that point in time, the Dec 31 and Jan 1 products had already been delivered to the DAAC, and it was decided not to try to officially reprocess or replace them because of the limited impact of the error, difficulty in replacing them, and other processing priorities. The geolocation quality is flagged anyway in these products (with a value 4 for "questionable ephem or utcf", -- the actual reason being that the Level 1B processing QA recognized a change in ephemeris file from the one noted in the TSDIS database at the start of 12/31 processing.)

The version 3 file start time was aligned with the version 1 file start time.

TSDIS planned to have the latest ephemeris replace the original one sent to SDPF (and which was used in processing orbits 6280 to 6293). The second replacement ephemeris file (version 3), which our software can use to span the leap second correctly, can be used for reprocessing orbits 6280 to 6295 at the next regular reprocessing cycle.

Note there were some unrelated problems in handling the leap second which resulted in 1 or 2 second shifts in the data start and stop times relative to the orbit defined start/stop times. This just affected which granules picked up a few scan lines near the southernmost orbit point, for January 1 and 2, orbits 6294 to 6324.

Below is a table of the header data for the three different versions of the 12/31/98 ephemeris file:

If our intra-ephemeris QA software would have been installed at the time we received the version 1 file for 12/31/98, it would have failed our QA check with two jumps in the definitive arc state vector. The following is our intra-ephemeris QA data at the two jumps for the version 1 file. Also included is the maximum intra-ephemeris QA data for the version 2 and version 3 files for comparison.

The two TAI times in the table above correspond to 1998-12-31T23:59:60.0 and 1999-01-01T00:09:59.0, so within the part of the definitive arc that TSDIS uses for in daily processing.

Note that the magnitude of the position vector disagreement is about 7.5 km at both times corresponding to a 1 second displacement.

The following is a table of our intra-ephemeris QA limits. Note that the version 1 file exceeded our maximum limit for Px, Py, and Pz at both times 1998-12-31T23:59:60.0 and 1999-01-01T00:09:59.0.

TSDIS did compares of the definitive arcs of all three versions of the file to the definitive arcs of the 12/30/98 and 1/1/99 files and to eachother. Below is a table of the results. The results are the difference between the two files in kilometers.

Note from the compare results above that the version 3 file was the only file to have a good compare with the 12/30/98 and the 1/1/99 files. The other two file versions either had a 1 second (or more) disagreement with the 12/30/98 file or the 1/1/99 file or both.

The following is a plot of version 1 to version 3 compare data at the day boundary between 12/31/98 and 1/1/99 where the leap second occurs to point out that there may be a bug in the FDF provided ephemeris file reading software in the way it handles leap seconds. Note that the along track difference between the two files is 15 km (ie a two second offset) for close to ten minutes before going back to a 7.5 km (ie a one second offset) difference.

D

For more information on the files or plots of the compares, please contact Michael Hensley at TSDIS.

TSDIS first noticed a problem with version 1 of this file when the inter-ephemeris QA labeled the compare of the files for 1/12/99 and 1/13/99 as "questionable" while processing the ephemeris file for 1/13/99. There was a 0.919 kilometer along track disagreement between the files for 1/12/99 and 1/13/99 as shown below:

Note the along track difference of 0.919 kilometers between the ephemeris files for 1/12/99 and 1/13/99.

The following is a table or our inter-ephemeris QA limits. Note that the version 1 file exceeded our maximum along track limit at time 1999-01-13T02:18:48.011 where the check was made.

TSDIS did a minute by minute compare of the two files over the first 10 hours of 1/13/99 (their definitive arc overlap period) and discovered that the two disagreed by 1.271 kilometers early in 1/13/99. TSDIS asked FDF to look into whether the flawed file was the 1/12/99 file or the 1/13/99 file. FDF looked at the two files in question and decided to generate a version 2 file for 1/12/99. They gave no explanation of their choice to re-generate the 1/12/99 file other than "our orbit solutions for those days are of roughly the same accuracy, so neither ephem is "less accurate" than the other. Also, I don't think that there is a problem and, therefore, neither ephem is "bad"".

TSDIS copied over the new file on 1/26/99 and did compares of the definitive arcs of both versions to the definitive arcs of the 1/11/99 and 1/13/99 files and to eachother. Below is a table of the results. The results are the difference between the two files in kilometers.

The data above shows that along track, the version 1 file compare to the 1/11/99 file is much better than the version 2 file compare to the 1/11/99 file. The cross track and radial differences are comparable. The version 1 and version 2 file compares to the 1/13/99 file are comparable along track, across track, and radially. From the compares, TSDIS decided to use the version 1 file in algorithm version 5 processing and will use the version 1 file in future re-processing.

For more information on the files or plots of the compares, please contact Michael Hensley at TSDIS.

Version 1 of this file is a duplicate of the ephemeris file for 8/25/99. TSDIS' inter-ephemeris QA caught the error and TSDIS informed FDF. FDF generated a new ephemeris file which passed both our intra- and inter-ephemeris QA checks so we used it in our algorithm version 5 processing and will use it in future re-processing.

For more information on the files or plots of the compares, please contact Michael Hensley at TSDIS.

An accuracy concern was raised over the version 1 file for 2/11/00 due to a -2.011 kilometer along track jump at the switch over to the 2/12/00 ephemeris file (after the first full orbit inside 2/12). The cause of the error was associated with a large geomagnetic storm and temporary rise in the Kp Index. Replacement files for 2/11/00 and 2/12/00 could not be provided quickly because research into the problem was needed. Replacement files (version 2) were provided on 4/17/00. The version 1 files were used in algorithm version 5 processing and the version 2 files will be used in algorithm version 6 processing.

TSDIS did not realize there was a problem with the 2/11/00 ephemeris file until we received the 2/12/00 ephemeris file. When we ran our inter-ephemeris QA code on the version 1 2/11/00 and 2/12/00 files to compare their definitive arcs at the overlap, we got the following error message:

Note the along track difference of -2.011 km between the two files at the comparison time of 2000-02-12T02:39:48.077.

The following is a table or our inter-ephemeris QA limits. Note that the version 1 file exceeded our maximum along track limit a