# Parker Solar Probe orbital velocity

Will Parker Solar Probe's orbital velocity of almost 200 km/s pose any exceptional challenges to the telemetry? Will the signal become distorted?

Yes, it causes distortion.
But No, this will not pose any exceptional problems.

All space probes are in motion relative to the sender/receiver on Earth.
This motion causes distortion of the signal's frequency and time synchronization.
The causes are many, listed roughly from strongest to least:

• Time delay due to distance to the probe
• Doppler frequency shift due to relative radial motion of the Probe to Earth
• Doppler frequency shift due to motion of the sender/receiver on Earth. The planet is rotating after all, which jerks the receiver to and fro with a relative speed of several hundred kilometers per hour every day
• Actual time dilation due to relative speed of the probe to Earth
• Actual time acceleration/dilation relative to Earth due to changing ambient gravity fields
• Frequency shift of signal due to having to climb up/down the Earth and Sun's gravity well

Obviously the last few items on that list are of vanishingly small effect, yet the engineers do need to account for them.

But because these distortions occur with all space probes, it is a well understood field of study.
Relative to other probes, the Parker probe's communications regime will experience greater scale of difficulties, but similar nature of difficulties to previous probes.

The Parker Solar Probe's rate of motion may be higher than any we've needed to communicate with before, but the difference is merely a matter of scale, not of the nature of the problem. Also the probe will be closer to the Sun than anything we've needed to communicate with before so interference from the Sun will also be greater than any we've needed to deal with before. But this too is only a matter of scale, not a change in the nature of the problem.

• It's interesting to see General Relativity effects in spacecraft. For Pioneer 10 at Jupiter, the frequency shift due to climbing out of Jupiter's gravity well was ~1/2 Hz (out of 8 GHz), easily measurable by the exquisitely accurate DSN ground stations. I was the technical lead on a 1990's proposal to NASA to fly a mission we called the "General Relativity and Coronal Environment" mission, "GRACE", before the lunar gravity mapping mission took that acronym. It would have done radio occultation experiments through the sun's corona to measure an expected 51 km of extra signal path due to GR! Aug 24, 2021 at 22:28

As @PcMans' answer points out, the effects will be predictable and have been accommodated on previous missions and will simply be larger this time.

While the frequency shift can be compensated by tuning the local oscillator to match the incoming carrier frequency, it's also necessary to adjust anything that splits off other components of the signal based on frequency modulation. Just for example, if you have a window near 0 kHz to pick off the carrier and one at 10 kHz to 100 kHz to pick off something else, those may end up at 10.02 and 100.2 kHz.

As @ ChristopherJamesHuff's comment points out, in addition to a change in frequency, there will be a change in "time synchronization" as well. The digital 1's and 0's of the data stream will clock in at a faster or slower rate than nominal.

Their comment also points out that that wasn't properly accounted for in the Cassini-Huygens mission and led to a serious problem in the mission because the firmware in a spacecraft's receiver could not be updated later. From How Huygens avoided disaster

Early in the design process, the engineers also understood one other consequence of the Doppler effect. But somehow, as the design was developed, this feature somehow dropped from sight. All design reviews of the Probe Data Relay Subsystem (PDRS), including those conducted with NASA participation, also failed to notice this oversight.

Presumably NASA's Deep Space Network will account for all of these effects live, and also record the near-raw signal stream for future processing in case their live demodulators can't make sense of the signal for any reason.

To explore that further I've just asked

### Communication at high Doppler shifts

Parker Solar Probe's highest velocities happen closest to the Sun, and low Sun-Earth-Probe angles there probably won't be any scheduled transmissions of data.

However Parker will spend a lot of time at velocities relative to earth almost as high! So I don't think they will wait until low Doppler shift to communicate.

### Communication through the solar wind

As the probe passes close to the Sun, a transmitted signal will pass though a region of high and variable charged particle density. This can cause simultaneous swings in signal strength and random shifts in delay, making it much more challenging to try to clean up and decode the signal.

Since Parker has a computer and memory, there's no need to even try to send valuable data during periods near the Sun when interference is worst, they can be scheduled later. Parker will be busy collecting data and maintaining a carefully selected attitude in order to hide behind its protective solar shield, and to allow only certain things to peek out from behind it; the tips of its solar panels and perhaps some other probes.

### Parker's trajectory

Below is a plot of the Sun-Earth-Probe angle (apparent separation between Parker and the Sun as seen from Earth) versus expected relative velocity.

The colors change at thresholds of 5 and 3 from the Sun, which are some numbers I picked out from sections 4.5.7 Solar Conjunction and 5.7.6 Solar Conjunction from the DESCANSO series' Volume 13; Deep Space Communications

I took the data from JPL's Horizons set up as follows:

Below I've ploted rdot versus the Sun-Earth-Spacecraft angle from launch day to 2025-Aug-30 at 1 hour intervals:

Here's the plotting script

import numpy as np
import matplotlib.pyplot as plt

fname = 'Parker Doppler 1h horizons_results.txt'
with open (fname, 'r') as infile:
a = [i for i, line in enumerate(lines) if 'SOE' in line][0]
b = [i for i, line in enumerate(lines) if 'EOE' in line][0]

linez = lines[a+1:b]
cols = (1,) + tuple(range(4, 11)) + (12, )

liszt, exceptions = [], []
for j, line in enumerate(linez):
try:
liszt.append([float(line.split(',')[i]) for i in cols])
except:
exceptions.append([line.split(',')[i] for i in cols])

data = np.array(liszt).T
JD, r, rdot, delta, ddot,Vsun, Vobs, SOT, STO = data

vbins = np.arange(101)
h, _ = np.histogram(np.abs(rdot), bins=vbins)
cs = np.cumsum(h)
cs = cs / cs.max()

if True:
fig, (ax1, ax2) = plt.subplots(2, 1)
z = np.zeros_like(SOT)
z[SOT <= 5.] += 1
z[SOT <= 3.] += 1
ax1.scatter(rdot, SOT, c=z, cmap='jet', marker='.', s=1)
ax1.set_xlim(-100, 100)
ax1.set_ylim(None, 60)
ax1.set_ylabel('Sun-Earth-Parker angle (deg)')
ax2.hist(rdot, bins=range(-100, 101, 1))
ax2.set_ylabel('hours spent per km/sec')
ax2.set_xlabel('relative speed (km/s)')
if False:
ax3.plot(vbins[:-1], cs)
ax3.set_xlabel('cumulative probability')
plt.show()