| No | Date | Project Code | Observer | Support Scientist | Description & Scheduling Blocks | Response |
|---|
| 1 | 02/22/2007 | T_RCO340: | Larry Morgan | Larry Morgan | Performing the receiver checkout I had trouble balancing the system. I needed to set iftarget levels to 0.1/0.2 V suggesting that the iftarget defaults are not satisfactory. | Frank will be sponsoring a change to th IFTarget MR regarding the IF Target levels for the PF receivers. This work is expected to be started when Frank returns during the week of Mon, March 5, 2007.
|
| 2 | 02/07/2007 | AGBT07A_048_01 | Larry Rudnick & Shea Brown | Toney Minter & Dana Balser | The observers report higher than expected RMS for L-band. This is not unexpected and is likely from 1/f noise. However, they see the noise in the YY signal increase by a large amount. This begins at the start of a scan, persists for several scans, and then goes away at the end of a scan. Very strange.
Toney
Toney,
We've included plots of (calon-caloff), both xx and yy, for our 200 MHz bandwidth observation of 1422+83 (see graph). The plots are of two 6.25 MHz pieces of the spectrum:
Band 15: center freq.=1447 MHz
Band 26: center freq.=1515 MHz (this info. is also in the packet we gave you)
The x-axis is record number (basically time), and we have zoomed in on a
region that shows the yy (calon-caloff) going from a large rms to a much
smaller rms. Here are the start and end times for the high rms period, and
they occur during scan transitions:
START: 2007_02_07_20:34:41, LST=1.539849845e+03, moving from scan 135 to 136
END: 2007_02_07_20:36:45, LST=1.714326241e+03, moving from scan 138 to 139
We used the GBT Spectrometer calculator (for 6.25 MHz band,TSYS=15,t_on
and t_off = 0.4s) to calculate a theoretical rms of 10mK. We then added
this in quadrature with a 13mK confusion rms (estimated for 3 points/beam)
to get 16.4mK expected rms. Dividing this by the mean TSYS gives us a
theoretical RMS/MEAN=0.001 for the above plots. Our data are showing
instead:
XX RMS/MEAN=0.06
YY RMS/MEAN=0.12
Let us know what you make of this, and thanks for all the help!
Cheers,
Shea
| |
| 3 | 02/28/07 | several | several | Toney Minter | I have now seen several cases since the mid-February release of Astrid where the observers scripts do not show up in the Run Tab of Astrid. In each case no software people were available to see the problem. We had to restart turtle to get the scripts to show up. | We will look into this. Are you sure that only a restart of turtle fixes the problem? Restarting the user's Astrid GUI doesn't solve it? AmyShelton
We tried exiting Astrid and restarting it but this did not fix the problem. ToneyMinter
|
| 4 | 02/07/2007 | AGBT07A_048_01 | Larry Rudnick | Toney Minter | The spectrometer has been found to have varying "exposure times" (integration time minus blanking time) for spectra taken at the same time. We also see time variability in the exposure time within one set spectrum - this is larger than you would expect from normal blanking, switch period interactions. Rich Lacasse thinks that this might be a software issue. | Caused by problem in INTEGRAT column of the DATA table in the FITS file. Fixed
in 7.2. MarkClark |
| 5 | 03-31-2007 | AGBT06B_037_18 | Val Wiesner | Toney Minter | Astrid would not valid scripts because it claimed it did not have write permission in /users/vwiesner. However, the permissions for this directory were all set using chmod 777 and the problem still persisted even after closing and restarting astrid. Something subtle is going on here.
We worked around the problem by using a directroy in /home/astro-utils/projects/
| It is not clear why the workaround
suceeded, but the cause was that astrid,
during validation, requires the ability
to write files, e.g., 'config_status',
in the current working
directory and the pulsar scripts passed
to execfile() change the currently
working directory, sometimes causing
it to be a directory which contains
a 'config_status' belonging to another
user or group which cannot be overwritten. MarkClark |
| 6 | 04-03-2007 | AGBT07A_074 | Jack Hewitt | Toney Minter | For 7A74 the observer wished to use 8 spectral windows using the C-band receiver. By default this uses ODM 4. There is a bad ORM in CM6. This was taken out of the standard.cabling file. This resulted in the config tool saying that it could not route the signal path.
There is actually a way to route all the signal paths and this is to use ODM 3 rather than ODM 4. The config tool evidently did not identify this option before it reported an error saying it could not route the signal path.
What we had to do was to have the operator put ODM 4 into the dev_health.conf file to force the config tool to use ODM 3.
Luckily the observer found this problem while trying to validate his script about an hour before observing. This allowed the workaround to be thought of before he started observing.
| The other factor is that there was a Converter Module path removed from the cabling file. This bug report has been added to JIRA. MelindaMello |