I grow tired of MCO being used as the poster child for the evils of imperial units. The unit conversion problem was merely the root cause in a long chain of mistakes and missteps, technical and organizational, which could and should have been caught and fixed.

In some cases the image is only partially received on the ground the first time around and retransmissions have to be commanded. That can slow things up, sometimes considerably. Also, images can be prioritized low and get stuck behind higher-priority data. I seem to recall images showing up weeks or even months after acquisition on MER. So the lag is pretty meaningless.

You don't get the subseconds in the filename, so you will be off by a second minus a tick worst-case.

My guess is that this is not ET but SCLK, which drifts from ET. You need to use scs2e (or sct2e) to get this into ET.

For Navcam the file name has the SCLK value for the image time, I think. For MMM it appears there is no SCLK in the filename and metadata would be needed to figure out the time. I'm not sure what the time on the raw image website means, I haven't tried to correlate it.

The NAIF website (http://naif.jpl.nasa.gov/naif/data_mars.html) has some information about how to map SCLK to UT and LMST and may be a source for pointing data (I'm not sure what the CK files there look like or what their plan is to update it.)

I'm not sure exactly what happened on MER or what the gear ratio is in the MSL drive train (for the teeny brushless motors in the cameras back-driving them is indeed very hard) but since MER had a commutator issue and brushless motors don't have commutators or brushes, we shouldn't need to worry about that. I'm not sure, but I assume that MSL has redundant windings also.

Now that the daily press conferences are over I'm not sure what the plan is for discussing the activity timeline. Alas, I'm not authorized to share the details. On the general topic of doing more imaging, you can rest assured that the team is just as interested (for example, I'd love to see some 100mm imaging!) and we'll be doing it as soon as we can subject to all the constraints.

I'm on the camera team and I'll complain about it if I want to, thanks.

That said, this is kind of an interesting article.
http://www.informationweek.com/government/...web-s/240005286

That's not a useful response IMHO. The camera thumbnails are lovingly antialiased onboard to be as good as they can be at their minimal size, so just tossing them seems really lazy, and it's contributing to make the pages load really slowly even if you have a fast connection.

As for metadata, if I recall correctly this was provided in a separate file for MER. There are no technical barriers to doing the same thing for MSL...

Let me emphasize, just my own opinion and not an official position, etc.

That sounds like a useful bug report, but I have no idea who's in charge of the website. I'll ask around. Maybe Doug knows?

MER used brushed actuators, while MSL uses brushless, so the lifetimes should be much longer.

I did the same thing.

Seen from the RSM the chips are under the UHF antenna just above a JPL logo. This frame was partial in the first Navcam pan but it will show up eventually. See ground image at http://mars.jpl.nasa.gov/msl/images/COPY_M..._on_deck-br.jpg

I couldn't find one, unfortunately. If you didn't save the initial certificate there doesn't seem to be a record of it.

On the chute the spacecraft (and the camera) wasn't pointing down, it was pointing more or less in the anti-sun direction. It only goes vertical later in the descent.

The MARDI FOV is 71x53 degrees.

That's the zero phase spot (point on the ground on a line between the camera and the sun) on the ground. See also "opposition effect". [ugordon beat me to it.]

I don't know precisely what he did and "brightened" covers a lot of ground. I see a perceptual color change even if I just do a level adjustment. At any rate, the raw data speak for themselves; I'm pretty happy with the straight-out-of-the-camera image quality.

google for "interline image sensor smear". Only likely to be an issue for very short exposure times.

That's really nice. Maybe we should just skip sending back the full-res Mastcam frames.

BTW, note the better contrast on the fiducials and the Curiosity logo in Navcam compared to Mastcam. Definitely a thin haze of dust over everything.

See ftp://naif.jpl.nasa.gov/pub/naif/MSL/kern...gc120806_v3.tsc

Before, you can clearly see it in the sol 1 pre-RSM-deploy Mastcam thumbnails.

I certainly wasn't expecting it.

About the only thing that the MSL MARDI has in common with the MPL/PHX MARDI is the name.

The MSL MARDI has a bandpass filter (minus blue/IR cut) as a coating on one of the optical elements. The sensor has microlenses and the bayer pattern color filter array, but since any contamination is sitting right on top of those (only a few microns above the photosites, I would guess) the f/cone really doesn't matter very much.

If it's not crud on the sensor, then by an amazing coincidence it's at exactly the same pixel coordinates as a feature I can see in the pre-delivery flat fields taken back in 2008.

And yes, pieces of debris on the sensor are this well-defined.

I'm in San Diego. I have a low tolerance for meetings and this way if there's a problem I'm better positioned to do troubleshooting on engineering model hardware.

I'm not sure what you're reacting to -- the full frames seem fine to me and I can't tell anything from the thumbnails. I was surprised the full was as clean as it was. I'd suspend judgment until the fulls of the deck come down.

I'm pretty sure that's a piece of crud on the sensor; I see one in the ground flats at about col 614 row 428.

In all fairness, there's only so much you can do with the thumbnails, the real magic will start when all of the full frames are back.