Matijevic Hill detailed survey, Sol 3153 - 3290 Options

[Vultur]

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.

[Gerald]

Indeed, even though the Sun is relatively quiet in the band used for radio communication, a single outburst could change a command into something quite undesirable. And on top of it the operators would have a very hard time to know which command have been randomly changed.

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?

[PaulH51]

Don't they add CRC32 or CRC64 checksums to the code blocks to be sure that only correctly transmitted commands will be executed

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.

[djellison]

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?

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.

[Gerald]

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.