A lot has happened and it seemed like a good time to start a new post. We will be staying in 53 day orbits until the project has a full understanding of the risks that may or may not be associated with reducing the orbit period to 14 days per our previous plan.

At the press conference last week I showed many beautifully processed images from amateurs, including many from this community. Thank you all very much! They were well-received, and in particular one reporter from space.com would like to follow up with a story on some of the individuals doing this great work. Please contact me if you would like to be interviewed, and I will get you connected.

At this moment we are trying to find the best time to get JunoCam powered back on to go back to collecting marble movie images. In any case we expect to be on for full image collection through Perijove 3 on December 11.

Thank you so much for using my images at the press conference. It was a great honor for me and a big pleasure to know that these images were shown there.

Until and unless we figure out how to fix or find a way to work around the engine sticky-valve issue, the new orbit perijoves will be on 2016 Dec 11 (PJ3), 2017 Feb 2 (PJ4), Mar 27 (PJ5), May 18 (PJ6), Jul 10 (PJ7), Sep 2 (PJ8), Oct 25 (PJ9). It's like that a solution/workaround will not be figured out until the time frame of PJ7.

This will affect not only the mission, but nearly all of the Earth-based support campaign.

I'm curious, should the engine problem be unresolved, if the mission will run the same number of perijoves over a longer span of time or a lesser number of perijoves over a mission of the planned duration, or something between the two.

Given a solar panel power supply, it would seem that absolute mission duration would not be the bottleneck, although a longer mission would surely have more costly ground support needs.

Here's a good article from Spaceflight Now that answers some of your questions.

Thanks for the link, Emily. That's pretty reassuring that Juno should still meet all of its goals.

I was going to make a new thread for PJ3, but I realized how short this "post-PJ1" thread was, so I just changed its title to cover both perijoves.

Voting for PJ3 targets started. It will last another 5 days. This perijove allows only for a small number of targets to be imaged beyond images of the poles and test imaging. Recently we had an outbreak near the northern tropical belt, one of the regions which might be of interest.
The locations of the features open to be voted on have been extrapolated. They are expected to be within reach for JunoCam during PJ-3.

Normally an 'interested lurker' here, but just noticed that PJ3 was yesterday but no updates on the forum or the Juno website? Anyone know if the data-gathering was successful?

(On a side note has public interest already dropped off on this mission, hope not!)

- Michael

New images have been scheduled to be published on Wednesday this week, I guess late in the night UTC.
As far as I can say from a distance, everyone involved is very busy with analysing the PJ1 data, and eagerly awaiting the PJ3 data, and/or performing accompanying ground-based observations.
There is also an AGU conference this week, in parallel.

Here are the plans for P3: LINK

Last update on Twitter was 22 hours ago. Nothing since, either good or bad.

Goldstone is downlinking data with 119.57 kb/sec:
Click to view attachment
I'd interpret this as Juno being healthy and having collected lots of data.

We've been steadily getting Junocam data and as of now have maybe 2/3rds of it. I think everyone will be pleased with the more favorable lighting on this pass, and it looks like the tweaks we made to the compression commanding have worked. I'm not sure when this will get pushed out to missionjuno. Normally we would wait for the whole dataset to show up and the DSN schedule has been spotty, for example, we were on the 34m net at Madrid last night and the data rate is low.

On the topic of public interest, obviously nothing new has happened since PJ1 apart from the problems with the propulsion system. All of the media reports I've seen have been supportive and enthusiastic about the mission. This was the first pass for public target voting, which had fairly good participation.

Thanks - good news anyway, I certainly don't mind waiting. Looking forward to seeing the new lighting.

PJ3 data posted -- https://www.missionjuno.swri.edu/junocam/processing

A very first idea of #03C00107:
Click to view attachment
(image: NASA / JPL / SwRI / MSSS / Gerald Eichstädt)

Other selected and enhanced Perijove-3 images as a first impression:
Click to view attachment

Preliminary PJ3 close-up RGBs, decompanded, color-corrected, square-root encoded.

Those are rendered without trajectory or (non-trivial) shape model. Spacecraft angular velocity just roughly estimated from PJ1 and Marble Movie.

Synopsis:
Click to view attachment

I'll try to refine this, and see whether I'll be able to create enhanced map products during the next days.

