Slashdot Mirror
Spirit Rover Communications Error
cybrthng writes "Through yesterdays press release and the current Nasa Briefing there is news that they are having communications errors with contacting spirit. Is she lost or is it something akin to the Pathfinder failures that happened? Or did little green people claim an expensive tonka truck toy?"
From the press release: similar events occurred several times during the Mars Pathfinder mission So a friendly "Don't Panic."
The BBC is reporting it here.
/* This sig is disabled. Press CTRL-W to enable. Thankyou */
Its been reported that a signal was sent to Spirit this morning to try and figure out whether it was in fault mode or not, and preliminary results suggest that Spirit is in fault mode. This is preliminary data and was announced half way through the news conference.
There is as of yet no reliable information as to what the state of Spirit is.
I watched the press conference and have read extensively about the communications system. I am also the person featured in yesterday's slashdot article about imagery and my postprocessing/color correction/stereo anaglyph creation from it.
By now they have probably rebooted it (forced it through safe mode to clear any software fault; space vehicles never really go all the way "down"), so if it's still happenning I would say it's either a hardware fault or corruption of essential software or data in (putatively) nonvolatile memory (not unreasonable in high-rad environments).
Not impossible, but relatively unlikely with deep-space grade hardware. It'd require a double fault to create a detectable error, and more than that to create an undetectable one.
If they haven't forced it through safe mode, then they're not too worried and are more interested in characterizing the problem than getting on with the scientific mission. Which is a good or a bad thing depending on which sort of information is more valuable. I'm sure the guys in the software group have their bias.
They've had one day, and much of that was spent thinking the problem was because of thunderstorms/atmospheric vapor near Canberra and dish tracking problems were causing communications errors. It's important to get some idea of the problem before you go shoving things into safe modes because you may make things worse (if it's a power bus fault, for instance).
That tone is still unconfirmed-- they are not positive they have received it (it came in only 2.5 hours ago and processing the data sets takes time.. NASA has not confirmed that they are sure they got a 7.2 tone).
But I agree it is likely the rover is reporting it is faulted, even if it is not a sure thing yet.
That last paragraph should be shot.
They have only had one day to troubleshoot. Much of that day was spent assuming atmospheric water vapor and dish tracking problems caused errors in sending command traffic. It's important to get some idea of the problem before you go shoving things into safe modes-- else you might make things worse.
They haven't quite given up on Beagle 2 yet. For the last few days its controllers have not sent any communications to Mars. Assuming that the lander is in one piece, it should now have switched to a beacon mode which will transmit throughout the Martian day.
ESA will begin listening for Beagle 2 again over the weekend, but this is very much a last-ditch attempt.
Best wishes,
Mike.
Stay tuned ...
chongo (was here)
Spirit status updates are here: http://spaceflightnow.com/mars/mera/statustextonly .html
"To confine our attention to terrestrial matters would be to limit the human spirit." -Stephen Hawking
Spirit runs an Operating System called VXWorks, by Wind River.
The software running onboard the MER rovers is not written in java. Not even a little bit. Sun's posters and propaganda at last year's JavaOne seemed to deliberately give that false impression. There is plenty of Java running on the ground, though, for both planning activities and processing the downlinked data.
Personally I prefer a good side kick. It leaves you with space to hop out of the way, and if done right will get you several items and some spare change
--Keeping the flame wars alive, one post at a time
No. The rover's architecture allows for it to correct single bit errors, but a garbled packet will simply be rejected by the rover.
It's a Bagel.
I meant a synchronization problem between the physical transmitter unit and the main avionics system.
When it comes to clocks, it is somewhat complicated. The rover keeps a clock, and usually finds earth by locating the sun in the sky. It has a set of keplerian/rotational elements for both Earth around the Sun and the MGS/Odyssey around Mars, and thus knows when they rise and set in the sky. This tells it when to transmit and where to point the antenna.
Full duplex communications are possible on xband, so transmitting and receiving do not need to be synchronized. Blocks of data are sent with error correction codes-- as they arrive intact, messages are sent telling the rover to delete them. Retransmits can also be requested if the data is particularly interesting and missing (but often aren't, as witnessed by the number of empty portions of images.
UHF is usually just used to offload additional data from the rover during the night to the satellites. The delays are short and the protocols are thus more conventional.
There's much more detail about this here.
Apparently, Tidbinbilla is one of only 3 stations tracking Spirit from Earth. If it's out, they have to wait until Spirit is visible from over the horizon at another station before they can communicate.
"The plural of anecdote is not data" -- Bruce Schneier
The OS on the Spirit lander was created by Wind River - details are here. As with any OS designed for deep-space uses there are multiple redundancies on virtually every aspect of the system.
Nothing runs Windows in this respect. The Rover runs custom code for the Rad 6000 chip they use in the vxworks RTOS, and the mission control systems use Java to run a live version of Meastro.
Also, the chip they use, a radiation hardened 6000 CPU comes from the days before Java was even thought of. Read up on the facts first.
NASA has experience with uploading new software (including os) to deployed spacecraft to correct defects.
On Tuesday, I talked with some of the project scientists for a TechTV interview that's running next week on Screen Savers. One of the many things I learned from them was that they upload new software, and patches, and all that stuff with surprising frequency and ease.
The thing that really blew my mind was, in order to make their launch date, they just coded enough commands to get the thing there, and sent all the software to drive around and research stuff after the landing while the spacecraft was in transit.
I really hope they solve this current problem, and get the mission back on track. They are SUPER cool people at JPL who are working on this.
Pathfinder in it's 1997 landing (04JUL1997) suffered a series of unexplained system failures. David Wilner CTO of WindRiver Systems, the creators of WxWorks the realtime embedded system kernel talked to IEEE Real-Time Systems Symposium at a later date explaining how they solved software bugs in the system.
this article explains how they solved the problem - by including the debug code with the os. I remember reading about this on /. some time ago. A detailed account can be read here by Glenn Reeves (JPL Mars Flight SE).
Windriver systems is supplying the OS for the current mission. Lets see how long it takes them to work this one out :)
links:l r itative_Account.html
www.kohala.com/start/papers.others/pathfinder.htm
research.microsoft.com/~mbj/Mars_Pathfinder/Autho
peterrenshaw ~ Another Scrappy Startup
Err, did you read the link?
priority inversion can be protected for however the mutex can be coded in two states. Priority Inversion Safe and non priority inversion safe. Unfortunately they forgot to turn the priority inversion protection on. Programming error, plain and simple.
Choose your allies carefully, it is highly unlikely you will be held accountable for the actions of your enemies