What exactly is the interaction that blocked Juno's data downlink near solar conjunction?

Question

According to Space.com's article Juno Phones Home: Jupiter Probe Reconnects with Earth After 8th Flyby, Juno's recent close flyby of Jupiter and data collection happened while Jupiter was too close to the Sun as seen from Earth for the data to be reliably received by the Deep Space Network.

Here is a GIF made from some SOHO LASCO C3 images; you can see Jupiter disappear behind the central occultation disk that protects each SOHO imager from the Sun. (Incidentally, that's Comet 96P on the right; see the NASA Goddard feature Return of the Comet: 96P Spotted by ESA, NASA Satellites.)

Solar conjunctions of Jupiter — when Earth's and Jupiter's orbits take the planets on opposite sides of the sun — mean that a spacecraft orbiting Jupiter can't transmit to Earth without the charged particles the sun emits corrupting the probe's signal. The last solar conjunction of Jupiter was in August 2015, before Juno had arrived at Jupiter, and the next will be in November 2018, according to in-the-sky.org.

Of course the article is wrong, and the previous conjunction would have been in 2016.

I've plotted the angles below; it looks like about 1.5 degrees is too close, but 4 degrees is OK. Those correspond to a closest approach of the line-of sight to the surface of the Sun of 3 vs 10 million kilometers.

Question: Is this a simple plasma density effect? When the line-of-sight passes too close to the Sun the cut-off frequency drops below that used by the spacectraft for downlink? Is the density of the solar wind at this distance quantitatively high enough to become opaque at this frequency? Or is the problem more complicated, and perhaps also involves too much dispersion? Or perhaps a geometrical problem; it's too hard to point so close to the Sun without equipment damage, or even a radio interference problem; there is too much spillover of radio noise from the Sun and the weak spacecraft signal can not be separated well enough to allow for a high-bandwidth downlink?

note: I'm looking for some level of explanation, and not just an answer that says "Because of interference from the Sun." Thanks!

---

Plot of calculated positions and separation using the python package Skyfield. I'm not sure of the exact time of the beginning of successful downlink, so I've just added seven days to the time of flyby (estimated from JPL's Horizons.)

Tiny dots are spaced at 1 day intervals, medium-sized red dot on the left is the moment of flyby, large-sized green dot near the right is roughly the time of successful downlink.

import numpy as np
import matplotlib.pyplot as plt

from skyfield.api import Loader  # http://rhodesmill.org/skyfield/

degs = 180./np.pi

load = Loader('~/Documents/SkyData')
data = load('de421.bsp')
ts   = load.timescale()
sun, earth, jupiter = data['sun'], data['earth'], data['jupiter barycenter']

ddays = np.arange(0, 10, 0.1)  # ten days by 0.1 day steps

times = ts.utc(2017, 10, 24+ddays, 17, 44) # with respect to 17:44 UTC, October 24th, 2017

observations = [earth.at(times).observe(thing) for thing in sun, jupiter]
separation   = degs*observations[1].separation_from(observations[0]).radians

if True:
    fig = plt.figure()

    ax1 = fig.add_subplot(2, 1, 1)

    for obs in observations:
        RAdegs, Decdegs = [degs*thing.radians for thing in obs.radec()[:2]]
        ax1.plot(RAdegs, Decdegs)
        ax1.plot(RAdegs[::10],  Decdegs[::10],  '.k'                 )
        ax1.plot(RAdegs[:1],    Decdegs[:1],    'or', markersize =  8)
        ax1.plot(RAdegs[70:71], Decdegs[70:71], 'og', markersize = 12)

    ax1.set_xlim(208, 220)
    ax1.set_ylim(-16, -10)
    ax1.set_aspect(1.0) # https://stackoverflow.com/a/18576329/3904031
    ax1.set_xlabel('RA (degs)')
    ax1.set_ylabel('Dec (degs)')
    ax1.set_title('Sun and Jupiter observed from Earth geocenter, start 2017-10-24, 17:44 UTC')
    ax1.text(212, -11, 'Sun')
    ax1.text(212, -14, 'Jupiter')

    ax2  = fig.add_subplot(2, 1, 2)

    ax2.plot(ddays, separation)
    ax2.plot(ddays[:1],    separation[:1],    'or', markersize =  8)
    ax2.plot(ddays[70:71], separation[70:71], 'og', markersize = 12)
    ax2.set_xlim(-0.5, None)
    ax2.set_ylim(0, None)
    ax2.set_xlabel('days since flyby')
    ax2.set_ylabel('Jupiter/Sun separation (degs)')

    plt.show()

Answer 1

This article claims that it's the charged particles emitted by the sun that actually block communication with Juno. https://www.space.com/38668-juno-8th-jupiter-science-flyby-success.html This article about Mars conjunction cites the same physics and points out more succinctly that it's the command uplink that operators are worried about corrupting. https://www.jpl.nasa.gov/news/news.php?feature=7485

From talking to the payload operations folks at Malin Space Science Systems where I work, I can tell you that many of the missions they support including Juno and the Mars rovers, will attempt to downlink data during times apart from the very middle of conjunction, and that will result in varying degrees of data corruption requiring packet retransmission once commanding is re-established. So I would argue that the real issue is that the uplink packet loss rate becomes too high and it's too much trouble to retransmit so much of the uplink commands once the RF noise floor goes too high for the spacecraft receiver.