Seems pretty unlikely. The longest wavelength it can observe is the thermal infrared to about 14 um. I haven't been able to find what the spectrum of phosphine looks like at visible to thermal IR wavelengths, but this would require there to be windows at the appropriate wavelengths for general atmospheric scattering and absorption, and enough SNR to be able to detect absorption lines.

These observations were made at wavelengths of around 1mm, much longer than any remote-sensing instrument that's been flown to Venus AFAIK (SPICAV only goes to 4.3 um). You need to penetrate down to the 50-km level, and you probably can't do that at shorter wavelengths. Which puts in situ measurement at a distinct advantage.

I'm not believing that this technology will be practical any time soon. See https://www.hou.usra.edu/meetings/exoplanet...ons/Gilmore.pdf for the current thinking of what could be done with a flagship budget, which has a goal of a lander that lasts 4-8 hours and a 30-day minimum lifetime balloon.

It will be an interesting moderator challenge to figure out how, or even if, this discussion can occur in light of rule 1.3.

Phosphine has been detected in the atmospheres of Jupiter and Saturn without exciting much comment I'm aware of. https://ui.adsabs.harvard.edu/abs/2009Icar......543F/abstract

The recollections of a recovering Magellan data processor: The noodle data came in two flavors: the really raw data that Brian is talking about, and the so-called F-BIDR (Full resolution basic image data record, https://pds-geosciences.wustl.edu/missions/...idr/dataset.cat -- map-projected noodles). Even during the mission, I didn't know anyone brave enough to look at the EDRs, and even using the F-BIDRs was considered pretty hard-core; not sure if going back to the EDR would really confer much benefit, but it would require a detailed knowledge of SAR processing.

There's no consensus that this has anything to do with the failures as far as I know. But Ithaco has started using ceramic bearings so maybe that will help if this was the root cause.

Note that Persephone would have 5 reaction wheels total, 2 for sparing.

Persephone already uses electric propulsion, though the viewgraphs are not terribly clear about exactly how the orbit insertion works -- it takes almost 10 years between the KBO flyby and arrival at Pluto. If you want really fast transit times, electric probably won't help. But you are talking a lot more launch vehicle delta-V than anything available now.

Solids have no particular advantages over storable biprops. A solid motor was used for Magellan; it worked but would not be anyone's first choice.

With regard to improving resolution, keep in mind that the satellite encounters can't be done for the convenience of imaging and the geometry is highly constrained by the spacecraft spin and spin attitude, so anything we get in that regard will be largely serendipitous.

And of course the extended mission is subject to approval and funding.

Considering that the resolution of the Voyager ISS NAC was 72x higher than the resolution of Junocam at the same distance, I'm not sure I'd say "certainly". If the closest approach was 320 km and if illumination conditions and spacecraft orientation were compatible with imaging there, then the maximum resolution Junocam could get is about 0.2 km/pixel at nadir. JIRAM could do about 3x better.

The Bolton presentation says 1-2 km resolution.

I'm not sure what the best resolution image of Europa from Voyager was, but there is global coverage at about 0.5 km/pixel from a mixture of Voyager and Galileo https://astrogeology.usgs.gov/search/map/Eu...bal_mosaic_500m although there are some gaps where the coverage is much worse or (near the south pole) even missing entirely.

Once more for clarity: there are multiple star cameras on the spacecraft. The SRU (two for redundancy, one active) is an engineering subsystem and the ASCs (four total) are part of the magnetometer, used for getting high-resolution orientation data for the magnetometer to remove the effects of boom motion. They can all be used for imaging, but it's the SRU that has been most used for low-light imaging and radiation monitoring at Jupiter.

The SRU is unrelated to the magnetometer. Maybe you're confusing it with the magnetometer's ASCs (Advanced Stellar Compasses)?

On this thread in general: The mission extension proposal will be quite detailed, and evaluated carefully. I think criticizing it on the basis of an OPAG overview presentation is a little inappropriate.

All US Mars missions have used either hydrazine monopropellant or MMH/N2O4 bipropellant. I'm unaware of any deep-space application for any cryogenic fuel of any kind after initial injection by the launch vehicle.

Centaur duration: "The present day Centaur vehicle looses [sic] upwards of 17-20 % lbm of Hydrogen per day" https://www.ulalaunch.com/docs/default-sour...n-2006-7270.pdf (There
are also avionics thermal control constraints but I'm not sure how driving those are.)

Keep in mind that any mission of reasonable cost pretty much has to use off-the-shelf systems; they typically can't afford to develop their own from-scratch flight infrastructure.

Did it turn out that step 5 was unneeded?

Would this work in theory? Probably. Is it practical from an engineering perspective? Not really, at least not right now. For example, there are no "space tugs" with high delta V and long on-orbit duration. The Centaur upper stage, for example, has a lifetime measured in hours or maybe a few days.

There are a lot of competing constraints in mission design, it's not all about orbital dynamics.

As interesting as the Oberth effect is, it seems to have seen limited use in interplanetary missions so far, largely because spacecraft either don't have significant post-injection delta V capability or they need it all for orbit insertion at the target. (It does get used to the extent possible during that orbit insertion.)

For example, look at where the burns were in the Juno 2+ deltaV-EGA trajectory. https://trs.jpl.nasa.gov/bitstream/handle/2...08-2728_A1b.pdf

JPL Horizons had some early optically-derived elements for Tianwen-1 but I expect those will rapidly become inaccurate. Hope is being tracked by the DSN but I don't know who is doing their navigation [edit: KinetX is doing it] or if any information is being publicly shared. So any simulation would be fairly schematic.

[Oops, spoke too soon, Hope is on Horizons at EMM (spacecraft ID -62)]

That's an interesting suggestion, we could look at that. Frankly, Junocam is not the best instrument on the spacecraft to be looking at lightning. We only take these images because the orbit geometry doesn't allow anything else and it's a way to keep the downlink full.

When I do that I produce an answer that matches the kernel value to numerical precision.

Here's my code. There's not much to it.

Are you sure you translated undistort correctly? I'm suspicious.

If Io subtends more than a couple of pixels, and you iterate over all pixels, you should obviously expect to get at least one hit*. This is of course a very stressing case. For debugging it makes more sense to overlay pixel hits on Jupiter on an image of Jupiter since it's much harder to miss. 1-2 pixel errors aren't unexpected once the start times have been corrected, larger ones would be unusual.

On the FOV pyramids, note that the I kernel says "They are provided for visualization purposes, do not represent the geometry of the actual FOV sides, and are not intended for quantitative analysis."

*Assuming you have the camera model correct. If you've got a bug associated with the focal length/pixel scale, then clearly you could still miss.

It's fairly hard to say. Galileo was taking long time exposures (tens of seconds long, IIRC) and we are taking much shorter exposures with TDI where the flash presumably only lasts as long as one pixel residence time. I guess if you assumed the flash duration was similar one could back out the relative radiometry, but I haven't done that.

"LT+S" corrections depend on observer velocity so these are not equivalent. If you used "NONE" or "LT" I think you'd find the answers were exactly the same.

Note that if you're using six significant digits for time you have about 1000 seconds of slop at the current epoch, but I assume you're just eliding for presentation.

You didn't transform the Io vector into the Junocam frame.

I suggest we take this offline since I doubt it's of much interest to the forum. You should have my email because we went over a lot of this back in 2016. Though actually, maybe someone else will have more insight into what's going on with your code.

This is certainly not the right thing to be doing. I know you tried it both ways and the second way is the correct approach.

Post the code by which you actually go from pixel x,y to Junocam frame pointing vector unless it's identical to the code given in the kernel. You want to be going in the correct direction (distorted to undistorted).

It would also be diagnostic if you computed the Io-to-Juno vector and looked at the angle between the pointing vector and that vector (in the same frame) to see how close they are. It's easy for sincpt to miss with the smallest of errors, and Io is obviously very small.

No, night side, during the high-TDI departure imaging.

We've seen similar things in the northern hemisphere on earlier PJs, e.g., pj14-002.

We can't be sure, but they're generally consistent with point sources (there are four pixels with values above background), whereas cosmics tend to either one pixel or many pixels in a line.

See https://www.storm-t.iag.usp.br/pub/ACA0330/...leo-jupiter.pdf especially Figure 5.