https://sese.asu.edu/research/psyche

The Psyche Multispectral Imager is a derivative of the MSSS MSL camera: http://www.hou.usra.edu/meetings/lpsc2016/pdf/1366.pdf

Mission design win #3 for that camera.

The Phoenix PI was at University of Arizona, not ASU. They're not the same.

You make me nostalgic for the old days when Doug Ellison would come in and shut down these discussions...

BTW, if people don't know about the work of John Rogers of the British Astronomical Association's Jupiter section, you can find it at https://www.britastro.org/node/7982 (some also posted on missionjuno but I prefer to go straight to the source.)

Refreshing change from all this processing discussion!

Double-precision floating-point constant.
Once upon a time there was a language called FORTRAN and all serious scientific programming was done in it...
similar syntax is used in languages like IDL.

This again? It's been discussed several times over the years.

The green cast to raw Mastcam images has nothing to do with compression, it's a function of the IR cut filter's bandpass. If you want to see what we say the image looks like color-balanced, see the color-corrected RDR PDS products.

I'm sure there's a long thread about this somewhere, I'm too lazy to search for it now.

Some reading on this topic:

https://www.lpl.arizona.edu/~showman/public...i-etal-2010.pdf

No mention of GR. Here's a paper on gravitational lensing by Jupiter:
http://iopscience.iop.org/article/10.1086/378785/meta
or https://arxiv.org/abs/astro-ph/0302294

The radial deflection was 1190 microarcsec = 0.0058 microradians. Lost in the noise for imaging systems.

I don't think so. If this was the case then all time conversions would require knowledge of position. I think the full extent of SPICE's treatment of GR is in the mapping from ET=TDB to TDT, which applies only to the Earth and is not something I've ever used. See https://naif.jpl.nasa.gov/pub/naif/toolkit_...ound%20Material

I'd guess, without having worked it out, that in the total error budget of spacecraft pointing, GR effects are several orders of magnitude down in the list, at least for spacecraft and targets like the ones we deal with now. In the future, if mission planners are flying relativistic spacecraft to black holes, the SPICE toolkit will have to be enhanced.

AFAIK, GR effects have never been part of the NAIF toolkit, but stellar aberration is: https://naif.jpl.nasa.gov/pub/naif/toolkit_...ice_spkezr.html
Although I doubt it makes much difference in this case.

Mods: IMHO this technical discussion belongs in some other thread.

Based on this reference DSIR used 16x16 DCT blocks and a single quantization value for all coefficients except the DC coefficient, unlike standard JPEG which uses 8x8 blocks and a different Q for each coefficient. The hardware DCT chip datasheet is http://www.littlediode.com/datasheets/pdf/...STV/STV3200.PDF and that describes the bit widths of the internal computation.

No, I should have read your post more carefully. I guess Amalthea might be barely resolved at minimum range, but I doubt that such an image would be of any real use.

I think they'd be resolved, Callisto would be about 4 pixels across if I did the math right. Turns out resolving the moons is not a big deal, we do that on every approach. Seeing useful detail on the moons is another thing.

The Junocam ring image in processed form is buried on missionjuno in the submissions section: https://www.missionjuno.swri.edu/junocam/processing?id=368 and the raw data is equally buried in https://www.missionjuno.swri.edu/junocam/processing?id=369 Note that the thumbnails are black so you have to click through to the full image.

Doubt if it's worth the anticipation, I was surprised we could see it at all.

PJ3 data posted -- https://www.missionjuno.swri.edu/junocam/processing

We've been steadily getting Junocam data and as of now have maybe 2/3rds of it. I think everyone will be pleased with the more favorable lighting on this pass, and it looks like the tweaks we made to the compression commanding have worked. I'm not sure when this will get pushed out to missionjuno. Normally we would wait for the whole dataset to show up and the DSN schedule has been spotty, for example, we were on the 34m net at Madrid last night and the data rate is low.

On the topic of public interest, obviously nothing new has happened since PJ1 apart from the problems with the propulsion system. All of the media reports I've seen have been supportive and enthusiastic about the mission. This was the first pass for public target voting, which had fairly good participation.

It would surprise me if there wasn't a local expert at VLT who has tools to deal with the specifics of this instrument.

For IR cameras, if you have a flat field at one scene temperature you can just subtract that from all scenes -- so-called "one point correction".

If you have two flats at two different scene temps, you can produce a multiplicative correction by taking the ratio of the two flats and an subtractive correction with the colder flat ("two-point correction").

Usually individual bad pixels have to be mapped and then interpolated over, although running a 3x3 median filter over the image can often be good enough.

Do you have any flat fields? Is this a fixed pattern?

If it is fixed, then this is detector 101 stuff. If it's not fixed, then your electronics is broken

I'd trust Daniel Sunshine over the Science Corner, so in situ. https://ntrs.nasa.gov/archive/nasa/casi.ntr...20100021925.pdf

BTW, I've always heard this pronounced "chimera" ( https://en.wikipedia.org/wiki/Chimera_%28mythology%29 ) and presume it's a bit of a backronym.

First images: http://www.esa.int/Our_Activities/Space_Sc...A_s_new_orbiter

Unlikely, it's a multiple beam Doppler radar which should be able to estimate attitude on its own.

AFAIK, typical flight control software doesn't use explicit validity checks but relies on Kalman filter weights to merge data from different sources. There is usually a big discontinuity at radar lockup as the IMU propagated altitude gets replaced. The story isn't making much sense yet but it seems like the filter was confused at this point, which seems like a pretty fundamental mistake as this is a known critical time.

I misspoke. While ring-sails were tested on Viking (and one was initially proposed for MSL) all US Mars missions have used disc-band-gap parachutes. See https://solarsystem.nasa.gov/docs/p491.pdf

The LDSD failures were of ring-sails.

Supersonic Mars parachutes are complicated. Viking proved the original ring-sail design, but this design doesn't scale very well. MSL development was all done in non-marslike conditions (higher pressure, lower velocity) in the big wind tunnel at NASA Ames and resulted in some failures which were only fixed late in testing. LDSD did flight-like testing at great expense for a larger parachute and despite lots of expert consulting (see https://www.nasa.gov/jpl/ldsd/the-supreme-c...rachute-experts ) both flights' chutes failed completely. One of the reasons that NASA is participating in SpaceX's Mars demo mission is because larger parachutes are not looking feasible after LDSD.

That said, the EDL demonstrator should have been well within the Viking/Pathfinder/MER experience base and should not have required additional flight testing IMHO. We'll just have to wait for the report to see.

The word "landing" doesn't imply success. See exchange below.

The last time the US did actual flight-like testing of supersonic parachutes was for Viking (not counting the LDSD flights, which both failed.)