Ah, ok, so it's about commands being received reliably, not that pointing the comm equipment at the Sun would damage it. That makes much more sense, thanks.

Don't they add CRC32 or CRC64 checksums to the code blocks to be shure that only correctly transmitted commands will be executed, with a fallback strategy in case the command sequence is corrupted?

I am sure check sums are utilized for commands as well as all of the returned data strings, but this is a classic example of the ultra cautious 'belt and suspenders approach'. Frustrating for this community of observers, but when all factors are taken into consideration it was probably the only sensible option.

If you look at the Descanso website I linked to above, you will find all the details you could want regarding DSN protocols.

However- even error checking/correction does not solve the problem. You radiate a command load - the spacecraft identifies it as 'bad'. That command load could have been very important - it could have been something to prevent the spacecraft doing something to harm itself in someway . If the spacecraft doesn't accept it - you are quite probably in a worse situation. You radiate commands because you want the spacecraft to do something. Imagine the MSL side-B swop, or MER-B flash anomaly - but with the added complexity of unreliable communications.

There is a less obvious benefit of this strategy - conjunction offers up an opportunity for spacecraft operations teams to have a little down time. It's very very hard for a lot of flight-ops people to find time for vacations etc. Projects also can not afford enough personel to staff up enough to have redundancy for every job required on the mission. Conjunction offers a chance for people to catch up on other responsibilities, or take a well earned break.

It makes no sense to try to transmit commands during solar conjunction. I don't question the down time at all.

And thank you very much for the link to the paper! It seems to accept a Bit Error Rate (BER) of below 1e-6 for the transmission (section 5.5), meaning up to 8 errors in a Mega byte.
So in most cases important commands will be successful, if accepted by the decoder.
But during normal operations it might be better just to refuse (rare) corrupted command sequences, e.g. containing a sign error in an arm moving command, to prevent damage. I'm with PaulH51 at this point, they'll likely do it.
Might be important command sequences are sent twice (executed once, of course), in the case one copy is corrupted.
But that's not clear to me from the MRO paper.

The PS Update/Summary of some important LPSC papers on this leg of the Traverse:

http://www.planetary.org/explore/space-top...ter-so-far.html

--Bill

With respect to the newberries, Ray Arvidson and Ken Herkenhoff keep all options open and seem to weight lapilli and precipitated concretions equal favorites. But based on Brad Jolliff’s analysis Steve Squyres indicates that they are probably diagenetic concretions although possibly predating the Endeavour impact. I guess we will never know for sure.

I recall Ray talking about principal component analysis at a recent AGU conference. Unsure if it can/is being applied in this case.