NH at Jupiter, Planning the Jupiter encounter Options

[Stephen]

And, the final nail in the Europa-orbit coffin was that Galileo wasn't completely sterilized (although you'd think that the Jovian radiation belts would have finished *that* job*), and there was a perceived contamination risk if it were to crash onto Europa. The easiest and most certain way to make sure that never happened was to ensure that Galileo was destroyed well away from Europa -- hence it was flown to its destruction into Jupiter itself.

Some years ago on one of the Usenet newsgroups one of the more informed members mentioned that some had contemplated a more spectacular end-of-mission for Galileo if only the antenna had not become stuck: a swan dive into Io a la Ranger.

"Waaaay back, in the early days of the mission, before the antenna failure,
a Ranger-style snapping-pictures-all-the-way-down kamikaze dive into Io
was seriously proposed as a possible way of terminating the mission, when
fuel ran low. Io was originally going to get only the one flyby, right at
arrival, and so a closer look would have been quite valuable. "

---4:14 am, Sun, Feb 4 2001, Henry Spencer replying to Patrick Flannery
in "Galileo (spacecraft)" thread on sci.space.history newsgroup

(EDIT: just located an earlier version of the same info by the same author: July 5 1997 in the "Shut Down Probe" thread on the sci.space.history group.)
======
Stephen

[hendric]

OK, now that's a little strange. I defintely posted that last message as two seperate messages to get under the 1MB attachment limit. But the BB keeps joining them back into one! Is this a feature of the upgrade?

[djellison]

OK, now that's a little strange. I defintely posted that last message as two seperate messages to get under the 1MB attachment limit. But the BB keeps joining them back into one! Is this a feature of the upgrade?

I'm still finding features but yes, I believe that's one of them. It tried to tidy up and not have one person making several consecutive replies.

Doug

[hendric]

There are actually two double shadow transits that occur before the flyby! Here is the animation of the first one. The shadows are both on Jupiter between 54117.03611 and 54117.10833. I couldn't resist adding additional time before and after the transits to show Ganymede and Io zipping around Father Jupiter.

Animation starts at 54116.7 and ends at 54117.13750000. Timestep is 15 minutes.

My KODAK_MMT is the center of when both shadows are visible, and targeting Io so that Jupiter and Ganymede are both visible.

The second shadow transit begins at 54123.875 and ends 54124.275. There is a very short time from 54124.1875 to 54124.206944 that both shadows are visible at the same time (basically, 28 minutes). It's also likely that due to the geometry, NH would not be able to see one of the shadows. I don't have time to do a 50 step animation, so my KODAK_MMT is the midpoint of when both shadows are visible, 54124.19722.


John, it's been fun helping out. But now I have to get back to work!

[hendric]

Will you be able to let us know which movies and KODAK_MMTs the team selects?

Also, I was hoping you could give us some technical details on your technique to recover the moon image data? I've got a solution:

The readout time is too long on the CCD, causing potential saturation at the lowest exposure times.

1. I assume you can take 0-s frames for measuring bias on the CCD?

2. What about moving the target up/down on the CCD to vary the amount of time for the average exposure? For example, if the CCD took 100 ms to readout, a 0-s exposure with an object at the middle of the frame would give an average exposure of 50ms. And as you move the object closer to the top, the exposure length would get shorter.

3. There would a small increase in brightness as you went down the rows, but so long as you're not totally saturated at the bottom you should be able to subtract out the increase since CCDs are linear.

This would even work to get photos of Jupiter, you would just have to take slices of it and mosaic the parts that don't get overexposed. Hopefully the inter-frame time isn't too long.

Of course, images with multiple bright objects far apart wouldn't be possible, unless the FoV could be rotated to get the objects near the top.

[ugordan]

I think the problem John is trying to describe is image smear during readout phase, not because the exposures are too large.
They can select a short enough exposure which won't bleach out the moons, but that exposure is short compared to the readout phase. LORRI has no shutter so light falls on the CCD continually. As a result, while the image is being readout light from the moon is still coming in and the end result of this (CCDs readout one line at a time, shifting the entire image in the process until the last image line is shifted into the A/D converter) is what I imagine will be a good image of the target with sort of a vertical motion-blur effect overlaid on it.

