Wednesday, January 28, 2009

How You Could Pilot a Space Telescope (Upside Down)

Stumble Upon Toolbar
This is the second in a series of articles on my experiences working with the MOST team on a study of Betelgeuse. This time, I look at the process of selecting targets and pointing the telescope.

When I first heard about public proposals for MOST (Microvariability and Oscillations of STars), I was quite interested and spent some time reading up on MOST on both the main web site and the outreach web site called MOST = My Own Space Telescope. I needed to understand both the capabilities of MOST and its limitations.

I should note that the proposal site is still open and accepting proposals. Just perhaps, you too may get a chance to pilot a space telescope.

What can MOST do?

MOST was designed to detect minute variations in light intensity in stars which turns out to be very useful if you are looking at things like:
  1. Star quakes (vibrations in stars), pulsations and other variable behaviour caused by the star itself or by outside influences
  2. Dimming from stars, planets and even asteroid swarms passing in front of a star
  3. Increases in reflected light from large close-in planets orbiting a star
The timescale of the variability must be short enough to be sampled well during the several weeks to two months that MOST can monitor a star continuously, or from year to year by having MOST return to the same target field in the sky.

It turns out there are lots of things on which MOSTs strengths can be brought to bear:
  • Looking for exoplanets (and swarms of exoasteroids)
  • Turbulence and variability in massive stars like giants and Wolf-Rayet Stars (just one type of pre-supernova star).
  • Variability in stars with companions such as black holes, pulsars, and dim dwarfs
  • Seismic variations in smaller stars similar to our Sun and other classes of stars
How to pick a target?

The MOST Science Team chooses targets based on the science they want to explore. What types of variations can teach them about the nature and life story of a star or planets around it? Are those variations likely in a particular star? And is MOST sensitive enough to see those particular variations in that particular star?

I think of this as the “bottom up” approach. I decided that as an amateur not immersed in the details and subtleties of astrophysics my best bet would be to play a different game and try a top down approach.

This approach led me to make a list of visually interesting and recognizable stars most of which were observable with the naked eye. My reason for choosing recognizable stars was to better connect with the public. Next I investigated the list for stars that would be (a) accessible to MOST and (b) suitable science targets for its mission. Again the order may seem upside down but determining visibility was easier to do in bulk than doing the research first.

My initial list contained over 50 stars and resulted in five proposals covering six stars. Below are a few of the ones not accessible to MOST for long durations:
  • La Superba - a very red carbon burning star in Canes Venatici
  • Eta Carina - a hyper giant that experienced a nova like event in 1843 and a possible Wolf-Rayet precursor
  • UW Canis Major - a Beta Lyra class contact binary - two giant stars orbiting each other every 5 day
  • Albireo - a spectacularly coloured double in Cygnus
Coincidentally, I later found that one of the stars on my list (but not proposed) had already been selected by the Science Team in their normal evaluation process.

How do I aim this thing?

The MOST = My Own Space Telescope public proposals page contains a lot of background on choosing target stars for MOST and the process for the public to submit proposals. Once you've selected an interesting target, you need to ensure that MOST can see it.

Targets (with some exceptions) need to be meet two major positional constraints (1) the CVZ or Continuous Viewing Zone, and (2) the SSR or Sun Sensor Range. The CVZ dictates how long MOST can look at a star without interruption and the SSR constraint has to do with MOST keeping its back and its main solar panels to the Sun (as shown below on the left), as well as maintaining a reasonable temperature for the spacecraft. The proposal site has a Java based Target Validation Tool that checks all of this but I built one in a spread sheet to work with my long list.

Left mage credit: MOST Team, CSA and UBC
Right image plotted from my proposal spreadsheet.

The second chart (above and to the right) shows a plot of some of the target stars that have been selected and proposed as candidates. The red arrows point to Betelgeuse and LG 5039 (a microquasar) - the first two winning proposals submitted by myself and by Gordon Sarty.

Proposal Review by MOST Team

