So sorry if reality bores you.

The VMC image is mostly striking because Arsia Mons is so close to the terminator and the cloud shadow is long.

The clock has almost certainly faulted, and even if it hasn't, I don't think one can presume anything close to the level of accuracy that you're suggesting.

The fact that there is no public source that says how long a particular signal is in carrier lock makes it impossible to tell a short transient from a longer, more plausible actual contact.

As far as I know the automated DSN twitter account is basically getting the same information as DSN Now. Many of us have said over and over again that this is not a reliable source of information with regard to the Opportunity recovery, and you can appreciate that there might be a certain amount of frustration when these caveats are ignored.

I've tried to figure out what an unambiguous detection might look like on DSN Now, but the initial contacts will likely just be beeps (carrier only) and with just this, my criterion of actually seeing data flowing at 10 bits/sec will never be met. Read https://descanso.jpl.nasa.gov/DPSummary/MER...cmp20051028.pdf 5.1.6 X-Band Carrier-Only Beeps for more information. It may be that once the recovery is well underway, DSN Now will be a viable way of seeing how it's progressing, but not initially.

The bottom line is that an official announcement is the only reliable way to know if something has been detected. AFAIK, team members are not supposed to be unofficially posting status information on social media. I don't think the team will sit on the news for any length of time, but it has to be coordinated with JPL PIO so I wouldn't expect it to happen over a weekend.

This has been discussed several times in this thread, look for "UHF".

The bottom line is that in this particular fault it doesn't help very much.

Sigh. I think a more likely explanation is that this was an uplink to some other spacecraft, and DSN Now got confused.

I suppose it's possible that there could be a switch fault that would preclude connecting the LGA to the SDST, but then I wouldn't expect them to use the highest-possible uplink rate to command, even if the HGA happened to be pointed at the Earth.

Yep. I just use a small subset of the BSC and loop as follows (note, no aberration correction):

From https://descanso.jpl.nasa.gov/DPSummary/MER...cmp20051028.pdf

So it seems very unlikely that they are sending 2K to the LGA. I don't know what they're doing. It's possible that DSN Now gets confused about uplink in MSPA or something, I suppose.

I don't think that follows, as the color and reflectivity of the rover is obviously different than the surroundings regardless of the dust loading.

https://www.uahirise.org/ESP_056955_1775 says

Clouds around the Tharsis volcanoes have been observed since before spaceflight. The classical name of Olympus Mons, Nix Olympica or "The Snows of Olympus", refers to such clouds.

There's only one X-band transmitter (though there are redundant solid-state power amplifiers) that can be switched between the LGA and the HGA. The HGA can't be pointed at the Earth in a clock fault because the rover doesn't know what time it is and therefore where the Earth is. So the HGA path is useless for recovery unless the clock can be updated. See https://descanso.jpl.nasa.gov/DPSummary/MER...cmp20051028.pdf Figure 3-1 on page 17.

In theory both transmit and receive could happen via the UHF. With a clock fault, though, the exact time of UHF comm windows is moving around in a hard-to-predict manner and it's unlikely that an orbiter pass will happen to coincide with one of these windows, though I expect this is being tried.

Not very similar (RAD750 compared to RAD6000) and the flash is not on the processor board anyway.

If there was a flash issue, on MSL this would be handled by switching to the redundant computer.

I had assumed you were doing that in ISIS3 as well but it probably can't do an off-center point perspective view (my software can't either.)

Thanks for sending the code, that was very helpful!

If it wouldn't be too much trouble, if you could put together an example of what steps you followed to create this image, it might help the ISIS3 group debug the problem. This seems like too big a glitch to be attributable just to our camera model being a little off.

If you have OpenCV2 and Python the following fragment will interpolate a Bayer JPEG:

If you see a "receiving data at 10 bps", then that might be a real signal. (They've transmitted from the LGA at higher rates but I don't think that the fault modes will ever try this.) My advice is to ignore all carrier lock messages.

There's a good chance that the first signals will only be seen in radio science recordings, which won't show up in the realtime DSN status anyway.

The bit rate would be very low for starters (<10 bps IIRC). If you don't see "receiving data" then I would assume it's a false alarm.

If a real signal is seen I don't think the team will keep it a secret.

Small rocket motors can be tested in vacuum chambers. https://www.nasa.gov/image-feature/firing-u...et-engine-tests Larger ones for which this would be impractical are usually tested with a modified nozzle or some kind of diffuser to try to simulate the effects of lower pressure under ambient conditions.

I don't know of any test that tries to simulate the ascent pressure profile, but I don't think that's critically important going from 6 mbar to vacuum.

You can learn a lot from a sea-level static test, especially for a simple solid or hybrid motor like those being considered. Whether that's sufficient testing, especially in a very risk-adverse situation, is debatable.

I'm not saying it was equivalent, but it's not like a system like the MSL sky crane was ever tested in flight before it got to Mars.

No, there are still several more to come.

[edit: as of 14:36 PDT all of PJ15 should be on missionjuno.]

Seems to me that neither the NAS folks nor MEPAG ask good technical/engineering questions very often. IMHO, they seem surprisingly credulous of the engineers who are basically trying to sell them something.

As to your comments: this is essentially a series of cartoons, not a technical document. I think your questions are well-founded in most cases. The operating temperature of -20C is not unreasonable (-100C would have been, maybe -20C was a typo) and probably not terribly driving if the AFTs on page 3 are to be believed. I share your skepticism about whether the case has been made for the hybrid.

Maybe a lot of people don't realize that because it's never been written down anywhere publicly before now, at least as far as I know.

Brian, the large image you put inline makes this page load very slowly.

Being "in lock" is only a very early step in the whole decoding process that ends with digital packet data being produced. If a signal makes it all the way to the end, it has a unique spacecraft ID in it AFAIK, and shouldn't be confusable with anything else; even without the unique ID it's hard to confuse one spacecraft's packets with another's.

In listen-only mode, signals are recorded in wideband, not decoded in real time, and can be combed through later in much more detail than real time will permit. So if there's a signal in there, it will be found.

I think that would be way off nadir, since from the MRO orbit the limb is only about 27 degrees of longitude from nadir. But I haven't studied the geometry carefully, and if there was an observed glint from Spirit there must be some way to make it work, though I don't remember what Spirit's tilt was.

However, I still argue that it's not diagnostic at all anyway.

I think that's not possible given the orbital geometry; given the low tilt the imaging would have to happen around local noon, and MRO is in a roughly 3 PM orbit.