-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Precision on timestamps in Tess data #18
Comments
Thanks for pointing this out! Can you just clarify what you would expect to see if this bug was not present? |
Yes of course! If the bug weren't present, the difference in time between cadences should be nearly constant. In the frame of the spacecraft, they should be exactly constant, plus then there will be a smooth correction due to changes in barycentric correction as the spacecraft orbits the earth---and there shouldn't be any structure on shorter timescales. Here's a plot for two minute data binned down to 30 minute cadence. Note the y-scale, the change over an orbit is only 0.005 seconds or so! |
Great, thanks! I'll put this on my list of things to fix. |
Hi @ceb8, just wondering if there's been any progress on this? |
@danhey There has not been. Apologies. It's still on my list, I promise. |
@danhey This is fixed in the code and on master, but it hasn't bubbled up to TESScut yet. Also, because of where the bug was, I will have to go back and fix all existing TESS FFI cubes on our systems, which will take a bit. I will keep you updated. |
Hello!
We've come across an issue in the timestamps in TessCut frames (TessCut is a wonderful service, by the way!)
When I look the astrocut file timestamps, there is a digitization that I can see in them when we plot the difference in time between consecutive frames. We think this is a floating point rounding error in the timestamps, somewhere they are being stored as 32-bit floats and since the time values have four digits before the decimal place, this limits the precision to ~10 seconds on any individual data point.
You can see what I mean in figure form at afeinstein20/eleanor#119. The code to reproduce this is below:
The TASOC light curve times look proper, so we think it's a processing issue along the way rather than the way the telescope is recording data. If you think it's something upstream from astrocut where the bug is then I'm happy to work my way up the chain until we figure out where this is being induced.
Thanks so much!
Ben
The text was updated successfully, but these errors were encountered: