Skip to content

From Radio Jupiter Pro to SQL

Radio Jupiter Pro is a Windows desktop application used by the Radio JOVE community — roughly 500 to 1000 amateur radio astronomers worldwide who monitor Jupiter’s decametric radio emissions. It predicts when Jupiter-Io interactions will produce radio bursts detectable from a given location, based on the Io orbital phase angle and Jupiter’s Central Meridian Longitude (CML, System III).

The application works. It has served the community well for years. But it has limitations that SQL can address: it’s Windows-only, it doesn’t export data for automated scheduling, and batch analysis over long time ranges requires manual date entry.

Jupiter emits powerful radio bursts at frequencies between roughly 15 and 38 MHz. The strongest emissions correlate with the orbital position of Io relative to Jupiter and with Jupiter’s rotation (the CML). The Carr et al. (1983) model maps source regions — labeled A, B, C, and D — onto an Io phase vs. CML diagram. When the current Io phase and CML fall within a source region, the probability of detecting a burst is elevated.

Both Radio Jupiter Pro and pg_orbit use this same underlying model.

  1. Launch the application (Windows only, or via Wine on Linux/Mac)
  2. Set your geographic coordinates in the preferences
  3. Set the date and time to the current moment
  4. Read the Io phase, CML, and source region prediction from the display
  5. Check whether a source region is active in the CML/Io-phase chart

There is no programmatic access. The result is on screen — you read it and decide whether to turn on your receiver.

This is where manual tools hit their limit. “When should I turn on my receiver tonight?” requires scanning hours of time at reasonable intervals.

In Radio Jupiter Pro, you would:

  1. Set the start time to sunset
  2. Advance time manually (or use the animation feature) in small steps
  3. Watch the CML/Io-phase indicator to see when it enters a source region
  4. Note the time and source region on paper or in a spreadsheet
  5. Repeat until sunrise

For a single evening, this takes 5 to 10 minutes of clicking. For planning a week of observations, multiply accordingly.

Planning a month of observations. Which nights have the best windows?

-- 30-day burst calendar: peak probability each night
-- Checks every 15 minutes between 00:00 and 12:00 UTC
WITH nightly_scan AS (
SELECT t::date AS night,
t,
jupiter_burst_probability(
io_phase_angle(t),
jupiter_cml('40.0N 105.3W 1655m'::observer, t)
) AS prob,
topo_elevation(planet_observe(5, '40.0N 105.3W 1655m'::observer, t)) AS jup_el
FROM generate_series(
now(),
now() + interval '30 days',
interval '15 minutes'
) AS t
WHERE topo_elevation(planet_observe(5, '40.0N 105.3W 1655m'::observer, t)) > 5
)
SELECT night,
round(max(prob)::numeric, 3) AS peak_prob,
(array_agg(t ORDER BY prob DESC))[1] AS best_time_utc,
round(max(jup_el)::numeric, 1) AS max_jupiter_el
FROM nightly_scan
WHERE prob > 0.1
GROUP BY night
ORDER BY night;

One query scans 30 nights and returns the peak burst probability for each, along with the specific time and Jupiter’s elevation at that moment. In Radio Jupiter Pro, this would require manually advancing through 30 separate nights.

If you maintain a database of past observations, pg_orbit lets you answer questions like “did I actually detect bursts when the model predicted them?”

-- Compare burst predictions with actual observation results
-- Assumes an observation_log table with timestamps and detection flags
SELECT o.obs_time,
o.detected,
o.snr_db,
round(jupiter_burst_probability(
io_phase_angle(o.obs_time),
jupiter_cml('40.0N 105.3W 1655m'::observer, o.obs_time)
)::numeric, 3) AS predicted_prob,
round(io_phase_angle(o.obs_time)::numeric, 1) AS io_phase,
round(jupiter_cml('40.0N 105.3W 1655m'::observer, o.obs_time)::numeric, 1) AS cml
FROM observation_log o
WHERE o.receiver = 'radio_jove_20m'
AND o.obs_time > now() - interval '1 year'
ORDER BY o.obs_time;
-- Detection rate by probability bucket
SELECT prob_bucket,
count(*) AS total_obs,
count(*) FILTER (WHERE detected) AS detections,
round(count(*) FILTER (WHERE detected)::numeric / count(*)::numeric, 2) AS det_rate
FROM (
SELECT o.detected,
CASE
WHEN jupiter_burst_probability(
io_phase_angle(o.obs_time),
jupiter_cml('40.0N 105.3W 1655m'::observer, o.obs_time)
) < 0.1 THEN '< 10%'
WHEN jupiter_burst_probability(
io_phase_angle(o.obs_time),
jupiter_cml('40.0N 105.3W 1655m'::observer, o.obs_time)
) < 0.3 THEN '10-30%'
WHEN jupiter_burst_probability(
io_phase_angle(o.obs_time),
jupiter_cml('40.0N 105.3W 1655m'::observer, o.obs_time)
) < 0.5 THEN '30-50%'
ELSE '> 50%'
END AS prob_bucket
FROM observation_log o
WHERE o.receiver = 'radio_jove_20m'
AND o.obs_time > now() - interval '1 year'
) sub
GROUP BY prob_bucket
ORDER BY prob_bucket;

