Hello everyone,
I recently encountered an issue. For variable star entries like BD+60 2611, which only have TESS data, the “Revision History” section usually includes a note like “mean magnitude derived from XXX.”
I’m curious about how this average magnitude is calculated. I’ve noticed that many such variable stars in VSX have photometric data from Gaia or APASS, but instead, data from Tycho or GCPD is used as the so-called average magnitude.
Additionally, it seems that these values need to be corrected before they can be used for calibrating TESS data. How is this achieved?
We recommend adding a mean standard magnitude from a photometric catalogue for TESS submissions because TESS magnitudes are not standard (are similar to Ic) and since all stars observed by TESS are bright, they tend to have well-measured magnitudes in catalogs like the GCPD, Hipparcos, etc. This applies when you can’t combine TESS data with observations from other survey like ASAS-SN, ZTF, ASAS-3, etc. A large number of objects can only be detected as variable with TESS (or Kepler) because their variations are of very small amplitude.
So the mean magnitudes adopted are taken from the above sources (Gaia DR3 is a very good choice now if the star is not too bright and is in the GCPD or Hipparcos), and since the amplitudes are tiny (usually <0.01 mag.), then the mean values are basically okay.
We do not calibrate TESS data, for VSX submissions just a magnitude offset is applied if we adopt a zero point from another survey. If only TESS data are used, you can plot TESS magnitudes as they are or even normalize them to 0 and show amplitudes.
About “correcting” the magnitudes, the only correction we apply is usually related to light contamination, since blending may affect some of the survey data. Each survey has its own resolution (you can see a list of surveys and their resolution in the VSX guidelines page), so we correct the magnitudes for light contamination, using Gaia DR3 magnitudes, which are free from contamination to <1".
One follow up, if you want to use Gaia DR3 magnitudes as the mean magnitude, it’s best you convert it to V. Usually you can do the conversion with Gaia DR3 G and BR-RP .
Hi,
I attempted to download the data from TESS and opened it using the plugin of Vstar. I noticed that the time presented in Vstar is in BJD.
When reporting to VSX, do I need to convert the BJD or directly fill in the JD column with the BJD values?
Hi Lucas,
What do you mean with “the JD column”?
Epochs in VSX are usually given in HJD, but the truth is that for every star with results from TESS, BJD is being added. The difference is small.
To be honest, stars imported from old catalogs that have not been revised, have JD dates, not even HJD. For the shortest period stars the difference between JD and HJD is large enough to cause problems.
We might discuss if we need to have multiple date type fields in the future VSX.
Hi, Sebastian.
I’m referring to the content at the “Epoch” when filling in the information for VSX.
I think that if I haven’t misunderstood the meaning, I can directly use the BJD from the TESS data to fill in the “Epoch” ?
Cheers, Lucas.
I do the conversion in Python (with astropy ). The specifics can be found in this notebook, of which one can use in a web browser without Python installation.
Does the converter (IDL - Julian Date) still work for you? Over the last few days, I’ve tried to use it but keep getting errors – it seems the site is down
And it affects BJDTDB converter plug-in in VStar too…
We currently only have a single field for dates and we have never forced people to convert BJD to HJD so most epochs we have in VSX coming from TESS data are BJD but are shown as HJD. The difference was small enogh not to consider it an issue.
We also have historical JD epochs from the GCVS shown in the epoch field. So the HJD label is actually not really accurate. In the new VSX we may consider adding different types of dates to avoid this. Fixing dates backwards will be a challenge though…
But observers should take care, depending on the type of data. For example, for the EW eclipsing binary BF Pav I have recently been observing for VSS, BJD_TDB minus HJD_UTC two nights ago was 71 seconds. I would regard that as too much to ignore because amateur observers can achieve measured times of mid eclipse with an error much less than 71 seconds.
For the interest for those observers who don’t usually have to worry about these conversions, BJD_TDB minus JD_UTC (as opposed to HJD_UTC) for BF Pav two nights ago was much greater at 461 seconds.
I am currently using AstroimageJ for aperture photometry. If the software knows the target, it accurately outputs all three times (JD_UTC, HJD_UTC and BJD_TDB) for every observation. Can be very useful.
Finally, only one conversion need be done for observations from one night even if they span several hours because the changes over that time are negligible (less than or much less than one second).
I totally agree with Roy: the difference between BJD_TDB and HJD is >1min, and it is sometimes visible in O-C diagrams. From my point of view, BJD_TDB is the best way to present times, especially when analyzing long light curves.
Any comments about the following info provided by CoPilot, especially the last section:
<<The time difference between Heliocentric Julian Date (HJD) and Barycentric Julian Date (BJD) can vary depending on the object’s position in the sky and the observer’s location, but here’s a breakdown:
Typical Time Difference
Up to ±4 seconds: This is the usual correction between HJD and BJD for most astronomical observations.
Why the difference?
HJD corrects for the Earth’s position relative to the center of the Sun.
BJD corrects for the Earth’s position relative to the barycenter of the Solar System, which accounts for the gravitational influence of all planets, especially Jupiter.
Directional Dependence
The correction varies with the direction to the observed object.
It’s small near the poles of the ecliptic, and largest near the ecliptic plane, where the Sun’s motion around the barycenter has more impact.
Time Standards Matter
HJD is often expressed in UTC, while BJD is typically in TDB (Barycentric Dynamical Time).
The time scale difference between UTC and TDB can be tens of seconds, so it’s important not to compare BJD_TDB and BJD_UTC directly.>>
One last comment. The online time utility at the link in Maksym’s last but one post does not provide direct conversion from BJD_TDB to HJD_UTC, instead converting to JD_UTC.
Even though BJD_TDB may win out in future software, I think in most cases the current practical choice is using JD_UTC when taking the image and changing to HJD_UTC prior to period analysis. It is likely adequate for ‘most’ periods considering it is only off by ± 4 sec from BJD_UTC?
I’m not advocating the use of BJD_TDB for AAVSO observers.
My interest in the various time standards relates to TESS data, which is in BJD_TDB. I analyse TESS data not infrequently for short period EBs of interest to Variable Stars South. The O-C data calculated in these analyses are in HJD_UTC.
My original point was that for this purpose the difference between BJD_TDB and HJD_UTC (several tens of seconds) is too large to ignore.
Of course, for most AAVSO observers personal data is taken in JD_UTC and for critical period analyis I presume converted to HJD_UTC.
Typical Time Difference
Directional Dependence
Time Standards Matter