Jupiter - PJ40-7
Full Version: Juno Perijove 40
Perijove 40 data is starting to be posted. I'm getting some weird timing issues with Europa, though.
Jupiter - PJ40-7
Jupiter - PJ40-7
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:
Click to view attachment
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.
Click to view attachment
QUOTE (Kevin Gill @ Feb 26 2022, 09:06 PM) 
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.
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
John
QUOTE (Bjorn Jonsson @ Feb 26 2022, 10:39 PM)
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).
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.
We don't typically do the timing corrections until later but FWIW I don't see anything especially noteworthy in our processing so far.
QUOTE (mcaplinger @ Feb 28 2022, 12:59 AM)
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.
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.
Click to view attachment
QUOTE (Bjorn Jonsson @ Feb 27 2022, 05:05 PM)
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.)
Click to view attachment
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'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.
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.
QUOTE (Brian Swift @ Feb 28 2022, 04:45 AM)
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.
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
Jupiter, Shadow of Ganymede - PJ40-39
QUOTE (Bjorn Jonsson @ Feb 28 2022, 02:19 PM)
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|>
"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|>
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:
Click to view attachment
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.
Click to view attachment
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.
QUOTE (Bjorn Jonsson @ Mar 1 2022, 03:40 PM)
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
QUOTE (Bjorn Jonsson @ Mar 1 2022, 03:40 PM)
*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.
Click to view attachment
QUOTE (Bjorn Jonsson @ Feb 26 2022, 02:39 PM)
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.
Click to view attachment
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.
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.
QUOTE (Brian Swift @ Mar 2 2022, 01:43 AM)
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 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.
Monolith Herd Stampeding Across Jovian Plains
Animation of JunoCam images from perijove 40 on 2022-02-25 showing Ganymede’s shadow moving across Jupiter’s clouds. While the Juno spacecraft was moving through its orbit during the 1.5 hours over which raw data was collected, these images are rendered from a single point of view in the orbit to hold Jupiter fixed in the video frame.
Full Resolution versions at https://vimeo.com/684456354 and https://youtu.be/wA9jliQZSdI
Click to view attachment
Animation of JunoCam images from perijove 40 on 2022-02-25 showing Ganymede’s shadow moving across Jupiter’s clouds. While the Juno spacecraft was moving through its orbit during the 1.5 hours over which raw data was collected, these images are rendered from a single point of view in the orbit to hold Jupiter fixed in the video frame.
Full Resolution versions at https://vimeo.com/684456354 and https://youtu.be/wA9jliQZSdI
Click to view attachment
PJ40 Images, Exaggerated Color/Contrast
Click to view attachment
Full resolution available at https://www.missionjuno.swri.edu/junocam/processing?id=12680
Click to view attachment
Full resolution available at https://www.missionjuno.swri.edu/junocam/processing?id=12680
This is processed from image PJ40_33. Approximately true color/contrast and enhanced versions:
Click to view attachmentClick to view attachment
The JunoCam images continue to get redder (this change was discussed in an earlier thread here last year). I have mainly been using the South Tropical Zone (STrZ) as 'reference' when monitoring the color. This is an updated plot showing the B/R ratio in the STrZ. As earlier, the B/R=1 point is arbitrary.
Click to view attachment
Because of the reddening I recently changed the color correction I use in my processing pipeline. For PJ40 I multiply R/G/B with 1, 1.306 and 3.275, respectively. These values are preliminary and might change slightly.
Click to view attachmentClick to view attachment
The JunoCam images continue to get redder (this change was discussed in an earlier thread here last year). I have mainly been using the South Tropical Zone (STrZ) as 'reference' when monitoring the color. This is an updated plot showing the B/R ratio in the STrZ. As earlier, the B/R=1 point is arbitrary.
Click to view attachment
Because of the reddening I recently changed the color correction I use in my processing pipeline. For PJ40 I multiply R/G/B with 1, 1.306 and 3.275, respectively. These values are preliminary and might change slightly.
Was the reddening noticed in the recent Europa images? That would definitely speak to whether it is specific to Jupiter or not.
This color change is specific to JunoCam, it is not Jupiter's color that is changing. This can be verified by checking images of Jupiter obtained by e.g. Hubble.
QUOTE (Bjorn Jonsson @ Mar 6 2022, 03:03 PM)
This color change is specific to JunoCam...
I don't think that is definitive. All I can share is my conclusions slide presented at the last Junocam science team meeting (Oct 2021):
QUOTE
Something seems to be happening to the color, but it’s not clear if
it’s intrinsic to the instrument or not
If it were radiation-induced, that would not be unexpected
(remember, Junocam was only designed to last until orbit 8) but the
observed effect doesn’t match any expected morphology very well
As always, caution is warranted for any science application that
depends on precise knowledge of instrument photometric response –
don’t go off and write papers asserting that Jupiter is changing color just on
the basis of Junocam imaging
it’s intrinsic to the instrument or not
If it were radiation-induced, that would not be unexpected
(remember, Junocam was only designed to last until orbit 8) but the
observed effect doesn’t match any expected morphology very well
As always, caution is warranted for any science application that
depends on precise knowledge of instrument photometric response –
don’t go off and write papers asserting that Jupiter is changing color just on
the basis of Junocam imaging
Also, here's a mosaic of the radiation characterization image of Jupiter we take on each orbit through PJ34, linearized and normalized for solar distance.
Click to view attachment
Click to view attachment
Thanks - this is the best overview of the reddening I have seen.
This color change is specific to JunoCam...
I don't think that is definitive. All I can share is my conclusions slide presented at the last Junocam science team meeting (Oct 2021):
Yes, my post wasn't clear enough. I was referring to JunoCam images, regardless of whether the color change is intrinsic to the instrument or due to e.g. scattered light (or both). In this context I find it interesting that in the plot I posted the point for perijove 38 is an outlier and this happens to be the perijove when the spacecraft was oriented differently from other recent perijoves. Which means that the illumination geometry is different for the spacecraft components that might be scattering small amounts of light into JunoCam. The only really clear thing IMHO is that only a small part of the reddening (or none at all) can be due to a global color change on Jupiter since e.g. Hubble images I have looked at show no obvious color change (I can't rule out a small color change though but if present it's much smaller than the change in the JunoCam images).
QUOTE (mcaplinger @ Mar 6 2022, 11:18 PM)
QUOTE (Bjorn Jonsson @ Mar 6 2022, 11:03 PM)
This color change is specific to JunoCam...
I don't think that is definitive. All I can share is my conclusions slide presented at the last Junocam science team meeting (Oct 2021):
Yes, my post wasn't clear enough. I was referring to JunoCam images, regardless of whether the color change is intrinsic to the instrument or due to e.g. scattered light (or both). In this context I find it interesting that in the plot I posted the point for perijove 38 is an outlier and this happens to be the perijove when the spacecraft was oriented differently from other recent perijoves. Which means that the illumination geometry is different for the spacecraft components that might be scattering small amounts of light into JunoCam. The only really clear thing IMHO is that only a small part of the reddening (or none at all) can be due to a global color change on Jupiter since e.g. Hubble images I have looked at show no obvious color change (I can't rule out a small color change though but if present it's much smaller than the change in the JunoCam images).
Image PJ40_38, approximately true color/contrast and enhanced:
Click to view attachmentClick to view attachment
Click to view attachmentClick to view attachment
Regarding the discussion earlier on the unusually large value I had to add to the START_TIME to get correct limb fits (Kevin had similar problems): Using the reconstructed SPK kernel (instead of the predict kernel released shortly after PJ40) didn't result in any significant change.
It might be of interest that I have noticed that for PJ40, Juno's distance to the closest point on Jupiter I get by computing it from the SPICE kernels is significantly larger than the SPACECRAFT_ALTITUDE value in the *-Metadata.json files released with the images. The difference is typically ~500 km. This is rather large but comparable values have been seen for a few earlier perijoves so I don't think it has anything to do with the limb fit issues.
Finally on a different note, this is processed from image PJ40_22:
Click to view attachmentClick to view attachment
It might be of interest that I have noticed that for PJ40, Juno's distance to the closest point on Jupiter I get by computing it from the SPICE kernels is significantly larger than the SPACECRAFT_ALTITUDE value in the *-Metadata.json files released with the images. The difference is typically ~500 km. This is rather large but comparable values have been seen for a few earlier perijoves so I don't think it has anything to do with the limb fit issues.
Finally on a different note, this is processed from image PJ40_22:
Click to view attachmentClick to view attachment
QUOTE (Bjorn Jonsson @ Apr 11 2022, 07:30 AM)
It might be of interest that I have noticed that for PJ40, Juno's distance to the closest point on Jupiter I get by computing it from the SPICE kernels is significantly larger than the SPACECRAFT_ALTITUDE value in the *-Metadata.json files released with the images.
All we do is call SPICE recpgr with the IAU spheroid flattening and report the "alt" value. https://naif.jpl.nasa.gov/pub/naif/toolkit_...e/recpgr_c.html
I'm using subpnt_c to get the distance to the closest point on the target body using the value "Near point: ellipsoid" for the first parameter. This call isn't really a part of my main processing pipeline, I'm using it only because I was curious to know the distance to the closest point. I may take a look at this issue later but I should be getting an obvious limb fit 'mismatch' if the spacecraft position (or Jupiter distance) really is incorrect, i.e. if the location of the 'upper' limb is correct the 'lower' limb would have a large error (or vice versa). However, everything looks normal there.
I guess this could quickly turn into a discussion of using the SPICE toolkit, but in my python scripts using spicypy, here is my code for calculating altitude (which I think is just lifted from the spicypy tutorial:
CODE
method = 'Intercept/Ellipsoid'
target = 'IO'
tarfrm = 'IAU_IO'
abcorr = 'LT+S'
# obtain cartesian coordinates for sub-spacecraft point at the time of closest approach
[spoint, trgepc, srfvec] = spiceypy.subpnt( method, target, et, tarfrm, abcorr, scname )
# compute altitude
alt = spiceypy.vnorm( srfvec )
target = 'IO'
tarfrm = 'IAU_IO'
abcorr = 'LT+S'
# obtain cartesian coordinates for sub-spacecraft point at the time of closest approach
[spoint, trgepc, srfvec] = spiceypy.subpnt( method, target, et, tarfrm, abcorr, scname )
# compute altitude
alt = spiceypy.vnorm( srfvec )
I'm reviving this thread because recently I was processing some PJ40 data and I think that at last I now know what was happening here:
This was followed by fairly extensive discussion; I wasn't the only one running into weird issues.
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. However, the error is still rather large. Using JNO_SCLKSCET.00124.tsc results in a 'typical' error.
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. Apparently the file dates cannot be used to determine this. The CK kernel contains a clock kernel name but that name is always juno.tsc so it is useless. For a long time I was assuming that using the file released around or immediately following a perijove was OK but clearly this is not the case as implied above. Usually it has not mattered exactly which file I used (typically the resulting difference when replacing a clock kernel was 1-2 pixels or less) but recently (the past 10-15 perijoves or so), it has become more common for this to make a large difference. Having to use trial and error to determine which clock kernel to use with the reconstructed CK kernel doesn't make sense to me.
Does anyone know of a better or more reliable way to determine which clock kernel to use together with a particular reconstructed CK kernel? Using trial and error, it *usually* becomes fairly obvious which kernel to use but this is not always the case.
QUOTE (Bjorn Jonsson @ Feb 28 2022, 12:07 AM)
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).
This was followed by fairly extensive discussion; I wasn't the only one running into weird issues.
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. However, the error is still rather large. Using JNO_SCLKSCET.00124.tsc results in a 'typical' error.
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. Apparently the file dates cannot be used to determine this. The CK kernel contains a clock kernel name but that name is always juno.tsc so it is useless. For a long time I was assuming that using the file released around or immediately following a perijove was OK but clearly this is not the case as implied above. Usually it has not mattered exactly which file I used (typically the resulting difference when replacing a clock kernel was 1-2 pixels or less) but recently (the past 10-15 perijoves or so), it has become more common for this to make a large difference. Having to use trial and error to determine which clock kernel to use with the reconstructed CK kernel doesn't make sense to me.
Does anyone know of a better or more reliable way to determine which clock kernel to use together with a particular reconstructed CK kernel? Using trial and error, it *usually* becomes fairly obvious which kernel to use but this is not always the case.
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? That began about 20 PJs ago. Close passes to a third body in principle introduce accentuated unknowns in trajectories. Are the updates refinements based on information known only after each such encounter?
QUOTE (StargazeInWonder @ Jul 5 2023, 06:07 PM)
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.
QUOTE (Bjorn Jonsson @ Jul 5 2023, 04:33 PM)
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.
QUOTE (mcaplinger @ Jul 6 2023, 03:06 AM)
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.
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.
QUOTE (Bjorn Jonsson @ Jul 5 2023, 04:33 PM)
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.
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:
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)
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
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)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.