This is the kind of analysis that’s impossible with Radio Jupiter Pro — it has no concept of historical data or past observations. The program shows you the current prediction and that’s it.

For operators who want to automate their receivers, pg_orbit can drive a scheduling system.

-- Generate tonight's observation schedule
-- Schedule 30-minute blocks centered on high-probability windows
CREATE MATERIALIZED VIEW tonight_schedule AS
WITH windows AS (
SELECT t,
jupiter_burst_probability(
io_phase_angle(t),
jupiter_cml('40.0N 105.3W 1655m'::observer, t)
) AS prob,
topo_elevation(planet_observe(5, '40.0N 105.3W 1655m'::observer, t)) AS el
FROM generate_series(
date_trunc('day', now()) + interval '1 hour',
date_trunc('day', now()) + interval '13 hours',
interval '5 minutes'
) AS t
),
high_prob AS (
SELECT t AS window_center,
prob,
el
FROM windows
WHERE prob > 0.3
AND el > 10
)
SELECT window_center - interval '15 minutes' AS rec_start,
window_center + interval '15 minutes' AS rec_stop,
round(prob::numeric, 3) AS probability,
round(el::numeric, 1) AS jupiter_el
FROM high_prob
ORDER BY window_center;

Export with COPY to feed into a receiver control script, a cron job, or any scheduling system. Refresh nightly with REFRESH MATERIALIZED VIEW tonight_schedule.

For operators building their own CML/Io-phase diagrams (the standard visualization in Jupiter radio astronomy):

-- CML vs Io phase over 24 hours, 5-minute resolution
-- Export for plotting a CML/Io-phase track
COPY (
SELECT t,
round(io_phase_angle(t)::numeric, 2) AS io_phase,
round(jupiter_cml('40.0N 105.3W 1655m'::observer, t)::numeric, 2) AS cml,
round(jupiter_burst_probability(
io_phase_angle(t),
jupiter_cml('40.0N 105.3W 1655m'::observer, t)
)::numeric, 3) AS prob
FROM generate_series(
'2025-06-15 00:00:00+00'::timestamptz,
'2025-06-16 00:00:00+00'::timestamptz,
interval '5 minutes'
) AS t
) TO '/tmp/cml_io_phase.csv' WITH CSV HEADER;

Feed the CSV into gnuplot, matplotlib, or any plotting tool to generate the CML/Io-phase diagram. Overlay the Carr source regions and you have the same visualization Radio Jupiter Pro provides — but with data you can customize, share, and version-control.

Visual CML/Io-phase chart. Radio Jupiter Pro displays the source regions graphically with the current position highlighted. You can see at a glance which source is active and how close the geometry is to a boundary. pg_orbit returns numbers — you build your own visualization.

Audio prediction. Radio Jupiter Pro includes models for the expected spectral characteristics of different source regions. pg_orbit provides geometry and probability only.

Integrated display. Radio Jupiter Pro shows Jupiter’s position, the current CML, Io phase, predicted source, and receiver recommendations all in one window. With pg_orbit, you compose the information yourself from separate function calls.

Zero setup. Install the application, enter your coordinates, and it works. pg_orbit requires PostgreSQL, the extension, and SQL knowledge.

Platform independence. Radio Jupiter Pro is Windows-only. pg_orbit runs on any platform that supports PostgreSQL — Linux, macOS, Windows, containers, cloud instances.

Batch analysis. Scanning 30 days, 90 days, or a full Jovian apparition at arbitrary resolution is a single generate_series query. No manual date advancement.

Data integration. Correlating predictions with observation logs, equipment status, weather data, or any other database table is a JOIN. Radio Jupiter Pro has no data export or import capability.

Automated scheduling. pg_orbit results feed directly into scripts, cron jobs, or any scheduling system through standard SQL exports. Radio Jupiter Pro requires a human to read the screen.

Reproducibility. A SQL query is a complete specification. Share it with another JOVE operator and they get the same results for their location by changing the observer coordinates.