Juno Perijove 40, February 25, 2022 Options

[Kevin Gill]

Perijove 40 data is starting to be posted. I'm getting some weird timing issues with Europa, though.




Jupiter - PJ40-7

[Bjorn Jonsson]

This is image PJ40_4 of Europa in approximately true color/contrast. The image is enlarged by a factor of 3 relative to the original data:

Perijove 40 data is starting to be posted. I'm getting some weird timing issues with Europa, though.

I had to make unusual corrections to the pointing when processing this image of Europa and I expect this to apply to the other images of Europa as well. I could instead have made a *very* large correction to the start time so something weird may be going on.

[john_s]

Cool! That has to be the best image of Europa taken for almost exactly 15 years, since the New Horizons Jupiter flyby on February 27th 2007. Soon to be beaten, though.

John

[Bjorn Jonsson]

I had to make unusual corrections to the pointing when processing this image of Europa and I expect this to apply to the other images of Europa as well. I could instead have made a *very* large correction to the start time so something weird may be going on.

Additional info: I'm getting weird results for the Jupiter images as well. For image PJ40_11 I need to add something like 250 msec to the start/stop times to get correct limb fits. This is far bigger than I have seen before (the highest I've seen is ~100 msec IIRC).

[mcaplinger]

IIRC, every time before when somebody has reported "weird results" it's been because of out-of-date kernels or something like that. Please list your complete kernel set and I'll take a look when I get a chance.

We don't typically do the timing corrections until later but FWIW I don't see anything especially noteworthy in our processing so far.

[Bjorn Jonsson]

IIRC, every time before when somebody has reported "weird results" it's been because of out-of-date kernels or something like that. Please list your complete kernel set and I'll take a look when I get a chance.

We don't typically do the timing corrections until later but FWIW I don't see anything especially noteworthy in our processing so far.

I'll post a kernel list tomorrow (time to go to sleep now in my time zone). However, I suspect signs of these "weird results" can also be seen in the map projected color images posted together with the raw images at the missionjuno website. Below is a modified version of PJ40_11. In contrast, e.g. the PJ39 images are not like this.

[Brian Swift]

I'll post a kernel list tomorrow (time to go to sleep now in my time zone). However, I suspect signs of these "weird results" can also be seen in the map projected color images posted together with the raw images at the missionjuno website. Below is a modified version of PJ40_11. In contrast, e.g. the PJ39 images are not like this.

I'm not seeing a problem. My limb fit came up with a -0.00876s start time adjustment for PJ40_11 (shown below with limb marks on Jupiter and Io.)

[Bjorn Jonsson]

This is a stripped-down list of the kernels I'm using:

pck\pck00010.tpc
lsk\naif0012.tls
sclk\JNO_SCLKSCET.00127.tsc
fk\juno_v12.tf
ik\juno_junocam_v03.ti
ck\juno_sc_rec_220224_220225_v01.bc
spk\spk_pre_211130_220526_220210_jm0410.bsp

Using juno_pred_orbit.bsp instead of spk_pre_211130_220526_220210_jm0410.bsp makes no difference.

I'm not seeing a problem. My limb fit came up with a -0.00876s start time adjustment for PJ40_11

I'd be interested in seeing the list of kernels you are using. It's interesting that Kevin seems to having problems with the geometry that are very similar to mine.

[Kevin Gill]

Nice shots of the shadow of Ganymede during the departure phase. Still getting timing errors on these, though I tried to work around them some


Jupiter, Shadow of Ganymede - PJ40-39

[Brian Swift]

I'd be interested in seeing the list of kernels you are using. It's interesting that Kevin seems to having problems with the geometry that are very similar to mine.

Here's mine just with comments stripped.

CODE

KPL/MK
Juno meta-kernel
\begindata

PATH_VALUES = ( '/Users/bswift/Downloads/junospice/kernels' )

PATH_SYMBOLS = ( 'JK' )

