Images are on missionjuno now.

Here's the lat/lon grid for the first image.

First Io image is up on social media, e.g., https://www.facebook.com/NASASolarSystem/

missionjuno data post to follow shortly.

Correct. Maybe we should have taken one, but Io starts leaving the FOV illuminated limb first by the time the resolution has gotten decent, so we judged it wasn't worth it.

We're less than a week out from the Io flyby. The first Junocam image should be taken at 2023-364T08:37:21 +/- 15s and the first four images are at 60s spacing.

Based on the photos, the screws on the periphery look like Phillips Torq-set ® screw heads. https://www.phillips-screw.com/drive_systems/torq-set/ Not what I would have used, but I'm sure this was carefully considered.

I'd love to know how they've tried to remove these, what state the screw heads are currently in, what state the bits they were using are currently in, and what they are actually planning to do next. Are they making new bits, or making a new wrench, or both?

Having been involved in projects that busted off a screw head in a piece of flight hardware a time or two (never personally, thank goodness) if you thought you might get contamination from the bit, you'll get even more when you have to drill into the screw head to remove it.

[added because I can't resist: if the Scoop-VII capsule in The Andromeda Strain had been this hard to open, the movie would have been much shorter. ]

https://blogs.nasa.gov/osiris-rex/2023/10/2...mass-milestone/ from October 20. I think the only value-added that Giz is providing is getting some sort of timetable statement out of NASA PAO ("we anticipate it will be opened in the first quarter of 2024").

https://www.nature.com/articles/d41586-023-03978-4 has a bit more recent info from AGU.

I sympathize with the PR problem NASA is having; almost everyone has experience with a balky screw and taking months to resolve it seems like a glacial pace.

I thought I saw an article that tried to link the drogue chute snafu with the stuck screws, but I'm not sure where, and it doesn't sound all that plausible.

Fingers crossed. But FWIW, I am certainly not holding my breath for this launch, which seems likely to slip even more, for Vulcan-related reasons if nothing else.

I also think it's amusing that the photo in the tweet makes it look like Peregrine only barely fits in the fairing, when in reality it is lost in all of that volume.

The bterms are only 8 bits, unfortunately. We did not anticipate this particular problem.

Alas, this isn't possible. The DRAM subsystem is designed around 8-bit pixels. In hindsight maybe we should have implemented a mode where one could get every other pixel in 12-bit form (there's something similar in CTX and LROC NAC) but obviously we weren't expecting this particular problem.

Similarly, if there's a better companding function that would improve on the current one given all of the limitations on the hardware (described upthread), we haven't been able to come up with it.

If there was something important enough about the blue channel to make up for the costs of reduced imaging cadence, extra processing, etc, then sure.

No, not for any image larger than 20 or so frames. You have to acquire all of the frames into JDEA DRAM and then transfer them all to the spacecraft before starting the next image.

(And I've just noticed an error in the Junocam paper -- it says "the data interface is a unidirectional three-signal RS-422 synchronous interface running at 20 Mbits/s" but the correct number is 4 Mbits/s.)

Thanks for doing this, Bjorn. Your results are impressive, and it makes me more optimistic that the PJ57 Io images will be useful.

You're certainly right that the blue channel is most badly affected.

I don't know for sure, but there's a lot of information in the Genesis failure report at https://ntrs.nasa.gov/api/citations/2006000...20060008607.pdf and this clearly shows three events and three sets of pyros (Table 2-3, below). I assume that the Genesis and OREx capsules are pretty similar electrically (though Genesis was supposed to use a parafoil.)

I didn't find anything with a similar level of detail for Stardust (all the best info is in failure reports. )

I know nothing about this except as a bemused bystander.

The press release https://blogs.nasa.gov/osiris-rex/2023/12/0...yment-sequence/ seems inconsistent.

My impression is that there were three events and three signals:

1) deploy cover and drogue;

2) cut away drogue;

3) deploy main.

and these were supposed to be fired in the order 1, 2, 3, but in fact were fired in the order 2, 1, 3 because they swapped 1 and 2. But if you read the text in the press release it sounds like they swapped 1 and 3, which would have been order 3, 2, 1 and might have had similar effects assuming that deploying the main with the cover still on wasn't a big deal (I'd have thought it would be, these deployments can be pretty energetic.)

I hope it's the press release that's confused and not the real failure analysis!

It takes about 150 msec to read out a one-band image and about 255 msec for a three-band image, plus exposure time. So the typical visible exposure time of 3.2 or 6.4 msec is only a small fraction of that time. It might be barely possible to take one-band images at an interframe of say 160 msec, which would overlap downspin by more than 50%. That could help somewhat but it's a pretty big impact for not much return, it seems to me. 4X is just not possible.