... this is an ad-hoc attempt of post-processing with consumer image processing software:
Click to view attachment
(NASA / JPL / SwRI / MSSS / Gerald Eichstädt)

Similar to a few posts above, but trying to enhance color.

The Junocam ring image in processed form is buried on missionjuno in the submissions section: https://www.missionjuno.swri.edu/junocam/processing?id=368 and the raw data is equally buried in https://www.missionjuno.swri.edu/junocam/processing?id=369 Note that the thumbnails are black so you have to click through to the full image.

Doubt if it's worth the anticipation, I was surprised we could see it at all.

It's still an impressive first, seeing them from this perspective! Could any of the four inner satellites be resolved if they were in the image at the time, or would they just be points?

I think they'd be resolved, Callisto would be about 4 pixels across if I did the math right. Turns out resolving the moons is not a big deal, we do that on every approach. Seeing useful detail on the moons is another thing.

Oops, I should've been more specific, I meant the four irregulars (Amalthea, etc). I know their orbits are a lot closer to Juno's perijove (~100-200 thousand km) but I'm not sure what that means considering their small size! I wouldn't expect anything like the Galileo images, but seeing their Jupiter-facing side (and constraining their orbits a bit) might be useful.

No, I should have read your post more carefully. I guess Amalthea might be barely resolved at minimum range, but I doubt that such an image would be of any real use.

Gerald, your work is very nice! Are you sure you didn't take it from a Van Gogh painting?

Thanks! I felt like diving through the Mandelbrot set.
Beauty without tinitus.

I'm working on resolving some of the glitches in my software, and am confident to be able to provide a lot more of hopefully even better products over the weekend and next week.

That's an enhanced crop of an intermediate map product derived from PJ3 image #092:
Click to view attachment
I'm experimenting with raw image #092 to find sw glitches. I had a bug in the calculations of the rotation matrix needed to transform between Jupiter and JunoCam frame for a given instant, which distorted the map away from a proper lon/lat frame. A small error in a fairly complex calculation. But it's sufficient, that you don't get what you intend.
I'm now presuming, that the residual non-flat brightness of my de-lamberted map products can partly be attributed to some mixing of planetocentric and planetographic code. The surface normal for de-Lamberting needs to be calculated planetographically while the map projection is planetocentric.
Of course one could work with the NAIF or ISIS3 libraries, but you learn more by going through all the technical challenges, and at some point you can't go beyond "the standard" without taking the risk to understand and do it yourself.

This may serve as a small status update.
I'm working on PJ3 map products:
Click to view attachment
In the meanwhile, I've found and resolved two glitches, but there are still several more issues to be resolved. In this version, longitudes have not yet been aligned.
I'm currently trying to determine Juno's rotation period from the images. My initial estimate of 30.242 seconds didn't fit well. Therefore I've determined the pointing for each images separately for the above animation, which led to a shift of longitudes as a side effect in this approach.
A better preliminary estimate of Juno's rotation period seems to be 30.330 seconds, on the basis of PJ3 images 103 and 104. I'll narrow this further down, before rendering the first set of maps in higher resolution, which will not yet be de-Lamberted. An other issue I've to resolve is a glitch in the rotation matrix for the de-Lamberting model, and a better approximation of the surface normal.

This gif shows an attempt to fit the images into a mask which simulates a Jupiter spheroid, assuming a constant rotation period of 30.33740 seconds for Juno, and neglecting light travel time:
Click to view attachment
The rotation period is inferred from PJ3 images 103 and 126. You'll see a black margin at the top or bottom of Jupiter of variable thickness with respect to the ugly turqoise background mask. The most distant images of this sequence are taken from a distance of a little more than 100,000 km. Light takes about 0.3 seconds for this distance. So we get a shift of very roughly 100 pixels in the raw images due to light travel time. This appears to be similar to the observed error. So this will be one of the things which I'll include into my model. If you're using NAIF/SPICE libraries and kernels, this effect should already be considered.

Edit: ...hmm, I'm a bit hesitant, whether General Relativity (equivalence principle) allows for this simplification. May be I'd better adjust the angles manually, and then look which physical model fits.

Which simplification?

AFAIK, GR effects have never been part of the NAIF toolkit, but stellar aberration is: https://naif.jpl.nasa.gov/pub/naif/toolkit_...ice_spkezr.html
Although I doubt it makes much difference in this case.

