I thought I would keep a log of what I do for observing tonight to share the experience.  Note that all times are my local time (EST).  (A discussion of the various times involved in observing is here.)

9:30 pm: I arrive at the office.  I’m not scheduled to be the telescope for an hour yet.  This is my time to collect everything I need for the night (notes, pens, etc.) and take care of important tasks – making myself a pot of coffee.

10:00 pm: Time to start preparing for the observing.  This is when I call the telescope operator, mostly to let them know that I’m here and ready to log in for my observing time.  I’m also setting up all the remote connections I need for the run now.  We use VNC for our remote observing.  This is a program that allows me to remotely display the desktop of one of the computers at Arecibo.  In essence, I’m running the programs that control the telescope and observations on a computer at Arecibo and using a viewer to have these programs displayed in front of me in Ithaca.  The nice thing about this is that if the internet connection drops out for a minute for any reason, the programs are still running at Arecibo – our observations aren’t affected.

10:30 pm: I’m on the telescope now!  Which means it’s time to start slewing the telescope to where we need it for the night.  This requires moving a giant arm that suspends the housing holding the receivers above the dish.  As the support arm and housing case for the receivers are both quite massive this can take a while.

10:40 pm: The telescope is in position and it’s time to start observations.  First, I run a script called TOGS which does calibrations for another observation program (G-ALFA) that piggybacks off of our observations.  This means that they record data while we are observing and use it for their own studies.

10:48 pm: TOGS is done running and it’s time to start the observations for the night.  I tell the telescope to start observing.  Ann talked earlier about how we observe, letting the telescope stay still and the sky move through the receiver.  This means that I don’t need to tell the telescope to do anything more until our time is up for the night and I start the observations.  My main job now is to monitor the data coming in and keep our log of the observations up to date.  Does everything look good?  Do I note something odd?  Then I should make a comment in the observing log.  Does something go wrong on the backend of the telescope?  Then it’s a bad night and I need to halt the observations, reset and start observing again.

12:30 am: I thought I would share a little bit of the data monitoring with you. The image below is a screen capture of the programs I use to keep an eye on things.  The top window monitors the power in each beam.  ALFA has seven beams, each with two polarizations.  You can see that the one there is one red number.  The power in one polarization of beam 6 is extremely low.  This is because this beam polarization is dead; it’s not receiving any signal.  This is a known problem and something I can ignore.  I need to make sure the power levels in the other beams stay within accepted values (blue).  If the powers get too high or low, the values change color to help alert me.  If the power levels start to go all crazy, I might need to restart things.  The bottom window contains the waterfall plots.  This shows the data instantaneously coming in for each beam, cascading up the screen.  If some sort of interference or strong source comes into the beams, I can notice it in these plots and make a comment in the log file for the night.  You might notice that there is a strong white line to the left side in each of the waterfall plots.  This is the FAA radar for the San Juan airport.  There is also a white line to the right side of the plots.  It’s harder to notice than the other line, but try looking at the center and upper leftmost plots.  This is the hydrogen in our own Galaxy.

Monitoring ALFA

Monitoring ALFA

2:16 am: It’s the most excitement observing has offered me tonight: I notice some GPS bursts.  (Not that I mind quiet nights observing at all.)  See the little white dots in the centers of the plots below?  That’s a short burst of radio signal from the GPS (Global Positioning System) satellites in orbit.  This is a type of noise called RFI – radio frequency interference.  Humans use radio frequency for communication and this produces signals that are observed incidentally with radio telescopes (like the airport radar).  As you might guess from the name (interference and all), RFI creates issues for radio astronomers.  Typically, we mark where RFI occurs so that we can mask those parts of our data.  We’re not going to be able to see any astronomical signals within the RFI and we want to get rid of it.  I made a note in the log of the GPS burst so that whoever processes the data from tonight’s observations will know that there was this extra RFI that they need to mask.  These GPS bursts have been extremely short in duration which is nice.  It means that there is less data we will need to mask out.

