That might work well, but we use an off-the-shelf sensor so we can't have a custom filter. No, the narrowband filters work because the Bayer filters are transparent in the near-IR, where the narrowband color can be used to look for iron-bearing minerals. In the visible, there is always some overlap between the narrowband filter and at least one of the three Bayer filters, often two. In those cases we just adjust the interpolation appropriately to use only the pixels that have usable signal after light has passed through both the Bayer and narrowband filters.

That's a downlinked data volume question; the hardware can certainly do it at up to 10 fps. Of course, nothing much is moving at rates that would justify a frame rate that high; the team is still considering this. (And no, we can't see the descent stage fly away; Mastcam and MAHLI are still turned off and stowed, and MARDI is pointed down.)

I'm certain we'll try this, but we only have 100 mm focal length, so I'm not sure the disk will even be resolved; it'll still just be a blue dot.

I'm not sure how to quantify "more advanced." They're about 100x faster with about the same noise performance. The MER cameras were all fixed-focus. Mastcam has a 10:1 zoom lens with autofocus. MAHLI (the MI equivalent) has adjustable focus with autofocus. All the instruments are capable of realtime image compression and other internal image processing and have 8 GB flash buffers for data storage. They can all take Bayer-pattern color images with one frame (some might call that less advanced than multiple exposures through color filters, but Mastcam can do that too.) On the other hand, they weigh more and are a lot more mechanically complex, which I can assure you is a development challenge.

First off, about the "you and Mike were reporting". As I've pointed out before, that was Wayne Lee's misidentification, as Malin was at JPL, and not on the voice net. It was me, me, all me!

During the development of the relay capability for MER, we were always careful to not make any latency guarantees, since so much depended on circumstances beyond our control (bad DSN tracks requiring recorder playbacks, the need to tweak software if needed, etc, etc.) For EDL it all worked, and we leaned on our own processing pretty hard to get the data to JPL quickly, but I could understand if you didn't expect that.



Thanks. A bunch of people at MSSS, CNES, Alcatel, and LMA worked really hard to make it happen. I'm just as glad the whole effort ended up as a footnote, since the only way it wouldn't have been was if a MER had crashed and been lost.

For Spirit, you had UHF data from MGS before you had the post-landing tones. It's not my fault you didn't pay any attention to it.

http://www.gao.gov/docdblite/info.php?rptno=NSIAD-94-24 is a good place to start.

"NSF" apparently refers to nasaspaceflight.com, not to the National Science Foundation. I don't think Jim is being official here, just very terse.

That said, ITAR is a real concern for this sort of thing. Trying to get launch vehicle information beyond that given in the cleared payload planning guides is going to be pretty hard, if not impossible.

JPL uses in-house tools as far as I know. Recently some projects have started using SOAP (from Aerospace Corp) but I don't know what licensing terms it has or what it can do in this area (I've mostly seen it used for visualization.) I've worked on proposals where we used STK's Astrogator (costs big, big bucks). SAIC's Trajectory Optimizer used to come in a cheap demo version that was sufficient to compute delta-v for planetary transfers of various sorts, but I don't see it on the net any more.

I think it's unlikely that a truly usable package that does all this stuff exists for free.

In KSC-07PD-1091, it's the thing with the blue glove on top of it. It's mounted to a bracket on the bottom surface of the science deck.

http://nssdc.gsfc.nasa.gov/database/Master...g?ds=PSPA-00335

This work was done, I believe at the Stanford AI Lab. It's digital contour data and would have to be interpolated to form a DEM. The whole dataset could be reprocessed using more modern techniques, I guess, but I'm not sure if anyone considers it that scientifically useful.

For what it's worth, at MSSS none of us call it anything in particular; I don't even think we consider it a separate entity, it's just a subsystem.

Short answer: maybe. See http://contactincontext.org/cic/v2i1/lucy.pdf for a "yes" and http://www.setileague.org/editor/uhftv.htm for a "no".

http://www.press.discovery.com/ekits/space...ge=pressrelease

Yes, it's just the IMAX movie on TV. Premiere is Thursday, May 10, at 9 PM (ET/PT).

http://passporttoknowledge.com/mars/mission/tomshainksc.html

I feel fairly sure that they have a reason. Maybe not one you'd agree with, but they're the ones with their *sses on the line. From the article, it sounds like they just enjoy trucking.

For what it's worth, MOC2 was trucked from Caltech to LMA in Denver, and CTX was flown in a chartered Lear 35 from Carlsbad, CA to Centennial outside of Denver. Given the choice, I'd pick the Lear every time.