The proposals were examined by the MOST Science Team to ensure that the candidates were likely to yield good science data; and by the Operations Team to ensure that the target could be safely observed by the satellite. Successful proposals are announced and scheduled.

I should say a few words about the proposals themselves. The information needed by the team is not large. They need to know the target star, its name (or identifier) and coordinates, your contact information, and a brief description of why you think this would be a good subject of study. If you feel the need to write a bit more, there is a place to attach a small document. You can find the submission form here.

Fine Tuning the Aim

MOST follows a Science Target by tracking Guide Stars near the target in the telescopes field of view. All of the Target and Guide Stars must to be within a maximum of 0.86 degrees (a bit less than the twice the diameter of the full Moon). There must be enough Guide Stars of suitable brightness close to a target for that star to be observed. That is not normally a problem.

The spacecraft can be “rolled” around the position of the target to optimise the guide star selection and to include stars which are also of scientific interest. MOST can monitor up to about 40 stars at a time, greatly increasing the scientific returns. The roll angle of the satellite is also chosen to minimise scattered light from the Earth (“Earthshine”) falling onto the focal plane of the instrument. The Team then maps out the positions of the Primary Science Target, Direct Imaging Targets and Guide Stars. The image below shows the MOST target map for Betelgeuse:

MOST targeting image, December 15, 2008, credit: MOST Team, CSA and UBC

As you can see, Betelgeuse (shown by the cross-hairs) is positioned under one of the central Fabry microlenses. The boxes show Guide Stars used to keep MOST pointing at Betelgeuse.

While in theory only two guide stars are required to keep the satellite pointed, in practice up to about 5 or 6 are actually used. All of these images are defocused over several pixels so that even minute variations in the intensity of the pixels watching a guide star can be used to detect and correct for any drift.

Another targeting wrinkle is that stars move ever so slightly due to what is know as "proper motion". Closer stars move more than ones further away. For example, Procyon (which has been studied by MOST) is very close to us compared to Betelgeuse and has a very much higher proper motion. The solution, a maneuver known as cross-hairs, takes sample measurements around the coordinates with the results being reviewed to fine tune the aim.

Keeping MOST on Target

MOST is able to keep itself pointed to a high degree of accuracy by combining information from several sensors that are listed below:
  • Position rate sensors which across 3 axis.
  • The Sun Sensor which uses a small pinhole camera on the back of MOST to determine the position of our Sun.
  • The two external Magnetometers (the large rods near the telescope opening) which sense variations in the Earth's magnetic field.
  • The Star Tracker that uses Guide Stars imaged by the satellite.
The accuracy of these sensors varies but most of these provide no more than 1-2 degrees of accuracy. It is the sub-pixel measurements provided by the Star Tracker in combination with the internal reaction wheels that can deliver the small kicks to keep MOST on target to within 1 arc second or less!

The other trick behind the ability of MOST to stare down a star for almost two months continuously is the orbit of the satellite. MOST orbits the Earth once about every 100 minutes but in a highly inclined orbit that keeps it moving east to west near the terminator so it can keep its back to the Sun and its front looking into the dark of deep space. Here is a track from Heavens Above of the orbit from near my location.

Switch Targets!

Not all targets require continuous observation and MOST has the ability to switch from one target to another in mid orbit. The process itself takes only a couple of minutes and it also means that some stars that are within the Sun Sensor limits but outside of the CVZ can be observed.

In fact one of my proposals was for pairs of targets which could be switched.

Here there be Dragons Protons!

One of the hazards MOST faces is radiation. A stray zap from a high-energy particle can scramble its software or damage its components. And MOST travels through a particularly hazardous realm known as the South Atlantic Anomaly (a low arm of the inner Van Allen radiation belt).

NASA ROSAT image showing the SAA.

The SAA is a potential satellite killer and MOST normally sails through it without harm. About once every two months, a cosmic ray hit during SAA passage can cause an on-board crash, from which MOST recovers usually by its next orbit. However, in January 2006, a very energetic particle hit disabled the original Star-tracker CCD, leaving only the Science CCD operational. The MOST Team always had a contingency plan to run the mission with only one CCD and it turns out that the performance of MOST is better than ever, after the MOST Team adapted to operating with a single CCD.

