Me too. MSL is the first mission we've done where the cameras ever needed to focus closer than infinity.

I don't think you did anything wrong. Either the numbers in the paper are confused, which would be kinda embarrassing since IIRC I computed them, or there is some distortion over the field which makes the full field wider than it would be if the IFOV at the center was constant. I'm hoping it's the latter but I'll check.

[edit] That's my story. The IFOV is computed from the effective focal length, which gets longer at increasing focus distance, but the FOV is computed from the field distortion of the optical model. The IFOV is really changing over the field and the quoted value is just at the center pixel.

Much as it pains me to mention this, you have to appreciate that those of us on the team are subject to rules about what we can and can't say. If you're high enough up the food chain (*cough*Rob*cough*) maybe you can get away with skirting those, but I sure can't I'm positive they'll report on the status at each day's morning press conference.

Press conference at 10 AM PDT (14 minutes from now.)

Don't sell yourself short, I think it looks pretty good.

Frame rates from the ecams are very low and there was a desire to not load the RCE up doing anything not critical to landing (MARDI was running autonomously and not sending anything to the rover during descent; recall our PHX experience?)

I had nothing to do with it, believe me. My design would have been a lot easier to deal with.

I think the big number after the MH is supposed to be a mission-unique image identifier, but there are some issues in how to generate these and it may still be a work in progress.

Looks like the engineering cameras will have a different convention from the science cameras unless this gets rationalized.

I'll take a guess from the first Navcams:

NRA_397586934EDR_T0010008AUT_04096M_.JPG

The NRA is Navcam Right A-side RCE. The 397586934 is the spacecraft clock value (0 = 1/1/2000 epoch of J2000 in seconds, ftp://naif.jpl.nasa.gov/pub/naif/MSL/kernels/sclk/msl.tsc). The EDR means Experiment Data Record, JPL-ese for pretty raw data. I'm not sure what the rest is, possibly the sequence ID and some image parameters?

I don't see any useful information in the JPEG labels so detailed analysis like pointing, sun angles, etc, would need some ancillary data as on MER.

The Mastcams are pointed toward the deck when the RSM is stowed, there's a protective lip on the deck all the way around the RSM instruments, and there are long sunshades in front of the lenses, so I think we're good. More dust than I was expecting, though, at least visually.

Wait for the press conference, I believe you'll find it interesting.

We're not sure. Something could come down in this pass (thumbnails) but it could get bumped by higher-priority EDL data. Might have to wait for tomorrow morning's passes.

Lead is too soft. Tungsten (or possibly a copper-tungsten alloy which is easier to machine) is much harder. Also, tungsten is denser, allowing volume savings.

http://www.e-tungsten.com/top_10_tungsten_reasons.html

I'm unaware of any planetary protection restrictions against lead or generally toxic materials. Consider the toxicity of Pu238...

I'd like to think I do too; among other things I wrote most of the flight software in the science cameras for MSL (Mastcam/MAHLI/MARDI.)

The quote was from an article in the Communications of the ACM, a leading computer science journal.

At any rate, all I was suggesting is that quantifying the likelihood of encountering a software bug is potentially meaningless. Obviously we have had many successful runs of the EDL sequence and all known bugs have been dealt with.

IMHO, such figures for complex systems that aren't tested a statistically-meaningful number of times are essentially meaningless. IIRC estimates of shuttle reliability before Challenger varied by several orders of magnitude; the 1:100 was just the one that turned out to be right.

Also, consider that many failures could be caused by bad software.

According to http://ntrs.larc.nasa.gov/search.jsp?R=201...ICAL%2BSCIENCES both the cruise and surface systems use CFC-11 (freon).

The fluid loop that's warmed by the RTG only goes inside the rover body; the actuators and other extremities have to be heated electrically.

The lift vector/bank angle is steered during entry in whatever direction is needed to hit the aim point. See http://trs-new.jpl.nasa.gov/dspace/bitstre...8/1/08-0255.pdf -- section 4.

Of course the IAU recognizes crater names on the Moon for the Apollo 1 astronauts. (And it's Chaffee, BTW.)

Those names don't appear in the IAU Gazetteer and AFAIK have no standing with the IAU.

Look, I'm not arguing with you guys, I agree that this was a confusing and seemingly ill-considered move. It would be interesting to get a statement from Brad Smith, the chair of the IAU Mars Task Group, about why they chose to do this now.

True. Maybe there's an interesting insider politics story here. Certainly the IAU didn't feel compelled to name the Columbia Hills out from under the MER team.

One can complain: "Any objections to these names based on significant, substantive problems must be forwarded in writing or email to the IAU Division III President within three months from the time the name was placed on the web site."

It's worth pointing out that unlike decisions like what defines a planet, nomenclature issues for planetary features are managed by a task group of planetary scientists: see http://planetarynames.wr.usgs.gov/Page/Approved

Still seems odd but as Phil points out naming a raised feature after a person just wasn't going to fit with the existing nomenclature convention.

Right. That's why I said "may" instead of "will".

In case anyone wants to play with the original data, here's a subsection of the first Earth/Moon image from Junocam in completely raw form. If you stretch it you can see some transform artifacts from the lossy compression we applied onboard. You may also see a little stray light from the sun on the right side of the image. Earth appears three times, once in the red, green, and blue bands (top to bottom). Earth is a bit saturated in the red and green bands; the exposure time was 3.2 msec, no TDI, and this is square-root companded.

If anyone can do a better job than the color composite we did, I'd be curious to see it. Because of the saturation, I think colorizing the blue channel would work better than a true composite, which tends to be a bit blurry.

First payload checkout is around L+20 days when the Earth is a "pale blue dot" ™ as far as Junocam is concerned.

I gave Emily an infodump about how Junocam works, expected image counts, when we image, etc, so you can look for that soon, I expect.

From the first post in this thread: "Fields including atmospheric science, solar physics, microgravity science, planetary science, space life science, space physics, and education and public outreach (EPO) stand to benefit from these vehicles."

And isn't this whole topic manned spaceflight, and hence banned by your own rules?