[X] My Assistant

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

[StargazeInWonder]

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?

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