[X] My Assistant

[Wyl2006]

I am wondering about two special things:


1. Why was the Imager system of Cassini not set on a scan platform? I am really wondering that more than the half possibilites for RADAR-cartography are lost to do other experiments? This seems not an excellent technical solution.

2. Why was the Huygens camera build with such bad resolution? Also the "test images" done at the LPI parking area would give a lot of questions if people were not said that these things in the picture are trees.

Some experiments with a simple CCD-camera at 1/1000 of the illumination given on Earth shows clearly that better pictures could be done without problems, and there are better compression algorithms.

As the soviet space probe has shown during the 70s and 80s, it is possible to make panorama photos from a torrent surface during a flyby of the bus without serios problems.

I am really wondering on those funny self beloving of some ESA-"professionals" and the things told about these bunch of lousy photos they have gotten.

Some experiments with a simple CCD-camera at 1/1000 of the illumination given on Earth shows clearly that better pictures could be done without major problems.

I am working on that topic making cameras for supervision and examination for night and day.

Greetings: Wyl

[The Messenger]

What is really sad, is no one anticipated the long life of Huygens on the surface:

Hello Huygens, ya, this is Cassini, Aw got nothin but goose eggs on ma '"A" Channel reciever, would you flop what you'all got left on 'A' Channel over to 'B', and resend all you can until you fade?

[ugordan]

What is really sad, is no one anticipated the long life of Huygens on the surface:

First, Huygens was an atmospheric probe. Anything sent back from the surface would be merely bonus science.
Second, the impact speed was not trivial at all and it was uncertain whether the probe would ever survive it.
Third, it was probably seriously considered back then that Titan's surface might be covered with oceans/lakes of liquid methane. There was a distinct probability the probe would land into liquid. If this were to happen, the probe's on-surface life would most likely be reduced to only a few minutes as the criogenically cool methane freezed the probe to death.

From an engineering point of view, it was unrealistic to prepare for an extended surface mission, given also the fact that no great scientific benefit would result from greatly prolonged surface life.
If, on the other hand, they anticipated (and prepared for) the probe's survival and instead it crashed, some people would get a nice new reason to bash ESA on a failed "lander".

[The Messenger]

From an engineering point of view, it was unrealistic to prepare for an extended surface mission, given also the fact that no great scientific benefit would result from greatly prolonged surface life.
If, on the other hand, they anticipated (and prepared for) the probe's survival and instead it crashed, some people would get a nice new reason to bash ESA on a failed "lander".

I don't agree. If you follow the Cassini Event logs, They have recently added programming that allows retransmitting of critical data in the event of a lose during transmission. During T-13, an ultrastable clocking system on one channel switched off, and much of the close-pass data would have been lost if Cassini engineers had not planned for this contingency. This was not an expensive programming change in terms of computer resources and real estate, just thoughful acceptance of the fact that seemingly unnecessary redundancy is a virtue.

There is no doubt this decision was prompted by the transmission failure during T-7(?), and also influenced by the loss of data from Huygens. In the case of Huygens, no, they did not have big enough buffers to retransmit all of the data, but they did have a seven year flight, during which they had plenty of time to contemplate contigencies; and they did know after changing the deployment scheme there may be more ground time. Retransmitting critical data, even if it the original data was fully redundant, would have been a very cheap safety play. So what if Cassini wasn't even listening? And speaking of not listening, my clients and servers do an automatic cycle reset when they don't see any valid data within a specified time out period before giving up. Why was Cassini so dumb?

Finally, if the ESA would not have revealed the loss of channel A data, would the Cassini team have taken the time to plan for such a contigency during T-13? What lessons are there to learn buried in the secret report of the DART debunkle? Let there be light.

[ugordan]

If you follow the Cassini Event logs, They have recently added programming that allows retransmitting of critical data in the event of a lose during transmission.

Recently? Not a chance. They had this ability from the start. This was more of a mission requirement than a contingency capability. That's the sort of contingency used for example when there's heavy rain over the DSN station and the data doesn't all come down in one piece. It had nothing to do with either Huygens or T-7. Cassini's SSR has two pointers, a record pointer and playback pointer. The two can be moved around to accomodate various changes. That's an oversimplification, but you get the point. Read Emily's blog on the recent anomaly.

There is no doubt this decision was prompted by the transmission failure during T-7(?), and also influenced by the loss of data from Huygens.

As I said, this had nothing to do with it.

