The Forgotten Huygens Experiment
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."
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.
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.
Everything in the world is controlled by a small, evil group to which, unfortunately, no one you know belongs.
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.
... a link to today's /. poll
The article isn't quite correct. A fuller description 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...
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.
The belief in a biblical god is an ignorant one
The first scientific assessments of Huygens' data were presented during a press conference at ESA head office in Paris on 21 January.
Results include:
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'.
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.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Black and white sensors have higher resolution, just as black and white film has higher resolution. Resolution is more than the number of pixels, it's the valuable ability to resolve actual data with those photosensors.
Your little consumer digicam that did not cost a hundred thousand dollars is arranged with cheap little colored filters, cutting out over half of the photons that arrive in the camera, just so you can get the right shade of pink on your girlfriend's tummy. Scientists would rather collect all the photons they can, thanks.
Scientists do use filters now and then. Spirit and Opportunity use black and white cameras, but they can use something like NINE different filters to block out all frequencies except certain bands of interest. They don't just select Red, Green, Blue, but also various bands of near and far Infrared and Ultraviolet too. Those probes were designed later, and were going to be used on a longer mission, where power and available light energy would be greater. Huygens was built earlier, and going to a distant and dark moon where they'd be lucky if the probe lasted a couple of hours.
Is their logic still a mystery to you?
[
Roughly five to ten O's have been omitted. Homer's trademark expression was voice actor Dan Castellaneta's interpretation "[ANNOYED GRUNT]" (which is how "D'oh!" has always been written in scripts for Simpsons episodes). It's based on the "Dooooooooooh!" from the Laurel and Hardy routines, only shortened considerably. Source
qntm.org