Bringing radiospectra into the Modern SunPy Ecosystem

What is radiospectra? 

If you've ever looked at a spectrogram of a solar radio burst i.e. a colorful time vs frequency heatmap showing how the Sun's radio emission changes during a flare then there's a good chance the data was handled by radiospectra. It's a Python package in the SunPy ecosystem that provides tools for fetching, reading and visualising solar radio spectral data from instruments like e-Callisto, WIND/WAVES and SWAVES.

Radiospectra plugs into SunPy's unified data search through Fido, meaning you can query and download radio data from multiple observatories with a few lines of Python in the same way you'd fetch solar images or timeseries data.

The problem: a foundation that hasn't kept up 🔍

While radiospectra works, its internal architecture hasn't evolved alongside the rest of the SunPy ecosystem. Here's the core issue:

Spectral data is stored as plain NumPy arrays with instrument-specific metadata conventions. There is no unified mapping between physical coordinates like time, frequency and array indices. Each instrument client handles axis ordering and metadata differently. If you want to slice a spectrogram by a time range, subtract a background or combine data from two instruments that means you're writing boilerplate code every time.

Compare this to sunpy.map, which provides a coordinate-aware Map object built on Astropy's WCS (World Coordinate System). With a Map, you can slice by solar coordinates, overlay data from different instruments, and plot everything with correct axis labels and doing all through a single, consistent API. Radiospectra has no equivalent.

This also means radiospectra doesn't integrate with NDCube, the SunPy-affiliated package designed specifically for multi-dimensional coordinate-aware data. NDCube provides slicing, coordinate transforms, and visualization out of the box but it is possible only if your data is built on WCS. Right now, radiospectra can't take advantage of any of that.

What needs to change 🤔

The fix isn't a patch, it's a redesign of the core data object. Specifically:

A new Spectra class built on NDCube and WCS so that every spectrogram carries its own coordinate mapping. You'd be able to call something like spectra.axis_world_coords('time') or slice with spectra[time_start:time_end, freq_low:freq_high] using physical units, not raw indices.

Built-in analysis tools like background subtraction is one of the most common operations in solar radio analysis, yet radiospectra has no built-in support for it. Methods like auto_const_bg, subtract_bg, and randomized_auto_const_bg (commonly used in tools like the e-Callisto software) should be part of the core API along with an extensible interface for custom operations.

Visualization that handles real-world data cause solar radio data is messy. There are data gaps, missing frequency channels, irregular time sampling and masked values. The plotting tools need to handle all of this gracefully with sensible defaults and customisable output.

Documentation and examples is important cause a redesigned API is only useful if people can learn it. Gallery examples, Jupyter notebooks and Sphinx API docs are essential.

My connection to this project 

I've been contributing to radiospectra over the past months. I restored the WIND/WAVES Fido client (#158), fixed spectrogram plotting behavior and submitted several other PRs (#144, #151, #142, #163). Through this work I've read through much of the codebase and understand where the architectural seams are.

I also opened issue #143 to propose design questions upfront about API style, coordinate behavior, data model choices. The maintainer confirmed these are exactly what the GSoC project will tackle during community bonding, which gave me a clearer picture of the design space ahead.

This project sits at the intersection of software architecture and scientific usability, which is exactly where I want to spend my time. The goal isn't just to refactor code but it's to make solar radio spectral analysis as accessible and interoperable as solar image analysis already is with sunpy.map.

What's next

I'm applying to work on this as a GSoC 2026 project under SunPy / OpenAstronomy. If selected, I'll be working with mentors @samaloney and @hayesla over 12 weeks+ to build and ship the redesigned API.

I'll be posting updates here as the project progresses. 

- By Kumar Amityush