The MSL bus is set up so the chassis ground is nominally halfway between the voltages of the battery and RTG terminals.

http://www.planetary.org/blogs/emily-lakda...ion-update.html

A schematic of the propulsion system plumbing would be needed to completely make sense of this.

Normally, redundant latch valves are in parallel so that either one or the other can control flow to the engine (and there are normally-open pyro valves in the lines that can shut one leg down if its valve sticks open.) I haven't heard of needing or wanting both open since if they behaved differently they wouldn't be truly redundant (a crude form of throttling?). Perhaps in trying this there was some flow-splitting problem and the flow rates weren't what they wanted. At any rate it seems a bit odd -- hopefully this afternoon's burn will go well.

Certainly, and I referenced your post, but if you reread it, you'll see that it expressed some hope that more features might appear in parts of the image that hadn't been received at that time. I was hoping that somebody might revisit that (as it turned out I don't think we can see anything you didn't initially.)

On the topic of the nightside images, I'll note that there are a few interesting blobs in efb15 and probably efb16 and no one has ever looked at those in any detail, so there's a chance for a real amateur discovery here. Of course most of those blobs are stars.

I think the brightest, largest blob (which I think of as "turtle-shaped") is Cape Town; this seems to show up twice in the overlap region from two different angles. See http://www.flickr.com/photos/nasamarshall/...157625188331491 for an ISS image for comparison.

We were thinking that Johannesburg would be visible but perhaps it was cloudy; I don't think anyone has looked at this in detail since Doug's message back on 10/10 when we only had part of the image.

I didn't see any features on the Earth in the overlap that showed up in one portion but not in the other, as you would expect lightning to do, but I admit I didn't look that carefully.

Each line has all the pixels the CCD has, including black and isolation pixels, and 3 overscan/garbage pixels at the start and 5 at the end.

Capturing the entire optical function by using a single FOV and pixel count is overly simplistic because of lens distortion. Many posts back I provided a radial distortion term, which admittedly is derived only from the prescription but is the best metric we currently have. If the mismatch is due to optical distortion, then my model isn't doing much better than yours, though. It may be optimistic to expect that we will ever be able to get the color to line up perfectly without doing some sort of ad hoc correction, though it's always painful to admit this.

Most interplanetary spacecraft are launched into a parking orbit, but they only stay in it for a few minutes before injection. AFAIK there are no delta V savings for the MOM mission profile, it's mostly because the spacecraft engine doesn't have enough thrust to do the injection in one burn.

As for checkout, there's plenty of time to do it in cruise, and it's not like you can go up and fix it if you stay in Earth orbit anyway.

That looks great, and exactly how I would expect my processing of efb10 to look, right down to the color mismatch at the join point that I am still struggling with for efb12. Still no good explanation of that, but I'm working on it.

Which C kernels did you use?

I'm not following this point, but I gave the line offsets as best I understand them.

Slightly later, by about 0.082 seconds. I hadn't factored that in, maybe it will help.

If there's a better one I don't know about it either.

All these observations about the shortcomings of the official release (however accurate or otherwise) are, IMHO, violations of rule 2.6.

We wanted to make the need for the launch restraint dependent on the terrain type, but it's hard to quantify exactly what the vibration environment will be for any particular situation, and there are no measurements of it afterwards. As for "hitting some bumps" I'm not sure that's the right phrase, given how slowly the rover is moving. The worst vibe loads, we think, come from wheels spontaneously slipping off rocks, but I've never seen the details of the analysis.

These are really nice. If you could get rid of the remaining visible seam in efb12, I think these would become candidates for the "official" images. I haven't been able to completely get rid of the seam in my own processing thus far, even with the new SPK file and with adjusting the interframe time slightly.

It's unclear from the processing flow, but it's possible that that's essentially what he's proposing.

That said, estimating the position and pose of each MARDI frame would be a useful contribution all by itself.

