Any idea why there are shifts in TESS data from one file to the next?

Science Data Mining
1

I have downloaded five files of TESS data for GSC 3894-0138, and have converted the flux to magnitudes.

TESS_data_all_five_files
TESS_data_all_five_files1920×1200 1.15 MB

The data covers a period from 2022/09/02 to 2023/01/17. There are significant shifts in the magnitudes from one file to the next. Does anyone know what might have caused these changes?
Allen Gilchrist

1 Like
2

Good question. I almost often get the same stair with light curves, processed by TESS. The reason obviously is not in the filters - TESS uses one broad bandpass.

3

So the short answer is systematics. TESS is actually composed of a several individual cameras and the entire telescope is rotating from one sector to the next. This means that often the star in question will be moving from one camera to another which can cause offsets because every camera, while the same from a design standpoint, will be slightly different. Additionally, there are other affects such as the orientation of the telescope relative to the sun and many other factors that can cause these differences. You really should not trust TESS magnitudes in the absolute sense. If you want to analyze the data you should work with differential data and either normalize the data itself and/or remove these offsets.

Clear Skies,
Bert Pablo
Staff Astronomer, AAVSO

2 Likes
4

Bert,
Thanks for the response. I suspected that the differences might be due to measurements with different cameras in the cluster and different orientations. I have used TESS data in the past for determining times of maxima and for Fourier analysis. The shifts won’t affect the ToMx times, but they will show up as very low frequency components in the Fourier transforms. I’ll need to normalize the different files before doing a Fourier analysis on the entire data set.
Allen

5

The object can also fall on different pixels on the same camera, causing slight differences in signal.

For short period variables, though, you have the advantage that (presumably) the star should have the same average magnitude over each sector. So, what I often do is scale the flux for each sector (really each orbit) to the overall average for all the sectors I’m looking at. Then I convert everything to a magnitude.

Obviously, for long period variables this is not possible.

-Kenneth

2 Likes
6

Is this actually the case? The shifts are in the magnitude ranges with no changes in frequency (unless the period of the star is also changing).

7

Roy,
I’ve already done a DFT on the entire data set, and the shifts do show up in low frequency (f ~ 0.014 to 0.021 cycles per day) components with statistically significant SNR values. These correspond to periods of between 48 and 71 days. If you look at the plot I posted, you can see why these components show up in the DFT. If I process only one of the data files, those components are gone.
Allen

1 Like
8

This is an excellent example of aliasing due to ‘windowing’ i.e. how the data are taken as a function of time. So if you know data have a strong pattern like this (like a 24-hour alias one often gets from the ground), you want to do a period-search on the times when the data were taken, not only the photometry itself. You can imagine having a data-file with three columns: JD, mags, errors — do the period-search on JD column as well as the magnitudes.

\Brian

1 Like
9

Brian, That’s an interesting idea. How do I search for a period in the BJD column?
Allen

10

Just do the periodigram on the dates column just as with any other series of data (it’s just numbers!). Obviously it helps to include what you might know to be the data-taking cadence in the frequency/period search range to see if that period shows up. This is the same sort of thing as having a 365-day alias appear in Mira lightcurves caused by gaps in the observing seasons, but simply a different range of periods.

\Brian

11

Sometime ‘windowing’ appears during period search as unusual concentrations of points. Other example has been given by Sebastian, who noted on my mistake with moon cycle, affected on photometry.

12

I’ve spent the last three years trying to understand how to properly do photometry with TESS. I was not completely successful, but learned a few thins along the way.

While “systematics” is a general answer to “why TESS lightcurves look so weird”, the usual sources of systematics for TESS are kind of small: the gain is known for each CCD and is pretty stable, the flat field is applied during calibration - it’s hard to tell how good the flat-field measured on the ground is, but probably not worse than a couple of percent (an amount of variation introduced by its imperfections). TESS is doing an amazing job getting rid of cosmic rays: each TESS exposure is a combination of many short sub-exposures stacked with outlier rejection for each pixel’s vales.

The biggest source of systematics in TESS lightcurves is, surprisingly, background subtraction. TESS images have a funny looking spatially- and time-variable background due to scattered light from Earth an Moon entering the cameras. That’s not a big deal for a bright (say 10mag) star that stands well above the background. It’s a bigger problem for fainter stars, because the accuracy with which the background can be modeled and subtracted directly translates into accuracy with which the brightness of the star can be measured. As TESS have near-perfect pointing (like within 0.1pix) it’s possible to extract photometry for faint stars (say 16mag) that are totally invisible in the images by placing an aperture at the known position of that star. The resulting lightcurve will be completely dominated by the background, but it might still be useful as it contains some signal from the faint star too. One could remove the background variation by detrending the lightcurve and after that possibly see a periodic signal from the star. The down side is that if the star is not a well behaving periodic variable but some irregular variable or an active galactic nucleus - there is no good way to separate such irregular variability from background subtraction imperfections (well, at least I haven’t found one).

The related complication is that with 20"/pix image scale, TESS images at low galactic latitudes are confusion-limited: what one sees in faint pixels around bright stars is not the sky background, but a combined light of many fain stars. That, obviously, doesn’t help constructing very accurate model of the background.

My current theory is that this confusion limit is the ultimate cause of sector-to-sector jumps in TESS data. Thanks to near-perfect TESS pointing, we are dealing with one particular realization of confusion noise within one TESS sector. But going to the next sector TESS rotates and the pixels (new pixels, possibly from another camera - but I argue that this probably will not introduce a jump of more than a couple of percent) that overlap with the star image also overlap with a slightly different region of the sky producing slightly different contribution from confusion noise (light of faint unresolved stars). That can introduce a sector-to-sector jump of any magnitude, depending on how faint the target star is compared to the confusion-limited background.

Long story short - I don’t know what to do with sector-to-sector jumps. If the target star is a well behaving periodic variable one may just compensate the offset between sectors by subtracting mean (or median) brightness (obviously use Pogson’s formula when subtracting magnitudes rather than linear fluxes) from each sector before doing period search.

I have a collection of Jupyter notebooks implementing some TESS analysis: https://github.com/kirxkirx/v606vul_lightkurve
The notebooks are mostly focused on full-frame images, but the period search part would be the same for analyzing pre-extracted lightcurves.

3 Likes
13

Some resources to consider:

1 Like