This is primarily a question for Alan et. all., but I thought it might spark some interesting about prioritizing science during a fast memory and time limited flyby. I'm also trying to get an idea of what to look forward to -- in nine years -- from Pluto. Don't want to be disappointed!

Alan has mentioned a couple of times that Pluto data collection is essentially memory limited. During the close encounter there just isn't time to dump data to Earth to make room for more. So that seems to say that the two constraints on collecting info are how much you can store and how long you have to gather it.

I've also noticed that some of the old NH materials describe 16 Gbit recorders while the latest information says 64 Gbit. That's quite a difference -- a factor of four. The only documentation I've seen about the expected data return, the archive and management plan pdf, implies about 11 Gbit of raw data to be returned. This makes complete sense with the older recorder specification with a nice healthy 50% margin for recorder degredation, engineering data, etc.

But has the expected data collection increased any now that the the recorder has quadrupled in size? Are you now limited by time during the encounter? Are you now limited by DSN time for download? Are you planning to, like Cassini with the Huygens descent, write the data repeatedly within each recorder for extra-super-redundancy? Are you expecting more radiation damage so that EOL capacity dramatically reduced?

So that's about a dozen questions, I guess.

Answers? Speculations? Related thoughts on how to schedule and prioritize observations?

The story was that the requirement was 16 GBits for the recorder, but because of the space-qualified flash memory chips available, it was actually simpler to go with 64 GBit. It's super-compliant, but compliant. I would think NH would be much more limited by power for taking science observations and data rate from 30 A.U.s then thye are by the size of the SSR. However, experience teaches that they will use more than 16 GBits now that they can. However, given the time required to get data back to Earth, the extra stuff will likely be lower priority.

Another thought: leave all the flyby data on the recorder, and then millions of years from now when someone finds it, they may be able to reconstruct some data from a planet in another solar system.

Does flash have data retention times of millions of years?

What use is that? Whatever you do with the recorder, it can all get sent back home given a few months of downlink time, and it needs to be nice and fresh ready for a KBO flyby hopefully a few years later


Doug

The data rate is a nonfactor...once it is on the SSR, it can simply spend more time transmitting the data back. It isn't like Cassini, where it has flyby after flyby. I am guessing here, but I think we will see the benefit of the larger than needed recorders in the fact that to image the new outer moons, there will be no data give-and-take from Pluto and Charon, other than the time spent pointed at them.

Which is a biggie! I imagine having two additional bodies to image will take a lot of time from imaging the surface of Pluto during the closest approach. Like having too much money, I suppose its not a problem you should complain about, but imagine the added complexity of planning the encounter taking four bodies into account as opposed to two!

But of course, c/a with pluto and c/a with charon will likely not be c/a with the new small moons.

Doug

With the new moons being small and rotating rather slowly, it would seem like an adequate strategy would be to point and snap off a multispectral series of each one at the moments just before and just after the planned Pluto-Charon observations. May as well extend those observations previous to the encounter to capture a full rotation of each, but given the weeks-long rotation periods, NH will be rather far when the rotation starts, and the observation will be more about light-curve data than having any resolving power.

None of that would take a lot of data, since the new moons will be single-frame objects. Possibly less than 10 MB, and with reasonable compression, maybe even less than that.