Yep. Considering that some reports suggest that MSR has severe cost difficulties already, expecting some full-up flight test which would have limited fidelity anyway is simply not in the cards.

Presumably the MAV subs (NGC and Lockheed Martin) have access to many decades of experience on solid rocket propulsion and control from military programs.

All images have been pushed to missionjuno. Enjoy.

https://astrogeology.usgs.gov/search/map/Ma...ily-Global-Maps are MARCI global maps for the first two Mars years of MRO.

The raw MARCI images are in PDS but I'll admit processing them is probably painful. I got out of that game after MGS.

As far as I can tell from https://naif.jpl.nasa.gov/pub/naif/toolkit_...s/C/req/ck.html no SCLK file result is embedded into a C kernel file, so there is no implicit dependency (though I'm not sure the source for the code that makes C kernels is available anywhere). A newer SCLK file should always just cover a larger range of time than an older one, not be inconsistent in the overlap time range (though I can't say if this has always been true, it would be easy enough to check.) If you use an SCLK value that's later than the end time of a given kernel, you get an extrapolation, which will almost certainly be less accurate than using a newer kernel.

Kernel 123 was produced months before kernel 127, so there's no reason to think it would be better for times around the end time of 127, unless these files are screwed up in some way.

I'd recommend asking NAIF if you can identify a very specific problem, in my experience they are extremely responsive. FWIW, when we did the timing corrections for PJ40, the largest error was 9 pixels (image 46). We did that on 7 April 2022 and used the latest SCLK available at that time, which I'm assuming would have been 129.

Could you produce a simple example of this where you show a large angular difference at the the same time for the same kernel files, with the only difference being the SCLKSCET kernel? Say, something like m2 = pxform("j2000", "juno_spacecraft", t); v = mxv(m2, (1,0,0))

As I understand it, CK files are essentially keyed by SCLK, so you need a valid SCLKSCET to use them (not a very out-of-date one, for example) but SCLKSCET files should be fairly continuous so using a newer one shouldn't make a big difference (barring big jumps in the spacecraft clock.)

Are you by any chance using the "high-precision" format clock? If you are, see if the results are different if you don't -- it's not useful for Junocam and seems to have had some issues over the course of the mission, though I'm not sure if it's used internally in CKs or not.

What Bjorn is describing seems to be associated with orientation, not position. And there have only been two passes close enough to significantly change the trajectory anyway.

You need an STL file. A google search of "comet 67p stl file" turned up several options. There may be one on the ESA website somewhere but I got lost in a maze of links leading from https://open.esa.int/rosetta-3d-model/

Great post on the RTGs, Tom! Looking forward to seeing them integrated into the overall model. I've never been sure of exactly where they were, as they are underneath a cover and not shown well in most extent drawings and photos.

It's a little surprising to me that having the RTGs "inside" was the configuration they chose (with a "thermal switch"* to control the conduction between the RTG and the equipment plate). MSL and M2020, of course, have their RTGs outside with a fluid loop to bring in the heat. Seems like it would get pretty hot under the RTG cover.

* https://ntrs.nasa.gov/api/citations/1981000...19810001592.pdf page 34.

It has two circular solar arrays (presumably ATK Ultraflex arrays like Lucy's) but according to https://www.thenationalnews.com/uae/2023/05...-asteroid-belt/ it will use solar-electric propulsion. Lucy uses a chemical biprop engine. I don't know if the supplier of the spacecraft has been selected yet.

I think there's more info in https://spaceref.com/science-and-exploratio...s-bold-mission/
and https://www.nytimes.com/2023/05/29/science/...id-mission.html (paywalled, sorry.)

I haven't read the article but this is more or less what the review board report said -- https://www.nasa.gov/sites/default/files/at...se_nov_2022.pdf

Not to be cynical, but I refer to you to https://en.wikipedia.org/wiki/The_Mythical_Man-Month

With all due respect to AMSAT, I'm not seeing any error bars on their analysis, I'm not sure where they got the orbit data, I don't know what coordinate system they're using, there are some assumptions made, etc, so I wouldn't have assigned very high confidence to their result in the first place.

They do say their result assumes a vertical pitch angle and note "The landing could also have been in Atlas crater but at a pitch angle of -86.7° rather than -90° which is vertical down."

Nice video, Jason. Sorry to disappoint, but Junocam is only taking 10 images of Io this time, from about 02:30 to 03:45. They are all lossless.

There is no adjustability of gains or CCD voltage in Junocam. About the only thing that can be controlled, to some degree, is the camera head temperature. From the Junocam paper:

I don't think it's necessary to call me out by name. Others may have answers and it just makes me feel bad if I can't respond.

As Stargaze has correctly intuited, these are temperature-related and intentional. I can't say more, but one might search for phrases like "radiation damage" and "room-temperature annealing". Once the PDS volume has been released, it should be fairly obvious what's going on.

The Jupiter community loves their acronyms and rarely bothers to explain them any more. N4 ("northern northern northern northern") https://britastro.org/section_information_/...3-to-n6-domains is the middle part of latitudes 43 to 64ºN. SEBn is "a superfast prograde jet at 7S" https://britastro.org/jupiter/epsc/EPSC2011...ct-SEBn-jet.pdf -- I think SEB is southern equatorial belt, n is the northern part?

I've complained about this (to my mind obscure) nomenclature to the point of being obnoxious, but you have to call stuff something and this is traditional.

When we were developing Shadowcam, we tried to come up with ways of having the TDI be selectable so that we could still image on the dayside, but this was just too complex given the constraints of the electronics. So we always asked about Earthlight images, but the SNRs are much poorer than the dimmest permanently-shadowed regions (which you can see in the graininess of the images.) Still, it's better than nothing and a good indication that the system doesn't do too badly even at very low signal levels.

Hmm. Well, I don't know. Google for "SAR layover". I worked on Magellan just enough to be very skeptical of changes in SAR data acquired with much different geometries. I would hope that the reviewers knew more about it than I do.

https://www.science.org/doi/10.1126/science.abm7735

"We therefore cannot exclude the possibility that the flows were present when the Cycle 1 image was taken, but were not apparent in the image, perhaps because the surface texture makes the flows more distinguishable at the lower incidence angle of Cycle 2."

Seems like this is most likely a radar artifact to me.

First batch of images including several Io images on missionjuno now.

I don't think he was saying that, I think he was saying that Jupiter is a different color between hemispheres. But even if he wasn't saying that, you can't prove otherwise.

Not to complain, but when people here say stuff about radiation changes, someone from the project stumbles across it, and I end up having to do more work to try to quantify it. So far I haven't found unequivocal evidence that there have been intrinsic instrument changes. You could do me a favor by being as specific as possible about what you are doing, which images and which regions of which images, attempts to control for photometric effects if any, etc. Then I can just paste that into my slides, and I'll be happy to give you all the credit.