GPS burst

GPS burst

2:23 am: I get a little bit more excitement.  This time what shows up is a continuum source.  Do you see the bright swath across the bottom two plots?  It is a little bit higher and fainter in the left plot.  The sources the survey is designed to detect are “line” sources; they are the result of emission at a specific frequency (with Doppler shifts) due to atomic transitions.  There are other types of sources in the sky which emit at a broad range of radio frequencies; they are referred to as continuum sources since they emit across a continuum of the spectrum.  These sources are typically powered by a process known as synchotron emission.  You can see below how these sources show power across the plot, which shows the whole frequency range we observe.  While we are not observing continuum sources for science (although they can be quite interesting), we do use them to help with pointing corrections.  The positions of continuum sources are typically known to high accuracy so we can use them to know exactly where the telescope is looking.  Some continuum sources are strong enough that they can create artifacts in the data that make processing a little bit more challenging.  Once again, it is something that is useful to note in the log when they occur.  Plus, it helps me feel like I’m doing something active for the observing.

Continuum Source

Continuum Source

3:30 am: This is what I get for blogging about a night’s observing: an error message I’ve never seen before.  ERROR ‘Taking drift scan …’ should have finished 4 minutes ago! Not the most comforting words and it also flashed red at me in the display which tends to induce panic.  I’m still not quite sure what seemed to happen.  We observe the sky for ten minutes at a time before firing a calibrator and starting another ten minute observation.  We call each of these ten minute chunks a ‘drift’.   When this error message came up, I noticed that countdown on the current drift was off compared to when that drift had started.  That is, less time on the countdown for the drift had elapsed then since the drift should have started.  I thought I had a few minutes until the next drift started, so I was searching through the log generated by the observing software to see if I could figure out what happened.  While I was doing this, the next drift started at the time I would have expected it to had I not seen an error message.  Things seem to be running smoothly now, so I’m not going to worry about it too much.  I did run a program called ‘quicklook’ which produces a quick spectrum of the data.  It produced the image below, which looks exactly like I would expect.  I can see the dead beam, the radar (left spike) and the Galaxy (small right spike) – all things I know about.  Really, I was checking to see if the file with that drift was “good”.  I’m mostly glad that the program didn’t crash when I ran it as it would have if there had been something grievously wrong with the data file.  There’s still a possibility that the file could be bad.  If it doesn’t contain a full ten minutes worth of data, it will cause issues with our data processing programs.  At the end of the night, I run a script that converts all the data from FITS files (a type of image used in astronomical applications) to a structure that can be read by IDL, the software program we use for our data processing/analysis.  I will probably find out then if there are any issues with this drift.

Quick Spectrum

Quick Spectrum

05:12 am: The internet connection dies.  No online music for me and the VNC viewers stop updating.

05:16 am: I’ve been debating at what point I call the operator to see have them end the observations at Arecibo (it’s near the end of the night) when I regain an internet connections.  My VNC viewers update.  A wonderful feeling.

05:30 am: The end of the scheduled night’s observing.  I stop the current drift and run the end of the night TOGS script.  The time for running TOGS is scheduled on as additional time at the end of the night – it isn’t part of the block assigned to our program.  Now I do all the fun end of the night things.  I make a list of the files we observed, moved the logs from the night to the directories they belong in, update a webpage with the night’s observing information, convert the FITS image files into another type of data structure.  Basically, it’s end of the night housekeeping.  Normally I would have left the office by now, but I’m sticking around to make sure all the IDL structures are properly created from the FITS files as I’m worried about the one drift from the middle of the night.  That’s what I get for blogging about observing.  Oh well, it could have been worse.  I could have had a failure that required me to stop observations and restart.  I can safely say this now because I’m not just done observing for the night but for the near future.

05:56 am: Woohoo!  The file I was worried about was created just fine.  Now I can go home and sleep.

About these ads