The first one updates nustarclock.py to include a new "bad Malindi" range that's hardcoded to account for the large gaps in the MLD data due to a clock issue at the ground station. This allows the code to use the clock measurements from the Singapore ground station to track the NuSTAR clock.
The second commit is a slew of new entires to the "BAD_POINTS_DB" file throughout the bad Malindi window and through ~mid-May 2021.
Before the change, this is what things looked like:
and after, this is what things look like:
Note the difference in Y-axis scales. We're back to within a few 100 microseconds residual timing error, which is good. I tried this last week, and I don't think we had enough data points to interpolate across the gap and makes things work out nicely.
The latest rolling average is a bit worse than usual (probably due to the large clock slews that are happening to bring the oscillator back in family), but it's probably the best we can do for now.
This PR has two commits:
The first one updates nustarclock.py to include a new "bad Malindi" range that's hardcoded to account for the large gaps in the MLD data due to a clock issue at the ground station. This allows the code to use the clock measurements from the Singapore ground station to track the NuSTAR clock.
The second commit is a slew of new entires to the "BAD_POINTS_DB" file throughout the bad Malindi window and through ~mid-May 2021.
Before the change, this is what things looked like:
and after, this is what things look like:
Note the difference in Y-axis scales. We're back to within a few 100 microseconds residual timing error, which is good. I tried this last week, and I don't think we had enough data points to interpolate across the gap and makes things work out nicely.
The latest rolling average is a bit worse than usual (probably due to the large clock slews that are happening to bring the oscillator back in family), but it's probably the best we can do for now.