Both 1 and 2 would be limited in their cadence ("followed by/immediately" is no faster than the amount of time it takes to read the previous images out of DRAM to the s/c, many seconds). We've taken a range of exposure times (RGB/CH4/lightning) already and there seems to be very little difference in behavior with exposure time or from frame to frame at the standard interframe time. The fact that the offset occurs with images of black space suggests little dependence on signal level, we think it is a shift between the reset and video level coming out of the CCD.

I'm not a lawyer, I just know what they tell me I can and can't say. Some of this is now covered by EAR rather than ITAR, but it's not clear that it's helped. Maybe https://www.space.commerce.gov/regulations/...ol-regulations/ would have some useful background. If you argued that this is being overapplied, I wouldn't disagree with you, but it's above my pay grade.

Bad bits out of ADC, basically everything after the CCD amplifier output.

Radiation degradation of the CCD or possibly a bias voltage supply.

Before.

Digital hardware, see above. The problem is not in companding.

I'm sure you're aware that this is not a very realistic request.

There's a nice block diagram in https://www.missionjuno.swri.edu/pub/e/down...each_Camera.pdf that should answer many questions. As time has gone by, we've had to be more and more conservative about the level of detail we've released in the open literature due to ITAR. That said, it's more or less the same as what's described in a little more detail in https://agupubs.onlinelibrary.wiley.com/doi...29/2008JE003315 for the MRO MARCI, sections 3.3.3 to 3.3.5. I can't share the specific part numbers of any of the ICs, though.

I'm not following why you think using a shorter exposure time would help, or why it would increase the file size. Junocam is a pushframe imager, so we could reduce the exposure time as much as we wanted below the nominal 1 IFOV of blur at 3.2 msec. As far as we can tell, the noise and offset is largely independent of exposure time. You can see this for yourself by comparing the RGB, methane, and single-band lightning search images.

Yes. Unfortunately one of the major impacts of the offset becoming so large is that low signals are normally quantized more finely than high signals, but with a large offset this doesn't happen, and this degrades the SNR of dark parts of the scene (and would do so even if the noise wasn't present at all.)

In case it helps, the Junocam paper didn't provide as much information about the companding as it could have. This is all implicit in the lookup tables in the PDS product SIS, but just to be clear about how the hardware works, see below.

Did you have specific questions? I can't really do anything with a request this broad. And I think you are overestimating the value of the "ongoing analysis".

So you're suggesting, basically, that we turn it off and back on again? Always reasonable tech support advice.

Unfortunately, whether that would help or not (and that's not clear), we can't do it for fear it will never start up again, as almost happened at PJ48. https://www.nasa.gov/missions/juno/nasas-ju...yby-of-jupiter/

If the images became completely unusable, we'll likely try this because there wouldn't be anything left to lose.

[added: To be clear, we don't think this is a transient, but we can't rule it out and in the abstract your suggestion is perfectly reasonable.]

The Junocam team is well aware of annealing. One might look carefully at the dark current in the past few marble movies for evidence of heating going back several orbits. (Dancing around the limits of what I can say here.)

As far as we can tell, this issue is not related to dark current, which is a more gaussian noise source. And there are some limits to the amount of offset that can be put into the standard companding function due to bit sizes of registers. The images are unusable with any degree of heating. If we could reduce the temperature below the level it's at with no heating, we would do that and we believe it would help, but that's not really possible (recall that Junocam is inside a thermal-blanketed volume with just the lens looking out, and by design it's a stable not-too-hot, not-too-cold temperature in there. There's no active cooling.)

We did post an explicit invitation for new ways to process the data on missionjuno, see above.

I've said elsewhere that there are very few knobs we have to turn on the camera. We can't change, or even measure, any of the internal voltages. We could adjust the companding parameters and that's something we are considering. We can change the temperature of the camera, but it's much easier to make it hotter than colder, and in general hotter is worse.

The approach images have been posted so one can watch the problem develop on the inbound leg. The partial frames are, we believe, unrelated to this issue; those look more like the data loss problems we've encountered before.

Both, really, although I don't expect an idea about how to operate going forward that is something we haven't thought of.

From https://www.missionjuno.swri.edu/junocam/processing



Maybe more detail will be released at some point, and maybe not, I can't tell. We are exploring some possible mitigations, but if anyone has any ideas we'd love to hear them.

Per https://www.hou.usra.edu/meetings/planetdat...23/pdf/7073.pdf