GB . Obsreports . SeptemberReport2005

Observing Reports - September, 2005

Reports for previous months are linked from the main obsreports page.

To report a problem with Astrid, use AstridReports

To submit a summary of your observing session, send an email to gbtobssum. To see previous emails, see the gbtobssum archives. You will need your username and gbtobssum mailing list password to view this.

If you would like to receive an email every time a staff astronomer adds a new Observing Report, or any time a member of Electronics or Software provides responses, click here (WebNotify) and add your name to the list.

Click on the header of any column to sort the log by that column's entries. Two clicks on the header does a reverse sort.

To edit this table, simply click "edit table" at the bottom of the page. You no longer need to edit the wiki page directly!

Entries are:

Date: Entered as yyyy-mm-dd (e.g. 2005-03-09)
Time: Approximate time (in EDT/EST) that error first occurred. Please give time using a 24-hr clock (e.g. 14:24)
Project Code: The is the full project code for the observing session, e.g. AGBT04A_042_12
Observer: Use last names only
Support: Last name of support scientist (yourself, if you are observing w/o a support scientist)
Instrument: This is the most common name of the instrument or software;
Bug, Etc.: This indicates the tupe of problem encountered
Priority: Urgent - Observations cannot proceed without this fixed; Important - this is going to be a problem very soon; Desired - Observations are going fine, but this would improve the observing experience
Time Lost: This is the total amount of observing time lost to this bug during the session. Please report using hh:mm
Status: This gives the current status of the project, along with the name (if any) of to whome the project has been assigned. Any further information regarding the status, such as project date of completion, when the project may be started, or why it was rejected, should be added to the project description. The status could be any of: Submitted; Approved by the CCC; Assigned (The last name of the person to whom the problem was assigned should be given in the "Response" column); On hold (until someone can be spared to work on the problem); Rejected (never to be worked on). The status should be updated as the project is worked on.
Description: A complete description of the problem, with all information that seems relevant, including the number of times the even occurred during observations
Response: Response of the person responsible for fixing/assessing the issue. These comments should be signed by the author. * Scripts: Attach any relevent set-up or observing scripts in this column

No	Date	Time	Project Code	Observer	Support Scientist	Instrument	Bug, Etc.	Priority	Time Lost	Status	Description	Response
1	2005-09-04	10:20	AGBT05B_011_39	tminter	tminter	Converter Modules/Rack	Problem	Urgent	1:00	Fixed	The converter rack synthesizers became unlocked and the data looked horribly. This was then followed shortly by errors with the converter rack a power supplies. Roger Norrod came in and found the the 10 MHz module was overloading the power supplies. He put in a new 10 MHz module and everything worked fine. About 1 hour of observing time was lost.
2	2005-09-04		AGBT05B_011_39	tminter	tminter	Other	Problem	Urgent		Fixed	The door to the control room is in dire need of attention. I have to put quite a bit of effort into opening the door. I would suspect that it is becoming nearly impossible to open for some folks.	Jonah lubricated the door on 6 September. Found waxy coating on the mating surfaces; cleaned and lubricated. R. Norrod
3	2005-09-02		TPTCSDSB_050902	Balser	Balser	Rcvr8_10	Problem	Important		Fixed	There are drops in DCR power in X-band channel LCP -> ODM2 -> DCR A2. Tests suggest that this is downstream of the RF polarization switch. Roger N. and Bob S. have been informed of the problem and plan to have a look during maintenance.	Simon et.al. changed suspected bad IF Heliax on 7 September. Additional testing scheduled 8 September during maintenance. Further checks done 15Sept05, with no problems seen. We're calling this fixed. Please notify us if further problems seen during observing. R. Norrod
4	2005-09-22	03:15	AGBT05B_002	Braatz	O'Neil	Rcvr18_26	Problem	Urgent	03:39	Fixed	The data from the kband Rx showed system temperatures all over the place. After playing around a bit, Jim suspected the cals weren't firing. I (Karen) was called and came to the same conclusion. Roger Norrod was then called, who got Mike Stennes in to look at the problem	Mike & Tracy fixed the problem. It turns out there wasa loose cable.
5	2005-09-26		AGBT05A_041_10	Demorest	Ransom	Other	Problem	Desired	0	Submitted	Paul Demorest reported that when he was turning the Cals on and off using the receiver manager, that the gbtstatus database did not update the "Cal State" entry to reflect the change. A phone call with Melinda revealed that the "Cal State" entry (which is listed as "On" or "Off") does not really describe whether the cals are on or off, but only whether the cals have been setup to be used in the current scan (i.e. are they available). If this is the case, we should change the output of gbtstatus to say "Cals available?" "yes/no" instead of the very deceptive (IMO) current values. (Moved from Astrid Reports to here. AmyShelton)	This sounds like a very reasonable request. CCC members - Is this new wording ok? AmyShelton

-- RichardPrestage - 30 Sep 2005

Topic SeptemberReport2005 . { Edit | Attach | Ref-By | Printable | Diffs | r1.1 | More }

Revision r1.1 - 30 Sep 2005 - 12:27 GMT - RichardPrestage Parents: WebHome	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.


NRAO Home > Green Bank \| Wiki Topic: GB > Obsreports > SeptemberReport2005

Changes \| Index \| Notify \| Search \| Go