EOVSA system knowledge¶
This page is the public map of how the main EOVSA systems fit together. Use it to follow a signal, command, telemetry value, or data product to the detailed documentation for that part of the system.
Public documentation boundary
This site describes the instrument and its scientific and operational concepts. Credentials, private access details, and sensitive control procedures are not published here. Authorized operators should use the internal EOVSA Operations Knowledge Hub for current runbooks and verify live behavior against the deployed system.
System at a glance¶
| Stage | What happens | Detailed documentation |
|---|---|---|
| Solar signal and antennas | The antennas collect solar radio emission; feeds and front ends prepare the two polarization channels. | Hardware overview, 2.1-m antennas, 27-m antennas |
| Analog conversion | Optical transport, frequency conversion, and attenuation place the selected radio-frequency bands into the digitizer input range. | Frequency tuning and downconversion, attenuation and level control, radio-frequency interference |
| Digitization and correlation | Digital backends sample the signals and form total-power and interferometric data. | Correlator modes, computing systems |
| Control and telemetry | The schedule and control system coordinate observing; stateframe telemetry records the reported instrument state. | Control commands, schedule commands, stateframe database |
| Calibration and processing | Calibration measurements and processing pipelines turn instrument output into science-ready visibility, spectrogram, and image products. | Calibration procedures, delay calibration, EOVSA flare pipeline |
| Data access and analysis | Public products are distributed through the EOVSA Data Browser and analyzed with the documented Python, SSWIDL, CASA, and SunCASA workflows. | EOVSA data products, data analysis tutorial, EOVSA Data Browser |
In compact form, the primary science path is:
Sun → antenna and frontend → optical/RF conversion → digitizer and correlator → calibration and pipelines → archive and data products
The control and telemetry path runs alongside it:
observing schedule and commands → instrument control → stateframe telemetry → monitoring, calibration records, and observing logs
A healthy telemetry connection does not by itself prove that the analog signal is healthy, and a poor science spectrum does not by itself establish a control or database failure. Start diagnosis at the boundary where the symptom first appears.
Find knowledge by question¶
-
What is the signal path?
Follow the antennas, front ends, frequency conversion, attenuation, digitization, and correlator.
-
How is EOVSA controlled?
Start with the observing schedule and command references, then use the stateframe documentation to interpret reported state.
-
How are measurements calibrated?
Select pointing, total-power, gain, delay, polarization, or baseline calibration from the calibration map.
Open calibration documentation · Go directly to delay calibration
-
How do data become products?
Trace visibility and total-power data through calibration, imaging, quicklook generation, and public distribution.
-
How do I analyze the products?
Use the local-file Python examples, SSWIDL references, CASA/SunCASA workflows, and advanced analysis guides.
-
Something looks wrong
Begin with the public troubleshooting guide. Hardware-changing or service-changing actions require the authorized internal procedure.
Procedures and references¶
The system procedures and references directory gathers the public observing, calibration, instrument, control, database, and data-processing pages in one place. It includes direct routes to procedures such as delay calibration that otherwise sit under a separate subject tab.
Knowledge sources and freshness¶
The documentation has three complementary layers:
- This public site provides the current public system map, scientific documentation, user tutorials, and non-sensitive observing guidance.
- The internal EOVSA Operations Knowledge Hub is the maintained source for operational architecture, diagnostics, incidents, and authorized runbooks.
- The original wiki archive preserves historical notes and earlier procedures. Treat archived procedures as historical until checked against a current source.
For claims about what is operating now, live telemetry, logs, deployed configuration, and active service or schedule entrypoints take precedence over documentation. Update the maintained source when a system relationship or procedure changes, record the review date, and publish only the portion that is appropriate for public use.
Public system map last reviewed: 2026-08-21.