It's taking a long time for the DSN to downlink everything and there are some partial images stuck in the pipeline.

I'm not much of an ISIS3 expert but map2cam shouldn't be able to introduce errors, so I suspect that something is bad in the processing before that. Are you using the most recent beta version from June? I don't think it's visible from the public site but if you're serious about trying it, PM me and I'll send you the instructions.

I guess, although I think the impact hypothesis is so unlikely as to not be worth any particular action (but perhaps that is excessively conservative of me.) However, not providing location information makes any context search difficult (unless it's very, very obvious.)

The two flashes in pj14-002 were at about 60N 220 and 38N 210 and the flash in pj14-003 was at about 60N 280.

Note that these were lightning search images in two different colors. The most likely explanation IMHO is that they are, in fact, lightning, but the team is working through various alternatives.

The fact that they look like point sources without any charge bleed or smear despite the high level of TDI suggests to me that their duration was no more than a few tens of milliseconds (total exposure time was about 200 milliseconds).

On what basis do you say this?

According to http://cab.inta-csic.es/rems/wp-content/up...RATION_PLAN.pdf the pressure sensor is only required to be accurate to 10 Pa at beginning of life and 20 Pa at end of life (end of the primary mission, I presume.) It may be doing better than that, but I'd be reluctant to draw any conclusions from absolute pressure measurements over long time scales without taking possible instrument drift into account.

If vout was the same variable as v1 or v2. All it's saying is that this is OK.

Adding two vectors shouldn't really be confusing.

I'm going to blame either Deimos or bad typesetting at Science for this -- in http://science.sciencemag.org/content/306/5702/1753 the abstract says "The dust's cross section weighted mean radius was 1.47 ± 0.21 micrometers (mm) at Gusev and 1.52 ± 0.18 mm at Meridiani." "mm" is, as far as I know, not a valid SI abbreviation for micrometer, which is mu-m. https://en.wikipedia.org/wiki/Micrometre

Pedantic much? They're at about the same longitude and who cares what time it is at Gusev? [Well, in fairness, they're not that close -- Mars24J says there's about 2 hours different between Gale and Gusev. If it's right.]

Maybe overkill, but I use https://www.giss.nasa.gov/tools/mars24/ -- right now it says it's 11:24 at Meridiani and 01:14 at Gale, which sounds about right.

On Mars, 0.15*38 = 5.7 pascals, I believe, unless you tried to compensate for this in your gram number (improperly, since a gram is a unit of mass, not weight.)

The article you linked cites https://www.sciencedirect.com/science/artic...2855?via%3Dihub which is behind a paywall, although I guess I could walk upstairs and get a copy from the author I think unit confusion is likely.

Of course. Without finding the raw data I can only show what the team chose to plot. My only point in posting this was to indicate that the pressure was being measured and eventually we would be able to see those measurements (see http://pds-atmospheres.nmsu.edu/data_and_s.../Mars/Mars.html although if this page is right the REMS team is way behind on releasing data.)

Going back to the Viking 1 data would be the best way to look at the pressure through a dust storm as of today, probably.

I don't think there's really an appreciable pressure signature from dust storms, but this has been measured. Note that some of the graphs below are more about diurnal variation in pressure and less about absolute pressure.

https://www-k12.atmos.washington.edu/k12/re...ion/overlay.gif

https://mars.nasa.gov/resources/4902/atmosp...ing-dust-storm/

Since I expect these are all autoexposed, you can't really compare them to anything sensibly. The best way to show this would be to show a series of images all taken with the same exposure time, or at least normalized to a single exposure time.

Also, the color processing between the two cameras is significantly different.

The filters are basically the same (440 nm and 880 nm centers, ND5 neutral density) but obviously the cameras are quite different in their pixel size, f/number, and quantum efficiency.

But without knowing the exposure times of the images (alas, not available until PDS archiving AFAIK) it's tough to figure out the radiometry.

You'll have to explain what you meant by this. I don't know exactly how DSN Now works as far as MSPA is concerned. When DSN is looking for a signal from a drifting frequency reference (which may be the case here), I think they often record in wideband and don't even try to lock up in real time, and I suspect this doesn't show up on DSN Now as a downlink (Doug would know for sure.)

However, if DSN Now says the uplink is to a specific spacecraft, I'm pretty sure it really is to that spacecraft.

Really? There's never any attempt to send anything on the X-band LGA autonomously? The fault protection paper implies that there is:



I read that as meaning that it's in receive mode as long as it's powered up and that it tries to send at 11 LST even if it hasn't heard anything. But I may be misinterpreting what "schedules a communication window" means.

In my experience it would be unusual to never transmit autonomously, since that would mean that if there was a receiver failure, you'd never hear anything even if the transmitter was healthy.

It's about 11:30 LST at Opportunity as I post this, and I see that DSN Now says they are uplinking to MER1 from Canberra. I wonder what they're trying to do? I thought they were in listen-only mode.

http://www.planetary.org/explore/space-top...mer-update.html has some discussion with John Callas about the consequences of the mission clock fault on Spirit.

It might be interesting if someone from TPS sat down with him to discuss the recovery of Opportunity in light of that experience. (Edit: I note that there's a little bit of that in http://www.planetary.org/explore/space-top...torm-sleep.html linked upthread.)

By "dust on the lens" do you mean the crud that's been on the surface of the MAHLI sensor since we assembled it, or something else?

I don't know of any evidence that suggests there is any dust on the MAHLI lens, but if you have any I'd like to know about it.

While the flash is not available, the rover also has 11MB of EEPROM thst could be used to store state information. I think, for example, that this is where Earth position as a function of SCLK is kept. Without time reference, no HGA comm will work until this can be updated.

The worst previous was back in 2007: "Due to extensive dust storms in Mars' southern hemisphere causing record atmospheric opacity levels, Opportunity is currently experiencing its lowest power levels to date. The tau measurement as of sol 1225 is 4.12, resulting in a mere 280 watt-hours of array energy. A tau measurement of 5.0 would result in approximately 150 watt-hours."

https://mars.nasa.gov/mer/mission/status_op...07.html#sol1382

Keep in mind that we have two competing measurements, the tau determined by analysis from Pancam images, and the actual solar production. From an engineering perspective, only the second one is of direct interest. I'm sure they have a model to go from the first to the second, but once you have an actual number for the second you should use it. And of course for any model, you not only have to know the irradiance but also how much dust is on the panels.

Perhaps, but this kind of elaborate solution that requires state to be recorded and used from sol to sol is usually not used in deep fault responses, because it's really hard to test all the possible permutations.

I expressed the same concern back in post #51, yes.

As noted before, if it was that easy, then how do you explain the need for the "sweep&beep" campaign done for months with Spirit?

No, and it was a bit of an off-the-cuff answer, but barring some additional information from the project it's all we have to go on, and it's not implausible given what details of the design we do know. For example, some types of Q-Tech oscillators really do draw 40 mA just for the oscillator, and then for a complete clock there has to be a counter and maybe some other stuff -- the fault protection paper references a "mission clock FPGA".

I also don't fully understand how the scheduling of transmission and reception periods happens if the mission clock is lost. This seemed to introduce a lot of complexity into the attempted recovery process for Spirit. Presumably without the mission clock there's no way for the rover to figure when 11 LST is (in theory it could do with from solar power production but that would vary a lot based on tau, tilt, dust on the panels, etc.); AFAIK this scenario isn't described in the fault protection paper.