IPB

Welcome Guest ( Log In | Register )

10 Pages V  « < 8 9 10  
Reply to this topicStart new topic
Juno PDS data
mcaplinger
post Oct 9 2018, 11:02 PM
Post #136


Senior Member
****

Group: Members
Posts: 1765
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ Oct 9 2018, 09:55 AM) *
Mike, just curious, is there an explanation for the 20 msec START_TIME jitter...

It's a software issue having to do with when the timestamp is captured relative to when the command to start imaging is sent.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post Oct 10 2018, 05:01 PM
Post #137


Junior Member
**

Group: Members
Posts: 60
Joined: 18-September 17
Member No.: 8250



QUOTE (mcaplinger @ Oct 9 2018, 04:02 PM) *
It's a software issue having to do with when the timestamp is captured relative to when the command to start imaging is sent.

Is the the imaging electronics start signal linked to the spacecraft system clock or is it driven from some other free running
asynchronous clock? My thinking being that if the start was linked to the spacecraft clock, the 20ms jitter would
have a 1/256 sec (low precision spacecraft clock) quantization. So I could model actual start time as a 0 to 5 tick offset
from the adjusted captured timestamp.
Go to the top of the page
 
+Quote Post
mcaplinger
post Oct 10 2018, 06:20 PM
Post #138


Senior Member
****

Group: Members
Posts: 1765
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ Oct 10 2018, 09:01 AM) *
Is the the imaging electronics start signal linked to the spacecraft system clock or is it driven from some other free running
asynchronous clock?

Neither, sort of? It's complicated. The software sends the command to start imaging over a 57600 baud UART and that command is received and imaging starts based on the free-running oscillator in the JDEA. Meanwhile, back in the spacecraft computer, there is then a potentially variable delay before the timestamp is captured from the spacecraft clock.

Yes, the spacecraft clock is quantized, but the delay is of order 20 msec for reasons having nothing to do with that. The delay could be 20 msec and it could be 40 msec and it could, perhaps, be anywhere in between or even longer. I don't think it can be shorter but I can't swear to that.

I can't go into this in more detail, sorry.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post Oct 10 2018, 11:58 PM
Post #139


Junior Member
**

Group: Members
Posts: 60
Joined: 18-September 17
Member No.: 8250



Thanks Mike, that answers my question. (Just not the answer I was hoping for.)
Go to the top of the page
 
+Quote Post
mcaplinger
post Oct 11 2018, 01:01 AM
Post #140


Senior Member
****

Group: Members
Posts: 1765
Joined: 13-September 05
Member No.: 497



While I'm sure you appreciated this, it's worth noting that the uncertainty only applies to the START_TIME, the interframe time is set by the JDEA and has nothing to do with the spacecraft clock.

For on-orbit images, I've had some luck characterizing the START_TIME by doing limb fitting of the first image that contains the limb. It would be interesting to know if there are any systematics of the error, but none were apparent in my brief look at it. The cruise star imaging appeared to be behaving differently with regard to the error.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Oct 13 2018, 08:53 PM
Post #141


IMG to PNG GOD
****

Group: Moderator
Posts: 1976
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



QUOTE (mcaplinger @ Oct 11 2018, 01:01 AM) *
For on-orbit images, I've had some luck characterizing the START_TIME by doing limb fitting of the first image that contains the limb. It would be interesting to know if there are any systematics of the error, but none were apparent in my brief look at it. The cruise star imaging appeared to be behaving differently with regard to the error.

This is exactly what I've been doing. Following this I also do limb fitting of the last image containing the limb and then adjust the interframe delay slightly if necessary (I typically end up with values like 0.3711 or 0.3708 or something like that instead of 0.371). After I fixed a bug in my software several months ago and another relatively minor and obscure bug last month this usually is sufficient and no further adjustments are necessary. However, I sometimes need to adjust the pointing by something like 3 pixels in the horizontal direction in the really hi-res images. This might be because an SPK kernel containing the reconstructed PJ15 trajectory wasn't available (it is now). Also the images of the northern hemisphere are sometimes slightly problematic. It's as if the spacecraft orientation changes slightly during image acquisition but of course that's highly unlikely. I'm still working on this particular problem (apparently it's the only problem left in my processing pipeline). This doesn't cause any color channel misalignments though so it's not a big inconvenience.

As a 'sanity check' it would be interesting to know which START_TIME value you got for an image or two, especially for images obtained at an altitude of ~25,000 km or closer.
Go to the top of the page
 
+Quote Post

10 Pages V  « < 8 9 10
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 17th October 2018 - 10:03 AM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and copyright.

OPINIONS AND MODERATION
Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators.
SUPPORT THE FORUM
Unmannedspaceflight.com is a project of the Planetary Society and is funded by donations from visitors and members. Help keep this forum up and running by contributing here.