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