I think battery life is still a significant limiter on the mission lifetime. That's what ultimately killed VL2 and would have killed VL1 had it not been miscommanded first.

Also, there are many factors in RTG degradation, not just the Pu decay. See "DEGRA : a computer model for predicting long term thermoelectric generator performance" at
http://trs-new.jpl.nasa.gov/dspace/handle/2014/38760

Note that we are rehashing a thread nearly two years old.

The analysis is fine as far as it goes, but I assume that ETIs would have antennas much larger than 10m. See the references in post #4 for details.

You are mistaken. MSL will have a laser (ChemCAM) and it will have a drill, and neither of those would have fit on MER.

As noted by kwan3217, there is already a very nice service to look at collision probabilities: http://celestrak.com/SOCRATES

If you look at today's top 10, the highest probability is 2.785E-03 (1 in 359). This is certainly a lot higher than I would have expected. I wonder if Iridium was using this service, and if so how, and if they were concerned at all before the collision.

That is certainly the case now, and frankly, it wouldn't have been that big a deal for Iridium to have done this. The argument could be made that it shouldn't be up to them, but absolving satellite operators of any responsibility for collision avoidance also seems like the wrong way to go.

One has to keep in mind that satellite paths are not predictable for more than a couple of weeks under any circumstance due to non-gravitational effects like drag, light pressure, etc, especially for LEO orbits. That's why NORAD regularly updates their element sets.

Unless there's reason to think that Cosmos 2251 suddenly changed course or that the data in the NORAD sets was wrong, I'd place the blame for this totally on Iridium. If they weren't looking for collisions, it was basically a hope that they would stay lucky. With 90+ satellites in LEO, they were really in a position to pay more attention.

Wasn't the Cosmos stage in the published NORAD two-line element sets? I'd say that Iridium should have been looking at those.

EDIT: sure it was: COSMOS 2251, NORAD ID 22675.

Just because the ADC is 14 bits doesn't mean that any given image will use all 14 bits; there is headroom at the bright end and shadows aren't perfectly black because of atmospheric backscatter, etc.

I don't know how HiRISE works but CTX images can be taken at half spatial resolution in 12-bit mode as long as no compression is commanded. I don't think this has ever been used operationally, though (I used it in ground calibration, occasionally.) Since you are just encoding shot noise without square-root encoding, there is in theory no value to using the mode.

The main problem other than registration errors has been the various redefinitions of W0 and to a lesser extent, the IAU spheroid. See http://astrogeology.usgs.gov/Teams/Geomati...esy/P22D-06.pdf

Hopefully we are now past these problems, at least at the 100-meter scale.

http://naif.jpl.nasa.gov/naif/toolkit.html but you will have to write code to use it. There's no reason that Horizons isn't just as accurate as it's probably just using the SPICE kernels internally anyway. And the orbit is going to be different than any available kernel anyway, based on the launch date and injection errors, TCMs, etc.

See
http://www.unmannedspaceflight.com/index.p...st&p=131840 -- 4 km at 5000 km implies an IFOV of 800 urad/pxl.

Sorry, but since Junocam has a 70-degree FOV none of these approaches is going to be spectacular. (All this was discussed upthread.) If there happened to be one closer than, say, 50,000 km, it might be worth doing, but even that's 40 km/pixel, only a 2-3x better than HST can get.

Keep in mind that this would rely on a serendipitous and unplannable close approach to Io sometime early in the mission before Junocam (aka JunoCam or JunoCAM) has been toasted by Jovian radiation, and that I have no idea how constrained Junocam operations will be (not sure how many bits the s/c can send down per orbit and what competition will be like for those bits). That said, if there's a good encounter it'd be disappointing to not make use of it. But I just build them, they don't let me push the shutter button, at least not very often.

I'll try not to be offended by that. Junocam is as much a "real camera" as MARCI on MRO is.

The imaging would presumably happen near Io closest approach, which is not especially near perijove, since Io's orbit is about 70x higher than Juno's perijove altitude. If there's a good opportunity (and even if there is one for the baseline orbit there's no reason to think the real orbit will have one) I think there's a fairly high chance that it'll be used.

Covault's article says "The MSL rover's launch was recently delayed... but the slip could enable a new landing site selection related to the methane findings, says Michael Meyer, the lead Mars program scientist at NASA headquarters in Washington." I think we can safely assume that Covault didn't fabricate what Mayer said, but as you say, it's not much of a revelation. Given that the putative methane concentrations cover areas hundreds or thousands of km across, I'm not sure how anyone thinks MSL could land "near a vent" or what it could do if it did, but clearly there's lots of time to consider this.

FWIW, Covault has a slight taste for sensationalism; I think Mike Dornheim, who was killed in a car crash in 2006, did a better job of covering JPL for AW&ST.

MARCI and CTX do "companding" from the sampled 12-bit ADC values to 8 bits, typically using a square-root table inside the instrument. I think HiRISE does the same thing from its 14-bit samples. You could call this compression, I guess, though it is intended to be effectively lossless.

Yes. I doubt if ISIS can process a pushframe image in an efficient manner, especially one with framelets as small as MARCI's.

Zonealarm and Avast are not the same sorts of thing: Zonealarm is an intrusion detection system that can see unauthorized traffic outbound from your machine; Avast is an antivirus program that as far as I know doesn't look at network traffic at all (at least the free version doesn't.) The two can be complementary.

Nope, no microphone on the MSL MARDI. You should note that while it shares a name with the instrument on PHX, it's a completely different electronic design and doesn't use the cellphone processor that made adding a microphone to the PHX design fairly straightforward.

As I said earlier in this thread, the Mastcam lens is many inches inside its sunshade and could not be reached by any plausible brush.

As to the navcams imaging during EDL: of course Doug is right, the navcams and Mastcam are pointed down towards the deck when the RSM is stowed. I guess the hazcams are looking at the ground during descent but the hazcam frame rate is quite slow (remember DIMES from MER) so only a few images could be taken, whereas MARDI will be running at about 4 FPS.

"Green Mars" (the novella, not the second book of the Mars trilogy) by Kim Stanley Robinson, collected in THE MARTIANS.

"The intense concentration of self in the middle of such a heartless immensity, my God! who can tell it?"

MER needed DIMES because of the late realization that transverse velocity, which couldn't be measured by the simple radar altimeter on MER, could cause problems for the airbags. All the other landers have had or will have more capable radars that can directly sense transverse velocity (since obviously a powered soft lander has to zero out transverse velocity.)

Yes, we have been discussing using MARDI post-landing, but I would think that the MSL navcams and hazcams would be just as capable of detecting slippage.

Here's the Casani report for people who feel like reading it. Note section 6.2.2 in particular.

http://www.bnsc.gov.uk/5278.aspx

Did you read my last post? You guys are way too eager to jump to conclusions without much knowledge of the engineering realities involved. I haven't seen a detailed analysis of the Beagle aeroshell design, but certainly the independent JPL review said nothing about this, so if it was an error, it was a subtle one, not a stupid and obvious one.

I believe it's a lot more involved than that, since we are talking about fluid dynamic regimes where gas properties are far from ideal, etc, etc. Designing these things is still a black art (literally; I think many aspects of RV design are still classified.)

That said, the Beagle entry design was done by engineers at EADS, and one presumes they had some basis to think it would work. It's not as if they picked the Huygens shape with no justification. My limited understanding is that the RV shape is at least partly a matter of tradition and heritage, not strongly engineering-driven.