That would not be possible, because it takes a lot longer than a spin to read out a full spin of data (over two minutes, in fact.)

One might assume that whatever magical process we used for, say, the PJ29 images of Ganymede (10 frames more or less centered on Ganymede) might be employed here in some form, but alas, I can't describe the details.

Sorry, no, because of the way we command these the details go outside the boundaries of the Junocam team.

Jason's animation gives you a good flavor of the likely timing, but of course the spacecraft spin phasing cannot be predicted in advance with any accuracy. We are almost certainly not going to try any imaging of the nightside because of time and data volume constraints. In rough terms, imaging will start around 16:57:30 +/- 15s and continue at 1-minute cadence for a while (TBD just how long, Ganymede leaves the field by 17:03:30 or so anyway but there are other constraints.)

FWIW, the kernels on the public NAIF site are the same ones we use.

I can't go into all of the constraints on timing and parallel operations we have for helicopter imaging, but suffice it to say that I think we are doing as well as we can within all of them. If people are still disappointed, oh well.

The helicopter sends extensive telemetry about its performance and the rover imaging is just a "nice to have".

Maybe we could move any discussion about future missions and capabilities elsewhere. And I rather resent the use of terms like "timid", "plodding", etc. Newer members might want to review Rule 2.6.

Not 100% clear that's true, but since slewing wasn't an option anyway, we didn't spend a lot of time digging into it.

No.

Can't say more, but here are a few technical terms: motor controllers, spread-spectrum radio, EMI.

Don't you think we would move it if we could?

Yes, this was described in post #175 upthread and a link in that post. The camera has some residual response even after the electronic global shutter is "closed".

I think all of the PJ33 images are on missionjuno now.

One problem is that this file (which we also use, see above) isn't on the NAIF web site at present, we've asked that it be put back up. The older ref files are, I think, wrong (as one would expect.)

Using the rec or later pre files should be safe, I hope.

Be aware that some of the files on the NAIF website produced before the EM was official will have the old pre-EM orbit, which I expect was the source of your problems. But I'm not sure which are good and which are bad or how this interacts with the ISIS kernel updating process, if that's what you're using.

Since I was on a number of teams for the 3 or 4 precursor missions and on a losing team for Clipper itself, I found that the book omitted all of the interesting details about those competitions (few of which, I expect, will ever be public). Not a surprise, since history is written by the winners...

Image 16 is SCLK 671800194:54 or 2021 APR 15 23:03:54.55 and the JSON on missionjuno says "IMAGE_TIME": "2021-04-15T23:03:54.546" so that all seems right to me.

We used juno_sc_rec_210414_210416_v01.bc and spk_ref_210111_251021_210111.bsp to do our processing, I believe, and it certainly found Jupiter OK.

Somebody has to pay for it. EDLcam DDC was 2Kx1500 and 140 grams not counting the processing unit. It's fairly hard to build a camera with decent optics that weighs 25 grams, at least for any definition of decent that I would use. Putting stuff up on the mast is very difficult. Doing things without interfering with the science mission is also difficult. EDLcam didn't have to deal with either of those problems.

This video rate has been a part of the Mastcam design all the way back to MSL (and was used for the MSL MARDI descent video, although there we had the flash space to store the images in raw form and read them out with compression later.) Though I'll acknowledge that there's not a huge amount of detail about it in https://link.springer.com/article/10.1007/s11214-020-00755-x ("Compressed color videos: Bayer pattern interpolated, 8-bit companded, lossy JPEG-compressed images concatenated into 16-frame motion-JPEG GOPs")

If JPL had wanted better video, they could have added another EDLcam I suppose, at some unknown cost delta (putting it on the RSM would have been prohibitive, I suspect, so it would have been fixed-pointing.)

Just to warn everybody -- owing to various DSN factors, it may be a while before the rest of PJ33 shows up.

When returning realtime-compressed video, 16 1280x720 frames have to fit in 2 Mbytes, so you can do the math about how much compression you can use. https://mastcamz.asu.edu/cameras/tech-specs/

I'm not sure what's going on with the JPL cameras, but WATSON raw color is exactly the same as MAHLI, and MCZ should be very similar to Mastcam. So if there are things you don't like about the color, they are common to MSL for those instruments. Unless the JPL raw site is doing something different -- I haven't followed what processing JPL is doing there. For sure they are doing a stretch. Honestly the MCZ color looks pretty decent to my eye -- better than the typical greenish hue of MSL Mastcam images.

Do we have to have yet another discussion about the subjective nature of true color?

"no best is quite so good you don’t conceive a better" -- ee cummings

Isn't this the same question that you asked and was answered in this thread back on post #102 and subsequent?

Good point. I thought this was all non-pyrotechnic, but based on https://www.compositesworld.com/news/nasa-i...or-first-flight you're correct, there was a pyro involved.

WATSON can only run at 1/4 the video rate of MCZ (like MAHLI on MSL.)

From "Curiosity’s Mars Hand Lens Imager (MAHLI) Investigation" https://link.springer.com/article/10.1007/s11214-012-9910-4 -- "For a 720p format video, the maximum rate is ∼1.9 frames per second."

This would hardly be remarkable, since most images are autoexposed. But the JSON metadata doesn't have any exposure time information that I can see.

1. Why would it be different?

2. No idea. I could look it up, but then I couldn't tell you. Did you look at the metadata?

3. I had nothing to do with the calibration target.

4. Not that I know of, we had no responsibility for ACI calibration.

Can't speak to exactly how they're modeling it, but my own experience with R/C helicopters of similar scale suggests that rotor downwash is a pretty ineffective way of cooling the motors on Earth, and nothing about the Mars helicopter suggests anything different. Take a look at figure 6 in https://trs.jpl.nasa.gov/bitstream/handle/2...L%2318-4405.pdf which shows the propulsion motors getting up to something like 85C worst-case. Of course, the range is extremely wide, suggesting that the thermal analysis is very conservative, as they usually are.