Slashdot Mirror
Saving Huygens
TazMainiac writes "This months IEEE Spectrum is running an article on how a Swedish scientist discovered that the Titan probe Cassini had a communications flaw that would cause it to lose all data sent back from the Huygens lander as it plunges into Titan's atmosphere. The problem - Doppler effect. The fix: go read the article."
The problem was discovered years ago, took 6 months to investigate and nearly 2 years to resolve. The BBC told us all about it with nice graphics the other night.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Oooooh! I love that technical jargon.
Spoiler Warning:
Now you know how they fixed it, so no need to read the article.
See what I've been reading.
They were supposed to run a simulation, as one of three safety nets to catch such problems, but decided not to because of the cost.
http://www.busyweather.com/
a collaboration with the European Space Agency, Cassini, in addition to its own suite of scientific instruments designed to scan Saturn and its moons, carries a hitchhiker--a lander probe called Huygens.
http://www.busyweather.com/
Certainly, satellites around the Earth qualify -- if you want to be truly successful working with amateur (ham) satellites, you need to adjust for the doppler shifts., especially at the higher frequencies. If you don't, you'll only be successful when the doppler shift is small -- basically, when the satellite is as high in the sky as it's going to get in this pass.
Suppose your signal is at 441 mHz, and the signal is only 20 kHz wide. It only takes a 0.005% shift in the frequency to move that signal 20 kHz so you can't detect it at all, and doppler shifts seen by objects in low Earth orbit satellites can be a good deal larger than that.
It looks like the relative velocity of Cassini to Huygens actually *was* high enough to lend a singificant Doppler shift, so correspondingly the data rate was massively compressed--like the frequency of a racecar coming towards you getting higher and higher, except in this case its bitrate instead of sound. The antenna was only designed to "listen" for a fairly static bitrate --like if once the car got close enough and the sound frequency high enough you just stopped hearing it. So instead they're altering the flightpaths so that Cassini is now far enough away from Huygens that the broadcast vector is mostly perpendicular, with minimal Doppler shift -- think about standing very far away from the racetrack instead of right in front of the car. The total distance between you and the car changes by much less, so you hear more of a constant hum than a higher and higher frequency, analogous to the drone of a jet plane passing far overhead. Because the Doppler shift is minimal, the antenna can now receive data at a nearly constant bitrate it can handle. Very nicely done.
What I find hard to beleive is that the data slicer for the radio was not a chunk of code running on a processor, rather than a hardwired circuit.
I do SDR (Software Defined Radio) for a living - doing a data slicer like this isn't very hard at all. Why they couldn't just reprogram the slicer to take into account the bit timing shift - or better still, why weren't they resyncing on the zero crossings of the signal so they could deal with bit timing errors automatically?
Hell, for that matter why don't they have an option to route the recovered signal verbatim to the main transmitter and send that to earth - and do the signal processing here? NASA *used* to have the philosophy of "all the bits to earth" - the wouldn't even use lossless data compression lest the signal be corrupted and unrecoverable.
www.eFax.com are spammers
The relative velocity was quoted as 5.5km/sec which means v/c=0.000018. This is not such a small number.
Furthermore, even though the frequency changes little, the phase can shift a lot. The change in phase is proportional to v/c times the number of cycles in the segment you are examining - and there are a lot of cycles in 1/8192 second chunk of the microwave signal they are using to communicate.
Lastly, the length of the transmission also matters - 2 hour transmission of 1/8192 sec chunks amounts to approximately 60 million chunks. If you multiply the doppler shift above by the number of chunks you get approx 1000 - i.e. the chunk timing will shift through completely 1000 times during transmission. (In other words you will be drifting in and out of sync with transmission rate 1000 times during descent.. A sure way to get most data scrambled)
Is *IS* a "software" radio and not hardware. It's implemented in "firmware" and they say they could have changed it easily, except there's apparently no way to do so after launch.
The problem is they didn't find this problem until AFTER launch. good timing, right?
The amount of doppler shift is proportional to frequency and velocity. But it wasn't the change in signal frequency alone, it was the change in length of data timing as well.
The general equation is:
fdoppler = (frest * velocity )/ c
where:
fdop = frequency after doppler shift
frest = frequency before doppler shift
velocity = speed of object relative to oberver
c = speed of light
Although radio waves have a longer wavelength (kilohertz/megahertz) than light (terahertz+), the
effect is less noticable, but still significant.
According to the article, the doppler shift was +/-38 Kilohertz. Given the fact that data was being transmitted on an 8/16 Kilohertz carrier wave, that's a rather significant change.
This is enough difference to allow police speed radar traps to work, and for researchers to measure the wind speeds inside tornado's.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
s/NASA/ESA/g
NASA was only observing - this part of the project was pretty much run by ESA. Still a "cock-up" all around.
Underloved Movies and Pub Quiz: donotquestionme.org
NASA Has an Independant Verification and Validation Center to provide technical oversight. I worked there (it's in West F'ing Virgina of all places). The folks there do a great job with what data they are given. Often to save costs, this IV&V team is not even allowed to participate in the Design Reviews, and when they are and discover issue the Project Offices sweep them under the rug. No use admitting to problems that might show someone is not thinking correctly or is not managing the project well. The theory is "Let's avoid the problems by witholding information and communication from anyone who might find a problem". Solid testing? Thats a joke too, it costs money to test things well, and who knows they might break!. Contractors will make mistakes, after all they employ humans, but the mistakes can be corrected BEFORE flight if they are found. Having an extra set of eyes, and doing extensive testing is valuable but costly. In FACT having IV&V on manned systems is the LAW since the Challenger disaster, it's just commonly disregarded at NASA for anything but ISS. Even STS has no IV&V, after all it's a "mature" system and there are no bugs left. Regardless of what you hear about NASA "changing" after Columbia it really isn't. I fully expect another STS disaster, and several more mini-disasters in unmanned systems in the near future.