Disk VSN: HOB+0126, Data volume at beginning: 85 GB
- Pointing solution: 2015.023.23:10:04.24#fivpt#xoffset 223.1793 79.2251 0.00554 -0.01362 0.00242 0.00285 1 1 1618m49
Disk VSN: GSFC+022, Data volume at beginning: 85 GB
- Pointing solution: 2015.023.23:09:44.20#fivpt#xoffset 175.8087 54.1101 -0.00089 0.00246 0.00199 0.00424 1 1 1618m49
- UT 14:44 Single alarm sounded at 14:40
ALARM: scan_check reports Mark5 data format problemlooks to be no consequences or repetition. (JS)
Disk VSN: USN-0002, Data volume at beginning: 24 GB
- Note that iread values are bad (S-band):
- The following point checks were done:
- 2015.023.23:14:09.20#fivpt#xoffset 150.4285 64.2660 0.05054 0.00538 0.00707 0.06890 0 1 1618m49
- 2015.023.23:41:07.22#fivpt#xoffset 105.3795 39.5677 0.00000 0.00538 0.01255 0.06890 0 0 1921-293
- 2015.023.23:52:16.17#fivpt#xoffset 163.0582 67.6059 0.00000 0.00538 0.00620 0.06890 0 0 1618m49
- The first scan (3C279 at 024-0000) was missed. It appears that bank A of the mk5 does work properly. The troubleshooting was as follows:
- USN-0002 could not be recorded to in bank A, so it was swapped with HOB+0031 in bank B.
- USN-0002 could be recorded to in bank B - the module is fine. Swapped to bank A for the schedule.
- Schedule started, and mk5 issued errors on recording; I thought I checked recording in bank A after the swap, but it appears I did not. Recorded to bank B in time for the second scan.
- UT 12:43 iread values are still bad but haven't drifted (JS)
- The long and short of the disk swap business above is: The module that needs to be recorded to next (AUG005 @11am local time) is in bank A, but Chris was unable to verify if bank A can be recorded to. This module may need to be physically moved to bank B for recording. (JS)