Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction and Timeline

Nominal Phase Segment 1 refers here to the first two orbits of the NMP, so roughly calendar year 2022, encompassing LTPs 06, 07, 08 and 09. It is the shortest period that can be planned independently of the rest of the mission, i.e. it contains a period during which the SSMM will not empty, so planning decisions made for LTP 06 will have an effect on the scope for operations in LTP 09.


Of course, the earlier the information comes, the more time we can spend planning and the better-optimised the end result will be.

The Link Between Remote Sensing Window Timing and the Scope for Data Generation

The data that can be generated during a particular period of scientific interest (e.g. a remote sensing window) is the sum of the data that can be downlinked during that window and the data that can be stored in the SSMM for later downlink. The latter is itself a function of how much data is already in the SSMM at the start of the period and crucially, how much data is expected to be stored in the SSMM during the next period of scientific interest, and how much data can be downlinked in between the two periods. Thus, the ideal case would be two intervals that are well-separated in time and take place during periods of good downlink. The worst case would be two concatenated intervals that take place during a period of bad downlink. Assuming the SSMM is not emptied at any point, any data that are generated in between the intervals (e.g. from a synoptic programme) are data that cannot be generated during the intervals of scientific interest.

Because the downlink rate is highly variable, the first step in assessing the scope an LTP period has for data generation, and the split between RSW and synoptic generation (equally applicable for high rate vs normal rate intervals for in situ instruments) is thus fixing the location of the remote sensing windows.

Proposed Remote Sensing Window Locations

During these early, low-inclination, orbits of the nominal mission phase, the default geometric placement of remote sensing windows doesn't make scientific sense. Instead we believe a reasonable trade-off between Sun-spacecraft distance and downlink performance, taking into account solar conjunctions, is to concatenate the three remote sensing windows from each orbit, so we have assumed two sets of 30 days covering these intervals:


By delaying the first set of remote sensing windows, it is possible to position their start so that they lie symmetrically relative to perihelion, but this comes with a downlink cost (see available trade-offs, below). In this proposal, the second set of remote sensing windows already start ~5 days after the end of the conjunction, this might be too close for comfort (MOC will need time with the spacecraft to check everything out post-conjunction, deal with any FDIR incidents etc., instruments might want to see their housekeeping data before doing anything complex) so we don't think it's possible to improve the geometry any further, indeed we may have to delay, but this has benefits for downlink, both during the windows and for data taken in the inter-window period.

Data Generation Scenario


The frequency of flushes is somewhat arbitrary. More frequent, smaller flushes would be better, but including these would have made building the plan more time consuming. Less frequent, larger flushes may not work when the SSMM is close to full.


In summary, with the assumed station coverage, we should be able to support:


In situ latencies are higher because of the high rate observations extending a couple of weeks after the end of the RSWs into the bad downlink period.

Special Considerations for PHI

To take into account the required processing time for PHI we have assumed the following:


This pattern will hold, to a greater or lesser extent, throughout the mission. Unless PHI wish to hold data internally for ~1 year, they will be more constrained than the other remote sensing instruments just before and during orbit legs where the spacecraft is outbound from Earth, but less constrained just before and during orbit legs where the spacecraft is inbound.

Data Accounting

With the strawman plan assumed above, all instruments are able to generate more data than the baseline. In total, the in situ payload can generate 215.5 GiBytes over the two orbits. The EID-A volume per orbit for in situ is 42 GiBytes. The remote sensing payload are generating 298 GiBytes over the two orbits compared to an EID-A per orbit volume of of 27 GiBytes.


Distance Range (AU)Day spentIS (GiBytes)IS (EID-A Orbit volumes)RS (GiBytes)RS (EID-A Orbit Volumes)
< 0.44640.30.9699.71.94
> 0.911652.71.2552.83.66

Scope for More Data Generation

The above plan essentially fills the downlink, apart from during the very good periods when the spacecraft is close to the Earth:


So the only scope for additional activities is during these periods. Of course, PHI could generate more in the first set of remote sensing windows if they were willing to keep those data internally until after the second set of remote sensing windows.

Available Trade-offs

  • Move first three RSWs by 5 days so they're centred on the perihelion.
    • Pro: Better range of Sun/sc distance
    • Con: Lose Sun-Earth line coverage
    • Con: Less scope for data generation - 11 GiBytes less downlink during the RSWs and we can't really carry that extra load in the SSMM, so it would mean downgrading the synoptics by the same amount of data (synoptics between windows are about 80 GiBytes).
  • More data for in situ so they can be in high rates whenever we're within 0.5 AU (not true currently). This would require about 8 GiBytes, so 10% of the existing inter-window synoptic programme, maybe a bit less.
  • Trade-off data between inter-window synoptics and RSWs. In practice this would mean trading off between RSW 3, the synoptics and RSW 4. Currently:
    • Inter window synoptics: 80 GiBytes
    • RSWs 1-3: 94 GiBytes
    • RSWs 4-6: 69 GiBytes
  • Move RSWs 4-6 later (note we're already close to the limit after the conjunction so this might have to happen anyway):
    • Pro: More data
    • Con: Already at 0.6 AU at the end of the current windows
    • Con: Perihelion is already on day 4/5 of the current 30

Possible Changes to the Pass Requests for 2022 H1 and/or 2022 H2:

  • We could request reduced hours per day in January/February when we are not filling the downlink and ask for more in April/May. We could also do the same in H2, i.e. fewer hours in November/December and more in the days before the conjunction. Either would relieve pressure on the SSMM and allow us to do more in RSWs 4-6 or during the inter-window period.