Nearly all of the PJ21 images are on missionjuno now -- one image is still partial AFAIK.

Be patient, the GRS views get better. We're still having some data dropout problems, I'd expect another push of images tomorrow.

Looks to me like our ground data system didn't command quite enough frames to catch the top limb of the planet in the red channel -- maybe it incorrectly assumes there can't be more than 40 frames in a nadir-centered image, which due to roundoff is not quite true. I'll take a look at it.

I'm not familiar enough with those sites to know what's broken -- the dates are wrong on MP but curiosityrover.com seems OK.

At any rate, if you don't tell anyone at JPL about whatever issue you are having, it's unlikely to be addressed. I've never known what group was responsible for the raw image site and have no control over anything.

Are you saying that there's something on https://mars.jpl.nasa.gov/msl/multimedia/raw that is actually wrong, or just that the page format changed? If there's an actual problem then you should report it to https://mars.jpl.nasa.gov/feedback/

Back in 2017 you were still speculating that it would be possible to fly from equator to pole. What changed?

I think it's a little early yet to know what the baseline mission profile will look like, though conservatism is not an unreasonable assumption.

I'll refer everyone to http://dragonfly.jhuapl.edu/News-and-Resou...4_03-Lorenz.pdf -- I'm not sure how many of the details of the imaging system design I'm free to disclose, and of course these are early days. From that document:



I think it's safe to say that the imagery quality will be many orders of magnitude improved over Huygens.

As for "global coverage" -- Titan is larger than Mercury, so one vehicle will only see a tiny fraction of the surface. But we'll see pretty much all there is to see from one vehicle's vantage point.

The electronics for MCZ are essentially identical to those of the MSL Mastcams, the major difference being that apart from the adjustable focal length, the optics fill the entire 1600x1200 active area of the sensor, rather than having vignetting at the corners which effectively reduces the area of the MSL Mastcams to something like 1400x1200.

"NASA's Mars 2020 Gets HD Eyes" -- Mastcam-Z cameras installed on the remote sensing mast: https://www.jpl.nasa.gov/news/news.php?feature=7414

Whoever wrote this managed to not mention the company that actually built the cameras.

Good question. The selected organization was supposed to conduct a contest during the 2019 spring academic semester and submit the top 25 names to NASA by 31 July 2019, but given that that semester is nearly over and the selected organization hasn't even been announced AFAIK, it seems like this is behind schedule.

https://nspires.nasaprs.com/external/viewre...6K%20Amend1.pdf

I think you only need to be able to read 4 of those lines to be able to reconstruct the orbital elements of the spacecraft.
https://www.physicsforums.com/threads/how-t...f-gauss.954514/

I sat down this morning with Justin Maki and looked at a bunch of color-corrected Insight images. Justin has, IMHO, done a spectacular job with this and most of the images are really nice. This particular one was obviously very dark and then it was simply linearly stretched on the clouds, which make them a lot more contrasty than they would really be. But the underlying blue tint is real.

I encourage everyone to look at the color-corrected versions when they get released to the PDS.

Well, it is after sunset and the martian sky is bluish at sunset, and then someone may have put a strong log stretch on it to simulate the eye response? Who knows, these true color things are slippery.

Signal levels in the lab are typically much lower than under solar illumination because it's hard to get sunlight in a lab.

The MER-heritage CCD has very low QE in the blue so the Bayer pattern needs a lot of boosting in the blue.

I'm not sure what issue you're actually reacting to.

Many numerical algorithms misbehave or even fail miserably in single precision. Double precision was added very early in the development of Fortran.

Standard Fortran didn't have anything like a character type until Fortran 77, though IIRC there might have been non-standard extensions in some compilers before then. https://en.wikipedia.org/wiki/Hollerith_constant

I guess you could COMMON a floating-point value with an integer and extract the bytes with divisions; I certainly hope this was uncommon in code.

It's worth noting that I doubt if JPL was using anything unique to them about the 7094, which was a standard well-supported IBM product that came with all the needed software infrastructure (although the Direct Coupled OS was developed by a third party it subsequently became an IBM product, apparently.)

Typically these sorts of operations are done in the compiler (7094 double-precision operations were implemented in hardware) so the code itself would be mostly portable except maybe for hacks dealing with overflow and underflow. It's pretty hard to get to the underlying representation of floating-point numbers from Fortran as far as I remember.

Have you read https://ntrs.nasa.gov/archive/nasa/casi.ntr...19660001134.pdf "Study of the Accuracy of the Double-Precision Arithmetic Operations on the IBM 7094 Computer", JPL Technical Memorandum No. 33-742, 1963?

Yes. The spacecraft was in a different attitude near perijove and we couldn't insure the camera wouldn't image the sun, which could potentially damage it, so we were directed to leave it off.

I think this is an actual data analysis using stray light from the Earth as seen in the TESS data. More or less pointless, but real.

I'll admit I didn't read the whole thing in detail either. If it's a joke it seems to be very long but not that funny.

If by "drone" you mean a multirotor of some kind, these are not as stable if a motor fails than the two-rotor coaxial configuration of this vehicle, nor as power-efficient.

I presume there's a camera for whatever hazard avoidance and autonomy the helicopter has.

Finally, there are no plans to do anything with the arm. If the helicopter lands badly, that's the end of its mission. It does have fairly wide-stance, high-clearance landing gear to protect against tipovers and bad landings.

C means losslessly-compressed 8-bit raster image and K means losslessly-compressed 8-bit raster video, so by itself that doesn't say anything about the exposure (see https://pds-imaging.jpl.nasa.gov/data/msl/M...R_RDR_DPSIS.PDF ) but if you don't have the metadata you have no way to know what the exposure times were.

Higher signal levels due to the evolving sun angle.

We are still using high TDI for some of the polar images in an effort to see the circumpolar cyclones better.