Difference between revisions of "STIX Bulk Science Data"
| Line 12: | Line 12: | ||
software running on a LEON3 processor then proceeds along | software running on a LEON3 processor then proceeds along | ||
three parallel paths: | three parallel paths: | ||
| − | + | * a primary path that handles the X-ray imaging and spec- | |
troscopy data; | troscopy data; | ||
| − | + | * a quick-look (QL) path that supports the generation of light | |
curves and other products used to monitor the performance | curves and other products used to monitor the performance | ||
of the instrument and to provide a continuous overview of | of the instrument and to provide a continuous overview of | ||
solar activity; | solar activity; | ||
| − | + | * a calibration path that acquires data needed to establish the | |
energy calibration of each detector/pixel. | energy calibration of each detector/pixel. | ||
</big> | </big> | ||
Revision as of 07:00, 26 May 2021
Onboard data handling
The design driver for the IDPU’s X-ray data processing is the need to reconcile an input stream of up to 800,000 photons per second (∼20 Mbits/sec) to a telemetry budget of 700 bits per second. This is done by combining rapid FPGA sorting and ac- cumulation of individual events with slower application software that processes the accumulator contents. Figure 17 indicates the overall data flow. The goal of the FPGA’s prompt processing is to sort and sum the input photon stream into accumulators on the basis of their detector ID, pixel ID and detected energy in keV. Application software running on a LEON3 processor then proceeds along three parallel paths:
- a primary path that handles the X-ray imaging and spec-
troscopy data;
- a quick-look (QL) path that supports the generation of light
curves and other products used to monitor the performance of the instrument and to provide a continuous overview of solar activity;
- a calibration path that acquires data needed to establish the
energy calibration of each detector/pixel.
