Skip to content

Observing short period time-series

In this example our aim is to observe an exoplanet transit. This is perhaps the most tricky type of short-period time-series observation because the timing and duration are critical.

The key to making a good request is finding a balance between competing interests. The request window needs to be wide (flexible) enough so that it fits around "obstacles" in the schedule but also narrow enough to ensure you cover the time period of interest.

Below is a worked example. For this example, we assume:

  • You want to observe a 3-hour exoplanet transit with 30 minutes baseline beforehand and 30 minutes afterwards (for a total of 4 hours).
  • Your entire transit is visible during the night from at least 1 LCO site,
  • This 4-hour period occurs from 03:00:00 to 07:00:00 UTC
  • For simplicity, we will assume an exposure time such that expose+readout = 60 seconds. This would mean you need and exposure count of 240 images to fill the 4-hour period of interest.

Tip 1

Make your window slightly larger than the time you need, in case a filter change takes slightly longer at the start of your window. This will also help if there is recent bad weather and the telescope is starting up at the beginning of your window.

Tip 2

Use the "Acceptability Threshold" in the "Request" section to set the percentage of observations you need to capture your transit. The default value is 90 (%).

Tip 3

For extremely important events (i.e., destined for publication), you may wish to submit several variants, where you stagger your 4 hour window's start time by 5 minutes. This allows for any delays with your block getting scheduled, e.g. recent bad weather clearing. It will also enable the possibility of getting data from multiple telescopes and possibly multiple sites.
Caution: If you get multiple data sets, you will be charged for all of them

Important

Event timing

Start-of-night events are easier than end-of-night events but differ in strategy. For requests that need to start as early as possible, less padding is better. For example, if twilight ends at 2:30, you might submit requests like:

  • 2:30 - 7:05 window with 4.5 hours of images
  • 2:30 - 7:35 window with 5 hours of images
  • 2:30 - 9:05 with 6.5 hours of images


The goal here is to have a large-enough block that you can overcome the lack of scheduling flexibility.

Quick Reminders

Here are some quick reminders:

  • Don't use cadence: It is not meant to request a long block of continuous observations. It is meant to request a smallish chunk of data every so often, for monitoring a regular event.
  • Longer blocks have a higher probability of getting scheduled. It is usually helpful  to request a bigger chunk of time than you would otherwise need in order to get something scheduled.
  • If possible, focus on time-series events that occur near the middle of the night at an LCO site. These will lend themselves well to the strategy below. Avoid transits that finish near sunrise. Start-of-night transits are manageable with some work.
  • Multiple requests: we often submit multiple requests with different lengths for the same transit. We do this to try and work around other high-priority requests that might be being considered by the scheduler. You may get more data than you require.
  • Don't try to alternate filters: Changing filter wheel positions may significantly affect the time your observations will take to happen. This may make your observations impossible to complete.
  • Guiding - off: If there is a problem with the auto-guider finding stars in one of your images, it will stop observing if you have asked for guiding
  • Even if you do everything perfectly, you may not experience a high success rate. This is due to the competition for telescope resources on LCO.


Additional issues when using the 0m4 telescopes

Camera overheads for the LCO 0.4m cameras vary significantly and our scheduler just uses an average. What this means in practice:

  • If your request is scheduled on one of the "slow readout" telescopes, your observation will cover the time window you wanted but you will have fewer images than expected. This is usually OK.
  • If your request is scheduled on one of the "fast readout" telescopes, your observation will finish significantly earlier than you want. Depending on exposure times, a 4-hour request might finish much earlier, and you run the risk of getting an incomplete set.


To compensate, make sure you add more time than your event requires (see worked example above). Adding more of this extra time to the end of your request window will make sure your observation doesn't start early.