Normally you don't use linear regulation from battery voltage, because most of the power is used in the regulator. 40 mA at 5V is only 200 mW (which is still a lot for a simple clock -- for example, a Chronodot RTC http://docs.macetech.com/doku.php/chronodot_v2.0 -- admittedly not rad-hard -- uses 840 nanoamps in standby timekeeping!). But it's not impossible that in this case they did use linear regulation because it's simpler and losing all solar power wasn't really a credible fault for the short mission design life.

At any rate, if the clock is lost, we may see a lot of X-band "sweep & beep" commanding once there's any expectation that the rover is getting enough power during the day to communicate. On Spirit they started this about 4 months after the loss of comm. See https://mars.nasa.gov/mer/mission/status_spiritAll_2010.html for some descriptions of this.

I don't see how, that heater is turned off when the battery controller is turned off, that being the whole point of deep sleep.

As a data point, I have solar panels on my house. On a typical day in March they generate about 30 kW-h. During the cloudiest, lowest-production day this March, I got about 3 kW-h, about 10x worse.

700/22 is 32x less production, so this would be a really cloudy day, at least by SoCal standards. (Solar distance is already scaled out so don't complain about that.)

During conjunction the rover has still been powered, of course. The most worrisome thing about this is whether there's some issue associated with losing the mission clock (go back through all the Spirit status reports after loss of comm for lots of discussion about various permutations there). We can assume that Spirit just got too cold, but there's no proof of that I'm aware of. And then there's the possibility that the panels will be so dusty after the storm clears that they won't produce a useful amount of power (although I think that's probably unlikely.)

https://trs.jpl.nasa.gov/handle/2014/43244 "The effects of clock drift on the Mars Exploration Rovers" is an interesting paper about the MER clock architecture. It didn't really have anything germane to the issue of losing time reference but it has a lot of detail about how the mission clock works.

John Callas said "If rover is generating less than 22Wh, then it won't have enough power to maintain clock". I'm not sure how to parse this. AFAIK, the mission clock is powered directly from the batteries during sleep and will presumably drain them down to some minimum voltage cutoff. 22Wh per sol would be a little under 1 watt of power, which is a heck of a high power draw for a simple clock.

At any rate, I think it's safe to assume that over the next few days there will be essentially no power generated.

The good news from the press conference is that the low-power fault state is basically the same thing as deep sleep, which they use all the time.

I don't know two things: first, how long it has until it loses its mission clock, which complicates the situation, and second, how the stuck-on IDD heater that deep sleep was added to get around will affect the recovery -- since that's a 0.5A load that will start as soon as the battery controller comes up.

Mods: are we going to discuss the dust storm and its aftermath in this thread or in the dust storm thread?

Bummer. Per https://trs.jpl.nasa.gov/handle/2014/37750 (assuming there are no changes to the fault response), if it gets enough power to boot back up, comm is limited to one LGA DTE per day at 11 LST, unless the ops team can get commands in to alter this behavior and enable UHF comm. I'm sure this will all be described tomorrow.

I don't know. I happened to notice a DSN track on DSN Now this morning but nothing was received while I was watching.

I'm not sure that the specific failure mode that got Spirit has ever really been identified. The presumption was that it was related to cold, but it would surprise me a little if there was anything about MER that could be rendered non-functional by a few deep thermal cycles. (Well, maybe the batteries, but the system would still work in the daytime.)

Hopefully there isn't some inherent flaw in the low power fault state, or better yet, that it never gets entered.

Has Opportunity ever been in a low-power fault state? I'm thinking not.

As far as I know, Spirit went into this state on sol 2210 and never came out, although this is supposed to be recoverable.

Read the paper, it's online. http://science.sciencemag.org/content/360/6393/1093.full

It's not grasping at straws, it's good science. "Extraordinary claims require extraordinary evidence."

The paper has some discussion of alternative explanations, including contamination.

The Junocam I kernel parameters were fit using stars from the cruise imaging and validated using the positions of the galilean satellites during PJ1.

How Gerald's processing works with regard to camera parameters has never been clear to me.

I am personally of the opinion that expecting deep sub-pixel registration between bands is a pipe dream, but obviously I could be wrong.

The code doesn't use this value, I didn't put it in the kernel, and I don't know what it's supposed to mean. You could very well be right technically (since for brevity I folded the typical height/2 offset into the constants themselves as Gerald points out.)

In a perfect world, these keywords would have well-defined and documented meanings, and the SPICE toolkit would have functions that used them and performed the basic camera geometry functions. As it is, the toolkit doesn't have those functions and the keywords don't have well-defined meanings, leaving us to do the best we can in the comments.

The comments were written after a big effort to determine the best possible fit from in-flight data and in the face of massive confusion from practically everyone who had ever written code to deal with pushframe systems about how to manage Junocam data. So my attitude was very much "do this specific thing" instead of "here's a whole bunch of information that will allow you to make your own design choices and mistakes and then come back to me and complain about it."

The 814.21 is the pixel coordinate given the 1648-wide image, so any issues about dummy pixels have already been accounted for.

I've got no idea what USGS is doing with the 600. The optic axis isn't at a Y of 600 any more than it's at an X of 1648/2.

I wrote the code in the kernel file so there would be no ambiguity about what needed to be done with managing the framelets. This code has been validated with limb fitting in one direction and ray tracing in the other so I'm pretty confident it's right to a pixel or two. If you want to use a different formalism, that's fine, but don't expect me to debug it -- I had enough trouble with my recommended method.

I'm not 100% sure what you mean by this. If you use the recipe I describe then you can just use the tabulated DISTORTION_Y values in the kernel and they account for both the readout offsets and the optic axis in one step. If you don't follow my recipe, then you're on your own for figuring out how those are combined: which is more work, no advantage I can see, and more potential error sources.

I suggested that that diagram be removed completely as I found it more confusing than helpful; I'm actually not sure if it's wrong or just incomplete. At any rate, you're supposed to be using the values in INS-6150*_DISTORTION_Y. I tried to be as clear and specific as I could be in the comments and pseudocode in the "optical distortion" section. I can't immediately map what I said there to numbers like 441.52; since we don't read out, much less transmit, the entire frame, I don't spend a lot of time thinking about what the coordinates of the entire frame are any more.

I hope that helped. Sorry for any confusion. If you find some ambiguity in the "optical distortion" section that you would like resolved, let me know.

There's no active hazard avoidance that I'm aware of. There's TRN but that still requires a priori knowledge of hazards from pre-existing orbital imagery. See https://marsnext.jpl.nasa.gov/workshops/201...straints_v6.pdf

I'm curious to know how the two different processing methods affect your workflow. Your original Brian Swift pipeline version looks about the same as this to my eye, the only difference I see are some uncorrected CCD blemishes (and some global brightness variation, this one is brighter near the terminator.)

Note that because the spacecraft antenna was pointed at the Earth during this pass, we are looking way off nadir in these images, which make them deviate from round significantly in non-map-projected form (and look like cashews in the point-perspective form that we use in our processed products.) It would be interesting to know if there's a way to fix this cosmetically without doing a real map projection.

The first batch of PJ13 images have been posted to missionjuno.

http://www.planetary.org/blogs/guest-blogs...paign-kuhn.html but that was down near the ground or away from the inlets. I don't think we can see the inlets during sample delivery anyway because the view is blocked.

No freakin' way.