In the case of Huygens, no, they did not have big enough buffers to retransmit all of the data, but they did have a seven year flight, during which they had plenty of time to contemplate contigencies; and they did know after changing the deployment scheme there may be more ground time. Retransmitting critical data, even if it the original data was fully redundant, would have been a very cheap safety play.

Just how exactly do you propose transmitting critical data again if you don't have a big enough buffer, as you yourself admit above? The second channel WAS a contingency by itself. And it worked.

So what if Cassini wasn't even listening? And speaking of not listening, my clients and servers do an automatic cycle reset when they don't see any valid data within a specified time out period before giving up. Why was Cassini so dumb?

Do you really think giving the S/C too much autonomy at mission critical times like that is anywhere near wise? Cassini was probably in an effective safe mode during probe relay, and its only orders were to listen, record and play back. Giving it an option to automatically switch the circuits on or off might have done more harm than good.
Spacecraft designers aren't that naive -- sometimes, less is more.

Also, your client-server analogy reminds me of the sort of comparisons: my digital camera would blow away the Huygens DISR and stuff... Comparisons like that don't really do justice to anything.

Finally, if the ESA would not have revealed the loss of channel A data, would the Cassini team have taken the time to plan for such a contigency during T-13? What lessons are there to learn buried in the secret report of the DART debunkle? Let there be light.

You are trying to find connections in places where there simply aren't any. Period.

[The Messenger]

Recently? Not a chance. They had this ability from the start. This was more of a mission requirement than a contingency capability. That's the sort of contingency used for example when there's heavy rain over the DSN station and the data doesn't all come down in one piece. It had nothing to do with either Huygens or T-7. Cassini's SSR has two pointers, a record pointer and playback pointer. The two can be moved around to accomodate various changes. That's an oversimplification, but you get the point. Read Emily's blog on the recent anomaly.

They did not impliment this level of redundancy on the T-7 pass, and important scientific data was lost. Read the event log:

As was reported on Monday, April 24, the Program Scientist was to make a final decision on what data to protect from being overwritten in the event of a problem with the DSN after the Titan 13 (T13) flyby. He has asked Science Planning, the S20 sequence leads, and members of the Spacecraft
Operations Office if it might be possible to preserve at least one block of the unique F ring data in the post T13 time period if such an anomaly were to occur. It was decided that the easiest strategy to implement was to save all of the Visual and Infrared Mapping Spectrometer (VIMS) data on the day after the T13 flyby, and to zero out all of the other instruments if a second playback is required. Since the total VIMS data volume is relatively small, the VIMS data, along with the Synthetic Aperture RADAR (SAR)/UVIS block, could all be played back over the next downlink. This strategy will preserve the key science data for both Titan and VIMS rings.

In the event of a problem, a file will be uplinked that will 1) create a new data policing table so no science is recorded for remainder of the downlink on DOY 121, 2) enable this table immediately once the file reaches the spacecraft, and 3) modify Table 19 for the following observation period on DOY 121/21:14 - 122/19:43 SCET. Only VIMS packets will be recorded.

This type of contigency was not in place at the time of the T-7 pass, and a lot of important data was overwritten that could have been retransmitted before it was erased.

With Huygens, the situation was much more problematic - the buffers were small and so was the broadcasting window. I agree, there was little to gain. It would have been reasonable to broadcast the final spectral measurements made just before landing on both channels, rather than just the A channel. It would have been prudent to have embedded in the software on Cassini, a sanity check that recycled the receiver start up sequence if it was not receiving valid data within a reasonable window. Maybe there was such a sequence, and it omitted the TURN ON THE RECEIVER command too: Without a report, who knows?

You are trying to find connections in places where there simply aren't any. Period.

No, I am placing emphasis on the fact that we can learn best from mistakes and anomalies if we candidly share information about causality and corrective actions. Sitting on the report of the cause of an anomalous condition for more than a year doesn't allow lessons -learned to be implimented in current engineering. There will be no public report on Dart, The Gemini report took more than a year, and the promised Huygens report is still pending.

[ugordan]

They did not impliment this level of redundancy on the T-7 pass, and important scientific data was lost. Read the event log:

<cut>

This type of contigency was not in place at the time of the T-7 pass, and a lot of important data was overwritten that could have been retransmitted before it was erased.

