Difference between revisions of "STIX Bulk Science Data"
| Line 1: | Line 1: | ||
== Onboard data handling == | == Onboard data handling == | ||
| − | The design driver for the IDPU’s X-ray data processing is | + | <big>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 | 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 | per second (∼20 Mbits/sec) to a telemetry budget of 700 bits per | ||
| Line 20: | Line 20: | ||
– a calibration path that acquires data needed to establish the | – a calibration path that acquires data needed to establish the | ||
energy calibration of each detector/pixel. | energy calibration of each detector/pixel. | ||
| + | </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.
