About the Project
Inspiration
Jupiter is one of the most powerful natural radio sources in our Solar System. Its radio emissions contain complex structures such as S-bursts, L-bursts, and other transient patterns, but studying these signals can involve large amounts of audio data and specialized analysis.
I wanted to build a tool that would let me explore these signals computationally rather than treating them simply as interesting sounds. The idea behind Jovian Pattern Engine (JPE) was to create a complete research workbench that could ingest recordings from different missions and observatories, detect interesting structures, compare them, and reveal patterns that would otherwise be difficult to inspect manually.
The project started as an exploration of Jupiter's radio emissions and became a broader experiment in combining digital signal processing, machine learning, scientific visualization, and data provenance.
What I Built
JPE is a desktop scientific analysis application built around a processing pipeline:
Audio → Preprocessing → STFT → Peak Detection → Pattern Tracking → Classification → Comparison → Clustering → Visualization
The engine can process audio from sources including Voyager, Juno, Galileo, Cassini, U. Iowa, and ground-based observations.
The signal-processing pipeline uses:
- Short-Time Fourier Transform (STFT)
- Adaptive peak detection
- Frequency peak tracking
- Spectral features
- Spectral signatures
- Dynamic Time Warping (DTW)
- Cross-correlation
- Spectral flux
- Chroma similarity
- Cosine similarity
- KMeans, DBSCAN, and Agglomerative clustering
- PCA, t-SNE, and UMAP visualization
Detected structures can be represented as Pattern objects and classified into categories such as S-burst, L-burst, N-burst, Broadband, and Unknown.
The application also creates a connection graph between patterns using relationships such as spectral similarity, temporal recurrence, harmonic relationships, cross-file similarity, and machine-learning clusters.
For reproducibility, analysis sessions and detected patterns are recorded in a SQLite database, while results can be exported to formats including PNG, CSV, JSON, HDF5, MIDI, and HTML.
The Technical Challenge
One of the biggest challenges was discovering that "similar" does not necessarily mean "the same."
An early version of the analysis compared patterns primarily through a 68-dimensional feature vector. This could produce extremely high similarity scores between patterns that actually had very different frequency content.
That forced me to make the validation pipeline more rigorous.
I introduced a hierarchy of checks:
- Feature-vector similarity — compares statistical characteristics.
- Spectral similarity — compares actual frequency-content signatures.
- Raw audio correlation — provides a stronger test for waveform-level similarity.
This changed the way I interpreted the results. Instead of claiming that two detections represented the same Jovian event because a machine-learning feature score was high, the system now distinguishes between similar statistical envelopes, similar frequency content, and evidence of an actual matching event.
That distinction became one of the most important lessons of the project.
What I Learned
Building JPE taught me that scientific software is not only about producing an interesting result. It is equally about determining what the result actually supports.
I learned how DSP techniques such as STFT and peak tracking can transform raw audio into structured observations, and how machine learning can help organize those observations into clusters.
I also learned that validation has to be designed alongside the analysis itself. A visually convincing spectrogram or a similarity score is not automatically scientific evidence.
During analysis of a curated real-data corpus, JPE detected 384 patterns across 10 recordings and generated a large relationship graph containing 191,339 edges. The results revealed repeated structures within recordings and differences between mission datasets.
Importantly, the analysis also showed that some initially attractive interpretations were not supported by stronger spectral and waveform-level validation. JPE therefore treats those observations as limitations rather than presenting them as discoveries.
Challenges
The project involved several difficult engineering problems:
- Processing recordings originating from different missions and instruments.
- Handling different signal characteristics and recording formats.
- Detecting short transient patterns without producing overwhelming numbers of false detections.
- Comparing patterns that can vary in duration and frequency.
- Designing meaningful similarity metrics.
- Keeping Python processing fast enough for interactive analysis.
- Separating genuine observations from artifacts caused by instrumentation or preprocessing.
- Making the results reproducible and auditable.
JPE therefore uses Python/NumPy/SciPy as the primary processing backend, with an optional C++ backend using FFTW3, libsndfile, Eigen, and pybind11 for performance-sensitive workloads.
Why It Matters
Jovian Pattern Engine is not intended to replace scientific instruments or claim discoveries about Jupiter on its own.
Instead, it is a research and exploration tool: a way to turn large collections of Jovian radio recordings into structured, searchable, comparable data.
The larger idea is that scientific AI should not simply produce impressive-looking results. It should help researchers explore, test, challenge, and validate hypotheses.
That principle became the most important part of building JPE.
Log in or sign up for Devpost to join the conversation.