How to Create a Data Request IOR

From stix
Revision as of 17:35, 21 June 2021 by Daniel.ryan (talk | contribs) (Created page with "== Important Background Information == === What is a Data Request IOR? === A Data Request IOR includes sets of instructions for STIX to process its observations into certain...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

1 Important Background Information

1.1 What is a Data Request IOR?

A Data Request IOR includes sets of instructions for STIX to process its observations into certain data products (e.g. L1 or L4 Spectrogram) and send them back to Earth. These instructions correspond to data requests made by the community or the STIX team. (To learn more, see What is a Data Request?) Data Request IORs can only be issued during STIX Analysis Windows which are scheduled and defined on SOOP KITCHEN.

1.2 Data Request IOR Criteria

A Data Request IOR must be compiled in line with the following criteria:

  • Highest priority data requests must be included first. Data Requests can have three priorities: High, Medium, and Low.
  • The total number to telecommands in a single 24 hour period must be less than 150. This includes any other IORs that send commands on the same day. However, this limit is not always a hard one. Sometimes ESA does accept slightly more than 150 telecommands in a single day.
  • The total data volume of the requests must be within the telemetry budget defined for the STIX Analysis Window. This will be recorded on SOOP Kitchen for the given analysis window.

While the telemetry budget should not be exceeded, current algorithms tend to over-estimate the data volume of data request IORs. Moreover, it is important not to waste telemetry as we can not utilized unused telemetry budget afterwards. It is therefore important to use as much of the budget as possible.

1.3 Data Request Status

Data Requests have one of three statuses:

  • Executed: The requested data has been received from STIX by the STIX Data Center and is available.
  • Processed: The data request has been included in an IOR on the STIX Data Center server, but the data has not yet received. This could be because the IOR has not been sent to STIX. Or the IOR has been sent but the data has not yet been received by the STIX Data Center server.
  • Pending: The data request has been succesfully saved to the STIX Data Center server, but has not yet been included in an IOR by the STIX operators.

1.4 Relationship to Other IORs

While it is possible to mix data requests with other telecommands, it is standard prcatice to create an IOR just for data requests and another for other operations telecommands. An exception might be to include non-data request telecommands that MUST be run during the STIX analysis window. This makes it easier to ensure that STIX is operating nominally during the STIX analysis window and the telecommand limit of 150/day is being used more efficiently. Therefore, IORs should not overlap in time.

2 Generate a Data Request IOR

2.1 Required Software

See Required Software.

2.2 How to Generate a Data Request IOR

  • To process data requests, STIX must be in Configuration or Nominal mode. Confirm that STIX will be in of these modes when the STIX analysis window starts. This is usually determined by the IOR sent at the start of the STP which power cycles the instrument.
  • Confirm no other IORs are sending commands during the STIX analysis window.
  • Save the data requests from the STIX Data Center as a JSON file, using a URL API.
  • Open STIX-Starlet and load in the data request JSON file by clicking yellow "open json" button.
  • Change the Action Time of the 2nd telecommand to +1s after the 1st.
  •  ???
  • Once ready, Submit IOR for Internal Review in the usual way.
  • Once approved by the STIX team, Submit IOR to SOC in the usual way.

2.2.1 Unprocessed Notes

  • The script that converts the data requests to JSON groups the data requests together by detector and pixel mask. After these are executed, there needs to be a wait time to ensure that all of them a re downloaded before changing the masks for the next batch.
  • Hualin makes this delay 12 hours from his personal experience. The amount of time per spectrogram to be generated onboard is not known. Can get an idea from the CPU load of the telemetry.
  • Can request high cadence Aspect data. Aspect data in HK is low resolution. These data requests must sent sequentially. The delay between requests must be long enough for previous aspect data request ot be processed. (By contract, spectrogram data requests will be queued, so the wait time between telecommands doesn't matter.) This means we have to change the action times of aspect data commands. This can be estimated by whether the aspect observation time period is long or short. Hualin usually leaves 1 hour between each aspect request. But you MUST BE CAREFUL is the aspect obs time period is long.