Juno Perijove 40, February 25, 2022 Options

[mcaplinger]

At the hazard of speculating when I have not gotten my hands dirty with this data, does this pertain to the influence that close passes with the Galileans have on the subsequent trajectory/orbit?

What Bjorn is describing seems to be associated with orientation, not position. And there have only been two passes close enough to significantly change the trajectory anyway.

[mcaplinger]

The reason this happened seems to have been the clock kernel I was using. I was using the JNO_SCLKSCET.00127.tsc file released a day after PJ40. A reconstructed CK kernel was released at a similar time but apparently a different clock kernel is needed together with the CK kernel. Using JNO_SCLKSCET.00126.tsc or JNO_SCLKSCET.00125.tsc results in a far smaller error, especially the latter.

Could you produce a simple example of this where you show a large angular difference at the the same time for the same kernel files, with the only difference being the SCLKSCET kernel? Say, something like m2 = pxform("j2000", "juno_spacecraft", t); v = mxv(m2, (1,0,0))

As I understand it, CK files are essentially keyed by SCLK, so you need a valid SCLKSCET to use them (not a very out-of-date one, for example) but SCLKSCET files should be fairly continuous so using a newer one shouldn't make a big difference (barring big jumps in the spacecraft clock.)

Are you by any chance using the "high-precision" format clock? If you are, see if the results are different if you don't -- it's not useful for Junocam and seems to have had some issues over the course of the mission, though I'm not sure if it's used internally in CKs or not.

[Bjorn Jonsson]

Could you produce a simple example of this where you show a large angular difference at the the same time for the same kernel files, with the only difference being the SCLKSCET kernel? Say, something like m2 = pxform("j2000", "juno_spacecraft", t); v = mxv(m2, (1,0,0))

Here is what I get for four different clock kernels (123 is JNO_SCLKSCET.00123.tsc etc.). I have always used the standard clock. The time I used when calling pxform is near the start time of the PJ40_4 Europa image.

123: v = (0.02346654, -0.30000134, -0.95365010) sclk_string=5/0698999556.077
124: v = (0.02253210, -0.30007218, -0.95365035) sclk_string=5/0698999556.081
125: v = (0.02561664, -0.29982719, -0.95364954) sclk_string=5/0698999556.068
127: v = (0.03678213, -0.29867191, -0.95364677) sclk_string=5/0698999556.023

Some angular differences:

124 vs. 127 difference: 0.820406° (I have no experience with what qualifies as large here but this looks large to me)
124 vs. 125 difference: 0.177288°
124 vs. 123 difference: 0.053693°

Kernels used:
pck\pck00010.tpc
lsk\naif0012.tls
sclk\JNO_SCLKSCET.00124.tsc (and also 123, 125 and 127)
fk\juno_v12.tf
ik\juno_junocam_v03.ti
spk\jup380s.bsp
ck\juno_sc_rec_220220_220226_v01.bc
spk\spk_rec_220204_220319_220330.bsp

Interestingly (and as mentioned earlier in the thread), the "official" PJ40 map projected images at the missionjuno website also seem to show hints that something strange was happening. This is visible at the limb.

[Bjorn Jonsson]

Additional information: It suddenly occurred to me that it might be interesting to compare the image times in the files released immediately following PJ40 and in the PDS files released later. I compared the START_TIME for image PJ40_20 in the file 12617-Metadata.json (released immediately after the flyby) to the time in the PDS file JNCR_2022056_40C00020_V01.LBL. The time in the PDS file is 0.236 seconds higher. This is a large difference.

[mcaplinger]

The real problem now is that I haven't found any reliable way to determine which clock kernel I should use together with a particular CK file.

As far as I can tell from https://naif.jpl.nasa.gov/pub/naif/toolkit_...s/C/req/ck.html no SCLK file result is embedded into a C kernel file, so there is no implicit dependency (though I'm not sure the source for the code that makes C kernels is available anywhere). A newer SCLK file should always just cover a larger range of time than an older one, not be inconsistent in the overlap time range (though I can't say if this has always been true, it would be easy enough to check.) If you use an SCLK value that's later than the end time of a given kernel, you get an extrapolation, which will almost certainly be less accurate than using a newer kernel.

Kernel 123 was produced months before kernel 127, so there's no reason to think it would be better for times around the end time of 127, unless these files are screwed up in some way.

I'd recommend asking NAIF if you can identify a very specific problem, in my experience they are extremely responsive. FWIW, when we did the timing corrections for PJ40, the largest error was 9 pixels (image 46). We did that on 7 April 2022 and used the latest SCLK available at that time, which I'm assuming would have been 129.

[volcanopele]

I'm not sure if this adds to the discussion AT ALL, but as part of my Io JIRAM work I do limb fitting and here are the offsets I calculated for those PJ40 Io images:

CODE

Observation    Image Mid-Time (UTC)    Xoffset    Yoffset
JIR_IMG_RDR_2022055T140151_V01    02/24/2022 14:01:49.296    -0.25    -0.75
JIR_IMG_RDR_2022055T140221_V01    02/24/2022 14:02:19.399    -0.35    -0.5
JIR_IMG_RDR_2022055T140251_V01    02/24/2022 14:02:49.500    -0.25    -0.9
JIR_IMG_RDR_2022055T140321_V01    02/24/2022 14:03:19.603    -0.5    -0.9
JIR_IMG_RDR_2022055T140352_V01    02/24/2022 14:03:49.705    -0.5    -0.75
JIR_IMG_RDR_2022055T140422_V01    02/24/2022 14:04:19.807    -0.25    -0.25
JIR_IMG_RDR_2022055T140452_V01    02/24/2022 14:04:49.909    0    -0.25
JIR_IMG_RDR_2022055T140522_V01    02/24/2022 14:05:20.011    -0.25    -0.5
JIR_IMG_RDR_2022055T140552_V01    02/24/2022 14:05:50.113    -0.35    -0.5
JIR_IMG_RDR_2022055T141023_V01    02/24/2022 14:10:20.995    -0.25    0
JIR_IMG_RDR_2022055T141053_V01    02/24/2022 14:10:51.099    -0.25    -0.25
JIR_IMG_RDR_2022055T141123_V01    02/24/2022 14:11:21.201    -0.25    -0.25
JIR_IMG_RDR_2022055T141153_V01    02/24/2022 14:11:51.304    -0.35    -0.4
JIR_IMG_RDR_2022055T141223_V01    02/24/2022 14:12:21.407    -0.35    -0.6
JIR_IMG_RDR_2022055T141253_V01    02/24/2022 14:12:51.509    -0.2    -0.6
JIR_IMG_RDR_2022055T141323_V01    02/24/2022 14:13:21.613    -0.2    0
JIR_IMG_RDR_2022055T141354_V01    02/24/2022 14:13:51.715    -0.2    0

These were calculated at the time of the PDS release so with whatever sclk file was available at the time (so at least 129 if not later)