You can read through the status reports at http://mars.jpl.nasa.gov/mgs/status/reports/msop-mgs.html
looking for "safe mode", "contingency mode", and "c-mode".

The fact that those spacecraft had no need to maintain attitude to the Sun (RTG-powered) and had no articulation makes the problem a lot simpler, doesn't it? Given the complexities of having two separately articulated solar panels, need for battery charge management, an articulated HGA, being in a low orbit with no sun half the time, etc, MGS's safe mode design drivers were vastly more complicated. To think that the way out of these problems is to have a "simpler" safe mode is naive. MGS was lost via a long chain of unlikely errors, any subset of which would have left things OK. We just got unlucky. With 20-20 hindsight, the problems seem rather obvious, as such problems usually do.

You're both wrong. They did try the HGA, and it didn't help.

And just for fun, here's an actual reference (see page 46):
http://descanso.jpl.nasa.gov/DPSummary/Des...Galileo_new.pdf

If you read the NESC position paper (which is an odd mixtuire of human factors stuff and technical details of EDL) you find that

"Apparently, as a consequence of the initial
low-density encounter, parachute deployment time, triggered at a specified
dynamic pressure of 725 Pa, was later in time and at a lower altitude
(approximately 2-sigma) than expected. Although this reduced the time margins
to complete descent and landing to a low level, as measured by the parachute
deployment altitude, margin was regained because the parachute descended more
slowly than expected. The cause of this fortuitous “over-performance” of the
parachute was not understood."

Since MER didn't include temperature and pressure sensors, doing the EDL reconstruction is problematic. There are many unknown aspects of the system performance, and it's hard to tune the adjustable parameters given limited knowledge of the atmosphere. The Spirit EDL was 2-sigma off in one parameter and made up for that with unexpectedly good chute performance.

That said, I don't disagree with your assessment, but how close it really was is pretty hard to tell.
I think there would be some hard thinking were the MER system to be flown again.

I might argue that even in the best of circumstances the MER EDL system is only "seconds away from failure" -- the margins are pretty tight.

Many MER close calls were described in http://pweb.ae.gatech.edu/people/rbraun/cl...-ugly-truth.pdf
but the one that seems like it fits the bill is "dust storm 10 days before Spirit landing reduces atmospheric density" -- http://sirius.bu.edu/aeronomy/withersmericarus2006.pdf has a lot of technical detail about the atmosphere's state. There was a timing parameter that could be adjusted by ground command to factor in the atmospheric density, and this was commanded shortly before EDL (see http://www.nasa.gov/offices/oce/llis/1480.html and http://www.nasa.gov/pdf/160654main_Mars%20...onsultation.pdf ) That alone would make anyone nervous, although I don't know what the sensitivity of this parameter really was. If Rob Manning drops by this forum again, obviously he would have some insight.

The story in ROVING MARS about DIMES saving the day is certainly based on fact, though the DIMES team understandably would like to believe that their work was critical. I don't think we know for sure what would have happened without DIMES.

Again, I can't tell if the data have not been delivered to PDS or if they have been and the datasets are still stuck in the review process. In any event, DISR is a mostly-US experiment so blaming ESA for any lack of data release doesn't seem appropriate to me.

According to the page at http://pds-atmospheres.nmsu.edu/data_and_s...ns/Huygens.html
the data were delivered to PDS in July 2006 but PDS has not yet validated it. So it would seem that the delay may be due to PDS and not to the instrument teams or ESA.

Well, I wouldn't agree with your assessment of ESA, but that said,
NASA doesn't have a "general policy of immediate publication of even raw data". Some instrument teams have done this and some haven't, but no planetary mission team that I know of is under any contractual obligation to release data on any timescale other than the PDS archiving schedule; typically six months. My understanding is that researchers on non-planetary missions (e.g., HST) have even longer to release data.

Since Alice is a US-provided instrument, I'd have thought that if the PI (Alan Stern) wanted to release some data he could do so without ESA's involvement, but I don't know exactly how that relationship works. I would guess that the Alice team is subject to the same PDS data archiving timetable that instrument teams on a NASA mission would be.

I don't know what the obligation of ESA science teams to release data to ESA member states and their citizens is; as a US citizen, I can expect nothing at all from ESA.

It worked in orbit from March 2002 to October 2003; I wouldn't call that "briefly".

http://en.wikipedia.org/wiki/Mars_Radiatio...ment_Experiment

Looks like the MARIE website at JSC has gone dark.