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.

[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).

[Bjorn Jonsson]

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:

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.

[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.