KERNELS_TO_LOAD = (

'$JK/lsk/naif0012.tls'

'$JK/pck/pck00010.tpc'

'$JK/sclk/JNO_SCLKSCET.00126.tsc'

'$JK/fk/juno_v12.tf'

'$JK/ik/juno_junocam_v03.ti'

'$JK/spk/de440s.bsp'
'$JK/spk/jup380s.bsp'
'$JK/spk/juno_struct_v04.bsp'

'$JK/spk/juno_pred_orbit.bsp'
'$JK/spk/spk_rec_131005_131014_131101.bsp'
'$JK/spk/juno_rec_orbit.bsp'

'$JK/ck/juno_sc_rec_131006_131012_v03.bc'

'$JK/ck/juno_sc_rec_160821_160827_v01.bc'

'$JK/ck/juno_sc_rec_160828_160903_v01.bc'
'$JK/ck/juno_sc_rec_161204_161210_v01.bc'
'$JK/ck/juno_sc_rec_161211_161217_v01.bc'
'$JK/ck/juno_sc_rec_170129_170204_v01.bc'
'$JK/ck/juno_sc_rec_170326_170401_v01.bc'
'$JK/ck/juno_sc_rec_170514_170520_v01.bc'
'$JK/ck/juno_sc_rec_170709_170715_v01.bc'
'$JK/ck/juno_sc_rec_170827_170902_v01.bc'
'$JK/ck/juno_sc_rec_171022_171028_v01.bc'
'$JK/ck/juno_sc_rec_171210_171216_v01.bc'
'$JK/ck/juno_sc_rec_171217_171223_v01.bc'
'$JK/ck/juno_sc_rec_180204_180210_v01.bc'
'$JK/ck/juno_sc_rec_180325_180331_v01.bc'
'$JK/ck/juno_sc_rec_180401_180407_v01.bc'
'$JK/ck/juno_sc_rec_180520_180526_v01.bc'
'$JK/ck/juno_sc_rec_180708_180714_v01.bc'
'$JK/ck/juno_sc_rec_180715_180721_v01.bc'
'$JK/ck/juno_sc_rec_180902_180908_v01.bc'
'$JK/ck/juno_sc_rec_180909_180915_v01.bc'
'$JK/ck/juno_sc_rec_181021_181027_v01.bc'
'$JK/ck/juno_sc_rec_181028_181103_v01.bc'
'$JK/ck/juno_sc_rec_181216_181222_v01.bc'
'$JK/ck/juno_sc_rec_190210_190216_v01.bc'
'$JK/ck/juno_sc_rec_190331_190406_v01.bc'
'$JK/ck/juno_sc_rec_190407_190413_v01.bc'

'$JK/ck/juno_sc_rec_190528_190529_v01.bc'
'$JK/ck/juno_sc_rec_190720_190721_v01.bc'
'$JK/ck/juno_sc_rec_190911_190912_v01.bc'
'$JK/ck/juno_sc_rec_191102_191104_v01.bc'
'$JK/ck/juno_sc_rec_191222_191228_v01.bc'
'$JK/ck/juno_sc_rec_200216_200218_v01.bc'
'$JK/ck/juno_sc_rec_200405_200411_v01.bc'
'$JK/ck/juno_sc_rec_200601_200602_v01.bc'
'$JK/ck/juno_sc_rec_200724_200725_v01.bc'
'$JK/ck/juno_sc_rec_200915_200916_v01.bc'
'$JK/ck/juno_sc_rec_201107_201108_v01.bc'
'$JK/ck/juno_sc_rec_201229_201231_v01.bc'
'$JK/ck/juno_sc_rec_210220_210222_v01.bc'
'$JK/ck/juno_sc_rec_210414_210416_v01.bc'
'$JK/ck/juno_sc_rec_210607_210608_v01.bc'
'$JK/ck/juno_sc_rec_210720_210721_v01.bc'
'$JK/ck/juno_sc_rec_210901_210903_v01.bc'
'$JK/ck/juno_sc_rec_211015_211017_v01.bc'
'$JK/ck/juno_sc_rec_211128_211130_v01.bc'
'$JK/ck/juno_sc_rec_220111_220112_v01.bc'
'$JK/ck/juno_sc_rec_220224_220225_v01.bc'


)

