Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Space Science

The Forgotten Huygens Experiment 556

jdray writes "An experiment onboard the Huygens probe didn't run as planned because someone forgot to turn it on. The team lead for the experiment has put eighteen years of his life into the project, just to watch it not happen after a seven year ride to its destination on Titan."
This discussion has been archived. No new comments can be posted.

The Forgotten Huygens Experiment

Comments Filter:
  • by sjrstory ( 839289 ) * on Friday January 21, 2005 @06:01AM (#11430083) Homepage
    1. Doh
    Doh (d)

    Interj.

    a) A Gen-X colloquialism conveying an overall feeling of frustration.

    b) Used to express a feeling one has after realizing they have been tricked, misled, scammed, swindled, etc..

    c) Used to boast or chide the victim of such tomfoolery

    d) Coined by the animated sitcom character Homer Simpson in the mid to late eighties, "Doh" is similar to other one word, one syllable explicatives in that it is a quick and succinct summary of one's aggravation, but differs in that it was an accepted substitute to similarly censored words.
  • Sad :-( (Score:2, Insightful)

    Damn that's sad. Don't they have checklists for these things??
    • When you have a billion things to do, you split it into smaller lists and pass those lists to others.

      Then those others split the lists to even smaller lists and pass them to others.

      That increases the number of ways things could go wrong. Even if you have list items on some lists to check that other people are doing stuff on their lists, stuff happens...
    • Re:Sad :-( (Score:3, Insightful)

      by Yazeran ( 313637 )
      I'm sure they did, but as another has already said, it's not a single man job. Besides, not very command to a spacecraft can be simulated and tested in advance. Some commands have to be sent at the exact right moment, not before, in order to make something as comples as the Heugens project work.

      It's a pity that the comand to activate channel A on the Cassini spacecraft was not sent as data was lost, but one can only hope that future missions do not make the same mistake.

      Incidently this event demonstrate w
      • Re:Sad :-( (Score:3, Informative)

        Well actually, I used to do software testing. You simply simulate the special conditions when things are supposed to happen. That's generally why satellites cost so damn much. Yes, there are some exotic materials that go into them, but the chief expense is testing.
    • Re:Sad :-( (Score:4, Funny)

      by supergiovane ( 606385 ) <arturo.digioiaNO@SPAMing.unitn.it> on Friday January 21, 2005 @07:58AM (#11430565)
      Damn that's sad. Don't they have checklists for these things??

      Sure they have!

      1. Spend 18 years planning a space mission.
      2. ???
      3. Profit!

      They just realized what was at point 2.

  • Redundancy... (Score:4, Insightful)

    by Burb ( 620144 ) on Friday January 21, 2005 @06:04AM (#11430094)
    I understand that half the camera pictures were lost because they were transmitted on channel A. Interestingly enough, an article in New Scientist quoted one of the mission planners as being scathing about the scientists' choice to use the 2 channels for increased bandwidth...

    This post is from memory. Please feel free to correct errors and ridicule me for factual inconsistencies.

    • Re:Redundancy... (Score:4, Informative)

      by Anonymous Coward on Friday January 21, 2005 @06:14AM (#11430137)
      David Southwood (the ESA head of science) was the one who said so - he said "That's scientists trying to screw the system. We don't have redundant systems to get more data down, we have redundant systems for redundancy." http://www.newscientist.com/channel/space/mg185248 33.700 [newscientist.com]
    • Re:Redundancy... (Score:2, Insightful)

      by Anonymous Coward
      In the case of pictures, the scientists' choice was correct. If both channels work, you get twice the number of pictures, if only one channel works you get the same as if you transmitted the same pictures on both channels because one interleaved set of pictures is as good as the other. (I assume that taking more pictures is relatively cheap.)

      Non-substitutable experiments on the other hand...
  • by WegianWarrior ( 649800 ) on Friday January 21, 2005 @06:06AM (#11430100) Journal

    I forgot to turn on my cellphone this morning, and missed a call from someone dear to me. Still, reading this makes me realise that somewhere out there, someone is feeling even worse over forgetting to turn something on.

  • Shit happens. (Score:4, Insightful)

    by KiloByte ( 825081 ) on Friday January 21, 2005 @06:07AM (#11430104)
    ... especially in this field of work. If you have a project this big, the chance that nothing will go wrong are simply infinitessimal. Do you remember the last time when you wrote a program of 100 lines without doing a single error?

    We should really praise the gods that the rest of Huygens mission was a grand success.
    • Even so, he said the overall space mission was a huge success, and the Europeans in particular were thrilled with the success of their Huygens probe.
      Yeah it's a success. Although you cannot guarantee that nothing will go wrong, making precautions to prevent everything from going wrong will add to the overall cost. The had two channels to transmit data, it's not easy to prevent a human error like this. They simply forgot to turn it on.
    • The point is, the radio channel that was never turned on was human error that caused the loss of half of all of the data from the probe. People's hard work functioned perfectly. Pictures were taken, data sampled, lander functioned correctly, no metric numbers were mistaken for imperial units, and they still lost half the data because someone screwed up.

      Thats not a grand success. Compared to crashing a lander into Mars, losing everything? Yeah, its probably a grand success. But thats a pretty low standard.
    • Re:Shit happens. (Score:5, Insightful)

      by grozzie2 ( 698656 ) on Friday January 21, 2005 @06:56AM (#11430294)
      Do you remember the last time when you wrote a program of 100 lines without doing a single error?

      I may not have got it all right on the first go around, but you can rest assured, i got it right after the testing and before it was deployed...

      In my primary field of work, 'shit happens' is just not an acceptable excuse, I'm a pilot. We use checklists precisely for that reason, to make sure that shit doesn't happen. Every flight has a few phases where even one minor screw up can have serious consequences, so we have checks and balances built into the system to make sure that small screw up does NOT happen.

      I know the software folks here on /. always want to make excuses about 'its hard' and 'its to complicated', but, it's actually not hard, and not to complicated. complex systems are designed and built every day in the aerospace field, systems that many lives depend on. We take it for granted that they are properly designed with failsafe modes, they can deal with problems on the fly, and they do not puke up and die when things become abnormal. Same goes for our crews, they train extensively to make sure they fully understand all operational modes, and they can deal with them. Once that's all done, we write books full of checklists, to make sure the details do not get missed at a critical time.

      'I forgot' or 'shit happens' is just not an excuse. In reality, it's an admission of unprofessional conduct. Billions of euros spent, many many man years of effort, and you want to take 'forgot' or 'shit happens' as an acceptable excuse? there is no acceptable excuse, those are just admissions of shoddy management and operations. Those are terms that are not even in the vocabulary of true professionals.

      Every time I read here on /. about how 'professional' programmers seem to think that it's to hard to actually take the time and effort to write failsafe code, and test it as such, I ask myself how many people would die if thier attitudes were used developing the flight management systems in our aircraft.

      Thanks to government regulations, i can only fly 9 days a month, that leaves me with a lot of time to operate my other business. We do software development, embedded systems for mission critical applications. We do deploy equipment into life critical situations, so, for our work, 'shit happens' and 'i forgot' just dont exist in the vocabulary. We use checklists to ensure that all testing covers all forseeable abnormal conditions, up to and including partial failure of various hardware. for your typical 'desktop' developer, equivalent testing would be along the lines of making sure programs handle gracefully things like having the hard drive removed from it's computer while the program is still running. They may not function at full capacity anymore, but it's not reason enough to have the thing just puke up and crash, it needs to fall into a failsafe mode that's prepared to deal with the detail of 'no local storage available anymore'. the code to handle this scenario will likely not 'get it right' on the first try, but, it'll surely be right before the product goes into release.

      Looking at the money spent, and the multitude of man years spent on developing the lander for this mission, to hear that a significant experiment was lost becase somebody forgot to turn it on, is just beyond comprehension. this goes way beyond unprofessional, and well past the line we would draw for 'incompetent'.

      • Re:Shit happens. (Score:2, Insightful)

        by Viol8 ( 599362 )
        " about 'its hard' and 'its to complicated', but, it's actually not hard, and not to complicated. complex systems are designed and built every day in the aerospace field, systems that many lives depend on. We take it for granted that they are properly designed with failsafe modes, they can deal with problems on the fly, and they do not puke up and die when things become abnormal."

        Yeah , theres *never* been any inflight problems in aircraft due to the computers or other systems has there. Though a couple of
        • Re:Shit happens. (Score:3, Insightful)

          by clausiam ( 609879 )
          >>"We use checklists to ensure that all testing covers all forseeable abnormal conditions"
          >You cannot forsee all abnormal conditions

          I think that's why he said all forseeable (sic) abnormal conditions. That subset must by definition be foreseeable :-)

      • In my primary field of work, 'shit happens' is just not an acceptable excuse, I'm a pilot. We use checklists precisely for that reason, to make sure that shit doesn't happen.

        Oh, so if you don't mind, why exactly do airplanes crash and kill hundreds of people?
        • Re:Shit happens. (Score:3, Informative)

          by Kombat ( 93720 )
          Oh, so if you don't mind, why exactly do airplanes crash and kill hundreds of people?

          I'm going from memory here, but I think it's something like 80% pilot/crew error, 15% weather (which could still be considered pilot error), and 5% mechanical failure. So if those pilots/crew had been following the proper procedure and protocol, then the shit *wouldn't* happen (except in those rare cases where mechanical error is to blame, and even then, most of those cases can be traced back to a mechanic cutting corner
      • I wonder if this mistake is really due to lack of routines. You say "only fly 9 days a month", this was the first construction of its kind ever, probably only with minor similarities to other probes as they're always heavily specialized for their tasks. And they have major projects like this resulting in actual launches (and not being cancelled) just how often? It's not too many times per decade, maybe just a handful.
      • Re:Shit happens. (Score:5, Insightful)

        by JaredOfEuropa ( 526365 ) on Friday January 21, 2005 @07:47AM (#11430499) Journal
        I know the software folks here on /. always want to make excuses about 'its hard' and 'its to complicated', but, it's actually not hard, and not to complicated.

        [...]
        We do deploy equipment into life critical situations, so, for our work, 'shit happens' and 'i forgot' just dont exist in the vocabulary. We use checklists to ensure that all testing covers all forseeable abnormal conditions, up to and including partial failure of various hardware.
        You're right... up to a point. The amount of robust coding, testing, and many other things like security, are always subject to a balance of costs and benefits. Rigorous testing is expensive, and in many software applications it might be wise to, say, not do a complete regression test on a minor release since the cost of that test outweighs the risk of a bug slipping through.

        In your field of business, I imagine you cannot easily deploy quick fixes (to embedded systems), and major bugs in life critical situations are obviously not acceptable. So you do rigorous tests and code reviews. In my line of business however, bugs are acceptable. Sometimes a bug makes it into production... users will moan, and we'll have to spend a bit extra on writing and deploying the fix, but the cost is lower than doing a full test on every release.

        I agree with you that software developers should realise the importance of testing, and take a critical look at their own testing and coding procedures... often it isn't that hard or expensive to make real improvements.
        • It's never about costs. Mistakes ALWAYS cost more than thorough testing. It's about time constraints. Pure and simple.

          You pay to do it right, or you pay to do it wrong, pay to clean it up, and THEN pay to do it right.

          Test scripts are your friend. If you haven't been introduced to TCL (Tool Command Language) yet, you should seriously think about it.

          • Re:Shit happens. (Score:4, Insightful)

            by Doomdark ( 136619 ) on Friday January 21, 2005 @04:38PM (#11436177) Homepage Journal
            It's never about costs. Mistakes ALWAYS cost more than thorough testing.

            Well, that's kind of nitpicking. Although "time is money" is just a slogan, it does point to the fact that both timeline and money are constraints that affect test coverage that can be done. And cost/benefit analysis should be done for testing as well as for implementation: proper amount of testing to do is a compromise based on many things (type of system, expertise of implementers, aggressiveness of implementation/release schedule etc. etc.). So I would argue that it's ALWAYS about cost, in broad sense (delaying a release costs money -- that's the main reason to avoid delays).

            And finally, there are cases where defects just are cheaper to have, than doing rigorours testing. Like everything in software engineering, impact of defects is relative; there are no absolute guidelines.

      • Re:Shit happens. (Score:3, Insightful)

        by TheAJofOZ ( 215260 )

        I know the software folks here on /. always want to make excuses about 'its hard' and 'its to complicated', but, it's actually not hard, and not to complicated. complex systems are designed and built every day in the aerospace field, systems that many lives depend on.

        Which is precisely why there has never been a software glitch in a plane system. You know, like the TCAS system which saw ghost planes and told pilots to avoid them (noted in IEEE Spectrum [uni-bielefeld.de]), or any of the cases cited here [nasa.gov] or here [ncl.ac.uk]. Nope, aer

      • I know the software folks here on /. always want to make excuses about 'its hard' and 'its to complicated', but, it's actually not hard, and not to complicated

        It's not that it's too complex, it's that it's too costly for most applications. In a system where 1 bug can kill hundreds of people, it's OK to spend huge sums of money on processes, tools, people and time to deliver perfect software, but most people would not be prepared to spend vast amounts more for a version of Word (or whatever) that never cras

      • If "I forgot" or "shit happens" isn't an excuse, why did the Concorde crash just because nobody bothered to remove a bit of metal from the runway? Why did two 747s collide during a takeoff run on Tenerife due to a misunderstanding with ATC? Why did Korean Air 007 get shot down over the USSR after the crew mishandled the autopilot?
      • Re:Shit happens. (Score:3, Insightful)

        by Illserve ( 56215 )
        To be fair to the Cassini mission, they only have one trial to test it.

        The system of checklists you are using has been finetuned over many decades and probably *millions* of flights. And your operating procedures evolved alongside the hardware.

        I'm sure on their millionth flight, the Cassini operation would be just as airtight.

        If we were to turn back the clock to the first weeks of commercial airline travel, I imagine things were quite a bit different than the industry you describe.
      • Complex system interactivity and tight coupling have caused accidents in many industries and in the transport sector.

        Charles Perrow has an excellent analysis of those type of accidents in Nuclear Plants, Petrochemical industries, Aircraft & Airways, Dams etc.

        (Normal Accidents: Living with High-Risk Technologies, by Charles Perrow, Basic Books, NY, 1984.) http://oak.cats.ohiou.edu/~piccard/entropy/perrow. html [ohiou.edu]

        Most of these accidents and failures were not the result of lack of money or due to opera

      • Re:Shit happens. (Score:4, Insightful)

        by Oxygen99 ( 634999 ) on Friday January 21, 2005 @08:54AM (#11431016)
        Well. Precisely. Coding is hard, but not any more so than designing a building, an aircraft or an automobile. However, neither is it any less hard, so why is software engineering not accorded anything like as much respect as other disciplines? Do you see Airbus outsourcing airtcraft designs to the far east to save a few Euro's? No. Yet for some reason management always believes software can be written cheaper and quicker.

        Admittedly lives don't depend on 90% of the software any of us here writes, but that isn't to say it isn't complex or demanding and requires complex, demanding testing to ensure high standards of reliability.

        If those resources aren't allocated, then I'm afraid 'Shit Happens' is very definitely an excuse.
      • Re:Shit happens. (Score:3, Interesting)

        by Dracolytch ( 714699 )
        While I agree with the majority of your post, I think some of the expectations you place on ordinary software are a bit unrealistic. That is, in part, why daily use software is written differently than critical-systems software.

        It's always a balance between the probability of a given failure, the concequences of a given failure, and the cost of adapting to that error. Different types of projects have different ways of looking at this balance.

        What are the chances of a HDD being removed (or totally failin
    • Do you remember the last time when you wrote a program of 100 lines without doing a single error?

      Just this past week. Actually, it was a little less than 200 lines.

      I was kind of surprised it compiled and ran exactly right the very first time.

      The only problem was the 9 megabytes of input data contained numerous errors.

  • Human error (Score:3, Funny)

    by Mikmorg ( 624030 ) on Friday January 21, 2005 @06:14AM (#11430136) Homepage
    Lets just hope noone forgets to turn on the anti-missile lasers on the orbiting satellites. Bigger mistakes can happen. :)
  • by Maegashira ( 738950 ) on Friday January 21, 2005 @06:18AM (#11430151)
    i spent 23 years of my life to get a girlfriend. i deleted all my pr0n for her. now she is gone. life is truly a misery.
  • by account_deleted ( 4530225 ) on Friday January 21, 2005 @06:20AM (#11430160)
    Comment removed based on user account deletion
  • by thesp ( 307649 ) on Friday January 21, 2005 @06:22AM (#11430171)
    The article isn't quite correct. A fuller description [spaceflightnow.com] would take a while to type, so I summarise:

    Two redundant radio channels were used to get data from the lander to the orbiter, which relays the data to earth. The signal for the orbiter to start listening on the high-sensitivity channel, channel A, was never given. The data was transmitted redundantly on both channels, except for images and the output of the Doppler wind speed experiment. Fortunately, all was not lost, as scientists donated radio telescope time around the earth to search directly for the A signal, despite it not being relayed via the orbiter. Thanks to this increase in sensitivity, the data acquired was good enough to fulfill all objectives of all experiments.

    So everyone can relax and get one with the analysis...
    • So everyone can relax and get one with the analysis...

      Good point, Zen science is the best kind. Less stressful.

      Now, if only I could really become one with my thesis and finish writing the damn thing...
    • by Anonymous Writer ( 746272 ) on Friday January 21, 2005 @08:49AM (#11430940)

      This is what the slashdot post says...

      An experiment onboard the Huygens probe didn't run as planned because someone forgot to turn it on.

      But I got this out of your linked article...

      Huygens was programmed to transmit telemetry and scientific data to NASA's Cassini Saturn orbiter for relay to Earth using two redundant S-band radio systems. Channel A was the sole path for an experiment to measure wind speeds by studying tiny frequency changes caused by Huygens' motion. In one other deliberate departure from full redundancy, pictures from Tomasko's descent imager were split up, with each channel carrying 350 pictures.

      As it turned out, Cassini never listened to channel A because of a software commanding error. The receiver on the orbiter was never commanded to turn on, according to officials with the European Space Agency.
      ...
      Even the lost wind measurement data will be made up, thanks to a remarkable effort on the ground to monitor a faint carrier signal broadcast by Huygens - the equivalent of a cell phone call at a distance of 751 million miles - using a network of 18 radio telescopes around the world. That data, which not as precise as the Doppler information that was lost, should fill in the blanks.
      And I also found this [nwpr.org] article online. Here's an excerpt...
      Atkinson had a Doppler wind experiment onboard the probe which landed on Saturn's moon Titan after dropping from the Cassini spacecraft. Atkinson and other team members estimate they had put in nearly eighty- man years to bring that experiment to a conclusion this past weekend.

      However, a command to turn on the instrument being used by Atkinson's team was not in the command sequence. The entire experiment was lost. There is some hope that some transmitted data was picked up by radio telescopes back here on earth, and if so, then an Earth- based version of the Doppler experiment may still be possible. ...
      The Cassini mission, he says, has been incredibly successful, and he says eventually they'll get the wind measurements they needed, but definitely not how they planned, and he says it will take a long, long time.

      The reports are confusing and I can't tell what happened. Was there a measurement device onboard the Huygens probe gathering data and transmitting it (like the Slashdot story suggests), or was the data supposed to come from the measurement of the signal from the Huygens probe in relation to the Cassini orbiter?

      If it was the former, is the data not as good because the Earth radio telescopes didn't pick up the entire signal, because there was signal degradation, or because they have to piece all the data together from all the different radio telescopes? If it was the latter, is the data not as precise because of the proximity from the transmitter to the receiver?

      Either way, the Slashdot post is wrong. If it was a measurement device solely on the Huygens probe, it was turned on- it was the relay onboard the Cassini orbiter that wasn't turned on. If the data was meant to be gathered from the proximity of the transmitter to the receiver, then the experiment wasn't onboard the Huygens probe but was actually meant to be a collaboration between the probe and the orbiter.

  • Don't worry (Score:4, Funny)

    by Illserve ( 56215 ) on Friday January 21, 2005 @06:25AM (#11430179)
    I'm sure they'll have plenty of time to try again.

    They send these missions all the time don't they?

  • The Joint Institute for VLBI in Europe (JIVE) has reported that the Huygens signal has been picked up [www.jive.nl] by several Radio Telescopes on the ground. There was already a plan in place [uni-bonn.de] to investigate the Doppler on the signal to learn about Huygens' descent profile.
    Also, the most recent ESA press conference on Huygens stated that they are trying to recover data from the ground telescopes (which they are now referring to as Channel C), although it was unclear if this would be just the signal's Doppler or actua
  • by Jonathan ( 5011 ) on Friday January 21, 2005 @06:34AM (#11430209) Homepage
    I assume (like practically all scientific projects) grad students were involved in the design. While the failure to turn on the experiment may be an embarrassment to the primary investigator, how does it affect the grad students? Do they just leave the "results" section of their dissertations blank? Do they need to restart their graduate research with another project?
  • The guy should be happy!

    Everybody knows the Huygens probe. Nobody knows any of the scientists who worked on the probe.

    Now, David Atkinson has become a name.

    Granted, he's that-guy-of-the-Huygens-mission-who-was-screwed- out-of-his-experimental-results-due-to-a-stupid- mistake-on-the-part-of-a-programmer, but at least people know him!

    He can write a book! He can go on talkshows!

    He can even use the fact that he is now a name to get more funding!

    After the initial feeling of depression, he should real

  • by Gallowsgod ( 766508 ) on Friday January 21, 2005 @06:47AM (#11430262)
    Find the person who was responsible for this, send him or her up there to turn it on, and tell them not to expect any overtime for it. In fact, the costs for sending them up should be taken out of their salary.

    Might sound a bit hard, but it's the only way they'll learn.
  • by zrq ( 794138 ) on Friday January 21, 2005 @06:55AM (#11430288) Journal
    The Huygens team held a press conference [esa.int] this morning and presented some of the results of their analysis so far.

    The first scientific assessments of Huygens' data were presented during a press conference at ESA head office in Paris on 21 January.

    Results include:
    • Geological evidence for precipitation, erosion, mechanical abrasion and other fluvial activity says that the physical processes shaping Titan are much the same as those shaping Earth
    • Huygens' data provide strong evidence for liquids flowing on Titan. However, the fluid involved is methane.
    • ... while many of Earth's familiar geophysical processes occur on Titan, the chemistry involved is quite different. Instead of liquid water, Titan has liquid methane. Instead of silicate rocks, Titan has frozen water ice. Instead of dirt, Titan has hydrocarbon particles settling out of the atmosphere, and instead of lava, Titanian volcanoes spew very cold ice ...
    • So, how much more difficult would a manned Titan mission be than a manned Mars mission?

      I know it's a heck of alot further up the Sun's gravity well, and there might be some harsh radiation near Saturn.

      Is it doable?

      • They would have to have very very good thermal insulation.

        ... the fluid involved is methane, a simple organic compound that can exist as a liquid or gas at Titan's sub-170C temperatures ..

        From what I have heard, this is one of the reasons the probe had such a short lifespan, batteries don't last long at these kind of temperatures.
        I suspect that this would make even a rover type robot quite a difficult challenge.

  • Isn't it wierd how bad an event is can depend so heavily on how it happened? I mean, I'd be pissed if this happened to me but I think I would be less pissed if it was due to component failure rather than human error (actually, sounds more like process or Q/A error, but I digress). And even if it was component failure, couldn't that (often) be ultimately traced back to human failure somewhere further up the line.

    I dunno, we humans are strange.

  • by adeyadey ( 678765 ) on Friday January 21, 2005 @07:04AM (#11430326) Journal
    It would be fantastic if they could, but I think they are only talking about using the phase/doppler shift of the carrier signal to infer something about the location/movement of the probe. The high frequency data channel is probably lost in the noise.

    As someone who has been involved in large coding projects (100,000 lines +) while I understand how easy it is for bugs to creep in, I do think the programming bug that effectively did not switch on the second channel should have been picked up on a project of this size/budget. Sadly, too often, the bigger the bureaucracy, the more mistakes like this you have - small keen teams often do better.

    Regarding image quality on Huygens - in hindsight could that have been done better?

    I realise there are constraints - 80's hardware, limited batteries, 8k bit channel, etc, but here are my casual observations..

    Much higher resolution CCD's were available at the time - Cassini had a 1 megapixel unit. Low res data could have been transmitted during descent, but hi-res data could have been stored & broadcast after landing. As it is, the radio spent a lot of time sending identical images of the landing site. Another idea that gets a lot more out of a video data stream is variable jpg compression & only transmitting the signal difference between certain frames. That way you can use hi res CCDs then compress-until-it-fits the 8K data channel. When there is a lot of data/change in the pictures you compress a lot, but if certain cameras are not returning any or little change in the pictures, or if the picture has no detail, more channel space is available to send either hi-resolution or even pre-recorded data.

    Furthermore, why the assumption that the probe will be destroyed on landing? Why not switch off Huygens when Cassini dissapears below the horizon, and switch it on for the next day? (titan's day is 16 days long..) The batteries lasted many hours after the landing, and the craft did cruise in standby mode for 16 days, so this might have been possible.

    I think they could have returned all the data we got anyway up to the landing, and designed a 2nd phase with more data being sent, with little change to mission profile/weight/etc..

    One thing I dont understand - why are the triplets out of sequence? The early pictures show the landing site! Is this just some artifact of the transmission process?

    If I didnt know any better, I would say that final picture of the rocks was just a "joke" by the programmer, a frame to put in when the data/checksum fails for that camera.. :-)
  • by syntap ( 242090 ) on Friday January 21, 2005 @07:06AM (#11430342)
    Many of us downloaded and listened to the audio of the probe falling through Titan's atmosphere... could it be possible that processing the audio with known things such as downward velocity of the probe and assuming what it was flying through was methane (or whatever hypothesized atmospheric makeup), etc could yield similar wind speed estimates?
  • Reminds me of this story, probably apocryphal, that said that Daniel Webster of "Webster's Dictionary" once had his life's work destroyed by an angry wife. Immediately after she'd burned (??) his work in the fireplace, he took out a pen, walked to his desk, then started again from the beginning.

    • by adeyadey ( 678765 ) on Friday January 21, 2005 @08:28AM (#11430786) Journal
      Edmund Blackadder: Right, let's get the book. Now; Baldrick, where's the manuscript?

      Baldrick: You mean the big papery thing tied up with string?

      E: Yes, Baldrick -- the manuscript belonging to Dr. Johnson.

      B: You mean the baity fellow in the black coat who just left?

      E: Yes, Baldrick -- Dr. Johnson.

      B: So you're asking where the big papery thing tied up with string belonging
      to the baity fellow in the black coat who just left is.

      E: Yes, Baldrick, I am, and if you don't answer, then the booted bony thing
      with five toes at the end of my leg will soon connect sharply with the
      soft dangly collection of objects in your trousers. For the last time,
      Baldrick: Where is Dr. Johnson's manuscript?

      B: On the fire.

      E: (shocked) On the *what*?

      B: The hot orangy thing under the stony mantlepiece.

      E: You *burned* the Dictionary?

      B: Yup.
  • This isn't the first or the last time this sort of thing has happened. A minor issue about metric vs. imperial comes to mind, and didn't someone forget to remove a lens cap from the Hubble space telescope before it launched?

    "Hey, perfessor, lookit, we got us a high resolution image of the 'REMOVE BEFORE LAUNCH' galaxy!'
  • It's kind of funny that these big mistakes can still happen, even after unit miscalculations causing Mars lander crashes and other embarrassing things. You'd expect they'd try to simulate as much as possible before launching it? In the former case with the Polar Lander (?), simulating the software, and in this case simply trying to get readings from the instruments? But since I'm literally not a rocket scientist, there just has to be some severe difficulties in making checklists by routine and simply trying
    • I've wondered exactly the same thing. I don't know if it's possible to build an identical test satellite, but for a project of this duration, you'd think that some sort of full run-through testing would be done. Now it may be cost prohibitive to test the physical pieces (i.e., does a sensor deploy at 100mph when upside down, etc.), but the inputs to software can be simulated easily. Maybe this is why we pin our hopes on Spaceship One projects rather than NASA.
  • It probably wasn't very important in the grand scheme of things,like most things. He has a good atitude about it but it must hurt in many ways. That's life I guess. Not everything was meant to be and this is one thing. I guess the speed of the winds on some moon of Saturn are not very important in the eyes of a greater power, if such a power exists. Else, someone's head has got to roll.
  • Why don't we just send up a staffed mission, and have done with it once and for all?

    Obviously, this would have to be a kamikaze mission. But is that such a bad thing anyway? Throughout history, explorers on Earth have set out knowing they might not return -- and many did not return. Even Christopher Columbus knew there was a risk that he could be wrong about the Earth being round. Of course it's best if you can be a living legend, but if you have to settle for one out of two then it's surely better to
  • I've got to drive 40 miles on Monday to kick the ass of a broadband router that won't connect so I know how this guy feels.
  • You think they'd put a software on/off switch on that thing.

    I guess it'll be there for the next mission...
  • When it is stated that the guy "put eighteen years of his life into the project", does that really mean that, for 18 years, he spent all his workdays (or at least all his research time, considering he is a University professor) doing nothing else but designing and building the hardware for this experiment?
  • by MidnightBrewer ( 97195 ) on Friday January 21, 2005 @08:46AM (#11430916)
    You know, if I were this guy, I would have been calling them once every five minutes saying, "Hey, did you remember to get my experiment going?" If it's really that important, why let someone else screw it up for you? It's your baby, your responsibility.
  • by rpjs ( 126615 ) on Friday January 21, 2005 @12:05PM (#11433120)
    According to this BBC report [bbc.co.uk] they've recovered most of the lost data by receiving it directly from the Huygens lander using radio telescopes.

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Working...