Paper says 250.37 +/- 101 g and 121.6 g is outside this range, but not by a huge amount (about 19% lower.)

PJ53 JIRAM data was released on 31 Jan 2024, but the cadence seems somewhat variable so it's hard to be certain. Months, certainly, unless there is some result that the team thinks is worthy of a press release.

https://atmos.nmsu.edu/PDS/data/PDS4/juno_j...undle/data_raw/

Informative, perhaps, but is it true? Well, it might depend on one's perspective. https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

I don't think the registers are 4 bits, I think the ALU does arithmetic 4 bits at a time on presumably 16-bit registers. This is called bit-slicing and was a fairly common design technique at the time: https://en.wikipedia.org/wiki/Bit_slicing

The Voyager FDS was designed several years before the first microprocessors. It has some unusual architectural features, including 128 general-purpose registers (mapped from the main RAM and not as separate logic entities) and a six-clock basic instruction cycle operating on 4-bit values per clock.

I'm not sure how the Voyager team is proceeding. If I were faced with this problem, I would try to build the smallest possible software load that would send useful telemetry to the transmitter. And to support that, I would build a software simulator of the system and make sure the behavior of existing loads was understood. The FDS memory (8K, I think) is loaded through the CCS, so it should be possible to experiment a bit with new FDS loads without the possibility of bricking everything, assuming of course that the CCS keeps working.

I'm not sure why you take issue with the simple claim that a lot of people who worked on the project are dead. And even if they're not, they may not be able to help for other reasons.

I note that the document talks about a software simulator that ran on an Interdata system. The 8/32 has SIMH emulator support (likely due to its use in the early development of Unix) so maybe there's some hope there. https://en.wikipedia.org/wiki/Interdata_7/32_and_8/32

FWIW, I reached out to the Voyager team and mentioned all of these possibilities.