This may be true for the engineering cameras, but it's not true of Mastcam or MARDI, where video can be acquired independent of the rover computer. However, the Mastcam focus mechanism is being put in the launch restraint position during driving out of concerns for vibration, so Mastcam can't be in focus during a drive (this could in theory be relaxed at some point because it's somewhat conservative). We've talked about taking MARDI drive movies but of course MARDI image quality isn't great. Of course, since the data volume is high and the science justification low, such imaging is hard to sell.

Are you sure? A quick look at http://pds-imaging.jpl.nasa.gov/data/msl/M...EX/RDR_CMDX.TAB shows 1280 EDL frames (all as "MrdiRecoveredProducts") though these are inconveniently scattered across releases 1-3 because of their transmission times (32 on 1, 864 on 2, and 384 on 3).

Per the documentation, the raw data are the digitized samples coming out of the camera and then passed through a 12-to-8-bit square-root table with no additional lossy compression. I'm not certain what you are concerned about in your images, but we've found that the two green pixels in the Bayer pattern have slightly different responses and this has to be accounted for for best color reconstruction. Bayer reconstruction is a very involved topic.

More or less, although the actual positions of the readout regions for each band is slightly different and to be honest I find that diagram a bit confusing. The actual start lines for each 128-line band framelet relative to line 0 at the "top" of the sensor are 291, 456, 611, and 766 with the nominal optic axis at line 600. And the focal length is 10.997mm.

http://www.msss.com/junocam_efb/images/efb12.tif is a raw TIFF file if that saves you any trouble.

Even in a terrestrial application, the guaranteed data retention time for NAND flash is only on the order of 10 years. It's likely that lower storage temperature will extend that, but flash is not a great choice for long-term data archiving.

I've put a preliminary version of the PDS-format EDR image for efb12 on the web site at http://www.msss.com/junocam_efb/images/JCE_jc029_C_012.IMG -- this was one of the few EFB images that was returned using lossless compression, so this version contains exactly the bits that came out of the camera without any compression artifacts. I doubt that would make any practical difference for most uses, but decide for yourself.

For those still keeping track, the remaining four partial Junocam data products have now been retransmitted and are posted to the web site, so our EFB dataset is complete.

No need to guess, see below for all of the timing parameters. The position and orientation can be computed from SPICE files.

It may be a little easier if you check again, as I just pushed a more complete version out to the website; a data drop was causing our processing to choke previously.

Jupiter actually appears twice in two adjacent framelets. The bright stuff at the bottom is not the actual Earth limb, which was out of the field, but stray light from the Earth. Also, don't read anything into the blown-up view of Jupiter; we are not able to see any satellites, that's likely pixel noise. Not a great image, but an interesting milestone nonetheless.


At Jupiter the spacecraft has an onboard ephemeris that tells us when we're pointed at the planet, and we can use that to center the images correctly. During EFB, that software was telling us where the Moon was, not the Earth. A few months ago, we also discovered a bug in how the Junocam flight software was using that information that still has to be fixed, so we weren't able to use it for EFB at all.

Here's a reprocessed version of efb12. Some explanation of the color mismatch that's visible near the center: recall that we didn't know the spin phase of the spacecraft when we planned the images, so we had to take a full 360-degree swath. As luck would have it, in efb12 the Earth was in the field at the start of acquisition, so the bottom half of the planet was at the top of the image and the top half at the bottom, with the overlap for some bands split between the top and the bottom. Since the spacecraft was moving fairly fast at this point, it traveled a significant distance in the 30 seconds between the time the first and last frames were taken, so there's some perspective shift. That should be modeled out by our processing, but we don't have the reconstructed SPK files from EFB yet, so our position knowledge is probably off. Hopefully quality will improve when we get that reconstruction, but there will likely always be a place for manual realignment of the color channels since our processing is not 100% perfect.

BTW, Gerald's processing is really nice (better than these automatic products by far IMHO) and greatly appreciated by the team. I can only imagine the amount of effort he's put in.

I was able to recover most of the efb12 image drops by tuning the decompression fault recovery parameters; improved versions posted to the web site.

Here's the first test of the fully map-projected and then reprojected version of efb12. Still some glitches, but not bad for a first attempt.