Also, here are the "start time offsets" from my limb fits (though I haven't done a close inspection of how good the fits are).

CODE

<|"P40_36" -> 0.00706812, "P40_37" -> -0.00397714, "P40_38" -> -0.00363904, "P40_39" -> -0.000206484,
  "P40_40" -> 0.00141616, "P40_41" -> -0.00805855, "P40_42" -> -0.0231084, "P40_43" -> -0.0107555,
  "P40_44" -> -0.0292792, "P40_45" -> -0.00170158, "P40_46" -> -0.0319372|>

[Bjorn Jonsson]

I'm starting to suspect the problem could be an inaccurate kernel in the set of kernels released following the flyby. The main reason is that I'm not only seeing this problem in my processing (and Kevin has been having similar problems). I'm also seeing what I think might be evidence of this same problem in the 1600x1600 pixel map-projected color images released at the missionjuno site together with the raw data. This is a brightened version of PJ40_20 from the missionjuno site:



This is comparable to the version of PJ40_11 I posted earlier but here the error is even more conspicuous. Notice the dark area 'outside' the upper limb. The timing (or pointing or something else) error manifests itself very similarly when I run the raw images through my processing pipeline without adding ~250 msecs to the start time. I also find it interesting that I couldn't find anything comparable to this in several 1600x1600 pixel map-projected images from recent perijoves that I checked. In contrast, I've seen this problem in all of the 1600x1600 pixel map-projected PJ40 images from the missionjuno site I have checked but it seems to become smaller with time (it's not nearly as obvious in the southern hemisphere images). Edit: Even though this looks smaller in the S hemisphere images I have now found that the required start time correction is similar there (~250 msecs).

*If* this is correct (and I admit I'm far from sure), Mike should be seeing this problem too.

[Brian Swift]

I'm starting to suspect the problem could be an inaccurate kernel in the set of kernels released following the flyby.

Do you use SPACECRAFT_CLOCK_START_COUNT or one of the formatted time strings (IMAGE_TIME or START_TIME) as your time reference?
I use SPACECRAFT_CLOCK_START_COUNT.
While I have no reason to believe there is a problem with the _TIME values, if there were, it could explain why I'm not seeing the issue.

Also, these are the checksums for the spk files I'm using:
MD5 (spk/juno_rec_orbit.bsp) = ffcfe2dabf9739e60a10840256a6b480
MD5 (spk/juno_pred_orbit.bsp) = 261553f641e6220d8115aacdd1f8d965

[mcaplinger]

*If* this is correct (and I admit I'm far from sure), Mike should be seeing this problem too.

PJ40-11: Not the greatest fit I have ever seen but not that bad, at least on the leading limb. If anything, it looks more like a crosstrack error than a timing error.

[mcaplinger]

I had to make unusual corrections to the pointing when processing this image of Europa...

Here's the pointing I see for PJ40-05. Again, not great but doesn't seem out of family with typical errors.

I'm using spk_pre_211017_220412_220107_jm0400.bsp if that matters.

[Bjorn Jonsson]

Thanks everyone for the information above. I'm still not sure what's going on. I tried several different kernels without significant changes. Also a new SCLK kernel was released today but using it didn't result in any significant changes.

Do you use SPACECRAFT_CLOCK_START_COUNT or one of the formatted time strings (IMAGE_TIME or START_TIME) as your time reference?
I use SPACECRAFT_CLOCK_START_COUNT.
While I have no reason to believe there is a problem with the _TIME values, if there were, it could explain why I'm not seeing the issue.

I'm using START_TIME which I convert to a double precision value using str2et_c. I'll try SPACECRAFT_CLOCK_START_COUNT soon to see what happens.