That is the gist of the problem with imaging the Galileans -- removing the unwanted "motion-blur" effect. Obviously, the images will need to be carefully processed to remove this linear smear. What John Spencer seems to be saying is that they can actually subtract the blurred part, but only for a small, well-defined target such as a moon or Jupiter when it's still far away.

I can't wait to see the results, both from the imaging perspective and image processing perspective they should be interesting indeed.

[john_s]

They can select a short enough exposure which won't bleach out the moons, but that exposure is short compared to the readout phase. LORRI has no shutter so light falls on the CCD continually. As a result, while the image is being readout light from the moon is still coming in and the end result of this (CCDs readout one line at a time, shifting the entire image in the process until the last image line is shifted into the A/D converter) is what I imagine will be a good image of the target with sort of a vertical motion-blur effect overlaid on it.

That is the gist of the problem with imaging the Galileans -- removing the unwanted "motion-blur" effect. Obviously, the images will need to be carefully processed to remove this linear smear. What John Spencer seems to be saying is that they can actually subtract the blurred part, but only for a small, well-defined target such as a moon or Jupiter when it's still far away.

That's exactly correct. For small targets (or, we think, for any image where we can arrange for a number of complete rows of dark sky in the field) we can probably get unsaturated images even at low phase angles, so we are interested in "Kodak moments" at low phase angles as well as high phase angles. And yes, we'll be sure to let you know which "Kodak" images make it into the final plan, though we won't know for a while, probably for several months. Integrating the Jupiter observations is pretty complicated (our biggest issue right now is finding the best times for the necessary Earth-pointed tracking periods, when we can't take data), and any "Kodak" observations will be the last things we add to the timeline, after we've optimized all our science observations.

John.

[hendric]

Ah yes, I forgot that CCDs transfer the pixels down and then over. In that case you would get a vertical smear of the image. I assume what you're doing is something like this:

1. Simplified image is like this:

CODE

0: 0
1: 0
2: 8000
3: 8000
4: 8000
5: 0
6: 0

2. Pixels are read out from the bottom of the display, with each row dropping down one during the readout. Each pixel read out step would be something like this, ideally:

CODE

CCD Pixel     Step 1          Step 2         Step 3          Step 4          Step 5          Step 6          Step 7
   0          -na-            -na-           -na-            -na-            -na-            -na-            -na-
   1          0               -na-           -na-            -na-            -na-            -na-            -na-
   2          0               0              -na-            -na-            -na-            -na-            -na-
   3          8000            0              0               -na-            -na-            -na-            -na-
   4          8000            8000           0               0               -na-            -na-            -na-
   5          8000            8000           8000            0               0               -na-            -na-
   6          0               8000           8000            8000            0               0               -na-

Output row    Read 0          Read 0         Read 8000       Read 8000       Read 8000       Read 0          Read 0

3. Since the readout time is comparable to the exposure time, and there is not a shutter, each time a value is in an "exposed" pixel, like 2-4 above, it would get a certain amount of light, depending on how long the value is kept in that pixel. For example, let's say 10% of the exposed value, so 800 in this case since all light pixels are 8000:

CODE

CCD Pixel     Step 1          Step 2         Step 3          Step 4          Step 5          Step 6          Step 7
   0          -na-            -na-           -na-            -na-            -na-            -na-            -na-
   1          0               -na-           -na-            -na-            -na-            -na-            -na-
   2          800             800            -na-            -na-            -na-            -na-            -na-
   3          8800            1600           1600            -na-            -na-            -na-            -na-
   4          8800            9600           2400            2400            -na-            -na-            -na-
   5          8000            8800           9600            2400            2400            -na-            -na-
   6          0               8000           8800            9600            2400            2400            -na-


Output row    Read 0          Read 0         Read 8000       Read 8800       Read 9600       Read 2400       Read 2400

4. Since you said above that you would need a few complete rows of dark in the image, I guess you are taking the value placed in those last image rows (in this case the 2400 read out in step 6&7) and using that to adjust the previous pixels? How do you subtract out the value, since it’s not going to be linear across real-world light pixels?