The T-7 data loss was not caused by failure to re-transmit the flyby data back. There was no data to be played back as it was never actually recorded on the SSR. The anomaly arose due to a software/commanding mistake that basically acted like "write-protect", preventing anything to be written on one of the solid state recorders. All science data was normally gathered during the flyby, but about half was lost because the spacecraft didn't store it. There was no commonality between T-7 and T-13. Period.

Since you're attacking the mission folks about what should and what had been done, at least get your facts straight if you wish to be taken seriously.

[The Messenger]

...There was no commonality between T-7 and T-13. Period.

Since you're attacking the mission folks about what should and what had been done, at least get your facts straight if you wish to be taken seriously.

You just don't see it, do you? What did I just write? Software redundancy checks are the easiest and cheapest backstops to onry hardware - especially if it is a light-hour away. Maybe it was not not possible to check the write protect bit, maybe it was not possible to do a trial recording and playback prior to collecting two hours worth of nothing. These are the kind of software impovements I am advocating, and they require the programmers and the engineers to work in close harmony with each other. They also require a long pause on the "what if" button, and that is not easy to do.

Would a timely release of the Huygens channel 'A' problem have lead to a closer inspection of the code prior to T-7? Probably not. But if the recommendations included software sanity checks of hardware bit states, who knows?

I'm applauding the Cassini Mission planners for including similar steps in the code during the T13 flyby. They are learning, adapting and improving the performance of Cassini on-the-fly. It is truly remarkable that the underlying safety systems are robust enough to allow this kind of flexibility. The Cassini team took a good hard look at T-7 and improved upon the already sterling performance.

As far as getting the facts straight, let me make one thing clear: I never have all the facts straight

[ugordan]

You just don't see it, do you? What did I just write?

You were constantly trying to reach conclusions based on T-7 and T-13 anomalies, as if T-7 could have easily prevented T-13. This was simply not true.

Software redundancy checks are the easiest and cheapest backstops to onry hardware - especially if it is a light-hour away. Maybe it was not not possible to check the write protect bit, maybe it was not possible to do a trial recording and playback prior to collecting two hours worth of nothing. These are the kind of software impovements I am advocating, and they require the programmers and the engineers to work in close harmony with each other. They also require a long pause on the "what if" button, and that is not easy to do.

Do you realize that software checks are as likely to be erroneous as the main code? Consider a situation where the main code performs normally, but the "sanity-check code" takes over due to some obscure bug. In the end the result is the same.
Does adding Cassini the ability to ask "are you really, really sure you want this bit set to that?" amount to a more full-proof spacecraft?
You simply can't check and double check every bit of code or redundancy. For all practical purposes, if the write-protect bit was set, Cassini's "sanity-check" should have assumed it was DELIBERATELY set to protect some science stored there, just like the T-13 contingency actions protected most of the Titan science being overwritten by later observations.

I'm applauding the Cassini Mission planners for including similar steps in the code during the T13 flyby.

Again, I fail to see just what it is they actually included in the code apart from the ability they had from the start, which they very much needed to exercise recently.

Frankly, this discussion is going nowhere and there's no point in beating a dead horse any further. This topic is closed as far as I'm concerned.

[The Messenger]

Do you realize that software checks are as likely to be erroneous as the main code? Consider a situation where the main code performs normally, but the "sanity-check code" takes over due to some obscure bug. In the end the result is the same.
Does adding Cassini the ability to ask "are you really, really sure you want this bit set to that?" amount to a more full-proof spacecraft?

This is silly. If I set two alarm clocks, a single bit failure won't let me sleep in, and I can still over-ride both if I want to. Well-designed systems don't care how often or how many start buttons are hit, and the stop action or masking should be independent of the start button states. Elevators have used this type of logic for decades and it does make them safer and more reliable.

You won't find a modern safe-and-arm system that doesn't check status before and after arming; there is both redundancy and fail-safing in these mission-critical systems. No one would dream of arguing a one-bit fire button would be more reliable - especially in space, where there are a lot of cosmic rays throwing bricks at the bit registers.

Of coarse I don't have all the facts, but if the ESA had planned on using only one bit in the code to enable the USO on channel A with no verification, this was an oversight. This was not a time-critical event, and it would not have been difficult to create a twenty-line module of code that verified the transmitter was consuming the expected power and returned a status bit or two before moving on to the next step - especially during in-flight verification. Twenty lines of careful status checking is a little more difficult to misplace than a single bit. It is safer, more reliable, and less prone to introduce errors, human or otherwise.