Payload Operation Challenges

4.4.1 Payload Power On/Off Statistics

The payload powered-off statistics shown in Figure 4-8 were analyzed from Day 2006-175 to Day 2007-105. Before Day 2006-175, the 8^o off angle in earth sensors haven’t been fixed and the GOX has not been ON for continuous 24 hour. We also excluded the action events done by the operations team such as flight software and common spacecraft database upload, and some processors reset by the team, etc. The events for payload off reduce the science data volume. The goal of the statistics is to realize the causes of payload off. During the one year operation, the causes of payload off are categorized to: (i) processor reboot, (ii) entrance to stabilized/safehold mode, (iii) stabilized mode after thrust

power contingency due to staying nadir mode too long, (vi) dMdC (Derivative of Battery Molecular to Charge) anomaly, (vii) FM2 power shortage, and (viii) Power Control Module (PCM) DC off anomaly [31]-[32], [61].

4.4.2 GOX Payload Reboot Loop

Two kinds of reboot loop anomaly events were observed, one is the GOX instrument will automatically reboot itself when there is no navigation solution for 15 minutes. This happened on FM1 and FM6 in the past. The other kind of reboot anomaly is that consecutive reboots occurred every 15 minutes. When GOX has this kind of anomaly, GOX instrument still could be automatically recovered by power cycle command. FM6 had the later kind of reboot anomaly occurred in February and April of 2007 recently, however, FM6 didn’t recover by itself. The root cause was preliminary identified as low signal-to-noise ratio (SNR) of the navigation antenna when the spacecraft was entered into beta angle between 0 and -30^o. A new firmware (FB 4.4) was loaded in June to enable to selection of the other healthy antenna as the navigation antenna. The reboot loop stopped since then.

[31]-[32], [61]

4.4.3 Solid State Recorder (SSR) Data Overflow

The SSR data storage only allocated 32 Mbytes (MB) for GOX-B out of 128 MB total memory. During the constellation deployment phase it was always possible to accumulate GOX data more than 32 MB before dumping the data to the ground. When the data overflow took place, it always came along with the data wrapping (disorder) because the 32 MB was not an integer numbers of the science data packet size, and the write pointer of the SSR would pass over the read pointer when data overflow occurred. To resolve this issue, the operations team narrowed the GOX field of view to control the data volume. When the spacecraft orbit planes separated and the availability of ground pass became better, the team opened up the GOX’s field of view and scheduled the dump to prevent the occurrence of SSR

data overflow. The auto-scheduling tool was generated to optimize the ground station utilization so as to minimize data dumped. After all spacecraft reach the final constellation with the orbit phasing under control, the loss of data due to SSR overflow no longer occurred [32], [61].

4.4.4 Maximizing Science Data Downloads

A total of 84 data dumps per day can be realized when all six spacecraft reach the final mission constellation. In the early phase of the mission, only a total of 12 data dumps (2 per each spacecraft) in a day could be executed, primarily due to the cluster formation during the constellation deployment phase. The GOX firmware was upgraded to improve the quality and the quantity of the science data as the satellite constellation configuration (such as altitudes, field of views, etc.) changed. In parallel, optimization efforts were implemented to the spacecraft operations processes, the ground software, the ground control auto scripts, and the spacecraft flying formation, etc. to maximize the number of science data dumps per day.

Currently there are around 66 dumps on average per day, a dramatic increase from the 12 dumps a day as originally planned [32], [61].

4.4.5 GOX Data Gapping Issue

The GOX data gapping problem is that 29% of RO science data has gapping issues.

After investigating questionable raw data, we found that a similar data dropout pattern has been observed in the ground End-To-End (ETE) tests. However, the on-orbit gapping issue is much worse than that found in the ETE tests. Through several analysis and tests, it was concluded that when dumping the stored spacecraft data and science data simultaneously the data dropouts are the worst. The operations team made these two data dumps separately to recover the data dropout issue, and rescued 70% of the lost data. Even when the science data is downloaded alone, the data dropouts still cause 8% of data gapping. A typical dump has a very small amount of data dropouts (~0.04%), but it actually causes 8% of RO data gapping.

The remedy for reducing data gapping is to dump the same science data twice. Eventually, these two dumps will not drop the same data packets, so we can make up any dropout. The saved data from double dumps is only about 0.04% of the whole data volume, but the RO data will increase 8%. Hence, even though double dumps increase local data storage and double the data transfer time from ground station to the data analysis center, they are still worthwhile [32], [61].