Mods: IMHO this technical discussion belongs in some other thread.

I was just looking for a simple solution to adjust for possible relativistic effects regarding spacecraft rotation. Since Juno's trajectory isn't an inertial system, but accelerated in a Newtonian understanding, we get into GR. I'd think, that this is implicite in SPICE by Ephemeris time (ET) - UT transformations.
I've been considering, that Juno's time-dilated rotation by GR might be equivalent to an offset by light travel time. But discussing this -- as M.Caplinger says -- would be an extra thread.
Since I can't be sure yet, to which degree relativistic effects play a role, and how complicated those considerations might become, I decided to adjust rotational offsets manually in a first step.

Edit: After these adjustments, the fitting looks better:
Click to view attachment
Maybe worth to create an animation (video) with black background and interpolated frames.

I don't think so. If this was the case then all time conversions would require knowledge of position. I think the full extent of SPICE's treatment of GR is in the mapping from ET=TDB to TDT, which applies only to the Earth and is not something I've ever used. See https://naif.jpl.nasa.gov/pub/naif/toolkit_...ound%20Material

I'd guess, without having worked it out, that in the total error budget of spacecraft pointing, GR effects are several orders of magnitude down in the list, at least for spacecraft and targets like the ones we deal with now. In the future, if mission planners are flying relativistic spacecraft to black holes, the SPICE toolkit will have to be enhanced.

Newtonian mechanics can handle acceleration - that's the "a" in F = ma! GR effects are only noticible in rare circumstances, when either the velocities are large (relative to c), the gravitational potential is large (black holes etc), or when the precision is extremely high (Mercury perihelion measurements, GPS, gravity probe B.). I can't imagine that GR will be anywhere close to detectible in junocam. And being in a rotating frame does not imply time dilation.

Well, in order to solve the question about whether relativistic effects might be relevant or not, I did a short SR calculation assuming velocities up to 1e-4 the speed of light, and got a relative effect of about 6.8e-9, which can't explain the offset, which I resolved only up to about 1e-7.
The effects I'm considering are often assumed to belong to SR, but they are better described by GR, like the twin paradox.

Eventually, the presumed fluctuations of the angular velocity seem to be of a different cause, either some spacecraft operation, which I've considered as less likely during flyby, interaction with Jupiter's environment, which looked also less likely at that height, unconsidered image processing effects, or some inaccuracies in the data, which I also assumed to be considerably smaller.

Taking this thread even farther from Jupiter, the twin paradox is special relativistic. It occurs on flat (Minkowsky) spacetime, which is what defines SR. It would also occur on curved spacetime, but curvature (ie gravity) is not needed.

By the equivalence principle "acceleration = gravity", for a non-inertial observer a Minkowski space looks curved, and we are in GR, at least in my understanding.
Investigating Jupiter's gravity field extremely accurately is part of the Juno mission. Otherwise I wouldn't have replied once more.
That said, essentially, GR doesn't solve or simplify the labor in my JunoCam processing in the way I had hoped for.

Some reading on this topic:

https://www.lpl.arizona.edu/~showman/public...i-etal-2010.pdf

No mention of GR. Here's a paper on gravitational lensing by Jupiter:
http://iopscience.iop.org/article/10.1086/378785/meta
or https://arxiv.org/abs/astro-ph/0302294

The radial deflection was 1190 microarcsec = 0.0058 microradians. Lost in the noise for imaging systems.

For those, who like to use the MSSS version of the PJ3 RGB images, but color-corrected, i.e. with much less color striping artifacts, and adjusted color weights.

====
Re Juno and GR:
There are even people, who think, that measuring the very subtle Lense-Thirring effect, aka frama dragging, might be feasible during the Juno mission:
https://arxiv.org/pdf/1302.6920v5.pdf
https://arxiv.org/pdf/0812.1485v3.pdf