If there has been wavelength-dependent degradation (I don't think the case is 100% made for this, but it would not be unexpected) it is almost certainly due to radiation darkening, which is caused by exposure to the jovian charged-particle environment. https://sci.esa.int/documents/34530/36042/1...rials_Doyle.pdf is a quick introduction to this and other effects in the context of Jupiter missions.

Junocam was designed with rad-hard glass* types in the front half of the lens and normal glasses farther back, shielded by the front half and also by a large cylinder of titanium. Of course, we were only required to last for 8 orbits, so for radiation effects to still be so subtle as to be debatable this late into the mission speaks to the conservatism of our approach. One could have expected the blue channel to be completely gone by this time otherwise.

It's possible that the annealing recovered some glass transmission that might have been lost, since the heater is attached to the optics and the optics thus warmer than the electronics we were trying to fix.

*I often refer to rad-hard glasses, only somewhat humorously, as "pre-darkened" -- they typically have poorer blue transmission on day 1 than their normal equivalents.

Sure, but if they had tools that ran on some 60s-70s platform, they might be operable with a simulator. A slightly newer example -- all of the tools for the MOC on MGS ran on a Microvax. By the end of the mission, I was running them on a simh software simulator since the Microvax hardware was long dead.

The biggest problem could be media -- it's progressively harder to read 9-track tapes -- but I'm sure there's a solution somewhere.

The article says this:

I find it incredible that they don't have any kind of simulator. I wouldn't even try to support a mission without at least a software simulator.

There's a little FDS information in Chapter 6 of https://ntrs.nasa.gov/api/citations/1988006...19880069935.pdf but all of the specifics are in JPL internal reports.

If these are map-projected products without an underlying DTM, then the relief at the limb will get mostly lost -- that's an inevitable consequence of this type of processing that Brian's method avoids.

Io images are up on missionjuno now. https://www.missionjuno.swri.edu/junocam/processing

Apparently there is going to be a live event with Q&A starting at 9:30 PST tomorrow (2/3) at https://twitch.tv/nasa if that's of interest.

I don't expect the data to be on missionjuno until sometime Monday 2/5, though I have been wrong about this before. There may be some pre-C-kernel images out earlier on social media.

Of course. The Peregrine leak only started after the Triton Space pyrovalves were fired. They apparently worked fine and the issue was downstream.


Possibly not, but heritage only goes so far. The components on Cassini and Juno had tons of heritage, but that didn't keep them from misbehaving.

Still nothing detected but JAXA was continuing to sweep/command as of 9 hours ago. Maybe tomorrow. https://nitter.net/coastal8049

That's what that tweet says, yes. Presumably JAXA has good orientation data from the images they have received but not yet released.

It's interesting that if you look at the metadata of this image, you see


so this looks like it was taken with a Fuji GFX100S in 7:6 L mode and then focus merged. https://fujifilm-x.com/en-us/products/camer...-image-quality/

It's raised.

Maybe it'll be helpful to review https://www.asteroidmission.org/asteroid-op...ns/tagsam_head/

I think most of the material you're seeing is overflow from the collection area proper.

Presumably the lower left is the vector sum of the three accel axes and doesn't say anything about orientation, and they only display the angular rates, not the absolute angles. But one imagines they wouldn't draw it upside down if it weren't in fact oriented that way.

For posterity, Jason's last message arrived too late to affect command generation, so what I said on 1/12 reflects what we commanded.

I'm never sure how timestamps work on this forum, I'm sending this at 12:46 PST or 20:46 UTC on 1/16.

Now, we wait.

Without a schematic of the propulsion system, it's really difficult to intuit what may be happening. Having done a little digging, apparently even the ACS thrusters are biprop (MMH doesn't work as a monopropellant, the spacecraft I'm familiar with that used dual-mode monoprop/biprop used pure hydrazine.)

Normally the large pressure gradient between the helium tank and the rest of the system would prevent any migration back into the helium tank, but if the pressure is equalized then all bets are off. Systems that aren't so mass-constrained have one-way check valves to keep migration from happening anyway (see Figure 1 in https://www.researchgate.net/publication/23...ion_Performance ) but it seems that Peregrine cut out anything that wasn't absolutely required.

It's not easy. To do it completely correctly, you need to know the pointing of the spacecraft as a function of time. For many of these flybys, including this one, the spacecraft spin axis (Z) is pointed at Earth, which makes it a little easier. So the Junocam FOV is a locus roughly +/- 30 degrees from the XY plane and spun about the Z axis. If a point on Io is in that locus we can see it, if it's not then we can't. I could imagine sampling a full range of lat/lon, checking to see if that point was in the locus, and drawing a little X there if it was, or something similar.

BTW, after much analysis I decided I couldn't take an image at 17:49, but one did fit at 17:48:30 so I took one there with TDI 12, then three images at 17:50 (TDI 12), 17:51 (TDI 2), and 17:52 (TDI 2). All RGB.

2024-034T17:32:00 RGB 6, 2
2024-034T17:39:00 RGB 2, 12
2024-034T17:48:30 RGB 12
2024-034T17:50:00 RGB 12, 2, 2
2024-034T17:53:30 RGB 12, 6

You have until Monday to change my mind

I think the difference (wait for it) is that Jupiter doesn't shine on the part of Io away from Jupiter, only on the part facing Jupiter. Duh.

So one shouldn't expect Jupitershine on inbound-to-Io images, only on outbound-from-Io images.

Have you compared the amount of Jupitershine in this encounter with the previous one? It looks similar, but I was surprised reviewing the PJ51 imaging that the nightside was much dimmer than it was in PJ57.

Probably this is just a Jupiter phase and Io orbit position thing, but the tools I have to look at this are clumsy.

Except Junocam isn't seeing the center of the disk at that point. IMHO 17:49 is too oblique.

I considered bumping everything back 30 seconds so starting at 17:49:30 but that's not a clear winner to me either, thoughts?

And you have to consider that due to spin phase uncertainty the position is uncertain by a spin period.

Whatever we do, I have a soft deadline of EOD today to decide.