5. It should be possible to also do it based on the opposite direction, since you know how long you timed the exposure and what the readout time per line is, and CCDs are pretty much linear. IE, if you have a readout time of 100ms, and 1024 rows, then you would get an additional exposure of 100/1024 or 97us per light pixel on the way off the CCD. So if you took an image 10ms long, you know the first light pixel read out from each column has no extra light, with each following pixel having .097/10=.0097 or about ~1% additional light from each corrected light pixel ahead of it. With this method, you could take full-frame light images, even if the top of the frame is overexposed the lower portions should be recoverable.

PS
John, I now understand what your problem was wrt that table not keeping the correct spacing. Even if you mark a section as

CODE

This is a fixed width font.  blah
0123456789012345

the editor doesn't switch to a fixed width font. What I did is edit my original table in Outlook with the font set to Courier New, and then copied&pasted it back here with the code tags.

PPS
Interestingly enough, I did some googling on this, and found out that the IRIS freeware camera software will automatically take care of this issue for you!
http://www.astrosurf.com/audine/English/result/obtu.htm
http://www.astrosurf.com/audine/English/first.htm#smearing
http://www.astrosurf.com/buil/iris/tutoria....htm#deconvflat

Well whaddaya know!

[john_s]

^^^Your analysis is almost correct- the additional wrinkle (which I didn't realize myself till recently) is that there is an additional period of smeared exposure *before* the static image is exposed, which looks exactly the same as the readout smear but is in the opposite direction. The result is that all rows in the image, whether "above" or "below" the main target, have exactly the same amount of readout smear in them. This makes it easy to subtract the smear if you have any dark sky rows- you can measure the smear in the dark sky rows and subtract it from all the other rows. We don't yet know how well this will work in the real world (though we are optimistic), and we'll always have to content with the photon noise from the subtracted smear, which can be significant.

[stevesliva]

I thought it might be hard to get excited about jovian cloud dynamics, but this definitely helps:
http://science.nasa.gov/headlines/y2006/02mar_redjr.htm

Perhaps Red Junior will still be there next year!

[Jyril]

The spots from it formed existed for about 70 years, so I don't think it'll disappear really soon.

[Guest_AlexBlackwell_*]

Pluto Mission News
March 9, 2006
http://pluto.jhuapl.edu

--------------------------------------------------------------------------------

New Horizons Adjusts Course Toward Jupiter

With a 76-second burst from its thrusters today, New Horizons cleaned up the last of the small trajectory “dispersions” from launch and set its course toward next February’s gravity-assist flyby of Jupiter.

Changing the spacecraft’s velocity by about 1.16 meters per second, the maneuver was the smallest of the three New Horizons has carried out since launch on Jan. 19, and the first conducted with the spacecraft in three-axis pointing mode. It also aimed New Horizons toward the Pluto “keyhole” at Jupiter – the precise point where the giant planet’s gravity helps swing the spacecraft toward the close flyby of the Pluto system on July 14, 2015.

When the maneuver started at noon EST, New Horizons was about 51.7 million kilometers (32.1 million miles) from Earth, moving along its trajectory at 37.5 kilometers (23.3 miles) per second. Mission operators at the Johns Hopkins University Applied Physics Laboratory in Laurel, Md., monitored spacecraft status through NASA’s Deep Space Network antenna station near Canberra, Australia.

[Guest_AlexBlackwell_*]

The PI's Perspective
Zero G and I Feel Fine
March 20, 2006
http://pluto.jhuapl.edu/overview/piPerspec...ive_current.php

[hendric]

John,
How much of a change to the Jupiter encounter with the TCM make? Will the simulator be adjusted with the new trajectory?

[john_s]

John,
How much of a change to the Jupiter encounter with the TCM make? Will the simulator be adjusted with the new trajectory?

At this stage in the game, the close approach time is being tweaked by a few minutes at most, and the distances are not changing significantly. Mark Showalter may update the trajectory in his Jupiter Viewer sometime, but you can rely on the simulator for most practical purposes.

John.