Spirit Sends Debug Information to Earth

gfilion writes "NASA has released a press release that says: 'Shortly before noon, controllers were surprised to receive a relay of data from Spirit via the Mars Odyssey orbiter. Spirit sent 73 megabits at a rate of 128 kilobits per second.'" They've been having communications troubles with Spirit since Wednesday, so it's good to hear from it again, even if the data is just filler.

Comments

Can low-power corrupt memory?

[corebreech]

I watched the press conference on NASA-TV and they talked about how the thing wouldn't go to sleep at night and so it got me to wondering about the low power question. Obviously they have the rover power off when power gets to a certain level, but what if that level is slightly off?

In other words, if the onboard CPU has enough power and continues to run but the memory doesn't have enough power, doesn't that cause all kinds of wackiness?

They keep talking about the data pointing to simultaneous faults... well, as programmers we know these are the very worst kinds of bugs to deal with, but with something as (I'm assuming) well written as their code, so doesn't that point to a memory problem? I mean, the think is working flat-out beautifully one moment, and then the next moment it goes tits up.

The other question I had concerned this motor they had turned on but which didn't complete its sequence. When they command the motor to do something, do they tell it to run for some interval of time, or do they tell it to achieve a specific position? I was thinking that if it's the latter, and then if it gets stuck somehow, this could create the low power situation as the motor just grinds away.

Re:Can low-power corrupt memory?

[ultrasound]

Generally there are low-voltage detection circuits inside and/or connected to the microprocessor that detect that power is fading, and wrap things up, terminating any writes in an orderly fashion if possible. Generally any power-down is going to be very slow (orders of 10s to 100s of milli-seconds or more) because of capacitor storage in the power supply. The LV device gives sufficient notice that power is fading so that the remaining processor time is more than ample to shut things down gracefully.

Obviously with volatile RAM without battery backup we shouldn't need to care about the state of the RAM on power-down as it is only temporary storage and will be re-initialised on power-up. Generally the storage components will have wider operating tolerances than the microprocessor so it is very unlikely that the RAM will get corrupted during the powerdown proceedure.

With non-volatile hardware such as battery backed RAM, flash, eeprom, fram etc we have a problem because these contain NV config data and firmware that must be consistent. And with some such as FLASH the write times can be very long, may be longer than the power-down time. In this case the general philosophy is to write the bytes, and the very last step is to update the checksum and set a valid data flag. Which means at worst the device boots up and knows its got some dodgy code or data on its hands, and hopefully handles it in a graceful fashion.

With something like the Spirit I would guess that some form of multiple redundancy is used so that there are multiple firmware images, with a switchable bootloader so that a new image or dataset can be uploaded to an area that is offline, and only once all of the checksums/message hashes are confirmed is the switch made. And hardware watchdogs are running so that if the worst happens and it hangs it can always boot an alternate image. I would also expect a backup OTP PROM image that is guaranteed never to change and known to work.

mars dvd message

[xk]

Has anyone cracked this yet?

-bk.

Re:400 million and only one CPU

[0x0d0a]

Nasa systems that involve human life are highly redundant. I remember a lecture by a NASA engineer about systems on the Shuttle. There are *seven* redundant computers which calculate data. That data requires identical answers from four to be accepted.

On Spirit, power is an issue. More CPUs == more power drain.

Furthermore, I remember the folks initially speculating that something was wrong with the power system. I stopped following it, but it said that this transmission was composed of power subsystem diagnostic data. Could be it's a response requested earlier that it didn't have enough juice to send, in which case more CPUs would have actually exacerbated the problem. :-)

Re:Suspiciously good pics of landing site from orb

[AndroidCat]

They're trying a new technique. From this article:

The MOC image of the Spirit lander and its landing site was acquired using a new technique that was pioneered by the MGS project in 2003. Called "cPROTO" (for Pitch and Roll Only Targeted Observation with planetary motion compensation), the approach allows MOC, which normally takes pictures 1.5 meters (5 feet) per pixel to 12 meters (40 feet) per pixel, to acquire images with a higher resolution. By pitching the MGS spacecraft at a rate faster than it orbits around Mars, and moving it in a way that compensates for the rotation of the planet, MOC is able to obtain images with a down-track resolution of about 50 cm/pixel (~20 inches/pixel), although the cross-track resolution remains ~1.5 m/pixel (5 ft/pixel). These images have a better signal-to-noise ratio than typical 1.5 m/pixel MOC images, as well. This technique allows the lander and other details not normally visible in a full-resolution MOC image to be seen.