Given the changes in coordinate systems since then (tens of km difference at least) I'd say that's a coincidence at best. What we call 158W today is quite different from what they called it in 1971.



It was more like the Pathfinder/MER landing system without the airbags IMHO.

I'm not sure what experience you're talking about. Previous Mars orbiters using aerobraking (e.g., MGS, MRO) have had articulated solar panels that could be shuttlecocked back for stability. MAVEN has fixed panels so this wasn't an option.

Cosine losses for these small angles are pretty negligible, of course (e.g., cos(10) is 0.98).

From http://lunar.colorado.edu/~jaburns/astr480...AVEN-ExSumm.pdf

It's unclear to me that pointing in such a direction would be safer from a dust deposition standpoint than pointing straight down. The MER navcams are somewhat contaminated by dust and it would be good to avoid this on MSL for as long as possible. I don't know how long into the MER mission images were being taken during conjunction, but given the memory anomaly on MSL, prudence at this point would seem to be indicated. My own personal opinion is that the science return from DD and cloud observations is not worth the potential issues of imaging during conjunction.

There's only one motor in MAHLI, the focus motor.

Working distance to motor count is described in the MAHLI paper, figure 13.

The last information I've seen on this was at http://www.nasa.gov/mission_pages/msl/news/msl20130325.html and it doesn't say what the root cause of the "memory glitch" was, or if there is any loss of memory capacity on the A side. I don't know the answers, either.

In fairness, there has been little detailed information about the problem from JPL, and most of the discussion here was, ah, speculative.
I wouldn't say that Robert's questions were actually answered.

One would have to take video since AFAIK there's no way to synchronize single frames with Chemcam shots, and I'm not sure you'd see anything worth the large data volume anyway; Chemcam emits at 1067 nm and Mastcam isn't very sensitive there, though the plasma cloud is more visible. Also, the Chemcam action happens on a very short timescale (shot rate is 3 Hz, each shot only lasts 5 ns), far faster than the limited video frame rate. See http://libs.lanl.gov/CHEMCAM_1_pg_web.pdf

If the target is shadowed then they help quite a bit during the day, but obviously it depends on how far the camera is from the target.

That would enormously simplify testing, though.

For our Venus proposals we spent a fair amount of time worrying about how we could even simulate the environment in any practical way. How do you put a scope probe on something that has to be at 450C to work?

Venus ambient is around 450C or almost 900F. There are no ICs I'm aware of that get anywhere close. Most mil-spec parts go to 150C or maybe 200C in a few cases (junction temps, not ambient.)

The cruise environment is fairly benign and once you get to Venus it's just hot all the time, there isn't a lot of diurnal variation. Exactly what the interconnect is made of is another question. That said, the SiC components are at a very early level of development so I'd say we are quite a ways away from having real and capable systems that would work at Venus ambient conditions.

RTG-powered refrigeration systems are feasible:
http://web.archive.org/web/20010106124800/...p/vgnp.txt.html

but for the foreseeable future I think short-lived landers are all we are likely to see, unfortunately.

You need to know, or assume, the emissivity of the surface in order to do that conversion. The brightness temperature is the temperature that a black body of the observed IR radiance would have.

I don't know for sure, but I suspect these are an artifact of something in the ground pipeline and don't reflect data coming from Mars at all.

Not as far as I know.

No, they weren't. During EDL they were saved in MARDI internal flash and not read out at all until after landing, and then only to the A side.

Saw it from San Diego last night. Not a naked-eye object for my aging eyes, but easy enough in binoculars.

Downlinking of the MARDI EDL images in lossless form had been going on for some time prior to the sol 200 problem. I don't think this is new data but I'm not sure what's going on.

Don't take every off-the-cuff remark as being gospel. There's plenty of controversy and multiple interpretations about the geomorphology. Speaking of which, isn't there a thread dedicated to these sorts of discussions?

I wouldn't expect gammas and cosmics to arrive at the same time, since gammas move at c and cosmics, however energetic, at <c.

Even assuming these flash errors are of the same type and cause, there are a lot of places for charged particles to come from. That said, I don't think your speculation can be entirely ruled out, but I question if there is much real science value to be had.

Where do you suppose this information would come from? Most mission personnel are not allowed to release any details to the public. Ken Herkenhoff's blog http://astrogeology.usgs.gov/news/category/astrogeology is the closest thing to a daily report you are likely to get. I'm sure they'll say something about it at next week's press conference.

The advances in flash have been in increasing density, using more sophisticated codes than Hamming codes, and moving the ECC controllers into hardware. None of those affect the basic architecture of flash usage very much.

I ran across this, which may or may not describe the testing of the flash on MSL: http://spinroot.com/gerard/pdf/cfv08.pdf

The process you're describing is correct for bad memory cells in SRAM and DRAM. Flash, since it's organized in a nulti-level page/block hierarchy and is inherently subject to bit errors even without radiation, is somewhat more involved. I'm not sure they've had bad flash blocks on MER. Normally, if your flash file system software is working correctly, bad blocks are automatically detected and replaced without service interruption, at least in theory.

Yes, all of the instruments can be run from either side equally well. And note that the flash that suffered the anomaly was rover flash, not Mastcam flash, which is unaffected. Unfortunately I don't know of a detailed public description of the MSL data architecture I could point you to.