Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Space Science

Spirit Sends Debug Information to Earth 477

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.
This discussion has been archived. No new comments can be posted.

Spirit Sends Debug Information to Earth

Comments Filter:
  • by Anonymous Coward
    Forego the obvious
    • by Anonymous Coward on Saturday January 24, 2004 @01:49PM (#8075970)
      How about red screen of death jokes?
    • by wash23 ( 735420 ) on Saturday January 24, 2004 @03:08PM (#8076429)
      You know, it occurs to me that maybe instead of having an interactive rover with a billion complicated subsystems and spectrometers and cameras... it might be a good idea to launch a package full of smaller autonomous devices carrying different instrumentation... So you'd have a base that lands on mars, opens up (like the rover bases do) and releases 20 or 30 "dumb robots" on treads or big balloon tires(I'm thinking each the size of a big R/C car), some of which would have cameras, the rest instrumentation of whatever sort.. All of the little slaves would move around randomly or according to some simple program (either mechanical or software) and relay collected information to the base, which would transmit it to earth... Some of the camera bots would be designed to just move as far as possible and take as many pictures as possible... others would just do instrumental analyses of whatever they happen to bump into or land on... You wouldn't know exactly what the instruments were looking at but you'd probably be able to collect a sizable amount of data on a particular landing region; know what minerals are present, etc. You wouldn't know that pyramid shaped rock 12B contains olivine but you'd know olivine was present.
      • You know, it occurs to me that maybe instead of having an interactive rover with a billion complicated subsystems and spectrometers and cameras... it might be a good idea to launch a package full of smaller autonomous devices carrying different instrumentation... So you'd have a base that lands on mars, opens up (like the rover bases do) and releases 20 or 30 "dumb robots"

        The two main problems I see with that is radio contact with the base and coordinated science. If a roverlet goes behind a hill it no
        • Good points. I'm sure NASA has thought of these sorts of things too; I have no idea where to read about them though if they have. It's sort of an interesting tradeoff to consider though; careful, directed examination of specific features of interest with really complicated instruments, or brute force "random" sampling with simpler ones.
  • by UnderAttack ( 311872 ) on Saturday January 24, 2004 @10:47AM (#8074940) Homepage
    128 kBits/sec! Quite a bit up from the ealire 100Bit/sec. Too bad Mars is too far from the next CO to qualify for DSL

    (first post?)
  • by Smallpond ( 221300 ) on Saturday January 24, 2004 @10:47AM (#8074942) Homepage Journal
    A diagnostic is what runs when nothing else will.
  • by JessLeah ( 625838 ) on Saturday January 24, 2004 @10:48AM (#8074952)
    ...but the ping times suck. Can you imagine playing Quake over that kind of link?
  • Wow (Score:5, Funny)

    by mbadolato ( 105588 ) on Saturday January 24, 2004 @10:49AM (#8074954)
    Spirit sent 73 megabits at a rate of 128 kilobits per second.

    Pretty damn scary that that's faster then most pr0n download's via Kazza... :)
  • by corebreech ( 469871 ) on Saturday January 24, 2004 @10:49AM (#8074956) Journal
    I watched the press conference on NASA-TV [nasa.gov] 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.
    • If it will not go to sleep at night it suggests to me that they have a serious hardware / software design flaw. They probably rely on software to initiate a standby vs alive mode. A proper design in this case would be to use standard analog circuits to do this type of job. Think about it you do not have to go out everynight and reboot your street light pole. Now of course this is pure speculation as IANANE
      but then again maybe I should be.
      • Analogue circuits are hardly a silver bullet.

        On the subject of streetlights, I was travelling down a major highway the other day. Usually there's a light or two that's stuck on during the day wherever you go. I decided to count how many there were, so I counted 100 streelights out. Out of those hundred, 19 *were stuck on in broad daylight*. The waste of electricity must be phenomenal, since these are all bright high-pressure Na lamps.
    • While I am sure the parent isn't at all involved in the project and is probably wildly off base, I think it is a very interesting observation. I mean the guys as NASA guess the same kind of stuff right? They just have the means to check it and rule it out (or not). I would have to say based on the limited info he has of the rover, that this isn't an all that unlikely guess as to the cause of problems.

      And for all those people that say things like "Do you think the people at NASA are just stupid and wouldn
    • by ultrasound ( 472511 ) on Saturday January 24, 2004 @12:47PM (#8075603)
      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.
    • by dtmos ( 447842 ) on Saturday January 24, 2004 @01:36PM (#8075893)

      Since Spirit is rebooting [cnn.com] sixty times per day, a problem that started when an electric motor moving its spectrometer "conked out", one thinks first of a hardware failure, possibly leading to software corruption.

      I don't know the boot sequence of Spirit, but in most battery-powered embedded systems with which I am familiar, an elaborate state machine design is made to ensure that, when the boot sequence is complete, the system has sufficient power to perform any task that may be requested of it. Since the power supply is limited, an unexpectedly heavy load on the primary supply could cause the supply voltage to the microcomputer to fall below its specified lower limit, leading to a system reset.

      Now imagine that there is a hardware failure associated with some process that runs during the boot sequence--a voltage regulator turn-on, a heating system initialization, an electric motor activation, whatever--that results in excessive current drain. When this part of the boot sequence is reached, the supply voltage falls, and the microcomputer resets. This disables the problem-causing hardware, unloading the power supply. When the supply voltage recovers, the microcomputer reboots (either automatically, with a power-on reset, via a watchdog timer, or via some other means) and, when the critical part of the boot sequence is reached, the supply voltage falls again. The system is now in a continuous loop, in which it can remain indefinitely. (Or at least 60 times per day....)

      Note that this situation can also arise due to a defect in the power supply--if the output impedance of the power supply has risen for some reason, its output voltage under lightly loaded conditions can be acceptable, but it may not be able to supply heavier loads.

      One expects the Spirit power supply to be complex, with separate regulators for the microcomputer, radio transceiver, and electric motors, so looking for common circuits and systems would be the first thing to do when troubleshooting for this type of failure. Looking for system conditions that can cause a system reset would be another; the JPL people have lived with their systems for years now, and would have had many design reviews to identify possible system failure scenarios--I'm not telling them anything new here. I understand that the system telemetry received yesterday indicates that the power supply is within specification, so that seems to eliminate that possiblility.

      The second alternative is a soft memory failure of some kind, either caused by a supply failure as the parent suggests or perhaps by a radiation event of some kind.

      Note that these problems can be multi-disciplinary; for example, the problem could be caused by some vibration when a motor runs that loosens a broken connection created by a chemical reaction to something on the surface (to take an extreme example).

  • by G4from128k ( 686170 ) on Saturday January 24, 2004 @10:50AM (#8074965)
    CNN is reporting [cnn.com] that spirit is self-rebooting 60 times a day. NASA suspects a hardware fault that is causing the processor to detect trouble and automatically reboot.
    • by pardasaniman ( 585320 ) on Saturday January 24, 2004 @11:07AM (#8075074) Journal
      It appears that while editing the crontab of the rover to send spam, the script-kiddie accidentally added a shutdown -r 24m . "Having the rover send spam was a great idea! When people ping the X-Originating IP, they'll surely timeout!!"
    • by pongo000 ( 97357 ) on Saturday January 24, 2004 @12:07PM (#8075388)
      Something like 2/3 of NASA's recent missions have failed in some way or another. Is it quite possible that NASA engineers simply have not mastered the art and science of designing hardware and software operable in the harshest of environments?

      In some ways, there is an air of arrogance in everything NASA does, from their press conferences to their marketing agreements. We have dead shuttle astronauts being transformed into "national heroes," even though their demise wasn't the result of any heroic sacrifices on their part, but rather a materials and systems failure scenario that NASA failed to handle properly. We have Spirit as the "little train that could," sending back waves of photographs of rocks that NASA engineers have actually named. Does the naming of rocks somehow bring NASA's mission closer to the unwashed masses who relate better to Beanie Babies than to the stark facts of reality?

      Harsh as it sounds, NASA is reaping what they sow: A string of hardware and software failures that is serving as a backdrop to newly-mandated initiatives by Bush to send miners to the moon and astronauts to Mars. Yet NASA can't even seem to get a remote-control buggy to work correctly. The mind just reels at the catastrophes that await us between now and 2015 should NASA continue down this road of inept management and hardware/software designs insufficiently tested against the harsh envrions of space. As geeks, we owe it not only to ourselves but to the non-geek public to recognize these failures as serious shortcomings in the NASA culture. We must resist the temptation to blindly set NASA on a pedestal in the name of scientific achievement without first critically analyzing their failures.
      • by G4from128k ( 686170 ) on Saturday January 24, 2004 @12:45PM (#8075592)
        Is it quite possible that NASA engineers simply have not mastered the art and science of designing hardware and software operable in the harshest of environments?

        While I would never claim that NASA is perfect, I think you underestimate the both the engineering challenge of putting a rover on Mars and the impact of more conservative, get-it-right, policies.

        Interplanetary missions are the hardest of all because the engineers never get to actually test the whole device under realistic conditions. Although they can test and analyze each subsystem under a variety of simulated or near-realistic conditions, they have no way of building a test rover, putting it in interplanetary space of months, having is aerobrake into a thin atmosphere, parachute in a thin atmosphere, and crashland at high speed, and then operate all its mechanical parts under dusty low G conditions.

        Second, get-it-right == conservatism == greater cost == fewer missions == less experience. The last thing NASA should do is spend more money, take more time, and do fewer missions. The only way we will really learn how to operate in space is to go into space. I'm not saying that better engineering won't help, only that more experience (unfettered by excessive conservatism) is a crucial part of learning to operate on other planets.
        • The last thing NASA should do is spend more money, take more time, and do fewer missions. The only way we will really learn how to operate in space is to go into space.

          This approach gives NASA the public exposure it needs to continue its work, but space is a very expensive testing ground. Where's the rush to get into space? It's not as if we're trying to capture fleeting moments of time. It seems ludicrous to me that NASA is on a 15-year time table...given the vastness of time in a cosmological sense,
          • by Jeremi ( 14640 ) on Saturday January 24, 2004 @01:15PM (#8075754) Homepage
            given the vastness of time in a cosmological sense, shouldn't NASA be considering 100-year or 1000-year timetables?


            That would be ideal, but keep in mind that NASA is funded by Congress, an entity that changes its mind about everything every 2-8 years. Any NASA program that takes too long to complete is very likely to be cancelled halfway through, wasting 100% of the resources that were put into it.

          • by AllUsernamesAreGone ( 688381 ) on Saturday January 24, 2004 @01:34PM (#8075886)
            It seems ludicrous to me that NASA is on a 15-year time table...given the vastness of time in a cosmological sense, shouldn't NASA be considering 100-year or 1000-year timetables?

            Unfortunately, if you want to look at things on the scale of cosmological time, we don't even exist. Human beings have been around for a blink of the eye of the universe, and unless we get our backsides off this damp ball of rock as soon as possible there's every chance that within another blink, we won't exist anymore. Between climate change (not even human-caused - the "comfortable" Earth we know is just a fleeting hospitible break between the planet's normal fire and ice), potential self-destruction, impact events and a dozen other risks, our continued persistence in keeping all our eggs in one basket is nothing short of asking for annihilation. How many other "intelligent" species would sit there and watch as enough rock and ice to wipe out life plunges into a planet that is, comparitively, just next door and do nothing? We did when Shoemaker-Levy 9 hit Jupiter. My only comfort is that, should the human race be wiped out while confined to Earth by its own lack of vision and sense, it'll be a service to galactic evolution.
      • If there was another agency out there putting machines on Mars, able to perform flawlessly for extended periods of time, and the NASA machines were the only ones crapping out, then I'd agree there needs to be some serious analysis of why NASA isn't getting it right.

        But this just isn't the case.

        From what I can tell NASA is doing as good a job as anyone on Earth with the technologies, manufacturing processes and testing programs available to them.

        I would hope that NASA be the first ones to run a diag
      • Maybe if Bush didn't invade Iraq, he could have given that 87 Billion to Nasa instead. In the mean time they have to do the best with what they have.

        I agree it's wrong to just put NASA on a pedestal, but analyze their success as well as thier failures, and be sure to compare it to the other space agencies out there. I think they are doing a pretty incredible job accomplishing lots of things that have never been done before.

        With that said, lets see how Opportunity does tonight!
        • Maybe if Bush didn't invade Iraq, he could have given that 87 Billion to Nasa instead.

          Ok- on one hand, we can spent the money to free 25 million people from a brutal and oppressive dictator, give credibility to the UN, provide a catalyst for the democratization of one of the most volatile regions in the world, and eliminate a threat to our national security.

          -OR-

          We can hurl more crap up into space.

          Thats a pretty tough choice.
      • by spaceyhackerlady ( 462530 ) on Saturday January 24, 2004 @02:50PM (#8076320)
        Something like 2/3 of NASA's recent missions have failed in some way or another. Is it quite possible that NASA engineers simply have not mastered the art and science of designing hardware and software operable in the harshest of environments?

        Maybe they have. That's how they know how difficult a task it is to get it right.

        I am something of an aerospace engineer, and work professionally with real-time systems (based on VxWorks - fancy that!). Let me illustrate the kind of bizarre bug that can happen on a spacecraft, and how it was fixed from the ground.

        Consider a satellite with a simple on-board computer. To guard against the OS locking up (no matter how good the software is, you can't protect against radiation-induced bit flips in memory), it has a hardware watchdog timer. The software resets the timer periodically, before the hardware can reboot the system. Things run well for a while.

        Then the on-board system starts resetting for no apparent reason. No suggestion of memory problems, no apparent hardware problems. The problem is traced to a radiation-induced change in component values in the watchdog timer, causing the timer to go off sooner than expected. Until the satellite is finally turned down a few years later, an important task of the ground stations was checking for watchdog resets and adjusting the software watchdog task accordingly. When the software eventually spent all its time resetting the watchdog timer, the satellite could no longer function and was turned down.

        The moral of the story: space is weird and hostile. Things happen. No matter how hard you try, you cannot always get it right.

        ...laura

  • by Anonymous Coward
    &^@%$@ WJS&&# D&@#&&# DD

    im sorry dave i can't do that

    &*A^S^ DJHDHSHA ASHHASD&@^%@@ DD&D^^@

  • CNN article (Score:4, Interesting)

    by pvt_medic ( 715692 ) on Saturday January 24, 2004 @10:50AM (#8074968)
    Cnn has an article [cnn.com] on some updates. Apparently the engineers been having all sorts of fun with the thing here a quick excert. "Cautioning that they will need more time to understand what went wrong, project engineers said they have determined that Spirit has rebooted or tried to reboot itself more than 60 times a day since the failure."
  • by Eevee ( 535658 ) on Saturday January 24, 2004 @10:50AM (#8074970)

    Only a couple of frames were fillers of random values. Most of the frames were engineering data. No actual scientific data came down, though.

    Still, it's a good sign that it's still able to talk.

  • by Crudely_Indecent ( 739699 ) on Saturday January 24, 2004 @10:51AM (#8074972) Journal
    It's nice to know that NASA engineers threw debugging code in the mix. Otherwise, we'd have a $410,000,000 junkyard on the red planet.

    I don't know what I'd do if I didn't get to see high resolution pictures of dirt and rock every day.
  • by darth_silliarse ( 681945 ) on Saturday January 24, 2004 @10:54AM (#8074989) Homepage
    Spirit Sends Debug Information to Earth

    A Fatal Exception 0E has occurred at 0028:C0231810 in VXD VMM(0D) + 00001810

    Cool! [bsod.org]
  • The little green men finally got thier hands on it... and haven't quite figured out how to put it back together again.
  • by mcleodnine ( 141832 ) on Saturday January 24, 2004 @10:56AM (#8075005)

    128 kbps over 35 million miles... looks like we'll need another benchmark to replace the station wagon full of DAT tapes



  • by cheezus ( 95036 ) on Saturday January 24, 2004 @10:58AM (#8075022) Homepage
    The transmission included power subsystem engineering data, no science data, and several frames of "fill data." Fill data are sets of intentionally random numbers that do not provide information.

    They don't say why it's sending fill data, but I bet the NASA geeks are happy about getting that engineering data.

    If we could put a man on the moon with slide rulers, we should have no problem figuring out how to three-key a computer on another planet
    • Fill Data (Score:5, Informative)

      by Detritus ( 11846 ) on Saturday January 24, 2004 @12:16PM (#8075438) Homepage
      Fill data is typically transmitted when the telemetry multiplexer does not have any engineering or science data to send. Due to the way synchronous communications links work, something is always being transmitted, even if there is no "real data" available.
    • by SnowZero ( 92219 ) on Saturday January 24, 2004 @02:29PM (#8076200)
      On Earth at least, picking bits off of radio links usually involves an adaptive threshold and a clock that syncs to the clock of the sender. Sending too many 1's or 0's in a row can interfere with that because there aren't any "bit edges" on the signal. Sending random data ensures all patterns are equally likely and your adaptive filter stays happy for when you have real data to send. Otherwise you'll miss the first part while you re-establish the threshold and sync to the signal.

      My guess is the NASA rover's link follows a similar principle, though its probably using some pretty damn fancy techniques to get the data from that far. Oh and missing the first part of the data would really suck for them since a retransmit would take 20 minutes.
  • . . .Spirit has rebooted or tried to reboot itself more than 60 times a day since the failure.

    At 73 megabits, that's a lot of BSOD. Oops. Sorry. Red Screens of Death with Spirit being on Mars and all.

  • Wind river (Score:2, Interesting)

    by hool5400 ( 257022 )
    Maybe Wind River [windriver.com] will not be so quick to brag now :)

    • Re:Wind river (Score:5, Informative)

      by AaronW ( 33736 ) on Saturday January 24, 2004 @12:22PM (#8075469) Homepage
      I wouldn't brag. I've been programming VxWorks for several years now and all I can say is it's a piece of crap for a complex system.

      VxWorks does not provide any memory protection (well, AE does, but it's so buggy nobody uses it).

      If a task dies, it does not clean up after it. All memory is global, i.e. any task can overwrite memory for any other task.

      Wind River couldn't even implement a decent malloc implementation. I had to replace it with Doug Lea's DLMalloc code (which glibc's malloc is based off of). It fragments horribly, and becomes increasingly slower the more free blocks exist.

      Just by replacing malloc, I brought the time down on our box from 50 minutes to under 3 minutes and went from tens of thousands of fragments to a couple of dozen.

      If you want a reliable embedded system with a lot of complexity, go with QNX or perhapse a good embedded Linux (I like Timesys Linux myself - good realtime support).

      At least with QNX if there's a problem in a task, it's much easier to isolate it and not kill the entire system. As it is on the product I'm working on, if a task dies about the only way to recover is to reboot. Also, VxWorks has piss-poor built-in debugging support. Sometimes you can get a stack trace. Tracing the heap is virtually impossible (and because it's a global memory pool, you don't even know what blocks were allocated by what task or even how much memory each task has allocated). In the product I'm working on I added such support to find memory leaks and detect memory corruption.

      VxWorks AE does provide memory protection. We tried to use it, but it was so buggy and slow we had to drop it and go back to standard VxWorks.

      VxWorks hasn't really changed in the last few years and Wind River is losing customers like crazy to the better alternatives. They're hemmoraging money at an astronomical rate and quickly losing market share to the likes of QNX and Linux.

      Even the realtime performance of VxWorks isn't that great. The finest granularity for a reliable timer is 1/2 the system tick rate (often no more than 20ms resolution).

      VxWorks doesn't have a shell as such either. The commands you type in are functions with parameters to those functions. You can do things like my_global = global_a + 7

      or

      my_func(&my_global, 3)

      on the command line, but it's not at all like a traditional command line.

      Most real-time Linux implementations arn't all that great either from my research into it. Most don't deal with priority inversion, or require a completely separate set of APIs for RT tasks (i.e. RT Linux). I found Timesys Linux to solve most of these issues and it looks like our next generation will be based off of either Timesys Linux or QNX.

      -Aaron
      • Re:Wind river (Score:4, Interesting)

        by gnalre ( 323830 ) on Saturday January 24, 2004 @03:25PM (#8076554)
        While I agree with the post in general, the one thing I do like about windriver is some of the debugging tools. It is hard to see how we could get along without windView for instance.

        I have been porting some vxWorks applications to windows recently(Don't ask) and the lack of a tool like that is killing me.

        Any suggestion of such a tool like windview that works on windows would be gratefully accepted.
      • Re:Wind river (Score:3, Interesting)

        by AaronW ( 33736 )
        I hate to follow up to my own post, but I heard on NPR that the problem is in the Flash memory.

        Usually in VxWorks everything is compiled and linked into a single binary image (i.e. no filesystem). For flash, the only built-in file system is FAT, not even FAT32. Due to this, it makes the flash much more critical. Fat itself is not very robust.

        Ideally they would have at least 2 copies of the image in flash and switch to the secondary if the primary fails a CRC or other validation test. Also, it should h
  • by BenBenBen ( 249969 ) on Saturday January 24, 2004 @11:03AM (#8075057)
    Did the "filler data" look anything like this [google.com]?
  • I wonder (Score:5, Funny)

    by skinfitz ( 564041 ) on Saturday January 24, 2004 @11:04AM (#8075058) Journal
    Doesn't Spirit's twin, Opportunity, start it's landing tomorrow?

    It's probably some bizarre licensing issue for the OS causing it to shut down as it's detected that NASA are trying to run two copies at the same time.

    Kind of like Beagle 2's problems caused by the transmissions being intercepted by the RIAA as they file a lawsuit against Colin Pillinger for offering illegal music downloads from Mars. [amishrabbit.com]
  • by Smallpond ( 221300 ) on Saturday January 24, 2004 @11:04AM (#8075061) Homepage Journal
    Fortunately, the cause [theeschalot.com] of the blackout has been located and will be corrected soon.
  • by Jacco de Leeuw ( 4646 ) on Saturday January 24, 2004 @11:06AM (#8075068) Homepage
    Pesky Martians! [jacco2.dds.nl] :-)
  • mars dvd message (Score:5, Interesting)

    by xk ( 64049 ) on Saturday January 24, 2004 @11:09AM (#8075084) Homepage
    Has anyone cracked this [planetary.org] yet?

    -bk.
    • Re:mars dvd message (Score:3, Informative)

      by 222 ( 551054 ) *
      Yea, I actually asked ( http://www.elonka.com )Elonka of Kryptos fame about this yesterday, it seems someone has indeed cracked it, although im not sure if any of them have come forward.
      Although i havent personally worked on this, it really seems like something that nasa put together for middle school students looking for something fun to do, not something any experienced codebreaker would have trouble poking through.
  • by tjstork ( 137384 ) <todd.bandrowskyNO@SPAMgmail.com> on Saturday January 24, 2004 @11:12AM (#8075099) Homepage Journal
    "I can't swim.. I CaN'T sWim ... I cannot swim... I can't swim.. I can't swim.. I can't swim.. I can't swim.. I can't swim.. I can't swim.. sdf@#$@#$@#$
  • by Anonymous Coward on Saturday January 24, 2004 @11:15AM (#8075118)
    rover: 128kbps
    most mp3's: 128kbps
    COINCIDENCE?
    i think not.
  • vxWorks... (Score:3, Informative)

    by codepunk ( 167897 ) on Saturday January 24, 2004 @11:17AM (#8075122)
    From the windriver site....

    Power and versatility was delivered via the advanced applications developed for each of the robotic functions of the Rover devices, plus their communications links with the landing craft. VxWorks not only served as the ideal development platform for the engineers, it also had to be sufficiently robust itself to ensure it would perform according to plan under the extreme conditions on Mars and during the journey from Earth.

    To bad it never makes it to run level three sounds like init is dying..
  • by Anonymous Coward on Saturday January 24, 2004 @11:18AM (#8075127)
    ...European, constantly rebooting, battery draining overlords. Now we know Beagle 2 was not lost but was in transit to Gusev crater. It took a little time to silently creep up behind spirit. If we had a high-enough resolution camera we would see that damn dog continuously poking at the rover, pressing our reset button.

    Cheers to the European engineers who caught us with our pants downs and jeers to the American engineers who thought our little rover needed an external reset button for some reason.
  • by Snork Asaurus ( 595692 ) on Saturday January 24, 2004 @11:27AM (#8075161) Journal
    Extreme Remote Debugging
  • Connections (Score:4, Funny)

    by vpscolo ( 737900 ) on Saturday January 24, 2004 @11:36AM (#8075203) Homepage
    Great the probe has a faster connection than I have. Now I've got to go live on mars

    Rus
  • by roman_mir ( 125474 ) on Saturday January 24, 2004 @11:40AM (#8075222) Homepage Journal
    you remember, the Apollo 13, the one with Tom Hanks? Where the austronauts believe that their transmission is watched by the viewers on Earth but in fact all TV networks refused the transmission, stating that NASA made flights to the Moon as exciting as trips to Pittsburgh (or something of this kind)?

    This is what is happenning people, the new in reality TV - our own Mars Rover - The Ultimate Survivor. The Opportunity will be landing today, so the audience should be able to vote for which rover is going to be kicked out of the show.

    The Drama, The Excitement, The Unknonw, The Sex... oh, wait!

  • by hazee ( 728152 ) on Saturday January 24, 2004 @11:46AM (#8075251)
    Is it just me, or has anyone else been very puzzled by the pics that NASA released of Sprit's landing site [nasa.gov]? These were supposedly taken by the Mars Orbiter Camera on the Mars Global Surveyor.

    I thought that the best cameras in orbit around Mars were those on the European Mars Express, with a top resolution of 12 metres/pixel, and yet here the Spirit lander, about 2 metres aross, is spread across about 10 pixels.

    Something's not right...
    • by AndroidCat ( 229562 ) on Saturday January 24, 2004 @12:01PM (#8075348) Homepage
      They're trying a new technique. From this article: [spaceref.com]
      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.
  • by Chilles ( 79797 ) on Saturday January 24, 2004 @12:01PM (#8075347)
    When the last lightminute is no problem but the last mile is?
  • by Eluding Reality ( 691589 ) on Saturday January 24, 2004 @12:04PM (#8075370)
    NASA's Spirit rover did not go to sleep today even after ground controllers sent commands twice for it to do so.
    It looks like NASA is experiencing a common parenting problem, I suggest something like this [amazon.com] for the rocket scientists
  • by Comatose51 ( 687974 ) on Saturday January 24, 2004 @12:54PM (#8075647) Homepage
    OK, which one of you posted the URL to Spirit's onboard webserver on Slashdot???
  • by maelstrom ( 638 ) * on Saturday January 24, 2004 @01:02PM (#8075697) Homepage Journal
    To have some actual technical discussion on a site that is supposed to be filled with nerds, instead of the same tired jokes about martians.

  • by dekashizl ( 663505 ) on Saturday January 24, 2004 @01:36PM (#8075891) Journal
    For news, status, updates, scientific info, images, video, and more, check out:
    (AXCH) 2004 Mars Exploration Rovers - News, Status, Technical Info, History [axonchisel.net].
  • by jasno ( 124830 ) on Saturday January 24, 2004 @01:59PM (#8076035) Journal
    Is there any reason the code, schematics and CAD designs aren't available for public viewing? Its a publicly funded project, and I don't think JPL has to worry about trade secrets.

    If JPL would give us more information, I bet they'd have 50% of the entire engineering brainpower on the planet checking for races, inversions, memory leaks, hardware design flaws, etc.

    If there was ever a project that could benefit from so many eyeballs, its space exploration. There are thousands of some of the most talented engineers on the planet who would jump at the chance to contribute to something like this.
  • unmanned probes (Score:3, Interesting)

    by tgibbs ( 83782 ) on Saturday January 24, 2004 @02:22PM (#8076146)
    Despite what seems to have become a widely held belief that we can learn as much from automated probes as from manned missions, it doesn't seem to have worked out that well in practice. Viking had a set of experiments that was supposed to definitively detect whether life was present. But when some of the experiments came out positive, they ended up being rejected, because researchers at home came up with nonbiological explanations. Unfortunately, there was nobody on site to do a follow-up experiment to really answer the question. Now we've had a long string of failed probes.

    Perhaps all Spirit really needs is somebody to give it a little kick.
  • by coaxial ( 28297 ) on Saturday January 24, 2004 @05:20PM (#8077328) Homepage
    Spirit is on fucking Mars and I'm stuck here in the boondocks of Earth and I still only get 56k.

    Damn it.
  • by io333 ( 574963 ) on Saturday January 24, 2004 @07:02PM (#8077882)
    The flash ram went bad." [nasa.gov]

    Why does this not surprise me? I'd guess that SanDisk put in the low bid for that part.

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Working...