Adaptation!

MOST has changed since its launch. The teams have adapted and improved its capabilities in some surprising ways.
  • The loss of the guiding CCD forced the team to use the Science CCD for both pointing and science, and to come up with ways that actually enhanced the performance of the mission. A fringe benefit is that the reduced power consumption of one CCD extends the potential lifetime of the MOST mission.
  • The Science Team wanted to extract scientific data from the Guide Stars and the Operations Team made that possible. In fact, MOST has observed approximately 1500 stars in the 5+ years it’s been in orbit. The limiting factor is the amount of memory to buffer results between down-links to Earth and the high sampling rates usually demanded by MOST science.
Retrieving the Data

The MOST spacecraft buffers the science results and operational data until it can down link through one of three ground stations. Different send and receive frequencies are used. One interesting fact is that because the satellite is moving these radio frequencies must be Doppler shifted. Think of the horn of an approaching train and now try and imagine carrying on a conversation between two people on the ground and on the train.

A network of computers and computer programs are designed to divide and coordinate the work while providing fail over capabilities. The work is divided logically into managing communications at each ground station, managing the pass or snapshot data from the satellite, updating command and control, and managing the parsing, pre-formatting and distributing the down-linked data.



Related Articles and Other References:
Thanks

I'd like to thank Dr. Jaymie Matthews, the Science Team, Ron Wessels, the Operations Team at MSCI (Microsat Systems Canada Inc. formerly the Space Systems division of Dynacon Inc.) for their cooperation and feedback. I'd also like to thank the MOST team, the University of British Columbia, and the Canadian Space Agency for permission to use their images.

Next Article: TBD

5 comments:

Varun said...

Hello there!

I'm Varun, the principal software developer and maintainer for the MOSTValidator Java tool as well as the MOST contest website.

It may interest you to know that I'm rewriting the software. Details are on my blog entry at http://oracology.net/2010/03/idea-revamping-the-mostvalidator/


I'd like to know if you found any features particularly useful or useless that you'd like me to keep/reject. I fully realize the user interface is not up to par, as it was initially an internal tool for the MOST science team.

Nevertheless, your input is appreciated. Please feel free to include your suggestions as comments to the MOSTValidator article.

Thanks!

Varun

Mang (433rd) said...

Varun,

Thanks for leaving a comment on my blog about the revamp.

Im not sure how much I can help. When I was trying to figure out what to propose for MOST, I looked at a lot of stars and then figured out which might be interesting to study. So my approach was a bit backward in some ways and the validator didn't help me much. I basically build a (yuck) spreadsheet and populated it with everything I thought my me of interest. Many of the stars I looked at were interesting for different reasons.

As for rewriting it, I tend to avoid languages like C or C++ when higher level languages are available. I not sure you need it to be blisteringly quick so a good high level language could be a good choice. Python might be a good fit.

BTW. Your blogs comments function appears to be broken. I get an invalid data message when I try and submit.

Varun said...

Oh dear. Thanks for the note on the blog comments. I have been messing around with it recently. I'll take a look at it.

Regarding the choice for C/C++, it is my most comfortable language; hence I chose it. Python is a good fit for this purpose and PyGTK is available to build the software in the manner I was outlining, however, I am still a bit cumbersome with Python.

The thought of learning Python using this project as a launch point has not escaped me however. Thanks for the input.

Varun

Mang (433rd) said...

Varun,

I find I prefer higher level languages than C/C++. Many are more efficient to code and protect you from all sorts of administrative errors like memory leaks. Also, many are far easier to make multi-platform. C/C++ can shine in very tight/speedy spots but often that portion of the code is a small.

For that, I would have likely chosen something like Python had it been me. (I normally write in Unicon).

Mang (433rd) said...

Varun,

This very timely link came to me if you're looking to compare languages.

http://rosettacode.org/wiki/Main_Page