But the effect I've been thinking about, is much more crude: It's the relative effect of velocity to clocks. And I'm keen enough to use Juno's rotation as a clock. Seen from Jupiter (barycenter), we get velocity changes of about +/- 1e-4 c. For a constant angular velocity, even small to tiny time-dilation sums up to a a small angle, which might be detectable by JunoCam. But as I've calcuated above, we are below 1 pixel per perijove. However displacements well below 1 pixel, in some cases down to less than 1e-2 pixels, are feasible for measurements. We are then in the same order of magnitude as relativistic effects. I've attributed these effects to GR, since we aren't in two inertial systems in a flat spacetime regarding Juno and Earth. But reasonable calculations should be possible with means of Special Relativity.
My very first crude presumption without calculations has been, that a velocity of 1e-4 c might result in relativistic effects near 1e-6, but as mentioned above, it's only near 0.5e-8. I was two orders of magnitude off, since the 1e-4 c need to be squared in the calculation for the relativistic effects.
The idea came during pondering about the root cause of an angular offset observed during PJ3 image processing.

Btw.: Regarding SPICE: Probes close to the Sun may experience considerably stronger relativistic effects.

Crescent Jupiter:
For the PJ3 Approach sequence, I'm currently running a calibration process. This required some software adjustment, since the background seems to be a little brighter than for Marble Movie. Previously this has been hard-coded. Now it's a program parameter. This calibration batch will run a few hours. So I found some time to enhance one of the intermediate images, image #2 of the PJ3 series:
Click to view attachment

All I want to tell you Gerald : you are doing an AMAZING work ! I don't understand clearly the process behind (because you know, mathematics and me are not in very good terms…) but I admire you for this, and thanks for being so generous about it

Regarding GR, in my numerical integration software used for solar system planet orbit calculations, I employ a GR correction. It can be thought of as an "anomalous" acceleration to be applied to the otherwise Newtonian formulation of determining the acceleration of a planet. I suppose this correction can be checked in the Jupiter setting to see if it appears to be significant.

Thanks a lot Damia! That's particularly precious, when those words come from one of the world's leading image processing experts.

@scalbers: Fully nailing this down for Juno's extremely elliptical orbit would be really great! Might be, you could even determine the accurate relativistic effects on clocks travelling with Juno. I guess, that only +/- a few hours around perijoves need to be considered, where we get high velocities, and a tiny gravitational red shift.

Gerald - here is the correction term for the orbital acceleration as it appears in my vintage (1970s) software. I'm unsure how easy it would be to retool this to run for Jupiter, though we could at least do some type of scale analysis on this, or augment another simulation program accordingly. The RDRD or r dot rdot term is sensitive to how elliptical the orbit is as one might expect.

! ADD PERTURBATIVE ACCELERATION DUE TO GENERAL RELATIVITY
RDRD=X(I)*XD(I)+Y(I)*YD(I)+Z(I)*ZD(I)
VSQ=XD(I)*XD(I)+YD(I)*YD(I)+ZD(I)*ZD(I)
A=FOURM*RLCM1-VSQ*CM2
B=FOURM*RDRD*RLCM3
XDD(I)=XDD(I)*(1.D0-A)+B*XD(I)
YDD(I)=YDD(I)*(1.D0-A)+B*YD(I)
ZDD(I)=ZDD(I)*(1.D0-A)+B*ZD(I)

The terms are defined as follows:

RDRD - r dot rdot - dot product of position and velocity
XYZ - position vector in AU
XD,YD,ZD - velocity vector
XDD,YDD,ZDD - acceleration vector
FOURM - 4 times the mass of the central object
RLCM1 - inverse distance between the two bodies
CM2 - 1 / c squared (c = speed of light)

I should try and look up the Cowell Astronomical Papers reference where I obtained this. The above just applies to calculating the GR perturbed positions. The clock changes are a different calculation.

This is an animated gif of preliminarily processed PJ3 approach images:
Click to view attachment
The last 10 or so frames have been too large to be properly aligned by centering.

Here the stills, and a respective version showing more context.

---

S.C.Albers:
I guess, 'I' is an index in a loop (iteration?). Not quite sure about the meaning of '1.D0', I guess simply 1.0 in some progamming language. Besides this, it looks fairly easy to implement. Thanks!
Transforming SPICE trajectories to this algorithm should be well-feasible, too, with position vectors relative to Jupiter.

Double-precision floating-point constant.
Once upon a time there was a language called FORTRAN and all serious scientific programming was done in it...
similar syntax is used in languages like IDL.

I see. Then the 'I' is likely used as an array index to overcome the lack of function scopes for (local) variables.
Not needed anymore in modern computer languages.

Here a couple of PJ3 processing and a test anaglyph